James Tindall | 24 Jul 12:03
Gravatar

[OpenID] check_authentication

I'm trying to test how the RP library I'm working on handles stateless 
mode - all works fine up to the point where I request that the OP verify 
the sig in the response. Whatever OP I try they all respond that the sig 
is not valid. It seems it must be some bug in my code but I really can't 
figure out what the problem could be?

For testing I'm forcing stateless session mode, so there's no 
association negotiated and the only params sent in the redirect url are 
openid.ns, openid.mode, openid.realm, openid.return_to, openid.identity 
and openid.claimed_id (also for testing purposes I'm preventing any 
extensions being added). The response to the authetication request is 
positive and passes all verification tests right up to the point where I 
request the OP to verify the sig, the response for which always contains 
is_valid=FALSE. I have checked and checked and double checked that - as 
the specs dictate - the check_authentication request post data only 
contains the exact same query params as received from the OP in the 
positive assertion except with the mode changed to 'check_authentication'.

As the response of is_valid=false is so uninformative and as far as I 
can tell I have followed the specs this has me kind of stumped.

I know this is tricky without source code or debug data but does anyone 
have any idea as to what could be the problem - or what I should try in 
order to find out??

many thanks,

=james.tindall
Egon Kocjan | 23 Jul 19:31

[OpenID] web server - outgoing connections?

Hello,

I am new to openid, so forgive me if this will sound obvious. Let's say 
I have a web site and I want to support openid, so users of my site will 
be able login using their openid url. The trouble I see here is that my 
web server will have to connect to random IPs on the internet as a part 
of authentication process*, am I right? Is there an authentication mode, 
where client's browser does all the outgoing communication?

* why this is a problem:
- I don't want my web server to be used in ddos attacks
- companies that are serious about security usually deny unrestricted 
outgoing connections from servers, so it's also a deployment issue

Thanks,
Egon
John Panzer | 23 Jul 17:28
Picon
Favicon
Gravatar

[OpenID] MySpace announces OP support

Great!  Does anyone have details on timing?  (I missed this news item 
yesterday, I'm amazed I don't see it on this
list...):

http://www.techcrunch.com/2008/07/21/myspace-to-join-openid-bringing-total-enabled-accounts-to-over-a-half-billion/ 
Frans Thamura | 21 Jul 00:58

[OpenID] OpenID in Indonesia

hi there

just chat with snorii

is there a way to apply become OpenID reps?

i stay in Indonesia, and that will be cool if there is someone host
the OpenID program so people here aware about OpenID

i want to apply for rep in Indonesia

-- 
--

-- 
Frans Thamura
Meruvian Foundation

Mobile: +62 855 7888 699
YM: fthamura <at> yahoo.com
GTalk: frans <at> meruvian.org
Skype: fthamura
Linkedin: http://www.linkedin.com/in/fthamura

Discuss BlueOxygen Projects at blueoxygen <at> yahoogroups.com
Shane B Weeden | 18 Jul 10:27
Picon

[OpenID] linking an openid to an existing account


I have a question about best-practices.

Consider a website with an existing user base. You want to provide the users an alternate means of authentication with an OpenID (e.g. replacing existing password-based authentication), so you show them a page (after they've authenticated) which says "Link an OpenID to your account".

The user authenticates with an OpenID, and the site associates <something> with the user's existing account so that in the future OpenID authentication can happen as the primary login and the same <something> can be used to figure out which user account to login as.

My question is what is the best thing to use as <something>. There are options, most with certain limitations, and I wanted to see if the community has a general pattern or recommendation.

For example, the <something> could be (non-exhaustive):

1. The "as-typed-in-by-the-user" user-supplied identifier. This has limitations that a user can have multiple user-supplied identifiers that normalize to the same id, and they can confuse themselves (e.g. shane.myopenid.com = http://shane.myopenid.com). This doesn't work well with OP identifiers.

2. The claimed identifier after discovery. This doesn't play well with delegation if a user switches OP's but keeps their user-supplied identifier.

3. Some other combination?

Your thoughts appreciated.
_______________________________________________
general mailing list
general <at> openid.net
http://openid.net/mailman/listinfo/general
Andrew Arnott | 15 Jul 20:50
Picon
Gravatar

Re: [OpenID] Multiple endpoints in a single XRDS document

As I understand it, checkid_immediate is an optional step the RP can take, that was added for AJAX scenarios.  In my mind, this is a useless feature as checkid_setup also tends to be 'immediate' if checkid_immediate would have worked, and if checkid_immediate fails, then the very next thing the RP inevitably does is follow up with a checkid_setup request.

As far as testing for OP-deadness, checkid_immediate is no good because it's a redirect of the browser just as checkid_setup is.  If the OP is dead, the user gets a dead-end error page regardless of what the openid.mode is set to.

Now, assuming all OPs are alive, the idea of running through all endpoints with checkid_immediate first to see if any happen to authenticate, and only if that fails doing a checkid_setup on the first good OP in the list is an interesting idea.  It would serve the user as he/she would have a higher likelihood of not being prompted for credentials, which is cool.  On the negative side, it means that if the user has 3+ OPs listed, he gets redirected 4 times before finally seeing his first OP's authentication page if none of them are willing to checkid_immediate.

On Tue, Jul 15, 2008 at 9:16 AM, James Tindall <james <at> atomless.com> wrote:
I've not double checked what the spec has to say about this Andrew but it seems to me that if an association with the chosen OP exists and is alive then the RP should simply attempt authorization using 'checkid_immediate' and if that then fails the RP should try authentication using the next endpoint in the list?




Andrew Arnott wrote:
Another thought: since a responsible RP only creates a single association
with an OP and stores it until it expires, and these associations often last
days, if the user has an endpoint in the XRDS doc that points to an OP that
is currently down, but with whom the RP has an existing, unexpired
association with, the RP shouldn't try to create an association with that
OP.  Instead, it might say to itself "yes, I successfully have an
association with this OP, so I'll redirect the user to it", but the OP
happens to be down for 5 hours that day, effectively disabling the user's
ability to log in, in spite of the multiple OPs listed in the XRDS doc.

So... perhaps OpenID can have a "ping, are you alive?" message in its
protocol.  But then we're no better than "dumb" RPs having to make multiple
hits to the OP instead of just one.

Another idea that keeps occuring to me is that the RP can use a frameset to
keep an RP frame around and have the OP authentication happen in another
frame (iframe or frameset would work).  That way, the RP frame could have
something like "Is your Provider not responding?  Click here to try your
next best choice..." or something to that effect.  The problem with this
idea is that the URL on the browser will always be the RP, so the user will
have one less way to confirm that this is indeed his genuine Provider and
not one of those notorious OpenID RP phishing attacks.

Anyone have any idea how to solve this dead OP problem?

On Tue, Jul 15, 2008 at 1:52 AM, James Tindall <james <at> atomless.com> wrote:

 
I've recently been writing an openid relying party library for the
Kohana php framework and I think you're right, the way I've tried to
handle multiple enpoints returned from the discovery phase is to first
sort them by their priority values and then also filter out any that do
not meet the (extension / security / openid-version) requirements set in
the current relying party configuration and then finally attempt to
establish an association with each endpoint in turn until a successfull
association response is returned.

I feel that all this is best done invisibly rather than requesting the
user to jump through extra hoops. The user has after all -at some point-
set the priority of the endpoints listed in the xrds and I suspect that
most would not wish for further input during the process of
authentication. My assumption being that the point of multiple endpoints
is to hopefully cater for the requirements of as many different relying
parties as possible and to have alternative/backup endpoints incase of
errors or failures with any of the other endpoints in the list during
authentication?

=james.tindall

Andrew Arnott wrote:
   
I'm curious how other libraries do (or plan to) handle multiple endpoints
     
in
   
a single XRDS document.  I see a few considerations, in order:

  1. Enumerate the services in the XRDS-defined priority order
  2. Skip the services that do not expose OpenID endpoints.
  3. Skip the OpenID endpoints with Providers that do not quality
  (whitelist/blacklist or advertised extension support
  4. Take the first endpoint that is left after these filters.

But what about the rest of the endpoints listed?  Here are some
possibilities:

  1. Just use the first endpoint and trust it works.
  2. Try each one successively.  That is, the RP should attempt to
  establish an association with each one until it succeeds with one, and
     
then
   
  redirect the user to that one for authentication.  Redirecting the
     
user to
   
  an unavailable Provider will result in a dead end failure page and the
     
RP
   
  will lose the opportunity at this point to try the next endpoint.
  3. A variant on the last, except that in addition to skipping OPs that
     
do
   
  not respond to association requests, allow the user to "fail" or
     
cancel the
   
  authentication on the first provider and proceed to the second
     
provider
   
  listed for another authentication attempt.
  4. Offer the user a list of his/her providers to choose from for
  authentication.

Have thoughts been written already on which of these are best and/or
     
common
   
in existing libraries?


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

_______________________________________________
general mailing list
general <at> openid.net
http://openid.net/mailman/listinfo/general

     
--

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

James Tindall

http://www.atomless.com/

T : +44(0)1305 250 377
M : +44(0)7971 012 032
F : +44(0)1305 250 377

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

_______________________________________________
general mailing list
general <at> openid.net
http://openid.net/mailman/listinfo/general

   

 

--

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

James Tindall

http://www.atomless.com/

T : +44(0)1305 250 377
M : +44(0)7971 012 032
F : +44(0)1305 250 377

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


_______________________________________________
general mailing list
general <at> openid.net
http://openid.net/mailman/listinfo/general
Andrew Arnott | 15 Jul 07:05
Picon
Gravatar

[OpenID] Multiple endpoints in a single XRDS document

I'm curious how other libraries do (or plan to) handle multiple endpoints in a single XRDS document.  I see a few considerations, in order:

  1. Enumerate the services in the XRDS-defined priority order
  2. Skip the services that do not expose OpenID endpoints.
  3. Skip the OpenID endpoints with Providers that do not quality (whitelist/blacklist or advertised extension support
  4. Take the first endpoint that is left after these filters.
But what about the rest of the endpoints listed?  Here are some possibilities:
  1. Just use the first endpoint and trust it works.
  2. Try each one successively.  That is, the RP should attempt to establish an association with each one until it succeeds with one, and then redirect the user to that one for authentication.  Redirecting the user to an unavailable Provider will result in a dead end failure page and the RP will lose the opportunity at this point to try the next endpoint.
  3. A variant on the last, except that in addition to skipping OPs that do not respond to association requests, allow the user to "fail" or cancel the authentication on the first provider and proceed to the second provider listed for another authentication attempt.
  4. Offer the user a list of his/her providers to choose from for authentication.
Have thoughts been written already on which of these are best and/or common in existing libraries?

_______________________________________________
general mailing list
general <at> openid.net
http://openid.net/mailman/listinfo/general
SitG Admin | 12 Jul 09:45

[OpenID] A balance of power: Identity based on DIStrust

I've been thinking about privacy, and for a moment I blanked out on 
the fact that we have this feature called "Delegation" now, which 
lets us outsource the authentication to a site other than the one our 
Identity is being hosted on. This doesn't really provide any 
*security* since the ID-hosting site can still temporarily redirect 
RP's to an OP of it's choice, bypassing the security at a user's 
designated OP, and then it can even make matters *worse* by giving 
that delegated-to OP the opportunity to masquerade as the user. So, 
we have 3 parties here who can act as the user, and 2 of them could 
be any number of employees with the ability to make changes. The only 
benefits I see delegation providing are outsourcing (in case the 
ID-hosting site can't run, or isn't running, a Provider themselves) 
and privacy (the ID-hosting site can't track which RP's are checking 
the user's authenticity with an external OP).

(Now, the ID-hosting site *can* look for User-Agent strings 
associated with common OpenID libraries, and check for requests to 
every user's Identity page, looking up the IP addresses of probable 
RP's to find out what site they were coming from. To mitigate this, I 
suggest an extension to OpenID whereby the lookup of an Identity page 
to discover the OpenID headers can *itself* be outsourced - this 
wouldn't help with timing, though, so the ID-hosting site could still 
(potentially) keep track of *when* a user was authenticating to a new 
service, and how often they used their OpenID elsewhere.)

While a single rogue employee (or boss, or IT sysadmin) may be able 
to leverage the resources of their entire company, their influence 
outside that sphere should be limited. Not only is there the expected 
difficulty of feeling out potential companions in crime, but some of 
these other companies will be *competitors*. I'm not thinking of the 
compounded effect here (where prospective co-conspirators are looked 
upon with more than the usual suspicion, because they're not usually 
friendly anyway), though this can be a factor; I'm looking at the 
typical effect of this, where rivals don't *trust* one another (even 
where misuse/abuse of information isn't the issue) because the 
"proper" use of information could still work against *your* company. 
I'm assuming we can count on the idea that giving any advantage to 
the competition will evoke a strong adverse reaction; indeed, that's 
part of the problem with gaining acceptance for OpenID so far.

The idea I'm toying with now is whether it's possible to *exploit* 
this atmosphere of distrust (which is ironic, since usually we speak 
about exploiting TRUST, not its opposite) by requiring users to 
authenticate with multiple (competing) Identity sites. The rated 
"Strength" of a user's Identity would be proportionate to the number 
of such sites they had authenticated as - since, presumably, it would 
be increasingly more difficult to persuade the people at all these 
rival companies to cooperate with each other for such a purpose! 
(Especially with the advantage they could gain by *exposing* their 
rivals in an attempt.)

One question is how to prevent someone at an ID-hosting company from 
simply registering accounts with other ID-hosting companies, all 
pointing (for real) to the same malicious OP they temporarily 
redirect Consumers to on the user's actual Identity page. This fits 
in neatly with my observation on how existing practices can 
(potentially) easily implement this sort of security in the real 
world; (some) OP's already allow you to "claim" different sites and 
link them all together under your profile, so it should be easy 
enough to have the OP challenge the user for credentials just once 
for all their URI's. Since the OP has all those Identities, it can 
send them (or a selected subset of them, for privacy) along to the RP 
for verification (checking that the indicated pages actually have 
OpenID headers pointing to that OP), providing the user with the 
convenience of not having to enter them.

Another question is how to prevent OP's from posing as the user. 
This, thankfully, seems far less tricky; let the user specify 
multiple OP's in their OpenID headers and then challenge *each* of 
them, increasing OP Strength accordingly (since presumably the 
different OP companies wouldn't be cooperating, either). This would, 
of course, essentially toss privacy out the window (since *several* 
OP's would know your OpenID activity), but it might be different if 
*all* the OP's were good about the privacy of their users (and 
*would* be different if you didn't care about privacy!), so it seems 
comparable to other (existing) threats to privacy present in OpenID 
already.

Persuading companies to embrace a system that openly acknowledges 
"None of us trust one another, so let's accept it and tell the user 
to like us because we don't require the user to trust *only* us." 
could well be the most difficult part of this idea to implement :)

-Shade
SitG Admin | 12 Jul 02:59

Re: [OpenID] OpenID and Patent... ?

>In fact it was a confusion with this patent:  >http://news.openideurope.eu/us20040205243_0_959_A1.pdf

You aren't the first to wonder at their similarities;
http://suse.groenbaek.net/openlife/2008/01/20/is-openid-like-digital-identity/
The linked-to Digital Identity site is effectively down now (and has been for several years, according to the Internet Wayback Machine), but previous versions show that "Digital Identity Technology is designed and built by Ascio Technologies Inc.":
http://www.ascio.com/
It might be worth checking in with them about a non-assertion covenant. If you're looking to contact (either of) the inventors personally, O'Reilly Media has a page on Nikolaj Nyholm:
http://radar.oreilly.com/nikolaj/
This one looks promising because identity is mentioned. I also found a LinkedIn page for one "Hans Hurvig", but other than the location (Copenhagen) there's nothing to show that he's related to the Hans who copatented an identity technology.

-Shade
_______________________________________________
general mailing list
general <at> openid.net
http://openid.net/mailman/listinfo/general
Andrew Arnott | 8 Jul 23:58
Picon
Gravatar

[OpenID] Canonical OpenID url form

What is the canonical form of an OpenID URL? One with the %AB%CD hex encoding for unicode chars in the URL or with the actual unicode chars? For the purposes of displaying to the user and storing in the RP's database.

The spec doesn't seem to have anything to say on this.  The reason I think it's not a simple automatic answer is the unicode chars may be what the user typed in and what exists on the server, but in transit, these characters are translated to %AB%CD in order to be validly escaped URI strings.  So one could argue that the unicode characters are never part of the protocol and therefore should not be in the Claimed Identifier.  On the other hand, if I were japanese and had to look at %AB%CD instead of my native character whenever I saw my OpenID on a web page I'd find it slightly annoying.

_______________________________________________
general mailing list
general <at> openid.net
http://openid.net/mailman/listinfo/general
SitG Admin | 7 Jul 18:14

[OpenID] Provider-side analytics

I was looking over the latest message:

"* Providers can give them much more analytics on their users' 
behavior pattern (this can be anonymous to keep user identity private 
and report something like 30% of people who visit your site also 
visit site 'x')."

I'm thinking that user identity wouldn't really be private if you 
had, say, ONE user from a given Provider and 100% of that OP's users 
who visited your site also visited another site. As favorable to 
enterprise-level RP's as it might be, I have to recommend that such 
statistics - if shared at all - only be available for "popular 
websites" (for visitors to that RP via the OP).

-Shade

Gmane