Re: [apps-discuss] AppsDir Review of draft-ietf-appsawg-webfinger-11

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

Dave,

> > > 1) I note that §4.4.4.1 describes a 'rel' such that it redefines and
> > > repeats RFC 5988's §4; I think this should be deferred explicitly to
RFC
> > > 5988 in entirety, rather than specifically only for registered link
> > > relation types.
> > >
> > > The good news is that this should simplify the text rather a lot:
> > >
> > > """
> > > The value of the "rel" member is a string containing a link relation
> > > type (see RFC 5988 [4]). Both registered and extended relation types
are
> > > permitted.
> > >  """
> >
> > I do not think we can simplify the text so much.  There is an explicit
> > limitation in the WebFinger draft that a "rel" value must either be a
single
> > absolute URI or a registered link relation type.  RFC 5988 allows for
> > multiple values like 'rel="shortcut icon"', but WebFinger does not.  RFC
> > 5988 also allows URIs with fragments, but WebFinger does not.  Valid
URIs
> > must conform to Section 4.3 of RFC 3986 (Absolute URIs).  These
decisions
> > were intended to avoid ambiguity.
> 
> Link relation types are a single one of those values, the
> <relation-type> ABNF production, as opposed to the rel, which contains a
> <relation-types>. I'm entirely with you on why you want to restrict your
> rel to a single link relation type. Worth calling it out the difference,
> but it's not a deviation from RFC 5988.

So, you are OK with the restriction?
 
> However, if you're changing the definition of link relation types, then:
>
> a) I'm deeply concerned. Redefining a standards-track specification
> seems worryingly close to NIH. There's horrible confusion lurking when
> someone says "Link relation type" and then has to qualify which
> definition.
>
> b) You need to make this absolutely clear in the document; it reads like
> you're restating, not redefining.
> 
> c) The only distinction you claim above that appears to me to be an
> actual distinction is that fragments are disallowed. Yet no such
> restriction exists in the current draft.

I'm still missing something.  How are we changing the definition of a link
relation type, aside from restricting rel to having a single value that is
either an absolute URI or a single link relation type?

Perhaps what might be confusing is the part that starts with "The other
members of the object have meaning only..."  probably should be a separate
paragraph.  The whole focus of the rest of the paragraph is to explain that
the other members of the "link relation object" can only be interpreted once
the link relation type is understood.

We had no intention of changing the definition of a link relation type,
though we do have the stated restrictions in 4.4.4.1: "rel" is exactly one
of either an absolute URI or a registered relation type.

> > Much of the text you removed talks about the other members of the link
> > relation object, which include "type", "href", "titles", and
"properties".
> > The value of the "rel" member dictates how the other members are
interpreted
> > and so I think that text needs to remain.
> Yes, I've probably trimmed too much there.
> > > 2) The use of webfinger with arbitrary URIs is something I had not
> > > previously realised. This raises some concerns for me, as it's not
clear
> > > whether this is either genuinely desirable or whether it introduces
> > > considerations (security and otherwise) beyond those discussed within
> > > the document.
> > >
> > > I would in general rather the mechanism were restricted to acct, http,
> > > https, and perhaps mailto.
> >
> > I don't think use of one URI scheme vs. another makes any difference in
> > terms of security.  However, it was definitely the desire of the group
to be
> > able to use any URI scheme, including some URIs like 'tel'.  Use of
'tel'
> > would mean the exact resolution mechanism would have to be defined, but
> > people did not want to preclude its use.  For others that have a domain
> > part, the desire is to be able to go to the server and request a JRD for
> > that URI.  There may or may not be information available for a given
URI,
> > but the procedures for one URI or another would be exactly the same.
> 
> I did say "security and otherwise". I'm not saying that any given URI
> scheme should be discounted forever more, I am suggesting the document
> should limit the schemes which have a defined behaviour for now.

All URIs have the same defined behavior.  You ask the server if it has any
information about X and it replies with a JRD if it does or 404 if it does
not.  There is no difference in behavior between acct:[e-mail]
or h323:[e-mail].  Both are requesting information about the
person or thing associated with the URI.  As you can see, you'll get the
same answer:

$ curl
https://packetizer.com/.well-known/webfinger?resource=acct:paulej@packetizer
.com
$ curl
https://packetizer.com/.well-known/webfinger?resource=h323:paulej@packetizer
.com

(Except that the aliases array is modified.)
 
> I have no clue what the possible impacts of using webfinger on a message
> id URI might be, nor do I wish to even think about it.

Likely a 404.
 
> I'm pretty sure that mailto has some corner cases we've not yet thought
> about; it's not just an email address after all.

On my server, that returns a JRD in the form of the example you do not like
so much. :-)

It would be entirely reasonable to also return the same JRD as the acct:
URI.  We struggled several years with whether to use mailto or acct.  Given
that some services do not have email (notably, Twitter), there were a push
for acct.  That's fairly well adopted at this point, but I would not dismiss
the use of mailto if that is the identifier one has in hand.

It might also be that aggsrv uses mailto to query for a JRD that has links
pointing to aggsrv documents.  I outlined two ways WF could be used to make
that happen during the BoF.  (But I did it with lightning speed due to time
constraints, so people might have blinked and missed it.)

> > > 3) There is no use of SRV here; I would prefer an SRV resolution step
> > > for at least acct and mailto scheme URIs, and possibly http/https as
> > > well. My concern is that a corporate webserver is typically unlikely
to
> > > be capable of providing webfinger services (being often externally
> > > hosted), and while this could be solved by handling redirects, or by
> > > reverse proxying, SRV feels like a more stable solution here.
> > >
> > > I'd be curious as to whether this has been discussed.
> >
> > This was discussed at length, yes.  We also discussed the use of the URI
> > resource record type.
> >
> > SRV records will tell you what host to go to, but not what URI.
> > URI records will tell you more precisely what URI to query.
> >
> > However, both mechanisms build a dependency on DNS that will not work in
web
> > browsers.  One of the first uses of WebFinger (for which there are
already a
> > few libraries available) is to query for information about people
directly
> > from JavaScript in a browser.  Thus, it was preferred to use a
.well-known
> > location rooted at the given host.
> 
> That sucks.
>
> It's a shame that browsers are holding back use of SRV and other
> decade-old technology for things like this.  But I accept that this has
> been discussed and blocked by browser brokenness.

I agree. Folks have some security concerns with the prospect, though.  I'm
not sure exactly what those concerns are, but it would be nice if there was
a secure was to do SRV or URI record lookups from the browser.

Paul