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: [xacml] Groups - IPC WD-06 uploaded

I agree with John. In fact, in terms of the OASIS process, the appropriate way to encourage implementation and use is to take a spec to Committee Specification. I don't see any reason not to move some consensus of the functionality forward to CSD or CS. Given that the profile basically just defines the semantics of some identifiers, I don't think it would be a great problem if version 2.0 ended up being radically different from version 1.0 based on real world experimentation with 1.0.
If anybody has some additional data based on using these kinds of constructs in the real world, by all means tell us about it and we can incorporate what you have learned. Absent that, we need to encourage people to try this stuff and tell us what is wrong or missing. I don't think we should wait until we understand the problem perfectly to propose constructs which may be immediately useful to some parties and encourage experimentation by others.
-----Original Message-----
From: Tolbert, John W [mailto:john.w.tolbert@boeing.com]
Sent: Wednesday, November 30, 2011 6:39 PM
To: Doron Grinstein; Tyson, Paul H; xacml@lists.oasis-open.org
Subject: RE: [xacml] Groups - IPC WD-06 uploaded

I would still like to advance a corrected version of WD-06 to at least committee draft status for the following reasons:


·         I believe the underlying data model is sound.  We have captured a sufficient number of intellectual property concepts that can be expressed as XACML attributes and used for access control and auditing purposes.  We know that others are already using the existing CD version successfully.  I intend to make use of the attributes as currently defined in WD-06.  Implementers are free to use the entire set of attributes or a subset of these attributes as their business requirements dictate.  Moreover, implementers may choose to extend these attributes for their own purposes.  This is similar to how profiles of SAML, particularly the web SSO profile, are employed today:  architects design identity federation relationships based on agreements, which are in turn instantiated via attributes specified in the SAML SSO profile.  “Federated connection” attribute lists often vary from connection to connection, depending on business requirements.  However, the web SSO profile serves as a framework upon which individual solutions can be constructed.

·         Moving the status forward will encourage vendor and user adoption of the profile.  There is a ubiquitous need across the private and public sectors for fine-grained access controls for intellectual property in electronic form.  This profile provides an extensible framework that can help guide deployments.  An upgraded status doesn’t imply that the profile contains “best practices” for building an IP authorization system.  In fact, we have a strong disclaimer that implementers should consult with their own legal experts to ensure that it meets their business and legal requirements.  The purpose of this profile is to identify and codify a standard set of attributes.  The examples contained in WD-06 are approximations of real-world use cases.

·         This profile, like the core and all other standards, can be modified as necessary in the future to meet evolving requirements.   Additional information discovered from deployments can be considered and incorporated to strengthen this profile as such situations occur.  We would welcome additional input. 

·         As we discussed in the F2F, I would like to use the IPC profile and use case for the XACML RSA interop.  IP protection is a very popular topic in a lot of venues right now, and showing that XACML can handle this important use case in that setting would be beneficial in generating additional support for XACML.


We can discuss this further on the call tomorrow.






From: xacml@lists.oasis-open.org [mailto:xacml@lists.oasis-open.org] On Behalf Of Doron Grinstein
Sent: Wednesday, November 30, 2011 10:47 AM
To: Tyson, Paul H; xacml@lists.oasis-open.org
Subject: RE: [xacml] Groups - IPC WD-06 uploaded


I appreciate John Tolbert’s effort on the IPC profile but I also agree with Paul Tyson that perhaps we should put this profile on hold. We are working with a set of customers that have IPC requirements and the result of that effort will yield our ability to more effectively provide feedback on the proposal profile. I am not suggesting starting from scratch. John has done a lot of good work. I am suggesting we wait until there’s more collective knowledge and experience and then take John’s work as the starting point and hopefully ratify the proposal quickly, perhaps in the second quarter of CY2012. My 2 cents…


Doron Grinstein  ¦ CEO  ¦ BiTKOO  ¦ 818-985-4700 Ext. 31 ¦www.bitkoo.com


Description: Description: Description: Description: LinkedIn Description: Description: Description: Description: Facebook Description: Description: Description: Description: Twitter

Schedule a meeting with me




From: xacml@lists.oasis-open.org [mailto:xacml@lists.oasis-open.org] On Behalf Of Tyson, Paul H
Sent: Wednesday, November 30, 2011 10:39 AM
To: xacml@lists.oasis-open.org
Subject: RE: [xacml] Groups - IPC WD-06 uploaded


My overall satisfaction with this spec has not risen over the last several working drafts, even though some technical details have been improved and clarified.


I remain deeply suspicious about the utility of the attributes and attribute values defined herein, except for ip-owner, ip-agreement, and organizational-affiliation.  I don’t think there is a broad enough base of experience with real-world, complete XACML systems using non-trivial IPC policy sets.  I do not think this spec will enable and encourage such implementations.  It is far from clear what the best practices are in this area, but by publishing this spec we would be claiming to have discovered and standardized some features of “best practices”.  I’m not ready to do that.


Would the Boeing reps consider putting this profile on hold for several months while they develop a production-track XACML system that exercises all the essential features?  (Bell has already implemented IPC policies using attributes that correspond to ip-owner, ip-agreement, and organizational-affiliation, which is why I am less suspicious of those.)


If the TC wants to promote the profile substantially as it is, I would like my name to be removed from the editors list.  There are also several technical glitches in the examples, such as misspelled attribute ids, and attribute ids that were turned into attribute values by the latest WD.  Section 3 should list all the identifiers defined by the profile, including attribute ids, URI-valued attribute values, and obligation ids.





From: xacml@lists.oasis-open.org [mailto:xacml@lists.oasis-open.org] On Behalf Of John Tolbert
Sent: Tuesday, 29 November, 2011 20:18
To: xacml@lists.oasis-open.org
Subject: [xacml] Groups - IPC WD-06 uploaded


Submitter's message
Revised WD-06, with anyURI data type for agreement-type and affiliation-type attributes. Examples updated.
-- Mr. John Tolbert

Document Name: IPC WD-06

Working draft 6
Download Latest Revision
Public Download Link

Submitter: Mr. John Tolbert
Group: OASIS eXtensible Access Control Markup Language (XACML) TC
Folder: Specifications and Working Drafts
Date submitted: 2011-11-29 18:17:39
Revision: 1


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