Proposed Minutes for SSTC Telecon call (8 January 2013)

[Nate Klingenstein <ndk@internet2.edu>]

> 1. Roll Call & Agenda Review.

A quorum was present.

> 2. Need a volunteer to take minutes.

Nate volunteered.

> 3. Approval of minutes from previous meeting(s):
> 
>   - Minutes from SSTC Call on 13 November 2012:
> 
> https://lists.oasis-open.org/archives/security-services/201212/msg00006.html
> 
> 
>   - Minutes from SSTC Call on 11 December 2012:
> 
> https://lists.oasis-open.org/archives/security-services/201212/msg00005.html

Chad moves to approve both sets of minutes and Anil and Scott both seconded the minutes.  There were no objections and both sets of minutes were adopted.

>  (c) SAML 2.1 work (Scott and Chad)
>      - SAML2.1 wiki: 
>        https://wiki.oasis-open.org/security/SAML2Revision
> 
>      - Chad's list:
>        https://wiki.oasis-open.org/security/SAML21
> 
>      - Re-org idea (mail-list):
> 
> https://lists.oasis-open.org/archives/security-services/201212/msg00009.html

Chad doesn't have much to add beyond what was stated in the thread; his proposal is that we take the protocol and profile documents and rearrange them so that things that are similar in nature, such as the Web Browser SSO stuff, could all be in one document.  NameID management and identifiers could be another document, or queries.

This would take the vertical organization most of the material has today and rearrange it to be horizontally cohesive.

Anil wants the SSTC to focus on the audience for the specifications.  He thinks the two sets of probable readers are implementers and information gatherers, and the rewrite has to keep both sets of people in mind.

Hal responded that, traditionally, the executive overview and the technical overview were the place for people who wanted to learn how SAML works without looking at the nitty-gritty details of implementation.  Hal prefers that those documents be improved rather than the specifications be focused on two significantly different populations.  He thinks part of the reason for the separation is that, early on, it wasn't clear what sorts of combinations and permutations implementers would be interested in.  With all the experience that has been gained since 2.0 has been released, we now have a much better idea how to structure the material.

Chad thinks complaints about the absolute length of these specifications are red herrings, and Hal thinks that the ultimate question really is, "how much stuff do I have to read that isn't relevant to what I'm trying to do?"

Scott is happy to see how the initial writeup comes out, with SSO as the most complex and important profile serving as the first to be written and a litmus test.  He also thinks that the AuthnRequest material was artificially made too abstract in order to deal with FUD from WS-* that is not important now.  OASIS requires that profiles be developed, a constraint that Scott isn't thrilled about, but he thinks protocols and profiles should be collapsed wherever possible in order to simplify material.  He thinks most of the sections of the core document need to be reusable.  He's also not sure that you could include metadata as a single discussion within a profile that would .

There would be more documents at the end of the process than there are today, but it would allow an implementer to start with one document that gives a clear roadmap to implementation.  Processing rules would be located in one place, helping readers "get it" at a high level quickly.

There remain decisions to be made about what is included in each profile and what is required for a conformance document.  The initial conformance document was rushed and developed at the end of the process, but a significantly improved conformance document could serve as an entry point for readers and implementers as well.

Consensus is that we should at least give the reorganization a try in order to see if it improves readability.  The goal is not to reduce the number of documents, or to collapse everything to a single document; clarity and order are the ultimate goals.  Evaluation of the reorganization would follow, and if the new approach was cleaner, then it would be adopted for 2.1.

Chad plans to do this using a plain document as a start as we evaluate the approach rather than burdening TC Admin and getting templates and tracking going.  The SAML Wiki is another resource that could be used.  Most of this initial work would just be copying, pasting, and reorganization, but he'll put out a draft on the Wiki.

>  (d) UML version of metadata schema (Rainer Hoerbe)
> 
> https://lists.oasis-open.org/archives/security-services/201211/msg00010.html

Rainer heard the questions about the usefulness and purpose of the UML diagram from the call in December and he laid out his thoughts in a response to the list.  He sees value in a simplified view that isn't normative but useful on the conceptual level in order to connect with deployers.  Whether this is handled in 2.1 or another document is up for discussion, but Rainer doesn't believe XSD is the best tool to convey a conceptual approach.

Chad still personally doesn't find the UML model to be any clearer than the screenshot of the XSD given by viewer tools.  Chad thinks it would be beneficial to have in the overview document, especially as metadata becomes somewhat more mandatory, a much clearer textual description of what really goes into metadata.  The Shibboleth documentation includes a very rough cut at something similar.

Rainer agrees that text augmenting a UML or visualized XSD picture is very important.  He started with XSD viewer tools as his starting point for developing the UML diagram.  He removed some text that is extraneous for initial understanding, such as namespaces.

Rainer has volunteered to work on the technical overview documents for 2.1 and he'd like to include in that a more comprehensive discussion of metadata.  This is a first step towards inclusion in such a discussion and he would like more input on what would be desired for the overview.

For Scott, a textual description is more valuable than any diagram because he gets nothing from diagrams.  He has no objection if others would like to include a diagram, but he does feel that the text is crucial and it needs to be improved, and that an improved diagram will not help alone.

Hal thinks Rainer's goal is to capture the major pieces of metadata rather than serving as a complete graphical normative reference, although such a complete graphical description could also be included.  Most participants, including Rainer, agreed that a general contextual diagram would be a valuable introduction and index for further exploration.

Rainer suggested that he could review Scott's document and compare it to the diagram he's generated, and then we can revisit this topic in an upcoming meeting.

>  (e) SAML ECP (Scott)
>     - Any updates?

Scott had no updates yet.  He's got some revised drafts pretty much ready to go, but he was hoping to get a little more implementation experience before presenting these drafts to standards organizations.

>  (f) XPA updates (David S. & Duane)
>     - Any updates?
> 
> https://lists.oasis-open.org/archives/security-services/201208/msg00010.html

Neither David nor Duane was in attendance.

>  (g) Asynchronous Single Logout Profile - CS Published
> 
> https://lists.oasis-open.org/archives/security-services/201212/msg00007.html

Congratulations to the SSTC and thanks to Chad and Scott for all the work on this.

> 5. Assorted mail items:
>  - New Cloud Authorization TC
>  - 30-day Public Review for REST Profile of XACML v3.0

A final vote by organizational representatives is happening right now.  Five or six companies will demonstrate interoperability using the JSON and REST representation of XACML at an upcoming conference.

> 7. Next SSTC Call:
>   - Tuesday Tue 22 January 2013.

We look forward to speaking with you then.