Google Withdraws Support for OpenID ... (G) button stops working for claims

[WardCunningham]

If one attempts to claim a site with the (G) button for OpenId authentication then this process fails as follows:

• Google authentication page comes up.
• User agrees to authenticate
• Google quits with 404 explaining that site is not already registered.

Their exact message is:

 OpenID auth request contains an unregistered domain: http://foo.fed.wiki.org

I interpret this to mean that they are only authorizing logins to sites that have already been claimed. This is good for a while but they say that they are withdrawing even this.

https://developers.google.com/accounts/docs/OpenID

This reminds me again why one should not build on other people's services. The (Y) choice seems to still work so those willing to make Yahoo accounts can claim sites with their OpenID.

With Persona facing a similar fate it may be time to write our own login system.

[mkelleyharris]

This reminds me again why one should not build on other people's services. :-) Quite a pattern observation in the age of the cloud and many web services. Maybe like any dependency, the Dependency Inversion principle could be applied. With SFW dependency on an authentication interface, the concrete instances can be swapped out, Of course, I know you know this. Just brainstorming out loud ...

On Sat, May 31, 2014 at 5:51 PM, Ward Cunningham notifications@github.com wrote:

If one attempts to claim a site with the (G) button for OpenId authentication then this process fails as follows:

• Google authentication page comes up.
• User agrees to authenticate
• Google quits with 404 explaining that site is not already registered.

Their exact message is:

OpenID auth request contains an unregistered domain: http://foo.fed.wiki.org

I interpret this to mean that they are only authorizing logins to sites that have already been claimed. This is good for a while but they say that they are withdrawing even this.

https://developers.google.com/accounts/docs/OpenID

This reminds me again why one should not build on other people's services. The (Y) choice seems to still work so those willing to make Yahoo accounts can claim sites with their OpenID.

With Persona facing a similar fate it may be time to write our own login system.

— Reply to this email directly or view it on GitHub https://github.com/WardCunningham/Smallest-Federated-Wiki/issues/415.

[coevolving]

@WardCunningham Over at issue #414, there's a peril at claiming the web site using a Gmail address right after installation on Openshift (e.g. http://fed-coevolving.rhcloud.com/ ) and then setting up the CName and alias (e.g. http://fed.coevolving.com/ ). Mozilla Persona doesn't recognize the Gmail address across both URLs, so that when I try to "Sign in with your Email", I get a response of "Login Failure. It looks as if you are accessing the site using an alternative address. Please check that you are using the correct address to access this site."

I use OpenID quite frequently for logging in, but don't usually use my Gmail address. The first OpenID I used was for http://daviding.wordpress.com , since I have multiple e-mail addresses for different web personas. This has me signed up at http://en.gravatar.com/daviding .

So, is the challenge not with "other people's services" but the implementation? Is the Gravatar approach (supported by Wordpress) a better (or at least alternative) target that e-mail addresses?

[almereyda]

@elf-pavlik, can you comment about Persona's fate @WardCunningham is mentionning above? I explicitly ask you, as you are promoting Persona everywhere possible.

Is it time for the transition to WebID already, @bblfish?

In general, I'm not so inclined in having Y-A-L-S: Yet another login system. In the end, right now, I favour Open ID Connect to anything else. There's also Node modules for both clients and providers.

[paul90]

Over at issue #414, there's a peril at claiming the web site using a Gmail address right after installation on Openshift (e.g. http://fed-coevolving.rhcloud.com/ ) and then setting up the CName and alias (e.g. http://fed.coevolving.com/ ).

This is more an issue with how the return address to be used when signing in with Persona is configured. The value is set when the server is started, so causing problems when multiple routes can be used to reach the server. This is avoided in farm mode, as node bouncy is used, and each access route gets its own configuration.

Is it time for the transition to WebID already, @bblfish?

This is something I was talking about, with Austin, when we added Persona to the node server. In conjunction with WebAccessControl, for those wanting to control access to content. Can that really be a year ago, where does the time go!? Sadly I never got around to writing up my thoughts.

[almereyda]

@paul90 Let's just do it. We have the author of the piece at hands, if something goes wrong or doesn't work.

[bblfish]

The WebID specs are pretty stable now. You can find them here: http://www.w3.org/2005/Incubator/webid/spec/

I have implementations in scala and have previously done some in Java. I am not so sure about the ruby tools. You may want to ask on http://www.w3.org/community/webid/

[almereyda]

Quick via mobile/mail : we'd rather love to go for node. Maybe Ward can have his rewrite there ;) Am 04.06.2014 17:36 schrieb "Henry Story" notifications@github.com:

The WebID specs are pretty stable now. You can find them here: http://www.w3.org/2005/Incubator/webid/spec/

I have implementations in scala and have previously done some in Java. I am not so sure about the ruby tools. You may want to ask on http://www.w3.org/community/webid/

— Reply to this email directly or view it on GitHub https://github.com/WardCunningham/Smallest-Federated-Wiki/issues/415#issuecomment-45106916 .

[elf-pavlik]

from: http://identity.mozilla.com/post/78873831485/transitioning-persona-to-community-ownership

There are no plans to decommission Persona. If it fits your needs, please use it. We will support you.

I see no reason why not to support Mozilla Persona, WebID and OpenID Connect leaving people choice which to use. IMO Persona with its graceful fallback to centralized IdP as minimum requires someone to have email address, while WebID and OpenID Connect require visitor to already have an account at some IdP (not sure here if http://webfist.org/ can help in OpenID Connect case)

When it comes to work on yet another auth, i would like to see first in depth analysis of those three i mention above and clear explanation how it would build on experience with designing/using them!

For WebID please note distinction between WebID and WebID+TLS In http://www.w3.org/2005/Incubator/webid/spec/ you can also find link to notes on Identity Interoperability

some work on WebID for node - https://github.com/magnetik/node-webid

[bblfish]

Aside: if you guys are also thinking of doing a re-write and are even considering other languages, and if node.js is of interest, because then one can develop in the same language on the client and server, then I'd suggest also looking at Scala since with http://www.scala-js.org/ you can then program with a language that has all the advantages and elegeance of Ruby, with additional type safety, ( code that compiles is mostly correct ) and can be run both on the client and the server. Plus you get mega powerful frameworks like playframework.com . And then of course I could work directly with you. :-)

But anyway, this has got nothing to do with WebID authentication, WebAccessControl, etc.. LDP can run on any platform, and the semantic web is programming language agnostic - though having very good multithreading and asynchronous libs is a mega useful for distributed systems.

[elf-pavlik]

One more development I need to investigate further - Identity Credentials & HTTP Signatures Manu Sporny who leads its development participated in earlier days of WebID development and had reasons not to use it in work on Web Payments

[bblfish]

@almereyda concerning Y-A-L-S the advantage of WebID+TLS is that you can in fact make a request over TLS for a X509 certificate when a user clicks a button. If the user does not have one, the Chrome certificate selector won't show up, and so you can switch to the other less secure identity and authentication systems. These can all be tied together in the authorization section of the code. I need to do a demo showing this on https://github.com/read-write-web/rww-play ( you can find good demos on the wiki of how WebAccessControl can work with WebID there ( in the curl demos ) )

[almereyda]

@bblfish There's two things now. As GitHub issues have limited moderation possibilities, I will fork out your complete rewrite topic quite soon and answer to that in a comprehensive manner. Short answer: We're already exploring this issue, but still lack a suitable place for discussion. Time will tell ;) .

There is a nice collection of authentication strategies by a Ruby project. Like databank or remotestorage provide interesting approaches for the storage layer, passport seems to provide something similiar for authentication in Node. There is an old, exhaustive overview of an implementation of WebID in Node available, too.

I'd also be interested in knowing if WebID also means to upgrade our leveldb layer to levelgraph, or something suitable @elf-pavlik, to add some quads for improved overall Semantics.

[elf-pavlik]

very relevant! read, also discussing Mozilla Persona and WebID: http://manu.sporny.org/2014/credential-based-login/

[bblfish]

Yes, @elf-pavlik the main interest is that Persona has died. Otherwise we have 4 short criticisms of WebID and then a long and complex description of something that does not exist, but that when it exists will be done so that Identity Providers have a big advantage. The criticism of WebID is in a few short phrases:

