[Openid-specs-fapi] Issue #289: resource and scopes in grant management (openid/fapi)
tlodderstedt
issues-reply at bitbucket.org
Sat May 2 12:31:12 UTC 2020
New issue 289: resource and scopes in grant management
https://bitbucket.org/openid/fapi/issues/289/resource-and-scopes-in-grant-management
Torsten Lodderstedt:
In a private conversion @{557058:b8e41ea0-12ae-4d1a-9752-c2853862c3f5} raised the topic of the representation of resource indicators in combination with scope values in a grant.
If a grant is created with a resource A and a scope X, the model currently defined in the spec \(resource and scope are kept separate\) works.
> HTTP/1.1 200 OK
> Cache-Control: no-cache, no-store
> Content-Type: application/json
>
> \{
> "scope": "X"
> \}
However, when the grant is updated with another resource B and scope Y, it breaks
> HTTP/1.1 200 OK
> Cache-Control: no-cache, no-store
> Content-Type: application/json
>
> \{
> “resources”:\[”A”,”B”\],
> "scope": "X Y"
> \}
since the user did not consent the combinations resource A/scope Y and resource B/scope X as suggested by the representation.
I feel like we should represent resource/scope combinations as requested and confirmed in the respective authorization requests.
> HTTP/1.1 200 OK
> Cache-Control: no-cache, no-store
> Content-Type: application/json
>
> \{
> "resource\_requests":\[
> \{
> "resources":\["A"\],
> "scope":"X"
> \},
> \{
> "resources":\["B"\],
> "scope":"Y"
> \}\]
> \}
More information about the Openid-specs-fapi
mailing list