Atul's comments addressed

Atul's comments addressed

Author: appsdesh

openid-sharedsignals-framework-1_0.md

@@ -552,18 +552,23 @@ TODO: consider adding a IANA Registry for metadata, similar to Section 7.1.1 of
 {{RFC8414}}. This would allow other specs to add to the metadata.
 
 ### Authorization scheme {#authorization-scheme}
-SSF is an HTTP based signals sharing framework. It is agnostic to the authentication and authorization schemes used to secure stream configuration APIs. It does not provide any SSF specific authentication and authorization schemes but relies on the cooperating parties mutual security considerations. Authorization scheme section of the metadata, providers discovery information related to the transmitter's stream management APIs.
+SSF is an HTTP based signals sharing framework. It is agnostic to the authentication and authorization schemes used to secure stream configuration APIs. It does not provide any SSF specific authentication and authorization schemes but relies on the cooperating parties' mutual security considerations. Authorization scheme section of the metadata, providers discovery information related to the transmitter's stream management APIs.
 
 spec_urn  
 
 > REQUIRED. A URN that describes the specification of the protocol being used.
 
 The receiver will call the transmitter APIs by providing appropriate credentials as per the `spec_urn`.
 
+The following is a non-normative example of the `spec_urn`
 
-If the `spec_urn` in Authorization scheme is `urn:ietf:rfc6749`
+~~~ json
+   {
+        "spec_urn": "urn:ietf:rfc:6749"
+   }
+~~~
 
-- The receiver may obtain an access token using the Client
+In this case, the receiver may obtain an access token using the Client
 Credential Grant {{CLIENTCRED}}, or any other method suitable for the Receiver and the
 Transmitter.
 
@@ -1452,9 +1457,9 @@ Errors are signaled with HTTP status codes as follows:
 
 Examples:
 
-1. If a Receiver makes a request with an invalid token, then the
+1. If a Receiver makes a request with an improper authorization, then the
    Transmitter MUST respond with a 401 error status.
-2. If the Receiver presents a valid token, but the Transmitter policy
+2. If the Receiver presents a valid authorization, but the Transmitter policy
    does not permit the Receiver from obtaining the status, then the Transmitter
    MAY respond with a 403 error status.
 3. If the Receiver requests the status for a stream that does not exist then the