Andre Durand

Discovering life, one mistake at a time.
Subscribe

Archive for the ‘Musings’

Topology of Federation

November 23, 2003 By: Andre Category: Musings

Introduction


While examining the key characteristics and deployment scenarios of federation, we (Ping) discovered that federations typically occur in one of three profiles.  Furthermore, we discovered that certain types of companies were more likely to engage in one type of federation than another (at least early on), and that Phase I of federation adoption, where companies engaged either as a consumer or an issuer, but not likely both at the same time, would likely give way to what is referred to as “Cross Domain” federation, whereby companies engaged in both consuming and issuing identity assertions simultaneously.      


(C) Copyright 2003, Ping Identity Corporation | October 24, 2003



 


Profile 1: Service Provider Hub



 


Extending an enterprises reach and available resources to include outsourced and managed applications is a key directive to many extended enterprise initiatives. In each case however, the enterprise would like to enable seamless employee access to these managed applications — as if they were running on the company’s internal network.  Said differently, once an employee is logged into the enterprise network, they should be able to access an outsourced service without performing an additional login or needing to maintain an additional account with the managed application provider.  Less identity federation, employees are forced to maintain multiple ‘identities’ for each outsourced application. Possibly even more important, redundant and disconnected identities represent an enterprise security risk, as revoking an identity from accessing the managed application can no longer be performed within the enterprise’s existing authorization and policy infrastructure, but instead must be managed as a one-off process.  


 


In a Service Provider Hub, one entity provides an outsourced service or web application (e.g. salesforce.com, travel.com, my SAP etc.) to enterprises that can be viewed as consumers of the  outsourced application, service or web process. As the service is operated outside of the enterprises domain of control, yet the enterprise wishes to manage access to the application as if it was within the enterprises domain of control, a mechanism of extending the enterprises existing directory and security policy infrastructure is required.


 


In this model, the service provider can be seen as sitting in the middle of a number of surrounding enterprises. In order to enable more seamless and integrated access to its enterprise end-users, both the service provider and the enterprises surrounding it desire a mechanism of enabling more seamless access to the managed application via federated single sign-on.  


 


In the Service Provider Hub federation profile, the service provider becomes a relying party to the identity assertions made to it by enterprise customers, who are in turn, identity providers to the outsourced application managed by the service provider.


 


Characteristics


·         Service Provider wishes to enable federated SSO to a surrounding number of enterprises by relying upon the enterprise identity assertions relating to its employees.


·         Authentication of end-users (e.g. employees) will take place at the enterprise, and then propagated via identity federation assertions to the service provider.


·         Roles, credentials or even authorization policies may also be asserted from the enterprise to the service provider via identity ‘attribute exchange’.


 


Hub Drivers


·         Service providers wish to better integrate and connect their managed applications or web services to an enterprise’s existing security, authorization and policy engines.


·         Enterprises wish to enable easier access to managed applications and services by enabling single sign-on over the public internet.


 


Examples


·         Fidelity wishing to enable federated SSO to its 401k management services.


·         Salesforce.com wishing to enable federated SSO to its managed CRM solutions.


·         A mortgage company wishing to enable federated SSO to applications which are accessed by financial services companies and mortgage brokers.


 



 


Profile 2: Identity Provider Hub



 


As a near mirror image of the Service Provider Hub, the Identity Provider Hub is designed to allow a central authenticator and identity provider to federate identity attributes to a surrounding number of service providers. Think of this as a mini Microsoft Passport, but one that extends only as far as a single companies domain.


 


Enterprises who have taken the time and expense to aggregate user identities into a single repository for the purposes of centralized authentication and customer relationship management, such as carriers, ISP’s and portals, typically fall into this category.


 


In most cases, we have found that Identity Provider Hub federations tend to be consumer-facing, where aggregation of consumers and end-user simplicity as enabled through single sign-on to a large number of services is highly valued.  


 


We have also noted that Identity Provider Hub federations, and the carriers, ISP’s and consumer facing portals behind them, tend to view internally facing federations (e.g. federating services within their domain) as only phase I of their goals to extend federation to partners.


 


Characteristics


·         A large number of service providers (consumers of identity attributes) wish to leverage the authentication mechanisms of a single and/or centralized authenticator.


·         Authentication strength will be driven to higher and higher levels of assurance over time, as a result of the needs of the consuming service providers.


·         Service Providers may over time, evolve into becoming their own identity providers, storing and propagating attributers pertaining to their users preferences and interaction history back to the central IdP over time.


 


Drivers


·         Desire to centralize authentication and the point at which CRM services are deployed, while still enabling a surrounding number of services to leverage the authentication services of a centralized IdP.


·         Desire to build an Identity Provider with strong enough levels of identity assurance that service providers outside of the identity providers domain will be comfortable in consuming the IdP’s authentication assertions.


 


 



 


Profile 3: Cross Domain



 


Cross Domain federations are of particular interest because they exist in both internal and external (between company) situations. The primary characteristic of a Cross Domain federation is that each entity acts as both an issuer of identity assertions (an ‘IdP’) and also a consumer of identity assertions (an ‘SP’) at the same time. Furthermore, there is little discernable topology to a cross domain federation, as each entity can connect to every other entity within the federation, and both accept and transmit identity-related assertions.


 


The Internal Cross Domain


Many large, multi-national companies, through merger and acquisition, are now faced with having to manage several heterogeneous systems at the same time. This creates both a security challenge as the IT department attempts to assure the right user-level access to resources as well as a complexity issue for employees who must manage multiple accounts, one for each security domain within the company. Internally facing federation describes the process of leveraging the relatively new and open identity federation protocols (such as SAML, Liberty or WS-Federation) to ‘link-together’ redundant identities maintained in silo’d security domains.  


 


The External Cross Domain


Topologically identical to the Internal Cross Domain federation, the External Cross Domain federation links identities across legal domains (between companies), and is therefore not limited to the linking of redundant identities between security domains within a single company. Many times, internally facing Cross Domain federation will occur as a pre-requisite to externally facing federation activities.


 


We expect that both SP Hub and IdP Hub federation profiles will give way, long-term, to cross domain federation, becoming increasing dynamic in their transaction behavior over time as trust networks are established a framework of assessing risk when engaging unknown partners is automated.  


 


Characteristics


·         Multiple entities engaging one another as both IdP’s and SP’s simultaneously.


·         Likely the ‘resting-state’ for a mature identity infrastructure.


·         Can be implemented in both internal and external (between company) situations.


·         Will result when an SP in an IdP Hub becomes the center of their own federation.


 


Drivers


·         Within large enterprises, Cross Domain federation provides some key cost and complexity saving advantages in that it enables cross-domain access via SSO without needing to homogenize systems or authentication.


·         As entities within both the IdP Hub and the SP Hub models engage multiple federations, they will become over time, both asserters and consumers of identity attributes, naturally evolving them to the Cross Domain profile.   


 

Test Page 2

April 11, 2003 By: erin@w... Category: Musings

This is a test by the server admin

The Ultimate Big Brother?

February 18, 2003 By: Andre Category: Musings

I was listening to Tim O’Reilly discuss databases one afternoon at his Open Source conference. He was talking about how there were at least three different approaches to building databases:

 

1. manually populate them one record at a time.

2. build a bot to populate them somewhat automatically.

3. or lastly, allow people to do what they do in the normal course of their day-to-day activities and let the database grow organically as a by-product. 

 

He then went on to talk about how Napster knows what’s hot in music and how it represented the #3 type of database – always current, always being updated.

 

Well, if you think that Napster learned about our music preferences, what do you think Google has leared about each of us in the past two years?

Three Phases of Identity Infrastructure Adoption

January 21, 2003 By: Andre Category: Musings

Unfortunately, there has been a tremendous amount of time, energy and money spent within the past five years by well intentioned visionaries who like myself, saw an opportunity to enable end-user control over digital identity, but were not able to capitalize on the opportunity.


While I owe my involvement in the identity industry to a similar personal passion – to see that end-users are ultimately in control over their digital identity, I’ve come to appreciate the timing of the opportunity, and the phases in which the industry will likely evolve.


Understanding the nuances of the progression of adoption of identity related technologies is likely the secret ingredient of any winning strategy for vendors in the identity space, and in the spirit of being true to my other passion — open source & open strategies — I’m going to lay out my ideas here in an open manner.


To begin, let’s start with a bit of background. Back in March of 2002, I published an essay which put forth the notion that there were in fact three tiers of identity. For simplicity, I’ll summarize the three tiers of identity below:


Tier 1: Personal (My) Identity – A T1 identity is your true and personal digital identity and is owned and controlled entirely by you, for your sole benefit. T1 identities are both timeless & unconditional and can exist for people as well as for devices and/or programs or objects, with the exception that a device or program T1 identity operates only as an AGENT of a personal (human) T1 (every object is owned and/or controlled by someone). We refer to object T1’s as ‘T1a’.

Tier 2: Corporate (Our) Identity – A T2 (corporate) identity refers to our digital identities that are assigned to us by corporations (e.g. our ‘customer accounts’). Nearly all of the existing digital identities are T2 identities — our title (assigned to us by our employer), our cell phone number (assigned to us by our mobile phone operator), our United Mileage Plus number (assigned to us by United Airlines), our social security number (assigned to us by the Government), our credit card number (assigned to us by our credit card companies) and the list goes on and on. T2 identities are both conditional & temporarily assigned and they can be revoked by either us or the company which issued them – thus you can think of them as ‘our’ identity.  

Tier 3: Marketing (Their) Identity – A T3 identity is an abstracted identity in that it identifies us through our demographics and other reputation like attributes, but does not need to do so in a 1:1 manner. T3 identities speak to the way in which companies aggregate us into different marketing buckets for the purposes of advertising or communicating with us. For example, we’re either a ‘frequent buyer’ or a ‘one time customer’ etc. T3’s are typically based upon our behavior in our interactions with business. The entire CRM market caters to T3 identities.


Where I and others who share a passion for the subject have steered the discussion towards enabling an infrastructure in support of the T1 identity, the fact is, neither end-users nor the world around us is ready for this infrastructure at this time, and many companies have both tried and failed to develop market share for technologies which supported the notion of a T1 identity.   


The problem with attempting to build support for T1 infrastructure (e.g. personal identity servers or even P2P based identity clients) at this time is to do so would leave that infrastructure isolated and misunderstood from existing corporate infrastructure (corporate systems do not yet speak the language of identity), and as such, would lack real utility in practical every day use. Any T1 infrastructure built and deployed in Phase I (see below) of the industries development is likely to receive only limited adoption, while lacking mainstream appeal.


The purpose of this essay is to introduce the notion that there might in fact be at least two intermediate phases which MUST take place before the world is prepared in all respects to absorb and indeed ‘enable’ the true utility of a T1 identity. These steps, or phases, and a brief description of their characteristics follow:



Phase I: Federation of T2 Identity


The first phase of digital identity infrastructure adoption will be characterized by a ‘linking’ of existing identity systems. What is now referred to within the industry as ‘identity federation’, companies are now beginning to figure out the language of connecting or linking their existing T2 identity databases or LDAP directory repositories, authentication systems, authorization systems and user management systems. This is a critical first step towards the broader notions of a ‘universal’ digital identity infrastructure, because it represents a small, incremental improvement over the way in which things are currently done, and does not require a ‘rip and replace’ strategy for corporations who are looking to gain incremental utility from their existing IT investments.


Enterprise interest in the Liberty Alliance Project and the work being done by only validate the fact that this is in fact a logical starting point for corporations to focus.


The reason Phase I is so important is not that it allows corporations to maintain some semblance of security while dealing with the inevitability of their disappearing firewall, but that in the process of federating, companies will define the common language (protocol) of identity interchange, a language which MUST be installed and understood by all enterprise applications PRIOR to the T1 identity having any real world utility.


The advantages of Phase I from an enterprise perspective are that they allow corporations to take a logical, useful but incremental first step. It also allows them to engage partners in more meaningful interactions while providing conveniences to end-users through things like single sign-on.


The disadvantage of T2 Identity Linking (identity federation) is that there is a tremendous amount of redundancy in maintaining accurate information across N databases (for the same individual) and this redundancy is an extremely inefficient way to do things. That said, customer databases have been and will continue to be viewed as both sacred and highly protected informational assets, and not something companies will be willing to give up anytime in the near future.


Phase II: Transition and Equilibrium


One characteristic that we are entering Phase II will be that consumers will become much more aware that they have a digital identity and that they are being used by corporations. At this point, end-users will begin to desire or in some cases even demand (e.g. legislation) to have more control over the use and access to their digital identity profile and attribute data. As a result of this awareness and in fact real demand, there will be a renewed interest to build-out T1 Identity Infrastructure, the difference being that this time, the T1 infrastructure will be built using the pre-installed language of identity invested in so heavily by corporations in Phase I (a key distinction in terms of the potential for success of T1). Because both T1 and T2 now co-exist in Phase II, equilibrium will likely emerge with respect to ‘who controls what aspects of your data’.


Note that Phase II may or may not actually be a transition Phase. It might indeed be a final state. Indeed, it is quite possible that the evolution of identity infrastructure never progresses beyond Phase II and I don’t believe that this as actually a bad thing. The co-existence of T1 and T2 systems could work provided a fair and balanced equilibrium with respect to control is reached between the needs and desires of the individual and the requirements of businesses to communicate with and service their customers. The only reason I can envision the world progressing in it’s evolution beyond Phase II and towards Phase III would be because of external pressures such as legislation or the efficiencies gained in Phase III through the elimination of redundant information would outweigh enterprises concerns that ‘fair use’ (Phil Becker) would in some way break or cease to exist.  


Phase III: The True T1 Emerges


In Phase III, T1 has evolved to the point where companies begin to rely upon the integrity of the T1 (maintained by the individual) and query the T1 to update their T2’s. When (and if) this occurs, T2’s as we know them today will likely forever change. It will be as if the T1 becomes the ‘master’ and T2 the ‘copy’.


The advantage of Phase III from the consumer or end-user perspective is that finally, they will be in complete control over their digital identity. From a corporate point of view, the advantage to them will be that the need to maintain a redundant copy of an end-users account information and the costs associated with maintaining that data (ensuring that is current and accurate) will be eliminated. Personally, I do believe that provided ‘fair use’ is accommodated, Phase III offers the most advantages to both the individual and the corporation.


Once again, I’m not sure that the world ever evolves as far as a Phase III, but I do believe that Phase I and II are precursors for even the possibility of a Phase III as described within.

Three Phases of Identity Infrastructure Adoption

January 21, 2003 By: Andre Category: Musings

