[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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. > 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 ============================================================================
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]