I have a draft with Barry’s edits less the removal of ASCII(string) ready to go.
In JWS we used ASCII(string) to indicate that the output is a sequence of octets, strings are not necessarily 8 characters bits and may have null termination etc. However as Brian states other changes may have removed the need for that. I admit saying "where STRING is a sequence of zero or more ASCII characters.” looks a bit circular. How about saying "where STRING is a sequence of zero or more characters” The ABNF in Sec 4.1 should keep people from going too wrong on its own. I think it is OK the way it is, but am willing to change it if people feel strongly. Let me know if I should make that change or publish a draft without it, addressing the other comments. John B. > On Jul 7, 2015, at 5:40 PM, Kathleen Moriarty > <kathleen.moriarty.i...@gmail.com> wrote: > > Thanks for your responses on these comments. > > I can approve an updated draft to make this change and the one for IANA if > that is the easiest path. The other option is to write this all up in an RFC > editor note and I can send that with the approval. Making the direct updates > may be simpler to avoid mistakes. > > Can you submit a new version? > > Thank you, > Kathleen > > On Tue, Jul 7, 2015 at 12:35 PM, Brian Campbell <bcampb...@pingidentity.com > <mailto:bcampb...@pingidentity.com>> wrote: > Regarding the comment on Section 2, I had originally argued for the inclusion > of ASCII(xxx) as I felt it was important to avoid potential ambiguity that > was in the draft at the time (it wasn't 100% clear to me at the time if the > code_verifier was to be base64url decoded as input into the hash or if the > ASCII bytes were to be used). However, other content (particularly §4.1 > <https://tools.ietf.org/html/draft-ietf-oauth-spop-14#section-4.1>) has since > changed and removed the potential for the ambiguity I thought might be there. > > Which is a long way of explaining that I'm okay with Barry's proposed change > to Section 2, and occurrences of ASCII(...) throughout, despite it undoing > something I'd previously requested. > > On Tue, Jul 7, 2015 at 10:09 AM, Nat Sakimura <sakim...@gmail.com > <mailto:sakim...@gmail.com>> wrote: > Thanks Barry, > > > These are the issues that I wanted to discuss with John before making change. > > -- Section 6.2 -- John has partly addressed your IANA comment already. I > needed > to check if there was any reason for just doing partly. > > -- Section 7.2 -- is probably just my oversight. I will deal with it. > > -- Section 2 -- : I agree with you and I wanted to confirm it with John and > other people to commit the change. > > Cheers, > > Nat > > 2015-07-07 11:49 GMT+09:00 Barry Leiba <barryle...@computer.org > <mailto:barryle...@computer.org>>: > Barry Leiba has entered the following ballot position for > draft-ietf-oauth-spop-14: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > <https://www.ietf.org/iesg/statement/discuss-criteria.html> > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-oauth-spop/ > <https://datatracker.ietf.org/doc/draft-ietf-oauth-spop/> > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Version -14 resolves my DISCUSS (and also some of my non-blocking > comments). Thanks very much for considering these and working with me on > them! > > ========================================= > My comment about the IANA Considerations remains. While it's > non-blocking, I still hope you will accept the change I suggest: > > -- Section 6.2 -- > I have the same comment here as in the other OAuth document: please shift > the focus away from telling IANA how to handle tracking of the expert > review, and make the mailing list something that the designated expert(s) > keep track of. Also, please give more instructions to the DEs about what > they should consider when they're evaluating a request (for example, > should they approve all requests, or are there criteria they should > apply?). > > For the first, here's a text change that I suggest we move toward for > this sort of thing: > > OLD > <most of Section 6.2> > > NEW > Additional code_challenge_method types for use with the authorization > endpoint are registered using the Specification Required policy > [RFC5226], which includes review of the request by one or more > Designated Experts. The DEs will ensure there is at least a two-week > review of the request on the oauth-ext-rev...@ietf.org > <mailto:oauth-ext-rev...@ietf.org> mailing list, > and that any discussion on that list converges before they respond to > the request. To allow for the allocation of values prior to > publication, the Designated Expert(s) may approve registration once > they are satisfied that an acceptable specification will be > published. > > Discussion on the oauth-ext-rev...@ietf.org > <mailto:oauth-ext-rev...@ietf.org> mailing list should use > an appropriate subject, such as "Request for PKCE > code_challenge_method: example"). > > The Designated Expert(s) should consider the discussion on the > mailing list, as well as <<these other things>> when evaluating > registration requests. Denials should include an explanation > and, if applicable, suggestions as to how to make the request > successful. > END > > ========================================= > -- Section 7.2 -- > I find the first first paragraph confusingly worded, and after discussion > with the author I suggest this: > > NEW > Clients MUST NOT downgrade to "plain" after trying the S256 method. > Because servers are required to support S256, an error when S256 is > presented can only mean that the server does not support PKCE at all. > Otherwise, such an error could be indicative of a MITM attacker trying > a downgrade attack. > END > > ========================================= > Finally, there is this comment, which is not a big deal and you should > proceed as you think best: > > -- Section 2 -- > There is no real distinction between STRING and ASCII(STRING), because > STRING is already defined to be ASCII. Using "ASCII(xxx)" only adds > clutter, and a suggest removing it. > > So, for example, that would result in changes such as this: > > OLD > BASE64URL-ENCODE(SHA256(ASCII(code_verifier))) == code_challenge > NEW > BASE64URL-ENCODE(SHA256(code_verifier)) == code_challenge > END > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org <mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > <https://www.ietf.org/mailman/listinfo/oauth> > > > > -- > Nat Sakimura (=nat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ <http://nat.sakimura.org/> > @_nat_en > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org <mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > <https://www.ietf.org/mailman/listinfo/oauth> > > > > > > -- > > Best regards, > Kathleen
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
