merged main to branch

Author: tulshi

openid-sharedsignals-framework-1_0.html

@@ -1227,7 +1227,7 @@
 <thead><tr>
 <td class="left"></td>
 <td class="center">SharedSignals</td>
-<td class="right">March 2023</td>
+<td class="right">June 2023</td>
 </tr></thead>
 <tfoot><tr>
 <td class="left">Tulshibagwale, et al.</td>
@@ -1242,7 +1242,7 @@
 <dd class="workgroup">Shared Signals</dd>
 <dt class="label-published">Published:</dt>
 <dd class="published">
-<time datetime="2023-03-21" class="published">21 March 2023</time>
+<time datetime="2023-06-23" class="published">23 June 2023</time>
     </dd>
 <dt class="label-authors">Authors:</dt>
 <dd class="authors">
@@ -1733,22 +1733,22 @@ <h4 id="name-jwt-id-subject-identifier-f">
   in <span>[<a href="#RFC7519" class="cite xref">RFC7519</a>]</span><a href="#section-3.4.1-5.1.1" class="pilcrow">¶</a></p>
 </li>
           </ul>
-<p id="section-3.4.1-6">The "JWT ID" Subject Identifier Format is identified by the name "jwt-id".<a href="#section-3.4.1-6" class="pilcrow">¶</a></p>
-<p id="section-3.4.1-7">Below is a non-normative example of Subject Identifier for the "jwt-id" Subject
+<p id="section-3.4.1-6">The "JWT ID" Subject Identifier Format is identified by the name "jwt_id".<a href="#section-3.4.1-6" class="pilcrow">¶</a></p>
+<p id="section-3.4.1-7">Below is a non-normative example of Subject Identifier for the "jwt_id" Subject
 Identifier Format.<a href="#section-3.4.1-7" class="pilcrow">¶</a></p>
-<span id="name-example-jwt-id-subject-iden"></span><div id="sub-id-jwtid">
+<span id="name-example-jwt_id-subject-iden"></span><div id="sub-id-jwtid">
 <figure id="figure-3">
             <div class="lang-json sourcecode" id="section-3.4.1-8.1">
 <pre>
 {
-    "format": "jwt-id",
+    "format": "jwt_id",
     "iss": "https://idp.example.com/123456789/",
     "jti": "B70BA622-9515-4353-A866-823539EECBC8"
 }
 </pre>
 </div>
 <figcaption><a href="#figure-3" class="selfRef">Figure 3</a>:
-<a href="#name-example-jwt-id-subject-iden" class="selfRef">Example: 'jwt-id' Subject Identifier</a>
+<a href="#name-example-jwt_id-subject-iden" class="selfRef">Example: 'jwt_id' Subject Identifier</a>
             </figcaption></figure>
 </div>
 </section>
@@ -1822,7 +1822,7 @@ <h2 id="name-event-properties">
 of these members are required and specified as such in the respective event
 types specs. If a Transmitter determines that it needs to include additional
 members that are not specified in the event types spec, then the name of such
-members MUST be a URI. The discoverability of all additional members is 
+members MUST be a URI. The discoverability of all additional members is
 specified in the Discovery <a href="#discovery" class="auto internal xref">Section 6</a> section.<a href="#section-4-1" class="pilcrow">¶</a></p>
 </section>
 </div>
@@ -3039,7 +3039,7 @@ <h5 id="name-deleting-a-stream">
             </h5>
 <p id="section-7.1.1.5-1">An Event Receiver deletes a stream by making an HTTP DELETE request to the
 Configuration Endpoint. On receiving a request the Event Transmitter responds
-with an empty "204 OK" response if the configuration was successfully removed.<a href="#section-7.1.1.5-1" class="pilcrow">¶</a></p>
+with an empty "204 No Content" response if the configuration was successfully removed.<a href="#section-7.1.1.5-1" class="pilcrow">¶</a></p>
 <p id="section-7.1.1.5-2">The DELETE request MUST include the "stream_id" as a parameter in order to
 identify the correct Event Stream.<a href="#section-7.1.1.5-2" class="pilcrow">¶</a></p>
 <p id="section-7.1.1.5-3">The following is a non-normative example request to delete an Event Stream:<a href="#section-7.1.1.5-3" class="pilcrow">¶</a></p>

openid-sharedsignals-framework-1_0.md

@@ -2,7 +2,7 @@
 title: OpenID Shared Signals Framework Specification 1.0 - draft 02
 abbrev: SharedSignals
 docname: openid-sharedsignals-framework-1_0
-date: 2023-03-21
+date: 2023-06-23
 
 ipr: none
 cat: std
@@ -207,8 +207,8 @@ This spec also directly profiles several IETF Security Events drafts:
 
 * Security Event Token (SET) {{RFC8417}}
 * Subject Identifiers for Security Event Tokens {{SUBIDS}}
