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

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>*