<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
Hi Matt,
<div class=""><br class="">
</div>
<div class="">I was thinking that something similar to <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> that is DNS based would be defined as
an extension to <a href="https://openid.net/specs/openid-connect-discovery-1_0.html" 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.</div>
<div class=""><br class="">
</div>
<div class="">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. </div>
<div class=""><br class="">
</div>
<div class="">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. </div>
<div class=""><br class="">
</div>
<div class="">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. </div>
<div class=""><br class="">
</div>
<div class="">-Karl</div>
<div class=""><br class="">
</div>
<div class="">
<div class=""><br class="">
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Thu, Dec 19, 2019 at 4:00 AM <<a href="mailto:openid-specs-fastfed-request@lists.openid.net" class="">openid-specs-fastfed-request@lists.openid.net</a>> wrote:</div>
<blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
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.op<wbr class="">enid.net</a>"<br class="">
<<a href="mailto:openid-specs-fastfed@lists.openid.net" target="_blank" class="">openid-specs-fastfed@lists.op<wbr class="">enid.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="">SN6PR04MB5168A044A14C5E80E187<wbr class="">55F9F2530@SN6PR04MB5168.namprd<wbr class="">04.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><mailt<wbr class="">o:<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="">d<wbr class="">iscovery@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><mail<wbr class="">to:<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" rel="noreferrer" target="_blank" class="">www.sailpoint.com</a><<a href="http://www.sailpoint.com/" rel="noreferrer" target="_blank" class="">http://www.s<wbr class="">ailpoint.com/</a>></blockquote>
</div>
</div>
</div>
</body>
</html>