Subject: Re: [apps-discuss] Aggregated service discovery

From: William Mills <[email-masked]>
Date: Wed, 13 Jun 2012 15:17:19 -0700 (PDT)

I was just thinking about this topic and found the thread in the archive.  I'm interested specifically in the use case of a client discovering IMAP and SMTP services along with OAuth endpoints.

XMPP, IMAP and POP all have URI schemes defined, though SMTP does not.  With things that already have a dedicated scheme for a service type would it make sense to use the "related" link type already defined?  Then the client looks for "related" links of the scheme they want to discover.

The "related" link type was registered as part of "Atom" http://www.iana.org/go/rfc4287, but it seems to fit.

We still have to deal with SMTP for what I want.  DNS SRV records certainly also work, but I like a one-stop-shop.

-bill

>________________________________
> From: Paul E. Jones <[email-masked]>
>To: 'Cyrus Daboo' <[email-masked]>; [email-masked] 
>Sent: Thursday, May 24, 2012 9:19 AM
>Subject: Re: [apps-discuss] Aggregated service discovery
> 
>Cyrus,
>
>I apologize for not replying sooner.
>
>I do believe WebFinger could be used to locate these services.  I wasn't
>aware of RFC 6186 (and rushed right out to add it to my domain), but
>WebFinger could be used to provide an even better level of granularity.  It
>exists now, so I'm not sure if one would want to migrate to WebFinger, but
>if it did I can imagine something like this:
>
>GET /.well-known/host-meta?resource=mailto:[email-masked]
>
>Returning...
>
>{
>  "subject" : "mailto:[email-masked]",
>  "links" :
>  [
>    {
>      "rel" : "config-email",
>      "href" : "http://www.packetizer.com.com/config/email/?user=paulej"
>    }
>  ]
>}
>
>The above document would include a link relation that refers to mail server
>configuration.  Querying the /config/email/ URI might return a JSON document
>like this:
>
>
>  {
>    "imaps" : "cluster23.imap.packetizer.com",
>    "smtp-submission" : "smtp.packetizer.com"
>  }
>
>(Note: this is a trivial example, whereas we'd probably need to indicate use
>of SSL, TLS, login requirements, etc.)
>
>It would accomplish something similar to SRV records, but provide a finer
>level of granularity to allow domain owners to assign users to different
>machines and specific configurations.
>
>Paul
>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]]
>> On Behalf Of Cyrus Daboo
>> Sent: Tuesday, May 22, 2012 11:00 AM
>> To: [email-masked]
>> Subject: [apps-discuss] Aggregated service discovery
>> 
>> Hi folks,
>> Today many protocols define their own "service discovery" protocols (e.g.,
>> <http://tools.ietf.org/html/rfc6186>,
>> <https://datatracker.ietf.org/doc/draft-daboo-srv-caldav/>,
>> <http://tools.ietf.org/html/rfc6125>).
>> 
>> >From a client perspective, these each work fine individually. But more
>> often than not, a client device actually wants to be able to discover all
>> services a "service provider" has available or provisioned for the user.
>> i.e., a user expects email, calendar, contacts, IM, directory etc to be
>> setup in one step by the client, rather than having to go and setup each
>> service separately. Whilst a client can present a single UI for such an
>> "aggregated service discovery" it still has to go use separate discovery
>> protocols for each service. This is expensive - lots of separate DNS
>> lookups, etc.
>> 
>> Several proprietary systems offer and "aggregated service discovery"
>> protocol - in its simplest form a GET on a well known URI that returns an
>> XML document listing available services and other useful configuration
>> information.
>> 
>> It is time we had such a protocol for the IETF standard suite of
>> protocols.
>> In particular implementors involved in the Calendaring and Scheduling
>> Consortium are very keen to see a good solution to this problem. So I am
>> starting a discussion on this here to solicit some ideas about how best to
>> approach this, with a view to writing a draft.
>> 
>> The obvious, and simplest approach, is the HTTP GET on a .well-known URI
>> returning an XML or JSON document with a standard "schema".
>> 
>> Another possibility is to leverage the webfinger work. I'd like to hear
>> from webfinger experts as to whether a use case like this would be a
>> reasonable solution. Some concerns I have are the security "scope".
>> Obviously service discovery is something that a user does for themselves
>> and their service information should be private, which seems somewhat
>> contrary to the primary user case for webfinger whether other users are
>> looking up the information.
>> 
>> Security, simplicity and efficiency are the key goals for this protocol.
>> 
>> Comments, ideas?
>> 
>> --
>> Cyrus Daboo
>> 
>> _______________________________________________
>> apps-discuss mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/apps-discuss
>
>_______________________________________________
>apps-discuss mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/apps-discuss
>
>
>

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 13 Jun 2012 16:45:01 -0600

On 6/13/12 4:17 PM, William Mills wrote:
> I was just thinking about this topic and found the thread in the
> archive.  I'm interested specifically in the use case of a client
> discovering IMAP and SMTP services along with OAuth endpoints.
> 
> XMPP, IMAP and POP all have URI schemes defined, though SMTP does not. 
> With things that already have a dedicated scheme for a service type
> would it make sense to use the "related" link type already defined? 
> Then the client looks for "related" links of the scheme they want to
> discover.
> 
> The "related" link type was registered as part of "Atom"
> http://www.iana.org/go/rfc4287, but it seems to fit.
> 
> We still have to deal with SMTP for what I want.  DNS SRV records
> certainly also work, but I like a one-stop-shop.

Hi Bill,

What exactly are you trying to discover? At least in XMPP, we've been
using DNS SRV records for many years, and they seem to work just fine
for discovering XMPP servers and the means for connecting to them. If
you want to discover the IM or other accounts associated with an email
address, then WebFinger seems more appropriate.

Peter

---

From: William Mills <[email-masked]>
Date: Wed, 13 Jun 2012 15:54:58 -0700 (PDT)

As I said, I'm interested specifically in IMAP, SMTP and OAuth endpoints.  

As a data point, DNS SRV records are not controllable in many hosted domain models.

> From: Peter Saint-Andre <[email-masked]>
>To: William Mills <[email-masked]> 
>Cc: Paul E. Jones <[email-masked]>; 'Cyrus Daboo' <[email-masked]>; "[email-masked]" <[email-masked]> 
>Sent: Wednesday, June 13, 2012 3:45 PM

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 13 Jun 2012 16:57:59 -0600

> As I said, I'm interested specifically in IMAP, SMTP and OAuth endpoints. 

What exactly is an "endpoint"? A client? An account? A server?

> As a data point, DNS SRV records are not controllable in many hosted

At the last XMPP Summit a few months ago, we learned that DNS SRV
records are unavailable in whole countries (e.g., Japan). That doesn't
mean we should define a replacement for DNS over HTTP. :)

Peter

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

---

From: William Mills <[email-masked]>
Date: Wed, 13 Jun 2012 16:31:40 -0700 (PDT)

In my use case it's a service/server.

Not a terribly happy answer to say "DNS SRV records won't work for you, and there is no other solution.".  By the same token I could ask "Why do we need Webfinger and host meta at all if we have DNS SRV records?".

If XMPP uses SRV records for discovery, that's fine.  IMAP and outbound SMTP services both lack a defined discovery method other than the ubiquitous "service documentation".  Is there a compelling reason to pick DNS over WF for this?  From the app developer point of view I don't want to have N ways to discover M services.

-bill

>Sent: Wednesday, June 13, 2012 3:57 PM

---

From: John Bradley <[email-masked]>
Date: Thu, 14 Jun 2012 01:14:48 +0100

It is probably worth remembering that WF is about discovering services for users.
hostmeta is about discovering services for domains.

One question is if [email-masked] and [email-masked] can have diffrent OAuth Authorization servers for there Imap and SMTP services.

If not then hostmeta and not WF would be the more appropriate way to find the OAuth Authorization service required to get a access grant.

For Connect we are also pondering the problem of users with hosted domains that don't have a web server running on the host for the primary domain, or at-least not one that is likely to provide a WF service.

There is not a perfect answer to that question at the moment.

John B.

---

From: William Mills <[email-masked]>
Date: Wed, 13 Jun 2012 18:51:32 -0700 (PDT)

An important distinction.

In the end though the same question applies.

