- From: Joe Andrieu <joe@joeandrieu.com>
- Date: Wed, 20 Dec 2017 13:28:51 -0800
- To: public-vc-wg@w3.org
- Message-Id: <1513805331.2945047.1211689960.1F56669F@webmail.messagingengine.com>
David, I think you're making it unnecessarily complicated, perhaps just so you don't have to update the diagram. =) I am contacted by recruiters all the time because of my LinkedIn profile, which includes things like my educational credentials. They are not acting on my behalf. I have no relationship with them. 99% of the time it is just SPAM and an annoyance. They are working for their client, who needs to hire talent. As the holder of the credential--which they downloaded from LinkedIn--they are acting on behalf of the verifier, their client. -j On Wed, Dec 20, 2017, at 1:37 AM, David Chadwick wrote: > > > On 20/12/2017 08:07, =Drummond Reed wrote: >> Excellent analysis, Joe. Seems right on. It's almost finding a new >> element that fits into a missing hold in the periodic table. > > Perhaps it could be a compound with the same molecular weight as the > missing element :-) > >> >> On Tue, Dec 19, 2017 at 5:00 PM, Joe Andrieu <joe@joeandrieu.com >> <mailto:joe@joeandrieu.com>> wrote: > > Good analysis, but I think the recruiter is still working on behalf of> the subject. The subject sends their VCs to the recruiter and asks (or> agrees to) the recruiter sending them to the employer on > his/her behalf.> The subject has also probably signed a contract with, or agreed to the> terms of business of the recruiter (including > privacy/disclosure rules).> The recruiter may have also withheld some information back such as the> name or contact details of the subject. > > So whilst it is true that the recruiter is being paid by the employer,> the recruiter is in fact acting on behalf of both parties. Hence my > reference to a compound in reply to Drummond :-) > > But this is definitely an interesting VC use case, and clearly the > employer will need to validate that the communication is coming > from the> recruiter and not from any random holder. So I will add it as > an example> of acts4 verifier > > kind regards > > David > >> >> __ >> Here's where I was thinking... >> >> In the VRM conversation, the question of who works for whom was >> resolved by following the money. >> >> The subject of the credential is the candidate. >> The recruiter is holder. >> The prospective employer is the verifier. >> >> The employer is paying the recruiter to find them qualified >> candidates. The employer reviews and verifies any credentials they>> receive before scheduling an interview. Hence, the recruiter is >> working for the employer and therefore, the holder is acting >> for the>> verifier. >> >> I think that matches your chart. >> >> -j >> >> On Tue, Dec 19, 2017, at 12:59 PM, David Chadwick wrote: >>> Hi Joe >>> >>> On second thoughts this is another example of holder acts4 >>> subject if>>> the client subsequently validates the VC. But if the client >>> relies on>>> the recruiter to validate the VC, then the client does not need >>> the VC>>> so it is not an example of a VC use case >>> >>> Comments? >>> >>> David >>> >>> >>> On 19/12/2017 20:38, Joe Andrieu wrote: >>> >>> Nice. >>> >>> For the case of the holder acting for a verifier: a recruiter>>> passing on >>> verified credentials of a candidate to their client. >>> >>> >>> On Tue, Dec 19, 2017, at 12:20 PM, David Chadwick wrote: >>> >>> Hi Everyone >>> >>> given that today we discussed the topic of subject not >>> being the holder, >>> I thought I would try to classify the different types of >>> VC that a >>> verifier might receive, given all the possible >>> relationships between >>> subject, holder, issuer and verifier. I attach a jpeg >>> picture that >>> depicts my first thoughts on how we might classify the >>> different types >>> and/or ways that a VC might be presented to a verifier, in>>> the shape of >>> a binary decision tree. I find the diagram useful in that>>> it is trying >>> to capture the wide variety of possibilities, and >>> eventually we will >>> need to cover them all in either the data model or >>> protocols or both, if >>> we are not to leave gaps in our specifications. >>> >>> If this is worth pursuing further then maybe this should >>> be put on the >>> web somewhere, and/or distributed to the CCG as well - >>> please advise. >>> >>> kind regards >>> >>> David >>> >>> Email had 1 attachment: >>> >>> * >>> |SubjectHolder.jpeg| >>> 95k (image/jpeg) >>> >>> >>> -- >>> Joe Andrieu, PMP>>> >>> joe@legreq.com <mailto:joe@legreq.com> >>> <mailto:joe@legreq.com> >>> LEGENDARY REQUIREMENTS>>> >>> +1(805)705-8651 <tel:(805)%20705-8651> >>> Do what matters.>>> >>> http://legreq.com >>> <http://www.legendaryrequirements.com >>> <http://www.legendaryrequirements.com>> >>> >>> >>> >> >> -- >> Joe Andrieu, PMP>> joe@legreq.com <mailto:joe@legreq.com> >> LEGENDARY REQUIREMENTS>> +1(805)705-8651 <tel:(805)%20705-8651> >> Do what matters.>> http://legreq.com >> <http://www.legendaryrequirements.com> >> >> >> > -- Joe Andrieu, PMP joe@legreq.comLEGENDARY REQUIREMENTS +1(805)705-8651Do what matters. http://legreq.com[1] Links: 1. http://www.legendaryrequirements.com
Received on Wednesday, 20 December 2017 21:29:14 UTC