Subject: [apps-discuss] Looking at Webfinger

From: Mark Nottingham <[email-masked]>
Date: Tue, 3 Jul 2012 15:47:07 +1000

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/

---

From: Mike Jones <[email-masked]>
Date: Tue, 3 Jul 2012 07:24:11 +0000

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:[email-masked]&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: [email-masked] [mailto:[email-masked]] On Behalf Of Mark Nottingham
Sent: Monday, July 02, 2012 10:47 PM
To: IETF Apps Discuss
Subject: [apps-discuss] Looking at Webfinger

Thanks,

_______________________________________________
apps-discuss mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 3 Jul 2012 17:26:31 +1000

On 03/07/2012, at 5:24 PM, Mike Jones wrote:

> You've essentially described Simple Web Discovery!  It avoids the complications introduced by host-meta exactly by using its own .well-known value.

This makes me happy. :)

So, what's the current state of SWF vs. webfinger? I thought I'd see an announcement go by that webfinger was going to become a WG draft.

Sorry for not keeping up, but I can only digest so much e-mail at once...

Thanks,

---

From: William Mills <[email-masked]>
Date: Tue, 3 Jul 2012 00:31:11 -0700 (PDT)

The answer is that they are close enough that having two drafts for very similar things seemed wrong.  WF is being updated with the incremental changes (small) to get the same functionality.

>________________________________
> From: Mark Nottingham <[email-masked]>
>To: Mike Jones <[email-masked]> 
>Cc: IETF Apps Discuss <[email-masked]> 
>Sent: Tuesday, July 3, 2012 12:26 AM
>Subject: Re: [apps-discuss] Looking at Webfinger
> 
>

---

From: Melvin Carvalho <[email-masked]>
Date: Tue, 3 Jul 2012 09:33:30 +0200

On 3 July 2012 07:47, Mark Nottingham <[email-masked]> wrote:

> 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.
>
> * 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.,
>

Seems very sensible.  To keep with the current naming it may need to be:

GET /.well-known/webfinger?acct=bob%40example.com (  )

acct, rather than, user.

Tho RFC6068 does in places include the term "user".  There is an argument
to say that user: is a more natural URI scheme than acct:.  Leads to some
interesting questions:

Should user: be registered as well as acct: ?
Should user: be registered instead of acct: ?
Does acct: being registered mean user: should NOT be registered. ?

In general +1 for this conceptually.  Note that a very similar idea was
suggested when this thread came up on the TAG list. [1]

https://gmail.com/.well-known/host-meta?acct=[email-masked]

http://lists.w3.org/Archives/Public/www-tag/2012Jun/0110.html

>
> 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?
>
> * 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,
>
>
> --

---

From: Michiel de Jong <[email-masked]>
Date: Tue, 3 Jul 2012 12:44:11 +0300

A brilliant and convincing post, IMO! My remarks, fwiw:

- it should be clear to implementers that they are allowed to use http
3** responses to redirect to some other place where running the actual
webfinger service might be easier to organize. it should be clear to
clients that they should follow such redirects. afaik, the ability to
redirect to some other place was an argument for using host-meta as a
first hop: first discover where the host-meta server is, and then do
the actual work there.

- changing existing implementations costs money and goodwill in the
short term (but so do prolonged discussions, so a change like this
could actually improve adoption if it's done right).

- the reason host-meta and also simple-web-discovery use URIs to
describe resources is that the architecture of the web says that if
you point to something of any importance, then the pointing should be
done with a URI. In this case i think it's fair to say we are not
really pointing to a resource, but rather just passing a string as a
query parameter. So i'm all in favour of ?user=user@host or
?acct=user@host, i'm just saying that i think that was the reasoning
at the time.

- if we give various applications all their own well-known URI, then
there might at some point a need to get an aggregated list of which
things are discoverable. Aggregated discovery has been discussed in a
separate thread already, and i think making it optional is good.

Otherwise, unless i overlooked some other point, I think it's hard to
deny that registering a well-known URI instead of a full URI scheme
would basically solve everything instantly and be preferable.

My 2ct,

--
Michiel de Jong   http://unhosted.org/

---

From: George Fletcher <[email-masked]>
Date: Tue, 03 Jul 2012 10:11:45 -0400

+1 for supporting redirects

 From a pure deployment perspective, managing multiple .well-known/ 
endpoints can be difficult is the group that "owns" the web domain is 
substantially different/separated from the group that wants to put 
"files" in the .well-known directory. In addition, a single organization 
supporting multiple domains that all use the same "identifier" strings 
can also add complications. Not unsolvable, but it creates a more 
brittle deployment.

Managing these endpoints as a set of fixed 3XX redirects is much simpler 
than having to deploy the actual functionality at the endpoint. Even 
easier (for my environment) is to only deploy one endpoint... but I get 
the rationale behind having multiple.

Thanks,
George

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 3 Jul 2012 10:52:54 -0400

I am not clear what the proposal is that is being referred to though.

There is a very clear rationale for having an acct: scheme as far as I
am concerned that is independent of WebFinger. Accounts are a specific
type of resource that we refer to repeatedly in protocols, a URI is
appropriate.

Web Finger looks to me like something that is eminently suitable for
implementation as a .well-known lookup returning some chunk of data in
response.

The place where I would see acct: being used in WebFinger is actually
more the data structures being returned. So for example if I am
looking up my friends profile, I would probably want to see their
battle.net accounts listed there along with their other stuff.

WebFinger would still be a way to resolve acct: URIs, but only one way
and the http: transport might only be one option.

If I click on an acct: link in a browser I would have a range of
possible options:
   * Grab the public WebFinger data
   * Grab the profile data exposed to me by virtue of me being a friend.
   * Attempt to connect on chat
   * Attempt to send an email

I would expect there to be a default action but that choice is
something the user would probably make.

The place I would be using acct: identifiers is in the authentication
and authorization layer.

And no, I don't get the XRD thing either except that it seems that
they painted the bus a color other people liked.

-- 
Website: http://hallambaker.com/

---

From: John Bradley <[email-masked]>
Date: Tue, 3 Jul 2012 11:24:19 -0400

We took SWD form openID Connect to the OAuth WG.

The decision was made to send it to Apps as it was seen as similar to WF.

Ironically a number of the XRD authors Nat Sakimura, myself and others were involved in SWD and not WF.

While some of us argued for SWDs simpler features and independence from any particular URI scheme,  the consensus of the WG has been to basically stick with WF.
Overloading host-meta to take a parameter in WF was one feature that was added to WF to reduce the number of calls.

By building on host-metta there is a perceived requirement that the template pass a URI and hence one of the requirements to register acct:

Now that WF has been accepted by the chairs as a WG draft it gets harder to make breaking changes.

WF was improved by the discussions.   It might have been improved more if more people had engaged in the conversation earlier.
Though sometimes it takes something moving to completion before people start to pay attention.

We have a relatively short deadline for completing openID connect, and still must make a decision on if we keep SWD or move to WF if there is sufficient stability and consensus around it.

Regards
John B.

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 03 Jul 2012 09:58:44 -0600

On 7/2/12 11:47 PM, Mark Nottingham wrote:

> * 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
> 
> implementations might want to come up with crazy URIs, but is that
> really a problem we want to solve?
> 

Mark, that seems like a reasonable approach. I have no strong attachment
to 'acct' URIs, and removing one step in the dance makes some sense. In
particular, I echo your question: is host-meta doing something special
for us here that we can't do with a well-known URI for webfinger?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 03 Jul 2012 10:05:29 -0600

>    * Attempt to connect on chat

Don't we have xmpp: for that?

>    * Attempt to send an email

Don't we have mailto: for that?

You're saying that acct: would be a general identifier and that
applications could attempt many different kinds of interactions with
that account, using specific protocols like SMTP or XMPP. But deciding
whether to attempt such interactions would depend on knowing if the
service provider actually offers email service, IM service, public
profiles, microblogging, etc. Presumably that information could be
discovered via WebFinger (for a particular account), but I wouldn't
assume that one can send email to an account simply because an acct: URI
exists.

> something the user would probably make.

It seems that the default action would be discovery.

> The place I would be using acct: identifiers is in the authentication

Describing those use cases more completely would help us decide whether
we really need the 'acct' URI scheme.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Julian Reschke <[email-masked]>
Date: Tue, 03 Jul 2012 18:17:57 +0200

On 2012-07-03 07:47, Mark Nottingham wrote:
> ...

Or even

   /.well-known/webfinger/[email-masked]

?

Best regards, Julian

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 3 Jul 2012 12:51:38 -0400

Yes we do have mailto and xmpp but they conflate a resource with the
action on that resource.

We keep on having to develop all these new identifiers because the old
ones have that conflation. Unfortunately I couldn't get people to
change <a href="mailto:[email-masked]"> into <a
href="acct:[email-masked]" action="mailto"> at the time it
appeared.

Having acct: in there allows the client to offer the default action
that makes sense in the context of that client. For example, a chat
client is probably going to default to trying to set up chat.

---

From: John Bradley <[email-masked]>
Date: Tue, 3 Jul 2012 12:56:58 -0400

In SWD we had a second parameter for the link relation you are looking for.    
That make processing on the client simpler if it can ask for the IMAP link relation and get back a simple document with just the relevant links.

That is similar to the WF resource and rel parameters,  though rel is somewhat limited in WF due to it only having a single template parameter.

I don't personally care if the resource being retrieved is part of the path or a query parameter.

This also cases the question of what is the thing de-refrenced.  Is it a abstract concept of the account or a concrete resource that is a file.

I think we are creating a new URI name using acct: for what is essentially a document, that also has a http: scheme uri for de-refrencing it.

So I am still unclear on if acct: really has some unique meaning as a identifier that can be defined.

John B.

---

From: William Mills <[email-masked]>
Date: Tue, 3 Jul 2012 10:29:09 -0700 (PDT)

For describing why we need acct: I come back to the previous discussion where the point was made almost exactly that xmpp:, mailto: and others have specific contexts and in the context of Webfinger are appropriate for discovering information about that specific context.  The acct: scheme satisfies the need for "I need information about this user" when it's not in the context of a specific applicaiton protocol.

> From: Peter Saint-Andre <[email-masked]>
>To: Phillip Hallam-Baker <[email-masked]> 
>Cc: Mark Nottingham <[email-masked]>; IETF Apps Discuss <[email-masked]> 
>Sent: Tuesday, July 3, 2012 9:05 AM
>Subject: [apps-discuss] the need for acct (was: Re:  Looking at Webfinger)
>

---

From: Barry Leiba <[email-masked]>
Date: Tue, 3 Jul 2012 14:41:00 -0400

> Now that WF has been accepted by the chairs as a WG draft it gets harder to

I'm not sure what you mean by "breaking changes", but I don't see that
having the document be a working group product undermines the ability
to suggest any change for which there has not already been a decision
against.  If your suggestion develops rough consensus, then it will be
included.  If not, then it won't.

To avoid the flogging of dead horses, the chairs may declare some
topics out of scope if those topics have already been firmly decided.
But that, too, is standard procedure.

Barry

---

From: John Bradley <[email-masked]>
Date: Tue, 3 Jul 2012 16:17:32 -0400

There are existing deployments of WF.   Changes that lead to something incompatible with what is deployed 
are likely to receive more resistance, now that we have a WG draft.

Not that changes can't be made with rough consensus..  

It may have been easier though to have had Mark and others comments before the WG draft.
That might have made it easier to have included some more of the SWD design.

That is however water under the bridge, and we have an initial document that is backwards compatible with WF as deployed.

John B.

---

From: James M Snell <[email-masked]>
Date: Tue, 3 Jul 2012 14:27:22 -0700

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 "[email-masked]", I sent a GET
request to http://example.org/.well-known/finger/{md5("[email-masked]")}
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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 3 Jul 2012 18:29:07 -0400

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.

---

From: John Bradley <[email-masked]>
Date: Tue, 3 Jul 2012 19:53:36 -0400

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.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 3 Jul 2012 21:59:34 -0400

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.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 3 Jul 2012 20:46:11 -0700

The fact that there's a WG draft now doesn't change what's been deployed.
These are two orthogonal points.

I (predictably) concur with Barry's statements about document evolution.
The working group could conceivably completely rewrite Webfinger at this
point if it so chooses, as driven by consensus.  That includes applying
all, some, or none of Mark's comments, for example.

If you have some changes you'd like to have the working group consider, the
floor is open.

-MSK

---

From: Melvin Carvalho <[email-masked]>
Date: Wed, 4 Jul 2012 21:05:12 +0200

On 4 July 2012 05:46, Murray S. Kucherawy <[email-masked]> wrote:

> If you have some changes you'd like to have the working group consider,
> the floor is open.
>

One question I've been thinking about.  Does the acct: scheme also apply to
subdomains too, or just the parent domain, or only where an email exists?

For example, are the following four, equivalent ways to describe an account?

acct:[email-masked]
acct:[email-masked]
acct:[email-masked]
https://graph.facebook.com/bob

---

From: John Bradley <[email-masked]>
Date: Wed, 4 Jul 2012 15:56:29 -0400

They are all separate identifiers and could resolve to different XRD/JRD.  It would be up to the provider to make the four identifiers return the same information.

Though example 3 and 4 would at least share the same host-metta for resolution.

One unresolved problem is what happens in a hosted environment like Google apps.

If I have a domain like ve7jtb.com where I have pointed mail.ve7jtb.com, calendar.ve7jtb.com , and the MX records to google.
I may have no web server for ve7jtb.com or have it pointed at some simple hosting service, that has no notion of WF.

How would Google provide WF and the services that rely on it to those hosted domains?

This is a real problem.   For openID 2.0 they asked the RP to check with a special google service to see if it was hosted.
This potentially allows for the hijacking of the discovery information and might not be ideal for all protocols using WF.

The ideas that have circulated are:
1 Using SRV records.   Not all DNS services support SRV and users will not configure not correctly  (on the order of the experience with goggle apps XMPP config)
2 Using MX records.  Check the MX host if you can't find the host-metta.   This is more likely to be configurable but ties acct:  and WF to SMTPl in a way that is not ideal.  Clients are also going to need to access DNS directly.
3 Use a special subdomain.  Check the host web finger-discovery-home.ve7jtb.com if you can't find host-meta on the target host.  The downside id that it bends the principal of not steeling namespace.  the upside is that configuring an A record is something users can do, and it is easy for WF clients.

Solving this real world problem for WF is a high priority to be able to deploy it.

John B.
On 2012-07-04, at 3:05 PM, Melvin Carvalho wrote:

> The fact that there's a WG draft now doesn't change what's been deployed.  These are two orthogonal points.
> 
> I (predictably) concur with Barry's statements about document evolution.  The working group could conceivably completely rewrite Webfinger at this point if it so chooses, as driven by consensus.  That includes applying all, some, or none of Mark's comments, for example.
> 
> If you have some changes you'd like to have the working group consider, the floor is open.
> 
> One question I've been thinking about.  Does the acct: scheme also apply to subdomains too, or just the parent domain, or only where an email exists?
>

---

From: James M Snell <[email-masked]>
Date: Wed, 4 Jul 2012 13:45:46 -0700

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

  {...}

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

---

From: William Mills <[email-masked]>
Date: Wed, 4 Jul 2012 14:04:41 -0700 (PDT)

I like the idea of registering a well-known for WF.   I'm not so  much in favor of changing the current query format.  There are tonss of ways to get the data in there, the one in the draft now has extant implementations.  The current syntax is easily extensible and sufficient, and not in my opinion overly complex.  I tend not to be a fan of stuffing things into the URL when there are multiple data items to deal with, query or post parameters make more sense to me.

-bill

> From: James M Snell <[email-masked]>
>Sent: Wednesday, July 4, 2012 1:45 PM

---

From: John Bradley <[email-masked]>
Date: Wed, 4 Jul 2012 17:18:00 -0400

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.

---

From: James M Snell <[email-masked]>
Date: Wed, 4 Jul 2012 14:33:58 -0700

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.

---

From: John Panzer <[email-masked]>
Date: Wed, 4 Jul 2012 15:16:30 -0700

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
[email-masked] / abstractioneer.org <http://www.abstractioneer.org/> /
@jpanzer

On Wed, Jul 4, 2012 at 2:33 PM, James M Snell <[email-masked]> wrote:

> > 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.
> > 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.'
> >
> > 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.
> >
> >>>>>> [1]
> http://chmod777self.blogspot.com/2012/03/thoughts-on-webfinger.html
> >>>>>>
> >>>>>> ...
> >>>>>>   GET
> /.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/vcard,avatar
> >>>>>> HTTP/1.1
> >>>>>> Host: example.org
> >>>>>>
> >>>>>>> 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:
> [email-masked]&service=urn:example.org:service:calendar HTTP/1.1
> >>>>>>>  Host: example.com
> >>>>>>>
> >>>>>>>  HTTP/1.1 200 OK
> >>>>>>> See http://tools.ietf.org/html/draft-jones-simple-web-discovery-02for more details.  By design, there aren't many...
> >>>>>>>
> >>>>>>>                               -- Mike
> >>>>>>>
> >>>>>>> From: [email-masked] [mailto:
> [email-masked]] On Behalf Of Mark Nottingham
> >>>>>>> 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.
> >>>>>>>
> >>>>>>> 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?"
> >>>>>>>
> "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).
> >>>>>>>
> URI. Defining a end-all-be-all well-known-URI kind of removes the point of
> >>>>>>> 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.,
> >>>>>>>
> >>>>>>> * 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,
> >>>>>>>
> >>>>>>>
> >>>>>>> --

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 5 Jul 2012 08:36:59 +1000

On 05/07/2012, at 8:16 AM, 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...

"dynamic" and "static" are properties of the implementation, not the interface. HTTP doesn't require that any particular URL be "dynamic"; anything can, with the right metadata, be cached (and indeed, I've cached many, many things with the wrong metadata, because of silly site operators and their ideas about "dynamic").

