Markdown Version | Session Recording
Session Date/Time: 18 Mar 2025 02:30
wimse
Summary
The Wimsy working group met at IETF 122 in Bangkok. The meeting included updates on the architecture draft, workload to workload identity draft, workload identity practice draft, and new proposals for credential exchange. Discussions also covered topics like confidential computing, data residency requirements, and trustworthy workload identity.
Key Discussion Points
- Architecture Draft:
- Review of scenarios: basic workload communication, security context, and cross-domain communication.
- Terminology alignment needed within Wimsy and with other groups (Oath, HTTP).
- Further work needed on authentication mechanisms (impersonation, delegation) and cross-domain use cases.
- Discussion on "Wimsy Token" name change to "Wimsy Credential" or "Identity Document".
- Discussion on identifier formats.
- Workload to Workload Identity Draft:
- Draft renamed from "Service to Service" to "Workload to Workload".
- Coexistence with bearer tokens: Wits should not be used as bearer tokens.
- SPIFFE integration: A new type of SPIFFE document (wit-SVID) proposed.
- Discussion on the location of private key generation (agent vs. workload).
- Audience claim: Sender needs to know it, receiver needs to verify it.
- Consider terminology on trust bundles.
- Workload Identity Practice Draft:
- Description of common patterns: environment variables, files (docker volumes), and APIs (SPIFFE).
- Discussion on whether to mention more insecure practices like basic authentication.
- Considerations for confidential computing environments.
- Credential Exchange Draft:
- Exploration of a meta-pattern for credential exchange.
- Needs for credential exchange: change in authority, subject, scope, lifetime, format.
- Exchange mechanisms: initial provisioning, on-demand provisioning, exchange.
- Debate if revocation mechanism is needed.
- No silver bullet exchange API is possible due to different security frameworks and token formats.
- Attestation and TLS:
- Presentation on combining attestation with TLS in confidential computing.
- Challenges related to CSP control and potential attacks.
- Relationship to token issuance problem.
- Confidential Computing Consortium (CCC) Work:
- Update on the CCC's special interest group on trustworthy workload identity.
- Definitions for workload, workload identity, workload credential, and workload lineage.
- Properties of trustworthy workload identity: isolation, strong binding, and lineage.
- Data Residency Requirements:
- Presentation on the impact of Wimsy on data residency requirements.
- Critical workloads need to run in a safe geolocation with cryptographic binding.
- Workload identity needs to be bound to platform identity and domain identity.
Decisions and Action Items
- Architecture Draft: Authors to continue working on terminology alignment, scenarios, and incorporating feedback on "Wimsy Token" naming and identifier formats.
- Workload to Workload Identity Draft: Close issue on migration from old bearer tokens. Investigate trust anchor terminology. Solicit more discussion on audience claims.
- Workload Identity Practice Draft: Solicit more feedback on drafts. Dean Sacks, Joe Salloway, Yaron, Mike agree to read document and provide comments.
- Credential Exchange Draft: Author to send a link to the draft to the Wimsy list for review.
- Attestation and TLS: Osama to target future drafts to Wimsy for specific attestation issues.
- CCC Work: Attend conference calls regarding the CCC's work.
- Data Residency Requirements: Rama is to submit an internet draft.
Next Steps
- Authors to address open issues and incorporate feedback on all drafts.
- Working group to continue discussions on the mailing list and GitHub.
- Next meeting in Madrid.