Staff Contact for Web Application Security, Web Authentication, Federated Idenity Working Groups, and Security Interest Group proposed
+
Co-Chair of Threat Modeling Community Group
+
+
+
I was in W3C in 2006 for the Semantic Web Deployment Working Group
+
But in general I am Security Geek since 2004 (and before)
I care about a secure Web
@@ -201,106 +209,89 @@
World Wide Web Consortium 万维网联盟
-
-
Security @ W3C
-
-
-
Developing security technology standards
-
-
Web Application Security Working Group
-
Web Authentication Working Group
-
Federated Identity Working Group
-
Web Payments Security Interest Group
-
-
-
Reviewing the security of the standards
-
-
Threat Modeling Community Group
-
Security Interest Group (proposed)
-
-
-
Guiding Web Developers
+
+
+
What is Threat Modeling?
-
Security Web Application Guidelines Commynity Group
+
Threat Modeling is a family of structured, repeatable processes that allows us to make rational decisions to secure applications, software, and systems (Shostack, 2014).
+
During Threat Modeling, we can identify potential threats, such as vulnerabilities or absence of controls, and prioritize the mitigations (OWASP).
+
It is a form of risk assessment that models aspects of the attack and defense sides (NIST SP 800-53 Rev. 5, NIST SP 800-154).
Federated Credentials Management and Status API to avoid third-party cookies
-
Digital Credentials API for mediation of presentation proposed
-
Verifiable Credentials and Decentralized Identifiers (DID) with BBS
-
Verifiable Credentials API, Verifiable Credentials Barcodes, Quantum-Proof signatures community
-
-
+
-
-
-
What is Threat Modeling?
+
+
Why Threat Modeling for Digital Credentials?
-
Threat Modeling is a family of structured, repeatable processes that allows you to make rational decisions to secure applications, software, and systems (Shostack, 2014).
-
During Threat Modeling, potential threats, such as vulnerabilities or the absence of appropriate safeguards, can be identified and enumerated, and countermeasures prioritized (OWASP).
-
In general terms it is a form of risk assessment that models aspects of the attack and defense sides of an entity (NIST SP 800-53 Rev. 5, NIST SP 800-154).
+
At W3C, we use Threat Modeling to analyze standards and write the security and privacy considerations sections.
+
When the standardization of the Digital Credentials API was proposed, since it will mediate high-assurance and government-issued credentials, a more wide-ranging analysis was requested.
+
Therefore, we created the Threat Modeling Community Group to support standards developers in their work, starting from Digital Credentials in general, and not only the API.
-
-
-
-
Do we do threat modeling yet?
-
+
-
The four questions of Threat Modeling
-
Answering the following questions:
+
How we are doing Threat Modeling?
+
We are using the "Four Questions Framework":
-
What are we working on?
-
What can go wrong?
-
What are we going to do about it?
-
Did we do a good job?
+
What are we working on? (understanding architecture, actors, data flows, etc...)
+
What can go wrong? (understanding threats, threat actors, attacks, etc...)
+
What are we going to do about it? (identify and prioritize countermeasures, residual risk, etc...)
+
Did we do a good job? (reiterating until we are happy with the result)
+
In this case, this is a living Threat Model as threats are evolving.
-
Which model is better?
- @@two pictures of LEGO Millenium Falcon vs Disneyworld's falcon@@
-
-
-
-
-
What are we working on? Big Picture
+
What are we working on? Architecture
+
We started from the Verifiable Credentials Data Model (VCDM) to identify main Actors, Data Flows, and Data to protect.
-
- Full Picture
+
+ The roles and information flows of VCDM
-
What are we working on? Credential Layer
-
-
- Credential Layer
-
+
What are we working on? Actors and Data Flows
+
The Actors and the Data Flows:
+
+
We have an Issuer, which issues the Verifiable Credential to the Holder and manages the status (e.g., revocation).
+
We have a Holder, who stores the Verifiable Credential in a Wallet, and send the Verifiable Presentation to a Verifier.
+
We have a Verifier, who verifies the Holder's Verifiable Presentations to give access to a resource or a service.
+
We also have a Verifiable Data Registry (VDR), which stores identifiers and schemas.
+
-
What are we working on? Verifiable Presentation
-
-
- Presentation
-
+
What are we working on? The actors exchanges
+
+
Verifiable Credentials (created by the Issuer):
+
+
Metadata: of the Credentials (e.g., reference to the issuer, the validity date)
+
Claim(s): one or more assertions where a characteristic of a subject is described (e.g., Alice is a citizen of a certain state).
+
Proof(s): cryptographic proof of the integrity of the credential, typically via a digital signature.
+
+
+
Verifiable Presentations (created by the Holder):
+
+
Metadata: of the Presentation
+
Verifiable Credential(s): data stemming from multiple Verifiable Credentials, and can contain additional metadata in forms of additional claims.
+
Proof(s): cryptographic proof of the integrity of the credential, typically via a digital signature.
+
+
+
+
From Threat Modeling perspective, we need to also consider Cryptographic elemenets (e.g., algorithms), Identifiers, Revocation methods, etc...
+
+
+
+
What are we working on? Identifiers
+
+
Talking about identifiers, we mainly refer to the Decentralized Identifiers (DIDs), an identifier technology based on cryptography that empowers us to control our data and consent to its usage.
+
DIDs methods can rely on various technologies, including blockchains, the web, InterPlanetary File System (IPFS), and Domain Name System (DNS).
+
+
From a Threat Modeling perspective, each DID method needs it is own Threat Model
-
-
What can go wrong?
-
A lot of things, we can apply different approaches:
+
+
What can go wrong? Threats/Attacks/Controls Frameworks
STRIDE: Spoofing, Tampering, Repudiation, Denial of service, Escalation of privileges
+
+
+ Brainstorming in a Side Meeting @ IETF120
+
-
+
What are we going to do about it? Cryptography
-
Blinded Signature: is a type of digital signature for which the content of the message is concealed before it is signed. With Public-Private Key Cryptography, the signature can be correlated with who signed it, specifically to their public key (and this is an important feature if we think about when we want to be sure of the sender when using GPG). Zero-knowledge cryptographic methods do not reveal the actual signature. Instead, with ZKP, we can send cryptographic proof of signature without providing the verifier with any other information about who signed. Thus protecting the public key of the holder.
-
Selective disclosure: is the ability to show only a part (claim) of the credential and not all of it or show only possession of that credential. as needed in the context of the transaction. For example, we can show only the date of birth rather than the entire driver's license where it is contained. This allows us to minimize the data sent to the verifier further.
-
Predicate Proofs and Range Proof: is the ability to respond to a boolean assertion (true-false) to a specific request, and it is an additional step for privacy and minimization. For example, if we say we are of age, I don't have to show just the date of birth but compute the answer.
-
Post-Quantum signature?
+
Blinded Signature: is a type of digital signature for which the content of the message is concealed before it is signed. Sending the cryptographic proof of signature without providing the verifier with any other information about the signer.
+
Selective disclosure: is the ability to show only a part (claim) of the credential and not all of it or show only possession of that credential. For example, we can show only the date of birth rather than the entire driver's license where it is contained.
+
Predicate Proofs and Range Proof: is the ability to respond to a boolean assertion (true-false) to a specific request. For example, if we say we are of age, we don't have to show the date of birth but compute the answer.
+
Post-Quantum Algorightms: generating a digital signature using Post-Quantum digital signature algorithms.
-
+
What are we going to do about it? Presentation and Verification
-
Anonymous Revocation: A credential has its life cycle: it is issued, it is used, and then it can be revoked for various reasons. Therefore, a verifier must be able to verify whether the credential has been revoked, but this must be done without allowing the ability to correlate information about other revoked credentials.
+
Anonymous Revocation: a verifier must be able to verify the status of a credential, but this must be done without allowing the ability to correlate information about the specific or other credentials.
Rotational Identifiers: identifiers can be used to correlate, so it is important that they are temporary as much as possible during a session and changed after they are used.
-
Phoning home or back-channel communication: Software often "calls home" for several reasons. They normally do this to collect usage or crash statistics (which could indicate a vulnerability).
-
Notification/Alerts: An important aspect, particularly about interactions where the user is required to interact through an Internet credential, is communication with the user
+
Phoning home or back-channel communication: Software often "calls home" for several reasons. They normally do this to collect usage or crash statistics but also to track the users or the verifier.
+
Notification/Alerts: An holder must be notified if a presentation is going to phoning home and must decide what do to.
+
Privacy-Preserving DIDs: When resolving a DID, it is possible that the method uses a connection to a system for resolution. If this system is under the direct or indirect control of the Issuer
-
-
-
Did we do a good job?
+
+
Did we do a good job?
+
All models are wrong, but some are useful from statistician George Box (1976), quoted by Shostack (2014) in the context of threat modeling
- 
+ 
- 
+