[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [security-services] draft: SAML 2.0 Bearer Assertion Profile for OAuth 2.0
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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]