Grant Management Revoke Grant response

[Filip Skokan]

## Revoke Grant 

To revoke a grant, the client sends a HTTP DELETE request to the grant's resource URL. The authorization server responds with a HTTP status code 204 and an empty response body.

This is illustrated by the following example.

```http
DELETE /grants/TSdqirmAxDa0_-DB_1bASQ 
Host: as.example.com
Authorization: Bearer 2YotnFZFEjr1zCsicMWpAA

HTTP/1.1 204 No Content
```

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. 

Note: Token revocation as defined in [@RFC7009] differentiates from grant revocation as defined in this specification in that token revocation is not required to cause the revocation of the underlying grant. It is at the discretion of the AS to retain a grant in case of token revocation and allow the client to re-connect to this grant through a subsequent authorization request. This decoupling may improve user experience in case the client just wanted to discard the token as a credential.

This section needs to address the behaviour when the underlying Grant is invalid/not found. Does it behave similar to revocation (returning 204 anyway) or returns a 400 invalid_grant?

‌

[Brian Campbell]

wouldn’t that be an HTTP 404?

[Filip Skokan]

Similar to revocation i think it should be 204 no content regardless of the grant found or not.

[Brian Campbell]

I’ve never found the reasoning for the “always 200” behavior of revocation particularly compelling or intuitive. And I think the context of use here is arguably somewhat different. But maybe that’s just me. There’s probably a philosophical debate about deletes and idempotency here too but I’m not really qualified to have it (or particularity interested TBH).

In a comment on #376 you said, “can’t dictate invalid route behaviours for all authorization servers” which seems quite reasonable. But this ticket would suggest that the document should dictate such behavior for DELETE requests but not GET. Or do I misunderstand?

One thing I’d really like to avoid is having unneeded requirements in the document that later result in nitpicky conformance tests looking for specific codes in situations where it doesn’t really matter. I suspect this might be one such area. And it might be better for the document to not mandate anything in the case the underlying Grant is invalid or not found.

‌

‌

‌

‌

[Filip Skokan]

In a comment on #376 you said, “can’t dictate invalid route behaviours for all authorization servers” which seems quite reasonable. But this ticket would suggest that the document should dictate such behavior for DELETE requests but not GET. Or do I misunderstand?

There’s a difference between what i say in #376 an invalid route, and this where the AS clearly supports the API and the client wants to perform revocation. If it’s revoked as a result of the request or was already revoked/invalid, the client needs not to know. Request was successful, the grant_is ensured to be deleted. If anything i wouldn’t burden the client with additional errors that may pop up in implementations if we don’t mandate this “always 204” behaviour.

‌

[Dima Postnikov]

Thanks @Filip Skokan and @Brian Campbell . I can see rationale for both options (204 and 404), although 204 seems a little more consistent way forward given this endpoint might be used in a similar way as token revocation endpoint.

Agree to leave it as 204?

[Brian Campbell]

Well, I’d say that the current text of the document, “If the resource URL is unknown, the authorization server responds with HTTP status code 400.” requires it to be a 400. That probably will be fixed as part of Issue #376. I’d prefer that specific behavior not be mandated here but don’t really care enough to argue about it more.

‌

[Filip Skokan]

‌

If the resource URL is unknown, the authorization server responds with HTTP status code 400.

This to speaks about hitting a non-existing endpoint, route, or path.

‌

[Brian Campbell]

Given the way “resource URL” is used elsewhere in the document, particularly the “Grant Resource URL” section, I took it as being specifically about the Grant Resource URL or basically any path under the base Grant Resource URL. I suppose more precise language is needed regardless.

[Stuart Low]

Isn’t the “always success” approach related to avoiding information disclosure and/or simpler replay?

[Dima Postnikov]

Discussed with Torsten and Stuart and decided to adopt standard HTTP / RESTful error codes:

• Successful grant deletion 204
• Not authorized 403
• Non existent grant or invalid URL 404

@Brian Campbell @Filip Skokan objections?

Any other comments?

‌

[Filip Skokan]

Looks good to me. But what is considered as “Invalid URL”?

[Dima Postnikov]

yeah, ok

• Successful grant deletion 204
• Not authorized 403
• Non existent grant 404

‌

[Filip Skokan]

Perfect.

[Brian Campbell]

works for me

[Dima Postnikov]

PR https://bitbucket.org/openid/fapi/pull-requests/272

[Dima Postnikov]

PR has been merged