Subject: [OAUTH-WG] Extensibility: new endpoints

From: Torsten Lodderstedt <[email-masked]>
Date: Mon, 02 Aug 2010 21:53:48 +0200

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.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 2 Aug 2010 13:05:32 -0700

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-masked] [mailto:[email-masked]] On Behalf
> Of Torsten Lodderstedt
> Sent: Monday, August 02, 2010 12:54 PM
> To: OAuth WG ([email-masked])
> Subject: [OAUTH-WG] Extensibility: new endpoints
> 
> 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-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Torsten Lodderstedt <[email-masked]>
Date: Mon, 02 Aug 2010 22:06:58 +0200

and discovery does not belong into the core?

regards,
Torsten.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 2 Aug 2010 13:18:40 -0700

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

> From: Torsten Lodderstedt [mailto:[email-masked]]
> Sent: Monday, August 02, 2010 1:07 PM
> To: Eran Hammer-Lahav
> Cc: OAuth WG ([email-masked])
> Subject: Re: [OAUTH-WG] Extensibility: new endpoints
> 
> >> From: [email-masked] [mailto:[email-masked]] On
> >> Behalf Of Torsten Lodderstedt
> >> 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.
> >>
> >>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Mon, 02 Aug 2010 22:20:12 +0200

What consensus do you refer to? The WG charter?

regards,
Torsten.

Am 02.08.2010 22:18, 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
>>>
>>>
>>>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 2 Aug 2010 13:33:13 -0700

General discussions on the list and during the interim meeting.

EHL

> Sent: Monday, August 02, 2010 1:20 PM
> To: 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
> >
> >
> >>>> 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
> >>>> This would also facilitate the incorporation of additional
> >>>> endpoints (with well-defined names) into OAuth discovery.
> >>>>
> >>>> Any thoughts?
> >>>>
> >>>> regards,
> >>>> Torsten.
> >>>>
> >>>>

---

From: David Recordon <[email-masked]>
Date: Mon, 2 Aug 2010 14:37:06 -0700

That matches my understanding as well.

--David

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 3 Aug 2010 15:59:39 +0200

I'm fine with specifying OAuth discovery in an additional I-D/RFC (along with the extension I have asked for). As a consequence, does this mean you will remove all references to OAuth Discovery from the core specification?

Beside that, this raises another question: Are there additional functional areas to be include into the core spec? How many additional WG items/ upcoming RFCs complementing the core spec are planned?
What about the following topics?
- security considerations
- token revocation (requested by several attendees during Maastricht WG meeting)
- signatures

regards,
Torsten.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 3 Aug 2010 08:17:14 -0700

> Sent: Tuesday, August 03, 2010 7:00 AM
> To: Eran Hammer-Lahav
> I'm fine with specifying OAuth discovery in an additional I-D/RFC (along with
> the extension I have asked for). As a consequence, does this mean you will
> remove all references to OAuth Discovery from the core specification?

If we get a discovery spec ready in time, I'll reference it as one way to obtain configuration info. Otherwise I'll remove the references which are already marked with [].

> Beside that, this raises another question: Are there additional functional
> areas to be include into the core spec? How many additional WG items/
> upcoming RFCs complementing the core spec are planned?

I am sure there are going to be more WG items. Discovery might be one, signatures are likely to be one. Then there is the SAML work, artifact binding, device profile, UX, identity...

The main problem is lack of authors/editors to put the work in, not lack of 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.

> - 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
 
> tokens endpoint) have a relatively clearly semantics and scope.
> 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
> 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.
> 
>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 3 Aug 2010 17:25:28 +0200

> The main problem is lack of authors/editors to put the work in, not lack of ideas. I still hope to get the discovery spec finished in the same timeframe, but have no plans to author or edit any oth…

Just to get this clear. Do you plan to author the discovery spec? And what is the core spec's timeframe?

regards,
Torsten.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 3 Aug 2010 08:32:04 -0700

> Sent: Tuesday, August 03, 2010 8:25 AM
> To: Eran Hammer-Lahav
> > The main problem is lack of authors/editors to put the work in, not lack of
> 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.
> 

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).

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. 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 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).

EHL

> > 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.
> >
> > 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.
> >>
> >>
> >> 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
> >>
> >>
> >> (with well- defined names) into OAuth discovery.
> >>
> >> Any thoughts?
> >>
> >> regards,
> >> Torsten.
> >>
> >>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 04 Aug 2010 19:04:58 +0200

> 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 architectur…

Good luck!

regards,
Torsten.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 4 Aug 2010 15:45:20 -0700

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

> Sent: Wednesday, August 04, 2010 10:05 AM
> To: Eran Hammer-Lahav
> Cc: OAuth WG ([email-masked]); Brian Eaton
> >> 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.
> >>
> > 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
> - 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).
> >
> 
>  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
> >
> >
> >> 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.
> >>
> >>>
> >> 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
> >>>>
> >>>> endpoints (with well- defined names) into OAuth discovery.
> >>>>
> >>>> Any thoughts?
> >>>>
> >>>> regards,
> >>>> Torsten.
> >>>>
> >>>>

---

From: Brian Eaton <[email-masked]>
Date: Wed, 4 Aug 2010 17:09:17 -0700

> @Brian: What do you think?

Go for it.

> per flow/profile base by multiple contributers (anyone interested?). At
> least we should agree on a common set of threat agents and a template.

Yeah, the security considerations are different for different profiles.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 5 Aug 2010 10:07:09 +0200

> 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.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 5 Aug 2010 10:13:07 +0200

Brian,

I would like to start from your security considerations document. Do you have a documented threat model (attackers, attacks, propabilities) motivating the choosen counter-measures?

regards,
Torsten.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 5 Aug 2010 08:39:12 -0700

Didn't take it as criticism. I just like to be done. 

EHL