Re: [OAUTH-WG] OAuth and JWT/VC documents

[Giuseppe De Marco]

Ciao Rifaat

I can say in the vest of an implementer, that VC documents are like
unrequited love, you know you need it but it's not something you can build
on.

Here I represent many organizations that are working to build on these,
with deadlines.

I express my strong support for these brand new specs, since I Need them
and I share the vision behind them. All about how these can became reality
would be search and found in a OAuth WG that would show how this would be
then possible.

I support the adoption and I'm implementing the so called vcstuff drafts

Il ven 29 set 2023, 20:16 Rifaat Shekh-Yusef  ha
scritto:

> There are two reasons for not calling for the adoption of this document:
> 1. The SPICE discussion, which gave the impression that the plan is to
> migrate this to a new dedicated WG.
> 2. Some people questioned whether this is in scope or not.
>
> If the first one is not an issue, and there is no plan to migrate this to
> a different WG, then we can definitely start a call for adoption and see
> what happens.
>
> Regards,
>  Rifaat
>
>
> On Fri, Sep 29, 2023 at 1:42 PM Kristina Yasuda  40microsoft@dmarc.ietf.org> wrote:
>
>> +1 to Brian’s and Orie’s observations.
>>
>>
>>
>> During last IETF, a question was asked whether
>> draft-looker-oauth-jwt-cwt-status-list draft is (or [*]) is in scope of
>> OAuth WG charter or not. A lot of comments observed that it is because as
>> Brian has succinctly put it “a general JWT status/revocation mechanism (as
>> defined in this draft) would fall easily within the remit of the WG as is”.
>>
>>
>>
>> I also agree that it seems that focus has been unintentionally shifted
>> away from working on this status list draft, which there is an interest and
>> a need from the implementers to work on it. It would be great if we can
>> discuss and agree whether this draft is in scope for oauth wg or not and if
>> so whether we can start the call for adoption.
>>
>>
>>
>> Best,
>>
>> Kristina
>>
>>
>>
>> *From:* Orie Steele 
>> *Sent:* Friday, September 29, 2023 10:35 AM
>> *To:* Brian Campbell 
>> *Cc:* Torsten Lodderstedt ; torsten=
>> 40lodderstedt@dmarc.ietf.org; Kristina Yasuda <
>> kristina.yas...@microsoft.com>; oauth ; Paul Bastian <
>> paul.bast...@bdr.de>; Christian Bormann <
>> christiancarl.borm...@de.bosch.com>
>> *Subject:* Re: [OAUTH-WG] OAuth and JWT/VC documents
>>
>>
>>
>> Inline:
>>
>>
>>
>> On Fri, Sep 29, 2023 at 12:05 PM Brian Campbell <
>> bcampb...@pingidentity.com> wrote:
>>
>>
>>
>> If I might offer an observation...
>>
>>
>>
>> The draft-looker-oauth-jwt-cwt-status-list draft is (or can easily be[*])
>> really just a generic status/revocation checking mechanism for JWTs in
>> general. Given the history/lineage of JWT development within the OAuth WG,
>> it seems like a general JWT status/revocation mechanism would fall easily
>> within the remit of the WG as is.
>>
>>
>> I agree with this.
>>
>>
>>
>>
>> It seems to me as though the prospect of the formation of a new WG from
>> the potential SPICE BoF that may or may not be a suitable future forum for
>> the status list work has unintentionally delayed or diverted
>> attention around consideration of the status list work being adopted and
>> progressed in OAuth in the more near term.
>>
>>
>>
>>
>> Speaking as a contributor to SPICE BoF, this was certainly never my
>> intention.
>>
>> I don't think work should be delayed if it is well solved within an
>> existing working group, and I agree that status lists are relevant to JWT
>> and CWT generally, not just credentials.
>>
>>
>>
>>
>> [*] it has some open TODOs for CWT based representations but no actual
>> content as such, which could be removed to focus the scope of the draft.
>>
>>
>>
>>
>> +1
>>
>>
>>
>>
>>
>>
>> On Tue, Sep 19, 2023 at 1:56 PM Orie Steele 
>> wrote:
>>
>> Excellent.
>>
>> Inline:
>>
>>
>>
>> On Tue, Sep 19, 2023 at 2:12 PM  wrote:
>>
>> Hi Orie,
>>
>>
>>
>> best regards,
>>
>> Torsten.
>>
>> Am 18. Sept. 2023, 16:01 +0200 schrieb Orie Steele <
>> orie@transmute.industries>:
>>
>> Torsten,
>>
>> Thanks for sharing this excellent framing.
>>
>> I agree with everything you said.
>>
>> Please correct me if I'm wrong about anything in this summary:
>>
>> 1. Keep working on JWT based credential formats at OAuth (implicit, don't
>> expand OAuth charter to work on CWT credential formats ?)
>>
>> yes
>>
>> 2. If a new working group (SPICE) is formed focused on credentials,
>> authors are open moving credential specific work items there, and don't
>> plan new credential related items at OAuth.
>>
>> We are open to move the credential work to a new working group. We are
>> open to discuss whether that will be SPICE, so far it seems to be COSE
>> centric. It’s clearly in everyone’s interest to have the JSON and COSE
>> based credential formats aligned.
>>
>>
>> I agree, I think a big part of this comes from trying to respect the work
>> that has already happened, in JSON-LD at W3C and JSON / JOSE at OAuth and
>> OIDF.
>>
>>
>> 

