Approval of an IIA #30
Comments
|
Ad. Method I Ad. Method II You write "However, they should use the same IIA-code." This condition is not met in the current specification. |
|
We would prefer a method 1 like approach. |
|
We also prefer a method 1. |
If we keep status for all the partners, than it seems a good idea. @georgschermann What do you think about our proposal where every partner sends only his own approval/status? |
|
I am not quite sure about this. It makes sense to only share someones own status, but for some edge cases it could come in handy to also propagate someone elses status, for example if you have 3 or more partners, or multiple faculties of one university, one of multiple partners not using EWP, ... |
|
But how can you be sure that you really know the current status of the opinion of the other partner? He might have changed his mind a couple of seconds ago. |
|
From the Minutes from the Technical meeting in Malaga (2019-09-12).
|
|
As agreed in the technical meeting in Málaga (12/09/2019), when an Institution creates a new IIA (or makes any change), hereinafter referred to as First Party, and sends the notification to the other institution, hereinafter referred to as Second Party, the First Party is automatically agreeing that the data is the correct data and will not be changed. Given this, the First Party must sign the data with a valid certificate, every time the Second Party gets this data. The signing process should be exactly the same as specified in he ToR Get API https://github.com/erasmus-without-paper/ewp-specs-api-imobility-tors/blob/master/endpoints/get.md . In summary, the following steps are needed.
|
|
Thank you. We will update the specification according to this proposal. |
That specification states that the certificate is not important, but
That is not always possible: in our case, the key and certificate to serve the API are managed by another team. What then should be the requirements for the certificate? |
|
Perhaps this could be used instead of embedded signatures. |
|
We see some problems with the solution described by Francisco. We wrote a short google document with the description of what we need and possible solutions (among others our comments to the Francisco's proposal). I will send you an email with a link. Please, comment. |
|
I wrote some comments in the document. One of the arguments against signing (only) PDF is that the PDF might not contain the same data as the XML (e.g. due to some error). Since the XML contains the master data (that is the purpose of this API), I think the XML should be signed. |
|
I added comments to your comments. My impression is that you miss the most important part, that - according to our opinion - the Francisco solution cannot be meaningfully implemented. If you think that it can, please explain how you see such an implementation. I hope that this will help us all to either notice deficiencies in the Francisco algorithm or maybe prove that we are wrong and the implementation is possible. We can discuss whether PDFs are better than XMLs, but that's not the biggest problem. I am afraid that the correct solution with XML signing would be just as or maybe even more complicated than LA, because the contracts are served by both parties. |
|
I think it would be easier if both parties just sign their own version of the agreement, and do not include the signature of the other party. That would eliminate most difficulties arising from using different element order, API version,... We already agreed that the agreement should not change once it is approved by both partners. If an field is to be added or removed, a new agreement must be created. If the API version is changed, the signature will change also. That should not be a problem, as it would not have an effect once the approval process is over. It is probably a good idea for both parties to keep the original signed XML. |
If each partner signs his own version, no partner has a proof that HIS version has been approved by the other party.
This is a real problem and it concerns not only HTTP Signatures. To solve it we should either use qualified certificates or store somewhere all keys in use any time by all partners (for example in the registry). This is a real challenge. To push the discussion forward we suggest that we first agree on the answers to the following questions:
|
That was one of the reasons why we log every registry change and allow people to replicate this log in a distributed Git-like fashion (although I cannot find the prod log for some reason, perhaps it wasn't configured?) In other words everyone should have access to fingerprints of all keys ever served by the registry. (Registry keeps this repository locally too, and it could run queries on it to help people find things.) |
Partner A fetches the signed version of partner B, and vice versa. Both versions should match, or there would be no agreement.
This applies to both XML and PDF. I would prefer CA-signed certificates over self-signed. But we still need to agree on which CA's are allowed. This hasn't even been decided for certificate-based server authentication.
Agreed, although that would be another discussion.
I have no strong opinion to whether we should or should not have (signed) PDF's. I agree signing XML has its challenges, but signing PDF and not XML incurs the risk of both versions deviating from each other. How would you guarantee that they are in sync? |
As I understand we started the whole discussion with the assumption that every partner needs to have the approval of his version of IIA of the other partner. Where is Paul? Where is George? Where is Francisco? There were so many opinions when we talked about that in Malaga and now only Bavo is interested in finding the solution? |
|
Hello, For what I have read I think we are mixing problems and different things. First, I think we should treat the IIA as a contract between parties, and as a contract, after signed, you can't just change content or add lines or any kind of alteration. So, as Bavo said, both versions of the XML should match so both parties can agree that they signed the same contract. Regarding the two parties signing the same XML or just one party, if both of them send to the other partner the agreement signed by them and it's saved as it is, I don't see a big problem with that. Both parties have proof that the other signed so. |
or I would rather say that we do not understand each other
That's obvious
That's also obvious but the problem is that we are not able to check that on a technical level, since semantically the two versions may be the same but represented by two different XML files. By the way - for that reason we still think that PDF is as good as XML and even better).
We do see the problem. It's not enough that every party signs his version, what we need is to approve the partner's version. So every partner should:
I would suggest to meet via Skype for a short talk to make sure that we do understand each other. |
|
I agree with a Skype meeting to agree to solve these issues. |
|
Bavo and all the others, will you be available for Skype on Monday, December 2nd, at 11:00 CET? |
|
Works for me. |
|
we would prefer PDF signatures for simplicity, the possibility of more than 2 signatures, the possibility of hand written or personal, digital signatures, the possibility for staff to view and verify the signatures, etc. Skype meeting works for me. |
|
Follow up on the Skype Meeting, please correct me if I got something wrong: The initial requirement we wanted to cover is, that Partner A can approve/verify Partner B's IIA Proposal. We think this should/could be achieved using a solution similar to method 1 and the EWP CNR/GET (vs. POST, discussed multiple times earlier) approach. We propose similar to method one to introduce an "approved" (or verified if preferred) timestamp.
We can use one shared The timestamps only add the possibility to check if the version the partner GOT earlier and approved will differ from the current version. (supposing the local last modified date of the IIA is stored) If a partner not approves an approved IIA, it can just omit the |
|
Seems logical and intuitive to me and in line with the Skype meeting, but of course I cannot see all the technical implications |
|
In this flow, isn't the partner is approving their own copy and not other partners copy? |
|
Georg, thank you very much for your input. I will try to explain why - in our opinion - it will not work. 1 We agree that we need an approval. Strictly speaking we need to know: Because of "what" neither version number nor timestamp is sufficient . 2 We can use: 2.1 hash (or fingerprint) - exactly as we already use in LA Final proposal to solve (1) --> Let's use hash.
Assumption: We are in favor of PUSH for several reasons: 2.1 PUSH allows us to obtain two goals in one simple synchronized call: 2.2 In case of CNR/GET we always have to keep in database the data we approve (GET can be invoked any time). In case of PUSH we push the data, which can be generated dynamically at our convenience. 2.3 Extensions needed in APIs specification 2.4 The scenario of data exchange 2.4.1 PUSH to endpoint approved PUSH is synchronous, we get the confirmation in a transactional way with error code 200 (everything is OK, A has got approval) or 409 (A has got an approval but the version approved is outdated) or 400/500 (some other error or timeout). 2.4.2 New APIs PARTNER_IIA_CNR/PARTNER_IIA_GET Final conclusion on (2) --> GET/CNR could also be used but is more complicated. We opt for PUSH, as it is simpler to specify, simpler to implement and compliant with the current version of LA. If we would replace PUSH with CNR/GET for IIA, we would still have PUSH in LA. If you would argue that PUSH should be replaced by CNR/GET in LA it would make LA even more complicated than it is now. |
|
But we recommend PUSH :) |
|
What do you think about our arguments and our solution? @umesh-qs, @fmapeixoto, @BavoNootaert, @georgschermann, the others? It will be easier to talk on Monday when we exchange arguments before. I will prepare an example scenario. |
|
Currently there is one simple example scenario. If I write more scenarios, I will put them in the same catalogue. |
|
In response to Janina's arguments above (#30 (comment)): |
|
Your response refers to the "Push vs. CNR" problem. We will try to answer soon. |
|
After thinking about implementation of our solution on the client side we noticed that the user needs to know:
To solve this issues we need to store the fact of approval and what has been approved (hash). We need to store this for every partner agreement and map it by partner agreement ID. In other words we would have all the information needed to implement GET in Partner Agreements Approval API. No point in not sharing this data with the partner. As for the question of adding the approval to IIAs GET method we don't think this is possible as it would require the approved partner to already have the mapping from partner's agreement ID to his own. It makes more sense to create a separate API for approvals and use ID's of the approved agreements. This also doesn't require agreements to always map 1 to 1. Having a separate API for approvals, it doesn't seem justified to use PUSH for sending an approval, as there aren't enough arguments for it. For example, knowing immediately that the partner agreement has changed doesn't solve an issue of the change happening just moments after the approval. |
|
We agreed to use hash and to use CNR and GET for sending approval. The last thing is to decide if we add the acceptance to the existing API or we add new API(s). Here you can find example scenario in this two approaches: https://github.com/erasmus-without-paper/ewp-specs-api-iias/tree/acceptanceExamples/example-scenarios |
|
Could you give an example where the agreements don't map 1 to 1? |
|
I can write something, but I'm not sure if it will be a real life scenario. I tried to find why we started to consider agreements which don't map 1 to 1 and found emails from tests with SOP. They are/were saving recurring agreements as one. @georgschermann do you still do this way? How will the acceptance process look like? Saving recurring agreements as one probably means that at some time you change a signed agreement. Maybe we shouldn't allow this? |
|
Yes, our internal agreements roughly correspond to the cooperation conditions, so 10 of our agreements are summarized to one iia, or the other way round. |
|
Having a seperate API for approval is OK for us. |
|
What about the others? @fmapeixoto, @umesh-qs? As I remember Georg said he can accept any version (separate API or field in existing API). Do we need this skype meeting that we have planned for today? |
|
If everyone agrees I don’t think we need to do it. I don’t have a problem on having 2 different endpoints.
Best regards,
FRANCISCO PEIXOTO
Segurança Informática / Information Security
Praça Gomes Teixeira
4099-002 Porto. Portugal
Tel. : +351 22 0408 721
Email: fpeixoto@uporto.pt <mailto:fpeixoto@uporto.pt>
… On 12 Dec 2019, at 09:23, Marta Juzepczuk ***@***.***> wrote:
What about the others? @fmapeixoto <https://github.com/fmapeixoto>, @umesh-qs <https://github.com/umesh-qs>? As I remember Georg said he can accept any version (separate API or field in existing API). Do we need this skype meeting that we have planned for today?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#30?email_source=notifications&email_token=ANN3VPD4HYAFY5UGXVMTXR3QYH7I5A5CNFSM4IS3UA2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGWAK6A#issuecomment-564921720>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ANN3VPACXIKBLPJ27RG2LX3QYH7I5ANCNFSM4IS3UA2A>.
|
|
The draft version of the new IIA Approval API is available at: There is still an issue how to handle PDFs. We see two options:
Consequences:
Option 2
Consequences:
Which one do you prefer? Do you see other options we should consider or other consequences which should be taken into account? |
|
@janinamincer-daszkiewicz if we talk about PDF created by us, does that mean it is signed by us? If both partners have the same data in their system, the PDF's (based on EC template) should look exactly the same whoever generates it right? |
|
In theory yes. But visually they may differ e.g. having different logos. For some reason Georg asked for the possibility to send separate PDFs. @georgschermann could you give us examples? |
|
I would prefer Option 1, because then the PDFs in each API reflect the meaning of the corresponding XML-document. Both options could possibly support multiple PDFs. |
I think we shouldn't include logos and other additional elements on the agreements and stick to the EC template and the data included on this template. In my view the PDFs are only relevant for IRO users who need to get used to a new way of dealing with agreements. They are used to support users in the transition to a new way of working and can become obsolete once a digital workflow is generally used, trusted and accepted. |
|
|
Sorry, probably a misunderstanding from my part. I thought
meant that multiple PDFs were required, but perhaps you meant just one PDF from each partner. In any case, as Paul said, we are not asking for any special features regarding PDF documents. But if they are to be supported by the API, then I think Option 1 is the cleaner solution. |
|
I think it would be 1 PDF for each partner at most. Some of our Universities use the E+ template, but some extend or adapt the template, use their logo, add more signature fields, additional information or be more specific on the conditions, etc. Some Universities won't allow any contracts/agreements which are not signed by various responsible persons. And the IROs cannot force the rectors or staff from other faculties, etc. to use any software tool they have. Getting a digital signature onto a PDF is the most digitization some can hope for at the moment. In some cases it may also end in print & re-scan. So for the time being the lack of PDFs would be a show stopper for some. I'll ask some of our customers if the have example agreements. For the implementation I think we would also prefer Option 1 |
|
Currently SIGMA generates the PDF according to the template, we do not add logos or more information. |
|
Marta, I think we can continue with the specification. |
|
Done: |
Scope: supporting the process of approving an IIA.
Out of scope: Discussion about the contents.
We have two different proposals. Of course, EWP should support only one method, either one of those below, or another one that evolves from these after discussion.
In both methods we follow the principals of this issue. We stick to IIA3 distributed, no-master, meaning that everybody is master of its own data. And this data can be duplicated by both parties.
Method I
Approval can be supported by including a status associated with the SCHAC-code of the approving partner in the current IIA API.
One of the partners enters the data into its system, and sends a notification to the partners. The IIA at that point contains an approval status from that one partner.
If the other partners agree, they enter the data in their system, and add their own approval status. A notification is sent to the partners.
The partners that have already approved, compare if the contents of the IIA they have in their local system is equal to the one the notification is sent for. If it is, the approval by the other partner is recorded in their local system. If it is not, the local system must report an error, and discussion should follow through some other medium.
In multilateral agreements, at a certain time the different partners may have different sets of approving partners, as notifications are being sent and processed. However, since the data itself is never changed, and approvals are only being added, this will stabilize after a little while.
In xml, the status element should contain the status APPROVED (different statusses may be needed in the future, see also the proposal about amendments), and the SCHAC-code of the approving partner.
If necessary, this element would be the place to add a signature of the approved data.
Example.
Suppose X and Y have agreed upon a proposal, and X first enters the data.
The iia element would look like this (only the relevant elements are included):
After review, Y adds its own status:
Method II
The approval proces could be considered a pattern that we will probably need more often. Maybe we can treat it in a general way like we have CN. We actually have an example already with the mobilities.
The difference between IIA and mobitilies is that incoming mobilities that are not communicated through the network, remain invisible to the network. Therefore every mobility is known by one ID inside the network. In the case of IIA both parties can expose the same IIA with different ID's. However, they should use the same IIA-code.
The approval proces consists of:
So in addition to the IIA and CNR-API we would need an API with corresponding CNR-API that we can use to report the status of the IIA.
The API could expose an entity like StatusUpdate(datetime of the statusupdate, hei-id of the status,surrogate-id of the IIA, version, comment, status).
Each HEI remains the master of its decision about the IIA, i.e. whether it approved or rejected the proposal
Example.
Initiator X creates IIA with surrogate ID "X-1" and version 1 and sends a IIA-CN to all partners (there is a single partner Y in this example).
Collaborator Y receives IIA-CN, creates
and sends a StatusUpdate-CN to all partners
Initiator X receives the StatusUpdate-CN and updates IIA and sends a IIA-CN for version 2 to all partners.
Collaborator Y receives IIA-CN, creates
and sends a StatusUpdate-CN to all partners
Initiator X creates
and sends a StatusUpdate-CN to all partners
It is possible that two hei's X and Y create an IIA that are in fact the same. In that case they can agree to approve only the one from X or only the one from Y, or both.
The text was updated successfully, but these errors were encountered: