From 589075302ba78db5eb018aeba01e73d0102aae31 Mon Sep 17 00:00:00 2001 From: Apoorva Deshpande Date: Thu, 21 Dec 2023 14:35:41 -0800 Subject: [PATCH 01/11] Include OAuth specifics in the interop spec Include OAuth specifics in the interop spec --- openid-caep-interoperability-profile-1_0.md | 48 +++++++++++++++++++-- 1 file changed, 44 insertions(+), 4 deletions(-) diff --git a/openid-caep-interoperability-profile-1_0.md b/openid-caep-interoperability-profile-1_0.md index 6790dee..c4dba93 100644 --- a/openid-caep-interoperability-profile-1_0.md +++ b/openid-caep-interoperability-profile-1_0.md @@ -21,8 +21,6 @@ author: name: Atul Tulshibagwale org: SGNL email: atul@sgnl.ai - -contributor: - ins: A. Deshpande name: Apoorva Deshpande @@ -74,10 +72,25 @@ normative: ins: A. Tulshibagwale name: Atul Tulshibagwale org: SGNL - + RFC7525: # Recommendations for Secure Use of Transport Layer Security + RFC6125: # Representation and Verification of Domain-Based Application Service Identity within Internet Public Key + # Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS) + RFC6750: # The OAuth 2.0 Authorization Framework: Bearer Token Usage + RFC8414: # OAuth 2.0 Authorization Server Metadata + OAUTH: + target: https://www.rfc-editor.org/info/rfc6749 + title: The OAuth 2.0 Authorization Framework + author: + - + ins: D. Hardt, Ed + name: Dick Hardt + org: Microsoft --- abstract -This document defines an interoperability profile for implementations of the Shared Signals Framework (SSF) {{SSF}} and the Continuous Access Evaluation Profile (CAEP) {{CAEP}}. It is organized around use-cases that improve security of authenticated sessions. It specifies certain optional elements from within the SSF and CAEP specifications as being required to be supported in order to be considered as an interoperable implementation. +This document defines an interoperability profile for implementations of the Shared Signals Framework (SSF) {{SSF}}, the Continuous Access Evaluation Profile (CAEP) {{CAEP}} and the OAuth 2.0 Authorization Framework (OAuth) {{OAUTH}}. It is organized around use-cases that improve security of authenticated sessions. It specifies certain optional elements from within the SSF and CAEP specifications as being required to be supported in order to be considered as an interoperable implementation. + +Interoperability between the SSF, CAEP and the OAuth framework empowers organizations to leverage the strengths of these standards, bringing in +more security to the APIs. --- middle @@ -93,6 +106,11 @@ Credential Change # Common Requirements {#common-requirements} The following requirements are common across all use-cases defined in this document. +## Network layer protection +* The SSF transmitter MUST offer TLS protected endpoints and shall establish connections to other servers using TLS. TLS connections MUST be set up to use TLS version 1.2 or later. +* When using TLS 1.2, follow the recommendations for Secure Use of Transport Layer Security in [RFC7525]{{RFC7525}}. +* The SSF receiver MUST perform a TLS server certificate check before calling the SSF transmitter APIs, as per [RFC6125]{{RFC6125}}. + ## Transmitters {#common-transmitters} Transmitters MUST implement the following features: @@ -175,6 +193,28 @@ Receivers MUST be prepared to accept events with any of the subject identifier f ## Event Signatures All events MUST be signed using the `RS256` algorithm using a minimum of 2048-bit keys. +## OAuth Service + +### Authorization Server +* SHALL 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 +** client credential grant flow +** authorization code flow + +### OAuth Scopes + +* Authorization server MUST reserve the scopes for the SSF endpoints with the prefix of `ssf` +* All the SSF stream configuration management API operations MUST be protected using `ssf.manage` scope +* All the SSF stream configuration Read API operations MUST be protected by `ssf.read` scope +* Authorization server MAY decide to postfix scope names with more granular operations eg. `ssf.manage.create`, `ssf.manage.update` etc. +* Transmitter managed poll endpoint MAY use the scope 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}} +* MUST NOT accept access tokens in the query parameters stated in Section 2.3 of OAuth 2.0 Bearer Token Usage [RFC6750]{{RFC6750}} +* SHALL verify the validity, integrity, expiration and revocation status of access tokens +* SHALL verify that the authorization represented by the access token is sufficient for the requested resource access and otherwise return errors as in section 3.1 of [RFC6750]{{RFC6750}} + # Use Cases Implementations MAY choose to support one or more of the following use-cases in order to be considered interoperable implementations From d4222fda8b495148cc4b51cc3a719e39fc4db6b5 Mon Sep 17 00:00:00 2001 From: Apoorva Deshpande Date: Tue, 9 Jan 2024 09:47:42 -0800 Subject: [PATCH 02/11] Atul's feedback --- openid-caep-interoperability-profile-1_0.md | 19 +++++++++---------- 1 file changed, 9 insertions(+), 10 deletions(-) diff --git a/openid-caep-interoperability-profile-1_0.md b/openid-caep-interoperability-profile-1_0.md index c4dba93..fa60645 100644 --- a/openid-caep-interoperability-profile-1_0.md +++ b/openid-caep-interoperability-profile-1_0.md @@ -77,7 +77,7 @@ normative: # Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS) RFC6750: # The OAuth 2.0 Authorization Framework: Bearer Token Usage RFC8414: # OAuth 2.0 Authorization Server Metadata - OAUTH: + RFC6749: target: https://www.rfc-editor.org/info/rfc6749 title: The OAuth 2.0 Authorization Framework author: @@ -87,10 +87,9 @@ normative: org: Microsoft --- abstract -This document defines an interoperability profile for implementations of the Shared Signals Framework (SSF) {{SSF}}, the Continuous Access Evaluation Profile (CAEP) {{CAEP}} and the OAuth 2.0 Authorization Framework (OAuth) {{OAUTH}}. It is organized around use-cases that improve security of authenticated sessions. It specifies certain optional elements from within the SSF and CAEP specifications as being required to be supported in order to be considered as an interoperable implementation. +This document defines an interoperability profile for implementations of the Shared Signals Framework (SSF) {{SSF}}, the Continuous Access Evaluation Profile (CAEP) {{CAEP}}. This also profiles The OAuth 2.0 Authorization Framework {{RFC6749}} usage in the context of the SSF framework. The interoperability should It is organized around use-cases that improve security of authenticated sessions. It specifies certain optional elements from within the SSF and CAEP specifications as being required to be supported in order to be considered as an interoperable implementation. -Interoperability between the SSF, CAEP and the OAuth framework empowers organizations to leverage the strengths of these standards, bringing in -more security to the APIs. +Interoperability between SSF and CAEP, leveraging OAuth {{RFC6749}} provides greater assurance to implementers that their implementations will work out of the box with others. --- middle @@ -109,7 +108,7 @@ The following requirements are common across all use-cases defined in this docum ## Network layer protection * The SSF transmitter MUST offer TLS protected endpoints and shall establish connections to other servers using TLS. TLS connections MUST be set up to use TLS version 1.2 or later. * When using TLS 1.2, follow the recommendations for Secure Use of Transport Layer Security in [RFC7525]{{RFC7525}}. -* The SSF receiver MUST perform a TLS server certificate check before calling the SSF transmitter APIs, as per [RFC6125]{{RFC6125}}. +* The SSF receiver MUST perform a TLS server certificate signature checks, chain of trust validations, expiry and revocation status checks before calling the SSF transmitter APIs, as per [RFC6125]{{RFC6125}}. ## Transmitters {#common-transmitters} Transmitters MUST implement the following features: @@ -196,24 +195,24 @@ All events MUST be signed using the `RS256` algorithm using a minimum of 2048-bi ## OAuth Service ### Authorization Server -* SHALL distribute discovery metadata (such as the authorization endpoint) via the metadata document as specified in [RFC8414]{{RFC8414}} +* 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 ** client credential grant flow ** authorization code flow ### OAuth Scopes -* Authorization server MUST reserve the scopes for the SSF endpoints with the prefix of `ssf` +* An OAuth {{RFC6749}} authorization 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 be protected using `ssf.manage` scope * All the SSF stream configuration Read API operations MUST be protected by `ssf.read` scope -* Authorization server MAY decide to 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 use the scope 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}} * MUST NOT accept access tokens in the query parameters stated in Section 2.3 of OAuth 2.0 Bearer Token Usage [RFC6750]{{RFC6750}} -* SHALL verify the validity, integrity, expiration and revocation status of access tokens -* SHALL verify that the authorization represented by the access token is sufficient for the requested resource access and otherwise return errors as in section 3.1 of [RFC6750]{{RFC6750}} +* MUST verify the validity, integrity, expiration and revocation status of access tokens +* MUST verify that the authorization represented by the access token is sufficient for the requested resource access and otherwise return errors as in section 3.1 of [RFC6750]{{RFC6750}} # Use Cases Implementations MAY choose to support one or more of the following use-cases in order to be considered interoperable implementations From 5e59386f021ecc3e0c307a5db3aad5b12e96b379 Mon Sep 17 00:00:00 2001 From: Apoorva Deshpande Date: Thu, 21 Dec 2023 14:35:41 -0800 Subject: [PATCH 03/11] Include OAuth specifics in the interop spec Include OAuth specifics in the interop spec --- openid-caep-interoperability-profile-1_0.md | 13 ------------- 1 file changed, 13 deletions(-) diff --git a/openid-caep-interoperability-profile-1_0.md b/openid-caep-interoperability-profile-1_0.md index fa60645..f0362e1 100644 --- a/openid-caep-interoperability-profile-1_0.md +++ b/openid-caep-interoperability-profile-1_0.md @@ -72,19 +72,6 @@ normative: ins: A. Tulshibagwale name: Atul Tulshibagwale org: SGNL - RFC7525: # Recommendations for Secure Use of Transport Layer Security - RFC6125: # Representation and Verification of Domain-Based Application Service Identity within Internet Public Key - # Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS) - RFC6750: # The OAuth 2.0 Authorization Framework: Bearer Token Usage - RFC8414: # OAuth 2.0 Authorization Server Metadata - RFC6749: - target: https://www.rfc-editor.org/info/rfc6749 - title: The OAuth 2.0 Authorization Framework - author: - - - ins: D. Hardt, Ed - name: Dick Hardt - org: Microsoft --- abstract This document defines an interoperability profile for implementations of the Shared Signals Framework (SSF) {{SSF}}, the Continuous Access Evaluation Profile (CAEP) {{CAEP}}. This also profiles The OAuth 2.0 Authorization Framework {{RFC6749}} usage in the context of the SSF framework. The interoperability should It is organized around use-cases that improve security of authenticated sessions. It specifies certain optional elements from within the SSF and CAEP specifications as being required to be supported in order to be considered as an interoperable implementation. From 25672dae72ad7408510d56429e587e9289de7c88 Mon Sep 17 00:00:00 2001 From: Apoorva Deshpande Date: Thu, 21 Dec 2023 14:35:41 -0800 Subject: [PATCH 04/11] Include OAuth specifics in the interop spec Include OAuth specifics in the interop spec --- openid-caep-interoperability-profile-1_0.md | 7 ------- 1 file changed, 7 deletions(-) diff --git a/openid-caep-interoperability-profile-1_0.md b/openid-caep-interoperability-profile-1_0.md index fa60645..e5d2833 100644 --- a/openid-caep-interoperability-profile-1_0.md +++ b/openid-caep-interoperability-profile-1_0.md @@ -78,13 +78,6 @@ normative: RFC6750: # The OAuth 2.0 Authorization Framework: Bearer Token Usage RFC8414: # OAuth 2.0 Authorization Server Metadata RFC6749: - target: https://www.rfc-editor.org/info/rfc6749 - title: The OAuth 2.0 Authorization Framework - author: - - - ins: D. Hardt, Ed - name: Dick Hardt - org: Microsoft --- abstract This document defines an interoperability profile for implementations of the Shared Signals Framework (SSF) {{SSF}}, the Continuous Access Evaluation Profile (CAEP) {{CAEP}}. This also profiles The OAuth 2.0 Authorization Framework {{RFC6749}} usage in the context of the SSF framework. The interoperability should It is organized around use-cases that improve security of authenticated sessions. It specifies certain optional elements from within the SSF and CAEP specifications as being required to be supported in order to be considered as an interoperable implementation. From c4f0f85ec328fde7ed9fc5ee4823841224e31132 Mon Sep 17 00:00:00 2001 From: Apoorva Deshpande Date: Tue, 16 Jan 2024 09:54:36 -0800 Subject: [PATCH 05/11] Updates 1. Shayne's suggestion 2. CAEP version --- openid-caep-interoperability-profile-1_0.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/openid-caep-interoperability-profile-1_0.md b/openid-caep-interoperability-profile-1_0.md index e5d2833..0d10f44 100644 --- a/openid-caep-interoperability-profile-1_0.md +++ b/openid-caep-interoperability-profile-1_0.md @@ -80,7 +80,7 @@ normative: RFC6749: --- abstract -This document defines an interoperability profile for implementations of the Shared Signals Framework (SSF) {{SSF}}, the Continuous Access Evaluation Profile (CAEP) {{CAEP}}. This also profiles The OAuth 2.0 Authorization Framework {{RFC6749}} usage in the context of the SSF framework. The interoperability should It is organized around use-cases that improve security of authenticated sessions. It specifies certain optional elements from within the SSF and CAEP specifications as being required to be supported in order to be considered as an interoperable implementation. +This document defines an interoperability profile for implementations of the Shared Signals Framework (SSF) {{SSF}}, the Continuous Access Evaluation Profile (CAEP) {{CAEP}}. This also profiles The OAuth 2.0 Authorization Framework {{RFC6749}} usage in the context of the SSF framework. The interoperability profile is organized around use-cases that improve security of authenticated sessions. It specifies certain optional elements from within the SSF and CAEP specifications as being required to be supported in order to be considered as an interoperable implementation. Interoperability between SSF and CAEP, leveraging OAuth {{RFC6749}} provides greater assurance to implementers that their implementations will work out of the box with others. @@ -103,6 +103,9 @@ The following requirements are common across all use-cases defined in this docum * When using TLS 1.2, follow the recommendations for Secure Use of Transport Layer Security in [RFC7525]{{RFC7525}}. * The SSF receiver MUST perform a TLS server certificate signature checks, chain of trust validations, expiry and revocation status checks before calling the SSF transmitter APIs, as per [RFC6125]{{RFC6125}}. +## CAEP specification version +This specification supports CAEP {{CAEP}} events from Implementer's Draft 1 + ## Transmitters {#common-transmitters} Transmitters MUST implement the following features: From e62050708015ceebf31bbf231748e0b22269a34f Mon Sep 17 00:00:00 2001 From: Apoorva Deshpande Date: Mon, 1 Apr 2024 21:42:14 -0700 Subject: [PATCH 06/11] Update openid-caep-interoperability-profile-1_0.md --- openid-caep-interoperability-profile-1_0.md | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/openid-caep-interoperability-profile-1_0.md b/openid-caep-interoperability-profile-1_0.md index 0d10f44..1cee214 100644 --- a/openid-caep-interoperability-profile-1_0.md +++ b/openid-caep-interoperability-profile-1_0.md @@ -80,7 +80,7 @@ normative: RFC6749: --- abstract -This document defines an interoperability profile for implementations of the Shared Signals Framework (SSF) {{SSF}}, the Continuous Access Evaluation Profile (CAEP) {{CAEP}}. This also profiles The OAuth 2.0 Authorization Framework {{RFC6749}} usage in the context of the SSF framework. The interoperability profile is organized around use-cases that improve security of authenticated sessions. It specifies certain optional elements from within the SSF and CAEP specifications as being required to be supported in order to be considered as an interoperable implementation. +This document defines an interoperability profile for implementations of the Shared Signals Framework (SSF) {{SSF}} and the Continuous Access Evaluation Profile (CAEP) {{CAEP}}. This also profiles The OAuth 2.0 Authorization Framework {{RFC6749}} usage in the context of the SSF framework. The interoperability profile is organized around use-cases that improve security of authenticated sessions. It specifies certain optional elements from within the SSF and CAEP specifications as being required to be supported in order to be considered as an interoperable implementation. Interoperability between SSF and CAEP, leveraging OAuth {{RFC6749}} provides greater assurance to implementers that their implementations will work out of the box with others. @@ -99,12 +99,12 @@ Credential Change The following requirements are common across all use-cases defined in this document. ## Network layer protection -* The SSF transmitter MUST offer TLS protected endpoints and shall establish connections to other servers using TLS. TLS connections MUST be set up to use TLS version 1.2 or later. +* The SSF transmitter MUST offer TLS protected endpoints and MUST establish connections to other servers using TLS. TLS connections MUST be set up to use TLS version 1.2 or later. * When using TLS 1.2, follow the recommendations for Secure Use of Transport Layer Security in [RFC7525]{{RFC7525}}. * The SSF receiver MUST perform a TLS server certificate signature checks, chain of trust validations, expiry and revocation status checks before calling the SSF transmitter APIs, as per [RFC6125]{{RFC6125}}. ## CAEP specification version -This specification supports CAEP {{CAEP}} events from Implementer's Draft 1 +This specification supports CAEP {{CAEP}} events from Implementer's Draft 2 ## Transmitters {#common-transmitters} Transmitters MUST implement the following features: @@ -192,9 +192,9 @@ All events MUST be signed using the `RS256` algorithm using a minimum of 2048-bi ### 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 -** client credential grant flow -** authorization code flow +* MUST support at least one of the following to obtain a short-lived access token. (Please check out security considerations around access token lifetime https://openid.bitbucket.io/fapi/fapi-2_0-security-profile.html#name-access-token-lifetimes) +** client credential grant flow {{RFC6749}} section 4.4 +** authorization code flow {{RFC6749}} section 4.1 ### OAuth Scopes @@ -208,7 +208,8 @@ All events MUST be signed using the `RS256` algorithm using a minimum of 2048-bi * MUST accept access tokens in the HTTP header as in Section 2.1 of OAuth 2.0 Bearer Token Usage [RFC6750]{{RFC6750}} * MUST NOT accept access tokens in the query parameters stated in Section 2.3 of OAuth 2.0 Bearer Token Usage [RFC6750]{{RFC6750}} * MUST verify the validity, integrity, expiration and revocation status of access tokens -* MUST verify that the authorization represented by the access token is sufficient for the requested resource access and otherwise return errors as in section 3.1 of [RFC6750]{{RFC6750}} +* MUST verify that the authorization represented by the access token is sufficient for the requested resource access. +* If the access token is not sufficient for the requested action, the Resource server MUST return errors as per section 3.1 of [RFC6750]{{RFC6750}} # Use Cases Implementations MAY choose to support one or more of the following use-cases in order to be considered interoperable implementations From 4cd21eaad53a4b2aee2c0ffe788682130f6e5b7d Mon Sep 17 00:00:00 2001 From: Apoorva Deshpande Date: Fri, 12 Apr 2024 10:47:33 -0700 Subject: [PATCH 07/11] Update openid-caep-interoperability-profile-1_0.md --- openid-caep-interoperability-profile-1_0.md | 20 ++++++++++++++++++-- 1 file changed, 18 insertions(+), 2 deletions(-) diff --git a/openid-caep-interoperability-profile-1_0.md b/openid-caep-interoperability-profile-1_0.md index 1cee214..bdb9b34 100644 --- a/openid-caep-interoperability-profile-1_0.md +++ b/openid-caep-interoperability-profile-1_0.md @@ -78,6 +78,21 @@ normative: RFC6750: # The OAuth 2.0 Authorization Framework: Bearer Token Usage RFC8414: # OAuth 2.0 Authorization Server Metadata RFC6749: + FAPI: + target: https://openid.bitbucket.io/fapi/fapi-2_0-security-profile.html + title: FAPI 2.0 Security Profile — draft + author: + - ins: D. Fett + - ins: D. Tonge + - ins: J. Heenan + OPRM: + target: https://www.ietf.org/archive/id/draft-ietf-oauth-resource-metadata-03.html + title: OAuth 2.0 Protected Resource Metadata + author: + -ins: M.B. Jones + -ins: P. Hunt + -ins: A. Parecki + --- abstract This document defines an interoperability profile for implementations of the Shared Signals Framework (SSF) {{SSF}} and the Continuous Access Evaluation Profile (CAEP) {{CAEP}}. This also profiles The OAuth 2.0 Authorization Framework {{RFC6749}} usage in the context of the SSF framework. The interoperability profile is organized around use-cases that improve security of authenticated sessions. It specifies certain optional elements from within the SSF and CAEP specifications as being required to be supported in order to be considered as an interoperable implementation. @@ -192,12 +207,12 @@ All events MUST be signed using the `RS256` algorithm using a minimum of 2048-bi ### 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. (Please check out security considerations around access token lifetime https://openid.bitbucket.io/fapi/fapi-2_0-security-profile.html#name-access-token-lifetimes) +* MUST support at least one of the following to obtain a short-lived access token. Please refer Access token lifetimes in the security considerations {{FAPI}} for additional considerations. ** client credential grant flow {{RFC6749}} section 4.4 ** authorization code flow {{RFC6749}} section 4.1 ### OAuth Scopes - +The OAuth scopes required to access the resources MAY be obtained by the client using {{OPRM}} hosted by the Resource Server. In the absence of this mechanism - * An OAuth {{RFC6749}} authorization 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 be protected using `ssf.manage` scope * All the SSF stream configuration Read API operations MUST be protected by `ssf.read` scope @@ -210,6 +225,7 @@ All events MUST be signed using the `RS256` algorithm using a minimum of 2048-bi * MUST verify the validity, integrity, expiration and revocation status of access tokens * MUST verify that the authorization represented by the access token is sufficient for the requested resource access. * If the access token is not sufficient for the requested action, the Resource server MUST return errors as per section 3.1 of [RFC6750]{{RFC6750}} +* MAY publish the {{OPRM}} to describe the metadata needed to interact with the protected resource. # Use Cases Implementations MAY choose to support one or more of the following use-cases in order to be considered interoperable implementations From 738dfebd54023bf3532843133be14ab6586ba2e3 Mon Sep 17 00:00:00 2001 From: Apoorva Deshpande Date: Thu, 23 May 2024 09:54:07 -0700 Subject: [PATCH 08/11] Atul's feedback Atul's feedback --- openid-caep-interoperability-profile-1_0.md | 16 +++++++++++----- 1 file changed, 11 insertions(+), 5 deletions(-) diff --git a/openid-caep-interoperability-profile-1_0.md b/openid-caep-interoperability-profile-1_0.md index bdb9b34..9426dab 100644 --- a/openid-caep-interoperability-profile-1_0.md +++ b/openid-caep-interoperability-profile-1_0.md @@ -207,15 +207,21 @@ All events MUST be signed using the `RS256` algorithm using a minimum of 2048-bi ### 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. Please refer Access token lifetimes in the security considerations {{FAPI}} for additional considerations. +* MUST support at least one of the following to obtain a short-lived access token. A short lived access token could be defined as `exp` claim no longer than 60 mins after `nbf`. Please refer Access token lifetimes in the security considerations {{FAPI}} for additional considerations. ** client credential grant flow {{RFC6749}} section 4.4 ** authorization code flow {{RFC6749}} section 4.1 ### OAuth Scopes -The OAuth scopes required to access the resources MAY be obtained by the client using {{OPRM}} hosted by the Resource Server. In the absence of this mechanism - -* An OAuth {{RFC6749}} authorization 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 be protected using `ssf.manage` scope -* All the SSF stream configuration Read API operations MUST be protected by `ssf.read` scope +The client could discover OAuth scopes needed to access the reource by 2 separate mechanisms depending on the support from the OAuth service + +#### Resource Server +The OAuth scopes required to access the resources MAY be obtained by the client using {{OPRM}} hosted by the Resource Server. + +#### Authorization Server +In the absence of Resource server's support for {{OPRM}} the following process should be adopted - +* 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 use the scope in the same nomenclature as `ssf.manage.poll` From 6f11d81a785b7cf1e26d77e191113a83996b2ad9 Mon Sep 17 00:00:00 2001 From: Apoorva Deshpande Date: Thu, 23 May 2024 15:25:06 -0700 Subject: [PATCH 09/11] Feedback addressed --- openid-caep-interoperability-profile-1_0.md | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/openid-caep-interoperability-profile-1_0.md b/openid-caep-interoperability-profile-1_0.md index 9426dab..4d89194 100644 --- a/openid-caep-interoperability-profile-1_0.md +++ b/openid-caep-interoperability-profile-1_0.md @@ -207,18 +207,16 @@ All events MUST be signed using the `RS256` algorithm using a minimum of 2048-bi ### 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. A short lived access token could be defined as `exp` claim no longer than 60 mins after `nbf`. Please refer Access token lifetimes in the security considerations {{FAPI}} for additional considerations. +* 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 Access token lifetimes in the security considerations {{FAPI}} for additional considerations. ** client credential grant flow {{RFC6749}} section 4.4 ** authorization code flow {{RFC6749}} section 4.1 ### OAuth Scopes -The client could discover OAuth scopes needed to access the reource by 2 separate mechanisms depending on the support from the OAuth service +Depending on the OAuth Authorization Service features, the client SHALL discover the OAuth scopes as follows: -#### Resource Server -The OAuth scopes required to access the resources MAY be obtained by the client using {{OPRM}} hosted by the Resource Server. +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. -#### Authorization Server -In the absence of Resource server's support for {{OPRM}} the following process should be adopted - +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 From fca28b976c8a7233cd39b4c5e785f8a367d5682d Mon Sep 17 00:00:00 2001 From: Apoorva Deshpande Date: Thu, 23 May 2024 17:02:46 -0700 Subject: [PATCH 10/11] More changes --- openid-caep-interoperability-profile-1_0.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/openid-caep-interoperability-profile-1_0.md b/openid-caep-interoperability-profile-1_0.md index 4d89194..534b9af 100644 --- a/openid-caep-interoperability-profile-1_0.md +++ b/openid-caep-interoperability-profile-1_0.md @@ -212,7 +212,7 @@ All events MUST be signed using the `RS256` algorithm using a minimum of 2048-bi ** authorization code flow {{RFC6749}} section 4.1 ### OAuth Scopes -Depending on the OAuth Authorization Service features, the client SHALL discover the OAuth scopes as follows: +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. @@ -221,7 +221,7 @@ Depending on the OAuth Authorization Service features, the client SHALL discover * 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 use the scope in the same nomenclature as `ssf.manage.poll` +* 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 f8af893eaf588f62abd26c7e4a73cd98cb0248d3 Mon Sep 17 00:00:00 2001 From: Apoorva Deshpande Date: Mon, 10 Jun 2024 12:18:25 -0700 Subject: [PATCH 11/11] Update openid-caep-interoperability-profile-1_0.md Co-authored-by: Shayne Miel (he/him) --- 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 534b9af..81000a4 100644 --- a/openid-caep-interoperability-profile-1_0.md +++ b/openid-caep-interoperability-profile-1_0.md @@ -207,7 +207,7 @@ All events MUST be signed using the `RS256` algorithm using a minimum of 2048-bi ### 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 Access token lifetimes in the security considerations {{FAPI}} for additional considerations. +* 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. ** client credential grant flow {{RFC6749}} section 4.4 ** authorization code flow {{RFC6749}} section 4.1