Remove Sec- prefixes

This is meaningless on the response headers, and on the
Sec-Session-Response, the server needs to carefully validate that the
expected key is being used anyway. It does seem kind of nice if the
server can trust that the Sec-Session-Id is truly coming from the site
instead of an XHR, so that it can look up the right expected public key
for the Sec-Session-Response, so we leave the Sec- prefix on that one
header. Following the discussion on
#59, we make the shared
prefix Secure-Session- instead.

Author: Daniel Rubery

spec.bs

@@ -190,7 +190,7 @@ In order to use DBSC, site owners need to establish two new endpoints:
 the registration endpoint and the refresh endpoint.
 
 The registration endpoint is contacted asynchronously after the browser receives
-the Sec-Session-Registration header. This endpoint should:
+the Secure-Session-Registration header. This endpoint should:
 - Serve the session config, including a new session id.
 - Persist and associate the request's public key with the session id.
 
@@ -201,7 +201,7 @@ cause browser agents to begin denial-of-service prevention mechanisms, or even
 terminate the session. Both could lead to future requests without bound
 cookies. The expected behavior of this endpoint is:
 - Look up the public key and recent challenges for the session by id.
-- Validate the Sec-Session-Response header has signed a recent challenge with
+- Validate the Secure-Session-Response header has signed a recent challenge with
   the correct key. Note that due to network latency and race conditions, it's
   possible to receive a signature for an old challenge after issuing a new
   challenge.
@@ -419,7 +419,7 @@ The <dfn>session credential</dfn> is a [=struct=] with the following
   Given a [=response=] (|response|), this algorithm updates the [=device bound
   session/cached challenge=] for a [=device bound session=].
 
-  1. Let |header name| be "<code>Sec-Session-Challenge</code>".
+  1. Let |header name| be "<code>Secure-Session-Challenge</code>".
   1. Let |challenge list| be the result of executing <a>get a structured
     field value</a> given |header name| and "list" from |response|’s
     [=response/header list=].
@@ -464,7 +464,7 @@ The <dfn>session credential</dfn> is a [=struct=] with the following
   1. Set |request|'s [=request/URL=] to |destination|.
   1. Set |request|'s [=request/header list=] to « ».
   1. If |signed challenge| is non-null, [=header list/append=] the header
-     ("Sec-Session-Response", |signed challenge|) to |request|'s
+     ("Secure-Session-Response", |signed challenge|) to |request|'s
      [=request/header list=].
   1. If |authorization| is non-null, [=header list/append=] the header
      ("Authorization", |authorization|) to |request|'s [=request/header list=].
@@ -545,7 +545,7 @@ The <dfn>session credential</dfn> is a [=struct=] with the following
 <div class="algorithm" data-algorithm="process-registration">
 To <dfn export id="create-session">create a new session</dfn> due to the
 [=response=] (|response|) to a [=request=] (|request|), do the following steps:
-  1. Let |header name| be "<code>Sec-Session-Registration</code>".
+  1. Let |header name| be "<code>Secure-Session-Registration</code>".
   1. Let |registration list| be the result of executing <a>get a structured
     field value</a> given |header name| and "list" from |response|’s
     [=response/header list=].
@@ -557,7 +557,7 @@ To <dfn export id="create-session">create a new session</dfn> due to the
     1. [=list/For each=] |algorithm| → |registration entry|
       1. If |algorithm| is not an <a>sf-token</a>, [=iteration/continue=].
       1. If |algorithm| represents a crypto algorithm supported in
-        [:Sec-Session-Registration:], and is supported on this client, add
+        [:Secure-Session-Registration:], and is supported on this client, add
         |algorithm| to |algorithm list|
     1. If |algorithm list| is empty, [=iteration/continue=].
     1. If |params|["path"] does not exist, or is not of type <a>sf-string</a>,
@@ -595,16 +595,16 @@ id="add-debug-header">add the debug header</dfn> to a [=request=]
 </div>
 
 # DBSC Formats # {#format}
