Validation of partner's HEI coverage

[wrygiel]

This topic is important, but it didn't seem urgent enough to bring it up before. Still, we should begin considering it. @erasmus-without-paper/all-members

The Problem

When a new partner X wants to join the EWP Network, it first publishes its manifest file. In this file X states that it covers HEIs A and B. Then, he sends the HTTPS URL of this manifest file to the EWP Registry maintainers.

• How should the Registry maintainers (or the Registry itself) verify if A and B indeed agree to be covered by X?
• Should such validation occur just once, or should it be repeated once in a while, or run continuously?

Solution 1 (the current one)

The current solution hasn't been discussed nor officially agreed with anyone. It's perfectly okay for development, but it will probably not be enough for production use (especially once more HEIs start to join the network).

It builds on the fact that the Registry maintainers know all the partners first hand:

• They know which partner is allowed to cover HEIs in which country.
• They simply trust the partner to cover any number of HEIs in his own country.
• They do not ask the HEIs themselves if they want to be covered by this partner.
• The only limit to that trust is expressed in the value of the <hei-regex> element they type into the Registry's manifest-sources.xml file (when they're adding the partner's manifest to it).

It currently looks like this:

<manifest-sources>
    <source>
        <location>https://example.com/manifest1.xml</location>
        <hei-regex>^uw\.edu\.pl$</hei-regex>
    </source>
    ...
</manifest-sources>

We are also thinking about using this feature as means of delegating trust. For example:

• We might allow certain partners to govern their own subset of manifest-sources.xml file, provided that all their <hei-regex> values end with .se.
• This way, we delegate the responsibility of validating all organizations in Sweden to that partner.

This solution has drawbacks though. In case of partners which will cover a large number of HEIs in different countries (such as SOP), we would (probably?) need to simply allow them to cover any HEI.

• Would this be acceptible by all the other partners?
• Note, that solutions to this particular problem can be changed without modifying any implementations (except, perhaps, the Registry itself). So - perhaps - Solution 1 would be acceptible for now, and we may plan modifications for later?

Solution 2 (Porto)

Copied from here:

Pre-requirements:
• Registry has a table like "ERASMUS_ORG", where the fields bellow are mandatory:

• ERASMUS Code
• Name
• ERASMUS_ORG's tld
• Email Address of contact
• A server IP address of ERASMUS_ORG.tld endpoint
• A date field

The ERASMUS_ORG must have on it's tld a TXT DNS record of the form default._erasmus_withoutpapers.ERASMUS_ORG.tld whose content would be an hash of some form containing the information above.
Connection:

1. HOST: establishes a secure connection of some form with the registry;

2. REGISTRY:
   o Checks the HOST's IP address/hostname and verifies against ERASMUS_ORG's tld default._erasmus_withoutpapers.tld DNS entry if HOST is allowed to talk with registry (on behalf of ERASMUS_ORG).
   ♣ If it is then connection proceeds normally.
   ♣ If it isn't then the REGISTRY 403's (or 401) the connection and sends a(n out-of-bound e-mail) message to the IRO/SYSADMIN of this domain from the ERASMUS_ORG asking him to confirm that in fact HOST is intended to talk on its' behalf to the REGISTRY, and if that is ACKed then send the IRO/SYSADMIN the contents to place under default._erasmus_withoutpapers.ERASMUS_ORG.tld

3. As an additional safety measure the keys to place in the DNS record described above would cease to function, say one year after their creation, forcing their periodic renewal.

Solution 3 (WP4)

We make use of the HEI's TXT DNS records (as Solution 2 does, but with different entries):

• We require the HEI to state which manifest file(s) it allows itself to be covered by.

  For example, uw.edu.pl would be required to contain a TXT record similar to this one:

  covered-by-erasmuswithoutpaper-manifest-url=https://ewp.demo.usos.edu.pl/manifest
  

• Now, the validation can be performed by the Registry automatically:

  • We make use of the fact that HEI TLDs perfectly match the definition of our SCHAC HEI IDs.
  • Whenever a manifest file at URL X states that it covers some HEI ID Y, the Registry fetches TXT records for Y's TLD and makes sure that covered-by-erasmuswithoutpaper-manifest-url=X is present among them.
  • The Registry verifies all TXT records every now and then. If X TXT entry disappears from Y, then the Registry removes Y from the list of HEIs been covered by X (and issues a warning at the manifest's <admin-email>).

• Manifest URLs are not supposed to be frequently changed, so HEIs will not be required to update their TXT entries later in time.

The only possible downside of this solution is the necessity of sustained presence of EWP TXT entries in the HEI's DNS entries. But I don't think it's a major problem.

Solution 4 (= 1 + 3)

A mixed solution: We use different strategies for different partners (e.g. for Poland, we stick with Solution 1, while for SOP, we require Solution 3). The Registry administrators express these requirements in the manifest-sources.xml file.

For example:

<manifest-sources>
    <source>
        <location>https://ewp.demo.usos.edu.pl/manifest</location>
        <!-- This indicates simple validation, as described in Solution 1 -->
        <hei-regex>^uw\.edu\.pl$</hei-regex>
    </source>
    <source>
        <location>https://www.service4mobility.com/manifest.xml</location>
        <!-- This means that all SOP's HEIs will need a Solution 3's TXT entry. -->
        <dns-tld-validation/>
    </source>
    ...
</manifest-sources>

This solution also allows for even more validation methods to be introduced in the future.

[mpuzar]

Can't say it with 100 % certainty, but any solution involving any requirements in DNS records is probably not feasible for us.

[wrygiel]

Can't say it with 100 % certainty, but any solution involving any requirements in DNS records is probably not feasible for us.

I also believe that Poland would prefer Solution 1 for itself (it doesn't make use of DNS and seems sufficient for partners which cover whole countries).

[georgschermann]

I don't believe that all of our customers would be able or willing to add such an entry to their dns.
Currently only ~5 out of 50+ customers which use our mail server were able/willing to add a SPF record to their dns. Although this would probably be the better solution.

One possible solution similar to 3 would be that they can host this text somewhere on their homepage, which is somehere under their domain and probably serverd via https with the same certificate as the domain represented by their schac. This would remove the need to alter their DNS entry. And most IROs are able to publish to a website of the university.

[wrygiel]

One possible solution similar to 3 would be that they can host this text somewhere on their homepage

If we intend for this verification to be automatic, this would need to be much more specific. Because "somewhere on their homepage" might include "anonymous comments below some unimportant article".

Here are some verification methods Google uses. They also seem to have an API which the Registry might make use of. However, all of Google's verification methods require direct access to the server. An admin would need to be involved, IROs wouldn't be able to do this themselves.

[mikesteez]

For now, solution 1 ought to be good enough. Stealing the scope of other HEIs should violate the Terms of Service for the EWP network.