Perform security and privacy assessment

[dlongley]

We need to produce a security and privacy assessment document by answering these questions:

https://www.w3.org/TR/security-privacy-questionnaire/

We aren't doing an browser APIs so it may not be immediately clear how to/if some of these questions can be answered.

[dlongley]

An example from the Web Payments Working Group:

https://docs.google.com/document/d/1w7ginyzNg-xZUmITK4vzcGUKB4gbMOAvlkWWaRtX14k

[dlongley]

cc: @David-Chadwick -- want to make sure you saw the example above.

[David-Chadwick]

Thanks Dave

[dlongley]

@David-Chadwick, thanks for the privacy assessment here:

https://lists.w3.org/Archives/Public/public-vc-wg/2017Oct/0003.html

We should get this into github in HTML format so others can comment or add with PRs.

[David-Chadwick]

3 Questions to Consider

3.1 Does this specification deal with personally-identifiable information?

Yes. The properties inside VCs are PII

Recommendation. None as the specification makes this clear.

3.2 Does this specification deal with high-value data?

Potentially yes. The specification places no restrictions on what data can be placed in a VC, but it could be highly sensitive personal data.

Recommendation. Protocols that carry VCs should always encrypt the VC payload. In addition, VCs that contain highly sensitive personal data should have that data encrypted inside the VC, so that any entity that captures the VC is not able to see the sensitive information.

3.3 Does this specification introduce new state for an origin that persists across browsing sessions?

Not of itself no, as the specification only specifies a data structure. However, protocols that use this specification may introduce new state.

Recommendation. None

3.4 Does this specification expose persistent, cross-origin state to the web?

Yes. VCs contain a random though potentially persistent identifier of the subject. This is passed between the issuer and the inspector. Consequently collusion between them could identify the subject to the inspector, even though the VC itself does not. This is because in many cases the issuer will know the complete identity of the subject, even if the VC only contains a small proportion of it (such as age).

Recommendation. The subject should limit the distribution of VCs containing the same PId to a minimal number of origins. The subject should obtain VCs with different PId to send to different origins wherever possible.

3.5 Does this specification expose any other data to an origin that it doesn't currently have access to?

Yes. It is the purpose of VCs to present identity attributes of the subject to the inspector. Note however that this is always with the full consent of the subject, except in the special case where the holder is not the subject. In this latter case the holder must be authorized to present this information to the inspector, otherwise the inspector should reject it.

Recommendation. Inspectors should only accept VCs from subjects or from holders who are authorized to present them to the inspector.

3.6 Does this specification enable new script execution/loading mechanisms?

Not of itself no, as the specification only specifies a data structure. However, protocols that use this specification may enable script loading.

Recommendation. None

3.7 Does this specification allow an origin access to a user's location?

Yes. VCs may contain location information such as a subject's home address, phone number, or current postal address.

Recommendation. None.

3.8 Does this specification allow an origin access to sensors on a user's device?

Not of itself no, as the specification only specifies a data structure. However, protocols that use this specification may enable access to sensors on a user's device.

Recommendation. None.

3.9 Does this specification allow an origin access to aspects of a user's local computing environment?

Not of itself no, as the specification only specifies a data structure. However, protocols that use this specification may enable an origin to access aspects of a user's local computing environment.

Recommendation. None.

3.10 Does this specification allow an origin access to other devices?

Not of itself no, as the specification only specifies a data structure. However, protocols that use this specification may enable an origin to access other devices e.g. to move a VC from one device to another.

Recommendation. None.

3.11 Does this specification allow an origin some measure of control over a user agent's native UI?

Not of itself no, as the specification only specifies a data structure. However, protocols that use this specification may enable an origin some measure of control over a user agent's native UI.

Recommendation. None.

3.12 Does this specification expose temporary identifiers to the web?

Potentially yes. The subject's ID in a VC could be a temporary identifier that is not stored permanently anywhere.

Recommendation. VCs should be encrypted during transfer to avoid their contents being snooped.

3.13 Does this specification distinguish between behaviour in first-party and third-party contexts?

???

3.14 How should this specification work in the context of a user agent's "incognito" mode?

This specification only presents a data model. However protocols that use this specification should be able to work in incognito mode.

Recommendation. None.

3.15 Does this specification persist data to a user's local device?

The overall life cycle of VCs envisages that they are stored persistently on the user's local device or on a remote device under the user's control. However, VCs on their own, if captured by a hostile entity, should not be of any value to it, except in so far as the VC may potentially reveal a small amount of PII about the subject.

Recommendation. VCs should be encrypted during storage to prevent them being stolen by an attacker

3.16 Does this specification have a Security Considerations and Privacy Considerations section?

Yes.

Recommendation. Ensure they are good enough

