[OAUTH-WG] Relationship between SPICE and OAuth

[Hannes Tschofenig]

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

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

[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  On Behalf Of Hannes Tschofenig
Sent: Wednesday, November 1, 2023 4:21 AM
To: oauth ; 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

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

[Brian Campbell]

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 
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
> OAuth@ietf.org
> 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._
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[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  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 <
> hannes.tschofe...@gmx.net> 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
>> OAuth@ietf.org
>> 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 communicati

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

[torsten=40lodderstedt . net]

Hi Hannes,
Am 1. Nov. 2023, 12:21 +0100 schrieb Hannes Tschofenig 
:
> 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**.
Have a missed a posting on this list where you have started a discussion with 
the WG of whether the drafts shall be moved into SPICE now? Otherwise I’m 
wondering about the tone of your post. It’s the WG that needs to decide on this 
topic, right? It’s not up to the WG chairs to do so.
>
> 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".
Absolutely. So let’s have a discussion in the WG.

best regards,
Torsten.
> ___
> 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

[OAUTH-WG] Missing IPR confirmations .... Re: IPR Disclosure - OAuth 2.0 Security Best Current Practice

[Hannes Tschofenig]

John & Andrey - please reply to my email below.


Ciao
Hannes


Am 04.10.2023 um 15:41 schrieb Tschofenig, Hannes:


Hi Daniel, Torsten, Andrey, John,

as part of the shepherd write-up, all authors of


must confirm that any and all appropriate IPR disclosures required for
full

conformance with the provisions of BCP 78 and BCP 79 have been filed.

Here is the draft:

draft-ietf-oauth-security-topics-23 - OAuth 2.0 Security Best Current
Practice


Please, reply to this email, on the mailing list, and indicate if you are

aware of any IPRs associated with this document.

Ciao

Hannes


___
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

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

[Hannes Tschofenig]

Hi Torsten,


Am 01.11.2023 um 17:43 schrieb tors...@lodderstedt.net:

Have a missed a posting on this list where you have started a
discussion with the WG of whether the drafts shall be moved into SPICE
now? Otherwise I’m wondering about the tone of your post. It’s the WG
that needs to decide on this topic, right? It’s not up to the WG
chairs to do so.


Because this is a decision that needs to be made by the participants I
am sending this email.


Ciao

Hannes


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Denis]

Hi Hannes,

The current charter of the OAuth WG is available at: 
https://datatracker.ietf.org/wg/oauth/about/


The major problem is that both this charter and the OAuth 2.1 (or OAuth 
2.0) authorization framework
cannot currently address the three roles model with an Holder, an Issuer 
and Verifier. In the three roles model,
there is no concept of a "resource owner ", nor of a "resource owner's 
consent".


Bridging the architectural narrative used in the core OAuth framework 
(AS, RS, RO) and in the three roles model

(Holder, Issuer, Verifier) would not be appropriate.

As Justin mentioned in https://oauth.net/articles/authentication/:

  "Remember, since OAuth is a delegation protocol, this is 
fundamental to its design".
  "In OAuth, the token is designed to be opaque to the client, but 
in the context of a user authentication,
   the client needs to be able to derive some information from the 
token".


The current draft from "The OAuth 2.1 Authorization Framework" states in 
section 1.4

(https://www.ietf.org/archive/id/draft-ietf-oauth-v2-1-09.html#name-access-token):

   "An access token is a string representing an authorization 
issued to the client.
    The string is considered opaque to the client, even if it has a 
structure".


When using selective disclosure, the access token cannot remain opaque 
to the client since it needs to be opened and modified by the client.
"Selective disclosure" is not a requirement: it is one mechanism that 
allows to support the privacy principle of "collection limitation",
i.e., limiting the collection of end-users attributes to that which is 
strictly necessary for the specified purpose(s).


However, "selectively disclosable claims" is only the tip of the "three 
roles model" iceberg, since other disclosure mechanisms, e.g., based on 
zero knowledge techniques
can be used and several privacy and security properties need to be 
considered. With some models, some properties can be supported, while 
with other models they can't.


The OAuth 2.0/2.1 framework cannot apply to a three roles model with an 
Holder, an Issuer and Verifier. Rather than working with document 
increments
based on the OAuth 2.0/2.1 framework, a re-chartering the OAuth working 
group would be necessary so that a framework tailored to the vocabulary

of three roles model could then be developed.

It should finally be noticed that the acronym of this WG, "OAuth", is a 
short for "Open Authorization". It is questionable whether that acronym 
or its meaning
would still be appropriate to address the three roles model which does 
not fit into the OAuth 2.0/2.1 framework.


Note: On the SPICE BoF mailing list, I raised an issue and proposed an 
alternative strawman proposal for the spice-charter
(https://github.com/transmute-industries/ietf-spice-charter/issues/3). I 
also sent several emails requesting changes to the wording of the 
proposed charter.
Please note that at this time, I don't agree with the current wording of 
the SPICE BoF charter.


Denis


Hi Hannes,
Am 1. Nov. 2023, 12:21 +0100 schrieb Hannes Tschofenig 
:


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 sc

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

[Dick Hardt]

I can't help myself to not reply to this ... :)

On Wed, Nov 1, 2023 at 11:18 AM Denis  wrote:

> 
>
> Bridging the architectural narrative used in the core OAuth framework (AS,
> RS, RO) and in the three roles model
> (Holder, Issuer, Verifier) would not be appropriate.
>

I'm not sure "would not be appropriate" is the right phrase, but I agree
that the models are different.



> It should finally be noticed that the acronym of this WG, "OAuth", is a
> short for "Open Authorization". It is questionable whether that acronym or
> its meaning
> would still be appropriate to address the three roles model which does not
> fit into the OAuth 2.0/2.1 framework.
>

OAuth is not short for anything. "OpenAuth" was originally proposed, but
Yahoo! was using that term at the time, so "OAuth" was picked.

The name of the WG is actually "Web Authorization Protocol"
https://datatracker.ietf.org/wg/oauth/about/

This does reinforce what I think is Denis' point -- this WG was chartered
for authorization protocol work -- not "identity" tokens.

/Dick
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] IPR Disclosure - OAuth 2.0 Security Best Current Practice

[isciurus]

Hannes,

I am not aware of any IPR related to this draft.

Andrey

On Wed, Oct 4, 2023 at 8:53 AM 
wrote:

> I am not aware of any IPR associated with this document.
> Am 4. Okt. 2023, 17:16 +0200 schrieb Daniel Fett  40danielfett...@dmarc.ietf.org>:
>
> I am not aware of any IPR associated with this document.
>
> -Daniel
> Am 04.10.23 um 17:10 schrieb Tschofenig, Hannes:
>
> In my earlier email I forgot to include John.
>
>
>
> John, I also need your confirmation!
>
>
>
> *Von:* OAuth   *Im
> Auftrag von* Tschofenig, Hannes
> *Gesendet:* Mittwoch, 4. Oktober 2023 15:41
> *An:* oauth@ietf.org
> *Betreff:* [OAUTH-WG] IPR Disclosure - OAuth 2.0 Security Best Current
> Practice
>
>
>
> Hi Daniel, Torsten, Andrey,
>
>
>
> as part of the shepherd write-up, all authors of
> 
>
> must confirm that any and all appropriate IPR disclosures required for full
>
> conformance with the provisions of BCP 78 and BCP 79 have been filed.
>
>
>
> Here is the draft:
>
> draft-ietf-oauth-security-topics-23 - OAuth 2.0 Security Best Current
> Practice
> 
>
>
>
> Please, reply to this email, on the mailing list, and indicate if you are
>
> aware of any IPRs associated with this document.
>
>
>
> Ciao
>
> Hannes
>
> ___
> 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
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth