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 producers are the WB and the MDVM, as they require sending push notifications for user-initiated revocation or MDVM-related 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.