Sorry for the confusion. The conversation thread out discussing why
the GSA didn't certify openID for LoA 2.
Certainly in other trust frameworks there can be other rules.
My point was that we need some other trust framework if you want to
achieve other goals.
Also things in the GSA profiles about signing messages with
certificates that chin to the US Federal trust bridge probably make no
sense outside of the GSA use case.
I agree that we need trust profiles. I am just cautious about people
thinking that the GSA ones are appropriate outside of there context.
People inside and outside government place almost magic significance
in the LoA numbers.
They specify some things and not others it is dangerous to read too
much into them.
John B.
On 19-Aug-09, at 12:44 PM, Nat Sakimura wrote:
John,
I am not only talking about US LoAs.
NIST SP800-63 LoAs are good for their purpose, but we need to retool
or create something new for other purposes.
The previous mail was referring to the necessity of some kind of
trust on the attributes for a wider adoption of OpenID and it has
nothing to do with SP800-63 LoAs.
For "the ability to contact customers when needed", something like
verified email or even better, permission to resolve/discover the
then current email address would be good. Of course, then it is up
to the RP to believe it or not. If there is some kind of assurance
program going on for this service, then it would help ease "RP's
trust" problem.
=nat
On Fri, Aug 14, 2009 at 10:27 AM, John Bradley <[email protected]
> wrote:
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
--
Nat Sakimura (=nat)
http://www.sakimura.org/en/
_______________________________________________
specs mailing list
[email protected]
http://lists.openid.net/mailman/listinfo/openid-specs
