OAuth 2.0 Dynamic Client Registration Protocol
draft-ietf-oauth-dyn-reg-30
Yes
(Kathleen Moriarty)
No Objection
(Alia Atlas)
(Alvaro Retana)
(Barry Leiba)
(Deborah Brungard)
(Jari Arkko)
(Joel Jaeggli)
(Martin Stiemerling)
(Spencer Dawkins)
(Terry Manderson)
Note: This ballot was opened for revision 24 and is now closed.
Kathleen Moriarty Former IESG member
Yes
Yes
(for -24)
Unknown
Alia Atlas Former IESG member
No Objection
No Objection
(for -27)
Unknown
Alvaro Retana Former IESG member
No Objection
No Objection
(for -27)
Unknown
Barry Leiba Former IESG member
No Objection
No Objection
(for -27)
Unknown
Ben Campbell Former IESG member
No Objection
No Objection
(2015-04-06 for -27)
Unknown
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?
Brian Haberman Former IESG member
No Objection
No Objection
(2015-04-08 for -27)
Unknown
I support Stephen's DISCUSS point #1.
Deborah Brungard Former IESG member
No Objection
No Objection
(for -27)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(for -27)
Unknown
Joel Jaeggli Former IESG member
No Objection
No Objection
(for -27)
Unknown
Martin Stiemerling Former IESG member
No Objection
No Objection
(for -27)
Unknown
Spencer Dawkins Former IESG member
No Objection
No Objection
(for -27)
Unknown
Stephen Farrell Former IESG member
(was Discuss)
No Objection
No Objection
(2015-05-05 for -29)
Unknown
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 [1] get a response? And I think I quite agree with Charlie's point#2 about versions. [1] https://www.ietf.org/mail-archive/web/secdir/current/msg05519.html
Terry Manderson Former IESG member
No Objection
No Objection
(for -27)
Unknown