Recent Changes - Search:


Admin & Tools

Mobile Networking

edit SideBar

UniK, Kjeller



Identity is simply a collection of characteristics which are either inherent or are assigned by another. These characteristics might include, among other things, the unchanging physical traits of the person, his preferences, or other people's perceptions of the individual's personality.

Real world identity

People already have lots of physical identities in the real world. That physical identity is the one that owns their bank accounts, that goes to work at their employer, that shops at, and to which the government issued their passport. We are also carrying other identities, such as; Student IDs, representing ourselves as students of certain institutes; driving license, represents us as authorize persons to drive. We are using bunch of user names/ passwords to log into our yahoo, msn, other web mails, skype etc. Each of these organizations already maintains a digital profile of information relating to that physical individual.

Laws of identity

Kim Cameron of Microsoft came out with a white paper called "The Laws of Identity". "The “Laws of Identity” are intended to codify a set of fundamental principles to which any universally adopted, sustainable identity architecture must conform. The laws define the architecture of the identity meta system. They are,

1. User control and consent: Identity system must only reveal information identifying a user with the user’s consent.

2. Minimal disclosure for a constrained use: The identity system must disclose the least identifying information possible, as this is the most stable, long-term solution.

3. Justifiable parties: Identity system must be designed so the disclosure of identifying information is limited to parties having a necessary and justifiable place in a given identity relationship.

4. Directed identity: A universal identity system must support both “omnidirectional” identifiers for use by public entities and “unidirectional” identifiers for use by private entities, thus facilitating discovery while preventing unnecessary release of correlation handler.

5. Pluralism of operators and technologies: A universal identity solution must utilize and enable the interoperation of multiple identity technologies run by multiple identity providers.

6. Human Integration: Identity system must define the human user to be a component of the distributed system, integrated through unambiguous human-machine communication mechanisms offering protection against identity attacks.

7. Consistent experience across contexts: The unifying identity metasystem must guarantee its users a simple, consistent experience while enabling separation of contexts through multiple operators and technologies.

Identity 1.0

Figure 1. Identity 1.0
  • Identity 1.0 is directory centric.
  • Web sites or resources are placed at the middle.
  • There is symmetric and somehow an opaque trust relationship in it.
  • There is no credential choice and it is not portable either.
  • It is not simple and user friendly.
  • It is an expensive solution as an identity silo with high security is required to maintain here.

It did not serve the purpose. People require simple, transparent, user friendly and mobile identity that can mimic the real world identities.

Identity 2.0

A new revolutionary digital identity, Identity 2.0 has been introduced to meet these requirements. The term Identity 2.0 was made popular by Dick Hardt at The first Web 2.0 conference October 2004. Preliminary principles were drawn.

Figure 2. Identity 2.0
  • Identity 2.0 is user centric. It means, the user is in the middle of a data transaction. This does not mean the user has to approve every transaction, but that the data always flows through the user’s identity agent. This does have user control and consent advantages.
  • User control their identity and what attributes of users want to share.
  • With identity 2.0 each and every company and website wouldn’t need its own silo or security platform (which is expensive).
  • It supports single sign-on and user can move their identity from any site to any site.
  • It is simple, open and flexible
  • It has decentralized mechanism.
  • It maintains asymmetric and transparent trust relationship.

Web 2.0

O'Reilly Media coined the phrase Web 2.0 in 2004 to refer to a supposed second-generation of Internet-based services that let people collaborate and share information online in perceived new ways — such as social networking sites, wikis, communication tools, and folksonomies.The concept of "Web 2.0" began with a conference brainstorming session between O'Reilly and MediaLive International.

Figure 3. Web 2.0 meme map

Figure 3 shows a "meme map" of Web 2.0 that was developed at a brainstorming session during FOO Camp, a conference at O'Reilly Media. Like many important concepts, Web 2.0 doesn't have a hard boundary, but rather, a gravitational core. You can visualize Web 2.0 as a set of principles and practices that tie together a veritable solar system of sites that demonstrate some or all of those principles, at a varying distance from that core. It's very much a work in progress, but shows the many ideas that radiate out from the Web 2.0 core. Proponents of the Web 2.0 concept say that it differs from early web development (retrospectively labeled Web 1.0) in that it moves away from static websites, the use of search engines, and surfing from one website to the next, towards a more dynamic and interactive World Wide Web. The retrospectively-labeled "Web 1.0" often consisted of static HTML pages, rarely (if ever) updated. They depended solely on HTML, which a new Internet user could learn fairly easily. The success of the dot-com era depended on a more dynamic Web (sometimes labeled Web 1.5) where content management systems served dynamic HTML web pages created on the fly from a content database that could more easily be changed. In both senses, so-called eyeballing was considered intrinsic to the Web experience, thus making page hits and visual aesthetics important factors.

