Remove requirement for iss in wallet attestations

[paulbastian]

Attestaiton-Based Client Authentication says regarding the Client Attestation JWT:

iss: REQUIRED. The iss (issuer) claim MUST contains a unique identifier for the entity that issued the JWT. In the absence of an application profile specifying otherwise, compliant applications MUST compare issuer values using the Simple String Comparison method defined in Section 6.2.1 of [RFC3986].

As HAIP decides to mandate x5c for wallet attestation and this is what would be referenced for trust management, the iss value becomes obsolete and HAIP could say that iss can be omitted.

[selfissued]

Would the JWT be signed with the key in the x5c header parameter? If so, I think that needs to be explicitly said, because that's pretty unusual.

[paulbastian]

Would the JWT be signed with the key in the x5c header parameter? If so, I think that needs to be explicitly said, because that's pretty unusual.

RFC7515:

The "x5c" (X.509 certificate chain) Header Parameter contains the X.509 public key certificate or certificate chain [RFC5280] corresponding to the key used to digitally sign the JWS.

[paulbastian]

Would the JWT be signed with the key in the x5c header parameter? If so, I think that needs to be explicitly said, because that's pretty unusual.

RFC7515:

The "x5c" (X.509 certificate chain) Header Parameter contains the X.509 public key certificate or certificate chain [RFC5280] corresponding to the key used to digitally sign the JWS.

[selfissued]

RFC7515:
The "x5c" (X.509 certificate chain) Header Parameter contains the X.509 public key certificate or certificate chain [RFC5280] corresponding to the key used to digitally sign the JWS.

Yes, I'm aware of that (having written it 😉). The thing that's unusual is for the key used to sign a JWT not to be available as a JWK. The issuer is typically used as the root of the algorithm used to retrieve the JWK. Without an issuer, I don't know how libraries wanting a JWK are going to obtain it.

[charsleysa]

The thing that's unusual is for the key used to sign a JWT not to be available as a JWK.

Wouldn't this then be a problem for every other component that utilizes JWT? Key attestation, SD-JWT VC, OAuth request object in VP, etc