Re: Report on ISO mDL meeting

This is a bit of tangent, but might be helpful wrt to combining the use of
VCs and OIDC, and the handling of VC and JWTs.

Below is a link to instructions for running a simple demo of an Identity
Provider (IdP) for an OIDC IAM (Keycloak in this case, but it should work
with any IAM) that verifies VCs presented by a holder. The IdP is assumed
to be under the control of the RP (e.g. its ability to verify VCs is
trusted by the RP). The IdP receives requests for, and returns, an OIDC
token to the RP. When an OIDC token is needed based on a VC, the IdP
initiates an interaction with a Mobile Agent (using Hyperledger Aries in
this case) to request the presentation of claims from one (or more) VCs.

The demo takes about 5 minutes to run, including installation of an IOS
only (for now...more coming) Hyperledger Aries app from the App Store. Once
installed and configured (don't forget that step - setting up the right
network in the Mobile App), you request/receive a verifiable credential
from one service, and then you use the verifiable credential to get access
to an OIDC-protected service.  Note - this IdP is the work of BC Gov
(Canada, where I am) and MattrGlobal (New Zealand).  The IOS app is from
another, unaffiliated vendor (Streetcred.id), and there are a number of
other vendors building comparable apps. All nice and interoperable!

https://github.com/bcgov/vc-authn-oidc/blob/master/docs/DemoInstructions.md


There is a link to some slides at the end of the instructions with more
details on the implementation, and an open source repo that you can use to
deploy your own instance of the solution. We'd love to get feedback from
others that try this out with other IAMs (gluu, Forge Rock, etc.).

Enjoy!

On Wed, Dec 11, 2019 at 6:36 PM David Chadwick <D.W.Chadwick@kent.ac.uk>
wrote:

> 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
>
>
>
>
>

-- 

Stephen Curran
Principal, Cloud Compass Computing, Inc. (C3I)
Technical Governance Board Member - Sovrin Foundation (sovrin.org)

*Schedule a Meeting: **https://calendly.com/swcurran
<https://calendly.com/swcurran>*