Workload Identity in Multi-system Environments

Notetakers: Jeff Lombardo, Henk Birkholz

Agenda & Chair Updates (5min) - Chairs

Slides:
https://datatracker.ietf.org/meeting/124/materials/slides-124-wimse-welcome-and-chair-updates-02

Full packed schedule.

Weekly Github digest

• Chairs reinforce the benefit of the weekly summarization bot

There are a lot documents rework at the moment that will presented in
this session.

WIMSE Workload to Workload Split (5min) - Chairs

Slides:
https://datatracker.ietf.org/meeting/124/materials/slides-124-wimse-welcome-and-chair-updates-02

This is mostly content restructuring - all the details of the convo are
on the list

2 major aspects:

• Credential formats
• Presenation methods

Goal: To be able to progress them separately

Expected outcome: To be able to move more quickly to WGLC

Workload Identity Tokens (10min) - Arndt

Slides:
https://datatracker.ietf.org/meeting/124/materials/slides-124-wimse-wimse-workload-credentials-00

Draft: https://datatracker.ietf.org/doc/draft-ietf-wimse-workload-creds/

S2S document has been split in 4
This is about the Workload credentials

• Problem space and context
• Include WIT and Certificate

Chagelog since IETF-123:

• Section on Key Management: Workload needs to manage private key
• Extensibility of the WIT
• Error Handling: Why not 401
  • Better support for WWW-Authenticate

Queue:

• Pieter with Chair Hat: When is WGLC ? Before IETF 125?

• Still some work todo, depends on when split happens

• Justin / Chair: Document can move separately. Still this document
  needs to go first.

  • Call for questions on the document or split.

• Arndt: There are downref references now

• Justin: Let's figure out if informative ref makes sense then

• Yaron: it is not clear how we will go to the RFC Editor. It is a
  good signal for the industry (document split)

• Thibault: The split makes it easier to read. Question about section
  5 - We might need to remove it. There are 2 formats (Token and
  Certificate), Certificate is already used in Production but the
  Token seems more experimental.

• Arndt: The certificate format is aligned with SPIFFE.

• Justin: This document is about standardizing for the WG on how to
  talk about things, not necessarilly things in Production

WPT (10min) - Brian

Slides:
https://datatracker.ietf.org/meeting/124/materials/slides-124-wimse-wimse-workload-proof-token-00

Draft: https://datatracker.ietf.org/doc/draft-ietf-wimse-wpt/

Signed with the private key of the Workload and sent along the WIT.
Generated for each request to match the audience.

Proove the possession of the key by the client (aka the workload).

Thereby, a Workload Identity Token is not a Bearer Token anymore.

The WPT can protect headers through the oth claim

One topic:

• Profiling guidance

• Arndt: Upcoming Decision: context specific Claims: a) one claim
  for a map on the root level OR all claims on the root level?

• Rohan: What are you trying to say as a Discussion.

• Arndt: We want to define the scope as as the document scope

• George: 2 questions - oth claim and protection of other header
  from the requests. Should we have profiles to expand or do we aim to
  embbed this in this specification?

• Arndt: In other protocol, the information we want to protect might
  not be in the header but the payload. So we may had to tackle that.
  For compliance profiles, it will be up to the community.

• Yaron: not confident about the synchronization in between the
  proposal and the W2W document.

• Arndt: In closed environments you are allowed to use dditional
  claims as long as the keys do not collide.

• Yaron: You cannot necessarilly induce this is a closed environment

• Arndt: I agree

HTTPSig (10min) - Yaron

Slides:
https://datatracker.ietf.org/doc/slides-124-wimse-wimse-authentication-with-http-signatures/

Draft: https://datatracker.ietf.org/doc/draft-ietf-wimse-http-signature/

How to integrate HTTP Sig with the WIT

• Justin: Call out to the Authors to reach out the PoC implementers to
  bring back feedback to the Draft

MTLS (10min) - Yaroslav

Slides:
https://datatracker.ietf.org/meeting/124/materials/slides-124-wimse-workload-authentication-using-mutual-tls-00

Draft: https://datatracker.ietf.org/doc/draft-ietf-wimse-mutual-tls/

