Subject: Re: SAML and REST - was Re: [dix] DIX use cases

From: Robert Yates <[email-masked]>
Date: Thu, 23 Mar 2006 15:23:33 -0500

Suresh Venkatraman wrote:

> Disagree - DIX should work with any HTTP/1.1 UA, not just a browser. 
> Is there a dependency on processing HTML in DIX?
>
>  
>
> ------------------------------------------------------------------------
>
>  
>
> No!  I think the intended scope of DIX is to work within the existing 
> HTTP capabilities.  In fact, DIX is intended to work in an 
> HTML/browser environment, rather than in non-HTML applications such as 
> WEBDAV or even browser-based AJAX schemes.
>
>
I also disagree. DIX needs to work with non browser clients.  I'll post 
my original use cases and restate my claim that core DIX needs to be 
able to handle 1-4 and that 5 needs to be a natural extension to the core.

1. Eliot's dad wants to remember one userid and password for the web.
2. Eliot's dad wants to stop retyping his credit card information and 
shipping address every time he wants to buy something on the web
3. Eliot's dad wants to share his online pictures with me and Eliot (and 
only me and Eliot)
4. I want to subscribe to Eliot's dad's photocast so that as new photos 
become available they are automatically downloaded to my machine. 
http://www.apple.com/ilife/iphoto/features/photocasting.html
5. I want to print Eliot's dad's photos using a web photo printing 
website.  The web site that I use to print the photos is different to 
the one that stores the photos.

Use cases 4 and 5 imply a non browser based HTTP/1.1 client. In 4 it is 
iPhoto, but it could be any Feedreader and in 5 it is a non-SOAP based 
api call from the photo printing service to photo storage service to 
retrieve the photos.

Rob

_______________________________________________
dix mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dix

---

From: Eliot Lear <[email-masked]>
Date: Sun, 26 Mar 2006 02:12:18 -0600

> 1. Eliot's dad wants to remember one userid and password for the web.
He also wants to use the same mechanism for IMAP a/o POP, SMTP to his
MSA, and calendaring.  As a stretch goal he may want to use the same
mechanism to authenticate through on 802.1x, but I would admit that this
could prove challenging.

Now, for those who weren't in the SAAG meeting there was a very good
presentation on a registration protocol that is very close to being
properly abstracted (CK-TIP?).  They already have text for HTTP.  Really
good stuff.  The callouts that are good for registration should be even
more easily adopted for just normal authentication.  Definitely related
work.

Eliot

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 27 Mar 2006 18:38:31 -0600

> mechanism to authenticate through on 802.1x, but I would admit that this

There was a BoF at Paris, but insufficient bodies to do the proposed
work then, for a Generally Useful Authentication Mechanism (GUAM)
framework so that we could end up with a suite of mechanisms for EAP,
SASL and the GSS-API.

There is now an I-D (draft-salowey-guam-mech-00.txt) for GUAM.  And more
work will follow.

This combined with some additional HTTP authentication using the GSS-API
(beyond what Negotiate can do) and the new SASL/GSS-API bridge
(draft-josefsson-sasl-gs2-00.txt), improvements in digest mechanisms,
and applying GUAM principles to any remaining populate mechanisms should
go a long way to meeting this requirement.

Coroporate networks tend to use lots of these protocols and plenty of
browser-based applications too.  Which is why I would insist on any
solutions in this problem space at the very least not preclude being
extended to work in non-browser contexts.  But I think such a
requirement wouldn't be difficult to meet.

Nico
--

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 28 Mar 2006 01:47:07 -0600

Hi Nico,

let me also point to the TLS Inner/Application draft here:
http://tools.ietf.org/wg/tls/draft-funk-tls-inner-application-extension-02.txt

It also tries to accomplish the goals mentioned below.

Ciao
Hannes

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 28 Mar 2006 13:57:17 -0600

> It also tries to accomplish the goals mentioned below.

You know, I'm a fan of this approach, but as I understand it there are
requirements we must meet in order to be deployable that this approach
doesn't address.  Specifically: support for proxies, and support for
proxies that want to see application protocol plaintext.

Nico
--