Hi Amanda,
I incoporated your comments. I'm waiting for feedback on the other
threads before I will post another revision.
http://www.ietf.org/mail-archive/web/oauth/current/msg10334.html
http://www.ietf.org/mail-archive/web/oauth/current/msg10331.html
http://www.ietf.org/mail-archive/web/oauth/current/msg10335.html
best regards,
Torsten.
Am 27.12.2012 15:22, schrieb Amanda Anganes:
Hi Torsten,
Responses inline in blue.
On 12/25/2012 08:11 AM, Torsten Lodderstedt wrote:
Hi Amanda,
thank you for reviewing the draft. Comments inline.
Am 30.11.2012 22:28, schrieb Anganes, Amanda L:
Here is my review of the Toke Revocation draft
(http://datatracker.ietf.org/doc/draft-ietf-oauth-revocation/):
Section 1. Introduction
First paragraph has the following definition in it: "A token is the
external representation of an access grant issued by a resource
owner to a particular client." This seems a bit odd to me. The
OAuth2 spec [1] defines "access token" as "An access token is a
string representing an authorization issued to the client." (section
1.4) and "refresh token" as "credentials used to obtain access
tokens (section 1.5). Should this spec borrow similar language to be
more consistent?
What about this:
"A token is a string representing an authorization issued by the
resource owner to the client. A revocation request will invalidate
the actual token and, if applicable, other tokens based on the same
authorization and the authorization itself."
Yes, that sounds more consistent.
Paragraph 2 "From an end-user's perception" should be "From an
end-user's perspective".
changed it.
Section 2. Token Revocation
What is the reason for requiring the service provider to detect the
token type automatically? For our implementation, Access Tokens,
Refresh Tokens, and ID Tokens are all structured tokens (with unique
structures across the three types), and as such are stored in 3
separate database tables. In order to "detect" the token type, we
would need to run a get-by-value query across all three tables,
check if any of those queries returned anything, and then proceed to
revoke the token (if one was found). This does not seem ideal to me.
As pointed out by Justin, there was such a parameter in an early
revision of the draft. WG feedback caused me to remove it. I would
like to stick with auto detection if not otherwise decided by the
working group. I explicitely asked for feedback on the other thread.
The spec says that "The authorization server first validates the
client credentials (in case of a confidential client) and verifies
whether the client is authorized to revoke the particular token."
What does this verification entail? Does it just mean that 1) the
client credentials must validate and 2) the token must belong to the
client requesting the revocation? If so I think the text should be
clarified to reflect that. Or are you thinking of a case where a
client might not be allowed to revoke its own tokens, via some kind
of scoping?
It's 1+2
What about this text
"The authorization server first validates the client credentials (in
case of a confidential client) and then verifies whether the client
is authorized to revoke the token. A client may only revoke a token
if the validation of the client identity succeeds and the particular
token had been issued to this client."
The confusing phrase here is "authorized to revoke the token". If a
client just needs to be the owner of the token in order to revoke it,
I would say that:
"The authorization server first validates the client credentials (in
case of a confidential client) and then verifies whether the token was
issued to the client making the revocation request."
Otherwise, the "authorized to revoke the token" language sounds like
there might be some way to *give* authorization to a particular
client, as opposed to authorization simply requiring authentication
and ownership.
2.1 Cross Origin Support
Formatting looks a little off here, otherwise this section looks fine.
What specifically to you mean?
The indentation looks strange. Should the example request, successful
response, and error response be indented? The example request in the
previous section is indented. Also, should the definition of the
"callback" parameter say "OPTIONAL." before the definition, or is that
redundant because the paragraph before indicates "MAY support"? I am
not sure of the IETF standards for these things; the section just
didn't look quite right to me.
5. Security Considerations
Paragraph 3 (Malicious clients...): "Appropriate countermeasures,
which should be in place for the token endpoint as well, MUST be
applied to the revocation endpoint." These countermeasures should be
referenced to the proper section(s) of the OAuth core spec or Threat
Model document.
Added reference to section 4.4.1.11 of threat model documemt
Paragraph 4 reads a bit oddly. Suggest following rewording:
"A malicious client may attempt to guess valid tokens on this
endpoint by making revocation requests against potential token
strings. According to this specification, a client's request must
contain a valid client_id, in the case of a public client, or valid
client credentials, in the case of a confidential client. The token
being revoked must also belong to the requesting client. If an
attacker is able to successfully guess a public client's client_id
and one of their tokens, or a private client's credentials and one
of their tokens, they could do much worse damage by using the token
elsewhere than by revoking it. If they chose to revoke the token,
the legitimate client will lose its authorization and will need to
prompt the user again. No further damage is done and the guessed
token is now worthless."
Adopted your text.
best regards,
Torsten.
References:
[1] http://tools.ietf.org/html/draft-ietf-oauth-v2-31
--
Amanda Anganes
Info Sys Engineer, G061
The MITRE Corporation
781-271-3103
aanga...@mitre.org
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
Thanks,
--Amanda
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
