I disagree with this approach. There are plenty of optional parameters in the spec.
The assertion access grant requires further profiling to be useful. This doesn't mean it needs another spec, but that when you use it, you need to document clearly what is expected. When you do that, spell out what you support and what not. It is not clear what about allowing client authentication or refresh token breaks security. This is purely a deployment decision for each provider. If you would like to request specific changes to draft -09, please list them and explain why you are requesting them. EHL On 7/7/10 2:42 PM, "Brian Eaton" <[email protected]> wrote: On Wed, Jul 7, 2010 at 2:18 PM, Eran Hammer-Lahav <[email protected]> wrote: > On 7/7/10 2:02 PM, "Brian Eaton" <[email protected]> wrote: >> Can you point me to the e-mail threads that reached consensus on using >> client authentication? > > This was requested a few months ago and was included in -05 as optional. I > did not see any feedback requesting to remove this. OK, here it is: http://www.ietf.org/mail-archive/web/oauth/current/msg02545.html I see that I was +1 on client_id and client_secret, so long as they were optional. =) I'd like to withdraw that +1. Optional input and output parameters have made the specification very confusing. If someone needs client_id and client_secret, great, they can explain their use case and propose a profile to address it. But the original use case for the assertion flow has no use for client ids. >> Can you point me to the e-mail threads that reached consensus on >> returning a refresh token? > > I raised this a long time ago about making the token endpoint output > consistent across all request types. At the time, consensus was that there > was no reason not to allow it, but that in general is should not be done > (refresh token when using assertions). Please review this thread: http://www.ietf.org/mail-archive/web/oauth/current/msg02188.html. I am sure there are people out there who want to use refresh tokens with SAML assertions. Good for them. But it's a different use case. It should be moved to a different profile. It is not a good idea to jam multiple use cases into a single protocol flow with a bunch of optional inputs and outputs. Instead different use cases should be separate profiles, with mandatory inputs and mandatory outputs. If there are going to be optional inputs and outputs, there should be clear guidance as to when they are expected and when they are not. Cheers, Brian
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
