Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

Summary

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

Recording from the call: 

Hyperledger is committed to creating a safe and welcoming

community for all. For more information

please visit the Hyperledger Code of Conduct.

Welcome and Introductions

Announcements

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

Attendees

Collaboration Channels

Agreed Upon:

  • See HackMD Document for most of what we have discussioned
  • To find networks we will require at least the first and perhaps the second of these approaches, while the rest are suggested:
    • Config files for one or more known networks
    • A mechanism for a ledger operator to register discovery information for other ledgers (aka "human gossip")
      • A DID/DIDDoc on a ledger will contain cross-registry information
      • A mechanism is needed for finding the DID(s) that contain the registrations – ideas have been put forward - a DID Name Directory (DND) is the likely approach.
      • Document about the DND and DNR records
    • Decentralized registries based on verifiable credentials
    • Other registry mechanisms, such as the DDNR proposal
    • The DID Method Spec will include a reference to a repo (likely) "indy-did-networks" within Hyperledger that will be a lightly managed, structured repository of folders per Indy network with at least the config file(s) for the networks. Use of the repo is voluntary, but provides a convenient way for networks to publish information about the network. Maintainers will be selected from the community and should exhibit a light hand in accepting PRs, being concerned mainly with structure of the data (not content) and that contributors are not being malicious about updating the information of other network operators. The Hyperledger governance structure may be used for disputes as appropriate. This is not a replacement for the Governance that a specific network should implement.

Online Discussion (from RocketChat this week)

  • None

This Week's Discussion:

Review of previous decisions

  • See "Agreed Upon" topics above.

Continuing from the last discussion on transforming NYM and ATTRIB data to get the DIDDoc

  • Status of HackMD Document – updated to reflect discussions made.
  • Transformations:
    • NYM
    • "endpoint"
    • 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:

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



  • No labels