Subject: [OAUTH-WG] draft-hardt-oauth-distributed suggestions

From: Evert Pot <[email-masked]>
Date: Fri, 28 Sep 2018 23:10:51 -0400

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]: