Subject: RE: [dix] DIX use cases

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 22 Mar 2006 12:39:25 -0800

> From: Robert Yates [mailto:[email-masked]] 
> Jeff Hodges wrote:
> 
> > Robert Yates wrote:
> > >  SAML can only do Web Services
> >
> > Incorrect -- and where did that notion come from?
> >
> > The web browser SSO profile of SAML [1], employing either the SAML 
> > HTTP Redirect Binding or the HTTP POST Binding [2], are essentially 
> > RESTful, AFAIU.
> 
> agreed, but i think you may be quoting me out of context :).  
> What I'm trying to state is that SAML cannot be used with 
> non-browser REST based web services such as the atom 
> publishing protocol.

I don't know why that would be the case. I wrote the first draft of what
became the SAML assertion infrastructure before Microsoft wrote the first
draft of SOAP.

WS-* is certainly tied down to the Web Services framework. That is a
different design decision that has advanatges and disadvantages. WS-* is
architected as an active transport layer protocol, SAML is architected as
static data.

The advantage of the static mode is precisely that you are not tied to
transport unless you want to be.

REST is just a protocol architecture style. Fielding has a different
architectural style to Fristyk-Neilsen or Hallam-Baker. I don't see why the
idea of giving his style an acronym makes it more valid than any other or
creates an incompatibility. He sees an adantage to keeping to one consistent
style that he adopted in 1995 or so. Folk who care about these things can
probably see quite a lot of change in my style over the years. There is a
case to be made for both approaches.

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

---

From: Robert Yates <[email-masked]>
Date: Wed, 22 Mar 2006 16:39:42 -0500

>case to be made for both approaches.
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 Robots 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

---

From: [email-masked]
Date: Wed, 22 Mar 2006 20:32:55 -0500

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