Proposed Minutes for SSTC Call (August/19th, 2014)

[Nate Klingenstein <ndk@internet2.edu>]

> AGENDA:
> 
> 1. Roll Call & Agenda Review.
> 
> 2. Need a volunteer to take minutes.

Unfortunately, a volunteer to take minutes was not selected during the call itself.  The call had lively discussion and several important points of feedback that Nate attempted to retrospectively capture below.  All call participants and SSTC members are strongly encouraged to contribute their recollections to this collation.

> 3. Approval of minutes from previous meeting(s):
> 
>   - Minutes from SSTC Call on 5 August 2014:
> 
> https://lists.oasis-open.org/archives/security-services/201408/msg00001.html

The minutes were adopted without objection.

> 4. Presentation/discussion from Alex DeJong / Siemens (30 mins).

The presentation offered by Siemens is attached here:

Attachment: SAMLforEPCS.pdf
Description: SAMLforEPCS.pdf

The main comments detailed the rationale used by the SSTC when it initially decided not to define a bunch of extremely precise context classes up front, emphasized the importance of using well defined names in appropriately owned namespaces, which are typically not OASIS-controlled names when doing subsequent profiling like this, and the general value in outlining the various deployment decisions they wanted to make in a formal deployment profile.

We didn't get into a lot of specific details. Scott noted particularly that there was a great deal of work on strong authentication in parts of the full SAML transaction without requiring such strong authentication for other links in the chain.  It's generally preferable to ensure a consistent level of integrity throughout the profile so the level of security and effort match the deployer's expectations rather than performing very strong SAML-based authentication and ending up with an HTML user-agent cookie at the end.  Siemens pointed out in a response that they have some unique deployment features, such as the fact that they use a browser plugin to guarantee user interaction and they can assume some level of client software, which opens up significant possibilities for a consistently stronger deployment profile.  Holder-of-key assertions and other mechanisms to improve assurance that security tokens are being played by the intended recipients would be an obvious place to begin thinking, so long as the conversations remained wholistic.

Siemens also broached the possibility of using two authentication statements to cover two different authentication factors, which is legal under the specification but likely a bad idea for interop purposes, in that much software has probably been written with the presumption of a single authentication statement per assertion.