[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: SSTC telecon minutes 2004-09-14
minutes for OASIS SSTC conference call Tuesday 2004-09-14 minute taker: RL "Bob" Morgan Summary: Votes: * accept text changes in items a, b, d, e, f as noted below * accept text change re confirming entity in SubjectConfirmation (partial item c) * accept text change re one-time semantic enforcement for artifact * accept text change re EncryptedID qualifier attributes Extended discussion: * IssuedTo element: no consensus for including it yet * requiring error responses: strict vs loose debate New action items: * none --- Raw notes: 0. Attendance taken, quorum achieved 1. Aug 31 con call minutes accepted unanimously 2. revised timeline posted to list 3. voting on changes proposed as a result of comments on CD (a) New text on SessionIndex http://lists.oasis-open.org/archives/security-services/200409/msg00015.html unanimously accepted (b) Proposed text for Attribute Value clarification http://lists.oasis-open.org/archives/security-services/200409/msg00031.html unanimously accepted (c) Proposed text for adding ID of confirming entity http://lists.oasis-open.org/archives/security-services/200409/msg00032.html discussion: Scott: original proposal (from Gary Ellison) was to add optional sequence of "issued-to" elements, still a good idea represents last of entities involved in transaction this is "presenter" of request Irving: OK to put in, but should be discouraged unless well-profiled Scott: yes, shouldn't modify standard SSO profiles to use it Ron: who is presenter? is it clear who is whom? these are not necessarily all distinct parties, right? Scott: can be distinct, or not Ron: now we're separating issued-to from confirmation, right? JohnK: yes, that was Gary's proposal (more discussion ...) Ron: have to say what it means when it's omitted, to be clear Scott: yes, omission should mean "don't know" JohnK: sounds like we need respun text combining both proposals Scott: will do Prateek: defer until then (d) text to clarify lack of "direction" in use of NameQualifier http://lists.oasis-open.org/archives/security-services/200409/msg00033.html unanimously accepted (e) text for replacement/enhancement of Recipient http://lists.oasis-open.org/archives/security-services/200409/msg00034.html Scott: at Jeff's suggestion, added to it rather than removing it propose to rename it also, since Recipient is already used ... based on WS-addressing, propose "Destination", implying location could use WS-addr directly if/when it's standardized in WS-flavored profiles unanimously accepted (f) proposed new X.500/LDAP attribute profile text http://lists.oasis-open.org/archives/security-services/200409/msg00035.html Eve: name change from LDAP to X.500 will affect several docs RLBob: URN changed, text name of profile didn't unanimously accepted 4. more discussion of comments * message today from Quadrasis re glossary terms Scott: hoping to get rid of "SSO assertion" term will go through docs to make sure it's expunged Jeff: OK, should remove it then can revise glossary this week Prateek: OK, can have it ready for vote next week * one-time artifact enforcement Scott: Conor proposed better language in his message Conor: point is to clarify how it can be done moved to include language from referenced message (200409/msg00046.html) unanimously accepted * Conformance requirements - SSL/TLS issues Prateek to do more research on why original language is there Scott: text in bindings now in conformance Prateek: yes * Scott: change proposed still needs to be accepted: http://lists.oasis-open.org/archives/security-services/200409/msg00030.html qualifier attributes on EncryptedID element don't make sense question about need to identify source of encryption Greg: don't see the need, handled elsewhere in message if needed when Encrypted nameid is decrypted, has all original qualifiers? Scott: yes unanimously accepted AIs: #0195: Publish glossary text for SessionAuthority, SessionParticipant JohnK will do #0160: Separate Privacy concerns language from Element/Attribute descriptions remains open #0158: Propose changes to definition of Federation in glossary remains open #0123: Obtain MIME type registration for HTTP lookup of SAML JeffH: comments from reviewers re magic numbers, and XML awareness of MIME processor should be ready to go to IESG Scott: text sent just now re IssuedTo/Confirming Entity: http://lists.oasis-open.org/archives/security-services/200409/msg00051.html Ron: seems open-ended, a placeholder for future real semantics Scott: mostly for auditing Rob: so, shouldn't this be done via extension by those defining it? Scott: but it's hard to extend assertion, is there extensions element? no, there's not, maybe should do one Ron: assumes authentication to get name that's put in since it will be relied on Scott: only other extension points are Conditions and Advice those don't seem right for this JohnK: does it have to be "profiled out" in existing profiles no different than other optional things whose use isn't specified in those profiles RLBob: much prefer to be done as extension, rather than putting poorly-defined items into core spec JohnK: does have defined use, but not in existing profiles Rob: can't we add optional element in 2.1? Scott: would break conforming 2.0 implementations Scott: now seems like this can be in Advice or Condition so wouldn't need any other extension point profile can say that something must be in Advice RLBob: Condition is meant to be "must understand" where Advice is "can ignore" so can a profile say that an Advice element must be understood? JohnK: argue that entities involved in assertion-handling should be able to be represented in the assertion RLBob: argue that entities are players in some protocol and should be represented in that protocol's messages Rob: maybe change Advice so profile can make something mandatory? (more discussion ...) RLBob: still a requirement for a new extension point? Scott: doesn't seem like it Scott: so what about original confirming entity proposal in SubjectConfirmation? Prateek: seems like people may not understand it still? Ron: this has real use case, solves problem IssuedTo was originally proposed for Scott: move to accept text in http://lists.oasis-open.org/archives/security-services/200409/msg00032.html unanimously accepted item: Jeff: Liberty offering to host SAML 2.0 interop event in November Rob: is that just physical logistics, or test case prep etc? Jeff: could be both Prateek: test cases/scenarios should be in SSTC (more discussion of interop ...) Rob: message to list about errors and conformance: http://lists.oasis-open.org/archives/security-services/200409/msg00052.html question is about how to respond to message that is schema-valid but doesn't conform to spec text, eg UTCDate format Rob's opinion is that this is error some other opinions that it is valid but should get no response spec should mandate error response Irving: shouldn't violate "liberal in what you accept" principle ie shouldn't tell RP it has to reject message it can handle Scott: seems like point is not to use "success" to mean failure rather to always use real error response (more discussion of this issue ...) --- Attendance of Voting Members (supplied by Steve Anderson) Conor P. Cahill AOL, Inc. Rick Randall Booz Allen Hamilton Tim Alsop CyberSafe Paul Madsen Entrust Carolina Canales-Valenzuela Ericsson Irving Reid Hewlett-Packard Company Paula Austel IBM Maryann Hondo IBM Michael McIntosh IBM Anthony Nadalin IBM Nick Ragouzis Individual Scott Cantor Internet2 Bob Morgan Internet2 Prateek Mishra Netegrity Forest Yin Netegrity Peter Davis Neustar Frederick Hirsch Nokia John Kemp Nokia Cameron Morris Novell Scott Kiester Novell Charles Knouse Oblix Steve Anderson OpenNetwork Ari Kermaier Oracle Vamsi Motukuru Oracle Darren Platt Ping Identity Jim Lien RSA Security John Linn RSA Security Rob Philpott RSA Security Dipak Chopra SAP Jahan Moreh Sigaba Bhavna Bhatnagar Sun Microsystems Jeff Hodges Sun Microsystems Eve Maler Sun Microsystems Ron Monzillo Sun Microsystems Greg Whitehead Trustgenix Attendance of Prospective Members or Observers Abbie Barbir Nortel Andy Moir OASIS Membership Status Changes Adam Dong Sun Microsystems - Requested membership on 9/9/2004 Abbie Barbir Nortel - Granted voting status after 9/14/2004 call James Vanderbeek Vodafone - Lost voting status after 9/14/2004 call
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]