[apps-discuss] Webfinger discussion

["Paul E. Jones" <[e-mail]>]

Folks,

I saw the notes regarding the Webfinger discussion today.  Unfortunately, I
could not be there, so please indulge me while I ask questions related to
the notes:

> Thomas Roessler: CORS is in last call

This is good to know.  So, was the group in favor of leaving it in as
mandatory?

?: Good idea.  Work going on in other orgs that reference this.

> Hannes Tschofenig: People like the whole idea, but is bizarre to mandate
CORS

Yeah, we have a choice to make.  If we mandate it, then (in theory) it
should be possible to query a Webfinger server via a JavaScript application
in the browser.  Without it, we would not be able to get beyond the
single-origin rules.

> Paul Hoffman: needs to have consensus calls, so should be in APPSAWG

Not sure what this meant.  Are you suggesting we make the document a WG
item?  For sure, I'd like to progress the document.

> Leif Johannsen: people don't have their own email servers anymore

This is true, which is one reason people have favored using "acct".  Now,
people have identifiers on social networks, but the user@domain notation is
convenient and understood.

> Andrew Sullivan: when I was a kid, they told us to turn off finger, so I'm
> concerned about security

That was due to the fact the finger protocol implementations had security
holes.  It was also possible to do things like "ln /etc/password .plan" and
that was a bad thing :-)

> Dave Crocker: email is the same as it's always been.  Email is good as
> identifier, even if there's no mailbox.  Nice service to have, but needs
> lots of input to get correct.  Might need more work than APPSAWG.  Might
> need its own WG.

I would hope it does not go so far as to needing its own WG.  Much of the
"Webfinger" functionality is really formally describing it as such and using
existing RFCs.  The "new" bits are the "acct" URI scheme, link relation,
requirement to use CORS, and requirement to implement JRD.  The "acct" URI
scheme is already used "in the wild" and is needed because some social
networks provide user accounts, but not email addresses.  To somebody else's
point, some do not run their own email servers anymore and certainly many
social networks are not going to provide email services, as there is little
to no value in doing so.  Yet, a "Webfinger" service has value.

> Mike Jones: (speaking as openid/oauth contributer) we don't use this;
> it doesn't have the right properties

Webfinger is not intended to be used by OpenID directly.  Actually, how I
stumbled into this area, though, was through OpenID.  As I implemented my
OpenID server, I wanted to find a way to get rid of forcing people to have
OpenID identifiers that had to enter on sites like
https://openid.packetizer.com/paulej.  People pointed me to the work on
Webfinger.  Webfinger does not replace the OpenID identifier, but merely
provides makes it easily discoverable.  So, when I visit a web site, I can
enter [e-mail].  This would result in a Webfinger query for
acct:[e-mail].  What would be returned is several pieces of
information one of which is https://openid.packetizer.com/paulej using the
link relation http://specs.openid.net/auth/2.0/provider.  (I'm not too
favorable to that particular link relation, since it's not a pointer to the
provider, but a pointer to my identifier.  But, that seems to be the
predominant value used.)  The service I'm trying to log into now has my
identifier in hand and would go through the same login procedures.  Security
should not be compromised, because the Webfinger account information should
have been provided securely and the login process within the OpenID provider
should either be automatic (because the provider already recognizes your
browser) or would prompt for credentials.  Nothing about OpenID has been
weakened in the process, as nothing about OpenID changed.  Further, there is
never a requirement to use Webfinger -- it's an option for OpenID.

> John Bradley: (speaking as author of XRD) JRD is doc'd in blog post,
> concerned about security/privacy, needs more work before could be used
> in OpenID/Connect.

JRD is documented now in standards-track RFC 6415.  It defines a direct
mapping from XRD to JRD.  I will not disagree that thought may need to be
considered in for use in OpenID or OpenID Connect, but that is not an issue
for Webfinger itself.  Webfinger merely provides pointers to information or
other identifiers.  I understand how this would work in OpenID and I don't
see risk there.  I'm not familiar with how OpenID Connect is supposed to
work.  I had seen some proposals, but nothing recent.  Those proposals I had
seen suggested that I enter my credentials for my identify provider on the
site that I was visiting.  Hopefully, that's now how it works now, because
there's no way I would do that :-)

So, what was the opinion of the group?  It's important to note that RFC 6415
essentially defines all of the mechanisms already, so it's out there and
people can use it.  The Webfinger draft is there to formalize the name and
to introduce the needed "acct" URI and link relation values.

Paul