OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

Some additional inline comment, in addition to what Scott and John already stated.

Note Tony that the latest revision is 5, so your comments are on an older revision.
Frederick Hirsch
-----Original Message-----
From: ext Anthony Nadalin [mailto:drsecure@us.ibm.com]
Sent: Thursday, February 05, 2004 11:55 PM
To: security-services@lists.oasis-open.org
Subject: Re: [security-services] Groups - hirsch-sstc-lecp-draft-04.pdf uploaded


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.

> Goal is to enable broader adoption and usability of many devices by providing a simple SAML profile for devices that know their IDP or know how to find it.

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

> No, we need a solicit-response pattern that doesn't fit either of these profiles

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? 

> This is not an authentication or key exchange protocol, in the sense that authentication to IDP is not defined in contribution

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. 

> As the accepted material is incorporated into the SAML 2.0 specifications it should become easier. 

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

> Generally, how SAML 2.0 will support SOAP 1.1 and 1.2 will need clarification.

(3) Lines 119-155: These seem like assumptions not requirements (as in requirements that drove the specification) 

 Perhaps we should call them constraints, e.g. #10 requires https

(4) Line 146: Need to define "circle of trust" in context of SAML 

> Agree, we should add the "circle of trust" definition to SAML 2.0

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

> Need to consider clarifying   use of WSS  X.509 tokens,   and tokens in general with SAML 

 (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 

 > ID-FF 1.2 Bindings and Profiles includes this info. See

(7) Line 177: What about versioning of the profile via URL ? 

 > Are you asking the convention that the URI  uses to convey versioning information?


 (8) Line 178: Seems that this should just be a versioned attribute (metadata) provided by the client  

> The headers provide runtime information on capabilities

(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 

 > Why? WSS:SOAP Message Security shouldn't always be required. Regardless WSS profiles should be composible with other SOAP profiles. What is the issue?

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

 > No, it says which IDPs  SP  will accept.   Don't understand why you are calling these attributes - attributes of which entity?   This is run time information . 

(11) Line 253: I assume that you are versioning the via the URL but not clear ? 

 > Yes
(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. 

> why return multiple AuthnResponses? How does this sense when requesting an authentication assertion from an IDP.  Since intermeidaries can ignore header blocks intended for the ultimate SOAP receiver, I don't understand this issue, especially since I don't know what intermediaries you are talking about. The contribution shows none.

(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. 

 > Are you saying AuthnResponseEnvelope  schema definition cannot be reused, why not? Maybe I do not understand questionl 

(14) Line 393: I assume this is only for active Liberty intermediaries not SOAP intermediaries

> Look at the accepted PAOS+LECP contribution

Anthony Nadalin | work 512.436.9568 | cell 512.289.4122

> Thank you for the review

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.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]