Subject: Re: [OAUTH-WG] Ben Campbell's No Objection on draft-ietf-oauth-dyn-reg-27: (with COMMENT)

From: Mike Jones <[email-masked]>
Date: Tue, 7 Apr 2015 22:09:03 +0000

I think that the current SHOULD is more realistic.  In the real world, particularly while developing and testing, people will have many iterations of pre-release software for a given version, all of which will likely be identified with the intended version number before the final release of that version of the software is made.

				-- Mike

-----Original Message-----
From: Ben Campbell [mailto:[email-masked]] 
Sent: Tuesday, April 07, 2015 11:11 AM
To: Phil Hunt
Cc: The IESG; [email-masked]; [email-masked]; Justin Richer
Subject: Re: Ben Campbell's No Objection on draft-ietf-oauth-dyn-reg-27: (with COMMENT)

On 7 Apr 2015, at 13:03, Phil Hunt wrote:

> 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?
>
>
> The group didn’t necessarily agree to make software_version mandatory 
> to provide. Thus the word, SHOULD seemed appropriate to indicate that 
> if used it SHOULD change from version to version. That said, I am ok 
> with MUST (e.g. if software_version is used, it MUST change...).
>
> In answer to your question what happens: this is not so much a 
> security issue (in the traditional sense of an attacker), but rather a 
> regular software versioning/maintenance issue. The idea is that some 
> client software updates may prove to be buggy (or have performance
> issues) and service providers may want to be able to refuse some 
> versions of client software while accepting others (e.g. 2.5 is broken 
> and causes DoS issues, while 2.5.1 is acceptable).  If a version is 
> not provided, than an AS’s only choice is to ban all versions and 
> force the client developer to use or obtain a different software_id 
> for future registrations.

Thanks for the response. I can live with either a SHOULD or a MUST, but if the SHOULD stays, it would be good to add a sentence or two to the effect of the above paragraph. That being said, "If used, it MUST change" seems to be more precise if that fits the WG intent.

---

From: Justin Richer <[email-masked]>
Date: Tue, 7 Apr 2015 17:51:26 -0700

> same software_id" --why not MUST? What happens if this doesn't happen?
> 

I agree with Mike that the SHOULD is more realistic, especially because the definition of “version” isn’t something that we can really lock down a lot from the spec’s perspective.

What we can do though is add some text, as Ben suggests, that says why the SHOULD ought to be applied in the common case and what kinds of exceptions there are. I’ll try to work something out based on the discussion threads here and add it to the draft.

To the other issues:

> 
> "Extensions and profiles MAY expand this list.." -- That seems more like
> a statement of fact than a normative requirement.
> 

Noted, we’re just trying to say that there are others items that could be in there. We can change the “MAY” to “can”.

> 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?

We’ve got some text on re-use of the client_id in the security considerations section.

> 
> 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?

I’ll defer to others’ expertise on the right text for the IANA section, this was imported from another example spec.

> 
> 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?

No specific reason that I recall, except that there’s not a specific step that we prescribe. We can make that a MUST.

> 
> 2nd paragraph from end: "... treat the new registration as being
> suspect": ... and do what?
> 
> 

Good catch, I think that thought is unfinished. It’s up to the AS in the end, but it should probably reject the registration.

 — Justin

> On Apr 7, 2015, at 3:09 PM, Mike Jones <[email-masked]> wrote:
>

---

From: Justin Richer <[email-masked]>
Date: Tue, 21 Apr 2015 21:30:57 -0400

Ben et. al,

We’ve incorporated feedback into the latest draft:

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

Hopefully this addresses all of the comments below. Thank you for your review!

 — Justin

> On Apr 7, 2015, at 8:51 PM, Justin Richer <[email-masked]> wrote:
> 
>> Section 2:
>> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Mike Jones <[email-masked]>
Date: Wed, 22 Apr 2015 23:35:25 +0000

I'd be fine adding the BCP 100 reference.  I'd rather that we keep the early registration procedures language.

				-- Mike

-----Original Message-----
From: Ben Campbell [mailto:[email-masked]] 
Sent: Wednesday, April 22, 2015 2:31 PM
To: Justin Richer
Cc: [email-masked]; Phil Hunt; <[email-masked]>; Mike Jones; The IESG; [email-masked]
Subject: Re: [OAUTH-WG] Ben Campbell's No Objection on draft-ietf-oauth-dyn-reg-27: (with COMMENT)

On 21 Apr 2015, at 20:30, Justin Richer wrote:

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

I think that resolves all my comments save one:

[...]

>> I’ll defer to others’ expertise on the right text for the IANA 
>> section, this was imported from another example spec.
>>

BCP 100 (RFC 7120) describes the IANA early allocation procedures. You 
might consider a reference to that, so you can capture the processes for 
walking back allocations that don't get finalized. Or, unless you want 
additional restrictions not in the BCP, you could leave out mention of 
early allocations completely, and let IANA deal with it according to 
standard procedures.

[...]

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 22 Apr 2015 22:13:07 -0400

Thanks, guys.  Let me know when tis has been addressed.

Kathleen

On Wed, Apr 22, 2015 at 7:35 PM, Mike Jones <[email-masked]>
wrote:

> Subject: Re: [OAUTH-WG] Ben Campbell's No Objection on
> draft-ietf-oauth-dyn-reg-27: (with COMMENT)
>

-- 

Best regards,
Kathleen

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 22 Apr 2015 16:31:13 -0500

[...]

[...]

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 22 Apr 2015 22:06:04 -0500

> early registration procedures language.

That would work for me.

> Cc: [email-masked]; Phil Hunt; <[email-masked]>; 
> Mike Jones; The IESG; [email-masked]