Convey both IIA ids in IIAs Approval get

[jiripetrzelka]

This suggestion appeared in the last infrastruture meeting but did not have a GitHub issue so I am creating it and adding that I think this change would be very useful for proper IIA matching.

[umesh-qs]

Providers would have already done the matching at the IIA level much before the approval. From matching perspective this seems to be redundant change

[sascoms]

@umesh-qs Not always.

If the partner sends first a normal IIA CNR, yes, the matching is done at that step.

However, there has been many cases where we only received an approval CNR, and not a normal IIA CNR.

And since there was no IIA CNR, our HEI could not approve the partner's copy as they do not know the partner's IIA ID.

We experienced this issue many times especially with dashboard. Although, the dashboard-developers informed that they accompany an direct approval CNR with a normal IIA CNR, that was not the case for many times unfortunately.

If the partner receives an IIA CNR first, or an accompanying IIA CNR with an approval CNR, it is redundant maybe.

But in the case I mentioned, it will directly help to match the IIAs.

[umesh-qs]

Honestly we are not here to solve problems with Dashboard, if any. You must reach out to them for fixing this.

[umesh-qs]

Also we shouldn't rely on CNR only. What if both CNR are not received. Better provide an option for manual refresh to your client for such cases.

[sascoms]

There are always workarounds but that is mainly a design and workflow problem.

[umesh-qs]

But we are not fixing the design with this change. This solution is sort of another workaround. What if approval CNRs are missed by either party? How do you interpret the response then?

[kkaraogl]

@sascoms I agree with how Eser described the issue at hand.

@umesh-qs this is a universal issue that affects all of us. It is not Dashboard related only.

[umesh-qs]

@kkaraogl universal issue that IIA CNR are not coming and approval CNR are coming? Sorry I didn't get. What will be the use of this solution if IIA approval CNR does not work

We are not in support of creating a change that itself might not work, to fix something that should ideally work.

[kkaraogl]

@umesh-qs matching the copies of the same IIA between the two parties' systems, by successfully exchanging both iia-ids. This is the issue at hand.

[umesh-qs]

@kkaraogl got the point. But why would you call the approval API if there is no approval CNR?

[kkaraogl]

@umesh-qs Sorry, I can't follow you. I never wrote about calling the approval, if there is no approval CNR.

The issue discussed here occurs when the partner sends an approval CNR, and they haven't previously communicated their own iia's id, with an IIA CNR.

[umesh-qs]

What I am saying is that you are trying to solve CNR issue of IIA API, using the CNR of IIA approval API. Even though it will reduce some of the problems, it is not a full proof solution There will still be problems if approval CNR is also not received or the approving partner has not linked the IIAs.

Better to fix the CNR issues and provide manual refresh to your clients.

[janinamincer-daszkiewicz]

This is a summary of brainstorming we have had internally.

1. In case of IIAs we have Master-Master situation and this is the appropriate model.
2. We already accepted that both partners need to publish their copies of IIA before approving.
3. In most cases there is a distinction between the first IIA and the partner IIA that has been created based on the first one. The second IIA is required to contain the ID of the first IIA, but there is no technical solution to impose that.
4. There is also a slight possibility that both IIAs have been created without the knowledge of each other’s presence.
5. Before an approval is being made both partners should match the IIAs based on the notification about partner IIA (IIA CNR).
6. Such matching should be a prerequisite to partner IIA approval.
7. Both IIAs would theoretically be never matched only if both IIA CNRs were missed. If at least one of the IIA CNR reaches the partner, then we can assume that he will make the matching and, in consequence, issue a IIA CNR with this matching.
8. An option for manual refresh may indeed help (also with lost CNRs). I have already seen in production servers which have been put down for a couple of days. How many times should you repeat sending CNRs to them before giving up?
9. It has been suggested that, even if a matching is made a prerequisite to IIA approval, then we should require to add the partner ID to the approval response.
10. That solution makes IIA approval contain a copy of the ID matching which, by specification, should already be contained in the IIA response. However this matching might become inconsistent in those two places.
11. The benefit of the solution (as mentioned in discussion and GitHub) is that it enforces (on a technical layer) that an ID matching has to be passed to create a valid IIA approval response (if someone validated the response with a XML schema). Still it wouldn’t enforce that an IIA response would contain the ID matching (and that it is consistent if provided).
12. We have to remember that IIA approval CNR cannot be rejected as per specification.
13. There is also no way for the approving party to know that an IIA approval has been acknowledged.
14. That means that if the partner erronously sends us IIA approval CNR before sharing his IIA id with us we have no other means to react than:

• accept CNR,
• do not fetch IIA approval,
• inform the partner outside EWP about the situation.

Our proposal is the following:

1. Describe in specification that this is obligatory to share the own IIA id with the partner as soon as possible and that sending IIA approval CNR before having in own system both ids is an error.
2. Do not add value for the own id in IIA approval response.
3. Come back to the idea of one simple text field in IIA to share short messages with the partner (equivalent to SMS not WhatsApp). This issue is discussed in https://github.com/erasmus-without-paper/general-issues/issues/38.

Pros of 1 and 2 above are that most of the providers already implement IIAs in such a way and they don't have to make any changes.

If you want to support (3) let's do it in the other issue.

[janinamincer-daszkiewicz]

During the Infrastructure Forum on 2022-04-06 most participants agreed with 1, some agreed with 2, there were mixed opinions about 3.

We propose to add new update endpoint to https://github.com/erasmus-without-paper/ewp-specs-api-iias/tree/stable-v6/endpoints:

• parameter: iia id
• fields: timestamp, comment

It would be up to the receiver to decide how the comment is handled in the local system.

[janinamincer-daszkiewicz]

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.

During the Infrastructure Forum meeting on 2022-11-16 the providers will vote if we want to introduce:

1. Update endpoint described in https://github.com/erasmus-without-paper/ewp-specs-api-iias-approval/issues/3#issuecomment-1114008774.
2. Local IIA id in IIA Approval get as discussed in this issue.

[janinamincer-daszkiewicz]

Infrastructure Forum meeting 2022-12-14. We voted the proposal to have both identifiers in IIA Approval. The voting results:

• YES: 11 providers
• NO: 0 providers

(the results of voting are summarised in an Excel file uploaded to the IF shared drive).

We will prepare the changes in specification.

There were two voices about current state of approved IIAs. Mappings are not stored for 'old' IIAs, we need to discuss how to solve this issue. I do not close this issue. Please continue on this topic here.

[demilatof]

Just a question: on EWP infrastructure, we may have or not more than an IIA bound to another single IIA? Where should we have both identifiers? In IIA Approval, in IIA Approval response, in IIA Approval request or already in Approval CNR?

Because we may have this scenario: a partner has two IIAs (A1 and A2) that it needs to bind to a single IIA with B1 Id. When A is ready to approve the partner's IIA now it sends an Approval CNR with only B1 Id in the request (plus HEI Ids). B replies calling A's Approval API; in the request B indicates its IIA Id, that is B1, but none of the A's IDs (A1 or A2).

Therefore A what should approve? B and what else? If the new specification takes care of only the Approval response, A cannot know what should add: A1 or A2? If B can call A's Approval API putting its ID and A's IDs, B must previously know what IDs A has used to map B1 ID. To know the exact ID, it should receive a CNR with both IDs: A1 and B. Are we considering of specifying both IIA IDs even in theApproval CNR?

But this could not be enough for A partner, that probably should send a second Approval CNR with A2 and B IDs. Are we sure that B system, in the current implementation, can accept two different Approval CNR (B1-A1 and B1-A2) for the same IIA?

PS: we may have a similar problem with the IIA Get. Let assume that B is able to have two copies of the same IIA: one with B1 and A1 Id, the other with B1 and A2 Id. When A performs an IIA Get asking for B1 Id, which copy should B return? The one with A1 Id or the one with A2 Id?

This is not a problem of the local implementation, this is an issue for the EWP specifications. In my opinion, there are only two possibilities:

1. We can have more IIAs bound to a single IIA and then the EWP specifications musts consider them at every level (IIA CNR, IIA Get, Approval CNR, Aprroval)
2. The specifications should state the we cannot have more IIAs bound to a single IIA.

[umesh-qs]

@janinamincer-daszkiewicz can you please elaborate how this change is helping? It is only making life of institutions difficult for existing approvals in the system.

[umesh-qs]

