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

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


 > 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 

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 

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 

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 
 > 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 
 > Owner: Tom Scavo
 > Status: Open
 > Assigned: 2008-05-30
 > Due: ---


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]