Human-to Human Delegation Issues in Open World
Session Topic: Human-to-Human Delegation Issues in Open World
Convener: Hidehito Gomi
Notes-taker(s): Amanda Anganes
Tags for the session - technology discussed/ideas considered: Delegation, human interaction, OAuth 2
FitBit, NIKE air band, personal information tracking – data is viewable on your smart device and also shareable
Human-Human – directly sharing information with other people
This is more often accomplished in the real world via human-software (or software- software) interaction (unless you email someone an access token)
OAuth example on the board – Alice stores her data (including personal health records) on a server, using an OAuth token; application can access the data using another Access Token
What happens when Bob wants access (and Alice wants to give it)?
Bob talks to the application; connection between Alice and Bob is not tight. This is possible using OAuth 2.0 flows / UMA where Alice can grant access to Bob so he can get a properly scoped Access Token to access the data.
Enter Carol, malicious. She tries to intercept token from Bob – if it is a true bearer token, then she can use the token maliciously to get the data.
Solutions – SSL everywhere (can use Bearer tokens), or stronger signed tokens (such as SAML assertions).
Open World – no pre-arranged agreements, Bob may not necessarily have an account on the same IdP that Alice is using. We don’t want to assume a full PKI environment.
If you can assume SSL everywhere then Bearer tokens may be OK in this scenario.
Hidehito’s proposed solution – we need delagatee authentication But how to do this with non-connected IdPs?
- Identity federation? Doesn’t quite fit with Open World assumption.
- Or, Alice puts in a rule that says Bob, authenticated at IdP2, is allowed to access her data as long as he can prove that he is Bob at Idp2.
- This requires some amount of channel/message security
- Cryptographic notion of the “1 free round/message”
- PIN transfer, secret exchange, etc
If you can do a secure secret exchange, can use same client secret from both Bob & Alice. Still have the problem of getting the secret to Bob over a secure channel, and man-in-the-middle attack.
Hidehito – what about some kind of “context”, such as geolocation
- This is easily forged, VPN tunnels into particular locations
We need a formal definition of the problem – security framework, assumptions, use case, threat model – then we could talk about proper mitigations of attacks.
Action item – if Hidehito can contribute to notes his description of
- Network model (what is open, what is not)
- Threat Model
Then we could continue conversation further
For example, it matters who Carol is and what she knows/how she is attempting to attack & intercept the personal health records.
Can we assume that it would be OK to transfer “1 free message”? Once a secret is established, we can establish a secure channel.
Alan Karp from HP showing a demo of person-to-person sharing; “Home Page for Sharing”
- Family with data for each person
- Lisa can share data with other family members, see what she has shared
- Home page is protected with URL containing unguessable random home page URL, + SHA of Lisa’s key. Not OAuth based but could use OAuth tokens. Based on WaterKen. Waterken server guarantees no failures, everything is processed exactly once.
- Things on the desktop environment can be arranged in 2-dimensions; not hierarchical. Claim that humans have evolved to handle 2D nav well, but not hierarchical. Interface is a proof-of-concept (good interaction design, not UI).