This feels exactly like the sort of thing that should be a new flow. Nat, thanks for writing it up! I think the next step is getting it into the XML2RFC format and some editing.
On Wed, May 26, 2010 at 8:07 PM, Manger, James H < [email protected]> wrote: > Nat, > > This looks like a decent idea: allow one user-uri parameter to reference a > larger set of user-uri parameters held elsewhere -- to avoid URI size > limits. > > Hopefully it can be specified as another user-uri parameter -- not as a > separate flow. It could be helpful for any of the delegation flows. > > [I think the spec would be improved with a dedicated section on the > user-uri (End-User endpoint) that lists all the parameters that it can take > (that are defined in the spec) -- and explains each parameter (some will > need their own sub-section). The per-flow sections would not repeat any of > that: they could be a lot more succinct.] > > > Quick suggestion for text: > > [for section 3.2 "End-user Endpoint"] > ... > The following user-uri parameters are defined in this specification: > ... > inc_uri A URI for obtaining further parameters for this request. > > ... > <inc_uri> allows parameters for the user-uri request to be referenced, > instead of included directly. This is particularly helpful when the > parameters are large and might not fit within the URI length limits of the > user's browser. The response to a GET request to <inc_uri> SHALL be user-uri > parameters in XXX format. Any parameter appearing directly in the user-uri > SHALL override the same parameter obtained from <inc_uri>. The <inc_uri> > response SHOULD be cacheable by including appropriate HTTP cache-control > headers. The <inc_uri> SHALL be an HTTP or HTTPS URI, and SHOULD be the > latter. > > > [Probably need a way for a service to indicate whether or not it supports > <inc_uri>. Perhaps a "features=inc_uri,other" parameter in the HTTP > WWW-Authenticate header.] > > -- > James Manger > > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Nat Sakimura > Sent: Wednesday, 26 May 2010 11:58 PM > To: oauth > Subject: [OAUTH-WG] OAuth 2.0 Mobile WebApp Flow > > Back in February, I have suggested mobile web app flow to the oauth_wrap > group. > Now that it is wrapped into OAuth 2.0, here is my another try, this > time for OAuth 2.0 draft. > > "OAuth 2.0 Mobile WebApp Flow" > http://www.sakimura.org/en/modules/wordpress/oauth-20-mobile-webapp-flow/ > > I really wish that this could be included in OAuth 2.0 as it will help > build identity layers on OAuth 2.0 that works for mobile web browsers etc. > > -- > Nat Sakimura (=nat) > http://www.sakimura.org/en/ > http://twitter.com/_nat_en > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
