]> LoginRadius

jyotirmoy.bandyopadhayaya@loginradius.com

Security Web Authorization Protocol OAuth push authentication CIBA device registration attestation This document defines a discovery, registration, attestation, and device-lifecycle layer for out-of-band OAuth 2.0 authenticator devices, allowing a single spec-compliant authenticator application to register with, and receive push-based wake signals from, any conforming Authorization Server, without requiring the Authorization Server operator to build and distribute its own dedicated mobile application. This document is intentionally agnostic to which back-channel authentication protocol ultimately consumes it; OpenID Connect Client-Initiated Backchannel Authentication (CIBA) Core is its first binding, defined in a separate companion document, but nothing in this document depends on CIBA or on OpenID Connect.

Introduction Push-based multi-factor authentication (MFA) today is implemented as a closed, vertically integrated stack per Authorization Server (AS) vendor: a proprietary API, a proprietary push backend, and a proprietary mobile application. This produces three compounding costs for application and AS developers:

1. Vendor lock-in — the authenticator application only speaks to the AS that shipped it.
2. Fragmentation — no shared registration ceremony exists, unlike (TOTP), where any application can generate codes for any AS from a shared secret.
3. Developer cost — offering push MFA requires building and maintaining a full mobile application, not just a backend integration.

This document defines a registration and device-lifecycle layer that removes these costs by letting any spec-compliant authenticator application serve push MFA for any spec-compliant AS.

Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

AS

Authorization Server.

RP

Relying Party.

Authenticator

The generic, spec-compliant push-MFA client application defined by this document.

Relay

The authenticator vendor's shared platform-push (APNs/FCM) integration point.

Consuming protocol

A back-channel authentication protocol (e.g. OIDC CIBA Core) that wakes a device registered under this document via a companion binding specification.

Relationship to Existing Work (Pushed Authorization Requests, PAR) covers moving authorization request parameters to a back-channel POST before redirect. It does not address push delivery or out-of-band devices. This document does not depend on PAR or its pushed_authorization_request_endpoint; instead borrows PAR's design pattern (pushing sensitive parameters over a back-channel POST and receiving a short-lived opaque reference in return) as its own self-contained mechanism. (OAuth 2.0 Authorization Server Metadata) establishes the pattern this document follows for its own discovery document: a dedicated well-known metadata document with additive-only evolution and no explicit version field (). OIDC CIBA Core defines /bc-authorize, auth_req_id, and the poll/ping/push delivery modes. This document does not reference or depend on CIBA; a device registered per this specification is usable by any back-channel authentication protocol that defines a binding to it. A companion document defines the CIBA binding: an interaction_type request parameter on /bc-authorize () and a device_revoked error extending CIBA's error surface (). This split follows the precedent of WebAuthn (a browser-facing API defined by the W3C) and CTAP (an authenticator-facing protocol defined by the FIDO Alliance) as companion specifications from different bodies serving different interfaces to the same underlying model. This document defines the registration and lifecycle layer; it takes no position on, and places no requirements on, the authentication protocol that ultimately wakes a registered device.

Discovery Document A conforming AS publishes a discovery document at a dedicated well-known URI , following the pattern rather than extending /.well-known/openid-configuration. This keeps the push-auth metadata document independently versionable and cacheable, at the cost of a second discovery round trip for clients that need both documents. A CIBA-binding AS additionally publishes CIBA's own discovery fields per the companion binding document; the two documents are independent but MAY be operated by the same AS simultaneously. GET /.well-known/oauth-push-notification HTTP/1.1 Host: oauth.example.com Fields are flattened, not nested, to match established discovery document convention and to simplify JSON Schema validation. The document SHOULD be published against a formal JSON Schema (2020-12 ); field registration follows an IANA registry established by this document (), so new fields, including protocol-binding-specific ones defined by companion documents, can be added without a version bump.

Versioning This document defines no explicit version field. Following precedent, evolution is purely additive: new capabilities are advertised via new _supported arrays or new optional fields, and conformant clients MUST ignore members they do not recognize. A version field would solve a breaking-change problem this specification does not yet have; one can be introduced later without disruption if that changes.

Error Response Format All endpoints defined in this document (registration_endpoint, revocation_endpoint, key_rotation_endpoint, device_management_endpoint) return errors as application/problem+json per , not the bare OAuth error/error_description shape from : these endpoints need extension members that shape does not accommodate cleanly. Error Registry

Type slug	Status	Meaning
registration_token_already_used	400	Token already redeemed (register)
registration_token_expired	400	Token used past its TTL (register)
attestation_missing	400	Attestation required but absent (register)
attestation_invalid	403	Attestation failed verification (register)
attestation_untrusted	403	Issuer not trusted/below minimum level (register)
interaction_type_unsupported	400	Device below the AS's minimum ceremony (register)
nonce_replayed	400	Replay-Nonce reused/missing (revoke, rotate)
rate_limited	429	Too many requests (register, revoke, rotate)

A consuming protocol's binding document MAY define additional error codes for its own wake surface (e.g. the CIBA binding's device_revoked, returned from /bc-authorize) without modifying this registry. registration_endpoint MUST return 429 with a Retry-After header on excessive attempts, keyed by source IP and/or registration token; this is the highest-value pre-authentication enumeration target. revocation_endpoint and key_rotation_endpoint SHOULD apply the same, keyed by device_id.

Interaction Type (User Approval Ceremony) interaction_type describes the ceremony the user performs on the authenticator when a request lands, a distinct concern from delivery_modes_supported, which is transport (push/ping/poll), not interaction. Three values are defined:

boolean

Plain approve/deny. The legacy default; vulnerable to MFA-fatigue ("prompt bombing") because the user can dismiss an unwanted prompt with a single tap under pressure.

number_choose

The consuming protocol's front end displays a number; the user must pick the matching number from a small set (the real value plus decoys) shown in the authenticator application. This is the industry-standard mitigation for MFA fatigue, formalized in CISA guidance .

input_manual

The user transcribes a code shown on one device into the other. The correct fallback shape when a richer UI cannot be shown (feature phones, accessibility, or the poll-only degraded path in ).

Rich transaction detail (e.g. "Approve $500 to X") and biometric-gated local confirmation are explicitly not additional interaction_type values; they are payload-content and local-authorization concerns respectively, and compose with any of the three values above rather than replacing them. This document defines the ceremony vocabulary and the discovery-level capability/floor fields (interaction_type_supported, minimum_interaction_type). It does not define how a specific back-channel authentication protocol requests a ceremony per request, or carries the ceremony's content to the user; that is a binding concern, defined by the companion CIBA binding document for CIBA specifically. Downgrade protection: minimum_interaction_type lets the AS set a floor: a consuming protocol's binding MUST NOT allow a caller to request an interaction_type weaker than the AS's floor. Without this, a caller could request boolean on every request regardless of AS risk policy, silently bypassing anti-fatigue protection the AS intends to enforce. Unsupported type: if an authenticator's registration-time capability list () does not include the AS's minimum_interaction_type, the AS MUST reject registration with interaction_type_unsupported rather than accepting the device and silently degrading to boolean at wake time. A silent degrade would recreate the exact fatigue exposure number_choose exists to close.

Registration Flow

1. The user scans a QR code encoding a URL with the registration token in the fragment, not the userinfo component: https://oauth.example.com/push/enroll#{REGISTRATION_TOKEN}. Fragments are never transmitted to servers, proxies, or logged in access logs, unlike the deprecated user:pass@host userinfo form (), which risks leaking the token via browser history, referrer headers, and QR-scanner applications that open the link in a WebView before the authenticator ever sees it. Authenticator vendors MAY alternatively register a custom URL scheme for direct OS-level handling.
2. REGISTRATION_TOKEN is itself a signed JSON Web Token (JWT) containing:

   iss

   The AS.

   client_id

   The OAuth client_id already registered at the AS (via dynamic registration or static onboarding) whose authentication requests the device is being enrolled to receive.

   sub

   The user being enrolled.

   exp

   Matches registration_token_ttl.

   jti

   Unique token identifier, used for single-use enforcement.

3. The authenticator resolves the discovery document at the host encoded in the token's iss.
4. The authenticator POSTs to registration_endpoint with the registration token, its push address (an APNs or FCM token, delivered via the relay), a public key, the interaction_type values it supports (), and attestation evidence per client_attestation_required (). The AS MUST reject registration with interaction_type_unsupported if the device's supported set does not include minimum_interaction_type. This POST is modeled on the design pattern of , not on PAR itself: sensitive registration parameters are pushed over a back-channel POST and the AS returns a short-lived opaque reference plus the durable device credential: The AS MUST reject a jti it has already consumed (registration_token_already_used) and MUST reject a token presented past exp (registration_token_expired). The AS MUST purge the consumed-jti record only after exp has passed, not before, so an expired-but-unconsumed token cannot be replayed after its record is dropped.
5. device_credential is scoped push_device, restricted to exactly: resolution by the consuming authentication protocol (a device-address lookup, not a bearer-scope check), and self-service calls to revocation_endpoint / key_rotation_endpoint for the same device (push:revoke:self, push:rotate:self). AS admin console and RP-triggered revocation use distinct scopes (push:revoke:admin, push:revoke:rp respectively; see ).
6. Once registered, the device is discoverable by any back-channel authentication protocol for which the AS has a binding; see the relevant companion document for how that protocol locates and wakes the device.

Device Lifecycle

Revocation This endpoint follows the general revocation model of (an authenticated POST that invalidates a credential), extended with the device-specific cascade and scope requirements below.

• Idempotent: revoking an already-revoked device returns 200.
• Must cascade: any pending authentication request bound to the device MUST be invalidated immediately. A consuming protocol's binding document defines how this surfaces to that protocol's callers (e.g. CIBA's device_revoked error); this document only requires that the cascade happen.
• The AS SHOULD push a wake signal so the application can clear local key material without waiting for its next authentication attempt. This reuses the same opaque wake-and-pull mechanism as ordinary authentication requests (): there is no separate revocation payload shape. The application performs its normal authenticated pull to retrieve the reason and wipe local key material.
• Distinct callers (application self-revocation, AS admin console, RP-triggered offboarding) MUST use distinct token scopes: push:revoke:self, push:revoke:admin, push:revoke:rp respectively.
• Requests MUST include a Replay-Nonce (issued by the AS on the prior response, per the pattern of ) as a JWS-protected nonce claim over the request body. The AS validates single use and rejects reused or missing nonces with nonce_replayed.

Key Rotation Rotation MUST be signed by the outgoing key. Without proof of possession, rotation is a forgeable takeover path for anyone holding a stolen device_id and bearer token.

• Grace window: the old public key remains valid for verification by the consuming authentication protocol until either (a) the new key completes one successful signed authentication, or (b) grace_period_seconds elapses (AS-configured, RECOMMENDED default 300), whichever occurs first. Rotation confirmation is asynchronous: the AS MUST NOT invalidate the old key synchronously in the rotate-key response, since an in-flight authentication request may already be signed under it. When the rotation reason is compromised rather than routine, the AS SHOULD reduce or skip the grace window.
• Replay protection: same Replay-Nonce requirement as .
• Credential binding: device_credential itself is bound using DPoP to the key established at registration: a jkt thumbprint is embedded in the credential at issuance, and rotate/revoke/device-management calls MUST present a DPoP proof for that key. This extends the same binding already requires for the pull step to the credential itself, so credential theft alone, without the private key, is insufficient to rotate or revoke a device.

Device Management Returns the list of registered devices (platform, registration time, last used, attestation status) backing a user-facing "manage your devices" view.

• The AS enforces max_devices_per_user (discovery document, RECOMMENDED default 5, AS-configurable) at registration time.
• Device replacement is a distinct, atomic ceremony from plain add-new-device: pass replaces_device_id on the registration POST (). The old device is revoked only upon successful completion of the new device's registration, avoiding a lockout if registration fails partway through. Plain registration (without replaces_device_id) is subject to the max_devices_per_user cap.
• Primary-device selection: the RECOMMENDED default is to wake only the most-recently-used registered device, not fan out to all, matching common industry practice rather than a multi-authenticator fan-out model, since push MFA lacks a synchronous prompt moment to let the user disambiguate which device just alerted. A device MAY be marked is_primary via device_management_endpoint to override recency-based selection. An AS or RP MAY instead opt into a fan-out-to-all mode as a documented alternative. A stated default matters here because this document's value proposition depends on one generic authenticator application behaving predictably across different AS implementations.

Account Recovery A hard lockout (device lost, no other device registered) is out of scope for the device protocol itself; recovery mechanisms embedded in the credential protocol tend to become bypass vectors. It MUST have a defined path at the AS/tenant level:

• Mandatory baseline: admin-console-forced re-registration. A tenant or AS admin MAY revoke all devices for a user (push:revoke:admin) and issue a fresh registration token out of band (e.g. via a verified-identity support flow), re-entering the flow at . This requires no new protocol mechanism; it is existing revoke plus existing registration, admin-initiated.
• Optional enhancement: the AS MAY support single-use backup codes, issued at registration time, redeemable by the consuming authentication protocol in place of a device-signed assertion, for self-service recovery when no device is reachable. Backup codes reintroduce a shared-secret bearer credential and reduce the phishing-resistance value of device attestation; RPs SHOULD gate this by risk tier rather than enabling it by default.

Push Transport Three delivery approaches were evaluated: Delivery Approaches

Approach	Verdict
Poll (user-initiated)	Fallback only; no ambient nudge
AS to APNs/FCM directly	Rejected; recreates per-AS platform lock-in
Push via relay	Recommended; only the authenticator vendor needs platform push credentials

Payload security requirements:

• The push payload MUST be an opaque wake signal only: No scope, binding message, or user context, since platform push infrastructure can inspect payloads in transit. A single wake shape covers both ordinary authentication requests and device-revocation signals; there is no separate revocation payload type.
• On wake, the application MUST perform an authenticated pull (mTLS or a DPoP-bound token) to retrieve request details.
• The pull response MUST be encrypted to the device's registered public key (JWE), mirroring the Web Push encryption model of , which mandates payload encryption to the subscriber's public key precisely because push infrastructure is an untrusted intermediary. This converts the relay from a trusted courier into a zero-trust hop that only ever sees ciphertext plus a routing reference (ref_id is deliberately not secret; it is routing metadata only).
• The authenticator's report of which delivery mode it actually used (push vs. poll fallback) MUST itself be signed by the device key and logged by the AS. The AS SHOULD alert or step-up-challenge on repeated push-to-poll fallback from the same device. This does not prevent an attacker from blocking push at the network layer, but makes a forced downgrade observable and rate-limitable instead of silent.
• Push-wait timeout: APNs and FCM are both best-effort platforms with no contractual delivery guarantee. This document does not attempt to specify a relay uptime commitment; that is a business matter between the AS and the relay operator, out of scope here, matching and , which likewise specify only protocol timeouts, never operator SLAs. What this document does specify: the client MUST NOT switch to active polling before push_wait_timeout_seconds (discovery document, RECOMMENDED default 10) has elapsed since the wake was expected, and MUST switch to polling at the consuming protocol's own poll interval once it has. This bounds worst-case wake latency to push_wait_timeout_seconds plus one poll interval without the two timers racing.

A persistent socket (WebSocket or MQTT) in place of platform push is explicitly rejected: it does not survive OS-level application suspension and defeats the purpose of platform push.

Trust Model A three-tier attestation ladder, modeled on WebAuthn/FIDO2 :

1. Device integrity (required): App Attest / Play Integrity API. Proves the running binary is unmodified and on a genuine device.
2. Authenticator attestation: a WebAuthn-style attestation object, signed by the authenticator vendor's build-time root key, proving which vendor produced this instance.
3. Vendor registry: the AS checks the attestation certificate against trusted_authenticator_registries, one or more neutral, certified metadata services modeled directly on the FIDO Alliance's Metadata Service (MDS) . Default-deny unless listed.

Registry entries are distributed as a signed JWT BLOB (MetadataBLOBPayload), adopting the FIDO MDS3 format: a single JWT signed by the registry operator's root key, containing per-authenticator entries (attestation root certificates, status reports), served over HTTPS with the signature providing integrity independent of transport. The AS MUST pin the registry's root signing certificate (distributed out of band, as with FIDO MDS's root) and the registry operator MUST publish a documented key-rotation ceremony (overlap period plus published fingerprint) before retiring a root key. trusted_authenticator_registries accepts a list rather than a single URL so an AS can configure fallback registries. A registry operator MUST publish a successor pointer before ceasing operation, so ASes and vendors have a migration path rather than a silent single point of failure. Governance model: multi-registry federation. No single body operates trusted_authenticator_registries; each AS or tenant owner configures its own list of trusted registries, choosing which neutral, certified metadata services it recognizes. This is distinct from per-AS authenticator allowlisting, which remains explicitly rejected, since it recreates vendor lock-in one layer up: the AS is choosing which registry operators it trusts, not which individual authenticator vendors. A protocol-level meta-registry (a curated "list of known registries") was considered and rejected: the closest real precedent for a federation-of-registries aggregator shows that a non-binding aggregator tends to accrete de facto gatekeeping authority once relying parties begin treating inclusion as a legitimacy signal, recreating the single-curator capture risk the federation model exists to avoid. Registry discovery is therefore left entirely out of band (specification text, vendor documentation, industry reputation). Per-AS bespoke allowlisting of individual authenticator vendors is explicitly out of scope and rejected; it recreates fragmentation one layer up. AS signing-key rotation (the AS's own protocol-signing keys, as distinct from device keys above) is out of scope for this document: it composes with existing jwks_uri and kid-tagged multi-key JWKS rotation per and requires no additional device-side handling.

Security Considerations This section consolidates security properties defined throughout this document. Registration token exposure. The registration token is carried in a URL fragment rather than the userinfo component (), since fragments are never sent to servers, proxies, or recorded in access logs; userinfo-form URLs are a known credential-leak vector and are deprecated by . Replay protection. Registration tokens are single-use, enforced via jti consumption (). Revocation and key-rotation requests require a Replay-Nonce (, ) modeled on . Credential binding. device_credential is DPoP-bound () to the key established at registration (), so credential theft alone, without the corresponding private key, is insufficient to rotate or revoke a device. Key-rotation takeover. Rotation requires proof of possession signed by the outgoing key (); without this, rotation would be a forgeable takeover path for anyone holding a stolen device_id and bearer token. Relay as an untrusted intermediary. Pull responses are mandatorily JWE-encrypted to the device's public key (), converting the relay into a zero-trust hop that only ever observes ciphertext and a non-secret routing reference. Downgrade attacks. A client's report of which delivery mode it actually used is signed and logged (), so an attacker forcing a fallback from push to poll at the network layer produces an observable, rate-limitable signal rather than a silent downgrade. Similarly, minimum_interaction_type () prevents an RP from silently requesting a weaker approval ceremony than the AS's risk policy requires, which is the mechanism that specifically defends against MFA-fatigue/prompt-bombing attacks. Attestation and registry trust. The three-tier attestation ladder and signed-BLOB registry distribution () bound the impact of a compromised or malicious authenticator vendor; registry root-key pinning and a mandatory successor-pointer requirement bound the impact of a registry operator's key compromise or cessation of operation. Backup codes. The optional account-recovery backup-code mechanism () reintroduces a shared-secret bearer credential and reduces the phishing-resistance value that device attestation otherwise provides; implementers are advised to gate its availability by risk tier rather than enabling it unconditionally.

IANA Considerations

Well-Known URI Registration This document requests IANA register the following well-known URI in the "Well-Known URIs" registry defined by : oauth-push-notification Well-Known URI

Field	Value
URI suffix	oauth-push-notification
Change controller	IETF
Specification document	This document
Status	permanent

OAuth Push-Auth Discovery Metadata Registry This document requests IANA establish a new registry, "OAuth Push-Auth Discovery Metadata", under the existing OAuth parameters registry group, using the same registration procedure (Specification Required, per ) as the "OAuth Authorization Server Metadata" registry established by . The initial contents are the field names defined in : registration_endpoint, delivery_modes_supported, interaction_type_supported, minimum_interaction_type, registration_token_ttl, signing_alg_values_supported, push_relay_endpoint, fallback_order, client_attestation_required, trusted_authenticator_registries, minimum_attestation_level, revocation_endpoint, key_rotation_endpoint, device_management_endpoint, max_devices_per_user, push_wait_timeout_seconds, and error_response_format. Error type values defined in are identified by URI as required by and do not require a central IANA registry.

Open Issues This section is to be removed before publication as an RFC.

• Relay SLA business terms remain outside this document's scope by design (); the protocol-level bound is push_wait_timeout_seconds.
• Registry-discovery convenience. Whether a non-normative, unofficial community page listing known registries is worth maintaining outside this document, given the rejection of a protocol-level meta-registry ().

Normative References Informative References W3C FIDO Alliance Cybersecurity and Infrastructure Security Agency JSON Schema Organization

Acknowledgments The design of this document draws on prior art from the OAuth, OpenID Connect, WebAuthn/FIDO2, ACME, and Web Push communities, each cited at the relevant point in the text.