[Wg-p3] Preparation for USG Privacy Workshop (Aug 10th)

Nicole Harris n.harris at jisc.ac.uk
Mon Aug 10 03:00:53 PDT 2009

Hi Robin

Coming at this a little late do to some severe broken e-mail problems in 
JISC land!  I couldn't agree me on the clear functional requirements for 
LOA1, and above.  Most of the people we talk to on a daily basis have a 
very hard time defining the assurance they need in any particular 
credential.  The answer I mostly get at the moment is 'because it is 
licensed material' (fair enough) but when pushed on the level of 
security required, service providers tend to just go along with practise 
that has been in place since the service was started.  I think it would 
be really interesting to dig deeper in to some of these presumptions as 
part of identity assurance work. 

The other common argument I get is 'we need LOA2'.  Again, when 
challenged most SPs reply 'because our stuff is really valuable'.  An 
interesting case in point recently has been us trying to persuade a 
large digital media organisation that increasing assurance level will 
not prevent users from inappropriately sharing downloads and that they 
really need to carry out a full risk assessment of service delivery vs. 
user experience vs. risk of 'leakage' before addressing this question. 

There is definitely a lot more work to be done in this space before 
assurance profiles can be effectively used in the UK academic environment!


JISC Executive
JISC London office
1st Floor, Brettenham House South
5 Lancaster Place
London WC2N 7EN

tel: +44 (0)20 3006 6035
mobile: +44 (0)7841951306
fax: +44 (0)20 7240 5377

Robin Wilton wrote:
> Folks - great traffic on the list, and good to see WG members 
> contributing quality input...
> (Just to debase the currency) here's my 2p-worth:
> 1 - having read the ID Scheme Adoption Process paper [1], I note that 
> it describes a wish to "transition from a Federation model to an open 
> model that promotes multiple agency solutions". On the face of it, I'd 
> question whether that reflects an accurate concept of Federation, or a 
> clear enough use of the word "open" (open architecture, open access, 
> open standards, open source...???).
> I have every reason to believe that a federated authentication 
> solution can be both "open" in the relevant senses and multi-agency, 
> so my initial reaction is that that quotation sets up a false 
> opposition ("You can have federated /or /open")... and when I see a 
> false opposition, I wonder what agenda it reflects.
> 2 - there are two things which the ICAM team might consider to be out 
> of scope - I don't know - but which introduce risk if they are omitted 
> from the discussion.
> - First, what's the mapping between OMB LoA levels and the many and 
> varied government services to which access is to be granted? (I.e. 
> where's the table which says "if the user is seeking to access service 
> x, then a credential of LoA <2 is not acceptable"?)
> U Wisc-Madison has this kind of table here. [2]
> The risk of not mapping LoAs to services is that this isn't a strict 
> one-to-one mapping between technologies and LoAs. What you have to 
> find in each case is the acceptable combination of three elements, not 
> two:
> Technology 	LoA 	Service
> not just technology-to-LoA. As the TFP Adoption Process paper puts it,
>     "In some cases, the parameters of a common criterion (e.g.,
>     required password entropy) may be different between LOAs."
> (Put another way... you could implement a PKI-based system in such a 
> way that it should fail to qualify even for LoA1....)
> - Second, what are the services for which LoA 1 is acceptable, and 
> what reliance, if any, is placed on the credential/persistent 
> identifier? What functional requirements does the credential fulfil? 
> (E.g. is it a means of preventing spam, is it used to identify repeat 
> visits by the 'same' user, and so on?)
> The risk of failing to establish clear functional requirements at LoA 
> 1 is that credentials are introduced on the basis of use for a 
> non-contentious purpose, and function creep results in their 
> inappropriate use for other services. (Anyone who says that can't 
> happen should consider what has happened to SSNs...).
> Hope this helps -
> Yrs.,
> Robin
> [1] 
> http://www.idmanagement.gov/documents/IdentitySchemeAdoptionProcess.pdf
> [2] http://www.cio.wisc.edu/security/initiatives/levels.aspx
> Robin Wilton
> Director, Future Identity
> Director of Privacy and Public Policy, Liberty Alliance
> www.futureidentity.eu
> +44 (0)705 005 2931
> ====================================================================
> Structured consulting on digital identity, privacy and public policy
> ====================================================================
> Future Identity is a limited company number 6777002, registered in England & Wales
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://kantarainitiative.org/pipermail/wg-p3_kantarainitiative.org/attachments/20090810/6e6aa7e4/attachment.html>

More information about the Wg-p3 mailing list