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

[Orie Steele <[e-mail]>]

That's just one example of what you can do with SD-CWT.

I think it's generally good form for IETF WGs to have very narrow charters,
but narrowing can take many forms:

RATS focuses on attestation use cases, but publishes documents that rely on
JOSE and COSE.

SCITT focuses on *software* supply chain use cases, but publishes documents
that only rely on COSE.

OAUTH focuses on authorization use cases, but publishes documents using
JOSE, COSE, and identity credentials (vc-sd-jwt).

At the beginning, when SPICE was forming, we talked about narrowing it in
the following ways:

1. SPICE will only work on CBOR
2. SPICE will only work on "Supply Chain Credentials"
3. SPICE will only work on "Personal Credentials''
4. SPICE will only work on JOSE and COSE based formats.
5. SPICE will not define protocols in the first charter

Then we asked the OAUTH list, would "identity credential work" move to
SPICE if it existed?

The answer from the OAUTH list was "maybe, but don't delay us".

Then later there were complaints that OAUTH felt like SPICE was delaying
the adoption of their work items.

Then OAUTH adopted all the work items that could have moved to SPICE.

Now that the work is adopted, moving it is just adding administrative delay.

My experience with SCITT has convinced me of a few things....

I think narrow charters help, but I think SCITT may have made some mistakes
by narrowing to "software" vs narrowing to "CBOR".

I don't see a need for SPICE to be narrowed to software supply chain use
cases and CBOR, any work that might fit that kind of charter can already be
done in SCITT or ACE.

Similarly I don't see a need for SPICE to be narrowed to "identity
credentials and JOSE", that work can already be done in OAUTH... apparently.

Should SPICE focus on "identity credentials / attribute certs and COSE"....
maybe.

Should SPICE focus on "identity credentials / attribute certs and JOSE &
COSE".... maybe.

^ this is the current framing in the draft charter, if that's not clear at
this point, allow me to repeat it....

The current SPICE charter frames the problem of JOSE and COSE related
groups awkwardly reinventing attribute certs, over and over again, in ways
that confuse developers, introduce security issues, or are just pointlessly
divergent for no benefit.

This problem is addressed by describing an architecture for attribute certs
that builds on IANA registries for JOSE and COSE, and the BCPs and other
security guidance.

In addition, new cryptographic building blocks, such as selective
disclosure, unlinkability, and identity document formats, are aligned so
that when divergence occurs it is for some benefit, and not simply because
the use case was rediscovered later, and the new authors never spoke to the
old authors.

Put another way.... If the next OAUTH charter adds support for working on
identity credentials / attribute certs in both JOSE and COSE.... SPICE
should not be formed.

If SPICE forms, the next OAUTH charter should not include COSE, and in my
opinion, the JOSE identity credential work can stay where it is, but there
are probably really good arguments for moving it out of OAUTH, so that
OAUTH can have a narrower charter... There is no reason to move things
around, unless people agree that it's beneficial.

I continue to think that use case based narrowing is "less helpful" than
"technology based narrowing"... If we could go back in time, I would have
made SCITT "cyber physical supply chain focused, with CBOR"... not
"software supply chain focused, with CBOR".

Even so, I think banning JOSE from SCITT also lost us lots of valuable
contributors with relevant expertise.

I think OAUTH will also lose valuable contributors by staying focused on
JOSE,
when I compare documents in ACE to documents in OAUTH, I wonder why they
are separate groups... but I have little exposure to ACE so far, and its
possible that "conciseness & compactness" deserves its own group.... I tend
to believe that everyone deserves conciseness and compactness.

Sorry this is such a long ramble, let me try to address your question one
last time.

Working groups should be focused on providing value to users, not
preserving transport and mediatype preferences for industry verticals.

OAUTH preserves HTTP and JOSE for web authorization (and authentication,
let's be honest) use cases.

ACE leverages HTTP and COSE for the same use cases.

When it comes to identity credentials / attribute certs 3.0 at IETF... I
think we should start by aligning JOSE and COSE.

That's the low hanging fruit, it's the problem I want to solve, because I
feel our customers should not have to choose between "compact & concise" vs
"easy to understand and use and well supported by industry".

Whatever decisions lead EAT to make the choices it made apply to SPICE.

RATS is not "attestation for people" or "attestation for software supply
chain" or "attestation for JOSE"... its "attestation built on IETF
standards".

OS



On Thu, Nov 2, 2023 at 9:25 AM Hannes Tschofenig <[e-mail]>
wrote:

> -- removing OAuth list
>
> Hi Orie, Hi all,
>
>
> good that we are now past the point of surprise. Hence, we can focus on
> finding out what work could be done in SPICE.
>
>
> The use case draft is content-wise empty but I noticed the post to the
> SCITT list yesterday:
> https://mailarchive.ietf.org/arch/msg/scitt/d3gs8VCQtk1Wmnp5vJ7oJBOaoGs/
>
>
> Could this be a driving use case for the SD-CWT draft?
>
>
> Ciao
>
> Hannes
>
>
> Am 01.11.2023 um 16:01 schrieb Orie Steele:
>
> I was also surprised to see this agenda, based on the discussions on OAUTH
> and SPICE lists.
>
> I am supportive of recapping, the great work that is happening at OAUTH,
> and how that work is applied outside of OAUTH to none OAUTH use cases.
>
> I don't think work items that are close to the finish line should be
> delayed, when we can all communicate effectively.
>
> OS
>
> On Wed, Nov 1, 2023 at 9:57 AM Brian Campbell <bcampbell=
> [e-mail]> wrote:
>
>> I didn't expect to see SD-JWT as a "proposed work item" on the SPICE BoF
>> agenda because its appropriateness to be and stay in the OAuth WG had been
>> discussed on list (e.g.,
>> https://mailarchive.ietf.org/arch/msg/oauth/6qjAsqLwyp5WoxqY3dVv8SJ5nVM/)
>> and SD-JWT wasn't mentioned in the SPICE BoF request
>> https://datatracker.ietf.org/doc/bofreq-prorock-secure-patterns-for-internet-credentials-spice/03/
>>
>> On Wed, Nov 1, 2023 at 5:21 AM Hannes Tschofenig <
>> [e-mail]> wrote:
>>
>>> 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
>>>
>>
>> *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.*--
>> SPICE mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/spice
>>
>
>
> --
>
>
> ORIE STEELE Chief Technology Officer www.transmute.industries
>
> <https://transmute.industries>
>
>

-- 


ORIE STEELE
Chief Technology Officer
www.transmute.industries

<https://transmute.industries>