-## \``Sec-Session-Registration`\` HTTP header field ## {#header-sec-session-registration}
-The \`<dfn export http-header id="sec-session-registration-header">
-<code>Sec-Session-Registration</code></dfn>\` header field can be used in a
+## \``Secure-Session-Registration`\` HTTP header field ## {#header-secure-session-registration}
+The \`<dfn export http-header id="secure-session-registration-header">
+<code>Secure-Session-Registration</code></dfn>\` header field can be used in a
 [=response=] by the server to start a new [=/device bound session=] on the
 client.
 
-[:Sec-Session-Registration:] is a List Structured Header [[RFC9651]]. Its ABNF
+[:Secure-Session-Registration:] is a List Structured Header [[RFC9651]]. Its ABNF
 is:
 
-<pre class="abnf">Sec-Session-Registration = <a>sf-list</a></pre>
+<pre class="abnf">Secure-Session-Registration = <a>sf-list</a></pre>
 
 Each item in the list must be an inner list, and each item in the inner list
 MUST be an <a>sf-token</a> representing a supported algorithm (ES256, RS256).
@@ -622,46 +622,46 @@ The following <a>sf-parameter</a>s are defined:
   <a>sf-string</a>. This <a>sf-parameter</a> will be copied into the
   registration JWT.
 
-<div class="example" id="sec-session-registration-example">
-  Some examples of [:Sec-Session-Registration:] from
+<div class="example" id="secure-session-registration-example">
+  Some examples of [:Secure-Session-Registration:] from
   https://example.com/login.html:
 
   ```html
   HTTP/1.1 200 OK
-  Sec-Session-Registration: (ES256);path="reg";challenge="cv";authorization="ac"
+  Secure-Session-Registration: (ES256);path="reg";challenge="cv";authorization="ac"
   ```
   ```html
   HTTP/1.1 200 OK
-  Sec-Session-Registration: (ES256 RS256);path="reg";challenge="cv"
+  Secure-Session-Registration: (ES256 RS256);path="reg";challenge="cv"
   ```
   ```html
   HTTP/1.1 200 OK
-  Sec-Session-Registration: (ES256);path="reg1";challenge="cv1";authorization="a"
-  Sec-Session-Registration: (RS256);path="reg2";challenge="cv2";authorization="b"
+  Secure-Session-Registration: (ES256);path="reg1";challenge="cv1";authorization="a"
+  Secure-Session-Registration: (RS256);path="reg2";challenge="cv2";authorization="b"
   ```
   ```html
   HTTP/1.1 200 OK
-  Sec-Session-Registration: (ES256);path="reg1";challenge="cv1";authorization="a", (RS256);path="reg2";challenge="cv2";authorization="b"
+  Secure-Session-Registration: (ES256);path="reg1";challenge="cv1";authorization="a", (RS256);path="reg2";challenge="cv2";authorization="b"
   ```
 </div>
 
-## \``Sec-Session-Challenge`\` HTTP Header Field ## {#header-sec-session-challenge}
-The \`<dfn export http-header id="sec-session-challenge-header">
-<code>Sec-Session-Challenge</code></dfn>\` header field can be used in a
+## \``Secure-Session-Challenge`\` HTTP Header Field ## {#header-secure-session-challenge}
+The \`<dfn export http-header id="secure-session-challenge-header">
+<code>Secure-Session-Challenge</code></dfn>\` header field can be used in a
 [=response=] by the server to send a challenge to the client that it expects to
-be used in future Sec-Session-Response headers inside the [=DBSC proof=], or to
+be used in future Secure-Session-Response headers inside the [=DBSC proof=], or to
 request a newly signed [=DBSC proof=] right away if the [=response/status=]
 is 403.
 
-[:Sec-Session-Challenge:] is a structured header. Its value must be a string.
+[:Secure-Session-Challenge:] is a structured header. Its value must be a string.
 Its ABNF is: <pre class="abnf">SecSessionChallenge = <a>sf-string</a></pre>
 The semantics of the item are defined in
 [[#challenge-structured-header-serialization]].
 
 The processing steps are defined in [[#algo-process-challenge]].
 
-### Sec-Session-Challenge structured header serialization ### {#challenge-structured-header-serialization}
-The [:Sec-Session-Challenge:] is represented as a Structured Field.[[!RFC9651]]
+### Secure-Session-Challenge structured header serialization ### {#challenge-structured-header-serialization}
+The [:Secure-Session-Challenge:] is represented as a Structured Field.[[!RFC9651]]
 
 In this representation, a challenge is represented by a string.
 
@@ -673,68 +673,68 @@ Note: The server might need to use this header to request the [=DBSC proof=] to
 be signed with a new challenge before a session id has been assigned. In this
 case the session ID is optional.
 
-<div class="example" id="sec-session-challenge-example">
-  Some examples of [:Sec-Session-Challenge:] from
+<div class="example" id="secure-session-challenge-example">
+  Some examples of [:Secure-Session-Challenge:] from
   https://example.com/login.html:
 
   ```html
   HTTP/1.1 403 Forbidden
