New text:

        Clients access protected resources by presenting an access token to the 
resource server.
        Access tokens are bearer tokens, where the token string acts as a 
password. This requires
        treating the access token with the same care as other passwords. Access 
tokens SHOULD NOT
        be sent in the clear over an insecure channel.

EHL


On 7/13/10 9:02 AM, "Eran Hammer-Lahav" <e...@hueniverse.com> wrote:

I am ok replacing it with 'acts as a password'.

EHL


On 7/13/10 8:55 AM, "Dirk Balfanz" <balf...@google.com> wrote:



On Tue, Jul 13, 2010 at 7:18 AM, Eran Hammer-Lahav <e...@hueniverse.com> wrote:
>From the client's perspective, they are 'shared symmetric secrets' because
the client has to store them as-is and present them as-is. The act exactly
like passwords. I added that text to make that stand out.

When using passwords, the server doesn't need to store them in plain-text
either (e.g. uses a way one hash).

That's why we don't call passwords "shared symmetric secrets", either. The 
verifier of a passwords can verify it without knowing the secret. In that 
sense, it's not "shared" with the verifier.

I would like the specification to make it clear that bearer tokens are only
secure while they remain *secret* and that *anyone* holding them can gain
full access to what their protect.

I think the word "capability" expresses that better than the word "shared 
secret".

Dirk.


EHL

On 7/12/10 10:39 PM, "Brian Eaton" <bea...@google.com> wrote:

> Section 5: http://tools.ietf.org/html/draft-ietf-oauth-v2-10#section-5
>
> Calling access tokens "shared symmetric secrets" is misleading,
> because if they are implemented well the authorization server and
> protected resource do not store a copy of the secret.
>
> Instead they store a one-way hash of the token.  Or they verify the
> token cryptographically.  Under no circumstances do they need to store
> a copy.
>
> I'd suggest the following language:
>
> "Access tokens are bearer authentication tokens or capabilities."
>
> Cheers,
> Brian
> _______________________________________________
> 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

Reply via email to