Peter,
Perhaps it is better to say that peoples perception of SP800-63 is
broken.
Profiles for the GSA based on SP800-63 and OMB 04-04 are not silver
bullets.
They do nothing for email verification in themselves.
If people want profiles that deal with those issues they need to
create them.
This issue is not unique to openID. INCommon has been certified with
NIH for a while now.
They still have a hard time getting people to understand that LoA 2
doesn't specify attribute proofing, only identity proofing. People
are still debating what attributes constitute an identity.
To be useful in the commercial world there needs to be profiles and
certification practices that address real issues.
The GSA profile is this community putting one toe into that water.
There is nothing to stop there being a openID profile for verified
attributes based on the LoA 1 profile.
Someone needs to do the profile and set up a certification program for
OP's and RP's.
There are big questions around who should do it and who should pay.
Trust issues are hard and have been out of scope for openID to this
point. That may well be part of it's success.
Is GSA LoA 2 certification for openID a good thing? Yes.
Will it solve any of our pressing problems on its own? Probably not.
John B.
On 14-Aug-09, at 8:44 AM, Peter Williams wrote:
Its not necessarily broken. These things are designed to be
composed. If any one agency goes for pre-eminence, it will restart
the inter-agency wars that made all the previous rounds of this same
underlying initiative largely ineffective.
1. from the smartcard hardware/firmware assurances you get
http://www.commoncriteriaportal.org/files/epfiles/cible2005_05.pdf
2. from the crypomodule assurance you get the entries on the like of http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/1401val2009.htm
. For example the functional groups of http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp575.pdf
3 from the cipher validation (e.g. HMAC) you get
http://csrc.nist.gov/groups/STM/cavp/documents/mac/hmacval.html
4 from the cps, you get identity proofing
http://mattche.iiie.disa.mil/cpmwg/doclibrary/dod_ref_med_assurance_lra_cps_v311_11may07.doc
5. from the cert profile, you get algorithm and trustpoint
management: http://www.nsa.gov/ia/_files/industry/Suite_B_Certificate_and_CRL_Profile_20080528.pdf
6. from GSA you get websso specific assurance superstructure, that
is now protocol independent: see John
It just goes on and on. Billions and billions of dollars worth.
7 If you go to the NIST site http://csrc.nist.gov/, you can trawl
through 20+ years of developing guidelines and generic risk
management methods... that underlie all the processes.
My question is: does ANY of this fit openid mission or culture? If
so, which bits?
Part of what draws me to openid is that its a bit counter-culture -
and offers an antidote to the above.
________________________________
From: John Bradley [[email protected]]
Sent: Thursday, August 13, 2009 6:27 PM
To: Nat Sakimura
Cc: [email protected]; Peter Williams; OpenID Specs Mailing List;
[email protected]
Subject: Re: [OpenID] OpenID + Government
Nat,
The LoA 2 profile doesn't say anything about the validity or vetting
of the attributes.
It only applies to identity. It is strange and perhaps broken.
There are some GSA sponsored workshops in DC Sep 28-29 to discuss
some of those issues.
Many people assume that Identity proofing has something to do with
attributes.
Other profiles can deal with it some other way, but the GSA profile
places no requirement on the IdP to verify an email.
Your argument is about verified email may relate to some other
profile not GSA LoA 2.
Many people including government ones make the mistake of reading
more into the LoA than is defined in SP800-63.
John B.
On 13-Aug-09, at 3:17 PM, Nat Sakimura wrote:
I think we need to clarify what makes it easier for RP adoption.
For that, we need to categorize the RPs and find out their pain
points.
Assurance or "Trust" is often one of the pain point in addition to UI.
For example, what we have been hearing in Japan is that if the RP
solely relies on OpenID, they fear that they loose the way to get in
touch of the users when they need to, such as recalling their
product. So, they tend to put their own flow for address validation
etc., which clutters UI, which is a recipe for failure. Higher
assurance for the contact address in this case will streamline the
UI and improve the success rate, thereby assisting the RP adoption.
Also, I would like to point out that spec being a little more
complex does not mean that it is going to be hard for deployers to
deploy. Most of the complexity will be taken care of by the
libraries, and often, more functionality on the spec and library
side would make the life easier for the deployers.
=nat
On Fri, Aug 14, 2009 at 5:55 AM, David Recordon <[email protected]<mailto:[email protected]
>> wrote:
Hey Peter,
I don't think that we should ignore the potential very interesting
Government RPs if we made OpenID support LoA 2, but wouldn't there
be a tradeoff with RPs Government or non-Government that are LoA 1
or below?
We've heard for a year that OpenID is still hard to adopt as a RP,
hard to get the UX correct and that the business value isn't being
communicated as clearly as an individual company does with a system
like Facebook Connect. If we were to increase the complexity we
might get more Government RPs, but I worry that we might also be
making it harder for "web" RPs which far out number Government RPs
that require LoA2.
The Government approached us earlier this year asking the Foundation
to help them OpenID enable a set of RPs with an initial focus on LoA
1. Some are in the social web space and others are not. I think
that we should take advantage of this request to make it even easier
to adopt OpenID successfully as an RP – Government or non-Government
– within LoA 1 or below situations.
--David
_______________________________________________
specs mailing list
[email protected]
http://lists.openid.net/mailman/listinfo/openid-specs
