or
or
By clicking below, you agree to our terms of service.
New to HackMD? Sign up
Syntax | Example | Reference | |
---|---|---|---|
# Header | Header | 基本排版 | |
- Unordered List |
|
||
1. Ordered List |
|
||
- [ ] Todo List |
|
||
> Blockquote | Blockquote |
||
**Bold font** | Bold font | ||
*Italics font* | Italics font | ||
~~Strikethrough~~ | |||
19^th^ | 19th | ||
H~2~O | H2O | ||
++Inserted text++ | Inserted text | ||
==Marked text== | Marked text | ||
[link text](https:// "title") | Link | ||
 | Image | ||
`Code` | Code |
在筆記中貼入程式碼 | |
```javascript var i = 0; ``` |
|
||
:smile: | ![]() |
Emoji list | |
{%youtube youtube_id %} | Externals | ||
$L^aT_eX$ | LaTeX | ||
:::info This is a alert area. ::: |
This is a alert area. |
On a scale of 0-10, how likely is it that you would recommend HackMD to your friends, family or business associates?
Please give us some advice and help us improve HackMD.
Syncing
xxxxxxxxxx
Credentials / Claims Exchange message formats
Table of Contents
Table of contents generated with markdown-toc
About this document/approach
Previously, the DIF Claims/Credentials Working Group proposed a general Credentials Exchange Manifest; however, before going too far along that path, we wanted to better understand existing approaches. That will help ensure our format is sufficiently expressive and flexible, and meet our goals of promoting interop.
This document is simply an effort to gather "what's out there" so we can categorize and generalize.
Currently, efforts like DID auth are having to focus on message formats in addition to protocols – even message formats dealing with claims exchange (see uPort selective disclosure/DID auth). We'd also like to identify when this is happening so we can iterats on them in the Claims/Credentials group.
Because of that, we'll be reviewing existing claims exchange protocols/formats that member companies have documented, including where they appear as part of protocols like DID Auth. References are at the end.
Categories
Based on review so far, it looks like we need interoperable message formats for Claims manifests/Claims (request/response) associated with:
Expressiveness/Features
Still deciding scope for initial interop POC, but eventually design should accommodate all.
Initial list:
Design Questions
Filters/Constraints
There will be a need for claims filters (by type, fields, etc), as shown in a couple of examples below, but we should be careful to not re-invent the wheel and create something restrictive.
We could consider something LISP S-expressions.
A JSON library attempting something similar is JSONLogic
Note Jolocom appears to use a similar style. DIF's previously-published Claim Metadata format looked home-grown…
Should we consider Verifiable Credential Exchange a special case of data exchange?
Identity hub examples are included below, because there is a fuzzy area between requesting unverified claim data and other user data.
A possible approach is for claims exchange to be a special case of data exchange.
Vocabulary
How do we let a requestor specify desired vocabulary/types? Current approaches seem ambiguous/confusing.
I think it is just a special case of Filters/Constraints
Category 1 examples
Note that responses take the form of Verifiable Credentials/Presentations, but examples are included to the demonstrate different wrappers/envelopes
uPort Verifiable Credential Request/Response
Format: JWT
Details: https://github.com/uport-project/specs/blob/develop/messages/verificationreq.md
About: The issuer is requesting the holder's wallet/agent to present a signed claim containing exactly the field
name
and respond with a payload like the followingExample request:
Example response:
Observations:
iss
,iat
,exp
are shared with Share Request, and should be fairly standard across JWTsuPort Selective Disclosure Request/Response (used in DID Auth)
Note: I would argue any claims-based aspects of DID auth belong with Claims/Credentials effort
Format: JWT
Details:
Response example:
Observations:
claims
as requested claims vsunsignedClaim
in previous example. Also they should allow similar options, like filtering by issueressential
– is a boolean ok, or do we need multi-valued. If booleam rename to required? what should default be?callback
not shown here but available as optional field, like previous exampleJolocom Credential Request/Response
Format: JWT
Reference: https://jolocom-lib.readthedocs.io/en/latest/interactionFlows.html
Example request:
Example response:
Observations:
type
appears to be requested type; that's a little confusing.Credential Handler API
Format: JSON-LD
Details: https://w3c-ccg.github.io/credential-handler-api/
Credential Storage (Registration) and Request. Uses notion of credential "hints"
About/Scope: imperative API enabling a website to request a user’s credentials from a user agent, and to help the user agent correctly store user credentials for future use. User agents implementing that API prompt the user to select a way to handle a credential request, after which the user agent returns a credential to the originating site. This specification defines capabilities that enable third-party Web applications to handle credential requests and storage.
ID Hub Search and Read Requests
If you squint enough, VC exchange requests look like a special case of data exchange requests that occur, e.g. in Identity Hub operations
Identity Hub has 2 relevant requests (search and read). Consider whether there are opportunities to unify/align these requests and how these can be shared with credential exchange.
Query Request/Response
Read Request/Response
TODO: See also Profiles, and more in ID Hub docs
ID Hub Write (Store) Request/Response (TODO: Categorize)
Sidetree VCs (TODO: categorize)
Details: https://hackmd.io/tx8Z0mIRS-aK84Gx4xIzfg?view
HIPE (TODO: categorize)
https://github.com/hyperledger/indy-hipe/blob/c761c583b1e01c1e9d3ceda2b03b35336fdc8cc1/text/anoncreds-protocol/README.md
Civic
Civic utilized draft specifications of DIDs and Verifiable Credentials in their product pipeline. Civic Technologies makes the open-source components of their implementation accessible to interested parties with an MIT License via identity.com. Generally the following Libraries exists:
Credential Commons
URL: https://github.com/identity-com/credential-commons
This Javascript Library provides functionality around Verifiable Credentials (VC), a W3C standard. Enables Validators to issue, Credential Wallets to verify, filter and Requesters to verify credentials.
Civic does not provide a Proof implementation for the issued Verifiable Credentials, but abstracts that via an interface implementation. E.g. interested parties are able to use Credential-Commons and provide their own implementation around JWT token proofs or JSON-LD Proofs. Internally Civic uses a proprietary implementation of VC Proofs declared via
Credential Commons furthermore defines a global definitions file for claims and credentials that can be referenced in Presentation Requests or Credential Manifests. (https://github.com/identity-com/credential-commons/blob/master/src/claim/definitions.js)
DSR - Dynamic Scope Request
ID Validator Toolkit (e.g. Issuer Toolkit)
URL: This component is not public yet.
The IDV Toolkit is a modular framework that allows an issuer of Verifiable Credential to host an endpoint to validate an users input and issue verifiable credentials to an interested party.
At Identity.com potential issuers are discovered via the Identity.com Marketplace, but this is not a prerequisite for hosting and issuing credentials. The discovery of Issuers and their respective Toolkits can be agnostic from the Identity.com Marketplace.
The IDV Validator Toolkit announces requirements for issuing an Verifiable Credential to a user via a Verification Process that looks similar to this:
In a Validation Process an ID Validator expresses the requirements to an external entity by exposing UCA "User Collectible Attributes" that are defined in an Identity.com specific Library. Entities can submit these UCA (e.g. an E-Mail, a document, a phone number, a validation token) in order to validate information dynamically with the ID Validator.
After a successful Validation process the ID Validator can issue the requested Credential to the User.
Entity Authentication is done via JWT HTTP Bearer Tokens of the respective DID Keys.
Questions/TODO
General References