[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Comments on IDCloud Use Cases from Dr. Michael Poulin
Members of the IDCloud TC, I am submitting these comments on behalf of Dr. Michael Poulin, individual member of OASIS. Dr. Poulin was unable to subscribe to the comments mailing list through his Yahoo email, so until we get him added manually, I have offered to forward his feedback to the list myself. Please include Dr. Poulin in any replies. Best regards, /chet --- Comments from Dr. Poulin --- 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 -- /chet ---------------- Chet Ensign Director of Standards Development and TC Administration OASIS: Advancing open standards for the information society http://www.oasis-open.org Primary: +1 973-378-3472 Mobile: +1 201-341-1393 Follow OASIS on: LinkedIn: http://linkd.in/OASISopen Twitter: http://twitter.com/OASISopen Facebook: http://facebook.com/oasis.open
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]