When to publish an approval

[jiripetrzelka]

As a server implementer, can I publish the new approval with iia-hash in case the valid-for-approval element from the XSLT transformation evaluates to false but the IIA has already been approved in version 6?

As a server implementer, can I publish the new approval with iia-hash in case the IIA does not contain the not-yet-defined attribute but contains the v6-value attribute? If not, why?

[mkurzydlowski]

As a server implementer, can I publish the new approval with iia-hash in case the valid-for-approval element from the XSLT transformation evaluates to false but the IIA has already been approved in version 6?

valid-for-approval set to false should block approval. Having an approval in version 6 shouldn't change things.

As a server implementer, can I publish the new approval with iia-hash in case the IIA does not contain the not-yet-defined attribute but contains the v6-value attribute? If not, why?

v6-value doesn't block approval.

[jiripetrzelka]

If v6-value doesn't block the approval then why does valid-for-approval evaluate to false when v6-value is set? https://github.com/erasmus-without-paper/ewp-specs-api-iias/blob/3e9516dba162fb5c117fb0354cbe70add02f0428/resources/xsltKit/transform_version_7.xsl#L92

Shouldn't it be that if valid-for-approval is false then the approval must not be published in the approval endpoint?

[mkurzydlowski]

In fact IIA version 7 should be approved when it is a new IIA or an IIA that changed after v6. In both cases it shouldn't contain value-v6.

[jiripetrzelka]

My idea is that I will publish approvals 2.0 for all IIAs 7.0 that I receive from partners regardless of whether the IIA has been approved previously as IIA 6.0 or newly as IIA 7.0. I know which iia-hash corresponds to which conditions-hash. I assume I am not forbidden to do that.

Now I understand that I must not publish the approval 2.0 in case the yet-not-defined attribute is present. However, I still don't understand if I am allowed to publish the approval 2.0 for an IIA, in which the v6-value is present. I don't see any added value in waiting for the partner to remove the attribute (which I assume would most probably happen only if an amendment was created).

So for IIAs approved as IIA 6.0, am I allowed to publish the corresponding approval 2.0 even if the v6-value is present or not?

[mkurzydlowski]

I believe that the best way to proceed with approvals after v7 is being implemented is to update the approval CNR to v2 by recalculating the new hash based on the saved IIA v6 snapshots. No CNRs should be issued in such case, as the approvals are pointing to the same IIA versions. I also think that we should update the specs to specify that the rule you mention (not-yet-defined and v6-value must not be used to approve an IIA) is only valid for agreements that are new or have been modified in v7.

[mkurzydlowski]

Please review this set of changes: https://github.com/erasmus-without-paper/ewp-specs-api-iias-approval/compare/approval-fix https://github.com/erasmus-without-paper/ewp-specs-api-iias/compare/approval-fix

[mkurzydlowski]

I would also ask you to review a description of the Approval v2 update steps:

Both IIA API v7 and IIA Approval API v2 have been released and must be used together.

Both APIs introduced new IIA hash calculation algorithm. The old hash used in IIA v6 (conditions-hash element) will not be used anymore.

A new hash has to be calculated for IIA approvals. The new element is now named iia-hash: https://github.com/erasmus-without-paper/ewp-specs-api-iias/blob/stable-v7/endpoints/get-response.xsd#L242-L249

A snapshot of the approved v6 IIA is needed to be able to upgrade to IIA v7 and Approval v2. Such snapshot is stored as an IIA v6 GET API response XML of the approved agreement.

To calculate the new hash and XSLT v6 (https://github.com/erasmus-without-paper/ewp-specs-api-iias/blob/stable-v7/resources/xsltKit/transform_version_6.xsl) has to be used to transform the stored snapshot to a string that will be hashed (see: https://github.com/erasmus-without-paper/ewp-specs-api-iias/tree/stable-v7/resources/xsltKit).

For example for a stored approved IIA: https://github.com/erasmus-without-paper/ewp-specs-api-iias/blob/stable-v7/resources/xsltKit/get-response-v6.xml

An IIA Approval v1 would contain: <conditions-hash>f2b01c46c8b87b895597ecc40122ff377da8df16bebfa9c0c8020fb2207a50ba</conditions-hash>

XSLT v6 used on that IIA GET v6 response would produce:

<?xml version="1.0" encoding="UTF-8"?>
<iia>
   <iia-id>0f7a5682-faf7-49a7-9cc7-ec486c49a281</iia-id>
   <text-to-hash>_0f7a5682-faf7-49a7-9cc7-ec486c49a281__1954991__uw.edu.pl__140__hibo.no__031__Social and behavioural sciences__5__false__7__8__2014/2015__2020/2021__uw.edu.pl__140__hibo.no__2__en__C1__0314__8__2016/2017__2017/2018_</text-to-hash>
</iia>

The text-to-hash element value when hashed using SHA-256 would produce: 7bdd07b3a5088cb85da17326afa4d0514521b53ee6fc78cf7025a9ee6f5b11ab

That hash would then be inserted into an IIA Approval v2: <iia-hash>7bdd07b3a5088cb85da17326afa4d0514521b53ee6fc78cf7025a9ee6f5b11ab</iia-hash>

And should match the IIA v7 hash after partner upgrades his IIA.

[mkurzydlowski]

I have added this proposal here: https://github.com/erasmus-without-paper/ewp-specs-api-iias-approval/compare/upgrade-steps