Re: [wss] SAML Token Profile 1.1 comments

[ronald monzillo <Ronald.Monzillo@Sun.COM>]

Frederick.Hirsch@nokia.com wrote:
> Ron
> 
> Thanks for an improved revision to the SAML Token Profile. I have a few questions and suggestions as well as a number of editorial comments (typos).
> 
> Line numbers refer to the PDF with change bars at 
> http://www.oasis-open.org/apps/org/workgroup/wss/download.php/12686/WSS-SAML-TOKEN-PROFILE-1.1-wd-02-changes.pdf
> 
> Comments:
> 
> 1) Line 195, should the definition of "SAML Assertion Authority" be "A system entity that issues SAML assertions."? Not sure why it is abstract, part of the current definition.
> 
I agree, but was asked to change the definition to its current form
during review of the 1.0 profile.

> 2) Section 3.4, line 436-7, should we restate requirement in the MUST NOT form (keeping the same meaning):

good idea, although I think both the MAY and the MUST NOT concepts must
be retained (to achieve a MAY ONLY).

> 
> "A key identifier MUST NOT be used to reference a remote SAML V2.0 assertion, i.e. an assertion not contained within the same SOAP message." 
> 
> 3) Footnote #4, after line 450, we should also refer to the 1.1 core (avoiding possible confusion regarding applicability of errata) , adding sentence:
> "This change has been merged into WSS: SOAP Message Security 1.1 as well."

I am not sure how to handle this. I guess this is no longer an issue for
the 1.1 specs (since it was fixed in the 1.0 spec. I think the footnoote
rationalizes the lack of encodingtype which should no longer be needed
(and could be removed)

> 
> 4) at line 469, remove "doubly-referenced", possibly confusing, maybe not always doubly-referenced.
> 

I don't see this. there is a ds"reference to an str which references and
assertion. thus the assertion is doubly-referenced.

> 5) line 489, not clear what is meant by "not included in this profile". Does this mean not addressed, or not allowed?  Suggest change to "not addressed by this profile"
> 

not defined by this profile. Not precluded, but one should not expect
implementers of this profile to understand such things.

> 6) Line 499, replace "compatible' with "conformant"
> 
yes I should be consistent.

> 7) 605-608, for clarity, show full example (it is short) rather than just changed urls.
> 
OK
> 8) Line 667, change SHOULD to a MUST, producing
> 
> "The STR Dereference transform MUST NOT be applied to an embedded reference."
> 

sing the transform eliminates the STR wrapper from the signature, but
one MAY be OK with doing that.

> 9) Are you sure the sender-vouches examples are correct (section 3.5.2.3 and 3.5.2.4)? They seem to use the holder-of-key confirmation method (lines 1034 and 1134).
> 
yes the examples are correct, but so many folks have not understood
them, that I likely would be doing folks a favor by simplifying the
STR's at lines 1047 and 1147, to point to a sv-confirmed assertion in
the msg, so folks can see that what is being signed with the msg is a sv
confirmed assertion.

> Typos/Editorial
> 

Thanks for the editorial comments, I will review them when I have a
littel more time.

thanks for the review and I did a quick review of the editorial
comments, and will follow up on them.

Ron

> 10) Section 1.1 
> 
> line 142 is awkward
> s/including for/including the use of such assertions for/
> 
> line 145 - not required to be referenced
> s/and referenced/and may be referenced/
> 
> line 145
> s/wsse:security/wsse:Security/ (actually just do this globally in the document)
> 

> line 146
> s/are used/may be used/
> 
> line 151 
> s/for/in conjunction with/
> 

> 11) Section 3.2
> 
> in 3.2.1 line 223 s/AssertionID/AssertionID"/
> 

> in footnote 3 after line 266, s/ds:keyinfo/ds:KeyInfo/ (actually just do this globally in the document)
> also line 651
> 
> 12) Section 3.4
> 
> in 3.4.1 line 510 s/in the header/in the SOAP header/
> 
> in 3.4.2 line 645 s/<ds:KeyInfo elements may/Such <ds:KeyInfo elements referencing SAML assertions may/
> 
> in 3.4.3 line 671, s/not its reference/not the reference to it./
> 
> in 3.4.4 line 724 s/Security/<wsse:Security>/
> 

> 14) Section 3.5
> 
> Why is "canonicalization" in italics, seems regular format would be appropriate for these usages.

> 
> line 990 s/act as/act for/
> 991 not clear what "and with the calims of the statements" means in this sentence. Remove?
> 
> line 998 s/SecurityTokeReference/SecurityTokenReference/

> 
> line 999 two times  s/ds:reference/ds:Reference/g  (do globally in document)

> 
> regards, Frederick
> 
> Frederick Hirsch
> Nokia
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your TCs in OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> 

--