Reversed HTTP binding for SOAP

Description

PAOS (Reversed HTTP binding for SOAP) is a protocol binding specification that inverts the conventional HTTP request-response model for SOAP-based web services. In standard SOAP over HTTP, a client initiates an HTTP request containing a SOAP envelope, and the server responds with an HTTP response containing another SOAP envelope. PAOS reverses this: the server can send an HTTP response that itself contains a SOAP request, and the client then replies with a subsequent HTTP request containing the SOAP response. This mechanism is formally defined within 3GPP TS 33.980, which profiles its use for Liberty Alliance Project (LAP) and SAML (Security Assertion Markup Language) protocols, particularly in scenarios involving identity federation and single sign-on (SSO).

Architecturally, PAOS operates within a multi-party trust framework. A key use case is the Identity Provider (IdP) initiated Single Sign-On with a Service Provider (SP). Here, the user's browser acts as the HTTP client. The IdP, acting as the HTTP server for the initial transaction, can embed a SOAP request within its HTTP response to the browser. The browser, following the PAOS binding rules, then forwards this SOAP request via a new HTTP request to the intended SP. This allows the IdP to asynchronously push authentication assertions or attribute queries directly to the SP through the user agent, without requiring the SP to poll the IdP.

The protocol's operation relies on specific HTTP headers and SOAP action URIs to indicate the reversed binding. The initial HTTP response from the server (e.g., IdP) includes a header like `PAOS` with a value identifying the supported versions and features. The SOAP envelope within this response is a legitimate request that the client must relay. This design is crucial for enabling seamless, secure interactions in federated identity scenarios defined by Liberty Alliance's ID-FF and ID-WSF frameworks, which were integrated into 3GPP's Generic Bootstrapping Architecture (GBA) and early multimedia service authentication mechanisms. PAOS facilitates a standardized way for network entities to communicate authentication and authorization data behind the scenes, improving user experience by enabling transparent service access across different domains.

Purpose & Motivation

PAOS was created to solve a fundamental limitation in the standard HTTP-based SOAP interaction model for specific federated identity and secure service scenarios. In traditional client-server web services, the client always initiates the dialogue. However, in identity federation protocols like those from the Liberty Alliance, there is a need for an Identity Provider to proactively communicate with a Service Provider via the user's browser. For example, during a single sign-on flow, after authenticating the user, the IdP needs to send a SAML assertion to the SP to grant access. A standard HTTP redirect with a URL-encoded token is one method, but PAOS provides a more structured, extensible, and SOAP-based alternative that can carry richer, signed XML payloads.

The historical context is the early 2000s convergence of web services and telecommunications, where 3GPP sought to integrate internet-based identity management into mobile networks. The Liberty Alliance Project developed specifications for federated identity, and 3GPP adopted and profiled these within its security architecture, notably for GBA and early IMS (IP Multimedia Subsystem) service authentication. The standard SOAP-over-HTTP binding was insufficient because it required the SP (the ultimate receiver of the authentication data) to act as an HTTP client and poll the IdP. PAOS elegantly solves this by allowing the IdP to 'push' a SOAP request through the user's agent, enabling a direct, secure, and synchronous-like exchange between the IdP and SP without complex backend connections, simplifying deployment and enhancing security by keeping assertions within controlled SOAP messages.

Key Features

• Reverses the standard HTTP client-server roles for SOAP messaging
• Enables server-initiated SOAP requests to be delivered via a client agent
• Defined for use with Liberty Alliance Project (LAP) and SAML protocols
• Supports asynchronous, push-based authentication and authorization flows
• Utilizes specific HTTP headers (e.g., PAOS header) to negotiate and indicate the binding
• Facilitates federated identity and single sign-on in 3GPP network service architectures

Evolution Across Releases

Defining Specifications