I think it belongs in a separate spec (even if at the end if might mean more work for others and me). I don't think the UX bits are well understood or enjoy enough experience to become part of core. They also tend to change often as the state of the art in UX evolves.
With -10, I am going to take a general approach of objecting any new features in core unless you can show the spec cannot be used without them. EHL On 7/12/10 7:31 PM, "David Recordon" <[email protected]> wrote: Obviously I'm fine with this being merged into core if that's what the group wants to do. :) On Mon, Jul 12, 2010 at 5:49 PM, Manger, James H <[email protected]> wrote: .David, > I'd like this draft [draft-recordon-oauth-v2-ux-02.txt] to become a working > group document I disagree. This shouldn't be a working group document. It should be moved into the core. The 2 parameters it defines (language and display) should be moved to the core OAuth doc now they have obtained some consensus (for which a separate draft was helpful). I suggest a sub-section of section 3 "Obtaining End-User Authorization" (of the core spec) for user interface parameters. Possible structure: 3. Obtaining End-User Authorization [keep most of the existing paragraphs, except the definitions of the 5 parameters] [Add a paragraph saying various query parameters can be added to the end-user authorization URI to provide details or preferences about the style of response, the client application, the scope of access desired, the user, the user interface etc. Some parameters are defined in the following sub-sections. Other parameters can be defined by other specifications, or by services.] 3.1 Response style parameters response_type ... redirect_uri ... state ... 3.2 Client parameters client_id ... 3.3 User interface parameters language ... display ... 3.4 Scope of access parameters scope ...
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
