To ensure that the User can trust the Wallet Solution, Wallet Providers preferably make their certified Wallet Solutions available for installation only via the official app store of the relevant operating system (e.g., Android, iOS). […] Finally, it prevents […] side-loading of apps, which can increase the risk of installing malicious apps.
They explicitly want to avoid unofficial distribution of APK (side loading). So I guess it will be difficult to have the official application working on AppSupport. There is no limitation to Android and iOS, so Jolla could make one such application one in their official store. I’m just wondering how useful it can be if the Wallet is running on SFOS but the target applications (who want to have access data from the Wallet) are isolated by the AppSupport layer.
Well, this would directly contravene other directives of the EU, wouldn’t it? On the one hand forcing app store neutrality and on the other making them a requirement? Not that that would stop a working group from ignoring another group, regulation or the like.
Looking at the reference framework, it’s nothing new ( often poorly formulated). The certificate mechanisms (which are becoming legion) are standard and have nothing to do with google or apple but require the application provider to be certified in a way that should prevent fraud… if the certification authority isn’t run like a discount shoe store. The latter is not so certain, these days. Trust anchors spread about:
gives me a warm fuzzy feeling about the exploits coming in the future. With a bit of luck, this whole thing will just fail to get traction.
The only real ‘trust anchor’ in the whole tottering enterprise, the oddly named PuB-EAA ( Public Body Authentic Source Electronic Attestation of Attributes (PuB-EAA) Providers, ie. Governements) will surely being paying out the nose to the other parties involved.
Having read most of this mess now, it can attest (I swear!) that it is not nearly finished and the parts that are finished are certainly not usable to actually create code.
Sorry to state this so bluntly, but this was badly web-linked and IMO also badly quoted. I wonder if the latter was on purpose, because when quoting the last sentence in its entirety, the meaning shifts from preventing users to side-load to the fact that side-loading bears risks.
To ensure that the User can trust the Wallet Solution, Wallet Providers preferably make their certified Wallet Solutions available for installation only 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.
These statements are correct if one is concerned about the integrity of software on an Android or iOS device, as one should when considering to install an “electronic identity (eID) app”.
The concluding sentence of this paragraph, where your omission altered its meaning, states:
Finally, it prevents the User must allow side-loading of apps, which can increase the risk of installing malicious apps.
Well, while not being perfectly phrased, it clearly states that “offering an app in the app store of the OS supplier provides that users are not forced to enable side-loading to install this app”, which is correct.
Thus your conclusion (emphasis by me) …
… is only true when considering “… the relevant operating system[s] (e.g., Android, iOS).”, which means “Android by Google”, because AOSP forks and AAS do not have built-in access to “the official app store” (rsp. there is none), and not reading “avoid” as “prevent” or “forbid”.
Furthermore, this is non-normative guidance for a piece of FOSS: The rights granted by the license (Apache 2.0 for all libraries, EUPL 1.2 for the apps’ GUI) supersede all this endless blather spread out on so many pages (as @poetaster wrote “often poorly formulated” in all aspects, i.e. technical content, language / wording / phrasing, conciseness, comprehensiveness.)
Having read most of this mess now, it can attest (I swear!) that it is not nearly finished and the parts that are finished are certainly not usable to actually create code.
There is a well paid contractor implementing this: Netcompany in Athens, Greece (which seems to be quite sizeable; they also name this as a reference project). They will implement something which is working to an extent that is survives a demonstration and maybe a little testing by some project owner at the EU, in order to get their money. This will then be released; at that point the fun starts.
I agree completely. I was merely stating that the condition of the arf was such that one could not make unambiguous choices when implementing code. I find it a bit disingenuous to tout open source and then provide a specification full of ambiguity and impossible to track conditional dependencies.
I have to admit, I just don’t get it. Ok, everyone wants to BE the bank. So, why don’t they just do it, and issue bank cards like everyone else? Rinky dink startups in Berlin do it! But, no, this is an identity card, errr, wallet, err what is it?
so it’s all a mater of waiting for some app being released so someone (i’d love to be that person but i’m not such a good dev) can start creating a sfos app for it ?
It is great and better than all other "solutions"™, it just does everything and even more: That is how governmental buzzword-bingo works and as always the EU is at the top (meh, I shall not use such primitive terms to depict their superiority: “pinnacle” is much better).
BTW, here is the session with recorded video, which explains everything about “Standards and Technical Architecture Behind eIDAS v2”. Without creating a log-in at Kuppingercole.com one has to endure the video recording in its entirety to see the slides, because the slide-deck is behind a login-wall.
I decided to abstain from both.
arf arf arf, maybe he’ll get that yaml to work finally, eventually jfc, developers developers developers
edit: seriously well spotted, this guy’s language of choice is .md, 15 years of such experience, we’re in good hands kek
He doesn’t have a choice. No Swedes does. Swedish authorities have given the banks a walk over in the case of digital ID and in practice made it impossible to function normally in Sweden without BankID. A de facto monopoly.
The problem is that because they’re living in such situation, they think it’s normal and they request others to implement that functionality, hence this thread and asking for it. That’s just sad
I have a fading hope that the EUDI might become an accepted alternative to BankID. It’s probably hard for the government and the banks to say no to an official EU identity system.
The EUDI is open source, the BankID is not (and never will be).
