[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Drastic SPKI simplifications
My latest drastic simplification proposal is that we describe a 2-tuple,
3-tuple and 4-tuple, in the following order:
[ Issuer, Assertion ]
- makes assertions about self.
[ Issuer, Assertion, Target ]
- delegates authority (or name or other information) to target,
with optional validition restrictions.
[ Issuer, Assertion, Target, Propagation ]
- adds optional permission to propagate specific authority.
====
One of the confusions that I've had with the current 5-tuple terminology
is the use of "Subject". I keep thinking of the Subject as principal
actor, and the Assertions as verbs (actions).
Actually, the principal actor is the Issuer, the Assertions are more
like combined adjectives, adverbs and subordinate clauses, and they all
act upon the Subject.
Therefore, I propose we change the term from Subject to Target.
====
I also recently noted that Validation is optional, and not required in
every certificate. If we think of it as a subordinate clause, then it
too is really part of Assertions, as a positive assertion about a time
restriction or other action. This brings us down to a 4-tuple.
====
Another confusion I've had with the current 5-tuple terminology is that
Delegation is optional, and is really permission to propagate the
properties in the Assertions (which are what is delegated).
Therefore, I propose we change the term from Delegation to Propagation.
This serendipitously matches the current syntax "(propagate)".
Propagation is optional. This brings us down to a 3-tuple.
====
I've been recently thinking that having a Target is also optional, as
the Issuer could be making Assertions about Self without delegating or
propagating. This brings us down to a 2-tuple.
====
Finally, I keep rearranging the 5-tuple syntax to match the order of the
parenthetical nestings in the certificates. This is too confusing. It
should be more clear that the 5-tuple is a theoretical construct, and
its order has nothing to do with the order of an actual certificate.
The <sequence> merely enhances this confusion. I have already proposed
a replacement.
WSimpson@UMich.edu
Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32
BSimpson@MorningStar.com
Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2
Follow-Ups: