Refeds


Subject Re: draft charge, refeds working group on attribute release
From David Chadwick <d.w.chadwick@xxxxxxxxxx>
Date Mon, 04 Jul 2011 21:47:26 +0100



On 04/07/2011 21:08, Nicole Harris wrote:


Getting back to Steven's charge, I still think there is a huge amount
of work we can do in the here and now just to allow members to
effectively release more attributes in a secure and trusted manner
without introduced 'increased' LOA, whatever that means.

Dont you see that they are different sides of the same issue? LOA is simply the metric that is used to quantify the security and trust that you want to achieve. You state that you want to release attributes in a trusted manner. I ask how trusted is that? You need to tell me, and LOA is one of the crude short hand metrics that is used to tell me.

Of course using LOA is like using a taste score out of 4 to rate a bowl of fruit salad. I give the taste a score of 2 out of 4. YOu know that this is better than 1 and worse than 3. But it does not rate the apples, pears, oranges etc in the fruit salad (which in the attribute case are the registration procedures, protection features etc.) Much more detailed metrics are needed for this. But using LOA gives us (and SPs) a crude handle to pass around in protocol along with the said attributes to give some assurance about their validity - assuming they are coming from a variety of different authorities. Another way, if you want to dispense with LOA, is for each SP to keep a list of the different attribute authorities it trusts to issue each type of attribute to whom, and if they are not in this list the authority and its attributes wont be accepted by the SP. This is the approach we are using today.

regards

David




On 4 Jul 2011, at 20:09, Peter Schober wrote:

* David Chadwick<d.w.chadwick@xxxxxxxxxx>  [2011-07-04 18:20]:
I am arguing that universities ought to be able to do better
than zero assurance, in order to add more value to their
assertions, and I believe that the majority of the UK IdPs
already do. Therefore the bar ought to be raised to this level
for all IdPs. This level is level 2, and it is not as onerous as
I think you think it is.

I agree with Nicole (most institutions are not at LoA2 currently
-- read on for why -- that's a simple fact, so we cannot *require*
LoA2 for general federation membership. Only optional assurance
profiles -- to use the SWAMID 2.0 federation policy terminology --
should mandata specific levels). I also agree with David in
thinking that probably all institutions in probably all federations
do in fact have processes in place which put them *way* above
self-asserted identity social IDPs currently deal in. *But* --
they're not proven/audited against an agreed upon set of criteria,
such as the Kantara framework.

I really do believe we're (current IdPs of current federations)
all offering a much higher LoA than what's available from social
id providers -- which exactly why we are in fact providing value
already, as Nicole points out. We're just not able to prove it to
others outside our cultural background (vertical sector, if your
prefer).

Because: a. It's expensive. The status quo seems to be good enough
for many things, so there's little incentive to invest for other
cases. b. There's not enough experience, documentation,
recommendations, agreement on how to do this. NIST SP 800-63 for
the whole world? Many don't agree with that (e.g. our national
government, who rolled their own, inspired by 800-63, but
incompatible).

-peter



--

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

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