Re: [OAUTH-WG] [Openid-specs-ab] Simple Web Discovery

Eran Hammer-Lahav <eran@hueniverse.com> Fri, 29 October 2010 16:40 UTC

Return-Path: <eran@hueniverse.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 C97F13A67F3 for <oauth@core3.amsl.com>; Fri, 29 Oct 2010 09:40:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.507
X-Spam-Level:
X-Spam-Status: No, score=-2.507 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, FUZZY_CPILL=0.001]
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 Aq6EwZ+0zZwC for <oauth@core3.amsl.com>; Fri, 29 Oct 2010 09:40:32 -0700 (PDT)
Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 854783A65A5 for <oauth@ietf.org>; Fri, 29 Oct 2010 09:39:42 -0700 (PDT)
Received: (qmail 31330 invoked from network); 29 Oct 2010 16:41:33 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 29 Oct 2010 16:41:33 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Fri, 29 Oct 2010 09:40:50 -0700
From: Eran Hammer-Lahav <eran@hueniverse.com>
To: Anthony Nadalin <tonynad@microsoft.com>, John Bradley <jbradley@mac.com>
Date: Fri, 29 Oct 2010 09:40:35 -0700
Thread-Topic: [OAUTH-WG] [Openid-specs-ab] Simple Web Discovery
Thread-Index: AQHLd4bhFCHF/EU1cEGyKlQi5dXrcJNYH+iwgAAAhwA=
Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343D46D80E9D@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <20101027013941.E742F21F40@mail.zxidp.org> <180155C5EA10854997314CA5E063D18FE573EE@TK5EX14MBXC117.redmond.corp.microsoft.com> <79DB6BC1-62CA-4B84-8B45-5E01044CFC4F@ve7jtb.com> <180155C5EA10854997314CA5E063D18FE59464@TK5EX14MBXC117.redmond.corp.microsoft.com> <E062F758-ED2E-4020-AA6B-65C7DB62BA1C@mac.com> <180155C5EA10854997314CA5E063D18FE62B29@TK5EX14MBXC113.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E72343D46D80E92@P3PW5EX1MB01.EX1.SECURESERVER.NET> <180155C5EA10854997314CA5E063D18FE63CA7@TK5EX14MBXC113.redmond.corp.microsoft.com>
In-Reply-To: <180155C5EA10854997314CA5E063D18FE63CA7@TK5EX14MBXC113.redmond.corp.microsoft.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "sampo@zxidp.org" <sampo@zxidp.org>, "openid-specs-ab@lists.openid.net" <openid-specs-ab@lists.openid.net>, the Connect work group <openid-specs-connect@lists.openid.net>, "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] [Openid-specs-ab] 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: Fri, 29 Oct 2010 16:40:55 -0000

JRD does not require an XML parser. If you want to talk about simplicity, "engage" is simpler than "reinvent".

EHL

> -----Original Message-----
> From: Anthony Nadalin [mailto:tonynad@microsoft.com]
> Sent: Friday, October 29, 2010 9:37 AM
> To: Eran Hammer-Lahav; John Bradley
> Cc: sampo@zxidp.org; openid-specs-ab@lists.openid.net; the Connect work
> group; oauth@ietf.org
> Subject: RE: [OAUTH-WG] [Openid-specs-ab] Simple Web Discovery
> 
> Like an XML parser
> 
> -----Original Message-----
> From: Eran Hammer-Lahav [mailto:eran@hueniverse.com]
> Sent: Friday, October 29, 2010 9:24 AM
> To: Anthony Nadalin; John Bradley
> Cc: sampo@zxidp.org; openid-specs-ab@lists.openid.net; the Connect work
> group; oauth@ietf.org
> Subject: RE: [OAUTH-WG] [Openid-specs-ab] Simple Web Discovery
> 
> Can you list those "quite a few more complex feature"?
> 
> XRD (and JRD) were carefully balanced over 3 years to produce a simple
> specification that covers basic discovery needs without any unnecessary
> complexity. It was coordinated with IETF, OASIS, OpenID, and W3C efforts,
> and successfully adopted by new lightweight protocols. To invent yet
> another format that is clearly overlapping without even trying to engage in
> the XRD/JRD work is poor community participation.
> 
> EHL
> 
> > -----Original Message-----
> > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> > Of Anthony Nadalin
> > Sent: Friday, October 29, 2010 8:57 AM
> > To: John Bradley
> > Cc: sampo@zxidp.org; openid-specs-ab@lists.openid.net; the Connect
> > work group; oauth@ietf.org
> > Subject: Re: [OAUTH-WG] [Openid-specs-ab] Simple Web Discovery
> >
> > I would not say that this is just a JSON version of XRD, as XRD has
> > quite a few more complex feature. What is being suggested here is
> > being able to use OAuth for the authorization/delegation to discovery
> > information in a very simple chunkable forward means.
> >
> > -----Original Message-----
> > From: John Bradley [mailto:jbradley@mac.com]
> > Sent: Thursday, October 28, 2010 5:22 PM
> > To: Anthony Nadalin
> > Cc: the Connect work group; sampo@zxidp.org; openid-specs-
> > ab@lists.openid.net; oauth@ietf.org
> > Subject: Re: [Openid-specs-ab] [OAUTH-WG] Simple Web Discovery
> >
> > If there is no authorization mechanism,  then this is just a JSON
> > version of XRD.
> >
> > Not that you couldn't add authorization to XRD.
> >
> > We were planning on doing that as an option for a proxy resolution
> > flow that would look quite similar.
> >
> > The way that the existing XRI resolver works is quite similar to what
> > you describe filtering by service.
> > One of the use cases has been adding authentication, but there was
> > never enough interest.
> >
> > Too bad MS didn't participate in XRD.
> >
> > John B.
> > On 2010-10-28, at 8:42 PM, Anthony Nadalin wrote:
> >
> > > So not sure that this would be handled by the SWD itself but as
> > > pointed out in the SWD specification is that the SWD may be
> > > accompanied by an authorization header and this is where I would
> > > expect that to happen
> > >
> > > -----Original Message-----
> > > From: openid-specs-connect-bounces@lists.openid.net
> > > [mailto:openid-specs-connect-bounces@lists.openid.net] On Behalf Of
> > > John Bradley
> > > Sent: Thursday, October 28, 2010 8:41 AM
> > > To: the Connect work group
> > > Cc: sampo@zxidp.org; openid-specs-ab@lists.openid.net;
> > > oauth@ietf.org
> > > Subject: Re: [Openid-specs-ab] [OAUTH-WG] Simple Web Discovery
> > >
> > > In the case where the user logs in to a RP with a PPID type identifier.
> > >
> > > How could the person then allow the RP to discover their service
> > endpoints.
> > > Also conversely would publishing the endpoint provide a way for the
> > > RP to
> > correlate the user without permission.
> > >
> > > One common practice for openID PPID is that the IdP generates the
> > > PPID
> > via AES128(actual ID + RP or sector identifier).
> > >
> > > In that case the RP could do an oauth flow to the IdP discovery
> > > endpoint to
> > get permission to see the user endpoints.
> > > The IdP could decrypt the opaque identifier to determine the actual
> > subject.
> > >
> > > That would protect the non correlation unless the user decides to
> > > permit
> > discovery.
> > >
> > > The model if not the details seem similar to some work that is being
> > submitted to the ITU-T as I understand it.
> > >
> > > John B.
> > >
> > >
> > > On 2010-10-28, at 12:07 PM, Anthony Nadalin wrote:
> > >
> > >> Sampo, can you give a usecase of how you would use the pairwise
> > >>
> > >> -----Original Message-----
> > >> From: openid-specs-ab-bounces@lists.openid.net
> > >> [mailto:openid-specs-ab-bounces@lists.openid.net] On Behalf Of
> > >> sampo@zxidp.org
> > >> Sent: Tuesday, October 26, 2010 6:40 PM
> > >> To: Mike Jones
> > >> Cc: sampo@zxidp.org; openid-specs-ab@lists.openid.net;
> > >> oauth@ietf.org; openid-specs-connect@lists.openid.net
> > >> Subject: Re: [Openid-specs-ab] [OAUTH-WG] Simple Web Discovery
> > >>
> > >> Simple enough spec. I like the notion of service type. However some
> > questions to answer:
> > >>
> > >> How would one convey saml2:Assertion as the "principal"? Or how
> > >> would
> > one convey a saml2:NameID as the "principal"?
> > >>
> > >> Or in more generic sense, how would one convey a pairwise
> pseudonym
> > as principal?
> > >>
> > >> Cheers,
> > >> --Sampo
> > >>
> > >> Mike Jones <Michael.Jones@microsoft.com> said:
> > >>> 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, 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 for the account joe.
> > >>>
> > >>> Yaron Goland<http://www.goland.org/> and I are submitting this
> > >>> Simple
> > Web Discovery
> > (SWD)<http://self-issued.info/docs/draft-jones-simple-web-
> > discovery-00.html> draft (attached and at
> > http://self-issued.info/docs/draft-
> > jones-simple-web-discovery-00.html) for consideration by the community
> > to address this need.  SWD is simple to understand and implement,
> > enables different permissions to be applied to discovery of different
> > services, and is JSON-based.  I look forward to discussing this with
> > many of you next week at
> > IIW<http://www.internetidentityworkshop.com/iiwxi-11-in-mountain-
> > view/>.
> > >>>
> > >>>                                                               --
> > >>> Mike
> > >>>
> > >>> _______________________________________________
> > >>> OAuth mailing list
> > >>> OAuth@ietf.org
> > >>> https://www.ietf.org/mailman/listinfo/oauth
> > >>>
> > >> _______________________________________________
> > >> Openid-specs-ab mailing list
> > >> Openid-specs-ab@lists.openid.net
> > >> http://lists.openid.net/mailman/listinfo/openid-specs-ab
> > >>
> > >> _______________________________________________
> > >> openid-specs-connect mailing list
> > >> openid-specs-connect@lists.openid.net
> > >> http://lists.openid.net/mailman/listinfo/openid-specs-connect
> > >
> > > _______________________________________________
> > > Openid-specs-ab mailing list
> > > Openid-specs-ab@lists.openid.net
> > > http://lists.openid.net/mailman/listinfo/openid-specs-ab
> >
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth