Flexibility in Verifier Attestation JWT typ parameter

[peppelinux]

In the current Draft 22, we have the following language (here)

Verifier Attestation JWTs compliant with this specification MUST use the media type application/verifier-attestation+jwt as defined in [Appendix D.6.1](https://openid.github.io/OpenID4VP/openid-4-verifiable-presentations-wg-draft.html#va_media_type).A Verifier Attestation JWT MUST set the typ JOSE header to verifier-attestation+jwt.

There might be several reasons to justify a more flexible approach, enabling any kind of typ or the absence of the typ value, due to the coexistence of multiple trust frameworks enabling multiple verifier attestation types.

I suggest the removal or the change of the previous sentence that mandates the typ value to be set to verifier-attestation+jwt .

[jogu]

As discussed offline - verifier_attestation is part of the verifier attestation client identifier scheme, and cannot be used if you're using the federation client identifier scheme. Using a federation trustmark as the attestation in the verifier attestation client identifier scheme does not really achieve anything useful without lots of other changes.

If you want to use a credential as a verifier attestation it probably makes most sense to wrap that credential as a sub-element of the attestation (not fully thought this through).

Removing the requirements around typ would be contrary to the JWT BCP, https://datatracker.ietf.org/doc/rfc8725/

[selfissued]

I'm not in favor of the removal of "typ" but I am in favor of updating the cited spec language from:

Verifier Attestation JWTs compliant with this specification MUST use the media type application/verifier-attestation+jwt as defined in Appendix D.6.1.A Verifier Attestation JWT MUST set the typ JOSE header to verifier-attestation+jwt.

to

Verifier Attestation JWTs compliant with this specification MUST use explicit typing, as defined in Section 3.11 of [@RFC8725].
The media type application/verifier-attestation+jwt as defined in Appendix D.6.1 MUST be used unless a different media type is specified for the particular kind of attestation used, for instance application/trust-mark+jwt. Per Section 4.1.9 of [@!RFC7515], if the media type begins with application/, the application/ should be omitted from the media type name in the typ header parameter value.

I'd be glad to create a PR achieving this goal.

[jogu]

I do not think it is that straightforward.

A trust mark as defined in https://openid.net/specs/openid-federation-1_0.html#section-7.1 does not meet the requirements laid out in for a verifier attestation in https://openid.github.io/OpenID4VP/openid-4-verifiable-presentations-wg-draft.html#section-5.10.4 (for example the 'cnf' claim is not required).

It is also not immediately obvious to me why a trust mark would be a good way to authenticate a client when the client can (more easily?) be authenticated using the federation client id scheme.

I think a solution has been jumped straight to without actually describing a problem that needs to be solved. We should start by agreeing what problem exists and needs to be solved.

[tlodderstedt]

I agree with @jogu. I would also like to understand the problem to be solved and the concrete solution proposal.

The verifier attestation method has a certain behavior and defines expectations regarding the content of the verifier attestation. And following the JWT BCP, it also defines the typ of the JWTs to be used for it. For example, the attestation must have a ' cnf' claim containing the key for performing the actual RP authentication. I'm not sure how the same logic could be applied to trust marks, as they are indirectly be bound to signing key material through the federation.