I had an offlist chat with Mike, and he asked for me to share some summary here.
COSE has unprotected headers, and they are used to transfer certificate chains, counter signatures, and transparency receipts, among other things. JADES - https://www.etsi.org/deliver/etsi_ts/119100_119199/11918201/01.01.01_60/ts_11918201v010101p.pdf Also uses unprotected headers to transport things. If JWTs had unprotected headers, I suspect SD-JWT would have used them for the mutable part (disclosures). When you don't give a token format an unprotected bucket, they will just make one up later, when it is needed... using concatenation. I would prefer for JWP / CWP to have some shared structure, and to not end up with awkwardness if moving from a CWP to a JWP or vice versa. This means that if I started with CWP, and added receipts, counter signatures and certificate chains... I should be able to move to JWP without much trouble. In order to do this, there might be a need to trade off some size for extensibility... If size is a consideration, JSON and text encoding binary are already the wrong answers. Ideally both JWP and CWP would have the following structure: [ immutable secured data, security information, mutable data ] In COSE this applies to [ protected header, unprotected header, payload, signature ] (immutable secured data = protected header + payload), mutable data = unprotected header + signature In SD-JWT this applies to [ protected header, payload, disclosures, signature ] (immutable secured data = protected header + payload), mutable data = disclosures + signature Side note, yes, signatures are mutable... ES256K upper and lowerS, etc... If you don't specify a JSON Serialization for JWP, and people need extensibility like they have in cose unprotected headers, they will simply make up the JSON serialization they need when they need it. Maybe that's ok, but I think that some design planning and consideration of both JOSE and COSE can eliminate potentially awkward future workarounds like the ~ in sd-jwt or the json serialized jwt variant for it in JADES. I'd recommend creating the concept of a JWP unprotected header, putting the disclosures and other mutable information in there, and then having both a JSON and Compact serialization. In COSE, there won't be a need for both, but there will be a need to name the "text encoded binary" since cbor is often transmitting text encoded. As we built out SD-CWT, we used the unprotected header to transport the mutable data. As we built out COSE Receipts, we used the unprotected header to transport the merkle tree proofs, and to add them over time... we also use unprotected header to store cert chains so that a holder can add all the verification material needed by a verifier when they need it, and remove it when its not needed. If JWP Compact supports unprotected headers, I see no reason to not define a JSON serialization. If JWP Compact only means no unprotected header, I don't like the design, and I suspect it will lead to awkward text concatenation in the future. I'm in favor of a JSON Serialization, especially one that is conceptually aligned to the CBOR Object that will represent CWPs. Regards, OS On Wed, Aug 7, 2024 at 12:47 PM Brian Campbell <bcampbell= [email protected]> wrote: > Trying to take a bit of learning from history - the many JSON > serializations for JWS and JWE have, to the best of my knowledge, been very > scantily used or implemented in comparison to the popular compact > serializations. As such, I don't believe the JWP JSON Serialization is > needed. > > On Tue, Aug 6, 2024 at 5:42 PM Michael Jones <[email protected]> > wrote: > >> I’m writing to ask whether any of you have a use case that requires the >> JSON Web Proof JSON Serialization? Unless concrete reasons are provided to >> keep it, we propose to make the Compact Serialization the only JSON >> Serialization for JWPs. This is being tracked at >> https://github.com/ietf-wg-jose/json-web-proof/issues/100. >> >> >> >> Responses saying “I don’t need the JSON Serialization” are also welcomed. >> >> >> >> (A CBOR serialization is planned of course – something we hope to create >> before IETF 121 in Dublin, building on the work to use binary fields values >> in computations that we did prior to Vancouver.) >> >> >> >> Thanks, >> >> -- Mike & >> DW >> >> >> _______________________________________________ >> jose mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited. > If you have received this communication in error, please notify the sender > immediately by e-mail and delete the message and any file attachments from > your computer. Thank you.*_______________________________________________ > jose mailing list -- [email protected] > To unsubscribe send an email to [email protected] > -- ORIE STEELE Chief Technology Officer www.transmute.industries <https://transmute.industries>
_______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
