And have it become one of the official IETF Working Group documents though.
On Wed, May 26, 2010 at 10:37 PM, David Recordon <record...@gmail.com>wrote: > 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
