[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