Security considerations, threat model, account protection, account recovery?

[dickhardt]

The ARF 2.1 states that it provides "high-security authentication" -- but there are no details on what that is, or how it is accomplished. Account protection is hard. Large providers today (Amazon, Apple, Facebook, Google) have teams of 100s of security engineers looking at 100s of signals with sophisticated ML models built on trillions of transactions to do anomaly detection to protect their user's accounts from takeover.

There is no life cycle on what happens when someone loses their phone, when their phone is stolen and someone has access. How do they recover? What happens when they get a new phone? Are all of these factors an exercise for the wallet providers?

It appears that enrollment and identification are left to each state to perform, which is reasonable as they already have processes in place to do that.

[dickhardt]

I had hoped that Chapter 7 would provide some details, but it looks to only cover certification. A regulated authentication process for users will not have the nimbleness required to thwart ever evolving threats.

[digeorgi]

Thank you very much for your input. High-security authentication' refers primarily to a user presenting their PID to a Relying Party. Since a PID is an identity means on LoA High, if a user is able to present their PID, they are assumed to be authenticated with a high level of security. This assumption is justified by several mechanisms, among which the following:

Access to the Wallet Instance requires user authentication. Access to cryptographic keys related to any attestation on the Wallet Instance requires user authentication by the WSCA/WSCD holding those keys. The latter implies at least that an attacker cannot present an attestation to a Relying Party or request attestations from an Attestation Provider unless they know the authentication factor(s) of the User for the WSCA/WSCD. A Wallet Instance is not an online account like Amazon, Apple, Facebook, or Google. The attestations and attribute values stored in the Wallet Instance are not backed up by the Wallet Provider, but are present only locally in the Wallet Instance. The Wallet Provider may not even know which attestations exist in a Wallet Instance. This enhances security significantly; most people will note very quickly when they lost their phone. Section 6.5.3 discusses that the User sets up an account with the Wallet Provider. This account is mainly there to ensure that the User can revoke their Wallet Instance in case of loss or theft of the (device holding the) Wallet Instance. Revocation of the Wallet means no attestation on the Wallet can be presented to a Relying Party anymore. Regarding what happens if the user loses his phone or if they get a new phone, they will first revoke their Wallet Instance to prevent misuse. To get their attestations back on a new phone, the user will have to request the relevant Attestation Providers to re-issue them. We hope this clarifies. Please let us know in case you have further comments.

[ivanek666]

@digeorgi in Section 6.5.3 there is no requirement for the Wallet Provider users' account LoA. I believe it should be on the same level as PID issuance. Is it possible to clarify?

[sander]

@digeorgi in Section 6.5.3 there is no requirement for the Wallet Provider users' account LoA. I believe it should be on the same level as PID issuance. Is it possible to clarify?

@ivanek666, the user is enrolled as a principal into at least three domains:

• WSCA domain, with at least one WSCA to protect identification at LoA High
• Wallet Provider domain, minimally for suspension or revocation of wallet units
• PID Provider domain, relying on the wallet for authentication and binding

In the Wallet Provider domain, for some use cases, single-factor authentication may be sufficient. For example, consider providing the user a static revocation code that they can enter any time to revoke their wallet unit.

Related: Does an EUDI Wallet only support LoA High? #358

[phin10]

Closed after release of ARF 1.10.0