[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Constructor v. Trivial Confinment
From: |
Marcus Brinkmann |
Subject: |
Re: Constructor v. Trivial Confinment |
Date: |
Mon, 01 May 2006 20:01:52 +0200 |
User-agent: |
Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (Sanjō) APEL/10.6 Emacs/21.4 (i486-pc-linux-gnu) MULE/5.0 (SAKAKI) |
At Mon, 01 May 2006 13:57:20 -0400,
"Jonathan S. Shapiro" <address@hidden> wrote:
>
> Marcus:
>
> This mechanism that you are describing is extremely important, and I am
> not able to understand it clearly from your description below. Could you
> please expand?
>
> From your description, it sounds as if S is a universal identification
> service. This worries me greatly.
>
> I think my confusion is in your last two sentences. You wrote:
>
> > It can invoke an operation on S to check if T is a capability
> > implemented by S. This identifies the server implementing T as
> > the server Z.
>
> If T is a capability implemented by S, how can the server implementing T
> be Z? Can you clarify this? Is the identity server separate from the
> server that implements the object? If so, this seems unnecessary and
> also prone to denial of resource attacks.
Sorry, that was a typo. It should be "Z" in both cases (S is a
capability, not a server). There is no identity server.
Let me state it much clearer:
A server Z that wants to provide an identification mechanism
implements an object S that provides the following interface:
bool identify (S, T)
Returns true if and only if allegedly T is implemented by Z.
However, note that Z may lie. This is intentional, because it allows
for a limited but useful application of proxying/virtualization.
Thanks,
Marcus