André Cruz | 1 Jun 12:08 2009
Picon

Re: [OpenID] Interoperability problem with OpenID POST response between myopenid and Google

On May 27, 2009, at 16:17 , Andrew Arnott wrote:

> Thanks.  The logs you sent were what I asked for, but unfortunately  
> they don't include any detail that's leading me to the problem.   
> I'll try again to repro it locally, since the log verbosity can be  
> increased to show more about the signing verification.

How are your tests going? Do you want me to run my tests against  
another RP?

André
Andrew Arnott | 1 Jun 15:41 2009
Picon

Re: [OpenID] Interoperability problem with OpenID POST response between myopenid and Google

Although I've not been able to reproduce the problem yet, I did add a few POST interop tests to the OSIS site.  Can you test against that and if you can repro it give me instructions to do so?
RP accepts POST assertion
OP accepts POSTed authentication requests
OP sends large assertions as POST

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre


On Mon, Jun 1, 2009 at 3:08 AM, André Cruz <andre.cruz <at> co.sapo.pt> wrote:
On May 27, 2009, at 16:17 , Andrew Arnott wrote:

Thanks.  The logs you sent were what I asked for, but unfortunately they don't include any detail that's leading me to the problem.  I'll try again to repro it locally, since the log verbosity can be increased to show more about the signing verification.

How are your tests going? Do you want me to run my tests against another RP?

André



_______________________________________________
general mailing list
general <at> openid.net
http://openid.net/mailman/listinfo/general
André Cruz | 1 Jun 17:18 2009
Picon

Re: [OpenID] Interoperability problem with OpenID POST response between myopenid and Google

Great suite of tests, Andrew.

On Jun 1, 2009, at 14:41 , Andrew Arnott wrote:

Although I've not been able to reproduce the problem yet, I did add a few POST interop tests to the OSIS site.  Can you test against that and if you can repro it give me instructions to do so?
RP accepts POST assertion

Google/Blogger comments FAIL.

Choose openid, fill captcha, result: Your OpenID credentials could not be verified.


SourceForge login FAIL


Error: Could not verify your OpenID. Please try again.


Plaxo OK



myopenid OK

Can you make one that exercises the UTF-8 encoding of attributes (SREG and AX)? Both in the OP (to check the signature generated) and in the RP (to check the signature verification).

Thanks,
André

_______________________________________________
general mailing list
general <at> openid.net
http://openid.net/mailman/listinfo/general
Santosh Rajan | 2 Jun 06:44 2009
Picon

[OpenID] Google Wave is Web 3.0


I am aware this blogpost of mine is off topic here. I would like to post it
here to push a case for Jabber ID's as OpenID's.

If you search the web to find out what web 2.0 and 3.0 is, you will find
them associated with social aspects. Things like web 2.0 is the "social web"
etc. But really each version of the web is a technological leap.

1) Static Web - Web 1.0 was the static web were you had to change the page
or reload the page to change its contents.
2) Dynamic Web - Web 2.0 was the dynamic web where you could change the
content without changing your browser page. (Google Maps, Ajax Pages).
3) Real time Web - Web 3.0 is the real time web where the content of the
page will change in real time as the "author(s)" changes it. Google Wave
makes this possible.

Web 2.0, the dynamic web took off in 2004 with Google maps. That is when
developers realized that you could change the contents of the page in place,
paving the way for Ajax technologies, leading to the social web.

Web 3.0 as described above is a technological leap to the next level. What
is interesting is that the very same people who brought about Web 2.0 with
Google maps, the brothers, Lars and Jens Rasmussen are also the ones who are
behind Google Wave, poised to bring about web 3.0!

Much has already been written about Google Wave, some even skeptical. But
most of the articles seem to have missed the fundamental point what Google
Wave is all about. What Google Wave has done is to combine the static,
dynamic, real time aspects of the web into one composite object called the
"Wave".

The Wave Object can be turned into anything the developer wants. It can be
turned into a message, blog comment, blog, real time game, tweet, a wall,
literally limited only to your imagination. That is why 4000 developers gave
it a standing ovation when it was revealed at the Google IO conference.
(Standing ovations are an extremely rare occurrence at developer
conferences).

Imagine a chat messenger without its text box (where you type), which has
only its display area. Now imagine that you can type right into the display
area. While you are typing the person you are chatting with can see you
typing in real time. Actually if it is a chat conference all the people can
type in at the same time and all of them can seen it in real time. You can
add, pics video's and other types of content into the display area. You can
fork off private conversations. A robot can spell check while all this is
happening. The possibilities are endless. And this is what a Google Wave is.

Actually Google Wave sits on top of the same protocol that Google Talk sits
on. The Jabber protocol now called XMPP. Google added to this protocol and
called it the Wave protocol. It is an Open protocol, anyone can implement
this protocol. Google is not keeping anything proprietary here. I can
already see an army of developers piling on to this technology and you will
see a lot cool stuff coming out within months.

Web 3.0 is here!

-----

Santosh Rajan
http://santrajan.blogspot.com http://santrajan.blogspot.com 
--

-- 
View this message in context: http://www.nabble.com/Google-Wave-is-Web-3.0-tp23826395p23826395.html
Sent from the OpenID - General mailing list archive at Nabble.com.
Chris Messina | 2 Jun 07:22 2009
Picon

Re: [OpenID] Beanstalk removes OpenID support

On Thu, May 28, 2009 at 12:36 PM, Andrew Arnott <andrewarnott <at> gmail.com> wrote:
I don't know how one could add OpenID support to SVN.  But OAuth would be a natural.  An 'svn authorize" command would pop up a web browser where the user would log into the SVN server site (the OAuth SP) using OpenID or any other credential, and then SVN could capture the OAuth token and use that programmatically from then on. 

Chris, what can we do to better "package" OpenID and OAuth as a combined solution for these scenarios?

Well, for one thing, document how that kind of flow might actually be implemented!

And, FWIW, Google Code and Basecamp both provide a decent solution for dealing with OpenID users in cases with browser-less situations like the command-line... by providing a revokable/resettable secret that can be used in combination with one's OpenID to perform CLI authentication w/o creating a new username.

It's all in how you think about implementing the solution — being pragmatic and not overly religious!

;)

Chris
 



2009/5/28 Ben Laurie <benl <at> google.com>

On Wed, May 27, 2009 at 11:43 PM, Chris Messina <chris.messina <at> gmail.com> wrote:
> So Beanstalk just removed support for OpenID from their hosted subversion
> app:
> http://www.wildbit.com/blog/2009/05/26/what-happened-to-openid-support-in-beanstalk/
> I find this both interesting and frustrating, since I used OpenID to sign in
> to my Beanstalk account and now can't remember my username. Heh, go figure.
> Still, it points out that the lack of desktop/API solution for OpenID as a
> *baked* solution could really hurt the protocol as OpenID seeps into more
> applications. I mean, Beanstalk is still one application, but the fact that
> we as a community haven't articulated how to use OpenID with SVN (or built
> the technical machinery to make that easy) ultimately impacts adoption.
> Anyway, thought it was worth bringing up here, since it's something I hadn't
> really seen before.

It is also interesting that they ask for OAuth support in SVN, but
what they actually need is OpenID support, isn't it?

> Chris
>
> --
> Chris Messina
> Open Web Advocate
>
> Website: http://factoryjoe.com
> Twitter: http://twitter.com/chrismessina
> Facebook: http://facebook.com/chrismessina
>
> Diso Project: http://diso-project.org
> OpenID Foundation: http://openid.net
>
> This email is:   [X] bloggable    [ ] ask first   [ ] private
>
> _______________________________________________
> general mailing list
> general <at> openid.net
> http://openid.net/mailman/listinfo/general
>
>
_______________________________________________
general mailing list
general <at> openid.net
http://openid.net/mailman/listinfo/general




--
Chris Messina
Open Web Advocate

Website: http://factoryjoe.com
Blog: http://factoryjoe.com/blog
Twitter: http://twitter.com/chrismessina

Diso Project: http://diso-project.org
OpenID Foundation: http://openid.net

This email is:   [ ] bloggable    [X] ask first   [ ] private
_______________________________________________
general mailing list
general <at> openid.net
http://openid.net/mailman/listinfo/general
Ben Laurie | 2 Jun 08:03 2009
Picon

Re: [OpenID] Beanstalk removes OpenID support

