Re: [OAUTH-WG] Relationship between SPICE and OAuth

[Hannes Tschofenig <[e-mail]>]

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 <[e-mail]> *On Behalf Of *Hannes Tschofenig
>>>> *Sent:* Wednesday, November 1, 2023 4:21 AM
>>>> *To:* oauth <[e-mail]>; [e-mail]
>>>> *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
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>> --
>>> Please use my new email address:[e-mail]
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
> --
> Please use my new email address:[e-mail]