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

[Dan Blum <dan@respectnetwork.net>]

It seems pretty clear the way you describe it, Drummond.

I like your use of "formulas" as descriptions. It would be good to have a formulas for the opposite process of checking the signatures.

Two question:

why  does this contextual statement have two slashes?

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

Does this approach only work when you're signing an entire statement? What if you want to sign an entire graph, or just a literal?

Dan

On Sun, Jun 29, 2014 at 11: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.