Canonicalization, whitespaces and hash calculation

[tsiakmaki]

Since the XML Canonicalization does not imply that the spaces are removed, one partner may calculate the hash using the part of the iia xml in pretty printed format and return a pretty iia get response, while the other partner may not use whitespaces. Both iia responses and hashes are valid, but will not be the same.

If I am not wrong on this, may I suggest during the canonicalization to enforce also the removal of the whitespaces introduced by pretty printing for partners that prefer to return an xml response in such format;

[mkurzydlowski]

Both iia responses and hashes are valid, but will not be the same.

That's true but there is no reason why hash of a partner IIA should match HEI's own IIA hash.

[tsiakmaki]

ok, so each partner could/must check that the hash included in the partner's approval is equal to the hash included in the latest partner's IIA GET Response?

But what about the above scenario:

Partner A creates an IIA with B

1. A sends IIA CNR to B 
A: iia_id=a_xxx, hash=x1
B: 

2. B Gets the IIA
A: iia_id=a_xxx, hash=x1
B: iia_id=b_yyy, hash=y1 (created with A's data)/ partner_iia_id=a_xxx, partner_hash=x1

B makes changes and informs A

3. B sends IIA CNR to A 
A: iia_id=a_xxx, hash=x1
B: iia_id=b_yyy, hash=y2 (updated with B's changes) / partner_iia_id=a_xxx, partner_hash=x1

4. A Gets the IIA
A: iia_id=a_xxx, hash=x2 (updated given B's changes) / partner_iia_id=b_yyy, partner_hash=y2
B: iia_id=b_yyy, hash=y2 / partner_iia_id=a_xxx, partner_hash=x1

A agrees with B's changes, do not further changes and approves the IIA

5: A sends IIA Approval CNR to B 
A: iia_id=a_xxx, hash=x2 / partner_iia_id=b_yyy, partner_hash=y2
B: iia_id=b_yyy, hash=y2 / partner_iia_id=a_xxx, partner_hash=x1

6. B gets the Approval
A: iia_id=a_xxx, hash=x2 / partner_iia_id=b_yyy, partner_hash=y2
B: iia_id=b_yyy, hash=y2 / partner_iia_id=a_xxx, partner_hash=x1

B checks the approval's hash and they are *not* the same
B:partner_hash=x1 =/= A:hash=x2 (the one send with the approval)

A correctly did not send a second CNR. He did not make further changes. 
B could not have been informed about the new calculated hash at A. 

[mkurzydlowski]

ok, so each partner could/must check that the hash included in the partner's approval is equal to the hash included in the latest partner's IIA GET Response?

Not exactly or maybe I misunderstood.

Partner's approval of our agreement must have a hash that matches our agreement's hash.

6. B gets the Approval A: iia_id=a_xxx, hash=x2 / partner_iia_id=b_yyy, partner_hash=y2 B: iia_id=b_yyy, hash=y2 / partner_iia_id=a_xxx, partner_hash=x1

What is the _partnerhash in your scenario? Where is it stored and why?

B checks the approval's hash and they are not the same B:partner_hash=x1 =/= A:hash=x2 (the one send with the approval)

I'm not able to tell where partner_hash came from, so I'm not able to understand why you expect them to be equal.

If A approves then it should respond with hash y2 that matches the latest hash of B's IIA.