SOA Security and WS-Federation

SOA is being used to support organizations in collaboration in the creation of virtual organizations for mutual benefit. A crucial building block in the creation of virtual organizations is the federation of identity information, allowing transparent access across security domains for users based on trustrelationships that are established between the participating organizations. While WS-Federation does not address the specifics of how trust relationships are established, itprovides a metadata exchange framework to allow organizations to provide services that leverage these trust relationships. WS-Federation is a component of the WS-Security family of standards and has been created to support the federation of security domains, which allows users whose identity information exists in one security domain to access resources in another security domain. This is enabled by the abilityto broker identity data including indentity, authentication, authorization and attribute information between security domains, through the use of mechanisms selected based on the relationship of trust that exists between the security domains. WS-Federation provides astandard way for security domains to exchange metadata in order to indicate the trust relationships between these security domains. This is an overview of the contents of the WS-Federation Version1.1 Specification published in December 2006.

An important aspect of the WS-Federation approach is that an organization needs to be able to use their existing identity management infrastructures in order to support identity federation, with minimal new investment required in order to participate. For this reason, the range of supported security tokens, attributes and discovery approaches are designed to support the range of technologies that are already in place as a foundation. The approach also does not specify specific trust toplogies, tools and relationships, deliberately in order to provide flexibility to allow the ability to participate in identity federation independently of what the existing infrastructure consists of. Furthermore, the approach is designed to be extensible to make it easy to integrate new approaches to identity and trust management that may be developed going forward.

WS-Federation exists within a family of other WS-*standards. It rests on a foundation of WS-Security and WS-Trust that contain the primitives necessary to define security tokens, trust topologies and security infrastructures. The primitives defined in WS-Policy and WS-SecurityPolicy, along with extensions that are defined as part of theWS-Federation specification, are indended to support the definition of policies that identify what the supported and required components of a federation are by participating members, and what the choices are for communicating the policy information between federation participants.

There are two types of requesters that are supported by WS-Federation, Web services and Web browser based requesters. Identity mapping could be done at the target service, the requestor, the identity provider, or an intermediate security token service. In order to provide privacy inthe situation where identity mapping is performed by the resource that the user is accessing, WS-Federation includes the specification of a service called a pseudonym service that provides the federated identity for the mapping. In this situation therequestor obtains, through the leverage of these trust relationships, a security token that the target service can accept. In this case, the target service has no way of knowing that the requestor is in another security domain.

2. Alternate Federation and Trust Model

In the case where there do not exist trust relationships between the requestor and its identity provider/security token service, or between the target service and its own identity provider/token service, the target service will need to use its own security token service to validate the token provided by the requestor. In this case, the target service is aware that the requestor is in another security domain.

3. Indirect Trust Model

In the indirect trust model, there is no direct trust relationship between the requestor's security token service and the target service's security token service, but trust relationships that both securitytoken services have with a third party security token service are leveraged in order to provide a security token to the requestor that will work with thetarget service.

4. Multiple Trust Domain Model

In the multiple trust domain model, the requestor accesses target services that exist in more than one other security domain, by leveraging trust relationships between the requestor's security token service and the security token services for the set of target services.

5. Trust Between Requestor-Resource and Resource-Delegate Resource

In this trust topology, a requestor accesses a target service leveraging a trust relationship between its security token service andthe target service's security token service, and the target service delegates its work to a delegate service leveraging a trust relationship between the target service's security token service and the delegate service's security token service.

6. No Trust Relationship Between Resource Providers

This trust topology exists when a requestor accesses a target service leveraging a trust relationship between its security token service and the target service's security token service, and the target service's security token service has no trust relationship with a delegateservice's security token service, but there is a trust relationship between the requestor's security token service and the delegate service's security token service.

Identity Providers and Security Token Services

A Security Token Service (STS) is a service that will issue and exchange security tokens. A Webservice that conforms to the WS-Trust specification may act as its own STS. Another type of STS is an identity provider that authenticates users and issues security tokens that contain identity claims. Sometimes an identityprovider and STS will reside in the same service. In other cases, an identity provider can access an STS to provide security tokens to requestors after they have been authenticated by the identity provider.

Attributes and Pseudonyms

Attributes are used to exchange information about requestors that are not already included in security tokens or requests. Pseudonym services provide account management for pseudonyms and the ability to issue, update and revoke pseudonyms

Federation Metadata

Federation metadata can be represented as a document that contains metadata for an endpoint existing in one or more federations, for one or more services, with one or more MEPRs per service, can refer to external metadata documents, and can be contained inside a service's WSDL description.

Federation Metadata Document

The federation metadata document is structured as follows:

<?xml version="1.0" encoding="..."?>

<fed:FederationMetadata xmlns fed="..." ...>

