www.oasis-open.org
Click to edit Master title style
Coping with Information Asymmetry
SESSION G: Managing Risk & Reducing Online Fraud Using New Security Technologies
Nat Sakimura
Nomura Research Institute
© 20101 by Nat Sakimura.
How can I trust that the
user is Alice?
Is the data provided
accurate?
IdP
Can I trust
this RP?
Can I trust
Alice?
RP
Alice
How can I trust this RP
that it will treat my data
as promised?
© 20101 by Nat Sakimura.
2
Market Failure
© 20101 by Nat Sakimura.
3
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
© 20101 by Nat Sakimura.
4



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.
© 20101 by Nat Sakimura.
5
- Results -
Name
Post Code
Address
Telephone
Mail Address
Sex
Occupation
Age
How It looked like
Attribute Sharing
User
AuthN +
Attr AuthZ
IdP
AuthZed Attrs
is being sent
from IdP to RP
①
No need to
fill in the info
that the user
authzed to be
sent
© 20101 by Nat Sakimura.
AuthZed Attrs
Sent to RP
RP
Users needed
to fill-in the attrs
not sent by IdP
Source: Based on the Report on Identity
Federation Substantial Experiment
6
- Results -
Attribute Sharing Greatly improves the
user experience
Both Time Required to complete
And the Error Rate were reduced.
Attribute Sharing
User
AuthN +
Attr AuthZ
IdP
①
No need to
fill in the info
that the user
authzed to be
sent
© 20101 by Nat Sakimura.
AuthZed Attrs
Sent to RP
RP
Without
Attr. Sharing
Time Req.
to complete
registration
1’33”
Input Error
Rate
19.6%
With Attrs
Sharing
0’19”
（Down 80%）
7.1%
（Down 65%）
(N=177)
Source: Based on the Report on Identity
7
Federation Substantial Experiment
-User Feedback -
94% Answered that they want to use
Attribute Sharing Services.
Do yo want to use such Attribute Sharing Services?
Do not
Want
3%
Yes
41%
Never
0%
Don't
Know
3%
Strongly
Yes
53%
Source: Based on the Report on Identity Federation Substantial Experiment
© 20101 by Nat Sakimura.
8
-User Feedback -
97% Users wanted to have a way to find out
the trustworthiness of the RP
Additional Features Wanted by the Users
Very Much
0%
20%
Additional
Features
Requested
Assist users
to find out
if the RP
Selectively Send the attributes
(e.g., not sending telephone no.)
Select one from Multiple
“profiles” when sending attrs.
40%
Not So Much
60%
72.6
is trustworthy
Automatically notify/update the
selected RPs when Attrs
changed.
Somewhat
33.3
80%
100%
24.8
63.2
42.7
Not At All
31.6
41.9
52.1
2.6
0
4.3
0.9
14.50.9
14.5 0
Source: Based on the Report on Identity Federation Substantial Experiment
© 20101 by Nat Sakimura.
9
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
© 20101 by Nat Sakimura.
10
ORMS Reference Model
Input data collection/
generation
Individual
&
demographic data
– entity E
Input data collection/
generation
Oberved
Entity E
data
Context
–
Input data collection/
generation
Real-world
entity E
data:
Input data collection/
generation
Inferred
Entity E
data:
Reputation
Computer
Computation
of
Trust by (external)
Consuming party
(local)
Reputation
Portable
Reputation
Data Input
Pub-Sub
…
Input data collection/
generation
subjective data –
Entity E
Reputation System
Portable
Reputation
Computation of Trust
by (external)
Consuming party
Reputation of
Input entities
© 20101 by Nat Sakimura.
Source: ORMS TC, “Use Cases”
11
Reputation Format Requirements
1. 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
2. The same for who is scoring, and sometimes for who is
receiving.
3. For what criteria, this reputation score was made.
4. Input Data Range
5. For the reputation to be aggregatable, it has to have a
distribution that we know about the aggregated distribution
(such as normal distribution).
6. The information about the distribution, including what
distribution, mean, and standard deviation must be published
together with the score.
7. Display score should be intuitive for an average person.
8. Date that score was made
9. Signature by the score maker so that it will be tamper proof.
© 20101 by Nat Sakimura.
Source: ORMS TC, “Use Cases”
12
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”
© 20101 by Nat Sakimura.
13
Example Reputation Display
Last Login, How Many
Times in the Past.
Reputation
Authorize
© 20101 by Nat Sakimura.
Source: Based on the Report on Identity
Federation Substantial Experiment
14