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...@hueniverse.com> wrote: > > Yes. > > > > -----Original Message----- > > From: Justin Richer [mailto:jric...@mitre.org] > > Sent: Thursday, September 02, 2010 2:27 PM > > To: Eran Hammer-Lahav > > Cc: OAuth WG (oauth@ietf.org) > > 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%3Aassertion& > >> > >> 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%3Aassertion& > >> > >> 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 > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
