From nico@cryptonector.com Tue May 8 14:28:39 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3E9D11E8072 for ; Tue, 8 May 2012 14:28:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.696 X-Spam-Level: X-Spam-Status: No, score=-0.696 tagged_above=-999 required=5 tests=[AWL=-1.133, BAYES_40=-0.185, FM_FORGED_GMAIL=0.622] 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 p-Bw0v12ec+7 for ; Tue, 8 May 2012 14:28:39 -0700 (PDT) Received: from homiemail-a70.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id F2C7D11E8088 for ; Tue, 8 May 2012 14:28:38 -0700 (PDT) Received: from homiemail-a70.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTP id B1835768061 for ; Tue, 8 May 2012 14:28:38 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :date:message-id:subject:from:to:content-type; q=dns; s= cryptonector.com; b=g/cvKchmEwj7Wx1Mwh4H0IfkWZqLc570Cx+avgBpTpdp Ma6zBrtovDjTcb45uaWl7TkJJ8JBehU/X+nXGlYSg7nLSM0B3tRx0uUxS1xAtdqQ iG/Pr6o1kg5pDe9XdbSTq1qU2F3RuBjgctBtE4FVncvluI1OHziOkjuQT/KLzSA= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:date:message-id:subject:from:to:content-type; s= cryptonector.com; bh=apcuK6F29DHClofU9Stf3hdKCYk=; b=EbmXPvit4c1 5cjIvE2FSKV+i62fPs7spHxvE4sd2Qatary652P8vw88+8WqrUCz3JUwH/ZUZoO3 J030CcdBWmTgSlDbEN8avBoabtCPV1RYVlum14QyTgq3u33Nj7eIAQffDTGLC/bx POpE/Y6P+r3GtAefulIEuH0bIUFx3ZlM= Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTPSA id 9F74C76806B for ; Tue, 8 May 2012 14:28:38 -0700 (PDT) Received: by dacx6 with SMTP id x6so408207dac.31 for ; Tue, 08 May 2012 14:28:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.132.201 with SMTP id ow9mr1440696pbb.160.1336512518153; Tue, 08 May 2012 14:28:38 -0700 (PDT) Received: by 10.68.5.99 with HTTP; Tue, 8 May 2012 14:28:38 -0700 (PDT) Date: Tue, 8 May 2012 16:28:38 -0500 Message-ID: From: Nico Williams To: kitten@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: [kitten] Proposal: extension to GSS_Acquire/Add_cred_from() X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 21:28:39 -0000 Recap: Simo and I have a proposal to add three new functions dealing with acquisition of creds from "credential stores" and storing credentials into credential stores. A credential store is a sequence of key/value pairs where the keys are URNs and the value syntaxes given by the keys. Among the possible keys as "password file" and such. Simo intends to use these functions in a context where the key/value pairs come from a configuration file. It would be inappropriate to allow passwords/keys/PINs/secrets of any kind to be encoded in a configuration file, so he proposes that no URNs be provided by which to pass secret values to the mechanism. But I see a general replacement for gss_acquire_cred_with_password() in these new functions and I don't want to either preclude such a use or force apps to write secrets into temporary files. At the same time I completely agree that no secrets should be stored in configuration files... So I'd like to propose an extension to the GSS_Acquire/Add_cred_from() functions such that the mechanism can tell if any secrets in the cred_store are to be allowed or not. Recall that the form of a cred store in the C bindings would be: typedef struct gss_cred_store_element_struct { const char *urn; const char *value; } gss_cred_store_element, *gss_cred_store_element_t; typedef const struct gss_cred_store_element *gss_const_cred_store_element_t; typedef struct gss_cred_store_struct { OM_uint32 count; gss_const_cred_store_element_t *elements; } gss_cred_store, *gss_cred_store_t; typedef const struct gss_cred_store_struct *gss_const_cred_store_t; I can see several possible extensions for allowing secret values here. My preference would be to have a per-element flag field because it that would allow the app/mech to distinguish the origin of each element. Perhaps cred stores should be opaque and should have accessor by which to add key/value pairs, then the accesspor could have an argument indicating the origin of the key/value pair. If we wanted to have a function for learning what the current cred store is then we'd need to concern ourselves with memory management, and then the lessons of gss_buffer_t and friends should push us to using an opaque object type here! I do realize that in order to use GSS_Acquire/Add_cred_from() as the basis for a GSS-API interactive initial credential acquisition interface we'd need a way to tell the app what cred store elements the mechanism needs, and that perhaps this is not the best approach to a generic initial cred acquisition API. However, I also don't want to make it harder to re-use the cred store functions later on if we should want to use them as the basis of an interactive initial credential acquisition API. So my proposal, then, is to make the gss_cred_store_t into an opaque type and to provide a constructor, a destructor, a function by which to add elements, and a function by which to iterate elements, with elements consisting of: key, value, flag, and one flag defined to indicate that the value was obtained interactively or from an appropriate store of secrets. Comments? Nico -- From ghudson@mit.edu Tue May 8 15:29:39 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62D5E21F8467 for ; Tue, 8 May 2012 15:29:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 1Xbuhpogi0Cu for ; Tue, 8 May 2012 15:29:38 -0700 (PDT) Received: from dmz-mailsec-scanner-5.mit.edu (DMZ-MAILSEC-SCANNER-5.MIT.EDU [18.7.68.34]) by ietfa.amsl.com (Postfix) with ESMTP id AEF7321F8466 for ; Tue, 8 May 2012 15:29:38 -0700 (PDT) X-AuditID: 12074422-b7fd66d0000008f9-59-4fa99e515427 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id A1.4F.02297.15E99AF4; Tue, 8 May 2012 18:29:37 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id q48MTbgG015671; Tue, 8 May 2012 18:29:37 -0400 Received: from [192.168.1.4] (pool-173-48-254-186.bstnma.fios.verizon.net [173.48.254.186]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id q48MTYkw013482 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 8 May 2012 18:29:36 -0400 (EDT) Message-ID: <4FA99E4E.5050008@mit.edu> Date: Tue, 08 May 2012 18:29:34 -0400 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Nico Williams References: In-Reply-To: X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpileLIzCtJLcpLzFFi42IR4hTV1g2ct9LfYM9yY4ujm1exWJy6doTN gcnj5alzjB5LlvxkCmCK4rJJSc3JLEst0rdL4Mq4/56/YA57xZ29TxgbGJ+xdjFyckgImEhM 6H7OBGGLSVy4t56ti5GLQ0hgH6PExcvLmSCc9YwSf1v/MEM4d5kk3n9eyQjSwiugJnF71wQ2 EJtFQFXizql1YHE2AWWJg2e/sYDYogIhEueefGeDqBeUODnzCVhcREBT4vq8pWBxZgFhiQvb 94KdJCzgITFz1UugOAfQsgCJPxOkQMKcAoESbS/fgoUlBKQkDi01gujUkXjX94AZwpaX2P52 DvMERqFZSJbNQlI2C0nZAkbmVYyyKblVurmJmTnFqcm6xcmJeXmpRbqmermZJXqpKaWbGEFB ze6itIPx50GlQ4wCHIxKPLxKL5b7C7EmlhVX5h5ilORgUhLlnTtzpb8QX1J+SmVGYnFGfFFp TmrxIUYJDmYlEd5Z6kA53pTEyqrUonyYlDQHi5I4r7rWOz8hgfTEktTs1NSC1CKYrAwHh5IE 75K5QI2CRanpqRVpmTklCGkmDk6Q4TxAw9tBaniLCxJzizPTIfKnGBWlxHn5QRICIImM0jy4 XljSecUoDvSKMG8hSBUPMGHBdb8CGswENHhDF9jgkkSElFQD4+yc1Tb2L+fMCthlVKgTF5Y7 p7nqQ+SmP3wmElXHFfdUL1odr+HtMCtblLXkU3Bc5boajg3PzcOPci/95zBN74DDy8xLqzzb etYrbL653fxAHvOWqPN3k44EqKg8qt1zQFm1umurYzyn+x+2hXzd57XTjKN8wj9McHmlvZy3 8WG0XL9zFE+EEktxRqKhFnNRcSIAPTE2/BUDAAA= Cc: kitten@ietf.org Subject: Re: [kitten] Proposal: extension to GSS_Acquire/Add_cred_from() X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 22:29:39 -0000 On 05/08/2012 05:28 PM, Nico Williams wrote: > an extension to the GSS_Acquire/Add_cred_from() > functions such that the mechanism can tell if any secrets in the > cred_store are to be allowed or not. [...] > My preference would be to have a per-element flag field [...] > Perhaps cred stores should be opaque and should have accessor [...] > make the gss_cred_store_t into an opaque > type and to provide a constructor, a destructor, a function by which > to add elements, and a function by which to iterate elements I think this is far too much complexity for the benefit. I also think cred store parameters are probably not a good basis for making initial credential acquisition work through GSS. Conflating "where credentials are stored" with "secrets you need to acquire credentials" seems like a bad idea. So, I disagree that we want to add complexity in order to leave the door open to this. From nico@cryptonector.com Tue May 8 15:48:11 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 646E221F84D9 for ; Tue, 8 May 2012 15:48:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.882 X-Spam-Level: X-Spam-Status: No, score=-1.882 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 2Qfs3zFuANDn for ; Tue, 8 May 2012 15:48:10 -0700 (PDT) Received: from homiemail-a32.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id C0DC521F84D8 for ; Tue, 8 May 2012 15:48:10 -0700 (PDT) Received: from homiemail-a32.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTP id D23A7584065 for ; Tue, 8 May 2012 15:48:09 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=Y4czfGCMyqA3TJGk9Vg5Sc/4h0AELsq54C4qZWX6la3L +QHIz0VYMnckJFJzzin11LQ2lZ8YfayXF4LijnCj+a7rBQ0ib42XkU1XXj4QXPJi CIF9mH2x70wFigT8HYvsStHVWkXrijRT6Y7Q/crYt4qf5Ytks5ImCs6o+aTfwNs= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=/4JuMixTqVJ//lqhxSCDBmoQbGg=; b=KG4L2JlJWrS cQ9an+KmQ4XVoiNzlel6G6XLGaIsGjbTQapquv5wJxfyUKfNVOVocmuKcjVN3Gpq 1l2AgC8Vv5IYySQOB54VUpGgdXu4v0FvU/KAZ1Ce1hCqY7KfBn9jChblL+Vtugha rrSLlfzGreOwQali+84bbpyOuaquc6t0= Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTPSA id B34A8584057 for ; Tue, 8 May 2012 15:48:09 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so8730884pbc.31 for ; Tue, 08 May 2012 15:48:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.204.2 with SMTP id ku2mr2373975pbc.55.1336517289336; Tue, 08 May 2012 15:48:09 -0700 (PDT) Received: by 10.68.5.99 with HTTP; Tue, 8 May 2012 15:48:09 -0700 (PDT) In-Reply-To: <4FA99E4E.5050008@mit.edu> References: <4FA99E4E.5050008@mit.edu> Date: Tue, 8 May 2012 17:48:09 -0500 Message-ID: From: Nico Williams To: Greg Hudson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: kitten@ietf.org Subject: Re: [kitten] Proposal: extension to GSS_Acquire/Add_cred_from() X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 22:48:11 -0000 On Tue, May 8, 2012 at 5:29 PM, Greg Hudson wrote: > On 05/08/2012 05:28 PM, Nico Williams wrote: >> [...] > > I think this is far too much complexity for the benefit. If we ever want a GSS_Get_current_cred_store() we'll kick ourselves for not having made cred_store opaque, as then we'll have all the same memory management issues that we've had with gss_buffer_t. So I definitely think we should at least address that. > I also think cred store parameters are probably not a good basis for > making initial credential acquisition work through GSS. =C2=A0Conflating > "where credentials are stored" with "secrets you need to acquire > credentials" seems like a bad idea. =C2=A0So, I disagree that we want to = add > complexity in order to leave the door open to this. It's already done in this API. I'd be OK with separating the two types of things, but that will complicate things for Simo's proxy project. Nico -- From Hannes.Tschofenig@gmx.net Wed May 9 10:50:16 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AC6E21F8551 for ; Wed, 9 May 2012 10:50:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 XFQEKcdhj8Bx for ; Wed, 9 May 2012 10:50:16 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id A992B21F8554 for ; Wed, 9 May 2012 10:50:15 -0700 (PDT) Received: (qmail invoked by alias); 09 May 2012 17:50:14 -0000 Received: from unknown (EHLO [107.17.145.89]) [216.141.82.2] by mail.gmx.net (mp072) with SMTP; 09 May 2012 19:50:14 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+2puAUrZK2ciLgH88kpmnmoURgadUYnZ9HuQ8CRb kZ5OBFlFbXiZE9 From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 9 May 2012 20:50:10 +0300 Message-Id: <40FC97F0-B72C-47F4-8206-590BA365997A@gmx.net> To: "oauth@ietf.org WG" , kitten@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Subject: [kitten] OAuth Discovery and what the relying party needs to know X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 17:50:16 -0000 Hi guys,=20 at the last IIW we had a discussion about SASL-OAuth and what the SASL = server needs to know for discovery.=20 The discovery discussions around WebFinger go in the same directions.=20 So, I have been wondering whether we have made an informed decision = about how the discovery procedure is actually supposed to look like.=20 In my view, the relying party (the client) only needs to know who the = identity provider (the AS/RS) is.=20 Any other views?=20 Ciao Hannes PS: Please let me know if I should provide more background about the = issue.=20 From ve7jtb@ve7jtb.com Wed May 9 11:21:22 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79D6011E80CB for ; Wed, 9 May 2012 11:21:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.529 X-Spam-Level: X-Spam-Status: No, score=-3.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, 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 6p+s9pbuq9P4 for ; Wed, 9 May 2012 11:21:22 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id C424D11E80AB for ; Wed, 9 May 2012 11:21:21 -0700 (PDT) Received: by yhq56 with SMTP id 56so711132yhq.31 for ; Wed, 09 May 2012 11:21:18 -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=JoLsDoJJFoJzaHfJ1KxlJ812kfM9JSFQ71jNKkf73TU=; b=J9aGLZ9Ho9FL8ZOBdDSEXwzB+jPKrAfyF/cptBKejtKBdq8v+WNBSLLTw03E6IGARr LX5seP/lXo+jw8+CLkaIt1N7chDXdrxHa29W8g6W+jJlZjf/ChSEoQ03+y7B9SYOHyV0 HmpiLGD76uI1mN88jVQjR7FxlJu/frzsAui67QR+x350pZTmZilEK6VsaPqMzGWNkPqN eUKGhL4agtcrzAXjz5+wzMc4BY7YW/MRYPV6295D3SmnJo5kE1bMtOaR9AgQpAgxAuVU eYkJmzbhoBnzTWISaTlnzB+HZCHC28Xv7IlrDlyJWX3GapOeAKBoLrP+zxIsUT8sV7gh v+dw== Received: by 10.236.145.168 with SMTP id p28mr1546482yhj.4.1336587678229; Wed, 09 May 2012 11:21:18 -0700 (PDT) Received: from [192.168.1.213] (190-20-20-74.baf.movistar.cl. [190.20.20.74]) by mx.google.com with ESMTPS id j34sm5201134ani.14.2012.05.09.11.21.12 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 09 May 2012 11:21:17 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/signed; boundary="Apple-Mail=_F8802354-95B0-461B-B1AC-507FA7B746DB"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <40FC97F0-B72C-47F4-8206-590BA365997A@gmx.net> Date: Wed, 9 May 2012 14:20:56 -0400 Message-Id: <5ECED997-49B8-4550-B79A-CF121FCD1AF9@ve7jtb.com> References: <40FC97F0-B72C-47F4-8206-590BA365997A@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQnhVoKwVJ5MJ2AgSHKVlboBaQpusrrs2wn4VmIiMOtvbRu7AD8JY7r5LXtPqG/4EX125ZRS Cc: kitten@ietf.org, "oauth@ietf.org WG" Subject: Re: [kitten] [OAUTH-WG] OAuth Discovery and what the relying party needs to know X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 18:21:22 -0000 --Apple-Mail=_F8802354-95B0-461B-B1AC-507FA7B746DB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii For openID Connect we are using the identifier to discover the AS. We = refer to that as an issuer, and perform a second discovery step to get = the configuration (Auth endpoint, token endpoint, user_info endpoint and = other config) for that issuer. SWD/WF may be used for other things by other protocols, but our use is = quite simple. I think that is probably the same thing for SASL, but others may think = differently. John B. =20 On 2012-05-09, at 1:50 PM, Hannes Tschofenig wrote: > Hi guys,=20 >=20 > at the last IIW we had a discussion about SASL-OAuth and what the SASL = server needs to know for discovery.=20 > The discovery discussions around WebFinger go in the same directions.=20= >=20 > So, I have been wondering whether we have made an informed decision = about how the discovery procedure is actually supposed to look like.=20 >=20 > In my view, the relying party (the client) only needs to know who the = identity provider (the AS/RS) is.=20 >=20 > Any other views?=20 >=20 > Ciao > Hannes >=20 > PS: Please let me know if I should provide more background about the = issue.=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_F8802354-95B0-461B-B1AC-507FA7B746DB Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDUw OTE4MjA1NlowIwYJKoZIhvcNAQkEMRYEFHQk5PGESxUxN1nBz9udSv2anC+SMIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB AK+yZru3unXEFGLo2H7hvLXZvCzz6aJDMGfBbhPRZRucouqEyqfWXSxMuqfJV7NCdusW4I8vAh+d yv3I2meoZMy6dBibbk0tyz27lCvX5OHMSmSQ2JFoq0a+qPrkQtiKVsS2n5cOSAWUMdfb0PqZdaCJ H4+aLbndTNUW3884SsgqG8jI6l4R3s2YOUWepNNoY0hon98ATFyfcb+lvx8ORl+COkIwD2JeWVX/ G6HPZmGeCCiN2KcbI3L9Rc/SAZV2RjQfK0wvvzZrP97OyH2jeh6t1ITao0YrNIkb3jON0lE5Ii+1 3jokGZH9S3x6200O+b0kTbvNwPUcUTUajMj7I/EAAAAAAAA= --Apple-Mail=_F8802354-95B0-461B-B1AC-507FA7B746DB-- From wmills@yahoo-inc.com Wed May 9 11:41:23 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0161D21F8566 for ; Wed, 9 May 2012 11:41:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.985 X-Spam-Level: X-Spam-Status: No, score=-15.985 tagged_above=-999 required=5 tests=[AWL=-0.987, BAYES_50=0.001, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] 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 dGd0zo7c6-n1 for ; Wed, 9 May 2012 11:41:22 -0700 (PDT) Received: from nm14.bullet.mail.sp2.yahoo.com (nm14.bullet.mail.sp2.yahoo.com [98.139.91.84]) by ietfa.amsl.com (Postfix) with SMTP id 63F3321F854B for ; Wed, 9 May 2012 11:41:22 -0700 (PDT) Received: from [98.139.91.61] by nm14.bullet.mail.sp2.yahoo.com with NNFMP; 09 May 2012 18:41:18 -0000 Received: from [98.139.91.5] by tm1.bullet.mail.sp2.yahoo.com with NNFMP; 09 May 2012 18:41:18 -0000 Received: from [127.0.0.1] by omp1005.mail.sp2.yahoo.com with NNFMP; 09 May 2012 18:41:18 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 473124.96269.bm@omp1005.mail.sp2.yahoo.com Received: (qmail 87179 invoked by uid 60001); 9 May 2012 18:41:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1336588877; bh=SqwZoywUPvYMlFeyn2w0KnrDevT3HRFQXUz4pW0PvCE=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=MI3XoxzvjnSn5C96QVEIJkS1U/IWqJxaPer4UVfNzz/U8Fa3VbuDSgJyb7tlczNCRwv95twznhWO4OgBvCTr2JBPanyR8xGP/mYpAT6//WfQedGBRmfDBgNJEbEwgWIaLYUdNz2wNGm7/t0WTHRKGKK/ak0aqW6x6ESVp/7BIEg= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=UcKM6ul36P8kt8/SilaKiZn8D85FLQX3AoHCx/BYMkJYbLwBuD1MrCRiMsg87WCeRaNYYKtkuQB1KjZoTtFKjWrOMCtelIJIlyKC/jd1Cwpz810nIw4OIso6xuLx5ZPXYBCjMWcEIu1kSuRFh7hIwGX5iBLNRZSvoefxtMzpISQ=; X-YMail-OSG: .QPJDzoVM1mdHXLeBU9AZX9Hs8ot96CwPPgEhAV_1as2xtd tHqM81qp.92LjKjWomOelETffwfZ.5N5ECZnry4fWGRFcW0pHMDw_zOimnmS 2SWcDl2X9_dWmvobsjJuzCZPhuGxv9_npDWbQWntEFhj0sDjEUMs.iKxUeCz 88WA_rORzTof9iDZe7TLL77i4Awg21j.Q0ctWlI99smeUf4JB6iaWphSMoCQ tYL5FQ5P_WyaHQqacXTrrxBNByl9RRgRlWuwt.27YcSrd8mOkOzu7t8AbJO6 Lu2cfydYZ.RPE47gNZFUH5Df2S.VbF8KCUeqt1h0wV.2udlF1QWcM..0WkDx pQZ9f4LC_Uk5gyUfC7yOo85jT8a7E4ocQi0jo0pvW6MF8tEawaoc1VDIDjne FNxVodiu5xQh.3UaK1fZCXR7JZbFBsCjtMOxhQjdq5xlgLpl3n_U- Received: from [209.131.62.115] by web31810.mail.mud.yahoo.com via HTTP; Wed, 09 May 2012 11:41:16 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.118.349524 References: <40FC97F0-B72C-47F4-8206-590BA365997A@gmx.net> Message-ID: <1336588876.87117.YahooMailNeo@web31810.mail.mud.yahoo.com> Date: Wed, 9 May 2012 11:41:16 -0700 (PDT) From: William Mills To: Hannes Tschofenig , "oauth@ietf.org WG" , "kitten@ietf.org" In-Reply-To: <40FC97F0-B72C-47F4-8206-590BA365997A@gmx.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1935884094-497063341-1336588876=:87117" Subject: Re: [kitten] OAuth Discovery and what the relying party needs to know X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 18:41:23 -0000 --1935884094-497063341-1336588876=:87117 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable This is going to get fun as we deal with various types of identities.=A0 Th= ere was a suggestion at IIW that the workable way to do this for e-mail is = via MX records.=A0 What do we do for other types of IDs?=0A=0A=0A=0A=0A>___= _____________________________=0A> From: Hannes Tschofenig =0A>To: "oauth@ietf.org WG" ; kitten@ietf.org =0A= >Sent: Wednesday, May 9, 2012 10:50 AM=0A>Subject: [kitten] OAuth Discovery= and what the relying party needs to know=0A> =0A>Hi guys, =0A>=0A>at the l= ast IIW we had a discussion about SASL-OAuth and what the SASL server needs= to know for discovery. =0A>The discovery discussions around WebFinger go i= n the same directions. =0A>=0A>So, I have been wondering whether we have ma= de an informed decision about how the discovery procedure is actually suppo= sed to look like. =0A>=0A>In my view, the relying party (the client) only n= eeds to know who the identity provider (the AS/RS) is. =0A>=0A>Any other vi= ews? =0A>=0A>Ciao=0A>Hannes=0A>=0A>PS: Please let me know if I should provi= de more background about the issue. =0A>=0A>_______________________________= ________________=0A>Kitten mailing list=0A>Kitten@ietf.org=0A>https://www.i= etf.org/mailman/listinfo/kitten=0A>=0A>=0A> --1935884094-497063341-1336588876=:87117 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
This is going to get fun as we deal with various types of identities.&nbs= p; There was a suggestion at IIW that the workable way to do this for e-mai= l is via MX records.  What do we do for other types of IDs?
=

From: Hannes T= schofenig <Hannes.Tschofenig@gmx.net>
To: "oauth@ietf.org WG" <oauth@ietf.org>; kitte= n@ietf.org
Sent: Wednesday, May= 9, 2012 10:50 AM
Subject:= [kitten] OAuth Discovery and what the relying party needs to know
=

=0AHi guys,

at the last IIW we had a discussion = about SASL-OAuth and what the SASL server needs to know for discovery.
= The discovery discussions around WebFinger go in the same directions.
<= br>So, I have been wondering whether we have made an informed decision abou= t how the discovery procedure is actually supposed to look like.

In= my view, the relying party (the client) only needs to know who the identit= y provider (the AS/RS) is.

Any other views?

Ciao
Hannes<= br>
PS: Please let me know if I should provide more background about the= issue.

_______________________________________________
Kitten m= ailing list
Kitten@ietf.org
https://www.ietf.org/mailman/listinfo/kitt= en