-* Push-Based SET Token Delivery Using HTTP {{DELIVERYPUSH}} 
-* Poll-Based SET Token Delivery Using HTTP {{DELIVERYPOLL}} 
+* Push-Based SET Token Delivery Using HTTP {{DELIVERYPUSH}}
+* Poll-Based SET Token Delivery Using HTTP {{DELIVERYPOLL}}
 
 --- middle
 
@@ -313,7 +313,7 @@ Below is a non-normative example of a Complex Subject claim in a SSF event.
     "sub" : "1234"
   }
 }
-~~~ 
+~~~
 {: #complex-subject-ex title="Example: Complex Subject"}
 
 ### Complex Subject Interpretation {#complex-subject-interpretation}
@@ -338,7 +338,7 @@ scope of this specification.
 
 ## Additional Subject Identifier Formats {#additional-subject-id-formats}
 
-The following new subject identifier formats are defined: 
+The following new subject identifier formats are defined:
 
 ### JWT ID Subject Identifier Format {#sub-id-jwt-id}
 
@@ -356,21 +356,21 @@ jti
 > REQUIRED. The "jti" (JWT token ID) claim of the JWT being identified, defined
   in {{RFC7519}}
 
-The "JWT ID" Subject Identifier Format is identified by the name "jwt-id".
+The "JWT ID" Subject Identifier Format is identified by the name "jwt_id".
 
-Below is a non-normative example of Subject Identifier for the "jwt-id" Subject
+Below is a non-normative example of Subject Identifier for the "jwt_id" Subject
 Identifier Format.
 
 ~~~ json
 {
-    "format": "jwt-id",
+    "format": "jwt_id",
     "iss": "https://idp.example.com/123456789/",
     "jti": "B70BA622-9515-4353-A866-823539EECBC8"
 }
 ~~~
-{: #sub-id-jwtid title="Example: 'jwt-id' Subject Identifier"}
+{: #sub-id-jwtid title="Example: 'jwt_id' Subject Identifier"}
 
-### SAML Assertion ID Subject Identifier Format {#sub-id-saml-assertion-id} 
+### SAML Assertion ID Subject Identifier Format {#sub-id-saml-assertion-id}
 
 The "SAML Assertion ID" Subject Identifier Format specifies a SAML 2.0
 {{OASIS.saml-core-2.0-os}} assertion identifier. Subject Identifiers of this
@@ -416,7 +416,7 @@ Additional members about an event may be included in the "events" claim. Some
 of these members are required and specified as such in the respective event
 types specs. If a Transmitter determines that it needs to include additional
 members that are not specified in the event types spec, then the name of such
-members MUST be a URI. The discoverability of all additional members is 
+members MUST be a URI. The discoverability of all additional members is
 specified in the Discovery {{discovery}} section.
 
 # Example SETs that conform to the Shared Signals Framework {#events-examples}
@@ -816,8 +816,8 @@ delivery
   parameters for the SET delivery method. The actual delivery method is
   identified by the special key "method" with the value being a URI as defined
   in {{delivery-meta}}. The value of the "delivery" field contains two
-  sub-fields: 
-  
+  sub-fields:
+
 >   method
 
 > > **Receiver-Supplied**, the specific delivery method to be used. This can be
@@ -1130,7 +1130,7 @@ Errors are signaled with HTTP status codes as follows:
 | 403  | if the Event Receiver is not allowed to read the stream configuration |
 | 404  | if there is no Event Stream with the given "stream_id" for this Event Receiver |
 {: title="Read Stream Configuration Errors" #tabreadconfig}
- 
+
 #### Updating a Stream’s Configuration {#updating-a-streams-configuration}
 An Event Receiver updates the current configuration of a stream by making an
 HTTP PATCH request to the Configuration Endpoint. The PATCH body contains a
@@ -1311,7 +1311,7 @@ Pending conditions or errors are signaled with HTTP status codes as follows:
 #### Deleting a Stream {#deleting-a-stream}
 An Event Receiver deletes a stream by making an HTTP DELETE request to the
 Configuration Endpoint. On receiving a request the Event Transmitter responds
-with an empty "204 OK" response if the configuration was successfully removed.
+with an empty "204 No Content" response if the configuration was successfully removed.
 
 The DELETE request MUST include the "stream_id" as a parameter in order to
 identify the correct Event Stream.
@@ -1676,14 +1676,14 @@ identified by a Phone Number Subject Identifier:
 POST /ssf/subjects:remove HTTP/1.1
 Host: transmitter.example.com
 Authorization: Bearer eyJ0b2tlbiI6ImV4YW1wbGUifQo=
-            
+
 {
   "stream_id": "f67e39a0a4d34d56b3aa1bc4cff0069f",
   "subject": {
     "format": "phone",
     "phone_number": "+12065550123"
   }
-}             
+}
 ~~~
 {: title="Example: Remove Subject Request" #figremovereq}
 
@@ -1707,7 +1707,7 @@ Errors are signaled with HTTP status codes as follows:
 | 429  | if the Event Receiver is sending too many requests in a given amount of time |
 {: title="Remove Subject Errors" #tabremoveerr}
 
-### Verification {#verification} 
+### Verification {#verification}
 In some cases, the frequency of event transmission on an Event Stream will be
 very low, making it difficult for an Event Receiver to tell the difference
 between expected behavior and event transmission failure due to a misconfigured
@@ -1720,7 +1720,7 @@ delivery is working, including signature verification and encryption.
 An Event Transmitter MAY send a Verification Event at any time, even if one was
 not requested by the Event Receiver.
 
-#### Verification Event {#verification-event} 
+#### Verification Event {#verification-event}
 The Verification Event is a standard SET with the following attributes:
 
 event type
@@ -1870,11 +1870,11 @@ subject
           "format": "iss_sub",
           "iss" : "http://example.com/idp1",
           "sub" : "1234"
-        }    
-      },   
+        }
+      },
       "status": "paused",
       "reason": "License is not valid"
-    }   
+    }
   }
 }
 ~~~
