Thanks for getting this out in time for the telecon today.
I have to say that I'm again surprised at the proposal because it's different from what we discussed at the F2F, and goes much beyond where I thought we were going. I was expecting to see only what you currently call authorization.finegrain and an example with XACML. My initial reaction to the proposal is to go no further than that as the resolution to issue 57. Never-the-less, I have a few questions and comments in case there is interest in pursuing this proposal further.
Question:
q1) authorization.finegrain - This is an intent that is only satisfied by the presence of a policySet? I think so, but just want to check that.
q2) Do any of the other intents need policySets to satisfy them or is the container expected to simply implement them? If so, then we need stronger normative guidance
Major comments:
1) I really don't know what SAR is. The description in the text is brief. Is there an external reference that we can cite here?
2) usecalleridentity is identity based instead of role based. I have a strong preference for role based mechanisms, such as RunsAs role.
3) propagatecalleridentity - Reword: "the propagatecalleridentity qualifier specifies that if the component invokes other services then it should use the caller identity that it was invoked by as the identity requesting access to those services. The absence of this intent will cause other services to be invoked with the component’s configured container identity."
Minor comments:
a) change qualifier names to camelCase
b) section 7.4.1 - denyaccessbias - second sentence contradicts the first sentence. I think the entire description should read:
"the denyaccessbias qualifier specifies that access should be denied unless explicitly permitted by the authorization policies. In the absence of this qualifier, access will be permitted unless there are specific authorization policies which explicitly deny access."
Dave Booz
STSM, BPM and SCA Architecture
Co-Chair OASIS SCA-Policy TC and SCA-J TC
"Distributed objects first, then world hunger"
Poughkeepsie, NY (845)-435-6093 or 8-295-6093
e-mail:booz@us.ibm.com
"Rich.Levinson" ---02/06/2009 11:36:22 PM---Hello TC, The attached document contains the revised proposed resolution for issue
 From: |  "Rich.Levinson" <rich.levinson@oracle.com> |
 To: |  "Rich.Levinson" <rich.levinson@oracle.com> |
 Cc: |  OASIS Policy <sca-policy@lists.oasis-open.org> |
 Date: |  02/06/2009 11:36 PM |
 Subject: |  Re: [sca-policy] Issue 57 - proposed text changes |
Hello TC,
The attached document contains the revised proposed resolution for issue 57 and subsequent actions from the F2F, Action 20090128-1 and Action 20090128-2, plus input from subsequent emails, particularly
http://lists.oasis-open.org/archives/sca-policy/200902/msg00007.html
The attached document has changes highlighted. Specifically, the changes to consider are all contained in the brand new sections 7.3, 7.4, which are proposed to totally replace what was previously sections 7.3-7.7.
These changes also render Action 20090128-1 moot, provide a resolution to 20090128-2, and with the last 3 qualifiers defined in section 7.4 represent an alternative representation of the requirements that appeared to be indicated by the replaced text that I tried to capture in these 3 qualifiers. As such, these last 3 qualifiers represent a "separable section" of the proposal to address the brunt of the above ref'd email that tries to preserve the original needs expressed in the previous text, with structures that conform to the overall SCA-Policy Framework methodology.
Thanks,
Rich
Rich.Levinson wrote:
- Hi TC,
Attached are two files that contain the proposed changes for XACML and fine grain authorization. The first file is from Ashok that shows the changes Ashok recommends for inclusion of XACML policy fragments. The second file is from me and shows the changes I applied to Ashok's proposal to enhance it to include fine grain authorization.
Thanks,
Rich
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php (See attached file: sca-policy-1[1].1-spec-CD01-Rev13e-chgs-accepted-rich-ashok-mods-3.doc)---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php