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
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