Proponents of the Web 2.0 approach believe that Web usage has started increasingly moving towards interaction and towards rudimentary social networks, which can serve content that exploits network effects with or without creating a visual, interactive web page. In one view, Web 2.0 sites act more as points of presence, or user-dependent web portals, than as traditional websites.

General characteristics- While interested parties continue to debate the definition of a Web 2.0 application, they generally accept that a Web 2.0 website would exhibit some basic characteristics. These include:

  • "Network as platform" — delivering (and allowing users to use) applications entirely through a web-browser.
  • Users own the data on the site and can exert control over the data.
  • An architecture of participation and democracy that encourage users to add value to the application as they use it.
  • A rich, interactive, user-friendly interface empowered by Ajax.
  • Some social networking aspects.

Organisations Involved

  • Sxip
  • Microsoft
  • Liberty Alliance
  • YADIS - distributing my security
  • OASIS (SAML ~ Idenity 1.5)



Figure 4. Sxip

Figure 5. Sxip

The internet has not made it easy for individuals to provide data to websites. As a result websites lose many potential customers, because they are not provided with convenient access the services they want. Key problems that users currently face include:

  • Tedious registration forms.
  • Confusing navigation.
  • deferred access to services, for example through interrupted processes that require users to wait for an email in order to access access a website's content.
  • Limitations on the kind of data they can provide.

In addition, website cannot determine whether or not the data they collect is relaible, because impatient users often enter nonsense into online forms. Websites are also limited in the kind of data they can request, and as a result are not able to provide services that many users require.

To mitigate these problems, many organizations are considering different models of identity management. One such model, Identity 2.0, proposes an internet-scalable and user-centric identity architecture that mimics real world interactions. The Simple eXtensible Identity Protocol (SXIP) was designed to address the principles defined by Identity 2.0 model.

How SXIP works- Identity data is one or more pieces of information that individuals can associate with themselves. This can include anything from a name, address and phone number, to physical attributes like height, weight and gender, to an individual's reputation as a participant in online communities. In SXIP 2.0, each piece of identity data is called a property.

SXIP 2.0 entities- User choice is at the core of the design considerations for SXIP 2.0. As with real world interactions, the manner in which an exchange of identity data occurs can have a tremendious effect on the choices that are made. The entities involved need to aware of certain information, including who the other entities are and the kind of data that is being exchanged. Figure 4 shows the relationship between the core SXIP 2.0 entities invloved in exchanging identity information.

Homesite- Homesites are websites or applications that facilitate the online exchange of identity data between users and other sites by providing them with choice in the data that they release to other sites.

Membersite- Membersites are typically websites that consumes identity data in order to provide services. With SXIP 2.0, a Membersite sends requests for user identity data to a homesite, via the user's browser.

User- Users are individuals who manage the exchange of their identy data via their client, typically a web browser. Users are able to store the data in an identity profile at a Homesite and release data in response to request from Membersites. With SXIP 2.0, users associate their identity data with one or more personas. For example, a user might have a work persona and home persona, each containing a set of properties about the user, such as their name, phone number. In the SXIP protocol, a user's persona is represented by a persona URL.

Users are able to create an identity profile at a homesite where Identity data is stored with user’s personas. The Sxip network rootsite, an authority for the Sxip network is responsible for issuing unique identifiers for those personas. The data is released from homesite in response to request from membersites upon user’s consent. SXIP 2.0 makes it easy for users move the location of the identity data stored with a persona, without loosing the identifier associated with the persona. SXIP uses two-factor authentication solution to access services, like, online bank, which requires strong authentication mechanism. By adding homesite functionality a website can provide authentication and identification of users. SXIP is created especially for internet domain. Microsoft:

Figure 6. Cardspace

Figure 7. Cardspace identity selection screen

