Status: DRAFT
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 adipiscing elit. Aliquam fermentum vestibulum est. Cras rhoncus. Pellentesque habitant morbi tristique senectus et netus et malesuada fames ac turpis egestas. Sed quis tortor. Donec non ipsum. Mauris condimentum, odio nec porta tristique, ante neque malesuada massa, in dignissim eros velit at tellus. Donec et risus in ligula eleifend consectetur. Donec volutpat eleifend augue. Integer gravida sodales leo. Nunc vehicula neque ac erat. Vivamus non nisl. Fusce ac magna. Suspendisse euismod libero eget mauris.
Ut ligula. Maecenas consequat. Aliquam placerat. Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Nulla convallis. Ut quis tortor. Vestibulum a lectus at diam fermentum vehicula. Mauris sed turpis a nisl ultricies facilisis. Fusce ornare, mi vitae hendrerit eleifend, augue erat cursus nunc, a aliquam elit leo sed est. Donec eget sapien sit amet eros vehicula mollis. In sollicitudin libero in felis. Phasellus metus sem, pulvinar in, porta nec, faucibus in, ipsum. Nam a tellus. Aliquam erat volutpat.
Sed id velit ut orci feugiat tempus. Pellentesque accumsan augue at libero elementum vestibulum. Maecenas sit amet metus. Etiam molestie massa sed erat. Aenean tincidunt. Mauris id eros. Quisque eu ante. Fusce eu dolor. Aenean ultricies ante ut diam. Donec iaculis, pede eu aliquet lobortis, wisi est dignissim diam, ut fringilla eros magna a mi. Nulla vel lorem. Donec placerat, lectus quis molestie hendrerit, ante tortor pharetra risus, ac rutrum arcu odio eu tortor. In dapibus lacus nec ligula. Aenean vel metus. Nunc mattis lorem posuere felis. In vehicula tempus lacus. Phasellus arcu. Nam ut arcu. Duis eget elit id eros adipiscing dignissim.
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