Subject Re: draft charge, refeds working group on attribute release
From David Chadwick <d.w.chadwick@xxxxxxxxxx>
Date Wed, 06 Jul 2011 11:33:57 +0100

Hi Steve

I would argue that if you delve a bit deeper into why attributes are really needed (use the Ishikawa fishbone mechanism of always asking why), I think you will find that, once you have identified the user, you then need to authorise the user to do something. So ultimately all the attributes are needed for authz.

I do indeed argue that ultimately each attribute needs its own LOA. Hard as that may be to swallow now.



On 06/07/2011 06:21, Steve Moitozo II wrote:
This has been a very interesting and educational thread.


Many of your comments about attribute release reveal the desire on the
part of the SP to use the attributes for local authorization, not merely
identification. I'd be interested to know some examples of such attributes.

This seems to intensify the complexity of the issue of LoA in attribute
release because it could be that the attributes you're looking for are
beyond the core identity of a particular user (e.g., affiliations, group
memberships, affinities, etc.) It seems like these are the very things
that are likely to be delegated outside (or at least to the ragged
edges) of an organization's IDM infrastructure. It may also follow that
as management gets delegated the LoA could decrease due to looser and
looser controls. Before you know it each attribute will require it's own
LoA and some kind of organizational process for determining how it's

All of this seems like a crude hack, when what is desired is true
federated authorization (i.e., Is Bill entitled to access this data in
this context?), not simply federated attribute sharing that gets used
for local authorization (i.e., Does Bill have X value in Y attribute?).
Of course, there aren't many applications that support this kind of
thing yet.

On 07/05/2011 02:01 PM, David Chadwick wrote:
Attribute release is not a one dimensional problem. It is multi-faceted,
which requires all of the following components at least to be in place

- user consent
- trust by the SP that the released attributes are genuine
- trust by the IDP that the SP will only use the attributes for the
stated purpose

So everything we have been discussing is related to attribute release


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.Chadwick@xxxxxxxxxx
Home Page:
Research Web site:
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5