Subject: Re: [OAUTH-WG] updated Distributed OAuth ID

From: Jared Hanson <[email-masked]>
Date: Tue, 12 Jun 2018 15:57:12 -0700

Thanks Dick, Nat and Brian for your work on this ID.  I have a couple
improvements I would like to discuss:

I would suggest replacing the "oauth_server_metadata_uri" link relation
with "oauth2-isser", and dropping the ".well-known" suffix from the value.
For example:

Link: <https://as.example.com>; rel="oauth2-issuer"

The rationale for this are two-fold:

1. It allows the discovery mechanism to be more flexible, or application
specific.  For instance, OpenID Connect discovery could be used and take
advantage of already deployed ".well-known/openid-configuration"
documents.  Applications could also take advantage of other discovery
mechanisms, either now (such as LRDD and WebFinger) or in the future.

2. It aligns the syntax (underscores vs dash) with
https://tools.ietf.org/html/draft-wmills-oauth-lrdd-07
(which I also think should be revived as link relations).  Also, existing
conventions with registered link relations seem to prefer dashes rather
than underscores.

I would suggest replacing the "resource_uri" link relation with "canonical"
(RFC6596), which seems to fit the purpose and avoids registering a
potentially duplicative link relation value.

There is language in the draft requiring the client to check "host" values
between TLS certificates and link relation values.  This seems unnecessary
to me, for a couple reasons.

1. It unnecessarily constrains the logical organization of resources, which
may be hosted on multiple domains and yet have a canonical URL by which
other systems, including the authorization server, identify them.  Allowing
the canonical URL to differ from the host of the initial request will avoid
these limitations.

2. The resource server must ultimately do audience checking in order to
validate the access token.  I believe this accounts for all the security
considerations, and alleviates the burden from the client to do any
checking itself.

Jared Hanson
Auth0 Inc.

-- 
Jared Hanson <http://jaredhanson.net/>

---

From: Brian Campbell <[email-masked]>
Date: Wed, 13 Jun 2018 15:43:28 -0600

Thanks for the review and suggestions, Jared. A token (pun intended!)
attempt at addressing your comments follows.

Though I don't think I actually discussed it with my co-authors, I did
think about the link relation for the AS being the issuer rather than
pointing to the metadata document under ".well-known".  I must admit that I
kinda liked using the full URL to the metadata because it relieved the
client from having to figure it out from the issuer. Which could be
cumbersome for clients given that there's both
".well-known/openid-configuration"
and the soon to be ".well-known/oauth-authorization-server" as well as
different procedures for forming the full metadata URL from the issuer
value when the issuer contains a path component. Having said that though,
I'm inclined to agree with you that the *right* thing to do here is have
the link relation to the AS be just the issuer value. Or at lest invite
more discussion about it. "oauth2-isser" seems a perfectly reasonable
relation name, should we take that route.

The idea behind the "resource_uri" link relation (and this likely needs to
be expanded on better in the document) is that it is like the base URL of
the application 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/>. RFC6596 says in
the abstract that the "canonical" Link Relation is used to "designate an
Internationalized Resource Identifier (IRI) as preferred over resources
with duplicative content".  "canonical" doesn't seem to fit the purpose
from that text and reading RFC6596 didn't help me see it fit either. I
looked through the registry for Link Relation Types and nothing jumped out
at me as being applicable for this.

The client check of the host in the link relation to the host where the
request was made is intended to protect against what the draft calls
Resource Server Impersonation in 6.2 where a bad RS would return a 401 with
a link relation for a different sever which would result in the client
asking for a token for that different server but using it with the bad
server, who in turn could replay it at the different server. PoP tokens
could also prevent such replay in a different way but for bearer tokens I
think the check is needed to ensure the right audience gets into the token.

On Tue, Jun 12, 2018 at 4:57 PM, Jared Hanson <[email-masked]> wrote:

> 2.. It aligns the syntax (underscores vs dash) with
> I would suggest replacing the "resource_uri" link relation with
> "canonical" (RFC6596), which seems to fit the purpose and avoids
> registering a potentially duplicative link relation value.
>
> 1. It unnecessarily constrains the logical organization of resources,
> which may be hosted on multiple domains and yet have a canonical URL by
> which other systems, including the authorization server, identify them.
> Allowing the canonical URL to differ from the host of the initial request
> will avoid these limitations.
>
> checking itself..
> _______________________________________________
> OAuth mailing list
> [email-masked]
> 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._