Re: [OAUTH-WG] OAuth and JWT/VC documents

[Giuseppe De Marco]

Hi,

I'm fashinated by these interpretation processes. It sounds resonable
having mapped the OAuth roles in three types:

Issuer or AS
Holder or Client
Verifier or RP

even if we try to keep things simple the real world continuosly breaks the
plans (as in the society the genders ...).

We often forget the User, that sometimes assumes the role of the "resource
owner"; and not at least the TTP, the trusted third party, whatever it
express in our minds, since trust still seems an abstract, or
controversial,  strategy, more sociological than ... Look, It Is everywhere
but still on the edge of the OAuth literature!

Anyway the challenge doesn't stop here, since in the Wallet ecosystem the
roles ends with swapping and mixing up, depending by the context, eg:

The holder became an AS during the presentation phase.

As in the biological, economics and sociological sciences, the diversity is
still the most important feature that allows a system to evolve, I believe
that the OAuth2 ecosystem with its solid roots Is the best place where this
diversity can be welcome. This Is also for the future of OAuth2 I believe.

I agree all the concerns about how the things are getting inflated and the
entropy increased losing the quality: everybody knows.

There might be the plan, or the vision, to merge some drafts together to
give the baseline for a complete architecture with well defined and
harmonized roles and features?

Il sab 9 set 2023, 15:44 Denis  ha scritto:

