-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
metadata master reference policies #65
Comments
@joshcornejo: please add specific proposal for changes in the current "formal semantics spec" or specific examples for the "best practices" (in the form: "at the end of section X, add this paragraph, this figure and this Turtle spec"). |
This is most likely something for version 3.0: The use case: "The EU wants to attach policies to persons' verifiable credentials. For example, to make sure companies keep citizen's information within GDPR compliance requirements. Generating millions of offers in advance is impractical, and there is no way to materialise offers and trace them to a single origin offer for multiple different assigners." As such, the policy is not created nor managed by the assigner; they are managed by an entity (the EU), and Agreements are only generated at the point in time when the three elements coincide in a governed situation "The insurer requesting a person's verifiable credential for a quote" (the assignee party: person, the asset: verifiable credential, the assigner: an insurer). As per the diagram above, the proposed expansion (odrlex?) could look like this:
Once someone needs an agreement, these templates materialise into an
|
At scale (e.g. verifiable credentials over the European market for GDPR compliance), it is impractical to generate individual policies for millions of people as associated odrl:Set or odrl:Offer
Ideally (continuing the example) a VC asset class shape (not an instance!) would have a reference to a policy, this policy would dictate the types of shapes allowed (in the image - always an assignee is a Party / assigner a PartyCollection).
In the use case "Bob wants an insurance Policy", the agreement for GDPR will materialise (as Bob's VC will be of the "VC asset class shape") and the right relationships can be assigned at that point.
The elements in blue represent this new "reference", the rules don't hold assigners/assignees (or any other function) nor actual assets are related to a policy (it is classes-to-classes until the instantiation).
The text was updated successfully, but these errors were encountered: