Re: [Wimse] Roman Danyliw's Block on charter-ietf-wimse-00-01: (with BLOCK and COMMENT)

[Roman Danyliw <[e-mail]>]

Hi Joe!

From: Joseph Salowey <[e-mail]>
Sent: Thursday, February 15, 2024 1:58 PM
To: Justin Richer <[e-mail]>
Cc: Roman Danyliw <[e-mail]>; The IESG <[e-mail]>; [e-mail]; [e-mail]
Subject: Re: [Wimse] Roman Danyliw's Block on charter-ietf-wimse-00-01: (with BLOCK and COMMENT)

Warning: External Sender - do not click links or open attachments unless you recognize the sender and know the content is safe.



On Thu, Feb 15, 2024 at 7:25 AM Justin Richer <[e-mail]<mailto:[e-mail]>> wrote:
Hi Roman, thanks for the review of the charter. Responses inline below — and to be clear, these represent my own interpretations of discussions, and I would welcome others on the list to chime in.

— Justin


On Feb 14, 2024, at 9:33 PM, Roman Danyliw via Datatracker <[e-mail]<mailto:[e-mail]>> wrote:

Roman Danyliw has entered the following ballot position for
charter-ietf-wimse-00-01: Block

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)



The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-wimse/



----------------------------------------------------------------------
BLOCK:
----------------------------------------------------------------------

** The text in the goals section appears to be extremely open ended.  How will
the WG know it is done?  Is it possible to describe to describe a narrower
initial tranche of work and recharter later?  Is the intent to have a long
standing WG?  More specific are in the comments.

** If “non-HTTP transport protocols that are found in workload deployments,
such as GraphQL, gRPC, and Kafka” is in scope, can the deliverables please be
described.

The expectation is that this would be a long standing working group that’s specifically focused on the technology area in question.

Workloads present a reasonably broad technology area that’s applicable to a very large community (e.g., companies that have service-based architectures and large scales), and therefore the intent is to charter a working group to bring together the expertise to work on problems in this area. From all of our initial conversations, it’s clear that there is a wide need for work in this space for solutions that account for the specific concerns that workloads bring to the table. Since this is a massive space, with a lot of interest and investment right now, we also realized the need to have a solid place to start. For that, we have defined a set of deliverables that the group believes are immediately tractable and useful to the community, and the goals/scope section remains a broader guideline for what any future rechartering or additional deliverables would be.

As such, we wrote the charter with three main points:

- The overall area that the charter focuses on (workloads) with walls of what we don’t focus on
- A list of immediate concrete deliverables
- A set of filters for how to consider new work in the group, either as a new deliverable or a larger recharter discussion

With this setup, I believe that the working group ends when there are no active deliverables and no more inputs to the group that fit through this filter. The chairs will need to ardently apply such a filter to all proposed work to prevent this from becoming a dumping ground for "neat ideas" that have little to do with workloads and their surrounding technologies. The proposers are keenly aware of the tendency for long-running groups to grow well beyond their original agreement, and the bounds here are intended to prevent exactly that behavior. It would need to be enforced, of course, but we felt it was important for the charter to acknowledge both the wide space and the intent for addressing specific problems.

So while the group isn’t being chartered to, for instance, write a specific protocol named WIMSE, I do believe in the intent to limit the scope to tractable items within a specific space, even though we anticipate there being more items to come as the group continues. This is why we have the text calling out both HTTP and alternatives - the initial deliverables will be around HTTP based protocols and systems (where applicable), but we already know walking into this that the world of workloads doesn’t just run on HTTP. Even HTTP-based solutions are going to need to consider carefully what parts of HTTP they rely on. While we don’t expect to necessarily create a single solution that works across all delivery mechanisms, we also don’t want the WG to focus solely on HTTP in the long run.

If there are better ways to communicate this intent, both the limitations of scope and the long vision, I know we’d appreciate guidance in doing so.


[Joe] To add to what Justin has said,  we feel there is a need for a long standing working group to address this area, that being said we have a list of concrete deliverables that we want to address first.   The goals are intended as guidelines for rechartering to add items outside the current scope of deliverables.
With respect to “other protocols” the intent of the working group is for the solutions to be applicable across the range of protocols in use.  We will be successful if the mechanisms and constructions we develop are as ubiquitous as the current usage of JWT tokens across multiple protocols.  This may require specific adaptations to meet the needs of certain protocols like how entities are identified and named or of how information is propagated from one system to another across different protocols at different times.

[Roman] Thanks for the explanation.  What I’m trying to understand is why scope beyond the already known deliverables needs to approved now, rather than restricting the scope to the known work items now and rechartering when those follow-on deliverables are known.  Per our call, I’ve sent a proposal on how to meet this intent.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

(3) Per the goal of “Identify and Advocate for Gap-filling Work: Engage with
other relevant working groups to pinpoint and address gaps in current
standards. This will involve thorough collaboration, ensuring that emerging
standards are consistent, holistic, and interoperable.” Does this bullet imply
new standardization activity?  What is the deliverable for "advocacy of
gap-filling work"?

The deliverable is engagement with other groups, and if that turns into a deliverable within that group then that’s great. Since we see WIMSE as a place to gather workload expertise, problems, and solution spaces, we think it’s important that this expertise be ready and willing to engage with other groups. We think of this as similar to a DISPATCH outcome — if someone brings work into this group that’s a better fit elsewhere, we’re saying that WIMSE will proactively seek and engage the "elsewhere".



(4) Per “Engage with other relevant working groups to pinpoint and address gaps
in current standards”, if this is in scope, what are the relevant WG and the
gaps?  As the initial deliverables are currently described, no existing IETF WG
appears to be built upon beyond JOSE and HTTP.  I observe that the charter says
to coordinate with OAuth, SCIM and RATS.  What gaps in what standards of those
WG is WIMSE focused on?

Token delivery and formats today are largely based on OAuth work, and some current OAuth drafts (like transaction tokens) are directly related to WIMSE’s goals and environments. I would personally argue that if WIMSE had been chartered at the time, the transaction token draft would belong in WIMSE and not in OAuth.

I believe "SCIM" might actually be a typo where we meant to say "SCITT", and with that and RATS you can start to address the foundational software, device, and system identities that workload identities can be built on — and in fact are built on today in running systems. But those spaces don’t get at the runtime context that WIMSE seeks to address, and likewise WIMSE does not seek to address supply chain or platform attestation.


[Joe] Yes I think SCIM should have been SCITT.


(5) Per the goal of “Initiate and develop new standards that provide the needed
functionality and ensure their widespread adoption to address propagating,
representing, and processing of workload identity”:

** what will the WG do to “ensure … widespread adoption”?  What’s the
deliverable?

We make good standards and engage the relevant communities, like any other WG would try to do. :) I admit that it’s a bit grandiose to say we can ensure it, but we certainly can try.

[Joe]  More concretely it's keeping the needs of the workload environment and problems space in mind, which includes developing solutions that are adaptable to other protocols and that integrate with the security requirements and mechanisms deployed in these environments.

[Roman] Thanks for the explanation.  If the bar is “good standards” then I’m not sure this text is needed.  I think we all aspire for that outcome for all RFCs.


** what is “processing of workload identity”?

I’ll say we struggled on capturing this at the right level for the charter — we are talking about situations like "what happens when a workload receives an identity from another workload?" The major space here is authorization, but we (1) believe that there are other functions beyond authorization, like call chain verification, and (2) we do not want the WG to focus on authorization technologies themselves. So, while this group would consider an application of, say, a cryptographic graph processing runtime provenance, it would not adopt a policy language or authorization rules system as an item.

[Joe] Processing would also include proof of possession or binding to identity where required.

[Roman] Consider if you can explicitly enumerate the security properties the solution needs to engineer for.

Regards,
Roman