Draft minutes for 29-Mar SSTC con-call

["Eve L. Maler" <Eve.Maler@Sun.COM>]

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