W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2009

RE: Authentication realm

From: Eran Hammer-Lahav <eran@hueniverse.com>
Date: Mon, 7 Dec 2009 16:52:19 -0700
To: "Roy T. Fielding" <fielding@gbiv.com>
CC: Julian Reschke <julian.reschke@gmx.de>, "HTTP Working Group (ietf-http-wg@w3.org)" <ietf-http-wg@w3.org>, "OAuth WG (oauth@ietf.org)" <oauth@ietf.org>
Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343785293C4C@P3PW5EX1MB01.EX1.SECURESERVER.NET>

> -----Original Message-----
> From: Roy T. Fielding [mailto:fielding@gbiv.com]
> Sent: Monday, December 07, 2009 3:15 PM

> Realm is useful for distinguishing multiple authentication realms on the same
> server.  I don't see how that would change, regardless of the new auth
> mechanism.  It is part of the credential caching mechanism of clients.

I agree. But if we define a mechanism that goes further and define credential types supported by the server (i.e. a combination of authorization, crypto, scope, etc.), realm becomes redundant. If the server names it token types and then ask for one of those types, it provides a similar functionality as realm but goes further.

I am trying to avoid having two mechanisms that greatly overlap but are not exactly the same.

> BTW, I find it odd that token auth has
>    10.4.  Plaintext Storage of Credentials
> I thought we learned that lesson a long time ago.  Why is it not using a hash
> of the shared secret instead of the shared secret, like how digest md5-sess
> uses H(user:realm:password)?

Because the first draft is based on OAuth 1.0, and we have yet to address this... This text was inherited from the previous version.

Thanks! I've got my first issue to address. :-)

Received on Monday, 7 December 2009 23:52:24 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:52 UTC