[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ebxml-msg] First draft of SAML document uploaded
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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]