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
