Re: [OAUTH-WG] updated Distributed OAuth ID

[Brian Campbell <[e-mail]>]

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 <[e-mail]> wrote:

> 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/>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> 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._