[Wg-uma] Use Case Scenarios
eve at xmlgrrl.com
Thu Aug 27 07:46:47 PDT 2009
Responding in turn... (This is fun. :)
On 27 Aug 2009, at 5:08 AM, Maciej Machulak wrote:
> Hi Eve,
> 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.
I had great hopes for getting through the whole thing, but felt I
needed to "start at the beginning"!
> 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.
As Iain's recent message points out, we need to have The Big
Terminology Conversation. And I would ideally like to align with the
terms that OAuth is moving towards, if possible, so e.g. if they stick
with Service Provider, I want to as well. The one where we have a big
choice (constrained to have a different acronym than the others :-) is
Authorization Manager, and I do want to discuss how the "relationship
manager application" concept fits in as well. My brain needs some
name for the overall application, but I realize how confusing it is,
given that even I get confused when I try to decide between the
endpoint name and the app name when speaking/writing.
> 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?
If you take a look at DataPortability.org (Christian S. on our calls,
and possibly others, represent them), you'll see that they have a goal
of ensuring a user's data can "escape" a hosting site without loss. I
like the idea of eventually having standard forms for audit logs and
such, so that (at a minimum!) "Export" and "Import" menu items in a
relationship manager could have significant meaning.
> 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.
Ah yes, I see. Yes, it's very useful to have this highlighted. This
has been the intent of the ProtectServe work to date as well. The
question I'd like to explore through a scenario on this topic is: In
V1, do we want to let a user carve out *subsets* of resources at the
same service provider to be protected by *different* authz managers?
For simplicity, in ProtectServe to date, we just said no. There are
protocol implications to allowing this: AM<->SP communications about
"manifests" of resources in scope. But maybe we need to solve for
that for other reasons anyway...
> 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.
This definitely deserves more of a drill-down in discussion --
probably not today, given our full agenda, but I hope we can iron out
the simplest and most basic scenarios first, and your simpler ones are
really helpful to that end! This is the first scenario of yours that
goes beyond the "simple" category. I'm still not sure about scenarios
for a single party wanting to apply policies of different "strengths"
through AM chaining (not meaning to imply a particular solution with
this word, but it just seems apropos), but I'm certainly willing to be
eve at xmlgrrl.com
More information about the Wg-uma