Minutes of 11/4 conference call: Present: Simon, Michiharu, Polar, Tim, Carlisle, Anne (scribe) Action items discussed: 0092: [Polar][OPEN] update 7.4.2 for MustBePresent. Waiting on resolution to 0146. 0134c: [Simon][DONE] Review e-mail comments on datatypes for XACML-defined attributes. All e-mail comments incorporated into a new version that has been sent to Tim. 0143: [Anne][OPEN] Write up missing-attribute StatusDetail schema fragment. 0147: [Polar][OPEN] Reword pseudocode for Only One Applicable, send to Tim. 0149: [Anne][OPEN] Reword SPECIFIC RESOLUTION to fit into Section 7 as a new sub-heading. [Anne] issue updated ChangeRequests list ASAP. [Anne] check for missing line P05 in Example 1, notify Tim. Unresolved change requests discussed: 0092: UNRESOLVED: Section 7.4.2 Attributes rewritewaiting on Action item. Depends on CR#0146. 0134c: RESOLVED: Simon submitted revised list of DataTypes for each XACML-defined attribute to Tim. This revision incorporates all e-mail comments received. 0146: UNRESOLVED: "MustBePresent" and "present" semantics problems. Difficulty in defining QualifiedSubjectAttributeDesignator semantics with MustBePresent. Polar has not dealt with current intent to allow multiple subjects to have the same subject-category: if multiple <Subject> blocks match a QualifiedSubjectAttributeDesignator, how does Policy know which returned attributes go with which <Subject>? Anne opines Policy doesn't care as long as all SubjectQualifiers are satisfied. Someone else opined QualifiedSubjectAttributeDesignator could return Indeterminate if more than one <Subject> block matches all the <SubjectQualifiers>. We were unable to find a solution to this during our meeting. 0153: CLOSED: Issuer should be xs:string in both context and policy. This allows use of X500 names, rfc822 names, urn's, etc. We do not handle specific datatypes for Issuer in XACML 1.0. [Note: SAML 1.0 doesn't either] 0154: PARTIALLY RESOLVED: Problems with QualifiedSubjectAttributeDesignator using <SubjectMatch>. We renamed SubjectAttributeDesignator to CategorizedSubjectAttributeDesignator, defined sub-element for QualifiedSubjectAttributeDesignator to be new type SubjectQualifier. See DETAILS for exact schema text changes. Following open issues, related to CR#0146, remain: OPEN ISSUES: 1) How to deal with missing attributes when evaluating a QualifiedSubjectAttributeDesignator. If MustBePresent="true" on SubjectAttributeDesignator inside the new <SubjectQualifier> element, does this mean that every single <Subject> MUST contain an instance of that Attribute or else the QualifiedSubjectAttributeDesignator returns Indeterminate? This is the same issue being addressed in CR#0092. 2) If multiple <Subject> blocks match the QualifiedSubjectAttributeDesignator, then how does Policy know which returned attributes go with which <Subject>? 0155: RESOLVED: See CR0154 RESOLUTION. Sub-element of QualifiedSubjectAttributeDesignator is named SubjectQualifier. The Change Requests list we were working off did not have the following CRs in it, so we overlooked addressing them. We spent all our time on CR#0146 anyway. 0156: UNRESOLVED: ObligationType maybe should be sequence rather than choice, since only one element permitted. 0157: UNRESOLVED: missing reference for arithmetic functions specification. 0158: APPROVED: redefine <AttributeValueType> to use same XML constructs used for context:RequestContent. Simon and Michiharu agree this is better from an XML schema point-of-view. 0159: APPROVED: add initial explanatory paragraph to each group of XACML-defined attributes in Appendix B. 0160: APPROVED (with two editorial changes that are in the DETAILS below): clarify handling of structured data as a string. 0161: APPROVED: Change "FulfilOn" to "FulfillOn" in policy schema. Schedule: - We have to resolve #0146 and #0154 (part of which is #0146) before we can issue a specification to vote on for Committee Specification. - Polar and Anne also have open ACTION ITEMs. These are promised by close of business TODAY (11/4). - Once ACTION ITEMS are submitted AND #0146 and #0154 are resolved, then: o Simon updates schema o Tim updates specification - Only then can we call for e-mail vote to start. We discussed having e-mail vote start before specification available, but decided that would not help. We also discussed depending on 2/3 of membership to be present and APPROVED on 11/7, but decided that was too risky. E-mail vote better. Two possible schedules: a) Assuming ACTION ITEMs submitted AND #0146 and #0154 resolved and specification updated by close of business Tues. 11/5: 11/05: Final specification issued along with opening of e-mail vote 11/10: Final day of e-mail vote. 11/11: 30-day public review starts 12/10: 30-day public review ends 12/11: at least 3 attestations due 12/11-12: resolve final issues from comments received. Possibly schedule a long conference call on 12/11. Final revisions to Committee Specification made. 12/12: TC re-vote on Committee Specification. Must depend on non-email vote in order to make this date. 12/13: Submit to OASIS (15th is a Sunday) [Anne: if we don't get spec finished and e-mail vote started on 5 Nov, we could still try to get 2/3 members present and approving for TC meeting on 7 Nov.] b) Assuming issues are not resolved, and specification is not available by close of business Tues. 11/5, then submission to OASIS slips by one month. Following are worst-case dates for submission to OASIS by 15 Jan 2003: 11/28: Final draft of specification and schemas issued 11/29: TC e-mail vote on Committee Specification begins 12/04: TC e-mail vote on Committee Specification ends 12/05: 30-day public review starts 01/04: 30-day public review ends 01/06: Final resolution of public review comments 01/09: TC e-mail re-vote on Committee Specification starts 01/14: TC e-mail re-vote on Committee Specification ends 01/15: Submit to OASIS -- Anne H. Anderson Email:
Anne.Anderson@Sun.COM Sun Microsystems Laboratories 1 Network Drive,UBUR02-311 Tel: 781/442-0928 Burlington, MA 01803-0902 USA Fax: 781/442-1692