Re: [apps-discuss] Looking at Webfinger

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 <ve7jtb@ve7jtb.com> 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 <hallam@gmail.com> 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 <ve7jtb@ve7jtb.com> 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 <jasnell@gmail.com> 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 "bob@example.org", I sent a GET
>>>>>> request to http://example.org/.well-known/finger/{md5("bob@example.org")}
>>>>>> 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 <Michael.Jones@microsoft.com> 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:joe@example.com&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: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] 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
>>>>>>> apps-discuss@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/apps-discuss
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> apps-discuss mailing list
>>>>>>> apps-discuss@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/apps-discuss
>>>>>> _______________________________________________
>>>>>> apps-discuss mailing list
>>>>>> apps-discuss@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/apps-discuss
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Website: http://hallambaker.com/
>>>>> _______________________________________________
>>>>> apps-discuss mailing list
>>>>> apps-discuss@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/apps-discuss
>>>>
>>>
>>>
>>>
>>> --
>>> Website: http://hallambaker.com/
>