Authorization server metadata uses `scopes_supported` key vs SSF using `supported_scopes`

[appsdesh]

In order to bring consistency and reduce confusion should we align with RFC8414 to use supported_scopes as key in the SSF config metadata?

[tulshi]

Actually I thought we deliberately made this different because the intent of those two fields is different. It should be in the meeting notes.

[appsdesh]

Actually I thought we deliberately made this different because the intent of those two fields is different. It should be in the meeting notes.

@atultulshi

The original meeting notes from 6/27 refer the field as scopes_supported

In the following meeting of 7/11 we restructured the JSON, and made it supported_scope. There are no references of consciously changing the naming to avoid conflict, so I assume this is just an oversight.

I agree that it could be confusing wrt OAuth metadata, so I suggest, using completely different naming rather than just flipping 2 words.

Some suggestions -

1. scopes_required
2. scopes_mandatory

[tulshi]

I don't think the intent of the fields is that those scopes are required or mandatory though. They describe scopes that are supported by the AS.

[appsdesh]

I don't think the intent of the fields is that those scopes are required or mandatory though. They describe scopes that are supported by the AS.

The field itself is OPTIONAL but if it has scopes populated then it would be mandatory to request the token.

OAuth tokens obtained using any of the scopes defined here MUST be accepted by the specified endpoint.

[appsdesh]

@atultulshi I came across OAuth 2.0 Protected Resource Metadata and it would make more sense to not stuff OAuth properties in the SSF metadata.

This spec suggests having a separate per protected resource metadata for the OAuth server.

[mcguinness]

I don't think OpenID Shared Signals Framework Specification configuration discovery metadata should directly include OAuth Resource Server metadata like scopes or authorization servers. There is no requirement that SSF endpoints are OAuth 2.0 Protected Resources.

I see this working similar to SCIM where SSF metadata publishes supported authenticationSchemes like https://datatracker.ietf.org/doc/html/rfc7643#section-5

"authenticationSchemes": [
   {
     "name": "OAuth Bearer Token",
     "description":
       "Authentication scheme using the OAuth Bearer Token Standard",
     "specUri": "http://www.rfc-editor.org/info/rfc6750",
     "documentationUri": "http://example.com/help/oauth.html",
     "type": "oauthbearertoken",
     "primary": true
   }
]

When a SSF transmitter indicates support for OAuth 2.0 a client can then use OAuth based discovery calls according to those specifications.

1. Get SSF Configuration Metadata

GET /.well-known/ssf-configuration HTTP/1.1
Host: tr.example.com

2. Discover OAuth as supported authentication scheme. Perform OAuth Protected Resource discovery for a published SSF management endpoint

GET /ssf/mgmt/stream/.well-known/oauth-protected-resource HTTP/1.1
Host: tr.example.com

3. Discover the Authorization Server, scopes, etc needed for the endpoint. Perform OAuth Authorization Server discovery for the Authorization Server

GET /.well-known/oauth-authorization-server HTTP/1.1
Host: tr.example.com

4. Client now as all the data needed to obtain an access_token for a SSF management endpoint

This keeps SSF decoupled from OAuth and allows the relevant OAuth specs to address discovery use cases for OAuth client scenarios

[independentid]

I tend to agreeI have some concerns where stream endpoints are common and a bearer token is required to determine stream. This means administrative access and other scenarios are complex.  Eg do admins keep a copy of the stream token?  Sounds like a bad practice.  If I manage multiple streams do I need another separate token for that?I am also concerned about how SSF will couple nicely with typical oauth2 implementations such that it doesn’t requires its own token issuer to issue special claims and authorization scopes. Karl’s comments are a good way to start thinking about the issue. Phil

[tulshi]

I agree with Karl's proposal of not having the authorization related information in the Transmitter Configuration Metadata. The mechanism he has outlined, which is based on existing standards will work well, I think.

On Mon, Aug 14, 2023 at 1:04 PM Phil Hunt @.***> wrote:

I tend to agreeI have some concerns where stream endpoints are common and a bearer token is required to determine stream. This means administrative access and other scenarios are complex. Eg do admins keep a copy of the stream token? Sounds like a bad practice. If I manage multiple streams do I need another separate token for that?I am also concerned about how SSF will couple nicely with typical oauth2 implementations such that it doesn’t requires its own token issuer to issue special claims and authorization scopes. Karl’s comments are a good way to start thinking about the issue. PhilOn Aug 14, 2023, at 10:57 AM, Karl McGuinness @.***> wrote: I don't think OpenID Shared Signals Framework Specification configuration discovery metadata should directly include OAuth Resource Server metadata like scopes or authorization servers. There is no requirement that SSF endpoints are OAuth 2.0 Protected Resources. I see this working similar to SCIM where SSF metadata publishes supported authenticationSchemes like https://datatracker.ietf.org/doc/html/rfc7643#section-5 "authenticationSchemes": [ { "name": "OAuth Bearer Token", "description": "Authentication scheme using the OAuth Bearer Token Standard", "specUri": "http://www.rfc-editor.org/info/rfc6750", "documentationUri": "http://example.com/help/oauth.html", "type": "oauthbearertoken", "primary": true } ]

When a SSF transmitter indicates support for OAuth 2.0 a client can then use OAuth based discovery calls according to those specifications.

Get SSF Configuration Metadata

GET /.well-known/ssf-configuration HTTP/1.1 Host: tr.example.com

Discover OAuth as supported authentication scheme. Perform OAuth Protected Resource discovery for a published SSF management endpoint

GET /ssf/mgmt/stream/.well-known/oauth-protected-resource HTTP/1.1 Host: tr.example.com

Discover the Authorization Server, scopes, etc needed for the endpoint. Perform OAuth Authorization Server discovery for the Authorization Server

GET /.well-known/oauth-authorization-server HTTP/1.1 Host: tr.example.com

Client now as all the data needed to obtain an access_token for a SSF management endpoint

This keeps SSF decoupled from OAuth and allows the relevant OAuth specs to address discovery use cases for OAuth client scenarios

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: @.***>

— Reply to this email directly, view it on GitHub https://github.com/openid/sharedsignals/issues/95#issuecomment-1677982404, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB55UG75IZ7OOA5SAJ25MF3XVKAFHANCNFSM6AAAAAA3CGN44I . You are receiving this because you commented.Message ID: @.***>

[mcguinness]

It seems like there isn't consensus for the proposed change in draft2. I suggest we revert the change before the draft is published so to set expectations with folks building implementations now of the draft. We can continue to hash out additional changes on this thread and WG calls to see if we want to include any other proposal before draft2 is published.