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

[Rifaat Shekh-Yusef]

Thanks Giuseppe!

Please, reply to the *official* call for adoption email.

Regards,
 Rifaat


On Fri, Sep 29, 2023 at 6:26 PM Giuseppe De Marco 
wrote:

> 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.
>>>
>>>
>>>
>>>
>&

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

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] 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.
>
>
>
>

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

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 

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

[Orie Steele]

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 issuing and presenting verifiable
> credentials and authenticating users based on keys in the wallet. These
> specifications are being standardized at the OpenID Foundation; they are
> already referenced by the eIDAS Architecture and Reference Framework.
>
> SD-JWT and OID4VC are combined in a specification designated as “OpenID
> for Verifiable Credentials High Assurance Interoperability Profile with
> SD-JWT VC” (HAIP). HAIP instantiates OID4VC with the credential format
> SD-JWT VC to allow implementers to build truly interoperable systems. This
> is the contribution we intend to make to eIDAS.
>
> While working on HAIP we identified missing pieces in the overall picture,
> most notably a way to use well-established JWT content rules and its
> extensibility model as basis for representing Verifiable Credentials with
> JSON payload. That’s why we drafted draft-ietf-oauth-sd-jwt-vc.
>
> We also noticed Verifiable Credentials are typically long living
> credentials and thus need a way for its issuer to influence its status.
> That’s 

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

[torsten=40lodderstedt . net]

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.
> 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.

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 issuing and presenting verifiable 
> > credentials and authenticating users based on keys in the wallet. These 
> > specifications are being standardized at the OpenID Foundation; they are 
> > already referenced by the eIDAS Architecture and Reference Framework.
> >
> > SD-JWT and OID4VC are combined in a specification designated as “OpenID for 
> > Verifiable Credentials High Assurance Interoperability Profile with SD-JWT 
> > VC” (HAIP). HAIP instantiates OID4VC with the credential format SD-JWT VC 
> > to allow implementers to build truly interoperable systems. This is the 
> > contribution we intend to make to eIDAS.
> >
> > While working on HAIP we identified missing pieces in the overall picture, 
> > most notably a way to use well-established JWT content rules and its 
> > extensibility model as basis for representing Verifiable Credentials with 
> > JSON payload. That’s why we drafted draft-ietf-oauth-sd-jwt-vc.
> >
> > We also noticed Verifiable Credentials are typically long living 
> > credentials and thus need a way for its issuer to influence its status. 
> > That’s why we drafted draft-looker-oauth-jwt-cwt-status-list and 
> > incorporated it into draft-ietf-oauth-sd-jwt-vc.
> >
> > In addition, we learned while working with the eIDAS expert group and 
> > others that wallet to issuer authentication needs to fulfill very special 
> > requirements. That’s why we drafted 
> > draft-ietf-oauth-attestation-based-client-auth as a new client 
> > authentication method.
> >
> > To sum up, draft-ietf-oauth-sd-jwt-vc and 
> > draft-looker-oauth-jwt-cwt-status-list extend the work being done around 
> > SD-JWT so we feel the OAuth WG is the best place to evolved them. However, 
> > we are open to discuss to carve out the work around credential formats and 
> > supporting mechanisms into a new working group.
> >
> > draft-ietf-oauth-attestation-based-client-auth is an OAuth extension, so we 
> > believe it belongs to the OAuth WG.
> >
> > ** 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?
> >
> > draft-ietf-oauth-sd-jwt-vc and draft-looker-oauth-jwt-cwt-status-list are 
> > fundamental building blocks on the level of credential formats for building 
> > applications according to the Issuer/Holder/Verifier model. A lot of 
> > initiatives around the globe are looking for technical standards for this 
> > kind of application now. (For example, the eIDAS expert group hopes to 
> > finalize its Architectural Reference Framework (ARF) this year.) So there 
> > is a window of opportunity for IETF and this group to make an impact with 
> > solid, secure and usable technical standards.
> >
> > We don’t plan further contributions in this space to the WG beyond the 
> > proposed drafts.
> >
> > ** What unknown about the direction and needed tasks?
> >
> > I hope I could shed some light on our 

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

