On Wed, Jul 7, 2010 at 2:18 PM, Eran Hammer-Lahav <e...@hueniverse.com> wrote: > On 7/7/10 2:02 PM, "Brian Eaton" <bea...@google.com> 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 OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
