[OpenID] [LIKELY_SPAM]Re: Problems with delegation and directed identity OPs

[Deron Meranda]

On Thu, Nov 6, 2008 at 2:27 PM, Peter Williams <pwilliams at rapattoni.com> wrote:
> This is beginning to sound like EAP/802.1x and cisco, where every vendor now does their own profile (which works with nobody else's supplicants/authenticators).

I'm not sure it's quite that fragmented yet.  The OpenID community is still
quite young, at least in terms of having big visible players jump in the
mix.  I think we're just seeing cases of minor ambiguity, either in terms of
the standard or in user's expectations.  I expect the OpenID community
is unified enough to try to work these out.

Yes, there are lots of implementation differences (which I'll show
below), but I don't know if these are necessarily interoperability
stoppers; or just different levels of service in a healthy market.

Is is worthy of review though, and see if we either need to update
the specs, or perhaps make a "best practices" document.


A big problem I see with Google's approach right now (which I'll give
them a big break; they've only been an OP for a week or two)... is
that the end user doesn't know his own identity URI.

If an RP tried to tell me my identity was

https://www.google.com/accounts/o8/id?id=ltZAV_4NwusDiXYx7qAhZWqxOwxr1IbofBRL-1a

I couldn't tell if that was really mine or not!
That seems to be a major disconnect to me.


The other, perhaps less important, problem is that different OPs
provide different services; which are mostly outside the OpenID
spec's scope, or intentionally left up to the implementations.
Just to list a few OP differences and only concentrating on the
OpenID-specific features (not value-add):

   -- These are my observations, please correct if what I say
   -- is wrong....


Yahoo!
   Fixed "randomized" Identity (may use URL hash #)
   User can view their identities
   Additional user-definable identities
   Directed identity support
   Which identity to use is selectable, unless delegation is being used
       and the claimed_id has already been chosen during discovery.
   Doesn't show full realm to user during authentication (If realm
        is wildcarded as http://*.example.com/, Yahoo will still
        only show the specific http://somehost.example.com/ -- the
        user is not aware that the login may have a broader scope)

Google!
   Per-RP "randomized" identity (great for anonymity, poor for a
public identity)
   No fixed identity; users can not create or manage identities (no delegation)
   Supports AX extension "email" attribute (fetch only), with some
Google-specific
       behavior: ignores if_available list, so user has no choice
whether to send
       attribute or not)
   Directed identity support (although not yet using simple top-level
domain URL)
   Identities are invisible to the users they identify
   Logins can be remembered, and removed

Verisign
   Fixed human-readable identity
   User can add/manage additional identities
   Supports PAPE extention
   SReg extension support.  User can choose which attributes to send
       and with what values.
   Logins (trusted sites) can be remembered; with arbitrary expiration time,
        and can be edited at any time
   User can view logs of past identity activity, including complete
        list of all attributes exchanged

Trustbearer
   Fixed human-readable identity
   Users can not add additional identities (to the same "account")
   Supports SReg "email" attribute; user can not choose whether
       the send it or not
   Supports PAPE extension
   Won't remember logins (for increased security)


Not even getting into all the ancillary distinguishing features
(SAML, OAuth, hardware tokens, anti-phishing, etc.) there are a lot
of differences between just these four OPs .... even though they
are all OpenID 2.0 compliant.

I'm not sure if the differences are good or bad.  I suspect a case
can be made for both.


Clearly, just in terms of delegation support, Google is the only
problematic one among these four.  But it may also be the
best if you want anonymity.
-- 
Deron Meranda