[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 ?)
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.
3. Coordinate with CBOR based credential formats (wherever they may be) to
ensure that architecture and conventions are as aligned as possible

Happy to help however I can, regardless of where work items land.

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 issuing and presenting verifiable
> credentials and authenticating users based on keys in the wallet. These
> specifications are being standardized at the OpenID Foundation; they are
> already referenced by the eIDAS Architecture and Reference Framework.
>
> SD-JWT and OID4VC are combined in a specification designated as “OpenID
> for Verifiable Credentials High Assurance Interoperability Profile with
> SD-JWT VC” (HAIP). HAIP instantiates OID4VC with the credential format
> SD-JWT VC to allow implementers to build truly interoperable systems. This
> is the contribution we intend to make to eIDAS.
>
> While working on HAIP we identified missing pieces in the overall picture,
> most notably a way to use well-established JWT content rules and its
> extensibility model as basis for representing Verifiable Credentials with
> JSON payload. That’s why we drafted draft-ietf-oauth-sd-jwt-vc.
>
> We also noticed Verifiable Credentials are typically long living
> credentials and thus need a way for its issuer to influence its status.
> That’s why we drafted draft-looker-oauth-jwt-cwt-status-list and
> incorporated it into draft-ietf-oauth-sd-jwt-vc.
>
> In addition, we learned while working with the eIDAS expert group and
> others that wallet to issuer authentication needs to fulfill very special
> requirements. That’s why we drafted
> draft-ietf-oauth-attestation-based-client-auth as a new client
> authentication method.
>
> To sum up, draft-ietf-oauth-sd-jwt-vc and
> draft-looker-oauth-jwt-cwt-status-list extend the work being done around
> SD-JWT so we feel the OAuth WG is the best place to evolved them. However,
> we are open to discuss to carve out the work around credential formats and
> supporting mechanisms into a new working group.
>
> draft-ietf-oauth-attestation-based-client-auth is an OAuth extension, so
> we believe it belongs to the OAuth WG.
>
> ** 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?
>
> draft-ietf-oauth-sd-jwt-vc and draft-looker-oauth-jwt-cwt-status-list are
> fundamental building blocks on the level of credential formats for building
> applications according to the Issuer/Holder/Verifier model. A lot of
> initiatives around the globe are looking for technical standards for this
> kind of application now. (For example, the eIDAS expert group hopes to
> finalize its Architectural Reference Framework (ARF) this year.) So there
> is a window of opportunity for IETF and this group to make an impact with
> solid, secure and usable technical standards.
>
> We don’t plan further contributions in this space to the WG beyond the
> proposed drafts.
>
> ** What unknown about the direction and needed tasks?
>
> I hope I could shed some light on our plans.
>
> ** For whatever that work might be, how should the OAuth charter evolve to
> support the work?
>
> We suggest extending the charter to cover work on credential formats and
> related mechanisms based on JWTs. As already mentioned above, we are also
> open to moving this work into a new dedicated working group once such a
> working group is operational. That working group might be established as a
> result of the SPICE effort.  It would be good to coordinate closely with
> those developing CBOR-based credentials to keep that work and ours
> architecturally aligned. We, however, see the need to keep working on the
> drafts to meet the expectations of 

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

[Orie Steele]

I agree with Brian's comments. It's clear to me that SD-JWT has benefited a
lot from the expertise of the OAuth WG.

OS




On Fri, Sep 15, 2023, 4:12 PM Brian Campbell  wrote:

