As a user,Alice wants to share accredited data with an organization,So that she can streamline administrative processes, while this organization can comply with legally obligated reporting.
Preconditions:
What conditions must be in place or assumed before this use case can begin?
The user has the authorization to access and share the accredited data.
The user is owner of a pod, and thus has CRUD permission on this pod.
There is trusted accreditation (e.g. a verified source or a trusted party signature).
The organization is subject to a legal obligation to prove the accredited data was verified at the time of exchange.
Trigger:
What (user or system) event or action initiates this use case?
The organization making an offer to the user, for which it requests accredited data
The relevant (government) agency auditing or demanding recurring reporting on the agreements the organization has closed.
Actors:
Describe the primary actor, and any other relevant actors involved in this use case
User who holds accredited data about them
Any organization requiring accredited data, which must report on verifying said data
Auditing agency
Distinction:
What unique challenges or distinguishing factors (like technical issues, user experience needs, workflow integration, etc.) are associated with this use case?
Given the rights that a user is expected to have on their pod, any linked data to which access is granted can be altered, deleted (if the user has such rights on the linked to source, or the source is the pod) or access can be revoked. Accordingly, the organization requesting the data has no garuantee of still being able to access the accredited data it would require in an audit from the original access request. To prevent such an organization of resorting to making a copy a solution is required for these situations. There is a need for some form of immutability or non-repudiation, that respect the user's permissions.
Scenario:
Describe an ideal or happy-case scenario where this use case would play out as intended.
Alice gets contacted by a recruitment agency (= the organization) with a job offer that requires her to confirm she has a medical degree. She grants access to a VC of her degree, accredited by the educational institution that awared her the degree, with the recruitment agency. The agency can draw up a contract based on this access. The agency reports the contract to the relevant authorities and receives clearance on the contract. Alice can start the job. At a later point in time, the agency is audited. They can still provide the VC (or if sufficient, the access to it) to pass the audit since the access has not been revoked. The recruitment agency is just one example of many cases in which legal obligations in reporting exist, so in no means is this specific example organization crucial to the use case. It must be noted regional law has a significant impact on the specifics of the obligations to report.
Alternative case(s):
What alternative flows or variations should the system handle for this use case?
Alice wants to revoke access, for any reason, to prevent this data to be used for other purposes than the audit.
Alice wants to revoke access, for any reason, to prevent this data to be used for any purpose, including the audit.
Error scenario:
What unexpected issues or errors might arise, and how should the system handle them?
Access is revoked, meaning the audit is not passed. Both Alice and the recruitment agency might face repercussion (e.g. get issued a fine). The system should have a fall-back mechanism in case access is revoked in any way.
Some fall-back mechanisms (in order of priority) that might improve this case, with limitation perhaps, are the following:
Time-based access grants that would allow access within a given timeframe (logically that of the legal obligation). This requires a high level of trust from the user that the access is only exercised by the recruitment agency, at the demand of the auditing agency. Strict policies, or even contractual agreements might be required to make this solution completely sound.
External party managing access grants would allow the user (and the organization alike) to automate this problem. Such external parties could contextualize the access granted in terms of the agreements made for both Alice and recruitment agency (in this case: contract to perform job comes with reporting obligation). This would again require a high level of trust from both Alice and the agency that such external parties do not act maliciously. A trade-off between user-friendliness and trust seems inevitable. The average user cannot be expected to evaluate every external party with great care (or be knowledgeable to do so). User experience is key here, as control is (partly) given away to the external party in return for a more user-friendly experience to exchange data.
In case Alice or the recruitment agency do not hold up their end of the bargain, a technical solution to act on this violation of agreements is needed. This in support of contractual agreements, so that automation is possible.
Acceptance Criteria:
What conditions or criteria must be met for this use case to be considered successfully handled? What limitations are acceptable?
Access grants (and consequently, access requests) should have the possibility to include a guaranteed timeframe for which access is granted. An acceptable limitation is that the purpose for which the grant is issued, is not enforced technically. This given that every access that is exercised could easily be logged, and matched with whether an audit was being performed at that time. At the same time, such usage policies are (a multitude) of issues in itself.
Two potentially interesting pieces of prior art here would be:
ISO 27560 (not an open standard, I've never paid for it so only know second-hand)
the Decentralized Identity Foundation's Claims and Credentials (i.e. applied Verifiable Credential tooling) working group had a taskforce/work item by two ESSIF-LAB grantees (Gataca & iGrant.io) that did some work specifying and prototyping some legal-reporting/purpose-audit user stories here
Jan Lindquist from iGrant was very familiar with the ISO spec (and I believe co-author or editor of it?)
As a user, Alice wants to share accredited data with an organization, So that she can streamline administrative processes, while this organization can comply with legally obligated reporting.
Preconditions:
What conditions must be in place or assumed before this use case can begin?
Trigger:
What (user or system) event or action initiates this use case? The organization making an offer to the user, for which it requests accredited data The relevant (government) agency auditing or demanding recurring reporting on the agreements the organization has closed.
Actors:
Describe the primary actor, and any other relevant actors involved in this use case
Distinction:
What unique challenges or distinguishing factors (like technical issues, user experience needs, workflow integration, etc.) are associated with this use case? Given the rights that a user is expected to have on their pod, any linked data to which access is granted can be altered, deleted (if the user has such rights on the linked to source, or the source is the pod) or access can be revoked. Accordingly, the organization requesting the data has no garuantee of still being able to access the accredited data it would require in an audit from the original access request. To prevent such an organization of resorting to making a copy a solution is required for these situations. There is a need for some form of immutability or non-repudiation, that respect the user's permissions.
Scenario:
Describe an ideal or happy-case scenario where this use case would play out as intended. Alice gets contacted by a recruitment agency (= the organization) with a job offer that requires her to confirm she has a medical degree. She grants access to a VC of her degree, accredited by the educational institution that awared her the degree, with the recruitment agency. The agency can draw up a contract based on this access. The agency reports the contract to the relevant authorities and receives clearance on the contract. Alice can start the job. At a later point in time, the agency is audited. They can still provide the VC (or if sufficient, the access to it) to pass the audit since the access has not been revoked. The recruitment agency is just one example of many cases in which legal obligations in reporting exist, so in no means is this specific example organization crucial to the use case. It must be noted regional law has a significant impact on the specifics of the obligations to report.
Alternative case(s):
What alternative flows or variations should the system handle for this use case? Alice wants to revoke access, for any reason, to prevent this data to be used for other purposes than the audit. Alice wants to revoke access, for any reason, to prevent this data to be used for any purpose, including the audit.
Error scenario:
What unexpected issues or errors might arise, and how should the system handle them? Access is revoked, meaning the audit is not passed. Both Alice and the recruitment agency might face repercussion (e.g. get issued a fine). The system should have a fall-back mechanism in case access is revoked in any way.
Some fall-back mechanisms (in order of priority) that might improve this case, with limitation perhaps, are the following:
Acceptance Criteria:
What conditions or criteria must be met for this use case to be considered successfully handled? What limitations are acceptable? Access grants (and consequently, access requests) should have the possibility to include a guaranteed timeframe for which access is granted. An acceptable limitation is that the purpose for which the grant is issued, is not enforced technically. This given that every access that is exercised could easily be logged, and matched with whether an audit was being performed at that time. At the same time, such usage policies are (a multitude) of issues in itself.