Thank you Orie, this is a wonderful compendium of feedback, much of which can be directly incorporated.
I'll start working through it over the next week or so, filing issues as necessary and such. There's a bunch of repo tooling rework (the way the examples were generated/inserted needs to be redone) that myself and DW have been planning on as well at the current home of the drafts ( https://github.com/json-web-proofs/json-web-proofs). Jer On Wed, May 17, 2023 at 7:53 AM Orie Steele <[email protected]> wrote: > Inline: > > On Tue, May 16, 2023 at 10:33 PM John Mattsson <john.mattsson= > [email protected]> wrote: > >> Hi, >> >> >> The three adopted drafts have been uploaded with new names. >> >> >> >> https://datatracker.ietf.org/doc/draft-ietf-jose-json-proof-algorithms/ >> > > It would be nice to see an initial table for the requested registry > similar to how HPKE established registries: > > https://www.rfc-editor.org/rfc/rfc9180.html#name-algorithm-identifiers > https://www.rfc-editor.org/rfc/rfc9180.html#name-kem-identifiers > > Similarly for any new reserved claims ( such as pjwk ), it would be nice > to see them all in one place. > > Assume the reader has some awareness of JOSE, and introduce terms like > "issuer_header" and "presentation_header" > > so that they defined in their sections, for example: > > > https://datatracker.ietf.org/doc/html/draft-ietf-jose-json-proof-algorithms-00#name-presentation-protected-header-2 > > does not include "presentation_header" header. > > For single use JWS, it seems odd that the header value must be static, > since I assume that the alg used is recoverable... from the issuer > protected header... we all know why, but it's sorta sad here... there > should have been a way to learn the algorithm out of band... > https://www.rfc-editor.org/rfc/rfc7515#page-10 ... this will add a lot of > wasted bytes for large claim sets.... > > An example with a mixed algorithm for issue and holder would be nice here, > or a comment about it being forbidden... for example issuer signing with > ES256 and holder presenting with EdDSA. > > I find myself really wanting JSON and base64url encoded examples as I read > this, the section on BBS is much easier to understand because of the > examples. > > The mac section has the same issue as the su section, repeating a static > header: > > jws_header = '{"alg":"ES256"}' > > The MAC section took a few reads to understand, diagrams would help here. > > The snark section adds nothing currently, and given the scope / breadth > and maturity of these 3 drafts, I suggest it be dropped and the focus be on > the 3 existing schemes. > > >> https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-proof/ >> > > I didn't really learn anything new from this document, after reading the > first one, > > You might want to change https://issuer.tld to issuer.example, similar > updates to other example email addresses... > > In the proof_jwk and presentation_jwk, perhaps some comments on > constraining keys using "alg"... I find myself wondering which keys are for > ES256 and which ones are for SU-ES256, alg remains optional in JWK, but it > would help explain the relationships here... > > BTW the merkle disclosure proofs work as moved to an I-D: > > https://datatracker.ietf.org/doc/draft-steele-cose-merkle-tree-proofs/ > > We have a section on multiple disclosure proofs: > > > https://ietf-scitt.github.io/draft-steele-cose-merkle-tree-proofs/draft-steele-cose-merkle-tree-proofs.html#name-signed-multiple-inclusion-p > > I prepared an implementation of RFC9162 to support this recently: > https://github.com/transmute-industries/rfc9162 > > That being said, I suggest maybe not addressing merkle proofs in the first > version of JWP, and focus on supporting the 3 JPA in the algorithms draft. > > >> https://datatracker.ietf.org/doc/draft-ietf-jose-json-proof-token/ >> > > This document is extremely light.... It would be nice to see: > > 1. complete JPT examples for 3 algorithms > 2. appendix / use case commentary on why not COSE Sign 1 / JWS / JWT... > > I know there has been lots of discussion on point 2, it would be good to > see it reflected in this document. > > Which registry will contain "claims", is there generic language that can > be written for explaining how: > > https://www.iana.org/assignments/jose/jose.xhtml > > registry entries are interpreted in these drafts? > > For example, JWK is being shared... but the "alg" values might not match > up for SU-ES256 vs ES256 etc... > > Another thought, can the recursive destructing algorithm from SD-JWT be > used here? > > It might be nice to not have to think in terms of arrays, the original JWT > claim set was an object, not an array. > > Thanks for taking the time to put these documents together, I hope I can > be of further assistance. > > >> >> It would be very welcome with reviews and comments on the drafts. I don’t >> think we have gotten any comments so far except that they should be adopted. >> >> It would also be very welcome if someone starts “An Informational >> document detailing Use Cases and Requirements for new specifications >> enabling JSON-based selective disclosure and zero-knowledge proofs.” in >> some form. >> >> Cheers, >> John >> >> >> >> *From: *John Mattsson <[email protected]> >> *Date: *Thursday, 20 April 2023 at 08:23 >> *To: *[email protected] <[email protected]> >> *Subject: *Re: Calls for adoption: Web Proof Drafts >> >> Dear JOSE, >> >> >> >> I have not talked to my co-chairs but it is obvious that there is >> overwhelming support to adopt the three Web Proof Drafts. The results in >> the IETF 116 session and on the list were unanimous in favor of adopting >> the three drafts. >> >> >> >> Authors, please rename the I-D to and resubmit as >> >> >> >> draft-ietf-jose-json-web-proof-00 >> >> draft-ietf-jose-json-proof-algorithms-00 >> >> draft-ietf-jose-json-proof-token-00 >> >> >> >> John Preuß Mattsson (for the three jose chairs) >> >> >> >> *From: *jose <[email protected]> on behalf of Brent Zundel >> <[email protected]> >> *Date: *Wednesday, 29 March 2023 at 16:18 >> *To: *Karen O'Donoghue <[email protected]>, >> [email protected] <[email protected]> >> *Subject: *Re: [jose] Calls for adoption: Web Proof Drafts >> >> I support adoption and volunteer to review and help write. >> >> >> >> Sent from my T-Mobile 5G Device >> Get Outlook for Android <https://aka.ms/AAb9ysg> >> ------------------------------ >> >> *From:* jose <[email protected]> on behalf of Karen O'Donoghue >> <[email protected]> >> *Sent:* Tuesday, March 28, 2023 12:54:06 PM >> *To:* [email protected] <[email protected]> >> *Subject:* [jose] Calls for adoption: Web Proof Drafts >> >> >> >> jose working group… >> >> >> >> Yesterday during the jose meeting @ IETF 116, we did a consensus call on >> the adoption of the three web proof drafts: >> >> JSON Web Proofs >> https://datatracker.ietf.org/doc/draft-jmiller-jose-json-proof-algorithms/ >> JSON Proof Algorithms >> https://datatracker.ietf.org/doc/draft-jmiller-jose-json-proof-algorithms/ >> JSON Proof Token >> https://datatracker.ietf.org/doc/draft-jmiller-jose-json-proof-token/ >> >> The result was unanimous in favor of adopting the three drafts. With this >> message, I am asking the mailing list for any thoughts on adopting these >> three drafts. This call will close on Wednesday 19 April. >> >> >> >> Also, this is an excellent time to read the drafts and start providing >> comments. >> >> >> >> Karen (for the three jose chairs) >> _______________________________________________ >> jose mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/jose >> > > > -- > *ORIE STEELE* > Chief Technical Officer > www.transmute.industries > > <https://www.transmute.industries> > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose >
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
