Mailing-List: contact river-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: river-dev@incubator.apache.org
Received-SPF: neutral (athena.apache.org: 209.147.113.130 is neither permitted
 nor denied by domain of mmcgrady@topiatechnology.com)
References: <4C9DB5BF.8090307@zeus.net.au>
 <201010051249.59529.michal.kleczek@xpro.biz> <4CAB06F7.60407@zeus.net.au>
 <201010051536.39779.michal.kleczek@xpro.biz>
In-Reply-To: <201010051536.39779.michal.kleczek@xpro.biz>
Mime-Version: 1.0 (iPhone Mail 8B117)
Content-Type: text/plain;
	charset=us-ascii
Message-Id: <28EAC322-3F6E-409D-8102-FE1F4F0705E6@topiatechnology.com>
Content-Transfer-Encoding: quoted-printable
From: Mike McGrady <mmcgrady@topiatechnology.com>
Subject: Re: Towards Internet Jini Services (trust)
Date: Tue, 5 Oct 2010 07:07:18 -0700
To: "river-dev@incubator.apache.org" <river-dev@incubator.apache.org>

Nice!

Sent from my iPhone

Michael McGrady
Principal investigator AF081_028 SBIR
Chief Architect
Topia Technology, Inc
Work 1.253.572.9712
Cel 1.253.720.3365

On Oct 5, 2010, at 6:36 AM, Michal Kleczek <michal.kleczek@xpro.biz> wrote:

> Looks like the real underlying issue in understanding is the definition of=
 the=20
> Jini Platform.
>=20
> How I see it is: the platform is the _minimal_ set of software that I need=
 to=20
> manually install on my computer to safely exchange objects (code + data) w=
ith=20
> other computers and run the code that constitutes those objects.
>=20
> Everything else should be implemented as a service (an object) that is run=
 on=20
> top of the platform - and should not be considered a part of the platform.=

> I would even say it should be discussed if discovery protocols and=20
> ServiceRegistrar definition are part of the platform.
>=20
> So what do we have now?
> JVM - necessary to have dynamic code downloading and permissions
> PreferredClassProvider and PreferredClassLoader - necessary to deal with=20=

> codebase issues
> IntegrityVerifier interface, httpmd url handler and HttpmdIntegrityVerifie=
r -=20
> necessary to make sure we download the right code to unmarshal an object (=
BTW=20
> - are there any fundamental security issues with having other=20
> UrlStreamHandlers and IntegrityVerifiers provided as services - similarly t=
o=20
> how OSGI does that?)
> TrustVerifier, ProxyTrust, RemoteMethodControl, Constraint, ProxyPreparer=20=

> interfaces and their basic implementations - necessary to verify unmarshal=
led=20
> objects
> various JERI endpoint implementations - necessary to be able to implement=20=

> ProxyTrust (BTW should unsecure endpoints like TcpEndpoint _really_ be par=
t of=20
> the platform?)
>=20
> As I see it - if we close the gap and solve the issue of possible DoS duri=
ng=20
> deserialization we have a complete platform to build everything else as=20=

> services on top of it.
> Even complicated trust decisions can be made by delegating to trusted=20
> services.
> We can quite easily build "sandbox" services (for example on top of Phoeni=
x)=20
> so that the client can choose not to download any code into it's own addre=
ss=20
> space.
>=20
> What am I missing?
>=20
> Michal
>=20
>=20
> On Tuesday 05 of October 2010 13:07:35 Peter Firmstone wrote:
>> Yes I think Sim is talking about making trust decisions and Michal and I
>> are talking about the handshake, we need both, I don't think we're
>> having an issue of agreement, just understanding.
>>=20
>> I'd like to see some kind of feedback service, where you give a good
>> rating when you get a good service and a bad one when you don't.  I'd
>> also like to see a security advisory service, for handling discovered
>> vulnerabilities.  These things might be useful in making trust decisions.=

>>=20
>> I'd also like some trust levels defined, with a wider range of
>> permissions as trust increases.  But I'd only like to grant the
>> intersection of the trust level Set of Permissions and the Set requested.=

>>=20
>> I'd like to see the level of trust others are granting to a service via
>> feedback services, if a service misbehaves and it's caught out, the
>> level of trust will diminish.
>>=20
>> Then we can go with the crowd, safety in numbers, like a school of fish,
>> just don't get caught in a bait ball.
>>=20
>> Cheers,
>>=20
>> Peter.
>>=20
>> Michal Kleczek wrote:
>>> Of course - I am not talking about the problem of deciding whether I
>>> should trust a particular service - this is a completely different
>>> subject and I am not really sure if we should even try to solve it since=

>>> I don't think it is possible to do without human intervention. In the
>>> end - choosing to trust and use gmail versus yahoo is not something that=

>>> can be done automatically.
>>>=20
>>> But checking whether an object (code + data) comes from the service I
>>> trust is something that can be done and is a prerequisite to the above
>>> anyway.
>>>=20
>>> Michal
>>>=20