rfi User-Centric Identity and Principles of Internet-Scalable Identity Metasystems

All:

Just to publish a thoughtstream that's been trickling and babbling like a breaking brook in my brain.

First off, I'd like to suggest that what we should be focusing on is not "user-centric identity," per se, but "internet-scalable identity metasystems" (a thought that Andre ping'd me on and Dick got me to take to hardt). What are the principles for making our identity metasystems truly internet-scalable? Could it be that user-centricity (however defined) is a necessary (but perhaps not sufficient) condition for internet-scalability?

Now, let's look back to that previous post where I enumerated the main internet-scalability questions that Mr. Hardt laid out for our consideration:

• How do we scale up user-centric identity schemes, in which claims/attributes flow through and are forwarded by the user, so that they work on an open internet scale, not just within self-contained federations or circles of trust?
• How do we enable the free movement of claims from anywhere to anywhere?
• How do we extend lightweight identity management to the "long tail" of websites that don't and won't implement a heavyweight trust/federation model such as SAML or Liberty requires just to do chained/proxied authentication?
• How do we leverage the same core universal lightweight internet design patterns--i.e., REST using URIs and HTTP/HTTPS--to do internet-scale ubiquitous identity?

Now I'm going to slightly shift the context for a moment to Kim Cameron's "laws of identity," and then attempt to map that, plus Hardt's concerns, back to the notion of what it takes to make an identity metasystem truly internet-scalable. First, what I'll do is just republish Kim's actual written principles, but in a different order:

• 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.
• Pluralism of Operators and Technologies: A universal identity system must channel and enable the inter-working of multiple identity technologies run by multiple identity providers.
• Human Integration: The universal identity metasystem 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.
• User Control and Consent: Technical identity systems must only reveal information identifying a user with the user’s consent.
• Minimal Disclosure for a Constrained Use: The solution which discloses the least amount of identifying information and best limits its use is the most stable long term solution.
• Justifiable Parties: Digital identity systems must be designed so the disclosure of identifying information is limited to parties having a necessary and justifiable place in a given identity relationship.
• Directed Identity: A universal identity system must support both “omni-directional” identifiers for use by public entities and “unidirectional” identifiers for use by private entities, thus facilitating discovery while preventing unnecessary release of correlation handles.

Now, I'll reclassify/regroup/rewrite these principles into three higher-order principles:

• Abstraction: An internet-scalable identity metasystem must provide all end- and intermediary entities (i.e., users, identity agents, IdPs, RP/SPs, identity brokers, etc.) with a consistent, abstract, standardized , lightweight, reliable, speedy, and secure experience/interface across all use cases, interactions, credentials, protocols, platforms, etc while enabling separation of identity contexts across myriad domains, operators, and technologies.
• Heterogeneity: An internet-scalable identity metasystem must enable seamless, standards-based interoperability across diverse identity use cases, interactions, design patterns, credentials, protocols, IdPs, RP/SPs, platforms, etc.
• Mutuality: An internet-scalable identity metasystem must ensure that all end- and intermediary-entities (i.e., human users, identity agents, IdPs, RP/SPs, identity brokers, etc.) can engage in mutually acceptable interactions, with mutual risk balancing, and ensure that their various policies are continually enforced in all interactions, including, from the human user’s point of view, such key personal policies/peeves as the need for unambiguous human-machine communication mechanisms, privacy protection, user control and consent, minimal disclosure for a constrained use, limitation of disclosures to necessary and justifiable parties, and so on and so forth.

Now, how would conformance to these three wordy uber-principles contribute to internet-scalability? Well, abstraction is the face of the universal interoperability backplane of any ubiquitous infrastructure (be it REST, SOA, ESB, or what have you). And heterogeneity is the fabric of any hyper-decentralized, federated, multidomain interoperability environment. And mutuality (i.e., a balancing of rights, responsibilities, risks, restrictions, rewards, etc.) is essential for any endpoint (e..g, the end user, an RP/SP, etc.) to participate in this heterogeneous, abstract environment with any degree of confidence that they can fend for themselves and actually benefit from plugging in.

User-centric identity got going as an industry concern when it became clear that federated identity environments are not always mutual, from the end user's point of view. In other words, under "traditional" federation, some "attribute authority" (not necessarily under your or my direct control) may be coughing up major pieces (attributes) of our identity to unseen RP/SPs (also not under our control) without consulting us on the matter. In other words, those RP/SPs can selectively deny us access to the resources (i.e., apps, data, etc.) we seek, but we often can't selectively deny them access to the resources (i.e., our identity attributes) that they seek. Doesn't seem like a balanced equation, does it?

Now, tying all this back to Dick's key design criteria for the identity metasystem (in summary): open, free, lightweight, ubiquitous interaction patterns. Seems to scream for abstraction plus heterogeneity plus mutuality, which are necessary and, taken together, sufficient conditions for internet scalability.

In other words, necessary for the identity metasystem to be universally feasible, flexible, interoperable, implementable, extensible, and acceptable.

Jim

rfi User-Centric Identity and What Roger Sullivan Said

All:

We spoke on Feb 16, and he spoke primarily in his capacity as president of Liberty Alliance. We're scheduled to speak again next week.

First off, Roger said that Liberty wants to participate in industry discussions and work to develop user-centric identity into a tangible, practical reality. In fact, several people active in Liberty--including Brett McDowell, Eve Maler, and Conor Cahill--are taking a more proactive role in this regard.

I pointed out to him that, when I first looked closely at this new wave of user-centric identity projects, I experienced deja vu. A few years back, during my Burton Group days, I did a consulting gig with Liberty during the period when they were first developing ID-WSF, and I noted that the core use case then--"permission-based attribute sharing"--seems to be also the core use case for CardSpace, OpenID, and other efforts now. Why is this? Did ID-WSF miss the mark? Or is it too heavyweight? Or are the new up-and-comers reinventing a perfectly fine wheel? Or is it a fifth wheel for a vehicle still under assembly?

"Yes, Liberty Alliance collaborated on this use case a few years ago for ID-WSF," said Roger. "Now I don't want to dampen the enthusiasm of people who are working on these new projects [outside Liberty]. There are legitimate new use cases being developed: anonymity, rightful anonymity, and transition from such an environment to a more trusted relationship. We must bridge from self-asserted identity environments to federated identity environments such as Liberty and SAML." He mentioned that Liberty has scheduled an open forum to work on these issues at its upcoming April session in Brussels, and that the forum is open to non-Liberty members. He also pointed out that non-Liberty members are encouraged to participate in the Liberty-hosted wikis at openliberty.org.

Bottom line about user-centric identity, though, says Roger, is that it's only half the equation: "People usually discuss this topic as referring to having complete control over my own identity and credentials at some level. But for you to trust me, the attestation of my credentials must come from a trusted third party. The challenge the industry faces now is that a novice person comes to the identity management space and their instinctual reaction is 'I don't want anybody to know anything about me.' But how do you do e-commerce [under those conditions]? How can I have trust in you? The novice might respond: 'from that little lock in the lower right corner of my browser.' But of course that's ridiculous. To grow the [identity management] industry, proponents of self-asserted identity models must come to reconciliation with third-party-reliance services, in order to define use cases that move from user-centric identity to [mainstream federation] environments within e-commerce."

Roger said a lot more, all of it interesting. When I circle back with him, I'll flesh out this blogpost, or do a new one, that brings it all into the thread.

Jim

rfi User-Centric Identity and What Dick Hardt Said

All:

I spoke with Dick yesterday. Just before the call I realized that we had met in a previous life, when I covered the anti-spam space and he ran ActiveState....which he sold (to who?...I forgot) and started SXIP a few years ago. I covered anti-spam as an identity management problem. Anyone out there remember that paper? I might have rehashed it in this blog somewhere in the early days...don't recall. Anyway, just want to point out that I periodically inject identity management back into new contexts in my career (such as the advisory report I'm germinating in my head for Current Analysis, wherein I'll converge IdM with MDM via CDI....still keeping that pot on the back burner....overtaken by more pressing things to dissect...such as today's Oracle acquisition of Hyperion). Or new assignments (such as this gig for BCR).

Anyway, nuff a me, more of Mr. Hardt. He drew a distinction between user-centric identity (the new waves of identity systems in which identity data flows through the user/subject/principal...equivalent to Eve Maler's take on user-centric identity, but also, interestingly, refers to the original SAML implementation profiles as well....browser/artifact and browser/post) and domain-centric identity (i.e., traditional identity systems, characterized by the primary flow of identity data through the directory, IdP, etc.). He also quickly moved the discussion away from user-centric identity, per se, to "internet-scalable identity" (i.e., the same focus taken by Andre Durand and Ping Identity in their excellent recent whitepaper).

Dick asked (and here I'm paraphrasing several things he said at several points during our discussion): How do we scale up user-centric identity schemes, in which claims/attributes flow through and are forwarded by the user, so that they work on an open internet scale, not just within self-contained federations or circles of trust? How do we enable the free movement of claims from anywhere to anywhere? How do we extend lightweight identity management to the "long tail" of websites that don't and won't implement a heavyweight trust/federation model such as SAML or Liberty requires just to do chained/proxied authentication? How do we leverage the same core universal lightweight internet design patterns--i.e., REST using URIs and HTTP/HTTPS--to do internet-scale ubiquitous identity?

As regards identity system scalability, Dick proposed a really interesting analogy (again I paraphrase): Domain-centric identity is like a leased line. Federated identity is like frame relay. User-centric identity is like IP packets.

He said user-centric identity--where it's incumbent on the user/subject to collect, assemble, and present their diverse claims/attributes to each RP/SP they wish to access--might be the most scalable, lightweight, feasible approach for making roles and entitlements portable across federated domains. And for easing the role administration burden within domains. As long as the claims/attributes they're presenting are currently valid in the trusted attribute authority domain that issued them.

Which brought my head back to this thought of user-centric identity for personal role multiplicity management. Or whatever I called that mashup of a notion at the beginning of this current blog thread.

Jim

rfi User-Centric Identity and What Eve Maler Said

All:

Eve sounded as rushed and frazzled today in our call as I always sound (and feel). She only had a limited amount of time, and I understood totally. But we got in a good half-hour of quality interaction, and she was articulate and insightful as always.

I ran down my list of interview questions, skipped some, and let her expand on topics of special interest to her. What stuck with me most was her approach to discussing the definition of user-centric identity.

She focused on the centricity of the user in the data flow during a login attempt, distinguishing between the "human present" interaction mode (i.e., the actual human user/subject is online during the transaction, responding to prompts, selecting i-cards, deciding whether or not to disclose this or that personal attribute to this or that relying party), vs. the "human absent" interaction (i.e., the human user/subject is not actually online during the transaction on which they are a principal, but, instead, an identity software agent/intermediary or delegated other human user is selecting i-cards, disclosing attributes etc. on their behalf).

She pointed out that most of the current crop of user-centric identity schemes (i.e, MSFT CardSpace, OpenID, etc.) focus primarily on the "human present" mode, which, as Eve stated memorably, means that the "user's policy is in their brain." By contrast, she pointed out, Liberty's ID-WSF was developed to support both the "human present" and "human absent" modes.

Eve said she didn't want to be understood as arguing that one or the other mode is best, but simply that they both have their proper roles and should both be supported in a comprehensive identity environment (user-centric or whatever). She took pains to point out that user-centric identity is orthogonal to, not mutually exclusive with, "traditional" federated identity of the SAML and Liberty variety. I pointed her to the excellent whitepaper recently published by Ping Identity that lays out the convergence scenarios (OpenID+Liberty+SAML+*****) in wonderful brain-opening detail.

On another issue, she noted that OpenID 1.0 has a vulnerability in that it leaves users' identities open to possible correlation by unauthorized third-parties. But that CardSpace has a vulnerability of an opposite but equally problematic nature. Given that each CardSpace is associated with a particular client device (i.e., a particular desktop, laptop, or mobile phone running Vista), and given the fact that each user might have multiple such devices, each with a multiplicity of cards running on them...that the more such devices, cardspaces, and i-cards multiply for a given user, the more difficult it will become for a particular user to correlate the various fragments of their identity across their own personal "space."

At which point, what each of us might need is a federation of personal cardspaces (this last thought just came to me....Eve didn't offer up this particular thought...but she inspired it...thanks Eve...next time I'm up in Redmond or thereabouts....coffee).

Jim

rfi User-Centric Identity and SOA Mashup Governance

All:

User-centric identity is just one subtopic in a more completely user-centric SOA/Web 2.0 world.

In fact, most of the Web 2.0 paradigm is user-centric. It focuses on enriching users’ interactive online experiences, letting them express themselves as they wish, build personalized presences, reach out to each other, create community, and concoct new content. Consider the many approaches subsumed under the heading of Web 2.0--AJAX, RSS, blogs, wikis, social networking, folksonomies, podcasting, mashups, etc.—and you can see that it’s mostly focused on helping users thoroughly shape, populate, and colonize the online environment.

As a growing phenomenon, much of user-centric identity has grown directly out of the Web 2.0 application paradigm. For example, OpenID was designed by the blogging site LiveJournal as a means for chaining logins among federated blogs so that a browser can leave authenticated comments at other blogs they visit. Essentially, this is user-centric identity federation, where users self-assert their identity (i.e., their blog URL, such as jkobielus.blogspot.com), self-publish their own identity attributes (i.e., the descriptors about themselves that they choose to place in their online profiles), and self-publish their own content (i.e., postings such as this), and/or mashups of content culled from the online universe.

As a Web 2.0 development approach, mashups are highly user-centric, or should be. On the one hand, a “mashup” application is essentially the same as a “portal” application—i.e., an aggregation of links to content/services generated/hosted elsewhere. But a mashup is something that the end user—not just professional programmers--can and should create, drawing both from their own resources and linking to whatever they can discover on the open Internet (and intranet, and extranet). Also, a mashup is something that represents the user’s own style and soul: spontaneous, individualistic, anarchic, creative, transitory, funky, unpremeditated, edgy, etc. And a mashup is something that repurposes others’ networked resources without necessarily gaining their prior permission.

This latter point is where the intellectual property lawyers—and privacy advocates--start to get real nervous. Likewise, anybody who has gravitated to the user-centric identity paradigm because they want to enforce “permission-based attribute sharing” over relying partners’ access to their own self-asserted identities (and to the self-asserted/published attributes and content linked to those identities) might worry about someday seeing themselves and their creations mashed up into an alien (non-revenue-producing) context by total strangers.

Which brings me to the notion of “mashup governance.” I didn’t originate the term—it came from a recent article by Dave Linthicum:

Enterprise mashups meet SOA
http://cwflyris.computerworld.com/t/1284237/1375321/51908/2/

"Governance -- the creation and enforcement of design time and runtime policies -- is tricky business for mashups. Given that mashups are made up of services and may indeed become services themselves, you need to manage these services across the entire lifecycle, as with any service or process contained in an SOA. Among other things, this means selecting, building and maintaining a mashup-aware registry/repository. However, although mashups need to be managed, you should avoid overloading them with policies and procedures, or you'll discourage developers from creating them.

Mashup security is critical, considering that you're looking to leverage interfaces, content and services you neither created nor own. No one wants to discover that an innocent-looking AJAX mashup is actually sending customer data to some remote server and compromising the business. Care must be taken to implement security policies and technology layers that will protect the value of the mashup platform. This should mesh with your SOA security or become an extension to it."

This interesting concept deserves greater development. How exactly would one represent complex, creative, presentation-layer compositions in a "mashup-aware registry/repository"? Do RDF, OWL, and the rest of the Semantic Web paradigm come to the forefront in this new order in defining the hypercomplex linkages of many mashups? How about the identity management side of the equation? How does one represent the welter of entitlements, access controls, and federation relationships among mashup providers and consumers in such a registry/repository?

In design-time mashup governance, one’s first impulse is to apply the same formal/professional design-time SOA governance regime (best practices, approval workflows, service promotion life cycle, access/version controls on registry/repository, etc.) to mashups as to any other service. But that’s essentially strangling the very notion of a what makes a mashup special—the ungoverned, unpremeditated, unprofessional expression of motivated users cobbling together found resources into a bold new creative synthesis. That’s what Dave gets at with his statement: “you should avoid overloading [mashups] with policies and procedures, or you'll discourage developers from creating them.” Of course, from there it’s a slippery slope toward dissolving any and all design-time governance controls on creation of any SOA/Web applications—on the grounds that to enforce those controls stifles developer creativity.

One middle ground is to provide users/developers with corporate-standard mashup development tools/frameworks that prevent them from coloring too far outside the lines of permissibility, in terms of the provenance of the resources they can mashup, the look-and-feel permutations of supported mashups, and the presentation platforms to which the mashups can be published. They can exercise all the mashup creativity they wish, but within the constraints of standard mashup toolkits and policy environments.

Spontaneous-but-governed user-centric identity mashups are already here. Look at any MySpace site, with its mashed-up these-are-my-friends aggregated-profiles pages. The governance there is simply the ability of the attribute-owning/asserting parties (your friends) to deny you or anybody else in MySpace from viewing and/or auto-publishing/aggregating that info on your own MySpace pages.

There should be a standards-based mechanism for enabling a identity mashup governance in Web 2.0 environments. Ideally, federated blogging and social-networking communities should provide the means for users to be prevented from mashing up each others’ personal profile attributes. One way to do this is for the federated blogsites/communities to implement the IGF specifications that Oracle developed and recently submitted to Liberty Alliance.

Under IGF, the attribute-relying parties (i.e., the people who wish to access and mashup other people’s personally identifiable identity attributes) would place Client Attribute Requirement Markup Language (CARML)-based requests for these attributes, and indicate desired operations and usage on these attributes. At the same time, the attribute-owning parties (i.e., the people whose personally identifiable identity attributes are available for third-party mashing) would declare Attribute Authority Policy Markup Language (AAPML) policies (essentially XACML 2.0 profiles) that specify conditions under which those attributes may be used by relying parties. An intermediary IGF “Identity Attribute Service” would enforce policies that govern access by CARML-requesting entities to attributes controlled by AAPML-declaring entities.

That IGF Identity Attribute Service would be the key run-time governance component in a user-centric identity-mashup environment. It will be interesting to see how Liberty Alliance mashes up IGF with the permission-based attribute sharing features of ID-WSF 2.0.

Jim

rfi User-Centric Identity and What Mark Wahl Said

All:

Full Q&A, followed by not-so-kwik comment:

*************************

Is user-centric identity primarily a B2C requirement, or does it have applicability in the B2B world and inside the enterprise?

I believe there is definitely a role for 'user-centric-style'
operations within the enterprise, as identity management
functions and services decentralize to the workgroup.

What standards are being developed in this space, and/or how are older standards (e.g., Liberty ID-WSF, if you can call that "old") being applied to these requirements?

There is a lot of innovation going on in this space and I think it's a
little too early to nail down specifications for user-centric
identity as 'standards' - perhaps in a year or two we'll see standards
for user-centric that have value and are seeing deployment in the
enterprise deployments of IdM. Certainly also many existing identity
management standards are continuing to be evolved to address some of
the requirements that drove the user-centric pioneers.

How can user-centric identity and federated identity management coexist and complement each other?

That's too big a question for just this email!

How soon can we expect to see user-centric identity architectures baked into the leading IdM vendors' software suites?

I think that user-centric identity needs to prove itself in enterprise
deployments. If the early adopter phase shows promise that user-centric
services open new market opportunities, the suite vendors will, as many
times before, make build-vs-buy decisions to add these capabilities to
their suites.

How soon before we see user-centric identity environments enjoy the mainstream enterprise acceptance, adoption, and interoperability now found with SAML?

It's too early to tell. I'd say 2-5 years as a rough guess

Does Microsoft have an early-mover advantage with CardSpace in Vista, or is it far too early to pronounce "winners" in this fast-evolving space?

I think that Microsoft has a definite advantage in CardSpace.

What significant/serious interoperability, deployment, trust, security, usability, and other challenges do implementers face when implementing user-centric identity?

Yes, all of the above :-). I discuss some of these challenges on my
blog on ldap.com; for example,

http://www.ldap.com/1/commentary/wahl/20070206_01.shtml
"How is the relationship between an Identity Provider (IDP) and a
Relying Party (RP) established and maintained?"

http://www.ldap.com/1/commentary/wahl/20070206_02.shtml
"Identity relationship management"

http://www.ldap.com/1/commentary/wahl/20060926_01.shtml
"Social engineering: trust is just a five-letter word"

http://www.ldap.com/1/commentary/wahl/20060920_01.shtml
"PKI and the risks to importing a managed card"

http://www.ldap.com/1/commentary/wahl/20060911_02.shtml
"Key management concern for the InfoCard regions of an identity metasystem"

http://www.ldap.com/1/commentary/wahl/20050103_01.shtml
"Identity systems without discovery or public entities"

etc. I plan to write more on the topics of audit and controls on
integrating user-centric services into the enterprise, and on
managing the relationships between a user's identity and the components
of a decentralized enterprise IdM deployment.

*************************

Follow Mark’s links…very fascinating discussion of the trust management challenges that may impede user-centric IdM from becoming internet-scalable in B2B environments….in other words, the same devilish details that continue to dog SAML/Liberty-style federated identity.

Note specifically his discussion of Mike Neuenschwander’s Law of Relational Risk…in reference to which Mike proposes “a kind of ‘SSL’ sessions for relationships - for now I'll call it Relational Continuity Sockets Layer. It would allow multiple participants to interact on a channel that is secure for the duration of the relationship or at least one risk cycle (this means longer-lived sessions than SSL) and allows for relation IDs (similar to session IDs). Such an invention would also address the requirements of addressable relations... “

Relation IDs? Issued by the involved parties, or trusted third parties (TTPs)? If you follow the link to Mike’s blog posting, you can see that it practically screams for one or more TTPs to vouch for the good reputation/behavior of participants in a (user-centric and/or traditional federated) IdM interaction, and possibly to see to it that appropriate sanctions are applied in cases of bad behavior. Per Mike’s post: “As a means of promoting relational continuity, for example, the principles suggest that issuance of IDs to participants is only a partial solution. Relations must be addressable resources separate from the actors involved. Further, each relation needs a definition of roles—symmetrically formed—that embody equilibrium for participants. And there must be rules stipulating that participants can't leave a relation without either settling all one’s outstanding transactions or designating a proxy. And finally, as participants fill roles in the relation, they receive those rights by recognition of the participants (and not simply by issuance of an ID).”

All of this sounds like a convoluted way of saying a common trust environment and legal systems are needed to keep everybody on the straight and narrow. What could be more symmetric than a society that is ruled by impartial laws, rather than (asymmetrically) by dictators? Good governance: that's the equilibrium condition for any social environment. What Mike is talking about is a trust/legal system that enforces levels of identity assurance that strongly bind actions to consequences. I think everybody can agree that these assurance levels are as necessary in user-centric IdM (B2C or what have you) and in federated IdM.

All of which puts me in mind of a convoluted identity assurance model that I myself developed in late 2005 and published in 2006. This is written from the top-down, spelling out the complete set of credentials, assertions, claims, vouchers, and policy and practice statements that the involved users, IdPs, SP/RPs, and TTPs would need to publish/exchange in a global trust environment, thereby thoroughly binding all user actions to real (penal/financial/social) consequences. Unlike Mike’s model, it’s not focused on person-to-person relationships (a la user-centric identity and reputation systems) but the “person-to-authority” (e.g., IdP, PKI CA, etc.) relationship, per traditional federated IdM. So take it with a grain of salt.

Anyway, each level in the following chain of identity assurances associates the actions that a user takes in an online session with the consequences of those actions:

IDENTITY ASSURANCE FACTORS	REQUIREMENTS
Assurance of association between an online session and a credential	This requires client-signed session assertions, signed cookies, or other means for strongly binding an online session to a credential under which a user logged into that session. In turn, client-signed session assertions or cookies require PKI X.509 end-entity digital signature certificates and private keys. All that, in turn, requires strong PKI assurance.
Assurance of association between a credential and a digital identity	This requires PKI X.509 end-entity identity certificates, which cryptographically bind an identity’s private identity key to the corresponding public key, and to a unique identifier such as UPN, X.500 DN, or UPN.
Assurance of association between a digital identity and a real person	This requires PKI registration authorities to issue and renew X.509 end-entity certificates only after in-person proofing/vetting that involves having a real person present a government-issued picture ID and other supporting identifying documentation. It also requires that the request for registration or renewal of a PKI certificate/token obtain all necessary administrative approvals within the IDP that has issued the unique identifier that will (upon certificate issuance) be cryptographically bound to a public key (published in the certificate) and a private key (to which only that real person will have authorized access). In addition, provisioning of certificates to proofed users should only follow user authentication to the CA through entry of a one-time secret proofing passcode provided at proofing time by a trusted agent of the CA.
Assurance of association between a real person and an IdP	This requires that the IdP that issued the unique identifier published in the real person’s end-entity PKI certificates maintain that identifier in a published master directory administered and controlled by the IdP. The IDP’s master directory must securely and reliably synchronize, replicate, and/or publish that master identity information to other directories and repositories, or vouch via SAML authentication or attribute assertions for its continued registration in the master directory. In addition, the IdP must use identity information in that master directory to drive the automated provisioning and deprovisioning of accounts associated with real persons.
Assurance of association between an IdP and an IdP-asserted federated identity policy/practice statement	This requires that IdPs digitally sign any federated identity policy/practice statement that they assert with a digital signing private key held by an authorized corporate officer.
Assurance of association between an IdP-asserted federated identity policy/practice statement and a TTP-published federated identity policy/practice statement	This requires that one or more TTPs develop and publish standard federated identity policy/practice statement formats. It also requires that TTPs investigate, vet, and certify equivalence or conformance between an IdP-asserted federated identity policy/practice statement and a TTP-published federated identity policy/practice statement.
Assurance of association between a TTP-published federated identity policy/practice statement and TTP-vouched observation of identity’s demonstrated compliance with norms of IdM “best practice”	This requires that one or more TTPs track, monitor, and audit real people’s online behavior. It also requires that TTPs determine the degree to which that behavior conforms to the norms of IdM best practice that they and their IdPs have pledged to comply with, in the form of published federated identity policy/practice statement.

You can chain together symmetric person-to-person assurances, under my model, as a transitive linking of asymmetric person-to-authority assurances. In other words, you and I cannot exploit our common relationship because a TTP is cracking the same whip over us all.

Or something to the effect. All of which brings me back to a question I’ve been formulating: In user-centric identity environments, how do personal/private IdPs symmetrically federate to each other, in the absence of (one or more) TTP(s) to vouch for their respective good reputations/behaviors?

Jim

rfi User-Centric Identity and What Johannes Ernst Said

All:

Full Q&A follows:

***************************

How do you do define user-centric identity?

I like to distinguish two forms:

In the 'weak form', identity information about me continues to be
collected and maintained by third parties ("IdP companies") and I, as
the user, have a big say in whether or not I want that information be
transmitted to another party ("Relying Party"). This is an
improvement over the state of the art, where the IdP and the RP
company get together and decide what to do with my identity
information without me being in the loop.

A real-world example of this would be for me to decide whether or not
to take out my AA frequent flyer membership card to get a 5% discount
at Hertz.

In the 'strong form', I assert my identity information myself, and
I'm my own IdP (although I might outsource the technical details of
how to do that to a service provider). A Relying Party may use other
parties to corroborate what I said about myself, e.g. ask the state
government whether I'm indeed a licensed nurse, or ask a reputation
service about how likely it is that I'm a spammer.

The latter, Doc Searls called "independent, sovereign identity".

A real-world example of this would be me handing you my business
card. Or me writing something on Wikipedia, with you being able to
check how many other edits I made and how often I was "reverted".

Interestingly enough, and while they don't map seamlessly, URL-based
identity maps more to the 'strong form', while card-based identity
maps more to the 'weak form'.

Is user-centric identity primarily a B2C requirement, or does it have applicability in the B2B world and inside the enterprise?

It absolutely has enterprise applications. One example that one of
our customers pointed out to us: while much information about
employees is maintained by enterprises in places like corporate
directories (whether the employee likes that or not), other identity
information that is relevant to business often is not. For example:
cell phone numbers. Instead, employees want to keep control over when
to hand out their cell phone numbers and to whom. The same thing
might be true about instant messaging handles, presence status,
current location in the building, schedule, etc. etc.

What standards are being developed in this space, and/or how are older standards (e.g., Liberty ID-WSF, if you can call that "old") being applied to these requirements?

Many technologies can be applied to this field, and they probably
are. But in my view, the problem is one of distribution, not of
technology. The early boost here was LiveJournal, which gave OpenID
instant distribution to millions of people, which caused a virtuous
cycle that continues unabated. And then, of course, there is Windows
Vista and its distribution. Other technologies / standards / products
don't necessarily have the same distribution dynamics.

