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

Hi Oliver;

I agree - I wrote down some of my early thinking on where these protocols overlap and where there could be a basic interoperable profile. The draft-but-now-defunct work is here: https://github.com/mavarley/vc-ql-spec


Some may find the intro part may be useful – there is a common pattern across all these protocols – but unfortunately I think (and based on feedback from some in this community) the intersection point is too abstract _right now_.

Hopefully this CHAPI work can bring in concepts to support DIDComm (RFC0037) and others.

I would also like to point out that although it would be ideal, we don’t need a one-and-only-single-way to request VPs. For example, both SAML and OpenID Connect can be used as federation protocols; and although OpenID Connect is more recent and more flexible, SAML still very much has its place in SSO and federated use cases.

MV

From: Oliver Terbu <oliver.terbu@consensys.net>
Date: Tuesday, May 5, 2020 at 5:48 AM
To: Orie Steele <orie@transmute.industries>
Cc: Dmitri Zagidulin <dzagidulin@gmail.com>, Credentials Community Group <public-credentials@w3.org>
Subject: Re: [PROPOSED WORK ITEM] VP Request Specification (for CHAPI etc)
Resent-From: <public-credentials@w3.org>
Resent-Date: Tuesday, May 5, 2020 at 5:46 AM

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


Owners

Dave Longley
Mike Varley
Dmitri Zagidulin


--
ORIE STEELE
Chief Technical Officer
www.transmute.industries

[Image removed by sender.]<https://www.transmute.industries/>

This email and any attachments are for the sole use of the intended recipients and may be privileged, confidential or otherwise exempt from disclosure under law. Any distribution, printing or other use by anyone other than the intended recipient is prohibited. If you are not an intended recipient, please contact the sender immediately, and permanently delete this email and its attachments.