<fed:Federation[FederationID="..."= ...>

[FederationMetadata]

</fed:Federation>

[Signature]

</fed:FederationMetadata>

The FederationID attribute is an optional URI designating a pecific federation, but can be left out which is interpreted as the default federation, or at most one Federation element in the FederationMetadata document. The [Federation Metadata] property consists of a set of optional metadata statements. The [Signature] property consists of an XML Digital Signature on the metadata document content, which provides integrity and data origin authentication for the metadata document.

Any federation participant's metadata document can containthe following metadata elements

1. mex:MetadataReference

2. fed:AttributeServiceEndpoint

A Security Token Service's metadata document can contain the following metadata elements:

1. fed:TokenSigningKeyInfo

2. fed:PseudonumServiceEndpoint

3. fed:SingleSignOutSubscriptionEndpoint

4. fed:TokenTypesOffered

5. fed:UriNamedClaimTypesOffered

6. fed:AutomaticPseudonyms

7. fed:IssuerNamesOffered

A Service Provider or Relying Party's (which can be aSecurity Token Service) metadata document can contain the following elements:

1. fed:TokenIssuerName

2. fed:TokenIssuerEndpoint

3. fed:TokenKeyTransferKeyInfo

4. fed:SingleSignoutNotificationEndpoint

In order to reference another metadata document, a mex:MetadataReference element is used which refers, using theWS-MetadataExchange specification, to another metadata document which has the same federation identification. Metadata documents can also share elements by using the fed:FederationInclude element and be named using URIs.

The TokenSigningKeyInfoElement of the Federation MetadataDocument

Security Token Services and other token issuers need to beable to indicate to metadata users what key it will use to sign security tokens that it issues. The fed:TokenSigningKeyInfo Element is used to specify this key and has the following structure:

<fed:TokenSigningKeyInfo ...>

<wsse:SecurityTokenReference>

...

</wsse:SecurityTokenReference>

</fed:TokenSigningKeyInfo>

The wsse:SecurityTokenReference can contain any child element of the ds:KeyInfo element defined in the XML-Signature specification. This element can be specific to a service or an endpoint.

The TokenKeyTransferKeyInfo Element of the FederationMetadata Document

Security Token Services and Relying Parties need to be able to indicate which key requestors need to use to encrypt key information that is to be sent to them. The fed:TokenKeyTransferKeyInfo element is used for this purpose and has the following structure:

<fed:TokenKeyTransferKeyInfo ...>

<wsse:SecurityTokenReference>

...

</wsse:SecurityTokenReference>

</fed:TokenKeyTransferKeyInfo>

The wsse:SecurityTokenReference element can contain any child element of the ds:KeyInfo element defined in the XML-Signature specification. This element can be specific to a service or an endpoint.

The IssuerNamesOffered Element of the Federation MetadataDocument

Token issuers can be part of a set of equivalent issuers. Relying parties need to verify that the token issuer is a member of the set in order to be able to use the token issuer. The fed:IssuerNamesOffered element is used for this purpose and has the following structure:

<fed:IssuerNamesOffered ...>

<fed:IssuerNameUri="xs:aURI" .../> ...

</fed:IssuerNamesOffered>

This element can be specific to a service or an endpoint.

The TokenIssuerName Element of the Federation MetadataDocument

Relying parties need to be able to indicate that they are included in a set of equivalent issuers. The fed:TokenIssuerName element is used for this purpose and has the following structure:

<fed:TokenIssuerName...>xs:aURI</fed:TokenIssuerName>

This element can be specific to a service or an endpoint.

The TokenIssuerEndpoint element of the Federation MetadataDocument

A relying party needs to be able to indicate to other federation members what Security Token Service that it trusts so that the other federation members can know where to go to get security tokens that can be used to access the relying party. TheTokenIssuerEndpoint element is used for this purpose and has the following structure:

<fed:TokenIssuerEndpoint>

wsa:EndpointReferenceType

</fed:TokenIssuerEndpoint>

The wsa:EndpointReferenceType indicates that an endpoint reference conforming to the WS-Addressing specification is used to specify the endpoint. This element can be specific to a service or an endpoint.

The PseudonymServiceEndpoint Element of the FederationMetadata Document

Token issuers and Security Token Services need to be able to indicate which pseudonym service that services should use when they want to map user identities. ThePseudonymServiceEndpoint element is used for this purpose and has the following structure:

<fed:PseudonymServiceEndpoint>

wsa:EndpointReferenceType

</fed:PseudonymServiceEndpoint>

The wsa:EndpointReferenceType indicates that an endpoint reference conforming to the WS-Addressing specification is used to specify the endpoint. This element can be specific to a service or an endpoint.

The AttributeServiceEndpoint Element of the FederationMetadata Document

Requestors need to be able to provide a way to indicate to services where to send queries for attribute information that may be required in order to process requests. The AttributeServiceEndpoint element is used for this purpose and has the following structure:

<fed:AttributeServiceEndpoint>

wsa:EndpointReferenceType

</fed:AttributeServiceEndpoint>

The wsa:EndpointReferenceType indicates that an endpoint reference conforming to the WS-Addressing specification is used to specify the endpoint. This element is a service level element.

The SingleSignOutSubscriptionEndpoint Element of the Federation Metadata Document

Token issuers and Security Token Services need to be able to specify a subscription endpoint for them to send sign out messages to.

<fed:SingleSignOutSubscriptionEndpoint>

wsa:EndpointReferenceType

</fed:SingleSignOutSubscriptionEndpoint>

The wsa:EndpointReferenceType indicates that an endpoint reference conforming to the WS-Addressing specification is used to specify the endpoint. This element can be specific to a service or an endpoint.

The SingleSignOutNofificationEndpoint Element of the Federation Metadata Document

Service providers and Security Token Services need to be able to register to receive notification when a requestor has signed out of the federation. The SingleSignOutNotification element is used for this purpose and has the following structure:

<fed:SingleSignOutNotificationEndpoint>

wsa:EndpointReferenceType

</fed:SingleSignOutNotificationEndpoint>

The wsa:EndpointReferenceType indicates that an endpoint reference conforming to the WS-Addressing specification is used to specify the endpoint. This element can be specific to a service or an endpoint.

The TokenTypesOffered Element of the Federation Metadata Document

Token issuers and Security Token Services need to be able to indicate which token types they support. The TokenTypesOffered element is used for this purpose and has the following structure:

<fed:TokenTypesOffered ...>

<fed:TokenType Uri="xs:aURI" ...>

...

</fed:TokenType>

...

</fed:TokenTypesOffered>

One or more fed:TokenType elements are used to specify the set of token types that are provided. A URI attribute can be used to specify a token type. The TokenTypesOffered element is extensible. Additional elements and attributes can be included in the TokenTypesOffered and TokenType elements if they preserve the existing semantics of the WS-Federation specification.

The UriNamedClaimTypesOffered Element of the FederationMetadata Document

Token Issuers and Security Token Services need to be able to specify the set of claims that they offer to service providers given the identity of a requestor. The UriNemedClaimTypesOffered element is used for this purpose and has the following structure:

<fed:UriNamedClaimTypesOffered ...>

<fed:ClaimTypeUri="aURI" ...>

<fed:DisplayName...>xs:string</fed:DisplayName>

<fed:Description...>xs:string</fed:Description>

...

</fed:ClaimType>

...

</fed:UriNamedClaimTypesOffered>

The UriNamedClaimTypesOffered element is extensible. Additional elements and attributes can be included in the UriNamedClaimTypesOffered, ClaimType, DisplayName and Description elements if they preserve the existing semantics of the WS-Federation specification.

The AutomaticPseudonyms Element of the FederationMetadata Document

Token issuers and Security Token Services need to be able to indicate whether they either perform the automatic mapping of pseudonyms or otherwise perform identity mapping. The AutomaticPseudonyms element is used for this purpose and has the following structure:

<fed:AutomaticPseudonyms>

xs:boolean

</fed:AutomaticPseudonyms>

The Signature Property of the Federation Metadata Document

The Signature property of the metadata document is used to provide data origin authentication and data integrity for the federation metadata. XML Signature is recomended, and if used it is required that XML Exclusive Canonicalization is used.

Federation Metadata Discovery

If a relying party needs to obtain federation metadata given nothing more than the DNS host name of a service then the following processing order is recommended by the WS-Federation specification:

1. HTTPS GET, WS-Transfer/WS-ResourceTransfer GET (WS-Security is recommended), and HTTP GET are preferred in the listed order.

2. The federation ID should be used before accessing metadata using the default federation.

The federation metadata document can be contained within a service's WSDL description.

The recommended federation metadata path is as follows:

https://server-name/FederationMetadata/specification-version/federation-id/FederationMetadata.xml

or

http://server-name/FederationMetadata/specification-version/federation-id/FederationMetadata.xml

or

https://server-name/FederationMetadata/specification-version/FederationMetadata.xml

or

http://server-name/FederationMetadata/specification-version/FederationMetadata.xml

The FederatedMetadataHandler Header

Services may be configured with a pre-processing service that handles federation metadata requests. The FederatedMetadataHandler header is used to identify metadata requests for this purpose. This is accomplished by including the following element in the header of a SOAP
message:

<fed:FederationMetadataHandler .../>

The Metadata Exchange Dialect

The metadata exchange dialect is used when including the federation metadata documents as an element in a Web service's mex:Metadata element conforming to the WS-MetadataExchange specification. This is done by specifying the metadata dialect URI using an attribute on a mex:MetadataSection element which contains the Federation Metadata Document:

<mex:MetadataSection
Dialect="http://schemas.xmlsoap.org/ws/2006/12/federation">

<fed:FederationMetadata ...>

...

</fed:FederationMetadata>

</mex:MetadataSection>

This can be used to provide backward compatiblity as subsequent versions of the WS-Federation specification may be published.

Publishing Federation Metadata Location

The WS-Federation specification recommends that domains publish federation metadata using SRV resource records in DNS databases.

The _Service.Protocol.TargetDnsDomain is used to specify the available protocols by which the metadata is available, which may be one or more of HTTP, HTTPS or WS-Transfer/WS-ResourceTransfer, by specifying the owner name of the SRV record as:

1. _fedMetadata._http.TargetDnsDomain in order to indicate that metadata is available via HTTP

2. _fedMetadata._https.TargetDnsDomain in order to indicate that metadata is available via HTTPS

3. _fedMetadata._wsxrf._http.TargetDnsDomain in order to indicate that metadata is available via WS-Transfer/WS-ResourceTransfer

In addition, priority (load balance priority), weight (load balance weight), port (port that the service is available on) and target (domain name) information is included in the SRV record.

The WS-Federation specification recommends that metadata providers include a signature element and that metadata consumers validate the signature elements of federation metadata documents.

Federated Sign-Out

Federated sign-out is used to give relying parties the ability to reclaim resources that had been consumed in order to support a user session within the federation. Sign-out is accomplished by sending an optional message.

The Sign-Out Message

When a requestor chooses to terminate a federation Single Sign-On session they will send a Sign-Out message to the Identity Provider or Security Token Service that they used to authenticate within the federation with. The mssage structure is as follows:

<fed:SignOut wsu:Id="..." ...>

<fed:Realm>xs:aURI</fed:Realm>

<fed:SignOutBasis ...>...</fed:SignOutBasis>

...

</fed:SignOut>

...

</fed:SignOut>

The optional fed:Realm element indicates a realm that the sign-out is operational for. The mandatory fed:SignOutBasis can is used to specify the principal that is signing out. The optional ID element is a label for the SignOut message. The SignOut message is extensible. Additional elements and attributes are allowed to be included in the SignOut and SignOutBasis elements if they do not modify the semantics of the WS-Federation specification. The WS-Federation specification recommends that SignOut messages be signed in order to prevent SignOut of a principal by an unauthorized entity.

Federating the Sign-Out Message

In order to share sign-out information with all relying parties that a user has accessed in the federation, a method of sending federated sign-out messages is needed. This can be accomplished by having Security Token Services send sign-out messages to secondary Security Token Services, or by using WS-Eventing to create subscriptions to federated sign-out messages. These messages can be filtered in two ways.

<wsrt:Expression>

<fed:FilterPseudonyms>

<fed:PseudonymBasis>

<wsse:BinarySecurityToken>...</wsse:BinarySecurityToken>

</fed:PseudonymBasis>

<fed:RelativeTo>

<wsa:Address>http://www.example.org/example-target-scope</wsa:Address>

</fed:RelativeTo>

</fed:FilterPseudonyms>

</wsrt:Expression>

</wsrt:Get>

</S:Body>

</S:Envelope>

This is an example reply:

<S:Envelope xmlns:S=:"..."xmlns:wsa="..." xmlns:wsxf="..." xmlns:fed="..."

xmlns:wsu="..." xmlns:wsse="..."xmlns:wsrt="...">

<S:Body>

<wsrt:GetResponse>

<wsrt:Result>

<fed:Pseudonym>

<fed:RelativeTo>

<wsa:Address>http://www.example.org/example-target-scope</wsa:Address>

</fed:RelativeTo>

<wsu:Expires>2007-02-18T20:04:00Z</wsu:Expires>

<fed:SecurityToken>...</fed:SecurityToken>

<fed:ProofToken>...</fed:ProofToken>

</fed:Pseudonym>

</wsrt:Result>

</wsrt:GetResponse>

</S:Body>

</S:Envelope>

Setting Pseudonyms

Pseudonyms are set in a Pseudonym Service using the WS-ResourceTransfer extensions to WS-Transfer in a wsrt:Put element, contained in a wsrt:Fragment element with the value of the Mode attribute set to "Insert".

Here's an example:

<S:Envelope xmlns:S=:"..."xmlns:wsa="..." xmlns:wsxf="..." xmlns:fed="..."

xmlns:wsu="..." xmlns:wsse="..."xmlns:wsrt="...">

<S:Body>

<wsrt:PutDialect="http://schemas.xmlsoap.org/ws/2006/12/federation/pseudonymdialect">

<wsrt:Expression Mode="Insert">

<fed:FilterPseudonyms>

<fed:PseudonymBasis>

<wsse:BinarySecurityToken>...</wsse:BinarySecurityToken>

</fed:PseudonymBasis>

<fed:RelativeTo>

<wsa:Address>http://www.example.org/example-target-scope</wsa:Address>

</fed:RelativeTo>

</fed:FilterPseudonyms>

</wsrt:Expression>

<wsrt:Value>

<fed:Pseudonym>

<fed:RelativeTo>

<wsa:Address>http://www.example.org/example-target-scope</wsa:Address>

</fed:RelativeTo>

<fed:SecurityToken>...</fed:SecurityToken>

<fed:ProofToken>...</fed:ProofToken>

</fed:Pseudonym>

</wsrt:Value>

</wsrt:Put>

</S:Body>

</S:Envelope>

Deleting Pseudonyms

Pseudonyms are deleted in a Pseudonym Service using the WS-ResourceTransfer extensions to WS-Transfer in a wsrt:Put element, contained in a wsrt:Fragment element with the value of the Mode attribute set to"Remove".

Here's an example:

<S:Envelope xmlns:S=:"..."xmlns:wsa="..." xmlns:wsxf="..." xmlns:fed="..."

xmlns:wsu="..." xmlns:wsse="..."xmlns:wsrt="...">

<S:Body>

<wsrt:PutDialect="http://schemas.xmlsoap.org/ws/2006/12/federation/pseudonymdialect">

<wsrt:Expression Mode="Remove">

<fed:FilterPseudonyms>

<fed:PseudonymBasis>

<wsse:BinarySecurityToken>...</wsse:BinarySecurityToken>

</fed:PseudonymBasis>

<fed:RelativeTo>

<wsa:Address>http://www.example.org/example-target-scope</wsa:Address>

</fed:RelativeTo>

</fed:FilterPseudonyms>

</wsrt:Expression>

</wsrt:Put>

</S:Body>

</S:Envelope>

Creating Pseudonyms

Pseudonyms are created in a Pseudonym Service using the WS-ResourceTransfer extensions to WS-Transfer in a wsrt:Put element, contained in a wsrt:Create element.

Here's an example:

<S:Envelope xmlns:S=:"..."xmlns:wsa="..." xmlns:wsxf="..." xmlns:fed="..."

xmlns:wsu="..." xmlns:wsse="..."xmlns:wsrt="...">

<S:Body>

<wsrt:CreateDialect="http://schemas.xmlsoap.org/ws/2006/12/federation/pseudonymdialect">

<wsrt:Expression Mode="Insert">

<fed:FilterPseudonyms>

<fed:PseudonymBasis>

<wsse:BinarySecurityToken>...</wsse:BinarySecurityToken>

</fed:PseudonymBasis>

<fed:RelativeTo>

<wsa:Address>http://www.example.org/example-target-scope</wsa:Address>

</fed:RelativeTo>

</fed:FilterPseudonyms>

</wsrt:Expression>

<wsrt:Value>

<fed:Pseudonym>

<fed:RelativeTo>

<wsa:Address>http://www.example.org/example-target-scope</wsa:Address>

</fed:RelativeTo>

<fed:SecurityToken>..</fed:SecurityToken>

<fed:ProofToken>...</fed:ProofToken>

</fed:Pseudonym>

</wsrt:Value>

</wsrt:Create>

</S:Body>

</S:Envelope>

Security Tokens and Pseudonyms

Pseudonyms services can associate a pseudonym with a security token. The requestor can storeand retrieve a security token that it receives from a Security Token Service, or the Security Token Service can store and retrieve the security token on behalf of the requestor. On the other hand, a requestor can communicate with a Security Token Service by sending a RequestSecurityToken element conforming to the WS-Trust specification, and receive a RequestSecurityTokenResponse element in return.

RequestSecurityToken and RequestSecurityTokenResponse Extensions

If a Security Token Service is mapping pseudonyms to present a unique pseudonym to a target service, security token requests can contain a fed:RequestPseudonym element in the RequestSecurityToken. The structure of the fed:RequestPseudonym element is as follows:

<fed:RequestPseudonym SingleUse="xs:boolean" Lookup="xs:boolean" ...>

...

</fed:RequestPseudonym>

The value of the SingleUse attribute is used to specify that a pseudonym shall be used only once. The value of the Lookup attributes specifies that a pseudonym associated with the scope that is indicated should be returned, or if the primary identity for the principal should be used regardless of the context. The RequestPseudonym element is extensible. Additional elements and attributes can be included in the RequestPseudonym element if they do not modify the semantics of the WS-Federation specification.

Security Tokens and RequestSsecurityToken and RequestSecurityTokenResponse Extensions

Pseudonym Services can also store usernames and passwords, symmetric keys and newly generated private keys along with the pseudonyms.

The ReferenceToken Element

Reference tokens are an extension to WS-Trust that were created as part of the WS-Federation specification. They enable RequestSecurityTokenResponse messages to return a reference to a token, secured with a proof token, leaving it up to the requestor to acquire the token itself.
The ReferenceToken element has the following structure:

<fed:ReferenceToken ...>

<fed:ReferenceEPR>wsa:EndpointReferenceType</fed:ReferenceEPR>

<fed:ReferenceDigest ...>xs:base64Binary</fed:ReferenceDigest>

<fed:ReferenceType ...>xs:anyURI</fed:ReferenceType>

<fed:SerialNo ...>...</fed:SerialNo>

...

</fed:ReferenceToken>

The ReferenceEPR element contains an endpoint reference that the request was sent to. The optional ReferenceDigest element contains an SHA1 digest of the token. The optional
ReferenceType element contains a URI that specifies the token type. The SerialNo element contains a unique identifier for the token. The ReferenceToken element is extensible. Additional elements and attributes are allowed in the ReferenceToken element, and additional attributes are allowed in the ReferenceDigest, ReferenceType and SerialNo elements if they do not modify the semantics of the WS-Federation specification.

The FederationID Element

The FederationID element can be included in an RequestSecurityToken or RequestSecurityTokenResponse in order to indicate which federation is being used. The structure of this element is as follows:

<fed:FederationID ...>xs:anyURI</fed:FederationID>

The FederationID element contains a URI that identifies the federation. The FederationID element is extensible. It can contian additional attributes that do not modify the semantics of the WS-Federation specification.

The RequestProofToken Element

The RequestProofToken element is used to extract a token to pass to a relying party that does not have the ability to get the session key. It has the following structure:

<fed:RequestProofToken ...>

...

</fed:RequestProofToken>

The RequestProofToken element is extensible. Additional elements and attributes can be
included in the RequestProofToken element if they do not modify the semantics
of the WS-Federation specification.

The ClientPseudonym Element

Pseudonym services may optionally support the ClientPseudonym element. The ClientPseudonym element is used to request an ad hoc pseudonym and is echoed in the RSTR. It has the following structure:

<fed:ClientPseudonym ...>

<fed:PPID ...>xs:string</fed:PPID>

<fed:DisplayName ...>xs:string</fed:DisplayName>

<fed:Email ...>xs:string</fed:Email>

...

</fed:ClientPseudonym>

The PPID element contains a private personal identifier. The DisplayName element
contains a display value. The Email element contains an E-mail address. The ClientPseudonym element is extensible. Additional elements and attributes can be included in the ClientPseudonym, PPID, DisplayName and Email elements if they do not modify the semantics of the WS-Federation specification.

The Freshness Element

The Freshness element is used to specify how long to re-use cached credentials. It has the
following structure:

<fed:Freshness AllowCache="xs:boolean" ...>

xs:unsignedint

</fed:Freshness>

The integer value of the Freshness element is used to specify the number of minutes to allow the re-use of cached credentials. The Freshness element is extensible. Additional attributes are allowed to be included in the Freshness element if they do not modify the semantics of the
WS-Federation specification.

Authorization in WS-Federation

One type of Security Token Service supported by WS-Federation is an authorization service.

WS-Federation includes an authorization model and extensions to the WS-Trust specification that are created for the purposes of supporting powerful authorization expressions. An authorization service uses two tables to make authorization decisions. The first of these tables is the requirement table that specifies the claims that are required to access target
services. The second table is the claim table and is used to store the sets of claims that requestors have provided, after processing with other context information and applicable policies.

The auth:AdditionalContext Element

The auth:AdditionalContext element is used for including arbitrary authorization context data in the RST and RSTR. It has the following structure:

<wst:RequestSecurityToken>

...

<auth:AdditionalContext ...>

<auth:ContextItem Name="xs:anyURI" Scope="xs:anyURI" ...>

element.</auth:AdditionalContext>

...

</wst:RequestSecurityToken>

The ContextItem element contains is used to specify names and values for additional context properties. The Name attribute value is a URI that indicates what type of context property is being specified. The Scope element is optional and is used to indicate a scope for the property.

A Dialect for Interoperable Claim Expression

A dialect is included in the WS-Federation specification for the interoperable specification of claims. A RequestSecurityToken element with a set of claims that uses this dialect has the following
structure:

<wst:RequestSecurityToken>

...

<wst:Claims Dialect=http://schemas.xmlsoap.org/ws/2006/12/authorization/authclaims>

<auth:ClaimType Uri="xs:anyURI" Optional="xs:boolean">

<auth:Value>...</auth:Value>

</auth:ClaimType>

</wst:Claims>

...

</wst:RequestSecurityToken>

The ClaimType element is used to specify an individual claim. The Uri attribute is used to indicate the claim type. The Optional attribute is used to specify whether a claim is optional or mandatory. The Value element is optional and is used to indicate a string value for the claimbeing specified. The ClaimType element is extensible. Additional elements and attributes are allowed to be contained in the ClaimType element if they do not modify the semantics of the WS-Federation specification.

SOA Security and HSPD-12: Cryptographic Foundations

Cryptographic Foundations for Understanding HSPD-12 and FIPS 201 Compliance Requirements
Post Overview
• Brief Overview of FIPS 201
• Cryptographic Foundations and Standards for FIPS 201

Additional Publications in Support of FIPS 201
– NIST Interagency Report 7337 Personal Identity Verification Demonstration Summary
• Report summarizes the demonstration of commercially available products that support FIPS 201 and the accompanying special publications
– NIST 800-06 PIV Card to Reader Interoperability Guidelines
• Provides interoperability requirements for PIV card readers in the areas of
– Performance
– Communications
• Covers two types of card readers:
– Contact card readers
– Contactless card readers
• Covers both access use cases:
– Physical access
– Logical access.
• Requirements are for PIV readers designed to read end-point cards.

Cryptographic Foundations and Standards for FIPS 201
• Review of Cryptographic Objects in FIPS 201
• Cryptographic Foundations
• FIPS 201 Cryptographic Requirements
• FIPS 201 Certificate Status Information Requirements

Cryptographic Mechanisms Specified in FIPS 201
Asymmetric PIV authentication key
Card authentication key
Asymmetric digital signature key for signing documents and messages
Asymmetric key management key, supporting key establishment or key transport

Cryptographically Protected Objects in FIPS 201, SP 800-73 and SP 800-76
Authentication Information Stored on the PIV Card
The following objects on the PIV card are required to be digitally signed by FIPS 201 and SP 800-73:
– The CHUID
– Biometric information
– The SP 800-73 Security Object
– X.509 Public Key certificates

Public Key Cryptographic Algorithms For Digital Signatures
• Rivest-Shamir-Adelman (RSA)
• Elliptic Curve Cryptography Digital Signature Algorithm (ECC DSA)
Cryptographic Components used with RSA Public Key Encryption
• The following components must be used with RSA in order to be secure:
– A hashing algorithm
– A padding scheme

Rivest-Shamir-Adelman (RSA) Public Key Encryption Algorithm
• An algorithm invented in 1978 based on the difficulty of factoring large integers, which can be used for encryption and digital signatures
• The algorithm is based on a public key which comprises a number N which is the product of two large primes (referred to as the modulus) and another number which is relatively prime
• The algorithm produces a private key, which is the multiplicative inverse of the relatively prime number which is included in the public key which is extremely difficult to calculate
• It is widely believed that the private key is as difficult to as it is to factor the integer N, but it has not been proven to be as difficult

Secure Hash Algorithms (SHA) for RSA
• Because the RSA algorithm requires the use of a hash algorithm, a secure hash algorithm must be used along with RSA
• The SHA family is a set of related cryptographic hash functions that were designed by the National Security Agency
• SHA has two major subsets:
– SHA-1
• Published in 1995
• Was considered to be the successor to the widely used MD5 function
• Vulnerable to known attacks
– SHA-2 (including SHA-224, SHA-256, SHA-384 and SHA-512)
• No attacks have yet been reported
• Because they are similar to SHA-1 researchers are working on more secure hashing standards to use in the event that SHA-2 is compromised

Purpose of Padding Schemes in RSA
• RSA must be combined with a padding scheme for the following reasons:
– To increase message size in order to address the following problems that can occur in short messages:
• Values m=0 and m=1 produce ciphertexts equal to 0 or 1 because of the properties of exponentiation
• Ciphertexts can be easily decrypted by taking the eth root of the ciphertext if using low encryption exponents and small values of m
– To provide a non-deterministic mapping from plaintext to ciphertext in order to defend against chosen plaintext attacks, which deterministic encryption algorithms such as RSA are vulnerable to

Specific Padding Schemes Used for RSA
• Public Key Cryptographic Standard (PKCS) #1 v 1.5
• Padding based on the Probabilistic Signature Scheme (PSS)

PKCS (Public Key Cryptography Standards) #1 v1.5
• Specified in the Network Working Group RFC 2313, Mar. 1998
• The original PKCS #1 standard was subject to chosen and adaptive ciphertext attacks
• PKCS #1 was modified to specify a plaintext-aware padding scheme, meaning that an adversary cannot produce a valid ciphertext without actually knowing the underlying plaintext, which defends against chosen ciphertext attacks
• However, because PKCS #1 v1.5 contains ad hoc constructions, it has not until now been proven secure against adaptive ciphertext attacks according to RSA Laboratories, the holder of the patent for the RSA public key encryption algorithm
• Used by most current implementations of RSA, but not recommended for new applications, for which an Optimal Asymmetric Encryption Padding (OAEP) scheme is recommended

Probabilistic Signature Scheme (PSS)
• A provably secure way of creating signatures with RSA
• Uses hashing in a sophisticated way to tie the security of the signature scheme to the security of RSA
• This is based on the notion that a digital signature scheme is provably secure if its security can be tied closely to that of an underlying cryptographic primitive, in this case RSA
• Developed by Mihir Bellare and Phillip Rogaway in 1996

Cryptographic Components Required For using Elliptic Curve Based Public Key Encryption
• An algorithm based on the difficulty of the discrete logarithm problem for elliptic curve groups
• A hashing algorithm

Elliptic Curve Digital Signature Algorithm (ECDSA)
• A variant of the Digital Signature Algorithm (DSA) that operates on elliptic curve groups
• The discrete logarithm problem is expressed by the problem of solving the following equation where a and c are known:
• ab=c
• An elliptic curve is a plane curve defined by an equation of the form:
• y2=x3 + ax + b
• The solutions to this equation form a finite abelian group
• Elliptic curve cryptography is based on the difficulty of solving the discrete logarithm problem on an elliptic curve group, which is believed to be more difficult than the corresponding problem in the underlying finite field
• It therefore provides smaller key sizes for the same security level, with execution time and signature size exactly the same
• While no proof of the difficulty of ECC has been published as of 2006, it is recommended by the National Security Agency in its Suite B set of recommended algorithms for communication of data with classification levels up to TOP SECRET

Hash Algorithms for ECDSA
• Because Elliptic Curve Digital Signature Algorithm uses a hash function, hash algorithms are required just as they are in RSA
• SHA-224 and SHA-256 are examples of hash algorithms that can be used with ECDSA

Key Management Key Algorithms
The following algorithms are used for key management key management:
• Rivest-Shamir-Adelman (RSA)
• Elliptic Curve Diffie-Hellman (ECDH)
• Elliptic Curve Cryptography Menezes-Qu-Vanstone (ECC MQV)

Diffie-Hellman Key Exchange (foundation for ECDH)
• A cryptographic protocol that allows two parties that have no prior knowledge of each other to jointly establish a shared secret key over an insecure communications channel. This key can then be used to encrypt subsequent communications using a symmetric key cipher.
• Because the parties involved are not known to each other it is known as an anonymous or non-authenticated key agreement protocol.
• It provides the basis for a variety of authenticated protocols and is used to provide perfect forward secrecy in Transport Layer Security (TLS)’s ephemeral modes.
• First published by Whitfield Diffie and Martin Hellman in 1976, although it was developed earlier by Malcolm J. Williamson of the British signals intelligence agency GCHQ, but was at that time classified.

How Diffie-Hellman Key Exchange Works
• An example:
• A and B agree to use a prime number p=23 and base g=5.
• A chooses a secret integer a=6, then sends B the value (g2 mod p) = 56 mod 23 = 8
• B chooses a secret integer b=15 and sends A the value (gb mod p) = 515 mod 23 = 19
• A computes the value (gb mod p)2 mod p = 196 mod 23 = 2, the shared secret
• B computes value (g2 mod p)b mod p = 815 mod 23 = 2, the shared secret
Both A and B have computed the same value because g2b and gb2 are equal. However computing the shared secret given g, p and g2 mod p cannot be done with the best known algorithms if p is a prime of 300 or more digits, and a and b are at least 100 digits long. This is known as the discrete logarithm problem.

Elliptic Curve Diffie-Hellman (ECDH)
• A key agreement protocol that allows two parties to establish a shared secret key over an insecure channel
• The key can be used to encrypt subsequent communications using a symmetric key cipher
• A variant of the Diffie-Hellman protocol using elliptic curve cryptography, which is based on a more complex version of the discrete logarithm problem allowing shorter key sizes for the same degree of security based on known algorithms
• Secure because nothing is disclosed other than the public keys, and extraction of the private key of one of the parties requires solution of the Elliptic Curve Discrete Logarithm Problem.

Elliptic Curve Cryptography Menezes-Qu-Vanstone (ECC MQV)
• An authentication protocol for key agreement (based on the Diffie-Hellman scheme) which was initially proposed in 1995
• Possibly the most efficient of all known authenticated Diffie-Hellman protocols that use public-key authentication
• Provides protection against an active attacker
• Has been shown by Hugo Krawczyk in June 2005 to be vulnerable to attacks in the Canetti-Krawczyk model of key exchange, which was acknowledged by Alfred Menezes in a proposed patch of ECC MQV called HMQV-1 in Nov. 2005
• Specified by the National Security Agency as part of the Suite B set of cryptographic standards for securing US Federal government communications up to the TOP SECRET classification

Algorithms for Card Management Keys
• Triple DEA
• Advanced Encryption Standard (AES)
DEA
• DEA is the Data Encryption Algorithm, also known as the Data Encryption Standard (DES)

Triple DEA
• Triple DEA is a block cipher formed from the DES cipher by using it three times
– Three steps are needed to prevent meet-in-the-middle attacks that are effective against double DES encryption
• Triple DEA requires keys that are 32 characters long and is ANSI standard for PIN management
– 2TDEA is Two Key Triple DEA
• A variant of 3TDEA that uses the same key as the first and third key, but is vulnerable to chosen-plaintext or known-plaintext attacks, giving it an effective security of 80 bits
– 3TDEA is Three Key Triple DEA
• Has a key length of 168 bits comprised of three 56-bit keys, with an effective security of 112 bits.

Advanced Encryption Standard (AES)
• AES, which is also known as Rijndael, is the Advanced Encryption Standard which is viewed as the natural successor to Triple DEA
– AES is around six times faster than TDEA
– AES provides a larger block size, potentially longer keys
– There are as of 2006 no known cryptanalytic attacks on AES, however there have been successful side channel attacks
– The following variants are used in FIPS 201, using the key sizes included in the variant name:
• AES-128
• AES-192
• AES-256

Advanced Encryption Standard (AES) Cipher
• AES operates on a 4x4 array of bytes, referred to as the state
• For encryption, each round of AES (except for the last round) is performed in four phases:
– 1: Each byte of the state is combined with the round key, each round key is derived from the cipher using a key schedule
– 2: Each byte is replaced with another using a lookup table, resulting in a non-linear substitution
– 3: Each row of the state is shifted cyclically a certain number of steps
– 4: The four bytes of each column are combined using a linear transformation
– The last round performs the first rounding step instead of the column combination

FIPS 201 Cryptographic Guidelines
• FIPS 201 Signature Algorithm and Key Size Requirements for PIV Information
• FIPS 201 Public Key Object Identifiers for PIV Key Types
• FIPS 201 Standards for Key Management
• FIPS 201 Hash Algorithm Standards for Message Digests in the NIST 800-73 Security Objects
• FIPS 201 Card Management Keys
• FIPS 201 Certificate Status Information
• Note: Guidelines listed in red are the ones that expire in 2010 due to the security level not being viewed as adequate beyond that date

FIPS 201 Signature Algorithm and Key Size Requirements for PIV Information
• Through 12/31/2010 the following are supported:
– RSA (1024, 2048 or 3072 bits), SHA-1 or SHA-256 hash algorithms, PKCS #1 v1.5 padding scheme
– RSA (1024, 2048 or 3072 bits), SHA-256 hash algorithm, PSS padding scheme
– ECDSA (Recommended Curves, 224-283 bits), SHA-1, SHA-224 or SHA-256 hash algorithms

• After 12/31/2010 the following are required:
– RSA (2048 or 3072 bits), SHA-256 hash algorithm, PKCS #1 v 1.5 padding scheme, PSS
– ECDSA (Recommended Curves, 224-283 bits), SHA-1, SHA-224 or SHA-256 hash algorithms

FIPS 201 Public Key Object Identifiers for PIV Key Types
• PIV Authentication Key, Card Authentication Key and Digital Signature Key may use the following asymmetric algorithms:
– RSA
• The Key Management Key may use the following asymmetric algorithms:
– RSA
– ECDH
– ECC MQV

FIPS 201 Hashing Algorithms for Message Digests in the SP 800-73 Security Objects
• Through 12/31/2010, SHA-1, SHA-224 or SHA-256 may be used
• After 12/31/2010, SHA-224 or SHA-256 may be used
• The specific formats for the Algorithm Object Identifiers are specified in SP 800-76

FIPS 201 PIV Card Management Keys
• PIV cards may support card activation by the card management system to support Card personalization Post-issuance card updates
• The algorithm and key-size requirements for Card Management Keys are:
– Through 12/31/2010, 2TDEA, 3TDEA, AES-128, AES-192 and AES-256 may be used
– After 12/31/2010, 3TDEA, AES-128, AES-192 and AES-256 must be used

FIPS 201 Certificate Status Information
• There are two formats for certificate status information used for the FIPS 201 functional component PIV Card Issuance and Management Subsystem
– X.509 Certificate Revocation Lists (CRLs)
– Online Certificate Status Protocol (OCSP) Status reponse messages

Certificate Revocation Lists
A Certificate Revocation is issued by a Certificate Authority (CA) that also issues X.509 Digital Certificates
A Certificate Revocation List is a list of certificate serial numbers representing certificates that have been revoked and should not be trusted, for one of the following reasons:
– Certificate was revoked by the Certificate Authority (CA)
– A temporary hold has been put on the certificate, possibly because the user believes the private key may have been compromised. The certificate can be later reinstated if the integrity of the private key has been re-established.

Online Certificate Status Protocol (OCSP)
– The Online Certificate Status Protocol is used for obtaining the revocation status of X.509 digital certificates
– Messages are encoded in ASN.1 and usually communicated using HTTP
– OCSP has the following advantages over CRLs:
– OCSP can provide more timely information regarding revocation status of a certificate
– OCSP removes the need for clients to retrieve the CRLs themselves, leading to less network traffic and better bandwidth management
– Clients do not need to parse CRLs themselves, saving client-side complexity
– An OCSP responder may implement billing mechanisms to pass the cost of validation transactions to the seller rather than the buyer
– Not subject to the unnecessary public exposure of CRLs (sometimes compared with credit card companies’ bad customer lists)
– Supports trusted chaining of OCSP requests between responders, allowing clients to communicate with a trusted responder to query an alternate responder, saving client-side complexity

Certificate Status Information Digital Signature Requirements
• Certificate status responses are required to be digitally signed to support authentication and integrity using the following standards, using algorithmic identifiers specified in SP 800-78:
– Through 12/31/2010, the following may be used:
• RSA (1024, 2048 or 3072 bits), SHA-1 or SHA-256 hash algorithms, PCKS #1 v1.5 padding scheme
• RSA (1024, 2048 or 3072 bits), SHA-256, PSS padding scheme
• ECDSA (Recommended Curves, 224-283 bits), SHA-224 or SHA-256 hash algorithms

– After 12/31/2010, the following are required:
• RSA (2048 or 3072 bits), SHA-1 or SHA-256 hash algorithms, PKCS #1 v1.5 or PSS padding scheme
• ECDSA (Recommended Curves, 224-283 bits), SHA-224 or SHA-256 hash algorithms

SOA Security, Identity 2.0 and Convergence

The convergence occuring between SOA, Ubiquitous Computing, Grid Computing, the Semantic Web, and Agent-Based Computing is being mirrored in the identity management area. I think it's all part of the same convergence, but am not sure what it will all be called once it is univerally recognized.

In the U.S. Federal Government, there is convergence happening between the E-Authentication Initiative and the efforts to implement HSPD-12 that requires implementation of a common identification system for Federal employees and contractors. With the convergence between Shibboleth, an E-Authentication Federation certified open source platform, and OpenID, an open-source identity federation, the possibility of convergence between the Federal and private sector is presenting itself. In October 2006, Identity 2.0 players from Microsoft and SxipIdentity were engaged in vigorous debate in their blogs about the differences between Microsoft's CardSpace(TM) and OpenID. A crucial topic of this debate was the vulnerability of the OpenID protocol to phishing attacks, in which a malicious web site pretends to be a legitimate participating site but is really attempting to get users to give up personal information. On Feb. 5, 2007, an Apache Authentication Module for CardSpace was made available for download [35]. On Feb. 6, 2007, there was an announcement made by the four companies Microsoft, Verisign, SxipIdentity and JanRain that their organizations would be collaborating, and specifically that Microsoft would be supporting OpenID in its identity management products. On Feb. 7, 2007, online identity provider ClaimID made a change in strategy to become the OpenID provider of choice. On Feb. 9, 2007 a demonstration of OpenID and CardSpace interoperability was presented at the Microsoft RSA Conference.

Convergence

The first wave of convergence on the Internet resulted in the World Wide Web. It was based on the convergence of technologies that had been in existence for years, that converged as an emergent property of the elegant invention, the URI, which is as simple and profound as Einstein's famous equation. The URI, HTML and HTTP together resulted in a transformed global economy, and profoundly altered the relationship between people and information. This first wave was a revolution in the delivery of information, the surface of the World Wide Web and of the global economy.

There is a second wave of convergence happening and it is happening on multiple levels. One of the levels is based on the emergent properties of XML and it's simple extension, SOAP, added to the foundation of the World Wide Web. This wave is transforming the plumbing of the Web and the global economy by making the virtual organization possible. As the technological foundation becomes more simple, the real-world application of the technology becomes more fluid and powerful. Technology is moving toward the minimization of itself as a barrier to the performance and management of business transactions.

One of these levels of convergence is in identity management. Let's look at the nuts and bolts. First, let's take a tour of the ideas and tools behind the notion of Identity 2.0, looking at OpenID, SXIP/DIX, Microsoft's CardSpace, LID and ClaimID. Then we'll look at the tools being used to express identity information including FOAF, XFN, hCard and RDF/vCard.

Identity 2.0

Identity 2.0 is an identity management model that has been created to give online interaction the same properties as real work interaction. It has the goals of

1. Reducing the number of registration forms that users need to fill out, which will reduce the enormous cost and effort previously required to provision new users for Web resources.

2. Limiting the amount of extra navigation required by users in order for them to share identity information· reducing the need for users to access services in a deferred manner (that occurs when a user has to wait for an E-mail response before accessing a resource).

3. Eliminating the existing limits on the identity information that a user can share.

Identity 2.0 provides users with the online equivalent of a driver's licesnse or passport, but allows them to decide which information that they want to share with whom. The following are the central ideas in Identity 2.0:

1. It is user-centric rather than permission-centric.

2. It has a concept of identity as a declarative group of claims and can include things like phone number, E-mail address but also things like customer service history, interests, social relationships and other attributes not traditionally found in user profiles in previous identity models.

3. It has a decentralized trust model based on URL ownership rather than the previous trust model based on centralized identity providers.

There are a number of Identity 2.0 identity technologies. There are URL based identity technologies, where a user's identity is associated with a URL, including XRI/i-name and OpenID. There are also token based identity technologies, where a user's identity is associated with a token, including CardSpace, SXIP, Higgins and Liberty.

In Identity 2.0, reputation based on identity is a currency used to acquire trust relationships.

Doc Searls in [33] describes a view of the Creative Commons as Creator Relationship Management, and how Identity 2.0 ideas can make creative collaboration between trusted parties as frictionless as possible. Kim Cameron of Microsoft thinks this is a "whole new creater-consumer model" [34].

XRI

Now let's look at a new relative of the URI that is one of the tools, besides URIs and URLs, that are being used to express and manage identity information in Identity 2.0 technologies.

An XRI (eXtensible Resource Identifier) is a privacy-aware, portable and persistent identifier for a resource which can be a person, organization, application, or idea. XDI (XRI Data Interchange) provides the ability to leverage XRIs to exchange, reference and update data between entities and maintain data exchange relationships. XRIs come in several flavors, including i-names, i-numbers, and i-tags.

An i-name is an internet address for a person. It provides a lightweight and safe way to authenticate and provide personal data, keep that personal data up to date and keep it private. It is important not to associate an i-name as a means of authentication only. For example, by using an i-name to provide contact information, a person can make sending spam E-mails extremely difficult. Microsoft's Identity 2.0 guru Kim Cameron claims to have used an i-name for several years without receiving any spam. An i-name is like a domain name in that it can be reassigned to a different resource by the i-name's owner. Each i-name corresponds to a non-reassignable i-number. An example of an i-name is =Andrew.Wilson which resolves to the URL http://xri.net/=Andrew.Wilson.

An i-number is an identifier for a resource which could include a person, organization, or file, which is not ever reassigned or transferred. For as long as the resource is available on the network, it can be addressed using its i-number.

An i-tag is an extensible, author-verifiable, which gives the author control over the tag dictionary that the tag should be resolved with, and provides dictionary services with the ability to provide services for tag authors and searchers. One use for an i-tag is to associate license information with digital content.

An i-broker is a provider of i-names. The owner of the entity referred to by an i-name need only be known to the i-broker. Examples of i-brokers include http://www.2idi.com/, the first i-broker, and http://http://www.iwantmynamenow.com.

OpenID

OpenID is a distributed digital identity system, in which a user's identity is represented as a URL or XRI. Any server that runs the OpenID protocol can verify the user's identity, providing a secure single sign-on for users of multiple Internet sites. Users do not need new accounts for each site, they only need an account with a trusted site, referred to as an identity provider, idP, or i-broker, which provides sites that run the OpenID protocol with the user's identity information.

These OpenID enabled web sites are referred to as relying parties or RPs. The OpenID protocol does not require a specific authentication protocol. In order to support sites containing sensitive data such as account or transaction information, these sites need to rely on identity providers that require strong authentication such as X.509 digital certificates, which are based on strong encryption. OpenID is supported by organizations that include Wikipedia, Technorati, Verisign and Microsoft. OpenID works a little differently from the familiar username and password that most users are familiar with.

1. An OpenID-enabled relying party, the site that the user wants to use, will have a login form with a single text box for the user to type in an OpenID indentifier. The relying party requests an XRDS document, which is sometimes referred to as a Yadis document from the identity provider, which contains proof that the identity provider asserts that the user is the one identified in the XRDS document. There are two operational modes for OpenID, checkid_immediate and checkid_setup. In the checkid_immediate operational mode, the identity information is exchanged between the relying party and the identity provider as a background task, requiring no user intervention. In the checkid_setup operational mode, the user communicates with the identity provider using the same web browser that they are seeking to access the relying party web site with. Depending on the security policy of the identity provider and relying party, they may establish an associate handle, a type of shared secret, saved by the relying party. The most common implementation of the associate handle is as a Message Authentication Code (MAC) conforming to the RFC1750 recommendations.

2. If the user is not already logged in to the identity provider, it will typically ask the user for a password, and ask whether the user trusts the relying party to receive the user's identity information. If the answer is negative, then the relying party is informed that the request for authentication is being rejected, and the relying party will deny access to the user.

3. If the user provides the password and answers in the affirmative that the relying party is trusted to receive identity information, then the identity provider replies to the relying party with the user credential information in the form of an XRDS (Yadis) document. If the relying party and identity provider have a previously established shared secret, then that shared secret is used by the relying party to validate that the credential information came from the identity provider and not some other entity, and the relying party grants access to the user.

4. If the relying party and identity provider do not have a shared secret, another step is required, called check_authentication which is done to ensure that the identity information did come from the identity provider.

HMAC-SHA1 and HMAC-SHA256 are the supported as signature algorithms. The latter is recommended in the OpenID 2.0 specification, and would be required for usage by any U.S. Federal Government application since it is FIPS 180-2 compliant, which HMAC-SHA1 is not due to the vulnerability of the underlying SHA-1 algorithm.

Because the OpenID protocol works well with AJAX, it is possible for this entire brokered authentication process to occur without the user leaving the relying party web page, unlike the browser redirects involved in other Federated identity approaches such as the E-Authentication architecture.

Users can use one of four methods to express their identity in OpenID. They can present a URL that is under their own control, which could be a home page or blog, to which they have added OpenID tags. They can present a URL received by registering with an OpenID identity provider. They can use an i-name, which is a reassignable synonym for an i-number. Whether the user chooses to use an i-name or i-number when using an XRI to express their identity, there is an underlying, un-reassignable i-number, which ensures that the user's identity cannot be taken over the way a DNS name can be taken over.

There is an OpenID Attribute Exchange specification which is under development to extend the OpenID framework beyond authentication. This could be used to implement the standard Role Based Access Control (RBAC) security pattern, or even more sophisticated access control using security context specific or transaction specific authorizations.

A part of the convergence is happening is that OpenID has already absorbed two technologies, the Simple eXtensible Identity Protocol (SXIP) and the Digital Identity Exchange (DIX) into the OpenID 2.0 Specification.

SXIP/DIX

SXIP, like other URL based identity protocols, allows for a decentralized model of identity management. SXIP has two types of participating sites, homesites and membersites. A homesite provides users and other sites the ability to control the data that they release to other sites. In the common nomenclature for federated identity systems, a homesite is an identity provider. Membersites are consumers of identity data used to provide access to services. Membersites send user identity requests to homesites through the user's browser. Membersites can discover dynamically a user's identity without having an existing relationship with a homesite. The discovery service points to the homesite in SXIP rather than the user's identifier. SXIP supports the exchange of third party claims and reliable updates to identity information that has been provided to membersites. SXIP has a separation between the authority for an identity assertion and the release of that assertion, eliminating the need for a homesite to process assertions every time they are requested by membersites. The following steps occur when a user connects to a membersite for the first time using SXIP 2.0:

1. The user types a homesite path into the type-in field next to a button labeled "sxip in" on the membersite page.

2. The user's browser is redirected to the homesite, which prompts the user to enter login information.

3. The user enters a username and password, and is presented with a logo representing the membersite indicating that the membersite is requesing their identity data.

4. The user selects a Persona from a set of Persona that they have established on the homesiste, which is represented by a URL, and verifies that the information contained in the person is correct.

5. The user selects whether the data contained in their Persona will be automatically shared with the membersite whenever they visit it again.

6. The user confirms that their identity information can be released to the membersite.

7. The user's browser is redirected to the membersite.

8. The membersite grants access to the user.

Through the use of the Persona, SXIP provides the user with the ability to decide which information they want to share with membersites.

When a SXIP user accesses a membersite on subsequent visits, the following steps generally occur:

1. The membersite accesses a cookie identifying the user's homesite.

2. The membersite displays the homesite that the user has already authenticated with.

3. The user clicks the button labeled "sxip in", if they want to access the membersite using the homesite whose homesite path is displayed.

4. The membersite grants access to the user.

CardSpace

Windows CardSpace is an identity metasystem, a digital identity framework which allows transaction-based identity. It is a component of Microsoft's initiative to create an identity metasystem. CardSpace rests on a foundation of WS-Security, WS-Trust, WS-SecurityPolicy and WS-MetadataExchange, and will run on any platform that supports those standards. CardSpace is part of Windows Vista and is also included in the .NET Framework 3.0. It supports both self-issued and managed identities, similar to OpenID. In order to authenticate using a CardSpace managed identity, a Security Token Service must be used that generates signed, encrypted tokens conforming to the WS-Trust standard.

Identities are stored as InfoCards in CardSpace. InfoCards are the digital equivalent to the physical identification cards stored in many people's wallets. The following steps occur when a CardSpace user browses to an InfoCard authentication compatible resource.

1. A modal dialog appears giving the user a choice of which InfoCard to present to the site that is asking for authentication. Because the dialog is modal, it prevents the user from browsing to another site (perhaps a phishing site) until the authentication process has completed.

2. The user decides which InfoCard to present and selects it.

3. The CardSpace InfoCard manager presents the user's identity information to the site that is asking for authentication.

4. The site grants access to the user.

The principal impetus behind the convergence of OpenID and CardSpace is the privacy and anti-phishing support provided by CardSpace.

The Higgins Trust Framework

The Higgins Trust Framework is an open-source, cross-platform framework for exchanging identities. It is an identity card selector like Microsoft's CardSpace. It supports the exchange of profiles and social relationships as well. The Higgins framework is user-centric, and was created to empower users with control over their identities, relationships and personal data. Users, rather than others, are in control of their data in the Higgins framework, and can decide what information they want to divulge when to trusted systems of their choice. Being API based it supports both browsers and rich clients, and has been designed with an SOA approach. It originated with SocialPhysics.org and is supported by IBM and Novell. Within the framework, a Context consists of a set of Digital Subjects, each possessing a Contextually Unique Identifier (CUID), which itself is an Identity Attribute. Optionally, the context might also have a Security Policy. A Digital Subject is a set of Identity Attributes. A given entity, which can be a person, may have multiple identities represented as Digital Subjects within the same context, or spread across multiple contexts.

An I-Card is a visual presentation of a Digital Subject which contains identity information. Just as a person may have different identity cards for different social contexts if they so choose, an entity can have multiple I-Cards to be used for purposes of their choice, including authentication. An I-Card comes from an I-Card provider, which may be a CardSpace compatible managed or personal providers, or a URI managed or personal provider.

XDiggins is the convergence of the Higgins Trust Framework and XDI.

OpenID, Phishing, idproxy and CardSpace

idproxy is a tool created by to allow users to access OpenID relying parties using their Yahoo! credentials. It also provides two added protections against phishing attempts. One is that an idproxy user selects a "Monster" which will greet them by name when they log in to idproxy. Because of the unlikelihood of a would-be phisher guessing which monster the user selects, it provides an extra layer of protection. In addition, rather than redirecting users to a relying party site with a login page, idproxy users are expected to browse to idproxy.net rather than using a login form on a site that the user is redirected to. This is one solution to the OpenID phishing problem.

Another approach to solving the OpenID phishing problem was proposed by Charles Drake, which is to have an Identity Provider authorize by using the user's static IP address rather than by issuing a password request. He also notes that authenticating with a browser certificate would also suffice. In either instance, there is no need to provide secret information which can be used by an unfriendly relying party.

Gabe Wachob in [26] made an important assertion about OpenID that relates to the SOA concept of Sofware as a Service (SaaS), when he urged that there be a distinction made between projects that aim to provide innovative approaches to authentication, such as the examples he provides, Mozilla/Firefox, Microsoft CardSpace and VxVsolutions, and projects that aim to provide innovative online services. This mirrors exactly the movement toward independence between security services and business services in SOA.

Microsoft's Kim Cameron outlines how OpenID and CardSpace can be integrated in [27], by having the user login using an identity selection tool such as CardSpace, which being part of the Windows desktop would not be susceptible to phishing attacks. This has resulted in the interoperability support for OpenID and CardSpace.

Another tool that allows users to login using OpenID, i-names or CardSpace is Whobar.

LID

Light-Weight identity (LID) is a set of digital identity management protocols which is compatible with underlying protocols including OpenID and Yadis. It is a RESTful technology, operating completely within a user's browser. LID is used for services including single sign-on, message authentication, contact management, social networking and publishing information so that access is only granted to trusted entities. Cryptographic proof is used to establish identity using OpenID or GPG.

Yadis

Yadis is the underlying service discovery layer which is the foundation for OpenID, and is also supported by LID. It is a key to interoperability, allowing discovery for different types of identity expressions including i-names, OpenID URLs, LID Ids, or Sxip Ids. The following steps occur in a the service discover process in Yadis.

1. A Yadis ID is presented.

2. The determination is made whether the Yadis ID is an XRI (such as an i-name), URL or other type of token.

3. A Relying Party Agent makes an HTTP request using the Yadis ID, and obtains either a Yadis document or the URL for a Yadis document.

4. A Yadis Resource Descriptor is extracted from the Yadis document, which contains a description of services available and which services can authenticate a user.

SAML 2.0 Enhanced Client or Proxy Profile

The SAML 2.0 Enhanced Client or Proxy (ECP) profile provides a foundation for identity metasystems for SAML consumers such as Web services using the WS-Security SAML Authentication profile. This is a way for SAML to leverage the user-centric identity management ideas for Identity 2.0. The following steps occur in an access to a resource using the SAML 2.0 ECP.

1. The SAML Principal, using the ECP, issues an HTTP request to a Service Provider for gaining access to a protected resource, for which there has not been already established a security context for the Principal and ECP.

2. The Service Provider issues an Authentication Request to the ECP, which is then delivered by the ECP to an appropriate identity provider. The SAML Reverse SOAP (PAOS) binding is used for this.

3. The ECP retrieves the endpoint location to an identity provider.

4. The ECP passes the Authentication Request to the identity provider.

5. The identity provider retrieves identification of the Principal.

6. The identity provider sends a Response message to the ECP using the SAML SOAP binding.

7. The ECP passes the Response message to the Service Provider.

8. The Service Provider grants or denies access to the service.

Using this approach, Web services can be accessed using SAML 2.0 with user-controlled and managed identities or personal information.

For certificate-based authentication for Web services using the WS-Security X.509 Digital Certificate profile, a way for the user to manage and select digital certificates is needed.

RDF

The Semantic Web is being used as a foundation for many of the tools being used to manage personal data on the Web. The Resource Description Framework (RDF) language is used to represent information about resources. RDF is based on XML. Unlike most data represented in XML that is structured in a hierarchical tree format, RDF represents data that is stored as a graph, meaning that there can be cycles or loops in the data model. The uses of RDF are numerous. It is used to provide data that can be machine processed in contexts other than the original context that it was created for, with the intention of making the World Wide Web as accessible to computer programs such as spiders, agents and bots as it is to human users. It is used to provide Web metadata such as privacy preferences, content rating, descriptions of capabilities. It is used for applications that require open information models such as annotating Web resources, collaborative scheduling of activities, and collaborative process description. It is also used for combining data from multiple applications to create new information. RDF can be used for the purposes of representing identity and other personal data. RDF is used to associate information with a URI representing the entity being described. The information about the entity is expressed in one or more RDF vocabularies, using a namespaces identified by other URIs.

Now that we have looked at the emerging identity federation tools from an application-centric point of view, let's looks at the tools available for users to control their own personal information.

FOAF

Friend of a Friend (FOAF) is a collaborative RDF metadata vocabulary about people, relationships and interests, and can include image, contact and geographic metadata using properties and established RDF vocabularies. It can be used in applications such as contact databases, address books, virtual communities and organizational directories. From an identity management point of view, these are all identity attributes. FOAF enables users to create their Semantic Web home page equivalent. FOAF provides the ability for the user to publish E-mail address contact information encoded using the SHA-1 secure hash algorithm, using a property calles foaf:mbox_sha1sum. People are identified in FOAF using the OWL (Web Ontology Language) concept of an Inverse Functional Property (IFP). These IFPs include E-mail addresses and home page addresses. The foaf:depicts property is used to associate images with people.

Out of the box, FOAF allows other people to associate information with a person, so there is a need to validate whether the personal data was in fact provided by the person in question. In order to securely associate an author with an FOAF file, files are signed with digital signatures generated using the Pretty Good Privacy (PGP), which establishes a connection between the file and the owner of the private key corresponding to the public key used to validate the signature, and prevents tampering of the file by anyone who does not possess the private key. Users protect private FOAF information by encrypting the data with PGP, using the public keys of people or entities that they wish to make the private data available to. While FOAF empowers users with control over their own personal information, it requires hand crafting and requires encryption of private data for each intended recipient. There clearly is a need for the ability for non-HTML savvy users to make use of this kind of privacy protection, and a tool called FOAF-a-Matic has been created for this purpose. However, FOAF-a-Matic might be enhanced to include PGP signing and encryption in order to provide the ability for the general public user to take full advantage of the privacy protection available through the use of PGP with FOAF. Another enhancement that may be useful is the concept of privacy categories or levels. For example, a user might want to make certain information available only to specific entities, but might want to make other information available to members of some group. In a business situation a user may want to provide home or cell phone numbers and private E-mail addresses only to specific people, but provide work phone and E-mail to all members of the same organization, which could be a company, SIG, or professional organization such as IEEE or PMI. FOAFBot is a tool for spidering FOAF files for a community application (it was created to support IRC), which can leverage PGP to allow only a specific trusted organization to see private data for dissemination within that group.

XFN

The XTHML Friends Network (XFN) is a very simple, lightweight way for people to specify relationship information using HTML, XHTML or XML attributes. This information is intended to make sense to both humans and computers. For example, a user can specify a relationship in their blogroll by including a rel attribute such as this:

rel="contact"

There is also the ability to specify finer-grained relationship information:

rel="contact met"

The rel="me" attribute value is used to designate links to an individual's own personal data. While XFN can be used to link web resources from any HTML, XHTML or XML document, it's primary use is for blogrolls. In XFN, information is controlled by the author and there is no method of confirmation that relationships are two-way. While it does not have any integrity or privacy protection itself, XFN can be used in conjunction with FOAF to provide security for the user. The advantage of this for the user is the ability to specify finer-grained relationship information. Business uses for this technology can include tracking customer relationships and technical and professional contacts online.

hCard

hCard is a semantic XHTML format for representing the elements of the vCard specification. It is an open microformat standard which can be included in XHTML, HTML, Atom, RSS and XML formatted data. A vCard is a digital business card, and contains information such as name, address, E-mail addresses, telephone numbers, images, logos, audio clips and other information. The vCard specification is used in Apple's MacOS X address book.

vCard/RDF

vCard/RDF is another way users can control their personal information on the Semantic Web. The RDF vCard specification establishes a namespace which contains the property types and values that had been previously specified in the vCard specification.

There does not seem to be much consideration given to privacy in the vCard and vCard/RDF specifications, however. For this reason, while vCard was created as a business-centric specification, the privacy and integrity functionality of FOAF might make it seem a better choice.

Convergence

The company PingIdentity, who presented the demo of interoperability between OpenID and CardSpace an RSA show on Feb. 9, 2007, proposes an Identity Metasystem which allows an interoperable framework preserving the advangates of SAML, OpenID, CardSpace and WSF. They hope to see a convergence that eliminates duplication between the different protocols, without eliminating any of the unique value provided by each of them. In their view, SAML's advantages are in terms of robust privacy and security models, vendor interoperability and broad scope. CardSpace has the advantages as they see it of being part of the Windows desktop and the elimination of password management. For OpenID, they recognize a lightweight trust model as the default, simplicity and facile integration as advantages. Finally they feel that ID-WSF has the advantages of offline use cases, distributed identity services and a malleable security model.

References

[1] Connolly, Dan, A Look at Emerging Web Security Architectures from a Semantic Web Perspective, DRAFT in progress, 2006.
URL: http://www.w3.org/2006/03dc-aus-lga/swauth
[2] http://en.wikipedia.org/wiki/OpenID
[3] OpenID Authentication Specification 2.0, Draft 11, http://openid.net/specs/open-id-authentication-2_0-11.html
[4] PingIdentity.com, Internet Scale Identity Systems: An Overview and Comparison, Jan. 7, 2007,
http://www.pingidentity.com/InternetIdentity010707b.pdf
[5] http://www.w3c.org/p3p
[6] http://www.foaf-project.org/
[7] http://www.ldodds.com/foaf/foaf-a-matic.html
[8] http://usefulinc.com/foaf/foafbot/
[9] Dawson, F. and T. Howes, vCard MIME Directory Profile, RFC 2426, Sept. 1998 ftp://ftp.isi.edu/in-notes/rfc2426.txt
[10] Alden, Roland, et. al., vCard: The Electronic Business Card Version 2.1, 1996, http://www.imc.org/pdi/vcard-21.txt
[11] Representing vCard Objects in RDF/XML, W3C Note 22 February 2001, http://www.w3c.org/TR/vcard-rdf
[12] http://gmpg.org/xfn/
[13] Meyer, Eric. A., XFN and FOAF, GMPG, 2003-2007, http://www.gmpg.org/xfn/and/foaf[14] http://microformats.org/wiki/hcard
[15] http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/
[16] http://www.sxip.net/downloads/sxip2-overview.pdf
[17] Hinchecliffe, Dion, How Can We Best Make "The Writeable Web" A Responsible Place, SOA World Magazine, Jan. 23, 2006,
http://soa.sys-con.com/read/173822.htm
[18] Cote, Michael, Identity 2.0, Trustless Redirects, OpenID, LID, and Friends…or, Learning to Spell 'Centralized', blog entry,
http://www.redmonk.com/cote/2006/04/20/identity-20-trustless-redirects-openid-lid-and-friendsor-learning-to-spell-centralized
[19] Goodin, Dan, Web Services Security Standards Aren't Enough, InfoWorld, 11-24-2006, http://www.infoworld.com/article/06/11/24/48FEwssecstand_1.html
[20] Seely, Rich, SAML 2.0 meets Web 2.0, SearchWebServices.com, 29 Nov. 2006,
http://searchwebservices.techtarget.com/originalContent/0,289142,sid26_gci1232137,00.html?track=sy80
[21] Willison, Simon, Solving the OpenID Phishing Problem, blog entry, 1-19-2007,
http://simonwillison.net/2007/Jan/19/phishing/
[22] Laurie, Ben, OpenID: Phishing heaven, blog entry, 1/19/2007, http://www.links.org/?p=187
[23] Drake, Charles, A simple solution to OpenID phishing attacks, Digital Consumption, blog entry, 23 Jaun. 2007,
http://digitalconsumption.com/forum/A-simple-solution-to-OpenID-phishing-attacks
[24] Cameron, Kim, Identity Weblog, 20 Jan. 2007, http://www.identityblog.com/?p=657
[25] Cameron, Kim, Identity Weblog, 20 Jan. 2007, http://www.identityblog.com/?p=656
[26] Wachob, Gabe, Digital Identity and Beyond, Weblog
[27] Cameron, Kim, Integrating OpenID and InfoCard - Part 1, Identity Weblog, 21 Jan. 2007,
http://www.identityblog.com/?p=659
[28] Hardt, Dick, Whobar, 2006, Sxip Identity Corp., http://whobar.org/
[29] 2idi Help/FAQ, http://2idi.com/welcome/help
[30] Cameron, Kim, I-Cards and CardSpace, Identity Weblog, 1/26/2007, http://www.identityblog.com/?p=664
[31] Dale, Andy, The Tao of XDI, Weblog, 1/25/2007,
http://xditao.blogspot.com/2007/01/i-wrote-this-missive-in-email-thread.html
[32] Drummond, Reed, Mary Hodder, Andy Dale and Kaliya Hamlin, ed., I-Tag Specification Working Draft 03, April 2006, http://www.itags.net/index.php/I-Tag_Specification_Working_Draft_03
[33] Searls, Doc, Putting the Wholes Together, weblog, 2/5/2007, http://www.linuxjournal.com/node/1000180
[34] Cameron, Kim, Doc Searls on Creator Relationship Management, Identity Weblog, 5 Feb. 2007, http://www.identityblog.com/?p=667
[35] Jain, Aashish, Apache Authentication Module for CardSpace, weblog, Feb. 5, 2007, http://itickr.com/index.php/?p=56
[36] http://lid.netmesh.org/wiki/LID_Features_and_Benefits
[37] OASIS, Profiles for the OASIS Security Assertion Markup Language V2.0, 2005, http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf