Verifier Attestation as W3C VP

[OIDF-automation]

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

Original Reporter: 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?

‌

‌

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: oliver-terbu

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

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: tlodderstedt

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.

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: 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?

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: 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/...

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: tomcjones

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

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: KristinaYasuda

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.

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: alen_horvat

@{712020:901dcb96-126a-470b-868c-ea29820af35a} , 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?)

[peppelinux]

Imported from AB/Connect bitbucket - Original Commenter: tomcjones

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

It would work in this way
https://peppelinux.github.io/draft-demarco-cose-header-federation-trust-chain/draft-demarco-cose-header-federation-trust-chain.html

[peppelinux]

Projects that are using JAdES can simply continue using srAts claim and include all the attestations there

Yes they can and I would suggest this

[Sakurann]

@alenhorvat are you still interested in defining a new client_id_scheme to be able to sue JaDES or have you defined that elsewhere? If you still are interested, could you please propose a specific text that you would like to see in the specification? I assumed you would like to define a new client_id_scheme, but at the same time, it also kind of sounds like you were looking for a clarification that a verifier attestation JWT, and signatures in OpenID Federation could use JaDES in addition to digital signatures (I might have completely misunderstood this part)?