oasis-charter-discuss message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: CloudAuthZ - Scope statement and minor issues
- From: Robin Cover <robin@oasis-open.org>
- To: OASIS Charter Discuss List <oasis-charter-discuss@lists.oasis-open.org>
- Date: Mon, 15 Oct 2012 20:37:50 -0500
* At the moment of email "Send" just now, I spot a reference to a recent
blog article from Rakesh Radhakrishnan, which I may get permission
to cite on this forum if it's not otherwise referenced.
============
I. Intro
============
Ongoing conversations with OASIS Staff and non-Staff suggest
that the CloudAuthZ TC, much like the OASIS IDCloud TC, will
attract significant attention, and focus attention on the
new authorization/entitlement issues raised by technological
challenges of cloud, mobile computing, big data, and
ubiquitous instrumentation of everything electronic.
My own research, anecdotally, similarly suggests that the
number of academic papers and presentations, not to mention
dedicated industry initiatives, are increasing in response
to the challenges of cloud and global networked computing.
In an article or blog I've recently lost, but I think written
by Rakesh Radhakrishnan, it was claimed that where SAML was
a key/foundational specification in the last decade, giving
rise to many new specification development initiatives and
software products, the next decade see the rise of interest
in XACML (extensions, profiles), particularly in connection
with new REST architectures.
With that growing body of evidence, I'm (personally) paying
close attention to the CloudAuthZ charter proposal [1], in
anticipation of the TC's popularity and success -- of course,
in synergy with SAML and XACML TC activities on the move.
I sent two short comment sets on the CloudAuthZ draft
proposal text (both editorial) [2], while Crystal L Hayes
and Patrick Durusau have submitted more substantive comments
[3].
Here's a final comment set, which includes one issue I
judge critical (II), and a handful of smaller/minor issues
that could be handled as clerical/editorial (III).
===========================
II. Clarification on Scope
===========================
Some features of the Scope seem crisp and clear, and especially
so for readers familiar with the OASIS process for specification
development and approval in our two Tracks:
1) the TC will develop/describe use cases and publish (some of)
them in Non-Standards Track Work Product(s)
2) the TC will develop technical specifications as profiles
and advance them in the Standards Track
3) these specifications will profile existing standards where
possible and appropriate
4) the specifications may represent new technical solutions
in cases where existing standards cannot be profiled
5) cloud computing service models supported by the profiles will
include PaaS, IaaS, and SaaS
The Scope seems not to be crisp and clear, however, in one
respect, because the references to "single call" and "close
to the consumer" are repeated in several sections of the
draft proposal. Are those notions meant to exclude?
Question: will use cases (issues, problems) be considered in
scope if they relate to "cloud computing authorization and
entitlements" but have little or nothing to do with these
two resource management considerations called out multiple times:
(a) performed/carried out as close to the consumer as possible
(b) facilitated via one/single call to the authorization server
That is: will the TC accept as "in scope" candidate use cases
for "cloud computing authorization and entitlements" where
the use cases are quintessentially unrelated to "(a)" and/or "(b)"?
I think proposal section "1.(c) Scope of work" needs to be
edited to make it clear whether the TC will meaningfully
consider (in scope) ALL "cloud computing authorization and
entitlements" use cases, in the large and in general, OR
(alternately) ONLY those which relate to "(a)" and/or "(b)"
above.
==========
Minor
==========
1) Item #5 in "1.(c) Scope of work" needs to be moved to Section
(2)(a), which will lead to a unified Reference list; see details
in [5] below
2) In (d)(1), "work product" needs to be "Work Products" [since
the term is defined, and the proposal lists three of them
3) The spelling for [Aa]uthorization and [Ee]ntitlements should
be consistent, and I recommend lower case unless the phrase
can be justified as a defined term, in which case, the
reader would benefit from a citation to the authority which
defines the term; in the draft text, there are three
occurrences of lower case spelling and three for upper case,
but I can detect no justification for the variation
4) Also on spelling (capitalization): I think the proposal
might be clearer to the non-expert reader, e.g., a CEO
or CMO if the term [Cc]onsumer were capitalized, as it is
in the OAuth specification and similarly, with the
spelling of "Policy Enforcement Point", "Cloud Computing",
"Cloud Providers" (etc) in the CloudAuthZ proposal draft.
That orthography (perhaps also: a gloss/definition) would
make it clearer to a non-expert that we are not talking
(necessarily) about a human user, but rather a device,
an application, an API, a process, web site, service, etc.
5) misc punctuation/copy editing: some nits that OASIS
Staff could fix just editorially if the proposers want
to send the penultimate fixed-up proposal for tweaks
==========
IV. Notes
==========
[1] Proposed Charter for Cloud Authorization (CloudAuthZ) TC
[2] Terminology for "Track" in the CloudAuthZ TC proposal
Possible liaison/collaboration candidate for CloudAuthZ TC (Novay Project)
Patrick Durusau (multiple issues)
[4] Details
Explanation: The proposal asserts in four passages the notion of
"closeness", and thus makes it unclear (from the Scope) whether
topics not related to "closeness" are also in scope. Similarly,
"one/single call" is mentioned twice. E.g., verbatim
- needs to be performed as close to the consumer as possible
- as close as possible to Policy Enforcement Points
- policies to be carried out as close to the consumer as possible
- policies to be carried out as close to the consumer as possible
- need... one call
- in a single call
The repetition of closeness and single call make it difficult
to ascertain whether scenarios NOT matching one or both of those
goals/constraints are in scope.
Also: the proposal section for "1.(c) Scope of work" begins
with two sentences that address "purpose": but "purpose" is
different than "scope", and purpose should be addressed in Section
"1.(b) Statement of Purpose", which is fundamentally a description
of "the problem to be solved". Does the proposed TC want to
address one problem, or several, or indeed: will the TC address
any problem or use case (whatsoever) relating to cloud authorization
and entitlements?
For "Scope", the reader needs to know how the technical activity
will provide technology and/or policy to solve the problem or
problems, viz.,
* a definition of what is the work of the TC
* a definition of what is not the work of the TC
* how it can be determined when the work of the
TC has been completed
* which specific contributions of existing work,
if any, will be used as a starting point
[5] Proposal Text: "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.
Action: Please discuss liaison relationships in proposal
Section (2)(a), not under Scope, per the instructions for TC Formation;
identifying liaison activity does not establish the scope of the
topic of work. Per the TC Process:
"(2)(a) Identification of similar or applicable work that is
being done in other OASIS TCs or by other organizations, why
there is a need for another effort in this area and how this
proposed TC will be different, and what level of liaison will
be pursued with these other organizations."
Ideally, for TC liaisons, the name of the peer Working Group,
Working Party, Technical Committee (etc) should be given,
together with a URI reference for each (example) named, best
probably in a unified References list
Examples, similar to the items now in the proposal (2)(a):
Kantara Attribute Management Working Group (AMWG)
OGF OGSA Authorization Working Group
--
Robin Cover
OASIS, Director of Information Services
Editor, Cover Pages and XML Daily Newslink
Email: robin@oasis-open.org
Staff bio: http://www.oasis-open.org/people/staff/robin-cover
Cover Pages: http://xml.coverpages.org/
Newsletter: http://xml.coverpages.org/newsletterArchive.html
Tel: +1 972-296-1783
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]