Scenario: Advertising a Resource to Arbitrary Potential Requesters (Pending)
(This is colloquially known as the "Hey, Sailor" scenario.)
While a resource may be sensitive and in need of protection against unauthorized access, the URL for the resource need not always be sensitive. An interesting way to provision a resource's URL to requesters is to advertise it directly – for example, on a blog or in a tweet. This may make sense in cases where the authorizing user has not yet met all the parties who may be interested in requesting access, or if the population of potential requesters is very large. When a person publishes URLs in this way, the act of publication functions as a "discovery service" for those resources.
Following are three specific circumstances in which advertising a resource widely may make sense. In all cases, terms negotiation becomes a key "line of defense" for authorizing access; see the scenarios specific to terms negotiation later in this document for more detail.
Sharing Exclusively with Family and Friends
Authorizing user Roxy wants to share her blog posts and song recordings only with family and friends. She publishes her posts and songs in feeds that are accessible only to those who can prove they are her family and friends, as she knows them through interactions on Twitter and Facebook and other social sites. (See the Requester Identification terms negotiation scenario to see details on how this access control scenario might work.) She also requires requesters to agree not to share this material further.
The feed URLs are available in the clear on her website, so that she can tell her loved ones simply to visit allaboutroxy.com to find the relevant links. But when they try to click on the links, they are routed to an interaction that requires them to prove their identity to her and to agree to her sharing terms.
In this case, each of her loved ones is a requesting party, working through some requester intermediary (such as Google Reader or Songbird) that helps them access her protected resources, which hosted either on her blog or elsewhere.
Sharing Resources on a Commercial Basis
Authorizing user Selma is an accomplished photographer, and she offers her photographs at full resolution for sale to any requester who can produce a receipt for US$10. The photographs are available at low resolution on the site, with the URLs of the full-size photographs advertised. When a potential photo purchaser tries to "hit" a full-size photo, they are told of the requirement for successfully getting the photo and given the opportunity to comply.
Sharing Personal Requests for Proposals (PRFPs)
When authorizing user Dirk's coffee maker dies, he constructs an online personal RFP (a description of his parameters and constraints for an acceptable replacement coffee maker, including height, capacity, basket style, price, and so on), hosted at a site that specializes in PRFPs that he has already registered with his AM.
One of the host site's services is to get his PRFP seen by various online retailers, and he might also tweet the PRFP. The online retailers will need to register with his AM as requesters in order to both see the PRFP and to supply a coffee maker proposal in a special inbox also hosted by the same site. Each proposal could contain an "offer URL" that allows Dirk to take advantage of each deal directly on their site, or could give other instructions on how he can get the deal.
Preventing Denial-of-Service Attacks on a Resource
Authorizing user Reed has a popular documentary blog where he exposes corruption and budgetary malfeasance in his home state, which he is happy for anyone to visit. However, the subject of his writing has made him collect some high-powered enemies. Some of them want to try to shut him down by flooding his blog and his comment threads with Denial-of-Service attacks. So Reed configures his AM to require that all requesters "prove their sincerity", in effect, by performing proof of work.