[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Draft SSTC Meeting Minutes - 15-Jul-2008 w/Roll Call (attendance)
============================================================================ SSTC/SAML concall Tue Jul 15 08:57:58 PDT 2008 ---------------------------------------------------------------------------- AI Summary ---------- AI - Eric Tiffany to document/distrib the "suspect text" from the NIST doc(s) (NIST-800-63 (most current draft) at least) ---------------------------------- Brian Campbell (bc) wrote: > Proposed Agenda SSTC Conference Call > July 15, 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 Bob Morgan Internet2 Eric Tiffany Liberty Alliance Project Tom Scavo NCSA Jeff Hodges NeuStar, Inc. Frederick Hirsch Nokia Corporation Srinath Godavarthi Nortel Paul Madsen, NTT Ari Kermaier Oracle Corporation Brian Campbell Ping Identity Corporation Anil Saldhana Red Hat Emily Xu Sun Microsystems David Staggs Veterans Health Administration Members: Duane DeCouteau Veterans Health Administration John Bradley Individual Quorum Achieved: 15 out of 20 Voting Members Membership Status Change: Kent Spaulding, Peter Davis and Paul Madsen (Lost Voting Rights) > Need a volunteer to take minutes =JeffH (jh) > 1. Approve minutes from June July 1, 2008 bc/jh: punt to next week because last minutes weren't published until this morning. jh promises to get this week's minutes out in more timely fashion. > 2. Document Status > > 2.1 Subject-based Profiles for SAML V1.1 Assertions: Public review ends Aug > 12 bc: haven't seen any feedback on this spec as yet. > 2.2 Holder of Key Browser SSO Profile > Draft-04 was posted with discussion and comments on draft-03 bc: some disc on this on list, but from Nate who is not on call today Tom Scavo (ts): was reviewing draft -03, sent comments to list, but since -04 is only slight update to -03, comments relevant sc: no fundamental disagreement w/Nate, but there is a question (ques) wrt rules for requesting SubjectConfirmation (SubjConf), there's a ques wrt syntax rules for requiring a HOK assertion -- so there's a ques on whether or not one always needs to pass SubjConf data in a request, and perhaps the same thinking applies to queries sc: so there's a ques whether this is worthy of an errata, but wondering what TC thinks... ts: once SC pointed me to the additional text in Profiles [saml-profiles-2.0-os], it was clear, so maybe the text in Core [saml-core-2.0-os] needs to be cleaned up, but don't feel strongly about it, will leave it up to you SC if you think that it needs to be formally cleaned up sc: ok, will look at it, not sure what I was thinking when orig wrote that text; this is relevant to another profile that I wrote in Liberty [Single SignOn Service (SSOS), ensconced in the "Authn Svc/SSOS/NameMapping" spec], because it actually uses these features -- will endeavor to go back and re-read it, esp to see whether the LAP spec is saying anything contradictory > 2.3 SAML 2 Infocard Profile Draft-01 > http://lists.oasis-open.org/archives/security-services/200806/msg00025.html bc: this spec is out there, want to remind folks to review it john bradley (jb): did steer infocard steering comm folks towards this, but they haven't gotten to it formally... RL "Bob" Morgan (rlbob): don't you mean osis? jb: but all the approp func in osis to review this are now in infocard foundation... [further discussion on this punted to AI review (below)] > 2.4 LOA AuthnContext profile > http://lists.oasis-open.org/archives/security-services/200807/msg00000.html Eric Tiffany (et): waiting for feedback, but may just make own decisions and just put out a new draft will appreciate feedback, though.. > 3. Discussion Threads > > 3.1 Latest on NIST prohibits use of SAML assertions at LOA 4 > http://lists.oasis-open.org/archives/security-services/200807/msg00014.html et: feels that it is bc: not sure what the content of a stmt ought to be -- do we even have consensus here wrt what we might say to them? sc: are they soliciting comments? et: not sure, believes that feedback would be welcomed sc: impression that we can say something as a TC if we have agreement as a TC, and then some folks here feel that its reasonable to outlaw bearer, but not SSO per se, others that perhaps at level 4 not doing web sso is reasonable et: haven't really made clear what it is that they are objecting to, in the doc there certainly are mechs to make assns workable in higher loa contexts rlbob: not clear what they mean wrt "assertions", reasonable to say that "there's these other uses of saml assns in the world that make sense in this context" but doing that is a lot of work, but in abscence of any "customers" who actually want to make use of that sort of stuff, they prob aren't going to go thru effort to make updates to doc -- this is for govt agencies, not wide world et: we didn't have disc at LAP Plenary last week, but various govts around world do use NIST docs as templates, and so would be nice to cover the base in case... rlbob: an alternate sort of resp would be from the TC or intersted parties as sort of a comment on the doc -- we see this doc draws a line btwn bearer assns and classic pki, there's a use of saml that's at least as strong as pki, and so those govts/other parties that want to use saml as a pki replacement up to LOA-4, that works -- but it'd be hard at this point to get NIST to do a full eval of that claim at this point bc: we could claim wrt saml assn HOK is good for level 4, but... et: we just need to look at it from our persp and see if can come up with a shrink-wrap response to it, and there's the issue of using saml everywhere else and pki at loa-4 is kinda bogus, so would be worth to address it... ?: maybe an informal comment will allow them to adj doc wrt this et: an issue is that we don't have a canned profile that makes it easy/clear to alter position sc: an issue is that this is general doc, not spec, we're viewing it too strictly, so perhaps we can craft language that improves that statment and then federations can say that "what we're doing meets the intent of this nist doc" can write this up but need help wrt where in NIST doc there's the lang we object to bc: can et take action to document where the lang at issue is in the nist doc(s) AI ET to document/distrib the "suspect text" from the NIST doc(s) (800-63 at least) > 3.2 Potential Errata: use of AudienceRestriction in the AuthnRequest > protocol > http://lists.oasis-open.org/archives/security-services/200807/msg00020.html bc: came up yesterday as protential errata item there is some lang in core that perhaps is too strict and maybe the result of having only concrete approach to AudienceRestriction (AudRestr), and perhaps we need to ease this language? sc: couldn't have a protocol that didn't have any rules, and so some rules were written in core that u should do if you don't have (good) reasons not to do them sec 3.4.1.4 -- if you follow those rules, you have to have an AudRestr that points to the entity that sent the request the prob is that once you put an aud in, ur telling the relying parties that if they aren't in Aud, they can't use it thus putting more than one entity in AudRestr is a big change my suggestion is to read that text in context of text above it -- these rules are to take effect in the abscence of any specific content (eg AuthnRequest) so if use case is such that need to put something in Request to signal the profile, then that's all you need to do in order to get around that language suggest tweak the text above it to make clear that "if you know what you're doing, then you can not follow the below" eg "you can follow whatever rules are nec for your profile" bc: is this necessary for folks writing profiles? sc: not that big of deal in comparison with other errata working on, but would be good to do, since issue came up thought it should be clarified one way or another ts: can live with what's there so don't feel strongly about it sc: don't want AI on this, will leave it on the table for now, might do it, we'll see > 4. Other business [no remarks] > 5. Action Items (Report created 14 July 2008 11:37am EDT) > > #0340: Circulate Infocard Profile for review > Owner: John Bradley > Status: Open > Assigned: 2008-07-08 > Due: --- John Bradley (jb): circulated it to OSIS list feedback on this profile is not in OSIS scope anymore, it should be Info-Card Foundation (aka "Information Card Foundation (ICF)" <http://informationcard.net/> ) providing feedback. OSIS is open to developing interop tests based on a spec. thus JB also circulated to the ICF general list, and JB has proposed a ICF Working Group to provide some sort of constructive comments on this draft. This was on the agenda at the last ICF board meeting, however time ran out before it was discussed. everyone [he's talked with about the notion of this spec] "has been really positive" Microsoft et al, are forming TC at OASIS that will "hold information card IPR" [apparently code for "the ISIP (infocard selector IOP profile) spec will be submitted to this new TC"], first meeting will (likely) be at end of Sep-2008 in London (this apparently hasn't yet been announced OASIS-wide) this was "secret", but Abbie Barbir said it was now ok to mention it to folks sc: observes that various specifications have been "left hanging" with microsoft/ibm-driven "ws-" TCs [eg ws-sec, they just shut them down when the work is "done"] thus no on-going maintenance -- thus don't want SAML InfoCard Profile spec to goto this new TC, rather have it stay in SSTC. But, there's a certain vendor not on sstc, want feedback from them (whether via front- or back-channel) wrt the SAML InfoCard Profile spec... jb: that vendor wants jb to set up ICF workgroup to funnel feedback to the sstc. so let's keep this AI open for now > #0339: Circulate Infocard Profile for review > Owner: Bob Morgan > Status: Open > Assigned: 2008-07-08 > Due: --- closed. > #0338: Circulate Infocard Profile for review > Owner: Eve Maler > Status: Open > Assigned: 2008-07-08 > Due: --- open. > #0337: Organize Profile Intentions Wiki > Owner: Eve Maler > Status: Open > Assigned: 2008-07-08 > Due: 2008-07-15 open > #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: --- closed. > #0334: SSTC home page cleanup after and linking to content from AI#335 > Owner: Brian Campbell > Status: Open > Assigned: 2008-05-28 > 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. > #0332: Revise Query Extension for SAML AuthnReq > Owner: Sampo Kellomki > Status: Open > Assigned: 2008-05-19 > Due: --- open. > #0328: Revise SimpleSign > Owner: Jeff Hodges > Status: Open > Assigned: 2008-05-19 > Due: --- open. ============================================================================
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]