> -----Original Message----- > From: Peter Saint-Andre [mailto:stpe...@stpeter.im] > Sent: Saturday, March 26, 2011 6:56 AM
> >> 10. In Section 4.3.2 there is an open issue regarding internationalization > >> of > >> the client's username and password. What is the current thinking about a > >> resolution? > > > > Nothing. Leave it where HTTP Basic left it. Not ideal but after almost a > > year, > no one offered a text (including the person who raised the issue). > > I think that's fine here given that these are the usernames and > passwords of automated clients, not human users (as RFC 2277 says, > "internationalization is for humans"). This is the same as HTTP Basic, so these credentials belong to human users. We're just sticking out heads in the Basic Auth sand. > >> 13. In Section 8.2, are we really recommending "x_"? I must finish work on > >> draft-saintandre-xdash-considered-harmful... > > > > It's the simplest way to curve out a namespace for vendor specific > parameters that have no value or place being registered. We can't use URI's > for parameter names (that would be awful). Got other suggestions? > > Not yet. I'll give it more thought. One option is to use period as a reserved character for vendor-specific parameters such as 'yahoo.id' and 'google.lang'. This used to be a problem with older versions of PHP4 but I don't think it is an issue anymore. > >> 14. In Sections 10.1 and 10.2, I'm uncomfortable with this text: > >> > >> Before a period of 14 days has passed, the Designated Expert(s) will > >> either approve or deny the registration request, communicating this > >> decision both to the review list and to IANA. Denials should include > >> an explanation and, if applicable, suggestions as to how to make the > >> request successful. Registration requests that are undetermined for > >> a period longer than 21 days can be brought to the IESG's attention > >> (using the i...@iesg.org mailing list) for resolution. > > > > It's from RFC 5785 which was negotiated with the IESG before RFC 5988. I'll > make the switch to 5988. > > This was a bone of contention during IESG discussions of what became RFC > 5988, so the language from the latter spec should be less controversial. Yep. Been there. > >> 15. Section 10.2.1 says: > >> > >> Parameter usage location: > >> The location(s) where parameter can be used. The possible > >> locations are: authorization request, authorization response, > >> token request, or token response. > >> > >> Are those the only allowable locations? I notice that the bearer token > spec > >> adds a locations of "resource request" and "resource response". I'm not > >> quite saying we need a registry of locations, but it might be good to have > >> a > >> well-defined way of adding to the list of allowable locations (otherwise a > >> document like the bearer spec might need to say that it updates the base > >> spec). > > > > The bearer token proposal to extend the locations available is in violation > > of > the protocol and specification architecture. It is just a really bad idea. > Specifically, the idea of any registry defining HTTP URI query request > parameters is a violation of the provider's namespace. We can define a > registry for OAuth endpoints but not for protected resources which may not > even support any URI query or form-encoded body parameters. Doing so > would REQUIRE updating 2616. > > > > There are no use cases or requirements for extending the locations and no > extensibility is needed. > > So will draft-ietf-oauth-v2-bearer be fixed? Mike Jones is still pushing for this change, and in a way, holding the bearer token spec hostage... :-) EHL _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
