Re: REST-GSS I-D

On Wed, Jun 8, 2011 at 3:32 PM, Phil Hunt <phil.hunt@oracle.com> wrote:
> I've been reading your draft and attended your presentation at W3C. Trying to understand how this compares and/or complements OAuth.
>
> While different (and interesting), it still seems to involve multiple request/response exchanges much like OAuth 2-leg flows.

That's up to the mechanism.  The GSS-API does not dictate that there
must be more than one security context token in the exchange.

You do need two or more tokens if you're going to do mutual
authentication.   And you need mutual authentication if you want
channel binding.  But all that is optional.  Mutual authentication
adds value, but it's not required.

> There also seems to be an implication that the REST endpoint must be relative to the resource being accessed. OAuth's token and authorization end-points can be decoupled allowing for centralization of token services.  OAuth seems to have more flexibility and a broader pattern.

This is certainly true.  You don't get to replay tokens (you wouldn't
want to anyways).  New authentication implies new tokens.  This does
NOT mean that you can't reuse/cache certain things.  For example,
Kerberos tickets, OCSP responses, passwords, etcetera, can all be
cached, and they can be part of the security context tokens -- but
typically one also has some sort of äuthenticator", a proof of
possession (e.g., a signature, in the case of PKI).

Nico
--

Received on Wednesday, 8 June 2011 20:43:36 UTC