[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [External] [xdi] $is and $xis scenarios for discussion on today's telecon
Drummond,
WRT: Right now I don't see any way to have just a single $is verb and not create major confusion about when an equivalence link is exposed and when it is not exposed, which misunderstanding is itself a privacy and security risk…
The rules I was trying to suggest, and didn’t do a good job on, were $(a)/$is/$(b) is revealed in the returned results of an XDI operation if and only if
1) the link contract permits it
2) $(b) is not an i-number, unless this is explicitly over-ridden by the link contract
3) $(a) is not an i-number, unless this is explicitly over-ridden by the link contract
Example 1:
The graph:
=al/$is/!1111
=bob/$is/!1111
=al$!(+name)/!/(data:,Al%20Robert%20Smith)
The operation:
A $get for ="">$!(+name)
The result:
Empty set
Example 2:
The graph:
=al/$is/!1111
=bob/$is/!1111
=al$!(+name)/!/(data:,Al%20Robert%20Smith)
=bob/$is/=al
The operation:
A $get for ="">$!(+name)
The result:
=bob$!(+name)/!/(data:,Al%20Robert%20Smith)
Example 3:
The graph:
=al/$is/!1111
=bob/$is/!1111
=al$!(+name)/!/(data:,Al%20Robert%20Smith)
=al/$is/=bob
The operation:
A $get for ="">$!(+name)
The result:
Empty set
Put another way, the binary $is XDI predicate is…
-Reflexive : R is reflexive if for all x in A, (x,x) in R, (Equivalently, for all x in A, x R x.)
-NOT symmetric : R is symmetric if for all x,y in A, (x,y) in R implies (y,x) in R. (Equivalently, for all x,y in A, x R y implies that y R x.)
-Transitive : R is transitive if for all x,y,z in A, (x,y) in R and (y,z) in R implies (x,z) in R. (Equivalently, for all x,y,z in A, x R y and y R z implies x R z.)
If any var is an i–number though, then the transitive property is broken. Actually thinking about it more I think we do need a new predicate, but not $xis..a new predicate that has any XDI node’s XRI as its domain and an i-number as its range. $is then cannot be between i-numbers. So =al/$is/!1111,=al/$is/=bob become =al/$as/!1111, =al/$is/=markus. Though I think !1111/$as/=al makes more sense, maybe. Might also need $sameid or some such for when domain and range are both i-nums.
Kind regards,
Bill Barnhill
Booz Allen Hamilton - Belcamp,MD
Cell: 1-443-924-0824
Desk: 1-443-861-9102
From: drummond@respectnetwork.net [mailto:drummond@respectnetwork.net] On Behalf Of Drummond Reed
Sent: Friday, November 09, 2012 10:18 AM
To: Barnhill, William [USA]
Cc: OASIS - XDI TC
Subject: Re: [External] [xdi] $is and $xis scenarios for discussion on today's telecon
Bill,
In case it wasn't clear in my message, I believe all use cases are served and all problems are solved cleanly by defining very strict behavior for $is and $xis. Both options are then clear to all developers, top to bottom.
Right now I don't see any way to have just a single $is verb and not create major confusion about when an equivalence link is exposed and when it is not exposed, which misunderstanding is itself a privacy and security risk.
I look forward very much to discussing this on the call - I think this is going to end out being one of the most crucial features of the XDI graph model.
=Drummond
On Fri, Nov 9, 2012 at 6:56 AM, Barnhill, William [USA] <barnhill_william@bah.com> wrote:
So I looked at this and have a different take on option 2, such that I think option 1 really needs to be how we go and option 2 cannot be allowed under any circumstances, in order to protect user identity.
1. “Option #2 exposes the true structure of the XDI graph to the client, which is actually very useful to the client for several reasons” – While this is useful to the client, it also exposes a security risk because it has leaked the i-number behind =markus.
2. Regarding the client being able to associate =markus and =Sabadello, I think this is behavior we don’t want the client to have, unless the graph authority also adds a statement =markus/$is/=sabadello.
3. Counter scenario to ponder: it’s =bob and =voltaire. Bob writes under the nom de guerre Voltaire with extreme political rants and does not want the connection between his identity as Bob and his identity as Voltaire known, except to a few people who help him. As a result he adds a =bob/$is/=voltaire to the graph with a link contract limiting discovery/result-inclusion of that statement to only his circle. With option 2, everyone can know who =voltaire is with two $gets, one for a property of =voltaire and one for a property of =bob.
4. I think the actual i-numbers should only be returned if used in the query explicitly, if the query is internal for the server, or if the query is performed under a share-all link contract.
5. The #xis vs #is is an interesting idea, but I think in implementation everyone starting with XDI will use #is. Since with option 1 we can support the required use cases without creating a new XDI verb, but with option 2 we need to create a new XDI verb, it seems to me that is an argument for going with option 1.
6. If you want the link known add the link specifically, as in 2 above.
7. As a result I do not consider the problem scenario as such, instead I consider that behavior a required use case, and strongly urge we go with option 1, without a $is and a $xis.
8. On precise $is behavior, I think there are three different sets of behaviors:
1. $is behavior in producing XDI message results
2. $is behavior when modifying the graph
3. $is behavior when evaluating a policy decision (i.e., link contract)
9. In #8, 8.2, 8.3 are internal to the server, whereas 8.1 is external, so you could possibly group 8.2 and 8.3
Kind regards,
Bill Barnhill
Booz Allen Hamilton - Belcamp,MD
Cell: 1-443-924-0824
Desk: 1-443-861-9102
From: xdi@lists.oasis-open.org [mailto:xdi@lists.oasis-open.org] On Behalf Of Drummond Reed
Sent: Friday, November 09, 2012 9:10 AM
To: OASIS - XDI TC
Subject: [External] [xdi] $is and $xis scenarios for discussion on today's telecon
Markus has been leading a discussion among the XDI2 developers about $is behavior. I can summarize it in the following two scenarios:
OPTION #1
If you have the following XDI data:
=markus/$is/=!1111
=!1111$!(+name)/!/(data:,Markus)
=!1111$!(+age)/!/(data:,33)
And you send an XDI operation like the following:
.../$get/=markus$!(+name)
You'll get back this response:
=markus$!(+name)/!/(data:,Markus)
OPTION #2
If you have the following XDI data:
=markus/$is/=!1111
=!1111$!(+name)/!/(data:,Markus)
=!1111$!(+age)/!/(data:,33)
And you send an XDI operation like the following:
.../$get/=markus$!(+name)
You'll get back this response:
=markus/$is/=!1111
=!1111$!(+name)/!/(data:,Markus)
***************
Since I joined the discussion late, I shared the following feedback:
RATIONALE FOR OPTION #2
1. Option #2 does not create any new XDI statements. In the first option, =markus$!(+name)/!/(data:,Markus) is actually a new XDI statement that does not exist natively in the XDI graph stored at the (=markus) endpoint. It can be logically inferred from the two statements =markus/$is/=!1111 and =!1111$!(+name)/!/(data:,Markus). But the statement =markus$!(+name)/!/(data:,Markus) does not actually exist natively in that store.
2. Option #2 exposes the true structure of the XDI graph to the client, which is actually very useful to the client for several reasons:
1. Without needing to ask explicitly for it, the client app discovers the i-number for ="">
2. This allows the client app to immediately begin caching an accurate subset of the XDI graph for ="" in case it needs it (efficiency).
3. The client now knows the persistent i-number associated with =markus and can use that for future queries (persistence).
3. Perhaps most importantly, it avoids the following potential problem scenario:
PROBLEM SCENARIO
1. Markus registers both =markus and =sabadello as synonyms for ="">
2. Client requests .../$get/=markus$!(+name)
3. Server returns =markus$!(+name)/!/(data:,Markus)
4. Client writes that into client-side database as identity for ="">
5. Repeat for other attributes of =markus
6. Next time Markus presents identity as =sabadello
7. Client requests .../$get/=sabadello$!(+name)
8. Client gets back =sabadello$!(+name)/!/(data:,Markus)
9. Client has no idea that identity is already present in its database.
Net net: except in the case of anonymity/pseudonymity, all of these issues are avoided if the server simply treats $is statements as "redirects" within the XDI graph AND includes these redirects in its response to a client. So the "redirect graph" of $is statements is transparent on both the server and the client.
Note that for the use case for anonymity/pseudonymity, there is still the need to support having a $is verb whose semantics is exactly the opposite, i.e., that the XDI server MUST still follow the equivalence link but MUST NOT expose the equivalence link to the client. This is what motivates my proposal for the $xis verb (which I've mentioned but not formally proposed on the XDI TC wiki yet). Here's an example of how $xis works:
$XIS SCENARIO
If you have the following XDI data:
=markus/$is/=!1111
=!1111$!(+name)/!/(data:,Markus)
=!1111$!(+age)/!/(data:,33)
=pseudonym/$is/=!2222
=!2222/$xis/=!1111
And you send an XDI operation like the following:
.../$get/=pseudonym$!(+age)
You'll get back this response:
=pseudonym/$is/=!2222
=!2222$!(+age)/!/(data:,33)
So, while the server still transparently reveals the $is mapping between =pseudonym and =!2222, it does NOT reveal the mapping between =!2222 and =!1111. That way Markus can still maintain one graph (=!1111) of the attributes he wants to share veronymously, but he can also choose to share any set of those attributes pseudonymously.
*************
Since deciding precise $is behavior is fundamental to many operations on the graph, I made this our top priority discussion for today's call.
=Drummond
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]