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

["Scott Cantor" <cantor.2@osu.edu>]

> 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.

Why?

> 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.

Well, we do it, see below.
 
> 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?

I'm thinking here of the web app use case. In that scenario, I would SSO
into the web app (bearer confirmation of browser to web app), and then I
would like to delegate to the web app the ability to access the authz server
to obtain the access token (holder of key or bearer confirmation of web app
to authz server).

It's completely natural for the web app to "get access" to the assertion.
Why wouldn't it?

> 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.

Sure, but that's delegation (which should be captured in the assertion using
the SubjectConfirmation and/or a Delegation condition).

I'm not saying the subject *can't* be the resource owner, but that's a
specific flow that may or may not be present. It could simply be some entity
who has been granted access. I'm just saying the subject should be, well,
the subject. Not solely the resource owner, unless it actually is the
resource owner.

> 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."

That's one route to take, but it has optional semantics. The new condition
is more appropriate in most cases since it requires the consumer to
recognize and accept the delegation.

-- Scott