Subject: Re: [OAUTH-WG] Signatures...what are we trying to solve?

From: George Fletcher <[email-masked]>
Date: Mon, 04 Oct 2010 12:19:56 -0400

Hi Zachary,

Here is a use case for signed messages. I've tried to keep this in the 
format of the other OAuth use cases. Please contact me off-list if there 
are editorial changes required. I've include the list to see if others 
have feed back on this use case.

Thanks,
George

Use case: Signed Messages

Description:

Alice manages all her personal health records in her personal health 
data store (www.myhealth.example.com). Alice's Primary Care Physician 
(www.pcp.example.com) recommends that Alice 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 from her PCP. 
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 issues 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 accesses 
www.myhealth.example.com to discover the location of the PCP system (XRD 
discovery)
* The application at www.sleepwell.example.com requests Alice to 
authorize 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 issues 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 constructs a request 
(includes the token issued by www.myhealth.example.com) to the 
application at www.pcp.example.com
* The application at www.sleepwell.example.com signs the request before 
sending it to www.pcp.example.com
* The application at www.pcp.example.com receives the request and 
verifies the signature
* The application at www.pcp.example.com parses the message and finds 
the authorization token
* The application at www.pcp.example.com verifies the signature of the 
authorization token
* The application at www.pcp.example.com parses the authorization token 
and verifies that this token was issued to the application at 
www.sleepwell.com
* The application at www.pcp.example.com retrieves the requested data 
and returns it to the application at www.sleepwell.example.com

On 9/28/10 12:27 PM, Zeltsan, Zachary (Zachary) wrote:
>
> These use cases are not in the draft 
> https://datatracker.ietf.org/doc/draft-zeltsan-use-cases-oauth.
>
> Could you write them up?
>
> Thanks,
>
> Zachary
>
> ------------------------------------------------------------------------
>
> *From:* [email-masked] [mailto:[email-masked]] *On 
> Behalf Of *George Fletcher
> *Sent:* Tuesday, September 28, 2010 11:39 AM
> *To:* OAuth WG
> *Subject:* Re: [OAUTH-WG] Signatures...what are we trying to solve?
>
> I think of the signature issues as falling into two classes... I think 
> they map to your classification as well...
>
>     * *Signing tokens* is important for interoperability especially
>       looking forward to a time when tokens issued by multiple
>       Authorization Servers are accepted at a given host.
>     * *Signing messages* is important because it provides a mechanism
>       to ensure that the entity making the API call (and presenting an
>       access token) is really the entity that is allowed to make the
>       API call.
>
> Signing messages applies to the re-delegation use cases. I've heard 
> the need for this class of use cases from both the hData (health data) 
> community as well as the user managed access (UMA) community.
>
> Signing tokens covers both your second class of tokens as well as 
> another use case that Eran has mentioned as well. Namely, a protected 
> resource server honoring tokens from multiple Authorization Servers.
>
> These are the two classes of use cases that I'd like to see solved.
>
> Thanks,
> George
>
>
> On 9/28/10 12:58 AM, David Recordon wrote:
>
> If you know me then you'll know that I'm generally one of the last 
> people to talk about Alice and Bob. That said, there are a lot of 
> technical proposals flying across the list with very little shared 
> understanding of the problem(s) we're trying to solve.
>
> From what I've seen there are two distinct classes of signature use cases.
>
> 1) The first is where the HTTP request parameters must be part of the 
> signature. An example is any OAuth 1.0a style API where you want to 
> make sure that the HTTP POST your server just received isn't 
> masquerading itself as a GET.
>
> 2) The second is where the HTTP request is orthogonal. An example 
> is OpenSocial where the server is sending state information to the 
> client such as what user is currently logged in.
>
> The main practical example I have of the first use case is what 
> Twitter wants to do with redelegation. In this case TweetDeck can't 
> given TwitPic it's own bearer token, but needs to sign the POST 
> request and pass that signature to TwitPic for it to include in the 
> final API request to Twitter.
>
> In terms of signing protected resource requests, I haven't heard 
> anyone bring up specific and detailed needs for this recently.
>
> JSON tokens pretty clearly make sense for the second class of 
> signature use cases and it's actually a bit hard to argue why they 
> would be a part of OAuth. Facebook shipped this a bit over a month ago 
> for canvas applications. We include a `signed_request` parameter which 
> is signature.base64url(JSON). Parsing it is 18 lines of PHP. 
> http://developers.facebook.com/docs/authentication/canvas
>
> This second class of use case will also be required by OpenID Connect 
> where the server is signing identity information and sending it to the 
> client. I imagine that OpenSocial will also still have it and wish to 
> continue relying on public key algorithms.
>
> So a few questions:
>
>  * Do we want to tackle both of these classes of signatures in OAuth?
>
>  * Why do you consider the second class part of OAuth versus something 
> completely separate that might happen to include an OAuth access token?
>
>  * Is the Twitter redelegation use case the right focus for the first 
> class?
>
>  * Is there an example of an OAuth 2.0 server that can't use bearer 
> tokens for protected resource requests and thus requires signatures?
>
> Thanks,
>
> --David
>
>   
>
>   
> _______________________________________________
> OAuth mailing list
> [email-masked]  <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: "Freeman, Tim" <[email-masked]>
Date: Mon, 4 Oct 2010 17:59:12 +0000

Putting the use cases on the table is good because it makes things much clearer.  Unfortunately, it's clear that this use case does not work.

I'd like to number the steps under "Requirements" so I can refer to them unambiguously:

1. The application at www.sleepwell.example.com<http://www.sleepwell.example.com> accesses www.myhealth.example.com<http://www.myhealth.example.com> to discover the location of the PCP system (XRD discovery)
2. The application at www.sleepwell.example.com<http://www.sleepwell.example.com> requests Alice to authorize access to the application at www.pcp.example.com<http://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.
3. The application at www.myhealth.example.com<http://www.myhealth.example.com> issues a token bound to www.sleepwell.example.com<http://www.sleepwell.example.com> for access to the application at www.pcp.example.com<http://www.pcp.example.com>. Note that a signed token (JWT) can be used to prove who issued the token.
4. The application at www.sleepwell.example.com<http://www.sleepwell.example.com> constructs a request (includes the token issued by www.myhealth.example.com<http://www.myhealth.example.com>) to the application at www.pcp.example.com<http://www.pcp.example.com>
5. The application at www.sleepwell.example.com<http://www.sleepwell.example.com> signs the request before sending it to www.pcp.example.com<http://www.pcp.example.com>
6. The application at www.pcp.example.com<http://www.pcp.example.com> receives the request and verifies the signature
7. The application at www.pcp.example.com<http://www.pcp.example.com> parses the message and finds the authorization token
8. The application at www.pcp.example.com<http://www.pcp.example.com> verifies the signature of the authorization token
9. The application at www.pcp.example.com<http://www.pcp.example.com> parses the authorization token and verifies that this token was issued to the application at www.sleepwell.com<http://www.sleepwell.com>
10. The application at www.pcp.example.com<http://www.pcp.example.com> retrieves the requested data and returns it to the application at www.sleepwell.example.com<http://www.sleepwell.example.com>

The stated purpose of signatures is:

>The application at www.pcp.example.com<http://www.pcp.example.com> verifies that Alice has authorized
>www.sleepwell.example.com<http://www.sleepwell.example.com> to access her health data as well as enforces
>that www.sleepwell.example.com<http://www.sleepwell.example.com> is the only application that can retrieve that
>data with that specific authorization.

I'll abbreviate domain names like "www.sleepwell.example.com" to "sleepwell".

Bearer tokens work fine when verifying that Alice has authorized  sleepwell<http://www.sleepwell.example.com> to access her health data, so the claim is apparently that signatures give the added benefit of enforcing that sleepwell<http://www.sleepwell.example.com> is the only application that can retrieve that data with that specific authorization.

Unfortunately, signatures do not do that.  Suppose sleepwell wanted to give Alice's data to apneacheck.  Sleepwell could follow the protocol up to step 4.  Then, instead of signing the request and sending the signed request to pcp, sleepwell could transmit the signed request to apneacheck.  apneacheck could then complete the protocol and get Alice's data from www.pcp.example.com.

If sleepwell has can retrive to Alice's data, and the protocol doesn't mandate an invasive control of sleepwell's computation and outputs, it's hopeless to prevent sleepwell from allowing apneacheck to retrieve Alice's data.  If all else fails, sleepwell could access Alice's data itself and then allow apneacheck to access the data from sleepwell.

For all I know, signatures might be a solution to some problem, but they aren't a solution to this problem.

Tim Freeman
Email: [email-masked]<mailto:[email-masked]>
Desk in Palo Alto: (650) 857-2581
Home: (408) 774-1298
Cell: (408) 348-7536

From: [email-masked] [mailto:[email-masked]] On Behalf Of George Fletcher
Sent: Monday, October 04, 2010 9:20 AM
To: Zeltsan, Zachary (Zachary)
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Signatures...what are we trying to solve?

Hi Zachary,

Here is a use case for signed messages. I've tried to keep this in the format of the other OAuth use cases. Please contact me off-list if there are editorial changes required. I've include the list to see if others have feed back on this use case.

Thanks,
George

Description:

Alice manages all her personal health records in her personal health data store (www.myhealth.example.com<http://www.myhealth.example.com>). Alice's Primary Care Physician (www.pcp.example.com<http://www.pcp.example.com>) recommends that Alice see a sleep specialist (www.sleepwell.example.com<http://www.sleepwell.example.com>). Alice arrives at the sleep specialist's office and authorizes it to access her basic health data from her PCP. The application at www.pcp.example.com<http://www.pcp.example.com> verifies that Alice has authorized www.sleepwell.example.com<http://www.sleepwell.example.com> to access her health data as well as enforces that www.sleepwell.example.com<http://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<http://www.myhealth.example.com> manages authorization of access to Alice's participating health systems
* The application at www.myhealth.example.com<http://www.myhealth.example.com> can issues authorization tokens understood by Alice's participating health systems
* The application at www.pcp.example.com<http://www.pcp.example.com> stores Alice's basic health and prescription records
* The application at www.sleepwell.com<http://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<http://www.pcp.example.com>) to the sleep specialist (www.sleepwell.example.com<http://www.sleepwell.example.com>).
* The transfer of health data only occurs if the application at www.pcp.example.com<http://www.pcp.example.com> can verify that www.sleepwell.example.com<http://www.sleepwell.example.com> is the party requesting access and that the authorization token presented by www.sleepwell.example.com<http://www.sleepwell.example.com> is issued by the application at www.myhealth.example.com<http://www.myhealth.example.com> with a restricted audience of www.sleepwell.example.com<http://www.sleepwell.example.com>

Requirements:
1. The application at www.sleepwell.example.com<http://www.sleepwell.example.com> accesses www.myhealth.example.com<http://www.myhealth.example.com> to discover the location of the PCP system (XRD discovery)
2. The application at www.sleepwell.example.com<http://www.sleepwell.example.com> requests Alice to authorize access to the application at www.pcp.example.com<http://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.
3. The application at www.myhealth.example.com<http://www.myhealth.example.com> issues a token bound to www.sleepwell.example.com<http://www.sleepwell.example.com> for access to the application at www.pcp.example.com<http://www.pcp.example.com>. Note that a signed token (JWT) can be used to prove who issued the token.
4. The application at www.sleepwell.example.com<http://www.sleepwell.example.com> constructs a request (includes the token issued by www.myhealth.example.com<http://www.myhealth.example.com>) to the application at www.pcp.example.com<http://www.pcp.example.com>
5. The application at www.sleepwell.example.com<http://www.sleepwell.example.com> signs the request before sending it to www.pcp.example.com<http://www.pcp.example.com>
6. The application at www.pcp.example.com<http://www.pcp.example.com> receives the request and verifies the signature
7. The application at www.pcp.example.com<http://www.pcp.example.com> parses the message and finds the authorization token
8. The application at www.pcp.example.com<http://www.pcp.example.com> verifies the signature of the authorization token
9. The application at www.pcp.example.com<http://www.pcp.example.com> parses the authorization token and verifies that this token was issued to the application at www.sleepwell.com<http://www.sleepwell.com>
10. The application at www.pcp.example.com<http://www.pcp.example.com> retrieves the requested data and returns it to the application at www.sleepwell.example.com<http://www.sleepwell.example.com>

On 9/28/10 12:27 PM, Zeltsan, Zachary (Zachary) wrote:
These use cases are not in the draft https://datatracker.ietf.org/doc/draft-zeltsan-use-cases-oauth.
Could you write them up?

Thanks,
Zachary

________________________________
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of George Fletcher
Sent: Tuesday, September 28, 2010 11:39 AM
To: OAuth WG
Subject: Re: [OAUTH-WG] Signatures...what are we trying to solve?

I think of the signature issues as falling into two classes... I think they map to your classification as well...

 *   Signing tokens is important for interoperability especially looking forward to a time when tokens issued by multiple Authorization Servers are accepted at a given host.
 *   Signing messages is important because it provides a mechanism to ensure that the entity making the API call (and presenting an access token) is really the entity that is allowed to make the API call.
Signing messages applies to the re-delegation use cases. I've heard the need for this class of use cases from both the hData (health data) community as well as the user managed access (UMA) community.

Signing tokens covers both your second class of tokens as well as another use case that Eran has mentioned as well. Namely, a protected resource server honoring tokens from multiple Authorization Servers.

Thanks,
George

On 9/28/10 12:58 AM, David Recordon wrote:
If you know me then you'll know that I'm generally one of the last people to talk about Alice and Bob. That said, there are a lot of technical proposals flying across the list with very little shared understanding of the problem(s) we're trying to solve.

>From what I've seen there are two distinct classes of signature use cases.
1) The first is where the HTTP request parameters must be part of the signature. An example is any OAuth 1.0a style API where you want to make sure that the HTTP POST your server just received isn't masquerading itself as a GET.
2) The second is where the HTTP request is orthogonal. An example is OpenSocial where the server is sending state information to the client such as what user is currently logged in.

The main practical example I have of the first use case is what Twitter wants to do with redelegation. In this case TweetDeck can't given TwitPic it's own bearer token, but needs to sign the POST request and pass that signature to TwitPic for it to include in the final API request to Twitter.

In terms of signing protected resource requests, I haven't heard anyone bring up specific and detailed needs for this recently.

JSON tokens pretty clearly make sense for the second class of signature use cases and it's actually a bit hard to argue why they would be a part of OAuth. Facebook shipped this a bit over a month ago for canvas applications. We include a `signed_request` parameter which is signature.base64url(JSON). Parsing it is 18 lines of PHP. http://developers.facebook.com/docs/authentication/canvas

This second class of use case will also be required by OpenID Connect where the server is signing identity information and sending it to the client. I imagine that OpenSocial will also still have it and wish to continue relying on public key algorithms.

So a few questions:
 * Do we want to tackle both of these classes of signatures in OAuth?
 * Why do you consider the second class part of OAuth versus something completely separate that might happen to include an OAuth access token?
 * Is the Twitter redelegation use case the right focus for the first class?
 * Is there an example of an OAuth 2.0 server that can't use bearer tokens for protected resource requests and thus requires signatures?

Thanks,
--David

OAuth mailing list

[email-masked]<mailto:[email-masked]>

---

From: George Fletcher <[email-masked]>
Date: Mon, 04 Oct 2010 14:28:11 -0400

Hi Tim,

Thanks for the feedback. Some comments/questions inline...

On 10/4/10 1:59 PM, Freeman, Tim wrote:
>
> Putting the use cases on the table is good because it makes things 
> much clearer.  Unfortunately, it's clear that this use case does not work.
>
> 1. The application at www.sleepwell.example.com 
> <http://www.sleepwell.example.com> accesses www.myhealth.example.com 
> <http://www.myhealth.example.com> to discover the location of the PCP 
> system (XRD discovery)
> 2. The application at www.sleepwell.example.com 
> <http://www.sleepwell.example.com> requests Alice to authorize access 
> to the application at www.pcp.example.com <http://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.
> 3. The application at www.myhealth.example.com 
> <http://www.myhealth.example.com> issues a token bound to 
> www.sleepwell.example.com <http://www.sleepwell.example.com> for 
> access to the application at www.pcp.example.com 
> <http://www.pcp.example.com>. Note that a signed token (JWT) can be 
> used to prove who issued the token.
> 4. The application at www.sleepwell.example.com 
> <http://www.sleepwell.example.com> constructs a request (includes the 
> token issued by www.myhealth.example.com 
> <http://www.myhealth.example.com>) to the application at 
> www.pcp.example.com <http://www.pcp.example.com>
> 5. The application at www.sleepwell.example.com 
> <http://www.sleepwell.example.com> signs the request before sending it 
> to www.pcp.example.com <http://www.pcp.example.com>
> 6. The application at www.pcp.example.com <http://www.pcp.example.com> 
> receives the request and verifies the signature
> 7. The application at www.pcp.example.com <http://www.pcp.example.com> 
> parses the message and finds the authorization token
> 8. The application at www.pcp.example.com <http://www.pcp.example.com> 
> verifies the signature of the authorization token
> 9. The application at www.pcp.example.com <http://www.pcp.example.com> 
> parses the authorization token and verifies that this token was issued 
> to the application at www.sleepwell.com <http://www.sleepwell.com>
> 10. The application at www.pcp.example.com 
> <http://www.pcp.example.com> retrieves the requested data and returns 
> it to the application at www.sleepwell.example.com 
> <http://www.sleepwell.example.com>
>
> >The application at www.pcp.example.com <http://www.pcp.example.com> 
> verifies that Alice has authorized
>
> >www.sleepwell.example.com <http://www.sleepwell.example.com> to access 
> her health data as well as enforces
>
> >that www.sleepwell.example.com <http://www.sleepwell.example.com> is 
> the only application that can retrieve that
>
> Bearer tokens work fine when verifying that Alice has authorized 
> sleepwell <http://www.sleepwell.example.com> to access her health 
> data, so the claim is apparently that signatures give the added 
> benefit of enforcing that sleepwell <http://www.sleepwell.example.com> 
> is the only application that can retrieve that data with that specific 
> authorization.
>
I suppose this depends on how you define "work fine". While the 
authorization token issued by myhealthdata and given to sleepwell to 
present to pcp can be passed as a bearer token (so in that sense it 
works fine) there is no security around the token. In the case of health 
data, just possession of an autorization token is NOT good enough to 
grant access.

Instead the PCP site needs to ensure that the presenting entity is 
specifically authorized by the Authorization Server. I contend that to 
establish this "chain of trust" signatures are needed.

Given that in most cases pcp will want to decode the token itself, it 
will need some form of signed structured token because pcp is the 
recipient of the token and not the issuer.

> Unfortunately, signatures do not do that.  Suppose sleepwell wanted to 
> give Alice's data to apneacheck.  Sleepwell could follow the protocol 
> up to step 4.  Then, instead of signing the request and sending the 
> signed request to pcp, sleepwell could transmit the signed request to 
> apneacheck.  apneacheck could then complete the protocol and get 
> Alice's data from www.pcp.example.com.
>
Maybe I wasn't clear in the use case. The point of signatures is not to 
enable authorization but to ensure that release of data only happens 
within the context that was authorized by the user. Let's take the flip 
side where signatures are not used. Any site with access to the bearer 
token issued to sleepwell has access to the Alice's data at the PCP. 
This is not acceptable with sensitive data.

So the point of signatures in this use case is to create a binding 
between the issuer of the token (myhealthdata), the presenter of the 
token (sleepwell) and the receiver of the token (pcp).

If sleepwell signs the message sent to pcp, then pcp can verify that 
sleepwell is the sender of the message. Next, if the message contains a 
token signed by myhealth data, and that token includes a claim that the 
token is issued to sleepwell. PCP can "connect the dots" and know that 
this is a valid request.

If the token is sent by another server, the "issued to" claim will not 
match the entity that signed the message and the PCP application will 
reject the request.
>
> If sleepwell has can retrive to Alice's data, and the protocol doesn't 
> mandate an invasive control of sleepwell's computation and outputs, 
> it's hopeless to prevent sleepwell from allowing apneacheck to 
> retrieve Alice's data.  If all else fails, sleepwell could access 
> Alice's data itself and then allow apneacheck to access the data from 
> sleepwell.
>
So I'll concede that once sleepwell has the data, if sleepwell is not 
trustworthy, there is little Alice can do to protect her data. Maybe 
laws and other such mechanisms will be developed to deal with this 
scenario. This is one reason why it's so important for the PCP to only 
release data to the specific entity that was authorized. This is not 
possible with bearer tokens in a delegated use case like this one.
> Email: [email-masked] <mailto:[email-masked]>
> *Sent:* Monday, October 04, 2010 9:20 AM
> *To:* Zeltsan, Zachary (Zachary)
> *Cc:* OAuth WG
> format of the other OAuth use cases. Please contact me off-list if 
> there are editorial changes required. I've include the list to see if 
> others have feed back on this use case.
>
> Thanks,
> George
>
> data store (www.myhealth.example.com 
> <http://www.myhealth.example.com>). Alice's Primary Care Physician 
> (www.pcp.example.com <http://www.pcp.example.com>) recommends that 
> Alice see a sleep specialist (www.sleepwell.example.com 
> <http://www.sleepwell.example.com>). Alice arrives at the sleep 
> specialist's office and authorizes it to access her basic health data 
> from her PCP. The application at www.pcp.example.com 
> <http://www.pcp.example.com> verifies that Alice has authorized 
> www.sleepwell.example.com <http://www.sleepwell.example.com> to access 
> her health data as well as enforces that www.sleepwell.example.com 
> <http://www.sleepwell.example.com> is the only application that can 
> retrieve that data with that specific authorization.
>
> Pre-conditions:
>
> * The application at www.myhealth.example.com 
> <http://www.myhealth.example.com> manages authorization of access to 
> Alice's participating health systems
> * The application at www.myhealth.example.com 
> <http://www.myhealth.example.com> can issues authorization tokens 
> understood by Alice's participating health systems
> * The application at www.pcp.example.com <http://www.pcp.example.com> 
> stores Alice's basic health and prescription records
> * The application at www.sleepwell.com <http://www.sleepwell.com> 
> stores results of Alice's sleep tests
>
>
> Post-conditions:
> (www.pcp.example.com <http://www.pcp.example.com>) to the sleep 
> specialist (www.sleepwell.example.com <http://www.sleepwell.example.com>).
> www.pcp.example.com <http://www.pcp.example.com> can verify that 
> www.sleepwell.example.com <http://www.sleepwell.example.com> is the 
> www.sleepwell.example.com <http://www.sleepwell.example.com> is issued 
> by the application at www.myhealth.example.com 
> <http://www.myhealth.example.com> with a restricted audience of 
> www.sleepwell.example.com <http://www.sleepwell.example.com>
>
> Requirements:
> 1. The application at www.sleepwell.example.com 
> <http://www.sleepwell.example.com> accesses www.myhealth.example.com 
> <http://www.myhealth.example.com> to discover the location of the PCP 
> system (XRD discovery)
> 2. The application at www.sleepwell.example.com 
> <http://www.sleepwell.example.com> requests Alice to authorize access 
> to the application at www.pcp.example.com <http://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.
> 3. The application at www.myhealth.example.com 
> <http://www.myhealth.example.com> issues a token bound to 
> www.sleepwell.example.com <http://www.sleepwell.example.com> for 
> access to the application at www.pcp.example.com 
> <http://www.pcp.example.com>. Note that a signed token (JWT) can be 
> used to prove who issued the token.
> 4. The application at www.sleepwell.example.com 
> <http://www.sleepwell.example.com> constructs a request (includes the 
> token issued by www.myhealth.example.com 
> <http://www.myhealth.example.com>) to the application at 
> www.pcp.example.com <http://www.pcp.example.com>
> 5. The application at www.sleepwell.example.com 
> <http://www.sleepwell.example.com> signs the request before sending it 
> to www.pcp.example.com <http://www.pcp.example.com>
> 6. The application at www.pcp.example.com <http://www.pcp.example.com> 
> receives the request and verifies the signature
> 7. The application at www.pcp.example.com <http://www.pcp.example.com> 
> parses the message and finds the authorization token
> 8. The application at www.pcp.example.com <http://www.pcp.example.com> 
> verifies the signature of the authorization token
> 9. The application at www.pcp.example.com <http://www.pcp.example.com> 
> parses the authorization token and verifies that this token was issued 
> to the application at www.sleepwell.com <http://www.sleepwell.com>
> 10. The application at www.pcp.example.com 
> <http://www.pcp.example.com> retrieves the requested data and returns 
> it to the application at www.sleepwell.example.com 
> <http://www.sleepwell.example.com>
>
>
>
> *From:* [email-masked] <mailto:[email-masked]> 
> [mailto:[email-masked]] *On Behalf Of *George Fletcher

-- 
Chief Architect                   AIM:  gffletch
Identity Services Engineering     Work: [email-masked]
AOL Inc.                          Home: [email-masked]
Mobile: +1-703-462-3494           Blog: http://practicalid.blogspot.com
Office: +1-703-265-2544           Twitter: http://twitter.com/gffletch

---

From: Igor Faynberg <[email-masked]>
Date: Mon, 04 Oct 2010 14:41:34 -0400

YES!!!   (I wish I could have made this point myself as clear as George 
did.)

In fact, I think this ought to be a fundamental requirement for OAuth 
applicability within several domains, health services in particular.

Igor

George Fletcher wrote:
> ... The point of signatures is not to enable authorization but to 
> ensure that release of data only happens within the context that was 
> authorized by the user.
...

---

From: "Zeltsan, Zachary (Zachary)" <[email-masked]>
Date: Mon, 4 Oct 2010 15:56:40 -0500

I believe that George has presented a convincing use case for the need of signatures for binding a resource request with the authorizing (myhelthdata on Alice's behalf), requesting (sleepwell), and storing the resource (pcp) entities. Such binding does not eliminate unauthorized access to the resources, but makes it harder to get and also, allows creation of the proof of the participants' actions (e.g., a proof that sleepwell has requested access to Alice's data at pcp).

Zachary

________________________________
From: George Fletcher [mailto:[email-masked]]
Sent: Monday, October 04, 2010 2:28 PM
To: Freeman, Tim
Cc: Zeltsan, Zachary (Zachary); OAuth WG
Subject: Re: Signatures don't solve that problem (was RE: [OAUTH-WG] Signatures...what are we trying to solve?)

Hi Tim,

>data with that specific authorization.

I'll abbreviate domain names like "www.sleepwell.example.com<http://www.sleepwell.example.com>" to "sleepwell".

Bearer tokens work fine when verifying that Alice has authorized  sleepwell<http://www.sleepwell.example.com> to access her health data, so the claim is apparently that signatures give the added benefit of enforcing that sleepwell<http://www.sleepwell.example.com> is the only application that can retrieve that data with that specific authorization.
I suppose this depends on how you define "work fine". While the authorization token issued by myhealthdata and given to sleepwell to present to pcp can be passed as a bearer token (so in that sense it works fine) there is no security around the token. In the case of health data, just possession of an autorization token is NOT good enough to grant access.

Instead the PCP site needs to ensure that the presenting entity is specifically authorized by the Authorization Server. I contend that to establish this "chain of trust" signatures are needed.

Given that in most cases pcp will want to decode the token itself, it will need some form of signed structured token because pcp is the recipient of the token and not the issuer.

Unfortunately, signatures do not do that.  Suppose sleepwell wanted to give Alice's data to apneacheck.  Sleepwell could follow the protocol up to step 4.  Then, instead of signing the request and sending the signed request to pcp, sleepwell could transmit the signed request to apneacheck.  apneacheck could then complete the protocol and get Alice's data from www.pcp.example.com<http://www.pcp.example.com>.
Maybe I wasn't clear in the use case. The point of signatures is not to enable authorization but to ensure that release of data only happens within the context that was authorized by the user. Let's take the flip side where signatures are not used. Any site with access to the bearer token issued to sleepwell has access to the Alice's data at the PCP. This is not acceptable with sensitive data.

So the point of signatures in this use case is to create a binding between the issuer of the token (myhealthdata), the presenter of the token (sleepwell) and the receiver of the token (pcp).

If sleepwell signs the message sent to pcp, then pcp can verify that sleepwell is the sender of the message. Next, if the message contains a token signed by myhealth data, and that token includes a claim that the token is issued to sleepwell. PCP can "connect the dots" and know that this is a valid request.

If the token is sent by another server, the "issued to" claim will not match the entity that signed the message and the PCP application will reject the request.

If sleepwell has can retrive to Alice's data, and the protocol doesn't mandate an invasive control of sleepwell's computation and outputs, it's hopeless to prevent sleepwell from allowing apneacheck to retrieve Alice's data.  If all else fails, sleepwell could access Alice's data itself and then allow apneacheck to access the data from sleepwell.
So I'll concede that once sleepwell has the data, if sleepwell is not trustworthy, there is little Alice can do to protect her data. Maybe laws and other such mechanisms will be developed to deal with this scenario. This is one reason why it's so important for the PCP to only release data to the specific entity that was authorized. This is not possible with bearer tokens in a delegated use case like this one.

Tim Freeman

Hi Zachary,

Thanks,
George

Description:

Pre-conditions:

Post-conditions:

Requirements:

Thanks,
Zachary

Thanks,
George

So a few questions:

Thanks,
--David

OAuth mailing list

--

Identity Services Engineering     Work: [email-masked]<mailto:[email-masked]>

AOL Inc.                          Home: [email-masked]<mailto:[email-masked]>

---

From: "Freeman, Tim" <[email-masked]>
Date: Mon, 4 Oct 2010 21:09:49 +0000

>Maybe I wasn't clear in the use case. The point of signatures is not to enable authorization but to
>ensure that release of data only happens within the context that was authorized by the user. Let's
>take the flip side where signatures are not used.

I agree that taking the flip side there is important.  In order to support the claim "X is important for security" with use cases, you need one use case where X is absent and someone gets some information they shouldn't, and another use case where X is present and everything else is similar and the information doesn't leak

>Any site with access to the bearer token issued to
>sleepwell has access to the Alice's data at the PCP.

Part of the story is missing here.  How did the site other than sleepwell get the bearer token issued to sleepwell?  The negative use case showing that bearer tokens leak would answer that question immediately.

If the bearer token leaks, why couldn't Alice's data have leaked by the same path in a scheme with signatures?

(quoting out of order)
>In the case of health data, just possession of an autorization token is NOT good enough to grant access. ...

I don't understand where you're coming from.  Are these meant to be technical statements (which would need some sort of explanation or example), statements about laws like HIPPA (which would need citation of the relevant law), or intuitive predictions about some future consensus?   You might be right about the future consensus.  I was hoping to see a technical justification for it, but that might not happen.

Signatures do decrease the amount that sleepwell has to trust pcp.  Without signatures, a dishonest pcp could give a bearer token to sleepwell, publish the bearer token anonymously to third parties who make unauthorized use of Alice's medical records, and then at the end we don't know whether to blame the bearer token leak on sleepwell or pcp.  (That's the negative use case.)  With signatures, pcp is supposed to check that the incoming token is signed by sleepwell, and if it receives the properly signed token when someone is accessing Alice's medical records, and those records leak, then either sleepwell leaked them directly or sleepwell allowed a signed token to leak or sleepwell allowed its private key to leak, so we know who to  blame.  (That's the positive use case.)  If the purpose of signatures is to allow auditing and correctly assigning blame afterward, rather than decreasing the risk of Alice's records leaking, it makes sense to me.

If this is the right story, we don't need discovery in step 1, and we don't need to prove who issued the token at step 3, and we do need to add the use case where pcp didn't do its job.  We also have the irritating problem of distributing a bunch of public keys at the beginning.

Tim Freeman

From: George Fletcher [mailto:[email-masked]]
Sent: Monday, October 04, 2010 11:28 AM
To: Freeman, Tim
Cc: Zeltsan, Zachary (Zachary); OAuth WG
Subject: Re: Signatures don't solve that problem (was RE: [OAUTH-WG] Signatures...what are we trying to solve?)

Hi Tim,

Tim Freeman

Hi Zachary,

Thanks,
George

Description:

Pre-conditions:

Post-conditions:

Requirements:

Thanks,
Zachary

Thanks,
George

So a few questions:

Thanks,
--David

OAuth mailing list

--

---

From: Prateek Mishra <[email-masked]>
Date: Thu, 07 Oct 2010 09:57:27 -0400

George,

I will comment at a later time on the details of your use-case.

But as far as signing the request for a protected resource (signature 
over access token, client_id, scope,  URL, request body) - isn't this 
requirement is a simple consequence of network architecture wherein an 
SSL connection may terminate quite early at the resource server site? 
There may be a good number of hops between SSL termination and the 
resource server. So I am not sure that we need a business use-case to 
justify the need for signatures as a means of addressing the threat that 
the message may altered at the resource server site, before it is 
presented to a particular resource server.

I guess this is a bit different from the motivation for request message 
signing you described in

http://www.ietf.org/mail-archive/web/oauth/current/msg04527.html

- prateek
> as enforces that www.sleepwell.example.com is the only application 
> that can retrieve that data with that specific authorization.
>
> Pre-conditions:
>
> * The application at www.pcp.example.com stores Alice's basic health 
> and prescription records
> www.myhealth.example.com to discover the location of the PCP system 
> (XRD discovery)
> 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 signs the request 
> before sending it to www.pcp.example.com
> * The application at www.pcp.example.com parses the authorization 
> token and verifies that this token was issued to the application at 
> www.sleepwell.com
>> I think of the signature issues as falling into two classes... I 
>> think they map to your classification as well...
>>
>>       to ensure that the entity making the API call (and presenting
>>       an access token) is really the entity that is allowed to make
>>       the API call.
>>
>> the need for this class of use cases from both the hData (health 
>> data) community as well as the user managed access (UMA) community.
>>
>> would be a part of OAuth. Facebook shipped this a bit over a month 
>> ago for canvas applications. We include a `signed_request` parameter 
>> which is signature.base64url(JSON). Parsing it is 18 lines of PHP. 
>> where the server is signing identity information and sending it to 
>> the client. I imagine that OpenSocial will also still have it and 
>> wish to continue relying on public key algorithms.
>>
>>  
>>
>> So a few questions:
>>
>>  * Why do you consider the second class part of OAuth versus 
>> something completely separate that might happen to include an OAuth 
>> access token?
>>
> [email-masked]

---

From: George Fletcher <[email-masked]>
Date: Thu, 07 Oct 2010 10:12:20 -0400

Hi Prateek,

I think that message signing has a number of benefits. The one you state 
is as important as any others. I was just writing up one use case as a 
justification for signatures. Not trying to cover them all:)

Looking forward to your feedback.

Thanks,
George

On 10/7/10 9:57 AM, Prateek Mishra wrote:
> justify the need for signatures as a means of addressing the threat 
> that the message may altered at the resource server site, before it is 
> I guess this is a bit different from the motivation for request 
> message signing you described in
>
>> Here is a use case for signed messages. I've tried to keep this in 
>> the format of the other OAuth use cases. Please contact me off-list 
>> if there are editorial changes required. I've include the list to see 
>> if others have feed back on this use case.
>>
>> Thanks,
>> George
>>
>> office and authorizes it to access her basic health data from her 
>> PCP. 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:
>>
>> 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 issues 
>> authorization tokens understood by Alice's participating health systems
>> height, etc). The mechanism Alice uses to authorize this access is 
>> out of scope for this use case.
>> * The application at www.pcp.example.com verifies the signature of 
>> the authorization token
>>>     * *Signing messages* is important because it provides a
>>>       mechanism to ensure that the entity making the API call (and
>>>       presenting an access token) is really the entity that is
>>>       allowed to make the API call.
>>>
>>> another use case that Eran has mentioned as well. Namely, a 
>>> protected resource server honoring tokens from multiple 
>>> Authorization Servers.
>>>
>>> 1) The first is where the HTTP request parameters must be part of 
>>> the signature. An example is any OAuth 1.0a style API where you want 
>>> to make sure that the HTTP POST your server just received isn't 
>>> This second class of use case will also be required by OpenID 
>>> Connect where the server is signing identity information and sending 
>>> it to the client. I imagine that OpenSocial will also still have it 
>>> and wish to continue relying on public key algorithms.
>>>
>>> So a few questions:
>>>

---

From: "Freeman, Tim" <[email-masked]>
Date: Thu, 7 Oct 2010 20:56:57 +0000

From: Prateek Mishra
>But as far as signing the request for a protected resource (signature over
>access token, client_id, scope,  URL, request body) - isn't this requirement
>is a simple consequence of network architecture wherein an SSL connection
>may terminate quite early at the resource server site? There may be a good
>number of hops between SSL termination and the resource server.

If you don't trust SSL to do its job, you might as well drop it from the protocol.

Tim Freeman

From: [email-masked] [mailto:[email-masked]] On Behalf Of George Fletcher
Sent: Thursday, October 07, 2010 7:12 AM
To: Prateek Mishra
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Signatures...what are we trying to solve?

Hi Prateek,

I think that message signing has a number of benefits. The one you state is as important as any others. I was just writing up one use case as a justification for signatures. Not trying to cover them all:)

Thanks,
George

But as far as signing the request for a protected resource (signature over access token, client_id, scope,  URL, request body) - isn't this requirement is a simple consequence of network architecture wherein an SSL connection may terminate quite early at the resource server site? There may be a good number of hops between SSL termination and the resource server. So I am not sure that we need a business use-case to justify the need for signatures as a means of addressing the threat that the message may altered at the resource server site, before it is presented to a particular resource server.

I guess this is a bit different from the motivation for request message signing you described in

- prateek

Hi Zachary,

Thanks,
George

Description:

Pre-conditions:

Post-conditions:

Requirements:
* The application at www.sleepwell.example.com<http://www.sleepwell.example.com> accesses www.myhealth.example.com<http://www.myhealth.example.com> to discover the location of the PCP system (XRD discovery)
* The application at www.sleepwell.example.com<http://www.sleepwell.example.com> requests Alice to authorize access to the application at www.pcp.example.com<http://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<http://www.myhealth.example.com> issues a token bound to www.sleepwell.example.com<http://www.sleepwell.example.com> for access to the application at www.pcp.example.com<http://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<http://www.sleepwell.example.com> constructs a request (includes the token issued by www.myhealth.example.com<http://www.myhealth.example.com>) to the application at www.pcp.example.com<http://www.pcp.example.com>
* The application at www.sleepwell.example.com<http://www.sleepwell.example.com> signs the request before sending it to www.pcp.example.com<http://www.pcp.example.com>
* The application at www.pcp.example.com<http://www.pcp.example.com> receives the request and verifies the signature
* The application at www.pcp.example.com<http://www.pcp.example.com> parses the message and finds the authorization token
* The application at www.pcp.example.com<http://www.pcp.example.com> verifies the signature of the authorization token
* The application at www.pcp.example.com<http://www.pcp.example.com> parses the authorization token and verifies that this token was issued to the application at www.sleepwell.com<http://www.sleepwell.com>
* The application at www.pcp.example.com<http://www.pcp.example.com> retrieves the requested data and returns it to the application at www.sleepwell.example.com<http://www.sleepwell.example.com>

Thanks,
Zachary

Thanks,
George

So a few questions:

Thanks,
--David

OAuth mailing list

OAuth mailing list