what is the exact meaning of an approval

[georgschermann]

During recent discussions this question reappeared again, during the last meeting I attended there was no clear answer to this. So what is the meaning of receiving an approval to ones iia in the different partners implementations? Should this be a 1:1 replacement for a signature on the iia get response? Does an approval mean that an iia can be put into effect even without signature data on it? I think the specification and examples don't provide a clear understanding what an approval should be and should do. @janinamincer-daszkiewicz @fmapeixoto @umesh-qs @pleys

In my understanding an approval only meant, that the iias in both systems are the same. In our implementation which is based on the initial optionality of the approval iia we: a) send an approval for the partner iia when we sign it. (signing it is currently only possible if we have a matching iia on partner side) b) we don't care for partner approvals of our own iias at all.

This leads to problems with some implementations which rely on the approval instead of signature data on the iia.

[janinamincer-daszkiewicz]

Georg, we will come back to you soon.

[martincharlier]

@georgschermann from a business perspective, it seems crucial that both parts give their approval on the data stored in each other's information systems. otherwise it can create misunderstandings and errors in the future.

[janinamincer-daszkiewicz]

I see this that way:

1. Signatures are for informative purpose - you want to know who and when. I presume that somebody in authority logs in to the partner's SIS and pushes the SIGN button. SIS saves person id and date. This is kind of a weak confirmation of will. In Polish law some documenta (like examination sheets) can be approved/signed/confirmed in such way.

