Thanks John. > -----Original Message----- > From: John Panzer [mailto:jpan...@google.com] > Sent: Tuesday, December 08, 2009 11:29 AM
> Suggestion: It would be better to start with simple examples (bearer token) > which avoids the need to wade through concepts like timestamp > synchronization and authentication coverage in order to understand the > simplest possible flow? (E.g., the example in 1.2.) I am not worried about examples at this point. There will be plenty more if this draft is adopted. > Suggestion: Make it clear up front that protected resources are allowed and > encouraged to put a WWW-Authenticate: header on all requests (even ones > that return 200 for read-only access) to indicate what authentication is > allowed in general. (The equivalent of the "login" link on web pages that > present a read-only view.) Is this consistent with common practice? > In general, I think that much of the text could be made simpler by separating > out the coverage="none" case from the other cases. At the moment the > only method under discussion with coverage="none" is bearer token. I think > that's all there ever will be. If that's correct, perhaps separating out > things > that way would lead to a simpler reading experience (for the bearer token- > users for sure, and possibly for everybody else as they don't have to worry > about the special case of coverage="none" over and over again.) Agreed. I still need to rework the 'none' methods. > Section 5: "A client making a request for a protected resource either > directly, > or in retrying a request after receiving a 401 status code > (Unauthorized) with a token challenge, MUST include at least one > "Authorization" header field including token scheme credentials." > - This could be read as forbidding clients from querying protected resources > before figuring out what Authorization: header to use (as they sometimes > need to make an initial request to discover that the resource is > protected). Possibly just rewording to "credentialled request"? What is the > right terminology here? Authenticated request. > Suggestion: Calling the token method "none" is odd and jarring. It makes me > think about the classic routine "Who's on first?". How about "bearer"? As > in, > the method for request validation is to simply check that it bears the token. Plain, bearer, unsigned, blue, whatever. Don't care. Others ok with 'bearer'? > "relying solely on the > value of the token identifier to authenticate the client" > > Surely we are authenticating the request in all these > methods? (Authenticating the client may be a side effect, but it is neither > necessary nor sufficient.) Fixed. > Suggestion: Add a note (SHOULD) about using SSL / TLS when discussing the > bearer token option, either within this section or in the security > considerations section (couldn't find one after some searching). It's implied > by the discussion in section 8.1 but it's difficult to parse out. I'm hoping to make this a MUST. > "The "coverage" > attribute MUST be set to "none" but MAY be omitted from the request." > > This reads oddly -- I would assume that I can set it to anything if it's > omitted > :). Suggestion: MUST be either set to "none", or omitted from the request. Well, the value goes into the normalized string... > "Nevertheless, these attributes MUST be included in the normalized request > string together with any other authentication attributes." > > After quick read, I have no idea what this sentence means operationally. Can > you clarify? That when you create the normalized string, they are included even if they are not sent on the wire. I tried to keep the normalized string consistent regardless of method used. Does this sound like a good/bad idea? EHL _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
