diff --git a/index.html b/index.html index 8b983fcd..094511b8 100644 --- a/index.html +++ b/index.html @@ -3700,318 +3700,41 @@

Verification Errors vs. Warnings

-
-

Privacy Considerations

-

-

- -
-

Delegation

- -

-[=Verifiable credentials=] [[VC-DATA-MODEL-2.0]] are a standard data model -designed to mitigate risks of misuse and fraud. As a data model, verifiable -credentials are protocol-neutral and consider at least two types of -entities: [=issuer=] and [=subject=]. When the subject of a verifiable -credential is a natural person or linked to a natural person, privacy and -human rights can be impacted by the vastly more efficient processing of -standardized [=verifiable credentials=] as compared to their analog -ancestors. -

- -

-Technology, in the form of standardized APIs and protocols for issuing -[=verifiable credentials=], further enhances the efficiency of processing -[=verifiable credentials=] and adds to the risks of unforeseen privacy and -human rights consequences. -

- -

-[=Verifiable credentials=] issuance has a request phase and a delivery phase. -The request might be made by the [=subject=] or another role, and delivery -can be to a client that might or might not be controlled by the subject. -Delegation is highly relevant for both phases. The [=issuer=] might delegate -processing of the request to a separate entity. The subject, for their part, -might also delegate the ability to request a [=verifiable credential=] to a -separate entity. Note that the subject might not always have the capability or -ability to perform delegation. Examples include a new born baby, a pet, and a -person with dementia. So the request might be performed by a third party who was -not delegated by the subject. The ability to delegate is a third dimension in -the enhanced efficiency of processing [=verifiable credentials=] and has -impact on privacy and human rights. -

- -

-The architecture described in this specification is designed for market -acceptance through a combination of efficiency and respect for privacy and human -rights. APIs and protocols for processing [=verifiable credentials=] do not -favor delegation by the issuer role over delegation by the subject role. -

-
- -
-

"Phoning Home" Considered Harmful

- -

-It is considered a bad privacy practice for a [=verifier=] to contact an -[=issuer=] about a specific [=verifiable credential=]. This -practice is known as "phoning home" and can result in a mismatch -in privacy expectations between [=holders=], [=issuers=], -[=verifiers=], and other parties expressed in a [=verifiable credential=]. -Phoning home enables [=issuers=] to correlate unsuspecting parties with -the use of certain [=verifiable credentials=] which can violate -privacy expectations that each entity might have regarding the use -of those credentials. For example, what is expected by the [=holder=] to be -a private interaction between them and the [=verifier=] becomes one where -the [=issuer=] is notified of the interaction. -

- -

-There are some interactions where contacting the [=issuer=] in a -privacy-preserving manner upholds the privacy expectations of the [=holder=]. -For example, contacting the [=issuer=] to get revocation status information -in a privacy-respecting manner, such as through a status list that provides -group privacy can be acceptable as long as the [=issuer=] is not able to -single out which [=verifiable credential=] is being queried based on the -retrieval of the status list. For more information on one such mechanism -see the [[[VC-BITSTRING-STATUS-LIST]]] specification. -

- -

-[=Verifiers=] are urged to not "phone home" in ways that will create -privacy violations. When retrieving content that is linked from a -[=verifiable credential=], using mechanisms such as [[[?RFC9458]]] and -aggressively caching results can improve the privacy characteristics of the -ecosystem. -

- -
-
- -
-

Security Considerations

-

-

- -
-

Unknown Proof Types

- -

-[=Holder coordinator=] implementations, such as digital wallet software, can -receive and store [=verifiable credentials=] that include [=data integrity -proof|proofs=] that are not understood by the software, however, these [=data -integrity proof|proofs=] are not to be presented by the implementation. A -[=verifiable credential=] with several [=data integrity proof|proofs=], some of -which the implementation understands and others that it does not, can be -presented by the implementation provided that the proof of choice is understood -by the implementation and the others are removed prior to presentation. -Implementations maintain allow lists of understood [=data integrity -proof|proofs=] and ensure that any [=data integrity proof|proofs=] not present -are stripped prior to presentation. -

