Tony
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.
regards,
Frederick
Frederick Hirsch
Nokia
-----Original Message-----
From: ext Anthony Nadalin
[mailto:]
Sent: Thursday, February 05, 2004 11:55
PM
To:
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
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
https://www.projectliberty.org/specs/liberty-idff-bindings-profiles-v1.2.pdf.
(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
wrote on 01/02/2004 09:35:00 AM:
> The document revision
hirsch-sstc-lecp-draft-05.pdf has been
> submitted by Frederick Hirsch
() 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.
>