> Historically, the OAuth WG has been using a model including five
> components: the user, the Client, the AS, the RO and the RS.
>
> The model applicable in the context of the "three part model (issuer,
> holder, verifier)" is rather different since there is no AS, nor RO.
> An AS should not be confused with an Issuer. An Issuer has no relationship
> with a verifier.
>
> In the "three part model", a Credential is issued by an Issuer to an
> holder who may then derive himself from it one or more Verifiable
> Presentations
> without any call-back to the Issuer. The holder may then present to a RS
> one or more Verifiable Presentations derived from Credentials issued
> by the same or different Issuers. It is implicit that the "three part
> model" shall support selective disclosure of the holder's attributes.
>
> The "three part model (issuer, holder, verifier)" involves more entities /
> components: the user, the TEE (Trusted Execution Environment)
> supported by the smart phone or tablet manufacturer, Trusted Applications
> (TAs) placed into the TEE, the providers of these Trusted Applications
> (TAs)
> and the RichOS supported by the smart phone or tablet. Security and
> privacy concerns can only be achieved while considering the whole chain.
>
> The protocols between an holder and a verifier are rather different from
> those defined din OAuth, since in many cases they support Zero-Knowledge
> proofs (ZKPs).
>
> Before designing an architecture, it is important to raise the following
> questions:
>
>- Is it desirable to support linkability between verifiers and/or
>unlinkability between verifiers ?
>- How to bind a Verifiable Presentation to its legitimate holder while
>also supporting the unlinkability property between verifiers ?
>
> IMO, bridging the architectural narrative used in the core OAuth framework
> (AS, RS, RO) and three part model (issuer, holder, verifier) is not
> desirable.
> This would add confusion. Extending the OAuth charter to address the "three
> part model" is not desirable.
>
> Some committees and foundations are already addressing this topic, e.g.,
> W3C, OpenID, DIF (Decentralized Identity Foundation) and GlobalPlatform
> (for the TEE).
>
> The key question is: what the IETF should do (*or not do)* in this area ?
>
> A BoF should be opened to continue this discussion.
>
> Denis
>
> Thanks for kicking off the conversation!
>
> Inline:
>
> On Fri, Sep 8, 2023 at 2:08 PM Roman Danyliw  wrote:
>
>> Hi!
>>
>> We've observed growing energy around JWT, selective disclosure and VC
>> related topics in the WG in recent meetings.  We spent almost all of the
>> third OAuth meeting at IETF 117 on related topics.  The initial SD-JWT
>> (draft-ietf-oauth-selective-disclosure-jwt) has been followed up with
>> SD-JWT-VC (draft-ietf-oauth-sd-jwt-vc).  There is also work like
>> draft-looker-oauth-jwt-cwt-status-list being proposed.
>>
>> As promised at IETF 117, we would like to start a conversation about the
>> direction the WG would like to take at a strategic level rather than
>> continuing to deal this topic in one document increments of additional
>> scope.
>>
>> ** What's the body of work around SD/JWT/VC that should be done and how
>> much work will that be?  What needs to be done first?  What unknown about
>> the direction and needed tasks?
>>
>>
> There are building blocks that "look like VC" but are actually vanilla JWT
> / relevant outside the 3 party model. I would recommend keeping them at
> OAuth (status list cwt is an 

Re: [OAUTH-WG] Review of draft-ietf-regext-rdap-openid

[Roman Danyliw]

Hi Justin!

Thank you so much for the review!

Roman

From: Justin Richer 
Sent: Thursday, September 28, 2023 7:46 PM
To: Roman Danyliw 
Cc: oauth 
Subject: Re: [OAUTH-WG] Review of draft-ietf-regext-rdap-openid

Hi Roman,

The concerns of this document are largely specific to OpenID Connect, and not 
vanilla OAuth, but of course many of us in the community overlap and I’m happy 
to help provide some feedback here. I’m not familiar with RDAP, so if any of my 
concerns are addressed by other aspects of the RDAP ecosystem, I would be happy 
to be corrected.

That said, I believe parts of the approach are fundamentally flawed as it 
conflates the RS and client roles in a potentially dangers and certainly 
confusing way.

Some thoughts as I read through this:


§3.2.1:

 - there seems to be some conflation of the RP and RS roles here in the RDAP 
server; it seems more proper that the RDAP server is the RS, and the RDAP 
client is the RP (the same as the OAuth client); this seems to stem from a 
problem with how the RDAP server actually gets user claims, see paragraph below 
for more

§3.1.3:

 - this seems to assume the authorization code grant type; though this is 
explained a little bit more in 3.1.4.2, it’s not clear that other grant types 
are supported here within this protocol
 - the first section on “session-oriented clients” conflates the end-user with 
the client (to wit: "An RDAP client (acting as an OpenID End-User)”); 
consequently it’s unclear who is getting “redirected” or interacting at any 
step; more properly, it seems that the end-user is interacting with the RDAP 
client to initiate the flow, which is borne out in the diagram

More importantly, in this section it becomes clear that the core of the 
specification’s “token-oriented” approach relies on the RDAP client passing the 
access token to the RDAP server and then having the RDAP server replay that 
same token to the OpenID IdP in order to get user claims. It is not considered 
good practice to have the RS replay the access tokens it receives to an 
external party, and on the surface this could potentially be exploited by an 
attacker. This also fails under sender-constrained token usage, wherein the 
RDAP client would need to also share key material with the RDAP server in order 
for the latter to use the token.

A better pattern would be a profile of OAuth Token Introspection (RFC7667) 
wherein user information could be specified. This would also allow the RDAP 
server to authenticate its call to the OpenID IdP. Introspection was designed 
specifically to allow the RS to call back to the AS to determine what (and who) 
a token is for, and it provides an extensible mechanism for doing so. An 
alternative would be to profile the access token itself to contain user 
information in a format readable by the RDAP server. More on this in the note 
for §6.3 below.

§3.1.5.1

- The registry information here should be in a separate IANA section that is 
forward-referenced from here
- which parties are responsible for validating the allowed purposes claims? 
Does the IdP need to know the list of allowed purposes applicable to the RS 
(RDAP server)?

§4.1

 - I appreciate that the fav1 data structure separates the applicable flags 
into a clear substructure, which will be easier to process as an extension to 
existing code

§4.2

- RFC3986 doesn’t actually specify the key=value format normatively; these 
days, that belongs to the HTML URL specification from WHATWG and so I would 
recommend that this reference be used instead: 
https://url.spec.whatwg.org/#application/x-www-form-urlencoded


§4.2.1

 - is it really the case that a client can only request a single purpose, but 
multiple can be authorized? I’m not an expert in the RDAP world, but this would 
seem to be quickly turn insufficient as purposes are not required to be 
completely separate and distinct from each other in the registration section

§4.3

- I think this section was probably meant to be a subsection of 4.2?

§5.1.1

 - OpenID Connect does not define a single global string value for a user 
identifier; instead only the tuple of issuer and subject are considered 
suitably unique; ergo, the UserID value in the data structure would need to 
have either a construction method or some other specification, or to have this 
declared as RDAP-server-specific explicitly

§5.1.2

 - this seems to replicate RFC8628, OAuth Device Flow, without any of the 
implementation detail or security considerations of that specification; 
furthermore, the device flow isn’t specified in OpenID Connect (which is being 
profiled here) though its use is far from unheard of in practice; this use is 
further expanded in §5.2.4, but it’s unclear that that’s why this is here

§5.2.1

 - I’m unclear when reading this whether the identifier in question is an OAuth 
client_id or a user identifier, as the text seems to indicate it can be either; 
these represent drastically different 

[OAUTH-WG] Requesting a reviews of SD-JWT based W3C Verifiable Credentials

[Orie Steele]

Hello,

As some of you are aware, W3C defines a JSON-LD Verifiable Credential
format which supports the "3 role model".

The working group is currently developing several documents relevant to
OAuth, that profile on top of SD-JWT.

The primary ones I am reaching out regarding are:

https://w3c.github.io/vc-data-model (the core date model defined in JSON-LD)
https://w3c.github.io/vc-jose-cose (securing JSON payloads with SD-JWT and
Cose Sign 1)
https://w3c.github.io/vc-json-schema (validating json payloads with JSON
Schema)
https://w3c.github.io/vc-status-list-2021 (validating credential statuses
with bitmaps)

The latest drafts at W3C recommend SD-JWT as the primary mechanism to
secure credentials, when not performing RDF canonicalization during the
sign and verify operations.

This means we expect to see the following examples in the specifications:

1. Examples of securing a verifiable credential with selective disclosure
2. Examples of securing a verifiable presentation with selective disclosure
3. Examples of securing a verifiable credential "status list" with
selective disclosure
4. Examples of securing a verifiable credential "json schema" with
selective disclosure

As far as I know, sd-jwt examples are missing from all specs except for
https://w3c.github.io/vc-jose-cose .

If you have time to review any of these documents, I would appreciate your
feedback.

I am especially concerned on maintaining alignment between
https://w3c.github.io/vc-jose-cose and
https://datatracker.ietf.org/doc/draft-ietf-oauth-sd-jwt-vc

This alignment is especially critical given other work happening at W3C
related to browser APIs and identity credentials:

https://github.com/WICG/identity-credential/blob/main/identity-credential-proposal.md#w3c-verifiable-credentials

Regards,

OS

-- 


ORIE STEELE
Chief Technology Officer
www.transmute.industries


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

Re: [OAUTH-WG] OAuth and JWT/VC documents

[Rifaat Shekh-Yusef]

There are two reasons for not calling for the adoption of this document:
1. The SPICE discussion, which gave the impression that the plan is to
migrate this to a new dedicated WG.
2. Some people questioned whether this is in scope or not.

If the first one is not an issue, and there is no plan to migrate this to a
different WG, then we can definitely start a call for adoption and see
what happens.

Regards,
 Rifaat


On Fri, Sep 29, 2023 at 1:42 PM Kristina Yasuda  wrote:

> +1 to Brian’s and Orie’s observations.
>
>
>
> During last IETF, a question was asked whether
> draft-looker-oauth-jwt-cwt-status-list draft is (or [*]) is in scope of
> OAuth WG charter or not. A lot of comments observed that it is because as
> Brian has succinctly put it “a general JWT status/revocation mechanism (as
> defined in this draft) would fall easily within the remit of the WG as is”.
>
>
>
> I also agree that it seems that focus has been unintentionally shifted
> away from working on this status list draft, which there is an interest and
> a need from the implementers to work on it. It would be great if we can
> discuss and agree whether this draft is in scope for oauth wg or not and if
> so whether we can start the call for adoption.
>
>
>
> Best,
>
> Kristina
>
>
>
> *From:* Orie Steele 
> *Sent:* Friday, September 29, 2023 10:35 AM
> *To:* Brian Campbell 
> *Cc:* Torsten Lodderstedt ; torsten=
> 40lodderstedt@dmarc.ietf.org; Kristina Yasuda <
> kristina.yas...@microsoft.com>; oauth ; Paul Bastian <
> paul.bast...@bdr.de>; Christian Bormann <
> christiancarl.borm...@de.bosch.com>
> *Subject:* Re: [OAUTH-WG] OAuth and JWT/VC documents
>
>
>
> Inline:
>
>
>
> On Fri, Sep 29, 2023 at 12:05 PM Brian Campbell <
> bcampb...@pingidentity.com> wrote:
>
>
>
> If I might offer an observation...
>
>
>
> The draft-looker-oauth-jwt-cwt-status-list draft is (or can easily be[*])
> really just a generic status/revocation checking mechanism for JWTs in
> general. Given the history/lineage of JWT development within the OAuth WG,
> it seems like a general JWT status/revocation mechanism would fall easily
> within the remit of the WG as is.
>
>
> I agree with this.
>
>
>
>
> It seems to me as though the prospect of the formation of a new WG from
> the potential SPICE BoF that may or may not be a suitable future forum for
> the status list work has unintentionally delayed or diverted
> attention around consideration of the status list work being adopted and
> progressed in OAuth in the more near term.
>
>
>
>
> Speaking as a contributor to SPICE BoF, this was certainly never my
> intention.
>
> I don't think work should be delayed if it is well solved within an
> existing working group, and I agree that status lists are relevant to JWT
> and CWT generally, not just credentials.
>
>
>
>
> [*] it has some open TODOs for CWT based representations but no actual
> content as such, which could be removed to focus the scope of the draft.
>
>
>
>
> +1
>
>
>
>
>
>
> On Tue, Sep 19, 2023 at 1:56 PM Orie Steele 
> wrote:
>
> Excellent.
>
> Inline:
>
>
>
> On Tue, Sep 19, 2023 at 2:12 PM  wrote:
>
> Hi Orie,
>
>
>
> best regards,
>
> Torsten.
>
> Am 18. Sept. 2023, 16:01 +0200 schrieb Orie Steele <
> orie@transmute.industries>:
>
> Torsten,
>
> Thanks for sharing this excellent framing.
>
> I agree with everything you said.
>
> Please correct me if I'm wrong about anything in this summary:
>
> 1. Keep working on JWT based credential formats at OAuth (implicit, don't
> expand OAuth charter to work on CWT credential formats ?)
>
> yes
>
> 2. If a new working group (SPICE) is formed focused on credentials,
> authors are open moving credential specific work items there, and don't
> plan new credential related items at OAuth.
>
> We are open to move the credential work to a new working group. We are
> open to discuss whether that will be SPICE, so far it seems to be COSE
> centric. It’s clearly in everyone’s interest to have the JSON and COSE
> based credential formats aligned.
>
>
> I agree, I think a big part of this comes from trying to respect the work
> that has already happened, in JSON-LD at W3C and JSON / JOSE at OAuth and
> OIDF.
>
>
> 3. Coordinate with CBOR based credential formats (wherever they may be) to
> ensure that architecture and conventions are as aligned as possible
>
> yes
>
>
> Happy to help however I can, regardless of where work items land.
>
> Let’s talk about how we can bring the COSE and JSON credential work
> together.
>
>
>
> Awesome, I think the most impactful way to achieve this would be adding a
> sentence like this to the SPICE BoF request, something to the effect of:
>
> The following documents would be transitioned from OAuth to SPICE if the
> WG forming BoF is successful.
>
> - draft-ietf-oauth-sd-jwt-vc
> - draft-looker-oauth-jwt-cwt-status-list
>
> It's debatable if the status list work item should move, since I see that
> as a generic token format that has applications beyond credentials.
>
> However, if authors 

Re: [OAUTH-WG] OAuth and JWT/VC documents

[Kristina Yasuda]

+1 to Brian’s and Orie’s observations.

During last IETF, a question was asked whether 
draft-looker-oauth-jwt-cwt-status-list draft is (or [*]) is in scope of OAuth 
WG charter or not. A lot of comments observed that it is because as Brian has 
succinctly put it “a general JWT status/revocation mechanism (as defined in 
this draft) would fall easily within the remit of the WG as is”.

I also agree that it seems that focus has been unintentionally shifted away 
from working on this status list draft, which there is an interest and a need 
from the implementers to work on it. It would be great if we can discuss and 
agree whether this draft is in scope for oauth wg or not and if so whether we 
can start the call for adoption.

Best,
Kristina

From: Orie Steele 
Sent: Friday, September 29, 2023 10:35 AM
To: Brian Campbell 
Cc: Torsten Lodderstedt ; 
torsten=40lodderstedt@dmarc.ietf.org; Kristina Yasuda 
; oauth ; Paul Bastian 
; Christian Bormann 
Subject: Re: [OAUTH-WG] OAuth and JWT/VC documents

Inline:

On Fri, Sep 29, 2023 at 12:05 PM Brian Campbell 
mailto:bcampb...@pingidentity.com>> wrote:

If I might offer an observation...

The draft-looker-oauth-jwt-cwt-status-list draft is (or can easily be[*]) 
really just a generic status/revocation checking mechanism for JWTs in general. 
Given the history/lineage of JWT development within the OAuth WG, it seems like 
a general JWT status/revocation mechanism would fall easily within the remit of 
the WG as is.

