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

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

> I recently submitted an internet draft that attempts to define the use
> of a SAML 2.0 bearer assertion as means for requesting an OAuth 2.0
> access token using the assertion flow or grant type in OAuth.  I
> wanted to inform the SSTC of the work and solicit any feedback or
> suggestions that any of you might have on it (I already have a pretty
> good idea of how Scott feels but his insightful comments are welcome
> regardless).

The fact that I don't like gateways isn't going to eliminate them.

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.

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

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.

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

-- Scott