In this blog post, I hope to provide some background on the driving purpose of DTVA. In addition, I will provide an overview of the specifications as well as potential future directions.
Tremendous value has been realized from standardization on SAML and OpenID Connect for Internet Single Sign-On (SSO). These specs are primarily used as an abstraction or bridge - allowing the authentication of an identity by one enterprise or consumer property to be used to initiate access into other applications and services. However, relatively few deployments go beyond that initial authentication event and attempt to create a cohesive session across these various services.
After the initial authentication event, an Identity Provider (IdP) generally loses all control of the terms and conditions of that authentication. The sessions created within any application are detached from the IdP, and in some cases an authentication event meant to be good for a few minutes will instead grant long-lived access into an application.
For more modern applications using OpenID Connect, access tokens are used to access essential systems. In these applications, the expiry of an access token may be used to necessitate further interaction with the IdP, including re-authentication. This allows the IdP to inject themselves on a periodic basis: both interact with the user, and to use new tokens to notify applications of policy and attribute changes.
Even for these applications, growing use of dynamic policies and exposure to real-time information available to the IdP have increased the desire to rapidly respond in the case of time-sensitive changes to authorization. The only mechanism available today (at least by standard means) is to decrease the lifetime of tokens, which creates additional burden on the IdP - and may result in a poorer user experience.
What DTVA Provides
DTVA is meant to allow an IdP to securely, reliably, and expeditiously distribute state changes around a token's validity to services and applications. It allows services and applications to integrate checks for token validity into their normal processes with full control over performance and availability.
DTVA is also meant to support additional communication around token usage and user activities. This allows IdPs to declare token policies around such information, and to make dynamic policy decisions from the activity information they receive. As an example of this, the submitted draft proposes a mechanism for an application to report user interaction, to support an IdP expiring tokens early due to user inactivity. This allows the IdP to make policies around user interactivity across all applications as a group, something which historically has only been accomplished with proprietary mechanisms.
There are existing logout specifications that have similarities to DTVA but they only address distributing logout action, where the semantics are to end the session and destroy any associated data. The DTVA semantics are minimized to only indicate the current tokens have expired, and that access should be temporarily suspended until a new token is provided. This allows the IdP much greater control over the access provided to different applications by allowing it to dictate the terms by which new tokens are provided. New tokens may be created when a risk prompts for a challenge in user credentials, based on authorization changes due to a change in roles within a user directory, or the IdP may refuse to issue new tokens for a user or application whose access is revoked.
The IdP may implement business policies to control how, when and why tokens are issued, but from an application standpoint the logic remains simple - if a token is no longer usable, fetch a new one.
To enable checking whether a token is still usable, DTVA specifies a HTTP-based API for use within an organization or a datacenter. This API is meant to locally deployable - organizations are able to deploy and secure their own systems which provide this API to meet the specific performance, reliability and security requirements of their environment. This API also has considerations made to support "eventually consistent" environments - where changes are not guaranteed to be immediately applied for latency and performance reasons.
Separate from the API, there needs to be a way to share information between systems local to applications and to the remote IdP. DTVA allows for multiple specifications, each defining a sharing mechanism for token validity information to be reliably distributed across organizational boundaries. These specifications define the data formats and transport mechanisms for how the state changes are shared between the IdP and each dependent Service Provider (SP). They can also specify how SPs share activity telemetry back to the IdP for risk analysis and other business processes.
Importantly, the information shared is constrained such that it contains no Personal Identification Information (PII). These specifications speak only in terms of opaque identifiers which either referenceable by (or are embedded within) tokens. In this way, the tokens remain the authoritative source of information on authorization and attributes. The validity information to a party without the associated tokens has at most statistical value only.
The current submission specifies the use of hashgraph as a distribution and consensus mechanism to connect DTVA instances. In addition to providing reliable delivery and consensus on message ordering, hashgraph provides a lower latency and a shared view of received message time. These properties help in ensuring the state across all instances quickly become consistent, barring any sort of network difficulties or attacks.
There are other specifications planned for the information distribution between parties. These possibly include HTTP forward proxy, ID-events over a reliable message queue, and supporting Distributed Ledger Technologies (DLTs, blockchains) with fast confirmation times such as Ethereum.
A proof of concept implementation of the API has been released on Github. This implementation includes the HTTP API and support for the hashgraph-based synchronization functionality. A future release may include proof-of-concept integration with PingFederate, as well as an administration console for viewing active user sessions and revoking tokens.
A profile on top of SAML Web SSO is also being discussed, allowing the same mechanisms to be used with environments using SAML instead of OAuth 2 or OpenID Connect.
SSO has always focused on the creation of the session, which while vital is only part of the actual lifecycle. DTVA aims to give IdPs and apps a means to manage that full lifecycle.