openId - sorua

[Michael Platzer]

(I just noticed that my reply to martin never found its way to the 
mailing-list. Here it is. I also appended his reply to my reply at the 
end. Sorry for the mess.)

------------------

>There's no reason why the thing at your URL has to be a weblog. At my
>identity URL I just have an HTML page with my name on it. TypeKey's
>identity URLs are (I assume) going to be the OpenID profile page. To use
>some of your examples, there's no reason why del.icio.us couldn't run an
>identity server to support URLs of a given form in their domain, such as
>mart.del.iciou.us or http://del.iciou.us/users/mart . 
>
That's the point. I want to be 'michi' the guy from 'twoday.net', and
not necessarily have a URL pointing to some (sometimes not very nice
looking) profile page. I guess that's the fundamental difference between
SORUA and openId/LID.

>What does twoday.net:michi actually map to? What is the server's real URL?
>  
>
twoday.net:michi is actually just a way the consumer decided to display
that User. The whole Identifier would be the End-Point of the AuthServer
(http://www.twoday.net/members/modSoruaAuthServer) together with the
Unique ID of that User Account (which is 'michi' in that case). The
consumer cuts that (if it wants to) down to twoday.net:michi, or to
'michi from twoday.net' or to whatever. And if i want to, the AuthServer
can easily tell the consumer also a specific url that is connected to
the user account.
I'm aware of the downside of such a long (non-memorizable)
AuthServer-URI, but that problem should be solvable through
AuthURI-auto-detection (for example as proposed by mario salzer here:
http://xprofile.berlios.de/USERID.txt, whereas i must admit that i still
have to take a closer look at that proposal).

SORUA mainly tries to tackle the problem, that we have to register at
each single service that pops up nowadays. I know that OpenId & LID try
to solve the same problem, but SORUA tries to do nothing else, even
thought the temptation is big.

>I'll leave others to deal with your other points, as they can probably
>give better answers than me.
>  
>
Thanks a lot for your answers. I'm especially looking forward to some
feedback regarding the crypto-stuff that goes on in OpenID. Why is that
necessary?

>It's quite likely that a gateway server for using a Sorua login on an
>OpenID consumer or vice-versa could be constructed quite easily. 
>
yes, i think so too.

greets,
  michi



-----------------

 >>
 >> That's the point. I want to be 'michi' the guy from 'twoday.net', and
 >> not necessarily have a URL pointing to some (sometimes not very nice
 >> looking) profile page. I guess that's the fundamental difference between
 >> SORUA and openId/LID.

For OpenID, you'd set things up so that your identity URL is either
michi.twoday.net or twoday.net/~michi (the pages at which can contain
anything you want) and LiveJournal would show that as "michi.twoday.net"
and "michi [twoday.net]" respectively. As I previously noted, that's up
to the consumer of course.


 >>>> What does twoday.net:michi actually map to? What is the server's real
 >>>> URL?
 >>>>
 >
 >> twoday.net:michi is actually just a way the consumer decided to display
 >> that User. The whole Identifier would be the End-Point of the AuthServer
 >> (http://www.twoday.net/members/modSoruaAuthServer) together with the
 >> Unique ID of that User Account (which is 'michi' in that case). The
 >> consumer cuts that (if it wants to) down to twoday.net:michi, or to
 >> 'michi from twoday.net' or to whatever. And if i want to, the AuthServer
 >> can easily tell the consumer also a specific url that is connected to
 >> the user account.


I'm still not sure that I'm understanding this correctly. I went and had
a look at twoday and found that it only supports three hardcoded
identity servers, but it's possible that I'm just misunderstanding the
interface as I don't understand German (?).  The same applies to moday.at.


 >> Thanks a lot for your answers. I'm especially looking forward to some
 >> feedback regarding the crypto-stuff that goes on in OpenID. Why is that
 >> necessary?


Paul and Brad are the ones to talk to about that, really. I'm a little
out of touch with the exact mechanics of the crypto in the protocol
myself as I've only been dealing with integration into applications.

The main thing that the crypto is used for, though, is so that the
consumer can be sure that it got an authoritative answer from the right
identity server. Since the consumer and the server both have a shared
key and (hopefully) no-one else knows it the consumer can be sure that a
signature based on that shared key came from the right server. The old
protocol (protocol version "zero") used asymmetric crypto to achieve a
similar end, but shared key encryption is easier to implement.