The following request body is sent during the preauthorize call:
{
"svcinfo": {
"did": 1,
"protocol": "FIDO2_0",
"authtype": "PASSWORD",
"svcusername": "svcfidouser",
"svcpassword": "Abcd1234!"
},
"payload": {
"username": "johndoe",
"txid": "254900MS6G5FQCUJMZ97-TELLARO-1631149799",
"txpayload": "ewogICAgIm1lcmNoYW50TmFtZSI6ICJTdHJvbmdLZXkiLAogICAgImN1cnJlbmN5IjogIlVTRCIsCiAgICAidG90YWxQcmljZSI6ICIxNDk5NSIsCiAgICAiY2FyZEJyYW5kIjogIkFtZXgiLAogICAgImNhcmRMYXN0NCI6ICJ4LTEyMzQiLAogICAgInR4aWQiOiAiMjU0OTAwTVM2RzVGUUNVSk1aOTctVEVMTEFSTy0xNjMxMTQ5Nzk5IiwKICAgICJ0eGRhdGUiOiAiVGh1IFNlcCA4IDE3OjAyOjU2IFBEVCAyMDIxIgp9",
"options": {},
"appTXID": "exampleappTXID"
}
}
Value |
Explanation |
---|---|
did |
Unique identifier for a cryptographic domain within the SKFS. Unless using a StrongKey Tellaro appliance, this defaults to 1. |
protocol |
The FIDO protocol to be used in this request (FIDO2_0) |
authtype |
The type of authentication supplied in this service request—it must be PASSWORD or HMAC (see API Security for details); the example shown here is for PASSWORD authtype. |
svcusername |
The username of the service credential requesting this web service. |
svcpassword |
The password of the service credential requesting this web service. When PASSWORD authtype is used, SKFS uses entries in a previously configured Lightweight Directory Access Protocol (LDAP) or Active Directory (AD) to authenticate the credential (see Manage Credentials under [ SKFS ⇒ Administration ⇒ Security ] for details). |
Value |
Explanation |
---|---|
username |
The name assigned by the web application to the user account registering the FIDO credential.
It is recommended that applications get the e-mail address from the user as part of the registration process, but that applications also generate a randomly generated string—such as a UUID—as the username in this webservice. This will ensure that the SKFS database holds no information that could be deemed PII. Applications may choose to still prompt users for their e-mail address to identify them; but once identified, the web application could lookup the UUID associated with that user and use it in this parameter to register a FIDO credential for the user. |
txid |
A string—with a maximum length of 256 characters—that represents a business application-defined unique transaction identifier. It can be anything that is appropriate to the business application. Some examples are shown below:
|
txpayload |
While this is intended to be free-form text with a maximum length of 10,000 characters, it is strongly recommended that it is a JSON object using a structure along the lines of the following (see the NOTE below for more info): {
"merchantName": "StrongKey",
"currency": "USD",
"totalPrice": "14995",
"cardBrand": "Amex",
"cardLast4": "x-1234",
"txid": "254900MS6G5FQCUJMZ97-TELLARO-1631149799",
"txdate": "Thu Sep 8 17:02:56 PDT 2021"
}
...and base64url-encode the object into something that resembles the following: ewogICAgIm1lcmNoYW50TmFtZSI6ICJTdHJvbmdLZXkiLAogICAgImN1cnJlbmN5IjogIlVTRCIsCiAgICAidG90YWxQcmljZSI6ICIxNDk5NSIsCiAgICAiY2FyZEJyYW5kIjogIkFtZXgiLAogICAgImNhcmRMYXN0NCI6ICJ4LTEyMzQiLAogICAgInR4aWQiOiAiMjU0OTAwTVM2RzVGUUNVSk1aOTctVEVMTEFSTy0xNjMxMTQ5Nzk5IiwKICAgICJ0eGRhdGUiOiAiVGh1IFNlcCA4IDE3OjAyOjU2IFBEVCAyMDIxIgp9
|
options |
A JSON object containing an optional list of features the web application may request of SKFS to associate with this authorization request. While the JSON object can contain one or more options, the UserVerification option must be present to require user identity verification for web services using SACL with the transaction confirmation web services.
|
appTXID |
An optional string within any SKFS web service request body's payload JSON object that, if added, will attach the appTXID value to the TXID logged by the server. |
NOTE: It is important to keep the transaction payload compact to ensure SKFS can combine it as quickly as possible with a randomly generated nonce (“number used once”) and generate a unique message digest (hash) that serves as the transaction’s unique challenge. This enables faster transaction processing on SKFS.
A JSON object makes the most sense because the mobile app and SACL lend themselves to parse and display the details appropriately within the limited Secure Display of small mobile screens.