This would basically involve creating a intermediary object that can create itself from the Paseto message format, and serialise itself back into it (that way we centralise the construction of messages away from individual implementations too). Then we can pass that to decrypt and verify methods, and it could be produced by encrypt and sign methods. The new PasetoMessage object in this PR is almost capable of being that intermediary object (sans a serialisation implementation).
The end result would be a little more verbose in PHP as you'd have to check the header validity manually where it matters (in the above implementation header correctness is enforced by choice of type parameters).
This is me basically just ripping this out in its PHP equivalent form
https://github.com/aidantwoods/swift-paseto/blob/f39f8a0c639c18fbeb417b4a52a5ff9c1115294d/Sources/Paseto/Blob.swift#L39-L54
I found it useful for creating a "take a peak at the header" convenience function, and it serves to basically do that here except for the footer (to avoid duplicating the parsing code). https://github.com/aidantwoods/swift-paseto/blob/f39f8a0c639c18fbeb417b4a52a5ff9c1115294d/Sources/Paseto/Util.swift#L24-L27
In-fact it also serves to separate message deconstruction from the validation specifics inherited by the parser object settings too.
If there is appetite, its possible to actually take this a little further and defer to a shared message deconstruction implementation within the protocols too, e.g. something like https://github.com/aidantwoods/swift-paseto/blob/f39f8a0c639c18fbeb417b4a52a5ff9c1115294d/Sources/Paseto/Implementations/Version2.swift#L58-L78
This would basically involve creating a intermediary object that can create itself from the Paseto message format, and serialise itself back into it (that way we centralise the construction of messages away from individual implementations too). Then we can pass that to
decryptandverifymethods, and it could be produced byencryptandsignmethods. The newPasetoMessageobject in this PR is almost capable of being that intermediary object (sans a serialisation implementation).The end result would be a little more verbose in PHP as you'd have to check the header validity manually where it matters (in the above implementation header correctness is enforced by choice of type parameters).
This also fixes the issue pointed out in https://github.com/paragonie/paseto/commit/2d3d70d102c58c7267f0544a8ed4218bbf53712b#r28076938 by @rlittlefield. Apparently the parser has somehow been getting away without having any test cases that have a footer in public mode 😆 (test cases filling this gap still need to be added)