Web Authorization Protocol J. Bandyopadhayaya Internet-Draft LoginRadius Intended status: Standards Track 29 July 2026 Expires: 30 January 2027 CIBA Binding for OAuth Push-Based Authentication Device Discovery draft-bandyopadhayaya-oauth-ciba-push-binding-00 Abstract 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. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 30 January 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Bandyopadhayaya Expires 30 January 2027 [Page 1] Internet-Draft CIBA Push Device Binding July 2026 Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 2. Relationship to Existing Standards . . . . . . . . . . . . . 3 3. Device Revocation and the CIBA Error Surface . . . . . . . . 3 4. interaction_type on the Authorization Request . . . . . . . . 4 5. Scope Boundary . . . . . . . . . . . . . . . . . . . . . . . 4 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 8. Normative References . . . . . . . . . . . . . . . . . . . . 5 9. Informative References . . . . . . . . . . . . . . . . . . . 6 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction [I-D.bandyopadhayaya-oauth-push-device] (the "base document") defines a generic device registration, attestation, and lifecycle layer. This document binds that generic layer to OIDC CIBA Core [OIDC.CIBA]'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 [WebAuthn2] (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. 1.1. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Bandyopadhayaya Expires 30 January 2027 [Page 2] Internet-Draft CIBA Push Device Binding July 2026 This document uses the terminology defined in [I-D.bandyopadhayaya-oauth-push-device], and the terminology defined in OIDC CIBA Core [OIDC.CIBA] (in particular auth_req_id and binding_message). 2. 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; [I-D.bandyopadhayaya-oauth-push-device] 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 [I-D.bandyopadhayaya-oauth-push-device]). 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 (Section 3, Section 4) and nowhere else. All device registration, key rotation, revocation, and push transport happen exactly as [I-D.bandyopadhayaya-oauth-push-device] defines, with zero CIBA-specific variation. 3. 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 Section 5.2 of [RFC6749] (an unrecognized error value). Bandyopadhayaya Expires 30 January 2027 [Page 3] Internet-Draft CIBA Push Device Binding July 2026 * 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. 4. 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. 5. 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 Bandyopadhayaya Expires 30 January 2027 [Page 4] Internet-Draft CIBA Push Device Binding July 2026 model (registry BLOB format, root pinning, registry-list redundancy) are all defined solely by [I-D.bandyopadhayaya-oauth-push-device] and apply to a CIBA-binding AS exactly as written there. This document adds no new endpoints and no new discovery fields. 6. Security Considerations This document inherits all security properties of [I-D.bandyopadhayaya-oauth-push-device] without modification; see that document's Security Considerations section. The device_revoked error (Section 3) 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 (Section 4) 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. 7. IANA Considerations This document defines no new discovery fields, endpoints, or well- known URIs; all IANA actions are performed by [I-D.bandyopadhayaya-oauth-push-device]. This document defines one new CIBA error code, device_revoked (Section 3), and one new CIBA authorization-request parameter, interaction_type (Section 4); 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. 8. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017, . [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, October 2012, . Bandyopadhayaya Expires 30 January 2027 [Page 5] Internet-Draft CIBA Push Device Binding July 2026 [OIDC.CIBA] Fernandez, G., Walter, F., Nennker, A., Tonge, D., and B. Campbell, "OpenID Connect Client-Initiated Backchannel Authentication Flow - Core 1.0", 2021, . [I-D.bandyopadhayaya-oauth-push-device] Bandyopadhayaya, J., "Discovery and Device Lifecycle for OAuth Push-Based Authentication", Work in Progress, Internet-Draft, draft-bandyopadhayaya-oauth-push-device- 00, July 2026, . 9. Informative References [WebAuthn2] W3C, "Web Authentication: An API for accessing Public Key Credentials Level 2", April 2021, . Acknowledgments This document's structure follows the companion-specification precedent of WebAuthn and CTAP, cited in Section 1. Author's Address Jyotirmoy Bandyopadhayaya LoginRadius Email: jyotirmoy.bandyopadhayaya@loginradius.com Bandyopadhayaya Expires 30 January 2027 [Page 6]