TOC 
WhitepaperJ. Hodges
 PayPal, Inc.
 July 3, 2009


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







 TOC 

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.






 TOC 

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.






 TOC 

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).






 TOC 

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).






 TOC 

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).






 TOC 

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).






 TOC 

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).



TopicOpenIDSAML


Open Source Implementation Availability:



Open source OpenID implementations are available from several sources. For example, see: [OpenID.site] (, “OpenID Site,” .).



Open source SAML implementations are available from several sources. For example, see: [SAML.open.source.impls] (, “SAML Open Source Implementations,” .).



Interoperability Certification and Testing:



There is as yet no testing and certification program for assuring interoperability of implementations.



The SAML specification set includes a conformance specification, and there is at least one formal testing and interoperability certification program [SAML.conformance.testing] (, “SAML v2.0 Conformance Testing,” .).



Specification Style:



The OpenID Authentication specification specifically and concretely addresses Web Single Sign-On (Web SSO) use cases.

It is a single monolithic specification binding together the specification of message formats, protocol initiation, identity provider discovery protocol, user identifier definition, and SSO protocol definition.



The SAML specification set modularly specifies two explicitly extensible frameworks, one consisting of security assertions and the other an abstract request-response protocol. These frameworks are then profiled for various usage contexts, one of which is Web SSO, in separate "Profiles" specifications.

Other SAML usage contexts include web services security, and SIP identity -- where SAML is profiled in specifications being developed in venues other than OASIS.



Design Center:



The design center of OpenID Authentication is "decentralized" Web SSO, i.e. dynamic interaction between relying parties (RPs) and identity providers (OP/IDPs) without requiring any configuration, setup, prior metadata exchange, or non-vanilla browsers or browser extensions. It can be summarized operationally as "trust and accept all comers".

Additionally, it is tacitly intended to be implementable in the "application layer" — meaning, for example, that one should be able to craft simple blog application or wiki application plugins that an end user with the most basic unprivileged hosting account can deploy.

Finally, it is also intended to be as trivially implementable as possible. Hence no reliance on a message encoding language, strictly optional security requirements, e.g. message signing, etc. And also there is a minimum of tailorability, and the specification has everything needed for a fairly narrow range of Web SSO use cases baked directly into it, e.g. user identifier treatment and OP/IDP discovery.



SAML's original design center was that of providing a flexible, reusable, secure framework for Web SSO—and security token representation in general—that provides as strong security as possible given the use of HTTP, which is an inherently insecure protocol.

Additionally, since a large range of use cases were considered during the design processes of the three SAML versions, it is designed to be highly tailorable in order to meet a wide variety of use cases, and be employable in a variety of protocol contexts.

Thus the "core" SAML specification, aka "SAML itself", does not specify use case particulars such as IDP discovery, user identifier treatment, metadata exchange, or even underlying protocol (it can be layered onto or into essentially any other protocol). These particulars are left up to the specification of particular SAML "profiles" and/or "operational modes", which are designed to address specific (sets of) use cases. Although the SAML 2.0 specification set defines several SAML profiles (and associated protocol "bindings") "out of the box" , this does not preclude one from defining new ones, if one's use cases are not met by the existing ones.



End-user Privacy:



End-user privacy is not presently explicitly addressed in OpenID's specification.



End-user privacy is a first-order consideration in SAML 2.0's design.



Security Assertions:



OpenID security assertions are comprised of a set of key-value pairs, without explicit message-independent delineation. OpenID does not define an explicitly delineated security assertion object, thus limiting reusability in other protocol contexts.



SAML assertions are explicitly delineated data objects, with explicitly defined semantics, are explicitly extensible, and feature the capability to represent unambiguous claims about a subject.



Message Structure:



OpenID messages are comprised of simple sets of key-value (aka name-value) pairs, and thus representation of hierarchically-related data, and/or multi-valued keys, is not directly supported.



SAML assertions and protocol messages are explicitly extensible and tailorable, thus facilitating reuse in addressing new and different use cases, e.g. web services security.



Profilability:



OpenID as-specified is not explicitly profilable. See "Specification Style", above. The OpenID Authentication specification constitutes one concrete Web SSO "profile".



SAML is explicitly profilable. This is a consequence of both the design center, the specification set style, and the explicit use of an extensible encoding language (XML). Note that to conduct a "concrete" comparison of Web SSO capabilities and approach of SAML and OpenID, one needs to compare the "SAML Web Browser SSO Profile" with the OpenID specification, rather than comparing OpenID Authentication with SAML as a whole.



Extensibility:



OpenID is rudimentally extensible in that it allows for arbitrary additional key-value pairs to be embedded in messages along with an overall "namespace" key, serving to identify the extension's set of keys. Essentially, this allows one to use the HTTP-redirect-based message exchange (between the RP and the OP/IDP) machinery to convey arbitrary "messages" consisting of differing sets of key-value pairs. This can be used, for example, to effect attribute exchange.



SAML is explicitly extensible in several fashions, including the protocol message layer, the assertions themselves, and in terms of the design modularity — one can relatively easily craft new "bindings" and "profiles" if existing ones do not meet one's needs.



Trust and Security Considerations:



OpenID's implicit trust framework and security considerations are not thoroughly examined.



The SAML specification set includes a thorough analysis of the SAML profiles' security considerations.

The SAML trust framework depends upon the specific context of use, and thus the particular SAML profile being employed. This is examined for the SAML profiles included in the SAML specification set.


 Table 1: Summary Comparison Table of Technical Features 









 TOC 

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.







 TOC 

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)






 TOC 

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.



TopicOpenIDSAML
Overall Status:

At the time of writing this document, OpenID 2.0 was a draft specification set. There are claimed to be multiple alpha/beta implementations. OpenID 1.x [OpenID.openid‑authentication‑1_1] (Recordon, D. and B. Fitzpatrick, “OpenID Authentication 1.1,” January 2007.) is discussed in a table below.

SAML 2.0 [OASIS.saml‑2.0‑spec‑set] (OASIS, SSTC., Ed., “Security Assertion Markup Language (SAML) v2.0 Specification Set,” March 2005.) was approved as an OASIS Standard in March 2005. There are multiple certified interoperable implementations including at least two open source ones [OpenSSO] (java.net, “OpenSSO Project,” .) and [LASSO] (Entr'ouvert, “LASSO: Liberty Alliance Single Sign On,” .). SAML 1.x [OASIS.saml‑1.1‑spec‑set] (OASIS, SSTC., Ed., “Security Assertion Markup Language (SAML) v1.1 Specification Set,” August 2003.) is discussed in a table below.
Architectural approach: OpenID 2.0 specifies a concrete web SSO protocol, IDP discovery protocol, user identifier format, an extensibility mechanism (e.g. for attribute exchange), security considerations, and backwards compatibility in a single draft specification [OpenID.openid‑authentication‑2_0] (OpenID, “OpenID Authentication 2.0 - Final,” September 2007.).

SAML specifies an abstract extensible security assertion and an abstract extensible request-response protocol via XML schemas, in one specification, the 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.) (see also [OASIS.draft‑hodges‑HowToLearnSAML‑01] (Hodges, J., “How to Study and Learn SAML,” October 2006.)). SAML protocol bindings and concrete profiles are defined in further specifications in the specification set, as described below.



