[WG-UMA] How we would handle the Soccer Club sharing issue

Kirk Brown kirk at talkwheel.com
Thu Mar 24 18:15:12 EDT 2011

Sounds interesting.

An ID Provider would really iron out the back channel hacks we had to do.
And even stronger
"nonrepudiation" attempts for collaboration requiring stronger Identity such
as an another security step your
product supplies with CreditCheckID. Of value to Enterprise / eGov scenarios
similar to this one.

Here is a little more challenge on the use case. Actually next week I can
demo it for
you if we want to use my GoToMeeting to share my screen, but:

Youth Soccer League President informs his team managers/coaches about a new
Social Web Service
he can use to organize and communicate with his players and parents called
"ZeroPC". Where they
will find a shared desktop of tools, like a master calendar, document
templates, news and a collab
application called Talkwheel to keep parents and players informed.

( These SaaS services ARE transient. For an hour, a few weeks, a few months.
We build them
     and then tear down and flush the users. Especially when their
subscription expires maybe  )

For social network users, memorizing and managing a password is a hassle. So
it is not
required as they hop around multiple SaaS services like a frog hopping lilly
pads. From
one to the next.

A coach registers with ZeroPC and is given a UID (his email) and a password.
On the desktop
he creates a Group using only the players and parents Name and email
address. Clicks send.

This is what they see in their email:

Message from coachBrown at zerodesktop.com

To access the shared transferable desktop click here:


(sorry not valid URL :D - their product launch is Monday with us. )

They click on the link and magically the shared webtop "desktop" loads in an
opened browser
window.  zeroPC service is running on EC2 cloud.

The team can view common tools and calendars. And maybe some are not
And there is a desktop icon with a big text bubble. They click to open the
Talkwheel app.

On the back plane zeroPC had to send Talkwheel the group Name and the list
of 25 names and
emails through an API that provisioned the users, there one last step before
we grant them access.

( this step could be more efficient and proper )

The first player launches Talkwheel and hits a landing page Welcoming the
user and offers a
video of how to use the app, OR suggests all they have to do is type their
email and "Join"

This they do and we launch the app embedded inside the shared desktop.
Everyone is happy.

If the user is "authorized" by the back channel API calls. Then this landing
page is really a
proxy that ensures the connection is from a known domain with a valid
private Group URI ;
takes the asserted email address and compares it to the entry on file before
enabling a fully
"authenticated" user.

Easy. Lightweight. Scales ....but could be stronger.

On Thu, Mar 24, 2011 at 1:52 PM, Kevin Cox <kevin.cox at edentiti.com> wrote:

> After listening to the discussion this morning I wondered how the approach
> we have adopted would handle the Soccer Club sharing of data.
> A little background. Our company (Edentiti) supplies a verification of
> identity service that enables an individual to "prove" that a person with
> their credentials (name, address, date of birth) exists.  They do this by
> accessing their personal records in other people's databases particularly
> government databases.  These records are made available for other purposes
> through public websites.  For example, it is possible in Australia for
> registered organisations to get access to the Immigration Entry Data Base to
> see if a person has a valid visa to work in the country.  It is possible to
> check with the passport office to see if your passport is due for renewal
> and to make an application for a new one.
> We establish whether a person who makes the various claims is the real
> person with this identity, not by proving it at the time, but by them
> leaving behind electronic markers that can be used to attach them to the
> record.  These are the common things like openids, passwords, voice prints,
> mobile phone numbers, electronic tokens etc.  This combined record becomes
> an electronic ID.
> We are in the process of convincing people that it makes sense for the
> people they deal with to have different sorts of IDs.  So an organisation
> might have an XXXXXID where XXXXX is the name of the organisation.  When a
> person comes to an organisation and they are using their XXXXXID then the
> organisation knows that they have certain sorts of permissions and those
> permissions can vary depending on the role they have within the
> organisation.  So if the person is a customer of bank they have certain
> privileges like only looking at their own records.  If they are a teller in
> the organisation they can view the bank accounts of a customer who has made
> a query.
> How does that handle the Soccer Club problem?
> People in the Soccer Club would be able to obtain a Soccer Club ID from a
> trusted ID supplier.  The person proves to the ID supplier that they are
> entitled to have a Soccer Club ID. This gives them certain privileges in the
> Soccer Club and when they come to the Soccer Club they use their Soccer Club
> ID and the Club - because the person uses a Soccer Club ID knows they can
> give them access.
> How does this idea work on a broader scale.
> The Australian Government has passed legislation called the "National
> Consumer Credit Protection Bill 2009" which requires lenders to ensure that
> they have checked the capability of the lender to repay the loan.  As with
> many laws industry is given a period of grace to work out how to comply with
> the laws and to put in place procedures to show that they comply.  That
> period ends in mid year but the industry has not yet come up with a system
> that enables them to easily and electronically fulfil their obligations.
>  They are under some pressure to do something.
> We are proposing a CreditCheckID approach where an individual obtains a
> CreditCheckID. They use it to get access to their credit obligations with
> credit providers and their income sources and so supply a lender with
> uptodate verified information on which the credit provider can make a
> decision.  The draft of the proposal is attached.
> This fits into the UMA model by the person themselves being the
> authorisation manager because all communication goes via their trusted
> electronic id which they control.  This trusted electronic id has been set
> up by the person.
> Kevin
> --
> 0413961090
> Home +61 2 62410647
> Fax +61 2 6103 0144
> http://www.linkedin.com/in/kevinrosscox
> _______________________________________________
> WG-UMA mailing list
> WG-UMA at kantarainitiative.org
> http://kantarainitiative.org/mailman/listinfo/wg-uma
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://kantarainitiative.org/pipermail/wg-uma/attachments/20110324/7edce600/attachment.html 

More information about the WG-UMA mailing list