[Openid-specs-fastfed] WebFinger discovery using subdomain

Tue Nov 10 00:53:23 UTC 2020

The reason it doesn’t simply return the FastFed metadata is because the WebFinger query response can be a list. In an enterprise setting, it’s not unusual for an organization to use multiple Identity Providers. For example, one provider is chosen for SCIM provisioning and another for SAML SSO. The intent is for the app to get the full list, check the metadata of each to verify compatibility, and display the list (including whether the provider is usable for authentication, provisioning, or both).
It is also possible, although rarer in practice, to return different WebFinger answers for different users sharing the same email domain.

From: Jared Hanson <jaredhanson at gmail.com>
Date: Monday, November 9, 2020 at 4:20 PM
To: "McAdams, Darin" <darinm at amazon.com>, Openid-specs-fastfed <openid-specs-fastfed at lists.openid.net>
Subject: RE: [EXTERNAL] [Openid-specs-fastfed] WebFinger discovery using subdomain

Thanks for detailing the rationale on my second question.

Based on my experiences prototyping FastFed, as well as implementing discovery, I've got some feedback and recommendations to consider.

WebFinger, to me, makes a lot of sense especially for discovery related to end-user services, which may be handled by a variety of different providers (hence both the `resource` and `rel` parameters).  The real value of WebFinger, as a hosted service, is only realized when each user can point their own link relations at a service of their choosing.  I personally wish this approach had more market traction.

That said, let's look at the current proposed FastFed discovery mechanism:

```
GET /
    ?resource=acct%3Ajane%40example.com<http://40example.com>
    &rel=http%3A%2F%2Fopenid.net%2Fspecs%2Ffastfed%2F1.0%2Fprovider
    HTTP/1.1
Host: fastfed._well_known.example.com<http://well_known.example.com>

HTTP/1.1 200 OK
Content-Type: application/jrd+json

{
  "subject": "acct:jane at example.com<mailto:acct%3Ajane at example.com>",
  "links": [ {
    "rel": "http://openid.net/specs/fastfed/1.0/provider",
    "href": "https://tenant-12345.idp.example.com/fastfed"
  } ]
}
```

A couple of things stand out:
1. The `rel` parameter is duplicative with the host header.  (`fastfed` appears in both)
2. Does the host need to vary its response to `jane at example.com<mailto:jane at example.com>` and `jack at example.com<mailto:jack at example.com>`?  Or is it based on the domain `example.com<http://example.com>`, which is also duplicative with the host header.

Given the above, WebFinger seems like a layer of indirection that isn't adding value.  Implementations would be simplified if the discovery endpoint just returned the FastFed provider metadata directly.  For example:

```
GET / HTTP/1.1
Host: fastfed.well-known.example.com<http://fastfed.well-known.example.com>

HTTP/1.1 200 OK
Content-Type: application/json

{
  "identity_provider": {
    "entity_id": "https://tenant-12345.idp.example.com/",
    "fastfed_handshake_start_uri": "https://tenant-12345.idp.example.com/fastfed/start"
    ...
  }
}
```

If varying the response is needed based on email addresses, then `resource` could be preserved as a parameter, while still returning the FastFed metadata directly.

Thoughts?

On Mon, Nov 2, 2020 at 4:56 PM McAdams, Darin <darinm at amazon.com<mailto:darinm at amazon.com>> wrote:
Thanks for the feedback. Heads-up that we just published V3, though the only material changes were to the SAML Profile.
https://openid.net/2020/10/29/second-public-review-period-for-three-proposed-fastfed-implementers-drafts/

#1 makes sense, and we probably would have run into that during implementation. Can raise at the next WG meeting.

#2 has a couple reasons behind it. One is that we predict most organizations will use a 3rd 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 3rd party, but _only_ for the FastFed queries. WebFinger lookups for other resource types should be servable by other providers. This lends itself to the subdomain approach.

For example:  “fastfed.web-finger.my-company.com<http://fastfed.web-finger.my-company.com>” is a CNAME for “tenant-12345.fastfed.web-finger.identity-provider.com<http://tenant-12345.fastfed.web-finger.identity-provider.com>”
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<http://fastfed.web-finger.example.com>”, and that’s all they get to control.

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<http://webfinger.example.com>”.

From: Openid-specs-fastfed <openid-specs-fastfed-bounces at lists.openid.net<mailto:openid-specs-fastfed-bounces at lists.openid.net>> on behalf of Openid-specs-fastfed <openid-specs-fastfed at lists.openid.net<mailto:openid-specs-fastfed at lists.openid.net>>
Reply-To: Jared Hanson <jaredhanson at gmail.com<mailto:jaredhanson at gmail.com>>
Date: Friday, October 30, 2020 at 6:08 PM
To: Openid-specs-fastfed <openid-specs-fastfed at lists.openid.net<mailto:openid-specs-fastfed at lists.openid.net>>
Subject: [EXTERNAL] [Openid-specs-fastfed] WebFinger discovery using subdomain

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 "https://fastfed._well_known.example.com<http://well_known.example.com>"

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.

There are a couple issues that need addressing in the current draft:

1. The CA Browser Forum no longer allows issuing TLS certificates to domain names containing underscores.  Details here: https://blog.entrust.com/2019/01/removal-of-underscores-from-domain-names/

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.

I suggest we use "well-known" as the subdomain.  If anyone knows of issues that would prevent that, please let the group know.

2. I'm unclear on why "fastfed._well_known" is being used as a way to locate the
WebFinger endpoint.  Why not use "webfinger._well_known"?

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.

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
wants to assist or comment, that draft is currently here:
https://github.com/jaredhanson/draft-well-known-dns-subdomain/blob/master/spec.txt

Thanks,
Jared Hanson

--
Jared Hanson <http://jaredhanson.net/>

--
Jared Hanson <http://jaredhanson.net/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-fastfed/attachments/20201110/5540455d/attachment-0001.html>