Menu

Projects:

  Higgins

  Identity Gang  

  Identity Schemas

SocialPhysics.org

SP Blog

Paul's Blog 

Security: If you wish edit rights to this page email paul at socialphysics.org

A.  Introduction

Purpose

This document maps out the dimensions of "identity-related interoperability space."

• Section A: this introduction
• Section B defines an overall architecture of components such as Identity Provider, Service Provider, and Identity Agent.
  
• Section C describes the interactions/flows between these components.
  
• Section D describes data formats used in security tokens, card files, etc.,
  
• Section E contains links to related materials
  

It is intended to support an ongoing discussion within the OSIS group on the topic of interoperability. Specifically, the OSIS group has co-created these related documents that build on this document's foundation:

1. OSIS Interop Use Cases
2. OSIS Interop Capabilities --includes these three charts
   
• Service Provider/RP Capabilities Chart
• Identity Agent Capabilities Chart
  
• Identity Provider Capabilities Chart

This document defines a system architecture that is protocol and platform independent and thereby provides an abstract framework of components and interactions that can be specialized to describe specific interoperability scenarios. For example, to describe a specific interoperability scenario one could take the system diagram below and:

• Delete the components from the diagram that are not present
• Overlay the remaining components with named, real world components. For example, overlay "MediaWiki" on "Service Provider", and overlay "Microsoft CardSpace App" over "Identity Agent" and so on.
• Delete the flows from the diagram that are not present
• Overlay the flow numbers (e.g. flow #7) with a specific protocol (e.g. OpenID)

• Many of the components mentioned below are still under development
• As an industry we are still grappling with how to define interoperability, so this document is a work in progress.
• This document will eventually move to the OSIS wiki at Identity Commons

Recent Edits

If you update this document in any material way, please add a comment here: 

• 2007.4.27: pt: Removed the interop table from this document. The OSIS site now has more updated and more detailed interoperability tables. Added links to the OSIS tables/charts.
  
• 2007.3.23: pt: Updated diagram colors. Created Token Service vs. IdP distinction. Added 3 new flows.
  
• 2007.3.5: pt: Added documentation of flow "E" (missing). Fleshed out Identity Agent deployment architectures section. Added in list of Service Provider Site software sub-components (e.g. Apache + PHP, etc.); Added in explicit list of Token Services (including OpenID OPs); added two new flows to diagram #17, #18. Removed i-card provisioning to separate diagram.
  
• 2007.2.27: pt: renamed "Local App" to "Client App"; added "User Agent" label to the green box
  
• 2007.2.24: pt: updated diagram: added a label to the entire blue block "Service Provider"; added a label to the entire pink block "Identity Provider"; renamed the grey Identity Provider box "Token Service". Added a second "summary" diagram in section B. Updated text switching some Identity Providers to Token Services.
  
• 2007.2.23: sc: Added SAML and Liberty SSOS sections.
  
• 2007.2.19: pt: Added 2 OpenID-specific flows (#16-17) between the IdA and IdP. (IdA acts as OP proxy).
  
• 2007.2.10: pt: Added 2 missing flows for OpenID/SAML browser redirects (flowing upwards); updated diagram.
  
• 2007.1.22: pt: Reorganized material separating "System Components" from "Flows"; New diagram (more unidirectional flows); Create placeholders for OpenID, SAML, etc. flows in text. Changed from "Relying Party Agent" to "Service Provider".
• 2007.1.7: pt: Added section G: References, started to add links to relevant spex on Mike's suggestion
  
• 2007.1.3: pt: Minor changes: folded "Authentication to IdP" into being a sub-section into WS-* section of "Protocols used with IdP" and ; updated table (v2): moved auth methods in underneath protocols; Created the major organizing sections A, B, C... Moved card formats to new "Data" section E.
  
• 2007.1.1: pt: Minor cleanup: e.g. use OpenInfoCard vs. XMLDAP/Chuck/etc.; rewrote the section on claim type namespaces to more clearly reflect the current OpenID state of affairs; Added IdA/IdP interaction protocols section; Added Browser Features section; Many minor changes to align with Interop Table summary;
  
• 2006.12.17: pt: rewrote the Card Types section (now Card Formats) and updated the Card Schemas section
  
• 2006.12.14: pt: edited card types section added more about the difference between CardSpace personal vs. managed cards; removed extra Higgins card type
• 2006.12.13: pt: added diagram and flow references; changed Card Selector to Identity Agent (IdA);
  
• 2006.12.12: pt: Updated personal and managed card term definitions; updated card types section
  
• 2006.12.11b: pt: Updated per Dec 11 OSIS conf call (lots of changes/improvements)
• 2006.12.11a: pt: Updated in anticipation of Dec 11 OSIS conf call
  
• 2006.12.4: pt: Created in anticipation of the Dec  4 OSIS conf call

To Do List

1. Need to have the OpenID-related text validated.
   
2. Need to add to "Negotiation" section material on extended validation certificate display
3. CardSpace: Need to add to cover Service Provider-side STS option
4. Add Creative Commons share alike license/icon
5. Flesh out the Reference section with links to all relevant spex and project home pages
6. Need to add I-Card definition
7. Section C (Flows): need to add a Recognition of the Service Provider flow category. How does the user recognize/trust the Service Provider
   
8. Section C (Flows): need to add description of "I-Card Management" flows
9. Add an HTML table: each column is a system or component, each row is a functional area. (Building on Mike Jone's table on the list)
   
10. The word agent in the term "IdP Agent" is redundant because an IdP is defined as an agent in the Lexicon
11. We could break the IdA/RP interaction into two separate patterns: how an RP initiates interaction vs. how the IdA or IdP responds

Terms Used

• Terms such as Relying Party, Claim , Identity Provider (IdP) , etc. are defined by the Identity Gang Lexicon here
• A Service Provider is an Agent of a Relying Party
• I-Card is defined here
  
• An issuer is the agent that creates a card. It might be the "private" IdP of a Identity Agent, or it might be an external IdP.
• A personal card is an i-card where the user's Identity Agent is acting as its own IdP. Personal cards support a set of claims whose values are provided by the user of the Identity Agent. The user's Identity Agent is the issuer and thus these are often called "self-issued" cards. The set of claim types supported is defined by the Identity Agent UI.
  
• A managed card is an i-card where the issuer is an external IdP, not the user's Identity Agent. The IdP gives a card to the user who imports it into their Identity Agent. IdPs declare the claim types they support in their cards. Separate IdPs can collaborate on defining these claim types or define their own.
  
• An Identity Agent (IdA) is an application that:
  
• Manages a consistent user experience for authentication (and in some cases other kinds of interactions) with a Service Provider
• Displays an i-card selector user interface based on i-card icons when authentication is required by a client application or Service Provider
• Provides a UI to create new personal i-cards (and signs them using the Identity Agent's private STS)
• Provides a UI to import and export personal or managed i-card files in standard file formats
• May provide an i-card manager capability to allow the user to manage (e.g. create, review, update and delete cards within) their portfolio of i-cards
• Is invoked by a browser extension or by a local rich client application
• We use the term Windows to mean Vista, WinXP/.net3 or Win2003

B.  System Components

Service Provider

Service Providers are shown in the blue topmost section of the diagram in section C.

Client App

• Eclipse RCP (Java)
• NetBeans (Java)
• Other Java or C/C++ apps

Service Provider Site

The Service Provider Site component relies on the identity data provided by the Identity Agent. Service Provider code is typically developed using standardized software sub-components including:

CardSpace-compatible

• Bandit
• Apache + PHP
  
• Apache and/or IIS + Ping Identity relying party code
• Apache and/or IIS + BMC relying party code
• Sun web server + Sun relying party code
• IIS + ASP.NET code
  

OpenID compatible

• JanRain (Python, PHP, Ruby, Perl)
• NetMesh
  
• Sxip (Java)
  

Browser/Extension

Browser/Extension Support for CardSpace

1. CardSpace-compatible HTML object tag parsing
   
2. CardSpace-compatible XHTML informationCard tag parsing
3. CardSpace-compatible retrieval of Relying Party policy from Service Provider's STS
   
4. CardSpace-compatible post of token to Service Provider's STS
   

1. Allow JavaScript invocation of isInstalled() method on browser informationCard (i-card) object
2. Advertise informationCard (CardSpace) support in userAgent string. This is detectable by Web server. This feature is supported by IE7 with .NET CLR 3.0

Browser support for CardSpace-compatible Service Providers:

• Firefox
• On Windows: A new Microsoft-sponsored extension. Works with the CardSpace Identity Agent
  
• On Windows, Linux or OSX: With Higgins Browser Extension (HBX)
• On Windows, Linux or OSX: With OpenInfoCard Extension
• Safari
• On OSX: Ian Brown's extension

Browser/Extension Support for Liberty ID-WSF Single Sign-On

Liberty primarily references SAML 2.0 for basic SSO capability, but also references the SAML 2.0 Enhanced Client Profile and combines it with certain ID-WSF 2.0 features to create an interoperable SSO mechanism that resembles Cardspace to some degree. The technical name for this is the ID-WSF Single Sign-On Service. As the "enhanced client" name indicates, the interaction patterns require extra browser functionality.

Here is a summary of the functionality required for interoperability with SAML 2.0 Enhanced Client Profile Service Providers:

1. Support for processing HTTP responses using the SAML PAOS (reverse-SOAP) Binding
   
2. Ability to HTTPS/POST SAML token to Service Provider using the SAML PAOS (reverse-SOAP) Binding

1. Advertise PAOS support in the prescribed HTTP header.

The remainder of the profile consists of Token Service selection and interaction with the Token Service via the Liberty ID-WSF SOAP Binding, which could be supplied by a browser extension or using an Identity Agent as described for Cardspace (and a similar card metaphor could easily be used).

There are no known browsers or extensions with the required functionality.

Browser Support for RSS/SSE

Microsoft has defined an extention to RSS called the Simple Synchronization Extension (SSE) that allows bidirectional synchronization of data. Only the Higgins browser extension for Firefox supports this interaction pattern. See Interop Table.

Browser Support for HTML Scraping

Some browser extensions (e.g. Sxip's Sxipper and Higgins HBX) include support for HTML Scraping--a method of retrieving for the user a copy of of their own data (e.g. profile data) entered by them from the Service Provider site.

Browser Support for Form Filling

Some browser extensions (e.g. Sxip Sxipper and Higgins HBX) include support for automatically populating HTML form fields with data from the user' I-Cards.

Identity Agent (IdA)

CardSpace-compatible Identity Agents

Here is a list of the choices of Identity Agents that have some or all of the functionality of Microsoft's CardSpace application and IE7 on Windows:

1. Microsoft CardSpace - runs on Windows as a rich client application. Status: in production: bundled within Windows Vista and available for WinXP as part of IE7 and .netfx
   
2. Higgins local IdA - client runs on Linux, OSX or Windows as rich client application. Status: under development
   
3. Higgins hosted IdA. Status: under development
4. OpenInfoCard - runs in Firefox on Linux, OSX or Windows. Status: under development
5. Ian Brown's IdA - runs in Safari on OSX. Status: under development

Other Identity Agents

Sxip has released an Identity Agent that can do form filling as well as act as an OpenID compatible "OP" (IdP).

Identity Agent Architectures

Identity Agents are implemented using these architectures:

1. Browser/extension with rich client Identity Agent: The browser invokes a local rich client application to get a token. This app displays an I-Card Selector, as well as all other Identity Agent functions. Examples include: IE7 + CardSpace client on Windows, Higgins H3 , OpenInfoCard Extension and I-Card Selector app, Ian Brown's extension and I-Card Selector application.
2. Browser/extension with rich client I-Card Selector and hosted Identity Agent: The browser invokes a local rich client application to get a token. This app displays an I-Card Selector but relies on a hosted service for all other Identity Agent functions. Examples: Higgins H2
   
3. Browser/extension with embedded I-Card Selector and hosted Identity Agent. The browser, via an extension, includes an embedded I-Card Selector but relies on a hosted/remote Identity Agent service. Example: Higgins H1

Identity Source

An Identity Source may include a Token Service or a Identity Provider (IdP) or both. Either of these may rely on an Attribute Service for the underlying attribute data.

Token Service

Here is a list of known Token Services. Note: If accessed using WS-*, this Token Service is usually referred to as a Security Token Services (STS).

WS-Trust Compatible 

1. Higgins STS (runs on multiple platforms)
   
2. XMLDAP STS (runs on multiple platforms)
3. Sun STS (runs on Solaris and/or Linux)
4. Ping Identity STS (runs on multiple platforms)
5. Microsoft STS code on Windows

Identity Providers (IdPs)

1. JanRain MyOpenID
2. Sxip
3. VeriSign PIP
4. NetMesh
5. Ping Identity
6. LinkSafe, 2idi, ooTao

SAML-based IdPs

1. Sun
   
2. Oracle
   
3. Ping Identity
   

Attribute Data Source

An Attribute Data Source is, from the point of view of an Identity Agent, a local or remote service that provides management access to identity attribute data. By "data management oriented," we mean the ability, as allowed by authorization policies, to potentially create, read, write and update attribute data. Examples of Attribute Data Sources include LDAP directories and RDF/XML data streams.

C.  Flows

Various flows are shown in the diagram.

The design principle behind the diagram is that between any two components there may be information flowing in one direction or another. Here and there we will "reuse" flows across protocols if the fundamental interaction is nearly the same. Otherwise a separate flow number is used.

Before discussing the details of flows used in various protocols, we start with a summary of all of the flows shown in the diagram:

1. User points browser at a Service Provider Site. (All)
   
2. Service Provider policy expression. (CardSpace, Liberty SSOS) or recognition of required protocol (OpenID)
   
3. Browser delegates to Identity Agent. (CardSpace, Liberty SSOS)
   
4. Identity Agent requests Digital Identity from Identity Provider (Token Service). (CardSpace, Higgins+OpenID, Liberty SSOS)
   
5. Identity Provider (specifically a Token Service) returns Digital Identity. (CardSpace, Higgins+OpenID, Liberty SSOS)
6. Identity Agent returns Digital Identity to Browser. (CardSpace, Liberty SSOS)
   
7. Browser posts Digital Identity to SP site. (CardSpace, Liberty SSOS)
   
8. Service Provider site sends browser redirect (OpenID, SAML)
9. Browser redirects to IdP. (OpenID, SAML)
10. IdP issues browser redirect to browser. (OpenID, SAML)
    
11. Browser redirect to Service Provider. (OpenID, SAML)
    
12. Bidirectional direct interactions between SP Site and IdP.
    
13. Identity Agent directly manages attributes in Attribute Data Source. (Higgins)
14. Token Service retrieves attribute data from external Attribute Data Source. (Higgins and many other implementations)
15. Client App requests Digital Identity from Identity Agent. (CardSpace, Liberty SSOS)
16. Request attributes from Identity Provider. (OpenID, SAML)
    
17. Return attributes to Identity Agent. (OpenID)
18. Request attributes from IdA acting as OpenID OP. (OpenID, Sxipper)
    
19. Return attributes from IdA acting as OpenID OP to browser. (OpenID, Sxipper)
20. Identity Provider requests attributes from Identity Attribute Provider
21. Token Service requests Digital Identity from Identity Provider
22. Identity Provider returns Digital Identity to Token Service
    

The diagram below describes what might be called i-card provisioning flows:

A. I-Card made available by IdP is "opened" by browser. (CardSpace)

B. Identity Agent installs i-card from browser. (CardSpace) 

C. Identity Agent exports i-card. (CardSpace)

D. Identity Agent imports i-card. (CardSpace) 

E. Token Service generates an i-card (CardSpace) 

Identity-related data flows can be roughly be categorized as follows:

• Negotiation and Identity Selection
• Retrieving Identity Data from its Source
• Providing Identity Data to the Service Provider
• Provisioning I-Cards
• I-Card Management --not yet written
  

We discuss each category in turn.

Negotiation and Identity Selection

In CardSpace

Retrieving Relying Party Policy

The browser/extension retrieves the Relying Party's policy in flow #2. This policy is expressed as extra (non displayed) tagging added to the RP site's HTML or XHTML page. The browser/extension parses these tags:

1. HTML Object tag support - browser/extension parses RP Agent web page and recognizes this tag. Uses parameters to invoke i-card selector interface in IdA.
2. XHTML informationCard tag support - browser/extension parses web page and recognizes this tag. Uses parameters to invoke i-card selector interface in IdA.

Requesting a Digital Identity Token from the Identity Agent

The browser/extension starts the identity agent requesting in return a token that satisfies this policy (flow #3)

Matching against the Policy

The IdA attempts to find an I-Card that matches the Relying Party's policy. It displays an I-Card Selector user interface displaying the user's I-Cards (disabling those that do not match the policy). The user clicks on one of the i-cards.

In SAML Browser SSO

Identity Provider Discovery

As a browser-based protocol, discovery of the Identity Provider cannot be offloaded to a client-side component. SAML does not require any particular means of discovery. Many approaches are possible, such as:

• Explicit entry from the user
• Selection from a list, possibly filtered in some way
• Use of a cookie, either local or in a shared domain, to recover earlier choices
• Reliance on a separate browser-facing site to make the selection (e.g. a Shibboleth WAYF)

Requesting Authentication

When using the Browser SSO profile, the relying party supplies its "policy" in the form of a SAML AuthnRequest message in response to a request (flow #8). The request is directed to the Identity Provider determined in the step above.

Requesting a Digital Identity Token from the Identity Provider

The browser relays the request issued by the Service Provider to the Identity Provider (flow #9). Various SAML "bindings" can be used to convey the message, using GET or POST, and some result in additional communication from the IdP to the SP (flow #12) to retrieve the request.

In Liberty SSOS

Retrieving Relying Party Policy

The browser/extension receives the Relying Party's SAML request in flow #2. This request is returned inside a SOAP message directed at the client. It is termed a PAOS binding because the SOAP request is in the HTTP response (thus, reverse SOAP).

Requesting a Digital Identity Token from the Identity Agent

The browser/extension starts the identity agent requesting in return that the request be sent on to a compatible IdP (flow #3)

Matching against the Policy

The IdA attempts to find an IdP that can satisfy the Relying Party's request. The request can include information suitable for display to the user indicating which IdPs might be acceptable (or the choice may be entirely up to the user). There is no "card" metaphor assumed in this model, but it maps reasonably.

In OpenID

<to be written>The user types the URL (or XRI) of an OpenID server (aka an OpenID Provider or OP)...describe browser redirects, etc.

Retrieving Identity Data from its Source

In CardSpace the Identity Agent retrieves identity data from the IdP and then (see next section) conveys it to the Service Provider or Client Application. In other systems (e.g. OpenID) the Service Provider retrieves identity data from the Identity Provider via first redirecting the browser to the Identity Provider site and then having the browser redirected back again.

In CardSpace

As soon as the user clicks on the selected i-card, the Identity Agent requests a token from this i-card's associated IdP using an WS-Trust request (aka RST) (flow #4) and receives back the token in the response message (flow #5) (aka RSTR).

• Authentication (to IdP) options:

1. Self-issued or Managed I-Card
2. Kerberos
3. X.509 Certificate
4. Username/Password

• WS-SecurityPolicy options supported
1. SymmetricBinding assertion
2. TransportBinding assertion
   

In SAML Browser SSO

Upon communicating the Service Provider's request to the IdP (flow #9), any form of browser-based authentication can take place, including recognition of an existing session (which is what creates the SSO experience). The AuthnRequest may greatly influence the kinds of authentication that are acceptable, and the contents of the eventual SAML assertion. Eventually the resulting assertion (or a SAML error) is communicated back to the browser (flow #10).

In Liberty SSOS

As soon as the user selects an IdP, the IdA relays the SAML request from the SP using a SOAP message (flow #4), and receives back a SAML response message (flow #5).

Authentication to the IdP takes place as part of the delivery of the request by means of a Liberty ID-WSF security mechanism, which can include various approaches, including any WS-Security token profile. The IdA may also communicate with the IdP via other authentication protocols to obtain credentials it can use during this step (e.g. the Liberty ID-WSF Authentication Service, which is a SASL-based protocol).

Providing Identity Data to the Service Provider

In CardSpace

The IdA receives the requested token from the IdP (flow #5) and returns it to the Browser/Extention (flow #6). The browser/extension posts the token using HTTPS to the Service Provider (flow #7).

<to be written: describe alternate flow using Service Provider delegated STS>

In SAML Browser SSO

The browser receives the requested token from the IdP (flow #10) and supplies the token in the form of a SAML protocol response to the SP (flow #11). Various SAML "bindings" can be used to convey the response, using GET or POST, and some result in additional communication from the SP to the IdP (flow #12) to retrieve the response.

In Liberty SSOS

The IdA receives the SAML response from the IdP (flow #5) and returns it to the Browser/Extension (flow #6). The browser/extension sends the message to the SP as a SOAP response, completing the PAOS interaction begun earlier (flow #7).

Provisioning I-Cards

In CardSpace

In CardSpace the user must acquire I-Cards from IdPs and install them into their Identity Agent. There are two paths. In the first path, the IdP can export an I-Card file (flow E) that the user manually imports into their Identity Agent (flow D). A second path is for the IdP to embed the I-Card data in a web page and have the user click on a button/icon. In this path the browser downloads the I-Card data (flow A) and installs it into the IdA (flow B).

The Cardspace i-card format can be imported/exported by these IdAs (flow C and D):

• CardSpace
• Higgins IdA
• OpenInfoCard IdP/STS
• Ian Brown's IdA

The CardSpace i-card format can be created by these IdP software components (flow E):

• Ping IdP/STS
• Microsoft IdP/STS (Active Directory)
• Higgins Token Service

D.  Data: Cards, Tokens, and Claims

Card Formats

There are two i-card data formats.

CardSpace Format (XML)

A format defined by Microsoft as used in CardSpace. The format is used in two different ways:

1. Personal profile - how this format is used to describe personal cards
• Card contains both the supported claim types as well as the values of these claims
• In this profile, the format elements used in the CardSpace Managed profile to describe an STS endpoint are not used.
2. Managed profile - how this format is used to describe managed cards
• Encapsulates the metadata about a non-local network STS endpoint that, via WS-Trust, can provide on a Digital Identity in token form.

Higgins Format (XML)

This format is a superset of the CardSpace format. CardSpace format data can be losslessly converted to Higgins format. It adds new element types that are used in the "URI profile" described below. This format can be used in three different ways:

1. CardSpace Personal profile (same as CardSpace personal profile described above)
   
2. CardSpace Managed profile (same as CardSpace managed profile described above)
   
3. URI profile
• In this profile a contextID XML element is used to hold the URI (may be an XRI) of an identity Attribute Data Source (see "Components" above). An Attribute Source is a service (usually a network endpoint) that is accessed using a data access protocol/format such as LDAP, RDF, XDI, etc. [In this I-Card profile, the document elements used in the CardSpace Managed profile to describe an STS endpoint are not used.]
• If the card supports a complex schema (as opposed to a set of URI claim types as defined in the CardSpace format), the complexSchema element must be present and it must contain a URI that can be resolved to a schema described in OWL/RDF based on the higgins.owl base schema/ontology.
  

The Higgins Format can currently only be created, imported, and exported by the Higgins IdA, but as an open, documented format, it could be processed by any IdA.

Token Types

The following types of tokens are passed in flows #2-7

1. OASIS WSS Token Profiles
1. SAML 1.1
2. SAML 2.0
3. Kerberos v5
4. UN/PW
5. X509 v3
6. Idemix

The following types of tokens are passed in flows #8 and #9:

1. OpenID Token Types
1. OpenID 1.1
2. OpenID 2.0
3. LID 2.0

Claim Types 

A claim is an attribute that is received by a Service Provider or Client App. Their "source" attributes and values are managed by IdPs and IdAs.

Each claim has a type. The claim types used in card formats are URIs. Any IdP (or IdA acting as its own IdP) can define its own claim type URIs, but these may or may not be known and understood by any given Relying Party.

Although there is no requirement to do so, in practice sets of well known claim types share a common root URI that we call here the claim type namespace.

At present there is currently only one well known claim type namespace, namely, CardSpace. All of the 14 defined CardSpace claim type URIs share the common root URI: (http://schemas.xmlsoap.org/ws/2005/05/identity/claims/). There is an ongoing discussion in the OpenID community on how to manage claim types (they're called attribute types in OpenID). Other well known sets of attribute types could be mapped into claim type URIs if we, as an industry, agree on the mapping to URI's). Examples include:

• SAML Attribute Profiles (SAML fully supports and encourages use of URIs to name attributes)
  
• Liberty People Service
• Other Liberty profile specifications
• See also IdentitySchemas.org / List of Schemas
  

Note: the Identity Commons working group, IdentitySchemas.org, is focused on attribute/claim interoperability.

E.  Reference

<work in progress> 

Specifications

• [CardSpace] CardSpace documentation at MSDN
• [LIBERTY] Liberty Alliance Specifications
  
• [LID]  LID Wiki
• [OpenID] OpenID.net Specifications
  
• [RSSE] Simple Sharing Extensions for RSS and OPML
• [SAML] SAML V2.0 (OASIS SAML TC)
• [WS-MetadataExchange] "Web Services Metadata Exchange (WS-MetadataExchange)," September 2004.
• [WS-Policy] WS-Policy v1.2
• [WS-SecurityPolicy] "Web Services Security Policy Language (WS-SecurityPolicy)," July 2005.
• [WS-Trust] "Web Services Trust Language (WS-Trust)," February 2005. (WS-SX TC )
  
• [WSS] OASIS WSS TC
  
• WS-Security Core Specification 1.1
• Username Token Profile 1.1
• X.509 Token Profile 1.1
• SAML Token profile 1.1
• Kerberos Token Profile 1.1
• Rights Expression Language (REL) Token Profile 1.1
• SOAP with Attachments (SWA) Profile 1.1
• [XRI] OASIS XRI TC

Open Source and/or Free Projects

• [Bandit] Novell Bandit
  
• [Higgins] Higgins project home (eclipse.org/higgins)
• [LID]  LID Wiki
• [OIC] OpenInfoCard 
• [Shibboleth] Internet2 Shibboleth Project
• [Sxipper] Sxipper Firefox Extension
  

G.  Authors

This wiki has been edited by Paul Trevithick, with input and corrections from others. If you make a additions/edits please add your name below.

Portions contributed during 2006-2007 by Paul Trevithick, Mike Jones, Mary Rundle, Scott Cantor, Tony Nadalin, Uppili Srinivasan