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

[Brian Campbell <bcampbell@pingidentity.com>]

On Tue, Aug 3, 2010 at 6:51 PM, Scott Cantor <cantor.2@osu.edu> wrote:
> What if the resource owner isn't the one doing the granting? Or what if the
> grant takes the form of a static ACL, but apart from that, the grantee is
> just a service that authenticates to a SAML authority, owner not involved,
> gets an assertion proving who it is, and presents that to the authz server
> to get its access token?

I guess my thinking is/was that in the resource owner might often not
be directly involved, to your point.  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.  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.

   o  If the assertion issuer authenticated the subject, the assertion
      SHOULD contain a single <AuthnStatement> representing that
      authentication event.

   o  If the assertion was issued with the intention that the client act
      autonomously on behalf of the subject, an <AuthnStatement> SHOULD
      NOT be included.

> I don't think the resource owner is a direct party to every possible
> transaction, and the assertion is not generally supposed to be about the
> resource, so metadata about the resource (like the owner) isn't going to be
> in the assertion unless the security flow warrants that.

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.   And I don't think SAML requires that
the subject of an assertion be a direct party to anything. But that
gets us back to where we started and perhaps we'll just have to agree
to disagree or maybe I'll just agree to not understand implications of
the point your are trying to make.

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?

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.