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 <jaredhan...@gmail.com> 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 > 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
