Hi
On 13/02/13 22:19, Torsten Lodderstedt wrote:
Hi all,
I just published a new revision, which should cover all the issues
raised/dicussed during WGLC.
I applied the following changes:
- introduced a new parameter "token_type_hint", which a client may use
to give the authorization server a hint about the type of the token to
be revoked
- replaced "authorization" by "authorization grant"
- an attempt to revoke an invalid token is now handled like a successful
revocation request (status code 200)
Does it create some precedent, meaning that while people suggest using
4xx statuses to indicate different sort of failures in this case 200 is
returned, to eliminate a potential security attack. I mean, should it
become the recommended practice ?
For example, in the discussion about DELETE, should it be 204 that is
returned all the time ?
Sergey
- CORS is now a MAY instead of SHOULD
- extended description of how developer/client may obtain endpoint location
- Improved wording regarding expected client behavior after sucessful
processing of the revocation request -> "The client must assume the
revocation is immediate upon the return of the request."
- Explanation of different policies and why having different server
policies should not cause interop problems
- aligned structure with core spec by introducing sub-sections for
request and response
regards,
Torsten.
Am 13.02.2013 23:13, schrieb internet-dra...@ietf.org:
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Web Authorization Protocol Working
Group of the IETF.
Title : Token Revocation
Author(s) : Torsten Lodderstedt
Stefanie Dronia
Marius Scurtescu
Filename : draft-ietf-oauth-revocation-05.txt
Pages : 9
Date : 2013-02-13
Abstract:
This document proposes an additional endpoint for OAuth authorization
servers, which allows clients to notify the authorization server that
a previously obtained refresh or access token is no longer needed.
This allows the authorization server to cleanup security credentials.
A revocation request will invalidate the actual token and, if
applicable, other tokens based on the same authorization grant.
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-revocation
There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-oauth-revocation-05
A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-revocation-05
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
