Status:
| Status | ||||||
|---|---|---|---|---|---|---|
|
Information for organizations that verify mobile credentials, and by inference organizations that provide software or services to issuers to enable the verifier to verify mobile credentials.
Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
...
- The relying party should only request the data that is required for the transaction.
- The user must have an assurance that they are releasing their data to the intended relying party behind the identity reader. Essentially, the terminal should be under the relying party's control
- The value of the intent to retain flag must match the use of the data received and should be consistent with their identity privacy policy.
- The relying party must maintain an identity specific data use policy that clearly indicates what dat is being requested, and why it's being requested. This identity data use policy should include 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.
- If the relying party can satisfy the use case transaction requirements via the device retrieval method outlined in ISO18013-5, the relying party should use the device retrieval method in order to request the data that is required for the transaction.
Additional information from Annex E in 18013-5.
- Consent and Choice – The Data Subject must consent to the processing of their personal data (see definitions in the section on mDL Holder Consent below).
• Purpose Specification – the Data Subject should be fully aware of the purpose for which their personal data is being collected, processed, and potentially stored.
• Collection Limitation – The Data Controller and Data Processors should only collect the data necessary for their purpose and should only collect data consistent with these principles.
• Data Minimization – Processing of data should be minimized to that specifically necessary for the purpose specified.
• Use, Retention, and Disclosure Limitation – Data Processors should not use personal data of the Data Subject except for the purposes specified and consistent with these other principles. Personal Data should only be retained for the period necessary to provide the service.
• Data Accuracy and Quality – High accuracy of data being processed and held is in the best interest of the Data Subject and processors should take measures to ensure accuracy.
• Openness and Transparency – What data and how data is being processed should be well-known to the Data Subject, including obtaining consent, and posting and updating clear notices.
• Individual Participation – the Data Subject should be involved in the collection, consent, processing, and storage management of their personal data.
• Information Security (of Data and Data Subject) - Personal data should be protected by security safeguards against such risks as loss or unauthorized access, destruction, use, modification or disclosure
• Privacy Compliance, Accountability and Auditing – The Data Controller and Data Processors must be accountable for all aspects of the processing of Personal Data and provide audit logs and auditability to the Data Subject.
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