Skip to content

Commit 4884461

Browse files
tulshitulshi
authored
Interop profile (#133)
* added caep interoperability profile doc * incorporated feedback from Shayne and Apoorva * incorporated Apoorva\'s feedback to the pull request * renamed file and updated workflows * Revert "renamed file and updated workflows" This reverts commit fff6731. * renamed file back to using openid standard. Incorporated feedback from Apoorva and Shayne * added poll delivery reference * incorporated Tim\'s feedback
1 parent d418a5a commit 4884461

File tree

2 files changed

+204
-0
lines changed

2 files changed

+204
-0
lines changed

‎.github/workflows/build-everything.yml‎

Lines changed: 8 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -40,6 +40,12 @@ jobs:
4040
run: xml2rfc openid-caep-specification-1_0.xml --html -o openid-caep-specification-1_0.html
4141
- name: Render caep text
4242
run: xml2rfc openid-caep-specification-1_0.xml --text -o openid-caep-specification-1_0.txt
43+
- name: Convert caep-interop md to xml
44+
run: kramdown-rfc2629 openid-caep-interoperability-profile-1_0.md > openid-caep-interoperability-profile-1_0.xml
45+
- name: Render caep-interop html
46+
run: xml2rfc openid-caep-interoperability-profile-1_0.xml --html -o openid-caep-interoperability-profile-1_0.html
47+
- name: Render caep-interop text
48+
run: xml2rfc openid-caep-interoperability-profile-1_0.xml --text -o openid-caep-interoperability-profile-1_0.txt
4349
- name: Upload artifact
4450
uses: actions/upload-artifact@v2
4551
with:
@@ -51,6 +57,8 @@ jobs:
5157
openid-risc-profile-specification-1_0.txt
5258
openid-caep-specification-1_0.html
5359
openid-caep-specification-1_0.txt
60+
openid-caep-interoperability-profile-1_0.html
61+
openid-caep-interoperability-profile-1_0.txt
5462
publish-to-pages:
5563
if: github.ref == 'refs/heads/main'
5664
needs: [build-sharedsignals]

‎openid-caep-interoperability-profile-1_0.md‎

Lines changed: 196 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,196 @@
1+
---
2+
title: CAEP Interoperability Profile 1.0 - draft 01
3+
abbrev: caep-interop
4+
docname: caep-interoperability-profile-1_0
5+
date: 2023-11-17
6+
7+
ipr: none
8+
cat: std
9+
wg: Shared Signals
10+
11+
coding: us-ascii
12+
pi:
13+
toc: yes
14+
sortrefs: yes
15+
symrefs: yes
16+
private: yes
17+
18+
author:
19+
-
20+
ins: A. Tulshibagwale
21+
name: Atul Tulshibagwale
22+
org: SGNL
23+
email: atul@sgnl.ai
24+
25+
contributor:
26+
-
27+
ins: A. Deshpande
28+
name: Apoorva Deshpande
29+
org: Okta
30+
email: apoorva.deshpande@okta.com
31+
32+
normative:
33+
RFC9493: # Subject Identifier Formats for SETs
34+
RFC8935: # Push delivery
35+
RFC8936: # POLL delivery
36+
SSF:
37+
target: https://openid.net/specs/openid-sharedsignals-framework-1_0.html
38+
title: OpenID Shared Signals and Events Framework Specification 1.0 - draft 02
39+
author:
40+
-
41+
ins: A. Tulshibagwale
42+
name: Atul Tulshibagwale
43+
org: Google
44+
-
45+
ins: T. Cappalli
46+
name: Tim Cappalli
47+
org: Microsoft
48+
-
49+
ins: M. Scurtescu
50+
name: Marius Scurtescu
51+
org: Coinbase
52+
-
53+
ins: A. Backman
54+
name: Annabelle Backman
55+
org: Amazon
56+
-
57+
ins: J. Bradley
58+
name: John Bradley
59+
org: Yubico
60+
-
61+
ins: S. Miel
62+
name: Shayne Miel
63+
org: Cisco
64+
65+
CAEP:
66+
target: https://openid.net/specs/openid-caep-specification-1_0.html
67+
title: OpenID Continuous Access Evaluation Profile 1.0
68+
author:
69+
-
70+
ins: T. Cappalli
71+
name: Tim Cappalli
72+
org: Microsoft
73+
-
74+
ins: A. Tulshibagwale
75+
name: Atul Tulshibagwale
76+
org: SGNL
77+
78+
79+
--- abstract
80+
This document defines an interoperability profile for implementations of the Shared Signals Framework (SSF) {{SSF}} and the Continuous Access Evaluation Profile (CAEP) {{CAEP}}. It is organized around use-cases that improve security of authenticated sessions. It specifies certain optional elements from within the SSF and CAEP specifications as being required to be supported in order to be considered as an interoperable implementation.
81+
82+
--- middle
83+
84+
# Introduction {#introduction}
85+
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:
86+
87+
Session Revocation
88+
: A SSF Transmitter or Receiver is able to respectively generate or respond to the CAEP session-revoked event
89+
90+
Credential Change
91+
: A SSF Transmitter or Receiver is able to respectively generate or respond to the CAEP credential-change event
92+
93+
# Common Requirements {#common-requirements}
94+
The following requirements are common across all use-cases defined in this document.
95+
96+
## Transmitters {#common-transmitters}
97+
Transmitters MUST implement the following features:
98+
99+
### Spec Version {#spec-version}
100+
The Transmitter Configuration Metadata MUST have a `spec_version` field, and its value MUST be `1_0-ID2` or greater
101+
102+
### Delivery Method {#delivery-method}
103+
The Transmitter Configuration Metadata MUST include the `delivery_methods_supported` field.
104+
105+
### JWKS URI {#jwks-uri}
106+
The Transmitter Configuration Metadata MUST include the `jwks_uri` field, and its value MUST provide the current signing key of the Transmitter.
107+
108+
### Configuration Endpoint {#configuration-endpoint}
109+
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.
110+
111+
### Status Endpoint {#status-endpoint}
112+
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:
113+
114+
* `enabled`
115+
* `paused`
116+
* `disabled`
117+
118+
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.
119+
120+
### Verification Endpoint {#verification-endpoint}
121+
The Transmitter Configuration Metadata MUST include the `verification_endpoint` field. The specified endpoint MUST provide a way to request verification events to be sent.
122+
123+
### Authorization Schemes
124+
The Transmitter Configuration Metadata MUST include the `authorization_schemes` field and its value MUST include the value
125+
126+
~~~json
127+
{
128+
"spec_urn": "urn:ietf:rfc:6749"
129+
}
130+
~~~
131+
132+
### Streams {#common-stream-configuration}
133+
In all streams created by the Transmitter, the following MUST be true:
134+
135+
#### Delivery {#common-delivery}
136+
A Transmitter MUST be able to accept a Create Stream request that includes either of the following delivery methods:
137+
138+
* urn:ietf:rfc:8935 (Push)
139+
* urn:ietf:rfc:8936 (Poll)
140+
141+
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.
142+
143+
#### Stream Control
144+
The following Stream Configuration API Methods MUST be supported:
145+
146+
**Creating a Stream**
147+
: Receivers MUST be able to create a Stream with the Transmitter using valid authorization with the Transmitter. The Transmitter MAY support multiple streams with the same Receiver
148+
149+
**Reading Stream Configuration**
150+
: A Receiver MUST be able to obtain current Stream configuration from the Transmitter by providing a valid authorization
151+
152+
**Getting the Stream Status**
153+
: A Receiver MUST be able to obtain the current Stream status from the Transmitter by providing a valid authorization
154+
155+
**Stream Verification**
156+
: A Receiver MUST be able to verify the liveness of the Stream by requesting that the Transmitter send it a Stream Verificaiton event by providing a valid authorization
157+
158+
## Receivers {#common-receivers}
159+
Receivers MUST implement the following features:
160+
161+
### Delivery Methods {#common-receiver-delivery}
162+
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.
163+
164+
### Implicitly Added Subjects {#common-receiver-subjects}
165+
Receivers MUST assume that all subjects are implicitly included in a Stream, without any `AddSubject` method invocations.
166+
167+
## Event Subjects {#common-event-subjects}
168+
The following subject identifier formats from "Subject Identifiers for Security Event Tokens" {{RFC9493}} MUST be supported:
169+
170+
* `email`
171+
* `iss_sub`
172+
173+
Receivers MUST be prepared to accept events with any of the subject identifier formats specified in this section. Transmitters MUST be able to send events with at least one of subject identifier formats specified in this section.
174+
175+
## Event Signatures
176+
All events MUST be signed using the `RS256` algorithm using a minimum of 2048-bit keys.
177+
178+
# Use Cases
179+
Implementations MAY choose to support one or more of the following use-cases in order to be considered interoperable implementations
180+
181+
## Session Revocation / Logout
182+
In order to support session revocation or logout, implementations MUST support the CAEP event type `session-revoked`. The `reason_admin` field of the event MUST be populated with a non-empty value.
183+
184+
## Credential Change
185+
In order to support notifying and responding to credential changes, implementations MUST support the CAEP event type `credential-change`.
186+
Within the `credential-change` event, implementations MUST support the following field values:
187+
188+
`change_type`
189+
: Receivers MUST interpret all allowable values of this field. Transmitters MAY generate any allowable value of this field
190+
191+
`credential_type`
192+
: Receivers MUST interpret all allowable values of this field. Transmitters MAY generate any allowable value of this field
193+
194+
`reason_admin`
195+
: Transmitters MUST populate this value with a non-empty string
196+

0 commit comments

Comments
 (0)