Re: [OAUTH-WG] draft-ietf-oauth-selective-disclosure-jwt

[Brian Campbell]

Thanks for the further remarks, Hannes. I'll work with the authors on
appropriately adding some additional background/context.

On Mon, Dec 5, 2022 at 3:39 AM Hannes Tschofenig 
wrote:

> Thanks for the response, Brian.
>
>
>
> A few remarks below.
>
>
>
> *From:* Brian Campbell 
> *Sent:* Tuesday, November 29, 2022 11:21 PM
> *To:* Hannes Tschofenig 
> *Cc:* oauth 
> *Subject:* Re: [OAUTH-WG] draft-ietf-oauth-selective-disclosure-jwt
>
>
>
> Hi Hannes,
>
>
>
> Though I am yet to officially have my name on the document as a co-author,
> you did mention me directly :) And so I'll attempt to answer or respond to
> your questions/statements below.
>
>
>
>
>
> On Mon, Nov 28, 2022 at 7:24 AM Hannes Tschofenig <
> hannes.tschofe...@arm.com> wrote:
>
> Hi Daniel, Hi Kristina, Hi Brian,
>
> Hi all,
>
>
>
> Reading through draft-ietf-oauth-selective-disclosure-jwt I was wondering
> why the document defines new terminology for roles that already exist in
> OAuth.
>
> For example:
>
>
>
>- Issuer  =  AS
>- Holder = Client
>- Verifier = RS
>
>
>
> I assume that was done intentionally. What was the rational was.
>
>
>
> JWT itself <https://datatracker.ietf.org/doc/rfc7519/> is a product of
> this WG (as I'm sure you remember).. While JWT had important applications
> in OAuth, it was developed as a more general purpose token format and has
> seen widespread usage both in OAuth and beyond. Similarly, SD-JWT is meant
> to be a general purpose selective disclosure mechanism for JWT, which can
> have applications in OAuth but is certainly not constrained to OAuth. As
> such, the terminology in the draft aims to be generally
> applicable/meaningful. This is similar/consistent with JWT/RFC7519, which
> also does not use terms like AS, RS, or client.
>
>
>
>
>
> [Hannes] I think the draft should provide that background.
>
>
>
>
>
> You write:
>
>
>
> “
>
> One of the common use cases of a signed JWT is representing a user's
> identity.
>
> “
>
>
>
> In classical OAuth this use case should not be common. We bragged about
> the fact that you could to delegated authorization without having to rely
> on identity information. I think it would help to expand this statement a
> bit and explain what the use case is.
>
>
>
> A signed JWT representing a user's identity is, in fact, exceedingly
> common. Even in classical OAuth the access tokens almost always convey
> something about an identity - the resource owner in OAuth parlance. The sub
> in introspection https://www.rfc-editor.org/rfc/rfc7662#section-2.2 and
> the JWT AT profile
> https://datatracker.ietf.org/doc/html/rfc9068#section-2.2 show this in
> specs, for example. Of course the AT format and content aren't defined by
> OAuth itself and are left up to the implementation/deployment so those
> optional specs don't tell the whole story. But every single deployment I've
> seen has some identity info in the AT for delegation.
>
>
>
>
>
> [Hannes] This paragraph would be a good addition to the draft providing a
> bit of background.
>
>
>
> You write:
>
> “ As long as the signed JWT is one-time use, it typically only contains
> those claims the user has consented to disclose to a specific Verifier.
> However, there is an increasing number of use cases where a signed JWT is
> created once and then used a number of times by the user (the "Holder" of
> the JWT). In such cases, the signed JWT needs to contain the superset of
> all claims the user of the signed JWT might want to disclose to Verifiers
> at some point. The ability to selectively disclose a subset of these claims
> depending on the Verifier becomes crucial to ensure minimum disclosure and
> prevent Verifiers from obtaining claims irrelevant for the transaction at
> hand.
>
> “
>
>
>
> Using the same access token with multiple resource servers is not good
> security practice not only from a privacy point of view but also from a
> security point of view.
>
>
>
> From reading the introduction I get the impression that you create your
> own problem that is subsequently solved in the document. Since I believe
> you are too clever to do this, I believe the document needs to provide more
> text to explain how this use case emerged. You mention “verifiable
> credential” as the “use case” but it is a technology rather than a use
> case.
>
>
>
> I've reread the introduction (which, in full disclosure, I did not write)
> and honestly feel like it does a pretty decent job of describing the
> emerging problem space and what the draft aims to provide. We c

Re: [OAUTH-WG] draft-ietf-oauth-selective-disclosure-jwt

[Hannes Tschofenig]

Thanks for the response, Brian.

A few remarks below.

From: Brian Campbell 
Sent: Tuesday, November 29, 2022 11:21 PM
To: Hannes Tschofenig 
Cc: oauth 
Subject: Re: [OAUTH-WG] draft-ietf-oauth-selective-disclosure-jwt

Hi Hannes,

Though I am yet to officially have my name on the document as a co-author, you 
did mention me directly :) And so I'll attempt to answer or respond to your 
questions/statements below.


On Mon, Nov 28, 2022 at 7:24 AM Hannes Tschofenig 
mailto:hannes.tschofe...@arm.com>> wrote:
Hi Daniel, Hi Kristina, Hi Brian,
Hi all,

Reading through draft-ietf-oauth-selective-disclosure-jwt I was wondering why 
the document defines new terminology for roles that already exist in OAuth.
For example:


  *   Issuer  =  AS
  *   Holder = Client
  *   Verifier = RS

I assume that was done intentionally. What was the rational was.

JWT itself<https://datatracker.ietf.org/doc/rfc7519/> is a product of this WG 
(as I'm sure you remember).. While JWT had important applications in OAuth, it 
was developed as a more general purpose token format and has seen widespread 
usage both in OAuth and beyond. Similarly, SD-JWT is meant to be a general 
purpose selective disclosure mechanism for JWT, which can have applications in 
OAuth but is certainly not constrained to OAuth. As such, the terminology in 
the draft aims to be generally applicable/meaningful. This is 
similar/consistent with JWT/RFC7519, which also does not use terms like AS, RS, 
or client.


[Hannes] I think the draft should provide that background.


You write:

“
One of the common use cases of a signed JWT is representing a user's identity.
“

In classical OAuth this use case should not be common. We bragged about the 
fact that you could to delegated authorization without having to rely on 
identity information. I think it would help to expand this statement a bit and 
explain what the use case is.

A signed JWT representing a user's identity is, in fact, exceedingly common. 
Even in classical OAuth the access tokens almost always convey something about 
an identity - the resource owner in OAuth parlance. The sub in introspection 
https://www.rfc-editor.org/rfc/rfc7662#section-2.2 and the JWT AT profile 
https://datatracker.ietf.org/doc/html/rfc9068#section-2.2 show this in specs, 
for example. Of course the AT format and content aren't defined by OAuth itself 
and are left up to the implementation/deployment so those optional specs don't 
tell the whole story. But every single deployment I've seen has some identity 
info in the AT for delegation.


[Hannes] This paragraph would be a good addition to the draft providing a bit 
of background.

You write:
“ As long as the signed JWT is one-time use, it typically only contains those 
claims the user has consented to disclose to a specific Verifier. However, 
there is an increasing number of use cases where a signed JWT is created once 
and then used a number of times by the user (the "Holder" of the JWT). In such 
cases, the signed JWT needs to contain the superset of all claims the user of 
the signed JWT might want to disclose to Verifiers at some point. The ability 
to selectively disclose a subset of these claims depending on the Verifier 
becomes crucial to ensure minimum disclosure and prevent Verifiers from 
obtaining claims irrelevant for the transaction at hand.
“

Using the same access token with multiple resource servers is not good security 
practice not only from a privacy point of view but also from a security point 
of view.

From reading the introduction I get the impression that you create your own 
problem that is subsequently solved in the document. Since I believe you are 
too clever to do this, I believe the document needs to provide more text to 
explain how this use case emerged. You mention “verifiable credential” as the 
“use case” but it is a technology rather than a use case.

I've reread the introduction (which, in full disclosure, I did not write) and 
honestly feel like it does a pretty decent job of describing the emerging 
problem space and what the draft aims to provide. We certainly don't want to 
leave you or any reader with the impression that the document invents a 
not-real problem only to subsequently solve it. But I'm not getting that 
impression from reading it. And I am honestly not sure how to better avoid 
giving that impression (other than writing this email, I guess).


[Hannes] The obvious solution to only disclose information relevant for a 
recipient is to provide that information. Now, you introduce a new requirement, 
namely that you want to obtain the token once and then share it with many 
recipients.

It would be good to motivate this new requirement since the solution comes with 
a certain cost.


Ciao
Hannes

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclo

Re: [OAUTH-WG] draft-ietf-oauth-selective-disclosure-jwt

[Denis]

Hi Brian,

My two cents.

1) This draft is about selective-disclosure. The draft should be 
balanced between enclosure and disclosure.

