[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Draft minutes for 17 January 2006 SSTC telecon, with attendance data
Attendance of Voting Members Steve Anderson BMC Software Mike Beach The Boeing Company Prasanta Behera Individual Brian Campbell Ping Identity Carolina Canales-Valenzuela Ericsson Scott Cantor Internet2 Peter Davis NeuStar Heather Hinton IBM Frederick Hirsch Nokia Jeff Hodges NeuStar John Hughes Individual Ari Kermaier Oracle Hal Lockhart BEA Systems, Inc Paul Madsen NTT Corporation Eve Maler Sun Microsystems Prateek Mishra Oracle Jahan Moreh Sigaba Bob Morgan Internet2 Cameron Morris Novell Anthony Nadalin IBM Ashish Patel France Telecom Rob Philpott RSA Security Rick Randall Booz Allen Hamilton Irving Reid Hewlett-Packard Company David Staggs Veteran's Health Admin Eric Tiffany IEEE Industry Standards Greg Whitehead Trustgenix Thomas Wisniewski Entrust Emily Xu Sun Microsystems Attendance of Non-Voting Members Guy Denton IBM Dana Kaufman Forum Systems Jim Lien RSA Security Ron Monzillo Sun Microsystems Nick Ragouzis Enosis Group Membership Status Changes Merritt Maxim CA - Removed from TC Membership 12/6/2006 Wendy Gray JPMorganChase - Removed from TC Membership 12/13/2006 Shaheen Abdul Jabbar JPMorganChase - Removed from TC Applicant 12/13/2006 Raajmohan Natarajan EDS - Requested membership 1/4/2006 Roger Reich Symantec - Requested membership 1/12/2006 Conor P. Cahill Intel - Granted TC Membership 1/17/2006 Jim Lien RSA Security - Granted Voting status after 1/17/2006 call Abbie Barbir Nortel - Lost Voting status after 1/17/2006 call AI summary: (#4a, 4b) Tom W. to send out a suggestion for shoring up the conformance language to clear up the requester/responder mismatch. (#4d) Greg W. to propose some clarifying text for the attribute profile section. (#5a) Jahan to revise the PE 10 wording proposal. > 1. Attendance 27(+?) of 32 voting members present. > 2. Approve minutes from December 6, SSTC Conference Call > http://www.oasis-open.org/archives/security-services/200512/msg00013.html Approved by general consent. > 3. Document Updates > > a. Website Updates > http://www.oasis-open.org/archives/security-services/200601/msg00008.html OASIS has dictated a new template to be used for public TC pages. All the newest TC documents have been linked from the page. The Adoption SC should update its OASIS public page if it can. However, Merritt Maxim has had to step down from the Adoption SC. > b. XPath Attribute Profile > http://www.oasis-open.org/apps/org/workgroup/security/download.php/16111/sstc-saml-xpath-attribute-profile-cd-01.sxw The CD version had to be corrected to fix some of the examples. > c. SAML 2.0 Constrained Delegation Profile > http://www.oasis-open.org/apps/org/workgroup/security/download.php/16076/sstc-saml-constrained-delegation-profile-draft-00.pdf A rev-00 draft has been produced. Prateek has received some feedback and will produce a revision next week. Scott noted that Conor thinks the document isn't necessary (through a note sent to saml-dev), which Scott thinks would be nice but isn't sure it's true. The theory is that, having created a placeholder in the syntax for this purpose, it's not clear it can be interpreted in any other fashion. Since you have to include a name ID (and it's recommended that you include an audience), maybe we don't need extra text. How interoperable is the current situation with subject confirmations -- are they sufficient? Higher-level delegation semantics are not part of the current specs. Beyond the subject confirmation mechanism, documenting the delegation parties and flow is left to the implementation. Is the presence of the subject confirmation inside the assertion enough to convey the circumstances of assertion creation, or not? If a given entity uses a particular key, it's treated as the attesting entity (metaphysical considerations aside). If that's enough to discriminate that entity from the subject, we don't need the extra profile language. What is the mandatory processing rule for the relying party on encountering this? It is just informational? The profile attempts to set up rules for verification. It provides tighter interpretations for existing constructs. Is it a "meta-profile"? Or would it be best as merely a clarification of the core spec? > 4. Active Threads > > a. *Authn Query and Authz Decision Query Requesters <msg00000.html>* > http://www.oasis-open.org/archives/security-services/200601/msg00000.html The clarification made informally was that you'd have a separate notion of a requester for each authority, and Thomas indicates that this seems sufficient. In the conformance spec it talks only about generic "requesters" across all sorts of authorities, which is perhaps slightly unclear. What does it mean for an attribute authority to respond to an authorization decision requester? You can respond with any sort of statement in your responding assertion, but from a WSDL standpoint, the intent is to only send the right kind of query to the right kind of responder. AI: Tom W. to send out a suggestion for shoring up the conformance language to clear up the requester/responder mismatch. > b. *SAML Authority and Requester Conformance question <msg00003.html>* > http://www.oasis-open.org/archives/security-services/200601/msg00003.html* Same as above (#4a). > c. Extensions and Profiles <msg00009.html>* > http://www.oasis-open.org/archives/security-services/200601/msg00009.html The discussion is ongoing in email. > d. *LDAP Attribute Profile (saml-profiles-saml2.0) > http://www.oasis-open.org/archives/security-services/200601/msg00013.html This seems to have settled out. We may need a couple of errata items to ensure that the thread doesn't have to be re-enacted again later! One issue is just an error in the spec example. Another issue is whether the ASN.1 wrapper is intended to handle binary data. The tendency seems to be to avoid having the additional wrapper layer. If you include the base64-encoded value directly, using the LDAP profile for it doesn't have any particular implication for special processing. Finally, there's a philosophical issue about attribute syntax assumptions. You can't assume anything about the encoding of values by looking at the name format; it would be a local deployment issue. Out-of-band agreement will be necessary at some level. AI: Greg W. to propose some clarifying text for the attribute profile section. > e. **Use of Audience as delegation flag <msg00022.html>* > *http://www.oasis-open.org/archives/security-services/200601/msg00022.html This seems to be covered by our discussion above (#4a, 4b). > 5. Errata Review/Status There's no new errata document this time. > a. *Proposed text for PE 10/Action item 0216 <msg00008.html>* > http://www.oasis-open.org/archives/security-services/200512/msg00008.html There has been text proposed, at the link above. Where spec text deliberately constrains more than the schema, we've said that the spec text takes precedence. This was an oversight and not deliberate, but in fact assuming deliberateness would "work", since URIs are subsets of strings -- the schema isn't strictly "in error". It would be worth having an erratum just clarifying that anyURI is indeed the right interpretation. AI: Jahan to revise the PE 10 wording proposal. > b. *error in saml-profiles-saml2.0 example (section 8.5.6) <msg00015.html> > http://www.oasis-open.org/archives/security-services/200601/msg00015.html Noted. Examples are non-normative, so this is low-criticality. Prateek brings up a new PE regarding holder of key problems: http://lists.oasis-open.org/archives/security-services/200601/msg00027.html Eric Tiffany brings up a new PE regarding metadata: http://lists.oasis-open.org/archives/security-services/200601/msg00034.html > 5. Open AIs > > *#0243*: Clean up text in Section 3.3.2.2.1 (RequestedAuthNContext) > *Owner*: Scott Cantor > *Status*: Open > *Assigned*: 2006-01-17 > *Due*: --- Scott needs to refresh his memory on the AI before tackling it. > ------------------------------------------------------------------------ > *#0242*: Recommended text for SAML Attr Sharing Profile > *Owner*: Rob Philpott > *Status*: Open > *Assigned*: 2006-01-17 > *Due*: --- Still open. > ------------------------------------------------------------------------ > *#0240*: Status of SAML 2.0 submission to ITU T > *Owner*: Abbie Barbir > *Status*: Open > *Assigned*: 2005-11-07 > *Due*: --- Abbie has asked Eve for help filling out a form having to do with Liberty's PAOS spec, on which SAML depends. She will probably delegate this. > ------------------------------------------------------------------------ > *#0238*: Plan for red-line versions of SAML 2.0 > *Owner*: Eve Maler > *Status*: Open > *Assigned*: 2005-11-07 > *Due*: --- Still open. > ------------------------------------------------------------------------ > *#0237*: Interop Test question: Metadata 2.0 EndpointType question > *Owner*: Eric Tiffany > *Status*: Open > *Assigned*: 2005-10-24 > *Due*: --- This has to do with #5 above; we can close it. > ------------------------------------------------------------------------ > *#0235*: Various Editorial Changes > *Owner*: Eve Maler > *Status*: Open > *Assigned*: 2005-10-10 > *Due*: --- This can be closed. > ------------------------------------------------------------------------ > *#0234*: Nick to prepare some text for PE 23. > *Owner*: Nick Ragouzis* > *Status*: Open > *Assigned*: 2005-10-10 > *Due*: --- Nick had thought we agreed to drop it for now. Perhaps we can find a new owner. > ------------------------------------------------------------------------ > *#0230*: SAML Conformance SSL/TLS requirements > *Owner*: Eric Tiffany > *Status*: Open > *Assigned*: 2005-09-12 > *Due*: --- Eric will try to tackle this soon. > ------------------------------------------------------------------------ > *#0180*: Need to update SAML server trust document > *Owner*: > *Status*: Open > *Assigned*: 2004-07-12 Still open. In addition: Scott would like to make progress on the extension document. In fact, there are several documents outstanding that we were planning to send to public review in batch form. Should we queue up that vote for the next call? Scott will consider that. France Telecom is looking at the extension profile for use against some of its current requirements. -- Eve Maler +1 425 947 4522 Technology Director eve.maler @ sun.com CTO Business Alliances group Sun Microsystems, Inc.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]