Awesome-Mirrors/decentralized-id.github.io
1
0
Fork 0
mirror of https://github.com/Decentralized-ID/decentralized-id.github.io.git synced 2024-12-14 10:04:23 -05:00
Code Issues Packages Projects Releases Wiki Activity
761b3a88be
decentralized-id.github.io/_posts/identosphere-dump/open-standards/decentralized-identifier.md
⧉ infominer 91fd6f06e2 MDC
2022-11-25 23:39:31 -05:00

23 KiB
Raw Blame History

published
false

DIDs

Goals of the did:indy DID Method Specification

  • Namespaced DIDs useful across all Indy instances
  • Indy network discovery
  • Full DIDDoc support
  • Namespaced identifiers for other Indy objects (schemas, etc.)
  • Support for important resolution parameters
  • E.g. version-id, version-time, resource
  • Nice to have (but not likely to be there):
  • Cross-ledger registration of networks for discovery
  • Support for KERI identifiers on Indy networks

Getting involved with this work:

DIDs that target a distributed ledger face significant practical challenges in bootstrapping enough meaningful trusted data around identities to incentivize mass adoption. We propose using a new DID method that allows them to bootstrap trust using a Tor Hidden Service's existing reputation.

we'd like to review more with our community how close we want to keep did:onion to did:web, and if we want to incorporate some elements of did:peer or KERI or to leverage services like Open Time Stamps.

Specification: https://did-did.spruceid.com/

Source: https://github.com/spruceid/did-did/

Registration request: https://github.com/w3c/did-spec-registries/pull/280

did:un-did is a DID method that enables using any valid Decentralized Identifier (DID) as a did:un-did DID, but more importantly it un-does the did that did:did did method performs.

Joe came and fervently disagreed with my assertions. Lots of people had reasonable counter arguments. My main arguments are 1. DID Documents don't have history when old keys are always relevant and 2. having 94 different DID methods that aren't compatible nor replaceable and don't function the same way is a HUGE problem.

DID Methods

  • DID:Customer

    While we are committed to providing optionality to our customers, it’s equally important to communicate the selection criteria behind these options so that customers can consider the tradeoffs of underlying DID-methods alongside the problem set they’re solving for.

  • BrightID (a singular address that is linked to your friends’ ID in a “web of trust”) and UBDI lets you pull in data from a whole variety of sources and then make deals to get $ for your data.

  • 3IDConnect Ceramic

  • along with the slightly problematic frame that users have “a DID” (GitHub)

godiddy.com is a hosted platform that makes it easy for SSI developers and solution providers to work with DIDs.

Basic functions are creating, resolving, updating, and deactivating DIDs across multiple DID methods and networks. Advanced functions include key management, search, transfer of DIDs, lookup of historical DID document versions, notification of DID-related events, and more.

This platform can be accessed either via a web frontend, or an API.

Check out the Documentation and the API Reference.

SaaS, Wallet, DID

  • Centralized service that shouldn’t be used to host security sensitive DIDs, it contradicts the principle of self-sovereignty. The service is meant for developers to try out the technology.

  • Godiddy is a service that hosts the community components universal resolver and registrar + additional proprietary components so that it offers a comprehensive DID service for creating and managing DIDs across multiple methods.

  • How robust is the service on bad network connections? Markus: There are github issues concerning TTL in the DID spec WG. Self-hosting is likely to be a better option than using the centralized service.

  • Feature Grid with future ideas: https://docs.godiddy.com/en/feature-grid

  • Key Management: When keys are created they are stored in the wallet and are returned to the client. This is not ideal from a security point of view. An improved API is planned that would allow clients to keep the private key on the client and use the service to create for example the DID Document -> this is also part of the next session.

This session was to talk about the topics I put in a recent article that created a huge fire in our community where I lay out the case for completely abandoning the W3C DID standards.

Joe came and fervently disagreed with my assertions. Lots of people had reasonable counter arguments. My main arguments are 1. DID Documents don't have history when old keys are always relevant and 2. having 94 different DID methods that aren't compatible nor replaceable and don't function the same way is a HUGE problem.

There was no conclusion other than Sam Smith and I came to the conclusion that we have more in common than we thought.

  • There is an attempt to specify abstract interfaces if you want to Create/Update/Deactivate a did that could be implemented for all did methods.
  • The idea of this specification is to provide a standard with the same assumptions as with resolution. It should be in an abstract level, meaning it should specify the inputs and outputs of creating/updating/deactivating a did but not how it should be implemented.
  • There are many differences on how the operations of different did methods work, so it is still a question whether this standard will work for all did methods at the current state.
  • Two greatest architectural questions that have come in the way:
  • How should key management be handled: where are keys created, how are they handled etc?
  • The concept of internal state or longer running jobs
  • Regarding key management, in the current early draft there is a section which describes 3 possible way to handle key management:
  • Internal secret mode: The service itself generates keys and either stores them or returns them to the client. The disadvantage is that the service has to be highly trusted. This mode could make sense if you run the service yourself.
  • External secret mode: Key management is handled by some kind of externally hosted wallet that the service can call (e.g hardware wallet).
  • Client-managed secret mode: The client that makes use of the registrar service would first create the keys and then call the different functions of the service. This would mean back and forth communication between server and client (e.g server sends sign request, client signs etc.).
  • [...]

