From 43fb3f34942fe8830d401471da66e7919d261eba Mon Sep 17 00:00:00 2001 From: Markus Sabadello Date: Thu, 14 Nov 2024 16:39:25 +0100 Subject: [PATCH 1/3] Avoid terms "Primary/Secondary Resource" --- index.html | 98 ++++++++++++++++++++++++++---------------------------- 1 file changed, 48 insertions(+), 50 deletions(-) diff --git a/index.html b/index.html index 1cea887..d3eaa87 100644 --- a/index.html +++ b/index.html @@ -1001,36 +1001,41 @@

DID URL Dereferencing Metadata

Algorithm

The following DID URL dereferencing algorithm MUST be implemented by a conformant DID resolver. - In accordance with [[RFC3986]], it consists of the following steps: Resolving the DID, dereferencing the primary - resource, and dereferencing the secondary resource (only if the input DID URL contains a DID fragment:

+ In accordance with [[RFC3986]], it consists of the following steps: Resolving the DID, dereferencing the + resource, and dereferencing the fragment (only if the input DID URL contains a DID fragment):

-
    -
  1. Validate that the input DID URL conforms to the `did-url` rule of the - DID URL Syntax. - If not, the DID URL dereferencer MUST return the following result: +
    +

    Dereferencing the Resource

      -
    1. dereferencingMetadata: «[ "error" → "invalidDidUrl" ]»
      2. -
    2. contentStream: null
      3. -
    3. contentMetadata: «[ ]»
      4. -
    -
  2. Obtain the DID document for the input DID by executing the - DID resolution algorithm as defined in . All - - DID parameters of the input DID URL MUST be passed as resolution options to the DID - Resolution algorithm. If the input DID does not exist, return a null result. - Otherwise, the result is called the resolved DID document.
    3. -
    3. -
  3. If present, separate the DID fragment from the input DID URL. Execute the algorithm for - , with the input DID URL adjusted - accordingly.
    4. -
  4. If the original input DID URL contained a DID fragment, execute the algorithm for - .
    5. -
+
  • Validate that the input DID URL conforms to the `did-url` rule of the + DID URL Syntax. + If not, the DID URL dereferencer MUST return the following result: -
    -

    Dereferencing the Primary Resource

    -
      -
    1. If the input DID URL contains the +
        +
      1. dereferencingMetadata: «[ "error" → "invalidDidUrl" ]»
        2. +
      2. contentStream: null
        3. +
      3. contentMetadata: «[ ]»
        4. +
      + +
    2. Obtain the DID document for the input DID by executing the + DID resolution algorithm as defined in . All + + DID parameters of the input DID URL MUST be passed as resolution options to the DID + Resolution algorithm. If the input DID does not exist, return a null result. + Otherwise, the result is called the resolved DID document.
      3. + + +
    3. If present, separate the DID fragment from the input DID URL and continue + with the input DID URL adjusted accordingly.
      4. + +
    4. If the input DID URL contains no DID path and no DID query: + 
      did:example:1234
      +
        +
      1. Return the resolved DID document.
        2. +
      +
      5. + +
    5. Otherwise, if the input DID URL contains the DID parameter service and optionally the relativeRef DID parameter: 
      did:example:1234?service=files&relativeRef=%2Fmyresume%2Fdoc%3Fversion%3Dlatest
      @@ -1058,12 +1063,6 @@

      Dereferencing the Primary Resource

      See comments by Dave Longley about `serviceType`.

      -
    6. Otherwise, if the input DID URL contains no DID path and no DID query: - 
      did:example:1234
      -
        -
      1. Return the resolved DID document.
        2. -
      -
    7. Otherwise, if the input DID URL contains a DID path and/or DID query: 
      did:example:1234/custom/path?customquery
        @@ -1082,17 +1081,16 @@

        Dereferencing the Primary Resource

    -
    -
    -

    Dereferencing the Secondary Resource

    +
    +

    Dereferencing the Fragment

    If the input DID URL contains a DID fragment, - then dereferencing of the secondary resource identified by the URL is dependent not on the URI scheme, but - on the media type ([[RFC2046]]) of the primary resource, i.e., on the result of - .

    + then dereferencing of the fragment is dependent + on the media type ([[RFC2046]]) of the resource, i.e., on the result of + .

      -
    1. If the result of is an output service endpoint URL, +
    2. If the result of is an output service endpoint URL, and the input DID URL contains a DID fragment: 
      did:example:1234?service=files&relativeRef=%2Fmyresume%2Fdoc%3Fversion%3Dlatest#intro
        @@ -1108,8 +1106,8 @@

        Dereferencing the Secondary Resource

        Location header (see section 7.1.2 of [[RFC7231]].

      -
    3. Otherwise, dereference the secondary resource identified by the DID fragment as defined by the media type ([[RFC2046]]) of the primary resource. - For example, if the primary resource is a representation of a DID document with media type application/did+ld+json, then +
    4. Otherwise, dereference the DID fragment as defined by the media type ([[RFC2046]]) of the resource. + For example, if the resource is a representation of a DID document with media type application/did+ld+json, then the fragment is treated according to the rules associated with the JSON-LD 1.1: application/ld+json media type [JSON-LD11]. @@ -1487,15 +1485,15 @@

      Client-Side Dereferencing

      algorithm may be performed by different components of a Resolver Architecture.

      Specifically, when a DID URL with a DID fragment is dereferenced, then - Dereferencing the Primary Resource is done by + Dereferencing the Resource is done by the DID resolver, and - Dereferencing the Secondary Resource is done by the client.

      + Dereferencing the Fragment is done by the client.

      Example: Given the DID URL did:xyz:1234#keys-1, a DID resolver could be invoked via local binding - for Dereferencing the Primary Resource (i.e., the DID document), + for Dereferencing the Resource (i.e., the DID document), and the client could complete the DID URL dereferencing algorithm by - Dereferencing the Secondary Resource (i.e., a part of the DID document).

      + Dereferencing the Fragment (i.e., a part of the DID document).

      Client-Side Dereferencing

      Example: Given the DID URL did:xyz:1234#keys-1, a DID resolver could be invoked via local binding which invokes another DID resolver via remote binding - for Dereferencing the Primary Resource (i.e., the DID document), + for Dereferencing the Resource (i.e., the DID document), and the client could complete the DID URL dereferencing algorithm by - Dereferencing the Secondary Resource (i.e., a part of the DID document).

      + Dereferencing the Fragment (i.e., a part of the DID document).

      Client-Side Dereferencing

      Example: Given the DID URL did:xyz:1234?service=agent&relativeRef=%2Fsome%2Fpath%3Fquery#frag, a DID resolver could be invoked - for Dereferencing the Primary Resource (i.e., a service endpoint URL), + for Dereferencing the Resource (i.e., a service endpoint URL), and the client could complete the DID URL dereferencing algorithm by - Dereferencing the Secondary Resource (i.e., a service endpoint URL with a fragment).

      + Dereferencing the Fragment (i.e., a service endpoint URL with a fragment).

      Date: Thu, 14 Nov 2024 18:13:38 +0100 Subject: [PATCH 2/3] Apply suggestion about media type by @msporny. Co-authored-by: Manu Sporny --- index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.html b/index.html index d3eaa87..440d963 100644 --- a/index.html +++ b/index.html @@ -1107,7 +1107,7 @@

      Dereferencing the Fragment

  • Otherwise, dereference the DID fragment as defined by the media type ([[RFC2046]]) of the resource. - For example, if the resource is a representation of a DID document with media type application/did+ld+json, then + For example, if the resource is a representation of a DID document with media type application/did, then the fragment is treated according to the rules associated with the JSON-LD 1.1: application/ld+json media type [JSON-LD11]. From 72c1447470fa3b471cd122ff7ab61a773c456b9e Mon Sep 17 00:00:00 2001 From: Markus Sabadello Date: Thu, 14 Nov 2024 21:35:52 +0100 Subject: [PATCH 3/3] Apply editorial suggestions by @TallTed. Co-authored-by: Ted Thibodeau Jr --- index.html | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/index.html b/index.html index 440d963..52bb05d 100644 --- a/index.html +++ b/index.html @@ -1001,8 +1001,8 @@

    DID URL Dereferencing Metadata

    Algorithm

    The following DID URL dereferencing algorithm MUST be implemented by a conformant DID resolver. - In accordance with [[RFC3986]], it consists of the following steps: Resolving the DID, dereferencing the - resource, and dereferencing the fragment (only if the input DID URL contains a DID fragment):

    + In accordance with [[RFC3986]], it consists of the following three steps: resolving the DID; dereferencing the + resource; and dereferencing the fragment (only if the input DID URL contains a DID fragment):

    Dereferencing the Resource

    @@ -1020,13 +1020,13 @@

    Dereferencing the Resource

  • Obtain the DID document for the input DID by executing the DID resolution algorithm as defined in . All - DID parameters of the input DID URL MUST be passed as resolution options to the DID - Resolution algorithm. If the input DID does not exist, return a null result. - Otherwise, the result is called the resolved DID document.
    • + DID parameters of the input DID URL MUST be passed as resolution options to the + DID Resolution algorithm. If the input DID does not exist, return a null result. + Otherwise, the result is called the resolved DID document.
  • If present, separate the DID fragment from the input DID URL and continue - with the input DID URL adjusted accordingly.
    • + with the adjusted input DID URL.
  • If the input DID URL contains no DID path and no DID query: 
    did:example:1234