Client Key Attestation JWT Example

[fmarino-ipzs]

In the example in section 3.1.1. the issuer and the sub parameters should not be the same since the Wallet provider and the wallet instance are distinct entities. The private key in sole control of the wallet instance is referenced in the attestation while the subject refers to the Wallet Provider.

Moreover, is the given example meant to be normative? I'm asking since in the example we find the JWS header parameter kid without any explanatory text about the key resolution mechanism allowed in the specs. (x5c, trust_chain, jwk)

[tlodderstedt]

re 1: the wallet instance is an instance of the software published by the wallet provider. Setting the sub to the issuer value is a plausible option as the wallet provider issued an attestation to one of its instances. It most notably prevents tracking of wallet instances (aka super cookies).
re 2: this draft (as all OAuth WG drafts) is a base module to be used in the context of a certain profile. Such a profile would define how the keys are resolved. There will be definitely be a definition on the level of the OID4VC High Assurance Interoperability Profile.

[peppelinux]

regarding the value of the sub claim in the WAI: since the wallet instance attestation is binded to a public key, we are not forced to use a unique and immutable subject identifier but instead a unique identifier with the same lifetime of the related key. That's why I suggest to place the jwk thumbprint value as sub or any other collision resistant value

anyway I think that's an implementation choice if not of interest in this specs, I'd ask to remove any constraint to have iss equal to sub, since doesn't make any sense following the awareness that the wallet provider and the wallet instance are distinct entities, even if part of the same wallet solution, then they should not use the same entity identifier

[tlodderstedt]

I don't see any constraints in the spec regarding the sub value. Please point our if I missed one.

[peppelinux]

I had a check, now I can confirm.
Happy to have put a stone with you on that

[tplooker]

Following the generalisation proposed in #32 if merged then we will need to constrain the sub value to being the client_id to ensure client identification and authentication can take place. Multiple client instances sharing a single client_id is not a new pattern and is common place for public clients.

[paulbastian]

As of now, I think there is consensus to have sub as client_id.
Pending close if no objections

[peppelinux]

I agreed that sub must have the same value of client_id but I didn't agreed that the specs should say which must be their value.
I agree @TakahikoKawasaki 's comment here and I think that different implementations and models may distinguish the wallet instance from the wallet provider as different entities

[tplooker]

I agreed that sub must have the same value of client_id but I didn't agreed that the specs should say which must be their value.
I agree @TakahikoKawasaki 's comment #32 (comment) and I think that different implementations and models may distinguish the wallet instance from the wallet provider as different entities

@peppelinux apologies we are struggling to understand what you mean here, can you possibly clarify?

[peppelinux]

Ciao @tplooker

iss is the entity that attests an instance, while sub is the instance.
in my current implementation the first is the wallet provider, the latter is the End-User personal device.

We have found a good compromise with @paulbastian to not force in the specs a specific value, in a way to not force that iss value must be equal to sub. Wee agreed and everything seems fine to date.

[tplooker]

Thanks @peppelinux, if you dont mind, could you copy in an example of your client attestation JWT just so we can be 100% aligned, what I'm trying to understand is whether the sub value you are using is unique per user? Because our proposal above is simply for the sub value to be the client ID which for public clients would mean the same sub value across multiple instances of the same client.

[TakahikoKawasaki]

@tplooker
The example of "wallet instance attestation" (which corresponds to the "client attestation JWT") in the page 9 of "Discover the Italian Wallet" indicates that the value of the sub is not a client application identifier but an identifer unique per user (per client instance key).

To be exact, the Italian technical document, "Wallet Instance Attestation", defines the sub as follows.

Thumbprint value of the JWK of the Wallet Instance for which the attestation is being issued.

As an implementer of an authorization server that plans to support the "OAuth 2.0 Attestation-Based Client Authentication" specification, I'm looking for a way to support both the cases at the same time where (1) sub is a client application identifier or (2) sub is a unique identifier per client instance key.

[tplooker]

Thanks @TakahikoKawasaki can you elaborate on the usecase/rationale for why the client attestation needs to include a client instance (or user unique) identifier in the attestation? For example the reason the attestation must include a client_id somewhere is because the authorisation server needs to know which client is making the request, but generally as is the case with public clients, the authorisation server doesn't care which specific instance is making the request.

[tplooker]

Related to #57

[TakahikoKawasaki]

@tplooker
To be honest, I don't care about the rationale behind the value of the sub claim in the "Client Attestation JWT". Because authorization server implementations can know the client application identifier from the iss claim in "Client Attestation PoP JWT", the value of the sub claim in the "Client Attestation JWT" is not necessary to identify the client application.

If the specification says "the sub claim in the Client Attestation JWT must be identical to the client application identifier", authorization server implementations must reject requests from Italian wallets. On the contrary, if the specification says "the sub claim in the Client Attestation JWT must be the JWK thumbprint of the client instance key", authorization server implementations must reject requests from other wallets (e.g. IDunion wallets?) that set the client application identifier to the sub claim.

