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] Minutes for 7 February 2013 TC Meeting - updated

Also, along the lines of simplification, I'd be in favor of making the RequestDefaults simpler. Today the JSON encoding mirrors the XACML encoding which contains 1 element nesting too many.

In the JSON spec we currently have

"Request": {


            ”XPathVersion” : ”http://www.w3.org/TR/1999/REC-xpath-19991116


We could change to the following instead:

"Request": {

"RequestDefaults": http://www.w3.org/TR/1999/REC-xpath-19991116



"Request": {

”XPathVersion” : ”http://www.w3.org/TR/1999/REC-xpath-19991116



On Tue, May 14, 2013 at 5:56 PM, David Brossard <david.brossard@axiomatics.com> wrote:
I'll leave them out. They make no sense in the response. Thanks.

On Tue, May 14, 2013 at 3:21 AM, Steven Legg <steven.legg@viewds.com> wrote:

Hi David,

On 11/05/2013 8:41 AM, David Brossard wrote:
Hi Steven,

See my comments below:

    On 6/02/2013 4:38 PM, Steven Legg wrote:
     > Section 5.2.11: Version should be a string.

This is now fixed. Thanks.

    The IdReference object needs a
     > Value property to hold the URI of the referenced policy or policy set.

Yes, I noticed that when implementing the profile :-). I fixed it now.

     > IdReference in an XACML response must have a Version and must not have a
     > LatestVersion or EarliestVersion. For consistency with any future profile
     > that defines a JSON representation for policies and policy sets, I suggest
     > that you keep the properties as they are, but add a note that Version
     > is required and EarliestVersion and LatestVersion must be absent in a
     > response.

I don't see in the XACML 3.0 core spec where the EarliestVersion and LatestVersion must be absent. On lines
1961 to 1964 I read that

/EarliestVersion [Optional] /
/Specifies a matching _expression_ for the earliest acceptable version of the policy set referenced. /
/LatestVersion [Optional] /
/Specifies a matching _expression_ for the latest acceptable version of the policy set referenced./

It also says it is part of the PolicySetIdReference and PolicyIdReference.

Later in the spec, I do see that in the response, the following rule applies:

/The identifier and version of a policy which was applicable to the request. See section 5.11. The

<PolicyIdReference> element MUST use the Version attribute to specify the version and MUST NOT use the
LatestVersion or EarliestVersion attributes./

Does it mean that the attributes /LatestVersion /and /EarliestVersion /must not be included altogether?

That is how I've interpreted it. They aren't needed at all in the JSON encoding
of a response, so we could leave them out, but if we later create a JSON encoding
for policies, then we would need to put them back in, or have two JSON objects
with the same name but different members, or use a different name for references
in a Policy. Take your pick which strategy is going to be the least confusing.


> It
would make sense.



        On Fri, Feb 8, 2013 at 12:41 AM, rich levinson <rich.levinson@oracle.com
        <mailto:rich.levinson@oracle.com> <mailto:rich.levinson@oracle.__com <mailto:rich.levinson@oracle.com>>>


             Minutes for 7 February 2013 TC Meeting - updated
               (added link below to ref material on the NIST site
                that describes the Policy Machine in more detail)

             Time: 15:00 ET (GMT-0500)
             Tel: 513-241-0892
             Access Code: 65998

             I. Roll Call

             Voting Members:
             Richard Hill    The Boeing Company
             Mohammad Jafari Veterans Health Administration
             Steven Legg     ViewDS
             Rich Levinson   Oracle
             Hal Lockhart    Oracle
             Bill Parducci   Individual
             Erik Rissanen   Axiomatics
             John Tolbert    The Boeing Company

             Robert van Herk Connectis

               Approve Minutes:
                24 January 2013 TC Meeting


                      hal: minutes approved, no obj

             II. Adminstrivia

               Conformance Tests v3.0


                  john: email contains a chart for conformance compliance; looking
                      for vendors to fill out the yes/no's as to whether support
                      is available for the features represented as list of the
                      xml elements in the xacml core spec plus a list of the combining
                      algorithms in the core spec.

               XACML REST Profile WD-07 uploaded, request for Vote


                      15 day public review
                        john moves
                        richard h seconds
                        no obj to unanimous

               XACML XSPA Profile WD-01 request for Vote


                 hal: is it 2.0 or 3.0
                 mohammad: will require schema support for 3.0, so 2.0 at present
                 hal: some other issues on front page
                 mohammad: will look at these issues;
                 hal: vote deferred until new draft or issues closed; hal will email comments

               XACML v3.0 Published


                 hal: official notification that 3.0 is now published OASIS Standard (OS)
                      the email has URLs for obtaining the specs;
                 hal: will contact abbie barbir for itut

               XACML Combining Algorithm Profile WD-03 status update:
                30 day Public Review has begun


                hal: both EC-US and IPC are in 15d pub rev;
                      comments? none so far

               XACML EC-US status update:
                15 day Public Review

               XACML IPC status update:
                15 day Public Review


                hal: Combining Algorithm Profile WD-03 is in 30d pub rev;
                      comments? none so far

               XACML JSON Profile WD-11 uploaded


                 new wd for json profile; wd10->wd11 based on stephen input
                 erik attr assign in obl optional
                 hal: should look at:

               Policy Machine reference
                The Policy Machine - email ref from prateek mishra

                      hal: you have to "buy" specification; anyone know more?
                       no replies
                      rich: I just checked the site, and there are quite a few direct
                       refs to material (free) describing the PM:

        <http://csrc.nist.gov/pm/__references-library.html <http://csrc.nist.gov/pm/references-library.html>>

               XACML RSA demo:
                 john: boeing ready for tagging part
                      stephen posted link
                      have been working w nextlabs
                      still not all people that are needed
                 hal: boeing, oracle, uds, nextlabs were only ones on this wk's call
                      only 2 more calls before interop - please send people to
                      call so info is rcvd
                 hal: oasis will make banner; kmip also put up a banner, company
                      logo's connected in box w chains around it. Last year we
                      showed components but not logos; open to suggestions to
                      give to oasis by next wed.
                 hal: slide deck from last yr needs some updates but should be usable;
                      respond to email

             III. Issues

               JSON Profile


                 stephen: has minor chgs plus one thing on id's but has not heard
                       from david yet

               Attributes of Relations


                  hal: should we tackle these 2 issues
                  erik: think we are converging on something; perf concern about
                      large sets of tuples, stephen said could optimize by
                      processing subsets; concern that xacml might be translatable
                      to db searches;
                  stephen: what should extensions actually look like, mohammad came
                      up w sql-like approach; in condition implicitly selects, and
                      need diff syntax for joins;
                  mohammad: thinks a simple join will work
                  stephen: tuple sets soon has duplication within nested context;
                      because of that abandoned nested;
                  rich: wants to mention that sql not a good representation, should
                      be more like attr-val-entity;
                  stephen: agrees in general
                  mohammad: agrees but when tried to extend hier ran into issues and
                      thats when sql emerged.
                  rich: will try to elaborate in followup email

               Policy Labeling


                 stephen: still looking into alternatives to admin approach; practical
                      necessity to dup admin policies nearly everywhere there is issue
                      wrt unsafe policies being integrated w admin policies; reduction
                      graphs lead to some perf issues
                 erik: fwd chaining doesn't have same problem; top down recursive
                      could limit intermediate delegates;
                      also issue w np-complete;
                 stephen: hasn't found way to deal w malicious policy;
                 hal: in old days disc about detecting invalid policies;
                 hal: recollection of use cases; large ratio between general pop
                       vs admin people; maybe that helps;
                 rich: what is issue of ctl
                 stephen: sibling admin policy; writer of admin has to anticipate
                      places where delegates will be extending, and making
                      sure delegates have right authority; only sibling within
                      same policy set.
                 hal: as opposed to putting admins high in the tree;
                 stephen: but hi in tree can't authorize things lower in the tree;
                 stephen: one interesting use case is discretionary access ctl, such
                      as every owner of resource is authorized, so they can write
                      policies for their own resources;
                 hal: "can do, can del" was intended to address that; if you are allowed
                      to do it, you can delegate it as a policy; originally was in
                      admin profile but we moved it to core.
                      "can do, can del" is popular access model, implicitly mentioned
                      in sections 2.7, 2.9 of core spec.

               Other business:

                hal: next call in 2 weeks 21-Feb-2013

                meeting/call adjourned: 3:51PM 7-Feb-2013


             To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.
          Follow this
             link to all your TCs in OASIS at:


        David Brossard, M.Eng, SCEA, CSTP
        Product Manager
        +46(0)760 25 85 75 <tel:%2B46%280%29760%2025%2085%2075>

        Axiomatics AB
        Skeppsbron 40
        S-111 30 Stockholm, Sweden
        http://www.linkedin.com/__companies/536082 <http://www.linkedin.com/companies/536082>


David Brossard, M.Eng, SCEA, CSTP
Product Manager
+46(0)760 25 85 75
Axiomatics AB
Skeppsbron 40
S-111 30 Stockholm, Sweden

David Brossard, M.Eng, SCEA, CSTP
Product Manager
+46(0)760 25 85 75
Axiomatics AB
Skeppsbron 40
S-111 30 Stockholm, Sweden

David Brossard, M.Eng, SCEA, CSTP
Product Manager
+46(0)760 25 85 75
Axiomatics AB
Skeppsbron 40
S-111 30 Stockholm, Sweden

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