Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-14.txt

From: [email-masked]
Date: Mon, 29 Jul 2013 12:32:13 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Web Authorization Protocol Working Group of the IETF.

	Title           : OAuth 2.0 Dynamic Client Registration Protocol
	Author(s)       : Justin Richer
                          John Bradley
                          Michael B. Jones
                          Maciej Machulak
	Filename        : draft-ietf-oauth-dyn-reg-14.txt
	Pages           : 36
	Date            : 2013-07-29

Abstract:
   This specification defines an endpoint and protocol for dynamic
   registration of OAuth 2.0 clients at an authorization server and
   methods for the dynamically registered client to manage its
   registration through an OAuth 2.0 protected web API.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-14

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-dyn-reg-14

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Anthony Nadalin <[email-masked]>
Date: Tue, 30 Jul 2013 07:47:03 +0000

I'm still confused by this specification, I do think it's an edge case and is not really in scope, we have the assertions draft that can be used to accomplish same thing and we don't have to define schema or protocol. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, July 29, 2013 12:32 PM
To: [email-masked]
Cc: [email-masked]
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-14.txt

Abstract:

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

_______________________________________________
OAuth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

---

From: Phil Hunt <[email-masked]>
Date: Tue, 30 Jul 2013 14:06:12 +0200

I think there are three deliverables that this spec (and the scim variant) are handling as part of registration:

1.  Issuance of a client_id -- yes this could be handled by an assertion only method
2.  issuance of an authentication credential (password, key, etc)
3.  Giving the service provider enough information about clients or groups of clients to manage them.

While we could go with an approach of present an assertion (e.g. software assertion) and get back a client assertion (following the SAML or JWT bearer specs), I don't think that approach works where the client authenticates by means other than bearer assertion.  IOW the exchange an assertion for a local assertion only works for specific cases.  Though I must say, it is incredibly simple!

As a criticism of both current reg drafts, they only really handle client_secret and need to have a more generalized handling or extension method for issuing tokens of other types such as bearer or some form of HoK token.

Phil

@independentid
www.independentid.com
[email-masked]

---

From: Anthony Nadalin <[email-masked]>
Date: Tue, 30 Jul 2013 12:26:38 +0000

I think that using assertions works in all cases I will have to go back and go through all the flows.

-----Original Message-----
From: Phil Hunt [mailto:[email-masked]] 
Sent: Tuesday, July 30, 2013 5:06 AM
To: Anthony Nadalin
Cc: [email-masked] WG
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-14.txt

1.  Issuance of a client_id -- yes this could be handled by an assertion only method 2.  issuance of an authentication credential (password, key, etc) 3.  Giving the service provider enough information about clients or groups of clients to manage them.

Phil

@independentid
www.independentid.com
[email-masked]

---

From: "Richer, Justin P." <[email-masked]>
Date: Tue, 30 Jul 2013 13:08:41 +0000

I fail to see how assertions are either simpler or more flexible than the "post-JSON-get-JSON" RESTful API pattern that runs the web. What we have now works in many established use cases (and has been implemented and deployed), and it even has been proven to be interoperable across domains. Especially because we can layer assertions on top of it for the cases that need assertions. I really look forward to the discussion around Phil's software assertions extension draft.

 -- Justin

---

From: "Richer, Justin P." <[email-masked]>
Date: Tue, 30 Jul 2013 13:36:09 +0000

New copy of the dynamic registration draft. In addition to some editorial updates and clarifications peppered throughout, this draft has included the "software_id" and "software_version" fields that Phil Hunt has proposed in his SCIM draft. They've been added to the client metadata section with some preliminary description language (based on discussion from the design team calls). This draft is the intended input for the presentation and discussion at the meeting in Berlin a few hours from now.

I've written a short presentation on the state of the draft that Mike Jones will be presenting in the room, and if all goes well I'll be logged in to the remote setup as well. 

 -- Justin