KYC for Verified Authors

[yattias]

Update author claiming functionality to be KYC based.

Rationale for feature: Authors will be able to earn rewards on their papers. In order to accurately provide rewards to the right people, a KYC process will need to be in place. Prior to the KYC approach, multiple iterations of a verification feature were attempted which resulted in abuse of our platform.

High level workflow:

Part 1: Identity

1. Users will initiate verification by clicking a CTA
   • ⚠ It is unclear exactly where the CTA will be. See discussion below
2. Modal will open and explain the benefits
3. Next step is identity verification via Persona. We should use their hosted solution to verify identity
4. Once identity is verified, a webhook will be triggered which will update the verification status on our end

Part 2: Profile

1. At this stage, a profile should be created for you based on the DOI of the paper
2. TBD

Potential Initiation points

[jeffreykoury]

One drawback we've been bumping into (maybe 5ish% of the time) is users who have left universities/institutions and no longer have "institution" emails. It would be good to have a flow to vet these (i.e. having official transcripts sent in lieu of an email or even non-institution emails in a viable way)

[yattias]

That's good know @jeffreykoury

@TylerDiorio Could we connect with Persona and see if they can help with that? Maybe we can skip validating institution email.

[TylerDiorio]

Re: Persona I created a Sandbox account with Persona to test out some of the functionality - from their Docs I see that you can do a "Document verification" which could probably be used to verify transcripts (i.e. dated University affiliation). Another question might be, is this something we need to have - since it does introduce quite a bit of friction + effort on the part of the researcher. If it's a past institution they may have to request their transcripts which can take time (and maybe money?)

[yattias]

The UX around KYC is a bit unclear and need to be ironed out. We may not deliver the ideal UX in the initial release, but would be good to identify what this ideal UX looks like so we can plan for it.

Some thoughts:

• KYC (identity) is different than rewards claim on a paper and should probably not be tightly coupled with it

• Good UX would not require user to exclusively be on a paper page in order to initiate a claim because this will be a "hidden action" which will be missed by many of our users.

• Complexity arises around bootstrapping an author profile page after KYC process. In order to bootstrap a profile we need to know either a DOI or some other identifying piece of data. If process is initiated outside of a paper page we do not have this information

• If user has already KYC'd then they do not need to do so again when claiming a paper, only the first time Need to figure out

One UX approach is:

Initiating claim via paper page

1. If not KYC'd, show KYC modal
2. Once KYC is completed send in-app notification which will prompt them to enter details about the paper they are claiming including pre-registration, etc..
3. Paper goes into admin queue

Initiating claim elsewhere (such as left sidebar) Same as above but will require user to enter a DOI

[TylerDiorio]

KYC (identity) is different than rewards claim on a paper and should probably not be tightly coupled with it

Agreed:

• Profile Claim:
  • Actions: KYC + 1x DOI
  • Outcome: Complete Author profile page, verified author badge
• Paper Reward Collect: (After KYC)
  • Actions: "Collect RSC" button -> Add open-access, pre-reg, open data -> Admin panel review per paper
  • Outcome: RSC sent to account, visible indicator on profile page for 'claimed/collected paper'

Good UX would not require user to exclusively be on a paper page in order to initiate a claim because this will be a "hidden action" which will be missed by many of our users. Complexity arises around bootstrapping an author profile page after KYC process. In order to bootstrap a profile we need to know either a DOI or some other identifying piece of data. If process is initiated outside of a paper page we do not have this information

My thought on possible flows, where the KYC modal has a DOI/Author field required:

Initiating claim via paper page

1. If not KYC'd, show KYC modal with auto-populated DOI/Author selection from paper page
2. Once KYC'd, auto-populate a complete profile page
3. Send in-app notification, prompting users "Congrats, you're verified" -> "Go to claim/collect your paper rewards", where we suggest their best paper as a starting suggestion

Initiating claim via side-bar

1. If not KYC'd, show KYC modal with empty URL/DOI/Author field
2. User pastes a URL/DOI, which finds the paper and creates a drop-down list of authors.
3. User selects their name in the author list
4. Once KYC'd, auto-populate a complete profile page
5. Send in-app notification, prompting users "Congrats, you're verified" -> "Go to claim/collect your paper rewards", where we suggest their best paper as a starting suggestion

Activity-based prompt (too broad for scope probably)

1. If active on site (few sessions or likes/comments), send a Toast notification E.g. "Have you authored a published paper? Claim your author profile"
2. show KYC modal with empty DOI/Author field
3. User pastes a URL/DOI, which finds the paper and creates a drop-down list of authors.
4. User selects their name in the author list
5. Once KYC'd, auto-populate a complete profile page
6. Send in-app notification, prompting users "Congrats, you're verified" -> "Go to claim/collect your paper rewards", where we suggest their best paper as a starting suggestion

[yattias]

Thanks @TylerDiorio. I was also thinking about the UX below

My thought on possible flows, where the KYC modal has a DOI/Author field required:

Initiating claim via paper page

1. If not KYC'd, show KYC modal with auto-populated DOI/Author selection from paper page
2. Once KYC'd, auto-populate a complete profile page
3. Send in-app notification, prompting users "Congrats, you're verified" -> "Go to claim/collect your paper rewards", where we suggest their best paper as a starting suggestion

Initiating claim via side-bar

1. If not KYC'd, show KYC modal with empty URL/DOI/Author field
2. User pastes a URL/DOI, which finds the paper and creates a drop-down list of authors.
3. User selects their name in the author list
4. Once KYC'd, auto-populate a complete profile page
5. Send in-app notification, prompting users "Congrats, you're verified" -> "Go to claim/collect your paper rewards", where we suggest their best paper as a starting suggestion

Some questions:

1. Is a DOI sufficient in all cases to populate an author profile page. I think so but can be missing something. From a DOI we can extract author, from author we get works and then create profile
2. From a time perspective, including a DOI in the modal will make development slower because we are now mingling identity verification with DOI and may not be able to use the Persona modal out of the box. More research will need to be done here to assess feasibility.

[TylerDiorio]

Is a DOI sufficient in all cases to populate an author profile page. I think so but can be missing something. From a DOI we can extract author, from author we get works and then create profile

It feels like it should be enough to create the author page like you mentioned (DOI -> Author -> Works). OpenAlex has a few useful things here:

1. On Works: [authorships][author_position][display_name] e.g. "authorships": [{"author_position": "first", "author": {"id": "https://openalex.org/A5059317331", "display_name": "Wahyu Utami", "orcid": "https://orcid.org/0000-0002-1604-2577"}, "institutions": [], "countries": [], "country_ids": [], "is_corresponding": false, "raw_author_name": "Wahyu Utami", "raw_affiliation_strings": []}, {"author_position": "last", "author": {"id": "https://openalex.org/A5064566864", "display_name": "Apt. Sudibyo Martono", "orcid": null}, "institutions": [], "countries": [], "country_ids": [], "is_corresponding": false, "raw_author_name": "Apt Sudibyo Martono", "raw_affiliation_strings": []}]
2. On Authors: [display_name_alternatives] e.g. {"id":"https://openalex.org/A5059317331","orcid":"https://orcid.org/0000-0002-1604-2577","display_name":"Wahyu Utami","display_name_alternatives":["Wida Utami","Winda Anggun Utami","Wahyu Pakerty Utami","W. Utami","Wahyu Lestari Utami","Wahyu Dwi Utami","Wahyu Utami","Wahyu Dhini Siswi Utami"]

Multiple Author objects associated with a given individual:

• 'Are you missing any publications?' button in the profile page
  • Allow authors to upload the DOI of one example paper they're missing, and we can fetch the OpenAlex author object associated with that which will allow us to grab all of that Author object's works and merge them into the user's profile.
  • *May require an admin review of the author name selected from this DOI

From a time perspective, including a DOI in the modal will make development slower because we are now mingling identity verification with DOI and may not be able to use the Persona modal out of the box. More research will need to be done here to assess feasibility.

I'm not sure I understand fully. It sounds like we could use Persona's out of the box modal to get their identity verified. Then after that, we can allow them to enter a DOI & select author for the purpose of fetching their Author & Works from OpenAlex. The interplay between Persona & DOI doesn't necessarily need to be automated in the v1 if we can't fit it in the scope. During Admin reviewal of claimed papers, the verified name and the author name being claimed can be inspected manually to begin

[TylerDiorio]

UX Suggestions:

• "Missing a paper"?
  • Under "Key Stats" & "Works"
  • Fetch all papers under the newly identified alt-name
  • Prompt user to uncheck any of the fetched papers they don't want imported
• Some unverified visual cue under "Expertise"
• "Verify Identity" =/= Claim Authorship
  • Anyone can kyc, authors can also add DOI via toast notification after kyc