Silicon Investor (SI) -- The First Internet Community

STOCKTALK

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor. We ask that you disable ad blocking while on Silicon Investor in the best interests of our community. If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.

Technology Stocks : Novell (NOVL) dirt cheap, good buy? -- Ignore unavailable to you. Want to Upgrade?

To: ToySoldier who wrote (28122)	9/15/1999 12:52:00 AM
From: Scott C. Lemon	Read Replies (1) \| Respond to of 42771

Hello Toy, This is a huge area ... and a lot of money is going to made in developing this whole infrastructure ... > So I would have to think that all the data in my vault/safes would > have to be encrypted and then some means of providing a key to > selected outsiders for each specific attribute in my vault/safe > would have to be developed. As you know, with key management this can become a nightmare. So each attribute would be encrypted, and only I would have the key to "write" this attribute, and then I give rights to people to "read" the encrypted value, and then a key to decrypt it? So the second person I want to be able to read it gets the key ... now, in this scenario, when I change the value of the attribute how do I "revoke" the key from the first person if I want to limit their access? Do I change the key on the new value? Then I have to redistribute keys to the remaining people who are supposed to have the key ... The simplest way I can think of is to only put information in "trusted" places. Then sharing of information is one level where you don't have to worry about encryption because the user accessing the data is already authenticated. This is like standard file or database access. Encryption, IMHO, is best used for limited storage or backup purposes. > This would also further ensure that some "Trusted Host" does not > have a backdoor into my vault/safes (although even that might not > be fully ensured). So this will be completely determined where the keys are kept. Just for you, we'll have the US Government keep the keys for all the worlds citizens ... ;-) (Or atleast some US bank ... ;-) > Very interesting comments Scott. This is going to be a huge area of growth ... I keep looking for where the investment opportunites are going to come from! > It is unfortunate that you cannot discuss your opinions of > Digital-Me, but I understand why you cannot. I actually think we are on the same ground here ... my reason is the same as yours ... neither of us has seen the release! Neither of us can talk about something that we've never experienced. Once we do, we will be able to experiment and will know a lot more about it! There are a lot of good engineers on the project, and I know that a lot of people are looking forward to the release! Scott C. Lemon

To: ToySoldier who wrote (28122)	9/15/1999 10:02:00 AM
From: Paul Fiondella	Read Replies (1) \| Respond to of 42771

Vault terminology....waiting for digitalme(Godot?) This is addressed to everyone not Toysoldier in particular. I think we should be careful with two aspects of an identity vault that seem to be getting confused here. -1- information in the vault that is meant to be used for verification which can be of two types -a- user generated as in the color of my dogs coat -b- vault owner generated as in my SS# which is used by my financial institution in setting up my account -2- information in the vault which is meant to be shared with selected communities It would be a mistake to use the concept of "trust" with regard to verification information. In fact, in a well designed identity vault, the user would be informed that sharing this information with others is prohibited. You don't "trust" anyone with this information. The mental slip that people are making is that CURRENTLY on the net you have to supply lots of this information in ecommerce and verify at the vendor site. The whole idea of an identity vault is to move verification of your identity away from the vendor centric model(aka MSFT) and toward a user centric model(digitalme). Once this new model is the norm, then you will not need to trust personal information to the net for verification. (see my example of the circles and labels.) With regard to communities, say my scuba diving club, the "trust" being exercised is simply that I trust that I am communicating with a real person in cyberspace because that person has an verifiable identity. If I question whether the person has ever really dived to the Andrea Doria, perhaps I might want my scuba diving club identity server to require its users to fax copies of diving certificates in order to obtain an account or membership in that community. You see how this starts to get more worthwhile. =========== We really cannot confuse verification for ecommerce and establishing secure identities with the notion that somehow having virtual communities equals trust. It doesn't make sense. The purpose of an identity vault is just that, to verify you are you to other people. That is why we put the information in one place and stop pumping it out over the net to every insecure web site as is currently done! We do this to center verification on the identity vault and not disperse verification into the far reaches of cyberspace. Once you verify who you are at the secure identity vault, then, when it comes to business transactions, none of this information should be transmitted from the vault to anywhere else, nor is it any longer necessary.