Re: [apps-discuss] Looking at Webfinger

[John Bradley <[e-mail]>]

At the moment we have WF adding query parameters to host-meta to avoid multiple round trips in the case where you can have a dynamic service.

The goal for SWD was to get the thing you are looking for on the first try if possible.  If that is not possible return a cacheable document that gives you the new base URL for a second query.

Without the dynamic service behind host-meta you get a template on the first try and then must expand the template for your second try.   
You also loose the ability to query for a specific rel  because there is only one template parameter for the URL.

I agree that host-meta makes sense for looking up host services.   The question that some are asking is if using that as an extra indirection for looking up end-user information is the best approach.

Thanks for the background.
John B.

On 2012-07-04, at 6:16 PM, John Panzer wrote:

> Just as a historical note.  The envisioned usage of host-meta was originally to avoid a specification which mandated a particular dynamic URL API at a particular /.well-known endpoint (because it may not be feasible to do that across all organizations and deployments).  The host-meta document itself would be highly cacheable and so wouldn't incur an additional network trip in the common case.
> 
> Having a 3xx redirect is a reasonable alternative that allows a similar escape hatch via something like mod_rewrite, albeit at the cost of needing an additional network trip each time.  Since a deployment can always avoid the 3xx redirect with additional dynamic plumbing behind the well-known endpoint, I don't think that's a horrible thing.
> 
> An application-level redirect would be almost equivalent to an HTTP redirect, but then there are two ways to do the same thing.  If _only_ an application-level redirect is allowed, then you have to have at least a minimal dynamic service at the well-known endpoint (no more mod_rewrite).  But the whole reason for this is to avoid the requirement for a dynamic service behind well-known...
> 
> --
> John Panzer / Google
> [e-mail] / abstractioneer.org / @jpanzer
> 
> 
> 
> On Wed, Jul 4, 2012 at 2:33 PM, James M Snell <[e-mail]> wrote:
> The redirect would not be strictly necessary. There'd be absolutely
> nothing wrong with the host returning a document that allows for an
> application-level redirect. The more important point is that the model
> can be greatly improved by not *requiring* the host-meta and
> XRD-indirection.
> 
> On Wed, Jul 4, 2012 at 2:18 PM, John Bradley <[e-mail]> wrote:
> > In some ways XRD is an artifact of trying to use host-meta.
> >
> > I agree that if starting from a clean sheet is possible then using the SWD approach of
> > having a specific .well-known location for discovery is better than trying to overload host-meta with query parameters.
> >
> > I am personally fine with using a redirect, though I understand there was push back in WF to that because not all hosting environments support redirects.
> > That was one reason why SWD supported a very basic application level redirect.
> >
> > For openID Connect I don't think there is any interest in a non JSON format.   If WF as submitted goes forward then we would profile it down for just JRD support.'
> >
> > I agree that it can be simpler and not require a new URI scheme.
> >
> > One reason for a JSON format in SWD is to allow for multiple links per rel to be returned to an application for fault tolerance.
> >
> > For the unloved XRI spec there was a way to get the response in HTML, and that was probably used as much and the XRDS format.
> >
> > I agree a html response format should be possible if not necessarily the default.
> >
> > The question is if there is enough interest in the WG to rework the basic design.
> >
> > The current WF draft is the path of least resistance.
> >
> > John B.
> >
> > On 2012-07-04, at 4:45 PM, James M Snell wrote:
> >
> >> The second issue here is the part about webfinger that bothers me the
> >> most... there really is no clear reason why XRD should be required
> >> here. The additional indirection serves no significant valuable
> >> purpose that I can determine. The Simple Web Discovery draft is better
> >> overall I think but much more can be done to simplify things and
> >> provide a much more succinct and useful protocol. Simply because XRD
> >> is in use today by a few early adopters, there's absolutely no reason
> >> to rubber stamp it here. I appreciate those early adopters for giving
> >> a great demonstration of how it shouldn't be done.
> >>
> >> In my previous feedback, I've demonstrated that the same benefits can
> >> be achieved without the use of XRD at all... in fact, we can achieve
> >> exactly the same result and eliminate a good third of everything
> >> that's discussed in the current WF draft... Using WF's own use cases
> >> from Section 4...
> >>
> >> Locating a user's blog...
> >>
> >> Assuming, for privacy purposes, we hash the acct id; and assuming we
> >> define "blog" as a Link Relation...
> >>
> >>  GET /.well-known/finger/fc5e68b29fa1d255bd038a167ca0b9bd/blog
> >>  Host: example.org
> >>
> >>  HTTP/1.1 302 Found
> >>  Location: http://blogs.example.com/bob/
> >>  Link: <http://www.example.com/~bob/bob.jpg>; rel="avatar",
> >>    <http://www.example.com/~bob/>; rel="http://webfinger.net/rel/profile-page"
> >>
> >> Locating a user's contact info...
> >>
> >>  GET /.well-known/finger/fc5e68b29fa1d255bd038a167ca0b9bd/vcard
> >>  Host: example.org
> >>
> >>  HTTP/1.1 200 OK
> >>  Context-Type: text/vcard
> >>
> >>  {vcard data}
> >>
> >> Simplifying the Login Process
> >>
> >>  GET /.well-known/finger/fc5e68b29fa1d255bd038a167ca0b9bd/openid
> >>  Host: example.org
> >>
> >>  HTTP/1.1 302 Found
> >>  Location: https://openid.example.com/carol
> >>
> >> Retrieving device info
> >>
> >>  GET /.well-known/finger/fc5e68b29fa1d255bd038a167ca0b9bd/tipsi
> >>  Host: example.org
> >>
> >>  HTTP/1.1 302 Found
> >>  Location: http://192.168.1.5/npap/
> >>
> >>
> >> So in each case we achieve the same fundamental goal without the
> >> additional indirection or use of XRD. A specific implementation could
> >> choose to use XRD if they'd like, but it shouldn't be a requirement.
> >> For instance, suppose...
> >>
> >>  GET /.well-known/finger/fc5e68b29fa1d255bd038a167ca0b9bd/xrd
> >>  Host: example.org
> >>
> >>  HTTP/1.1 200 OK
> >>  Content-Type: application/json
> >>
> >>  {...}
> >>
> >> Doing this would be an entirely optional implementation choice,
> >> however. If I did, for instance...
> >>
> >>  GET /.well-known/finger/fc5e68b29fa1d255bd038a167ca0b9bd
> >>
> >> Specifying no additional path, the server could very well just forward
> >> me on to an HTML representation of my profile that contains
> >> microdata/RDFa properties I could harvest. The server should be
> >> allowed to serve up whatever information it wants, in whatever format
> >> it wants; client applications will determine for themselves whether
> >> that data is usable or not. Keeps the protocol, and the spec, as drop
> >> dead simple as possible.
> >>
> >> - James
> >>
> >> On Tue, Jul 3, 2012 at 6:59 PM, Phillip Hallam-Baker <[e-mail]> wrote:
> >>> I recall something rather different. I recall a claim that the IPR was
> >>> open when in fact the registry was to be operated on a commercial
> >>> basis.
> >>>
> >>> This technology keeps appearing in specs without any apparent
> >>> requirement to motivate it. In OpenID the only reason for =Phill being
> >>> required was that user@domain was not supported as we were told that
> >>> people wanted to use the URL of their blog.
> >>>
> >>>
> >>> On Tue, Jul 3, 2012 at 7:53 PM, John Bradley <[e-mail]> wrote:
> >>>> I recall that there were strait answers and a meeting with the OASIS lawyer on the topic back in the day.
> >>>>
> >>>> Not everyone trusted the answers apparently,  but you can't make everyone happy.
> >>>>
> >>>> The IPR you are concerned about related to XRI resolution and not the XRDS or XRD XML document formats.
> >>>>
> >>>> There should be no more IPR concern than there is with other OASIS specs like SAML.
> >>>>
> >>>> That said I am not advocating the use of XRD,  SWD used a simple link data type JSON format.
> >>>>
> >>>> The XRD and JRD format are heavily influenced by the link data format if you look at it closely.
> >>>>
> >>>> Regards
> >>>> John B.
> >>>>
> >>>>
> >>>>
> >>>> On 2012-07-03, at 6:29 PM, Phillip Hallam-Baker wrote:
> >>>>
> >>>>> What are the PR encumbrances of XRD?
> >>>>>
> >>>>> The XRI folk never gave me a straight answer, it is all tainted until
> >>>>> there is an explicit statement AFIK.
> >>>>>
> >>>>> On Tue, Jul 3, 2012 at 5:27 PM, James M Snell <[e-mail]> wrote:
> >>>>>> Great to see this conversation coming up... A couple of months ago I
> >>>>>> posted a few thoughts on WebFinger on my personal blog [1]... I've
> >>>>>> copied the relevant bits here for discussion. The short summary:
> >>>>>> WebFinger is ok but can be made so much simpler.
> >>>>>>
> >>>>>> [1] http://chmod777self.blogspot.com/2012/03/thoughts-on-webfinger.html
> >>>>>>
> >>>>>> ...
> >>>>>> Ok... so [WebFinger] seems simple enough, but can we make it even
> >>>>>> simpler? I think we definitely can. Let's start by eliminating the
> >>>>>> requirement to use XRD. Look at the first response... what is the XRD
> >>>>>> document giving us? A Link. One Link. Ok, not really a Link, but a URI
> >>>>>> Template. Wait, so that's two things we I actually need to process
> >>>>>> before I can actually look up information about the user "bob"...
> >>>>>> let's eliminate both of those things and simply provide a means of
> >>>>>> looking up information about the user directly.. for instance:
> >>>>>>
> >>>>>> GET /.well-known/finger/acct%3Abob%40example.org HTTP/1.1
> >>>>>> Host: example.org
> >>>>>>
> >>>>>> If we still need to know things about the domain, then we can finger
> >>>>>> that domain...
> >>>>>>
> >>>>>> GET /.well-known/finger/example.org HTTP/1.1
> >>>>>> Host: example.org
> >>>>>>
> >>>>>> But looking up basic information about the user should not be
> >>>>>> predicated on first looking up basic information about the domain.
> >>>>>> Those can, and should, be two completely separate tasks.
> >>>>>>
> >>>>>> There is a problem here, however. A big problem actually. Many
> >>>>>> enterprises frown on putting things that look like email addresses
> >>>>>> into URLs because of fairly significant privacy concerns. So let's
> >>>>>> change that, instead of passing the acct: ID directly, we'll pass a
> >>>>>> hash of the acct id.. much more secure and private that way...
> >>>>>>
> >>>>>> GET /.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba HTTP/1.1
> >>>>>> Host: example.org
> >>>>>>
> >>>>>> Ah, that's better... and in the process I managed to eliminate about a
> >>>>>> third of what the WebFinger draft currently requires.
> >>>>>>
> >>>>>> It boils down to nothing more than this:
> >>>>>> If I want to know something about user "[e-mail]", I sent a GET
> >>>>>> request to http://example.org/.well-known/finger/{md5("[e-mail]")}
> >>>>>> and see what I get back. No absolute need to parse any XML. No need to
> >>>>>> process any URI Templates. No need to define special query string
> >>>>>> parameters. Keep it very simple and we're essentially done.
> >>>>>>
> >>>>>> Ok, so what about the response from the server? What would that look
> >>>>>> like? Currently, WebFinger requires that the response has to either be
> >>>>>> XRD or this other thing called JRD. While I don't have any problem
> >>>>>> with using either of those particular formats, I do not believe that
> >>>>>> the WebFinger spec needs to declare that any format MUST be supported.
> >>>>>> It should be up to the server to provide whatever format it wishes.
> >>>>>> The client can determine if it's able to get what it's needs from the
> >>>>>> provided format or not. If the response is HTML and includes Link or
> >>>>>> Anchor elements that use appropriately labelled rel attribute values,
> >>>>>> then the client should be able to get the information it needs; if the
> >>>>>> response is JSON and includes appropriately labeled information in a
> >>>>>> way the client can understand, then great. That's what we have things
> >>>>>> like the Accept request header for...
> >>>>>>
> >>>>>> GET /.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba HTTP/1.1
> >>>>>> Host: example.org
> >>>>>> Accept: application/xrd+xml, text/html, application/atom+xml
> >>>>>>
> >>>>>> The client can tell the server what format it would like and the
> >>>>>> server can respond appropriately. These mechanism are widely used and
> >>>>>> the abstract notion of a Link is fairly universal now and easily
> >>>>>> represented in multiple formats.
> >>>>>>
> >>>>>> The response to the above request could very well be as simple as:
> >>>>>>
> >>>>>> HTTP/1.1 204 No Content
> >>>>>> Link: <http://blogs.example.org/bob/>; rel="blog",
> >>>>>>   <http://example.org/profiles/bob>; rel="profile",
> >>>>>>   <http://example.org/profiles/avatar>; rel="avatar"
> >>>>>>
> >>>>>> Sure, this hypothetical type of response may be impractical if a
> >>>>>> particular user has a significantly large number of links associated
> >>>>>> with it, but (a) realistically most users won't have that many at any
> >>>>>> single service and (b) this is just an example, I did say that I have
> >>>>>> no problem with XRD/JRD being used... it just shouldn't be required.
> >>>>>>
> >>>>>> Another possibility. Just to stretch the imagination a bit more.
> >>>>>> Suppose I want to know the location of the user's blog and I send this
> >>>>>> for a request:
> >>>>>>
> >>>>>> GET /.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/blog HTTP/1.1
> >>>>>> Host: example.org
> >>>>>>
> >>>>>> Note the addition of the "/blog" at the end of the request URI. Let's
> >>>>>> just say that the last little bit there is a rel value. If the user
> >>>>>> has only a single rel="blog" Link, then the server can tell me where
> >>>>>> it is with a simple redirect:
> >>>>>>
> >>>>>> HTTP/1.1 302 Found
> >>>>>> Location: http://blogs.example.org/bob
> >>>>>>
> >>>>>> If there happen to be multiple "blog" links associated with that
> >>>>>> particular user, then the server can tell me about all of them...
> >>>>>>
> >>>>>> HTTP/1.1 300 Multiple Choices
> >>>>>> Location: http://blogs.example.org/bobs_default_blog
> >>>>>> Link: <http://blogs.example.org/bobs_default_blog>; rel="blog",
> >>>>>>   <http://blogs.example.org/bobs_other_blog>; rel="blog"
> >>>>>>
> >>>>>> What if I want to know about some other kind of Link associated with
> >>>>>> the user... well, I simply replace "/blog" with the other rel
> >>>>>> attribute value...
> >>>>>>
> >>>>>>   GET /.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/vcard HTTP/1.1
> >>>>>> Host: example.org
> >>>>>>
> >>>>>>   GET /.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/avatar HTTP/1.1
> >>>>>> Host: example.org
> >>>>>>
> >>>>>>   GET /.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/
> >>>>>> http%3A%2F%2Fspecs.openid.net%2Fauth%2F2.0%2Fprovider HTTP/1.1
> >>>>>> Host: example.org
> >>>>>>
> >>>>>> Whatever specific link rel I want to know about, I just append that to
> >>>>>> the end. If I need to know about more than one, separate them by a
> >>>>>> comma:
> >>>>>>
> >>>>>>   GET /.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/vcard,avatar
> >>>>>> HTTP/1.1
> >>>>>> Host: example.org
> >>>>>>
> >>>>>> Which could return something along the lines of...
> >>>>>>
> >>>>>> HTTP/1.1 300 Multiple Choices
> >>>>>> Link: <http://example.org/bob.vcard>; rel="vcard",
> >>>>>>   <http://example.org/bob.jpg>; rel="avatar"
> >>>>>>
> >>>>>> Or it could return an XRD or JRD... either way, it works just fine.
> >>>>>> The point is that it's MUCH simpler than what WebFinger defines and
> >>>>>> requires fewer moving parts (no required XML parsing, no required URI
> >>>>>> Template processing, no required querystring parameters, etc).
> >>>>>>
> >>>>>> With regards to security considerations, the original Finger protocol
> >>>>>> was quite problematic because of the potential for inappropriate
> >>>>>> disclosure of sensitive information about an account.  The same basic
> >>>>>> concern would be applicable to WebFinger depending on what information
> >>>>>> was being made available for discovery. I've already dealt with one
> >>>>>> particular concern -- the use of an email-like identifier within the
> >>>>>> discovery URI... requiring a hash is a simple fix there. But what else
> >>>>>> can be done?
> >>>>>>
> >>>>>> Well, obviously, we're talking about a HTTP request here. When a
> >>>>>> requester sends an unauthenticated HTTP request to discover
> >>>>>> information about a user, the server can choose to respond with only
> >>>>>> the most basic generic and public information about the user and
> >>>>>> possibly some links to that user's public facing services (their blog,
> >>>>>> their avatar, etc). Mechanisms such as OAuth 2 can be employed,
> >>>>>> however, to support much more interesting scenarios. For instance, a
> >>>>>> trusted third party could acquire an OAuth 2 access token to request
> >>>>>> additional, more detailed information about a user...
> >>>>>>
> >>>>>> GET /.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/blog HTTP/1.1
> >>>>>> Host: example.org
> >>>>>> Authentication: Bearer {my_access_token}
> >>>>>>
> >>>>>> Such requests can be easily tracked, rate-limited, etc, making the
> >>>>>> protocol generally much more reliable and secure than the original
> >>>>>> finger protocol. Unfortunately, the current WebFinger specification
> >>>>>> does not adequately address this particular concern.
> >>>>>> ....
> >>>>>>
> >>>>>> - James
> >>>>>>
> >>>>>> On Tue, Jul 3, 2012 at 12:24 AM, Mike Jones <[e-mail]> wrote:
> >>>>>>> You've essentially described Simple Web Discovery!  It avoids the complications introduced by host-meta exactly by using its own .well-known value.  The basic example is:
> >>>>>>>
> >>>>>>>  GET /.well-known/simple-web-discovery?principal=mailto:[e-mail]&service=urn:example.org:service:calendar HTTP/1.1
> >>>>>>>  Host: example.com
> >>>>>>>
> >>>>>>>  HTTP/1.1 200 OK
> >>>>>>>  Content-Type: application/json
> >>>>>>>
> >>>>>>>  {
> >>>>>>>   "locations": ["http://calendars.example.net/calendars/joseph"]
> >>>>>>>  }
> >>>>>>>
> >>>>>>> See http://tools.ietf.org/html/draft-jones-simple-web-discovery-02 for more details.  By design, there aren't many...
> >>>>>>>
> >>>>>>>                               -- Mike
> >>>>>>>
> >>>>>>> -----Original Message-----
> >>>>>>> From: [e-mail] [mailto:[e-mail]] On Behalf Of Mark Nottingham
> >>>>>>> Sent: Monday, July 02, 2012 10:47 PM
> >>>>>>> To: IETF Apps Discuss
> >>>>>>> Subject: [apps-discuss] Looking at Webfinger
> >>>>>>>
> >>>>>>> I've pretty much ignored the whole webfinger / acct: / SWD discussion (too much!). However, since it's apparent it may soon become Real, I had a look.
> >>>>>>>
> >>>>>>> In a nutshell, my initial reaction is "It's Not Nearly As Bad As I Thought It Would Be." :)
> >>>>>>>
> >>>>>>> With that in mind, a few questions / comments (I'll resist going into editorial matters, for the time being):
> >>>>>>>
> >>>>>>> * First and foremost, why use host-meta? What value does adding this extra step to the dance bring, beyond "We've defined it, therefore we must use it?"
> >>>>>>>
> >>>>>>> As I think I've said many times before, the whole point of a .well-known URI is to group like uses together, to avoid having a "dictionary" resource that gets bloated with many application's unrelated data, thereby overburdening clients with too much information (especially when they're constrained, e.g., mobile).
> >>>>>>>
> >>>>>>> As such, host-meta is a spectacularly bad example of a well-known URI. Defining a end-all-be-all well-known-URI kind of removes the point of having a registry, after all...
> >>>>>>>
> >>>>>>> Instead, why not just define a NEW well-known URI for user data? That has a more constrained scope, and saves one round trip (or more). E.g.,
> >>>>>>>
> >>>>>>> GET /.well-known/webfinger?user=bob%40example.com HTTP/1.0
> >>>>>>> Host: example.com
> >>>>>>>
> >>>>>>> I.e., let webfinger define the URI template to use. Yes, some implementations might want to come up with crazy URIs, but is that really a problem we want to solve?
> >>>>>>>
> >>>>>>> Astute observers will notice that this approach removes the need for an ACCT URI scheme (at least here).
> >>>>>>>
> >>>>>>>
> >>>>>>> * What's the fascination with XRD and JRD? These specifications seem to be creeping into IETF architecture; first it was in a pure security context, but now folks are talking about using them in a much more generic way, as a cornerstone of what we do. As such, I think they deserve a MUCH closer look, especially since we're defining things with "Web" in their name when the W3C has already defined solutions in this space.
> >>>>>>>
> >>>>>>> Thanks,
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> Mark Nottingham   http://www.mnot.net/
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>> apps-discuss mailing list
> >>>>>>> [e-mail]
> >>>>>>> https://www.ietf.org/mailman/listinfo/apps-discuss
> >>>>>>>
> >>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>> apps-discuss mailing list
> >>>>>>> [e-mail]
> >>>>>>> https://www.ietf.org/mailman/listinfo/apps-discuss
> >>>>>> _______________________________________________
> >>>>>> apps-discuss mailing list
> >>>>>> [e-mail]
> >>>>>> https://www.ietf.org/mailman/listinfo/apps-discuss
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Website: http://hallambaker.com/
> >>>>> _______________________________________________
> >>>>> apps-discuss mailing list
> >>>>> [e-mail]
> >>>>> https://www.ietf.org/mailman/listinfo/apps-discuss
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> Website: http://hallambaker.com/
> >
> _______________________________________________
> apps-discuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>