Device licensing compatibility

Device licensing and status originated in the TrustMint Android SDK and belong conceptually to unified DDI. They are not yet a live public DDI capability. EntitleKit owns license approval, refusal, subscription, and billing management; device applications must not call EntitleKit management APIs directly.

Current availability

The Android binding models these intended device-mTLS calls:

SDK operation	Intended relative route	Managed status
getStatus()	/<thing_id>	not published
requestLicense(type, appletId)	/<thing_id>/license/request	not published
renewLicense()	/<thing_id>/license/renew	not published
getTelemetryConfig()	/<thing_id>/telemetry/config	legacy; not published

With SdkConfig.apiBaseUrl=https://things.flexgalaxy.ai, the inherited DdiApiClient resolves these below /ddi/v1. The managed gateway does not currently serve them. Do not ship a workflow that depends on these calls until the routes, mTLS identity binding, EntitleKit integration, and conformance tests are published in Runtime surface.

They also depend on the Android facade’s internal enrollment store. Version 1.1.0 provisionDevice() does not populate that store and exposes no public import method, so the high-level licensing methods are not reachable through a fresh DDI provisioning flow without changing the binding.

Android compatibility API

TrustMintSDK exposes:

• getStatus() -> LicenseManager.DeviceStatus

• requestLicense(licenseType, appletId) -> LicenseRequestResult

• renewLicense() -> TokenResult

• getOfflineLicenseStatus() -> LicenseStatus

• setLicenseStatusListener(listener)

LicenseStatus values are VALID, EXPIRED, RENEWAL_NEEDED, NONE, PENDING, and REFUSED. The SDK schedules periodic renewal with WorkManager after enrollment, using the configured interval, and persists a returned token.

Offline status is not authorization

The current getOfflineLicenseStatus() implementation decodes JWT claims and checks only structure and exp. It does not verify the JWT signature, issuer, audience, subject-to-certificate binding, revocation, or applet claim. It therefore answers only “does this stored token look unexpired?”

Never use this result to unlock paid or safety-sensitive functionality. Until a signature-verifying validator and trusted key-distribution contract ship, use it only as a UI/cache hint and fail closed when authoritative status is unavailable. Absence of exp is treated as valid by the compatibility implementation, which is another reason it is unsuitable as an enforcement boundary.

Target device contract

Before device licensing can be marked live, the managed implementation must:

1. derive thing_id from the verified device certificate, never a path or body field alone;

2. authorize the device, applet, account, and requested license type;

3. forward approval/refusal state from EntitleKit without exposing an integrator AK/SK to the device;

4. issue signed, short-lived tokens with explicit issuer, audience, subject, applet, license state, and expiration claims;

5. provide signature-verification keys with rotation and cache rules;

6. define revocation and offline grace behavior;

7. implement Python, Android, and C parity or explicitly scope supported terminals; and

8. publish end-to-end tests and the live routes in the runtime matrix.

External integrators that approve or refuse requests use EntitleKit’s external API with their own AK/SK. That is a server-to-server management integration, not a DDI device credential or device route.