On 21-Feb-06, at 6:14 AM, rob yates wrote:
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.
I like the term 'agency' for this scenario.
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.
In your example 'qoop' is acting as an agent on your behalf. How
does qoop get access to your data stored at flickr without being
you?
I do not believe this is in scope for DIX, but I think that DIX should
enable this at a lower level. A solution to the problem is for the
user to provide the agent with a token that allows them access
to the data (the photo).
Using dmd0: User instructs Agent (qoop) to perform action (print
photo), Agent requests token (dmd0 fetch), Homesite doesn't
have token so refers user to token generator (flickr), User
authenticates and receives token, which they store at their
Homesite (dmd0 store), User returns to Agent, Agent requests
token (dmd0 fetch), Homesite provides Agent with token, Agent
makes call on data source (flickr) with token as parameter.
Out of Scope:
Token definition. [There are many existing token definitions,
e.g. SAML]
Tokens in Web Services calls. (REST, SOAP, etc) [Could be
WS-*, or at HTTP layer.]
I just wonder whether this is a use case you are considering for the
core specification.
Not for the 'core', but certainly could be layered on top, or
extended. This is something we've been thinking about at
Sxip, and will present here, or in wherever forum seems most
appropriate, if there's demand for it.
John
_______________________________________________
dix mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/dix
