Again apologies for my late comments. __________________________________________
> -----Original Message----- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of Brian Campbell > Sent: Monday, August 09, 2010 12:30 PM > To: oauth > Subject: [OAUTH-WG] SAML profile comments/questions from the SAML > people > > I received some feedback on the SAML profile from a cross posting on > the OASIS SSTC (SAML) list. Links to the thread topic index are > below[1], if you are interested, but I'll try and summarize the two > primary issues here. > > 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). Does Oauth-v2 today allow the Authorization Server to delegate/relegate the actual obtaining of the access token to a 3rd Party? > The second issue involves my assumption and requirement in the profile > that the subject of the assertion be the resource owner. To me, it > seemed like a reasonable and useful constraint that was generally > inline with the spirit of the assertion flow, ... 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. /thomas/ _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
