Re: [xdi] final (i hope) signature proposal

[Joseph Boyle <planetwork@josephboyle.net>]

I think the purpose of the collection and member indexing in Peter’s examples was for the user or authority named =example to have a list of all their signatures in one place. Not sure whether we ever explicitly discussed whether this was a requirement, or whether it is enough to have signature information a little more distributed in the graph as in Drummond’s example below - Drummond, what is your view here?

There was also uncertainty on whether the literal value has to be part of the signature of the literal statement that sets the value - Drummond, why is this unnecessary?

Dan, the double slash indicates a triple where the predicate is empty string. This is a “contextual statement” whose meaning can be explained as “trace from the common root down to the =example<#work> node in the graph, then create the path <#email> starting from that node.” The path resulting from the statement is simply =example<#work><#email> which does happen to coincide with the contextual statement with the // removed. Conversely, you can take a path from common root to an existing node, and by inserting // at any point, get a contextual statement which asserts/creates that path, possibly assuming that the first part of it exists - Markus, do we get an error if the subject node doesn’t yet exist?

This indicates to me that contextual statements are very closely related to context paths, and that according to the XDI philosophy that the graph is fundamental and serialization secondary, we should prefer to sign the subgraph (which is just a path, in this case) rather than the statement creating the path, unless there is a good reason to do so.

I think literal statements are similar: the statement =example<$email><$work>&/&/"example@employer.org" creates an address (path from root) which is  =example<$email><$work>&"example@employer.org” which is identical to the statement with /&/ removed. We know the literal is addressable because this was a major XDI design principle and the & arc was designed with this in mind. Applying the same philosophy as for contextual statements, we should be able to act on and sign the path =example<$email><$work>&"example@employer.org” in preference to signing the literal statement creating the path. However, currently XDI2 rejects =example<$email><$work>&"example@employer.org” as illegal syntax, which seems to me an arbitrary restriction inconsistent with the principle of addressability of the literal.

The third type of statement is relational, such as =drummond/#friend/=markus. This is also just a means to create a subgraph, but here that subgraph is a triangle rather than a single path. I think we should first think it out in terms of signing this triangular subgraph, rather than thinking in serialization. 

In general I think our thinking has been too colored by expressing all examples in (Display) serialization as lists of statements, rather than thinking primarily about subgraphs.

If we have a general procedure for signing subgraphs, then some of the issues about signing statements specifically should disappear.

On Jun 29, 2014, at 8:37 AM, =Drummond Reed <drummond.reed@xdi.org> wrote:

I just got to this thread, and there are syntactic problems with both top-level signature statements.

In the first example:

=example/$sig(=example/#friend)/=example[<$sig>]<@0>

The first problem is that there is inner root under an entity, i.e., 

$sig(=example/#friend)

An inner root (just like a peer root) can only be used at the start of a subject, predicate (where it would be strange to have an inner root), or object.

The second one is that I can't actually figure out what statement is being signed. So rather than guess, I'll make the assumption that the example statement you want to sign is a relational statement something like this:

=drummond/#friend/=markus

Based on what we talked about on yesterday's call, the pattern to sign this statement would be:

(=drummond/#friend)=markus[<$sig>]<@0>

So the formula for signing a relational statement is:

1. Turn the statement subject and predicate into an inner root.
2. Put the statement object in the context of this inner root.
3. Add the signature attribute to that.

Now, for the second example. The statement that is being signed is a relational statement:

=example<$email><$work>&/&/"example@employer.org"

There are two issues with this statement - first that $email and $work are not $words but #words, and second that the semantics should be reversed because in XDI specialization is right-to-left, i.e., #work specializes #email so it should go before it. So the statement should read:

=example<#work><#email>&/&/"example@employer.org"

Now, to sign this statement, the signature goes on the address of the literal. The actual literal value (in quotes) never gets included in another statement, i.e., the actual literal value only ever appears as an object.

Based on our discussions yesterday, and the conclusion that we don't want inner roots to have blank relational arcs, the pattern to sign this literal statement would be:

(=example<#work><#email>&/&)[<$sig>]<@0>

So the formula for signing a literal statement is:

1. Turn the statement subject and predicate (the &) into an inner root.
2. Add the signature attribute to that.

Lastly, to complete the set, if you want to sign a contextual statement such as:

=example<#work>//<#email>

then we agreed yesterday that we need a non-blank predicate to represent the contextual arc. Per my suggestion yesterday, we can use () for this. So the signature statement would be:

(=example<#work>/())<#email>[<$sig>]<@0>

So the formula for signing a contextual statement is:

1. Turn the statement subject into an inner root.
2. Add the predicate ().
3. Put the statement object in the context of this inner root.
4. Add the signature attribute to that.

So that covers all three options for signing single statements. To sign any other type of subgraph, just add the $sig signature attribute to the context node that is the parent of the subgraph.

=Drummond 

On Thu, May 22, 2014 at 11:59 AM, Davis, Peter <Peter.Davis@neustar.biz> wrote:

first, thanks to all who contributed comments and feedback for this. I think we are now very close to a final workable proposal. below are two examples. the first is the subject signing the inner graph (=example/#friend). The second is an employer signing the work email address of =example. These examples also include the key material information found in the graph. not that the actual signature (assertion) in the work email example is stored in the employers graph (not the subject), though it could have just as easily been stored in the =example graph.

1  ——————

=example/$sig(=example/#friend)/=example[<$sig>]<@0>

=example[<$sig>]<@0>/$is#/$sha$256$rsa

=example[<$sig>]<@0>&/&/"PXBldGV..."

=example[<$sig>]<@0>/$key/=example[<$key>]<@4><$public>

=example[<$sig>]<@0><$sigdate><$t>&/&/"2014-05-30T09:02:32Z"

=example[<$key>]<@4><$public>&/&/"IDjsia9jdSJD..."

=example[<$key>]<@4><$public>/$is#/$pem

=example[<$key>]<@4><$private>&/&/"HWYS8fdj9ksK..."

=example[<$key>]<@4><$private>/$is#/$pem

=example[<$key>]<@4><$notbefore><$t>&/&/"2014-01-01T00:00:00"

=example[<$key>]<@4><$notafter><$t>&/&/"2014-12-31T23:59:59"

2 ——————

=example<$email><$work>&/&/"example@employer.org"

=example/$sig(=example<$email><$work>&/&/"example@employer.org")/+employer[<$sig>]<@22>

+employer[<$sig>]<@22>/$is#/$sha$256$rsa

+employer[<$sig>]<@22>&/&/"PXBldGV..."

+employer[<$sig>]<@22>/$key/+employer[<$key>]<@9><$public>

+employer[<$sig>]<@22><$sigdate><$t>&/&/"2014-05-30T09:02:32Z"

+employer[<$key>]<@9><$public>&/&/"IDjsia9jdSJD..."

+employer[<$key>]<@9><$public>/$is#/$pem

+employer[<$key>]<@9><$private>&/&/"HWYS8fdj9ksK..."

+employer[<$key>]<@9><$private>/$is#/$pem

+employer[<$key>]<@9><$notbefore><$t>&/&/"2014-01-01T00:00:00"

+employer[<$key>]<@9><$notafter><$t>&/&/"2014-12-31T23:59:59”

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.