[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [oasis-charter-discuss] Proposed Charter for Cloud Authorization (CloudAuthZ) TC
Chet, Cloud computing is one of the next "big growth" areas for standards.Other SDOs are aware of that potential so there will be a lot of competition for cloud standards work.
That competition means that OASIS needs to put its best foot forward to attract new members interested in cloud standards.
I have pointed out below some areas where the proposed charter for this TC isn't putting the "best foot forward" for OASIS. Where possible I have included suggestions that could improve it.
On 10/03/2012 02:21 PM, Chet Ensign wrote:
Cloud Computing is gaining traction in the industry. Cloud Providers are facing challenges from the lack of standardized profiles for authorization and entitlements . In Cloud Computing Systems, resources such as bandwidth and memory are constrained. There are use cases where the access policy enforcement of a cloud resource needs to be performed as close to the consumer as possible. This requires availability of attributes including contextual attributes. Additionally, since the computing resources are limited, there are use cases where there is a need for the Policy Enforcement Point to obtain the contextual entitlements (the consumer has) with one call, rather than perform a large number of calls to the authorization set up as seen in the classic enforcement model.
I read the problem statement as:1) lack of standardized profiles (if so, what are the standards we lack profiles of?)
2) bandwidth and memory constrained (are these the use cases for access policy enforcement close to the consumer?)
3) use cases where access policy enforcement close to the consumer (and those use cases are?)
4) consumer (I get the sense the definition of consumer varies in the charter but cannot distinguish one from the other)
5) contextual attributes, Policy Enforcement Point, contextual entitlements Is this common terminology? I ask because: "contextual entitlements" - 640 "hits""Policy Enforcement Point" - 141,000 "hits" (apparently from XACML, but note the usage varies into other CS areas, like LDAP and RFC 2753 use this phrase as well.
"contextual attributes" - 18,100 "hits" and the meaning is all over the place. (If you are interested I can do a survey and map of them.)
6) classic enforcement model? (earlier said there wasn't one, now there is a classic one?)
Problem: No CTO could read that paragraph cold and have any interest in the TC. I rather doubt they could determine what it was meant to do, other than something with the cloud and that it involves authorization. That's not much.
Fixable but really needs to happen among the proposers before this gets broadcast to a broader audience.
The Cloud Authorization Technical Committee will use existing, well designed standards, to provide mechanisms for enabling the delivery of cloud contextual attributes as close as possible to Policy Enforcement Points. Such mechanisms can enable the development of cloud infrastructures that provide in real time a subset of contextual entitlements sets that a decision point can use to authorize or deny a consumer’s use of a specific resource. By developing standard mechanisms to do this, the need to customize the interactions between customer and vendor systems will be reduced, the overhead needed to support authorization and entitlement will decrease and portability across multiple systems will be enhanced.
1) The first sentence gets repeated in the next paragraph (editorial)2) "cloud contextual attributes as close as possible to Policy Enforcement Points" means something to the drafters but what it should mean to prospective members isn't clear.
"cloud contextual attributes" - 2 "hits" - This charter and:Cloud Computing: Standards Development for Security, Privacy and Trust by John Sabo, CA Technologies. http://infosec-summit.issa-balt.org/assets/Presentations/2012%20Summit/2012_Summit-John_Sabo-Cloud_Computing___Policy_Management_and_Standardization.pdf (watch the line wrap)
2 "hits" doesn't qualify as common usage for appearance in a TC charter."contextual entitlement sets" - 2 "hits" - same 2 as "cloud contextual attributes"
3) customer and vendor systems? Some division is contemplated but not clear what that may be. Particularly when overhead to support "authorization and entitlement" (however defined) will decrease, across "multiple systems." Now not vendor/customer but multiple systems. (language shift)
The Cloud Authorization Technical Committee will use existing, well designed standards, to provide mechanisms for enabling the delivery of contextual entitlements to the Policy Enforcement Points. 1.(c) Scope of work: The purpose of this TC is to generate profiles for Cloud Authorization and Entitlements. The purpose of the TC is to develop optimal configuration of relevant standards in order to allow enforcement of authorization policies to be carried out as close to the consumer as possible. In this case, the TC will develop techniques that allow a consumer to receive a set of allowed entitlements and will develop authorization mechanisms that can use these entitlements to determine in real time contextual applicable policies.
1) Repeats earlier language and still left with "Cloud Authorization and Entitlements" as undefined.
2) What is an "optimal configuration of relevant standards? As in what "relevant" standards and are we talking about profiles or "optimal configurations?"
2) Again, consumer not defined, or closeness or "...to determine in real time contextual applicable policies?" none of this is transparent to the reader.
It would help to have one or more explicit use cases along with "authorization and entitlements."1. The TC will define use cases for authorization and entitlements in a Cloud Computing context. These may be existing use cases or new use cases as the TC determines. The TC will reuse use cases identified by the OASIS Identity In The Cloud (ID) TC in the context of Cloud Authorization.
It has been said several times that the TC will use existing standards, but so far I don't know which ones or how. Repetition and not further information.2. When necessary, the TC will work on defining missing specifications for Cloud Authorization and Entitlements. The TC will reuse as a primary objective, existing standards as well as standards that are being developed in the area of scope. The TC will make an effort at not reinventing the wheel.
3. The TC will generate Cloud Authorization and Entitlements profiles for Platform As A Service (PaaS), Infrastructure As a Service (IaaS) and Software As a Service (SaaS) models of Cloud Computing.
Profiles of what standards?
4. In all of its work, the TC should, to the extent feasible, prefer widely implementable, widely interoperable, modular standards, extensions, profiles and methods that permit use by a variety of participants.
I don't think this advances the agenda of the proposed TC.
5. The TC will develop strong liaison relationships with other OASIS Technical Committees, Standards groups and Bodies in the industry. Some of these non-OASIS organizations include OASIS, IETF, ITU-T, ISO and W3C. The TC is free to adopt liaison relationships with any standards organization as it sees fit.
I don't think OASIS qualifies as a non-OASIS organization.Reference to specific organizations where is is likely or where OASIS has ongoing relationships would make this a more credible statement. Particularly in the area of cloud standards.
Should have some use cases in mind to start the TC, perhaps not in ultimate detail bu something that can be used to interest others.Out of Scope Identity Management Provisioning. 1.(d) List of deliverables: 1. A document calling out in detail the specific use cases of authorization and entitlements in a Cloud Computing context that the TC plans to address in their work product. This document will be completed and approved by the TC by January 2013. This document will be a OASIS Committee Note Track document.
Again, "close to the consumer." Without more it isn't possible to imagine what "close" means in a networked context, to say nothing of who is the consumer.2. A document detailing the configuration of relevant standards in order to allow enforcement of authorization policies to be carried out as close to the consumer as possible, using the Cloud Computing Models of IaaS, PaaS and SaaS as examples in this document. This document will be completed and approved by the TC by June 2013. This document will be a OASIS Committee Specification Track document.
I can't even begin to parse the first sentence and I suspect that will be true for many people more deeply involved in Cloud work.3. A document detailing the configuration and specifications to define the download of contextual entitlements in a single call to a Policy Enforcement Point, using the Cloud Computing Models of IaaS, PaaS and SaaS as examples in this document. This document will be completed and approved by the TC by December 2013. This document will be a OASIS Committee Specification Track document.
In terms of a "best foot forward" for OASIS, this charter isn't it. To repair: 1) Use common terminology that is know to participants in cloud work.2) Specify standards if profiles are to be written, standards also known to participants in cloud work.
3) Specify use cases, not all but at least enough for prospective participants to judge if this TC is or is not of interest to them. (Hopefully yes so choose good use cases.)
4) General proofing and editing for readability. For something this important, I would test a draft of the charter with someone not privy to its drafting and ask them to say back its main points and whether they would be interested in joining the TC or not. Try it on ten or fifteen possible new members. Take their responses to heart and make any necessary changes.
If we are trying to attract a substantial number of members for this activity, the delay, process overhead will be worth it. Consider a charter that fails to attract a significant number of new participants versus one that does. What is that worth?
I saved a critical concern to last as it will probably be seen as OASIS/standards politics. Perhaps so, but so be it.
If I were a CTO interested in the cloud and I got a re-written charter that corrects all the issues above, what are my first questions about this charter?
Answer: Where are Amazon, CISCO, HP, IBM, Microsoft, Oracle? Aren't they interested in cloud computing?
(Not meaning to offend by omission but if the average CTO doesn't see names they recognize, the charter isn't DOA, but is on life support upon arrival.)
Or many of the sponsors you will find at: http://cloudcomputingexpo.com/The time to gain momentum is *before* the charter goes out for general release, so that others will see the role call and for public spirited (or defensive) reasons will decide to join the TC.
I would say at least 3 or 4 of the big six and as many of the others as possible should be sponsors of this charter.
Hope you are having a great weekend! PatrickPS: Apologies for the length but if this is going to be a success for OASIS, it needs work.
1.(e) IPR Mode under which the TC will operate: The Cloud Authorization TC will operate under the Non Assertion IPR mode as defined in the OASIS Intellectual Property Rights (IPR) Policy effective 15 October 2010. 1.(f) Anticipated audience or users: The Cloud Authorization TC is intended for the following audiences: architects, designers and implementers of Cloud Computing Infrastructure and Services. (1)(g) Language TC business will be conducted in English. The output documents will be written in English. (2) Non-normative information regarding the startup of the TC (2)(a) Similar or Applicable Work 1. OASIS has Identity In The Cloud (IDCloud) TC [1] and Extensible Access Control Markup Language (XACML) TC [2] whose work will be reused as necessary. 2. IETF has Web Authorization (Oauth) work ongoing [3]. (2)(b) Date, Time, and Location of First Meeting The first meeting of the CloudAuthZ TC will be a teleconference to be held on Tuesday 4th December 2012, 11am to 12pm Eastern. This teleconference will be sponsored by RedHat. (2)(c) On-Going Meeting Plans & Sponsors It is anticipated that the CloudAuthZ TC will meet via teleconference every 2 weeks for 60 minutes at a time determined by the TC members during the TC's first meeting. It is anticipated that the CloudAuthZ TC will meet face-to-face every 6 months at a time and location to be determined by the TC members. TC members will determine the actual pace of face-to-face and teleconference meetings. One of the proposers, as listed below, will sponsor the teleconferences unless other TC members offer to donate their own facilities. (2)(d) Proposers of the TC Anil Saldhana, anil.saldhana@redhat.com, RedHat Scott Stark, sstark@redhat.com, RedHat Mark Little, mlittle@redhat.com, RedHat Abbie Barbir, abbie.barbir@bankofamerica.com, Bank of America Marian Radu, radu.marian@baml.com, Bank of America Rakesh Radhakrishnan, rakesh.radhakrishnan@bankofamerica.com, Bank of America Shahrokh Shahidzadeh, shahrokh.shahidzadeh@intel.com, Intel Mohan Kumar, mohan.kumar@intel.com, Intel Jonathan Sander, jonathan.sander@quest.com, Quest Doron Grinstein, Doron.Grinstein@quest.com, Quest Danny Thorpe, Danny.Thorpe@quest.com, Quest Erik Rissanen, erik@axiomatics.com, Axiomatics Gerry Gebel, ggebel@axiomatics.com, Axiomatics David Brossard, david.brossard@axiomatics.com, Axiomatics Thomas Hardjono, hardjono@mit.edu, MIT Tomas Gustavsson, tomas@primekey.se, PrimeKey Dawn Jutla, Dawn.Jutla@SMU.CA, St.Mary's University Prabath Siriwardena, prabath@wso2.com, WSO2 Paul Fremantle, paul@wso2.com, WSO2 Craig Forster, craig.forster@sailpoint.com, Sailpoint Technologies Darran Rolls, darran.rolls@sailpoint.com, Sailpoint Technologies Tony Rutkowski, tony@yaanatech.com, Yaana Technologies Mary Ruddy, mary@meristic.com, Identity Commons Gershon Janssen, gershon@qroot.com, Individual (2)(e) Statements of Support Mark Little, mlittle@redhat.com, RedHat: As Primary Representative for Red Hat, we are pleased to support the OASIS Cloud Authorization Technical Committee in its work. Abbie Barbir , abbie.barbir@bankofamerica.com, Bank of America: As Bank of America representative to OASIS, I approve the Cloud Authorization TC Charter, and endorse all BofA proposers listed. Shahrokh Shahidzadeh, shahrokh.shahidzadeh@intel.com, Intel: As the primary representing Intel Corp at OASIS I like to report that we do support the formation of Oasis Cloud Authorization TC per attached proposal. Doron Grinstein doron.grinstein@quest.com, Quest Software, Inc.: As Quest Software, Inc.'s representative to OASIS, I approve the Cloud Authorization TC Charter, and endorse all Quest proposers listed. Erik Risannen, erik@axiomatics.com, Axiomatics: As the OASIS primary contact for Axiomatics, I support the creation of the proposed OASIS Cloud Authorization Technical Committee as described in its Charter. Thomas Hardjono, hardjono@mit.edu, MIT: As MIT's representative to OASIS, I approve the Cloud Authorization TC Charter, and endorse all MIT proposers listed. Paul Fremantle,paul@wso2.com, WSO2: As the OASIS Primary Representative for WSO2, I support the creation of the proposed OASIS Cloud Authorization Technical Committee as described in this Charter. Tomas Gustavsson, tomas@primekey.se, Primekey: As primary representative, I hereby declare that I support the Cloud Authorization TC. Dawn Jutla, Dawn.Jutla@SMU.CA, St.Mary's University: As the primary OASIS representative of Saint Mary's University, I support the OASIS Cloud Authorization TC charter. Tony Rutkowski, tony@yaanatech.com, Yaana Technologies: Yaana Technologies LLC supports this charter and the creation of this TC. Mary Ruddy, mary@meristic.com, Identity Commons: As the Identity Commons liaison to OASIS and primary representative, I approve the Cloud Authorization TC Charter. Darran Rolls, darran.rolls@sailpoint.com, Sailpoint Technologies: As the Sailpoint Technologies primary representative, I support the OASIS Cloud Authorization TC charter. (2)(f) TC Convener Abbie Barbir, abbie.barbir@bankofamerica.com , will be the Convener of the CloudAuthZ TC. (2)(g) Affiliation to Member Section OASIS IDTrust Member Section (2)(h) Initial Contribution None (2)(i) Draft Frequently Asked Questions (FAQ) (optional) N/A (2)(j) Working title and acronym for the Work Products to be developed by the TC To Be Determined. References [1] OASIS Identity in the Cloud TC: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=id-cloud [2] OASIS Extensible Access Control Markup Language TC: https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml [3] IETF Web Authorization Charter: http://datatracker.ietf.org/wg/oauth/charter/ /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-996-2298 Mobile: +1 201-341-1393 --------------------------------------------------------------------- To unsubscribe, e-mail: oasis-charter-discuss-unsubscribe@lists.oasis-open.org For additional commands, e-mail: oasis-charter-discuss-help@lists.oasis-open.org
-- Patrick Durusau patrick@durusau.net Former Chair, V1 - US TAG to JTC 1/SC 34 Convener, JTC 1/SC 34/WG 3 (Topic Maps) Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300 Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps) Another Word For It (blog): http://tm.durusau.net Homepage: http://www.durusau.net Twitter: patrickDurusau
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]