[Wg-uma] Newcomer questions, please be patient...

Paul C. Bryan email at pbryan.net
Thu Sep 24 08:48:23 PDT 2009


Hi Tom:

Welcome!

One of the objectives in UMA is to separate the point of policy decision
from the point of policy enforcement. So, in the calendar example, the
user tells the host (the calendar application and/or middleware/filter
in front of it) what authorization manager (policy decision point) to
use, and the host enforces policy decisions made by authorization
manager.

This lets me as a user trust one or more disparate authorization
managers to manage my access control policies, and have my resources
distributed, hosted by multiple service providers.

The planned protocol—so far at least—is relatively simple once token
issuance is out of the way: the host asks authorization manager for
policy decisions based on who is asking for what access to what
resource. The protocol intentionally does not address how policies are
expressed. I personally believe that how policies are expressed,
profiled and enforced are areas where implementors can and should be
able to innovate and compete.

So, while "access profiles" (a term I think describes what you're
looking for) are not an explicit part of the protocol, implementors of
an authorization manager should certainly be able to build such
functionality in.

I hope that answered your question?

Paul

On Thu, 2009-09-24 at 08:21 -0700, Holodnik, Tom wrote:
> Folks,
> 
>  
> 
> I’ll admit to being a newbie to the group and still catching up with
> the body of work to date.  I’d like to review the scenarios a bit
> more, but had a couple of comments that perhaps you could help me
> with… 
> 
>  
> 
> I had thought of certain aspects of the scenarios a little
> differently.  It’s possible that a Calendar application could have
> very different access policies and terms of use requirements for
> different markets.  The same underlying calendar logic can be applied
>  for a car repair shop with service bays, an office building with
> conference rooms, or a medical office with examination rooms.  
> 
>  
> 
> -         There’s nothing really confidential about the work being
> done within a service bay at a car repair shop.  
> 
> -         There may be confidential materials associated with one
> conference room for one meeting at some time.  
> 
> -         Everything should be confidential about what goes on within
> an examination room at a clinic.  
> 
>  
> 
> One approach would be to design and implement for the medical case,
> and then “dumb down” to suit the car repair scenarios.  It would be
> nice to be able to start with the simple cases and “wise up” to the
> medical case in an orderly way. In most cases today, each of the three
> applications is a separate product, marketed differently, and built
> differently. In most cases, the access controls and protections on
> content (like encryption in storage) are hardwired.
> 
>  
> 
> In each case, we would prefer to logically connect some representation
> of user access preferences with the container-based access controls
> available within the application.  This way, the differences between
> the 3 classes of applications might be a difference in configuration
> and not a difference in code.  The ideal would be for the user to
> select the configuration that best suits their market and
> requirements. 
>  
> 
> Does this match the high-level view of what UMA is intending to
> accomplish?  Sorry if I’m re-treading old ground. 
> 
>  
> 
> Thanks,
> 
> -tom
> 
>  
> 
> Tom Holodnik| Corporate Information Security| Intuit |
> Office: 650-944-5494 | Cellular: 650-387-6574
> 
>  
> 
> 
> _______________________________________________
> Wg-uma mailing list
> Wg-uma at kantarainitiative.org
> http://kantarainitiative.org/mailman/listinfo/wg-uma_kantarainitiative.org




More information about the Wg-uma mailing list