Trusted Data Exchange
Trusted Data Exchange Extention and Reputation Service for OpenID
- Date & Time: Dec. 4, 2007 11:30-12:30
- Cordinater:
- Nat Sakimura (=nat, Nomura Research Institute)
- Masaki Nishitani (=masaki, Nomura Research Institute)
KEYWORDS
Reputation Service, Trust Model, Contract, Secure Channel, Business Case, OpenID, Higgins, XRI, XDI, ORMS
Contents
Backgrounder
OpenID is designed for an open and worldwide framework of authentication including single-sign-on. Sreg and AX are extensions bringing capability to share “casual” information such as nicknames, gender or street address (in U.S) between OP and RP. Exchanging more sensitive information will require OP to be more responsible for protecting its users from attacks such as Phishing, Man-in–the-Middle attacks, etc. OPs will be regarded as “data authorities” of user privacy information. In addition, in some countries (Japan and perhaps EU), even street address is considered as one of the sensitive (e.g., privacy) information so that to communicate the data, it has to go with the permission (contract) stating the purpose of use (and period). (One is not allowed to give this information to a third party without explicit consent of that person = data owner.)
Thus, we need some extention that bringus us more Security and Trust.
They are not abstract requirements.
They are the real user requirement that we have to implement in couple of month time.
Basic Principles on How to tackle this issue
These problems cannot be solved only by technical , but also requires Social and Legal Approaches. Technically, we cannot control the data (or very difficult to) after delivery, but we can do it socially and legally at least to some extent.
To achieve the goal, the following three components seems to be essential.
- Reputation
- Contract
- Secure Channel
Reputation Service
Reputation service is a service that rates various parties involved in this picture. It can be used for
- Rating the trustworthiness of the OP
- Is this OP’s statement such as PAPE level 1 trustworthy?
- Rating the trustworthiness of the ID and / or claims
- Is this ID registered for this person?
- Is the claim presented trustworthy?
- Rating the trustworthiness of the RP
- Is it safe to hand this data over to this RP?
Etc. This service, together with contract is essential in assisting social and legal means of controlling the mis-behavior of the involved parties. The mis-behavior of these parties would hart their reputation thereby hindering such action.
Since there are 3 parties involved in our picture, there are at least six directed reputation that can come into existence. Also, we may have to consider additional reputation such as self-reputation. These are subdivided into contexts of authentication.
Also, it is important to note that anybody can start a reputation service. It is entirely up to the reputation consumer to choose the one. However, this has a flip side on it: how do we trust a reputation service? This factor will be elaborated in more detail in the challenges of reputation services section.
Required Fields to be Returned by a Reputation Service
To be useful in our context, a Reputation Service should return at least:
- ID (or regex of ID like realm) in question
- On what kind of trustworthiness (Context)
- Rating score
Additionally, in our proposal, it should return:
- Public key of the party in question (which is registered separately)
Rating Methods
There are 2 Models that can be used to rate the parties.
- Auditing / Certification
- Collective Intelligence
Auditing and Certification
This is a time tested method of establishing a reputation for the parties and the services involved. Prime example is the company audit to establish the trustability of the financial statements of the company in question, but others include such things like stock rating, ISO9001, SAS70, Zagat and Michelin rating for restaurants, etc. In a more technical world, web server certificats (e.g. EV Certs) has been there for over a decade.
Obvious limitation of this method is that it is only periodically conducted. Thus, it will not be detect eve if the quality of the services may radically dropped between the audit timings. Collective Intelligence is a complimentally method to fill this gap.
Collective Intelligence
Prime example of the Collective Intelligence are such things like eBay reputation, digg, etc. In a more traditional world, "Word of Mouth" has served such purpose. There can be many methods for doing this. A party that has conducted a transaction with the other party may be eligible for casting a vote for the rating of the party. Also, there can be a reputation aggregator. These are the subject of the interest of the Open Reputation Management Systems TC which is being formed at OASIS Open.
Challenges of Reputaion Services
The biggest challenge would be the bootstrapping of the reputation of the reputation service. It is not a new problem. There has been a similar thing in the past such as the trust root problem of the X.509 certificate. Conventional root of trust for this can be something like SAS70 and ISO27001 certifications, etc. The i-broker certification by XDI.ORG may be another such example to be looked at.
Contract
When we consider such things like OECD's 8 principles on privacy, EU Directive, and Japanese Privacy Laws, it is desirable to base the privacy data exchange on an explict permission contract. Such contract should include at least:
- Who is using the data
- Why (Purpose)
- What Data
- Until When and Where
- How to update
- Date
- Signature (for Non-repudiation)
The user should be presented with these conditions and the reputation rating information of the receiving party so that he can make decision on whether to approve (i.e., sign the contract) or not.
In the framework that we envision, this would be expressed in XML format. XDI is a prime candidate for this, but we need more investigation on this.
Secure Channel
- Data must only be sent to the party in the contract.
=> authenticate the receiving party.
- Data must be authoritative
- Must not be tampered.
- Must be able to tell which data authority have asserted.
=> signature on the data
- Data must not be seen by the third parties
- such as eavesdroppers and man-in-the-middle.
=> Data Encryption
Basic Strategy for creating the Extension
- Extend Minimally on the OpenID authentication.
- Define complicated part (policies and data exchange) separated to keep the simplicity.
- Define Reputation service and hook on it to get trust info.
- Make it possible to express variety of RP’s terms and policies of using end-user’s information.
- Secure data delivery using RP’s public key or certificate.
Protocol Extension
Overview
See Page 10 of the PowerPoint Presentation.
Protocol Sequence
1. Post End Users Identifier (OpenID) to the RP
2. Resolution of the OP
3. Association between OP and RP
4. AuthN Request with openid.tx.policy_url, openid.realm, and optionally AX data request.
5. OP makes a reputation request for the RP with openid.realm.
6. OP gets the reputation score for the realm together with the public key of the RP.
7. OP requests RP the policy that includes Contract proposal incl. what data, purpose, expiry, etc. (see Contract section above.)
8. RP responds with the signed proposed policy.
9. OP prompts the user agent whether to accept the policy.
10. User responds with Yes or No. If Yes, it will be signed.
11. OP returns AuthN response with openid.tx.contract_handle (and ax data if there were any.)
12. RP request the data with the contract_handle.
13. OP (in this example... could be other attribute authorities) returns data (which includes contract handle and signed by the authority)
(Page 11 of the PowerPoint Presentation.)
More Details
More details on the XML formats being passed etc. are found at http://nishitani.info/hiki.cgi?OpenIDTrustedDataExchange
ToDo
- =nat to write a white paper based on todays presentation and discussion. (A part of it is this wiki page.)
- =drummond.reed to come up with contract file format and data exchange file format, as well as the reputation score file format.
Attendee List
- Nat Sakimura (=nat, =sakimura), NRI, XDI.ORG
- Henrik Bierwg, Netmania
- Les Chasen, Neustar
- George Fletcher, AOL
- Dee Schur, OASIS
- , LCE
- Kevin Turner, JanRain
- Masaki Nishitani, NRI
- Abbie Barbir, Nortel
- Bill Washburn, OpenID
- Song-Hyun Kim, ETRI
- Gabe Wachob, Amsoft
- Phil Windley, BYU
- Andy Dale, ooTao
- Lena Kannnapan,
- Joe Steel Adobe
- Madhuker Thakur, Google
- Brett McDowell, Liberty Alliance
Please add yourself if you are not included in this list!
Authors
- Nat Sakimura, Original Author of this article, Protocol extension
- Masaki Nishitani, Protocol extension, Diagrams
