@techreport{mcguinness-oauth-client-instance-assertion-01,
    number =    {draft-mcguinness-oauth-client-instance-assertion-01},
    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-client-instance-assertion/01/},
    author =    {Karl McGuinness},
    title =     {{OAuth 2.0 Client Instance Assertion}},
    pagetotal = 78,
    year =      2026,
    month =     jun,
    day =       24,
    abstract =  {This specification defines the Client Instance Assertion: a signed JWT identifying a concrete runtime instance of an OAuth 2.0 client. It registers the client\_instance\_assertion request parameter for carrying the assertion at the OAuth 2.0 token endpoint on the authorization\_code, client\_credentials, refresh\_token, and JWT bearer (RFC 7523) grants; on the token-exchange grant (RFC 8693), the same assertion is presented as actor\_token with actor\_token\_type set to urn:ietf:params:oauth:token-type:client-instance-jwt, also registered by this specification. This specification does not introduce a new client\_instance identifier in protocol messages. Instead, it defines client metadata parameters (applicable to clients identified by a Client ID Metadata Document (CIMD) or registered via OAuth Dynamic Client Registration (RFC 7591)) that let a client\_id identify a logical client whose concrete runtime instances are authenticated by one or more trusted instance issuers (for example, workload identity systems). The Authorization Server validates the instance assertion and represents the instance either as an act claim, when another principal is present (e.g., a user delegating to the instance), or as the access token's sub, when the instance itself is the principal (e.g., a client credentials grant). The issued access token is sender-constrained to a key the instance possesses.},
}