Unique URLs + Unique Certificates vs hei_id Parameters

[georgschermann]

Since the switch to discovery version 6, all URLs and Certificates on the Network have to be uniquely associated with a hei_id.
So there is currently theoretically no need to have hei_id, sending_hei_id, receiving_hei_id, etc. parameters.

For various reasons we are currently already ignoring these parameters and determine them by the url and certificate.
This leads to the failure of the validators, since some of the test cases are not relevant any more.

Our current suggestion would be to keep the parameters in place for providers who rely on them, probably mark them to be removed in a future version and state that these parameters CAN be ignored in favor of URLs and certificates.

[umesh-qs]

Since the switch to discovery version 6, all URLs and Certificates on the Network have to be uniquely associated with a hei_id. So there is currently theoretically no need to have hei_id, sending_hei_id, receiving_hei_id, etc. parameters.

For various reasons we are currently already ignoring these parameters and determine them by the url and certificate. This leads to the failure of the validators, since some of the test cases are not relevant any more.

Our current suggestion would be to keep the parameters in place for providers who rely on them, probably mark them to be removed in a future version and state that these parameters CAN be ignored in favor of URLs and certificates.

We match the parameter with the calling API URL and throw error if there is no match. If the parameter is not there we go by the calling API URL.
But we should clean this up at some point with major version change

[milsorm]

What if URL change because HEI is renamed? We have such cases several times in history of our partners? How you distinguish "this is the same partner"? Through HEI main identification and list of history-bounded URL? Or through local catalogs where in every moment we associate some manifest with HEI to some partner in local catalog?

[umesh-qs]

What if URL change because HEI is renamed? We have such cases several times in history of our partners? How you distinguish "this is the same partner"? Through HEI main identification and list of history-bounded URL? Or through local catalogs where in every moment we associate some manifest with HEI to some partner in local catalog?

I am not sure if I have understood it. When someone is calling our URL (each of our client has unique URL), we use that to identify the client. And the caller is identified by the certificate they use when calling our API. There is no need of HEI ID in the parameters.

[milsorm]

So adding layer where we transform certificate to HEI ID internally. Only for purness of API specification?

[umesh-qs]

@milsorm again I am not sure what it means. This is not new. It is as per the changes in Discovery 6.0. If you are not getting partner HEI ID using the certificate and instead using from the parameter then you are exposing yourself to security issue.

[milsorm]

@milsorm again I am not sure what it means. This is not new. It is as per the changes in Discovery 6.0. If you are not getting partner HEI ID using the certificate and instead using from the parameter then you are exposing yourself to security issue.

It is fact that we are checking certificate - HEI ID relation, so we can use retrieved information instead of parameter. OK.

[janinamincer-daszkiewicz]

As mentioned in erasmus-without-paper/ewp-specs-api-iias#108 (comment), according to recommendations of DG EAC, this set of changes to the family of IIA APIs will be issued as the major stable release. There will be enough time for all to implement the planned set of changes. Which means that we can also clean up the parameters in the IIA APIs.

[janinamincer-daszkiewicz]

Approved for IIA 7.0.0 release.

[janinamincer-daszkiewicz]

Commit: erasmus-without-paper/ewp-specs-api-iias@5e1bc11
Please, have a look if nothing is missed.

[janinamincer-daszkiewicz]

Added: erasmus-without-paper/ewp-specs-api-iias@e768bd8

[janinamincer-daszkiewicz]

Added: erasmus-without-paper/ewp-specs-api-iias-approval@stable-v2...remove-hei-id

[janinamincer-daszkiewicz]

Added: https://github.com/erasmus-without-paper/ewp-specs-api-iia-cnr/compare/stable-v3

[janinamincer-daszkiewicz]

Added: https://github.com/erasmus-without-paper/ewp-specs-api-iia-approval-cnr/compare/stable-v2