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: F2F Minutes Thursday 6/30 AM


Attendees:

·         David Chadwick

·         John Tolbert

·         David Choy

·         Erik Rissanen

·         Gregory Neven

·         Rich Levinson

·         Hal Lockhart

Agenda

-          Administrative

-          What to do to finish 3.0

-          Open Topics (Distribution Protocol, WS-*)

-          OpenAz

-          RSA Interop

-          BTG Continuation

-          Distributed Combining

Administrative

Hal: We will not have a call next week (July 7) since there was a lot of time spent on F2f

 

What to do to complete 3.0

Hal: Don’ t like the idea of hanging at committee spec indefinitely.  We are changing small things, but we are not changing the fundamental functionality.  There is enough there for people to build.  2-wk public review and then we can vote.

Hal: I will send Stephen Lake (currently reviewing spec) a note to see how much more we expects to find

Erik: I will do the same with Remon. 

Hal: is that acceptable to everyone?  (no objections). 

 

Open Topics

-Policy Distribution Protocol

Hal: I think it was Tuesday I introduced the idea of a Policy Distribution protocol.  Is that of interest to others?

David Choy: Is the protocol a push model?

Hal: Logically it is a push model, but it is probably a pull model.  This is because it may be difficult for a PDP to accept a incoming call.

Erik: What is the motivation for making it a standard?  All the products have this.

Hal: if the future the environment will have a lot of pdps that may be different from the lifecycle manager.

David Chad..:

Erik: what is the method by which a PDPs would identify themselves to determine which policy get deployed.

Hal: I was thinking that they would have a unique identifier like a URI.

Erik: We manage multiple cohorts on a single PDP

Hal: this could support that.  Why don’t I make a specific proposal.  I was thinking of making something simple that is XACML specific.

-WS-XACML, WS-Security

Hal: What should we do with WS-XACML? No one seems to be working on this.  WS-XACML is about policy and relating policy to web services.  It seems like interest in soap based web services is waning. 

Hal: I looked at the Metadata spec Erik did and I think that would be useful to complete.

Erik: Yes.

Hal: That’s all I can think of in terms of old things.

Hal: There was Tim Moses’ work on how do we generalize XACML beyond access control.  It seemed pretty simple, but the charter for this group is Access Control so it was abandoned.

Hal: WS-Security is being implemented by Oracle, IBM, MSFT, etc.  There is a nagging question about the relationship, but no active work.

Rich: I can look at the WS-XACML work to see where it is at.

 

OpenAz

Hal: We originally contributed materials about 2 years ago.  Code is in sourceforge.  Original objective was to make it easier for people to build PEPs.  When we first contributed we had azapi and we have a new one that is easier.  One of the ideas was to decouple development and operations.  You can change the apps but not the infrastructure or vise versa.

Rich: (see zip file sent to XACML). Naming change EZapi is now PEPapi.  The two files show a shorthand line at a time notation and then generates XML. 

110629-OpenAz-xacml-f2f-03.pptx, presented by Rich.

Slide 2: Conceptual Framework Illustrates current thinking of a model use to try to show how XACML fits in with the environment.  Policy people are talking about high level terms, but don’t understand the runtime objects.  At Netegrity, we had a policy server and we had to integrate with a lot of this stuff.  Started thinking about how XACML maps to Netegrity.  The most critical thing were these Canonical Attributes and how they map to these Enterprise Objects.  What we have with the XACML TC is policy logic and attributes, but we haven’t looked at how to clamp this to the runtime enterprise stuff.   This is a high level view of the origin of OpenAz

Slide 4: OpenAz Perspective.  It is all about looking about how to package up random runtime objects and shoot them down to a XACML PDP.

Slide 5: OpenAz Design.  

Rich: The original AzAPI was too difficult for application developers.

Hal: The AzAPI was designed for infrastructure like IDEs, containers, etc.

David Chadwick: We have an API in PHP

Hal: We are interested in many language bindings

Rich: We had an app developer try this, and we came up with PepApi.  You can pass anything in (dump in the objects) and then there are these mappers (from PepAPI to AzAPI)

Slide 6: How does OpenAz map to Conceptual Framework

Slide 7: What about existing PDPs? Why do we have to go to XACML, we have our own objects in our pdp and we want a high performance channel to our PDP.  PepAPI can translating request to the correct PDP.  We have three solid implementations.  C++ from NextLabs, Oracle Product, and Reference Java Implementation from Oracle.

David Chadwick: Is the canonical form enforced or is it done with a mapper.

Rich: in order for me to be convinced that we can pull the objects out and translate to a canonical standard form (e.g. like a tap).  The canonical representation coming out of PepAPI is a key element of it for monitoring it.

Hal: what I want to build now is a remote client underneath this to SAML.

Slide 8: What does OpenAz currently do

Slide 9: Use Cases Demo’d by OpenAz

Slide 10: Advanced Use Cases

Slide 11: Sample Shorthand Notation.  TS stands for target subject and TR target resource.

Hal: The topic of a shorthand notation has come up a few times.

Slide 12: Tutorials

Slide 13: Oauth Simulation.  Last fall oauth became the rage so I started to look into this. 

Slide 14: Details of Oauth simulation. 

Hal: Oauth talks about “client”, which is an intermediary.

Rich: The key components of oauth are resource owner.  Resources are stored on a resource server. 

David Chadwick: you need to ask two things.  Can the owner have access to this and then can he delegate.

