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

Re: Rant on Capability Security [LONG]



At 08:58 AM 4/18/97 -0400, jar@ornl.gov wrote:
>Bill,
>
>I  think you are missing some of the power of SPKI as I envision it. The
point 
>is that there are lots of situations where authority is not mapped
directly onto 
>file (or device) access permissions. If the latter were adequate, the CMW 
>solution probably covers most of your points.
>
>Instead, I see executable programs (single entities) that do different
things 
>according to the certificates presented to it when it starts to run. My
example 
>of remote access to online facilities is a good example. A grade-school
student 
>might be able to view the output of an electron microscope, but not have
access 
>to the focus controls. A researcher could do everything.
>
>Jim Rome
>


This is my basic mental model, also. Providing one can determine the precise
scope of PolicyMaker language, and make a java class which is equivalently
restricted to those language features, then, as with PolicyMaker, assuming a
type-safe and trusted execution environment, there is no reason why the
specific security policy rules which authorize an action cannot be
expressed in java application "notation" within an auth field.

End-systems can persistently learn permission schemes, or obtain the
implementation of the arithmetic and reduction algebra from the auth-field
each time, where the notation is a trusted java class. A minimum profile of
SPKI may or may not mandate support for the static Policy maker language...we
will see.

I actually cannot find however a non-proprietary-controlled PolicyMaker 
detailed description document,  even though its referenced in the SPKI WG's 
IETF docs (which require ceding of change control, etc)

Could someone from AT&T post a public-domain version, perhaps, as an I-D
to this WG?

Follow-Ups: