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

Alan Karp alanhkarp at gmail.com
Fri Jan 28 18:38:54 EST 2011


(Forgive me if I'm jumping into the middle of an ongoing discussion.
I'm just starting to catch up after being busy with my actual job.)

An interesting use case, but it doesn't cover a second level of
sharing.  Perhaps www.sleepwell.example.com is a broker for
contractors that do the actual work.  As described here,
www.sleepwell.example.com has two ways to get the job done.  The first
is to read Alice's data and forward it to sleepcontractor.example.org.
 The second is to share its private signing key with
sleepcontractor.example.org  Neither is particularly attractive.  The
first means that www.sleepwell.example.com, which has no need to see
Alice's data, must see it in order to forward it.  The second has the
effect of allowing sleepcontractor.example.org to sign for
www.sleepwell.example.com.

These problems wouldn't arise if the bearer token was the only proof
of authorization required.  Then www.sleepwell.example.com could
forward the token to sleepcontractor.example.org, and
sleepcontractor.example.org could access the data directly.  Alice
will hold www.sleepwell.example.com responsible for the access to her
data using this token.  It's up to www.sleepwell.example.com to
penalize sleepcontractor.example.org for any violations.

There is no loss of security.  Alice has no way to prevent
www.sleepwell.example.com from getting her data to
sleepcontractor.example.org by proxying requests or credential
sharing. Making the second level of sharing hard hurts Alice's privacy
(first solution) or www.sleepwell.example.com's security (second
solution).

There is a general principle behind all of this, the distinction
between "permission" and "authority,"  which is nicely described in
"Paradigm Regained" (http://www.erights.org/talks/asian03/).
Basically, what's described in the write-up grants
www.sleepwell.example.com "permission" to access Alice's data.
www.sleepwell.example.com uses its permission and behavior to grant
sleepcontractor.example.org "authority" to read Alice's data.  Who
gets to do what depends on authority, not just permission.

--------------
Alan Karp



On Thu, Jan 27, 2011 at 10:11 AM, George Fletcher
<george.fletcher at teamaol.com> wrote:
> 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
>
> _______________________________________________
> WG-UMA mailing list
> WG-UMA at kantarainitiative.org
> http://kantarainitiative.org/mailman/listinfo/wg-uma
>
>


More information about the WG-UMA mailing list