Thanks for your comments, Torsten.
I've removed the sentence "Encrypting the token contents is another alternative
..." from draft -02 since it was redundant and potentially confusing.
I deleted the word "rare", since I agree with your conclusion.
The "reuse" phrase now reads: "To deal with token capture and replay, ..."
-- Mike
-----Original Message-----
From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
Sent: Monday, January 10, 2011 12:04 PM
To: Mike Jones; OAuth WG
Cc: Hannes Tschofenig
Subject: Comments on OAuth 2.0 Bearer Token specification draft -01
Hi Mike,
I've got some more comments on ยง 3.2 of your I-D.
paragraph 4: "Encrypting the token contents is another alternative ..."
How does token content encryption prevent the disclosure and abuse of a token?
paragraph 5: "For those rare cases where the client is prevented from observing
the contents of the token, token encryption has to be applied in addition to
the usage of TLS protection"
How did you come to the conclusion these are _rare_ cases? The token is used to
pass data between authorization server and resource server via the client as a
intermediary. A self-contained token may contain a lot of user-specific or
service provider internal information neither end-user nor authorization server
would like to disclose to the client. Therefore, here at Deutsche Telekom we
encrypt token contents per default.
paragraph 6: "To deal with token reuse, ... "
The "reuse" appears a bit misleading, isn't this paragraph talking about
capture/tap and replay attacks?
regards,
Torsten.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