"WebID+TLS, unfortunately, relies on the client-certificate technology built into most browsers which is confusing to non-technologists and puts too much of a burden, such as requiring the use of an RDF TURTLE processor as well as the ability to hook into the TLS stream, onto websites adopting the technology. WebID+TLS also doesn’t do much to protect against pervasive monitoring and tracking of your behavior online by companies that would like to sell that behavior to the highest bidder."

1. Client Side certificates are in most commercial desktop browsers extremely intuitive and easy to use - except Firefox, but that's their problem. On linux everybody copies Firefox. There are some screenshots https://www.w3.org/wiki/Foaf%2Bssl/Clients/CertSelection
2. Nothing in WebID requires Turtle. So that that can't be a major problem. There are Turtle parsers for every language. JSON-LD Parsers could be made available too, but that's not quite a standard yet, and we don't have anything against that. We just wanted to avoid the other criticism that would be leveled against us, and that is that this is too complex to have many parsers. 
3. And the monitoring and tracking issue is complete nonsense. If you identify to a web site with a global identity - whatever it be - a web site can share who did what. They want to use an e-mail, could that not be sold behind your back?
4. That WebID has not evolved: Well it is so simple, there is not much to do in making it simpler. It has evolved as other standards have evolved allowing Web Access Control, Read/Write functionality with LDP, etc...

[WardCunningham]

Federated Wiki's identity needs are modest. The server must know, is this your wiki? If not, you can't write.

Perhaps we can assume that the first person to visit a new wiki is in fact the owner. The server could generate a suitable credential and share it with that person's browser. This completes the "claim" process. Let's call this the zero-steps to claim solution.

The primary advantage of zero-steps is that it just works without any explanation. No entry fields or buttons are required. No identifying information need be offered. No service dependency either.

Server-side plugins could distribute the credential by a variety of means. Maybe the plugin asks for an email address or a smart phone number and uses that for sharing. This begins to feel like login. However it works, it is a feature of the plugin, not the core wiki client or server code. And it is not the first thing you have to do to start using wiki.

[bblfish]

@WardCunningham the advantage of WebID is that you could be more flexible in who has write access. You could:

• allow your friends to write
• allow friends of your friends to write ( foaf )
• allow anyone to write, but have their writes be moderated by your foaf
• and of course this is not limited to foaf, but could be much more flexible such as allowing groups of people you met at a conference, where the conference published the members of the group on their web site to have access

WebID because it ties easily into distributed declarative social networks makes that relatively easy to do. One could of course also use other authentication methods such as OpenID to complement that.

I'll be developing a blogging tool on rww-play to demonstrate that. Then it is quite clear that adding a wiki would be a very useful feature too... I'll keep you posted.

[paul90]

Perhaps we can assume that the first person to visit a new wiki is in fact the owner. The server could generate a suitable credential and share it with that person's browser. This completes the "claim" process. Let's call this the zero-steps to claim solution.

The primary advantage of zero-steps is that it just works without any explanation. No entry fields or buttons are required. No identifying information need be offered. No service dependency either.

Interesting idea, not sure how this fits with the idea of leaving some site unclaimed in a farm. But, maybe adding the role of farm manager with the ability to configure such things. Or how you recover from the loss of the shared credential.

Other than we were discussing how to restrict read access, @bblfish that sounds almost identical to a conversation I was having with @ozten, while we were adding Persona support a year ago.

As @WardCunningham commented at the time, probably the biggest barrier for WebID is the requirement for server certs, especially for the wildcard cert that a farm would require. A great shame that all the noise about the problems with the CA trust model has not really delivered.

Maybe part of the answer with farms is to single sign-on to the farm, so offering a way of removing the need for a wildcard certificate. Or, to switch from using sub-domains to a url structure. But, while ward.fed.wiki.org could easily become fed.wiki.org/ward, what about 623633.ward.fed.wiki.org? Maybe not such a good idea!?

All that aside, we probably need to pull the security out into a module as a first step. There is currently an inbuilt assumption that only the site owner will authenticate, anybody else gets an error message, and that being authenticated which in the current model means being the site owner also means you are authorized to edit.

[WardCunningham]

Let's imagine that a company with LDAP based SSO wants to host a farm for many conversations. Sites could be "born claimed" so that all edits end up in browser local storage until the wiki-plugin-ldap-login creates shares credentials allowing saves to the public site.

[coevolving]

For a novice, there's quite a difference between the C2 wiki and the current instantiation of Federated Wiki.

On the C2 wiki, if I want to contribute, I press the "Edit Text" button, and I'm on my way. Of course, the edits happen on the server, so this is simpler.

If I go to http://sandbox.fed.wiki.org/view/welcome-visitors , I can "Double Click to Edit", which seems to make the changes. As a novice, my assumption is since I'm working in a browser, the changes are saved on the server. (This could be an artifact of the history of browsers before HTML5, but only if I had "saved" the document on my personal computer would I presume that the contents are saved there).

There's further confusion, when -- as a novice -- I then notice at the bottom of the page "OpenID ... Claim" ... and don't know that means. I try my preferred open ID -- a wordpress.com site -- which works. I logout. I try the "G", and login with my Gmail address -- which works. I logout.

Does a solution that "all edits end up in browser local storage until the wiki-plugin-ldap-login creates shares credentials allowing saves to the public site" do the intuitive thing for novices? On the C2 wiki, effort put into writing content is preserved. On the current Federated Wiki, how long does the content stay in my local browser? If I spend 3 hours editing content before logging in, what happens when I return to the site a week later?

One of the fastest ways to turn off a novice will be for him or her to put some work into writing content, and then have it lost. If the web site is explicitly labelled as "Sandbox", a good portion of the user community will understand that Sandboxes are not permanent places to write content. However, when we talk about pages not named "Sandbox", what is the behaviour of least astonishment?

Should the statement on "Welcome Visitors" that says "You will need your own site to participate" be clearer? I'm not the average user, as I already manage web domains, and was able to set up an OpenShift account with the help of many in this community. As I look forward to bringing on a Service Systems Thinking community in a federation, I'm wondering myself about how the learning curve could be eased for them.

[coevolving]

On the Hangout yesterday, we discussed the challenge with using OpenID, with Google's support waning.

Of all of the choices of OpenID providers at http://openid.net/get-an-openid/ , I had stated my preference towards using Wordpress as my OpenID provider, as they have a strong participation in the open source community, as well as a commercial platform -- so their longevity is promising.

During an installation of a Wordpress blog last night (using a CPanel installer), I noticed a checkbox option for "Clef". Never having seen that, I went over to https://getclef.com/ .

I'm not currently inclined towards using Clef, at the moment. I did stop to wonder about the progressiveness of the Wordpress community, as Clef is showing up there first.

For novices coming onto Federated Wiki for the first time, perhaps is Google isn't supporting OpenID, it may be better to support Wordpress as a provider. It's free to sign up for Wordpress, and I don't see any indication that they're going to drop support soon.

[almereyda]

There is another Web Identity Proposal, interestingly based on Telehash, that derives from the Web Payments Community Group and is called Identity Credentials.

[donpdonp]

The minimal implementation I see is, on page load, check for an auth token for this federated wiki. If it exists, check the request headers for a matching cookie. If match, the visitor is the owner, otherwise visitor is a guest. If no auth token is recorded for this wiki, add a cookie with the token to the response.

[almereyda]

You might enjoy the read of @bblfish's interview especially regarding philosophical implications of a federated web.

[WardCunningham]

I've now discussed simplification with @donpdonp at Open-Source Bridge, explored IndyAuth with @aaronpk at Indie Web Camp, and read the @bblfish interview and related posts regarding WebID. I'm convinced we all agree what forces are in play.

However, our goal is much more to innovate as a creative space than to demonstrate a web of trust. As such, we moved login from the header to the footer. Now we should bury it down in some profile pages which our authors may or may not choose to use. This attitude was expressed early in the project history as have fun first. We need more of that.

http://ward.fed.wiki.org/have-fun-first.html

[WardCunningham]

I've revived my YAHOO account and used it to claim using the (Y) option. This is just me hanging on to old code rather than investing the effort for a permanent fix. When the big fix happens, I'll have one more test datapoint for automatic conversions.

[mkelleyharris]

I'd welcome some hints on how to login to my account: http://kelley.fed.wiki.org/view/welcome-visitors, to add content. I see this when I log on with Google (As expected from this thread. Page originally claimed with Google.): "OpenID 2.0 for Google Accounts has gone away"

Then I tried my Yahoo account, and got: "This is not your wiki"

Thank you.