[Openid-specs-fastfed] Preliminary feedback from IIW

[Marcos Sanz]

Hi Darin,

> IdP Discovery
> -------------------------------------
> We ran an IIW session to deep dive on IdP discovery from an email 
address. 
> 
> The attendees confirmed the pain points of hosting WebFinger services 
under the root domain. One participant had previously built 
> dynamic discovery based on domain.

webfinger itself had some issues for us (not just only because running 
under the root domain). The issues we encountered and the way we discover 
IdP via DNS are described here
https://www.ietf.org/archive/id/draft-sanz-openid-dns-discovery-01.txt

Needless to say this solution also enables CNAMEs.

> Many corporate customers were blocked because they were unable to host 
services under the root.
> Solution was a proxy as described below in (3).
> 
> The discussion circled around 3 alternatives:
> 
> (1) Subdomains. 
> 
>    -- Example: Instead of "https://<domain>/.well-known/webfinger" , 
flip it around into "https://webfinger.well-known.<domain>"
>    -- Pros:  Easiest for everyone to implement. Just works for HTTP 
GETs.  Enables CNAMES, which is nice when using 3rd party 
> hosted IdPs and you want to point your domain at the hosted service. 
>    -- Cons:  No well-established patterns for reserved subdomains. More 
difficult to standardize. Subdomains existed in early 
> versions of WebFinger but were cut because of these challenges. 

Reserved domain names or domain names with "special use" have always been 
"problematic" within the IETF, as Mike already said. You could take a look 
at RFC 6761 and 8244 to better understand the mess.

> (2) SRV records
> 
>    -- Example: DNS SRV record for "webfinger.<domain>" that points to 
the location of that service.

Actually "_webfinger.<domain>", dictates RFC 2782

We also looked at SRV records (and NAPTR records, and S-NAPTR..) but ended 
up using TXT because of being more straightahead (that's what e.g. DMARC 
and DKIM also did). Scoping of the TXT record is done according to the 
recommendations of 
https://tools.ietf.org/html/draft-ietf-dnsop-attrleaf-14

>    -- Pros:  There exists a well-established SRV registry.

This is the thing: 
https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml 


It's not just an "SRV registry", but THE service names registry (a 
precursor of which is referenced by the SRV spec).

>    -- Cons: More difficult for application developers to integrate with. 
 Can't make a simple HTTP GET to a URL. SRV require an 
> explicit DNS resolution first. Some environments, like javascript in 
browser, don't allow SRV queries. 

Don't allow for _any_ kind of direct DNS queries. That's the reason why..

> (3) SRV records + Proxy
> 
>    -- Example:  Same as above, but run a proxy. For example: 
"webfinger.org".  Make the WebFinger request to the proxy using a 
> regular HTTP GET. Behind the scenes, proxy resolves the SRV record and 
invokes the authoritative WebFinger server.
>    -- Pros: Preserves the simple experience for developers. Uses 
standard mechanisms like SRV records behind the scenes.
>    -- Cons:  Somebody has to run the proxy.

..we also run a proxy. FWIW

https://lookup.freedom-id.de/lookup/$your_domain_name_here

e.g.

https://lookup.freedom-id.de/lookup/sanz.denic.de

The proxy also performs DNSSEC signature validation and returns that 
information to the client. The JSON returned is proprietary and hasn't 
been specified anywhere, we didn't have a need for that.

Hope that helps.

Best regards,
Marcos