OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

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