[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

The notion of an ``individual'' (e.g. person, corporation, process, or machine) is not required

"Principals are public keys. Our system is ``key-centric'': SDSI principals
are public digital signature verification keys. These public keys are
central; everything is based around them. The notion of an ``individual''
(e.g. person, corporation, process, or machine) is not required. Of course,
such individuals will actually control the associated private keys, so that
the public/private keys can be viewed as ``proxies'' for those individuals.

As should be evident from my mail sequence, Im trying to prepare
a SPKI/SDSI pilot to help propel adoption of the ideas, and (of course)
one element is to fixup the legal stuff so at least people know where
they stand in relation to an issuer, and the act of issuance.

Whilst academically, individuals as a system notion may not exist,
legally they will always exist. Sorry if this offends you; its just
true. As those who control private keys, they will be responsible, and
the SDSI notion which is in concordance with SPKI does assert that
essentially there is a proxy relationship between the [(re)liable]
party and key, and a "speaking act" occurs.

In a B3-DAC conforming capability list design, normally the protection
system knows about and controls who has capabilities. (I don't know if
any such animal actually exists, BTW) and can mediate in the
transference of permissions, change of domains etc. In the SPKI environment,
there is no such central protection system.

Logically, it seems legal responsibility for
the act of passing the capability has passed form the control obligations
of the central system, to those who actually release a reduced
capability chain signed by themselves to another for that
parties use and reliance.

The nature of the design to date allows an number of outcomes
as to enforcement, which are not controlled by the party
which release a capability for others to rely upon.

Is there a need therefore to limit potential damage 
and repercussion on the releasing party? (I tend to
say yes, these days!)

SDSI/SPKI may want to consider a design need for the
releaser to mandate, and provide a signal and procedure
requirement set  for, a "critical" auth-field enabling
that issuer to make a representation that this
is the choice (or choices) which it is willing to
stand behind legally. So as not to impact the
free-wheeling permission design, anyone can actually
do whatever they like with other tagged permissions, but they
cannot hold the issuer accountable. Everything else is
"hold harmless".

Hopefully, one can see Im looking for the angle
by which legal reliance properties can be controlled technically,
without upsetting the intent of the SPKI system
or the kinds of flexibilities it wishes to engender,
when used in a public environment where there is
just no escaping legal stuff.