Re: [webfinger] [appsawg] #12: Semantic gap for the client side

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

Pete,

> > It is true that a WF server could return any information for a given URI
> > scheme, but that's because we have not specified anything that is to be
> > expected for any given URI, except "acct:".
> >
> 
> Where in the document (or in the -acct-uri document) does it specify
> what is to be expected for the acct: URI? I can find nothing in the
> -webfinger document that is outside of an example, and certainly nothing
> with a MUST or a SHOULD or even a MAY, describing what is to be expected
> for a query on an acct: URI. Your statement appears to be incorrect.

The WF spec only says if you want information about an account, the acct URI
should be used.  Now, what gets returned when querying an acct URI is not
specified.  The plan is that one might be able to get OpenID Connect info,
an avatar, a vcard, etc.  The OpenID Connect draft already spells that out.
The others are to be specified in other drafts.

Over time, there may be any number of new link relation types defined and
intended for use with WebFinger.  There are already requirements in place
for that registry to have an RFC spelling things out.
 
> > We do not want to have the ambiguity you describe.  Devices and
> applications
> > should not play guessing games.  If one wishes to retrieve information
> about
> > a user's account, then "acct:" is to be used and that is recommended in
> the
> > WF spec.
> 
> Where????

Uhm...

> If the document said anything like this, I would not be pushing back. Do
> you think that section 4.5 is saying that? That's not nearly what I
> would call a specification.

Yeah... section 4.5.  WF does not dictate the use of any URI.  The group
just wanted to encourage use of "acct" when querying a user's account at
whatever service.  Much of this relates to social network accounts, but
certainly not limited to those.

What URI is queried to get whatever information via WebFinger would be
specified elsewhere.
 
> > Until there is a specification that says exactly what information to
> expect
> > if one were to use mailto: or jabber:, then one should not use those
> URIs.
> > That said, we do want WebFinger to accommodate those or any URI type.
> This
> > is to align with RFC 6415, but also because there might be something
> useful
> > defined for other URIs in the future, just as we're seeing 'acct' take
> > shape.
> >
> 
> The document should say that the semantics of URI queries will be
> defined in other documents. The document should probably also set up an
> IANA registry of URI queries that can be used along with their specific
> meanings and pointers to the documents defining these things.

I'll insert whatever words you want.  Exactly what would you like me to put
where?

I'm not quite sure how we'd construct this registry.  There is already the
link relation registry.  Now, which of those are for use in HTTP?  Which
ones for use in ATOM?  Are there separate registries for those two
protocols?

> Again, right now the client is flying completely blind.

Presently, that's largely true.  However, there are community-defined link
relation types out there that people just started using.  Those would be
returned if one queries a user's account URI.  OpenID Connect has a formal
spec that explains how an OpenID Connect client would perform a query.
There is intent by a few folks to define a few other link relation types for
use with WebFinger once the base spec is done.  Those would also spell out
that queries would be via the acct URI.

The aggsrv group, if it elected to use WebFinger, would specify use of acct
or perhaps smtp, jabber, etc.  That's really their call and would be
documented in their specs.

> >>> Each URI queried might return the same or different information.  The
> >>> specifications that rely on WebFinger would state explicitly what URI
> to
> >>> use.  As an example, the OpenID Connect specs state that
> >>> acct:[e-mail] would be used to issue a WebFinger query.
> >>>
> >> That's the part that scares me. Let's say I'm not using OpenID Connect.
> >> Let's saying I'm using the "PeteID Info" protocol. Do I get to redefine
> >> what an acct: URI returns? If so, that's completely non-interoperable.
> >>
> > No, but you might define a new link type.
> >
> 
> Let's skip link types. Let's talk about properties. What properties can
> I expect to get back for the acct: URI webfinger query? Where is this
> documented? For instance, how do I ask for the full name of the person
> associated with the account? Other than the example in 4.4.3, I find
> nothing in this document or the -acct-uri document that tells me what I
> can expect, or how I can even ask the question.

The WF spec allows for URI-level properties and link-level properties.
Property types are fully-qualified URIs and the property name (URI) and
value would be defined in whatever specification wanted to define them.

As Peter responded, the user's name is likely to be found via a link that
points to a vcard or xcard.  I would personally like to define properties at
the account level that are the user's names, but it would be redundant with
the vcard.  Still, it might be useful so that a client would not have to
grab a vcard and parse it.  This would be a subject for discussion at some
later point.

For now, properties are not defined anywhere.  The mail server configuration
example shows the intent of properties.  If there was a spec that defined
how to provision an email client, it would detail the link relation type,
specify the URI scheme to use to query for the JRD, and define any
properties associated with that link type.
 
> > However, a client will know exactly what it is looking for and would
> ignore
> > link type is does not understand.  Any client that implements PeteID
> would
> > be looking for a specific link type defined in your protocol spec.
> > [...]
> > For example, say you want my vcard.  Presently, nothing
> > tells you how to find it.  My server will return a "rel" of
> > "http://packetizer.com/rel/businesscard" and a type of "text/vcard".  To
> be
> > useful, this would need to be standardized.  There is an intent to
> > standardize this one and others (blog, avatar, profile-page, etc.).
> >
> 
> That's my point. You haven't specified the use of the acct: URI at all
> in this document. You're leaving it for a future standard. You haven't
> even set up a registry of URIs that can be used for webfinger that would
> contain pointers to the standard that would define the semantics. There
> is not enough in this document to do anything interoperable with.

The acct URI scheme is recommended.  It used to be a part of this draft,
even, but it was pulled out separately since there was belief it has broader
value.

Any URI may be used with WebFinger, so what would the registry tell us?

Let's say I am writing a blogging application and I want names and faces of
users visiting the blog to appear on the site.  As part of the registration,
I might ask you to enter the account identifier from which to get your name
and face.  This might be your email address, your facebook ID, Twitter ID,
or whatever.  The client I write on the blog site create a URI in the form
acct:user@domain, because the two pieces of information are link relation
types defined for use with the acct URI.  I know this, because there will be
an RFC written that says so.  The link relation types in that to-be-written
document are registered with IANA, just as link relation types for HTTP and
ATOM are registered there.
 
> > The 'acct' URI scheme is of this form:
> >
> > acctURI      =  "acct" ":" userpart "@" host
> >
> > (See draft-ietf-appsawg-acct-uri-04.)
> >
> > The intent was that the host portion would always be present.  Twitter
> does
> > not use email addresses, so you never see "@twitter.com".  But, if
> querying
> > for account information at twitter.com for user paul_e_jones, the URI
> would
> > be constructed as I showed it.
> >
> 
> How am I (as a client) supposed to know that? I got a Twitter
> identifier. It doesn't have a domain portion. How am I supposed to
> figure out that I'm supposed to put "@twitter.com" after it? Why not
> "@twitter.net" or "@twitter.id"? Why not leave it out and use a URI that
> doesn't require a domain name? Where is this defined? (I *hope* not
> every service that wants to provide account information has to
> separately publish it's own rules for forming the query!)

>From the "acct" URI spec:
   Thus a particular 'acct' URI is formed by setting the "user" portion
   to the user's account name at the service provider and by setting the
"host"
   portion to the DNS domain name of the service provider.

That's the guidance.  I assume Twitter's account IDs do not start with an
'@'.  It's not present in the URI when visiting a person's Twitter page.
Thus, I assume the '@' is just a means of indicating to the Twitter platform
that the following is an account ID vs. regular text when tweeting.

Given the above and then yet-to-be-written RFCs (that defines the link
relation types) to perform WF queries, it should be possible to visit the
blog I described above, tell it your Twitter account (and I'd even write it
to be smart enough to auto-convert @paul_e_jones to
acct:[e-mail]), and it would query Twitter to see if it can
get your name and picture.
 
> Skipping down...
> 
> > It was definitely not the intent that clients would be guessing as to
> how to
> > perform a query.  If a client is looking for my avatar, for example, the
> > client needs to know exactly what URI to use and what link type to look
> for.
> > That should be spelled out in the document that describes the link type.
> >
> > Any words you want to suggest for the WF spec to make that abundantly
> clear,
> > I'm happy to introduce.
> >
> 
> I can work on that if desired. Tim Bray's idea would also make it
> abundantly clear. But what would also address the issue is some text
> which explicitly says, "This is a framework. How to query for particular
> purposes is in other documents. This document defines a registry where
> you can find the different use cases." And if you want, register
> "acct:". And give it some expected semantics.

Is HTTP (RFC 2616) a framework document?  It defines the syntax of the
request and response, but does not define the payload.  WebFinger is
more-or-less the same thing: it defines that the protocol on the wire looks
like going to the server and from the server.  But, it does not define what
a client will query for, nor does it define the payload to be returned.

The link relation registry already exists, so I'm not sure we need another
registry.  We may need a registry for properties, though, if any properties
are to be defined with an IETF-specified URI.  Presently, we've not
discussed defining any properties (aside from my mention above).

In any case, I'll add whatever text you think is appropriate.

> I think Tim is correct: This document is trying to boil the ocean. The
> problem is it's only providing instructions on what to do after the
> entire ocean is in the pot and the fire is going. It's short a few
> pieces of info.

Allowing use of any URI is not boiling the ocean, IMO.  The only issue, I
think, is that there are missing pieces.  The WF spec does not describe what
set of links is returned if one issues a query for any particular URI.  That
was deliberately left for other specifications.

I would venture to guess that the 'acct' URI will be what is used most with
WF, because of the interest from social networking circles.  However, we
didn't want to limit it to that one URI scheme.  Some have stated, for
example, that they'd like to use the 'tel' URI with WF.  I can appreciate
how one might use that as a means of determining which of several ENUM
registries to query, for example.  Some are already using http URIs with
WebFinger, too (e.g.
http://openid.net/specs/openid-connect-discovery-1_0.html#URLSyntax).  And
if we want to know the author of a web page, querying a server and passing
the URI of the web page could result in returning a link with the "author"
link relation type, perhaps also a "copyright", etc.  (Those are examples in
RFC 6415.)

I think boiling the ocean would have been defining all these use cases in
the WF spec.  We did not want to do that.  Instead, we define the base
protocol and then other specs define how to use WF to get certain
information.

Paul