[Openid-specs-fastfed] WebFinger discovery using subdomains

[Dick Hardt]

I missed the webfinger discussion as well, and near the end of the meeting
last week, some people mentioned they would not be supporting the webfinger
discovery.

Given that, I think there is room for discussion.

On Tue, Dec 17, 2019 at 3:51 PM Karl McGuinness via Openid-specs-fastfed <
openid-specs-fastfed at lists.openid.net> wrote:

> Hello FastFed WG,
>
> I have been trying to post this for awhile but have had issues with
> mailing list permissions.  The current draft spec defines an extension to
> Webfinger using subdomains
>
> The subdomain location is determined by prefixing the email domain
>    with ""webfinger._well_known"".  For example, if the user email is
>    ""babs at example.com"", the resulting Webfinger endpoint is
>    ""https://webfinger._well_known.example.com"".
>
>    Application Providers performing WebFinger discovery MUST first
>    attempt to read from the subdomain endpoint.  If the response is not
>    an HTTP 200, the Application Provider MUST subsequently attempt
>    reading from the traditional WebFinger path at the root domain.  A
>    non-normative example is illustrated in Section 4.1.2.1.2.
>
>
> I remember discussing this at IIW last year and wasn’t sure if we settled
> on this approach.  I remember some folks saying that this approach wouldn't
> fly in IETF land.  Alternative approaches such as DNS SRV or TXT records
> were also discussed.  Folks liked the simplicity of using DNS host records
> so that devs could just plop it into a connection string and the magic of
> the URL would do its thing.
>
> We have an internal use case for discovery of an openid issuer based on
> email suffix where customers don’t want to host a webfinger endpoint.
> Customers *might* be able to delegate the entire webfinger endpoint to our
> SaaS using a subdomain but it might not be something we are authoritative
> for for all webfinger queries.
>
> We were looking at
> https://tools.ietf.org/html/draft-sanz-openid-dns-discovery-01 as a
> possible solution to serialize webfinger results in a TXT record.  This
> removes the need for administrators to maintain (scale, availability, etc)
> an endpoint for webfinger for relatively static results such as issuer
> which can be cached.  I could see us extending this to support a fedfed tag
> as well.  The dev friction of using TXT records is slowly being ameliorated
> as DNS over HTTP becomes mainstream (see
> https://developers.google.com/speed/public-dns/docs/doh/json).  I’m
> making assumption that the admin friction of creating TXT records is
> similar to host/subdomain records which may not be true for all enterprises.
>
> Is it worth rehashing this topic or has it already reached consensus in
> the WG?
>
> -Karl
> _______________________________________________
> Openid-specs-fastfed mailing list
> Openid-specs-fastfed at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-fastfed
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-fastfed/attachments/20191217/78163a44/attachment.html>