Re: [apps-discuss] Aggregated service discovery

John Bradley <ve7jtb@ve7jtb.com> Tue, 19 June 2012 15:30 UTC

Return-Path: <ve7jtb@ve7jtb.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 674E611E808F for <apps-discuss@ietfa.amsl.com>; Tue, 19 Jun 2012 08:30:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.198
X-Spam-Level:
X-Spam-Status: No, score=-3.198 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SMRjpJivDkrN for <apps-discuss@ietfa.amsl.com>; Tue, 19 Jun 2012 08:30:52 -0700 (PDT)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7072C21F8518 for <apps-discuss@ietf.org>; Tue, 19 Jun 2012 08:30:52 -0700 (PDT)
Received: by yenq13 with SMTP id q13so5367427yen.31 for <apps-discuss@ietf.org>; Tue, 19 Jun 2012 08:30:51 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=hXXcuJ3HyZMnRdPLp3VhXQ+6UCl2gI6/R5g4ruWMU5Y=; b=OUJZkzx41DgwOMdjLK+CM5qosbbdgV0v9gYkHj2XsFNjckDy6fXDswYjeX0yW2U4vB 5T7buwD8MdSc9QXym/5t912O/vqbmE8LZgjZBw4mu5pLvZN/WtrLBs/fv7YADAGwuyJF BgluOmz3Z0wdmlLDL28uaQXCsMtSMsYCLf4qMRE6F5zTIn2T8p6YqHmdvCBt9B7kqVXL nMntamQnjBF+PasPxDp9/lXNIYKhyBZMgHrw2tCq8RVsjEDHrLPH9E0OhwG01K89kjO0 XRmTtTlQ5aH4Hko22fniI55m6XUZLlzOUy/a7Mddlc3aL1dSK/SxHIwmTCgyMtNnsoEQ 5Syg==
Received: by 10.236.152.97 with SMTP id c61mr23350531yhk.130.1340119851667; Tue, 19 Jun 2012 08:30:51 -0700 (PDT)
Received: from [192.168.1.213] (190-20-33-245.baf.movistar.cl. [190.20.33.245]) by mx.google.com with ESMTPS id c12sm35476622ann.15.2012.06.19.08.30.44 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 19 Jun 2012 08:30:50 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1278)
Content-Type: multipart/signed; boundary="Apple-Mail=_69EDF29C-6322-4A9D-AFED-439E84F6FA86"; protocol="application/pkcs7-signature"; micalg="sha1"
From: John Bradley <ve7jtb@ve7jtb.com>
In-Reply-To: <A09A9E0A4B9C654E8672D1DC003633AE53A11C866F@GRFMBX704BA020.griffon.local>
Date: Tue, 19 Jun 2012 11:30:35 -0400
Message-Id: <9748187C-3224-4C70-869C-63D982A920D3@ve7jtb.com>
References: <64C6DF43A866F40437AF4CC3@cyrus.local> <059c01cd39c8$f3d027c0$db707740$@packetizer.com> <1339625839.48148.YahooMailNeo@web31816.mail.mud.yahoo.com> <4FD917ED.2050805@stpeter.im> <1339628098.85328.YahooMailNeo@web31812.mail.mud.yahoo.com> <4FD91AF7.5050107@stpeter.im> <1339630300.21499.YahooMailNeo@web31812.mail.mud.yahoo.com> <012401cd4cf4$6a465da0$3ed318e0$@packetizer.com> <1340040987.3036.YahooMailNeo@web31812.mail.mud.yahoo.com> <022801cd4d7f$644c4dc0$2ce4e940$@packetizer.com> <FB0F8557-7683-4F57-9495-37AFEFCA8083@ve7jtb.com> <1340047154.69599.YahooMailNeo@web31803.mail.mud.yahoo.com> <24783551-C1B8-456B-8E94-9BF59A3CAC75@ve7jtb.com> <1340051757.92228.YahooMailNeo@web31803.mail.mud.yahoo.com> <3E2D94E4-C8E3-4AF2-A0F0-0C2BCB5B0AA5@ve7jtb.com> <A09A9E0A4B9C654E8672D1DC003633AE53A11C866F@GRFMBX704BA020.griffon.local>
To: Goix Laurent Walter <laurentwalter.goix@telecomitalia.it>
X-Mailer: Apple Mail (2.1278)
X-Gm-Message-State: ALoCoQn0kvmo0foRpH/kH9jDnmazw5y7NVRStxrM3QIUxpaq2244DPLwiUVoMWlv0xbDSpZOMNGl
Cc: "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Aggregated service discovery
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Jun 2012 15:30:55 -0000

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.
>  
> Is that your suggestion john?
> walter
>  
> Da: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] Per conto di John Bradley
> Inviato: lunedì 18 giugno 2012 22.42
> A: William Mills
> Cc: apps-discuss@ietf.org
> Oggetto: Re: [apps-discuss] Aggregated service discovery
>  
> 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.
> On 2012-06-18, at 4:35 PM, William Mills wrote:
> 
> 
> 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.
>  
> From: John Bradley <ve7jtb@ve7jtb.com>
> To: William Mills <wmills@yahoo-inc.com> 
> Cc: Paul E. Jones <paulej@packetizer.com>; 'Peter Saint-Andre' <stpeter@stpeter.im>; "apps-discuss@ietf.org" <apps-discuss@ietf.org> 
> Sent: Monday, June 18, 2012 1:19 PM
> Subject: Re: [apps-discuss] Aggregated service discovery
>  
> 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.
>  
> On 2012-06-18, at 3:19 PM, William Mills wrote:
> 
> 
> 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.
>  
> From: John Bradley <ve7jtb@ve7jtb.com>
> To: Paul E. Jones <paulej@packetizer.com> 
> Cc: 'William Mills' <wmills@yahoo-inc.com>; 'Peter Saint-Andre' <stpeter@stpeter.im>; apps-discuss@ietf.org 
> Sent: Monday, June 18, 2012 11:36 AM
> Subject: Re: [apps-discuss] Aggregated service discovery
>  
> 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:
> 
> 
> 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:carol@example.com",
>   "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:wmills@yahoo-inc.com] 
> Sent: Monday, June 18, 2012 1:36 PM
> To: Paul E. Jones; 'Peter Saint-Andre'
> Cc: 'Cyrus Daboo'; apps-discuss@ietf.org
> Subject: Re: [apps-discuss] Aggregated service discovery
>  
> 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
>  
>  
> From: Paul E. Jones <paulej@packetizer.com>
> To: 'William Mills' <wmills@yahoo-inc.com>; 'Peter Saint-Andre' <stpeter@stpeter.im> 
> Cc: 'Cyrus Daboo' <cyrus@daboo.name>; apps-discuss@ietf.org 
> 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:paulej@packetizer.com”.  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:
>  
> GET /.well-known/host-meta?resource=mailto:paulej@packetizer.com
>  
> This query would then return something like this:
>  
> {
>   "subject" : "mailto:paulej@packetizer.com",
>   "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:wmills@yahoo-inc.com] 
> Sent: Wednesday, June 13, 2012 7:32 PM
> To: Peter Saint-Andre
> Cc: Paul E. Jones; 'Cyrus Daboo'; apps-discuss@ietf.org
> Subject: Re: [apps-discuss] Aggregated service discovery
>  
> 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
>  
>  
> From: Peter Saint-Andre <stpeter@stpeter.im>
> To: William Mills <wmills@yahoo-inc.com> 
> Cc: Paul E. Jones <paulej@packetizer.com>; 'Cyrus Daboo' <cyrus@daboo.name>; "apps-discuss@ietf.org" <apps-discuss@ietf.org> 
> Sent: Wednesday, June 13, 2012 3:57 PM
> Subject: Re: [apps-discuss] Aggregated service discovery
> 
> On 6/13/12 4:54 PM, William Mills wrote:
> > 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
> > domain models.
> 
> 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/
> 
> 
> 
> 
>  
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> 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.
> 
> <logo Ambiente_foglia2.jpg>Rispetta l'ambiente. Non stampare questa mail se non è necessario.
> 
> <logo Ambiente_foglia2.jpg>