Re: [apps-discuss] Looking at Webfinger

[Phillip Hallam-Baker <[e-mail]>]

I am not clear what the proposal is that is being referred to though.

There is a very clear rationale for having an acct: scheme as far as I
am concerned that is independent of WebFinger. Accounts are a specific
type of resource that we refer to repeatedly in protocols, a URI is
appropriate.

Web Finger looks to me like something that is eminently suitable for
implementation as a .well-known lookup returning some chunk of data in
response.

The place where I would see acct: being used in WebFinger is actually
more the data structures being returned. So for example if I am
looking up my friends profile, I would probably want to see their
battle.net accounts listed there along with their other stuff.


WebFinger would still be a way to resolve acct: URIs, but only one way
and the http: transport might only be one option.

If I click on an acct: link in a browser I would have a range of
possible options:
   * Grab the public WebFinger data
   * Grab the profile data exposed to me by virtue of me being a friend.
   * Attempt to connect on chat
   * Attempt to send an email

I would expect there to be a default action but that choice is
something the user would probably make.


The place I would be using acct: identifiers is in the authentication
and authorization layer.


And no, I don't get the XRD thing either except that it seems that
they painted the bus a color other people liked.

On Tue, Jul 3, 2012 at 5:44 AM, Michiel de Jong <[e-mail]> wrote:
> A brilliant and convincing post, IMO! My remarks, fwiw:
>
> - it should be clear to implementers that they are allowed to use http
> 3** responses to redirect to some other place where running the actual
> webfinger service might be easier to organize. it should be clear to
> clients that they should follow such redirects. afaik, the ability to
> redirect to some other place was an argument for using host-meta as a
> first hop: first discover where the host-meta server is, and then do
> the actual work there.
>
> - changing existing implementations costs money and goodwill in the
> short term (but so do prolonged discussions, so a change like this
> could actually improve adoption if it's done right).
>
> - the reason host-meta and also simple-web-discovery use URIs to
> describe resources is that the architecture of the web says that if
> you point to something of any importance, then the pointing should be
> done with a URI. In this case i think it's fair to say we are not
> really pointing to a resource, but rather just passing a string as a
> query parameter. So i'm all in favour of ?user=user@host or
> ?acct=user@host, i'm just saying that i think that was the reasoning
> at the time.
>
> - if we give various applications all their own well-known URI, then
> there might at some point a need to get an aggregated list of which
> things are discoverable. Aggregated discovery has been discussed in a
> separate thread already, and i think making it optional is good.
>
> Otherwise, unless i overlooked some other point, I think it's hard to
> deny that registering a well-known URI instead of a full URI scheme
> would basically solve everything instantly and be preferable.
>
>
> My 2ct,
>
>
> --
> Michiel de Jong   http://unhosted.org/
> _______________________________________________
> apps-discuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/apps-discuss



-- 
Website: http://hallambaker.com/