[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 60-day Public Review for REST Profile of XACML 3.0 - Conformance issues
Hello, I would like some clarification from XACML TC on 2 issues I have with conformance clause 4.2.2 (Entry Point) of REST Profile, to check whether our implementation could be considered compliant or not. Let’s say we provide a multi-tenant REST API where each tenant has a specific “single entry point” for its RESTful XACML system: For tenant X, it would be: https://az.example.com/domains/X For tenant Y, it would be: https://az.example.com/domains/Y etc. My first issue is with the assertion urn:oasis:names:tc:xacml:3.0:profile:rest:assertion:home:documentation which seems to say there should be a single entry point for the XACML system across the whole web server, whereas here there is one per tenant (or domain). Have I got that wrong? Or is this kind of multi-tenant API still compliant somehow? Now regarding my next issue, when one makes a GET request on https://az.example.com/domains/X , one would get a status code 200 with the following response payload (some content omitted): <domain xmlns:atom="http://www.w3.org/2005/Atom"> … <atom:link rel="item" href="" title="Domain properties"/> <atom:link rel="item" href="" title="Policy Administration Point"/> <atom:link rel="http://docs.oasis-open.org/ns/xacml/relation/pdp" href="" title="Policy Decision Point"/> … </domain> My issue then is with the last sentence of 2.2.1 Entry Point which says: The XACML entry point representation that is returned SHOULD NOT contain anything other than links to other resources specified in this profile. (Side note: I would be interested to know why there should not be any other resource link btw.) However, the assertion urn:oasis:names:tc:xacml:3.0:profile:rest:assertion:home:pdp does not mention that requirement again but simply says: The XACML entry point representation SHOULD contain a link to the PDP. In my case I have a link to some “/pap” resource besides the link to the “/pdp” (and some other things); so all in all, would this be considered compliant in TC’s opinion? Thanks for any light on this. Kind regards, Cyril --- Cyril Dangerville Security Engineer, CISSP Thales Services From: Chet Ensign [mailto:chet.ensign@oasis-open.org] OASIS Members and other interested parties, Members of the OASIS eXtensible Access Control Markup Language (XACML) TC [1] have recently approved Special Majority Ballots [2] to advance REST Profile of XACML 3.0 Version 1.0 and JSON Profile of XACML 3.0 Version 1.0 as Candidate OASIS Standards (COSs). These COSs now enter a 60-day public review period in preparation for the member call for consent for OASIS Standards. The REST Profile specification defines a profile for the use of XACML in a RESTful architecture. The TC received 4 Statements of Use from Oracle, EMC, Axiomatics, and NextLabs [3]. The JSON profile proposes a standardized interface between a policy enforcement point and a policy decision point using JSON, leveraging the decision request and response structure specified in the core XACML standard. The TC received 3 Statements of Use from ViewDS Identity Solutions, Axiomatics AB, and NextLabs [4]. The Candidate OASIS Standards are available at: - REST Profile of XACML v3.0 Version 1.0 Candidate OASIS Standard 01 12 October 2017 Editable source (Authoritative): HTML: PDF: - JSON Profile of XACML 3.0 Version 1.0 Candidate OASIS Standard 01 12 October 2017 Editable source (Authoritative): HTML: PDF: ZIP distribution file (complete): For your convenience, OASIS also provides ZIP files of each of the COS. You can obtain the ZIP files at: REST Profile of XACML 3.0: JSON Profile of XACML 3.0: Public Review Period: This 60-day public review starts 08 November 2017 at 00:00 UTC and ends 06 January 2017 at 23:59 UTC. This is an open invitation to comment. OASIS solicits feedback from potential users, developers and others, whether OASIS members or not, for the sake of improving the interoperability and quality of its technical work. Additional information about the specification and the XACML TC may be found at the TC's public home page: Comments may be submitted to the TC by any person through the use of the OASIS TC Comment Facility as explained in the instructions located via the button labeled "Send A Comment" at the top of the TC public home page, or directly at: Comments submitted by TC non-members for this work and for other work of this TC are publicly archived and can be viewed at: All comments submitted to OASIS are subject to the OASIS Feedback License, which ensures that the feedback you provide carries the same obligations at least as the obligations of the TC members. In connection with these public reviews of “REST Profile of XACML 3.0 V1.0" and "JSON Profile of XACML 3.0 V1.0,” we call your attention to the OASIS IPR Policy [5] applicable especially [6] to the work of this technical committee. All members of the TC should be familiar with this document, which may create obligations regarding the disclosure and availability of a member's patent, copyright, trademark and license rights that read on an approved OASIS specification. OASIS invites any persons who know of any such claims to disclose these if they may be essential to the implementation of the above specification, so that notice of them may be posted to the notice page for this TC's work. ============== [1] OASIS eXtensible Access Control Markup Language (XACML) TC [2] Approval ballots: [3] Statements of Use for REST Profile of XACML 3.0 [4] Statements of Use for JSON Profile of XACML 3.0 ViewDS Identity Solutions: https://lists.oasis-open.org/archives/xacml/201707/msg00011.html RF on Limited Terms Mode --
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]