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: RE: [xacml] New Issue#61: WS-XACML: How are the contents of XACMLAuthzAssertions represented in the base XACML Policies


The features of XACML 2.0 perfectly match these requirements. The use of
policies and policy sets along with policy combining algorithms allows
policies that address different concerns (privacy, application
structure, regulatory requirements), or different scopes (department,
division, organization) to be created by distinct administrators who are
not closely coordinating their activities. The processing rules of XACML
will automatically collect all the policies relevant to a given
situation and the combining rules will resolve any conflicts.

In past, we have had debates as to whether or not there is such a thing
as a policy consistency check. At a minimum there are numerous
difficulties with determining if a set of policies "conflict" in the
intuitive sense of the word, except in the most simple and obvious
cases. 

Of course if I have a policy with two rules, one of which says if
subject is a member of the foo group, permit and another which says if
subject is a member of the foo group, deny, intuitively we would say
this is probably not how the policy was intended to be written. However,
XACML has no problem evaluating such a policy and giving a deterministic
answer (which depends on the combining algorithm in force). A tool to
detect this kind of thing could be developed, but many feel it would
have little value as this thing is easy for a person to spot and few
policies are written this way.

Now consider a more realistic example. Suppose one policy says members
of the foo group can access resources with the bar attribute value
greater than 100 and another policy says that members of the blah group
are not allowed to access resources with a splat attribute value of less
than 1000. Are these conflicting? The answer depends on the assignment
of attributes to subjects and resources. It also may depend on the
particular access request. Further, the attribute assignments may not be
known at the time of policy creation. In fact, the assignments my change
over the lifetime of the policies so that at one point in time they
always conflict and at other time the never conflict and perhaps at a
third time they conflict for some requests and not for others.
  
Hal

> -----Original Message-----
> From: Smith, Martin [mailto:Martin.Smith@DHS.GOV]
> Sent: Wednesday, December 20, 2006 4:59 PM
> To: Anne.Anderson@sun.com; Anthony Nadalin
> Cc: Rich Levinson; xacml@lists.oasis-open.org; frankmccabe@mac.com
> Subject: RE: [xacml] New Issue#61: WS-XACML: How are the contents of
> XACMLAuthzAssertions represented in the base XACML Policies
> 
> Anne --
> 
> For what it's worth, in my organization we have been viewing privacy
rules
> as just one of several sets of rules controlling access (to data
assets.)
> We envisioned each set of rules as being managed by a separate
authority
> (e.g., Chief Privacy Officer for privacy rules based on the Privacy
Act)
> using some tooling interface of the PAP and being applied jointly in
the
> access-control PDP.
> 
> This implies a potentally large set of rules, which may raise some
> engineering issues (lots more cycles determining access than in
executing
> query.)
> 
> It also suggests the need for a "consistency check" (in the PAP?) to
make
> sure rules don't contradict each other. (For extra value-added, create
a
> "rules inconsistency resolution" service to facilitate among rules
> authorities.)
> 
> Martin
> 
> 
> Martin F. Smith
> Program Manager, Information Sharing & Identity Management
> DHS CIO Office
> 202 447-3743 (New! as of 10/2006)
> 202 441-9731 cell
> 
> 
> ________________________________
> 
> From: xacml-return-125-martin.smith=dhs.gov@lists.oasis-open.org on
behalf
> of Anne Anderson - Sun Microsystems
> Sent: Wed 12/20/2006 3:30 PM
> To: Anthony Nadalin
> Cc: Rich Levinson; xacml@lists.oasis-open.org
> Subject: Re: [xacml] New Issue#61: WS-XACML: How are the contents of
> XACMLAuthzAssertions represented in the base XACML Policies
> 
> 
> 
> 
> 
> Anthony Nadalin wrote On 12/20/06 10:12,:
> > One thing that bothers me (well I have several),
> >
> > 1) is why is this called WS ? as I'm not seeing a tie to web
services,
> > just to WS-Policy
> 
> XACMLAssertions were originally designed as a way to include XACML
> policies in WS-Policy instances, and thus tie XACML more directly to
Web
> services, but the XACMLAssertions are certainly useful for more than
> WS-Policy.  WS-Authorization and WS-Privacy have been mentioned
numerous
> times, although I have not seen anything moving forward, and it seems
to
> me that the XACMLAuthzAssertion and the XACMLPrivacyAssertion should
be
> able to fill the roles possibly envisioned for those two
specifications.
> 
> The other two parts of the WS-XACML specification - the authorization
> token and passing Attributes in the SOAP header - are more explicitly
> Web services oriented.
> 
> That said, the XACMLAssertions are useful both in WS-Policy and in
other
> contexts.  I have proposed dropping the non-Assertion sections from
> WS-XACML, and if so, I would be open to changing the name to something
> like "XACML Authorization and Privacy Policy Assertions" (XAPPA? :-)
> 
> > 2) missing the tie to WS-Security, as SAML is not the only
assertions
> > that are used, this effort should be able to tie into the claims
used in
> > WS-Security
> 
> Are you referring to ways an XACMLAssertion could refer to WS-Security
> claims used in the SOAP Security Header?  I could define a new
standard
> vocabulary identifier for such claims, and could give an example of
> placing constraints on them.  Do you want to supply an example of a
> claim you would like to see used?
> 
> > 3) there are 2 sides the requestor and receiver, each should be able
to
> > represent policy, not seeing this clearly in this proposal
> 
> Section 6 of WD 8 shows a client XACMLPrivacyAssertion and a Service
> XACMLPrivacyAssertion.  What more would you like to see?
> 
> The academic team I am working with has made use of XACMLAssertions in
a
> multi-stage privacy policy negotiation protocol, so once our paper is
> finished, perhaps I could include that as an example that would show
the
> two sides even more clearly.
> 
> Thanks for the review and comments.
> 
> Regards,
> Anne
> 
> >
> > Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
> > Inactive hide details for Anne Anderson - Sun Microsystems
> > <Anne.Anderson@sun.com>Anne Anderson - Sun Microsystems
> > <Anne.Anderson@sun.com>
> >
> >
> >                         *Anne Anderson - Sun Microsystems
> >                         <Anne.Anderson@sun.com>*
> >
> >                         12/20/2006 08:23 AM
> >                         Please respond to
> >                         Anne.Anderson@sun.com
> >
> >
> >
> > To
> >
> > Rich Levinson <rich.levinson@oracle.com>
> >
> > cc
> >
> > xacml@lists.oasis-open.org
> >
> > Subject
> >
> > Re: [xacml] New Issue#61: WS-XACML: How are the contents of
> > XACMLAuthzAssertions represented in the base XACML Policies
> >
> >
> >
> >
> > Hi Rich,
> >
> > The problem to me with having WS-XACML policies integrated with
other
> > policies is that it is not possible in general to extract an
isolated
> > <Apply> statement from a normal policy - that <Apply> might be in
the
> > middle of an "...:and" function, for example, that requires it to be
> > associated with other constraints.  Or it might be in an "...:or"
such
> > that it is not necessarily required to be true.
> >
> > That was why I suggested that WS-XACML policies be contained in a
> > top-level separate PolicySet.  The policies in that set can be
"AND"ed
> > with the remaining policies using an appropriate combining
algorithm.
> > Then during evaluation of the remaining policies, if you know the
> > WS-XACML policies have already evaluated to "true", then you don't
have
> > to re-evaluate the WS-XACML PolicySet.
> >
> > <PolicySet PolicySetId="all:policies"
> >             PolicyCombiningAlg="ordered-deny-overrides">
> >
> >
> >     <PolicySet PolicySetId="ws-xacml:policies"
> >             PolicyCombiningAlg="deny-overrides">
> >
> >          <!-- These don't have to be re-evaluated if you know they
> >               must have been satisfied in order to get this far -->
> >
> >         ... WS-XACML Assertion Requirements,
> >             written as <Policy> elements ...
> >
> >     </PolicySet>
> >
> >     <PolicySet PolicySetId="other:policies"
> >             PolicyCombiningAlg="deny-overrides">
> >
> >         ... Remaining policies, which can assume
> >             the WS-XACML Assertions have already
> >             evaluated to "true"/"permit" ...
> >
> >     </PolicySet>
> > </PolicySet>
> >
> > Another idea is to use the WS-XACML policy constraints to partially
> > evaluate the remaining policies.  For example, if you know that a
> > WS-XACML policy requiring "role" to be a subset of {"manager",
> > "auditor"} must evaluate to "true" before other policies are
evaluated,
> > then you can go through the remaining policies and replace any
> > predicates that require "role" to be a subset of {"manager",
"auditor"}
> > with "True".  But I don't think it is worthwhile pursuing this: when
> > there are multiple WS-XACML policy alternatives, you don't know
which
> > one will be the one that evaluated to "True", the cost of
determining
> > the intersections with every predicate in the other policies is
high,
> > and in many cases the intersections can't be fully evaluated (e.g. a
> > predicate that says "role" must be a subset of {"manager",
"individual
> > contributor"}).
> >
> > I misspoke yesterday when I said the Capabilities could be included
in
> > the overall XACML policies as "or"ed constraints.  The
"Capabilities"
> > are things the issuer of a policy is willing and able to do for the
> > other party and, as such, play the role of an XACML Request to the
other
> > party, and not an XACML Policy that the other party must satisfy.
So
> > above I said to write the only the Requirements as Policy elements
in
> > the WS-XACML PolicySet.
> >
> > Regards,
> > Anne
> >
> > Rich Levinson wrote On 12/19/06 19:46,:
> >  > Hi Anne,
> >  >
> >  > I guess I have not been thinking along the lines of  "WS-XACML"
> policies
> >  > as being a distinct class of xacml Policy, but that the info in
this
> >  > profile would
> >  > be worked into existing xacml Policy structures, but maybe the
> analysis
> >  > below might be interpreted from either perspective.
> >  >
> >  > Basically, the point of view I am looking at this from is that I
see
> >  > that web
> >  > service access is now effectively a 2 step process, whereas
before
> >  > WS-Policy
> >  > was introduced, it was essentially a 1 step process where one
just
> >  > submitted one's
> >  > request, for example using WS-Security, and hoped for the best.
> >  >
> >  > It is clear the 2 step process has the advantage that in step 1,
the
> >  > client is
> >  > now formally told in advance, what the reqts are to successfully
> submit
> >  > the request. Then, in step 2, based on the input from step 1, the
> client
> >  > can construct a request that should be in compliance with the
policy
> >  > requirements that will be applied by service infrastructure when
the
> >  > request is submitted.
> >  >
> >  > So, from my view, step 2 doesn't change that much from what
currently
> >  > exists today (except for new features such as the privacy
obligations
> >  > that are currently being included in this profile - I think the
> >  > "Capabilities"
> >  > are also new, but I see them more relevant in step 1 than step 2
-
> i.e.
> >  > if the client doesn't like the service capabilities, then it
probably
> > never
> >  > gets to step 2).
> >  >
> >  > Bottom line is that my expectation is that many
XACMLAuthzAssertions
> that
> >  > are supplied to the client will, in general, reflect aspects of
> existing
> >  > policies
> >  > that are in current operation. For example, maybe a service
requires
> >  > that a client
> >  > submit a valid "gold club member number" in some element of the
> request
> >  > and this
> >  > element is evaluated as part of authorization.
> >  >
> >  > Now, in order to make the service more readily accessible by
users,
> the
> >  > service
> >  > provider decides to put a XACMLAuthzAssertion in the WSDL that
will
> > specify
> >  > this constraint.
> >  >
> >  > If you agree that the above is a possible or typical az type of
> >  > scenario, ...,
> >  > then it appears to me the next logical concern is that: somehow,
in
> the
> >  > Policy
> >  > that contains the "gold card member number" constraint,  a "flag"
of
> some
> >  > sort would be appropriate to apply to that constraint in order
that a
> >  > service
> >  > provider would know by reading the Policy for that resource
> (presumably
> >  > thru some TBD policy access/distribution mechanism). Possibly the
> >  > constraint
> >  > could be a VariableDefinition that could be referenced in the
main az
> >  > policy
> >  > and a separate Policy segment for use in constructing
> > XACMLAuthzAssertions.
> >  >
> >  > My sense is that something would be useful in the WS-XACML
profile
> that
> >  > would advise on how to construct new policies and adapt existing
> policies
> >  > to address this issue (i.e. issue 61).
> >  >
> >  > I think the profile identifies 3 major classes of info:
> >  >
> >  >     Requirements of the az type - i.e. constraints that are
typically
> >  >        found in existing policies.
> >  >
> >  >     Requirements of the privacy type - i.e. constraints that bind
the
> >  > user as
> >  >        to how the resource is used once acquired (these may be
> considered
> >  >        just another az type in general, but they are "new" in the
> sense
> >  > that
> >  >        they are things the user has to "agree to" and as such the
> user
> >  > needs
> >  >        to know what is being agreed to, and how in the request to
> > represent
> >  >        the fact that the agreement is accepted). As such these
reqts
> >  >        may lend themselves to be separable off in a separate
Policy
> or
> >  >        PolicySet.
> >  >
> >  >     Capabilities in general - the service is simply adding info
to be
> >  > presented
> >  >        to users indicating things the service is willing to
commit
> to,
> >  > and as such
> >  >        would seem to be properly considered part of the Policy
> governing
> >  > the
> >  >        publication and use of this service by the Provider
> organization.
> >  >
> >  > Another path that might make sense would be to model these
> > XACMLAssertions
> >  > as xacml:Obligations, whereby the "obligation" would be to inform
the
> > user
> >  > of this Policy info, which could be presented directly thru PEP
> access,
> >  > if, for
> >  > example, the request was denied because something was missing
that
> might
> >  > be in this category of info (i.e. this would allow the info to
> provided
> >  > either
> >  > in advance via WS-Policy or on the spot in a "1-step" manner).
> >  >
> >  > I think the above or parts of it might be considered guidelines
for a
> >  > possible
> >  > proposal and explanatory context for what might be considered to
be
> added
> >  > to the profile, but it probably needs to be shaken out a bit,
> > assuming that
> >  > you and/or others think it's valid subject matter for this
profile.
> >  >
> >  > Also, I think it is possibly in synch with your proposal. i.e. it
> looks
> >  > to me like we are
> >  > generally on the same path - ex. where you pointed out section
3.2
> for
> >  > containing
> >  > Apply elements, I was considering those to be the az-type
> requirements,
> >  > and your
> >  > site-specific naming convention looks like it might be similar to
the
> >  > "flag" I suggested
> >  > to apply to items in existing policies.
> >  >
> >  >     Thanks,
> >  >     Rich
> >  >
> >  > Anne Anderson - Sun Microsystems wrote:
> >  >
> >  >> Hi Rich,
> >  >>
> >  >> Thanks for the endorsement.
> >  >>
> >  >> As for identifying WS-XACML policies, I had not considered the
> >  >> problem, but it sounds like proposals might be useful.
> >  >>
> >  >> What occurs to me is to have all WS-XACML policies collected
into a
> >  >> special PolicySet that is combined with other internal
> >  >> PolicySets/Policies so all are evaluated if necessary to reach a
> result.
> >  >>
> >  >> The WS-XACML PolicySet could have an identifier that uses a
special
> >  >> site-specific naming convention: e.g.
> >  >> urn:somecompany:...:xacmlauthzassertion:policyset:20
> >  >>
> >  >> Isolated <Apply> elements don't occur in normal XACML, so for
> >  >> Requirements, they should be expressed as a Policy in the form
> >  >> described in Section 3.2.  For Capabilities, they should be
> expressed
> >  >> as a similar Policy, except using ...:function:or rather than
> >  >> ...:function:and to combine the <Apply> elements (I will add
this
> >  >> equivalence to the next Revision).  Again, a site-specific
naming
> >  >> convention could be used to notify the XACML...Assertion builder
> that
> >  >> the <Apply> elements from that policy MAY be extracted: e.g.
> >  >> urn:somecompany:...:xacmlauthzassertion:requirements:25
> >  >> urn:somecompany:...:xacmlauthzassertion:capabilities:25
> >  >>
> >  >> Requirements and Capabilities that "go together" could be put
into
> >  >> individual PolicySet instances inside the "WS-XACML PolicySet".
> >  >>
> >  >> That certainly isn't a complete solution, and I need to think
more
> >  >> about using Capabilities in a standard XACML policy, but maybe
this
> is
> >  >> a start.
> >  >>
> >  >> Regards,
> >  >> Anne
> >  >>
> >  >> Rich Levinson wrote On 12/15/06 16:57,:
> >  >>
> >  >>> Hi Anne,
> >  >>>
> >  >>> I just want to mention that I think the profile is a great
document
> >  >>> and a really valuable example of how XACML can be applied.
> >  >>>
> >  >>> I quickly looked over your suggestion and I think I must not
have
> >  >>> expressed my point clearly.
> >  >>>
> >  >>> What I am thinking is that these XACMLAssertions,  both the
> >  >>> XACMLAuthzAssertion and the XACMLPrivacyAssertions are
> >  >>> elements that can be included in a ws:Policy elements and used
> >  >>> in wsdl and other policy containers to express the requirements
> >  >>> to clients as to what they need to do to successfully access
the
> >  >>> web service. I think we probably agree on that, and, if so,
then
> >  >>> I can get to what the issue is that I am considering.
> >  >>>
> >  >>> I would expect (correct me if I am wrong, but this is what I am
> >  >>> thinking) that it is perfectly reasonable, if not likely, that
> these
> >  >>> XACMLAssertions will be part of an overall xacml architecture
> >  >>> in various enterprise environments. As such, it is likely that
> >  >>> there are one or mores PDP out there in the enterprise that are
the
> >  >>> home of a collection of xacml policies, as well as being the
> decision
> >  >>> points handling PEP requests.
> >  >>>
> >  >>> It is also my expectation that this PDP (or at least the people
who
> >  >>> adminster the PDP) will likely consider the Web Services to be
> >  >>> Resources that its policies in general will cover.
> >  >>>
> >  >>> So, I put myself in the position of one of these PDP admins and
> >  >>> ask myself, how do I create a XACML Policy that will contain
all
> >  >>> the info I want to govern the access to this web service
Resource
> >  >>> (as suggested by the para 2 in section 4, etc.). What I am
thinking
> >  >>> is that only a subset of this info should go to the
> XACMLAssertions,
> >  >>> which will end up in the wsdl, but the rest of the info I want
to
> keep
> >  >>> private and just use at runtime to validate and authorize
requests
> and
> >  >>> produce Responses etc.
> >  >>>
> >  >>> So, the question is: how do I flag the subset of XACML Policy
info
> >  >>> that is targeted for the XACMLAssertions - I guess I am also
> assuming
> >  >>> that the WebService Manager, in whatever form it will take,
will in
> >  >>> general make a XACMLRequest to the PDP to get the Policy or
> >  >>> Policies governing this Resource. That Manager would then need
to
> >  >>> be able to select from the XACML Policy (as opposed to the WS
> Policy,
> >  >>> which, on the other hand, the Manager is populating for setup
etc.)
> the
> >  >>> elements:
> >  >>>
> >  >>>       <element ref="*xacml:Policy*" minOccurs="*0*"
maxOccurs="*1*"
> />
> >  >>>       <element ref="*xacml:PolicySet*" minOccurs="*0*"
> >  >>> maxOccurs="*1*" />
> >  >>>       <element ref="*xacml:Apply*" minOccurs="*0*"
> >  >>> maxOccurs="*unbounded*" />
> >  >>>   <element ref="*xacml-context:Request*" minOccurs="*0*"
> >  >>> maxOccurs="*1*" />
> >  >>>
> >  >>> that can be moved from the xacml:Policy data to the
Capabilities
> and
> >  >>> Resources
> >  >>> elements of the XACML*Assertion.
> >  >>>
> >  >>> So, I am wondering what the original xacml:Policy, which I
assume
> can
> >  >>> contain
> >  >>> the source elements for these XACML*Assertions, will look like
and
> >  >>> how one
> >  >>> would go about selecting the appropriate info therefrom.
> >  >>>
> >  >>> Bottom line is that the examples you suggested below, appear to
me
> to
> >  >>> be the
> >  >>> final step of this process: i.e. some entity has put these
> ws:Policy
> >  >>> blocks as
> >  >>> part of the wsdl or other that the client encounters before
making
> >  >>> the actual
> >  >>> access. To use your first example:
> >  >>>
> >  >>>     <Requirements>
> >  >>>        Has signed license agreement
> >  >>>     </Requirements>
> >  >>>
> >  >>> I would expect that somewhere in the PDP policy store that a
> >  >>> xacml:Attribute
> >  >>> might exist with an AttributeValue: "Has signed license
agreement",
> >  >>> and that
> >  >>> when one queries the PDP for this xacml:Policy that they are
able
> to
> >  >>> obtain this
> >  >>> AttributeValue and put it in the Requirements element of the
> ws:Policy.
> >  >>>
> >  >>> OK, so now hopefully that explains how I am looking at this and
> maybe
> >  >>> there
> >  >>> is some complete aspect to this that I am missing, that will
help
> >  >>> explain it all.
> >  >>>
> >  >>>        Thanks,
> >  >>>        Rich
> >  >>>
> >  >>>
> >  >>>
> >  >>>
> >  >>> Anne Anderson - Sun Microsystems wrote:
> >  >>>
> >  >>>> Hi Rich,
> >  >>>>
> >  >>>> Thanks for the feedback.
> >  >>>>
> >  >>>> Rich Levinson wrote On 12/15/06 14:05,:
> >  >>>>
> >  >>>>>
> >  >>>>>         61. WS-XACML: How are the contents of
> XACMLAuthzAssertions
> >  >>>>>         represented in the base XACML Policies
> >  >>>>>
> >  >>>>> (Submitted by: *Rich*)
> >  >>>>>
> >  >>>>> Reading the spec, it appeared to me that an important piece
of
> info
> >  >>>>> might be missing (or either I missed it or it intentionally
is
> not
> >  >>>>> there, but that's the point of this issue). As an entry point
to
> >  >>>>> this potential issue, consider statement in Section 4, p 23,
para
> >  >>>>> 2, that says
> >  >>>>>
> >  >>>>> "For security reasons, many entities are unwilling to publish
> their
> >  >>>>> complete authorization and access control policies.
Therefore, an
> >  >>>>> XACMLAuthzAssertion </xacml/AuthzAssertion> MAY not be a
complete
> >  >>>>> specification of an entity's authorization and access control
> >  >>>>> policy. A service MAY choose to publish all or a subset of
the
> >  >>>>> XACMLauthorization or access control policy it will apply
with
> >  >>>>> respect to particular policy targets."
> >  >>>>>
> >  >>>>> How are the subsets of the core xacml policies identified as
to
> >  >>>>> what should and should not be made public?
> >  >>>>
> >  >>>>
> >  >>>>
> >  >>>>
> >  >>>> It is completely site-dependent as to what is published and
what
> >  >>>> isn't. Particular trade/service communities (on-line
bookstores,
> >  >>>> etc.) might standardize policy vocabularies to be used in
stating
> >  >>>> XACMLAuthzAssertions or XACMLPrivacyAssertions for their
sites.
> >  >>>>
> >  >>>> As an example, Sun certainly isn't going to publish its
enterprise
> >  >>>> policy.  But consider some fictitious software download site
> >  >>>> maintained by Sun; for this site, Sun might publish the
following:
> >  >>>>
> >  >>>> <wsp:exactlyOne>
> >  >>>>   <XACMLAuthzAssertion>
> >  >>>>     <Requirements>
> >  >>>>        Has signed license agreement
> >  >>>>     </Requirements>
> >  >>>>     <Capabilities>
> >  >>>>        Provide trial version
> >  >>>>     </Capabilities>
> >  >>>>   </XACMLAuthzAssertion>
> >  >>>>   <XACMLAuthzAssertion>
> >  >>>>     <Requirements>
> >  >>>>       Has signed license agreement
> >  >>>>       Has paid for Level 3 support
> >  >>>>     </Requirements>
> >  >>>>     <Capabilities>
> >  >>>>       Provide current production version
> >  >>>>     </Capabilities>
> >  >>>>   </XACMLAuthzAssertion>
> >  >>>> </wsp:exactlyOne>
> >  >>>>
> >  >>>> Would it help to include an example like this?
> >  >>>>
> >  >>>> Also, it would be of interest to
> >  >>>>
> >  >>>>> see some example policies that contained entities that end up
in
> >  >>>>> the Capabilities and Requirements sections of the Assertions.
I
> am
> >  >>>>> particularly interested in how privacy requirements might be
set
> up
> >  >>>>> in the original policy since these are generally not part of
the
> >  >>>>> authorization process, per se', but possibly could be
considered
> to
> >  >>>>> be modelled as XACML Obligations. Any guidance on this in
reply
> to
> >  >>>>> issue or changes to doc would be much appreciated.
> >  >>>>
> >  >>>>
> >  >>>>
> >  >>>> Consider a service policy saying the service will provide a
copy
> of
> >  >>>> its current price list if the client agrees to retain it no
longer
> >  >>>> than 30 days and not to disclose it to 3rd parties.  The
service
> >  >>>> also says it will not disclose the client's personal
information
> to
> >  >>>> 3rd parties.
> >  >>>>
> >  >>>>   <XACMLPrivacyAssertion>
> >  >>>>     <Requirements>
> >  >>>>        max-data-retention-days <= 30
> >  >>>>        data-disclosure == "ours" }
> >  >>>>     </Requirements>
> >  >>>>     <Capabilities>
> >  >>>>        resource-id="current-price-list"
> >  >>>>        //p3p10full/POLICIES/POLICY/RECIPIENT/* subset-of {
"ours"
> }
> >  >>>>     </Capabilities>
> >  >>>>   </XACMLPrivacyAssertion>
> >  >>>>
> >  >>>> A client policy might say:
> >  >>>>
> >  >>>>   <XACMLPrivacyAssertion>
> >  >>>>     <Requirements>
> >  >>>>        resource-id="current-price-list"
> >  >>>>        //p3p10full/POLICIES/POLICY/RECIPIENT/* subset-of {
"ours"
> }
> >  >>>>     </Requirements>
> >  >>>>     <Capabilities>
> >  >>>>        max-data-retention-days <= 30
> >  >>>>        data-disclosure == "ours" }
> >  >>>>     </Capabilities>
> >  >>>>   </XACMLPrivacyAssertion>
> >  >>>>
> >  >>>> There is another example using XACML's XML syntax in Section 6
of
> > WD 8.
> >  >>>>
> >  >>>> Is this what you are looking for?  If you could describe ways
in
> >  >>>> which the examples in Section 6 are inadequate, I could
provide
> more
> >  >>>> examples or better examples.
> >  >>>>
> >  >>>>>
> >  >>>>> Status: *OPEN*
> >  >>>>>
> >  >>>>
> >  >>
> >
> > --
> > 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
> >
> 
> --
> 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] | [List Home]