|
|
|
|
|
| The ultimate purpose of the system is to allow services to access personal information in an environment that protects user privacy. This process is broken into the three major steps of getting permission, accessing the data, and logging the operation. |
|
|
|
| The realm, account provider, and user play cooperative parts in determining who can and cannot access each profile in the user’s account. The results of this determination are stored along with the account, perhaps in an access control list (ACL). Whenever a service wants to access information stored in a particular user’s account, the account provider consults this ACL to see if the access is authorized. If it is, the account provider returns a digitally signed certificate stating that, for some temporary period, the service is authorized to access data stored in the account. The service then presents this authorization certificate (called a ticket) to the storage provider storing the account data (or to the account provider, if the account provider stores its own accounts). This process is demonstrated in the following example: |
|
1.
|
eTrade contacts Accounts, Inc. to request permission to access the Portfolio account profile of the user’s account. eTrade identifies itself using its public key and an SSL connection, as well as presents its certification seal acquired from the Brokerage realm provider. This seal, signed by the Brokerage realm provider, asserts that eTrade has been granted “gold certification”, and is by default allowed to access portfolio data. |
|
2.
|
Accounts, Inc. consults the ACL for the requested account to see (1) if eTrade has been individually granted access to the Portfolio profile by the user; (2) if the user has explicitly granted access to all services with “gold certification”; or (3) if the default access set by the Brokerage realm provider grants access and has not been overridden by the user. If any of these checks indicate that the eTrade is authorized to access the Portfolio account profile, Accounts, Inc. returns to eTrade a temporary, digitally signed ticket that asserts eTrade’s permission. |
|
3.
|
eTrade presents this ticket to BitsRUs (the storage provider actually storing the account profile in question), and requests that some action be performed on the portfolio data (read, write, delete, etc.). |
|
4.
|
BitsRUs validates the ticket (verifies that the ticket was indeed issued by Accounts, Inc.), performs the operation on behalf of eTrade, and then returns the results. |
|
Figure 1: eTrade getting permission to access an account
|
|
|
| By using digital certificates to encapsulate the result of the access control check, the account provider can centralize access control even if the account storage itself is decentralized. This technique decouples the account provider and storage provider, eliminating the need for synchronous communication (such as having the account provider notify the storage provider that the service is authorized to access the account) and allows for stateless server design. |
|
|
|
| The precise manner through which services access account data is extremely flexible. Talisman system is primarily concerned with coordinating decentralized storage and access control of data; the underlying data transport mechanism is somewhat arbitrary. It would be entirely possible to build Talisman atop standard HTTP, FTP, or even SMTP protocols (along with higher-level protocols such as BEEP, SOAP, XML-RPC, etc.). |
|
| That said, there is a fantastic opportunity to introduce a new data transport mechanism specifically designed to handle the tasks of data sharing in a cross-enterprise environment. In particular, the purpose of this system would be to provide “share by reference” style data sharing to a cross-enterprise, web-services environment (as opposed to “pass by value” style communication that is the norm for current technologies). This new technology would provide “out of the box” support for version control, asynchronous transactions, multi-master replication and conflict resolution, and other features necessary for secure, fast, and reliable data sharing in an insecure, slow, and unreliable Internet. For more information on this technology, see Appendix B: Cross Enterprise Data Sharing. |
|
|
|
| One feature designed to increase the user’s level of privacy confidence is the ability to see who uses what information and for what purpose. At the very least, the account provider is in a position to record every request for permission to access account data. These requests can be logged and presented to the user. Additionally, it’s possible to require that services accompany their requests with a one-line description of why they need the data and what they intend to do with it, perhaps with a link to a privacy policy. This privacy policy might even be exposed in the Platform for Privacy Policy (P3P), with account providers validating P3P policies just as web browsers do today (and potentially refusing access to services with inadequate privacy policies, even if otherwise authorized). Finally, realms could require additional levels of usage logging for their account profiles, perhaps even requiring each operation performed upon the data to be annotated with an explanation. In short, any level of logging can be performed, and all of this logging can be exposed to the users in order to increase their confidence in the system. |
|
|
|
|