[WG-UMA] Proposed OAuth use case for signed messages

George Fletcher george.fletcher at teamaol.com
Thu Jan 27 13:11:02 EST 2011


Hi,

Here is the text that is planned to be submitted as part of the oauth 
use cases document...


      3.12.  Signed Messages


Description:

Alice manages all her personal health records in her personal health 
data store at www.myhealth.example.com. Alice's Primary Care Physician 
(PCP), which has a Web site at www.pcp.example.com recommends her to see 
a sleep specialist (www.sleepwell.example.com). Alice arrives at the 
sleep specialist's office and authorizes it to access her basic health 
data at her PCP's web site. The application at www.pcp.example.com 
verifies that Alice has authorized www.sleepwell.example.com to access 
her health data as well as enforces that www.sleepwell.example.com is 
the only application that can retrieve that data with that specific 
authorization.

Pre-conditions:

    * Alice has a personal health data store that allows for discovery
      of her participating health systems (e.g. psychiatrist, sleep
      specialist, PCP, orthodontist, ophthalmologist, etc)
    * The application at www.myhealth.example.com manages authorization
      of access to Alice's participating health systems
    * The application at www.myhealth.example.com can issue
      authorization tokens understood by Alice's participating health
      systems
    * The application at www.pcp.example.com stores Alice's basic health
      and prescription records
    * The application at www.sleepwell.com stores results of Alice's
      sleep tests

Post-conditions:

    * A successful procedure results in just the information that Alice
      authorized being transferred from the Primary Care Physician
      (www.pcp.example.com) to the sleep specialist
      (www.sleepwell.example.com)
    * The transfer of health data only occurs if the application at
      www.pcp.example.com can verify that www.sleepwell.example.com is
      the party requesting access and that the authorization token
      presented by www.sleepwell.example.com is issued by the
      application at www.myhealth.example.com with a restricted audience
      of www.sleepwell.example.com

Requirements:

    * The application at www.sleepwell.example.com interacting with
      www.myhealth.example.com must be able to discover the location of
      the PCP system (e.g., XRD discovery)
    * The application at www.sleepwell.example.com must be capable of
      requesting Alice's authorization of access to the application at
      www.pcp.example.com for the purpose of retrieving basic health
      data (e.g. date-of-birth, weight, height, etc). The mechanism
      Alice uses to authorize this access is out of scope for this use case
    * The application at www.myhealth.example.com must be capable of
      issuing a token bound to www.sleepwell.example.com for access to
      the application at www.pcp.example.com. Note that a signed token
      (JWT) can be used to prove who issued the token
    * The application at www.sleepwell.example.com must be capable of
      issuing a request (which includes the token issued by
      www.myhealth.example.com) to the application at www.pcp.example.com
    * The application at www.sleepwell.example.com must sign the request
      before sending it to www.pcp.example.com
    * The application at www.pcp.example.com must be capable of
      receiving the request and verifying the signature
    * The application at www.pcp.example.com must be capable of parsing
      the message and finding the authorization token
    * The application at www.pcp.example.com must be capable of
      verifying the signature of the authorization token
    * The application at www.pcp.example.com must be capable of parsing
      the authorization token and verifying that this token was issued
      to the application at www.sleepwell.com
    * The application at www.pcp.example.com must be capable of
      retrieving the requested data and returning it to the application
      at www.sleepwell.example.com



-- 
Chief Architect                   AIM:  gffletch
Identity Services Engineering     Work: george.fletcher at teamaol.com
AOL Inc.                          Home: gffletch at aol.com
Mobile: +1-703-462-3494           Blog: http://practicalid.blogspot.com
Office: +1-703-265-2544           Twitter: http://twitter.com/gffletch

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://kantarainitiative.org/pipermail/wg-uma/attachments/20110127/13568e42/attachment.html 


More information about the WG-UMA mailing list