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

[George Fletcher]

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....@teamaol.com
AOL Inc.                          Home: gffl...@aol.com
Mobile: +1-703-462-3494           Blog: http://practicalid.blogspot.com
Office: +1-703-265-2544           Twitter: http://twitter.com/gffletch

[Alan Karp]

(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

> _______________________________________________
> WG-UMA mailing list
> WG-...@kantarainitiative.org
> http://kantarainitiative.org/mailman/listinfo/wg-uma
>
>
_______________________________________________
WG-UMA mailing list
WG-...@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/wg-uma

[George Fletcher]

Hi Alan,

Some comments inline. I totally understand being "busy with my actual job"... I'm particularly swamped right now:)

On 1/28/11 6:38 PM, Alan Karp wrote:

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

You are correct. I was not trying to solve that level of delegation. The main purpose of this use case is to show the value of signatures to OAuth (something that hasn't been excepted unanimously by the OAuth community:).

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.

My problem with bearer tokens is that you lose the chain-of-trust. If www.sleepwell.example.com just passes its authorization token to sleepcontractor.example.com, then the access by sleepcontractor.example.com is indistinguishable from the access my www.sleepwell.example.com. In certain use cases, this is not acceptable. Also, if sleepcontractor.example.com is compromised, then the attacker can use any of the bearer tokens that it finds with out also having to find the corresponding token.

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

It is true that www.sleepwell.example.com could get all necessary data and then pass it along to sleepcontractor.example.com (or use credential sharing). I'm not sure I follow why what's described "hurts" Alice's privacy. Alice is releasing her information to www.sleepwell.example.com not to sleepwell's contractor.

If I have a contract with a brokerage firm or bank and they sub-contract out the handling of my account with some other company, I currently don't have any control over that other than to switch brokerage firms. When I give my SSN to the brokerage firm, they may give the data to a contractor, but the "contract" or implicit agreement is between me and the brokerage firm.

I would rather a model where www.sleepwell.example.com would request scoped tokens for it's contractors such that the token explicitly identifies the contractor and it's relationship to www.sleepwell.example.com. This keeps the relationships clear as data traverses amongst the different servers.

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.

I'm fine with this model as long as www.sleepwell.example.com explicit requests a special token (based on it's granted permission) for each contractor that provides that contractor with just the authority that it needs. I believe that in certain use cases, it must be possible to prove that the token presented is presented by the party it was issued to. A bearer token does not carry this semantic.

Thanks,
George

[Alan Karp]

Comments on your inline comments inline :)

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

On Mon, Jan 31, 2011 at 5:27 PM, George Fletcher <george....@teamaol.com> wrote:

Hi Alan,

Some comments inline. I totally understand being "busy with my actual job"... I'm particularly swamped right now:)

On 1/28/11 6:38 PM, Alan Karp wrote:

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

You are correct. I was not trying to solve that level of delegation. The main purpose of this use case is to show the value of signatures to OAuth (something that hasn't been excepted unanimously by the OAuth community:).

The problem is that your proposal blocks that level of delegation.  It's like having a programming language with one level of function calling. 

I'm not opposed to signatures.  They are useful to prevent tampering with the request when using bearer tokens (but so does using https).  However, your proposal goes beyond that, making useful functions more difficult to implement.

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.

My problem with bearer tokens is that you lose the chain-of-trust. If www.sleepwell.example.com just passes its authorization token to sleepcontractor.example.com, then the access by sleepcontractor.example.com is indistinguishable from the access my www.sleepwell.example.com. In certain use cases, this is not acceptable. Also, if sleepcontractor.example.com is compromised, then the attacker can use any of the bearer tokens that it finds with out also having to find the corresponding token.

Actually, bearer tokens provide the right level of responsibility tracking.  Alice will hold www.sleepwell.example.com responsible for all uses of the token she gave it.  It's up to www.sleepwell.example.com to hold sleepcontractor.example.com responsible. 

You get the same protection from compromise by encrypting your bearer tokens when storing them.  

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

It is true that www.sleepwell.example.com could get all necessary data and then pass it along to sleepcontractor.example.com (or use credential sharing). I'm not sure I follow why what's described "hurts" Alice's privacy. Alice is releasing her information to www.sleepwell.example.com not to sleepwell's contractor.

It exposes her information to the proxy, who doesn't need to see it.  As a practical matter, proxying hurts www.sleepwell.example.com as much.  If there's a leak, everyone who shows up in the audit trail is suspect.  With a pure bearer token approach, www.sleepwell.example.com never shows up in the log as having accessed Alice's data.

If I have a contract with a brokerage firm or bank and they sub-contract out the handling of my account with some other company, I currently don't have any control over that other than to switch brokerage firms. When I give my SSN to the brokerage firm, they may give the data to a contractor, but the "contract" or implicit agreement is between me and the brokerage firm.

That's exactly the way it works with bearer tokens.  If one of their contractors violates the rules, you go after your broker, not the contractor, who you probably never heard of, anyway. 

I would rather a model where www.sleepwell.example.com would request scoped tokens for it's contractors such that the token explicitly identifies the contractor and it's relationship to www.sleepwell.example.com. This keeps the relationships clear as data traverses amongst the different servers.

Nothing says that companies can't do that.  For example, my health insurance plan explicitly redirects me to my mail order pharmacy's web site.  On the other hand, my bank makes the bill pay service I use look like I'm at the bank's web site.  Bearer tokens can be used both ways, too.  

Keep in mind the need to keep the right metadata.  Most of today's systems don't.  If I ask the administrator of a SharePoint workspace to add you to the ACL of some file, the audit log shows the administrator added you, but nowhere do they record that it's because I asked.  If you violate the rules, they know you did it, but they've lost track of the fact that you had access because I said so.

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.

I'm fine with this model as long as www.sleepwell.example.com explicit requests a special token (based on it's granted permission) for each contractor that provides that contractor with just the authority that it needs. I believe that in certain use cases, it must be possible to prove that the token presented is presented by the party it was issued to. A bearer token does not carry this semantic.

A desirable goal, but one that's unenforceable given the reality of proxying and credential sharing.  Charlie Landau likes to say, DPWYCP (Don't Prohibit What You Can't Prevent).  Your agreement with www.sleepwell.example.com could require a separate token for each contractor.  I think you gain just as much by having all uses of the token you gave www.sleepwell.example.com signed by whoever is making the request.  However you do it, it only helps if you have knowledge of the contractors independent of www.sleepwell.example.com (think the sock puppet problem).