Refeds


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

Hi Robin

I was only talking about identification first, because Steve asserted that this was all that was needed, and I wanted to point out that after you had done that, what you really wanted was authz. Identification is only needed if you want to track the user between transactions, otherwise authz on its own is sufficient. And identification can be done by simply adding another "uniquely identifying" attribute to the authz set. So in this sense, the use cases are the same.

regards

David

On 06/07/2011 12:17, Robin Wilton wrote:
They're not the same use case in the terms you used. The distinction I
was trying to draw was between
"I don't care who you are, provided I can establish that you have a
particular attribute",
and what you originally said, which was
"/once you have identified the user/, you then need to authorise the
user to do something."
R
On Wed, 06 Jul 2011 12:08 +0100, "David Chadwick"
<d.w.chadwick@xxxxxxxxxx> wrote:
 > 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
 >
 > *****************************************************************
 >
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

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