Threat Modeling for Decentralized Identities about digital-credentials HOT 18 OPEN

reasoning about the issue, I began to structure a Threat Model, to which I would then apply privacy (or other) techniques

from digital-credentials.

Nick also mentioned threat model here: w3c/strategy#458

I'm generally supportive of revising the threat model, as the API aligns to support protocols and credential formats.

Especially because some threats will be out of scope for the API, but maybe in scope for a protocol or format.

It can be helpful to identify what the API can change, and where the API's security or privacy considerations are subject to constraints from the choice of supporting a protocol or format.

from digital-credentials.

thanks @OR13 I've just update it (and maybe I need to move from an issue to something different).

Clarified a bit the scope that I agree it is broader to the API, but for the model I think we need to analyze also the full flow/architeture and then part of the model can be applied to the API.

from digital-credentials.

this is more of a threat meta-model as the details about the vulnerabilities, costs, mitigations, and justifications are missing. That is ok as a start, although mixing models makes it harder to come up with a single lists of vulnerabilities for the analysis. Or is the point to create the model and then every implementer would build the analysis?

One item missing is the verifier proof of identity and purpose. As one example, you don't say that the holder must trust the verifier.

There is an implicit assumption here, that the holder is the subject with a slight nod to delegation in "One particularly useful and interesting aspect is that of delegation of a credential (I use the term delegation loosely, as questionies such as Guardianship have a precise legal meaning), which prevents much abuse and identity theft and should be modeled properly as Issuer rules." If you mean this you need much more detail and the separation of the holder from the subject.

from digital-credentials.

By @slistrom and @peppelinux

A classification of the Wallet types, considering that each wallet, at a specific level, can have a different Threat Model.

Wallet Instance Types

There are many ways to technically implement Wallet Instances to manage Digital Credentials. There are typically two types of Wallet End-Users: one is a natural person and another is an Organisational Entity such as a legal person. These two types of users may have different usage and functional requirements.

Below a non-exaustive list of the different Wallet Instance types.

Mobile Wallet Native Application:

Also known as Mobile Wallet only, is an application that runs natively on a Personal Device under the sole control of an End-User and provided through a platform vendor specific app-store, on behalf of the Wallet Solution. In some cases the End-User as natural person uses the Mobile Wallet representing a legal person.
Web Wallet Native Application:

Also known as Cloud Wallet or Web Wallet only, is a Wallet that uses native web technologies for its components, such as UI components. Cloud Wallets are typically suited for Organisational Entities that requires automated Digital Credential operations (request, issuance, store, presentation, revocations) in unsupervised flows, therefore without any human control. Web Wallets are divided into two additional subtypes: Custodial Web Wallets and Non-Custodial Web Wallets.

Custodial Web Wallet
Cloud Wallets that have dependency on a cloud infrastructure, not necessarily hosted by the Wallet Provider, are typically classified as Custodial Web Wallets; in this case, the cryptographic keys used and the Digital Credentials are stored in the cloud infrastructure.

Non-Custodial Web Wallet
A Web Wallet where the cryptographic keys are stored and managed on a media in possession by the End-User and the Digital Credentials can only be used by the End-User, e.g. using a FIDO enabled security hardware token, no matter whether the Credentials are stored locally in a Personal Device or in cloud storage.
Progressive Web Application Wallet (PWAW)

PWAW is a web application that looks like a native app. It can be installed on a Personal Device and not necessarly using the operative system specific app-store. The advantage with a PWAW is that it gives the End-User the same experience as a Mobile Native Wallet Application while also offering the benefits of a web application. PWAW can be Custodial or Non-Custodial.

from digital-credentials.

The strategy link issue is 404.

There are solutions for dynamic state, that rely on getting a fresh status from the issuer at some interval, but where the holder requests the status, not the verifier.

• https://github.com/peppelinux/draft-demarco-oauth-status-attestations

This kind of approach is especially useful for enumerations status values, that are not boolean, since you don't need to do bit logic on the status list, and storing enumerations in cryptographic accumulators can be complicated.

from digital-credentials.

@OR13 Thank you for the 404 check; it was fixed. And also for the status attestations

from digital-credentials.

