Status:
| Status | ||||||
|---|---|---|---|---|---|---|
|
...
- The user must review and authorize the release of any data before it is transmitted to the relying party.
- Only the subset of the mDL data requested by the relying party is shared. If a relying party only needs your date of birth, your address will not be shared even though it is part of your mDL data.
- The user must have an assurance that they are releasing the data to the intended relying party behind the identity reader.
- The relying party must be honest about their intent to retain flag per data element.
- The relying party must maintain an identity specific data use policy that clearly indicates what data is being requested, and why it's being requested.
- If the relying party intends on retaining any specific identity data, the relying party must indicate in the data use policy why it's being requested, why it's being stored and for how long it will be stored.
- The relying party must adhere to the ISO18013-5 mDL standard in order to properly interface with the mobile devices.
| Loremipsum |
|---|
FIC Recommendations: Relying Party Handling of Transaction Data
...
Public key administration
6.1.1
| B.P. | Process in place for relying party to obtain signed Issuer public key so the relying party may check its validity, e.g. AAMVA Digital Trust Service for North American mDLs. |
Relying party technical & procedural readiness
Issuing authorities may not have any direct obligations to drive relying party technical or operational readiness, but they may not enjoy widespread adoption until the relying party ecosystem has implemented acceptance.
6.2.2
| B.P. | Terminal manufacturers providing terminals in the jurisdiction are enabled for acceptance in software, hardware, and APIs. |
6.2.2 | B.P. | Acquirers (where relevant) in the jurisdiction are enabled for acceptance in software and APIs. |
6.2.3 | B.P. | Relying parties in the jurisdiction are enabled for acceptance in their ability to consume data from terminals and integrate it into their terminal software and back end services. |
6.2.4 | B.P. | Issuing Authorities encourage Relying party ecosystem participants to self-regulate, and proactively adopt best practices for data minimization in their acceptance of Digital IDs, for local, national and global use cases. |
6.2.5 | B.P. | Relying parties to encourage Relying Party ecosystem participants to ensure user consent and data is respected within internal systems and operational support capabilities. |
6.2.5 | B.P. | All ecosystem participants are encouraged to engage in discussions on mechanisms to achieve data minimization consistently (e.g. terminal pre-registration with master lists for relying party keys’ best practices for “identity bundles” by use case; and government polices). |
User consent model
There are two types of obligations on relying parties in Digital ID release, one category is regulated obligations where transparency is a best practice for the user to access the service (e.g. regulated financial and health use cases). In this category the only choice the user has is to present their physical ID or their Digital ID, and some information is required from the ID in order to offer the user the service at all. In the non-regulated use cases, the relying party has an obligation in most market to secure user consent before obtaining data, but the relying party has considerable discretion on what to ask for. In the end, the user should never be surprised about what a relying party has done with their data.
...
Further work is required to establish a standard that the ecosystem can lean into in the absence of prescriptive policy (e.g. OpenID Foundation eKYC & IDA WG, which can in turn point to local or global jurisdiction trust frameworks & best practices).
6.3.1 | B.P. | For US issuing authorities, they can refer to the US FTC Fair information Act for reference on obligations & recommendations under current law, and the law covers both regulated and unregulated use cases. For other issuing authorities, you can reference Annex E of the ISO 18013-5.
|
6.3.2 | B.P. | Ecosystem partners should consider generating transactions records or logs with relying parties and storing them on the device. Examples include Kantara consent receipts (e.g. Kantara 1.1 Consent receipt standard) and notice receipts. |
UX
6.4.1 | B.P. | Follow emerging best practices on data minimization. Such best practices are likely to specify minimum data required for different use cases and geographies. |
...
Page Tasks
- Type your task here, using "@" to assign to a user and "//" to select a due date
...