Mostly mTLS but Client authentication is validation of the SPIFFE
identifier

Question 1: Should we move the Workload Certificate in this spec or not?

• Joe: Think the Workload Identity Certificate in the Credentials
  Draft but keep the TLS related elements in this Draft.

• Brian: Agree with Joe. Uncomfortable about how the 4 Draft deal with
  the way the WIMSE Identifier is dealt with when accessing TLS
  resource.

  • Yaroslav: We have more on that

• Arndt: Think the having the WIT and IDentity Certificate in the same
  document allow to compare them better

• Usama: Comparing WIT + mTLS to mTLS, what are the advantages?

  • Yaroslav: We have nothing about WIT here, only mTLS

Question 2: DNS hostname is the only SNI option in certificate. Would it
not be great to have WIMSE identifier as a recognized scheme as a TLS
name extension?

• Arndt: It addresses a real problem. I agree this is a problem space
  we need to address.

• Brian: No

• Atul: Will there be problem with EKU from webpki?

  • Yaroslav: not sure, let's bring that to the Data Tracker
    discussion

• Yaron: In the older S2S Draft we had an Implementation section. We
  still need and we should bring that back in the Wiki

• Justin: Encourage the authors to create a Wiki page

• Justin: those Drafts are expected to go fast, also in reviewing so
  please audience pay attention

• WIMSE Architecture (20min) - Joe

  Slides:
  https://datatracker.ietf.org/meeting/124/materials/slides-124-wimse-wimse-architecture-00

  Draft: https://datatracker.ietf.org/doc/draft-ietf-wimse-arch/

• Two new versions (-06 now) and one interim

• Topics to extend that will need more fleshing out: Security,
  Authorization (we want to say more), Key Management (sort of
  references), some type of "attestation"

• Usama: There is no connections to attestation here, what are the
  plans?

  • Joe: We need to discuss that and see what the industry is
    proposing
  • Usamma: asking more details
  • Joe: It probably does not align with RATS, we need help to find
    the right amount of text
  • Usamma: We can contribute with RATS content,

• Henk: With TCG Attestation WG Co-Chair hat on: I don't know what you
  want to talk about. There is a draft-novak-rats-twi-attestation in
  RATS, maybe that is the part that you want to insert/reference here?

• Arndt: I am a SPIFFE lead maintainer and they did a good job at
  writting the section. They made some mentions to RATS. Authors
  should look at it.

• Mark: Because WIMSE went into Agent and Server deal with
  attestation, there are some overlap. Happy to raise an issue.

• Lucia: Regarding the Authorization, this is something we already did
  but it was out of scope initally, if you want to work on that I can
  do it.

• Joe: For more details we might need to do a separate workstream of
  document. Effectively this is not something in charter right now.

• Justin: This is effectively explicitely out. In an Architecture
  document, this is ok. Diving and solving the Authorization decision
  is out of scope and related to future work. This is a reasonnable
  topic for the second round of Draft. Still this is a good forum to
  have the discussion.

• Flemming: There is a need in Architure to talk about to talk about
  workload instances.

• Joe: Rephrasing: You can have multiple isntances of a workload and
  you might want to do something with that. They are still Workloads.

• Flemming: You still need that they might be different. You need to
  convey the difference in the credential.

• Jeff: WRT the identifier draft: how deep should we go? Especially if
  we are forcing some signalling method (e.g., this one instance is
  prohibited from interacting with my ecosystem).

WIMSE Identifier (15min) - Yaroslav

Slides:
https://datatracker.ietf.org/meeting/124/materials/slides-124-wimse-workload-identifier-00

Draft: https://datatracker.ietf.org/doc/draft-ietf-wimse-identifier/

Recently adopted - Thanks

Text did not change since adoption

Worklaod Identifier scope will contained the Authority Trust Domain and
Path

SPIFFE does not want you to shoot yourself in the foot when dealing with
URI

• Flemming: is that rules for everything or are we considering more
  rules for SPIFFE?

• Yaroslav: We will support SPIFFE specificities through "profilling"
  currently

• Flemming: SPIFFE Support IPV6

