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

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Some additional editorial comments for last call core spec (draft 10)...


Hi folks,

 

I raised most (all?) of these comments within the sstc-philpott-core-1.1-draft-06-comments spec I uploaded to the web site and announced to the list on 28-April.  We didn't have time to deal with them in the last call drafts, so I'm posting them for separate discussion and comment on the list as last call comments. We'll need to close on dispose of these over the next couple of weeks. Comments on the list are preferred, but any that are contentious can be discussed at the next con-call.

 

Line numbers are relative to draft 10.

 

  1. [Line 1419] Section 4.1.2, 1st bullet: "A SAML authority MUST NOT issue any assertion whose version number is not supported." 
    • Not supported by whom? The SAML specifications? The authority? By a requester? I assume it means "by the SAML specification set". The text should be clarified.
  2. [Line 1481] Section 4.2, 3rd paragraph: After "the specification.", adding something like the following might be useful.  Thoughts?
    • "For example, the SAML V1.1 specification set will continue to use the same SAML XML schema namespaces (e.g. "urn:oasis:names:tc:SAML:1.0:assertion") as the V1.0 specification set."
  3. [Line 1516] Section 5, 2nd paragraph, 1st bullet: "The reason is that the entire context must be retained to allow validation, exposing the message contents and adding potentially unnecessary overhead."
    • What does "exposing the message contents" really mean here?  Would it be more appropriate to say "exposing the XML content" as I think we should be talking in general terms and "message" might be construed to be talking about SAML protocol messages.  Also, to what are we exposing the contents? Tampering?
  4. [Lines 1833-1836] Section 7.1, 2nd paragraph: "In contrast, <SubjectConfirmationMethod> is a part of the <SubjectConfirmation> element, which is an optional part of a SAML subject. <SubjectConfirmation> is used to allow the SAML relying party to confirm that the request or message came from a system entity that corresponds to the subject in the statement."
    • "request or message" doesn't sound right in this last sentence.  I'm sure it says that because SubjectConfirmation is part of a Subject, which appears in both request messages and subject-based statements. But the "came from a system entity that corresponds to the subject in the statement" phrase doesn't seem to work since statements aren't in requests.  If I'm the only one that is confused by the wording, I'll drop the question.  Otherwise, could someone try to wordsmith it to make it clearer? 
  5. [Lines 1969-2058] There are a number of Reference section entries that have no cross-reference links from the text. 
    • We should either remove the unused entries or find places where the documents might be referenced in the text and add the cross-references to the bookmarks in the reference section.  How do folks want to deal with them? The ones I know of are:
      1. Kern84
      2. Pkcs1
      3. Pkcs7
      4. Rfc_2104
      5. Rfc_2630
      6. Rfc_2648
      7. W3c_line
      8. Xmlenc
  6. [Lines 2039-2040] The UNICODE-C reference identifies the March 2001 spec (http://www.unicode.org/unicode/reports/tr15/tr15-21.html). 
    • Should we refer to the latest UNICODE spec here [Version 4.0 - TR15-23, April 2003]?

 

 

Rob Philpott
RSA Security Inc.
The Most Trusted Name in e-Security
Tel: 781-515-7115
Mobile: 617-510-0893
Fax: 781-515-7020
mailto:rphilpott@rsasecurity.com

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]