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


  1. Section 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.
  2. 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.
  3. 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>.
  4. 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.
  5. 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.
  6. 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.
  7. 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


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