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