Subject: privacy, authentication, identification , authorization

From: [email-masked]
Date: Sat, 10 Apr 2004 17:34:40 -0600

basically somebody provides some authentication information, in
public/private key scenario ... a digital signature is generated by a
private key as part of a "something you have" authentication paradigm.

there could be some certification process where a hardware token is
involved (certifies the operation of specific hardware token analogous to
FIPS or common criteria, not as in a public key certificate issuing
institition), the hardware token is certified as generating (on-chip) a key
pair where the private key never leaves the chip. the hardware token could
also be certified as generating specific kinds of digital signature when
correct PIN or biometric is presented. with such a certificate
infrastructure .... the relying party might then have grounds to believe
that in addition to "something you have", there may bave been "something
you know" and/or "something you are" authentication. This wouldn't be a
shared-secret based operation .... but the relying-party could infer
"something you know" and/or "something you are" if it trusted the
certification process for the hardware token operation.

the relying-party then obtains a public-key and validates the digital
signature. the infrastructure for the public-key could be a database
(conforming to most existing business processes for authentication
material) or a certificate (in the PKI model).

the infrastructure typically has bound the public-key to some
identification, index, and/or authorization information. In the case of
identification or index, that information is frequently then used to lookup
some authorization information (i.e. specific identity is allowed to do
specific stuff). A trivial example is a generic employee certificate ...
all it contains is some generic employer information and the public key, if
the digital signature authenticates ... then it is known that the person is
some employee and is entitled to do whatever generic employees are entitled
to do.

the issue here is that there aren't a lot of business processes that
perform identification (or authentication) just for the sake of it (having
absolutely no other purpose)  .... the business process is performing the
operation as part of some additional activity. For instance, there aren't a
lot of identification  stores in malls, where you walk in
authenticate/identify ... and then walk out (with no other operation
occuring).

The early x.509 identity certificates tended to contain a lot of arbitrary
information that ran afoul of various pricacy issues. The result was
retrenching to relying-party-only certificates that contain an indication
or domain-specific index ... which was then used to index a database entry
that then provided the actual information needed for executing a business
process.

Putting in generic identity information or possibly institutional specific
identity and/or authorization information (like clearance levels) in a
public certificate (targeted for uncontrolled distribution) tends to
violate various privacy and/or institutional rules/policies.

just because some item of information is encapsulated in a public
certificate doesn't magically mitigate all rules and policies regarding the
handling of that information

--
Anne & Lynn Wheeler - http://www.garlic.com/~lynn/