Verifier app attestation for Wallet Instances

[grausof]

It is necessary to define a verification app attestation mechanism (similar to the Wallet Instance Attestation) to be presented to the Wallet Instance at the credentials request stage and also working offline.

[fmarino-ipzs]

According to ISO, this should require Verifier App Authentication and it should be done using x.509 access certificate provided by the Verifier app provider to the instance.

[peppelinux]

X.509 access certificates resolves and simplify many aspects according to the delegation paradigm.

To avoid the implementations of both the Wallet Unit Attestation presentation using ISO 18013-5 and the credential revocation check mechanisms using status lists or whatever, I would put it in the following way:

1. Credential Issuers must issue a specialized X.509 certificate about each issued mdoc cbor, linked to a specialized CRL (dynamic webpath deploy strategy)
2. Credential Issuers rely on the wallet providers trustworthness beofre issuing the credentials, using the long lived WTE.
3. Credential Issuers periodically checks the WTE non revocation using status list. If WTE revocation occurs, the linked credential's x509 certificate will be revoked as well
4. Credential Verifier must verify the mdoc cbor using the X.509 certificate against its CRL

Revoking the X.509 certificate makes the credential unusable, therefore as it would be revoked.
This approach satisfy the both the security and the interoperability requirements, making implementations more simple.

if there will be an agreed other approach suitable for interoperability, these will be evaluated in future milestones.

[grausof]

X.509 access certificates resolves and simplify many aspects according to the delegation paradigm.

To avoid the implementations of both the Wallet Unit Attestation presentation using ISO 18013-5 and the credential revocation check mechanisms using status lists or whatever, I would put it in the following way:

1. Credential Issuers must issue a specialized X.509 certificate about each issued mdoc cbor, linked to a specialized CRL (dynamic webpath deploy strategy)
2. Credential Issuers rely on the wallet providers trustworthness beofre issuing the credentials, using the long lived WTE.
3. Credential Issuers periodically checks the WTE non revocation using status list. If WTE revocation occurs, the linked credential's x509 certificate will be revoked as well
4. Credential Verifier must verify the mdoc cbor using the X.509 certificate against its CRL

Revoking the X.509 certificate makes the credential unusable, therefore as it would be revoked. This approach satisfy the both the security and the interoperability requirements, making implementations more simple.

if there will be an agreed other approach suitable for interoperability, these will be evaluated in future milestones.

I agree with this approach, but by not presenting the Wallet Attestation there is no way for the Verifier to ensure that it is talking to a secure and certified Wallet Instance. The same goes for the Wallet Instance that will have to ensure that it is talking to a certified Verifier App. The purpose of this issue is to allow the Wallet Instance to verify that the verifier app has been released by an entity that is trusted.

[peppelinux]

but by not presenting the Wallet Attestation there is no way for the Verifier to ensure that it is talking to a secure and certified Wallet Instance

the trust is delegated, it's up to the credential issuer periodically monitoring the status of the wallet for which it has issued the credentials. Revocation of those wallets must trigger to the credential issuer the revocation of the certificates and therefore the unverifiability of the linked credentials.

according to this model, the RP relyies on the credential issuer only, making implementations simpler.

[fmarino-ipzs]

X.509 access certificates resolves and simplify many aspects according to the delegation paradigm.

To avoid the implementations of both the Wallet Unit Attestation presentation using ISO 18013-5 and the credential revocation check mechanisms using status lists or whatever, I would put it in the following way:

1. Credential Issuers must issue a specialized X.509 certificate about each issued mdoc cbor, linked to a specialized CRL (dynamic webpath deploy strategy)
2. Credential Issuers rely on the wallet providers trustworthness beofre issuing the credentials, using the long lived WTE.
3. Credential Issuers periodically checks the WTE non revocation using status list. If WTE revocation occurs, the linked credential's x509 certificate will be revoked as well
4. Credential Verifier must verify the mdoc cbor using the X.509 certificate against its CRL

Revoking the X.509 certificate makes the credential unusable, therefore as it would be revoked. This approach satisfy the both the security and the interoperability requirements, making implementations more simple.

if there will be an agreed other approach suitable for interoperability, these will be evaluated in future milestones.

We need to clarify better our proposal:

1. Reader Authentication: This is a mandatory requirement for the RP Instance (Verifier App) registered in the IT-Wallet ecosystem. This is performed using X.509 certificates issued by the RP (provider of the RP Instance).

2. Wallet authentication: according to the ISO, this is performed using the binding device mechanism.

3. Digital Credential revocation: we are planning to add the Status List as a revocation mechanism. For delivery, we should consider this in a future milestone to be planned.

4. Wallet Instance Validity and Trust: we need Wallet Attestation to be presented for the main following reason:

   • The RP Instance (and the human verifier) should be able to know if the Wallet Instance has been revoked.
   • The RP Instance (and the human verifier) should know if the Wallet Instance is provided by a trustworthy Wallet Provider (registered in the IT-Wallet ecosystem)

[peppelinux]

Requirements discussed during the call of the 19 march 2025:

1. definition of the entity type credential_verifier_provider.
2. wallet attestation became an items within the mdoc object, a namespace identifier and therefre the data schema are required
3. verifier apps will use status list to verify the credentials revocation. Actually, it-wallet solution checks the credentials status on its own, preventing a revoked or suspended credential to be presented using the proximity flow.
4. wallet attestation is confirmed as short-lived, it sounds not compliant with the ongoing ISO/eudiw implementation. However, consider it as an additional doc provided within the same presentation, it would be ideally ignored by any ISO verifier app receiving it.

I would also add that:

a) X.509 Certificate Chains require CRL