Subject: [OAUTH-WG] Clarification enhancement for saml2 bearer spec

From: Phil Hunt <[email-masked]>
Date: Tue, 3 Jul 2012 12:15:38 -0700

I have had a couple developers get confused by sections 2.1 and 2.2 of the spec. What seems to be happening is they read them as distinct complete flows rather then considering the core spec still applies.

In the case of 2.1, "Using SAML Assertions as Authorization Grants" they forget that a client credential is also needed and only specify the SAML authorization assuming it includes both (which may or may not be intended).

In the case of 2.2, "Using SAML Assertions for Client Authentication", they are not making the link that the client authentication may be used in connection with any of the OAuth flows. They are instead treating this as a new flow. IOW they forget to add the grant_type parameter.

It might be helpful to include complete examples for each of 2.1 and 2.2 to clarify.

Phil

@independentid
www.independentid.com
[email-masked]

---

From: Brian Campbell <[email-masked]>
Date: Tue, 3 Jul 2012 15:12:35 -0600

Thanks for the feedback Phil.

In the case of §2.1, "Using SAML Assertions as Authorization Grants"
the intent was to allow for such a SAML grant to be used with or
without client authentication. Whether or not client authentication is
required (and what type of authentication) would be a
deployment/policy decision of the AS. But both are possible from the
spec.

In the case of §2.2, "Using SAML Assertions for Client
Authentication", yes it's just providing an alternative method of
client authentication beyond what's specified in §2.3 of core. It
doesn't really do anything on its own and must be used in conjunction
with the grant_type parameter.

I'll take a stab at some clarifying text and/or examples for those
points of confusion. Suggestions are, of course, welcome too.

On Tue, Jul 3, 2012 at 1:15 PM, Phil Hunt <[email-masked]> wrote:
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Phil Hunt <[email-masked]>
Date: Tue, 3 Jul 2012 14:47:29 -0700

Phil

@independentid
www.independentid.com
[email-masked]

> deployment/policy decision of the AS. But both are possible from the
Yes. This makes sense. However in light of the recent discussion about bearer codes and tokens I'm a little more nervous of convolving the grant and client authentication together. It's really the token server that should properly authenticate the client and obscuring that act by combining in a single grant may serve to confuse. There is also the issue of offering too many choices.

Just an opinion, but I can live with your suggestion that grant can be used alone. 

> points of confusion. Suggestions are, of course, welcome too.

Works for me.

---

From: Brian Campbell <[email-masked]>
Date: Wed, 25 Jul 2012 12:03:01 -0600

I'm really inclined to keep it such that that is an option. We've got
product features that allow for it an assertion grant to be used alone
now and I think they are really useful in some cases.  And I think
this use case is different enough from the authorization code
situation that the fix for the code swapping there doesn't really
apply here.

Just one point of clarification: when an assertion is used as a grant
alone with no client identification or authentication, the assertion
doesn't authenticate the client. The client is anonymous. The issuer
of the assertion may give some clues about the client or the security
domain of the client. But it doesn't necessarily directly identify the
client.

Sorry (as usual) for the delayed response. And I've still got it on my
queue to propose some new text for the points of confusion you raised
in the beginning of this thread.

On Tue, Jul 3, 2012 at 3:47 PM, Phil Hunt <[email-masked]> wrote:
> Yes. This makes sense. However in light of the recent discussion about bearer
> codes and tokens I'm a little more nervous of convolving the grant and client
> authentication together. It's really the token server that should properly
> authenticate the client and obscuring that act by combining in a single grant
> may serve to confuse. There is also the issue of offering too many choices.
>