Re: grrp-reqs-06, 3.2 Identification and Authentication [3]

[Andre Cormier <Andre.Cormier@viagenie.qc.ca>]

Eric Brunner-Williams in Portland Maine wrote:
> 
> 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.
To my knowledge this is not a big problem since SASL describes how to do
this and BEEP is using it. SASL = RFC 2222

As i understand it this is for Registrars authentication to the
registry. I do not see a problem with this requirement. If we don't have
a negociation mecanism, we are bound to change the protocol if we wish
to change the authentication method.

> 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