Technical Comparison: OpenID and SAML - Draft 07a

Abstract

This document presents a technical comparison of the OpenID Authentication protocol and the Security Assertion Markup Language (SAML) Web Browser SSO Profile and the SAML framework itself. Topics addressed include design centers, terminology, specification set contents and scope, user identifier treatment, web single sign-on profiles, trust, security, identity provider discovery mechanisms, key agreement approaches, as well as message formats and protocol bindings. An executive summary targeting various audiences, such as end-users, implementors, and deployers, is provided. We do not attempt to assign relative value between OpenID and SAML, e.g. which is "better"; rather, it attempts to present an objective technical comparison.

Revisions of this doument:

This version:

http://identitymeme.org/doc/draft-hodges-saml-openid-compare-07a.html

Latest version:

http://identitymeme.org/doc/draft-hodges-saml-openid-compare.html

Previous version:

http://identitymeme.org/doc/draft-hodges-saml-openid-compare-06.html

Table of Contents

1.  Introduction
2.  Executive Summary
    2.1.  The End User Perspective
    2.2.  The Implementor Perspective
    2.3.  The Deployer Perspective
    2.4.  The "Tool" vs. "Metal" Analogy
    2.5.  Summary Comparison Table of Technical Features
3.  Terminology
4.  OpenID - SAML Technical Comparison
    4.1.  Specification Set Contents and Scope
    4.2.  User Identifier Treatment
    4.3.  Web Browser Single Sign-On
        4.3.1.  Web Browser SSO with Association
        4.3.2.  OpenID Authentication without Established Association
        4.3.3.  Unsolicted Response
    4.4.  Trust
    4.5.  Security
    4.6.  OP/IDP Discovery Mechanisms
    4.7.  Key Agreement Approaches for OP/IDP - RP Communication
    4.8.  Message Formats and Protocol Bindings
    4.9.  Assertions
5.  Change Log
6.  References
Appendix A.  Acknowledgments
§  Author's Address

1.  Introduction

This paper presents a technical comparison of the OpenID Authentication protocol and the Security Assertion Markup Language framework (SAML), and its Web Browser SSO Profile. Overall, the comparison is conducted between OpenID 2.0 and SAML 2.0, although prior versions of each are mentioned occasionally. We do not attempt to assign relative value between OpenID and SAML, e.g. which is "better". Rather, we attempt to present an objective technical comparison.

Non-technical readers may glean the gist of this document from the executive summary.

Technical readers will find the remainder of this document divided into topical sections, each of which provides a tabular comparison between the two specifications.

2.  Executive Summary

The analysis in this document demonstrates that the OpenID Authentication specification and the SAML Web Browser SSO Profile appear to offer very similar functionality. Though one cannot directly compare the OpenID Authentication specification to the overall abstract SAML framework itself. We said "appear to offer" in the foregoing because there are some detailed aspects of the SAML Web Browser SSO Profile, e.g. explicit privacy provisions, that OpenID Authentication does not presently explicitly provide.

The value to the reader of comparisons between these two protocols depends upon the reader's perspective. For example, if the reader is an end user, her concerns and interests will be different than if the reader is an implementor of the specifications, a system administrator, an IT system analyst, and so on.

Therefore, we have divided the remainder of this section into several "mini" executive summaries based on a few anticipated reader perspectives. Hopefully, you, the reader, will be able to glean useful insight by reading the summary that most closely matches your perspective. Also, for the adventurous reader, reading all the summaries—as well as the rest of this document—will hopefully prove enlightening and useful.

The executive summary sections below are organized as follows:

Section 2.1 (The End User Perspective): The End User Perspective (The End User Perspective)

Section 2.2 (The Implementor Perspective): The Implementor Perspective (The Implementor Perspective)

Section 2.3 (The Deployer Perspective): The Deployer Perspective (The Deployer Perspective)

Section 2.4 (The "Tool" vs. "Metal" Analogy): The "Tool" vs. "Metal" Analogy (The "Tool" vs. "Metal" Analogy)

Section 2.5 (Summary Comparison Table of Technical Features): Summary Comparison Table of Technical Features (Summary Comparison Table of Technical Features)

Also, Section 3 (Terminology): Terminology (Terminology) may prove helpful to readers uncertain about the meanings of various terms. Note that term definitions are sensitive to context-of-use.

2.1.  The End User Perspective

SAML itself is an abstract framework providing for the concrete definition of assertions as well as protocols for obtaining and tranporting assertions. SAML itself does not directly define any end-user visible behavior, while the OpenID Authentication 2.0 specification concretely defines a specific Web Single Sign-On protocol prescribing a particular "end-user identifier format" as well as a particular form of "identity provider discovery". Thus it isn't possible to make a direct end-user comparison between the two, unless one is comparing a particular SAML profile that does in fact prescribe specific end-user-visible behavior(s). None of the SAML profiles specified within the SAML specification set do so, however.

Also, there is a school of thought that end users should not have to know about the various machinations involved in Web SSO—it should just magically occur, as transparently and invisibly as possible. SAML-based Web SSO can be crafted in order to meet such a requirement, while OpenID, as presently specified, cannot meet it because it is predicated on interactions visible to end-users.

Note also that it is possible for one to create a SAML Web Browser SSO-enabled set of websites that exhibit the exact same end-user-visible behavior as OpenID-enabled websites. Accomplishing this is predicated on implementing and deploying a SAML profile that exhibits the same operational behavior as an OpenID implementation. See Section 2.2 (The Implementor Perspective), below, for some more discussion of this.