End-user Privacy:



End-user privacy is not presently explicitly addressed in OpenID's specification.



End-user privacy is an explicit first-order consideration in SAML v2.0's design. Several aspects of the design, e.g. establishment of pseudonyms between an IDP and an RP, one-time or transient identifiers, allowance for the claimed fact of a user consenting to certain operations, and expression for identifier policy constraints.

See also Section 4.5 of [OASIS.sstc‑saml‑tech‑overview‑2.0‑draft‑14] (Ragouzis, N., Hughes, J., Philpott, R., Maler, E., Madsen, J., and T. Scavo, “Security Assertion Markup Language (SAML) V2.0 Technical Overview v14,” September 2007.).

Profilability: The OpenID specification does not explicitly support profiling in the sense that the SAML specification set does. The OpenID specification set is concretely bound to HTTP and concretely defines a single web SSO profile. However, it does feature a simple extensibility mechanism, supporting definition of specific data query and response for name/value pairs. For example, three additional OpenID 2.0 draft specifications define attribute exchange [OpenID.openid‑attribute‑exchange‑1_0] (Hardt, D., Bufu, J., and J. Hoyt, “OpenID Attribute Exchange 1.0 - Final,” December 2007.), attribute types [OpenID.openid‑attribute‑types‑1_0‑02] (Hardt, D., “OpenID Attribute Types - Draft 02,” November 2006.), and attribute metadata (aka properties) [OpenID.identity‑attribute‑metadata‑1_0‑01] (Hardt, D., “Identity Attribute Metadata - Draft 01,” November 2006.) via this facility.

Concrete SAML profiles—one per each specific use-case, e.g. Vanilla web browser SSO, enhanced-client SSO, IDP discovery, Single Logout, name identifier management & mapping, assertion query/response, attribute query/response—are specified in the "SAML profiles" specification [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.). Note that SAML profiles are specified using, or "on top of" SAML bindings. A given profile may be designed to utilize more than one binding, e.g. the Web SSO Profile, or may be designed to use just one particular binding, e.g. as the SAML Lightweight Web Browser SSO (lSSO) Profile [I‑D.hodges‑saml‑lsso] (Hodges, J. and S. Cantor, “SAML 2.0 Lightweight Web Browser SSO Profile,” September 2007.) uses just the SAML "SimpleSign" binding [OASIS.sstc‑saml‑binding‑simplesign‑cd‑02] (Hodges, J. and S. Cantor, “SAML 2.0: HTTP POST "SimpleSign" Binding,” September 2007.) (see also [OASIS.draft‑hodges‑HowToLearnSAML‑01] (Hodges, J., “How to Study and Learn SAML,” October 2006.)). Further note that SAML was explicitly designed such that any number of profiles and bindings may be defined, in whatever venue makes sense for the definers (note that the lSSO draft is presently ensconced in the IETF venue).



Extensibility:



OpenID is rudimentally extensible in that it allows for arbitrary additional key-value pairs to be embedded in messages along with an overall "namespace" key, serving to identify the extension's set of keys. Essentially, this allows one to use the HTTP-redirect-based message exchange (between the RP and the OP/IDP) machinery to convey arbitrary "messages" consisting of differing sets of key-value pairs. This can be used, for example, to effect attribute exchange.



SAML is explicitly extensible in several fashions, including the protocol message layer, the assertions themselves, and in terms of the design modularity — one can relatively easily craft new "bindings" and "profiles" if existing ones do not meet one's needs.

Protocol bindings:

OpenID, in [OpenID.openid‑authentication‑2_0] (OpenID, “OpenID Authentication 2.0 - Final,” September 2007.), specifies two bindings to HTTP POST and HTTP GET (and requisite responses) messages. The former is intended for so-called "direct" interactions between system entities (i.e. not redirected), and the latter are explicitly defined as being redirected through the user agent. The specification does not provide guidance with respect to the creation of any other bindings.

Protocol bindings of abstract request-response protocol messages to concrete underlying protocols, e.g. HTTP and SOAP, are specified in the ""SAML Bindings" specification [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.). All of HTTP POST, HTTP redirect, SOAP-over-HTTP, reverse SOAP-over-HTTP ("PAOS"), SAML Artifact, and SAML URI bindings are specified.
Metadata support:

OpenID relies on XRDS documents, which can be found by resolving [OASIS.xri‑resolution‑v2.0‑wd‑11] (Wachob, G., Ed., Reed, D., Ed., Chasen, L., Ed., Tan, W., Ed., and S. Churchill, Ed., “Extensible Resource Identifier (XRI) Resolution Version 2.0,” November 2007.) an XRI [OASIS.xri‑syntax‑V2.0‑cs] (Reed, D., Ed., McAlpin, D., Ed., Davis, P., Sakimura, N., Lindelsee, M., and G. Wachob, “Extensible Resource Identifier (XRI) Syntax V2.0,” November 2005.), for what is essentially "service metadata" in SAML terminology.

Additionally, OpenID relies upon establishing so-called "associations" for exchanging keying material between an RP and an OP/IDP. See 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) for more info.

SAML metadata, e.g. for identity providers and relying parties (aka service providers), are defined in the "SAML metadata" specification [OASIS.saml‑metadata‑2.0‑os] (Cantor, S., Moreh, J., Philpott, R., and E. Maler, “Metadata for the Security Assertion Markup Language (SAML) V2.0,” March 2005.). See also 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) for information about so-called "dynamic/distributed metadata exchange".

Conformance criteria: The OpenID specification set does not explicitly define conformance criteria at this time. Rather it is implicit in the specification(s).

Conformance criteria and the specification roadmap are given in the "SAML conformance" specification [OASIS.saml‑conformance‑2.0‑os] (Mishra, P., Philpott, R., and E. Maler, “Conformance Requirements for the Security Assertion Markup Language (SAML) V2.0,” March 2005.).

Security considerations:

See also: Section 4.5 (Security): Security (Security)


Security considerations are nominally discussed in [OpenID.openid‑authentication‑2_0] (OpenID, “OpenID Authentication 2.0 - Final,” September 2007.). An incomplete security profiles draft spec, [OpenID.openid‑authentication‑security‑profiles‑01] (Granqvist, H., “OpenID Authentication Security Profiles - Draft 1,” September 2006.), by an individual contributor, remains at version -01, from Sep-2006.