@weizman have you some insight as you have experience in the Wallets-in-the-Browsers (even if probably more on high-level than your article and also on user experience?

from digital-credentials.

by @peppelinux on linkedin

1. Foundational digital identity systems streamline and secure identification across platforms, enhancing security, reducing fraud, and improving service access, which cuts costs beyond just money.

2. Driven by urgent modernization and security needs, these programs use strict data protection, encryption, and audits, adhering to international standards. Despite their robustness, challenges may arise. Open, inclusive processes are vital for evolving these technologies, allowing wide, representative contributions and enhancing global understanding.

3. Mandatory enrollment ensures universal coverage and effectiveness, facilitating comprehensive integration across services and platforms for equal access to essential services.

Inclusivity and transparency are crucial; time should not be an enemy, nor haste an ally. Empiricism and field experience are essential for making informed decisions.

from digital-credentials.

by Stephan Engberg on linkedin

It depends on how you define Digital Identity.

If it is vulnurable to loss, theft, renting, man-in-the-middle, tracking, lock-in etc. or simply weak, we are very likely talking about identity as an attack on citizens and society rather than security.

If is it empowering, i.e. mainly non-linkable, digital identity can be the critical enabler. The key question is if citizens can share data WITHOUT LOOSING CONTROL.

If not, we are talking various form of means that always feed surveillance, e.g. payment cards or smartphones that by design are invasive.

In this, it should be noted that Verified Credentials is not an enabler in itself even though it can be an element. You need to determine linkability on the entire transaction, not just the single attribute credential.

And politely, World Bank has for a long time appeared to be working on behalf of some shady commercial agenda where human rights are reduced to the right to be commoditized, i.e. the opposite - e.g. biometric identity is the opposite of freedom, it is designing for oppression.

I made this roadmap in 2007 - getting close to being state-of-the-art. But notice how e.g. EU 2.0 ARF is far down to the right.

Image: https://media.licdn.com/dms/image/D4D2CAQElLaerjehW7w/comment-image-shrink_8192_480/0/1716361039335?e=1717052400&v=beta&t=01c6j5dk0i2CcNuNz2F034nc9bLdjOT3IFkZ4V0O9d0

from digital-credentials.

I updated the model by improving the scope, architectural, and flow analysis parts, then wrote the various prompt lists to brainstorm on.

from digital-credentials.

Hi @TomCJones

this is more of a threat meta-model as the details about the vulnerabilities, costs, mitigations, and justifications are missing. That is ok as a start, although mixing models makes it harder to come up with a single lists of vulnerabilities for the analysis. Or is the point to create the model and then every implementer would build the analysis?

Yes, it is still a meta-model to be codified in the clear structure "threat>mitigation>residual threat, as in a common final form.

There are several "profiles" and elements that change the setup a lot (e.g., I can choose to have formats that do not support selective disclosure, while an output that doesn't come out and has to be used/predilected those). Also, because I didn't find that reasoning, it seemed like a good place to start.

The mix between Security and Privacy in this case is given by the fact that I started doing the analysis with the OSSTMM. Still, yes in a later round (the fateful fourth step) the various analyses have to be harmonized.

One item missing is the verifier proof of identity and purpose. As one example, you don't say that the holder must trust the verifier.

Great finding, I will update it thank you

There is an implicit assumption here, that the holder is the subject with a slight nod to delegation in "One particularly useful and interesting aspect is that of delegation of a credential (I use the term delegation loosely, as questionies such as Guardianship have a precise legal meaning), which prevents much abuse and identity theft and should be modeled properly as Issuer rules." If you mean this you need much more detail and the separation of the holder from the subject.

Yes, you are right. I added that sentence as my memento since I thought the concept was interesting. Lately, at least in Europe, we talk a lot about government-issued credentials for people, but there are many use cases where the subject is not the holder (animals, supply chain, etc.).

Thanks again for your comment!

from digital-credentials.

In the section that pertains to the Status List revocation approach, it claims the approach discloses personal information, but that doesn't seem accurate. Assuming the revocation document only contains flipped bits at positions that can only be tied a given credential if you'd been privy to disclosure of their association, what personal information does the author of that passage think is contained in this revocation document?

from digital-credentials.

hi @csuwildcat , thank you for the feedback.

i was more thinking of a correlation issues as specified here:

https://www.w3.org/TR/vc-bitstring-status-list/#privacy-considerations

for sure, I am going to explain better the concept

from digital-credentials.

Additional points to consider:

• #139 by @martinthomson
• eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework#200 by @alysyans

from digital-credentials.

We're also started working with Fondazione Bruno Kessler as they have a Threat Model to on the Wallet/Protocol side: https://drive.google.com/drive/folders/1mgwhZ0jTAeGIE8Ewf3kK34dLjPwOTM5L

from digital-credentials.

One thing I think is missing from the "threat>mitigation>residual threat" form that this is taking is a discussion of the actors/assets/invariants that are useful to describe the assumptions made in constructing the model. That sort of discussion can help us get on common ground, which could be really nice for defining exactly the security/privacy relationship of the wallet and browser. I'm still thinking about how to approach this, but this may be an additional section worth adding.

from digital-credentials.

@bvandersloot-mozilla I agree with you. it is needed a refinement "numbering" the threats, the mitigation so that we can understand the residial part (and understand what to do)

from digital-credentials.