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

[Pete Resnick <[e-mail]>]

Sorry for the delay. A few comments, but generally a good direction here:

On 6/14/13 8:43 PM, Mike Jones wrote:
> I've just read about two weeks of WebFinger mail (catching up after vacation) 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.
>    

Fine, of course.

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

This sounds reasonable, though I would add a third column (well, 
actually I would make it the first column of 3) called "Service". In 
this case, the service would be "Open ID Connect Issuer". As time goes 
on, I'd expect there to be things like "Mail Client Configuration", 
"User Account Info", and other such entries.

> 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've always found this a weird case and never understood why you'd want 
to allow queries without "rel" parameters; I don't understand why a 
client would ever want to do that. But if you're going to do that, this 
explanation seems useful. As I've said a few times now, what this 
document is missing is some hint of how the client is going to figure 
out what it needs to do.

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

Agreed. One other possibility is simply to remove all examples, but have 
an informative reference to an existing spec, e.g. OpenID Connect.

> 5.  We could remove all references to and discussion of the acct: URI, since WebFinger actually has no dependency upon it.  Other specifications can still specify that it be used in particular contexts with WebFinger, as OpenID Connect does.
>    

I'd like to see how the acct: URI discussion shakes out before making 
that call. For a while, the two document seemed inextricably linked. 
Now, I'm not sure.

This is a reasonable start toward addressing my concerns. I look forward 
to some proposed text.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - [phone]