@@ -1888,9 +1888,9 @@ The receiver may obtain an access token using the Client
 Credential Grant {{CLIENTCRED}}, or any other method suitable for the Receiver and the
 Transmitter.
 
-# Security Considerations {#management-sec} 
+# Security Considerations {#management-sec}
 
-## Subject Probing {#management-sec-subject-probing} 
+## Subject Probing {#management-sec-subject-probing}
 It may be possible for an Event Transmitter to leak information about subjects
 through their responses to add subject requests. A "404" response may indicate
 to the Event Receiver that the subject does not exist, which may inadvertently
@@ -1904,7 +1904,7 @@ to the subject, and Event Receivers MUST NOT assume that a 204 response means
 that they will receive events related to the subject.
 
 
-## Information Harvesting {#management-sec-information-harvesting} 
+## Information Harvesting {#management-sec-information-harvesting}
 SETs may contain personally identifiable information (PII) or other non-public
 information about the event transmitter, the subject (of an event in the SET),
 or the relationship between the two. It is important for Event Transmitters to
@@ -1922,7 +1922,7 @@ transmitting the event. The mechanisms by which such validation is performed
 are outside the scope of this specification.
 
 
-## Malicious Subject Removal {#management-sec-malicious-subject-removal} 
+## Malicious Subject Removal {#management-sec-malicious-subject-removal}
 A malicious party may find it advantageous to remove a particular subject from a
 stream, in order to reduce the Event Receiver’s ability to detect malicious
 activity related to the subject, inconvenience the subject, or for other reasons.
@@ -1937,9 +1937,9 @@ from the stream, and MUST NOT report these events as errors to the Event
 Transmitter.
 
 
-# Privacy Considerations {#privacy-considerations} 
+# Privacy Considerations {#privacy-considerations}
 
-## Subject Information Leakage {#sub-info-leakage} 
+## Subject Information Leakage {#sub-info-leakage}
 Event issuers and recipients SHOULD take precautions to ensure that they do not
 leak information about subjects via Subject Identifiers, and choose appropriate
 Subject Identifier Types accordingly. Parties SHOULD NOT identify a subject
@@ -1950,34 +1950,34 @@ Identifier Type and the same claim values to identify a given subject when
 communicating with a given party in order to reduce the possibility of
 information leakage.
 
-## Previously Consented Data {#previously-consented-data} 
+## Previously Consented Data {#previously-consented-data}
 If SSF events contain new values for attributes of Subject Principals that were
 previously exchanged between the Transmitter and Receiver, then there are no
 additional privacy considerations introduced by providing the updated values in
 the SSF events, unless the attribute was exchanged under a one-time consent
 obtained from the user.
 
-## New Data {#new-data} 
+## New Data {#new-data}
 Data that was not previously exchanged between the Transmitter and the Receiver,
 or data whose consent to exchange has expired has the following considerations:
 
-### Organizational Data {#organizational-data} 
+### Organizational Data {#organizational-data}
 If a user has previously agreed with a Transmitter that they agree to release
 certain data to third-parties, then the Transmitter MAY send such data in SSF
 events without additional consent of the user. Such data MAY include
 organizational data about the Subject Principal that was generated by the
 Transmitter.
 
