This document is a product of the User-Managed Access Work Group. It records the scenarios and use cases governing the development of the User-Managed Access protocol and guiding associated implementations and deployments.
Intellectual Property Notice
The User-Managed Access Work Group operates under Option Liberty and the publication of this document is governed by the policies outlined in this option.
Table of Contents
Error rendering macro 'toc' : null
Introduction and Instructions
This document is a product of the User-Managed Access Work Group. It records the scenarios and use cases governing the development of the User-Managed Access protocol and guiding associated implementations and deployments, and outlines technical issues raised thereby.
Please copy and revise an existing scenario in adding new scenarios and subordinate use cases. Each scenario is created as a separate child wiki page with a name like xyz_scenario and then linked from here. Change the status keyword in each scenario and use case title as appropriate, linking to the meeting minutes page explaining the status change:
Edit the descriptions of technical issues and scope questions to reflect (or point to) group decisions about how to handle them.
Scenario: Sharing a Calendar with Vendors (Accepted)
Submitted by: Eve Maler
Online calendars are an example of personal data that is readily shared with other people in a manner that evokes VRM paradigms. Because calendar data is fairly volatile, static calendar snapshots are rarely shared; rather, a calendar feed is provided and authorized recipients can pull fresh calendar data as required. The data is often considered sensitive and is expected to be kept secure, hence "private URLs" and (minimal) ACL features offered by Google Calendar and other hosts.
In this scenario, personal online calendars are shared with "vendors" (online services) rather than other individuals, and they are shared in such a way as to allow permissioning and auditing from a central location rather than wherever the calendar is hosted. For the purposes of this scenario we'll focus on sharing a single online calendar (such as for "work", "soccer", or "travel") as a unitary Web resource, on an ongoing basis, with one or more individually-authorized recipients.
User interface mockups of a calendar-sharing interaction can be found in the initial blog post made about ProtectServe and, in somewhat more sophisticated form, slides from a speech made at an identity conference.
Following are some motivating circumstances in which calendar-sharing with vendors may make sense. (NOTE: All references to real vendors are hypothetical.)
Travel Calendar Sharing with Vendors
Alice, who is based in the Seattle area, has an online calendar that specifically contains business travel details such as flights, hotel stays, and car rentals, and since she travels quite frequently and often to international destinations, she wishes to share it with the following vendors:
Soliciting Timely Interactions from Vendors
Alice happens to work from home. Her typical work day is very busy, and she rarely has time to sit on hold when calling the various vendors in her life. She has a calendar that exposes the times during the day when she is free to accept a phone call or consider an invitation to a meeting or other event. She would like to share this information with the following vendors:
Use Case: Separate Resource Host, Relationship Manager, and Recipient (Accepted)
Submitted by: Eve Maler
The most generic possible configuration of protocol endpoints solving this scenario is to have one service hosting the calendar in question, a different service getting permissioned read access to it, and yet a different service functioning as the authorization manager, all of them "in the cloud" from the perspective of the user and all operating on the open Internet rather than on a corporate intranet (since our user is an individual acting on her own behalf). This configuration is illustrated below.
Scenario: Packaging Resources for E-Commerce Vendors (Accepted)
Submitted by: Eve Maler
This scenario focuses on the typical set of information that we hand over to online vendors repeatedly, and the desire to avoid sharing the data "by value", instead focusing on how to share it "by reference" (pointers).
Let's look at how an online buying scenario might look today.
Following are some key questions we can ask, identified by whether they capture an identity management (IdM) issue, a vendor relationship management (VRM) issue, or a social networking issue. (Note that some of these questions highlight scenarios and use cases that the calendar scenario has already captured. Some of these might want to get turned into unique use cases for this scenario.)
Maya shares the information about herself that Staplers.com needs at the beginning of her e-commerce relationship with them, but instead of having to share it "by value", she shares it as some form of pointer to a package of resource pointers that Staplers can dereference and refresh as they needs to over time. She can change the underlying information whenever she wants to without worrying about paying special attention to Staplers (or any of the other hundred e-commerce sites with which she has registered.
Use Case: Online Purchase with Setup of a Long-Running Account Relationship (Accepted)
Submitted by: Eve Maler
Preconditions: Maya has already stored, and packaged together, pointers to the set of relevant resources frequently needed for online purchases:
Use Case: Engaging in a Purchase "One-Night Stand" (Accepted)
Submitted by: Eve Maler
This is the same as the first use case outlined above, except that Maya provides her resource package not as part of a request to register a new account, but as part of a one-time purchase. (Some websites today allow for purchases without registering, and are prepared not to give you a browser cookie or retain your information beyond necessary for the purchase and its aftermath.)
The policies Maya chooses in this case are likelier to be more stringent about not retaining personally identifiable information (PII) for any significant length of time, and may ask the vendor to generate "positive" assurance messages about policy adherence (not just silent adherence).
(The protected-inbox scenario might play an especially important role if Maya is engaging in a one-night stand purchase, since it enables the vendor to report product recalls and such to Maya without her having to expose other more compromisable communications endpoints such as persistent email addresses or phone numbers.)
Scenario: Online Personal Loan request scenario (Accepted)
Submitted by: Domenico Catalano
The Economy downturn and the Financial institution crisis have introduced new needs to increase the control on loan or mortgage request process verifying user credit information and user status, in order to reduce financial risks.
Online Personal loan request is a specific use case in which a user/customer apply a request for a personal loan to a financial service.
Today, human interactions are based on online access to Financial Risk Central Service, by Financial service operator, or operator telephone call to user's bank to verify account or to the user's Employer to verify employee status, ect.
Scenario: Distributed Services (Pending)
*Submitted by:* Christian Scholz
(this text is just to describe one possible environment in which distributed or mass authorization of services is useful)
If you look at the social networking scene today one thing is obvious already: There is lot of data online on various services and much of this data is redundant because it is available in various copies which are usually not synced. The main area for this problem is probably profile and friendship/contact information. On each social network or service you register you usually have to enter your profile information again and try to find your contacts.
With the advent of more and more of such social services the amount of redundant data will grow even more and this will lead to a acceptance problem.
The Service Catalogue idea
It is unlikely that users will centralize all their data in one place. It's more likely that data will be distributed even more. So one problem might already be to manage all the places where data is stored about you or where services can provide functionality on your behalf. One solution to this might be a concept called "Service Catalogue" which came up in discussions in the open web/DiSo/DataPortability communities. The basic idea is to have a list of all these places stored under your control which can be queried by services.
Another point is that for reducing the amount of copies of your data it is necessary to link to your data instead of copying it (or even worse asking the user to type it in again). The Service Catalogue can serve basically as such a link list where each service/type of data is marked up with a location (URI) and type (probably another URI). Obvious things to link to are your profile and contact list but other things make also sense, like photos, videos, blog posts, recommendations, your attention profile, travel information and much more.
Having this catalogue you can easily tell a new service which other services you already use by simply pointing it to the Service Catalogue:
Note though that this Service Discovery is out of scope for the work at UMA and only serves as an example of how to obtain a list of services to authorize later on. Another method apparently is the user typing in various URLs which is not that user friendly though.
The result is in any case a list of services you want to authorize.
The problem is how you authorize that new service to get access to all the other 3rd party services. OAuth is one possible solution but at least if the default mechanism for retrieving a token is used this means that the user has to be redirected to each of these 3rd party services in order to give consent for the new service to use that data.
Moreover OAuth does not contain a mechanism to define what permissions should be used on the service endpoints. This can be done individually by each service but having a central place for such policy decisions and being able to store policies and share them among services might be beneficial as well.
An example for such profiles would be that you can filter which fields of your profile a PortableContacts endpoint actually gives out to a certain consumer.
For the sake of usability what we want is a single page where you can define the relationships between that new service and all the other services you have access to.
This could look like this:
Additionally a user should be able to quickly revoke tokens again in a central location as well as getting an overview of which services have access to which other services under which policies.
Scenario: Controlling Two-Way Sharing of Location Information (Pending)
Submitted by: Eve Maler
Today's location services such as FireEagle, BrightKite, and Dopplr let Alice set her location within any one of several applications, and then use OAuth-enabled connections to propagate that information through other such services. Since Alice can end up "chaining" services this way quite easily, with a thicket of pairwise connections, it's valuable for her to know and control where this information is flowing to. In this scenario, a user of HotLocale and RovingRound wants to arrange to connect them up so that her location can be propagated among them, and she wants to get a global view through her AM about who's allowed to do what, so she can change and stop permissions in a coordinated way.
Note: This scenario is not exploring anything other than person-to-self sharing. How Alice exposes her location to other people and companies should be the subject of a different scenario, as warranted.
Below is a screenshot showing that FireEagle and Dopplr have the capability today to have two-way location information flow. Our user wants to be able to see this "combinatorily", for all connected location services and indeed for all such services on the web that she chooses to use for hosting any data or content.
Assumptions and Preconditions
This scenario assumes that Alice has an account at each of AM, H1, H2, R1, and R2. These accounts might or might not be driven off of federated login, for example, Alice might log in to HotLocale through Google and RoadWarrior through Facebook.
This scenario assumes that AM, H1, H2, R1, and R2 are all UMA-enabled but have otherwise not met before. (Simplified circumstances that assume prior introduction are described in their turn below.)
This scenario assumes that H1 and H2 use a hypothetical standard location API that R1 and R2 are configured to understand, and that H1 and H2 expose APIs through URLs that differ per user in some fashion (e.g., through a URL query parameter or through a part of the URL path).
Use Case 1: Alice Sets Up AM Protection Over Location Information at HotLocale
This flow can be embedded in other flows, or can be standalone.
The identical sequence can be done with HipHappeningPlaces (H2).
Use Case 2: Alice Shares HotLocale Location Access with RovingAround and RoadWarrior
The identical sequence can be done with RoadWarrior (R2), except that once HotLocale is introduced to the AM, it never needs to be introduced again, so the optional embedded UC1 block isn't ever done again unless Alice wants to switch AMs.
Use Case 3: Alice Monitors and Controls Location Information Access from Her AM
To monitor access, Alice interacts with value-added functionality provided at the "data-sharing relationship manager" application that serves as her AM endpoint; that is, this use case does not involve standardized UMA protocol behavior. These interactions might include:
To control access, Alice may take various actions:
Scenario: Requester Delegate (Accepted)
Submitted by: Michael Hanson
The Requester may be using a hosted service, which may need to make requests on its behalf.
The user has entered a relationship with BizService, and wants to authorize it to access her calendar. BizService is using a website hosted by BizTools, which is the entity that will initiate all network activity and actually hold the tokens generated during the transaction.
The user should be able to authorize BizService to access her data, without granting any privileges specifically to BizTools, and without granting privileges to any other company hosted by BizTools.
Use Case: BizTools Impersonates BizService (Accepted)
Today, app-hosting relationships commonly involve sharing of private keys (covered by service-level agreements), and concomitant "impersonation" of the company by the outsourced service. This use case would seem to be transparent to the user (for example, if the user is given a real-time opportunity to consent to access when BizTools/BizService attempts it, the request will appear to come from BizService) and to the UMA protocol.
Use Case: BizTools Provides Its Own Network Endpoint (Rejected)
If BizTools approaches the resource not by impersonating BizService but in its own right (on BizService's behalf), true delegation would somehow have to come into the protocol picture. The goal would be to avoid creating an "omnipotent token" that allows the proximate Requester (BizTools) to use the token for access on the behalf of other parties. As discussed on 2009-10-08, we are inclined to reject this use case.
Scenario: Managing Information in Which Employers and Employees Both Have a Stake (Pending)
Submitted by: Eve Maler
Both an employer and their employees might want to impose their own constraints on the sharing of the same employee-related resource. Examples of pieces of information your employer holds that you might want to share with others:
Some additional ones listed in the Liberty ID-SIS Employee Profile Service specification:
The following “user stories” capture the distinctive aspects of this scenario:
See the use cases below for the different configurations in which the actors might appear.
Issue: In large companies, typically the function of verifying someone's employment is outsourced to a specialized company. The employer is still seen as authoritative for employment status and other such data, though. For such information, where in the use cases below the employer is assumed to be the authoritative Host, perhaps the employer needs to provides a pointer to the employer's chosen verification service resource, such that the resource being shared is a pointer to a pointer (double indirection). Or perhaps the employer instructs Alice to introduce her AM to the real Host directly.
Use Case: Employer as AM and Host (Pending)
Submitted by: Eve Maler
Here, the employer runs an employee profile self-service application that could include both AM and Host functionality. The AM could let Alice configure her sharing policies, but could also let Alice know that it will be enforcing additional constraints out of band with respect to UMA.
This is probably a “legacy” solution because it forces the employee to seek out other relationship managers in the outside world where they’re just an individual rather than an employee, and it seems the employer would be hosting the AM only for corporate inertia (admittedly, a force to be reckoned with).
Use Case: Employer as Host (Pending)
Submitted by: Eve Maler
For information for which the employer is authoritative (”Is this person employed here?”), it could offer a Host willing to attest to this on request (in accordance with the instructions issued by Alice's personal AM). If the employer doesn’t want to release the data even though the employee wants to allow the sharing, it could use existing access control mechanisms that are out of band with respect to UMA.
Issue: Should the employer-Host surface a response code to the Requester that reflects this type of refusal? Should it provide audit-log data back to the AM?
Use Case: Employer as Requester (Pending)
Submitted by: Eve Maler
For information that Alice already self-asserts to the employer (”What is the employee’s home address of record?”), the employer should ideally consume this data in the same way some other “vendor” (online service) on the open Internet could. If the employee moves, a number of workflow actions have to unroll on the employer’s side as they would have anyway (in the U.S., moving to a different state might involve withholding a different amount of state income tax), but this is already handled in existing systems when the employee provisions the new information into employee profile apps by value. An on-board “personal datastore” Host is shown here with the user’s chosen AM, but the Host could just as easily be remote.
Scenario: Delegating Access Management to Custodians (Pending)
Submitted by: Maciej Machulak
Social applications become increasingly important for a large part of the society. Young and mature Internet users participate in social networks and exchange information about their personal or professional activities. They create connections with friends or other professionals. They share their personal information and digital content using various social applications.
Young people, in particular, have little knowledge about technical complexities of those applications. They have little understanding about the value of information that they submit and share among their peers and other users of those applications. Personal information such as age, sex, telephone numbers or hobbies is often not perceived as valuable. Similarly, other digital content such as photos, short video clips or documents is viewed as any other information which can be freely available for other users of social networks.
In reality, information submitted by users of social networks may be of great value to third parties. Personal information is often used for advertising purposes or can be abused by malicious users for other purposes. Digital content, on the other hand, has influence on how a particular individual is perceived by others, be it employers or peers. As such, restricting access to information and ensuring one’s privacy is a necessity.
To prevent information leakage, parents often require having insight into what information is submitted and shared. They can then restrict publishing of sensitive information. In order to be able to control information, parents need to be given usernames and passwords. This, however, is often perceived to be too intrusive from the perspective of younger users.
In this scenario we discuss how User-Managed Access can be used to support parents with restricting information publishing by their children. We present how younger users of social networking applications can benefit from our proposal. With our scenario we show how the User-Managed Access approach allows a user to delegate access control related tasks to other entities that may have a better understanding of security requirements for resources owned by those users.
Alice, a 14 year old girl, wants to have an account on a popular social networking application - FaceSpace. She wants to create a network of her friends with whom she wants to share photos and discuss her hobbies. She wants to keep in touch with them and does not want to be left behind with new technologies that have been used by her peers for some time now.
When Alice sets up the account at FaceSpace she needs to provide a variety of information. This includes providing information about her age. When Alice states that she’s 14 then then FaceSpace detects that she is very young and informs her that she will need parental control over all the information that she submits and wishes to share with other users of the application. What this means is that an adult (legal guardian) will be able to restrict access control for information that Alice submits. However, Alice will still be able to share information if her access control rules do not contradict with those specified by her legal guardian. To set up the parental control, Alice asks her father Bob for some help.
Bob is happy that his daughter will be able to communicate with her friends but he is concerned with what information will be released and how this information might be used by legitimate or malicious users. He knows that FaceSpace has been certified to support parental control and allows third party UMA-based access control systems to be used for that purpose.
Bob is already using a specialized Authorization Manager – CopMonkey – for his own purposes. He uses this AM to define access control policies for his personal data (home address, telephone number) so that he can point other Web services to pull such data as required (e.g. during registration process at different Web sites). Moreover, he protects his online calendar service using CopMonkey and he established necessary relationships between his calendar feeds and his Visa payment service. He wants to be sure that Visa knows where Bob is and can correlate such data with data regarding his credit and debit card usage.
Bob decides that CopMonkey will be perfect for parental control over Alice's information. Therefore, he introduces this AM to FaceSpace (establishes a trust relationship between these two services). As such, he is able to restrict how different information published by his daughter is accessed by her friends or other users of the application. Bob sets up basic policies regarding sharing of such information:
When the account is set up and parental control has been configured then Alice is able to use FaceSpace just as any other user. She writes comments about her day, posts links to interesting movies. Additionally, she uploads some of her photos and short video clips. She knows that her father is very concerned with Alice's safety and the privacy of her information and that her sharing options are therefore limited. She knows that she can share the information by herself but that she cannot override higher level sharing constraints imposed by her father.
Alice uploads a photo from her birthday party and wishes to share it with some of the users of FaceSpace. When the upload is finished, she clicks on the “Share” link next to the photo and defines the users with whom the picture should be shared. Her sharing options include all of her friends and members of one of the groups that Alice participates in - "Youth Sport". She confirms her sharing choice by clicking on the "Apply Sharing Options" link.
Jane, one of Alice’s best friends, heard that a new photo from a birthday party has been uploaded and wishes to see it immediately. She logs in to FaceSpace and clicks on the Alice’s photo album link. She can see a link to the newly uploaded photo. When she clicks the link, the application detects that a request has been made to an UMA protected resource. Therefore, such access request is subject to access control by the configured Authorization Manager apart from the internal mechanisms used at FaceSpace. Jane knows nothing about UMA and does not see the underlying protocol that is being executed by FaceSpace. She is not aware of the fact that FaceSpace acting on her behalf obtains an access token from Bob's CopMonkey (meeting requirements of policy no. 1). She observes a very small delay before accessing the photo. This delay, however, is visible only when she wishes to access the photo for the first time.
Patrick does not have a connection with Alice but is a member of the "Youth sport" group. He saw that a new picture has been uploaded by one of the group members. Therefore, he clicks on a link to see the photo. Similarly to Jane's case, FaceSpace detects that a request has been made to an UMA protected resource. Therefore, such access request is subject to access control by the configured Authorization Manager apart from the internal mechanisms used at FaceSpace. Patrick gets redirected to a page presenting a short description of what just happened (i.e. that he is subject to additional access control mechanisms as defined in policy no. 2). He sees that he must agree not to distribute the photo and that is a member of the "Youth sport" group. He agrees to that happily and is redirected back to the photo hosted by FaceSpace. Just as Jane, he is not aware of any complexities of the UMA protocol and only knows that he had to agree to some simple terms. Thanks to the UMA protocol, CopMonkey collects the following claims: (a) one self-asserted by Patrick that he will not share a photo, (b) a claim certified by FaceSpace that Patrick is a member of the "Youth sport" group. Both claims are required to authorize FaceSpace access Alice's photo on behalf of Patrick.
Patrick likes the photo very much and he decides to see who Alice is. Therefore, he clicks on her "Profile" link. This access request is also subject to parental control configured for FaceSpace. In this case, Patrick is denied access which conforms to Bob's policy no. 3.
Over time, Alice learns that allowing her father to have impact on security of the resources that she shares with her friends is not a bad thing. She feels safe and knows that everything she submits to FaceSpace is secure. Over time, Alice also learns more about security and sees what information is prevented from being shared with her friends. In the future she hopes to make better security decisions by herself. At some point she'll be fully responsible for controlling access to her resources.
Her father Bob is also happy as he knows that his daughter can communicate with her friends in a safe and secure way. He checks his Authorization Manager on a daily basis and composes access control policies and defines terms as new photos and other resources are uploaded by his daughter. Moreover, he audits all access requests and sees how Alice's friends access her photos and video clips. He hasn't noticed any abuses and is confident in whatever her daughter does. After all, he's fully responsible for her privacy and security and he puts much effort into ensuring that his daughter stays safe and still enjoys the benefits of social networking on the Web.
Actors in the described scenario are as following:
The following scenario shows how a user can delegate (a part of) access control functionality to a different user. In this case, an owner of a resource decides that a different entity (a custodian) will be also responsible for security of their resources. A user is concerned with producing and submitting content on the Web and may define sharing options for such content (e.g. Alice can upload a picture and define who sees that picture). However, it is the custodian that is responsible for ensuring that such content is well protected by defining mandatory access control policies. Such MAC rules cannot be overridden by rules defined by the primary resource user (e.g. Bob may define a rule that Alice's photos can be shared with her friends only which may restrict Alice's sharing options). It is then up to the custodian what access control rules are applied effectively to resources. An Authorization Manager in such setting can be viewed as an access control module externalized from a Web application that is simply under control of a different entity. Such Authorization Manager may serve the purpose of Mandatory Access Control.
A custodian can be fully responsible for defining access control policies and may be fully separated from an owner of resources. In the described scenario, Bob could be the only entity that defines access control rules for Alice's resources and Alice would only be concerned with producing and submitting these resources to FaceSpace. In such case no direct interactions are needed between the primary resource user and an authorizing user. A primary resource user may not have any knowledge about the security that is applied to a resource. As such, he or she can focus on the main tasks related to producing a resource (e.g. writing a document, submitting a photo) and can leave applying security to those who have greater knowledge and experience in defining security rules.
In the scenario, a particular Host could only accept to establish its trust relationship with a whitelisted AM. Such AM would be able to certify that a particular Authorizing User is an adult and a legal guardian of the Primary Resource User. Bob needs to get involved in the registration process to establish a trust-relationship between FaceSpace and CopMonkey. Another option for Bob, for example, would be to get an email with the instructions concerning introducing FaceSpace to AM and to perform this introduction later. Before this happens (i.e. resources submitted by Alice are protected by an adult),
Scenario: Moving Resources Between Hosts (Pending)
Submitted by: Maciej Machulak
In a rapidly developing Web environment there is a wide spectrum of various Web applications that combined together provide users with a powerful set of features. New interesting Web applications are being offered on a daily basis by corporations, small start-ups or single developers.
As new applications are being delivered, it is often the case that Web users wish to test functionality of those applications. Often they decide that a new application meets their needs and should substitute their old application. Apart from a better functionality, an application may additionally compete on the price which plays an important role when choosing which Web application to use.
In a situation where a user decides to switch between two or more Web applications then resources need to be transferred between those applications. Most commonly, the user will need to download all resources from an old application and upload them to a new one. In some cases, tools are provided to support users with this time consuming process. However, security settings and access control policies need to be manually set up on a new Web application and cannot be reused from an old one.
When a user wishes to transfer resources from one application to another, be it manually or automatically, then the problem of access control can be easily resolved if those applications support User-Managed Access. Once resources are transferred a user may simply plug in their existing and already configured Authorization Manager to a new application. Then a user may apply already composed access control policies for the same set of resources which is hosted by a new Web application.
In the next section we present how a User-Managed Access can be used to support users when resources are moved between Web applications (Hosts). We show how our approach allows a user to compose access control policies for their resources once and apply them independently of Web applications that host those resources.
(NOTE: All references to real Web apps are hypothetical.)
Use Case: Moving Resources Between Web Applications (Pending)
Submitted by: Maciej Machulak
Caroline is using the Web mostly to share short video clips and pictures of herself with her friends. She is using YouTube and Picasa Web Albums for that purpose. She is very happy with those services and is particularly pleased with their reliability and the fact that those services are free to use for non-commercial users.
Caroline is very security conscious. She wants all of her video clips and pictures to be well protected and only accessible by legitimate users (i.e. her friends). She is fine with spending some time every week to make sure that access control policies are in place to protect her resources. She is using an Authorization Manager for that purpose. All of her access control policies are composed centrally and are applied to her resources hosted by YouTube and Picasa.
Apart from pictures and video clips, Caroline stores her documents online as well. She uses Office Live Workspace as it is integrated with her word processor. She can access her documents over the Web from almost any place in the world. She configured Office Live Workspace to delegate access control to her Authorization Manager - the same which is used for Picasa and YouTube.
After some time, Caroline decides to use a single Web application to host her pictures and video clips. However, she does not want to change the Office Live Workspace application as she finds it very good. Caroline finds a PhotoBucket service. This Web application allows storing pictures and video clips and sharing them with other users of the Web.
Caroline reads reviews on the Web and decides to try the PhotoBucket service. She creates an account on the service. She then configures her Authorization Manager to allow PhotoBucket access her resources hosted on YouTube and Picasa. The PhotoBucket service then acts as a consumer of those resources and retrieves them. Caroline does not have to be actively involved in that process and she does not have to download any of her pictures and videos from YouTube and Picasa and upload them to PhotoBucket by herself.
The PhotoBucket service supports a User-Managed Access so Caroline configures it to use her already tested Authorization Manager. By default, all newly uploaded resources to PhotoBucket are made private. However, Caroline logs in to this service and clicks on the Administration option. She is then presented with a menu where she can perform various administration tasks. Among all of the options she can choose to apply security to all of her resources. Once she clicks on that option, the PhotoBucket contacts her Authorization Manager so that policies can be applied to resources hosted by this application.
Typically, when Caroline defines access control rules for her resources (i.e. pictures, video clips and documents), she logs in to the application that hosts those resources and clicks on an Access Control link next to a resource. She is then redirected to an Authorization Manager of her choice. Under the hood, the application contacts the Authorization Manager with information about the resource and operations supported by this resource. When Caroline is redirected to her Authorization Manager then she sees that it waits to compose an access control policy for this resource. She uses the interface of her AM to specify access control rules that will be later applied to this resource.
In the following case, however, Caroline does not click on the Access Control link. Instead, she clicks on a link to apply security for all of her resources. Similarly, she is redirected to her Authorization Manager and sees that a group of resources waits for policies to be specified. Her AM detects that access control policies were previously applied for those resources and informs Caroline about that. What she needs to do at this moment is to confirm that those policies can be reapplied. Once she does that, her resources remain protected in the same way when those resources were hosted by YouTube and Picasa Web Albums.
The architecture for a User-Managed Access for the provided scenario is depicted below.
A user delegates access control for a set of resources from a Web application to an Authorization Manager. If a user decides to move this set of resources from one application to another then the same set of policies can be reapplied to those resources at the new application. Policies stored and evaluated by an Authorization Manager are therefore application agnostic. A user is able to define access control rules to resources independently of the application that hosts those resources.
View of the actors presented in this scenario with regards to the generic architecture of a User-Managed Access is depicted below. Presented diagram shows an Authorization Manager (1), a User (2), a set of Hosts (3), Requesters (4) and a Resource (5).
An access control policy protects resources independently of Web applications (Hosts). As such, if a resource is moved from one application to another application, the same access control policy can be easily reapplied.
The following scenario shows how a user is able to reapply already composed access control policies to resources if those resources are transferred from one Web application to another Web application. Typically, in such situation it would be necessary to define access control policies from scratch or to transform policies from one application to the format used by another application. However, in case of a User-Managed Access where policies are stored in a central location, it is possible to simply apply those policies to the same set of resources that is hosted by a different Web application.
Reapplying an access control policy to a set of resources does not differ much from applying a single policy to a resource hosted by a Web application. Typically, when a user creates a resource on the Web and wants to protect it then a Web application contacts an Authorization Manager so that either a new access control policy can be composed or an already defined policy can be applied. In a situation where a resource is transferred from one application to another, the new application perceives such resource as newly created. Therefore, this new Web application contacts an Authorization Manager as usual. It is an Authorization Manager that detects that a policy for this resource has been previously defined and applied. Therefore, this Authorization Manager proposes to reapply the same policy to protect this particular resource.
An important issue that needs to be resolved in the discussed use case is the possibility of having different operations that are supported by different applications for the same type of resources. An example of that is when one application allows downloading, writing, deleting and shrinking a picture while another application allows downloading, writing, deleting and transforming pictures. When an application contacts an Authorization Manager it sends information about a resource along with operations supported on this resource. An Authorization Manager may detect that a policy has been already specified for such resource and may propose such policy to be reapplied. However, a set of operations described by a new Web application may differ from the set of operations that are defined in a security policy. This can be either a subset of original operations, a superset of those operations or a different set of operations.
If a new Web application supports only a subset of operations that were originally supported by the previous Web application, then rules for those operations that exist in an access control policy are simply removed. In case a new application supports a superset of operations then all rules from an access control policy are retained. New rules for newly supported operations can be easily added to the policy. In case the set of operations differs from the operations as defined in an access control policy, a human intervention may be required to map names of old operations to the names of new operations.
Following are discussions of technical issues raised by one or more scenarios and use cases. Acceptance of a scenario or use case will imply agreeing to develop a satisfactory solution to applicable issues.
Issue: Policies Specific to the Web Resource Type
There is a potential need to restrict, anonymize, blur, or otherwise transform a shared resource, possibly based on the unique characteristics of its content type.
With respect to calendar resources, the premier calendar format standard already accounts for a blurring of data details by providing a "free/busy" option in addition to a full-data option. It feels like it should be out of scope to solve for filtering the calendar data cleverly (beyond the format's natural capabilities) to hide Alice's destination, hotel, etc. (though generic solutions such as making events taggable, and then filtering on the tags in a relationship manager interface, come to mind). An "identity oracle" approach (filtering the data into a completely different type) might be necessary if what Alice is trying to convey is simply "don't deliver my newspaper on these days" vs. "here's all of my travel information".
In the Controlling Two-Way Sharing of Location Information scenario, note that FireEagle allows a user to choose to share locations only at the city level, and this level happens to be chosen for the connection that authorizes Dopplr to read the FireEagle location (a different level can be chosen for each application that reads location from FireEagle). As it happens, Dopplr does not offer the same policy capability. Without having to teach UMA generically about all the possible policy options specific to all the kinds of information in the world, is it possible for each Host to teach each AM about the policy options it offers, in some way that lets the the relationship manager application surrounding the AM present user interface options to see and select these policies? Seeing may have less protocol impact than selecting, and seems to be a minimum value-add if the goal is to allow OAuth users to get a global view.
Some data-usage policies and terms may possibly have an interaction with some resource types, such as requiring recipients to discard volatile data after a period dictated by the data's type.
It has been observed that if fine-grained calendar filtering were a solved problem, different calendar sites could be shared with different friends as a way of managing minimal disclosure through indirection.
Issue: Authorization Manager Endpoint Discovery
The mockups linked in the calendar scenario imagine that the user's authorization manager endpoint (what we imagine Alice will perceive as the name of her relationship management service) will be handled as if it were an OpenID, with introductions to popular relationship manager services offered in an array by potential UMA Hosts much in the way that the RPX solution presents options. (The user always has the ability to self-host an authorization manager endpoint, similarly to self-hosting an OpenID provider – and they might even be colocated.)
Issue: Handling the Resource URL and Provisioning It to the Consumer Site
The mockups linked in the calendar scenario imagine the simplest possible situation: The Consumer site literally asks for exactly the kind of information it needs, and the user copies and pastes a URL into a field.
This is how calendar feeds, photo streams, RSS feeds, and other such resources are shared today; it works but we need to consider its scalability to arbitrary types of information. There are several challenges here: The Consumer's ability to handle the information, its way of expressing the desire/need for the correct information, and the user's (or user agent's) ability to provide it in a convenient and correct fashion.
In addition, the relationship manager interface is shown having some knowledge of that resource as a unique object. We need to consider how to let the AM and SP communicate about this information appropriately.
In the case of the photo set scenario, note that in OAuth usage today, the resource-based interaction is often accomplished silently from the user's perspective: the desired combinatorial effect simply "happens" as if the feature that was "outsourced" to a third-party app were native. Perhaps this is possible in the UMA approach.
Issue: How Terms can be Met
An AM has two major tools at its disposal in allowing access to a user's resources: policies declared by the authorizing user, and terms which the Requester must meet in order to gain access. To a first approximation, policies can be unilaterally applied, whereas terms require two parties to come to agreement.
Because policies are anticipated to be applied by an AM "silently" (out of band) with respect to the UMA protocol, this is an opportunity for AM business value and we should not dictate any answers here. But following are some policies that could be useful:
By contrast, terms might take some of the following forms:
The following hypothetical wireframe (with hypothetical Creative Commons-like sets of standard terms) imagines what a user interface could look like for an AM's default policy and term settings for all resources it manages:
The UMA group is hoping to borrow from the work of others in using any standard sets of terms that might exist, for example as might be developed by the Kantara Information Sharing (UD-VPI) WG. However, even if this area is well fleshed out, major design questions remain.
Human interaction by a party "behind" the Requester
Some parties behind a Requester's actions may be big companies like credit card issuers, large e-commerce sites, or government agencies – but some may be small organizations, such as a dentist's office. Small organizations may need a human-accessible interface and the option of an "I Agree" button so that the person manually fielding an offer of data can complete the transaction.
Requester resistance to user-driven terms
It may be necessary for us to consider "partial measures" in the V1 UMA effort to improve adoption. For example, it may be more difficult to demand evidence of positive action (such as payment) from a Requester vs. demanding a simple statement of passive acceptance of terms (such as "I agree not to sell the data"). This would be a natural first step if Requesters are at all amenable to the notion of user-driven terms.
If we discover that Requesters are resistent, we may need to consider options for allowing the user to passively inform the Requester of policies such as "I ask you not to sell this data", rather than requiring action on the part of the Requester to accept such terms. Or given that Requesters are today in the habit of making their own terms of service and privacy policies known to users in passive fashion, we may need to account for a case where the user's terms amount to an opening gambit of "What can you offer me?" in a contract negotiation.
Depth of contract negotiation
There is some minimum functionality needed around a sequence roughly like the following:
However, there are many layers of sophistication we could get into, depending on where our scenarios take us. For example, is it important for the user to be able to specify "you must satisfy these terms 'or better'"? If so, what does "better" mean? Do we have to solve for "I will sell you n pieces of data for terms X, but n+m pieces for terms Y"?
Legal enforceability and terms persistence
We have discussed whether machine readability of terms is strictly needed, since having a URL that persistently refers to a human/lawyer-readable version seems to suffice in a lot of cases today for string-matched satisfaction (no complex negotiation), including very complex enterprise cases. Nat Sakimura's blog post on contract exchange suggests various ways to characterize, share, negotiate, and record data-sharing contracts. How we answer these questions also has an impact on our goals around simplicity, particularly our emerging goal around not adding undue cryptography burdens.
Paul Bryan has stated a preference expressing a set of terms as a Web resource whose representation can be retrieved with an HTTP GET and modified (with an affirmation that the terms are being met) with an HTTP POST.
Is this site useful to you? Please share it!
| | More
Pages in this Space:
You are viewing an old version of this page. View the current version. Compare with Current · View Page History