caep-interop November 2023
Tulshibagwale Standards Track [Page]
Workgroup:
Shared Signals
Published:
Author:
A. Tulshibagwale
SGNL

CAEP Interoperability Profile 1.0 - draft 01

Abstract

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.

▲

Table of Contents

1. 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:

Session Revocation

A SSF Transmitter or Receiver is able to respectively generate or respond to the CAEP session-revoked event

Credential Change

A SSF Transmitter or Receiver is able to respectively generate or respond to the CAEP credential-change event

2. Common Requirements

The following requirements are common across all use-cases defined in this document.

2.1. Transmitters

Transmitters MUST implement the following features:

2.1.1. Spec Version

The Transmitter Configuration Metadata MUST have a spec_version field, and its value MUST be 1_0-ID2 or greater

2.1.2. Delivery Method

The Transmitter Configuration Metadata MUST include the delivery_methods_supported field.

2.1.3. JWKS URI

The Transmitter Configuration Metadata MUST include the jwks_uri field, and its value MUST provide the current signing key of the Transmitter.

2.1.4. Configuration Endpoint

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.

2.1.5. Status Endpoint

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.

2.1.6. 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.

2.1.7. Authorization Schemes

The Transmitter Configuration Metadata MUST include the authorization_schemes field and its value MUST include the value

{
    "spec_urn": "urn:ietf:rfc:6749"
}

2.1.8. Streams

In all streams created by the Transmitter, the following MUST be true:

2.1.8.1. Delivery

A Transmitter MUST be able to accept a Create Stream request that includes either of the following delivery methods:

  • 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.

2.1.8.2. Stream Control

The following Stream Configuration API Methods MUST be supported:

Creating a Stream

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

Reading Stream Configuration

A Receiver MUST be able to obtain current Stream configuration from the Transmitter by providing a valid authorization

Getting the Stream Status

A Receiver MUST be able to obtain the current Stream status from the Transmitter by providing a valid authorization

Stream Verification

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

2.2. Receivers

Receivers MUST implement the following features:

2.2.1. Delivery Methods

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.

2.2.2. Implicitly Added Subjects

Receivers MUST assume that all subjects are implicitly included in a Stream, without any AddSubject method invocations.

2.3. Event Subjects

The following subject identifier formats from "Subject Identifiers for Security Event Tokens" [RFC9493] MUST be supported:

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.

2.4. Event Signatures

All events MUST be signed using the RS256 algorithm using a minimum of 2048-bit keys.

3. Use Cases

Implementations MAY choose to support one or more of the following use-cases in order to be considered interoperable implementations

3.1. Session Revocation / Logout

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.

3.2. Credential Change

In order to support notifying and responding to credential changes, implementations MUST support the CAEP event type credential-change. Within the credential-change event, implementations MUST support the following field values:

change_type

Receivers MUST interpret all allowable values of this field. Transmitters MAY generate any allowable value of this field

credential_type

Receivers MUST interpret all allowable values of this field. Transmitters MAY generate any allowable value of this field

reason_admin

Transmitters MUST populate this value with a non-empty string

4. Normative References

[CAEP]
Cappalli, T. and A. Tulshibagwale, "OpenID Continuous Access Evaluation Profile 1.0", n.d., <https://openid.net/specs/openid-caep-specification-1_0.html>.
[RFC8935]
Backman, A., Ed., Jones, M., Ed., Scurtescu, M., Ansari, M., and A. Nadalin, "Push-Based Security Event Token (SET) Delivery Using HTTP", RFC 8935, DOI 10.17487/RFC8935, , <https://www.rfc-editor.org/info/rfc8935>.
[RFC8936]
Backman, A., Ed., Jones, M., Ed., Scurtescu, M., Ansari, M., and A. Nadalin, "Poll-Based Security Event Token (SET) Delivery Using HTTP", RFC 8936, DOI 10.17487/RFC8936, , <https://www.rfc-editor.org/info/rfc8936>.
[RFC9493]
Backman, A., Ed., Scurtescu, M., and P. Jain, "Subject Identifiers for Security Event Tokens", RFC 9493, DOI 10.17487/RFC9493, , <https://www.rfc-editor.org/info/rfc9493>.
[SSF]
Tulshibagwale, A., Cappalli, T., Scurtescu, M., Backman, A., Bradley, J., and S. Miel, "OpenID Shared Signals and Events Framework Specification 1.0 - draft 02", n.d., <https://openid.net/specs/openid-sharedsignals-framework-1_0.html>.

Contributors

Apoorva Deshpande
Okta

Author's Address

Atul Tulshibagwale
SGNL