Introducing a general purpose assertion-based client authentication with holder-of-key JWT

[ju-cu]

What about introducing a general purpose client authentication using a holder-of-key JWT assertion instead of Client Attestation JWT?

The draft introduces the Client Attestation JWT that is bound to the public key of a Client Instance Key. What about having a spec that replaces the Client Attestation JWT with an assertion that is a holder-of-key JWT, meaning a JWT bound to a key that the client proofs to be able to control (e.g. using DPoP as suggested in #67 ). The draft would not make any assumptions on whether the holder-of-key JWT is an attestation or not; it technically would support any JWT with a cnf claim and require a proof-of-possession for client authentication. Attestation-based client authentication could profile such a spec if necessary. In the ecosystem, there would be RFC7521, upon it RFC7523 for the bearer JWT assertion and next to it some spec for holder-of-key JWT assertion, and upon that the attestation-based client authentication. What do you think?

This idea was first proposed by @pmhsfelix in #64 (https://github.com/vcstuff/draft-ietf-oauth-attestation-based-client-auth/pull/64#issuecomment-1838969799).

[tplooker]

Hi @ju-cu thanks for surfacing this into a seperate issue. I'm wondering how much of this is a terminology issue as the Client attestation JWT is really just a JWT with minimal normative requirements to ensure it is appropriate as an attestation or in your terminology a holder-of-key JWT. Can you explain what other usecases you would like to use this holder-of-key JWT outside of this specs usage? As it would appear that is the key to understanding whether this additional layer of abstraction would be useful.

[ju-cu]

I agree, it is mainly a terminology issue and I'm not sure there is a need for an additional layer or updating the current one is actually good enough. As you say, the draft includes only minimal normative requirements for the Client Attestation JWT. But this fact made me wonder how the proposed authentication method is actually related to attestation and what it distinguishes it from an authentication method for any holder-of-key JWT. So, I started to think that there could be likewise an authentication method that uses a holder-of-key JWT and any attestation specifics (if there are any) would be on top of that.

[tplooker]

Understood, perhaps the question more lies with what usecases do you see outside of client authentication where this mechanism would be useful? Keeping in mind this draft is inherently bound to applications of the OAuth 2.0 protocol.

[pmhsfelix]

Currently, we have:

• RFC 7521 - Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants as a very general and format independent framework for both client authentication and authorization grants.

  • This framework defines "two general types of assertions": "Bearer Assertions" and "Holder-of-Key Assertions" (https://www.rfc-editor.org/rfc/rfc7521.html#section-3).

• RFC 7523 - JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants profiles RFC 7521 for JWT bearer tokens.

• AFAIK, there isn't any spec profiling RFC 7521 for JWT holder-of-key assertions.

My idea, which I believe is similar to @ju-cu, would be to create such a holder-of-key profile spec, using DPoP-based proof-of-possession. This spec would be useful in both client authentication and authorization grant scenarios that require additional security (i.e. bearer is not adequate). Attestation-based client authentication would be based in this last profile spec, by defining a set of attestation-related claims to be contained in the JWT

This seems more modular and useful.

RFC 7521 - The framework
|
+---> RFC 7523 - profiles the framework for Bearer JWT
|
+---> NewSpec1 - profiles the framework for holder-of-key JWT, based on DPoP, independent of attestation
          |
          +---> NewSpec2 - Tiny spec profiling NewSpec1 for *attestation*-based client authentication, 
                    just by defining extra JWT claims.

The main advantage would be the broader applicability of NewSpec1 as a version of RFC 7523 with holder-of-key

[ju-cu]

I do not have any (additional) use cases for a general purpose client authentication using a holder-of-key JWT, other than the general one that @pmhsfelix described: a JWT-assertion-based authentication for scenarios where bearer is not enough.

This draft does not specify any attestation specific claims for the client attestation JWT (it does not even define attestation and how it differs from an assertion). The only thing, that defines the client attestation JWT is the fact that it is bound to a public key and that the draft expects a client backend to generate it, which imo is not enough for an attestation. For example, the client attestation JWT does not provide any information about how the client protects the key as pointed out in this comment: https://github.com/openid/OpenID4VCI/issues/150#issuecomment-1918865432

In best cases, this draft provides some confidence that the request comes from a genuine client (or what the "client backend" thinks is genuine). I believe that you do not need a client backend to get this confidence. Technically, I don't think, it makes a difference if the client attestation JWT was issued by a client backend or any other third party because it all boils down to how the client authenticates to the client backend (step 2) which is out of scope of the draft anyways. I believe, to make this draft applicable, you will need a profile that defines the attestation-specific claims in the client attestation JWT as well as the client authentication to who-ever-issues-the-key-bound-jwt. Imo, the current draft is more suited as a general-purpose holder-of-key-based client authentication method.

Maybe you can help me to understand the difference between an attestation and a key-bound JWT?