Re: OpenID Connect extension to support verifiable credential issuance

Hi Mike, appreciate the feedback.

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

We felt the notion of a bound end-user assertion ("credential") was
sufficiently different from say the "id_token" that it warranted its own
top level response element. For example the way we have defined a
credential is an end-user assertion that features a binding mechanism,
whereas an "id_token" is a simple bearer based end-user assertion. We also
wanted to create an extensibility point here in requesting the format of
the resulting assertion, so that we can support both JSON-LD linked data
proof based assertions and JWT.

In essence we have just continued the mode of extensibility that OpenID
used when adding identity to OAuth.

Would your alternative be
1 To nest this information in the id_token, if so, would it be a nested
assertion i.e JWT / linked data proof inside the id_token?
2 Simply just have the claims, like in the identity assurance work?

Happy to explore 1 but if it is 2 this potentially removes the ability to
have richer assertion formats such as those based on JSON-LD.

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

Our claims syntax is based on
https://openid.net/specs/openid-connect-core-1_0.html#ClaimsParameter, but
instead we defined a new top level member "credential" because of it being
a separate artifact return from the flow rather than nesting the syntax in
the two existing members ("userinfo" and "id_token"), again this is related
to your previous point.

w.r.t SIOP, I do agree there are a set of un-answered questions around this
at present, however I think the syntax defined in OpenID Connect core
around SIOP will need to be extended in any case, for example your
(Microsoft's) recently released VerifiableCredentials SDK has extended this
syntax in a similar manner to what we are suggesting. The below is a
snippet from a SIOP request from your SDK.

[image: Screen Shot 2020-06-18 at 9.58.09 AM.png]

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

Yes, you do still need to use the "claims" request parameter, but this is
not the primary intent of the scope, the scope is intended to communicate
that the client is requesting a "bound end-user assertion", i.e the client
would like some claims about the end-user that are rendered in an assertion
featuring some binding mechanism (like a public key) for which the client
can then authenticate using the private key to produce a signature on
presentation of that assertion to other relying parties later. This scope
is also used to communicate that there is a further response element
expected from
the product of the flow. I'm happy to explore an alternative means of
communicating this intent in the request, but fundamentally an OpenID
provider must be able to disambiguate between a request from a client for
claims about the end user vs a request for claims about the end user that
will be rendered in a bound assertion, because that latter has impacts on
many things such as obtaining user consent.

As a quick note in regards to the identity assurance work (
https://openid.net/specs/openid-connect-4-identity-assurance-1_0-10.html#name-requesting-verified-claims),
I believe the spec we have written does have some overlap but also quite a
different core intent. Correct me if I am wrong, but the identity assurance
effort is attempting to describe how you request and receive claims from an
OpenID flow (for a particular business process e.g KYC) that have a greater
set of assurances than standard OpenID claims. Whereas our spec is more
focused on returning a different type of assertion e.g one that has the
potential to be richer in nature and features a binding to the client so
that the client is then able to present it to another relying party and it
be properly authenticated.

Thanks,
[image: Mattr website] <https://mattr.global>
*Tobias Looker*
Mattr
+64 (0) 27 378 0461
tobias.looker@mattr.global
[image: Mattr website] <https://mattr.global> [image: Mattr on LinkedIn]
<https://www.linkedin.com/company/mattrglobal> [image: Mattr on Twitter]
<https://twitter.com/mattrglobal> [image: 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.


On Thu, Jun 18, 2020 at 5:46 AM Mike Jones <Michael.Jones@microsoft.com>
wrote:

> 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
>
>
>
>
>
>
>
>
>
> *From:* Tobias Looker <tobias.looker@mattr.global>
> *Sent:* Tuesday, June 16, 2020 10:00 PM
> *To:* Credentials Community Group <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: Image removed by sender. Mattr website] <https://mattr.global/>
>
>
>
> *Tobias Looker*
>
> Mattr
>
> +64 (0) 27 378 0461
> tobias.looker@mattr.global
>
> [image: Image removed by sender. Mattr website] <https://mattr.global/>
>
> [image: Image removed by sender. Mattr on LinkedIn]
> <https://www.linkedin.com/company/mattrglobal>
>
> [image: Image removed by sender. Mattr on Twitter]
> <https://twitter.com/mattrglobal>
>
> [image: 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.
>
>

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