Would it help if the client_ stuff were dropped from the example in the assertion flow? I'm in favor of it being allowed, but if the general use case is going to be without it then the example should reflect that and cut down on the confusion.
-- Justin On Wed, 2010-07-07 at 18:01 -0400, Brian Eaton 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