--1935884094-497063341-1336588876=:87117-- From Hannes.Tschofenig@gmx.net Wed May 9 11:42:35 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F43921F8566 for ; Wed, 9 May 2012 11:42:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 tbgP-YpQH7du for ; Wed, 9 May 2012 11:42:34 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id EE15621F8567 for ; Wed, 9 May 2012 11:42:33 -0700 (PDT) Received: (qmail invoked by alias); 09 May 2012 18:42:32 -0000 Received: from unknown (EHLO [107.17.145.89]) [216.141.82.2] by mail.gmx.net (mp071) with SMTP; 09 May 2012 20:42:32 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/5S7UhV7X5d3u76oQ7DqX5wh2WCGv+W91/wPw0PF thWZibus4A8UJ1 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <5ECED997-49B8-4550-B79A-CF121FCD1AF9@ve7jtb.com> Date: Wed, 9 May 2012 21:42:27 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <9F541ABD-23C0-4592-BC8C-7B7E7CC620CB@gmx.net> References: <40FC97F0-B72C-47F4-8206-590BA365997A@gmx.net> <5ECED997-49B8-4550-B79A-CF121FCD1AF9@ve7jtb.com> To: John Bradley X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: kitten@ietf.org, "oauth@ietf.org WG" Subject: Re: [kitten] [OAUTH-WG] OAuth Discovery and what the relying party needs to know X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 18:42:35 -0000 Hi John,=20 does the "identifier" contain of a domain part AND a username part or = only the domain part?=20 That's the crucial question here.=20 Ciao Hannes On May 9, 2012, at 9:20 PM, John Bradley wrote: > For openID Connect we are using the identifier to discover the AS. = We refer to that as an issuer, and perform a second discovery step to = get the configuration (Auth endpoint, token endpoint, user_info endpoint = and other config) for that issuer. >=20 > SWD/WF may be used for other things by other protocols, but our use is = quite simple. >=20 > I think that is probably the same thing for SASL, but others may = think differently. >=20 > John B. >=20 >=20 > On 2012-05-09, at 1:50 PM, Hannes Tschofenig wrote: >=20 >> Hi guys,=20 >>=20 >> at the last IIW we had a discussion about SASL-OAuth and what the = SASL server needs to know for discovery.=20 >> The discovery discussions around WebFinger go in the same directions.=20= >>=20 >> So, I have been wondering whether we have made an informed decision = about how the discovery procedure is actually supposed to look like.=20 >>=20 >> In my view, the relying party (the client) only needs to know who the = identity provider (the AS/RS) is.=20 >>=20 >> Any other views?=20 >>=20 >> Ciao >> Hannes >>=20 >> PS: Please let me know if I should provide more background about the = issue.=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 From kwiereng@cisco.com Wed May 9 11:41:32 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94BFE21F856A; Wed, 9 May 2012 11:41:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.136 X-Spam-Level: X-Spam-Status: No, score=-7.136 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] 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 hiKokBXLW6WJ; Wed, 9 May 2012 11:41:31 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id F32C821F8569; Wed, 9 May 2012 11:41:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=kwiereng@cisco.com; l=1705; q=dns/txt; s=iport; t=1336588891; x=1337798491; h=references:in-reply-to:mime-version:message-id: content-transfer-encoding:cc:from:subject:date:to; bh=wTL5wmnepv5Jj1iCIVNXdALfud7ZJVzT9ESEyM1lz2k=; b=DQDJbH3tMbACifReAn4QdNXkqB0PrEJjBUk0e6RuczJc7niBJ3xzkJmO gHUFOKPbKk/hlvtzr2SBeV/1JAmmyPTuxKqQSB1Mf1Uw60tEhlv0wJgNY cGf5zOgq7l9/qmmEDQrFlQs0aRc/AHDmPEg3CIsCRWwHwTBvl6z09aIUo Y=; X-IronPort-AV: E=Sophos;i="4.75,559,1330905600"; d="scan'208";a="137478483" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 09 May 2012 18:41:29 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q49IfT4d020057; Wed, 9 May 2012 18:41:29 GMT Received: from xmb-ams-101.cisco.com ([144.254.74.76]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 9 May 2012 20:41:29 +0200 Received: from 144.254.74.76 ([144.254.74.76]) by XMB-AMS-101.cisco.com ([144.254.74.76]) with Microsoft Exchange Server HTTP-DAV ; Wed, 9 May 2012 18:41:28 +0000 References: <40FC97F0-B72C-47F4-8206-590BA365997A@gmx.net> <5ECED997-49B8-4550-B79A-CF121FCD1AF9@ve7jtb.com> In-Reply-To: <5ECED997-49B8-4550-B79A-CF121FCD1AF9@ve7jtb.com> MIME-Version: 1.0 (1.0) Content-Type: text/plain; charset="us-ascii" Thread-Topic: [OAUTH-WG] OAuth Discovery and what the relying party needs toknow Thread-Index: Ac0uE1hl6IDOqd2hSsqaJMGxE6vWAQ== Message-ID: <96CEC5DF-F64F-4821-ACA6-69A53BF0720A@cisco.com> Content-Transfer-Encoding: quoted-printable From: "Klaas Wierenga (kwiereng)" Date: Wed, 9 May 2012 20:41:26 +0200 To: "John Bradley" X-OriginalArrivalTime: 09 May 2012 18:41:29.0386 (UTC) FILETIME=[58DEB8A0:01CD2E13] X-Mailman-Approved-At: Wed, 09 May 2012 11:43:00 -0700 Cc: kitten@ietf.org, oauth@ietf.org Subject: Re: [kitten] [OAUTH-WG] OAuth Discovery and what the relying party needs toknow X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 18:41:32 -0000 For SASL-SAML I do something similar, I use the term 'domain', but again thi= s used to lookup the associated SAML IdP Klaas Sent from my iPhone On 9 mei 2012, at 20:21, "John Bradley" wrote: > For openID Connect we are using the identifier to discover the AS. We re= fer to that as an issuer, and perform a second discovery step to get the co= nfiguration (Auth endpoint, token endpoint, user_info endpoint and other con= fig) for that issuer. >=20 > SWD/WF may be used for other things by other protocols, but our use is qui= te simple. >=20 > I think that is probably the same thing for SASL, but others may think di= fferently. >=20 > John B. >=20 >=20 > On 2012-05-09, at 1:50 PM, Hannes Tschofenig wrote: >=20 >> Hi guys,=20 >>=20 >> at the last IIW we had a discussion about SASL-OAuth and what the SASL se= rver needs to know for discovery.=20 >> The discovery discussions around WebFinger go in the same directions.=20 >>=20 >> So, I have been wondering whether we have made an informed decision about= how the discovery procedure is actually supposed to look like.=20 >>=20 >> In my view, the relying party (the client) only needs to know who the ide= ntity provider (the AS/RS) is.=20 >>=20 >> Any other views?=20 >>=20 >> Ciao >> Hannes >>=20 >> PS: Please let me know if I should provide more background about the issu= e.=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From ve7jtb@ve7jtb.com Wed May 9 12:31:51 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 675CA11E80CE for ; Wed, 9 May 2012 12:31:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.534 X-Spam-Level: X-Spam-Status: No, score=-3.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, 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 NlVFXNyV118b for ; Wed, 9 May 2012 12:31:50 -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 BB6BB21F8466 for ; Wed, 9 May 2012 12:31:50 -0700 (PDT) Received: by yenq13 with SMTP id q13so790882yen.31 for ; Wed, 09 May 2012 12:31:50 -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=JO3qCiDpKU0AAW9OW6GGq1djWU7Brie/HdVRuCWQ/9I=; b=Xh24Mx/yC6kpp7tc8Q3YzJ1jixlBNI0TpN4uF2uGxSQknVlOMtiJ5TF2bk6ckc3hun hr3oExFk5PLuv3D9zK9/eODzqaGYQWK7onaoY5THv91SUrBkCR7zNyZfFyt5e+L9Rkm0 vdOD+U3Us07+9fZzcTWm5199bSqZhDZhyAkMKchixR8OCRCHHhh8xVy4VZd3cZ20mLVt p7+K3ePRaw8UI8CI233CI6G6nL02j4fR655+J02ZLSGQgKsFgFIgOcdVqZIQs529diTO 4kShQmF5UOhqhe81+VKLwwZ5v8fkt2cV1Ax6rmP3HfyeRMm5kWEKA4ibrGX9PpWtm07c IuHQ== Received: by 10.236.184.134 with SMTP id s6mr1528721yhm.122.1336591910134; Wed, 09 May 2012 12:31:50 -0700 (PDT) Received: from [192.168.1.213] (190-20-20-74.baf.movistar.cl. [190.20.20.74]) by mx.google.com with ESMTPS id y28sm15976381yhi.16.2012.05.09.12.31.43 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 09 May 2012 12:31:48 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/signed; boundary="Apple-Mail=_7D41B96E-1F64-4D9D-A5F2-B101C1755077"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <9F541ABD-23C0-4592-BC8C-7B7E7CC620CB@gmx.net> Date: Wed, 9 May 2012 15:31:31 -0400 Message-Id: <81091A66-03C3-4085-A840-BEC1BBF48161@ve7jtb.com> References: <40FC97F0-B72C-47F4-8206-590BA365997A@gmx.net> <5ECED997-49B8-4550-B79A-CF121FCD1AF9@ve7jtb.com> <9F541ABD-23C0-4592-BC8C-7B7E7CC620CB@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQkpiE92soMCk11BEShZuVvKGKmakuBglnIxPQ7i2sPxFQfbEorAcqHnqof/4sywRseKcZJ3 Cc: kitten@ietf.org, "oauth@ietf.org WG" Subject: Re: [kitten] [OAUTH-WG] OAuth Discovery and what the relying party needs to know X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 19:31:51 -0000 --Apple-Mail=_7D41B96E-1F64-4D9D-A5F2-B101C1755077 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The lookup is based on the identifier provided by the user. It can have = a user portion in the format of a URI https://john@example.com , = https://example.com/john or anything else where you can extract the = domain. The user portion is necessary to allow for per user IdP delegation. = Otherwise only one IdP per host could be supported. John B. On 2012-05-09, at 2:42 PM, Hannes Tschofenig wrote: > Hi John,=20 >=20 > does the "identifier" contain of a domain part AND a username part or = only the domain part?=20 > That's the crucial question here.=20 >=20 > Ciao > Hannes >=20 > On May 9, 2012, at 9:20 PM, John Bradley wrote: >=20 >> For openID Connect we are using the identifier to discover the AS. = We refer to that as an issuer, and perform a second discovery step to = get the configuration (Auth endpoint, token endpoint, user_info endpoint = and other config) for that issuer. >>=20 >> SWD/WF may be used for other things by other protocols, but our use = is quite simple. >>=20 >> I think that is probably the same thing for SASL, but others may = think differently. >>=20 >> John B. >>=20 >>=20 >> On 2012-05-09, at 1:50 PM, Hannes Tschofenig wrote: >>=20 >>> Hi guys,=20 >>>=20 >>> at the last IIW we had a discussion about SASL-OAuth and what the = SASL server needs to know for discovery.=20 >>> The discovery discussions around WebFinger go in the same = directions.=20 >>>=20 >>> So, I have been wondering whether we have made an informed decision = about how the discovery procedure is actually supposed to look like.=20 >>>=20 >>> In my view, the relying party (the client) only needs to know who = the identity provider (the AS/RS) is.=20 >>>=20 >>> Any other views?=20 >>>=20 >>> Ciao >>> Hannes >>>=20 >>> PS: Please let me know if I should provide more background about the = issue.=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >=20 --Apple-Mail=_7D41B96E-1F64-4D9D-A5F2-B101C1755077 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDUw OTE5MzEzMlowIwYJKoZIhvcNAQkEMRYEFEeTUieEr17Yy1aOczarGcHMsB73MIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB AKLr10daaNMgIKnoTzrYi/OgZ+mY0964lBQFqCeGa7JwtOU0HvMkxD8XiXyZuj6Lht2WENm7Mm5T gC4IN7JuKyK1YpPCWBqo+EcVIMMZNV/WSjowQ/TFi2kefdChlgs+RPBauBIIgXtxyNhWCLOwHS3y Ez/iYTUnn3Y2/EqWhkpE7sua6qRJWuXM8xgnyC9bwJfrW0MEznYLl3GrYFI8adTW+WjVuCbKr+wJ 4akoMtKnL7gibaobSIcUZ/nV1BlQnoI0v8ZI/33FFM34t+8JwVqMIo83102pVsx5ic2NBmRsuicl u6PXQTn8E4ZCMo7XLJJOrcoqHzWdfHclq+WIb14AAAAAAAA= --Apple-Mail=_7D41B96E-1F64-4D9D-A5F2-B101C1755077-- From kwiereng@cisco.com Wed May 9 22:43:44 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A1C321F8516; Wed, 9 May 2012 22:43:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.136 X-Spam-Level: X-Spam-Status: No, score=-7.136 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] 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 LLkXAqzinH9H; Wed, 9 May 2012 22:43:43 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 5734721F850B; Wed, 9 May 2012 22:43:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=kwiereng@cisco.com; l=3000; q=dns/txt; s=iport; t=1336628623; x=1337838223; h=subject:references:content-transfer-encoding:from: in-reply-to:message-id:date:to:cc:mime-version; bh=C0qNzd4rOIfUWlcCImjIJM4Hx5K/KuEKMYPxiz7LTNw=; b=Ex35xoLPTGLW69PwtJ2vKJfUYRSSNuGh9vkXcTgIcKOabtHIW4ZUiTJV WkTMYs7/ACPdH7p9zLv1hXvSKVeX7p7M0i694+t1OKk2a1qu3FOVy4G6R iT5LBf+XaJtGRIcRFvDbcxIScn3v02ZDnbQkfdG6xVzPJrEmSPxtGS1sE k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmMHADlVq0+Q/khL/2dsb2JhbAA7CbEcAQEGghUCgQeCDAEBAQMBAQEBDwEnNAsFCwIBCA4KLicwAQEEEyKHZwULmwSgG4sNEIU2YwSVfYERjUYngUKCaw X-IronPort-AV: E=Sophos;i="4.75,561,1330905600"; d="scan'208";a="137507378" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 10 May 2012 05:43:20 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q4A5hKxF021503; Thu, 10 May 2012 05:43:20 GMT Received: from xmb-ams-101.cisco.com ([144.254.74.76]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 10 May 2012 07:43:20 +0200 Received: from 144.254.74.76 ([144.254.74.76]) by XMB-AMS-101.cisco.com ([144.254.74.76]) with Microsoft Exchange Server HTTP-DAV ; Thu, 10 May 2012 05:43:19 +0000 References: <40FC97F0-B72C-47F4-8206-590BA365997A@gmx.net> <5ECED997-49B8-4550-B79A-CF121FCD1AF9@ve7jtb.com> <9F541ABD-23C0-4592-BC8C-7B7E7CC620CB@gmx.net> <81091A66-03C3-4085-A840-BEC1BBF48161@ve7jtb.com> Content-Transfer-Encoding: quoted-printable From: "Klaas Wierenga (kwiereng)" Content-Type: text/plain; charset="us-ascii" Thread-Topic: [kitten] [OAUTH-WG] OAuth Discovery and what the relying partyneeds to know Thread-Index: Ac0ub84LsNJtIDyjT8mLTat+qsjtww== In-Reply-To: <81091A66-03C3-4085-A840-BEC1BBF48161@ve7jtb.com> Message-ID: Date: Thu, 10 May 2012 07:43:20 +0200 To: "John Bradley" MIME-Version: 1.0 (1.0) X-OriginalArrivalTime: 10 May 2012 05:43:20.0736 (UTC) FILETIME=[CEADDA00:01CD2E6F] X-Mailman-Approved-At: Wed, 09 May 2012 22:52:00 -0700 Cc: kitten@ietf.org, oauth@ietf.org Subject: Re: [kitten] [OAUTH-WG] OAuth Discovery and what the relying partyneeds to know X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 05:43:44 -0000 Hmmm, I see your point but I think that from a privacy PoV revealing the use= rname to the RP is not good practice, especially not prior to trust being es= tablished between RP and IdP. If the IdP wants to send the assertion in the a= uthentication statement that is another matter. But you don't want rogue RPs= harvesting user names. So instead i have assumed that the domain could be m= ore specific if needed, i.e. for 99% of the cases example.com would suffice b= ut for the corner cases I imagine using idp1.example.com and idp2.example.co= m. But I understand that in an oauth scenario that may be less pretty. Klaas Sent from my iPad On 9 mei 2012, at 21:31, "John Bradley" wrote: > The lookup is based on the identifier provided by the user. It can have a= user portion in the format of a URI https://john@example.com , https://exam= ple.com/john or anything else where you can extract the domain. >=20 > The user portion is necessary to allow for per user IdP delegation. Othe= rwise only one IdP per host could be supported. >=20 > John B. >=20 >=20 > On 2012-05-09, at 2:42 PM, Hannes Tschofenig wrote: >=20 >> Hi John,=20 >>=20 >> does the "identifier" contain of a domain part AND a username part or onl= y the domain part?=20 >> That's the crucial question here.=20 >>=20 >> Ciao >> Hannes >>=20 >> On May 9, 2012, at 9:20 PM, John Bradley wrote: >>=20 >>> For openID Connect we are using the identifier to discover the AS. We r= efer to that as an issuer, and perform a second discovery step to get the c= onfiguration (Auth endpoint, token endpoint, user_info endpoint and other co= nfig) for that issuer. >>>=20 >>> SWD/WF may be used for other things by other protocols, but our use is q= uite simple. >>>=20 >>> I think that is probably the same thing for SASL, but others may think d= ifferently. >>>=20 >>> John B. >>>=20 >>>=20 >>> On 2012-05-09, at 1:50 PM, Hannes Tschofenig wrote: >>>=20 >>>> Hi guys,=20 >>>>=20 >>>> at the last IIW we had a discussion about SASL-OAuth and what the SASL s= erver needs to know for discovery.=20 >>>> The discovery discussions around WebFinger go in the same directions.=20= >>>>=20 >>>> So, I have been wondering whether we have made an informed decision abo= ut how the discovery procedure is actually supposed to look like.=20 >>>>=20 >>>> In my view, the relying party (the client) only needs to know who the i= dentity provider (the AS/RS) is.=20 >>>>=20 >>>> Any other views?=20 >>>>=20 >>>> Ciao >>>> Hannes >>>>=20 >>>> PS: Please let me know if I should provide more background about the is= sue.=20 >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>=20 >=20 > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten From ve7jtb@ve7jtb.com Thu May 10 07:58:48 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 969E921F86C2 for ; Thu, 10 May 2012 07:58:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.537 X-Spam-Level: X-Spam-Status: No, score=-3.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, 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 tjRWhrPmJ6-H for ; Thu, 10 May 2012 07:58:48 -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 C4F8C21F86C7 for ; Thu, 10 May 2012 07:58:47 -0700 (PDT) Received: by yenq13 with SMTP id q13so1907729yen.31 for ; Thu, 10 May 2012 07:58:46 -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=0NppPTQsCGyoj7OkhlfDUzDgDhZp9vF0XOem4dQMtM4=; b=kzRxQLTevOCpCdmLoZfud0l8vPks3klJGcvwUIvw+GROLK7D12OQAauz9z5IFtW7gf 0bUOy/bk8GwwGcm3bM2DwmIC8TVTJyjFEyjrMa4CesrIuGTWW2mIxjTsM/R9f/Cf8ZC8 rXU2xPk9w/DCWEiLcC3KKxUJNS8O0dz/WkcmdTYzka1NpoKfWG45kNw5WQPPSFpM4i2F XXfXxfC45v21yRvnEqrPb3iw5H9LhfuFiAHqmrlNVVDBEFCpkaOLvmtOvkippgaZN1Ce k8ZS1FHXOMsnR+vmeeKI78DaGyJZQ2stvTb6kAsIxycFPaWR6RnR5EWC14PH6m+wf9wu 6G7A== Received: by 10.236.116.169 with SMTP id g29mr5490430yhh.54.1336661925182; Thu, 10 May 2012 07:58:45 -0700 (PDT) Received: from [192.168.1.213] (190-20-35-188.baf.movistar.cl. [190.20.35.188]) by mx.google.com with ESMTPS id j34sm9634812ani.14.2012.05.10.07.58.42 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 10 May 2012 07:58:44 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/signed; boundary="Apple-Mail=_CC1131A4-E711-4E86-B315-FDB14AA02927"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: Date: Thu, 10 May 2012 10:58:35 -0400 Message-Id: <6E2A5AF6-F4D8-4FCA-A45F-7AE5032A82BE@ve7jtb.com> References: <40FC97F0-B72C-47F4-8206-590BA365997A@gmx.net> <5ECED997-49B8-4550-B79A-CF121FCD1AF9@ve7jtb.com> <9F541ABD-23C0-4592-BC8C-7B7E7CC620CB@gmx.net> <81091A66-03C3-4085-A840-BEC1BBF48161@ve7jtb.com> To: "Klaas Wierenga (kwiereng)" X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQlOihzGh8vIccMvKb8Pfr5mk3l7XFOb9D7+xTdmeOax3mTLYHzra+QCGuyoyB5l6MMObAtd Cc: kitten@ietf.org, oauth@ietf.org Subject: Re: [kitten] [OAUTH-WG] OAuth Discovery and what the relying partyneeds to know X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 14:58:48 -0000 --Apple-Mail=_CC1131A4-E711-4E86-B315-FDB14AA02927 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii openID Connect dosen't require a user portion of the identifier to be = discovered and supports a opaque or pseudonymous user_id. =20 email is an optional attribute that can be returned by user consent. OpenID 2.0 actively discouraged using email addresses for privacy = reasons. Teaching people to enter there email addresses into unknown = sites was seen as a bad thing by many. WF was started partially as an alternative discovery mechanism for = openID to allow people to enter email addresses to discover there IdP, = given a belief that users could only be asked to enter email and=20 NASCAR UI was not scalable. openID is attempting to separately address the NASCAR problem with it's = Account Chooser project to allow the user to configure and control their = selection of IdP without entering info directly into the RP. For WF/SWD the decision is to enforce discovery by host only or support = a user component so that a email or other service provider could allow = per user choice. I do happen to personally agree that teaching users to give up there = email to random websites is not a good idea, however not allowing a user = component in discovery won't stop RP from asking and removes otherwise = useful functionality and choice fro the user. John B. On 2012-05-10, at 1:43 AM, Klaas Wierenga (kwiereng) wrote: >=20 > Hmmm, I see your point but I think that from a privacy PoV revealing = the username to the RP is not good practice, especially not prior to = trust being established between RP and IdP. If the IdP wants to send the = assertion in the authentication statement that is another matter. But = you don't want rogue RPs harvesting user names. So instead i have = assumed that the domain could be more specific if needed, i.e. for 99% = of the cases example.com would suffice but for the corner cases I = imagine using idp1.example.com and idp2.example.com. But I understand = that in an oauth scenario that may be less pretty. >=20 > Klaas >=20 > Sent from my iPad >=20 > On 9 mei 2012, at 21:31, "John Bradley" wrote: >=20 >> The lookup is based on the identifier provided by the user. It can = have a user portion in the format of a URI https://john@example.com , = https://example.com/john or anything else where you can extract the = domain. >>=20 >> The user portion is necessary to allow for per user IdP delegation. = Otherwise only one IdP per host could be supported. >>=20 >> John B. >>=20 >>=20 >> On 2012-05-09, at 2:42 PM, Hannes Tschofenig wrote: >>=20 >>> Hi John,=20 >>>=20 >>> does the "identifier" contain of a domain part AND a username part = or only the domain part?=20 >>> That's the crucial question here.=20 >>>=20 >>> Ciao >>> Hannes >>>=20 >>> On May 9, 2012, at 9:20 PM, John Bradley wrote: >>>=20 >>>> For openID Connect we are using the identifier to discover the AS. = We refer to that as an issuer, and perform a second discovery step to = get the configuration (Auth endpoint, token endpoint, user_info endpoint = and other config) for that issuer. >>>>=20 >>>> SWD/WF may be used for other things by other protocols, but our use = is quite simple. >>>>=20 >>>> I think that is probably the same thing for SASL, but others may = think differently. >>>>=20 >>>> John B. >>>>=20 >>>>=20 >>>> On 2012-05-09, at 1:50 PM, Hannes Tschofenig wrote: >>>>=20 >>>>> Hi guys,=20 >>>>>=20 >>>>> at the last IIW we had a discussion about SASL-OAuth and what the = SASL server needs to know for discovery.=20 >>>>> The discovery discussions around WebFinger go in the same = directions.=20 >>>>>=20 >>>>> So, I have been wondering whether we have made an informed = decision about how the discovery procedure is actually supposed to look = like.=20 >>>>>=20 >>>>> In my view, the relying party (the client) only needs to know who = the identity provider (the AS/RS) is.=20 >>>>>=20 >>>>> Any other views?=20 >>>>>=20 >>>>> Ciao >>>>> Hannes >>>>>=20 >>>>> PS: Please let me know if I should provide more background about = the issue.=20 >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>=20 >>=20 >> _______________________________________________ >> Kitten mailing list >> Kitten@ietf.org >> https://www.ietf.org/mailman/listinfo/kitten --Apple-Mail=_CC1131A4-E711-4E86-B315-FDB14AA02927 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDUx MDE0NTgzNlowIwYJKoZIhvcNAQkEMRYEFKIx0xDQ3tSWW20+QoYlbSRniU5LMIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB AEuZCPD4iKDCmS2acSy0NQtREwhIcSiXUAJ/z7pMQvnBrZu9Yk316Fa9GFwK4iyyzmV3NFEl4y4n 0lODz4cRje2EQPz3w0DM/ogXqWODhvCYm3hDZ9YcxuolSNvTA8jFGlxOfAzoENAGhgAbrJFLiDqL JWGOaPCPYeXNRN2sDOGNSXYlJWg+rKqWoDhaWXsyVRzd/1ZT4t94I/gO7XVzr+XxUE+NHAcrfysm VEkyGwV0Mwv/WG/wA0qd/NuZ96zQGTaMG0iZeDW7rkVzMWtqdG23c/ZKwN6V1j9FSEHEUgEfbybT S3kh4Xekw7eWrFOCTIYFapF0hNuBsq/4GAXaX+wAAAAAAAA= --Apple-Mail=_CC1131A4-E711-4E86-B315-FDB14AA02927-- From jricher@mitre.org Thu May 10 08:17:06 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2317F21F86E1; Thu, 10 May 2012 08:17:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.553 X-Spam-Level: X-Spam-Status: No, score=-6.553 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 nxnpiYVwcchG; Thu, 10 May 2012 08:17:04 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 90E4D21F8592; Thu, 10 May 2012 08:17:04 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id DC4C521B1536; Thu, 10 May 2012 11:16:59 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id BDFB621B151F; Thu, 10 May 2012 11:16:59 -0400 (EDT) Received: from [129.83.50.12] (129.83.31.51) by IMCCAS04.MITRE.ORG (129.83.29.81) with Microsoft SMTP Server (TLS) id 14.2.283.3; Thu, 10 May 2012 11:16:59 -0400 Message-ID: <4FABDBA2.20908@mitre.org> Date: Thu, 10 May 2012 11:15:46 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: John Bradley References: <40FC97F0-B72C-47F4-8206-590BA365997A@gmx.net> <5ECED997-49B8-4550-B79A-CF121FCD1AF9@ve7jtb.com> <9F541ABD-23C0-4592-BC8C-7B7E7CC620CB@gmx.net> <81091A66-03C3-4085-A840-BEC1BBF48161@ve7jtb.com> <6E2A5AF6-F4D8-4FCA-A45F-7AE5032A82BE@ve7jtb.com> In-Reply-To: <6E2A5AF6-F4D8-4FCA-A45F-7AE5032A82BE@ve7jtb.com> Content-Type: multipart/alternative; boundary="------------040308030308090104020009" X-Originating-IP: [129.83.31.51] X-Mailman-Approved-At: Thu, 10 May 2012 09:02:03 -0700 Cc: kitten@ietf.org, "Klaas Wierenga \(kwiereng\)" , oauth@ietf.org Subject: Re: [kitten] [OAUTH-WG] OAuth Discovery and what the relying partyneeds to know X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 15:17:06 -0000 --------------040308030308090104020009 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit It's important to remember that these identifiers need to be handled, seen, and remembered by people. Especially in the long-tail case (which is to say, IdPs who aren't big enough to get a log in button), users will need to enter a piece of text into a website to tell the website who they are. There's the longstanding usability issue of how users self-identify. We have taught people over the last 30 years or so that a format of "user@domain" represents a person. SMTP, XMPP, SIP, and other protocols have used this format successfully. OpenID made the mistake of trying to teach people that "http://domain/user" could also stand for them, but people just don't think of themselves in terms of HTTP URLs. Webfinger came about to address this, and SWD adopted the same pattern. Account Chooser is a great UI for public, internet-facing websites, but it's far from universally applicable. Whether it's good privacy practice or not, the natural pattern for people to log into a website is to type something that looks like an email address. Also note that while in many peoples' cases, the acct:user@domain will match their mailto:user@domain address, but that's not necessarily true universally. This adds flexibility for allowing a domain-style identifier to use the same discovery process as a user@domain-style identifier and privacy-conscious users can use the former. -- Justin On 05/10/2012 10:58 AM, John Bradley wrote: > openID Connect dosen't require a user portion of the identifier to be discovered and supports a opaque or pseudonymous user_id. > email is an optional attribute that can be returned by user consent. > > OpenID 2.0 actively discouraged using email addresses for privacy reasons. Teaching people to enter there email addresses into unknown sites was seen as a bad thing by many. > > WF was started partially as an alternative discovery mechanism for openID to allow people to enter email addresses to discover there IdP, given a belief that users could only be asked to enter email and > NASCAR UI was not scalable. > > openID is attempting to separately address the NASCAR problem with it's Account Chooser project to allow the user to configure and control their selection of IdP without entering info directly into the RP. > > For WF/SWD the decision is to enforce discovery by host only or support a user component so that a email or other service provider could allow per user choice. > > I do happen to personally agree that teaching users to give up there email to random websites is not a good idea, however not allowing a user component in discovery won't stop RP from asking and removes otherwise useful functionality and choice fro the user. > > John B. > > On 2012-05-10, at 1:43 AM, Klaas Wierenga (kwiereng) wrote: > >> Hmmm, I see your point but I think that from a privacy PoV revealing the username to the RP is not good practice, especially not prior to trust being established between RP and IdP. If the IdP wants to send the assertion in the authentication statement that is another matter. But you don't want rogue RPs harvesting user names. So instead i have assumed that the domain could be more specific if needed, i.e. for 99% of the cases example.com would suffice but for the corner cases I imagine using idp1.example.com and idp2.example.com. But I understand that in an oauth scenario that may be less pretty. >> >> Klaas >> >> Sent from my iPad >> >> On 9 mei 2012, at 21:31, "John Bradley" wrote: >> >>> The lookup is based on the identifier provided by the user. It can have a user portion in the format of a URI https://john@example.com , https://example.com/john or anything else where you can extract the domain. >>> >>> The user portion is necessary to allow for per user IdP delegation. Otherwise only one IdP per host could be supported. >>> >>> John B. >>> >>> >>> On 2012-05-09, at 2:42 PM, Hannes Tschofenig wrote: >>> >>>> Hi John, >>>> >>>> does the "identifier" contain of a domain part AND a username part or only the domain part? >>>> That's the crucial question here. >>>> >>>> Ciao >>>> Hannes >>>> >>>> On May 9, 2012, at 9:20 PM, John Bradley wrote: >>>> >>>>> For openID Connect we are using the identifier to discover the AS. We refer to that as an issuer, and perform a second discovery step to get the configuration (Auth endpoint, token endpoint, user_info endpoint and other config) for that issuer. >>>>> >>>>> SWD/WF may be used for other things by other protocols, but our use is quite simple. >>>>> >>>>> I think that is probably the same thing for SASL, but others may think differently. >>>>> >>>>> John B. >>>>> >>>>> >>>>> On 2012-05-09, at 1:50 PM, Hannes Tschofenig wrote: >>>>> >>>>>> Hi guys, >>>>>> >>>>>> at the last IIW we had a discussion about SASL-OAuth and what the SASL server needs to know for discovery. >>>>>> The discovery discussions around WebFinger go in the same directions. >>>>>> >>>>>> So, I have been wondering whether we have made an informed decision about how the discovery procedure is actually supposed to look like. >>>>>> >>>>>> In my view, the relying party (the client) only needs to know who the identity provider (the AS/RS) is. >>>>>> >>>>>> Any other views? >>>>>> >>>>>> Ciao >>>>>> Hannes >>>>>> >>>>>> PS: Please let me know if I should provide more background about the issue. >>>>>> >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>> _______________________________________________ >>> Kitten mailing list >>> Kitten@ietf.org >>> https://www.ietf.org/mailman/listinfo/kitten > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------040308030308090104020009 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit It's important to remember that these identifiers need to be handled, seen, and remembered by people. Especially in the long-tail case (which is to say, IdPs who aren't big enough to get a log in button), users will need to enter a piece of text into a website to tell the website who they are. There's the longstanding usability issue of how users self-identify. We have taught people over the last 30 years or so that a format of "user@domain" represents a person. SMTP, XMPP, SIP, and other protocols have used this format successfully. OpenID made the mistake of trying to teach people that "http://domain/user"  could also stand for them, but people just don't think of themselves in terms of HTTP URLs. Webfinger came about to address this, and SWD adopted the same pattern. Account Chooser is a great UI for public, internet-facing websites, but it's far from universally applicable.

