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
