Re: [OAUTH-WG] OAuth Interim Meetings

[Aaron Parecki]

I would like to present on OAuth 2.1.

Separately, and preferably later in the series, I would like to present on
the Browser App BCP.

Thanks!

Aaron



On Sat, Sep 4, 2021 at 8:23 AM Rifaat Shekh-Yusef 
wrote:

> All,
>
> We would like to start a new series of interim meetings later in September.
> Please, let us know if you would like to present during one of
> these meetings.
>
> Regards,
>  Rifaat & Hannes
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
-- 
---
Aaron Parecki
https://aaronparecki.com
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth Interim Meetings

[Justin Richer]

I would like to present the proposed HTTP signatures draft, and separately I 
think it would also be beneficial to the OAuth wg to present an update on the 
progress of GNAP. 

-Justin

From: OAuth [oauth-boun...@ietf.org] on behalf of Rifaat Shekh-Yusef 
[rifaat.s.i...@gmail.com]
Sent: Saturday, September 4, 2021 11:22 AM
To: oauth
Subject: [OAUTH-WG] OAuth Interim Meetings

All,

We would like to start a new series of interim meetings later in September.
Please, let us know if you would like to present during one of these meetings.

Regards,
 Rifaat & Hannes

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

[OAUTH-WG] Spam apparently coming from my email address

[Thomas Broyer]

Hi all,

Someone's apparently sending spam through this list using my email address
as the sender.

I'm obviously not the author of those.

Could some of you please send me the full spam mail (with full mail
headers) ?

Thank you in advance and sorry for the inconvenience but I don't think I
can do anything about it.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] OAuth Interim Meetings

[Rifaat Shekh-Yusef]

All,

We would like to start a new series of interim meetings later in September.
Please, let us know if you would like to present during one of
these meetings.

Regards,
 Rifaat & Hannes
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] IPR Disclosures - OAuth 2.0 Authorization Server Issuer Identification

[Rifaat Shekh-Yusef]

Authors,

As part of the shepherd write-up, all authors of the document must confirm
that any and all appropriate IPR disclosures required for full conformance
with the provisions of BCP 78 and BCP 79 have already been filed.

Please, reply to this email on the mailing list and indicate if you are
aware of any IPRs associated with this document.

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

[OAUTH-WG] Implementations for OAuth 2.0 Authorization Server Issuer Identification

[Rifaat Shekh-Yusef]

All,

As part of the shepherd write-up for the OAuth 2.0 Authorization Server
Issuer Identification document, we need a list of implementations for this
specification.

Please, reply to this email on the list with any implementation details for
this document.

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

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

[Rifaat Shekh-Yusef]

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

[OAUTH-WG] I-D Action: draft-ietf-oauth-jwt-introspection-response-12.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol WG of the IETF.

Title   : JWT Response for OAuth Token Introspection
Authors : Torsten Lodderstedt
  Vladimir Dzhuvinov
Filename: draft-ietf-oauth-jwt-introspection-response-12.txt
Pages   : 19
Date: 2021-09-04

Abstract:
   This specification proposes an additional JSON Web Token (JWT)
   secured response for OAuth 2.0 Token Introspection.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-response/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwt-introspection-response-12

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-jwt-introspection-response-12


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


___
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

[Torsten Lodderstedt]

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
> ---
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.google.com/url?q=https://www.ietf.org/mailman/listinfo/oauth=gmail-imap=163132276000=AOvVaw2Fa1GyOiE6a7mRCghwMI5J


smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth