OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[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
Should you not reference the most recent one

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
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

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" -->

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
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,


-----Original Message-----
From: ebxml-msg@lists.oasis-open.org
[mailto:ebxml-msg@lists.oasis-open.org] On Behalf Of Mr. Ian
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:

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]