Attending IETF meetings is always an amazing experience, and IETF 120 was no different. This community is responsible for developing standards people use every day, whether they realize it or not, such as DNS and TLS. The specifications developed here are responsible for ensuring secure connections between websites, systems, and services. The hallways and sessions were filled with insightful discussions and innovative proposals to improve the Internet. In the fields of identity and security, topics ranged from exploring software supply chains to credential profiles, security events, and more. With 832 registered attendees onsite and 705 registered remote participants, we had a diverse and lively event.
The OAuth Working Group (oauth) alone met for six hours across three separate sessions; that’s in addition to time spent in the Security Area Open Meeting (saag) to discuss improvements to current standards for security events. I’m going to highlight three of the drafts discussed during the week:
- Push And Pull Based Security Event Token (SET) Delivery (in saag)
- Transaction Tokens (in oauth)
- OAuth Identity and Authorization Chaining Across Domains (in oauth)
Security Event Tokens and Pushpull
Security events used to have its own working group in the IETF; that group closed in June 2023 as the last work item, RFC 9493: Subject Identifiers for Security Event Tokens, was approved for publication as an RFC. While their chartered work concluded, I am making an argument that additional work is needed, specifically around an efficient bi-directional transport mechanism for SETs. Traditional push delivery can only handle one SET per connection and does not allow for delayed acknowledgments, necessitating multiple connections for bi-directional communication. The ‘pushpull’ delivery aims to overcome these challenges by introducing a common JSON object for SET transfer, acknowledgment, and error reporting and transporting it via WebSockets or HTTP request / response.
While strongly tied to previous work done in the IETF, this draft has the interest of the OpenID Foundation’s Shared Signals working group. As with the case of all drafts, the more eyes on it to offer diverse perspectives is critical; I’ll be revising the draft based on the discussions and look forward to bring it back to the IETF and the Shared Signals group over the next few months.
OAuth Transaction Tokens
The oauth meeting included a conversation about an updated draft on OAuth Transaction Tokens (TraTs). This draft is co-authored with myself, George Fletcher (CapitalOne), and Pieter Kasselman (Microsoft). In a microservices architecture, applications are broken down into smaller, independent services that interact through well-defined APIs. This approach offers several advantages, including enhanced development velocity and independent development and release cycles. However, microservices are typically deployed within a secured “virtual private cloud” (VPC) that often relies on implicit or service-to-service trust models using SPIFFE, which can leave systems vulnerable to software supply chain and privileged user compromise attacks.
TraTs offer a simple solution to address these vulnerabilities. TraTs are short-lived, cryptographically signed JSON Web Tokens (JWTs) that immutably preserve the user identity and authorization context of an external API invocation. They ensure that the user identity and authorization details of an external request, such as an API call, are maintained across all involved services within a microservices application. Additionally, TraTs enable these services to assert their involvement in the transaction chain to downstream workloads. This provides assurance of both user identity and authorization context at every step of a transaction.
Identity Chaining
One specification is important to me (not one I’ve authored, but have contributed to), and that’s one on identity chaining. The OAuth Identity and Authorization Chaining Across Domains (aka, ID-chaining) draft enables services in different trust domains (e.g. a SaaS provider and an enterprise application or VPCs belonging to the same organization in different cloud platforms) to assert the identity of the user in API calls so that the API server does not have to blindly trust the caller. This method allows for a more seamless and secure way to handle identity transitions and associations, ensuring that identity-related data remains consistent and verifiable across services in different cloud infrastructures.
This isn’t of interest solely to the oauth working group. The new Workload Identity in Multi-System Environments (wimse) working group is also very interested in what this specification might offer in the case of multi-domain authorization scenarios.
Conclusion
Between the formal sessions, informal side-meetings and discussions over coffee or dinner, the IETF 120 meeting lived up to its expectations of being a cauldron for churning and firming new ideas. Technical standards development does not move quickly; consensus in highly specialized areas like authorization takes time. Still, meetings like IETF always provide the energy of face-to-face interactions to push ahead with the work. New and evolving specifications such as OAuth Transaction Tokens, ID-Chaining, and the Pushpull delivery of SETs, promise to enhance security, efficiency, and flexibility in managing digital identities. As these technologies continue to evolve, they will undoubtedly play a crucial role in shaping the future of identity-driven security.