Changes for ACME support

[andrewbaxter]

Hello, like #9 I'm looking into using this for an ACME implementation. I think a few other changes would be necessary

1. Support extra fields in the header, specifically url and nonce. I'm not sure the best way to do this. I can think of three options?
   • Allow embedding Header in other structs as a flat field, and move methods out of that struct. This would probably lose type safety since there's no way to restrict arguments on struct members
   • Allow embedding a user struct in Header as a flat field, with generics. You'd still need the generic parameter even if you aren't adding any fields.
   • Just add url and nonce to Header. Header is already a superset of possible fields, and AFAIK the two main uses of JWT are Oauth2 and ACME so it doesn't seem like a stretch.
2. Allow empty payload (in JWS at least) - per the JWT spec the payload can be any octet sequence, but is typically a base64 encoded document. ACME requires it to be "" for POST for GET in the protocol.
3. Add a JWS structure and encode/decode methods. I was thinking of jws.rs with encode_jws and decode_jws

These are fairly small changes so I'd be glad to make a PR if it sounds reasonable.

[gregparsons]

Is it the same thing that I need a nonce header to build the JWT coinbase expects?

https://docs.cloud.coinbase.com/advanced-trade-api/docs/rest-api-auth

From their python example...

jwt_token = jwt.encode(
  jwt_payload,
  private_key,
  algorithm='ES256',
  headers={
    'kid': key_name, 
    'nonce': secrets.token_hex()
  },
)

[andrewbaxter]

The ACME document didn't refer to any other spec so I think it's a coincidence, but I guess if one protocol needs a nonce there are probably others that do too?

IIRC one of the JWT spects talked about making RFCs for header keys, so maybe it is defined somewhere else... sorry, not sure.