Re: [OAUTH-WG] Partially standardized format for access tokens?

[George Fletcher <[e-mail]>]

On 6/8/10 9:58 AM, Luke Shepard wrote:
> Again: can you provide a specific, real-world example where this is 
> necessary? I'd rather not deal in hypotheticals. I've already answered 
> the case of a hypothetical endpoint that accepts both SAML and 
> JSON-encoded tokens.
I believe one such case is person-to-person sharing where person A is 
NOT part of the same network as person B.

If I have a protected resource at photos.example.com and I want to share 
with someone who is NOT a member of photos.example.com there are only a 
couple of options...

1. Today's method: security by obscurity with "non-guessable" URLs 
emailed to person B

2. Use OpenID and force Person B to "sign in" to photos.example.com 
(effectively establishing a relationship with photos.example.com that 
they might not want)

3. Have photos.example.com be able to accept a token from person B's 
authorization service saying this is person B when accessing the 
protected resource.

Option 3 is a much better experience for the user and simpler to 
implement for any client that person B is using. However, this requires 
that photos.example.com be able to read and understand the token from 
person B's authorization server (AS). Hence we need some way to 
associate origin and format with the token.

Personally, I think that using XRD the origin server could expose a 
"dumb mode" token validator such that resource owners that don't now how 
to process the token natively could still validate the token and get 
some minimal information.

Thanks,
George

Some additional thoughts and links: 
http://practicalid.blogspot.com/2010/05/identity-as-attribute.html