$is and $xis scenarios for discussion on today's telecon

[Drummond Reed <drummond@connect.me>]

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