Header flexibility

[markm77]

Hi there,

I have made local modifications (hacks) to support headers of the type

{
  "alg": "PS256",
  "typ": "JOSE",
  "kid": "xxx",
  "b64": false,
  "http://openbanking.org.uk/iat": 1573333614,
  "http://openbanking.org.uk/iss": "yyy/zzz",
  "http://openbanking.org.uk/tan": "openbanking.org.uk",
  "crit": [
    "b64",
    "http://openbanking.org.uk/iat",
    "http://openbanking.org.uk/iss",
    "http://openbanking.org.uk/tan"
  ]
}

but wondering if these could be supported in the library?

Maybe making headers a Swift protocol is the way to go?

Interested in your thoughts.

BR,
Mark

[markm77]

Any thoughts @djones6 ? 😀

[djones6]

@markfinlabs Let me start off by saying that I'm not an expert in the JWT/JWS/JOSE space. It looks like what you are after is a more general JWS library. I feel this goes beyond the intended scope of the Swift-JWT project, which was to support JWTs (as defined by RFC 7519).

Specifically, the JWT specification requires typ to be JWT, also (according to RFC 7797) the b64 header should not be used where a JWT is expected, as it would lead to errors or misinterpretation by JWT implementations that do not recognize it. The header is therefore intentionally restricted to just the fields a JWT might contain.

All that said, if you'd like to develop your changes into a broader JWS library, you'd be welcome to use this one as a starting point, and if you were to develop an API which is additive, I'd be happy to review a PR to add support for this (at which point it might make sense to rename this library, or create a 'Swift-JWS' library that 'Swift-JWT' is based upon).

[markm77]

Thanks @djones6 for your comments, I'll give this some thought and reply this week. I really appreciate the crypto support your library provides but I understand the need for scope limitations. I need to think if there is a simple way I can add something to your library or minor changes which might allow more external flexibility which i could propose. At the moment this is blocking my own software release so I'm motivated to see if there might be a solution.😀

[markm77]

Hi @djones6 . The most obvious change would be to turn Header into a protocol like Claims which would also have the benefit of allowing Header.encode() to overridable like Claims.encode().

However a better solution might be have both a protocol, say HeaderProtocol, as well as the current (now conforming) Header type to retain the simple syntax let myHeader = Header(kid: "keyID") which I suspect you won't want to lose. Only advanced users then need know about the existence of HeaderProtocol and the ability to use a custom Header type instead of Header.

If either of these solutions worked for you I'd be happy to prepare a pull request somehow?

[markm77]

Any thoughts on this @djones6 ?

[markm77]

I have made a pull request based on the HeaderProtocol option: #84

I welcome any thoughts.