Re: draft-sstc-bindings-05

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

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