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 <phil.h...@oracle.com> wrote: > 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 > phil.h...@oracle.com > > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
