[Openid-specs-ab] Verifiable presentation question

David Waite david at alkaline-solutions.com
Thu May 13 06:12:58 UTC 2021

> On May 12, 2021, at 9:06 PM, Tom Jones <thomasclinganjones at gmail.com> wrote:
> This needs to be unpacked a little.
> 1. there is no VP spec, there is only a VC spec.
> 2. There is no case where a naked VC should ever go to a verifier - aka relying party.

There are scenarios, as the VC data model use cases are very broad. Presentations are optional within the VC data model. The VC data model says that directly sharing a credential makes it a presentation.

A credential without a verifiable presentation just doesn’t have confirmation. If I found a passport laying in the street that doesn’t make the information less valid. My ability to use the information goes down because I’m not interacting with the person it belongs to.

> I would state that even stronger. Naked creds should NEVER appear in an OpenID protocol.

We likely do not have need to present credentials without confirmation to a verifier - you don’t need any challenge -response, you might as well just host it as a file someplace.

However, there are efforts to define protocol to retrieve claims for aggregation from a claims provider, and VCs from an issuer acting as an OP to a RP acting as a holder. We’ll. Need to define a way to get credentials before we will be able to successfully present them.

> 3. But there is a case where a simple VC can be encapsulated inside a VP, which really subverts the goals of the spec which is to allow the user selective disclosure.

Selective disclosure is not a hard requirement of VCs or VPs. There are systems in production which do not support this.

> 4. Daniel is working on a PE spec(let) that describes how a request to a wallet, with VCs, can be returned as a VP.

Just to be clear since there was earlier confusion, PE does not define a request or response message, nor does it define any protocol.

> 5. There is no concept worked out in CCG of a user having more than one wallet. Which makes the problem of a RP creating a request incomprehensibly difficult, if not impossible.

CHAPI supports multiple wallets simultaneously, but has limitations (such as being web-exclusive and being fragile wrt modern browser state management)


More information about the Openid-specs-ab mailing list