Subject: [OAUTH-WG] New Working Group Items?

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 03 Feb 2011 18:19:26 +0200

Hi all,

while we are hopefully coming to an end with the main specification (and 
the two other WG items) I need to put text for re-chartering together. 
The entire process typically takes a little while because

* I need your feedback (hence this mail) of what you guys want to work on
* I have to draft a charter text (and the group needs to be happy with it)
* the IESG (who receives the charter text) also needs to agree with it
* finally the documents need to be submitted as working group items and 
progressed in the group.

While a few of you have responded already to an earlier query (see 
http://www.ietf.org/mail-archive/web/oauth/current/msg04352.html)  there 
wasn't enough feedback.

Again, here are the documents that have been put forward. When you 
express interest for a specific item please also provide a bit of 
additional information. For example, it would be good to know whether 
you are willing to do reviews, whether you even have time to co-author 
the specification, whether you want to implement or deploy a specific 
mechanism, etc. It is quite simply: if there is no interest in the work 
(other than from the authors) then it does not make sense to turn it 
into a working group item. If there is nobody who wants to review or 
edit the document then we cannot pick it up either.

Also note that these document are only used as a *starting point* and 
they are very likely going to change as we work on them. Feel free to 
express your thoughts about the content as well. Would be nice to know 
whether you think that the document needs to be, for example, enhanced 
in a specific direction.

Long introduction - here are the documents:

A) Simple Web Discovery (SWD)
http://www.ietf.org/id/draft-jones-simple-web-discovery-00.txt

B) HTTP Authentication: MAC Authentication
http://datatracker.ietf.org/doc/draft-hammer-oauth-v2-mac-token/

C) Token Revocation
http://tools.ietf.org/html/draft-lodderstedt-oauth-revocation-01

D) OAuth 2.0 Device Profile
http://tools.ietf.org/html/draft-recordon-oauth-v2-device-00

E) OAuth 2.0 User Experience Extension
http://tools.ietf.org/html/draft-recordon-oauth-v2-ux-00

F) Request by Reference ver.1.0 for OAuth 2.0
http://tools.ietf.org/html/draft-sakimura-oauth-requrl

G) OAuth Dynamic Client Registration Protocol
http://tools.ietf.org/html/draft-oauth-dyn-reg-v1

H) OAuth Use Cases
http://tools.ietf.org/html/draft-zeltsan-oauth-use-cases

I) OAuth Client Instance Extension	
http://datatracker.ietf.org/doc/draft-richer-oauth-instance/

J) XML Encoding for OAuth 2	
http://datatracker.ietf.org/doc/draft-richer-oauth-xml/

K) OAuth 2.0 support for the Kerberos V5 Authentication Protocol
http://datatracker.ietf.org/doc/draft-hardjono-oauth-kerberos

Please let me know if I have forgotten something.

I also hope that Torsten is able to submit a security document soon!

Ciao
Hannes

PS: You may notice that I haven't placed 
http://tools.ietf.org/html/draft-jones-json-web-token-01 on the list yet 
since I believe we will get push-back from the IESG on that item at the 
moment.

---

From: "Manger, James H" <[email-masked]>
Date: Fri, 4 Feb 2011 15:38:54 +1100

Hannes,

I would like one more item in the list:
* OAuth2 discovery from the response to any HTTP request, probably via a WWW-Authenticate response header. I am keen to contribute, and perhaps co-author such a spec.

> http://datatracker.ietf.org/doc/draft-hammer-oauth-v2-mac-token/

I'm happy to review.

> http://tools.ietf.org/html/draft-recordon-oauth-v2-ux-00

I'm happy to support.

--
James Manger

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 3 Feb 2011 23:32:35 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Hannes Tschofenig
> Sent: Thursday, February 03, 2011 8:19 AM

> http://www.ietf.org/id/draft-jones-simple-web-discovery-00.txt

This has no business in this working group. It is not even the appropriate venue for discussions (the application area list is much more suitable). In addition, it is directly competing with other efforts without any attempt to address them.

> http://datatracker.ietf.org/doc/draft-hammer-oauth-v2-mac-token/

I am not sure I want this to become a WG item, given the WG's apparent interest in engineering a solution that involves repeating HTTP bits in a signature specific payload. I am only interested in making this an official WG item if it is clearly scoped to work with a single HTTP request (i.e. no Digest like round trips), and without any duplication of request bits (HTTP method, request URI, etc.). This does not preclude such proposals, but that's a completely separate item.
 