On Mon, Jun 1, 2009 at 10:22 PM, Chris Messina <chris.messina <at> gmail.com> wrote:
> On Thu, May 28, 2009 at 12:36 PM, Andrew Arnott <andrewarnott <at> gmail.com>
> wrote:
>>
>> I don't know how one could add OpenID support to SVN.  But OAuth would be
>> a natural.  An 'svn authorize" command would pop up a web browser where the
>> user would log into the SVN server site (the OAuth SP) using OpenID or any
>> other credential, and then SVN could capture the OAuth token and use that
>> programmatically from then on.
>>
>> Chris, what can we do to better "package" OpenID and OAuth as a combined
>> solution for these scenarios?
>
> Well, for one thing, document how that kind of flow might actually be
> implemented!
> And, FWIW, Google Code and Basecamp both provide a decent solution for
> dealing with OpenID users in cases with browser-less situations like the
> command-line... by providing a revokable/resettable secret that can be used
> in combination with one's OpenID to perform CLI authentication w/o creating
> a new username.

I don't think Google Code does ... but clearly it could, using the
mechanism it currently uses for generating passwords. That is, as you
say, a resettable random string, which could be used as an unguessable
user ID instead of as a password. Alternatively, if we used email
addresses as IDs, their email address could be their user id and
OpenID used to generate the password, much as Google Code does today.
Just saying.

Obviously, the fact you have to use the password at all is SSO FAIL,
but to fix that I guess CLI apps have to figure out how to talk to
browsers. At least, in the OpenID world. There are other worlds.

> It's all in how you think about implementing the solution — being pragmatic
> and not overly religious!
> ;)
> Chris
>
>>
>>
>> 2009/5/28 Ben Laurie <benl <at> google.com>
>>>
>>> On Wed, May 27, 2009 at 11:43 PM, Chris Messina <chris.messina <at> gmail.com>
>>> wrote:
>>> > So Beanstalk just removed support for OpenID from their hosted
>>> > subversion
>>> > app:
>>> >
>>> > http://www.wildbit.com/blog/2009/05/26/what-happened-to-openid-support-in-beanstalk/
>>> > I find this both interesting and frustrating, since I used OpenID to
>>> > sign in
>>> > to my Beanstalk account and now can't remember my username. Heh, go
>>> > figure.
>>> > Still, it points out that the lack of desktop/API solution for OpenID
>>> > as a
>>> > *baked* solution could really hurt the protocol as OpenID seeps into
>>> > more
>>> > applications. I mean, Beanstalk is still one application, but the fact
>>> > that
>>> > we as a community haven't articulated how to use OpenID with SVN (or
>>> > built
>>> > the technical machinery to make that easy) ultimately impacts adoption.
>>> > Anyway, thought it was worth bringing up here, since it's something I
>>> > hadn't
>>> > really seen before.
>>>
>>> It is also interesting that they ask for OAuth support in SVN, but
>>> what they actually need is OpenID support, isn't it?
>>>
>>> > Chris
>>> >
>>> > --
>>> > Chris Messina
>>> > Open Web Advocate
>>> >
>>> > Website: http://factoryjoe.com
>>> > Twitter: http://twitter.com/chrismessina
>>> > Facebook: http://facebook.com/chrismessina
>>> >
>>> > Diso Project: http://diso-project.org
>>> > OpenID Foundation: http://openid.net
>>> >
>>> > This email is:   [X] bloggable    [ ] ask first   [ ] private
>>> >
>>> > _______________________________________________
>>> > general mailing list
>>> > general <at> openid.net
>>> > http://openid.net/mailman/listinfo/general
>>> >
>>> >
>>> _______________________________________________
>>> general mailing list
>>> general <at> openid.net
>>> http://openid.net/mailman/listinfo/general
>>
>
>
>
> --
> Chris Messina
> Open Web Advocate
>
> Website: http://factoryjoe.com
> Blog: http://factoryjoe.com/blog
> Twitter: http://twitter.com/chrismessina
>
> Diso Project: http://diso-project.org
> OpenID Foundation: http://openid.net
>
> This email is:   [ ] bloggable    [X] ask first   [ ] private
>
Santosh Rajan | 2 Jun 15:28 2009
Picon

[OpenID] OpenID Discovery for Email like identifiers - Draft 0.1


I have posted a draft spec on the wiki to get the ball rolling on this one.
http://wiki.openid.net/OpenID-discovery-for-Email-Like-identifiers OpenID
Discovery for Email like identifiers - Draft 0.1 
Lets have some discussion on this in order to add this into the 2.1
proposal.

-----

Santosh Rajan
http://santrajan.blogspot.com http://santrajan.blogspot.com 
--

