Re: [ebxml-msg] First draft of SAML document uploaded

["Makesh Rao (marao)" <marao@cisco.com>]

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
>