Meeting minutes
Patrick: I work for ETH Zurich, and we're going to discuss, like with Simone and Amir, we started talking at GDC and in SING, on how to extend the threat models
… also becouse sometimes threat models cannot be sufficient, presenting the threat stack approach, and having a discussion on that
… identity systems are systems that we need to protect with potential security, privacy, and societal impact issues, with different attacks
… we have the famous picture about dependicy problem for identity solutions
… when the identity can make the all the systems collapsing
… as it is a complex design space
… with differnet use cases
… e.g., health systems
… we have also different stakeholders
… e.g., issuers, users, verifiers
… and differnt security tools
… threat modeling, formal verification, game-based proofs
… we have also different approaches, e.g., formal security proof, and threat models
… in the crypto layer, we have game-based and crypto implementations
… it is a quetion of trade-offs
… e.g., giving or not more freedom to the user
Caroline: this is why we mapped the identity systems components to identity threats on different levels and also security goals and maturity
… base layer is the math foundations
… e.g., P=NP :)
… we have also crypto primitives
… on building blocks or assumptions (e.g., random numbers)
… and on this layer we have different protections, then we have teh hardware and platform
… there are some incident cases such as the seed extraction on trezor
… going to the uppere layer we havec the communication protocols (specifications)
… e.g., EMV credot card protocol bypassed
… another layer is the role assignment
… e.g., the attacks on BBS
… then we have the layer of implementations
… e.g., data leak on biometric data from police
… an approach is viper
… the top layer is UX, ecosystem and interoperability
… e.g., users unaware of implications, misunderstanding
… and attack is dusting attack
… or the bug in the covid certification app
… the idenitified threats can be evaluteds using impact*likelihood matrix
… thus, risk management strategies
… e.g., risk acceptance, risk transfer
… and risk avoidance
… and mitigation
… one approach is reducing likelihood
… but we need to look also at interactions within different layers
… otherwise that can be wrong assumptions or vulnerabile protocols
… on the ohter side, also different components on the same layer
… interaction result in attack
… such as tehe Card Brand Mixup attack
Patrick: the threat stack can be adapted
… layers can be splitted, consolidated, added or reordered
… as it is required an holistic approach, not only looking risks at each layer
… happy to collect feedback and questions
Manu: thank you for the presentation, is there a plan to apply this is digital credentials in W3C
Patrick: the idea is to use it as a landscape
… and it can be used also for communication
Manu: it does makes sense, i am concerned that we do some level on this, but hoping the researchers are also ineterested in looking inside some WGs
… we need more people
… to embed them in the groups
Patrick: we can talk with some researchers
Caroline: we are reasoning also on the concept related to the DC API in relation also to EUDI ARF
Dan: +1 to manu
… how we potentially lock down problems at spec level but the requirements... and shiting left can be useful
Caroline: yes, and security is sometimes a compromise
<Zakim> npdoty, you wanted to comment on holistic beyond traditional security
Nick: thank you for the presentation, good to have an holistic view
… as I am more on privacy, how you think about threats, such as the one for survelliance when a state can known when i use the credential on the web
Caroline: we captured this threat at UX/Interop level, but maybe we should solve it as a lower level
… iterating on the problem
Patrick: you are also pointing on properties on the design phase?
… at fist we need to make them more explicit
Dan: the specific threat, it is something we talked about in the TAG finding
… on the abuse on credentials and we should work on this related to the standard
… and a spec should NOT permit this
… as we talked this morning in the human rights session
Patrick: we have a discusssion in CH about the wallet that should be secure by design
Manu: +1 to work on this important problem. I don't know if we can address this at standard layer, but maybe on governance layer
… that we should influence as an SDO
<npdoty> I'm not sure where to locate the responsibility. it doesn't seem like a usability problem.
<npdoty> we aren't trying to protect against hackers by using some unclear governance layer happening somewhere else
Manu: I am concerned on how to operationalize this, also to be part of the process
joe: the threat model and the sec consideration section are is the place to write these threats
… this is when we operationalize it
Dan: we can also use prompts in specs
… and use normative requirements
… we should try
akc np
<Zakim> npdoty, you wanted to comment on interaction across layers
npdoty: the point is how we can try to solve it, this is a challenge for the groups
Patrick: it is related to the gov layer
… and we need this holistic approach
<npdoty> some people might be okay with risk acceptance, especially if the risk will primarily be borne by a marginalized group
<npdoty> npdoty: might be thrown off by the layer diagram, debating which individual layer can mitigate the risk. but actually need to coordinate between governance and spec design, rather than expecting either to handle it alone.
<manu_> simone: To add one point -- often the source, layering of threats are located are on the government, we should consider them as a source of threats. With experience, they just defined the requirements and law and push people to write standards to feed the requirements -- user point of view, who is going to protect the user.
Patrick: happy TPAC