-- 
View this message in context: http://www.nabble.com/OpenID-Discovery-for-Email-like-identifiers---Draft-0.1-tp23832524p23832524.html
Sent from the OpenID - General mailing list archive at Nabble.com.
Dirk Balfanz | 2 Jun 20:03 2009
Picon

Re: [OpenID] OpenID Discovery for Email like identifiers - Draft 0.1

In general, I don't think you need to "adapt" webfinger. Webfinger gives you everything you need. The OpenID community just needs to decide whether the email-like identifiers falling out of webfinger are acceptable OpenIDs.

Couple of specific comments:

- re signatures: I would just use whatever the XRI TC comes up with there for XRD signing.
- I don't think you should have the openid21.provider Rel-type with the URI. Since you start with an email(-like) identifier, it is clear that you're performing discovery on an identifier for a user, not for a host. So you should only look for a Link element that has a URITemplate in it. If you want to map all users to the same endpoint, just make it a template that doesn't actually have any unbound variables in it.
- "openid21.usermeta" should should be something generic like "describedby"  - as you point out that's the user's _meta data_, not just OpenID stuff (although there was some discussion at IIW that "describedby" isn't appropriate b/c the email-like identifier isn't technically a URI, and URITemplates, and "describedby" are supposed to be for URIs - but I think that's a technicality we'll work out).
- the openid21.local_id being its own Link seems weird to me. Why not something like this:

<Link>
  <Rel>openid.provider</Rel>
  <URI>http://openidprovider.com/op</URI>
  <openid:LocalID xmlns:openid="http://...">some-local-id</openid:LocalID>
</Link>

Dirk.

On Tue, Jun 2, 2009 at 6:28 AM, Santosh Rajan <santrajan <at> gmail.com> wrote:

I have posted a draft spec on the wiki to get the ball rolling on this one.
http://wiki.openid.net/OpenID-discovery-for-Email-Like-identifiers OpenID
Discovery for Email like identifiers - Draft 0.1
Lets have some discussion on this in order to add this into the 2.1
proposal.

-----

Santosh Rajan
http://santrajan.blogspot.com http://santrajan.blogspot.com
--
View this message in context: http://www.nabble.com/OpenID-Discovery-for-Email-like-identifiers---Draft-0.1-tp23832524p23832524.html
Sent from the OpenID - General mailing list archive at Nabble.com.

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

_______________________________________________
general mailing list
general <at> openid.net
http://openid.net/mailman/listinfo/general
Santosh Rajan | 2 Jun 20:44 2009
Picon

Re: [OpenID] OpenID Discovery for Email like identifiers - Draft 0.1


Dirk Balfanz wrote:
> 
> In general, I don't think you need to "adapt" webfinger. Webfinger gives
> you
> everything you need. 
> 

Point Taken

> The OpenID community just needs to decide whether the
> email-like identifiers falling out of webfinger are acceptable OpenIDs.
> 

I believe there is some traction on this matter. Why don't we put this up
for voting on the foundation? 

> Couple of specific comments:
> - re signatures: I would just use whatever the XRI TC comes up with there
> for XRD signing.
> 

Agreed

> - I don't think you should have the openid21.provider Rel-type with the
> URI.
> Since you start with an email(-like) identifier, it is clear that you're
> performing discovery on an identifier for a user, not for a host. So you
> should only look for a Link element that has a URITemplate in it. If you
> want to map all users to the same endpoint, just make it a template that
> doesn't actually have any unbound variables in it.
> 

Since the "host-meta" may have other use cases, we cannot just rely on one
link having a URITemplate. I think we need to be explicit here.

> - "openid21.usermeta" should should be something generic like
> "describedby"
>  - as you point out that's the user's _meta data_, not just OpenID stuff
> (although there was some discussion at IIW that "describedby" isn't
> appropriate b/c the email-like identifier isn't technically a URI, and
> URITemplates, and "describedby" are supposed to be for URIs - but I think
> that's a technicality we'll work out).
> 

> - the openid21.local_id being its own Link seems weird to me. Why not
> something like this:
> 
> <Link>
>   <Rel>openid.provider</Rel>
>   <URI>http://openidprovider.com/op</URI>
>   <openid:LocalID xmlns:openid="http://...">some-local-id</openid:LocalID>
> </Link>
> 

Again I think it is better that it remains as separate link. This has more
to do with the design of XRD vis-avis XRDS.

-----

Santosh Rajan
http://santrajan.blogspot.com http://santrajan.blogspot.com 
--

-- 
View this message in context: http://www.nabble.com/OpenID-Discovery-for-Email-like-identifiers---Draft-0.1-tp23832524p23838393.html
Sent from the OpenID - General mailing list archive at Nabble.com.
Peter Williams | 2 Jun 20:51 2009

Re: [OpenID] OpenID Discovery for Email like identifiers - Draft 0.1

I venture that any id is "acceptable" - provided it delivers all the openid-featured properties of URLs.

1. you must be able to type it
2. it must enable names of user to be written in the user's native script
3. there should (only) be feature for permancy and synonyms
4. the name must discover an authoritative XRD (or XRDS) by XRI Resolution or by simple resource location

Anything on top of those 4 constraints is a bonus. E.G. clickpass, google/yahoo UI conventions, myopenid
outsourcing, facebook ispassive. These latter features merely allow vendors to distinguish
themselves from each other. Providing such value add does not interfere with the open systems rules (any
2+ vendors systems will cooperate at the community-agreed minimum level, without requiring vendor
intervention), they are fine. The market will sort out what folks will or will not adopt.

The test of a good id  would be that, if encoded in a URL and when supported by a URL->id gateway resolver (like
HXRIs), the RP conformance suite would not even know that the id might have properties in addition to those
from URLs.

Folks proved that the fantastically complex XRI Resolution can be  reduced to URL resolution, using HXRI
proxies. Similarly, w3c showed that sparql queries can reduce many useful rdf graph searches to a URL. So,
there is little excuse to make exceptions now for jabberids, email ids, or other.

Ideally, the XRI proxy would be the gateway of name resolver gateways ; but that's unlikely to happen. Name
serving is far to much of a hot-topic - given its geopolitical control properties - for there to ever be such
consensus on that. For example, one can give the US a pass concerning its geo-political manipulation of
the DNS, for lots of mostly positive historical reasons. This doesn't mean USG gets a pass in the future though.

________________________________
From: general-bounces <at> openid.net [general-bounces <at> openid.net] On Behalf Of Dirk Balfanz [balfanz <at> google.com]
Sent: Tuesday, June 02, 2009 11:03 AM
To: Santosh Rajan
Cc: general <at> openid.net
Subject: Re: [OpenID] OpenID Discovery for Email like identifiers - Draft 0.1

In general, I don't think you need to "adapt" webfinger. Webfinger gives you everything you need. The
OpenID community just needs to decide whether the email-like identifiers falling out of webfinger are
acceptable OpenIDs.

Couple of specific comments:

- re signatures: I would just use whatever the XRI TC comes up with there for XRD signing.
- I don't think you should have the openid21.provider Rel-type with the URI. Since you start with an
email(-like) identifier, it is clear that you're performing discovery on an identifier for a user, not
for a host. So you should only look for a Link element that has a URITemplate in it. If you want to map all users
to the same endpoint, just make it a template that doesn't actually have any unbound variables in it.
- "openid21.usermeta" should should be something generic like "describedby"  - as you point out that's the
user's _meta data_, not just OpenID stuff (although there was some discussion at IIW that "describedby"
isn't appropriate b/c the email-like identifier isn't technically a URI, and URITemplates, and
"describedby" are supposed to be for URIs - but I think that's a technicality we'll work out).
- the openid21.local_id being its own Link seems weird to me. Why not something like this:

<Link>
  <Rel>openid.provider</Rel>
  <URI>http://openidprovider.com/op</URI>
  <openid:LocalID xmlns:openid="http://...">some-local-id</openid:LocalID>
</Link>

Dirk.

On Tue, Jun 2, 2009 at 6:28 AM, Santosh Rajan <santrajan <at> gmail.com<mailto:santrajan <at> gmail.com>> wrote:

I have posted a draft spec on the wiki to get the ball rolling on this one.
http://wiki.openid.net/OpenID-discovery-for-Email-Like-identifiers OpenID
Discovery for Email like identifiers - Draft 0.1
Lets have some discussion on this in order to add this into the 2.1
proposal.

-----

Santosh Rajan
http://santrajan.blogspot.com http://santrajan.blogspot.com
--
View this message in context: http://www.nabble.com/OpenID-Discovery-for-Email-like-identifiers---Draft-0.1-tp23832524p23832524.html
Sent from the OpenID - General mailing list archive at Nabble.com.

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

Gmane