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

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

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


Subject: Re: [xacml] Attribute Assertions in request context


Hi Tony,

The example you gave is actually much richer than what we had in mind,
but at the same time it doesn't really exemplify the functionality that
we do have in mind. Delegation is definitely out of scope for us. We
simply envision IDPs as storing attributes about users and being willing
to certify (true) predicates over these attributes for consumption by
relying parties.

To adapt our use case to your notation, what we have in mind would be
more along the lines of:

Employee database at A:
DB-A says Alice is an employee of A
DB-A says Alice started working with A on June 1st, 2009

Policy at PDP-C:
C says X may execute Calculation if
X is an employee of A,
X has been with A for more than 1 year.

Alice gets from STS-A and sends to PDP-C the following assertions:
A says Alice is an employee of A
A says Alice has been with A for more than 1 year

Best,
Greg

On 2/8/2011 18:16, Anthony Nadalin wrote:
> Here is a "federation" scenario, not sure it's simple though
>
>
> For brevity, this example uses the “say/can-say” assertion notation of Butler Lampson.
> Alice at Company A wants to perform some calculations using data stored at B and computational server C.   Assume that the date is June 3, 2010.
>
>
> Policy at STS-A:
> 	A says X is a member of project Gamma if (new) 
> 	DB-A says X reports to Y, 
> 	DB-A says Y is the manager of project Gamma. 
>
> Employee database at A:
> 	DB-A says that Alice is an employee of A. 
> 	DB-A says that Alice reports to Jose
> 	DB-A says that Jose is the manager of project Gamma. 
>
> Policy at PDP-B: 
> 	B says X may read file F if 
> 	X is a member of project Gamma
> 		F is contained in B:/Gamma/.
>
> Policy at STS-B:
> 	B says X can say∞ (Y can read F before time T) if 
> 	X can read F,
> 	T < Now() + 30 days. 
> 	wrapped in a transport)
> 	B says A can say0 X is a member of project Gamma
>
>
> Policy at PDP-C:
> 	C says X may execute Calculation if 
> 	X is an employee of A. 
>
> Policy at STS-C:
> 	C says A can say0 X is an employee of A
>
> Alice gets from STS-A the following assertions: 
> 	A says Alice is a member of project Gamma. 
> 	A says Alice is an employee of A. 
>
> Alice sends to STS-B the following command plus assertions:
> 	A says Alice is a member of project Gamma. 
> 	Alice says C can read file "B:/Gamma/data" before time Time("2010-07-01"). 
>
> 	and receives the following assertion back from STS-B:
> 	B says C can read file "B:/Gamma/data" before time Time("2010-07-01"). 
>
> Alice sends to C the following command plus assertions:
> 	Execute Calculation(file "B:/Gamma/data").
> 	A says Alice is an employee of A. 
> 	B says C can read file "B:/Gamma/data" before time Time("2010-07-01"). 
>
> C checks PDP-C for a Permit to execute Calculation.  After receiving the permission, C sends to B the following command and assertions:
> 	Read file "B:/Gamma/data".
> 	B says C can read file "B:/Gamma/data" before time Time("2010-07-01"). 
>
> B checks PDP-B and receives permission for C to read "B:/Gamma/data".  B sends the file to C. C performs the calculation.
>
> -----Original Message-----
> From: Bill Parducci [mailto:bill@parducci.net] 
> Sent: Thursday, February 03, 2011 10:33 AM
> To: Anthony Nadalin
> Cc: XACML TC
> Subject: Re: [xacml] Attribute Assertions in request context
>
> Tony,
>
> Do you have a simple use case that describes what you are trying to achieve? 
>
> thanks
>
> b
>
> On Feb 2, 2011, at 8:46 AM, Anthony Nadalin wrote:
>
>> Correct, it would not be the basic permit or deny, we thought about the obligation but this leaves us with the permit/deny problem (what to do there). Our issue is that the PDP may not be able to actually may not be able to prove the claim and only the PEP can (application).
>
>
>
>
>
> ---------------------------------------------------------------------
> 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]