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