[Wg-uma] Use Case Scenarios

Eve Maler eve at xmlgrrl.com
Mon Aug 31 22:16:46 PDT 2009

Okay, I'm trying to go through the rest of Maciej's document (though  
Analyzing While Fatigued ought to be against the law...).  I apologize  
in advance for any incoherence and for seeming to say too little about  
any of the scenarios!

- 2.6 Access Control for Internal and External Web Applications: This  
one could almost have a nickname of "RESTful, Web 2.0-enabled XACML"  
for the consumerized enterprise, and indeed, the polices required in  
such a case might be as complex as they are now for XACML (and  
proprietary) access control deployments. Of course, XACML would be a  
suitable choice for the policy expression language too.

Because this scenario is not about individuals who are acting on their  
own behalf, but rather about employees acting on their employer's  
behalf, I suspect this might be headed for a deferral -- but I am  
still interested in capturing it.

Part of the complexity of the policy situation here is the ability to  
gather identity attributes from multiple sources.  This is something I  
hadn't anticipated would be needed by a person who's a "free agent on  
the web".  However, it seems like Facebook etc. -- which are described  
as being "identity providers" here -- could be recursively serving as  
UMA Service Providers/UCAC Web Applications (entity #3) whose release  
of identity attributes could be controlled by *someone* (not sure who,  
and now my brain is hurting :-).

Finally, I'm not sure I understand the notion of having an employee  
security provider and a company security provider working in concert.   
Is the employee security provider just a policy administration point  
vs. also being a policy decision point, or are there really two policy  
decision points whose output somehow gets combined?

- 2.7 Access Control Using Opaque Tokens and Obligations: Aha, very  
sophisticated scenario here.  This gets us into the world of payments,  
which has been imagined but not captured in an UMA scenario properly  
so far, and it takes a good hard look at some of the protocol and  
content-handling implications we might have.  It would be great to  
have a group conversation about an UMA scenario focused on this, and  
see if the dynamicism of "requiring a resource being processed after  
an access control decision is enforced but before a resource is sent  
to a consumer (e.g. the service can grant access to a resource but  
process the picture first by decreasing its resolution)" is a nice-to- 
have use case or a must-have use case.  I think Paul spent some time  
on the last call describing how we were anticipating a Client (party  
#4) could actively "meet terms" (such as "here's my receipt for the  
$10 I paid you") set by the User (party #1) -- but this is not fleshed  
out at all yet.

- 2.8 Delegating Access Control for Single Resources: This sounds very  
much like the idea for a "bookkeeping"/Virtual Assistant scenario I  
mentioned in email (in response to the VO thread).  For quite a few  
real-life use cases I can think of, as for the examples provided here,  
we might be forced into handling clever UMA Service Provider/UCAC Web  
Application (party #3) policy options.  We'll have to expand on the  
scenario(s) to really see if this is true.  E.g., typically a small  
business owner would grant his bookkeeper access at a very gross level  
of granularity, only reserving, say, password-changing functions -- so  
perhaps we can come up with a small handful of likely policy options  
that *don't* require special knowledge that it's a bank account being  

I believe this scenario (like the Virtual Assistant idea) also carries  
with it the notion that the person whose access is being permissioned  
is taking on a special role: "on-behalf-of".

- 2.9 Moving Resources Between Web Applications: The nickname for this  
one could be the "data portability" scenario.  I'm not actually  
familiar with many Web 2.0 apps that make the portability of the data  
they host on your behalf simpler, though it's obviously a feature many  
people would like to have!  My guess is that as soon as import/export  
of the data resources themselves is made painless, the policies you  
attach to them should also be made painless...but we have a while to  
go before this latter need is truly felt.

- 2.10 User Intervention in the Access Control Decision Making  
Process: This scenario highlights a very important goal that appears  
briefly in the wireframes for the Calendar scenario, but is otherwise  
not remarked on specially.  This is the policy option to "ask me  
first" before sharing, either on initial access or every time.  This  
need has protocol implications (which the ProtectServe sketch has  
tried to take into account), but once the basic mechanism is built in,  
there lots of interface and user-messaging choices that would all be  
"compliant".  I'd love to have an UMA scenario focused on user  
intervention to make sure we get it right.


On 25 Aug 2009, at 2:44 PM, Maciej Machulak wrote:

> Hi,
> The preliminary Use Cases Document had some mistakes so that use  
> cases from sections 2.7, 2.8, 2.9 and 2.10 had to be rewritten.  
> Therefore, those sections have some major changes.
> If anyone's interested, the final draft is available at: http://www.trust-economics.org/maciejm/UseCasesFinalDraft.pdf
> Cheers,
> Maciej
> ________________________________________
> From: Maciej Machulak
> Sent: 20 August 2009 17:09
> To: WG UMA
> Subject: RE: Use Case Scenarios
> Hi,
> Not sure if my last email got through (because of attachments?), so  
> here are the links to documents regarding User-Centric Access Control:
> http://www.trust-economics.org/maciejm/Oakland_May_2009.pdf
> http://www.trust-economics.org/maciejm/UseCasesDocument.pdf
> Cheers,
> Maciej
> ________________________________________
> From: Maciej Machulak
> Sent: 20 August 2009 16:19
> To: WG UMA
> Subject: Use Case Scenarios
> Hi all,
> Please find attached the (preliminary!) version of the document with  
> some use case scenarios that was made for our User-Centric Access  
> Control approach (equivalent of UMA) here at Newcastle University.  
> There are ten scenarios - from basic ones to those that are more  
> interesting. Hope the document is interesting (even taking into  
> account its length...). I should be taking the most interesting  
> scenarios and putting them on our Wiki - this is when I'll be able  
> to discuss them in much more details and add bits which are still  
> missing.
> Anyway, I hope the scenarios are helpful.
> Cheers,
> Maciej

Eve Maler
eve at xmlgrrl.com

More information about the Wg-uma mailing list