Verifier Attestation as W3C VP

[Alen Horvat]

When Verifiers operate in environments that support Verifiable Credentials, verifiers might receive one or more VCs that attest

• their identity
• rights to ask for VCs or claims
• obligations to request VCs/claims (e.g., you MUST ask for over 18 credential before allowing access)

In this case the Verifier Attestation (as introduced in -20) could be a W3C Verifiable Presentation (signed or unsigned).

Is it possible to add support for W3C VP Verifier Attestations?

‌

‌

[Oliver Terbu]

IMO, it would make sense to allow VC/VPs or a similar data structure as the VP Token for the verifier attestation.

[Torsten Lodderstedt]

Hi Alen, I assume you are referring to the client id schemes? A client id scheme for W3C VPs could certainly be defined. Given the growing number of client id schemes, I think, we need to find a way to describe them and make them accessible outside of the OID4VP spec.

[Alen Horvat]

Yes. More specifically: https://openid.bitbucket.io/connect/openid-4-verifiable-presentations-1_0.html#name-verifier-attestation-jwt

In x509, for example, the Verifier attestations/claims can be expressed with x509; Same can already be achieved when using JAdES since additional claims as VCs/JWT/… can be passed within the signature.

Here the “jwt” claim is somehow trying to mimic x5c or the srAts as defined by ETSI. If srAts is used as per JAdES, then VCs or JWTs can be shared in the same way.

Would it be meaningful to re-use the work of ETSI?

[Alen Horvat]

Would it make sense to sync how the information is expressed across different OID specs?

• Federation is using “trust_chain”
• This specification proposes “jwt” (it can be an array since verifier may have multiple attestations for different purposes)

JAdES introduces signer attributes as srAts; According to the current specifications attributes can be

• srAts.signedAssertions → any format
• srAts.claimed → any format
• srAts.certified → limited to x509

Data model is such that the format and encodings can be expressed directly within the header, which makes it a nice container to transport a wide range of information.

You could put there JWT Verifier Attestations, x509 certs, full trust chain, VCs, …

client_id schema (would “profile” be a better name?) would define the profile/requirements for the content/formats/...

[Tom Jones]

agree w/ Torsten = we need to find a way to describe them and make them accessible outside of the OID4VP spec.

while i suppose that federation would be somewhat better = it is not enuf = i want to see this works across xfer protocols, like 18013

[Kristina Yasuda]

Verifier Attestation JWT section for client_id_scheme verifier_attestation is meant to be a JWT, not W3C VP. so for W3C VP to be used in a similar manner, a separate client_id_scheme value should be defined. and we might also want to make existing client_id_scheme more specific to something likeverifier_attestation_jwt, not sure.

[Alen Horvat]

@Kristina Kristina , thank you for the answer. It is perfectly fine having Verifier Att. as JWT (or any other format). My question is further elaborated (see above).

Fact is that Attestations will come in different formats and with different processing rules. We already see 3

• x509 (included via x5c)
• Verifier Att. JWT (OID4VP)
• Entity Statements (OIDC Federation)
• There are also use cases that use issuer and verifier attestation based on the W3C VCDM

Since JAdES introduced a nice placeholder for such information that can cater for different format, question is whether it would be meaningful for the WG to consider the signer attributes definition as per JAdES.

Projects that are using JAdES can simply continue using srAts claim and include all the attestations there. Note that the approach works for both verifiers and issuers (is there a plan of having similar capability in OID4VCI? e.g,. issuer attestation JWT?)

[Tom Jones]

it seems that this is a duplicate of issue 1255. There never has been any sort of resolution in any stds meeting i have ever attended that addressed the issue of:

Why should the wallet holder trust any request for data sent to the wallet from the verifier?

There is no context for the wallet as there is in the case of OIDC. So how does the holder even have the information about who the verifier really is?

[Mark Haine]

Migrated to GitHub

https://github.com/openid/OpenID4VP