Re: [apps-discuss] Looking at Webfinger

[James M Snell <[e-mail]>]

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/