[OpenID] [from Marketing] I object to OpenID whitelists

[Martin Paljak]

On 05.07.2007, at 4:42, Peter Williams wrote:

> Issue 1: Which providers shall a trust point "accept"? Some think that
> the consumer agent associated with a trust point shall accept any and
> all providers. Others think that the agent supporting the trust point
> shall enforce a security policy limiting via such as black/white lists
> the providers with whom it is authorized to establish
> openid-associations.

You can't enforce the way applications are built or organizations  
work. You can't dictate the way OpenID is used. RP decides what is  
good, why is good and how is good enough for it to operate and  
there's nothing others can do.

White-blacklists are an implementation detail of the RP. If some of  
the white-blacklists happens to be  public ones (like botbouncer.com)  
then it is again just an implementation detail of the RP.


>
> Issue 2: When a trust-point-authorized provider provides a claim  
> that a
> given user "controls" a given OP, should a provider assert a "strength
> of claim"? Some think that there is no explicit signal  
> communicating the
> strength of this claim (e.g. a provider confirmed user control via
> 2-factor technique, rather than biometric technique, and as opposed to
> weak password technique) as the strength-signal is implied by the

Do you mean this:

http://openid.net/specs/openid-provider-authentication-policy- 
extension-1_0-01.html

?

> assurance level of the provider as beheld by the trust point. Others
> think that assurance of provider is independent of strength of claim,
> and thus strength requires a field for communicating the id of the
> technique the provider used to confirm "user's control over an OP".

I would not care less about 'foobarhacker.com' returning 'yes,  
smartcard authentication was used'  but would not care about  
authentication strength if it is somehow set with out of band  
guarantees-contracts like open.id.ee does.

In the end it is always the application policy that matters. There is  
no universal solution yet to come. Even though some providers might  
be super secure and super-trusted by users, RP-s can have a different  
understanding and thus the conversation ends - they don't accept them.

The meaning of trust has to be re-defined and re-implemented in this  
case. The most interesting case here is that RP-s have to learn to  
trust their users - if me as a user, I'm OK with a OP being my  
provider, I usually trust it and trust is well focused on one entity  
only - my OP.  Most applications are not built this way. Currently  
you have to split yoru trust between all different sites you use. If  
the application decides 'we trust our users and thus trust their  
decision when selecting a OP to use' then everything is OK. But if  
the decision is 'no, we don't trust our users' then there's nothing  
to do.



> Issue3: On experimenting practically with the JanRain server/consumer
> .NET portals with colleagues at http://www.scardsoft.com, we aimed to
> distinguish several concepts. We designed and then built an  
> experimental
> apparatus that would distinguish (1) "user authentication  
> strength" (aka
> OP control strength, in OpenID terminology) (2) a provider's assurance
> level, and (3) receiver confidence (aka degree of reliance, in OpenID
> terminology).

When mixing smart cards and OpenID one should of course look at other  
Open?? things like OpenSC - www.opensc-project.org :)

(disclosure: I'm part of that project)

> The
> consumer then evaluates confidence level in the webSSO act by
> calculating a metric over {assurance level of the provider(from id of
> provider), strength of the user authentication (from ATR), the  
> perceived
> quality of the OP (from the domain-name registrars or XRI proxies used
> in the OP).

Is there some universal algorithm to get the yes/no out of this  
evaluation ?


-- 
Martin Paljak
http://martin.paljak.pri.ee