General comments * adding a diagram showing the message flow would be very helpful; especially as I believe the desire deployment supports multiple trust domains. This implies that any given transaction token is only valid within a single trust domain. * a lot more specificity needs to be added to sections 4 and 5 * the current draft is directional but lacks specifics. I’m not sure transaction tokens are the correct construct for crossing trust domain boundaries. Concepts from transaction tokens are applicable. * recommend continuing to work with the other draft looking at leveraging transaction tokens for AI Agent flows
Section 3 - Rationale * this section mentions both the security boundaries between agents as well as cross-domain calls. I’m not sure how to reconcile this with transaction tokens being restricted to a single trust-domain. Is the expectation that all agents in the A2A call chain are in the same trust domain (i.e. audience). Basically all agents would need to trust the same Transaction Token Service. That doesn’t seem viable for these complex call chains. * for transaction tokens the expectation is that the transaction token is obtained at the beginning of the transaction and then used as a bearer token throughout the rest of the call chain. It’s unclear to me if this will work with A2A complex call chains as I suspect that a downstream agent may want to obtain it’s own “transaction token” (potentially from a different Transaction Token Service). If this is true, it breaks the transaction token model. Section 4 - Transaction Token Request * minor nit - in the latest draft base64url encoding of JSON objects has been removed * request_details - it makes sense to pass the original A2A request call in the `request_details` parameter. One thing to consider if whether additional data needs to be passed in as well and whether that gets added into the A2A request or a wrapper structure is needed to carry both the A2A original request as well as additional claims. * request_context - the request_context is also immutable when the transaction token is issued so it can’t be changed by downstream systems * a proper profile will need to explicitly specify the content of these JSON objects so that the Transaction Token Service will know how to parse them and extract the necessary details Section 5 - Transaction Token Claims * the ‘purp’ claim is no longer supported and has been replaced by the ’scope’ claim * ’tctx’ - the Transaction Token spec explicitly allows the Transaction Token Service to have authority to make decisions about which claims from the ‘request_details’ are included in the ’tctx’. It is possible for this profile to override that and that decision should be taken carefully. * ‘rctx’ - this object is immutable when the transaction token is issued and can not be changed. I’m not sure that matches the intent in the doc George Fletcher Identity Standards Architect Practical Identity LLC
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
