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
No comments:
Post a Comment