Removed type from authorization scheme

- More OAuth agnostic changes
- Removed OPRM references

Author: appsdesh

openid-sharedsignals-framework-1_0.md

@@ -140,17 +140,7 @@ normative:
     date: May 2021
     target: https://datatracker.ietf.org/doc/html/draft-ietf-secevent-subject-identifiers
     title: Subject Identifiers for Security Event Tokens
-  OPRM:
-    author:
-    - ins: M.B. Jones
-      name: Michael B. Jones
-    - ins: P. Hunt
-      name: Phil Hunt
-    - ins: A. Parecki
-      name: Aaron Parecki
-    date: July 2023
-    target: https://datatracker.ietf.org/doc/html/draft-jones-oauth-resource-metadata-04#name-protected-resource-metadata
-    title: OAuth 2.0 Protected Resource Metadata
+
 
 informative:
   CAEP:
@@ -551,7 +541,7 @@ critical_subject_members
 
 authorization_schemes
 
-> OPTIONAL. A multi-valued complex type that specifies supported
+> OPTIONAL. A list of complex type that specifies 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
@@ -562,24 +552,18 @@ 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 schems 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 disovery informaton related to the transmitter's stream management APIs. 
-
-type
-
-> The authorization scheme.  This specification defines the values "oauth",
-  "oauth2", "oauthbearertoken" REQUIRED.
+SSF is an HTTP based signals sharing framework. It is agnostic to the authentication and authorization schems 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 disovery informaton related to the transmitter's stream management APIs.
 
 spec_urn  
 
-> A URN for a specification for the protocol being used  OPTIONAL.
+> A URN for a specification for the protocol being used  REQUIRED.
+
 
+The receiver will call the transmitter APIs by providing appropriate credentials as per the `spec_urn`.
 
-The receiver will call the transmitter APIs by providing appropriate credentials as mentioned in the type.
 
+If the `spec_urn` in Authorization scheme is `urn:ietf:rfc6749`
 
-If the Authorization scheme is OAuth2 
-- The Transmitter SHOULD publish Protected Server Metadata {{OPRM}} to aid the discovery of metadata needed to interact with an OAuth 2.0 protected resource.
-- Discovery of the Protected Server Metadata {{OPRM}} is outside the scope of this specification.
 - The receiver may obtain an access token using the Client
 Credential Grant {{CLIENTCRED}}, or any other method suitable for the Receiver and the
 Transmitter.
@@ -681,14 +665,14 @@ Content-Type: application/json
   "verification_endpoint":
     "https://tr.example.com/ssf/mgmt/verification",
   "critical_subject_members": [ "tenant", "user" ],
-  "authorization_schemes": {
-    [
+  "authorization_schemes":[
       {
-        "type": "oauth2",
         "spec_urn": "urn:ietf:rfc:6749"
+      },
+      {
+        "spec_urn": "urn:ietf:rfc:8705"
       }
     ]
-  }
 }
 ~~~
 {: #figdiscoveryresponse title="Example: Transmitter Configuration Response"}
@@ -1469,9 +1453,9 @@ Errors are signaled with HTTP status codes as follows:
 
 Examples:
 
-1. If a Receiver makes a request with an invalid OAuth token, then the
+1. If a Receiver makes a request with an invalid token, then the
    Transmitter MUST respond with a 401 error status.
-2. If the Receiver presents a valid OAuth token, but the Transmitter policy
+2. If the Receiver presents a valid token, 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