You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This works fine as long as the CompanyName is not encrypted, however an issue I still remember from the early days with Alexander is that KPN encrypts the CompanyName as they consider it sensitive data, while the other eHerkenning makelaars don't
This, combined with the fact that we don't support EncryptedAttributes (eg: "The Response could not be validated due to the following error: There is an EncryptedAttribute in the Response and this SP not support them") means that we are currently generating eHerkenning metadata which won't work when used with KPN. This can be modified manually however Laurens and I suggest to remove the CompanyName from the automatically-generated metadata as OF and OIP retrieve this via the KVK API instead.
The text was updated successfully, but these errors were encountered:
Discussed with @LaurensBurger , encountered with Het Hogeland OF
CompanyName is now included in the eHerkenning metadata (this seems to be included by @SilviaAmAm earlier this year via https://github.com/maykinmedia/django-digid-eherkenning/blame/master/digid_eherkenning/models/eherkenning.py
This works fine as long as the CompanyName is not encrypted, however an issue I still remember from the early days with Alexander is that KPN encrypts the CompanyName as they consider it sensitive data, while the other eHerkenning makelaars don't
This, combined with the fact that we don't support EncryptedAttributes (eg: "The Response could not be validated due to the following error: There is an EncryptedAttribute in the Response and this SP not support them") means that we are currently generating eHerkenning metadata which won't work when used with KPN. This can be modified manually however Laurens and I suggest to remove the CompanyName from the automatically-generated metadata as OF and OIP retrieve this via the KVK API instead.
The text was updated successfully, but these errors were encountered: