comments and questions on sstc-saml-core-2.0-cd-02

Following a group review of some of the doc’s, the
following comments and questions arose on -core. I have some more, but haven’t
had time to write them up. I’ll get them out asap.

 

 
Section 3.7.3.2 Session
     Authority Rules (Lines 2506-2509), states that the protocol does not
     permit partial success and that "any error during the propagation of
     logout requests… MUST result in the failure of the overall logout
     process ...".  Doesn't this imply that somehow logout messages
     that "succeeded" need to be rolled back if the request to a
     subsequent SP fails?  This will be impractical to implement in many
     systems since there is no feasible way to undo the logout’s that
     were already processed.

 
There was a question about why
     the “terminate” option of the Name ID Management Protocol was
     combined with the ID management and thus now always requires a response to
     be returned. In Liberty-based FederationTerminationNotification, the
     message could be delivered via an asynchronous SOAP message with no
     expected response.  It seems to introduce additional overhead. I
     couldn’t recall the justification for it.

 
Section 2.2.4 (<Issuer>):
     Since it is of type NameIDType, an Issuer can have the various attributes
     described in the base type (NameQualifier, SPNameQualifier, and
     SPProvidedID – in addition to Format).  We don’t describe
     anywhere if/when you would use those attributes.  In fact, if they do
     get used, it probably creates some ambiguity for the definition of a
     SourceID used in the artifact resolution profile since it says that it is
     created from the SHA-1 hash of the <Issuer>.

 
Line 753: states that the <Conditions>
     element “MAY contain the following elements…” and the
     <Condition> element on line 760 is listed as one of these. 
     However, technically, the <Condition> element actually can’t
     appear since it has a type that is abstract (i.e. ConditionAbstractType).  
     What can be included are “Elements that are derived from
     ConditionAbstractType”.  This convention is used throughout the
     document for other abstract types.  Would it make sense to clarify
     each such use? Or perhaps we should just briefly mention the convention in
     the Notations section at the front of the document.

 
People generally find it a bit
     confusing that we have the similar terms “asserting party”,
     “authority/SAML authority”, and “responder” as
     well as “relying party”, service provider”, and
     “requester”. I explained that the terms have slightly
     different meanings and the term that is used depends on the context of the
     discussion. I think we should do 2 things: a) search the specs for the
     terms and make sure we’re using the correct one in each context, and
     b) somewhere (notation?) make it clear that there are terms defined in the
     glossary that have similar, but subtle differences in meaning and that the
     proper term depends on the context of the discussion.

 
People also find it confusing
     that we frequently refer to “principal”,
     “subject”, “user”, and
     “identity”.  Again, we should double-check their usage
     and explain their uses depending on context.

 
Nit: why are sections 1.2.1
     (String Values) through 1.2.4 (ID and ID Reference Values) subsections of
     1.2 (Schema Organization and Namespaces)?

Senior Consulting Engineer 

RSA Security Inc. 

Tel: 781-515-7115 

Mobile: 617-510-0893 

Fax: 781-515-7020 

mailto: