On 19-Mar-06, at 8:46 AM, Robert Yates wrote:
Dick Hardt wrote:
great, but I just want to clarify a point. dmd1 today can move
around all this identity data. The reason that dmd1 doesn't yet
fulfill our requirements is that it moves it too late in this
process for it to be useful to us. We need the data moved the
moment that a space owner adds a new user to the space.
To echo John's comments, why do you need this?
When the space administrator adds a new member to the space, the
following things currently happen. Note that at this point in time
the new member is no where in sight.
1) The new member gets added to the access control for the space.
2) The new member is e-mailed with a welcome message and a link to
the space.
3) The new member's contact details e.g. phone number, e-mail
address, jabber id are available to other space members from the
space's membership list.
Note also that there are some space members that log into the space
extremely infrequently and with the advent of feeds some may never
log into the space via a browser. They're just "observers" of what
is taking place. However it is important that their contact
details be available to other members of the space.
Ok, I think I understand your use case.
Essentially you are saying that someone can be added to a space
without their permission? :-)
Seriously though, I'm sure there are situations where your use case
makes sense. In order to solve the other aspects of the identity
problem, I would expect that server to server communication would
currently be out of scope
I think to move the data as you describe, a tight coupling
between all parties is required.
Not sure why you think the coupling is any tighter than the
coupling between a homesite and membersite. We're just requesting
a set of user properties.
The site with the data MUST trust the site requesting the data. ie,
there is an existing relationship between them. In dmd1, the
membersite and homesite don't need to have any prior relationship,
and the user can use one homesite one day, and another another day
do you envision a future draft with the "lookup" capability? in
the use case, as described, the identity data is needed and the
user is not around to present it.
Would be interested in hearing use cases for where this is needed
where the user had not already been there.
see above. We want the user's properties to move when the space
admin adds them to the membership list, so we can send them an e-
mail, and so that their contact details are available to others.
This is how the products work today, the difference is that today
all the members are in the corporate LDAP and so the application
just "pulls" the data from there.
Sounds like LDAP is a solution now. Why not keep using it?
The Homesite is the users agent for managing their data. Liberty
deployments typically combine the identifier authentication and
property assertion operations. DIX is wanting to separate those
so that you can provide third party claims from many
authoritative sites in a single request, and that the Homesite
does NOT need to be trusted.
ie. AT&T may claim that my persona has a phone number, VeriSign
that I have a specific email address, and Air Canada that I am
Star Alliance Gold. Company X needs to trust AT&T, VeriSign and
Star Alliance -- but not my Homesite.
k, sorry, have been slow at grasping this fact (as demonstrated by
an earlier posting of mine), thanks for the explanation.
Rob
p.s. I notice this statement in the DIX charter.
"The end-user should have control over their identity information
and always be providing consent for the exchange of any of their
information."
I just wonder whether this holds true in the corporation to
corporation use cases. In these instances it is the end-user's
corporation that provides consent for the exchange of their
employee's identity information. I think this is an important
distinction from the consumer space.
I agree there are differences. I have found this useful discussion.
-- Dick
_______________________________________________
dix mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/dix
