I read the Distributed OAuth draft, and I have a few comments and questions:
The draft defines 2 new link relations. "resource_uri" and "oauth_server_metadata_uri". However, the underscore is actually invalid[1]. On the IANA Links Relations registry[2], most existing link relations use dashes, or occasionally camel-case as a separator. I would suggest using dashes. I also don't think that the _uri postfix is needed, as the implication of any link is that it points to a uri. A second question I have is related to the resource_uri. The way I expect this specification to be used, is that a client will attempt to access a resource. When accessing it will be met with a 401 Unauthenticated along with meta-data that will help the client authenticate. To me the implication of this is that the resource_uri is the uri that the client tried to access. A more appropriate existing link relation might therefore be the 'self'. However, why would a resource server ever need to communicate what it's own url is? The explanation I can think of is that this is a mechanism for a resource to suggest a different resource to authenticate for. I'm curious what the use-case for this is. Regardless, I feel that the "resource_uri" name is going to be rejected on the basis that 'Resource Uri' is a generic concept on the web, but this draft assigns a very specific oauth2 meaning to it. I also have a question: One thing I've missed from using OAuth2-powered services over HTTP Basic / Digest, is the ability for a browser to handle login. The idea that a browser can potentially do all the steps required, means that a user could potentially hit a resource server directly and browse it interactively without requiring a non-browser client. I think this concept is really powerful, and Distributed OAuth is a good step in that direction. The piece that's missing though is that using the current OAuth2 framework, a generic client would still need to have a client_id. I don't fully understand the security implications of this, but could this specification potentially be expanded so that the WWW-Autenticate challenge can optionally also include a client_id? The way I see this work is that a browser could grab it and attempt using it with the implicit flow. I did some experimentation with this, and I believe that this feature could actually be built as a web extension, but it will only work in Firefox as Chrome does not give web extensions access to the Authorization header. If there is interest in this idea, I'm happy to help edit the current draft. Evert [1]: https://tools.ietf.org/html/rfc8288#section-3.3 [2]: https://www.iana.org/assignments/link-relations/link-relations.xhtml [3]: _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
