Report on ISO mDL meeting

Hi All

Today I am travelling home from the ISO SC 17 WG10 (mobile driving 
licenses) meeting. The meeting was more productive than I had 
anticipated before joining it, given the cold response to including VCs 
in the first version of the mDL standard, and that VCs were the last 
item on the agenda at the start of the meeting. (This subsequently 
changed and VCs were discussed half way through the meeting.)

Specifically, the French and UK had contributions on how to include VCs 
in mDL, whilst MS (Tony) had a contribution on why not to include VCs 
and to use OIDC instead.

What became clear to me as the meeting progressed, is that mDL has a lot 
of protocols for transferring mDLs, and they have put a lot of time and 
effort into these, so we should be able to benefit from these for the 
transfer of VCs (since we have no standard protocols of our own.)

It also became clear at the meeting that most people do not like 
standard OIDC for transfer because of its privacy implications, in that 
it requires the issuer to communicate directly with the verifier. 
However, if we include a self issuing OIDC server in with the 
holder/client software, and load this with VCs directly from the issuer, 
then the RP can use the standard OIDC protocol to retrieve the mDL 
without communicating with the issuer. This would seem to be a win-win 
situation, since VCs do not have any standardised transport protocols, 
and OIDC is used by several popular large organisations. So if we can 
leverage the OIDC protocol to carry VCs from the holder to the verifier 
this would ease the pain of verifiers in adopting VCs.

Tony is not averse to this solution providing we can remove one sticking 
point from the standard, namely the mandatory requirement to convert 
JWTs into VCs on receipt. I actually agree with Tony on this point, as 
it is not required. Kent's JWT implementation of VCs never actually 
creates a pure VC in either the issuer, holder or verifier. Rather it 
creates a conformant JWT signed VC, the holder (and verifier) validate 
the JWS signature and the vc claim contents, without needing to convert 
the various other JWT fields (times and issuer) into VC properties. The 
holder then ships out the JWT (embedded in a JWT presentation) to the 
verifier. So you could say Kent's implementation is non-conformant 
according to the strict wording of the standard. However it should be 
able to interwork perfectly well with other JWT signing VC 
implementations. Consequently I think this is something we should 
revisit once the maintenance WG is up and running, with a view to 
removing this mandatory requirement.

Other good points to note. The mDL group had a clear use case for VC 
based mDLs, and a task force has been established to flesh out the use 
of VCs in mDL in more depth and to indicate the costs and benefits of 
introducing VCs into the mDL standard.

Given that the VC maintenance working group has a mandate to liaise with 
the mDL working group, then if you would like, I can ask if members of 
the VC WG can join this task force to help flesh out the integration. 
Members of the task force currently include myself, Tony and the French 
contingent (amongst others).

So to summarise, a very positive meeting. Many (though not all) of the 
delegates see positive advantages in having a standard profile of VCs 
for mDL, and if we can work with MS and the task force to put VCs into 
the OIDC protocol as well, then that would be another positive outcome 
from the joint work.

If you have any further questions, dont hesitate to ask

Kind regards

David

Received on Thursday, 12 December 2019 02:34:51 UTC