@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.

Denmark's has no lock-in.

@p1gp1g In order for GrapheneOS to participate, this kind of system would need to be created and managed by a neutral organization. It must not be created by for-profit companies selling devices and operating systems. Volla, Murena and iodé in particular cannot make a legitimate system due to their business practices. There are also a bunch of other constraints including a commitment to never delaying updates for certification which would be required for our participation. Even if all of these constraints were met for us to be willing to participate in this kind of system, we would still oppose it while reluctantly obtaining certification through it. Anyone who cares about being able to use forks or their own builds or any OS should be on our side against these systems and Unified Attestation in particular.

I've an idea that should allow forks and own builds too, while giving the attestation the banks & co want. I'm trying to put that down on "paper" and share with them

I'm trying to put that down on "paper" and share with them

Could you host it as an online doc or something please? (Viewing rights only is fine.)

@p1gp1g Android's hardware attestation API supports it but they're not going to be willing to trust arbitrary verified boot key fingerprints. There's no need for a new API, just a way of distributing signed roots and verified boot key fingerprints for the standard hardware attestation API where those can be fetched from multiple organizations approving them instead of a new API specific to a centralized service where apps implementing that will only work with what that permits rather than having the ability to easily add more sources of trusted devices. The organization also clearly shouldn't be created and run by companies making products.

There's no need for a new API, just a way of distributing signed roots and verified boot key fingerprints for the standard hardware attestation API where those can be fetched from multiple organizations approving them

Over time, I’m thinking that it’s unrealistic that such neutral organization might exist and keep being neutral going forward. It’s going to generate endless discussions on which operating systems to trust and it’s also going to have to resist pressure from companies and governments.

Whitelisting GrapheneOS would be great, but only harm reduction. The whole attestation framework opens up a can of worm, such as a future digital identity app cryptographically verifying users are not running non-backdoored E2EE messaging app.

Anyway, unless forced by law, apps are unlikely to extend their trust from Play Integrity to this new way to distribute keys or even Uattest. Since a law is likely required, it would be much better to just forbid banning devices for apps fulfilling essential needs like healthcare, digital identity, and financial services.

Instead, just run a TOFU mechanism where the environment is assumed safe on first run, and warn users about the objective security issue of their configuration.

The law never mention Play Integrity, but the interpretation of the law pushes companies to go to Play Integrity. If we have a solution that cover the same need, we don't need to update the law.

Regarding TOFU: I think we can have a solution based on that, which would cover the same "features" of Play Integrity - there are other solutions

For information, the UA dev is open to implement a way to verify own system builds - so we would be sure that nobody can be locked out of the system

And that also mean that some OS provider can ignore the verification if they want: users will be able to do it themselves

The people behind Unified Attestation are misleading people about how it works and are making up bogus reasons to justify seizing control over which devices and operating systems people are allowed to use. They're absolutely not capable of being neutral and are clearly demonstrating it. Their business interests are clearly what's going to be prioritized above everything else. The system exists to permit using their products and to create a moat around themselves where competing with them is harder and requires signing a deal with the devil through agreeing to their arbitrary demands. They're leading people on claiming their concerns will get addressed but the system itself lacks any reasonable justification and they absolutely shouldn't be the ones creating this kind of system.

Look at how Volla is engaging in underhanded attacks on GrapheneOS because we oppose Unified Attestation:

https://grapheneos.social/@GrapheneOS/116251325625494349

https://archive.ph/LhddH

This has been very clearly shown to be one of their employees and we have a very good idea of which specific Volla employee it is based on very specific content and wording. They've used personal accounts in their real name to make nearly identical posts.

The two other companies listed as being the main ones involved in creating Unified Attestation have waged years of war on the GrapheneOS project with endless inaccurate claims and fabricated stories about our team. It's unacceptable for them to be in a position of power to block app compatibility with GrapheneOS. Far more than GrapheneOS users should oppose these groups seizing control of what they're allowed to use on their devices especially considering how untrustworthy they've shown themselves to be.

Now I know that I'll be able to get a verified GrapheneOS device even if it isn't implemented by GrapheneOS, it becomes a non-subject to me and I prefer to disengage.

Thanks for your work on GOS by the way

I don't really understand the concerns now, and I'm sure I'll convince other people to migrate to GOS once they'll be able to use their banking app, wallet etc

@p1gp1g No legitimate reasons have been provided for Unified Attestation existing rather than using directly using Android hardware attestation. Android hardware attestation enables multiple parties to act as sources of trust rather than locking people into one organization. Why aren't they distributing a list of verified boot keys for use with it? Why do they need to control it with a centralized API? It's incredibly strange you take these companies which are openly engaging in extremely underhanded tactics to harm GrapheneOS at their word about everything. It draws into question the other projects you work on and their future on GrapheneOS.

@p1gp1g

I don't really understand the concerns now, and I'm sure I'll convince other people to migrate to GOS once they'll be able to use their banking app, wallet etc

The status quo is people can use the vast majority of banking and government apps on GrapheneOS. You're advocating for people who are going to further degrade compatibility with it. Currently, 90% of banking and government apps still work on GrapheneOS. You're advocating for a project which is going to heavily degrade that if it succeeded. You're justifying it based on what people caught using sockpuppet accounts to attack us over the long term before we spoke out against Unified Attestation have claimed to you. It's quite clear from their recent posts that they're telling people want they want to hear, but they've still failed to provide any justification for moving this under their control with their own API or why they should be the ones setting it up and controlling it.

Thanks for your work on GOS by the way

I decided to glance through your social media feed and who you follow on Mastodon. You follow and regularly boost the posts of multiple people who have heavily participated in spreading fabricated stories about me which have resulted in relentless daily harassment, raids on our chat rooms and even severe real world violence. Have you come up with some internal justification for why it's okay to be targeting me with a massive amount of bullying, libel and harassment?

For information, the UA dev is open to implement a way to verify own system builds - so we would be sure that nobody can be locked out of the system

And that also mean that some OS provider can ignore the verification if they want: users will be able to do it themselves

You... you see the issue is the system itself right? Why are they making a system where the problem many may face is lock-out? Why is that even a possibility? How is that acceptable? They are making a problem and then trying to sell people on the idea of the solution. The solution is clear, UA has no justifiable reason to exist, and making problems for the sake of it is clearly selfishly motivated.

I don't really understand the concerns now, and I'm sure I'll convince other people to migrate to GOS once they'll be able to use their banking app, wallet etc

The concern is a blatantly illegal system developed to further the interests of for profit companies that make insecure and nonprivate devices, further justifying the existence of play integrity in the eyes of people who are capable of stopping play integrity. Just because its an alternative does not make it good. Its still a crime.

Can you articulate a single justifiable reason as to why this system should exist? Because none have provided one. Any proper attestation system would exclude the companies that are pushing for UA. But its not going to exclude them. Why is that? It is a blatant conflict of interest.

For information, the UA dev is open to implement a way to verify own system builds - so we would be sure that nobody can be locked out of the system

And that also mean that some OS provider can ignore the verification if they want: users will be able to do it themselves

That doesn't mean and prove anything.

The only justification for UA is to manipulate the market and impose arbitrary and misleading standards in order to violate fair competition.

https://competition-policy.ec.europa.eu/antitrust-and-cartels_en

Given the known identities of the companies behind this initiative and their track record, this is a attack on the GrapheneOS project, which is the main target for drastically reducing its compatibility with applications. GrapheneOS has been the subject of numerous smear campaigns by law enforcement, especially in France, and Murena and iodé are based in France.

They want inventing a problem to sell you a solution; the existence of UA is completely useless and serves absolutely no beneficial purpose.

I don't really understand the concerns now, and I'm sure I'll convince other people to migrate to GOS once they'll be able to use their banking app, wallet etc

Current concerns is an illegal cartel, with the primary risk of which will always be unjustified blocking, orchestrated by untrustworthy for-profit companies.