I have a question on the scope of DIX. I have read the current draft and the use cases and it seems to be inline with openid / lid approaches.
We have investigated the use of these protocols in some detail and one of the issues that seems to surface pretty quickly in real world scenarios is how one system can access another systems data acting as a proxy for a user. For example, I store my pictures on flickr and make some of these pictures "private" (only I can see them). I now want to use the printing services offered by http://www.qoop.com/ to access my flickr pictures. How does qoop authenticate with the flickr back end service to get to my private pictures and how does it state that it is acting on my behalf. I just wonder whether this is a use case you are considering for the core specification. Thanks, Rob p.s. in case I lost you in my scenario, see "proxy authentication" http://www.ja-sig.org/products/cas/overview/proxy_auth/index.html in JA-SIG's Central Authentication System (CAS) http://www.ja-sig.org/products/cas/index.html. p.p.s. Are any CAS developers participating in this working group? p.p.p.s. I notice that the current specification is relying on HMAC, has there been any consideration to a ticket based approach like the one outlined in CAS. Similar approaches seem to be pretty widespread http://dystopics.dump.be/2006/02/04/the-mysteries-of-x-google-token-and-why-it-matters/ and it could be argued that CAS is more lightweight than openid / lid / dix, it doesn't get much simpler than this http://www.ja-sig.org/products/cas/overview/cas1_architecture/index.html. _______________________________________________ dix mailing list [email protected] https://www1.ietf.org/mailman/listinfo/dix
