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

Few Thoughts...

IMHO - It's not about identity - it's about identifiers and more
specifically external claims. SO, if identity is made-up of personally
controlled stuff - like persona and the way you organise your
communications; in addition to external stuff, such as the secure documents
you use (birth certificates, passports, qualifications, etc.) and then you
add in time and the way that changes things; it's a bit like 'who you are'
and 'who others think you are', and their in the right to choice.

So, i'd say it's not about Identity - as Identity is not linear nor does it
pertain a singular encryption pyramid with external forcefully trusted
dependencies. This distinction serves to clarify the concept of ‘freedom of
thought’.

The purpose of these identifier solutions is to define the bedrock for
applications of credentialing technologies in a manner that is ‘human
centric’ as a primary design aspiration. In-turn these design qualities
relate to privacy, the rights of person and our ambitions to participate in
facilitating a role that forges a path to the best of our capacity, towards
a more advanced and sustainable future.

So therefore, with regard to the technological capability designed to
support the communication of a secure-document (credential) capability; and
the knowledge engineering principles applied to those secure document
capabilities for the express purpose of supporting machine readable
human-identifiers and related logic-support capabilities; I figure the
'agents' reviewing or requesting these things are in-effect a bit like the
customs passport control desk people - it's a checkpoint.

the checkpoint needs some particulars that have been issued to the
holder/owner that the claim is about.  It is their choice whether or not
the present the document at the checkpoint.

(i'm not suggesting their wouldn't be consequences if they refused to, but
rather, it's their choice to do so or not to do so...  the machine doesn't
really care or have real consequences put upon them...)

so, i think using language that reinforces the choices of humans to use the
thing or not to use it at any given point to be important in the language
we convey / make standard...

Tim.H.

On Thu, 9 Jun 2016 at 01:12 Manu Sporny <msporny@digitalbazaar.com> wrote:

> Joe forgot to cc this group on his input.
>
>
>
> ---------- Forwarded message ----------
> From: Joe Andrieu <joe@joeandrieu.com>
> To: public-webpayments-ig@w3.org
> Cc:
> Date: Wed, 08 Jun 2016 07:58:47 -0700
> Subject: 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
>
>