RE: [security-services] Proposed Minutes for SSTC Telecon (Tue 4 September 2012)

[Thomas Hardjono <hardjono@MIT.EDU>]

Adding roll call for Sept/4/2012 call:

Alan Foster (Forgerock)
Hal Lockhart (Oracle)
Frederick Hirsch (Nokia)
Anil Saldhana (Red Hat)
Nate Klingestein (Internet2)
Scott Cantor (OSU)
John Bradley (Ping)
Thomas Hardjono (MIT)

Quorum was achieved.


__________________________________________

-----Original Message-----
From: security-services@lists.oasis-open.org
[mailto:security-services@lists.oasis-open.org] On Behalf Of Nate
Klingenstein
Sent: Tuesday, September 04, 2012 12:30 PM
To: OASIS SSTC
Subject: [security-services] Proposed Minutes for SSTC Telecon (Tue 4
September 2012)

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

Nate volunteered.

> 3. Approval of minutes from previous meeting(s):
>
>   - Minutes from SSTC Call on 21 August 2012: (adding Rainer Hoerbe)
>
>
https://lists.oasis-open.org/archives/security-services/201208/msg0001
> 9.html

Rainer's name didn't make it onto the posted minutes, but his name was
included in the approval process.  John Bradley moved for the approval
of the minutes and Nate Klingenstein seconded.  With no objections,
the motion passed and the minutes were adopted.

>  (c) SAML 2.1 work:
>      - Status: SSTC agrees to proceed on this in 2012.
>      - AIs:
>        o Scott to request new document name & will transfer
>          boilerplate and properties into the old docs, etc.
>
>      - https://wiki.oasis-open.org/security/SAML2Revision

Scott has been on and off vacation throughout much of August.  He had
put a bunch of metadata material in the Wiki and continues to want to
see some sort of consensus achieved so that it can be moved to the
"agreement" section from the "close to consensus", and the more
agreement the better in preparation for the webinar.

The metadata specification specifically needs to be updated to break
apart trust and autoconfiguration use cases, both in terms of the
specification and in terms of conformance.  DDDS, normative material
around third party hosting of metadata, stronger profile language for
improved interop for conforming implementations, different conformance
levels, and so forth have all been discussed.  Many metadata
extensions that have been used widely in deployment have also been
moved towards the core specification.

Scott moved to move the metadata requirements to the approved
category, and John Bradley seconded.  No objections were registered
and the motion passed.

Scott also wanted to solicit input on addition of new element types to
the XML schema, tightening a few fields.  He doesn't think it would be
contentious to publish a second edition of the schema, not changing a
namespace, but adding constraints that are in the prose into the
published schema.  He realizes people are sensitive about revising
published and widely used schema.

The schema version attribute would be changed to 2.1 in order to
reflect these changes, and the URL's where the schemas lived would
also presumably change.

John's initial reaction is, if this is clearly a different schema and
implementations could clearly decide which schema they want to be
conforming with and validating against, then that's good, but the old
schema should be published as well.

Hal's initial reaction was, "sure, but I need to investigate this."

In practice, this sort of schema revision is unlikely to cause any
problems in existing implementations because the existing schema would
still be usable.

The only interop change would occur is that someone who didn't fully
implement the specification could send something that would be
rejected by a provider using the 2.1 schema.  While that may actually
be the intention, Hal mentioned that when something that was
functioning seems to break arbitrarily, customers are not usually
thrilled.

This would possibly lead to the publication of a new namespace as
well, making it a one-for-one change on schemas.

Scott will hold back on any schema revisions until we get more
feedback -- feedback encouraged -- but he thinks it's reasonable to
start down this path.  He sent a message on the 14th of August
entitled, "suggested schema tightening for 2.1".

>  (d)  SSTC Webinar:
>      - Proposed topic: scope of work for the 2.0.1 spec.
>      - Status: date planned is 27 September 2012.
>      - Status:
>        o Data from NASA posted by Thomas.
>        o Rainer posted link to data from Kantara BTCF
>
>
https://lists.oasis-open.org/archives/security-services/201208/msg0002
> 2.html
>
>
http://kantarainitiative.org/confluence/display/bctf/Global+Trust+Fram
> ework+Survey

The Webinar will be entitled "SAML: Right Here, Right Now".  Hal wrote
a blurb and he hoped that Dee would have posted a notice about this by
now.  He'll ping Dee to make sure they're not waiting on Hal.

>  (e) Asynchronous Single Logout Protocol Extension (Chad)
>     - Status: Scott will post a new WD after getting latest files
from 
> Chad.
>
>
>  (f) XPA updates (David S. & Duane)
>
>
https://lists.oasis-open.org/archives/security-services/201208/msg0001
> 0.html

Neither David nor Duane was in attendance, so this discussion item was
delayed.

>  (g)  SAML in JSON
>     - Continue discussion from last telecon.

The only thing discussed that might lead to action would be a defined
mapping between SAML and the proposed JWT spec happening in the OAuth
TC and/or some version of JOSE to be used in a fashion like SAML
simple sign was proposed to be used.  Since there wasn't a lot of
appetite for making either an action item yet, there's probably not
much more to discuss about this topic until such time this work
becomes more necessary.

If this is brought up again as a work item in the future, the SSTC
hopes to have a concrete proposal on which to deliberate.

We look forward to speaking to you in 2 weeks.

---------------------------------------------------------------------
To unsubscribe, e-mail:
security-services-unsubscribe@lists.oasis-open.org
For additional commands, e-mail:
security-services-help@lists.oasis-open.org

Attachment: smime.p7s
Description: S/MIME cryptographic signature