i’m sure there’s a clause here mentioning android/ios somehow???
I just checked if the German state has any support for people like me to use this document for identity purposes vis. the state. Nope. The requirements are quite clear.
I’m just dealing with eudi-doc-architecture-and-reference-framework/docs/arf.md at main · eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework · GitHub
2 Likes
There seems to be more functions in the wallet than just identification. Look at the video at:
1 Like
This topic is temporarily closed for at least 4 hours due to a large number of community flags.
This topic was automatically opened after 12 hours.
From the link above provided by @poetaster
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.
I wouldn’t have asked for a native app if I had thought that the android app would work.
The swedish BankID already forces me to have two extra phones for this reason.
(American operating systems only).
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:
Wallet Providers,
PID Providers,
QEAA Providers,
PuB-EAA Providers,
Access Certificate Authorities for
Relying Parties,
PID Providers,
QEAA Providers,
PuB-EAA Providers.
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.
3 Likes
This topic is temporarily closed for at least 4 hours due to a large number of community flags.
This topic was automatically opened after 12 hours.
This topic is temporarily closed for at least 4 hours due to a large number of community flags.
This topic was automatically opened after 24 hours.
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.
Hence please re-read the first paragraph of section “6.5.2.2 User verifies Wallet Solution” of the document eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/docs/arf.md at GitHub. It states in the section you quoted (emphasis by me):
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.)
The only point where I do not concur with poetaster’s assessments is his conclusion:
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?
3 Likes
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).
Just look at the perfect bio of the EU policy officer who manages all this with excellence!
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.
2 Likes
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
1 Like
nope it’s not, it’s just the amount of time you’ll see it’s not.
Then change your bank if you can and do not allow to force your bank to dictate you what you have to do as long as you have the option to choose.