On Feb 27, 2006, at 10:51 PM, Dave Crocker wrote:
An identity is a globally unique reference to an
online user or agent. The
form
of the reference is a URI. <<There are some serious
dragons in a statement that
general, but they will hold their breath, for now.
/d>> Associated with an
identity is a collection of information that
describes characteristics of the
identity and/or privileges imparted to the
identity. The information
about an
identity can be divided into subsets, according to
the different functional
roles performed by the user or
agent.
This is very useful text. I'd be happy to see such text in a draft
introducing a particular identity system, but I think it's also appropriate
for the charter provided it doesn't contradict too many models. It does
pre-suppose some part of a solution but that may even be appropriate if we all
agree on that part of a solution even before chartering.
Is it helpful to also point out that it's expected that these identities
will come from different authorities that aren't required to coordinate with
one another in any way?
DIX is transaction mechanism for identity
information. <<obvious
questions:
you mean dix semantics cannot transit via
email? equally obvious
question: why
does this need a new transfer mechanism?
>>
Transport rather than transaction?
Suggested further text perhaps: "Currently, there is no standard,
interoperable way for a user to have some identity information transferred
from an identity authority to a third-party consumer of such
information."
<< Meta-suggestions: DIX should define an identity
object first, and make sure
it can be carried in multiple ways, unless there is
something special in the
semantics of the exchange mechanism. /d
>>
An initial application of DIX will be to permit
users to have a single step of
authenticating themselves to a DIX client and then
having that client be able to
perform other authentications, on behalf of the
user, to servers around the
Internet.
I think most people are thinking in terms of "users having a way to
authenticate themselves to a DIX identity authority (NOT a client) and having
that authority be able to vouch for their identity, oh behalf of the user, to
servers around the Internet."
That is the most common model I've seen, although it *also* presupposes
some aspects of a solution. For example, a solution where clients
generated one or more self-signed certificates, in addition to a possible set
of certs signed by other authorities, and selected from those to identify
themselves to servers around the internet -- would not quite fit that
description.
<< By the way, one problem with this example
is that it is not obvious what it
is that requires an interoperable standard, as
opposed to a common database and
agent on a single machine, as folks already
have. Where is the
requirement for
a distributed mechanism on the client side? /d >>
My last two paragraphs above may answer your question about what requires
an interoperable standard.
The presentation was entertaining. It contained at least one
statement of equivalence that I find unpersuasive from just its
assertion. The
equivalence of identity = reputation is a strong and
Wearing my email anti-abuse hat, I will certainly
claim that anything called
"reputation" is grotesquely relative. It is not even close to "the same
as" the
identity of the thing having the reputation.
(By way of example, for a few folks on this list,
there is a set of people among
whom I have a reputation of being patient and
kind. And, yes, they and the
IETF
community are perceiving the same identity... There is a reason I said
"grotesque".)
Reputation may be out of scope for an initial charter for DIX. I
would suggest that would be a wise choice for limiting the initial work as it
would not limit later work.
Lisa
