[Openid-specs-ab] Issue #1268: Issues in the comment PR 34 by Torsten (openid/connect)

Nat issues-reply at bitbucket.org
Wed Jul 14 17:18:38 UTC 2021

New issue 1268: Issues in the comment PR 34 by Torsten

Nat Sakimura:

Section 2.2

* I miss a parameter to determine the credential type. This is important to allow OPs to support multiple credentials, e.g. a bank could issue identity and credit score credentials, without to need to setup different issuers.
* "Public private key pairs are used by a requesting Credential Holder to establish a means of binding to the resulting credential. A Credential Holder making a Credential Request to a Credential Issuer must prove control over this binding mechanism during the request, this is accomplished through the extended usage of a signed request defined in OpenID Connect Core.“ Does this mean the holder can prove control using a signed authentication request? If so, why isn’t the credential provided in the token response? 

Credential Endpoint Request

* I assume the objective of the signed object in the credential endpoint request is proof of possession of a private key linked to the DID for which the credential shall be provided \(basically holder binding\). To me this seems to be less of a OIDC signed request object than a SIOP/portable identifier assertion/id token. The purpose of the OIDC signed request object is to authenticate the client, which does not happen in this case. It’s instead an assertion signed by the holder \(sub?\), so why is the iss containing an identifier of the wallet? Where is this data used?
* "The Credential Holder may provide a signed request object …“ sounds optional. What happens if no signed request object is provided?

Section 5.1. 

Sounds like the spec support other identifiers than DIDs. What are the supported alternatives? 

Why do you use a „did" claim to convey the holder’s identifier instead of „iss“/„sub" claims?

What purpose servers the „redirect\_uri“ claim in this use case? The credential request is a direct HTTPS request w/o redirects. 

Section 6.1. 

Reads like a discovery protocol for SIOPish deployments. How is this related to this spec? I’m asking since I would assume credential issuers will typically be cloud based and thus can use standard OIDC Discovery. 

General questions/thoughts:

* It seems the OP is required to issue an access token good to obtain credentials bound to arbitrary DIDs. This means that this access token is a very powerful credential. I think bearer tokens are not suitable in this case and recommend to make sender constrained access tokens \(using mTLS or DPoP\) mandatory. 
* I also don’t understand how consent works in case the client can obtain \(different\) credentials over some timespan. Do you expect the user to consent to this upfront in the single authorisation flow or do you assume the user is called back from the credential endpoint? 
* Alternatively, the credential could be issued in the token response. That would allow to make it a one time exercise with a less risky security characteristics and always get the holder’s consent. 
* I think it would be attractive to combine this draft with CIBA. I could imagine to setup the „connection“ with the wallet using a standard OIDC redirect flow and, for sub-sequent credentials, the wallet could use CIBA to obtain additional credentials, using the „sub" from the first transaction as holder identifier towards the OP. 
* What do you think about adopting the same representation for credentials as \(whatever we decide to use with\) the OIDC 4 W3C Verifiable Credential Objects spec? If so, we could align the two drafts and focus OIDC 4 W3C Verifiable Credential Objects onto VPs or merge both specs. This would potentially allow wallet providers to use the same protocol to provide VPs and \(bearer\) VCs.

More information about the Openid-specs-ab mailing list