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

Reply via email to