esipa_rest_utils: use correct ASN.1 type for notificationsList
In SGP.32 V.1.0.1, the type for notificationsList is SGP32-RetrieveNotificationsListResponse. With SGP.32 V.1.2, the type is changed to PendingNotificationList
rest_handler: add API versions and schema validation
The JSON based REST API currently has no version checking and also does not use any JSON schema based validation yet. This patch adds both. An X-ADMIN-PROTOCOL field in the HTTP header informs about the API version (same style as the JSON interfaces defined in GSMA SGP.32 and SGP.22 would use). For incoming messages, the X-ADMIN-PROTOCOL field is checked to prevent outdated clients from using the REST API.
The incoming and outgoing JSON messages are now validated against JSON schema files. Those are the same JSON schema file which were only provided for documentation purposes only before. Now those files have been fixed up and moved to the priv directory, where they are now actively used.
The REST API also makes use of the cowboy HTTP server in the same way as the ESipa API does when running without SSL/TLS. Let's unify the code in such a way that both HTTP servers call the same startup helper functions.
esipa_asn1_handler_utils: clean up handling of EuiccPackageResult
The function that handles the parsing and processing of the EuiccPackageResult is written in a confusing way and also seems to be slightly wrong (we do not want to re-bind any work item to a eimTransactionId here). Let's clean it up in a way that is easier to follow.
contrib: restructure REST API usage examples (tryme-scripts)
The so called tryme scripts are using a very clumsy method to set the varying parameters (tryme.cfg). The files also mix with other unrelated files in the contrib directory. There is also a lot of distracting output displayed which complicates the usage of the examples even further. This patch fixes those shortcomings.
- put everything related to the usage example into a dedicated directory. - renovate restop.py so that it produces more readable output. - in the tryme_*.sh scripts, avoid output that is not needed. - cleanup tryme.cfg so that it only contains one set of parameters, add some helpful comments. - add functionality to pass the the parameters either via commandline options or via tryme.cfg, add a parameter to point to an alternative .cfg file, so that users can use multiple different configurations. - update documentation - cleanup other minor inconsistencies
esipa_rest_utils: align IpaEuiccDataResponse to SGP.32 V.1.2
The ASN.1 struct IpaEuiccDataResponse has renamed the error code member from ipaEuiccDataError to ipaEuiccDataErrorCode. The new ipaEuiccDataErrorCode is a sequence that has an ipaEuiccDataErrorCode member, which is the equivalent of the previously existing ipaEuiccDataError member.
esipa: rename TransactionId to EimTransactionId where applicable
In SGP.32 V.1.2 all TransactionIds which are generated by the eIM are called now called "eimTransactionId". Let's make sure that we name the EimTransactionId variables and atoms (eimTransactionId) accordingly.
restop.py, tryme_*.sh: improve log output and handling
The tryme scripts and the restop.py script produce lots of distracting and difficult to read log output. Let's renovate the scripts a bit so that the useful information is displayed in a readable way.
esipa: supply eimTransactionId in profileDownloadTriggerRequest
When we supply an eimTransactionId in profileDownloadTriggerRequest, the IPAd will echo the same eimTransactionId in the initiateAuthenticationRequestEsipa message. This allows the eIM to distinguish to which transaction (work) the received initiateAuthenticationRequestEsipa belongs. This was not possible before. The eIM had to rely soly on the PID of the sub process which is handling the HTTP connection.
mnesia_db_rest: add comment on why we create an euicc entry early
Even though it is technically not necessary, we ensure that an entry is present in the euicc table on each REST API call. Let's add a comment to explain why we do it anyway.
The REST API also makes use of the cowboy HTTP server in the same way as the ESipa API does when running without SSL/TLS. Let's unify the code in such a way that both HTTP servers call the same startup helper functions.
contrib: restructure REST API usage examples (tryme-scripts)
The so called tryme scripts are using a very clumsy method to set the varying parameters (tryme.cfg). The files also mix with other unrelated files in the contrib directory. This patch fixes those shortcomings.
- put everything related to the usage example into a dedicated directory. - cleanup tryme.cfg so that it only contains one set of parameters, add some helpful comments. - add functionality to pass the the parameters either via commandline options or via tryme.cfg, add a parameter to point to an alternative .cfg file, so that users can use multiple different configurations. - update documentation - cleanup other minor inconsistencies
esipa_asn1_handler: use eimTransactionId in EimPackageResultResponseError
EimPackageResultResponseError contains an eimTransactionId, let's use this eimTransactionId and add a dedicated handler function for the EimPackageResultResponseError to esipa_asn1_handler_utils
esipa_asn1_handler_utils: clean up handling of EuiccPackageResult
The function that handles the parsing and processing of the EuiccPackageResult is written in a confusing way and also seems to be slightly wrong (we do not want to re-bind any work item to a eimTransactionId here). Let's clean it up in a way that is easier to follow.
esipa_asn1_handler_utils: rename EsipaReq to Debuginfo
The parameter EsipaReq only exists because we pass it as Debuginfo to mnesia_db_work:finish. Let's rename it to "Debuginfo" in esipa_asn1_handler_utils as well to make clear what the purpose of this parameter is.
esipa_rest_utils: align IpaEuiccDataResponse to SGP.32 V.1.2
The ASN.1 struct IpaEuiccDataResponse has renamed the error code member from ipaEuiccDataError to ipaEuiccDataErrorCode. The new ipaEuiccDataErrorCode is a sequence that has an ipaEuiccDataErrorCode member, which is the equivalent of the previously existing ipaEuiccDataError member.
mnesia_db: split functionality into dedicated modules
The mnesia_db module is responsible to handle three different tables with different scope. Let's split the functionality into separate modules to make the code easier to maintain.
esipa_rest_utils: use correct ASN.1 type for notificationsList
In SGP.32 V.1.0.1, the type for notificationsList is SGP32-RetrieveNotificationsListResponse. With SGP.32 V.1.2, the type is changed to PendingNotificationList
rest_handler: add API versions and schema validation
The JSON based REST API currently has no version checking and also does not use any JSON schema based validation yet. This patch adds both. An X-ADMIN-PROTOCOL field in the HTTP header informs about the API version (same style as the JSON interfaces defined in GSMA SGP.32 and SGP.22 would use). For incoming messages, the X-ADMIN-PROTOCOL field is checked to prevent outdated clients from using the REST API.
The incoming and outgoing JSON messages are now validated against JSON schema files. Those are the same JSON schema file which were only provided for documentation purposes only before. Now those files have been fixed up and moved to the priv directory, where they are now actively used.
The IPAd may pass a notifyStateChange and a stateChangeCause code. The notifyStateChange flag tells that a state change happened and the stateChangeCause code tells what the cause was.
let's store the stateChangeCause code as a state in the euicc table, so that the REST API user can poll for stateChangeCause codes in suitable intervals.
esipa_asn1_handler: use eimTransactionId for ipaEuiccDataResponse
The ipaEuiccDataResponse does currently not use the eimTransactionId, which was added with SGP.32 V.1.2, let's make use of the eimTransactionId and move the handler functionality to a dedicated helper function in esipa_asn_handler_utils.
mnesia_db_euicc: renovate handling of euicc table (mnesia, REST)
The REST API that allows users to set certain eUICC parameters (we call them "states" from now on) only allows to set eUICC states, but doesn't allow to read them back.
With this patch, we renovate the handling of the mnesia euicc table from the ground up so that REST API users have read and write access to the states stored in the mnesia euicc table.
esipa: rename TransactionId to EimTransactionId where applicable
In SGP.32 V.1.2 all TransactionIds which are generated by the eIM are called now called "eimTransactionId". Let's make sure that we name the EimTransactionId variables and atoms (eimTransactionId) accordingly.
esipa: supply eimTransactionId in profileDownloadTriggerRequest
When we supply an eimTransactionId in profileDownloadTriggerRequest, the IPAd will echo the same eimTransactionId in the initiateAuthenticationRequestEsipa message. This allows the eIM to distinguish to which transaction (work) the received initiateAuthenticationRequestEsipa belongs. This was not possible before. The eIM had to rely soly on the PID of the sub process which is handling the HTTP connection.
esipa_asn1_handler_utils: clean up handling of EuiccPackageResult
The function that handles the parsing and processing of the EuiccPackageResult is written in a confusing way and also seems to be slightly wrong (we do not want to re-bind any work item to a eimTransactionId here). Let's clean it up in a way that is easier to follow.
mnesia_db: split functionality into dedicated modules
The mnesia_db module is responsible to handle three different tables with different scope. Let's split the functionality into separate modules to make the code easier to maintain.
esipa_asn1_handler: use eimTransactionId in EimPackageResultResponseError
EimPackageResultResponseError contains an eimTransactionId, let's use this eimTransactionId and add a dedicated handler function for the EimPackageResultResponseError to esipa_asn1_handler_utils
The esipa_middleware filters incompatible requests by their protocol version (X-ADMIN-PROTOCOL), but there is no error logged in that case. Let's make sure that incompatible requests are brought to the operator's attention.
mnesia_db_euicc: renovate handling of euicc table (mnesia, REST)
The REST API that allows users to set certain eUICC parameters (we call them "states" from now on) only allows to set eUICC states, but doesn't allow to read them back.
With this patch, we renovate the handling of the mnesia euicc table from the ground up so that REST API users have read and write access to the states stored in the mnesia euicc table.
restop.py, tryme_*.sh: improve log output and handling
The tryme scripts and the restop.py script produce lots of distracting and difficult to read log output. Let's renovate the scripts a bit so that the useful information is displayed in a readable way.
esipa_asn1_handler_utils: rename EsipaReq to Debuginfo
The parameter EsipaReq only exists because we pass it as Debuginfo to mnesia_db_work:finish. Let's rename it to "Debuginfo" in esipa_asn1_handler_utils as well to make clear what the purpose of this parameter is.
mnesia_db_rest: add comment on why we create an euicc entry early
Even though it is technically not necessary, we ensure that an entry is present in the euicc table on each REST API call. Let's add a comment to explain why we do it anyway.
esipa_rest_utils: use correct ASN.1 type for notificationsList
In SGP.32 V.1.0.1, the type for notificationsList is SGP32-RetrieveNotificationsListResponse. With SGP.32 V.1.2, the type is changed to PendingNotificationList
esipa_asn1_handler: use eimTransactionId for ipaEuiccDataResponse
The ipaEuiccDataResponse does currently not use the eimTransactionId, which was added with SGP.32 V.1.2, let's make use of the eimTransactionId and move the handler functionality to a dedicated helper function in esipa_asn_handler_utils.
esipa_rest_utils: align IpaEuiccDataResponse to SGP.32 V.1.2
The ASN.1 struct IpaEuiccDataResponse has renamed the error code member from ipaEuiccDataError to ipaEuiccDataErrorCode. The new ipaEuiccDataErrorCode is a sequence that has an ipaEuiccDataErrorCode member, which is the equivalent of the previously existing ipaEuiccDataError member.
The IPAd may pass a notifyStateChange and a stateChangeCause code. The notifyStateChange flag tells that a state change happened and the stateChangeCause code tells what the cause was.
let's store the stateChangeCause code as a state in the euicc table, so that the REST API user can poll for stateChangeCause codes in suitable intervals.
esipa_asn1_handler: use eimTransactionId for ipaEuiccDataResponse
The ipaEuiccDataResponse does currently not use the eimTransactionId, which was added with SGP.32 V.1.2, let's make use of the eimTransactionId and move the handler functionality to a dedicated helper function in esipa_asn_handler_utils.
esipa: rename TransactionId to EimTransactionId where applicable
In SGP.32 V.1.2 all TransactionIds which are generated by the eIM are called now called "eimTransactionId". Let's make sure that we name the EimTransactionId variables and atoms (eimTransactionId) accordingly.
esipa: supply eimTransactionId in profileDownloadTriggerRequest
When we supply an eimTransactionId in profileDownloadTriggerRequest, the IPAd will echo the same eimTransactionId in the initiateAuthenticationRequestEsipa message. This allows the eIM to distinguish to which transaction (work) the received initiateAuthenticationRequestEsipa belongs. This was not possible before. The eIM had to rely soly on the PID of the sub process which is handling the HTTP connection.
rest_handler: add API versions and schema validation
The JSON based REST API currently has no version checking and also does not use any JSON schema based validation yet. This patch adds both. An X-ADMIN-PROTOCOL field in the HTTP header informs about the API version (same style as the JSON interfaces defined in GSMA SGP.32 and SGP.22 would use). For incoming messages, the X-ADMIN-PROTOCOL field is checked to prevent outdated clients from using the REST API.
The incoming and outgoing JSON messages are now validated against JSON schema files. Those are the same JSON schema file which were only provided for documentation purposes only before. Now those files have been fixed up and moved to the priv directory, where they are now actively used.
The IPAd may pass a notifyStateChange and a stateChangeCause code. The notifyStateChange flag tells that a state change happened and the stateChangeCause code tells what the cause was.
let's store the stateChangeCause code as a state in the euicc table, so that the REST API user can poll for stateChangeCause codes in suitable intervals.
mnesia_db_rest: add comment on why we create an euicc entry early
Even though it is technically not necessary, we ensure that an entry is present in the euicc table on each REST API call. Let's add a comment to explain why we do it anyway.
contrib/tryme_euiccDataRequest: fixup example tag string
The eUICC data request takes a string with TLV tags as input. The example in this example still uses tags from SGP.32 V.1.0.1, let's update the string so that it is compliant with SGP.32 V.1.2.
The esipa_middleware filters incompatible requests by their protocol version (X-ADMIN-PROTOCOL), but there is no error logged in that case. Let's make sure that incompatible requests are brought to the operator's attention.
esipa_asn1_handler: use eimTransactionId in EimPackageResultResponseError
EimPackageResultResponseError contains an eimTransactionId, let's use this eimTransactionId and add a dedicated handler function for the EimPackageResultResponseError to esipa_asn1_handler_utils
esipa_asn1_handler_utils: rename EsipaReq to Debuginfo
The parameter EsipaReq only exists because we pass it as Debuginfo to mnesia_db_work:finish. Let's rename it to "Debuginfo" in esipa_asn1_handler_utils as well to make clear what the purpose of this parameter is.
mnesia_db: split functionality into dedicated modules
The mnesia_db module is responsible to handle three different tables with different scope. Let's split the functionality into separate modules to make the code easier to maintain.
esipa_rest_utils: align IpaEuiccDataResponse to SGP.32 V.1.2
The ASN.1 struct IpaEuiccDataResponse has renamed the error code member from ipaEuiccDataError to ipaEuiccDataErrorCode. The new ipaEuiccDataErrorCode is a sequence that has an ipaEuiccDataErrorCode member, which is the equivalent of the previously existing ipaEuiccDataError member.
restop.py, tryme_*.sh: improve log output and handling
The tryme scripts and the restop.py script produce lots of distracting and difficult to read log output. Let's renovate the scripts a bit so that the useful information is displayed in a readable way.
esipa_asn1_handler_utils: clean up handling of EuiccPackageResult
The function that handles the parsing and processing of the EuiccPackageResult is written in a confusing way and also seems to be slightly wrong (we do not want to re-bind any work item to a eimTransactionId here). Let's clean it up in a way that is easier to follow.
The REST API also makes use of the cowboy HTTP server in the same way as the ESipa API does when running without SSL/TLS. Let's unify the code in such a way that both HTTP servers call the same startup helper functions.
esipa_asn1_handler_utils: clean up handling of EuiccPackageResult
The function that handles the parsing and processing of the EuiccPackageResult is written in a confusing way and also seems to be slightly wrong (we do not want to re-bind any work item to a eimTransactionId here). Let's clean it up in a way that is easier to follow.
mnesia_db_euicc: renovate handling of euicc table (mnesia, REST)
The REST API that allows users to set certain eUICC parameters (we call them "states" from now on) only allows to set eUICC states, but doesn't allow to read them back.
With this patch, we renovate the handling of the mnesia euicc table from the ground up so that REST API users have read and write access to the states stored in the mnesia euicc table.
restop.py, tryme_*.sh: improve log output and handling
The tryme scripts and the restop.py script produce lots of distracting and difficult to read log output. Let's renovate the scripts a bit so that the useful information is displayed in a readable way.
Change-Id: I7fe40e7ed50354114e80cd96a5b40f3e579220e9 Related SYS#8100
The IPAd may pass a notifyStateChange and a stateChangeCause code. The notifyStateChange flag tells that a state change happened and the stateChangeCause code tells what the cause was.
let's store the stateChangeCause code as a state in the euicc table, so that the REST API user can poll for stateChangeCause codes in suitable intervals.
esipa: supply eimTransactionId in profileDownloadTriggerRequest
When we supply an eimTransactionId in profileDownloadTriggerRequest, the IPAd will echo the same eimTransactionId in the initiateAuthenticationRequestEsipa message. This allows the eIM to distinguish to which transaction (work) the received initiateAuthenticationRequestEsipa belongs. This was not possible before. The eIM had to rely soly on the PID of the sub process which is handling the HTTP connection.
mnesia_db_euicc: renovate handling of euicc table (mnesia, REST)
The REST API that allows users to set certain eUICC parameters (we call them "states" from now on) only allows to set eUICC states, but doesn't allow to read them back.
With this patch, we renovate the handling of the mnesia euicc table from the ground up so that REST API users have read and write access to the states stored in the mnesia euicc table.
esipa_asn1_handler_utils: rename EsipaReq to Debuginfo
The parameter EsipaReq only exists because we pass it as Debuginfo to mnesia_db_work:finish. Let's rename it to "Debuginfo" in esipa_asn1_handler_utils as well to make clear what the purpose of this parameter is.
esipa_asn1_handler: use eimTransactionId in EimPackageResultResponseError
EimPackageResultResponseError contains an eimTransactionId, let's use this eimTransactionId and add a dedicated handler function for the EimPackageResultResponseError to esipa_asn1_handler_utils
mnesia_db_rest: add comment on why we create an euicc entry early
Even though it is technically not necessary, we ensure that an entry is present in the euicc table on each REST API call. Let's add a comment to explain why we do it anyway.
contrib/tryme_euiccDataRequest: fixup example tag string
The eUICC data request takes a string with TLV tags as input. The example in this example still uses tags from SGP.32 V.1.0.1, let's update the string so that it is compliant with SGP.32 V.1.2.
esipa: rename TransactionId to EimTransactionId where applicable
In SGP.32 V.1.2 all TransactionIds which are generated by the eIM are called now called "eimTransactionId". Let's make sure that we name the EimTransactionId variables and atoms (eimTransactionId) accordingly.
mnesia_db: split functionality into dedicated modules
The mnesia_db module is responsible to handle three different tables with different scope. Let's split the functionality into separate modules to make the code easier to maintain.
esipa_rest_utils: align IpaEuiccDataResponse to SGP.32 V.1.2
The ASN.1 struct IpaEuiccDataResponse has renamed the error code member from ipaEuiccDataError to ipaEuiccDataErrorCode. The new ipaEuiccDataErrorCode is a sequence that has an ipaEuiccDataErrorCode member, which is the equivalent of the previously existing ipaEuiccDataError member.
esipa_asn1_handler: use eimTransactionId for ipaEuiccDataResponse
The ipaEuiccDataResponse does currently not use the eimTransactionId, which was added with SGP.32 V.1.2, let's make use of the eimTransactionId and move the handler functionality to a dedicated helper function in esipa_asn_handler_utils.
contrib/onomondo-eim.sh: add option to set a mnesia dir
The onomondo-eim.sh startscript we provide in the contrib directory does not set the "mnesia dir" parameter when starting the erlang VM. Let's add a commandline parameter and a default location to the script.
esipa: rename TransactionId to EimTransactionId where applicable
In SGP.32 V.1.2 all TransactionIds which are generated by the eIM are called now called "eimTransactionId". Let's make sure that we name the EimTransactionId variables and atoms (eimTransactionId) accordingly.
esipa_asn1_handler: use eimTransactionId in EimPackageResultResponseError
EimPackageResultResponseError contains an eimTransactionId, let's use this eimTransactionId and add a dedicated handler function for the EimPackageResultResponseError to esipa_asn1_handler_utils
esipa: supply eimTransactionId in profileDownloadTriggerRequest
When we supply an eimTransactionId in profileDownloadTriggerRequest, the IPAd will echo the same eimTransactionId in the initiateAuthenticationRequestEsipa message. This allows the eIM to distinguish to which transaction (work) the received initiateAuthenticationRequestEsipa belongs. This was not possible before. The eIM had to rely soly on the PID of the sub process which is handling the HTTP connection.
esipa_asn1_handler: use eimTransactionId for ipaEuiccDataResponse
The ipaEuiccDataResponse does currently not use the eimTransactionId, which was added with SGP.32 V.1.2, let's make use of the eimTransactionId and move the handler functionality to a dedicated helper function in esipa_asn_handler_utils.
mnesia_db_euicc: renovate handling of euicc table (mnesia, REST)
The REST API that allows users to set certain eUICC parameters (we call them "states" from now on) only allows to set eUICC states, but doesn't allow to read them back.
With this patch, we renovate the handling of the mnesia euicc table from the ground up so that REST API users have read and write access to the states stored in the mnesia euicc table.
Related: SYS#8100
The original purpose of the euicc table was to hold static params for an eUICC (e.g. the public key or the flag that tells if it is a consumer eUICC or not). Now that we plan to extend the scope of the euicc table, it makes more sense to talk about states rather than parameters.
contrib/tryme_euiccDataRequest: fixup example tag string
The eUICC data request takes a string with TLV tags as input. The example in this example still uses tags from SGP.32 V.1.0.1, let's update the string so that it is compliant with SGP.32 V.1.2.
esipa_asn1_handler_utils: rename EsipaReq to Debuginfo
The parameter EsipaReq only exists because we pass it as Debuginfo to mnesia_db_work:finish. Let's rename it to "Debuginfo" in esipa_asn1_handler_utils as well to make clear what the purpose of this parameter is.
mnesia_db_rest: add comment on why we create an euicc entry early
Even though it is technically not necessary, we ensure that an entry is present in the euicc table on each REST API call. Let's add a comment to explain why we do it anyway.
mnesia_db: split functionality into dedicated modules
The mnesia_db module is responsible to handle three different tables with different scope. Let's split the functionality into separate modules to make the code easier to maintain.
The Makefile allows to compile and install onomondo-eim. This allows to build it with osmo-dev and therefore build and run it with testenv of osmo-ttcn3-hacks.
The start script allows to run onomondo-eim without starting erlang by hand. It was taken from osmo-s1gw repository and log-level option was added.
The program name changed from 'onomondo_eim_release' to 'onomodo-eim'.
esipa: rename TransactionId to EimTransactionId where applicable
In SGP.32 V.1.2 all TransactionIds which are generated by the eIM are called now called "eimTransactionId". Let's make sure that we name the EimTransactionId variables and atoms (eimTransactionId) accordingly.
esipa: supply eimTransactionId in profileDownloadTriggerRequest
When we supply an eimTransactionId in profileDownloadTriggerRequest, the IPAd will echo the same eimTransactionId in the initiateAuthenticationRequestEsipa message. This allows the eIM to distinguish to which transaction (work) the received initiateAuthenticationRequestEsipa belongs. This was not possible before. The eIM had to rely soly on the PID of the sub process which is handling the HTTP connection.
esipa_asn1_handler: use eimTransactionId for ipaEuiccDataResponse
The ipaEuiccDataResponse does currently not use the eimTransactionId, which was added with SGP.32 V.1.2, let's make use of the eimTransactionId and move the handler functionality to a dedicated helper function in esipa_asn_handler_utils.
esipa_asn1_handler_utils: rename EsipaReq to Debuginfo
The parameter EsipaReq only exists because we pass it as Debuginfo to mnesia_db_work:finish. Let's rename it to "Debuginfo" in esipa_asn1_handler_utils as well to make clear what the purpose of this parameter is.
esipa_asn1_handler: use eimTransactionId in EimPackageResultResponseError
EimPackageResultResponseError contains an eimTransactionId, let's use this eimTransactionId and add a dedicated handler function for the EimPackageResultResponseError to esipa_asn1_handler_utils
esipa_asn1_handler_utils: rename EsipaReq to Debuginfo
The parameter EsipaReq only exists because we pass it as Debuginfo to mnesia_db_work:finish. Let's rename it to "Debuginfo" in esipa_asn1_handler_utils as well to make clear what the purpose of this parameter is.
esipa_asn1_handler: use eimTransactionId for ipaEuiccDataResponse
The ipaEuiccDataResponse does currently not use the eimTransactionId, which was added with SGP.32 V.1.2, let's make use of the eimTransactionId and move the handler functionality to a dedicated helper function in esipa_asn_handler_utils.
esipa: supply eimTransactionId in profileDownloadTriggerRequest
When we supply an eimTransactionId in profileDownloadTriggerRequest, the IPAd will echo the same eimTransactionId in the initiateAuthenticationRequestEsipa message. This allows the eIM to distinguish to which transaction (work) the received initiateAuthenticationRequestEsipa belongs. This was not possible before. The eIM had to rely soly on the PID of the sub process which is handling the HTTP connection.
esipa_asn1_handler: use eimTransactionId in EimPackageResultResponseError
EimPackageResultResponseError contains an eimTransactionId, let's use this eimTransactionId and add a dedicated handler function for the EimPackageResultResponseError to esipa_asn1_handler_utils
esipa: rename TransactionId to EimTransactionId where applicable
In SGP.32 V.1.2 all TransactionIds which are generated by the eIM are called now called "eimTransactionId". Let's make sure that we name the EimTransactionId variables and atoms (eimTransactionId) accordingly.
mnesia_db: split functionality into dedicated modules
The mnesia_db module is responsible to handle three different tables with different scope. Let's split the functionality into separate modules to make the code easier to maintain.
mnesia_db: split functionality into dedicated modules
The mnesia_db module is responsible to handle three different tables with different scope. Let's split the functionality into separate modules to make the code easier to maintain.
esipa: rename TransactionId to EimTransactionId where applicable
In SGP.32 V.1.2 all TransactionIds which are generated by the eIM are called now called "eimTransactionId". Let's make sure that we name the EimTransactionId variables and atoms (eimTransactionId) accordingly.
esipa_asn1_handler: use eimTransactionId for ipaEuiccDataResponse
The ipaEuiccDataResponse does currently not use the eimTransactionId, which was added with SGP.32 V.1.2, let's make use of the eimTransactionId and move the handler functionality to a dedicated helper function in esipa_asn_handler_utils.
esipa_asn1_handler: use eimTransactionId in EimPackageResultResponseError
EimPackageResultResponseError contains an eimTransactionId, let's use this eimTransactionId and add a dedicated handler function for the EimPackageResultResponseError to esipa_asn1_handler_utils
esipa_asn1_handler_utils: rename EsipaReq to Debuginfo
The parameter EsipaReq only exists because we pass it as Debuginfo to mnesia_db_work:finish. Let's rename it to "Debuginfo" in esipa_asn1_handler_utils as well to make clear what the purpose of this parameter is.
esipa: supply eimTransactionId in profileDownloadTriggerRequest
When we supply an eimTransactionId in profileDownloadTriggerRequest, the IPAd will echo the same eimTransactionId in the initiateAuthenticationRequestEsipa message. This allows the eIM to distinguish to which transaction (work) the received initiateAuthenticationRequestEsipa belongs. This was not possible before. The eIM had to rely soly on the PID of the sub process which is handling the HTTP connection.
mnesia_db: split functionality into dedicated modules
The mnesia_db module is responsible to handle three different tables with different scope. Let's split the functionality into separate modules to make the code easier to maintain.
es9p_client: convert InitiateAuthenticationOkEsipa to match SGP.32 V.1.2
In SGP.32 V.1.0.1, InitiateAuthenticationOkEsipa is almost identical to SGP.22 InitiateAuthenticationOkEs9. However, in SGP.32 V.1.2, the member euiccCiPKIdToBeUsed is renamed to euiccCiPKIdentifierToBeUsed. This means it is no longer possible to pass InitiateAuthenticationOkEsipa as InitiateAuthenticationOkEs9 to ES9+ directly. Instead we have to re-build the the InitiateAuthenticationOkEs9 from the contents of InitiateAuthenticationOkEsipa.
esipa_asn1_handler: re-align to SGP.32 section 2.11.2 and section 5.14.6
Section 2.11.2: eIM package result (EuiccPackageResult case) is now concatenated with PendingNotificationList instead of RetrieveNotificationsListResponse Section 5.14.6: ESipa.ProvideEimPackageResult: Significant change in parameters
eim_cfg: set eimSupportedProtocol and indirectProfileDownload flags
The members eimSupportedProtocol and indirectProfileDownload were added as optional members to EimConfigurationData with SGP.32 V.1.2.
Since our eIM implementation only supports eIM Package Retrieval via HTTPs and the Indirect Profile Download procedure is the only Profile Download procedure we currently support, the EimConfigurationData should reflect those properties correctly.
(The EimConfigurationData is not announced actively by the eIM, but this eIM implementation contains a generator to help with the encoding of the EimConfigurationData that is programmed into the eUICC)
