[Wg-uma] Use Case Scenarios
m.p.machulak at newcastle.ac.uk
Thu Aug 27 05:08:52 PDT 2009
Thanks for your email. It's great you had time to take a look at the document. The bad part is you only looked at the "not so interesting" scenarios ;) Hope the other part (sections 2.6 - 2.10) will be much more interesting and much more useful for the UMA work.
Remarks about terminology:
I started using 'Security Provider', 'Web app', etc. some time ago and this is mostly why those terms are still in the document (and to be coherent with my previous documents). When I contribute to the Wiki, I shall change those terms obviously so that they match terminology of UMA.
Remarks about your comments:
2.2. Yes, this is exactly what is being mentioned at the end of the link you provided. The RM component can and should be able to act as a Service Provider and as a Consumer, as mentioned. With modularity of its design, it should be very easy to achieve that. However, I'm not sure what you mean about 'data portability' practices?
2.3. This scenario is a bit different from what you comment in here - your comments apply more to scenarios from sections 2.4 and 2.6 . What I tried to capture in here is very simple (I'll mention this again - scenarios from sections 2.1 to 2.5 are quite simple; more interesting ones are described later in the document). The same Web application can use different Authorization Managers depending on the user who owns resources hosted by this Web application. This is mostly to capture one of the motivations of User-Centric Access Control / User Managed Access: as a User I would like to be able to use application A because I like its functionality. I may not like its security features though. That is why I would like to plug in my own Authorization Manager which meets my requirements. Different user has different security requirements and skills. They both may like the same application but would like to have different RM.
2.4. I think that at some point there could be a way of multiple modules (RM) be able to provide their input into the access control decision making process. In this scenario, it is a single user that controls all of those components. However, there could be multiple entities in control over a single set of Web resources. This is similar to your Employee/Employeer scenario: "If the employer doesn’t want to release the data even though the employee is cool with the sharing, it could use existing access control mechanisms that are out of band with respect to ProtectServe, perhaps only surfacing a response code that reflects its refusal." The Employeer could also use its own RM which would additionally control access to employee's resource (e.g. checking for data leaks, etc). This is mentioned in Section 2.6.
2.5. I think that being able to delegate access control to different entities that may be more proficient in security is an important feature. This is what is captured by the scenario. Originally, I was not thinking about shared ownership but about just delegating access control. In any case, both features are quite desirable right now, I suppose. The project I'm participating in at Newcastle Uni is closely related to how users perceive security and how such security affects their core tasks. What I was interested in is how to allow entities proficient in security take care of access control for resources that are owned/created by users whose main tasks have nothing to do with security.
I'll be happy to discuss more of those scenarios and that you find the rest of the document much more interesting and beneficial for the UMA work.
Really looking forward to today's telephone conversation.
From: wg-uma-bounces at kantarainitiative.org [wg-uma-bounces at kantarainitiative.org] On Behalf Of Eve Maler [eve at xmlgrrl.com]
Sent: 26 August 2009 21:46
To: WG UMA
Subject: Re: [Wg-uma] Use Case Scenarios
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
Hasan, please note my queries to you below, marked with the usual
Terminology and concept matching:
- UCAC "Security Provider (SP)" == UMA "Authorization Manager (AM)",
- 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
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.)
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,
> On Tue, Aug 25, 2009 at 11:44 PM, Maciej Machulak <m.p.machulak at newcastle.ac.uk
> > wrote:
> 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
> From: Maciej Machulak
> Sent: 20 August 2009 17:09
> To: WG UMA
> Subject: RE: Use Case Scenarios
> Not sure if my last email got through (because of attachments?), so
> here are the links to documents regarding User-Centric Access Control:
> 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
> Anyway, I hope the scenarios are helpful.
> Maciej Machulak
> PhD Student, Newcastle University
eve at xmlgrrl.com
Wg-uma mailing list
Wg-uma at kantarainitiative.org
More information about the Wg-uma