@BoGnY If you are referring to your national wallet, this is something that should be discussed with the development team of your national wallet. The reference implementation is designed to showcase the technology and provide the fundamental features.

Member states are free to use it as they see fit, but we do not have any control over their security implementations. We can only recommend MASVS compliance, but we do not enforce it—this is entirely up to them.

@stzouvaras After a few months, we have their official response of why they use Play Integrity.. Because is a requirements by EUDI Wallet.

Wallet Attestation Requirements delle Regole tecniche italiane:

The Wallet Provider MUST ensure the integrity, authenticity, and genuineness of the Wallet Instance, preventing any attempts at manipulation or falsification by unauthorized third parties. The Wallet Provider MUST also verify the Wallet Instance using the available OS Provider’s API and MUST do so using the securest flow allowed by the OS Provider’s API. Examples include Play Integrity API for Android and App Attest for iOS

Architecture Reference Framework (ARF) v.2.1 – EUDI Wallet Consortium:

[…] ensure that the User can trust the Wallet Solution, Wallet Providers preferably make their certified Wallet Solutions available for installation via the official app store of the relevant operating system (e.g., Android, iOS). This allows the operating system of the device to perform relevant checks regarding the authenticity of the app

So they understood it as mandatory and not as a recommendation.

The wallet is one of the few apps, I think there are about ten in the entire Play Store, that uses the Play Integrity API so heavily. Not even banking apps use such heavy and restrictive systems.

Nonsense

It is worth taking note here of the fact that the one thing they're trying to check -- whether a device is modified or not and thus the person with it in hand may have advanced access -- can't be checked accurately at the app level. A modified device has root access available to some components (whether exposed to the user or not) and this goes above the app's ability to actually see. There are modules that bypass integrity/safety net checks and fool apps.

It's completely pointless for an app to check because it just isn't in the right position even to make the checks.

In 2025 we are still talking about whether or not we have the right to do what we want with the devices we LEGALLY BUY.
The Play Integrity API VIOLATES I don't know how many points of the EU Digital Markets Act, Google itself VIOLATES the EU Digital Markets Act, there are infringement procedures and sanctions against Google for various of these reasons, but despite this, the EUDI Wallet Consortium forces Wallet developers to use precisely those procedures that are contested to Google by the European Commission.

All this is highly stupid and senseless.

Without considering the fact that considering the Play Integrity API a security measure means having no idea of ​​what it actually is, that is, a Google tool to check that the device and the operating system installed are from a Google Partner, that is, a manufacturer that has paid millions and millions to Google to be a certified Google Mobile Services partner, nothing else.

When paper documents will be definitively abolished and will be only electronic (it has been expressly stated by our Government that this is the ultimate goal), when the Police stop me will I tell them to ask for my documents to PagoPA (the Italian company that manages the Wallet) or to the EUDI Wallet Consortium because they voluntarily refuse to give me access to my documents??

@stzouvaras Using the Play Integrity API and therefore locking users into devices licensing Google Mobile Services is unnecessary and goes against the EU Digital Markets Act which makes the Play Integrity API very clearly illegal.

Android has a hardware attestation API supporting verifying other operating systems and which can also be used with another root of trust than the Google one. It does not make sense to unnecessarily lock users into using devices licensing Google Mobile Services. Play Integrity API is not truly for checking device integrity but rather enforcing Google's business model. You should be using the proper hardware attestation API supporting other roots of trust and other operating systems. Instead, you're locking people into using Google devices.

Verifying GrapheneOS devices with the hardware attestation API is documented at https://grapheneos.org/articles/attestation-compatibility-guide. This can also be used to verify other operating systems and also non-Google-certified hardware through adding their attestation roots, if those existed.

@stzouvaras A new issue about implementing the more secure hardware attestation API not forcing enforcing Google's anti-competitive business model has been filed at #390. Please switch to the hardware attestation API avoiding a requirement to have Play services and providing the ability to allow GrapheneOS and other secure operating systems. GrapheneOS is much more secure than Google approved operating systems, not less secure. It provides not only the full standard Android security model and features but also substantial improvements to that. You should be setting an example on how to do things properly and in compliance with EU laws/regulations which will not be the case if the Play Integrity API is enforced. Play Integrity API even enforces installing apps from the Google Play Store and logging into a Google account now, both clearly violations of the DMA.

Hello everyone,

We understand your concerns and truly appreciate your suggestions. As previously mentioned, this is not something that is enforced by the reference implementation — these are simply recommendations, not requirements, for any wallet implementer. That said, we recognize that this is a sensitive topic, and we may need to revisit it, even at the level of recommendations.

I assure you that I will escalate this matter to the appropriate stakeholders for further discussion, to explore whether our recommendations can be revised. While I cannot guarantee any specific outcome at this stage, I will ensure that all your concerns and feedback are clearly communicated and carefully considered.

@stzouvaras I appreciate your help, and I understand what you mean, but the word "MUST" implies that it is mandatory, and not recommended, and is different from "should" or "could" and probably this is the basis of the problem.

They wrote it clearly in an official answer that it is a mandatory security mechanism, because they understood it in that way.

We also appreciate your bringing this issue to the appropriate stakeholders attention, thank you.

@stzouvaras

We understand your concerns and truly appreciate your suggestions. As previously mentioned, this is not something that is enforced by the reference implementation — these are simply recommendations, not requirements, for any wallet implementer. That said, we recognize that this is a sensitive topic, and we may need to revisit it, even at the level of recommendations.

Using the Play Integrity API device or strong integrity means banning anything other than using a device licensing Google Mobile Services where the user is logged into a Google account and the app has been installed from a Play Store. That's a very clear violation of the EU Digital Markets Act and it's in no way required to do these integrity checks for the device, OS and app. There's a hardware attestation API which is what's used by the Play Integrity API strong integrity level in the first place which does not require only permitting Google Mobile Services devices, logging into a Google account and installing the app from the a Play Store. Checking the version code and key fingerprints of the app via the hardware attestation API is better than checking the install location. Checking the attestation root works for verifying the device and checking the OS verified boot state and for alternate operating systems also the verified boot key fingerprint provides verification of the OS. Since alternate roots and OS keys can be permitted, it avoids being inherently anti-competitive as long as there's a way for other roots and operating systems to be permitted. Permitting ONLY Google as a root means locking out competing hardware not licensing Google Mobile Services. Permitting ONLY stock operating systems locks out operating system competition. Play Integrity API does both of those things and more, since it also requires using a Google account and installing the app from a Play Store. Play Integrity API very clearly violates EU law, as do apps/services using it.

I assure you that I will escalate this matter to the appropriate stakeholders for further discussion, to explore whether our recommendations can be revised. While I cannot guarantee any specific outcome at this stage, I will ensure that all your concerns and feedback are clearly communicated and carefully considered.

Using the hardware attestation API instead of the Play Integrity API is very straightforward and enables permitting other roots of trust beyond Google along with permitting non-stock operating systems. It has no security downside and if there are clear requirements for hardware and operating systems to meet with a process for applying to be included, then it could be a legal way of doing it that's not clearly a violation of EU law. It's still restricting what people can use but if there's a process for permitting secure devices and operating systems not approved but Google without too much of a burden, then that could be reasonable. Bear in mind Google themselves are permitting devices with 8+ years of missing security patches for the Play Integrity API device and strong integrity levels. The standard enforced by the Play Integrity API is the rock bottom requirement of licensing Google Mobile Services which has little to do with the device being secure.

It's not reasonable to forbid using GrapheneOS while permitting years of missing security patches. GrapheneOS is much more secure than any Play Integrity certified OS. The most secure Play Integrity certified OS would be the stock Pixel OS and GrapheneOS is specifically built to include all of the same security features as it along with massive improvements. We tend to ship patches faster overall too, since we ship Android Security Bulletin patches for AOSP a bit early, Linux kernel patches far earlier and many other specific patches far earlier such as fixing the serious TapTrap vulnerability shortly after it was made public, which is still not fixed by Android. It's only driver/firmware patches for specific devices where we need to wait for the stock OS release and therefore require at least part of a day to include and ship it.

Dear all,

For any ARF-related topics, please refer directly to the official ARF repository: https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework. If you believe there is something in the ARF that should be revised or discussed, please feel free to open a new thread in the repository and initiate the discussion.

With regard to the EUDI Reference Wallets, OWASP MASVS compliance is strongly recommended. This compliance can be achieved through various methods and should not be restricted to specific APIs from Google or Apple. As previously mentioned in this thread, multiple viable approaches are available, and this is the guidance we provide to all implementers.

should not be restricted to specific APIs from Google or Apple

If it's anything other than MUST NOT be restricted... it's meaningless in practice.

@stzouvaras please update the documentation, italian wallet enforce google play integrity requirement, there is something that should be done

Permitting any secure non-Google device or OS via the hardware attestation is the logical thing to do if banks want to verify the integrity of devices. This isn't only something which needs to be recommended but rather it's legally required by the EU Digital Markets Act and other regulation to permit using apps without a Google Mobile Services OS, without being logged into a Google account via Google Play and without banning installing an app from outside the Play Store. It's a lot easier to follow EU regulation by permitting competition among app stores, operating systems and hardware than dealing with lawsuits. GrapheneOS Foundation is willing to approach it that way, but we greatly prefer mutually beneficial cooperation over legal action. Many banks are beginning to explicitly permit GrapheneOS but it should clearly be the norm. Any other secure OS or device which provides the hardware attestation API should also be permitted. This is something which should be dealt with in 1 place rather than each app doing their own thing and needed their own list of allowed verified boot key fingerprints for non-stock operating systems.

A mandatory Google account is unacceptable in a OSS Project

Hi @andrew-ld,

The README files for both the iOS and Android Wallets have been updated to mention only OWASP MASVS compliance, without referencing any specific APIs.

For any ARF-related changes, please refer to the ARF repository.

Dear @stzouvaras,

Thank you for listening to the complains about this issue. Unfortunately I don't think that removing the reference to the Play Integrity API is enough, as some apps may still limit to this API.

To ensure that all citizens are granted their right to access their digital identity, it is necessary to state that "the app must not require Play Integrity" as it would exclude all the people not using a Google licensed OS.

The Italian digital identity app IO has already implemented mandatory Play Integrity so it is important to explicitly state that this is not allowed and breaks EU law.