2020-02-25 Special: Rich Schemas

Summary

Special meeting February 25

Discuss progress on Rich Schemas, and next steps

Remember the Hyperledger Code of Conduct

Anti-Trust Policy

Linux Foundation meetings involve participation by industry competitors, and it is the intention of the Linux Foundation to conduct all of its activities in accordance with applicable antitrust and competition laws. It is therefore extremely important that attendees adhere to meeting agendas, and be aware of, and not participate in any activities that are prohibited under applicable US state, federal or foreign antitrust and competition laws.

Examples of types of actions that are prohibited at Linux Foundation meetings and in connection with Linux Foundation activities are described in the Linux Foundation Antitrust Policy available at http://www.linuxfoundation.org/antitrust-policy. If you have questions about these matters, please contact your company counsel, or if you are a member of the Linux Foundation, feel free to contact Andrew Updegrove of the firm of Gesmer Updegrove LLP, which provides legal counsel to the Linux Foundation.

Introductions

Attendees

Main Business

Rich Schemas Roadmap for Rich Schema MVP:

HIPE / RFCs (50% done)
- Mapping and CredDefs use a single Schema only
- Update Schema, Context and Encoding HIPEs/RFCs to match the Common format of rich schema objects
- Mapping (Alex)
- Cred Def (Alex)
- Presentation Def 0.5 version (Ken and Brent)
- Presentation (Ken and Brent)
- Verifiable Credential (Alex)

Update existing HIPEs (Alex)
HIPEs for new objects:

Indy Node implementation (95% done) (Alex)

Make sure that @id == id (Alex)
json_ld validation for objects that must be json_lds

Indy-vdr (Andrew N)
- need estimates

Prerequisite: CI / CD for indy-vdr, and integration into Indy SDK
Requests for every Rich Schema request

aries-credx / indy-credx (Andrew N. and Echo)

create_w3c_cred
sign_w3c_cred
verify_presentation
create_presentation
Need estimates for all items

Milestones:

Issuance of W3C credentials
Presentation and verification

Technical items:

State/search
- Discussed the current logic of storing objects in ledger State (two entries: id and type:name:version)
- type:name:version can be used for discovery functionality
- We may consider supporting of discovery by schema attribute names (either on Ledger, on Observers or off-chain)
HIPEs / RFCs
- Agreed to reference just a single schema by a Mapping object (and hence a CredDef). This will simplify processing and will always have an explicit schema for every credentials.
  - If a CredDef or Mapping needs to use attributes from multiple Schema, it needs to create a new Schema first combining all sub-schemas
- Agreed to have a shared common format for Schemas, Mappings and credentials:
  - Schema defines a set of attribute (as a graph object potentially)
  - Mapping uses a subset of the same attributes (as a graph potentially) following the same structure.
  - Every value in the Mapping object is a list of encoding and rank pairs.
  - Credentials has the same attributes as in Mapping
- Agreed to implement Presentation Definition by phases:
  - Version 0.5: the same workflow as the current proof request
  - Version 0.6: more advanced one with groupings and selections
  - Version 1.0: final Presentation Definition interoperable with the community
- There will be a Delta in protocols for Issuance and Presentation.
  - The workflow is supposed to be the same
  - The only difference is in the format of objects (to not be linked to old schema approach)
JSON-LD
- What objects supposed to be in json-ld format:
  - Context - Json / json_ld
  - Schema - json_ld
  - Encoding - json
  - Mapping - json_ld
  - CredDef - json
  - PresentationDef - json_ld
- Every JSON-LD is supposed to have
  - @id
  - @type
- @id must be equal to the Rich Schema's ID (DID).
- The only thing that we currently expect from json-ld processing is substitution of attributes by a fully-qualified ones
- Due to the proposed format of Schemas, Mappings and Credentials, it looks like we don't need to do any JSON-LD processing/substitution during issuance
- We may need to do JSON-LD processing/substitution during presentation
- If we do JSON-LD processing/substitution, then for MVP we may assume that we resolve the contexts (substitute the fields belonging to a context) belonging to the current ledger only. We are not going to resolve other Indy ledger's context, other blockchain's contexts, and Internet contexts.
DID as ID
- We considered 6 options on how ID may look like:
  - UUID
  - did:sov:const_idstring?name=...;version=....
  - did:sov:issuer_idstr?name=...;version=....
  - did:sov:context-hash-based-idstring
  - sch:sov:idstring
  - dri:sov:idstring
- We think that we should go with did:sov:context-hash-based-idstring and the proposed Draft for canonicalization
- We agree to postpone DID_DOC resolving of Rich Schema object (we may decide not to do it at all)
- The question whether it's OK to use a DID for Rich Schema objects identification is raised in Community
Old VS new credentials

	Anoncreds 1.0	Anoncreds 2.0
Old Schema == old credentials	0 (already done)	2? (second priority if there is a need from product point)
Rich Schema == W3C credentials	1 (first prioarity)	2 (second priority)

So, schema/credentials and Anoncreds version are two separate independent dimensions.

The list of tasks in Jira for the action items we defined:
- HIPEs/RFCs:
  - INDY-2337: Design Schema, Context, Encoding, Mapping, CredDef [Alex]
  - INDY-2347: Design W3C Credential [Alex]
  - INDY-2346: Design Presention Definition [Brent]
  - INDY-2348: Design W3C Presentation [Brent]
- Indy Node:
  - INDY-2350: Improvements in Rich Schema commion code [Alex]
- indy-vdr:
  - IS-1505: Support submitting of Rich Schema txns in indy-vdr [Andrew Nikitin]
  - IS-1506: Support getting Rich Schema txns in indy-vdr [Andrew Nikitin]
- indy-credx:
  - IS-1507: Support issuance of W3C credentils in indy-credx
  - IS-1508: Support presentation of W3C credentials in indy-credx

Space shortcuts

Page tree