See also Table 1 (Summary Comparison Table of Technical Features): Summary Comparison Table of Technical Features (Summary Comparison Table of Technical Features).

2.2.  The Implementor Perspective

From an implementor's perspective, the OpenID Authentication specification [OpenID.openid‑authentication‑2_0] (OpenID, “OpenID Authentication 2.0 - Final,” September 2007.) is relatively self-contained, and is a single specification rather than a set of several specifications, as is the SAML specification set (this is only true if one does not also implement any of the various OpenID extensions, which are defined in additional separate specifications, and does not also count other specifications referenced by OpenID Authentication). The spareness of the OpenID Authentication specification in comparison to the SAML specification set is due to its direct concreteness, rather than adopting a framework approach, as discussed above in Section 2.1 (The End User Perspective).

Since the OpenID Authentication specification defines the data it conveys as a set of "key-value" pairs, and then specifies placing them directly within HTTP messages, it avoids using some form of encoding language, and structure, for the OpenID "messages". Thus there are fewer external dependencies (though, the final revision of OpenID 2.0 references 16 other specs, which number is in the SAML specification set's ballpark), and implementation is more simple, than a similar implementation of any SAML-based profile. This simplicity is obtained on OpenID's part by not employing XML [W3C.REC‑xml] (Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler, “Extensible Markup Language (XML) 1.0 (2nd ed),” October 2000.), and thus not using XML Digital Signature [W3C.xmldsig‑core] (Eastlake, D., Reagle , J., and D. Solo, “XML-Signature Syntax and Processing,” October 2000.).

In comparison, SAML defines its assertions and messages in terms of XML [W3C.REC‑xml] (Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler, “Extensible Markup Language (XML) 1.0 (2nd ed),” October 2000.), necessitating message assembly and parsing that is more complex than OpenID's key-value pair approach. Though, with SAML and XML, one can straightforwardly express subtle, hierarchical relationships, something that is difficult to accomplish with simplistic key-value pairs.

SAML's assertions and messages are tailorable, extensible, and defined abstractly in the "core" SAML 2.0 specification [OASIS.saml‑core‑2.0‑os] (Cantor, S., Kemp, J., Philpott, R., and E. Maler, “Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML) V2.0,” March 2005.). Since this core specification is essentially an "abstract class" (to use a object-oriented programming analogy), one must cast the constructs defined in the core specification in terms of specific use cases, define and tailor their exact contents, and then bind them to underlying protocol(s) for conveyance. This has already been done by the SAML community for some common use cases such as "web single sign-on" (which is directly comparable to the use case behind OpenID Authentication). The specifications of these SAML "profiles" and "bindings" are in additional specifications [OASIS.saml‑profiles‑2.0‑os] (Hughes, J., Cantor, S., Hodges, J., Hirsch, F., Mishra, P., Philpott, R., and E. Maler, “Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0,” March 2005.) [OASIS.saml‑bindings‑2.0‑os] (Cantor, S., Hirsch, F., Kemp, J., Philpott, R., and E. Maler, “Bindings for the OASIS Security Assertion Markup Language (SAML) V2.0,” March 2005.) included in the SAML 2.0 "specification set" [OASIS.saml‑2.0‑spec‑set] (OASIS, SSTC., Ed., “Security Assertion Markup Language (SAML) v2.0 Specification Set,” March 2005.).

Also, if the SAML specification set does not provide a profile and binding to address one's particular use case—where, say, SAML assertions could play a useful role as security tokens—then one can craft one's own profile and bindings, building on the core specification, and even the other specs comprising the SAML 2.0 specification set. Examples of doing exactly this are both the "SIP-SAML" draft specification [I‑D.ietf‑sip‑saml] (Tschofenig, H., Hodges, J., Peterson, J., Polk, J., and D. Sicker, “SIP SAML Profile and Binding,” March 2009.) in the IETF's SIP Working Group, as well as the SAML 2.0 "Simple Sign binding" [OASIS.sstc‑saml‑binding‑simplesign‑cd‑02] (Hodges, J. and S. Cantor, “SAML 2.0: HTTP POST "SimpleSign" Binding,” September 2007.) upon which the draft "OpenID-SAML Lightweight Web Browser SSO Profile" [draft‑hodges‑saml‑openid‑profile‑02] (Hodges, J., “OpenID-SAML Lightweight Web Browser SSO Profile - Draft 02,” September 2007.) is based.

See also Section 2.4 (The "Tool" vs. "Metal" Analogy): The "Tool" vs. "Metal" Analogy (The "Tool" vs. "Metal" Analogy), below.

Additionally, for the curious, there is a brief introduction to the SAML 2.0 specification set available, that's written from an implementor's perspective: "How to Study and Learn SAML" [OASIS.draft‑hodges‑HowToLearnSAML‑01] (Hodges, J., “How to Study and Learn SAML,” October 2006.).

Both SAML and OpenID are implementable in a variety of programming languages, including scripting languages such as Perl, Python, PHP, and Ruby—and a variety of open source implementations of both are available [SAML.open.source.impls] (, “SAML Open Source Implementations,” .) [OpenID.site] (, “OpenID Site,” .). It is possible to craft implementations of either to be installable by users of lowest-common-denominator web hosting accounts, and such implementations of both are available (see Section 2.3 (The Deployer Perspective): The Deployer Perspective (The Deployer Perspective) for some more discussion of this point).

SAML was designed with security and modularity as its design centers (see "Design Center" in Table 1 (Summary Comparison Table of Technical Features) below). Thus this arguably contributed to the SAML specification set being more daunting to an implementor than the OpenID Authentication specification.

However, note that it is possible to craft simplistic SAML bindings and profiles that both relax SAML's security requirements and do their work in a more simple fashion, for example see the SAML "Simple Sign binding" [OASIS.sstc‑saml‑binding‑simplesign‑cd‑02] (Hodges, J. and S. Cantor, “SAML 2.0: HTTP POST "SimpleSign" Binding,” September 2007.), which eases development and deployment of SAML-based implementations.

See also Table 1 (Summary Comparison Table of Technical Features): Summary Comparison Table of Technical Features (Summary Comparison Table of Technical Features).

2.3.  The Deployer Perspective

Due to OpenID's design center (see "Design Center" in Table 1 (Summary Comparison Table of Technical Features) below), OpenID implementations will all likely be very similar and all operate similarly in terms of user identifier treatment and setting up interactions with other sites—i.e. essentially no setup required, and very little configuration. OpenID is baked into various blog/wiki packages and/or plugins for such packages are available. Or, if one has their own web application implementation, or are using an as-yet unsupported one, there are OpenID code libraries available. This makes it fairly easy to deploy an OpenID-based site. Note this ease is derived in large part from OpenID's overall design philosophy of "trust and accept all comers", and to its being a relatively rigidly defined self-contained specification. If one's site's requirements are essentially congruent with what OpenID offers and how it works, then deploying it will likely work out. Though, if one's site requirements evolve, e.g. require greater security, or wish to provide greater end-user privacy, then it may work less well.

Additionally, if one's use case is not necessarily one of "trust and accept all comers", or if one wants to have one's users wield one's own identifier format, or if one does not want to support insecure interactions with just any site and/or user agent, then deploying OpenID is not necessarily going to work.

For example, there are some sites/deployments that do not believe that the OpenID-prescribed OP/IDP discovery approach—e.g. of having users enter a pointer to their identity provider and then be shown a different web page wherein they login—is viable for their users (e.g. ask Scott Cantor of OSU/Internet2 about this). For these sites, OpenID is thus not directly usable as presently specified, and typically implemented, because it mandates such an approach. See [InCommonFederation] (, “InCommon Higher Education Federation,” December 2007.) for an example of a federation having such requirements.

SAML implementations, in contrast, are typically highly configurable, and offer an array of security features. Typically, they do not prescribe any particular form of user identifier, thus existing deploying sites can often retain their existing user identifiers, and new "greenfield" sites are free to concoct theirs without being constrained by SAML. Additionally, a deploying site, or federation of sites, may have particular requirements with respect to IDP discovery, metadata exchange, security characteristics, etc. They are typically able to tailor these as they need. Although, due to a paucity of conventions, and implementations thereof, deploying a SAML-based federation of sites, at this time, can be difficult—although, participating in an established federation, such as [InCommonFederation] (, “InCommon Higher Education Federation,” December 2007.), can ease this burden since many of the foregoing variables have been nailed down.

Recognizing that there is a non-trivial subset of federations that share typical requirements in these areas, an ad-hoc (presently) group of SAML folk are working on concocting a profile for standardized SAML IDP discovery, metadata exchange, HTTP protocol binding selection, and user identifier treatment. Implementations supporting this so-called "Dynamic Federation" profile will be essentially "as easy" to deploy as OpenID implementations, but with SAML's security and other features available—see [I2.DistribDynamSaml] (Internet2, “Distributed Dynamic SAML,” Octover 2007.), [IIW.DynamicFederationSession] (, “IIW2007b Dynamic Federation Session,” December 2007.), and Section 4.7 (Key Agreement Approaches for OP/IDP - RP Communication): Key Agreement Approaches for OP/IDP - RP Communication (Key Agreement Approaches for OP/IDP - RP Communication).

See also Section 2.4 (The "Tool" vs. "Metal" Analogy): The "Tool" vs. "Metal" Analogy (The "Tool" vs. "Metal" Analogy), below.

Another aspect of this overall puzzle is the notion of "federation", also known as "account linking" in some contexts. SAML v2.0 explicitly supports this notion through features in its assertion design and protocols. In contrast, the OpenID Authentication 2.0 specification nominally supports this notion at a protocol level, similarly to how SAML 1.x did, but it is not at present fully specified.

Related to this is the "user account privacy" notion. With SAML, an IDP, for example, is able to to interact with RPs using random opaque bit strings as user identifiers, with different bit strings used at different RPs on the behalf of the same end user. This inhibits the capabilities of RPs to collude against the user's interests. OpenID can apparently be profiled to accomplish this, but it is not at present fully specified.

See also Table 1 (Summary Comparison Table of Technical Features): Summary Comparison Table of Technical Features (Summary Comparison Table of Technical Features).

2.4.  The "Tool" vs. "Metal" Analogy

At a fundamental level, direct comparison of "SAML itself"—the SAML "core" defined in [OASIS.saml‑core‑2.0‑os] (Cantor, S., Kemp, J., Philpott, R., and E. Maler, “Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML) V2.0,” March 2005.)—and OpenID Authentication is somewhat difficult because SAML itself is an abstract framework, and OpenID Authentication is concretely defined without relying upon abstract underpinnings.

Thus, comparing OpenID and SAML itself is much like comparing a crowbar and a metal, such as iron. OpenID is like a crowbar—a very specific tool to solve a set of problems needing application of straightforward leveraging force. Crowbars are typically made from a mild steel, which is an iron alloy (a dash of carbon being the difference making the iron into steel). So when one picks the OpenID protocol specification and crafts an implementation and deployment from it, they will essentially end up with a single-purpose tool. Though with some effort, it can be used for other purposes, for example as a crowbar can perhaps be used as a hammer in a pinch (although it may not work terribly well as one).

SAML itself is like the metal iron, a basic material that can be shaped into a given form as needed, although such shaping (aka "profiling") must be performed before one has something in hand (aka "a profile") with which to perform a particular task. However, such shaping can and does yield useful tools such as crowbars, hammers, pliers, screwdrivers, and others. Additionally and more subtlety, one can alter the alloying elements in the process of crafting the end product, e.g. obtaining stainless steel for corrosive environments, and thus one may more closely meet the task requirements than one might otherwise if one were attempting to use an already crafted tool perhaps intended for a different application.

Therefore, it is more appropriate to compare the SAML Web Browser SSO Profile—defined in [OASIS.saml‑profiles‑2.0‑os] (Hughes, J., Cantor, S., Hodges, J., Hirsch, F., Mishra, P., Philpott, R., and E. Maler, “Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0,” March 2005.)—rather than the SAML "core" itself, to OpenID Authentication if a concrete comparison of existing capabilities is desired.

