Again, sorry for the slow reply. On Thu, Aug 19, 2010 at 1:52 PM, Thomas Hardjono <[email protected]> wrote: >> First, concern was expressed that restricting the assertion to only >> allow for a single <SubjectConfirmation> element was too limiting. >> The restriction basically limits the ability of a single assertion to >> be issued for use across multiple use-cases/profiles. A good example >> is the use-case that Prateek recently brought up in a different thread >> on this list[2] where the assertion is delivered to an SP via Web SSO >> and then that SP uses that same assertion to acquire an access token >> for data services at a 3rd party site. As currently written, >> draft-campbell-oauth-saml-00[3], wouldn't allow for that use-case. >> I'm starting to think that my attempt at simplification was is indeed >> too restrictive. Allowing for more than one <SubjectConfirmation> will >> make the wording in the profile a bit more complicated (as well as >> implementing validation) but I think, in the longer term, it's probably >> the right thing to do from a spec perspective. At this point I'm >> planning on loosening that restriction in the next draft. I'm curious, >> however, if anyone has any strong opinions on it one way or the other? > > I was under the impression that the Oauth use-case was > intentionally made to be simple, where the client talks direct to > the Authorization Server (not via Web-SSO and the SP, > as in the classic SAML use-case).
It is simple in that the client talks directly to the authz server and exchanges an assertion for an access token. However, the means by which the client gets the assertion, who issues/signs the assertion, and how the authz server decides to trust the assertion, are all out of scope. That allows for more complex use cases or deployments. In the case Prateek mentions, for example, the client gets the assertion via web sso from an IdP that is mutually trusted by the 3rd party. I don't think it's the most common use case by any means but the profile, as I have it written now, would disallow it and that's probably too restrictive. > Does Oauth-v2 today allow > the Authorization Server to delegate/relegate the actual > obtaining of the access token to a 3rd Party? I'm not sure I follow the question? > I think there are a large number of SAML-based use cases that > can be interestingly "layered" atop OAuth. I guess the question > is how complex should we get in Oauth-v2. Perhaps for now you > should make the subject of the assertion be the resource owner, > to be in-line with the basic Oauth design assumptions. That was my thinking as well but most of the other feedback I've gotten about it suggesting it's too restrictive. _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
