Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: ESSR protected client APIs #351

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

iFergal
Copy link
Collaborator

@iFergal iFergal commented Jan 15, 2025

This replaces the current RFC-9421 signed headers between Signify and KERIA with ESSR. Beyond confidentiality, it also resolves other issues from before such as unsigned query params and bodies. (#287)

The unsigned HTTP request from the client is converted to a HTTP bytestream and embedded in an ESSR payload. This payload becomes the body of a wrapper HTTP request for the "/" path - so tunneled via ESSR. The wrapper could be handled by pure TCP but for now this works quite nicely in the Falcon middlewares with minimal changes.

Like the keripy ESSR parser, the commitment to unsigned HTTP request is done by taking a digest:

payload = dict(
    src=<sender>,
    dest=<receiver>,
    d=coring.Diger(ser=cipher, code=MtrDex.Blake3_256).qb64,
    dt=dt,
)

I have written the corresponding code in Signify and all integration tests pass. I will create a Signify PR tomorrow. They should probably merge together.

@iFergal iFergal self-assigned this Jan 15, 2025
@iFergal iFergal changed the title feat: ESSR client authentication feat: ESSR protected client APIs Jan 16, 2025
@iFergal
Copy link
Collaborator Author

iFergal commented Jan 17, 2025

WebOfTrust/signify-ts#304 created on Signify side

}

for key, value in headers.items():
key = "HTTP_" + key.replace("-", "_").upper()
Copy link
Collaborator

@2byrds 2byrds Jan 17, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why does it need this replacement, is it a fix for another issue with the headers we're producing/receiving?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's how WSGI (falcon) expects it in the environ that builds the request. The headers in the actual HTTP request still have dashes like normal.

hio also does it: https://github.com/ioflo/hio/blob/main/src/hio/core/http/serving.py#L737-L740

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants