Re: [apps-discuss] Looking at Webfinger

[John Bradley <[e-mail]>]

They are all separate identifiers and could resolve to different XRD/JRD.  It would be up to the provider to make the four identifiers return the same information.

Though example 3 and 4 would at least share the same host-metta for resolution.

One unresolved problem is what happens in a hosted environment like Google apps.

If I have a domain like ve7jtb.com where I have pointed mail.ve7jtb.com, calendar.ve7jtb.com , and the MX records to google.
I may have no web server for ve7jtb.com or have it pointed at some simple hosting service, that has no notion of WF.

How would Google provide WF and the services that rely on it to those hosted domains?

This is a real problem.   For openID 2.0 they asked the RP to check with a special google service to see if it was hosted.
This potentially allows for the hijacking of the discovery information and might not be ideal for all protocols using WF.

The ideas that have circulated are:
1 Using SRV records.   Not all DNS services support SRV and users will not configure not correctly  (on the order of the experience with goggle apps XMPP config)
2 Using MX records.  Check the MX host if you can't find the host-metta.   This is more likely to be configurable but ties acct:  and WF to SMTPl in a way that is not ideal.  Clients are also going to need to access DNS directly.
3 Use a special subdomain.  Check the host web finger-discovery-home.ve7jtb.com if you can't find host-meta on the target host.  The downside id that it bends the principal of not steeling namespace.  the upside is that configuring an A record is something users can do, and it is easy for WF clients.

Solving this real world problem for WF is a high priority to be able to deploy it.

John B.
On 2012-07-04, at 3:05 PM, Melvin Carvalho wrote:

> 
> 
> On 4 July 2012 05:46, Murray S. Kucherawy <[e-mail]> wrote:
> On Tue, Jul 3, 2012 at 1:17 PM, John Bradley <[e-mail]> wrote:
> There are existing deployments of WF.   Changes that lead to something incompatible with what is deployed
> are likely to receive more resistance, now that we have a WG draft.
> 
> Not that changes can't be made with rough consensus..
> 
> It may have been easier though to have had Mark and others comments before the WG draft. 
> That might have made it easier to have included some more of the SWD design.
> 
> 
> The fact that there's a WG draft now doesn't change what's been deployed.  These are two orthogonal points.
> 
> I (predictably) concur with Barry's statements about document evolution.  The working group could conceivably completely rewrite Webfinger at this point if it so chooses, as driven by consensus.  That includes applying all, some, or none of Mark's comments, for example.
> 
> If you have some changes you'd like to have the working group consider, the floor is open.
> 
> One question I've been thinking about.  Does the acct: scheme also apply to subdomains too, or just the parent domain, or only where an email exists?
> 
> For example, are the following four, equivalent ways to describe an account?
> 
> acct:[e-mail]
> acct:[e-mail]
> acct:[e-mail]
> https://graph.facebook.com/bob
> 
>  
> 
> -MSK
> 
> _______________________________________________
> apps-discuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/apps-discuss
> 
>