F2F input to bindings

[Anders Rundgren <anders.rundgren@telia.com>]

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" <anders.rundgren@telia.com>
To: "Mishra, Prateek" <pmishra@netegrity.com>; "OASIS SAML" <security-services@lists.oasis-open.org>
Cc: <security-bindings@lists.oasis-open.org>
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>