Thanks Brian. I am going to pick on this spec more than usual because I think it is a very important extension (and because it is my secret mission to make *you* cry). Important enough that I am going to propose it is included in the IETF version as an optional parameter. I want to be able to cut and paste this into the core spec...
I think this spec could be much more compact. This is purely editorial. I have no meaningful changes to the method itself. Section 2, 3.1: I would turn sections 2 and 3.1 into a single Introduction section. I would remove references to mailing list postings and sum up the OpenSocial use case as an example in the second paragraph. Next explain in 1-2 lines the difference between signing body and hashing body (because that is the big feature here). I think the normative text of 3.1 is not needed. The SHOULD is too strong here, and the MAY is stating the obvious. If you remove both or turn them to lowercase, you can move this text to the introduction. Also address the usefulness of this method over HTTPS. Move comment about PLAINTEXT from 3.3 here. Also: "An eavesdropper or man-in-the-middle who obtains a signed request URL may be able to replay that URL with a different HTTP request body" Should be: "An eavesdropper or man-in-the-middle who captures a signed request URL may be able to forward that URL with a different HTTP request body" Or something like that. The word 'replay' is misleading since the server cannot see the original request for this attack to work. Section 3: I would call this "The oauth_body_hash Parameter". It will make it much easier for developers to understand what is going on if you focus on the fact you are just adding a new parameter with a mini-workflow. Section 3.2: No need to define HTTP here. Simply state that if a request contains a body and is not form-encoded, it should use this method (the GET example is just confusing). Section 3.3: I would flip the order. First offer the generic rule for any signature method, then define it for the two methods from core. Section 3.4, 3.5: Merge together and write it in numbered steps. This was a big issue with the original core spec were instructions were given in a compressed paragraph form. Section 3.6: Same idea, turn into steps. Last paragraph is more a RECOMMENDED than SHOULD. Section 4: More steps: * Calculate the hash value and show it base64 encoded * Set the value of the oauth_body_hash parameter * Build signature base string * Sign request * Show full request with Auth header (which should be broken down to make it easier to read) Thanks for doing this! This is important stuff! Hope this feedback is useful. EHL > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf > Of Brian Eaton > Sent: Thursday, March 12, 2009 9:29 AM > To: [email protected]; [email protected]; > [email protected] > Subject: [oauth] last call for comments on body signing > > > Hi folks - > > I've neglected the body signing specification for a few months and I'd > like to wrap it up. A fresh draft is here: > > http://oauth.googlecode.com/svn/spec/ext/body_hash/1.0/drafts/3/spec.ht > ml > > Changes: > - language cleaned up to be more precise > - more detailed example > > Things that have not changed: > - no, I'm not going to do anything about HTTP header integrity. Write > another spec if you want that. > > I'm aiming to have a couple of reference implementations and a final > spec by next Friday, March 20th. > > Cheers, > Brian > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
