On 6/4/10 9:53 AM, Luke Shepard wrote:
Having a single resource server that works with multiple independent
auth servers is not in scope for OAuth. That said, there's nothing to
stop multiple servers to agree amongst themselves to have a
standardized format for access token- and if necessary, to write that
agreement as a separate spec (perhaps an extension).
-1
limiting OAuth to a single Authorization Server (AS) and it's associated
SPs (resource owners) significantly restricts the value of delegation
across the internet.
On the other hand, if OAuth allows for cross AS token processing, then
it becomes very easy for me to protect my photo album while not
requiring that all those I've shared it with to have an account at my
photo service (as one example; there are many more).
Thanks,
George
In particular, I wouldn't like your proposal because of the use of
equals and ampersand, both of which would need to be URL encoded so
developers couldn't copy/paste the token as easily. For Facebook, it's
important that the access tokens are as short as possible; other sites
may have different requirements.
On Jun 4, 2010, at 6:37 AM, Andrew Arnott wrote:
Having just implemented OAuth 2.0 web server flow, it was great to be
able to issue an "opaque" access token to the client. This access
token is in an encrypted format that only the resource server
understands. I feel pretty good about this approach as it lends to
high security and tokens that only the client needs to store (or not
at all).
But I'm wondering about the resource server that trusts multiple auth
servers, which each have their own access token format. Without even
a standardized way for an access token to express what format it is
in, a resource server may have to just try decoding the token each
known way until one "works".
Proposal: perhaps the access token can be /mostly/ opaque, but not
quite. For instance:
The access token is in the format: /format=URI&opaquevalue/
Where URI is an arbitrary URI assigned by the auth server to assist
the resource server in interpreting the /opaquevalue/ part of the token.
Feedback?
--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the
death your right to say it." - S. G. Tallentyre
<ATT00001..txt>
=
_______________________________________________
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
