REPEATED: F2F input to bindings

The F2F #4 is over, but the issues remain.

Why not take a shot at this or do you have a problem with the
issues?  Or with me? :-) :-)

POST seems to finally (I proposed this in January...
http://lists.oasis-open.org/archives/security-services/200101/msg00007.html)
have landed at least.

If the issues are insignificant, please let me know why.

/a.r.

----- Original Message -----
From: "Anders Rundgren" <>
To: "OASIS SAML" <>; "Hallam-Baker, Phillip" <>; "Tim Moses"
<>; "Mishra, Prateek" <>; <>
Sent: Monday, August 27, 2001 10:40
Subject: F2F input to bindings


Hi Guys!

I would have loved to come to the F2F but can't make it.
I would though very much appreciate a comment at least on
point #2, #3 and #4 below as they are sort of fundamental.

Regarding #4: clock-sync independence is another thing that PUSH
[at least could] introduce.

I would like to see some more discussions on scaling, statefulness,
configuration, user-friendliness, ASP, and reliability issues.
All these factor are within SAML scope IMHO.

Anders

----- Original Message -----
From: "Anders Rundgren" <>
To: "Mishra, Prateek" <>; "OASIS SAML" <>
Cc: <>
Sent: Friday, August 24, 2001 11:47
Subject: Re: draft-sstc-bindings-05


Prateek et al,
Here are some comments to the bindings-05 draft browser profile(s).

1.
The initial GET used in all profiles specifies (by example) that
the query string contains TARGET etc. IMHO the initial GET
should not be restricted/specified in any way as it is an entirely
internal thing of the source site. I.e. GET could equally well point
to an URL with a local database index in the query string etc.
It could AFAIK equally well be a POSTed form (that we have
recently found out is GET-compatible with respect to redirects).

2.
An observation (for what it is worth):

- In PUSH the source-site is authenticated before the dest-site
- In PULL the dest-site is authenticated before the source-site
- In POSTed form only the source-site is authenticated

I sort of prefer the second *principle* as it is more in-line with
authentication in general and is a must for Shibboleth-like uses.

3.
The s.c. distinguished assertion consumer URL could without any
performance or security implications be fully dynamic in the PUSH
profile (to require source sites to configure *two* destination
URLs is IMO a bit over the edge).  In the same way,  PartnerIDs are
redundant for all profiles except for PULL.

4.
IMHO only the PUSH profile is user-friendly, as a broken URL
or rejected request will be detected first-hand by the user's own
site/server (possibly automatically alerting the IS-department,
and giving the user a nice/appropriate error-message), while the
other profiles leave the user with the problem.

5.
That POSTed forms implicate stateful destination-servers is IMHO
not absolutely necessary as there are workarounds:

-A short-lived assertion like 60 seconds, makes replay "possible"
but still "unlikely" to be performed by any other but the original user.

-A session-cookie should be able to hold the last assertions used
at a particular site to hamper replay.

Although replay protection is highly recommended, I still
wonder if it should be a MUST as this could be considered as
a policy-decision rather than a technical ditto.

Regards
Anders




----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>


----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>