@@ -1016,14 +1016,117 @@ <h3>
1016
1016
</ section >
1017
1017
< section >
1018
1018
< h3 >
1019
- Transmission of Personally Identifiable Information
1019
+ User Permission and Transparency
1020
1020
</ h3 >
1021
- < p class ="issue " title ="Work in progress ">
1022
- Explain that the API does enable the transmission of personally
1023
- identifiable information and that it does its best to ensure there is
1024
- informed consent by the individual, but that the consent might be
1025
- provided due to exhaustion or not understanding what PII is being
1026
- transmitted and how to mitigate those concerns.
1021
+ < p class ="issue " title ="Work in progress "> </ p >
1022
+ < p >
1023
+ The Digital Credentials API enables the sharing of highly personal,
1024
+ sensitive, and at-risk user information with websites via credentials,
1025
+ potentially granting the ability to track users online and offline,
1026
+ through permanent, unique, irrevocable, cross-context identifiers. It
1027
+ also reveals parts of the user's browsing activity as well as their
1028
+ intent to identify to specific websites and/or wallets. One crucial
1029
+ responsibility of the user agent in a credential request is to gather
1030
+ permission from the user to proceed with the exchange of information.
1031
+ </ p >
1032
+ < p >
1033
+ Important context details that are needed for a user to make an informed
1034
+ decision about proceeding with a credential exchange include the following:
1035
+ </ p >
1036
+ < ul >
1037
+ < li > The origin of the verifier that requests the credential.
1038
+ </ li >
1039
+ < li > The information that is being requested, or that would be
1040
+ revealed by responding to the request.
1041
+ </ li >
1042
+ < li > Whether presenting this information will enable tracking.
1043
+ </ li >
1044
+ < li > Which wallet(s) can be used to fulfill the credential request.
1045
+ </ li >
1046
+ < li > Which credential would be used to share the requested
1047
+ information.
1048
+ </ li >
1049
+ </ ul >
1050
+ < p >
1051
+ It is advised that user agents in their implementation ensure that
1052
+ the details listed are fully disclosed to the user before an exchange
1053
+ of any user-related information occurs.
1054
+ </ p >
1055
+ < p class ="issue " data-number ="252 ">
1056
+ Should these be normative in the spec?
1057
+ </ p >
1058
+ < p class ="issue " data-number ="44 ">
1059
+ Should the API be designed so the site can provide in-context
1060
+ explanations?
1061
+ </ p >
1062
+ < h4 >
1063
+ Integrating Multiple User Agents
1064
+ </ h4 >
1065
+ < p >
1066
+ Depending on the technical architecture of a user's system, it is
1067
+ likely that the definition of a "user agent" will include multiple
1068
+ cooperating layers of the software stack, such as a browser and the
1069
+ operating system. The greatest priority for these layers has to be
1070
+ a safe and well-informed user permission experience. As such,
1071
+ integration can be vital for user safety. Some layers may hold
1072
+ information that is inaccessible by other layers, such as the
1073
+ availability of a user's credentials. Overprompting or prompting
1074
+ without sufficient context could lead to (exploitable) confusion
1075
+ and prompt blindness.
1076
+ </ p >
1077
+ < p >
1078
+ For this reason, user agents prompting for permission are encouraged
1079
+ to integrate software layers for an ideal user experience, if they
1080
+ consider it safe to do so. This could happen, for example, if a
1081
+ browser trusts the API contract of an operating system to show an
1082
+ appropriate prompt, and thus does not show a prompt itself.
1083
+ </ p >
1084
+ < h4 >
1085
+ Permission Prior to Wallet Selection
1086
+ </ h4 >
1087
+ < p >
1088
+ As part of the user permission flow, the user agent needs to ensure
1089
+ that users retain the power to choose whether to forward a credential
1090
+ request to a wallet, and which wallet to select. This is due to the
1091
+ information disclosure that happens as part of the request, and the
1092
+ ability of wallets to retain or share this information at the time of
1093
+ the request.
1094
+ </ p >
1095
+ < h4 >
1096
+ Permission vs. Consent
1097
+ </ h4 >
1098
+ < p >
1099
+ The permission mediated by the user agent is not consent, which has
1100
+ specific legal definitions which can vary among different legal and
1101
+ regulatory environments and may need to be collected by the digital
1102
+ wallet before sharing information with the verifier, or by the
1103
+ verifier itself before initiating the request. With frameworks and
1104
+ regulations for obtaining consent still being developed, this API
1105
+ aims to enable the exchange of the necessary information, which
1106
+ could include the following:
1107
+ </ p >
1108
+ < ul >
1109
+ < li > The privacy policy of the verifier receiving the credential.
1110
+ </ li >
1111
+ < li > The purpose for which the verifier is requesting the information.
1112
+ </ li >
1113
+ < li > What the information will be used for.
1114
+ </ li >
1115
+ < li > How the information will be shared or retained.
1116
+ </ li >
1117
+ < li > Any evaluations and attestations of this information, if
1118
+ available.
1119
+ </ li >
1120
+ < li > Assertions of the verifier's legimitacy and registration for
1121
+ accessing the credential, such as < a href =
1122
+ "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 ">
1123
+ EUDI access and registration certificates</ a > .
1124
+ </ li >
1125
+ </ ul >
1126
+ < p >
1127
+ As more of this information becomes available in a structured format,
1128
+ we expect user agents and this specification to leverage it to
1129
+ improve the user permission experience as well.
1027
1130
</ p >
1028
1131
</ section >
1029
1132
</ section >
0 commit comments