[Openid-specs-fapi] Issue #454: Expected behavior for grant_management_action=replace (openid/fapi)

[Takahiko Kawasaki]

New issue 454: Expected behavior for grant_management_action=replace
https://bitbucket.org/openid/fapi/issues/454/expected-behavior-for

Takahiko Kawasaki:

The following requirement in “[6.5. Revoke Grant](https://openid.net/specs/fapi-grant-management-ID1.html#name-revoke-grant)”

> The AS MUST revoke the grant and all refresh tokens issued based on that particular grant, it SHOULD revoke all access tokens issued based on that particular grant.

requires authorization server implementations to track the relationship between a grant ID and refresh tokens. From the description, it is clear that the “grant revoke” request to the grant management endpoint will result in revoking all relevant refresh tokens.

On the other hand, the following description in “[3.3. Replace the details of a grant](https://openid.net/specs/fapi-grant-management-ID1.html#name-replace-the-details-of-a-gr)”

> In some scenarios, clients might choose to replace the grant with the new one while keeping the same grant id. Old privileges will be revoked and new privileges will be added if approved by the user. The client has to specify full details of the new request.

and the explanation about `replace` in “[5.2. Authorization Request](https://openid.net/specs/fapi-grant-management-ID1.html#name-authorization-request)“

> `replace`: this mode requires the client to specify a grant id using the `grant_id` paramter. If the parameter is present and the AS supports the grant management action `replace`, the AS will change the grant to be ONLY the permissions requested by the client and consented by the user in the actual request.

are not so clear in terms of refresh token revocation.

A question raised here is as follows:

Which is the expected behavior for `grant_management_action=replace`?

1. Just break the relationship. The previously-referenced refresh tokens remain valid.
2. Break the relationship and revoke the previously-referenced refresh tokens.

See also the attached image which illustrates the question visually.