[RFC] Proof of Association, Work, Learning, and Payment - request for comments

[surendrasinghs]

Requesting the community to help refine the Proof of Association, Work, Learning, and Payment VC specs. Please share your comments and suggestions here in the document.

@suresh12 @parthlawate @ChakshuGautam @amarts @girirajdaga @sukhpreetsamagra @sankarshanmukhopadhyay @rahul101001000 @pramodkvarma @dileepbapat @vrayulu @coolbung @gsasikumar @vvujjini

[surendrasinghs]

Quick update: Here's a sheet to capture everyone's comments on VC Specs

We have taken a shot at drafting Proof of Association to start with. Please suggest changes to the specification as well as the methodology/template for capturing comments.

We aim to get to Proof of Assessment (e.g. Exam Report Card, Regular Assessments) and Proof of Payment (e.g. Benefit Transfer, Salary slips) soon after, since we are looking at some of these use-cases in the immediate future.

Please add any other category/type of Proofs in the "use-cases" sheet. Look forward to contributions, comments, and suggestions. Thanks!

[gsasikumar]

I have updated it with comments in the excel sheet. Instead of proof of xxx can we look at these keywords . Is it ok if call it as Enrolled.for, Qualified.with, Trained.on, Affiliated.to, Volunteer.for, earned.morethan, earned.lessthan, Compensated.at The Proof of conflicts with the proof (Signature) that VC has.

[amarts]

Checked the document, and I don't see anything where 'Proof of' is used as part of JSON.

It can be title or category of the schema, that way, everyone knows when it says 'Proof of Work', there are certain fields to look for. The VC schema def will continue to have proof and other fields as per the VC standard.

This categorisation helps in applications who wants to have interoperability with respect to UI and workflow.

[pramodkvarma]

@gsasikumar if we start enumerating all possible "exact" relationships/associations, we can never be complete. So, my suggestion is to keep the natureOfAssociation as an enumeration (say, Enrollee, Employee, Partner, Consultant, Other) and then have a free text attribute titleOfAssociation (or role) which allows issuers to be flexible (Student, Teacher, Headmistress, Software Engineer, Advisor, Program Manager, Platinum Member, Volunteer, Intern, etc.). @surendrasinghs I have commented inside sheet as well.

The VC schema type of "Proof Of Association". I don't see an issue with that given it is a signed proof of some claim.

[gsasikumar]

@pramodkvarma Fair enough but then how will anyone know what natureOfAssociation really would mean? a claim is supposed to be an assertion but here we seem to be generalizing it and the assertion is clear only after understanding the enumeration. Also, some of the lists above should have a mapping to a type as defined in VC . When a user has multiple such credentials you may want to selectively query as a verifier a specific type of VC. For eg: I would request for the credential with type as education. This should give me all his education type or subtype VC as a VP.

[pramodkvarma]

We will specialize the schema through enumerations (like two layers of becknprotocol.io schema for example), a generalized structure to capture various types of associations and specialized enums and tag names for specialization. An inheritance like structure to avoid many structures coming up which is almost look alike! Hope that makes sense.

[pramodkvarma]

This is great! Allows product/functional folks to participate in feedback. Once this is done, actual schema can be created. Btw, @surendrasinghs I do have comments on Proof of Association sheet. Don't seem to have comment rights. If you want folks in the community to comment, please enable comment rights for everyone. If you prefer any alternate way, please suggest.

[surendrasinghs]

Thanks, @pramodkvarma, for a prompt (lightening fast!) response.

I have given commenting rights to the folks tagged on this thread. Please request comment/edit access if you don't already have it.

[pramodkvarma]

In addition to known folks, I suggest you give comment rights to "anyone who has link" given this is an open source effort. Hope that's fine.

[surendrasinghs]

Done :)

[suresh12]

@pramodkvarma we just want to confirm, were you suggesting to also derive generic schemas like address, contact, city, etc. like in Beckn(https://github.com/beckn/protocol-specifications/tree/master/schema) as part of this, so that we can create composed schemas.

[surendrasinghs]

Yes, I believe that would be quite helpful as well. Let's initiate that as well - maybe in the same sheet for now. We should aim to do this in a way that everyone (non-tech) folks can engage as well. Thanks!

[pramodkvarma]

Yes @suresh12, that's what I meant.

[pramodkvarma]

@surendrasinghs Also, issuer need not be the org itself. We need to separate. Also, is there any reason for assuming org vs individual for the association? Association could be between any two persons (entities being legal persons).