Handling E-Signature with REST apis
Starting 7612, Maximo E-Signatures have been enhanced to support E-Signature keys which are Maximo managed E-Signature verifcations without needing to delegate the verification to the underlying authentication scheme. This was done keeping in mind the existing issues of doing E-Signature verifications when we have federated authentocation schemes (like SAML/OIDC) in play. However this is not the place to discuss that new E-Signature enhancement. We are going to discuss how the REST apis can deal with E-Signature metadata as well as handle the E-Signature verifications.
E-Signature metadata
The first thing a REST client code would like to know is if any E-Signtaure enabled attribute been modified. To do that, the REST request needs to have an added query parameter &checkesig=1. Once that is set (as part of the POST request), the server would respond back with a Maximo error with the BMX code BMXAA9766E. This will be an indicator to the client code to show the esig challenge to the end user. Note that by default the REST framework will not track esig enabled attribute modifications - it will only do so when that &checkesig=1 query paremeter is set.
Respoding to the E-Signature challenge
To respond to the esig challenge, the rest api provides an esigauth request header to set the base64 encoded esig password (or esig key if native esig is turned on). Along with that there is another request header esigreason which can be leveraged to provide the reason (memo) for the change. The clent should re-submit the change along with these request headers. Once the server verifies the esigauth, it will let the transaction go through the save process.