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 protected]> 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? >> > > 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 protected]> 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:[email protected]] >> Sent: Tuesday, April 07, 2015 11:11 AM >> To: Phil Hunt >> Cc: The IESG; [email protected]; [email protected]; >> 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. > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
