Notetakers: Arndt & Jeff
Existing work aiming for WGLC
Lots of current work in-flight, Workload Identity Practices is in AD
review
Callout for interim meeting for AI Agent Authentication and
Authorization, will hear about today
Callout for Workload Identity Federation: Not we are tackling in WIMSE
but there is a lot of traction so maybe we need to talk about it
Draft: https://datatracker.ietf.org/doc/draft-ietf-wimse-workload-creds/
Presentation:
https://datatracker.ietf.org/meeting/126/materials/slides-126-wimse-workload-credentials-witwic-01
Brian is giving an update of the Workload Identity Credentials draft and
it's state (WGLC). A lot of discussion on the list. Brian C. is not sure
if all of the feedback received is directly related to the draft, but
there's useful feedback in between the authors will work on. He's
showing a screenshot from Github. He ends the presentation with a
metaphore of the road ahead to San Francisco until which the authors are
planning to be finished. The chairs ask whether the feedback received is
big picture or details. Brian confirms it's details.
Workload need to represent their identity and bind a key to it: Format
of a certificate of a JWT
There was a lot of feedback, aiming at finishing before SFO IETF 127
Justin: What is the state? Do we need to start over or cleanning?
Brian: The latter
Draft: https://datatracker.ietf.org/doc/draft-ietf-wimse-wpt/)
Presentation:
https://datatracker.ietf.org/meeting/126/materials/slides-126-wimse-wpt-of-wimse-00
After giving context, Brian explains that there hasn't been much work
happening since Shenzen. He's showing a screenshot from a list of Github
issues. He's pointing out an issue that talks about adding transaction
token to the examples. Brian believes that OAuth is for the outside of
the trust domain, and within it, it's WIMSE and says that adding the
Transaction Token into the examples would help paint that picture. He's
finishing the presentation with an outlook to the next IETF. The chairs
ask whether this work is expected to finish until the next meeting and
the authors confirm.
Proof of Possession of the key associated with the WIT
No progress since Schenzen
One callout to have an example of TXn-Token with a WPT. Author mind is
at OAuth is on the outside boundary of the Trust Domain while the
Txn-Token will be on the internal. While all the examples are not
normative this is important.
Also Yaron pointed to some clean-up being needed in the Draft.
Ambitious to close all of that before SFO - IETF 127.
Pieter (chair hat off): Very supportive of having an example on
Txn-Token
Pieter (chair): Please do finish before SFO
Justin (chair): How confident are we to close that before SFO
Arndt: Confident we can do it now that WIMSE Credentials is close to the
end
Yaron S.: Txn-Token should also be mentionned in the Architecture doc
Draft: https://datatracker.ietf.org/doc/draft-ietf-wimse-http-signature/
Presentation:
https://datatracker.ietf.org/meeting/126/materials/slides-126-wimse-http-signatures-00
Yaron presents 2 significant changes and is asking about WGLC. He
presents a slide about the audience discussion, highlighting how
audience started as an HTTP header but has now moved to a HTTP Signature
signature parameter. This avoids the extra header while maintaining the
content and characteristics. Adding the audience in general is needed to
survive request URI rewriting in proxies while keeping the signature
intact. The other topic Yaron presents is about binding request and
response in HTTP message signature and presents a solution where the
nonce value of the request is copied into the response signature as a
"wimse-req-nonce" signature parameter. The examples are not up-to-date
(-04) but has been fixed (-05). Yaron is asking for WGLC. The chairs ask
for questions and feedback. Kathleen M. is asking whether this work is
aligned with WebBotAuth and the work that is happening there, Yaron says
that the work is not aligned. Jonathan Hoyland asked whether signature
stripping is an attack vector. Yaron believes that it's a deployment
decision/configuration parameter. Kathleen, John, Andrew commit to
reading the draft prior WGLC. The chairs discuss issuing WGLC in the
following weeks.
2 significant changes:
1/ Audience signal to control authorized recipients: Shifted from header
to signature parameter; protect from proxy and tranformation on the way
2/ Binding between request and response: despite the signature a
malicious entity could copy a response for a request which is not
related; introducing a nonce as signature parameter
Calling for WGLC
Kathleen: Is this aligned with WebBotAuth?
Yaron S.: No
Jonathan: If signature is optional does that mean that signature
stripping is an attacker vector
Yaron S.: It is a deployment decision, configuration parameter
Justin (chair): Confirming the question / answer is about Response
signature
Reading: Kathleen, Jeff, Jonathan, Karthik
Justin (chair): Issue WGLC in the following weeks
Karthik: Would like to spend some time on it
Draft: https://datatracker.ietf.org/doc/draft-ietf-wimse-mutual-tls/
Presentation:
https://datatracker.ietf.org/meeting/126/materials/slides-126-wimse-wimse-mtls-00
Joe is presenting the last update of the mTLS adopted draft which is an
update to the server name validation. He's echo-ing the question from
Yaron whether certificates should have a DNS name in them or not? Arndt
asks on the microphone whether this question is not actually a WIMSE
creds WGLC item and not just specific to mTLS. The chairs discuss
chaining and organizing the order of WGLC.
Draft pretty stable so far; Mostly server name resolution and rules
Call for open issues if needed, pretty close for WGLC
Arndt: is the DNS discussion not a WGLC comment for the WIMSE Creds
Draft
Joe: Agree
Draft: https://datatracker.ietf.org/doc/draft-ietf-wimse-arch/
Presentation:
https://datatracker.ietf.org/meeting/126/materials/slides-126-wimse-wimse-architecture-00
Joe presents a list of a docent updates to the architecture since the
last update. Updates include workload vs workload instance, identifiers,
identity binding, delegation and impersonation, key management, policy
enforcement and more. At the next slide he's asking for WGLC. He would
like to see more review before WGLC but acknowledges that this can be
within the review process itself. Mark asks on the microphone that
figure 5 is missing wording about remote attestation. In some cases the
workload doesn't trust the agent and he'd like to add wording there.
Flemming A. raises concern that consistency with the credentials draft
drifted with the last iterations. Justin reminds the authors that the
architecture is supposed to be reactive to the other work that is
happening and explains that that is the reason the architecture is
lagging compared to other work and (in-)consistencies are expected in
the current stage.
Don't know if they should talk about Txn-Token but that sounds important
Need more reviews before WGLC, still WGLC is always full of reviews
Mark: Figure 5. needs more details and need to detailled the
authentication / attestation mechanisms
Joe: Got it
Flemming: Did not review the last version. Think there are
inconsistencies with the Creds Draft
Joe: Agree
Justin (Chair): Please review more than one document at the time to
ensure consistency about taxonomy / ontology
Draft: https://datatracker.ietf.org/doc/draft-ietf-wimse-identifier/
Presentation:
https://datatracker.ietf.org/meeting/126/materials/slides-126-wimse-workload-identifier-00
Yaroslav shows a slide of the key changes since -02. Updates include
softening information disclosures, clarifications to definitions and
synced terminology with other documents. The slide ends with a statement
that all the outstanding issues are addressed. The next slide is asking
for WGLC. The chairs are asking for readers. Flemming, Nick, Kathleen
and Andrew commit to reading it. Pam D. is talking about the OAuth
SPIFFE Client Auth and whether there are dependencies to this work. The
room acknowledges it but believes that by the time the OAuth work
settles the WIT work will be finished.
Words and Terms are difficult that is why it takes time
Clarified grounded language for disclosure of information, ensure
bettert cosnsitency with other Drafts
Asking for WGLC
Pieter (Chair): We need more reviewer
Flemming, Andrew, Kathleen
Pam: Since the last pleanry, the OAuth SPIFFE Client authentication came
alive with usage of the WIT, is there any impact on WIMSE
Arndt: There are dependencies. SPIFFE has adopted the WIT work in CNCF.
It is up to decide how to handle it - soft dependencies
Pieter: I think it is pretty well contain
Draft:
https://datatracker.ietf.org/doc/draft-schwenkschuster-wimse-trust-domain-discovery/
Presentation:
https://datatracker.ietf.org/meeting/126/materials/slides-126-wimse-wimse-trust-domain-discovery-00
Following an agreement at Montreal
WIMSE Arch set the discovery out of scope
This closes it
Today there is an outbound establishment on how to resolve Trust Domains
Same problems exist in SPIFFE and WIMSE
Using same mechanism as OAuth with Metadata document
Do we agree on the problem space?
How do we solve it?
Hannes: 1/ Does WIMSE require something specific for discovery? 2/ What
about Authorization: What does the relationship means in a multi domain
ecosystem?
Aaron: What is the overlap in between that and CIMD? Cause it could
help. Do you see that as an option?
Arndt: yes there is definitively some thing to reuse
Jonathan: Is this the same problem as WebBotAuth?É
Arndt: Yes
Draft: https://datatracker.ietf.org/doc/draft-klrc-aiagent-auth/
Presentation:
https://datatracker.ietf.org/meeting/126/materials/slides-126-wimse-aims-00
Yaroslav sets the stage by talking about AI agents, how they are
sometimes wrongly treated as humans and that they are in need of
identity. A slide shows that it's an anti goal to invent new procotols
and not repeating mistakes. The goal is to locate missing pieces in
existing standards and surgically address them. A slide s hows the
background, how AI Agents are workloads that interact with users, LLMs
and tools/services/resources. The next slides shows a diagram that
contains of the various areas the draft talks about. Another slides
displays the key building blocks: SPIFFE, WIMSE, OAuth and SSF. The next
slides go over the building blocks in details. Identifiers, URI scoped
to a trust domain that uniquely identifiers an agent. Credentials,
agents need to proof that they have identifiers. Provisioning, make
credentials available. Authentication, agents proof posession of a
credential. Authorization. Monitoring, Observability and Shared Signals,
outside of IETF today. Policy & Compliance, which applies to all the
layers. Yaroslav asks to consider adoption in the WG. Peter L. brings up
that this work is similar to prior proposed work and how they relate.
Hank raises concerns that this work is biased within WIMSE. Brian
supports the work. Roberta supports the work too. Nick S. supports the
work.
Agents need Identity
It is hard to wrap one's head around dozens of Drafts and Standards
Looked for you at what exists and is missing
Requesting Adoption from the WG, WIMSE is the best place for that
Peter: Expressing interesed in this cause we pushed for a similar Draft
several IETF ago, where some endpoints might act as
Yaroslav: We are not proposing anything new, yes there might be missing
blocks. But formalizing those would be oput
Andrew: Could we separate Agent from Workload
Paul:
Arndt: I am supportive, we need to be crisp about definition
Hank: I am not supportive at this stage cause it conflates definition
Brian: I am very supportive once I understood the piece of the model
Roberta: I am very supportive of the work
Nick: OpenAI We are very interested into those flows
Justin (chair): We wil do a call for adoption soon as it seems there is
support
Paul presents how to give workloads offline access to user data without
refresh tokens. Agent use case but is valid broader. He's explaining the
problem on multiple slides and where current solutions fall short. Arndt
asks if transaction tokens have been considered. Paul raises that
transaction tokens are currently only within a trust domain and this
draft is cross trust domain. Hannes asks whether this work is not better
suited in OAuth. Aaron confirms that this is OAuth unless you're trying
to bind this to WIMSE artefact. He asks what is the handle of the
problem, whether it's offline access or binding to the workload. Peter
mentions work that is happening to make transaction tokens work cross
trust domains. George F. mentions that this may directly be covered by
the user-managed access (UMA) work. Brian wonders if a profile of ID-JAG
is a bit too detailed and suggests to profile ID chaining instead.
Agent wants to access User Resouces and user cannot be contacted
Usual flow would be using Refresh Token, but we don't want that the
refresh is unique per agent
ID-JAG is an option, but that does not work either as IdToken is also
unique for all use cases
Arndt: Curious about if Txn-Token could be used there?
Paul: Mostly useful within one trust domain, here we are looking at
multiple trust domain
Hannes: Would this be more suited for OAuth ID-JAG work? Should be
discussed on the OAuth WG Mailling List
Paul: yes
Aaron: This might be an OAuth problem. If this is only about the Refresh
Token, then it is an OAuth problem. Why is it into WIMSE? Is it because
you are introducing Workload...?
Paul: This is a for a client having multiple Workloads
Peter: You said is that Txn-Token are not cross domain, but there are
proposal for that
George: Pre-Authorizing a workload to do something, this was a use of
UMA
Brian: You talk about a profile of ID-JAG, but should be over Identity
Chaining
Draft:
https://datatracker.ietf.org/doc/draft-jiang-wimse-heterogeneous-credential/
Yuning presents slides that show that a request carries many credentials
and all matter for a single decision. A slide shows that the scope of
this work and what is missing on the receiving side. A multi-credential
handle mechanism is needed. Another slide shows how this work relates to
WIMSE. Yuning also presents the mechanics of the draft. Jonathan is
asking about whether specific errors can be used to learn about a
system. Pam D. raises a concern about credential replay.
There multiple cases of using multiple credentials as part of flow
there errors at different layers depending which credential is missing
What if we had one common verification status
Jonathan: Pretty interesting. Do you have to worry about Oracle attacks?
Pam: This feels like credential replay, it is part of the security
considerations
Draft https://datatracker.ietf.org/doc/draft-rampalli-pedigree/
Presentation:
https://datatracker.ietf.org/meeting/126/materials/slides-126-wimse-karthikrampalli-pedigree-deck-00
Karthik describes a problem where sub-agents act on orchestrators
ambient credentials. To a relying party every request looks like from
the orchestrator. He goes through multiple slides describing the problem
space. And also slides explaining the related protocols and then the
mechanics of the draft. He raises questions to the working group about
scope, framing and asking for review. Nick S. agrees to read the draft,
Jeff L. asks how it works with key-bound credentials and Aaron brings
OAuth into the picture.
The problem is that sub-agent are spawned by the meta-agent, and they
carry the same identity as the meta one
The shared credential miss the mark
A compromised orhestrator can affect the whole chain
Nick: Interested
Jeff: How the credential can be shared if there is a proof of possession
Aaron: There some problems from OAuth that could be put in place to
prevent the sharing of credentials in the first place
Draft:
https://datatracker.ietf.org/doc/draft-reddy-wimse-workload-attestation/
Presentation:
https://datatracker.ietf.org/meeting/126/materials/slides-126-wimse-wimse-workload-attestation-00
Tirumaleswar sets the stage and the gap where TLS attestation stops at
the proxy. A slide proposes 2 new HTTP headers carrying the evidance and
attestation result. Usama sees a critical issue (please go to transcript
for details). Hank B. says that platform + key is complicated or
impossible.
Adding new header to host the Workload Evidence
Usama: It needs to be connected to the session, There is a CVE related
to that.
Tirumal: the request has a unique nonce so it is bound to the request
Hank: Platform + keys are very complex
Draft:
https://datatracker.ietf.org/doc/draft-schrock-human-authorization-binding/
Draft:
https://datatracker.ietf.org/doc/draft-schrock-ep-authorization-receipts/
Presentation:
No show
Draft: https://datatracker.ietf.org/doc/draft-sato-soos-mjwt/
Draft: https://datatracker.ietf.org/doc/draft-sato-soos-kia/
Presentation:
https://datatracker.ietf.org/meeting/126/materials/slides-126-wimse-soos-mandate-jwt-cross-principal-transaction-id-xpid-00
Tom describes a problem that is being worked on across four idenpendent
protocols. He describes 2 enforcements, MJWT (Mandate JWT) and CAP
(Constitutional Action Policy). Tom offers to contribute to other works
and offers his help.
George: Lots of important content presented today, whenwe talk aboout
attenuation and scope in cross domain, this is not always the case
Usuma: We have a lot discussions around Attestation, there are lot of
CVEs with High CVSS score. Would Like WIMSE to consider this part too
Justin (chair): We are not in the Security Area yes, but we have a
Technical Advisor to be ensure that the work is focused on Security. As
long as it is not implementation level, but at the protocol level
Arndt: Would like to come back to WIF, I see value. All started recently
as a 3LA.
Justin (chair): the 3 implementations are not homogeneous, this WG
should look into it
Charles: Part 2 great, but please focus on WGLC. Agent-Proto is supposed
to reuse a lot of the work done in WIMSE so please finish that
Justin (chair): BOF is Thursday 9 AM
Pam: Absoilutely on the WIF comment. I don't believe all Agents are
workload. If you only have Client ID 1 Secret, are you a workload?
Roberta: