Lukas,
thanks for your feedback.
I think 1c not neccessarily introduces something new to manage. I would
rather expect implementations use either a ID already contained in the
token (like the SAML assertion ID) or a base64-encoded version of the
token itself.
regards,
Torsten.
Am 17.08.2010 00:51, schrieb Lukas Rosenstock:
+1 for your option 1a or 1b
- 1c introduces another "token" to manage with the id, which I feel
should be avoided.
- 2 would also be fine, though not so "beautiful" in terms of
architecture.
2010/8/16 Torsten Lodderstedt <tors...@lodderstedt.net
<mailto:tors...@lodderstedt.net>>
But is it advisable to pass tokens as URI query parameters? The
current character set definition for access tokens (ยง5.1.1) is not
URL-safe since it includes URI reserved characters (e.g. '/').
Additionally, there is no definition of a refresh tokens character
set. So compliant authorization servers could issue tokens, which
cannot be safely passed as URI query parameters.
Passing URLs in the query string is already defined in section 5.1.2
of OAuth, though it is optional for servers to support this method.
The class of services who want to support 5.1.2 and those who want to
support revocation might not match, though ...
--
http://lukasrosenstock.net/
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
