Skip to content
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

Add section about terms of use #48

Closed
jandrieu opened this issue May 30, 2017 · 7 comments
Closed

Add section about terms of use #48

jandrieu opened this issue May 30, 2017 · 7 comments
Labels
privacy-tracker Group bringing to attention of Privacy, or tracked by the Privacy Group but not needing response.

Comments

@jandrieu
Copy link
Contributor

Currently we don't have a section on how the data model supports various terms-of-use scenarios.

There have been discussions about expiry, revocation, and scope of use, but none have matured enough to have made it into the data model.

In particular, we need some distinction between terms of use for a given claim or credential, as set by the issuer, and the terms of use of a given presentation, as set by the controller of the claim.

Without the right hooks in the data model for this, we're propagating legacy problems related to data binding, the right to erasure, and other privacy issues.

FWIW, the UMA work on scope may be of use. https://docs.kantarainitiative.org/uma/rec-uma-core.html

@jandrieu
Copy link
Contributor Author

Another use case for issuer's TOS, from the mailing list:

Claimants present claims. That's simple. Authentication, delegation, and proving right to use, are external to the claim.

There is one exception that I can see, where an issuer includes a TOS clause that explicitly affords the right to be a claimant to a specific entity--which may or may not be the subject. In fact, I think that's a fairly useful TOS: this claim only applicable when presented by the subject as authenticated by procedure X.

@David-Chadwick
Copy link
Contributor

I see two different 'terms of use'. The first is the policy of the issuer. This states the restrictions on the use of the VC by the subject, and the inspector should honour this policy. If the inspector disregards this policy then the issuer will take no responsibility for this i.e. the risk from use of the VC is entirely upon the inspector.
The second 'terms of use' is that of the holder when he/she presents the VC to the inspector. An example might be 'I want you to use my address in the VC in order to post me the item that I have just purchased but not to subsequently send me any marketing literature or other junk mail'.
This latter terms of use probably does not need to be in the VC, and could be in the protocol between the holder and the inspector

@riannella
Copy link

Hi all, have you looked at:
ODRL Information Model https://www.w3.org/TR/odrl-model/
ODRL Vocabulary & Expression https://www.w3.org/TR/odrl-vocab/
(now entering CR)

The POE WG (listed on your Charter under Liaisons) would be happy to chat more and look into the use case(s) ;-)

@msporny
Copy link
Member

msporny commented Oct 25, 2017

@riannella Would you be able to join the VCWG to give a background on POE and ODRL and how we may be able to use it to express things like "consent", "terms of use", and "policy" for Verifiable Credentials?

@riannella
Copy link

Yes, that would be fine. What times is the VCWG call? (I am in Brisbane, AU) #41

@David-Chadwick
Copy link
Contributor

I think this issue can be closed now since we have a terms of use section in the latest VC Data Model document

@msporny
Copy link
Member

msporny commented Feb 19, 2018

Closing, per @David-Chadwick's observation. We will continue to discuss exactly how to express terms of use using ODRL in another issue.

@msporny msporny closed this as completed Feb 19, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
privacy-tracker Group bringing to attention of Privacy, or tracked by the Privacy Group but not needing response.
Projects
None yet
Development

No branches or pull requests

4 participants