- -

-Implementations can use the presence of unknown [=data integrity proof|proofs=] -as potential adoption signals in a decentralized ecosystem. It is also important -for implementers to understand that in the -three party model, the [=holder -coordinator=] acts as a conduit between the [=issuer=] and the [=verifier=], -enabling interoperability between the two even if/when the [=holder -coordinator=] doesn't necessarily implement [=verification=] of certain [=data -integrity proof|proofs=]. As an example in another space: "Web browsers were -able to download and store PDF files prior to adding their own PDF-reader -functionality" — this kind of decentralized innovation, interoperability, and -progressive enhancement is important in the three party model and more -generally in scalable, decentralized ecosystems. It is also important to help -reduce centralization by not forcing people to adopt specific new and different -software just to store a [=verifiable credential=] that has at least one proof -on it that their current software does not (yet) understand. -

- +
+

Threat Model

-A [=holder coordinator=] might be able to present some [=data integrity -proof|proofs=] even when it does not have the software to verify them, -but this needs to be understood with certainty, not guessed. That is, -when adding a copy of a stored [=verifiable credential=] to a presentation, -[=holder=] software needs to remove any [=data integrity proof|proofs=] -that it does not explicitly know it can safely present. Any -[=data integrity proof|proofs=] that software does explicitly know it can -safely present can remain. For example, a digital wallet that can verify -an `ecdsa-rdfc-2019` -[=data integrity proof|proof=], but not an `ecdsa-jcs-2019` [=data integrity -proof|proof=], can still present either. Other [=data integrity proof|proofs=], -such as those that offer [=selective disclosure=] and / or [=unlinkable -disclosure=] features require -transformation (that is, a -base proof is transformed to a derived proof plus a "reveal document") and, -therefore, a wallet will not be able to [=presentation|present=] these [=data -integrity proof|proofs=] unless the wallet has implemented the procedures for -deriving a proof. It is vital that a wallet not present a base proof by -accident, as it might include information that is secret to the [=holder=]. + This section details the general threat model for this specification + including security considerations, privacy considerations, and market + competition considerations.

-
- -
-

Use of HTTPS for Interaction URLs

-This specification strongly suggests the use of HTTPS for [=interaction URLs=] -for the following reasons: -

- -
    -
  • -The HTTPS URL used in an interaction firmly establishes trust in the -interaction based on the existing and well understood same-origin trust model -used by browsers. -
    • -
  • -The initial URL provided establishes trust such that subsequent protocols used -in the interaction can be simply and safely delegated or outsourced to other -systems, some of which can be in a separate domain. -
    • -
  • -Graphical interfaces that need to gather consent can use domain names, which -are understood well enough by the general population to combat phishing attacks. -
    • -
  • -Protocols that require stronger verification of any party can use -protocol-specific mechanisms, such as [=verifiable credentials=], to verify -the [=holder=], [=issuer=], or [=verifier=] during a particular protocol -exchange. -
    • -
- -

-Using protocol schemes that are not rooted in the HTTPS trust model requires -separate encryption protocol, key management, and trust models to be used, which -are often less broadly developed and deployed and require much more development -and analysis to determine the threat and privacy model. -

- -
- -
-

Deletion

- -

-The APIs provided by this specification enable the deletion of -[=verifiable credentials=] and [=verifiable presentations=] from -[=storage services=]. The result of these deletions -and the side-effects they might cause are out of scope for this specification. -However, implementers are advised to understand the various ways deletion can be -implemented. There are at least two types of deletion that are contemplated by -this specification. -

- -

-Partial deletion marks a record for deletion but continues to store -some or all of the original information. This mode of operation can be useful if -there are audit requirements for all credentials and/or presentations over -a particular time period, or if recovering an original credential might be a -useful feature to provide. -

-

-Complete deletion purges all information related to a given -[=verifiable credential=] or [=verifiable presentation=] in a way that -is unrecoverable. This mode of operation can be useful when removing information -that is outdated and beyond the needs of any audit or when responding to any -sort of "right -to be forgotten" request. -

-

-When deleting a [=verifiable credential=], handling of its status -information needs to be considered. Some use cases might call for deletion -of a particular [=verifiable credential=] to also set the revocation -and suspension bits of that [=verifiable credential=], such that any sort of -status check for the deleted credential fails and use of the credential is -halted. -

-

-Given the scenarios above, implementers are advised to allow the system actions -that occur after a delete to be configurable, such that system flexibility is -sufficient to address any [=verifiable credential=] use case. -

-
- -
-

Payload Sizes

-

-Larger transactions can trigger DoS incidents. It's recommended to configure the -payload size accepted by endpoints at an instance level. -

-
- -
-

Additional Validation

-

-In most cases, simply verifying the proof might not be sufficient to properly -handle the received data. [=Verifier services=] are expected to configure additional -validation steps based on their use cases. To define such additional -validations, implementers can refer to specifications such as -Section 2.3: Resource -Integrity and -Section 2.4: -Contexts and Vocabularies -in the [[[?VC-DATA-INTEGRITY]]] specification where further information can be -found about context handling and integrity verification. -

-

-Improper validation will often lead to security vulnerabilities. -

-

-Additional validation steps can be accounted for when returning a verification -response object, through the problem details. -

-
- -
-

Secure Coding Practices

- -

-Implementers are urged to use industry standard secure coding practices when -implementing this specification. Even deeply experienced software developers can -make mistakes and the use of secure coding checklists and vulnerability scanning -software can catch errors that would result in security compromises. Following -checklists and guides such as the - -OWASP Secure Coding Practices Checklist and the - -OWASP Web Security Testing Guide can help reduce the chance of insecure -implementations. -

-
- -
-

Threat Model

-

A threat model for the VCALM specification has been created based on a use case of a first responder onboarding themselves to a new incident. This use case was chosen because it could be simplified to detail the issuance of a [=verifiable credential=] for the particular incident, predicated on the [=verification=] of an existing emergency responder credential. This enabled the data flow diagram in the threat model to detail both the [=verification=] and issuance steps, in the same workflow.

-
- -
-

Other Security Considerations

- -

-Since the interfaces to manage the lifecycle of [=verifiable credentials=] -described by this specification are generalized in nature, the security -implications of their use might not be immediately apparent to readers. -To understand the sort of security -concerns one might need to consider in a complete software system, implementers -are urged to read about how this technology can be used by the -[[[?VC-DATA-MODEL-2.0]]] specification (specifically the section -on -Verifiable Credential Security Considerations), as well as the -[[[?VC-DATA-INTEGRITY]]] specification (specifically the section -on -Data Integrity Security Considerations). -

-
+ +
+

Security Considerations

+

