[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
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.
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 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
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]