Tsvika, Just so you have the whole of our thinking on this, here¹s a bit more detail about where we are headed with Higgins: The user¹s selector is ³serialized² with a key unique to that selector installation (this is the ³something you have part²), then the selector is secured with a ³master² password (this is the ³something you know² part). If a person¹s computer is stolen, they can use any other device to de-provision that computer so that it no longer works. Azigo has developed this capability and will be contributing it to Higgins very soon. If a specific card requires yet stronger security, the card¹s IdP can require yet other factors to also be required. The card IdP could require its own password, a USB token device, etc.
If/when we can tie the serialization key to a local TPM chip or equivalent on mobile device, we can harden this approach even further. --Paul On 7/24/09 4:09 PM, "Tsvika Rabkin" <[email protected]> wrote: > Paul, > > Sharing some thoughts on physical device vs. hosted services: > > Physical device: > 1. The identity provider creates real world trust by providing cards on a > physical device. > 2. There is strong "two factor authentication". Something you have (card/key) > and something you know (PIN). > 3. If the device is lost or stolen, the feedback is almost immediate. The > security risk can be minimized by quick notification to the IDP that issued > the managed card. > 4. Devices cost more than hosted service. However, USB keys are very common > and the IDP/user can load the cards to the key he/she already own. > Hosted I-Card service: > 1. Hosted I-Card service is easy to synchronize and backup. > 2. Cost efficient. > 3. Cards are not stored on the selector. Good for shared machines. > 4. > 5. The "master" pw is a bit of concern, especially regarding to "leakage" of > managed cards stored on the hosted service. Maybe there's a hybrid solution. A > possible scenario: >> * The user stores the cards (self issued and managed) on the hosted service. >> * >> * Suppose that the user has at least one managed card (issued by the same IDP >> that issued one of the cards stored on the hosted service), stored on >> his/hers personal machine or an external device. >> * This card can be used to login to the I-Card hosted service. In this case >> the cards are backed up and synchronized regularly, but no un/pw is involved. >> * In this scenario, usage of shared machines still demands an external >> device. > Tsvika > > On Fri, Jul 24, 2009 at 9:37 PM, Paul Trevithick <[email protected]> > wrote: >> Tsvika, >> >> I¹m trying to understand your requirements. You wrote to me privately: >> >> * Most of the clients in this [your] project are windows XP based, and the >> login is done via browsers using un/pw. The computers are shared workstations >> with common windows account for all the students, making card portability a >> necessary demand >> * >> * In order to avoid the usage of un/pw for card provisioning, it seems that >> the preferred solution will be to carry the cards on a physical device such >> as usb key or smart card. For security reasons the cards should not stay on >> the selector, but vanish when the external device (usb/smartcard) is plugged >> out. >> >> For Higgins 1.1 we are working on an Adobe AIR selector that uses a hosted >> I-Card Service. No cards are stored locally, so there is nothing to delete. >> Cards are stored on the server and fed to any selector that wants/needs them. >> Could that work? >> >> Now it IS true that for this to work we require a ³master² username/password >> to authenticate the user to the hosted service. Is this what you are trying >> to avoid in your second bullet above? It seems to me that an external device >> will cost more than running a hosted I-Card Service and some people think >> that the external devices themselves should be protected by a PIN etc. to >> prevent others from using them directly. And in this case both solutions >> require a password/PINso they are equally bad/good in that regard. >> >> --Paul >> > >
_______________________________________________ higgins-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/higgins-dev
