Subject: [webfinger] Automated Service Configuration now uses webfinger

From: Cyrus Daboo <[email-masked]>
Date: Fri, 05 Jul 2013 10:17:27 -0400

Hi folks,
I have recently posted a new version of the Automated Service Configuration 
draft (formerly known as Aggregated Service Discovery): 
<https://datatracker.ietf.org/doc/draft-daboo-aggregated-service-discovery/>.

This protocol now makes use of webfinger to "bootstrap" discovery of the 
config document. Hopefully it will serve as a useful example of how 
webfinger can be used by specific applications. I would appreciate feedback 
from the webfinger community on how we have gone about using webfinger, 
thanks.

-- 
Cyrus Daboo

---

From: "Markus Lanthaler" <[email-masked]>
Date: Fri, 5 Jul 2013 16:55:34 +0200

CC'ing apps-discuss

On Friday, July 05, 2013 4:17 PM, Cyrus Daboo wrote:
> This protocol now makes use of webfinger to "bootstrap" discovery of
> the config document. Hopefully it will serve as a useful example of how
> webfinger can be used by specific applications. I would appreciate
> feedback from the webfinger community on how we have gone about using
> webfinger, thanks.

Looks good to me. The only thing that bugs me is that the  " Automated
Service Configuration Document Format" you define doesn't have its own media
type. That will make it impossible to reuse in other scenarios and ambiguous
how to process the target of a service-configuration link because other
people may start using their own JSON flavors. I would suggest to define a
media type or at list a profile URI to make this unambiguous.

HTH,
Markus

--
Markus Lanthaler
@markuslanthaler

---

From: Jesse Thompson <[email-masked]>
Date: Mon, 08 Jul 2013 08:12:38 -0500

On 7/5/13 9:17 AM, Cyrus Daboo wrote:
> Hi folks,
> I have recently posted a new version of the Automated Service
> Configuration draft (formerly known as Aggregated Service Discovery):

Since "the target FQDN is not in the queried domain" will apply to the 
vast majority of email/calendar domains (hosted by Google, Microsoft, etc):

When it comes to practical implementation, essentially no clients will 
bother to "verify with the user that the link URI target FQDN is 
suitable for use before executing any connections to the host", 
especially if they already have an auto-config scheme that doesn't 
prompt the user (e.g. Thunderbird).

It might be beneficial to the adoption of this standard to bake in a 
method of secure delegation that could work from day one.

Jesse

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 08 Jul 2013 13:46:18 -0600

On 7/8/13 7:12 AM, Jesse Thompson wrote:
>> Hi folks, I have recently posted a new version of the Automated
>> Service Configuration draft (formerly known as Aggregated Service
>> Discovery): 
>> config document. Hopefully it will serve as a useful example of
>> how webfinger can be used by specific applications. I would
>> appreciate feedback from the webfinger community on how we have
>> gone about using webfinger, thanks.
> 
> Since "the target FQDN is not in the queried domain" will apply to
> the vast majority of email/calendar domains (hosted by Google,
> Microsoft, etc):
> 
> When it comes to practical implementation, essentially no clients
> will bother to "verify with the user that the link URI target FQDN
> is suitable for use before executing any connections to the host", 
> It might be beneficial to the adoption of this standard to bake in
> a method of secure delegation that could work from day one.

Hi Jesse, do you have anything in mind?

One option might be POSH:

http://datatracker.ietf.org/doc/draft-miller-posh/

However, if the original query to the service domain goes to an HTTPS
URI, then following a redirect from there to an HTTPS URI at the
target domain seems like a form of secure delegation to me. That's the
same model that Matt Miller and I outline in the POSH draft.

If I've misunderstood your comment, please do let me know. :-)

Peter

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

---

From: Jesse Thompson <[email-masked]>
Date: Mon, 08 Jul 2013 15:03:24 -0500

Peter Saint-Andre <[email-masked]> wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>the

Yes, I was assuming that would be a good option. 

Jesse 

>
>Peter
>
>- -- 
>Peter Saint-Andre
>https://stpeter.im/
>
>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
>Comment: GPGTools - http://gpgtools.org
>Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
>iQIcBAEBAgAGBQJR2xcKAAoJEOoGpJErxa2pin4P/3WZjKXbWnpjErNGAQm621ah
>8T2Yt0mQyChZUpwcFpQqibi3Qf1Y0YdzVSpX0A21rCayF4lz9i+B3w4iJaUslUpC
>lPAxQudKBhSZOQlRAbac3UtMKW5g4beIswFbSVsNkhAHxAsRqvbGWD61sL+rmDzO
>t/BeOjuoqKhXPnSLCjONnDwU+7p79+wTozDMhEtAvdiAoM5qYu8pxn+INWC0yjiA
>Erl+xQisaW4t8Xc/2c+4XioLM1Hfi1AYpcc6SkZn2xO9k2d0aysudf1cvg/Yb/NV
>zmk+kpQ/j/nAqllMayWMa+nD6SBF3ymG4hxBL+yYdeamcdfblkBgi88ryyDYdGO7
>RozGaflNDPw2icgXnav70914V7z9JNI1Y2tLZLxfs4Ag9ORBl5fbcew1phvBA5aR
>gg0JTalFQ5z+LkDZwTmMBG7mmoOyqBeFhITPmJf6iWLG92XbP1UBp+d4wxXmJgNN
>dWVNe6r9rEz1L5PyErtLtE3VzJUrEJTSx3fsqXd/nAkHvq3CRJVzfOo0c2gHCUaj
>zGkRw5v2WuPzQItaAhdH89Hp0n/6BV1my1fzg36wLmxk2MFSRwpVQjadpyyBSEVv
>7HP7bClYAN15bxnorS5DKkrRqH3pVHh+fxloQGVRi24ndNyt4r9wJ0CoSn1mJpgp
>Bg0mkbaxoqOBzte9QtAL
>=hzKu
>-----END PGP SIGNATURE-----
>_______________________________________________
>webfinger mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/webfinger

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 08 Jul 2013 14:04:07 -0600

>> Yes, I was assuming that would be a good option. 

OK, so we might want some text about that, which probably could be
borrowed or adapted from the POSH document.

Peter

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

---

From: John Bradley <[email-masked]>
Date: Mon, 8 Jul 2013 13:36:42 -0700

In Sec 4.2 WF currently allows redirecting requests from a https: uri to another https: uri.

The problem is mostly domains that don't have any sort of secure web hosting to redirect from.

John B.

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 08 Jul 2013 14:44:18 -0600

> web hosting to redirect from.

Well, if you don't have secure web hosting in the first place, secure
delegation via HTTP is going to be a problem, eh? ;-)

I don't see that there's anything we can do about that, other than
warn of the potential dangers.

Peter

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

---

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 9 Jul 2013 00:24:35 -0400

Cyrus,

I had a quick look over the new draft.  I do think it's good that this will
utilize WebFinger in order to retrieve service discovery information.

I am curious about one thing.  When issuing a query to the WF server, the
server returns a link relation of type "service-configuration".  The
associated URL in the Appendix B example is
"https://example.com/service-config".  Since the response from the WF server
is for a specific identifier (user), I believe this URL should point
directly to the service config document for the user.

For example, what I would expect the example in Appendix B to look like
would be this (changed line denoted with !):

   {
     "subject" : "acct:[email-masked]",
     "links" :
     [
       {
         "rel" : "service-configuration",
         "type" : "application/json",
!        "href" : "https://example.com/service-config?id=[email-masked]"
       }
     ]
   }

Or perhaps like:

   {
     "subject" : "acct:[email-masked]",
     "links" :
     [
       {
         "rel" : "service-configuration",
         "type" : "application/json",
!        "href" : "https://example.com/service-config/cyrus.json"
       }
     ]
   }

I believe for all examples we've considered with WF so far, there was no
need for the client to perform any manipulation on the URI for the specific
link relation.  The examples in this document are the first to do that.  Is
there a reason?  Can I persuade you to put the user-specific URL right into
the WebFinger response?

Paul

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Cyrus Daboo
> Sent: Friday, July 05, 2013 10:17 AM
> To: [email-masked]
> Subject: [webfinger] Automated Service Configuration now uses webfinger
> 
> Hi folks,
> Configuration
> feedback

---

From: "Markus Lanthaler" <[email-masked]>
Date: Tue, 9 Jul 2013 11:12:33 +0200

> directly to the service config document for the user.
[...]
> there a reason?  Can I persuade you to put the user-specific URL right
> into the WebFinger response?

I think doing the opposite to make it consistent might be better. The
service-configuration document doesn't contain any information depending on
the user. So, returning *and* requesting https://example.com/service-config
would be better in my opinion.

--
Markus Lanthaler
@markuslanthaler

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 09 Jul 2013 09:45:52 -0400

Hi Markus,

--On July 9, 2013 at 11:12:33 AM +0200 Markus Lanthaler 
<[email-masked]> wrote:

> service-configuration document doesn't contain any information depending
> on the user. So, returning *and* requesting
> https://example.com/service-config would be better in my opinion.

