Thales device bound key extension

The device bound key (DBK) extension (thalesgroup_dbk_ext) enables your application to associate a hardware-backed cryptographic key with a FIDO credential. This extension allows the device to generate and store a device-bound key that is tied to the authenticator, providing an additional layer of security for authentication flows that require key binding.

The use of this extension is optional.

Overview

When the DBK extension is used, the FIDO server coordinates the creation and management of device-bound keys:

• During registration (attestation), your application specifies the allowed cryptographic algorithms for the device-bound key. The server generates a key identifier (kid) and returns it to the client.
• During authentication (assertion), your application uses the previously bound key to sign the assertion. The server validates the signature and verifies the device-bound key is still valid.

A single authenticator can have multiple device-bound keys. The number of allowed bindings can be limited via the authenticator policy.

Registration (Attestation)

Options request

To activate the DBK extension during registration, include the thalesgroup_dbk_ext object in the extensions field of the attestation options request body. Specify the list of allowed COSE algorithm identifiers for the device-bound key:

{
    "userId": "VTBUODQwMC1lMjliLTQxZDQtYTcxNi00NDY2NTU0NDAwMDA",
    "displayName": "testUser1",
    "relyingPartyOptions": {
        "rp": {
            "id": "myawesomesite.com",
            "name": "myawesomesite.com",
            "origins": [
                "https://myawesomesite.com"
            ]
        }
    },
    "extensions": {
        "thalesgroup_dbk_ext": {
            "allowedAlgorithms": [-7],
            "v": 1
        }
    }
}

You can optionally supply a dbkKid query parameter to specify an existing device-bound key identifier if you want to reuse an existing key during registration.

Options response

The server returns the thalesgroup_dbk_ext object in the options response, including the generated kid and the confirmed list of allowed algorithms:

{
    "extensions": {
        "thalesgroup_dbk_ext": {
            "allowedAlgorithms": [-7],
            "kid": "dbk_kid_123",
            "v": 1
        }
    }
}

The kid value must be passed to the authenticator to bind the device key.

Authentication (Assertion)

Options request

To use a previously bound device key during authentication, include the thalesgroup_dbk_ext object in the assertion options request body:

{
    "userId": "VTBUODQwMC1lMjliLTQxZDQtYTcxNi00NDY2NTU0NDAwMDA",
    "relyingPartyOptions": {
        "rp": {
            "id": "myawesomesite.com",
            "name": "myawesomesite.com",
            "origins": [
                "https://myawesomesite.com"
            ]
        }
    },
    "extensions": {
        "thalesgroup_dbk_ext": {
            "v": 1
        }
    }
}

You can optionally supply a dbkKid query parameter to specify which device-bound key to use for signing.

To create a new device-bound key during authentication (for example, when the existing key has been lost), set allowNewDbkBinding: true:

{
    "userId": "VTBUODQwMC1lMjliLTQxZDQtYTcxNi00NDY2NTU0NDAwMDA",
    "relyingPartyOptions": {
        "authenticationTimeout": 30000,
        "rp": {
            "id": "myawesomesite.com",
            "name": "myawesomesite.com",
            "origins": [
                "https://myawesomesite.com",
                "android:apk-key-hash-sha256:6dTaEM3TD8KwxMDxgpSe8otNMjdzlxSkj/6Spbc/qwE="
            ]
        }
    },
    "extensions": {
        "thalesgroup_dbk_ext": {
            "allowNewDbkBinding": true,
            "v": 1
        }
    }
}

Options response

The server returns the thalesgroup_dbk_ext object in the options response, including the kid to be used by the client:

{
    "extensions": {
        "thalesgroup_dbk_ext": {
            "kid": "dbk_kid_123",
            "v": 1
        }
    }
}

Managing device-bound keys

Viewing bound keys

Device-bound key information is visible in the get authenticator and list authenticators admin API responses under the dbk array field:

{
    "dbk": [
        {
            "kid": "dbk_kid_123",
            "lastUsedDateTime": "2026-01-15T10:30:00Z"
        }
    ]
}

Deleting device-bound keys

Device-bound keys are removed when the associated authenticator is deleted. You can also delete individual DBK bindings without deleting the authenticator itself.

To delete a specific device-bound key binding, use the following endpoint:

DELETE /authenticators/{credId}/dbk/{dbkKid}

Required parameters:

• credId — the credential ID of the authenticator (Base64URL encoded)
• dbkKid — the key identifier (kid) of the device-bound key binding to delete
• userId or username — the identifier of the user who owns the authenticator

This operation requires the fido2_server-authenticator_delete_dbk role. If the deleted binding was the last authenticator using that DBK public key, the public key is also removed from the server.

Example:

DELETE /authenticators/h_0I4nKMO0wwXZRlK.../dbk/dbk_kid_123?userId=VTBUODQwMC1lMjli...

Limiting device-bound keys per authenticator

You can configure the maximum number of device-bound keys allowed per authenticator using the maxDbkPerAuthenticator field in the authenticator policy. The default limit is 5 device-bound keys per authenticator. See authenticator policy overview for details.