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

I agree this change makes sense. It is so easy to get domain names and certs and SNI is so widely adopted that I do not see many arguments against this. 

> On Apr 9, 2019, at 11:59 AM, Ted Hardie <ted.ietf@gmail.com> 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?
> 
> regards,
> 
> Ted
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb