Re: Alternative terminology for "consumer"

I had one additional thought about the consumer of claims. It strikes me that the role they are actually playing is gatekeeper. I got to this after thinking about the various processes in which claims are used and the reason that someone wants your claim/s is to evaluate it/them in a context. If the evaluation finds the claims and attendant and other sources of evidence sufficient, you get a chance at an opportunity, access to something, a permission, a benefit, and so on. I am not sure gatekeeper is the best word but wanted to share the line of thinking and see how it may help.

Sent from my iPhone

> On Mar 31, 2016, at 10:56 AM, Kerri Lemoie <kerri@openworksgrp.com> wrote:
>
> I see our audience for the term consumer is primarily directed at developers. Consumer apps could be displayers, directories, hiring sites, college applications, or anywhere the claim is being used. The holder/owner/earner/recipient is the user of these apps and those apps can control that language on their end as its applicable to the claims they are consuming.
>
> Some thoughts re: holder/owner/earner/recipient  - I can see where owner becomes problematic but I think we may have a fundamental question here beyond language as far as this actor is concerned.
>
> While it may be true that a claim can be revoked, I don’t think that makes the issuer the owner. It just means that the claim no longer exists. Perhaps we think of it as shared ownership where the claim is a trusted contract between two parties and in which case maybe the actor names are “issuer” and “issuee” or something to that effect. The issuee is more than just a holder as this person should have control over the privacy of the claim. If issuer is considered the owner then the issuee will lose that power.
>
> In the examples of having access to parent’s or even children’s claims, that appears to be an access use case. If I have access to my children’s or parent’s claims, it doesn’t make me the holder or the issuee, it just means I’ve been granted permission by my children or parents (who are the issuees) to have access to the claim.
>
> And for the dog - well, even though in my case my dog definitely owns me, I paid for his rabies license, so the contract is between me and the city where I live so I am the issuee.
>
> Currently we think of the issuers as the owners because they are hosting or maintaining some kind of data record in their files. As we start thinking more about blockchain, the transactions start looking more like trusted contracts.
>
> K
>
>
>
>> On Mar 30, 2016, at 3:41 PM, Steven Rowat <steven_rowat@sunshine.net> wrote:
>>
>> On 3/30/16 6:09 AM, Kerri Lemoie wrote:
>>> I agree with Jim. I also think that an actor label helps to make a
>>> technology relatable and consume (consumer) is an apt enough term that
>>> if defined & supported well works if it’s described as “uses
>>> credential” . It implies that the data is being used however the user
>>> (consumer) intends to use it and does not add any implications on how
>>> the data should be used.
>>
>> Perhaps a point where some of us are talking past others in this discussion that might clear some things up (at least for me) is:
>>
>> Will the term 'consumer' be buried in the code, so that only developers see it, or will it be offered up front to the average 'holder' of a credential/claim (who, I re-emphasize, has been trained to respond to themselves being 'the consumer' in our society).
>>
>> If 'consumer' is buried in the code and only seen by developers, I agree that it doesn't make much difference.
>>
>> But, if the 'consumer' of a credential is going to be part of the surface-level UI, then I still think almost anything else would be better.
>>
>> A current example: the first time I read Kerri's statement above, I subconsciously misread the phrase "however the user (consumer) intends to use it" in exactly this way. I thought It meant the 'holder', not the body that is requiring it later. I had to read it again to get the entrenched 'consumer' definition out of my mind.
>>
>> As a developer, who is using the term over and over, I could re-map this relatively easily. But with a credential 'holder', who might only occasionally -- or only once or twice, even -- encounter this usage, I think the confusion would be common.
>>
>> Steven Rowat
>>
>>
>>>
>>>
>>> Kerri
>>>
>>>> On Mar 30, 2016, at 8:36 AM, Jim Goodell <jgoodell2@yahoo.com
>>>> <mailto:jgoodell2@yahoo.com>> wrote:
>>>>
>>>> It is difficult (sometimes impossible) to find a label that works
>>>> for everyone and every use, in this case for an actor with multiple
>>>> roles (needs credential, earns credential, receives credential, uses
>>>> credential for x, y, and z). Better to find a label for the actor
>>>> that works "well enough" (with no strong objections); then clearly
>>>> define, in the context of verifiable claims, all that label means
>>>> about a person's role in the ecosystem. A two or three sentence
>>>> definition can remove ambiguity of a single word label.
>>>>
>>>> -Jim
>>>>
>>>> On Wednesday, March 30, 2016, 1:25 AM, Stone, Matt
>>>> <matt.stone@pearson.com <mailto:matt.stone@pearson.com>> wrote:
>>>>
>>>>   Since our fundamental topic is a "verifiable claim", maybe
>>>>   "verifier" fits.
>>>>
>>>>   I'm afraid we're overthinking the nuance and subtext to the
>>>>   point that no one  will get it when we eventually roll it out.
>>>>   I respect that language has power but also know than few others
>>>>   will think as deeply as we do on the topic.  If it's overworked,
>>>>   we'll spend the next 5yrs saying things like "Think about it
>>>>   like this..."
>>>>
>>>>   -stone
>>>>
>>>>   On Tuesday, March 29, 2016, Steven Rowat
>>>>   <steven_rowat@sunshine.net <javascript:return>> wrote:
>>>>
>>>>       On 3/29/16 9:42 PM, Dave Longley wrote:
>>>>
>>>>           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.
>>>>
>>>>
>>>>       demander
>>>>       requirer
>>>>       needer
>>>>       necessitator
>>>>       requisitioner
>>>>       caller
>>>>
>>>>       S.
>>>>
>>>>
>>>>
>>>>
>>>>   --
>>>>
>>>>   =====
>>>>   Matt Stone
>>>>   501-291-1599 <tel:501-291-1599>
>
>

________________________________

This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited.


Thank you for your compliance.

________________________________

Received on Thursday, 31 March 2016 15:28:47 UTC