Is lib still supported?

[shvez]

last update to library happened around year ago.

Are there plans to continue development?

[dvsekhvalnov]

Hi @shvez , any specific feature you are looking for?

RFC 7518 (JWA) was finalized in 2015 and not much updates since, so can't say there is backlog of new functionality.

We do provide bug fixes for security vulnerabilities when coming from research groups, minor enhancements time to time and some basic level assistance.

Also accepting PRs when make sense.

[shvez]

hi, @dvsekhvalnov I try long story short. We currently use JWT to carry some json data, later we are probably will use it to carry byte[]. Also token can sometimes be encrypted sometimes not. And also I add our header to headers to identify type of content. and last thing, I do not what to use any data (even our header) before signature check.

Having all that I would happy to use JWE.Decrypt but it does not work with non encrypted tokens. If we send bytes it does not make sense to use just JWT.Decode because instead if string I need byte[]. And after call to Decode I also need to call Headers to get my header (that already second time you have to parse headers - first through Decode)

What I want: It would be cool to get something like JweToken (result of JWE.Decrypt call) from JwtDecode. so that I call it once and have received data represented as byte[] and string with list headers and so on.

in this case I get all info and validation in one call.

Hope it is clear what I mean.

Currently I found this way of work: Jwt.DecodeBytes I get byte[] and validation. Now when I know that data are valid I read headers by Jwt.Headers call and depending on value of our header I either parse byte[] or convert it to string and parse JSON

[dvsekhvalnov]

Do you want Jwt.Decode to return both payload and headers ?

[shvez]

Now I believe I managed to formulate it for my self I would like to get next:

1. in one call:
   • validation
   • binary data
   • headers
2. it would be nice to get it in allocation free from, i.e. as struct

[shvez]

it might be that I'm asking too much, but we also could check whether it is possible to use inplace decryption. if case we need byte[] we will need to pass length or something like Memory struct, in case if we need to return payload as string it is transparent for users I have some experience with encryption/decryption. so, I could take a look

[dvsekhvalnov]

Can you sketch how it can look in code interface wise? Just a snippet you'd like to make real. Can be easier to understand.

[shvez]

public readon struct JwtDecodeBytesResult { public byte[] PayloadBytes[] {get;} public IDictionary Headers {get;}

//some other JWT stuff like in JweToken }

JwtDecodeBytesResult result = Jwt.DecodeBytes(jwtString, key);

Same way we could have Jwt.Decode. I would split those two cases for efficiency

[dvsekhvalnov]

JweToken - represents RFC7516 JWE JSON Serialization form.

There is JWS JSON Serialization aka RFC 7515 that is not supported in library. But i doubt you asking for it, that's different thing than compact serialization (3 or 5 parts separated with dots).

If you need both headers and payload - i'd just code a wrapper around library, it's really just 5 lines of code to get both and pack to the structure of choice. You can take a look at https://github.com/dvsekhvalnov/jose-jwt/tree/master#two-phase-validation for more ideas may be.

[shvez]

currently I do two calls: Jwt.DecodeBytes to validate data and get byte[] and after that I call Jwt.Headers to get headers.

During decoding library already parses headers and by call Jwt.Headers I do that work again. it would be cool to get it all in one go. for instance it can be Jwt.Decode[Bytes] with 'out' parameter 'headers'

this will be just a bit more efficient, no?

in two phase validation you read headers, get key, and call Decode, but decode again reads headers. Why?

[dvsekhvalnov]

Well, yes i guess returning both headers and payload is definitely little bit more efficient, but it is so micro optimization so i can't consider it enough to change library contract.

It just the way it was implemented XX years ago, probably was design mistake, but that's how it is. People complaining about even binary compatibility between versions, so changing contract is big no.

With 2 phase validation you don't trust headers until 2nd phase so anyway have to parse twice.

Think of it as library provides low level nuts & bolts of JWA/JWS/JWE mechanics and you can build higher-level abstractions on top to fit your use case.

[shvez]

ok, thank you. I see your point, although I'm not sure how adding new overloads might break existing clients