<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="">
Thanks Dick and Darin for refreshing my memory.
<div class=""><br class="">
</div>
<div class="">I agree that the OIDC issuer URI doesn’t neatly align with the user identifier suffix in practice. I support an alternative strategy for discovery. </div>
<div class=""><br class="">
</div>
<div class="">What I was after was a mechanism that didn’t require organizations to host a HTTPS endpoint and could just use DNS exclusively. Dropping a file in a S3 bucket unfortunately is foreign to folks still. My assumption was IT orgs today already need
to manage MX records for their email addresses in DNS. A great majority of folks use SaaS for their email and delegate to MS/Google/etc and also use additional email security gateways that need MX routing. They have a process to publish/manage these DNS
records even if an engineering org owns the DNS namespace and/or infrastructure. </div>
<div class=""><br class="">
</div>
<div class="">Supporting a DNS-based mechanism was appealing as it required no additional infrastructure, leveraged existing processes, and aligned with how they manage records for their user identifier suffixes.</div>
<div class=""><br class="">
</div>
<div class="">I do agree that if a DNS based approaches requires DNSSEC for security, then HTTPS is less friction.</div>
<div class=""><br class="">
</div>
<div class="">Whatever discovery mechanism we align on, my suggestion is that it should probably live outside of fastfed spec so it can be leveraged by any OIDF protocol including OIDC for issuer discovery as an alternative to the current WebFinger spec (which
is what I was originally after)</div>
<div class=""><br class="">
</div>
<div class="">Thanks,</div>
<div class="">Karl</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
<div class="">
<div><br class="">
<blockquote type="cite" class="">
<div class="">On Jan 14, 2020, at 10:41 AM, Dick Hardt <<a href="mailto:dick.hardt@gmail.com" class="">dick.hardt@gmail.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div dir="ltr" class="">
<div dir="ltr" class="">
<div dir="ltr" class="">
<div dir="ltr" class="">
<div dir="ltr" class="">
<div class="mc-ip-hide">
<div style="font-size: 12px; text-align: left; font-family: Helvetica, Arial, sans-serif;" class="">
<strong class="">This message originated outside your organization.</strong><br class="">
</div>
<hr class="">
</div>
Darin: I think your suggestion is the best approach, given where the world is.<br class="">
</div>
<div dir="ltr" class=""><br class="">
</div>
<div dir="ltr" class="">Karl: as I am sure you know, the OIDC methodology has not enabled easy discovery. The OIDC issuer in practice has not been discoverable. Google's issuer is
<a href="https://accounts.google.com" class="">
https://accounts.google.com</a> and discovery is at at <a href="https://accounts.google.com/.well-known/" class="">https://accounts.google.com/.well-known/</a> -- it is not obvious that a
<a href="http://google.com" class="">
google.com</a> email address would have an issuer at <a href="https://accounts.google.com" class="">
https://accounts.google.com</a></div>
<div dir="ltr" class=""><br class="">
</div>
<div class="">Microsoft discovery documents are even more confusing:</div>
<div class=""><br class="">
</div>
<div dir="ltr" class=""><a href="https://login.microsoftonline.com/{tenant}/v2.0/.well-known/openid-configuration" class="">https://login.microsoftonline.com/{tenant}/v2.0/.well-known/openid-configuration</a></div>
<div dir="ltr" class=""><br class="">
</div>
<div class="">It would appear that the https://{provider}/.well_known pattern has not been adopted, and that metadata documents are off of a different subdomain.</div>
<div class=""><br class="">
</div>
<div dir="ltr" class="">Since using a subdomain is clearly what the industry wants to use, a standardized subdomain mechanism will allow automatic discovery. An advantage of DNS is that a hostname can point to another hosthame, allowing an organization to delegate
the management of the contents to a service provider. <br class="">
</div>
<div class=""><br class="">
</div>
<div class="">While IETF may be cranky, the current model for discovery is not working. </div>
<div dir="ltr" class="">
<div class=""><br class="">
</div>
</div>
</div>
</div>
</div>
</div>
<br class="">
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Mon, Jan 13, 2020 at 11:58 PM McAdams, Darin via Openid-specs-fastfed <<a href="mailto:openid-specs-fastfed@lists.openid.net" class="">openid-specs-fastfed@lists.openid.net</a>> wrote:<br class="">
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div lang="EN-US" class="">
<div class="gmail-m_7153589813149038811WordSection1">
<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...<u class=""></u><u class=""></u></p>
<p class="MsoNormal"><u class=""></u> <u class=""></u></p>
<p class="MsoNormal">It was actually a bit different. To illustrate, consider our email addresses. Mine ends with “@<a href="http://amazon.com" target="_blank" class="">amazon.com</a>”. Erik’s is “@<a href="http://google.com" target="_blank" class="">google.com</a>”.
Adhering to the prior pattern would necessitate hosting files at “<a href="https://amazon.com/.well-known/..." target="_blank" class="">https://amazon.com/.well-known/...</a>” or “<a href="https://google.com/.well-known/..." target="_blank" class="">https://google.com/.well-known/...</a>”.<u class=""></u><u class=""></u></p>
<p class="MsoNormal"><u class=""></u> <u class=""></u></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.<u class=""></u><u class=""></u></p>
<p class="MsoNormal"><u class=""></u> <u class=""></u></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.<u class=""></u><u class=""></u></p>
<p class="MsoNormal"><u class=""></u> <u class=""></u></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.
<u class=""></u><u class=""></u></p>
<p class="MsoNormal"><u class=""></u> <u class=""></u></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 “<a href="https://fastfed./" target="_blank" class="">https://fastfed.</a>_<a href="http://well-known.amazon.com" target="_blank" class="">well-known.amazon.com</a>” which can simply
point to the S3 file.<u class=""></u><u class=""></u></p>
<p class="MsoNormal"><u class=""></u> <u class=""></u></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.<u class=""></u><u class=""></u></p>
<p class="MsoNormal"><u class=""></u> <u class=""></u></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.<u class=""></u><u class=""></u></p>
<p class="MsoNormal"><u class=""></u> <u class=""></u></p>
<div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(181,196,223);padding:3pt 0in 0in" class="">
<p class="MsoNormal"><b class=""><span style="font-size: 12pt;" class="">From: </span>
</b><span style="font-size: 12pt;" class="">Openid-specs-fastfed <<a href="mailto:openid-specs-fastfed-bounces@lists.openid.net" target="_blank" class="">openid-specs-fastfed-bounces@lists.openid.net</a>> on behalf of Openid-specs-fastfed <<a href="mailto:openid-specs-fastfed@lists.openid.net" target="_blank" class="">openid-specs-fastfed@lists.openid.net</a>><br class="">
<b class="">Reply-To: </b>Karl McGuinness <<a href="mailto:kmcguinness@okta.com" target="_blank" class="">kmcguinness@okta.com</a>><br class="">
<b class="">Date: </b>Thursday, December 19, 2019 at 5:56 PM<br class="">
<b class="">To: </b>Openid-specs-fastfed <<a href="mailto:openid-specs-fastfed@lists.openid.net" target="_blank" class="">openid-specs-fastfed@lists.openid.net</a>><br class="">
<b class="">Subject: </b>Re: [Openid-specs-fastfed] WebFinger discovery using subdomains<u class=""></u><u class=""></u></span></p>
</div>
<div class="">
<p class="MsoNormal"><u class=""></u> <u class=""></u></p>
</div>
<p class="MsoNormal">Hi Matt, <u class=""></u><u class=""></u></p>
<div class="">
<p class="MsoNormal"><u class=""></u> <u class=""></u></p>
</div>
<div class="">
<p class="MsoNormal">I was thinking that something similar to <a href="https://tools.ietf.org/html/draft-sanz-openid-dns-discovery-01" target="_blank" class="">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" target="_blank" class="">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.<u class=""></u><u class=""></u></p>
</div>
<div class="">
<p class="MsoNormal"><u class=""></u> <u class=""></u></p>
</div>
<div class="">
<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. <u class=""></u><u class=""></u></p>
</div>
<div class="">
<p class="MsoNormal"><u class=""></u> <u class=""></u></p>
</div>
<div class="">
<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. <u class=""></u><u class=""></u></p>
</div>
<div class="">
<p class="MsoNormal"><u class=""></u> <u class=""></u></p>
</div>
<div class="">
<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. <u class=""></u><u class=""></u></p>
</div>
<div class="">
<p class="MsoNormal"><u class=""></u> <u class=""></u></p>
</div>
<div class="">
<p class="MsoNormal">-Karl<u class=""></u><u class=""></u></p>
</div>
<div class="">
<p class="MsoNormal"><u class=""></u> <u class=""></u></p>
</div>
<div class="">
<div class="">
<p class="MsoNormal"><u class=""></u> <u class=""></u></p>
<div class="">
<div class="">
<p class="MsoNormal">On Thu, Dec 19, 2019 at 4:00 AM <<a href="mailto:openid-specs-fastfed-request@lists.openid.net" target="_blank" class="">openid-specs-fastfed-request@lists.openid.net</a>> wrote:<u class=""></u><u class=""></u></p>
</div>
<blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in" class="">
<p class="MsoNormal">Message: 1<br class="">
Date: Wed, 18 Dec 2019 20:42:38 +0000<br class="">
From: Matt Domsch <<a href="mailto:matt.domsch@sailpoint.com" target="_blank" class="">matt.domsch@sailpoint.com</a>><br class="">
To: "<a href="mailto:openid-specs-fastfed@lists.openid.net" target="_blank" class="">openid-specs-fastfed@lists.openid.net</a>"<br class="">
<<a href="mailto:openid-specs-fastfed@lists.openid.net" target="_blank" class="">openid-specs-fastfed@lists.openid.net</a>><br class="">
Subject: Re: [Openid-specs-fastfed] WebFinger discovery using<br class="">
subdomains<br class="">
Message-ID:<br class="">
<<a href="mailto:SN6PR04MB5168A044A14C5E80E18755F9F2530@SN6PR04MB5168.namprd04.prod.outlook.com" target="_blank" class="">SN6PR04MB5168A044A14C5E80E18755F9F2530@SN6PR04MB5168.namprd04.prod.outlook.com</a>><br class="">
<br class="">
Content-Type: text/plain; charset="utf-8"<br class="">
<br class="">
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" class="">discovery-it@example.com</a><mailto:<a href="mailto:discovery-it@example.com" target="_blank" class="">discovery-it@example.com</a>> and
<a href="mailto:discovery@example.com" target="_blank" class="">discovery@example.com</a><mailto:<a href="mailto:discovery@example.com" target="_blank" class="">discovery@example.com</a>> when multiple IDPs are in use for subsets of the population.<br class="">
<br class="">
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 class="">
<br class="">
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 class="">
<br class="">
Thanks,<br class="">
Matt<br class="">
<br class="">
Matt Domsch<br class="">
VP, Lead Corporate Architect<br class="">
<a href="mailto:matt.domsch@sailpoint.com" target="_blank" class="">matt.domsch@sailpoint.com</a><mailto:<a href="mailto:matt.domsch@sailpoint.com" target="_blank" class="">matt.domsch@sailpoint.com</a>><br class="">
mobile: 512-981-6486<br class="">
<a href="http://www.sailpoint.com" target="_blank" class="">www.sailpoint.com</a><<a href="http://www.sailpoint.com/" target="_blank" class="">http://www.sailpoint.com/</a>><u class=""></u><u class=""></u></p>
</blockquote>
</div>
</div>
</div>
</div>
</div>
_______________________________________________<br class="">
Openid-specs-fastfed mailing list<br class="">
<a href="mailto:Openid-specs-fastfed@lists.openid.net" target="_blank" class="">Openid-specs-fastfed@lists.openid.net</a><br class="">
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-fastfed" rel="noreferrer" target="_blank" class="">http://lists.openid.net/mailman/listinfo/openid-specs-fastfed</a><br class="">
</blockquote>
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</div>
</body>
</html>