On 7/7/10 3:01 PM, "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. I'd probably agree with Eran on this one - additional spec isn't required, but in absence, additional doc almost certainly will be. We are strongly against any mandatory client credentials, however, as long as client creds are optional, then it's up to the server or profile to define. I'm not sure I get the objection, as it remains under your control. > 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*. Refresh tokens are already labeled as SHOULD NOT, which I find strong enough; if others want to do something crazy with the flow I consider it up to them. We are are strongly against any SHOULD or MUST language on refresh tokens. 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. I don't really view the assertion flow in current form to be anything but a basis for futher profiling or docs. In both these cases, it seems like the server maintains control. I'm certain we can't expect interoperable clients using SAML without further profiling / doc / agreement. -cmort > 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
