Re: [OAUTH-WG] Simpilfying use of assertions when requesting an access token

[Brian Campbell <[e-mail]>]

Do parameters defined by grant types really need a registry?  I mean,
a client only presents one access grant request at a time so it's not
like there's potential for name conflicts. Am I missing something?



On Wed, Sep 22, 2010 at 10:53 AM, Eran Hammer-Lahav <[e-mail]> wrote:
> It's a question of use cases. Right now, a single assertion parameter seems to be useful. But there is no strong reason why the SAML spec can't register that as an extension. The thing is, once that is done, other specs using the same parameter (say, a future SAML spec for a newer version) will need to update the registry and potentially the RFC of the extension... Not pretty.
>
> So if we have consensus that an assertion parameter is better than a saml2 and saml3 parameters for each extension, I'd say keep it in.
>
> EHL
>
>> -----Original Message-----
>> From: Brian Campbell [mailto:[e-mail]]
>> Sent: Tuesday, September 21, 2010 3:20 PM
>> To: Justin Richer
>> Cc: Eran Hammer-Lahav; OAuth WG ([e-mail])
>> Subject: Re: [OAUTH-WG] Simpilfying use of assertions when requesting an
>> access token
>>
>> I'm not sure one email from me asking for clarification exactly counts
>> as a movement ;-)   I was just thinking that it'd be more consistent
>> to have each uri-defined grant type define it's own parameter set.
>> Really this is what is already happening with the core defined short names -
>> the "authorization_code" grant type defines the "code" param, the
>> "password" grant type defines the "username" and "password"
>> params, and "refresh_token" defines "refresh_token".   The
>> "client_credentials" grant type is a little different in that it doesn't directly
>> define parameters but defers to a different part of the spec to do that but a
>> uri extension could conceivably do something similar (point to other specs or
>> other layers in the protocol stack or whatever).
>>
>> Having said all that, however, I do see the logic in what you said about having
>> the one assertion parameter.  But, I dunno, it just seems a little awkward
>> there all by itself.
>>
>>
>> On Tue, Sep 21, 2010 at 3:30 PM, Justin Richer <[e-mail]> wrote:
>> > I personally think it makes a certain amount of sense to have the
>> > assertion parameter: if you have only one thing to say, here's where
>> > to say it. And I think that we've got a few cases of assertions with
>> > only a single string to assert. However, I was always concerned with
>> > that single parameter as the *only* allowed parameter, which Eran has
>> > said won't be a problem. That said, if there's a movement for dropping
>> > it in favor of extension-defined parameter sets, I won't block it.
>> >
>> >  -- Justin
>> >
>> > On Tue, 2010-09-21 at 17:11 -0400, Brian Campbell wrote:
>> >> Following from that (Justin: "url-defined grant type can also legally
>> >> add and remove parameters from the endpoint, right?" / Eran: "Yes")
>> >> does the assertion parameter still make sense to have in the core
>> >> spec?  I had sort of assumed that it would be going away in favor of
>> >> whatever parameters any url-defined grant type would deem necessary.
>> >> However, Eran's "working copy" of draft -11 as of 2010-09-03 still
>> >> has the assertion parameter.  Is that area still being worked on or
>> >> was the intent to leave the parameter in for -11?
>> >>
>> >>
>> >> On Thu, Sep 2, 2010 at 3:28 PM, Eran Hammer-Lahav
>> <[e-mail]> wrote:
>> >> > Yes.
>> >> >
>> >> > -----Original Message-----
>> >> > From: Justin Richer [mailto:[e-mail]]
>> >> > Sent: Thursday, September 02, 2010 2:27 PM
>> >> > To: Eran Hammer-Lahav
>> >> > Cc: OAuth WG ([e-mail])
>> >> > Subject: Re: [OAUTH-WG] Simpilfying use of assertions when
>> >> > requesting an access token
>> >> >
>> >> > +1
>> >> >
>> >> > I've never liked the notion of not being able to extend the "grant type"
>> >> > field, and this change addresses that particular gripe.
>> >> >
>> >> > Just so I'm clear here: an extension that defines its own url-defined
>> grant type can also legally add and remove parameters from the endpoint,
>> right?
>> >> >
>> >> >  -- Justin
>> >> >
>> >> > On Thu, 2010-09-02 at 17:11 -0400, Eran Hammer-Lahav wrote:
>> >> >> I would like to make this change in -11:
>> >> >>
>> >> >>
>> >> >>
>> >> >> Instead of the current user of the 'assertion' grant type -
>> >> >>
>> >> >>
>> >> >>
>> >> >>   POST /token HTTP/1.1
>> >> >>
>> >> >>   Host: server.example.com
>> >> >>
>> >> >>   Content-Type: application/x-www-form-urlencoded
>> >> >>
>> >> >>
>> >> >>
>> >> >>   grant_type=assertion&
>> >> >>
>> >> >>
>> >> >>
>> assertion_type=urn%3Aoasis%3Anames%3Atc%3ASAML%3A2.0%3Aassertio
>> n&
>> >> >>
>> >> >>   assertion=PHNhbWxwOl[...omitted for brevity...]ZT4%3D
>> >> >>
>> >> >>
>> >> >>
>> >> >> Drop the 'assertion' grant type and put the assertion type
>> >> >> directly in the grant_type parameter:
>> >> >>
>> >> >>
>> >> >>
>> >> >>   POST /token HTTP/1.1
>> >> >>
>> >> >>   Host: server.example.com
>> >> >>
>> >> >>   Content-Type: application/x-www-form-urlencoded
>> >> >>
>> >> >>
>> >> >>
>> >>
>> >>   grant_type=urn%3Aoasis%3Anames%3Atc%3ASAML%3A2.0%3Aassertio
>> n&
>> >> >>
>> >> >>   assertion=PHNhbWxwOl[...omitted for brevity...]ZT4%3D
>> >> >>
>> >> >>
>> >> >>
>> >> >> In other words, the grant_type parameter value will be defined as:
>> >> >>
>> >> >>
>> >> >>
>> >> >> -          authorization_code
>> >> >>
>> >> >> -          password
>> >> >>
>> >> >> -          client_credentials
>> >> >>
>> >> >> -          refresh_token
>> >> >>
>> >> >> -          an abolute URI (extensions)
>> >> >>
>> >> >>
>> >> >>
>> >> >> I considered turning all the values into URIs but found it to be
>> >> >> counter-intuitive. The practice of using "official" short names
>> >> >> and extension URIs is well established and is already the general
>> >> >> architecture used here. This just makes it cleaner.
>> >> >>
>> >> >>
>> >> >>
>> >> >> I ran this idea by Brian Campbell and Chuck Mortimore who are
>> >> >> generally supportive of the idea.
>> >> >>
>> >> >>
>> >> >>
>> >> >> Any objections?
>> >> >>
>> >> >>
>> >> >>
>> >> >> EHL
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >> > _______________________________________________
>> >> > OAuth mailing list
>> >> > [e-mail]
>> >> > https://www.ietf.org/mailman/listinfo/oauth
>> >> >
>> >
>> >
>> >
>