Just a question: on EWP infrastructure, we may have or not more than an IIA bound to another single IIA? Where should we have both identifiers? In IIA Approval, in IIA Approval response, in IIA Approval request or already in Approval CNR?

Because we may have this scenario: a partner has two IIAs (A1 and A2) that it needs to bind to a single IIA with B1 Id. When A is ready to approve the partner's IIA now it sends an Approval CNR with only B1 Id in the request (plus HEI Ids). B replies calling A's Approval API; in the request B indicates its IIA Id, that is B1, but none of the A's IDs (A1 or A2).

Therefore A what should approve? B and what else? If the new specification takes care of only the Approval response, A cannot know what should add: A1 or A2? If B can call A's Approval API putting its ID and A's IDs, B must previously know what IDs A has used to map B1 ID. To know the exact ID, it should receive a CNR with both IDs: A1 and B. Are we considering of specifying both IIA IDs even in theApproval CNR?

But this could not be enough for A partner, that probably should send a second Approval CNR with A2 and B IDs. Are we sure that B system, in the current implementation, can accept two different Approval CNR (B1-A1 and B1-A2) for the same IIA?

PS: we may have a similar problem with the IIA Get. Let assume that B is able to have two copies of the same IIA: one with B1 and A1 Id, the other with B1 and A2 Id. When A performs an IIA Get asking for B1 Id, which copy should B return? The one with A1 Id or the one with A2 Id?

This is not a problem of the local implementation, this is an issue for the EWP specifications. In my opinion, there are only two possibilities:

1. We can have more IIAs bound to a single IIA and then the EWP specifications musts consider them at every level (IIA CNR, IIA Get, Approval CNR, Aprroval)
2. The specifications should state the we cannot have more IIAs bound to a single IIA.

@demilatof only 1-1 mapping is allowed for IIA.

[demilatof]

@demilatof only 1-1 mapping is allowed for IIA.

Maybe I'm wrong, but this is not yet mandatory. I asked here but, unluckily, the discussion was closed before receiving an answer. Anyway @janinamincer-daszkiewicz didn't tell me that the 1-1 mapping is compulsory. I remember a thread, but now I cannot find it, where it was stated that until now it's not compulsory the 1:1 mapping, maybe from 2023. If you have a link to specifications where it's clear that 1-1 mapping is mandatory could you share with us?

[umesh-qs]

@demilatof Please see "9. IIA interoperability - mandatory business requirements" in below document

https://github.com/erasmus-without-paper/ewp-specs-api-iias/blob/stable-v6/resources/mandatory_business_requirements_IIA.pdf

[demilatof]

@demilatof Please see "9. IIA interoperability - mandatory business requirements" in below document

https://github.com/erasmus-without-paper/ewp-specs-api-iias/blob/stable-v6/resources/mandatory_business_requirements_IIA.pdf

@umesh-qs thanks for the link; do you mean this paragraph? I think that it is quite new and that there wasn't in the previous version, but again I may be wrong.

The copy of the agreement stored in each partners' systems must be presented to each other via the IIAs API as exactly one IIA having the same number of corresponding cooperation conditions.

It may state that there must be 1-1 mapping for each agreement, but only as concern the cooperation conditions. In my opinion it is not clear about the fact that a party has 2 agreements and the other party only one. Should the first party join their agreement in only one IIA or the second party has to split its IIAs?

[janinamincer-daszkiewicz]

@janinamincer-daszkiewicz can you please elaborate how this change is helping? It is only making life of institutions difficult for existing approvals in the system.

This will eliminate the situation that happened surprisingly often in the past and still happens where the institution A sent Approval to institution B while institution B did not yet have the local identifier of institution A.

[janinamincer-daszkiewicz]

@demilatof https://github.com/erasmus-without-paper/ewp-specs-api-iias#important-rules

This topic was discussed at Infrastructure Forum meetings for some time, see the presentations in the shared drive.

[demilatof]

I thank you both for finally addressing me in the right direction.

May bad, but I don't find much linear the process of changing the specification. I see that the "Important rule" change was commited on 2 may, but on 4 may we were still discussing about something slightly different (p. 14):

Change approved. Generally 1:1 logic and matching identifiers. Proposal of text to be added to specification

https://owncloud.erasmuswithoutpaper.eu/index.php/s/zyNXSfU78NMtULf?path=%2F2022-05-04_Infrastructure_Forum#pdfviewer

That is, someone changed the specification and 2 days later we were told "Proposal of text to be added". If a text is under proposal, and in chat someone even asked to postpone it to 2023, I don't go up and down to check if something was changed in requirements. I don't see in the chat of the 4 May any result about this poll.

The following forum (25 May) the slides said that "These changes will be issued soon" whilst they were already issued on 2 May. A link to where they had been written would have been appreciated.

For the future, I hope in a better communication when there are important changes in requirements. I'm a developer and while I'm developing I pay much attention to the get-response.xsd and this doesn't still say anything about 1-1 mapping.

[demilatof]

@janinamincer-daszkiewicz can you please elaborate how this change is helping? It is only making life of institutions difficult for existing approvals in the system.

This will eliminate the situation that happened surprisingly often in the past and still happens where the institution A sent Approval to institution B while institution B did not yet have the local identifier of institution A.

I don't understand where is the magic, this solution will not eliminate anything in my opinion. B can always perform an IIA Get to download A's IIA and retrieves A's IIA Id to add to its own IIA. If B doesn't care of doing so, why should it care of A's IIA Id when it receives it with with the approval?

Maybe you mean adding both IIA Ids in B's request to A's Approval API? This may be a way to force B to know A's IIA Id, but there is no warranty that B adds the A's IIA Id to its IIA.

The only way I see to force B to add A's IIA Id is to not send Approval CNR to B and to deny approval if received a request for it without a previous Approval CNR.

The A approval response is conclusive: what happens if A gives the wrong IIA Ids or doesn't give its IIA Id at all?

[umesh-qs]

@janinamincer-daszkiewicz can you please elaborate how this change is helping? It is only making life of institutions difficult for existing approvals in the system.

This will eliminate the situation that happened surprisingly often in the past and still happens where the institution A sent Approval to institution B while institution B did not yet have the local identifier of institution A.

I don't understand where is the magic, this solution will not eliminate anything in my opinion. B can always perform an IIA Get to download A's IIA and retrieves A's IIA Id to add to its own IIA. If B doesn't care of doing so, why should it care of A's IIA Id when it receives it with with the approval?

Maybe you mean adding both IIA Ids in B's request to A's Approval API? This may be a way to force B to know A's IIA Id, but there is no warranty that B adds the A's IIA Id to its IIA.

The only way I see to force B to add A's IIA Id is to not send Approval CNR to B and to deny approval if received a request for it without a previous Approval CNR.

The A approval response is conclusive: what happens if A gives the wrong IIA Ids or doesn't give its IIA Id at all?

I agree with @demilatof . This is not going to help. If IIA is not linked for some reason the approval will still not contain both IIA. @janinamincer-daszkiewicz do you believe that IIA will not be linked in IIA GET and will still be linked in IIA Approval? Only solution for this is for individual system to enforce this and not to accept approval. This proposal has no added value with changes of data discrepancy between IIA GET and IIA Approval and hence making everyone's live more difficult. Seems to be driven by overenthusiasm then logic. This is also same as having a IIA comment API and also keeping comments in IIA GET.

[umesh-qs]

I thank you both for finally addressing me in the right direction.

May bad, but I don't find much linear the process of changing the specification. I see that the "Important rule" change was commited on 2 may, but on 4 may we were still discussing about something slightly different (p. 14):

Change approved. Generally 1:1 logic and matching identifiers. Proposal of text to be added to specification

https://owncloud.erasmuswithoutpaper.eu/index.php/s/zyNXSfU78NMtULf?path=%2F2022-05-04_Infrastructure_Forum#pdfviewer

That is, someone changed the specification and 2 days later we were told "Proposal of text to be added". If a text is under proposal, and in chat someone even asked to postpone it to 2023, I don't go up and down to check if something was changed in requirements. I don't see in the chat of the 4 May any result about this poll.

The following forum (25 May) the slides said that "These changes will be issued soon" whilst they were already issued on 2 May. A link to where they had been written would have been appreciated.

For the future, I hope in a better communication when there are important changes in requirements. I'm a developer and while I'm developing I pay much attention to the get-response.xsd and this doesn't still say anything about 1-1 mapping.

I do agree that this should be described in the IIA GET specifications.

