Shibboleth Developers

[Chad La Joie <>]

A comment I sent to Nate directly was

line 412: "<saml:Subject> element WITH EXACTLY ONE 
<saml:SubjectConfirmation>..." this is consistent with the wording in 
the other specs.  It's also necessary because of the SAML core rule that 
if any confirmation is acceptable than the whole assertion is okay.  So 
if people did include a bearer confirmation you'd lose everything you 
were trying to do.

My reason for that was that in SAML 2 code, lines 654 - 656, it states 
"If more than one subject confirmation is provided,  then satisfying any 
one of them is sufficient to confirm the subject for the purpose of 
applying the assertion."  So, if an IdP were to include Nate's described 
HoK confirmation *and* a bearer confirmation, so as to be compatible 
with both Nate's profile and the SAML WebSSO profile, then from a 
security standpoint this profile offers no additional security over bearer.

So, as Nate and I discussed, the real question comes down whether the 
ability to interoperate with the current profile is really necessary. 
My personal take is that if you're doing HoK you probably actually care 
that you are gaining the security benefits Nate has outlined in his 
profile.  I find the ability for an IdP to insert something like a 
bearer confirmation method in and basically silently destroy this added 
level of security, very disturbing.

So, my suggestion is that he not aim for interoperability with the 
WebSSO profile and allow people to use WebSSO when it's appropriate and 
HoK when it's appropriate.

Nate Klingenstein wrote:
> Round two!
>
> The feedback has been very useful.  I've made the following decisions 
> and changes in addition to the ones that I've already stated over the 
> weekend, factoring in feedback both on- and off-list.
>
> Added the following to the background to address Diego's concerns about 
> different TLS configuration/CA requirements and the impact on the user 
> experience.  "Deployments should minimize user interaction and avoid 
> mutually conflicting CA requirements by coordinating certificate 
> issuance and TLS configuration."
>
> Changed many references from "web browser" to "[HTTP] user agent".  This 
> should generalize the profile to encompass non-web-browser HTTP user 
> agents, but if I were to expand this to include any application-layer 
> protocol I think it would be too hopelessly broad, leaving little to 
> profile.  SOAP over HTTP already has good protocols and profiles to 
> choose from.  I retained the name "Web Browser" and the associated 
> identifying URN for consistency with the existing profile, but I'm not 
> certain that's best.
>
> Hope you guys like it,
> Nate.

--
SWITCH
Serving Swiss Universities
--------------------------
Chad La Joie, Software Engineer, Security
Werdstrasse 2, P.O. Box, 8021 Zürich, Switzerland
phone +41 44 268 15 75, fax +41 44 268 15 68
,
 http://www.switch.ch