Security considerations are presented and examined in the "SAML sec considerations" specification [OASIS.saml‑sec‑consider‑2.0‑os] (Hirsch, F., Philpott, R., and E. Maler, “Security and Privacy Considerations for the OASIS Security Markup Language (SAML) V2.0,” March 2005.).
Authentication context support: The draft OpenID Assertion Quality specification [OpenID.openid‑assertion‑quality‑extension‑1_0‑03] (Recordon, D., Glasser, A., and J. Madsen, “OpenID Assertion Quality Extension 1.0 - Draft 3,” December 2006.) is an OpenID extension which conveys simple key-value pair information with respect to an authentication event.

Meta-information regarding the particulars of authentication events is specified in the "SAML authentication context" specification [OASIS.saml‑authn‑context‑2.0‑os] (Kemp, J., Cantor, S., Mishra, P., Philpott, R., and E. Maler, “Authentication Context for the Security Assertion Markup Language (SAML) V2.0,” March 2005.). SAML Authentication Context information is expressed in XML, based on an extensible XML schema, and thus can easily represent complex, hierarchical or mesh relationships. Potential deploying organizations, such as mobile phone network operators, and financial institutions, specifically contributed to crafting this specification.

Terminology: The OpenID Authentication specification includes a brief terminology section defining key terms.

SAML terminology is coalesced and documented in the "SAML Glossary" [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.) (also available in HTML on the Web: SAML-Glossary-in-HTML)


 Table 2: Specification Set Contents and Scope 









 TOC 

4.2.  User Identifier Treatment



OpenIDSAML


OpenID presumes and specifies that user identifiers, termed OpenID identifiers herein, are necessarily directly dereferencable in order to contact the user's OP/IDP using HTTP or HTTP/TLS — thus the identifiers are specified to be of "HTTP:" or "https:" URI schemes [RFC2616] (Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” June 1999.) [RFC3986] (Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.).

Note that this leads directly to the topic of "OP/IDP discovery", addressed below in Section 4.6 (OP/IDP Discovery Mechanisms): OP/IDP Discovery Mechanisms (OP/IDP Discovery Mechanisms).


SAML does not specify, in the OASIS-issued specification sets themselves, for any version of SAML, the nature of the user-wieldable end-user identifiers. It is left as an exercise for profiliers, and/or implementors, and/or deployers.

This of course means that any particular profile and/or application of SAML may define any particular user identifier scheme that is appropriate for the use cases at hand.

And it also means that whether or not user identifiers play a role in OP/IDP discovery may be defined in the context of a SAML profile.

Also note that SAML provides for various identifiers to be used at the protocol level, e.g. "Persistent Identifiers" which are non-public, pair-wise pseudonyms whose purpose is to aid in preventing the discovery of the subject's identity or activities (see Section 8.3.7 of [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.)).

 Table 3: Identifier Treatment 









 TOC 

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.






 TOC 

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).



OpenIDSAML





 +----+                  +----+               +--------+
 | 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|                      |
   |<----------------------|                      |
   |                       |                      |

 Figure 1: OpenID Authentication with an Established Association 








 +----+                  +----+                +-----+
 | 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 |                      |
   |<----------------------|                      |
   |                       |                      |

 Figure 2: SAML HTTP Redirect- or HTTP POST-based Web Broswer SSO Profile 




 Table 4: Web Browser SSO with Association 









 TOC 

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.



OpenIDSAML



 +----+                  +----+               +--------+
 | 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|                      |
   |<----------------------|                      |
   |                       |                      |
   |                       |                      |

 Figure 3: OpenID Authentication without Established Association 




 +----+                  +----+                +-----+
 | 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 |                      |
   |<----------------------|                      |
   |                       |                      |
   |                       |                      |

 Figure 4: SAML Web Broswer SSO Flow with Artifact Binding used on Reply from IDP 


 Table 5: Web Browser SSO without Association 









 TOC 

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)                      |
   |<----------------------|                      |
   |                       |                      |
   |                       |                      |

 Figure 5: SAML Web Browser SSO Profile "Unsolicited Response" 






 TOC 

4.4.  Trust



TopicOpenIDSAML
Overall:

[OpenID.openid‑authentication‑2_0] (OpenID, “OpenID Authentication 2.0 - Final,” September 2007.) leaves an OP/IDP free to convey information with respect to a user to any entity requesting it, e.g. to any RP via a response to an OpenID authentication request made by any such RP.

In other words, the default OpenID trust model implicit in the spec is to "trust any and all", by default, i.e. "laissez-faire trust".

It's important to note that this notion of trust is hard-wired into OpenID's very concrete design.



The SAML v2.0 specification set [OASIS.saml‑2.0‑spec‑set] (OASIS, SSTC., Ed., “Security Assertion Markup Language (SAML) v2.0 Specification Set,” March 2005.) and the v1.x specification set [OASIS.saml‑1.1‑spec‑set] (OASIS, SSTC., Ed., “Security Assertion Markup Language (SAML) v1.1 Specification Set,” August 2003.) admonish and constrain, via SHOULDs and MUSTs, all entities to "do the right thing" with respect to security, whether an interaction is a run of the AuthnRequest protocol, or AttributeQuery protocol, or any of the other SAML-specified protocol profiles.

The spirit of these requirements is that the entities will not inappropriately convey information to arbitrary entities, and also to aid in avoiding man-in-the-middle (MITM) attacks. See lines 532-536 in section "4.1.4.1 <AuthnRequest> Usage" 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.), and more generally, [OASIS.saml‑sec‑consider‑2.0‑os] (Hirsch, F., Philpott, R., and E. Maler, “Security and Privacy Considerations for the OASIS Security Markup Language (SAML) V2.0,” March 2005.) for specific treatment of such attacks.

Of Laissez-faire Trust and Phishing:

Additionally, OpenID is predicated on having users supply their OpenID Identifier, which is essentially a pointer to their OP/IDP (or a pointer-to-a-pointer), to any entity they interact with on the Internet. In other words, the protocol design explicitly demands that they trust any relying party with an interactively user-supplied pointer to their OP/IDP.

This practice, as presently specified, is an invitation to "be phished". See [Blog.BenLaurie.Links.OpenID.Phish] (Laurie, B., “OpenID: Phishing Heaven,” January 2007.) and [Blog.BenLaurie.Links.OpenID.Phish2] (Laurie, B., “OpenID and Phishing: Episode II,” January 2007.).

See also Section 4.6 (OP/IDP Discovery Mechanisms): OP/IDP Discovery Mechanisms (OP/IDP Discovery Mechanisms), and Section 4.5 (Security): Security (Security) below.

At the time of writing this, there had been a fairly in-depth discussion of these issues on the OpenID mailing lists, but no solutions had made it into the OpenID 2.0 specification [OpenID.openid‑authentication‑2_0] (OpenID, “OpenID Authentication 2.0 - Final,” September 2007.). Note that the OpenID 1.1 specification[OpenID.openid‑authentication‑1_1] (Recordon, D. and B. Fitzpatrick, “OpenID Authentication 1.1,” January 2007.) is for the most part what is deployed at this time, and it is in a finished, frozen state -- and has this phishing vulnerability.



The SAML specification sets are silent with respect to user identifiers. Of course, this means that OpenID Identifiers and the associated OP/IDP discovery mechanism (as well as association mechanism) could be used with a SAML-based Web SSO profile (either the existing one 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 new ones such as [draft‑hodges‑saml‑openid‑profile‑02] (Hodges, J., “OpenID-SAML Lightweight Web Browser SSO Profile - Draft 02,” September 2007.) ). If this is done, then such a SAML profile would have security issues, related to the OpenID Identifier and its wielding by end users, similar to those that the OpenID specifications have.

Cursory trust analysis:

OpenID (@@TODO: note: more work to do here, using tools such as those discussed in [IEEE.YaKlBe1993] (Yahalom, R., Klein, R., and T. Beth, “Trust relationships in secure systems-a distributed authentication perspective,” 1993.)):

  • RP relies on UA to supply an OpenID Identifier, which upon dereferencing (via DNS), leads to a legitimate OP/IDP serving the UA's user, via either "<link href=...>" or i-name/XRDS resolution. RP thus also relies upon DNS, unless the supplied OpenID Identifier uses an IP address rather than a FQDN.


  • UA, and thus the user, relies on the RP to be legitimate, for the RP to legitimately dereference the user's supplied OpenID Identifier, to legitimately discover the OP/IDP, and to legitimately send an authentication request to the discovered OP/IDP.


  • User relies upon OP/IDP to be legitimate and to not surreptitiously impersonate user at RPs, or to facilitate others in doing so.


  • User relies upon UA to legitimately send appropriate requests (typically HTTP GETs and/or POSTs) to RP and OP/IDP, and to render information returned from both OP/IDP and RP, as well as faithfully relay messages between RP and OP/IDP.





(@@TODO

although it's reasonable to note that if one is using a SAML profile that essentially emulates OpenID Authentication, e.g. [draft‑hodges‑saml‑openid‑profile‑02] (Hodges, J., “OpenID-SAML Lightweight Web Browser SSO Profile - Draft 02,” September 2007.), then the trust analysis of said profile will be quite close to that of OpenID)

 Table 6: Trust 









 TOC 

4.5.  Security



TopicOpenIDSAML
Overall: In the OpenID specs [OpenID.openid‑authentication‑2_0] (OpenID, “OpenID Authentication 2.0 - Final,” September 2007.) [OpenID.openid‑authentication‑1_1] (Recordon, D. and B. Fitzpatrick, “OpenID Authentication 1.1,” January 2007.), there are security provisions in terms of key establishment, message signature and verification mechanisms, and use of SSL/TLS-protected channels.

However, employment of these security provisions is entirely optional on the part of implementors and/or deployers.



In the SAML specification sets, there are robust security provisions based on explicit stipulations in profiles, the bindings profiles employ, as well as in the design of the SAML assertion semantics. Message signatures are either xmldsig-based, or SimpleSign-based [OASIS.sstc‑saml‑binding‑simplesign‑cd‑02] (Hodges, J. and S. Cantor, “SAML 2.0: HTTP POST "SimpleSign" Binding,” September 2007.).

Because security provisions, and whether their employment is required, vary on a per-binding and per-profile basis, as well as profile use being denoted at runtime, and also due to robust conformance requirements along with denoted "operational modes", interoperability and security is enhanced.

Security review:

Security reviewed by VeriSign at least. Hans Granqvist sent messages to OpenID list cataloging findings, and also as a result concocted this draft doc: [OpenID.openid‑authentication‑security‑profiles‑01] (Granqvist, H., “OpenID Authentication Security Profiles - Draft 1,” September 2006.).

As yet, this is only a draft document -- it hasn't been "adopted" by the OpenID community in an "official" manner. However, the basic notion of there being various "protocol variants" which "may or may not directly affect the security" of a run of the protocol are taken from the above security profiles draft doc and incorporated in in section 15.6 of [OpenID.openid‑authentication‑2_0] (OpenID, “OpenID Authentication 2.0 - Final,” September 2007.).



SAML's security properties have been reviewed both in academia, corporate contexts, and the public sector. The various findings have been rolled into subsequent versions, culminating in SAML 2.0.

In the SAML specification sets, security considerations are thoroughly examined and presented, e.g. in [OASIS.saml‑sec‑consider‑2.0‑os] (Hirsch, F., Philpott, R., and E. Maler, “Security and Privacy Considerations for the OASIS Security Markup Language (SAML) V2.0,” March 2005.) and [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.) and [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.).

Also, security considerations were taken into account when the "Operational Modes" given in [OASIS.saml‑conformance‑2.0‑os] (Mishra, P., Philpott, R., and E. Maler, “Conformance Requirements for the Security Assertion Markup Language (SAML) V2.0,” March 2005.) were defined. This conformance specification details the features SAML implementations must have in order to honestly claim conformance to the SAML 2.0 specification set.

Phishing:

Because OpenID, as a complete concrete SSO system, is predicated directly upon the notion of a user interactively supplying RPs with essentially a pointer to their OP/IDP, it is inherently "phishable", as noted above in Section 4.4 (Trust): Trust (Trust).

Because the "associate" operational mode is based on anonymous Diffie-Hellman key agreement [RFC2631] (Rescorla, E., “Diffie-Hellman Key Agreement Method,” June 1999.), one does not know (except via IP/MAC addresses and/or DNS name) who one is actually executing the key agreement with. If it is a man-in-the-middle (MITM) attacker you may have no indication that you're being phished. Because of the concrete, non-profilable fashion in which the OpenID specifications are fashioned, it would take a non-trivial specification revision in order to add, say, (optional) PKI-based message signing.



Because SAML itself (i.e. the SAML "core", aka the SAML "framework", nor the SAML profiles included in the SAML specification sets [OASIS.saml‑2.0‑spec‑set] (OASIS, SSTC., Ed., “Security Assertion Markup Language (SAML) v2.0 Specification Set,” March 2005.) [OASIS.saml‑1.1‑spec‑set] (OASIS, SSTC., Ed., “Security Assertion Markup Language (SAML) v1.1 Specification Set,” August 2003.), is predicated on users supplying RPs pointers to their IDPs, SAML's Web Browser SSO Profile is not inherently phishable in the same manner that OpenID is.

However, this depends upon the particular implementation and deployment practices employed. For example, a SAML Web Browser SSO Profile implementation that uses the OpenID initiation and discovery techniques along with OpenID-style identifiers would be phishable in essentially the same fashion as OpenID is.

Note though, that since SAML can employ public-key-based message signatures, it has additional tools at the disposal of implementors and deployers to use to combat phishing (as compared to OpenID).

Message Signatures:

In general, OpenID does not specify application of digital signatures to its messages. The messages that are signed are, in [OpenID.openid‑authentication‑2_0] (OpenID, “OpenID Authentication 2.0 - Final,” September 2007.), the "indirect response" messages returning "positive assertions". In [OpenID.openid‑authentication‑1_1] (Recordon, D. and B. Fitzpatrick, “OpenID Authentication 1.1,” January 2007.) it is the corresponding messages.

Note that the "check_authentication" messages that are sent "directly" by the RP to the OP for verification are not themselves signed. This is a subtle point because although they convey a signed message for verification by the OP, the surrounding message itself is not signed.

Using unsigned messages means that any such messages may be undetectably modified by an active attacker, i.e. a "man-in-the-middle" (MITM). Such an attacker could be an entity on the communication paths themselves and/or the user agent (which acts as an intermediary and is a de-facto MITM, one we typically assume is not hostile) and/or other malware on the user's system.

OpenID's defense against such attacks is ostensibly having the implementor provide for, and the deployer employ, use of TLS/SSL for all interactions between RP, UA, and OP. This is noted in the security considerations section of [OpenID.openid‑authentication‑2_0] (OpenID, “OpenID Authentication 2.0 - Final,” September 2007.).

However, even this does not address the vulnerability of the user's UA and system in general, since messages traversing TLS/SSL channels are handled "in the clear" while within the bounds of the UA intermediary. Only actual signing of the messages themselves, as an inherent part of the messages, addresses this in an endpoint-to-endpoint fashion.



SAML provides for digital signatures to be applied to all messages, and additionally separately to SAML assertions themselves [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.). This flexibility is accomplished modularly in the sense that the specification of SAML bindings [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.) typically address application of message signatures, and the 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.) that build on top of SAML bindings employ such SAML binding features as needed to address their use cases [OASIS.draft‑hodges‑HowToLearnSAML‑01] (Hodges, J., “How to Study and Learn SAML,” October 2006.) and the security considerations thereof. Additionally, SAML profiles specify whether SAML assertions themselves must or should be signed, as appropriate (per security considerations stipulated in the specification set).

The SAML specifications set also appropriately stipulates use of TLS/SSL in both profiles and bindings, which in combination with appropriate message signing, provides a full-featured security context on a per-use-case basis.

Subject confirmation:

Neither [OpenID.openid‑authentication‑2_0] (OpenID, “OpenID Authentication 2.0 - Final,” September 2007.) nor [OpenID.openid‑authentication‑1_1] (Recordon, D. and B. Fitzpatrick, “OpenID Authentication 1.1,” January 2007.) at this time provide a means for an OP to insert "subject confirmation" information, e.g. material cryptographically attesting to the UA wielder being the entity who authenticated with the OP/IDP.



SAML's assertion design [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.) explicitly features the notion of subject confirmation, which is useful for applying SAML assertions in a host of contexts besides just Web SSO — e.g. securing web services interactions, multi-tier delegated interactions, etc.

Profilability of security features:

Since the OpenID authentication protocol is a concrete profile, and doesn't feature a formalized notion of a "security assertion" (aka "security token"), it will prove difficult to reuse portions of the OpenID authentication protocol and/or its security mechanisms in other contexts (the OpenID Identifier is a presumably reusable notion, but it isn't a security feature).



