OASIS eXtensible Access Control Markup Language (XACML) TC

  • 1.  IPC profile proposed attribute list

    Posted 11-12-2011 00:18
    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


  • 2.  Re: [xacml] IPC profile proposed attribute list

    Posted 11-12-2011 16:28
    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


  • 3.  RE: [xacml] IPC profile proposed attribute list

    Posted 11-16-2011 21:21
    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.    From: David Brossard [mailto:david.brossard@axiomatics.com] Sent: Saturday, November 12, 2011 8:28 AM To: Tolbert, John W Cc: xacml@lists.oasis-open.org Subject: Re: [xacml] IPC profile proposed attribute list   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


  • 4.  RE: [xacml] IPC profile proposed attribute list

    Posted 11-16-2011 21:34
    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     From: xacml@lists.oasis-open.org [mailto:xacml@lists.oasis-open.org] On Behalf Of Tolbert, John W Sent: Wednesday, 16 November, 2011 15:21 To: David Brossard Cc: xacml@lists.oasis-open.org Subject: RE: [xacml] IPC profile proposed attribute list   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.      From: David Brossard [mailto:david.brossard@axiomatics.com] Sent: Saturday, November 12, 2011 8:28 AM To: Tolbert, John W Cc: xacml@lists.oasis-open.org Subject: Re: [xacml] IPC profile proposed attribute list   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


  • 5.  RE: [xacml] IPC profile proposed attribute list

    Posted 11-17-2011 00:41
    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   From: Tyson, Paul H [mailto:PTyson@bellhelicopter.textron.com] Sent: Wednesday, November 16, 2011 1:34 PM To: Tolbert, John W; David Brossard Cc: xacml@lists.oasis-open.org Subject: RE: [xacml] IPC profile proposed attribute list   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     From: xacml@lists.oasis-open.org [mailto:xacml@lists.oasis-open.org] On Behalf Of Tolbert, John W Sent: Wednesday, 16 November, 2011 15:21 To: David Brossard Cc: xacml@lists.oasis-open.org Subject: RE: [xacml] IPC profile proposed attribute list   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.      From: David Brossard [mailto:david.brossard@axiomatics.com] Sent: Saturday, November 12, 2011 8:28 AM To: Tolbert, John W Cc: xacml@lists.oasis-open.org Subject: Re: [xacml] IPC profile proposed attribute list   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


  • 6.  Re: [xacml] IPC profile proposed attribute list

    Posted 11-17-2011 18:50
    Hi John, This is what I meant on the call: 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#anyURI .  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 “urn:oasis:tc:xacml:ipr-profile:non-disclosure-agreement”, “urn:oasis:tc:xacml:ipr-profile:proprietary-information-agreement”, “urn:oasis:tc:xacml:ipr-profile:technical-data-grant”, “urn:oasis:tc:xacml:ipr-profile:copyright-grant”, “urn:oasis:tc:xacml:ipr-profile:patent-grant”, “urn:oasis:tc:xacml:ipr-profile:trademark-grant”, “urn:oasis:tc:xacml:ipr-profile:cross-licencing-grant”, and/or “urn:oasis:tc:xacml:ipr-profile:royalt-bearing”. /Erik On 11/17/2011 01:40 AM, Tolbert, John W wrote: 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   From: Tyson, Paul H [ mailto:PTyson@bellhelicopter.textron.com ] Sent: Wednesday, November 16, 2011 1:34 PM To: Tolbert, John W; David Brossard Cc: xacml@lists.oasis-open.org Subject: RE: [xacml] IPC profile proposed attribute list   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     From: xacml@lists.oasis-open.org [ mailto:xacml@lists.oasis-open.org ] On Behalf Of Tolbert, John W Sent: Wednesday, 16 November, 2011 15:21 To: David Brossard Cc: xacml@lists.oasis-open.org Subject: RE: [xacml] IPC profile proposed attribute list   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.      From: David Brossard [ mailto:david.brossard@axiomatics.com ] Sent: Saturday, November 12, 2011 8:28 AM To: Tolbert, John W Cc: xacml@lists.oasis-open.org Subject: Re: [xacml] IPC profile proposed attribute list   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