OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

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


Subject: [xacml] Minutes of 4 Nov Subcommittee call


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



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


Powered by eList eXpress LLC