Whether it's good privacy practice or not, the natural pattern for people to log into a website is to type something that looks like an email address. Also note that while in many peoples' cases, the acct:user@domain will match their mailto:user@domain address, but that's not necessarily true universally. This adds flexibility for allowing a domain-style identifier to use the same discovery process as a user@domain-style identifier and privacy-conscious users can use the former.

 -- Justin

On 05/10/2012 10:58 AM, John Bradley wrote: 
openID Connect dosen't require a user portion of the identifier to be discovered and supports a opaque or pseudonymous user_id.    
email is an optional attribute that can be returned by user consent.

OpenID 2.0 actively discouraged using email addresses for privacy reasons.  Teaching people to enter there email addresses into unknown sites was seen as a bad thing by many.

WF was started partially as an alternative discovery mechanism for openID to allow people to enter email addresses to discover there IdP, given a belief that users could only be asked to enter email and 
NASCAR UI was not scalable.

openID is attempting to separately address the NASCAR problem with it's Account Chooser project to allow the user to configure and control their selection of IdP without entering info directly into the RP.

For WF/SWD the decision is to enforce discovery by host only or support a user component so that a email or other service provider could allow per user choice.

I do happen to personally agree that teaching users to give up there email to random websites is not a good idea, however not allowing a user component in discovery won't stop RP from asking and removes otherwise useful functionality and choice fro the user.

John B.

On 2012-05-10, at 1:43 AM, Klaas Wierenga (kwiereng) wrote:


Hmmm, I see your point but I think that from a privacy PoV revealing the username to the RP is not good practice, especially not prior to trust being established between RP and IdP. If the IdP wants to send the assertion in the authentication statement that is another matter. But you don't want rogue RPs harvesting user names. So instead i have assumed that the domain could be more specific if needed, i.e. for 99% of the cases example.com would suffice but for the corner cases I imagine using idp1.example.com and idp2.example.com. But I understand that in an oauth scenario that may be less pretty.

Klaas

Sent from my iPad

On 9 mei 2012, at 21:31, "John Bradley" <ve7jtb@ve7jtb.com> wrote:


The lookup is based on the identifier provided by the user.  It can have a user portion in the format of a URI https://john@example.com , https://example.com/john or anything else where you can extract the domain.

The user portion is necessary to allow for per user IdP delegation.   Otherwise only one IdP per host could be supported.

John B.


On 2012-05-09, at 2:42 PM, Hannes Tschofenig wrote:


Hi John, 

does the "identifier" contain of a domain part AND a username part or only the domain part? 
That's the crucial question here. 

Ciao
Hannes

On May 9, 2012, at 9:20 PM, John Bradley wrote:


For openID Connect we are using the identifier to discover the AS.   We refer to that as an issuer,  and perform a second discovery step to get the configuration (Auth endpoint, token endpoint, user_info endpoint and other config) for that issuer.

SWD/WF may be used for other things by other protocols, but our use is quite simple.

I think that is probably the same thing for SASL,  but others may think differently.

John B.


On 2012-05-09, at 1:50 PM, Hannes Tschofenig wrote:


Hi guys, 

at the last IIW we had a discussion about SASL-OAuth and what the SASL server needs to know for discovery. 
The discovery discussions around WebFinger go in the same directions. 

So, I have been wondering whether we have made an informed decision about how the discovery procedure is actually supposed to look like. 

In my view, the relying party (the client) only needs to know who the identity provider (the AS/RS) is. 

Any other views? 

Ciao
Hannes

PS: Please let me know if I should provide more background about the issue. 

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


            

            

          

          
_______________________________________________
Kitten mailing list
Kitten@ietf.org
https://www.ietf.org/mailman/listinfo/kitten


        

      

      

      

      

      

      
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


    

    

  


--------------040308030308090104020009--

From ve7jtb@ve7jtb.com  Thu May 10 09:25:54 2012
Return-Path: 
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CB5421F86F8 for ; Thu, 10 May 2012 09:25:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.541
X-Spam-Level: 
X-Spam-Status: No, score=-3.541 tagged_above=-999 required=5 tests=[AWL=0.057,  BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 sghyn+ZBcYOa for ; Thu, 10 May 2012 09:25:53 -0700 (PDT)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id B86EF21F86C7 for ; Thu, 10 May 2012 09:25:52 -0700 (PDT)
Received: by yhq56 with SMTP id 56so2032696yhq.31 for ; Thu, 10 May 2012 09:25:52 -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=TCEXhcsOJAyizsbEI3Jqzfp4DIQAtuet+cc0cJBwj5c=; b=K2KKFqjWVrV2TwNhSgOF6AhMN9tPlI5p2ctLGYmlxCZReNBNCd3exzich9Fl9GaYeO LOvQ3VWYu+FRnUuxLU14Ny/mKbBCL1kHCVJ068UaFweHDSpkNv5oZcFCUDFcRCROdjSs prP+PUYmKOtq1EIb+31MuTrVrhcHHOlT8APGYMR36AjPLEEXfGIofj00hcz34kjjfybf F85vhMEKXR8s0e9NS2zn9AaZoNMQUd7Xx5tw+vZh+ZLWmbUgxVzDtESVAARt7Z+qeh7f NANNQB9liGuT2Ekz64s8U+T6cWJapQcP8UTdiDsxhCTzfG66jQMF5TVQHH3LdDzHVNxN lz6w==
Received: by 10.236.79.234 with SMTP id i70mr5882999yhe.88.1336667151993; Thu, 10 May 2012 09:25:51 -0700 (PDT)
Received: from [192.168.1.213] (190-20-35-188.baf.movistar.cl. [190.20.35.188]) by mx.google.com with ESMTPS id p29sm22743290yhl.19.2012.05.10.09.25.48 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 10 May 2012 09:25:50 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: multipart/signed; boundary="Apple-Mail=_941D81E7-8CC1-49DF-BEC8-6BDD4CE267BF"; protocol="application/pkcs7-signature"; micalg=sha1
From: John Bradley 
In-Reply-To: <4FABDBA2.20908@mitre.org>
Date: Thu, 10 May 2012 12:25:42 -0400
Message-Id: 
References: <40FC97F0-B72C-47F4-8206-590BA365997A@gmx.net> <5ECED997-49B8-4550-B79A-CF121FCD1AF9@ve7jtb.com> <9F541ABD-23C0-4592-BC8C-7B7E7CC620CB@gmx.net> <81091A66-03C3-4085-A840-BEC1BBF48161@ve7jtb.com>  <6E2A5AF6-F4D8-4FCA-A45F-7AE5032A82BE@ve7jtb.com> <4FABDBA2.20908@mitre.org>
To: Justin Richer 
X-Mailer: Apple Mail (2.1257)
X-Gm-Message-State: ALoCoQnTmZ2jVOLJTfSSXmGUEPjcBkxLfOR4rdLvQxfF/WanE7AQm3CtmxefS7AwVQ0bo8mRsT80
Cc: kitten@ietf.org, "Klaas Wierenga \(kwiereng\)" , oauth@ietf.org
Subject: Re: [kitten] [OAUTH-WG] OAuth Discovery and what the relying partyneeds to know
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Common Authentication Technologies - Next Generation 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 May 2012 16:25:54 -0000

--Apple-Mail=_941D81E7-8CC1-49DF-BEC8-6BDD4CE267BF
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_0A0E5208-4463-4AE8-BACF-4564DADB7231"


--Apple-Mail=_0A0E5208-4463-4AE8-BACF-4564DADB7231
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

Allowing user based discovery is not mutually exclusive with things that =
provide browser based help for selecting a IdP.
Forcing a user to type a email address for twitter may also prove =
unnatural. =20

More help for the user by their trusted user agent is probably the =
better way to go in the long term. =20
In the short therm almost anything is better than users current practice =
of entering there email and password directly into random sites. =20

It is reasonable in the IMAP case where the client already has the email =
to use that to start discovery for the Authorization server for that =
identifier.

John B.
On 2012-05-10, at 11:15 AM, Justin Richer wrote:

> It's important to remember that these identifiers need to be handled, =
seen, and remembered by people. Especially in the long-tail case (which =
is to say, IdPs who aren't big enough to get a log in button), users =
will need to enter a piece of text into a website to tell the website =
who they are. There's the longstanding usability issue of how users =
self-identify. We have taught people over the last 30 years or so that a =
format of "user@domain" represents a person. SMTP, XMPP, SIP, and other =
protocols have used this format successfully. OpenID made the mistake of =
trying to teach people that "http://domain/user"  could also stand for =
them, but people just don't think of themselves in terms of HTTP URLs. =
Webfinger came about to address this, and SWD adopted the same pattern. =
Account Chooser is a great UI for public, internet-facing websites, but =
it's far from universally applicable.
>=20
> Whether it's good privacy practice or not, the natural pattern for =
people to log into a website is to type something that looks like an =
email address. Also note that while in many peoples' cases, the =
acct:user@domain will match their mailto:user@domain address, but that's =
not necessarily true universally. This adds flexibility for allowing a =
domain-style identifier to use the same discovery process as a =
user@domain-style identifier and privacy-conscious users can use the =
former.
>=20
>  -- Justin
>=20
> On 05/10/2012 10:58 AM, John Bradley wrote:
>>=20
>> openID Connect dosen't require a user portion of the identifier to be =
discovered and supports a opaque or pseudonymous user_id.   =20
>> email is an optional attribute that can be returned by user consent.
>>=20
>> OpenID 2.0 actively discouraged using email addresses for privacy =
reasons.  Teaching people to enter there email addresses into unknown =
sites was seen as a bad thing by many.
>>=20
>> WF was started partially as an alternative discovery mechanism for =
openID to allow people to enter email addresses to discover there IdP, =
given a belief that users could only be asked to enter email and=20
>> NASCAR UI was not scalable.
>>=20
>> openID is attempting to separately address the NASCAR problem with =
it's Account Chooser project to allow the user to configure and control =
their selection of IdP without entering info directly into the RP.
>>=20
>> For WF/SWD the decision is to enforce discovery by host only or =
support a user component so that a email or other service provider could =
allow per user choice.
>>=20
>> I do happen to personally agree that teaching users to give up there =
email to random websites is not a good idea, however not allowing a user =
component in discovery won't stop RP from asking and removes otherwise =
useful functionality and choice fro the user.
>>=20
>> John B.
>>=20
>> On 2012-05-10, at 1:43 AM, Klaas Wierenga (kwiereng) wrote:
>>=20
>>> Hmmm, I see your point but I think that from a privacy PoV revealing =
the username to the RP is not good practice, especially not prior to =
trust being established between RP and IdP. If the IdP wants to send the =
assertion in the authentication statement that is another matter. But =
you don't want rogue RPs harvesting user names. So instead i have =
assumed that the domain could be more specific if needed, i.e. for 99% =
of the cases example.com would suffice but for the corner cases I =
imagine using idp1.example.com and idp2.example.com. But I understand =
that in an oauth scenario that may be less pretty.
>>>=20
>>> Klaas
>>>=20
>>> Sent from my iPad
>>>=20
>>> On 9 mei 2012, at 21:31, "John Bradley"  wrote:
>>>=20
>>>> The lookup is based on the identifier provided by the user.  It can =
have a user portion in the format of a URI https://john@example.com , =
https://example.com/john or anything else where you can extract the =
domain.
>>>>=20
>>>> The user portion is necessary to allow for per user IdP delegation. =
  Otherwise only one IdP per host could be supported.
>>>>=20
>>>> John B.
>>>>=20
>>>>=20
>>>> On 2012-05-09, at 2:42 PM, Hannes Tschofenig wrote:
>>>>=20
>>>>> Hi John,=20
>>>>>=20
>>>>> does the "identifier" contain of a domain part AND a username part =
or only the domain part?=20
>>>>> That's the crucial question here.=20
>>>>>=20
>>>>> Ciao
>>>>> Hannes
>>>>>=20
>>>>> On May 9, 2012, at 9:20 PM, John Bradley wrote:
>>>>>=20
>>>>>> For openID Connect we are using the identifier to discover the =
AS.   We refer to that as an issuer,  and perform a second discovery =
step to get the configuration (Auth endpoint, token endpoint, user_info =
endpoint and other config) for that issuer.
>>>>>>=20
>>>>>> SWD/WF may be used for other things by other protocols, but our =
use is quite simple.
>>>>>>=20
>>>>>> I think that is probably the same thing for SASL,  but others may =
think differently.
>>>>>>=20
>>>>>> John B.
>>>>>>=20
>>>>>>=20
>>>>>> On 2012-05-09, at 1:50 PM, Hannes Tschofenig wrote:
>>>>>>=20
>>>>>>> Hi guys,=20
>>>>>>>=20
>>>>>>> at the last IIW we had a discussion about SASL-OAuth and what =
the SASL server needs to know for discovery.=20
>>>>>>> The discovery discussions around WebFinger go in the same =
directions.=20
>>>>>>>=20
>>>>>>> So, I have been wondering whether we have made an informed =
decision about how the discovery procedure is actually supposed to look =
like.=20
>>>>>>>=20
>>>>>>> In my view, the relying party (the client) only needs to know =
who the identity provider (the AS/RS) is.=20
>>>>>>>=20
>>>>>>> Any other views?=20
>>>>>>>=20
>>>>>>> Ciao
>>>>>>> Hannes
>>>>>>>=20
>>>>>>> PS: Please let me know if I should provide more background about =
the issue.=20
>>>>>>>=20
>>>>>>> _______________________________________________
>>>>>>> OAuth mailing list
>>>>>>> OAuth@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>> _______________________________________________
>>>> Kitten mailing list
>>>> Kitten@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/kitten
>>=20
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>=20


--Apple-Mail=_0A0E5208-4463-4AE8-BACF-4564DADB7231
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset=iso-8859-1

Allowing user based discovery is not mutually exclusive with things that provide browser based help for selecting a IdP.
Forcing a user to type a email address for twitter may also prove unnatural.  

More help for the user by their trusted user agent is probably the better way to go in the long term.  
In the short therm almost anything is better than users current practice of entering there email and password directly into random sites.  

It is reasonable in the IMAP case where the client already has the email to use that to start discovery for the Authorization server for that identifier.

John B.
On 2012-05-10, at 11:15 AM, Justin Richer wrote:


  
    
  
  

    It's important to remember that these identifiers need to be
    handled, seen, and remembered by people. Especially in the long-tail
    case (which is to say, IdPs who aren't big enough to get a log in
    button), users will need to enter a piece of text into a website to
    tell the website who they are. There's the longstanding usability
    issue of how users self-identify. We have taught people over the
    last 30 years or so that a format of "user@domain" represents a
    person. SMTP, XMPP, SIP, and other protocols have used this format
    successfully. OpenID made the mistake of trying to teach people that
    "http://domain/user"  could also stand for them, but people just
    don't think of themselves in terms of HTTP URLs. Webfinger came
    about to address this, and SWD adopted the same pattern. Account
    Chooser is a great UI for public, internet-facing websites, but it's
    far from universally applicable.

    

    Whether it's good privacy practice or not, the natural pattern for
    people to log into a website is to type something that looks like an
    email address. Also note that while in many peoples' cases, the
    acct:user@domain will match their mailto:user@domain address, but
    that's not necessarily true universally. This adds flexibility for
    allowing a domain-style identifier to use the same discovery process
    as a user@domain-style identifier and privacy-conscious users can
    use the former.

    

     -- Justin

    

    On 05/10/2012 10:58 AM, John Bradley wrote:
    

      
openID Connect dosen't require a user portion of the identifier to be discovered and supports a opaque or pseudonymous user_id.    
email is an optional attribute that can be returned by user consent.

OpenID 2.0 actively discouraged using email addresses for privacy reasons.  Teaching people to enter there email addresses into unknown sites was seen as a bad thing by many.

WF was started partially as an alternative discovery mechanism for openID to allow people to enter email addresses to discover there IdP, given a belief that users could only be asked to enter email and 
NASCAR UI was not scalable.

openID is attempting to separately address the NASCAR problem with it's Account Chooser project to allow the user to configure and control their selection of IdP without entering info directly into the RP.

For WF/SWD the decision is to enforce discovery by host only or support a user component so that a email or other service provider could allow per user choice.

I do happen to personally agree that teaching users to give up there email to random websites is not a good idea, however not allowing a user component in discovery won't stop RP from asking and removes otherwise useful functionality and choice fro the user.

John B.

On 2012-05-10, at 1:43 AM, Klaas Wierenga (kwiereng) wrote:



      

        
Hmmm, I see your point but I think that from a privacy PoV revealing the username to the RP is not good practice, especially not prior to trust being established between RP and IdP. If the IdP wants to send the assertion in the authentication statement that is another matter. But you don't want rogue RPs harvesting user names. So instead i have assumed that the domain could be more specific if needed, i.e. for 99% of the cases example.com would suffice but for the corner cases I imagine using idp1.example.com and idp2.example.com. But I understand that in an oauth scenario that may be less pretty.

Klaas

Sent from my iPad

On 9 mei 2012, at 21:31, "John Bradley" <ve7jtb@ve7jtb.com> wrote:



        

          
The lookup is based on the identifier provided by the user.  It can have a user portion in the format of a URI https://john@example.com , https://example.com/john or anything else where you can extract the domain.

The user portion is necessary to allow for per user IdP delegation.   Otherwise only one IdP per host could be supported.

John B.


On 2012-05-09, at 2:42 PM, Hannes Tschofenig wrote:



          

            
Hi John, 

does the "identifier" contain of a domain part AND a username part or only the domain part? 
That's the crucial question here. 

Ciao
Hannes

On May 9, 2012, at 9:20 PM, John Bradley wrote:



            

              
For openID Connect we are using the identifier to discover the AS.   We refer to that as an issuer,  and perform a second discovery step to get the configuration (Auth endpoint, token endpoint, user_info endpoint and other config) for that issuer.

SWD/WF may be used for other things by other protocols, but our use is quite simple.

I think that is probably the same thing for SASL,  but others may think differently.

John B.


On 2012-05-09, at 1:50 PM, Hannes Tschofenig wrote:



              

                
Hi guys, 

at the last IIW we had a discussion about SASL-OAuth and what the SASL server needs to know for discovery. 
The discovery discussions around WebFinger go in the same directions. 

So, I have been wondering whether we have made an informed decision about how the discovery procedure is actually supposed to look like. 

In my view, the relying party (the client) only needs to know who the identity provider (the AS/RS) is. 

Any other views? 

Ciao
Hannes

PS: Please let me know if I should provide more background about the issue. 

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


              

              

            

            

          

          
_______________________________________________
Kitten mailing list
Kitten@ietf.org
https://www.ietf.org/mailman/listinfo/kitten


        

      

      

      

      

      

      
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


    

    

  





--Apple-Mail=_0A0E5208-4463-4AE8-BACF-4564DADB7231--

--Apple-Mail=_941D81E7-8CC1-49DF-BEC8-6BDD4CE267BF
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw
ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh
cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4
MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew
HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3
NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU
BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ
ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93
rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe
nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa
hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw
26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc
ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz
9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh
ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl
N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC
IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz
c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp
ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj
b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy
dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu
IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC
AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg
YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh
dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6
Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB
BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr
BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu
Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF
AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc
0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d
NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT
0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC
Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI
hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT
IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl
cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx
CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln
aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h
cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD
teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA
o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX
fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6
5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w
CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd
gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy
dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw
JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G
CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu
Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu
Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU
MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj
b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p
bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy
dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl
Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg
UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR
BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy
eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA
A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE
4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn
JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1
z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7
qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ
3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E
/ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9
tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH
jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK
qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk
LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv
U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO
AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDUx
MDE2MjU0M1owIwYJKoZIhvcNAQkEMRYEFAjpE8kvyoFCZuh8uGUmDZtMxVJOMIGkBgkrBgEEAYI3
EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL
EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL
MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi
U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh
c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB
AH1RyVcJvyQj+ClyiSws3giWJNRema8/uBG5WELtsLGQDrLZxqeoFQ6TZXbrWDO1xGqAxUWRNLU1
tLBfSjfv6rFsvRQgYu0gZ7Kp30WgBBYqbLZBEoHwtKOoxMKdv73dOPHeXtMndqy4Ltl0C0z2vkfT
gsmxl9DhlffmD54isl1KQcLjAxGvDG1fX++7Yyks5d6PHPK7ORQT2/oj3xXT6s8ZRRnmeg24xhFX
RkGAvmwSOY6T3EAQXRpjjKvXx9ib8a5DhBrsU90hnKs2PrNLt5lMBTfx8Dp47VRcWsGDzkeSl+BC
zPWGAVZarzm/N6CzfNEbkPdgfHIlUF8VVbDMkmQAAAAAAAA=

--Apple-Mail=_941D81E7-8CC1-49DF-BEC8-6BDD4CE267BF--

From wmills@yahoo-inc.com  Fri May 11 08:08:39 2012
Return-Path: 
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C0DA21F85A7 for ; Fri, 11 May 2012 08:08:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.221
X-Spam-Level: 
X-Spam-Status: No, score=-17.221 tagged_above=-999 required=5 tests=[AWL=0.377, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15]
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 CP2y7pCSLKUK for ; Fri, 11 May 2012 08:08:38 -0700 (PDT)
Received: from nm6.bullet.mail.ac4.yahoo.com (nm6.bullet.mail.ac4.yahoo.com [98.139.52.203]) by ietfa.amsl.com (Postfix) with SMTP id 7068B21F859A for ; Fri, 11 May 2012 08:08:38 -0700 (PDT)
Received: from [98.139.52.197] by nm6.bullet.mail.ac4.yahoo.com with NNFMP; 11 May 2012 15:08:35 -0000
Received: from [98.139.52.133] by tm10.bullet.mail.ac4.yahoo.com with NNFMP; 11 May 2012 15:08:35 -0000
Received: from [127.0.0.1] by omp1016.mail.ac4.yahoo.com with NNFMP; 11 May 2012 15:08:35 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 388113.71852.bm@omp1016.mail.ac4.yahoo.com
Received: (qmail 48393 invoked by uid 60001); 11 May 2012 15:08:32 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1336748911; bh=fiLsi7HRkAy2K7dEgBshkudcRk8zdMN0KlrhFc041e4=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=fy+WtI/kSbCzIKMLuFQOUResZm/EFzGYl+xgfiSNX/4s6M9ICXuWwfWQtdl5WdkpBQcLXiBcHUrAxXdKoBd8fTZXEaNrIrQfx2RQw9tkpLhkg5TtTbwz3xAg0a3cAXVklNrkILpFMpqCyJFPD54gMKfMErj3mPc1FZUt+uBQwD0=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=PhinUWweE634Ee6o/YEJiIaf3om4wCZEKm9Tanjz2XMlNauEn9+6lorMe9LrVUD4/jIOw22ZmrTlQFoADLNcMoUXjmBNZ6xTrVRap2NL7pEwnCWXPKvZSbfUS4sku2jLiiH9bU50Q0++PQdJdtjT63MFAqpxecchqtwjCVAXCt0=;
X-YMail-OSG: .F03WacVM1lJcb_lzo55L_yPgblxfHSkaxmZdW2BAiCmYWi AS2DVj7Fi5CH2Kt8DDElOGrXHH07PQKxg8vAv0UUo.VsYvVcewfUb3.XmUor TbVd3FuQsvZrpWAKqtmE6Irqn8imgPr7hjKvVxR22bkuatsm_Sesm100zoy. UTU5LfADn5VPHDoXnMhJEx3fPj.6aALHBa95a4yqV8n86ze3AznRsR_BIwK1 qyLdXLrtlvg_ol8bmA0GZNqUDE.AcVLpxOxtDSBrtjI9ycWutwwrSP1o9Ckm j42G_hhC7JEvYWCtM1Ftek1RUrt18IV4u1Io7_9L8GflP5SeVrrPjGaisXkA AAx15fAOzrACpgOHfjvcCbXLHS7hhK5qeOUZxNmNwtsXgfj9qUMDJnrM2_wX k53jRWKsFcBZitUvVGqnuaOdgrjiYd18dD88Gq2xLRx2FYerTT9V_aw--
Received: from [209.131.62.115] by web31807.mail.mud.yahoo.com via HTTP; Fri, 11 May 2012 08:08:31 PDT
X-RocketYMMF: william_john_mills
X-Mailer: YahooMailWebService/0.8.118.349524
References: <40FC97F0-B72C-47F4-8206-590BA365997A@gmx.net> <5ECED997-49B8-4550-B79A-CF121FCD1AF9@ve7jtb.com> <9F541ABD-23C0-4592-BC8C-7B7E7CC620CB@gmx.net> <81091A66-03C3-4085-A840-BEC1BBF48161@ve7jtb.com>  <6E2A5AF6-F4D8-4FCA-A45F-7AE5032A82BE@ve7jtb.com> <4FABDBA2.20908@mitre.org> <6.2.5.6.2.20120511000851.0a735510@resistor.net>
Message-ID: <1336748911.21434.YahooMailNeo@web31807.mail.mud.yahoo.com>
Date: Fri, 11 May 2012 08:08:31 -0700 (PDT)
From: William Mills 
To: SM , Justin Richer 
In-Reply-To: <6.2.5.6.2.20120511000851.0a735510@resistor.net>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="-125733401-1884177604-1336748911=:21434"
Cc: "kitten@ietf.org" , "oauth@ietf.org" 
Subject: Re: [kitten] [OAUTH-WG] OAuth Discovery and what the relying partyneeds to know
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: William Mills 
List-Id: Common Authentication Technologies - Next Generation 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 May 2012 15:08:39 -0000

---125733401-1884177604-1336748911=:21434
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Kitten is in the CC list because this applies to the discovery needs of the=
 OAUTH SASL draft.=0A=0A=0A=0A=0A>________________________________=0A> From=
: SM =0A>To: Justin Richer  =0A>Cc: kit=
ten@ietf.org; oauth@ietf.org =0A>Sent: Friday, May 11, 2012 12:19 AM=0A>Sub=
ject: Re: [OAUTH-WG] [kitten] OAuth Discovery and what the relying partynee=
ds to know=0A> =0A>Hi Justin,=0A>=0A>[not sure why kitten@ is in the Cc.=A0=
 Feel free to drop]=0A>=0A>At 08:15 10-05-2012, Justin Richer wrote:=0A>> "=
user@domain" represents a person. SMTP, XMPP, SIP, and other protocols have=
 used this format successfully. OpenID made the mistake of trying to teach =
people that "http://domain/user"=A0 could also stand for them, but people j=
ust don't think of themselves in terms of HTTP URLs. Webfinger came about t=
o address this, and SWD adopted=0A>=0A>The strings industry probably have s=
ome reason to believe that people think of themselves in terms of domain na=
mes.=A0 Some people think of the other person in terms of "what's your [ins=
ert social network]?".=A0 There are several specifications which reference =
rfc822 identifiers.=A0 The interesting point in the above is what will be p=
eople's expected behavior while taking into account the usual technical lim=
itations.=0A>=0A>Regards,=0A>-sm =0A>______________________________________=
_________=0A>OAuth mailing list=0A>OAuth@ietf.org=0A>https://www.ietf.org/m=
ailman/listinfo/oauth=0A>=0A>=0A>
---125733401-1884177604-1336748911=:21434
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable


Kitten is in the CC list because this applies to the discovery needs of t=
he OAUTH SASL draft.

  
 
 
  
  From: SM <sm@resistor.net>
 To: Justin Richer <jricher@mitre.org> Cc: kitten@ietf.org; oaut=
h@ietf.org 
 Sent: Frid=
ay, May 11, 2012
 12:19 AM
 Subject: Re:=
 [OAUTH-WG] [kitten] OAuth Discovery and what the relying partyneeds to kno=
w
  
 
=0AHi Justin,

[not sure why kitten@ is in t=
he Cc.  Feel free to drop]

At 08:15 10-05-2012, Justin Richer w=
rote:
> "user@domain" represents a person. SMTP, XMPP, SIP, and other=
 protocols have used this format successfully. OpenID made the mistake of t=
rying to teach people that "http://domain/user"  could also stand for =
them, but people just don't think of themselves in terms of HTTP URLs. Webf=
inger came about to address this, and SWD adopted

The strings indust=
ry probably have some reason to believe that people think of themselves in =
terms of domain names.  Some people think of the other person in terms=
 of "what's your [insert social network]?".  There are several specifi=
cations which reference rfc822 identifiers.  The interesting point in =
the above is what will be people's expected behavior while taking into acco=
unt the usual technical limitations.

Regards,
-sm
 
_______________________________________________
OAuth mailing list<=
br>OAut=
h@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

 
 
 
   

---125733401-1884177604-1336748911=:21434--

From sm@resistor.net  Fri May 11 00:22:17 2012
Return-Path: 
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2514021F8628; Fri, 11 May 2012 00:22:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.467
X-Spam-Level: 
X-Spam-Status: No, score=-102.467 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 NHvOoZEt+E3K; Fri, 11 May 2012 00:22:16 -0700 (PDT)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id BBED421F8615; Fri, 11 May 2012 00:22:16 -0700 (PDT)
Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q4B7MB4o027164; Fri, 11 May 2012 00:22:13 -0700 (PDT)
Message-Id: <6.2.5.6.2.20120511000851.0a735510@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Fri, 11 May 2012 00:19:02 -0700
To: Justin Richer 
From: SM 
In-Reply-To: <4FABDBA2.20908@mitre.org>
References: <40FC97F0-B72C-47F4-8206-590BA365997A@gmx.net> <5ECED997-49B8-4550-B79A-CF121FCD1AF9@ve7jtb.com> <9F541ABD-23C0-4592-BC8C-7B7E7CC620CB@gmx.net> <81091A66-03C3-4085-A840-BEC1BBF48161@ve7jtb.com>  <6E2A5AF6-F4D8-4FCA-A45F-7AE5032A82BE@ve7jtb.com> <4FABDBA2.20908@mitre.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Mailman-Approved-At: Fri, 11 May 2012 12:47:47 -0700
Cc: kitten@ietf.org, oauth@ietf.org
Subject: Re: [kitten] [OAUTH-WG] OAuth Discovery and what the relying partyneeds to know
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Common Authentication Technologies - Next Generation 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 May 2012 07:22:17 -0000

Hi Justin,

[not sure why kitten@ is in the Cc.  Feel free to drop]

At 08:15 10-05-2012, Justin Richer wrote:
>"user@domain" represents a person. SMTP, XMPP, SIP, and other 
>protocols have used this format successfully. OpenID made the 
>mistake of trying to teach people that "http://domain/user"  could 
>also stand for them, but people just don't think of themselves in 
>terms of HTTP URLs. Webfinger came about to address this, and SWD adopted

The strings industry probably have some reason to believe that people 
think of themselves in terms of domain names.  Some people think of 
the other person in terms of "what's your [insert social 
network]?".  There are several specifications which reference rfc822 
identifiers.  The interesting point in the above is what will be 
people's expected behavior while taking into account the usual 
technical limitations.

