ProtectServe draft protocol flows

In previous posts I’ve described the basic ProtectServe/Relationship Manager proposition and use cases. Here is a set of web protocol flows we’ve developed to support our goals. This design is definitely not fully baked, but we hope it’s suggestive and that it generates some useful feedback.

Keep in mind that the mockup screenshots shared earlier illustrate a lot more than just bare protocol interactions. In the flows below, dotted-line arrows reflect steps outside the protocol per se, and each one of those arrows hints at lots of activity that lives in the “application value-add” world rather than the “interoperable protocol” world.

The Players

The User (working through a User Agent) is involved in the protocol per se at two key points: personally introducing the Authorization Manager and Service Provider, and optionally exercising a “right of refusal” in agreeing to a contract to release data to a requesting Consumer. In addition, the User has several duties, like policy-setting, that take place out of band. In our mockups, the User is Alice Adams.

The Authorization Manager (AM) is the hub that keeps track of the User’s registered Service Providers and all of the Consumer services that attempt to retrieve User data. It also applies the User’s policies to this retrieval. In our mockups, the AM Alice has chosen is CopMonkey.

The Service Provider (SP) is a service where the User goes to create and maintain some content that she may want to share selectively. The SP gets introduced to the User’s desired AM and thereafter knows where to send authorization requests before releasing data to Consumers. In our mockups, the SP is an online calendaring service called Schedewl.

The Consumer is a service that tries to retrieve some of the User’s data (in the form of a web resource, which may itself reference many other resources that are possibly unprotected or served out of other SPs), on a one-time or ongoing (i.e. feed) basis. Before it can retrieve the data successfully, it needs to meet the contract terms that the User has chosen to demand for that resource. In our mockups, the Consumer is the 3rd National credit-card site, asing for Alice’s travel calendar.

The Steps

There are four steps, which we have numbered in zero-based fashion (natch). The links are to WebSequenceDiagram.com flows. This tool rocks!

  • Step 0: User introduces SP (Schedewl) to AM (CopMonkey) – done once per SP/AM pair
  • Step 1: AM (CopMonkey) provisions consumer key and access token to Consumer (3rd National) – done once per AM/Consumer pair
  • Step 2: Consumer (3rd National) meets contract terms for access to resource (residing at Schedewl) – done if Consumer hasn’t yet met terms
  • Step 3: Consumer (3rd National) is granted access to resource (at Schedewl) by AM (CopMonkey) – done every time

I’m putting the actual flow diagrams below the fold because they blow out my margins. Note that you may not be able to see all of the pretty swim-lane pictures inline, depending on what browser you use; in that case, click on the step links above. [UDATE: Or if you’re reading this post in a feed, try going to the real web page.]

Step 0: User introduces SP to AM

participant "User agent"
participant "Authorization manager"
participant "Service provider"
participant "Consumer"
note over "User agent", "Consumer"
Step 0: Introduce service provider to authorization manager (V2009.03.30.1)\nDotted-line steps take place outside this protocol.
end note
User agent-->Service provider: Provide authorization manager metadata URL (via HTTP)
activate "User agent"
activate "Service provider"
Service provider->Authorization manager: GET authorization manager metadata
activate Authorization manager
Authorization manager->Service provider: Policy decision resource, consumer key issuer, \nrequest token issuer, access token issuer
deactivate Authorization manager
note over "User agent", "Consumer"
Service provider acts below as anonymous OAuth consumer, per OAuth unregistered consumer profile.
Authorization manager in turn as an OAuth service provider.
end note
Service provider->Authorization manager: POST request service provider handle
activate Authorization manager
Authorization manager->Service provider: 401 unauthorized\n(protection realm matches metadata)
deactivate Authorization manager
Service provider->Authorization manager: Request OAuth request token
activate Authorization manager
Authorization manager-->Authorization manager: Allocate request token (unauthorized)
Authorization manager->Service provider: Request token "rt"
deactivate Authorization manager
Service provider->User agent: Redirect user agent to authorization manager to authorize request token "rt" (w. callback URL)
deactivate Service provider
User agent->Authorization manager: Request authorization consent page (w. "rt")
activate Authorization manager
Authorization manager->User agent: Return authorization consent page
deactivate Authorization manager
deactivate User agent
User agent-->User agent: Authorize
User agent->Authorization manager: Authorize request token (w. "rt")
activate User agent
activate Authorization manager
Authorization manager-->Authorization manager: Change status of request token "rt" to authorized
Authorization manager->User agent: Redirect user agent to callback URL
deactivate Authorization manager
User agent->Service provider: Callback to confirm that request token is authorized
activate Service provider
Service provider->Authorization manager: Request access token (w. "rt")
activate Authorization manager
Authorization manager-->Authorization manager: Allocate access token
Authorization manager->Service provider: Access token "sat" and secret "sats"
deactivate Authorization manager
Service provider->Authorization manager: POST request service provider handle\n(w. "sat" and signature using "sats")
activate Authorization manager
Authorization manager-->Authorization manager: Allocate service provider handle
Authorization manager->Service provider: Service provider handle "sph"
deactivate Authorization manager
Service provider-->User agent: Connection to authorization manager successful
deactivate Service provider
deactivate User agent
User agent-->Authorization manager: Configure policies (optional)
activate User agent
activate Authorization manager
deactivate Authorization manager
deactivate User agent

Step 1: AM provisions consumer key and access token to Consumer

