We Need a Working IdP Discovery Mechanism (for RISC, Fast Fed, and more)

We Need A Working IdP Discovery Mechanism (for Rise, Fast Fed, and More)

Day/Session:Tuesday 4C

Convener:Darin McAdams

Notes-taker(s): Darin McAdams

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

The attendees confirmed the pain points of hosting WebFinger services under the root domain. One participant had previously built dynamic discovery based on domain. 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. 

(2) SRV records 

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

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

-- 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.  

(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.  

Finally, there was discussion about whether WebFinger was truly necessary here, as opposed to simple static configuration at an endpoint. WebFinger is necessary if multiple IdPs are used for a single domain. (WebFinger allows discovery of the specific IdP for a username in that domain.)  There was mixed feedback from the room.