+1 for basic signature support
there is a need to protect end-users from token abuse by rogue resource
servers (see
http://tools.ietf.org/html/draft-ietf-oauth-v2-10#section-5, paragraph
3). Signatures based on a token secret is one way to prevent this kind
of attack.
Signature mechanisms aiming for other purposes (e.g. client
authentication) should be defined as extensions in my opinion.
>I think draft –05 went too far in terms of additional parameters for
requesting tokens with secrets. Since the core spec lacks any form of
discovery, I think servers should simply issue whatever token >they deem
appropriate to the client (bearer, with secret, etc.). Other extensions
can define parameters to allow the client to ask, and the server to
advertise whaich schemes are supported.
>My approach is for the server to issue a token with two additional
parameters: signature algorithm and secret. Based on that, the client
will send requests with a few additional parameters (nonce, >timestamp,
signature – maybe combined into one).
+1
This is simple but sufficient. The authz server and resource server have
a strong coupling anyway so the authz server should know what the
resource server expects. Does this also mean the client MUST send signed
requests if the authz server issued a token secret?
regards,
Torsten.
Am 24.09.2010 03:43, schrieb Eran Hammer-Lahav:
Since much of this recent debate was done off list, I'd like to ask people
to simply express their support or objection to including a basic signature
feature in the core spec, in line with the 1.0a signature approach.
This is not a vote, just taking the temperature of the group.
EHL
_______________________________________________
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