2. Approval sent by my partner to my own version of IIA which brings hash of this version is more serious. It is like a digital qualified signature, strong proof of will by the partner. I can keep it and use in court (although with some extra effort, see discussion on XML signatures in https://github.com/erasmus-without-paper/ewp-specs-api-iias/issues/48#issuecomment-922460127). In Polish law you need this type of strong approval e.g. for the administrative decisions concerning stipends, admissions etc.

Some HEI's are happy with (1), the others feel better with (2), providers should deliver what their clients request. In particular no HEI should refuse strong approval if their partner requests one.

[georgschermann]

Then there is a serious overhaul of the specification needed, since nothing of this is mentioned in the slightest way. Also the approval lacks several criteria to come anywhere near a qualified signature but that shouldn't be an issue in the context of EWP. Since I approve a set of coop-conditions which is separate from signing information and in-effect status, does an approval always mean that the approving partner is ready and willing to put these coop-conditions into productive use?

[janinamincer-daszkiewicz]

Then there is a serious overhaul of the specification needed, since nothing of this is mentioned in the slightest way. We can work together on making the specification more clear (Github issues help with that) but also not too restrictive to leave some space for local arrangements if needed.

Also the approval lacks several criteria to come anywhere near a qualified signature but that shouldn't be an issue in the context of EWP.

We do not need full strength of qualified signatures, what we have now is good enough for the purpose it is supposed to serve.

Since I approve a set of coop-conditions which is separate from signing information and in-effect status, does an approval always mean that the approving partner is ready and willing to put these coop-conditions into productive use?

This is worth discussion. I would like to here opinion of BPOs. Definitely we should respect what our partners in mobility need and expect.

[georgschermann]

@janinamincer-daszkiewicz Are there any updates on this specification- or documentation-wise? Any documentation reflecting the decisions that approvals are on par with signatures? We still have some Universities asking for signatures where partners can only deliver approvals.

[demilatof]

After discussing in other threads about approval and reading again the APIs' specification, I still have a lot of doubts about what is the exact meaning of an approval. Because I read about legal proof, but in my opinion, we have first to clarify when an approval is effective.

The specification of Approval CNR says:

approving_hei_id (required) Identifier of the HEI which has recently approved the partner's copy of the IIA"

https://github.com/erasmus-without-paper/ewp-specs-api-iia-approval-cnr

This means that the approving hei (A) can approve an IIA downloaded from the partner (B), without knowing if B considers that IIA the good copy? If so, this would mean that in A's system there is an approval of B's IIA without that B is informed. And that the approval remains even if A never sends an IIA Approval CNR. B could periodically poll to check if there is an approval, but what happen if, at some point, B realizes that A approved the wrong version of IIA?

Therefore, in my opinion, it could bring legal issues if A gives approval by itself.

Second step: A must use Approval CNR to inform B that is ready to give an approval. Is the approval effective after sending Approval CNR? No, because A is still thinking alone, without knowing B's will.

Third step: B sends Approval request specifying ONLY IIA-Id and not hash code. The specifications say that A should answer with an approval that contains IIA-Id and hash code. Is the approval effective at this step? Yes, according to specification, not for me.

There is a lag from Approval CNR and Approval; during this time B could have changed its cooperation conditions, then B could send Approval Request with the same IIA Id. In this scenario B could "stole" an approval from A, and we have B that considers that A approved its new version of IIA whilst A still considers that it has approved the right version (but it approved the old one). The specifications say that A can check if hash code is changed from when A sent Approval CNR, but specifications don't say what to do.

Moreover, if I haven't misunderstood the specifications, A should not compare if the previous IIA hash code is identical to the one contained in the last B's IIA, but only compare the hash code proposed by B and hash code computed again by itself. And this control should be performed not when A receives B's approval request, but before sending Approval CNR.

For this purpose, the server has to call the IIAs get API and compare the hash received in the response with the hash independently calculated from the cooperation conditions received in that response. If both hashes are identical, the agreement can be approved ... Note: Server does not perform above mentioned hash verification as a result of IIAs Approval get request. It MUST be done before and stored locally on the server (and announced with CNR).

https://github.com/erasmus-without-paper/ewp-specs-api-iias-approval/blob/stable-v1/response.xsd

In my opinion we can have an approval after and only after the following steps are all concluded successfully:

1. A retrieves last B's IIA and check that hash code is equal to the IIA previously examined by A's IRO
2. A sends Approval CNR to B, saving the hash code of the IIA for which is ready to give approval (repeat until status 200)
3. B sends Approval request to A's server (this could happen immediately or after weeks, depend on B's implementation)
4. A reads the received parameter "IIA-Id" and calls B's IIA Get to download the last IIA version in B's systems (the lag from B's Approval request and this IIA Get is really minimal, few seconds)
5. A checks if the hash code stored at point 2 is still the same of the hash code just downloaded (point 4)
6. If and only if the stored and downloaded hash code is identical, A can send Approval response.

If the hash code is changed it means that A IRO has seen a different version of IIA and its approval is no more valid. A's system must notify A's IRO that B copy is changed and must be examined again.

Only after point 6 concluded successfully we are sure to have an approval that respects both A and B will. If the check in point 6 fails, we don't know what to do, because specifications don't say anything.

I'll appreciate to listen some opinions about the above statements; I can even propose a possible solution to inform B that A could no more give approval.

[janinamincer-daszkiewicz]

This means that the approving hei (A) can approve an IIA downloaded from the partner (B), without knowing if B considers that IIA the good copy?

One of the conclusions from the BPO meeting yesterday: only IIAs which are regarded by the HEI as ready for approval can be made available to the partner in the network. HEI should not (intentionally) expose IIA which is not regarded as 'ready to be approved'.

Minutes from the meeting will be ready soon.

[demilatof]

One of the conclusions from the BPO meeting yesterday: only IIAs which are regarded by the HEI as ready for approval can be made available to the partner in the network. HEI should not (intentionally) expose IIA which is not regarded as 'ready to be approved'.

And doing so we can say that EWP dies under the master-master model. An IIA to be ready for approval must contain both HEI A's IIA-ID and HEI B's IIA-ID. To fill the IIA with both IIA-IDs the HEI A has to download an IIA from the HEI B (or all the IIAs obtained by index API), then HEI A has to examine the downloaded IIAs to find the exact IIA-ID. But because the BPO said that only IIAs that are ready for approval can be made available to the partner in the network, it means that no IIA could be downloaded so that we can match it with our copy. Deadlock (even the API index will be empty)

[janinamincer-daszkiewicz]

An IIA to be ready for approval must contain both HEI A's IIA-ID and HEI B's IIA-ID.

Not the very first one - this is the reason partner's IIA id is optional in spec.

[demilatof]

An IIA to be ready for approval must contain both HEI A's IIA-ID and HEI B's IIA-ID. Not the very first one - this is the reason partner's IIA id is optional in spec.

Are you sure? I read something different:

Also it is REQUIRED to provide partner agreement ID to be able to approve it.

https://github.com/erasmus-without-paper/ewp-specs-api-iias/blob/stable-v6/endpoints/get-response.xsd

It's optional if we want to expose out agreements to partner, so that it could examine our copy of the IIA. But it is mandatory if we want to be able to approve it. Shall we add it in a blinded manner, because the partner emailed the IIA Id to us, without checking the content of the IIA? Because without approval in future we could not get the partner's IIA, but to give the approval we have to know the partner IIA Id. And without the partner's IIA Id the EWP network could not expose anything.

[janinamincer-daszkiewicz]

It's optional if we want to expose out agreements to partner, so that it could examine our copy of the IIA.

Yes

But it is mandatory if we want to be able to approve it.

Yes

Shall we add it in a blinded manner, because the partner emailed the IIA Id to us, without checking the content of the IIA?

The partner shouldn't do it.

Because without approval in future we could not get the partner's IIA, but to give the approval we have to know the partner IIA Id. And without the partner's IIA Id the EWP network could not expose anything.

We will get the partner's id after the partner sends IIA CNR and we call IIA get, but that should not happen blindly.

Yes, it creates practical problems in the network and this is the reason the Dashboard send blindly IIA CNR after storing the partner's IIA in the local system, just to share iia-id as soon as possible.

Do you have the better proposal?

[demilatof]

We will get the partner's id after the partner sends IIA CNR and we call IIA get, but that should not happen blindly. This is no more a problem, after I read this

For me, ready to be approved means that (1) A has created it, (2) B downloads it, (3) B declares it as ready for approval, B sends Approval CNR to A and finally B receives IIA Approval calling.

Ready for approval means that in someway we straightly jump to step (3), when A's IIA is ready for approval.

Yes, it creates practical problems in the network and this is the reason the Dashboard send blindly IIA CNR after storing the partner's IIA in the local system, just to share iia-id as soon as possible.

Do you have the better proposal?

My problem was concerned to "ready for approval"; I realized that indeed the BPO asks for "ready to be approved", therefore now the IIA IDs can be exchanged as they were before.

But at this point I'm more interested in understanding the Dashboard behavior. What does it mean, exactly, the Dashboard sends blindly IIA CNR after storing the partner's IIA in the local system? The IIA CNR regards the Dashboard's local copy of the agreement. To share the IIA-IDs the partner's IIA must be examined to know the matching local IIA, the simple storing is not enough. Moreover, if it sends immediately the IIA CNR the partner could download the Dashboard's copy before the Dashboard's officer corrects his copy of the agreement to uniform it to the partner's IIA information.

[janinamincer-daszkiewicz]

As requested during the Infrastructure Forum meeting on 2022-12-14 I close old issues and will create a new one to finalize the discussion on functionality to terminate/modify approved IIAs.