Skip to content
Merged
Changes from all commits
Commits
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
31 changes: 17 additions & 14 deletions openid-caep-interoperability-profile-1_0.md
Original file line number Diff line number Diff line change
Expand Up @@ -291,39 +291,42 @@ All events MUST be signed using the `RS256` algorithm using a minimum of

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

* 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 is 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:
OAuth Client SHALL discover the OAuth scopes as follows:

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

* If the Resource Server does not support {{OPRM}}, then the following scopes
MUST be supported -
MUST be supported:

* An OAuth {{RFC6749}} authorization server that is used to issue tokens to
* 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.
* Transmitter managed poll endpoint MAY support the postfix scopes in the same
nomenclature as `ssf.manage.poll`

### The SSF Transmitter as a Resource Server

Expand Down