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

[Anthony Nadalin <drsecure@us.ibm.com>]

Frederick,

I assume the goal of your proposal is to have a client (application) to be able to store/retrieve knowledge of the user's IdP and use that knowledge to find the IdP.

The LEC protocol can be generalized in several ways. For instance, the protocol can be based entirely on web services if the client and the service provider also interact via SOAP. Or it can be based entirely on classical Internet standards if the client and the identity provider also interact via HTTP. If its the former then we need to role this into a basic SOAP profile, of latter then we need to role this into the a POST profile

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?

Here are some comments and issues

(1) The document is hard to read mostly because of all the Liberty references, its hard to tell if your talking about Liberty or SAML.
(2) Lines 107-113: What about SOAP 1.2 support ?
(3) Lines 119-155: These seem like assumptions not requirements (as in requirements that drove the specification)
(4) Line 146: Need to define "circle of trust" in context of SAML
(5) Line 151: Is this limited to X509 Tokens only ?
(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
(7) Line 177: What about versioning of the profile via URL ?
(8) Line 178: Seems that this should just be a versioned attribute (metadata) provided by the client
(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
(10)Line 231: Is this saying that the SP vouches for the entities in the list, why aren't these attributes ?
(11) Line 253: I assume that you are versioning the via the URL but not clear ?
(12) Line 295: and other places, it states that only one element must be returned it does not state were multiples may be returned. This also assumes that intermediaries understand LECP which may not be the case.
(13) Line 301: Here we have to assume that all other current and future Liberty profiles using the same token types do not leak tokens to parties other than U and SP, because we do not see any measure preventing exactly the same token from also occurring in a different profile.
(14) Line 393: I assume this is only for active Liberty intermediaries not SOAP intermediaries

Anthony Nadalin | work 512.436.9568 | cell 512.289.4122

frederick.hirsch@nokia.com wrote on 01/02/2004 09:35:00 AM:

> The document revision hirsch-sstc-lecp-draft-05.pdf has been
> submitted by Frederick Hirsch (frederick.hirsch@nokia.com) to the
> OASIS Security Services TC document repository.  
> This document is revision #1 of hirsch-sstc-lecp-draft-04.pdf.
>
> Document Description:
> Revised version of LECP enhanced client profile solution proposal
> for SAML 2.0, updated to ID-FF 1.2 Liberty contribution, changes to
> align with Oasis style and template. File name change to match convention
>
> Also uploaded diff pdf version, Open Office source and Open Office
> source for v4
>
> Download Document:  
> http://www.oasis-open.org/apps/org/workgroup/security/download.
> php/4641/hirsch-sstc-lecp-draft-05.pdf
>
> View Document Details:
> http://www.oasis-open.org/apps/org/workgroup/security/document.php?
> document_id=4641
>
> Revision:
> This document is revision #1 of hirsch-sstc-lecp-draft-04.pdf.  The
> document details page referenced above will show the complete revision history
>
>
> PLEASE NOTE:  If the above links do not work for you, your email application
> may be breaking the link into two pieces.  You may be able to copy and paste
> the entire link address into the address field of your web browser.
>
>
>
> To unsubscribe from this mailing list (and be removed from the
> roster of the OASIS TC), go to http://www.oasis-open.
> org/apps/org/workgroup/security-services/members/leave_workgroup.php.
>