what is the advantage in comparison to a token secret?
How do you want to propagate the client_id and secret to the resource
servers?
regrards,
Torsten.
Am 30.05.2010 um 03:27 schrieb Andrew Arnott <andrewarn...@gmail.com>:
Perhaps we can say that installed client apps can have client
secrets after all, by calling the authorization server and asking
for a new client_id and client_secret assignment for that particular
app-install.
Any thoughts on that?
--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the
death your right to say it." - S. G. Tallentyre
On Sat, May 29, 2010 at 5:21 AM, Andrew Arnott
<andrewarn...@gmail.com> wrote:
Hi Dirk,
If you eradicated access token secrets in favor of signing with
client secrets, how would installed apps, where the client secret is
worthless and usually blank, authenticate/sign their own requests?
--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the
death your right to say it." - S. G. Tallentyre
On Thu, May 20, 2010 at 4:39 PM, Dirk Balfanz <balf...@google.com>
wrote:
Hi guys,
at today's interim meeting, we were discussing Brian Eaton's
proposal for OAuth signatures. He was proposing a mechanism that
would (1) do away with base string canonicalization, (2) allow for
symmetric and public keys, and (3) allow for extensibility.
He got homework from the group to prove the feasibility of his
proposal by showing a couple of implementations.
In this post, I would like to introduce another improvement of the
OAuth 2 signing mechanism, one which is orthogonal to Brian's
proposal (i.e., it would work both with the signing mechanism in the
current spec, as well as with Brian's signature mechanism). The goal
of my proposal is twofold:
- it simplifies the spec. It will become more readable and therefore
easier to implement
- it separates out the mechanisms for delegated authorization and
for integrity protection into two independent pieces, which can be
put together by Servers and/or Clients like LEGO blocks.
Summary:
- use the client secret instead of the token secret for signing PR
access requests.
Long version of the proposal:
- remove all references to access tokens that are not bearer tokens
from the spec.
- stop calling the access tokens "bearer tokens". Call them just
"access tokens".
- remove all references to token secrets from the spec
- remove all parts of the spec that are of the kind "if bearer_token
then X, else Y", and replace them with X.
- delete section 5.3
- add a section called "Request Authentication" that goes something
like this:
"Servers may require that requests be authenticated by the Client,
so that presentation of the access token alone is not sufficient to
access a Protected Resource. This has several use cases, including,
but not limited to, the following:
- Non-repudiation: high-security deployments may require that
requests be authenticated (signed) in a non-repudiateable way[1]
- Access to protected resources is not protected by SSL, so that
access tokens may leak.
- End-to-end-integrity: even if SSL _is_ used, network
infrastructure may strip SSL protection before the request reaches
the protected resource. The protected resource, however, may require
end-to-end integrity.
If the Server requires that the Client authenticate PR access
requests, then the Client uses the following mechanism to sign their
HTTP requests: [...]"
Then, we basically drop the old Section 5.3 here (except we use the
client secret instead of the access token secret). Eventually,
instead of Section 5.3, we may have Brian's new signature scheme
section here, which would add the option of public-key crypto[1], etc.
What do you guys think?
Dirk.
[1] Technically speaking, the goal of non-repudiation can only be
achieved once we have public-key crypto.
_______________________________________________
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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
