Re: Alternative terminology for "consumer"

On 03/29/2016 02:15 PM, Stone, Matt wrote:
> dave, can you remind me why we opened this thread?

About a month ago we started reconsidering the terminology for both
"curator" and "consumer". For the latter, people were concerned that the
term "consumer" had a potentially negative connotation (perhaps even
disrespectful/insulting) and that it could be confused with the "holder"
as they were seen as the primary actor in the system.

> "acceptor" pre-supposes a positive outcome, an inspector may accept or
> deny the claim - even if it's verified as authentic. -- I'm not crazy
> about "inspector" for the reasons you suggested above.  
> 
> Maybe we should be focused on the "ask" - this role is that of the
> "requester" , ie. some interested party has requested proof of
> {status/attribute}. Consult the thesaurus for "one who asks" :)

We've tried "requester" before, but unfortunately, people felt that it
could be easily confused with other parties. There are lots of
"requests" that are made in the ecosystem. It could be said that a
holder requests a credential from an issuer. It could also be said that
a consumer requests a credential from a holder. Which is the "requester"?

Here's the knowledge we have about the ecosystem (without using any of
the terms for its actors):

The ecosystem is about obtaining and transacting sets of verifiable
claims or "credentials". A credential is its main "currency". The
ecosystem contains four main actors:

Actor 1 makes claims about Actor 2.
Actor 2 receives claims from Actor 1 and decides with whom to share  them.
Actor 3 helps Actor 2 store their claims.
Actor 4 requires claims from Actor 2 for some purpose.

(Note: Technically, the party that claims are made about may have no
agency -- eg: is an inanimate object like a IoT device -- and in this
case Actor 2 acts on its behalf.)

Another observation is that it seems pretty clear that we could model
the behavior of each of these actors using a sentence that has this
common structure:

<Actor X> <predicate> a credential <preposition> <Actor Y>.

There is always one actor doing something with the currency (a
credential) with respect to another actor. Using this structure may help
disambiguate actor terminology.

Now, out of all of the terms we have used to identify these actors, I
think the best we have is "issuer". It seems to fit well with the
"currency" analogy:

Actor 1 (The "Issuer") issues currency, like a mint, to Actor 2.
Actor 2 receives the currency and decides how/where to "spend" it.
Actor 3 is like a bank that helps Actor 2 store their currency.
Actor 4 is like a merchant that can provide a good/service in exchange
for currency from Actor 2.

If we put "issuer" into the sentence form, we get:

"An issuer issues a credential to <Actor Y>."

I'd argue that what is special about "issuer" is that the predicate that
is derived from its name ("issue") unambiguously identifies the "issuer"
as referring to Actor 1 and Actor Y as Actor 2. There are no potential
substitutes that would cause confusion.

To "issue" means to "create", "publish", or "distribute". Given that
we're understanding credentials as currency in the ecosystem, no one
would be "issuing" it other than Actor 1. Actor 2 certainly gives it to
Actor 4, but they do not create that currency and I doubt anyone would
think that they "issue" it to Actor 4. Actor 3 and 4 are clearly not
applicable.

Now, let's try to analyze "requester" the same way. Our sentence would be:

"A requester requests a credential from <Actor Y>."

To "request" means "to ask for something". So which actors might ask for
a credential? Unfortunately, I think it's ambiguous because we need to
know "for what purpose" they are asking. Are they asking for a new
credential to be created? Are they asking for an existing one in return
for something? Couldn't it be either of these? Could it even be that
we're asking to store a credential?

This term *could* be used to refer to Actor 4, but it just doesn't seem
as unambiguous as issuer is for Actor 1.

We can try this method with "accepter":

"An accepter accepts a credential from <Actor Y>."

To "accept" means "to receive something that was offered." So, both
Actor 2 and Actor 4 receive offered credentials, from Actor 1 and Actor
2, respectively. There's still some ambiguity that makes me
uncomfortable with the term. However, it does somewhat fit with the
currency analogy -- you could think of it as merchants that "accept
Visa", for instance. These are "accepters" of certain credentials.

If we try with "inspector":

To "inspect" means "to examine carefully".

"An inspector inspects a credential from <Actor Y>."

Actor 1 doesn't inspect a credential. Actor 2 *might* inspect a
credential it receives from Actor 1, but that seems like a stretch -- or
at least it's not what I'd expect the majority of people would think
first. Actor 3 might also inspect a credential (prior to storage), but
that seems like it's incidental to its main purpose. Actor 4 will
definitely inspect a credential. So this term doesn't seem to be that
ambiguous to me, per this analysis.

However, I think the following terms have the same analysis as "inspector":

authenticator
verifier
assessor
evaluator
admitter
inquirer

So some other mechanism is required to better decide amongst them (or
some other alternative). An argument could be made that any party might
try to authenticate, verify, assess, or evaluate a credential. The
differentiator seems to be why they are performing the evaluation:

Actor 2 and Actor 3 would only possibly perform that evaluation to
ensure that the credential will be accepted by a potential Actor 4. They
are trying to prevent potential future errors. It's a step that may be
unnecessary.

Actor 4 must perform that evaluation in order to actually take some
immediate action. This is really where the term "consumer" came from to
begin with. The notion wasn't that the credential is "used up", but that
it was at least "used" for something, rather than simply "primed for
later use".

So, I believe we need a term that indicates that someone is in need of
something (ie: a credential) in order to proceed with some action.


-- 
Dave Longley
CTO
Digital Bazaar, Inc.

Received on Wednesday, 30 March 2016 04:43:18 UTC