- From: Joe Andrieu <joe@joeandrieu.com>
- Date: Wed, 08 Jun 2016 07:58:47 -0700
- To: public-webpayments-ig@w3.org
First, my apologies for joining the conversation so late and for such a long email. In particular, my apologies to Manu if by bringing up terms outside his solicitation, I am speaking out of turn. I won't be offended if you tell me that discussion is simply off the table at this stage. IMO, our primary obstacle to adoption is not understanding by developers and technologists understand, it is acceptance by states, courts, and public services. Our audience isn't technologists. It's the people who make decisions about how identity is managed in real-world systems. That said, I do understand that for this initial set of work output, our audience *is* actually technologists, so I won't feel dismissed if trying to favor the layperson is a lower priority at this time. ======= Recipient. (Second choice receiver.) NOT Consumer, Inspector, Reader, or Verifier Coming from the "VRM" and user-centric conversations, and echoed by the sentiment at the UN last month, "Consumer" reads as the purchaser of goods and services. I understand that in technical contexts, it is a common term of art, but for me the sensitivity to treating human beings entirely from a commercial perspective is too great. At the UN summit in particular, it was made clear that whatever solution we figure out, it cannot be an enabler of new forms of digital colonialism. The specter of Western Civilization subjugating the world through commerce is a real problem for adoption on a global scale. So using "Consumer" for any role is a hot button. Also, the FTC Fair Information Practice Principles, the most comprehensive regulation in the US regarding privacy, uses "Consumer" to refer to the Holder and not the Inspector/Recipient/etc. This ambiguity of which /role/ in the architecture might be the "Consumer" is a further argument against its use. I favor "Recipient" (and possibly "Receiver") because it flowed for me in my simple diagram of Issuer, Recipient, Subject, and Presenter. Issuer -> Recipient. That pairing made sense. Who is accepting the verified claim and using it to provide a service? The recipient. Just writing up that sentence I ran into the issue raised on the call about "Recipient". My impulse was to ask "Who is getting the verified claim?", but that could mean also mean the Holder receiving the claim at the time of issuance. Then I thought "Who is relying on the verified claim?" and that led me down the path of "relying party", but I understand the desire to distinguish this work from other user-centric identity efforts. The matter of whether or not the important receipt happens at claim issuance or claim assertion is fair. Another alternative could be "Service Provider", if we are willing to accept that the reason a claim is asserted is for access to, or to use, a given service (which I think applies to both digital and real-world use cases). I *would* champion that term, as I favor it over "Recipient", but it wasn't on the list and I fear it may be too far out to find consensus in the time frame we want to resolve the issue. I dislike "Inspector" and "Verifier" because I resonate with Dave Crocker's desire to allow a third party inspector service that performs the role of validation or verification. The technical function of validating a claim is distinct from depending on, or using, a claim presented by a user. The validation just checks the crypto. The Recipient is the party that actually uses the content and relies on the meaning of the claim. FWIW, I favor "Recipient" rather than "Receiver" because recipients are entities (people, companies, etc.) while receivers are often just things (radios, etc.) "Reader," like "Receiver" reads to me as a device, e.g., an RFID reader. It also fails to associate the dependence upon the credential in providing a service, instead of an apparent focus on the means by which the claim is ingested, such reading the RFID tag or the JWT claim. ======= For TBD Credential, I don't have a strong opinion. But I do for two other terms. Again, Manu, please correct course if this isn't the right time to raise these issues. ======= "Presenter" instead of "Holder" It seems from the architecture that the "Holder" of a claim may in fact, not be holding it. They may simply provide a reference (or the means to derive a reference) to a claim stored elsewhere. I believe this is a key distinction in the architecture as described by DIDs and the work at the ID2020 Design Workshop. Whether we use a blockchain, a DHT, or just a website, it's clear that the actual cryptographically verified claim may in fact NEVER be held by the party presenting it to a service provider. Like my Facebook data that gets transferred via OAuth when I use Facebook to log in to Bing, a verifiable claim has no inherent need to ever be physically (or digitally) in the possession of either the subject or the "Presenter" of that claim. Unless I'm missing something with the Verifiable Claims work, I think this is kind of a big deal. In almost all cases, there is no need for the Subject or Holder to actually hold that data. In a system where the ledger is "in the cloud", people could assert a given set of claims--or a recipient could derive a reference and retrieve a set of claims in the public record--without ever having the claims themselves in the possession of the "Holder"/"Presenter"/"Asserter", either physically or digitally. At the UN summit multiple cases were discussed where the Subject either had destroyed their credentials or had them confiscated as a means of control. The implication of the term "Holder" is that the control lies in those who hold the claim and this is precisely the problem in those use cases. In contrast, from an architectural standpoint, the semantic distinction for "Presenter" is that they are the party asserting a particular claim. The Presenter is saying "this claim applies". The claim may be about their dog, a parent, or about them, but the key distinction is that this party is the one making the assertion about applicability to the current transaction. The Issuer isn't saying that the current user is associated with the claim; the claim stands on its own. The Recipient isn't making an assertion either; it is ingesting the claim. It is the Presenter's role to say that a particular claim applies. Whether or not the Presenter "holds" it in any sense of digital hosting or physical location is besides the point. They can, but it isn't a requirement of the system. Unless it is... then I'm just wrong. ======= Anything other than "identity" for the collection of claims about a subject. I realize this is probably to big too, too late to get into the Task Force's work product in a significant way, but it is a primary focus of my contribution to the ID 2020 Design Workshop and the follow up paper I'm writing. I'd be remiss if I didn't make the effort to share my thinking on the topic. When we refer to "identities" as things we control, we obscure the fact that *all* identity is inherently emergent and NOT an innate property. Only when an observer correlates a subject with something else is there identity. Without the act of identification, there is no identity. I argue in an upcoming paper from the workshop, all identity systems can be fully specified through their correlations--intended, unintended, and restricted, without using the philosophically and politically overcharged and overloaded term "identity" or "identities" to describe the things in the system. As an adjective to label the system or parts of the system, it's great. Just don't treat "identity" as a concrete noun. For example, in the Use Cases document, "identity" is formally defined as a noun: "A set of information that can be used to identify a particular entity such as a person, organization, concept, or device. An entity may have multiple identities associated with it." This is a great example of the use of "identity as a property" that I argue against in my Topic Paper for the ID2020 Workshop: https://github.com/WebOfTrustInfo/ID2020DesignWorkshop/blob/master/topics-and-advance-readings/Identity%20is%20a%20Phenomenon%20Not%20a%20Property.Andrieu.2016.pdf First, I'm not sure why this isn't "identifiers" or Personally Identifiable Information" Second, consider the definition in light of the one for "credential" in that same section: "A set of claims that refer to a qualification, achievement, personal quality, aspect of an identity such as a name, government ID, preferred payment processor, home address, or university degree typically used to indicate suitability." Either there is no meaningful difference between an "identity" and a "credential" since everything in a credential can be used to "identify a particular entity" and credentials can incorporate "any aspect of an identity"... *or* I just don't understand the distinction. There are a lot of commas keeping me from understanding if, for example, "government ID" is an aspect of an identity, or something a set of claims refer to. With the greatest respect for the intelligence and hard work that has gone into these documents, this is a common, even endemic, problem in technical conversations about identity. The term is simply so overloaded it is nearly useless as a noun. I love it as an adjective, but as a noun, it obscures more than it illuminates. Figuring out what to use instead feels like a rathole, but I think that's because we tend to fixate on "identity" and try to limit its definition somehow when the innate flexibility of the term itself is the problem. It's like having an argument about how to stop having arguments... I make the case in the upcoming paper that using "correlation" instead can avoid the rathole and clean up the conversation. Here are a few possible definitions as a proposal for the use case document (and elsewhere), which avoid "identity" as a noun, but which I think describe essentially the same elments One thing... I didn't see (in the use case document) a distinction between an unsigned statement and a signed claim. So I propose one. A statement is an assertion by an issuer, associating a subject with a fact, an identifier, or a privilege. For example, * the current user's username is "joeandrieu", * "joeandrieu" is "an American citizen", or * "joeandrieu" has admin privileges. A claim is a cryptographically signed statement. (Collection of one or more statements?) A credential is a collection of one or more claims (from a single issuer?), typically used to correlate individuals across contexts and provide access to services. For example, to verify that the current user is, in fact, the board certified podiatrist Michael Smith, with "admittance" privileges to Huntington Medical Center. A profile is a collection of one or more credentials, potentially from multiple different issuers, presented by an individual to help a service authenticate, authorize privileges, and correlate activity across contexts. I *believe* this is in keeping with the spirit of the terminology. My apologies if I'm off base. Obviously I have some questions about where a thing might be a collection versus just a singleton. Also, here's the current draft of the upcoming white paper on "identity" and "correlation". It's not complete, but you can get a bit more detail on the argument and a few examples of what we mean. https://docs.google.com/document/d/1nxo7jXrfg0s5nAXS4ue0uERm6aAAUF39HczgwygJLFk/edit?usp=sharing Again, I realize it might be too late to shift that language, but if we can, I think it would significantly improve the clarity and simplicity of the documents. That's it. My apologies if I'm talking out of school or stepping on toes. As a latecomer (and nonmember to boot), I welcome suggestions for how to best contribute. On Tue, Jun 7, 2016, at 08:00 PM, Manu Sporny wrote: > We discussed terminology on the Verifiable Claims Task Force call today > and left two things undecided. We really need to get this terminology > straight in order to align the prose in all of the documents. As a first > step, we need to get all of the options on the table. > > ------- > > We have a block in our architecture block diagram that is currently > labeled as "inspector": > > http://w3c.github.io/webpayments-ig/VCTF/architecture/architecture.svg > > This is the entity that requests a set of verifiable claims from the > holder and examines them to determine if they are valid for the purposes > of granting access to a particular resource. Naming options include: > > Consumer > Inspector > Reader > Verifier > Receiver > > ------- > > We agreed to relabel the word "Credential" with a modifier in order to > reduce confusion with other "credential initiatives". Naming options > include: > > Identity Credential > Digital Credential > Web Credential > > ------- > > Please add to these list of options with the following caveats: > > 1. If you propose something, make sure that you're the champion for > that term. Don't suggest something that you wouldn't want as the #1 > pick. > 2. If you propose something, make an argument for the use of that term > and an argument against all of the other terms. > 3. Don't send "me too" emails. If you want to weigh in, please make > sure you're making an argument that no one else has made in order to > cut down on the number of emails sent to the mailing list. > > We are going to collect input until midnight on Thursday and put up two > Generalized Instant Runoff Voting[1] polls on Friday. The polls will be > open for a week and will determine the final terminology we'll use > across all of the documents. > > -- manu > > [1]https://www.opavote.com/methods#instant-runoff-voting > > -- > Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny) > Founder/CEO - Digital Bazaar, Inc. > JSON-LD Best Practice: Context Caching > https://manu.sporny.org/2016/json-ld-context-caching/ > -- Joe Andrieu joe@joeandrieu.com +1(805)705-8651 http://blog.joeandrieu.com
Received on Wednesday, 8 June 2016 14:59:12 UTC