Skip to content

Commit 90fcf9d

Browse files
johannhofjohannhof
authored
Write initial privacy considerations for unnecessary use (#262)
1 parent 50c962a commit 90fcf9d

File tree

1 file changed

+304
-18
lines changed

1 file changed

+304
-18
lines changed

‎index.html

Lines changed: 304 additions & 18 deletions
Original file line numberDiff line numberDiff line change
@@ -74,6 +74,13 @@
7474
href: "https://docs.google.com/document/d/1Ppaz_EnhzHqPOz5UusRJvbSunh-RXPWgJ3Np_TM2EE0/",
7575
authors: ["Simone Onofri"]
7676
},
77+
"identity-web-impact": {
78+
title: "Identity & the Web",
79+
href: "https://www.w3.org/reports/identity-web-impact",
80+
authors: ["Simone Onofri"],
81+
date: "2025-02-25",
82+
publisher: "W3C"
83+
},
7784
},
7885
xref: {
7986
profile: "web-platform",
@@ -1128,10 +1135,11 @@ <h5>
11281135
</p>
11291136
<p>
11301137
Through the Digital Credentials API, the user agent can help
1131-
verifiers and wallets exchange unlinkable attributes, but it can not
1132-
guarantee that no linkable information is passed between verifiers
1133-
and wallets. It is recommended that user agents account for this fact
1134-
in their user permission experience.
1138+
verifiers and wallets exchange unlinkable attributes, but, because of
1139+
response encryption, it can not guarantee that no linkable
1140+
information is passed between verifiers and wallets. It is
1141+
recommended that user agents account for this fact in their user
1142+
permission experience.
11351143
</p>
11361144
<p class="issue" data-number="279">
11371145
Which level of unlinkability is the goal for this API? Can we
@@ -1237,21 +1245,299 @@ <h5>
12371245
<h3>
12381246
Unnecessary Requests for Credentials
12391247
</h3>
1240-
<p class="issue" title="Work in progress">
1241-
Explain how the API could be used to unnecessarily request digital
1242-
credentials from individuals such as requesting a driver's license to
1243-
log into a movie rating website and how the ecosystem can mitigate
1244-
this risk.
1248+
<p>
1249+
Unnecessary credential requests are a key privacy risk to the entire
1250+
digital credentials ecosystem. They could manifest in different ways
1251+
and from different motivations:
12451252
</p>
1246-
</section>
1247-
<section>
1248-
<h3>
1249-
Over Collection of Data
1250-
</h3>
1251-
<p class="issue" title="Work in progress">
1252-
Explain how the API could be used to request more data than necessary
1253-
for a transaction and how the ecosystem can mitigate that over
1254-
collection.
1253+
<ul>
1254+
<li>Intentional abuse of the API to learn sensitive information about
1255+
the user for the purpose of fraud, tracking, or sale of the data. For
1256+
example, a site could trick a user into sharing their passport
1257+
information through misleading content. This can lead to identity
1258+
theft and financial loss, and severe loss of control and/or leakage
1259+
of personal information.
1260+
</li>
1261+
<li>Unnecessary requests for credentials without the explicit intent
1262+
of user harm, such as an online store requesting users to sign up
1263+
with their driver's license instead of generic email & passkey or
1264+
federated credentials. This can lead to <a data-cite=
1265+
"identity-web-impact#opportunities-and-threats">exclusion</a> of
1266+
users without the ability or willingness to share such a credential
1267+
with the site, a deterioration of the prompt experience on the web,
1268+
and an increase in the risk of accidental data leakage.
1269+
</li>
1270+
<li>Requests for an excessive amount of information for valid
1271+
purposes against the principle of data minimization. A common example
1272+
is collection of a user's entire national identity document for age
1273+
verification instead of relying on selective disclosure and age
1274+
predicates.
1275+
</li>
1276+
</ul>
1277+
<p>
1278+
One challenge here is determining what constitutes "valid" purposes
1279+
and which requests are therefore "unnecessary", and requires
1280+
participation from all parties involved in the credential exchange.
1281+
</p>
1282+
<ul>
1283+
<li>Ideally, verifiers would self-regulate their requests for
1284+
credentials. However, from a user agent's perspective, verifiers are
1285+
potential attackers, and might not consider the user's best interest
1286+
in their designs. The Digital Credentials API needs to operate from
1287+
an assumption that all verifiers might have incentives that motivate
1288+
unnecessary requests and abuse, and protect users accordingly.
1289+
</li>
1290+
<li>User agents are responsible for protecting their users against
1291+
dangerous content and permission requests on the Web and could
1292+
intervene on their behalf, proactively rejecting requests or
1293+
requiring pre-authorization. To support this, the Digital Credentials
1294+
API requires credential requests to not be encrypted.
1295+
</li>
1296+
<li>Issuers and lawmakers might decide to restrict use of
1297+
(particularly government-issued) credentials to specific verifiers
1298+
with purpose attestations. Wallets might be expected to enforce these
1299+
restrictions by law or policy.
1300+
</li>
1301+
<li>The ultimate decision of whether or not to share their personal
1302+
information lies with the user, which is why the API requires the
1303+
user agent to present a credential picker to the user, and other
1304+
parties might additionally require confirmation or consent.
1305+
</li>
1306+
</ul>
1307+
<p>
1308+
For a more detailed exploration of how to determine and address
1309+
unnecessary usage, it makes sense to consider goverment-issued
1310+
credentials and other credentials separately, as they potentially
1311+
differ in the sensitivity of their data and the potential harms from
1312+
misuse as well as legal & regulatory considerations.
1313+
</p>
1314+
<p>
1315+
A key component of risk mitigation and ensuring user control that
1316+
applies to both types of credentials is the user agent's ability to
1317+
inspect the credential request metadata and make decisions or UI
1318+
presentation based on it. The DC API ensures this user agent access
1319+
to the exchange through requirements placed on protocols to transmit
1320+
requests unencrypted and to include relevant information.
1321+
</p>
1322+
<h4>
1323+
Government-issued credentials
1324+
</h4>
1325+
<p>
1326+
<a data-cite=
1327+
"identity-web-impact#pure-digital-credentials">Government-issued
1328+
digital credentials</a> include travel documents, personal licenses,
1329+
proof of welfare and public health programs, vehicle registrations,
1330+
and other documents issued by government authorities, or other
1331+
documents representing this information. These documents are highly
1332+
sensitive, as they can contain permanent, irrevocable, unique
1333+
identifiers that are central to a person's individual identity and
1334+
ability to interact with vital public services.
1335+
</p>
1336+
<h5>
1337+
Risk of theft and leakage of government credentials
1338+
</h5>
1339+
<p>
1340+
The high value of these credentials to users and attackers means
1341+
there is a significant risk of theft, and significant potential harm
1342+
from leakage to unauthorized third parties. This includes the request
1343+
of government identity for the purpose of tracking and
1344+
personalization.
1345+
</p>
1346+
<h5>
1347+
Risk of proliferation of requests for government credentials
1348+
</h5>
1349+
<p>
1350+
A major concern with increased availability of government credentials
1351+
online is <a href=
1352+
"https://en.wikipedia.org/wiki/Jevons_paradox">Jevon's Paradox</a>,
1353+
i.e., the chance of increasing demand for credentials through lower
1354+
friction of access. This effect is not inherently caused by the
1355+
Digital Credentials API, and rather the overall increasing adoption
1356+
of digital credentials across the ecosystem, which, however, would
1357+
likely see additional momentum from user agent implementation of the
1358+
Digital Credentials API. As such, the effect needs to be considered
1359+
by user agents implementing the API, as it might result in harmful
1360+
outcomes for users:
1361+
</p>
1362+
<ul>
1363+
<li>Increased risk of information leakage, and ultimately a less
1364+
trusted user experience on the Web. When a large number of services
1365+
access and store government-issued credentials in an insecure manner
1366+
(i.e. not maintaining encryption or failing to safeguard private
1367+
keys), the chance of data leaks and unauthorized access increases as
1368+
well. Even seemingly non-identifying information like birthdates and
1369+
postal codes, when combined, can statistically identify an
1370+
individual.
1371+
</li>
1372+
<li>Prompt fatigue and a loss in trust by users when they are
1373+
prompted by a large number of websites to share personal information.
1374+
</li>
1375+
<li>Increased potential for <a data-cite=
1376+
"rfc6973#section-5.1.1">surveillance</a> and restrictions on
1377+
pseudonymous use of online services. Collusion between verifiers and
1378+
issuers, or other parties, might result in the ability to closely
1379+
monitor a user's activity on the Web and take adverse action against
1380+
this individual. Even when no action is taken, the possibility of
1381+
surveillance alone can cause anxiety, discomfort, and behavioral
1382+
changes such as inhibition and self-censorship, impacting individual
1383+
autonomy and freedom of expression.
1384+
</li>
1385+
<li>
1386+
<a data-cite=
1387+
"credential-considerations#restrictions-of-free-expression">Exclusion
1388+
and discrimination</a> of individuals who cannot, or do not want
1389+
to, provide these credentials, prohibiting them from participation
1390+
in services that would previously not require government-issued
1391+
credentials, such as forums and social media platforms on the Web.
1392+
</li>
1393+
</ul>
1394+
<h5>
1395+
Mitigating unnecessary requests for government credentials
1396+
</h5>
1397+
<p>
1398+
The outlined risks of government-issued digital credentials present a
1399+
challenge that cannot be solved by a single participant in the
1400+
ecosystem, and will require a broader policy discussion within
1401+
individual soverign nations about the risks and benefits of accessing
1402+
online services through real-world credentials.
1403+
</p>
1404+
<p>
1405+
It is desirable that a government that issues digital credentials
1406+
also enact laws and regulations that clearly define how and for what
1407+
purposes those credentials are able to be used. All parties involved
1408+
in the exchange, whether they are legally obliged to do so or not,
1409+
are advised to support any government verifier authentication
1410+
schemes, if they exist. The support for (and integration of) verifier
1411+
authentication schemes such as <a href=
1412+
"https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/blob/main/docs/annexes/annex-2/annex-2-high-level-requirements.md#a2327-topic-27---registration-of-pid-providers-providers-of-qeaas-pub-eaas-and-non-qualified-eaas-and-relying-parties">
1413+
EUDI access and registration certificates</a> can mitigate risks of
1414+
proliferation of unnecessary credential requests. However, the
1415+
presence of such schemes is not guaranteed, which significantly
1416+
increases the risk in a credential exchange.
1417+
</p>
1418+
<p>
1419+
There are other practical steps that user agents implementing the
1420+
Digital Credentials API can take to reduce risk, increase user
1421+
understanding, and prevent certain types of harm:
1422+
</p>
1423+
<ul>
1424+
<li>Only support protocols that support selective disclosure and
1425+
other techniques of data minimization can reduce the impact and
1426+
likelihood of information leakage, and provide better context to
1427+
users in permission and consent flows.
1428+
</li>
1429+
<li>Support for protocols that allow unlinkability mechanisms such as
1430+
Zero-Knowledge Proofs can prevent verifier-based surveillance and
1431+
potential discrimination, by hiding the issuer.
1432+
</li>
1433+
<li>Offering useful context and a clearly understandable permission
1434+
flow will help users make better decisions on whether or not to
1435+
accept a credential exchange, which can reduce the viability of
1436+
exchange requests that are made without a concrete user need.
1437+
</li>
1438+
</ul>
1439+
<p>
1440+
It is further critical that user agents design a permission
1441+
experience that accounts for the lack of these mitigations, e.g., the
1442+
exchange of personal information from government credentials without
1443+
any verifier authentication scheme. It is recommended that a higher
1444+
level of friction and clear user messaging that highlights the
1445+
involved risk be applied to these types of exchanges.
1446+
</p>
1447+
<h4>
1448+
Non-government-issued credentials
1449+
</h4>
1450+
<p>
1451+
Non-government-issued credentials include all other digital
1452+
documents, certificates, and attestations that are not
1453+
government-issued and don't represent government-issued documents.
1454+
This could include proof of employment, (non-government) education
1455+
credentials, or cinema tickets. Notably, their exchange is likely
1456+
less restricted by laws and regulations. While these documents often
1457+
don't exhibit the same risks as government-issued credentials, they
1458+
could also contain identifiable or sensitive information.
1459+
</p>
1460+
<h5>
1461+
Risk of theft and leakage of non-government credentials
1462+
</h5>
1463+
<p>
1464+
The impact and viability of credential theft and leakage of
1465+
non-government credentials is largely based on the content of each
1466+
individual credential type. In general, it could lead to loss of
1467+
control and exposure of sensitive private information, as well as
1468+
impersonation and data theft, which can increase the likelihood of
1469+
further attacks on the affected individual.
1470+
</p>
1471+
<h5>
1472+
Risk of proliferation of requests for government credentials
1473+
</h5>
1474+
<p>
1475+
The flexibility and lack of regulation of non-government credentials
1476+
carries potential for abuse for the purpose of cross-site tracking
1477+
and linking identities through long-lived identifiers, such as email
1478+
address or phone number. Verifiers participating in a tracking scheme
1479+
based on digital credentials could create user incentives to accept
1480+
sharing identifier credentials across many sites ("loyalty cards" for
1481+
the Web), without fully understanding the implications on their
1482+
privacy.
1483+
</p>
1484+
<p>
1485+
Even users unwilling to share their information in such a scheme
1486+
could be affected by prompt fatigue and potentially risk exclusion
1487+
from using these services.
1488+
</p>
1489+
<h5>
1490+
Mitigating unnecessary requests for non-government credentials
1491+
</h5>
1492+
<p>
1493+
For non-government-issued credentials, it is recommended that the
1494+
user agent understand the requested credential format and its privacy
1495+
attributes, and build a risk framework that informs the context that
1496+
is shown to the user, as well as the amount of friction that is
1497+
appropriate for each credential type. Protocols and formats involved
1498+
in the exchange of these credentials are generally expected to
1499+
support features such as selective disclosure and unlinkability, but
1500+
these features might not always be appropriate or necessary in the
1501+
exchange of information, especially when it concerns low-risk
1502+
credentials such as cinema tickets.
1503+
</p>
1504+
<p>
1505+
A user agent that recognizes the type of credential being requested
1506+
is encouraged to customize its permission experience to best suit the
1507+
requested credential and help users understand the consequences of
1508+
sharing it.
1509+
</p>
1510+
<p>
1511+
User agents can not be expected to understand all credential
1512+
requests. A user agent that does not recognize the type of credential
1513+
being requested is advised to significantly increase user friction in
1514+
their permission experience, and very clearly communicate the risks
1515+
of sharing unknown credentials with websites to the user. Note that
1516+
this could require integration between <a href=
1517+
"#multiple-user-agents">different user agents</a> to apply
1518+
appropriate levels of friction and transparency. For example, a
1519+
browser might delegate knowledge about credential requests to the
1520+
operating system, which might require wallets to register known
1521+
credential types and reject an exchange request for an unknown
1522+
credential type.
1523+
</p>
1524+
<p class="issue" data-number="100">
1525+
The need to provide users with appropriate transparency conflicts
1526+
with the desire to enable the ecosystem to develop new credential
1527+
formats without explicit user agent buy-in.
1528+
</p>
1529+
<p class="issue" data-number="117">
1530+
Is it a good idea for the group to maintain a registry of request
1531+
types and/or <a href=
1532+
"https://github.com/w3c-fedid/digital-credentials/issues/85">credential
1533+
types</a>?
1534+
</p>
1535+
<h5>
1536+
Reporting abuse
1537+
</h5>
1538+
<p class="issue" data-number="267">
1539+
Consider an interoperable abuse reporting system for verifiers making
1540+
unnecessary and abusive requests.
12551541
</p>
12561542
</section>
12571543
<section>

0 commit comments

Comments
 (0)