<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Verdana;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
span.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style>
</head>
<body lang="EN-US" link="blue" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal">Thanks for the feedback. Heads-up that we just published V3, though the only material changes were to the SAML Profile.<o:p></o:p></p>
<p class="MsoNormal"><a href="https://openid.net/2020/10/29/second-public-review-period-for-three-proposed-fastfed-implementers-drafts/">https://openid.net/2020/10/29/second-public-review-period-for-three-proposed-fastfed-implementers-drafts/</a><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">#1 makes sense, and we probably would have run into that during implementation. Can raise at the next WG meeting.
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">#2 has a couple reasons behind it. One is that we predict most organizations will use a 3<sup>rd</sup> party Identity Provider who is also hosting the FastFed WebFinger endpoint for them. Therefore, we wanted to make it possible for an
organization to create a CNAME for their FastFed WebFinger endpoint that aliases to the 3<sup>rd</sup> party, but _<i>only</i>_ for the FastFed queries. WebFinger lookups for other resource types should be servable by other providers. This lends itself to
the subdomain approach.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">For example: “fastfed.web-finger.my-company.com” is a CNAME for “tenant-12345.fastfed.web-finger.identity-provider.com”<o:p></o:p></p>
<p class="MsoNormal"><o:p></o:p></p>
<p class="MsoNormal">Even if an organization decides to host it’s WebFinger functionality in-house, we still see value in the subdomain. For example, as organizations grow large, the goals of agility and security trend toward giving individual departments the
ability to own their slice of stuff, without getting tangled up with other parts of the organization. An easy way to achieve this is via subdomains. In this example, the team managing the FastFed settings would get ownership over the DNS settings for “fastfed.web-finger.example.com”,
and that’s all they get to control. <span style="font-size:10.0pt;font-family:"Verdana",sans-serif;color:black">
<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Lastly, one of the nice things about this approach is that if somebody did want to host a consolidate WebFinger server for all their resources, nothing precludes that. They’d just need a wildcard DNS entry for “*.webfinger.example.com”.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:12.0pt;color:black">From: </span></b><span style="font-size:12.0pt;color:black">Openid-specs-fastfed <openid-specs-fastfed-bounces@lists.openid.net> on behalf of Openid-specs-fastfed <openid-specs-fastfed@lists.openid.net><br>
<b>Reply-To: </b>Jared Hanson <jaredhanson@gmail.com><br>
<b>Date: </b>Friday, October 30, 2020 at 6:08 PM<br>
<b>To: </b>Openid-specs-fastfed <openid-specs-fastfed@lists.openid.net><br>
<b>Subject: </b>[EXTERNAL] [Openid-specs-fastfed] WebFinger discovery using subdomain<o:p></o:p></span></p>
</div>
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">The latest draft (02) of FastFed Core includes a mechanism for discovery that uses the "fastfed._well_known" subdomain, resulting in requests to URLs such as "<a href="https://fastfed.">https://fastfed.</a>_<a href="http://well_known.example.com">well_known.example.com</a>"<br>
<br>
I am a proponent of moving in this direction, as I'd like to see a mechanism for discovery that is both operationally easy to delegate as well as secure.<br>
<br>
There are a couple issues that need addressing in the current draft:<br>
<br>
1. The CA Browser Forum no longer allows issuing TLS certificates to domain names containing underscores. Details here:
<a href="https://blog.entrust.com/2019/01/removal-of-underscores-from-domain-names/">
https://blog.entrust.com/2019/01/removal-of-underscores-from-domain-names/</a><br>
<br>
I assume the intent of using underscores was to align with RFC8552. However, the use of underscores in that specification, alongside generalized DNS resource records (TXT, SRV, URL), does not require use of HTTPS (and associated certificates). Due to the
fact that this mechanism does require HTTPS, I believe we should be using domain names that are valid hostnames. That implies we need to not use underscores.<br>
<br>
I suggest we use "well-known" as the subdomain. If anyone knows of issues that would prevent that, please let the group know.<br>
<br>
2. I'm unclear on why "fastfed._well_known" is being used as a way to locate the<br>
WebFinger endpoint. Why not use "webfinger._well_known"?<br>
<br>
The later would be more general purpose, and would allow other applications (such as OIDC) to make use of the same mechanism. It'd be nice to align the work being done here so that the discovery mechanism is reusable by other protocols.<br>
<br>
Regarding this, I am working on pulling this capability out into its own draft specification, so that other protocols can take advantage of it. For anyone who<br>
wants to assist or comment, that draft is currently here:<br>
<a href="https://github.com/jaredhanson/draft-well-known-dns-subdomain/blob/master/spec.txt">https://github.com/jaredhanson/draft-well-known-dns-subdomain/blob/master/spec.txt</a><br>
<br>
Thanks,<br>
Jared Hanson<br clear="all">
<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">-- <o:p></o:p></p>
<div>
<p class="MsoNormal">Jared Hanson <<a href="http://jaredhanson.net/" target="_blank">http://jaredhanson.net/</a>><o:p></o:p></p>
</div>
</div>
</div>
</div>
</body>
</html>