Hal: We added a new function to 3.0 (access permitted) to do the second part. You can do this check at access time, versus at issuance time.  Makes it easier to compare policies.

Slide 16: What is the purpose.  Demonstrates the relationship between oauth and openaz. Proves that it works.

Slide 17-18: What is real and what is simulated

Slide 19-20: XACML shorthand policies used in oauth simulation.

Review the remainder of the slides on your own.

Greg: UMA, I think there is a tie in with UMA as well.

 

RSA Interop

Hal: there is a desire to show XACML interop demo at RSA next year.  One possibility is around oauth.  Plusses are the buzz factor, but may distract from the xacml value.

David Chadwick: Oauth is a continually moving topic

Hal: Oauth 2 is looking more stable.  But there are also big holes in the spec.

David Chadwick: separate the discussions of RSA interop from what to demo.

Greg (and others): it is only using a simple capabilities of XACML. 

John: IP might be good, so as not to be pigeon holed in healthcare.

David Chadwick: Sticky documents might be a good demo.

Hal: I invite people to contribute ideas.  I will start a tread.  People will expect that we demonstrate 3.0.

 

[Break]

 

BTG Continuation

David: Erik mentioned yesterday that the encoding of the btgstate + RC can be passed from the PDP to the PEP. The two components that work out the glass to break are the PIP and the Obligation Service.  Everyone else (PEP, PDP) just copy the information around.

David Choy, Erik: You many not need two PEP (PEP-S, PEP-R)

David Chadwick: Yes, those could be collapsed.  It complicates things because you need to pass information between the two PEPs.

DC: What we standardize is the unique identifier of the obligation.

DC: what is passed is “btg[day, subject(role)]” and it is treated as just a string (attribute) until the PIP gets it.  The PIP knows how to process this with the RC to identify a glass


Rich: I think that this needs to be brought out more.  That I have to think about.

DC: in the document.  There will be one section for each component that needs to be standardized.  There will be an appendix for each component that can’t be done in v2. 

Erik: Can you do this without the second obligation?

DC:  Yes, but we have different pilots and we and to make this as application independent as possible.  That would require the PEP-s to know something.

Hal: I would like to see a component architecture picture.

DC: [Draws picture on board]

 

Distributed Combining

David Choy: Has an immediate requirement.  In a larger enterprise you do not have a single administrator and many workgroups across the organization.  If you partition the resources it is fine, but in reality it is not the case.  A workgroup belongs to a bigger organization and corporation.  The bigger organization and corporation wants to apply policy as well.  The question is how to combine them.  The combining algorithm only applies at the policy set container.  Who is going to own the larger container?  It is not the outcome that is combined, but the authority.  We are talking about a hierarchy of authorities.  One way to solve this is to create a hierarchy of authorities.

David Chadwick: what we do is have multiple PDP (e.g. legal PDP) and then a master pdp who deals with the conflict resolution algorithm.  It determines the conflict resolution algorithm based on the request.  You can’t do this in XACML, since the algorithm is based on the request, not the policies.

Hal: can you give an example of this?

David Chadwick: For example a person can read their personal data.  So in this case, we use grant overrides if it is the user. 

Erik: you can use first applicable and put the law first.

David Choy: but there is not one around who can order the policies.  Nobody knows these.

Hal: there is this tendency that a PDP represents an organization, but it is really a cohort of policy. Now that we have a common language not it is possible to build tools and analyze who can do what.  Having a bunch of PDPs is going back to the bad old days.  If we need more combining algorithms we can do that to address these use cases.

David Chadwick: So we can bring an example.

David Choy: a lot of organizations dealing with records management, which is corporate.  We you declare a document a business record then nobody can delete them and no updates to the content.

Andy: so there is an operational management issue and then there is the capability of the language.  So is this a tooling issue.

Hal: You need to have a structure that represents the organization that can organize who can write what kinds of policies.

David: most often the corporate policy is talking about deny, but not always the case.

Hal: there are some things that you will never enforce in a policy, like Fair Use.  But this type of problem I think we can handle. Erik gave an example.

David Choy: it is unthinkable that the you would have a policy set that would point to all policies

Hal: It would point to some small number of structures.

Andy: is the requirement about the expressiveness of the language is expressive or is it if about the manageability of the access control.

David: we have to build a system that will going beyond the standard.

Hal: anything that has to do with how we make a decision is in scope.  I would think if we look at the problem, we will find that XACML can handle it.  I think this is a worthwhile thing to look at.

 

Closing Discussion

Andy: Asked about process for starting post 3.0 profiles Interest in Rights Management Profile?

Hal: Draft a spec, Oasis Admin to get a template and name. Maybe Patent Issues with rights management.

Rich: XrML Rights Management Content Guard in WS-Security, XSPA is another initiative.

David Chadwick: There is a combining issue with BTG, where an indeterminate may had the BTG response.  I think there is a work item here.

Hal: Close

 

 

Andy Han

NextLabs, Inc.

andy.han@nextlabs.com

650-577-9101 ext 201

www.nextlabs.com

 


- --------------------------------------------------------------------
STATEMENT OF CONFIDENTIALITY

The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain confidential or privileged information. No representation is made on its accuracy or completeness of the information contained in this electronic message. Certain assumptions may have been made in the preparation of this material as at this date, and are subject to change without notice. If you are not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this e-mail and any attachment(s) is strictly prohibited. Please reply to the sender at NextLabs Inc and destroy all copies of this message and any attachments from your system. ======================================================================


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