MySpace announces OP support

[John Panzer-3]

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/ 

_______________________________________________
general mailing list
general@...
http://openid.net/mailman/listinfo/general

[Peter Williams]

I think this community is mature enough to rejoice in adoption by a major brand - even if it is not the purest of adoptions. The web is built one adoption at a time. As the obvious benefits flow, folks do more...

The benefits of websso are just obvious. Of the 50 sites we armed with websso over the last 18 months (and we have 36 more, grassroots, "local adoptions" in the queue just within US realty), none have ever turned it off. They have stayed with the program - even distinguishing between poor implementation (i.e. Peter grade programming/operations) and concept, when things stop working for a bit. They are just annoyed...at the lack of the very websso they soon are taking for granted.

AS the very topic of "id sharing" stresses commercial interests and invokes lots of politics, its critical to AVOID being doctrinaire.

Learn from SSL! As soon as we dumped the military PKI religion being imposed on IETF, we got mass web adoption (and an F thereafter in the exam following the military key management class)! Quite what that adoption became.. is rather amorphous in nature, and hard to define academically. But, mass adoption there was, at varying grades of quality!

-----Original Message-----
From: general-bounces@... [mailto:general-bounces@...] On Behalf Of John Panzer
Sent: Wednesday, July 23, 2008 8:29 AM
To: OpenID List
Subject: [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/

_______________________________________________
general mailing list
general@...
http://openid.net/mailman/listinfo/general
_______________________________________________
general mailing list
general@...
http://openid.net/mailman/listinfo/general

[Lukas Rosenstock]

The news is on German IT Media Heise (and its English/UK counterpart):
http://www.heise-online.co.uk/news/MySpace-links-up-with-the-OpenID-Foundati
on--/111162
http://www.heise.de/netze/MySpace-schliesst-sich-der-OpenID-Foundation-an--/
news/meldung/113215

Do they actually join the foundation (the German article says so, the
English one at least in the headline) or just implement the technology? Does
anyone know more?

Lukas

-----Ursprüngliche Nachricht-----
Von: general-bounces@... [mailto:general-bounces@...] Im
Auftrag von John Panzer
Gesendet: Mittwoch, 23. Juli 2008 17:29
An: OpenID List
Betreff: [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-e
nabled-accounts-to-over-a-half-billion/

_______________________________________________
general mailing list
general@...
http://openid.net/mailman/listinfo/general

_______________________________________________
general mailing list
general@...
http://openid.net/mailman/listinfo/general

[James Tindall]

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



_______________________________________________
general mailing list
general@...
http://openid.net/mailman/listinfo/general

[Dan Ragle-2]

Just some guesses:

Are you sure you're sending everything back; especially assoc_handle,
sig, response_nonce, signed, op_endpoint (i.e., the things you didn't
send in your original request but received from the OP)?

Are you sending the data as a POST request (required for direct
requests), and not a GET?

Is there perhaps some type of character encoding (or lack thereof)
going on behind the scenes that may be altering the values of the
parameters that are actually being sent to the OP? I.E., is the
content-type being set to application/x-www-form-urlencoded and
the data actually properly URL encoded? I like to use wireshark
to ensure I know exactly what the data looks like pre and post my
script getting it.

Are you checking for true/false (lower case)?

Hope this is helpful...

Dan

> 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
>
>
>
> _______________________________________________
> general mailing list
> general@...
> http://openid.net/mailman/listinfo/general
>
>

_______________________________________________
general mailing list
general@...
http://openid.net/mailman/listinfo/general

[James Tindall]

Thanks for your suggestions Dan! Your intuition was correct, I realised
with help from Shane Weeder that some of my code catering for openid 1
responses without a response_nonce was replacing the response_nonce in
openID 2 responses with the RP generated nonce.

=james.tindall

Dan Ragle wrote:

> Just some guesses:
>
> Are you sure you're sending everything back; especially assoc_handle,
> sig, response_nonce, signed, op_endpoint (i.e., the things you didn't
> send in your original request but received from the OP)?
>
> Are you sending the data as a POST request (required for direct
> requests), and not a GET?
>
> Is there perhaps some type of character encoding (or lack thereof)
> going on behind the scenes that may be altering the values of the
> parameters that are actually being sent to the OP? I.E., is the
> content-type being set to application/x-www-form-urlencoded and
> the data actually properly URL encoded? I like to use wireshark
> to ensure I know exactly what the data looks like pre and post my
> script getting it.
>
> Are you checking for true/false (lower case)?
>
> Hope this is helpful...
>
> Dan
>
>  
>> 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
>>
>>
>>
>> _______________________________________________
>> general mailing list
>> general@...
>> http://openid.net/mailman/listinfo/general
>>
>>
>>    
> _______________________________________________
> general mailing list
> general@...
> http://openid.net/mailman/listinfo/general
>
>  

_______________________________________________
general mailing list
general@...
http://openid.net/mailman/listinfo/general