W3C home > Mailing lists > Public > public-credentials@w3.org > June 2020

OpenID Connect extension to support verifiable credential issuance

From: Tobias Looker <tobias.looker@mattr.global>
Date: Wed, 17 Jun 2020 14:00:14 +1200
Message-ID: <CAJmmfSQ1Un1PPLF_d9mG7S1=SsLTHXUQu1JZHA9o8mggX_ftEA@mail.gmail.com>
To: Credentials Community Group <public-credentials@w3.org>
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.
Received on Wednesday, 17 June 2020 02:03:48 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 17 June 2020 02:03:51 UTC