-  Sec-Session-Challenge: "new challenge"
+  Secure-Session-Challenge: "new challenge"
   ```
   ```html
   HTTP/1.1 403 Forbidden
-  Sec-Session-Challenge: "new challenge";id="my session"
+  Secure-Session-Challenge: "new challenge";id="my session"
   ```
   ```html
   HTTP/1.1 200 OK
-  Sec-Session-Challenge: "new challenge";id="my session"
+  Secure-Session-Challenge: "new challenge";id="my session"
   ```
   ```html
   HTTP/1.1 200 OK
-  Sec-Session-Challenge: "new challenge";id="my session 1"
-  Sec-Session-Challenge: "another challenge";id="my session 2"
+  Secure-Session-Challenge: "new challenge";id="my session 1"
+  Secure-Session-Challenge: "another challenge";id="my session 2"
   ```
   ```html
   HTTP/1.1 200 OK
-  Sec-Session-Challenge: "c1";id="session 1", "c2";id="session 2"
+  Secure-Session-Challenge: "c1";id="session 1", "c2";id="session 2"
   ```
 </div>
 
-## `Sec-Session-Response` HTTP Header Field ## {#header-sec-session-response}
-The \`<dfn export http-header id="sec-session-response-header">
-<code>Sec-Session-Response</code></dfn>\` header field can be used in the
+## `Secure-Session-Response` HTTP Header Field ## {#header-secure-session-response}
+The \`<dfn export http-header id="secure-session-response-header">
+<code>Secure-Session-Response</code></dfn>\` header field can be used in the
 [=request=] by the user agent to send a [=DBSC proof=] to the server to prove
 that the client is still in possession of the private key of the session key.
 
-\`<a http-header><code>Sec-Session-Response</code></a>\` is a structured
+\`<a http-header><code>Secure-Session-Response</code></a>\` is a structured
 header. Its value must be a string. It's ABNF is:
 <pre class="abnf">SecSessionChallenge = <a>sf-string</a></pre>
 This string MUST only contain the [=DBSC proof=] JWT. Any <a>sf-parameter</a>s SHOULD be
 ignored.
 
-<div class="example" id="sec-session-response-example">
+<div class="example" id="secure-session-response-example">
   ```html
   POST example.com/refresh
-  Sec-Session-Response: "eyJhbGciOiJFUzI1NiIsInR5cCI6ImRic2Mrand0In0.eyJhdWQiOiJodHRwczovL2V4YW1wbGUuY29tL3JlZyIsImp0aSI6ImN2IiwiaWF0IjoiMTcyNTU3OTA1NSIsImp3ayI6eyJrdHkiOiJFQyIsImNydiI6IlAtMjU2IiwieCI6IjZfR0Iydm9RMHFyb01oNk9sREZDRlNfU0pyaVFpMVBUdnZCT2hHWjNiSEkiLCJ5IjoiSWVnT0pVTHlFN1N4SF9DZDFLQ0VSN2xXQnZHRkhRLWgweHlqelVqRUlXRSJ9LCJhdXRob3JpemF0aW9uIjoiYWMifQ.6Fb_vVBDmfNghQiBmIGe8o7tBfYPbPCywhQruP0vIhxgmcJmuNTaMHeVn_M8ZnOm1_bzIitbZqCWEn-1Qzmtyw"
+  Secure-Session-Response: "eyJhbGciOiJFUzI1NiIsInR5cCI6ImRic2Mrand0In0.eyJhdWQiOiJodHRwczovL2V4YW1wbGUuY29tL3JlZyIsImp0aSI6ImN2IiwiaWF0IjoiMTcyNTU3OTA1NSIsImp3ayI6eyJrdHkiOiJFQyIsImNydiI6IlAtMjU2IiwieCI6IjZfR0Iydm9RMHFyb01oNk9sREZDRlNfU0pyaVFpMVBUdnZCT2hHWjNiSEkiLCJ5IjoiSWVnT0pVTHlFN1N4SF9DZDFLQ0VSN2xXQnZHRkhRLWgweHlqelVqRUlXRSJ9LCJhdXRob3JpemF0aW9uIjoiYWMifQ.6Fb_vVBDmfNghQiBmIGe8o7tBfYPbPCywhQruP0vIhxgmcJmuNTaMHeVn_M8ZnOm1_bzIitbZqCWEn-1Qzmtyw"
   ```
 </div>  
 
-## `Sec-Session-Id` HTTP Header Field ## {#header-sec-session-id}
-The \`<dfn export http-header id="sec-session-id-header">
-<code>Sec-Session-Id</code></dfn>\` header field can be used in the
+## `Sec-Secure-Session-Id` HTTP Header Field ## {#header-sec-secure-session-id}
+The \`<dfn export http-header id="sec-secure-session-id-header">
+<code>Sec-Secure-Session-Id</code></dfn>\` header field can be used in the
 [=request=] by the user agent to request the current session is refreshed, 
 with the current session identifier as a string argument.
 
-\`<a http-header><code>Sec-Session-Id</code></a>\` is a structured header.
+\`<a http-header><code>Sec-Secure-Session-Id</code></a>\` is a structured header.
 Its value must be a string. It's ABNF is:
 <pre class="abnf">SecSessionChallenge = <a>sf-string</a></pre>
 This string MUST only contain the session identifier. Any parameters SHOULD be
 ignored.
 
-<div class="example" id="sec-session-id-example">
+<div class="example" id="sec-secure-session-id-example">
   ```html
   POST example.com/refresh
