RE: OpenID Connect extension to support verifiable credential issuance

Hi Anil,

Thanks for bringing this to my attention.  The standards team at Microsoft is in a conversation about this with Tobias.  (Unfortunately, I had a conflict for our initial call but I expect there to be another one.)  We agree that something like this is important.

Having looked the proposal, I have a few technical questions, which I’ll cover Tobias.  Among them are:

  *   Why return a new “credential” member from the Token Endpoint instead of returning the credential (or credentials) as claim(s)?  This is particular important for SIOP, where there is no Token Endpoint.
  *   It would be ideal to unify the claims request syntax with that in https://openid.net/specs/openid-connect-4-identity-assurance-1_0-10.html#name-requesting-verified-claims (which like this one, is based on https://openid.net/specs/openid-connect-core-1_0.html#ClaimsParameter).
  *   Using a scope value doesn’t seem necessary or adequate, since it doesn’t tell you anything about the credential claims wanted.  You still need to do that in the “claims” request parameter.

As the high order bit, I hope we can come up with a common verified claims request syntax for OpenID Connect, including one that works for claims representing Verified Credentials.

                                                       Best wishes,
                                                       -- Mike

From: John, Anil <anil.john@hq.dhs.gov>
Sent: Wednesday, June 17, 2020 6:37 AM
To: Credentials Community Group <public-credentials@w3.org>
Cc: Mike Jones <Michael.Jones@microsoft.com>; openid@justin.richer.org
Subject: [EXTERNAL] RE: OpenID Connect extension to support verifiable credential issuance

Tobias,

This is really interesting.
Very much looking forward to hearing the perspectives and feedback on this from folks with deep OIDC expertise/history such as Mike Jones, Justin Richer and others.

Best Regards,

Anil

Anil John
Technical Director, Silicon Valley Innovation Program
Science and Technology Directorate
US Department of Homeland Security
Washington, DC, USA

Email Response Time – 24 Hours

[cid:image001.png@01D64493.41D074B0]



From: Tobias Looker <tobias.looker@mattr.global<mailto:tobias.looker@mattr.global>>
Sent: Tuesday, June 16, 2020 10:00 PM
To: Credentials Community Group <public-credentials@w3.org<mailto:public-credentials@w3.org>>
Subject: OpenID Connect extension to support verifiable credential issuance

CAUTION: This email originated from outside of DHS. DO NOT click links or open attachments unless you recognize and/or trust the sender. Contact your component SOC with questions or concerns.

Hi All,

Recently we drafted a specification of how an OpenID Connect (OIDC) flow can be extended to support the issuance of Verifiable Credentials, the draft to the spec is linked below

https://mattrglobal.github.io/oidc-client-bound-assertions-spec/


Note - much of the language in this spec is born from the OIDC realm rather than from terminology used by the CCG around verifiable credentials, so some aspects of the specification are potentially less obvious to those otherwise un-familiar with OIDC.

Essentially the high level goal of the flow is to extend an ordinary OIDC request such that it is a request for a verifiable credential, in this request a few things occur.

1.. The client (digital wallet) requests a credential be issued featuring the defined claims
2. The client (digital wallet) provides a binding mechanism that the verifiable credential will be bound to (e.g a public key or a DID)
3. The client proves control of this binding mechanism in the request by signing the request.

On successful submission of this request the user is redirected (as per conventional OIDC flows) to a browser page requesting that the user authenticate (if the user is already authenticated then this step is skipped), on success of this step the user is redirected back to the client (digital wallet) with the resulting credential.

Benefits of this flow

- It extends popular, already deployed login infrastructure on the web today so that digital wallets can receive verifiable credentials.
- It handles issuer based user authentication during the flow using standard OIDC.
- The request for the credential and authentication of the binding mechanism that will be used in the resulting credential (e.g DID Auth) is done in a single request.
- It allows for a flow that issues credentials into either a web based wallet or a native app based wallet.

Note - there are still elements of the specification that are a work in progress but we are interested in feedback from the community about the approach taken.

Thanks,
[Image removed by sender. Mattr website]<https://mattr.global/>

Tobias Looker
Mattr
+64 (0) 27 378 0461
tobias.looker@mattr.global<mailto:tobias.looker@mattr.global>
[Image removed by sender. Mattr website]<https://mattr.global/>
[Image removed by sender. Mattr on LinkedIn]<https://www.linkedin.com/company/mattrglobal>
[Image removed by sender. Mattr on Twitter]<https://twitter.com/mattrglobal>
[Image removed by sender. Mattr on Github]<https://github.com/mattrglobal>

This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002.


This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002.