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: Re: [security-services] Proposed Minutes for SSTC Call (Tue 17 April 2012)


On 04/17/2012 12:05 PM, Nate Klingenstein wrote:

AGENDA:

1. Roll Call&  Agenda Review.

Company     Name ascending     Role
Internet2     Scott Cantor     Secretary
M.I.T.     Thomas Hardjono     Chair
Internet2     Nathan Klingenstein     Chair
Internet2     Chad La Joie     Voting Member
Oracle     Hal Lockhart     Secretary

Quorum: 4 out of 8 voting members (50%). Not Achieved.

Status: Nate regains. Ari K loses voting rights.

Quorum was not achieved.

Scott offered to give a brief update about some of the GSS work activity.

2. Need a volunteer to take minutes.

Nate volunteered to take the minutes.

3. Approval of minutes from previous meeting(s):

    - Minutes from SSTC Call on 3 April 2012:

http://lists.oasis-open.org/archives/security-services/201204/msg00008.html

   (Roll-call list needed)

Because quorum was not achieved on this call, the minutes will be approved on the next call. Anil has posted the roll call.

4. AIs&  progress update on current work-items:

   (a) Current electronic ballots: (none)

   (b) Status/notes regarding past ballots:

       - MDUI Version 1.0 CSD03 passed.
http://lists.oasis-open.org/archives/security-services/201204/msg00010.html

This ballot passed and the process was approved.

   (c) Metadata Extensions for Registration&  Publication Info (Chad)
       - Status: Any comments received?

Waiting until we hear from TC-Admin here, but we believe this specification passed as well. Thomas will email TC-Admin after the call and CC the authors.

(d) Metadata Extensions for Login and Discovery User Interface (MDUI) (Scott)
       - Status: now TC-Admin #896

Percolating through the process at present. Scott thought that PDF's were not being generated, while HTML was, and although OASIS is treating HTML as the standard publication format, we need a PDF as well at minimum to avoid forcing people to use the ODF files. Our ODF files don't convert cleanly to HTML; we'd have to use Docbook. Scott will confirm that his memory here is correct and will contact TC-Admin if so and weigh whether it's worth fighting this.

Hal suggested it would be more sensical to just generate HTML directly rather than relying on an ODF and export.

   (e) SAML2.0 Approved Errata (Scott)
       - Status: published

http://docs.oasis-open.org/security/saml/v2.0/errata05/csprd01/saml-v2.0-errata05-csprd01.html

A full majority vote needs to be scheduled on a call with quorum to finalize the approval of the errata. No comments were received during the public comment period.

   (f) SAML 2.0.1 and Security Considerations doc
       - Status: SSTC agrees to proceed on this in 2012.
       - Issues: Should metadata and trust exchange frameworks
                 be made mandatory.
       - Status: Scott has emailed a proposal to the list.

http://lists.oasis-open.org/archives/security-services/201203/msg00011.html

There were a few murmurs in general agreement and a sense that we want to rethink the labels we use for different conformance classes to better fit with the deployment scenarios experienced in the wild. If there are useful conformance classes that people are willing to propose and document, while we don't want a very long conformance document with full deployment profiles, we should be open to suggested classes that include feature lists important to specific communities or deployments.

The existing conformance classes were based on somewhat arbitrary distinctions, specifically around the need to persist or maintain state. Conformance classes that guide implementers towards the feature sets important to the community they want to serve are likely to be more valuable to both implementers and deployers.

Scott called out algorithm support as a specific thing that needs to be emphasized because of the known vulnerabilities in XML CBC encryption, but Hal remains conflicted about the best way for the SSTC to deal with that.

Limited pushback on the extensions that Scott had proposed merging into Core. Presuming that's the case, then there are likely just a number of discussions around some of his other proposals. He would like general TC consensus, and once that is achieved, then it's time to start working. Hal will answer point by point the questions Scott raised in email at some time this week.

This is all barring an attempt to change the formatting of the specifications, which would involve a large amount of work. As long as PDF's are available, we don't care too much that the HTML is ugly.

Scott would like to solicit help from others to accomplish this work in a timely fashion, and there are independent documents that would create discrete workloads for everyone who would like to contribute. Some of this work will be fairly mechanical, e.g. just applying errata that have already been defined in a red-line spec. Otherwise, it might take a long time to complete the work.

This will, of course, remain on the agenda going forward.

   (g)  SSTC Webinar:
       - Proposed topic: scope of work for the 2.0.1 spec.
- AI: Thomas to email Dee to suggest dates (around the 1st week of
             June on the planned work in 2.x).
             Audience assumed to be SAML-knowledgeable.

Thomas sent this email out immediately prior to the call and it should be in the archive shortly. We don't need a lot of lead time for the webinar; mostly, we need to deliver a consensus about the SSTC's scope and purpose for 2.0.1. We aren't sure how long it will take to achieve this consensus and we don't know what the technologies used for the webinar will be.

   (h) Enhancement for Dynamic Attribute Queries (David Chadwick)
       - AI: David to start document (done)

http://lists.oasis-open.org/archives/security-services/201204/msg00009.html

David Chadwick was not present on the call so we were unable to proceed with this item.

There has been some implementation activity recently around the various GSS mechanisms that have been floating around. People are beginning to discover some real issues as the rubber meets the road. There are many GSS assumptions baked into applications that need to be accommodated and are not standardized. Scott's draft in particular did have some issues that needed to be dealt with through implementation experience, and he now has the feedback he needed to understand how best to finalize the draft.

The two drafts that would go through the OASIS SSTC to support this work are likely to be ready to proceed soon.

The writers and initial implementers of these specifications are still struggling to define some sort of rudimentary session key generation and persistence past the delivery of the initial bearer token; we're also looking at holder-of-key, or the ability to drop a key out of the TLS session; of course, it will be difficult to determine an approach that will work for the wide variety of GSS applications present in the world. Naming issues are the other primary remaining issue. There may need to be a draft either on the IETF side or the OASIS side in order to address the session keying question in particular.


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