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

[Peter Saint-Andre <[e-mail]>]

On 6/14/13 7:43 PM, Mike Jones wrote:
> I've just read about two weeks of WebFinger mail (catching up after
> vacation) 

You're a good man. :-)

> have the following observations on how we might make
> progress towards closing the issues being discussed.
> 
> 1.  Explicitly state that WebFinger is a framework and that the
> information to be returned for specific "rel" link relation types for
> specific kinds of URIs is outside the scope of the specification, but
> is intended to be defined by other specifications.

Agreed.

> 2.  We could establish a registry indexed by "rel" link relation
> values pointing to documents that define this information.  For
> instance, we could then register the "rel" value
> "http://openid.net/specs/connect/1.0/issuer" and point it to
> http://openid.net/specs/openid-connect-discovery-1_0.html, which
> defines the meaning of that link relation.  Other link relation
> definitions could then also use that registry.

That seems quite sensible.

> 3.  Explicitly state that the link relation types that will be
> returned from server when no "rel" parameter is used is entirely
> dependent upon the services supported by that host, and that, in the
> general case, clients must be prepared for the response to be the
> empty set for any particular resource.

I'll need to think about that more.

> 4.  Since people are finding the examples problematic, we could
> remove them, or possibly only keep the OpenID Connect one, which is
> concrete and being used in practice.  Or in fact, we could add a
> second OpenID Connect example - so that there's one with the resource
> being a URL and another with the resource using e-mail address
> syntax.  We could also bring over the apparently-innocuous
> "copyright" and "author" examples from RFC 6415, if those would cause
> people less consternation.  But the device and e-mail examples seem
> to be generating more heat than light.

Yes.

> 5.  We could remove all references to and discussion of the acct:
> URI, since WebFinger actually has no dependency upon it. 

I think that would be helpful, because in the off-list email threads
with the IESG there is a lot of confusion about the meaning of an acct
URI, and much of that confusion stems from (I think) a misunderstanding
of WebFinger's relationship to acct URIs and a conflation of the
semantic meaning that comes from WebFinger and the semantic meaning that
comes from acct URIs.

> Other
> specifications can still specify that it be used in particular
> contexts with WebFinger, as OpenID Connect does.

Right.

> I realize that the examples provide more context for developers but
> if they're standing between us and finishing the spec it would be
> better for them to go. 

I'd hate to remove examples that are helpful, but if some of the
examples are confusing (and I think they are, because they are
speculative rather than examples that reflect existing usage or
WebFinger-based applications) then let's remove them.

> Likewise, if acct: is standing between us and
> finishing, it should go too.

Works for me. I didn't conceive of acct URIs, I'm just trying to get
them documented properly.

> I'll close by saying that I believe that WebFinger does one simple
> thing very well - enabling querying about a resource at a host,
> optionally narrowing the query to a particular kind of information of
> interest.  Like OAuth, this protocol is both incredibly simple and
> incredibly powerful.  Like OAuth, particular applications of
> WebFinger will define particular syntax to be used in requests and
> responses that meets the needs of those applications.
> 
> Let's focus our energies on deciding what the best next steps are to
> finish in a timely manner.

Thanks for the productive message. Let's get this done.

Peter

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