why that? If there will be a signature proposal for resource server
access, the same (simplified?) model could be applied to the authz
server's API.
And as I pointed out in my original posting, I see this as a _further_
option not the only one. While it is technically more complicated, it
has its adavantages (we already discussed). One further advantage of
already signing the inbound request is that the authz server can refuse
unauthorized requests early.
regards,
Torsten.
Eran Hammer-Lahav schrieb:
At some point this brings us back to 1.0...
EHL
On Jul 14, 2010, at 17:59, Torsten Lodderstedt <tors...@lodderstedt.net> wrote:
Am 14.07.2010 23:52, schrieb Brian Eaton:
On Wed, Jul 14, 2010 at 2:48 PM, Torsten Lodderstedt
<tors...@lodderstedt.net> wrote:
Yepp. That's an optimization of use case 2. That way the authz server does
not need to store the authorization transaction's results in a database and
there is no need to perform a a second request.
The authorization server doesn't need to store the transaction results
in a database regardless, the authorization code can be a signed
message.
That's an indeed option. But then the whole data is transported twice
between authz server and client.
The second request (as you pointed out in your original mail) is
currently used to verify the client identity. Do you have a
suggestion for an alternate mechanism?
A digital signature over the authz request? Alternatively, the authz
server could encrypt the authz response.
regards,
Torsten.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
