From 28c9f64c759fcb3e43319b449ebb6439a24cc265 Mon Sep 17 00:00:00 2001 From: Apoorva Deshpande Date: Thu, 17 Aug 2023 17:00:37 -0700 Subject: [PATCH] Decouple SSF from OAuth protocol Revert #83 Atul's comments addressed Atul's comments addressed Review comments addressed Review comments addressed Removed type from authorization scheme - More OAuth agnostic changes - Removed OPRM references spec_urn verbiage changes spec_urn verbiage changes spec_urn Updated to read spec_urn Removed OAuth2 references from the aud claim Removed OAuth2 references from the aud claim Metadata attribute details Added more details around the metadata attributes Update openid-sharedsignals-framework-1_0.md Added references to protected resource metadata Added references to protected resource metadata --- openid-sharedsignals-framework-1_0.md | 71 +++++++++++---------------- 1 file changed, 29 insertions(+), 42 deletions(-) diff --git a/openid-sharedsignals-framework-1_0.md b/openid-sharedsignals-framework-1_0.md index 1b8c8db..8236159 100644 --- a/openid-sharedsignals-framework-1_0.md +++ b/openid-sharedsignals-framework-1_0.md @@ -141,6 +141,7 @@ normative: target: https://datatracker.ietf.org/doc/html/draft-ietf-secevent-subject-identifiers title: Subject Identifiers for Security Event Tokens + informative: CAEP: author: @@ -537,42 +538,39 @@ critical_subject_members > OPTIONAL. An array of member names in a Complex Subject which, if present in a Subject Member in an event, MUST be interpreted by a Receiver. - -supported_scopes -> OPTIONAL. A list of OAuth {{RFC6749}} scope names that the Transmitter supports for specific endpoints. The value of this field is a JSON object that has the endpoint names as keys, and arrays of scope name strings they support as their values. OAuth tokens obtained using any of the scopes defined here MUST be accepted by the specified endpoint. Any key that is not defined as an endpoint in the Transmitter Configuration Metadata MUST be ignored. If the supported_scopes member is present in the metadata and an endpoint is not listed as a key, then that endpoint MUST not require OAuth for authorization. +authorization_schemes -authorization_servers +> 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 + publicly accessible without prior authentication. -> OPTIONAL. An array of supported authorization servers and the scopes they support. Each element of the array is a Authorization Server Descriptor JSON object defined in the section {{authz-server-descriptor}} below. If the `supported_scopes` member is present in the metadata, then the `authorization_servers` MUST also be present, and it MUST provide a server location for every supported scope. 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 Server Descriptor {#authz-server-descriptor} -An Authorization Server Descriptor is a JSON object that has two keys: - -scopes +### 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. -> REQUIRED. An array of scope names supported by the authorization server +spec_urn -servers +> REQUIRED. A URN that describes the specification of the protocol being used. -> REQUIRED. An array of authorization server URLs. This is the URL from which the Authorization Server Metadata MAY be obtained by following the process described in Section 3 of RFC8414 {{RFC8414}} +The receiver will call the transmitter APIs by providing appropriate credentials as per the `spec_urn`. -The following is a non-normative example of an Authorization Server Descriptor +The following is a non-normative example of the `spec_urn` ~~~ json -{ - "scopes" : ["scope1", "scope2"], - "servers": [ - "https://server1.example/base/url", - "https://server2.example/base/url", - "https://server3.example/base/url" - ] -} + { + "spec_urn": "urn:ietf:rfc:6749" + } ~~~ -{: #authz-descriptor-example title="Example Authorization Server Descriptor"} + +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. ## Obtaining Transmitter Configuration Information @@ -671,17 +669,14 @@ Content-Type: application/json "verification_endpoint": "https://tr.example.com/ssf/mgmt/verification", "critical_subject_members": [ "tenant", "user" ], - "supported_scopes": + "authorization_schemes":[ { - "status_endpoint": ["status_scope"], - "configuration_endpoint": ["admin_scope", "status_scope"] + "spec_urn": "urn:ietf:rfc:6749" }, - "authorization_servers": [ { - "scopes": ["admin_scope", "status_scope"], - "servers": ["https://myauthzserver.example"] + "spec_urn": "urn:ietf:rfc:8705" } - ] + ] } ~~~ {: #figdiscoveryresponse title="Example: Transmitter Configuration Response"} @@ -1462,9 +1457,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 improper authorization, 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 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 @@ -1878,14 +1873,6 @@ subject ~~~ {: title="Example: Stream Updated SET with stream as the subject of single-stream Transmitter" #figstreamupdatedstreamset} -# Authorization {#management-api-auth} -HTTP API calls from a Receiver to a Transmitter SHOULD be authorized by -providing an OAuth 2.0 Access Token as defined by {{RFC6750}}. - -The receiver may obtain an access token using the Client -Credential Grant {{CLIENTCRED}}, or any other method suitable for the Receiver and the -Transmitter. - # Security Considerations {#management-sec} ## Subject Probing {#management-sec-subject-probing} @@ -2064,9 +2051,9 @@ 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 or an array. Each value SHOULD be the -OAuth 2.0 client ID. Other values that uniquely identifies the Receiver to the -Transmitter MAY be used, if the two parties have agreement on the format. +The "aud" claim can be a single value (string) or an array of strings. Values that +uniquely identifies the Receiver to the Transmitter MAY be used, if the two parties +have agreement on the format. More than one value can be present if the corresponding Receivers are known to the Transmitter to be the same entity, for example a web client and a mobile