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

This is why I suggested we give a name to the triplet of Requester
Credentials, Request Scope, and Request Purpose.

- Adrian

On Tue, May 5, 2020 at 2:30 PM Liam McCarty <liam@unumid.org> wrote:

> 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>
> 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
>> - HL Aries:
>> 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
>> - Digital Bazaar: https://digitalbazaar.github.io/vp-request-spec/
>> - CHAPI: 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 spec,
>>> are as aligned as possible.
>>>
>>> OS
>>>
>>>
>>>
>>> On Mon, May 4, 2020 at 5:25 PM Dmitri Zagidulin <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/
>>>>
>>>> *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>*
>
>
>