[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Minutes for 29-Mar SSTC con-call, with attendance
Attendance of Voting Members
Hal Lockhart BEA Systems, Inc
Steve Anderson BMC
Rebekah Metz Booz Allen Hamilton
Thomas Wisniewski Entrust
Carolina Canales-Valenzuela Ericsson
Irving Reid Hewlett-Packard Company
Guy Denton IBM
Maryann Hondo IBM
Anthony Nadalin IBM
Scott Cantor Internet2
Wendy Gray JPMorganChase
Peter Davis NeuStar
Abbie Barbir Nortel
Cameron Morris Novell
Ari Kermaier Oracle
Prateek Mishra Principal Identity
Jim Lien RSA Security
John Linn RSA Security
Rob Philpott RSA Security
Jahan Moreh Sigaba
Eve Maler Sun Microsystems
Ron Monzillo Sun Microsystems
Emily Xu Sun Microsystems
Mike Beach The Boeing Company
Greg Whitehead Trustgenix
Attendance of Prospective Members or Observers
Alberto Squassabia Ping Identity
Peter Michalek Individual
Sharon Boeyen Entrust
Membership Status Changes
Martin Soukup Nortel - Requested membership 3/15/2005
Dana Kaufman Forum Systems - LOA starting 22 Mar
Alberto Squassabia Ping Identity - Requested membership 3/21/2005
Dipak Chopra SAP - Withdrew 3/29/2005
Peter Michalek Individual - Requested membership 3/29/2005
Summary of AIs:
AI: Eve to revise Tech Overview according to Eve/Scott comments by
roughly April 4.
AI: Scott to review the Tech Overview SSO material in more detail by
next week.
AI: Jahan to formulate some suggested redline text for E7 for review.
AI: Rob and Eve to explore how best to do publication of errata and
redlining with Mary McRae.
AI: Tom to propose specific errata text for E3.
AI: Scott to put together text to solve E4.
AI: Scott to respond to Rick on subject confirmation issue on the
X509 Attribute Sharing Profile.
> 1. Approval of minutes from 15-Mar SSTC con-call
>
> a. *minutes for OASIS SSTC conf call, 2005-03-15*
<http://lists.oasis-open.org/archives/security-services/200503/msg00091.html>
Rebecca moved to accept; Jahan seconded. Approved with unanimous
consent.
> 2. Technical Overview:
>
> **a. **[Eve] *Comments on Tech Overview rev 03*
<http://lists.oasis-open.org/archives/security-services/200503/msg00097.html>****
>
> **b. ****[Scott]* RE: [security-services] Comments on Tech
Overview rev 03
<http://lists.oasis-open.org/archives/security-services/200503/msg00101.html>*****
John Hughes has suggested that Eve incorporate comments.
AI: Eve to revise Tech Overview according to Eve/Scott comments by
roughly April 4.
AI: Scott to review the Tech Vow SSO material in more detail by next
week.
We'll try to wrap up the Tech Vow by the end of next week.
> 3. Errata:
>
> a. *Groups - SAML 2.0 Errata - Draft 02
(sstc-saml-errata-2.0-draft-02.pdf) uploaded*
<http://lists.oasis-open.org/archives/security-services/200503/msg00102.html>
Jahan has added a few items based on recent email.
E2 is simple: an incorrect section reference. Jahan moves to accept
correct; Eve seconds. Accepted by unanimous consent.
Scott: Suggests producing a non-normative redline version of the
errata'd documents (apparently the idea has come up before); the
resulting documents would have to change dynamically in response to
any new errata. This is the plan of record.
AI: Rob and Eve to explore how best to do publication of errata and
redlining with Mary McRae.
E7 is more substantive: Logout Request reason Mismatch with Schema.
The rule for precedence applies to schema snippets, not the actual
schema; it's kosher for the spec text to further constrain what the
schema says, which is effectively what's being done in this case,
but it's unusual because elsewhere we've used the anyURI type rather
than string. The schema isn't wrong per se, but it doesn't apply as
much validation as we've done in other cases.
Eve: Suggests that a mere clarification statement is in order,
saying that the intent is for a URI, and the effect of the
spec+schema together is a URI by virtue of a tighter constraint
dictated in the spec, even if achieved in a slightly confusing fashion.
Rob: In addition, the statement should say a future version of the
schema may change the type to anyURI.
AI: Jahan to formulate some suggested redline text for E7 for review.
There is still an outstanding AI for Scott to produce text to answer
some of the existing errata items. He thinks he can do some of them
by next Tuesday.
For E3 (SLO and NameID termination), Tom W. had proposed a solution:
http://lists.oasis-open.org/archives/security-services/200503/msg00034.html
AI: Tom to propose specific errata text for E3.
E4 (Clarification on SP AuthnRequestsSigned and the IdP
WantAuthnRequestsSigned SP metadata flags) was determined to be an
acknowledged problem, though we don't have a solution yet. But
we'll be more careful in future about not moving PEs to become Es
until we have a solution for them.
AI: Scott to put together text to solve E4.
> 4. Executive Overview
>
> a. *Groups - SAML V2.0 Executive Overview
(sstc-saml-exec-overview-2.0-draft-07.pdf) uploaded*
<http://lists.oasis-open.org/archives/security-services/200503/msg00095.html>
A new draft was uploaded six days ago. People should review soon
because we want to progress this spec.
> 5. Metadata Extension:
>
> a. NOTE: We plan to vote on this document for CD status
>
> b. [Scott] *Metadata extension proposal/namespace*
<http://lists.oasis-open.org/archives/security-services/200503/msg00088.html>
Scott reviewed his proposal; we may want to ensure that additional
extensions can be accommodated.
Greg: Would we have a single schema file that incorporated new
extensions in a rolling fashion, or multiple schema files?
Scott: Doesn't want to see a proliferation of namespaces, though we
may have very few ultimately.
Rob: If the document gets too big because of many extensions, then
we can revisit at that time.
The XML namespace is currently:
urn:oasis:names:tc:SAML:metadata:extension
If we need a version number later, we can add it at the end, but
perhaps there's no need for it now.
Greg: Should the fact that the metadata applies to a specific SAML
version be reflected in the namespace? Maybe this should be the
document that works for all versions of SAML.
Scott: Agrees; wouldn't want to have to rev this namespace for no
reason whenever SAML revs.
Scott moved and Greg seconded to start an electronic ballot to
approve this document as a CD. Approved with unanimous consent.
> 6. X509 Attribute Sharing Profile
>
> a. 15-Mar minutes indicate further list discussion of
contents for profiles like this may be needed. No discussion
occurred. Are we ready to vote on this spec for CD status?
Rebekah: Spoke to Rick and will sync up with him and Scott later
this week.
Scott: This has a push model. Not clear there's any way to use
subject confirmation in this profile, since there's no attesting entity.
Ron: What about if there's a signature with a key in the assertion?
Scott: Yes, but what does it buy you? You already have a
correlation based on the subject element. You don't need two copies
of the DN.
Rob: A user is going to an SP and authenticating using a client cert
directly at the SP, and the SP is using the cert to do an attribute
query for that subject.
Ron: So if the assertion that comes back doesn't have the same key,
it shouldn't be usable, right?
Scott: Yes, though that means the DN is broken somehow. Will send a
note back to Rick on this discussion, suggesting that you could use
subject confirmation, but you pretty much have to have a key in
there to get the desired effect. Maybe the next draft of the
metadata document can accommodate this.
AI: Scott to respond to Rick on subject confirmation issue on the
X509 Attribute Sharing Profile.
> 7. General List discussions
>
> **a. ****Reminder: Andy Moir is looking for feedback on
V1.1 spec conformance certification program. Review perioed closed
11-April:**
>
> ** i.
**http://lists.oasis-open.org/archives/security-services/200503/msg00054.html****
>
> ** ii.
**http://lists.oasis-open.org/archives/security-services/200503/msg00055.html**
**
Noted.
> **b. ****[Adam D] ***[security-services] ECP and PAOS*
<http://lists.oasis-open.org/archives/security-services/200503/msg00092.html>****
Scott: Doesn't seem to be a problem here based on the discussion. It
may be helpful to have explanatory text, but this should go in
advice to implementors, not the spec.
No action needed here right now.
> **c. ****[Prateek] ***Status of drafts seeking CD or other
"official" status*
<http://lists.oasis-open.org/archives/security-services/200503/msg00103.html>****
Prateek: Traditionally the TC has used CD status as a way to
recognize drafts as having the approval of the TC as a whole, even
if they're not part of a standard. It's also a way to "freeze" the
spec so that people know it's final. No particular fondness for CD
status as such, but need something here. What problems does the TC
see with this model?
Maryann: Is this something that should happen on a TC-by-TC basis?
Tony: It's unclear what documents should have CD status.
Hal: Proposing changes to the TC process might be a good thing, but
it could take a year or more.
Rob: Sent a note to Mary McRae and Andy Moir asking for guidance on
how to give such docs official status but without the intent of
moving them to an OASIS Standard status.
Maryann: Sent a request to IEEE to publish the Gross document.
Hal: As an example, W3C publishes the SOAP Primer as a
Recommendation. There are two cases we're concerned about here:
errata and informative-type documents.
Eve: Note that it's expected in OASIS that some docs can proceed to
CD without being on an OASIS Standard track.
Tony: There has been some confusion in the past on errata.
Hal: Since TCs run on RROR, we can make any kind of resolution we
want, within the applicable rules. TCs have dealt with such
questions before, and they do different things.
Rob: The SSTC has, in the past, moved informative documents to CD.
Hal: Back when CD was known as Committee Specification, a lot of TCs
went that far but no further. The renaming was perhaps meant to
encourage proceeding further.
Scott: On the errata question, we do need a better process.
Eve: OASIS has a stance on errata, which is "negative": You need to
use the full approval process if you want interop not to suffer.
Hal: Let's hear from the OASIS staff first before taking action.
Prateek/Rob: We'll add it to the agenda for the next call.
> d. [Tom W] *Status Code Response for an Invalid Principal*
<http://lists.oasis-open.org/archives/security-services/200503/msg00100.html>
Tom: The question is, what's the right code? This may be just an
implementation question. Is there meant to be a second-level status?
Scott: We haven't given much guidance about how to use these
second-level statuses. It's kind of arbitrary. Second-level status
codes in his environment are typically used for debugging and then
turned off for production.
Rob: Can a response with no assertion be returned instead of an error?
Scott: This is normative in the artifact case. And if no assertion
is found that satisfies query constraints, it's broadly allowed.
Rob: Will respond on the list.
[subject change] Tony:
> 8. Action Item review
>
> a. AI’s haven’t been updated on the web site. I’ll do this
before the con-call and will work through the open ones at that time.
#210: Links to new IPR policy to be sent to SSTC: Rob will do that soon.
#180: Need to update SAML server trust document: Still open.
#213: Prepare final CD draft of metadata-1x document and submit it
to OASIS: Eve will try to do that by next week.
#207: Provide [Want]AuthnRequestsSigned metadata setting comments to
Jahan for Potential Errata: Closed.
#208: Run additional tests to check issues with deflate encoding and
rfc1951 (java libraries): Still open. Greg ran some tests but Scott
will wants to test in something other than Java.
#211: Update SAML FAQ. Closed.
#209: Update X.509 Authentication-based Profile: Still open.
#212: What track to use for Thomas Gross response document?: Prateek
and Rob are both tracking this.
> 9. Any other business?
None.
Eve moved to adjourn; adjourned.
--
Eve Maler eve.maler @ sun.com
Sun Microsystems - Business Alliances x40976 / +1 425 947 4522
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]