Re: [OAUTH-WG] Draft OAuth WG Agenda @ Yokohama

[Rifaat Shekh-Yusef]

Jaimandeep,

We have two side meetings at IETF116 (Wednesday and Thursday).
If you are able to work on a slide deck to discuss this topic, then we
would be happy to add that to the agenda of one of these side meetings to
allow you to present and discuss this topic.

Let us know.

Regards,
 Rifaat & Hannes


On Thu, Mar 16, 2023 at 2:15 PM Aaron Parecki  wrote:

> Hi Jaimandeep,
>
> This sounds like a good discussion to continue on the mailing list, as I
> don't think 5 minutes is enough to make any progress or come to any
> conclusions.
>
> Aaron
>
>
>
> On Thu, Mar 16, 2023 at 11:10 AM Jaimandeep Singh  40nfsu.ac...@dmarc.ietf.org> wrote:
>
>> Dear Rifaat,
>>
>> The main reason for proposing this topic was to gather the members'
>> opinions on whether the current methodology for preserving the application
>> state is adequate or there is a need to explore other alternatives. I don't
>> have any supporting documents to share at this time. My intention was
>> simply to open a discussion and assess the feasibility of alternative
>> methodologies. The topic had come up during the mailing list discussions.
>> As per my understanding, I would like to summarize the issue here:
>>
>> To ensure a better user experience, it is important to preserve the state
>> from where the OAuth process was initiated. One way to convey this
>> information is through the "state" parameter, which is passed from the
>> client to the authorization server (AS) and back. The primary purpose of
>> the "state" parameter is to mitigate Cross-Site Request Forgery (CSRF)
>> attacks, and the developers may not appreciate its use for restoring the
>> previous state of the application. The "state" parameter is impacted by all
>> the three security principles i.e confidentiality, integrity and
>> availability. The remediation measures in terms of confidentiality and
>> integrity have been well brought out by the members in the mailing list by
>> way of encryption or signing of "state" parameters. However, decryption and
>> verification of the "state" parameter incurs performance penalties.
>> Therefore, two questions arise:
>> (a) Are there any other patterns that we can look at to address the
>> concerns in terms of performance penalty?
>> (b) Is there a need to provide clear guidelines on how to restore the
>> previous state of the client application to ensure a seamless user
>> experience in upcoming RFCs?
>>
>> Regards
>> Jaimandeep Singh
>>
>>
>>
>> On Thu, Mar 16, 2023 at 5:39 PM Rifaat Shekh-Yusef <
>> rifaat.s.i...@gmail.com> wrote:
>>
>>> Hi Jaimandeep,
>>>
>>> Can you elaborate on bullet 3? Do you have a document that discusses
>>> this topic?
>>>
>>> Regards,
>>>  Rifaat
>>>
>>>
>>> On Thu, Mar 16, 2023 at 2:01 AM Jaimandeep Singh <
>>> jaimandeep.phdc...@nfsu.ac.in> wrote:
>>>
 Dear Rifaat,

 I would like to suggest following regarding the upcoming conference:

 1. It would be very beneficial if the presenters could share the
 presentation materials and discussion points for each item on the agenda
 well in advance. This would enable us to go through the same and streamline
 the discussion. IMO when the points for discussion are presented at the
 last moment, it is difficult to make meaningful contributions.

 2. Additionally, I suggest that we establish a hard cutoff time for
 each agenda item to ensure that we cover all the items on the agenda within
 the allocated time. In case of time overrun, we can continue the same in
 side discussions. In the last conference, it was observed that some agenda
 points ran over time, which meant that other important items on agenda were
 not addressed or did not get sufficient time.

 3. If the members agree, a 5-minute agenda item can be added to discuss
 the use of the "state" parameter design pattern for preserving the current
 state and the impact it may have on performance of the oauth.

 Regards
 Jaimandeep Singh

 On Wed, 15 Mar, 2023, 7:34 pm Rifaat Shekh-Yusef, <
 rifaat.s.i...@gmail.com> wrote:

> All,
>
> The following is the agenda for the official two sessions scheduled
> for the OAuth WG:
>
> *Tuesday*
>
>- *Chairs update –* Rifaat/Hannes (10 min)
>- *SD-JWT *– Kristina/Daniel – (20 min)
>- *Browser-based Apps* – Aaron (20 min)
>- *OAuth 2.1* – Aaron (20 min)
>- *Client/Trust Management *– Kristina/Torsten (20 min)
>- *Protected Resource Metadata *– Mike (15 min)
>- *Machine Identity *– Pieter (15 min)
>
>
> *Friday*
>
>- *JWT Embedded Tokens *– Rifaat/Dick (15 min)
>- *Cross Device Flow –* Pieter (15 min)
>- *Identity Chaining *– Rifaat/Pieter (20 min)
>- *Native Apps UX* – Aaron/Pieter (20 min)
>- *Authorization Server Discovery *– Aaron/Ben (20 min)
>- *PoP Security Architecture *– Nat (15 min)
>- *Power of Attorney 

Re: [OAUTH-WG] Draft OAuth WG Agenda @ Yokohama

[Aaron Parecki]

Hi Jaimandeep,

This sounds like a good discussion to continue on the mailing list, as I
don't think 5 minutes is enough to make any progress or come to any
conclusions.

Aaron



On Thu, Mar 16, 2023 at 11:10 AM Jaimandeep Singh  wrote:

> Dear Rifaat,
>
> The main reason for proposing this topic was to gather the members'
> opinions on whether the current methodology for preserving the application
> state is adequate or there is a need to explore other alternatives. I don't
> have any supporting documents to share at this time. My intention was
> simply to open a discussion and assess the feasibility of alternative
> methodologies. The topic had come up during the mailing list discussions.
> As per my understanding, I would like to summarize the issue here:
>
> To ensure a better user experience, it is important to preserve the state
> from where the OAuth process was initiated. One way to convey this
> information is through the "state" parameter, which is passed from the
> client to the authorization server (AS) and back. The primary purpose of
> the "state" parameter is to mitigate Cross-Site Request Forgery (CSRF)
> attacks, and the developers may not appreciate its use for restoring the
> previous state of the application. The "state" parameter is impacted by all
> the three security principles i.e confidentiality, integrity and
> availability. The remediation measures in terms of confidentiality and
> integrity have been well brought out by the members in the mailing list by
> way of encryption or signing of "state" parameters. However, decryption and
> verification of the "state" parameter incurs performance penalties.
> Therefore, two questions arise:
> (a) Are there any other patterns that we can look at to address the
> concerns in terms of performance penalty?
> (b) Is there a need to provide clear guidelines on how to restore the
> previous state of the client application to ensure a seamless user
> experience in upcoming RFCs?
>
> Regards
> Jaimandeep Singh
>
>
>
> On Thu, Mar 16, 2023 at 5:39 PM Rifaat Shekh-Yusef <
> rifaat.s.i...@gmail.com> wrote:
>
>> Hi Jaimandeep,
>>
>> Can you elaborate on bullet 3? Do you have a document that discusses this
>> topic?
>>
>> Regards,
>>  Rifaat
>>
>>
>> On Thu, Mar 16, 2023 at 2:01 AM Jaimandeep Singh <
>> jaimandeep.phdc...@nfsu.ac.in> wrote:
>>
>>> Dear Rifaat,
>>>
>>> I would like to suggest following regarding the upcoming conference:
>>>
>>> 1. It would be very beneficial if the presenters could share the
>>> presentation materials and discussion points for each item on the agenda
>>> well in advance. This would enable us to go through the same and streamline
>>> the discussion. IMO when the points for discussion are presented at the
>>> last moment, it is difficult to make meaningful contributions.
>>>
>>> 2. Additionally, I suggest that we establish a hard cutoff time for each
>>> agenda item to ensure that we cover all the items on the agenda within the
>>> allocated time. In case of time overrun, we can continue the same in side
>>> discussions. In the last conference, it was observed that some agenda
>>> points ran over time, which meant that other important items on agenda were
>>> not addressed or did not get sufficient time.
>>>
>>> 3. If the members agree, a 5-minute agenda item can be added to discuss
>>> the use of the "state" parameter design pattern for preserving the current
>>> state and the impact it may have on performance of the oauth.
>>>
>>> Regards
>>> Jaimandeep Singh
>>>
>>> On Wed, 15 Mar, 2023, 7:34 pm Rifaat Shekh-Yusef, <
>>> rifaat.s.i...@gmail.com> wrote:
>>>
 All,

 The following is the agenda for the official two sessions scheduled for
 the OAuth WG:

 *Tuesday*

- *Chairs update –* Rifaat/Hannes (10 min)
- *SD-JWT *– Kristina/Daniel – (20 min)
- *Browser-based Apps* – Aaron (20 min)
- *OAuth 2.1* – Aaron (20 min)
- *Client/Trust Management *– Kristina/Torsten (20 min)
- *Protected Resource Metadata *– Mike (15 min)
- *Machine Identity *– Pieter (15 min)


 *Friday*

- *JWT Embedded Tokens *– Rifaat/Dick (15 min)
- *Cross Device Flow –* Pieter (15 min)
- *Identity Chaining *– Rifaat/Pieter (20 min)
- *Native Apps UX* – Aaron/Pieter (20 min)
- *Authorization Server Discovery *– Aaron/Ben (20 min)
- *PoP Security Architecture *– Nat (15 min)
- *Power of Attorney (PoA) Grant Type *– Olov (15 min)


 Please, let us know if you have any comments about the above agenda.

 Regards,
  Rifaat & Hannes

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

>>>
>
> --
> Regards and Best Wishes
> Jaimandeep Singh
> LinkedIn 
> ___
> OAuth mailing list
> 

Re: [OAUTH-WG] Draft OAuth WG Agenda @ Yokohama

[Jaimandeep Singh]

Dear Rifaat,

The main reason for proposing this topic was to gather the members'
opinions on whether the current methodology for preserving the application
state is adequate or there is a need to explore other alternatives. I don't
have any supporting documents to share at this time. My intention was
simply to open a discussion and assess the feasibility of alternative
methodologies. The topic had come up during the mailing list discussions.
As per my understanding, I would like to summarize the issue here:

To ensure a better user experience, it is important to preserve the state
from where the OAuth process was initiated. One way to convey this
information is through the "state" parameter, which is passed from the
client to the authorization server (AS) and back. The primary purpose of
the "state" parameter is to mitigate Cross-Site Request Forgery (CSRF)
attacks, and the developers may not appreciate its use for restoring the
previous state of the application. The "state" parameter is impacted by all
the three security principles i.e confidentiality, integrity and
availability. The remediation measures in terms of confidentiality and
integrity have been well brought out by the members in the mailing list by
way of encryption or signing of "state" parameters. However, decryption and
verification of the "state" parameter incurs performance penalties.
Therefore, two questions arise:
(a) Are there any other patterns that we can look at to address the
concerns in terms of performance penalty?
(b) Is there a need to provide clear guidelines on how to restore the
previous state of the client application to ensure a seamless user
experience in upcoming RFCs?

Regards
Jaimandeep Singh



On Thu, Mar 16, 2023 at 5:39 PM Rifaat Shekh-Yusef 
wrote:

