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:
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
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:* oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *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
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
------------------------------------------------------------------------
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
