Re: OpenID Connect extension to support verifiable credential issuance

This is awesome work.

In particular it highlights how W3C Verifiable Credentials can be
transported over OIDC, whether they be LD Proofs, JWT or Indy Credentials...

The one question I always have with OIDC integrations is:

Does this modify the OP Server, and can this be used with Okta and Auth0
with minimal configuration?

OS

On Tue, Jun 16, 2020 at 9:06 PM Tobias Looker <tobias.looker@mattr.global>
wrote:

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

-- 
*ORIE STEELE*
Chief Technical Officer
www.transmute.industries

<https://www.transmute.industries>