[Openid-specs-fastfed] WebFinger discovery using subdomains

Fri Dec 20 01:55:03 UTC 2019

Hi Matt,

I was thinking that something similar to https://tools.ietf.org/html/draft-sanz-openid-dns-discovery-01<https://tools.ietf.org/html/draft-sanz-openid-dns-discovery-01>  that is DNS based would be defined as an extension to https://openid.net/specs/openid-connect-discovery-1_0.html.   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.

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.

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.

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.

-Karl

On Thu, Dec 19, 2019 at 4:00 AM <openid-specs-fastfed-request at lists.openid.net<mailto:openid-specs-fastfed-request at lists.openid.net>> wrote:
Message: 1
Date: Wed, 18 Dec 2019 20:42:38 +0000
From: Matt Domsch <matt.domsch at sailpoint.com<mailto:matt.domsch at sailpoint.com>>
To: "openid-specs-fastfed at lists.openid.net<mailto:openid-specs-fastfed at lists.openid.net>"
        <openid-specs-fastfed at lists.openid.net<mailto:openid-specs-fastfed at lists.openid.net>>
Subject: Re: [Openid-specs-fastfed] WebFinger discovery using
        subdomains
Message-ID:
        <SN6PR04MB5168A044A14C5E80E18755F9F2530 at SN6PR04MB5168.namprd04.prod.outlook.com<mailto:SN6PR04MB5168A044A14C5E80E18755F9F2530 at SN6PR04MB5168.namprd04.prod.outlook.com>>

Content-Type: text/plain; charset="utf-8"

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. discovery-it at example.com<mailto:discovery-it at example.com><mailto:discovery-it at example.com<mailto:discovery-it at example.com>> and discovery at example.com<mailto:discovery at example.com><mailto:discovery at example.com<mailto:discovery at example.com>> when multiple IDPs are in use for subsets of the population.

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.

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.

Thanks,
Matt

Matt Domsch
VP, Lead Corporate Architect
matt.domsch at sailpoint.com<mailto:matt.domsch at sailpoint.com><mailto:matt.domsch at sailpoint.com<mailto:matt.domsch at sailpoint.com>>
mobile: 512-981-6486
www.sailpoint.com<http://www.sailpoint.com><http://www.sailpoint.com/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-fastfed/attachments/20191220/d88f537c/attachment.html>