Responses inline:
2014-08-29 10:00 GMT+09:00 Mike Jones <michael.jo...@microsoft.com>: > Here's some feedback on the document. > > > > First, while I believe that the document is a good first working group > draft and this specification is important, it is not ready for last call, > since there are open issues called out in the document that have not been > discussed by the working group and aspects of the specification are > incomplete. I’ll discuss those below. There are also significant > ambiguities in the document at present that could lead to non-interoperable > implementations. I believe that it would be more appropriate to bring the > document to WGLC once these significant issues (and those that may be > raised by other reviewers) have been addressed. > > > > 2. Terminology – I would list “code challenge” before “code verifier” > both because it is used first and because it’s alphabetically first. > The "code verifier" is listed before "code challenge" as the later uses the former in its definition. > > > 2.1 code verifier – Is this an octet sequence to be sent as-is (with the > requirement for %-escaping octets representing non-url-safe characters) or > as the base64url encoding of the octet sequence? > Previously, it was agreed to be octet sequence and it is to be sent as-is. The clarification will be added. > > > 2.2 code challenge – Same question as above. Then I would just say that > the code challenge value is a function of the code verifier value and > discuss the possible functions in its own section or subsection. > Same as above. It is an open question whether we want to preserver the extensibility in the transformation at this time. If we decide not, then this spec will be further simplified and this point will become subsumed. > > > NOTE 1: This should be discussed in the section about the transformation > function. Also, say here what criteria people might use to choose function. > > > > NOTE 2: Also fold this into the transformation function section. > > > > 3.2 Client registers its desired code challenge algorithm – A means of > registering this algorithm using OAuth Dynamic Client Registration should > be defined. Use of this method should be optional. Any metadata values > defines should be registered in the appropriate registry. > As stated above, if we do not need extensibility, we do not need this section. My sense is that we do not. See my response to Hannes' detailed review. > > > 3.4 Client sends the code challenge – Is the code challenge octet sequence > value sent or the base64url encoding of it? > As above. > > > 3.6 Client sends the code and the secret – Is the code verifier octet > sequence value sent or the base64url encoding of it? > As above. > > > 4.1 OAuth Parameters Registry – The change controller should be “IESG”. > Yes. > > > 5. Security Considerations – The implications of choosing different kinds > of transformation functions should be discussed. > Will become unnecessary if we throw the extensibility away at this time. > > > I would recommend running the HTML output of xml2rfc through a grammar and > spelling checker, as numerous grammar nits would be caught by doing so. > Thanks for the advise. Best, Nat > > > -- Mike > > > > -----Original Message----- > From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig > Sent: Wednesday, August 27, 2014 8:45 AM > To: oauth@ietf.org > Subject: Re: [OAUTH-WG] Working Group Last Call on "Symmetric Proof of > Possession for the OAuth Authorization Code Grant" > > > > Based on the reaction from a few I thought I should add a few words about > this working group last call. > > > > There is no requirement to wait a specific timeframe after a document > became a WG item to issue a working group last call. > > > > In this specific case, the document was around for a while and I didn't > see a reason for not-finishing it as soon as possible. > > > > Additionally, since the document deals with a security vulnerability that > is being exploited today I thought it might make sense to get the attention > from the group to review it. > > > > Finally, it is also a fairly "simple" document (if there is something as > simple in this working group). > > > > Ciao > > Hannes > > > > On 08/26/2014 09:32 PM, Hannes Tschofenig wrote: > > > Hi all, > > > > > > This is a Last Call for comments on the "Symmetric Proof of Possession > > > for the OAuth Authorization Code Grant" specification. > > > > > > The document can be found here: > > > http://datatracker.ietf.org/doc/draft-ietf-oauth-spop/ > > > > > > Please have your comments in no later than September 9th. > > > > > > Ciao > > > Hannes & Derek > > > > > > > > > > > > _______________________________________________ > > > OAuth mailing list > > > OAuth@ietf.org > > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > _______________________________________________ > 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
