This is where we differ. You are talking about "an identity" like it is
an object. I see identity as being *all* the things about me.
So when your password changes or your home phone number changes, it results in a
different identity? I don't understand this paradigm.
What you call identity above, I would call an identifier.
ok.
<< 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 >>
I was not involved, but HTTP did not need to define an object in order
to be able to move things around.
Protocols move data objects of some sort. No objects, no protocol.
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.
If all we are doing is solving SSO with DIX, then we might as well stop
now!
Identity is *so* much more then username and password -- although not
having to have a different username and password for each site is
*nice*, it is not all that compelling for sites to adopt. That is a user
issue. Making it easy for users to give sites data is compelling.
The web took off because it was browsable. You did not need to type
stuff in. Automating the movement of identity data is what DIX is about.
SSO is a small subset of that.
URLs can be typed in. Forms data can be typed in. A key click on a URL is a
bit of input that is shipped to the server.
The web was based on a particular usage goal. There was a very concrete problem
to solve. That it was able to do more than that original task was not an
accident, but it was not created as an exercise in abstract capabilities.
<< 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 >>
that is because we are not just doing SSO -- need a common language for
sites to make queries to get identity data
As I said, I was trying to formulate a concrete task. SSO was mentioned by one
of you folk so that's what I went with.
If the entire goal of the exercise is to create a standard that is highly
general but has no immediate customers trying to solve an immediate, concrete,
specific problem, you will find adoption a tad slow.
Glad you found it entertaining. The key point was that identity is
much more then a username and password.
or less.
if I change my password, I have not changed my identity. (Well, not
usually. I
did build an email service, once that used the password to ensure
uniqueness of
identity, but that was an anomoly is the design world, I think...)
we need to be using the same definition of identity for this
conversation to make sense :)
yup. as I recall, that was a basic point to my early (and continuing) postings
on this lists.
d/
--
Dave Crocker
Brandenburg InternetWorking
<http://bbiw.net>
_______________________________________________
dix mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/dix
