Re: [security-services] draft: SAML 2.0 Bearer Assertion Profile for OAuth 2.0

[Brian Campbell <bcampbell@pingidentity.com>]

Thanks for the feedback Scott.  Responses, more questions, etc., are
inline below.

On Thu, Jul 29, 2010 at 8:50 AM, Scott Cantor <cantor.2@osu.edu> wrote:
> I only had a couple of comments:
>
> It seems like a mistake to limit the assertion to only one
> SubjectConfirmation. I would suggest emulating the approach in the SSO
> profile; you can have any number, but (given the intent to identify the
> format as "bearer" here) one of them has to be bearer. That's better for
> composition with other profiles.

I was wondering if anyone would notice/comment that I'd constrained it
to a single subject conf.  I did that intentionally to try and
simplify the validation process.  Allowing for multiple
SubjectConfirmations makes validation more difficult.  In particular
it makes it hard to provide meaningful feedback when none of the
confirmations can be confirmed.

So I opted for simplicity on that one.  In practice it doesn't seem
very likely that a single assertion needs to have confirmation info
from multiple profiles.  It seems to me that an IdP generates an
assertion for a specific purpose (aligning with a particular profile)
and transports it via some binding to a single SP who consumes it.
The assertion is short lived and single use.  That's how I see web sso
work and that's how I envision this profile working.  I couldn't see
anything more than an abstract need for multiple subject confirmations
and thus opted for simplicity.

> For example, I should be able to issue a SSO assertion to an SP that
> includes a delegated subject confirmation to an OAuth authz server (so in
> that case it would have two bearer confirmations, one for the SP and one for
> the OAuth server).

I'm not sure I follow how that example would really play out?   The
SSO assertion would be issued in an HTTP response to the browser via
one of the browser bindings and sent to the SP.  How would an OAuth
client (which could be a desktop or mobile app, a web app, etc.) even
get access to that assertion in order to send it to the OAuth authz
server?    Or am I completely misunderstanding?

> Also, it says "The assertion MUST contain a <Subject> element that
> identifies the      resource owner for whom the access token is being
> requested.". Is that really accurate? Isn't the subject meant to be the
> subject accessing the resource? That's who you're granting rights to, not
> the resource owner.

I think I do mean the resource owner but let me try and explain.  The
thing that will be accessing the resource (a client in OAuth speak)
will be doing it on behalf of the resource owner.  The assertion
subject identifies the resource owner and the assertion itself
represents the (possibly implicit) access grant that the subject makes
to the client to access some resource on his/her behalf.  The client,
who the rights are being granted to, is (optionally) identified at the
OAuth layer by the client_id and some form of authentication (a
password is the only explicitly supported means of client authn now
but some folks, including myself, are pushing to allow assertions to
be used in that context as well).

So I thought I could explain that but now I feel like I'm just talking
in circles with buzz works without saying much at this point - does
any of that even make sense?

Perhaps the content of Errata 47 should be considered/discussed at
this point in the profile?   The second part of E47 says, "If an
assertion is issued for use by an entity other than the subject, then
that entity SHOULD be identified in the <SubjectConfirmation>
element."   Maybe if the client is known by the issuer to be an entity
worthy/capable of representation via a NameID, the issuer should
include the client identity in the SubjectConfirmation?  I'm not sure
if that adds much value and I'd think that would introduce a need to
check client_id against a NameID in the SubjectConfirmation, if one
was present.

> Minor comment, I guess given past experience, I'd suggest elaborating very
> briefly in the last bullet ("MUST verify that the assertion is valid in all
> other respects") with some examples. Maybe just add "such as evaluating all
> content within the Conditions element, rejecting unknown condition types,
> etc."

Good point.  I'll add something like that text (if not that text
exactly) to that bullet point.