> Hi Roman,
>
> I'm going to dodge some of the bigger picture questions but wanted to give
> a bit of historical context/justification for the
> draft-ietf-oauth-selective-disclosure-jwt work in the OAuth WG.
>
> JWT  itself was a product of
> OAuth WG yet was intentionally developed as a general-purpose token format
> with no direct dependency or relation to RFC6749
> . JWT certainly had useful
> applications in OAuth/RFC6749 but it wasn't limited to such. JWT has seen
> widespread usage in a variety of applications and other standards, which is
> arguably a testament to the intent and nature of that development.
>
> SD-JWT
> 
> is basically just a selective disclosure mechanism for JWT. It builds on
> and leverages the established and familiar constructs of JWT. It is
> similarly intended to be a general-purpose specification. Given that broad
> intent and SD-JWT's relationship to JWT, with JWT's heritage of being
> developed in the OAuth WG, it seemed only natural and appropriate that
> SD-JWT follow suit and find its "home" for development in the OAuth WG too.
> SD-JWT has been an active work item of the WG for about a year and has
> matured nicely in that environment. I'm (maybe naively) hoping that the
> work is closer to the end of its time in WG than it is to the beginning.
>
>
>
>
> On Fri, Sep 8, 2023 at 1: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?
>>
>> ** For whatever that work might be, how should the OAuth charter evolve
>> to support the work?
>>
>> ** Is there work to be done around bridging the architectural narrative
>> used in the core OAuth framework/RFC6749 (AS, RS, RO) and three part model
>> (issuer, holder, verifier) used in
>> draft-ietf-oauth-selective-disclosure-jwt?
>>
>> Thanks,
>> Roman, Hannes, and Rifaat
>> ___
>> 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
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[torsten=40lodderstedt . net]

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 issuing and presenting verifiable credentials and 
authenticating users based on keys in the wallet. These specifications are 
being standardized at the OpenID Foundation; they are already referenced by the 
eIDAS Architecture and Reference Framework.

SD-JWT and OID4VC are combined in a specification designated as “OpenID for 
Verifiable Credentials High Assurance Interoperability Profile with SD-JWT VC” 
(HAIP). HAIP instantiates OID4VC with the credential format SD-JWT VC to allow 
implementers to build truly interoperable systems. This is the contribution we 
intend to make to eIDAS.

While working on HAIP we identified missing pieces in the overall picture, most 
notably a way to use well-established JWT content rules and its extensibility 
model as basis for representing Verifiable Credentials with JSON payload. 
That’s why we drafted draft-ietf-oauth-sd-jwt-vc.

We also noticed Verifiable Credentials are typically long living credentials 
and thus need a way for its issuer to influence its status. That’s why we 
drafted draft-looker-oauth-jwt-cwt-status-list and incorporated it into 
draft-ietf-oauth-sd-jwt-vc.

In addition, we learned while working with the eIDAS expert group and others 
that wallet to issuer authentication needs to fulfill very special 
requirements. That’s why we drafted 
draft-ietf-oauth-attestation-based-client-auth as a new client authentication 
method.

To sum up, draft-ietf-oauth-sd-jwt-vc and 
draft-looker-oauth-jwt-cwt-status-list extend the work being done around SD-JWT 
so we feel the OAuth WG is the best place to evolved them. However, we are open 
to discuss to carve out the work around credential formats and supporting 
mechanisms into a new working group.

draft-ietf-oauth-attestation-based-client-auth is an OAuth extension, so we 
believe it belongs to the OAuth WG.

** 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?

draft-ietf-oauth-sd-jwt-vc and draft-looker-oauth-jwt-cwt-status-list are 
fundamental building blocks on the level of credential formats for building 
applications according to the Issuer/Holder/Verifier model. A lot of 
initiatives around the globe are looking for technical standards for this kind 
of application now. (For example, the eIDAS expert group hopes to finalize its 
Architectural Reference Framework (ARF) this year.) So there is a window of 
opportunity for IETF and this group to make an impact with solid, secure and 
usable technical standards.

We don’t plan further contributions in this space to the WG beyond the proposed 
drafts.

** What unknown about the direction and needed tasks?

I hope I could shed some light on our plans.

** For whatever that work might be, how should the OAuth charter evolve to 
support the work?

We suggest extending the charter to cover work on credential formats and 
related mechanisms based on JWTs. As already mentioned above, we are also open 
to moving this work into a new dedicated working group once such a working 
group is operational. That working group might be established as a result of 
the SPICE effort.  It would be good to coordinate closely with those developing 
CBOR-based credentials to keep that work and ours architecturally aligned. We, 
however, see the need to keep working on the drafts to meet the expectations of 
current and prospect implementers.

** Is there work to be done around bridging the architectural narrative used in 
the core OAuth framework/RFC6749 (AS, RS, RO) and three part model (issuer, 
holder, verifier) used in draft-ietf-oauth-selective-disclosure-jwt?

We suggest clearly distinguishing protocol aspects from data format aspects. 
draft-ietf-oauth-selective-disclosure-jwt as part of the credential format 
aspect has dependencies on JWT but no dependencies on RFC 6749.

There is work to be done to cater for protocols sitting on top of OAuth for 
supporting the issuer/holder/verifier model. OpenID4VC is built on top of OAuth 
and we have come up with some observations around that. For example, clients 
(either verifiers or wallets acting as clients towards issuers) are typically 
not managed by the AS. Either there is a 

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

[Denis]

Hi Brian,

The main questions raised by Roman were:

   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?

The topic is about SD-JWT-VC (draft-ietf-oauth-sd-jwt-vc). It is not 
about SD-JWT (draft-ietf-oauth-selective-disclosure-jwt).


At a first glance, using JWTs within SD-JWT-VC seems fine, since none of 
the claims defined in RFC7519 are intended to be mandatory to use or 
implement.


However, compliance to RFC 7519 (JWT) means compliance with all the 
content of the document, i.e., including its processing requirements
defined in section 7.  "Creating and Validating JWTs". None of these two 
sections (i.e., 7.1 and 7.2) allows to create and verify a JWT-VC

as intended in draft-ietf-oauth-sd-jwt-vc.

Are JWTs adequate to be used in the context of a "three *roles* model" 
(i.e., Holder, Issuer and Verifier) ?


Both OAuth 2.0 and OAuth 2.1 consider that a JWT is "considered opaque 
to the client, even if it has a structure".

This consideration cannot apply to SD-JWT-VC (draft-ietf-oauth-sd-jwt-vc).

The "three roles model" should be usable using smartphones supporting 
Digital Identity Wallets. Unfortunately, this is not the case

with draft-ietf-oauth-sd-jwt-vc.

The three roles model should consider (at least) seven other *entities*: 
TA, TA Issuer, TEE, TEE Issuer, RichOs, RichOS Issuer and the user agent.
Neither the OAuth 2.0 Framework, nor the OAuth 2.1 Framework, considers 
these seven entities.



Below is an answer to the second question raised by Roman:

   *What needs to be done first? **
   *

   1) A Framework, usable in a smartphone environment, needs first to
   be defined with its own vocabulary and its own data flows.
   Let us call it something like: "The Credentials Framework 1.0".

  Then after the trust relationships between the various roles and
   entities need to be defined.

   In order to follow both a privacy-by-design and a
   security-by-design approach, a model including the ten entities (and
   maybe more)
   should first be defined with a description of the sequencing of
   the flows and of the interactions between its entities.

  Then after, both a "Security considerations" section and a
   "Privacy considerations" section should be written to highlight
   which security and privacy properties are intended (and are not
   intended) to be supported.

   2) The W3C VCDM 2.0 model should be analysed in order to identify
   which aspects should be retained and which other aspects should be
   discarded,
 with a rational for each aspect. This implicit means that the
   full W3C VCDM document will not necessarily be endorsed. One of the
   results of this analysis
 would be to identify which syntaxes and semantics would be
   candidate to be used for VC, and for VPs, with pros and cons.
   Copyright issues might need
 to be addressed between the W3C and the IETF and I am fully
   ignorant on that aspect.

   3) Schemas for VCs supported by a given Issuer should then be
   defined, so that a Holder may request a Credential corresponding to
   a selected profile.

   4) All the data flows, starting from the data flow between a
   pre-Holder and an Issuer, will need to be considered.


Much more than a single RFC will be needed. Both the W3C and the OpenID 
Foundation (OIDF) have already paved the beginning of this path.


