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

[Justin Richer <[e-mail]>]

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

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 <[e-mail]> wrote:
> 
> 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:[e-mail]]
> Sent: Tuesday, April 07, 2015 11:11 AM
> To: Phil Hunt
> Cc: The IESG; [e-mail]; [e-mail]; 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.