Hi Pim Your first comment is probably due to my fault :( I had put in the names when requesting the template from the TC admin. I believe Ian just used that. ~Makesh On 7/30/13 6:21 AM, "Pim van der Eijk" <
pvde@sonnenglanz.net> wrote: > >Hello Ian, > >Some comments on the draft: > >Page 1, you include all voting members as editors, but >right now you're the editor and we're just reviewers. >The rest of are mentioned in Appendix A. > >Page 1, related work, you mention WS-Security 1.0 and 1.1. >Do you want to reference both versions or is the latest one >sufficient? >Should you not reference the most recent one >
http://docs.oasis-open.org/wss-m/wss/v1.1.1/os/wss-SOAPMessa >geSecurity-v1.1.1-os.doc? > >Page 4 "SAML Assertions (obtained through WS-Trust)": how >the assertions are obtained seems out of scope for this >profile, as long as they are obtained somehow. In practice >WS-Trust may be the way to obtain them, but this >specification should not be hardwired to that. > >Page 4, references, update to WS 1.1.1 where relevant. >These fix interoperability issues with 1.1 and earlier. >Turn the bibliographic identifiers (e.g. "[EBMS3CORE]") into >Bookmarks and change any reference to them to Bookmark >references. >Is SAML 1.1 still relevant (see below on conformance). > >Page 5, I think you can state the this profile specifies a >way to use SAML as an alternative for situations where the >Core Spec mentioned X.509 tokens. If one is used, the other >is not used and vice versa (if I understand this spec >correctly). > >Page 6, reference to SAML 1.1. If you have decided to focus >on SAML 2.0, all references to SAML 1.1 can be removed. > >Page 6, section 2.1. Right now the assumption seems to be >that one is a hub and the other SME or other business and >that the SAML token is only used for the initiator and the >responder uses a known X.509 token. Can this profile be >used for communication between two SMEs? Would the >responder then be able to also use a SAML token or is the >initiator supposed to find out the X.509 certificate of the >receiver prior to sending messages? > >Page 7, 3.1 last sentence and Page 8, MPC authorization: >in the Core Specification this is an optional feature >including a second WS-Security header targeted to an "ebms" >actor/role. This second header is configured using the >Pmode.Initiator.Authorization parameters. > >Page 7, "a symmetric key, then it will be wrapped": use the >RFC keywords, this is probably a MUST. Also in other parts >of the spec. > >Page 7, 3.3 first line "where:" --> "where". "should" --> >"SHOULD". > >Page 8, 3.5 are you stating that the second header must not >be used, or is it still an option? > >Page 8 "this is normally the SOAP endpoint of the receiver, >but it may be any URI that logically denotes the SOAP >receiver". >Is this a Pmode parameter? If yes, which one? > >Page 8: "both attribute were" --> "both attributes are" > >Page 9, errors like EBMS:0005 are defined as errors in >communication with the receiving MSH. But these are here >errors in communication with the STS. I would suggest >defining new errors for all communication with the STS >rather than overloading existing errors. > >Page 9, many of these errors would be generated by the >receiving security module as SOAP Faults? How do they >relate to the ebMS errors? > >Page 9, "Token subject is unknown to Receiver" and page 14. >It seems there can be two situations: the Receiver accepts >messages from anyone provided they're identified by a listed >STS or there is some enumeration of Token subjects. Then I >think we would need an optional PMode parameter to enumerate >the accepted subjects and/or one for denied parties, so the >MSH can map the token to the white list/black list. > >Is there a requirement that the Token subject be the same as >the From/PartyId ? I think it would not be a bad idea. > >Page 10, state that the example is non-normative. > >Page 13 "the must be encrypted" --> "they must be encrypted" > >Page 14 "Encryption of elements should use the X.509 >PModes." You enumerated the Signature parameters, so best >to enumerate the Encryption ones here as well. > >Page 14 "These PModes in whole or in part may be expressed >through various mechanisms specific to the implementation >including via [WSPOLICY] and [WSSECPOLICY] for both WSDL and >MEX." We haven't discussed how Pmodes are distributed in >any spec, it would indeed be implementation specific. > >Page 15, Conformance. All conformance clauses relate to >SAML 2.0. If you have decided to focus on SAML 2.0, all >references to SAML 1.1 can be removed. >But you could also add separate profiles that use SAML 1.1 >instead of SAML 2.0. > >Hope this helps, > >Pim > > > >
Original Message----- >From: ebxml-msg@lists.oasis-open.org >[ mailto:ebxml-msg@lists.oasis-open.org ] On Behalf Of Mr. Ian >Otto >Sent: 17 July 2013 11:42 >To: ebxml-msg@lists.oasis-open.org >Subject: [ebxml-msg] First draft of SAML document uploaded > >I have prepared the first draft of the SAML conformance spec >and put it here: > https://www.oasis-open.org/apps/org/workgroup/ebxml-msg/down >load.php/49984/ebms-v3%200-saml-conformance-v1%200-wd01.doc > >Probably too short notice for today's meeting, but it would >be great to get feedback on it within the next week. > > > >--------------------------------------------------------------------- >To unsubscribe from this mail list, you must leave the OASIS TC that >generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >