[cap-talk] SAML assertions as capabilities vs. ocaps

Mark Miller erights at gmail.com
Wed Apr 23 22:09:36 CDT 2008


On Wed, Apr 23, 2008 at 5:26 PM, Karp, Alan H <alan.karp at hp.com> wrote:
> The Navy folks I'm working with frequently come back to some features of
SAML authorizations that they like, particularly having the full delegation
chain in the certificate and the fact that an attenuating delegation doesn't
needing prior planning.  Both of these features are implementable with
ocaps, but perhaps not as conveniently.

To do arbitrary attenuation without prior planning always requires either
extra communication or mobile code. For example, given an int-slot defined
by

def makeIntSlot(var value :int) {
   def intSlot {
       to get() :int { return value }
       to put(newValue :int) { value := newValue }
   }
   return intSlot
}
(Never mind that E provides a more straightforward way to reify an
int-slot.)

a silly attenuation would only allow the slot to be updated with a prime
larger than its current value

def makeSillyAttenuator(intSlot) {
   def sillyAttenuator {
       to get() :int { return intSlot.get() }
       to put(newValue :int) {
           if (isPrime(newValue) && newValue > intSlot.get()) {
               intSlot.put(newValue)
           } else {
               throw "oops"
           }
       }
   }
   return sillyAttenuator
}

How would you do this with SAML, without prior planning?


>  That leads me to make a challenge.  Find the best way to implement these
features purely with ocaps.  I'll accept an intravat solution as long as the
intervat version is reasonable.  For example, a forwarder can be used to
attentuate an ocap, but some extra communication is involved.

An attenuator that allowed only primes, or only primes larger than some past
value would be implementable as a remote forwarder at the cost of extra
communication. Just to make your challenge juicier, I defined a silly
attenuation that requires an atomic read-test-write without prior planning
for such atomicity. This can only be implemented with mobile code.


>  Is there an intervat solution that doesn't require extra intervat
messages?  Minimizing messages is of particular interest to the Navy.
>

   # ... define the above makeSillyAttenuator as pass-by-copy or pbc

   def p := where (distIntSlot) -> {
       makeSillyAttenuator(distIntSlot)
   }

This uses the hypothetical "where" construct previously discussed on e-lang,
which would mean something like

   def [p, pR] := Ref.promise()
   distIntSlot <- __whenResolved(def mobileReactor implements pbc {
       to __optUncall() {
           return [__eval, "run", [meta(mobileReactor).getScript(),
                                   meta(mobileReactor).getEnvironment()]]
       }
       to run(localIntSlot) {
           pR.resolve(makeSillyAttenuator(localIntSlot)
       }
   }

In other words, "where", like "when", evaluates the body-expression to the
right of the "->" at most once, and only after the where-arguments are
resolved, so any appearance of these arguments within the body-expression
will be resolved references. The body-expression is to be evaluated in its
own separate turn. The where-expression immediately returns a promise for
the value that the body-expression will evaluate to.

In addition, the where-body-expression is to be evaluated where the
where-arguments are located, so any appearance of these arguments within the
where-body-expression will be near references.

There's a security problem with the simple "where" notation above that has
previously been discussed on e-lang: The sugar obscures the fact that a
potentially mistrusted remote machine is being given access to the values of
all variables used freely within the where-body-expression. But the
unsugared form above is adequate for the present discussion.

-- 
Text by me above is hereby placed in the public domain

Cheers,
--MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eros-os.org/pipermail/cap-talk/attachments/20080423/97c2a65b/attachment.html 


More information about the cap-talk mailing list