The topic of selective-enclosure should also be addressed.

In particular in OAuth, the claims to be incorporated are usually only 
selected with a coarse granularity
and the end-user (as well as the holder) has no clue about which claims 
will or will not be incorporated.


2) The draft states:

 However, anyone receiving an unencrypted JWT can read all 
of the claims.


In OAuth, the claims are considered to be opaque and SHALL not be read 
by the holder. Their semantics or content of a JWT can change at any time.

This should be mentioned in the draft.

In the privacy considerations section, another sub-section should be 
included about OAuth, i.e. a section "8.3  OAuth".


OAuth considers that the claims included into the JWT are opaque to the 
holder (i.e. the Client) when a JWT is used in the context of OAuth.
This means that the holder is unable to verify that the claims that have 
been incorporated in the JWT correspond to those that have been requested.


The Issuer is a position to include more claims or different claims from 
those that should have been incorporated. This may be a concern for some 
end users.


3) About section 8.2 Unlinkability

The text states:

   More advanced cryptographic schemes, outside the scope of 
this specification, can be used to prevent this type of linkability.


The draft by itself creates the problem since a single JWT is intended 
for multiple verifiers.
The linkability problem arises because in particular when the same "sub" 
claim is used for two different Verifiers.


The use of the following claims should be avoided (I reuse one of the 
examples):


 "given_name": "John",
"family_name": "Doe",
"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

In order to solve the problem, the use of previous claims should be 
avoided and a specific "sub" claim should be used for each verifier.


Hence, the concern could be solved using no " advanced cryptographic 
schemes " but by defining a new structure in the JWT that would allow
to associate a "sub" claim (as well as other claims) with a specific 
Verifier. A change of the SD-JWT Releases structure should be considered.


The use of this draft for end users concerned with some forms of 
linkages between verifiers should be deprecated
and this should be mentioned in the Introduction: a single JWT targeted 
to a single Verifier solves this concern.


Denis



Hi Hannes,

Though I am yet to officially have my name on the document as a 
co-author, you did mention me directly :) And so I'll attempt to 
answer or respond to your questions/statements below.


On Mon, Nov 28, 2022 at 7:24 AM Hannes Tschofenig 
 wrote:


Hi Daniel, Hi Kristina, Hi Brian,

Hi all,

Reading through draft-ietf-oauth-selective-disclosure-jwt I was
wondering why the document defines new terminology for roles that
already exist in OAuth.

For example:

  * Issuer  =  AS
  * Holder = Client
  * Verifier = RS

I assume that was done intentionally. What was the rational was.


JWT itself  is a product of 
this WG (as I'm sure you remember).. While JWT had important 
applications in OAuth, it was developed as a more general purpose 
token format and has seen widespread usage both in OAuth and beyond. 
Similarly, SD-JWT is meant to be a general purpose selective 
disclosure mechanism for JWT, which can have applications in OAuth but 
is certainly not constrained to OAuth. As such, the terminology in the 
draft aims to be generally applicable/meaningful. This is 
similar/consistent with JWT/RFC7519, which also does not use terms 
like AS, RS, or client.


 You write:

 “One of the common use cases of a signed JWT is representing a
user's identity“

 In classical OAuth this use case should not be common. We bragged
about the fact that you could to delegated authorization without
having to rely on identity information. I think it would help to
expand this statement a bit and explain what the use case is.

A signed JWT representing a user's identity is, in fact, exceedingly 
common. Even in classical OAuth the access tokens almost always convey 
something about an identity - the resource owner in OAuth parlance. 
The sub in introspection 
https://www.rfc-editor.org/rfc/rfc7662#section-2.2 and the JWT AT 
profile https://datatracker.ietf.org/doc/html/rfc9068#section-2.2 show 
this in specs, for example. Of course the AT format and content aren't 
defined by OAuth itself and are left up to the 
implementation/deployment so those optional specs don't tell the whole 
story. But every single deployment I've seen has some identity info in 
the AT 

Re: [OAUTH-WG] draft-ietf-oauth-selective-disclosure-jwt

[Brian Campbell]

Hi Hannes,

Though I am yet to officially have my name on the document as a co-author,
you did mention me directly :) And so I'll attempt to answer or respond to
your questions/statements below.


On Mon, Nov 28, 2022 at 7:24 AM Hannes Tschofenig 
wrote:

> Hi Daniel, Hi Kristina, Hi Brian,
>
> Hi all,
>
>
>
> Reading through draft-ietf-oauth-selective-disclosure-jwt I was wondering
> why the document defines new terminology for roles that already exist in
> OAuth.
>
> For example:
>
>
>
>- Issuer  =  AS
>- Holder = Client
>- Verifier = RS
>
>
>
> I assume that was done intentionally. What was the rational was.
>

JWT itself  is a product of this
WG (as I'm sure you remember).. While JWT had important applications in
OAuth, it was developed as a more general purpose token format and has seen
widespread usage both in OAuth and beyond. Similarly, SD-JWT is meant to be
a general purpose selective disclosure mechanism for JWT, which can have
applications in OAuth but is certainly not constrained to OAuth. As such,
the terminology in the draft aims to be generally applicable/meaningful.
This is similar/consistent with JWT/RFC7519, which also does not use terms
like AS, RS, or client.



>
>
> You write:
>
>
>
> “
>
> One of the common use cases of a signed JWT is representing a user's
> identity.
>
> “
>
>
>
> In classical OAuth this use case should not be common. We bragged about
> the fact that you could to delegated authorization without having to rely
> on identity information. I think it would help to expand this statement a
> bit and explain what the use case is.
>

A signed JWT representing a user's identity is, in fact, exceedingly
common. Even in classical OAuth the access tokens almost always convey
something about an identity - the resource owner in OAuth parlance. The sub
in introspection https://www.rfc-editor.org/rfc/rfc7662#section-2.2 and the
JWT AT profile https://datatracker.ietf.org/doc/html/rfc9068#section-2.2
show this in specs, for example. Of course the AT format and content aren't
defined by OAuth itself and are left up to the implementation/deployment so
those optional specs don't tell the whole story. But every single
deployment I've seen has some identity info in the AT for delegation.



You write:
>
> “ As long as the signed JWT is one-time use, it typically only contains
> those claims the user has consented to disclose to a specific Verifier.
> However, there is an increasing number of use cases where a signed JWT is
> created once and then used a number of times by the user (the "Holder" of
> the JWT). In such cases, the signed JWT needs to contain the superset of
> all claims the user of the signed JWT might want to disclose to Verifiers
> at some point. The ability to selectively disclose a subset of these claims
> depending on the Verifier becomes crucial to ensure minimum disclosure and
> prevent Verifiers from obtaining claims irrelevant for the transaction at
> hand.
>
> “
>
>
>
> Using the same access token with multiple resource servers is not good
> security practice not only from a privacy point of view but also from a
> security point of view.
>
>
>
> From reading the introduction I get the impression that you create your
> own problem that is subsequently solved in the document. Since I believe
> you are too clever to do this, I believe the document needs to provide more
> text to explain how this use case emerged. You mention “verifiable
> credential” as the “use case” but it is a technology rather than a use
> case.
>

I've reread the introduction (which, in full disclosure, I did not write)
and honestly feel like it does a pretty decent job of describing the
emerging problem space and what the draft aims to provide. We certainly
don't want to leave you or any reader with the impression that the document
invents a not-real problem only to subsequently solve it. But I'm not
getting that impression from reading it. And I am honestly not sure how to
better avoid giving that impression (other than writing this email, I
guess).


>

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