Interestingly enough, an essay I published hypothesizing Three Tiers of Identity back in March of 2002 has sparked some recent discussion between Doc, Mitch and others. Furthermore, recent news of RSA’s T1 identity initiative and a number of T1 based identity products have lead me to formalize my own thoughts on the subject of timing and the T1 identity.


In this essay, I lay out my ideas related to identity industry adoption timing, and what I feel are the required pre-cursors for a fully viable T1 infrastructure. Read the Essay.

Parker Madison Durand

January 10, 2003 By: Andre Category: Musings


Parker’s Photo Website

Public Source License – SourceID SSO v1.0

December 31, 2002 By: Andre Category: Musings


License Summary


The Public Source License (the “License”) applies to SourceID SSO software distributed by Ping Identity Corporation. It authorizes you to copy, distribute or modify the software, royalty free, for unlimited personal or non-commercial use, or for commercial use on fewer than 100 computers. The fees for commercial use on 100 or more computers are available at http://www.pingidentity.com.


This is a summary of license terms intended to describe, in plain English, the nature and scope of this License. However, this summary is not a part of this License. The legal effect of the License is dependent only upon the terms of the License, including its definitions, and not this summary.


Ping Identity Corporation provides you with both the executable version of the software and the associated source code. You may modify the source code and use, copy or distribute your modified versions. Please note that the term “Modifications” is defined specifically in the License below.


If you modify the software and distribute your modifications, you must distribute your modified source code and executable code under the terms of this License. This reciprocity provision ensures that recipients of your modifications can enjoy the same rights to your modifications as this License grants to you, and that they will accept the same obligations. If you plan to distribute your modifications under this License, you must also grant back to Ping Identity Corporation a license to your modifications so that we may, at our discretion, incorporate them into our future distributions. Further information about the SourceID SSC public source software development project can be found at http://www.sourceid.org. A Proprietary Source Code Waiver, permitting you to distribute your modifications without disclosing your source code (subject to the payment of a one-time Proprietary License Fee), is attached as Exhibit A to the License below.


If you become aware of third party claims or other intellectual property rights that would restrict or limit use of the software, you must notify everyone to whom you give copies. You must also retain all copyright, trademark or patent notices already in the software. These provisions are intended to ensure that there is a clear record of ownership of all intellectual property rights necessary to copy, modify, distribute, make, use or sell the software or modified versions of the software.


The software is distributed on an AS IS basis, WITHOUT WARRANTY OF ANY KIND. You cannot hold Ping Identity Corporation liable for any damages that result from use of the software.


The License terminates automatically if you breach any of the terms of the License, or if you assert certain types of patent claims against Ping Identity Corporation or any contributor.


We encourage you to read the terms and conditions of the License carefully before you use, copy, modify or distribute this software. You must expressly assent to this License upon installation of the software or before you will be allowed to execute the software for the first time. For all other uses of the software not covered under this License you must obtain an amendment to the License.


Ping Identity Corporation welcomes your comments and suggestions about its software and its other products. We can be reached at 341 Albion Street, Denver CO 80220, or at info@pingidentity.com.


Public Source License


SourceID SSO v1.0


This Public Source License (the “License”) applies to certain software (“SourceID SSO software” or “Licensed Software”) distributed by Ping Identity Corporation, 341 Albion Street, Denver, Colorado 80220 (the “Licensor”). The Licensed Software is protected by copyright law. This License identifies the terms under which you may use, copy, distribute or modify the Licensed Software. For a license to use, copy, distribute or modify Ping Identity Corporation products under terms or conditions other than those described here, or for trademark licensing, please contact the Licensor at http://www.pingidentity.com.


License Terms


1. Grant of Copyright License from Licensor. In consideration for your acceptance of all of the terms and conditions of this License, Licensor (and, by application of Section 5 of this License, each Contributor of Modifications, as those terms are later defined) grants to you a world-wide, non-exclusive license, under copyrights now owned or controlled by Licensor or Contributor, to use, reproduce, modify, display, perform and distribute Licensed Software (including Modifications) or portions thereof, in both Source Code or as an executable program, as follows:


a. Without payment of royalty for unlimited Personal Use or Non-Commercial Distribution (as those terms are defined below);


b. Without payment of royalty for other than Personal Use and Non-Commercial Distribution as long as Licensed Software will run on fewer than 100 computers (as that term is defined below); and


c. Subject to the payment of one-time paid-up Royalty Fees for other than Personal Use and Non-Commercial Distribution on 100 or more computers. Licenses to run the Software on additional computers are subject to the Royalty Fees and payment terms as obtained at http://www.pingidentity.com and in effect on the date such additional licenses are obtained from Licensor. Royalty Fees to run the Software on additional computers are due and payable to Licensor prior to first use on those computers.


2. Grant of Patent License from Licensor. In consideration for your acceptance of all of the terms and conditions of this License including, without limitation, the payment of applicable Royalty Fees as described in Section 1 above, Licensor (and, by application of Section 5 of this License, each Contributor of Modifications) grants to you a world-wide, non-exclusive license, under claims of patents now or hereafter owned or controlled by Licensor or Contributor, to make, use, sell, offer for sale, have made, and/or otherwise dispose of Licensed Software (including Modifications) or portions thereof for the uses permitted by this License, but solely to the extent that any such claim is necessary to enable you to make, use, sell, offer for sale, have made, and/or otherwise dispose of Licensed Software (including Modifications) that you received from Licensor or a Contributor.


3. Definitions.


a. As used in this License, the term “Personal Use” means the functional use of software by an individual solely for his or her personal, private and non-commercial purposes. An individual’s use of software in his or her capacity as an officer, employee, member, independent contractor or agent of a corporation, business or organization (commercial or non-commercial) does not qualify as Personal Use.


b. As used in this License, the term “Non-Commercial Distribution” means the distribution of software to any third party for which no payment is made in connection with such distribution, whether directly (including, without limitation, payment for a copy of the software) or indirectly (including, without limitation, payment for a service related to the software, or payment for a product or service that includes a copy of the software “without charge”).


c. As used in this License, the term “Source Code” means the preferred form for making Modifications to software, including all modules contained therein, plus any associated interface definition files, scripts used to control compilation and installation of an executable program, or a list of differential comparisons against the Source Code of the software.


d. As used in this License, the term “Modifications” means any additions to or deletions from the substance or structure of (i) a file containing Licensed Software, or (ii) any new file that contains any part of Licensed Software. The term Modifications includes, without limitation, Derivative Works, as that term is defined in U.S. Copyright Law, 17 U.S.C. §101. If you merely combine the Licensed Software with other software and do not modify any of the Source Code provided under this License, then you have not created Modifications that are subject to the provisions of Section 5.


e. As used in this License, the term “Contributor” means any person or entity that created or contributed to the creation of, and distributed, Modifications.


f. “You” throughout this License, whether in upper or lower case, means an individual or a legal entity exercising rights under, and complying with all of the terms of, this License or a future version of this License issued under Section 8. For legal entities, “you” includes any entity that controls, is controlled by, or is under common control with you. For purposes of this definition, “control” means (i) the power, direct or indirect, to cause the direction or management of such entity, whether by contract or otherwise, or (ii) ownership of fifty percent (50%) or more of the outstanding shares, or (iii) beneficial ownership of such entity.


g. As used in section 1 of this License, the term “computer” refers to a single processor running a single instance of Licensed Software. Each additional processor or instance of Licensed Software counts as an additional computer.