Regards,
-sm 


From wmills@yahoo-inc.com  Mon May 14 14:59:07 2012
Return-Path: 
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14AA921F882E for ; Mon, 14 May 2012 14:59:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.944
X-Spam-Level: 
X-Spam-Status: No, score=-15.944 tagged_above=-999 required=5 tests=[AWL=-0.946, BAYES_50=0.001, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15]
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 Z+QUN1fuABZP for ; Mon, 14 May 2012 14:59:06 -0700 (PDT)
Received: from nm38-vm7.bullet.mail.bf1.yahoo.com (nm38-vm7.bullet.mail.bf1.yahoo.com [72.30.239.23]) by ietfa.amsl.com (Postfix) with SMTP id 463B821F8822 for ; Mon, 14 May 2012 14:59:06 -0700 (PDT)
Received: from [98.139.212.149] by nm38.bullet.mail.bf1.yahoo.com with NNFMP; 14 May 2012 21:59:05 -0000
Received: from [98.139.212.234] by tm6.bullet.mail.bf1.yahoo.com with NNFMP; 14 May 2012 21:59:05 -0000
Received: from [127.0.0.1] by omp1043.mail.bf1.yahoo.com with NNFMP; 14 May 2012 21:59:05 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 652753.37832.bm@omp1043.mail.bf1.yahoo.com
Received: (qmail 88180 invoked by uid 60001); 14 May 2012 21:59:03 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1337032743; bh=6gkKsiflfCGTyEeHmiQQI968YxHwXcR1X4qDEHk9vf8=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=sMG07wSiP9iQp7zvJhyl16pXIUvoq0UkPEJy1SCNK+tHOQ8xWd74gBMLSPgpOT38SJmO2gDlA9tCk8ieoluMxlfJlcQe2LE9mrdzFT0deDg5h6JrIfPP2pG+Nu/drneSOUJrhlYAzDm1Xmgz+/7UBAoz0dLC/vci7BxtQ/TC/hs=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=aLgBxwUcOctfwCfXdUzyOl9Wcd+pdCqQ1A9oIBO3gfGNlZOZA3zlB/FnzWX8dnkqly0i4891G+hATVUlpckM47sOToc117+MQ1lcYZDNd99Q8opkJzP1KMfljjfDEKzLYg92Lhcj+U3uVZJ7d2168tKXyHmqvrO9gK33e4rj2Ww=;
X-YMail-OSG: iHGD5pYVM1n1QF2u2mruo33i7SgI.00jq1JgXg8cI5fc.c3 B6WYMj3.gx30pts7uTtfAeNIG3Zkdwdil2btqxpIv4S1mjc8GC1wEXzqiYqj 7Lk7qScBqa9Oftwu4EoTWR13a6HfDWeK_MIA44WoDGZTW0xz1l_KBKai2jk8 RLNkAmGuaP9JPzF6dyxdu0yBNsRWSAkY5VrIU4Jirk61sGBV3rBT.uB7UWtg qWvRYApcRvzEIfl_ANrLzM2wJc5TWhzMCApry8hO2y9mR51qCdo0tEE4XdGj ax0w5zFAhYkXok4YIp4KExI74bMONBh9UOIVQJCLHVQpH8iE2KBknQqGyEpN Tc8tCx4baJIqKNO6aVVobrfo9BPoxygWrHGq2sntO8oSTWjFLMb8KKNrQRcO jY2W3zz_zLalWrLTDlS4flVl9X61FEseJjg--
Received: from [209.131.62.120] by web31806.mail.mud.yahoo.com via HTTP; Mon, 14 May 2012 14:59:03 PDT
X-RocketYMMF: william_john_mills
X-Mailer: YahooMailWebService/0.8.118.349524
Message-ID: <1337032743.59474.YahooMailNeo@web31806.mail.mud.yahoo.com>
Date: Mon, 14 May 2012 14:59:03 -0700 (PDT)
From: William Mills 
To: "kitten@ietf.org" 
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="-1055047407-1120115850-1337032743=:59474"
Subject: [kitten] OAUTH/SASL and the format debate
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: William Mills 
List-Id: Common Authentication Technologies - Next Generation 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 May 2012 21:59:07 -0000

---1055047407-1120115850-1337032743=:59474
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Having inquired of a number of folks that have implemented the XOAUTH mecha=
nism and getting no reply, I'm planning to go with "silence =3D=3D consent"=
 and presume there's no big objection to moving away form the HTTP format s=
tyle for the SASL messages.=A0 I' planning on a key/value pair format, whic=
h is easily extensible.=A0 My plan was something like:=0A=0A=A0=A0=A0 NONZE=
RO ::=3D  %x31-39=0A=A0=A0=A0 key ::=3D NONZERO *DIGIT=A0=0A=A0=A0=A0 value=
 ::=3D *(SP HTAB VCHAR)=0A=0A=A0=A0=A0 msg_line ::=3D key SP value CRLF=0A=
=A0=A0=A0 sasl_msg ::=3D +msg_line CRLF=0A=0AWe would need an IANA registry=
 for keys.=A0 Objections?=A0 Other preferred formats?=0A=0A-bill
---1055047407-1120115850-1337032743=:59474
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable


Havi=
ng inquired of a number of folks that have implemented the XOAUTH mechanism=
 and getting no reply, I'm planning to go with "silence =3D=3D consent" and=
 presume there's no big objection to moving away form the HTTP format style=
 for the SASL messages.  I' planning on a key/value pair format, which=
 is easily extensible.  My plan was something like:

    NONZERO ::=3D =0A%x31-=
39
    key ::=3D NONZERO *DIGI=
T 
    value ::=3D=
 *(SP HTAB VCHAR)
  &nbs=
p; msg_line ::=3D key SP value CRLF
    sasl_msg ::=3D +msg_line CRLF

We would need an IANA registry for keys.  Objections?  Other p=
referred formats?

-bill


---1055047407-1120115850-1337032743=:59474--

From stpeter@stpeter.im  Mon May 14 15:09:19 2012
Return-Path: 
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C543321F88E8 for ; Mon, 14 May 2012 15:09:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.551
X-Spam-Level: 
X-Spam-Status: No, score=-102.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 BfQmhGRa9PS8 for ; Mon, 14 May 2012 15:09:19 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id E90A221F88C1 for ; Mon, 14 May 2012 15:09:18 -0700 (PDT)
Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 242454005A; Mon, 14 May 2012 16:24:56 -0600 (MDT)
Message-ID: <4FB1828D.2080404@stpeter.im>
Date: Mon, 14 May 2012 16:09:17 -0600
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: William Mills 
References: <1337032743.59474.YahooMailNeo@web31806.mail.mud.yahoo.com>
In-Reply-To: <1337032743.59474.YahooMailNeo@web31806.mail.mud.yahoo.com>
X-Enigmail-Version: 1.4.1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: "kitten@ietf.org" 
Subject: Re: [kitten] OAUTH/SASL and the format debate
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Common Authentication Technologies - Next Generation 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 May 2012 22:09:19 -0000

On 5/14/12 3:59 PM, William Mills wrote:
> Having inquired of a number of folks that have implemented the XOAUTH
> mechanism and getting no reply, I'm planning to go with "silence ==
> consent" and presume there's no big objection to moving away form the
> HTTP format style for the SASL messages.  I' planning on a key/value
> pair format, which is easily extensible.  My plan was something like:
> 
>     NONZERO ::= %x31-39
>     key ::= NONZERO *DIGIT 
>     value ::= *(SP HTAB VCHAR)
>     msg_line ::= key SP value CRLF
>     sasl_msg ::= +msg_line CRLF
> 
> We would need an IANA registry for keys.  Objections?  Other preferred
> formats?

+1. This approach seems more easily parseable than HTTPish headers
(especially given questions about how complete one's HTTP parser needs
to be). However, if we're going to have a simple key-value format, why
not use JSON instead of defining something new? (And yes, I'm an XML guy
myself...)

Peter

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



From wmills@yahoo-inc.com  Mon May 14 15:38:25 2012
Return-Path: 
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 417BC21F88ED for ; Mon, 14 May 2012 15:38:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.216
X-Spam-Level: 
X-Spam-Status: No, score=-17.216 tagged_above=-999 required=5 tests=[AWL=0.382, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15]
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 QiNuudEgneBs for ; Mon, 14 May 2012 15:38:24 -0700 (PDT)
Received: from nm9.bullet.mail.sp2.yahoo.com (nm9.bullet.mail.sp2.yahoo.com [98.139.91.79]) by ietfa.amsl.com (Postfix) with SMTP id 7B2D821F8901 for ; Mon, 14 May 2012 15:38:24 -0700 (PDT)
Received: from [98.139.91.66] by nm9.bullet.mail.sp2.yahoo.com with NNFMP; 14 May 2012 22:38:21 -0000
Received: from [98.139.91.47] by tm6.bullet.mail.sp2.yahoo.com with NNFMP; 14 May 2012 22:37:21 -0000
Received: from [127.0.0.1] by omp1047.mail.sp2.yahoo.com with NNFMP; 14 May 2012 22:37:21 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 769552.49348.bm@omp1047.mail.sp2.yahoo.com
Received: (qmail 5153 invoked by uid 60001); 14 May 2012 22:37:21 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1337035041; bh=ppy4eF1pd06qPMyS+6TkkJSp/G5LZnQ+lqPomSb+1i8=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=VtHGUpqDLvzuxigG7oRu2gkIAin2XXwVdWHIMFc8UyxRtL0hR+3gvdkIvV3F7wQIR4SyPcWA43iVse2htXOuVCuXe87jteFFxPbSdFhsiYzALsweB/b/TvReGR4hM+EjsS8v9LLT69VDazcaJT8myXpujWR2euqNLdM673SEOkE=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=SJDgZ6gMfU6d4AktRZN4AYuzKUIRPTchf4lNxn8pl9S/BCsXuOr2O7vXH6Na14Qf3ShH3TW7J/Fa9tQ44cI83U59bxmHEOFPSDAm5RN2PIjJ/54Yw4C6HSber9DA7GA6sIF+vZ1wMrRq0hAMWVO5s7Ggrj29nZWM8xabnX24u34=;
X-YMail-OSG: zTtQblAVM1l_mtY9xHhHjljwmbAX2zDH1abdVY4GU_5QmTm VS0w7uydhTZFaDMnTQWPz5c1CQRbzr4eopCFariTvH3FXMiTet4ApZBxu06M UqGwF4zbgJVJWR0arqcFCpqoLtxEkdurTdD23f.u7BWPC87wu_cw3aot5E_B AaFsUluDVzYziAQKgncneyVmNHmtN71U2NSqzKOWtSQh1YM30ofBtHsHDD1Y rJnVlpP9.FWD8OpFRrM4XWl9f0zgMOwHOWi5s7qk_gfDkFkvIklLi_qRorsO .UBJtwsqCSiSOZWGaI1O3y1zXDg1jRwiBVh_Jy1YPjmS6RkZRDm_.5Gvx8kl S2Ua.fkm51TLmoCet0mxAQMS7rYzcNd5qYd3Vz4mhqdXs0NYiQADMnwx53r6 6KK7lfjPosLg4LF6THfxKfQRiHB.jqe74HjxXl_O7RjxeNA1oHi3mUb38Rku 3ynVNi7xkoWWiv2jw1CR8jm0wMEiI2Mkl2x34dibfBHo4
Received: from [209.131.62.120] by web31811.mail.mud.yahoo.com via HTTP; Mon, 14 May 2012 15:37:20 PDT
X-RocketYMMF: william_john_mills
X-Mailer: YahooMailWebService/0.8.118.349524
References: <1337032743.59474.YahooMailNeo@web31806.mail.mud.yahoo.com> <4FB1828D.2080404@stpeter.im>
Message-ID: <1337035040.62404.YahooMailNeo@web31811.mail.mud.yahoo.com>
Date: Mon, 14 May 2012 15:37:20 -0700 (PDT)
From: William Mills 
To: Peter Saint-Andre 
In-Reply-To: <4FB1828D.2080404@stpeter.im>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="764183289-1979944025-1337035040=:62404"
Cc: "kitten@ietf.org" 
Subject: Re: [kitten] OAUTH/SASL and the format debate
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: William Mills 
List-Id: Common Authentication Technologies - Next Generation 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 May 2012 22:38:25 -0000

--764183289-1979944025-1337035040=:62404
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

I don't have a preference.=A0 The key value format is easier to parse.=A0 J=
SON has libraries.=0A=0AFolks please weigh in with JSON vs. KV votes please=
.=0A=0AThanks,=0A=0A-bill=0A=0A=0A=0A=0A>________________________________=
=0A> From: Peter Saint-Andre =0A>To: William Mills  =0A>Cc: "kitten@ietf.org"  =0A>Sent: Mo=
nday, May 14, 2012 3:09 PM=0A>Subject: Re: [kitten] OAUTH/SASL and the form=
at debate=0A> =0A>On 5/14/12 3:59 PM, William Mills wrote:=0A>> Having inqu=
ired of a number of folks that have implemented the XOAUTH=0A>> mechanism a=
nd getting no reply, I'm planning to go with "silence =3D=3D=0A>> consent" =
and presume there's no big objection to moving away form the=0A>> HTTP form=
at style for the SASL messages.=A0 I' planning on a key/value=0A>> pair for=
mat, which is easily extensible.=A0 My plan was something like:=0A>> =0A>>=
=A0 =A0  NONZERO ::=3D %x31-39=0A>>=A0 =A0  key ::=3D NONZERO *DIGIT =0A>>=
=A0 =A0  value ::=3D *(SP HTAB VCHAR)=0A>>=A0 =A0  msg_line ::=3D key SP va=
lue CRLF=0A>>=A0 =A0  sasl_msg ::=3D +msg_line CRLF=0A>> =0A>> We would nee=
d an IANA registry for keys.=A0 Objections?=A0 Other preferred=0A>> formats=
?=0A>=0A>+1. This approach seems more easily parseable than HTTPish headers=
=0A>(especially given questions about how complete one's HTTP parser needs=
=0A>to be). However, if we're going to have a simple key-value format, why=
=0A>not use JSON instead of defining something new? (And yes, I'm an XML gu=
y=0A>myself...)=0A>=0A>Peter=0A>=0A>-- =0A>Peter Saint-Andre=0A>https://stp=
eter.im/=0A>=0A>=0A>=0A>=0A>
--764183289-1979944025-1337035040=:62404
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable


I don't have a preference.  The key value format is easier to parse.=
  JSON has libraries.

Folks please weigh in with JSON vs. KV votes please.
Thanks,

-bill
<=
/span>

  
 
 
  
  From: Pe=
ter Saint-Andre <stpeter@stpeter.im>
 To: William Mills <wmills@yahoo-inc.com> 
Cc: "kitten@ietf.org" <kitte=
n@ietf.org> 
 Sent: =
Monday, May 14, 2012 3:09 PM
 Subj=
ect: Re: [kitten] OAUTH/SASL and the format debate
  <=
/div> 
=0AOn 5/14/12 3:59 PM, William Mills wrote:
> Having inquir=
ed of a number of folks that have implemented the XOAUTH
> mechanism =
and getting no reply, I'm planning to go with "silence =3D=3D
> conse=
nt" and presume there's no big objection to moving away form the
> HT=
TP format style for the SASL messages.  I' planning on a key/value
=
> pair format, which is easily extensible.  My plan was something l=
ike:
> 
>     NONZERO ::=3D %x31-39
>  &nb=
sp;  key ::=3D NONZERO *DIGIT 
>     value ::=3D *(SP HTAB =
VCHAR)
>     msg_line ::=3D key SP value CRLF
> =
    sasl_msg ::=3D +msg_line CRLF
> 
> We would need an IA=
NA registry for keys.  Objections?  Other preferred
> forma=
ts?

+1. This approach seems more easily parseable than HTTPish heade=
rs
(especially given questions about how complete one's HTTP parser need=
s
to be).
 However, if we're going to have a simple key-value format, why
not use =
JSON instead of defining something new? (And yes, I'm an XML guy
myself.=
..)

Peter

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




  
 
   

--764183289-1979944025-1337035040=:62404--

From wmills@yahoo-inc.com  Mon May 14 17:02:39 2012
Return-Path: 
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81CAC21F8942 for ; Mon, 14 May 2012 17:02:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.927
X-Spam-Level: 
X-Spam-Status: No, score=-15.927 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_50=0.001, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15]
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 bG-bNBznZPlp for ; Mon, 14 May 2012 17:02:39 -0700 (PDT)
Received: from nm28-vm4.bullet.mail.ne1.yahoo.com (nm28-vm4.bullet.mail.ne1.yahoo.com [98.138.91.188]) by ietfa.amsl.com (Postfix) with SMTP id C3AE121F8941 for ; Mon, 14 May 2012 17:02:38 -0700 (PDT)
Received: from [98.138.90.51] by nm28.bullet.mail.ne1.yahoo.com with NNFMP; 15 May 2012 00:02:38 -0000
Received: from [98.138.87.7] by tm4.bullet.mail.ne1.yahoo.com with NNFMP; 15 May 2012 00:02:38 -0000
Received: from [127.0.0.1] by omp1007.mail.ne1.yahoo.com with NNFMP; 15 May 2012 00:02:38 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 372840.55111.bm@omp1007.mail.ne1.yahoo.com
Received: (qmail 6499 invoked by uid 60001); 15 May 2012 00:02:37 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1337040157; bh=K3W9LAVsxANMZmEdSojLKUs+s/ZjIHWBf9YLgVn8atc=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=T+9JjXv3XBpKtwtvHaJHLfuzzIVvEgAd3FEduymU5VS2usLSyqeiv7Uy0hvA1sTBjbnzA2l87II0pw7bTmNojS2BH7VOcXbW1qtqO3EIyFDc+QhD1I2EEOMIxrRASeCqAdS6AFuo7/516aAgip4Wx6FwM6TAhINWs9oiT3i9SIs=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=PlAOPWekICmsYLP50T09ZHKhSZZXkhsgDgcT30bUjcaWtjJ5YW6KVCO4/N3P/Pt05LU9S5J0o/XfWmj7BNk7V3iDApFr3DLzRe35VyMclsjoRodxnBpIcBGt3KKwx5mfKfS3KGnFD1waI8qq0z6KEgGFuLzYiWGF2gKnh2cbvwU=;
X-YMail-OSG: d104VR8VM1nhiS4aCRYtvbcoFJGYzP1tk_pS5wrESwEFwUU zgw7.OATT3cKwJYHRdIbzYd18OK46b2gg8FpPIDG5B74benEl9qrInrXxVWz SROiKe.jZY_Itm.iRs0UGmSVAcspu532jT363ubWshSpIo_DlmWKm.GEzpJF 0UQC7RxQOcarU6Y5D3vComuwGQx_tdnER2IGYcgLOa_wEItN0r9fBfNGTVv0 nTrO1xoyBV9XQF1qs0QIs2iWu6mXp2UFHTmx6kL8a16d_qk6JpiY6wKn1xJi Ff76WcYfAzlxBOdJdBrCOGt0aGqHFSyDt0AePPh8mgQSIH8wUvWuIKpuNE9E .oHw8PgkeAz2.g7DW4yYWZMW_SCGSJemX.CAM_4Xj7p6yyX4..hdST_9iRy. YamobbWW3LuC4qC7YQJz9ocsunO7C4W3W
Received: from [209.131.62.115] by web31809.mail.mud.yahoo.com via HTTP; Mon, 14 May 2012 17:02:37 PDT
X-RocketYMMF: william_john_mills
X-Mailer: YahooMailWebService/0.8.118.349524
Message-ID: <1337040157.1064.YahooMailNeo@web31809.mail.mud.yahoo.com>
Date: Mon, 14 May 2012 17:02:37 -0700 (PDT)
From: William Mills 
To: "kitten@ietf.org" 
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="-1395015409-1825650508-1337040157=:1064"
Subject: [kitten] channel binding?
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: William Mills 
List-Id: Common Authentication Technologies - Next Generation 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 May 2012 00:02:39 -0000

---1395015409-1825650508-1337040157=:1064
Content-Type: text/plain; charset=us-ascii

What's the prevailing wisdom on channel binding, is it still the case that we SHOULD define SASL mechanisms that support channel binding along with non-bound ones?

Thanks,

-bill

---1395015409-1825650508-1337040157=:1064
Content-Type: text/html; charset=us-ascii


What's the prevailing wisdom on channel binding, is it still the case that we SHOULD define SASL mechanisms that support channel binding along with non-bound ones?

Thanks,

-bill

---1395015409-1825650508-1337040157=:1064--

