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

Reply via email to