OAuth 2.0 Dynamic Client Registration Protocol
Note: This ballot was opened for revision 24 and is now closed.
(Kathleen Moriarty) Yes
(Jari Arkko) No Objection
(Alia Atlas) No Objection
Deborah Brungard No Objection
(Ben Campbell) No Objection
Comment (2015-04-06 for -27)
Section 2: The software_version "SHOULD change on any update identified with the same software_id" --why not MUST? What happens if this doesn't happen? "Extensions and profiles MAY expand this list.." -- That seems more like a statement of fact than a normative requirement. 3.2.1: client_id "SHOULD NOT be currently valid for any other registered client": Why not MUST? What happens if it is valid for another client? 4.1 and 4.2 allow the designated expert to accept preliminary registrations if they are confident a spec will be published. Shouldn't this follow the normal processes for preliminary registrations? Is there a way to walk back registrations if the spec isn't published after all? section 5: 4th paragraph after bullet list: "... authorization server needs to take steps to mitigate this risk...": Other statements like this have been normative. Is there a reason this one is not? 2nd paragraph from end: "... treat the new registration as being suspect": ... and do what?
(Spencer Dawkins) No Objection
(Stephen Farrell) (was Discuss) No Objection
Comment (2015-05-05 for -29)
My previous DISCUSS point (1) is below. That has been handled via new text in section 5 (on p27). I do wonder though if you ought also say a bit about, or point at a reference describing, the possible bad outcomes if one of these URLs goes bad. The new text I think assumes that the developer will get how bad that can be, but I'm not sure if they would or not. (1) General: there are many URIs sent to the AS from the client here. Nothing prevents the client messing about with the content served from those later, after registration. What mechanism holds clients accountable for such misbehaviours? (Examples, logo_uri, tos_uri, policy_uri, jwks_uri) Section 5 does say that the AS "SHOULD check" but does not say what "checking" means, nor what to do if the check fails. I think a bit more security considerations-like text here, reflecting what is (or ought;-) actually be done would be good. Do you agree? --- OLD COMMENTS, I didn't check if they'd been handled - s2, software_version: what is the impact if the s/w is updated twice a day, every day? - 3.2.1 - why is the response status 201? That may be correct, but seems to subtle if so to only state in an exmaple. - s5, last para - "be very particular" is not good spec language - what do you actually mean that can be implemented? - thanks for section 6 - it's great to see thought being devoted to these issues. - Did the secdir review  get a response? And I think I quite agree with Charlie's point#2 about versions.  https://www.ietf.org/mail-archive/web/secdir/current/msg05519.html
(Brian Haberman) No Objection
Comment (2015-04-08 for -27)
I support Stephen's DISCUSS point #1.