Re: [OAUTH-WG] assertion profile changes

[Eran Hammer-Lahav <[e-mail]>]

BTW, I'm not opposed to writing more detailed profiles based on the generic framework provided by the two endpoints defined and theyr many optional components. I think the new format helps clarify the overall architecture and easier to implement a generic client for (given that all the parameters for each endpoint are listed in a single place).

If people think this can be useful, I'm happy to give it a try once -10 is out and declared stable.

EHL


On 7/7/10 3:01 PM, "Brian Eaton" <[e-mail]> wrote:

On Wed, Jul 7, 2010 at 2:52 PM, Eran Hammer-Lahav <[e-mail]> 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