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