• Yaroslav: That is because they are supporting : - We won't support
  IPv6 for Scheme

• Arndt: is there any use case to support IPv6?

• Yaroslav: There might be specific scheme in the wild that we don't
  want to restrict through WIMSE.

• Henk: Every SPIFFE ID is a WIMSE ID but not contrary? Why would ":"
  not be okay in the superset that is the WIMSE ID scheme?

• Joe: the host portion of the URI is common to all the scheme...
  maybe it is the way you look up to the key material or other use
  case.

• Peter: What does "no user information" refering about?

• Yaroslav: We don't want the username and password part of the URI
  support

• Pamela: From reading the spec and the subset / superset, is there a
  way to distinguish the two (SPIFFE / WIMSE) ?

• Yaroslav: URI are very broad, we are constraining those to fit the
  need here and limit the flexibility.

Each scheme needs to define what is specific to their support path
format.

• Pieter: Who are the user of the WIMSE Scheme needs to be taken in
  consideration

• Yaron: Define a default scheme for people wanting an identifier but
  not having a specific Scheme

• Flemming: What can of semantics are going to use

Identity Practices WGLC (10min) - Arndt

Slides:
https://datatracker.ietf.org/meeting/124/materials/slides-124-wimse-workload-identity-practices-wglc-00

Draft:
https://datatracker.ietf.org/doc/draft-ietf-wimse-workload-identity-practices/

Added a new pattern, the service mesh

Multi-tenant problems:

• issuer can be shared

• Justin: We got only one review... this is not enough. Call for
  reviewers. Recorded volunteers:

  • Katherine
  • Monty
  • Jeff
  • Brian

WIMSE for AI Agent Identity (10min) - Yuan Ni

Slides:
https://datatracker.ietf.org/meeting/124/materials/slides-124-wimse-wimse-applicability-for-ai-agents-02

Draft:
https://datatracker.ietf.org/doc/draft-ni-wimse-ai-agent-identity/

• Usama: can you explain what the Evidence in Step 1 is?

• Yuan: this is the remote attestation

• Usama: I would have expected the Agent to be the attester not the
  proxy. Can you precise that? What is the boundary of the attester.

• Justin: We have 4 minutes left, bring your questions to the list.

• Justin: Have you guys submitted an ID yet? Please read the draft

• Peter: This is just a starting point. This is keeping our CISO up at
  night.

• Jonathan: Just looking at the flow including the user. This is not
  an Authentication but an Authorization.

• Yuan: what is the entity is allowing to do. This exposes different
  problems.

• Jonmathan: This is the poroblem of semantics.

• Yuan: We don't want the agent to be the user.

• Yaroslav: There are lots of talks at this IETF. Before we decide
  this is in or not, we need to discuss with the other WGs.

• Jeff: If you remove AI, This is a Workload and this is the exact
  same diagram as in the Architecture Draft. The Credential of the
  Agent is then an OAuth Client credential that could allow you to
  start an OAuth Authorization code grant flow.

• Flemming: Not sure this is the WIMSE WG for this.

OAuth Delegated Auth (10min) - Ruochen

Slides:
https://datatracker.ietf.org/meeting/124/materials/slides-124-wimse-delegated-authorization-00

Draft:
https://datatracker.ietf.org/doc/draft-li-oauth-delegated-authorization/

• Jeff: There seems to be a lot of Security problems on what is the DK
  and how DAT are signed. Also not going through the AS does not allow
  to manage session properly

• Geroge: Token endpoint allows down-scoping with RT. This solution
  does not seem to solve so much problems but create its own set of
  Security problems.

AOB

Arndt - key distribution and management

This is out of scope of the Architecture but there is a reference in S2S

There is a de facto standard for WebPKI

• Justin: And not Defakto, this is not a proprietary standard (typo in
  the slides)

• Yaroslav: You might want to come closer to WebBotAuth

AOB

• Jeff: There was multiple discussion of the collision on WIMSE
  Identifier and the Draft for OAuth Client ID Metadata Document

Chair

There are 7 Drafts in, we need to review and ship them

• Flemming: We need more interop meeting

• Pieter: thanks to the Authors

Any Other Business (5min) - Chairs