Atul's feedback

Author: appsdesh

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