modulair building / connect the *** dots

[Will Fris]

For Modulair Login :

OpenAuth // OpenID ~ Google Is an OpenID provider for instance, but there are many more.

For other systems we need to get their API's

or we should define out own API ( i guess that's what needs to be done for the resource-allocation/-availability stuff ).

An example of an API we could use is identi.ca/status.net's API which is quite identical to twitter's.

Is this API already used on tzmnetwork.com ? Could it provide links to those services ?

Am i stating the obvious/clear stuff here ?

Sure 'd like to hear from y'all :p

[Victor Phelemba]

This was something I envisioned also quite some time ago, ended up 'sleeping on the source'.

A protocol for association to objects at minimum would be helpful.

Synchronized nodes of assets with i18n/localized communications.. like many a linux package manager.

Think pacman/ yum .. a search without the GUI would save hours for teams to sync the media project with there localized assets.

Votes could keep asset cache poisoning/spam down to minimum.

What's working in other chapters is lost in localized media, bringing this up to speed for video/audio would be paramount for the Ling team.

Will post to the wiki with program/progress.

"Will Fris" <imme....@gmail.com> wrote:

>--
>You received this message because you are subscribed to the Google Groups "ZM Global Dev Team" group.
>To post to this group, send email to zm-global...@googlegroups.com.
>To unsubscribe from this group, send email to zm-global-dev-t...@googlegroups.com.
>For more options, visit this group at http://groups.google.com/group/zm-global-dev-team?hl=en.
>

--
Sent from my Android phone with Secure9 Mail. Please excuse my brevity. --

[Chris Boertien]

Both protocols are part of a good modular design, but it's important
not to confuse the two, as they have nothing whatsoever to do with one
another.

OpenID is an authentication protocol. It allows users to authenticate
with their provider, and allows the site operator to not require
performing their own authentication. The site itself gets a token back
from OpenID and then the site can continue onward with a cookie token
to maintain the session.

OAuth is an authorization protocol. It allows a 3rd party website to
access information from the source on behalf of a user. This can allow
for example, a 3rd party site to submit information from the user to
the source site, without the user having to go to the source site
itself. It can also allow the user to access their information from
the source site on the 3rd party site.

For the research that I had done on setting up an integrated
environment that allowed sharing of assets across various websites and
services, OAuth is really worth looking into, but OpenID doesn't
really apply since it is only an authentication protocol, not an
authorisation protocol.

The beauty of OAuth here is that a single centralized service can be
created, and any number of separate websites can easily provide access
to their users to the central data center. And in fact it need not be
centralized, but then you really start getting into some heavy coding,
as I couldn't find any systems that allowed for the many-to-many 3
legged authorization that would be required. Not to mention the system
would have to be automated as no human administrator would have a hope
in hell of maintaining something of that complexity.

[Nick Polimeni]

The convenience sounds good; but what happens to the data if for some reason we no longer have access to our members through a 3rd party? We are not the owners of the data, are we? So what can prevent a third party from withholding the data? Or if some 4th party orders the third party to withhold the data from us?

Nick

[Will Fris]

i guess a local copy could be made

there's probably more data to be stored as well

so some sort of storage for users/clients will come into existence i guess.

[Chris Boertien]

I think you misunderstood the way it works, the 3rd party doesn't have any data, nor does it control data. Instead it is given permission by the central system to request data on behalf of the user. The central system then asks the user if they accept this request, and the information is provided to the 3rd party so it may be displayed to the user.

It's what Facebook, Twitter and Google have been doing for awhile. If some web application is hooked up through Facebook Connect then you can sign-in through facebook. When you do this your bounced off to Facebook and asked if you want to grant permission to the 3rd party site to access some amount of your information, usually stuff like name and email, which automates your registration.

This is how single sign-on works, and is eventually what I would like to build, though I think it really will take at least a handful of software engineers to pull it off.

--
You received this message because you are subscribed to the Google Groups "Global Dev Team" group.

To view this discussion on the web visit https://groups.google.com/d/msg/zm-global-dev-team/-/ZWQyME01dmg5d1FK.

[Nick Polimeni]

Probably did misunderstood, as I got the idea that the information can be lost to us, without us having nothing to say about it!

Thus, I can say, yes, it's a very good tool, and should be added to the list of things to consider.

Which brings me to that... You have many ideas that were discussed with Federico, and other people who started the activity...

Can you give me at least some sketchy list, and I can add it to the wiki so they don't get lost?

Nick