From ecef6f174d22f3fdd04ffde6aa5969eee64e78ad Mon Sep 17 00:00:00 2001 From: Jen Schreiber Date: Mon, 31 Mar 2025 19:35:30 -0600 Subject: [PATCH 1/7] fixes #203 - clarify relationship between transmitter and oauth authorization server --- openid-caep-interoperability-profile-1_0.md | 17 +++++++++++------ 1 file changed, 11 insertions(+), 6 deletions(-) diff --git a/openid-caep-interoperability-profile-1_0.md b/openid-caep-interoperability-profile-1_0.md index 399d076..1c9d776 100644 --- a/openid-caep-interoperability-profile-1_0.md +++ b/openid-caep-interoperability-profile-1_0.md @@ -216,22 +216,27 @@ 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. +### The SSF Transmitter as an Authorization Server + +A Transmitter can act as an OAuth {{RFC6749}} Authorization Server. As such, it issues access tokens to Receivers. + +* Transmitters MAY distribute discovery metadata (such as the authorization endpoint) via the Authorization Server Metadata as specified in [RFC8414]{{RFC8414}} +* Transmitters MUST support at least one of the following to issue a short-lived access token. - 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: 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` ### The SSF Transmitter as a Resource Server From ebd25eac81d805a545c7a8a3837cfe7267d65a4b Mon Sep 17 00:00:00 2001 From: Jen Schreiber Date: Tue, 1 Apr 2025 16:27:17 -0600 Subject: [PATCH 2/7] update from pr comments --- openid-caep-interoperability-profile-1_0.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/openid-caep-interoperability-profile-1_0.md b/openid-caep-interoperability-profile-1_0.md index 1c9d776..9e5f7da 100644 --- a/openid-caep-interoperability-profile-1_0.md +++ b/openid-caep-interoperability-profile-1_0.md @@ -216,24 +216,24 @@ All events MUST be signed using the `RS256` algorithm using a minimum of 2048-bi ## OAuth Service -### The SSF Transmitter as an Authorization Server +### Authorization Server -A Transmitter can act as an OAuth {{RFC6749}} Authorization Server. As such, it issues access tokens to Receivers. +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. -* Transmitters MAY distribute discovery metadata (such as the authorization endpoint) via the Authorization Server Metadata as specified in [RFC8414]{{RFC8414}} -* Transmitters MUST support at least one of the following to issue a short-lived access token. +* 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` + * 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. From 2573d5043e086b8c15cac2c63e8cd7a17729454f Mon Sep 17 00:00:00 2001 From: Jen Schreiber Date: Tue, 1 Apr 2025 16:29:23 -0600 Subject: [PATCH 3/7] fix formatting --- openid-caep-interoperability-profile-1_0.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/openid-caep-interoperability-profile-1_0.md b/openid-caep-interoperability-profile-1_0.md index 9e5f7da..6b5c061 100644 --- a/openid-caep-interoperability-profile-1_0.md +++ b/openid-caep-interoperability-profile-1_0.md @@ -234,10 +234,10 @@ Depending on the features supported by the OAuth service and the SSF APIs, the O 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. - - Transmitter managed poll endpoint MAY support the postfix scopes in the same nomenclature as `ssf.manage.poll` + * 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 * MUST accept access tokens in the HTTP header as in Section 2.1 of OAuth 2.0 Bearer Token Usage [RFC6750]{{RFC6750}} From eddb6330d9186daf38af2bbba60ccfa185a65739 Mon Sep 17 00:00:00 2001 From: Jen Schreiber Date: Tue, 1 Apr 2025 16:30:25 -0600 Subject: [PATCH 4/7] revert formatting --- openid-caep-interoperability-profile-1_0.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/openid-caep-interoperability-profile-1_0.md b/openid-caep-interoperability-profile-1_0.md index 6b5c061..2de24e1 100644 --- a/openid-caep-interoperability-profile-1_0.md +++ b/openid-caep-interoperability-profile-1_0.md @@ -233,11 +233,11 @@ Depending on the features supported by the OAuth service and the SSF APIs, the O 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` - * 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` + - 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 * MUST accept access tokens in the HTTP header as in Section 2.1 of OAuth 2.0 Bearer Token Usage [RFC6750]{{RFC6750}} From 12ef05b687a8e9513f8b7da5502175a8a3bb37fd Mon Sep 17 00:00:00 2001 From: Jen Schreiber Date: Thu, 4 Dec 2025 16:24:26 -0700 Subject: [PATCH 5/7] review comments --- openid-caep-interoperability-profile-1_0.md | 2 -- 1 file changed, 2 deletions(-) diff --git a/openid-caep-interoperability-profile-1_0.md b/openid-caep-interoperability-profile-1_0.md index 2de24e1..05fbd9d 100644 --- a/openid-caep-interoperability-profile-1_0.md +++ b/openid-caep-interoperability-profile-1_0.md @@ -236,8 +236,6 @@ Depending on the features supported by the OAuth service and the SSF APIs, the O - 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 * MUST accept access tokens in the HTTP header as in Section 2.1 of OAuth 2.0 Bearer Token Usage [RFC6750]{{RFC6750}} From d2f8bbfed3cff58bcafff3c7e312886c2a4138ac Mon Sep 17 00:00:00 2001 From: Jen Schreiber Date: Thu, 4 Dec 2025 16:30:39 -0700 Subject: [PATCH 6/7] remove whitespace --- openid-caep-interoperability-profile-1_0.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/openid-caep-interoperability-profile-1_0.md b/openid-caep-interoperability-profile-1_0.md index 8545d94..82d0fd0 100644 --- a/openid-caep-interoperability-profile-1_0.md +++ b/openid-caep-interoperability-profile-1_0.md @@ -319,7 +319,7 @@ scopes by using it. * 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` From d399b93749ddb01517f9ed291cccd14c55d26776 Mon Sep 17 00:00:00 2001 From: Jen Schreiber Date: Thu, 18 Dec 2025 17:44:04 -0700 Subject: [PATCH 7/7] fix wording --- openid-caep-interoperability-profile-1_0.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/openid-caep-interoperability-profile-1_0.md b/openid-caep-interoperability-profile-1_0.md index 6a8f20b..04ab726 100644 --- a/openid-caep-interoperability-profile-1_0.md +++ b/openid-caep-interoperability-profile-1_0.md @@ -303,7 +303,7 @@ 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 +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.