One thing that plays into this is the "weight" of the technology.
When we invented URL-based identity at NetMesh over 2 years ago, we
consciously called it "Light-Weight Identity". Because in our view,
only technology that's sufficiently low-cost (in total cost of using
it, not just software cost) has a chance of mass distribution, and
that's one of the reasons why so many sites have found it easy to
adopt OpenID and not so easy to adopt other technologies.

How can user-centric identity and federated identity management coexist and complement each other?

The key battle here will be at the boundary of the enterprise, where
self-empowered users (customers, contractors, partners, employees)
want to "bring their identity" and companies need to support this,
otherwise users (particularly customers) will go to a different
company that serves them as they want to be served. THe challenge is
to keep what's working inside the company, but allow for external
sources of identity via user-centric technologies / processes as
well; this will take some years to be figured out because it is
rather complex, but it certainly will get solved.

Certainly that is one of the recurring discussions we have at NetMesh
with enterprise adopters.

How soon can we expect to see user-centric identity architectures baked into the leading IdM vendors' software suites?

I would defer to those "leading IdM vendors" to answer that ;-)

How soon before we see user-centric identity environments enjoy the mainstream enterprise acceptance, adoption, and interoperability now found with SAML?

Interoperability in the OpenID world is excellent. There are dozens
of independent identity providers, dozens of independent software
implementations, and hundreds of relying parties: the reports of
interoperability problems are few and far between. (Somewhat to my
surprise, I have to admit). Note that all of this works without any
formal certification regime or even a shared test suite.

My understanding is that out-of-the-box interop of more traditional
identity products is something that happens less frequently.

The best guess for the OpenID growth rate right now is 5% per week
with about 1000 relying parties at this point, so you can do the math
when ubiquity arrives ...

Does Microsoft have an early-mover advantage with CardSpace in Vista, or is it far too early to pronounce "winners" in this fast-evolving space?

