Include OAuth specifics in the interop spec (#134)

* Include OAuth specifics in the interop spec

Include OAuth specifics in the interop spec

* Atul's feedback

* Include OAuth specifics in the interop spec

Include OAuth specifics in the interop spec

* Include OAuth specifics in the interop spec

Include OAuth specifics in the interop spec

* Updates

1. Shayne's suggestion
2. CAEP version

* Update openid-caep-interoperability-profile-1_0.md

* Update openid-caep-interoperability-profile-1_0.md

* Atul's feedback

Atul's feedback

* Feedback addressed

* More changes

* Update openid-caep-interoperability-profile-1_0.md

Co-authored-by: Shayne Miel (he/him) <[email protected]>

---------

Co-authored-by: Apoorva Deshpande <[email protected]>
Co-authored-by: Shayne Miel (he/him) <[email protected]>

Author: 3 people

openid-caep-interoperability-profile-1_0.md

@@ -21,8 +21,6 @@ author:
         name: Atul Tulshibagwale
         org: SGNL
         email: [email protected]
-
-contributor:
       -
         ins: A. Deshpande
         name: Apoorva Deshpande
@@ -74,10 +72,32 @@ 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:
+  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}}. 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}} 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.
 
 --- middle
 
@@ -93,6 +113,14 @@ 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 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 2
+
 ## Transmitters {#common-transmitters}
 Transmitters MUST implement the following features:
 
@@ -176,6 +204,34 @@ 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
+* 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. 
+** client credential grant flow {{RFC6749}} section 4.4
+** authorization code flow {{RFC6749}} section 4.1
+
+### 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`
+* 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}}
+* 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.
+* 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.
+
 ## Security Event Token
 
 ### The "events" claim