I agree with this.


It seems to me as though the prospect of the formation of a new WG from the 
potential SPICE BoF that may or may not be a suitable future forum for the 
status list work has unintentionally delayed or diverted attention around 
consideration of the status list work being adopted and progressed in OAuth in 
the more near term.


Speaking as a contributor to SPICE BoF, this was certainly never my intention.
I don't think work should be delayed if it is well solved within an existing 
working group, and I agree that status lists are relevant to JWT and CWT 
generally, not just credentials.


[*] it has some open TODOs for CWT based representations but no actual content 
as such, which could be removed to focus the scope of the draft.


+1



On Tue, Sep 19, 2023 at 1:56 PM Orie Steele 
mailto:orie@transmute.industries>> wrote:
Excellent.

Inline:

On Tue, Sep 19, 2023 at 2:12 PM 
mailto:tors...@lodderstedt.net>> wrote:
Hi Orie,

best regards,
Torsten.
Am 18. Sept. 2023, 16:01 +0200 schrieb Orie Steele 
mailto:orie@transmute.industries>>:
Torsten,

Thanks for sharing this excellent framing.

I agree with everything you said.

Please correct me if I'm wrong about anything in this summary:

1. Keep working on JWT based credential formats at OAuth (implicit, don't 
expand OAuth charter to work on CWT credential formats ?)
yes
2. If a new working group (SPICE) is formed focused on credentials, authors are 
open moving credential specific work items there, and don't plan new credential 
related items at OAuth.
We are open to move the credential work to a new working group. We are open to 
discuss whether that will be SPICE, so far it seems to be COSE centric. It’s 
clearly in everyone’s interest to have the JSON and COSE based credential 
formats aligned.

I agree, I think a big part of this comes from trying to respect the work that 
has already happened, in JSON-LD at W3C and JSON / JOSE at OAuth and OIDF.

3. Coordinate with CBOR based credential formats (wherever they may be) to 
ensure that architecture and conventions are as aligned as possible
yes

Happy to help however I can, regardless of where work items land.
Let’s talk about how we can bring the COSE and JSON credential work together.

Awesome, I think the most impactful way to achieve this would be adding a 
sentence like this to the SPICE BoF request, something to the effect of:

The following documents would be transitioned from OAuth to SPICE if the WG 
forming BoF is successful.

- draft-ietf-oauth-sd-jwt-vc
- draft-looker-oauth-jwt-cwt-status-list

It's debatable if the status list work item should move, since I see that as a 
generic token format that has applications beyond credentials.

However, if authors feel it should be paired with `draft-ietf-oauth-sd-jwt-vc` 
I can also see that argument.

Speaking as one of the authors of 
https://datatracker.ietf.org/doc/draft-prorock-cose-sd-cwt/

We would prefer to leverage a CWT status list format for that work, so if we 
consider the following work items as all possible candidates for SPICE:

- draft-looker-oauth-jwt-cwt-status-list
- draft-prorock-cose-sd-cwt
- draft-ietf-oauth-sd-jwt-vc (perhaps we can adjust this to apply to both 
SD-JWT and SD-CWT).

I can see us getting more concentrated contribution and having an easier time 
maintaining architectural alignment.

I think sd-jwt should stay at OAuth, I agree with Brian, it's nearly complete, 
and I am happy to help close the gap on any remaining issues with the 

Re: [OAUTH-WG] OAuth and JWT/VC documents

[Orie Steele]

Inline:

On Fri, Sep 29, 2023 at 12:05 PM Brian Campbell 
wrote:

>
> If I might offer an observation...
>
> The draft-looker-oauth-jwt-cwt-status-list draft is (or can easily be[*])
> really just a generic status/revocation checking mechanism for JWTs in
> general. Given the history/lineage of JWT development within the OAuth WG,
> it seems like a general JWT status/revocation mechanism would fall easily
> within the remit of the WG as is.
>

I agree with this.


>
> It seems to me as though the prospect of the formation of a new WG from
> the potential SPICE BoF that may or may not be a suitable future forum for
> the status list work has unintentionally delayed or diverted
> attention around consideration of the status list work being adopted and
> progressed in OAuth in the more near term.
>
>
Speaking as a contributor to SPICE BoF, this was certainly never my
intention.

I don't think work should be delayed if it is well solved within an
existing working group, and I agree that status lists are relevant to JWT
and CWT generally, not just credentials.


>
> [*] it has some open TODOs for CWT based representations but no actual
> content as such, which could be removed to focus the scope of the draft.
>
>
+1