3.17 Does this specification allow downgrading default security characteristics?

No. The specification simply defines a data structure and a signature field.

Recommendation. None

[TallTed]

On Oct 10, 2017, at 11:42 AM, David Chadwick notifications@github.com wrote:

3.5 Does this specification expose any other data to an origin that it doesn't currently have access to?

Yes. It is the purpose of VCs to present identity attributes of the subject to the inspector. Note however that this is always with the full consent of the subject, except in the special case where the holder is not the subject. In this latter case the holder must be authorized to present this information to the inspector, otherwise the inspector should reject it.

"always with the full consent of the subject" says that I cannot verifiably say anything about anything.

I cannot make verifiable claims about the Eiffel Tower, because the Eiffel Tower cannot consent.

The scope of this work is supposedly confined to checking whether "Joe said { x y z }". That is -- verifying that the statement "{ x y z }" emanated from the entity "Joe".

This group's work is not supposed to be about checking whether Fred, who presented the statement from Joe, has authorization from either Joe or x.

This group's work is not supposed to be about checking whether Joe has authorization from x.

This group's work is not supposed to be about checking whether Joe is qualified to know anything about x's y.

This group's work is not supposed to be about confirming whether x's y is in fact z.

The work that is being done in these directions may well have value, but it is equally well outside of scope.

-- A: Yes. http://www.idallen.com/topposting.html | Q: Are you sure?
| | A: Because it reverses the logical flow of conversation. | | | Q: Why is top posting frowned upon?

Ted Thibodeau, Jr. // voice +1-781-273-0900 x32 Senior Support & Evangelism // mailto:tthibodeau@openlinksw.com // http://twitter.com/TallTed OpenLink Software, Inc. // http://www.openlinksw.com/ 10 Burlington Mall Road, Suite 265, Burlington MA 01803 Weblog -- http://www.openlinksw.com/blogs/ LinkedIn -- http://www.linkedin.com/company/openlink-software/ Twitter -- http://twitter.com/OpenLink Google+ -- http://plus.google.com/100570109519069333827/ Facebook -- http://www.facebook.com/OpenLinkSoftware Universal Data Access, Integration, and Management Technology Providers

[David-Chadwick]

Nobody really cares if Joe literally said 'x y z' unless they talk alphabet language. Furthermore Joe is entitled to say whatever he wants about anything but that is outside the scope of our work.

Our work is limited to self-sovereign credentials. Please read again the Abstract of the 29th Aug version of Data Model document. It says "Driver's licenses are used to claim that we are capable of operating a motor vehicle, university degrees can be used to claim our education status, and government-issued passports enable holders to travel between countries. This specification provides a standard way to express these sorts of claims on the Web in a way that is cryptographically secure, privacy respecting, and automatically verifiable."

There are a number of implicit assumptions we can draw from the above summary, such as: i) the credentials are authorisation tokens, not any random statement about anything ii) they will usually be presented by the subject i.e. holder=subject iii) since they are privacy respecting the subject will not need to be identified, meaning that x remains a meaningless x to the inspector iv) if x is meaningless, and credentials are automatically verifiable, then the inspector needs an automatic way knowing the relationship between x and the holder

regards David

[stonematt]

I'm not sure that I agree with credentials = authorization tokens - they may be used that way sometimes, but it's not a universally true statement. I agree that "full consent of the subject" is not required, nor desired for our scope. @TallTed mentions that the Eiffel tower can't consent, we also have the need to assert "negative claims" about an individual, which would never obtain consent by the holder.

In order for a VC to work, the inspector simply has to know who the issuer is and who/what the claim is about -- and trust that it hasn't been tampered. There are NO RULES about what can be asserted in a VC. It's up to the inspector's judgement to determine if the issuer and claim meets their needs.

We also know that issuers (and probably holders) in the marketplace will put limits on how a claim can be used. The simple example is duration. An issuer can say I assert x about subject A and I will stand behind this assertion for 10days (unless revoked {here})

There is a final requirement that the Datamodel/ecosystem must support. Claims should be untethered from the issuer, such that the subject (or agent) could choose to store and manage their own repository of claims and share any collection of them on demand.

From a privacy perspective, transparency is likely our key feature. The subject should be able to read the claim that's being made about them and have a mechanism to dispute it. That may be all.

[David-Chadwick]

Please read 3.5 again. It is correct. It currently says "this is always with the full consent of the subject, except in the special case where the holder is not the subject." It might be clearer if it is reworded to say "this is always with the full consent of the subject where the holder is the subject." Followed by "In the special case where the holder is not the subject the holder should be authorized......" otherwise I believe the provisions of the EU General Data Protection Regulation would be violated if random holders present PII about identifiable people to inspectors.

[dlongley]

I believe we've added this to the spec, closing.