search

openid / federation

4 stars 3 forks source link

Well-known URI path component MUST begin with /.well-known (in RFC 8615) #50

Closed SECtim closed 2 days ago

SECtim commented 3 weeks ago

Section 9 currently says: https://github.com/openid/federation/blob/48c673836f1eccfe99b74466093c41c1b708113c/openid-federation-1_0.xml#L5187-L5193

I read this as "take the Entity ID and append /.well-known/openid-federation to the (possibly, but not necessarily empty) path component of that Entity ID".

However, this is in conflict with RFC 8615, e.g., Section 3:

A well-known URI is a URI [RFC3986] whose path component begins with the characters "/.well-known/"

Also Section 3 (bold text highlighted by me):

Well-known URIs are rooted in the top of the path's hierarchy; they are not well-known by definition in other parts of the path. For example, "/.well-known/example" is a well-known URI, whereas "/foo/.well-known/example" is not.

And Section 4.1:

[...] well-known locations effectively represent the entire origin [...]

Since ID 4 contained a different formulation, I assume that there has been/is some ongoing discussion about this in the WG.

SECtim commented 3 weeks ago

Linking this to #36 - I think it is fine to do it the OIDC way, but then it is not in line with RFC 8615 and the Federation spec should point this out (especially considering RFC 8615 is a normative reference).

selfissued commented 2 weeks ago

We can add the requested clarification. As the spec used to say "Of course, in real multi-tenant deployments, in which the Entity Identifier might be of the form https://multi-tenant-service.example.com/my-tenant-identifier the tenant is very likely to not have control over the path https://multi-tenant-service.example.com/.well-known/openid-federation/my-tenant-identifier whereas it is very likely to have control over the path https://multi-tenant-service.example.com/my-tenant-identifier/.well-known/openid-federation." Developers were against the previous formulation, which required implementations to first try one location, which will usually fail, then try the other, which will then succeed. The old way entailed unnecessary spec and code complexity, a waste of network bandwidth, and was a needless cause of latency.

SECtim commented 2 weeks ago

I certainly agree that the newer formulation is better, especially from a security standpoint: What if the first request (in the old formulation) does NOT fail, but gets an answer (that is not controlled by my-tenant)?

Of course, one might argue that whoever controls /.well-known/openid-federation/my-tenant-id can probably also control /my-tenant-id/.well-known/openid-federation against my will if they want to, but that's a) not always the case, and b) might lead to issues even if the /.well-known/openid-federation/my-tenant-id response is "honest" (e.g., some non-standard error).