[OpenID] query regarding OP migration

[Babu N]

Hi Shape,

Please see inline..


On Sat, May 31, 2008 at 9:45 PM, SitG Admin <sysadmin at shadowsinthegarden.com>
wrote:

>  >Babu> Could you please elaborate more on the harsh criticisms we face ?
> Do we have any link where we can see why "centralization" was not preferred
> ?
>  There was a link posted to this list recently:
> http://idcorner.org/2007/08/22/the-problems-with-openid/
> Only four days ago, in fact :)
>
> Read the "Privacy" section. Then, for good measure:
> http://www.techcrunch.com/2007/02/20
>         /kevin-rose-at-fowa-digg-adopts-openid/
> (I've split the URL onto two lines to prevent it being wrapped.)
>
> Honorable mention goes to "mathew" for comment #34.
>

> >Babu> There is not going to be any cache in RPs.
>
> But according to the specs (since v1.0, even!), there *is*.
>
> Actually, the term used is "MAY", but developers are warned against using
> this "stateless" mode because it may (that word again) be vulnerable to
> replay attacks. There are other reasons, but you can read them yourself at
> the URL's I'll provide in a moment.
>
> First, it's important to note that, if RP's *did* cache the OP address from
> a user's claimed URI, an attacker could compromise the OP, tell the RP "this
> NEVER expires", and log in as that user indefinitely. I haven't been able to
> read the specs well enough to figure out exactly where or how this is
> addressed, but I've been reading from lots of other sources too, and I
> generally gather that a user can tell the RP to re-check their claimed
> Identity, manually. The only thing that still bothers me is what happens
> when the user isn't *aware* that anyone else is logging in with their
> Identity to a RP; for comments posted to public (and indexed by search
> engines) sites this can work out, but what about a bank that accepted the
> user's personal details as provided by the OP?
>
> http://wiki.openid.net/Stateless_Mode
> http://openid.net/developers/specs/
>
> >Whenever user logs in, an RP should contact the "central digital identity"
> server to find out the OP serving this digital ID & then only redirect the
> user to appropriate OP for the authentication.
>
> Sounds like you're inserting an extra layer of centralization. As the
> process currently stands, an RP contacts the user's claimed URI to find out
> the OP serving that user's digital ID, and then redirects the user to that
> OP for the authentication, sending them there with a few extra pieces of
> information to get things started.
>
> >The central database is always going to say who my current OP is.
>
> If you keep the central database updated, that is. How is this update going
> to take place? Will it run a check every so often at your URI to see if
> anything has changed? Why not just look at that URI and leave it at that?
>

Babu>

Let me quote again the steps I wrote in my earlier email:

quote start "
        1. Let there be some central digitalID server to issue a digital
identity, which is not attached to any URL (say I go this server, register
myself & ask for a digital identity "babu_n"). And in this same server, I
would also associate my digital identity with "OP details".
        2. I would select an OP & register with OP. Provide my digital id
here & associate my digital ID with "my details" (like password,
personal/profession details, etc etc..). It should be mandated how OPs
should store "my details".
        3. I go to some OpenID enabled website & provide my id as "babu_n".
Here the OpenID enabled website now contacts the "central digitalID server"
& gets the OP details of the user (here "babu_n"). After that it allows the
user to get authenticated via OP.
" quote end

Here URIs are not used for digital identification. How many of general
internet users have URIs ? How can we ask some general internet user to have
an URI & then mangle the headers and so on ? So suggesting user to always
maintain some live URI for purposes of digitalID may not be appropriate.
Instead, digitalID is obtained by the user in step1 at central digitalID
server.

Coming to the question of when the update is going to happen in cetral
digitalID server:
So, in this context, whenever the user decides to switch from one OP to
another, he goes through the following steps:
    1. Exports all his details from his current OP
    2. register with new OP, provide digital ID ("babu_n") & import all the
details exported in step1.
    3. Logs into to "central digitalID server" & change the OP of the
digital id "babu_n" to new OP

There is no URIs involved. A user registers at central digitalID server &
gets his digital ID.



> If we're going to try adding more security to our personal info, why not
> keep all these details at the user's URI? Just add an extra line in the
> headers containing the URL of an XML file (probably also at the user's site)
> that, in turn, contains *encrypted* information. The cipher, unique for each
> item, is a full bitmask that your OP holds, and can send to RP's when you
> okay this to happen. The unencrypted information is with you (possibly on a
> computer not connected to the internet), and you can make up new keys when
> you switch to a new OP.
>
> Sure, the OP can request this XML file themselves, and use the keys you
> provided them with to gain all this information, but when you switch to a
> new OP and use new keys, the old OP's data is at risk of becoming dated
> (though probably not with eye or hair color). Yes, the length of an
> encrypted stream can provide clues as to its content, but you can easily pad
> it with other characters that decrypt to null or to blank spaces. And anyone
> eavesdropping on the communications between these nodes will be able to lift
> the keys, but only if those are transmitted without some encryption of their
> own. (I'm supportive of this whether COPPA applies to the user or not.)
>

Babu> Sounds very interesting. Is this already in specs ?


Thanks,
Babu


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