OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

cloudauthz message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: FW: [cloudauthz] a definitino of 'Entitlement' - proposal


it is certrainly to earlier in the process to get to the level of semantics that distingiuishes between the owner and the entitlement system that is supposed to work on its behalf. Nonehteless, based on my experience of working with other standard TCs, I think it is very important to establish an accurate wording from the beginning. This will save us from the later arguments like "this expressions is used by us from the early days and nobody had problems with it". I do have a problem even at the lower semantic level.

Also, in my practice, a wrong implementation of correct business rules was as frequent as mistakes in specifications of business rules. So, I cannot agree that this is an insignificant matter, sorry.

Anyway, I am impatient to here your critics to the presentation statement I posted into CloudAuthZ document folder.

Best regards,
- Michael Poulin


----- Original Message -----

From: David Chadwick

Sent: 01/22/13 05:46 PM

To: Mike Poulin

Subject: Re: FW: [cloudauthz] a definitino of 'Entitlement' - proposal


i think you are splitting semantics to too fine a point. If the owner 
sets the policy for the entitlement system and the latter obeys the 
owner's policy then the owner is effectively making the decision, albeit 
via a piece of automated machinery that acts on his behalf. The chance 
of the entitlement system making a "wrong" decision due to a fault in 
its machinery is far less than a wrong decision due to the owner not 
specifying his policy accurately enough. So I think the risk you talk 
about is insignificant compared to the risk of the owner screwing up 
himself. Complex policies are very hard to get right 



On 22/01/2013 15:54, Mike Poulin wrote: 
> I think we have to use more accurate language - if an entitlement system 
> make actual decision about permission, it is done NOT by the owner of 
> the resource. However, entitlement system acts upon 
> instructions/directives given by the owner. So, the decision belongs to 
> the entitleement system, in general, not to the owner of the resourse, 
> and the entitleement system has a risk of realising the owner's 
> instructions/directives not in 100%. This what we must to take into 
> consideration. 
> I think that the industry passed the point of the owner making 
> entilement decisions long ago. 
> - Michael Poulin 
>> ----- Original Message ----- 
>> From: David Chadwick 
>> Sent: 01/22/13 02:46 PM 
>> To: Barbir, Abbie 
>> Subject: Re: FW: [cloudauthz] a definitino of 'Entitlement' - proposal 
>> Tom, I think we are on the same path. What we call the entity that 
>> passes from the user to the resource is less important than its 
>> semantics, and we agree it is not a privilege, but rather it is 
>> something that the resource owner decides is or is not permission to 
>> access what the user requested to access. I dont think entitlement is 
>> the correct name for this entity 
>> regards 
>> David 
>> On 22/01/2013 14:18, Barbir, Abbie wrote: 
>> > *From:*Smith, Thomas C. [mailto:Tom.Smith@jhuapl.edu] 
>> > *Sent:* Tuesday, January 22, 2013 9:07 AM 
>> > *To:* Barbir, Abbie 
>> > *Subject:* RE: [cloudauthz] a definitino of 'Entitlement' - proposal 
>> > 
>> > Abbie, 
>> > 
>> > I tried to post this but it bounced. Can you post it for me? Thanks, -tom 
>> > 
>> > All, 
>> > 
>> > So here’s my two cents… 
>> > 
>> > An entitlement is what you get by virtue of membership regardless of how 
>> > it’s obtained (birth, grant, activity, etc.). It implies, but does not 
>> > guarantee or even specify privilege (where privilege is allowing a 
>> > subject’s requested resource action in a given context).  To say it 
>> > another way, privilege is the consequence of applying policy to 
>> > entitlement(s). This separation of concerns is very important because 
>> > the resource owner controls the policy, not the entitlement manager. So 
>> > if you bind them in the design then it will not scale across resource 
>> > owners that don’t have the same policy set. 
>> > 
>> > -tom 
>> > 
>> > *From:*cloudauthz@lists.oasis-open.org 
>> > <mailto:cloudauthz@lists.oasis-open.org> 
>> > [mailto:cloudauthz@lists.oasis-open.org] *On Behalf Of *Mike Poulin 
>> > *Sent:* Tuesday, January 22, 2013 8:12 AM 
>> > *To:* cloudauthz@lists.oasis-open.org 
>> > <mailto:cloudauthz@lists.oasis-open.org> 
>> > *Subject:* [cloudauthz] a definitino of 'Entitlement' - proposal 
>> > 
>> > Hello All, 
>> >   here is a proposal for a definitino of Entitlement: 
>> > 
>> > An Entitlement is 
>> > 
>> >   * ·A concept of having a right to something or a guarantee of access 
>> >     to something or based on established rights or by legislation. A 
>> >     "right" is itself an entitlement associated with a moral or social 
>> >     principle, such that an "entitlement" is a provision made in 
>> >     accordance with the legal framework of a society. 
>> >   * ·A process of on- and off-boarding an entitlement system, claiming 
>> >     and assigning access rights,  and administering the entitlement system 
>> >   * ·A system (manual or automated) that physically realises the 
>> >     entitlement process, keeps entitlement entries, maintains 
>> >     permissions and access rights for as well as information about the 
>> >     actors and resources covered by the entitlement 
>> > 
>> > 
>> > 
>> > Cheers, 
>> > - Michael Poulin 
>> > 
>> > ------------------------------------------------------------------------ 
>> > This message, and any attachments, is for the intended recipient(s) 
>> > only, may contain information that is privileged, confidential and/or 
>> > proprietary and subject to important terms and conditions available at 
>> > http://www.bankofamerica.com/emaildisclaimer. If you are not the 
>> > intended recipient, please delete this message. 
>> --------------------------------------------------------------------- 
>> 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 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]