Evolve domain validation mechansims

[ghalse]

The advent of the GDPR caused many DNS Registries around the world to redact personal information from WHOIS. This makes validating the right to use a DNS domain using the mechanisms defined in the existing template nearly impossible except in the situation where a federation operator also happens to be the registry operator or otherwise has a back channel.

In addition, we've seen a shift toward the use of shared, multi-tenanted cloud providers using their own domains in entityIDs. This makes validation of the right to use a particular entityID more nuanced that can be reflected in DNS alone.

Thus we need to evolve the template's mechanisms for validating the right to use an entityID and the right to use a domain for things like scopes. In the latter case, we can look at how other organisations are validating the right-to-use of a domain and establish similar domain control validation mechanisms.

This pull request proposes changes that give effect to such mechanisms. It will be shared with the refeds@lists.refeds.org mailing list for further discussion.

[paxus42]

We should remove the URN alternative from the basic MDRPS template. That means that line 103, 120 and 131 should be removed altogether.

If we decide to keep the URN alternative, I'm happy with the changes.

[paxus42]

In line with my comments later suggested change. If we decide to remove URN in the template line 193 should be removed. Otherwise, I'm happy with the suggested change.

[paxus42]

Under section 5.2 the changes names Tenant but that is a very vendor specific name. We should strive to use a more general name. Othe than that I think that this change is good.

I wonder that in section 5.5 there is also a simpler way to establish ownership of domain when the organization uses it as their main organization domain name, i.e. used for the organization official web site. We hhall not make to much bureaucracy if we don't need to. Otherwise ok.

[ghalse]

Under section 5.2 the changes names Tenant but that is a very vendor specific name. We should strive to use a more general name. Othe than that I think that this change is good.

Was tenant in the sense of multi-tenanted systems, which I thought was relatively generic. Is the problem that it is capitalised?

What about changing line 123 to say "In the case of a multi-tenanted, third-party, or ..." to emphasise that interpretation?

I wonder that in section 5.5 there is also a simpler way to establish ownership of domain when the organization uses it as their main organization domain name, i.e. used for the organization official web site. We hhall not make to much bureaucracy if we don't need to. Otherwise ok.

We'd have to be careful about public suffixes and subdomains. But otherwise, I think this might not be a bad idea. What about:

• A Member uses a domain name delegated by a public DNS registry as their primary domain for email and/or (optionally prefixed with "www.") their official website.

[paxus42]

I like both of your suggested changes.

[alexstuart]

The pull request will allow DCV through a variety of mechanisms. There are about 20 in version 1.8.7 of the CA/Browser forum baseline requirements, including 3.2.2.5.4 "Any other method", so that's already a lot of choice for the registrant.

A Member uses a domain name delegated by a public DNS registry as their primary domain for email and/or (optionally prefixed with "www.") their official website.

This part of the proposal is a simpler way to associate emails and websites with an organisation, for sure, and might work for academic home organisations where there is a strong academic brand. But I can see difficulties when dealing with service provider organisations, especially those which consist of multiple legal entities. What would be a primary domain for email? Which of the websites would be "their official website"? I don't think we should add this loosely-defined mechanism to an already-flexible proposal.

[paxus42]

I agree that web and mail address check is more for home organisations than for services, but we need to have a battery of different possibilities. We could add the home organisation constraint to the method.

[paxus42]

I agree that web and mail address check is more for home organisations than for services but we need to have a battery of different possibilities. We could add the home organisation constraint to the method.

[alexstuart]

I've tripped over this wording when I've reviewed eduGAIN applications. To me, "properly" implies that the registrar has some criterion and performs tests against the endpoints using a public service or private application, and also implies that the entity is operational at the time of registration. I'd remove "properly" to allow a process where a registrar only checks whether the endpoints are HTTPS.

[ghalse]

@alexstuart how about:

• Ensuring protocol endpoints are protected with TLS / SSL certificates. Where a private certificate authority is used, the Federation Operator MAY ask the Registered Representative to confirm that the trust anchor is reasonably likely to be embedded into the browsers of all users of the Entity.

[alexstuart]

Yes, I like this. It would also allow test entities with certificates from an internal / private CA to be in the main metadata.

[paxus42]

I agree

[ghalse]

This part of the proposal is a simpler way to associate emails and websites with an organisation, for sure, and might work for academic home organisations where there is a strong academic brand. But I can see difficulties when dealing with service provider organisations, especially those which consist of multiple legal entities. What would be a primary domain for email? Which of the websites would be "their official website"? I don't think we should add this loosely-defined mechanism to an already-flexible proposal.

Thinking about this, I agree with @alexstuart. But perhaps not for the same reasons, particularly given 3.2.2.5.4 he referred to is marked as retired. My logic is:

• The non-retired DCV mechanisms in the CA/Browser forum already allow for some email-based authentication (3.2.2.4.4). A federation could also take a slightly more liberal interpretation of "agreed upon change to website", more akin to the version that used to exist before the /.well-known/pki-validation path was standardised (i.e. 3.2.2.4.6/3.2.2.5.1). [As an aside, this is what we currently do]
• Almost every institution will have an SSL certificate of some form and will be used to the DCV mechanisms they use. So this isn't asking them to do something unfamiliar.