<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;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle18
{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">
<div class="WordSection1">
<p class="MsoNormal">>> FastFed is not following the pattern of just publishing a .well-known discovery resource... The discovery flow would have been the same as OIDC; find the issuer for the email, then fetch the {issuer}/.well-known/fastfed-metadata resource.
The only reason I can think of why this pattern wasn’t chosen was to enable the OpenID issuer to be a different host than FastFed metadata...<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">It was actually a bit different. To illustrate, consider our email addresses. Mine ends with “@amazon.com”. Erik’s is “@google.com”. Adhering to the prior pattern would necessitate hosting files at “https://amazon.com/.well-known/...” or
“https://google.com/.well-known/...”.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Those are customer-facing website properties, run by product engineering teams. They are not generally accessible by internal enterprise IT. Therefore, asking for workforce discovery metadata to be hosted from the core public properties
is a hefty organizational friction, regardless of whether the purpose is for OIDC or FastFed or whatever. It crosses trust boundaries we generally don’t want to cross, and requires access that people don’t have.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">We believe this is not unusual in large enterprise environments, causing the classic “.well-known” approach to be a non-starter for enterprise SSO.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">In contrast, enterprises find subdomains easier. It’s not unusual for enterprises to create subdomains (and DNS zones) which are delegated to portions of the enterprise.
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Agree that DNS TXT records would be easiest, hosted at a subdomain. Absent that, the next easiest would be hosting a static file. For Amazon, that means we’d simply drop a file in S3, for example. To enable that, it would be nice to specify
a location such as “https://fastfed._well-known.amazon.com” which can simply point to the S3 file.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">The use of WebFinger protocols in the FastFed spec has remained because, in very limited circumstances, some enterprises wish to vary the answers for different users under a single email domain. A full-fledged WebFinger server enables that
flexibility. However, since I suspect most don’t need it, it would be ideal to allow a simpler-to-implement mechanism for enterprises.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Personally, I like the approach of “https://{resource}._well-known.{issuer}/”. It’s simply an inversion of the OIDC approach, using subdomains instead of paths. We anticipated pushback from IETF-land, but since no other shovel-ready approach
was identified, the outcome of the IIW discussion was to ask forgiveness instead of permission. It’s something I’m toying with while revising the spec with latest feedback.<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>Karl McGuinness <kmcguinness@okta.com><br>
<b>Date: </b>Thursday, December 19, 2019 at 5:56 PM<br>
<b>To: </b>Openid-specs-fastfed <openid-specs-fastfed@lists.openid.net><br>
<b>Subject: </b>Re: [Openid-specs-fastfed] WebFinger discovery using subdomains<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">Hi Matt, <o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I was thinking that something similar to <a href="https://tools.ietf.org/html/draft-sanz-openid-dns-discovery-01">https://tools.ietf.org/html/draft-sanz-openid-dns-discovery-01</a> that is DNS based would be defined as an extension to <a href="https://openid.net/specs/openid-connect-discovery-1_0.html">https://openid.net/specs/openid-connect-discovery-1_0.html</a>.
Each service that supports discovery in OIDF such as FastFed would register its URI (rel) in a common OIDF managed registry. This would enable the service to be discoverable via DNS or HTTP API.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">If we expect each OIDF service to be owned/hosted by different administrators, then having a DNS record per service has advantages. If we expect the majority use case to be the same administrator then there is simplicity in having just
one TXT record with a tag for each service. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I would have expected that in most deployments the FastFed metadata provider is the same host as the OpenID provider (issuer). FastFed endpoints defined in the metadata could always be different. This must not be the case as FastFed is
not following the pattern of just publishing a .well-known discovery resource like OpenID, RISC, etc off the issuer. The discovery flow would have been the the same as OIDC; find the issuer for the email, then fetch the {issuer}/.well-known/fastfed-metadata
resource. The only reason I can think of why this pattern wasn’t chosen was to enable the OpenID issuer to be a different host than FastFed metadata such as common issuer but tenant-specific fastfed metadata. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I agree with you on the DNSSEC requirement, it will prevent adoption due to deployment friction. This may be a deal breaker itself as without integrity of DNS its possible for an attacker to mix-up the FastFed host returned via DNS and
attempt to have the administrator federate the service with their provider. Not sure how this will play out in practice as having folks copy/paste or click URLs in docs/emails to bootstrap FastFed flows has its own problems. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">-Karl<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Thu, Dec 19, 2019 at 4:00 AM <<a href="mailto:openid-specs-fastfed-request@lists.openid.net">openid-specs-fastfed-request@lists.openid.net</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal">Message: 1<br>
Date: Wed, 18 Dec 2019 20:42:38 +0000<br>
From: Matt Domsch <<a href="mailto:matt.domsch@sailpoint.com" target="_blank">matt.domsch@sailpoint.com</a>><br>
To: "<a href="mailto:openid-specs-fastfed@lists.openid.net" target="_blank">openid-specs-fastfed@lists.openid.net</a>"<br>
<<a href="mailto:openid-specs-fastfed@lists.openid.net" target="_blank">openid-specs-fastfed@lists.openid.net</a>><br>
Subject: Re: [Openid-specs-fastfed] WebFinger discovery using<br>
subdomains<br>
Message-ID:<br>
<<a href="mailto:SN6PR04MB5168A044A14C5E80E18755F9F2530@SN6PR04MB5168.namprd04.prod.outlook.com" target="_blank">SN6PR04MB5168A044A14C5E80E18755F9F2530@SN6PR04MB5168.namprd04.prod.outlook.com</a>><br>
<br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
I certainly think that discovery via a well-known DNS entry is simplest for most organizations with the common config of having a single IDP for a single domain name. Sanz does allow for records to be scoped by email address as well, should that need arise,
though I?d consider it DNS pollution to have to put all email addresses into DNS for this discovery purpose when few would in practice be used. Maybe a BCP specifies an email address to be used for such discovery (e.g.
<a href="mailto:discovery-it@example.com" target="_blank">discovery-it@example.com</a><mailto:<a href="mailto:discovery-it@example.com" target="_blank">discovery-it@example.com</a>> and
<a href="mailto:discovery@example.com" target="_blank">discovery@example.com</a><mailto:<a href="mailto:discovery@example.com" target="_blank">discovery@example.com</a>> when multiple IDPs are in use for subsets of the population.<br>
<br>
Karl, would you expect to add a new tag=value pair the _openid TXT record specified in Sanz, or create a new _fastfed TXT record, similar to but separate from _openid? Given that FastFed uses, but it separate from, OIDC, SAML, and SCIM, I?d think the latter
would be most appropriate, and would require the least coordination with other WGs and standards bodies.<br>
<br>
My only concern with DNS comes from Sanz section 5, which requires DNSSEC to be valid. In practice this is still not widely-enough used.<br>
<br>
Thanks,<br>
Matt<br>
<br>
Matt Domsch<br>
VP, Lead Corporate Architect<br>
<a href="mailto:matt.domsch@sailpoint.com" target="_blank">matt.domsch@sailpoint.com</a><mailto:<a href="mailto:matt.domsch@sailpoint.com" target="_blank">matt.domsch@sailpoint.com</a>><br>
mobile: 512-981-6486<br>
<a href="http://www.sailpoint.com" target="_blank">www.sailpoint.com</a><<a href="http://www.sailpoint.com/" target="_blank">http://www.sailpoint.com/</a>><o:p></o:p></p>
</blockquote>
</div>
</div>
</div>
</div>
</body>
</html>