Versions Compared

Old Version 1

changes.mady.by.user Stephen Curran

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.

...

  • Indy Node and Indy Plenum CI/CD process continuing – progress being made.

Attendees

Collaboration Channels

...

  • Status of HackMD Document – updated to reflect discussions made.
  • Transformations:
    • NYM
    • "endpoint" – historical – such ATTRIBs are on the ledger now
    • Concepts agreed to:
      • 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:

        • 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?

    ...