feat: initial gnap and http signatures implementation

[elijah0kello]

Changes in this PR

• added classes for key management
• added http signature header support for requests to auth server and resource server
• added unit tests
• added github actions file to run tests

Things to note

• integration tests are still failing since when I was making requests to https://auth.interledger-test.dev, I didn't have any public keys registered.
• I therefore need some help understanding how to upload public keys to the AS.

@Tymmmy @johngian please review

Authors

• @elijah0kello
• @Kasweka1

Run unit tests

poetry run pytest -s test/unit

[elijah0kello]

@Tymmmy I have added some usage documentation in the README.md. Still adding more docs though.

The current docs should give an idea of how I envisioned the client to be used.

[elijah0kello]

The integration test for requesting a grant is now passing.

to run integration tests.

poetry run pytest -s tests/integration/test_grants.py

I registered a wallet , created keys and loaded it in privkey.pem.example for testing

[sidvishnoi]

Looking good!
Did a quick first pass, will try setting up locally for next round of review.

[elijah0kello]

thanks @sidvishnoi for these comments. I will address them ASAP.

[johngian]

Some overall comments about this PR:

• I think 33 commits are not very manageable/readable to review. I suggest the commits to be more atomic.
• I am not sure what's the policy for 3rd party libraries but I would advise against building on top of non established authentication related libraries

[elijah0kello]

thanks @johngian for these comments.

• I am happy to take you through the codebase if it is overwhelming. Also it is just a lot of commits but the actual code changes are not so many.
• In regard to the third party lib, I read through the code base for the http signatures lib and also made a PR to fix something that was wrong. That being said if there is a policy, let's hear it and I'll address that specific issue with a custom implementation of http signatures.

[johngian]

@elijah0kello its not about having an overwhelming codebase. There is a purpose and value on having atomic commits. The PR at its current state (from a quick look) has 4+ commits that are about running unit tests and 3-4 commits only about updating docs, on top of that there is a bunch of merge commits from other repositories which don't bring much value in the context of the commit history. Also there is a commit that fixes a typo of a change introduced in this changeset.

Regarding the http signatures lib i would defer to the folks from the organization to decide but if it was my decision i would rather have an implementation that is audited/vetted by the org or built internally just for the purpose of ILF projects.

[johngian]

We do have a poetry based setup, there is no need to point to a pinned version of the wheel file.

[johngian]

If you are running poetry install why do you need to explicitly install the module?

[koekiebox]

@elijah0kello its not about having an overwhelming codebase. There is a purpose and value on having atomic commits. The PR at its current state (from a quick look) has 4+ commits that are about running unit tests and 3-4 commits only about updating docs, on top of that there is a bunch of merge commits from other repositories which don't bring much value in the context of the commit history. Also there is a commit that fixes a typo of a change introduced in this changeset.

Regarding the http signatures lib i would defer to the folks from the organization to decide but if it was my decision i would rather have an implementation that is audited/vetted by the org or built internally just for the purpose of ILF projects.

I am happy, as long as we introduce CVE scanning to ensure the libraries are safe to use. I have left other comments on the PR. 🙇

[koekiebox]

Left a couple of comments, mostly regarding pip-audit.

[elijah0kello]

thanks @koekiebox for comments.

I will address as advised. Especially the dependency auditing.