[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?
From: firstname.lastname@example.org [mailto:email@example.com]
On Behalf Of Martin Smith
Hal et al.--
Here's a revised draft comment per the process you laid out in your message earlier today. We might want to include the "picture" just to make it crystal clear what the "High Level Architecture" picture is.
PROPOSED XACML TC COMMENT TO NIST RE: SP 1800
"The OASIS XACML Technical Committee welcomes NIST's draft SP 1800-3 Attribute Based Access Control - Practice Guide as an addition to the guidance available for implementers of advanced access-control capability.
This is a comment [representing the views of the Technical Committee] on the SP 1800-3b document (Approach, Architecture, and Security Characteristics), which states it is “intended for individuals responsible for implementing IT security solutions.”
We note and agree with the stated context of the guidance, i.e., "This example solution is made of many commercially available parts. You might swap one of the products we used for one that is better suited for your environment."
We suggest that the guidance would be significantly enhanced by addition of an architectural description or depiction that is not product-specific. Such a logical solution architecture, indicating the componentization, interfaces and applicable standards, would permit implementers to use the guidance to configure a variety of product-specific solutions, thus increasing the applicability and impact of NIST's work.
A depiction of the logical solution architecture would also be simpler and easier to understand than the product-specific configuration in the current draft, since it would not have to depict the interactions needed only for the specific solution described in the draft.
We suggest that the High-Level Architecture included in the NCCOE’s ABAC Building Block V2, of April 1, 2015, would serve this purpose. This logical ABAC architecture depiction would provide a clear transition between the Practice Guide’s Overview of “demonstrable capabilities” (functional requirements) in Section 5.1 of the draft SP 1800b and the product-specific ABAC Build 1 Architecture currently depicted in Section 5.2.
We appreciate this opportunity to comment and look forward to publication of the final version of the Practice Guide. "
On Mon, Nov 23, 2015 at 11:21 AM, Hal Lockhart <firstname.lastname@example.org> 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.
Martin F Smith, Principal
BFC Consulting, LLC
McLean, Va 22102
703 389-3224 mobile