See also Table 1 (Summary Comparison Table of Technical Features): Summary Comparison Table of Technical Features (Summary Comparison Table of Technical Features).

2.5.  Summary Comparison Table of Technical Features

Below is Table 1 (Summary Comparison Table of Technical Features) summarizing our overall findings. Additional details with respect to the topics presented in Table 1 (Summary Comparison Table of Technical Features) can be found in Section 4 (OpenID - SAML Technical Comparison): OpenID - SAML Technical Comparison (OpenID - SAML Technical Comparison).

3.  Terminology

deployer

In this document, the term deployer refers to one who installs (and configures) one or more implementations, of one or more of the protocols or profiles discussed herein, onto systems for use by some group of users. Also, the deployer role is considered distinct from the implementor role.

deployment

A deployment is the operating installation of implementations, of one or more of the protocols or profiles discussed herein. Deployments are created by deployers.

Identity Provider (IDP)

The SAML term referring to, essentially, an authentication authority, or authentication server, and is essentially similar to the term OpenID Provider. See also OP/IDP (below), and the [OASIS.saml‑glossary‑2.0‑os] (Hodges, J., Philpott, R., and E. Maler, “Glossary for the Security Assertion Markup Language (SAML) V2.0,” March 2005.) definition for Identity Provider.

implementation

An implementation is taken in this document to mean a chunk of code—whether assembled, compiled, or interpreted—that implements one or more of the protocols and/or profiles discussed in this document.

implementor

In this document, an implementor is one who crafts implementation(s). Note that the implementor role is considered distinct from the deployer role.

key

In OpenID, a key is essentially a protocol message parameter name. For example, "OpenID.mode" is such a (fully-qualified) key (name). A key has an associated value. Within the OpenID specs, keys are often discussed in their unqualified form, e.g. "mode" [OpenID.openid‑authentication‑2_0] (OpenID, “OpenID Authentication 2.0 - Final,” September 2007.).

key-value

A shorthand OpenID term describing a "key and value" pair, or, more generally, the overall notion of conveying information as sets of key-value pairs. This term is used in both senses in [OpenID.openid‑authentication‑2_0] (OpenID, “OpenID Authentication 2.0 - Final,” September 2007.).

Note: often, this "key-value" notion is also referred to as "name-value" or "name-value pairs". Also, in the LDAP/X.500 world(s), similar constructs are referred to as "attribute value assertions" (AVAs).

OP

See OpenID Provider.

OP Identifier

An Identifier for an OpenID Provider.

OpenID

The term OpenID represents either..

(a) the Web SSO protocol of that name (see also OpenID Authentication) and/or,

(b) a user's OpenID identifier, and/or

(c) the suite of specifications defining (a), or perhaps just the OpenID Authentication specification,

..depending on its context of use.

OpenID Authentication

The name of the Web Browser SSO protocol defined in the specification ([OpenID.openid‑authentication‑2_0] (OpenID, “OpenID Authentication 2.0 - Final,” September 2007.) and/or [OpenID.openid‑authentication‑1_1] (Recordon, D. and B. Fitzpatrick, “OpenID Authentication 1.1,” January 2007.)) of the same name.

OP/IDP or IDP/OP

The term used in this document to denote both OpenID Providers (OP) and Identity Providers (IDP) in general, because: regardless of the particular Web SSO protocol(s) they speak, their role in the overall interactions with relying parties and user agents is essentially the same. Also, the generic term IDP is used by many camps within the overall Identity Management community, whereas OP is used only by the OpenID camp.

OP/IDP discovery

OP/IDP discovery is the process of finding a particular user's OP/IDP. It is typically performed by a relying party (RP) when said user has "visited" the RP by virtue of having her browser send an HTTP GET or POST message to the RP. The RP then, under certain circumstances, performs "IDP/OP discovery" in order to ascertain the address of the user's OP/IDP.

OpenID Identifier

The term used in this document for sense (b) of OpenID.

Within [OpenID.openid‑authentication‑2_0] (OpenID, “OpenID Authentication 2.0 - Final,” September 2007.), what we refer to here as an OpenID Identifier, is referred to variously as..

• URL Identifier
• User-Supplied Identifier
• Claimed Identifier

..depending upon context of use.

OpenID message

A term in this document meaning a particular set of key-value pairs comprising a particular OpenID message, e.g. an "authentication request" or an "Association Session Request".

OpenID Provider (OP)

The OpenID-specific term used in [OpenID.openid‑authentication‑2_0] (OpenID, “OpenID Authentication 2.0 - Final,” September 2007.) to refer to an "OpenID Authentication server", which in SAML is referred to as an Identity Provider, or IDP. See also OP/IDP.

principal

A SAML term that often, in SAML profiles [OASIS.saml‑profiles‑2.0‑os] (Hughes, J., Cantor, S., Hodges, J., Hirsch, F., Mishra, P., Philpott, R., and E. Maler, “Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0,” March 2005.), maps to the OpenID term user.

relying party (RP)

The OpenID definition:

A Web application that wants proof that the end user controls an Identifier.


The SAML glossary definition:

A system entity that decides to take an action based on information from another system entity.

SAML

The acronym SAML stands for "Security Assertion Markup Language". Depending upon context of use, it may mean..

(a) the (or a) Web Browser SSO Profile of SAML (aka a SAML Profile, and/or,

(b) the abstract SAML framework consisting of XML schemas for (abstract) security assertions and request-response protocol messages, and/or,

(c) the specification suite defining (a) and (b), as well as concrete profiles of (b).

SAML assertion

A distinct data object, defined in [OASIS.saml‑core‑2.0‑os] (Cantor, S., Kemp, J., Philpott, R., and E. Maler, “Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML) V2.0,” March 2005.), with carefully defined semantics, representing information concerning authentication events, attributes, and authorization information on behalf of a subject. In many SAML profiles, the subject is a user, although it does not have to be.

SAML binding

A SAML binding is a specification for how SAML assertions and/or protocol messages are conveyed in some particular concrete protocol [OASIS.saml‑bindings‑2.0‑os] (Cantor, S., Hirsch, F., Kemp, J., Philpott, R., and E. Maler, “Bindings for the OASIS Security Assertion Markup Language (SAML) V2.0,” March 2005.). E.g. in HTTP, as defined in the Web Browser SSO SAML profile in [OASIS.saml‑profiles‑2.0‑os] (Hughes, J., Cantor, S., Hodges, J., Hirsch, F., Mishra, P., Philpott, R., and E. Maler, “Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0,” March 2005.), or in SIP, as defined in [I‑D.ietf‑sip‑saml] (Tschofenig, H., Hodges, J., Peterson, J., Polk, J., and D. Sicker, “SIP SAML Profile and Binding,” March 2009.).

SAML profile

A SAML profile [OASIS.saml‑profiles‑2.0‑os] (Hughes, J., Cantor, S., Hodges, J., Hirsch, F., Mishra, P., Philpott, R., and E. Maler, “Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0,” March 2005.) is a concrete application of the abstract SAML "core" [OASIS.saml‑core‑2.0‑os] (Cantor, S., Kemp, J., Philpott, R., and E. Maler, “Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML) V2.0,” March 2005.) (which describes assertions and SAML protocol messages, in an abstract context), and likely also one or more SAML bindings, in a particular concrete context of use. Web browser-based SSO is an example of one such context of use. Expressing "identity" in SIP ("Session Initiation Protocol") is another example of a context of use [I‑D.ietf‑sip‑saml] (Tschofenig, H., Hodges, J., Peterson, J., Polk, J., and D. Sicker, “SIP SAML Profile and Binding,” March 2009.). Note that SAML profiles may be concocted by anyone, in any venue of choice. The latter work is being done in the IETF (www.ietf.org), for example.

Single Sign-On (SSO)

From a user's perspective, in the context of the specifications considered here, single sign-on encompasses the capability to authenticate with some IDP/OP and have that authentication honored by various relying parties.

user

Also known as "end user". In OpenID, the natural person wielding a user agent. In SAML profiles, this term typically maps to principal, subject, and/or web user [OASIS.saml‑glossary‑2.0‑os] (Hodges, J., Philpott, R., and E. Maler, “Glossary for the Security Assertion Markup Language (SAML) V2.0,” March 2005.).

User Agent (UA)

In the discussion context herein, the user agent is assumed to be a vanilla, unmodified, unextended HTTPv1.x-speaking web browser.

value

An OpenID term for the value associated with a particular key.

Web SSO

A more precise term than just "SSO", for what both the OpenID Authentication protocol and the SAML Web Browser SSO Profile provide. Note that realizing the notion of "Web Single Sign-On" in practice implies cross-domain delegation of authentication tasks.

4.  OpenID - SAML Technical Comparison

OpenID 1.X and 2.0, and SAML 2.0's Web Browser SSO Profile (and earlier versions thereof), offer functionality quite similar to each other. Obvious differentiators to a protocol designer are the message encodings, security mechanisms, and overall profile flows. Other differentiators include the layout and scope of the specification, trust and security aspects, OP/IDP discovery mechanisms, user-visible features such as identifier treatment, key agreement provisions, and security assertion schema and features.

Below, we touch on all these topics over several sections, beginning with an overview of the specification sets. Gory details of both SAML and OpenID are then examined in the following sections. The list of sections is as follows:

Section 4.1 (Specification Set Contents and Scope): Specification Set Contents and Scope (Specification Set Contents and Scope)

Section 4.2 (User Identifier Treatment): User Identifier Treatment (User Identifier Treatment)

Section 4.3 (Web Browser Single Sign-On): Web Browser Single Sign-On (Web Browser Single Sign-On)

Section 4.3.1 (Web Browser SSO with Association): Web Browser SSO with Association (Web Browser SSO with Association)

Section 4.3.2 (OpenID Authentication without Established Association): OpenID Authentication without Established Association (OpenID Authentication without Established Association)

Section 4.3.3 (Unsolicted Response): Unsolicted Response (Unsolicted Response)

Section 4.4 (Trust): Trust (Trust)

Section 4.5 (Security): Security (Security)

Section 4.6 (OP/IDP Discovery Mechanisms): OP/IDP Discovery Mechanisms (OP/IDP Discovery Mechanisms)

Section 4.7 (Key Agreement Approaches for OP/IDP - RP Communication): Key Agreement Approaches for OP/IDP - RP Communication (Key Agreement Approaches for OP/IDP - RP Communication)

Section 4.8 (Message Formats and Protocol Bindings): Message Formats and Protocol Bindings (Message Formats and Protocol Bindings)

Section 4.9 (Assertions): Assertions (Assertions)

4.1.  Specification Set Contents and Scope

Table 2 (Specification Set Contents and Scope): Specification Set Contents and Scope (Specification Set Contents and Scope), below, provides a high-level comparison of the OpenID and SAML specification sets.

4.2.  User Identifier Treatment

4.3.  Web Browser Single Sign-On

This section examines the message exchange patterns — also known as "message flows" or "protocol flows" — of OpenID authentication [OpenID.openid‑authentication‑2_0] (OpenID, “OpenID Authentication 2.0 - Final,” September 2007.) and SAML (Section 4.1 "Web Browser SSO Profile" of [OASIS.saml‑profiles‑2.0‑os] (Hughes, J., Cantor, S., Hodges, J., Hirsch, F., Mishra, P., Philpott, R., and E. Maler, “Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0,” March 2005.)). Initiation and discovery are not considered, as they are examined in following sections.

4.3.1.  Web Browser SSO with Association

Table 4 (Web Browser SSO with Association): Web Browser SSO with Association (Web Browser SSO with Association), below, illustrates web browser SSO where no "callbacks" from the RP to the OP/IDP are employed. As can be seen from Figure 1 (OpenID Authentication with an Established Association) and Figure 2 (SAML HTTP Redirect- or HTTP POST-based Web Broswer SSO Profile) therein, the flows for both OpenID authentication and SAML web browser SSO Profile are the same for this variation where the RP has already been introduced to the OP/IDP. In the OpenID case, this means that RP discovered (if necessary) and formed an association with the OP/IDP prior to beginning the flow in Figure 1 (OpenID Authentication with an Established Association). In SAML it means that the RP discovered the IDP before the flow (via some unspecified means, though possibly using the OpenID initiation and discovery mechanism [draft‑hodges‑saml‑openid‑profile‑02] (Hodges, J., “OpenID-SAML Lightweight Web Browser SSO Profile - Draft 02,” September 2007.)), or had been configured with the information (this is a subtle-but-key point in that SAML per se is not wedded to particular initiation and discovery mechanisms as discussed in Section 4.2 (User Identifier Treatment): User Identifier Treatment (User Identifier Treatment), above, and Section 4.6 (OP/IDP Discovery Mechanisms): OP/IDP Discovery Mechanisms (OP/IDP Discovery Mechanisms), below).

 +----+                  +----+               +--------+
 | UA |                  | RP |               | OP/IDP |
 +-+--+                  +-+--+               +---+----+
   |                       |                      |
   | 1. Authentication Req |                      |
   | and assoc_handle!=null|                      |
 +<- - - - - - - - - - - - |                      |
 . | (HTTP redirect resp)  |                      |
 . |                       |                      |
 +-------------------------+--------------------->|
   |  (HTTP GET or POST)   |                      |
   |                       |                      |
   |                       |                      |
   |                       |                      |
   | 2. OP/IDP authenticates user                 |
   | (methods vary, realization is out of scope)  |
   |<============================================>|
   |(Step 2 transparent to user if openid.mode is |
   | checkid_immediate)    |                      |
   |                       |                      |
   |                       |                      |
   |                       |                      |
   | 3. Authentication Resp|                      |
 +<- - - - - - - - - - - - - - - - - - - - - - - -|
 . | (HTTP redirect resp)  |                      |
 . |                       |                      |
 +------------------------>|                      |
   |  (HTTP GET or POST)   |                      |
   |                       |                      |
   |                       |                      |
   | 4. User is signed-on  |                      |
   | or some form of       |                      |
   | error msg is displayed|                      |
   |<----------------------|                      |
   |                       |                      |

 +----+                  +----+                +-----+
 | UA |                  | RP |                | IDP |
 +-+--+                  +-+--+                +--+--+
   |                       |                      |
   | 1. <AuthnRequest> msg |                      |
 +<- - - - - - - - - - - - |                      |
 . |   (redirect to IDP)   |                      |
 . |                       |                      |
 +-------------------------+--------------------->|
   |  (HTTP GET OR POST)   |                      |
   |                       |                      |
   |                       |                      |
   |                       |                      |
   | 2. Identity Provider authenticates user      |
   | (methods vary, realization is out of scope)  |
   |<============================================>|
   |(this step transparent to user if IsPassive=T)|
   |                       |                      |
   |                       |                      |
   | 3. <Response> message |                      |
 +<- - - - - - - - - - - - - - - - - - - - - - - -|
 . |   (redirect to SP)    |                      |
 . |                       |                      |
 +------------------------>|                      |
   |  (HTTP GET OR POST)   |                      |
   |                       |                      |
   |                       |                      |
   | 4. user is signed-on  |                      |
   | or some form of       |                      |
   | error msg is returned |                      |
   |<----------------------|                      |
   |                       |                      |

4.3.2.  OpenID Authentication without Established Association

Table 5 (Web Browser SSO without Association): Web Browser SSO without Association (Web Browser SSO without Association), below, illustrates web browser SSO where an association isn't established ahead of time (in OpenID's case) and in SAML's case the SAML Artifact Binding is employed. I.e. both of these examples employ "callbacks" from the RP to the OP/IDP, and thus illustrate that both SAML and OpenID encompass notions of so-called direct "backchannel" communication.

However, the flows differ in detail-level functionality, so this is a somewhat contrived comparison. In OpenID, the purpose of step 4 in Figure 3 (OpenID Authentication without Established Association) is to send the entire authentication response message, received from the OP/IDP via the UA in step 3, directly back to the OP/IDP in order for the OP/IDP to do signature verification on the message. In SAML, Figure 4 (SAML Web Broswer SSO Flow with Artifact Binding used on Reply from IDP), the purpose is to dereference the SAML artifact, received from the IDP via the UA in step 3, and obtain the associated SAML assertion. The RP remains responsible for verifying any signature on the message and/or any contained assertion(s). A SAML profile that returns SAML messages directly back to the OP/IDP could be devised. As of this writing, [draft‑hodges‑saml‑openid‑profile‑02] (Hodges, J., “OpenID-SAML Lightweight Web Browser SSO Profile - Draft 02,” September 2007.) does not (yet) do this.

 +----+                  +----+               +--------+
 | UA |                  | RP |               | OP/IDP |
 +-+--+                  +-+--+               +---+----+
   |                       |                      |
   | 1. Authentication Req |                      |
   | and assoc_handle==null|                      |
 +<- - - - - - - - - - - - |                      |
 . | (indirected via UA)   |                      |
 . |                       |                      |
 +-------------------------+--------------------->|
   |  (HTTP GET or POST)   |                      |
   |                       |                      |
   |                       |                      |
   |                       |                      |
   | 2. OP/IDP authenticates user                 |
   | (methods vary, realization is out of scope)  |
   |<============================================>|
   |(Step 2 transparent to user if openid.mode is |
   | checkid_immediate)    |                      |
   |                       |                      |
   |                       |                      |
   |                       |                      |
   | 3. Authentication Resp|                      |
 +<- - - - - - - - - - - - - - - - - - - - - - - -|
 . | (indirected via UA)   |                      |
 . |                       |                      |
 +------------------------>|                      |
   |  (HTTP GET or POST)   |                      |
   |                       |                      |
   |                       |                      |
   |                       | 4. check_authn plus  |
   |                       | resp params from (3) |
   |                       |--------------------->|
   |                       |                      |
   |                       |                      |
   |                       | 5. sig verif'n result|
   |                       | plus invalid_handle  |
   |                       |<---------------------|
   |                       |                      |
   | 6. User is signed-on  |                      |
   | or some form of       |                      |
   | error msg is displayed|                      |
   |<----------------------|                      |
   |                       |                      |
   |                       |                      |

 +----+                  +----+                +-----+
 | UA |                  | RP |                | IDP |
 +-+--+                  +-+--+                +--+--+
   |                       |                      |
   | 1. <AuthnRequest> msg |                      |
 +<- - - - - - - - - - - - |                      |
 . |   (redirect to IDP)   |                      |
 . |                       |                      |
 +-------------------------+--------------------->|
   |  (HTTP GET OR POST)   |                      |
   |                       |                      |
   |                       |                      |
   |                       |                      |
   | 2. Identity Provider identifies user         |
   | (methods vary, details not shown)            |
   |<============================================>|
   |(this step transparent to user if IsPassive=T)|
   |                       |                      |
   |                       |                      |
   | 3. <Response> message |                      |
 +<- - - - - - - - - - - - - - - - - - - - - - - -|
 . |   (redirect to SP)    |                      |
 . |                       |                      |
 +------------------------>|                      |
   | (HTTP GET w/artifact) |                      |
   |                       |                      |
   |                       |                      |
   |                       | 4. Resolve artifact  |
   |                       | query (w/artifact)   |
   |                       |--------------------->|
   |                       |                      |
   |                       |                      |
   |                       | 5. Response with SAML|
   |                       | assertion, or error  |
   |                       |<---------------------|
   |                       |                      |
   | 6. user is signed-on  |                      |
   | or some form of       |                      |
   | error msg is returned |                      |
   |<----------------------|                      |
   |                       |                      |
   |                       |                      |

4.3.3.  Unsolicted Response

The previous tables illustrated message exchange patterns that begin with the UA initially interacting with the RP. There are other cases where the UA may initially be interacting with the OP/IDP first, and then is redirected to the RP, whereupon an authenticated session is transparently (to the user) established. Such patterns are examined here.

SAML explicitly supports such a scenario—it is called an "unsolicited response" (see [OASIS.saml‑profiles‑2.0‑os] (Hughes, J., Cantor, S., Hodges, J., Hirsch, F., Mishra, P., Philpott, R., and E. Maler, “Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0,” March 2005.) Section 4.1.5).

OpenID more-or-less implicitly supports this pattern: the sixth paragraph of Section 10 in [OpenID.openid‑authentication‑2_0] (OpenID, “OpenID Authentication 2.0 - Final,” September 2007.), and the third paragraph of Section 11.2, both mention the term "unsolicited positive assertion", and specify behavior on the part of RPs upon receipt of them. But these are the only mentions of this sort of message exchange pattern in the specification.

 +----+                  +----+                +-----+
 | UA |                  | RP |                | IDP |
 +-+--+                  +-+--+                +--+--+
   |                       |                      |
   |                       |                      |
   | 1. User Agent interacts                      |
   | with IDP in some      |                      |
   | manner, typically in- |                      |
   | cluding HTTP-based in-|                      |
   | teractions            |                      |
   |<============================================>|
   |                       |                      |
   .                       .                      .
   .                       .                      .
   .                       .                      .
   |                       |                      |
   | 2. At some point IDP authenticates user      |
   | (methods vary, realization is out of scope)  |
   |<============================================>|
   |                       |                      |
   |                       |                      |
   .                       .                      .
   .    < Time may pass, various further inter-   .
   .      actions between UA and IDP may occur.   .
   .      Ultimately, the OP/IDP redirects the    .
   .      UA to the RP, per step 3... >           .
   .                       .                      .
   |                       |                      |
   |                       |                      |
   |                       |                      |
   | 3. <Response> message |                      |
   | issued by Identity    |                      |
   | Provider to Relying   |                      |
   | Party                 |                      |
 +<- - - - - - - - - - - - - - - - - - - - - - - -|
 . |   (redirect to SP)    |                      |
 . |                       |                      |
 +------------------------>|                      |
   |  (HTTP GET OR POST)   |                      |
   |                       |                      |
   |                       |                      |
   | 4. Based on the Iden- |                      |
   | tity Provider identify-                      |
   | ing (or not) the user,|                      |
   | the Relying Party     |                      |
   | either returns a re-  |                      |
   | source or an (HTTP)   |                      |
   | error (further re-    |                      |
   | directs may occur here)                      |
   |<----------------------|                      |
   |                       |                      |
   |                       |                      |

4.4.  Trust

4.5.  Security

4.6.  OP/IDP Discovery Mechanisms

                                                         +-------------+
                                                         |    User's   |
                                                         |   Website   |
                                                         |   ..or..    |
 +----+                  +----+               +--------+ |   an XRI    |
 | UA |                  | RP |               | OP/IDP | |  Authority  |
 +-+--+                  +-+--+               +---+----+ +-----+-------+
   |                       |                      |            |
   |                       |                      |            |
   | 1. User Agent access  |                      |            |
   | RP Site, typcially via|                      |            |
   | GET                   |                      |            |
   |---------------------->|                      |            |
   |                       |--[2. Do I have a     |            |
   |                       |  security context    |            |
   |                       |  for this UA? Hm,    |            |
   |                       |  no, so I'm going    |            |
   |                       |  to establish one..] |            |
   |                       |                      |            |
   | 3. RP returns a page  |                      |            |
   | with prompt for user  |                      |            |
   | to use to enter OpenID|                      |            |
   |<----------------------|                      |            |
   |                       |                      |            |
   | 4. UA typically POSTs |                      |            |
   | user's OpenId string  |                      |            |
   | to RP                 |                      |            |
   |---------------------->|                      |            |
   |                       |                      |            |
   |                       | 5. RP resolves OpenID|            |
   |                       | string via Yadis,    |            |
   |                       | XRI, or HTTP GET res-|            |
   |                       | olution, yielding URL|            |
   |                       | of user's OP/IDP     |            |
   |                       |<--------------------------------->|
   |                       |                      |            |
   |                       |                      |            |

4.7.  Key Agreement Approaches for OP/IDP - RP Communication

                                                         +-------------+
                                                         |    User's   |
                                                         |   Website   |
                                                         |   ..or..    |
 +----+                  +----+               +--------+ |   an XRI    |
 | UA |                  | RP |               | OP/IDP | |  Authority  |
 +-+--+                  +-+--+               +---+----+ +-----+-------+
   |                       |                      |            |
   |                       | 1. POST DH params,   |            |
   |                       | openid.mode =        |            |
   |                       |            associate |            |
   |                       |--------------------->|            |
   |                       |                      |            |
   |                       |                      |            |
   |                       | 2. OP/IDP returns    |            |
   |                       | shared secret and    |            |
   |                       | assoc_handle         |            |
   |                       |<---------------------|            |
   |                       |                      |            |
   |                       |                      |            |

4.8.  Message Formats and Protocol Bindings

Key     | Value
--------+---------------------------
mode    | error
error   | This is an example message

4.9.  Assertions

5.  Change Log

• Changes from -06 to -07a:
  1. Updated author's affiliation.
• Changes from -05 to -06:
  1. Precise list TBD (i.e. many and varied).
• Changes from -00 to -05:
  1. Essentially built out major content, built out references.

6. References

Appendix A.  Acknowledgments

Eve Maler and Paul Hoffman provided feedback on an earlier draft of this document. Susan Landau provided editorial comments on the executive summary of Draft 05, which we've incorproated into Draft 06.

Author's Address