Versions Compared

Old Version 2

changes.mady.by.user Paul Bastian

Saved on

compared with

New Version Current

changes.mady.by.user Stephen Curran

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Excerpt
  • ATTRIBs – cardinality, transformation, assembly – specific examples
  • Spec. document structure

Recording from the call: 20210112 Indy DID Method Specification Recording

Hyperledger is committed to creating a safe and welcoming

community for all. For more information

please visit the Hyperledger Code of Conduct.

...

  • Status of HackMD Document – updated to reflect discussions made.
  • Transformations:
    • NYM
    • "endpoint" – historical – such ATTRIBs are on the ledger now
    • DID Core components:
      • Verifications Methods
      • Verification Relationships
      • Agent Service Endpoints
      • Linked Domain Endpoints
      • Additional Public Keys
  • Last meeting we talked about the easy cases:
    • NYM and no ATTRIB
    • NYM and ATTRIB only with an "endpoint" URL.
  • Structure of specification
    • Request: Formalize the Table of Contents and organizing the document into that structure 

Future Discussions:

    • Concepts agreed to:
      • Only the last value of an ATTRIB type should be merged into the document; each instance should be complete
        • We don't have to track streams of updates
        • We are less likely to get into an invalid state
      • For "endpoint" and "serviceEndpoint" – the last of either should be used.
      • The "serviceEndpoint" and other DID Core concepts are likely to be complete sections of the JSON
        • This means there is less of a chance of transforming the document
        • If all the sections are complete, is it worth breaking them up vs. having a single "DIDDoc" ATTRIB and merging into it the data from the NYM transaction?
  • Controller discussion
    • Question: Should the ability to update a DID use current Indy rules (checking the NYM owner signature and if necessary an Endorser) or should the contents of the DIDDoc be used?
    • This generated a discussion of the trade-off in the changes needed to Indy vs. the need to enable DID Core capabilities and organizational use cases (e.g. a DID controlled by multiple people in an organization).
    • Idea:
      • Extend the NYM to include more complex DID Controller concepts – e.g. multiple verkeys and multiple signatures required for writes, including (perhaps) N of M requirements.
      • If we did this, the more complex NYM would have to be merged into the ATTRIB(s) that make up the DIDDoc
  • Idea:
    • Instead of having multiple ATTRIBs assembled into a DIDDoc, use a version identifier to handle the transformation of the NYM+ATTRIB to make the DIDDoc to enable backwards compatibility
  • Open question: While we want to merge the NYM into the DIDDoc, do we need to have multiple ATTRIBs assembled into a DIDDoc, or just one?

Future Discussions:

  • Request for Markus Sabadello to provide guidance on aligning the "NYM as controller" concept (above) with and the DID Core specifications concept of a controller.
  • ATTRIB transformations to generate a DIDDoc
  • DNR and DND discussions
  • DNR and DND discussions
  •  DIDDocs:What is the structure of the DIDDoc template - core and extensions?
  • Structure for Indy specific objects returned as DIDs
    • What is the DID?
    • What is the DIDDoc format?
    • Existing objects – backwards compatibility
      • DID vs. DID URL – how could that be done?

...