OpenID4VCI
                                
                                 OpenID4VCI copied to clipboard
                                
                                    OpenID4VCI copied to clipboard
                            
                            
                            
                        adding an optional `sub` claim in Key proof
The spec currently defines that an optional iss value in key proof MUST be the client_id of the Client making the Credential request. However, in many cases, keys to validate a JWT are obtained in combination of iss and kid claims, in which case, having iss set to client_id can be pretty limiting.
To be specific about the problem we face. In our implementation, the key used to sign a key proof is represented as a DID. kid will contain a reference to a key contained in a DID Doc. So the payload needs to contain an actual DID that is used to obtain that DID Doc. The most natural option would be to include DID in the iss value, but that does not match the current spec text requirement. Alternative we are considering is putting DID in sub and it kind of logically makes sense since the Wallet is issuing a proof for a user that is a subject, but from a signature validation perspective, it is very counterintuitive and probably error-prone to obtain a key from a sub claim...
Can we consider removing the requirement that iss must be client_id? I don't think wallet's client_id carry much value in the context of these protocols.
Identifying the party signing a JWT based on its identity in the protocol (here: client_id) is a good practice in my opinion. It allows to further qualify the context (besides sub and nonce).
Your observation in my opinion hints at adding the kid to the proof JWT not removing the iss value. I think this problem could be solved by putting the DID in the kid, right?
The question is whether there needs to be a binding between client_id and kid. I'm not sure about this.
@Sakurann in the same way that the OID4VP spec allows a DID to be the client_id (when client_id_scheme = did) for a Verifier. it does seem consistent to me to also use the DID of a Wallet to be the client_id in the relationship between a Wallet and an Issuer. As such the iss = client_id makes sense.
Your observation in my opinion hints at adding the kid to the proof JWT not removing the iss value. I think this problem could be solved by putting the DID in the kid, right?
we are adding kid, but don't believe that's enough because kid needs a reference point in the payload.
The question is whether there needs to be a binding between client_id and kid. I'm not sure about this, expecially when
kidis a relative DID URL, like#key-1. ... it does seem consistent to me to also use the DID of a Wallet to be the client_id in the relationship between a Wallet and an Issuer.
Logically, iss is an identifier of the issuer of a proof == wallet/client (and sure, it could be DID, I guess), but here, we are talking about DID of the User, possession of which is proven in this proof. so we decided to use sub to put a full DID of the user. so might be a good idea to add a note in the spec about a sub claim in the proof.
to summarize, I think the proposal is to define an optional sub parameter in a proof that can be used to put user's identifier.
as described in #17, could be used to communicate jwk thumbprint uri, too.