...
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.
| 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
...