Re: ACL Draft

Paul,

> To stop a possibly long debate -- yes, we need to agree on what
> principal names are. I didn't mean to imply differently.  I just said
> that we shouldn't do so in the ACL draft, but rather in an
> authentication draft. It is an issue of separation of concerns. The form
> of principal names and how a user or server proves that they are
> identified by a particular principal name is just totally orthogonal to
> the question of the ACL draft (as long as principal  name can be encoded
> as a string).

I'm trying to make a distinction between the credentials exchanged during an
authentication process, and how the specification of a principal within an
ACE on the wire references a user identity.  I don't believe these need to
be the same, or even the same form.

In my view, a principal specification in an ACE on the wire should be an
extensible description of a set of principals.  The form of the description
ought to be included in the access control protocol specification, and it
should allow expressions such as:

  user=<principal identifier for Ringo> AND dns=*.old-drummers.org
or
  group=<principal identifier for Beatles> OR dns!=*.foo.com

(modulo the group consensus on a reasonable syntax).  The mechanism can be
arbitrarily extended by defining more attributes (e.g. "user", "group",
"dns", "ip") that can be used in the expressions.  I'd hope that the access
control protocol specification would require that a set of the most common
attributes be supported.

The form of <principal identifier for Ringo> may actually be opaque, but it
should be canonical, i.e. anywhere that Ringo is identified in the access
control protocol (ACEs, resource owner, lock owner), the exact same
<principal identifier for Ringo> must be used.  And it would be good if
there were operations to:

  fetch a principal identifier for the currently authenticated user
  fetch other properties (to be defined) of an entity referenced by a given
principal identifier, including at least a descriptive name to display in
the client UI

The terminology is part of the confusion, I think.  I'd suggest that
"principal identifier" be used to mean a canonical reference to a user or
group object that is accessible to the server at least, but also possibly to
the client as well.  Conceptually, any authentication mechanism maps
authentication credentials to a user (or perhaps group) object, and once
that is done, the corresponding principal identifier can be retrieved from
the object, or constructed by using information in the object.  (In the case
of certificate-based authentication, the client certificate might actually
be the user object.)

The descriptive form which I called "a principal specification in an ACE on
the wire" and gave examples of above, needs a term to describe it that does
not use "principal".  Generally speaking, it is a conditional expression
that determines under what conditions the ACE which contains it applies,
that is, under what conditions the policy of granting or denying rights as
specified in the ACE will be effective.  (Subject to the mechanism for
resolving conflicting policies in different ACEs.)  I'd suggest that
something like "ACE conditions" or "ACE conditional" be used to refer to
this concept.

> Futhermore, I don't want to be inventing authentication protocols in
> this WG -- there are other WGs for that purpose, and I want to rely on
> them.

I completely agree.

> So, I'd be happy to say in the draft that (e.g.) Kerberos
> principal names (RFC 1510) are one way to specify principals -- and in
> the ACL draft, or some other DAV draft, we can say what the "mandatory
> to implement" authentication protocols are in order to insure DAV
> interoperability at all layers of the stack.

I'd be happy to leave authentication mechanisms completely out of DAV, but
I'd also have no objection to DAV requiring support for one or a few
authentication mechanisms on which we can reach consensus.

That being said, I'm waiting until we reach some kind of closure on the
"principal" issue to bring up the topic of "lazy authentication" (or perhaps
"dynamic authentication"), which concerns not how authentication is done,
but when.

Howard