-  Sec-Session-Id: "session-id"
+  Sec-Secure-Session-Id: "session-id"
   ```
 </div>
 
@@ -793,7 +793,7 @@ At the root of the JSON object, the following keys can exist:
   :: a [=boolean=] describing the wanted session behavior during a session
     refresh. If this value is true all requests related to this session will be
     deferred while the session is refreshed. If instead the value is false every
-    request will instead be sent as normal, but with a [:Sec-Session-Response:]
+    request will instead be sent as normal, but with a [:Secure-Session-Response:]
     header containing the [=DBSC proof=].
     This key is OPTIONAL, and if not present a value of true is default.
 
@@ -816,7 +816,7 @@ At the root of the JSON object, the following keys can exist:
     [[#algo-request-in-scope]] for details.
 </dl>
 
-<div class="example" id="sec-session-instruction-example">
+<div class="example" id="secure-session-instruction-example">
   ```json
   {
     "session_identifier": "session_id",
@@ -948,11 +948,11 @@ The payload of [=DBSC proof=] MUST contain at least the following claims:
 </dl>
 
 In addition the following claims MUST be present if present in
-[:Sec-Session-Registration:]:
+[:Secure-Session-Registration:]:
 <dl dfn-for="DBSC proof">
   : <dfn>authorization</dfn>
   :: a [=string=], direct copy of the string from
-    [:Sec-Session-Registration:], if set there. Note that this string is
+    [:Secure-Session-Registration:], if set there. Note that this string is
     OPTIONAL to include in the header, but if it is present it is
     MANDATORY for clients to add the claim in the [=DBSC proof=].
 </dl>
@@ -991,7 +991,7 @@ present:
   Based on this response header from the server:
   ```html
   HTTP/1.1 200 OK
-  Sec-Session-Registration: (ES256);path="reg";challenge="cv";authorization="ac"
+  Secure-Session-Registration: (ES256);path="reg";challenge="cv";authorization="ac"
   ```
   received on a response from ```http://example.com/page.html```
 </div>
@@ -1028,10 +1028,10 @@ registered domain.
 The permanent message header field registry should be updated with the following
 registrations: [[!RFC3864]]
 
-## Sec-Session-Challenge ## {#iana-ses-session-challenge}
+## Secure-Session-Challenge ## {#iana-ses-session-challenge}
 <dl>
   <dt>Header field name</dt>
-  <dd>Sec-Session-Challenge</dd>
+  <dd>Secure-Session-Challenge</dd>
 
   <dt>Applicable protocol</dt>
   <dd>http</dd>
@@ -1043,13 +1043,13 @@ registrations: [[!RFC3864]]
   <dd>W3C</dd>
 
   <dt>Specification document</dt>
-  <dd>This specification (See [[#header-sec-session-challenge]])</dd>
+  <dd>This specification (See [[#header-secure-session-challenge]])</dd>
 </dl>
 
-## Sec-Session-Id ## {#iana-ses-session-id}
+## Sec-Secure-Session-Id ## {#iana-sec-secure-session-id}
 <dl>
   <dt>Header field name</dt>
-  <dd>Sec-Session-Id</dd>
+  <dd>Sec-Secure-Session-Id</dd>
 
   <dt>Applicable protocol</dt>
   <dd>http</dd>
@@ -1061,13 +1061,13 @@ registrations: [[!RFC3864]]
   <dd>W3C</dd>
 
   <dt>Specification document</dt>
-  <dd>This specification (See [[#header-sec-session-id]])</dd>
+  <dd>This specification (See [[#header-sec-secure-session-id]])</dd>
 </dl>
 
-## Sec-Session-Registration ## {#iana-sec-session-registration}
+## Secure-Session-Registration ## {#iana-secure-session-registration}
 <dl>
   <dt>Header field name</dt>
-  <dd>Sec-Session-Registration</dd>
+  <dd>Secure-Session-Registration</dd>
 
   <dt>Applicable protocol</dt>
   <dd>http</dd>
@@ -1079,13 +1079,13 @@ registrations: [[!RFC3864]]
   <dd>W3C</dd>
 
   <dt>Specification document</dt>
-  <dd>This specification (See [[#header-sec-session-registration]])</dd>
+  <dd>This specification (See [[#header-secure-session-registration]])</dd>
 </dl>
 
-## Sec-Session-Response ## {#iana-sec-session-response}
+## Secure-Session-Response ## {#iana-secure-session-response}
 <dl>
   <dt>Header field name</dt>
-  <dd>Sec-Session-Response</dd>
+  <dd>Secure-Session-Response</dd>
 
   <dt>Applicable protocol</dt>
   <dd>http</dd>
@@ -1097,7 +1097,7 @@ registrations: [[!RFC3864]]
   <dd>W3C</dd>
 
   <dt>Specification document</dt>
-  <dd>This specification (See [[#header-sec-session-response]])</dd>
+  <dd>This specification (See [[#header-secure-session-response]])</dd>
 </dl>
 
 ## Secure-Session-Skipped ## {#iana-secure-session-skipped}