From b0eb14cf2406a61b45a973956524a524b52a7b4f Mon Sep 17 00:00:00 2001 From: Jen Schreiber Date: Wed, 1 Apr 2026 15:48:47 -0600 Subject: [PATCH 1/3] clarify OAuth section --- openid-caep-interoperability-profile-1_0.md | 33 +++++++++++++++++---- 1 file changed, 28 insertions(+), 5 deletions(-) diff --git a/openid-caep-interoperability-profile-1_0.md b/openid-caep-interoperability-profile-1_0.md index 1b82a11..8771ca2 100644 --- a/openid-caep-interoperability-profile-1_0.md +++ b/openid-caep-interoperability-profile-1_0.md @@ -209,11 +209,11 @@ Verification as defined in {{SSF}} Section 8.1.4. The Transmitter Configuration Metadata MUST include the `authorization_schemes` field and its value MUST include the value: -```json +~~~ json { "spec_urn": "urn:ietf:rfc:6749" } -``` +~~~ ### Streams {#transmitter-common-stream-configuration} @@ -356,7 +356,29 @@ at least one of subject identifier formats specified in this section. All events MUST be signed using the `RS256` algorithm using a minimum of 2048-bit keys. -## OAuth Service +## OAuth Support + +~~~ascii +┌──────────────┐ +│ │ ┌─────────────────┐ +│ │ 1. Fetch AS Metadata │ │ +│ │───────────────────────────►│ │ +│ │ │ Authorization │ +│ │ 2. AS Metadata Response │ Server (AS) │ +│ Client │◄───────────────────────────│ -- │ +│(SSF Receiver)│ │ Trusted by the │ +│ │ 3. Token Request │ SSF Transmitter │ +│ │───────────────────────────►│ │ +│ │ │ │ +│ │ 4. Access Token │ │ +│ │◄───────────────────────────│ │ +│ │ └─────────────────┘ +│ │ 5. SSF API Request with ┌─────────────────┐ +│ │ Access Token │ Resource Server │ +│ │───────────────────────────►│(SSF Transmitter)│ +└──────────────┘ └─────────────────┘ +~~~ +{: #figintro title="OAuth Support for CAEP Interoperability Profile"} ### Authorization Server @@ -379,8 +401,9 @@ considerations. ### OAuth Scopes -Depending on the features supported by the OAuth service and the SSF APIs, the -OAuth Client SHALL discover the OAuth scopes as follows: +Depending on the features supported by the Authorization Server and the SSF +APIs, the OAuth Client SHALL discover the OAuth scopes that MAY be used as +follows: * If the Resource Server, hosting SSF configuration APIs, supports OAuth Protected Resource Metadata {{OPRM}} then the client MUST obtain the required From c9d7bb4dcd7f717ff5f4dead7a29d7b9b282a3db Mon Sep 17 00:00:00 2001 From: Jen Schreiber Date: Wed, 1 Apr 2026 16:06:06 -0600 Subject: [PATCH 2/3] fix ascii --- openid-caep-interoperability-profile-1_0.md | 39 +++++++++++---------- 1 file changed, 20 insertions(+), 19 deletions(-) diff --git a/openid-caep-interoperability-profile-1_0.md b/openid-caep-interoperability-profile-1_0.md index 8771ca2..a53ced6 100644 --- a/openid-caep-interoperability-profile-1_0.md +++ b/openid-caep-interoperability-profile-1_0.md @@ -278,7 +278,7 @@ methods: ### JWKS URI {#receiver-jwks-uri} -The Receiver MUST obtain the Transmitter’s signing key(s) using the `jwks_uri` +The Receiver MUST obtain the Transmitter's signing key(s) using the `jwks_uri` from the Transmitter Configuration Metadata, as defined in {{SSF}} Section 7.1. ### Authorization Schemes {#receivers-authorization-schemes} @@ -359,24 +359,25 @@ All events MUST be signed using the `RS256` algorithm using a minimum of ## OAuth Support ~~~ascii -┌──────────────┐ -│ │ ┌─────────────────┐ -│ │ 1. Fetch AS Metadata │ │ -│ │───────────────────────────►│ │ -│ │ │ Authorization │ -│ │ 2. AS Metadata Response │ Server (AS) │ -│ Client │◄───────────────────────────│ -- │ -│(SSF Receiver)│ │ Trusted by the │ -│ │ 3. Token Request │ SSF Transmitter │ -│ │───────────────────────────►│ │ -│ │ │ │ -│ │ 4. Access Token │ │ -│ │◄───────────────────────────│ │ -│ │ └─────────────────┘ -│ │ 5. SSF API Request with ┌─────────────────┐ -│ │ Access Token │ Resource Server │ -│ │───────────────────────────►│(SSF Transmitter)│ -└──────────────┘ └─────────────────┘ ++--------------+ +| | +-----------------+ +| | 1. Fetch AS Metadata | | +| |--------------------------->| | +| | | Authorization | +| | 2. AS Metadata Response | Server (AS) | +| Client |<---------------------------| -- | +|(SSF Receiver)| | Trusted by the | +| | 3. Token Request | SSF Transmitter | +| |--------------------------->| | +| | | | +| | 4. Access Token | | +| |<---------------------------| | +| | +-----------------+ +| | +| | 5. SSF API Request with +-----------------+ +| | Access Token | Resource Server | +| |--------------------------->|(SSF Transmitter)| ++--------------+ +-----------------+ ~~~ {: #figintro title="OAuth Support for CAEP Interoperability Profile"} From ef5b548783828dd080759b14a69e4b4930078e57 Mon Sep 17 00:00:00 2001 From: Jen Schreiber Date: Fri, 10 Apr 2026 14:50:52 -0600 Subject: [PATCH 3/3] updates ascii and added description --- openid-caep-interoperability-profile-1_0.md | 48 +++++++++++++-------- 1 file changed, 31 insertions(+), 17 deletions(-) diff --git a/openid-caep-interoperability-profile-1_0.md b/openid-caep-interoperability-profile-1_0.md index a53ced6..3a09939 100644 --- a/openid-caep-interoperability-profile-1_0.md +++ b/openid-caep-interoperability-profile-1_0.md @@ -358,29 +358,43 @@ All events MUST be signed using the `RS256` algorithm using a minimum of ## OAuth Support +Implementations MUST support OAuth 2.0 {{RFC6749}}. The following diagram +illustrates the OAuth flow between the SSF Transmitter, SSF Receiver, and the +Authorization Server. + ~~~ascii +--------------+ -| | +-----------------+ -| | 1. Fetch AS Metadata | | -| |--------------------------->| | -| | | Authorization | -| | 2. AS Metadata Response | Server (AS) | -| Client |<---------------------------| -- | -|(SSF Receiver)| | Trusted by the | -| | 3. Token Request | SSF Transmitter | -| |--------------------------->| | -| | | | -| | 4. Access Token | | -| |<---------------------------| | -| | +-----------------+ +| | +-----------------+ +| | 1. AS Metadata Request | | +| |---------------------------->| | +| |<----------------------------| Authorization | +| | Client obtains AS Metadata | Server (AS) | +| Client | | -- | +|(SSF Receiver)| | Trusted by the | +| | 2. OAuth Exchange | SSF Transmitter | +| |<--------------------------->| | +| | Client obtains access token | | +| | | | +| | +-----------------+ | | -| | 5. SSF API Request with +-----------------+ -| | Access Token | Resource Server | -| |--------------------------->|(SSF Transmitter)| -+--------------+ +-----------------+ +| | 3. SSF API Request with +-----------------+ +| | Access Token | Resource Server | +| |---------------------------->|(SSF Transmitter)| ++--------------+ +-----------------+ ~~~ {: #figintro title="OAuth Support for CAEP Interoperability Profile"} +1. The SSF Receiver/Client makes a request to fetch the Authorization Server +metadata at its Metadata URL. The Metadata URL can be discovered from the +Resource Server via {{OPRM}} or out-of-band. The Authorization Server responds +with the Authorization Server metadata document as described in {{RFC8414}}. + +2. The SSF Receiver/Client obtains an access token from the Authorization Server +using either the authorization code grant or the client credentials grant. + +3. The SSF Receiver/Client makes a request to the Transmitter's protected +endpoints using the access token. + ### Authorization Server An OAuth {{RFC6749}} Authorization Server issues access tokens. In the context