Phil @independentid www.independentid.com phil.h...@oracle.com
On 2012-07-03, at 2:12 PM, Brian Campbell wrote: > 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. > 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. > 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. Works for me. > > 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
