To:
Andre.Cormier@viagenie.qc.ca
cc:
ietf-provreg@cafax.se
From:
Eric Brunner-Williams in Portland Maine <brunner@nic-naa.net>
Date:
Fri, 09 Feb 2001 19:01:21 -0500
Sender:
owner-ietf-provreg@cafax.se
Subject:
grrp-reqs-06, 3.2 Identification and Authentication [3]
Last December Andre Cormier (1) proposed added requirement [3], viz [3] The protocol or another layered protocol MUST provide services to negotiate an identification and authentication mechanism acceptable to both the server and the client. The requirement he's proposed is negociation between the server and the client as the precondition for subsequent transactions. My issue with this is that the scope of R-* policied data flows is larger than participant identification and authentication, which is distinct from negociation proposed concerning the duration of a particular registration, (and I suppose equivalent object-specific properties). As Richard Shockey noted (2), BEEP provides a negociation mechanism. Absent BEEP, this requirement places upon the provreg design group the participant policy negociation problem. The specific policy I've in mind (wearing my P3P Spec hat) is neither participant identification nor authentication, but participant data collection policies. I've proposed off-list that [1] and [2] be reworded to be symmetric, so they address server identification authentication. I propose that [3] be dropped, least we have the situation where we can negociate a means to identify and also authenticate any provreg participant, but can't negociate data collection policies. The real throw-hands-up-in-dispair is that after two years of effort, the P3P activity couldn't figure out how to negociate a fundamental, and I don't want provreg to pause-to-refresh while revisiting a problem appealing to generalist aesthetics and not present deployment schedules. Everyone wants to negociate, and we don't really have negociated policed flows anywhere in the internet architecture (corrections gladly paid for). Incidently, P3P has versioning. 1.0, ... Cheers, Eric (1) http://www.cafax.se/ietf-provreg/maillist/2000-12/msg00045.html (2) http://www.cafax.se/ietf-provreg/maillist/2000-12/msg00052.html