How about this:
Agreement-Type classification values shall
be designated with the following attribute identifier:
urn:oasis:names:tc:xacml:3.0:ipc:resource:agreement-type
The DataType
of this attribute is http://www.w3.org/2001/XMLSchema#string.
This attribute data may contain multiple values.
This attribute can be used to indicate
whether or not a specific resource is governed by a particular
license arrangement. The range of values of the attribute
SHALL be “NON-DISCLOSURE AGREEMENT”, “PROPRIETARY INFORMATION
AGREEMENT”, “TECHNICAL DATA GRANT”, “COPYRIGHT GRANT”, “PATENT
GRANT”, “TRADEMARK GRANT”, “CROSS LICENSING GRANT”, and/or
“ROYALTY BEARING”.
Affiliation-Type classification values
shall be designated with the following attribute identifier:
urn:oasis:names:tc:xacml:3.0:ipc:subject:affiliation-type
The DataType
of this attribute is http://www.w3.org/2001/XMLSchema#string.
This attribute data may contain multiple values.
The range of values of the attribute SHALL
be “CUSTOMER”, “SUPPLIER”, “PARTNER”, “NON-PROFIT”,
“GOVERNMENT”, “PRIMARY CONTRACTOR”, “SUBCONTRACTOR”, “JOINT
DEVELOPMENT”, and/or “AUTHORIZED SUB-LICENSOR”.
IP-Type and IP-Data will still be replaced by the
Copyright/Patent/Proprietary/Public Domain/Trademark
Booleans.
We can discuss tomorrow.
Thanks
I don’t recall about favoring several
Boolean-valued attributes over a single attribute with a
defined range of string values. I checked the minutes and
did not see anything there.
I would prefer to see a defined range of string
values for a single ‘agreement-type’ attribute. If an
agreement fit into several categories there could be
multiple values.
Regards,
--Paul
Upon further consideration, we decided the
*-registration values aren’t needed, so I have removed them
from the forthcoming WD-06.
After the last TC call, I was under the
impression that using Booleans for a constrained list was
preferred over strings with defined values. I agreed to
replace the former IP-Data string options with a series of
Booleans. I decided to extend that method to agreement-type
and affiliation-type as well, in the interest of consistency
and in the hope that it would simplify policy authoring.
Hi John,
I don't see how the following structure makes it easier than
what you had before. Where's the catch to having too many
string data-types attributes?
Agreement-Type:non-disclosure-agreement
Boolean
Agreement-Type:proprietary-information-agreement
Boolean
Agreement-Type:technical-data-grant
Boolean
Agreement-Type:patent-grant
Boolean
Agreement-Type:trademark-grant
Boolean
Agreement-Type:cross-licensing-grant
Boolean
Agreement-Type:royalty-bearing
Boolean
In the WD05 in section 2.1.5 you used multi-valued attributes
so why the change to a list of boolean? It seemed cleaner in
WD05.
Also with regards to copyright and a time attribute (for
expiry), is copyright-registration the time at which
registration was achieved? I couldn't find the attribute in
WD05. I believe you introduced it in this email (http://lists.oasis-open.org/archives/xacml/201111/msg00005.html).
My question is: is having a boolean and a timestamp a bit
redundant. Could we infer that no timestamp means false and
the presence of a timestamp will help determine whether true
or false depending on whether the timestamp has expired.
True the boolean will help simplify policy authoring. It could
actually be a virtual attribute computed by a PIP rather than
stored in an underlying attribute store. But of course that's
an implementation discussion which is orthogonal to the
profile discussion.
Thanks John,
David.
On Fri, Nov 11, 2011 at 7:18 PM, Tolbert,
John W <john.w.tolbert@boeing.com>
wrote:
To reduce
the number of string data-types, we've decided to expand the
allowable strings for the "agreement-type" and
"affiliation-type" attributes into separate Boolean
attributes, as noted below. I plan on updating WD-06 with
this new structure and more explanatory text.
Resource attribute
Data Type
Copyright
Boolean
Copyright-Registration
String
Patent
Boolean
Patent-Registration
String
Proprietary
Boolean
Public-Domain
Boolean
Trademark
Boolean
Trademark-Registration
String
IP-Owner
String
IP-Designee
String
Agreement-Type:non-disclosure-agreement
Boolean
Agreement-Type:proprietary-information-agreement
Boolean
Agreement-Type:technical-data-grant
Boolean
Agreement-Type:patent-grant
Boolean
Agreement-Type:trademark-grant
Boolean
Agreement-Type:cross-licensing-grant
Boolean
Agreement-Type:royalty-bearing
Boolean
Agreement-Id
String
Effective-Date
Date
Expiration-Date
Date
Subject attribute
Data Type
Organizational-Affiliation
String
Affiliation-Type:customer
Boolean
Affiliation-Type:supplier
Boolean
Affiliation-Type:partner
Boolean
Affiliation-Type:non-profit
Boolean
Affiliation-Type:government
Boolean
Affiliation-Type:primary-contractor
Boolean
Affiliation-Type:sub-contractor
Boolean
Affiliation-Type:joint-development
Boolean
Affiliation-Type:authorized-sub-licensor
Boolean
Agreement-Id
String
Thoughts?
Thanks,
John
---------------------------------------------------------------------
To unsubscribe, e-mail: xacml-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: xacml-help@lists.oasis-open.org
--
David Brossard, M.Eng, SCEA, CSTP
VP
Product Marketing & Customer Relations
+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