This article is very relevant in the context of the EU Digital Identity Wallet, and digital credentials in general, such as ISO/IEC 18013-5 mobile driver licenses and other mdocs.
We may accidentially end up with non-repudiation of attribute presentation, thinking that this increases assurance for the parties involved in a transaction. The legal framework is not designed for this and insufficiently protects the credential subject for example.
Instead, the high assurance use cases should complement digital credentials (with plausible deniability of past presentations) with qualified e-signatures and e-seals. For these, the EU for example does provide a legal framework that protects both the relying party and the signer.
Isn't non-repudiation something we want for cases like this? If e.g. a car rental place checks your driving license before renting you a car, and then you get into a crash, no-one wants you to be able to claim that you never showed them your driving license and they never checked.
To prove that the car rental company has seen the driver licence, they just need to show the judge a copy of the licence which is e-sealed by its issuing authority. No need to include a non-repudiable proof-of-possession signature of the holder. Having that in addition would just introduce legal ambiguity and information asymmetry to the disadvantage of the holder.
The opponent may still claim that the car rental place is showing a copy that was obtained illegally, and not in holder presentation. To avoid such a claim, the car rental company should ask for a qualified e-signature before providing the car key. The signed data can include any relevant claims that both parties confirm as part of the transaction. To provide similar assurance to the customer, the company should counter-sign that document, or provide it pre-sealed if it is an automated process.
Note that with the EU Digital Identity, creating qualified e-signatures is just as easy as presenting digital credentials.
Getting the parties on the desk, or the people commissioning enterprise IT systems, to understand this is going to be a serious uphill struggle. Especially in places that are used to photocopying your ID.
the liquor store owner that scans the barcode on your Driver's License "does not understand" and does not care to understand. Yet the opening to your entire life to some low-level cog has been transferred. The correct answer for the wonks out there is : scan ID to answer the question "is this person over the legal drinking age" YES or NO .. which is stored. Similar situations with different contexts, abound.
I mean it's not a super big deal if the EU identity private key leaks in some arcane attack or if someone steals it the normal way, you can just cancel it and order a new one like a credit card. It expires every two years I think anyway.
This reminds me of a specific number that Americans have to give in plain text as proof of digital identity that they only get one of and can't change it ever. Lol.
That doesn’t matter. The claim being made by the grandparent post is that the legal system isn’t well-equipped to deal with scenarios like, “yes the digital signature is valid but it was improperly authorized.”
The legal system also isn't well equipped to deal with the conceptually roughly equal case of someone stealing your car and running people over with it, but it deals with it anyway.
> This reminds me of a specific number that Americans have to give in plain text as proof of digital identity that they only get one of and can't change it ever. Lol.
You can get up to ten replacements of your card in your lifetime. They do all have the same number though.
Non-repudiation of commitments to a transaction can be good when both parties want to avoid later disputes about the authenticity of these commitments. It requires careful design of the data to be signed, the public key certificates, the policies governing the signature creation and validation processes, and the signature formats to enable validation as long as needed.
Attribute presentation is not designed for this feature. When attribute presentation becomes non-repudiable, it creates legal uncertainty:
1. In court, the verifier may now present the proof of possession as evidence. But this is, at least in the EU, not recognised by default as an e-signature. It is yet unknown if it would be interpreted as such by a court. So the verifier keeps a risk that will be difficult for them to assess.
2. Even if it would be recognised as evidence, the holder may argue that it is a replay of a presentation made in another transaction. Presentation protocols are not designed for timestamp assurance towards third parties, and generally do not include verifiable transaction information.
3. The verifier may protect itself by audit-logging attribute presentation input and output along with publicly verifiable timestamps and verifiable transaction information, and by editing its terms and conditions to claim a priori non-repudiation of any presentation. Typically such a solution would not create the same evidence files at the holder’s side. So the holder would not be able to present as strong evidence in court as the verifier. (This asymmetry aspect needs some more elaboration.)
Non-repudiation is well arranged in EU law for e-signatures. If anyone would want the same for attribute presentation, this should involve changes in law. As far as I can see, non-repudiation is now opportunistically being considered in mDL/EUDI just from an isolated technical perspective.
Another issue with non-repudiation of presentation is that it encourages relying parties to log full transcripts of presentation interactions. It could also encourage supervisory bodies to request such over-complete logging. Instead, relying parties should log the minimum necessary, to avoid developing a honeypot of personal data.
I’m not sure what the German eID uses today, but the German architecture team has explored KEM+MAC for the EU Digital Identity Wallet. Maybe its eID is similar. You can apply KEM+MAC at either or both of two points:
1. plausible deniability of the document’s issuer seal
2. plausible deniability of having presented the document
The second is great for legal certainty for the user. The first has problems. It would be incompatible with qualified e-sealing; stakeholders have no evidence if issuer integrity was compromised.
Also, it would mean that issuance happens under user control, during presentation to a relying party. In a fully decentralised wallet architecture, this means including the trusted issuer KEM key pair on the user’s phone. Compromising the issuance process, for example by extracting the trusted issuer KEM key pair, could enable the attacker to impersonate all German natural persons online.
The advantage would have been that authenticity the content of stolen documents could be denied. This potentially makes it less interesting to steal a pile of issued documents and sell it illegally. But how would illegal buyers really value qualified authenticity e-seals on leaked personal data?
I was curious what would be needed to apply Web Authentication for message/document signatures that third parties can verify. This is an article/demo I wrote about what my findings. Note that the standard was deliberately not designed for this and I can’t recommend applying this hack for real.
Cleverbase, Vidua | https://cleverbase.com | The Hague, the Netherlands, hybrid options | iOS / Android native mobile app engineer
We deliver identity wallets and trust services. Users can sign documents on mobile with the same legal value as paper signatures, but higher security. Users can identify online in cases where physical presence or showing a passport would otherwise be needed. And the wallet is a strong multi-factor customer authenticator.
We founded Cleverbase in 2016, aiming to enable everyone to do easy and secure business online. Since 2018 we operate under Dutch government supervision within the eIDAS trust framework. We are part of the development of a European Digital Identity Wallet. We are currently hiring for two of our teams:
- enrollment of European citizens with a high level of assurance, issuing reusable credentials
- wallet cryptography to enable users to fully control their own digital identity, managing and using credentials
Go has an excellent standard library for cryptography primitives with well-established best practices. It was designed and is maintained in a principled way that likely appeals to more cryptography engineers. Also see this answer by one of its maintainers:
It also reminds me (in a positive way) of Étoilé which seems to not be developed anymore, but had a similar Mac OS / NeXTStep inspired approach to design:
This software design classic has been hard to obtain lately. Co-author Rebecca Wirfs-Brock announced yesterday that it has been re-published now as a free download:
We use a combination of Markdown + PlantUML, CSV, YAML, Structurizr DSL, and Gherkin feature files under Git version control next to the code to structure the requirements and examples. A GitHub Actions continuous integration workflow does validations and compiles reader-friendly documentation with Mkdocs. We are experimenting with consolidating more and more of this into feature files.
We structure the project and its related projects hierarchically along service design packages, similar to the “class-responsibility-collaboration” breakdown in object-oriented design.
All of our stream-aligned team collaborates continuously on this data as part of sprints, including analysts, managers, software and QA engineers. We recently started to collaborate with the enabling Risk & Compliance team on the same data, and started doing compliance audits using the generated, Git hash-versioned reports.
Our other teams use similar combinations of data, mostly centered around Confluence spaces which enable some form of traceability due to bi-directional linking.
We are 12 (and hiring). All engineers. Each of our client projects only need 2-3 engineers.
We specialize in software only medical devices. Engineers handle the design controls with input from product owners. We even got a product implemented and a 510(k) cleared using RDM and a team of just 3 engineers.
It adds a little bit of overhead but we think it results in a better product in the end because engineers are thinking more about building the right thing as opposed to just building the thing right. It also results in a safer product since engineers are thinking about risk as they design and implement the product. Automated documentation generation also cuts down on manual process that required non-technical folks in the first place.
Currently we are with between 50 and 100 in total, the team in this example is with 9.
We are building inherently complex systems with high compliance and security impact. So all colleagues are aware that we need to manage a lot of requirements and design knowledge in the progress. So there is a strong motivation to re-use information, reducing work and room for errors. And it helps to have some people passionate about knowledge management and making Git-based workflows easy to use. For example by linking the Mkdocs-generated pages to the GitHub file editor.
We use a very similar approach at Innolitics when working on medical-device projects for our clients. We've been slowly creating an open source tool to help streamline all of this (https://github.com/innolitics/rdm). We've used this tool to write 510(k)s for three of our clients now and have a couple of more submissions in progress. Each time we go through it we improve the tool a bit.
It handles requirements gathering, documentation generation, regulatory audits, and design documents. We also have been playing around with Structurizr DSL and so far like it quite a bit. We also have a backend that integrates with GitHub and plan to add backends for GitLab and Jira soon.
Any experiences with intentionally hostile software architecture?
Curious how for example code project structure or inter-process messaging constraints can prohibit mixing concerns or breaking the domain model. Also curious how such a forceful environment is experienced and whether it has the intended effect.
I came to the comments to talk about this, was totally hoping to scroll down and find a section about software in the wikipedia article.
I would argue that almost every project I have every worked on where the software was initially maintained by a single individual would be classified as "hostile architecture"
We may accidentially end up with non-repudiation of attribute presentation, thinking that this increases assurance for the parties involved in a transaction. The legal framework is not designed for this and insufficiently protects the credential subject for example.
Instead, the high assurance use cases should complement digital credentials (with plausible deniability of past presentations) with qualified e-signatures and e-seals. For these, the EU for example does provide a legal framework that protects both the relying party and the signer.