RFC Provable attributes

[berkes]

Summary

Provable attributes in a resumé, marked as such.

Basic example

Many platforms and tools have proven, authorized or checks in place for attributes. Below are examples in keybase, mastodon, keyoxide and IRMA.

As a viewer of a resumé
When I view the resumé (CV)
Or I search, based on attributes
Then I want to see if the attributes are verified, have proof or are otherwise provable
So that I know how far I can trust attributes provided.

As a member of flockingbird
When I view the rcontact details of another member
Then I want to see if the contact details are verified, have proof or are otherwise provable
So that I know whether the contact details are correct and belong to the member

As an owner of a profile
When I fill my resume with attributes
Then I want to have instructions on how to provide proof for the attributes.
So that I can attach the proof and have the verified status show up.

Motivation

A resumé with some provable attributes has great value. Not only for people searching and filtering by those attributes, but also when reviewing a single resumé.

It is one thing for a person to say they have "16+years experience in iPhone" , or that they attended Hogwards School, without any proof, this leans entirely on trusting the applicant of the information.
Which is why HR often wants some contact details to be able to call previous employers, a university etceteras. And why they often want additional proof such as (hard to forge) certificates, an ID-document and so on. All of which comes with high friction and cost. Which is fine in later stages of recruiting.

In earlier recruiting stages, it may be very interesting to have (cryptographically) proofs next to an attribute. A proof "this github repo is really mine" or "I'm 21+ years old" or "I attended Hogwards university from X to Y".

A side effect is that this makes a great tool to defer scammers or fraudsters. If you cannot, or do not want to, offer the proof that you attended a school, wrote this paper, contributed to this software and so on, people are right in doubting you actually did those things. Provided it is easy to give that proof.

Another important side-effect is that this same mechanism allows proof of contact details, such as an email-address, domain, phone number and so on.

Detailed design

It needs a thorough investigation of attributes that can be provable now, can become provable in (near future) or can never become provable.

For example, IRMA has a list of use-cases and attrbitutes, most of which are limited to the country where it is being rolled out (the Netherlands). Other provable attributes are those presented by keyoxide, keybase or mastodon, and are mostly in the area of proof of ownership of accounts, websites or cryptocurrency-addresses.

IRMA has proof of attendence or employment by some Dutch Universities. Other apps and initiatives may cover other geographic regions. Research is needed for this.

Technical implementation is complex, but could re-use either keyoxide, or mastodon. The latter being limited in what can be verified, the former being relativly hard due to its use of GPG. Though the userfriendlyness of keyoxide could improve easily in future.

Drawbacks

Decentralised proofs

It is not enough to simply render some checkmark next to an attribute, as that can easily be forged in a decentralised setup: I could easily run my own instance of flockingbird that simply checks everything I add. A reader then needs to trust the instance, which hardly solves the problem.

Proof should be easily verifyable. E.g. a link to a twitter message in which I tweeted "I own this account" shows that I own (or at least am able to post tweets to) this twitter account. This proof is easily verifyable by anyone.

Proof that cannot be accessed publicly, cannot be verified in this way. E.g. a verified email-address of phone-number cannot be verified with public proof: there is no way external people can access the email or SMS received, which contains the verification code. For such attributes, we must trust the instance. Such attributes may be presented differently or omitted entirely. This is to be decided.

Usefullness of attribute-proofs for resumés or contact details

Many easily provable attributes are not very suitable for a resumé.
For example, proving that I owe a certain reddit-account, twitter-handle or mastodon account is not usefull for a resumé.

Those are, however, usefull for when providing contact details. "Reach me at @jack on twitter" as contact detail is much more valuable if that contact detail includes proof that I own @jack on twitter.

Why should we not do this? Please consider:

• leaning on keyoxide either, the protocol or the entire project, requires users to engage with commandline GPG still. Untill this is solved, this means it remains rather inaccessble to many potential flockingbird users.
• leaning on mastodon implementation removes most of the inaccessibility (though may not reach usability levels for masses, yet that is not the goal here), it does limit in types and therefore amounts of attributes that can be verified.
• verification requires instances to run processes to fetch verification in a timely and repeating manner (e.g. weekly re-check if the proof is still online). This may cause errors and issues, due to the nature of the proofs: they will go offline, get removed etc. as a common part of the working of this feature. Extra load and monitoring will make operating an instance more complex.
• Offloading to- or integration with protocols such as "keyoxide" (which isn't a protocol, really) or "IRMA" requires a lot of work for a rather small audience. Scaling up leans on either one of the existing implementations scaling up themselves (IRMA launching EU wide, for example) or on implementing more of such third parties. The former is full of risk the latter requires a large investment every time.

Alternatives

• Simply pointing to existing provable platforms from your profile. A "here is my keyoxide link" for example.
• Merely offering GPG itself and using that to sign the entire profile (which is similar to how keyoxide works, really).

Adoption strategy

There would need to a critical mass of "green checkmarks" appearing in profiles for people to notice it and research how they can get those themselves.

What that cricical mass is, how it can be reached and if it can be reached at all, should be researched.

How we teach this

See above.

Additional documentation and guides on what steps to take could be written either by externals or as part of the project usermanual

Unresolved questions

• Critical mass to be reached in order for people to notice it and start using it themselves.
• what attributes to offer and which to add in later phases.
• what third parties to include for offering proof.
• whether keyoxide offers enough to start offering this feature.
• whether the mastodon model and limitation of attributes (only domains?) is enough to start using this.

---

Footnotes and references

---

This RFC template is modified from the React RFC
template