I like that this also collapses the grant_type=assertion and assertion_type=foo.
On Thu, Sep 2, 2010 at 2:28 PM, Eran Hammer-Lahav <[email protected]>wrote: > Yes. > > -----Original Message----- > From: Justin Richer [mailto:[email protected]] > Sent: Thursday, September 02, 2010 2:27 PM > To: Eran Hammer-Lahav > Cc: OAuth WG ([email protected]) > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
