Re: [xacml] Duplicate Organization Attribute in EC-US and IPC Profiles

Hi Rich,

Ambiguity wasn't the issue. There are already two distinct organization
attributes that we can tell apart. The discussion is about whether they
mean the same thing (in which case only one identifier is necessary).
In both cases the organization attribute indicates an association between
the subject and an organization. The IPC profile describes two particular
kinds of association, employee or contractor, but allows that there
may be more. The EC-US profile says employee or agent without suggesting
that there may be other kinds. Without being familiar with the problem
spaces, it seems to me that the attributes are the same, and will typically
have the same values, but not always. For example, "customer" might be a
valid association for IPC, but irrelevant for EC-US. The difference needs
to be reflected somehow and different attribute identifiers is one way to
do it.

If one believes that IPC and EC-US are always evaluated independently
(different PEPs sending different requests to different PDPs using
different policies), then there is no need for two different identifiers
for organization; the two will never meet. Jean-Paul thinks there is a
case for using IPC and EC-US together and I am inclined to agree with him,
but that means a distinction needs to be made.

I note the affiliation-type attribute in the IPC draft is problematic
when the organization and affiliation-type attributes are both multi-valued
because there is no way to align particular values of affiliation-type
with particular values of organization. An application could solve that
problem by using multiple requests. That is, one request for each value
of organization with the appropriate value for affiliation-type in each
case. If EC-US also uses affiliation-type (i.e., the same attribute!),
then IPC and EC-US could easily co-exist in such a scenario with a single
organization attribute. EC-US policies would only be applicable for
requests where the affiliation-type is relevant to EC (so paying attention
to "employee" and "contractor", but ignoring "customer").

An alternative to one request for each organization value is to define
a separate attribute for each type of affiliation and use a single request.
So instead of having organization and affiliation-type attributes, have
employee-of-organization, contractor-of-organization, customer-of-organization
and so on. IPC and EC-US would share these attributes. A subject could be
an employee of one organization, contracted to another organization, and
a customer of several other organizations and it would be clear what the
affiliation to each organization is. EC-US policies would most likely
only pay attention to the employee-of-organization and
contractor-of-organization attributes.

Regards,
Steven

On 13/09/2012 6:28 AM, rich levinson wrote: