Hi Ray,
Finally I got round to editing the doc w/ your comments. Please see inline and thanks a bunch for such detailed review.
Things are shaping up really well! I've had interest from several non-XACML folks (analysts, devs) so it looks promising.
Cheers,
David.
On Fri, Aug 24, 2012 at 11:16 AM, Sinnema, Remon <> wrote:
Hi David,
General
- WD04 still identifies itself as WD03 [fixed]
- The copyright messages states 2011, is that OK?
[yes, that's when it started]
- Element and attribute names should be formatted using the "CODE temp"
[where is the style defined?]
style
- There should be a section for the IANA registration
[fixed - can you help me add the content?]
1.2 Normative References
- There should be a reference to ECMAScript
[fixed]
(http://www.ecma-international.org/publications/files/ecma-st/ECMA-262.pdf),
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)
[fixed]
may be useful as well
- There should be a reference to the Multiple Decision Profile
[fixed]
2 Vocabulary
- "key-value pair" => "member" (see section 2.2 of RFC 4627 and the
ECMAScript spec)
[fixed]
4.1 Assumed default values
- "string" => either "String" or "http://www.w3.org/2001/XMLSchema#string"
[fixed]
4.2 Object Names
- We need something similar for attributes
[fixed]
4.3 Object cardinality
- The reference to section 5.1 should be a link
[it is already 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
What do you mean here?
- "when it can safely be inferred from the value of the attribute" => Does
this need to be more precise?
I think we further specify that...
- "within integer range" => This needs to be more precise, for instance
"within signed 32 bit integer range"
I want to rely on the definition of integer from the XML spec since this is what XACML uses.
4.5 Non-normative example
- Shouldn't this use the "{Non-normative}" label instead of indicating the
status in the title?
[fixed]
- "interpretor" => "interpreter"
[fixed]
- "#integer" => either "integer" or
"http://www.w3.org/2001/XMLSchema#integer"
[fixed]
5.1 Class Diagram
- The link from AttributesReference to Attributes misses cardinality on the
AttributesReference side
[fixed]
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.
Agreed. I haven't fixed that at all yet.
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
"http://www.w3.org/2001/XMLSchema#boolean"
- "key-value pair" => "member"
- "The ReturnPolicyIdList can be omitted in the JSON representation." =>
Isn't that implied by "Default value"?
You have a point. Is still saying it making sure we all understand the same?
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?
[fixed]
5.2.3.2 Non-normative example
- "{.}" => "[.]"
5.2.4.1 Non-normative example:
- This example doesn't follow the escaping rule. The value also doesn't
start with a double quote
[fixed]
5.2.5 The Attribute Object representation
- "Boolean" is missing from the "Type" for "Value"
[fixed]
5.2.5.1 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
(urn:oasis:names:tc:xacml:2.0:subject:role)?
I guess it is better to do so but it doesn't look good to have long IDs.
5.2.7 The RequestReference object representation
- "id" => "Id"
[fixed]
6.1 Class Diagram
- The self-link on StatusCode misses cardinality
[fixed]
6.2 Representation of the XACML response in JSON
- There are no sections on Advice and Obligation
There is: 6.2.5 and further...
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
[fixed]
6.2.4.1 Non-normative example
- There is a "." before "Value" that shouldn't be there
[fixed]
6.2.5 The Obligations object representation
- "ObligationOrAdvice" => "Obligation"
What do you mean?
6.2.7 The ObligationOrAdvice object representation
- "in the JSON representation, the naming has been harmonized." => Why?
This harmonization goes against what is previously defined (re. keeping the names intact). In this case though I felt it wasn't adding any value. What is everyone's view on that?
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?
Thanks,
Ray
From: David Brossard<>
To:
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
section.
> -- Mr. David Brossard
--
David Brossard, M.Eng, SCEA, CSTP
Product Manager
+46(0)760 25 85 75
Axiomatics AB
Skeppsbron 40
S-111 30 Stockholm, Sweden
http://www.linkedin.com/companies/536082
http://www.axiomatics.com
http://twitter.com/axiomatics
