WIMSE IETF 121

Note takers: Yaroslav & Pamela

Welcome and chair update: Pieter and Justin

Chair notes:
WIMSE - Workload Identity in Multi-System Environments
Chair updates: Pieter now works at SPIRL and Justin now works for
UberEther. In practical terms nothing really changes. Chairs are proud
of the working group website.
Three current documents:

• WIMSE architecture,
• Oauth Client Authentication BCP
• Service to Service.

Other ongoing work includes token translation and authorization levels.

Other working groups delivering relevant transaction tokens, identity
chaining and Proof of Issuer Key Authority (PIKA). Pieter particularly
recommends checking out PIKA document. See
https://ietf-wg-wimse.github.io

Why are we here - Brian Campbell

• Recently there was a blog post at IETF main page - nice to see WIMSE
  getting press.
• First meeting happened at IETF119 in Brisbane.
• Brian presents a WIMSE workflow overview diagram from Justin's IETF
  119 slides. Vanilla OAuth, session cookies or DBSC are out of scope
  for WIMSE.
• WIMSE service to service addresses "inside chall chains, ie
  transactions within various stacks"
• Transaction tokens addresses a context that chains context not only
  within a stack but between stacks. This could be used with service
  to service authentication.
• Transaction tokens already also includes some discussion of token
  exchange, which might be how a transaction token is retrieved from a
  gateway.
• When crossing domains, Existing solutions help including RFC 7523
  (authz grnt part), RFC 8414 (AS metadata), maybe identity chaining
  draft. each of the above are pure OAuth, not OIDC (despite naming
  choices from certain vendors with similar solutions).
• Kathleen Moriarty: to add to list of options, PIKA proposal is a JWT
  that uses the cert keypair. Sharon Goldberg is responsible for this
  proposal. It is worth having her engaged in this conversation.
• Brian: Agree, we should involve her
• Brian is sorry about RFC8693 (OAuth 2.0 Token Exchange). It is
  REALLY not intended for cross-domain usage.
• Maybe some of this should go into architecture draft, maybe there is
  a room for RFC7523 profile, maybe PIKA should be included.
• Joe Saloway: I think at least part of this should go into
  architecture draft.
• Yaron: Sounds like re-chartering...
• Justin: As chair, AD can correct -much of what Brian addressed is in
  charter but not in current work items. Working group needs to
  consider where to put energy
• Pieter: don't think we need to re-charter but do want to encourage
  discussion
• Yaron: Would involving PIKA or profiling 7523 not be a rechartering?
• Justin: We first need to see the work and make a decision when we
  get there. Having the discussion is very much in charter
• Arndt: token exchange preso may speak exactly to this.

Architecture Update - Joe Salowey

• Not a lot of change to arch spec since last IETF.
• Updates to identity and trust domain defitions and expanded use
  cases. Expecting things to develop a bit more (service to service).
  It will be easier to incorporate into architecture upcoming work
  from token translation.
• Stuff from Brian's presentation isn't in the arch yet but it does
  represent where the authors think it needs to go.
• We reworked definition of workload identity to sync it up with
  Service to Service spec. This information is encapsulated into
  credential. Trust domain is a grouping of systems.
• Looking for more information on current def of a trust domain. Main
  goal of a TD is you have a way to map the credentials you verify, eg
  a root CA, a JWK set for JWTs etc. TD is defining the scope of the
  token, if you have 2 things in two domains that look the same they
  shouldn't be assumed to be the same, corrolation may be needed.
• Ned Smith: Please explain what is "Trust" in trust domain, how is it
  different from just "domain".
• Joe: where the trust comes in, the name is referring to the set of
  creds used to validate the credentials, there is a trust
  relationship there, different from DNSSec.
• Workload identifier is now defined. Similar to what SPIFFE does,
  basically a URI format that we can put into a certificate or a JWT
  token.
• In a s2s (service to service) case, it is a certain kind of JWT used
  to authenticate between services.
• Format is flexible - it has a scheme, trust domain and some path
  information that is specific to the scheme. One example is SPIFFE.
• We can define our own scheme or not, if we do we can have our own
  semantics with the rest of the identifier.
• Gridhar Mandyam: Do we envision WIMSE alternatives to FTTNs? If I
  migrate workloads within a machine that I own, may I not bother with
  cross domains?
• Joe: I think the issue if you use a simple hostname is there is more
  chance of collision. For just an internal domain maybe you can avoid
  the issue. We do say the name has to be fully qualified, could
  discuss but is it a problem to fully qualify?
• Giry: We may not want to roll out FQDN before knowing if it blows
  stuff up\
• Joe: Remember that FQDN part is for trust domain part. Each service
  is not necessarily uses FQDN. Service is defined by path part of the
  URI which is locally defined unless we decide on the format. I think
  we should have this discussion if we want to allow non-FQDN domains
  in scheme. Intent is to be SPIFFE compatible but maybe we could
  extend it in a different way. It would be bad if we diverged in
  incompatible ways.
• Flemming: if we do make schematic changes, question is are you
  making any syntactic deviations and if so why? Lots of goodness to
  stay consistent, at the same time we should understand why it might
  be a good idea
• Joe: Makes sense.
• Arndt: I believe that host part is not required. Kubernetes for
  example can use just host part.
• Justin (chair hat off): entirely dependent on scheme, on whether
  there is a host part or what that means. WIMSE & SPIFFE define their
  own.
• Ardnt: Reason for the host part is that same path with different
  host may not be the same. Cutting the host may not be the same.
• Joe: with this particular scheme we suppose the scheme would always
  have a trust domain part in order to validate the identity
• Yaroslav: i don't think we mandate the host schema to be globally
  unique so nothing stops you from using .local for example so that
  should be possible
• Joe: this is why we don't want to have text that forbids or requires
• We have 2 types of credentials in the S2S draft - X.509 and a bound
  JWT for S2S auth. We want to discuss bearer JWTs and whether they
  fit but we don't have text yet.
• One of the questions that we have is if we can remove identity
  defintion from S2S document so that we won't be repeating ourselves.
• Can we remove the workload identity definiton from the S2S spec and
  put it in the reference arch doc?
• Fleming: I fully support that. Let's keep it in one place.
• Joe: Does anyone think the def should not go in the arch doc?

• Justin: Chairs will ask editors to confirm on the queue

  • No objections

• Dmitry: the transaction token spec should also work in conjunction,
  in that spec there is also a definition of a trust domain but it is
  less specific.

• Joe: We'll take a look at that
• New topics: Impersonation, delegation
• Next steps: there are open issues on terminology, things like
  transaction tokens. Looking for alignment.
• We'll look at threat model. We need to start making progress on how
  authorization context and things like that getting propagated
  through the spec. We'd like contributions and discussions on these
  things.
• It might make sense to schedule an Interim.
• Justin: The chairs will take it as an action item and check if there
  is energy in the working group for architecture-centric interim.
• Kathleen: for #6 (attestation) I have a draft in RATS that will
  either feed or solve #6
• Joe: can you send a pointer?
• Kathleen: some changes this week, will push to the WIMSE list in the
  next 2 weeks

Service-to-service update - Joe, Brian, Arndt

• Joe: We had a number of changes: we updated identity section that we
  just covered in architecture section.
• Workload proof token is similar to DPoP, working through github
  issues.
• We are talking about how one workload communicates with another. We
  are inside a trust domain and define how one workload communicates
  with another. We are not dealing with cross-domain for this
  particular use case and a single-hop for the most part.
• Arndt: We define multiple ways how to perform service-to-service
  authenticaiton. One of them is mTLS, another is application-specific
  approach. Both of these methods use wimse token. It is not meant to
  be a bearer token.
• The new header is workload identity token.
• Differs in the way that we edit the issuer, and remove cnf because
  this isnt a bearer token. Would present proof in context of token
  (wippet?) A token on every request with ath claim (access token
  hash) or tth (transaction token hash)
• You would have your wit over session, there is no audience. You
  would sign a token for every request depending on audience.
• Yogesh: since it is not a bearer token, what is significance of
  expiry claim?
• Arndt: to keep it short lived. On the WIT you could remove but it
  wouldn't be good practice
• Yogesh: isn't it true that the identity should last the whole
  lifetime
• Justin: this is the proof not the WIT.
• Yaroslav: feels like overlap with other work like HTTP message
  signatures.
• Justin: that is in the next slide
• Arndt: that leveraged a pre-existing spec, we have both options in
  the draft, both have pros/cons.
• Since last IETF we made a comparison between WPT and HTTPSig, they
  solve different things. WPT is better for async, just need one
  library and can use for non-HTTP
• HTTPSig provides integrity protection. With WPT you could change the
  body because there is no digest. Includes response signing.
• Dean Saxe: Is there a problem with doing both? And giving
  flexibility for implementer to decide. In some cases both could be
  needed for a particular implementation.
• Arndt: It is more work for us but it is fine. Question is should we
  be opinionated?
• Dean: I think you have been opinionated about both. It is perfectly
  valid to keep both and move forward with considerations. I would
  recommend to leave both in place and allow implementers to decide
  which works best for their use cases.
• Arndt: There is an interoperability question (would implementer need
  to support both) but am curious what folks think is a good idea.
• Hannes: I was thinking along the same lines partially because there
  are cases where you want protection of the HTTP body. I'm less
  enthusiastic about arguments about implementation complexity as
  these perceptions change very quickly. For example, originally
  SW-JWT was considered to be "simple", but now it is "relatively
  simple". I see value in the flexibility. Dean is right.
• Arndt: thank you
• Flemming: I think it's fine to have multiple options.
• Yaron: one of the options, we need to choose one, we don't want
  people to make decisions they are not equipped especially since the
  runtime folks tdo not know if they have a middle box (audio was
  choppy)
• Kenneth: I created a github issue asking to consider workload proof
  by reference. I feel like building workload identity on top of
  established TLS layer should be considered as well.
• Arndt: thank you
• Joe: We made updates to the MTLS section, recommending if you have
  elements in your system to validate a server cert you may need to
  include both DNS & WIMSE identifiers, no big deal, validating trust
  domain is important.

• Poll 1: Do you support WPT being defined in the S2S document?

  • Results: 11 yes, 2 no, 6 no opinion

• Poll 2: Do you support definition of HTTPSig in this document:

  • Results: 12 yes, 1 no, 11 no opinion

• Poll 3: Do you support definition of X.509 style within this
  document:

  • Results: 21 yes, 0 no, 5 no opinion

• Justin: fairly positive for all three. We'll post to the list asking
  about combinats and how they should be patched together

• We'll take rest of the discussion to the list.

Token Exchange update - Dean Saxe

• Progress: slow, published recent draft update on Oct 21, fans of
  Oauth token exchange might see similarities, that is because that
  spec could be used in this spec.
• We have started a weekly process to work on use cases (Yaroslav
  leading) which won't be an RFC but will refine thinking. RFC 8693
  can't be used for all use cases, it is a good set of tools but not
  meant for cross-domain use cases. The reason we are using exchange
  and translation, exchange is high-fidelity (info is retained) while
  translation may involve loss of information that cannot be
  recovered. Don't know yet if that is ok or not. Concerns also that
  downstream security impacts could occur so must keep that in mind.
• Hannes: Can you explain what do you mean by we are not bound to
  OAuth tokens?
• Dean: We need to consider - SPIFFE SVIDs are a type of token, we may
  not go from SVID to X.509 (no OAuth). Want to be loose because we
  don't know what token types we will see. Because this is so open
  ended, this is an unbounded exercise.
