On Thu, Feb 4, 2010 at 12:02 AM, Eran Hammer-Lahav <[email protected]>wrote:
> Thanks John. > > > -----Original Message----- > > From: John Panzer [mailto:[email protected]] > > 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? > We successfully did it for all feeds on AOL Journals for several years, with no bug reports. I don't know if anyone has done a recent survey. It's certainly allowed by the protocol, and it's the simplest way to flag what kind of auth is available IMHO. > > > 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? > > That makes sense, but perhaps it would be good to make it more explicit: The default values are explicitly included in the normalized string for purposes of generating the signature, even if not sent on the wire. (Are you sure it wouldn't be better to just eliminate default values entirely?) > EHL >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