Links:

Join research project between SBA Research and Danube Tech, partially funded by FFG (Austria) and DHS (US).

did:btcr https://w3c-ccg.github.io/didm-btcr

did:v1 https://w3c-ccg.github.io/did-method-v1/

did:ethr https://github.com/ethr-did-resolver/

did:sov(did:indy) Sovrin DID Method Specification

did:web https://github.com/w3c-ccg/did-method-web

did:ion https://github.com/decentralized-identity/ion-did-method

did:peer https://identity.foundation/peer-did-method-spec/index.html

Selected criteria were rule making, operation, enforcement, security, controllability, portability, keying material, privacy.

Challenges and insights:

  • For some DID method, evaluation requires more effort than just the specification. Each DID method uses different infrastructure. E.g. evaluating governance of Bitcoin blockchain is complex.
  • Most DID methods focus on CRUD operations but don't think much about governance, privacy, security.
  • Some DID methods are not very well documented.
  • Discrepancies between specifications and actual implementations.
  • It was difficult to compare methods since they are based on different technologies.
  • Specifications change after or during the evaluation.
  • DID Rubric has also changed/improved over time.
  • Each DID method has pros and cons; there is no "winner"
  • We had 6 evaluators, and in some cases we had different opinions.

Criteria for did Method Evaluation:

DID Methods Evaluation Report - Draft

  • Does not require a centralized registration authority
  • Many DIDs use the distributed ledger technology or any other decentralized network, though it is not mandatory
  • It is a permanent identifier because it does not depend on a single third-party or centralized registry for its existence.
  • Can be cryptographically verified
  • They connect a DID subject (the entity identified by the DID) with a DID document (a set of data that describes the DID subject) to enable the subject to have trustable interactions.
  • They are interoperable and portable, provided they conform to the existing standards laid down by W3C

Peer DIDs offer many benefits such as,

  • No transaction costs involved
  • Easy to create and maintain
  • Since these DIDs are independent of a central system such as a GDPR controller, they can be scaled as needed
  • Offers the highest levels of privacy as only the parties involved can access the DIDs
  • No uncertainties or external problems since these DIDs are not associated with any particular network
  • No degradation of trust throughout the entire lifecycle.
  • In tune with local-first software philosophies
  • Reduces unnecessary correlation between a verifier and an issuer of a verifiable credential.

We are proud to have UNISOT ID (did:unisot) listed at the Decentralized Identity Foundation (DIF). As part of our commitment to open technologies and global interoperability we have presented our DID schema (did:unisot) to the Decentralized Identity Foundation (DIF) and supplied a driver for their Universal DID Resolver which can be accessed at: https://resolver.identity.foundation/. With this anyone can resolve a UNISOT DID Document in a trusted and easy way.

A large set of impact investor, international donor, and government anti-poverty policy is based on the notion that for-profit companies can be induced to serve the poor with life changing services like banking or schooling but the limits of the for profit model are not always taken into account

did:orb that decouples DIDs from ledgers while maintaining trust and security. SecureKey is leveraging standard and open-source peer-to-peer protocols like ActivityPub, data structures like verifiable credentials content-addressed storage like IPFS, and distributed trust services like the Google Trillian project to build a peer-to-peer trust network.

This session covered the evolution of thinking from the initiation of did:git at IIW April 2019 up until now. I recently chose to deprecate the did:git proposal in lieu of a new project to update Git to use provenance logs for identifier management in Git repos. I recently wrote an article describing the proposal:

and the current proposal is here:

This is an exciting project that will bring decentralized identifiers to software creation to give us end-to-end secure and verifiable software delivery.

Veres One, DID Rubric Evaluation, DID methods, DIDs,

What we learned #1

  • Rubric still in infancy
  • Some questions were just too academic
  • Need structure-variable questions
  • 1.3 Separation of Power
  • 4.6 Consensus layers
  • Enforcement (initial draft of real questions)

What we learned #2

  • Design is itself a separable concern
  • Distinct from governance
  • May need separate evaluations for Implementations, esp wallets
  • Adversaries: how does the method handle particular adversaries

What we learned #3

  • Still a long learning curve
  • Learning the Rubric
  • Learning each Method
  • Need better tools for community engagement
  • Criteria discussion
  • Custom rubric development
  • Shared rubric evaluations
  • [...]

Notes from Chat:

Slides: iiw-between-public-and-private.pdf

  • It was very hard for me to explain the problem I’m searching a solution for and equally for the proposed solution ideas.
  • We discussed a lot of more philosophical questions and if peer-dids are a good thing or not and if it is worth trying to minimize correlation when any involved party anyway stores the personal data of the related persons. I think we should make it as hard as possible to correlate data, even if we can not completely prevent it.
  • We also discussed the potential complexity of such a solution and if it is worth it. The conclusion was to minimize the number of personas one should (be forced) to hold, such that it is still easy to maintain.