Placing such a work under the umbrella of the OAuth WG is questionable 
since it would likely create a confusion with the OAuth 2.0 and OAuth 
2.1 Frameworks

and this is one of the topics currently discussed in the SPICE BoF.

Would a Creds WG be more appropriate ?

Denis


Hi Roman,

I'm going to dodge some of the bigger picture questions but wanted to 
give a bit of historical context/justification for the 
draft-ietf-oauth-selective-disclosure-jwt work in the OAuth WG.


JWT  itself was a product 
of OAuth WG yet was intentionally developed as a general-purpose token 
format with no direct dependency or relation to RFC6749 
. JWT certainly had 
useful applications in OAuth/RFC6749 but it wasn't limited to such. 
JWT has seen widespread usage in a variety of applications and other 
standards, which is arguably a testament to the intent and nature of 
that development.


SD-JWT 
 
is basically just a selective disclosure mechanism for JWT. It builds 
on and leverages the established and familiar constructs of JWT. It is 
similarly intended to be a general-purpose specification. Given that 
broad intent and SD-JWT's relationship to JWT, with JWT's heritage of 
being developed in the OAuth WG, it seemed only natural and 
appropriate that SD-JWT follow suit and find its "home" for 
development in the OAuth WG too. SD-JWT has been an active work item 
of the WG for 

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

[Denis]

t;email": "john...@example.com",
  "phone_number": "+1-202-555-0101",
  "address": {
    "street_address": "123 Main St",
    "locality": "Anytown",
    "region": "Anystate",
    "country": "US"
  },
  "birthdate": "1940-01-01",
  "is_over_18": true,
  "is_over_21": true,
  "is_over_65": true
}

Some observations:

1) The last items should rather be:

  "is_over_18": null,
  "is_over_21": null,
  "is_over_65": null

null describes the absence of a value.

A JWT shall never contain a line like "is_over_21": false.

2) Since age limits are most often country dependent and it would not be 
appropriate to define a set of Claims "is over_XX" with XX between 7 and 77
and the same set for Claims "is under_XX" between 7 and 77. Instead of 
registering to IANA around 140 claims, it would be simpler to register 
to IANA
only two claims: "age_over" and "age_under" able to contain  one or more 
age values.


This is possible by ignoring the following sentence placed in section 4 
of JWT (RFC 7519):


   "The Claim Names within a JWT Claims Set MUST be unique".

... which means using a JSON structure _that will NOT be conformant to 
RFC 7519 (JWT)_.


The "privacy considerations" section of draft-ietf-oauth-sd-jwt-vc-00 is 
nearly empty. :-(


Since RFC 7519 indicates that all of the claims are OPTIONAL, is there a 
set of claims that SHALL be present in the VC issued by the Issuer to 
the Holder ?


Same question for a VP presented by an Holder to a Verifier ?

Even if no claim is been disclosed, the use of a JWT does not allow to 
support the Unlinkability property between verifiers.


Both this section and the Introduction should indicate that this 
solution *by design* does not permit to support the unlinkability 
property between verifiers.


Note that the W3C data model, which is rather flexible, allows to 
support the unlinkability property between verifiers.


Using a JWT does not only mean that its data structure shall be 
compliant to RFC 7519 but also to its processing requirements,
i.e. to section 7.  "Creating and Validating JWTs". None of these two 
sections (i.e., 7.1 and 7.2) allows to create and verify a JWT-VC as 
intended.


draft-ietf-oauth-sd-jwt-vc-00 is currently unable to conform to section 
7 from RFC 7519 (JWT).


The OAuth 2.1 Framework states:

    "Access tokens are credentials used to access protected 
resources. 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".


This is consistent with the OAuth 2.0 Framework, but a client CANNOT 
consider a JWT-VC to be *opaque* when it receives it from the Issuer.


Nor the OAuth 2.0 Framework or the OAuth 2.1 Framework is able to 
support the draft-ietf-oauth-sd-jwt-vc-00.


Regarding the question: "The protocols between an holder and a 
verifier are rather different from those defined in OAuth, since in 
many cases they support Zero-Knowledge proofs (ZKPs).


The answer is: No, not necessarily. That's what the whole SD-JWT is 
about.


A zero-knowledge proof is a method involving one or more exchanges 
between a prover and a verifier where the prover is able to convince the 
verifier
that a statement is true, without revealing to the verifier any 
additional information beyond that knowledge.


draft-ietf-oauth-sd-jwt-vc-00 supports selective disclosure, but reveals 
more information about the prover than the disclosed claims.
It discloses information that allows different verifiers to link the 
proofs they receive. By design, draft-ietf-oauth-sd-jwt-vc-00 is unable
to support the Unlinkability property between verifiers. ZKP cannot be 
supported. That's what the whole SD-JWT *VC* is about.


Denis


Ciao

Hannes

*Von:*OAuth  *Im Auftrag von *Denis
*Gesendet:* Samstag, 9. September 2023 15:44
*An:* Roman Danyliw 
*Cc:* oauth 
*Betreff:* Re: [OAUTH-WG] OAuth and JWT/VC documents

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" s

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

[Brian Campbell]

Hi Roman,

I'm going to dodge some of the bigger picture questions but wanted to give
a bit of historical context/justification for the
draft-ietf-oauth-selective-disclosure-jwt work in the OAuth WG.

JWT  itself was a product of
OAuth WG yet was intentionally developed as a general-purpose token format
with no direct dependency or relation to RFC6749
. JWT certainly had useful
applications in OAuth/RFC6749 but it wasn't limited to such. JWT has seen
widespread usage in a variety of applications and other standards, which is
arguably a testament to the intent and nature of that development.

SD-JWT

is basically just a selective disclosure mechanism for JWT. It builds on
and leverages the established and familiar constructs of JWT. It is
similarly intended to be a general-purpose specification. Given that broad
intent and SD-JWT's relationship to JWT, with JWT's heritage of being
developed in the OAuth WG, it seemed only natural and appropriate that
SD-JWT follow suit and find its "home" for development in the OAuth WG too.
SD-JWT has been an active work item of the WG for about a year and has
matured nicely in that environment. I'm (maybe naively) hoping that the
work is closer to the end of its time in WG than it is to the beginning.




On Fri, Sep 8, 2023 at 1: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?
>
> ** For whatever that work might be, how should the OAuth charter evolve to
> support the work?
>
> ** Is there work to be done around bridging the architectural narrative
> used in the core OAuth framework/RFC6749 (AS, RS, RO) and three part model
> (issuer, holder, verifier) used in
> draft-ietf-oauth-selective-disclosure-jwt?
>
> Thanks,
> Roman, Hannes, and Rifaat
> ___
> 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] OAuth and JWT/VC documents

[Tschofenig, Hannes]

Hi Denis,

OAuth defines 4 roles, see Section 1.1 of RFC 6749. In the three party model 
there is likely a human behind the holder as well.

You can map the OAuth terms to the VC terms, if you like, as follows:

* Issuer: Authorization Server
* Holder: Client
* Verifier: Relying Party

TEEs, Trusted Applications, etc. are implementation specific details. You can 
use them in OAuth, and other protocols as well.

Regarding the question: "What the IETF should do (or not do) in this area ?"
The answer is: We are working in the IETF on these topics already, see Web 
Authorization Protocol (oauth) 
(ietf.org)<https://datatracker.ietf.org/wg/oauth/documents/>.

Regading the question: "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).
The answer is: No,not necessarily. That's what the whole SD-JWT is about.

Ciao
Hannes


Von: OAuth  Im Auftrag von Denis
Gesendet: Samstag, 9. September 2023 15:44
An: Roman Danyliw 
Cc: oauth 
Betreff: Re: [OAUTH-WG] OAuth and JWT/VC documents

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 
mailto:r...@cert.org>> 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 example of this IMO).

It's possible that a document at OAuth recognizing the data model elements of 
the 3 party model (iss, sub, cnf, kid, etc) might help enable documents outside 
of OAuth to better defer to OAuth for "moving tokens, or leveraging successful 
protocols"... this could help reduce the data model reinvention everywhere 
else, and it could drive the common understanding

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

[Tom Jones]

The problem is that we need a 2 party, off-line model for the world of
mobile devices.
that should not depend on OAuth.

..tom


On Mon, Sep 11, 2023 at 8:22 AM Orie Steele 
wrote:

> As far as I know, OpenID and DIF both use OAuth for these cases (the 3
> party model).
>
> W3C focuses only on the data model (in JSON-LD and RDF) and lacks
> the expertise to focus on the other parts (including security, and
> transport considerations IMO.)
>
> GlobalPlatform and others are related to the area by the concept of
> attestation, which is related to gaining higher confidence in the OAuth
> roles (Client, Resource Server, wallet / credential issuer, etc...)
>
> Regarding a BoF for this topic, as opposed to extending the OAuth charter,
> you might be interested in: https://mailarchive.ietf.org/arch/browse/spice
>
> Regardless of where the "3 party model" lands at IETF, I think there
> should be coordination with JOSE, COSE, OAUTH, given their existing use in
> this ecosystem...
>
> But that does not necessarily mean charter changes for OAuth, it could be
> as simple as cross posting and seeking review where it makes sense to do so.
>
> Maybe a different way of gaining clarity on the same topic... If OAUTH
> were to recharter, what would it include / exclude... (ignoring the 3 party
> model for a second)... would attestaton be in scope?
>
> Regards,
>
> OS
>
>
> On Sat, Sep 9, 2023 at 12:57 PM Tom Jones 
> wrote:
>
>> +1 Denis.
>>
>> I cannot understand why OAuth is used in this user (or many others in
>> development) as there is no authorization involved!
>>
>> The verifier asks the user (wallet) for data (perhaps with some back and
>> forth) the user (wallet) supplies the data or not with consent to the
>> conditions supplied by the verifier.There is no separate RO or
>> authorization path.
>>
>> Starting with OAuth in these cases adds a level of complexity that is
>> wholly unnecessary.
>>
>> ..tom
>>
>>
>> On Sat, Sep 9, 2023 at 6:44 AM Denis  wrote:
>>
>>> 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
 

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

[Orie Steele]

As far as I know, OpenID and DIF both use OAuth for these cases (the 3
party model).

W3C focuses only on the data model (in JSON-LD and RDF) and lacks
the expertise to focus on the other parts (including security, and
transport considerations IMO.)

GlobalPlatform and others are related to the area by the concept of
attestation, which is related to gaining higher confidence in the OAuth
roles (Client, Resource Server, wallet / credential issuer, etc...)

Regarding a BoF for this topic, as opposed to extending the OAuth charter,
you might be interested in: https://mailarchive.ietf.org/arch/browse/spice

Regardless of where the "3 party model" lands at IETF, I think there should
be coordination with JOSE, COSE, OAUTH, given their existing use in this
ecosystem...

But that does not necessarily mean charter changes for OAuth, it could be
as simple as cross posting and seeking review where it makes sense to do so.

Maybe a different way of gaining clarity on the same topic... If OAUTH were
to recharter, what would it include / exclude... (ignoring the 3 party
model for a second)... would attestaton be in scope?

Regards,

OS


On Sat, Sep 9, 2023 at 12:57 PM Tom Jones 
wrote:

> +1 Denis.
>
> I cannot understand why OAuth is used in this user (or many others in
> development) as there is no authorization involved!
>
> The verifier asks the user (wallet) for data (perhaps with some back and
> forth) the user (wallet) supplies the data or not with consent to the
> conditions supplied by the verifier.There is no separate RO or
> authorization path.
>
> Starting with OAuth in these cases adds a level of complexity that is
> wholly unnecessary.
>
> ..tom
>
>
> On Sat, Sep 9, 2023 at 6:44 AM Denis  wrote:
>
>> 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 

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

[Tom Jones]

+1 Denis.

I cannot understand why OAuth is used in this user (or many others in
development) as there is no authorization involved!

The verifier asks the user (wallet) for data (perhaps with some back and
forth) the user (wallet) supplies the data or not with consent to the
conditions supplied by the verifier.There is no separate RO or
authorization path.

Starting with OAuth in these cases adds a level of complexity that is
wholly unnecessary.

..tom


On Sat, Sep 9, 2023 at 6:44 AM Denis  wrote:

> 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 example of this IMO).
>
> It's possible that a document at OAuth recognizing the data model elements
> of the 3 party model (iss, sub, cnf, kid, etc) might help enable documents
> outside of OAuth to better defer to OAuth for "moving tokens, or leveraging
> successful protocols"... this could help reduce the data model reinvention
> everywhere else, and it could drive the common understanding of registered
> claim names to be interpreted consistently across JWT / CWT (and their SD
> friends).
>
>
> ** For whatever that work might be, how should the OAuth charter evolve to
>> support the work?
>>
>>
> I don't know, but I am happy to help : )
>
> One thing that seems worth unpacking is why DCP at OIDF is leaving the
> OIDC part behind (paraphrasing, kristina probably has a better take):
> https://openid.net/wg/digital-credentials-protocols/
>
> Are there things DCP might need from OAuth WG, how might the charter align
> to that work?
>
>
>> ** Is there work 

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

[Denis]

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 example of this IMO).


It's possible that a document at OAuth recognizing the data model 
elements of the 3 party model (iss, sub, cnf, kid, etc) might help 
enable documents outside of OAuth to better defer to OAuth for "moving 
tokens, or leveraging successful protocols"... this could help reduce 
the data model reinvention everywhere else, and it could drive the 
common understanding of registered claim names to be 
interpreted consistently across JWT / CWT (and their SD friends).



** For whatever that work might be, how should the OAuth charter
evolve to support the work?


I don't know, but I am happy to help : )

One thing that seems worth unpacking is why DCP at OIDF is leaving the 
OIDC part behind (paraphrasing, kristina probably has a better take): 
https://openid.net/wg/digital-credentials-protocols/


Are there things DCP might need from OAuth WG, how might the charter 
align to that work?


** Is there work to be done around bridging the architectural
narrative used in the core OAuth framework/RFC6749 (AS, RS, RO)
and three part model (issuer, holder, verifier) used in
draft-ietf-oauth-selective-disclosure-jwt?


I think so? but it depends on the comment above.

Personally I would like to see the OAuth WG tackle this head on, 
especially because of the wallet / client / subject / holder 
confusion Starting with the people we are here to serve seems like 
a safe way to progress through the technical sugar (which I love).


OS


Thanks,
Roman, Hannes, and Rifaat

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

[Orie Steele]

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 example of this IMO).

It's possible that a document at OAuth recognizing the data model elements
of the 3 party model (iss, sub, cnf, kid, etc) might help enable documents
outside of OAuth to better defer to OAuth for "moving tokens, or leveraging
successful protocols"... this could help reduce the data model reinvention
everywhere else, and it could drive the common understanding of registered
claim names to be interpreted consistently across JWT / CWT (and their SD
friends).


** For whatever that work might be, how should the OAuth charter evolve to
> support the work?
>
>
I don't know, but I am happy to help : )

One thing that seems worth unpacking is why DCP at OIDF is leaving the OIDC
part behind (paraphrasing, kristina probably has a better take):
https://openid.net/wg/digital-credentials-protocols/

Are there things DCP might need from OAuth WG, how might the charter align
to that work?


> ** Is there work to be done around bridging the architectural narrative
> used in the core OAuth framework/RFC6749 (AS, RS, RO) and three part model
> (issuer, holder, verifier) used in
> draft-ietf-oauth-selective-disclosure-jwt?
>

I think so? but it depends on the comment above.

Personally I would like to see the OAuth WG tackle this head on, especially
because of the wallet / client / subject / holder confusion Starting
with the people we are here to serve seems like a safe way to progress
through the technical sugar (which I love).

OS


>
> Thanks,
> Roman, Hannes, and Rifaat
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>


-- 


ORIE STEELE
Chief Technology Officer
www.transmute.industries


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