W3C : A DID developer's guide to understanding and implementing Decentralized Identifiers

[Vishwas1]

DID implementers guide

Understand this: A DID developer's guide to understanding and implementing Decentralized Identifiers

https://w3c.github.io/did-imp-guide/

[Vishwas1]

DID operations

• Create, : tyronzil-did-create, hlindy-did-create
• Resolve, : tyronzil-did-resolve, hlindy-did-resolve
• Update, : tyronzil-did-update, hlindy-did-update
• and Deactivate : tyronzil-did-deactivate, hlind-did-deactivate

Verifiable Data Registry (VDR)

• Blockchains or distributed ledgers are popular choices for building verifiable data registries, but there are other solutions
• Depending on the nature of the VDR, it may be desirable to store data other than DID documents, such as verifiable credentials, templates or schemas for credentials, discovery metadata, or integrity- or content-addressable identifiers for related information.

Establishing a DID

• In order to create secure DID systems, it is important to consider the process of establishing a Decentralized Identifier.
• Common process would be
  • Obtain entropy from a source of randomness that is as close to actually random as possible.
  • Generate a first verification method (publickey) from entropy.
  • Use the first verification method to perform a DID Create operation.

DID create operation

• A DID method specification MUST specify how a DID controller creates a DID and its associated DID document.
• The Create Operation will often use the first verification method directly, or a deterministic function thereof, such as a hash, to construct and register the DID.

DID resolve

• DID resolution is a function which takes a DID, and produces a DID resolution result in a representation, most commonly JSON.
• A DID method specification MUST specify how a DID resolver uses a DID to resolve a DID document, including how the DID resolver can verify the authenticity of the response.

DID URL

• DID URLs can be used to identify sub-resources inside a DID document, older versions of a DID document, or resources outside of a DID document.
• It can be used to retrieve things like representations of DID subjects, verification methods, services, specific parts of a DID document, or other resources.
• Examples: https://w3c.github.io/did-imp-guide/#did-url-syntax https://www.w3.org/TR/did-core/#did-url-syntax
• The resource identifiers did:example:123, did:example:123/path and did:example:123?args=1 each identify a unique resource.
• types
  • path: did:example:123/ephemeral/77d66171-b290-489c-abf1-95ae10725201#primary
  • query: DID URL identifying a verification method in an older version of a DID document did:example:123?versionId=77d66171-b290-489c-abf1-95ae10725201#primary
  • fragment: DID URL identifying a verification method in a DID document did:example:123#primary

DID Update operation

• A DID method specification MUST specify what constitutes an update to a DID document and how a DID controller can update a DID document or state that updates are not possible.

DID Deactivate

• The DID method specification MUST specify how a DID controller can deactivate a DID or state that deactivation is not possible.

Verification relationship

Authentication

• Implementers are advised to implement support for this relationship.
• The authentication verification relationship is used to specify how the DID subject is expected to be authenticated, for purposes such as logging into a website or engaging in any sort of challenge-response protocol.

  "authentication": [
  // referenced
  "did:example:123456789abcdefghi#keys-1",
  // embeded
  {
    "id": "did:example:123456789abcdefghi#keys-2",
    "type": "Ed25519VerificationKey2020",
    "controller": "did:example:123456789abcdefghi",
    "publicKeyMultibase": "zH3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV"
  }
  ],

If authentication is established, it is up to the DID method or other application to decide what to do with that information.

A particular DID method could decide that authenticating as a DID controller is sufficient to, for example, update or delete the DID document.

Another DID method could require different keys, or a different verification method entirely, to be presented in order to update or delete the DID document than that used to authenticate.

• Note that the verification method indicated by the authentication property of a DID document can only be used to authenticate the DID subject.

Assertion

The assertionMethod verification relationship is used to specify how the DID subject is expected to express claims, such as for the purposes of issuing a Verifiable Credential

• This property is useful, for example, during the processing of a verifiable credential by a verifier.
• During verification, a verifier checks to see if a verifiable credential contains a proof created by the DID subject by checking that the verification method used to assert the proof is associated with the assertionMethod property in the corresponding DID document.

Key Agreement

The keyAgreement verification relationship is used to specify how an entity can generate encryption material in order to transmit confidential information intended for the DID subject, such as for the purposes of esta blishing a secure communication channel with the recipient.

An example of when this property is useful is when encrypting a message intended for the DID subject. In this case, the counterparty uses the cryptographic public key information in the verification method to wrap a decryption key for the recipient.

Capability Invocation

The capabilityInvocation verification relationship is used to specify a verification method that might be used by the DID subject to invoke a cryptographic capability, such as the authorization to update the DID Document.

I could not understand it completely : https://www.w3.org/TR/did-core/#capability-invocation

Capability delegation

https://www.w3.org/TR/did-core/#capability-delegation

Verification methods properties

1. publicKeyJwk
2. publicKeyMultibase
3. blockchainaccountid https://w3c-ccg.github.io/security-vocab/#blockchainAccountId

Verification Method types

These are values to be used for the type field in a verification method object.

https://w3c-ccg.github.io/security-vocab/#classes

1. jsonwebkey2020
2. EcdsaSecp256k1VerificationKey2019
3. Ed25519VerificationKey2018
4. Bls12381G1Key2020
5. Bls12381G2Key2020
6. pgpverificationkey2021
7. RsaVerificationKey2018
8. X25519KeyAgreementKey2019
9. EcdsaSecp256k1RecoveryMethod2020
10. VerifiableCondition2021 : It can be used to combine verification methods together to form conjugated conditions such as logical operations &&, thresholds, weighted thresholds, relationships and a delegation to external verification methods.

Services

https://w3c.github.io/did-spec-registries/#service

[Vishwas1]

Compliance

Review any applicable local law when considering developing or operating a decentralized identifier method.

Consider GDPR, CCPA, EAR.

https://w3c.github.io/did-imp-guide/#compliance

Cryptography

• Digtial Signature: Avoid secp256k1, RSA, P-256, P-384 and P-521. We recommend the user review safecurves.cr.yp.to before selecting elliptic curve types.
• Hashing Algos: Avoid MD5, SHA1, and other legacy hashing algorithms with known weaknesses or high collision rates.
• Randomness: When making an implemention carefully consider how you are sourcing random numbers. Consult RFC 4086: Randomness Requirements for Security when selecting an approach to get random bits
• Zero Knowledge Proof: Consider using BBS+ Signatures for selective disclosure and linked-secret–based JSON-LD verifiable credentials. Avoid zero knowledge proofs as described in the AnonCredDerivedCredentialv1. Ledger-specific technologies should be avoided when designing for portable, interoperable, and open-standards–based zero knowledge proofs.