...

Let's imagine a web user, Alice Adams, who doesn't mind sharing her personal travel information with the right sources as long as the process of sharing is convenient (e.g., no requirements to alert authorized recipients every time a new trip gets booked); her expectations for the uses of that information are met (e.g., she's not worried about recipients divulging to the whole world knowing when that her house is going to be empty); and she feels "in control" of what's allowed and not allowed (e.g., she can get an at-a-glance view of who's seeing what).

She uses a website called TravelIt.com (think TripIt) to store all of her travel itineraries. Since it's the nature of travel information to change frequently, she wants to be sure that her good friend Bob Baker always has the latest version so he can pick her up from the airport on time and make sure her cat is fed while she's away; he likes to use Schedewl.com (think Google Calendar) for subscribing to TravelIt. She would also like her social travel site Airplanr.com (think Dopplr) to pick up her itineraries automatically and make them available to friends who are on that system.

...

To this picture, UMA adds the possibility of a new kind of websiteweb-based application: a kind of "traffic cop" for overseeing all these instances of travel itinerary sharing, which will help Alice manage her digital footprint. We'll call this site CopMonkey.com.

...

As hinted in the introduction, UMA involves four main players:

• An Alice is an authorizing user: A a web user who gets to be in charge of authorizing access to his or her "stuff" on the web (known as protected resources)A .
• The TravelIt application acts as a host: One one of possibly many websites where the Alice's resources are stored and managed in various fashionsA requester: One of possibly many web-enabled .
• The Schedewl, Airplanr, and FrodoReviews applications act as requesters: web-based applications that seek access to the authorizing user's resources; access . Access may not mean more than just downloading or viewing, but could also include for example adding more "stuff" to be stored, or manipulating or transforming it in some other wayAn .
• The CopMonkey application acts as an authorization manager or AM: A a unified web-based control point that makes it easy for the authorizing user Alice to set up protections for all those resources at their various hosts, and to control and track access to them by requesters.

So far, this description relates only to the UMA web protocol itself. These four players are commonly referred to as "endpoints" in discussions of computing protocols (or sometimes as "entities" or "parties", but we'll avoid these in order to avoid confusion with the legal connotations of these words). Protocols define rules, and you can think of each these players as serving in a unique role with certain expectations and responsibilities, as if the rules were about soccer and governed the allowed actions of goalkeepers versus outfielders.

You might be asking, Where did Bob go? Recall that the authorizing user can make demands of the other side to judge their suitability for access. We must ask: What is the nature of the "other side"? The authorizing user is flesh-and-blood, but the AM, host, and requester endpoints are just tools. They are implemented in software, and the software is deployed in the form of networked applications and services. A tool can't be responsible for the consequences of accessing an authorizing user's "stuff". For this reason, we introduce another important player that's not strictly part of the UMA protocol:

• A requesting party: Either a legal person In our examples, Bob and the companies that run Airplanr and FrodoReviews are requesting parties: legal persons (such as corporationcorporations) , or a and real human being beings (other than the authorizing user, who uses Alice herself) who use a requester endpoint to seek authorized access to some protected resource.

We'll explore this most complex set of players more in a moment.

Finally, we need to ask: What is the nature of these "demands" and their responses? Since we're talking about web interactions, the authorizing user isn't exactly sitting across a table from the requesting party (or their legal or business representative) in real time, pestering them with questions. Rather, the authorizing user can, at leisure, configure the AM with policies that constrain the conditions for access by others. When a requester endpoint comes calling, the AM may ask them to provide a set of it to convey the following:

• A claim: An set of claims: one or more affirmative or promissory statement statements about the requesting party that are intended to satisfy some policy Alice has configured into her AM.

Now we can have enough language to begin discussing potential access authorization agreements and liability that may obtain between two parties (yes, in the legal sense) interacting in an UMA environment: the authorizing user and the requesting party.

Image Added

...

Person-to-service access: a walkthrough

...