>
>
> On Tue, Sep 19, 2023 at 1:56 PM Orie Steele 
> wrote:
>
>> Excellent.
>>
>> Inline:
>>
>> On Tue, Sep 19, 2023 at 2:12 PM  wrote:
>>
>>> Hi Orie,
>>>
>>> best regards,
>>> Torsten.
>>> Am 18. Sept. 2023, 16:01 +0200 schrieb Orie Steele
>>> :
>>>
>>> Torsten,
>>>
>>> Thanks for sharing this excellent framing.
>>>
>>> I agree with everything you said.
>>>
>>> Please correct me if I'm wrong about anything in this summary:
>>>
>>> 1. Keep working on JWT based credential formats at OAuth (implicit,
>>> don't expand OAuth charter to work on CWT credential formats ?)
>>>
>>> yes
>>>
>>> 2. If a new working group (SPICE) is formed focused on credentials,
>>> authors are open moving credential specific work items there, and don't
>>> plan new credential related items at OAuth.
>>>
>>> We are open to move the credential work to a new working group. We are
>>> open to discuss whether that will be SPICE, so far it seems to be COSE
>>> centric. It’s clearly in everyone’s interest to have the JSON and COSE
>>> based credential formats aligned.
>>>
>>
>> I agree, I think a big part of this comes from trying to respect the work
>> that has already happened, in JSON-LD at W3C and JSON / JOSE at OAuth and
>> OIDF.
>>
>>
>>> 3. Coordinate with CBOR based credential formats (wherever they may be)
>>> to ensure that architecture and conventions are as aligned as possible
>>>
>>> yes
>>>
>>>
>>> Happy to help however I can, regardless of where work items land.
>>>
>>> Let’s talk about how we can bring the COSE and JSON credential work
>>> together.
>>>
>>>
>> Awesome, I think the most impactful way to achieve this would be adding a
>> sentence like this to the SPICE BoF request, something to the effect of:
>>
>> The following documents would be transitioned from OAuth to SPICE if the
>> WG forming BoF is successful.
>>
>> - draft-ietf-oauth-sd-jwt-vc
>> - draft-looker-oauth-jwt-cwt-status-list
>>
>> It's debatable if the status list work item should move, since I see that
>> as a generic token format that has applications beyond credentials.
>>
>> However, if authors feel it should be paired with
>> `draft-ietf-oauth-sd-jwt-vc` I can also see that argument.
>>
>> Speaking as one of the authors of
>> https://datatracker.ietf.org/doc/draft-prorock-cose-sd-cwt/
>>
>> We would prefer to leverage a CWT status list format for that work, so if
>> we consider the following work items as all possible candidates for SPICE:
>>
>> - draft-looker-oauth-jwt-cwt-status-list
>> - draft-prorock-cose-sd-cwt
>> - draft-ietf-oauth-sd-jwt-vc (perhaps we can adjust this to apply to both
>> SD-JWT and SD-CWT).
>>
>> I can see us getting more concentrated contribution and having an easier
>> time maintaining architectural alignment.
>>
>> I think sd-jwt should stay at OAuth, I agree with Brian, it's nearly
>> complete, and I am happy to help close the gap on any remaining issues with
>> the document.
>>
>> I'm happy to make further updates regarding consolidating credential work
>> items in SPICE, and reducing the load on OAUTH WG, but I look to authors
>> and the OAUTH working group to confirm if they are ok with the SPICE BoF
>> request commenting on their work in this way.
>>
>> Perhaps we can discuss briefly in the OAuth office hours tomorrow.
>>
>>
>>
>>> best regards,
>>> Torsten.
>>>
>>>
>>> Regards,
>>>
>>> OS
>>>
>>> On Mon, Sep 18, 2023 at 7:06 AM >> 40lodderstedt@dmarc.ietf.org
>>> > wrote:
>>>
>>> Hi Roman,
>>>
>>> I’m writing this post on behalf of the group of co-authors who proposed
>>> the following drafts for adoption by the OAuth WG:
>>>
>>> draft-ietf-oauth-attestation-based-client-auth
>>> draft-ietf-oauth-sd-jwt-vc
>>> draft-looker-oauth-jwt-cwt-status-list
>>>

Re: [OAUTH-WG] OAuth and JWT/VC documents

[Brian Campbell]

If I might offer an observation...

The draft-looker-oauth-jwt-cwt-status-list draft is (or can easily be[*])
really just a generic status/revocation checking mechanism for JWTs in
general. Given the history/lineage of JWT development within the OAuth WG,
it seems like a general JWT status/revocation mechanism would fall easily
within the remit of the WG as is.

It seems to me as though the prospect of the formation of a new WG from the
potential SPICE BoF that may or may not be a suitable future forum for the
status list work has unintentionally delayed or diverted attention around
consideration of the status list work being adopted and progressed in OAuth
in the more near term.


[*] it has some open TODOs for CWT based representations but no actual
content as such, which could be removed to focus the scope of the draft.



On Tue, Sep 19, 2023 at 1:56 PM Orie Steele 
wrote:

> Excellent.
>
> Inline:
>
> On Tue, Sep 19, 2023 at 2:12 PM  wrote:
>
>> Hi Orie,
>>
>> best regards,
>> Torsten.
>> Am 18. Sept. 2023, 16:01 +0200 schrieb Orie Steele
>> :
>>
>> Torsten,
>>
>> Thanks for sharing this excellent framing.
>>
>> I agree with everything you said.
>>
>> Please correct me if I'm wrong about anything in this summary:
>>
>> 1. Keep working on JWT based credential formats at OAuth (implicit, don't
>> expand OAuth charter to work on CWT credential formats ?)
>>
>> yes
>>
>> 2. If a new working group (SPICE) is formed focused on credentials,
>> authors are open moving credential specific work items there, and don't
>> plan new credential related items at OAuth.
>>
>> We are open to move the credential work to a new working group. We are
>> open to discuss whether that will be SPICE, so far it seems to be COSE
>> centric. It’s clearly in everyone’s interest to have the JSON and COSE
>> based credential formats aligned.
>>
>
> I agree, I think a big part of this comes from trying to respect the work
> that has already happened, in JSON-LD at W3C and JSON / JOSE at OAuth and
> OIDF.
>
>
>> 3. Coordinate with CBOR based credential formats (wherever they may be)
>> to ensure that architecture and conventions are as aligned as possible
>>
>> yes
>>
>>
>> Happy to help however I can, regardless of where work items land.
>>
>> Let’s talk about how we can bring the COSE and JSON credential work
>> together.
>>
>>
> Awesome, I think the most impactful way to achieve this would be adding a
> sentence like this to the SPICE BoF request, something to the effect of:
>
> The following documents would be transitioned from OAuth to SPICE if the
> WG forming BoF is successful.
>
> - draft-ietf-oauth-sd-jwt-vc
> - draft-looker-oauth-jwt-cwt-status-list
>
> It's debatable if the status list work item should move, since I see that
> as a generic token format that has applications beyond credentials.
>
> However, if authors feel it should be paired with
> `draft-ietf-oauth-sd-jwt-vc` I can also see that argument.
>
> Speaking as one of the authors of
> https://datatracker.ietf.org/doc/draft-prorock-cose-sd-cwt/
>
> We would prefer to leverage a CWT status list format for that work, so if
> we consider the following work items as all possible candidates for SPICE:
>
> - draft-looker-oauth-jwt-cwt-status-list
> - draft-prorock-cose-sd-cwt
> - draft-ietf-oauth-sd-jwt-vc (perhaps we can adjust this to apply to both
> SD-JWT and SD-CWT).
>
> I can see us getting more concentrated contribution and having an easier
> time maintaining architectural alignment.
>
> I think sd-jwt should stay at OAuth, I agree with Brian, it's nearly
> complete, and I am happy to help close the gap on any remaining issues with
> the document.
>
> I'm happy to make further updates regarding consolidating credential work
> items in SPICE, and reducing the load on OAUTH WG, but I look to authors
> and the OAUTH working group to confirm if they are ok with the SPICE BoF
> request commenting on their work in this way.
>
> Perhaps we can discuss briefly in the OAuth office hours tomorrow.
>
>
>
>> best regards,
>> Torsten.
>>
>>
>> Regards,
>>
>> OS
>>
>> On Mon, Sep 18, 2023 at 7:06 AM > > wrote:
>>
>> Hi Roman,
>>
>> I’m writing this post on behalf of the group of co-authors who proposed
>> the following drafts for adoption by the OAuth WG:
>>
>> draft-ietf-oauth-attestation-based-client-auth
>> draft-ietf-oauth-sd-jwt-vc
>> draft-looker-oauth-jwt-cwt-status-list
>>
>> We have brought these drafts to the IETF because they are built on IETF
>> drafts/standards and enhance them. Those drafts are interrelated and part
>> of a bigger effort to provide initiatives around the globe for building
>> ecosystems based on the Issuer/Holder/Verifier model, especially focussing
>> on EU’s eIDAS, with interoperable technical standards.
>>
>> The work is based on two pillars, Selective Disclosure JWT (SD-JWT) and
>> OpenID for Verifiable Credentials (OID4VC). The latter is a credential
>> format agnostic family of protocols for