Rename Identity-Digest to Unencoded-Digest.

Following LPardue/draft-pardue-http-identity-digest#16, this PR
changes the header name that we require signatures to include.

index.bs

@@ -33,7 +33,7 @@ urlPrefix: https://w3c.github.io/webappsec-subresource-integrity/; spec: SRI
         text: valid SRI hash algorithm token
 urlPrefix: https://lpardue.github.io/draft-pardue-http-identity-digest/draft-pardue-httpbis-identity-digest.html; spec: ID.pardue-httpbis-identity-digest
     type: http-header; 
-        text: Identity-Digest; url: name-the-identity-digest-field
+        text: Unencoded-Digest; url: name-the-unencoded-digest-field
 urlPrefix: https://www.rfc-editor.org/rfc/rfc9421.html; spec: RFC9421
     type: dfn
         text: signature base; url: name-creating-the-signature-base
@@ -81,7 +81,7 @@ spec:html; type:element; text:link
   "ID.pardue-httpbis-identity-digest": {
     "authors": [ "Lucas Pardue", "Mike West" ],
     "href": "https://lpardue.github.io/draft-pardue-http-identity-digest/draft-pardue-httpbis-identity-digest.html",
-    "title": "HTTP Identity Digest"
+    "title": "HTTP Unencoded Digest"
   }
 }
 </pre>
@@ -142,8 +142,8 @@ This document outlines the changes that would be necessary to [[Fetch]], and
         Vary: Accept-Encoding
         Content-Type: text/javascript; charset=UTF-8
         Access-Control-Allow-Origin: *
-        Identity-Digest: sha-512=:[base64-encoded digest of `console.log("Hello, world!");`]:
-        Signature-Input: sig1=("identity-digest";sf); keyid="[base64-encoded public key]"; tag="sri"
+        Unencoded-Digest: sha-512=:[base64-encoded digest of `console.log("Hello, world!");`]:
+        Signature-Input: sig1=("unencoded-digest";sf); keyid="[base64-encoded public key]"; tag="sri"
         Signature: sig1=:[base64-encoded result of Ed25519(signature base)]:
 
         console.log("Hello, world!");
@@ -187,7 +187,7 @@ into a few independent parts, layered on top of one another to achieve the goals
 developers are aiming for.
 
 1.  **Server-initiated integrity checks**: Servers can deliver an
-    [:Identity-Digest:] header along with responses that contain one or more
+    [:Unencoded-Digest:] header along with responses that contain one or more
     digests of the response's content _after_ decoding any [=content codings=]
     (gzip, brotli, etc).
 
@@ -224,7 +224,7 @@ developers are aiming for.
 
 Implementing the mechanism in this document therefore requires:
 
-1.  Implementing [:Identity-Digest:] checks, at least for the subset of
+1.  Implementing [:Unencoded-Digest:] checks, at least for the subset of
     resource types upon which SRI can act: scripts and stylesheets.
 
 2.  Implementing the subset of HTTP Message Signatures required to support the
@@ -253,7 +253,7 @@ we're only executing script correctly signed with a key we expect:
     requirements for resource inclusion.
 
 4.  Once the response has streamed in, we validate the integrity information
-    contained in the [:Identity-Digest:] headers against the response body,
+    contained in the [:Unencoded-Digest:] headers against the response body,
     refusing to execute any mismatched responses.
 
 5.  We're done, executing probably-safe JavaScript to our heart's content.
@@ -317,11 +317,11 @@ guidelines from Section 1.4 of [[RFC9421]]:
     1.  Include the following [=component identifiers=] with their associated
         constraints:
 
-        *   `identity-digest`, which MUST include the <a>`sf`</a> parameter and
+        *   `unencoded-digest`, which MUST include the <a>`sf`</a> parameter and
             no other parameters.
 
         Note: We'll extend the set of allowed headers over time. The limitation
-        to `identity-digest` is artificial, and aimed towards making a prototype
+        to `unencoded-digest` is artificial, and aimed towards making a prototype
         of this approach as simple as possible to implement and evaluate as we
         decide what makes sense to ship at scale.
 
@@ -369,7 +369,7 @@ guidelines from Section 1.4 of [[RFC9421]]:
         which guarantees uniqueness.
 
 :   **Structured Field Types**:
-::  *   The `identity-digest` component references the [:Identity-Digest:]
+::  *   The `unencoded-digest` component references the [:Unencoded-Digest:]
         header defined in [[ID.pardue-httpbis-identity-digest]]. It is a
         [=structured header/Dictionary=] Structured Field.
 
@@ -404,7 +404,7 @@ guidelines from Section 1.4 of [[RFC9421]]:
 
 :   **Other**
 ::  The HTTP Message Signature must be delivered with a response.
-::  The [:Identity-Digest:] header must be [=Identity-Digest/valid for SRI=].
+::  The [:Unencoded-Digest:] header must be [=Unencoded-Digest/valid for SRI=].
 ::  When instructed to "determine an order" while constructing the signature
     base, clients and servers both MUST choose the same order as the
     [:Signature-Input:] header they consume or produce, respectively.
@@ -413,7 +413,7 @@ guidelines from Section 1.4 of [[RFC9421]]:
 <div class="example" id="example-verification-requirements">
     Valid [:Signature-Input:] header values would therefore include:
 
-    *   `("identity-digest";sf);keyid="MCowBQYDK2VwAyEAJrQLj5P/89iXES9+vFgrIy29clF9CC/oPPsw3c5D0bs=";tag="sri"`
+    *   `("unencoded-digest";sf);keyid="MCowBQYDK2VwAyEAJrQLj5P/89iXES9+vFgrIy29clF9CC/oPPsw3c5D0bs=";tag="sri"`
 </div>
 
 <div class="note">
@@ -464,12 +464,12 @@ For posterity, this set of requirements has a few helpful implications:
 
 </div>
 
-#### `Identity-Digest` Validation for SRI #### {#identity-digest-validation-for-sri}
+#### `Unencoded-Digest` Validation for SRI #### {#unencoded-digest-validation-for-sri}
 
 <div algorithm>
 
-An [:Identity-Digest:] [=header=] (|header|) is
-<dfn for="Identity-Digest">valid for SRI</dfn> if the following steps return
+An [:Unencoded-Digest:] [=header=] (|header|) is
+<dfn for="Unencoded-Digest">valid for SRI</dfn> if the following steps return
 "`valid`":
 
 1.  Let |parsed| be the result of [$parsing structured fields$] with `input_string`
@@ -625,7 +625,7 @@ Patches to Fetch {#monkey-patch-fetch}
 --------------------------------------
 
 Support for this feature would require changes to [[Fetch#main-fetch]] to support
-enforcement of server-initiated integrity checks through [:Identity-Digest:],
+enforcement of server-initiated integrity checks through [:Unencoded-Digest:],
 [:Signature:], and [:Signature-Input:], and to pass the right set of information
 into the version of [[SRI#does-response-match-metadatalist]] altered by this
 specification in order to enable signature-based checks that require information
@@ -645,7 +645,7 @@ setting the [:Accept-Signature:] header on outgoing requests based on their
   <li>
     If |request|'s [=request/integrity metadata=] is not the empty string,
     <ins>or <var ignore>internalResponse</var>'s [=response/header list=]
-    [=list/contains=] [:Identity-Digest:],</ins> then:
+    [=list/contains=] [:Unencoded-Digest:],</ins> then:
 
     <ol>
       <li>
@@ -731,7 +731,7 @@ A request generated from the following HTML element:
 would contain the following header:
 
 ```http
-Accept-Signature: sig0=("identity-digest";sf);keyid="JrQLj5P/89iXES9+vFgrIy29clF9CC/oPPsw3c5D0bs=";type="sri"
+Accept-Signature: sig0=("unencoded-digest";sf);keyid="JrQLj5P/89iXES9+vFgrIy29clF9CC/oPPsw3c5D0bs=";type="sri"
 ```
 
 If multiple keys are acceptable (e.g. to support key rotation), the [:Accept-Signature:]
@@ -749,8 +749,8 @@ would produce the following header in its request:
 ```http
 NOTE: '\' line wrapping per RFC 8792
 
-Accept-Signature: sig0=("identity-digest";sf);keyid="JrQLj5P/89iXES9+vFgrIy29clF9CC/oPPsw3c5D0bs=";type="sri" \
-                  sig1=("identity-digest";sf);keyid="xDnP380zcL4rJ76rXYjeHlfMyPZEOqpJYjsjEppbuXE=";type="sri"
+Accept-Signature: sig0=("unencoded-digest";sf);keyid="JrQLj5P/89iXES9+vFgrIy29clF9CC/oPPsw3c5D0bs=";type="sri" \
+                  sig1=("unencoded-digest";sf);keyid="xDnP380zcL4rJ76rXYjeHlfMyPZEOqpJYjsjEppbuXE=";type="sri"
 ```
 
 </div>
@@ -777,7 +777,7 @@ To <dfn abstract-op>append the `Accept-Signature` header</dfn> for a [=request=]
 
 7.  For each |signature| in |parsed|["`signatures`"]:   
 
-    1.  Let |value| be the [=string/concatenation=] of « \`<code>sig</code>\`, counter, \`<code>=("identity-digest";sf);keyid="</code>\`, |signature|["`val`"], \`<code>";type="sri"</code>\` ».
+    1.  Let |value| be the [=string/concatenation=] of « \`<code>sig</code>\`, counter, \`<code>=("unencoded-digest";sf);keyid="</code>\`, |signature|["`val`"], \`<code>";type="sri"</code>\` ».
     2.  [=header list/Append=] (\`<code>Accept-Signature</code>\`, |value|) to |request|'s [=request/header list=].
 
 
@@ -800,7 +800,7 @@ To <dfn abstract-op>perform server-initiated integrity checks</dfn> given a
 (|response|), execute the following steps. They return "`passed`" or
 "`failed`" as appropriate:
 
-1.  <a lt="verify Identity-Digest assertions" abstract-op>Verify
+1.  <a lt="verify Unencoded-Digest assertions" abstract-op>Verify
     `Identify-Digest` assertions</a> for |bytes| and |response|. If the
     result is "`failed`", return "`failed`".
 
@@ -812,15 +812,15 @@ To <dfn abstract-op>perform server-initiated integrity checks</dfn> given a
 
 </div>
 
-### `Identity-Digest` Validation ### {#identity-digest-validation}
+### `Unencoded-Digest` Validation ### {#unencoded-digest-validation}
 
-<div algorithm="identity-digest validation">
-To <dfn abstract-op>verify `Identity-Digest` assertions</dfn> given a
+<div algorithm="unencoded-digest validation">
+To <dfn abstract-op>verify `Unencoded-Digest` assertions</dfn> given a
 [=byte sequence=] (|bytes|) and a [=/response=] (|response|), execute the
 following steps. They return "`verified`" or "`failed`":
 
 1.  Let |header| be the result of [=header list/get a structured field value|getting=]
-    the [:Identity-Digest:] header as a "<a for="structured header">`dictionary`</a>"
+    the [:Unencoded-Digest:] header as a "<a for="structured header">`dictionary`</a>"
     from |response|'s [=response/header list=].
 
 2.  If |header| is `null`, return "`verified`".
@@ -839,7 +839,7 @@ following steps. They return "`verified`" or "`failed`":
 4.  Return "`verified`".
 
 Note: This algorithm requires *all* valid digests delivered via
-[:Identity-Digest:] to match the response's decoded body. Since the server
+[:Unencoded-Digest:] to match the response's decoded body. Since the server
 controls both the body and the headers, it seems unnecessary to allow the
 flexibility of allowing the asserted digests to match more than one resource
 (as we do in client-initiated checks, which need to support servers' content
@@ -872,7 +872,7 @@ following steps. They return "`verified`" or "`failed`":
 
         1.  |components| is a parameterized [=structured header/Inner List=].
         2.  |components| [=list/size=] is 1.
-        3.  |components|[0] [=string/is=] the [=string=] "`identity-digest`".
+        3.  |components|[0] [=string/is=] the [=string=] "`unencoded-digest`".
         4.  |components|[0] has a single [=structured header/parameter=]: <a>`sf`</a>.
 
     3.  Let |params| be |components| [=structured header/parameters=].
@@ -1108,14 +1108,14 @@ user@host:~/path$  echo -n "{\"hello\": \"world\"}" | openssl dgst -binary -sha2
 X48E9qOokqqrvdts8nOJRJN3OWDUoyWxBf7kbu9DBPE=
 ```
 
-And send that digest along with the response via an [:Identity-Digest:] header;
+And send that digest along with the response via an [:Unencoded-Digest:] header;
 
 <xmp highlight=http line-highlight=5>
 HTTP/1.1 200 OK
 Date: Tue, 20 Apr 2021 02:07:56 GMT
 Content-Type: application/json
 Content-Length: 18
-Identity-Digest: sha-256=:X48E9qOokqqrvdts8nOJRJN3OWDUoyWxBf7kbu9DBPE=:
+Unencoded-Digest: sha-256=:X48E9qOokqqrvdts8nOJRJN3OWDUoyWxBf7kbu9DBPE=:
 
 {"hello": "world"}
 </xmp>
@@ -1153,7 +1153,7 @@ with open("/tmp/tmp_key.pem", "rb") as pem:
 ```
 
 With that encoding in hand, the developer can construct a [:Signature-Input:]
-header that specifies the [:Identity-Digest:] header as a signed component,
+header that specifies the [:Unencoded-Digest:] header as a signed component,
 and includes the base64-encoded public key as the <a>`keyid`</a> parameter
 (as discussed in [#profile]):
 
@@ -1162,8 +1162,8 @@ HTTP/1.1 200 OK
 Date: Tue, 20 Apr 2021 02:07:56 GMT
 Content-Type: application/json
 Content-Length: 18
-Identity-Digest: sha-256=:X48E9qOokqqrvdts8nOJRJN3OWDUoyWxBf7kbu9DBPE=:
-Signature-Input: signature=("identity-digest";sf);keyid="JrQLj5P/89iXES9+vFgrIy29clF9CC/oPPsw3c5D0bs=";tag="sri"
+Unencoded-Digest: sha-256=:X48E9qOokqqrvdts8nOJRJN3OWDUoyWxBf7kbu9DBPE=:
+Signature-Input: signature=("unencoded-digest";sf);keyid="JrQLj5P/89iXES9+vFgrIy29clF9CC/oPPsw3c5D0bs=";tag="sri"
 
 {"hello": "world"}
 </xmp>
@@ -1174,8 +1174,8 @@ as the header's ordering each time it instructs us to "determine an order" in
 Section 2.3 of [[RFC9421]]. We'll end up with:
 
 ```
-"identity-digest";sf: sha-256=:X48E9qOokqqrvdts8nOJRJN3OWDUoyWxBf7kbu9DBPE=:
-"@signature-params": ("identity-digest";sf);keyid="JrQLj5P/89iXES9+vFgrIy29clF9CC/oPPsw3c5D0bs=";tag="sri"
+"unencoded-digest";sf: sha-256=:X48E9qOokqqrvdts8nOJRJN3OWDUoyWxBf7kbu9DBPE=:
+"@signature-params": ("unencoded-digest";sf);keyid="JrQLj5P/89iXES9+vFgrIy29clF9CC/oPPsw3c5D0bs=";tag="sri"
 ```
 
 That's the string we'll sign, placing the base64-encoded signature into a
@@ -1185,10 +1185,10 @@ That's the string we'll sign, placing the base64-encoded signature into a
 HTTP/1.1 200 OK
 Date: Tue, 20 Apr 2021 02:07:56 GMT
 Content-Type: application/json
-Identity-Digest: sha-256=:X48E9qOokqqrvdts8nOJRJN3OWDUoyWxBf7kbu9DBPE=:
+Unencoded-Digest: sha-256=:X48E9qOokqqrvdts8nOJRJN3OWDUoyWxBf7kbu9DBPE=:
 Content-Length: 18
-Signature-Input: signature=("identity-digest";sf);keyid="JrQLj5P/89iXES9+vFgrIy29clF9CC/oPPsw3c5D0bs=";tag="sri"
-Signature: signature=:eTKYITprfJYJmsOZlRTmu0szHbt0yLxHYBU0oXDdkx8najLl59IPO0zUofe5T23RGuquHLdZx177tBX45CUcAg==:
+Signature-Input: signature=("unencoded-digest";sf);keyid="JrQLj5P/89iXES9+vFgrIy29clF9CC/oPPsw3c5D0bs=";tag="sri"
+Signature: signature=:gHim9e5Pk2H7c9BStOmxSmkyc8+ioZgoxynu3d4INAT4dwfj5LhvaV9DFnEQ9p7C0hzW4o4Qpkm5aApd6WLLCw==:
 
 {"hello": "world"}
 </xmp>