[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Draft minutes for SSTC Conference call - May 6/2008
Proposed Agenda SSTC Conference Call May 6, 2008, 12:00pm ET NOTE: NEW PHONE NUMBER Dial in info: +1 215 446 3648 Access code 270-9441# Roll Call & Agenda Review Need a volunteer to take minutes 8-ball chooses Paul Madsen 1. Approve minutes from April 22, 2008 http://lists.oasis-open.org/archives/security-services/200804/msg00048.html No objections , minutes approved Attendance Roll Call: ========= Voting Members: George Fletcher AOL Hal Lockhart BEA Systems, Inc. Rob Philpott EMC Corporation Scott Cantor Internet2 Bob Morgan Internet2 Eric Tiffany Liberty Alliance Project Tom Scavo National Center for Supercomputing Applica... Jeff Hodges NeuStar, Inc. Paul Madsen NTT Corporation Ari Kermaier Oracle Corporation Prateek Mishra Oracle Corporation Anil Saldhana Red Hat Eve Maler Sun Microsystems Non-Voting Members: Sampo Kellomki Symlabs, S.A. Kent Spaulding Tripod Technology Group, Inc. Peter Davis NeuStar, Inc. Nathan Klingenstein Internet2 Srinath Godavarthi Nortel Frederick Hirsch Nokia Corporation Quorum: 13 out of 17 Voting Members Status Change: Welcome to the new voting members (Sampo, Kent, Nathan, Srinath) Frederick lost voting status after April 22 call. 2. Administrative 2.1 SSTC Home Page Older versions, extraneous content, etc. Discussed last time. Any progress to report? Eve had an action, any update? Eve: has begun, may be able to finish soon. Not hard to do. Will draft suggestions. 3. Document Status 3.1 Subject-based Profiles for SAML V1.1 Assertions (Draft-03) Documents updated, submitted to TC Admin Hal: Docs were updated to CD, packet was sent to Mary. Review should start soon. Any suggestions for groups to be notified of the public review? Hal: SSTC can suggest to TC admin as to any groups we think appropriate be notified. Tom: The Web Services Security TC is candidate? Hal: More relevant for groups outside OASIS. No suggestions came, Hal will give his thoughts to TC admin 3.2 Five specs approved as Committee Specifications Check if CS versions for LDAP/X.500 Attribute Profile, IdP Discovery Service Protocol and Profile and the "SimpleSign" Binding are in place Hal: do we have all requried CS specs Scott: mine were lagging, they are there now Discussion on list re: SimpleSign do we have consensus on next step? Scott: the primary issue is to make the call on whether or not we need to 'crack open' the spec. Jeff has volunteered to revise. AI: Jeff will revise SimpleSign. 3.3 Holder-of-Key Web Browser SSO Profile Draft New Draft uploaded 4/21 Comments from Tom: http://lists.oasis-open.org/archives/security-services/200805/msg00000.html http://lists.oasis-open.org/archives/security-services/200805/msg00011.html Nate: Tom made lots of suggestions. Discovery Nate: we left it out of this draft because we felt it was separate. Not saying it didnt need to be speced somewhere Tom: it seems like it would be low-hanging logical extension of this profile because self-signed certs might be a typical use within the profile, as opposed to CA issued certs. If so, short jump to include the IDP entityID in the self-signed cert. Acknowledge that it has value beyond this profile Nate: Doesnt have the time himself to tackle this work. Is there a volunteer? Tom: understood, will think more on this. How many Authn Statements Nate: original SSO profile says 'at least one' wrt authn statements. Not sure about this, wanted to constrain to just one statement Tom: my question was more about the intent, do you want 'one and only one'? Nate: yes, thats the intent, will reword it AI: Nate to revise Holder-of-Key Web Browser SSO Profile accordingly SSL or TLS Nate: chose TLS because it came from standards body. Not sure Scott: probably shouldn't go there. Nate: didn't mean to preclude SSL, just using TLS as shorthand for the both of them Scott: should write both Hal: using SSL is actually TLS Scott: convention is to write SSL/TLS Hal: is there a footnote reference to the RFC Nate: yes, in the normative refs Hal: my suggestion is to leave it TLS, readers will know. Is there a demand for SSL? Scott: is this the HTTP client talking to the IDP. if so, some HTTP clients make you configure one or the other. Tom: could be handled in the introduction simply by defining what 'TLS' means when used in the doc. Meta comment is 'Is SSL OK' RL Bob: SSL 2 is NOT acceptable, TLS 1.1 is most current Ari: just say TLS Scott: finesse it in doc, but make clear in the conformance section what you need to support AI: Nate to revise Holder-of-Key Web Browser SSO Profile to make clear what 'TLS' means, i.e. SSL 3, TLS 1, or TLS 1.1 Collapsing Sections 2.4 & 2.5 Nate: tried to reproduce original browser SSO structure. Any particular reason that this was done this way, broke out message processing and message flows into two sections? Scott: just where we ended up after long process Eve: just the desire of consistency across profiles Nate: tried to maintain consistency, but expect it would read better if I collapsed Scott: I'd probably leave as is, better to have consistency rather than try to improve structure. Nate: Ambivalent, will take the path of least work. Things stay the same. Keying Material Nate: the question is what keying material gets placed into the Holder of the Key by the IDP. Options include key fingerprint, the public key, or the certificate itself. Hal: Cert fingerprint is more typical than key fingerprint Nate: wants to pick something usable, but easy. Nate: likely to choose the cert option. Although makes for a big assertion Scott: No correlation impact here ... Nate: concern is that the IDP selects some keying material the SP cant process Scott: put something in conformance then, mandatory to implement Scott: I'd stay away from names, deliver the keys (or fingerprints etc) themselves Hal: suggest we continue on list AI: Nate to revise Holder-of-Key Web Browser SSO Profile to make X.509 mandatory to implement 3.4 Proposal: Query Extension for SAML AuthnReq http://lists.oasis-open.org/archives/security-services/200804/msg00019.h tml Sampo: objective is to allow an SP to ask for certain attributes on AuthnRequest, or to pass attributes in AuthnRequest. Original options was a) to embed AttributeQuery in AuthnRequest b) to embed AttributeQuery in AuthnRequest/Extension c) new top level query element d) boxcarring e) leverage <RequestedAttributes> (from metadata) as child element of AuthnRequest/Extension Option E is the consensus Prateek: an existing IDP would not process? Scott: no, its in an extension that would not understand it Prateek: shouldnt break though Sampo: but if we are putting in an extension, then do we need a wrapper element Scott: likes the cleanliness of AuthnRequest Extension RequestedAttributes RequestedAttribute Sampo: fine, will rev accordingly Scott: still need to clarify the mandatory processing rules around this extension, and recoincile with the processing rules for the existing element in metadata. Needs to be written carefully, complication is that its an extension, and so an IDP doesnt have to support it. Hal: make sense for the IDP to indicate 'in the message' that the IDP did understand the message? Scott: even if written as mandatory, existing IDPs wont see it Scott: just wanted to hilite the limitations Sampo: if you claim to support this extension, then it must be possible to confugure your IDP deployment to return an error if it doesnt have the attribute Sampo: how to indicate in metadata to indicate support for an extension Scott; we already have a mechanism, it goes in the extension spec AI: Sampo to revise Query Extension for SAML AuthnReqaccordingly 3.5 Proposal: Profile for Use of DisplayName http://lists.oasis-open.org/archives/security-services/200804/msg00020.html Sampo: Draft is how an entity is supposed to render a UI, i.e. how an SP should render a button for initiating SSO? Displaying entity would look at metadata to determine how the entity name should be displayed. Hal: any concerns? Scott: slight feeling that this might belong in an extension, rather than overload the DisplayName. Jeff: feel the same AI: Sampo will publish a new revision of Profile for Use of DisplayName in OASIS template 3.6 Comment from ITU-T Enhancement to X.500 Attribute Profile http://lists.oasis-open.org/archives/security-services/200804/msg00038.html Hal: seems to be an enhancement request...? 3.6 From Comment List Permitting use of Subject Alt Names in Attribute Sharing Profile http://lists.oasis-open.org/archives/security-services-comment/200805/msg00000.html Hal: who followed up? Tom: comment was related to a SAML dev list that solved this problem. Extend the BaseID element to allow the entire cert to be placed in the Subject? Tom: the doc he is referring to is already at CS, so thats another issue Hal: do we need to revise? 4 Errata 4.1 New Errata document http://www.oasis-open.org/committees/download.php/28185/sstc-saml-errata-2.0-draft-44.pdf New draft uploaded. We need to re-approve the corrected PE15. Scott: will correct Corrected link: http://lists.oasis-open.org/archives/security-services/200506/msg00030.html PE67 is still in progress. 5 Other business No other business 6 Action Items Report created 05 May 2008 10:48pm EDT #0325: Update Subject-based Profiles for SAML V1.1 Assertions to CD Owner: Tom Scavo Status: Open Assigned: 2008-04-23 Due: --- Done #0326: Submit Subject-based Profiles for SAML V1.1 Assertions for initial public review Owner: Status: Open Assigned: 2008-04-23 Due: --- Done #0327: Draft proposal for SSTC homepage cleanup - migrating content to appropriate wikis, etc. Owner: Eve Maler Status: Open Assigned: 2008-04-23 Due: 2008-05-20 Open next call is in 2 weeks on May 20th Adjourned -- Paul Madsen e:paulmadsen @ ntt-at.com NTT p:613-482-0432 m:613-282-8647 aim:PaulMdsn5 web:connectid.blogspot.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]