Am 05.08.2010 um 00:45 schrieb Eran Hammer-Lahav <e...@hueniverse.com>:
> 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: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
