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