[janinamincer-daszkiewicz]

@demilatof

B can always perform an IIA Get to download A's IIA and retrieves A's IIA Id to add to its own IIA.

B can not because in 'bad' scenario B does not know the A’s IIA id yet.

Maybe you mean adding both IIA Ids in B's request to A's Approval API?

I mean adding both IIA Ids to the IIA Approval response.

This may be a way to force B to know A's IIA Id, but there is no warranty that B adds the A's IIA Id to its IIA.

That would be an implementation error.

The only way I see to force B to add A's IIA Id is to not send Approval CNR to B and to deny approval if received a request for it without a previous Approval CNR.

There is no way to deny approval (other than making changes in IIA and sending IIA CNR).

The A approval response is conclusive: what happens if A gives the wrong IIA Ids or doesn't give its IIA Id at all?

If we make both IIIA Ids mandatory, not giving it would be an error.

@umesh-qs

If IIA is not linked for some reason the approval will still not contain both IIA. @janinamincer-daszkiewicz do you believe that IIA will not be linked in IIA GET and will still be linked in IIA Approval?

@kkaraogl can give many examples of such behaviour. They tested with many partners and in many cases IIA Approvals were sent BEFORE the partners shared IIA Ids

Only solution for this is for individual system to enforce this and not to accept approval.

There is no easy way not to accept the approval.

Seems to be driven by overenthusiasm then logic.

Voting was conclusive: 14 against 0.

[demilatof]

@janinamincer-daszkiewicz

B can always perform an IIA Get to download A's IIA and retrieves A's IIA Id to add to its own IIA.

B can not because in 'bad' scenario B does not know the A’s IIA id yet.

I always put my design in worst case. There is no 'good' scenario in which B can know A's IIA ID in EWP infrastructure.

In EWP infrastructure, B can know A's IIA ID only in two ways:

1. receiving A's IIA-CNR
2. calling A's IIA-Index

In both cases is the B's officer that look for the right A's Id scrolling the list of all A's IIA (retrieved one by one calling A's IIA-Get). And even if A states that its X Id is bound to B's Y id, B's officer can decide otherwise. Therefore is useless to add both IDs to Approval Response. Unless someone wishes to rely on the other party's decision just to do less work.

Maybe you mean adding both IIA Ids in B's request to A's Approval API?

I mean adding both IIA Ids to the IIA Approval response.

The IIA Approval response is conclusive and useless, I think this is a bad solution. Doing so we don't solve the present weakness in the design, we just add an extra one. Currently the A's Approval response can contain the wrong hash (e.g. the hash of an old IIA, not the last one) and B cannot do anything. We really want to add the risk that A adds a wrong IIA ID and B cannot do anything again? Anyway, how can you trust that after that B adds the suggested ID to its IIA?

This may be a way to force B to know A's IIA Id, but there is no warranty that B adds the A's IIA Id to its IIA.

That would be an implementation error.

Until there aren't specifications that states what a provider must check or do before calling an API there will always be an implementation error.

The only way I see to force B to add A's IIA Id is to not send Approval CNR to B and to deny approval if received a request for it without a previous Approval CNR.

There is no way to deny approval (other than making changes in IIA and sending IIA CNR).

This is a weakness in the analysis and in the specifications; an approval should be deniable. Anyway the specifications already provides how to manage invalid parameters:

Values of iia_id that are not known by the server as owner_hei_id's agreements or not approved (yet or at all) MUST be ignored. Servers MUST return a valid (HTTP 200) XML response in such cases, but the response will simply not contain any information on these missing entities

Therefore the solution already exists and is quite simple: if B calls A's Approval API with an IIA-ID that represents an IIA, without both IDs, A not only can ignore it (soft deny) but A MUST ignore it, because A is not ready to approve it. Where is the problem we are discussing about?

The A approval response is conclusive: what happens if A gives the wrong IIA Ids or doesn't give its IIA Id at all?

If we make both IIIA Ids mandatory, not giving it would be an error.

It would be an error not giving both IDs, but it would not be an error giving wrong IDs

[demilatof]

I'll try to recap because I think we are trying to solve a problem in the wrong way without solving it at last. To be clear, I voted to add both IIA IDs in approval response because it's not a problem for me to add both of them, not because I think that they could be helpful. I think that the biggest mistake is to think, or to hope, that local ID can be added by the system and not by a human operator.

Anyway the problem we aim to solve seems to be the one described by @janinamincer-daszkiewicz :

This will eliminate the situation that happened surprisingly often in the past and still happens where the institution A sent Approval to institution B while institution B did not yet have the local identifier of institution A.

In my opinion, this is not a common problem, but a problem for who are not following the EWP Specification. To be clear, why we may have a scenario where A sends an approval to B if B's IIA doesn't contain both IDs? Most probably it is A that skips some checks.

As described by EWP flow chart, it's upon A to decide when it is ready to approve B's IIA and therefore B should not ask for an approval by itself. Therefore A should not send an Approval CNR if it has a copy of B's IIA that doesn't contain both IIA IDs. (Please note: A can track if it has sent an Approval CNR for a given HEI_ID-IIA_ID-Hash_code. If someone doesn't save this information then this is its own internal problem).

If B calls A's Approval API anyway, without a previous Approval CNR (e.g. because B is worried about having missed the Approval CNR), what A should do? It's explained here:

**Values of iia_id that are (...) not approved (yet or at all) MUST be ignored. Servers MUST return a valid (HTTP 200) XML response** in such cases, but the response will simply not contain any information on these missing entities.

This is a soft denial that the specifications take into account. Therefore, it is wrong to say that you cannot deny an approval. But even if someone wants to try to accept the Approval request anyway, the above remembered EWP flowchart strongly states:

This digest MUST be verified by HEI B (A in our example) before sending the approval. For this purpose, HEI B (A in our example) 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

Therefore, A MUST call the B's IIA-GET API, retrieve B's IIA and check if the hash is the same before sending the approval (and not before calling B's Approval CNR API: this is a huge error in the flowchart!). Since A has an updated copy of B's IIA, A can check if now B's IIA contains both IDs. If so (and the hash is the right one), A can accept B's call to Approval API, otherwise we are back in the case that IIA ID represents an IIA that cannot be approved.

To summarize, EWP specifications already allow us to not approve IIAs that lack of both IIA IDs, we don't need to change anything. We only have to specify (again) that some checks are mandatory and the internal systems just have to implement all the necessary steps.

Of course, if we could add a message in the Approval answer for "Invalid Parameters" when we cannot give an approval, it would be a great improvement. But please, don't over complicate the model for everyone only to solve the problems of some internal implementation.

PS: doing so, we also avoid that someone gives an approval for an old IIA, that is for an IIA with the same IIA Id we sent calling Approval API, but an old hash code (that means a different version)

[umesh-qs]

@demilatof

B can always perform an IIA Get to download A's IIA and retrieves A's IIA Id to add to its own IIA.

B can not because in 'bad' scenario B does not know the A’s IIA id yet. @janinamincer-daszkiewicz .. it is a problem with A's system then. Same situation can arise when I do not pass both IIA in IIA approval. What will you do then. Come up with another shady solution? You cannot solve problems that are caused by individual systems.

Maybe you mean adding both IIA Ids in B's request to A's Approval API?

I mean adding both IIA Ids to the IIA Approval response.

This may be a way to force B to know A's IIA Id, but there is no warranty that B adds the A's IIA Id to its IIA.

That would be an implementation error. @janinamincer-daszkiewicz same logic goes with IIA GET. Point is if the system does not have IIA mapped in IIA Get then this solution is not going to help. Same system what cause issue in IIA GET will continue with IIA Approval.

The only way I see to force B to add A's IIA Id is to not send Approval CNR to B and to deny approval if received a request for it without a previous Approval CNR.

There is no way to deny approval (other than making changes in IIA and sending IIA CNR).

@janinamincer-daszkiewicz so is there a way to reject the approval response that does not have both IIA ID?

The A approval response is conclusive: what happens if A gives the wrong IIA Ids or doesn't give its IIA Id at all?

If we make both IIIA Ids mandatory, not giving it would be an error.

@janinamincer-daszkiewicz how is the error identified and communicated. This is exactly similar to earlier situation where an approval is in error of IIAs are not bound in IIA GET

@umesh-qs

If IIA is not linked for some reason the approval will still not contain both IIA. @janinamincer-daszkiewicz do you believe that IIA will not be linked in IIA GET and will still be linked in IIA Approval?

@kkaraogl can give many examples of such behaviour. They tested with many partners and in many cases IIA Approvals were sent BEFORE the partners shared IIA Ids

Only solution for this is for individual system to enforce this and not to accept approval.

There is no easy way not to accept the approval.

Seems to be driven by overenthusiasm then logic.

Voting was conclusive: 14 against 0.

@janinamincer-daszkiewicz well at that time we thought it will solve the proposed problem. But looks like it is not. Also there was a discussion on how to handle existing approvals that happened before this mandatory IIA condition was introduced. So voting was based on this and if the solution is not solving the problem proposed then voting has no meaning.

[skishk]

hello to everyone,

just to be sure that i understand well: 1) will we add both IDs in approval response to approve the partner's IIA?

2) so we ignore the hash code? that means no changes allowed (if no one already approved)?

