From: Dr. Joerg Haake (haake_at_darmstadt.gmd.de)
Date: Wed 11 Jun 1997 - 00:56:41 CDT
yes - I'm still alive and reading the mails of the OHS mailing list ;-)
Since collaboration was mentioned, I waked up :-)
I find the idea of grounding our decisions in more realistic scenarios very important, so here are my comments:
> Actually, I find that adding some context to Jorg's existing scenario makes
> it pertinent for this discussion. In Jorg's scenario, there are two
> collaborators, A and B. In this scenario, the collaborators are at
> different sites, but the network connections between them are not detailed.
> This scenario can be expanded into two cases:
> Case 1: Collaborators A and B are using OHP technology at different sites
> behind the same firewall (for example, different facilities of the same
> Case 2: Collaborators A and B are using OHP technology at different sites
> not behind the same firewall (for example, two researchers from different
> institutions collaborating on a standards document, or two engineers from
> different companies working on a cross-company project)
> However, having added some extra context to Jorg's scenario, I find we're
> still faced with the same questions: who do we see using OHP technology?
> What level of security and authentication should OHP provide?
> I think OHP should be robust enough to support collaborative activity
> across the Internet between collaborators from different organizations
> which are not behind the same firewall (Case 2 above). However, this then
> leads to a need for robust authentication technology, and for dealing with
> the security implications of sending executable content from an OHP server
> to an OHP client. Since this increases the complexity of making an OHP
> client and an OHP server, there needs to be a group decision on a) whether
> to support this use situation, b) to what degree this affects
> authentication and security.
> - Jim
I agree completely with Jim (and, of course, also Kai's remark about including minimal linking capability) that we need to include minimal (whatever that is) update mechanisms that require also some sort of security.
In our work, we largely omitted these issues when thinking about Case 1 (within firewall, one company, more trust, and providing access permissions grounded on within-company user accounts). So, the protocol would "just" need to provide hooks for integrating existing authentification mechanisms within the company's firewall.
However, in our work for the German government, we face all sorts of security problems/requirements. In a first step, we transformed our situation into a Case 1 problem by relying on the governments firewall and providing separate accounts/access rights. This seems to be acceptable within a ministery or even between ministeries sharing documents. However, if communication to external partners occurs, this changes. So, Case 2 needs to be addressed for the real world. (Sorry, I can't offer a solution here, but the problem is real).
Who should use OHP? From my point of view it is for developers building (cooperative) information systems that need to interoperate, and subsequently for the users of these clients/servers (who use the runtime environment).
Clearly, we can envision Case 1 usage situations, where security is low (and trust must be high). May be, write access can be limited to modify you own stuff and add/link/annotate to existing stuff (potentially limited by access rights, which requires authentification - too bad).
As a next class, we could provide Case 2 usage situations with an extended OHP that includes "more" security means (by exploiting some general services? as e.g. in CORBA?). THis one would be more heavy, but also more applicable.
This archive was generated by hypermail 2.1.5 : Tue 13 Aug 2002 - 07:20:51 CDT