On 27-Feb-06, at 1:46 PM, Dave Crocker wrote:
"who you are" is a reasonable place to begin, but does not have
quite enough substance to direct technical work. For example, the
difference between a person performing in one role, versus another,
might or might not require different identities. It might even
require some sort of identity "hierarchy".
I see that people will have many personas, but only one identity.
Each persona presents a different facet of themselves.
Yes, all of these issues have been discussed in specialized circles
for some decades.
The issue I am raising, here, is that the engineering work to be
pursued here needs to list specific choices for these things and
has to have community agreement on those choices.
Do we need to preclude what is and is not identity? ... if we have an
open mechanism for adding to the identity data that can be moved
around, we will have a platform for moving around any identity data.
In our ID, we intentionally left out describing the specifics of what
could be moved around, our goal was to provide a mechanism for any
organization to define properties that could be moved around and
defining them as URIs.
So, before there is any discussion of formats and protocol rules,
there needs to be an understanding of the capabilities and
constraints of the construct "identity" used for this work.
Philips related post I think covers this a little, and his comments
point out what I think is an important aspect of identity protocols.
There is an implicit and often overlooked aspect of identity, which
is the identity of session between machines. I use the term session
here quite broadly, I mean for it to be a way for one machine to know
that a message it receives is related to a previous message.
When we talk about identity, there are two aspects, one is the
property, and the other is who the property is about. Over 21 is
rather useless. The entity at the other end of a session being over
21 is useful. Let's call tying a property to an identifier a claim.
In this case, the identifier is the session. But the identifier could
be something else that has more permanence. Philip used [EMAIL PROTECTED]
as an example. [EMAIL PROTECTED] is over 21] is a claim that will be
true the rest of my life (as long as [EMAIL PROTECTED] is associated with
me :-)
This leads to me controlling who can say they are [EMAIL PROTECTED] If
only I can claim that the a session is associated with [EMAIL PROTECTED],
then I will be the only where the claim [EMAIL PROTECTED] is over 21] is
considered valid.
Does this clarify your question Dave, or am I missing something?
-- Dick
_______________________________________________
dix mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/dix
