WIMSE IETF 119

Note taker: Richard Barnes

Agenda

• Welcome - 5 min (chairs)
• What is WIMSE and Why Are We Here - 20 min (chairs)
• Transaction Tokens - 15 min (George)
• Identity Chaining - 15 min (Kelly)
• Token Delivery BCP - 10min (Hannes)
• WIMSE Architecture - 15 min (Joe)
• Deliverables Review and Calls for Adoption - 30 min (chairs)
• Other Business - 10min (chairs)

Welcome

• The chairs held a hum to start the meeting, 2 in favor, none against
• Murray: Orie will be taking over as sponsoring AD as of plenary on
  Wednesday
• We're a working group!

What is WIMSE and Why Are We Here

• Summary of WIMSE concepts: Workload, workload identity, etc.
• What we're doing / what we're not doing
• Trying to reuse stuff from other spaces when it makes sense
• Richard Barnes (RB): Just to confirm, there are provisioning /
  presentation aspects, and we're doing both?
  • Justin Richer (JR): Yep, more presentation than provisioning

Transaction Tokens

• https://datatracker.ietf.org/doc/draft-ietf-oauth-transaction-tokens/

• RB: Even though you need chainability, you should consider sticking
  to sender constrained tokens; just requires more signatures

  • JR: Notion of "sender" can be a little ambiguous in workload
    environments
  • RB: Bearer tokens compound that problem; let's try to clarify

• Bron Gondwana (BG): If you're going to be signing things, need to
  avoid replayability

• Peter Kasselman (PK): Might be able to have not sender-constrained
  tokens, but tx-constrained
• [[ missed final comment ]]

Identity Chaining

• RB: Where does the connection between the two domains made?

  • Kelly ?: Presumption that the two authorization servers are
    configured to work together

• Roy Williams: Have we thought throw leakage of information between
  domains?

  • Arndt Schwenkschuster: The AS of the originating domain can
    police this

WIMSE Architecture

• JR: Looking at adoption is later in the agenda for today

• PK: You mentioned writing down security properties. Could that
  support formal analysis?

  • Joe Salowey: Something we've thought about, don't know how
    feasible it would be
  • RB: Super important to capture desired security properties here;
    not crazy to envision formal models
  • Yaron Scheffer (YS): We should also make sure to capture privacy
    properties
  • Muhammad Usama Sardar: Some formal modelling being done in CNCF
    and happy to make a formal model for WIMSE specs

  Proposal: https://github.com/CCC-Attestation/governance/issues/13
  CoCo KBS https://github.com/confidential-containers/trustee
  KBS protocol:
  https://github.com/confidential-containers/trustee/blob/main/kbs/docs/kbs_attestation_protocol.md

BCP for Workload Identity

• RB: We can both (a) say that using JWTs in certain ways is best
  current practice, and (b) build more sender-constrained stuff for
  the future

  • JR: Current scope is for a BCP, but sender-constrained stuff
    seems like plausible future scope

• Pete Resnick: BCPs, procedurally, are a mess. There are these things
  called "Applicability Statements" that are neater

  • RB: So the upshot of that is "set the intended status to PS"?
  • PR: Yep
  • JR: Great, "Best Current Proposed Standard" it is

Deliverables Review and Calls for Adoption

• JR: Plan to keep architecture open while we develop protocol

  • Yaroslav ?: Maybe we should call it WIMSE 1.0
  • PK: Let's cross that bridge when we come to it

• [[ missed last point from George Fletcher ]]

• WIMSE Architecture

  • Paul Wouters: Only 10 people said they read it
  • Henk Birkholz: That only asked people in the room
  • Poll indicates strong support, nobody opposed
  • JR: The authors will do a quick cleanup revision, do call on the
    list on that

• Token distribution BCP

  • Poll indicates some support, but also several "no"s (9 : 4 ::
    yes : no)
  • YS: There's been some discussion of scope changes, would like
    for those to settle down before adopting
  • Orie Steele (OS): Would like to see some of the feedback in the
    room addressed
  • Hannes Tschofenig: This isn't a WGLC! Just a starting point
  • Evan Gilman: +1 to Yaron's point
  • YS: Think this doc isn't ready even as a starting point until
    we're clear on the scope

• Token Exchange

  • OS: Has there been discussion about why OAuth docs aren't good
    enough?
  • George Fletcher (GF): Seems premature to adopt this, we don't
    even know what we need beyond OAuth
  • Yaroslav ?: +1 to George. Potential challenges, e.g., with WIMSE
    tokens not being OAuth tokens
  • Chairs might form a small design team

• Token Issuance

  • GF: Liberty Alliance produced something called "SHIPS" that
    might be relevant

• Securing service-to-service traffic

  • JR: Propose a similar approach to token exchange, and have a
    design team diff to the OAuth doc
  • Volunteers: Yaron, Joe, Hannes, Evan, one or two more

Other Business

• Atul Tulshibagwale: You had mention a "bag of tokens" thing, is that
  going to be worked in this group?

  • JR: Not a deliverable for this group right now

• Brian Campbell: Confused on the service-to-service stuff

  • Justin mentioned similarity to Tx tokens, Peter had also
    mentioned some similarity to DPoP...
  • PK: Could be multiple drafts against this deliverable
  • Hannes Tschofenig: Lots of examples of forwarded signed things,
    DKIM, SIP, etc.

• Oliver Borchert: Do you believe service-to-service stuff would
  include Zero Trust

  • JR: We would need to agree on what Zero Trust meant first
  • PK: A lot of the tech we are developing is important for
    realizing things people call ZT