I'd honestly write it as a standalone few page document. We really need to show that flows can be defined outside of the core spec from an extensibility standpoint.
On Wed, May 26, 2010 at 10:29 PM, Nat Sakimura <sakim...@gmail.com> wrote: > I can do the XML2RFC thing as well. > > Shall I just make a section and upload the section somewhere? > > =nat > > On Thu, May 27, 2010 at 12:37 PM, David Recordon <record...@gmail.com> > wrote: > > 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 > > <james.h.man...@team.telstra.com> 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: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] 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 > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > -- > Nat Sakimura (=nat) > http://www.sakimura.org/en/ > http://twitter.com/_nat_en >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
