<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
<div class=""><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-family: ProximaNova-Regular;" class="">Hello FastFed WG,</span></div>
<div class="" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-family: ProximaNova-Regular;">
<br class="">
</div>
<div class="" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-family: ProximaNova-Regular;">
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</div>
<div class="" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-family: ProximaNova-Regular;">
<br class="">
</div>
<blockquote class="" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-family: ProximaNova-Regular; margin: 0px 0px 0px 40px; border: none; padding: 0px;">
<div class="">
<div class="">The subdomain location is determined by prefixing the email domain</div>
</div>
<div class="">
<div class="">   with ""webfinger._well_known"".  For example, if the user email is</div>
</div>
<div class="">
<div class="">   ""<a href="mailto:babs@example.com" class="">babs@example.com</a>"", the resulting Webfinger endpoint is</div>
</div>
<div class="">
<div class="">   ""<a href="https://webfinger._well_known.example.com" class="">https://webfinger._well_known.example.com</a>"".</div>
</div>
<div class="">
<div class=""><br class="">
</div>
</div>
<div class="">
<div class="">   Application Providers performing WebFinger discovery MUST first</div>
</div>
<div class="">
<div class="">   attempt to read from the subdomain endpoint.  If the response is not</div>
</div>
<div class="">
<div class="">   an HTTP 200, the Application Provider MUST subsequently attempt</div>
</div>
<div class="">
<div class="">   reading from the traditional WebFinger path at the root domain.  A</div>
</div>
<div class="">
<div class="">   non-normative example is illustrated in Section 4.1.2.1.2.</div>
</div>
</blockquote>
<div class="" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-family: ProximaNova-Regular;">
<br class="">
</div>
<div class="" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-family: ProximaNova-Regular;">
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.</div>
<div class="" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-family: ProximaNova-Regular;">
<br class="">
</div>
<div class="" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-family: ProximaNova-Regular;">
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.</div>
<div class="" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-family: ProximaNova-Regular;">
<br class="">
</div>
<div class="" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-family: ProximaNova-Regular;">
We were looking at <a href="https://tools.ietf.org/html/draft-sanz-openid-dns-discovery-01" class="">https://tools.ietf.org/html/draft-sanz-openid-dns-discovery-01</a> 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 <a href="https://developers.google.com/speed/public-dns/docs/doh/json" class="">https://developers.google.com/speed/public-dns/docs/doh/json</a>).  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.</div>
<div class="" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-family: ProximaNova-Regular;">
<br class="">
</div>
<div class="" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-family: ProximaNova-Regular;">
Is it worth rehashing this topic or has it already reached consensus in the WG?  </div>
<div class="" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-family: ProximaNova-Regular;">
<br class="">
</div>
<div class="" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-family: ProximaNova-Regular;">
-Karl</div>
</body>
</html>