Re: [OAUTH-WG] Simple Web Discovery

Mike Jones <Michael.Jones@microsoft.com> Wed, 27 October 2010 17:56 UTC

Return-Path: <Michael.Jones@microsoft.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 80FCE3A695E for <oauth@core3.amsl.com>; Wed, 27 Oct 2010 10:56:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.406
X-Spam-Level:
X-Spam-Status: No, score=-10.406 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
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 CP+oLy2RKbN0 for <oauth@core3.amsl.com>; Wed, 27 Oct 2010 10:56:48 -0700 (PDT)
Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 6C51B3A6803 for <oauth@ietf.org>; Wed, 27 Oct 2010 10:56:48 -0700 (PDT)
Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 27 Oct 2010 10:58:38 -0700
Received: from TK5EX14MBXC207.redmond.corp.microsoft.com ([169.254.7.105]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.01.0255.003; Wed, 27 Oct 2010 10:58:38 -0700
From: Mike Jones <Michael.Jones@microsoft.com>
To: Dick Hardt <dick.hardt@gmail.com>
Thread-Topic: Simple Web Discovery
Thread-Index: Act1ZjJjDCe6rYI9TGy/HfaZ555XawAZUTiAAA0ktKA=
Date: Wed, 27 Oct 2010 17:58:37 +0000
Message-ID: <4E1F6AAD24975D4BA5B1680429673943245A3004@TK5EX14MBXC207.redmond.corp.microsoft.com>
References: <4E1F6AAD24975D4BA5B16804296739432459E77D@TK5EX14MBXC207.redmond.corp.microsoft.com> <44E8DE65-84D7-4FD9-BACF-1E2F58E4FD82@gmail.com>
In-Reply-To: <44E8DE65-84D7-4FD9-BACF-1E2F58E4FD82@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [157.54.51.78]
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943245A3004TK5EX14MBXC207r_"
MIME-Version: 1.0
Cc: "openid-specs-ab@lists.openid.net" <openid-specs-ab@lists.openid.net>, "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Simple Web Discovery
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: Wed, 27 Oct 2010 17:56:53 -0000

These posts of Yaron's outline the basic vision and flows:
                http://www.goland.org/adhocauthentication/
                http://www.goland.org/oauthgenericdelegation/

We hope to also come out with a description in Internet-draft style soon to provide concrete details about possible implementation choices for this kind of end-to-end scenario.  But if you dig into these posts, I believe you'll find there's a lot there already at the conceptual level.

                                                                -- Mike

From: Dick Hardt [mailto:dick.hardt@gmail.com]
Sent: Tuesday, October 26, 2010 9:38 PM
To: Mike Jones
Cc: oauth@ietf.org; openid-specs-ab@lists.openid.net
Subject: Re: Simple Web Discovery


On 2010-10-26, at 4:33 PM, Mike Jones wrote:


Having a simple discovery method for services and resources is key to enabling many Internet scenarios that require interactions among parties that do not have pre-established relationships.  For instance, if Joe, with e-mail address joe@example.com<mailto:joe@example.com>, wants to share his calendar with Mary, then Mary's calendar service, in the general case, will need to discover the location of Joe's calendar service.  For example, Mary's calendar service might discover that Joe's calendar service is located at http://calendars.proseware.com/calendar/joseph by doing discovery for a service named urn:adatum.com:calendar  at example.com<http://example.com> for the account joe.

I think it would be really useful to complete the scenario. What happens when Mary's service discovers Joe's calendar service? How does Joe give Mary's calendar service permission to access his calendar? How does Joe identify Mary?

-- Dick