Different hash in for v6 and v7 xml under https://github.com/erasmus-without-paper/ewp-specs-api-iias/tree/stable-v7/resources/xsltKit

[umesh-qs]

under https://github.com/erasmus-without-paper/ewp-specs-api-iias/tree/stable-v7/resources/xsltKit xml get-response-v7.xml and get-response-v6.xml are supposed to show how v6 xml should look like in v7. Why is hash not matching?

Also I see <isced-f-code>031</isced-f-code> is supposed to be changed to <isced-f-code v6-value="031">0314</isced-f-code>. How would a service provider know the converted value?

[mkurzydlowski]

conditions-hash and iia-hash aren't supposed to match as they use different algorithms.

The value 0314 is set automatically by the server to make this field valid. It should be ignored. That is why v6-value must be set and the proper value will be filled by the end user if the agreement will be modified.

[umesh-qs]

conditions-hash and iia-hash aren't supposed to match as they use different algorithms.

I don't agree. When I am converting v6 xml to v7 xml, hash value must match. Else how would approved agreements remain approved.

The value 0314 is set automatically by the server to make this field valid. It should be ignored. That is why v6-value must be set and the proper value will be filled by the end user if the agreement will be modified.

Does it mean server can fill any random 4 digit value, as long as v6-value is specified?

[mkurzydlowski]

That is why there is a template for v6. An IIA hash calculated on v6 XML should return the same hash as the one obtained from the v7 template on the v7 XML.

Yes, server can fill a random value, as it must be ignored.

[umesh-qs]

So we should use transform_version_6.xsl on v7 xml to get the hash for approved IIAs? And we should use transform_version_7.xsl on v7 xml to get hash for non-approved IIAs?

[mkurzydlowski]

You use transform_version_6.xsl on v6 XML.

It is not important if the IIA is approved. To be able to check if the IIA changed from v6 to v7 you calculate transform v6 on v6, transform v7 on v7 and compare.

[umesh-qs]

You use transform_version_6.xsl on v6 XML.

It is not important if the IIA is approved. To be able to check if the IIA changed from v6 to v7 you calculate transform v6 on v6, transform v7 on v7 and compare.

How? I will always get v7 xml from the partner after march.

[mkurzydlowski]

I was referring to the transition phase when you have the v6 IIA snapshot.

[umesh-qs]

I was referring to the transition phase when you have the v6 IIA snapshot.

I am not sure what it means. We will only send and accept v7 xml after March 2024. Can you please share an example v7 xml for an IIA that was approved in V6 with 3 digit isced code?

[mkurzydlowski]

The example you have linked in this issue is exactly that: https://github.com/erasmus-without-paper/ewp-specs-api-iias/blob/stable-v7/resources/xsltKit/get-response-v6.xml https://github.com/erasmus-without-paper/ewp-specs-api-iias/blob/stable-v7/resources/xsltKit/get-response-v7.xml

[umesh-qs]

The example you have linked in this issue is exactly that: https://github.com/erasmus-without-paper/ewp-specs-api-iias/blob/stable-v7/resources/xsltKit/get-response-v6.xml https://github.com/erasmus-without-paper/ewp-specs-api-iias/blob/stable-v7/resources/xsltKit/get-response-v7.xml

And that is why I said, hash must match.

[mkurzydlowski]

The new IIA hash must match but to calculate it for v6 you have to use the transform_version_6.xsl and hash the text-to-hash output element.

[umesh-qs]

conditions-hash and iia-hash aren't supposed to match as they use different algorithms.

Please see my initial question. I just asked why the hash value is not matching in the example xmls.

v6 xml has hash 3ecc69b81e73bf215b5b2c8da0f2b1a77dac97105171669c16c0e88a4e6be84c v7 xml has hash 87b33170d7a6c6d894215641f39e7b7de36501265479e5ab3922f32d5b225033

Can this be corrected please?

[mkurzydlowski]

v6 xml has hash 3ecc69b81e73bf215b5b2c8da0f2b1a77dac97105171669c16c0e88a4e6be84c

This is the old hash (conditions hash). The new hash (IIA hash) that you obtain through XSLT transformation, is 87b33170d7a6c6d894215641f39e7b7de36501265479e5ab3922f32d5b225033.

[umesh-qs]

v6 xml has hash 3ecc69b81e73bf215b5b2c8da0f2b1a77dac97105171669c16c0e88a4e6be84c

This is the old hash (conditions hash). The new hash (IIA hash) that you obtain through XSLT transformation, is 87b33170d7a6c6d894215641f39e7b7de36501265479e5ab3922f32d5b225033.

Sorry it is still not clear. Lets go by an example

1. There is an IIA iia1, hash1 with partner A and iia2, hash2 with partner B. iia1 and iia2 are linked and both partners have approved. This is in v6.
2. Partner A converts iia1 to v7 and according to you, hash will change to new hash3
3. Partner B pulls the iia1 by calling get API (v7) of Partner A.
4. Partner B sees that the hash in iia1 is now hash3, but approved hash was hash1.

Please explain how partner B is supposed to do its calculation to make sure that the approval is not reset.

[mkurzydlowski]

Partner B should have stored iia1 in v6 and now can calculate hash3 on this snapshot by using XSLT transformation.

[umesh-qs]

Partner B should have stored iia1 in v6 and now can calculate hash3 on this snapshot by using XSLT transformation.

Please explain how partner B can calculate hash3 on stored iia1 which is in v6?

[mkurzydlowski]

He has to use the v6 XSLT on it and then SHA-256 on the outputed text-to-hash.

[umesh-qs]

So this solution assumes that the partner would have stored raw xml until now? What is the approach if the partner does not have raw xml?

[janinamincer-daszkiewicz]

Excel file 2023-10-28-DeleteModifyScenarios.xlsx, tab 8. Switch from IIAs API version 6 to version 7.

[umesh-qs]

Excel file 2023-10-28-DeleteModifyScenarios.xlsx, tab 8. Switch from IIAs API version 6 to version 7.

What is this for?