CloudAuthZ - Scope statement and minor issues

* 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

     https://lists.oasis-open.org/archives/oasis-charter-discuss/201210/msg00003.html

     

[2]  Terminology for "Track" in the CloudAuthZ TC proposal

     https://lists.oasis-open.org/archives/oasis-charter-discuss/201210/msg00006.html

     Possible liaison/collaboration candidate for CloudAuthZ TC (Novay Project)

     https://lists.oasis-open.org/archives/oasis-charter-discuss/201210/msg00007.html

     https://lists.oasis-open.org/archives/oasis-charter-discuss/201210/msg00008.html

     

[3]  Crystal L Hayes <> (compliance monitoring)

     https://lists.oasis-open.org/archives/oasis-charter-discuss/201210/msg00005.html

     Patrick Durusau (multiple issues)

     https://lists.oasis-open.org/archives/oasis-charter-discuss/201210/msg00027.html

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

http://kantarainitiative.org/confluence/display/AMDG/Draft+00+--+Charter+for+an+Attribute+Management+Working+Group

OGF OGSA Authorization Working Group

http://www.ogf.org/gf/group_info/charter.php?review&group=ogsa-authz-wg

-- 
Robin Cover
OASIS, Director of Information Services
Editor, Cover Pages and XML Daily Newslink
Email: 

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