Re: Request for terminology input - consumer/inspector/TBD Credential

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