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