[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [security-services] Minutes for SSTC Focus Group, Tuesday Dec 18
Agenda - OASIS SSTC Focus Group - Tuesday Dec 18 Dial in info: +1 334 262 0740 #856956 Attendees: Joe P Phill HB Hal L Steve A RLBob Gil P Scott C Jason R Emily Xu Prateek M Irving R Simon G Darren P Bob G Tim M Jeff B Thomas H Jeff H Chris M Agenda: 1. Review status of action items - and move to resolution 2. Conformance 3. JeffH’s last call process 4. RLBob’s resent email 5. SimonG’s email re: attr authority in assertions 6. ScottC: status codes 7. Adjourn > > 1. JeffH’s Last Call Process > - 5 documents for delivery are agreed upon - Want doc set substantially polished and basically at same "level" by 9 Jan - Conformance and sec-considerations docs require the most attention to meet schedule - Go into "last call" with status of "candidate committee specification" - Email includes interim milestone dates for bindings doc, but not core doc - How to fit Domain Model material into Core doc? - Phill will take material from latest version of Domain Model doc in repository and integrate - Joe would like draft no later than 3 Jan, preferably by 27 Dec - 27 Dec not very likely - Milestone set for 3 Jan - Risk remains with little time left between 3 Jan and 9 Jan for people to make comments - After 9 Jan, rest of schedule is tentative - Aggressively targets 1 Mar - If we make the 1 Feb date for close of Last Call, that leaves 2 weeks for public review and 2 weeks to adjust to comments during that review - These represent the latest dates possible to still meet the 1 Mar end date - Proposed methodology for determining whether Last Call has been passed - Editorial comments are not sufficient to prevent passing Last Call - Technical issues, which are sufficient, require champions - Raised issues may be challenged, otherwise the committee "buys into" the issue - If the issues go unchallenged, the doc doesn’t pass - JeffH again requests review of this Last Call process > > 2 -- Review status of action items - and move to resolution > > [A3: Phill] - Section 3.1.5, need to further define error cases > - Joe to Scott: Are error cases still open? - Scott: hasn’t communicated with Eve, believes they are still open - Phill familiar with the fact that there are not enough error codes defined, but not sure how to resolve yet - Issues - Phill: What level of detail to give to clients - Scott: Top-Level codes, their semantics and completeness - Joe: How close are we to closing this? - Scott has floated some ideas, but has only received comments from Rick Salz from the SOAP perspective - Scott has suggested re-organization to top-level codes, hoping to spark discussion, but discussion hasn’t happened - Joe: does anyone have strong feelings on this? - RLBob: comfortable with current state - Joe to Phill: what do you need to complete the next core draft? - Phill: need text - Need semantic description for error codes - Scott can enumerate what he did - SOAP doesn’t have status, it has Fault, so success code may or may not be appropriate - Failure, Error or Unknown isn’t clear enough - Not hearing anyone indicating they will have new codes to discuss by 9 Jan - Scott recommends starting with the smallest set possible at the top level - Joe would like comments on the alternatives between the proposals on the list - If no comments, power left to Phill and Eve to choose during editing - Status: we have proposal on table, open to comments, no consensus established > > [A5: BobB] - Section 4.1.3 472-473, text to clarify construction of > ID (w.r.t. uniqueness) > - Joe has not contacted Bob yet - stays open > > [A15: Chris] - Write up advice on how to use current approach to > generic slots for attributes > - Just waiting on integration into doc - Chris not sure if Eve has included yet or not - Joe to Chris: please sent note to list when you see it in draft > > [A18: Phill] - completion of error code specification for core > > Status: still open > - Same as [A3] > > [A20: Prateek] - Need for additional ConfirmationMethod identifiers > (Prateek and Phil) > - Prateek: wrt codes in section 5, has sent msg with constants and some text - Phill: can use URNs from RFCs from IETF where appropriate, and where they don’t already exist, we can make them up - Hal: you’re not talking about SASL codes, since you’re referring to URNs, so what are you referring to? - Phill: There's an RFC (RFC2648, informal, not on standards track) on how to use URNs to reference IETF documents - Hal: some things are defined in multiple RFCs - RLBob: or an RFC may define multiple things - Phill: we’ll have to just pick one RFC for each method - Hal: sounds reasonable as long as some text explains the approach - Scott: was there a previous issue from Eve over the use of URIs versus strings? - Need to ask Eve - Joe: We will re-confirm this in Jan > > [A22: Irving] - core line 752, return code for completeness specifier: > - Irving: Missed last concall, and it looks like there was some activity on this - Not sure if it takes away his action item - Joe: wasn’t re-assigned, but Scott & Eve have been contributing - Scott: could be relegated to a second-level code - Irving: msg in question was on 12 Dec - Irving: thinks BobB was biggest supporter of Completeness specifier, but there were others at that F2F - Joe: anyone else feel strongly about this? - None - Joe: directs Phill (and Eve) to go ahead and integrate this change > > [A24: Phill] - Bring together Tim's etc. text for the Authentication > mechanism section. > - Still open, for tracking > > [A26: Phill] - text on the <RespondWith> option voted for at F2F#5 > - Phill has updated the schema for this - Believes he updated core - Stays open > > 3. Conformance, BobG > - Three fundamental issues - How do we categorize conformance? - How do we specify mandatory vs options? - How do we specify proof of conformance, e.g. test cases - "How do we categorize conformance?" - Originally based on entities in domain model - Over time, has concluded this to be insufficient, as domain model has become non-normative, and instances of overlap on assertions used has increased - Has kept this proposal, but has also introduced new model, based on assertions - New approach includes notion of levels and considerations to bindings and profiles - << DISTRACTED HERE >> - any objections to this approach? - Phill likes it, as they aren't going to implement all of it, for example - Hal not so sure - Prateek prefers a binding/profile-first approach - General concern with vendors implementing bits and pieces, but not being interoperable - There is great detail in the bindings doc about what is required to implement a given binding or profile - Finer level of granularity appropriate for bindings, but should go into conformance doc - Scott: so if I build a toolkit, would it be compliant, or would I have to built a running product in order to claim compliance? - Hal: the latter, since his customers really are interested in products that interoperate - Any concerns over taking a binding/profile-first approach? - Proposal: allow an app claim conformance with any of the bindings or profile, and underneath that, they can claim the assertions they support - BobG will write this up and send to list for discussion - There won’t be time for group discussion of this before 8 Jan, but if anyone wants to discuss prior to that, they can contact BobG - Discussion of mandatory bindings/profile - If a vendor has no use for SOAP binding, why must it be required to be in their product? If it can’t be turned off, does it leave door open for potential attacks? - Prateek: ok with not requiring any binding/profile, but leaves strange feeling over basic interop if no basic binding/profile can be counted on - Gil: how can consumer look on side of box and determine interoperability? - RLBob: still large amount of work done outside of SAML to ensure interop between systems - Sounds like this SOAP binding is useful to require, true? - Darren: not convinced. Even thinks Hal had mentioned only implementing the SSO aspects, which doesn’t seem to imply all of SOAP binding - JeffB: what happens in future when there are more bindings? - We’ll have to revisit this in the future - Any objections to moving forward with proposal? - None - Mechanism for specifying conformance - One is a black box of tests - Another is a specification of scenarios and test cases - BobG proposes that he proceed with generating that specification - Doesn’t think there is time to develop the black box tests - Any issues with this proposal? - None - [ACTION] BobG to send out proposal by end of this week on this topic - There will be a meeting on Friday 4 Jan for anyone wishing to review > > 4. SimonG’s Authorization Authority Proposal (evolved into > discussion of process for issue handling) > - Simon had sent msg to list already, proposing authN assertions with a list of authorities that the cliet must check with - Not sure if people have read it - Joe suggests Simon resend it - JeffH: is there an open issue? - Simon: at F2F, it was deemed that there was not enough text to consider, and now there is - JeffH: There should be a high level issue around this - Chris: the issues have revolved around submitting text, not whether the text should go into the spec - Scott: there are two others in a similar situation - Joe: champion has to push it until it gets agreed to - JeffH: our mechanism should change, adding issues for discussion when solid text is proposed - This will get worse in the last call process if the process doesn’t change now - RLBob: based on this, he has three issues to champion - Via email, Joe will contact Hal to manage this - [ACTION] Joe to contact Hal concerning: - What is the outlook for updating issues doc - Does he agree that once proposals are solid, should they become issues - Can he do overall sweep of list of issues so that issues doc is the singular source for issues? - RLBob will help with identification of his proposals - Prateek thought there was some level of agreement to RLBob’s proposals already - These were unusual because at the F2F, they were agreed to initially, but then group became uncomfortable with agreeing to something without complete text - Prateek already modified bindings doc to incorporate RLBob’s proposals - Joe: do not roll back, send reminder to list of original agreement and the tie to this completed text - Noted that the group needs to approve several proposals very soon in order to get them into 9 Jan drafts - Since no call is scheduled before 8 Jan, much of this will have to be handled on list > > 5. Adjourn > - Adjourned -- Steve Anderson OpenNetwork Technologies sanderson@opennetwork.com 727-561-9500 x241
begin:vcard n:Anderson;Steve tel;fax:727-561-0303 tel;work:727-561-9500 x241 x-mozilla-html:FALSE url:www.opennetwork.com org:OpenNetwork Technologies version:2.1 email;internet:sanderson@opennetwork.com title:Product Architect adr;quoted-printable:;;13577 Feather Sound Drive=0D=0ASuite 330;Clearwater;Florida;33762;USA x-mozilla-cpt:;-15216 fn:Steve Anderson end:vcard
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC