Subject: [OAUTH-WG] Simple Web Discovery

From: Mike Jones <[email-masked]>
Date: Tue, 26 Oct 2010 23:33:29 +0000

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 [email-masked], 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

---

From: Dick Hardt <[email-masked]>
Date: Tue, 26 Oct 2010 21:38:25 -0700

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 [email-masked], 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.

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

---

From: Mike Jones <[email-masked]>
Date: Wed, 27 Oct 2010 17:58:37 +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:[email-masked]]
Sent: Tuesday, October 26, 2010 9:38 PM
To: Mike Jones
Cc: [email-masked]; [email-masked]
Subject: Re: Simple Web Discovery

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 [email-masked]<mailto:[email-masked]>, 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.

-- Dick

---

From: Lukas Rosenstock <[email-masked]>
Date: Fri, 29 Oct 2010 13:04:40 +0200

Hello!
This draft is looking nice, the idea and specification is simple and
straightforward. I would like to draw the connection to other
discovery approaches.

The introductory example in the draft was this one:
GET /.well-known/simple-web-discovery?principal=mailto:[email-masked]&service=urn:adatum.com:calendar
HTTP/1.1

This returns the following response:
{
 "locations":["http://calendars.proseware.com/calendars/joseph"]
}

As per my understanding - please correct me if I'm wrong - this should
be semantically equivalent to the following:
1) Perform host-meta discovery for example.com, which returns an XRD
with the webfinger endpoint.
2) Do webfinger for [email-masked].
3) The final XRD contains the following:
<XRD>
[...]
<Link rel="urn:adatum.com:calendar"
href="http://calendars.proseware.com/calendars/joseph" />
[...]
</XRD>

Both approaches work, but SWD is a shortcut removes parsing
requirements and fetching roundtrips from the client.

Thoughts, anyone?!

Regards,
 Lukas Rosenstock

2010/10/27 Mike Jones <[email-masked]>:
> Yaron Goland and I are submitting this Simple Web Discovery (SWD) 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.
>
>
>
>                                                                 -- Mike

---

From: John Panzer <[email-masked]>
Date: Fri, 29 Oct 2010 11:35:08 -0700

I think that it would be good to have a writeup like this that describes the
differences and pros and cons of each approach. Perhaps on a Wiki page?

Some random thoughts:

One thing:  host-meta is highly cacheable, so the # of round trips will
hopefully be comparable for large services with significant traffic.  In
fact the user XRD is also cacheable as well so there can be zero round
trips.  This proposal defines a mechanism separate from HTTP caching in
order to cache responses, it'd be good to have a rationale for doing that
(and to have an explanation of how this should interact with additional HTTP
level caching.)

This mechanism appears to require multiple round trips to a server if you
want to discover multiple services.

This proposal seems to require that the /well-known provider run a
significant service on their endpoint, as opposed to just dropping a file in
place.  I think that the forwarding mechanism may be a way around that?  How
would I hook into this mechanism if I really only can drop static files on
my web server, but I can perhaps use cloud services that I've registered
with to actually power the discovery?

--
John Panzer / Google
[email-masked] / abstractioneer.org <http://www.abstractioneer.org/> /
@jpanzer

On Fri, Oct 29, 2010 at 4:04 AM, Lukas Rosenstock <[email-masked]>wrote:

> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: John Bradley <[email-masked]>
Date: Sun, 31 Oct 2010 08:48:28 -0300

John is correct.  

Also when using a URL identifier like a blog it is possible to publish a XRD via link headers as well.  
That helps make publishing meta-data open to a broader selection of users.

If a site wanted to have a oAuth protected XRD service there is nothing to stop that.

In XRI/XRDS resolution we had per service discovery, much the same as MS is proposing for similar reasons.

People criticized that in XRI/XRDS as being too complicated.  That is why it is not in the current XRD spec.

We do need to make a side by side comparison.

I know that people have asked for a JSON format XRD document option.   That is on the OASIS TC list of things to work on.

John Bradley
On 2010-10-29, at 3:35 PM, John Panzer wrote:

> I think that it would be good to have a writeup like this that describes the differences and pros and cons of each approach. Perhaps on a Wiki page?
> 
> Some random thoughts:
> 
> One thing:  host-meta is highly cacheable, so the # of round trips will hopefully be comparable for large services with significant traffic.  In fact the user XRD is also cacheable as well so there can be zero round trips.  This proposal defines a mechanism separate from HTTP caching in order to cache responses, it'd be good to have a rationale for doing that (and to have an explanation of how this should interact with additional HTTP level caching.)
> 
> This mechanism appears to require multiple round trips to a server if you want to discover multiple services.  
> 
> This proposal seems to require that the /well-known provider run a significant service on their endpoint, as opposed to just dropping a file in place.  I think that the forwarding mechanism may be a way around that?  How would I hook into this mechanism if I really only can drop static files on my web server, but I can perhaps use cloud services that I've registered with to actually power the discovery?
> 
> --
> John Panzer / Google
> [email-masked] / abstractioneer.org / @jpanzer
> 
> 
> 
> On Fri, Oct 29, 2010 at 4:04 AM, Lukas Rosenstock <[email-masked]> wrote:
> Hello!
> Openid-specs-ab mailing list
> [email-masked]
> http://lists.openid.net/mailman/listinfo/openid-specs-ab

---

From: Lukas Rosenstock <[email-masked]>
Date: Sun, 31 Oct 2010 16:22:42 +0100

> differences and pros and cons of each approach. Perhaps on a Wiki page?

Feel free to copy this to a wiki page:

1) Server-side requirements:
- XRD/Webfinger: creating .well-known, placing a static host-meta file
with appropriate content type, a Webfinger endpoint which could be
static as well (e.g. by mapping to a file named like the account
identifier)
- SWD: creating .well-known, placing a dynamic endpoint which can
parse the input (requested user and service) and return the output as
one service from a list of services for the user

2) Server delegation:
- XRD/Webfinger: host-meta can point to a third-party host for rel="lrdd"
- SWD: defines its own delegation mechanism based on a JSON file

3) Authentication:
- not fully defined but possible in both approaches via HTTP Basic
authentication or OAuth

4) Consumer-side requirements:
- XRD/Webfinger: fetching host-meta (preferrably with caching),
parsing XML for lrdd endpoint; webfinger request, parsing XML for
required service links
- SWD: one request for user and service, parsing JSON for endpoint;
multiple trips for multiple requests or if redirection is required

5) Network bandwidth requirements:
- XRD/Webfinger: two requests (host-meta and lrdd), of which one is
cacheable for multiple users (same domain); transmission of irrelevant
data is very likely if XRDs are getting bigger
- SWD: one request only, lightweight data; but can become inefficient
if a longer list of services is fetched (individually)

> with to actually power the discovery?

I've tried to include these thoughts in the compilation.

Lukas