[WG-UMA] Enterprise questions about UMA

Thomas Hardjono identity at hardjono.net
Fri Jun 1 09:59:03 EDT 2012

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

- Is it conceivable that an external provider could host and operate
an AM on behalf of an Enterprise?



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 :)


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
they will lose control of their customers and "give their
away".  This is because many enterprises believe (correctly) that
main asset is their relationships with their customers and anything
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?


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


WG-UMA mailing list
WG-UMA at kantarainitiative.org

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
Tel:  +49 (0)89/ 322 9986-177 (fixed)
     +49 (0)151/121 68100 (mobile)

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


More information about the WG-UMA mailing list