Subject: [dix] scope question - proxy authentication and then some thoughts about ticket based approaches

From: "rob yates" <[email-masked]>
Date: Tue, 21 Feb 2006 09:14:53 -0500

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-masked]
https://www1.ietf.org/mailman/listinfo/dix

---

From: John Merrells <[email-masked]>
Date: Fri, 24 Feb 2006 11:13:16 -0800

On 21-Feb-06, at 6:14 AM, rob yates wrote:

> a proxy for a user.

I like the term 'agency' for this scenario.

> For example, I store my pictures on flickr and

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

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

---

From: Robert Yates <[email-masked]>
Date: Mon, 27 Feb 2006 15:44:32 -0500

John Merrells wrote:

> enable this at a lower level. 

Good to hear

> makes call on data source (flickr) with token as parameter.

Hmmm, this seems a little complicated to me at the moment..

I also wrote up the requirements for "proxy authentication" and called 
it "DIX Agency".  Am interested if others are seeing this use case and 
whether they feel that a draft should be created that extends DIX 
Protocol to provide these capabilities,

Rob

1.  Introduction 

  DIX Agency extends the DIX protocol [DIX].  It allows third party
  "agencies" to act on a user's behalf.  A trivial example is allowing
  a photo printing service to access photographs stored by a separate
  service.

2.  Definitions

  This document uses all the definitions outlined in [DIX] section 2
  and additionally adds the following.

2.1.  Servicesite

  A website or an application that provides services for end users.
  These services are available to other websites or applications via an
  API.

2.2.  Agencysite

  A website or an application that acts on behalf of a user when
  accessing the servicesite.

3.  Overview

  The core of DIX agency is a set of procedures for negotiating access
  to the servicesite by the agencysite.  Without drilling into too many
  details, this is a general description of the DIX Agency protocol.

  The User browses to an Agencysite.  The DIX Protocol is used to establish
  their "Persona URL" with the Agencysite.  The user initiates an
  action that requires the Agencysite to access the Servicesite.  The
  Agencysite determines that it is not authorized to access the
  Servicesite.  The Agencysite then sends a request for access to the
  Servicesite through the User's client.  The Servicesite processes the
  request (possibly also establishing the user's "Persona URL"),
  prompting the User for consent and returns a response, again through
  the User's client.  The Agencysite utilizes this response to access
  the Servicesite.