[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Minutes with roll call for SSTC Conference Call: August 3, 2004
Thanks to Steve Anderson... > Agenda for SSTC Conference Call: August 3, 2004 > > Dial in info: +1 865 673 6950 #351-8396 > > 1. Roll Call Attendance of Voting Members Hal Lockhart BEA Ronald Jacobson Computer Associates Gavenraj Sodhi Computer Associates Tim Alsop CyberSafe Carolina Canales-Valenzuela Ericsson Dana Kaufman Forum Systems Paula Austel IBM Maryann Hondo IBM Michael McIntosh IBM Scott Cantor Internet2 Bob Morgan Internet2 Prateek Mishra Netegrity Frederick Hirsch Nokia John Kemp Nokia Senthil Sengodan Nokia Charles Knouse Oblix Steve Anderson OpenNetwork Ari Kermaier Oracle Darren Platt Ping Identity Jim Lien RSA Security John Linn RSA Security Rob Philpott RSA Security Dipak Chopra SAP Jahan Moreh Sigaba Bhavna Bhatnagar Sun Microsystems Eve Maler Sun Microsystems Ron Monzillo Sun Microsystems Emily Xu Sun Microsystems Mike Beach The Boeing Company James Vanderbeek Vodafone Attendance of Prospective Members Peter Davis Neustar Vamsi Motukuru Oracle Nick Ragouzis Individual Scott Kiester Novell Cameron Morris Novell Membership Status Changes Scott Kiester Novell - Requested membership 7/28/2004 Cameron Morris Novel - Requested membership 7/29/2004 John Hughes Entegrity Solutions - LOA 8/3/2004 through 9/17/2004 Peter Davis Neustar - Granted voting status after 8/3/2004 call Vamsi Motukuru Oracle - Granted voting status after 8/3/2004 call Nick Ragouzis Individual - Granted voting status after 8/3/2004 call Forest Yin Netegrity - Granted voting status after 8/3/2004 call > 2. Agenda Bashing (including moving any items to focus session after adjournment) Eve: Add editor's review, cueing off of Scott's recent email. Let's add this after item #6 as part of the quorate call. Hal: Did I mention the new IPR policy last week? Yes. > 3. Approve minutes from 27-Jul con-call > > a. http://lists.oasis-open.org/archives/security-services/200407/msg00157.html Minutes APPROVED by unanimous consent. > 4. Status of Last Call Review > > a. Current target is to vote for CD on 10-August. Is this still realistic? Defer this till the end. > b. Various messages exchanged re: Jeff’s figures for profiles Prateek: Do we need to work on this, or is it just editorial? The latter. > c. Thread re: cost of MTI figures/Stateless conformity to SAML Prateek: Has published a conformance draft that reflects the ID-FF Static Conformance Requirements, except that, with the new bindings/profiles ideology, it may need updates. Asks for review, esp. from those familiar with the SCR. There are now IdP/SP definitions of conformance similar to the SCR. Do we need an "IdP Lite" conformance target? Scott: We're really talking about whether to allow products to conform that don't *expose* the necessary support for *enabling* persistence. Rob: Is it okay to consider different operational modes of conformance that allow you not to do this? Scott: I shouldn't need a DB inside my product in order to be conformant. Eve: Can't we just keep conformance to the matter of protocols? Scott: The thread seemed to conclude that this isn't enough. But we don't want to impose certain implementation choices. Prateek: There's a sequence of message exchanges that are going to be stateful when used in a certain way; this can't be avoided. Eve/Scott/Rob: We have to allow for "must store" *and* "must cause to be stored" versions of implementation. Eve: Do we need to make a conformance flavor for this, or can it be an (important) feature of deployment? Are we overloading "conformance" to give it characteristics of deployment configuration? Right now the protocol definition accommodates both stateful and stateless. Rob: One category of conformance could be what we have currently, and a new category of conformance could be "doesn't implement name ID management". Steve: This sounds fair. But has a more general concern that this approach isn't very scalable; for every case where a set of table rows is contentious, we'd wind up adding another column for product type. Scott: We need to get an overview sense of where the problems really are, and group decisions together. Steve: Thus prefers Prateek's original approach, which is to have categories of functionality, and you can choose which ones you implement. So *all* the Web SSO (and maybe SLO) rows would be one set. Scott: But then you don't end up with a set of MTI pieces that customers can rely on, because everyone's picking and choosing profiles. Steve: Sounds about right! Nick: We need to figure out the error conditions surrounding implementations that claim name ID management support but don't handle it, and vice versa, so that appropriate challenges of conformance claims can be made. Eve: We shouldn't try to "legislate morality", and where there are natural seams in providing functionality we should respect them. Steve: Would prefer a very fine level of this, along the lines of the profiles in the Profiles document. RLBob: Let's appreciate that this TC is not Liberty, and there will be lots of conformance activity, including with the Shibboleth profile, that will continue outside this group. Scott: Conformance to the individual profiles is already enabled; anyone can do that now without invoking official conformance. Scott: Let's use "persistence" rather than "state". If we add "Lite" IdPs and SPs, then perhaps we'll later find other things that properly belong in that column. MOTION: Add two new operational modes, IdP Lite and SP Lite, that don't include support for the name ID management protocol (which amounts to four rows, given the binding choices). They would include all of the Web SSO and SLO rows and the identity cookies. Scott moves, MikeB seconds. Dana: Speaks in favor. Clarification of the motion: Is name ID management supposed to be optional in this case, or actually disallowed? The latter. Rewritten MOTION: Add two new operational modes, IdP Lite and SP Lite, that are identical to the regular versions except that they say "must not" in the four name ID management rows. Rob: We should put *something* in all cells that are now blank, to be clearer: maybe "N/A". MikeB: Is there a defined response if someone attempts to interact? Scott: There's nowhere to send the request. MikeB: It would be sufficient if a Request Denied response were returned; there seems to be plenty of status code stuff to handle this. JohnK: Okay with an IdP Lite, but less happy with an SP Lite because it could hamper deployment. Prateek: What would the rationale be for an SP Lite? There are many. They range from devices to building an application that simply consumes security information (like an LDAP directory), which is pervasive. "Enterprise write" is a big deal. The concern is that systems will be architected such that they'll be *unable* to expose name ID management. Voice vote on motion: 14 YES, 3 NO, 3 ABSTAIN. Motion CARRIES. > d. Scott’s note re: editing status: http://lists.oasis-open.org/archives/security-services/200408/msg00016.html Motion from Scott: Accept proposal for core changes for Attribute by-value queries. Relevant message is: http://lists.oasis-open.org/archives/security-services/200407/msg00158.html Eve seconds. Motion CARRIES. Core: Scott and Eve will polish in the next few days, with Rob input. Assertion/protocol schemas: Have been kept up to date, and Scott has also validates the instance examples in the document. Bindings: Scott needs to do the artifact example and review the later sections. There are diagrams now, which Scott has also uploaded separately (following Jeff). Media type issue: Jeff had indicated that we'd try to use the fast-track process. There's an application/samlassertion+xml media type, and also one for metadata. Metadata: Scott needs to add info about the new application/samlmetadata+xml media type and a couple of other small items. Metadata schema: Scott will update in accordance with main spec changes. Profiles: ECP work has been done. It's also missing diagrams; these exist but Scott needs to incorporate them. This spec needs a thorough editing pass. Attribute profile schemas: These currently exist only as listings. Scott will break them out into separate files. ECP profile schema: Is fine. Conformance: Eve will make changes to conform-03 to make it a formal entry point for the entire spec suite. Prateek will continue working on the rev after that. Security/Privacy Considerations: This was updated and discussed some time ago and again after the recent F2F. Glossary: Scott made some relatively provocative suggestions for this, scaling back the Liberty definitions of some things. In particular, the definition for "affiliations". MOTION: Incorporate Scott's proposed new definitions found in this message, using the phrase "identifier namespace" rather than just "namespace" to disambiguate from XML and other namespaces: http://lists.oasis-open.org/archives/security-services/200407/msg00193.html Motion CARRIES by unanimous consent. AI: Eve to incorporate this. Authentication context and schemas: There have been no changes since last call. There was an issue regarding changing the name of one of the attributes. Some of the schema files don't appear to be in the repository; John will fix this. Eve would like, eventually, to make this use the same format as the core spec for explicating the vocabulary, but this can be done post-V2.0. Scott has a question about the element for the authenticating authority; should it be removed? Yes. John will follow up on this. Back to discussing Conformance in detail: Scott: MOTION not to call out any specific name identifier types or semantics in the extended profile matrix (line 195 -- table 2 -- in rev 03 of the conference spec). He then amended to consider a limited version of the motion, to remove just the "One-Time (Anonymous) Name Identifiers" row. We agreed to defer (Scott withdrew), and discuss it on the list. Steve: The SLO rows that are SOAP-related say MUST; this is a problem. Some products will need to interact with the browser of the user in that session, so this won't be feasible in all cases. Scott: The only reason to have the front-channel version in some cases was to support such implementations. Why bother with the front channel if we're forcing people to implement the back channel already? JohnK: There was an issue in Liberty where, if the user's credentials were compromised, there had to be a back channel for propagating the logout. However, this is a fairly unlikely scenario. Prateek: This has some expectation of at least a short-lived persistent store for the session. Steve: MOTION to change MUST to OPTIONAL across the entire row for the SLO IdP-initiated over SOAP and SLO SP-initiated over SOAP rows. (Line 191 -- table 2 -- in rev 03 of the Conformance spec.) Seconded by Dana. Scott: But what's the difference between SP and SP Basic, then? Motion CARRIES by unanimous consent. Scott: MOTION to eliminate SP and rename SP Basic to SP, thus making back-channel name ID management OPTIONAL in all cases. Steve seconds. Motion CARRIES by unanimous consent. Steve: Doesn't see why the IdP introduction is MTI. Prateek: This is a relatively cheap feature that is annoying if absent. All: <sigh/> New agenda item: Readiness for Committee Draft vote next Friday Eve: Can all the editors get final drafts out by Friday end of day, for a Tuesday vote? Several people are on vacation this week, and the Conformance document is the one we're most concerned about. We can't leave it out. Some sentiment that we should put it through our last-call process in order to be consistent. But then, nothing in it tells people *how* to implement any of the profiles. Eve: If we do not have a successful Committee Draft vote on the entire spec suite next week, we will definitively miss the opportunity to go to OASIS Standard balloting by September 15 (though we might still miss that for other reasons even if we do have a successful Committee Draft vote next week). Scott: Let's target a Committee Draft vote August 17 but get Conformance (and everything else) into really good shape for review August 10. Still believes that the last-call process is just an IETF thing. All: agreed. [Quorate call adjourned; still a bit of discussion left] Prateek is available to chair the call next Tuesday. > 5. Other docs > > a. Technical Overview: PMadsen comments: http://lists.oasis-open.org/archives/security-services/200407/msg00162.html > b. Glossary upload notice from Jeff: http://lists.oasis-open.org/archives/security-services/200407/msg00168.html > · JLinn comment: http://lists.oasis-open.org/archives/security-services/200408/msg00008.html > 6. Action item review (see list below) > 7. Any other business > > 8. Adjourn > > 9. Focus call (if needed) > > > > Action Items: Report created 03 August 2004 01:45am EDT Everyone should send a reply to the agenda mail saying which items they've completed. > > > > ---------------------------------------------------- > > #0191: Need proposed text re: XACML Attribute proposal > Owner: Scott Cantor > Status: Open Closed (and discussed/accepted above). > ---------------------------------------------------- > > #0190: Need better text for NameIdentifier > Owner: Scott Cantor > Status: Open > > Assigned: 03 Aug 2004 > > Due: --- > > Comments: > > Rob Philpott 2004-08-03 05:41 GMT > > 27-Jul: re comments on core-2.0-draft-1 > > Scott – main item to be discussed is that we need some text up from better describing NameIdentifier. Not hearing any objections (on the list), Scott will, by the next call, work through them and incorporate as appropriate. > > *** AI: Scott to incorporate the notes > > > > ---------------------------------------------------- > > #0189: Incorporate ECP comments > > Owner: Scott Cantor > > Status: Open > > Assigned: 03 Aug 2004 > > Due: --- > > Comments: > > Rob Philpott 2004-08-03 05:38 GMT > > 27-Jul: Discussed detailed comments on sec 4.2 Enhanced Client and Proxy (ECP) sstc-saml-profiles-2.0-draft-17 > > http://lists.oasis-open.org/archives/security-services/200407/msg00144.html > > *** AI: Scott and Jeff will coordinate offline to incorporate the changes. > > > > ---------------------------------------------------- > > #0188: Update conformance document with focus call input > > Owner: Prateek Mishra > > Status: Open > > Assigned: 26 Jul 2004 > > Due: --- > > Comments: > > Prateek Mishra 2004-07-27 03:27 GMT > > http://lists.oasis-open.org/archives/security-services/200407/msg00134.html > > Rob Philpott 2004-08-03 05:29 GMT > > 27-Jul: Considerable dscussion took place at 27-Jul SSTC call; refer to minutes. Still open. > > > > ---------------------------------------------------- > > #0186: Proper use of URIs results in uniqueness > > Owner: Scott Cantor > > Status: Open > > Assigned: 26 Jul 2004 > > Due: --- > > Comments: > > Prateek Mishra 2004-07-27 03:23 GMT > > AI: Scott add something to Core around our use of URIs as identifiers in > > the spec, to explain that proper use of URIs results in uniqueness. > > > > ---------------------------------------------------- > > #0185: Rationalize presence of empty elements in schema > > Owner: Scott Cantor > > Status: Open > > Assigned: 26 Jul 2004 > > Due: --- > > Comments: > > Prateek Mishra 2004-07-27 03:22 GMT > > Scott to rationalize presence of empty elements in > > empty types in the schemas. > > > > ---------------------------------------------------- > > #0184: Send SSTC response to Thomas Grss paper to the author > > Owner: Prateek Mishra > > Status: Open > > Assigned: 23 Jul 2004 > > Due: --- > > Comments: > > Rob Philpott 2004-07-23 17:11 GMT > > Per 20-July con-call: AI: ultimately to provide a formal response to Thomas Gross. > > > > ---------------------------------------------------- > > #0183: Comment s solicited on John Linn response to Thomas Gross paper > > Owner: Prateek Mishra > > Status: Open > > Assigned: 23 Jul 2004 > > Due: 23 Jul 2004 > > Comments: > > Rob Philpott 2004-07-23 17:10 GMT > > Per 20-July con-call: Prateek (by July 23) to comment on the draft of John Linn's draft of our response to the Thomas Gross security analysis. > > > > ---------------------------------------------------- > > #0182: Use Conform. doc as entry point to docs > > Owner: Eve Maler > > Status: Open > > Assigned: 23 Jul 2004 > > Due: --- > > Comments: > > Rob Philpott 2004-07-23 16:59 GMT > > Per 20-July con-call: > > AI: Eve to write up a text section and a suggested new title for the Conformance document, reflecting this wider role (make the Conformance doc the official entry point of the doc set), and post these to the list. > > Rob Philpott 2004-08-03 05:31 GMT > > 27-Jul: merged in redundant AI #187: > > AI: Eve to write up a text section and a suggested new title for the > > Conformance document, reflecting this wider role, and post these to the list. > > > > ---------------------------------------------------- > > #0181: Explain that proper use of URIs results in uniqueness > > Owner: Scott Cantor > > Status: Open > > Assigned: 23 Jul 2004 > > Due: --- > > Comments: > > Rob Philpott 2004-07-23 16:46 GMT > > Per 20-July con-call: > > AI: Scott add something to Core around our use of URIs as identifiers in the spec, to explain that proper use of URIs results in uniqueness. > > > > ---------------------------------------------------- > > #0180: Need to update SAML server trust document > > Owner: Jeff Hodges > > Status: Open > > Assigned: 12 Jul 2004 > > Due: --- > > Comments: > > Rob Philpott 2004-07-20 01:59 GMT > > Original AI was for Eve to follow up with Jeff to determine whether he would be updating this doc. That was done. > > Discussion of this AI on 13-Jul indicates that the update will be a post 2.0 deliverable. Reassigned AI to Jeff for now. > > > > ---------------------------------------------------- > > #0179: Does conformance meet pki-cross-domain-profile-draft-01.doc requirements? > > Owner: Rick Randall > > Status: Open > > Assigned: 12 Jul 2004 > > Due: --- > > Comments: > > Prateek Mishra 2004-07-12 21:47 GMT > > CHeck conformance document to see if it captures the desired functionality described in this document. > > > > ---------------------------------------------------- > > #0176: Provide sequence diagrams for profiles > > Owner: Jeff Hodges > > Status: Open > > Assigned: 23 Jun 2004 > > Due: --- > > Comments: > > Rob Philpott 2004-06-23 20:14 GMT > > as discussed at F2F #5. > > Diagram for BAP sent to list. > > Rob Philpott 2004-07-23 17:03 GMT > > 20-July: Jeff - Will finish this week. > > > > ---------------------------------------------------- > > #0166: Investigate use of Wiki from teh web site > > Owner: Scott Cantor > > Status: Open > > Assigned: 22 Jun 2004 > > Due: --- > > Comments: > > Rob Philpott 2004-06-22 16:40 GMT > > Scott will investigate the establishment of a wiki for SSTC use to be linked from the SSTC web site. > > > > ---------------------------------------------------- > > #0163: Need process for submission of profiles/authn context classes, etc. > > Owner: Rob Philpott > > Status: Open > > Assigned: 22 Jun 2004 > > Due: --- > > Comments: > > Rob Philpott 2004-06-22 16:29 GMT > > On the web site, we need to state what the process is for submitting and dealing with additional authn context classes, new profile documents, etc. > > Rob Philpott 2004-06-23 16:03 GMT > > Note that this is different from AI 164 for SCott and John K to propose text within the spec documents that points to the web site. > > > > ---------------------------------------------------- > > #0160: Separate Privacy concerns language from Element/Attribute descriptions > > Owner: Prateek Mishra > > Status: Open > > Assigned: 30 Apr 2004 > > Due: --- > > Comments: > > Prateek Mishra 2004-04-30 18:14 GMT > > Jeff H - We need to highlight privacy considerations related to core, could be notes in core, could be section. > > *** AI: Prateek - will generate list potential changes from core > > Rob Philpott 2004-07-23 17:05 GMT > > 20-July: Still open. Eve: Note that the explanation of constraints on session indexes now includes a rationale along these lines. > > > > ---------------------------------------------------- > > #0158: Propose changes to definition of Federation in glossary > > Owner: Prateek Mishra > > Status: Open > > Assigned: 30 Apr 2004 > > Due: --- > > Comments: > > Rob Philpott 2004-07-23 17:05 GMT > > 20-July: Still open. Prateek will send thoughts to the list. > > > > ---------------------------------------------------- > > #0144: Explain optional subject decision > > Owner: Eve Maler > > Status: Open > > Assigned: 29 Apr 2004 > > Due: --- > > Comments: > > Prateek Mishra 2004-04-29 21:51 GMT > > *** AI: Eve: Optional subject implemented in core spec prose. Schema shows that subject is optional. > > o Eve: Has wanted to create a rationale for some of the decisions made on spec. Decision on subject less statements is a good example of what needs to be documented. Making an explicit design decision that is not really explicit on. By choosing to add prose to core spec we're making a stealth abstract profile (generic design decision) that applies to all explicit profiles. > > o Scott: data model (design) decision to require subjects in all SAML statements. > > Rob Philpott 2004-07-20 02:05 GMT > > 13-Jul con-call minutes note that the issue should be closed. and that Eve "may work on commentary". > > Rob Philpott 2004-07-23 17:02 GMT > > 20July con-call: > > Eve: The thought here was that we may have an optional post-V2.1 deliverable that explains the "XML rationales" for various things. > > JohnK: But there are selected places in the actual specs where it would be helpful; he has suggested these. Eve: Let's treat these comments one by one, then. > > Rob Philpott 2004-08-03 05:35 GMT > > 27-Jul: Per SSTC call: Still open. Deferred to post SAML 2.0 > > > > ---------------------------------------------------- > > #0125: Propose language to explain that AuthNResponse may contain attribute statements > > Owner: Prateek Mishra > > Status: Open > > Assigned: 16 Feb 2004 > > Due: --- > > Comments: > > Prateek Mishra 2004-02-16 14:46 GMT > > Easy to do but needs proposal on validity of assertion life-times as well. > > > > ---------------------------------------------------- > > #0123: Obtain MIME type registration for HTTP lookup of SAML > > Owner: Jeff Hodges > > Status: Open > > Assigned: 13 Feb 2004 > > Due: --- > > Comments: > > Rob Philpott 2004-06-23 15:29 GMT > > Attached is the initial rev of an I-D seeking to register the MIME media type > > "application/saml+xml". Please review. > > I've pinged the I-D editor to request a filename for the doc, I'll submit it to > > both the I-D editor and the SSTC doc repository once that's finalized (std > > procedure for I-Ds). > > In concocting this draft, I've noted that MIME media type registrations aren't > > necessarily the simple little registration exercise I'd thought they were. They > > (the ietf-types@iana.org denizens) may desire more content, e.g. sec > > considerations, in this doc. We'll see. Nominally, I think it's "good enough" > > as is, especially since the SAML spec sets have thorough sec considerations > > sections and I've referenced said spec sets carefully. Anyway, we'll see. > > Also, I based this on a draft registration for application/rdf+xml. In that > > draft, Aaron Schwartz claimed an optional parameter of "charset", and indicated > > that the considerations thereof are the same as for "application/xml" (as > > documented in http://www.ietf.org/rfc/rfc3023.txt). Additionally, he did the > > same thing for the "encoding considerations", i.e. said they were the same as > > for "application/xml". So, without excrutiating research, I did the same thing > > in this draft. fwiw/fyi. > > anyway, lemme know whatcha think. > > thanks, > > JeffH > > Rob Philpott 2004-08-03 05:33 GMT > > 27-Jul: * Scott – we need to do one for metadata as well. Roll the metadata one into AI #123. -- Eve Maler +1 781 442 3190 Sun Microsystems cell +1 781 354 9441 Web Products, Technologies, and Standards eve.maler @ sun.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]