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
