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>: > 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 > 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/ > > > > ---------------------------------------------------------------------- > 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 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 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 > https://www.ietf.org/mailman/listinfo/oauth > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
