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