2.1) so we exposing something that is the definitive version so it does not require approval?!

i think approval must be done on a specific version of IIA (so we need to use condition-hash that determinare specific condition of the IIA, that we already have and use) and before sending the approval to partner we must call IIA-GET and check if we are approving the right version (checking condition-hash) or not.

it's easy solution with already existing implementation, so no one need to implement new code, just using what already everyone have and use.

[janinamincer-daszkiewicz]

@skishk

so we ignore the hash code?

No, we don't.

i think approval must be done on a specific version of IIA

Of course

it's easy solution with already existing implementation, so no one need to implement new code, just using what already everyone have and use.

Yes, so why there are so many wrong implementations? We are trying to fight against them.

@demilatof

To summarize, EWP specifications already allow us to not approve IIAs that lack of both IIA IDs, we don't need to change anything.

I agree with the first part, but looking at the voting results majority of providers do not agree with the second. We still have a number of incorrect implementations which send approvals before matching identifiers. The change will help to reject them. Response without both identifiers will not parse/validate against schema.

@umesh-qs

Also there was a discussion on how to handle existing approvals that happened before this mandatory IIA condition was introduced.

Yes. Ghent declared they will solve the problem by themselves. Let's talk how to solve the problem of QS.

[demilatof]

To summarize, EWP specifications already allow us to not approve IIAs that lack of both IIA IDs, we don't need to change anything.

I agree with the first part, but looking at the voting results majority of providers do not agree with the second. We still have a number of incorrect implementations which send approvals before matching identifiers. The change will help to reject them. Response without both identifiers will not parse/validate against schema.

I think that most of them answered like me: "I've no problem to add both IDs in approval response, you want it, I'll give you". But my collaboration ends here; I'll ignore the extra information when I'll call an approval API, because I would no be able do anything if it is wrong (e.g.: my IIA contains X and Y IIA IDs, the approval answer contain X and Z and this answer is conclusive)

And you should explain us how adding both IDs can solve the problem of incorrect implementations which send approvals before matching identifiers. With your solution the approval is given anyway, you don't reject anything. We can reject only with an empty answer, not with an approval containing both IDs.

Once you have given the approval, the partner's IIA is approved. How can you think that it will add both IIA IDs in its IIA if it haven't done before?

The only way to compel it to add the missing information is not giving the approval.

I think that who complains about this problem should show us an example and tell us if it performs an IIA-Get before answering to an approval or if it makes any other control (e.g. does it check if it has sent an Approval-CNR before? If it hasn't sent an Approval-CNR it was not ready to approve, therefore we have two bad implementation if it approves anyway, not just one). If you don't like an IIA-Get between the calling to Approval API and Approval response, you should think to add hash code in the request to Approval API.

[umesh-qs]

I agree with the first part, but looking at the voting results majority of providers do not agree with the second. We still have a number of incorrect implementations which send approvals before matching identifiers. The change will help to reject them. Response without both identifiers will not parse/validate against schema.

@janinamincer-daszkiewicz I would like to mention again that the voting was on the trust that the network has given you to solve the problems at hand. Instead in the entire discussion here, again and again you are trying to mislead everyone by saying that this solution will solve the problem at hand. Any provider will still continue to send the approval without the partner IIA just as they are sending now without mapping. Also you pointed out to @kkaraogl, looks like is the most affected. He was not even aware the IIA binding before approval is a recent change and there will be IIAs in the network that are not bound. Please solve his problem and not tax the entire network. You need to think from network perspective and not from Dashboard. Off course any change that will benefit the network along with solving Dashboards problem(s) is welcome.

[skishk]

@janinamincer-daszkiewicz

it's easy solution with already existing implementation, so no one need to implement new code, just using what already everyone have and use.

Yes, so why there are so many wrong implementations? We are trying to fight against them.

I'm glad that we are trying to find a solution on this problem. I think there is a large number of problems on validation because if a large number of partners use the same provider it's obviously if there is a little mistake on his system it will be multiplied for number of partners and IIA that every one had. so in this scenario it's seems that are a lot of Institution having the same problems.

A easy first step is, we can start to check in the IIA Response (so we need to do a call on IIA-GET API, before sending approve) if we received a IIA-ID Partner so we can know that he linked his Agreement with our Agreement. then we must check if che received conditionHash is the same of the one that we want to approve, and if everything is ok we can send the approval, if all check are not ok we will not send the approval.

(as some colleagues have said, it's not a problem to add both IIA IDs in the approval response, but it's not solving problems and it's not a logical information to add on approval flow, because we are approving the partner agreement not our one)

Hope I was helpful

[janinamincer-daszkiewicz]

@skishk

A easy first step is

And it is described like that in the specification but bad implementations are still in the network.

[kkaraogl]

Sharing both IDs before approval is detailed in the exchange scenario since March 2021 (2 years ago). Not a recent change.

The proposed solution, that all providers in the IF already voted for, is an adequate way for this issue to stop occurring. The problem is still evident in production exchanges.

[umesh-qs]

Sharing both IDs before approval is detailed in the exchange scenario since March 2021 (2 years ago). Not a recent change.

The proposed solution, that all providers in the IF already voted for, is an adequate way for this issue to stop occurring. The problem is still evident in production exchanges.

@kkaraogl I would request you to please go through the full discussion on this before starting over the same stuff that is already answered. You are just wasting everyone's time by restarting the same questions.

[kkaraogl]

@umesh-qs I didn't ask any question. I shared some facts and my opinion.

[umesh-qs]

@umesh-qs I didn't ask any question. I shared some facts and my opinion.

@kkaraogl Looks like you are not willing to go through the arguments posted by other and just want your opinion to be heard, which is also the same what Janina has said. But these points have already been countered. If you want to share anything in support please read the counter arguments and add more to it.

[janinamincer-daszkiewicz]

But these points have already been countered.

Not quite. We have some number of pros and some number of cons and results of the voting. I would be happy to see the current opinion of the other voters.

[demilatof]

The proposed solution, that all providers in the IF already voted for, is an adequate way for this issue to stop occurring. The problem is still evident in production exchanges.

@kkaraogl This is your opinion without any proof. As I already said, adding both IDs to the approval response doesn't resolve anything, because:

1. you approve anyway your partner's IIA
2. your partner is not compelled to do anything with its copy

So, where is the magic in your vision? If both IDs are mandatory, you make a mistake too approving your partner's IIA. Doesn't matter that after that you have added both IDs in the response, you approved an IIA that wasn't well formed: you were simply not ready to approve. You already have the solution:

Values of iia_id that are (...) not approved (yet or at all) MUST be ignored. Servers MUST return a valid (HTTP 200) XML response in such cases, but the response will simply not contain any information on these missing entities

What we may need is an extra element (outside the approval one) that explains why an IIA-IDs is not inside the approval. If you wish, this new element would be the right place to add the second ID

[umesh-qs]

But these points have already been countered.

Not quite. We have some number of pros and some number of cons and results of the voting. I would be happy to see the current opinion of the other voters.

Not sure what "Not quit" means. Please defend your statement and just share 1 pro of this new process over the current process. Else it will again be one more instance of misleading everyone.

[demilatof]

I would be happy to see the current opinion of the other voters.

I would be happy to see if the other voters are sure to solve the original problem with this change

[janinamincer-daszkiewicz]

Convey both IIA ids in IIAs Approval get

As reported during the Infrastructure Forum on 2023-01-18:

• Not a real MUST, as the current specification, if correctly implemented, solves the problem of IIAs which are not properly binded.
• May affect large group of end users and cause their frustration.
• Postponed, as recommended by DG EAC.