Life would be simpler if a single digital identity, represented with a single security token format, could be used for everything. Yet for the same reasons that we have different identities in the physical world, we will always have different identities in the digital world. The challenge is to create, use, and manage these diverse digital identities in an understandable and effective way. This is exactly the problem that the identity metasystem addresses. Rather than invent yet another technology for creating and representing digital identities, the identity metasystem instead provides a consistent way to work with multiple digital identities, regardless of the kinds of security tokens they use. Using standard protocols that anyone can implement on any platform, the identity metasystem allows the acquisition and use of any kind of security tokens to convey identity.By providing a way for users to select identities and more, Windows CardSpace plays an important part in the identity metasystem.

Windows CardSpace (formerly "InfoCard") is a Microsoft .NET Framework version 3.0 (formerly WinFX) component that provides the consistent user experience required by the identity metasystem. It is specifically hardened against tampering and spoofing to protect the end user's digital identities and maintain end-user control. Windows CardSpace enables users to provide their digital identities in a familiar, secure and easy way. In the physical world we use business cards, credit cards and membership cards. Online with CardSpace, it uses a variety of virtual cards to identify ourselves, each retrieving data from an identity provider. "Don't struggle with usernames and passwords, just choose an information card!"

Four aspects of this technology stand out as most important:

  • Support for any digital identity system
  • Consistent user control of digital identity
  • Replacement of password-based Web login
  • Improved user confidence in the identity of remote applications

