Tim's comments addressed

Tim's comments addressed

Author: appsdesh

openid-sharedsignals-framework-1_0.md

@@ -609,7 +609,7 @@ critical_subject_members
 
 authorization_schemes
 
-> OPTIONAL. A list of JSON objects that specify the supported
+> OPTIONAL. An array of JSON objects that specify the supported
   authorization scheme properties defined in {{authorization-scheme}}.  To enable seamless discovery of
   configurations, the service provider SHOULD, with the appropriate
   security considerations, make the authorization_schemes attribute
@@ -620,7 +620,7 @@ 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. The authorization scheme section of the metadata provides discovery information related to the transmitter's stream management APIs.
+SSF is an HTTP based signals sharing framework and 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. The authorization scheme section of the metadata provides discovery information related to the transmitter's stream management APIs.
 
 spec_urn  
 
@@ -1543,9 +1543,9 @@ Errors are signaled with HTTP status codes as follows:
 
 Examples:
 
-1. If a Receiver makes a request with an improper authorization, then the
+1. If a Receiver makes an unauthorized request, then the
    Transmitter MUST respond with a 401 error status.
-2. If the Receiver presents a valid authorization, but the Transmitter policy
+2. If a Receiver makes an authorized request, 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
@@ -2143,7 +2143,7 @@ The purpose is defense in depth against confusion with other JWTs, as described
 in Sections 4.5 and 4.6 of {{RFC8417}}.
 
 ### The "aud" Claim {#aud-claim}
-The "aud" claim can be a single value (string) or an array of strings. Values that 
+The "aud" claim can be a single string or an array of strings. Values that 
 uniquely identify the Receiver to the Transmitter MAY be used, if the two parties
 have agreement on the format.