Dear Colleagues,

Let me introduce myself: my name is Michael Poulin, OASIS Member. I
have certain experience in SOa and Identity Management, theoretical,
architectural and hands-on development. I have just a few comments -
general and particular.

My general comment is this: in the Statement of Purpose, the document says:

"The purpose of the OASIS Identity in the Cloud TC is to collect and
harmonize definitions, terminologies, and vocabulary of Cloud
Computing, and develop profiles of open standards for identity
deployment, provisioning and management... The TC will collect use
cases to help identify gaps in existing Identity Management standards.
The use cases will be used to identify gaps in current standards and
investigate the need for profiles for achieving interoperability
within current standards, with a preference for widely interoperable
and modular methods."

However, I have not found "definitions, terminologies, and vocabulary
of Cloud Computing" defined in the document (such as Actor, Client,
Provider, Function, Resource, and others) but rather an extended set
of use-cases. Also, I have not found any identified "gaps in existing
Identity Management standards" in the document.

If we assume that the real purpose of the this work is a definition of
the most useful or frequently used use-cases, what is the expectation
of the authoring team on how these uses-cases would be used by the
document readers? It is unclear to me from the text provided.

My particular comment relates to "Use Case 12: Consumer Cloud Identity
Management, Single Sign-On (SSO) and Authentication".

I think, it would be beneficial for the document if it were defined
such term as a "service user". Is it an entity that explicitly invokes
the service or is it an end-user who invoked another service and the
current one has been reached just in the "chain of invocations"?

I, personally, have a difficulty to accept the statement saying: "From
a user perspective, Users subscribing to an array of cloud services".
If I am an end-user, I prefer dealing with 1 service for particular
task/need of mine and I do not care and should not care about any
other services that may be involved with the service I communicate to.
If I have another need, I will deal with another service. That is, an
appearance of an "an array of cloud services" I have to subscribe is
justified in this use-case.

Then, if I am an end-user, I do not know much and do not want to know
much about "interoperable identity that would be used to obtain
different services from different providers" but I, indeed , prefer
having one identity for all. At the same time, I'd like to be the
owner of my identity and change it whenever I want. Also, I may prefer
having several identities to use different services from the same or
different providers. Overarching conclusion: if Cloud is a
service-oriented environment, then I, the user, is the Master, i.e.
the more the system restricts my choices, the less I like this system
and,thus, will look up for another one.

Please, consider that the end-user considers simplification to the
service provider the least - this is the difference between
service-oriented and application-oriented environment. Federated
identity standards are good but they may be engaged only upon explicit
permission of the identity owner. By the way, I think there is a typo
in the sentence: "the user already have(has?), helps to attract ..."

On another note, in my 15 years work with services, I have found that
the identity of the end-user is of little interest of independent
services called in the "chain of invocations". In particular, if a
service A faces the end-user with identity EUI and invokes a service
B, the latter is not aware and does not want to be aware about the
end-user with identity EUI because the invocation of the service B was
not accompanied by any trust settlement between the end-user and the
service B (trust is the mandatory pre-condition in the SOA ecosystem
for a service invocation). Instead, the service B is interested in the
identity of its user, i.e. in the identity of the service A. The
interaction between A and B has to be trustful as well as an
interaction between service B and potential service C that B might
invoke in turn. Overall, this is a federation of trust model for
explicitly interacting consumer-services groups. This logical review
is based on the rules that I and my colleagues use for SOA ecosystem -
we call them "The Knight Rules" and they say: 1) a service of my
service is not my service; 2) a consumer of my consumer is not my
consumer; 3) every service is responsible and accountable to its
consumers for everything it provides.

I hope, these notes help you to deliver your work in good state.

Best regards,

• Dr. Michael Poulin