The multiple digital identities that we use come from several different sources, and they are expressed in a variety of ways. In other words, we typically rely on a number of different digital identity systems, each of which may use a different underlying technology. To think about this diversity in a general way, it's useful to define three distinct roles:

  • User—Also known as the subject, the user is the entity that is associated with a digital identity. Users are often people, but organizations, applications, machines, and other things can also have digital identities.
  • Identity provider—An identity provider is just what the name suggests: something that provides a digital identity for a user. For the digital identity assigned to you by your employer, for example, the identity provider is typically a system such as Active Directory. For the digital identity you use with Amazon, the identity provider is effectively you, since you define your own username and password. Digital identities created by different identity providers can carry different information and provide different levels of assurance that the user really is who he claims to be.
  • Relying party—A relying party is an application that in some way relies on a digital identity. A relying party will frequently use an identity (that is, the information contained in the claims that make up this identity's security token) to authenticate a user, and then make an authorization decision, such as allowing this user to access some information. A relying party might also use the identity to get a credit card number, to verify that the same user is accessing it at different times, or for other purposes. Typical examples of relying parties include Internet websites such as online bookstore and auction sites, and any application that accepts requests through Web services.

Given these three roles, it isn't difficult to understand how Windows CardSpace and the identity metasystem can support any digital identity. Figure 8 shows the fundamental interactions among the three roles.

Figure 8. Iteractions among the users, identity providers and relying party roles

As Figure 8 suggests, a user might rely on an application that supports CardSpace, such as a Web browser, to access any of several relying parties. She might also be able to choose from a group of identity providers as the source of the digital identity she presents to those relying parties. Whatever choice she makes, the basic exchange among these parties has three steps:

1. First, the application gets the security token requirements of the relying party that the user wishes to access. This information is contained in the relying party's policy, and it includes things such as what security token formats the relying party will accept, and exactly what claims those tokens must contain.

2. Once it has the details of the security token this relying party requires, the application passes this information to CardSpace, asking it to request a token from an appropriate identity provider.

3. Once this security token has been received, CardSpace gives it to the application, which passes it on to the relying party. The relying party can then use this token to authenticate the user or for some other purpose.

As this figure 7 illustrates, each digital identity is displayed as an information card, sometimes shortened to just InfoCard (the source of this technology's codename). Each card represents a digital identity that the user can potentially present to a relying party. Along with the visual representation shown in the screenshot, each card also contains information about a particular digital identity. This information includes what identity provider to contact to acquire a security token for this identity, what kind of tokens this identity provider can issue, and exactly what claims these tokens can contain. (As described later, each information card is actually created by an identity provider, and then installed on a user's machine.) By selecting a particular card, the user is actually choosing to request a specific security token with a specific set of claims created by a specific identity provider. This technical complexity is hidden, however, leaving the user free to think in terms that make sense to him or her. Figure 9, a slightly expanded version of Figure 8, shows where the user's decision fits into the process.

''Figure 9. Expanded version of figure 8.

As described earlier, the process begins with an application requesting a relying party's policy. Recall that this policy indicates what kind of security tokens this relying party can accept, and what claims those tokens must contain. Once this information is returned and passed to CardSpace, the system displays the card selection screen. To give the user a consistent experience, every information card he or she owns on this system is shown, just as every card in a wallet is visible when that wallet is opened. Only some cards are applicable in any situation, however, and therefore any information cards whose associated security token and claims don't match the requirements of this relying party are dimmed—that is, the user can't submit them. Once the user clicks on a particular card, CardSpace issues a request, as described earlier, to the identity provider associated with that card. As before, the identity provider then returns a security token that is passed on to the relying party.

Providing a consistent way for users to select digital identities is important for two main reasons:

Users have a consistent and predictable way to use their digital identities. Without this, for all but expert users, the result would surely be confusion and error. Every application built to use CardSpace will use the exact same mechanism for working with digital identities, presenting them to users through the exact same interface. Users are shielded from differences in security technologies. You shouldn't care whether a particular identity's security token is expressed using X.509 certificates, SAML, or in some other way. By providing a common visual representation, CardSpace makes sure that users aren't faced with this unnecessary complexity. Everything is expressed in terms of what a user is concerned with: the identity itself and the information it contains. For greater security, users can choose to protect individual information cards with personal identification numbers (PINs), requiring a user to enter this value before the information card is used. And to further deter local attacks, CardSpace creates a private Windows desktop for the identity selection screen that lets users choose a card. This is similar to the mechanism used to isolate the Windows login screen, and it prevents attacks by other locally-running processes.

It's worth pointing out that providing a consistent mechanism for users to select which digital identity to use is an intrinsic part of the identity metasystem. This paper focuses on CardSpace, a Windows technology, but implementations on other operating systems should provide their own intuitive screen for selecting a card.


Figure 10. YADIS

Given an identity URL and no other information, how do we know what protocol needs to be used to authenticate that a user? Yadis is a service discovery system allowing relying parties (aka identity consumers or membersites) to determine automatically, without end-user intervention, the most appropriate protocol to use.

Examples of such services are:

  • Single sign-on across web sites
  • Profile exchange and form filling
  • Blog anti-spam

Yadis provides the first step for any service that uses identifiers for authentication, accountability, privacy controlled data exchange and more. There are several projects concurrently working towards decentralised identity or single sign-on. Many of these use URLs as identifiers. Yadis was initiated by the leaders of the LID and OpenID projects.

What does YADIS do for me?-The Yadis specification provides:

  • A general purpose identifier for persons and any other entities, which can be used in a variety of services.
  • A syntax for a resource description document identifying services available using that identifier and an interpretation of the elements of that document.
  • A protocol for obtaining that resource description document, given that identifier.

Together these enable coexistence and interoperation of a rich variety of services using a single identifier. The identifier uses a standard syntax and a well-established namespace; it requires no additional namespace administration infrastructure.

When a User offers a Yadis ID to a Relying Party, that Relying Party will want to discover which services are available using that Yadis ID.


  • Is it an OpenID URL, an XRI, a LID or a Sxip ID?
  • What authentication methods are available?
  • What other services?


Figure 11. SAML (Identity 1.5)

SAML, developed by the Security Services Technical Committee of OASIS, is an XML-based framework for communicating user authentication, entitlement, and attribute information. As its name suggests, SAML allows business entities to make assertions regarding the identity, attributes, and entitlements of a subject (an entity that is often a human user) to other entities, such as a partner company or another enterprise application.

The single most important problem that SAML is trying to solve is the web single sign-on (SSO) problem. SSO solutions at the intranet level abound (using cookies, e.g.) but extending these solutions beyond the intranet has been problematic and has led to the proliferation of proprietary technologies that do not interoperate. SAML has become the definitive standard underlying many web SSO solutions in the identity management problem space.

SAML assumes the principal (often a user) has enrolled with at least one identity provider. This identity provider is expected to provide local authentication services to the principal. However, SAML does not specify the implementation of these local services; indeed, SAML does not care how local authentication services are implemented (although individual service providers most certainly will).

A use case: Somebody wants to buy Air ticket from Norwegian airlines by his/her Identity Homesite or Profile

Edit - History - Print - Recent Changes - Search
Page last modified on September 22, 2006, at 10:49 AM EST