From nico@cryptonector.com  Mon May 14 19:04:30 2012
Return-Path: 
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFD5E21F892B for ; Mon, 14 May 2012 19:04:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.812
X-Spam-Level: 
X-Spam-Status: No, score=-1.812 tagged_above=-999 required=5 tests=[AWL=0.165,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
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 0yuhgabDFQ6t for ; Mon, 14 May 2012 19:04:29 -0700 (PDT)
Received: from homiemail-a95.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id 77FF921F889F for ; Mon, 14 May 2012 19:04:29 -0700 (PDT)
Received: from homiemail-a95.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTP id D5B921E2B0 for ; Mon, 14 May 2012 19:04:28 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=YdA+20fmwe6avDQqYlfPr cPh2m5NlQsbH/K/FISytshr6Y7vyIPKbpw+CXxHjOgu8pKIsnqxJA4Lk3XVjE11N vCfJb1RLl5NxSmBXYUqhejCu8rcDUhIGODrsWik4QdF8tIkQjbYcyMiAYIeoTUqo wRQWNhwRcuBRtoVljv7utE=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=Cdby2WCygvdsgLp0NV++ y3w/SNw=; b=Nl7ba1Y3d10EmGh4yg3LvO+yykuQXHwuKd7lHZ/yBHZ7uB9DqI5f huUfBdL/J+Myriq0/eEeF59AdZ6KxmgGZdDS/wz5gvoPHQnK/5lSl8M7LVvh5g9j TwrHBR12lUwA0+crznpfEWXsD45PZlASfoM6nvOQPTm0hO82tpCU+6s=
Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTPSA id C4B3A1E2AA for ; Mon, 14 May 2012 19:04:28 -0700 (PDT)
Received: by dacx6 with SMTP id x6so6866689dac.31 for ; Mon, 14 May 2012 19:04:28 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.68.132.34 with SMTP id or2mr337203pbb.118.1337047468306; Mon, 14 May 2012 19:04:28 -0700 (PDT)
Received: by 10.68.5.99 with HTTP; Mon, 14 May 2012 19:04:28 -0700 (PDT)
In-Reply-To: <1337040157.1064.YahooMailNeo@web31809.mail.mud.yahoo.com>
References: <1337040157.1064.YahooMailNeo@web31809.mail.mud.yahoo.com>
Date: Mon, 14 May 2012 21:04:28 -0500
Message-ID: 
From: Nico Williams 
To: William Mills 
Content-Type: text/plain; charset=UTF-8
Cc: "kitten@ietf.org" 
Subject: Re: [kitten] channel binding?
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Common Authentication Technologies - Next Generation 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 May 2012 02:04:30 -0000

On Mon, May 14, 2012 at 7:02 PM, William Mills  wrote:
> What's the prevailing wisdom on channel binding, is it still the case that
> we SHOULD define SASL mechanisms that support channel binding along with
> non-bound ones?

Very much so, yes.  But that doesn't mean that you can't create new
SASL mechanisms that can't do channel binding.  The key is that if a
mechanism could support it given its fundamentals, then it must
support it.

Nico
--

From simon@josefsson.org  Tue May 15 06:54:08 2012
Return-Path: 
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F48D21F89CE for ; Tue, 15 May 2012 06:54:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.527
X-Spam-Level: 
X-Spam-Status: No, score=-99.527 tagged_above=-999 required=5 tests=[AWL=-0.218, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, J_CHICKENPOX_35=0.6, USER_IN_WHITELIST=-100]
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 Zccwuvth1l5Y for ; Tue, 15 May 2012 06:54:07 -0700 (PDT)
Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id 7CFB221F89DA for ; Tue, 15 May 2012 06:54:06 -0700 (PDT)
Received: from latte (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q4FDrrko009747 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 15 May 2012 15:53:54 +0200
From: Simon Josefsson 
To: William Mills 
References: <1337032743.59474.YahooMailNeo__29027.4895648055$1337032752$gmane$org@web31806.mail.mud.yahoo.com>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:120515:wmills@yahoo-inc.com::TQcp8+LQ9Q+dN4hp:CdCL
X-Hashcash: 1:22:120515:kitten@ietf.org::gt+itNDs9pW72XVi:dlYE
Date: Tue, 15 May 2012 15:53:53 +0200
In-Reply-To: <1337032743.59474.YahooMailNeo__29027.4895648055$1337032752$gmane$org@web31806.mail.mud.yahoo.com> (William Mills's message of "Mon, 14 May 2012 14:59:03 -0700 (PDT)")
Message-ID: <87zk99czym.fsf@latte.josefsson.org>
User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/23.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.97.3 at yxa-v
X-Virus-Status: Clean
Cc: "kitten@ietf.org" 
Subject: Re: [kitten] OAUTH/SASL and the format debate
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Common Authentication Technologies - Next Generation 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 May 2012 13:54:08 -0000

William Mills  writes:

> Having inquired of a number of folks that have implemented the XOAUTH
> mechanism and getting no reply, I'm planning to go with "silence ==
> consent" and presume there's no big objection to moving away form the
> HTTP format style for the SASL messages.  I' planning on a key/value
> pair format, which is easily extensible.  My plan was something like:

Great.  I like a key=value approach.  To me, it is better than JSON
since it is easier to parse when you don't have external libraries
available.

>     NONZERO ::=  %x31-39
>     key ::= NONZERO *DIGIT 
>     value ::= *(SP HTAB VCHAR)
>
>     msg_line ::= key SP value CRLF
>     sasl_msg ::= +msg_line CRLF
>
> We would need an IANA registry for keys.  Objections?  Other preferred
> formats?

Why digits as keys?  Some consistency with RFC 5801/RFC5802 would be
nice, so how about something like the following, in pseudo ABNF/regexp
language:

   key = [A-Za-z0-9_-]+
   value = [^,]*
   kvpair = key "=" value
   msg = kvpair ("," kvpair)*

This allows descriptive names for the "key" names.

/Simon

From simon@josefsson.org  Tue May 15 06:58:13 2012
Return-Path: 
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 123FA21F85F0 for ; Tue, 15 May 2012 06:58:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.82
X-Spam-Level: 
X-Spam-Status: No, score=-99.82 tagged_above=-999 required=5 tests=[AWL=0.089,  BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553,  HOST_EQ_STATICB=1.372, USER_IN_WHITELIST=-100]
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 dflyhHVwnEUk for ; Tue, 15 May 2012 06:58:12 -0700 (PDT)
Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id 229E821F8686 for ; Tue, 15 May 2012 06:58:11 -0700 (PDT)
Received: from latte (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q4FDve0J009970 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 15 May 2012 15:57:48 +0200
From: Simon Josefsson 
To: Nico Williams 
References: <1337040157.1064.YahooMailNeo@web31809.mail.mud.yahoo.com> 
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:120515:nico@cryptonector.com::ksCV9PyoiT1W5TLX:21Ba
X-Hashcash: 1:22:120515:kitten@ietf.org::jJdtv6PuJQ5d4QWS:FYKZ
X-Hashcash: 1:22:120515:wmills@yahoo-inc.com::ozFK6ADQvPY+G6NB:GAAt
Date: Tue, 15 May 2012 15:57:40 +0200
In-Reply-To:  (Nico Williams's message of "Mon, 14 May 2012 21:04:28 -0500")
Message-ID: <87vcjxczsb.fsf@latte.josefsson.org>
User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/23.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Virus-Scanned: clamav-milter 0.97.3 at yxa-v
X-Virus-Status: Clean
Cc: "kitten@ietf.org" 
Subject: Re: [kitten] channel binding?
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Common Authentication Technologies - Next Generation 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 May 2012 13:58:13 -0000

Nico Williams  writes:

> On Mon, May 14, 2012 at 7:02 PM, William Mills  wrote:
>> What's the prevailing wisdom on channel binding, is it still the case that
>> we SHOULD define SASL mechanisms that support channel binding along with
>> non-bound ones?
>
> Very much so, yes.  But that doesn't mean that you can't create new
> SASL mechanisms that can't do channel binding.  The key is that if a
> mechanism could support it given its fundamentals, then it must
> support it.

+1

What hasn't been clear to me if there is any way to achieve channel
binding with OAuth.  Possibly it is in a similar situation as SAML which
resulted in the two SASL mechanisms SAML20 and SAML20EC, namely, that
the traditional and most common deployment of the protocol does not
easily support it, but it may be possible to use some extension to
achieve channel bindings.  If this is the case, I think it would be nice
if both variants could be achieved within the same SASL mechanism.
Unless that becomes very ugly.  If it becomes ugly, it may be simpler to
have two SASL mechanisms that each become less complex.

/Simon

From wmills@yahoo-inc.com  Tue May 15 08:53:59 2012
Return-Path: 
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 127CB21F8939 for ; Tue, 15 May 2012 08:53:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.901
X-Spam-Level: 
X-Spam-Status: No, score=-15.901 tagged_above=-999 required=5 tests=[AWL=-0.903, BAYES_50=0.001, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15]
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 sKQKdHshLnb4 for ; Tue, 15 May 2012 08:53:58 -0700 (PDT)
Received: from nm27-vm0.bullet.mail.sp2.yahoo.com (nm27-vm0.bullet.mail.sp2.yahoo.com [98.139.91.232]) by ietfa.amsl.com (Postfix) with SMTP id 3B8C821F886F for ; Tue, 15 May 2012 08:53:58 -0700 (PDT)
Received: from [72.30.22.92] by nm27.bullet.mail.sp2.yahoo.com with NNFMP; 15 May 2012 15:53:53 -0000
Received: from [72.30.22.76] by tm14.bullet.mail.sp2.yahoo.com with NNFMP; 15 May 2012 15:53:53 -0000
Received: from [127.0.0.1] by omp1070.mail.sp2.yahoo.com with NNFMP; 15 May 2012 15:53:53 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 290267.54173.bm@omp1070.mail.sp2.yahoo.com
Received: (qmail 66759 invoked by uid 60001); 15 May 2012 15:53:52 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1337097232; bh=/oh7yv/UuuB7OyUtcv4HP2PL5A+g2mePiMU6iQ9PrXQ=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=aYTS5FsFR98FeW9Y/HOmL9dxhS3U8SMIAQajFxwnhtqrpNNmGQROSsq5flbbNzX36SwR4FcczrIfwn3+gCeHw+B3y6VKHw0gGHgLacox/BLuc4AByrEgn5K6adEJ30UYT7NtBshpMkxjpr92dOvNsCPKx81QEElObB282ki7l/4=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=C2Whf+MoNoQjASdXDTnlk+ZbKoYfmyZSsW7P0D+B/KOCPHb0btNX8wjP+zuJ3Kxe2wr7QQrnki+DXqQLbMFWidLWpbH2PAzEPFXLnN5o8U2ITD1Do6L+MeqP5LBMSULCr/dvhYn6LSqWr8PKNhZZQKQlBvZWZDIoY0mVUkoSVBM=;
X-YMail-OSG: KoU47vgVM1lAoHBKzVjYZjiNCnDVv5jtZ.q2rSOjAWSFWTE rYUXqIq9sxmBcgcELDqc6hNjjgdRZSzuA3i2CI519PGzgwnwY0WF3CtMfknO LV8cZZtNOQ1NaitbzNrT1dpdc_K4GO6UIM_aEEn02CcNCTMlwjdQd2DLT_wf qflzv3QdmixxZl49BcD_gukoDbzv6yAYfBlpYGteLE1Y_gzqI0D927E5KUKm HHroCVvmZkTWUa1dGr7z63nsQ.rJVPveTDXK61XxJvuNXlT_3c2zc7EcqPua HUfbXdoGmRzvR1CfW8lg86yJcjeudjv_ltwf1RkHW3qXbloqNed8tZ3t6Bvn U2.Rv08TZIpNt6xLULh1Iqe4CNuX.X7v0Kc8tvhcK.GnG4DD8EpgmdehQ7dC XShgSJRbd2U5ts0ypv0w9dwK_9pQ0USXW0YLjkfHhtMT0Q3Z6gA--
Received: from [209.131.62.115] by web31816.mail.mud.yahoo.com via HTTP; Tue, 15 May 2012 08:53:52 PDT
X-RocketYMMF: william_john_mills
X-Mailer: YahooMailWebService/0.8.118.349524
References: <1337040157.1064.YahooMailNeo@web31809.mail.mud.yahoo.com>  <87vcjxczsb.fsf@latte.josefsson.org>
Message-ID: <1337097232.42738.YahooMailNeo@web31816.mail.mud.yahoo.com>
Date: Tue, 15 May 2012 08:53:52 -0700 (PDT)
From: William Mills 
To: Simon Josefsson , Nico Williams 
In-Reply-To: <87vcjxczsb.fsf@latte.josefsson.org>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="-1238014912-948274361-1337097232=:42738"
Cc: "kitten@ietf.org" 
Subject: Re: [kitten] channel binding?
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: William Mills 
List-Id: Common Authentication Technologies - Next Generation 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 May 2012 15:53:59 -0000

---1238014912-948274361-1337097232=:42738
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

I'd prefer to go with two mechanisms.=A0 It makes the logic MUCH simpler.=
=A0 Policy is then implemented by the mechanism you advertise.=0A=0A-bill=
=0A=0A=0A=0A=0A>________________________________=0A> From: Simon Josefsson =
=0A>To: Nico Williams  =0A>Cc: =
William Mills ; "kitten@ietf.org"  =
=0A>Sent: Tuesday, May 15, 2012 6:57 AM=0A>Subject: Re: channel binding?=0A=
> =0A>Nico Williams  writes:=0A>=0A>> On Mon, May 14=
, 2012 at 7:02 PM, William Mills  wrote:=0A>>> What's=
 the prevailing wisdom on channel binding, is it still the case that=0A>>> =
we SHOULD define SASL mechanisms that support channel binding along with=0A=
>>> non-bound ones?=0A>>=0A>> Very much so, yes.=A0 But that doesn't mean t=
hat you can't create new=0A>> SASL mechanisms that can't do channel binding=
.=A0 The key is that if a=0A>> mechanism could support it given its fundame=
ntals, then it must=0A>> support it.=0A>=0A>+1=0A>=0A>What hasn't been clea=
r to me if there is any way to achieve channel=0A>binding with OAuth.=A0 Po=
ssibly it is in a similar situation as SAML which=0A>resulted in the two SA=
SL mechanisms SAML20 and SAML20EC, namely, that=0A>the traditional and most=
 common deployment of the protocol does not=0A>easily support it, but it ma=
y be possible to use some extension to=0A>achieve channel bindings.=A0 If t=
his is the case, I think it would be nice=0A>if both variants could be achi=
eved within the same SASL mechanism.=0A>Unless that becomes very ugly.=A0 I=
f it becomes ugly, it may be simpler to=0A>have two SASL mechanisms that ea=
ch become less complex.=0A>=0A>/Simon=0A>=0A>=0A>
---1238014912-948274361-1337097232=:42738
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable


I'd prefer to go with two mechanisms.  It makes the logic MUCH simpl=
er.  Policy is then implemented by the mechanism you advertise.=


-bill
  
 
 
  
  <=
b>From: Simon Josefsson <si=
mon@josefsson.org>
 To:<=
/b> Nico Williams <nico@cryptonector.com> 
Cc: William Mills <wmills@YAHOO-INC.COM>; "kitten@=
ietf.org" <kitten@ietf.org> 
 Subject: Re: channel binding?
  
=
 
=0ANico Williams <nico@cryptonector.com> writes:
=

> On Mon, May 14, 2012 at 7:02 PM, William Mills <wmills@yah=
oo-inc.com> wrote:
>> What's the prevailing wisdom on chann=
el binding, is it still the case that
>> we SHOULD define SASL mec=
hanisms that support channel binding along with
>> non-bound ones?=

>
> Very much so, yes.  But that doesn't mean that you ca=
n't create new
> SASL mechanisms that can't do channel binding. =
 The key is that if a
> mechanism could support it given its fundamen=
tals, then it must
> support it.

+1

What hasn't been cl=
ear to me if there is any way to achieve channel
binding with OAuth.&nbs=
p; Possibly it is in a similar situation as SAML which
resulted in the t=
wo SASL
 mechanisms SAML20 and SAML20EC, namely, that
the traditional and most c=
ommon deployment of the protocol does not
easily support it, but it may =
be possible to use some extension to
achieve channel bindings.  If =
this is the case, I think it would be nice
if both variants could be ach=
ieved within the same SASL mechanism.
Unless that becomes very ugly.&nbs=
p; If it becomes ugly, it may be simpler to
have two SASL mechanisms tha=
t each become less complex.

/Simon


 
 
 
   

---1238014912-948274361-1337097232=:42738--

From wmills@yahoo-inc.com  Tue May 15 09:00:14 2012
Return-Path: 
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12BD321F8990 for ; Tue, 15 May 2012 09:00:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -16.877
X-Spam-Level: 
X-Spam-Status: No, score=-16.877 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, USER_IN_DEF_WHITELIST=-15]
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 3125UPLw1hpV for ; Tue, 15 May 2012 09:00:13 -0700 (PDT)
Received: from nm9-vm0.bullet.mail.ac4.yahoo.com (nm9-vm0.bullet.mail.ac4.yahoo.com [98.139.53.192]) by ietfa.amsl.com (Postfix) with SMTP id B1BDD21F8999 for ; Tue, 15 May 2012 09:00:12 -0700 (PDT)
Received: from [98.139.52.194] by nm9.bullet.mail.ac4.yahoo.com with NNFMP; 15 May 2012 16:00:09 -0000
Received: from [98.139.52.180] by tm7.bullet.mail.ac4.yahoo.com with NNFMP; 15 May 2012 16:00:09 -0000
Received: from [127.0.0.1] by omp1063.mail.ac4.yahoo.com with NNFMP; 15 May 2012 16:00:09 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 12663.28554.bm@omp1063.mail.ac4.yahoo.com
Received: (qmail 45099 invoked by uid 60001); 15 May 2012 16:00:08 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1337097608; bh=WQcGDt49mXSXLQOsxQsq5kPga2q7hOwER5zaTX6ipZI=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=ObR5JC1rhlCl4eTQVIFtL+6pm7Pzz6NJKtVwxjISevbSOtAWqqLUzb+pqH1EHeTtqQR5s4mLvgPRMvveZjxBfAdf5gdZxSl7NGMdgYqU+88NX2iZnS5TniP69simFTaICERBPAsL9T4qZHB8CbgKfi9zXd9P0uib/jQZAi+JKXY=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=XoO/K4j7tfYByqBqO3ECnO4L86atDghZwiO9G1y41aQB0+o4RV8Wu6hNPGniUQ4PVe0uDd4o40nKFtmBmnW+KkvAXTRje5VCgmNyd8K/4ght9FzQK/VmLGglsStDDbaYnEmqTk+keN/twNmGWdg0Zs0nMi34bFVpRc98D1Y4BwE=;
X-YMail-OSG: AvWxc1cVM1nD5iaeFcJ8sBPbS5S7Wq0rEWXjNdRQWzPhgFV kmxHvaIrW.H9f2vhJgxNF_dRvGoHFf9tWhOlnJhBZiiFscaF.NGuN0xxJbQ6 3HoyXpBnK9vW5Adfw4MrfPFUAp0ewvDD4RCDXc.BenyZmgFRCDHFs5ubYN33 rZ_7ARV7bDIgdSd8cQSyto1iha0zqeZ7aqx1P3SgP0YmtsOZKiyFI8oUJekg 5NyLvk2uqdl2UtwjwdcoZMJj1UkmskEQBp59MQAbPmS0FhFKmgk28Jq0ubdO QripYILpUbEwo.UyDHBWUIQyai3vXAEOYLOA2bQoFQY7YJiTE44hmI2l3NY7 YZ2DJC1.F0zhV8zGoIOOyIKdmraOikaxfohpqJ8fJ.rGcik8yM6bDsS2ijL1 18EBfgB9e7MKDpEiyVHm3TwK7MlBwbS4znDs8fF04SXPzyRGgNvo-
Received: from [209.131.62.115] by web31812.mail.mud.yahoo.com via HTTP; Tue, 15 May 2012 09:00:08 PDT
X-RocketYMMF: william_john_mills
X-Mailer: YahooMailWebService/0.8.118.349524
References: <1337032743.59474.YahooMailNeo__29027.4895648055$1337032752$gmane$org@web31806.mail.mud.yahoo.com> <87zk99czym.fsf@latte.josefsson.org>
Message-ID: <1337097608.40079.YahooMailNeo@web31812.mail.mud.yahoo.com>
Date: Tue, 15 May 2012 09:00:08 -0700 (PDT)
From: William Mills 
To: Simon Josefsson 
In-Reply-To: <87zk99czym.fsf@latte.josefsson.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "kitten@ietf.org" 
Subject: Re: [kitten] OAUTH/SASL and the format debate
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: William Mills 
List-Id: Common Authentication Technologies - Next Generation 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 May 2012 16:00:14 -0000

>________________________________=0A> From: Simon Josefsson =0A>To: William Mills  =0A>Cc: "kitten@ietf.org=
"  =0A>Sent: Tuesday, May 15, 2012 6:53 AM=0A>Subject: Re:=
 OAUTH/SASL and the format debate=0A> =0A>William Mills  writes:=0A>=0A>> Having inquired of a number of folks that have impleme=
nted the XOAUTH=0A>> mechanism and getting no reply, I'm planning to go wit=
h "silence =3D=3D=0A>> consent" and presume there's no big objection to mov=
ing away form the=0A>> HTTP format style for the SASL messages.=A0 I' plann=
ing on a key/value=0A>> pair format, which is easily extensible.=A0 My plan=
 was something like:=0A>=0A>Great.=A0 I like a key=3Dvalue approach.=A0 To =
me, it is better than JSON=0A>since it is easier to parse when you don't ha=
ve external libraries=0A>available.=0A>=0A>> =A0=A0=A0 NONZERO ::=3D=A0 %x3=
1-39=0A>> =A0=A0=A0 key ::=3D NONZERO *DIGIT=A0=0A>> =A0=A0=A0 value ::=3D =
*(SP HTAB VCHAR)=0A>>=0A>> =A0=A0=A0 msg_line ::=3D key SP value CRLF=0A>> =
=A0=A0=A0 sasl_msg ::=3D +msg_line CRLF=0A>>=0A>> We would need an IANA reg=
istry for keys.=A0 Objections?=A0 Other preferred=0A>> formats?=0A>=0A>Why =
digits as keys?=A0 Some consistency with RFC 5801/RFC5802 would be=0A>nice,=
 so how about something like the following, in pseudo ABNF/regexp=0A>langua=
ge:=0A>=0A>=A0=A0=A0key =3D [A-Za-z0-9_-]+=0A>=A0=A0=A0value =3D [^,]*=0A>=
=A0=A0=A0kvpair =3D key "=3D" value=0A>=A0=A0=A0msg =3D kvpair ("," kvpair)=
*=0A>=0A>This allows descriptive names for the "key" names.=0A=0A=0ADescrip=
tive key names I like.=A0 "=3D" instead of "SP" is fine too.=A0 Comma separ=
ated means that the authorization header value will have to be base64 encod=
ed, and I'm not sure I'm a big fan of that.=A0 CRLF won't appear in the aut=
h header.=0A=0ARe-using the parser from 5801/5802 is attractive though.=A0 =
Not sure what I prefer there.=0A=0A=0A>=0A>/Simon=0A>=0A>=0A>

From stpeter@stpeter.im  Tue May 15 09:12:46 2012
Return-Path: 
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC7AC21F85C7 for ; Tue, 15 May 2012 09:12:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.552
X-Spam-Level: 
X-Spam-Status: No, score=-102.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 58hHSsAz+b2Z for ; Tue, 15 May 2012 09:12:46 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id E06C221F85C0 for ; Tue, 15 May 2012 09:12:45 -0700 (PDT)
Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id B7DC84005A; Tue, 15 May 2012 10:28:25 -0600 (MDT)
Message-ID: <4FB2807A.6010008@stpeter.im>
Date: Tue, 15 May 2012 10:12:42 -0600
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Simon Josefsson 
References: <1337040157.1064.YahooMailNeo@web31809.mail.mud.yahoo.com>  <87vcjxczsb.fsf@latte.josefsson.org>
In-Reply-To: <87vcjxczsb.fsf@latte.josefsson.org>
X-Enigmail-Version: 1.4.1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: "kitten@ietf.org" 
Subject: Re: [kitten] channel binding?
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Common Authentication Technologies - Next Generation 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 May 2012 16:12:47 -0000

On 5/15/12 7:57 AM, Simon Josefsson wrote:
> Nico Williams  writes:
> 
>> On Mon, May 14, 2012 at 7:02 PM, William Mills  wrote:
>>> What's the prevailing wisdom on channel binding, is it still the case that
>>> we SHOULD define SASL mechanisms that support channel binding along with
>>> non-bound ones?
>>
>> Very much so, yes.  But that doesn't mean that you can't create new
>> SASL mechanisms that can't do channel binding.  The key is that if a
>> mechanism could support it given its fundamentals, then it must
>> support it.
> 
> +1
> 
> What hasn't been clear to me if there is any way to achieve channel
> binding with OAuth.  Possibly it is in a similar situation as SAML which
> resulted in the two SASL mechanisms SAML20 and SAML20EC, namely, that
> the traditional and most common deployment of the protocol does not
> easily support it, but it may be possible to use some extension to
> achieve channel bindings. 

I think that's right for the OAuth case.

> If this is the case, I think it would be nice
> if both variants could be achieved within the same SASL mechanism.
> Unless that becomes very ugly.  If it becomes ugly, it may be simpler to
> have two SASL mechanisms that each become less complex.

No strong preference here.

Peter

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



From simon@josefsson.org  Tue May 15 09:33:46 2012
Return-Path: 
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A90B021F87C8 for ; Tue, 15 May 2012 09:33:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.823
X-Spam-Level: 
X-Spam-Status: No, score=-99.823 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, USER_IN_WHITELIST=-100]
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 41jdnXtJwXpH for ; Tue, 15 May 2012 09:33:45 -0700 (PDT)
Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id 6B47821F899E for ; Tue, 15 May 2012 09:33:45 -0700 (PDT)
Received: from latte (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q4FGXVfn016999 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 15 May 2012 18:33:32 +0200
From: Simon Josefsson 
To: William Mills 
References: <1337032743.59474.YahooMailNeo__29027.4895648055$1337032752$gmane$org@web31806.mail.mud.yahoo.com> <87zk99czym.fsf@latte.josefsson.org> <1337097608.40079.YahooMailNeo__47563.1773741499$1337097627$gmane$org@web31812.mail.mud.yahoo.com>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:120515:wmills@yahoo-inc.com::YrZFkgGFSA0SDL0P:A2Dk
X-Hashcash: 1:22:120515:kitten@ietf.org::/8CNumSU58HzMr15:V3q5
Date: Tue, 15 May 2012 18:33:30 +0200
In-Reply-To: <1337097608.40079.YahooMailNeo__47563.1773741499$1337097627$gmane$org@web31812.mail.mud.yahoo.com> (William Mills's message of "Tue, 15 May 2012 09:00:08 -0700 (PDT)")
Message-ID: <87y5otbe05.fsf@latte.josefsson.org>
User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/23.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.97.3 at yxa-v
X-Virus-Status: Clean
Cc: "kitten@ietf.org" 
Subject: Re: [kitten] OAUTH/SASL and the format debate
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Common Authentication Technologies - Next Generation 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 May 2012 16:33:46 -0000

William Mills  writes:

>>Why digits as keys?  Some consistency with RFC 5801/RFC5802 would be
>>nice, so how about something like the following, in pseudo ABNF/regexp
>>language:
>>
>>   key = [A-Za-z0-9_-]+
>>   value = [^,]*
>>   kvpair = key "=" value
>>   msg = kvpair ("," kvpair)*
>>
>>This allows descriptive names for the "key" names.
>
>
> Descriptive key names I like.  "=" instead of "SP" is fine too.  Comma
> separated means that the authorization header value will have to be
> base64 encoded, and I'm not sure I'm a big fan of that.  CRLF won't
> appear in the auth header.
>
> Re-using the parser from 5801/5802 is attractive though.  Not sure
> what I prefer there.

Is there some other character that isn't used in authorization headers
that could be used as a separator?

I also dislike having to base64 encode values if it can be avoided.
Another option is to escape "," but escaping is often troublesome as
well.

What I don't like about CRLF is that in some environments you may end up
combatting EOL conversions.  Also, doesn't some HTTP header allow
embedded CRLF as whitespace?

Another approach is to use ASCII NUL as separator.  The length is
implicit anyway, since you know when to stop parse.  That is:

key = [A-Za-z0-9_-]+
value = [^\00]*
kvpair = key "=" value
msg = kvpair (%x00 kvpair)*

This has the following properties:

* Easy to parse
* All non-NUL data values can be expressed (binary data with embedded
  NULs will have to be base64 encoded)
* No escaping
* You can use strlen and friends to find the end of the string to parse

/Simon

From wmills@yahoo-inc.com  Tue May 15 10:07:08 2012
Return-Path: 
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 269FA21F89C9 for ; Tue, 15 May 2012 10:07:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.994
X-Spam-Level: 
X-Spam-Status: No, score=-15.994 tagged_above=-999 required=5 tests=[AWL=-0.809, BAYES_40=-0.185, USER_IN_DEF_WHITELIST=-15]
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 g1aTCRlX2pad for ; Tue, 15 May 2012 10:07:07 -0700 (PDT)
Received: from nm30-vm0.bullet.mail.ne1.yahoo.com (nm30-vm0.bullet.mail.ne1.yahoo.com [98.138.91.69]) by ietfa.amsl.com (Postfix) with SMTP id 1AE3421F89B3 for ; Tue, 15 May 2012 10:07:07 -0700 (PDT)
Received: from [98.138.90.56] by nm30.bullet.mail.ne1.yahoo.com with NNFMP; 15 May 2012 17:07:04 -0000
Received: from [98.138.88.233] by tm9.bullet.mail.ne1.yahoo.com with NNFMP; 15 May 2012 17:07:04 -0000
Received: from [127.0.0.1] by omp1033.mail.ne1.yahoo.com with NNFMP; 15 May 2012 17:07:04 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 194894.75363.bm@omp1033.mail.ne1.yahoo.com
Received: (qmail 20922 invoked by uid 60001); 15 May 2012 17:07:03 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1337101623; bh=konD4FslLAq4HcwE4TNWbUAqh3414RHEI5bKdusH/uc=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=MwMmCeXBxyyK3Nsta5yms0US9xKtDb6ZmRLAvZSVMqegINHOCtW+4+HHJ0VoIfwG9nsmV/prCfIsv/+3c+QFFCic2JVY8YLeOh90PlLkzJmgTBqbCpZz8MNozrPQAUeyZxXdXbAdxMA0rB4JpCJEpDxnlISyqrnMmqcTcP4LeJk=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=OZKRmKKt02lHaOL1dwU+B1vvLbBRbkdTBsezBhMLVuTWipP1Ha0Lyxvi7TRvOTZLZRhsZ/EjWRzu8NSIawMRzNIlQbuMcoRHVrKavBte9vBhzjfx8gA5j9jf4W4o16idJVItA+9emeU05GdQWhy5LgV74e06WGcA67ClqK5+Ylo=;
X-YMail-OSG: nK329i0VM1lD92JkkR3p1t6Hwy5Pn.MISONqahipZuKYgh. WvfusPi2ICuM7SEPYB_eYyE45arZ2nn9pqvg1ubcwtGqO6b8jJsyQ.KPbGbh 1CNDUsRK6VcNoJiNWcVz8fPPhGJxK0fxzRH5i6cdpJeI8rgzmWGM6eESGcoT _TnBlf7WQaD9xfIRzQ32k.d6ZtvgmySJFzHFVeU.qW8pWxPAX0Rchns0IC.s HD2KCKTNxRy2PnzqxjfEytii00fGBN63fZ9f0mc0Rc81pdjw48abQMBAuWkh 91XUhNpcuTnS7xqVfc1q.8sTg5m0mxRRhdwYOlGtFec6W0oaC8bGIoWW0aSy sihVJfOLQEiI.r3tL9u51HjrDamaPjVoHSb0OY.d6ptJfN7ApO93nXcbkf_N Ea5.vzgoFJYVepRbzVD5yPyp2tMzDoYYIY3uaUtNJok5oBKWD2zw-
Received: from [209.131.62.115] by web31807.mail.mud.yahoo.com via HTTP; Tue, 15 May 2012 10:07:03 PDT
X-RocketYMMF: william_john_mills
X-Mailer: YahooMailWebService/0.8.118.349524
References: <1337032743.59474.YahooMailNeo__29027.4895648055$1337032752$gmane$org@web31806.mail.mud.yahoo.com> <87zk99czym.fsf@latte.josefsson.org> <1337097608.40079.YahooMailNeo__47563.1773741499$1337097627$gmane$org@web31812.mail.mud.yahoo.com> <87y5otbe05.fsf@latte.josefsson.org>
Message-ID: <1337101623.7979.YahooMailNeo@web31807.mail.mud.yahoo.com>
Date: Tue, 15 May 2012 10:07:03 -0700 (PDT)
From: William Mills 
To: Simon Josefsson 
In-Reply-To: <87y5otbe05.fsf@latte.josefsson.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "kitten@ietf.org" 
Subject: Re: [kitten] OAUTH/SASL and the format debate
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: William Mills 
List-Id: Common Authentication Technologies - Next Generation 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 May 2012 17:07:08 -0000

Inline...=0A=0A>________________________________=0A> From: Simon Josefsson =
=0A>To: William Mills  =0A>Cc: "=
kitten@ietf.org"  =0A>Sent: Tuesday, May 15, 2012 9:33 AM=
=0A>Subject: Re: OAUTH/SASL and the format debate=0A> =0A>William Mills  writes:=0A>=0A>>>Why digits as keys?=A0 Some consistenc=
y with RFC 5801/RFC5802 would be=0A>>>nice, so how about something like the=
 following, in pseudo ABNF/regexp=0A>>>language:=0A>>>=0A>>>=A0=A0=A0key =
=3D [A-Za-z0-9_-]+=0A>>>=A0=A0=A0value =3D [^,]*=0A>>>=A0=A0=A0kvpair =3D k=
ey "=3D" value=0A>>>=A0=A0=A0msg =3D kvpair ("," kvpair)*=0A>>>=0A>>>This a=
llows descriptive names for the "key" names.=0A>>=0A>>=0A>> Descriptive key=
 names I like.=A0 "=3D" instead of "SP" is fine too.=A0 Comma=0A>> separate=
d means that the authorization header value will have to be=0A>> base64 enc=
oded, and I'm not sure I'm a big fan of that.=A0 CRLF won't=0A>> appear in =
the auth header.=0A>>=0A>> Re-using the parser from 5801/5802 is attractive=
 though.=A0 Not sure=0A>> what I prefer there.=0A>=0A>Is there some other c=
haracter that isn't used in authorization headers=0A>that could be used as =
a separator?=0A>=0A>I also dislike having to base64 encode values if it can=
 be avoided.=0A>Another option is to escape "," but escaping is often troub=
lesome as=0A>well.=0A>=0A>What I don't like about CRLF is that in some envi=
ronments you may end up=0A>combatting EOL conversions.=A0 Also, doesn't som=
e HTTP header allow=0A>embedded CRLF as whitespace?=0A=0AI don't believe so=
, but there can be line continuations, that is escaped CRLF.=A0 I was going=
 to specifically disallow that in the syntax.=0A=0A=0A>=0A>Another approach=
 is to use ASCII NUL as separator.=A0 The length is=0A>implicit anyway, sin=
ce you know when to stop parse.=A0 That is:=0A>=0A>key =3D [A-Za-z0-9_-]+=
=0A>value =3D [^\00]*=0A>kvpair =3D key "=3D" value=0A>msg =3D kvpair (%x00=
 kvpair)*=0A>=0A>This has the following properties:=0A>=0A>* Easy to parse=
=0A>* All non-NUL data values can be expressed (binary data with embedded=
=0A>=A0 NULs will have to be base64 encoded)=0A>* No escaping=0A>* You can =
use strlen and friends to find the end of the string to parse=0A>=0A=0AI'm =
not rabidly against NULL, though it makes life harder for the producer of t=
he string to have to embed nulls and it's more annoying in other languages =
than C variants.=A0 C variants can easily replace some other fencepost with=
 NULL for in place string handling.=A0 Agreed that EOL conversion is a PITA=
.=A0 If it's not CRLF I would be more inclined to pick a control character =
like control-A or control-C (which has the tag EOT in ascii and so is weird=
ly pleasing).=0A=0A=0A>/Simon=0A>=0A>=0A>

From simon@josefsson.org  Tue May 15 11:22:37 2012
Return-Path: 
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D47E121F85E3 for ; Tue, 15 May 2012 11:22:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.826
X-Spam-Level: 
X-Spam-Status: No, score=-99.826 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, USER_IN_WHITELIST=-100]
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 G4TA59euSCTa for ; Tue, 15 May 2012 11:22:37 -0700 (PDT)
Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id 75E3321F85DD for ; Tue, 15 May 2012 11:22:35 -0700 (PDT)
Received: from latte (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q4FIMOOF021884 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 15 May 2012 20:22:31 +0200
From: Simon Josefsson 
To: William Mills 
References: <1337032743.59474.YahooMailNeo__29027.4895648055$1337032752$gmane$org@web31806.mail.mud.yahoo.com> <87zk99czym.fsf@latte.josefsson.org> <1337097608.40079.YahooMailNeo__47563.1773741499$1337097627$gmane$org@web31812.mail.mud.yahoo.com> <87y5otbe05.fsf@latte.josefsson.org> <1337101623.7979.YahooMailNeo__14668.9488123686$1337101640$gmane$org@web31807.mail.mud.yahoo.com>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:120515:kitten@ietf.org::jFsNHj8WW0LR8HpR:2uR4
X-Hashcash: 1:22:120515:wmills@yahoo-inc.com::eF2mVpndyHOnjwEE:EXhD
Date: Tue, 15 May 2012 20:22:24 +0200
In-Reply-To: <1337101623.7979.YahooMailNeo__14668.9488123686$1337101640$gmane$org@web31807.mail.mud.yahoo.com> (William Mills's message of "Tue, 15 May 2012 10:07:03 -0700 (PDT)")
Message-ID: <87pqa5719b.fsf@latte.josefsson.org>
User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/23.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.97.3 at yxa-v
X-Virus-Status: Clean
Cc: "kitten@ietf.org" 
Subject: Re: [kitten] OAUTH/SASL and the format debate
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Common Authentication Technologies - Next Generation 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 May 2012 18:22:38 -0000

William Mills  writes:

> I'm not rabidly against NULL, though it makes life harder for the
> producer of the string to have to embed nulls and it's more annoying
> in other languages than C variants.  C variants can easily replace
> some other fencepost with NULL for in place string handling.  Agreed
> that EOL conversion is a PITA.  If it's not CRLF I would be more
> inclined to pick a control character like control-A or control-C
> (which has the tag EOT in ascii and so is weirdly pleasing).

We are firmly in bikeshedding land here, but what about TAB as the
separator?

/Simon

From simon@josefsson.org  Tue May 15 12:56:18 2012
Return-Path: 
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A76BF11E80A3 for ; Tue, 15 May 2012 12:56:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.833
X-Spam-Level: 
X-Spam-Status: No, score=-99.833 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, USER_IN_WHITELIST=-100]
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 UJ7O47MtON0c for ; Tue, 15 May 2012 12:56:18 -0700 (PDT)
Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id C326C11E8073 for ; Tue, 15 May 2012 12:56:17 -0700 (PDT)
Received: from latte (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q4FJtVAJ026027 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 15 May 2012 21:55:33 +0200
From: Simon Josefsson 
To: William Mills 
References: <1337040157.1064.YahooMailNeo@web31809.mail.mud.yahoo.com>  <87vcjxczsb.fsf@latte.josefsson.org> <1337097232.42738.YahooMailNeo__45381.5115303316$1337097244$gmane$org@web31816.mail.mud.yahoo.com>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:120515:kitten@ietf.org::mePTFf+7w632Vc5j:0m/K
X-Hashcash: 1:22:120515:wmills@yahoo-inc.com::OMqJWlkD6CHLgzrO:C5yQ
X-Hashcash: 1:22:120515:nico@cryptonector.com::LHSqdUToJ4zyGmqv:rzhZ
Date: Tue, 15 May 2012 21:55:25 +0200
In-Reply-To: <1337097232.42738.YahooMailNeo__45381.5115303316$1337097244$gmane$org@web31816.mail.mud.yahoo.com> (William Mills's message of "Tue, 15 May 2012 08:53:52 -0700 (PDT)")
Message-ID: <87wr4d5idu.fsf@latte.josefsson.org>
User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/23.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.97.3 at yxa-v
X-Virus-Status: Clean
Cc: "kitten@ietf.org" 
Subject: Re: [kitten] channel binding?
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Common Authentication Technologies - Next Generation 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 May 2012 19:56:18 -0000

William Mills  writes:

> I'd prefer to go with two mechanisms.  It makes the logic MUCH
> simpler.  Policy is then implemented by the mechanism you advertise.

Thinking about how SAML20 and SAML20EC could be collapsed into one
mechanism (it would become quite complex), I am inclined to agree.  I
guess it depends on the underlying protocol, for SCRAM it makes sense to
have both variants in the same document, but for complex environments
like SAML and OAuth it might not make sense.

/Simon

> -bill
>
>
>
>
>>________________________________
>> From: Simon Josefsson 
>>To: Nico Williams  
>>Cc: William Mills ; "kitten@ietf.org"  
>>Sent: Tuesday, May 15, 2012 6:57 AM
>>Subject: Re: channel binding?
>> 
>>Nico Williams  writes:
>>
>>> On Mon, May 14, 2012 at 7:02 PM, William Mills  wrote:
>>>> What's the prevailing wisdom on channel binding, is it still the case that
>>>> we SHOULD define SASL mechanisms that support channel binding along with
>>>> non-bound ones?
>>>
>>> Very much so, yes.  But that doesn't mean that you can't create new
>>> SASL mechanisms that can't do channel binding.  The key is that if a
>>> mechanism could support it given its fundamentals, then it must
>>> support it.
>>
>>+1
>>
>>What hasn't been clear to me if there is any way to achieve channel
>>binding with OAuth.  Possibly it is in a similar situation as SAML which
>>resulted in the two SASL mechanisms SAML20 and SAML20EC, namely, that
>>the traditional and most common deployment of the protocol does not
>>easily support it, but it may be possible to use some extension to
>>achieve channel bindings.  If this is the case, I think it would be nice
>>if both variants could be achieved within the same SASL mechanism.
>>Unless that becomes very ugly.  If it becomes ugly, it may be simpler to
>>have two SASL mechanisms that each become less complex.
>>
>>/Simon
>>
>>
>>
> _______________________________________________
> Kitten mailing list
> Kitten@ietf.org
> https://www.ietf.org/mailman/listinfo/kitten

From rra@stanford.edu  Tue May 15 14:34:09 2012
Return-Path: 
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32A0E21F8659 for ; Tue, 15 May 2012 14:34:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 yGatEZFcPsES for ; Tue, 15 May 2012 14:34:08 -0700 (PDT)
Received: from smtp.stanford.edu (smtp2.Stanford.EDU [171.67.219.82]) by ietfa.amsl.com (Postfix) with ESMTP id 4D7F321F8656 for ; Tue, 15 May 2012 14:34:08 -0700 (PDT)
Received: from smtp.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id E53906214F7 for ; Tue, 15 May 2012 14:34:06 -0700 (PDT)
Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.67.225.134]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.stanford.edu (Postfix) with ESMTPS id 640696213AE for ; Tue, 15 May 2012 14:34:06 -0700 (PDT)
Received: by windlord.stanford.edu (Postfix, from userid 1000) id 3ED962F45F; Tue, 15 May 2012 14:34:06 -0700 (PDT)
From: Russ Allbery 
To: "kitten\@ietf.org" 
In-Reply-To: <87pqa5719b.fsf@latte.josefsson.org> (Simon Josefsson's message of "Tue, 15 May 2012 20:22:24 +0200")
Organization: The Eyrie
References: <1337032743.59474.YahooMailNeo__29027.4895648055$1337032752$gmane$org@web31806.mail.mud.yahoo.com> <87zk99czym.fsf@latte.josefsson.org> <1337097608.40079.YahooMailNeo__47563.1773741499$1337097627$gmane$org@web31812.mail.mud.yahoo.com> <87y5otbe05.fsf@latte.josefsson.org> <1337101623.7979.YahooMailNeo__14668.9488123686$1337101640$gmane$org@web31807.mail.mud.yahoo.com> <87pqa5719b.fsf@latte.josefsson.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux)
Date: Tue, 15 May 2012 14:34:05 -0700
Message-ID: <87wr4dt9gy.fsf@windlord.stanford.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [kitten] OAUTH/SASL and the format debate
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Common Authentication Technologies - Next Generation 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 May 2012 21:34:09 -0000

Simon Josefsson  writes:
> William Mills  writes:

>> I'm not rabidly against NULL, though it makes life harder for the
>> producer of the string to have to embed nulls and it's more annoying in
>> other languages than C variants.=C2=A0 C variants can easily replace some
>> other fencepost with NULL for in place string handling.=C2=A0 Agreed that
>> EOL conversion is a PITA.=C2=A0 If it's not CRLF I would be more incline=
d to
>> pick a control character like control-A or control-C (which has the tag
>> EOT in ascii and so is weirdly pleasing).

> We are firmly in bikeshedding land here, but what about TAB as the
> separator?

While admittedly this is a wire protocol, I still think it's a bad idea to
assume that TAB will survive unmolested.  All it takes is editing test
data in a "helpful" editor and now your TAB is some number of spaces and
you have a confusing and strange problem that you're probably going to
waste some time on.

If we go that round, I think we'd be better off with some control
character that editors are unlikely to assign special properties to, like
Ctrl-A, Ctrl-C, or Ctrl-G.

--=20
Russ Allbery (rra@stanford.edu)             

From jbasney@illinois.edu  Wed May 16 08:03:37 2012
Return-Path: 
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E98AD21F8653 for ; Wed, 16 May 2012 08:03:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 G9WpMx3WYfDG for ; Wed, 16 May 2012 08:03:37 -0700 (PDT)
Received: from dscas1.ad.uiuc.edu (dscas1.ad.uiuc.edu [128.174.68.119]) by ietfa.amsl.com (Postfix) with ESMTP id 36E2421F862F for ; Wed, 16 May 2012 08:03:36 -0700 (PDT)
Received: from bit.ncsa.uiuc.edu (141.142.220.216) by smtp-secure.illinois.edu (128.174.68.18) with Microsoft SMTP Server (TLS) id 8.3.159.2; Wed, 16 May 2012 10:03:29 -0500
Message-ID: <4FB3C1C1.2000509@illinois.edu>
Date: Wed, 16 May 2012 10:03:29 -0500
From: Jim Basney 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: kitten@ietf.org
X-Enigmail-Version: 1.4.1
OpenPGP: id=0A33BE15; url=http://www.ncsa.illinois.edu/~jbasney/pgp.asc
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Subject: [kitten] saml-ec gss implementation
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Common Authentication Technologies - Next Generation 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 May 2012 15:03:38 -0000

Hi,

I mentioned in a post a few months ago that we've been working on a
GSS-API mechanism implementation according to
draft-ietf-kitten-sasl-saml-ec. We've now got it working with the MIT
GSS example programs and Shibboleth identity provider using HTTP Basic
Authentication, so I figure it's a good time to send around a pointer to
our code:

  https://github.com/jbasney/mech_saml_ec

If you have a chance to give it a try, please let me know. Any
contributions (patches, bug reports, etc.) are very welcome.

Next we're going to try to get it working with OpenSSH.

-Jim

From alexey.melnikov@isode.com  Wed May 16 08:11:27 2012
Return-Path: 
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83C3B21F84E6 for ; Wed, 16 May 2012 08:11:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.695
X-Spam-Level: 
X-Spam-Status: No, score=-102.695 tagged_above=-999 required=5 tests=[AWL=-0.097, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
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 QI2W5rKcGsKq for ; Wed, 16 May 2012 08:11:26 -0700 (PDT)
Received: from rufus.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 43C0721F8636 for ; Wed, 16 May 2012 08:11:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1337181084; d=isode.com; s=selector; i=@isode.com; bh=iIyRoMoCL7Y5irzo6tSdJlhfbUdEbFwsIOd1EaTTglY=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=KAiA8UkN/mhkLRYVHAYKMHeUnuLy/E3LURNpl9707TWuU75M2Gd+XvfmEj3j0MeoqiQWh9 SWhKJa5RCSvO+v4AdQd1CC4k1pZIhrdngH/X6kNkJibzTJOhggR4ve0OYzpP4LwrcXNv5v xFWnxQcDRKJDU+nNnTIPwNeZBhcykzI=;
Received: from [172.16.11.4] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id ; Wed, 16 May 2012 16:11:24 +0100
Message-ID: <4FB3C3F2.1000701@isode.com>
Date: Wed, 16 May 2012 16:12:50 +0100
From: Alexey Melnikov 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
To: William Mills 
References: <1337032743.59474.YahooMailNeo@web31806.mail.mud.yahoo.com> <4FB1828D.2080404@stpeter.im> <1337035040.62404.YahooMailNeo@web31811.mail.mud.yahoo.com>
In-Reply-To: <1337035040.62404.YahooMailNeo@web31811.mail.mud.yahoo.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------040201010908020503040509"
Cc: "kitten@ietf.org" 
Subject: Re: [kitten] OAUTH/SASL and the format debate
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Common Authentication Technologies - Next Generation 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 May 2012 15:11:27 -0000

This is a multi-part message in MIME format.
--------------040201010908020503040509
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 14/05/2012 23:37, William Mills wrote:
> I don't have a preference.  The key value format is easier to parse.  
> JSON has libraries.
>
> Folks please weigh in with JSON vs. KV votes please.
>
I slightly prefer KV, but I can live with either.
> Thanks,
>
> -bill
>
>     ------------------------------------------------------------------------
>     *From:* Peter Saint-Andre 
>     *To:* William Mills 
>     *Cc:* "kitten@ietf.org" 
>     *Sent:* Monday, May 14, 2012 3:09 PM
>     *Subject:* Re: [kitten] OAUTH/SASL and the format debate
>
>     On 5/14/12 3:59 PM, William Mills wrote:
>     > Having inquired of a number of folks that have implemented the
>     XOAUTH
>     > mechanism and getting no reply, I'm planning to go with "silence ==
>     > consent" and presume there's no big objection to moving away
>     form the
>     > HTTP format style for the SASL messages.  I' planning on a key/value
>     > pair format, which is easily extensible.  My plan was something
>     like:
>     >
>     >    NONZERO ::= %x31-39
>     >    key ::= NONZERO *DIGIT
>     >    value ::= *(SP HTAB VCHAR)
>     >    msg_line ::= key SP value CRLF
>     >    sasl_msg ::= +msg_line CRLF
>     >
>     > We would need an IANA registry for keys.  Objections?  Other
>     preferred
>     > formats?
>
>     +1. This approach seems more easily parseable than HTTPish headers
>     (especially given questions about how complete one's HTTP parser needs
>     to be). However, if we're going to have a simple key-value format, why
>     not use JSON instead of defining something new? (And yes, I'm an
>     XML guy
>     myself...)
>
>     Peter
>
>     -- 
>     Peter Saint-Andre
>     https://stpeter.im/
>
>


--------------040201010908020503040509
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    On 14/05/2012 23:37, William Mills wrote:
    

      

        
I don't have a preference.  The key value format is
            easier to parse.  JSON has libraries.

        


          

        
Folks please weigh in with JSON vs. KV votes please.

        


        

      

    

    I slightly prefer KV, but I can live with either.

    

      

        
Thanks,

        


          

        
-bill

          

        


          

            

              

                
 
                    
 From:
                    Peter Saint-Andre <stpeter@stpeter.im>

                    To:
                    William Mills <wmills@yahoo-inc.com> 

                    Cc:
                    "kitten@ietf.org" <kitten@ietf.org> 

                    Sent:
                    Monday, May 14, 2012 3:09 PM

                    Subject:
                    Re: [kitten] OAUTH/SASL and the format debate

                   

                

                On 5/14/12 3:59 PM, William Mills wrote:

                > Having inquired of a number of folks that have
                implemented the XOAUTH

                > mechanism and getting no reply, I'm planning to go
                with "silence ==

                > consent" and presume there's no big objection to
                moving away form the

                > HTTP format style for the SASL messages.  I'
                planning on a key/value

                > pair format, which is easily extensible.  My plan
                was something like:

                > 

                >    NONZERO ::= %x31-39

                >    key ::= NONZERO *DIGIT 

                >    value ::= *(SP HTAB VCHAR)

                >    msg_line ::= key SP value CRLF

                >    sasl_msg ::= +msg_line CRLF

                > 

                > We would need an IANA registry for keys. 
                Objections?  Other preferred

                > formats?

                

                +1. This approach seems more easily parseable than
                HTTPish headers

                (especially given questions about how complete one's
                HTTP parser needs

                to be). However, if we're going to have a simple
                key-value format, why

                not use JSON instead of defining something new? (And
                yes, I'm an XML guy

                myself...)

                

                Peter

                

                -- 

                Peter Saint-Andre

                https://stpeter.im/

                

              

            

          

        

      

      

    

    

  


--------------040201010908020503040509--

From alexey.melnikov@isode.com  Wed May 16 08:16:10 2012
Return-Path: 
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF8D521F86C6 for ; Wed, 16 May 2012 08:16:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.695
X-Spam-Level: 
X-Spam-Status: No, score=-102.695 tagged_above=-999 required=5 tests=[AWL=-0.096, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 acPMg6cpPQGQ for ; Wed, 16 May 2012 08:16:10 -0700 (PDT)
Received: from rufus.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id C515521F86C4 for ; Wed, 16 May 2012 08:16:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1337181368; d=isode.com; s=selector; i=@isode.com; bh=Xib/ErStT0etLXl+fTuYuHgryTZtHNw++5dAexeSUw8=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=FbrPWBY/6XJdtUp/lj2ueZe4Bwgu+ZwxyJ4A9N2ust95DxjrCvseEJ7uaEMLbTqUP/N1+2 D6Qn3amD+/eMXUIOhqKDP4+OKrV8+SheT7af/5vGsKNLcBU0Oyi895ncCPFJMhf8kDOX+F 5b4C+1d7bd+yxohv+St9QITfxZGUkwQ=;
Received: from [172.16.11.4] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id ; Wed, 16 May 2012 16:16:08 +0100
Message-ID: <4FB3C50E.3090600@isode.com>
Date: Wed, 16 May 2012 16:17:34 +0100
From: Alexey Melnikov 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
To: William Mills 
References: <1337032743.59474.YahooMailNeo__29027.4895648055$1337032752$gmane$org@web31806.mail.mud.yahoo.com> <87zk99czym.fsf@latte.josefsson.org> <1337097608.40079.YahooMailNeo__47563.1773741499$1337097627$gmane$org@web31812.mail.mud.yahoo.com> <87y5otbe05.fsf@latte.josefsson.org> <1337101623.7979.YahooMailNeo@web31807.mail.mud.yahoo.com>
In-Reply-To: <1337101623.7979.YahooMailNeo@web31807.mail.mud.yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "kitten@ietf.org" , Simon Josefsson 
Subject: Re: [kitten] OAUTH/SASL and the format debate
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Common Authentication Technologies - Next Generation 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 May 2012 15:16:11 -0000

On 15/05/2012 18:07, William Mills wrote:
> Inline...
>
>> ________________________________
>> From: Simon Josefsson
>> To: William Mills
>> Cc: "kitten@ietf.org"
>> Sent: Tuesday, May 15, 2012 9:33 AM
>> Subject: Re: OAUTH/SASL and the format debate
>>
>> William Mills  writes:
>>
>>>> Why digits as keys?  Some consistency with RFC 5801/RFC5802 would be
>>>> nice, so how about something like the following, in pseudo ABNF/regexp
>>>> language:
>>>>
>>>>     key = [A-Za-z0-9_-]+
>>>>     value = [^,]*
>>>>     kvpair = key "=" value
>>>>     msg = kvpair ("," kvpair)*
>>>>
>>>> This allows descriptive names for the "key" names.
>>>
>>> Descriptive key names I like.  "=" instead of "SP" is fine too.  Comma
>>> separated means that the authorization header value will have to be
>>> base64 encoded, and I'm not sure I'm a big fan of that.  CRLF won't
>>> appear in the auth header.
>>>
>>> Re-using the parser from 5801/5802 is attractive though.  Not sure
>>> what I prefer there.
>> Is there some other character that isn't used in authorization headers
>> that could be used as a separator?
>>
>> I also dislike having to base64 encode values if it can be avoided.
>> Another option is to escape "," but escaping is often troublesome as
>> well.
>>
>> What I don't like about CRLF is that in some environments you may end up
>> combatting EOL conversions.  Also, doesn't some HTTP header allow
>> embedded CRLF as whitespace?
> I don't believe so, but there can be line continuations, that is escaped CRLF.  I was going to specifically disallow that in the syntax.
Right.
>> Another approach is to use ASCII NUL as separator.  The length is
>> implicit anyway, since you know when to stop parse.  That is:
>>
>> key = [A-Za-z0-9_-]+
>> value = [^\00]*
>> kvpair = key "=" value
>> msg = kvpair (%x00 kvpair)*
>>
>> This has the following properties:
>>
>> * Easy to parse
>> * All non-NUL data values can be expressed (binary data with embedded
>>    NULs will have to be base64 encoded)
>> * No escaping
>> * You can use strlen and friends to find the end of the string to parse
> I'm not rabidly against NULL, though it makes life harder for the producer of the string to have to embed nulls and it's more annoying in other languages than C variants.  C variants can easily replace some other fencepost with NULL for in place string handling.  Agreed that EOL conversion is a PITA.  If it's not CRLF
I don't think CRLF is particularly problematic. Using just LF is fine as 
well.
> I would be more inclined to pick a control character like control-A or control-C (which has the tag EOT in ascii and so is weirdly pleasing).
This is indeed a minor issue, but using a character that would be hard 
to type in telnet (such as NUL) would make debugging more difficult.


From alexey.melnikov@isode.com  Wed May 16 08:22:40 2012
Return-Path: 
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F44321F858D for ; Wed, 16 May 2012 08:22:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.692
X-Spam-Level: 
X-Spam-Status: No, score=-102.692 tagged_above=-999 required=5 tests=[AWL=-0.094, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
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 oA34-eZtSJJJ for ; Wed, 16 May 2012 08:22:39 -0700 (PDT)
Received: from rufus.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0758A21F853B for ; Wed, 16 May 2012 08:22:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1337181757; d=isode.com; s=selector; i=@isode.com; bh=GUCuYhbUN0DJETJV5CEwIamFldhVbc7As2ERRTetclk=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=Zwjqp+hA83KGNypt9QWf3haVr3ZPnE+EiZfmyJRz0fSzKLSajsbFseSV3WnWLHrLpKZ3/c iTzgrH3VD6NNj4dKt2uxvew+R84JJZMsMgsS4wbfe0wAzBI0wvgAaf0rr3bXEehdXkLxRO hn6h2rCGg4oT+RPuQDSki0E+gCB6t98=;
Received: from [172.16.11.4] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id ; Wed, 16 May 2012 16:22:37 +0100
Message-ID: <4FB3C694.4000609@isode.com>
Date: Wed, 16 May 2012 16:24:04 +0100
From: Alexey Melnikov 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
To: William Mills 
References: <1337040157.1064.YahooMailNeo@web31809.mail.mud.yahoo.com>  <87vcjxczsb.fsf@latte.josefsson.org> <1337097232.42738.YahooMailNeo@web31816.mail.mud.yahoo.com>
In-Reply-To: <1337097232.42738.YahooMailNeo@web31816.mail.mud.yahoo.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------030006010309020302010609"
Cc: "kitten@ietf.org" , Simon Josefsson 
Subject: Re: [kitten] channel binding?
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Common Authentication Technologies - Next Generation 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 May 2012 15:22:40 -0000

This is a multi-part message in MIME format.
--------------030006010309020302010609
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 15/05/2012 16:53, William Mills wrote:
> I'd prefer to go with two mechanisms.  It makes the logic MUCH 
> simpler.  Policy is then implemented by the mechanism you advertise.
If the only difference is to say "I don't want to use/don't have access 
to channel binding data", then I think 2 variants of 1 mechanism are 
actually simpler to implement overall.
>
> -bill
>
>     ------------------------------------------------------------------------
>     *From:* Simon Josefsson 
>     *To:* Nico Williams 
>     *Cc:* William Mills ; "kitten@ietf.org"
>     
>     *Sent:* Tuesday, May 15, 2012 6:57 AM
>     *Subject:* Re: channel binding?
>
>     Nico Williams      > writes:
>
>     > On Mon, May 14, 2012 at 7:02 PM, William Mills
>     > wrote:
>     >> What's the prevailing wisdom on channel binding, is it still
>     the case that
>     >> we SHOULD define SASL mechanisms that support channel binding
>     along with
>     >> non-bound ones?
>     >
>     > Very much so, yes.  But that doesn't mean that you can't create new
>     > SASL mechanisms that can't do channel binding.  The key is that if a
>     > mechanism could support it given its fundamentals, then it must
>     > support it.
>
>     +1
>
>     What hasn't been clear to me if there is any way to achieve channel
>     binding with OAuth.  Possibly it is in a similar situation as SAML
>     which
>     resulted in the two SASL mechanisms SAML20 and SAML20EC, namely, that
>     the traditional and most common deployment of the protocol does not
>     easily support it, but it may be possible to use some extension to
>     achieve channel bindings.  If this is the case, I think it would
>     be nice
>     if both variants could be achieved within the same SASL mechanism.
>     Unless that becomes very ugly.  If it becomes ugly, it may be
>     simpler to
>     have two SASL mechanisms that each become less complex.
>
>     /Simon
>


--------------030006010309020302010609
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    On 15/05/2012 16:53, William Mills wrote:
    

      

        
I'd prefer to go with two mechanisms.  It makes the
            logic MUCH simpler.  Policy is then implemented by the
            mechanism you advertise.

      

    

    If the only difference is to say "I don't want to use/don't have
    access to channel binding data", then I think 2 variants of 1
    mechanism are actually simpler to implement overall.

    

      

        


          

        
-bill

          

        


          

            

              

                
 
                    
 From:
                    Simon Josefsson <simon@josefsson.org>

                    To:
                    Nico Williams <nico@cryptonector.com> 

                    Cc:
                    William Mills <wmills@YAHOO-INC.COM>;
                    "kitten@ietf.org" <kitten@ietf.org> 

                    Sent:
                    Tuesday, May 15, 2012 6:57 AM

                    Subject:
                    Re: channel binding?

                   

                

                Nico Williams <nico@cryptonector.com>
                writes:

                

                > On Mon, May 14, 2012 at 7:02 PM, William Mills <wmills@yahoo-inc.com>
                wrote:

                >> What's the prevailing wisdom on channel
                binding, is it still the case that

                >> we SHOULD define SASL mechanisms that support
                channel binding along with

                >> non-bound ones?

                >

                > Very much so, yes.  But that doesn't mean that you
                can't create new

                > SASL mechanisms that can't do channel binding.  The
                key is that if a

                > mechanism could support it given its fundamentals,
                then it must

                > support it.

                

                +1

                

                What hasn't been clear to me if there is any way to
                achieve channel

                binding with OAuth.  Possibly it is in a similar
                situation as SAML which

                resulted in the two SASL mechanisms SAML20 and SAML20EC,
                namely, that

                the traditional and most common deployment of the
                protocol does not

                easily support it, but it may be possible to use some
                extension to

                achieve channel bindings.  If this is the case, I think
                it would be nice

                if both variants could be achieved within the same SASL
                mechanism.

                Unless that becomes very ugly.  If it becomes ugly, it
                may be simpler to

                have two SASL mechanisms that each become less complex.

                

                /Simon

                

              

            

          

        

      

    

    

  


--------------030006010309020302010609--

From wmills@yahoo-inc.com  Fri May 18 21:33:33 2012
Return-Path: 
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 927F19E8031 for ; Fri, 18 May 2012 21:33:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.649
X-Spam-Level: 
X-Spam-Status: No, score=-15.649 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_50=0.001, USER_IN_DEF_WHITELIST=-15]
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 HPSqqywzO+yn for ; Fri, 18 May 2012 21:33:32 -0700 (PDT)
Received: from nm30.bullet.mail.ac4.yahoo.com (nm30.bullet.mail.ac4.yahoo.com [98.139.52.227]) by ietfa.amsl.com (Postfix) with SMTP id B2C619E8030 for ; Fri, 18 May 2012 21:33:32 -0700 (PDT)
Received: from [98.139.52.193] by nm30.bullet.mail.ac4.yahoo.com with NNFMP; 19 May 2012 04:33:28 -0000
Received: from [98.139.52.160] by tm6.bullet.mail.ac4.yahoo.com with NNFMP; 19 May 2012 04:33:28 -0000
Received: from [127.0.0.1] by omp1043.mail.ac4.yahoo.com with NNFMP; 19 May 2012 04:33:28 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 195568.30527.bm@omp1043.mail.ac4.yahoo.com
Received: (qmail 29599 invoked by uid 60001); 19 May 2012 04:33:27 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1337402007; bh=F2XKIJCPZx4pB5l1Bi4c1Q0On6RfFz1OxlR7w9amumk=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=ozApVLAOmZnR27/TW2zhKpdTdVm71PWAcRakisJqTAj2sj+Cocf4Cnj9+boC+2MrrKFLFq7xdFSYJgtSlvms7MnvWgdb8OqTKe5Gn98UFzzs/pLa7pEGRGtCn5SFnis2RoWN5e8RlqVOwTZ7tENRi9q9X2odGE0npfipiuALnLg=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=J7vuoJf0bDN4bWfJ1BoPDFWBPsTjnVPcdb00r6ayBN+7yUfHVFTOSw7dy7GUHhfrw2Fno1OXzFt5Hrh+bM1z37cpwKHpqU4xgihi9teYpoPMzAWivKl+3nrXpubYkpaaUVsV24SKDetnOiWBX7tL4OfMbb49jJaAqIXEIq7Pznc=;
X-YMail-OSG: PdjbJ3AVM1lEJ62qTEdDkPekj.nEo9r0zNk05_wFrtTSbjh B1puH7BuAlukWCxM2pxacPuaGKG5emODw_qE28vcTYsQuzvHUMMgRznCu.P4 kdcj8mEjljeZZwX1iHsnA8E1ZXYj0ePAOau3Jip8GNBiFVrn8TGWeuOlgzM4 miTWcmh6iYM6.cCrosqSSvZPQPm2_ulisCieVnTZvJel2z8g.hALyA3nRYnP Q9qUv2M3xkA9cuplZ3LpGwFaZw6ser.NXtQ5E3QbLBETUyPoS.SgtmkEuS7s DVZIl221DxCpK5PuLwOG3JJ9Ll5v7EhbLbrbWf6M1bVDWV2zo28Ba9wUTrVC yfv4Ua1COVa1RXs.UBWkz9kbsx8iIntfbIklMMXK1XM.7Pe2QmWlK0iCmake 6oP9ZR1m7Ui8Dlec9iKcR6txQo2Up2KtCU6WMwkrFPhRuIV1KWq4-
Received: from [209.131.62.115] by web31805.mail.mud.yahoo.com via HTTP; Fri, 18 May 2012 21:33:27 PDT
X-RocketYMMF: william_john_mills
X-Mailer: YahooMailWebService/0.8.118.349524
References: <1337032743.59474.YahooMailNeo__29027.4895648055$1337032752$gmane$org@web31806.mail.mud.yahoo.com> <87zk99czym.fsf@latte.josefsson.org> <1337097608.40079.YahooMailNeo__47563.1773741499$1337097627$gmane$org@web31812.mail.mud.yahoo.com> <87y5otbe05.fsf@latte.josefsson.org> <1337101623.7979.YahooMailNeo__14668.9488123686$1337101640$gmane$org@web31807.mail.mud.yahoo.com> <87pqa5719b.fsf@latte.josefsson.org>
Message-ID: <1337402007.76171.YahooMailNeo@web31805.mail.mud.yahoo.com>
Date: Fri, 18 May 2012 21:33:27 -0700 (PDT)
From: William Mills 
To: "kitten@ietf.org" 
In-Reply-To: <87pqa5719b.fsf@latte.josefsson.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: [kitten] New draft soon Re: OAUTH/SASL and the format debate
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: William Mills 
List-Id: Common Authentication Technologies - Next Generation 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 19 May 2012 04:33:33 -0000

Well, I've got a draft done, however it's not playing nice with the submiss=
ion tool, even though it passes all of the xml2rfc tools I checked.=A0 =0A=
=0A=0A-bill=0A=0A=0A=0A----- Original Message -----=0A> From: Simon Josefss=
on =0A> To: William Mills =0A> C=
c: "kitten@ietf.org" =0A> Sent: Tuesday, May 15, 2012 11:2=
2 AM=0A> Subject: Re: OAUTH/SASL and the format debate=0A> =0A> William Mil=
ls  writes:=0A> =0A>>  I'm not rabidly against NULL, =
though it makes life harder for the=0A>>  producer of the string to have to=
 embed nulls and it's more annoying=0A>>  in other languages than C variant=
s.=A0 C variants can easily replace=0A>>  some other fencepost with NULL fo=
r in place string handling.=A0 Agreed=0A>>  that EOL conversion is a PITA.=
=A0 If it's not CRLF I would be more=0A>>  inclined to pick a control chara=
cter like control-A or control-C=0A>>  (which has the tag EOT in ascii and =
so is weirdly pleasing).=0A> =0A> We are firmly in bikeshedding land here, =
but what about TAB as the=0A> separator?=0A> =0A> /Simon=0A> 

From wmills@yahoo-inc.com  Fri May 18 22:00:27 2012
Return-Path: 
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2337721F8609 for ; Fri, 18 May 2012 22:00:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -16.732
X-Spam-Level: 
X-Spam-Status: No, score=-16.732 tagged_above=-999 required=5 tests=[AWL=0.867, BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15]
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 kXHe8C7pQYgh for ; Fri, 18 May 2012 22:00:25 -0700 (PDT)
Received: from nm8-vm0.bullet.mail.ac4.yahoo.com (nm8-vm0.bullet.mail.ac4.yahoo.com [98.139.52.230]) by ietfa.amsl.com (Postfix) with SMTP id 9092B21F85BB for ; Fri, 18 May 2012 22:00:25 -0700 (PDT)
Received: from [98.139.52.191] by nm8.bullet.mail.ac4.yahoo.com with NNFMP; 19 May 2012 05:00:21 -0000
Received: from [98.139.52.166] by tm4.bullet.mail.ac4.yahoo.com with NNFMP; 19 May 2012 05:00:21 -0000
Received: from [127.0.0.1] by omp1049.mail.ac4.yahoo.com with NNFMP; 19 May 2012 05:00:21 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 477709.16929.bm@omp1049.mail.ac4.yahoo.com
Received: (qmail 23074 invoked by uid 60001); 19 May 2012 05:00:20 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1337403620; bh=Oin0PjiQcWg9EJbUj8R1yyAgpGwHZOz5gqgh1B6aDXM=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=V8igJRZ/odIMf5DwLwJJbxYIlHEgH+O9fPVxD1I9wbvM+PhegNwU1l9UMfEwWcsVdjhJYhbL3cYVAbjlhU2AZAV5B1536KV4l2ZMYlyezDL41zDvkCEWMMmYI4HfmnTT/mpwyigBILNVmMR51NcrcqqB9EYtgDnvh/eDVP48Lss=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=CStGkQTferRfvCSRxn0gayG+MfwxS3xnAX0LAA8MwLrK8r7a/wzVJjE8G+sx41SmwXUcCAzHpARrHJ97lgpGJ1GUHUxwGbAvOS9yxoEQbV/SnkhpbXjvmU43mdif8J7n4D4910PUY7g0bzpvJUBwycbTOb3UDa6fr9f1VW8dhJE=;
X-YMail-OSG: nF_pEgEVM1m80NLfCZKaYVZ_QV3Mvnb3STs5mOSrdS3zTyc 4bs64Ar.Uq6A8BtNdbxZ6pajWDinBVcvxW7HIfTZfkIAZTG4ha_DAvz5mPru vgf66S71CpDdHRqcKP5Oke55Mmir2I7IVBF8NioAiE5z3QbGEzcuikrkY.dw .3xjGPqKKIhTRiClQkrxJOF03kH8pGkG52GBMHEnDaWVMPqiYcXKcfK6WqDJ XybisxojAwvMaQX5V4v6gQHzVpiOjSLte6bYETjJ2FfX6ApgBj.OUrUsYBnE PMiA9_cKrUdeBqY5M5GoFqa4ysjpiaN_A_CKSPNOMasl6JxXjUYw9Ag7T_5i jn6kSfYRk8F48ERpesMbZrMXHTETXo9xez3GK9xZxd4KJaRUDQFEUW_gwb0M QPQfdtnm1IwfnYKqMFbA4O9GwOs59xIpbDP_hrWb5Pp8j8bDf0w--
Received: from [209.131.62.115] by web31810.mail.mud.yahoo.com via HTTP; Fri, 18 May 2012 22:00:19 PDT
X-RocketYMMF: william_john_mills
X-Mailer: YahooMailWebService/0.8.118.349524
References: <1337032743.59474.YahooMailNeo__29027.4895648055$1337032752$gmane$org@web31806.mail.mud.yahoo.com> <87zk99czym.fsf@latte.josefsson.org> <1337097608.40079.YahooMailNeo__47563.1773741499$1337097627$gmane$org@web31812.mail.mud.yahoo.com> <87y5otbe05.fsf@latte.josefsson.org> <1337101623.7979.YahooMailNeo__14668.9488123686$1337101640$gmane$org@web31807.mail.mud.yahoo.com> <87pqa5719b.fsf@latte.josefsson.org> <1337402007.76171.YahooMailNeo@web31805.mail.mud.yahoo.com>
Message-ID: <1337403619.81973.YahooMailNeo@web31810.mail.mud.yahoo.com>
Date: Fri, 18 May 2012 22:00:19 -0700 (PDT)
From: William Mills 
To: William Mills , "kitten@ietf.org" 
In-Reply-To: <1337402007.76171.YahooMailNeo@web31805.mail.mud.yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [kitten] New draft soon Re: OAUTH/SASL and the format debate
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: William Mills 
List-Id: Common Authentication Technologies - Next Generation 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 19 May 2012 05:00:27 -0000

Ah hah!=A0 Eager readers can see the txt or PDF version at https://datatrac=
ker.ietf.org/submit/status/41447/=0A=0A=0A=0A----- Original Message -----=
=0A> From: William Mills =0A> To: "kitten@ietf.org" <=
kitten@ietf.org>=0A> Cc: =0A> Sent: Friday, May 18, 2012 9:33 PM=0A> Subjec=
t: [kitten] New draft soon Re: OAUTH/SASL and the format debate=0A> =0A> We=
ll, I've got a draft done, however it's not playing nice with the =0A> subm=
ission tool, even though it passes all of the xml2rfc tools I checked.=A0 =
=0A> =0A> =0A> -bill=0A> =0A> =0A> =0A> ----- Original Message -----=0A>>  =
From: Simon Josefsson =0A>>  To: William Mills =0A>>  Cc: "kitten@ietf.org" =0A>>  Sent: T=
uesday, May 15, 2012 11:22 AM=0A>>  Subject: Re: OAUTH/SASL and the format =
debate=0A>> =0A>>  William Mills  writes:=0A>> =0A>>>=
 =A0 I'm not rabidly against NULL, though it makes life harder for the=0A>>=
> =A0 producer of the string to have to embed nulls and it's more =0A> anno=
ying=0A>>> =A0 in other languages than C variants.=A0 C variants can easily=
 replace=0A>>> =A0 some other fencepost with NULL for in place string handl=
ing.=A0 Agreed=0A>>> =A0 that EOL conversion is a PITA.=A0 If it's not CRLF=
 I would be more=0A>>> =A0 inclined to pick a control character like contro=
l-A or control-C=0A>>> =A0 (which has the tag EOT in ascii and so is weirdl=
y pleasing).=0A>> =0A>>  We are firmly in bikeshedding land here, but what =
about TAB as the=0A>>  separator?=0A>> =0A>>  /Simon=0A>> =0A> ____________=
___________________________________=0A> Kitten mailing list=0A> Kitten@ietf=
.org=0A> https://www.ietf.org/mailman/listinfo/kitten=0A> 

From wwwrun@rfc-editor.org  Tue May 29 09:49:33 2012
Return-Path: 
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD3C311E80BF; Tue, 29 May 2012 09:49:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102
X-Spam-Level: 
X-Spam-Status: No, score=-102 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
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 B9eqlkn1mVo3; Tue, 29 May 2012 09:49:33 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 67CC211E80BD; Tue, 29 May 2012 09:49:33 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 841BAB1E012; Tue, 29 May 2012 09:38:54 -0700 (PDT)
To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org
From: rfc-editor@rfc-editor.org
Message-Id: <20120529163854.841BAB1E012@rfc-editor.org>
Date: Tue, 29 May 2012 09:38:54 -0700 (PDT)
Cc: kitten@ietf.org, rfc-editor@rfc-editor.org
Subject: [kitten] RFC 6616 on A Simple Authentication and Security Layer (SASL) and Generic Security Service Application Program Interface (GSS-API) Mechanism for OpenID
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Common Authentication Technologies - Next Generation 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 May 2012 16:49:34 -0000

A new Request for Comments is now available in online RFC libraries.

        
        RFC 6616

        Title:      A Simple Authentication and Security 
                    Layer (SASL) and Generic Security Service 
                    Application Program Interface (GSS-API) Mechanism for 
                    OpenID 
        Author:     E. Lear, H. Tschofenig,
                    H. Mauldin, S. Josefsson
        Status:     Standards Track
        Stream:     IETF
        Date:       May 2012
        Mailbox:    lear@cisco.com, 
                    Hannes.Tschofenig@gmx.net, 
                    hmauldin@cisco.com,
                    simon@josefsson.org
        Pages:      18
        Characters: 39323
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-kitten-sasl-openid-08.txt

        URL:        http://www.rfc-editor.org/rfc/rfc6616.txt

OpenID has found its usage on the Internet for Web Single Sign-On.
Simple Authentication and Security Layer (SASL) and the Generic
Security Service Application Program Interface (GSS-API) are
application frameworks to generalize authentication.  This memo
specifies a SASL and GSS-API mechanism for OpenID that allows the
integration of existing OpenID Identity Providers with applications
using SASL and GSS-API.  [STANDARDS-TRACK]

This document is a product of the Common Authentication Technology Next Generation Working Group of the IETF.

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Internet
Official Protocol Standards (STD 1) for the standardization state and
status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC



From wmills@yahoo-inc.com  Tue May 29 09:58:22 2012
Return-Path: 
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B34811E80D5 for ; Tue, 29 May 2012 09:58:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.841
X-Spam-Level: 
X-Spam-Status: No, score=-15.841 tagged_above=-999 required=5 tests=[AWL=-0.843, BAYES_50=0.001, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15]
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 l9+Mkdx-xQdq for ; Tue, 29 May 2012 09:58:21 -0700 (PDT)
Received: from nm34-vm5.bullet.mail.bf1.yahoo.com (nm34-vm5.bullet.mail.bf1.yahoo.com [72.30.239.77]) by ietfa.amsl.com (Postfix) with SMTP id 4D02211E80D3 for ; Tue, 29 May 2012 09:58:20 -0700 (PDT)
Received: from [98.139.212.145] by nm34.bullet.mail.bf1.yahoo.com with NNFMP; 29 May 2012 16:58:20 -0000
Received: from [98.139.212.207] by tm2.bullet.mail.bf1.yahoo.com with NNFMP; 29 May 2012 16:58:20 -0000
Received: from [127.0.0.1] by omp1016.mail.bf1.yahoo.com with NNFMP; 29 May 2012 16:58:20 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 190780.86983.bm@omp1016.mail.bf1.yahoo.com
Received: (qmail 61379 invoked by uid 60001); 29 May 2012 16:58:19 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1338310699; bh=Jo2XFHfNo4xUxb5rv1+zV4jnNt8ik/cpV2/qTOUcwxY=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=MEldVYeNw2HbzRMOzeYFhQElHWAaLI3amSfncvbHeYP6aYX+dt1eRPuzMyfYFpurnX6T0KOGuifyOzwRFmHONSAS357xgX+K8APjb50nXI0PWksK6C8In7KAtLn5yIeErrU4dtXI7rAklW2heWlXBpHztbLg58BeQfglqV8j6M0=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=JwUXm/GoqsY8Nd8sCCugLIbScKBO5pG9tVTOXnBaD0Hitzs+HcghqBrYwjZXztJsDFZkiRTVD1sLb2VPVFYEDHTLFMjqTV48y2FeQJI2InxXqvCphKXD6VuDao/yPZW3g6lo58tyLTcW+Gr0POL4QqGsqjcBI+iEImqabZljZiw=;
X-YMail-OSG: PSAMMrYVM1mBAG0if4lBMqjqA1c7ha0rzCkj088r7WEUCz8 K_nS7yBZ_frB5bAY.VN3vxk3DFsOvDRskoA022PLzeXX1LJbfxOLoJBtjJMf VT5dmtZfwMTtmgTNMNCadFq2cg6NzKtBKZvERPIiHvzCGndUZ_zfTDRHkHZN zXA55lmyJ3D125pnefDyqNo85L4KJ7185loF5yQ9jvG9OVIkWEcgGhMu3kKP JMn1_530o6r7GT4SN8Ni.CNNn4BV4IcqEZONYJSyabDJ6zYB.pAtFYyGhzH8 .OpdAqgVYgykPB2RSw1tmTAheUkiFoGeSIKkiqTliuoNB.XZkBAzVWsx3AD9 qTiBM4iHYsMeyQqGqt_lhEdkSWqZUjdGUM0Tl0wrWmlRQGBdUYwHSsqlOLX8 2Hhmf_G9Cpf6.7m7CLUTlodUTNk_cp9sa
Received: from [209.131.62.115] by web31804.mail.mud.yahoo.com via HTTP; Tue, 29 May 2012 09:58:19 PDT
X-RocketYMMF: william_john_mills
X-Mailer: YahooMailWebService/0.8.118.349524
Message-ID: <1338310699.60023.YahooMailNeo@web31804.mail.mud.yahoo.com>
Date: Tue, 29 May 2012 09:58:19 -0700 (PDT)
From: William Mills 
To: "kitten@ietf.org" 
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="835683298-78958768-1338310699=:60023"
Subject: [kitten] problems submitting....
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: William Mills 
List-Id: Common Authentication Technologies - Next Generation 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 May 2012 16:58:22 -0000

--835683298-78958768-1338310699=:60023
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

I've tried uploading a draft though the tool and it fails the nit's upload =
check.=A0 I sent an e-mail submission it last week and have gotten no reply=
.=A0 How do I move this along?=A0 I'm stuck.=0A=0AThanks,=0A=0A-bill=0A
--835683298-78958768-1338310699=:60023
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable


I've=
 tried uploading a draft though the tool and it fails the nit's upload chec=
k.  I sent an e-mail submission it last week and have gotten no reply.=
  How do I move this along?  I'm stuck.

=
Thanks,

-bill

--835683298-78958768-1338310699=:60023--

From alexey.melnikov@isode.com  Tue May 29 11:05:45 2012
Return-Path: 
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A28011E8114 for ; Tue, 29 May 2012 11:05:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.503
X-Spam-Level: 
X-Spam-Status: No, score=-102.503 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
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 7FVM1q8tUwsx for ; Tue, 29 May 2012 11:05:44 -0700 (PDT)
Received: from rufus.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0B77011E8102 for ; Tue, 29 May 2012 11:05:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1338314743; d=isode.com; s=selector; i=@isode.com; bh=10EVuMAhu7v6zQOMxTpFUEzJuZX9ePD1mk0K96NQSuM=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=N9exbp+J7aMnyfuDythjwWF19sdkjIg55vzbo1yk2Gn/MvsQk6kgWF5ZQVXoJYQu+hlRyW XcZlf8WeARyNp5w7l5OL3pOZTjVChVLxTjz+xtZScJYVB5bVnAkmptFIcBdwTzgl/zI9Tp 1YXoY5uNKma6bJf9sBRFNIR0le/ZNOA=;
Received: from [192.168.1.144] ((unknown) [62.3.217.253])  by rufus.isode.com (submission channel) via TCP with ESMTPSA  id ; Tue, 29 May 2012 19:05:42 +0100
X-SMTP-Protocol-Errors: NORDNS PIPELINING
Message-ID: <4FC50FF6.2070406@isode.com>
Date: Tue, 29 May 2012 19:05:43 +0100
From: Alexey Melnikov 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
To: William Mills 
References: <1338310699.60023.YahooMailNeo@web31804.mail.mud.yahoo.com>
In-Reply-To: <1338310699.60023.YahooMailNeo@web31804.mail.mud.yahoo.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------040104030904070704080501"
Cc: "kitten@ietf.org" 
Subject: Re: [kitten] problems submitting....
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Common Authentication Technologies - Next Generation 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 May 2012 18:05:45 -0000

This is a multi-part message in MIME format.
--------------040104030904070704080501
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 29/05/2012 17:58, William Mills wrote:
> I've tried uploading a draft though the tool and it fails the nit's 
> upload check.  I sent an e-mail submission it last week and have 
> gotten no reply.  How do I move this along?  I'm stuck.
>
Hi,
Send me your .txt version and I will try to submit it. If that doesn't 
work, I will submit to Secretariat over email.

Regards,
Alexey


--------------040104030904070704080501
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    On 29/05/2012 17:58, William Mills wrote:
    

      

        
I've tried uploading a draft though the tool and it fails
          the nit's upload check.  I sent an e-mail submission it last
          week and have gotten no reply.  How do I move this along?  I'm
          stuck.

        

      

    

    Hi,

    Send me your .txt version and I will try to submit it. If that
    doesn't work, I will submit to Secretariat over email.

    

    Regards,

    Alexey

     

  


--------------040104030904070704080501--

From internet-drafts@ietf.org  Wed May 30 09:44:45 2012
Return-Path: 
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCDD611E80CA; Wed, 30 May 2012 09:44:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 7EgUQ-66JmAr; Wed, 30 May 2012 09:44:45 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2419B11E80AE; Wed, 30 May 2012 09:44:45 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.02
Message-ID: <20120530164445.23685.26184.idtracker@ietfa.amsl.com>
Date: Wed, 30 May 2012 09:44:45 -0700
Cc: kitten@ietf.org
Subject: [kitten] I-D Action: draft-ietf-kitten-gssapi-extensions-iana-07.txt
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Common Authentication Technologies - Next Generation 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 May 2012 16:44:46 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies. This draft is a work item of the Common Authentication Technology Next=
 Generation Working Group of the IETF.

	Title           : Namespace Considerations and Registries for GSS-API Exte=
nsions
	Author(s)       : Nicolas Williams
                          Alexey Melnikov
	Filename        : draft-ietf-kitten-gssapi-extensions-iana-07.txt
	Pages           : 10
	Date            : 2012-05-30

   This document describes the ways in which the GSS-API may be extended
   and directs the creation of an IANA registry for various GSS-API
   namespaces.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-kitten-gssapi-extensions-ian=
a-07.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-kitten-gssapi-extensions-iana=
-07.txt

The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-kitten-gssapi-extensions-iana/


From internet-drafts@ietf.org  Wed May 30 12:02:27 2012
Return-Path: 
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 396F811E8181; Wed, 30 May 2012 12:02:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.18
X-Spam-Level: 
X-Spam-Status: No, score=-102.18 tagged_above=-999 required=5 tests=[AWL=0.419, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 NYjZWuV6+2bN; Wed, 30 May 2012 12:02:26 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93B3711E815E; Wed, 30 May 2012 12:02:26 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.02
Message-ID: <20120530190226.12880.56537.idtracker@ietfa.amsl.com>
Date: Wed, 30 May 2012 12:02:26 -0700
Cc: kitten@ietf.org
Subject: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-01.txt
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Common Authentication Technologies - Next Generation 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 May 2012 19:02:27 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies. This draft is a work item of the Common Authentication Technology Next=
 Generation Working Group of the IETF.

	Title           : A SASL and GSS-API Mechanism for OAuth
	Author(s)       : William Mills
                          Tim Showalter
                          Hannes Tschofenig
	Filename        : draft-ietf-kitten-sasl-oauth-01.txt
	Pages           : 21
	Date            : 2012-05-30

   OAuth enables a third-party application to obtain limited access to a
   protected resource, either on behalf of a resource owner by
   orchestrating an approval interaction, or by allowing the third-party
   application to obtain access on its own behalf.

   This document defines how an application client uses OAuth over the
   Simple Authentication and Security Layer (SASL) or the Generic
   Security Service Application Program Interface (GSS-API) to access a
   protected resource at a resource serve.  Thereby, it enables schemes
   defined within the OAuth framework for non-HTTP-based application
   protocols.

   Clients typically store the user's long term credential.  This does,
   however, lead to significant security vulnerabilities, for example,
   when such a credential leaks.  A significant benefit of OAuth for
   usage in those clients is that the password is replaced by a token.
   Tokens typically provided limited access rights and can be managed
   and revoked separately from the user's long-term credential
   (password).


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-kitten-sasl-oauth-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-kitten-sasl-oauth-01.txt

The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-kitten-sasl-oauth/


From wmills@yahoo-inc.com  Wed May 30 14:57:15 2012
Return-Path: 
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AFE61F0C5E for ; Wed, 30 May 2012 14:57:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.081
X-Spam-Level: 
X-Spam-Status: No, score=-17.081 tagged_above=-999 required=5 tests=[AWL=0.517, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15]
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 rX40R9ev6ccc for ; Wed, 30 May 2012 14:57:14 -0700 (PDT)
Received: from nm4-vm0.bullet.mail.ac4.yahoo.com (nm4-vm0.bullet.mail.ac4.yahoo.com [98.139.53.206]) by ietfa.amsl.com (Postfix) with SMTP id 0D68A1F0C5D for ; Wed, 30 May 2012 14:57:13 -0700 (PDT)
Received: from [98.139.52.192] by nm4.bullet.mail.ac4.yahoo.com with NNFMP; 30 May 2012 21:57:08 -0000
Received: from [98.139.52.176] by tm5.bullet.mail.ac4.yahoo.com with NNFMP; 30 May 2012 21:57:08 -0000
Received: from [127.0.0.1] by omp1059.mail.ac4.yahoo.com with NNFMP; 30 May 2012 21:57:08 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 742924.70854.bm@omp1059.mail.ac4.yahoo.com
Received: (qmail 68939 invoked by uid 60001); 30 May 2012 21:57:08 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1338415028; bh=c+1VG3DkViERjvQlJY0h+GviuZjG6ehMjufr3inFsaw=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=MvV0eBPEexkKWTqA6ak7XVRmvpRti0qRnD6RoIIGrU4NoDvhSMlLO8Kods8xhSE8TiCBir7hftXkA+AwhAPa0JxOyxUi68FTcY8FGMwpngeXC4VVNN6LNEkHeZ//HxJuc3iMzFYqBFjOpEey5EaRMDHZg/h7p9bdn5BMHGRsMdA=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=WV0UxZxYba3n71qeU7rRsUtKQ8kJltv/5NBFIn4kByg6kd81JiKXYAp905hnc+3P+J75AoLAAlDvZQOyQU/1ukF0Cgkp/MVs/XSxnNydABqgAlPswYIXYD/8xwPQOasoxFIR6LAmDn+gzFC/HzjCbQKe0+5qsU9ToPbMheRab70=;
X-YMail-OSG: qL24jmwVM1n0y_zojz19uVQ3kYAjtL292nJO1tQiENf1S8z 0WhEkqc4Vm9t_DjTrebQfAWwI7sLhSd.S5NrepsTioluKFm2KXSCMzM8HxT0 z5mdNb03ULgdEzl.zbYCVexON2SlYCdO48vvQuhoZHVJJSSrRXnLOnRw0iL7 5vGKxfKXfKaczdfjIoHtKkfLKb1k6qrsotAAcl2NLnXXn_MCQaqX6YGKsgcl QaaxPqpH0LwrwG8X2gfZ5koZRrCxmg9cv48MUww9Qd2VpBgqOV7DjTqCBxDX gw_EzRVnaWYCi8jsz6A1.bZ6lVxM1Bj3oiborAkSUMXJBh14X9KVgP9Uq9GV TqezUt9W2qWcN_c1i8s_pAqJNB6x8Qy6b8VWKMA2SLPaQ6st8ybO5jYTUFuY VOlrH4W67D_.hnpAJzZ8EOcLvHoyA_mxC8dpuH2kIje39hctxmg--
Received: from [209.131.62.120] by web31802.mail.mud.yahoo.com via HTTP; Wed, 30 May 2012 14:57:08 PDT
X-RocketYMMF: william_john_mills
X-Mailer: YahooMailWebService/0.8.118.349524
References: <20120530190226.12880.56537.idtracker@ietfa.amsl.com>
Message-ID: <1338415028.63249.YahooMailNeo@web31802.mail.mud.yahoo.com>
Date: Wed, 30 May 2012 14:57:08 -0700 (PDT)
From: William Mills 
To: "kitten@ietf.org" 
In-Reply-To: <20120530190226.12880.56537.idtracker@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="-1036955950-1583371570-1338415028=:63249"
Subject: Re: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-01.txt
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: William Mills 
List-Id: Common Authentication Technologies - Next Generation 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 May 2012 21:57:15 -0000

---1036955950-1583371570-1338415028=:63249
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

This draft rips out the HTTP style format and in band discovery.=A0 Feedbac=
k would be very welcome.=0A=0AMany thanks to Alexey for helping me get this=
 posted.=0A=0A-bill=0A=0A=0A=0A=0A=0A>________________________________=0A> =
From: "internet-drafts@ietf.org" =0A>To: i-d-anno=
unce@ietf.org =0A>Cc: kitten@ietf.org =0A>Sent: Wednesday, May 30, 2012 12:=
02 PM=0A>Subject: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-01.txt=
=0A> =0A>=0A>A New Internet-Draft is available from the on-line Internet-Dr=
afts directories. This draft is a work item of the Common Authentication Te=
chnology Next Generation Working Group of the IETF.=0A>=0A>=A0=A0=A0 Title=
=A0 =A0 =A0 =A0 =A0  : A SASL and GSS-API Mechanism for OAuth=0A>=A0=A0=A0 =
Author(s)=A0 =A0 =A0  : William Mills=0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 Tim Showalter=0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 Hannes Tschofenig=0A>=A0=A0=A0 Filename=A0 =A0 =A0 =A0 : dr=
aft-ietf-kitten-sasl-oauth-01.txt=0A>=A0=A0=A0 Pages=A0 =A0 =A0 =A0 =A0  : =
21=0A>=A0=A0=A0 Date=A0 =A0 =A0 =A0 =A0 =A0 : 2012-05-30=0A>=0A>=A0  OAuth =
enables a third-party application to obtain limited access to a=0A>=A0  pro=
tected resource, either on behalf of a resource owner by=0A>=A0  orchestrat=
ing an approval interaction, or by allowing the third-party=0A>=A0  applica=
tion to obtain access on its own behalf.=0A>=0A>=A0  This document defines =
how an application client uses OAuth over the=0A>=A0  Simple Authentication=
 and Security Layer (SASL) or the Generic=0A>=A0  Security Service Applicat=
ion Program Interface (GSS-API) to access a=0A>=A0  protected resource at a=
 resource serve.=A0 Thereby, it enables schemes=0A>=A0  defined within the =
OAuth framework for non-HTTP-based application=0A>=A0  protocols.=0A>=0A>=
=A0  Clients typically store the user's long term credential.=A0 This does,=
=0A>=A0  however, lead to significant security vulnerabilities, for example=
,=0A>=A0  when such a credential leaks.=A0 A significant benefit of OAuth f=
or=0A>=A0  usage in those clients is that the password is replaced by a tok=
en.=0A>=A0  Tokens typically provided limited access rights and can be mana=
ged=0A>=A0  and revoked separately from the user's long-term credential=0A>=
=A0  (password).=0A>=0A>=0A>A URL for this Internet-Draft is:=0A>http://www=
.ietf.org/internet-drafts/draft-ietf-kitten-sasl-oauth-01.txt=0A>=0A>Intern=
et-Drafts are also available by anonymous FTP at:=0A>ftp://ftp.ietf.org/int=
ernet-drafts/=0A>=0A>This Internet-Draft can be retrieved at:=0A>ftp://ftp.=
ietf.org/internet-drafts/draft-ietf-kitten-sasl-oauth-01.txt=0A>=0A>The IET=
F datatracker page for this Internet-Draft is:=0A>https://datatracker.ietf.=
org/doc/draft-ietf-kitten-sasl-oauth/=0A>=0A>______________________________=
_________________=0A>Kitten mailing list=0A>Kitten@ietf.org=0A>https://www.=
ietf.org/mailman/listinfo/kitten=0A>=0A>=0A>
---1036955950-1583371570-1338415028=:63249
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable


This draft rips out the HTTP style format and in band discovery.  Fe=
edback would be very welcome.

=
Many thanks to Alexey for helping me get this posted.

-bill


  
 =

 
  
  From: "internet-drafts=
@ietf.org" <internet-drafts@ietf.org>
 To: i-d-announce@ietf.org 
Cc: kitten@ietf.org 
 Sent: Wednesday, May 30, 2012 12:02 PM
 Subject: [kitten] I-D Action: draft-=
ietf-kitten-sasl-oauth-01.txt
  
 
=0A
A New Internet-=
Draft is available from the on-line Internet-Drafts directories. This draft=
 is a work item of the Common Authentication Technology Next Generation Wor=
king Group of the IETF.

    Title     =
      : A SASL and GSS-API Mechanism for OAuth
  &nb=
sp; Author(s)       : William Mills
      =
                    Tim S=
howalter
                  =
        Hannes Tschofenig
    Filenam=
e        : draft-ietf-kitten-sasl-oauth-01.txt
 =
;   Pages           : 21
  =
  Date            : 2012-05-30

&n=
bsp;  OAuth enables a third-party application to obtain limited access to a=

   protected resource, either on behalf
 of a resource owner by
   orchestrating an approval interaction, o=
r by allowing the third-party
   application to obtain access on it=
s own behalf.

   This document defines how an application clien=
t uses OAuth over the
   Simple Authentication and Security Layer (=
SASL) or the Generic
   Security Service Application Program Interf=
ace (GSS-API) to access a
   protected resource at a resource serve=
.  Thereby, it enables schemes
   defined within the OAuth fra=
mework for non-HTTP-based application
   protocols.

   =
Clients typically store the user's long term credential.  This does,   however, lead to significant security vulnerabilities, for exampl=
e,
   when such a credential leaks.  A significant benefit of =
OAuth for
   usage in those clients is that the password is replace=
d by a token.
   Tokens typically provided limited access
 rights and can be managed
   and revoked separately from the user'=
s long-term credential
   (password).


A URL for this Int=
ernet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-kitten-sa=
sl-oauth-01.txt

Internet-Drafts are also available by anonymous FTP =
at:
ft=
p://ftp.ietf.org/internet-drafts/

This Internet-Draft can be ret=
rieved at:
ftp://ftp.ietf.org/internet-drafts/=
draft-ietf-kitten-sasl-oauth-01.txt

The IETF datatracker page fo=
r this Internet-Draft is:
https://datatracker.ietf.org=
/doc/draft-ietf-kitten-sasl-oauth/

_____________________________=
__________________
Kitten mailing list
Kitten@ietf.org
https://www.ietf.or=
g/mailman/listinfo/kitten


 
 
 
=
   
---1036955950-1583371570-1338415028=:63249--

From simon@josefsson.org  Thu May 31 00:08:11 2012
Return-Path: 
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4720621F8610 for ; Thu, 31 May 2012 00:08:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.656
X-Spam-Level: 
X-Spam-Status: No, score=-98.656 tagged_above=-999 required=5 tests=[AWL=1.253, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, USER_IN_WHITELIST=-100]
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 G4BwKWIFrouv for ; Thu, 31 May 2012 00:08:10 -0700 (PDT)
Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id 4056F21F8418 for ; Thu, 31 May 2012 00:08:09 -0700 (PDT)
Received: from latte (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q4V77oTn028744 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 31 May 2012 09:07:52 +0200
From: Simon Josefsson 
To: William Mills 
References: <20120530190226.12880.56537.idtracker@ietfa.amsl.com> <1338415028.63249.YahooMailNeo__38044.4741262638$1338415043$gmane$org@web31802.mail.mud.yahoo.com>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:120531:kitten@ietf.org::RGnV0egTz953QQIs:9umd
X-Hashcash: 1:22:120531:wmills@yahoo-inc.com::FFT8bXSWFt4MtaOj:F3Q7
Date: Thu, 31 May 2012 09:07:45 +0200
In-Reply-To: <1338415028.63249.YahooMailNeo__38044.4741262638$1338415043$gmane$org@web31802.mail.mud.yahoo.com> (William Mills's message of "Wed, 30 May 2012 14:57:08 -0700 (PDT)")
Message-ID: <87zk8orfpa.fsf@latte.josefsson.org>
User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/23.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Virus-Scanned: clamav-milter 0.97.3 at yxa-v
X-Virus-Status: Clean
Cc: "kitten@ietf.org" 
Subject: Re: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-01.txt
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Common Authentication Technologies - Next Generation 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 May 2012 07:08:11 -0000

This version looks much better to me -- thanks!

As we discovered for RFC 6595, you may want to expand the TLS
certificate verification text with some RFC 6125 wording.  See fifth
paragraph of section 4 of RFC 6595.  It should also explain which
identity string is compared to what's in the certificate.

Also, it seems this variant supports the PLUS channel-binding enabled
variant (I have not read the draft in detail there, but it is
mentioned), so shouldn't it then also be able to support per-message
tokens and GSS_Pseudo_random?  This could be done similar to SAML20EC
(which is work in progress, but the mechanism it eventually uses could
be the same).

/Simon

From internet-drafts@ietf.org  Thu May 31 07:43:30 2012
Return-Path: 
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67D7521F86F2; Thu, 31 May 2012 07:43:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 F8sE+UQJcp4M; Thu, 31 May 2012 07:43:30 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7E9C21F86D3; Thu, 31 May 2012 07:43:29 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.02
Message-ID: <20120531144329.31357.22092.idtracker@ietfa.amsl.com>
Date: Thu, 31 May 2012 07:43:29 -0700
Cc: kitten@ietf.org
Subject: [kitten] I-D Action: draft-ietf-kitten-gssapi-naming-exts-15.txt
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Common Authentication Technologies - Next Generation 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 May 2012 14:43:30 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies. This draft is a work item of the Common Authentication Technology Next=
 Generation Working Group of the IETF.

	Title           : GSS-API Naming Extensions
	Author(s)       : Nicolas Williams
                          Leif Johansson
                          Sam Hartman
                          Simon Josefsson
	Filename        : draft-ietf-kitten-gssapi-naming-exts-15.txt
	Pages           : 19
	Date            : 2012-05-31

   The Generic Security Services API (GSS-API) provides a simple naming
   architecture that supports name-based authorization.  This document
   introduces new APIs that extend the GSS-API naming model to support
   name attribute transfer between GSS-API peers.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-kitten-gssapi-naming-exts-15=
.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-kitten-gssapi-naming-exts-15.=
txt

The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-kitten-gssapi-naming-exts/


From wmills@yahoo-inc.com  Thu May 31 07:56:49 2012
Return-Path: 
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B17021F86D6 for ; Thu, 31 May 2012 07:56:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.599
X-Spam-Level: 
X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15]
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 gB2+B2iq2x4U for ; Thu, 31 May 2012 07:56:48 -0700 (PDT)
Received: from nm4.bullet.mail.sp2.yahoo.com (nm4.bullet.mail.sp2.yahoo.com [98.139.91.74]) by ietfa.amsl.com (Postfix) with SMTP id 9D33C21F86BD for ; Thu, 31 May 2012 07:56:48 -0700 (PDT)
Received: from [72.30.22.92] by nm4.bullet.mail.sp2.yahoo.com with NNFMP; 31 May 2012 14:56:46 -0000
Received: from [98.139.91.33] by tm14.bullet.mail.sp2.yahoo.com with NNFMP; 31 May 2012 14:56:46 -0000
Received: from [127.0.0.1] by omp1033.mail.sp2.yahoo.com with NNFMP; 31 May 2012 14:56:45 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 987211.23264.bm@omp1033.mail.sp2.yahoo.com
Received: (qmail 43994 invoked by uid 60001); 31 May 2012 14:56:45 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1338476205; bh=jW63xohsFeSQt3mcFAaYWKrTjN1f+vhERSxCcMU3GMg=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=QRCSFT5ZWiKJQcGRg0ce1mlcTse/8TfZDCLQR+zhi3ymOayTzu2GQgi3xqCqhb7jNM9BAbBNwou82oGZSfvfaIXDTjyBs5iW54GoxMqZrZLENxvlEWUhNtxrbGcbdUR8badpLASNoE5SSqRcMuGbJlrFsGNJMQMkMX8X9kvHXcY=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=LdVW2mz49zl8peQE13tSixWHrDLHpasgKAUS4ij1Fz/mnQYrptVWGxB5VQN/AGqghyXo0hv3e7aPkn1zESeunD6VLPEeXY4ghktoKnQOqmcTz19DCq0euKZvPrnJ9h7GfYw4kyNl2SZWYBfUKRLu/MOAD1NtPN7iC5ewnGmZpIs=;
X-YMail-OSG: 5Q3ycAsVM1n3d7Y2_rQA_P2D__LX5.9KKjBwR5kTM4RvbjL s5N6dc7YPQwIKiiZBRE0vS0rphtrkDz1k5od38dA3HbjTOV2IItroREBauQM GUFxQLjrCJv_OG1WUOO5fx7afSzR2NIWCSgUM8R0UBgeu5QtV6jTJFnV8aRH QHC7rg6NHxJRLPJetBNAp_CG11w0Bn1bEDDFOsDSfPQz7DQLdmOGAvHTKdIg rBLuaQI7hfitFjaMkUl6GG93xSbCWutbf3tU0T114LFAv3XTX_ZjyfTPChj8 DGr8LlQqURVsX7YJ8fAZ8uaZtJtQGdOsS49_RfPKplx_onSdeKBM4rjmT2lP t1JO_PiNOiU3cOwLKX1W2Fc59P3dt7d.x79smAl3POYOsI4r1MG9kj6j5p0Y CswPBMvLmLpSNgLyDRbngXh9dIyM-
Received: from [99.31.212.42] by web31807.mail.mud.yahoo.com via HTTP; Thu, 31 May 2012 07:56:45 PDT
X-RocketYMMF: william_john_mills
X-Mailer: YahooMailWebService/0.8.118.349524
References: <20120530190226.12880.56537.idtracker@ietfa.amsl.com> <1338415028.63249.YahooMailNeo__38044.4741262638$1338415043$gmane$org@web31802.mail.mud.yahoo.com> <87zk8orfpa.fsf@latte.josefsson.org>
Message-ID: <1338476205.39484.YahooMailNeo@web31807.mail.mud.yahoo.com>
Date: Thu, 31 May 2012 07:56:45 -0700 (PDT)
From: William Mills 
To: Simon Josefsson 
In-Reply-To: <87zk8orfpa.fsf@latte.josefsson.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "kitten@ietf.org" 
Subject: Re: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-01.txt
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: William Mills 
List-Id: Common Authentication Technologies - Next Generation 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 May 2012 14:56:49 -0000

=0A=0A=0A=0A=0A>________________________________=0A> From: Simon Josefsson =
=0A>To: William Mills  =0A>Cc: "=
kitten@ietf.org"  =0A>Sent: Thursday, May 31, 2012 12:07 A=
M=0A>Subject: Re: I-D Action: draft-ietf-kitten-sasl-oauth-01.txt=0A> =0A>T=
his version looks much better to me -- thanks!=0A>=0A>As we discovered for =
RFC 6595, you may want to expand the TLS=0A>certificate verification text w=
ith some RFC 6125 wording.=A0 See fifth=0A>paragraph of section 4 of RFC 65=
95.=A0 It should also explain which=0A>identity string is compared to what'=
s in the certificate.=0A=0AI'll take a look, thanks.=0A=0A>=0A>Also, it see=
ms this variant supports the PLUS channel-binding enabled=0A>variant (I hav=
e not read the draft in detail there, but it is=0A>mentioned), so shouldn't=
 it then also be able to support per-message=0A>tokens and GSS_Pseudo_rando=
m?=A0 This could be done similar to SAML20EC=0A>(which is work in progress,=
 but the mechanism it eventually uses could=0A>be the same).=0A=0A=0AYes, i=
t's -PLUS instead of doing CB in a single profile.=A0 In the draft it=0Adis=
cusses the fact that some auth profiles have secrets that can be used=0Afor=
 per message signing, so I think it COULD support per message tokens. If=0A=
there is no shared secret to use I don't think there's a way to bootstrap =
=0A=0Athis in channel that increases the security properties.=0A=0A=0A>=0A>=
/Simon=0A>=0A>=0A>

From cantor.2@osu.edu  Thu May 31 08:00:57 2012
Return-Path: 
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEB5321F86F3 for ; Thu, 31 May 2012 08:00:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 XsT+PbIjwgR4 for ; Thu, 31 May 2012 08:00:56 -0700 (PDT)
Received: from defang22.it.ohio-state.edu (defang22.it.ohio-state.edu [128.146.216.225]) by ietfa.amsl.com (Postfix) with ESMTP id 611A921F8723 for ; Thu, 31 May 2012 08:00:54 -0700 (PDT)
Received: from CIO-KRC-HT02.osuad.osu.edu (cio-krc-ht02.osuad.osu.edu [164.107.81.40]) by defang22.it.ohio-state.edu (8.13.1/8.13.1) with ESMTP id q4VF0oBW003120; Thu, 31 May 2012 11:00:52 -0400
Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-KRC-HT02.osuad.osu.edu ([fe80::8554:1787:2a7:72c9%12]) with mapi id 14.01.0355.002; Thu, 31 May 2012 11:00:41 -0400
From: "Cantor, Scott" 
To: William Mills , Simon Josefsson 
Thread-Topic: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-01.txt
Thread-Index: AQHNPz2Y0LlRP4fEMUi0rtO0jGMO15bj/csA
Date: Thu, 31 May 2012 15:00:40 +0000
Message-ID: 
In-Reply-To: <1338476205.39484.YahooMailNeo@web31807.mail.mud.yahoo.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [128.146.178.28]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <269A273635768443A46E940394FBEEA3@exchange.osu.edu>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CanIt-Geo: ip=164.107.81.40; country=US; region=OH; city=Wooster; postalcode=44691; latitude=40.8077; longitude=-81.9730; metrocode=510; areacode=330; http://maps.google.com/maps?q=40.8077,-81.9730&z=6
X-CanItPRO-Stream: outbound
X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.225
Cc: "kitten@ietf.org" 
Subject: Re: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-01.txt
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Common Authentication Technologies - Next Generation 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 May 2012 15:00:57 -0000

On 5/31/12 10:56 AM, "William Mills"  wrote:
>
>Yes, it's -PLUS instead of doing CB in a single profile.  In the draft it
>discusses the fact that some auth profiles have secrets that can be used
>for per message signing, so I think it COULD support per message tokens.
>If
>there is no shared secret to use I don't think there's a way to bootstrap
>this in channel that increases the security properties.

I have the same issue, but I'm told that some application usage of GSS
require this, even if it's not secure. I've basically settled on passing a
nonce up from the client as the simplest option and one that makes the
lack of security self-evident.

The other point is that when there is a key, deriving the session key is
going to require some algorithm-specific language somewhere, and it would
be nice if the SAML mechanism and the OAuth mechanism used the same key
derivations.

-- Scott


From iesg-secretary@ietf.org  Thu May 31 11:47:36 2012
Return-Path: 
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEFEC21F8700; Thu, 31 May 2012 11:47:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.214
X-Spam-Level: 
X-Spam-Status: No, score=-102.214 tagged_above=-999 required=5 tests=[AWL=0.385, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 P1N9-gFelhVc; Thu, 31 May 2012 11:47:36 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D233321F8702; Thu, 31 May 2012 11:47:35 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG 
To: IETF-Announce 
X-Test-IDTracker: no
X-IETF-IDTracker: 4.02
Message-ID: <20120531184735.29874.40909.idtracker@ietfa.amsl.com>
Date: Thu, 31 May 2012 11:47:35 -0700
Cc: kitten mailing list , kitten chair , RFC Editor 
Subject: [kitten] Protocol Action: 'GSS-API Naming Extensions' to Proposed Standard	(draft-ietf-kitten-gssapi-naming-exts-15.txt)
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Common Authentication Technologies - Next Generation 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 May 2012 18:47:37 -0000

The IESG has approved the following document:
- 'GSS-API Naming Extensions'
  (draft-ietf-kitten-gssapi-naming-exts-15.txt) as Proposed Standard

This document is the product of the Common Authentication Technology Next
Generation Working Group.

The IESG contact persons are Stephen Farrell and Sean Turner.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-kitten-gssapi-naming-exts/




Technical Summary

  The Generic Security Services API (GSS-API) provides a simple naming
  architecture that supports name-based authorization.  This document
  introduces new APIs that extend the GSS-API naming model to support
  name attribute transfer between GSS-API peers.

Working Group Summary

  Nothing worth noting regarding WG process.

Document Quality

  This protocol has been implemented in the MIT 1.8 release.  At least 
  one other vendor has plans on implementing this in the future as well.

Personnel

  The document shepherd is Shawn Emery
  The responsible AD is Stephen Farrell