Re: [Arch]Re: [Auth]a list of what we need the personal Data system to do.

[John]

Myrddian wrote:
> what I was trying to probably mean was.
> 
> 1) The Authentication data stored on a Authentication Provider (one who 
> provides
>    Authentication/Authorization service) Is Encrypted
> 2) The Data cannot be accessed (which is stored in the server) by the Admins 
> of the 
>    system/server or any other person. That is only the user may access 
> his/her own 
>    data, so the admin is locked out.

If I understand you correctly, then what you describe is purr-fect. I'm
assuming you meant to say "which is stored --on another-- server" and
not "which is stored in the server" 

If so, this gives us several sample use cases:

1) The customer agrees to have his data scanned for marketing purposes
hopefully for a 
   reward from the DataBank. The authentication and DataBank provider
are one and the same. 
   The combined service does both encryption and decryption and sending
to the other
   provider. The customer switches Databanks by one at a time
transfering his key/data 
   pairs to the new DataBank.  This is the Passport model, AFAIK.
2) The customer wants his data to not be scanned. The authentication and
DataBank providers 
   are separate and distinct. The customer switches providers by bulk
moving his data to the
   new system. Authentication provider can be similarly switched. The
customer acts as the
   conduit to transfer keys from auth to DataBank thus preventing either
service from 
   mining. The DataBank still handles en/decryption and sending. The
PassThrough model.
3) The customer is semi private, but wishes remote access to his data.
He stores the 
   authentication locally and the key/value pairs are encrypted locally
and stored on a
   DataBank. The Customer requests the data, decrypts locally, sends the
data on to the
   destination. Switching can be done in bulk. The SilentPartner model.
4) The customer is truly private. Both data and authentication are
stored locally. The 
   customer must manually replicate the data onto each device in their
possession. The
   HotSync model similar to the Mozy Password Manager.

Note that none of these models prevent us from moving to multiple
DataBanks later on.

Further note that where model names remind you of trademark names of
various entities, the naming is purely coincidental.

Now we need a layerable protocol that can handle these variations? Why
not start at the highest level and move downwards?