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-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


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