Excluding certain fields when calculating conditions-hash #48
Comments
|
In my opinion, the contacts shouldn't be calculated because, as referred by Kamil, "...do not contain information that should affect the validity of the agreement.". Regarding the OUnits in the cooperation conditions, I have 2 use cases that I understand may exists or not:
|
There may be situations when e.g.:
Of course, an erroneous situation may arise when, for example, faculty is specified at the partner level, and other faculties are specified at the cooperation conditions level. But it is a business error that should be noticed by the user and not by the system. |
|
And one more remark, does it make sense, per cooperation condition, to have it 0-unbounded? Shouldn't it be just 0-1 per cooperation? Just asking because I don't know practical use-cases of these. |
|
Restricting to a maximum of 1 can also resolve #29. This was closed today without any solution. |
|
I don't know if this is relevant, but the Erasmus Dashboard right now only allows one OUnit per Agreement (so not even on the cooperation level). Is this something that EUF should 'fix'? For example: @umesh-qs, it might prove weird when one of your MoveOn users starts an agreement with 4 cooperation conditions that each has a different OUnit, and it comes into the Dashboard as 4 separate agreements. What happens if the Dashboard user then changes things on an agreement level, and sends it back? What does the MoveOn user see then? As for your remark @fmapeixoto
It depends; right now the Dashboard users are making up OUnits for 'institution-wide' agreements - because they cannot choose multiple OUnits per Agreement in the Dashboard. That means that we have 7 faculties + 1 institution-wide OUnit. That is not a problem per se, but might not be the perfect way to use these Units... |
|
@EvelienRenders But that is not what is there under the issue #29. What I was asking is that when there is no limit on the number of cooperation conditions then how do I uniquely identify each cooperation condition. Restriction to max 1 for each type can resolve the issue. |
|
@umesh-qs I find it comforting to hear that you think the Dashboard's implementation is not the best because personally, I'm thinking that as well - I will send EUF the feedback via their support portal once it is online again... Thank you for all the hard work that is going into this on your end, but also on the ends of the other 3rd party providers - it's much appreciated (although not many might let you know during the 'trial and error' phase 😉) |
|
@kamil-olszewski-uw I think we should leave contacts out of conditions hash. I see a great advantage of having contacts connected the the agreements, e.g. for sharing the academic coordinator of a given agreements (who can be the responsible person for signing learning agreements) but this person can change every year and we don't want to re-approve our agreement every year. |
|
The organisational units discussion is somewhat more complex and the discussion above points to the issue of grouping agreements that I raised earlier. |
|
@kamil-olszewski-uw |
The point is that the mobility coordinators are not part of the agreement. They would not be on a traditional paper agreement. However, since the coordinators are part of the cooperation conditions in API, the change of the coordinator would make the hash, which was the basis for accepting the agreement, obsolete. And the change of coordinator is something common. Therefore, we want sending-contact and receiving-contact not to be taken into account when hash is calculated. |
|
I believe the discussion here should be directly related to whether we remove some fields from the calculation of the Hash, and or they should exist, and if so, in which circumstances. For the IIA ecosystem (all APIs) to work properly, all the systems (ownsys and providers) have to guarantee that they are able to comply with all the fields (at least for the calculation of the hash) and have proper ways of storing and sending the exact same values, in the same order, so the hash match every time. I don't think we should discuss here already what is supported by whom because what is agreed here should be implemented to comply. I agree with Paul regarding the contacts. Regarding the ounits, I leave the he discussion to the ones who have more deep knowledge about all the use-cases and needs. |
|
@kamil-olszewski-uw |
|
@umesh-qs that is actually a good question which I believe is related because what else is proof that a specific agreement has been "signed" if the hashes don't match on both sides? Perhaps coming back to the topic of having a digital signature in the XML somehow fixes everything. But is the same of having the fields and not being able to change any of them after "signing" (including contacts). |
We are currently in the infant stage of the IIAs Approval API. I cannot speak for others, but we do not have any digitally approved IIA yet, not including test agreements. And even if some agreements between partners using EWP have been approved via EWP, there should still be signed agreements on paper. The most important thing is to meet the specification on the deadlines set by the EC regarding agreements, which will be signed only digitally. |
|
There are a few important issues in this thread - related, but still separate, so we have a slight chaos here. I will try to answer here to unanswered questions: 1. Number of organizational units with cooperation conditions: We understand that @fmapeixoto asked about the 0-unbounded to 0-1 change in the context of organizational units under cooperation conditions, and not in the context of the cooperation conditions themselves. We don't remember who postulated the unbounded organizational units and think we can limit them to 0-1 as long as no one objects. 2. Number of cooperation conditions of one kind: We cannot change cooperation conditions from 0-unbounded to 0-1. A simple use case where the unbounded option matters:
3. Differences between Dashboard and API: @EvelienRenders - If something in the Dashboard currently looks different than the final API shape that we collectively agree to, we are convinced that the Dashboard will be adapted to the API structure. |
|
SUMMARY (our proposed changes to IIAs API based on our discussion):
|
|
Please suggest how to handle hash/approval for existing agreements in the EWP network. |
|
@kamil-olszewski-uw |
|
With regards to point 3 - we found that this would be a bit restrictive. Could someone explain elaborate if this is a technical requirement?
|
|
@kamil-olszewski-uw |
Do you really have individual cooperation conditions dedicated to several (but not all) organizational units? We have several thousand agreements with universities from the EU and almost as much with the rest of the world, and it was always enough for us to indicate one unit or no unit at all. |
Do you mean (1) changes to the existing agreement due to the modification of the cooperation conditions or (2) obsolescence of the hashes calculated so far due to the change in the method of calculating the hash? Ad 1. We thought about it and many voices were in favor of the solution that the change in cooperation conditions should result in signing a new agreement. Ad 2. As I wrote earlier, we are currently in the infant stage of the IIAs Approval API. First stable version was released few years ago. It is difficult to consider earlier versions as an unchanging basis without the risk of numerous backwards incompatible changes |
|
@kamil-olszewski-uw |
|
@kamil-olszewski-uw |
|
This is not true that because of the new changes to the API structure all the existing agreements are not valid anymore. |
|
"We have nothing else to add so please do not push.". This is a very harsh comment. Let me come back to the issue of hash change, with an example
Now both HEI A and HEI B implements IIA API version 6.0
Can any of the IIA service provider, suggest ways, where our clients, don't have to re-approve the already approved agreement in the above scenario? |
|
If I have not misunderstood the question: There two ways:
In my opinion, already approved IIAs do not need to go through a new approval check or process as the re-approval process should apply only if one of the partners change any of the content or the valid years or similar data in the IIA. However, if the IIA API version sets new required fields and these fields are missing in the existing IIAs and the provider systems require these fields to exist for approval process or mobilities, then #2 option should definitely be applied. |
|
This will be a problem over time, not only from 5 to 6 or 4 to 5. |
|
As Francisco wrote, this problem may reappear many times in the future - for example, when the EC decides to introduce completely new elements to the cooperation conditions. We plan to add signatures in the future. But this is a more general issue that also applies to other APIs. Currently, for example, you can use such a solution: If the institution wants the approve agreement only once - with a hash that will never expire and can always be used to check whether the agreement has not changed - then the institution may keep an information in the system, which the IIAs API version was used during approval of the agreement, and the system may have hash calculation algorithms implemented for different versions of the IIAs API. |
|
Of course one would use libraries as much as possible. The point is: the hash is effectively a reference to a response received earlier (in some of the comments above it is treated as a nonce.) That is relatively straightforward. The entire XML is harder:
I think the legal argument (that it is a better proof) should be moved to a different issue, as it solves a different problem, and leads to other questions. |
|
If some one is interested, I tried here #72 (comment) to explain a different approach to the problem; this approach can produce two possible solutions:
|
|
Returning to the issue of emulating signature with a hash. For HEI A to be able to acquire a "signature" on A's IIA it currently needs to:
What's more A has to store B's IIA approval in a way that can be used as a proof of B's will. Currently B would need to implement HTTP signature and A would need to store the data being transmitted. Also B's server key needs to be kept. This key needs to emulate the signing party even if an actual person is a better fit in this scenario.
For a "signature" to be emulated we need both IIA XML and "signed" IIA approval XML, and also be sure that hashes are equal. It should be noted that such "signature" would not be subject to IIA data and version changes, as both IIA and approval would be stored based on the moment of signing. It should also be noted that what has been described above is in fact a simulation of XML signature but a very cumbersome and error prone one. For an XML signature to take place:
Such signed XML is in fact a well defined proof and it additionally keeps the exact information about the signing party. |
|
Some changes in the IIA and IIA Approval APIs will take place by the end of 2022. It makes sense to group them to make the change in the major number of the APIs once. Have a look at arguments listed in #48 (comment). During the Infrastructure Forum meeting on 2022-11-16 the providers will vote if we want to replace hash with XML signature as proposed by UWarsaw. |
|
My bad, I don't completely understand the advantage of XML signature respects the hash code, whilst it could offer similar issues in hash computation. If introducing XML signature is for saving a copy of the XML signed by the partner (as a proof), the same could be achieved saving our XML and the Approval Response where there is the hash code. |
|
There is no advantage of XML Signature over current hash in current context. This just seems a fancy proposal with no real need. |
|
By XML Signatures you mean what we already have in ToRs, i.e. this element?: Do you suggest to encrypt the entire IIA contents and not only the cooperation-conditions element? Do you suggest to encrypt the raw xml or first canonize the xml? Which/whose private key do you suggest to use for encryption? How would the approvals work? Would partners still approve some kind of digest/hash? What is the main added value of introducing this change? |
|
@demilatof, @umesh-qs and @jiripetrzelka asked about added value of XML Signature solution but I'm not really able to add anything more than what I tried to summarize in my previous comment. This solution gives the simplest way (calling XML signing library) to obtain a proper proof of partner's will (properly signed XML with credentials). It is intended to replace the current solution that proved to be very cumbersome and misleading.
Entire IIA.
Raw XML.
We might decide to impose whose credentials should be used for signing but there is a possibility, in this solution, to acknowledge that an agreement is signed be an actual person.
By returning a signed XML with the partner's IIA. The side that gets and approval may (but is not obliged to) check if the signed XML is in fact what it supposed to be. But I wouldn't stress on that, as the IIA might changed in time (data or IIA format) but what is crucial is the exact IIA "state" that has been signed and the fact of signing.
As I wrote in my previous comment, we want to have a proper proof and a simple one to obtain. |
|
@mkurzydlowski How is XML signature a better proof as compared to hash? |
This argument we have heard during analysis from various IROs. Some told us that occasionally they have to go to court and need some proof. This was the main reason the idea to have hash was born. |
|
As well as I remember, this proposal/solution was discussed last year and nobody was in favor of it from the providers. And we now found it on the desk again. Why? Not having a better solution does not mean we need/have to accept a bad or complicated solution. Better, continue with the current implementation until we find a better one. |
@janinamincer-daszkiewicz I assume before proposing this new process as a legally binding proof, you might have checked and confirmed this with legal expert. Please confirm. |
No. Are you suggesting that we do not need hashes at all or that neither the current solution not the proposed one will solve the legal issues? |
I am amused with this question. You and Michal (not sure if this is coming from EWP Consortia) are suggesting that the reason for this proposal is for providing valid legal proof, because some IROs have asked for it. And we are discussing that. If the new complex solution is not solving that then why propose it? |
Yes. The busines requirement was to provide a legal proof. Yes, the request came from Business Process Owners, meaning IROs.
I assume that we are not discussing the business need but the technical solution. We have implemented hashes. We discuss other option, HTTP signatures. Some of us argue that it is more complex, some not. We are gathering all arguments here to be ready for making the final decision and voting. |
I don't agree. We are discussing a technical solution to a business problem. And since the trigger for this proposed technical solution is for providing a legally binding proof, a natural question is "Can this new process provide legally binding proof?". And the proposer(s) is not ready to answer this, but still wants a discussion. |
The same question can be asked about hashes and the answer would be the same. Do you suggest that discussing various technical options does not make sense? |
|
Really? Aren't we already discussing this? I am repeating again. Whole premise of this new proposal is legal validity of the approved agreements. If that is not happening then take is back, work on it and come back. But lets close it for now. I wouldn't even consider it for a vote at this stage. |
|
If I understand it correctly, the main benefit of introducing XML signatures would be increased security. Currently, in case of a dispute, I would show the log containing HTTP communication with partner IIA Approval endpoint and the log containing HTTP communication with my IIA Get endpoint. I would then show that conditions-hashes match and consider it to be the proof of what the partner has approved. In which case this would not be enough? Well, if anybody with fraudulent intentions could get to the logs and modify them. They could modify anything except HTTP headers signed by partner using Http signature. By proposing to start signing the entire IIA and not only Http headers, you suggest that the current mechanism is not secure enough. But I would argue that it is not less secure than what coordinators have been using so far - that is, scanned PDFs with pen signatures. Is forging a pen signature harder than forging HTTP communication logs? I wouldn't say so. @janinamincer-daszkiewicz You mention that Business Process Owners asked for this. Did they mention any legal dispute concerning IIAs in the past in which a pen signature was the weak point? Or have they mentioned that their national or EU legislation requires this level of security or that this kind of legislation is to be introduced in the next 2 years? @mkurzydlowski Do I understand it correctly that instead of approving a hash or digest, the partner A would take the entire IIA of partner B, sign it with their private key and then expose the entire signature element in their approval endpoint, i.e. something like this?: |
|
I have probably made a mistake in my previous comment because Http signature contains message digest on input. So if I am correct, introducing XML signatures is not about increased security but just about a more standard solution. And with the potential to start using personal certificates for signatures. But is it something we need/want? @mkurzydlowski If the entire IIA would be signed and not just the cooperation-conditions, wouldn't it bring some new problems? What if I change just a contact person? The counterparty will need to inspect the my IIA and find out whether the changes made need a new signature? Wouldn't this complicate the process? |
|
I totally agree with @umesh-qs
I don't understand how could be possible discussing the technical solution without fully understanding the business needs. @mkurzydlowski you said:
But on what basis you state that is the simplest way to obtain a proper proof? In order to have a legal proof that is valid in Europe we cannot experiment new solutions that bring only new problems. For example: what XML Signature? Enveloped, Enveloping or detached signature? You also suggest to encrypt the "Raw XML"; but what you mean with "raw XML"? We have already seen that the "RAW cooperation conditions" element was not so "RAW" and unique. In my opinion the great problem that underlies the legal proof issue is the master-master model and the distributed architecture. |
On the request from the European Commission we included in the mandatory business requirements: For the time being and until eSignature becomes a function available in EWP, approval by both parties in the EWP network is considered as the equivalent of a digital signature confirming institutional commitment, provided the institutional legal representative has given an internal mandate. If necessary, due to local rules or regulations, a legal representative can sign Inter-institutional agreements on top of the EWP approval outside the network. In such exceptional cases, HEIs are encouraged to sign digitally and in full compliance with eIDAS legislation. It will also be added to all official EC documentation about IIAs. |
I think you have included in the mandatory business requirements a statement too generic.
"While different levels of electronic signatures may be appropriate in different contexts, only qualified electronic signatures are explicitly recognized to have the equivalent legal effect of hand-written signatures all over EU Member States." To have almost an Advanced electronic signature/seal (AdES) I think we have to consider XML AdES (XAdES) and not simply XML Signature. https://ec.europa.eu/digital-building-blocks/wikis/display/DIGITAL/eSignature+FAQ |
|
@pleys does EC considers "XML Signature" as a concrete legal proof? If so please let us know from whom in EC is this requirement coming from, so that we can directly talk to them and present our case. |
|
This topic is continued in #109. |
There are fields in the cooperation coditions that are not in the IIAs template. Those are:
Recently, there has been the idea that certain fields should be removed from the conditions-hash computations, because changing these fields would change the hash, but they do not contain information that should affect the validity of the agreement.
We believe that this should apply to fields sending-contact and receiving-contact, as the contact details of cooperation coordinators can indeed change.
However, we believe that the hash should take into account the field sending-ounit-id and receiving-ounit-id, because the faculties implementing cooperation conditions are unlikely to change. And if this happens (or the name of the organizational unit changes due to changes in the structure of the university), a new agreement should be signed in such a case.
Please comment if you think we should do it differently.
The text was updated successfully, but these errors were encountered: