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