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

opps....



On Thu, 9 Jun 2016 at 01:43 Timothy Holborn <timothy.holborn@gmail.com>
wrote:

> Few Thoughts...
>
>
SNIP

IMHO - It's not about identity - it's about identifiers and more
> specifically external claims.
>

That should read - externally *validated* 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
>>
>>