Subject: Identity terminology in 2222bis

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 01 Oct 2004 11:21:13 -0700

Historically, there was a bit of hand waving in regards
to identities.  In trying to nail down what identities
are involved in the SASL framework, where each identity
comes from and what are they used for, we ended up with
3 identities:
 - the "authentication identity" to refer to the
   identity associated with the users credentials,
 - the "requested identity" to refer to identity which
   the user requests to act as, and
 - "authorization identity" to refer to identity
   used by the server in making authorization decisions.
   (The latter being derived from by former two.)

However, we now face is that what we've historically
called an authorization identity is not the precise
identity used in making authorization decisions.

The amount of 2222bis editing to implement the WGLC
conclusion is actually minor in comparison to the
impact upon other documents, including most mechanism
specifications and application profiles.  If it was
only 2222bis, I'd be inclined to just bit the
bullet and make the terminology changes.  But given
the broader impact this terminology change would have,
we need to consider other approaches to resolving our
terminology woes.

In particular, I think this can be done by separating
how identities are used conceptually from how they
are used in practice and, in particular, their form.

Below is a 3.2 rewrite which, I think, demonstrates
how we can avoid the terminology problem.  I do think
other portions need work as well, but this should give
you reasonable idea of the approach I suggest we take.

Comments?

-- Kurt (as an individual contributor)

3.2 Identity Concepts

Conceptually, SASL framework involves two identities:
	1) an identity associated with the authentication
	credentials (termed the authentication identity), and
	2) an identity to act as (termed the authorization
	identity).

The client provides its credentials and, optionally, a
string representing the requested authorization identity
as part of the SASL exchange.  When this string is not
provided, the client is requesting to act as the identity
associated with the credentials (e.g., the user is
requesting to act as the authentication identity).

The server is responsible for verifying the user's
credentials and verifying that the user is able to
act as the authorization identity.  A SASL exchange
is successful if and only if both of these verifications
are successful.

While SASL mechanisms specify the form of credentials
used to authenticating users and SASL application
profiles specify the form of authorization identities
transferred as part of authentication exchange, the
precise form(s) of the authentication identities (used
within the server in its verifications, or otherwise)
and the precise form(s) of the authorization identities
(used in making authorization decisions, or otherwise) is
beyond the scope of the SASL and this specification.  In
some circumstances, the precise identity forms used
outside of the SASL exchange may be dictated by other
specifications.  For instance, the authorization policy
specification for an application protocol may dictate the
precise form that an authorization identity is to be
represented in the authorization policy.