8 Message Queue

This chapter describes the Message Queue (MQ), which provides asynchronous communication between the backend services of the Wallet Provider: the Wallet Provider Backend (WB), the Remote Wallet Secure Cryptographic Application (RWSCA), the Mobile Device Vulnerability Management (MDVM) and the Push Notification Service (PNS).

The MQ decouples the publication of an event from its processing: events published to a queue are persisted, so a temporarily unavailable consumer processes pending events as soon as it is available again, instead of the producer having to retry failed requests. Consumers acknowledge an event only after it has been processed successfully; events that are not acknowledged are redelivered. Events are therefore delivered at least once and the processing of every event is designed to be idempotent. The MQ is only reachable within the Wallet Provider's backend infrastructure, producer and consumer connections are mutually authenticated via mTLS and publishing is restricted per queue to its designated producers.

Events published to the MQ identify the targeted Wallet Instance by the possession factor wi_mdvm_auth_pubk, the only identifier shared across all three backends. The wi_mdvm_auth_pubk needs to be serialized in a single canonical byte representation across all backends to avoid matching failures due to different encodings and serializations (e.g. compressed or uncompressed, DER or JWK, or serialized with JSON members in a different order). This is security-critical, as two representations of the same key could fail to match and thus not properly propagate the event. To avoid this, the backends derive the JWK Thumbprint of the key (RFC 7638) with SHA-256 hash and use it as the canonical value that is published to the MQ and used to look up and compare wi_mdvm_auth_pubk across backends. Because the construction ignores encoding choices, member order, and non-essential parameters, every backend computes the same thumbprint for the same key, independently and without coordination. Each backend stores this thumbprint as an indexed lookup key next to the full wi_mdvm_auth_pubk, which is retained for verifying the Wallet Instance's proofs of possession during authentication.

8.1 Revocation Queue

The revocation queue propagates wallet revocations between the backends, see revocation propagation between backends.

The producers are the WB and the MDVM, the initiating backend publishes one revocation event per affected Wallet Instance to the queue. All three backends(WB, MDVM and RWSCA) are consumers of the revocation queue and execute their respective Revoke Account operations (WB, MDVM and RWSCA) to block the affected accounts. A revocation event contains the JWK thumbprint of its wi_mdvm_auth_pubk, a timestamp and a revocation reason.

The processing of revocation events is idempotent, as marking an already revoked account as REVOKED has no further effect. Every backend, including the one that published an event, consumes all revocation events and executes its Revoke Account operation; if the initiating backend has already marked the affected account as revoked (as the MDVM does when it initiates the revocation), processing its own event has no further effect.

8.2 Push Notification Queue

The push notification queue sends push notifications to Wallet Instances through the push notification service of the Mobile Platform Provider (MPP).

The producer is the MDVM, as its Revoke Account operation requires sending push notifications for both user-initiated and MDVM-initiated revocation. The PNS is the consumer of the events and executes its Send Push Notification operation to deliver the notification to the MPP. A push notification event contains the JWK thumbprint of its wi_mdvm_auth_pubk, a timestamp and an instruction for the WI to check it's revocation status (further instructions may be added in the future).

The processing of push notification is idempotent, as resending the notification to the WI only retriggers the instruction for the WI. The queue provides a retry mechanism in case of the MPP not being available, unacknowledged events are redelivered instead of each publishing operation implementing its own mechanism.

8.3 Purge Queue

The purge queue propagates the deletion of the accounts of Wallet Instances that exceeded the data retention period, see backend deletion.

The MDVM is the only producer, as it is the backend that maintains the last-seen timestamp of a Wallet Instance and therefore evaluates the retention period. It publishes one purge event per affected Wallet Instance to the queue. All four backends (WB, MDVM, RWSCA and PNS) are consumers of the purge queue and execute their respective Purge Account operations (WB, MDVM, RWSCA and PNS) to delete all data of the affected accounts. A purge event contains the JWK thumbprint of its wi_mdvm_auth_pubk and a timestamp.

The processing of purge events is idempotent, as the deletion of an already deleted account has no further effect. Every backend, including the MDVM as the producer of the events, consumes all purge events and executes its Purge Account operation. The backends delete their accounts independently from each other, as the operations are internal and the Wallet Instance is not involved.