SAML's security features are designed to be modularly reusable since they are largely built into the underlying formal schemas of both SAML assertions and SAML messages.

Thus designers, implementors, and deployers of both existing (i.e. present in the SAML specification set) and new SAML profiles have a rich set of security features at their disposal to use to address the particular security considerations of the use cases at hand.


 Table 7: Security 









 TOC 

4.6.  OP/IDP Discovery Mechanisms



OpenIDSAML


OP/IDP discovery is concretely specified in the OpenID specification. It is based directly on the notion that OpenID Identifiers are normalizable into either URIs [RFC3986] (Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.) or XRIs [OASIS.xri‑syntax‑V2.0‑cs] (Reed, D., Ed., McAlpin, D., Ed., Davis, P., Sakimura, N., Lindelsee, M., and G. Wachob, “Extensible Resource Identifier (XRI) Syntax V2.0,” November 2005.). These in turn are dereferencable into either an XRDS document [Yadis] (Miller, J., “Yadis Specification 1.0,” .) [OASIS.xri‑resolution‑v2.0‑wd‑11] (Wachob, G., Ed., Reed, D., Ed., Chasen, L., Ed., Tan, W., Ed., and S. Churchill, Ed., “Extensible Resource Identifier (XRI) Resolution Version 2.0,” November 2007.) which in turn points to the user's OP/IDP (via a <Service> element), or a web page containing an HTML <Link> tag pointing to the user's OP/IDP. See Figure 6 (Protocol Flow: OpenID "Initiation and Discovery").

See [OpenID.openid‑authentication‑2_0] (OpenID, “OpenID Authentication 2.0 - Final,” September 2007.) Section 7.



The SAML specification sets themselves are neutral with respect to any particular IDP discovery mechanism. The "Common Domain Cookie" (CDC) approach is offered as one possible, optional, approach. However, none of the SAML profiles specified in the SAML specification sets mandate use of the CDC approach. Though, the SAML conformance specification [OASIS.saml‑conformance‑2.0‑os] (Mishra, P., Philpott, R., and E. Maler, “Conformance Requirements for the Security Assertion Markup Language (SAML) V2.0,” March 2005.) mandates that any implementation of the "IDP" and "IDP Lite" operational modes must at least implement CDC in order to legitimately claim conformance to those operational modes. Note that this does not mean that any SAML deployer must, or should, actually employ CDC. Rather, they simply "may".

NOTE: A SAML profile could define a particular IDP discovery approach, for example essentially the same one that OpenID employs, and in fact one has recently been drafted:

[OASIS.sstc‑saml‑idp‑discovery‑cd‑02] (Widdowson, R. and S. Cantor, “Identity Provider Discovery Service Protocol and Profile,” September 2007.) .


 Table 8: 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     |            |
   |                       |<--------------------------------->|
   |                       |                      |            |
   |                       |                      |            |


 Figure 6: Protocol Flow: OpenID "Initiation and Discovery" 






 TOC 

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



OpenIDSAML


See [OpenID.openid‑authentication‑2_0] (OpenID, “OpenID Authentication 2.0 - Final,” September 2007.) Section 8 "Establishing Associations". See also Figure 7 (Protocol Flow: OpenID "Associate" Operational Mode).

"Establishing an association" between an SP/RP and an OP/IDP is, in other words, executing a session key agreement protocol between said parties.

The "association establishment sub-protocol" is based directly on Diffie-Hellman (DH) key exchange [RFC2631] (Rescorla, E., “Diffie-Hellman Key Agreement Method,” June 1999.), and is actively performed between the RP and the OP/IDP.

It yields a symmetric session key, which is subsequently used to sign messages exchanged between the parties.

This eases deployment- and run-time considerations in that no mutual beforehand configuration is required between a relying party (RP) and an OP/IDP in order to exchange mutually-verifiable signed messages.


None of the SAML profiles specified in the SAML specification sets specifies an active key agreement protocol or protocol steps.

Rather, SAML uses its metadata facility to distribute keying material between IDPs and SPs [OASIS.saml‑metadata‑2.0‑os] (Cantor, S., Moreh, J., Philpott, R., and E. Maler, “Metadata for the Security Assertion Markup Language (SAML) V2.0,” March 2005.) (see 2.4.1.1 Element <KeyDescriptor>).

At this time, there is no standardized (e.g. via OASIS SSTC [OASIS.SSTC] (, “OASIS Security Services Technical Committee (SAML),” .)) approach for effecting automated SAML metadata exchange at runtime. However, various parties are developing exactly this capability and intend on bringing their work to the SSTC for standardization in 2008. See:

[I2.DistribDynamSaml] (Internet2, “Distributed Dynamic SAML,” Octover 2007.)

[I2.DistribSamlMetadataMgmt] (Stockholms Universitet, “A profile for distributed SAML metadata management,” October 2007.)

[PingID.DynamicFederation] (Ping Identity, “Dynamic Federation. A Game Changer?,” November 2007.)

[PingID.DynamicFederationDetails] (Ping Identity, “Dynamic Federation - Under the Covers,” November 2007.)

[IIW.DynamicFederationSession] (, “IIW2007b Dynamic Federation Session,” December 2007.)


 Table 9: 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         |            |
   |                       |<---------------------|            |
   |                       |                      |            |
   |                       |                      |            |

 Figure 7: Protocol Flow: OpenID "Associate" Operational Mode 






 TOC 

4.8.  Message Formats and Protocol Bindings



TopicOpenIDSAML
Overall message formats:

OpenID Authentication protocol messages are comprised of sets of key-value pairs, e.g this figure from [OpenID.openid‑authentication‑2_0] (OpenID, “OpenID Authentication 2.0 - Final,” September 2007.) section 4...


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

...which are encoded into HTTP messages, in varying fashions dependent upon whether the underlying HTTP message is an HTTP request or response, and also whether (if it is a request) the HTTP method being employed is GET or POST. These variations are delineated in [OpenID.openid‑authentication‑2_0] (OpenID, “OpenID Authentication 2.0 - Final,” September 2007.) by the notions of "Data Formats" (section 4) and "Communication Types" (section 5).



Abstract SAML Messages are 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.), are expressed in 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 are structured according to message definitions expressed in XML Schema [W3C.REC‑xmlschema‑1] (Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, “XML Schema Part 1: Structures,” May 2001.). This is regardless of the particular underlying protocol messages they are ultimately bound to.

SAML assertions and protocol messages are comprised of many various "parameters" — essentially corresponding to the OpenID notion of keys — and are configurable (i.e. various parameters are optional), thus explicitly extensible.

Bindings to underlying protocols:

OpenID's "communication types" are essentially what is referred to in SAML as "Protocol Bindings" — i.e. they describe how to map a message at one layer to an underlying layer's message structure. The underlying layer here, as well as in SAML's web browser SSO profile, is HTTP.

The "Data Formats" define how to encode the sets of key-value pairs, that comprise OpenID messages, into HTTP messages in various ways.



SAML messages are bound to underlying protocol messages, e.g. HTTP [RFC2616] (Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” June 1999.) or SOAP [W3C.soap11] (Box, D., Ehnebuske, D., Kakivaya, G., Layman, A., Mendelsohn, N., Nielsen, H., Thatte, S., and D. Winer, “Simple Object Access Protocol (SOAP) 1.1,” May 2000.), for conveyance (per the particular SAML binding(s) [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.) being employed) by the the particular SAML profile being executed [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.).

Server-to-server communication:

Requests of the "direct" communication type ([OpenID.openid‑authentication‑2_0] (OpenID, “OpenID Authentication 2.0 - Final,” September 2007.) section 5.1), sometimes referred to as "back channel", which are used by RPs to make requests directly to OP/IDPs (i.e. without using a user agent as an intermediary), are constructed using only the HTTP POST method, with the key-value pairs FORM-encoded per section 4.1.2.



[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.) defines explicit (abstract) request and response messages, which can be tailored for various purposes, e.g. facilitating RPs to query OP/IDPs. [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.) specifies how to bind these messages to SOAP.

Note: additionally, these messages may be conveyed by so-called "indirect" means (i.e. routed via the user agent) — other bindings may be designed.

Several profiles 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.) employ, or optionally employ, the SAML SOAP binding.

"Indirect" communication:

Requests of "indirect" communication type (section 5.2), which are used by RPs to make requests to OP/IDPs indirectly through user agents, may be either HTTP GET- or POST-based. Note however that in this communication type, a RP instigates its OpenID "request" to an OP/IDP by returning an HTTP Response message to the user agent (in response to some original request initiated by the user agent) containing the OpenID request message (which is a set of key-value pairs). Then the user agent is caused to send an HTTP Request to the OP/IDP containing the OpenID message. It is this latter HTTP request from the user agent to the OP/IDP that may be constructed using either HTTP GET or POST methods. See step 1 in Figure 1 (OpenID Authentication with an Established Association), below.

Note: [OpenID.openid‑authentication‑2_0] (OpenID, “OpenID Authentication 2.0 - Final,” September 2007.) appears to be vague about whether both GET- and POST-based bindings (to borrow SAML terminology) are supported for indirect communication from the OP/IDP back to the RP, see step 3 in Figure 1 (OpenID Authentication with an Established Association), for example. Related, it isn't explicitly clear in the specification whether one can compose GET- and POST-based bindings in the same interaction, e.g. using GET for one step and POST for another.



SAML explicitly defines both HTTP GET- or POST-based bindings in [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.). The former is named "HTTP Redirect Binding", and the latter is the "HTTP POST Binding". These bindings are composable in that they formally define just one direction of communication (e.g. from the RP to the OP/IDP or the reverse), and as used by the Web Browser SSO 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.), either one may be used for either of the OP/IDP <--> RP communication steps.

Indirect communication - HTTP redirect:

