Skip to content

Update OAuth Section #325

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
jischr wants to merge 3 commits into
base: main
Choose a base branch
from
+44 −6
Open

Update OAuth Section #325

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
b0eb14c
clarify OAuth section
jischr Apr 1, 2026
c9d7bb4
fix ascii
jischr Apr 1, 2026
ef5b548
updates ascii and added description
jischr Apr 10, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
50 changes: 44 additions & 6 deletions openid-caep-interoperability-profile-1_0.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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}

Expand Down Expand Up @@ -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}
Expand Down Expand Up @@ -356,7 +356,44 @@ 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

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. 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 | |
| | | |
| | +-----------------+
| |
| | 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
Copy link
Copy Markdown
Contributor

@thomasdarimont thomasdarimont Apr 10, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this partially answers the question in #327

It seems that OPRM (RFC 9728) is the only spec-defined in-band path from an SSF Transmitter URL to an Authorization Server.
Perhaps we should point the following interaction out more explicitly:

Discovery of OAuth Authorization Server from a SSF Transmitter issuer.

  1. Given a Transmitter URL
  2. derive .well-known/oauth-protected-resource URL (RFC 9728 §3)
  3. fetch OPRM document
  4. read authorization_servers[0] (RFC 9728 §2)
  5. derive .well-known/oauth-authorization-server URL (RFC 8414 §3)
  6. fetch AS metadata → token_endpoint, scopes etc.

Copy link
Copy Markdown
Contributor Author

@jischr jischr Apr 10, 2026 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes I agree, as the first subsection, we can have "Discovery of OAuth Authorization Server" to clarify some of those points. Let's make a new PR for that one.

The sections then flow nicely:
-> Discovery of AS
-> Authorization Grants
-> OAuth Scopes
-> Access Token Validation

Might require a bit of rework but may clear things up?

Copy link
Copy Markdown
Contributor

@ysarig75 ysarig75 Apr 12, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@thomasdarimont Can you explain the "It seems that OPRM (RFC 9728) is the only spec-defined in-band path from an SSF Transmitter URL to an Authorization Server." statement?

Can you also explain how you derive .well-known/oauth-protected-resource URL from a Transmitter URL? A transmitter URL can have a path so it can look like this: https:///.well-known/ssf-configuration/ssf/subscribers/5134159e-4fc8-48e2-8718-540d7f54ee56. Do you expect the OPRM URL to be https:///.well-known/oauth-protected-resource?

@jischr The interoperability spec mandate the usage of Oauth 2.0 for authorization. That shouldn't mean that we should be restrictive in how the Oauth 2.0 configuration is discovered. In order for a receiver to be able to get an access token, it needs to know the authorization or token endpoint. There are many ways to get those:

  • OIDC configuration (.well-known/openid-configuration)
  • Authorization Server Metadata (.well-known/oauth-authorization-server)
  • OPRM (.well-known/oauth-protected-resource)
  • An explicit configuration for the endpoint

Is there a reason why we should explicitly specify only one of those options?

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

Expand All @@ -379,8 +416,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
Expand Down
Loading