[OAUTH-WG] Protocol Action: 'JWT Response for OAuth Token Introspection' to Proposed Standard (draft-ietf-oauth-jwt-introspection-response-12.txt)

[The IESG]

The IESG has approved the following document:
- 'JWT Response for OAuth Token Introspection'
  (draft-ietf-oauth-jwt-introspection-response-12.txt) as Proposed Standard

This document is the product of the Web Authorization Protocol Working Group.

The IESG contact persons are Benjamin Kaduk and Roman Danyliw.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-response/





Technical Summary

   This draft proposes an additional JSON Web Token (JWT) based response
   for OAuth 2.0 Token Introspection.

Working Group Summary

The document received many reviews and feedback from multiple WG members on the 
mailing list and during the WG meetings.

During initial IESG review, it received a DISCUSS that required a change of 
sufficient scope that that it was returned to the WG.  The WG addressed the 
issue and the document again went through WGLC and IETF LC.  The proposed 
change moves the data of the introspected token into a top-level JWT claim to 
allow for the separation of the carrier JWT claims from the actual 
token introspection response claims.

Document Quality:

The document has been implemented by the following:

* node.js OSS oidc-provider implements the document in full behind an optional 
feature toggle
https://github.com/panva/node-oidc-provider/blob/master/docs/README.md#featuresjwtintrospection

* connect2id has an implementation:
https://connect2id.com/products/server/docs/api/token-introspection

* ForgeRock:
https://github.com/ForgeRock/PSD2-Accelerators/tree/yes.com/openig/yes-openig-signed-introspect-filter

Personnel:

The document shepherd is Rifaat Shekh-Yusef. 
The responsible Area Director is Roman Danyliw.

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

[OAUTH-WG] No OAuth WG Virtual Office Hours today

[Hannes Tschofenig]

Hi all,

Due to the holiday in the US and in Canada we are skipping the call today.

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 disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] RAR 05 - Token response with sensitive data in draft-ietf-oauth-rar-05

[Jacob Ideskog]

Thank you Torsten, that's a good addition, it helps to have that clarified.

BR
Jacob

Den mån 6 sep. 2021 kl 16:05 skrev Torsten Lodderstedt <
tors...@lodderstedt.net>:

> Hi Jacob,
>
> and here is the PR https://github.com/oauthstuff/draft-oauth-rar/pull/79 for
> review.
>
> Thanks for the proposed text. I modified it a bit because I think the AS
> should only omit data (not mask) and data can be provided even if
> considered sensitive as long as there is a reasonable purpose and a legal
> basis.
>
> best regards,
> Torsten.
>
> Am 06.09.2021 um 09:52 schrieb Jacob Ideskog :
>
> Yes, privacy considerations could be more explicit about this. It should
> probably explicitly mention the token response and the Client.
>
> I also suggest clarifying in 7 or 7.1 that the token response MAY be less
> explicit or even different than the authorization details issued in the
> tokens.
>
> This is not simple, since it may lead the Client to think it has more (or
> less) access than it actually does, but since the intended audience of the
> authorized data is the RS it should be ok.
> A scenario I see is that the client requests Account access based on
> pseudonyms or names of the accounts ("accounts" : ["foo", "bar"]) . The AS
> replaces these with the actual account numbers ("accounts" : ["123-123",
> "234-BCD"]) so the RS doesn't have
> to deal with those translations. So: in the token response the pseudonyms
> are still used, but in the issued token the explicit account values are
> used.
>
> Suggestion for  section 7:
> "The AS MAY omit, mask or hide values in the authorization_details to the
> Client in the Token Response if these are deemed sensitive and of no
> intended use for the Client."
>
> Something in that direction would make it more clear that it is allowed to
> do so, and that the Token Response doesn't prevent the issued token from
> containing sensitive data.
>
> /Jacob
>
>
> Den lör 4 sep. 2021 kl 11:41 skrev Torsten Lodderstedt <
> tors...@lodderstedt.net>:
>
>> The AS intentionally shares the list of accounts in the mentioned example
>> with the client. The assumption is the client asks for access to some
>> accounts and the user decides which accounts to grant the client access to.
>> This means the AS is authorized by the user to share this data.
>>
>> The privacy considerations section already has text about sharing data
>> with resource servers. I suggest to add some text re data sharing with
>> clients.
>>
>> Would that work for you?
>>
>> > Am 04.09.2021 um 03:12 schrieb Justin Richer :
>> >
>> > This is a fair point... The privacy and security considerations talk
>> about this a bit as I recall, but likely need to in more depth and
>> specificity. This is an intentional message channel to the client from the
>> AS, but if the AS is blindly sending all information it might be saying
>> more than it means to say to an entity that doesn't need that detail to
>> function. Scopes have similar issues, but this structure adds more
>> opportunities for mistakes just due to the possible increased complexity.
>> >
>> > -Justin
>> > 
>> > From: OAuth [oauth-boun...@ietf.org] on behalf of Jacob Ideskog [
>> jacob.ides...@curity.io]
>> > Sent: Friday, September 3, 2021 10:42 AM
>> > To: oauth
>> > Subject: [OAUTH-WG] RAR 05 - Token response with sensitive data in
>> draft-ietf-oauth-rar-05
>> >
>> > Hi all,
>> >
>> > I have a question about section 7.0 and 7.1 in draft-ietf-oauth-rar-05
>> that describes the token response.
>> >
>> > The authorization_details values could be sensitive in their nature.
>> The example in section 7.1 highlights this nicely. The accounts array is
>> empty when the client requests it, but is enriched by the AS and returned
>> to the client in the token response.
>> >
>> > This means that the AS may leak potentially sensitive information to
>> the client in a new place. Before this was only possible in the ID Token or
>> UserInfo or if the AS returned a JWT as an access token which the client
>> popped open (even though it shouldn't).
>> >
>> > I understand that the spec considers this an option for the AS to
>> enrich or not. I think the enrichment is good and necessary, but with the
>> side-effect of it ending up in the token response it becomes an issue.
>> >
>> > Is the token response a mirror of the authorization_details claim in
>> the corresponding access token, or can it be a masked version?
>> >
>> > Perhaps the security considerations section should be updated with a
>> statement with regards to the fact that the client may see claim data only
>> intended for the RS?
>> >
>> > Regards
>> > Jacob Ideskog
>> >
>> >
>> >
>> > --
>> > Jacob Ideskog
>> > CTO
>> > Curity AB
>> > ---
>> > Sankt Göransgatan 66, Stockholm, Sweden
>> > M: +46 70-2233664
>> > ja...@curity.io
>> > curity.io
>> 

Re: [OAUTH-WG] RAR 05 - Token response with sensitive data in draft-ietf-oauth-rar-05

[Torsten Lodderstedt]

Hi Jacob, 

and here is the PR https://github.com/oauthstuff/draft-oauth-rar/pull/79 
 for review. 

Thanks for the proposed text. I modified it a bit because I think the AS should 
only omit data (not mask) and data can be provided even if considered sensitive 
as long as there is a reasonable purpose and a legal basis. 

best regards,
Torsten. 

> Am 06.09.2021 um 09:52 schrieb Jacob Ideskog :
> 
> Yes, privacy considerations could be more explicit about this. It should 
> probably explicitly mention the token response and the Client.
> 
> I also suggest clarifying in 7 or 7.1 that the token response MAY be less 
> explicit or even different than the authorization details issued in the 
> tokens.
> 
> This is not simple, since it may lead the Client to think it has more (or 
> less) access than it actually does, but since the intended audience of the 
> authorized data is the RS it should be ok.
> A scenario I see is that the client requests Account access based on 
> pseudonyms or names of the accounts ("accounts" : ["foo", "bar"]) . The AS 
> replaces these with the actual account numbers ("accounts" : ["123-123", 
> "234-BCD"]) so the RS doesn't have
> to deal with those translations. So: in the token response the pseudonyms are 
> still used, but in the issued token the explicit account values are used.
> 
> Suggestion for  section 7:
> "The AS MAY omit, mask or hide values in the authorization_details to the 
> Client in the Token Response if these are deemed sensitive and of no intended 
> use for the Client."
> 
> Something in that direction would make it more clear that it is allowed to do 
> so, and that the Token Response doesn't prevent the issued token from 
> containing sensitive data.
> 
> /Jacob
> 
> 
> Den lör 4 sep. 2021 kl 11:41 skrev Torsten Lodderstedt 
> mailto:tors...@lodderstedt.net>>:
> The AS intentionally shares the list of accounts in the mentioned example 
> with the client. The assumption is the client asks for access to some 
> accounts and the user decides which accounts to grant the client access to. 
> This means the AS is authorized by the user to share this data.
> 
> The privacy considerations section already has text about sharing data with 
> resource servers. I suggest to add some text re data sharing with clients.
> 
> Would that work for you?
> 
> > Am 04.09.2021 um 03:12 schrieb Justin Richer  > >:
> > 
> > This is a fair point... The privacy and security considerations talk about 
> > this a bit as I recall, but likely need to in more depth and specificity. 
> > This is an intentional message channel to the client from the AS, but if 
> > the AS is blindly sending all information it might be saying more than it 
> > means to say to an entity that doesn't need that detail to function. Scopes 
> > have similar issues, but this structure adds more opportunities for 
> > mistakes just due to the possible increased complexity. 
> > 
> > -Justin
> > 
> > From: OAuth [oauth-boun...@ietf.org ] on 
> > behalf of Jacob Ideskog [jacob.ides...@curity.io 
> > ]
> > Sent: Friday, September 3, 2021 10:42 AM
> > To: oauth
> > Subject: [OAUTH-WG] RAR 05 - Token response with sensitive data in 
> > draft-ietf-oauth-rar-05
> > 
> > Hi all,
> > 
> > I have a question about section 7.0 and 7.1 in draft-ietf-oauth-rar-05 that 
> > describes the token response.
> > 
> > The authorization_details values could be sensitive in their nature. The 
> > example in section 7.1 highlights this nicely. The accounts array is empty 
> > when the client requests it, but is enriched by the AS and returned to the 
> > client in the token response.
> > 
> > This means that the AS may leak potentially sensitive information to the 
> > client in a new place. Before this was only possible in the ID Token or 
> > UserInfo or if the AS returned a JWT as an access token which the client 
> > popped open (even though it shouldn't).
> > 
> > I understand that the spec considers this an option for the AS to enrich or 
> > not. I think the enrichment is good and necessary, but with the side-effect 
> > of it ending up in the token response it becomes an issue.
> > 
> > Is the token response a mirror of the authorization_details claim in the 
> > corresponding access token, or can it be a masked version?
> > 
> > Perhaps the security considerations section should be updated with a 
> > statement with regards to the fact that the client may see claim data only 
> > intended for the RS?
> > 
> > Regards
> > Jacob Ideskog
> > 
> > 
> > 
> > --
> > Jacob Ideskog
> > CTO
> > Curity AB
> > ---
> > Sankt Göransgatan 66, Stockholm, Sweden
> > M: +46 70-2233664
> > j>a...@curity.io 
> > 

Re: [OAUTH-WG] Doc Shepherd Review - OAuth 2.0 Authorization Server Issuer Identification

[Karsten Meyer zu Selhausen]

Hi Rifaat,

thank you for the shepherd's review.

Those are valid comments. We will have a second look on this paragraph.

Best regards,
Karsten

On 04.09.2021 16:20, Rifaat Shekh-Yusef wrote:

Hi Karsten, Daniel,

As the document shepherd, I have reviewed the document and I have the 
following comments on draft-ietf-oauth-iss-auth-resp-01 version:



Section 2.4, paragraph 3, first sentence:

"If clients interact with both authorization servers supporting this
   specification and authorization servers not supporting this
   specification, clients SHOULD store the information which
   authorization server supports the "iss" parameter."

Why is this a SHOULD?


"Clients MUST
   reject authorization responses without the "iss" parameter from
   authorization servers which do support the parameter according to the
   client's configuration."

What should the client do when it receives a response with "iss" parameter
from an authorization server that did not indicate its support for 
this parameter?



Section 7

RFC6479 should be replaced with *RFC6749*


Regards,
  Rifaat

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


--
Karsten Meyer zu Selhausen
Senior IT Security Consultant
Phone:  +49 (0)234 / 54456499
Web:https://hackmanit.de | IT Security Consulting, Penetration Testing, 
Security Training

Is your OAuth or OpenID Connect application vulnerable to mix-up attacks? Find 
out more on our blog:
https://www.hackmanit.de/en/blog-en/132-how-to-protect-your-oauth-client-against-mix-up-attacks

Hackmanit GmbH
Universitätsstraße 60 (Exzenterhaus)
44789 Bochum

Registergericht: Amtsgericht Bochum, HRB 14896
Geschäftsführer: Prof. Dr. Jörg Schwenk, Prof. Dr. Juraj Somorovsky, Dr. 
Christian Mainka, Prof. Dr. Marcus Niemietz



OpenPGP_signature
Description: OpenPGP digital signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] RAR 05 - Token response with sensitive data in draft-ietf-oauth-rar-05

[Jacob Ideskog]

Yes, privacy considerations could be more explicit about this. It should
probably explicitly mention the token response and the Client.

I also suggest clarifying in 7 or 7.1 that the token response MAY be less
explicit or even different than the authorization details issued in the
tokens.

This is not simple, since it may lead the Client to think it has more (or
less) access than it actually does, but since the intended audience of the
authorized data is the RS it should be ok.
A scenario I see is that the client requests Account access based on
pseudonyms or names of the accounts ("accounts" : ["foo", "bar"]) . The AS
replaces these with the actual account numbers ("accounts" : ["123-123",
"234-BCD"]) so the RS doesn't have
to deal with those translations. So: in the token response the pseudonyms
are still used, but in the issued token the explicit account values are
used.

Suggestion for  section 7:
"The AS MAY omit, mask or hide values in the authorization_details to the
Client in the Token Response if these are deemed sensitive and of no
intended use for the Client."

Something in that direction would make it more clear that it is allowed to
do so, and that the Token Response doesn't prevent the issued token from
containing sensitive data.

/Jacob


Den lör 4 sep. 2021 kl 11:41 skrev Torsten Lodderstedt <
tors...@lodderstedt.net>:

> The AS intentionally shares the list of accounts in the mentioned example
> with the client. The assumption is the client asks for access to some
> accounts and the user decides which accounts to grant the client access to.
> This means the AS is authorized by the user to share this data.
>
> The privacy considerations section already has text about sharing data
> with resource servers. I suggest to add some text re data sharing with
> clients.
>
> Would that work for you?
>
> > Am 04.09.2021 um 03:12 schrieb Justin Richer :
> >
> > This is a fair point... The privacy and security considerations talk
> about this a bit as I recall, but likely need to in more depth and
> specificity. This is an intentional message channel to the client from the
> AS, but if the AS is blindly sending all information it might be saying
> more than it means to say to an entity that doesn't need that detail to
> function. Scopes have similar issues, but this structure adds more
> opportunities for mistakes just due to the possible increased complexity.
> >
> > -Justin
> > 
> > From: OAuth [oauth-boun...@ietf.org] on behalf of Jacob Ideskog [
> jacob.ides...@curity.io]
> > Sent: Friday, September 3, 2021 10:42 AM
> > To: oauth
> > Subject: [OAUTH-WG] RAR 05 - Token response with sensitive data in
> draft-ietf-oauth-rar-05
> >
> > Hi all,
> >
> > I have a question about section 7.0 and 7.1 in draft-ietf-oauth-rar-05
> that describes the token response.
> >
> > The authorization_details values could be sensitive in their nature. The
> example in section 7.1 highlights this nicely. The accounts array is empty
> when the client requests it, but is enriched by the AS and returned to the
> client in the token response.
> >
> > This means that the AS may leak potentially sensitive information to the
> client in a new place. Before this was only possible in the ID Token or
> UserInfo or if the AS returned a JWT as an access token which the client
> popped open (even though it shouldn't).
> >
> > I understand that the spec considers this an option for the AS to enrich
> or not. I think the enrichment is good and necessary, but with the
> side-effect of it ending up in the token response it becomes an issue.
> >
> > Is the token response a mirror of the authorization_details claim in the
> corresponding access token, or can it be a masked version?
> >
> > Perhaps the security considerations section should be updated with a
> statement with regards to the fact that the client may see claim data only
> intended for the RS?
> >
> > Regards
> > Jacob Ideskog
> >
> >
> >
> > --
> > Jacob Ideskog
> > CTO
> > Curity AB
> > ---
> > Sankt Göransgatan 66, Stockholm, Sweden
> > M: +46 70-2233664
> > ja...@curity.io
> > curity.io<
> https://www.google.com/url?q=http://curity.io=gmail-imap=163132276000=AOvVaw0O7NO5RiGVK6v1SxLCSz4k
> >
> > ---
> >
> > ___
> > OAuth mailing list
> > OAuth@ietf.org
> >
> https://www.google.com/url?q=https://www.ietf.org/mailman/listinfo/oauth=gmail-imap=163132276000=AOvVaw2Fa1GyOiE6a7mRCghwMI5J
>


-- 
Jacob Ideskog
CTO
Curity AB
---
Sankt Göransgatan 66, Stockholm, Sweden
M: +46 70-2233664
j a...@curity.io
curity.io
---
___
OAuth mailing list