- From: Timothy Holborn <timothy.holborn@gmail.com>
- Date: Mon, 26 Jun 2017 14:45:41 +0000
- To: W3C Credentials Community Group <public-credentials@w3.org>
- Message-ID: <CAM1Sok2rdYkXymEkxGOTc-rzCTDo-U1QhrO8m1nsKgj8TeM-0w@mail.gmail.com>
I've been spending alot of cycles thinking about the terminology, and this in-turn has brought about other queries that requires more time / work than is available. Role A: signatory Role B: recipient Role C: consumer Best outcome for now is that the signatory (role a) is the person who legally controls the cryptography instrument used to sign the document / declaration / statement. The recipient (role b) may not agree or countersign the document to provide a legal contract that would represent agreement (free from issues) for the statements made, which in turn means the document is assigned to them in some way as a recipient. Other services (role c) consume these documents as dependents of the authority (role a) who is in turn considered to be the controller of the claim due to the use of the signature ("signatory") making them a signatory, wherein they are responsible for the statements made (including whether their true, false, cause injury / harm, may be misleading or mid represent the full circumstances of a situation, et.al.) in that claim, and indeed also the implications of any mandatory requirement for a recipient and/or consumer to rely on the the statements made in that signed document. So. In-turn, explanation. (Let me know if I've missed something technically, re; functional properties of VCs). I felt that to make the terminology work the introduction of the term "signatory" to "role a" helped explain the responsibilities incumbent upon operators of a system. noting that due to the lack of means for support for the recipients needs (ie: being able to have both entities sign the document to show agreement) the legal responsibility for the proper use of these things in-turn falls upon the party who's cryptographic signatures are used, which in this case seems only to be the creator of the claim; and in-turn also, the controller of the web-id / identity instrument / identifier who may or may not have any relationship or means to influence the manner in which their identifiers have been used by others to forge claims (and whether those claims are true and correct or otherwise); indeed also another influencer is the maintainer of the ontological definitions referenced in the cryptographically signed document; that would in turn store some sort of creation date information, which could be used by archive.org or similar to FAQ check should version control of ontology be a problem. Usecase: traffic infringement. Traffic camera identifies a vehicle exceeding the speed limit and issues a claim to the vehicle owner that results in loss of license which is denoted as an identifier linked to a vehicle registration plate. The authority controlling the automation systems employs the use of the system to lower operation / enforcement cost, whilst not developing systems that offer similar levels of automation or means to dispute a claim, making it difficult to process circumstances where someone else was driving the vehicle or other circumstances where the claim was false. The vehicle owner looses their license and the job they had that required them to own a vehicle. They are then required to spend many hours and/or employ legal professionals in addition to attending a court with witnesses to prove they were not driving the vehicle; and this becomes a matter of fact that is no longer disputed. As the claim systems never required the recipient of the claim to have any input as to the validity of the claim andor the systems made it difficult, complex, time-consuming, et.al. to correct the record this can be taken into account by others in legal setting. The recipient wrongly suffered economic loss as a result of poorly implemented automation systems for the purposes law enforcement is able to use the evidence of their circumstance to sue the signatory of that claim who was legally responsible for the circumstances due to the automation systems relying upon the trustworthiness of the cryptographically signed document to operate, whether this resulted in a plurality of outcomes or simply a singular and relatively minor one. Usecase: digital reciepts vs. loyalty card data. I wonder whether retailers who've sold food that has caused health problems such as allergies could be influenced by similar considerations when a machine readable digital reciept may have mitigated any such Ill health outcomes, and that data is already being used for other purposes such as loyalty programs or CRM / customer analytics... A round-a-bout way to progress... nonetheless, perhaps the circumstance has merit. If the data from the Fitbit could have prevented heart attack, is the data storage operator responsible for not supplying that data to the consumer in a way that it could be used for health purposes? Yet also; herein a new challenge. The language changes so that rather than recipients being entitled consumers, retailers are entitled consumers of instruments issued to recipients through their role of being entities of trust (and implicitly, solely accountable signatories). So, thats where my headspace is upto. Hope it helps. Tim.h.
Received on Monday, 26 June 2017 14:46:27 UTC