I think the key here is to make the existing document simpler, and advance it faster, with a smaller focus.
Another document can be added later, if there is interest in doing the work. OS On Sat, Nov 25, 2023 at 6:25 PM Tobias Looker <[email protected]> wrote: > Just to add some further commentary to this which I’ll say from the outset > certainly doesn’t leave me feeling strongly either way on the topic at the > moment. > > > > One of the key observations I see is that if we look at the design of JWS > and the fact that it supports two effective categories of cryptographic > algorithms, HMAC and asymmetric digital signatures, within the same > securing envelop which have different properties as an example of why it > perhaps wouldn’t be un-usual for JWP to consider both the salt and hash SD > scheme and signatures like BBS under the same envelop. I’m sure arguments > can be made for why that design isn’t favourable in certain situations, > which I think are what are being applied here now. But the tricky thing > about designing these sorts of contain formats is that the tent needs to be > big enough to actually be a tent and bifurcating things has a cost too. For > instance how would have the JWT world played out if syntactically there > were two classes of JWT’s? HMAC ones and asymmetric digital signature based > ones? > > > > Thanks, > > [image: MATTR website] <https://mattr.global/> > > > > *Tobias Looker* > > MATTR > > +64 273 780 461 > [email protected] <[email protected]> > > [image: MATTR website] <https://mattr.global/> > > [image: MATTR on LinkedIn] <https://www.linkedin.com/company/mattrglobal> > > [image: MATTR on Twitter] <https://twitter.com/mattrglobal> > > [image: MATTR on Github] <https://github.com/mattrglobal> > > > This communication, including any attachments, is confidential. If you are > not the intended recipient, you should not read it – please contact me > immediately, destroy it, and do not copy or use any part of this > communication or disclose anything about it. Thank you. Please note that > this communication does not designate an information system for the > purposes of the Electronic Transactions Act 2002. > > > > *From: *jose <[email protected]> on behalf of Brian Campbell > <[email protected]> > *Date: *Saturday, 11 November 2023 at 10:22 AM > *To: *Orie Steele <[email protected]> > *Cc: *JOSE WG <[email protected]> > *Subject: *Re: [jose] JWP focus/scope > > EXTERNAL EMAIL: This email originated outside of our organisation. Do not > click links or open attachments unless you recognise the sender and know > the content is safe. > > > > > > > > On Fri, Nov 10, 2023 at 1:53 PM Orie Steele <[email protected]> > wrote: > > Inline > > On Fri, Nov 10, 2023, 9:27 PM Brian Campbell <bcampbell= > [email protected]> wrote: > > I was rewarded for a comment in the meeting today* with an action item to > start a discussion on-list. So here I am with that. It's difficult (for me > anyway) to articulate some of this in writing, which is why I wanted to > voice it in the meeting. But that got redirected back to the list so here's > my attempt :) > > > > Basically my suggestion is/was that the JWP/JWA/JPT drafts should focus > only on container formats and support for the newer cryptographic > techniques, like BBS, that can provide both selective disclosure and > unlinkability. And not try to do something with "traditional" cryptography > and JWS that can only do selective disclosure. From my perspective it'd be > preferable to have the overall JWP container/abstraction provide a more > consistent set of security/privacy properties that doesn't vary by the > algorithm (that kind of variance has been a problem in JWS, for example, > where the same container can be asymmetrically signed, HMAC'd or not > protected at all). > > > > I agree. > > > > And I think it'd be good to have the general design be unencumbered by > considerations trying to retrofit or account for the "legacy" stuff. The > documents could be simplified (or at least made shorter and more focused) > too by removing the "Single Use JWP" concept that uses multiple JWS values > as well as the MAC JPA stuff. > > > > Move to a separate document? Or simply remove? > > > > Simply remove. In my view anyway. Selective disclosure alone is achievable > now with other things like SD-JWT. Let JWP focus on the newer stuff that > can't be done with other formats/containers. > > > > > > > > > > > > * which did also refer back to similar comments from the BoF @ IETF 114 > > https://mailarchive.ietf.org/arch/msg/jose/Qde04x9VqmhGavrlg2Gm_H54Zcc/ > > > > > > > *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] > https://www.ietf.org/mailman/listinfo/jose > > > *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.* > -- ORIE STEELE Chief Technology Officer www.transmute.industries <https://transmute.industries>
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
