RE: IPC WD-07 feedback

Hi Richard,

Thanks for the reply.

For Item 2, I’m suggesting that we add to the normative text a definition of how the expiration-date should be used in date comparisons.

If we define the expiration-date as the first date on which the agreement is not valid (the exclusive upper bound of the agreement lifetime), then all policy implementations should test using <, not <=. The legalese of “This agreement is valid from July 1, 2012 up to but not including January 1, 2013” would be unambiguously represented as effective-date=2012-07-01, expiration-date=2013-01-01. Policies should consistently implement agreement validity tests as (effective-date <= current-date AND current-date < expiration-date)

We could instead define expiration-date to be the last date that the agreement is valid (inclusive upper bound of the agreement lifetime).

It doesn’t matter to me which one we choose, but I think we should specify one or the other to avoid variations in interpretation.

Effective-date is clearly inclusive, the first date that the agreement is valid.

For item #3, the XMLSchema#date definition (http://www.w3.org/TR/xmlschema-2/#date) indicates that the date type does not include time values.

“A "date object" is an object with year, month, and day properties just like those of dateTime objects, plus an optional timezone-valued timezone property.”

We should use the XMLSchema#dateTime type to support agreement periods of less than a day and starting/ending at times other than midnight.

-Danny

Danny Thorpe

Product Architect | | Quest Software - Now including the people and products of BiTKOO | www.quest.com

From: Hill, Richard C [mailto:Richard.C.Hill@boeing.com]
Sent: Wednesday, January 18, 2012 12:16 PM
To: Danny Thorpe; xacml@lists.oasis-open.org
Subject: RE: IPC WD-07 feedback

Danny,

In response to your comments:

1.) I will fix typo.

2.) I'm not sure what’s being requested here. Can I get some clarification or was this just a comment for discussion?

3.) Since the DataType of this attribute is http://www.w3.org/2001/XMLSchema#date the ISO 8601 Date and Time Formats format allows granularity down to the second. I believe we’re ok here.

4.) I will add your text suggestion to the description of the Encrypt Obligation.

XACML TC,

If there are no other comments by the end of the week I will update the IPC with 1 & 4 above and upload by early next week.

Thanks,

Richard C. Hill

The Boeing Company
Information Security
(206) 856-6654

From: xacml@lists.oasis-open.org [mailto:xacml@lists.oasis-open.org] On Behalf Of Danny Thorpe
Sent: Monday, January 16, 2012 3:55 PM
To: xacml@lists.oasis-open.org
Subject: [xacml] IPC WD-07 feedback

1. Typo on line 192: “fo” -> “of”

2. In Sections 2.1.10 Effective-Date and 2.1.11 Expiration-Date it’s unclear whether the given date values are inclusive or exclusive to the agreement or resource lifetime.

For example, is the Expiration-Date value the last date that the agreement/resource is valid (current-date <= expiration-date), or the first date that the agreement/resource is invalid (current-date < expiration-date)? The last sentence of 2.1.11 (“This attribute may also convey the date on which other resource attribute elements are no longer valid; for example, when a copyright or patent expires”) suggests to me an exclusive endpoint (< test).

The non-normative copyright example in section 4 treats the effective and expiration dates as inclusive bounds (effective <= current <= expiration).

3. As Date types, Effective-Date and Expiration-Date cannot represent agreements or resources that have a valid lifetime less than one full day, or that start or end at specific times of day. Example: license to (re)broadcast protected content at a public event only during a specific 2 hour window of time.

I realize that traditional business contracts are phrased in terms of whole dates, not hour and minutes, but in the emerging world of on-demand content / media streaming, being able to specify a license’s effective period with a granularity of minutes or portion of a day may be increasingly useful.

(A hacky way around full-day granularity might be to leverage the optional time zone portion of the XMLSchema date type to approximate a time of day as the beginning of the day in a particular time zone, but this is really ugly)

4. Section 2.3.1 Encrypt doesn’t state what the PEP is required to do when it receives an Encrypt obligation.

Text suggestion, modeled after 2.3.2 Marking: “The encrypt obligation can be used to command PEPs to encrypt the resource.”

-Danny

Danny Thorpe

Product Architect | | Quest Software - Now including the people and products of BiTKOO | www.quest.com

xacml message