Skip to content

Commit dd60cac

Browse files
tulshitulshi
committed
added caep interoperability profile doc
1 parent d418a5a commit dd60cac

File tree

2 files changed

+181
-0
lines changed

2 files changed

+181
-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 caep-interoperability-profile-1_0.md > caep-interoperability-profile-1_0.xml
45+
- name: Render caep-interop html
46+
run: xml2rfc caep-interoperability-profile-1_0.xml --html -o caep-interoperability-profile-1_0.html
47+
- name: Render caep-interop text
48+
run: xml2rfc caep-interoperability-profile-1_0.xml --text -o 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+
caep-interoperability-profile-1_0.html
61+
caep-interoperability-profile-1_0.txt
5462
publish-to-pages:
5563
if: github.ref == 'refs/heads/main'
5664
needs: [build-sharedsignals]

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

Lines changed: 173 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,173 @@
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+
normative:
26+
SSF:
27+
target: http://openid.net/specs/openid-sse-framework-1_0.html
28+
title: OpenID Shared Signals and Events Framework Specification 1.0
29+
author:
30+
-
31+
ins: A. Tulshibagwale
32+
name: Atul Tulshibagwale
33+
org: Google
34+
-
35+
ins: T. Cappalli
36+
name: Tim Cappalli
37+
org: Microsoft
38+
-
39+
ins: M. Scurtescu
40+
name: Marius Scurtescu
41+
org: Coinbase
42+
-
43+
ins: A. Backman
44+
name: Annabelle Backman
45+
org: Amazon
46+
-
47+
ins: John Bradley
48+
name: John Bradley
49+
org: Yubico
50+
CAEP:
51+
target: https://openid.net/specs/openid-caep-specification-1_0.html
52+
title: OpenID Continuous Access Evaluation Profile 1.0
53+
author:
54+
-
55+
ins: T. Cappalli
56+
name: Tim Cappalli
57+
org: Microsoft
58+
-
59+
ins: A. Tulshibagwale
60+
name: Atul Tulshibagwale
61+
org: SGNL
62+
RFC8935:
63+
64+
65+
--- abstract
66+
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.
67+
68+
--- middle
69+
70+
# Introduction {#introduction}
71+
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:
72+
73+
Session Revocation
74+
: A CAEP Transmitter or Receiver is able to respectively generate or respond to the CAEP session-revoked event
75+
76+
Credential Change
77+
: A CAEP Transmitter or Receiver is able to respectively generate or respond to the CAEP credential-change event
78+
79+
# Definitions
80+
CAEP Transmitter
81+
: A SSF Transmitter that supports generating least one event type defined in the CAEP specification.
82+
83+
CAEP Receiver
84+
: A SSF Receiver that supports receiving at least one event type defined in the CAEP specification.
85+
86+
# Common Requirements {#common-requirements}
87+
The following requirements are common across all use-cases defined in this document.
88+
89+
## Transmitters {#common-transmitters}
90+
Transmitters MUST implement the following features:
91+
92+
### Spec Version {#spec-version}
93+
The Transmitter Configuration Metadata MUST have a `spec_version` field, and its value MUST be `1_0-ID2` or greater
94+
95+
### Delivery Method {#delivery-method}
96+
The Transmitter Configuration Metadata MUST include the `delivery_methods_supported` field and its value MUST include the value `urn:ietf:rfc:8935` (i.e. the Push-Based Security Event Token (SET) Delivery Using HTTP specificaiton {{RFC8935}})
97+
98+
### Authorization Schemes
99+
The Transmitter Configuration Metadata MUST include the `authorization_schemes` field and its value MUST include the value
100+
101+
~~~json
102+
{
103+
"spec_urn": "urn:ietf:rfc:6749"
104+
}
105+
~~~
106+
107+
### Streams {#common-stream-configuration}
108+
In all streams created by the Transmitter, the following MUST be true:
109+
110+
#### Delivery {#common-delivery}
111+
The `delivery` field MUST be present in the Configuration of any Stream generated by the Transmitter, and its value MUST include the following:
112+
113+
~~~ json
114+
{
115+
"method" : "urn:ietf:rfc:8935"
116+
}
117+
~~~
118+
119+
#### Stream Control
120+
The following Stream Configuration API Methods MUST be supported:
121+
122+
**Creating a Stream**
123+
: 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
124+
125+
**Reading Stream Configuration**
126+
: A Receiver MUST be able to obtain current Stream configuration from the Transmitter by providing a valid authorization
127+
128+
**Getting the Stream Status**
129+
: A Receiver MUST be able to obtain the current Stream status from the Transmitter by providing a valid authorization
130+
131+
**Stream Verification**
132+
: A Receiver MUST be able to verify the liveness of the Stream by requesting that the Transmitter send it a Stream Verificaiton event
133+
134+
## Receivers {#common-receivers}
135+
Receivers MUST implement the following features:
136+
137+
### Push Delivery {#common-receiver-push}
138+
Receivers MUST be able to accept events using the Push-Based Security Event Token (SET) Delivery Using HTTP {{RFC8935}} specification.
139+
140+
### Implicitly Added Subjects {#common-receiver-subjects}
141+
Receivers MUST assume that all subjects are implicitly included in a Stream, without any `AddSubject` method invocations.
142+
143+
## Event Subjects {#common-event-subjects}
144+
Subjects of all events MUST support the `email` Simple Subject format.
145+
146+
## Event Signatures
147+
All events MUST be signed using the `RS256` algorithm using a minimum of 2048-bit keys.
148+
149+
# Use Cases
150+
Implementations MAY choose to support one or more of the following use-cases in order to be considered interoperable implementations
151+
152+
## Session Revocation / Logout
153+
In order to support session revocation or logout, implementations MUST support the CAEP event type `session-revoked`.
154+
155+
## Credential Change
156+
In order to support notifying and responding to credential changes, implementations MUST support the CAEP event type `credential-change`.
157+
Within the `credential-change` event, implementations MUST support the following field values:
158+
159+
`change_type`
160+
: Receivers MUST interpret all allowable values of this field. Transmitters MAY generate any allowable value of this field
161+
162+
`credential_type`
163+
: Receivers MUST interpret the following values of this field. Transmitters MAY generate any of the following values:
164+
165+
* `password`
166+
* `pin`
167+
* `fido2-platform`
168+
* `fido2-roaming`
169+
* `fido2-u2f`
170+
171+
172+
173+

0 commit comments

Comments
 (0)