[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Draft SSTC Meeting Minutes - 1-Jul-2008 w/Roll Call (attendance)
============================================================================ sstc concall Wed Tue Jul 1 09:10:52 PDT 2008 ---------------------------------------------------------------------------- Hal Lockhart wrote: > Proposed Agenda SSTC Conference Call > July 1, 2008, 12:00pm ET > > Dial in info: +1 215 446 3648 > Access code 270-9441# > > Roll Call & Agenda Review Voting Members ---------------- George Fletcher AOL Rob Philpott EMC Corporation Scott Cantor Internet2 Nathan Klingenstein Internet2 Bob Morgan Internet2 Eric Tiffany Liberty Alliance Project Tom Scavo NCSA Jeff Hodges NeuStar, Inc.* 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 Emily Xu Sun Microsystems David Staggs Veterans Health Administration Members -------- John Bradley Individual Quorum Achieved: 17 out of 22 Voting Members Membership Status Change: ------------------------ Sampo Kellomki lost voting rights > Need a volunteer to take minutes =JeffH > 1. Approve minutes from June 17, 2008 > http://lists.oasis-open.org/archives/security-services/200806/msg00017.html approved by unanimous consent. > 2. Administrative > > 2.1 OASIS Launches SAML XML.org Online Community > http://lists.oasis-open.org/archives/security-services/200806/msg00013.html [no remarks] > 2.2 SAML XML.org coverage in GCN > http://lists.oasis-open.org/archives/security-services/200806/msg00018.html [no remarks] > 2.2.1 Policy Regarding Vendor Announcements > http://lists.oasis-open.org/archives/security-services/200806/msg00019.html Eve Maler (em): any vendor announcements that mention saml right in the headline, seems reasonable Hal Lockhart (hl): like supports "saml profile xyz"... em: well, if it's right up in the headline, sure, but if it's buried, then no... hl: we can try that if there's no objection Brian Campbell (bc): and as paul said it is a community and so vendors can post their stuff themselves if they feel it is really important > 2.3 Call for Profile Intentsions Wiki > http://wiki.oasis-open.org/security/CfPi2008 em: proposes substantively discussing profiles that are coming down the pike (rather than just mentioning them in passing (on this call) and pointing at the wiki page)... hl: for next time, want to sched discussion of work items, what they are, whether there's overlap, profile naming conventions, em: and get a schedule together on when they might/should appear hl: yes, there's some "orphaned" projects floating around em: should notate them in order to moderate expectations and such [noting that for next call, eve wont be available, HL will be traveling] hl: things that's perm dead, the spml profile, champ has moved on... em: the thing I em raised on "constrained delegation", it might be a contender for moribund unless tom scavo wants to do something with it. and expects more profiles to come in over next couple weeks > 3. Document Status > > 3.1 Subject-based Profiles for SAML V1.1 Assertions > 3.1.1 Public review started recently and ends Aug 12 > http://lists.oasis-open.org/archives/security-services/200806/msg00006.html [no remarks] > 3.1.2 Call for disclosure > http://lists.oasis-open.org/archives/security-services/200806/msg00007.html [no remarks] > 3.2 Holder of Key Browser SSO Profile Draft-04 > http://lists.oasis-open.org/archives/security-services/200806/msg00022.html nate klingenstein (nk): nothing to discuss at this time. TS may make comments on list. > 3.3 SAML 2 Infocard Profile Draft-01 > http://lists.oasis-open.org/archives/security-services/200806/msg00025.html Scott Cantor (sc): had AI in concordia to do token profile as followup from the RSA interop using SAML assertions where sec considerations and iop issues came up. so felt motivated to write up a profile that would be nominally secure, certain amount of relevance regarding NIST discussions wrt bearer assertions (the LOA-4 thing), so explored the Infocard specs, collaborated with implementer, and wrote up profile. there's some signif issues wrt sites indent/naming, etc, so there's enough there to justify doing a profile, and so this will be nec to iop with "managed card impls", so if the TC is willing to adopt the doc, then there's work to do. and if folks are impl'g, we should try it out to ensure that it actually works as expected. em: AI can take action to check with eg pat patterson to review it rlbob: AI there'll be an iop (osis) for icard stuff, will take an action to raise their consciousness wrt it, will mention in context of icard foundation, eg this is a john bradley (jb): AI will circulate it to other OSIS folks, eg Pamela, MikeJ et al sc: one issue will highlight that profile should say is, wrt an icard feature, operating in non-auditing mode, where hidai e the ident from the RP, would be fine with HOK, but not otherwise, but inclined to write profile up to say MUST NOT DO THIS jb: brought this up on OSIS call, what happens if have auditing card and a ? RP, this is an issue sc: theres things when using SSL underneath, is nominally ok, but on some stacks the private key isn't available jb: [there's issues with openid, WSF EPRs, and such...] the default is non-auditing em: the default is non-auditing (?!) sc: takes some effort to figure this out from the specs jb: the RP has no way to ask that it be audited sc: there's some mismatches wrt various models in the architecture em: are your profile simplifications [reasonable]? sc: i tried to anticiapte the problemeatic cases and create language around them, but you can lead yourself into doing some pretty dangerous things if you don't figure them out, and it screams for putting an option in your impl that say "don't do this", etc. jb: another debate is what happens when a RP wants to pass an param to the STS, because that doesn't usually occur, so there's lots of unknowns like that... sc: well, issues with icard should be addressed in icard forum, whatever that is jb: stuff in the works on that... sc: did this profile wrt what the specs say now hl: is intention to make this profile comprehensive enough that if you just impl it, then you don't need to do anything else to get iop ? sc: ans is yes, this is intended to accomplish the same thing in order to get web SSO a la the web browser SSO profile hl: want it to be based on all public info... sc: i looked at only public info and an available impl, needed to do latter to figure out edge cases > 3.4 LOA AuthnContext profile > <to be posted> hl: not sure doc is there yet... et: just uploaded it, circulated among some folks is just a reduction-in-scope of the AuthnCtx schema, all one can do is refer to a "governing agreement", allows one to point to that doc, from which one can obtain more info. as used in the wild, authnctx is there largely for doctn, and what really matters is the actual URIs conveyed, no one really parses authnctx in real time, so this allows one to define a ctx that meets the NIST LOAs, and name them with URIs there's a lot of disc wrt LOA in various groups, and so wanted to put stake in the ground, but then there's the LOA-4 issue [which intersects with this work] > 4. Discussion Threads > > 4.1 NIST prohibits use of SAML assertions at LOA 4 > http://lists.oasis-open.org/archives/security-services/200806/msg00026.html hl: long thread issues/ques: 1. precisely what does the nist doc say? 2. what action should we take? et: original nist rev doesn't exclude assertions sc: past communities that have used prior vers of nist 800-063 have treated lvl 4 as inapprop to use with SAML rlbob: even at lvl 3 sc: that was because it was spec the web browser SSO profile context et: and so they've also changed other sec discussions in the doc and other govt groups that use the nist doc, i don't know eg whether danish doc, whether they interp doc literally wrt lvl 4, or even use it, and other grps have diff interp than doc, haven't heard from them hl: they are making incorrect assumptions, eg. not between bearer assns, and crypto-bound tokens am worried about the possible headlines "saml dissed by..." we all know there are inherent issues with browser profile and that at lvl 4, there's all sorts of issues with perhaps any protocol that might be used dave : at least in VA we don't think it'd be inapprop to use saml assns at lvl 4, eg when making a class 2 req for a protected drug, but the DEA has released a rule stmt saying that they would use PKI, and so I think there's lots of room for use of SAML assns at lvl 4 de: don't see how RP can figure out whethers there's issues with what's been presented... jh: it's really about protocols, not assns/tokens [disc wrt tech details...] hl: change language to be "don't use bearer token?" rlbob: loosing proposition hl: perhaps tactic is to help them revise their definitions, perhaps need to ref authoratative sources... hl: well suggest we take this back to the list to formulate some sort of comment that the SSTC can support et: several of the LAP SIGs are interested in thinking about this as well, clearly want to align w/them hl: can you liaison? et: sure. hl: can freely comment on saml-comment@ and read security-services@ et: and the LAP SIGs are open to all hl: if someone can draft something we can work this, so work on their defn's and some of the stmts in the doc -- we want to "get on the record" because this affects people > 4.2 OpenID Simple Permissions and SAML constrained delegation > http://lists.oasis-open.org/archives/security-services/200806/msg00036.html em: have an interest in this, anyone else? don't want to take AI, but mebbe Tom? ts: aware of the proposal that came out of Internet2, and prop in Grid space wich is diff, but wrt Browser SSO, it is interesting, would support it, but can't take it on at this time sc: don't see the point of it if you're only going one hop the usecase to me is perhaps you wuddn't modify, because if you're going to make resources avail to others, need to change app anyway em: they are talking about that sc: you don't need deleg if you're going to modify the app -- you only need it if you goto more than one hop. all the pieces are there to do it in SSO profile, but need to have a need to do it. so if you want to give access to your calendar to someone else, i only need to give permission in policy to me the use case is that RP doesn't change, and that's dangerous rlbob: so equiv to give the other use the passwd em: [details on what she thinks openid folks are doing...] jb: xris, concept of synonymity, if the OP is smart enough, without.... don't see value... em: have the OP still be really dumb sc: AI can send msg to the list detailing how this can be done with existing SAML profile rlbob: what this is, is (a better way of doing) an account with a "shared password" jb: this is a way of allowing multiple user ids to leverage the same private key at the RP em: will ensure the research students will see this > > 5. Other business > > > 6. Action Items > Report created 30 June 2008 07:42pm EDT > > #0328: Revise SimpleSign > Owner: Jeff Hodges > Status: Open > Assigned: 2008-05-19 > Due: --- > > #0332: Revise Query Extension for SAML AuthnReq > Owner: Sampo Kellomki > Status: Open > Assigned: 2008-05-19 > Due: --- > > #0333: Publish a new revision of Profile for Use of DisplayName in OASIS template > Owner: Sampo Kellomki > Status: Open > Assigned: 2008-05-19 > Due: --- > > #0334: SSTC home page cleanup after and linking to content from AI#335 > Owner: Brian Campbell > Status: Open > Assigned: 2008-05-28 > Due: --- > > #0335: Add homepage content to wiki(s) as per http://lists.oasis-open.org/archives/security-services/200805/msg00033.html > Owner: Tom Scavo > Status: Open > Assigned: 2008-05-30 > Due: --- ============================================================================
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]