With the GET-based approach, which is referred to as "HTTP Redirect", the OpenID message is x-www-urlencoded into the query string of the URL placed into the Location field of an 302, 303, or 307 HTTP Redirect Response message. This URL (and query string) is then automatically used by the user agent as the HTTP Request-Line's GET method's Request-URI ([RFC2616] (Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” June 1999.) section 5.1) of the subsequent HTTP Request. See section 5.2.1 of [OpenID.openid‑authentication‑2_0] (OpenID, “OpenID Authentication 2.0 - Final,” September 2007.)

This approach is functionally equivalent to the SAML HTTP Redirect Binding.

[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.) defines the "HTTP Redirect Binding" which is functionally equivalent to the OpenID HTTP Redirect.
Indirect communication - HTTP POST:

With the POST-based approach, referred to as "HTML FORM Redirection", the OpenID message is FORM-encoded into an HTTP Response message containing an HTML page where the <FORM> element's "action" attribute value contains the target URL of the OP/IDP (aka "the receiver"). The FORM is subsequently submitted either by the user clicking on the Submit button, or submission is automated via JavaScript/ECMAscript. See section 5.2.2 of [OpenID.openid‑authentication‑2_0] (OpenID, “OpenID Authentication 2.0 - Final,” September 2007.).

This approach is functionally equivalent to the SAML HTTP POST binding.

[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.) defines the "HTTP POST Binding" which is functionally equivalent to the OpenID HTML FORM Redirection.
Authentication request messages:

The OpenID "authentication request" simply conveys the claimed OpenID Identifier, or, that as well as an OP-local Identifier, a "return to" URL, and an association handle, if any, plus a few other housekeeping parameters.



The SAML 2.0 <AuthnRequest> protocol [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 is conveyed using any of the SAML bindings mentioned above) can convey a rich set of information between requester and the OP/IDP.

[@@TODO: a detailed comparison between the two sets of parameters will be done in a later version of this document]

The SAML 1.x form of AuthnRequest similar to OpenID, although not as full-featured, in that it only conveys the URI of the target resource at the RP.


 Table 10: Message Formats and Protocol Bindings 









 TOC 

4.9.  Assertions



TopicOpenIDSAML


Security Assertions Formats

as-defined in OpenID authn, OpenID Assertions..

  • Mix protocol messaging parameters amongst security assertion items.

  • Security assertions are not clearly delineated and self-contained objects.

  • The packaging of security token is determined by messaging means:

    • indirect-get-redirect uses URL encoding

    • indirect-form-redirect uses form encoding

  • Security assertions are not designed to convey keying material, hence the equivalent of SAML's "holder of key" confirmation method is impossible to implement (for at least a couple of reasons).

  • Extensible in ad-hoc fashion.

@@TODO: there's a fair bit more to note here.



  • Explicit schema design for assertions. Assertions are explicitly delineated, self-contained data objects.

  • Encoded in XML. Supports hierarchical and linear representation.

  • Assertions can convey a variety of information about the subject.

  • Supports inclusion of keying material.

  • Explicitly crafted security semantics for all elements.

  • Extensibility explicitly supported.

@@TODO: there's a fair bit more to note here.


 Table 11: Assertions 






 TOC 

5.  Change Log






 TOC 

6. References

[Blog.BenLaurie.Links.OpenID.Phish] Laurie, B., “OpenID: Phishing Heaven,” Links - Ben Laurie Blathering (blog) www.links.org, January 2007.
[Blog.BenLaurie.Links.OpenID.Phish2] Laurie, B., “OpenID and Phishing: Episode II,” Links - Ben Laurie Blathering (blog) www.links.org, January 2007.
[I-D.hodges-saml-lsso] Hodges, J. and S. Cantor, “SAML 2.0 Lightweight Web Browser SSO Profile,” Internet-Draft (expired) draft-hodges-saml-lsso-02, September 2007.
[I-D.ietf-sip-saml] Tschofenig, H., Hodges, J., Peterson, J., Polk, J., and D. Sicker, “SIP SAML Profile and Binding,” draft-ietf-sip-saml-06 (work in progress), March 2009 (TXT).
[I2.DistribDynamSaml] Internet2, “Distributed Dynamic SAML,” wiki page Distributed Dynamic SAML, Octover 2007.
[I2.DistribSamlMetadataMgmt] Stockholms Universitet, “A profile for distributed SAML metadata management,” Distributed Dynamic SAML version 7 (Gruesome Gorilla), October 2007.
[IANA.application.samlassertion-xml] OASIS Security Services Technical Committee (SSTC), “application/samlassertion+xml MIME Media Type Registration,” IANA MIME Media Types Registry application/samlassertion+xml, December 2004.
[IEEE.YaKlBe1993] Yahalom, R., Klein, R., and T. Beth, “Trust relationships in secure systems-a distributed authentication perspective,” 1993.
[IIW.DynamicFederationSession] IIW2007b Dynamic Federation Session,” wiki page IIW2007b Dynamic Federation Session, December 2007.
[InCommonFederation] InCommon Higher Education Federation,” web page InCommon Higher Education Federation, December 2007.
[LASSO] Entr'ouvert, “LASSO: Liberty Alliance Single Sign On.”
[OASIS.SSTC] OASIS Security Services Technical Committee (SAML),” web page  OASIS Security Services Technical Committee (SAML).
[OASIS.draft-hodges-HowToLearnSAML-01] Hodges, J., “How to Study and Learn SAML,” OASIS SSTC Working Draft draft-hodges-HowToLearnSAML-01, October 2006.
[OASIS.saml-1.1-spec-set] OASIS, SSTC., Ed., “Security Assertion Markup Language (SAML) v1.1 Specification Set,” OASIS Standard SAML 1.1, August 2003.
[OASIS.saml-2.0-spec-set] OASIS, SSTC., Ed., “Security Assertion Markup Language (SAML) v2.0 Specification Set,” OASIS Standard SAML 2.0, March 2005.
[OASIS.saml-authn-context-2.0-os] Kemp, J., Cantor, S., Mishra, P., Philpott, R., and E. Maler, “Authentication Context for the Security Assertion Markup Language (SAML) V2.0,” OASIS Standard saml-authn-context-2.0-os, 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,” OASIS Standard saml-bindings-2.0-os, March 2005.
[OASIS.saml-conformance-2.0-os] Mishra, P., Philpott, R., and E. Maler, “Conformance Requirements for the Security Assertion Markup Language (SAML) V2.0,” OASIS Standard saml-conformance-2.0-os, March 2005.
[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,” OASIS Standard saml-core-2.0-os, March 2005.
[OASIS.saml-glossary-2.0-os] Hodges, J., Philpott, R., and E. Maler, “Glossary for the Security Assertion Markup Language (SAML) V2.0,” OASIS Standard saml-glossary-2.0-os, March 2005.
[OASIS.saml-metadata-2.0-os] Cantor, S., Moreh, J., Philpott, R., and E. Maler, “Metadata for the Security Assertion Markup Language (SAML) V2.0,” OASIS Standard saml-metadata-2.0-os, March 2005.
[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,” OASIS Standard OASIS.saml-profiles-2.0-os, March 2005.
[OASIS.saml-sec-consider-2.0-os] Hirsch, F., Philpott, R., and E. Maler, “Security and Privacy Considerations for the OASIS Security Markup Language (SAML) V2.0,” OASIS Standard saml-sec-consider-2.0-os, March 2005.
[OASIS.sstc-saml-binding-simplesign-cd-02] Hodges, J. and S. Cantor, “SAML 2.0: HTTP POST "SimpleSign" Binding,” OASIS SSTC Committee Draft sstc-saml-binding-simplesign-cd-02, September 2007.
[OASIS.sstc-saml-exec-overview-2.0-cd-01] Madsen, P. and E. Maler, “SAML V2.0 Executive Overview,” OASIS SSTC Committee Draft sstc-saml-exec-overview-2.0-cd-01, April 2005.
[OASIS.sstc-saml-idp-discovery-cd-02] Widdowson, R. and S. Cantor, “Identity Provider Discovery Service Protocol and Profile,” OASIS SSTC Working Draft draft-sstc-saml-idp-discovery-01, September 2007.
[OASIS.sstc-saml-protocol-ext-thirdparty-cd-02] Cantor, S., “SAML Protocol Extension for Third-Party Requests,” OASIS SSTC Committee Draft sstc-saml-protocol-ext-thirdparty-cd-01, September 2006.
[OASIS.sstc-saml-tech-overview-2.0-draft-14] Ragouzis, N., Hughes, J., Philpott, R., Maler, E., Madsen, J., and T. Scavo, “Security Assertion Markup Language (SAML) V2.0 Technical Overview v14,” OASIS SSTC Working Draft sstc-saml-tech-overview-2.0-draft-14, September 2007.
[OASIS.xri-metadata-V2.0-wd-08] Schleiff, M., Ed., Reed, D., Ed., McAlpin, D., Ed., Sakimura, N., Lindelsee, M., and G. Wachob, “Extensible Resource Identifier (XRI) Metadata V2.0,” Committee Working Draft xri-metadata-V2.0-wd-08, May 2006.
[OASIS.xri-resolution-v2.0-wd-11] Wachob, G., Ed., Reed, D., Ed., Chasen, L., Ed., Tan, W., Ed., and S. Churchill, Ed., “Extensible Resource Identifier (XRI) Resolution Version 2.0,” Committee Working Draft xri-resolution-v2.0-wd-11-final, November 2007.
[OASIS.xri-syntax-V2.0-cs] Reed, D., Ed., McAlpin, D., Ed., Davis, P., Sakimura, N., Lindelsee, M., and G. Wachob, “Extensible Resource Identifier (XRI) Syntax V2.0,” Committee Working Draft xri-syntax-V2.0-cs, November 2005.
[OpenID.identity-attribute-metadata-1_0-01] Hardt, D., “Identity Attribute Metadata - Draft 01,” Draft identity-attribute-metadata-1_0-01, November 2006.
[OpenID.openid-assertion-quality-extension-1_0-03] Recordon, D., Glasser, A., and J. Madsen, “OpenID Assertion Quality Extension 1.0 - Draft 3,” Draft openid-assertion-quality-extension-1_0-03, December 2006.
[OpenID.openid-attribute-exchange-1_0] Hardt, D., Bufu, J., and J. Hoyt, “OpenID Attribute Exchange 1.0 - Final,” Final openid-attribute-exchange-1_0, December 2007.
[OpenID.openid-attribute-types-1_0-02] Hardt, D., “OpenID Attribute Types - Draft 02,” Draft openid-attribute-types-1_0-02, November 2006.
[OpenID.openid-authentication-1_1] Recordon, D. and B. Fitzpatrick, “OpenID Authentication 1.1,” Final openid-authentication-1_1, January 2007.
[OpenID.openid-authentication-2_0] OpenID, “OpenID Authentication 2.0 - Final,” Final openid-authentication-2_0, September 2007.
[OpenID.openid-authentication-security-profiles-01] Granqvist, H., “OpenID Authentication Security Profiles - Draft 1,” Draft openid-authentication-security-profiles-01, September 2006.
[OpenID.site] OpenID Site,” wiki pages OpenID Libraries.
[OpenSSO] java.net, “OpenSSO Project.”
[PingID.DynamicFederation] Ping Identity, “Dynamic Federation. A Game Changer?,” blog post Dynamic Federation. A Game Changer?, November 2007.
[PingID.DynamicFederationDetails] Ping Identity, “Dynamic Federation - Under the Covers,” blog post Dynamic Federation - Under the Covers, November 2007.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” RFC 2616, June 1999 (TXT, PS, PDF, HTML, XML).
[RFC2631] Rescorla, E., “Diffie-Hellman Key Agreement Method,” RFC 2631, June 1999 (TXT).
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” STD 66, RFC 3986, January 2005 (TXT, HTML, XML).
[SAML-Glossary-in-HTML] SAML Glossary (in HTML),” web page SAML-Glossary-in-HTML.
[SAML.conformance.testing] SAML v2.0 Conformance Testing,” web page SAML v2.0 Conformance Testing via Liberty Interoperable Program.
[SAML.open.source.impls] SAML Open Source Implementations,” wiki page SAML Implementations.
[W3C.REC-HTML401] Raggett, D., Le Hors, A., and I. Jacobs, “HTML 4.01 Specification,” December 1999.
[W3C.REC-xml] Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler, “Extensible Markup Language (XML) 1.0 (2nd ed),” W3C REC-xml, October 2000.
[W3C.REC-xmlschema-1] Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, “XML Schema Part 1: Structures,” W3C REC-xmlschema-1, May 2001.
[W3C.soap11] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A., Mendelsohn, N., Nielsen, H., Thatte, S., and D. Winer, “Simple Object Access Protocol (SOAP) 1.1,” W3C Note soap11, May 2000.
[W3C.xmldsig-core] Eastlake, D., Reagle , J., and D. Solo, “XML-Signature Syntax and Processing,” W3C Recommendation xmldsig-core, October 2000.
[Yadis] Miller, J., “Yadis Specification 1.0” (PDF, ODT).
[draft-hodges-saml-openid-profile-02] Hodges, J., “OpenID-SAML Lightweight Web Browser SSO Profile - Draft 02,” independent draft-hodges-saml-openid-profile-02, September 2007.





 TOC 

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.






 TOC 

Author's Address

  Jeff Hodges
  PayPal, Inc.
  2211 North First Street
  San Jose, CA 95131
  US
Email:  Jeff.Hodges@PayPal.com