• Created by Unknown User (jukohtan@csc.fi), last modified by Unknown User (anastasi@csc.fi) on Jun 06, 2019

When

26th of November 2018 11:00-12:00 CET

Where

TelCo   https://cscfi.zoom.us/j/706669343

Please install the Zoom client in advance https://zoom.us/download#client_4meeting

Documents

Comments

Some initial feedback from Matija on the feedback from Janina/ Wojtek:

Pros:

* Well defined, works well with existing EWP standards and protocols

* It would solve the need for some NCPs to only accept registered clients

 

Cons:

* One of EMREX' strongest points was its simplicity, especially for clients. This way, more complexity is introduced.

* Complex implementation

   - NCPs would need to create and handle manifests

   - clients would have to parse the EWP registry and find suitable NCPs

* Clients would need to register in the EWP registry as well, and publish own manifests, if they are to be able to use the EWP security mechanisms (HTTP signatures are validated against known keys from the registry)

* Missing a smooth solution to handle expiration/replacement of certificates (current EMREG is missing it too, but we have a proposal to improve this)

* Not backwards compatible

   - rewriting EMREG to act as a proxy could work, but then it should only be that - a proxy, not have an own list in addition to the NCPs fetched from EWP; also, it would have to be a temporary solution and deprecated at a later point

* Political issue - EMREX gets devoured by EWP.

 

Suggestions for improvement, if we go for this:

* Consider using JWT as a token (with a very short expiration time) to avoid the need to handle sessions at the NCP

 

Wojtek's comments:

> * One of EMREX' strongest points was its simplicity, especially for clients. This way, more complexity is introduced.

- If we go with the backward compatible solution, then not necessarily.

- As far as I recently learned, some countries require these new features.

- The alternative proposal Janina had me read (the one about adding client certificates to EMREG) introduces even more complexities, I think.

> * Complex implementation

>    - NCPs would need to create and handle manifests

Only if they want the clients to authenticate themselves. Otherwise, they can make use of EMREG (assuming you go with the backward-compatible solution).

>    - clients would have to parse the EWP registry and find suitable NCPs

Only if the clients want to authenticate themselves. In the backward-compatible solution EMREG will do the filtering for them (and present those NCPs which can be accessed without authentication).

> * Clients would need to register in the EWP registry as well, and publish own manifests, if they are to be able to use the EWP security mechanisms (HTTP signatures are validated against known keys from the registry)

Same as above (only if the clients want to authenticate themselves).

> * Missing a smooth solution to handle expiration/replacement of certificates (current EMREG is missing it too, but we have a proposal to improve this)

It's not missing. EWP already has a solution for that. Both servers and clients are allowed to use multiple credentials at the same time. Smooth handling of credential expiration was one of the initial design priorities, and was solved long ago

> * Not backwards compatible

>    - rewriting EMREG to act as a proxy could work, but then it should only be that - a proxy, not have an own list in addition to the NCPs fetched from EWP; also, it would have to be a temporary solution and deprecated at a later point

I don't understand. Perhaps I missed something when I was writing the quick specs draft I prepared, but I'm pretty sure it can be done in a backward-compatible way.

> * Political issue - EMREX gets devoured by EWP.

I guess we could dress this up in some kinder wording. E.g. "EMREX allows partners to make use of their existing EWP implementations to provide additional security, if the partners need it"

 

add you comments here

  • No labels

4 Comments

  1. Unknown User (jmd@mimuw.edu.pl)

    1. The decision was to go for the combined registry.
    2. We should make the solution backward compatible and keep backward compatibility as long as necessary.
    3. Norway agrees to switch to the new registry under the condition that Warsaw will design and implement it and the EMREG will become a proxy.
    4. Wojtek upgraded the specification, it is posted above as version 2.
    5. It is crucial that the combined registry will not be owned by any of the European projects. It should be 'owned' by the academic community, delivering services to all past and future projects and digital initiatives, like EWP, EMREX, ESMO, ESC, you name it.
    6. Jan-Joost will meet EUF on December 6th and will explain how we view the possible cooperation and how all projects may profit out of it.
    7. We need a new name for the registry. I give those below to make you think about better proposals
      • DigiReg
      • EuroReg
      • UniReg
      • E-REG

  2. Unknown User (jmd@mimuw.edu.pl)

    Wojtek, could you please sum up the new specification, by explaining who will be able to talk with whom and in what way in such scenario:

    1. Denmark does not change the EMREX client (SMP).
    2. Italy does not change its NCP.
    3. DUO (Netherlands) changes its EMREX client and NCP.

  3. Unknown User (g.m.vangen@fsat.no)

    In addition to Janina's summary :

    7.

    • EduReg

    8. We need to agree on a SLA for a common registry

     

  4. Jorma Korkiakoski

    My comments:

    1/ Don't see the new spec to be too complex

    2/ Certificate management - cert updates have daily - needs to as self-service via UI or API

    3/ SLA for EMREG?

    4/ We need a good test suite