diff --git a/index.html b/index.html index dd599fe..4e92ec0 100644 --- a/index.html +++ b/index.html @@ -195,26 +195,26 @@

Introduction

Implementer Overview

- By invoking a DID resolver using the standard resolve(did, resolutionOptions) interface (as defined in - the DID Resolution section) one can obtain a DID document and accompanying metadata - (e.g., `contentType`, proof, versioning) which an application can use to validate a user's cryptographic keys, - service endpoints, or status. + By invoking a DID resolver using the standard resolve(did, resolutionOptions) interface (as defined in + the DID Resolution section) one can obtain a DID document and accompanying metadata + (e.g., `contentType`, proof, versioning) which an application can use to validate a user's cryptographic keys, + service endpoints, or status.

- For example, a wallet app could resolve did:example:123?versionTime=2021-05-10T17:00:00Z - using the `versionTime` parameter to retrieve the state of that DID at a past time, or a client could - dereference a DID URL - like did:example:123?service=files&relativeRef=/resume.pdf - (see here for detailed example) - to fetch a user's resume stored via a service declared in the DID document. + For example, a wallet app could resolve did:example:123?versionTime=2021-05-10T17:00:00Z + using the `versionTime` parameter to retrieve the state of that DID at a past time, or a client could + dereference a DID URL + like did:example:123?service=files&relativeRef=/resume.pdf + (see here for detailed example) + to fetch a user's resume stored via a service declared in the DID document.

- Further, the specification's DID URL dereferencing algorithm shows how - a client can follow a fragment (e.g., #key-1) to extract a particular verification method from - the DID document (see here for detailed example). - In practice, implementers validate their resolver against the - DID Resolution Test Suite which exercises - normative MUSTs and error conditions (such as invalid DIDs, deactivated DIDs, unsupported methods, - relative URL expansion, etc.) to ensure that client applications can reliably depend on correct resolution behavior + Further, the specification's DID URL dereferencing algorithm shows how + a client can follow a fragment (e.g., #key-1) to extract a particular verification method from + the DID document (see here for detailed example). + In practice, implementers validate their resolver against the + DID Resolution Test Suite which exercises + normative MUSTs and error conditions (such as invalid DIDs, deactivated DIDs, unsupported methods, + relative URL expansion, etc.) to ensure that client applications can reliably depend on correct resolution behavior across different DID methods.

@@ -265,32 +265,32 @@

  • A decentralized address book: By using DIDs as identifiers for people and organizations within an address book, the controllers of those DIDs can independently update the contents of -their DID documents. Through DID resolution these DIDs can be resolved to obtain the +their DID documents. Through DID resolution these DIDs can be resolved to obtain the current state of the DID document for any given contact, enabling persistent stable identifiers -with updatable services and verification material necessary for continued verifiable interactions. +with updatable services and verification material necessary for continued verifiable interactions.
  • -Verifying a Verifiable Credential: Verifiable Credentials are signed by an issuer and given to a +Verifying a Verifiable Credential: Verifiable Credentials are signed by an issuer and given to a holder. The holder can then create a Verifiable Presentation that is presented to a verifier. -Within the credential, if issuers and holders are identified using a DID, the verifier can +Within the credential, if issuers and holders are identified using a DID, the verifier can use DID resolution to resolve the DID documents of the identified issuer and holder to obtain the verification material necessary to verify the signatures on the Verifiable Presentation.
  • Auditability: DID resolution can be used to obtain the historical state of a DID document either -at a specific point in time or for a specific version. This can be used to audit the historical -verifiable actions of a DID controller. For example, the issuance of a verifiable receipt or the +at a specific point in time or for a specific version. This can be used to audit the historical +verifiable actions of a DID controller. For example, the issuance of a verifiable receipt or the signing of a contract.
  • DID URL based resource retrieval: A DID controller can add service endpoints to their DID document that point to resources they control, for example a profile picture. By referencing these resources -using a DID URL, a web application can use DID resolution and DID URL dereferencing to retrieve the +using a DID URL, a web application can use DID resolution and DID URL dereferencing to retrieve the current version of the resource. The DID URL can act as a persistent, dereferencable identifier for this resource, while the DID controller can independently change the resource over time.
    • - + @@ -409,17 +409,6 @@

    DID Parameters

    For example: 2020-12-20T19:17:47Z. - - - hl - - - A resource hash of the DID document to add integrity protection, as - specified in [[?HASHLINK]]. This parameter is non-normative. - If present, the associated value MUST be an - ASCII string. - - @@ -1588,7 +1577,7 @@

    Metadata Structure

    boolean, or null. The values within any complex data structure such as a map or list MUST be one of these data types as well. - All metadata property definitions registered in the DID Resolution Extensions + All metadata property definitions registered in the DID Resolution Extensions [[?DID-EXTENSIONS-RESOLUTION]] MUST define the value type, including any additional formats or restrictions to that value (for example, a string formatted as a date). It is RECOMMENDED that property