discussed with @tlodderstedt. sub is a self-attested value from the wallet front end to the wallet backend. the issuer does not really need to understand sub, more imp for audit trails and user consent.

@paulbastian what do you do in your current implementation?

I suggest the jwk thumbprint value for the sub value (and consequently for the client_id in the issuance flow)

the sub will be always derived from the cnf.jwk, producing a privacy-preserving value since it would be like a kid

this proposal assumes that the wallet instance could only be tracked with its public key, considering that it should have/use more than a single key, the risk is mitigated

The sub could just be set to a fix value per wallet provider (most likely sub==iss). This is sufficient for authorization and auditing and it is privacy preserving since the wallet instances cannot be identified.

I'm not in favour of sub == iss since Wallet Provider and Wallet Instance are different subjects

the Wallet Provider (iss) issues the Wallet Instance Attestation to a Wallet Instance (sub), so these are definitively different

if we admit that the only way to identify/trace a wallet instance is exploiting the public key (used in Holder binding) ad that the Wallet Instance should have more than a key and obtain fresh documents with a different key, we may assume that the subject identifier if the key, that's not unique, and that from this it could be derived the sub value

In my mental model, the sub is the client id the wallet uses to perform authorization and auditing. I would assume that happens on the level of the wallet provider (or wallet product) but not on instance level.

also should not this be addressed in VCI?

add a text that wallet provider picks a client_id value and it should be used by all wallet instances from privacy perspective