[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [security-services] draft minutes SSTC/SAML concall Tue9-Sep-2008 with attendance
> -----Original Message----- > From: ' =JeffH ' [mailto:Jeff.Hodges@KingsMountain.com] > Sent: Tuesday, September 09, 2008 2:39 PM > To: OASIS SSTC > Subject: [security-services] draft minutes SSTC/SAML concall Tue 9-Sep- > 2008 [lacks attendance] > > > ========================================================================== > == > SSTC/SAML concall Tue Sep 9 09:00 PDT 2008 > -------------------------------------------------------------------------- > -- > > AI Summary: no explicit AIs issued this meeting. > > Attendance: [to be supplied] > > Hal Lockhart (hl) presided. > > > Need a volunteer to take minutes > > Jeff Hodges (jh) volunteers. > Attendance Voting Members George Fletcher AOL John Bradley Individual Jeff Hodges Individual Scott Cantor Internet2 Nathan Klingenstein Internet2 Tom Scavo National Center for Supercomputing Applications Frederick Hirsch Nokia Corporation Srinath Godavarthi Nortel Ari Kermaier Oracle Corporation Hal Lockhart Oracle Corporation Brian Campbell Ping Identity Corporation Anil Saldhana Red Hat Eve Maler Sun Microsystems Duane DeCouteau Veterans Health Administration David Staggs Veterans Health Administration Members Kent Spaulding Tripod Technology Group, Inc. Brett Burley Veterans Health Administration > > > 1. Approve minutes from August 26, 2008 > > http://lists.oasis-open.org/archives/security- > services/200808/msg00090.html > > hl: prior minutes approved by unanimous consent > > hl: anything to add to agenda ? > > dave staggs (ds): please add XSPA profile discussion to agenda > > hl: will do at end > > > > > 2. Document Status > > > > 2.1 Subject-based Profiles for SAML V1.1 Assertions > > http://wiki.oasis-open.org/security/SamlSubjectProfiles > > > > Voted to request CS vote of revised document - ready as of Sep 7 > > http://lists.oasis-open.org/archives/security- > services/200809/msg00013.html > > > > Action deferred pending resolution of reference to XML Signature (Second > Edition). > > http://lists.oasis-open.org/archives/security- > services/200809/msg00014.html > > > hl: got comment on the doc at 11th hour -- ought to ref xmldsig 2nd ed. > > ways to handle... > > 1. don't do change > > 2. can vote to cd if we agree to do the change (it's editorial?), then do > change, then goto CS vote w/o another pub review > > 3. made changes, redo pub review, then do CS vote > > > scott cantor: what's being raised? > > hl: there's a footnote ref to the spec, and where that spec is actually > used > is on ref'g the namespace in pg 6, that's it > > sc: mebbe we shoudn't deal with it because the namespaces are the same in > both > xmldsig specs > > fredrick hirsch (fh): just refer to 2nd edition -- because there's an > additional required alg in the 2nd edition -- be good for readers > > hl: change xmlsig to xmlsig1 .... > > sc: if i was editor I'd say this was a waste of time > > jh: concurs > > sc: there's no ambiguity... [tom scavo(ts) concurs] > this spec doesn't use xmldsig actually > xmldsig shows up in examples only, arguably it should be ref'd in > non-normative refs rather than footnote > and.. we have five other specs where it is normative and we are going to > update them formally > > > hl: resolution is we are going to continue with what we agreed to in last > meeting, and so chairs are going to req CS vote on this spec, and folks > can > expect that in next week or so. > > > > > 2.2 SAML V2.0 Metadata Interoperability Profile > > http://wiki.oasis-open.org/security/SAML2MetadataIOP > > Draft 2 posted > > http://lists.oasis-open.org/archives/security- > services/200809/msg00003.html > > sc: went through this spec and made updates wrt comments (many by TS) > probably some examples that can still be put in, but wanted to get text > updated first > changes should match > > added placeholder for defining x509cert element in keyinfo but value > syntax > isn't defined and so believe that that is errata for xmldsig spec... > > I am participating in the w3c xmlsec working group as invited expert and > will > perhaps raise it there > > I assume everyone puts a DER-encoded cert value in there, but it should be > nailed down, because it could be some other encoding, and it prob should > be > nailed down in xmldsig spec(s)... > > > hl: other approach would be to put a type field in cuz they do sometimes > come > in diff formats, and so (agree) that it isn't inherently obvious which > format > to use... > > sc: so put placeholder in the draft to accomodate this... > > fh: agree that xmlsec wg should look at this, what's timing? > > sc/hl: we've been living with the xmldsig spec as it is for a long time, > so > this is not really urgent > > sc: can finess this in our spec, i have placeholder, etc > > hl: so, (to pop the stack) -- folks should comment on the spec overall on > the > list so we can move this forward... > > > > > 2.3 SAML V2.0 Holder-of-Key Assertion Profile > > http://wiki.oasis-open.org/security/SAMLHoKSubjectConfirmation > > Draft 3 posted. > > http://lists.oasis-open.org/archives/security- > services/200809/msg00008.html > > tom scavo (ts): quite a few changes made in this draft > five issues were addressed, summarized in this message... > > Re: issues with sstc-saml2-holder-of-key-draft-02 > http://lists.oasis-open.org/archives/security- > services/200809/msg00017.html > > at least four of five adequately addressed, one of them, processing the > x509 > cert element, needs to be discussed > > would like to know how folks are doing it now, way I have it now seems > reasonable, not sure where other suggestion is coming from... > > sc: it is not operationally simpler, but it is (seems) to be simpler impl- > wise > > I don't want to create spurious failure conditions when xaction should > succeed. so by doing key comparisons rather than cert comparisons whenever > possible, it maximizes operational utility [without compromising security] > > ts: if you want to do that, should use other element x509ski... > > sc: that value is a hash, what i'm reducing it to is key value, haven't > seen > anyone use x509ski, haven't seen any support of it in reality, so am leery > of > using it > > ts: it seems your suggestion violates the spirit of xmldsig, which has two > elements, one for cert another for key... > > sc: it's correct imho cuz xmldsig spec doesn't firmly spec the op > semantics > > hl: tends to agree > > sc: keyvalue is problematic otherwise would use it > focus for me is sec of xaction, and writing processing rules that won't > compromise that > > > hl: other comments, others familiar with impls? <silence> > > how to resolve? > > sc: I don't have prob with profile, as long as processing rules are clear, > am > a little leery of skewed processing rules; operationally speaking since > assertions are shortlived, am inclind to believe that the op issue I run > into > wrt metadata aren't as applicable here -- my principle objection prob > isn't a > big deal in this context. would prefer it to be the other way, but that's > just > me speaking as an implementer > > ts: let's leave this discussion open on the list and see what others think, > I > don't feel terribly strongly about it, could go other way, if this is > hangup > to spec progressing might let it slide, will do some wider research > [beyond > sstc] and see what folks think > > sc: will do more thorough review...but in skimming, see some things like > SubjectName procesisng, prob need to say more concrete things about how > PKI is > wired in, etc... > > hl: ok, folks should read and take comments to list > > > > 3. Discussion Threads > > > > 3.1 Non-browser HTTP binding for SAML > > http://lists.oasis-open.org/archives/security- > services/200808/msg00082.html > > hl: any work items that will come out of this? status? > > geo fletcher (gf): didn't seem there was much interest from community, > just > scott & me... > > sc: have interest in gen area, doubt is a saml binding, is really an http > issue, almost a "saml token profile" for REST -- see that as the use case > rather than casting it as a SAML binding > > eve maler (em): have been talking in Sun, put that way, is more true > > gf: summarize: sec msgs within http msgs, so why not OAuth? > > sc: understand OAuth does some signing, so u might be right.. > > gf: can use OAuth to pass saml msgs, so mebbe heading in that direction in > a > more general sense... > > em: have been talking with various folks circling around this topic, let's > chat offline... > > gf: ok > > > > 3.2 Attestations from Internet2 > > http://lists.oasis-open.org/archives/security- > services/200808/msg00089.html > > hl: anyone who has posted an attestation for something in the process, > might > need to update the attestation to spec which conformance clause one is > attesting to -- please > > eg, see what ScottC did, it isn't onerous, please follow suit if > appropriate/applicable > > > > > 3.3 compatibility of HoK profiles > > http://lists.oasis-open.org/archives/security- > services/200809/msg00000.html > > Nate Klingenstein (nk): have had back channel conversation, figured out > way > forward, involves x509 and [?], still haven't figured out metadata stuff; > Tom > also commented that hack to figure out which profile to use isn't general > enough, agree, not sure how to take forward > > ts: will read and reply, agree metadata messy, if you piggyback on > assertion > profile, attach some data in request, have tried to do it, it is difficult > because subject elements appear in lots of reqs for diff purposes, so > would be > great if you addressed that issue in your profile > > nk: no intention to address it, because of impl concerns > > ts: so if you attach this meaning to subjconf in request, then IDP would > be > reqired to honor it, if it isn't there, then default would be x509 cert > option > -- would that work? > > nk: that's fine except for the idp-first use case, we can hack it > specificlly > in this case, but such an approach isn't general, hence leery. > > ts: so the assertion profile mandates x509 > > hl: so sounds like resolution is to be more explicit in next draft? > > nk: would rather rely on assertion profile spec for this... > > ts: can't cuz have taken everything like that out due to SC's req... > that's what meant when said it is difficult > could write a [shim] profile to address it... (ugh) > > nk: ugh > > hl: please take further discussion to the list > > > > 3.4 comments re sstc-saml-holder-of-key-browser-sso-draft-06 > > http://lists.oasis-open.org/archives/security- > services/200809/msg00001.html > > hl: ts has 2 msgs with comments on the doc > > ts: nothing further to say -- it's in email > > > > > 3.5 [added agenda item] Dave Skaggs -- XSPA Profile > > ds: am at hipspi [?] financial conf right now, talking about our profiles > here > > will update the profile, cut back some of the HIMS/health specific stuff > in > it, and want to turn the doc into a tangible committee draft > > i.e. have this done by the 2009 meeting, can feature it there, have demo, > etc, > it'll be a big deal > > XSPA TC will be meeting this friday, want to firm up the portion thats > talking > about SAML > > want to turn it into a committee draft (CD) > > have folks read it? do you have feedback? > > hl: two docs? > > ds: saml xacml profile is in SSTC, will be combined with another spec > that's > in the XSPA TC > > hl: it just takes a vote of the TC to make it a CD > > ?: turning into a lightweight profile for > Dewyane Ducuto > > hl: is it in docs repository in Kavi? > > DD: yes > > hl: CD is a low bar, i.e. no one on TC is actually objecting to it as it > stands, but want folks to have notice and time to review, so if you can > get > doc out this week maybe we can goto CD during an upcoming TC > concall/meeting > > ts: don't see doc in kavi... > > dd: in kavi in June... > > hl: checking for it in personal archive.... > > jh: have xspa-saml-profile2008428_V31.doc from April in local cache > > dd: that's old... > > hl: so if you're publishing in next few days, put it in the "A.5: Post- > V2.0 > Working Documents" section of the doc repository, ask for review on the > list > and modulo discussion we can have a vote at the appropriate next TC > meeting > and make it a CD > > ds/dd: ok, will do > > > > > 4. Other business > > > > > > 5. Action Items (Report created 08 September 2008 10:27pm EDT) > > > > #0328: Revise SimpleSign > > Owner: Jeff Hodges > > Status: Open > > Assigned: 2008-05-19 > > Due: --- > > underway, still open > > > > #0332: Revise Query Extension for SAML AuthnReq > > Owner: Sampo Kellomki > > Status: Open > > Assigned: 2008-05-19 > > Due: --- > > open > > > #0333: Publish a new revision of Profile for Use of DisplayName in OASIS > template > > Owner: Sampo Kellomki > > Status: Open > > Assigned: 2008-05-19 > > Due: --- > > open > > > #0341: Draft text for SSTC submission to NIST > > Owner: > > Status: Open > > Assigned: 2008-08-26 > > Due: --- > > hl: no owner? > > brian campbel: I believe this should be eric tiffany, will fix the action > item > > > > ========================================================================== > == > > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]