]> LoginRadius

jyotirmoy.bandyopadhayaya@loginradius.com

Security Web Authorization Protocol OAuth CIBA push authentication device binding A companion specification, "Discovery and Device Lifecycle for OAuth Push-Based Authentication", defines a generic, back-channel-protocol-agnostic device registration, attestation, and lifecycle layer for out-of-band OAuth 2.0 authenticator devices. This document is the thin binding that lets a device registered under that specification be woken by OpenID Connect Client-Initiated Backchannel Authentication (CIBA) Core's authorization endpoint: one request parameter, one additive error code, and a statement of how CIBA's existing binding_message composes with the base document's interaction-type ceremony. This document adds no new endpoints and no new discovery fields of its own.

Introduction (the "base document") defines a generic device registration, attestation, and lifecycle layer. This document binds that generic layer to OIDC CIBA Core 's /bc-authorize endpoint. Everything other than the two additive elements defined here, discovery document shape, registration, revocation, key rotation, device management, account recovery, push transport, and the attestation and registry trust model, is defined entirely by the base document and is not repeated here. 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): one generic protocol-facing layer, and one thin binding to a specific consuming interface.

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. This document uses the terminology defined in , and the terminology defined in OIDC CIBA Core (in particular auth_req_id and binding_message).

Relationship to Existing Standards OIDC CIBA Core defines /bc-authorize, auth_req_id, and the poll/ping/push delivery modes, plus discovery fields on /.well-known/openid-configuration. It assumes an authenticator is already registered with the AS; fills that gap generically, and this document connects the two. An AS implementing this binding publishes both discovery documents: /.well-known/openid-configuration (with CIBA's standard fields, including backchannel_authentication_endpoint) and /.well-known/oauth-push-notification (per ). The two are independent documents operated by the same AS; nothing in either is required to reference the other. This binding modifies CIBA's request/response surface in exactly two places (, ) and nowhere else. All device registration, key rotation, revocation, and push transport happen exactly as defines, with zero CIBA-specific variation.

Device Revocation and the CIBA Error Surface The base document requires that revoking a device cascade to invalidate any pending authentication request bound to it, and defers the concrete error shape to the consuming protocol's binding. For CIBA:

• A revoked device's credential resolving during /bc-authorize, or a poll on an already-issued auth_req_id bound to a now-revoked device, MUST return device_revoked as an additive CIBA error, using the same response shape as CIBA's existing access_denied error.
• This is the only modification this binding makes to CIBA's response surface. It is purely additive: CIBA-compliant ASes that do not implement this binding are unaffected, and existing CIBA clients that do not recognize device_revoked degrade to generic error handling per (an unrecognized error value).
• The base document's revocation wake signal ({"wake_reason": "device_revoked", "ref_id": "{device_id}"}) is unchanged by this binding; the application's local key wipe happens identically regardless of which consuming protocol triggered the revocation.

interaction_type on the Authorization Request The base document defines the interaction_type ceremony vocabulary (boolean, number_choose, input_manual) and the discovery-level interaction_type_supported / minimum_interaction_type fields, but leaves per-request selection and content-carrying to the consuming protocol. For CIBA:

• /bc-authorize gains an interaction_type request parameter. The RP selects a value per request; the AS MUST reject a value weaker than minimum_interaction_type with CIBA's existing invalid_request error. The downgrade-protection requirement is enforced identically to the base document's general rule, surfaced through CIBA's existing error vocabulary rather than a new error code.
• Composition with CIBA's existing binding_message:

  interaction_type=boolean

  binding_message is unchanged: purely advisory display, exactly as CIBA defines it today.

  interaction_type=number_choose

  The AS populates binding_message with the real number the RP displays; decoy numbers are generated by the AS and delivered exclusively via the base document's authenticated pull step, never in the CIBA request or the opaque wake push.

  interaction_type=input_manual

  binding_message carries the code the user transcribes.

• If the RP omits interaction_type, the AS uses minimum_interaction_type as the default: an RP never receives a weaker ceremony than the AS's floor by omission.

Scope Boundary For the avoidance of doubt: discovery document shape and fields, registration flow (including the registration-token JWT, the PAR-pattern registration POST, and the push_device scope), key rotation (grace window, DPoP binding, replay nonce), device management (max_devices_per_user, atomic device replacement, primary-device selection), account recovery, push transport (opaque wake payload, mandatory JWE, signed downgrade reporting), and the trust/attestation model (registry BLOB format, root pinning, registry-list redundancy) are all defined solely by and apply to a CIBA-binding AS exactly as written there. This document adds no new endpoints and no new discovery fields.

Security Considerations This document inherits all security properties of without modification; see that document's Security Considerations section. The device_revoked error () is purely additive to CIBA's error surface and introduces no new attack surface beyond what access_denied already exposes: it discloses only that a given device is revoked, which the party attempting /bc-authorize for that device already necessarily controls or has observed failing. The interaction_type downgrade protection () is the mechanism that specifically defends against MFA-fatigue/prompt-bombing attacks for CIBA-bound deployments; an AS that fails to enforce minimum_interaction_type reintroduces that exposure despite implementing the base document correctly.

IANA Considerations This document defines no new discovery fields, endpoints, or well-known URIs; all IANA actions are performed by . This document defines one new CIBA error code, device_revoked (), and one new CIBA authorization-request parameter, interaction_type (); if CIBA Core or a future revision thereof establishes an IANA registry for its error codes or request parameters, this document's values should be registered there.

Normative References Informative References W3C

Acknowledgments This document's structure follows the companion-specification precedent of WebAuthn and CTAP, cited in .