renamed file back to using openid standard. Incorporated feedback from Apoorva and Shayne

Author: tulshi

.github/workflows/build-everything.yml

@@ -41,11 +41,11 @@ jobs:
       - name: Render caep text
         run: xml2rfc openid-caep-specification-1_0.xml --text -o openid-caep-specification-1_0.txt
       - name: Convert caep-interop md to xml
-        run: kramdown-rfc2629 caep-interoperability-profile-1_0.md > caep-interoperability-profile-1_0.xml
+        run: kramdown-rfc2629 openid-caep-interoperability-profile-1_0.md > openid-caep-interoperability-profile-1_0.xml
       - name: Render caep-interop html
-        run: xml2rfc caep-interoperability-profile-1_0.xml --html -o caep-interoperability-profile-1_0.html
+        run: xml2rfc openid-caep-interoperability-profile-1_0.xml --html -o openid-caep-interoperability-profile-1_0.html
       - name: Render caep-interop text
-        run: xml2rfc caep-interoperability-profile-1_0.xml --text -o caep-interoperability-profile-1_0.txt
+        run: xml2rfc openid-caep-interoperability-profile-1_0.xml --text -o openid-caep-interoperability-profile-1_0.txt
       - name: Upload artifact
         uses: actions/upload-artifact@v2
         with:
@@ -57,8 +57,8 @@ jobs:
             openid-risc-profile-specification-1_0.txt
             openid-caep-specification-1_0.html
             openid-caep-specification-1_0.txt
-            caep-interoperability-profile-1_0.html
-            caep-interoperability-profile-1_0.txt
+            openid-caep-interoperability-profile-1_0.html
+            openid-caep-interoperability-profile-1_0.txt
   publish-to-pages:
     if: github.ref == 'refs/heads/main'
     needs: [build-sharedsignals]

caep-interoperability-profile-1_0.md renamed to openid-caep-interoperability-profile-1_0.md

@@ -32,8 +32,8 @@ contributor:
 normative:
   RFC9493: # Subject Identifier Formats for SETs
   SSF:
-    target: http://openid.net/specs/openid-sse-framework-1_0.html
-    title: OpenID Shared Signals and Events Framework Specification 1.0
+    target: https://openid.net/specs/openid-sharedsignals-framework-1_0.html
+    title: OpenID Shared Signals and Events Framework Specification 1.0 - draft 02
     author:
       -
         ins: A. Tulshibagwale
@@ -52,9 +52,14 @@ normative:
         name: Annabelle Backman
         org: Amazon
       -
-        ins: John Bradley
+        ins: J. Bradley
         name: John Bradley
         org: Yubico
+      -
+        ins: S. Miel
+        name: Shayne Miel
+        org: Cisco
+
   CAEP:
     target: https://openid.net/specs/openid-caep-specification-1_0.html
     title: OpenID Continuous Access Evaluation Profile 1.0
@@ -76,7 +81,7 @@ This document defines an interoperability profile for implementations of the Sha
 --- middle
 
 # Introduction {#introduction}
-SSF and CAEP together enable improved session security outcomes. This specification defines the minimum required features from SSF and CAEP that an implementation MUST offer in order to be considered as an interoperable implementation. This document defines specific use cases. An implementation may support only a subset of the use cases defined herein, and SHALL be considered an interoperable implementation for the specific use-cases it supports. The following use-cases are considered as a part of this specification:
+SSF and CAEP together enable improved session security outcomes. This specification defines the minimum required features from SSF and CAEP that an implementation MUST offer in order to be considered as an interoperable implementation. This document defines specific use cases. An implementation MAY support only a subset of the use cases defined herein, and SHALL be considered an interoperable implementation for the specific use-cases it supports. The following use-cases are considered as a part of this specification:
 
 Session Revocation
 : A SSF Transmitter or Receiver is able to respectively generate or respond to the CAEP session-revoked event
@@ -100,10 +105,16 @@ The Transmitter Configuration Metadata MUST include the `delivery_methods_suppor
 The Transmitter Configuration Metadata MUST include the `jwks_uri` field, and its value MUST provide the current signing key of the Transmitter.
 
 ### Configuration Endpoint {#configuration-endpoint}
-The Transmitter Configuration Metadata MUST include the `configuration_endpoint` field. The specified endpoint MUST provide a way to Create a Stream.
+The Transmitter Configuration Metadata MUST include the `configuration_endpoint` field. The specified endpoint MUST support the `POST` method in order to be able to create a stream.
 
 ### Status Endpoint {#status-endpoint}
-The Transmitter Configuration Metadata MUST include the `status_endpoint` field. The specified endpoint MUST provide a way to Get and Update the Stream Status. The Transmitter MUST be able to pause and restart streams. For streams that are paused, the Transmitter MUST specify (offline) the resource constraints on how many events it can keep, or for how long. The way a Transmitter specifies this information is outside the scope of the SSF spec.
+The Transmitter Configuration Metadata MUST include the `status_endpoint` field. The specified endpoint MUST support the `GET` and `POST` methods in order to get and update the stream status respectively. The Transmitter MUST support the following values in an Update Stream Status request:
+
+* `enabled`
+* `paused`
+* `disabled`
+
+For streams that are `paused`, the Transmitter MUST specify (offline) the resource constraints on how many events it can keep, or for how long. The way a Transmitter specifies this information is outside the scope of the SSF spec.
 
 ### Verification Endpoint {#verification-endpoint}
 The Transmitter Configuration Metadata MUST include the `verification_endpoint` field. The specified endpoint MUST provide a way to request verification events to be sent.
@@ -121,13 +132,12 @@ The Transmitter Configuration Metadata MUST include the `authorization_schemes`
 In all streams created by the Transmitter, the following MUST be true:
 
 #### Delivery {#common-delivery}
-The `delivery` field MUST be present in the Configuration of any Stream generated by the Transmitter, and its value MUST include the following:
+A Transmitter MUST be able to accept a Create Stream request that includes either of the following delivery methods:
 
-~~~ json
-{
-    "method" : "urn:ietf:rfc:8935"
-}
-~~~
+* urn:ietf:rfc:8935 (Push)
+* urn:ietf:rfc:8936 (Poll)
+
+The `delivery` field MUST be present in the Configuration of any Stream generated by the Transmitter, and its value MUST include one of the two delivery methods listed above.
 
 #### Stream Control
 The following Stream Configuration API Methods MUST be supported:
@@ -147,8 +157,8 @@ The following Stream Configuration API Methods MUST be supported:
 ## Receivers {#common-receivers}
 Receivers MUST implement the following features:
 
-### Push Delivery {#common-receiver-push}
-Receivers MUST be able to accept events using the Push-Based Security Event Token (SET) Delivery Using HTTP {{RFC8935}} specification.
+### Delivery Methods {#common-receiver-delivery}
+Receivers MUST be able to accept events using the Push-Based Security Event Token (SET) Delivery Using HTTP {{RFC8935}} specification and the Poll-Based Security Event Token (SET) Delivery Using HTTP {{RFC8936}} specification.
 
 ### Implicitly Added Subjects {#common-receiver-subjects}
 Receivers MUST assume that all subjects are implicitly included in a Stream, without any `AddSubject` method invocations.