[Query] Best approach to handle authorization_details and scope conflicts

[VimukthiRajapaksha]

Hi,

The "Relationship to the 'scope' Parameter" section[1] says both authorization_details and scope can be used in the same authorization request. We're unsure what happens when there's a conflict between them in the same request. For example, imagine a scenario where an authorization request has both the READ_ACCOUNTS scope and the following authorization_details JSON.

[
  {
    "type": "account_information",
    "actions": [
      "WRITE_ACCOUNTS"
    ],
    "locations": [
      "https://example.com/accounts"
    ]
  }
]

curl https://www.auth-server.com/authorize? \
	response_type=code& \
	client_id=<client_id>& \
	redirect_uri=https://www.example.com/callback& \
	scope=READ_ACCOUNTS& \
	authorization_details=[{"type":"account_information","actions":["WRITE_ACCOUNTS"],"locations":["https://example.com/accounts"]}]

When the scope and authorization_details conflict, does one take precedence? Or, if it's different for each API, may we know what is the best practice suggested by the specification?

[1] https://datatracker.ietf.org/doc/html/rfc9396#name-relationship-to-the-scope-p

Thanks,
Vimukthi

[tlodderstedt]

Hi, the behavior in such a case needs to be determined by your implementation. You might define a precedence, preferable only option should be support per RS. Please note that the RFC states: "It is RECOMMENDED that a given API use only one form of requirement specification." best regards, Torsten. Am 21. Dez. 2023, 13:25 +0100 schrieb Vimukthi Rajapaksha ***@***.***>:

…

Hi, The "Relationship to the 'scope' Parameter" section[1] says both authorization_details and scope can be used in the same authorization request. We're unsure what happens when there's a conflict between them in the same request. For example, imagine a scenario where an authorization request has both the READ_ACCOUNTS scope and the following authorization_details JSON. [ { "type": "account_information", "actions": [ "WRITE_ACCOUNTS" ], "locations": [ "https://example.com/accounts" ] } ] curl https://www.auth-server.com/authorize? \ response_type=code& \ client_id=<client_id>& \ redirect_uri=https://www.example.com/callback& \ scope=READ_ACCOUNTS& \ authorization_details=[{"type":"account_information","actions":["WRITE_ACCOUNTS"],"locations":["https://example.com/accounts"]}] When the scope and authorization_details conflict, does one take precedence? Or, if it's different for each API, may we know what is the best practice suggested by the specification? [1] https://datatracker.ietf.org/doc/html/rfc9396#name-relationship-to-the-scope-p Thanks, Vimukthi — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[jricher]

It is definitely per-API to determine the precedence, just like with plain scope values on their own -- if I ask for "write" vs "read write" is that the same, or different? It depends on the API, really - you could have an API with a write-only option so they'd be different, or you could have write subsume the read operation. The same logic applies here with RAR.

One approach is to define each existing scope value as expanding to a specific RAR object structure, and then define how the different RAR structures compare to each other.
A sensible interpretation of your specific example would be READ_ACCOUNTS with no other details means it applies across all possible accounts but WRITE_ACCOUNTS at that specific location (and not others). But if, for example, there's only one applicable location, this wouldn't really be different, and you'd have to decide whether the write subsumes the read or they add to each other.