MAC is already implemented in an open source library and in a product that will ship in the next few month.

> http://tools.ietf.org/html/draft-lodderstedt-oauth-revocation-01

Will review.

> http://tools.ietf.org/html/draft-recordon-oauth-v2-device-00

Will review.

> http://tools.ietf.org/html/draft-recordon-oauth-v2-ux-00

Will review and happy to help with editorial.

> http://tools.ietf.org/html/draft-oauth-dyn-reg-v1

No objections but this feel premature. I would like to see some working implementations of this in shipped products. 

> http://tools.ietf.org/html/draft-zeltsan-oauth-use-cases

I am not sure if this is worth the effort if it requires WG resources, but if the author is willing to keep working on it, I support its publication.

EHL

---

From: Torsten Lodderstedt <[email-masked]>
Date: Mon, 07 Feb 2011 21:02:38 +0100

> http://www.ietf.org/id/draft-jones-simple-web-discovery-00.txt

I consider authorization server endpoints and capabilities discovery an 
important aspect and would be willed to review.

> http://datatracker.ietf.org/doc/draft-hammer-oauth-v2-mac-token/

Review.

> http://tools.ietf.org/html/draft-lodderstedt-oauth-revocation-01

Editor. I will submit another revision based on the WG feedback before 
IETF-80.

> http://tools.ietf.org/html/draft-recordon-oauth-v2-device-00

I'm very interested to bring this forward (reviewer).

> http://tools.ietf.org/html/draft-recordon-oauth-v2-ux-00

Review.

> http://tools.ietf.org/html/draft-oauth-dyn-reg-v1

Another important aspect I would like to support (reviewer).

> http://tools.ietf.org/html/draft-zeltsan-oauth-use-cases

co-author

> http://datatracker.ietf.org/doc/draft-richer-oauth-instance/

This is, in my opinion, the same problem domain as 
http://tools.ietf.org/html/draft-oauth-dyn-reg-v1 and I would suggest to 
align those I-Ds.

> I also hope that Torsten is able to submit a security document soon!

You can bet on it!

regards,
Torsten.
> http://tools.ietf.org/html/draft-jones-json-web-token-01 on the list 
> yet since I believe we will get push-back from the IESG on that item 
> at the moment.
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Justin Richer <[email-masked]>
Date: Tue, 8 Feb 2011 15:01:04 -0500

> http://datatracker.ietf.org/doc/draft-hammer-oauth-v2-mac-token/
In favor of adopting as WG item, willing to review.

> http://tools.ietf.org/html/draft-lodderstedt-oauth-revocation-01
In favor of adopting as WG item, willing to review.
> http://tools.ietf.org/html/draft-recordon-oauth-v2-ux-00
In favor of adopting as WG item, willing to review.

> http://tools.ietf.org/html/draft-zeltsan-oauth-use-cases
Don't think it's really a WG item, but worth keeping around. Also, 
should be merged with UMA use cases.

> http://datatracker.ietf.org/doc/draft-richer-oauth-xml/
I'm the editor for both of these and would like to see them adopted as 
WG items.

-- Justin

---

From: Igor Faynberg <[email-masked]>
Date: Tue, 08 Feb 2011 15:23:38 -0500

Hannes,

A comprehensive list!

I am in support of all items listed, and I commit to reviewing all of 
them (and contributing where I will see significant gaps).

One comment on the use cases (my pet peeve).  Those were specifically 
requested by Peter at the first OAuth meeting, and I think they were 
requested for a very good reason.

Even then--and more often now--whenever a feature appears, there comes 
up a question "What is the use case?"  Then a discussion starts.  Then 
the feature is agreed on and added. And then... someone who was not 
present at the previous discussion looks at the protocol spec asks a 
question: "What is the use case for this?.."

I think a lot of time would have been saved, if every feature had been 
linked to a crisp use case.  As the capabilities of OAuth grow, the 
protocol specification will become soon overwhelming if not altogether 
unreadable: people think it terms of services rather than combinations 
of parameters and messages.

I strongly believe that we will much more effective if we develop--and 
document the protocol--top down. 

Igor

Hannes Tschofenig wrote:
> ....
> * finally the documents need to be submitted as working group items 
> and progressed in the group.
>
>
>
>
>

Review.