Subject: [OAUTH-WG] [oauth] #6: Make automated self-registration of unique clients possible

From: "oauth issue tracker" <[email-masked]>
Date: Sun, 16 May 2010 17:00:01 -0000

#6: Make automated self-registration of unique clients possible
-----------------------------+----------------------------------------------
 Reporter:  eve@…            |       Owner:     
     Type:  enhancement      |      Status:  new
 Priority:  major            |   Milestone:     
Component:  authentication   |     Version:     
 Severity:  -                |    Keywords:     
-----------------------------+----------------------------------------------
 There are some cases where subsequent correlation of initially anonymous
 clients is desirable (just as there are some cases where humans can self-
 choose a username and password at a website). It would be helpful to have
 a standard, interoperable "pre-flow" that precedes normal token-getting
 flows for issuing a unique client_id and client_secret to walk-up clients.
 The alternative is documenting, or letting the client discover, statically
 allocated credentials that don't distinguish it from other clients. For at
 least the uses to which UMA is putting OAuth, and possibly for others as
 well, it would be useful to have enough context to distinguish clients
 uniquely outside of the context of the access token it is ultimately
 given.

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/oauth/trac/ticket/6>
oauth <http://tools.ietf.org/oauth/>

---

From: "oauth issue tracker" <[email-masked]>
Date: Sun, 16 May 2010 19:10:08 -0000

Comment(by recordond@…):

 I proposed http://openidconnect.com/#associations for OpenID Connect.
 While I think it could become part of OAuth 2.0, the spec is already
 getting way too long.

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/oauth/trac/ticket/6#comment:1>
oauth <http://tools.ietf.org/oauth/>

---

From: "oauth issue tracker" <[email-masked]>
Date: Sun, 16 May 2010 22:46:50 -0000

Comment(by eve@…):

 (I agree the spec is getting pretty long. I wonder if it's possible to do
 some factoring-out of common text, e.g. regarding common features of
 flows, to mitigate this. The length is actually making me waver a bit on
 my previously shared opinion about including all the currently known flows
 into the core protocol document...)

 Thanks for pointing to this piece of the OpenID Connect proposal. I tend
 to think that a whole "discovery" solution would be an appropriate
 modularity boundary, so maybe this piece of the proposal could be combined
 with some of the stuff we're having to define in UMA, into a new Discovery
 2.0 proposal or something.

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/oauth/trac/ticket/6#comment:2>
oauth <http://tools.ietf.org/oauth/>

---

From: Dick Hardt <[email-masked]>
Date: Sun, 16 May 2010 15:52:58 -0700

> #6: Make automated self-registration of unique clients possible

IMHO: Reading one long document is better than reading two or more shorter documents that combined are the same size or longer. I think the current factoring in the document lets someone read only the flows they need. If need be, we could clarify that in the copy. I had that in WRAP.

-- Dick

---

From: Eve Maler <[email-masked]>
Date: Mon, 17 May 2010 07:03:07 -0700

> IMHO: Reading one long document is better than reading two or more shorter documents that combined are the same size or longer. I think the current factoring in the document lets someone read only…

Actually, reading V2-05 carefully yesterday, I found that it had indeed already factored out everything that could be, and that it's pretty much the right length and organization for its current purpose.  So never mind. :)

	Eve

Eve Maler
[email-masked]
http://www.xmlgrrl.com/blog