> From: John Bradley <[email-masked]>
>Cc: Peter Saint-Andre <[email-masked]>; "[email-masked]" <[email-masked]> 
>Sent: Wednesday, June 13, 2012 5:14 PM

---

From: "Paul E. Jones" <[email-masked]>
Date: Sun, 17 Jun 2012 21:48:07 -0400

Bill,

My apologies for the belated reply.  I've been busy this week and got rather
behind on email.

I do not personally like using SRV records, either.  SRV records could work
for smaller domains, but I'm not sure that they're the best solution for
larger domains.  Personally, I would prefer putting users on specific
servers or server clusters and SRV records will not differentiate users. 

To use WebFinger to find one's IMAP, SMTP, or POP server, we could do as I
suggested in my email.  Now the question is what does one query?  Since
these three services are email, I'd suggest we query
"mailto:[email-masked]".  We could use another URI scheme (e.g.,
"acct:"), but mailto seems most appropriate given that you're seeking info
about mail services.

I provided an example earlier that would simply point to a config file with
server information.  We could do this directly via WebFinger like this:

This query would then return something like this:

{

  "links" :

  [

    {

      "rel" : "smtp-server",

      "properties" :

      {

        "host" : "smtp.packetizer.com",

        "port" : "587",

        "login-required" : "yes",

        "transport" : "starttls"

      }

    },

    {

      "rel" : "imap-server",

      "properties" :

      {

        "host" : "imap.packetizer.com",

        "port" : "993",

        "transport" : "ssl"

      }

    }

  ]

}

We would need to standardize the link relation values (smtp-server and
imap-server).  We would also need to document what the various properties
would be.  If you would like to create such a configuration document based
on WebFinger, I'd be happy to help out.  In any case, you can see that
WebFinger would serve quite nicely for conveying configuration information
given a user's email ID.

I'm not sure exactly what you would need for OAuth endpoints, but I would
suggest you make that a separate document since it is not mail related.  (At
least I assume it's not.  Even if it were, the mail server information and
OAuth information are still different animals.)

Paul

From: William Mills [mailto:[email-masked]] 
Sent: Wednesday, June 13, 2012 7:32 PM
To: Peter Saint-Andre
Cc: Paul E. Jones; 'Cyrus Daboo'; [email-masked]
Subject: Re: [apps-discuss] Aggregated service discovery

Not a terribly happy answer to say "DNS SRV records won't work for you, and
there is no other solution.".  By the same token I could ask "Why do we need
Webfinger and host meta at all if we have DNS SRV records?".

If XMPP uses SRV records for discovery, that's fine.  IMAP and outbound SMTP
services both lack a defined discovery method other than the ubiquitous
"service documentation".  Is there a compelling reason to pick DNS over WF
for this?  From the app developer point of view I don't want to have N ways
to discover M services.

-bill

  _____  

From: Peter Saint-Andre <[email-masked]>
To: William Mills <[email-masked]> 
Cc: Paul E. Jones <[email-masked]>; 'Cyrus Daboo' <[email-masked]>;
"[email-masked]" <[email-masked]> 
Sent: Wednesday, June 13, 2012 3:57 PM
Subject: Re: [apps-discuss] Aggregated service discovery

Peter

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

---

From: William Mills <[email-masked]>
Date: Mon, 18 Jun 2012 10:36:27 -0700 (PDT)

Paul, 

Thanks for the reply on this.  I do already have a separate doc for registering the OAuth specific relations, http://tools.ietf.org/id/draft-wmills-oauth-lrdd-01.html

I don't think I like the thought of having to register a new link type for every service, but that might be the right way.  IMAP already has a URI defined for example so if we use a more general link relation then the URI scheme details the type.  The tradeoff is whether you can look for a specific link-type or if you have to scan list elements for the URI type you need.

-bill

>To: 'William Mills' <[email-masked]>; 'Peter Saint-Andre' <[email-masked]> 
>Cc: 'Cyrus Daboo' <[email-masked]>; [email-masked] 
>Sent: Sunday, June 17, 2012 6:48 PM
>Subject: RE: [apps-discuss] Aggregated service discovery
> 
>
>Bill,
> 
>My apologies for the belated reply.  I’ve been busy this week and got rather behind on email.
> 
>I do not personally like using SRV records, either.  SRV records could work for smaller domains, but I’m not sure that they’re the best solution for larger domains.  Personally, I would prefer putting users on specific servers or server clusters and SRV records will not differentiate users. 
> 
>To use WebFinger to find one’s IMAP, SMTP, or POP server, we could do as I suggested in my email.  Now the question is what does one query?  Since these three services are email, I’d suggest we query “mailto:[email-masked]”.  We could use another URI scheme (e.g., “acct:”), but mailto seems most appropriate given that you’re seeking info about mail services.
> 
>I provided an example earlier that would simply point to a config file with server information.  We could do this directly via WebFinger like this:
> 
>We would need to standardize the link relation values (smtp-server and imap-server).  We would also need to document what the various properties would be.  If you would like to create such a configuration document based on WebFinger, I’d be happy to help out.  In any case, you can see that WebFinger would serve quite nicely for conveying configuration information given a user’s email ID.
> 
>I’m not sure exactly what you would need for OAuth endpoints, but I would suggest you make that a separate document since it is not mail related.  (At least I assume it’s not.  Even if it were, the mail server information and OAuth information are still different animals.)
> 
>Paul
> 
>From:William Mills [mailto:[email-masked]] 
>>From:Peter Saint-Andre <[email-masked]>

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 18 Jun 2012 14:22:59 -0400

Bill,

In the referenced draft below, I assume the “grant-types” and “token-types” should be contained inside a “properties”?  That is, I think you want this:

{

  "subject" : "acct:[email-masked]",

  "links" :

  [

    {

      "rel" : "oauth2-athorize",

      "href" : "http://login.example.com/oauth2/authorize"

    },

    {

      "rel" : "oauth2-token",

      "href" : "https://login.example.com/oauth2/token",

     "properties" :

      {

       "grant-types" : "code password",

        "token-types" : "bearer"

      }

    }

  ]

}

For auto-provisioning of email clients (which I understand was your goal), we can either define one link relation that points to a separate configuration document of some sort, or we define multiple link relations.  My previous example showed the single link relation and the email below shows use of multiple.  Both have pros and cons, but I tend to favor using multiple link relations, since this allows one to introduce new stuff without changing the one mail configuration file.  Also, it reduces the number of queries a mail client has to make to get config information.

You indicate that IMAP already has a defined URI.  Where is that defined?  I could not find it in the IANA link relations registry, so I assume it’s really a URI defined in a spec somewhere.  In any case, we could use URIs for these things (rather than defining single token link relation values and registering them).  I have no preference, but I would like an agreed approach to provisioning.  I hate configuring all the stuff manually on email clients. :-)

Paul

From: William Mills [mailto:[email-masked]] 
Sent: Monday, June 18, 2012 1:36 PM
To: Paul E. Jones; 'Peter Saint-Andre'
Cc: 'Cyrus Daboo'; [email-masked]
Subject: Re: [apps-discuss] Aggregated service discovery

Paul, 

-bill

  _____  

Bill,

{

  "links" :

  [

    {

      "rel" : "smtp-server",

      "properties" :

      {

        "host" : "smtp.packetizer.com <http://smtp.packetizer.com/> ",

        "port" : "587",

        "transport" : "starttls"

      }

    },

    {

      "rel" : "imap-server",

      "properties" :

      {

        "host" : "imap.packetizer.com <http://imap.packetizer.com/> ",

        "port" : "993",

        "transport" : "ssl"

      }

    }

  ]

}

Paul

-bill

  _____  

Peter

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

---

From: John Bradley <[email-masked]>
Date: Mon, 18 Jun 2012 14:36:22 -0400

A user is likely to have a number of OAuth authorization services for different things.  

I suspect that the best way to organize it is to describe the services the user has:
openID Connect
imap
portable contacts
etc

and let the service describe how it is authenticated and where the endpoints are.

For Connect there is a single relation for the Connect issuer and that is then discovered to get the endpoint and other configuration information.  
Given that user identifiers may point to services in other domains it is best to leave it up to the service to describe itself rather than relying on individual user information to be correct.

John B.

On 2012-06-18, at 2:22 PM, Paul E. Jones wrote:

> Thanks for the reply on this.  I do already have a separate doc for registering the OAuth specific relations,http://tools.ietf.org/id/draft-wmills-oauth-lrdd-01.html
>

---

From: William Mills <[email-masked]>
Date: Mon, 18 Jun 2012 12:15:23 -0700 (PDT)

Ah, I missed that nuance, that declared application data goes in "properties".

The "imap" scheme is listed in http://www.iana.org/assignments/uri-schemes.html and defined in http://www.rfc-editor.org/rfc/rfc5092.txt

I've been inquiring about the "related" link relation type, which seems semantically what we want at first glance.  It's not clear to me that you can define a link relation that does not have a uri?  That has only application data?  I don't think it's right to extend link relations to be an arbitrary data container, but requiring a URI scheme is going to be a lot of work for some things.  SMTP is the hard one right now, a hack for that might be a new relation and just put the postmaster mailto: link in the URI spot.  

I'm not inclined to try to encode arbitrary flags like login-required, I'd probably go as far as a well known service name and leave it there.

-bill

>Sent: Monday, June 18, 2012 11:22 AM
>>From:Paul E. Jones <[email-masked]>

---

From: William Mills <[email-masked]>
Date: Mon, 18 Jun 2012 12:19:14 -0700 (PDT)

Unfortunately we came to the conclusion that letting a service endpoint define it's authenticators is probably wrong, this was in the context of discovery for SASL mechanisms.  The core problem is when the client supports the password grant if it then trusts the service endpoint to tell it who to give the username password pair then it's vulnerable.

>To: Paul E. Jones <[email-masked]> 
>Cc: 'William Mills' <[email-masked]>; 'Peter Saint-Andre' <[email-masked]>; [email-masked] 
>Sent: Monday, June 18, 2012 11:36 AM

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 18 Jun 2012 16:16:45 -0400

Bill,

Ah, I was confused.  I thought you were speaking of an IMAP link relation.  You did same URI scheme.

It is possible to have a link relation with no URI.  At least that is valid per the XRD spec.  The href is listed as optional:

http://docs.oasis-open.org/xri/xrd/v1.0/xrd-1.0.html#element.link

In any case, one could return an IMAP URI or one could just return properties.  The choice is ours, but I do tend to think we would not want a URI scheme for POP3, IMAP, SMTP, etc.  It seems like overkill. 

This is why I preferred returning the mail configuration info using the “mailto” URI scheme.  This is an example where I would prefer it over “account” since “mailto” would refer to  a specific email address.  With that address, one could then discover the mail server configuration data as I showed it below.  I’d expect this to be populated by the email provider, not the user.

If we want to use the href field, then we could just use WebFinger to point to the email config document as I had initially proposed.  That was something like this:

{

  "links" :

  [

    {

      "rel" : "config-email",

    }

  ]

}

So the client would first query the WebFinger server to get the above link relation (“config-email” or whatever) and then perform a second query to get the actual configuration parameters.  The document containing the configuration parameters would be in whatever format we want to define.

There are pros and cons with each approach.  I have no strong preference either way, but as I said, I’d love to see agreement on some universally agreed approach :)

Paul

Sent: Monday, June 18, 2012 3:15 PM

-bill

  _____  

Bill,

{

  "links" :

  [

    {

    },

    {

      "rel" : "oauth2-token",

     "properties" :

      {

        "token-types" : "bearer"

      }

    }

  ]

}

Paul

Paul, 

-bill

  _____  

Bill,

{

  "links" :

  [

    {

      "rel" : "smtp-server",

      "properties" :

      {

        "port" : "587",

        "transport" : "starttls"

      }

    },

    {

      "rel" : "imap-server",

      "properties" :

      {

        "port" : "993",

        "transport" : "ssl"

      }

    }

  ]

}

Paul

-bill

  _____  

Peter

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

---

From: John Bradley <[email-masked]>
Date: Mon, 18 Jun 2012 16:19:08 -0400

That is not what I am saying.

I am saying that the user's discovery document has a link relation to the providers decryption of the service.   That is different from the imap endpoint providing the link relation.

If you can trust the user's information to provide the Oauth endpoint why can't you trust the user's information to link to the description of the service.

As I have pointed out before you probably don't want per user configuration for things like imap,  the simplest thing is to describe the service in host-meta and forget the extra user discovery steps and maintenance.

John B.

---

From: William Mills <[email-masked]>
Date: Mon, 18 Jun 2012 13:35:57 -0700 (PDT)

I believe you meant description where you wrote decryption...

IMAP likely is advertized with host-meta, however I do have a use case where premium users may get a different DOS guarantee and might be handled on a different set of servers, and therefor a per-user return would be appropriate.

>Cc: Paul E. Jones <[email-masked]>; 'Peter Saint-Andre' <[email-masked]>; "[email-masked]" <[email-masked]> 
>Sent: Monday, June 18, 2012 1:19 PM

---

From: John Bradley <[email-masked]>
Date: Mon, 18 Jun 2012 16:42:12 -0400

OK but you are talking about the OAuth authorization service for IMAP,  do you intend to run different ones for different users?

If you are that's fine.   However listing the service configuration in the users XRD rather than pointing to it from the XRD is probably not a good design.

Listing a generic OAuth 2.0 authorization service in the users XRD is interesting, but probably not specific enough.

John B.

---

From: William Mills <[email-masked]>
Date: Mon, 18 Jun 2012 13:56:44 -0700 (PDT)

What data elements does a generic service description need?  

    name:  a service name form http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xml
    host:  hostname

    port:  a port number

Is the name here sufficient to convey protocol and such things as SSL?  I think so, if we are using well known services.

>Sent: Monday, June 18, 2012 1:16 PM

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 18 Jun 2012 17:43:43 -0400

Bill,

It’s hard to make everything generic.  For IMAP, for example, one should be able to specify the use of SSL, TLS, or no security.  It’s also important to specify the root folder path.  There may be other options, but I’m not an IMAP guru.  Those are just options I’ve had to configure personally.

For other services, the transports might vary from TCP to UDP, too.   So, for a generic service I think indicating a transport, transport security option.  Things like the folder path are specific to IMAP and would have no meaning to, say, SMTP.

For SMTP, one would need to indicate whether logging in is required or not.

So, I think any service that would be specified would have:

   Hostname

   Port

   Transport

   Transport-Security  (Perhaps the transport and transport security could be combined?)

   Protocol specific parameters (IMAP root folder path, SMTP login requirements)

The “service name” could be assumed given the value of the link relation.    And it’s those protocol-specific parameters that are a challenge to make generic, but they are important.

Paul

Sent: Monday, June 18, 2012 4:57 PM

    host:  hostname

    port:  a port number

 

  _____  

Bill,

{

  "links" :

  [

    {

      "rel" : "config-email",

    }

  ]

}

Paul

-bill

  _____  

Bill,

{

  "links" :

  [

    {

    },

    {

      "rel" : "oauth2-token",

     "properties" :

      {

        "token-types" : "bearer"

      }

    }

  ]

}

Paul

Paul, 

-bill

  _____  

Bill,

{

  "links" :

  [

    {

      "rel" : "smtp-server",

      "properties" :

      {

        "port" : "587",

        "transport" : "starttls"

      }

    },

    {

      "rel" : "imap-server",

      "properties" :

      {

        "port" : "993",

        "transport" : "ssl"

      }

    }

  ]

}

Paul

-bill

  _____  

Peter

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

---

From: Cyrus Daboo <[email-masked]>
Date: Mon, 18 Jun 2012 18:08:00 -0400

Hi Paul,

>    Protocol specific parameters (IMAP root folder path, SMTP login

Andrew and I are working on a draft that has pretty much that set of 
attributes per service. We did include details on authentication - (e.g. 
mechanism, user id to use etc). Some other features are needed, such as 
priority (e.g., whether IMAP is preferred over POP). Our draft will start 
out with an XML schema and its own .well-known resource - that was pretty 
much our original design before we started the wider discussions here - but 
obviously that is all open to change (i.e. JSON, host-meta or whatever).

-- 
Cyrus Daboo

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 18 Jun 2012 19:42:59 -0400

Cyrus,

> much our original design before we started the wider discussions here -
> but obviously that is all open to change (i.e. JSON, host-meta or
> whatever).

WebFinger is about discovering resources, and you are defining the resource.  What you are apparently already working on is in line with the approach I suggested at the outset: use WebFinger with an address like mailto:[email-masked] to discover a link relation of type "config-email" (or whatever) that points to this XML document you're defining.  That XML document can contain all of the information necessary to provision a mail client.

I look forward to seeing it and would be happy to lend a hand.

Paul

---

From: Goix Laurent Walter <[email-masked]>
Date: Tue, 19 Jun 2012 16:33:59 +0200

I also believe the the oauth related links could typically stay in the host-meta rather than the user's xrd/jrd. The draft should not mandate its usage into one or the other imho and it will be up to service providers to include these links into host-meta (if this can be generalized) or user descriptors.

Is that your suggestion john?
walter

Da: [email-masked] [mailto:[email-masked]] Per conto di John Bradley
Inviato: lunedì 18 giugno 2012 22.42
A: William Mills
Cc: [email-masked]
Oggetto: Re: [apps-discuss] Aggregated service discovery

John B.

________________________________
From: John Bradley <[email-masked]<mailto:[email-masked]>>
To: William Mills <[email-masked]<mailto:[email-masked]>>
Cc: Paul E. Jones <[email-masked]<mailto:[email-masked]>>; 'Peter Saint-Andre' <[email-masked]<mailto:[email-masked]>>; "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Sent: Monday, June 18, 2012 1:19 PM
Subject: Re: [apps-discuss] Aggregated service discovery

John B.

________________________________
From: John Bradley <[email-masked]<mailto:[email-masked]>>
To: Paul E. Jones <[email-masked]<mailto:[email-masked]>>
Cc: 'William Mills' <[email-masked]<mailto:[email-masked]>>; 'Peter Saint-Andre' <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Sent: Monday, June 18, 2012 11:36 AM
Subject: Re: [apps-discuss] Aggregated service discovery

John B.

Bill,

In the referenced draft below, I assume the "grant-types" and "token-types" should be contained inside a "properties"?  That is, I think you want this:

{

You indicate that IMAP already has a defined URI.  Where is that defined?  I could not find it in the IANA link relations registry, so I assume it's really a URI defined in a spec somewhere.  In any case, we could use URIs for these things (rather than defining single token link relation values and registering them).  I have no preference, but I would like an agreed approach to provisioning.  I hate configuring all the stuff manually on email clients. :-)

Paul

Cc: 'Cyrus Daboo'; [email-masked]<mailto:[email-masked]>

Paul,

-bill

________________________________
From: Paul E. Jones <[email-masked]<mailto:[email-masked]>>
To: 'William Mills' <[email-masked]<mailto:[email-masked]>>; 'Peter Saint-Andre' <[email-masked]<mailto:[email-masked]>>
Cc: 'Cyrus Daboo' <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Sent: Sunday, June 17, 2012 6:48 PM
Subject: RE: [apps-discuss] Aggregated service discovery

Bill,

My apologies for the belated reply.  I've been busy this week and got rather behind on email.

I do not personally like using SRV records, either.  SRV records could work for smaller domains, but I'm not sure that they're the best solution for larger domains.  Personally, I would prefer putting users on specific servers or server clusters and SRV records will not differentiate users.

To use WebFinger to find one's IMAP, SMTP, or POP server, we could do as I suggested in my email.  Now the question is what does one query?  Since these three services are email, I'd suggest we query "mailto:[email-masked]".  We could use another URI scheme (e.g., "acct:"), but mailto seems most appropriate given that you're seeking info about mail services.

{
  "subject" : "mailto:[email-masked]",
  "links" :
  [
    {
      "rel" : "smtp-server",
      "properties" :
      {
        "host" : "smtp.packetizer.com<http://smtp.packetizer.com/>",
        "port" : "587",
        "login-required" : "yes",
        "transport" : "starttls"
      }
    },
    {
      "rel" : "imap-server",
      "properties" :
      {
        "host" : "imap.packetizer.com<http://imap.packetizer.com/>",
        "port" : "993",
        "transport" : "ssl"
      }
    }
  ]
}

We would need to standardize the link relation values (smtp-server and imap-server).  We would also need to document what the various properties would be.  If you would like to create such a configuration document based on WebFinger, I'd be happy to help out.  In any case, you can see that WebFinger would serve quite nicely for conveying configuration information given a user's email ID.

I'm not sure exactly what you would need for OAuth endpoints, but I would suggest you make that a separate document since it is not mail related.  (At least I assume it's not.  Even if it were, the mail server information and OAuth information are still different animals.)

Paul

From: William Mills [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
Sent: Wednesday, June 13, 2012 7:32 PM
To: Peter Saint-Andre
Cc: Paul E. Jones; 'Cyrus Daboo'; [email-masked]<mailto:[email-masked]>
Subject: Re: [apps-discuss] Aggregated service discovery

-bill

________________________________
From: Peter Saint-Andre <[email-masked]<mailto:[email-masked]>>
To: William Mills <[email-masked]<mailto:[email-masked]>>
Cc: Paul E. Jones <[email-masked]<mailto:[email-masked]>>; 'Cyrus Daboo' <[email-masked]<mailto:[email-masked]>>; "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, June 13, 2012 3:57 PM
Subject: Re: [apps-discuss] Aggregated service discovery

Peter

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

_______________________________________________
apps-discuss mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/apps-discuss

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.

Rispetta l'ambiente. Non stampare questa mail se non è necessario.

---

From: John Bradley <[email-masked]>
Date: Tue, 19 Jun 2012 11:30:35 -0400

Yes,

I wouldn't preclude putting config info into the users XRD.    

It is mostly the protocols that use WF for discovery that should be specifying the lookup pattern.

For Connect you would discover the issuer link relation in the user XRD and then follow that to get the configuration for the IdP.

Allowing a user XRD to define the OAuth endpoint URI and signing keys would open all sorts of interesting attacks.  

For Connect we don't assume that the IdP/Issuer controls the user's WF.   I think that is consistent with the overall WF approach.

Putting service config directly in a XRD/JRD is supported, however if those config settings have security implications, that probably limits them to XRD/JRD that are under the control of the service.

When we did XRD several years ago the format was intended to be generic and allow the protocols using them to define the higher level semantics.

For things like IMAP you need to consider that as an enterprise I may be foo.com but host key email with Google or Yahoo etc. 

My MTA is going to need to discover me based on my enterprise email but use the service provider IMAP/SMTP and perhaps my enterprise SSO/OAuth Authorization service or Mail Service provider SSO/OAuth Authorization service for getting an access token.

There is also the problem of what to do if the enterprise is not hosting a web server on a host with the same name as the domain(not uncommon, at least not on a trusted host).
This is something WF doesn't yet support but I suspect is important to Bill's use case and also important to Connect.

You probably need to have enough flexibility to accommodate the various use cases.  

John B.

On 2012-06-19, at 10:33 AM, Goix Laurent Walter wrote:

> I also believe the the oauth related links could typically stay in the host-meta rather than the user’s xrd/jrd. The draft should not mandate its usage into one or the other imho and it will be up to service providers to include these links into host-meta (if this can be generalized) or user descriptors.
>  
> <logo Ambiente_foglia2.jpg>Rispetta l'ambiente. Non stampare questa mail se non è necessario.
> 
> <logo Ambiente_foglia2.jpg>

---

From: William Mills <[email-masked]>
Date: Tue, 19 Jun 2012 08:51:49 -0700 (PDT)

Agreed, and in fact the 3rd avenue this might be used in is Link headers on a failed OAuth authorization in a webservices context.  I'll re-read with that in mind and see if we need edits.

> From: Goix Laurent Walter <[email-masked]>
>To: John Bradley <[email-masked]>; William Mills <[email-masked]> 
>Cc: "[email-masked]" <[email-masked]> 
>Sent: Tuesday, June 19, 2012 7:33 AM
>Subject: R: [apps-discuss] Aggregated service discovery
> 
>
> 
>Da:[email-masked] [mailto:[email-masked]] Per conto di John Bradley
>>From:John Bradley <[email-masked]>
>>>From:John Bradley <[email-masked]>
>This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.Rispetta l'ambiente. Non stampare questa mail se non è necessario.  
>
>