incorporated Apoorva\'s feedback

Author: tulshi

openid-sharedsignals-framework-1_0.html

@@ -2032,13 +2032,13 @@ <h3 id="name-transmitter-configuration-m">
 <p id="section-6.1-20">supported_scopes<a href="#section-6.1-20" class="pilcrow">¶</a></p>
 <ul class="normal ulEmpty">
 <li class="normal ulEmpty" id="section-6.1-21.1">
-            <p id="section-6.1-21.1.1">OPTIONAL. A list of OAuth <span>[<a href="#RFC6749" class="cite xref">RFC6749</a>]</span> 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<a href="#section-6.1-21.1.1" class="pilcrow">¶</a></p>
+            <p id="section-6.1-21.1.1">OPTIONAL. A list of OAuth <span>[<a href="#RFC6749" class="cite xref">RFC6749</a>]</span> 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 <code>supported_scopes</code> member is present in the metadata, and if an endpoint is not present as a key in it, then the endpoint MUST NOT require OAuth for authorization.<a href="#section-6.1-21.1.1" class="pilcrow">¶</a></p>
 </li>
         </ul>
 <p id="section-6.1-22">authorization_servers<a href="#section-6.1-22" class="pilcrow">¶</a></p>
 <ul class="normal ulEmpty">
 <li class="normal ulEmpty" id="section-6.1-23.1">
-            <p id="section-6.1-23.1.1">OPTIONAL. An array supported authorization servers and the scopes they support. Each element of the array is a Authorization Server Descriptor JSON object defined in the section <a href="#authz-server-descriptor" class="auto internal xref">Section 6.1.1</a> below.<a href="#section-6.1-23.1.1" class="pilcrow">¶</a></p>
+            <p id="section-6.1-23.1.1">OPTIONAL. An array supported authorization servers and the scopes they support. Each element of the array is a Authorization Server Descriptor JSON object defined in the section <a href="#authz-server-descriptor" class="auto internal xref">Section 6.1.1</a> below. If the <code>supported_scopes</code> member is present in the metadata, then the <code>authorization_servers</code> MUST also be present, and it MUST provide a server location for every supported scope.<a href="#section-6.1-23.1.1" class="pilcrow">¶</a></p>
 </li>
         </ul>
 <p id="section-6.1-24">TODO: consider adding a IANA Registry for metadata, similar to Section 7.1.1 of

openid-sharedsignals-framework-1_0.md

@@ -540,11 +540,11 @@ critical_subject_members
 
 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
+> 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 if an endpoint is not present as a key in it, then the endpoint MUST NOT require OAuth for authorization.
 
 authorization_servers
 
-> OPTIONAL. An array 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.
+> OPTIONAL. An array 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.

openid-sharedsignals-framework-1_0.txt

@@ -571,13 +571,18 @@ Tulshibagwale, et al.        Standards Track                   [Page 10]
       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
+      ignored.  If the supported_scopes member is present in the
+      metadata, and if an endpoint is not present as a key in it, then
+      the endpoint MUST NOT require OAuth for authorization.
 
    authorization_servers
 
       OPTIONAL.  An array supported authorization servers and the scopes
       they support.  Each element of the array is a Authorization Server
       Descriptor JSON object defined in the section Section 6.1.1 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
@@ -602,6 +607,17 @@ Tulshibagwale, et al.        Standards Track                   [Page 10]
    The following is a non-normative example of an Authorization Server
    Descriptor
 
+
+
+
+
+
+
+Tulshibagwale, et al.        Standards Track                   [Page 11]
+
+                              SharedSignals                    June 2023
+
+
    {
        "scopes" : ["scope1", "scope2"],
        "servers": [
@@ -611,13 +627,6 @@ Tulshibagwale, et al.        Standards Track                   [Page 10]
        ]
    }
 
-
-
-Tulshibagwale, et al.        Standards Track                   [Page 11]
-
-                              SharedSignals                    June 2023
-
-
              Figure 9: Example Authorization Server Descriptor
 
 6.2.  Obtaining Transmitter Configuration Information
@@ -657,15 +666,6 @@ Tulshibagwale, et al.        Standards Track                   [Page 11]
    GET /.well-known/ssf-configuration/issuer1 HTTP/1.1
    Host: tr.example.com
 
-     Figure 11: Example: Transmitter Configuration Request (with path)
-
-   Using path components enables supporting multiple issuers per host.
-   This is required in some multi-tenant hosting configurations.  This
-   use of ".well-known" is for supporting multiple issuers per host;
-   unlike its use in [RFC5785], it does not provide general information
-   about the host.
-
-
 
 
 
@@ -674,6 +674,14 @@ Tulshibagwale, et al.        Standards Track                   [Page 12]
                               SharedSignals                    June 2023
 
 
+     Figure 11: Example: Transmitter Configuration Request (with path)
+
+   Using path components enables supporting multiple issuers per host.
+   This is required in some multi-tenant hosting configurations.  This
+   use of ".well-known" is for supporting multiple issuers per host;
+   unlike its use in [RFC5785], it does not provide general information
+   about the host.
+
 6.2.2.  Backward Compatibility for RISC Transmitters
 
    Existing RISC Transmitters MAY continue to use the path component
@@ -717,14 +725,6 @@ Tulshibagwale, et al.        Standards Track                   [Page 12]
 
 
 
-
-
-
-
-
-
-
-
 Tulshibagwale, et al.        Standards Track                   [Page 13]
 
                               SharedSignals                    June 2023