attestation of the key signing SIOP ID Token

[Sakurann]

do we assume that the key used for the signature of the SIOPv2 id token must be attestable with a wallet instance attestation? from @peppelinux

[tlodderstedt]

I don't think so. it's the wallet (provider) that is being attested, not the key. Like for the issuance of credentials, where the wallet is attested and not the key the credential is bound to.

[peppelinux]

My bad since I didn't understand.

I assume that the SIOP, then the material issuer of the id token, is the Wallet Instance and not the Wallet Provider.
I assume that a SIOP may issue an id token including the wallet instance attestation containing the public key used to verify the signature of the id token, since the wallet instance attestation has the holder binding

the verifier given the id token and the wallet instance attestation, is able to trust that the wallet is secure and compliat to eidas, considering that the Wallet Instance Attestation SHOULD contain the trust chain (or x5c...) to give the proof that the Wallet Provider, that's its issuer, is reliable and attestable as trustworthy

[tlodderstedt]

I assume that a SIOP may issue an id token including the wallet instance attestation containing the public key used to verify the signature of the id token, since the wallet instance attestation has the holder binding

I don't understand the meaning of "since the wallet instance attestation has the holder binding".

Our concept for attestation is pretty simple. If the verifier wants an attestation of the wallet (along with the SIOP response), it requests a wallet attestation VC in the same transaction. So technical speaking, the verifier sends a combined SIOP + OID4VP request. The wallet attestation VC is the kind of VC used to authenticate towards issuers during credential issuance.

[peppelinux]

I don't understand the meaning of "since the wallet instance attestation has the holder binding".

cnf claim in the payload of the Wallet Instance Attestation binds the holder public key in the JWS

it requests a wallet attestation VC in the same transaction.

Not sure since the pseudonym should be also presented in offline flows. The Wallet Instance Attestation should expire and at the same time be usable in a configured time window

if the wallet instance should have to ask a wallet instance attestation for every id token it issues the offline flows would not possible with pseudonymization

I agree with your solution and at the same time I find the limits above, so I'd go for a wallet instance attestation usable in offline flows for pseudonymizations

[tlodderstedt]

cnf claim in the payload of the Wallet Instance Attestation binds the holder public key in the JWS

That seems to me a pretty constrained concept. What is the reason for this tight coupling?

re offline: wallet attestations can be pre-fetched (batch issuance) and used in offline scenarios, too.

[peppelinux]

how to establish that the wallet instance that has issued that id token is the same that own that wallet instance attestation, since this latter is the sole proof that the wallet instance is reliable?

[tlodderstedt]

It is not the wallet instance issuing the id token, it is the holder. The attestation answers the question whether the wallet can be trusted to securely manage the keys on behalf of the holder. There is no need to create any relationship between the keys.

[alenhorvat]

Hi.
This is a very important discussion.
Questions:
a) How does the wallet instance attestation look like?
b) Does wallet instance attestation contain information about the wallet keys?
c) To my understanding Wallet Instance Attestation (WIA) is issued by the wallet provider to the wallet instance. I assume WIA is cryptographically bound to one of the keys managed in the wallet.

Is the following statement correct (in the context of this specification): Since the wallet is in the same flow presenting a wallet attestation (presentation is signed by 1 key) and an ID token (can be signed by another key) the verifier trusts the ID token since it can trust the wallet attestation? In other words, if a box is attested so that I can trust it, I trust everything that comes out of that box?
Assumption: Wallet attestation doesn't contain any info about the key used to sign the ID token.

If true, a MITM is possible (if wallet holder is rouge).

[paulbastian]

Related to #120
Also related #1, probably reusing the key attestations that we introduced in OpenID4VCI