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