Inclusion Lists for Hypercardus Clonus

[Eric Dean Tribble <tribble>]

Abstract: I discuss why we need conformance checking and
re-registration soon (probably first product).  I also finally can
articulate my main discomfort with the endorsement implementation of
work-types (distributed authentication) and look at the partial
solutions that I know of currently.

   Yep.  The problem doesn't arise for the backend for any of the initial
   Xanadu-supplied waldos, or any data entered through any backend-waldo
   of the appropriate type, because it had to conform to be entered.

Right now we only implement de-registration.  We really do need
re-registration (confirmance testing and type upgrades) to fully use
our Waldos.  Imagine importing data: I make a program dump all my
files into Xanadu documents, then later I figure out which ones are
text documents.  Or, I dump in PostScript files, and then later
register some of them as Janus programs (described pictorially in
postscript).  I'm sure we'll see lots more examples.  I expect such
examples to arise almost immediately, too.  I also consider it
sufficiently important that third party Waldo types have conformance
checking that it should really be part of the protocol.

   It MAY arise if we, in some future release, integrate a third-party
   waldo (say, "WordAStra") into the backend.  At that point, we may want
   to make it automagically endorse with "Xanadu WordAStra" any "WordAStra"
   data it retrieves that conforms.  (Since the backend would be endorsing
   the data as conforming to our idea of the spec, it wouldn't rubberstamp
   the endorsements from (potentially-broken) frontends, but would check
   for itself.)

This strikes me as a bad idea for lots of reasons, most unrelated to
possible implementations.  Eventually, Waldos will encapsulate their
doc-type endoresement capability, so only documents created with the
original "WordAStra" Waldo will have that type (regardless of broken
frontends).  The doc-type should be incorporated (if at all) by
licensing the endorsment used by the original Waldo.  I think we'd
consider doing this only very rarely.  I would rather facilitate
pushing arbitrary Waldos into the mid-end so that any user can get
efficiency for any Waldo.

   It may also arise if we decide to check the data that arrives over BEBE.
   We should do that starting with the first release where backend-users
   will be running BEBE with a competitor's machine, to prevent a hacked
   backend feeding them "poisoned" data.

Bing!  You've hit the problem that's nagged me for awhile about
Waldos.  Waldos encapsulate an endorsement which represents their
type.  They endorse any Stamp made using them.  Since endorsements
really correspond to digital signatures in the distributed system,
this would require having every user defined waldo sign the
cryptographic hash of the contents of every orgl it makes - an
expensive proposition.  MarkM and I just discussed optimizing this for
all Waldos within a trust boundary, but it still looks expensive.  For
the normal use of endorsements (as endorsements), this would only need
to be done to stamps generated by the highest level Bert (that
actually carries endorsements).  This endorsed Bert would only get
hopped on Saves.  

Your "claimed-to-be-Foo" endorsements suggest another solution to the
BEBE case.  When non-authenticated endorsements gets transmitted to an
untrusted backend, they become endorsement hints.  These would
particularly be used for work-types and link-types.  A frontend that
recognizes a particular endorsement-hint would then check conformance
on the endorsement and then confirm for that backend that the document
actually had that type.  

dean