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.
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.
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.
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.
_______________________________________________
dix mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/dix
