[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: FW: XACML attestation
Sorry for the slow response.
The definition of Statement of use begins:
"Statement of Use", with respect to a Committee Specification, is a written statement that a party has successfully used or implemented that specification in accordance with all or some of its conformance clauses, identifying those clauses that apply, and stating whether its use included the interoperation of multiple independent implementations.
The JSON Profile has only a single conformance clause effectively covering all the normative parts of the spec.
The issues noted by Cyril are clearly in sections indicated to be Normative.
If an implementation sends the shorthand forms to a different implementation which does not understand them, they will not interoperate.
Therefore, it appears to me that ThalesGroup cannot issue a statement of use as things stand today.
Make the shorthand forms non-normative.
Put the shorthand forms under a different conformance clause so people could claim basic-only or basic-with-shorthands.
Require receivers to recognize shorthand forms, but don’t require anyone to generate them. (I think this is what the current Profile implies, but it could be made explicit.)
Drop the shorthand forms entirely.
Obviously there are various tradeoffs to each alternative.
Out of curiosity, why is your JSON implementation not conformant? Was it a timing thing whereby you implemented before I was done? Is it just the case you did not implement all the "tricks"?
Re. the shorthand notation, the language in the spec is unclear (my own language I must add ahem): it says
The full XACML [...] URI can also be used in JSON as the JSON shorthand type codes are a convenience, not a replacement.
You could interpret that either way I suppose. Hal, what's your take on this? I would say it is mandatory because otherwise the PEP cannot send a meaningful request. Either that or the PDP throws a meaningful exception taht the PEP can act on and use the full blown identifiers.
On Tue, Jul 25, 2017 at 8:59 AM, DANGERVILLE Cyril <firstname.lastname@example.org> wrote:
As of now, we support the REST profile and we also support JSON on our REST API, but not according to the JSON profile specification. Nevertheless, we are quite interested in such attestation because we believe this could promote AuthzForce in a good way.
So short answer: today we don’t implement the JSON profile. Therefore, if you need to issue the statement shortly, then I’m afraid you can’t mention AuthzForce for the moment.
Long answer: we can add this to our roadmap. Therefore, if you don’t find any other candidate and you accept to delay your announcement, I can get back to you next week with a more precise answer, that is to say:
1) whether this actually feasible for us, and
2) when we can have it implemented if this is a matter of days or weeks.
I first need to check with my team what is the necessary effort to adapt our format to the JSON profile, and whether we can afford it.
Just to clarify on what is mandatory and what is not in the spec, because this is not absolutely clear to me, I have a few questions:
1. Is it mandatory to support the JSON shorthand type codes for data-types (3.3.1)?
2. Is it mandatory to support the shorthand notations for standard XACML categories (22.214.171.124)?
From: David Brossard [mailto:email@example.com]
Right now the JSON profile of XACML is a committee specification. For it to become a standard, it needs to have 3 attestations of implementation or use.
An attestation looks like the following:
<company_name> has successfully implemented JSON Profile of XACML 3.0 Version 1.0 Committee Specification 01, approved on 11 December 2014, in accordance with the conformance clauses in Section 9. This did not include inter-operation with independent implementations.
Do you think you could issue such a statement on behalf of AuthZForce? I do believe it implements the REST and JSON profiles of XACML?
+1 312 774-9163
+1 502 922 6538