Wallet metadata in Wallet Instance Attestation

[rohe]

In https://github.com/WalletInteroperabilityLab/eudi-wif/blob/versione-corrente/docs/en/wallet-instance-attestation.rst there is a set of claims that describes metadata that could be useful when the Wallet interacts with a Verifier.
That set of metadata is of no usage in the context where the Wallet interacts with a Credential Issuer. Here another set of claims could be useful.

To me this means that the present text can not stand. We should either remove these claims completely or accept that a wallet may have WIAs of different kinds. One when it acts as an OIDC RP communicating with a Credential Issuer and another when it acts as an OIDC OP when interacting with a Verifier. If we choose the later path we have to define two sets of metadata schemas.

[peppelinux]

this was my first assumption and in italy we agreed that we should have multiple WA for different scopes

this is something not defined yet in the EUDI Wallet

the direction we're taking, even if still under discussion, is to have a WA with the sole key attestation to be used for both issuance and presentation and the wallet instance metadata would be provided to the RP using the Advanced Flow.

[ve7jtb]

The whole flow of attestations needs to be looked at.

The wallet instance needs to provide attestations to the wallet provider to get an instance attestation.

1. an attestation of something like Safety Net or its equivalent to show package integrity, at least for native implementations.
2. An attestation for the proof key is used to present the attestation. It might be the PAR signing key, depending on the flow.
3. an attestation over the public keys that will be included in the PIDS.

In 2, the provider should know that the proof key the wallet will use to get the PIDS is in hardware or the chain of trust is broken.

There may be a gap in OID4VCI in 3. OID4VCI assumes that any key the wallet can provide and sign a nonce with could be used to bind the issued PID to the wallet. I think the wallet provider needs to indicate that the public key to be bound is OK (secured in HW). There is a built-in assumption that if the wallet is verified, it will manage all its keys properly. That that a more difficult assumption to make about a web wallet.