Refeds


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

Hi Robin

ultimately they are the same use case - authz.

"I dont care who you are, I care what you can do"

This should be the driving force of federations

regards

David


On 06/07/2011 11:40, Robin Wilton wrote:
That's one use case; the other vital one is the case where you want a
trusted attribute assertion but don't particularly care about the user's
identity. To my mind, that's the vital next step in online authn/authz
management. Shibboleth led the way in this, with the ability to assert
"is a member of this institution" - frustrating as this thread can be
from time to time, I think it's a really important debate with
implications far beyond the REFEDS community...!

R

On Wed, 06 Jul 2011 11:33 +0100, "David Chadwick"
<d.w.chadwick@xxxxxxxxxx>  wrote:
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.

regards

David

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

David,

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

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

*****************************************************************

Robin Wilton

+44 (0)705 005 2931



--

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

*****************************************************************