[Openid-specs-fapi] Issue #385: Grant Management: ambiguities around update (openid/fapi)

[Brian Campbell]

New issue 385: Grant Management: ambiguities around update
https://bitbucket.org/openid/fapi/issues/385/grant-management-ambiguities-around-update

Brian Campbell:

It’s a bit unclear what a grant update is intended to mean - overwrite or append/merge? Something else? AS decides?

I’d guess that it’s intended to mean append/merge. But there’s some text in Implementation Considerations, “update and append actions” that is maybe left over from a prior approach in the document but sort of suggests that update is something distinct from append. 

Also, if the AS doesn’t support update \(`grant_update_supported`\) and receives a request with a legit `grant_id`, what is supposed to happen? Error or ignore the given grant\_id and assign a new one \(subject to `grant_id_supported` and/or `grant_id_required`\)? Following the logic quoted below \(or trying anyway\), I think the “Otherwise” kicks in and the only mandated behavior in this situation is that there can’t be grant id in the token response. Which doesn’t sit quite right. 

> The `grant_id` value MUST have been issued by the respective authorization server and the respective client MUST be authorized to use the particular grant id. If the parameter is present and the AS supports grant updates \(see \(#server\_metadata\)\), the AS will assign all permissions as consented by the user in the actual request to the respective grant. If the parameter is not present and the AS always issues grant ids or the AS optionally issues grant ids \(see \(#server\_metadata\)\) and the client requires grant ids \(see \(#client\_metadata\)\), the AS MUST create a new grant and return the respective grant id in the token response. Otherwise, the AS MUST NOT return a grant id in the token response.

‌