[Wg-uma] Use Case Scenarios

Eve Maler eve at xmlgrrl.com
Wed Aug 26 13:46:31 PDT 2009


Hi Hasan, Maciej, et al.,

I've done a partial (and very quick) analysis of about half of  
Maciej's document. Hopefully these thoughts will be helpful in teasing  
out distinctive aspects, conceptual similarities, next steps, etc.,  
and I hope Maciej will also correct any of my misunderstandings.  If  
I've generally hit the nail on the head, I can continue the analysis  
later this week.

(Below "UCAC" is "User-Centric Access Control" as conceived in the  
document.)

Hasan, please note my queries to you below, marked with the usual  
hashtags.

	Eve

====

Terminology and concept matching:

- UCAC "Security Provider (SP)" == UMA "Authorization Manager (AM)",  
quite precisely
- UCAC "Web Application" == UMA "Service Provider (SP)", quite precisely
- UCAC "Consumer" assumes more strongly that a human is behind this  
endpoint than does V1 of UMA "Consumer" (it is not precluded in V1 --  
just not optimized for)

Scenario and use case analysis:

- 2.1 Access Control to Distributed Web Resources seems close to  
"calendar" scenario; no unique aspects jump out that aren't already  
captured elsewhere in UMA work.

- 2.2 Multiple Levels of Access Control highlights the user's ability  
to choose multiple Security Providers/Authz Managers, in order to  
apply stricter release policies in some cases and to distribute the  
resource "eggs" among multiple "baskets".  This is an intended feature  
of UMA, but has not been highlighted through a formal scenario yet  
(see http://is.gd/2AmpW for a mention at the end). This scenario could  
be made more interesting still by highlighting the need for Security  
Providers/Authz Managers to adhere to "data portability" practices,  
such that the SP/AM itself becomes a Web Application/Service Provider  
in turn, feeding metadata into a master digital dashboard.

- 2.3 Diverse Access Control for Web Resources points out the need for  
a user to see data-sharing analytics; this need is shown in wireframes  
linked from the "calendar" scenario, so this may be covered already.

2.3 Diverse Access Control for Web Resources is very complex and  
introduces several distinctive aspects.  First, there is the notion of  
a drag-and-drop graphical UX for nontechnical people, which I'm not  
sure needs a new scenario for our purposes but I strongly agree with!   
Second, there is a hint about knowing unique identities of other users  
in various namespaces (Peter and Natalie somehow coordinating access  
on resources they share?), though I'm not clear that this is an  
essential part of the scenario.  This should be discussed to tease out  
the distinctive features and figure out whether they're in scope.  I  
suggest there is also an #issue here to document: To what degree do we  
need to capture literal *shared ownership* of some resource, vs. being  
able to finesse the issue by allowing a single owner to grant some/all  
access rights to others?  I'm hoping to lean on the latter as much as  
possible.

2.4 Multiple Security Providers for a Single Set of Web Resources has  
a somewhat unrealistic motivation, I find.  However, there are many  
realistic scenarios that do involve the need for multiple throttles on  
sharing.  The big question here is whether it's realisitic for a  
*single* person to want to apply multiple independent controls, or  
whether *multiple* parties (and possibly their separate Security  
Providers/Authz Managers) need to be in the authorization loop.  There  
are several use-case topologies for solving the latter, as discussed  
in http://is.gd/2AmFf (employer/employee scenario); some of the use  
cases finesse the problem by applying additional users' constraints in  
an out-of-band fashion.  (Hasan, should/can we "import" the employer/ 
employee #scenario and #use cases from my blog into the document?)

2.5 Access Control Management Delegation is a very interesting and  
important scenario, since the only way the risks of full-access  
impersonation (through, e.g. password sharing) are going to be  
mitigated is through a robust, easy-to-use partial-access delegation  
model!  The use cases for this scenario may turn out to involve  
"identity" in a deep fashion, which I'd prefer to avoid, but I'd also  
like us to avoid missteps when defining the architecture, which might  
make it impossible to solve for such use cases.  In other words,  
depending on the details, this might be a "defer but try not to  
preclude" situation.   Alternatively, it may be that we can combine  
UMA with an identity-aware service such as a smarter version of  
Portable Contacts ("PoCo.next"?) to get the needed functionality.   
(Note that this scenario explicitly involves a person in the Consumer  
role, which is nominally out of scope for UMA V1.)

(Still need to review 2.6 - 2.10.)

	Eve

On 26 Aug 2009, at 4:17 AM, Hasan Ibne Akram wrote:

> Dear Maceij,
>
> Thanks for sending the documents out. Personally, I am certainly  
> very interested in them. Now the question is "how to incorporate the  
> relevant issues in our UMA use case document?"
> What I would like to figure out first is, the similarities and  
> commonalities between the already added scenarios and your  
> scenarios. In other words, how to extract from your scenarios issues  
> which are possibly within the scope of UMA and has not yet been  
> addressed? Do you have any comments to that?
>
> Best regards,
>
> Hasan
>
> On Tue, Aug 25, 2009 at 11:44 PM, Maciej Machulak <m.p.machulak at newcastle.ac.uk 
> > 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
>
> --
> Maciej Machulak
> PhD Student, Newcastle University
> http://www.trust-economics.org/maciejm


Eve Maler
eve at xmlgrrl.com
http://www.xmlgrrl.com/blog




More information about the Wg-uma mailing list