<div dir="auto">Only one minor nit with DW. The PE claims not to be a protocol, but as David c points out, it really is as it shows data used across time.<br><br><div data-smartmail="gmail_signature">thx ..Tom (mobile)</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, May 12, 2021, 11:13 PM David Waite <<a href="mailto:david@alkaline-solutions.com">david@alkaline-solutions.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
> On May 12, 2021, at 9:06 PM, Tom Jones <<a href="mailto:thomasclinganjones@gmail.com" target="_blank" rel="noreferrer">thomasclinganjones@gmail.com</a>> wrote:<br>
> <br>
> This needs to be unpacked a little.<br>
> <br>
> 1. there is no VP spec, there is only a VC spec.<br>
> 2. There is no case where a naked VC should ever go to a verifier - aka relying party.<br>
<br>
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.<br>
<br>
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.<br>
<br>
> I would state that even stronger. Naked creds should NEVER appear in an OpenID protocol.<br>
<br>
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.<br>
<br>
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.<br>
<br>
> 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.<br>
<br>
Selective disclosure is not a hard requirement of VCs or VPs. There are systems in production which do not support this.<br>
<br>
> 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.<br>
<br>
Just to be clear since there was earlier confusion, PE does not define a request or response message, nor does it define any protocol.<br>
<br>
> 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.<br>
<br>
CHAPI supports multiple wallets simultaneously, but has limitations (such as being web-exclusive and being fragile wrt modern browser state management)<br>
<br>
-DW</blockquote></div>