I hope to have some discovery draft to share shortly after the next core draft. It would be very much in line with the discovery stuff from previous core drafts before I took it out (-05).
As for WG process/focus, that's the job of the chairs to figure out. I have no intention of drafting or editing any additional specs beyond core and discovery. The only practical approach I have found is to simply ask people to express their views and request in the form of feedback for the latest draft. If you think something is missing or needs to change, the way to address it is as feedback. I will add or change the spec based on my best sense of WG consensus since that's all I have to work with. If you don't like this, please talk to the chairs. EHL > -----Original Message----- > From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net] > Sent: Wednesday, August 04, 2010 10:05 AM > To: Eran Hammer-Lahav > Cc: OAuth WG (oauth@ietf.org); Brian Eaton > Subject: Re: [OAUTH-WG] Extensibility: new endpoints > > > > >> ideas. I still hope to get the discovery spec finished in the same > >> timeframe, but have no plans to author or edit any other draft. > >> > >> Just to get this clear. Do you plan to author the discovery spec? And > >> what is the core spec's timeframe? > >> > > I have started to write the discovery spec, but work on the core spec has > taken most of my free time to do this (OAuth is not part of my day job). > > > > The same holds for me :-) Would you mind to share your thoughts regarding > discovery with the group. I especially would like to know, whether you agree > with the requirements I described in "OAuth Discovery Requirements" and > how they can be met. > > > I have no idea what's the timeframe for the core spec. This groups isn't > very good at providing timely feedback and staying focused. > > Good point. What might be the reasons for the missing focus? In my opinion, > there are a couple of. > > First of all, what is the "thing" we shall be focusing on? That's not clear > to me > (probably also to others). I therefore asked for your plans to include several > aspects in the core spec. Moreover, it's also not clear to me what > complementary specs and sub-sequent versions of the core spec the WG will > produce in the future. As an effect, everyone is afraid that his/her own ideas > are not being considered and focuses on advocating them. If we find a WG > consensus on the core spec or "first stage" and also the additional WG items, > work will probably become more focused. My impression after attending > IETF 78 is, bringing the core spec through the IETF approval process will be > hard enough! > > Additionally, I think the WG lacks consensus on what OAuth 2.0 should be, > especially regarding fundamental architectural questions and there > consequences! Just to list a few: > - supported use cases and client types (there is more than web clients :-)) > - number of resource servers an authorization can handle (1:1 vs. 1:n) > (resource server specific tokens + resource server addressing) > - supported token types (self-contained vs. artifacts vs. session ids) > - usage of scopes (resources vs. resource server vs. permissions vs. > duration vs. ...) > - role of signatures (none, authentication, prove of posession, message > integrity, ...) + key management approaches > - security level (none, relaxed, state-of-the-art, paranoid), probably there > is > a need for different OAuth security profiles > > This not only results in a spec difficult to understand for an "outsider". It > also > causes endless discussions around those or derived topics. > > > So far no one has offered to work on the security consideration section > (Brian's draft is too far from the format I need to incorporate). > > > > I could work on this topic, if Brian does not insist to do so. > @Brian: What do you think? > > From my point of view, the security considerations could be worked out on a > per flow/profile base by multiple contributers (anyone interested?). At least > we should agree on a common set of threat agents and a template. > > > I am planning the next draft for early September which will include the few > changes raised on the list, but will focus on finding a middle ground between > detailed profiles and a generic architecture (editorial work). > > > > Good luck! > > regards, > Torsten. > > > EHL > > > > > >>>> What about the following topics? > >>>> - security considerations > >>>> > >>> That's part of core and someone has to write it. I'd like to see > >>> someone > >>> > >> take the security section from RFC 5849 and rework it to match 2.0, > >> as well as add everything that is missing. I will incorporate it and > >> take care of the editorial work but I am not writing it from scratch. > >> > >>> > >>>> - token revocation (requested by several attendees during > >>>> Maastricht WG meeting) > >>>> > >>> Someone needs to write a proposal and work to get WG consensus (to > >>> the > >>> > >> point where enough people say they like it and no one is objecting). > >> Get it there, I'll do the rest. Feel free to ask the chairs to help out. > >> > >>> > >>>> - signatures > >>>> > >>> I think Nat offered to take a stab at a first draft based on Dirk's > >>> work and > >>> > >> the WG discussions. I have offered to help with editorial work if > requested. > >> > >>> EHL > >>> > >>> > >>>> regards, > >>>> Torsten. > >>>> > >>>> > >>>> Am 02.08.2010 um 22:33 schrieb Eran Hammer-Lahav > >>>> <e...@hueniverse.com>: > >>>> General discussions on the list and during the interim meeting. > >>>> > >>>> EHL > >>>> > >>>> > >>>> -----Original Message----- > >>>> From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net] > >>>> Sent: Monday, August 02, 2010 1:20 PM > >>>> To: Eran Hammer-Lahav > >>>> Cc: OAuth WG (oauth@ietf.org) > >>>> Subject: Re: [OAUTH-WG] Extensibility: new endpoints > >>>> > >>>> What consensus do you refer to? The WG charter? > >>>> > >>>> regards, > >>>> Torsten. > >>>> > >>>> Am 02.08.2010 22:18, schrieb Eran Hammer-Lahav: > >>>> No according to WG consensus. We took it all out because too many > >>>> people considered it experimental, so while it may be a WG item, it > >>>> is not part of the core spes. > >>>> > >>>> EHL > >>>> > >>>> > >>>> -----Original Message----- > >>>> From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net] > >>>> Sent: Monday, August 02, 2010 1:07 PM > >>>> To: Eran Hammer-Lahav > >>>> Cc: OAuth WG (oauth@ietf.org) > >>>> Subject: Re: [OAUTH-WG] Extensibility: new endpoints > >>>> > >>>> and discovery does not belong into the core? > >>>> > >>>> regards, > >>>> Torsten. > >>>> > >>>> Am 02.08.2010 22:05, schrieb Eran Hammer-Lahav: > >>>> > >>>> This doesn't belong in core. A registry is used to avoid name > >>>> collisions, not > >>>> > >>>> to provide an inventory. > >>>> > >>>> Maybe in discovery. > >>>> > >>>> EHL > >>>> > >>>> > >>>> > >>>> -----Original Message----- > >>>> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On > >>>> Behalf Of Torsten Lodderstedt > >>>> Sent: Monday, August 02, 2010 12:54 PM > >>>> To: OAuth WG (oauth@ietf.org) > >>>> Subject: [OAUTH-WG] Extensibility: new endpoints > >>>> > >>>> the existing authorization server endpoints (end-user authorization > >>>> and tokens endpoint) have a relatively clearly semantics and scope. > >>>> Adding distinct new functions to an authorization server will (in > >>>> my > >>>> opionion) require the definition of new endpoints. For example, I'm > >>>> working on an I-D for token revocation. Such a function does not > >>>> fit into the tokens endpoint since it has become a "token issuance > >>>> endpoint" rather than a general purpose client2server endpoint. > >>>> > >>>> I therefore would propose to include the option to define and > >>>> register new endpoints into the Extensibility section of the spec. > >>>> This would also facilitate the incorporation of additional > >>>> endpoints (with well- defined names) into OAuth discovery. > >>>> > >>>> Any thoughts? > >>>> > >>>> regards, > >>>> Torsten. > >>>> > >>>> > >>>> _______________________________________________ > >>>> 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