4. Exclusions from License Grant. Nothing in this License shall be deemed to grant any rights to trademarks, copyrights, patents, trade secrets or any other intellectual property of Licensor or any Contributor except as expressly stated herein. No patent license is granted separate from the Licensed Software, for code that you delete from the Licensed Software and use separately, or for combinations of the Licensed Software with other software or hardware. Nothing in this License shall be interpreted to prohibit Licensor from licensing under different terms from this License any software that Licensor otherwise would have a right to license.


5. Your Obligations Regarding Distribution.


a. Application of This License to Your Modifications. As an express condition for your use and distribution of the Licensed Software, you hereby agree that any Modifications that you create or to which you contribute, and which you distribute, are governed by the terms of this License including, without limitation, Sections 1 and 2. You must include a copy of this License with every copy of the Licensed Software or Modifications that you distribute, and you must obtain the express assent of your sublicensees to this License before you allow them to install the Licensed Software or use it for the first time.


b. Responsibility for Payment of Royalties. You and your sublicensees shall be jointly and severally liable for all royalties due by your sublicensees under this License, which must be paid to Licensor prior to distribution of Licensed Software or Modifications. You may charge additional fees to your sublicensees for your Modifications or for services relating thereto.


c. Availability of Source Code. You must make available, under the terms of this License, the Source Code of the Licensed Software and any Modifications that you distribute, either on the same media as you distribute any executable or other form of the Licensed Software, or via a mechanism generally accepted in the software development community for the electronic transfer of data (an “Electronic Distribution Mechanism”). The Source Code for any version of Licensed Software or Modifications that you distribute must remain available for at least twelve (12) months after the date it initially became available, or at least six (6) months after a subsequent version of said Licensed Software or Modifications has been made available. You are responsible for ensuring that the Source Code version remains available even if the Electronic Distribution Mechanism is maintained by a third party. You must also contribute the Source Code for any version of Licensed Software or Modifications that you distribute to the SourceID SSO project by following the contributor instructions at http://www.sourceid.org.


d. Description of Modifications. You must cause any Modifications that you create or to which you contribute, and which you distribute, to contain a file documenting the additions, changes or deletions you made to the Source Code of the Licensed Software, and the dates of any such additions, changes or deletions. You must include a prominent statement in the Source Code that the Modifications are derived, directly or indirectly, from the Licensed Software. You may not modify or delete any preexisting copyright, patent, trademark or other attribution notices in the Licensed Software.


e. Grant-Back of License to Modifications. As an express condition for the license to create and distribute Modifications granted to you in Section 1 herein, you hereby grant to Ping Identity Corporation, its successors and assignees, a world-wide, royalty-free, non-exclusive license, subject to third party intellectual property claims, to do the following:


i. Under copyrights owned or controlled by you, to use, reproduce, modify, display, perform, sublicense and distribute your Modifications or portions thereof, in both Source Code or as an executable program; and


ii. Under claims of patents now or hereafter owned or controlled by you, to make, use, sell, offer for sale, have made, and/or otherwise dispose of your Modifications or portions thereof, but solely to the extent that any such claim is necessary to enable Ping Identity Corporation, its successors and assignees, to make, use, sell, offer for sale, have made, and/or otherwise dispose of your Modifications alone or in combination with Licensed Software.


f. Intellectual Property Matters.


i. Third Party Claims. If you have knowledge that a license to a third party’s intellectual property right may be required to exercise the rights granted by this License, you must include a text file with your Source Code distribution titled “LEGAL” that describes the intellectual property right and the owner of the intellectual property right in sufficient detail that a recipient will know whom to contact. If you obtain such knowledge after you make any Modifications available as described in Section 5(a), you shall promptly modify the LEGAL file in all copies you make available thereafter and shall take other steps (such as notifying appropriate mailing lists or newsgroups) reasonably calculated to inform those who received the Licensed Software from you that new knowledge has been obtained.


ii. Contributor APIs. If your Modifications include an application programming interface (“API”) and you have knowledge of patent licenses that are reasonably necessary to implement that API, you must also include this information in the LEGAL file.


iii. Representations. You represent that, except as disclosed pursuant to 5(f)(i) above, you believe that any Modifications you distribute are your original creations and that you have sufficient rights to grant the rights conveyed by this License.


6. Inability to Comply Due to Statute or Regulation. If it is impossible for you to comply with any of the terms of this License with respect to some or all of the Licensed Software due to statute, judicial order, or regulation, then you must (i) comply with the terms of this License to the maximum extent possible, (ii) cite the statute or regulation that prohibits you from adhering to the License, and (iii) describe the limitations and the code they affect. Such description must be included in the LEGAL file described in Section 5(f)(1), and must be included with all distributions of the Source Code. Except to the extent prohibited by statute or regulation, such description must be sufficiently detailed for a recipient of ordinary skill at computer programming to be able to understand it.


7. Versions of This License.


a. New Versions. Licensor may publish from time to time revised and/or new versions of the License.


b. Effect of New Versions. Once Licensed Software has been distributed under a particular version of the License, you may always continue to use it under the terms of that version. You may also choose to use Licensed Software under the terms of any subsequent version of the License published by Licensor. No one other than Licensor has the right to modify the terms applicable to Licensed Software created under this License.


c. Derivative Works of this License. If you create or use a modified version of this License, which you may do only in order to apply it to software that is not already Licensed Software under this License, you must rename your license so that it is not confusingly similar to this License, and must make it clear that your license contains terms that differ from this License. In so naming your license, you may not use any trademark of Licensor or any Contributor.


8. Disclaimer of Warranty. Licensed Software is provided under this License on an “AS IS” BASIS, WITHOUT WARRANTY OF ANY KIND, either express or implied, including, without limitation, warranties that the Licensed Software is free of defects, merchantable, fit for a particular purpose or non-infringing. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE LICENSED SOFTWARE IS WITH YOU. Should Licensed Software prove defective in any respect, YOU (and not the Licensor or any Contributor) assume the cost of any necessary servicing, repair or correction. THIS DISCLAIMER OF WARRANTY CONSTITUTES AN ESSENTIAL PART OF THIS LICENSE. NO USE OF LICENSED PRODUCT IS AUTHORIZED HEREUNDER EXCEPT UNDER THIS DISCLAIMER.


9. Termination.


a. Automatic Termination upon Breach. This license and the rights granted hereunder will terminate automatically if you fail to comply with the terms of this License and fail to cure such breach within thirty (30) days of becoming aware of the breach. Provisions that, by their nature, must remain in effect beyond the termination of this License, shall survive.


b. Termination upon Assertion of Patent Infringement. If you initiate litigation by asserting a patent infringement claim (excluding declaratory judgment actions) against Licensor or a Contributor (Licensor or Contributor against whom you file such an action is referred to herein as “Respondent”) alleging that Licensed Software, alone or including Modifications, directly or indirectly infringes any patent, then any and all rights granted by such Respondent to you under Sections 1 or 2 of this License shall terminate prospectively upon sixty (60) days notice from Respondent (the “Notice Period”) unless within that Notice Period you either agree in writing (i) to pay Respondent a mutually agreeable reasonably royalty for your past or future use of Licensed Software made by such Respondent, or (ii) withdraw your litigation claim with respect to Licensed Software against such Respondent. If within said Notice Period a reasonable royalty and payment arrangement are not mutually agreed upon in writing by the parties or the litigation claim is not withdrawn, the rights granted by Licensor to you under Sections 1 and 2 automatically terminate at the expiration of said Notice Period.


