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

John Bradley <jbradley@mac.com> Fri, 29 October 2010 10:49 UTC

Return-Path: <jbradley@mac.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 0C9873A6A2B for <oauth@core3.amsl.com>; Fri, 29 Oct 2010 03:49:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.529
X-Spam-Level:
X-Spam-Status: No, score=-1.529 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, 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 8+wnDa8lLExa for <oauth@core3.amsl.com>; Fri, 29 Oct 2010 03:49:16 -0700 (PDT)
Received: from asmtpout024.mac.com (asmtpout024.mac.com [17.148.16.99]) by core3.amsl.com (Postfix) with ESMTP id AA7893A689C for <oauth@ietf.org>; Fri, 29 Oct 2010 03:49:16 -0700 (PDT)
MIME-version: 1.0
Received: from [192.168.1.3] (190-22-62-69.baf.movistar.cl [190.22.62.69]) by asmtp024.mac.com (Oracle Communications Messaging Exchange Server 7u4-18.01 64bit (built Jul 15 2010)) with ESMTPSA id <0LB1008Z3ST1BY70@asmtp024.mac.com> for oauth@ietf.org; Fri, 29 Oct 2010 03:51:10 -0700 (PDT)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2010-10-29_06:2010-10-29, 2010-10-29, 1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=3 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1004200000 definitions=main-1010290036
Content-type: multipart/signed; boundary=Apple-Mail-455-766899986; protocol="application/pkcs7-signature"; micalg=sha1
From: John Bradley <jbradley@mac.com>
In-reply-to: <180155C5EA10854997314CA5E063D18FE59464@TK5EX14MBXC117.redmond.corp.microsoft.com>
Date: Thu, 28 Oct 2010 21:22:24 -0300
Message-id: <E062F758-ED2E-4020-AA6B-65C7DB62BA1C@mac.com>
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>
To: Anthony Nadalin <tonynad@microsoft.com>
X-Mailer: Apple Mail (2.1081)
X-Mailman-Approved-At: Fri, 29 Oct 2010 05:09:37 -0700
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 10:53:30 -0000

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/>w/>.
>>> 
>>>                                                               -- 
>>> 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