participant "User agent"
participant "Authorization manager"
participant "Service provider"
participant "Consumer"
note over "User agent", "Consumer"
Step 1: Provision consumer key and access token to consumer (V2009.03.30.1)\nDotted-line steps take place outside this protocol.
end note
Consumer-->Consumer: Need to access resource "r"
Consumer->Service provider: GET "r"
activate Consumer
activate Service provider
Service provider->Consumer: 401 unauthorized; protection realm "pr";\nlocation of protection realm metadata
deactivate Service provider
opt consumer doesn't have access token
Consumer->Service provider: GET protection realm "pr" metadata
activate Service provider
Service provider->Consumer: Protection realm "pr" metadata\n(incl. authorization manager location\nand service provider handle "sph")
deactivate Service provider
end
opt consumer doesn't have consumer key
Consumer->Authorization manager: POST request consumer key
activate Authorization manager
Authorization manager-->Authorization manager: Allocate consumer key
Authorization manager->Consumer: Consumer key "ck" and secret "cks"
deactivate Authorization manager
end
opt consumer doesn't have access token
Consumer->Authorization manager: POST request access token\n(w. "sph", "ck" and sign using "cks")
activate Authorization manager
Authorization manager-->Authorization manager: Verify signature "cks"
Authorization manager-->Authorization manager: Allocate access token and secret
Authorization manager->Consumer: Consumer access token "cat" and secret "cats"
deactivate Authorization manager
deactivate Consumer
end
note over "User agent", "Consumer"
Note: This protocol deviates from OAuth, in that consumer key is intended only to acquire
access tokens, and is not used for subsequent authentication of resource requests.
end note
note over "User agent", "Consumer"
Implementation note: Authorization manager should take steps to prevent denial of service
attacks from spurious consumer key and access token requests.
end note

Step 2: Consumer demonstrates that it meets terms for access to resource

participant "User agent"
participant "Authorization manager"
participant "Service provider"
participant "Consumer"
note over "User agent","Consumer"
Step 2: Consumer to meet requisite terms and conditions for access to resource (V2009.03.30.1)
Dotted-line steps take place outside this protocol.
end note
Consumer->Service provider: GET "r" (w. "cat" and sign w. "cats")
activate Consumer
activate Service provider
opt Service provider hasn't seen "cat" access token
Service provider->Authorization manager: GET shared secret for "cat"
activate Authorization manager
Authorization manager-->Authorization manager: Validate "cat" is for service provider
Authorization manager->Service provider: Access token shared secret "cats"
deactivate Authorization manager
Service provider-->Service provider: Store "cats" for future requests
end
Service provider-->Service provider: Verify signature using "cats"
Service provider->Authorization manager: GET policy decision for "r"\n(w. "cat", "sat" and sign w. "sats")
activate Authorization manager
Authorization manager->Service provider: Deny; location of terms "lt"
deactivate Authorization manager
Service provider->Consumer: 403 forbidden; location of terms "lt"
deactivate Service provider
Consumer->Authorization manager: GET "lt" (w. "ck" sign w. "cks")
activate Authorization manager
Authorization manager->Consumer: Terms and conditions "t"
deactivate Authorization manager
Consumer-->Consumer: Evaluate terms
Consumer->Authorization manager: POST claims to meet to terms "t" (w. "ck" and sign w. "cks")
activate Authorization manager
Authorization manager-->Authorization manager: Evaluate claims
Authorization manager-->Authorization manager: Create agreement resource
opt
Authorization manager-->Authorization manager: Notify user of pending agreement
end
Authorization manager->Consumer: Location of agreement resource "a"
deactivate Authorization manager
opt Loop: pending agreement status
Consumer->Authorization manager: GET "a" (w. "ck" and sign w. "cks")
activate Authorization manager
Authorization manager->Consumer: Agreement (status: pending)
deactivate Authorization manager
end
opt Real-time consent process
User agent-->Authorization manager: User consent for agreement
activate User agent
activate Authorization manager
Authorization manager-->Authorization manager: Accept agreement
deactivate Authorization manager
deactivate User agent
end
Consumer->Authorization manager: GET "a" (w. "ck" and sign w. "cks")
activate Authorization manager
Authorization manager->Consumer: Agreement (status: accepted)
deactivate Authorization manager
deactivate Consumer

Step 3: Consumer is granted access to resource by AM

participant "User agent"
participant "Authorization manager"
participant "Service provider"
participant "Consumer"
note over "User agent","Consumer"
Step 3: Consumer granted access to resource by authorization manager (V2009.03.30.1)
Dotted-line steps take place outside this protocol.
end note
Consumer->Service provider: Get "r" (w. "cat" and sign w. "cats")
activate Consumer
activate Service provider
Service provider-->Service provider: Verify signature using "cats"
Service provider->Authorization manager: Request policy decision for "r"\n(w. "cat", "sat" and sign w. "sats")
activate Authorization manager
Authorization manager->Service provider: Allow (w. cacheable duration)
deactivate Authorization manager
Service provider-->Service provider: Cache allow response (optional)
Service provider->Consumer: 200 OK (resource)
deactivate Service provider
deactivate Consumer
opt Utilize cached decision
Consumer->Service provider: Get "r" (w. "cat" and sign w. "cats")
activate Consumer
activate Service provider
Service provider->Consumer: 200 OK (resource)
deactivate Service provider
deactivate Consumer
end

Tags:

3 Comments to “ProtectServe draft protocol flows”

  1. Mark Dixon 2 April 2009 at 9:00 pm #

    I propose in my blog post that the ID HAT (Have a Token) concept be added to the protocol. :)

    http://blogs.sun.com/identity/entry/have_a_token_id_hats

  2. […] Pushing String » ProtectServe draft protocol flows (tags: protectserve evemaler protocol usescenarios) […]

  3. […] a nutshell, an RM is an application, and an AM is a ProtectServe protocol entity. An RM at a minimum has to serve as an AM endpoint but could also provide SP and even […]