• Hannes: Yes, it helps. It was just a very generic statement.
• Dean: This is extremely open ended, which is a challenge.
• Ned Smith: I believe you said that it is in the context of domain
  crossing?
• Dean: May be in a domain or crossing, we want to support all use
  cases. We defined 9 use cases with the kinds of operations expected.
  Could be changing names, token types, encryption types etc.
• Ned: In context of domain crossing and translation: as soon as
  tokens are signed and translation happens - you need to resign so
  you need to talk about trusted entity between the domains.
• Dean: yes, because one of the outstanding questions is how do we
  define what this looks like. We need some kind of profiles, working
  on verbiage for RFC-style drafts that describes the transformation
  looks like and what the implications would be of data loss. Must
  define as profiles to have explicit mechanisms not just magic.
• Ned: there should be an authority context, creating the contract,
  lots of ways to do it, ie relying on a non-existent trusted 3rd
  party
• Dean: Hopefully we won't wind up in this situation. In an ideal
  world all exchanges happen between trusted parties
• We would like to create profiles as RFCs (in conversation with
  chairs) to ensure process rigor. Should be uni-directional - profile
  from A-B might not be same as B-A.
• Ultimately we need to define what it looks like based on real types
  of token that people want to do exchanges or translations with. I
  could use your help with your use cases: what kinds of tokens that
  you would like to exchange or translate.
• We need to ask: should our profiles cover RFC 8293? Do we need to
  put bounds around token exchange?
• As we begin putting these profiles together: should these be
  composable? Aka Token Type A->B->C. What are security considerations
  of doing this? Is it acceptable? Please talk to us on list, on our
  Office hours calls or through GIT issues.
• Dean is sharing QR code for meeting invite.
• Yaron: Suggest we include 1-2 real profiles in this document to
  prove out the template. A lot of value in having real profiles.
• Dean: agree - trying to figure out what should be in the template to
  speed develop. Agree that including here however perhaps we do that
  early for discussion sake and then break them out again later.
• Justin: General process comment - could be a path for this work to
  progress the concrete profiles as separate docs but keep the
  template as unfinalized in the meantime
• Dean: would publication of those profiles be a dependency on WGLC of
  this doc so they move together in lockstep?
• Justin: I was proposing that the primary document does not need to
  be of a separate artifact.
• Dean: sounds good.
• Pieter (not as chair) do you have a sense of concrete examples? Is
  there something specific looking at the use cases did anything pop
  out as "we should go do?"
• Dean: Getting some feedback from this group which token
  exchange/translations are most important. There was some work around
  profiling X.509 and oauth.
• Flemming: Disagreeing a little: there is a lot of value in outlining
  in a document that explains the process. That can make things go a
  lot faster, things you can make sure are specified.
• Dean: Thank you
• Pieter (non-chair): In terms of exchange, have you any thoughts on
  when you are requesting access token or requesting a certificate
  (issuance) - how do you avoid using token exchange as a method of
  obtaining credentials when other better methods already exist?
• Dean: We have not written that down per se however it is a good call
  out and we should write more about that concept, we shouldn't bind
  folks to this doc only, if there are other mechanisms they should be
  able to use them. We may wish to profile exact steps however if they
  are part of a specific chain of events.
• Justin reminds the group that they are not constraint anyone from
  doing work outside of the group. If there are other token mechanisms
  that are not fitting inside it, we are not stopping you from
  developing them.
• Yogesh: You have a use case document - can you explain some
  interoperability there instead of in a new document?
• Dean: I don't know if it fits exactly now but we should have the
  conversation. There is a side meeting tomorrow at 8am on this topic.
  Please join.
• Brian Campbell: we seem to both have reservations, but whatever you
  do, don't take token exchange across domains. It should not be used
  here because it is already standardized elsewhere.
• Dean: I have heard quite clearly about non-reinventing wheels. This
  is not the intent. But this space is deep so there is a lot of work
  to be done.

Informational/BCP Update - Arndt

• Former "best practices for workload identity" is now "informational
  for workload identity". Since last IETF we were told to document
  current practices w/o strong recommendation. Old scope was
  kubernetes. New scope includes SPIFFE and cloud providers and also
  workload platforms. Let us know if you have other platforms that
  should be added there.
• In kubernetes the cubelet schedules the workload and protects a
  service account token. workloads use it to talk to the control plane
  and each other. Often however there is an externally authorized
  domain (eg a S3 bucket).
• Authorization service has pre-established trust and access token.
  With that token workload can get access to external authorization
  domain.
• Cloud providers use similar flow. Workflow identity would first get
  identity from instance metadata API. You can use that access token
  to access protected endpoints in the cloud.
• Scenarios may be cross-cloud, for example a diff AWS account. in
  that case what you get back would be presented to access protected
  resources in a different cloud.
• SPIFFE: Similar pattern. Workload can get short SVIT from workload
  API. It can present that as assertion, get access token and use it
  for accessing protected resource.
• Last: CI/CD, you have a pipeline step/action that is scheduled byt
  the platform. a JWT can be retrieved from the platform and can
  perform a deployment or upload a build artifact.
• In this draft we are documenting this common pattern. You get
  credentials from platform and you push or pull it. You present
  resulting token/credential as assertion to the access server.
• The current draft (the editor's draft) outlines this pattern. In the
  common pattern we talk about presenting an assertion but it isn't
  actually an assertion. Different providers use different things -
  every provider has their own thing.
• Security considerations - if you use CI/CD you have to tell the
  difference between main branch & dev branch. OpenID lockout token
  can be accepted.
• Workload lifecycle - do we invalidate the token?
• Platforms do different things. For example, kubernetes invalidates
  token of workload that is stopped.
• This document talks maintly about assertion flows. There are other
  documents in these working group and these building blocks fit
  nicely together.
• Muhammad: You have workload identity ready. Do you assume that it
  comes from the same platform? Can it come from outside?
• There is a trust assumption - you are assuming there is a
  relationship but is that a TLS relationship that is protecting?
• Arndt: It can potentially come from outside of the platform
• Muhammad: if it is coming from outside you may have to protect that
  interaction
• Arndt: It depends on pattern. For example, SPIFFE can sign it with
  something different.
• Muhammad: I could have obtained the identity and as a MITM I could
  represent myself (impersonate).
• Arndt: It really depends on platform. I would put this out of scope.
  Please put it as an issue into repo for us to look into this.
• Muhammad: I think it is important
• Arndt: can you put this as an issue in the repo so we can consider?
  Every authz server has their own means of establishing trust
  relationship
• Muhammad: You are open to any protocol that is protecting
  communication but you are not specifying which one?
• Arndt: I'm not sure, lets take it offline
• Osama: Is there TLS between the boxes?
• Arndt: yes there is TLS. But maybe it should be more explicit
• Joe: Do you run into scenario when authorisation server is within
  trust domain? Is there a case when there is token exchange/token
  translation involved?
• Arndt: between workload and...
• Joe: is the workload always directly processing or is there a
  translation in there somewhere - concern is kubernetes things
  disappear and come back, maybe somethings can be easily coordinated.
  Have you seen a pattern where there are 2 authz servers, one local
  and one other that could account for the differences.
• Arndt: Whoever singed this credential is an authorisation server.
  Maybe it's worth raising as an issue.
• Hannes: did we lose something in omitting the "host" box that
  workloads are running, we lost the agent - is that important for how
  does the WL actually get the initial token, ie ENV variable etc.
  Also - in Venn diagram, I would have drawn the circles to include
  token exchange as in scope for this draft, assertion flows are a
  means to do token exchange.
• Arndt: this is just my personal opinion, let's not get stuck on it
• Flemming: Slide on new direction - I don't understand.
• Arndt: Before we just talked about Kubernetes. With new direction we
  describe the whole pattern.
• Flemming: Are you still planning to have all the individual
  scenarios?
• Arndt: In the appendix
• Flemming: Whole pattern feels like an architecture artifact. I would
  also add VMWare as a platform.
• Arndt: yes.
• Justin: polls will be put out to the list. Biggest frequest is to go
  read the PR and familiarize with the content.

Authentication Maturity Levels - Ryan Hurst (remote)

• This is a follow-up to Vancouver, where we discussed having a doc
  talking about workload auth maturity levels to rationalize choices
  in this space. Properties are hard to reason about systems that are
  complex. Goals that resonated were to create a structured approach
  to talk about the problem domain.
• Goal is to create a similar style framing for the project for
  practitioners and organisations to improve their security posture
  and explain how that all fits together.
• An initial draft has been submitted, it gets across directionally
  the plan. From mailing list & hallway conversations we gathered
  feedback and have a structure to get started. Jeff Lombardo also
  involved. Still looking for additional support (thanks Dean for
  providing some). We need to replace the current outline to make
  clearer and talk about purpose realigned to 800-63 in structure so
  those who know that doc can benefit. There is no security section,
  don't talk about security properties like whether the tokens are
  bound to hardware. Deciding how to keep high level yet while
  providing useful & accurate security description. Any time you
  develop a taxonomy must remember all models are wrong at some level.
  Today there are 6 levels in the doc, would be nice to
  reduce.Distinguishing workload & human identities can be done, would
  be useful for normative/consistent language to adopt. I don't think
  we can boil the ocean. Current draft is uploaded and in github,
  email was sent with conversation and will be setting up an office
  hours (details on list)
• Justin: as a reminder: this is not an official working group item
• Dean: thanks for the work - good progress. When we write RFCs they
  are static docs that live for a long time unless obsoleted. How does
  that impact utility of defining maturity levels? Is there a plan for
  when the levels lose their usefulness? Maybe chairs, ADs, Hannes etc
  have input
• Ryan: It's a good thought. I believe that protocols themselves do
  not change over time. I think it should be informational and we
  should be updating it.
• Hannes: the answer is relatively simple - need to abstract away from
  specific solutions,eg distinguish between storing private keys in
  software/hardware, that will likely survive. Couldn't find doc
  except in your repo, if not please use wimse so we can find it
• Ryan: I'll make sure that it is visible.
• Justin: Feel free to reach out to chairs if you need any help
• Giry: My experience in RATS: when we tried to bring in security
  issuance levels into the attestation token, modelled off FIDO
  levels, we had to rip it out, problem was that from an RP
  perspective it looked like a self-declaration which was useless. Are
  you looking at enriching workload tokens and if so how would you
  prevent them from looking like self-declarations?
• Ryan: My thought was no - for that reason actually. We have a lot of
  conversations in the working group about how that can be adopted in
  the given space. I think this is a textual document, not a protocol
  document.

Wrap up

Justin: Three action items:

1. interim for architecture document (taking into consideration winter
   holidays). It might be January depending on fit.
2. put out a formal poll for S2S presentation adn security mechanisms.
   Is it pick one, pick all, something in between.
3. We were not able to get to all questions after Arndt presentation.
   Work with us how to formally bring those to list. Please read the PR
   version of the document.

• Reminder: please read the pull request, encourage the editors to not
  wait, just merge now so more people read it
• Flemming: I missed email, my bad - is there a reason not to just
  submit the document?Mu
• Justin: That was a timing thing, it was too close to cut off
• Murray (acting on behalf as Orie for AD) - if you're in deep and you
  need to get approved after the deadline, the AD can override.
• Arndt: I did not want to mess with scope of WG adopted document

See you in Bangkok!