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] | [List Home]


Subject: Minutes F2F 13/14 March 2007 - UPDATED


Minor corrections made to text based upon input from Erik (denoted by  
"|" on left margin). -bill

Minutes of XACML TC Face-to-Face Meeting
Austin, Texas; hosted by IBM Austin Research Lab

DAY 1 - 13 March 2007

I. Role and Administrivia

     Attendees
      Hal Lockhart
      David Lin
      Anthony Nadalin
      Ron Williams
      Argyn Kuketayev
      Abbie Barbir
      Prateek Mishra
      Erik Rissanen
      Bill Parducci
      David Staggs
      Rich Levinson

    Proposed agenda reviewed and adjusted

II. Discussion

    Refer to XACML 3.0 Issues list at
    http://wiki.oasis-open.org/xacml/IssuesList

  - ISSUE#32: Exception handling

     Thread at:
     http://lists.oasis-open.org/archives/xacml/200702/msg00034.html

     SUMMARY:

     Administrative Policy reduction Cases:
     1. Not Applicable => no reduction
     2. Permit|Deny => reduce
     3. Indeterminate => reduce

     If reduction performed, Indeterminate results are carried up (as
     Indeterminate)

     General consensus is that all Indeterminate results need to be
     reduced.

   VOTE: APPROVED AS PROPOSED.

     DISCUSSION:

     Currently: if don't get a trusted path leading to Permit or
     Deny, then the policy is dropped.

     Proposed solution: 1) reduce as now, following Permit/Deny
     results: if normal path reduces, OK - take that; otherwise,
     2) Follow paths for Indeterminate (both for admin policies
     and access policies).  See if "potentially" Permit or Deny.
     If reach a trusted policy that way, then Access Policy is
     Indeterminate.  (could get more complex, and if all Rules in
     the Policy are Permit, then would not need to try reduce as
     potential Deny).

     Potential for Denial of Service (DoS), everything is done
     twice at each level.  Good news is that if you start from
     Trusted Policies and evaluate toward the Access Policy, you
     don't run into this problem.

     Hal: need to optimize for most common case - one-level
     delegation, etc.

     Erik: but have to analyze complexity of worst case.  Want to
     make sure someone can't submit an untrusted policy that
     causes indefinite evaluation.

     Tony: what about backwards compatibility?

     Bill: this is actually closer to what we do now - we bubble
     up Indeterminate now if don't get a definite Permit or Deny,
     and proposal is that Indeterminate would bubble up in the
     Admin Policy case also.

     NOTE: Diagrams, etc. in Erik's e-mail description of the
     problem are with respect to "new" deny-overrides algs:
     propagate Indeterminate rather than "potential deny" and let
     PEP decide.

     NOTE: paths in graphs of "proposed solution" description are
     not PolicySets, but reduction paths.  Arrows mean that the
     policies were authorized by policy at the end of the arrow.

     NOTE: Olav's model includes three "flavors" of Indeterminate:
     {potential Permit, or Deny, or N/A}, {potential Permit, or
     N/A}, {potential Deny, or N/A}.

  - NEW ISSUE#72: Need better specification of where PEP-supplied
     policies go

     Now a supplied PolicySet would end up being parallel to
     existing inner PolicySets, which violates current model.  See
     related Issue#73.

  - NEW ISSUE#73: Can AdminPolicies be in different PolicySet
     from Access Policy.

     Related to problem of scope of evaluation: want to be able to
     do reductions "locally".  What are the rules for where
     policies are placed in the Admin Policy model?  "At which
     level in the Admin Policy model does reduction start?"

  - ISSUE#50: Maximum Delegation Depth

     Brief overview of the issue:
     Currently we do have a Boolean on whether delegation allowed at
     all.  Issue has to do with more complex specification of actual
     allowed depth.

     Currently, delegation depth in Admin Req can now be specified in
     an arbitrarily complex way because it is constrained by the
     Condition in the XACML policy.  Currently delegation depth is an
     Attribute in the Request; Admin Policy may have a Condition
     saying {"Deleg depth" = 5} OR {"Deleg depth" = 7}, or something.

     If just change delegation depth condition to be an upper bound,
     then it is hard for an implementation to tell if it is part of
     the Condition.

     Bill: Seems like delegation depth might need to be a PEP
     control, and not an Administrative control.  An administrator
     might add a delegation depth, and all of a sudden lots of
     policies start being invalid.

     Erik: a deleg depth will only affect that admin's own policies.

     Erik: If allow variable delegation depth, reduction becomes NP
     complete.  If reducing from the bottom up, have to backtrack and
     attempt another path if delegation depth exceeded.  If do
|   reduction top down, can't do deleg depth. This is a suspicion
|   Erik has not performed a proof

     Hal: why not just do reduction as now, but keep track of depth
     and stop if exceeded.

     Erik: Depth not known until reduction done.

     PROPOSAL: Add new "custom" element to express "maximum depth" as
     an integer.

   ACTION: Erik to write-up formal proposal based upon integers.

  - NEW ISSUE#71: Treat different Subjects with same
     SubjectCategory as different entities.

     Currently, XACML 2.0 does not treat different
     SubjectCategories as different entities; all Attributes are
     lumped together as if they were one entity.

     Anne: presented limit-scope:all and limit-scope:atLeastOne from
     WS-XACML specification.

     Erik: this would require the arguments to the limit-scope
     functions to be treated as strings that are passed to the
     function itself, which would evaluate them using XACML
     semantics. e.g. Enclose all the arguments in an <AttributeValue>
     with some datatype - could be "string", where semantics say
     of functions say "evaluate arguments as XACML expressions in
     specified scope".

     Argyn: this requires Requests to be in XML format.  Also
     requires support for XPath.

     Anne: Yes to XML format.  We could add another form of the
     limit-scope functions in which the first argument is an
     Attributes category, and all the remaining arguments are
     Attribute values from within one instance of that Attributes
     category.  e.g.: ...:limit-scope:designator:atLeastOne takes
     AttributeDesignator arguments, and
     ...:limit-scope:selector:atLeastOne takes AttributeSelector
     (XPath) arguments.

     Tony: so :atLeastOne returns false if there is no element
     that is selected by the XPath expression?

     Anne: right.  And for :all, we need to specify whether it
     returns "true" or "false" if there are no elements that
     satisfy the XPath expression.

     Erik: could do it with higher-order functions.  XACML 2.0
     does not allow bags-of-bags, so would need to relax that, and
     would need to define a lambda expression syntax.

     Erik: MultipleCondition format
     (http://lists.oasis-open.org/archives/xacml/200703/msg00010.html)
     solves the same problem as limit-scope:all in the
     AttributeDesignator form.  Example:

       <Condition>
          <MultipleCondition FunctionId="string-equal"
                             Category="intermediate-subject"
                             AttributeId="role"
                             DataType="string">
             <AttributeValue>manager</AttributeValue>
          </MultipleCondition>
       </Condition>

     Means all intermediate-subject Attributes groups must have
     role="manager" with DataType="string".

     Would be easy to generalize to "atLeastOne"

   NO RESOLUTION

  - ISSUE #68: Backwards compatibility of generalized Target

     Erik noted that this is dependent upon "multiple conditions",
     so this was tabled until ISSUE#71 is resolved.

  - WS-XACML Presentation

     Anne presented the WS-XACML Profile. She will be reworking
     the slide presentation for distribution (available at
     http://research.sun.com/projects/xacml)

   ACTION: Anne to describe on mailing list the separate top-level  
PolicySet
     possibility for grouping WS-XACML assertion requirements for
     guidance and review.  Not appropriate for normative
     specification.

     DISCUSSION:

     ISSUE#56 add Preference Attribute; extend XACML Expression to
     create a new flavor of <Apply>

     ISSUE#57 XPath expressions may all need to refer to leaf nodes

     ISSUE#76 with limit-scope functions, it is probably not
     possible to match predicates because they can select
     different sub-trees of a document.  limit-scope may be useful
     for general XACML policies, however.  Might also be possible
     to define handling of subsets if Capabilities can only
     specify "all" elements in a subtree will satisfy
     requirements, but that any subset may be required; requires
     more thought.

     ISSUE#76 include <AttributeDescriptor> form of the
     limit-scope functions; don't force use of XPath.

  ACTION: Anne to describe on mailing list how Vocabulary elements
     are used more clearly.


  ACTION: Anne: justify "must-not-be-present" function better -
     example

  ACTION: Anne: in WS-XACML profile, make sure fact that vocabulary
     domains is known is being utilized: any vocabulary element
     that is not explicitly constrained either has no constraints
     or is not allowed.

  - Issue #61 XACMLAuthzAssertions in access control Policies

     The TC discussed the inability of XACML policy Attributes to
     be extracted independently; particularly via normative
     language.

     Rich asked if usage guidance can be posted to the list. Anne
     offered that some non-normative suggestions can be created,
     but that it should be of limited scope since this is
     implementation specific.

  ACTION: Anne to post description of possible approaches to
     mailing list.

  - CONFORMANCE TEST

     Argyn initiated discussion on Conformance testing in XACML
     v3.0.

     Conversion of existing conformance tests: we will translate
     copies of 2.0 tests to 3.0.  Testing 2.0 requests input to 3.0
     policies or 3.0 requests input to 2.0 policies handled by 3.0
     PDP is not committed, but would be nice.

     NOTE: We don't have version indications in Request context: but
     can determine from the namespace element.

  ACTION: ?? to query the XACML mailing lists to see how people are
     using XPath expressions, and we can try to develop
     translation methods for the commonly used formats.

     Erik: we have 3.0 tests that we could contribute.

     Argyn: where do we store conformance tests?  It is more
     convenient to track changes with a source control system.

     Hal: some TCs are using CVS.

  ACTION: Hal to ask Mary McRae what OASIS can support.

  - ISSUE#9 and ISSUE#68: Conformance led into a discussion of
     backward compatibility and migration from v2.0 to v3.0
     automatically. It is generally believed that
     <ResourceContent> in a Request can be mapped to <Attributes
     Categories=""> except in case of certain XPath expressions
     (e.g. element[2]).

  GENERAL CONSENSUS is that v2.0 Conformance Tests will be modified to
     support v3.0 and supplemented to address new functionality.

     Hal: we can require that 3.0 implementations support 2.0
     policies and requests, but not dictate how.  Sites might convert
     all their policies once, they could have a pre-processor, or
     could actually support two schemas at once in the PDP itself.

     Erik: there is the issue of XPath expressions in 3.0 policies
     that will resolve to different targets in 2.0 Request Contexts.

     Argyn: if a policy is converted from 2.0 to 3.0 format, it may
     contain XPath expressions that were originally written to 2.0
     Requests.

     Erik: our implementation does the translations of policies and
     requests, but don't deal with XPath expressions.  Won't work
     with 2.0 policy that gets a 3.0 request.

     Anne: possible to specify that all references to
     //Request/Resource/ResourceContent/ are converted to
     //Request/Attributes[Category="Resource"]/Content/

     Erik: example of problem is if the XPath expression points to
     element[2].

     Hal: do we really need to translate Request Context?

     Erik: except for XPath expressions, it is trivial.

     PROPOSAL: 3.0 PDPs MUST support 2.0 policies and 2.0 requests in
     some way that we do not specify.  Exception: XPath expressions
     will be on a best-effort basis (usually need to be translated by
     hand).  Supporting requests requires on-the-fly conversion, but
     policies MAY be converted once, using a pre-processor, by
     supporting two schemas at once in the PDP, or in any other way
     that satisfies the requirements.

   PROPOSAL APPROVED UNANIMOUSLY

  - ISSUE#68 Backwards compatibility of generalized Target

     The general consensus is to allow the more generalized form of the
     <ConjunctiveMatch> syntax. This will preserve v2.0 compatibility in
     the Target.

     In XACML 2.0:
          Subjects/Resources: conjunctive
          Subject/Subject: disjunctive
          SubjectMatch/SubjectMatch: conjunctive
             these could be different SubjectCategories

     In XACML 3.0,
          Each SubjectCategory will be a different "Subject", and all
          <ConjunctiveMatch> elements must refer to same <Attributes
             Category="X">, so can't intermix equivalent of different
             SubjectCategory Attributes.

     MODULO ISSUE#71 Treating different subject categories as
     different entities

   PROPOSAL: within a ConjunctiveMatch, different Match elements
     can reference different Attributes Category values.

   PROPOSAL APPROVED.

  - EXIT CRITERIA FOR XACML 3.0

     XACML 3.0 implementations: we will need 3 conforming
     implementations; the definition of "conforming
     implementations" is being tightened up.

     XACML 3.0 scope: when will set of issues not to be addressed be
     settled.  Answer: no set rule.

  - PEP/PDP

     Hal reviewed his posting re: Policy provisioning.

     Hal: Assume PAP knows where PDPs are and what policies each
     needs to have; not all PDPs need all policies.  Whole
     motivation for creating an XACML profile is because
     XACML-related knowledge is needed to know which policies each
     PDP needs; just a general "push everything" doesn't require
     any fancy protocol and requires no special XACML knowledge.
     PAP knows when policies change, so knows when new policies
     need to be pushed to PDPs.  What is needed for a provisioning
     protocol:

     - Minimal requirement is: "Unsolicited push" from PAP to
       PDP(s).
     - SPML batch package operation to push policies that are
       needed.
     - Query from PAP to PDP: what policies do you have?
     - Query from PDP to PAP: sync me up (e.g. when PDP starts up
       or restarts after being down), possibly establish channel
       for PAP to push new policies later; "sync me up" might
       include list of policies the PDP already has, or might ask
       for "which should I have", then PDP goes back and asks for
       the one it doesn't have.
     - Incremental step further: PAP could also provide a batch of
       policies and a time, saying "this batch of policies must be
       atomically loaded at given time".

     David: why is XACMLPolicyQuery not suitable?

     Hal: it was really designed primarily for retrieving
     referenced policies by PolicyId

     Argyn: proposed PDP-local PAP and remote PAP

  meeting adjourned for the day


F2F DAY 2 - 14 March 2007

I. Administrivia

    Agenda reviewed and adjusted.

II. Discussions

  - SAML Profile

     Anne reviewed the SAML Profile

     NEW ISSUE#74 specify how to use SAML metadata.

  - ISSUE#54 Number of policies required by administrative policy  
delegation

     The VHA model currently uses a database attribute to hold a
     list (group) of all subjects who are authorized to do
     something.  In order to delegate, the modifier of the
     database entry must have authorization to modify that
     database entry.  David wanted to know if this was a
     reasonable approach, or if Policy Admin should be used
     instead, even though it would lead to a large number of
     policies.

     Erik: If it is working, don't change it.  Big gain of 3.0
     model is allowing grouping of resources under the same
     policy.  For example, can create two delegation policies for
     two owners of different resources, and they can delegate it
     further.  They can delegate to a single authority that
     aggregates the two policies.  Useful in federations, such as
     roles.  A complete solution must contain attribute
     administration as well as policy administration.

     Hal: VHA scheme would not work well for GRID scheme where
     they want to pass policies on the fly; no time or place to
     update an attribute repository.  VHA environment has large
     number of users with potentially the same situation, so
     amenable to the attribute-style solution.  One
     strength/characteristic of XACML is that everything in the
     policy is self-contained; authorization decision is made
     based solely on Request and Policy[Set].  When assigning
     Subject Attributes, they should typically be something that
     would be understandable to the president of the company -
     they should be constructs that make sense in your
     organization; should not be categories created specifically
     for access control.  XACML Admin Policy model is like a bank
     teller, who can take money out of Hal's account when
     requested by Hal and given to Hal, but not on the teller's
     own authority.

     General consensus: there are various ways to implement
     delegation, and the current VHA approach may well be the best
     approach for their situation.

III. Review of issues not yet closed

  - ISSUE#3 Generalized Attribute Categories

     Change from Open to Pending Review, since in most recent
     Admin Policy draft.

  - ISSUE#5. Policy statements in the request context

     Pending Review: should clarify where Admin Policies should be
     in the same PolicySet, but that is a new issue #73.

  - ISSUE#72 [New issue] Where should passed-in Admin Policies be
     inserted?

     Erik suggests the base Policies should be constructed with
     Admin Policies in mind, so it should be clear where they are
     inserted.

  - ISSUE#4 PPD references in policies

     Change to CLOSED for lack of active champion

  - ISSUE#8 Alternate Owner-Policy-Statement to determine sentinel

     CLOSED for lack of active champion

  - ISSUE#12 General obligations

     Bill will talk on this later

  - ISSUE#13 What are my permissions?

     Erik's student looked at it, and found some cases that could
     be handled

     Change to CLOSED for lack of proposal and no impact on
     current schema

  - ISSUE#22 Right to revoke

     Erik: has a research paper he is working on, but hasn't
     finished writing up.  Recommends deferring.  As interim
     measure, people have to do their own revocation.  Hasn't
     tried out his model, and wants to make sure it works in
     practice.

     Example: two resource owners A and B have delegated to User
     C; C creates a policy that contains both Resource A and
     Resource B.  If Owner B revokes the policy, it affects access
     via C to Resource A.  So need to look at who revoked it, how
     the resource is being used.

     Hal: concerned about ignorance issue - person doing reduction
     never sees the revoke (not an issue in the repository case,
     where you can just remove it from the repository).

     Anne: One use case for revoking another's policies are where
     the other issuer has left the company.

     Erik: not sure about how far down revocation should be
|   allowed; suspects problem becomes NP-complete.

     Erik: is it OK for the PDP to do revocation?

     General agreement: yes.  We are not specifying anything about
     how revocation is done.

     Changed to CLOSED for 3.0 for lack of complete proposal.

  - ISSUE#23 Access permitted

     Erik: doesn't work now because worded against old Subject,
     Resource, etc.  If rephrased in the wrong way, it can become
     NP complete.  Hal had agreed to provide a new proposal.  The
     wrong way is to allow adding new information while you keep
     old information in the request; OK to replace old subject
     with new subject.  But if just add a subject that was not
     there originally, problem becomes NP complete.  Reference:
     terse e-mail on 2/22/07 from Erik (Message#56).

     Change to OPEN; action item for Hal to provide proposal.

  - ISSUE#24 Mixed administrative/access target

     Change from PENDING REVIEW to CLOSED.  Text accepted.

  - ISSUE#25 Nested policy sets and enforcement of delegation  
constraints

     Change from PENDING REVIEW to CLOSED.  Text accepted.

  - ISSUE#27 The issuer of the PDP policy set

     Change from PENDING REVIEW to CLOSED.  Text accepted.

  - ISSUE#31 Passing arbitrary sets of Attributes in the request

     Hal: the existing profile can serve as a checklist for the
     types of information that need to be provided.

     Change from PENDING REVIEW to CLOSED.  Text accepted.

  - ISSUE#32 Exception handling

     Change from OPEN to PENDING.  This is the problem we
     discussed on Tuesday.  Erik will provide text for review.

  - ISSUE#33. How to match any delegate

     Proposal pending new core schema.  Current status is that
     current schema specifies a solution for this.  If you want to
     match any delegate you don't write anything on the delegate.

     Change to PENDING REVIEW

  - ISSUE#34. Draft 10 has a circular import in the schemas

     Change to PENDING REVIEW.  Fix in current draft.

  - ISSUE#36. PDP metadata

     Bill: would be useful for PDP to indicate whether it has a
     bias for permit or deny.

     Hal: Also implied top-level combining algorithm, and whether
     historic or current Attributes are used.

     Hal: recommends providing some XML syntax and some suggested
     publication methods.  Need to provide a metadata schema.
     Refer to SAML's 2.0 metadata spec.  We could steal their
     approach.

     ACTION: Bill to provide proposal.  Still OPEN

  - ISSUE#40. Change ResourceContent

     One thing still needs to be changed: remove content-uri.

     Leave PENDING, otherwise, current draft OK.

  - ISSUE#41. Flag to force evaluation of all applicable policies

     Change from OPEN to CLOSED due to technical issues.

  - ISSUE#42. SAML Profile: Matching of holder identity against the
     request context

     Change from PENDING REVIEW to CLOSED.  Text accepted.

  - ISSUE#43. SAML profile: Inheritance between additional attributes

     Change from PENDING REVIEW to CLOSED.  Text accepted.

  - ISSUE#44. SAML profile: Do we add attributes to the access
     request?

     Change from PENDING REVIEW to CLOSED.  Text accepted.

  - ISSUE#45. In the SAML profile: Translation of saml:Subject?

     Leave as PENDING REVIEW.  Draft came out too recently.

  - ISSUE#46. SAML profile: multiple holders of attributes

     Currently yes.

     Change from OPEN to CLOSED.  Text accepted.

  - ISSUE#49. Delegation with attribute categories

     Change from PENDING REVIEW to CLOSED.  Text accepted.

  - ISSUE#50. Maxdepth with attribute categories

     Conceptual agreement on creating a new element.

     Change from OPEN to PENDING.

  - ISSUE#51. Reduction of deny with attribute categories

     Change from PENDING REVIEW to CLOSED.  Text accepted.

  - ISSUE#52. Indirect delegates with attribute categories

     Change from PENDING to CLOSED.

  - ISSUE#53. Computational complexity of delegation

     Change from OPEN to CLOSED.

  - ISSUE#54. Number of policies required by administrative policy  
delegation

     Erik's specification addresses administration of policies,
     not of Attributes.

   ACTION Erik to add note about alternative ways to do delegation.

     Change to PENDING

  - ISSUE#55. WS-XACML: Address policy references in a Requirements
     element containing a PolicySet

     Still PENDING.  Will re-use same element defined for SAML
     Profile Policy references.

  - ISSUE#56. WS-XACML: Add optional "Preference" XML attribute to  
Apply element

     Resolution: WS-XACML will define a new type of "Apply"
     derived from XACML Expression for constraints, and add such
     an XML attribute.

     PENDING

  - ISSUE#57. WS-XACML: Restrictions on XPath expression to support
     matching Attribute references

     Anne is still reading references.

     PENDING REVIEW

  - ISSUE#58. WS-XACML: Handle P3P 1.0
     POLICY/STATEMENT/NON-IDENTIFIABLE in an XACMLPrivacyAssertion

     ACTION: Anne to update description to remove my old Action
     items.

     OPEN

  - ISSUE#59. WS-XACML: Allow restricted regular expression
     functions in XACMLAssertion

     We will allow.  Anne needs to write up.

     PENDING

  - ISSUE#60. WS-XACML: Remove "XACML Authorization Token" and
     "Conveying XACML Attributes in a SOAP Message"?

     Change from PENDING REVIEW to CLOSED.  Text accepted from
     current SAML Profile draft.

  - ISSUE#61. WS-XACML: How are the contents of
     XACMLAuthzAssertions represented in the base XACML Policies

     ACTION: Anne will post description of one way to the list, and
     might be included as non-normative example in the SAML Profile
     itself.

    DEFERRED until Rich can call in.

  - ISSUE#62. Policy provisioning interface

     Still OPEN.  Hal will do skeleton proposal for two protocols,
     one PAP-initiated, one PDP-initiated.

  - ISSUE#63. Generalizaton of multiple resources

     Defer until after lunch.

  - ISSUE#64. Treatment of administrative deny

     Still PENDING.

  - ISSUE#66. Missing attributes may be underspecified

     Defer for Rich and Prateek.

  - ISSUE#67. Add XPath 2.0 support

     Already support specification of XPath version.

  ACTION: Daniel to submit proposal for specifying settings.

  - ISSUE#68. Backwards compatiblity of generalized Target

     Allow more general form.

     PENDING (see discussion notes earlier)

  - ISSUE#69. Incorrect URL in
     access_control-xacml-2.0-context-schema-os.xsd schema file

     PENDING - fix it and approve Errata

    ACTION: Argyn to send out schema with corrected URL.

  - ISSUE#70. SAML Profile: IDs for policies in XACMLPolicyStatementType

    ACTION: Anne to check with Seth, otherwise seems OK to
     require Policy[Set]Reference value to match Policy[Set]Id in
     the referenced policy.

  - ISSUE#71. Treating different subject categories as different  
entities

     OPEN.

  - ISSUE#72. Where should passed in (SAML profile) policies be inserted

     OPEN.

  - ISSUE#73. At which level in a nested policy set does reduction  
start?

     OPEN.

  - ISSUE#74. Add SAML metadata to the SAML Profile

     OPEN.

IV. Call with Rich Levinson and Prateek Mishra

A. ISSUE#61 WS-XACML: How are the contents of
     XACMLAuthzAssertions represented in the base XACML Policies

     3 separate sub-issues:

     a) Whether we are talking about XACML Policies or individual
      sequence of <Apply> elements

     b) How to flag individual constraints

     c) Querying for policies from enterprise

     d) Collecting policies relevant to a particular service

     If central admin does policy, it all goes into enterprise
     repository, so how does Web Service pull out what goes into
     its WSDL.

     In order to get a policy associated with a specific resource, Web
     Server would need to query for all policies associated with that
     resource.

     Could construct policies in a separate PolicySet.

     Hal: is there still some open requirement?

     Rich: need to absorb all the information and see where it
     needs to be pushed further, if it does.

     Rich: How to front-end the requirements of the net.
     WS-Security Requirements and set of Assertions populated
     there - might come out of same repository, but he's not
     suggesting that now.  OK to move on from Issue#61 now.

   CLOSE Issue#61 and open new issues as they arise.

B. PDP provisioning protocol
    http://lists.oasis-open.org/archives/xacml/200702/msg00061.html

     Hal described the basic protocol requirements we worked out
     yesterday.

     Prateek says they would be interested in contributing.
     Specify indices on which push and pull are based.

     Hal: assumption is that PAP knows which PDPs are supposed to
     get which policies and they are all indexed by Policy[Set]Id.

C. PEP/PDP issues: closely coupled PEP/PDP
    http://lists.oasis-open.org/archives/xacml/200702/msg00060.html

     Hal: BEA and IBM provide this, but no XACML-specific
     standardization around it.  Can't do it in a very generic way
     - needs to be for a very specific environment, such as Java
     or CORBA. [Prateek agrees] Would some of the J2EE-defined
     things be sufficient, or does it need to be XACML-specific?

     Prateek: if enterprise invests in an XACML infrastructure,
     enterprise would like all their applications to be able to
     interact with the authz engine with some API.  By use of
     containers, this can be pushed out for coarse-grained authz,
     but need to point to some API in a direct way.  Not to
     suggest that current J2EE approaches are inadequate, but a
     specific API would enhance value of XACML.

     Hal: BEA has contributed some of their SPIs to JSRs.  They
     use these to invoke XACML from containers and applications.
     Not XACML-specific.  BEA could explore whether they would be
     willing to contribute some of their SPIs.

     Ron: JACC use-models are limited.  Specification provides a
     hole in the container through which you can get at the
     necessary information.  Still have to implement the
     mechanism.  Some people think advantage of XACML is can
     implement not just the JACC-specified web policies, etc., but
     can provide fully expressive policies.

     Hal: BEA supports JACC because it is a standard, but they
     encourage use of their SPIs, which can support more
     expressive policies.  Let's identify specifically what is
     insufficient about JACC (JSR#115).  Then decide what to do
     about it.

     Prateek: identify some of the patterns and flows that are
     hard to fit into JACC.  A "generic Java environment" is a
     good starting point.  He and Rich will take action item to
     identify these.

     NEW ISSUE#75: need to define interface for a closely-coupled
     PEP and PDP.

D. PEP/PDP issues: how do you know what inputs the policies refer
    to?
    http://lists.oasis-open.org/archives/xacml/200702/msg00059.html

     Hal: it is really the PEP and PAP that care what Attributes
     are needed to satisfy policies.  The WS-XACML "Vocabulary"
     mechanism might be sufficient: advertise per Web Service an
     identifier associated with a set of Attributes and their
     semantics.

     Prateek: that is a good starting point.  Need to work through
     an appropriate definition for it.  Rather than Vocabulary
     involved with a Web Service, the Vocabulary involved with a
     PEP.

     Hal: or is it more valuable to know this on a Web Service
     basis.  Support of a Service by particular PEPs is hidden
     from the Web Service interface.  Don't you want to know on a
     Service basis?

     Prateek: brings up which services are managed by a PEP.

     Hal: but if you know which services, do you even care about
     which PEP?

     Prateek: issue is of deployment-level information.  If I
     purchase or send out RFP for a content repository that will
     support some PEP, then need to be able to say something about
     what the PEPs require.  Need way to describe expected set of
     queries that might arise from a PEP; otherwise hard to
     implement a plug-and-play environment.

     Hal: that seems like more a runtime administration issue.

     Prateek: another scenario is that applications are delivered
     with embedded PEPs.  Want to know what kinds of queries will
     be generated from them.  Want to tell application developers
     to use a certain request/response language.  How would you
     characterize your expectations of those PEPs?

     Hal: might conform to XACML SAML message format.

     Prateek: need to know also what Attributes they would carry.

     Ron: application should provide policies "out of the box"
     that are suitable for that application.  Might need some
     hooking up for retrieving the specific Attributes required.

     Hal: could define meta-data to say "this set of roles is in
     use", which might be useful for a policy editor tool, but who
     else needs to know that?

     Ron: a product already defines how it operates and the
     semantics of its access control.  Integration into the
     enterprise is at the level of mapping roles onto the
     enterprise users.

     Prateek: a few use-case scenarios on the list would be
     helpful.  Big picture scenario is where an enterprise is
     acquiring applications with embedded PEPs, and would like to
     understand what could possibly be obtained in the queries
     that would come from the PEPs.  Need to know which Attributes
     the PEP will provide in its Requests, and which will need to
     be retrieved from elsewhere.

     Hal: could provide a schema for describing all Attributes
     that might be required and where they are obtained.

     Prateek: that might be all that is required.  Again a few
     concrete examples might be helpful.  He will provide such
     examples and example descriptor that characterizes what a PEP
     proposes to emit and accept back (which Obligations).
     Related to some of the vocabulary discussion we had, but
     needs to be clarified with example.

   ACTION: Prateek to generate examples

E. Resource Attributes
    http://lists.oasis-open.org/archives/xacml/200702/msg00059.html (4)

     Hal: experience has been that every enterprise defines these
     differently.  Not sure how much could be standardized.

     Prateek: mostly interested in finding some formats for
     Resource meta-data.  Formats that would indicate ownership of
     the resource, other aspects of the resource.  Might be
     difficult to make much progress on standardizing this.

     Hal: some vertical industry groups are defining such
     metadata, such as the geo-spatial people (they even added
     functions, not just Attributes, since their "resources" might
     overlap each other).

     Prateek: so may not have a general framework.

     Hal: perhaps Seth could point us at some of the groups that
     have been defining AttributeIds for their problem sets.
     Prateek should contact Seth directly and ask for links to
     industry groups that may have defined such things.

F. Referencing policies by PolicyId
    http://lists.oasis-open.org/archives/xacml/200702/msg00062.html

     Hal: PDP must have a mechanism for retrieving policy by Id.

     Prateek: no need to go further so long as PDP knows how to
     retrieve?  Even with multiple PAPs operating on a policy
     repository, is there no additional information needed?

     Hal: two general cases.  1) PDP has no policy storage at all
     between one evaluation and the next; makes a network call to
     the PAP for each decision, 2) PDP has policies lying around
     and uses them for each decision.

     Hal: being able to get policy by Id is just part of the
     general requirement that you have to be able to get them by
     situation and by Id.

     Prateek: so maybe don't need anything beyond.

     Hal: so an Oracle database may be used to store policies, or
     DB2, etc.

V. A Chat on Obligations

     Bill presented current status of enhanced Obligations.

     Erik presented an alternative that his group developed.

     Bill and Erik have had some conversations about this.  Erik
|   had a student (Ja'far) working on it.

     Basic idea: a completely unbounded problem [Hal: "an
     open-ended kludge"] Biggest problem is what to do when you
     have a large bag of Obligations and need to reduce them to
     something that the PEP can fulfill.  Combinations possible
     for interactions become too complex.

     Bill had suggested hierarchical approach similar to
     Michiharu's category approach (on WIKI).  Would also need to
     have hierarchy among the categories themselves.

     Still have to overcome problem of resolving conflict.  Bill
     migrated toward thinking this should be handled in the
     Context.  In conjunction with Michiharu, decided terms needed
     to be better defined.

     Need to decide whether context is place to handle this, and
     whether we have an approach that will work with this
     unbounded problem.

     Spec says: PEP must not allow access if doesn't understand or
     can't fulfill an Obligation passed back with a decision.  We
     don't have multiple flavors (ignorable, mandatory).

     Hal: Michiharu's presentation summary: for bag of
     Obligations, might want to do all, pick some, etc.

     Bill: one could say encrypt Blowfish, another encrypt DES.
     Combining mechanism could be "pick one".  Hard part is where
     one Obligation says "stand", the other says "sit", and they
     have the same priority.

     Erik: similar to Permit/Deny conflicts, except that number of
     separate Obligation identities is unbounded.

     Hal: would need to have a matrix to show which Obligations
     override others where there is any possibility of conflict.

     Bill: proposed precedence hierarchy for categories.  Side
     benefit of the matrix is advertising which Obligations need
     to be understood.

     Erik: alternative solution (URI-combiner).

     Obligation-combining-algorithms via callbacks to the PDP

      Jafar's proposal (roughly):
       <PolicySet> can define
         <ObligationCombiningAlgS>
            <CombiningAlg id="overrides-combalg">

                 e.g. If person has both normal and emergency
                 access, should use the normal access to avoid
                 unnecessary auditing related to access allowed
                 only for emergencies

                 Example: ObligId="Normal", ObligId="heavy-audit"
                 <CombAlg id="overrides-combalg">
                 <Policy>
                    <Obligs > f([a1],[b11,b12]...], WS),ObligPS</Obligs>
             </CombiningAlg>
        </ObligationCombiningAlgs>

     Erik: Output of one algorithm is passed to the next.
                 Requires
     implementation in code.

     Erik: Michiharu had defined five basic categories of
                 obligations
     (e.g. atomic: choose only one; ).  Bill introduced hierarchy:
     precedence of different categories, in case where they are
     exclusive.  Erik: The five categories are five different
                 kinds
     of combining algorithms.  We could define standard
                 categories.

     5 Categories: atomic, data processing, cycling, [see WIKI]

     Hal: we've proposed defining some standard Obligations, but
     haven't gotten proposals.

     W3C Workshop on future of Web Services; one paper was from
                 some
     financial industry organization (FSTC) that recommended
     establish policy languages for various functional and
     non-functional services such as QoS, ...

     Rich: was thinking of using Obligations to return privacy
                 data.
     Don't know if that is feasible or not.  [we asked him to post
     description to list so we can think about it]

VI.  Adjournment

    The meeting adjourned at 4pm.




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