CIBA Binding for OAuth Push-Based Authentication Device Discovery

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. 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

[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.¶

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).¶

• 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 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.¶

Acknowledgments

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

Author's Address