@techreport{mcguinness-oauth-insufficient-claims-00,
    number =    {draft-mcguinness-oauth-insufficient-claims-00},
    type =      {Internet-Draft},
    institution =   {Internet Engineering Task Force},
    publisher = {Internet Engineering Task Force},
    note =      {Work in Progress},
    url =       {https://datatracker.ietf.org/doc/draft-mcguinness-oauth-insufficient-claims/00/},
    author =    {Karl McGuinness},
    title =     {{OAuth 2.0 Insufficient Claims Challenge}},
    pagetotal = 35,
    year =      2026,
    month =     may,
    day =       27,
    abstract =  {This specification defines an OAuth 2.0 challenge mechanism by which an Authorization Server or Protected Resource signals that a credential presented by a Client is otherwise acceptable but lacks claims required to fulfill the request. A new error code, insufficient\_claims, together with a required\_claims parameter that enumerates the missing claims, lets the recipient signal what is needed. The same challenge is used in Token Endpoint error responses, in Bearer authentication challenges at Protected Resources, and (optionally) in OAuth 2.0 Protected Resource Metadata. The challenge is intentionally decoupled from how the Client responds. For back-channel re-issuance grants (OAuth 2.0 Token Exchange and Refresh Token), a Client uses the requested\_claims Token Endpoint request parameter defined here. For grants that may require end-user interaction (authorization\_code, device\_code, CIBA), a Client uses an applicable front-channel claims request mechanism, such as the OpenID Connect claims request parameter. A motivating use case is just-in-time account provisioning by a Resource Authorization Server receiving an identity assertion under the Identity Assertion Authorization Grant.},
}