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
>
>
>
> 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>
> 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: 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.
>