General-purpose authorization server implementations want to accept both requests at runtime, or at least want to be (statically) configurable to accept either of the two patterns. A simple resolution would be to define the value of the sub claim of the Client Attestation JWT as follows.

• The client identifier or the JWK thumbprint of the client instance key

[tplooker]

To be honest, I don't care about the rationale behind the value of the sub claim in the "Client Attestation JWT". Because authorization server implementations can know the client application identifier from the iss claim in "Client Attestation PoP JWT", the value of the sub claim in the "Client Attestation JWT" is not necessary to identify the client application.

I understand the AS can use the PoP to identify who the client is, but without a client_id in the client attestation its not really a client attestation instead its just a key attestation. Perhaps @peppelinux can you elaborate on why the sub value needs to be a JWK thumbprint in your implementation what does this enable?

[peppelinux]

@tplooker

The cnf.jwk represents the identifier of the wallet instance. A wallet instance may have more than a private key and more than a single wallet instance attestation. Even using iss == sub the wallet instance attestation can be implicitly identified with the cnf.jwk.

The value of the sub claim is something to uniquely identify the subject, we should not mandate a specific value type but the only requirement to have unique value per wallet instances, while iss == sub == client_id doesn't make sense to me.

I agree with Taka and at the same time I foudn a compromise with @paulbastian and at the end if iss == sub this will be ignored by the implementations because it doesn't bring any value, sense or benefit. It would be then better to remove client_id and sub. Anyway if this compromise to ignore the sub value helps the interop, I can buy but in Italy we're prone to distinguish the issuer from the subject because they are distinct entities, the first is the wallet instance attestation issuer, the latter is the wallet instance.

[tplooker]

Thanks for the explanation @peppelinux.

The value of the sub claim is something to uniquely identify the subject, we should not mandate a specific value type but the only requirement to have unique value per wallet instances, while iss == sub == client_id doesn't make sense to me.

I think perhaps here is where there is a disconnect. At present in the specification, the attestation is called a "client attestation" not "user attestation" which is because the issuer of the attestation is a client and the subject is an instance that particular client.

If we make the change proposed in #32 then the issuer of the client attestation is no longer necessarily the client (or client backend) instead it could be any party that the authorization server trusts to make attestations about clients. However in that model the subject of the attestation is still always a client instance not a user.

So with the adoption of #32 the iss will no longer be the client ID meaning instead the client_id must feature somewhere else in the client attestation, otherwise the authorization server has no way to validate for which client an attestation it is presented has been produced for. The most practical change I see here would be for us to require the sub value to be the client_id of the client being attested.

In short with the change proposed above the iss value could be any string but the sub would then still have to be the client_id, would that work for your implementation? For a concrete example see here #32 (comment) as proposed by @TakahikoKawasaki

[TakahikoKawasaki]

The following table summarizes the current spec, the Italian ecosystem, and possible compromises.

No.	Client Attestation JWT iss	Client Attestation JWT sub	Client Attestation JWT, new claim	Client Attestation PoP JWT iss	Memo
1	Attester	Client ID	N/A	Client ID	The current spec.
2	Client ID	Client ID	N/A	Client ID	The example in the current spec (excerpted in #32). My understanding is that the example is misleading because the current spec conceptually treats the attester and the client as different things.
3	Attester	Thumbprint of Client Instance Key	N/A	Client ID	The Italian ecosystem
4	Attester	Any	N/A	Client ID	Compromise A
5	Attester	Client ID or Thumbprint of Client Instance Key	N/A	Client ID	Compromise B
6	Attester	Client ID	Thumbprint of Client Instance Key	Client ID	Compromise C
7	Attester	Thumbprint of Client Instance Key	Client ID	Client ID	Compromise D
8	Attester	Any	Client ID	Client ID	Compromise E
9	Attester	Any	Thumbprint of Client Instance Key	Client ID	Compromise F
10	Attester	Client ID or Thumbprint of Client Instance Key	Client ID	Client ID	Compromise G
11	Attester	Client ID or Thumbprint of Client Instance Key	Thumbprint of Client Instance Key	Client ID	Compromise H

[tplooker]

Thanks @TakahikoKawasaki for your write up. @peppelinux if the main intent of your use-case is to support identifying the client instance, then I believe as you highlight above that can be accomplished via the cnf claim. Therefore we can leave the sub claim as the client_id value. Will that work for your deployment?

[peppelinux]

@tplooker

If we make the change proposed in #32 then the issuer of the client attestation is no longer necessarily the client (or client backend) instead it could be any party that the authorization server trusts to make attestations about clients. However in that model the subject of the attestation is still always a client instance not a user.

I didn't mention any user, a subject could be any kind of entity, like a robot, a machine, a client, etc.

Therefore we can leave the sub claim as the client_id value. Will that work for your deployment?

In my deployment the sub value, then the client_id, is the thumbprint value of the cnf.jwk and this is therefore different from the iss value.

Thanks to @TakahikoKawasaki for his memorable contributions.