Far too early. Looking backward from a few years in the future, it is
very likely that we will say that in 2006, most people still thought
the product was "identity management software" and its hosted
equivalent. But now that virtually "everybody" in technology (see
membership list in OSIS) is working real hard to make the basic user-
centric identity layer free on the internet, the question about
winners and losers will be decided on a layer above or below that
free layer. As an industry, today we all have only very rudimentary
understanding what those layers even are. So it's too early to
declare even who the contenders are, never mind the winners!

Microsoft will clearly play an important role, as will websites with
a mass audience, and big enterprise vendors. But personally I would
bet on startups -- many new appealing business models are emerging
that appear incompatible with traditional technology business models,
and that gives startups an unfair advantage against the incumbents.

What significant/serious interoperability, deployment, trust, security, usability, and other challenges do implementers face when implementing user-centric identity?

I'm not quite sure I can give you an exhaustive list here. Some of
them probable include:
- the market is immature, and there is still more slideware and
beta software around than technology that has been proven
- as a whole, we don't know yet what the attack vectors of the bad
guys will be because the bad guys haven't really started attacking yet
- many pieces of technology are missing -- e.g. see James
McGovern's recent push for XACML-related things in an OpenID context
- the business ecosystem isn't there either -- e.g. how does an IdP
get compensated for taking on authentication risk?

However, what we're seeing clearly at NetMesh is that many leading
companies in their market realize that in spite of this, they have to
move very quickly to make their play, because there is a huge
economic network effect associated with user-centric identity, and
they can't afford to let their competitors benefit from that one
first, even if many answers don't exist yet. The vendors and the
adopters are learning together ... nothing wrong with that either.

So in spite of many obstacles, companies are moving, and quite fast
at that.

To what extent and at what speed are the URL-based schemes (OpenID, LID, iNames/XRI, mIDm, Yadis, etc.) converging into a single standard/framework?

On mIDm, I don't know whether that is an ongoing project.

All others have effectively converged into the same framework since we all adopted Yadis a year ago (which in itself was a combination of the discovery pieces of XRI, LID and OpenID).

There are lots of different pieces advocated by different people on top of that same framework, many of which are competing. But that's a feature, not a bug: it allows many parties to innovate and solve problems really well for those parts of the market that they play in, and it does not limit the market to whatever one particular approach can accomplish. As particular pieces become well-understood and broadly deployed -- as it happened with Diffie-Hellman-base, browser-based Authentication -- I expect those to be supported by everybody. This kind of higher-level convergence will happen faster for some and slower for others and never for some (e.g. vertical-specific services).

So I expect the XRI folks to continue doing things that won't be adopted by everybody in the OpenID community, just like we at NetMesh continue to have (and build more) service types under the LID umbrella that not everybody in the OpenID community relates to.

To what extent will self-asserted IdPs (which I believe is also supported in CardSpace) eliminate the need for traditional (multi-user/ID) IdPs?

There will always be a need for third parties to make statements about somebody else. For example, it is unlikely a shop keeper will sell me that bottle of Gin based on my self-assertion that I'm above drinking age but don't look it.

But how exactly that is done is a matter of ongoing dispute. I could show my driver's license (basically the CardSpace model). Or, I could create cryptographic proof that I'm above drinking age without you learning how old I am, nor the government learning that I bought booze (the Credentica model). Or, I could bring a thousand people who all say that I'm above drinking age (the "wisdom of crowds" model). Or, I could give the merchant permission to ask the government in real-time, either directly or routed through me (the "3rd-party confirmation model" that has the advantage that it works for information changing in real-time).

As these examples show, some of them map to the "traditional IdP" model. Others only sort-of, and some not at all (the "Wisdom of crowds model"). I expect the majority of the market growth to come from non-traditional models, although timing would be a conjecture ...

To what extent will companies allow their employees to selectively conceal privacy-sensitive attibutes (e..g, cellphone number, presence, location in building) when the trend has been toward tighter company monitoring of e-mail, IM, etc.?

Well, that highly depends on the company. If a company's success depends on their people making maximum use of their intellectual and social resources, then getting in the way of how people want to deploy those resources is not a particularly wise business decision. And the reverse is probably true as well.

**************************

Per what Johannes said, the "distribution" and "weight" of user-centric identity technologies will determine whether, when, and how they dominate the IdM space in coming years.

Federated IdM--a la SAML and Liberty Alliance--have gone mainstream, but they're still climbing the implementation curve. They're not widely distributed in the B2C sphere because they're heavyweight to implement (i.e., to set up the requisite interoperability, trust, and implementation agreements).

I spend a year in the wilderness working with a B2B trading community trying to kickstart federation (just for cross-domain SSO) by setting up multilateral, transitive trust relationships that passed muster with all the requisite regulators, lawyers, and beancounters--and, I can tell you, it was painful.

Perhaps portal-initiated SSO (the core federated IdM use case) is just not an "internet-scalable IdM" arrangement (per an excellent whitepaper recently authored by Ping Identity). Maybe RP-initiated multiple sign on (MSO)--the core user-centric ID use case--is the way to go. Just assume that SSO is too heavyweight for dynamic, Internet-scale IdM (be it B2C or B2B). Instead, give the user the tools (e.g, identity card selectors etc.) to make their MSO experience more convenient, secure, and standardized.

Jim

rfi User-Centric Identity and Specific Interview Questions

All:

I'd like to get your thoughts on the matter, specifically:

• How do you do define user-centric identity?
• Is user-centric identity primarily a B2C requirement, or does it have applicability in the B2B world and inside the enterprise?
• What standards are being developed in this space, and/or how are older standards (e.g., Liberty ID-WSF, if you can call that "old") being applied to these requirements?
• How can user-centric identity and federated identity management coexist and complement each other?
• How soon can we expect to see user-centric identity architectures baked into the leading IdM vendors' software suites?
• How soon before we see user-centric identity environments enjoy the mainstream enterprise acceptance, adoption, and interoperability now found with SAML?
• Does Microsoft have an early-mover advantage with CardSpace in Vista, or is it far too early to pronounce "winners" in this fast-evolving space?
• What significant/serious interoperability, deployment, trust, security, usability, and other challenges do implementers face when implementing user-centric identity?

Contact me at james_kobielus@hotmail.com if you're interested in responding.

Thanks.

Jim

rfi User-Centric Identity and the Definition of User-Centric Identity

All:

I've just been crawling through the blogosphere, the literature, my head, etc.....putting together a quick cheatsheet, definition-wise.

In some radical/fundamental/ideal sense, user-centric identity could conceivably mean any and/or all of the following:

• All user identities/attributes are self-asserted and provisioned
  
• All user identity interactions flow through the user's client, icard space, personal idp, and/or agent
• All user identities/attributes are immediately, conveniently, and visually available to the user from all clients/UIs to present to the appropriate relying parties
  
• All user identities/attributes are self-selected within the context of each interaction
• All user identity-based interactions are engaged in by the user with full knowledge, transparency, and nonrepudiation of the relying parties
  
• All user attribute disclosures require permission of the user and/or the user's authorized agent
• All user identity interactions contribute to the user's privacy
• All user attribute disclosures are anonymized, encrypted, pseudonymized, and/or minimized in each interaction
• All user identities/attributes are disclosed and distributed in such a way that they cannot be joined or correlated back to the user
• All user identities/attributes are stored locally under the user's control and protected through secret keys that only the user possesses and which are authenticated through multiple factors, including biometric

This list pretty much recapitulates Cameron's laws of identity. Just working through the analysis from a slightly different pov.

Jim

rfi User-Centric Identity and the Enterprise Market

All:

Re my message a moment ago to Sandy, from whom I never need to request interaction, because she's always beating me to the punch:

***********************

Sandy:

Thanks.

