I think Issuer is absolutely required in some environments, where the
information may be available from distinct authorities with different associated
levels of trust. In some cases the Issuer may also be used to disambiguate the
meaning of the attribute value. To pick up on David's example, the dollar is
different in Canada, the US, Australia, New Zealand, Hong Kong, Brunei, etc.

I think the issue of whether credential should be the primary construct, rather
than attribute is more arguable. It is clear that metadata used for vetting
(e.g. expiration date) needs to be associated with the attributes taken from the
same credential and not treated as a freestanding attribute which can be
combined with any other attribute.

The argument that an attribute in one credential is different from the attribute
in a different credential WITH THE SAME ISSUER, seems much weaker to me. It is
easy to think of cases like getting an attribute from a Repository where there
is no credential involved. In the vast majority of cases, I think that if an
organization had conflicting information about an individual (e.g. two different
birthdates) they would consider it merely a clerical error to be corrected as
soon as noticed. If I am called Harold Lockhart on my military identity card and
Hal Lockhart on my military driver's license is that likely to have any
significance?

Still I concede that there may be cases where this is needed. If the Policy is
going to operate directly on the credential value, it must be associated with
the attribute in some way.

This subject raises one of the subtle points about XACML. There is an
unspecified division of labor between the context handler and the policy
evaluation logic. In all implementations, the context handler does a certain
amount of work to vet and format the attributes it submits to the PDP. In many
cases there can be considerable latitude as to what is put in to code (context
handler) and what appears in policy. For example, during the discussion on the
3.0 admin model, I got the impression that Frank Seibelist wanted to put the
entire PKI validation logic in XACML policy. At the other end of the scale, some
languages (Secpal) assume that the data will be put in canonical format and thus
omit the many data formatting functions we have in XACML.

I think that the middle road taken by XACML of leaving the choice to the
implementers and deployers provides necessary flexibility, although it does
sacrifice some potential interoperability amongst different deployments. When
deciding how much vetting or formatting should be done by the context handler
vs. the policy there are two main considerations: how dynamic is the processing
and how familiar to users will the resulting attribute values be.

As an example of the first, I would expect that the process of verifying a
certificate chain would be relatively constant within an organization or at
least within an application, so I would suggest this not be represented in
policy.

As an example of the second, suppose the organization rates all their customers
as gold, silver, bronze based on a complex calculation of frequency, size and
recentness of transactions. This is reasonable to represent as an attribute
since it is familiar to all users in that organization. On the other hand, some
kind of risk score, known only to the Security Department would be better to
express as a policy based on the attributes it is calculated from.

Hal

https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

***************************************************************** David W. Chadwick, BSc PhD Professor of Information Systems Security School of Computing, University of Kent, Canterbury, CT2 7NF Skype Name: davidwchadwick Tel: +44 1227 82 3221 Fax +44 1227 762 811 Mobile: +44 77 96 44 7184 Email: D.W....@kent.ac.uk Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html Research Web site: http://www.cs.kent.ac.uk/research/groups/iss/index.html Entrust key validation string: MLJ9-DU5T-HV8J PGP Key ID is 0xBC238DE5