RE: [security-services] Groups - hirsch-sstc-lecp-draft-04.pdf uploaded

[Scott Cantor <cantor.2@osu.edu>]

>The authentication request and response formats might be slightly different
>from the formats defined by Liberty, e.g., original SAML, and similarly the
>envelopes might be slightly different. What, however, is the really
>distinguishing feature from other authentication and key-exchange
protocols?

I think the basic idea behind it is that while a LEC/P *could* potentially
be an active intermediary in terms of actively going and asking for
assertions and then sending them to an SP, it doesn't have to. The idea that
I always read into it was to let it fit into the more passive
browser-oriented framework that most of this stuff uses, but take advantage
of the IdP provisioning and some optimized message exchanges. Sort of a
middleground.

>(2) Lines 107-113: What about SOAP 1.2 support ?

I think I asked this generally. Is it done? Being used? Do we hand wave or
get serious and fully specify against it? Is that something we have time
for?

>(5) Line 151: Is this limited to X509 Tokens only ? 

This is a general issue that applies across most of the SAML work. I think
ID-FF tries to have the usual sort of "hand wavy" language that in theory
anything accepted by the providers is acceptable but we all know the
reality...

>(6) Line 155: I can't find the SOAP Binding for Liberty document. I assume
>that we would just use the WSS: SAML Token Profile and not have another
SAML
>SOAP binding, this can then solve the issues in #5 allowing different token
>types

Basically what that reference is talking about is the equivalent to the SAML
SOAP binding, which is about how to package SAML protocol messages in
SOAP/HTTP. It's in ID-FF Bindings and Profiles, and it's an attempt to copy
the SAML binding with some additional latitude. It is *not* at all related
to the SAML Token Profile. This is the old SOAP binding vs. SOAP profile
mess. The token profile says how to secure SOAP messages with SAML
assertions. The binding says how to send SAML messages in SOAP. Orthogonal
beasts.

>(9) Line 193: Issue here is that WS-Security should be used here to protect
>the message, this goes back to the issue around the use of a single SAML
SOAP
>binding as defined in WSS-TC

WSS does not define a SAML binding (in the SAML sense of that word) in any
way shape or form. Totally different concepts. I believe WSS should be an
option (but not a requirement) for authenticating SAML protocol messages.
And for many of us, TLS or straight XML signatures over the SAML object
remain common and simple options. New options shouldn't preclude or replace
the existing ones.

>(10)Line 231: Is this saying that the SP vouches for the entities in the
>list, why aren't these attributes ?

It's advisory since ultimately the the SP will get the assertion and would
reject it if untrusted. This just prevents a pointless rejection. They
aren't attributes because there's no assertion needed.

-- Scott