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

j stollman stollman.j at gmail.com
Tue Aug 4 12:23:34 PDT 2009


Robin,

I have interjected some comments into your note.  I have had lengthy
experience working with the government and may offer some useful
perspective.

On Tue, Aug 4, 2009 at 11:14 AM, Robin Wilton <futureidentity at fastmail.fm>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.
>

I believe that the government's distinction between federation and open
comes from their openness to having solutions at low assurance levels that
do not interact with other solutions.  They may choose to accept OpenID for
only Assurance Level 1 transactions.  Higher trust levels in which there are
multiple Identity Providers (IDPs) tends to demand federation of the IDPs in
order to the clients of one IDP to be trusted by those of another IDP.

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

I suspect that as they move forward, they will undertake this mapping.  But
given the breadth of the government, they don't want to hold off on
developing the tools to implement their plans while waiting for every
possible transaction to be mapped.  They will likely have to implement a
governance process to determine the assurance levels required for the
thousands of different transactions in which various agencies engage.

>
>
> "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...).
>

Your thoughts here are right on target.  I suspect that they will have to
define some initial use cases for particularly well understood and
documented transactions in order to establish initial guidance.  Then, they
will need to envision the governance process I refer to above.  As they
begin to be design this process, I think that you are likely to be a
valuable contributor.

>
>
> 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
>
>
> _______________________________________________
> Wg-p3 mailing list
> Wg-p3 at kantarainitiative.org
> http://kantarainitiative.org/mailman/listinfo/wg-p3_kantarainitiative.org
>
>


-- 
Jeff Stollman
stollman.j at gmail.com
1 202.683.8699
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://kantarainitiative.org/pipermail/wg-p3_kantarainitiative.org/attachments/20090804/7302862e/attachment-0001.html>


More information about the Wg-p3 mailing list