[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [security-services] sstc/saml concall minutes Tue 2-Dec-2008 (withattendance)
Jeff, I just wanted to thank you for picking up the note-taking task so often. I promise I'll be more forthcoming with offers in future, and I hope others consider doing so as well. Eve On Dec 2, 2008, at 4:14 PM, =JeffH wrote: > comments to the list please. > > =JeffH > > > = > = > = > = > = > = > ====================================================================== > SSTC/SAML concall Tue Dec 2 09:03:19 PDT 2008 > ---------------------------------------------------------------------------- > > co-chair Brian Campbell (bc) presiding > > ---------------- > Motions passed: > > Resolved: PE74 is approved errata item now > > Resolved: place xspa-saml-profile-cd-01 into 60-day public review. > > > -------------- > Action Item Summary: > > * AI: Duane DeCouteau (dd): will take AI to do packaging of > xspa-saml-profile-cd-01 for public review > > * AI: SSTC co-chairs will notify TC admin once receive spec pkg from > Duane. > > > ----------------- > Attendance: > > > Voting Members > ------------------------------ > George Fletcher AOL > John Bradley Individual > Jeff Hodges Individual > Scott Cantor Internet2 > Nathan Klingenstein Internet2 > Bob Morgan Internet2 > Tom Scavo NCSA > Frederick Hirsch Nokia Corporation > Srinath Godavarthi Nortel > Hal Lockhart Oracle Corporation > Brian Campbell Ping Identity Corporation > Anil Saldhana Red Hat > Eve Maler Sun Microsystems > Emily Xu Sun Microsystems > Duane DeCouteau Veterans Health Administration > David Staggs Veterans Health Administration > > Members > --------------------- > Peter Davis, Neustar > Rob Philpott, EMC > > Observers > ---------------- > Greg Parsons Jericho Systems Corporation > > Quorum: 16 out of 20 voting members (80%) > > Membership Status: Ari Kermaier (Oracle) lost voting status. > > > -------------------- > detailed minutes: > > >> Roll Call & Agenda Review >> >> Need a volunteer to take minutes > > =JeffH (jh) volunteers > >> 1. Minutes from SSTC/SAML conference call November 18, 2008 >> http://lists.oasis-open.org/archives/security-services/200812/msg00000.html > > bc: the minutes were just posted to the mailing list so we'll wait > until next > call > to approve them. > > >> 2. Document Status >> >> 2.1 SAML 2.0 Errata draft 45/46 -> PE73, PE74, PE75, PE76, PE77 / >> PE78 added >> http://lists.oasis-open.org/archives/security-services/200811/msg00071.html > > > Scott Cantor (sc): am making motion to accept PE74 as proposed in > errata 46 > > fh: 2nds the motion > > discussion... > > Rob Philpott (rp): xmldsig is also mentioned/ref conformance doc... > bc/sc: that's covered > rp: ok, as long as this updated spec doesn't change anything in > conformance > spec > sc: all algs & references are not changed > do we norm ref the canonicalization specs? > <exclusive c14n is referenced> > > rp: we say SHOULD use excl but don't say anthing about other c14n > approach > ok, looks good to me, don't see need to postpone > > > bc: back to motion, any obj to unan consent of approving PE74 ? > none, motion passes. > Resolved: PE74 is approved errata item now > > > bc: moving on to PE75.. > > rp: the text shd be more specific with respect to 2nd level error > codes > > sc: 2nd level codes aren't something needing to be nailed down > interop-wise -- > this > is a abstract situation > > rp: but there's various reasons subject may not match... > > sc: it doesn't seem to be worth the amount of work it'd take to do it > > tom scavo(ts): don't feel strongly, what sc has in the errata > currently is fine > > rp: are we going to allow implementors/deployers to stick in other > 2nd level > error > code values? > > sc/bc: yes > > sc: this is a really abstract error condition, this is more > discussion than > wanted to have, shd take this to the list not sugg we vote PE75 > in today > anyway > > pe76 -- wrt validity attrs, suggesting additional txt on that > folks shd read that one and see if you all agree > > pe77 -- wrt adoption of saml assertions in ws-fed context -- but we > can > make some constrained changes that would address the prob > e.g. if we remove word "saml" in various places it fixes it all > it seems > > > pe78 -- want to discuss this... > > persistent nameid format -- whether or not by definition if those > ids can be > reassigned to other principals -- applicable in federation use cases > imho in no situation reassign opaque ids to other principals, i.e. > "must not" > be done so suggest either "must not" or "should not", favors "must > not", > modulo > what others think > > Eve Maler (em): this is a bit of a stretch for an erratum > is there some usefulness in reassign opaq ids? > > sc: absolutely not > > em: totally breaks the traceablility of ids (which might be what > someone > wants)... > > sc; these are explicitly persistent ids not transient > > em: oh, ok, but not sure we should do this at this point > > ts: am bit surprised this is coming up as erratum, like eve, > there is something btwn "shd not" and "must not" eg "must not be > reassigned > for > a year".... > > jh: dont think this is good idea > > [ detailed discussion ensued with rp equating persist ident > reassignment with > notions of opaque identifier randomness, jh noting that those are > seperate > notions, others chiming in ] > > sc: in anycase these proposed changes are simple > > always thought it is a "must not" > > came up in Shib context via Tom (ts), then realized the saml spec > doesn't > say anything > > don't know of any reasons to reasign persist idents, my intent (when > originally > writing that language in the spec) is that it is a "must not", don't > believe it > is material change to make it that, but am fine with "should not" > > bc: this is something that was intended but isn't really clear, a > "shd not" is > easy > and nice but a "must not" might affect various impls/deployments > > in any case we shd take this to the list... > > sc: am not aware of any errata items that are not in the errata doc > at this > time, > so if folks know of any they need to speak up. > > >> 2.2 SAML V2.0 Metadata Extension for Entity Attributes (draft 2) >> http://lists.oasis-open.org/archives/security-services/200811/msg00079.html > > sc: wrt attaching tagging info to entities that they admit into a > federation, > have done some draft work on this notion, but now am proposing a > formalization > of it > > [from draft spec abstract: > This profile defines an extension element for use in attaching SAML > attributes > to an <md:EntityDescriptor> or <md:EntitiesDescriptor> element, to > communicate > an arbitrary set of additional information about an entity in its > metadata. ] > > bc: am confused about details > > sc: orig proposal is wrt saml attributes, they aren't self- > describing wrt > signature > over metadata, there is a sense in our community that folks will do > it non > interoperably > > if asking "why not use assertions?" -- that's hard > > did try to come up with assn profile that's constrained but it's > difficult, > see the > draft spec. > > bc: is there a way to take the attr part out and simplify assn > portion so it > meets your needs? > > sc: don't know. if you take the attr fork out, you don't make it > easier to > impl, the > assn part is hard to impl -- if there's enuff interest in this to > make > 1 > prof > of it, am happy to discuss/investigate. > > > bc: let's take discussion to the list > > >> 2.3 SAMLv2.0 HTTP POST ³SimpleSign² Binding >> http://lists.oasis-open.org/archives/security-services/200812/msg00005.html > > jh: summarizes the delta between this draft spec and the present > Committee > Spec (CS) edition. > > [discuss whether want to update the CS version, jh: that's the > intention] > > [discuss wrt pub review. HL notes there's an escape clause to allow > for 15-day > pub review.] > > ts: did a diff on the docs, will send to jh > > bc: we will endeavor to vote to pub rev next call > > >> 2.4 XSPA Profile of SAML for Healthcare >> To public review? > http://www.oasis-open.org/committees/download.php/29921/xspa-saml-profile-cd-01 > .doc > > ds: HITSP/HIMSS folks have noted to ds that they'd like to see public > review of this profile before the HIMSS demo in Apr > > ds: moves that we take the xspa profile from cd and take it to 60day > pub > review. > > hl: 2nds > > discussion... > > hl: what's the rel of the xspa profile(s) to other stds ? > > ds: there's 2 -- one for international, another for US realm > > the US realm one is more specific as to the use of certain vocabs > that > allow > interop btwn health care entities > > there's another profile that's xacml-based > > haven't gotten feed back on ws-trust profile from ws-sx TC > > > hl: does the overall one ref the other ones (3 of them?) ? > > ds: the overall one refs the underlying one > > to know whole story need all 4 docs > > ws-trust and xacml are optional > > saml profile is really required one > > "overall one" -- is in xspa tc and hasn't been publicly released yet > > need to join xspa tc to see docs, encourage folks to do so > > > bc: does it make sense for sstc to be doing this considering that > there is a > xspa tc? > > ds: guidance from jamie clark et al was that the saml profile should > be done > where > there is saml expertise > > > bc: back to motion, any further discuss? (none) > > bc: any obj to unanimous consent to moving > profile to initial 60 day pub review? hearing none, motion passes. > > Resolved: place xspa-saml-profile-cd-01 into 60-day public review. > > need AIs to ensure pkg is prepared and send it off to TC admins. > > > AI: Duane DeCouteau (dd): will take AI to do packaging of > xspa-saml-profile-cd-01 for public review > > > ds: they will state other orgs that shud be notified of this pub > rev, e.g. > HITSP > > AI bc: co-chairs will take AI to notify TC admin once receive pkg > > >> 3. Discussion Threads >> >> 3.1 Comments on HoK Web Browser & Assertion Profiles >> http://lists.oasis-open.org/archives/security-services-comment/200811/mailli >> st.html > > > bc: seems to be on-going disc on this, do we need broader disc? > > Nate Klingenstein (nk): will incorp feedback into another rev of the > spec -- > hopefully > in next 3/4 days will be draft -11 > > ts: will take a pass on it once it arrives > > >> 3.2 New SAML profiles for XRI >> http://lists.oasis-open.org/archives/security-services/200811/msg00056.html > > bc: re-remind folks about these. > > Peter Davis (pd): is info heads-up. are going to be worked on in XRI > tc. > > > >> 3.3 XAdES support in SAML? >> http://lists.oasis-open.org/archives/security-services/200811/msg00074.html > > bc: msg scott sent a bit ago, no responses > > sc: it came up in IMI tc (icard) -- it may come up as an issues that > sstc may > want > to make a stmt about in the future -- coming up on part of cardspace > deployers > > bc: if anyone has bkgrnd/time to look into this, please do so. > > >> 4. Other business > > none. > >> 5. Action Items (Report created 01 December 2008 01:05pm EST) >> >> #0333: Publish a new revision of Profile for Use of DisplayName in >> OASIS >> template >> Owner: Sampo Kellomki >> Status: Open >> Assigned: 2008-05-19 >> Due: --- > > remains open > >> #0332: Revise Query Extension for SAML AuthnReq >> Owner: Sampo Kellomki >> Status: Open >> Assigned: 2008-05-19 >> Due: --- > > remains open > > = > = > = > = > = > = > ====================================================================== > > > > --------------------------------------------------------------------- > 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 > Eve Maler +1 425 947 4522 Principal Engineer eve.maler @ sun.com Business Alliances group Sun Microsystems, Inc.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]