Didn't take it as criticism. I just like to be done. EHL
On Aug 5, 2010, at 1:08, Torsten Lodderstedt <[email protected]> wrote: > > > > > Am 05.08.2010 um 00:45 schrieb Eran Hammer-Lahav <[email protected]>: > >> 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. >> > > I didn't intend to criticize you, I think you do a terrible good job as an > editor. I just offered my opinion of why this WG is not as focused as you > would expect it. > > regards, > Torsten. > > >> EHL >> >>> -----Original Message----- >>> From: Torsten Lodderstedt [mailto:[email protected]] >>> Sent: Wednesday, August 04, 2010 10:05 AM >>> To: Eran Hammer-Lahav >>> Cc: OAuth WG ([email protected]); 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 >>>>>>> <[email protected]>: >>>>>>> General discussions on the list and during the interim meeting. >>>>>>> >>>>>>> EHL >>>>>>> >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Torsten Lodderstedt [mailto:[email protected]] >>>>>>> Sent: Monday, August 02, 2010 1:20 PM >>>>>>> To: Eran Hammer-Lahav >>>>>>> Cc: OAuth WG ([email protected]) >>>>>>> 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:[email protected]] >>>>>>> Sent: Monday, August 02, 2010 1:07 PM >>>>>>> To: Eran Hammer-Lahav >>>>>>> Cc: OAuth WG ([email protected]) >>>>>>> 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: [email protected] [mailto:[email protected]] On >>>>>>> Behalf Of Torsten Lodderstedt >>>>>>> Sent: Monday, August 02, 2010 12:54 PM >>>>>>> To: OAuth WG ([email protected]) >>>>>>> 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 >>>>>>> [email protected] >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >> _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