-### Consentable Data {#consentable-data} 
+### Consentable Data {#consentable-data}
 If a Transmitter intends to include data in SSF events that is not previously
 consented to be released by the user, then the Transmitter MUST obtain consent
 to release such data from the user in accordance with the Transmitter's privacy
 policy.
 
-# Profiles {#profiles} 
+# Profiles {#profiles}
 This section is a profile of the following IETF SecEvent specifications:
 
-* Security Event Token (SET) {{RFC8417}} 
+* Security Event Token (SET) {{RFC8417}}
 * Push-Based SET Token Delivery Using HTTP {{DELIVERYPUSH}}
 * Poll-Based SET Token Delivery Using HTTP {{DELIVERYPOLL}}
 
@@ -1987,20 +1987,20 @@ RISC Use Cases {{USECASES}}.
 The CAEP use cases that set the requirements are described in CAEP Use Cases (TODO: Add
         reference when file is added to repository.)
 
-## Security Event Token Profile {#set-profle} 
+## Security Event Token Profile {#set-profle}
 This section provides SSF profiling specifications for the Security Event Token (SET)
 {{RFC8417}} spec.
 
-### Signature Key Resolution {#signature-key-resolution} 
+### Signature Key Resolution {#signature-key-resolution}
 The signature key can be obtained through "jwks_uri", see {{discovery}}.
 
-### SSF Event Subject {#event-subjects} 
+### SSF Event Subject {#event-subjects}
 The subject of a SSF event is identified by the "subject" claim within the event
 payload, whose value is a Subject Identifier. The "subject" claim is REQUIRED
 for all SSF events. The JWT "sub" claim MUST NOT be present in any SET containing
 a SSF event.
 
-### SSF Event Properties {#event-properties} 
+### SSF Event Properties {#event-properties}
 The SSF event MAY contain additional claims within the event payload that are
 specific to the event type.
 
@@ -2043,7 +2043,7 @@ specific to the event type.
 ~~~
 {: #caep-event-properties-example title="Example: SET Containing a CAEP Event with Properties"}
 
-### Explicit Typing of SETs {#explicit-typing} 
+### Explicit Typing of SETs {#explicit-typing}
 SSF events MUST use explicit typing as defined in Section 2.3 of {{RFC8417}}.
 
 ~~~ json
@@ -2059,13 +2059,13 @@ Sections 4.5, 4.6 and 4.7 of {{RFC8417}}. While current Id Token {{IDTOKEN}}
 validators may not be using the "typ" header parameter, by requiring it for SSF
 SETs a distinct value is guaranteed for future validators.
 
-### The "exp" Claim {#exp-claim} 
+### The "exp" Claim {#exp-claim}
 The "exp" claim MUST NOT be used in SSF SETs.
 
 The purpose is defense in depth against confusion with other JWTs, as described
 in Sections 4.5 and 4.6 of {{RFC8417}}.
 
-### The "aud" Claim {#aud-claim} 
+### The "aud" Claim {#aud-claim}
 The "aud" claim can be a single value or an array. Each value SHOULD be the
 OAuth 2.0 client ID. Other values that uniquely identifies the Receiver to the
 Transmitter MAY be used, if the two parties have agreement on the format.
@@ -2097,7 +2097,7 @@ multiple Receivers would lead to unintended data disclosure.
 ~~~
 {: title="Example: SET with array 'aud' claim" #figarrayaud}
 
-### The "events" claim {#events-claim} 
+### The "events" claim {#events-claim}
 The "events" claim SHOULD contain only one event. Multiple event type URIs are
 permitted only if they are alternative URIs defining the exact same event type.
 
@@ -2116,7 +2116,7 @@ on this subject. The Shared Signals Framework is asking for further restrictions
 This section provides SSF profiling specifications for the {{DELIVERYPUSH}} and
 {{DELIVERYPOLL}} specs.
 
-### Stream Configuration Metadata {#delivery-meta} 
+### Stream Configuration Metadata {#delivery-meta}
 Each delivery method is identified by a URI, specified below by the "method"
 metadata.
 
@@ -2139,7 +2139,7 @@ authorization_header
 > The HTTP Authorization header that the Transmitter MUST set with each event
   delivery, if the configuration is present. The value is optional and it is set
   by the Receiver.
-  
+
 #### Polling Delivery using HTTP
 This section provides SSF profiling specifications for the {{DELIVERYPOLL}} spec.
 
@@ -2153,7 +2153,7 @@ url
   Transmitter. These URLs MAY be reused across Receivers, but MUST be unique per
   stream for a given Receiver.
 
-# IANA Considerations {#iana} 
+# IANA Considerations {#iana}
 Subject Identifiers defined in this document will be added to the "Security
 Events Subject Identifier Types" registry. This registry is defined in the
 Subject Identifiers for Security Event Tokens {{SUBIDS}} specification.