[OpenID] OWL project for OpenID WhiteListing

[Meng Weng Wong]

On Jul 5, 2007, at 11:18 AM, Evan Prodromou wrote:

> On Thu, 2007-05-07 at 14:12 +0300, Martin Paljak wrote:
>
>> 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.
>

I agree.  The above argument is successfully used in the email world  
of antispam DNSBLs.


> I've found that one of the great entry points for OpenID is two-way or
> multi-way closed trust systems. The big use case for many  
> administrators
> seems to be letting users from another "partner" site log into  
> their own
> site, and vice versa. Only after this relationship is established do
> some admins enable more open trust relationships.
>

I am working on web-of-trust whitelisting, and will keep this in mind  
as a common starting point.


So far I have the following proposal.  Please accept my apologies for  
any terminology inconsistencies with existing work.  I am still  
getting up to speed and have not read all the specs yet.


OpenID WhiteListing (OWL) Project

(The world is not black and white, so I may add more nuance to the  
concept of a whitelist; perhaps it should be more value-neutrally  
called a "claimlist".)

This project, as a v0.1 straw man prototype, produces three whitelists.

Please consider these whitelists to be Platonic forms which may see  
one or more embodiments, provided by different operators, and used by  
different people in different ways.


OWL-OP
A whitelist of OpenID Providers.

A Relying Party may choose to distinguish EUs associated with a  
listed OP.



OWL-RLY
A whitelist of OpenId Relying Parties.

At present, the login process involves two speedbumps.

Speedbump 1: "Oops, you're not logged in to your OP.  Please login now."

Speedbump 2: "Now that you're logged in to the OP, do you want to  
trust this RP?"

Speedbump 1 is addressed by extending OP session longevity as much as  
possible.

Speedbump 2 may be addressed by OWL-RLY.

If an RP is on the list, an OpenID Provider may choose to bypass it  
and just proceed with a "yes" assumption.

I hereby name the bypass operation "YARLY".

An OpenID Provider can offer its End-Users a menu of which whitelists  
to trust, with defaults preset in the spirit of libertarian  
paternalism.  Tinfoilhat types can uncheck all.  Our grandmothers can  
check all.  Tinfoilhat grandmothers are considered an edge case.

For people with no sense of humour, OWL-RLY is aliased identically to  
OWL-RP.



OWL-EU
A whitelist of OpenID End-Users.

RPs can use this whitelist where increased granularity is needed.   
The analogous case is when both legitimate and phishing websites are  
hosted on Geocities.

The corresponding OBL-EU may be used as a signaling mechanism to  
inform OPs that their EUs have been naughty.



Implications for User Experience and Phishing

If the ORLY / YARLY paradigm gains adoption, and if end-users stay  
logged in to their OPs >98% of the time, then the typical use case  
will bypass both the login speedbump and the "allow?" speedbump.  We  
may then observe a reduction in phishing scenarios, as end-users will  
be alerted by the very unexpectedness of the login speedbump.

I make the assumption that to combat phishing it is important to  
marginalize the appearance of any speedbump at all.  If users become  
accustomed to clicking through Speedbump 2, I assert that they will  
be less alert when presented with a phish of Speedbump 1.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20070705/d0e41dab/attachment-0002.htm>