Re: [PROPOSED WORK ITEM] VP Request Specification (for CHAPI etc)

I’d like to suggest that this be a verifiable Verifiable Presentation request. In other words, a holder that receives a request should be able to verify that it comes from a particular verifier. (Maybe this has already been suggested?)

This is where the VC spec language becomes absurdly cumbersome! Since “Verifiable VP Request” is quite a mouthful, I think we’d be better off with “Verifiable Request” or VR for short.

We’ve found this sort of thing completely necessary for our own work, and we’ve been developing a Verifiable Request format internally. Happy to help contribute to this as we go.

Liam McCarty
Co-Founder of Unum ID <http://www.unumid.org/>

> On May 5, 2020, at 8:48 AM, Stephen Curran <swcurran@cloudcompass.ca> wrote:
> 
> Oliver, on your list I would suggest that there are two "doesn't belong" elements and one missing.
> 
> As we learned last week at IIW, CHAPI has nothing to do with Credential Exchange other than as a transport for moving data between browser sandboxes. That's way too low level for Presentation Requests.
> 
> HL Aries "Present Proof" protocol is agnostic to the presentation request, presentation format, and is a protocol designed to enable the generalized request for and delivery of presentations. Likewise it is too low level for the presentation request format.
> 
> Missing is HL Indy, where Proof Requests have been used for several years and in many, many use cases, including production interoperable use cases.  I strongly suggest that the Indy implementation be considered in this work - at least as a checklist to make sure that the format defined is sufficient based on implemented use cases. It was a "code first" approach that includes both presentation request and credential storage querying ("Wallet Query Language") for finding credentials matching the requirements of the proof request.  We've not spent a lot of time on this issue because it's always "just been there" and works very well.
> 
> I find both specs jump straight into a (possibly incomplete?) example without a statement of what features the format needs to be able to support. I think that dissecting the Indy implementation a bit and getting an inventory of features would be useful.
> 
> On Tue, May 5, 2020 at 2:48 AM Oliver Terbu <oliver.terbu@consensys.net <mailto:oliver.terbu@consensys.net>> wrote:
> As pointed out during IIW, I currently see countless different attempts to normalize this, e.g., HL Aries, DIF, Digital Bazaar, ConsenSys/uPort, CHAPI + many more. I'm not opposed as long as we can reconcile and as long the concepts are not fundamentally different.
> 
> - DIF: https://github.com/decentralized-identity/presentation-exchange <https://github.com/decentralized-identity/presentation-exchange>
> - HL Aries: https://github.com/hyperledger/aries-rfcs/blob/master/features/0037-present-proof/README.md <https://github.com/hyperledger/aries-rfcs/blob/master/features/0037-present-proof/README.md>
> - uPort/ConsenSys: https://github.com/uport-project/daf/tree/master/packages/daf-selective-disclosure <https://github.com/uport-project/daf/tree/master/packages/daf-selective-disclosure>
> - Digital Bazaar: https://digitalbazaar.github.io/vp-request-spec/ <https://digitalbazaar.github.io/vp-request-spec/>
> - CHAPI: https://w3c-ccg.github.io/credential-handler-api/ <https://w3c-ccg.github.io/credential-handler-api/>
> 
> Oliver
> 
> On Tue, May 5, 2020 at 12:39 AM Orie Steele <orie@transmute.industries> wrote:
> I'd like to support this work, we've recently spent a bunch of time using this stuff, and I am eager to ensure that this like the ongoing https://github.com/decentralized-identity/presentation-exchange <https://github.com/decentralized-identity/presentation-exchange> spec, are as aligned as possible. 
> 
> OS
> 
> 
> 
> On Mon, May 4, 2020 at 5:25 PM Dmitri Zagidulin <dzagidulin@gmail.com <mailto:dzagidulin@gmail.com>> wrote:
> New Work Item Proposal
> 
> This data model specification describes a declarative JSON-based query language used by applications to perform requests for Verifiable Presentations to wallets and agents.
> 
> The Credential Handler API <https://w3c-ccg.github.io/credential-handler-api/> (CHAPI) spec is an existing Work Item of this community group, and has seen increased implementation and discussion activity recently (for example, the CHAPI and DIDComm overview presentations given at last week's IIW conference resulted in a lot of great questions and expression of interest). And if the CHAPI spec describes a protocol, a simple communication pipe over which apps can communicate with wallets through a web browser, then the VP Request Spec work item proposed in this email, is a data model complement to it.
> 
> Is the CHAPI protocol bound to the VP Request Spec data model? No, you can use CHAPI to pass on other types of messages and requests.
> 
> Is the VP Request Spec limited only to CHAPI? No, you can use this declarative query syntax with other protocols, such as by wrapping it in DIDComm messages, or by serializing it into URLs, for use with inter-app communication within mobile operating systems.
> 
> What is the relationship between the VP Request format and query formats used by DIDComm? That is partly what we hope to explore and come to consensus on in this proposed work item! In general, we believe that these formats can be complementary and inter-operable.
> 
> Include Link to Abstract or Draft
> 
> https://digitalbazaar.github.io/vp-request-spec/ <https://digitalbazaar.github.io/vp-request-spec/>
> 
> Owners
> 
> Dave Longley
> Mike Varley
> Dmitri Zagidulin
> 
> 
> -- 
> ORIE STEELE
> Chief Technical Officer
> www.transmute.industries
> 
>  <https://www.transmute.industries/>
> 
> 
> -- 
> Stephen Curran
> Principal, Cloud Compass Computing, Inc. (C3I)
> Technical Governance Board Member - Sovrin Foundation (sovrin.org) <>
> Schedule a Meeting: https://calendly.com/swcurran <https://calendly.com/swcurran>