[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Draft minutes for 29-Mar SSTC con-call
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]