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

Nat Sakimura sakimura at gmail.com
Mon Jul 29 13:26:07 UTC 2013


Right. Once we have diverted from /.well-known, but to ./.well-known, we
are polluting every directory.
Still, the conjecture I suppose was that it has less chance of collision
than some random other locations.
I think that was the sentiment of the group at the time.

This is the relevant ticket.

https://bitbucket.org/openid/connect/issue/638/discovery-using-issuer-identifer-w-path



2013/7/29 Torsten Lodderstedt <torsten at lodderstedt.net>

> **
>
> 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
>
>
>



-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20130729/35d50cf8/attachment.html>


More information about the Openid-specs-ab mailing list