Skip to end of metadata
Go to start of metadata

Usage

EMREG is a centralized service that has to be available to all SMPs. It gives a list of all available NCPs, as well as other information necessary to establish communication with each of them. Administration of NCPs within EMREG is out of scope of this document.

Available services (API)

There is only one service available to the SMPs, returning a list of all available countries and NCPs, where each NCP can contain a list of all institutions it is responsible for. There is also a parameter (called "singleFetch") saying whether a particular country has separate NCPs for each institution. In that case, after the country has been selected, the student will be presented with a list of all NCPs registered for that country, and for each NCP only the first institution on the list will be presented to the student (even though, for compatibility reasons, it will still be delivered by EMREG as a list).

In later versions, if we see that the list might be too large, we might give the possibility to send a filter/search parameter as well (however, we have to bear in mind that this would cause more connections towards EMREG).

Input: (none)

Output: List of all available NCPs, in JSON format. Example:

NCP List

Live EMREG

We have implemented a live & running EMREG with three different sets of data (development, test, and production).

Development: https://fsweb-demo.uio.no/emreg/list/dev

Test: https://fsweb-demo.uio.no/emreg/list/test

Production: https://fsweb-demo.uio.no/emreg/list

  • No labels

7 Comments

  1. I have a new EMREG root data section proposal:

    • The key would be trustedReceivers.
    • The value would contain a dictionary:
      • Each key would contain a regular expression describing an URL of a trusted NCP-response receiver endpoint.
      • Each value would contain name of the owner of this endpoint.

    E.g.

    {
    "countries": [...],
    "ncps": [...],
    "trustedReceivers": [
    "^https://example.com/process-ncp-response\b.*$": "University of Example",
    "^https://([a-z]*.)?example.com/.*$": "Including sub-domains"
    ]
    }

    It's a security issue:

    • The current way of handling NCP-requests provides NCPs with no way of verifying the level of authority the requester has.
    • With "trustedReceivers" we would be able to tell the student who precisely will receive his data instead of displaying returnUrls (which wouldn't tell much for a regular user).
    • NCP would still be allowed to send the data to untrusted receivers, but the student would be warned differently.

    Also, it's backward compatible, so the existing NCP implementations won't need to be changed (unless they want to adopt that extra level of security).

    1. We had something like this in the initial proposal, but dropped it as it would mean a lot of administration work when new institutions are added (or URLs changed), with no apparent security gain. Also, we have to remember that it is the student who starts the whole process, is logged in on the client side first (so the student has a problem already there if it is "untrusted"), and then at the NCP as well.

      1. Then why do we require for NCP to display the URL of the receiver endpoint? http://i.imgur.com/52f6TfG.png

  2. That is new to me, I can't remember such a decision being made (note that the text you point to does not say URL, and as you also pointed out an URL wouldn't mean anything to the user).

    However, it is a valid discussion point - it would be nice for the student to get a message saying something like "Please check the results above, and press the button below to transfer them to University of Example". A simple implementation would be to include the requester institution's name into the request message. Of course this cannot be verified, but as mentioned before, if the requester is fake, the student has much bigger problems as their whole account has been compromised by that point.

  3. (Side note) If we can detect such compromised accounts, then there's no reason not to.

  4. Sending requester's name along the request would just make the potential hacker's job easier. Of course, we could say it's "unverified" when displaying such name, but that would just make the student uncomfortable. (wink)

  5. As mentioned, it would be a potentially huge administration work on EMREG for potentially no security gain. Failure to keeping EMREG up-to-date and saying that (valid) requests are unverified would also make the students uncomfortable.