Hi Daniel,
thanks for the detailed response. However, you answered a different
question.
I believe you had a very specific use cases in mind when you worked on
SD-JWT and that use case obviously didn't require COSE and CBOR.
Do you see a need for COSE/CBOR in your use case now?
Do you have other (maybe new) use cases that rely on COSE/CBOR?
As you can see, I am trying to find out whether there are real-world use
cases that require us to do this work or whether we just do it because
it can be done.
Ciao
Hannes
PS: A little bit of background for my questions: A few years ago the ACE
working group was formed, where several people from the IoT community
saw the need to standardize an authorization architecture. The idea was
to re-use OAuth but the OAuth selected encoding formats based on JSON
were seen as too "heavy" for IoT devices and networks. As a result,
everything was re-defined in CBOR/COSE. CWT was one of the outcome of
that work.
The idea was nice but the success was below my expectations.
Am 02.11.2023 um 13:23 schrieb Daniel Fett:
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> *On Behalf Of *Hannes Tschofenig
*Sent:* Wednesday, November 1, 2023 4:21 AM
*To:* oauth <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 list
OAuth@ietf.org
https://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
--
Please use my new email address:m...@danielfett.de
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
