Open Kleidukos opened 3 years ago
@Kleidukos thanks for filing. I'm at end of my day but will return tomorrow and set out all the API breaks I can think of, for discussion on how to proceed, and some rough ideas about the order in which to do things.
@Kleidukos sorry for the delay, I should manage to get to it in the next couple days.
OK, sorry it took so long. Rough plan:
Crypto.JOSE.Lens
. The module can be exposed. It's fine to only implement what jose actually uses.Control.Lens.Cons
stuff for a later step.Cons
or AsEmpty
, convert as suggested below (feel free to discuss). Because this is a breaking API change, the tests and example program may need updates too.Commits should follow the plan above, more or less.
Cons
and AsEmpty
conversions:
Crypto.JOSE.JWS.signature
: s
~ Data.ByteString.ByteString
Crypto.JOSE.JWS.signJWS
: s
~ Data.Bytestring.Lazy.ByteString
Crypto.JOSE.JWS.verifyJWS
, verifyJWS
and verifyJWSWithPayload
: s
~ Data.ByteString.Lazy.ByteString
Crypto.JOSE.JWK.fromOctets
: s
~ Data.ByteString
Crypto.JOSE.Types.Internal.base64url
: Either we split it into two prisms: one for strict ByteString
and one for lazy. Alternatively, define as a method of a new type class that provides the conversions, e.g. class Base64URL dec enc where base64url :: Prism' dec enc
with four instances (strict strict, strict lazy, lazy strict, lazy lazy). I think I prefer the second approach provides better (though imperfect) compatibility for existing code. Note the specific implementation for lazy, which we currently don't use: https://hackage.haskell.org/package/base64-bytestring-1.2.0.0/docs/Data-ByteString-Base64-URL-Lazy.html. Crypto.JWT.stringOrUri
: s
~ Data.Text.Text
Note that use of lazy ByteString where the payload is concerned does not match with how the JWS is defined. Specifically, the payload is stored as a Types.Base64Octets
, which is a newtype wrapper around strict ByteString. We can deal with this mismatch now (e.g. by defining a different newtype for lazy bytestring or abstracting Base64Octets
over the representation. Or feel free to punt on it and just do the conversions wherever necessary, and I will follow up later.
I probably missed some stuff and we will no doubt have more to discuss as the work gets tacked.
@frasertweedale I can't say I'm the most comfortable with the codebase, but if you're available for some pairing one day, I would love that. :)
After a discussion with @frasertweedale, it has been decided to explore available options to end the dependency on
lens
for the API, while still retaining the classy optics that are not moving anywhere soon. There is also a plan to get rid of TH for optics generation.Points to discuss: