[Openid-specs-ab] .well-known in OIDC Discovery

John Bradley ve7jtb at ve7jtb.com
Mon Jul 29 13:45:42 UTC 2013

We could have made the issuer a full path to the discovery document.  The decision was to make the issuer shorter by placing the discovery document at a well known location relative to the issuer URI.   The .well-known directory is a place where system configuration files are likely to live.  Some large IdP may be using smart TLS terminators to direct this to a compleatly separate server from regular content.   Putting the config there seemed to make administrative sense.

Later in the process supporting multi-tennent per domain name was identified as important.   That was when paths were allowed in the issuer as there were originally not part of the issuer. 
Adding the same relative path to the URI containing a path made the client processing easier and did not change the simple case


On 2013-07-29, at 3:09 PM, Torsten Lodderstedt <torsten at lodderstedt.net> wrote:

> I don't get that argument. From my perspective, using .well-known makes sense if one does not use any other discovery mechanism. Then ./well-known allows to place meta data at a certain location (root folder) on a host. That's simple.
> OIDC works completely different as it allows to place this data anywhere (with respect to the URL) and discovers this location. 
> Am 29.07.2013 14:55, schrieb Nat Sakimura:
>> General answer, I guess, is that we wanted to minimize the URI pollution - that we should confine the URI pollution just withing .well-known folders. 
>> 2013/7/29 Torsten Lodderstedt <torsten at lodderstedt.net>
>> Hi all,
>> I just took a look on the OIDC discovery spec. Why does it use .well-known? I'm asking since it deviates from the RFC in that it allows for path components (in order to support multi-tenancy) and the URL itself is either discovered via WebFinger or obtained out of band. Why not just obtain the connect config base URL that way and directly request the metadata. What is the value of adding "/.well-known" to the URL?
>> regards,
>> Torsten.
>> _______________________________________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>> -- 
>> Nat Sakimura (=nat)
>> Chairman, OpenID Foundation
>> http://nat.sakimura.org/
>> @_nat_en
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20130729/d5d912fe/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4507 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20130729/d5d912fe/attachment.p7s>

More information about the Openid-specs-ab mailing list