|
74 | 74 | href: "https://docs.google.com/document/d/1Ppaz_EnhzHqPOz5UusRJvbSunh-RXPWgJ3Np_TM2EE0/",
|
75 | 75 | authors: ["Simone Onofri"]
|
76 | 76 | },
|
| 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 | + }, |
77 | 84 | },
|
78 | 85 | xref: {
|
79 | 86 | profile: "web-platform",
|
@@ -1128,10 +1135,11 @@ <h5>
|
1128 | 1135 | </p>
|
1129 | 1136 | <p>
|
1130 | 1137 | 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. |
1135 | 1143 | </p>
|
1136 | 1144 | <p class="issue" data-number="279">
|
1137 | 1145 | Which level of unlinkability is the goal for this API? Can we
|
@@ -1237,21 +1245,299 @@ <h5>
|
1237 | 1245 | <h3>
|
1238 | 1246 | Unnecessary Requests for Credentials
|
1239 | 1247 | </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: |
1245 | 1252 | </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. |
1255 | 1541 | </p>
|
1256 | 1542 | </section>
|
1257 | 1543 | <section>
|
|
0 commit comments