synced to updated main branch

Author: tulshi

.github/workflows/build-everything.yml

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

README.md

@@ -6,6 +6,17 @@ The goal of the [Shared Signals](http://openid.net/wg/sharedsignals/) Working Gr
 * Prevent malicious actors from leveraging compromises of accounts, devices, services, endpoints, or other principals or resources to gain unauthorized access to additional systems or resources.
 * Enable users, administrators, and service providers to coordinate in order to detect and respond to incidents.
 
+## Current Development Drafts
+The current drafts of the specifications under development are kept here:
+
+| Specification            | HTML    | TXT    |
+|--------------------------|---------|--------|
+| Shared Signals Framework | [HTML](https://openid.github.io/sharedsignals/openid-sharedsignals-framework-1_0.html)| [TXT](https://openid.github.io/sharedsignals/openid-sharedsignals-framework-1_0.txt)|
+| CAEP                     | [HTML](https://openid.github.io/sharedsignals/openid-caep-specification-1_0.html)| [TXT](https://openid.github.io/sharedsignals/openid-caep-specification-1_0.txt)|
+| RISC                     | [HTML](https://openid.github.io/sharedsignals/openid-risc-profile-specification-1_0.html)| [TXT](https://openid.github.io/sharedsignals/openid-risc-profile-specification-1_0.txt)|
+
+
+
 ## Development
 
 To change the spec, update one of the xml files and then run `make` as follows:
@@ -16,4 +27,6 @@ Similarly, to update the text file, you would run `make foo.txt`
 
 Pay attention to errors generating the files and warnings about the document date. You should update the date to today's date.
 
-In order to run `make` you need to install `xml2rfc` which can be done via pip: `pip install xml2rfc`
+In order to run `make` you need to:
+1. install `xml2rfc` which can be done via pip: `pip install xml2rfc`
+1. install `kramdown-rfc` which can be done via Ruby gems: `gem install kramdown-rfc`

openid-caep-specification-1_0.md

@@ -689,6 +689,7 @@ NOTE: The event type URI is wrapped, the backslash is the continuation character
 {: #device-compliance-change-examples-out-of-compliance title="Example: Device No Longer Compliant - Complex Subject + optional claims"}
 
 --- back
+
 # Acknowledgements
 
 The authors wish to thank all members of the OpenID Foundation Shared Signals

openid-risc-profile-specification-1_0.xml

@@ -116,7 +116,7 @@
       "subject": {
         "format": "iss_sub",
         "iss": "https://idp.example.com/",
-        "sub": "7375626A656374",
+        "sub": "7375626A656374"
       }
     }
   }
@@ -165,7 +165,7 @@
         "iss": "https://idp.example.com/",
         "sub": "7375626A656374",
       },
-      "reason": "hijacking",
+      "reason": "hijacking"
     }
   }
 }
@@ -217,9 +217,9 @@
     identifier-changed": {
       "subject": {
         "format": "email",
-        "email": "john.doe@example.com",
+        "email": "john.doe@example.com"
       },
-      "new-value": "john.roe@example.com",
+      "new-value": "john.roe@example.com"
     }
   }
 }
@@ -251,7 +251,7 @@
     identifier-recycled": {
       "subject": {
         "format": "email",
-        "email": "foo@example.com",
+        "email": "foo@example.com"
       }
     }
   }

openid-sharedsignals-framework-1_0.html

@@ -2874,7 +2874,8 @@ <h5 id="name-updating-a-streams-configur">
 request MUST NOT be changed by the Transmitter.<a href="#section-7.1.1.3-2" class="pilcrow">¶</a></p>
 <p id="section-7.1.1.3-3">Transmitter-Supplied properties beside the stream_id MAY be present,
 but they MUST match the expected value. Missing Transmitter-Supplied
-properties will be ignored by the Transmitter.<a href="#section-7.1.1.3-3" class="pilcrow">¶</a></p>
+properties MUST be ignored by the Transmitter. The <code>events_delivered</code> property,
+if present, MUST match the Transmitter's expected value before any updates are applied.<a href="#section-7.1.1.3-3" class="pilcrow">¶</a></p>
 <p id="section-7.1.1.3-4">The following is a non-normative example request to replace an Event Stream's
 configuration:<a href="#section-7.1.1.3-4" class="pilcrow">¶</a></p>
 <span id="name-example-update-stream-confi"></span><div id="figupdateconfigreq">
@@ -2997,7 +2998,8 @@ <h5 id="name-replacing-a-streams-configu">
 <span>[<a href="#RFC7159" class="cite xref">RFC7159</a>]</span> representation, then make a replacement request.<a href="#section-7.1.1.4-2" class="pilcrow">¶</a></p>
 <p id="section-7.1.1.4-3">Transmitter-Supplied properties besides the stream_id MAY be present,
 but they MUST match the expected value. Missing Transmitter-Supplied
