-
Notifications
You must be signed in to change notification settings - Fork 110
/
privacy.html
294 lines (258 loc) · 11.7 KB
/
privacy.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
<!DOCTYPE html>
<html>
<head>
<title>Verifiable Credentials Data Model 1.0: Privacy Analysis</title>
<meta http-equiv='Content-Type' content='text/html;charset=utf-8'/>
<!--
=== NOTA BENE ===
For the three scripts below, if your spec resides on dev.w3 you can check them
out in the same tree and use relative links so that they'll work offline,
-->
<script src='https://www.w3.org/Tools/respec/respec-w3c-common' class='remove'></script>
<script src="./common.js" class="remove"></script>
<script type="text/javascript" class="remove">
var respecConfig = {
// specification status (e.g. WD, LCWD, NOTE, etc.). If in doubt use ED.
specStatus: "ED",
// the specification's short name, as in http://www.w3.org/TR/short-name/
shortName: "verifiable-credentials-privacy-analysis",
// subtitle for the spec
subtitle: "A privacy analysis of the Verifiable Credentials data model",
// if you wish the publication date to be other than today, set this
//publishDate: "2017-08-03",
// if there is a previously published draft, uncomment this and set its YYYY-MM-DD date
// and its maturity status
// previousPublishDate: "1977-03-15",
// previousMaturity: "WD",
// extend the bibliography entries
localBiblio: vcwg.localBiblio,
github: "https://github.com/w3c/vc-data-model",
includePermalinks: false,
// if there a publicly available Editor's Draft, this is the link
edDraftURI: "https://w3c.github.io/vc-data-model/privacy.html",
// if this is a LCWD, uncomment and set the end of its review period
// lcEnd: "2009-08-05",
// editors, add as many as you like
// only "name" is required
editors: [
{ name: "David Chadwick", url: "https://www.linkedin.com/in/david-chadwick-36816395/",
company: "University of Kent", companyURL: "https://www.kent.ac.uk/"},
{ name: "Manu Sporny", url: "https://digitalbazaar.com/",
company: "Digital Bazaar", companyURL: "https://digitalbazaar.com/" }
],
// authors, add as many as you like.
// This is optional, uncomment if you have authors as well as editors.
// only "name" is required. Same format as editors.
authors:
[
{ name: "David Chadwick", url: "https://www.linkedin.com/in/david-chadwick-36816395/",
company: "University of Kent", companyURL: "https://www.kent.ac.uk/"},
{ name: "Manu Sporny", url: "https://digitalbazaar.com/",
company: "Digital Bazaar", companyURL: "https://digitalbazaar.com/" }
],
// name of the WG
wg: "Verifiable Credentials Working Group",
// URI of the public WG page
wgURI: "https://www.w3.org/2017/vc/",
// name (with the @w3c.org) of the public mailing to which comments are due
wgPublicList: "public-vc-comments",
// URI of the patent status for this WG, for Rec-track documents
// !!!! IMPORTANT !!!!
// This is important for Rec-track documents, do not copy a patent URI from a random
// document unless you know what you're doing. If in doubt ask your friendly neighborhood
// Team Contact.
wgPatentURI: "https://www.w3.org/2004/01/pp-impl/98922/status",
maxTocLevel: 4,
inlineCSS: true
};
</script>
<style>
pre .highlight {
font-weight: bold;
color: green;
}
pre .subject {
font-weight: bold;
color: RoyalBlue;
}
pre .property {
font-weight: bold;
color: DarkGoldenrod;
}
pre .comment {
font-weight: bold;
color: Gray;
}
</style>
</head>
<body>
<section id='abstract'>
<p>
This document is a privacy analysis of the Verifiable Credentials Data Model.
</p>
</section>
<section id='sotd'>
<p>
Comments regarding this document are welcome. Please file issues
directly on <a href="https://github.com/w3c/vc-data-model/issues/">GitHub</a>,
or send them to
<a href="mailto:public-vc-comments@w3.org">public-vc-comments@w3.org</a>
(<a href="mailto:public-vc-comments-request@w3.org?subject=subscribe">subscribe</a>,
<a href="https://lists.w3.org/Archives/Public/public-vc-comments/">archives</a>).
</p>
</section>
<section>
<h1>Privacy Analysis</h1>
<section>
<h2>Does this specification deal with personally identifiable information?</h2>
<p>
Yes. The properties inside Verifiable Credentials include Personally Identifiable Information (PII).
</p>
<p>
Recommendation: None, as the specification makes this clear.
</p>
</section>
<section>
<h2>Does this specification deal with high-value data?</h2>
<p>
Potentially yes. The specification places no restrictions on what data can be placed in a Verifiable Credential, so it could include highly sensitive personal data.
</p>
<p>
Recommendation: Protocols that carry Verifiable Credentials should always encrypt the Verifiable Credential payload. In addition, Verifiable Credentials that contain highly sensitive personal data should have that data encrypted inside the Verifiable Credential, so that any entity that captures the Verifiable Credential is not able to see the sensitive information.
</p>
</section>
<section>
<h2>Does this specification introduce new state for an origin that persists across browsing sessions</h2>
<p>
Not in itself, no, as the specification only specifies a data structure. However, protocols that use this specification may introduce new state.
</p>
<p>
Recommendation: None
</p>
</section>
<section>
<h2>Does this specification expose a persistent, cross-origin state to the web?</h2>
<p>
Yes. Verifiable Credentials contain a random though potentially persistent identifier of the subject. This is passed between the issuer and the verifier. Consequently, collusion between them could identify the subject to the verifier, even though the Verifiable Credential itself does not. This is because in many cases the issuer will know the complete identity of the subject, even if the Verifiable Credential only contains a small proportion of it (such as age).
</p>
<p>
Recommendation: The holder should limit the distribution of Verifiable Credentials containing the same PId to a minimal number of origins. The holder should obtain Verifiable Credentials with different PId to send to different origins wherever possible.
</p>
</section>
<section>
<h2>Does this specification expose any other data to an origin that it doesn’t currently have access to?</h2>
<p>
Yes. It is the purpose of Verifiable Credentials to present identity attributes of the subject to the verifier. Note, however, that this is always with the full consent of the subject, except in cases where the holder is not the subject. In this latter case, the holder must be authorized to present this information to the verifier; otherwise, the verifier should reject it.
</p>
<p>
Recommendation: Verifier should only accept Verifiable Credentials from subjects or holders who are authorized to present them to the verifier.
</p>
</section>
<section>
<h2>Does this specification enable new script execution/loading mechanisms?</h2>
<p>
Not in itself, no, as the specification only specifies a data structure. However, protocols that use this specification may enable script loading.
</p>
<p>
Recommendation: None
</p>
</section>
<section>
<h2>Does this specification allow an origin access to a user’s location?</h2>
<p>
Yes. Verifiable Credentials may contain location information such as a subject’s home address, phone number, or current postal address.
</p>
<p>
Recommendation: None.
</p>
</section>
<section>
<h2>Does this specification allow an origin access to sensors on a user’s device?</h2>
<p>
Not in 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.
</p>
<p>
Recommendation: None.
</p>
</section>
<section>
<h2>Does this specification allow an origin access to aspects of a user’s local computing environment?</h2>
<p>
Not in 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.
</p>
<p>
Recommendation: None.
</p>
</section>
<section>
<h2>Does this specification allow an origin access to other devices?</h2>
<p>
Not in 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 Verifiable Credential from one device to another.
</p>
<p>
Recommendation: None.
</p>
</section>
<section>
<h2>Does this specification allow an origin some measure of control over a user agent’s native UI?</h2>
<p>
Not in 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.
</p>
<p>
Recommendation: None.
</p>
</section>
<section>
<h2>Does this specification expose temporary identifiers to the web?</h2>
<p>
Potentially, yes. The subject’s ID in a Verifiable Credential could be a temporary identifier that is not stored permanently anywhere.
</p>
<p>
Recommendation: Verifiable Credentials should be encrypted during transfer to avoid their contents being snooped.
</p>
</section>
<section>
<h2>Does this specification distinguish between behavior in first-party and third-party contexts?</h2>
<p>
???
</p>
</section>
<section>
<h2>How should this specification work in the context of a user agent’s "incognito" mode?</h2>
<p>
This specification only presents a data model. However protocols that use this specification should be able to work in incognito mode.
</p>
<p>
Recommendation: None.
</p>
</section>
<section>
<h2>Does this specification persist data to a user’s local device?</h2>
<p>
The overall life cycle of Verifiable Credentials envisages that they may be stored persistently on the user’s local device or on a remote device under the user’s control. However, Verifiable Credentials on their own, if captured by a hostile entity, should not be of any value to it, except in so far as the Verifiable Credential may potentially reveal a small amount of Personally Identifiable Information (PII) about the subject.
</p>
<p>
Recommendation: Verifiable Credentials should be encrypted during storage to prevent them being stolen by an attacker
</p>
</section>
<section>
<h2>Does this specification have a "Security Considerations" and "Privacy Considerations" section?</h2>
<p>
Yes.
</p>
<p>
Recommendation: Ensure they are good enough.
</p>
</section>
<section>
<h2>Does this specification allow downgrading default security characteristics?</h2>
<p>
No. The specification simply defines a data structure and a signature field.
</p>
<p>
Recommendation: None
</p>
</section>
</section>
</body>
</html>