[ga-full] Re: [ga] Registration process suggestion

[Mark Measday <measday@ibm.net>]

The authentication between user and email address should be a matter of concern
also..

In the civil services of the world and many of the businesses, a document is
written for signature, not for identity, by qualified people, whose names do
not appear. The name of their titular head appears. This may apply also to
email and other forms of electronic communication..

So the concept of identity Dave assumes is not necessarily operative once you
get into political, diplomatic or business circles. However, in scientific,
artistic or social areas, the concept of identity is primordial. There's just
no point in talking to the wrong person.

If you receive a letter from someone at the US PTO, it is representative of the
view of the organisation. If you receive an email from that same person, it may
or may not be representative of that organisation, the convention has not been
wholly established. If you receive an email from someone at the Japanese MITI,
it has been authorised.

One can only hope that the remaining dnso ga subscribers can benefit from any
breakthroughs to resolve this ambiguity through the innovative group
intellectual property scheme being set up by the estimable Mr Gaetano and his
advisers.

Dave Crocker wrote:

> This has been a fascinating thread to read.  Pretty much everything people
> have been saying sounds correct and reasonable.  The only problem is that
> it is irrelevant to any near-term GA activity, since the technical
> solutions being proposed are not viable.
>
> As noted, the spoofing problem is theoretically amenable to a localized
> technical solution.  The GA provides its own cert authority for just (and
> only) this use. Typical objections to use of CAs do not apply in this case,
> because the activity is sufficiently small scale and small scope.  (Not too
> many participants, and the certs are used in a very constrained way.)
>
> The problem of ballot-stuffing by creation of multiple persona can only be
> solved by something that constrains the creation of those persona.  In the
> current environment, a persona is defined by an email address and, as we've
> seen, some people DO multiply themselves by getting any number of email
> addresses.
>
> Although the formal cert developers understand the issue of certs needing
> to be defined carefully, so that different criteria are applied in
> assigning different kinds of certs, there is no large scale use of certs as
> a basis for distinguishing individuals.
>
> For that matter, there is no large scale use of certs.
>
> For that matter, there is no large scale use of open, encrypton-based
> authentication services.
>
> And that's the problem.  All of this technology-iriented discussion, for
> solving the registration problem, is being conducted without attending to
> the raw fact that the technology has not already been deployed and used on
> very wide scale.  Hence considering it here is pursuit of a legal/technical
> experiement in an environment that is quite awful for experimentation.
>
> PGP advocates might disagree about large scale authentication activities,
> but that is an example of the problem, rather than a counter to it.  Both
> PGP and S/Mime are still human factors problems for average users.
>
> I'd love to offer a viable solution, but at this point only a human in the
> loop seems feasible.
>
> d/
>
> =-=-=-=-=
> Dave Crocker  <dcrocker@brandenburg.com>
> Brandenburg Consulting  <www.brandenburg.com>
> Tel: +1.408.246.8253,  Fax: +1.408.273.6464
> 675 Spruce Drive,  Sunnyvale, CA 94086 USA
>
> Gong Xi Fa Cai   /  Selamat Tahun Baru Cina
>
> --
> This message was passed to you via the ga@dnso.org list.
> Send mail to majordomo@dnso.org to unsubscribe
> ("unsubscribe ga" in the body of the message).
> Archives at http://www.dnso.org/archives.html



--
This message was passed to you via the ga-full@dnso.org list.
Send mail to majordomo@dnso.org to unsubscribe
("unsubscribe ga-full" in the body of the message).
Archives at http://www.dnso.org/archives.html