Nearly a month later (sorry) replies to some of the comments/questions are inline below.
On Fri, Sep 28, 2018 at 9:11 PM Evert Pot <m...@evertpot.com> wrote: > 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]. > Well that's definitely a problem that needs to be fixed. Doh. Thanks for pointing that out! > 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. > The idea or use-case behind the "resource_uri" link relation (and this likely needs to be explained better in the document and clearly the name needs to change) is that it is likely to be a more general URI than the specific request was made to. Like a base URL for the whole application, API, or set of protected resources. So, for example, both a request to https://api.example.com/someapp/stuff/abc123 and https://api.example.com/someapp/stuff/xyz789 might get a 401 with resource_uri link relation value of <https://api.example.com/someapp/>;. Or a requests to https://resources.example.com/some/deeper/path/here and https://resources.example.com/things might both get a 401 with resource_uri link relation value of <https://resources.example.com/>;. So 'self' isn't quite right for 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. > > I do suspect there'd need to be a serious look at the security implications of something like that. And my sense is that it is beyond the scope of the distributed oauth document. 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 > -- _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you._
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
