{"action":"created","issue":{"url":"https://api.github.com/repos/w3c/vc-data-model/issues/298","repository_url":"https://api.github.com/repos/w3c/vc-data-model","labels_url":"https://api.github.com/repos/w3c/vc-data-model/issues/298/labels{/name}","comments_url":"https://api.github.com/repos/w3c/vc-data-model/issues/298/comments","events_url":"https://api.github.com/repos/w3c/vc-data-model/issues/298/events","html_url":"https://github.com/w3c/vc-data-model/pull/298","id":385142037,"node_id":"MDExOlB1bGxSZXF1ZXN0MjM0MTc4NTE5","number":298,"title":"Replaced language about requirements for \"accepting\" a verifiable credential","user":{"login":"jandrieu","id":186831,"node_id":"MDQ6VXNlcjE4NjgzMQ==","avatar_url":"https://avatars3.githubusercontent.com/u/186831?v=4","gravatar_id":"","url":"https://api.github.com/users/jandrieu","html_url":"https://github.com/jandrieu","followers_url":"https://api.github.com/users/jandrieu/followers","following_url":"https://api.github.com/users/jandrieu/following{/other_user}","gists_url":"https://api.github.com/users/jandrieu/gists{/gist_id}","starred_url":"https://api.github.com/users/jandrieu/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jandrieu/subscriptions","organizations_url":"https://api.github.com/users/jandrieu/orgs","repos_url":"https://api.github.com/users/jandrieu/repos","events_url":"https://api.github.com/users/jandrieu/events{/privacy}","received_events_url":"https://api.github.com/users/jandrieu/received_events","type":"User","site_admin":false},"labels":[{"id":490241843,"node_id":"MDU6TGFiZWw0OTAyNDE4NDM=","url":"https://api.github.com/repos/w3c/vc-data-model/labels/CR-blocker","name":"CR-blocker","color":"b60205","default":false}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":2,"created_at":"2018-11-28T07:50:41Z","updated_at":"2018-12-04T20:22:22Z","closed_at":null,"author_association":"CONTRIBUTOR","pull_request":{"url":"https://api.github.com/repos/w3c/vc-data-model/pulls/298","html_url":"https://github.com/w3c/vc-data-model/pull/298","diff_url":"https://github.com/w3c/vc-data-model/pull/298.diff","patch_url":"https://github.com/w3c/vc-data-model/pull/298.patch"},"body":"This addresses issue #293.\n\nI attempted to retain the clarifications about the goals of ToUs and the recipient's liability should they choose to ignore those terms. However in mentioning that liability, I pointed out the legal limits of assuming how and to whom such liability accrues. Perhaps we should excise that completely, but it was the best way I could find to describe the possible means of enforcement of a ToU, given there is no technical enforcement supported by VCs.\n\nTo wit, the previous language asserted the verifier would be responsible if a holder violated the terms of use under which a credential is issued. However, the verifier receives the information covered by the ToU **before** they are able to review, much less agree to, the asserted terms. (There is no protocol to enforce that VCs are only given to those who have agreed to such ToUs). In such a case, I don't believe the ToU will be found legally binding on the verifier. I did add a note about seeking reliable counsel, but maybe the whole section should just be removed.\n\nI also attempted to couch the language about \"accepting\" in the subject != holder discussions such that the original intention remains. The actual examples do not, IMO, address the use cases, but they work as illustrations that \"may\" be appropriate for some use cases.  I initially started rewriting these to address my concerns, but that quickly got way too complicated to do properly in the timeframe we have.\n\nFWIW, I'd start with having the original holder create a new credential with claims that explicitly say the new holder has been given the original credential for a specific purpose rather than including the original claims and implying the delegation without formally stating it. This gets into territory where VCs are decidedly challenging around the edge cases. In general, I am not a fan of quirky, non-explicit semantics of these use cases. If the thing is delegated, say it in claims rather than overload the semantics of the credentials themselves, which is simply that the issuer made an utterance. \n\nSimilarly, I tried to shift the parent/child examples to be clear that the assertions of relationship are information for consideration when deciding whether or not to rely on a VC. I believe this retains the intention without implying that all verifiers MUST accept the DMV's assertion of a relationship as a means of appropriate delegation for their particular use. I think it also avoids the ambiguity between \"verify\" and \"accept\". Whether or not the DMV's assertion is suitable for the delegation is subject to the business rules of the verifier. For some cases, parentage doesn't imply any rights to delegation. For instance, money stored in a trust is often completely out of reach of the parent, even if the DMV is accepted as authoritative for the relationship asserted. As such, it's inappropriate to assert that a given arrangement of multiple credentials MUST be accepted by any given verifier for any given use.\n\nI, for one, would not view the DMV as an authoritative source for a parenting relationship (nor for weight, height, or even current address). I attempted to frame these from the perspective that verifiers reliance on any VC needs to take into account several factors beyond verification, which is what I believe @David-Chadwick's means by \"accept\".\n\nAnyway, I hope this fits the bill. I made a sincere effort to meet the use cases @David-Chadwick wants addressed while fixing my concerns about untestable conformance and dependence on solving demonstrably unsolved, out-of-scope problems.\n\nComments and suggestions welcome.\n\n\n<!--\n    This comment and the below content is programatically generated.\n    You may add a comma-separated list of anchors you'd like a\n    direct link to below (e.g. #idl-serializers, #idl-sequence):\n\n    Don't remove this comment or modify anything below this line.\n    If you don't want a preview generated for this pull request,\n    just replace the whole of this comment's content by \"no preview\"\n    and remove what's below.\n-->\n***\n<a href=\"https://pr-preview.s3.amazonaws.com/jandrieu/vc-data-model/pull/298.html\" title=\"Last updated on Dec 3, 2018, 10:53 AM GMT (2075789)\">Preview</a> | <a href=\"https://pr-preview.s3.amazonaws.com/w3c/vc-data-model/298/8b58476...jandrieu:2075789.html\" title=\"Last updated on Dec 3, 2018, 10:53 AM GMT (2075789)\">Diff</a>"},"comment":{"url":"https://api.github.com/repos/w3c/vc-data-model/issues/comments/444244264","html_url":"https://github.com/w3c/vc-data-model/pull/298#issuecomment-444244264","issue_url":"https://api.github.com/repos/w3c/vc-data-model/issues/298","id":444244264,"node_id":"MDEyOklzc3VlQ29tbWVudDQ0NDI0NDI2NA==","user":{"login":"msporny","id":108611,"node_id":"MDQ6VXNlcjEwODYxMQ==","avatar_url":"https://avatars3.githubusercontent.com/u/108611?v=4","gravatar_id":"","url":"https://api.github.com/users/msporny","html_url":"https://github.com/msporny","followers_url":"https://api.github.com/users/msporny/followers","following_url":"https://api.github.com/users/msporny/following{/other_user}","gists_url":"https://api.github.com/users/msporny/gists{/gist_id}","starred_url":"https://api.github.com/users/msporny/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/msporny/subscriptions","organizations_url":"https://api.github.com/users/msporny/orgs","repos_url":"https://api.github.com/users/msporny/repos","events_url":"https://api.github.com/users/msporny/events{/privacy}","received_events_url":"https://api.github.com/users/msporny/received_events","type":"User","site_admin":false},"created_at":"2018-12-04T20:22:22Z","updated_at":"2018-12-04T20:22:22Z","author_association":"MEMBER","body":"@jandrieu, I heard you say that both you and @David-Chadwick agree on this PR, which is great. I also saw a few requests to change text that you didn't respond to from @David-Chadwick ... so, I just want to make sure there is agreement to pull in this PR before I do it. Also, merge conflicts need to be fixed."}}
{"actor":{"display_login":"msporny"}}