On 8/9/10 9:30 AM, "Brian Campbell" <bcampb...@pingidentity.com> wrote: 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? 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, however, the comments from Scott (editor of the core SAML specifications) suggest that it's too constraining and/or inappropriate. I'm honestly not sure where to go with this one and am reaching out to this list for ideas/suggestions/opinions. I guess I see where he's coming from but I'm kind of partial to the restriction/guidance as I have it. Also, I'm thinking that perhaps the counter example cases he describes would be better captured by use of the "none" access grant type and a client assertion (coming in draft -11, I think?). I think it would be reasonable to loosen the language to reflect that the subject is who access will be granted to. It may or may not be the resource owner, I agree. -cmort Thanks, Brian C [1] Discussion Thread on SSTC list http://lists.oasis-open.org/archives/security-services/201008/threads.html#00000 http://lists.oasis-open.org/archives/security-services/201007/threads.html#00034 [2] Discussion Thread with use-case on OAuth list http://www.ietf.org/mail-archive/web/oauth/current/msg04118.html [3] draft-campbell-oauth-saml-00 / SAML 2.0 Bearer Assertion Profile for OAuth 2.0 http://www.ietf.org/id/draft-campbell-oauth-saml-00.txt _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
