RE: [security-services] comments and questions on sstc-saml-core-2.0-cd-02

["Scott Cantor" <cantor.2@osu.edu>]

These were discussed on the last call, comments/resolutions inline:

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

TC resolved that logout has always been meant as best-effort, and any error
aborts the process and results in an overall failure, but no rollbacks.

Implementation guidelines should clearly note that Single Logout is *not* an
effective security measure, but is intended for user convenience. Will also
clarify lack of rollback in spec.

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

It avoided the need to invent a new SAML protocol exchange pattern, and
there was no real value in having just a one-way notification. The overhead
is clearly minimal. The reason for it was historical in ID-FF, not out of
any particular reasoning.

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

Some of this is being clarified by factoring out the NameIDType definition,
but we resolved to insure that none of these attributes can appear in an
entityID, in section 8.3.6.

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

This is incorrect. Abstract typed elements will often appear in SAML (e.g.
Condition, Statement) because we block substitution. They simple have to
include an xsi:type.

>  What can be included are "Elements that are derived from 
> ConditionAbstractType".

Also incorrect. We specifically do not permit this unless those elements are
built in extensions that we define in core.

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

Rsolved to search the document for consistency.

> 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)?

Resolved to move those into a subsection.

-- Scott