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: FW: XACML attestation


 

 

From: David Brossard [mailto:david.brossard@axiomatics.com]
Sent: Friday, August 04, 2017 12:57 PM
To: DANGERVILLE Cyril
Cc: Hal Lockhart
Subject: Re: XACML attestation

 

Hi Cyril,

 

The following is just my opinion and the TC could choose otherwise.

 

No, I have no plan to align them. The only possible alignment would be to modify the profile given the core spec is a standard. A change would lead us to XACML 4.0 (and we should definitely think about that - XACML could benefit from simplifications)

 

The reason I did the JSON profile the way I did it was to simplify things. XACML Core has 2 ways to send in XACML attributes. Either:

 

  • Attribute a with value {"asd", #string}; Attribute a with value {"asd", #string}; Attribute a with value {"asd", #string}; Attribute a with value {"asd", #string}
  • Attribute a with values [{"asd", #string}, {"asd", #string}, {"asd", #string}, {"asd", #string}]

All I did was say that there are too many ways to express the same thing. Having the datatype on the attribute level or the attribute value level is moot. If you do it on the attribute value level, it forces you to have yet another object and therefore creates unnecessary depth. If you have it on the attribute level, it reduces that complexity.

 

You can still express the same requests in JSON as you could in XACML. That's what matters.

 

I hope this helps,

David.

 

On Fri, Aug 4, 2017 at 5:58 AM, DANGERVILLE Cyril <cyril.dangerville@thalesgroup.com> wrote:

Hello,

Thanks for the proposal of remedies. I like the second option better: Put the shorthand forms under a different conformance clause…. But of course, it is up to you/the TC to decide. For the moment, I agree we cannot issue the Statement of Use.

 

I also have a minor question for my own understanding:

·         In the XML schema of XACML, the DataType is a property of the AttributeValue element. In other words, an Attribute may have AttributeValues of different DataTypes.

·         In the JSON Profile, the DataType is a property of the Attribute Object. In other words, an Attribute object has a single DataType.

Is there a reason for having such fundamental difference between the two models, and is there any plan to align them in a foreseeable future?

 

Kind regards,

Cyril

 

From: Hal Lockhart [mailto:hal.lockhart@oracle.com]
Sent: jeudi 3 août 2017 21:27
To: David Brossard; DANGERVILLE Cyril
Cc: FERRARI Romain
Subject: RE: 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.

 

Possible remedies:

 

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.

 

Hal

 

From: David Brossard [mailto:david.brossard@axiomatics.com]
Sent: Tuesday, July 25, 2017 12:23 PM
To: DANGERVILLE Cyril
Cc: Harold Lockhart; FERRARI Romain
Subject: Re: XACML attestation

 

Hi Cyril,

 

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 <cyril.dangerville@thalesgroup.com> wrote:

Hello David,

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 (4.2.2.1)?

 

Regards,

Cyril

 

 

From: David Brossard [mailto:david.brossard@axiomatics.com]
Sent: jeudi 20 juillet 2017 18:34
To: DANGERVILLE Cyril; Harold Lockhart
Subject: XACML attestation

 

Hi Cyril,

 

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?

 

Thanks,

David.

 

--

David Brossard
VP of Customer Relations

+46(0)760 25 85 75
Axiomatics

525 W. Monroe Suite 2310
Chicago 60661



 

--

David Brossard
VP of Customer Relations

+46(0)760 25 85 75
Axiomatics

525 W. Monroe Suite 2310
Chicago 60661



 

--

David Brossard
VP of Customer Relations

+1 312 774-9163

+1 502 922 6538

+46(0)760 25 85 75
Axiomatics

525 W. Monroe Suite 2310
Chicago 60661



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