[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [security-services] Minutes for Telecon, Tuesday 14 May 2002
Minutes for SSTC Telecon, Tuesday 14 May 2002 Dial in info: +1 334 262 0740 #856956 Minutes taken by Steve Anderson > > > 1. Roll call > - Attendance attached to bottom of these minutes - Quorum achieved > > 2. confirm submission to Oasis goal on June 1 > - [minute-taker arrives late, with apologies] - deadline for getting attestations? - Jeff: can probably take them right up until end, but sooner is better - Simon: what is definition of "having working version" - Jeff: somewhat vague - Simon: so participation in interop would suffice? - Jeff: sounds true - Scott: had understood that just demo implementation wasn't sufficient - Irving: but doesn't have to be on price list - Jeff: if you know in your heart that it's throw-away, that won't do - Scott: Internet2 should have some attestations by then - Jeff: let's say timeline is by 31th May [decision changed later in call] - Jeff: we've jumped ahead in agenda, but sounds like submission goal is still intact > > 3. IPR reminder > - just a reminder, if you have any claims, get them in > > 4. attestations - > > Here's the current consolidated state of the "implementation > attestation matrix" > > Requester of AuthN by means of SOAP-over-HTTP binding 1 > Requester of AuthZ by means of SOAP-over-HTTP binding 0 > Requester of Attrib by means of SOAP-over-HTTP binding 2 > Responder returning AuthN by means of SOAP-over-HTTP binding 2 > Responder returning AuthZ by means of SOAP-over-HTTP binding 2 > Responder returning Attrib by means of SOAP-over-HTTP binding 2 > Browser/artifact profile consumer 3 > Browser/artifact profile producer 3 > Browser/POST profile consumer 2 > Browser/POST profile producer 2 > > We need more attestations to fill this out! Please send > attestations to Joe & Jeff. > - partially covered on call already - we definitely are short, esp in AuthZ Requesters - don't hesitate sending them in, having more than minimum will help chances of getting spec approved - heard from Baltimore, Entegrity, Internet2, Oblix, Netegrity, Sigaba - if you can update additional rows of coverage, that will help - Emily: need to understand what "requester" is, and whether an API qualifies - Prateek: Netegrity believes so, as an API does go through testing to ensure correct functionality wrt SAML - Emily: then Sun will have attestations to contribute - Don: their product uses the assertions, but in the mid-tier, so they don't fit into the matrix - Irving: test matrix is more profile driven - Hal (to Don): are you using request protocol? - Don: yes, but not over the standard binding - Hal: our focus was on interop, which drove the matrix as it is, but we should have 1 additional category of just using assertions - Hal: don't want lots of categories because of need to have 3 attestations for each - Jeff: so we want to create 3 (maybe 6) new rows to cover creation of assertions over any binding - Don: we are using request/response protocol, just not over SOAP/HTTP - Jeff: so everyone that has checks in current rows will automatically be able to check these new rows, where someone like - Eve: was told that if an implementation didn't provide the SOAP/HTTP binding, it wasn't SAML compliant - Hal: that was driven by interoperability, but this case is driven by use - Eve: fair enough - Hal: motion to create 1 new row that is for other uses of SAML assertions not covered by the above - Eve: we're probably obsessing over this more than anyone ever has, and OASIS just wants to see traction - - Prateek: this raises the bar higher for getting attestations - Scott: but everyone who has checked off rows already will be able to check off this new row - Steve: so amend motion to say "... uses of SAML assertions covered above or otherwise" - Jeff: Hitachi appears to be the only ones in this position - Hal: Systinet, Crosslogix and others are in this spot - Jeff: time is getting tight, and we don't want to hinder our case - Don: could amend to just say "... uses of SAML assertions" - Hal: for purpose of OASIS attestation, we've already raised the bar - Eve: for OASIS, we can just provide the complete set of companies that are using the standard and, for further detail, a breakdown of how - Hal: will accept that as friendly amendment - Jeff: do we want to mention request/response in addition to assertions? - Steve: even mentioning assertions is being too specific, based on the direction we're taking this - Jeff: so new wording might be "use of SAML specification in some fashion" - Hal: how about just "other"? so if you want to see the list of companies, just look at the matrix edge showing company names - Jeff: what to you think, Eve? - Eve: sounds fine, don't over-engineer it - Jeff: so we can present to OASIS "here is the list of companies that are using the spec, and the table below represents a breakdown of how they're using the spec" - Hal: sounds like we're in general agreement, and we're just word-smithing > > 5. schedule a date for the vote to submit to Oasis. (our next conf > call on 5/28?) > - Jeff: we need the attestations by 5/27 to be available for the vote on the 5/28 conf call - no objections to voting on submission of document set to OASIS on 5/28 - note that 5/27 is Memorial Day in the US > > 6. editorial issues to be addressed before submission to OASIS > > Potential errata on the Committee Specs to date > Eve Maler > < http://lists.oasis-open.org/archives/security-services/ > 200205/msg00022.html > > > Eve is stating a errata submission cutoff date of 5/28 > > > Possible resolutions to some errata items (at least: PE1, PE7, > PE8, PE12, PE13) potentially affect schema. Require engaged > consideration. > > Decide on process for accepting (or not) errata items. - Eve: we should discuss general principles to handling these before going through them - the schema is the most normative, since it is machine-readable, and we agreed to freeze the schema so people could start implementing against them, so we generally have to consider impact to changing the schema vs. violating the agreed-upon intent - Hal: instinct would be to change them - some could have been coding to the intent, and some could have been coding to the schema - Jeff: if anyone is dead-set against changing the schema, speak up now - Eve: there are 3 representations of schemas, and even these aren't always consistent, so it's not just a case of schema vs. prose - Eve: sounds like we'll take these on a case-by-case decision and bounce them off the SAMLDev list - going through list - PE1 - Eve moves to accept option 2 - [VOTE] no objections, passes - PE2 - Eve moves to accept option 1, and to add to comments in schema files - [VOTE] no objections, passes - PE3 - Scott's affiliation info should change like RLBob's - Eve moves to accept option 1 - [VOTE] no objections, passes - PE4 - want to address editorial issue first, then potential issue - Eve moves to accept option 1 - [VOTE] no objections, passes - should have someone take action to review Ken's comments and provide feedback by next call on 5/28 - [ACTION] RLBob will review - PE5 - there are 2 cut-and-paste errors here, as Jeff noted this morning - Eve moves to accept option 1 (which Word numbered as 3), which is to make this change - [VOTE] no objections, passes - Prateek: (getting back to PE4) he responded to Ken, and in short, there is not issue - RLBob will review as part of his action item - PE6 - not a schema change, but almost as bad as a schema change - evenly split on implementations using Sender/Receiver vs. Requester/Responder, but all indicate that it is easy to change - Eve moves to accept option 1 (which Word numbered as 5), which is to make this change - [VOTE] no objections, passes - PE7 - since there is an inconsistency, there is no option to do nothing - Jeff: so options 1 & 2 only affect prose, but 3 also affects schema - Eve: it is arguable whether our decision to limit to one instance of Evidence in AuthorizationDecisionStatement also applied to AuthorizationDecisionQuery - would be somewhat inconsistent to allow multiples in 2nd case but not in first, and at a minimum we'd need to add wording stating no additional semantics on statements in multiple Evidence instances vs in a single instance - Bhavna moves to accept option 3 - Don: more concerned about performance impact - [VOTE] no objections, passes - PE8 - Eve believes our intent was to make them required - Irving: name is certainly required, but namespace perhaps isn't - Eve: didn't provide an option for this, adding option 3 - Prateek: recalls some discussion of dangers of optional namespace, and in the absence of compelling reasons to make it optional, leave it required - Scott: had to define a dummy value - Eve moves to accept option 1 - RLBob: pushes problem out to designers to come up with placeholder namespaces - Scott: would love to see SAML define a URI - Irving: had fought previously to use URN, but lost then, but we're hearing now that implementers are struggling with it - Eve: could change prose to include some recommendation with a magic namespace value - Irving: it would be beneficial to have one that says "this is a DSML LDAP attribute" - RLBob: would prefer to not do it halfway, given our timeframe - [VOTE] no objections, passes - PE9 - Eve moves to accept option 1, specifically line "Schema is normative, with the actual schema module taking precedence" - [VOTE] no objections, passes - RLBob: moves to remove duplicate schema listing in core section 8.1/8.2, replacing them with a pointer to the xsd file - Eve: Phill is not on call, and he really likes keeping them as is - Phill will be back on 5/20, so Eve will get with him then - motion tabled, and new PE16 added - PE10 - Eve moves to accept option 1 to make change - [VOTE] no objections, passes - PE11 - Eve moves to accept option 1 to make change - [VOTE] no objections, passes - PE12 - Eve doesn't recall intent - RLBob: sure it was to be required - Eve moves to accept option 1 to make changes - [VOTE] no objections, passes - PE13 - Eve moves to accept option 1 - [VOTE] no objections, passes - PE14, PE15 and PE16 have been added, and we'll have to discuss on next call - Jeff: we could have call next week to discuss errata, though not in this timeslot, since SAMLDev is using it - will discuss need for call on list > > 7. Adjourn > - Adjourned ----------------------------------------------------------------------- Attendance of Voting Members: Irving Reid Baltimore Krishna Sankar Cisco Hal Lockhart Entegrity Carlisle Adams Entrust Don Flinn Hitachi Jason Rouault HP Marc Chanliau Netegrity Chris McLaren Netegrity Prateek Mishra Netegrity Charles Knouse Oblix Steve Anderson OpenNetwork Rob Philpott RSA Security Jahan Moreh Sigaba Bhavna Bhatnagar Sun Jeff Hodges Sun Eve Maler Sun Aravindan Ranganathan Sun Emily Xu Sun Bob Morgan UWashington Attendance of Observers or Prospective Members: Ronald Jacobson Computer Associates Robert Griffin Entrust Simon Godik Crosslogix Membership Status Changes: Ronald Jacobson Computer Associates - granted voting status after call -- Steve
Attachment:
sanderson.vcf
Description: Card for Steve Anderson
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC