On 19-Mar-06, at 5:44 PM, Robert Yates wrote:
Dick Hardt wrote:
Essentially you are saying that someone can be added to a space
without their permission? :-)
Yes :) there are a lot of similar use cases in the consumer space
that I think DIX needs to accommodate, e.g. in flickr I can share
photos with a limited set of contacts, in kodak gallery the same
thing. These sites all send the user an e-mail stating something
like "Rob has shared some photos with you, click here to access the
photos". I can imagine ways that this could work with dmd1, I
could type in the user's e-mail address and their persona-url, or
some secret in the mail message the user receives could be used
that allows the user to type in their persona-url and then the
service associates this e-mail with that persona-url. These
approaches however seem a little strained to me. Is there
something special about an e-mail address that needs to be better
reflected in future revisions of dmd1?
Not sure what you mean about something being special about the email.
Per my earlier email, providing the email as an identifier to
bootstrap a user account was something I envisioned would happen. All
other aspects about the user are provided by the user when they login
the first time.
btw: Funny you mention flickr having been the first outside investor
and board member ... they were on track to put in SXIP until Yahoo!
bought them.
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
Am not sure that I would describe an existing relationship as a
"tight coupling". How different is this to me instructing my
homesite that it can always release my credit card information to
amazon.com, and that it can do so without requiring me to confirm
its release. I have always been assuming that this is why the
membersite can optionally send its signature.
Currently, the membersite does not need to have any method of proving
who it is, which lowers the barrier to adoption.
If a WG is formed, and I wish you all the best of luck this week in
Dallas, then I think it worth exploring some options to see if
these use cases can be accommodated without placing a significant
burden on homesites. Given how close dmd1 is to meeting these
requirements we may surprise ourselves and find an easy solution. I
would not be too hasty in removing these use cases from scope.
I have heard from quite a few people that we need to keep a narrow
scope.
Sounds like LDAP is a solution now. Why not keep using it?
Is possible, but I don't think enterprises like placing their ldaps
on the public internet.
agreed
Securely proxying http requests is well understood. Am not sure
that the same can yet be said for ldap.
LDAP over TLS can be done.
For the same reasons why they don't want to put their LDAP servers
out there, I think you have the same issues around "pulling" data
using any other protocol.
-- Dick
_______________________________________________
dix mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/dix
