I agree, I don't think one should block the other. In our implementation of SD-CWT, we take advantage of the unprotected header for disclosures, this means we don't need new media types, we are also considering enabling selective disclosure of the header parameters, which would allow the payload to be dedicated to other media types.
I do think it's worth keeping as much the same as makes sense, and making improvements where we can. My sense from OAUTH is that CBOR is not a passion point for this group, and that in case SPICE does not form, it might be better to try to take sd-cwt to ACE which created CWTs in the first place. However, there are other items listed in the milestone deliverables for SPICE that are not existing OAUTH work items, and which are still worth accomplishing. In particular a profile of JWP in CBOR for Verifiable Credentials, and identity document work in CBOR building on the success of key thumbprints and confirmation, which have been solved essentially the same way in JOSE and COSE. In terms of aligning JOSE and COSE, I don't mind being a broken record that we have a responsibility to do this... Attempting it, keeps the differences useful to implementers, and keeps failures from one, like alg : none, out of the other. Trying to align things doesn't mean forcing alignment where it doesn't belong, but it will surface "gotchas" like how COSE has polymorphic algorithms and JOSE does not, and this breaks negotiation for protocols that want to upgrade... That's an example where the newer thing made worse choices than the older thing... This could happen for SD-CWT. Putting things together, in the same WG or in the same document, is a way to force alignment... But it's probably not necessary unless communication is not working and users will be harmed by the decisions being made... I'm getting the sense that OAUTH does not want to take on CBOR work, and does not want to give up JSON identity credential work based on JOSE. And I think that is a fine thing to put into the next charter. OS On Thu, Nov 2, 2023, 7:24 AM Daniel Fett <fett= 40danielfett...@dmarc.ietf.org> wrote: > Hi Hannes, > Am 02.11.23 um 12:46 schrieb Hannes Tschofenig: > > The question to the authors of the SD-JWT & related documents is: Does a > CBOR/COSE serialization provide value in your use cases? > > My point of view: It makes sense to define a format enabling SD for > CBOR/COSE, but it will be more than just a different serialization. We had > to make a number of choices for SD-JWT to reach the current format that is > optimized for security, ease of use and compactness. Many of these choices > were due to details of the encoding, e.g., the problems associated with > canonical representations of JSON, avoiding double-JSON encoding, avoiding > double-base64 encoding, the existing format for JWTs. > > I expect that, due to different features in the underlying format, a > CBOR-based solution will end up making very different trade-offs. This may > even extend to providing a different featureset. We therefore should not > strive to align SD-JWT and a CBOR-based solution as much as possible (or > even putting them in the same draft), but we should attempt to create the > best possible SD format for JOSE and, independently, the best possible SD > format for COSE. Otherwise we would create two mediocre formats. > > In that sense, I also don't see that SD-JWT should wait for a CBOR-based > draft to start or even longer. > > -Daniel > > > Ciao > > Hannes > > > > Am 02.11.2023 um 08:41 schrieb Daniel Fett: > > I second what my co-authors Kristina and Brian said. It is a risk, and > there are a lot of unknowns here. > > I have a similar feeling regarding SD-JWT VC, even though that is farther > away from the finish line. > > And as an attempt to explain some of the responses: I think the > communication here was less than ideal. Even if the authors of the drafts > may have no more say than anyone else, as you pointed out, getting them on > board with the idea before listing the drafts as "proposed work items" > would have helped. > > -Daniel > Am 01.11.23 um 15:54 schrieb Kristina Yasuda: > > Moving a somewhat mature draft to another WG is highly likely slow down > the progress on that document: there is no guarantee there will be an > overlap in the WG members, there is a risk that discussions that were > already resolved to be re-opened to be, etc. > > > > I consider SD-JWT closer to a finish line then a start line and would not > like its progress being slowed down by moving it to another WG at this > point of document's lifecycle. I am not in favor of moving SD-JWT work to > SPICE WG. > > > > Best, > > Kristina > > > > *From:* OAuth <oauth-boun...@ietf.org> <oauth-boun...@ietf.org> *On > Behalf Of *Hannes Tschofenig > *Sent:* Wednesday, November 1, 2023 4:21 AM > *To:* oauth <oauth@ietf.org> <oauth@ietf.org>; sp...@ietf.org > *Subject:* [OAUTH-WG] Relationship between SPICE and OAuth > > > > Hi all, > > > > I am a bit puzzled by the response Pam and I received when putting the > agenda for the SPICE BOF together. It appears that most people have not > paid attention to the discussions during the last few months. > > > > Let me try to get you up to speed. So, here is my summary. > > > > The OAuth working group has seen a lot of interest in the context of the > SD-JWT/VC work and there have been complaints about the three WG sessions > we scheduled at the last IETF meeting. (FWIW neither Rifaat nor I > understood why we received these complaints given that people asked us for > more slots. But that's another story...) > > > > The SD-JWT/VC work is architecturally different to the classical OAuth > (which is not a problem) but raises questions about the scope of the work > done in the OAuth working group, as defined by the charter. The charter of > a group is a "contract" with the steering committee (IESG) about the work > we are supposed to be doing. There is the expectation that the work > described in the charter and in the milestones somehow matches the work the > group is doing (at least to some approximation). See also the mail from > Roman to the OAuth list for the type of questions that surfaced: > https://mailarchive.ietf.org/arch/msg/oauth/a_MEz2SqU7JYEw3gKxKzSrRlQFA/ > > > > In time for the Prague IETF meeting a BOF request (with the shiny name > SPICE, see > https://datatracker.ietf.org/doc/bofreq-prorock-secure-patterns-for-internet-credentials-spice/) > was submitted. It was subsequently approved by the IESG. SPICE aims to > cover the scope of the SD-JWT/VC work (plus work on defining the CWT-based > counterparts) -- my rough summary; details are here: > https://github.com/transmute-industries/ietf-spice-charter/blob/main/charter.md > > > > This BOF request again raised questions about the scope and the > relationship with OAuth, see Roman's note here: > https://mailarchive.ietf.org/arch/msg/spice/Aoe86A0x6bezllwx17Xd5TOQ3Pc/ > > > > Now, we are in the final stages of preparing the BOF for the Prague IETF > and in the agenda preparation we repeately get asked the same question: > > > > "Has the transfer of some of the OAuth documents already been agreed?" > > > > The answer is "no". Nothing has been agreed. The purpose of the BOF is to > find this agreement. > > > > So, if you have an opinion whether some of the OAuth documents (in > particular draft-ietf-oauth-sd-jwt-vc, > draft-ietf-oauth-selective-disclosure-jwt, draft-ietf-oauth-status-list) > should move to a new working group then you should speak up **now**. > > > > The SPICE BOF (and the WIMSE BOF) will happen on Tuesday next week. The > first OAuth WG session happens shortly afterwards (also on Tuesday). The > outcome of the BOF(s) will guide us in our discussion about re-chartering > the OAuth working group (which is an item on the OAuth agenda, see > https://datatracker.ietf.org/meeting/118/materials/agenda-118-oauth-03). > > > > Rifaat, Pam and I are mediators in this process and therefore we rely on > your input. Since you have to do the work, you should think about where you > want to do it. > > > > Ciao > > Hannes > > > > PS: A process-related note. If you are author of a working group document > you are working for the group. With the transition from an individual > document to a working group document you have relinquished control to the > group. While your opinion is important, it has the same weight as the > opinion of any other working group participant. The theme is "We reject: > kings, presidents, and voting. We believe in: rough consensus and running > code". > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > > -- > Please use my new email address: m...@danielfett.de > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > > -- > Please use my new email address: m...@danielfett.de > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
