[Wimse] Re: [EXTERNAL] Re: Request for Input: Best Current Practice for OAuth 2.0 Client Authentication in Workload Environments

[Yaron Sheffer <[e-mail]>]

I agree with Arndt on the selection of option A: document existing practices but without labelling them as BCP.

 

I disagree about the separate document he proposes, because I think once we are further along with the WIMSE solution, we can work with the Kubernetes (and/or service mesh) communities to come up with better solutions, rather than keep with the old file-based hacks. If we write a BCP too early we face the risk of ossifying bad practices.

 

Thanks,

                Yaron

 

 

From: Arndt Schwenkschuster <[e-mail]>
Date: Tuesday, 30 July 2024 at 13:04
To: Andrii Deinega <[e-mail]>, Flemming Andreasen (fandreas) <fandreas=[e-mail]>
Cc: Pieter Kasselman <pieter.kasselman=[e-mail]>, [e-mail] <[e-mail]>, Justin Richer <[e-mail]>
Subject: [Wimse] Re: [EXTERNAL] Re: Request for Input: Best Current Practice for OAuth 2.0 Client Authentication in Workload Environments

TLDR: I vote for A.

 

As one of the authors, I see value in documenting existing patterns and believe it’s crucial to do this as soon as possible.

On the other hand, I understand the concern labelling this as “best current practices”.

I would like to propose to:

• Move forward with the current scope as “Informational"
• Others and I work together to start a new individual draft BCP which contains a wider scope including proof of possession and other aspects (for example Andrii’s feedback) the current scope does not consider. I believe this work can be built on top of the service-to-service authentication work, which is currently in call for adoption where token format and other things are defined.

 

-Arndt

 

From: Andrii Deinega <[e-mail]>
Date: Monday, 29 July 2024 at 23:57
To: Flemming Andreasen (fandreas) <fandreas=[e-mail]>
Cc: Pieter Kasselman <pieter.kasselman=[e-mail]>, [e-mail] <[e-mail]>, Justin Richer <[e-mail]>
Subject: [EXTERNAL] [Wimse] Re: Request for Input: Best Current Practice for OAuth 2.0 Client Authentication in Workload Environments

You don't often get email from [e-mail]. https://aka.ms/LearnAboutSenderIdentification" rel="nofollow">Learn why this is important

Pieter, I choose to go with C.

 

ATs need to be protected from replay attacks, there must be a proof of possession mechanism in place, without that we can't simply refer to it as BCP.

 

https://mailarchive.ietf.org/arch/msg/wimse/HeF1jAzR6p1BPT_jx_6MuLN7WM0" rel="nofollow">https://mailarchive.ietf.org/arch/msg/wimse/HeF1jAzR6p1BPT_jx_6MuLN7WM0 is also my feedback on this document.

 

All the best,

Andrii

 

 

On Mon, Jul 29, 2024 at 3:17 PM Flemming Andreasen (fandreas) <fandreas=[e-mail]> wrote:

Given the choices, I would go for option A (i.e. no specific recommendations), the reason being I don't think it makes a lot of sense for WIMSE to recommend one thing based purely on OAuth access tokens, when we may end up specifying something different using WIMSE tokens (or whatever we end up calling it). I do think pointing out potential issues with current mechanisms would be helpful though.

Thanks

-- Flemming

On 7/29/24 06:21, Pieter Kasselman wrote:

During the Working Group meeting in Vancouver there was discussion on the scope of the Working Group document titled Best Current Practice for OAuth 2.0 Client Authentication in Workload Environments [1], which was adopted in accordance with the following deliverable in the charter [2]:

 

• [I or BCP] Document and make recommendations based on operational experience to existing token distribution practices for workloads.

 

This is intended to respond to the following milestone [3]:

 

• Submit informational document describing considerations for filesystem-based JWT delivery in Kubernetes to the IESG

 

Please reply to the list to indicate which of the following options represent the appropriate scope for this document:

 

1. Document existing practices without specific recommendations on how to obtain, protect and use OAuth Access Tokens.
2. Document existing practices along with strong recommendations on how to obtain, protect and use OAuth Access Tokens.
3. Need more information (please state what more information you need).
4. No opinion (i.e., this isn’t a topic you care strongly about).

Please reply to the list by August 12th, 2024.

 

Thank you,

 

Pieter and Justin

 

[1] https://datatracker.ietf.org/doc/draft-ietf-wimse-workload-identity-bcp/" rel="nofollow">https://datatracker.ietf.org/doc/draft-ietf-wimse-workload-identity-bcp/

[2] https://datatracker.ietf.org/doc/charter-ietf-wimse/" rel="nofollow">https://datatracker.ietf.org/doc/charter-ietf-wimse/

[3] https://datatracker.ietf.org/wg/wimse/about/" rel="nofollow">https://datatracker.ietf.org/wg/wimse/about/

 

 

--
Wimse mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]