[WG-UMA] Enterprise questions about UMA

Kevin Cox kevin.cox at edentiti.com
Fri Jun 1 13:52:38 EDT 2012

If we pass responsibility of personal data to a third party UMA does not
scale because the number of legal agreements is of order N squared where N
is the number of entities holding personal data.  I am very familiar with
the Identity Provider problem where we  verify the identity of a person by
accessing personal data held on government and non government databases.

What the Australian government has found is that if they allow a third
party to act on behalf of an individual then the law has to be changed.
 The changes have to be similar to the laws required to allow third parties
to supply credit ratings.

If however the individual is their own Identity Provider then there few, if
any, changes to laws. In practice the underlying systems may look similar,
and even be the same, but underneath the supplier of the Identity Provider
software never acts on behalf of a legal entity.

Obtaining personal data for verification is an example of access to
personal data and the systems will not scale unless the legally responsible
party manages the data and access. The reason is that there will have to be
laws established for all the different types of data and what a third party
may or may not do with the data.  The government is trying to set up a
national electronic health system and allowing third parties to act on
behalf of people. They have spent years trying to define the system and
frame and create laws to make it happen for health data.  They will get
something going but it is not a scalable process and is going to be a very
inefficient cumbersome system.

What I am trying to say is that software systems need to be constructed so
that the legally responsible entities manage access to data and never pass
responsibility to a third party.

In other words the Authorisation Manager can be third party software but it
should never take on legal responsibility.  This puts constraints on how
User Managed Access operates - but the constraints make the systems
simpler.  If we put the constraint on the system so that all data about a
legal entity must pass through the legal entity then the legal entity can
always take responsibility.

What does this mean in practice.  It means that if we want to pass data
about a person from organisation A to organisation B then the data is
passed from organisation A to the person then passed to organisation B.  If
we construct our systems so that this occurs then the legal issues "go
away" because there is an agreement between A and the person and a separate
agreement between B and the person and there does not have to be an
agreement between A and B.

This approach is scalable because the number of agreements necessary if we
allow A to pass a persons data directly to B is of order N squared where N
is the number of entities.  If data is always passed via the person then
the number of agreements is of order N and that agreement is established
when the data is first stored.

We make this happen in the case of verification of identity by making each
legal entity their own identity provider and hence the data always passes
by them.  I believe the same holds for all other cases of movement of
entity data and that is how we plan to implement user managed access for
such systems as "Proof of Income",  "Proof of Credentials", "Positive
Credit ratings", and "EHealth".

An interesting point is that the model also works for non-legal entities
such as motor cars.  The data about a car always passes via the car and
hence via the legal entity that owns the car at the time.

What it also means is that if an organisation has a credential to identify
a person then that credential never has to be used by any other
organisation.  This really protects privacy.

It also means that we do not have define standards for the meaning of data
but can let standards arise naturally and through the use of the system.


On Fri, Jun 1, 2012 at 11:59 PM, Thomas Hardjono <identity at hardjono.net>wrote:

> Thanks Kevin and Mario,
> For what it’s worth, perhaps it is useful to distinguish between two
> sets of Enterprise users:
> (a) Employees: First, there is the employees, and most likely UMA/UME
> will be used by them to control internal resources (eg. files etc).
> Many Enterprise are looking closely at the web-API model seeing that
> it can scale well and seeing that it lends itself to be “cloudified”.
> Here the Enterprise will want to operate their own AM.
> (b) Customers: Second, there are the customers who have accounts and
> data held by the Enterprise (eg. think 401K or Retirement accounts at
> Financial institutions). These users/customers would like to control
> their data items from outside the Enterprise. Depending on the
> Enterprise policy, it may partner with an external IdP and AM in order
> to facilitate these user-customers (e.g. customers transferring their
> accounts from a different financial institution).
> For the Enterprise it make sense to build a common infrastructure that
> can serve both sets of users in (a) and (b) [even though IP and HTTP
> traffic maybe separated physically, eg. via VLANs]. In fact, the
> Enterprise may even run separate clouds (private or hybrid) to
> firewall these two groups of users.
> ps. there might be a third type of customer/user, namely the
> corporate-customer where a small number of persons have access to
> corporate-accounts held at the financial institution.
> Some interesting models:
> - For customer/users (non-employees) it would interesting if an
> Enterprise-AM could somehow “partner” with an external Provider-AM, so
> that the Enterprise-AM will accept AAT and RPT tokens issued by a
> Provider-AM.
> - Is it conceivable that an external provider could host and operate
> an AM on behalf of an Enterprise?
> /thomas/
> ---------------------------------------------
> From: wg-uma-bounces at kantarainitiative.org
> [mailto:wg-uma-bounces at kantarainitiative.org] On Behalf Of Kevin Cox
> Sent: Thursday, May 31, 2012 5:37 PM
> To: Mario Hoffmann
> Subject: Re: [WG-UMA] Enterprise questions about UMA
> Mario this is very helpful.
> I have given short comments on your answers to questions inline below
> and started to give my answers to the questions.
> To answer your questions:
> Yes, from my point of view, a user in UMA can be an enterprise (or
> let's say the people in charge), indeed.
> KC: A user is an entity that can take on responsibility for data
> What commercially sensitive data you are thinking of? Not necessarily
> all data needs to be under costumers' control. You might define fine
> grained policies in the AM distinguishing data customers can change
> and can not.
> KC: To many organisations the fact that an individual is a customer of
> theirs is commercially sensitive.  The amount of money a customer pays
> for a service is very commercially sensitive.  It is not just money
> but it what an organisation knows about you that takes on value.  For
> example, google and facebook get their advertising power from the fact
> they can target ads.  Information is valuable not just because it an
> organisation can charge for it.
> Note: Enterprises all around the world tend to outsource eMail, CRM,
> ERP, etc. to Cloud service providers. So, what exactly do you mean
> with "lose control of its own information systems"? ;)
> KC: This is related to the first answer.  You will find that when an
> organisation uses a third party provider they put stringent conditions
> on what happens with that data and have been reluctant to use cloud
> service providers.  For example I would bet that FaceBook does not use
> google mail internally.  If they are not the access/manager they will
> not do it and hence they do not like the idea of a cloud service being
> an access/manager because they then believe they have lost control of
> their customer information systems.
> Liability is a good question! Is Sony for example liable for the
> misuse of the credit card information they lost last year (even
> without the feature customers managing data about themselves)? ...
> Don't know? Would this change if they had?
> KC: This is at the heart of many problems because third party
> liability in most cases cannot be taken or accepted.  For example a
> cloud based identity provider cannot take on liability for false
> identities otherwise they would go broke.  What they do is to provide
> a service but do not take on the liability for  the actions that
> happen when false or stolen identities cause loss.  Sony should be
> liable for the loss of credit card information but you will find that
> provided they followed the rules to be taken for the storage of credit
> card information then they will be OK.  It is the same problem with
> the misuse of any technology.  Is the supplier of the gun responsible
> for the actions of the person who murders someone with the gun?
> KC: This is particularly pertinent to the business of third party
> Identity Providers.  If a third party Identity Provider will not take
> on responsibility for the actions of the person being identified why
> bother with using them.  If a third party AM will not take on
> responsibility for how data is accessed why use them?  This is why we
> have come to the conclusion that we are in the business of supplying
> tools to legal entities who are responsible for their actions and not
> in the business of being an Identity Provider or AM.  Once you start
> thinking that way it becomes obvious that the most efficient system is
> the one where the legal entity that takes responsibility is the their
> own Identity Provider and their own A/M
> Additional questions:
> Well, you never know 100% who is managing the data at the frontend. It
> highly depends on your authentication machanisms; from OpenID (free,
> but absolutely no validity) to fully fletched PKI/Smartcard solutions
> (fortune, but very high validity) a lot of different solutions are
> available. It simply depends on the security level that you need to
> reach in your particular case.
> KC: It is not the particular authentication mechanism that matters.
>  It is who takes responsibility for the authentication used.  In
> practice this can only be the legal entity.  Again why we have come to
> the conclusion that it is best for the legal entity to decide the
> authentication method in consultation with the party with whom they
> are authenticating.  Again in practice it is a two way authentication
> process that should be agreed between the two parties interacting.
> KC: This is a particular problem for governments and is why they want
> to have national id credentials.  Unfortunately any credential is
> vulnerable once it is used across multiple organisations.  Hence again
> our conclusion that if a credential is used for authentication of
> identity it should only be used with one organisation.
> Hope this helps :)
> Cheers
> Mario
> Am 31.05.2012 19:08, schrieb Kevin Cox:
> The biggest problem we have in trying to get organisations to permit
> users to be able to access data they hold is that enterprises think
> that
> they will lose control of their customers and "give their
> relationships
> away".  This is because many enterprises believe (correctly) that
> their
> main asset is their relationships with their customers and anything
> that
> means they might lose their customers to competitors is treated with
> great suspicion.
> The following questions relate to that barrier.
> Can a User in UMA be an enterprise?
> If individuals can manage and access data held by an enterprise won't
> commercially sensitive data be passed to competitors?
> Won't an enterprise lose control of its own information systems if
> others manage access to data held by the enterprise?
> Is the enterprise liable if an individual, when managing data about
> themselves held by the enterprise, suffers a financial loss?
> Kevin
> --
> 0413961090
> Home +61 2 62410647
> Skype cscoxk or +61 2 61003884
> 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
> --
> Mario Hoffmann (Dipl.-Inform.)
> Head of Department "Secure Services & Quality Testing"
> Fraunhofer Research Institution AISEC
> Parkring 4, 85748 Garching near Munich (Germany)
> WWW:  http://www.aisec.fraunhofer.de
>      http://www.cloud-competence.center.com
> Tel:  +49 (0)89/ 322 9986-177 (fixed)
>      +49 (0)151/121 68100 (mobile)
> --
> 0413961090
> Home +61 2 62410647
> Skype cscoxk or +61 2 61003884
> Fax +61 2 6103 0144
> http://www.linkedin.com/in/kevinrosscox

Home +61 2 62410647
Skype cscoxk or +61 2 61003884
Fax +61 2 6103 0144

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://kantarainitiative.org/pipermail/wg-uma/attachments/20120602/4c642c93/attachment-0001.html 

More information about the WG-UMA mailing list