Now, if people want to target a particular implementation that makes it easier to serve a particular style of URL without writing code, fine, but let's not confuse things.

E.g., a URL like

http://example.com/.well-known/user/bob

is easy to serve in pretty much any way you like with Apache.

I'm also going to push back on the "it may not be feasible to do that across all organizations and deployments" motivation. This is a race to the bottom. The trick is to make it accessible enough to get sufficient traction to pull everyone along, without pandering to *everyone*'s requirements.

Regards,

---

From: John Bradley <[email-masked]>
Date: Wed, 4 Jul 2012 18:42:04 -0400

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:

> [email-masked] / abstractioneer.org / @jpanzer
> 
> 
>

---

From: John Panzer <[email-masked]>
Date: Wed, 4 Jul 2012 15:58:28 -0700

Mark -- Of course I was speaking about practical realities of typical web
server administration and deployment.  In practical terms, adding a new
mod_rewrite rule or moral equivalent is going to be easier than adding a
new PHP script that connects to a database.  The latter is just always
going to be a much higher bar.

And, something that returns per-user data is generally going to need a
dynamic service of some kind, unless your site has just a handful of users
and you don't mind going through a publishing exercise each time you add or
change a user...

None of this has anything to do with the interface, just deployment
realities.  And in reality all of this is going to need a dynamic service
somewhere for each non-trivial site, this is all just a question of how to
hook it up.

On Wed, Jul 4, 2012 at 3:36 PM, Mark Nottingham <[email-masked]> wrote:

> "dynamic" and "static" are properties of the implementation, not the
> interface. HTTP doesn't require that any particular URL be "dynamic";
> anything can, with the right metadata, be cached (and indeed, I've cached
> many, many things with the wrong metadata, because of silly site operators
> and their ideas about "dynamic").
>
> Now, if people want to target a particular implementation that makes it
> easier to serve a particular style of URL without writing code, fine, but
> let's not confuse things.
>
> E.g., a URL like
>
> I'm also going to push back on the "it may not be feasible to do that
> across all organizations and deployments" motivation. This is a race to the
> bottom. The trick is to make it accessible enough to get sufficient
> traction to pull everyone along, without pandering to *everyone*'s
> requirements.
>
> Regards,
>
> --

---

From: "Martin J. Dürst" <[email-masked]>
Date: Thu, 05 Jul 2012 09:48:52 +0900

> https://graph.facebook.com/bob

In general, no. If you know a lot about facebook, and you trust them 
that they won't change things, you might be able to infer that the 
account or person behind these URIs is one and the same, but that would 
be at your own risk, and may depend on what exactly you are trying to do.

Regards,   Martin.

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 4 Jul 2012 23:23:32 -0400

Mark,

WebFinger has been around now for a few years.  This most recent effort is
one of formally documenting it.  The plan for a long time has been that
discovering information about users or entities on the Internet would be via
host-meta and, more specifically, Link-based Resource Descriptor Documents
(LRDD).  XRD was created for this purpose, which is why we see it used in
this document.  JRD was subsequently introduced as RFC 6415 was developed.
While LRDD is still present on the server side, the most recent version of
the WebFinger spec effectively hides that via the "resource" parameter.  So,
it's not really that we're building upon host-meta, but really that we're
formally documenting the procedures that were laid down long ago.  WebFinger
and host-meta was moving along together.

What I find most attractive about the approach taken is the consistency and
the fit with the web linking work that you did, essentially serving up a set
of link relations related to the entity that is queried.  WebFinger will
serve up an XRD or JRD document, as desired by the client, that contains a
list of link relations that allow one to convey through those relations all
sorts of information about the entity being queried.  That might be a vCard,
portable contacts, OpenID identifier, mail server configuration, or other.

Another thing I find attractive is the consistency in the approach to
discovery. Regardless of the URI, I can query for information in precisely
the same way.  It might be an acct URI, a mailto URI, an HTTP URI, etc.  If
I want to discover information about acct:[email-masked] or
http://www.packetizer.com/people/paulej, I can use the same discovery
mechanism.  In this case, the server might even be configured to return the
same set of information of both identifiers refer to the same entity.  In
any case, it is important to allow for discovery of entities on the Internet
that are not necessarily users, but any URI.

