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: Groups - Request / Response Interface based on JSON and HTTP for XACML 3.0 Version 1.0 uploaded

Hi David,

- WD04 still identifies itself as WD03
- The copyright messages states 2011, is that OK?
- Element and attribute names should be formatted using the "CODE temp"
- There should be a section for the IANA registration

1.2 Normative References
- There should be a reference to ECMAScript
as it defines the JSON grammar (in section 15.12.1) and the data types (in
section 8) that are referenced in section 4.4.1
- A reference to the JSON media type (http://tools.ietf.org/html/rfc4627)
may be useful as well
- There should be a reference to the Multiple Decision Profile

2 Vocabulary
- "key-value pair" => "member" (see section 2.2 of RFC 4627 and the
ECMAScript spec)

4.1 Assumed default values
- "string" => either "String" or "http://www.w3.org/2001/XMLSchema#string";

4.2 Object Names
- We need something similar for attributes

4.3 Object cardinality
- The reference to section 5.1 should be a link

4.4.1 Overview
- "property" => A property could be a function (see section 4.2 of the
ECMAScript spec). I don't think we should allow that
- "when it can safely be inferred from the value of the attribute" => Does
this need to be more precise?
- "within integer range" => This needs to be more precise, for instance
"within signed 32 bit integer range"

4.5 Non-normative example
- Shouldn't this use the "{Non-normative}" label instead of indicating the
status in the title?
- "interpretor" => "interpreter"
- "#integer" => either "integer" or

5.1 Class Diagram
- The link from AttributesReference to Attributes misses cardinality on the
AttributesReference side

5.2 Representation of the XACML request in JSON
- As Hal mentioned on the last call, spelling everything out may not be such
a good idea. Every time we make a change to the XACML XML schema, we would
have to update this profile as well. Also, it's easy to make little mistakes
(see 5.2.7). Finally, it's a dry read. Instead, we could explain how to
algorithmically convert XACML XML to XACML JSON. In fact, most of that is
already done in section 4. We should keep the examples, and maybe add the
corresponding XML representations to them. The same holds for section 6.2.
5.2.1 The Request object representation
- "boolean" => either "Boolean" or
- "key-value pair" => "member"
- "The ReturnPolicyIdList can be omitted in the JSON representation." =>
Isn't that implied by "Default value"?

5.2.3 The Attributes object representation
- "The value of the Content property must be valid, XML." => XML may contain
quotes that interfere with the JSON value and therefore must be encoded.
This is spelled out in section 5.2.4, so maybe there should be a reference
to that section? Non-normative example
- "{.}" => "[.]" Non-normative example:
- This example doesn't follow the escaping rule. The value also doesn't
start with a double quote

5.2.5 The Attribute Object representation
- "Boolean" is missing from the "Type" for "Value" Non-normative example
- If you're going to use an RBAC example, wouldn't it be better to use the
attribute ID from the RBAC profile

5.2.7 The RequestReference object representation
- "id" => "Id"

6.1 Class Diagram
- The self-link on StatusCode misses cardinality

6.2 Representation of the XACML response in JSON
- There are no sections on Advice and Obligation

6.2.3 The Status object representation
- The StatusDetail element in XML may contain arbitrary XML, so there should
be a similar comment as in section 5.2.3 Non-normative example
- There is a "." before "Value" that shouldn't be there

6.2.5 The Obligations object representation
- "ObligationOrAdvice" => "Obligation"

6.2.7 The ObligationOrAdvice object representation
- "in the JSON representation, the naming has been harmonized." => Why?

7 Transport
- I would like to see this profile restricted to a representation only,
without mandating anything for transport. That should be the purpose of the
REST profile

8 Examples
- There should be a section with a sample response

9 # Conformance
- Each normative section should have an identifier and this section should
list those identifiers in a table that states what is mandatory and what is
optional. Alternatively, maybe we could simply refer to the core spec?


From: David Brossard<david.brossard@axiomatics.com>
To: xacml@lists.oasis-open.org
Date: Mon, 20 Aug 2012 13:12:01 -0700 (PDT)

> Submitter's message
> Finalized work on the XACML response, added a note on HTTPS. Restructured
the document to extract paragraphs common to the Request and > Response
> -- Mr. David Brossard

Attachment: smime.p7s
Description: S/MIME cryptographic signature

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