RE: [xacml] Groups - IPC WD-04 DOC (xacml-3 0-ipc-v1 0-spec-wd-04-en.docx) uploaded

["Tolbert, John W" <john.w.tolbert@boeing.com>]

Hello,

>2.1.2 ...resource:ip-data.  I still have reservations about this and would like to see a few policy examples showing the possible variation in the values and what they mean.

JT:  This attribute represents more specific categorization information about the resource.  We will be working on policy examples.  One of the example categories I provided previously was for author/creator names for IP-Type:Copyright.  For now, let’s assume that a stock photography site has licensed usage of photos from a particular photographer, and needs to write rules to allow the graphic artist customer to view and download copyrighted photos whose author/creator name value is Jane Smith.

>2.1.4 ...resource:ip-agreement-type.  I do not understand how the *type* of agreement would be used for an authorization decision.  An agreement (of any type) either allows a subject to see a resource, or it doesn't.  Perhaps an example will clear it up.

JT:  IP-agreement-type is important in the overall intellectual property authorization model.  It may not be populated and used in every access control decision, and therefore doesn’t need to be mandatory.  However, consider a scenario where you want to prevent disclosure of a certain type of IP in all cases except where the parties have a “technical data license”.  This would have the effect of preventing disclosure even if the parties have a “Proprietary Information Agreement” (PIA), which is generally used in the exploratory phase of a potential collaboration project. Having the ability to write a rule to exclude specific resources based on the agreement type can serve as a safeguard to prevent unintended data loss.  Moreover, this attribute provides useful reverse query (determining access potentials) and audit capabilities.

>2.1.7 ...resource:effective-date.  Still has muddled semantics.  It is not about the resource, it is about an agreement that covers the resource.  If this is a fixed value, the policy can include a match or condition against the built-in environment variable, current-date.  If it is really a variable value, perhaps it belongs in a custom category.

JT:  I understand the point about simply collecting time/date information from the PDP at evaluation time.  However, I think that implementers should have a standard metadata attribute to convey effective/expiration dates of license agreements on resources themselves.  In a federated authorization model, individual files could be tagged with effective/expiration dates, and having a corresponding attribute and values would allow policy authors to construct rules and policies accordingly.  These values also afford auditors the ability to create searches and reports on these key license terms.  Additionally, in cases of a copyright or patent, these attributes can be used to track the term and expiration dates of the legal status of the resource.   

>2.1.8 ...resource:expiration-date.  Same as for effective-date.

JT:  See above.

>2.2.1 ...subject:organization.  I concur with this attribute, but after a couple of years working with the corresponding export compliance attribute I would suggest a more descriptive name, such as 'organizational-affiliation', or just 'affiliation'.  'Organization' doesn't immediately suggest the intended meaning.  Furthermore IP decisions might depend on the type of affiliation (such as 'employee', 'contractor', which would require some way to make further distinctions about this relationship.

JT:  I concur with changing “Organization” to “Organizational-Affiliation”.  I also see some value in an “Affiliation-Type” attribute.  

>2.2.2 ...subject:ip-agreement.  I really did mean to put this in the subject category, not as a duplicate of the "...resource:ip-agreement" attribute.  The meaning is: "an identifier of an IP agreement that covers this subject".  If one can arrange one's context handler to provide all the pertinent resource:ip-agreement values and subject:ip-agreement values, then the rule just has to check for any-of-any equal between the two bags of values (assuming there are no other complicating conditions).

JT:  I think being able to link IP-agreements to resources and subjects is potentially useful.  On the surface it may seem duplicative to include a subject:ip-agreement if subject name and “organizational-affiliation” are both available.  However, to provide facilities for more fine-grained access control, consider cases where companies have multiple ip-agreements with one another.  Tying resource:ip-agreement to subject:ip-agreement would allow policy authors to limit access based on a match of those 2 attribute values.

>2.3.1 ...environment:location.  I still think this violates the sense of the built-in Environment category, which refers to the time and place where the request is being evaluated--not where the request is made from.  Why can't this be a subject attribute?

JT:  Upon further consideration, we will remove the location attribute.

>2.5 Obligations.  Need to distinguish between prescribed values of the ObligationId attribute, and possible AttributeId values that can be put in an IP ObligationExpression.  ObligationId values will not have a datatype or allowed values, so these sections should be reworded.

JT: 
<xacml:Obligations  
xmlns:xacml="urn:oasis:names:tc:xacml:3.0:policy:schema:os" >
	<xacml:Obligation 
 ObligationId="urn:oasis:names:tc:ipc:1.0:obligation:encrypt" FulfillOn="Permit">
	</xacml:Obligation>
</xacml:Obligations>


>2.5.1 The ObligationId perhaps should be '...obligation:encrypt', and a useful AttributeId included in the obligation might be '...obligation-attribute:encryption-type'.

JT: Agree.  It may be best to leave it to vendors to determine encryption parameters based on what is available in the calling applications.  Over-specifying could lead to some PEPs being unable to fulfill the encryption obligation.

>2.5.2 Marking.  If this is an ObligationId, it doesn't need a datatype or suggested values.  The wording should say this value is to be used as the value of ObligationExpression/@ObligationId.  If specialized AttributeId values need to be added (e.g. for specifying the wording, sense, or style of the marking) they should be defined under this section.

