[OpenID] OpenID + Government

[Peter Williams]

Confusing some more, I'm playing with the qop= option on www-
authenticate signals optionally exchanged by indirectly connected
parties using digest auth scheme. Just as qop=auth-int allows data
origen authentication between web (not openid) layer endpoints to
cover the data object being communicated, other qop values can signal
encryption of the payload - where www-auth acts as a bearer for such
signals.

main point is that it would not require wg to get a common signalling
layer for endend encryption services.




On Aug 19, 2009, at 10:09 AM, "John Bradley" <john.bradley at wingaa.com>
wrote:

> 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 <john.bradley at wingaa.com
>>> 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/
>