[xdi] question on singletons

[Markus Sabadello <markus.sabadello@gmail.com>]

Hi Peter yes this is an interesting situation and it has come up a few times in the past.

I think an xdi server should be able to do this automatically, i.e. convert a singleton into a collection.

We might need a specialized operation for this, e.g. [$set] instead of $set or something like that. Also, such an operation should be able to work with both ordered and unordered collections.

I don't think all attributes should always be collections, I am confident we can make it so a client does not have to know the structure of the attribute when constructing the $msg.

So the server would create the [<#email>] as you describe it. In addition it would change the <#email> to have a $ref to to the original value which is now inside the collection.

This $ref I think would take care of Dan's concern. A client with a link contract for <#email> would still be able to access it after the change.

I don't understand your point about $set and $get permission. Obviously for adding an email address you would need $set.

I agree with our current signatures proposal(s) we might have to recreate signatures. That seems not ideal.

Markus

On Wednesday, July 9, 2014, Davis, Peter <Peter.Davis@neustar.biz> wrote:
> In doing some additional exploration of corner cases for signatures, I came up with the following scenario:
> 1] a graph contains the singleton: =example<#email>&/&/“me@example.biz”
> 2] time passes, and the subject needs to add a new, additional, email to the graph: “me@example.org”
> what i assume will transpire is:
> 1] delete the singleton =example<#email>&/&/“me@example.biz”
> 2] create a new email collection:
> =example[<#email>]<@0>&/&/“me@example.biz”
> =example[<#email>]<@1>&/&/“me@example.org”
> how does an XDI service know ahead of time this is what needs to be done, or is that somehow automatically handled by the graph server? if the former, what happens if the client does not have a $get policy, but does have a $set policy in place?
> this means (among other cascading consequences), that if a signature/encryption was present on the original singleton, a new signature/encryption values need to be generated for one or both of the new triples.
> =peterd
> Peter Davis: Neustar, Inc.
> Distinguished Engineer, Director, Neustar Foundry
> 45980 Center Oak Plaza Sterling, VA 20166
> [T] +1 571 434 5516 [E] peter.davis@neustar.biz [W] http://www.neustar.biz/ [X] xri://@neustar*pdavis [X] xri://=peterd
>
> The information contained in this e-mail message is intended only for the use of the recipient(s) named above and may contain confidential and/or privileged information. If you are not the intended recipient you have received this e-mail message in error and any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately and delete the original message.
>