Re: [rtcweb] Security-arch IdP determination issue/DISCUSS

["Martin Thomson" <[e-mail]>]

On Wed, Apr 10, 2019, at 04:00, Ted Hardie wrote:
> In section 7.5 of the Security-arch draft, the document says:
> 
> Authority:  The authority [RFC3986 
> <https://tools.ietf.org/html/rfc3986>] at which the IdP's service is
>       hosted.  Note that this may include a non-default port or a
>       userinfo component, but neither will be available in a certificate
>       verifying the site.
> 
> Benjamin Kaduk raised a DISCUSS on this:
> > I'm a bit unclear about how the port in the 
> > IdP URI's Authority (Section 7.5) would get 
> > discovered. If it can be remotely supplied, 
> > there may be risks in just trusting blindly 
> > whatever value is received.
> 
> Given that we discover this via a .well-known location which is meant 
> to be deterministic, I went looking for the more general .well-known 
> advice on this topic. Turns out that the updated version in 578bis 
> <https://tools.ietf.org/html/draft-nottingham-rfc5785bis-09#page-2> has 
> this:
> 
> > Typically, applications will use the default port 
> > for the given scheme; if an alternative port is 
> > used, it MUST be explicitly specified by the 
> > application in question.
> 
> Obviously, our doc predates 5785bis, but given the discuss and that 
> advice, I think the right thing to do here is to drop the ability to 
> have a non-default port or to specify an alternate port.
> 
> Is there anyone currently using this with a non-default port?
> 
> Any objections to dropping this or preferences for specifying an alternate port?

I hope that this also includes dropping the userinfo part, so that this is just the host portion (https://tools.ietf.org/html/rfc3986#section-3.2.2).

Firefox does support the port number, but I'm not aware of anyone using it.  As Cullen points out, getting a unique name is not the biggest barrier to deployment.  You might even argue that there is a security benefit in that arbitrary ports can be used to assert identities.