For each attestation instance the Holder EUDIW generates a public/private key pair. The public keys are sent to the Providers during the issuing process. For each requested attestation a separate key shall be used. The keys are signed together with the payload data by the provider.
The private keys are used by the holder EUDIW during the presentation to the RP to proof that the holder EDIW is the wallet to which the presented attestations was issued. The attestation instance specific private key is used by the holder wallet to sign the generated random number during the challenge response check.
This mechanism is required to implement the requirement formulated in the ARF V1.3:
ARF1.3 6.3.2.4 Relying Party trusts device binding
“…Note that a EUDI Wallet Instance can contain multiple attestations, originating from multiple Providers. For each attestation, the EUDI Wallet Instance has access to an attestation private key, which is stored in the WSCD in (or connected to) the User's device. As discussed in section 6.2.2, the EUDI Wallet Instance also contains a EUDI Wallet Instance private key. Depending on the attestation requested by the 6.3.2.4, the EUDI Wallet Instance SHALL use the correct private key for signing the random number generated by the Relying Party.”
The mechanism is described in slides nr. 20 and 21 of the following presentation: T
Although relevant, content regarding keys and key binding will be added in later revisions of the RFC. There is ongoing work around theese subjects and we expect standards to be developed during fall.
For each attestation instance the Holder EUDIW generates a public/private key pair. The public keys are sent to the Providers during the issuing process. For each requested attestation a separate key shall be used. The keys are signed together with the payload data by the provider. The private keys are used by the holder EUDIW during the presentation to the RP to proof that the holder EDIW is the wallet to which the presented attestations was issued. The attestation instance specific private key is used by the holder wallet to sign the generated random number during the challenge response check. This mechanism is required to implement the requirement formulated in the ARF V1.3: ARF1.3 6.3.2.4 Relying Party trusts device binding “…Note that a EUDI Wallet Instance can contain multiple attestations, originating from multiple Providers. For each attestation, the EUDI Wallet Instance has access to an attestation private key, which is stored in the WSCD in (or connected to) the User's device. As discussed in section 6.2.2, the EUDI Wallet Instance also contains a EUDI Wallet Instance private key. Depending on the attestation requested by the 6.3.2.4, the EUDI Wallet Instance SHALL use the correct private key for signing the random number generated by the Relying Party.” The mechanism is described in slides nr. 20 and 21 of the following presentation: T