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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
