Skip to content

Clarify relationship between Transmitter and AS #245

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
wants to merge 4 commits into
base: main
Choose a base branch
from
Open

Clarify relationship between Transmitter and AS #245

Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
ecef6f1
fixes #203 - clarify relationship between transmitter and oauth autho…
jischr Apr 1, 2025
ebd25ea
update from pr comments
jischr Apr 1, 2025
2573d50
fix formatting
jischr Apr 1, 2025
eddb633
revert formatting
jischr Apr 1, 2025
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
17 changes: 11 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 @@ -217,21 +217,26 @@ All events MUST be signed using the `RS256` algorithm using a minimum of 2048-bi
## OAuth Service

### Authorization Server
* MAY distribute discovery metadata (such as the authorization endpoint) via the metadata document as specified in [RFC8414]{{RFC8414}}
* MUST support at least one of the following to obtain a short-lived access token. For example, a short lived access token could be defined as one in which the value of the `exp` claim is not longer than 60 mins after `nbf` claim. Please refer to Access token lifetimes in the security considerations of {{FAPI}} for additional considerations.

An OAuth {{RFC6749}} Authorization Server issues access tokens. In the context of this profile, the Authorization Server that issues access tokens can be a separate entity than the SSF Transmitter.
Copy link
Contributor

Choose a reason for hiding this comment

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

An OAuth {{RFC6749}} Authorization Server that issues access tokens. (the word "that" is missing there)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

this is an informational line describing what an OAuth AS is. i don't think that makes sense gramatically.
We could rephrase it to align with your thoughts here


* The Authorization Server MAY distribute discovery metadata (such as the authorization endpoint) via Authorization Server Metadata as specified in [RFC8414]{{RFC8414}}
* The Authorization Server MUST support at least one of the following to issue a short-lived access token to the Receiver
- client credential grant flow {{RFC6749}} section 4.4
- authorization code flow {{RFC6749}} section 4.1

A short lived access token could be defined as one in which the value of the `exp` claim is not longer than 60 mins after `nbf` claim. Please refer to access token lifetimes in the security considerations of {{FAPI}} for additional considerations.

### OAuth Scopes
Depending on the features supported by the OAuth service and the SSF APIs, the client SHALL discover the OAuth scopes as follows:
Depending on the features supported by the OAuth service and the SSF APIs, the OAuth Client SHALL discover the OAuth scopes as follows:

1. If the Resource Server, hosting SSF configuration APIs, supports OAuth Protected Resource Metadata {{OPRM}} then the client MUST obtain the required scopes by using it.

2. If the Resource Server does not support {{OPRM}}, then the following scopes MUST be supported -
- An OAuth {{RFC6749}} authorization server that is used to issue tokens to SSF Receivers, MUST reserve the scopes for the SSF endpoints with the prefix of `ssf`
2. If the Resource Server does not support {{OPRM}}, then the following scopes MUST be supported:
- An OAuth {{RFC6749}} Authorization Server that is used to issue tokens to SSF Receivers, MUST reserve the scopes for the SSF endpoints with the prefix of `ssf`
- All the SSF stream configuration management API operations MUST accept `ssf.manage` scope
- All the SSF stream configuration Read API operations MUST accept `ssf.read` scope
- Authorization server MAY postfix scope names with more granular operations eg. `ssf.manage.create`, `ssf.manage.update` etc.
- Authorization Server MAY postfix scope names with more granular operations eg. `ssf.manage.create`, `ssf.manage.update` etc.
- Transmitter managed poll endpoint MAY support the postfix scopes in the same nomenclature as `ssf.manage.poll`
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
- Transmitter managed poll endpoint MAY support the postfix scopes in the same nomenclature as `ssf.manage.poll`
- Transmitter managed poll endpoint SHOULD support the postfix scopes in the same nomenclature as `ssf.manage.poll`

Copy link
Contributor

Choose a reason for hiding this comment

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

To align with the changes from #208

Copy link
Contributor

Choose a reason for hiding this comment

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

Why do you think this is a "SHOULD" versus a "MAY"? The reason we shouldn't have a SHOULD in this spec, is because we won't be able to determine if something is interoperable or not based on a "SHOULD". If it's a "MAY", it's just informational, and if it is a "MUST", then it can be tested for interoperability.

Copy link
Contributor

Choose a reason for hiding this comment

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

Whatever gets decided, we should make sure #208 is fixed the same way as this


### The SSF Transmitter as a Resource Server
Expand Down