Unique URLs + Unique Certificates vs hei_id Parameters

georgschermann commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

umesh-qs commented 1 year ago

@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 commented 1 year ago

@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.