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

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

> I guess my thinking is/was that in the resource owner might often not
> be directly involved, to your point.

Ok.

> The assertion represents the
> grant and the grant is likely implicit based on the trust established
> between the two providers as well as policy at those providers.

Well...an assertion is a set of statements about a subject, usually
authentication and attributes. It is definitely *not* a grant. That is not a
use case that any existing SAML statements address (incl AuthzDecision), and
even if they did, the grant would be to the *subject* of the assertion.
Meaning the subject is the one attempting to access the resource.

If there's been an explicit delegation of authentication or identity between
the resource owner and the client, *then* I would agree that the subject is
probably going to be the resource owner. But if the client just says "here's
my key, I'm puppies.com, please give me an assertion so I can go get a token
to access Joe's pet food preferences..." that's not delegation. And Joe's
identity wouldn't be in the assertion.

> I intended the language about including or not including the
> <AuthnStatement> (included below) to try and distinguish between the
> client acting with the direct involvement of the user and the client
> acting autonomously on the user's behalf.

That language is more or less ok, but it still assumes that the client is
acting "on behalf of the subject". That is not a given, IMHO, at least not
unless you start by constraining the profile to that use case (and I would
wonder why).
 
> Agreed that the resource owner isn't gong to be a direct party to
> every possible transaction but I'm not sure I agree that the owner is
> just metadata about the resource.   In my view, the resource owner is
> the subject of the exchange.

Can't agree there. The subject of the assertion is the authenticated party
about whom the assertion is issued (where delegation of authentication might
imply that the actual presenter is somebody else). But it's not a given that
it's the resource owner. It probably is a lot of the time, of course.

> So let me try coming at it a different way and call on your extensive
> experience authoring and editing documents like this.  If it were you,
> what text would you include regarding the subject in the context of
> this little profile?  Or would you say anything about it at all?

I would probably say something to the effect that the subject of the
assertion is the party that is effectively requesting access to the
resource, and perhaps point out or highlight specific ways in which
intermediaries might (or perhaps SHOULD?) be reflected.

Whether that's the resource owner to me is just implicit in the scenarios
that the profile is eventually used to address. What I would definitely not
do is count on the assertion to self-identify the resource, owner, and any
other transactional metadata the authz server might need to issue the OAuth
token. That should be part of the message exchange with the authz server.

> BTW, I'm not trying to be argumentative.  I'm trying to write
> something that will be useful to implementers without being too
> restrictive or outright incorrect.  It sounds like you are saying I've
> done the latter and I'm trying to fully understand that.

I would say it's more the former than the latter. It seems to be implicitly
ruling out use cases (and in the subject confirmation case, really
common/important ones that would defeat the utility of the profile for me).

I think the restrictions are unneeded, particularly because nobody who finds
them necessary is going to be implementing an authz server that uses SAML
anyway (you know who I mean). But if they're there, then perhaps some text
explaining what's in scope and not in scope would be good.

-- Scott