Tuesday, January 16, 2007

A virtual solution

Conor and Eve's responses to "Putting ID all together" correctly note that the Liberty spec is 'location agnostic' about data. I'll even agree with Eve when she states

"If all you’re storing is self-asserted info about you personally, then sure, it’s handy to consolidate all of it in one place over which you have direct control, whether that’s a traditional web app/service, a device you carry on your person, etc. But as soon as you get into information that someone else has the right to own (including mundane things like your employment status, which comes up a lot when you, say, apply for loans), I can’t see their being okay with giving you the “gold copy” to hold. That’s where multi-sourcing really shows its stuff."
(This in response to Dick Hardt's assumption that the user, having chosen an identity provider [in that discussion, an OpenID Provider or OP], would happily entrust everything about themselves to that one OP and wants all relying parties to upload any interesting facts about the user back to the OP. )

But there is, of course, a third way. And one I think is a better way. It's the tried and true "virtual directory." Data is consolidated into a repository controlled by the user. Applications query that repository for data. But the authoritative source for that data may well lie somewhere else (e.g., Eve's "employment status" data point). All that's needed is a synchronizing join engine (something the folks at Oracle, Radiant Logic, Symlabs, MaXware and the Penrose Project are very familiar with) with a new frontend or two to support attribute exchange via Liberty protocols, WS-* or even OpenID.

Labels: ,

Ah, but what about identity data that's not in LDAP? SAML, for one, is entirely agnostic as to the storage format of the attributes -- and except for DSML, all the other technologies we've been discussing are, as well. Would we have to invent some new join technology for models that aren't LDAP-biased?
I'm afraid I don't follow, Eve - there's no requirement for the data source to be LDAP enabled, there simply needs to be a way to query the data (SQL, Xquery, even grep work) or file and return information. See Radiant Logic's explanation. Now currently most access to the data within the virtual directory is via an LDAP call (or DSML) but that's why I suggested "a new frontend or two to support attribute exchange" for today's user- or even enterprise-centric identity systems.
Hi Eve & Dave!

Virtual Directories are really great for picking up data from different
places and presenting them in multiple view - just the right way for the
applications that need to view the data (see
Fragmented Identities

Virtual Directories are also much faster than retrieving the data through
SAML or the Liberty protocol because they are specialized for this
particular purpose.

However, virtual directories do not explicitly add the privacy features that
you would have, for example, when using Liberty's ID-WSF specifications.

Our customers are actually deploying our virtual directory together with our
federation products, because the combination is especially strong: the ease
of getting to the data through a virtual directory bundled with the power of
SAML and ID-WSF 2.0. This creates a very powerful foundation for
privacy-enabled identity-based web services.
How to ensure Virtual Directory securely run over internet (i.e. without intranet and VPN SSL between different servers?

Another question: Can I user virtual directory to enable Web Single Sign On over different security domains? (where is one of the driver for SAML as per my understanding) Why?

Post a Comment

© 2003-2006 The Virtual Quill, All Rights Reserved


[Powered by Blogger]