The SSO app

I'm not well oriented to this specific effort but I'll share related thoughts.

Secure, unique, persistent digital agent identities are certainly a key personal resource.

In theory, it's fine to allow each agent identity to use Single Sign-On/SSO to access a completely open system of basic apps. On the other hand, it could also be fine (ultimately) to require no sign-on at all to access basic tools which are potentially useful for all humans.

What's important to me is community. Please enable each community to require community-specific sign-on for agents who have specific *roles* in the community.

Note that potential roles include concepts such as guest, member, or any functional posts or "positions".

With that in mind: I think it'd ultimately be best for an identity-generating function and a sign-on function to be separately available apps. That way, even if agents only need to sign-on once (if at all) to use a system of apps, each community will be able to create its own participation standards, and its own list(s) of participants.

Note: I acknowledge that some people might prefer for everyone to use a single global identity (and username) for all online communities and activities which they participate in. However that's neither necessary nor desirable from my perspective, for many reasons.

Does this make sense? Questions or comments welcome.

(Note: I address related subjects in a short section of Peer-to-Peer Digital Networking; however, that section needs updates.)

it's fine to allow each agent identity to use Single Sign-On/SSO

What's an agent ?

What's important to me is community. Please enable each community to require community-specific sign-on for agents who have specific roles in the community.

I really don't get the community part. I don't get why SSO is not in accordance with community ? I mean, I am completly lost, I really don't see your point here (it could be my english). Could you try to explain like I was 8 ? :D

However that's neither necessary nor desirable from my perspective, for many reasons.

What do you propose then ?

What's an agent ?

Lynn answered that effectively for most purposes above. I do have a more technical and detailed definition which can distinguish persons from agents when potentially necessary, IMO, in socially complex contexts. However, that definition probably isn't necessary-- nor even useful!-- for most currently active communities.

What do you propose then ?

I made a suggestion above:

Please enable each community to require community-specific sign-on for agents who have specific roles in the community.

Why? Among other reasons, because some people may want or need to participate in specific communities via pseudonyms. (For activists and people in war zones, this can be a matter of life and death.)

Now, I must acknowledge that this is a complex topic which I haven't been able to fully address here. Also, I certainly definitely don't expect an initial Open App Ecosystem to incorporate all of the features which I consider to be deeply desirable for the development of global peer-to-peer networking. So, I do have a further suggestion which will hopefully seem reasonably simple and practical:

(Possibly) require all systemic apps to use SSO, but do NOT require them to ONLY use SSO.

That suggestion could address potential social complexities. It could also reduce the dependency of the system upon an SSO specification or any specific SSO app.

I'd appreciate questions or comments on that suggestion.

Yes, we are in loose contact with Roland Alton from Fairkom via Gualter and the Transition Netzwerk connection, and their Fairlogin idea is known to us since we explore the subject of SSO at Ecobytes. I have also watched the Wekan card and noticed that LemonLDAP has been replaced by Keycloak.

We've had similar changes in our mindset. Initially trying to build an OpenLDAP-based interface in Drupal and using this connection as an Identity and OpenID Connect provider, I had also proposed LemonLDAP back then, which was rejected for its Perl sources and financing by the French government.

Then we discussed this further in Transformap and I ended up with these links without issue, but in the #transformap-development:matrix.allmende.io chatlog:

• http://blog.keycloak.org/2015/04/running-keycloak-cluster-with-docker.html
• http://rhelblog.redhat.com/2016/03/22/red-hat-federation-story-ipsilon-keycloak-a-clash-of-the-titans/
• http://rhelblog.redhat.com/2016/04/26/why-use-sssd-instead-of-a-direct-ldap-configuration-for-applications/
• https://keycloak.gitbooks.io/server-adminstration-guide/content/topics/user-federation/sssd.html
• https://keycloak.gitbooks.io/securing-client-applications-guide/content/topics/oidc/javascript-adapter.html
  • https://github.com/keycloak/keycloak-js-bower
• https://keycloak.gitbooks.io/securing-client-applications-guide/content/topics/oidc/nodejs-adapter.html
  • https://github.com/keycloak/keycloak-nodejs-connect
• https://github.com/keycloak/keycloak-nodejs-auth-utils
• http://blog.keycloak.org/2015/08/improved-ldap-integration-with-keycloak.html
• http://keycloak-user.88327.x6.nabble.com/keycloak-user-Create-user-from-keycloak-UI-with-FreeIPA-backend-td1653.html

I am choosing the non-LDAP integration with provisioning of users in FreeIPA, as they also offer PAM and SSH management, next to a DNS server.
So before all of this, I need to set up FreeIPA in a High Availability Scenario (for two DNSes) and then plug Keycloak for OAuth2. I had been looking at Project Ipsilon before, but the blog post linked above convices me to stick with Keycloak instead.

I think it is fair to propose Ecobytes as an infrastructure partner for this endeveaour, yet @elfpavlik used to remind us of alternative approaches to distributed Identity, which is the overarching question at hands, such as WebID, IndieAuth, IndieCert (?), Web Credentials and the likes. Was there already a discussion documented somewhere I didn't look yet that concluded with the choice of OpenID Connect as an answer to this problematic? I am also wondering why we are not working together with Fairkom on this issue, yet. There have been so many contacts in so many contexts already, that the overlap in interest is hard to deny. And Roland is even explicitly mentioned few lines above the excerpted chat.

Then also know that the Matrix.org ecosystem is also providing a new Identity scheme, mediated by their 3rd party identity directory service, which can link like phone numbers, etc. to usernames.

That we want to be able to use services anonymously and without login, that goes without saying.

Re. Ecobytes, it is this, no? https://ecobytes.net/

@jonrichter I apologize for being out of touch, but as you are proposing them as a partner, could you give more information for people? Thanks!

@jonrichter thanks much for plugging in here, great to hear of your TransforMap research! To fill in between the blanks, we got @funkycram into a Telegram chat that Roland is in, where we have discussed SSO before, so that they could chat directly. Roland earlier gave the update that I copied above, but since then has not replied to Marc's questions in Telegram.

Re. alternative approaches, I think that is a very valid question. My understanding is that the ones I know of - Solid (@elfpavlik has been pretty involved there), Secure Scuttlebutt (@bobhaugen and @ivan116 have some involvement there) - aren't ready yet for prime time. My understanding is 2rd or 3rd hand, I'm sure others could comment more productively.

I should say that personally I am not technically qualified to figure out the best method, I defer to others to connect with Marc here on the topic. It sounds like there is a lot more going on than I knew about, which is nice to hear.

It also might be worth saying, I'm not sure how to balance thorough research and possibly organizing a joint effort, with a desire to move forward and have something that can be used. @funkycram and others, what do you think?

It sounds like there is a lot more going on than I knew about, which is nice to hear.

Hell yeah, we can't even imagine what's going on. That's why we need this open app ecosystem, to connect people with the same objectives ! :D

Hi, can you share a link to that Telegram chat so I can see what they already talked about?

Please don't get me wrong, I am quite sure OpenID Connect is the "most simple" and best supported way to go for now, but I'd like to have the others on the screen, especially for their reasons to implement another thing extra to what there is already.

Ecobytes is an association which works not for-profit. We are creating a community-led infrastructure, similar to what community-supported agriculture does. We also develop and provide the infrastructure for Transformaps and also for the German CSA network, Research & Degrowth and few smaller initiatives.

Currently a focus is to investigate the idea of a computational commons, an infrastructure and development environment that is free to use for end-users. allmende.io is a start in this direction, but an isp.coop or a federated commons cloud is yet to come.

@jonrichter Here is info: https://telegram.org/faq#q-what-are-usernames-how-do-i-get-one

First you have to join Telegram. Then I will invite you to the group. (There's probably a link, but this will be easier.) Or if you have already joined, let me know your id, because I didn't find it.

Why do you use a telegram chat (which close and propriatary) more than a riot or rocket chat ?

Why do you use a telegram chat (which close and propriatary) more than a riot or rocket chat ?

This is a decision of the FairCoop community, where this other chat grew out of.

What's an agent ?

An agent is a person or an organization (formal or informal). (This is from ValueFlows vocabulary, but also other semantic web vocabularies.)

Thanks very much @jonrichter for all these details and links.
I sadly don't have enough time to answer to all your comments, but if you want we can have a visio call ? For the moment, I have configured Keycloak on an Ubuntu server and I'm working to add the possibility for open apps to connect threw it, when possible via OpenId Connect (depending of what's available on the applications).

@gregorycassel

Please enable each community to require community-specific sign-on for agents who have specific roles in the community.

I'm not sure this is really an issue, we can't in fact require anything, and people can create multiple signons and/or multiple identities as agents as they wish.

Note also that a useful thing to think about in modeling agents is that a person (an agent) may have multiple logon credentials. So an agent does not equal a user, and imo should be separated in the underlying model. The user is really just logon credentials related to one or more software systems. That might help speak to the edge cases that you are talking about where more security is required. Or not, maybe a different agent is also required as a persona. But the model won't know or care about that, people will just do it themselves.

Also we need to distinguish between authentication (SSO is for that) and authorization, which is where community specific permissions come in, and I think that will be handled by each app.

(Possibly) require all systemic apps to use SSO, but do NOT require them to ONLY use SSO.

We can't "require" the "only" part anyhow, especially for existing apps.

I think we should define things that an app can do to become a functioning part of the ecosystem, but not get too crazy about requirements until we start to have some things that can work together, and can think about it more concretely.

@lynnfoster , you (and perhaps the rest of VF too) are using the term "agent" a bit differently than I do. I directly distinguish between persons (human individuals) and agents. I think that that's deeply important, but it's probably not important in the context of this current OAE activity. (So I'm not planning to argue about it, and especially not in this topic.)

You seem to be using the term "user" in almost the same way that I use "identity". Well, I'd obviously agree that each person should be able to control multiple users/log-on credentials/ identities.

I'm not sure this is really an issue, we can't in fact require anything, and people can create multiple signons and/or multiple identities as agents as they wish.

Okay, that's fine IMO as long as people can freely manage multiple identities via the same email address. It's not the way that I'd factored the design challenge, but it could work out fine.

We can't "require" the "only" part anyhow, especially for existing apps.

I don't understand this bit. Wouldn't you agree that OAE needs to develop a standard which includes some requirements and recommendations for each OAE app?

I certainly think that OAE can and should create requirements for a specific app to directly wear an OAE label, or to be listed in an official OAE directory. If existing apps don't meet those requirements, fine! They can either adapt to meet those requirements or not; their (teams') choice.

Anyway, I think it'd be unwise for the system to explicitly or implicitly depend upon a specific SSO app. (For example, the system could implicitly depend on a specific SSO app if the system is technically based on the use of that app.)

I also think that it could be unwise for the system to depend upon using a specific SSO specification (or API). However, I think that such a dependency would be fine if (and only if) the specification allowed users to manage multiple identities via the same email address.

, you (and perhaps the rest of VF too) are using the term "agent" a bit differently than I do. I directly distinguish between persons (human individuals) and agents.

We may actually agree. For us, agent is an object that has agency in an economic network. It might represent a person or an organization or possible a bot, although we haven't gotten into that too much.

An individual human could have more than one agent representing themselves in different contexts. That poses difficulties of trust, though, if the same individual represents themselves differently in the same context, possibly for evil purposes.

About requirements to be an OAE app: I lean toward minimal requirements: use a shared vocabulary, or a vocabulary that is translatable to a shared vocabulary, and use shared protocols.

For an app that I would use or would want an organization that I am part of to use, I also want it to be open source. If we are to collaborate as app creators, I would also want some agreement on values and goals.

But I'd like the minimal requirements to be more like the Internet than a private consortium.

All open to discussion and persuasion. I can go along with a lot of variations on all of the above.

(Possibly) require all systemic apps to use SSO, but do NOT require them to ONLY use SSO.

I think it will be designed this way.

you (and perhaps the rest of VF too) are using the term "agent" a bit differently than I do. I directly distinguish between persons (human individuals) and agents. (So I'm not planning to argue about it, and especially not in this topic.)

Yes, that is the VF definition, as well as foaf. So I guess we could argue that in another place another time.... :)

We can't "require" the "only" part anyhow, especially for existing apps.

I don't understand this bit. Wouldn't you agree that OAE needs to develop a standard which includes some requirements and recommendations for each OAE app?

Yes I agree that OAE needs to have some requirements for apps to participate. I was just saying that if you are an existing app with its own existing login, we shouldn't (imo) require you to eliminate your existing login in addition to supporting an OAE SSO. Others may disagree on strictness, I don't know, but to me supporting the SSO is enough to make you a functioning part of the ecosystem.

I see Lynn and I crisscrossed in the ether and did not read each other's messages until they landed here. We're discussing whether we disagree...

minor edit: i technically should've written "(Possibly) require all systemic apps to be compatible with an SSO specification, but do NOT require them to ONLY allow sign-on through that specification"

Realistically, what signon methods are offered will be up to the software that the SSO signs onto. For example, in the Mutual Aid Network, where they have a combination of a Hamlet-based mutual credit system and a Wezer-based social-economic-network system, both of those systems will need to support the SSO app if they want to use it. And since all of the participants already have "legacy" user login credentials, they might just keep those alive for the time being too, but it's up to them.

Realistically, what signon methods are offered will be up to the software that the SSO signs onto.

That makes sense to me. I'm just trying proactively (and perhaps unnecessarily) to guard against the possibility of OAE becoming too strictly defined and interdependent of a system.

Let me know if you smell anybody doing that. I haven't seen it yet.

Although I know there was a big argument in the CTA about whether open source should be required or not...and I came down on the required side...so I guess it depends on the requirement.

For OAE, as I have repeatedly said, I like shared vocabulary(s) and protocol(s) and minimal other rules, and even those, with translators and adapters. I would still require open source for anything I or any community I am part of want to use, but that doesn't mean that some proprietary software couldn't obey the vocab and protocol and use some of the open apps, unless we want to disallow that in some way. Which could be done by choice of OS license, which I might leave to the app creators.

For @funkycram the best thing would be to centralized all the things we want concerning this SSO (cause he can't read all the posts). Maybe creating a collaborative document about this subject is the best thing to do.

So if you want your idea to be in the SSO, you can put it here : https://docs.google.com/document/d/1FIhAxFTAovlgmow047aw_oROKPNN6CyAG0Dqt2pDSU4/edit?usp=sharing

I would still require open source for anything I or any community I am part of want to use, but that doesn't mean that some proprietary software couldn't obey the vocab and protocol and use some of the open apps, unless we want to disallow that in some way.

As mentioned elsewhere in this group, I personally prefer the less restrictive open licenses including MIT. (And I desire communities which create their own specific restrictions, according to internal preferences.)

I'm good with any license that lets the open apps work together without too much friction.

I'm good with every kind of licenses, like said @jimwhitescarver , he made a extension for slack, even if he disagree with their politic.

I will personally work with open source software, but anyone is free to plug other kind of software.

How do I join the Wekan card? Why wekan rather than gitlab? can we integrate wekan with other tools via api/webhooks/events? That would be cool.

I have been considering support of decentralized identities openid/oauth2, JabberID, WebID over SAML. Is saml the expedient way to go? I can commit some effort in any case and hopefully synergise with the BYOid cross community project I am a leader of.

I'm installing http://www.keycloak.org, as http://fair.coop/ are doing.
It's an identity provider and can accept OpenID Connect and SAML protocols, which are the 2 most used. OpenID Connect is the most recent (successor to openid) and might be used more and more in the future as it is well design for mobile terminals and more simple than SAML

Never used gitlab so I can"t tell :D

Wekan is to manage actions and do this pretty good. If gitlab can do the same and do it better, I'm good to go there.

in the AEO - SSO / Identity app discussions at OPEN 2017 a group of developers suggested that:

• Picking a standard which is / can be used by other groups / co-ops would be the best way to go i.e. a "co-op / commons passport" - which you might pay for but could use in lots of co-op / commons places
• Ultimately we are looking for "a standard way to log in to any co-operative platform or site" and as such if Enspiral forced Loomio to use a specific standard that would help a lot by adding significant weight
• Blockchain based cryptographic keys such as keybase.io might be an option (NB I am not explicitly promoting that - there was much agreement that SSO should be blockchain agnostic)
• systems which don't use email addresses and passwords are more future proof e.g. using your face as your key is a good idea
• webid.info is another option
• uport is another

I hope some of that helps!?

using your face as your key is a good idea

Is the technology available ? :D