Proposed BadgingAPI Refactor to Reduce GitHub Permission Scope Requirements

[adeyinkaoresanya]

The BadgingAPI maintenance team is currently refactoring the BadgingAPI to address a few issues identified in the system, including concerns about the permission scopes required by the badging bot on users’ repositories. This relates to the earlier discussion held on Slack.

At the moment, GitHub OAuth does not provide a granular permission scope that allows access to only public email/user information. Because of this limitation, we explored a workaround in order to implement the principle of least-privilege access.
With the new implementation for event badging:

• The badging bot will create the issue on behalf of the applicant.
• The applicant’s name and GitHub profile link will still appear in the application.
• The database output remains the same as the current implementation.

The main trade-off is that applicants will no longer appear as issue participants directly. However, they will still receive notifications whenever they are tagged in comments using their GitHub username, thus will be notified if a reviewer is asking for further details or when their badge is ready.

Below are screenshots comparing the old and new permission scopes, along with examples of the resulting output:

Before:

After:

Before:

After:

We would appreciate your feedback before we move this into production.

CC:
@germonprez
@ElizabethN
@Ruth-ikegah
@geekygirldawn
@DesmondSanctity

[ElizabethN]

This all makes sense to me! Thanks for sorting out a workaround. ✨

[geekygirldawn]

+1 I think this looks like a really good solution to avoid asking access that we don't really need.

[Ruth-ikegah]

+1. This looks great to me. Since the issue still mentions the applicant, we are good to go.

[germonprez]

Hi everyone. Thanks for the work. I really do appreciate the effort. Seems to be good to go!

[adeyinkaoresanya]

Thank you, everyone! I will relay this back to the team