Secondly, you've obviously never worked with LDAP if you think it's the answer to anything.
You're "obviously" inept if you can't get LDAP to do work for you. I'm currently using it in several places and it is literally the best thing since sliced bread. Not only are all of our user accounts stored in LDAP along with their contact information but so are all of our customers and their relevant data. Now throw on a second major branch from the directory and that keeps track of every product we've ever shipped since setting up the directory. (things like configuration, distributor, end user, links to quotation/acknowledgement/service reports, etc.) It ties in beautifully with our RDBMS (PostgreSQL) by storing the DN as the key on the SQL side and/or storing an oid on the LDAP side.
"Obviously" it can't possibly work because you say so. I'd love to get the PostgreSQL backend working for OpenLDAP so that the data is stored in one (easily backed-up) place and there are just different accessor methods. With LDAP there is no need for separate difficult-to-keep-synced address books because they can all use LDAP. Palm software can hit the directory and generate customized lists for each person based on territory or any number of search keys. LDAP is very cool and very very useful, despite what you say.
Why not store everything in the RDBMS? Quite simply, it is obvious that this kind of data does not lend itself well to being stored in that manner. Some contacts have personal contact info, multiple business or territory information and so on. I could have created a bazillion joiner tables but that's crazy. Use the tool for the job.
The spec is completely obfusucated and imprecise. Anyone who has ever tried to normalize LDAP DNs knows what I'm talking about (for starters). And from a compatibility point of view the spec is way too vague; both AD and iPlanet are technically "compliant" (no matter what either company says), but still have enough annoying deviations to make it a pain to get them to work together. LDAP causes more problems than it creates.
The spec does not tell you how to lay things out, that is your job when you create the schema. Yes it is difficult to normalize a directory, especially when there is a lot of varied information. That's the whole point of choosing your DN scheme carefully. Honestly, it's no different than normalizing an SQL database -- the rules are the same but the problem is more difficult because the very nature of the data makes it hard to do.
AD and iPlanet are compatible on the protocol level; that's all the spec ever guarantees. To try and force schemes would be suicide. If you don't know the schema you're screwed, true, but have you ever looked at something like an AccPAC database table? If you don't have the documentation handy you'd be just as lost.
First off, what exactly do you mean "Decentralized LDAP"? Although LDAP is technically just the protocol, I've never seen a real decentralized implementation.
What I meant by that is something along the very same lines as DNS: you have your root servers handing out pointers of where to get information (these would obviously be run by the government or some "trusted" third party) but that's about it. You choose to upload (replicate) your information to the system using your master copy. Now you're known to the system and the various bits are encrypted to the people/systems/companies you have allowed for the information. My rough estimate would be that your infomation is then stored at the municipal level (giving a geographic scheme here), perhaps with a badass backup at the federal census database level.
I don't think your idea would work anyway. You've essentially rehashed the "public/private key for everyone" idea coupled with storing everything in an open LDAP directory. This former has been a pipe dream for many, many years. The latter would have to be run by the government, which most people aren't too keen on.
Yes, that is what I am proposing. You already have shitloads of data stored on you by the government, how is this any different? You at least get some degree of protection by your encryption of private/semi-private information. I'd take it a step further and allow arbitrary encryption on any non-essential attribute. Anything from ROT13 to triple AES mocha swirl inverse parabolic DES with elliptical XOR™. And you could also use the same trick as OpenDNS does and use different root servers with gateways to government networks. Pipe dream perhaps; I didn't say I was proposing something radically new, and I certainly don't understand why it can't happen today. You get a "smart" SSN card with your private key on it which has a TTL of 5 years or so (like a driver's license). Your private key you don't know. It's encrypted with two keys: a thumbprint/phrase combo and some government key which requires a court-order to use (akin to a search warrant, for when you lose your thumb or die or something -- potential MIB problem here).
Lastly, it would be really redundant to store copies of the same data encrypted the same way for every single person/group you want to grant access to. However, what I could see in its place is that each discrete piece of data is encrypted with a random key (i.e. not public/private encryption).
You're right, something like that would have to be implemented. I was suggesting a public key for "public searches", "government agencies", "law-enforcement", "family", "medical", etc. and then any specific persons or organizations.
[ Parent ]