[OpenID4VP] Relying Party verifiable_attestation without requiring a specific typ

[OIDF-automation]

Imported from AB/Connect bitbucket: https://bitbucket.org/openid/connect/issues/1992

Original Reporter: peppelinux

Following the definition of the verifiable_attestation achieved in the PR 524, we read the normative text below

In the context of this specification, such a JWT MUST set the `typ` JOSE header to `verifier-attestation+jwt`.

OpenID4VP doesn’t explain how the the verifiable_attestation should or may be provisioned.
There are some cases where the verifiable_attestation is issued as an OIDC Federation 1.0 Trust Mark.

In these cases the typ value is set to trust-mark+jwt, for this reason I think that the previous text should be changed to not exclude this scenario, and then it may be improved in the following way:

”””
In the context of this specification it is not defined how the verifiable_attestation can be provisioned.
In case this is issued in the form of a trust mark according to OpenID Connect Federation, the JWT JOSE header typ MUST be set to trust-mark+jwt, for all other cases where the JWT does not have a specific typ identifier, the verifiable_attestation JWT JOSE header typ MUST be configured with the value verifier-attestation+jwt.
”””

‌

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: alen_horvat

If the Verifier Attestation is issued as a W3C VC, should additional type be registered?

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: peppelinux

I’d make it more simple, the verifier_attestation parameter gives us the semantic and the nature of the value carried within it, then we assume that’s not important the media type for the scope of this parameter, since a verifier attestation can be issued in multiple formats and encodings and then it must be the trust model which defines the known types that must be taken in account during the trust evaluation

I assume that even if a verifier attestation is issued with the media type X or Y or Z, then the trust evaluator has to establish the trust with the issuer of the verifier attestation. Well, this can be accomplished in many ways, since different types of verifier attestation gives different discovery processes, as it is oidc federation for the trust marks when these are used for attesting something, for example

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: alen_horvat

Yes, I agree. Every attestation type issued within a given framework will define the validation rules. Questions are:

a) Can federation support 3rd party attestations

b) How to express the information? e.g., federation supports trust frameworks A, B, and C (note that the information can be conveyed within the attestation itself)

[peppelinux]

It seems to me that according to the current text this issue seems to be ready to be closed, since it's out of the scope of openid4vp specs define how the verifier attestation could be obtained, according to which trust framework

at the same time, the current text offers many options about possible and well known trust frameworks to be used and configured through the client_scheme_id

I don't see any reason to keep this issue open