Nat Sakimura Nomura Research Institute

1. Coping with Information AsymmetrySESSION G: Managing Risk & Reducing Online Fraud Using New Security Technologies Nat Sakimura Nomura Research Institute www.oasis-open.org

2. Alice How can I trust that the user is Alice? Is the data provided accurate? IdP RP Can I trust this RP? Can I trust Alice? How can I trust this RP that it will treat my data as promised?

3. Market Failure

4. Empirical Study • Funded by Ministry of Internal Affairs and Communication (MIC) • n=117, distributed same as the population. • Observed testing combined with F2F interviews Source: Based on the Report on Identity Federation Substantial Experiment

5. Restaurant Search Engine + Restaurant Sites (Both Mobile and PC) • Users are told to find the restaurants they want to go and reserve. • Registration requires various user information depending on the site. • Some are traditional “Form Submission” • Some are using Identity Federation and attribute sharing.

6. - Results - How It looked like Name Post Code Address Telephone Mail Address Sex Occupation Age Attribute Sharing AuthN + Attr AuthZ User IdP AuthZed Attrs is being sent from IdP to RP ① ② ③ No need to fill in the info that the user authzed to be sent AuthZed AttrsSent to RP Users needed to fill-in the attrsnot sent by IdP RP Source: Based on the Report on Identity Federation Substantial Experiment

7. - Results - Attribute Sharing Greatly improves the user experience Both Time Required to complete And the Error Rate were reduced. With Attrs Sharing Without Attr. Sharing Time Req. to complete registration 1’33” 0’19” （Down 80%） Input ErrorRate 19.6% 7.1% （Down 65%） (N=177) Attribute Sharing AuthN + Attr AuthZ User IdP ① ② ③ No need to fill in the info that the user authzed to be sent AuthZed AttrsSent to RP RP Source: Based on the Report on Identity Federation Substantial Experiment

8. User Feedback - 94% Answered that they want to use Attribute Sharing Services. Do yo want to use such Attribute Sharing Services? Source: Based on the Report on Identity Federation Substantial Experiment

9. User Feedback - 97% Users wanted to have a way to find out the trustworthiness of the RP Additional Features Wanted by the Users Additional Features Requested Assist users to find out if the RP is trustworthy Selectively Send the attributes (e.g., not sending telephone no.) Automatically notify/update the selected RPs when Attrs changed. Select one from Multiple “profiles” when sending attrs. Source: Based on the Report on Identity Federation Substantial Experiment

10. How? • Third Party Audit • E.g., Open Identity Trust Framework • Reputation • “Reputation is a subjective evaluation of the assertion about an entity being true based on factual and/or subjective data about it, and is used as one of the factors for establishing trust on that subject for a specific purpose. Reputation can be aggregated by rolling up opinions from smaller sets like individuals.” Open Reputation Management Systems (ORMS) TC

11. Individual & demographic data – entity E Portable Reputation Data Input Input data collection/ generation Context Computation of Trust by (external) Consuming party Input data collection/ generation Oberved data – Entity E Reputation Computer Pub-Sub Input data collection/ generation Real-world data: entity E (local) Reputation Input data collection/ generation Inferred data: Entity E … Portable Reputation Input data collection/ generation subjective data – Entity E Reputation System Computation of Trust by (external) Consuming party Reputation of Input entities ORMS Reference Model Source: ORMS TC, “Use Cases”

12. Reputation Format Requirements • Reputation result XML needs to have an identifier of somebody being scored. • It may include PII (e.g., Social Security Number), so it may be wise to mandate that this be a hash(identifier, salt)?=>Protocol Consideration • The same for who is scoring, and sometimes for who is receiving. • For what criteria, this reputation score was made. • Input Data Range • For the reputation to be aggregatable, it has to have a distribution that we know about the aggregated distribution (such as normal distribution). • The information about the distribution, including what distribution, mean, and standard deviation must be published together with the score. • Display score should be intuitive for an average person. • Date that score was made • Signature by the score maker so that it will be tamper proof. Source: ORMS TC, “Use Cases”

13. Protocol Requirements • PR1. The reputation consumer SHOULD be able to obtain the reputation file by specifying the assertion including the subject identifier. • PR2. Since the reputation data itself is often an sensitive data including PII, it SHOULD have the following security considerations: • SubjectID SHOULD be represented so that it cannot be traced back to the Subject, e.g., sha256(SubjectID, salt). This implies that the protocol should be a request-response protocol since otherwise the receiver cannot map the file to the Subject. • Be able to make the source detectable in the case of the leakage, the file should contain the requester ID. • To make the request forgery-proof, the request should contain the digital signature of the requesting party. • To protect from eavesdropping and MITM attacks, the response should be encrypted using a content encryption key (session key) which in turn is encrypted by the requesting party’s public key. • Considering that the mere fact that an entity is requesting a reputation representation of the subject may be a privacy risk, the request probably should be encrypted in the same manner as the response, with reputation authority’s public key. Source: ORMS TC, “Use Cases”

14. Example Reputation Display Last Login, How Many Times in the Past. Reputation Authorize Source: Based on the Report on Identity Federation Substantial Experiment