This is exactly the direction UMA is headed (as George knows :-), since we *are* trying to solve for "unmooring" authorization servers and resource servers -- which we call authorization managers and hosts.
The absolute simplest thing to do is hand out tokens that are essentially artifacts that the host must carry over and validate at the AM (I think Dick was calling these "identifiers" but I'm coming to like "artifact"). But by then, in our case, the host and AM have already met in the context of the user who controls the protected resource in question, and in fact the host has gotten an access token to use at the AM's token validation endpoint so it already knows where to go to validate. Thus, the artifact could be an opaque string. There are other aspects to the host-specific API at the AM that become handy/necessary when you have to build in this kind of dynamic association. For example, the host needs to tell the AM what resources it's protecting on behalf of this user; we're fleshing out that API now, but for now it's just POSTing a complete JSON structure (wielding its access token to do so). And I believe it's possible to solve some scoping interop this way too, though we're not there yet by a long shot. Would love to have folks interested in these use cases come on over to the UMA WG and share their thoughts: http://kantarainitiative.org/confluence/display/uma/Home Eve On 4 Jun 2010, at 7:06 AM, George Fletcher wrote: > +1 to some standardization to the token > > The URI would also allow for discovery and the ability for the provider to > define an endpoint in the XRD for the URI that allows "dumb mode" token > validation. This way, even if the resource owner doesn't know how to "crack" > the token locally, they could ask the provider to do it for them. > > Thanks, > George > > On 6/4/10 9: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 >> >> _______________________________________________ >> 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 Eve Maler e...@xmlgrrl.com http://www.xmlgrrl.com/blog
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
