Re: [apps-discuss] Looking at Webfinger

[Phillip Hallam-Baker <[e-mail]>]

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/