RE: [security-services] List of possible implementation features for SAML 2.0

["Mishra, Prateek" <pmishra@netegrity.com>]

John, this was discussed at the F2F and I am reasonably comfortable with the
current state of the binding. I don't think it needs to be exposed at the
conformance level, it is not really a choice point for implementers (maybe
for deployers). 

I have been concerned about the issue of burying a number of choices within
bindings and the implementation cost of the same. However, in this case, I
understand that the implementation cost is modest: you have a single
"artifact consumer" URL which either finds the artifact on the URL line or
in the POST body. Using POST for artifact delivery mitigates the "referrer"
issue identified by Thomas Gross.

In fact, here is a different position altogether: remove the GET part
completely and retain only the POST delivery method. This limits the
implementations to just one form and avoids the "referrer" issue.

Comments? 

-----Original Message-----
From: Scott Cantor [mailto:cantor.2@osu.edu] 
Sent: Wednesday, June 30, 2004 6:17 PM
To: 'John Hughes'; Mishra, Prateek
Cc: security-services@lists.oasis-open.org
Subject: RE: [security-services] List of possible implementation features
for SAML 2.0

> this may add perhaps too much detail - but do you want to capture the fact
> that the HTTP Artifact binding can use HTML forms or URL encoding to
> transport the artifact (albeit that conformant implementation for this
> binding MUST implement both)

It was my hope we'd just bury that inside the binding and not have to call
it out in conformance. Given the choice between that and having to make
things even more complex there, I'd actually be in favor of just backing off
to GET.

I just think allowing POST is a good nod toward security without costing us
much in complexity.

-- Scott