[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]