-properties will be ignored by the Transmitter.<a href="#section-7.1.1.4-3" class="pilcrow">¶</a></p>
+properties MUST be ignored by the Transmitter. The <code>events_delivered</code> property,
+if present, MUST match the Transmitter's expected value <em>before</em> any updates are applied.<a href="#section-7.1.1.4-3" class="pilcrow">¶</a></p>
 <p id="section-7.1.1.4-4">The following is a non-normative example request to replace an Event Stream's
 configuration:<a href="#section-7.1.1.4-4" class="pilcrow">¶</a></p>
 <span id="name-example-replace-stream-conf"></span><div id="figreplaceconfigreq">
@@ -3023,7 +3025,7 @@ <h5 id="name-replacing-a-streams-configu">
     "urn:example:secevent:events:type_2",
     "urn:example:secevent:events:type_3",
     "urn:example:secevent:events:type_4"
-  ],
+  ]
 }
 </pre>
 </div>
@@ -3542,6 +3544,20 @@ <h4 id="name-subjects">
 <p id="section-7.1.3-1">An Event Receiver can indicate to an Event Transmitter whether or not the
 receiver wants to receive events about a particular subject by "adding" or
 "removing" that subject to the Event Stream, respectively.<a href="#section-7.1.3-1" class="pilcrow">¶</a></p>
+<p id="section-7.1.3-2">If a Receiver adds a subject to a stream, the Transmitter SHOULD send any events
+relating to the subject, which have event_types that the Receiver has subscribed to,
+and both the stream and the subject are enabled. In the case of Simple Subjects,
+two subjects match if they are exactly identical. For Complex Subjects, two subjects
+match if, for all fields in the Complex Subject (i.e. <code>user</code>, <code>group</code>, <code>device</code>, etc.),
+at least one of the following statements is true:<a href="#section-7.1.3-2" class="pilcrow">¶</a></p>
+<ol start="1" type="1" class="normal type-1" id="section-7.1.3-3">
+<li id="section-7.1.3-3.1">Subject 1's field is not defined<a href="#section-7.1.3-3.1" class="pilcrow">¶</a>
+</li>
+            <li id="section-7.1.3-3.2">Subject 2's field is not defined<a href="#section-7.1.3-3.2" class="pilcrow">¶</a>
+</li>
+            <li id="section-7.1.3-3.3">Subject 1's field is identical to Subject 2's field<a href="#section-7.1.3-3.3" class="pilcrow">¶</a>
+</li>
+          </ol>
 <div id="adding-a-subject-to-a-stream">
 <section id="section-7.1.3.1">
             <h5 id="name-adding-a-subject-to-a-strea">

openid-sharedsignals-framework-1_0.md

@@ -1207,7 +1207,8 @@ request MUST NOT be changed by the Transmitter.
 
 Transmitter-Supplied properties beside the stream_id MAY be present,
 but they MUST match the expected value. Missing Transmitter-Supplied
-properties will be ignored by the Transmitter.
+properties MUST be ignored by the Transmitter. The `events_delivered` property,
+if present, MUST match the Transmitter's expected value before any updates are applied.
 
 The following is a non-normative example request to replace an Event Stream’s
 configuration:
@@ -1292,7 +1293,8 @@ deleted. Event Receivers MAY read the configuration first, modify the JSON
 
 Transmitter-Supplied properties besides the stream_id MAY be present,
 but they MUST match the expected value. Missing Transmitter-Supplied
-properties will be ignored by the Transmitter.
+properties MUST be ignored by the Transmitter. The `events_delivered` property,
+if present, MUST match the Transmitter's expected value _before_ any updates are applied.
 
 The following is a non-normative example request to replace an Event Stream’s
 configuration:
@@ -1317,7 +1319,7 @@ Authorization: Bearer eyJ0b2tlbiI6ImV4YW1wbGUifQo=
     "urn:example:secevent:events:type_2",
     "urn:example:secevent:events:type_3",
     "urn:example:secevent:events:type_4"
-  ],
+  ]
 }
 ~~~
 {: title="Example: Replace Stream Configuration Request" #figreplaceconfigreq}
@@ -1648,6 +1650,19 @@ An Event Receiver can indicate to an Event Transmitter whether or not the
 receiver wants to receive events about a particular subject by “adding” or
 “removing” that subject to the Event Stream, respectively.
 
+If a Receiver adds a subject to a stream, the Transmitter SHOULD send any events
+relating to the subject, which have event_types that the Receiver has subscribed to,
+and both the stream and the subject are enabled. In the case of Simple Subjects,
+two subjects match if they are exactly identical. For Complex Subjects, two subjects
+match if, for all fields in the Complex Subject (i.e. `user`, `group`, `device`, etc.),
+at least one of the following statements is true:
+
+1. Subject 1's field is not defined
+
+2. Subject 2's field is not defined
+
+3. Subject 1's field is identical to Subject 2's field
+
 #### Adding a Subject to a Stream {#adding-a-subject-to-a-stream}
 To add a subject to an Event Stream, the Event Receiver makes an HTTP POST
 request to the Add Subject Endpoint, containing in the body a JSON object the