Re your question: "How likely is it (technically, not sociologically) they
will find something (desktop with Vista? Internet portal? freewares you
mention or ?) that works well at home and that they will then take to work,
or take the demand for it to work?"

My tentative, hedging, heavily qualified response:

It's 50-50 likely.

In other words, look at various now-ubiquitous business clients/tools/apps
that got their initial commercial push (to a degree) in the B2C space (e.g.,
the Web, Internet e-mail, e-commerce, cellphones, WiFi, instant messaging,
VoIP, social networking) and then penetrated the enterprise (intranet, B2B,
etc.) market in a (big, medium, or small-but-growing) way (we could easily
debate which demand-side driver, B2C or enterprise, had the first-push in
each of these segments, but it's undeniable that the B2C acceptance was
fairly strong from the start in all of them).

Now look at the identity management space--in which, B2C-wise, trusty ol'
username/password still rules, and in which federation (SAML, Liberty, etc),
is still not a major force, but in which the enterprise/B2B demand-side has
been the dominant driver for federation.

Now look at "user-centric identity" as an IdM approach that's originating on
the B2C side, not so much as an alternative to federation but as a sort of
adjunct that will eventually converge with federation if/when user-centric
identity penetrates (to varying degrees) the enterprise market.
Enterprises are not generally "user-centric," where their employees are
concerned.

Instead, enterprises are "company-centric," with a strong bias/inclination
toward "owning" their employees' identities/credentials/attributes and
controlling them tightly.

In other words, enterprises (i.e., IdPs run by your employer) provision you
your identity, and reserve the right to deprovision it.

This is the opposite paradigm from the radical "I issue, own, and manage my
own identity" ethos/ideology that motivates many folks developing the
"user-centric identity" space.

Bottom line: Employees will demand user-centric identity from their
organizations as a tool for managing the diverse identities (e.g., roles)
that they play with respect to those organizations (e.g., formal job
description role, plus roles specific to each solid-line and/or dotted-line
reporting relationship, plus roles specific to various projects/teams in
which I participate for this company). User-centric
business-role-multiplicity management.

Or something less wordy. I'm working on it.

Jim

***********************

Your words welcome: james_kobielus@hotmail.com.

Jim

rfi User-Centric Identity and the Convergence of Paradigms

All:

Carrying forward this request for interaction (thanks, Bob...I'll contact you shortly, and thanks Andre, for yesterday, and for those couple of days in early December 2004...and Craig Burton, wherever you are....ironic to finally meet you at that particular point in my life...).

One thought that's occurred to me is that this new focus on "user-centric identity" is a bit of 2001-2002 redux. Early in this decade, when the topic of identity management (IdM) was just heating up, the industry was grappling with the issue of Microsoft-uber-alles (Passport, i.e., identity aggregation) versus uber-our-dead-bodies (SAML, Liberty Alliance, etc., i.e., identity federation). Now, here in 2006-2007, it's once again Microsoft (taking the lead, implementation-wise, in this new twist, user-centric identity, with another bold initiative, CardSpace, that's a bit ahead of the eventual standards, and may or may not be the ultimate approach that Microsoft and others settle on when the industry dust clears in, let's say, 2013) versus the rest of the industry (e.g., Higgins, Bandit, OpenID, Yadis, OSIS, LiD, iNames, mIDm, SXIP, etc.).

But, of course, the "versus" is a softer, more collegial thing this time around, considering that Microsoft has just declared (through the still somehow in the game though he sorta said he was retiring Bill Gates) that it will implement OpenID 2.0 in CardSpace...and Kim Cameron being just about the most hyper-collegial human on the planet. Close to 2 years after they were more or less finalized, Kim's "identity laws" and "identity metasystem" are still the most concise definition of what's come to be known as "user-centric identity." And they are a seminal statement of the core principles that have driven the work that many people are doing around the world in this very exciting new branch of the IdM space.

Trying to get my own head around the rapid evolution that's taking place in the IdM space, it appears that three paradigms are jostling for dominance, or at least harmonious convergence, in the emergence of user-centric identity:

• URL-based identity: This is founded on the notion that users have the ability to provision their identity as a URL/URI construct. Drummond Reed , Cordance, and the XRI community kickstarted this notion with their i-numbers/i-names, and people such as Johannes Ernst of NetMesh, pushed it forward with LID, and now we have OpenID, Yadis, and other projects that are developing it into a potentially universal infrastructure.
• iCard-based identity: This is founded on the notion that users have the ability to present the identity (and user-selected credentials/attributes thereof) that works best for them in the context of an interaction, to a relying party, in the form of a standard structure known as an iCard. The primary example of this is CardSpace.
  
• Assertion/claims-based identity: This is founded on the notion that users have the ability to request, upon successful authentication, that their identity provider (authentication authority and attribute authority) present their identity (and IdP and/or user-selected credentials/attributes thereof), in standards-based assertion/claim structures, to relying parties under established trust relationships (IdP-to-RP). The primary example of this is Liberty Alliance ID-WSF 2.0 (if memory serves).

From what I can see, Liberty ID-WSF's primary use case--"permission-based attribute sharing"--is also the primary use case for the new "user-centric identity" space as well. That, plus "privacy protection," "anti-phishing protection," "IdP discovery," and "identity self-provisioning." In other words, the agenda items that the SAML and Liberty specs developers discussed to varying degrees but, quite rightly, decided to defer to a later date (and to latter-day developers) rather than bog down their core 2001-2002-2003-2004 agenda.

That's a huge cool new exhausting exhaustive scope. All of it is quite orthogonal to the core, mainstream federated identity use case that has driven SAML/Liberty to pre-eminence: "cross-domain single sign-on." Also, from what I can see, the new URL-based and iCard-based approaches are orthogonal to SAML in that they rely on REST approaches (URLs, HTTP, etc.) whereas SAML, Liberty, WS-Federation rely on SOA approaches (XML, WSDL, SOAP, etc.).

Or perhaps those are overstatements. Or wrongheaded generalizations. The tendentious ramblings of an old guy who has far too much memory, and perhaps needs to unlearn various things in order to stay fresh.

You tell me: james_kobielus@hotmail.com.

Jim

rfi User-Centric Identity article for Business Communications Review

All:

Hi. I'm back. I've been giving the blog a relative rest for the past several months for various unimportant reasons.

These past few years, I've been following the frenetic industry activity surrounding user-centric identity, including the announcements at this week's RSA Security Conference. Especially Microsoft's commitment to converging CardSpace with OpenID.

Just a few days ago, one of my fondest professional associates--Sandy Borthick of Business Communications Review--contacted me and asked for an article on user-centric identity for BCR's May issue. I love Sandy for many unimportant reasons, one of them being that she drops juicy topics in my lap, and lets me develop them as I see fit. I try not to disappoint (case in point: the piece on Master Data Management in this month's issue, leveraging the MDM maturity model I'm developing in my main gig, as Principal Analyst at Current Analysis).

Anyway, this BCR piece is, of course, a freelance assignment that doesn't have much direct relationship with my core coverage areas at Current Analysis (though lotsa folks know that I covered federated identity management and tons of other stuff in my Burton Group days, so it's not that huge of a stretch for me....a dirty little secret about Jim Kobielus is that I never stop covering anything that I covered at one point in my career...for me, everything's a cumulative building process....I'm synthesizing all of this old and new stuff in my head at all times....I'm a "synthesist" (putting things together) as well as an "analyst" (pulling them apart)....a fact that some people fail to comprehend...but they need to). My life, my career, is one big crazy mash-up.

Anyway, enough about me and more about YOU. Or, more to the point, anybody in the user-centric identity community (OpenId, Higgins, Bandit, LiD, OSIS, CardSpace, SXIP, Yadis, Identity Commons, OpenXRI, iNames, Passel, mIDM, Liberty ID-WSF, etc.) who'd like to share their thoughts with me...I'd like to speak with you. Just to keep this all from impinging on my main gig, just send me a quick e-mail to james_kobielus@hotmail.com to open up discussions. I want to speak with you at a time convenient for us both (preferably evenings and weekends, the way I've been managing my freelance work in the 20+ years I've spent in this industry---god i'm old). I'll contact several of you under my own initiative.

But I'm putting out this all-points "request for interaction" to the user-centric identity community. The BCR piece won't be hugely long, and it won't necessarily break any new ground. You folks, collectively, are doing a wonderful job developing this promising new realm of the IdM universe. I just want to get my arms around it all. Communicate it all clearly to BCR's readers.

And press it deeper into my main groove.

Jim

fyi Inside MySpace.com

All:

Found content: http://www.baselinemag.com/article2/0,1540,2082921,00.asp?kc=BLBLBEMNL011607EOAD

My take:

This is one of the most fascinating case studies I’ve ever read in the IT literature. Free-of-charge social networks are among the most fragile creations in the web universe. They live and die by their ability to stoke the “network effect” of snowballing invitations among people within diverse social circles. If the service shows any chronic degradation in performance and reliability, users will abandon it freely and speedily.

The article shows in painful detail how MySpace.com—without any fixed strategy--has continually evolved its distributed access, application, processing, storage, hosting, and management infrastructure to keep pace with surging membership, traffic, content, and expectations. It breaks the architectural evolution of MySpace.com into “membership milestones”--500,000 users, 1 million, 3 million, 9 million, 26 million, ….—and shows how the service broke and was quickly fixed to avoid strangling the golden goose they had birthed.

What I found most fascinating about this case study is the following statement, in which a rival (Friendster) partly attributes MySpace.com’s runaway success to MySpace.com’s superior performance (and Friendster’s concurrent growing pains): “MySpace was launched in 2003, just as Friendster started having trouble keeping pace with its own runaway growth. In a recent interview with Fortune magazine, Friendster president Kent Lindstrom admitted his service stumbled at just the wrong time, taking 20 to 30 seconds to deliver a page when MySpace was doing it in 2 or 3 seconds.”

Once MySpace.com started to explode, they continually ran into bottlenecks in data access performance that threatened to derail them as well. The case study lays out the peril to MySpace in stark terms: “MySpace has tens of millions of people posting messages and comments or tweaking their profiles on a regular basis—some of them visiting repeatedly throughout the day. That makes the technical requirements for supporting MySpace much different than, say, for a news Web site, where most content is created by a relatively small team of editors and passively consumed by Web site visitors. In that case, the content management database can be optimized for read-only requests, since additions and updates to the database content are relatively rare. A news site might allow reader comments, but on MySpace user-contributed content is the primary content. As a result, it has a higher percentage of database interactions that are recording or updating information rather than just retrieving it…..Every profile page view on MySpace has to be created dynamically—that is, stitched together from database lookups. In fact, because each profile page includes links to those of the user's friends, the Web site software has to pull together information from multiple tables in multiple databases on multiple servers. The database workload can be mitigated somewhat by caching data in memory, but this scheme has to account for constant changes to the underlying data.”

Since the beginning, MySpace.com has operated in ad-hoc fire-fighting mode, evolving its architecture to oil whatever new squeaks presented themselves. In reading this article, I scribbled down notes on the convoluted saga of ad-hoc fixes. Here (reading like the “and then, and then, and then” run-on ramblings of toddlers trying to make sense of an apparently pointless plot) are my notes on what they’ve done to keep heads above water:

§ first: single database server, with two access/web servers:

§ then: handle access/usage growth by throwing more more web servers at the problem

§ then: divide database loads among single master database and two access databases that have replicated copies of data posted to master, plus more database servers and bigger hard disks

§ then: vertical partitioning of separate databases among various functions of the MySpace.com service

§ then: a storage area network with pool of disk storage devices tied together by a high-speed specialized network

§ then: every database was given its own copy of the users table

§ then: distributed computing architecture treating the website as a single app, with one user table, split into chunks of 1 million accounts, with those chunks in separate mirrored instances of SQL Server, with webserver/access server redirecting logins to the applicable database servers

§ then: rewrite app in faster, more efficient computing environment (ASP.NET), with re-examination of every function for streamlining opportunities

§ then: continually redistributing data across the SAN to reduce I/O imbalances, but it was a manual process

§ then: virtualized storage architecture where the entire SAN is treated as one big pool of storage capacity, without requiring that specific disks be dedicated to serving specific applications

§ then: caching tier

§ then: faster version of database server running on 64-bit hardware with more memory access/less memory bottleneck

§ then: turn off distributed denial of service protection in order to goose performance further (introducing risk)

§ then: implement backup data centers/SANs tied to different power grids

§ then: lengthen data-commit checkpoint intervals to goose performance (introducing more risk)

§ and always: in any fix, impossible to do thorough load/performance testing on each new architectural fix/stopgap, simply resigning themselves to fixing new problems ad-hoc as they spring up

Of course, MySpace.com’s teenager customers don’t care, and don’t want to care, about any of this. The service continues to grow smartly, which may be attributed, among many factors, to the fact that it has yet to cross a “MySpace sucks, let’s leave” threshold. As the article states over and over, MySpace.com continues to experience significant performance and reliability problems, but they’ve never been showstoppers.

How long would it take for a social networking site to slow down and/or crash before it gets abandoned by its users? Are these sites so “group-sticky” that participants will tolerate poor performance for long periods? Are users’ performance/reliability expectations on these services lower than for standard corporate and e-commerce websites?

Or could the life or death of a social networking service—or of any online channel/forum—be driven more by the zeitgeist—fad, fashion, weariness, exhaustion, restless, new cool alternatives? Ten years ago, my 9-year-old son created a Digimon website. He’s in college now, and I don’t snoop into his doings, but I suspect that both of my kids have MySpace.com pages (no—I have better things to do then spy on them). Ten years from now, they and their peers will probably have long abandoned whatever social networking services they’re currently using.

They’ll write it off as youthful experimentation. To the extent they’ll still be participating in any online community that resembles today’s social networking services, it’ll be an act of nostalgia, more than anything. From a technical standpoint, it’ll probably be lightning-fast and scalable as can be, the fruit of lessons learned in the ‘00s by MySpace.com and other pioneers in this world of hyper-federated data service layers. And it will probably be far more navigation-friendly, as today’s chaotic MySpace homepage designs (which resemble the overcrowded Web-site home page designs that even big corporations were using in the ‘90s) settle into more consistent, pleasing patterns that everybody accepts without question.

But at that point the messy fun of the ungoverned social-networking frontier will be a distant, and slightly quaint, cultural memory. Like hippie communes in '60s.

Jim

poem Mless

MLESS

Dream of dreamless sleep
deep as dusk in a
musk as bright as
soft awakening.

fyi Where Will The Next Bill Gates Come From? Not The United States, Most Americans Say According To New Poll

All:

Found content: http://www.zogby.com/news/ReadNews.dbm?ID=1226

My take:

This is, of course, inane in the extreme. Zogby should be ashamed of themselves for phrasing the question in this ridiculous manner, and for pretending that the collective responses are worthy of serious consideration. While we’re on the topic, where are the “next” instances of the 6 billion-plus unique humans on the planet going to come from? Cloning seems the only truly effective approach, but I digress.

But I suppose that institutionalized idiocy has its own weird logic. What this misbegotten market research shows is that Mr. William Gates III has truly passed from the realm of limited mortals into the cultural hagiosphere. Does the following phrase sound like Christian second-coming imagery to you? “’The next Bill Gates has already been born, and time will tell what country is providing the environment of innovation, entrepreneurism and opportunity to enable him or her to flourish with the next great idea,’ said 463 partner Tom Galvin.” Or perhaps the current mortal Bill is an avatar of some timeless Hindu deity. But once again, I digress.

Clearly, the man who co-founded Microsoft has long since passed far beyond, say, Rockefeller, Carnegie, or JP Morgan in the pantheon of capitalist earthly gods. How can I make that assertion? Ask children to name one rich person known principally for his/her riches (as opposed to whatever celebrity career, be it athlete actor or musician, furnished them their largesse). Even in their days, I suspect, those ancient robber barons were probably known to few children. Even the kids who frequented the Carnegie-funded libraries (such as the one in my father’s Wisconsin hometown) probably didn’t realize that a munificent human was putting books in their hot little hands.

But today’s preschoolers, everywhere, know quite well that some well-endowed individual named Bill Gates is behind all things software, including the Internet (yes, I’m assuming that few tots care about the distinctions between Microsoft and other software companies). Maybe that lowest-common-denominator overattribution will diminish over time as Gates (perhaps) withdraws from active participation in the high-tech industries, but maybe not.

The world community demands an “inventor” of this created software universe. “Bill Gates” is a serviceable “father” to it all. “He” is two easy syllables that almost everybody everywhere can say with ease and be immediately understood.

Better than G. Presper Eckert.

But in some sense this annoying opinion survey may be onto something. If Bill Gates is an avatar of some timeless presence—in Hindu terms, the “creator”—then maybe the “next Bill Gates” refers to the next manifest avatar of some counter-personage in that pantheon. The “destroyer”? Who will come along to destroy or dismantle Gates’ software industry legacy? From a financial standpoint, Gates and his wife are self-dismantling through their foundation.

From an industry standpoint, open source, software as a service, virtualization, etc are dismantling Microsoft’s created order, steadily, erosively. “The Zogby/463 Internet Attitudes poll found that practically half of all Americans (49 percent) believe that the next great technology leader will come from either China or Japan. Twenty-one percent believe that ‘next Bill Gates’ will come from the United States while 13 percent believe he or she will come from India.”

So, given that half the world’s people are from Asia, chances of the “next Bill Gates”—the “destroyer” but also the “creator” of the next softworld order--coming from that region are a coin flip.

50-50.

Jim

personal John Pierce Askegren

All:

Sad news: http://www.washingtonpost.com/wp-dyn/content/article/2006/12/20/AR2006122001918.html

Published obituary:

*********************

Thursday, December 21, 2006; B06

John Pierce Askegren, Novelist, Technical Writer

John Pierce Askegren, 51, a freelance writer who authored science-fiction novels and short stories featuring Marvel Comics characters and also worked as a technical writer for government contractors, was found dead Nov. 29 at his home in Annandale. The cause of death was atherosclerotic cardiovascular disease.

Since 1995, Mr. Askegren wrote or co-wrote more than 10 novels and a half-dozen short stories, mostly under the pen name Pierce Askegren.

His early credits included original short story contributions to anthologies featuring the Silver Surfer, Spider-Man and the Hulk.

"He was a huge fan of Marvel Comics and had a really spectacular sense of the history of the characters," said his former editor Keith R.A. DeCandido. "He did a wonderful job of bringing back obscure characters and giving them a twist."

Mr. Askegren was a co-author of the novels "Spider-Man & The Incredible Hulk: Doom's Day Book One: Rampage" (1996), "Spider-Man & Iron Man: Doom's Day Book Two: Sabotage" (1997) and "Spider-Man & Fantastic Four: Doom's Day Book Three: Wreckage" (1997).

In more recent years, he published a trilogy of science-fiction work: "Human Resource," "Fall Girl" and "Exit Strategy." This year, he wrote "After Image," part of the Buffy the Vampire Slayer paperback series.

For most of his career, he worked on his fictional stories in the evenings and on weekends, and by day he wrote educational handbooks and training manuals for government contractors.

He managed Crown Book stores before working for ACS Corp. from 1995 to 1999 and C2 Technologies from 1999 until 2003, when he left to concentrate on his freelance writing.

Mr. Askegren was born in Pittsburgh and grew up in a number of places before his family settled in Sterling in 1970. He graduated from Broad Run High School and James Madison University.

He became hooked on comic books as a youngster recovering from a broken hip.

"It started with two comic books my dad bought him when he had a metal pin in his leg. From that point on, he always had an affinity for it," said his brother James William Askegren of Sterling.

In addition to his brother, survivors include another brother, Robert Steven Askegren of Manassas.

*********************

A few additional words of eulogy:

Pierce Askegren was one of the coolest guys I ever met who didn’t realize how cool he was.

I hadn’t seen Pierce since 1998, though we exchanged a few e-mails in 1999. I only knew Pierce for a short time. We were work acquaintances, nothing more. I was a product manager at a wireless test and measurement equipment vendor in Tysons Corner, Virginia. Pierce was a technical-writer contractor that we brought in to do our manuals.

The first thing I noticed about Pierce was the quality of his technical writing. He took complex, boring technical goo and quickly boiled it down to a crystalline substrate of absolute clarity. Straightforward, unambiguous, readable, practical prose. Modest, not showy. Just like the man.

I also noticed that Pierce was an easy, pleasant person to engage in conversation. I’ve never been in the habit of lingering in colleagues’ offices longer than I need to, preferring to respect their work-hour space/time just as I hope they’ll do for me. But I found myself periodically traipsing down the hall to the tucked-away end-office where Pierce was set up. Among other things, he had a nifty little collection, arrayed on his bookcase, of comic-book action figurines.

Yes, this 40-ish man (only 3 years older than me) was a nerd, but not an obsessive fetishist hanger-on type of nerd. Through our conversations I began to determine that not only did he have an encyclopedic grasp of every comic book publisher, publication, issue, character, story arc, and detail going back—it seemed—to the Yellow Kid—but that he himself wrote paperback novels that carried forward the development of some of the most popular comic-book characters: especially, Marvel Comics’ Spider-Man.

Yeah, lotsa fanatics write unpublished/unpublishable novels, short stories, etc all around their venerated comic-book heroes, but Pierce was someone entirely different: a professional published freelance comic-book novelist. He mentioned that he had already authored a few such novels through some big-time publishing house. Though I had long since given up the comic-book habit (a staple my own childhood), and wasn’t much of a reader of any sort of fiction (nerd that I am, I’m much more likely to have a history or other non-fiction work in my hands), I had to see these. So I asked, and he gladly lent me two of his most recent books: one a Spider-Man title, the other (I believe) Fantastic Four.

I read them both quickly and with absolute delight. The man was a terrific novelist, and he clearly applied the same economy of technique to his fiction as to his tech writing. In addition, within the constraints of the comic-book novel, he was quite adept at developing characters, plots, and themes. He also had a real gift at drawing verbal pictures of dynamic action sequences, such as Spider-Man zipping his webline from his wrists, grabbing it and swinging back and forth between tall buildings as he rapidly homed on the baddies, while occasionally freefalling and trying to avoid annihilation. I can still feel and see the dynamic images that Pierce sketched out so brilliantly.

He also had great taste in music, especially classic R&B, soul, and pre-Beatles rock and roll. He lent me a lot of his CDs, and an excellent collection it was. So it was with special sadness that I encountered Pierce’s obituary in the paper version of Washington Post a couple of nights ago. Interestingly (and counter to what the Post normally does in its standard obituary pages), they published a small headshot of the man. This is the only occasion where I’ve clipped an obit and taped it to the wall of my home office.

Loved ya, Pierce.

Jim

poem Once

ONCE

Old stones settle and
once wars are themselves
laid in place never
to reconnect the
same names in battle.

(inspired yesterday by some mysterious ancient war memorial at the base of Pennsylvania Avenue, catercorner to the Willard, on the Ellipse side of the Treasury Department HQ, and at one end of the ghastly barricaded zone that used to be the pedestrian friendly heart of our nation's government)