c. Reasonable Value of This License. If you assert a patent infringement claim against Respondent alleging that Licensed Software, alone or including Modifications, directly or indirectly infringes any patent where such claim is resolved (such as by license or settlement) prior to the initiation of patent infringement litigation, then the reasonable value of the licenses granted by said Respondent under Sections 1 and 2 shall be taken into account in determining the amount or value of any payment or license.


d. No Retroactive Effect of Termination. In the event of termination under Sections 9(a) or 9(b) above, all sublicenses (excluding licenses to distributors and resellers) that have been validly granted by you or any of your distributors or resellers prior to termination shall survive termination.


10. Limitation of Liability. Under no circumstances and under no legal theory, whether in tort (including negligence), contract, or otherwise, shall the Licensor, any Contributor, or any distributor of Licensed Software alone or including Modifications, or any supplier of any such parties, be liable to any person for any indirect, incidental, or consequential damages of any character including, without limitation, damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses, even if such party shall have been informed of the possibility of such damages. This limitation of liability shall not apply to liability for death or personal injury resulting from such party’s negligence to the extent applicable law prohibits such limitation. Some jurisdictions do not allow the exclusion or limitation of incidental or consequential damages, so this exclusion and limitation may not apply to you.


11. Responsibility for Claims. As between Licensor and Contributors, each party is responsible for claims and damages arising, directly or indirectly, out of its utilization of rights under this License. You agree to work with Licensor and Contributors to distribute such responsibility on an equitable basis. Nothing herein is intended or shall be deemed to constitute any admission of liability.


12. U.S. Government End Users. The Licensed Software is a “commercial item,” as that term is defined in 48 C.F.R. 2.101 (Oct. 1995), consisting of “commercial computer software” and “commercial computer software documentation,” as such terms are used in 48 C.F.R. 12.212 (Sept. 1995). Consistent with 48 C.F.R. 12.212 and 48 C.F.R. 227.7202-1 through 227.7202-4 (June 1995), all U.S. Government End Users acquire Licensed Software with only those rights set forth herein.


13. Miscellaneous. This License (excluding any accompanying license summary) represents the complete agreement concerning the subject matter hereof. If any provision of this License is held to be unenforceable, such provision shall be reformed only to the extent necessary to make it enforceable. This License shall be governed by Colorado law provisions (except to the extent applicable law, if any, provides otherwise), excluding its conflict-of-law provisions. You expressly agree that any litigation relating to this license shall be subject to the jurisdiction of the federal courts or state courts in the State of Colorado (as appropriate), with venue lying in Denver, Colorado, with the losing party responsible for costs including, without limitation, court costs and reasonable attorneys’ fees and expenses. The application of the United Nations Convention on Contracts for the International Sale of Goods is expressly excluded. You and Licensor expressly waive any rights to a jury trial in any litigation concerning Licensed Software or this License. Any law or regulation that provides that the language of a contract shall be construed against the drafter shall not apply to this License.


Exhibit A


Proprietary Source Code Waiver


This Proprietary Source Code Waiver (the “Waiver”) to the Ping Public Source License (the “License”) for SourceID SSO software (the “Licensed Software”) is made in consideration for the payment to Ping Identity Corporation (the “Licensor”) of a one-time Proprietary License Fee by the Licensee identified below. (Contact http://www.pingidentity.com for further information on the amount of the Proprietary License Fee.)


1. Licensor hereby waives enforcement of the provision of the License at Section 5(a) that requires that any Modifications of the Licensed Software that Licensee creates or to which it contributes, and that it distributes, be governed by the terms of the License.


2. Licensor hereby waives enforcement of the provision of the License at Section 5(c) that requires Licensee to distribute the Source Code of its Modifications of the Licensed Software.


3. Licensor hereby waives enforcement of the provision of the License at Section 5(d) that requires Licensee to document the additions, changes or deletions it made to the Source Code of the Licensed Software.


4. Licensor hereby waives enforcement of the provision of the License at Section 5(e) that requires Licensee to grant-back a license to its Modifications of the Licensed Software to Ping Identity Corporation.


All other License terms, including the requirement to pay Royalty Fees as described in the License, remain in full force and effect.


This Waiver shall become effective upon the payment to Ping Identity Corporation of the Proprietary License Fee and the execution of this Waiver by duly authorized representatives of the two parties identified below.



















Ping Identity Corporation:


Licensee: ___________________________________


Signed: ____________________ ____


Signed: _____________________________________


Name: ________________________


Name: _____________________________________


Title: _________________________


Title: _______________________________________


Date: _________________________


Date: ______________________________________


This license is (c) Copyright 2002, Ping Identity Corporation

Towards Federated Identity Management

December 09, 2002 By: Andre Category: Musings

Eric and I wrote this whitepaper back in 2002. It’s always interesting to see if your writings stand the test of time. I believe two years later this document still captures the problems and challenges associated with scaling identity federation interactions. Most of the concerns addressed in this whitepaper have now been addressed through products and services offered by Ping Identity Corporation or through the PingID Network. If you like this whitepaper, I strongly suggest you also read the following: How the nature of identity will shape it’s deployment & Topology of Federation.



by Eric Norlin and Andre Durand – (C) Copyright 2002-2004, Ping Identity Corporation


The IT Dilemma
The 1990’s witnessed enterprise adoption of an increasing number of information systems, each designed to streamline business processes through electronic automation. With the introduction of new systems for managing customers, supply chains, content  and corporate knowledge, enterprises have been challenged with how to cost-effectively integrate and maintain an increasing number of information systems across a growing number of networks and platforms.  Simultaneously, enterprises have also been challenged by the need to provide increased access to a larger and more dynamic group of end-users.


The challenge of managing these systems has resulted in a complex IT dilemma – namely, how to control costs and maintain security while increasing access to information.




The IT Dilemma: How to balance growing access to information with the need to maintain security.



As a consequence of globalization and to add to the growing list of corporate pressures, IT departments are now being forced to increase access to information for both employees (e.g. intranets) and partners and customers (e.g. extranets, supply chain management etc.).  These and other pressures are driving corporations to re-evaluate their security and information architectures to accommodate the increasingly dynamic and transparent ways in which a growing number of parties wish to interact.


The Advent of Digital Identity
New distributed computing models such as those proposed by web services create a fresh set of challenges which in turn have given rise to a requirement to establish stronger and more granular methods of electronic identification.


To meet these new challenges, emerging technologies such as ‘Digital Identity’ are now being recognized as a key ingredient in the re-architecting of systems to accommodate the secure adoption of more distributed and transparent computing models. 


The broad adoption of XML Web services as a computing model means that solutions no longer reside just within the four walls of an organization—while this brings new capabilities, it also forces one to consider how to manage trust and identity, not just across internal applications that are tightly controlled by corporate IT, but also to manage identity information across applications and services that span organizations, platforms, security approaches, and programming models.
 Microsoft Website regarding Federated Security and Identity Roadmap


As corporate IT systems become more distributed and interdependent with partners and affiliates, new Digital Identity-based information architectures are helping to readily “identify” each component, thereby allowing IT departments to maintain security while allowing increased access to sensitive information. By answering the questions: a) Who are you? B) What are you allowed to do? and c) Where are you allowed to go? in a cost efficient way, IT departments are able to respond to the pressures of globalization by safely allowing their boundaries to become more transparent and permeable.


To help manage this transparent access to information, companies are integrating identity management solutions which help automate the procedures for user and role provisioning, password management and access control to information. To date however, the bulk of these solutions have focused on the internal use and management of identity, and not the inter-company and interdependent management of identity information between companies — what is know referred to as ‘Federated Identity Management’.




While current identity management solutions provide distinct cost-saving benefits, they do not specifically address the issues which surround the emergence of identity federation, namely, how to safely and without incurring liability, exchange identity information between companies. 


 


From Enterprise to Federated Identity Management
The true nature of the identity challenge is just now beginning to unfold, and stems not from how corporations manage identities within their control, but how they manage identities that are at least partially beyond their control. 
 



 


Federated Identity Management (FIM), or the management of identities between corporate boundaries, has recently emerged in response to the desires to simplify the way in which individuals (consumers) are able to move between companies.  Applications such as shared sign-on (SSO) and the emergence of web services architectures are driving the need for companies to understand and manage inter-company dependencies. Unlike EIM, where technology serves to resolve a good portion of the corporate IT dilemma, FIM raises issues which are far more complex and extensive, and require new approaches. To truly appreciate the FIM challenge, one must recognize that some identity information fundamentally exists beyond the corporate firewall, and is therefore at least partially beyond any one corporation’s individual control.


The adoption of new distributed computing models (e.g. federated identity and web services) are requiring enterprises to recast their view of themselves as a component of a larger interdependent construct.  With the emergence of inter-company computing, the hard boundaries of today’s corporate firewalls are dissolving, or at least becoming semi-transparent — allowing for more transparent movement of the individual between control boundaries.


 


Identity Federation
Federated Identity is just one of several new distributed computing constructs that recognizes the fact that individuals move between corporate boundaries at an increasingly frequent rate. Driving the requirement to understand the implications of identity federation is the rise in popularity of Shared Sign-On (SSO), an application which reduces redundant logons by allowing applications, systems and companies to share a user (identity) authentication.  As a consequence of inter-company SSO, and the interdependency which is assumed in such interactions, companies are now forced to deal with new issues such as liability, risk and the costs associated with establishing trust and security in a quality conscious manner.  As one would expect, these new challenges give rise to new costs, including: (i) the cost of negotiating and establishing formal agreements with electronic trading partners, (specifying the rules which will govern the exchange of identity information—including provisions for legal liability, dispute resolution and ensuring compliance with privacy requirements), (ii) the cost of implementing new technologies and (iii) the cost of maintaining security.


“Over the next few years we have to deal with some very messy problems – namely, what it takes to deploy federated technology along with what it takes to bash out contracts between partners…”
Michael Barrett, Vice President of Internet Strategy at American Express & President of Liberty Alliance



Challenges of Wide-Scale Identity Federation
While it’s entirely possible to control the costs and complexity of identity federation on a limited scale, within small circles of trust, wide-scale federation introduces new costs, complexity and challenges which exist on an entirely new scale.


The real challenge of wide-scale FIM only becomes evident when attempting to scale beyond a few partnerships, as when engaging several dozen, hundreds or even thousands of companies, many of which may not be known or ‘trusted.’


The reality is, trust will only take you so far in terms of managing quality and maintaining security in a new world of inter-company computing dependencies. It’s inevitable that if we are to realize the full potential of the Internet as a medium for automated electronic interaction, we holistically approach the challenges which allow us to engage one another on the largest of scales — everyone talking to everyone.


To efficiently enable wide-scale identity federation, without incurring incremental costs which are proportional to the number of relationships which are established, both technology and business standards must be established and new frameworks for creating these relationships explored.


 



 Figure: Four major areas which must be addressed to enable wide-scale identity federation.




Furthermore, the business issues of mutual confidence, liability, risk and compliance must be consistently and cost effectively addressed if inter-company interaction surrounding identity is to become a reality.


 




In analyzing the complete spectrum of technical and business issues surrounding wide-scale federation, the following challenges must be addressed:


Interoperability Standards
Technical interoperability is the cornerstone of efficient wide-scale federation.  Less interoperability, the full potential of identity federation will never be achieved. Addressing interoperability requires cross industry cooperation to ensure that the resulting solutions address the wide range of systems with which it must integrate. The Liberty Alliance Project is one such consortium which understands the need for open standards surrounding interoperable identity.


The mission of the Liberty Alliance Project is to establish an open standard for federated network identity through open technical specifications.
Liberty Alliance Project Website


Managing the Needs of All Constituents
Unlike the management of identity within an enterprise, where user data is deemed proprietary and an asset of the corporation, federated identity requires the privacy requirements of the principle be satisfied and that the exchange of data does not violate government legislation such as the Health Insurance Portability and Accountability Act (HIPPA) or Gramm Leach Bliley Act (GLB). 
 



Figure: Successful identity federation requires that the needs of three different constituents be met: 1) individual, 2) government and 3) business.


 


The challenge of federated identity lies in managing – and indeed aligning – the needs of all three constituents. Without a structure for doing so, constituents might soon find themselves at odds with government legislation, privacy concerns of consumers or the needs of business to better serve their customers.


Ever Expanding ‘Circles of Trust’ – Peering to the Nth Degree
As companies engage ever larger concentric circles of trust, moving from known and trusted trading partners to first time interactions with a growing number of entities, a requirement to establish legal agreements becomes ever more evident. Practically speaking, while it’s possible to establish agreements with a few dozen entities through bilateral negotiation, it’s entirely cost prohibitive and impractical to do so with hundreds or potentially thousands of companies.



To overcome this challenge, new models of peering must be explored — models which do not introduce proportional costs, or an inconsistent handling of relationships.


Dispute Resolution
Just as the necessary business agreements must be established for the federation of identity, so too the necessary measures of resolving disputes. Imagine a customer of an online brokerage firm who uses a shared identity to access their account to perform a critical trade but is unable to do to so as a result of a problem stemming from the shared authentication. Who’s at fault? Who’s financially liable? What’s the individual’s recourse? And most importantly, what are the efficient and timely procedures for revolving the incident? Without a defined resolution process to the issues which will arise as a result of inter-company dependencies such as this, the legal ramifications alone would prohibit voluntary interaction.


Liability
In today’s electronic environment, liability is both compartmentalized and binary, each party specifically limiting or explicitly refusing to incur any liability which results from assertions or representations to third parties. With a movement towards web services and identity federation, inter-company dependencies become fundamentally more substantial and the potential ramifications which may result from assertions which are inaccurate more damaging.


Initially at least, it is unlikely that any additional liability will be tolerated as companies begin to engage one another in federated identity interactions. While this may be satisfactory (because the risk is known) when dealing with known and trusted trading partners, it becomes less tolerable when engaging or relying upon an unknown company’s assertions. Long term at least, the future of web services and identity federation depends on the industry at large defining acceptable methods of addressing quality in identity assertions, thereby reducing the risk of financial liability. Furthermore, accountability must be established as companies engage one another in asserting identity or other forms of information within the larger context of federation.


Quality Assurance
Overall, addressing the issue of quality is a major challenge in the context of wide-scale federation. Without an ability to assure or affect quality in the assertions which are made between companies, the cost of misplaced trust outweighs the rewards of relying upon others.


A foundation for enabling quality begins with an ability to define minimum standards and requirements, and an assertion by each party which is either self-certified or independently certified that they can and will adhere to these minimum requirements.


Furthermore, legally binding recourse must be defined in a context which motivates (if not rewards) each party for continual improvement in the quality of the assertions which they represent to other relying parties. 


Revocation
One of the risks of identity federation is that security becomes interdependent, a notion which is viewed negatively or in some cases unacceptable by IT. Furthermore, as an identity-owner, the possibility that linked accounts (within an identity federation) can result in additional damage to a digital reputation if compromised by identity fraud is potentially terrifying.


How therefore companies can minimize the inevitability of security breaches and the resulting damage or financial exposure is of major concern. Defining the procedures for revoking credentials, suspending an identity or lowering the confidence in a particular interaction below some threshold must become an integral component of any quality assured identity network.


Risk Management
Every interaction which involves a third party inherently introduces new risks. While every company’s tolerance for risk is different, each company must evaluate for themselves how much they are willing to invest to reduce risk.


Within the context of wide-scale identity federation, the risks of misplaced trust can easily outweigh the potential return of having the freedom to interact with everyone. That said, the risk of isolationism can result in a loss of marketshare to those companies who better serve the same customer.


In today’s non-federated environment, risk is both assessed and addressed on a company by company basis, a format which is appropriate, but also expensive and inappropriate or perhaps even cost prohibitive if new variables are introduced through federation. While federation introduces new risks, it also introduces new possibilities, and requires new approaches towards addressing those problems. With proper coordination, both group and individual risk can be minimized through a pooling of efforts. One of the ways to address this collectively is to define for the federation the same minimum quality standards, standardized procedures, certification and credentialing programs which are used individually, and to track the adherence to these standards and the success or failures of each interaction.


Privacy Compliance
As identity authentications and attributes are shared within an identity federation, businesses are compelled through privacy legislation to be cognoscente of the individuals privacy rights and preferences.  Identity federation simply does not work if an individual is subjected to differing privacy policies but is not explicitly made aware of such fact as they move from one company to the next within a SSO interaction.  Privacy legislation such as HIPPA and GLB are making these issues ever-more complex. As noted earlier, identity federation MUST accommodate the needs and desires of all three constituents, the individual, the business and the government. Once again, a pooling of resources within an identity federation can reduce redundancy and thereby alleviate or help to solve many of these issues.


 


Defining a Solution: The ATM Network Analogy
One potential framework which can serve as a model to understand how many of the challenges surrounding federated identity can be resolved can be found in the analogous history of the evolution of ATM and other financial networks.


For hundreds of years, the banking industry was characterized as a local or regional business. With the advent of ATM’s, it became possible to extend a bank’s presence to allow cash withdrawal 24/7 from a much greater number of locations. While this enhanced consumer convenience, it also created a problem, namely, how could individuals remove cash from ANY ATM, even if that ATM was not sponsored by the individual’s bank.
To resolve this issue, banks began to regionally establish ATM relationships with other banks, and to invest in connecting their systems electronically through dedicated links to one another. While this solved some of the problems, at least locally, it didn’t resolve how the traveling individual withdrew funds from an ATM in another state or country.


Once more, it was becoming increasingly cost-prohibitive for banks to negotiate and establish what appeared to be a never ending number of electronic relationships with other banks.


In response to this problem, national and international ATM networks were established to respond to this “PeeringNth” degree dilemma. By establishing a set of common operating rules and regulations, these new independent third party ATM networks were able to address the quality control issues surrounding minimum requirements and standardized procedures while at the same time reducing a requirement for every bank to communicate directly with every other bank (by offering transaction clearing house services).


At the core of many of these networks was a member-owned corporation that provided for a fair and equitable governance structure, affording its membership an opportunity to define for themselves the operating rules and minimum requirements with which they would engage one another.



Enter the PingID Network – An Identity Network Operator
The PingID Network is a member-owned, technology-neutral identity network, the first of its kind designed to provide the necessary business and legal framework for the accelerated development of wide-scale identity federation. 


The rapid adoption of identity services in the absence of formalized inter-company business processes, procedures and standards will result in a patchwork of isolated solutions and a growing and inefficient replication of unmanageable legal agreements. An organized effort is required to represent the best interests of the business community and the end-user at-large. This is accomplished by establishing the business process standards which are required to ensure security, reliability and interoperability.


By joining PingID, member-companies are afforded an opportunity to instantly engage all other Network members in quality assured identity-based interactions.


Member Services Include
• Standardized business / legal agreements for federation
• Standardized interoperability rules and dispute resolution procedures
• Shared services for enhanced interoperability and identity interchange
 




Member Benefits Include
• Reduced cost of federation – standardized agreements, shared resources and pooled knowledge make widespread FIM affordable across all market segments.
• Reduced complexity – as peering becomes standardized, it reduces a requirement to maintain one-off relationships.
• Increased interoperability – a standardized business framework combined with enhanced identity interchange services improves interoperability.
• Improved ability to comply with privacy legislation – by providing services which help individuals manage their privacy preferences, enterprises are better equipped to deal with existing and new privacy legislation.
• Improved trust – by providing enhanced services which enable distributed trust, companies can engage one another with increased confidence.
• Improved framework for resolving new issues – by providing defined procedures for resolving emerging issues, companies can spend less time focusing on identity and more time focusing on their business.


 


Conclusion
Businesses are challenged with two seemingly opposed trends, the need to increase access to information and the need to maintain security. As firewalls become increasingly semi-permeable, companies are forced to re-examine their approach towards security. New digital identity constructs are serving to help solve this dilemma, allowing known entities to access information with confidence, but new infrastructures are required to manage these identities. Corporations are now beginning to invest in identity management solutions to help them manage users, roles and permissions but these solutions do not address many of the issues that result from inter-company identity services (identity federation) such as shared sign-on. 


As companies enter into an ever-increasing number of electronic relationships which involve identity, there is a commensurate need for a common business framework that will provide for an adherence to consistent end-user handling, a means for dispute resolution and a baseline for privacy compliance.


Through common business frameworks, pooled resources and shared services, companies can efficiently and with confidence engage one another in wide-scale federated identity services.


The PingID Network is one such common business framework, designed to accelerate identity federation, improve confidence through quality assurance and minimum standards and reduce costs through shared services within a fair and equitable member-owned governance structure.  The PingID Network lays the foundation needed for quality-assured, wide-scale identity federation, enabling enhanced interoperability and improved reliability, security, and process efficiencies.


Download Whitepaper (PDF – 594k)
End of Whitepaper


(C) Copyright 2002-2004, Ping Identity Corporation

Jabber Messenger – A Big Step in the Right Direction

September 22, 2002 By: Andre Category: Musings

Jabber, Inc. recently announced the Jabber Messenger, a much anticipated update to the JIM instant messenger client which had been in circulation as the official Jabber client for over 18 months. (but was never meant originally to be anything more than a demo of Jabber client funcationality that had overgrown it’s original intended use).


Jabber Messenger is based upon Disney’s Go Instant Messenger, which was written in C++ (unlike the JIM client, which was written in Delphi) and has some fantastic built-in features.


The updated client does several things for Jabber, Inc.


– it provides solid footing to develop out it’s client offering, balancing the sophistication and robustness of its current scalable server offering with a client which can truly provide some powerful desktop features in the years to come.


– it incorporates a much needed auto-client-update feature which will ensure that from here on out, the Jabber client installed base will be using the latest-and-greatest Jabber, Inc. has to offer.


– it incorporates much better window handling behavior.


– with an embedded IE browser within the client and a tab structure for adding content dynamically, it now provides a client platform (programmable from the server) capable of extending generic notification services to the desktop and dynamically updated XML content. Positioned correctly to the developer and enterprise community, this is a HUGE feature, and one which provides a foundation for corporations and service providers deploying IM services to build upon. It’s also the first step towards what I envisioned as a ‘universal communications client’. One which is fully programmable by the server and context sensative (taking on a different UI) based upon what communications it was engaged in.


