erasmus-without-paper / ewp-specs-api-iias

Specifications of EWP's Interinstitutional Agreements API.
MIT License
4 stars 13 forks source link

Which IIAs should be published to the counterparty? #89

Closed jiripetrzelka closed 1 year ago

jiripetrzelka commented 2 years ago

The specification is currently not very clear when it comes to the definition of conditions that have to be met in order for an IIA to be published to the counterparty. My assumption is that an IIA should be published only in case the coordinator of the owning side is aware of the existence of the IIA and has internally signed or otherwise confirmed the contents of the IIA and subsequently requests an approval from the counterparty. To ask for an approval is to ask for energy and time of the counterparty. Ideally, the coordinator should ask for the approval only once.

How does the counterparty find out that an approval is required from them? By mere presence of the IIA in the network? Or should they assume that a greater set of IIAs may be published by partners and only some of them are supposed to be reviewed and approved? If so, how do coordinators divide the IIAs into "approvable" ones and those IIAs that do not require their attention yet? Can client implementers assume that there is an equivalence between the presence of the conditions-hash element and the IIA being ready for approval? I.e. assume that if the element is present, approval is requested, and if not, then approval is not yet requested?

I raise these questions because I have come across hundreds of IIAs that we have published to universities using Dashboard. Each time we publish an IIA, Dashboard imports the IIA and publishes the corresponding copy in their Index endpoint. This is done instantly and without any intervention of the partner coordinator. After several seconds, the IIA of the counterparty is available and we can approve it. And so we do. And it costs us time and effort because our coordinator has to review the IIA. After all, we don't know if the IIA has been created by an automaton from our IIA or whether there has already been some conscious action from the partner coordinator.

Several days later, the coordinator of the counterparty usually logs into Dashboard and finds out that there is a new IIA and changes something and then signs the IIA. Regardless of whether it is an important change or a completely insignificant change, the conditions-hash is usually changed* and a new approval is requested from our coordinator. So we have to review the IIA anew and issue a new approval. This would not be the case if the IIA had been published to us only after partner coordinator reviewed and signed the IIA.

The scenario illustrated above has implications for the IIA Stats too, specifically for the number specified in the iia-local-approved-partner-unapproved element. This number is artificially augmented by the number of IIAs that have been imported automatically by Dashboard and which we have subsequently approved. Evidently, we approve IIAs whose contents is identical to our own IIAs.

What do others think about this? Should only those IIAs be published that have been reviewed/signed by the coordinator of the owning party? Please share your opinion.

umesh-qs commented 2 years ago

Hi @jiripetrzelka This is very valid point that you have raised and unfortunately the end users of both the partner system suffers because of different processes. And this will continue to happen until we arrive at a common process.

Anything released into the EWP network should go an initial check. This sounds absurd that IIAs are shared without the knowledge of the person who is supposed to approve it. This is not only adding more work for the partner university staff, it is also giving wrong figure to EUF.

janinamincer-daszkiewicz commented 2 years ago

This issue will be discussed during the Infrastructure Forum meeting on 2022-10-19 (and the next ones, until resolved).

janinamincer-daszkiewicz commented 1 year ago

Discussion continues in https://github.com/erasmus-without-paper/ewp-specs-api-iias/issues/41 and https://github.com/erasmus-without-paper/ewp-specs-api-iias/issues/96, I close this issue.