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