That is not true in general, and I will try and add an example to the spec 
to illustrate that. e.g., some users may be given access to a service that 
other users do not have (and should not see at all) - perhaps some services 
are "for-pay" and the user hasn't signed up yet.

Another aspect we have not addressed is the possibility that the user id 
used to login to the advertised services may be different from the id typed 
in to to discovery - so those id's ought to be in the service config 
document too.

-- 
Cyrus Daboo

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 09 Jul 2013 09:51:36 -0400

Hi Markus,

--On July 5, 2013 at 4:55:34 PM +0200 Markus Lanthaler 
<[email-masked]> wrote:

> Service Configuration Document Format" you define doesn't have its own
> media type. That will make it impossible to reuse in other scenarios and
> ambiguous how to process the target of a service-configuration link
> because other people may start using their own JSON flavors. I would
> suggest to define a media type or at list a profile URI to make this
> unambiguous.
>

Agreed - I think that makes sense - I will add that to the next revision of 
the spec.

-- 
Cyrus Daboo

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 09 Jul 2013 09:54:11 -0400

Hi Paul,

--On July 9, 2013 at 12:24:35 AM -0400 "Paul E. Jones" 
<[email-masked]> wrote:

> need for the client to perform any manipulation on the URI for the
> specific link relation.  The examples in this document are the first to
> do that.  Is there a reason?  Can I persuade you to put the user-specific
> URL right into the WebFinger response?

Yes, that seems like a better approach.

One question that has come up is whether webfinger should be the only HTTP 
service config document discovery mechanism. One suggestion has been to 
have a separate .well-known resource for direct access to the document. My 
feeling is that at this point I think we should stick solely with webfinger 
- partly to help promote use of webfinger itself, but also because there 
might be a whole bunch of other useful information that webfinger could 
provide. e.g. the service config client might also want to get the user's 
vCard in addition to service information and that could be accomplished in 
a single webfinger lookup. I will try adding an example to the spec to 
illustrate that.

-- 
Cyrus Daboo

---

From: "Markus Lanthaler" <[email-masked]>
Date: Tue, 9 Jul 2013 16:00:02 +0200

On Tuesday, July 09, 2013 3:46 PM, Cyrus Daboo wrote:
> Hi Markus,
> 
> --On July 9, 2013 at 11:12:33 AM +0200 Markus Lanthaler wrote:
> 

I wasn't generalizing but talking specifically about the examples in the
current draft.

> in to to discovery - so those id's ought to be in the service config

True, but that should be a separate example. The best would be to describe
both mechanisms and, in the case the "id" query parameter is required, it
should be included directly in service-configuration URL in the WebFinger
response as Paul noted.

--
Markus Lanthaler
@markuslanthaler

---

From: Gonzalo Salgueiro <[email-masked]>
Date: Tue, 9 Jul 2013 12:33:55 -0400

On Jul 9, 2013, at 9:54 AM, Cyrus Daboo <[email-masked]> wrote:

> Hi Paul,
> 
> --On July 9, 2013 at 12:24:35 AM -0400 "Paul E. Jones" <[email-masked]> wrote:
> 

Agreed.
> 
> One question that has come up is whether webfinger should be the only HTTP service config document discovery mechanism. One suggestion has been to have a separate .well-known resource for direct access to the document. My feeling is that at this point I think we should stick solely with webfinger - partly to help promote use of webfinger itself, but also because there might be a whole bunch of other useful information that webfinger could provide. e.g. the service config client might also want to get the user's vCard in addition to service information and that could be accomplished in a single webfinger lookup. I will try adding an example to the spec to illustrate that.

An example would help. In this case, Webfinger's flexibility to discover info of any kind is a big advantage and should be highlighted. Our experiences with Webfinger dictate that simplicity is key to widespread adoption, so IMO restricting to just Webfinger as a discovery framework seems more implementation-friendly.  

Thanks for the updates to the doc.  It is looking much better.

--G

---

From: Jesse Thompson <[email-masked]>
Date: Tue, 09 Jul 2013 15:47:05 -0500

> borrowed or adapted from the POSH document.

My suggestion:

"  In the absence of a secure DNS option,
    clients MUST verify that the link URI target FQDN is suitable
    for use before executing any connections to the host as follows.

    1. If the service domain supports it, verify the domain delegation
    chain of trust using POSH (PKIX Over Secure HTTP) as defined by
    [I-D.draft-miller-xmpp-posh-prooftype]

    2. Require that the target FQDN returned in the
    link relation URI record exactly match the original service
    domain that was queried.

    3. Prompt the user for manual confirmation of the trust relationship.

Jesse