IETF Logo Mail Archive

[OAUTH-WG] OAuth 2 delegation flow names

Marius Scurtescu <mscurtescu@google.com> Tue, 08 June 2010 18:16 UTC

Return-Path: <mscurtescu@google.com>
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C897A3A68BC for <oauth@core3.amsl.com>; Tue, 8 Jun 2010 11:16:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.562
X-Spam-Level:
X-Spam-Status: No, score=-99.562 tagged_above=-999 required=5 tests=[AWL=-0.185, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4WgfQ5PNOiAZ for <oauth@core3.amsl.com>; Tue, 8 Jun 2010 11:16:57 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id D95413A68E3 for <oauth@ietf.org>; Tue, 8 Jun 2010 11:16:56 -0700 (PDT)
Received: from hpaq14.eem.corp.google.com (hpaq14.eem.corp.google.com [172.25.149.14]) by smtp-out.google.com with ESMTP id o58IGscL008795 for <oauth@ietf.org>; Tue, 8 Jun 2010 11:16:54 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1276021014; bh=mTbohf/Q1mZpbz84qIFK6G+xVmw=; h=MIME-Version:From:Date:Message-ID:Subject:To:Content-Type; b=ZJ5BM2J2DmPBSfEXparOx+YUaSTBcNpczjuCXL/umkCOTo3gxtLGN2Ap2TsATKHeo HS5MVE0kY882gEPtGQ0Kw==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:from:date:message-id:subject:to:content-type; b=agqPtmnJ6vo7wGnkWGZ0+9nKlRzsGbUg/uA0yTDtV4sZ7Oq1ws486f4Tw1PmVkWAP qYY7kwbkdFUL8Mr4+jM1g==
Received: from pwi5 (pwi5.prod.google.com [10.241.219.5]) by hpaq14.eem.corp.google.com with ESMTP id o58IGLrv000677 for <oauth@ietf.org>; Tue, 8 Jun 2010 11:16:54 -0700
Received: by pwi5 with SMTP id 5so163526pwi.26 for <oauth@ietf.org>; Tue, 08 Jun 2010 11:16:53 -0700 (PDT)
Received: by 10.141.101.16 with SMTP id d16mr13514030rvm.169.1276021013495; Tue, 08 Jun 2010 11:16:53 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.141.124.13 with HTTP; Tue, 8 Jun 2010 11:16:33 -0700 (PDT)
From: Marius Scurtescu <mscurtescu@google.com>
Date: Tue, 08 Jun 2010 11:16:33 -0700
Message-ID: <AANLkTilDRHVUgD7YCjW670qQpMzrLgUNcNI1XHW95JnV@mail.gmail.com>
To: OAuth WG <oauth@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"
Subject: [OAUTH-WG] OAuth 2 delegation flow names
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Jun 2010 18:16:57 -0000

Hi,

I find the names of the user delegation flows a bit misleading. These
flows are currently named: "User-Agent", "Web Server" and "Device".
The names are pointing to the typical client for these flows, but
these are not the only use cases, and this is where it can be
misleading.

For example:
- "User-Agent" can also be used use by native apps and web apps
- "Web Server" can also be used by JavaScript based clients and native apps
- "Device" can also be used by native apps and web apps

Instead of naming them after a typical client, maybe we can name them
based on some technical characteristics of the flow.

The "User-Agent" flow is characterized by the fact that the access
token is returned directly to the client, no verification code step is
used.

The "Web Server" flow is characterized by the fact that a verification
code is first returned which then needs to be exchanged for tokens
with a direct call from client to authz server.

The "Device" flow is mainly characterized by the fact that a polling
mechanism is used to retrieve the tokens.

How about the following names:
- "Web Server" -> "Verification Code"
- "Device" -> "Polling"

Not sure about the User-Agent flow. Since this flow does not have any
direct calls from client to authz server, everything is passed through
the browser, "User-Agent" could be the right name?

Thoughts?

Marius

v2.23.0 | Report a Bug | By Email