[Openid-specs-fastfed] WebFinger discovery using subdomain

Jared Hanson jaredhanson at gmail.com
Tue Nov 10 00:19:24 UTC 2020


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
    &rel=http%3A%2F%2Fopenid.net%2Fspecs%2Ffastfed%2F1.0%2Fprovider
    HTTP/1.1
Host: fastfed._well_known.example.com

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

{
  "subject": "acct:jane 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` and `
jack at example.com`?  Or is it based on the domain `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/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> 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” is a CNAME for “
> 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”, 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”.
>
>
>
>
>
>
>
> *From: *Openid-specs-fastfed <
> openid-specs-fastfed-bounces at lists.openid.net> on behalf of
> Openid-specs-fastfed <openid-specs-fastfed at lists.openid.net>
> *Reply-To: *Jared Hanson <jaredhanson at gmail.com>
> *Date: *Friday, October 30, 2020 at 6:08 PM
> *To: *Openid-specs-fastfed <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"
>
> 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/20201109/cfe6fffe/attachment.html>


More information about the Openid-specs-fastfed mailing list