[WG-UMA] How we would handle the Soccer Club sharing issue
kevin.cox at edentiti.com
Sun Mar 27 14:23:02 EDT 2011
Yes well summarised.
In UMA each ID would correspond to a dedicated AM. That is, for the mapping
to be complete there would be an AM for soccerIDs, an AM for creditIDs,
etc. This has the advantage of helping stop leakage from one part of a
person's electronic life to another.
On Mon, Mar 28, 2011 at 1:00 AM, Eve Maler <eve at xmlgrrl.com> wrote:
> Some comparative observations:
> It seems like the soccer ID is roughly equivalent to winning an
> authorization scope in UMA by having provided the requisite claims, in that
> it's not specific to any one requesting party, so more than one can be
> granted that scope. However, whereas a soccer ID (so-called) is very
> purpose-specific in its labeling, a real scope would likely have a label
> that reflects generic "read access" to an authz-user-specific "resource ID",
> and it would be bound to the requesting party's unique token at that AM. I
> think UMA and edentiti share the property of scalability, though UMA gets it
> through some AM-magic handwaving at the moment... E.g., if a claim's
> validity period expires, the AM has a way of barring access until it's
> It also seems a bit similar to a classic role or entitlement in an
> enterprise, where now that you've been assigned that role by some internal
> process, there is a lifecycle that the assigner has to go through to ensure
> that the assignee still deserves it (access recertification etc.).
> On Mar 27, 2011, at 2:48 AM, Kevin Cox wrote:
> Having gone through your description here is how our approach varies. While
> it might appear the same outcome the variation makes the approach more
> scalable and we believe more private.
> In your scenario the coach sets up a group. People then come and join.
> What we do is to define the characteristics of the people who can get a
> SoccerID. People then prove they have those characteristics and they join.
> This turns out to be scalable and it keeps the end users in control.
> On Fri, Mar 25, 2011 at 9:15 AM, Kirk Brown <kirk at talkwheel.com> wrote:
>> 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.
>>> Home +61 2 62410647
>>> Fax +61 2 6103 0144
>>> WG-UMA mailing list
>>> WG-UMA at kantarainitiative.org
> Home +61 2 62410647
> Fax +61 2 6103 0144
> WG-UMA mailing list
> WG-UMA at kantarainitiative.org
> Eve Maler http://www.xmlgrrl.com/blog
> +1 425 345 6756 http://www.twitter.com/xmlgrrl
Home +61 2 62410647
Fax +61 2 6103 0144
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the WG-UMA