As I initiated the negotiations to have Jabber acquire the Disney IM client some time ago, it’s pleasing to see that something came of those early discussions, and even more pleasing to see what a solid job Jabber has done in incorporating it into its strategy.

Anatomy of a Digital Reputation

April 30, 2002 By: Andre Category: Musings

The notion of a digital reputation first came up in my discussions with Phil Becker, editor of Digital ID World about three months ago. Ever since then, I’ve grown in my fascination over the concept of reputations, what they are and how a digital reputation might mirror reputations in the real-world.

Reputations are both deep and complex at the same time, in one instance serving to amplify reality (“…she was larger than life.”) and in another instance oversimplify it, (“…he’s amazing.“). Reputations are not limited to people, but can and do apply to groups, organizations, companies, countries, governments and even objects.

Having a good or positive reputation can serve to make your life easier, (e.g. “…of course I trust you, your reputation precedes you.“) just like having a negative reputation can work against you, many times in ways that you’ll never even realize (e.g. “…his resume looked like a perfect match, but when I inquired others who knew him, I found he had a poor reputation as a team player, so I didn’t hire him.“)

But what is a reputation and how might a digital reputation affect you in the future?

First of all, a reputation is not something that’s internal to you. Yes, it’s YOUR reputation, but you don’t have a reputation with yourself per-say. Reputations only really exist within the context of your interactions with others, and therefore, a reputation can be viewed as existing in the space between you and others.

While a reputation can be thought of as distinct, separate and external to us all, they are inextricably linked to us, and don’t exist outside of the context of their owner for which they refer. In some instances, a reputation can become so independent from us that they ‘take on a life of their very own.’ In these cases, reputations can actually drive how we act, rather than how we act dictate our reputation. For example, sometimes we find ourselves acting in uncharacteristic ways, many times unconsciously, just to support an external perception amongst others of who we are that is no longer true to our being.

A reputation is comprised in part by what we say and what we do over some period of time and in some particular context of an interaction with others. As an individual, I might never know all of the different facets of my reputation, just as others might also never know every aspect of my reputation. Needless to say, reputations are important to us all because they affect us in very tangible ways, serving to make our lives easier or more difficult, depending on whether they are positive or negative.


The reason we care about our reputations is two-fold:
1) our reputation is often tightly coupled with our sense of self-worth, serving as an external reflection of who we are, or who we wish to be and
2) our reputation can precede our physical being, serving to ‘open doors’ or generally make our lives more convenient or to close doors, in which case we are blocked from doing something or going somewhere, and we might never know why.

At any moment in time, our reputation is nothing more than a snapshot of our historical interactions with others. If the snapshot supports what we say about ourselves, then our reputation is positively amplified (R+1). If the snapshot contradicts what we have said about ourselves, then our reputation is diminished (R-1).

As reputations baring any weight and credibility are only built over time, it’s difficult to truly circumvent their creation. This is often why we learn early the value of ‘borrowing’ a reputation. Namedropping is nothing more than an attempt to place oneself in the positive glow of another’s positive reputation, hoping that it will make our life easier in the process or gain us access to something which we would not normally have access to on our own. How many times have you specifically gone someplace with someone who you knew was bearing the credentials and reputation of being ‘well-connected.’ (e.g. “I’m good friends with the owner and he always let’s us in for free.“)

Reputations are likely the most important quality enabled by identity and I believe that digital reputations will likely become the core and central reason why individuals will choose to have a digital identity in the future.

eBay™ uses a simplified version of digital reputation to allow individuals to quickly see whether or not a buyer or seller is trustworthy in their ecommerce transactions, but what if the concept of a digital reputation was expanded to encompass all facets of ones identity. The reason this is important is that I may be completely trustworthy within one context and completely untrustworthy within another. Let’s examine the attributes of a reputation.

Attributes of a Reputation

What You Say – To begin with, many people believe that a reputation can be created by what they say about themselves. Bragging is in essence nothing more than a naïve attempt to short-circuit the creation of a positive reputation, often eliciting the exact opposite, which is a reputation that he/she is insecure. Of all the ways to create a reputation, telling people what they should think of you is both the weakest and carries the least amount of weight in the real world. That said, what you say about yourself can serve to amplify a positive opinion of you if it is consistent with your actions (in their experience). Likewise, what you say about yourself can negatively impact one’s image of you if it is inconsistent with their experiences with you.

What You Do – “Actions speak louder than words” embodies this attribute of an identity. Nothing serves to more quickly establish a reputation than ones actions. When we say, “…what they say and what they do are two different things,” we’re really making a profound statement about ones reputation, namely, ‘you can’t trust what they say, because in our experience, they don’t follow through.’ One’s perceived actions, combined with ones words, constitute the foundation of a reputation.

What’s Public – Certain elements of our reputation are public, that is, generally known by us (the owner of the reputation) and by others who know us. I know that many people think of me as creative and honest, two elements of my reputation that I consider positive attributes. Because I view these elements as positive and because I’m aware of them, I work hard to reinforce them by saying and doing things which are both creative and honest. Generally speaking, we work to reinforce positive elements of our reputation and diminish negative ones. If I knew that I’d been branded a ‘tight-wad’ when it comes to paying my bar tab, I might over-pay in the future to counteract a negative impression of my reputation as being generous.

What’s Private – Certain facets of my reputation are private, and will never be known to me or others. Individuals who choose to create a new identity are doing nothing more than running from their reputation. The same way that individuals might attempt to conceal their past and reputation from others, others might also feel compelled to conceal elements of our reputation from ourselves. While many of us are aware of some of the negative attributes of our reputation, we will likely never be aware of all of them, and as a result, we’ll never actually know when and where our future has been walled in or blocked off because of them.

What Context – Lastly, while in real life and in every day conversation we do in fact attempt to summarize an individual’s reputation (e.g. “…she’s an amazing person.“), the fact is, our reputation is contextual and it is quite possible for me to have a positive reputation in one area of my life with individual A and a negative reputation in another area of my life with individual B.

The Digital Reputation
While historically reputations have been a somewhat vague and subjective, in the digital world they are likely to become more objective, binary and long-lasting (all the reason to take them seriously). Biologically, time is a built-in eraser, allowing us to forget and move on. In the digital world however, where memory is cheap and caching the norm, our reputations are likely to become more persistent, at least in the areas in which the law has not intervened (e.g. driving tickets are erased every three years and bad credit every seven). Probably more important, in the digital world, our various reputations which are today disconnected are likely to become more connected, if not by us, then by others. Think this is far fetched? Don’t think for a second that my reputation as a frequent flyer is not in some way connected to my reputation as an individual who rents cars when I’m out of town, and that’s just the beginning.

The fact is, systems specifically designed to create and track our digital reputations do in fact exist today. They are disguised as cookies, packaged as awards programs and renamed to convenience time-savers. As individuals navigating an increasingly complex and interconnected world, our slime-trails spell money to the private sector, and control to the government sector. As the digital reputation is an off-spring of digital identity, ensuring that we maintain control in how they are built, used and accessed is essential to our future as a free society that holds dear our right to privacy.
 


Andre Durand is a contributing writer to Digital ID World and the CEO of Ping Identity Corporation, creators of Open Digital Identity Infrastructure.