Subject Re: draft charge, refeds working group on attribute release
From Steve Moitozo II <steve_moitozo@xxxxxxx>
Date Wed, 06 Jul 2011 01:21:21 -0400

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

Attachment: signature.asc
Description: OpenPGP digital signature