[OAUTH-WG] OAuth Device Flow data from Microsoft implementations
Mike Jones <Michael.Jones@microsoft.com> Sun, 08 May 2016 05:27 UTC
Return-Path: <Michael.Jones@microsoft.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 622BC12B04F for <oauth@ietfa.amsl.com>; Sat, 7 May 2016 22:27:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level:
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9daFOnTlIpLs for <oauth@ietfa.amsl.com>; Sat, 7 May 2016 22:27:53 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0119.outbound.protection.outlook.com [65.55.169.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7508E12B00F for <oauth@ietf.org>; Sat, 7 May 2016 22:27:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Y3cGYrVLAWHUOKKlrZ++VOTm/5AF5hpC3HRd0cKivsw=; b=I0tBByFOxiHiyzj6MJ3ZiQb/lHZhVsIh9hCWi2m7UO+CltpjMnQPtMFefY/M1pB5bot3aq8vbrTkoOmRFVfzj26Nay6ADyxlhNGJ4b+lo4uxV26E2E90HPI+maK0DQDUEzV789JeMWhU1yiCBBUcQfrey+iR+TpIjJCU/4YWA8U=
Received: from SN1PR0301MB1645.namprd03.prod.outlook.com (10.162.130.139) by SN1PR0301MB1648.namprd03.prod.outlook.com (10.162.130.142) with Microsoft SMTP Server (TLS) id 15.1.485.9; Sun, 8 May 2016 05:27:51 +0000
Received: from SN1PR0301MB1645.namprd03.prod.outlook.com ([10.162.130.139]) by SN1PR0301MB1645.namprd03.prod.outlook.com ([10.162.130.139]) with mapi id 15.01.0485.015; Sun, 8 May 2016 05:27:51 +0000
From: Mike Jones <Michael.Jones@microsoft.com>
To: "oauth@ietf.org" <oauth@ietf.org>
Thread-Topic: OAuth Device Flow data from Microsoft implementations
Thread-Index: AdGo2nd/NnTx4o0gSPCmDyZ4h6uFHg==
Date: Sun, 08 May 2016 05:27:51 +0000
Message-ID: <SN1PR0301MB16455DFD74EA565D1FB99A4EF57F0@SN1PR0301MB1645.namprd03.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [12.130.119.128]
x-ms-office365-filtering-correlation-id: b8eefce9-6d0f-4e67-2a7c-08d377017fd3
x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1648; 5:isCN+41pF+b71WFnxl4Mxu1anrVWBrFfiv5HriVuzkrMjbAc8vNg8Li4W+sQ1kFNXuA5wr1clWI201UcGcz57neUT0TQiczn5aLMd4ZbRhmkg5++w1it0lU1j/yJFFigPWtawTTpo5NrNdfADK7jew==; 24:LeOnzaDPyZvkH9bjZKtlaVnfPkUDH7TSafkz9UvRPhYg48rL82QScp9w0e4vfFR060jdchGZWDupo2lV10CuuOIKv0I3zQSglNTShX0xlj0=; 7:eDH5MSF8OTCmQ/py0A+khvSnY0PaYLk7l6il6PE1/UQA46AM3JqZWmxaGFC8OaQWxd+v51QVgbSS0plQ8h48+TCIuHd9ucE1prsW4hxe0Yg97Zu8BrF9gUTgVi5YJta+Z6tDqxz06v/kZ1RBgR7ju6uDX4esrS3wRBQN8FtZ1RwDPvUEsuTh3jTEmYnK0EAPuEz8ACeund2uCTGZ2lzYyA==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1648;
x-microsoft-antispam-prvs: <SN1PR0301MB1648775D8611C0162742D652F57F0@SN1PR0301MB1648.namprd03.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:SN1PR0301MB1648; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1648;
x-forefront-prvs: 09368DB063
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(9170700001)(10400500002)(10290500002)(86612001)(122556002)(1730700002)(5005710100001)(5003600100002)(50986999)(8990500004)(2906002)(5008740100001)(3660700001)(54356999)(19300405004)(2900100001)(5004730100002)(66066001)(2501003)(107886002)(110136002)(16236675004)(19625215002)(77096005)(8936002)(189998001)(11100500001)(1220700001)(5002640100001)(99286002)(33656002)(9686002)(586003)(87936001)(102836003)(81166005)(790700001)(6116002)(3846002)(10090500001)(81156013)(3280700002)(86362001)(19580395003)(2351001)(5630700001)(5640700001)(450100001)(15975445007)(76576001)(92566002)(74316001)(229853001); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0301MB1648; H:SN1PR0301MB1645.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en;
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_SN1PR0301MB16455DFD74EA565D1FB99A4EF57F0SN1PR0301MB1645_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 May 2016 05:27:51.1496 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1648
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/v6VhunO7C4t-iGdB-TSoeUmTgto>
Subject: [OAUTH-WG] OAuth Device Flow data from Microsoft implementations
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/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: Sun, 08 May 2016 05:27:55 -0000
I sat down with the two Microsoft teams that have implementations of the OAuth Device Flow and compared what they currently have built to draft-ietf-oauth-device-flow. Here's some data that we assembled...
One of the two implementations has an optional "message" parameter containing text that is to be shown to the user. This one also uses a "mkt" parameter to indicate the locale of the message (as opposed to, for instance, ui_locales). The developers want to know what the working group thinks of the possibility of supporting some kind of a "message" parameter.
The developers would like an example in the spec that shows the use of simple polling.
We are using the "device_code" grant type. The token request is missing from the spec, including the grant type being missing from the spec.
One implementation adds two new errors: auth_pending and expired_device_code. (The spec uses authorization_pending.) This implementation also uses the access_denied error defined by RFC 6749.
The other uses authorization_pending, code_expired, and authorization_declined. The developers agreed that authorization_declined should become access_denied. That implementation hasn't implemented slow_down.
The developers wanted to ask what the right code expiration error code is. They felt that invalid_grant may be a bit too broad.
Our requests in both implementations do match the specification.
Our implementations currently use verification_url instead of verification_uri. This should be changed to verification_uri to match IETF naming practices.
Our default expires_in is 900 (15 minutes). Our default interval is 5 seconds.
Both implementations do intend to migrate to the syntax in the eventual final specification.
-- Mike