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?
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.
Given this fact, dmd1 is within sniffing distance of being able to
fulfill the use case that I have described previously. Our server could
issue a fetch request directly to the homesite url. The homesite could
check that the request is coming from a membersite with which an
existing relationship exists and hence immediately returns the form to
post. Although ugly and not an approach that I would advocate our
server can parse the form in the response from the homesite and get the
information that it requires.
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.
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. Securely proxying http requests is well
understood. Am not sure that the same can yet be said for ldap.
Rob
_______________________________________________
dix mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/dix
