feat(http-signature-utils): move http signature related code to this package

[sabineschaller]

Changes proposed in this pull request

• moves signature generation, jwk generation, and private key loading to here
• adds app with endpoint for postman to consume pre-request to generate signature headers

Context

• fixes Add sig support to postman collection #665
• fixes (open-payment): use signature creation code from http-signature-utils #818

Checklist

• Related issues linked using fixes #number
• Tests added/updated
• Documentation added
• Make sure that all checks pass

[wilsonianb]

Are you planning to add the signing endpoint to the localenv?

[mkurapov]

This also

• fixes (open-payment): use signature creation code from http-signature-utils #818

[wilsonianb]

Suggested change

	const sigInput = request.headers['signature-input'] as string
	const sigInput = request.headers['signature-input']

[sabineschaller]

getSigInputComponents(sigInput ?? '') requires a string and as is, sigInput is of type string | {toString(): string;} | string[]

[wilsonianb]

Can we keep this but just as a wrapper for the imported validateHttpSigHeaders in order to keep the HttpSigContext type guard?

[sabineschaller]

I'm not sure I understand.

[wilsonianb]

It would avoid having to change HttpSigContext to AppContext in verifySigFromClient/verifySigFromClient.
Not a big deal.

[wilsonianb]

Actually, this is already being checked by the OpenAPI validation middleware

rafiki/packages/auth/src/app.ts

Lines 198 to 204 in 30096d1

	createValidatorMiddleware(openApi.authServerSpec, {
	path: '/',
	method: HttpMethod.POST
	}),
	this.config.bypassSignatureValidation
	? (ctx, next) => next()
	: grantInitiationHttpsigMiddleware,

Maybe the types used in the OpenAPI type guards should also extend HttpSigContext which can be used throughout these signature middlewares

• feat(auth): add typings to request contexts & bodies #821

Maybe that gives us enough sanity checking to stop calling validateHttpSigHeaders early?
#797 (comment)

[wilsonianb]

Could generic SignOptions and Headers types be used to enforce that a request with body will return headers with content headers?

[sabineschaller]

I don't understand

[wilsonianb]

Not sure if it's worth it

type NoBodyRequest = SignOptions['request'] & {
  body?: never
}

type NoBodyOptions = Omit<SignOptions, 'request'> & {
  request: NoBodyRequest
}

type NoBodyHeaders = SignatureHeaders

type BodyRequest = SignOptions['request'] & {
  body: string | Buffer
}

type BodyOptions = Omit<SignOptions, 'request'> & {
  request: BodyRequest
}

type BodyHeaders = SignatureHeaders & ContentHeaders

export const createHeaders:
  | ((options: NoBodyOptions) => Promise<NoBodyHeaders>)
  | ((options: BodyOptions) => Promise<BodyHeaders>) = async ({
  request,
  privateKey,
  keyId
}) => {

[wilsonianb]

I'm wondering if we should either just export a verifyHttpSigHeaders function or minimize overlap between that and validateHttpSigHeaders?
As is, I like how we're able to perform basic validation checks on expected headers in auth's signature middleware before fetching the client key for actual signature verification. But I don't like how we call validateHttpSigHeaders again internally (with getSigInputComponents+validateSigInputComponents)

[sabineschaller]

I don't really know how we could improve on that here. Like you said, we want to validate the headers before fetching the key. When we validate the signature, however, we do need the components again. So the only option we have, I think, is to remove component validation from validating the signature because we always validate the headers first, which already includes validating the components.

[wilsonianb]

Should we require that content-length and content-type are also included?

[sabineschaller]

In the headers, in the Signature-Input components, in both?

[wilsonianb]

Both unless they're somehow not required by GNAP/httbis?
I think content-type is being enforced in the headers by the OpenAPI spec's:

      requestBody:
        content:
          application/json:

[mkurapov]

🚀

[mkurapov]

I like it, especially that the Open API schema gets defined in a single place. I'm guessing this package will also have http-signature-utils as a dependency? Are we planning on signing these AS <> RS introspection requests?