> Hi Jaimandeep,
>
> Can you elaborate on bullet 3? Do you have a document that discusses this
> topic?
>
> Regards,
>  Rifaat
>
>
> On Thu, Mar 16, 2023 at 2:01 AM Jaimandeep Singh <
> jaimandeep.phdc...@nfsu.ac.in> wrote:
>
>> Dear Rifaat,
>>
>> I would like to suggest following regarding the upcoming conference:
>>
>> 1. It would be very beneficial if the presenters could share the
>> presentation materials and discussion points for each item on the agenda
>> well in advance. This would enable us to go through the same and streamline
>> the discussion. IMO when the points for discussion are presented at the
>> last moment, it is difficult to make meaningful contributions.
>>
>> 2. Additionally, I suggest that we establish a hard cutoff time for each
>> agenda item to ensure that we cover all the items on the agenda within the
>> allocated time. In case of time overrun, we can continue the same in side
>> discussions. In the last conference, it was observed that some agenda
>> points ran over time, which meant that other important items on agenda were
>> not addressed or did not get sufficient time.
>>
>> 3. If the members agree, a 5-minute agenda item can be added to discuss
>> the use of the "state" parameter design pattern for preserving the current
>> state and the impact it may have on performance of the oauth.
>>
>> Regards
>> Jaimandeep Singh
>>
>> On Wed, 15 Mar, 2023, 7:34 pm Rifaat Shekh-Yusef, <
>> rifaat.s.i...@gmail.com> wrote:
>>
>>> All,
>>>
>>> The following is the agenda for the official two sessions scheduled for
>>> the OAuth WG:
>>>
>>> *Tuesday*
>>>
>>>- *Chairs update –* Rifaat/Hannes (10 min)
>>>- *SD-JWT *– Kristina/Daniel – (20 min)
>>>- *Browser-based Apps* – Aaron (20 min)
>>>- *OAuth 2.1* – Aaron (20 min)
>>>- *Client/Trust Management *– Kristina/Torsten (20 min)
>>>- *Protected Resource Metadata *– Mike (15 min)
>>>- *Machine Identity *– Pieter (15 min)
>>>
>>>
>>> *Friday*
>>>
>>>- *JWT Embedded Tokens *– Rifaat/Dick (15 min)
>>>- *Cross Device Flow –* Pieter (15 min)
>>>- *Identity Chaining *– Rifaat/Pieter (20 min)
>>>- *Native Apps UX* – Aaron/Pieter (20 min)
>>>- *Authorization Server Discovery *– Aaron/Ben (20 min)
>>>- *PoP Security Architecture *– Nat (15 min)
>>>- *Power of Attorney (PoA) Grant Type *– Olov (15 min)
>>>
>>>
>>> Please, let us know if you have any comments about the above agenda.
>>>
>>> Regards,
>>>  Rifaat & Hannes
>>>
>>> ___
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>

-- 
Regards and Best Wishes
Jaimandeep Singh
LinkedIn 
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Draft OAuth WG Agenda @ Yokohama

[Rifaat Shekh-Yusef]

Hi Jaimandeep,

Can you elaborate on bullet 3? Do you have a document that discusses this
topic?

Regards,
 Rifaat


On Thu, Mar 16, 2023 at 2:01 AM Jaimandeep Singh <
jaimandeep.phdc...@nfsu.ac.in> wrote:

> Dear Rifaat,
>
> I would like to suggest following regarding the upcoming conference:
>
> 1. It would be very beneficial if the presenters could share the
> presentation materials and discussion points for each item on the agenda
> well in advance. This would enable us to go through the same and streamline
> the discussion. IMO when the points for discussion are presented at the
> last moment, it is difficult to make meaningful contributions.
>
> 2. Additionally, I suggest that we establish a hard cutoff time for each
> agenda item to ensure that we cover all the items on the agenda within the
> allocated time. In case of time overrun, we can continue the same in side
> discussions. In the last conference, it was observed that some agenda
> points ran over time, which meant that other important items on agenda were
> not addressed or did not get sufficient time.
>
> 3. If the members agree, a 5-minute agenda item can be added to discuss
> the use of the "state" parameter design pattern for preserving the current
> state and the impact it may have on performance of the oauth.
>
> Regards
> Jaimandeep Singh
>
> On Wed, 15 Mar, 2023, 7:34 pm Rifaat Shekh-Yusef, 
> wrote:
>
>> All,
>>
>> The following is the agenda for the official two sessions scheduled for
>> the OAuth WG:
>>
>> *Tuesday*
>>
>>- *Chairs update –* Rifaat/Hannes (10 min)
>>- *SD-JWT *– Kristina/Daniel – (20 min)
>>- *Browser-based Apps* – Aaron (20 min)
>>- *OAuth 2.1* – Aaron (20 min)
>>- *Client/Trust Management *– Kristina/Torsten (20 min)
>>- *Protected Resource Metadata *– Mike (15 min)
>>- *Machine Identity *– Pieter (15 min)
>>
>>
>> *Friday*
>>
>>- *JWT Embedded Tokens *– Rifaat/Dick (15 min)
>>- *Cross Device Flow –* Pieter (15 min)
>>- *Identity Chaining *– Rifaat/Pieter (20 min)
>>- *Native Apps UX* – Aaron/Pieter (20 min)
>>- *Authorization Server Discovery *– Aaron/Ben (20 min)
>>- *PoP Security Architecture *– Nat (15 min)
>>- *Power of Attorney (PoA) Grant Type *– Olov (15 min)
>>
>>
>> Please, let us know if you have any comments about the above agenda.
>>
>> Regards,
>>  Rifaat & Hannes
>>
>> ___
>> 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] Draft OAuth WG Agenda @ Yokohama

[Jaimandeep Singh]

Dear Rifaat,

I would like to suggest following regarding the upcoming conference:

1. It would be very beneficial if the presenters could share the
presentation materials and discussion points for each item on the agenda
well in advance. This would enable us to go through the same and streamline
the discussion. IMO when the points for discussion are presented at the
last moment, it is difficult to make meaningful contributions.

2. Additionally, I suggest that we establish a hard cutoff time for each
agenda item to ensure that we cover all the items on the agenda within the
allocated time. In case of time overrun, we can continue the same in side
discussions. In the last conference, it was observed that some agenda
points ran over time, which meant that other important items on agenda were
not addressed or did not get sufficient time.

3. If the members agree, a 5-minute agenda item can be added to discuss the
use of the "state" parameter design pattern for preserving the current
state and the impact it may have on performance of the oauth.

Regards
Jaimandeep Singh

On Wed, 15 Mar, 2023, 7:34 pm Rifaat Shekh-Yusef, 
wrote:

> All,
>
> The following is the agenda for the official two sessions scheduled for
> the OAuth WG:
>
> *Tuesday*
>
>- *Chairs update –* Rifaat/Hannes (10 min)
>- *SD-JWT *– Kristina/Daniel – (20 min)
>- *Browser-based Apps* – Aaron (20 min)
>- *OAuth 2.1* – Aaron (20 min)
>- *Client/Trust Management *– Kristina/Torsten (20 min)
>- *Protected Resource Metadata *– Mike (15 min)
>- *Machine Identity *– Pieter (15 min)
>
>
> *Friday*
>
>- *JWT Embedded Tokens *– Rifaat/Dick (15 min)
>- *Cross Device Flow –* Pieter (15 min)
>- *Identity Chaining *– Rifaat/Pieter (20 min)
>- *Native Apps UX* – Aaron/Pieter (20 min)
>- *Authorization Server Discovery *– Aaron/Ben (20 min)
>- *PoP Security Architecture *– Nat (15 min)
>- *Power of Attorney (PoA) Grant Type *– Olov (15 min)
>
>
> Please, let us know if you have any comments about the above agenda.
>
> Regards,
>  Rifaat & Hannes
>
> ___
> 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

[OAUTH-WG] Draft OAuth WG Agenda @ Yokohama

[Rifaat Shekh-Yusef]

All,

The following is the agenda for the official two sessions scheduled for the
OAuth WG:

*Tuesday*

   - *Chairs update –* Rifaat/Hannes (10 min)
   - *SD-JWT *– Kristina/Daniel – (20 min)
   - *Browser-based Apps* – Aaron (20 min)
   - *OAuth 2.1* – Aaron (20 min)
   - *Client/Trust Management *– Kristina/Torsten (20 min)
   - *Protected Resource Metadata *– Mike (15 min)
   - *Machine Identity *– Pieter (15 min)


*Friday*

   - *JWT Embedded Tokens *– Rifaat/Dick (15 min)
   - *Cross Device Flow –* Pieter (15 min)
   - *Identity Chaining *– Rifaat/Pieter (20 min)
   - *Native Apps UX* – Aaron/Pieter (20 min)
   - *Authorization Server Discovery *– Aaron/Ben (20 min)
   - *PoP Security Architecture *– Nat (15 min)
   - *Power of Attorney (PoA) Grant Type *– Olov (15 min)


Please, let us know if you have any comments about the above agenda.

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