This thread forced a great deal on internal discussion today, and we actually do have some more immediate use-cases where we'll require client_id with the assertion flow
I support leaving it as optional -cmort On Wednesday, July 7, 2010, Brian Eaton <bea...@google.com> wrote: > On Wed, Jul 7, 2010 at 2:52 PM, Eran Hammer-Lahav <e...@hueniverse.com> wrote: >> I disagree with this approach. There are plenty of optional parameters in >> the spec. > > Yes. I think most of them are a bad idea. > >> 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 doesn't, actually. Lots of people have existing SAML assertion > formats that they support, and they are going to use the SAML to > access token swap without any further spec writing. > >> It is not clear what about allowing client authentication or refresh token >> breaks security. This is purely a deployment decision for each provider. > > Please see this thread: > http://www.ietf.org/mail-archive/web/oauth/current/msg02218.html. > > Note multiple voices of approval for dropping the refresh token. > > Note that people who want the refresh token have *completely different > use cases*. > > Steering multiple use cases into the same profile is how we made OAuth > 1.0 complex, slow, and insecure. Let's not make the same mistake with > OAuth 2. > >> If you would like to request specific changes to draft –09, please list them >> and explain why you are requesting them. > > I'd like to see the following changes: > > 1) Separate profiles for separate use cases. > The spec started off this way, and recent drafts have made it > progressively more compressed. Shorter is not a win. > > 2) Drop refresh token, client id, and client secret from the SAML flow. > If someone needs them, that's OK, but put it in different profile > for a different use case. > > Cheers, > Brian > _______________________________________________ > 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
