Hi Jørn, For what it's worth, in the UMA work (built on top of OAuth), we are working on the option for a resource server to outsource the validation of the token back out to the authorization server, rather than validating it locally. Since in our case the two servers may be in different administrative domains, this can greatly simplify the configuration that would have to happen between them, as well as present other new opportunities. (E.g., the authorization server can serve as a true policy decision point.)
There is also an aspect of claims-based authorization in UMA, but we do it a little differently than you might be thinking. The client may need to present claims to the authz server in order to satisfy user policy (agrees to terms XYZ, controls [email protected], is over 18...), which leads to an access token being granted. Eve On 1 Sep 2010, at 10:34 PM, Jørn Wildt wrote: > Yes, SWT or similar was what I was looking for. But all I could find > was, well, nothing, and people indicating that SWT is dead - or at > least not part of OAuth. > > Originally I was looking for a claims based security standard for a > REST API. That's why I ended up with OAuth - but having finally > figured out the inner workings of OAuth, I see that OAuth is not > claims based (at least not in the token). It's only federated, which > is certainly good! But I was hoping to find something for REST that > SAML does for SOAP: a standard for sending claims with each request. > > Thanks, Jørn > > On Sep 1, 10:19 pm, Dick Hardt <[email protected]> wrote: >> There were a couple of documents that described standard access tokens. SWT >> (Simple Web Token was one of those) >> >> The WRAP and OAuth work specifically were token agnostic. >> >> -- Dick >> >> On 2010-08-31, at 11:54 PM, Jørn Wildt wrote: >> >>> Thanks! So OAuth is only concerned with the actual exchange of the >>> authorization token and access token - not what's in them. Further: >>> it's up to the OAuth vendor to decide how it should handle those >>> tokens internally. >> >>> For instance: When an end user grants access to something, then this >>> is registered internally in the application, and when a resource >>> webservice receives the access token, it looks it up in the internal >>> register to see what it is valid for? The specs say nothing about what >>> the webservice should do with that token. Right? >> >>> /Jørn >> >>> On Sep 1, 7:58 am, John Kristian <[email protected]> wrote: >>>> It's vendor specific. >> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "OAuth" group. >>> To post to this group, send email to [email protected]. >>> To unsubscribe from this group, send email to >>> [email protected]. >>> For more options, visit this group >>> athttp://groups.google.com/group/oauth?hl=en. >> >> > > -- > You received this message because you are subscribed to the Google Groups > "OAuth" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/oauth?hl=en. > > Eve Maler http://www.xmlgrrl.com/blog http://www.twitter.com/xmlgrrl http://www.linkedin.com/in/evemaler -- You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/oauth?hl=en.
