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.
The spec currently defines that an optional
issvalue in key proofMUST be the client_id of the Client making the Credential request. However, in many cases, keys to validate a JWT are obtained in combination ofissandkidclaims, in which case, havingissset 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
issvalue, but that does not match the current spec text requirement. Alternative we are considering is putting DID insuband 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
issmust be client_id? I don't think wallet's client_id carry much value in the context of these protocols.