+ W3C is migrating to a holistic threat modelling approach and is in the process + of deprecating the Security Considerations sections in new specifications. + Please refer to Appendix [[[#threat-model]]] for documentation related to + security considerations. +

+
+
+

Privacy Considerations

+

+ W3C is migrating to a holistic threat modelling approach and is in the process + of deprecating the Privacy Considerations sections in new specifications. Please + refer to Appendix [[[#threat-model]]] for documentation related to privacy + considerations. +

+
diff --git a/threat-model/index.html b/threat-model/index.html index 7d1c1a75..15947d6b 100644 --- a/threat-model/index.html +++ b/threat-model/index.html @@ -114,6 +114,17 @@ + + + + + + + + + + + @@ -726,6 +737,53 @@

Threats

+
+

Security Considerations

+

+ This section details additional security considerations that were not + found to have direct threats related to this specification but the group + still wanted to highlight. +

+ +
+

Secure Coding Practices

+ +

+ Implementers are urged to use industry standard secure coding practices when + implementing this specification. Even deeply experienced software developers can + make mistakes and the use of secure coding checklists and vulnerability scanning + software can catch errors that would result in security compromises. Following + checklists and guides such as the + + OWASP Secure Coding Practices Checklist and the + + OWASP Web Security Testing Guide can help reduce the chance of insecure + implementations. +

+
+ +
+

Other Security Considerations

+ +

+ Since the interfaces to manage the lifecycle of [=verifiable credentials=] + described by this specification are generalized in nature, the security + implications of their use might not be immediately apparent to readers. + To understand the sort of security + concerns one might need to consider in a complete software system, implementers + are urged to read about how this technology can be used by the + [[[?VC-DATA-MODEL-2.0]]] specification (specifically the section + on + Verifiable Credential Security Considerations), as well as the + [[[?VC-DATA-INTEGRITY]]] specification (specifically the section + on + Data Integrity Security Considerations). +

+
+ +
+ + \ No newline at end of file diff --git a/threat-model/threats/outline.js b/threat-model/threats/outline.js index 4db93cd8..b7494ab1 100644 --- a/threat-model/threats/outline.js +++ b/threat-model/threats/outline.js @@ -8,12 +8,12 @@ { name: "Implementation Threats", id: "threat-model-implementation-threats", - threats: ["T2", "T3", "T9", "T14", "T15", "T16", "T18", "T20", "T22", "T23", "T24", "T25", "T26", "T27"], + threats: ["T2", "T3", "T9", "T14", "T15", "T16", "T18", "T20", "T22", "T23", "T24", "T25", "T26", "T27", "T33", "T34", "T35", "T36", "T38", "T39", "T40"], }, { name: "External Threats", id: "threat-model-externnal-threats", - threats: ["T8", "T10", "T11", "T12", "T13", "T29"], + threats: ["T8", "T10", "T11", "T12", "T13", "T29", "T30", "T31", "T32", "T37"], }, { name: "Dependency Threats", diff --git a/threat-model/threats/t30-issuance-request-and-or-delivery-made-by-third-party.js b/threat-model/threats/t30-issuance-request-and-or-delivery-made-by-third-party.js new file mode 100644 index 00000000..4e50968a --- /dev/null +++ b/threat-model/threats/t30-issuance-request-and-or-delivery-made-by-third-party.js @@ -0,0 +1,15 @@ +(function () { + var threat = { + id: "T30", + name: "Issuance Request and/or Delivery Made by Third Party", + desc: "Verifiable credentials issuance has a request phase and a delivery phase. The request might be made by the subject or another role, and delivery can be to a client that might or might not be controlled by the subject.", + response: [ + { id: "R45", name: "Cryptographic Delegation", type: "Reduce", desc: "Use of cryptographically bound delegation techniques, such as zCaps, allow for third parties to act on behalf of the subject." } + ], + elements: ["F1", "F19", "P1", "P4", "P5"], + tags: ["security", "privacy"], + taxonomyName: "STRIDE", + taxonomyClass: "Spoofing" + }; + window.ThreatModel.register(threat); +})(); diff --git a/threat-model/threats/t31-unintended-data-leak-due-to-third-party-processing.js b/threat-model/threats/t31-unintended-data-leak-due-to-third-party-processing.js new file mode 100644 index 00000000..5f50ec21 --- /dev/null +++ b/threat-model/threats/t31-unintended-data-leak-due-to-third-party-processing.js @@ -0,0 +1,16 @@ +(function () { + var threat = { + id: "T31", + name: "Unintended Data Leak Due to Third Party Processing", + desc: "An issuer or verifier may make use of a third party service to process some data during an issuance or verification workflow. This third party service becomes a potential data leak risk as it may be able to aggregate across different issuers or verifiers using its services.", + response: [ + { id: "R46", name: "Minimize Data Sent to Third Party Services", type: "Reduce", desc: "Sending only data necessary for a third party service to perform its intended function limits the ability of the service, maliciously or via attacks on said service, to reveal unintended data." }, + { id: "R47", name: "Appropriate Legal Contracts", type: "Transfer", desc: "When making use of a third party service, having appropriate legal contracts in place around the usage of the data sent to the service allows issuers and verifiers to have recourse should data leaks occur." } + ], + elements: ["P4"], + tags: ["privacy"], + taxonomyName: "STRIDE", + taxonomyClass: "Information Disclosure" + }; + window.ThreatModel.register(threat); +})(); diff --git a/threat-model/threats/t32-malicious-entity-acts-on-behalf-of-incapable-party.js b/threat-model/threats/t32-malicious-entity-acts-on-behalf-of-incapable-party.js new file mode 100644 index 00000000..7ffa9b2c --- /dev/null +++ b/threat-model/threats/t32-malicious-entity-acts-on-behalf-of-incapable-party.js @@ -0,0 +1,15 @@ +(function () { + var threat = { + id: "T32", + name: "Malicious Entity Acts on Behalf of Incapable Party", + desc: "Some subjects such as a new born baby, a pet, or a person with dementia, are incapable of acting on their own behalf. In these cases requests may be made on behalf of a subject with no cryptographic delegation possible. This can be problematic for guardians with malicious intent.", + response: [ + { id: "R48", name: "Additional Validation Steps in Workflow", type: "Reduce", desc: "In cases where the requesting party is not the intended subject of the action being requested, the workflow in question can include additional validation steps that ask the requesting party for additional information." } + ], + elements: ["F1", "F19", "P1", "P4"], + tags: ["security", "privacy"], + taxonomyName: "STRIDE", + taxonomyClass: "Spoofing" + }; + window.ThreatModel.register(threat); +})(); diff --git a/threat-model/threats/t33-verifier-phones-home-about-specific-verifiable-credential.js b/threat-model/threats/t33-verifier-phones-home-about-specific-verifiable-credential.js new file mode 100644 index 00000000..66921b31 --- /dev/null +++ b/threat-model/threats/t33-verifier-phones-home-about-specific-verifiable-credential.js @@ -0,0 +1,15 @@ +(function () { + var threat = { + id: "T33", + name: "Verifier “phones home” about specific verifiable credential", + desc: "It is considered a bad privacy practice for a verifier to contact an issuer about a specific verifiable credential. This practice is known as \"phoning home\" and can result in a mismatch in privacy expectations between holders, issuers, verifiers, and other parties expressed in a verifiable credential. Phoning home enables issuers to correlate unsuspecting parties with the use of certain verifiable credentials which can violate privacy expectations that each entity might have regarding the use of those credentials. For example, what is expected by the holder to be a private interaction between them and the verifier becomes one where the issuer is notified of the interaction.", + response: [ + { id: "R30", name: "Use privacy-respecting status list", type: "Reduce", desc: "There are some interactions where contacting the issuer in a privacy-preserving manner upholds the privacy expectations of the holder. For example, contacting the issuer to get revocation status information in a privacy-respecting manner, such as through a status list that provides group privacy can be acceptable as long as the issuer is not able to single out which verifiable credential is being queried based on the retrieval of the status list. For more information on one such mechanism see the Bitstring Status List v1.0 specification." }, + { id: "R31", name: "Make use of Oblivious HTTP and aggressive cashing of results", type: "Reduce", desc: "Verifiers are urged to not \"phone home\" in ways that will create privacy violations. When retrieving content that is linked from a verifiable credential, using mechanisms such as Oblivious HTTP and aggressively caching results can improve the privacy characteristics of the ecosystem." } + ], + elements: ["P4", "P6", "F14", "P9"], + taxonomyName: "STRIDE", + taxonomyClass: "Information Disclosure" + }; + window.ThreatModel.register(threat); +})(); diff --git a/threat-model/threats/t34-unknown-proof-types.js b/threat-model/threats/t34-unknown-proof-types.js new file mode 100644 index 00000000..e40240aa --- /dev/null +++ b/threat-model/threats/t34-unknown-proof-types.js @@ -0,0 +1,18 @@ +(function () { + var threat = { + id: "T34", + name: "Unknown Proof Types", + desc: "Holder coordinator implementations, such as digital wallet software, can receive and store verifiable credentials that include proofs that are not understood by the software.", + response: [ + { id: "R32", name: "Remove Unsupported Proofs Prior to Presentation", type: "Eliminate", desc: "A verifiable credential with several proofs, some of which the implementation understands and others that it does not, can be presented by the implementation provided that the proof of choice is understood by the implementation and the others are removed prior to presentation. Implementations maintain allow lists of understood proofs and ensure that any proofs not included are stripped prior to presentation." }, + { id: "R33", name: "Holder as Interoperability Conduit", type: "Transfer", desc: "It is important for implementers to understand that in the three party model, the holder coordinator acts as a conduit between the issuer and the verifier, enabling interoperability between the two even if/when the holder coordinator doesn't necessarily implement verification of certain proofs. As an example in another space: \"Web browsers were able to download and store PDF files prior to adding their own PDF-reader functionality\". This kind of decentralized innovation, interoperability, and progressive enhancement is important in the three party model and more generally in scalable, decentralized ecosystems. It is also important to help reduce centralization by not forcing people to adopt specific new and different software just to store a verifiable credential that has at least one proof on it that their current software does not (yet) understand." }, + { id: "R34", name: "Use Unknown Proofs as Adoption Signals", type: "Reduce", desc: "Implementations can use the presence of unknown proofs as potential adoption signals in a decentralized ecosystem." }, + { id: "R35", name: "Only Present Proofs That Are Well Understood", type: "Reduce", desc: "A holder coordinator might be able to present some proofs even when it does not have the software to verify them, but this needs to be understood with certainty, not guessed. That is, when adding a copy of a stored verifiable credential to a presentation, holder software needs to remove any proofs that it does not explicitly know it can safely present. Any proofs that software explicitly knows it can safely present can remain. For example, a digital wallet that can verify an `ecdsa-rdfc-2019` proof, but not an `ecdsa-jcs-2019` proof, may include either of these in a verifiable presentation. Other proofs, such as those that offer selective disclosure and/or unlinkable disclosure features require transformation (that is, a base proof is transformed to a derived proof plus a \"reveal document\") and, therefore, a wallet will not be able to present these proofs unless the wallet has implemented the procedures for deriving a proof. It is vital that a wallet not present a base proof by accident, as it might include information that is secret to the holder." } + ], + elements: ["P1", "F12", "F19", "P5", "P7", "P6", "F16", "F13"], + tags: ["security"], + taxonomyName: "STRIDE", + taxonomyClass: "" + }; + window.ThreatModel.register(threat); +})(); diff --git a/threat-model/threats/t35-interaction-url-does-not-use-https.js b/threat-model/threats/t35-interaction-url-does-not-use-https.js new file mode 100644 index 00000000..a872a246 --- /dev/null +++ b/threat-model/threats/t35-interaction-url-does-not-use-https.js @@ -0,0 +1,18 @@ +(function () { + var threat = { + id: "T35", + name: "Interaction URL Does Not Use HTTPS", + desc: "Using protocol schemes that are not rooted in the HTTPS trust model requires separate encryption protocol, key management, and trust models to be used, which are often less broadly developed and deployed and require much more development and analysis to determine the threat and privacy model.", + response: [ + { id: "R36", name: "Same Origin Trust Model", type: "Transfer", desc: "The HTTPS URL used in an interaction firmly establishes trust in the interaction based on the existing and well understood same-origin trust model used by browsers." }, + { id: "R37", name: "Establish Trust Upfront", type: "Transfer", desc: "The URL of the coordinator application that the authenticated holder is engaging within establishes trust such that subsequent protocols used in the interaction may be simply and safely delegated or outsourced to other systems, some of which may be in a separate domain." }, + { id: "R38", name: "Use Domain Name for Consent", type: "Transfer", desc: "Graphical interfaces that need to gather consent can use domain names, which are understood well enough by the general population to combat phishing attacks." }, + { id: "R39", name: "Protocol-Specific Elevation for Stronger Verification", type: "Transfer", desc: "Protocols that require stronger verification of any party can use protocol-specific mechanisms, such as verifiable credentials, to verify the holder, issuer, or verifier during a particular protocol exchange." } + ], + elements: ["D2", "F3", "P4", "P2", "P1"], + tags: ["security"], + taxonomyName: "STRIDE", + taxonomyClass: "Spoofing" + }; + window.ThreatModel.register(threat); +})(); diff --git a/threat-model/threats/t36-deletion-request-only-results-in-partial-deletion-of-credential.js b/threat-model/threats/t36-deletion-request-only-results-in-partial-deletion-of-credential.js new file mode 100644 index 00000000..3211f92c --- /dev/null +++ b/threat-model/threats/t36-deletion-request-only-results-in-partial-deletion-of-credential.js @@ -0,0 +1,16 @@ +(function () { + var threat = { + id: "T36", + name: "Deletion Request Only Results in Partial Deletion of Credential", + desc: "The APIs provided by this specification enable the deletion of verifiable credentials and verifiable presentations from storage services. In some cases, a record may be only partially deleted which means that some or all of the original information continues to be stored. This mode of operation can be useful if there are audit requirements for all credentials and/or presentations over a particular time period, or if recovering an original credential might be a useful feature to provide but can lead to unintended persistence of records for longer than necessary.", + response: [ + { id: "R40", name: "Have a Good Use Case for Only Partially Deleting a Record", type: "Reduce", desc: "When choosing how to implement the function of deleting a verifiable credential, consider carefully the various use cases that may warrant the continued storage of some or all of the data being deleted against the potential harm should the data ever be compromised." }, + { id: "R42", name: "Configurable Deletion", type: "Reduce", desc: "Implementers are advised to allow the system actions that occur after a deletion to be configurable, such that system flexibility is sufficient to address any verifiable credential use case." } + ], + elements: ["E1", "C5", "C6"], + tags: ["privacy"], + taxonomyName: "STRIDE", + taxonomyClass: "Information Disclosure" + }; + window.ThreatModel.register(threat); +})(); diff --git a/threat-model/threats/t37-credential-deletion-violates-legal-regulation.js b/threat-model/threats/t37-credential-deletion-violates-legal-regulation.js new file mode 100644 index 00000000..a453c1eb --- /dev/null +++ b/threat-model/threats/t37-credential-deletion-violates-legal-regulation.js @@ -0,0 +1,16 @@ +(function () { + var threat = { + id: "T37", + name: "Credential Deletion Violates Legal Regulation", + desc: "Due to some legal regulations and/or audit requirements, the complete or partial storage of a credential is required for some amount of time after a deletion request has been made.", + response: [ + { id: "R41", name: "Establish Clear Policy Regarding Credential Deletion", type: "Transfer", desc: "Often confusion and frustration about why data is being retained is a result of a lack of communication between the various parties involved. If data is being retained for some valid reason, clear communication of these reasons back to the end user allows for all parties to make informed decisions and use the appropriate channels for complaints." }, + { id: "R42", name: "Configurable Deletion", type: "Reduce", desc: "Implementers are advised to allow the system actions that occur after a deletion to be configurable, such that system flexibility is sufficient to address any verifiable credential use case." } + ], + elements: ["P7", "P8", "P9", "C5"], + tags: ["privacy"], + taxonomyName: "STRIDE", + taxonomyClass: "Information Disclosure" + }; + window.ThreatModel.register(threat); +})(); diff --git a/threat-model/threats/t38-mishandled-status-information-upon-credential-deletion-reveals-information.js b/threat-model/threats/t38-mishandled-status-information-upon-credential-deletion-reveals-information.js new file mode 100644 index 00000000..f41e664b --- /dev/null +++ b/threat-model/threats/t38-mishandled-status-information-upon-credential-deletion-reveals-information.js @@ -0,0 +1,16 @@ +(function () { + var threat = { + id: "T38", + name: "Mishandled Status Information Upon Credential Deletion Reveals Information", + desc: "When deleting a verifiable credential, handling of its status information needs to be considered. Some use cases might call for deletion of a particular verifiable credential to also set the revocation and suspension bits of that verifiable credential, such that any sort of status check for the deleted credential fails and use of the credential is halted.", + response: [ + { id: "R41", name: "Establish Clear Policy Regarding Credential Deletion", type: "Transfer", desc: "Often confusion and frustration about why data is being retained is a result of a lack of communication between the various parties involved. If data is being retained for some valid reason, clear communication of these reasons back to the end user allows for all parties to make informed decisions and use the appropriate channels for complaints." }, + { id: "R42", name: "Configurable Deletion", type: "Reduce", desc: "Implementers are advised to allow the system actions that occur after a deletion to be configurable, such that system flexibility is sufficient to address any verifiable credential use case." } + ], + elements: ["E1", "P8", "P7", "P9"], + tags: ["privacy"], + taxonomyName: "STRIDE", + taxonomyClass: "Information Disclosure" + }; + window.ThreatModel.register(threat); +})(); diff --git a/threat-model/threats/t39-large-payload-triggers-denial-of-service-dos.js b/threat-model/threats/t39-large-payload-triggers-denial-of-service-dos.js new file mode 100644 index 00000000..fd2cfcf4 --- /dev/null +++ b/threat-model/threats/t39-large-payload-triggers-denial-of-service-dos.js @@ -0,0 +1,15 @@ +(function () { + var threat = { + id: "T39", + name: "Large Payload Triggers Denial of Service (DoS)", + desc: "Large transaction payloads can trigger DoS incidents.", + response: [ + { id: "R43", name: "Configure Payload Size at Instance Level", type: "Reduce", desc: "It's recommended to configure the payload size accepted by endpoints at an instance level." } + ], + elements: ["P2", "P1", "P4", "P5", "F12", "F19", "P3", "F9"], + tags: ["security"], + taxonomyName: "STRIDE", + taxonomyClass: "Denial of Service" + }; + window.ThreatModel.register(threat); +})(); diff --git a/threat-model/threats/t40-improper-credential-validation-leads-to-security-vulnerabilities.js b/threat-model/threats/t40-improper-credential-validation-leads-to-security-vulnerabilities.js new file mode 100644 index 00000000..f5dd7c35 --- /dev/null +++ b/threat-model/threats/t40-improper-credential-validation-leads-to-security-vulnerabilities.js @@ -0,0 +1,15 @@ +(function () { + var threat = { + id: "T40", + name: "Improper Credential Validation Leads to Security Vulnerabilities", + desc: "In most cases, simply verifying the proof might not be sufficient to properly handle the received data. Improper validation will often lead to security vulnerabilities.", + response: [ + { id: "R44", name: "Additional validation", type: "Reduce", desc: "Verifier services are expected to configure additional validation steps based on their use cases. To define such additional validations, implementers can refer to specifications such as Section 2.3: Resource Integrity and Section 2.4: Contexts and Vocabularies in the Verifiable Credential Data Integrity 1.0 specification where further information can be found about context handling and integrity verification. Additional validation steps can be accounted for when returning a verification response object, through the problem details." } + ], + elements: ["E1", "P5", "P4"], + tags: ["security"], + taxonomyName: "STRIDE", + taxonomyClass: "Tampering" + }; + window.ThreatModel.register(threat); +})();