Paul

> Sent: Tuesday, July 03, 2012 1:47 AM
> To: IETF Apps Discuss
> URI is to group like uses together, to avoid having a "dictionary"
> resource that gets bloated with many application's unrelated data, thereby
> implementations might want to come up with crazy URIs, but is that really
> a problem we want to solve?
> 
> 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

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 4 Jul 2012 23:28:21 -0400

Peter,

> Don't we have xmpp: for that?

Yeah, but this would be the means through which one might discover a
person's XMPP URI.

> Don't we have mailto: for that?

Ditto.

> applications could attempt many different kinds of interactions with that
> account, using specific protocols like SMTP or XMPP. But deciding whether
> to attempt such interactions would depend on knowing if the service
> provider actually offers email service, IM service, public profiles,
> microblogging, etc. Presumably that information could be discovered via
> WebFinger (for a particular account), but I wouldn't assume that one can
> send email to an account simply because an acct: URI exists.

I personally would not assume this is the means through which clients launch
applications, but the means through which one discovers the modalities of
communication possible and the URIs associated with those modalities.

Paul

---

From: Melvin Carvalho <[email-masked]>
Date: Thu, 5 Jul 2012 08:36:15 +0200

> traction to pull everyone along, without pandering to *everyone*'s

Really nice idea.  I've already implemented this on my homepage, took only
a few minutes.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 5 Jul 2012 08:38:34 -0400

IETF Working Group process is not just a documentation effort. If all
that is required is to document what exists then an independent
submission is more appropriate.

In this case we have a protocol that engages in what many of us feel
is a weird, inefficient and convoluted approach with no apparent
motivation. It would be bad even if XRI was not tainted from an IPR
standpoint (and will remain tainted unless the rights holders release
the right to run a registry).

Finger was the simplest protocol, so why is WebFinger complex. Why is
it anything more than a single HTTP lookup to request the relevant
data? That is what Web servers are designed to support after all.

I can see that it might be appropriate to make use of the HTTP
authentication capability to return different profiles depending on
who is asking. But that is also well established.

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 5 Jul 2012 11:10:58 -0400

Philip,

> IETF Working Group process is not just a documentation effort. If all that
> is required is to document what exists then an independent submission is
> more appropriate.

The work on WebFinger is not entirely one of documenting, either.  Perhaps I
stated that too strongly.  The concepts have been brewing over the past few
years, but that's not unusual for many protocols that are brought into the
IETF.  In this case and others, the group has influenced the specifics of
the protocol.
 
> In this case we have a protocol that engages in what many of us feel is a
> weird, inefficient and convoluted approach with no apparent motivation.

I personally find this statement a bit surprising.  I cannot claim to have
come up with the idea or the elements that are included in WebFinger,
Hostmeta, or XRD, so I do feel I speak without bias when I say that it was
pretty easy for me to implement and I do understand exactly what I get.  I
can issue a query and I get back a set of link relations about an entity.  I
can then select the particular link relation of interest and further query
to get the specific information I seek.

> It would be bad even if XRI was not tainted from an IPR standpoint (and
will
> remain tainted unless the rights holders release the right to run a
> registry).

I'm not sure why XRI is often mentioned, since XRD and JRD are both
unrelated to XRI, as far as I know, and are both trivial to produce and
consume.  They're just containers for a set of link relations.
 
> Finger was the simplest protocol, so why is WebFinger complex. Why is it
> anything more than a single HTTP lookup to request the relevant data? That
> is what Web servers are designed to support after all.

Finger returns unstructured data, which was fine back in the day.  WebFinger
returns structured data, which makes it suitable for machine processing.
Why is this considered complex?

https://packetizer.com/.well-known/host-meta? \
                      resource=acct:[email-masked]

It's a simple HTTP GET that returns a set of link relations (and possible
properties).

> authentication capability to return different profiles depending on who is
> asking. But that is also well established.

The spec does not speak to authenticating users at all.  Are you saying this
is a concern or as it should be?

Paul

---

From: Goix Laurent Walter <[email-masked]>
Date: Sat, 7 Jul 2012 12:43:29 +0200

I do think there are many potential usages of the acct: URI, besides WF.
In particular there are many placeholders of IRIs already appropriate for acct: URIs. Atom feeds (and the related ActivityStreams), the ActivityStreams JSON format, and even the OpenSocial API URI syntax make use of IRIs for identifying users (or in general entities, should this be a group, a place, etc).

Originally many blogging platforms exporting rss/atom feeds have been using the mailto: uri for identifying authors as this has been the most popular at that time. However, most of such platforms did not offer email service and sometimes email accounts provided in such feeds where actually referring to a different domain, which is of course still acceptable.
The rise of social networking services have made even more popular such user-related feeds where account identifiers are disjoints from the mailto namespace/service (or xmpp etc) and where acct: URIs are the most appropriate identifier.

walter

Da: [email-masked] [mailto:[email-masked]] Per conto di William Mills
Inviato: martedì 3 luglio 2012 19.29
A: Peter Saint-Andre; Phillip Hallam-Baker
Cc: Mark Nottingham; IETF Apps Discuss
Oggetto: Re: [apps-discuss] the need for acct (was: Re: Looking at Webfinger)

Peter

--
Peter Saint-Andre
https://stpeter.im/

_______________________________________________
apps-discuss mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/apps-discuss

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.

Rispetta l'ambiente. Non stampare questa mail se non è necessario.