6th TF-DLT Meeting (September 2022) Notes

14:00-14:05

Welcome

Follow up to June's meeting

14:05-14:35

Klaas provided an update on the latest round of EC calls on EU ID wallets and the likes. 

EBSI is still growing and needs to keep growing; eIDAS uptake is growing but it is very much driven by the member states. 
The EC is promoting the wallet the wallet paradigm, to empower users to be in control. 
Two main uses have been identified: diploma  and social security; for them there will be funding to do large scale pilots (that is with at least 5 member states).

The diploma use-case has been on the agenda for some time and the Erasmus+ has provided an additional dimension to that (i.e. microdentials, etc). For this specific use-case there has been significant effort in the past 20 years that produced a production infrastructure. 

There were five calls were open, two of which interesting for the NRENs, one about the EBSI and the other one about eIDAS and wallets; GEANT participate in the EBSI proposal as an associated partner and in the wallet call (Digital Credentials for Europe, DI4EU) has a beneficiary. The proposals were submitted in July; the evaluation results are expected in November. 

Paco noted that tension between the eGov driven and the education driven IDs is less big than in the past; the biggest challenge now is about the aggregation of personal information (the expectation was that eIDAS would solve but that is not the case), so particularly for the diploma’s case the universities will play a bigger role possibly. 

Niels to present after the conclusion of the ION DLT pilot

Niels provided an overview on Microsoft Entra, the new capability that recently entered into production as part of Azure. ENTRA Is a verifiable credential Expert Issuance Issuance and Verifier sample. 
For more info on MS Entra https://www.microsoft.com/en-us/security/business/microsoft-entra

In NL about 80% of the unis uses Azure to connect to SURF federation. Many institutions ask how to integrate verifiable credentials with their federated access.
 
Q: was the ID-token flow tested with OIDC ? 
A: the flow was tested with SURF Conext that has also an OIDC end-point, but SURF Conext only accept https and not URN (which its what OIDC OP uses).

It is worth noting that in this solution the wallet does not communicate directly with the ledger but all the communication goes via Azure - this bears the question if this can still be considered an SSI solution. It’s not clear if one can independently validate transactions against the ION ledger. 

Niels pointed out that two features that would assert studentness. 

It is important to note also that in this implementation there is no selective release of credentials by users - the only way would be to create a new card with less information which is not very desirable. There are no schema in this ecosystem, how the verify know what to request from the issuer? Microsoft built a service where for any given issuer, the verifier can see what credentials they support. The issuer cannot bind a set of credentials to a verifier. 

 Lastly both the issuers and the verifier must have an azure instance.