Awesome-Mirrors/decentralized-id.github.io
1
0
Fork 0
mirror of https://github.com/Decentralized-ID/decentralized-id.github.io.git synced 2024-10-01 01:05:54 -04:00
Code Issues Packages Projects Releases Wiki Activity
0c45becd18
decentralized-id.github.io/identosphere-dump/open-standards/exchange-protocol/exchange-protocols.md
⧉ infominer 0c45becd18 move for easier to think this way
2022-12-12 06:09:55 -05:00

14 KiB
Raw Blame History

published
false

Credential Exchange

This document describes a mechanism to transfer digital credentials securely between two devices. Secure credentials may represent a digital key to a hotel room, a digital key to a door lock in a house or a digital key to a car. Devices that share credentials may belong to the same or two different platforms (e.g. iOS and Android). Secure transfer may include one or more write and read operations. Credential transfer needs to be performed securely due to the sensitive nature of the information.

  • Figuring out Verifiable Credentials Exchange - combining Bloom, Aires Protocols, Presentation Exchange into a unified - Killer Whale Jello Salad by Kaliya Young, Orie Steele, Drummond , Kyle et al [ presentation]

    • Because what we need is interoperable - issuance - issue-> holder || holder -> verifier some conversation about SIOP - has not been the focus of the discussion.
    • Goal to create a bridge between
    • the W3C CCG / DHS SVIP - VCI-HTTP-API (VHA) in combination with CHAPI protocol and the (VC Request) for issuing credentials.
    • Aries protocols run on top of DIDComm
    • If we agree on a credential format we can exchange across those universes - JSON-LD ZKP BBS+ then we need a protocol to do it - can go between.
    • Orie proposed - that we rather then extend VHA - that the we take a streamlined path with DIDComm as envelop layer - present proof - presentation exchange as a payload including the DIF work presentation, Aries and hopefully alternative to expanding VHA - for holder interactions - since it doesn’t have a holder interactions leverage existing
    • So can be tested with next SVIP - testing.
    • Presentation Exchange and use of DIDComm and for sake of interop testing pave a narrow path - and expand in future interoperability efforts.
    • Summary: DIDComm, Presentation request, presentation exchange, present proof format using JSON-LD ZKP with BBS+
    • Potentially quickly spinning up a working group at DIF - Decision was to nest within the Credentials and Claims group at DIF Result: https://identity.foundation/arewewaciyet/

  • BBS+ Credential Exchange in Hyperledger Aries [presentation]

  • Credentials Exchange - figuring it out - (Jello Bowl Death Match?) [Slides] DIDComm, Verifiable Credential Exchange, Aries Protocol, Bloom Protocol, Presentation Exchange

The ultimate goal is to get to a clear exchange protocols.

Also to have a paper similar to this one that outlines the choice landscape that is and points to a convergence point - https://www.lfph.io/wp-content/uploads/2021/02/Verifiable-Credentials-Flavors-Explained.pdf

Good Health Pass is literally right now trying to figure this out and will “pick” solutions it needs to get implementations working in the next 30-90 days and point the whole industry in one direction.

We started out with this framework of understanding

Contextualizing VC Exchange in Layers

Verifiable Credentials (VC or VCs) is one of the key standardized components of decentralized identity. The VCs Data Model, defined at the W3C, is a universal data format that lets any entity express anything about another entity.  It provides a common mechanism for the interoperable implementation of digital credentials that are cryptographically secure, tamper-evident, privacy-respecting, and machine-verifiable.

There clarity emerging on standards that are interoperable with one another for the VC format.

There is less clarity on the Exchange mechanisms.

One way that has been proposed to look at the exchange options available is to see them in different layers.

CHAPI

TL;DR: chapi.io is a site that helps developers integrate Verifiable Credential issuance, holding, and presentation into their applications. It includes a playground that can issue arbitrary VCs to digital wallets (web and native). It also includes tutorials on how Web Developers can add CHAPI integration to their websites. All you need to try it out is a web browser.

The Credential Handler API or CHAPI is currently a draft community group report developed by/under the Credentials Community Group at the W3C. At the heart of this model is a credential repository which is a Web application that can handle credential requests and credential storage on behalf of the user/holder.  The API Is designed to support the transmission of credentials between a web based issuer and a holder with a cloud wallet (credential repository) that is visible in the same browser but in a different tab.  It creates a “dumb pipe” between the two tabs in the holder’s browser and permits the transmition of the credential effectively from one tab to another.

TL;DR: chapi.io is a site that helps developers integrate Verifiable Credential issuance, holding, and presentation into their applications. It includes a playground that can issue arbitrary VCs to digital wallets (web and native). It also includes tutorials on how Web Developers can add CHAPI integration to their websites. All you need to try it out is a web browser.

This video demonstrates the TrustBloc platform to Issue a W3C Verifiable Credential through CHAPI and Share the Verifiable Credential/Presentation through WACI.

CHAPI

https://www.notion.soimages/image7.png

TL;DR: chapi.io is a site that helps developers integrate Verifiable Credential issuance, holding, and presentation into their applications. It includes a playground that can issue arbitrary VCs to digital wallets (web and native). It also includes tutorials on how Web Developers can add CHAPI integration to their websites. All you need to try it out is a web browser.

The credential selector is an icon-based selector for all the credentials that the chapi.io playground currently supports issuing. You can now click on an image of the credential you'd like to issue.

  • [...]

We have added a permanent resident card from the fictitious Government of Utopia to the list of credentials that can be issued. This credential uses the Citizenship Vocabulary[...]

TL;DR: In an attempt to support the current Jobs for the Future Plugfest, an Open Badge v3.0 example for an Academic Achievement has been added to the chapi.io playground. You can now see what a JFF badge issuance and transfer to a Holder wallet looks like in CHAPI (on mobile and web, on any device that can run a web browser). Images of the flow are attached.

VC-HTTP-API  (VHA)

The VC HTTP is a RESTful API specification (conforming with the OpenAPI 3.0 Specification for constructing and verifying objects which conform to the Verifiable Credential Data Model specification.

A bit more about the OpenAPI 3.0 specification itself:

The OpenAPI Specification (OAS) defines a standard, language-agnostic interface to RESTful APIs which allows both humans and computers to discover and understand the capabilities of the service without access to source code, documentation, or through network traffic inspection. When properly defined, a consumer can understand and interact with the remote service with a minimal amount of implementation logic.

This API is versioned in conformance with the Semantic Versioning 2.0 specification to prevent breaking changes between minor versions, and to allow for reliable testing and integration of implementations of this API within enterprise environments. This API provides a standard set of interfaces by which interoperability may be tested and verified by various parties who leverage Verifiable Credentials (VCs).

This slide, from a slide deck presentation by Manu Sporny to the W3C Credentials Community Group on 20 April 2021, explains the relationship of the VC-HTTP-API to CHAPI:

WACI

There are interactions between a wallet and relying party that require passing information between the two. WACI provides a standard for these interactions.

WACI bound to JWT - signed. Could be JWE technically (would have to know the other parties DID and Keys - only optionally required here).

Fully supports credential manifest and presentation exchange.

Could be bound to DIDComm

Orie linked this related github issue and discussion:https://github.com/w3c-ccg/universal-wallet-interop-spec/issues/84 Also related: https://w3c-ccg.github.io/vp-request-spec/#format

Use cases support mobile wallets, backend services and web apps. Supports chaining of requests…. Relies on credential manifest and presentation exchange

W3C CCG work seems focussed on the “vc-http-api” and “vp-request-spec” as the solutions to this problem… We reviewed IoT / Web / API considerations for presentation exchange. We notes the following hypothetically viable non interoperable solutions to this problem:

  1. DIDComm v1 (IIW ticket flows?)

  2. vp-request-spec + CHAPI

  3. vc-http-api + …. ? / w3c ccg traceability API.

  4. OIDF vp-token spec?

Message Format

Presentation Exchange defined in DIF

Presentation Exchange is a protocol to support the interaction between holders and verifiers. It supports them being able to express what combination of credential the verifier wants or needs.

Credential Manifest as defined in DIF

Asking for a presentation

And asking proof to enable issuing a credential.

Indy Proof Request

Aries Exchange Protocol

Define the messages that go back and forth between

Issuer and holder (4 messages)

Holder and Verifier (3 messages)

Different formats (types of credentials) are different attachments in those messages.

DIDComm v1, there is AIP v1 and AIP v2 :)

Where does it go?

Assorted

Timeline:

  • When is the next Claims and Credentials Group? (who are the chairs? - Martin, Wayne, Daniel McGrogan ) Bi-Weekly -
  • Work Items within DIF WG can have their own dedicated Calls.
  • Join DIF: https://identity.foundation/join/
  • Stewardship - , Orie, Brent, Snorre, Stephen? Troy
  • DIDComm Expert - Sam, Stephen
  • Presentation Exchange Expert -
  • Register for the first meeting:(26th April, Monday 1pm ET) https://forms.gle/SqkymupnYc9tDARm9

We discussedhttps://github.com/w3c-ccg/vc-http-apiAddress concerns with VC-HTTP-API #190