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

[Joseph Salowey <[e-mail]>]

On Thu, Feb 15, 2024 at 7:25 AM Justin Richer <[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]> 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.


>
> ----------------------------------------------------------------------
> 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.


>
> ** 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.


>
> (6) Per the entire list of deliverables, there seems to be an implicit
> architecture of the solution but that isn’t sketched out anywhere.  See a
> few
> example of that below.
>
>
> We believe that there isn’t one single architecture that’s universally
> true, but we believe there are a lot of commonalities. The thing is, nobody
> has written those down anywhere. The Architecture document deliverable is
> specifically designed to capture this need. The specific deliverables, as
> they are today, reflect that we can see point solutions in this space but
> do not yet see a single grand overarching architecture that unites
> everything.
>
>
> (7) Per the initial deliverable of “Securing service-to-service traffic”:
> ** Editorial. Expand “authn/authz”
>
> ** What is “strong identification of microservices …”?
>
>
> By this we mean an ability to verify the identities of portions of a
> workload at runtime. Say I’ve got three micro services that talk to each
> other, I need to be able to identify them individually as well as identify
> them together in a context. This duality is found throughout the workload
> world.
>
>
> ** Is "within and across trust domains" effectively the internet then?
>
>
> I don’t believe so, as when we say "across trust domains" we mean specific
> point to point connections that carry a specific context with them. So it
> isn’t meant to be "A and also Not A", it’s meant to be "A and B". The most
> important thing here, to me, is that the group is chartered for problems
> that exist within single domains (such as a tightly coupled call chain) as
> well as across connected systems (such as an API service running across
> multiple cloud environments).
>
>
> (8) Per the initial deliverable of “Token Issuance”:
> ** What is a “workload component”?
>
>
> Part of a workload, most commonly a micro service of some kind.
>
>
> ** Is this work describing a new protocol (i.e., what is a “method for
> issuance”)?  Does that protocol build on anything (e.g., is it
> HTTP-based?)?
>
>
> Some existing systems are HTTP based, some are not. The WG would collect
> and evaluate these existing approaches.
>
>
> ** Is this the protocol for issuing the “JOSE-based token solution”
> described
> in the previous bullet?
>
>
> It might be, but the result might not be JOSE-based. These are composable
> solutions.
>
>
> ** What’s the different between local and generic token issuance?
>
>
> "Local token issuance" was our intent to capture the practice of a
> workload component being able to create/sign its own tokens locally, where
> "generic token issuance" was that same component relying on a specialized
> "signing service" to do the issuing. Both are well established patterns,
> but there isn’t a lot of guidance about how to properly apply them. As
> such, in the wild you run into people using a local token signing key in a
> workload because it’s fast and simple, but without considering the security
> hazards and auditability tradeoffs. We anticipate this deliverable would
> change that.
>
>
> (9) Per the initial deliverable of a “Token exchange”
> ** What is the relationship between an incoming token and workload-specific
> tokens?
>
>
> The workload-specific token takes the incoming token as input to its
> context, along with the workload identity, runtime context, and other
> factors. So the workload-specific token is derived from the incoming token,
> but the incoming token isn’t the only input to that derivation process so
> we can’t say it’s a direct descendant.
>
> Let’s say you’ve got a user that says "go print this photo", and you’ve
> got a workload that runs the photo storage and one that runs the printer.
> The incoming token has information about the user and what they’re asking
> you to do, but the workload need not know anything about the user as a
> person, but rather the photo entity being accessed. So the photo-storage
> workload token would say "you can fetch data for this photo", which is
> based on the exchange being done in the context of ’this user can load that
> photo" and "this workload is allowed to load photos at all". The printer
> likewise doesn’t need to know any of that information, only that they can
> access the photo data that’s been passed in to the workload and can access
> the printer. So the workload token here is more generic, "you can print the
> photo that I give you".
>
> Both of these workloads might have multiple steps in the chain — for
> example, color correction, audit logging, resize/resample, checking printer
> ink levels, etc. All of that gets kicked off in the context
>
>
> ** Is the workload-specific token the "JOSE-based token solution" described
> earlier?
>
>
> It might be, but the result might also not be JOSE-based. These are
> composable solutions.
>
>
> ** Can the token formats which will be exchanged be described now?
>
>
> We could enumerate some today (JWT, CWT, PASETO, Biscuit, Macaroon), but I
> don’t think it’s helpful to put those limitations into the charter text.
> Rather, I think that’s a job for WG consensus.
>
>
> (10) Per the initial deliverable of “Document existing local token
> distribution
> practices for workloads: An Informational deliverable describing the
> considerations and best practices for filesystem-based token delivery in
> Kubernetes.
>
> ** In my cursory review, the contents of
> draft-hofmann-wimse-workload-identity-bcp-00 don’t seem to match the
> description of this task.  The don’t seem to talk much about file-based
> token
> delivery.  It sketches protocol interaction (Figure 1) relying on OAuth.
>
>
> Yes, the input document is not explicit about that in its text, but that
> is the background from which it was written — what do you do when you are
> delivering a token to a workload without it going to an external service or
> making a network call? In addition to the BoF at the last meeting, the
> ongoing discussions on the mailing list and on regular phone calls have
> expanded the goal of this deliverable to address this more generally.
>
>
> ** This deliverable is framed as being “informational” status.  However,
> publishing informational status documents isn’t an obvious scope from the
> text
> is the goals section.
>
>
> I would expect the WG to deliver standard and informational documents as
> best fits the individual deliverables. As this document specifically is
> describing best practices, we anticipated an informational RFC would be the
> right target.
>
>
>
> --
> Wimse mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/wimse
>
>
>