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

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 22 Mar 2006 20:27:06 -0800

Lets forget about REST and concentrate on the BEST place.
 
The HTTP-Authorization field is the right place (and no I did not choose
that tag name and I objected at the time, they snuck it in along with BASIC
while I was suffering from food poisoning). I am responsible for the
imaginative spelling of Referer though. 

  _____  

From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, March 22, 2006 7:33 PM
To: [email-masked]
Subject: Re: SAML and REST - was Re: [dix] DIX use cases

It could go in the HTTP Authorization field using a new scheme to be
defined.
 
There seem to be several people interested in enhancing HTTP to allow data
like this to be provided for REST-style interactions.  This has parallels
with putting data in SOAP headers rather than in the content of the message.

Terry

-----Original Message-----
From: Robert Yates <[email-masked]>
To: Digital Identity Exchange <[email-masked]>
Sent: Wed, 22 Mar 2006 16:39:42 -0500
Subject: SAML and REST - was Re: [dix] DIX use cases

so I admit that I am confused and probably out of my depth, and I know
better than to argue with the initial spec author that it can't be done. 
 
but I simply don't understand what it means to use SAML with something like
atompub
http://www.ietf.org/internet-drafts/draft-ietf-atompub-protocol-08.txt or
any of the plethora of so-called REST based web services. 
 
Here is an ATOM post. 
 
POST /myblog/entries HTTP/1.1 
  Host: example.org 
  User-Agent: Thingio/1.0 
  Content-Type: application/atom+xml 
  Content-Length: nnn 
 
  <entry xmlns="http://www.w3.org/2005/Atom"> 
  <title>Atom-Powered Ro bots Run Amok</title> 
  <id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id> 
  <updated>2003-12-13T18:30:02Z</updated> 
  <content>Some text.</content> 
  </entry> 
 
Where does the SAML go? I apologize for my lack of understanding here. 
 
Rob 
 
_______________________________________________ 
dix mailing list 
[email-masked] <mailto:dix%40ietf.org>  
https://www1.ietf.org/mailman/listinfo/dix 

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

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 22 Mar 2006 22:35:39 -0600

Do we really need to change HTTP for DIX?

Gruesse, Carsten

---

From: [email-masked]
Date: Thu, 23 Mar 2006 14:50:14 -0500

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'd like to discuss changes to HTTP somewhere, but probably not on the DIX list.
 
Terry
 
-----Original Message-----
From: Carsten Bormann <[email-masked]>
To: Digital Identity Exchange <[email-masked]>
Sent: Wed, 22 Mar 2006 22:35:39 -0600
Subject: Re: SAML and REST - was Re: [dix] DIX use cases

Gruesse, Carsten

---

From: [email-masked]
Date: Thu, 23 Mar 2006 14:52:57 -0500

I agree.  We should probably drop the discussion of REST and HTTP-Authorization on this list and focus on the browser-based HTML requirements.
 
(I'm not sure what Phill is hinted at as far as BEST goes!)

Terry
 
-----Original Message-----
From: Hallam-Baker, Phillip <[email-masked]>
To: Digital Identity Exchange <[email-masked]>
Sent: Wed, 22 Mar 2006 20:27:06 -0800
Subject: RE: SAML and REST - was Re: [dix] DIX use cases

The HTTP-Authorization field is the right place (and no I did not choose that tag name and I objected at the time, they snuck it in along with BASIC while I was suffering from food poisoning). I am responsible for the imaginative spelling of Referer though. 

 
It could go in the HTTP Authorization field using a new scheme to be defined.
 
There seem to be several people interested in enhancing HTTP to allow data like this to be provided for REST-style interactions.  This has parallels with putting data in SOAP headers rather than in the content of the message.

Terry

-----Original Message-----
From: Robert Yates <[email-masked]>
To: Digital Identity Exchange <[email-masked]>
Sent: Wed, 22 Mar 2006 16:39:42 -0500
Subject: SAML and REST - was Re: [dix] DIX use cases

so I admit that I am confused and probably out of my depth, and I know better than to argue with the initial spec author that it can't be done. 
 
but I simply don't understand what it means to use SAML with something like atompub http://www.ietf.org/internet-drafts/draft-ietf-atompub-protocol-08.txt or any of the plethora of so-called REST based web services. 
 
Here is an ATOM post. 

 
 
Rob

---

From: "Suresh Venkatraman" <[email-masked]>
Date: Thu, 23 Mar 2006 12:04:54 -0800

Disagree - DIX should work with any HTTP/1.1 UA, not just a browser. Is
there a dependency on processing HTML in DIX?

  _____  

From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, March 23, 2006 11:50 AM
To: [email-masked]
Subject: Re: SAML and REST - was Re: [dix] DIX use cases

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'd like to discuss changes to HTTP somewhere, but probably not on the DIX
list.

Terry

-----Original Message-----
From: Carsten Bormann <[email-masked]>
To: Digital Identity Exchange <[email-masked]>
Sent: Wed, 22 Mar 2006 22:35:39 -0600
Subject: Re: SAML and REST - was Re: [dix] DIX use cases

Gruesse, Carsten

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 23 Mar 2006 14:25:57 -0600

On Thu, Mar 23, 2006 at 02:50:14PM -0500, [email-masked] wrote:
Carsten> Do we really need to change HTTP for 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.

Which, given the complaints we've seen about SAML not catering to REST
applications (+ counter arguments that either it's very close or could
easily be profiled to cater to them also) one wonders: why should DIX be
so limited?

I'm not interested in furthering the divide between browser and
non-browser based applications, unless there's a very clear way forward
to address that gap (including no conflicts with DIX/SAML/YADIS/...).

> I'd like to discuss changes to HTTP somewhere, but probably not on the DIX list.

Well, OK, there are fora for that, but whether it should be discussed
here depends on what sorts of changes we'd be talking about and how
closely related to DIX they would be.  Though it certainly seems too
soon -- the problem statement alone needs plenty of work...

Nico
--