RE: [security-services] Core spec errata

I will enter this into 
the errata document with disposition TBD. Some of these are fairly trivial and 
we should be able to knock them out quickly. Some others will undoubtedly 
generate more discussion.

 

Thanks,

Jahan

 

----------------
Jahan Moreh
Chief Security 
Architect
310.286.3070 

  
-----Original Message-----
From: Philpott, Robert 
  [mailto:]
Sent: Tuesday, January 21, 2003 
  1:44 PM
To: 
  ''
Subject: 
  [security-services] Core spec errata

  

  
Hi all - Some of these items may 
  really trigger new issues or re-open some old ones.  If so, we can open 
  separate email discussions on each one in question...

  
 

  
    
Lines 722, 726: The font for the 
    "Location" and "Binding" attributes is different from "AuthorityKind" on 
    line 714. 
    
Line 887: 
    s/interger/integer/ 
    
Line 961: s/may/MAY/ 
    ? 
    
Line 966: s/success would 
    normally/"Success MUST"/ 
    
Line 967: s/to be found 
    therein/will be included/ 
    
Lines 969-970: "exactly as for 
    saml:AuthorityKind attribute; see Section 2.4.3.2" - The AuthorityKind 
    section is referring to samlp:Query references not saml:Statement 
    references.  Folks read the reference to AuthorityKind and sometime try 
    to figure out a relationship between RespondWith and AuthorityKind, which of 
    course does not exist.  The section reference is intended to highlight 
    the use of saml and samlp QNames. Also, AuthorityKind is an attribute, while 
    RespondWith is an element, so the methods for specifying the values are 
    different. I recommend removing the section reference and simply insert 
    similar text inline. 
    
Line 971: s/must/MUST/ 
    ? 
    
Section 3.2.1.1 - I think we 
    should provide better guidance on rationalizing use of RespondWith elements 
    in a query and the associated Query type.  I know there's been some 
    discussion on this topic on the list, but I don't think the current text 
    here is very clear. For example, we should be explicit about what happens on 
    an AuthenticationQuery that includes a RespondWith for a 
    saml:AttributeStatement.  Another example is when an authority has an 
    existing Web SSO assertion that contains both AuthenticationStatements and 
    an AttributeStatement (e.g. what we used in the Interop).  Now if a 
    later AuthenticationQuery arrives for the SAML Subject with a RespondWith of 
    saml:AuthenticationStatement, this Web SSO assertion should NOT be returned 
    according to lines 963-964. So we should be explicit that if an assertion 
    contains multiple statement types, there must be a RespondWith in the query 
    for every statement type in the assertion (assuming at least one RespondWith 
    is specified). 
    
Section 3.2 (Requests) - Section 
    3.3 (Queries) provides not only definitions of query elements, it also 
    provides processing rules and interpretation info for the Queries.  But 
    we don't do that for the <AssertionArtifact> or 
    <AssertionIDReference> request types.  Section 3.2.3 defines the 
    <AssertionArtifact> element but doesn't say how it is used (of course 
    this is discussed in the Profiles).  There is no section describing the 
    RequestType "saml:AssertionIDReference" here since the element is defined in 
    section 2.3.1.  When someone asked me why AssertionIDReference wasn't 
    described, I at first thought it was an omission since all of the other 
    request and query types are discussed in 3.2 and 3.3.  Then I realized 
    the saml/samlp distinction. But it might be clearer and avoid questions if 
    there was a brief mention of processing rules for 
    AssertionIDReference. 
    
Lines 1061-1065: In addition to 
    subject and authn method matching rules, we should indicate that the 
    assertion processing rules are also impacted by the presence of RespondWith 
    elements in the Query. 
    
Section 3.3.4 AttributeQuery - 
    Should also mention the subject-matching rules as described in section 
    3.3.3 
    
Line 1085: "the start of the 
    current document" - In a query, the samlp:Request is the **current** 
    document, so what does it mean to use a Resource with an empty 
    URI? 
    
Section 3.3.5 
    AuthorizationDecisionQuery - Should also mention the subject-matching rules 
    as described in section 3.3.3 
    
Line 1219: s/request. 
    top-most/request. The top-most/ 
    
Line 1237: s/subcodes MAY 
    be/subcodes may be/ (should not use normative "MAY") 
    
Section 3.4.4 (Responses to 
    <AuthnQuery> and <AttrQuery>) - Don't the saml:Subject matching 
    rules described in this section also apply to <AuthzQuery>?  In 
    fact, I assume the rules should apply to all <SubjectQuery> requests, 
    including and extensions.  So I think the section should be more 
    general. 
    
Line 1417: 
    s/REQUIRES/requires/ 
    
Section 5.4.2 (C14n) - We should 
    mention the preference for Exclusive C14N and refer to the external DSig 
    Guidelines document. 

  
 

  
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: