search

erasmus-without-paper / general-issues

An empty project for tracking issues not related to any specific project.
0 stars 1 forks source link

Changes to specifications presented at the Technical Workshop on 2021-10-19 #37

Closed mkurzydlowski closed 2 years ago

mkurzydlowski commented 2 years ago

This issue is provided as a place to write comments regarding the changes to specifications presented at the Technical Workshop on 2021-10-19:

2021-10-19-TechnicalWorkshop2_final.pdf

pmarinelli commented 2 years ago

Hello everyone,

here are our comments, from the University of Bologna.

Nominations – additional info/documents

If the proposal aims to give the chance to embed attachments (encoded in some codification scheme) into XML responses, we are a little bit concerned about it: HEIs that want to store XML responses will implicitly store every attachment embedded in those responses and that doesn’t make much sense in our opinion. In order to avoid that, client will be required to remove any attachments from the received response.

We ask you if you have ever considered to design an API dedicated to attachments. That would clearly separate documents from data. It seems a good idea in our opinion.

One Manifest File per Hei

We already have one manifest per HEI, so we are not among those that will be most impacted by this change. However, we ask you to arrange things such that the EWP Registry Service client (https://github.com/erasmus-without-paper/ewp-registry-client) will preserve its current behavior.

Moreover, the report states: “Certificate one per manifest!”. Does it mean that each HEI will be allowed to publish at most one certificate?

If that’s the case, we believe that it could cause some communication issues. Indeed, a CA-signed certificate is generally valid for one year. Having the chance to publish more than one certificate would allow an HEI to publish the new certificate one or two days before the expiration of the old one and to continue to use the old certificate. Subsequently, the HEI will remove the old certificate and start using the new certificate. This is a way to avoid authorization errors: by the time the new certificate will be used, all HEIs will have updated their cache of the registry and thus will recognize it.

Conversely, without the chance to publish more than one certificate, at the expiration of the old certificate, an HEI must remove it, publish the new certificate and start using the new certificate, everything in a single step. Then, if it wants to communicate with another HEI but such a HEI has not updated its registry cache yet, the communication will fail.

The alternative to multiple certificates is to use self-signed certificates, whose validity could be set to span over a very long period (e.g., 10 years). If the specs will go for the one certificate limit, then we think that they should also state the self-signed certificates MUST be accepted.

Hash vs XML signature

We think that the specs should continue to make use of hashes, provide a more precise explanation on how to calculate them as well as a set of test documents that could be used by developers to test their implementation.

We are afraid that introducing a completely new mechanism such as XML Signature at this time would require an effort that is far from being compatible with the current deadlines.

georgschermann commented 2 years ago

Hi @pmarinelli I think the one cert by manifest is a misunderstanding as the 2021-02-14-RP-ManifestFile describes "One section with client credentials." and "One section with server credentials." per hei, so I think what this means is that one cert should not be used for multiple HEIs, as it is currently the case. Also httpSig work with keys instead of certificates so the problem does not arise here and tls cert auth may become deprecated in my opinion with the spread of TLS1.3 since there are a few breaking changes, also Dashboard among others already dropped tls cert auth, so httpSig auth is already a "must" and is supported by all partners I think.

AlbertoCloserideas commented 2 years ago

Hi from url.edu we agree with the changes. When will they be released? when will be mandatory to follow?

janinamincer-daszkiewicz commented 2 years ago

We are working on the changes in the specifications, they should be expected early next year.

janinamincer-daszkiewicz commented 2 years ago

Specifications have been further discussed during the second Infrastructure Forum on 2022-03-02. Changes to specifications are underway, will be finished next week.