JT:  Agree.  But wording should be left unspecified.

<xacml:Obligations  
xmlns:xacml="urn:oasis:names:tc:xacml:3.0:policy:schema:os" >
	<xacml:Obligation 
 ObligationId="urn:oasis:names:tc:ipc:1.0:obligation:marking" FulfillOn="Permit">
	</xacml:Obligation>
</xacml:Obligations>


>2.5.3 Disposal.  Similar to Marking.

JT:  I agree.  It will be removed.

Thanks,
John 

-----Original Message-----
From: Tyson, Paul H [mailto:PTyson@bellhelicopter.textron.com] 
Sent: Sunday, September 25, 2011 1:56 PM
To: Tolbert, John W; xacml@lists.oasis-open.org
Subject: RE: [xacml] Groups - IPC WD-04 DOC (xacml-3 0-ipc-v1 0-spec-wd-04-en.docx) uploaded

Unfortunately I do not have time to compose a note on the general approach and architecture for IP protection, which I think this profile should discuss.  But I will make some quick comments on the attributes proposed.  Some of these reiterate my previous comments embedded in the profile document.

2.1.2 ...resource:ip-data.  I still have reservations about this and would like to see a few policy examples showing the possible variation in the values and what they mean.

2.1.4 ...resource:ip-agreement-type.  I do not understand how the *type* of agreement would be used for an authorization decision.  An agreement (of any type) either allows a subject to see a resource, or it doesn't.  Perhaps an example will clear it up.

2.1.7 ...resource:effective-date.  Still has muddled semantics.  It is not about the resource, it is about an agreement that covers the resource.  If this is a fixed value, the policy can include a match or condition against the built-in environment variable, current-date.  If it is really a variable value, perhaps it belongs in a custom category.

2.1.8 ...resource:expiration-date.  Same as for effective-date.

2.2.1 ...subject:organization.  I concur with this attribute, but after a couple of years working with the corresponding export compliance attribute I would suggest a more descriptive name, such as 'organizational-affiliation', or just 'affiliation'.  'Organization' doesn't immediately suggest the intended meaning.  Furthermore IP decisions might depend on the type of affiliation (such as 'employee', 'contractor', which would require some way to make further distinctions about this relationship.

2.2.2 ...subject:ip-agreement.  I really did mean to put this in the subject category, not as a duplicate of the "...resource:ip-agreement" attribute.  The meaning is: "an identifier of an IP agreement that covers this subject".  If one can arrange one's context handler to provide all the pertinent resource:ip-agreement values and subject:ip-agreement values, then the rule just has to check for any-of-any equal between the two bags of values (assuming there are no other complicating conditions).

2.3.1 ...environment:location.  I still think this violates the sense of the built-in Environment category, which refers to the time and place where the request is being evaluated--not where the request is made from.  Why can't this be a subject attribute?

2.5 Obligations.  Need to distinguish between prescribed values of the ObligationId attribute, and possible AttributeId values that can be put in an IP ObligationExpression.  ObligationId values will not have a datatype or allowed values, so these sections should be reworded.

2.5.1 The ObligationId perhaps should be '...obligation:encrypt', and a useful AttributeId included in the obligation might be '...obligation-attribute:encryption-type'.

2.5.2 Marking.  If this is an ObligationId, it doesn't need a datatype or suggested values.  The wording should say this value is to be used as the value of ObligationExpression/@ObligationId.  If specialized AttributeId values need to be added (e.g. for specifying the wording, sense, or style of the marking) they should be defined under this section.

2.5.3 Disposal.  Similar to Marking.

Regards,
--Paul


> -----Original Message-----
> From: john.w.tolbert@boeing.com [mailto:john.w.tolbert@boeing.com]
> Sent: Wednesday, September 07, 2011 18:06
> To: xacml@lists.oasis-open.org
> Subject: [xacml] Groups - IPC WD-04 DOC (xacml-3 0-ipc-v1 0-spec-wd-04-
> en.docx) uploaded
> 
> WD-04 incorporates Erik's idea of mapping IP-Type values to IP-Data
> values
> (see Section B: Non-normative).  We also accepted most of Paul's
> suggestions on attribute name changes, additions, and deletions.  We
> did
> have a couple of clarifying questions for Paul on the diagram and use
> cases, noted in the margin comments.
> 
>  -- Mr. John Tolbert
> 
> The document named IPC WD-04 DOC (xacml-3 0-ipc-v1 0-spec-wd-04-
> en.docx)
> has been submitted by Mr. John Tolbert to the OASIS eXtensible Access
> Control Markup Language (XACML) TC document repository.
> 
> Document Description:
> XACML Intellectual Property Control Profile, working draft 4
> 
> View Document Details:
> http://www.oasis-open.org/committees/document.php?document_id=43459
> 
> Download Document:
> http://www.oasis-open.org/committees/download.php/43459/xacml-3%200-
> ipc-v1%200-spec-wd-04-en.docx
> 
> 
> PLEASE NOTE:  If the above links do not work for you, your email
> application
> may be breaking the link into two pieces.  You may be able to copy and
> paste
> the entire link address into the address field of your web browser.
> 
> -OASIS Open Administration