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] Comment on NIST/NCCOE draft -- existing XACML architecture artifacts?


Hal--where do we stand on the proposed comment on the draft NIST SP 1800-3?  Have we heard from enough people? (Reminder to all: comment period closes this Friday, Dec 4.)  

Thanks,

Martin



On Mon, Nov 23, 2015 at 12:02 PM, Martin Smith <bfc.mclean@gmail.com> wrote:
Hal--Good plan. Thanks,

Martin


On Mon, Nov 23, 2015 at 11:21 AM, Hal Lockhart <hal.lockhart@oracle.com> wrote:

Yes, this is pretty much exactly what I had in mind. I think you are right that it is better to suggest using NIST’s own materials.

 

I suggest you draft a comment to NIST from the TC along the lines you suggest and post it here.

 

Unfortunately I did not realize that we will not meet again before the deadline. However, since this is not an OASIS mandated vote, we can be a bit more informal if no one objects. I suggest we follow one of two procedures.

 

1. People who agree with your draft can post a +1 to it. If we get a majority of the voting members, we can submit the comment as coming from the TC,

 

2. If the members prefer, after you post the draft I will create a ballot for a resolution supporting the comments.

 

Either way, if we get a simple majority of the voting members, the Chairs will send the comment on behalf of the TC.

 

If not, you can still submit the comment in the name of any individuals (including yourself) who have endorsed it.

 

If there seems to be any reason for it, we can still have a voice vote on Dec 10.

 

Hal

 

From: Martin Smith [mailto:bfc.mclean@gmail.com]
Sent: Friday, November 20, 2015 5:28 PM
To: Hal Lockhart
Cc: Rich Levinson; William Parducci; XACML TC
Subject: Re: [xacml] Comment on NIST/NCCOE draft -- existing XACML architecture artifacts?

 

Hal, all--Thanks--that looks like material that might be used. 

 

However, I looked again at the other recent NCCOE paper, the so-called ABAC Building Block.  That is referenced in the draft SP 1800-3b ("b" is the "medium-sized" volume of the set that we have been discussing)  one time in a footnote, not very prominently, as a "white paper."  However, in that ABAC Building Block paper is a pretty good logical diagram, here:

 

Inline image 1

 

(I could quibble about how a few things are represented, but this looks like a good 80% solution.) 

 

Here's a link to the whole document:

 

Assuming that it would be easier and more acceptable to NIST to add material from one of their own docs to the draft 1800-3, we might just suggest that they include this diagram as a logical architecture before presenting their physical (product-specific) solution diagram. We might even suggest they highlight the parts of this diagram that the physical solution covers (which is most of it.) 

 

Looking past the proposed suggestion to include a logical ABAC architecture diagram, does anyone have other observations on the draft 1800-3?

 

And do we agree that we can endorse the above diagram as--is, or do people want to ask them to tweak it?

 

Whatever we do, we need to do it pretty soon:

 

Comments on this publication may be submitted to: abac-nccoe@nist.gov

Public comment period: September 30, 2016 through December 4, 2016

 

 

Regards,

 

Martin

  

 

PS-- I also promised last meeting to locate and send around the functional capabilities which the 1800-3 physical implementation sought to demonstrate. Here they are: 

 

The scope of this build is the successful execution of the following capabilities:

n identity and attribute federation between trust partners

n user authentication and creation of an authentication context

n fine-grained access control through a policy enforcement point (PEP) closely coupled with the

application

n creation of attribute-based policy definitions

n secondary attribute requests

n allowing RP access decisions on external identities without the need for pre-provisioning

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

On Thu, Nov 12, 2015 at 11:49 AM, Hal Lockhart <hal.lockhart@oracle.com> wrote:

I think it was me not Rich.

 

What I had in mind was something like section 3.1 of the core spec.

 

Also I and others have done many overview of XACML/ABAC architecture presentations over the years. For example, This presentation Prateek and Rich did at RSA in 2009.  https://www.oasis-open.org/committees/download.php/22335/RSA-V09.ppt

 

Or the attached one I created for the 2012 RSA Showcase.

 

Hal

 

 

From: Martin Smith [mailto:bfc.mclean@gmail.com]
Sent: Wednesday, November 11, 2015 3:46 PM
To: rich levinson; William Parducci
Cc: XACML TC
Subject: [xacml] Comment on NIST/NCCOE draft -- existing XACML architecture artifacts?

 

Rich/Bill--

 

Last meeting in discussing possible TC comment on the NIST/NCCOE draft, I believe Rich expressed reluctance to make a comment like "you should do more work to make x change in your document" rather than offering specific text adds or changes. He also suggested that there might be something produced in the TC in the past that could be offered as a logical architecture to be added to the NIST doc. (Addition of a non-product-specific architecture diagram to the NIST document was my suggested comment.)

 

So, this is just a reminder to ask if Rich or anyone can suggest a TC-produced artifact that we might provide to NIST for incorporation in the document. 

 

Martin


 

--

Martin F Smith, Principal

BFC Consulting, LLC

McLean, Va 22102



 

--

Martin F Smith, Principal

BFC Consulting, LLC

McLean, Va 22102




--
Martin F Smith, Principal
BFC Consulting, LLC
McLean, Va 22102



--
Martin F Smith, Principal
BFC Consulting, LLC
McLean, Va 22102
703 506-0159
703 389-3224 mobile


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