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

Robin Wilton futureidentity at fastmail.fm
Tue Aug 4 08:14:30 PDT 2009


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]
[1]http://www.idmanagement.gov/documents/IdentitySchemeAdoptionPr
ocess.pdf
[2] [2]http://www.cio.wisc.edu/security/initiatives/levels.aspx

References

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/20090804/8ff33bd1/attachment.html>


More information about the Wg-p3 mailing list