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

To enable a data subject (holder) to make a decision on the presentation of
private information, the query bundles three sorts of components:
- the credentials of the requesting party
- the scope of information requested
- the purpose for the request

Is this triplet a general concept that we should give a name to?

- Adrian

On Tue, May 5, 2020 at 9:21 AM Daniel Buchner <Daniel.Buchner@microsoft.com>
wrote:

> We have the Presentation Exchange spec work going on now in the DIF Claims
> & Credentials WG that defines the data formats for the Presentation
> Definition (a syntax/logical definition of requirements presented to a
> user) and subsequent Presentation Submission payload sent in relation to
> proof demands an Issuer/Verifier specifies. This could be a good basis for
> some (not all) of the needs. Presentation Exchange is not a
> wire/transport/routing spec, it only seeks to define a VC negotiation
> protocol-agnostic data model for the two-sided objects send to
> demand/respond to Issuer/Verifier requirements.
>
>
>
> *From:* Oliver Terbu <oliver.terbu@consensys.net>
> *Sent:* Tuesday, May 5, 2020 5:47 AM
> *To:* Balázs Némethi <balazs@identity.foundation>; Rouven Heck <
> rouven.heck@consensys.net>; Daniel Buchner <Daniel.Buchner@microsoft.com>
> *Cc:* Orie Steele <orie@transmute.industries>; Dmitri Zagidulin <
> dzagidulin@gmail.com>; Credentials Community Group <
> public-credentials@w3.org>; Mike Varley <mike.varley@securekey.com>
> *Subject:* [EXTERNAL] Re: [PROPOSED WORK ITEM] VP Request Specification
> (for CHAPI etc)
>
>
>
> I agree that the "presentation request" may be integrated in different
> protocols and transports.
>
>
>
> There were a couple of years between SAML and OpenID Connect. SAML already
> had a lot of adoption when OpenID Connect became popular. The DID community
> does not have to deal with such assumptions. We have the chance to agree on
> a common message format including query format. We should at least come
> together and try to agree on that.
>
>
>
> I could imagine a similar approach to what we did with Secure Data Storage
> (SDS) could work. We could have a joint work item between DIF, W3C CCG and
> HL Aries on a "presentation request" spec as it relates to all of us.
>
>
>
> I am curious about other people's thoughts (e.g., @Daniel Buchner
> <Daniel.Buchner@microsoft.com>, @Balázs Némethi
> <balazs@identity.foundation>, @Rouven Heck <rouven.heck@consensys.net>,
> @Manu Sporny, @Sam Curran, @Daniel Hardman).
>
>
>
> Thanks,
>
> Oliver
>
>
>
> On Tue, May 5, 2020 at 2:04 PM Mike Varley <mike.varley@securekey.com>
> wrote:
>
> 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
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmavarley%2Fvc-ql-spec&data=02%7C01%7CDaniel.Buchner%40microsoft.com%7Cae0c7dc0356e4b780d7408d7f0f277cb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637242796499031044&sdata=9vq0ufa4CynwNs73Dx3rmVxvC2pv0Rs5j%2FjnqPkCEiQ%3D&reserved=0>
>
>
>
> 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
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdecentralized-identity%2Fpresentation-exchange&data=02%7C01%7CDaniel.Buchner%40microsoft.com%7Cae0c7dc0356e4b780d7408d7f0f277cb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637242796499041014&sdata=krp8cMvZKH3pzZBH%2BLbk002ZHVO4JW4zvZaRJ9u7T3g%3D&reserved=0>
>
> - HL Aries:
> https://github.com/hyperledger/aries-rfcs/blob/master/features/0037-present-proof/README.md
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fhyperledger%2Faries-rfcs%2Fblob%2Fmaster%2Ffeatures%2F0037-present-proof%2FREADME.md&data=02%7C01%7CDaniel.Buchner%40microsoft.com%7Cae0c7dc0356e4b780d7408d7f0f277cb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637242796499050958&sdata=9SqqUmd0TiqiQvYrhii4xbyrz%2FS6YxA9QAD8NYEZkBQ%3D&reserved=0>
>
> - uPort/ConsenSys:
> https://github.com/uport-project/daf/tree/master/packages/daf-selective-disclosure
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fuport-project%2Fdaf%2Ftree%2Fmaster%2Fpackages%2Fdaf-selective-disclosure&data=02%7C01%7CDaniel.Buchner%40microsoft.com%7Cae0c7dc0356e4b780d7408d7f0f277cb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637242796499050958&sdata=hdy5NcvDghNGUc%2B43Nb3yN3kZGGlOYsALCYZ1lNqT24%3D&reserved=0>
>
> - Digital Bazaar: https://digitalbazaar.github.io/vp-request-spec/
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdigitalbazaar.github.io%2Fvp-request-spec%2F&data=02%7C01%7CDaniel.Buchner%40microsoft.com%7Cae0c7dc0356e4b780d7408d7f0f277cb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637242796499060924&sdata=LjBxvrwVc95IQwHiLf3KJ%2FCYG72miA5IpSbTKp%2BFU4U%3D&reserved=0>
>
> - CHAPI: https://w3c-ccg.github.io/credential-handler-api/
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fw3c-ccg.github.io%2Fcredential-handler-api%2F&data=02%7C01%7CDaniel.Buchner%40microsoft.com%7Cae0c7dc0356e4b780d7408d7f0f277cb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637242796499060924&sdata=c8UqKGEsqNnFLe2OIliPl5m0dlJ4hFOVWOXJ6G5CpZE%3D&reserved=0>
>
>
>
> 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdecentralized-identity%2Fpresentation-exchange&data=02%7C01%7CDaniel.Buchner%40microsoft.com%7Cae0c7dc0356e4b780d7408d7f0f277cb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637242796499070875&sdata=gWTB4xxArDYstEU2uaH6hqlHc4DWHq1RfQ4taRRR1y4%3D&reserved=0> 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fw3c-ccg.github.io%2Fcredential-handler-api%2F&data=02%7C01%7CDaniel.Buchner%40microsoft.com%7Cae0c7dc0356e4b780d7408d7f0f277cb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637242796499070875&sdata=zJ34tnu65rX5BfFOvGKHhUh7goa1Sz%2B4gmQDAvNAYPQ%3D&reserved=0> (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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdigitalbazaar.github.io%2Fvp-request-spec%2F&data=02%7C01%7CDaniel.Buchner%40microsoft.com%7Cae0c7dc0356e4b780d7408d7f0f277cb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637242796499080822&sdata=O%2Bk5sQf%2BBd11rRvF7zyoIur8%2FVzP%2BXemwma8hO3%2BCeE%3D&reserved=0>
>
>
>
> *Owners*
>
>
>
> Dave Longley
>
> Mike Varley
>
> Dmitri Zagidulin
>
>
>
>
> --
>
> *ORIE STEELE*
>
> Chief Technical Officer
>
> www.transmute.industries
>
>
>
>
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.transmute.industries%2F&data=02%7C01%7CDaniel.Buchner%40microsoft.com%7Cae0c7dc0356e4b780d7408d7f0f277cb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637242796499080822&sdata=uHnMXiLXwBy9Pz16s719ZCJuU1KUE55fO2qNfm3aQDo%3D&reserved=0>
>
> 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.
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.transmute.industries%2F&data=02%7C01%7CDaniel.Buchner%40microsoft.com%7Cae0c7dc0356e4b780d7408d7f0f277cb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637242796499080822&sdata=uHnMXiLXwBy9Pz16s719ZCJuU1KUE55fO2qNfm3aQDo%3D&reserved=0>
>
>