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 minutes for SSTC Conference call - May 6/2008

Proposed Agenda SSTC Conference Call
May 6, 2008, 12:00pm ET


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

No objections , minutes approved


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 

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:


Nate: Tom made lots of suggestions.


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


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 
Scott: put something in conformance then, mandatory to implement
Scott: I'd stay away from names, deliver the keys (or fingerprints etc) 
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

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 

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 
Scott: likes the cleanliness of


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 

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

Hal: seems to be an enhancement request...?

3.6 From Comment List
Permitting use of Subject Alt Names in Attribute Sharing Profile

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

New draft uploaded. We need to re-approve the corrected PE15.

Scott: will correct

Corrected link:


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


#0326: Submit Subject-based Profiles for SAML V1.1 Assertions for
initial public review
Status: Open
Assigned: 2008-04-23
Due: ---


#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

next call is in 2 weeks on May 20th


Paul Madsen            e:paulmadsen @ ntt-at.com
NTT                    p:613-482-0432

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