From nobody Sun Oct 4 13:12:56 2015 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F1701A1B47 for ; Sun, 4 Oct 2015 13:12:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.238 X-Spam-Level: X-Spam-Status: No, score=0.238 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i8ZIWi5--vbG for ; Sun, 4 Oct 2015 13:12:52 -0700 (PDT) Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [IPv6:2001:6b0:8:2::201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72D251A1B2B for ; Sun, 4 Oct 2015 13:12:52 -0700 (PDT) Received: from smtp1.sunet.se (smtp1.sunet.se [192.36.171.214]) by e-mailfilter01.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id t94KCjIN000423 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 4 Oct 2015 22:12:45 +0200 Received: from kerio.sunet.se (kerio.sunet.se [192.36.171.210]) by smtp1.sunet.se (8.14.9/8.14.7) with ESMTP id t94KCf5P016988 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 4 Oct 2015 22:12:44 +0200 (CEST) VBR-Info: md=sunet.se; mc=all; mv=swamid.se DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sunet.se; s=default; t=1443989564; bh=75S7fWspNvwGZ89M/KfG/f6mPepF6LzVHbL+yl3LObI=; h=To:Cc:From:Subject:Date; b=jx4t2Pf3YB1qz/q9pupyKIXKZIl/FKnCuDmWpQZF8+W30OfC6y9stdSTNukB4nIqO aCt19s9BSs4n4S8iwOR+AT9Tg0aJ4CJ5Qu4HOqUoMA/8iFej2v8Ms/DFQN825YGZ5I UohvSdDhMfV37SUwuR7JniBThIX7LFbj2TdDqLzs= X-Footer: c3VuZXQuc2U= Received: from [10.12.136.13] ([192.171.20.23]) (authenticated user leifj@sunet.se) by kerio.sunet.se (Kerio Connect 8.3.4 patch 1) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256 bits)); Sun, 4 Oct 2015 22:12:39 +0200 To: abfab@ietf.org From: Leif Johansson Message-ID: <56118835.4090706@sunet.se> Date: Sun, 4 Oct 2015 22:12:37 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, outbound-sunet-se:default, sunet-se:default, base:default, @@RPTN) X-CanIt-Geo: ip=192.36.171.210; country=SE; latitude=59.3294; longitude=18.0686; http://maps.google.com/maps?q=59.3294,18.0686&z=6 X-CanItPRO-Stream: outbound-sunet-se:outbound (inherits from outbound-sunet-se:default, sunet-se:default, base:default) X-Canit-Stats-ID: 09Pp8cJTm - 9398a7fda26c - 20151004 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw Received-SPF: neutral (e-mailfilter01.sunet.se: 192.36.171.210 is neither permitted nor denied by domain leifj@sunet.se) receiver=e-mailfilter01.sunet.se; client-ip=192.36.171.210; envelope-from=; helo=smtp1.sunet.se; identity=mailfrom X-Scanned-By: CanIt (www . roaringpenguin . com) on 192.36.171.201 Archived-At: Subject: [abfab] final piece of the puzzle - OASIS SSTC review X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Oct 2015 20:12:55 -0000 I had a chat with Scott Cantor today and he explained that the OASIS SSTC is not really able to provide review beyond the reivew that Scott already has done on aaa-saml and we should just take that review we got and declare victory. I am certainly in favor of such an approach and unless there are objections (Stephen?) the chairs will proceed with writeup of aaa-saml Cheers Leif From nobody Sun Oct 4 13:43:42 2015 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B81531A3BA0 for ; Sun, 4 Oct 2015 13:43:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.911 X-Spam-Level: X-Spam-Status: No, score=-2.911 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W2osmBpxYCOD for ; Sun, 4 Oct 2015 13:43:40 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 091F71A3B9D for ; Sun, 4 Oct 2015 13:43:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E301DBEE3; Sun, 4 Oct 2015 21:43:36 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ME35luOrgEOF; Sun, 4 Oct 2015 21:43:35 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.22.228]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 3788FBEDD; Sun, 4 Oct 2015 21:43:35 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1443991415; bh=xymnrx0/5J7sA8bCyMksfQVweJdb++nIe7Qu43Oih3E=; h=Subject:To:References:From:Date:In-Reply-To:From; b=yYJ18A3PBhPa3LkgUV58oMwBt8XH1B3quCrAP+IHlug4k3RNYLQHl6MEDxHfymjP5 DpdXdrntKq3wMjMDcpELxSCiibssnnPfbK2U5XyVTOjt6jiX83ge4TcSCNbC+kYPGe /Wq1PD7c7rIAmoCB5b3ybJR5Q/zVj5ghwNAFItms= To: Leif Johansson , abfab@ietf.org References: <56118835.4090706@sunet.se> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <56118F76.3020107@cs.tcd.ie> Date: Sun, 4 Oct 2015 21:43:34 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <56118835.4090706@sunet.se> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [abfab] final piece of the puzzle - OASIS SSTC review X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Oct 2015 20:43:41 -0000 On 04/10/15 21:12, Leif Johansson wrote: > > I had a chat with Scott Cantor today and he explained that the > OASIS SSTC is not really able to provide review beyond the reivew > that Scott already has done on aaa-saml and we should just take > that review we got and declare victory. > > I am certainly in favor of such an approach and unless there are > objections (Stephen?) the chairs will proceed with writeup of > aaa-saml I've no obnjection at this point. If I have any when I read it I'll let you know and that won't take 1103 days:-) So yes, fire ahead please. S. > > Cheers Leif > From nobody Sun Oct 4 13:51:52 2015 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 709331A6F29 for ; Sun, 4 Oct 2015 13:51:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mzs0wr8037Nu for ; Sun, 4 Oct 2015 13:51:50 -0700 (PDT) Received: from mail-qg0-f53.google.com (mail-qg0-f53.google.com [209.85.192.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3DC21A6F27 for ; Sun, 4 Oct 2015 13:51:48 -0700 (PDT) Received: by qgt47 with SMTP id 47so134430027qgt.2 for ; Sun, 04 Oct 2015 13:51:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=dHzHzhkzMx7mQz7kG548+kzvvVOayZcsOhVsL+MofXM=; b=EbJVdlm4Kp25iPJyHg2tXgU1UwRoMWPWej/EVWZJl1W9ITLn8+2we1f8JrrmBphGiA Wilk48qbWZCr3gG+jzTDjT6N/9g7dyXq7EnfFBmCvD0gEaei1b/ORMEF9yU7LMt7IoiP NkBx77nkeF6tlHXFI8kxoh/eVMS38ArV3DDLjuFtljPmSTnPqY5/9PCFCigwVrI6qQ0E Psemf5icSjdDLCbL31Sps9nHmGmxuf0vwZq1/DyrdGkkeXf3fGGn4NnhsM8qAmLCoSiU vPl+5d0lnYE2v0aEjKBM69/Ylj/nWY12l4Nx4v0Lwj6yWeyfvGsD8wWDhl0xNx6Ujap/ A/xA== X-Gm-Message-State: ALoCoQkceG95NKd2EasTMh2E46PXDsGrFSH310KOHGasAPyPRhbvcUA1PpXJe9PrQ+lmZhVowEkz X-Received: by 10.140.194.8 with SMTP id p8mr37178698qha.63.1443991907944; Sun, 04 Oct 2015 13:51:47 -0700 (PDT) Received: from [10.12.136.13] ([192.171.20.23]) by smtp.googlemail.com with ESMTPSA id 68sm9642197qhc.49.2015.10.04.13.51.46 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 04 Oct 2015 13:51:47 -0700 (PDT) To: abfab@ietf.org References: <56118835.4090706@sunet.se> <56118F76.3020107@cs.tcd.ie> From: Leif Johansson Message-ID: <56119162.4010409@mnt.se> Date: Sun, 4 Oct 2015 22:51:46 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <56118F76.3020107@cs.tcd.ie> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [abfab] final piece of the puzzle - OASIS SSTC review X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Oct 2015 20:51:51 -0000 On 2015-10-04 22:43, Stephen Farrell wrote: > > > On 04/10/15 21:12, Leif Johansson wrote: >> >> I had a chat with Scott Cantor today and he explained that the >> OASIS SSTC is not really able to provide review beyond the reivew >> that Scott already has done on aaa-saml and we should just take >> that review we got and declare victory. >> >> I am certainly in favor of such an approach and unless there are >> objections (Stephen?) the chairs will proceed with writeup of >> aaa-saml > > I've no obnjection at this point. If I have any when I read > it I'll let you know and that won't take 1103 days:-) So yes, > fire ahead please. Ok then... There are very few idnits [1] so maybe we can fix those when the document hits IESG. [1] https://www.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-abfab-aaa-saml-11.txt From nobody Sun Oct 4 13:57:19 2015 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E200B1A6F39 for ; Sun, 4 Oct 2015 13:57:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FJHROkg0AyH0 for ; Sun, 4 Oct 2015 13:57:14 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0135.outbound.protection.outlook.com [207.46.100.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61A511A6F3A for ; Sun, 4 Oct 2015 13:57:14 -0700 (PDT) Received: from BY2FFO11HUB041.protection.gbl (10.1.14.82) by BY2FFO11HUB040.protection.gbl (10.1.14.161) with Microsoft SMTP Server (TLS) id 15.1.286.14; Sun, 4 Oct 2015 20:57:13 +0000 Received: from BY2FFO11FD045.protection.gbl (10.1.14.30) by BY2FFO11HUB041.protection.gbl (10.1.14.82) with Microsoft SMTP Server (TLS) id 15.1.286.14; Sun, 4 Oct 2015 20:57:12 +0000 Authentication-Results: spf=pass (sender IP is 164.107.81.208) smtp.mailfrom=osu.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=osu.edu; Received-SPF: Pass (protection.outlook.com: domain of osu.edu designates 164.107.81.208 as permitted sender) receiver=protection.outlook.com; client-ip=164.107.81.208; helo=cio-krc-pf01.osuad.osu.edu; Received: from cio-krc-pf01.osuad.osu.edu (164.107.81.208) by BY2FFO11FD045.mail.protection.outlook.com (10.1.15.177) with Microsoft SMTP Server (TLS) id 15.1.286.14 via Frontend Transport; Sun, 4 Oct 2015 20:57:12 +0000 Received: from CIO-TNC-HT05.osuad.osu.edu (localhost [127.0.0.1]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by cio-krc-pf01.osuad.osu.edu (Postfix) with ESMTPS id 04D83A0037; Sun, 4 Oct 2015 16:57:11 -0400 (EDT) Received: from CIO-TNC-D2MBX02.osuad.osu.edu ([fe80::3960:dd86:ba2:ad26]) by CIO-TNC-HT05.osuad.osu.edu ([fe80::d0be:603:484c:5a2f%10]) with mapi id 14.03.0248.002; Sun, 4 Oct 2015 16:57:10 -0400 From: "Cantor, Scott" To: Leif Johansson , "abfab@ietf.org" Thread-Topic: [abfab] final piece of the puzzle - OASIS SSTC review Thread-Index: AQHQ/uERmdCUeRjzKk2z1LgXzRCYKJ5b0LQA Date: Sun, 4 Oct 2015 20:57:09 +0000 Message-ID: <7FC71EA1-8DE4-4DD0-AE57-DB0B249450F0@osu.edu> References: <56118835.4090706@sunet.se> In-Reply-To: <56118835.4090706@sunet.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [162.244.106.216] x-header-sapphire: true Content-Type: text/plain; charset="utf-8" Content-ID: <9F43AF31AE31164AB37CE8FF44B44C22@osu.edu> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11FD045; 1:6eaAk6ejHoHd9XWkVGsFYiFKYtd0k2Ir2eC2uYIwEX+NnaOtkGbx4Fc9394X5S8rOtsBmTAX8+SsvW966UAQnzqHrtc/YQW47zs/SYfPjXjuTHRARNAm/POm8yUUineTWvCaHEdLvbOCtCJTBl909EjUQQ410Y38cTbB1Sr7nRrpGQu6pdUvSbQLFCCQ9Dfq6QnkcIeJlFGNApLK8gcuVB0JyaD47loYB7WKRLNffgUMpnAcQ9Wd7n8UR41NMVwumtMfiwbaAPgjCsQZ7Jl2e6SLaJKjdrqxirp30+lsnz6jZLqMrR8e0T9eHq8ypjx+gB0CgH+Fpa0F43LqXNrlNsY2zVwk/9Iv8iBOysHo5lTgwlh2z0jCwB8jRThFlAoYnxpMQ35XMZ4xlMYcbl2//Q== X-Forefront-Antispam-Report: CIP:164.107.81.208; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(438002)(377454003)(24454002)(199003)(189002)(479174004)(106116001)(86362001)(19580405001)(19580395003)(5003600100002)(109096001)(106466001)(93346002)(89122001)(92566002)(87936001)(2950100001)(83716003)(2900100001)(102836002)(62966003)(189998001)(82746002)(6806005)(46102003)(77156002)(5008740100001)(5001830100001)(2501003)(33656002)(5001860100001)(5004730100002)(5250100002)(47776003)(50466002)(5001920100001)(4001540100001)(90282001)(66066001)(107886002)(5007970100001)(5001770100001)(64706001)(76176999)(54356999)(75432002)(11100500001)(50986999)(23676002)(36756003)(88552001)(217873001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2FFO11HUB041; H:cio-krc-pf01.osuad.osu.edu; FPR:; SPF:Pass; PTR:cio-krc-pf01.osuad.osu.edu; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11HUB041; 2:+7rQ4Nz9yuXuS4BtU7mDxrE9vpP8kVDxf4H+1K6FW9cZjm5/xCsqFtpmTLEW+WLkbiU6w2CRA2TIM19dhfbSxsOLv8ZSKdnpvOApnHOtngmk8xJoAhuiBJGX2l/4VwAMpeklvrG4s4MkNZyUCcLBeqvXdPRCVdI3AKhz9fM4KtI=; 3:3HM1zNramLBa6HuGK7YuAxazZTqCgyrb0gUPlYFocl2S6nE/NoidgT4nlrR4CQQfLi5sjom3/Stvsk0Cl7ElrUDhcd1U9GTDZTquuHLSmLmZIFc0LNwlW8m39PePTvyHZgjtH0f7lOQ6IuHkIB0SIE/rVUHM37p3f1MUSw1SOtRLEuB1lGbViYXaB7UIEYX5Ob3o7IDSexVNTVqYGbFh5N5tXIEVxc9Ms+AkRLgA5/1XoWD4vKVxBr6P3C8Eqi85cE2dgReZs0ZC6xW6FfGTFA==; 25:LOvZmaXQt9w7QWOYteuP9BGVDIEjeNCzCHEPIohH+TfnoOA7tw2e74VjBb09LnurhhpFm9/u/fiI5RqvhCfJdyloDnNjxxgFBsd8eGmKh2oVeaMHiMPK58EGfvcP+RAOUL/DIp2KGOtKfEwsvDOBE3xlw55A9hGN5tUWh4SPOfLkLnOcTfzjjgHEaqHR0Cgp2+/lhid09EH7YtbajsI2sQdMxYcTeMHsPBP0D+uEQ/wsOH0fUH/7hOXL+frAfouY+y+5Yealf0ZY1ANqeFG+8w== X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(8251501001); SRVR:BY2FFO11HUB041; X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11HUB041; 20:nRpGGJoeuAvD92bHGMv1jnV54E3T38hfhsWR0g5vKQErMmwUPPwWMCmjl3Ro8Gv6dh0EXyqJUexzCV1uhifHSmQEUUgOUqrbIjPyCvVoYOKmd/Ufr1XQPvRIqy2ioEP1CvqKGI7KyvVh7IX/EWnaFxH02h8Ynr9A3eDmRpdQVyZozm7E63dBlQl7Cw2xGLvSsVkSDXgMEjY5KbfvBOQ/8E7Pzdt41wHwGIdgPLDL1ih7J8VAnX29O2yqEqr59g1S4rknXuKjIub3N1VoMU7wmLLsfb8oDMFhbVcwvY44coT2Tv+0RPqS6r0r6iIqGU9dCOru/XANHSsTzbkKKR3b+O6/FX/t9OjxikIrLROtXXEmCYYPM6IPkm+co8/a7XDWle27nFMw/H8Gqmkp2oJYlgXRW3phRI42L3I950+z+KGpOG5ObyfJAreAv/L8vC5FHEtnYqkhRLzDgcpUl5f1pJD0iEra0GiAx0M+oKExMAHwOywqDwKrNJj09SstoDWg; 4:yBTJq5t+ijE/SeT8H446EZwsFamTY69PhWEm9O8K8FWIjIo8FZXbzBbSpbJr/v6ztDJum4z8PRDIDkRu6j4p6SPzqB46l/Ad0BsGmVxxkUsaFlX6L+RrtAJl7wbWRXLvuD5nt0FrvX/dSfOR/7mby7Ut9MZLu09JWgK7hODhLLMlSgYwH8GTqwe+vmqFjDqGYxPrutkatWFqsGl9GRTP1CyaTK4qDVez2TrKFxsW8k+ulminma0Z1TwLOdQivuC0n6KojwzxtZk3xogC6D/oMD7hVcWO/SpDKGFtZfede75yZUrCKLI5Jw0ZXlHXqvNsP2G5gM4Go7KQsK+rQZzJZvnb83QNQc3P+1hx2RNjOsu9NybCq2J1TEsw92ktSYaX X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001)(10115024); SRVR:BY2FFO11HUB041; BCL:0; PCL:0; RULEID:; SRVR:BY2FFO11HUB041; X-Forefront-PRVS: 0719EC6A9A X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCWTJGRk8xMUhVQjA0MTsyMzpTMnc0RGQyaG5xejBhT3hUbG42SngwSm9J?= =?utf-8?B?UU9RNG5kdTNvcDY1ZFJCbnhxVEZMS0haRFBDUkN4dlRPdjdDTE5VR2crYmpv?= =?utf-8?B?bS9kb25senRwMUtBcFBHb1dnNnQ5UDhiTDByTHF5ZHB0NkJOVmlUQUJkVUF4?= =?utf-8?B?UERtdWllNGRpMWdYN0tncDlrZnFLZXlRSUVDY1BtWUovSXZKL1FvZkFKWjdo?= =?utf-8?B?MUo4ZnVCQ05tejEzWXo4dzhsZk9nZEpiUkp3UHE2UVU2Z3pzSExRK1ZDOWZK?= =?utf-8?B?MmRQdHh2ejVHQUsxbVVPVmxDY2taU3QwWHF3VGtVWmpZRjlkU1BZZXFPSkdm?= =?utf-8?B?dHZPa0pHY0krOCsrUWI1Sk8rSHByVzlRU2N4a0dJRWRYVU8xeVFLd0R0dkYy?= =?utf-8?B?WlBOcGJlNzE4K3lqWlNkUVA2S2U4aFRtaXpSM3h4Ly9OdjdPbVp4WWNtTktY?= =?utf-8?B?alhJVmdNVzNMbXpwTHczR0lDUndUYkQ0YVBBeWM4Sm1uN0kyVHhLakRWR2o1?= =?utf-8?B?TnQxYlFUelRYaUJXYzdJckljcnk3TjlFMWxDMmNzREppVCtIcVROdWdqT1VP?= =?utf-8?B?eUVPOXBmclBGRG8rMVpGbWZpd3V0dldPdDhzZTQ0VitPVlk1bkVKcVJXZUNL?= =?utf-8?B?cTNCb1I1LzdBYlhtN2pNMUVXYWZJWk5iTDVQNUJyL3Rrb0VTUUtyR1dVVkk1?= =?utf-8?B?MXl6dVhaMGxPbGd2YTNaaTdVYXZsM2hOZUxjRC9OeDF6Ym16cEZwVlJCOGJU?= =?utf-8?B?Z295QVMvQlVlRDNNMnVhbFAreGNaLzJpdWlrc05rWWlZMmJya0I1MEU2WXFV?= =?utf-8?B?YytHY3ZyL1p5R1BjYVk5TVN0U2hMRFJzUVQ2T25SdmtTWXlnWGlSVUw4UDNH?= =?utf-8?B?N0llVldHYnZkWWpNUnlDUG9VM3YyTWhnK2Q3MXo5SHlKcFNKVm9DbUl3VHk4?= =?utf-8?B?R1hRTHM2cURtWnVzTkZSQ1VQam96MEVGa3ViRFNMbm1jRDQ0eUdwZGJJcjF4?= =?utf-8?B?U3FkQlg3Q2NROEo2YU90YWlpZXl0aTZGdzlBb29LREdQUjkrc2QyTlVnVDlr?= =?utf-8?B?RjIvWlhydmFFTEJDZjVRZG5HbUVKOUtpd0lZZlN1a2dqb09iM0djYWkzRUE2?= =?utf-8?B?dmJFK2RicWpOUGVsSk4xUk8vSmFGZFBCVnZzcEt5dzUxa05yZ1lPbFV6ZGtX?= =?utf-8?B?c3ZhR1JQWDEvQW1raHVaL0RFeVhpMEtBYTMvWFRpVHk3eXJLZDNOOVJpTjlF?= =?utf-8?B?VVB1NmxTc3hFamFXWjJ2NzFXOWJEaTFXVHhkdm1XU1hQRmQ5bThIVmlidjlh?= =?utf-8?B?RU5CbnNZTSswTGluTGlueW5Lek81ZXVVSFN1SENHU0J6OEVjVVJDZDU2R1Zx?= =?utf-8?B?cTF4SlIxOHBaaFlubEl4eml4WkFsbGZFL2d6NmxsLzdieVhaNjhrM1Z3cis3?= =?utf-8?B?RW1ETXpRS0UvbXdsK2REMXgwMm9xMFNMYU5BOWRQbkFFc1VvTGh1NGxnbTRo?= =?utf-8?B?TFdoZEJoejR0Vkw1QnU4dThQeU5NNDY3MHc1d0xXdlRxMGlYdlVxRzRNb2lV?= =?utf-8?B?K0xQcC9TcVhjZUlTellGQ1pvMXpHQzVsMXZ5bVJ5OTBLOHZQc0tMRVpJOG5E?= =?utf-8?B?UWJvTFJPamtxdFQwaWRsdDFIakw3Sk9jRkhCak5vY0syOEZPOXVrUTVJZllw?= =?utf-8?B?cWJJWjFzNnF4UVdNVjlOWVJPQldPNUliemJSQkk2OHI1TlFlbzB3Nlo4L2lR?= =?utf-8?B?VDhmaWR5SFJCOSs2YTdhSlBvRmxEUXZUYmlBdXNnNEJxSG01NWdnUEU4Y3hD?= =?utf-8?B?dldodEJycEU2RzQxQUdiL1JpQnVIeDA4b1RKQVEvZXM1LzhzVURhY1lOZ0VT?= =?utf-8?B?S21KZkR2UjJYRUpFWlA1L1p2NlF6VnIxeXFCRXFDbGFVYUs0RUJRdEJhc0RD?= =?utf-8?B?MTM4UUhCYWlvcGEraWl1cy9JcWxFQ2JrZUdkNFhqZnVmMDdZenRkQnFUYXVl?= =?utf-8?B?WDdUYUFVQXFva256ZVQ3TzNiSm8rRmtWSkU4bFE9PQ==?= X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11HUB041; 5:NJOuOximGFW9CuoikHilekCKMMjCnlz9tUCbTrdm5w3nhEZuvW8ts0mPtHsfbNl5c1ZH2kZXYease0WeK0SqHV6DwghqP58rftwoklADf+YBoXfhjKnSusJ+MZ68ryZfPBiZWuZ9VEbLuA8DhfCYXw==; 24:qzfpfAwfJdbfQXU7XTHU9qtuY/VKXQzHz8jziIg4wnI4DjvwKcGxr2HQTHfbjh4YznoNqWGCswa5RxfvNNQwr71+fiA1vP1tBB81+8G6/WE= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Oct 2015 20:57:12.1136 (UTC) X-MS-Exchange-CrossTenant-Id: b4d138ca-1815-4a9b-a3a7-130a33b1e692 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=b4d138ca-1815-4a9b-a3a7-130a33b1e692; Ip=[164.107.81.208]; Helo=[cio-krc-pf01.osuad.osu.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2FFO11HUB041 X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11HUB040; 2:8xAbCd4XO6tEzrJUX6h3Iz4cRmFjFP4dtaD6bFnz/qkpxe6aCWVU7aZjw9xE644a28lhwsOs6rBI8fl9MauMEBfnf47qlrhDnJv1wxzElaaD4WX1d4gxtBE2UMkZ21mq5mGuhYUeRd8qEkYDuHUxl2/8etfNekFqDfkoHA4mdN4=; 23:cd3rpizgxsMYw0b0l99/uBr3PHarX7gIgbN5tkEuAnwqdXzVeHBHrwUw9DoTebnjqoMY0vs1ojrM+QtSRroU3seWho2PzQJDypRiLtGeRasY9lYl3UaXpVIFw8jc1ZWc9u8EGMkWWJeNfVGF0zXWMleE6nHbiUgRauorOVSX9cDBuLArTrkQGLv2RT0c3Bc4 X-OriginatorOrg: osu.edu Archived-At: Subject: Re: [abfab] final piece of the puzzle - OASIS SSTC review X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Oct 2015 20:57:18 -0000 T24gMTAvNC8xNSwgNDoxMiBQTSwgImFiZmFiIG9uIGJlaGFsZiBvZiBMZWlmIEpvaGFuc3NvbiIg PGFiZmFiLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGxlaWZqQHN1bmV0LnNlPiB3cm90 ZToNCg0KDQoNCj4NCj5JIGhhZCBhIGNoYXQgd2l0aCBTY290dCBDYW50b3IgdG9kYXkgYW5kIGhl IGV4cGxhaW5lZCB0aGF0IHRoZQ0KPk9BU0lTIFNTVEMgaXMgbm90IHJlYWxseSBhYmxlIHRvIHBy b3ZpZGUgcmV2aWV3IGJleW9uZCB0aGUgcmVpdmV3DQo+dGhhdCBTY290dCBhbHJlYWR5IGhhcyBk b25lIG9uIGFhYS1zYW1sIGFuZCB3ZSBzaG91bGQganVzdCB0YWtlDQo+dGhhdCByZXZpZXcgd2Ug Z290IGFuZCBkZWNsYXJlIHZpY3RvcnkuDQoNCkkgYWxzbyBvZmZlcmVkIHRvIGRvIGEgbW9yZSB0 aG9yb3VnaCByZXZpZXcgdGhpcyB3ZWVrLCBwYXJ0aWN1bGFybHkgaWYgSSBjYW4gZ2V0IGFueSBy ZXZpZXdlcnMgZm9yIHRoZSBraXR0ZW4gc2FtbC1lYyBkcmFmdCwgaGludCwgaGludC4NCg0KLS0g U2NvdHQNCg0K From nobody Sun Oct 4 14:01:48 2015 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98F5E1A6F45 for ; Sun, 4 Oct 2015 14:01:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.661 X-Spam-Level: X-Spam-Status: No, score=-1.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id umrFATfhqw9j for ; Sun, 4 Oct 2015 14:01:45 -0700 (PDT) Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [IPv6:2001:6b0:8:2::201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1CCC1A6F40 for ; Sun, 4 Oct 2015 14:01:44 -0700 (PDT) Received: from smtp1.sunet.se (smtp1.sunet.se [192.36.171.214]) by e-mailfilter01.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id t94L1fKM017606 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 4 Oct 2015 23:01:41 +0200 Received: from kerio.sunet.se (kerio.sunet.se [192.36.171.210]) by smtp1.sunet.se (8.14.9/8.14.7) with ESMTP id t94L1c0C013778 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 4 Oct 2015 23:01:40 +0200 (CEST) VBR-Info: md=sunet.se; mc=all; mv=swamid.se DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sunet.se; s=default; t=1443992501; bh=b0zVxGJht5Ak4RHDCt30p/rK2+N8r0H5G9jxsW4yH3s=; h=Subject:To:References:From:Date:In-Reply-To; b=WbSk8t3aD25MiTmvs5jibm/jpTSV55v2fz4ARcPTstzLkWCtSjvR7UFwfKtABj1OV 53+zsto4sEP/prWuGCx69F9thRX2BiUVdJLDtTlL29oUwpmLpwMUVIqnyddweYy2+9 Fz1/mm2y6HkeGYnC5T1vkop/YU21oJGwXxF/PcvU= X-Footer: c3VuZXQuc2U= Received: from [10.12.136.13] ([192.171.20.23]) (authenticated user leifj@sunet.se) by kerio.sunet.se (Kerio Connect 8.3.4 patch 1) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256 bits)); Sun, 4 Oct 2015 23:01:35 +0200 To: "Cantor, Scott" , "abfab@ietf.org" , Alejandro Perez Mendez References: <56118835.4090706@sunet.se> <7FC71EA1-8DE4-4DD0-AE57-DB0B249450F0@osu.edu> From: Leif Johansson Message-ID: <561193AD.9000000@sunet.se> Date: Sun, 4 Oct 2015 23:01:33 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <7FC71EA1-8DE4-4DD0-AE57-DB0B249450F0@osu.edu> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, outbound-sunet-se:default, sunet-se:default, base:default, @@RPTN) X-CanIt-Geo: ip=192.36.171.210; country=SE; latitude=59.3294; longitude=18.0686; http://maps.google.com/maps?q=59.3294,18.0686&z=6 X-CanItPRO-Stream: outbound-sunet-se:outbound (inherits from outbound-sunet-se:default, sunet-se:default, base:default) X-Canit-Stats-ID: 09Pp91FUW - 9b471bf478d7 - 20151004 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw Received-SPF: neutral (e-mailfilter01.sunet.se: 192.36.171.210 is neither permitted nor denied by domain leifj@sunet.se) receiver=e-mailfilter01.sunet.se; client-ip=192.36.171.210; envelope-from=; helo=smtp1.sunet.se; identity=mailfrom X-Scanned-By: CanIt (www . roaringpenguin . com) on 192.36.171.201 Archived-At: Subject: Re: [abfab] final piece of the puzzle - OASIS SSTC review X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Oct 2015 21:01:46 -0000 On 2015-10-04 22:57, Cantor, Scott wrote: > On 10/4/15, 4:12 PM, "abfab on behalf of Leif Johansson" wrote: > > > >> >> I had a chat with Scott Cantor today and he explained that the >> OASIS SSTC is not really able to provide review beyond the reivew >> that Scott already has done on aaa-saml and we should just take >> that review we got and declare victory. > > I also offered to do a more thorough review this week, particularly if I can get any reviewers for the kitten saml-ec draft, hint, hint. > > -- Scott > Alejandro - if you could do a review of Scotts saml-ec draft in kitten I belive that would be very helpful! Cheers Leif From nobody Sun Oct 4 23:40:34 2015 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBAB01B497D for ; Sun, 4 Oct 2015 23:40:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.911 X-Spam-Level: X-Spam-Status: No, score=-3.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kyQK1QuXv42F for ; Sun, 4 Oct 2015 23:40:32 -0700 (PDT) Received: from xenon24.um.es (xenon24.um.es [155.54.212.164]) by ietfa.amsl.com (Postfix) with ESMTP id C191E1B497C for ; Sun, 4 Oct 2015 23:40:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon24.um.es (Postfix) with ESMTP id A082C104F; Mon, 5 Oct 2015 08:40:29 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon24.um.es Received: from xenon24.um.es ([127.0.0.1]) by localhost (xenon24.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id tqSS-2+AicoI; Mon, 5 Oct 2015 08:40:29 +0200 (CEST) Received: from [155.54.204.2] (alex.inf.um.es [155.54.204.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: alex) by xenon24.um.es (Postfix) with ESMTPSA id CF58A130; Mon, 5 Oct 2015 08:40:26 +0200 (CEST) To: Leif Johansson , "Cantor, Scott" , "abfab@ietf.org" References: <56118835.4090706@sunet.se> <7FC71EA1-8DE4-4DD0-AE57-DB0B249450F0@osu.edu> <561193AD.9000000@sunet.se> From: =?UTF-8?Q?Alejandro_P=c3=a9rez_M=c3=a9ndez?= Message-ID: <56121B5A.70108@um.es> Date: Mon, 5 Oct 2015 08:40:26 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <561193AD.9000000@sunet.se> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [abfab] final piece of the puzzle - OASIS SSTC review X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2015 06:40:34 -0000 El 04/10/15 a las 23:01, Leif Johansson escribió: > On 2015-10-04 22:57, Cantor, Scott wrote: >> On 10/4/15, 4:12 PM, "abfab on behalf of Leif Johansson" wrote: >> >> >> >>> I had a chat with Scott Cantor today and he explained that the >>> OASIS SSTC is not really able to provide review beyond the reivew >>> that Scott already has done on aaa-saml and we should just take >>> that review we got and declare victory. >> I also offered to do a more thorough review this week, particularly if I can get any reviewers for the kitten saml-ec draft, hint, hint. >> >> -- Scott >> > Alejandro - if you could do a review of Scotts saml-ec draft in kitten I > belive that would be very helpful! Sure, I'll be glad to do it. Regards, Alejandro > > Cheers Leif > From nobody Mon Oct 5 00:33:05 2015 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09FD11B4B74 for ; Mon, 5 Oct 2015 00:33:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P27BpfgWUcId for ; Mon, 5 Oct 2015 00:33:03 -0700 (PDT) Received: from xenon23.um.es (xenon23.um.es [155.54.212.163]) by ietfa.amsl.com (Postfix) with ESMTP id 65A1A1B4B66 for ; Mon, 5 Oct 2015 00:33:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon23.um.es (Postfix) with ESMTP id 90C8D2ADF for ; Mon, 5 Oct 2015 09:32:59 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon23.um.es Received: from xenon23.um.es ([127.0.0.1]) by localhost (xenon23.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id gBRCfptyOW6B for ; Mon, 5 Oct 2015 09:32:59 +0200 (CEST) Received: from [155.54.204.2] (alex.inf.um.es [155.54.204.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: alex) by xenon23.um.es (Postfix) with ESMTPSA id 7CB052914 for ; Mon, 5 Oct 2015 09:32:59 +0200 (CEST) References: <20151005072718.21102.94680.idtracker@ietfa.amsl.com> To: "abfab@ietf.org" From: =?UTF-8?Q?Alejandro_P=c3=a9rez_M=c3=a9ndez?= X-Forwarded-Message-Id: <20151005072718.21102.94680.idtracker@ietfa.amsl.com> Message-ID: <561227AA.8090602@um.es> Date: Mon, 5 Oct 2015 09:32:58 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151005072718.21102.94680.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------000303000906030204090809" Archived-At: Subject: [abfab] Fwd: New Version Notification for draft-perez-abfab-gss-remote-attr-00.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2015 07:33:05 -0000 This is a multi-part message in MIME format. --------------000303000906030204090809 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Dear all, we have submitted a new draft called " Retrieving remote attributes using GSS-API naming extensions" that aims to describe how current GSS-API extensions can be used to allow mechanisms to retrieve remote attributes without requiring of any change neither on the existing calls nor on the way applications use the API. Any comment or feedback is welcome. Regards, Alejandro -------- Mensaje reenviado -------- Asunto: New Version Notification for draft-perez-abfab-gss-remote-attr-00.txt Fecha: Mon, 05 Oct 2015 00:27:18 -0700 De: internet-drafts@ietf.org Para: Alejandro Perez-Mendez , Alejandro Perez-Mendez , Rafa Marin-Lopez , Rafael Lopez , Gabriel Lopez-Millan , Gabriel Lopez-Millan A new version of I-D, draft-perez-abfab-gss-remote-attr-00.txt has been successfully submitted by Alejandro Perez-Mendez and posted to the IETF repository. Name: draft-perez-abfab-gss-remote-attr Revision: 00 Title: Retrieving remote attributes using GSS-API naming extensions Document date: 2015-10-05 Group: Individual Submission Pages: 9 URL: https://www.ietf.org/internet-drafts/draft-perez-abfab-gss-remote-attr-00.txt Status: https://datatracker.ietf.org/doc/draft-perez-abfab-gss-remote-attr/ Htmlized: https://tools.ietf.org/html/draft-perez-abfab-gss-remote-attr-00 Abstract: The GSS-API Naming Extensions define new APIs that extend the GSS-API naming model to support name attribute transfer between GSS-API peers. Historically, this set of functions has been used to obtain the authorization information contained in some sort of authorization token provided to the GSS acceptor during the context establishment process, such as a Kerberos ticket, a SAML assertion, or an X.509 attribute certificate. However, some scenarios require to allow the GSS acceptor to request additional attributes after context establishment. If these attributes are not locally stored by the GSS mechanism they have to be retrieved from an external source (e.g. SQL database, LDAP directory, external IdP, etc.). This document describes how current GSS-API extensions are able to encompass such functionality without requiring of any change, neither on the existing calls nor on the way applications use the API. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --------------000303000906030204090809 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Dear all,

we have submitted a new draft called " Retrieving remote attributes using GSS-API naming extensions" that aims to describe how current GSS-API extensions can be used to allow mechanisms to retrieve remote attributes without requiring of any change neither on the existing calls nor on the way applications use the API.

Any comment or feedback is welcome.

Regards,
Alejandro


-------- Mensaje reenviado --------
Asunto: New Version Notification for draft-perez-abfab-gss-remote-attr-00.txt
Fecha: Mon, 05 Oct 2015 00:27:18 -0700
De: internet-drafts@ietf.org
Para: Alejandro Perez-Mendez <alex@um.es>, Alejandro Perez-Mendez <alex@um.es>, Rafa Marin-Lopez <rafa@um.es>, Rafael Lopez <rafa@um.es>, Gabriel Lopez-Millan <gabilm@um.es>, Gabriel Lopez-Millan <gabilm@um.es> 


A new version of I-D, draft-perez-abfab-gss-remote-attr-00.txt
has been successfully submitted by Alejandro Perez-Mendez and posted to the
IETF repository.

Name:		draft-perez-abfab-gss-remote-attr
Revision:	00
Title:		Retrieving remote attributes using GSS-API naming extensions
Document date:	2015-10-05
Group:		Individual Submission
Pages:		9
URL:            https://www.ietf.org/internet-drafts/draft-perez-abfab-gss-remote-attr-00.txt
Status:         https://datatracker.ietf.org/doc/draft-perez-abfab-gss-remote-attr/
Htmlized:       https://tools.ietf.org/html/draft-perez-abfab-gss-remote-attr-00


Abstract:
   The GSS-API Naming Extensions define new APIs that extend the GSS-API
   naming model to support name attribute transfer between GSS-API
   peers.  Historically, this set of functions has been used to obtain
   the authorization information contained in some sort of authorization
   token provided to the GSS acceptor during the context establishment
   process, such as a Kerberos ticket, a SAML assertion, or an X.509
   attribute certificate.  However, some scenarios require to allow the
   GSS acceptor to request additional attributes after context
   establishment.  If these attributes are not locally stored by the GSS
   mechanism they have to be retrieved from an external source (e.g.
   SQL database, LDAP directory, external IdP, etc.).  This document
   describes how current GSS-API extensions are able to encompass such
   functionality without requiring of any change, neither on the
   existing calls nor on the way applications use the API.

                                                                                  


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


--------------000303000906030204090809-- From nobody Mon Oct 5 02:11:25 2015 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87BB81B4E9C for ; Mon, 5 Oct 2015 02:11:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bOeIJqfrNpB1 for ; Mon, 5 Oct 2015 02:11:21 -0700 (PDT) Received: from treacle.ucs.ed.ac.uk (treacle.ucs.ed.ac.uk [129.215.16.102]) by ietfa.amsl.com (Postfix) with ESMTP id CB7151B4E92 for ; Mon, 5 Oct 2015 02:11:20 -0700 (PDT) Received: from hbdkb2.is.ed.ac.uk (hbdkb2.is.ed.ac.uk [129.215.234.33]) by treacle.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id t959BKwa017315 for ; Mon, 5 Oct 2015 10:11:20 +0100 (BST) Received: from emea01-am1-obe.outbound.protection.outlook.com (213.199.154.11) by exseed.ed.ac.uk (129.215.234.33) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 5 Oct 2015 10:11:00 +0100 Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=alex.stuart@ed.ac.uk; Received: from dlib-glasgow.ucs.ed.ac.uk (129.215.169.215) by AM3PR05MB1348.eurprd05.prod.outlook.com (10.163.7.22) with Microsoft SMTP Server (TLS) id 15.1.286.20; Mon, 5 Oct 2015 09:10:48 +0000 To: References: <20151005072718.21102.94680.idtracker@ietfa.amsl.com> <561227AA.8090602@um.es> From: Alex Stuart X-Enigmail-Draft-Status: N1110 Message-ID: <56123E92.5020208@ed.ac.uk> Date: Mon, 5 Oct 2015 10:10:42 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <561227AA.8090602@um.es> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Originating-IP: [129.215.169.215] X-ClientProxiedBy: AM3PR02CA0021.eurprd02.prod.outlook.com (10.242.240.21) To AM3PR05MB1348.eurprd05.prod.outlook.com (25.163.7.22) X-Microsoft-Exchange-Diagnostics: 1; AM3PR05MB1348; 2:jP5uPeWknYIt7k7fe4riMwr4QPg/gYV9VIqhc2FnU24SDU4fs9Gtr0ZvPXjhTPQ2/E5nAzEnMqEvHDh3vRz7vV7r+edmLW3b5QL9SprTDeGVHBrxH53/A54QmU5JpP5O+0BDGGc6eWBvoQ6ACTT/nwC8xBfxmXWI0bV6oZvv+wQ=; 3:HH3Dm6MbwvP80xjR5wBJMFf1adSX03Iw5icAzeyOiLks1bY6nhlhjCP/5YZBAxtTe0UNMiWrWROYNm8NVe15h+4uJbhhr3R48BZFSaEflCQkoWqsgOVhYo5BlBk/UlvDiMSxsEjgS+N2JoluSxISrg==; 25:3bcTq4Iit9C4l/JWJswWgS42Z9w4SWOBcvPbyaL/H2BVViJ+i/NyVMYar+q61AhjEp8pGXCJD4QkYW7PzjlaWMGFL7pb8xB7PAdXGQGbCQJHIBrDVld1S/HOsG29uCiWJC8SOngEs161V3dpD+fidFSM504n0aBZtRVHC5RwjDyIWpwq3whih0KRwOvNjm0q6V0lQxQ9DzpD6BXFBadOF9sAOyegNKbT/8/iproVeWNAV7QpFzAVeRfAnzzsKocG6hTuvY85ngDE53isBkjAAw== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM3PR05MB1348; X-Microsoft-Exchange-Diagnostics: 1; AM3PR05MB1348; 20:TcqbuCZ5jE9dJzremD4OaReFdfdxLgJznFKWGs5w7+OzzbciK1tDJ8TMtjy2x/vePZ31sSyBsYpZL7KD7/def5yx/AkE4tgHV3aYBWSXZphiQ1JvMxTfMQ4+qoQpCHjIs/QBPdNTrZe7+uOCYcDgQXGL+dcHCxJLDU4v1ZIPMAxrNN3EixRCDjs7GI8YmcejclpDCJKsBx4gH9cbVZ2M4vJi0T82jANO4myOCm5Ow4IgoCW4T8HIPSG2T3YguHVC68kZ8wk91GzDbx63N3C014fnZ8tO61xc0LOodsvnxO+9PYg/uvvW5IeD+Yc4Cgk8zzm1ZFn0D2VixlrfEi4OdgfwkjWy6nwXsfoYqn7ea8g=; 4:YF5W/f1N/XJxV242Nis1KqlkU+d6RSumX4ahHfiGDiLcQ9T9lH463zjvIyq7o9fcQCrG93TKOyc6c7t7Otohcirn2Sw2vxxJR6tIc8VjGIMcHZUnziaVW84atJM8TzYVNLfpT2GqxLZcehSsb+hYeCKmMg/FScjCs9wYfDq7opYqB9Y4MEv5RMsJBRp3sc9Z2YkmhGHv/mLgTQBJkgRZwCW03B7RmkquqecybaF3A5ydVUPYw0CQ3lhaaq+SkEBr/D/8BAPuNJznx1KWAEN913PKou4A/cQHQLo/ioOvwxm2KPqNJtBL2AyBmgvjfJ8Pt5QkMAIlABLOo/aTU0i6JxQhUDwF3hPUh1qm33G5/1E= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001); SRVR:AM3PR05MB1348; BCL:0; PCL:0; RULEID:; SRVR:AM3PR05MB1348; X-Forefront-PRVS: 07200C0526 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6009001)(189002)(479174004)(24454002)(2473001)(377424004)(199003)(101416001)(77156002)(5008740100001)(62966003)(5001860100001)(5001830100001)(92566002)(4001350100001)(97736004)(2950100001)(64126003)(36756003)(4001540100001)(5004730100002)(5007970100001)(50466002)(450100001)(74482002)(122386002)(54356999)(87266999)(230783001)(2351001)(59896002)(40100003)(19580405001)(23746002)(19580395003)(80316001)(106356001)(15975445007)(105586002)(68736005)(77096005)(46102003)(65816999)(33656002)(110136002)(107886002)(47776003)(189998001)(83506001)(99136001)(65956001)(64706001)(66066001)(65806001)(86362001)(76176999)(50986999)(42186005)(87976001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR05MB1348; H:dlib-glasgow.ucs.ed.ac.uk; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (protection.outlook.com: ed.ac.uk does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; AM3PR05MB1348; 23:auAymb1oGd9im6EquaBIQSrMQChMPgDENAWkc?= =?Windows-1252?Q?dGNlJDQtLSJstfhvjV5W9dHhPa4UG8n/2GUqNaYvyhaOiO/jlQ0+sVNo?= =?Windows-1252?Q?ekyi14yfcl+CSaWrhUobJN4IKcYaP5dCX8WtSYkaiAEfTmq38+r16HSn?= =?Windows-1252?Q?qVgyLHr84c5AGKdpxocBMUPK6iJQs5vixvX44y+6tla9H8KIIQAUTjnm?= =?Windows-1252?Q?uIPzRg1zhB1VzZKM+JckcAQL692q8fTWiFiryUA3dXkNoI+9yQhqVPg9?= =?Windows-1252?Q?oDhIeiXRcXj1qyqHX1s/A//q1olO26TPK10rPU0LxgwS27pmuQB6gXgc?= =?Windows-1252?Q?IJSzcI3aX4oP7tP/yG4m8DmgD8obhkmK6w1zY5SFGZBJfam7X8gc0qV5?= =?Windows-1252?Q?VftKB2m0ubhLb63TwaZReyDqfIBgEfIZI0jZY7ty+DmZXjcmc8mY1cVv?= =?Windows-1252?Q?ma9nK+Sk12CbjeT1NtU7Mw4YbV/kc0Obf32sywSqJ1pm0A3PdF8L068d?= =?Windows-1252?Q?GNFpJXpo7T1k7LOxgmiJemmhSdJqK8s4XvS9m2YwKzdOm6uX6napzmBA?= =?Windows-1252?Q?rc0V9owJz/tSY0nhtzfY5MW6OPczhtPQx2RS4VpQxHjbv/IvOqcprQZy?= =?Windows-1252?Q?OI1nMuQmiJYxMXXNKtXHlGs/MDrvbhHNhNMMWu593ii2H+QSInibGpc1?= =?Windows-1252?Q?urTn02dIsfZm0fjESHemCnqv8aMLbporVdSPc7HIWNRmZYLHL6vqXmJ/?= =?Windows-1252?Q?wUb09kr+dQnIs6E280HCMt/di/kOBW4iekm16agoyrqZ5EitOXS8MUbO?= =?Windows-1252?Q?dPybkElP8Il5bU/otf84QRno6Wivt7vWkBICE0M19ZNx33hUbhui4cle?= =?Windows-1252?Q?XZvJgyg9BuChLatDdJDEH86XzGfKCb+w2sllWZVwi7+PLqcJG1tdBHZx?= =?Windows-1252?Q?w70bPhRUEHv8N3kjQHifAA4S4Xs2LPgGie0ck/hBL+Rt2L1WzdpAQxgl?= =?Windows-1252?Q?o1GjM5avQhQRTVSbzuPnbK+GZDoirIIrL4DrBdRQg3D9XaIpN+rtEqCJ?= =?Windows-1252?Q?odTCRZ7JKEkJQqZ6tGWEqgrZ6w2B0MrsIIt/A8H8YrnOQ64g0mvVYJLV?= =?Windows-1252?Q?35g1oYCbb8MQ0d1rm1YU34EIG/oqASE4eUot3xZ+bcYtjpKEvD49SGN7?= =?Windows-1252?Q?T7/QJF7/COfmYweOp4A7SClrGzAfXQ1/BiLa7goUGn0VIu4hjDWMtXU0?= =?Windows-1252?Q?hePzjc3NN5tu0xmlxJdlKKxzO1OVZhq0aEVhC3EaTH9cNXYAjk+rZ+rM?= =?Windows-1252?Q?ExjfnmLcLI+XceInTuHOTaqjK86E2x/ywADpdLlc8XXm/wKK5BU0ZZp4?= =?Windows-1252?Q?OYigFSHyb/TqZGo9QsocNwIwadf+jJNDhxLHQQLufnXPLPGXZP/UxHEA?= =?Windows-1252?Q?K4cRZ9ud3qn/jVrVXNrOH4CCIr3UG12T2IbtSvq1yLEftO4vGsCeYnei?= =?Windows-1252?Q?zVif6rh9Hz2M8lBOvtTtjlyqjVqwQr+iWD4amijOW88fHCEMH+cUbJki?= =?Windows-1252?Q?bxQxOw/Knx5eOnRm/sWMyqIsaKzxWZXxTWdJQ3lxjsx+j/NeCh1H9XVP?= =?Windows-1252?Q?A/fxt5eeuQyk4V+PiInrxfWRJRk3k2j9fMoqaj7Juzy?= X-Microsoft-Exchange-Diagnostics: 1; AM3PR05MB1348; 5:p6bKOwCvQXm6kDBA/kM8haURBG/wsW5rSRYSKE52Kl39kBmDz0qoltyfIKbNXwcuLuX2BbIhbDxhBbj1NUtI8YV+RjteFVrVfbVnGonIKLUsBRXczU969MKUvF+vWTpI+DYdKzOABRQUpAMC0nsTSg==; 24:F+ZNGC2WYXq+PwMHyT9gwPha6GWiTaX2en9FPgmjRcQbYACDg9B5/3uNezRHg57GP/cJjDBnADSXvRcJ9KH6knYwIshrkt2hllekOMsCPMc=; 20:7r4NdHTaXV9jEUGsykcaCUg3GQF1acuTc9nBeT8q2Gr5uBJ9KYYCSkS3N6rpaKKjR/JmeKzF4bqZO9WwqGXnGw== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Oct 2015 09:10:48.5186 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR05MB1348 X-OriginatorOrg: ed.ac.uk X-Edinburgh-Scanned: at treacle.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus Content-Disposition: inline X-Scanned-By: MIMEDefang 2.60 on 129.215.16.102 Archived-At: Subject: Re: [abfab] Fwd: New Version Notification for draft-perez-abfab-gss-remote-attr-00.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2015 09:11:23 -0000 Hi Alejandro I think some names of the SAML attributes have got swapped. In section 5.1, the last bullet point should be: * urn:ietf:params:gss:federated-saml-attribute urn:oasis:names:tc:SAML:2.0:attrname-format:uri urn:oid:1.3.6.1.4.1.5923.1.1.1.7 (SAML eduPersonEntitlement attribute) And in 5.6, the parenthetical SAML eduPersonAffiliation and SAML eduPersonEntitlement should be swapped. However, I'm not sure that an application would first receive an entitlement, then ask for an affiliation. Because affiliation has a small controlled vocabulary and entitlement can be as fine-grained as you like, I think the logic would be reversed. I can envisage that an application receives affiliation, which it finds too coarse to allow authorization, and then looks for entitlement to make the decision. Regards, Alex On 05/10/2015 08:32, Alejandro Pérez Méndez wrote: > Dear all, > > we have submitted a new draft called " Retrieving remote attributes > using GSS-API naming extensions" that aims to describe how current > GSS-API extensions can be used to allow mechanisms to retrieve remote > attributes without requiring of any change neither on the existing calls > nor on the way applications use the API. > > Any comment or feedback is welcome. > > Regards, > Alejandro > > > -------- Mensaje reenviado -------- > Asunto: New Version Notification for > draft-perez-abfab-gss-remote-attr-00.txt > Fecha: Mon, 05 Oct 2015 00:27:18 -0700 > De: internet-drafts@ietf.org > Para: Alejandro Perez-Mendez , Alejandro Perez-Mendez > , Rafa Marin-Lopez , Rafael Lopez , > Gabriel Lopez-Millan , Gabriel Lopez-Millan > > > > A new version of I-D, draft-perez-abfab-gss-remote-attr-00.txt > has been successfully submitted by Alejandro Perez-Mendez and posted to the > IETF repository. > > Name: draft-perez-abfab-gss-remote-attr > Revision: 00 > Title: Retrieving remote attributes using GSS-API naming extensions > Document date: 2015-10-05 > Group: Individual Submission > Pages: 9 > URL: https://www.ietf.org/internet-drafts/draft-perez-abfab-gss-remote-attr-00.txt > Status: https://datatracker.ietf.org/doc/draft-perez-abfab-gss-remote-attr/ > Htmlized: https://tools.ietf.org/html/draft-perez-abfab-gss-remote-attr-00 > > > Abstract: > The GSS-API Naming Extensions define new APIs that extend the GSS-API > naming model to support name attribute transfer between GSS-API > peers. Historically, this set of functions has been used to obtain > the authorization information contained in some sort of authorization > token provided to the GSS acceptor during the context establishment > process, such as a Kerberos ticket, a SAML assertion, or an X.509 > attribute certificate. However, some scenarios require to allow the > GSS acceptor to request additional attributes after context > establishment. If these attributes are not locally stored by the GSS > mechanism they have to be retrieved from an external source (e.g. > SQL database, LDAP directory, external IdP, etc.). This document > describes how current GSS-API extensions are able to encompass such > functionality without requiring of any change, neither on the > existing calls nor on the way applications use the API. > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > > > > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab > -- Alex Stuart Team Leader - Federated Access Management EDINA, University of Edinburgh The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. From nobody Mon Oct 5 02:30:42 2015 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5FCF1B4EBC for ; Mon, 5 Oct 2015 02:30:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.911 X-Spam-Level: X-Spam-Status: No, score=-3.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rEDMsrdIu1nH for ; Mon, 5 Oct 2015 02:30:38 -0700 (PDT) Received: from xenon21.um.es (xenon21.um.es [155.54.212.161]) by ietfa.amsl.com (Postfix) with ESMTP id 553D81B4EC0 for ; Mon, 5 Oct 2015 02:30:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon21.um.es (Postfix) with ESMTP id 6596F406B4 for ; Mon, 5 Oct 2015 11:30:37 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon21.um.es Received: from xenon21.um.es ([127.0.0.1]) by localhost (xenon21.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id MHgBs43VOOAC for ; Mon, 5 Oct 2015 11:30:37 +0200 (CEST) Received: from [155.54.204.2] (alex.inf.um.es [155.54.204.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: alex) by xenon21.um.es (Postfix) with ESMTPSA id 4E32B406B1 for ; Mon, 5 Oct 2015 11:30:35 +0200 (CEST) To: abfab@ietf.org References: <20151005072718.21102.94680.idtracker@ietfa.amsl.com> <561227AA.8090602@um.es> <56123E92.5020208@ed.ac.uk> From: =?UTF-8?Q?Alejandro_P=c3=a9rez_M=c3=a9ndez?= Message-ID: <5612433A.6050603@um.es> Date: Mon, 5 Oct 2015 11:30:34 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <56123E92.5020208@ed.ac.uk> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [abfab] Fwd: New Version Notification for draft-perez-abfab-gss-remote-attr-00.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2015 09:30:41 -0000 El 05/10/15 a las 11:10, Alex Stuart escribió: > Hi Alejandro > > I think some names of the SAML attributes have got swapped. In section > 5.1, the last bullet point should be: > > * urn:ietf:params:gss:federated-saml-attribute > urn:oasis:names:tc:SAML:2.0:attrname-format:uri > urn:oid:1.3.6.1.4.1.5923.1.1.1.7 (SAML eduPersonEntitlement attribute) > > And in 5.6, the parenthetical SAML eduPersonAffiliation and SAML > eduPersonEntitlement should be swapped. Hi Alex, yup, you are right. I will change it for the next version. > > However, I'm not sure that an application would first receive an > entitlement, then ask for an affiliation. Because affiliation has a > small controlled vocabulary and entitlement can be as fine-grained as > you like, I think the logic would be reversed. I can envisage that an > application receives affiliation, which it finds too coarse to allow > authorization, and then looks for entitlement to make the decision. It was just an example, so I didn't think so much how much sense it made :). But since your example seems more logical, I will borrow it and use it for the next version. Thanks! Regards, Alejandro > > Regards, > Alex > > On 05/10/2015 08:32, Alejandro Pérez Méndez wrote: >> Dear all, >> >> we have submitted a new draft called " Retrieving remote attributes >> using GSS-API naming extensions" that aims to describe how current >> GSS-API extensions can be used to allow mechanisms to retrieve remote >> attributes without requiring of any change neither on the existing calls >> nor on the way applications use the API. >> >> Any comment or feedback is welcome. >> >> Regards, >> Alejandro >> >> >> -------- Mensaje reenviado -------- >> Asunto: New Version Notification for >> draft-perez-abfab-gss-remote-attr-00.txt >> Fecha: Mon, 05 Oct 2015 00:27:18 -0700 >> De: internet-drafts@ietf.org >> Para: Alejandro Perez-Mendez , Alejandro Perez-Mendez >> , Rafa Marin-Lopez , Rafael Lopez , >> Gabriel Lopez-Millan , Gabriel Lopez-Millan >> >> >> >> A new version of I-D, draft-perez-abfab-gss-remote-attr-00.txt >> has been successfully submitted by Alejandro Perez-Mendez and posted to the >> IETF repository. >> >> Name: draft-perez-abfab-gss-remote-attr >> Revision: 00 >> Title: Retrieving remote attributes using GSS-API naming extensions >> Document date: 2015-10-05 >> Group: Individual Submission >> Pages: 9 >> URL: https://www.ietf.org/internet-drafts/draft-perez-abfab-gss-remote-attr-00.txt >> Status: https://datatracker.ietf.org/doc/draft-perez-abfab-gss-remote-attr/ >> Htmlized: https://tools.ietf.org/html/draft-perez-abfab-gss-remote-attr-00 >> >> >> Abstract: >> The GSS-API Naming Extensions define new APIs that extend the GSS-API >> naming model to support name attribute transfer between GSS-API >> peers. Historically, this set of functions has been used to obtain >> the authorization information contained in some sort of authorization >> token provided to the GSS acceptor during the context establishment >> process, such as a Kerberos ticket, a SAML assertion, or an X.509 >> attribute certificate. However, some scenarios require to allow the >> GSS acceptor to request additional attributes after context >> establishment. If these attributes are not locally stored by the GSS >> mechanism they have to be retrieved from an external source (e.g. >> SQL database, LDAP directory, external IdP, etc.). This document >> describes how current GSS-API extensions are able to encompass such >> functionality without requiring of any change, neither on the >> existing calls nor on the way applications use the API. >> >> >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat >> >> >> >> >> >> _______________________________________________ >> abfab mailing list >> abfab@ietf.org >> https://www.ietf.org/mailman/listinfo/abfab >> From nobody Mon Oct 5 08:47:50 2015 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FE451B31C0 for ; Mon, 5 Oct 2015 08:47:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y7d3G6mAM62X for ; Mon, 5 Oct 2015 08:47:47 -0700 (PDT) Received: from mail-qg0-f53.google.com (mail-qg0-f53.google.com [209.85.192.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FA1E1B31B8 for ; Mon, 5 Oct 2015 08:47:47 -0700 (PDT) Received: by qgt47 with SMTP id 47so153085765qgt.2 for ; Mon, 05 Oct 2015 08:47:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-type:content-transfer-encoding; bh=BucVi+4Swyl5ZCJkNmkjSdLniObIVaHkjv5jcGnfwiY=; b=RBCR0QGwKtiU++EL0DZf9GSNIyAu1NaePYVH9ixPjU4lPCp30ew20kIt6J8CuHbqHH jHl5ur1ix/fX7rxrdcJqwNPpslSGtaQz3LWNn+TMIGsKmBF2AKS8t3+w9xnbvxmcBQjX nT5U56WtDHkmgDPh0Vn5Ixw5iCYHCuUkNukjX7hbItuCXX46+7zlyEbyGu5KfE/avwZK 7Z5oUuXYCLgKlp8EnpUz5A/7/WEM4u2g4A28kJP58wQlSstRkl1FX6PP9L7bHUfgP3WR bDeeBbLhcT3NIafjRTNFl/7H5MxiDoi3No/csV+mJtpj9u6KLYwfLG7npcUU2qLly82+ Q8Cw== X-Gm-Message-State: ALoCoQk5yL3ttjKzxkOp+8hoslCv1ew7V6qMIoD6Z2PNVPQ9zwt+LHw8cbnuHi6T1W0ScEo7LBdS X-Received: by 10.140.234.212 with SMTP id f203mr42397998qhc.10.1444060066483; Mon, 05 Oct 2015 08:47:46 -0700 (PDT) Received: from [10.12.12.14] ([192.171.20.23]) by smtp.googlemail.com with ESMTPSA id t77sm11602776qgt.24.2015.10.05.08.47.45 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 05 Oct 2015 08:47:45 -0700 (PDT) To: "abfab@ietf.org" From: Leif Johansson Message-ID: <56129BA1.8090806@mnt.se> Date: Mon, 5 Oct 2015 17:47:45 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [abfab] WGLC on draft-ietf-abfab-aaa-saml-11 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2015 15:47:48 -0000 Folks, As Sam pointed out we haven't actually done a WGLC on aaa-saml so here goes: This starts a 2 week WGLC on draft-ietf-abfab-aaa-saml-11. Please respond with your final comments before 19:th of October 2015. Best R Leif & Klaas From nobody Thu Oct 15 20:12:26 2015 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21EA31B2DB4 for ; Thu, 15 Oct 2015 20:12:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NOMW0M-_7Q_W for ; Thu, 15 Oct 2015 20:12:22 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0142.outbound.protection.outlook.com [207.46.100.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46FF21B2DB2 for ; Thu, 15 Oct 2015 20:12:22 -0700 (PDT) Received: from BN1AFFO11FD051.protection.gbl (10.58.52.30) by BN1AFFO11HUB030.protection.gbl (10.58.52.140) with Microsoft SMTP Server (TLS) id 15.1.293.9; Fri, 16 Oct 2015 03:12:21 +0000 Authentication-Results: spf=pass (sender IP is 164.107.81.210) smtp.mailfrom=osu.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=osu.edu; Received-SPF: Pass (protection.outlook.com: domain of osu.edu designates 164.107.81.210 as permitted sender) receiver=protection.outlook.com; client-ip=164.107.81.210; helo=cio-krc-pf03.osuad.osu.edu; Received: from cio-krc-pf03.osuad.osu.edu (164.107.81.210) by BN1AFFO11FD051.mail.protection.outlook.com (10.58.53.66) with Microsoft SMTP Server (TLS) id 15.1.293.9 via Frontend Transport; Fri, 16 Oct 2015 03:12:21 +0000 Received: from CIO-TNC-HT08.osuad.osu.edu (localhost [127.0.0.1]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by cio-krc-pf03.osuad.osu.edu (Postfix) with ESMTPS id 6497F20172 for ; Thu, 15 Oct 2015 23:12:20 -0400 (EDT) Received: from CIO-TNC-D2MBX02.osuad.osu.edu ([fe80::3960:dd86:ba2:ad26]) by CIO-TNC-HT08.osuad.osu.edu ([fe80::8431:784b:bd14:3d8%18]) with mapi id 14.03.0248.002; Thu, 15 Oct 2015 23:12:19 -0400 From: "Cantor, Scott" To: "abfab@ietf.org" Thread-Topic: Review of draft-ietf-abfab-aaa-saml-11 Thread-Index: AdEHswO8BUpjHdymSS6jZh1XsrZH3Q== Date: Fri, 16 Oct 2015 03:12:19 +0000 Message-ID: <9846A6064BD102419D06814DD0D78DE112712074@CIO-TNC-D2MBX02.osuad.osu.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [75.179.164.143] x-header-sapphire: true Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11FD051; 1:zVQ5Vn64VcsfrnAKj2DOjnc+vrtWropDXwgieAB9ors3oDcPpN28whHTaQK0tefNsATC4KllF2Hc9BR3vhHwR0cxGZlmYMJ9OAX8feX5BPhipxdM7FY/185qnSIgoszENSIXnYvoF/UT5/FLCucY86rHTWZWtGVj5na5WsT6q0cvxCzGsOH0gdK5JdO6uxuMpAPAPGFnIKIzXFaUUtC3XgFH1w2GbUUW9C7BZCIGCfR4zwnjS1KgU58z+bFwrnywvTM9/5kMcSvqvQTz3kxgugIfJT8nU4v1v9rZK7RIHOJlE7+d1QlDSp5HZQl+vi2ZAHd9mGQy0MK/lKNMClNi+myViBzTmGbWpReLRjNIkwc= X-Forefront-Antispam-Report: CIP:164.107.81.210; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(438002)(199003)(189002)(93346002)(2920100001)(2900100001)(5003600100002)(5007970100001)(2930100002)(86362001)(102836002)(50466002)(11100500001)(5004730100002)(6806005)(19580395003)(66066001)(450100001)(54356999)(50986999)(189998001)(107886002)(110136002)(47776003)(92566002)(64706001)(55846006)(87936001)(23726002)(33656002)(106466001)(97756001)(75432002)(229853001)(90282001)(109096001)(2501003)(2351001)(15975445007)(5250100002)(5008740100001)(46406003)(230783001)(89122001)(88552001)(46102003); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1AFFO11HUB030; H:cio-krc-pf03.osuad.osu.edu; FPR:; SPF:Pass; PTR:cio-krc-pf03.osuad.osu.edu; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11HUB030; 2:J5NventbZUGBD7ygFZYPHb6sSoiBB4zVia9tewJpn0onpoduCEqZpWak4nTmY9RUqAnH/3fimE0akiuDX6KRTUENNvJ4o/SLjjTKqIGWixuiSJ9qIG9W3IGbtYhDLm8s6+QUq+EtVOz34dJGtRnY9LMkFArRY6eL5ZvcV+efkBo=; 3:Ji1LF3nHH61xrw5hG25mMon5dHWYyeG0vjEA+5jXCwpcG70jqLu9MmLIXOfeWSLk1ARlAxd4hmLKn/MRBOzygc5UPg10OhG0mN7bY/6Qn7vCYoEogGm1yTc24yjlROVYLTp5BgwbFQtJ10dYrhZQkIkqJox5Zeb/9SbZ+ExFmiYXYdVLXsJMcOVOUvOgjzhJuvS7jsP62UluNZ1j3tCju6pZC/deZJstI23eiQ4TOgLVaxqen15QrgiMZYk/60ywaslYg2LE2vyEDD8MDEP7gw==; 25:WGx97pBK4MFYhknG9UH70Gearl0wm3SvCBKIhfHnQ2/ywl7bML/SVq6Ho1WCM3IsZ4OiPpDWV3q4lKmk5ctLBB7m6Qx9YWJCO1SxMbqT0pprTYK/LuVi/L3MR//y0bbVK9RhEhVwDSXPF5IGNggoTMtW0HnvGPIsjlJE9tggaFGmuSPZPmiwrabA1pqbL93yEbgMe5N+smaw8ersW1/1qXDiTMdxV0wKki5cTJSYTT1lmjQ+aoHVaI2fBm8YnsCN5+LHNlrKCd54aEZbdXvswQ== X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(8251501001)(12001); SRVR:BN1AFFO11HUB030; X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11HUB030; 20:+r21hperVSGUak2jyHt4W8EtblJbUAkcc2JdkIcFlUQs1ZyfCOU2aFYxNzSImGMysqp4A6Y2KTbMMUTSAK+2fA231q3m0WRHdnR+ayyCSpg6+qcQsZDlNfewGTzEOGE+UauOcM15lPZwVQw/yjTk1DrGrWog6BCnpuN0EnSDxXI754bSag1hUddj2ZTP6H0/KSt4UDjc/jXOnsQ+ujSMPAKOEZ3DOjNnIAsxVutjjGQIQMdrPMDvJCqq0vU4wEpifBMlUry8bHJLFLVV+WWWR3Gv3SEhYAw0PsYJOQaot3J4gIqoUpgkJXJMVCPOWZVq9IjtWBEErmJ7Za5I6w3oiRlhLQVZ7QY+2IBSqxyFlTFwL+zRXTynxtzpqSkNeYcqdA/ncLolrqBOQKSZHaGKKU73pp0bnOhM6Hiqac0StKdcwEE1i1z3rQdtdB3Mw85GJUt/nK9LvAjcqJk7ZByNIXtcwhxooXURoko5eLPM+eUGCsxZoSGnrht8q0KAioGy; 4:4mbtehhMTeNerdh+2jfpKG8scJ2jBvbYi80E1c+BfloYUhUEXbM25w09D9221OpexLH1VhroyjVEwa9limpSV3u2BJInC0bGyxi+ThjgxqBvxZbzBU4GcfQZScemPboZkXceGa9CeptWMg7zQRQpuP5EIQQJNuGypQZOWJkVGAom41pAtCBtOsTyYFmbZWdL5D1kxw3ovK1t7ssz5Hj7xCkhbl3Io0XfbNuc+yoz8QlpRHkmlIy2h7K65dkqSADc1gBNBHqbeFRrbHOwy2c22369xkLtA9MfycpRmk8g3PDhqOCRXVpO7EyZYT8gbUAnljaqBdKd/0/kqvkCr23yC+ttsdFYDOBZ9ILa5vj+3wE0XnB6WOqz5/CIfJBOGHo/ X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(520078)(5005006)(3002001)(10115024); SRVR:BN1AFFO11HUB030; BCL:0; PCL:0; RULEID:; SRVR:BN1AFFO11HUB030; X-Forefront-PRVS: 0731AA2DE6 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN1AFFO11HUB030; 23:pZKkung+JV+SQj/ItZM1YE75f255rE0g6cHU8pQ?= =?us-ascii?Q?s1NfEF3wNZvRu3/NPIHtyUVCMqTCIdq+jsz4MhYRsP4fCq1csHAKcSMhOVEy?= =?us-ascii?Q?VMwtje2AxhBzH7ktTYBxUjHT/SfeAgaUfEiynOVYgLk0aEpEPnMYDLvzPGrN?= =?us-ascii?Q?NJ97Vs/vZLTgDuIpy6MrJPlOND76feNhoiq8BOVZKDJJq3bUGJD/M+HzwWMt?= =?us-ascii?Q?rEClGum0hDZXhDP6XYlYROcSb8fCUytRH9vgJ145LucvMvt9ce29ZXR579bf?= =?us-ascii?Q?/0LVhoJtRBIWTi9cYKbLgKpV2Sd6J+dx6G5ozo0kjC5/KujLx4QSy6C8qD5a?= =?us-ascii?Q?NlBm16b3Rw99S4IdOH7EOow31dhNVjYXoNzaP2SV4IeExexb1BYD6lBfas6X?= =?us-ascii?Q?DRCzgRGvRn+VlKfXGJd7Yus2OGw5hK/kb6GvgavTjmeBZYOhNcUy4LI5vrsa?= =?us-ascii?Q?q+r6xxVGaiFK7AECzJLVu0USMnQTGxdRsNqjvVGI1U5IbCtOsV3ljkStnhCb?= =?us-ascii?Q?Fncol+lyys3QAKD1LE5R1Vyk2yOiIz19Om5KUc0lTR3CP0OyhYBJU7YJQZS3?= =?us-ascii?Q?EyMXs18dJdqBaaoD428F+dET/qFrSMePx+lUdm2L2WlrRfdmZt0huwNxK0NB?= =?us-ascii?Q?iuhTd9HVCNgf6+SxBf5J/Bfihp2vtY8JvqADBv/u3ESL8cfyZwBPIwXnkfb6?= =?us-ascii?Q?t/8HqqGOzlZPD6CHD+zG+d/dFTKKeMM9Bwo7lFBic/Pggu697fio/J2GVcRN?= =?us-ascii?Q?SWg5AgJaeHsYQ/K5sHbnZOSf+QBWEGsMmmuJBpfi+KI6RHEnNBjeQiDOV94o?= =?us-ascii?Q?tqVqTNPQBa20v6LnSfXE+j/wLxOO+WMGjOOEylNLhKM6yEDHtnchC1No8tix?= =?us-ascii?Q?FjmTu8Q7kJg51928cED23w8z6h3iJfqzmGJMS+1ee9SS1ZPYRqmmz5hI9ieg?= =?us-ascii?Q?zBu3sWXIIEN/B1c/sXxkCrTkvAVRicDYUBaGorsXqy7M2wOB+yLBXXMMHJyn?= =?us-ascii?Q?cZWXphzK8n2TWNw+RTCPYdj7xhPHCKf2+OgpSVyV3fB2z4GZHf69KVX/6quv?= =?us-ascii?Q?nNpa7gNV9W0NmBC/Lv/ZKJVIeQLXZX89cizshpszscxt7u420/BNiphK0+AC?= =?us-ascii?Q?WxL0flAk8SfceOVzQFe883sTrKqCsEclYKHlRunoM117M/eJR1NArHuPaJvY?= =?us-ascii?Q?zjyWzQtH5pscZgvm0X0tmTBiwvzXM5UXKr0WEX1qnTIPfmCo4+3PTsqZGutQ?= =?us-ascii?Q?fog2KjG2J+RmTR6+Ggow=3D?= X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11HUB030; 5:Ks6LtCAex4nF3DpLPTtSirVNY7fSHe1L4mU8g5eS/g9IeGOAOpfp10SCFD+IxhtAt/AZbnCzrXME6HXGQCPBq+tOPRIs/Zc2QAMHF5aSebbidxgGgRjYASuGyAtj5BRh/xguOuhogWqhiG8qF4xtkA==; 24:hsYd+BfnFbvW6j8frIxk1Gi1LEKxGztZnEJCpeMkRCHqsKZ4Od0+lxPrlTSZ4dH456b5x3WUBFzeTPN4j+8U3lO+L5KYCP4fiR4I4KbsG4I= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: osu.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Oct 2015 03:12:21.3080 (UTC) X-MS-Exchange-CrossTenant-Id: b4d138ca-1815-4a9b-a3a7-130a33b1e692 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=b4d138ca-1815-4a9b-a3a7-130a33b1e692; Ip=[164.107.81.210]; Helo=[cio-krc-pf03.osuad.osu.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1AFFO11HUB030 Archived-At: Subject: [abfab] Review of draft-ietf-abfab-aaa-saml-11 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2015 03:12:25 -0000 Sorry this is a little late. I gave it a pretty thorough read. Substantive: Is it useful to say something in section 3 along the lines that apart from = the binding defined in section 4, the spec doesn't prescribe any particular= pattern/usage/constraint/etc. on the use of the two RADIUS attributes it d= efines? I ask because of the statement in section 4 about the two attribute= s not being used in the same RADIUS message, and wondered if that should be= stated in section 3, but then thought maybe that wasn't something being co= nstrained by the spec, but just the binding. In 4.2 where it talks about the Status element, if the message is one that = includes the Status element, then by definition it has to have a Status ele= ment in it, but you probably mean to say that the Status element should hav= e an appropriate value in it. I'm not sure that's a SHOULD or MAY, really. = Seems like a MUST, in that if you're including a response, it's going to ha= ve to have a Status whether you want one or not. And obviously it shouldn't= be something silly. Just reads kind of oddly to me. Was there some point t= his was trying to make that I'm not getting? Some metadata corrections in section 4.3.3: In 4.3.3.1 and 4.3.3.2, it's saying that it's defining elements (and using = the notation), but there actually isn't much point in defining th= ose role elements. They can't appear in a metadata file because EntityDescr= iptor doesn't allow for extension role *elements*, only extension role type= s via Up to you guys, but I think it will create more confusion than help anythin= g by defining the elements. And in fact, your examples in 4.3.4 are wrong f= or this reason, the elements can't appear in the EntityDescriptor. Should l= ook like this: etc. If you need me to, I can edit the draft appropriately to reflect all this X= ML correction if it will save you time. It's critical that the examples don= 't have errors, obviously. Also, I don't see an actual schema appendix. As I understood it, the RFC ha= s to stand alone, so I think the schema has to be included in full form in = an appendix. That's what I did in the SAML-EC work. We need a namespace def= ined as well (and I guess that would also be added to the ABFAB URN registr= y in Section 11?), your schema fragments don't specify it. So it's not quit= e done. Again, I'm happy to do that bit if you wanted to pass me the pen. In 7.4.2, it mentions including an using the element notation. = Sorry if this is old ground, but is XML Encryption intended to be ruled out= ? One might infer that because of the literal mention of but no= t . Don't know if that's intentional. Also in 7.4.2, it mentions InResponseTo, and I think it's talking about the= SubjectConfirmationData element's attribute by that name, not the Response= element's attribute. You probably want both though. In 7.4.7 and 8.3.4, I think it should read "particular to this profile", bu= t maybe it should say something more to the effect that there are none asid= e from those applying to the use of the RADIUS binding? Nits: Section 1 intro: s/In particular where this document provides/In particular, this document p= rovides/ Section 4.2 (and 7.4.5): s/provide confidentiality and improve integrity protection/provide confiden= tiality and integrity protection/ s/other arbitrary RADIUS attributes will be used/other arbitrary RADIUS att= ributes MAY be used/ Section 4.3: The verbage "profiles of this binding" appears a few times. I think it's mo= re accurate in SAML terms to say "profiles making use of this binding". Section 4.3.2: s//"entity ID"/ s/establish a relation/establish a relationship/ s/SAML federation metadata/SAML metadata/ Section 4.3.3: s/represent AAA names associated to a particular/represent AAA names associ= ated with a particular/ Section 4.3.3.1/4.3.3.2: s/associated to this Entity/associated with the entity/ The reference link to section 3.4 of RFC7055 is not linking to the RFC in t= he HTML version of the draft. Section 7.3: "Where this specification conflicts with it, the former takes precedence." A little muddy which spec is meant to take precedence. I think you mean the= ABFAB profile does? Section 7.4.2: s/is subject conform to the following/is subject to the following constrain= ts/ Section 9: s/required to being able to route/required to route/ s/Other kind of attributes/Other kinds of attributes/ -- Scott From nobody Thu Oct 15 21:01:55 2015 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D31221B2E58 for ; Thu, 15 Oct 2015 21:01:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dhHYN1eLo6id for ; Thu, 15 Oct 2015 21:01:51 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F42311B2E55 for ; Thu, 15 Oct 2015 21:01:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 9585F20869 for ; Fri, 16 Oct 2015 00:00:17 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aAiaV39rhwjR for ; Fri, 16 Oct 2015 00:00:17 -0400 (EDT) Received: from [10.113.143.111] (c-73-182-250-48.hsd1.ma.comcast.net [73.182.250.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: mark@mail.suchdamage.org) by mail.painless-security.com (Postfix) with ESMTPSA for ; Fri, 16 Oct 2015 00:00:17 -0400 (EDT) To: abfab@ietf.org From: Mark Donnelly X-Enigmail-Draft-Status: N1110 Message-ID: <5620769F.4020203@painless-security.com> Date: Fri, 16 Oct 2015 00:01:35 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: [abfab] UI considerations document X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2015 04:01:53 -0000 All: I've spoken with Rhys about the UI considerations document (https://tools.ietf.org/html/draft-ietf-abfab-usability-ui-considerations-02), and I've volunteered to handle the next revision of the draft. I've collected the comments from the last draft and I'm working to incorporate them in. However, I have a few questions for the list. To start off, Alejandro Perez Mendez wrote that a reference to Microsoft Cardspace in section 5.1 would be nice. Does anyone have one? All I can find is a Wikipedia article, which notes the discontinuation of Cardspace. (Actually, does that warrant the removal of the inclusion in the doc? I'm not familiar with Cardspace at all.) Next, Ken Klingenstein asked about whether the user will want some degree of privacy, or a pseudo-identity. Does the UI have any visibility or control over this? As I understand the system, the information that is released about an identity is decided entirely by the IDP, and communicated to the RP. Ken also suggests that we add a privacy considerations section. If the answer to the above question is that the UI doesn't have any visibility into what attributes the IDP releases, then I'm not sure what could go in to a privacy considerations section for the UI document. The privacy considerations I see would all apply to the greater system, rather than the client UI. Does anyone have any better thoughts? Finally, Ken suggested that the UI drop the concept of an NAI having a password change URL. Ken argues that the helpdesk URL that the document already specifies would be less volatile, and the user could navigate from there. I think this would remove a usable feature of the system, and if the password change URL doesn't work then the user could go through the helpdesk anyway. Any thoughts? Thanks, --Mark From nobody Fri Oct 16 02:55:09 2015 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A842E1A0097 for ; Fri, 16 Oct 2015 02:55:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.911 X-Spam-Level: X-Spam-Status: No, score=-3.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ivaxXMtbYyiI for ; Fri, 16 Oct 2015 02:55:04 -0700 (PDT) Received: from xenon21.um.es (xenon21.um.es [155.54.212.161]) by ietfa.amsl.com (Postfix) with ESMTP id 32CFC1A0074 for ; Fri, 16 Oct 2015 02:55:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon21.um.es (Postfix) with ESMTP id 821B43F987 for ; Fri, 16 Oct 2015 11:55:02 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon21.um.es Received: from xenon21.um.es ([127.0.0.1]) by localhost (xenon21.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id enuT6LNbRz-N for ; Fri, 16 Oct 2015 11:55:02 +0200 (CEST) Received: from [155.54.204.2] (alex.inf.um.es [155.54.204.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: alex) by xenon21.um.es (Postfix) with ESMTPSA id 67FFB3F985 for ; Fri, 16 Oct 2015 11:55:01 +0200 (CEST) To: abfab@ietf.org References: <9846A6064BD102419D06814DD0D78DE112712074@CIO-TNC-D2MBX02.osuad.osu.edu> From: =?UTF-8?Q?Alejandro_P=c3=a9rez_M=c3=a9ndez?= Message-ID: <5620C974.30400@um.es> Date: Fri, 16 Oct 2015 11:55:00 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <9846A6064BD102419D06814DD0D78DE112712074@CIO-TNC-D2MBX02.osuad.osu.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [abfab] Review of draft-ietf-abfab-aaa-saml-11 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2015 09:55:07 -0000 Hi Scott, thanks for this thorough review. See my comments inline. > Sorry this is a little late. I gave it a pretty thorough read. > > Substantive: > > Is it useful to say something in section 3 along the lines that apart from the binding defined in section 4, the spec doesn't prescribe any particular pattern/usage/constraint/etc. on the use of the two RADIUS attributes it defines? I ask because of the statement in section 4 about the two attributes not being used in the same RADIUS message, and wondered if that should be stated in section 3, but then thought maybe that wasn't something being constrained by the spec, but just the binding. I think that it would make sense to move the restriction up to section 3, as one can see both attributes as exclusive alternatives to represent SAML information. If the RADIUS server decides to send a SAML Message, why sending a SAML Assertion aside? > > In 4.2 where it talks about the Status element, if the message is one that includes the Status element, then by definition it has to have a Status element in it, but you probably mean to say that the Status element should have an appropriate value in it. I'm not sure that's a SHOULD or MAY, really. Seems like a MUST, in that if you're including a response, it's going to have to have a Status whether you want one or not. And obviously it shouldn't be something silly. Just reads kind of oddly to me. Was there some point this was trying to make that I'm not getting? I didn't write that text, so we have to hear the original authors' opinion here. I guess the point was that the SAML error response is optional, and that the RADIUS server, in presence of SAML errors, can just limit to provide a RADIUS-only response. Nevertheless, I think the last two paragraphs of section 4.2 could be reduced to the following text, it the original authors agree: "In the case of a SAML processing error, the RADIUS server MAY include a SAML response message with an appropriate value for the element within the Access-Accept or Access-Reject packet to notify this fact to the Client.". Does it read better? > > Some metadata corrections in section 4.3.3: > > In 4.3.3.1 and 4.3.3.2, it's saying that it's defining elements (and using the notation), but there actually isn't much point in defining those role elements. They can't appear in a metadata file because EntityDescriptor doesn't allow for extension role *elements*, only extension role types via > > Up to you guys, but I think it will create more confusion than help anything by defining the elements. And in fact, your examples in 4.3.4 are wrong for this reason, the elements can't appear in the EntityDescriptor. Should look like this: > > entityID="https://IdentityProvider.com/SAML"> > "urn:oasis:names:tc:SAML:2.0:protocol"> > etc. > > If you need me to, I can edit the draft appropriately to reflect all this XML correction if it will save you time. It's critical that the examples don't have errors, obviously. It'd be great if you could do that, thanks! > > Also, I don't see an actual schema appendix. As I understood it, the RFC has to stand alone, so I think the schema has to be included in full form in an appendix. That's what I did in the SAML-EC work. We need a namespace defined as well (and I guess that would also be added to the ABFAB URN registry in Section 11?), your schema fragments don't specify it. So it's not quite done. Again, I'm happy to do that bit if you wanted to pass me the pen. Yes, please :) > > In 7.4.2, it mentions including an using the element notation. Sorry if this is old ground, but is XML Encryption intended to be ruled out? One might infer that because of the literal mention of but not . Don't know if that's intentional. Section 10 indicates ML signatures and encryption are optional, so I'd say they are not ruled out entirely. > > Also in 7.4.2, it mentions InResponseTo, and I think it's talking about the SubjectConfirmationData element's attribute by that name, not the Response element's attribute. You probably want both though. Yes. It refers to the SubjectConfirmationData element attribute. > > In 7.4.7 and 8.3.4, I think it should read "particular to this profile", but maybe it should say something more to the effect that there are none aside from those applying to the use of the RADIUS binding? Right. > > Nits: > > Section 1 intro: > s/In particular where this document provides/In particular, this document provides/ > > Section 4.2 (and 7.4.5): > s/provide confidentiality and improve integrity protection/provide confidentiality and integrity protection/ > > s/other arbitrary RADIUS attributes will be used/other arbitrary RADIUS attributes MAY be used/ > > Section 4.3: > The verbage "profiles of this binding" appears a few times. I think it's more accurate in SAML terms to say "profiles making use of this binding". > > Section 4.3.2: > s//"entity ID"/ > s/establish a relation/establish a relationship/ > s/SAML federation metadata/SAML metadata/ > > Section 4.3.3: > s/represent AAA names associated to a particular/represent AAA names associated with a particular/ > > Section 4.3.3.1/4.3.3.2: > s/associated to this Entity/associated with the entity/ Thanks! > > The reference link to section 3.4 of RFC7055 is not linking to the RFC in the HTML version of the draft. Yes, those ones are automatically generated (I just have plain text on the XML file). I have to check whether xml2rfc has an option to disable automatic references being generated. Otherwise, I guess I can make them an actual reference, linking to the right document. > > Section 7.3: > "Where this specification conflicts with it, the former takes precedence." > A little muddy which spec is meant to take precedence. I think you mean the ABFAB profile does? Would the following be clearer? The ABFAB Authentication Profile is a profile of the SAML V2.0 Authentication Request Protocol [OASIS.saml-core-2.0-os]. Where both specifications conflict, the ABFAB Authentication Profile takes precedence. > > Section 7.4.2: > s/is subject conform to the following/is subject to the following constraints/ > > Section 9: > s/required to being able to route/required to route/ > s/Other kind of attributes/Other kinds of attributes/ Again, thank you for the review, and for your offer to help us with the XML corrections. Regards, Alejandro > > -- Scott > > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From nobody Fri Oct 16 05:55:48 2015 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C23181ACEEC for ; Fri, 16 Oct 2015 05:55:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nX4DNUvjmzpN for ; Fri, 16 Oct 2015 05:55:43 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FC951ACEF0 for ; Fri, 16 Oct 2015 05:55:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 0DC4C207DF; Fri, 16 Oct 2015 08:54:09 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2q9qv_70zAoE; Fri, 16 Oct 2015 08:54:08 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-50-136-30-120.hsd1.ma.comcast.net [50.136.30.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Fri, 16 Oct 2015 08:54:08 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 8069888C9F; Fri, 16 Oct 2015 08:55:38 -0400 (EDT) From: Sam Hartman To: Alejandro =?utf-8?B?UMOpcmV6IE3DqW5kZXo=?= References: <9846A6064BD102419D06814DD0D78DE112712074@CIO-TNC-D2MBX02.osuad.osu.edu> <5620C974.30400@um.es> Date: Fri, 16 Oct 2015 08:55:38 -0400 In-Reply-To: <5620C974.30400@um.es> ("Alejandro =?utf-8?Q?P=C3=A9rez_M?= =?utf-8?Q?=C3=A9ndez=22's?= message of "Fri, 16 Oct 2015 11:55:00 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: abfab@ietf.org Subject: Re: [abfab] Review of draft-ietf-abfab-aaa-saml-11 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2015 12:55:44 -0000 >>>>> "Alejandro" =3D=3D Alejandro P=C3=A9rez M=C3=A9ndez writ= es: Alejandro> Hi Scott, thanks for this thorough review. See my Alejandro> comments inline. >> Sorry this is a little late. I gave it a pretty thorough read. >>=20 >> Substantive: >>=20 >> Is it useful to say something in section 3 along the lines that >> apart from the binding defined in section 4, the spec doesn't >> prescribe any particular pattern/usage/constraint/etc. on the use >> of the two RADIUS attributes it defines? I ask because of the >> statement in section 4 about the two attributes not being used in >> the same RADIUS message, and wondered if that should be stated in >> section 3, but then thought maybe that wasn't something being >> constrained by the spec, but just the binding. Alejandro> I think that it would make sense to move the restriction Alejandro> up to section 3, as one can see both attributes as Alejandro> exclusive alternatives to represent SAML information. If Alejandro> the RADIUS server decides to send a SAML Message, why Alejandro> sending a SAML Assertion aside? Agreed. Alejandro> I didn't write that text, so we have to hear the original Alejandro> authors' opinion here. I guess the point was that the Alejandro> SAML error response is optional, and that the RADIUS Alejandro> server, in presence of SAML errors, can just limit to Alejandro> provide a RADIUS-only response. Yes, that's the intent as I understand it. Alejandro> Nevertheless, I think the last two paragraphs of section Alejandro> 4.2 could be reduced to the following text, it the Alejandro> original authors agree: Alejandro> "In the case of a SAML processing error, the RADIUS Alejandro> server MAY include a SAML response message with an Alejandro> appropriate value for the element within Alejandro> the Access-Accept or Access-Reject packet to notify this Alejandro> fact to the Client.". I think the following would be more clear: "In the case of a SAML processing error, the RADIUS server MAY include a SAML response message with an appropriate value for the element within the Access-Accept or Access-Reject packet to notify the client. Alternatively, the RADIUS server can respond without a SAML-Message attrib= ute.". Or did we end up calling it SAML-Protocol? --Sam From nobody Fri Oct 16 06:02:41 2015 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06BF61AD0C3 for ; Fri, 16 Oct 2015 06:02:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8b8F6n09PI6F for ; Fri, 16 Oct 2015 06:02:38 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21F301AD0C4 for ; Fri, 16 Oct 2015 06:02:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id E1BF32086A; Fri, 16 Oct 2015 09:01:03 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oyLSO-2vwMes; Fri, 16 Oct 2015 09:01:03 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-50-136-30-120.hsd1.ma.comcast.net [50.136.30.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Fri, 16 Oct 2015 09:01:03 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 4E7F888C9F; Fri, 16 Oct 2015 09:02:33 -0400 (EDT) From: Sam Hartman To: Mark Donnelly References: <5620769F.4020203@painless-security.com> Date: Fri, 16 Oct 2015 09:02:33 -0400 In-Reply-To: <5620769F.4020203@painless-security.com> (Mark Donnelly's message of "Fri, 16 Oct 2015 00:01:35 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: abfab@ietf.org Subject: Re: [abfab] UI considerations document X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2015 13:02:40 -0000 >>>>> "Mark" == Mark Donnelly writes: Mark> All: I've spoken with Rhys about the UI considerations Mark> document Mark> (https://tools.ietf.org/html/draft-ietf-abfab-usability-ui-considerations-02), Mark> and I've volunteered to handle the next revision of the draft. Mark> I've collected the comments from the last draft and I'm Mark> working to incorporate them in. Mark> However, I have a few questions for the list. Mark> To start off, Alejandro Perez Mendez wrote that a reference to Mark> Microsoft Cardspace in section 5.1 would be nice. Does anyone Mark> have one? All I can find is a Wikipedia article, which notes Mark> the discontinuation of Cardspace. (Actually, does that Mark> warrant the removal of the inclusion in the doc? I'm not Mark> familiar with Cardspace at all.) I definitely think it is worth mentioning; it was certainly something we were all thinking of. See if you find something starting at https://technet.microsoft.com/en-us/magazine/2006.07.infocard.aspx Mark> Next, Ken Klingenstein asked about whether the user will want Mark> some degree of privacy, or a pseudo-identity. Does the UI Mark> have any visibility or control over this? As I understand the Mark> system, the information that is released about an identity is Mark> decided entirely by the IDP, and communicated to the RP. Correct. The overall protocol supports pseudonyms, but the UI is not currently involved in this decision at all. Mark> Ken also suggests that we add a privacy considerations Mark> section. If the answer to the above question is that the UI Mark> doesn't have any visibility into what attributes the IDP Mark> releases, then I'm not sure what could go in to a privacy Mark> considerations section for the UI document. The privacy Mark> considerations I see would all apply to the greater system, Mark> rather than the client UI. Does anyone have any better Mark> thoughts? So, here are privacy impacts I can think of from the UI. * Automatically choosing an identity can have privacy impact. Think of the Chrome incognito discussion. Whether to let a given application choose a given identity for a given service has privacy impact. * Discussion of the difference between the Kerberos model (use your default credential when you can, giving your KDC information about what services you access even if they don't support Kerberos at all and our model of requesting the user explicitly select an identity when first talking to a service. Note that the impact would be a bit different for ABFAB if we used a default credential. Rather than letting the home IDP know what service you are using, it would let the service know what IDP you were using even if the IDP was inappropriate for that service. Mark> Finally, Ken suggested that the UI drop the concept of an NAI Mark> having a password change URL. Ken argues that the helpdesk Mark> URL that the document already specifies would be less Mark> volatile, and the user could navigate from there. I think Mark> this would remove a usable feature of the system, and if the Mark> password change URL doesn't work then the user could go Mark> through the helpdesk anyway. Any thoughts? I'd assume that if someone doesn't want a password change URI they can not fill it in. Also, this is an informational document. So I tend to agree with you. From nobody Fri Oct 16 06:17:24 2015 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 774091ACD93 for ; Fri, 16 Oct 2015 06:17:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z6z5yCaS9nL6 for ; Fri, 16 Oct 2015 06:17:20 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0739.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::739]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 246B41A901C for ; Fri, 16 Oct 2015 06:17:19 -0700 (PDT) Received: from BN1AFFO11FD045.protection.gbl (10.58.52.31) by BN1AFFO11HUB024.protection.gbl (10.58.52.134) with Microsoft SMTP Server (TLS) id 15.1.293.9; Fri, 16 Oct 2015 13:17:01 +0000 Authentication-Results: spf=pass (sender IP is 164.107.81.210) smtp.mailfrom=osu.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=osu.edu; Received-SPF: Pass (protection.outlook.com: domain of osu.edu designates 164.107.81.210 as permitted sender) receiver=protection.outlook.com; client-ip=164.107.81.210; helo=cio-krc-pf03.osuad.osu.edu; Received: from cio-krc-pf03.osuad.osu.edu (164.107.81.210) by BN1AFFO11FD045.mail.protection.outlook.com (10.58.53.60) with Microsoft SMTP Server (TLS) id 15.1.293.9 via Frontend Transport; Fri, 16 Oct 2015 13:17:01 +0000 Received: from CIO-TNC-HT07.osuad.osu.edu (localhost [127.0.0.1]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by cio-krc-pf03.osuad.osu.edu (Postfix) with ESMTPS id 3815A20174; Fri, 16 Oct 2015 09:17:01 -0400 (EDT) Received: from CIO-TNC-D2MBX02.osuad.osu.edu ([fe80::3960:dd86:ba2:ad26]) by CIO-TNC-HT07.osuad.osu.edu ([fe80::3ca1:e895:a165:1359%10]) with mapi id 14.03.0248.002; Fri, 16 Oct 2015 09:17:00 -0400 From: "Cantor, Scott" To: =?iso-8859-1?Q?Alejandro_P=E9rez_M=E9ndez?= , "abfab@ietf.org" Thread-Topic: [abfab] Review of draft-ietf-abfab-aaa-saml-11 Thread-Index: AdEHswO8BUpjHdymSS6jZh1XsrZH3QAZzvgAAAF1mXA= Date: Fri, 16 Oct 2015 13:16:59 +0000 Message-ID: <9846A6064BD102419D06814DD0D78DE1127144C9@CIO-TNC-D2MBX02.osuad.osu.edu> References: <9846A6064BD102419D06814DD0D78DE112712074@CIO-TNC-D2MBX02.osuad.osu.edu> <5620C974.30400@um.es> In-Reply-To: <5620C974.30400@um.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [75.179.164.143] x-header-sapphire: true Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11FD045; 1:Eb8mBFZZ007AX1WbCwAob5NFolnzFCO4KQQm5yWdo8Ao0x2pdW6G3E2+wddKscTig6xPvUdto5SD6UPmsor4k8bC+Bt5QcNwIBH5GqAPUzj8/oH6xYoPDBKMm8ze7IxbjpaRXH673oKitslM/p+jzWV5OsI50AtmCByUTpUT/GDQPLHKqJOhlma9tcS5QT/1fHHKq2jhObVzvy3OgkmXJM8r2Dw3r8pyzfhxssfdJmeGDiyinpxyl6XG8EQpkoBovFnnrJ/ZFeN7ZxAf05vWzemJSF8z/9UYpHqqL8DK6pLnh1+ckwjP0OJopPxfe0ywkvdVe1yDLQIavImu//4ReolwDzKTU6FAf7i31jHFepsNuCH/Nd/+vFcYy+HIhDx0dAcQAzwjAHcuFhUqTt5POA== X-Forefront-Antispam-Report: CIP:164.107.81.210; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(438002)(199003)(189002)(75432002)(2900100001)(50466002)(2950100001)(11100500001)(2920100001)(54356999)(76176999)(86362001)(5003600100002)(5004730100002)(93346002)(6806005)(19580395003)(66066001)(47776003)(92566002)(5007970100001)(189998001)(5001770100001)(64706001)(107886002)(50986999)(87936001)(55846006)(23756003)(106466001)(2501003)(90282001)(33656002)(5250100002)(89122001)(46102003)(5008740100001)(109096001)(102836002)(88552001)(230783001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1AFFO11HUB024; H:cio-krc-pf03.osuad.osu.edu; FPR:; SPF:Pass; PTR:cio-krc-pf03.osuad.osu.edu; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11HUB024; 2:gw9ZIeyCWuwba3mhBxAKG8+BioaCquIF4z6VggcanyjSSdl1V0eDsytexWgtYQw8iRGYw89Nich6dLfpU9QgMmHSuzstuuUCkwQ6EuvWC1nLVVAR56qq0dwc0T6KeaZFjVPvemgW4yIzQCVDXMyEEFOAluzJEJ7nCbJdP9NbR2o=; 3:Wq7cEAXXO4Vr0yrcgqaYHk2yWXsLtjGpSWjvHAGuFU6nM0dCbtm/oFTuar2p3u0etSfSnj+Brlm3HrfMuP5E4eGJNjb0hIlmCGxODqFUhLzophNiooaqhgCPXnmAqo/AgcqrVTEC/oYp7ZdBAE0clWudUBI8FROvO/BBeoZWwPYFAIlJa/yqND99eArYSDPipSI1xho9xeX85dF8O6jPycGNE2WQvWMydPcfO5l4UxyH4U74p8t1qjIQpI2W8w7sLHmiK0npe9eHR/afKdOMBw==; 25:sCCpS5hjLdgrdI/xE9badjE/wG8qPbrOr9b/pDsyw8zPVFO/UZI36IGGO8zPrSyo9FfVlRginufdzu5g1CO+wWNOKmF0yaZWNSqSaJw6zHNHLOg5waQ97DVgbG8kVq4fVyGDpA6iuTaUjleqXhdT12Etxc2vmmCI69UNKJyc1X/HRs0xoNEylAZiqxQF4J7fSBL7P6MGki9oDY3Bg6JUF/kJPuMKN3wyqj5EjajvEjLo7lnAt1OBfgp6UjhvC+TYSyxUFsWGHz+OPoFsPjVVXg== X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(8251501001); SRVR:BN1AFFO11HUB024; X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11HUB024; 20:WXFQ8fyn9FiYu2Ft/Zu6qNqAEewOIiHO9PnF1+CSonW1/rMvL2+vw2JCaC0MblHmB6dcQ88oTiDV5D8nIyKVZkkn0J7q53L5eN1fuvq6SVp5z9upZMZEgDILJxzE/R1N8DYzKuI/JD3aLejpFHwQdb7a6Pd1n/2ebu6WwbPa/q/uqTXSHMtjfcDwecXnF2NEoW/6vZJut0Y3zelzGoxk/qZZneGDSzEeC8xEQ4kr1WpO9rBSEisP87yRzhYQuwGD6TarzmvHH3sGeDoS6E9dnjv/176NSLwQa2ljGsSX/FQ3TdpmKErwNujCMAhqi0pfx+k/D94B/PgHv565MxuZzPl17jo4Cn05Zbb/M5fXggAFKjsRev55soqd/E85ku4Q7WJByzd9ViYrBayJKvXNphrj4HP1S4DLf/ocyVky6yopWJv+UbBIZaKdzgwnZ0odJIFSpb5RBLa/n0lLClW+3yFUfUc1SIcOOv0wAi9RpwJxKtyex5NNPc1zqewGqCLM; 4:9h51REptS5vV20ZPM42Jh4yeH6bMiTaJDPR2s63clQ1fhSScJhwaDwpF43G5hoj33P+BCuVqNxvc0PbjKLCyflsOk31+SFRhDPlZ0tvTKJJvDnD7CofkzF3qOs8sLLN8cnehsuLmTUh5Ua4NOslzMWfE+W07gasulMS7tp5zwTGcod3Q2nZiII6fLGuEdqHjI+5dWuUwCUHCC2rggsx7Yy1buSl+fbcCNTcHeuzszEJklvDJJ3tNdMHTN/qLzpCWkO+YU457GMScnzvZDna/Bc8l0bzZ20h9ucN0m4CDyxlwPUbbdHZ0/X5JJ0+1XjaihPvFhAFgVC69s9j37vkqfWK2RRAJIh4L80NvabnbLeZNQVs1UVWsi18PmW0b9jWF X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(520078)(3002001)(10115024); SRVR:BN1AFFO11HUB024; BCL:0; PCL:0; RULEID:; SRVR:BN1AFFO11HUB024; X-Forefront-PRVS: 0731AA2DE6 X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; BN1AFFO11HUB024; 23:kdRxMELoaSqdI0AptKYcTy4coGpn28xRekxBc?= =?iso-8859-1?Q?nQGc5zEHNMq1Hg+x7y9yhOZeHH9OG+qHuTEgtc2/MVoz30dypLIn08ce5T?= =?iso-8859-1?Q?8HOa+OLvwfiyQWTdIA489odi/CjUj21kC9L5hvlB5sA24TBE2RNxF1mmKv?= =?iso-8859-1?Q?nP+kILA5q3U3KivpFlRFW7xZyFMomm9mmAZk8dZLOFHFzzzVXwz9KlmPDb?= =?iso-8859-1?Q?wbziFK1Hey8qdvHJ3lTkP8AtWbTkwMl5n/3SmgC0jMd2MXsNqYhHi/M0ow?= =?iso-8859-1?Q?+dnxaRenbRENqd+71Ktig4Yc/FQp77saeQomE04l9xA/pdBQEGcFahNZQW?= =?iso-8859-1?Q?Bh9A6crl2kr4+MapZJOnQOP9bum10k6dsIelnCbiaSJ0d7c558I0Ka/eTZ?= =?iso-8859-1?Q?r0tggkTSN/pUcMcT0TgkVnnJI0Qu/fIzhyxom85P7vI6anWabQMoW8Xmj+?= =?iso-8859-1?Q?03JWDkwJ3RLGGRl7EI0xRfS1B0V4wEBtje3ccFvcuHSXzgLRsF7s3YLVpn?= =?iso-8859-1?Q?8ydnV0NlZClgpXw7/+X1sYEWLkde2d6kcIMHVjNMcvQGLeaZ1CrYBIk21d?= =?iso-8859-1?Q?2hXjEYXX+HjzP1S0OKDu0Knta3LQK5KdOYEa8ZUWBhpdNix5vF5et0Zh5l?= =?iso-8859-1?Q?dHFlZiF1ydxAqeqnZmG1ieYzqjEqVN4QGcdoN49KiOVoj9WPLomHvWBC02?= =?iso-8859-1?Q?Dzlfr/U/5Ij4mkmLx/yyXj9SmxIrKYGOQMc3D1Zsrrmw5i2mxZTMwPFNIH?= =?iso-8859-1?Q?vEE7Qx2LmiGITR45giWZLyYptFED6Wepu+Z2O+GOljn8noWO6GEYIogkG7?= =?iso-8859-1?Q?CzK/nCDvJ1hd3lCGlqxLGzS2ANC6dirf1q17ei99fD8mfmhWrlw6X8y1K2?= =?iso-8859-1?Q?pSI2X2T1Kz/WoSo04xU70BChsP+EN2rjpri0gCfrZu0wyNEdaHytDC1w58?= =?iso-8859-1?Q?dghDzNYZn9eDOkqTxadwSUd2XGWb2va0jtKC0vQSXbVPAf243/8+bs5R9w?= =?iso-8859-1?Q?mJooipiWd31acwCQNd/Ix8GgZzp+TDhKHSROHv/rYxmM0AWyOn4m1omF/n?= =?iso-8859-1?Q?Oy+wfRYRel33ZvX7UjhL8e8UL/cpTsTWA0cjPTY2vi5bXxB7ytCwIifHci?= =?iso-8859-1?Q?6zeCv3dVxQFZI+CsHeSH4o/ADc8m8I5/MTODAWxL420uwVPtOl6d+Nph4q?= =?iso-8859-1?Q?yNJ159ASECwsWEvwjSiPZuLq8ObAhMG3UKA=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11HUB024; 5:7Wx20WuPNYBCY3+DNmsrgXrMvYLaFslYAzw+vc/WUtBxvXDDmrZbnkGYjlfYZd8qpQbHe2tZkotVz+7DxOcgZBzMXLsPiuQfGdjn5eOWxpsK9n6J+rpVXL1XzKhMRa12/pfJKGpl39oBTLDv1YmlCQ==; 24:NYeNmqHhZAb8FJdzo5X55Dgy3cOjl9EMVfhOsSMvTO2iuWjzpF89KxK4fni5+gfqA6zBNfWFpKKW8Xg7s0NzSZT9YRcjyx3z+LwTjLcOk50= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: osu.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Oct 2015 13:17:01.7576 (UTC) X-MS-Exchange-CrossTenant-Id: b4d138ca-1815-4a9b-a3a7-130a33b1e692 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=b4d138ca-1815-4a9b-a3a7-130a33b1e692; Ip=[164.107.81.210]; Helo=[cio-krc-pf03.osuad.osu.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1AFFO11HUB024 Archived-At: Subject: Re: [abfab] Review of draft-ietf-abfab-aaa-saml-11 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2015 13:17:23 -0000 > Does it read better? I think Sam's suggestion works, and now I understand what you were trying t= o say, thanks. > It'd be great if you could do that, thanks! I can take an edit pass within the next few days to get the XML fixed, can = you pass me a copy of the WD XML source? Or if you want to finish up your e= dits and then pass it along, that's fine. > Section 10 indicates ML signatures and encryption are optional, so I'd > say they are not ruled out entirely. In that case I'd use wording that says " or ". Or just use "assertion" in lower case. > Would the following be clearer? >=20 > The ABFAB Authentication Profile is a profile of the SAML V2.0 > Authentication Request Protocol [OASIS.saml-core-2.0-os]. Where both > specifications conflict, the ABFAB Authentication Profile takes > precedence. That's fine. -- Scott From nobody Fri Oct 16 07:27:12 2015 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 503F11B2C2F for ; Fri, 16 Oct 2015 07:27:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.911 X-Spam-Level: X-Spam-Status: No, score=-3.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dFMei00r39OT for ; Fri, 16 Oct 2015 07:27:09 -0700 (PDT) Received: from xenon22.um.es (xenon22.um.es [155.54.212.162]) by ietfa.amsl.com (Postfix) with ESMTP id D2CF01B2C2D for ; Fri, 16 Oct 2015 07:27:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon22.um.es (Postfix) with ESMTP id 69646468; Fri, 16 Oct 2015 16:27:05 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon22.um.es Received: from xenon22.um.es ([127.0.0.1]) by localhost (xenon22.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Fe8cdYJd8o2A; Fri, 16 Oct 2015 16:27:05 +0200 (CEST) Received: from [192.168.1.102] (84.121.15.122.dyn.user.ono.com [84.121.15.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: alex) by xenon22.um.es (Postfix) with ESMTPSA id 7753F131; Fri, 16 Oct 2015 16:27:02 +0200 (CEST) To: Sam Hartman References: <9846A6064BD102419D06814DD0D78DE112712074@CIO-TNC-D2MBX02.osuad.osu.edu> <5620C974.30400@um.es> From: =?UTF-8?Q?Alejandro_P=c3=a9rez_M=c3=a9ndez?= Message-ID: <56210936.4000808@um.es> Date: Fri, 16 Oct 2015 16:27:02 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: abfab@ietf.org Subject: Re: [abfab] Review of draft-ietf-abfab-aaa-saml-11 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2015 14:27:11 -0000 El 16/10/15 a las 14:55, Sam Hartman escribió: >>>>>> "Alejandro" == Alejandro Pérez Méndez writes: > Alejandro> Hi Scott, thanks for this thorough review. See my > Alejandro> comments inline. > > >> Sorry this is a little late. I gave it a pretty thorough read. > >> > >> Substantive: > >> > >> Is it useful to say something in section 3 along the lines that > >> apart from the binding defined in section 4, the spec doesn't > >> prescribe any particular pattern/usage/constraint/etc. on the use > >> of the two RADIUS attributes it defines? I ask because of the > >> statement in section 4 about the two attributes not being used in > >> the same RADIUS message, and wondered if that should be stated in > >> section 3, but then thought maybe that wasn't something being > >> constrained by the spec, but just the binding. > > Alejandro> I think that it would make sense to move the restriction > Alejandro> up to section 3, as one can see both attributes as > Alejandro> exclusive alternatives to represent SAML information. If > Alejandro> the RADIUS server decides to send a SAML Message, why > Alejandro> sending a SAML Assertion aside? > > Agreed. > > Alejandro> I didn't write that text, so we have to hear the original > Alejandro> authors' opinion here. I guess the point was that the > Alejandro> SAML error response is optional, and that the RADIUS > Alejandro> server, in presence of SAML errors, can just limit to > Alejandro> provide a RADIUS-only response. > > Yes, that's the intent as I understand it. > > Alejandro> Nevertheless, I think the last two paragraphs of section > Alejandro> 4.2 could be reduced to the following text, it the > Alejandro> original authors agree: > > Alejandro> "In the case of a SAML processing error, the RADIUS > Alejandro> server MAY include a SAML response message with an > Alejandro> appropriate value for the element within > Alejandro> the Access-Accept or Access-Reject packet to notify this > Alejandro> fact to the Client.". > > I think the following would be more clear: > > "In the case of a SAML processing error, the RADIUS > server MAY include a SAML response message with an > appropriate value for the element within > the Access-Accept or Access-Reject packet to notify the client. > Alternatively, the RADIUS server can respond without a SAML-Message attribute.". That sounds better, yes. > > Or did we end up calling it SAML-Protocol? Oh, right. I'll change that. Regards, Alejandro > > --Sam From nobody Fri Oct 16 07:29:00 2015 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 809F81B2C3D for ; Fri, 16 Oct 2015 07:28:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.911 X-Spam-Level: X-Spam-Status: No, score=-3.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3aeyA0WpzWlU for ; Fri, 16 Oct 2015 07:28:57 -0700 (PDT) Received: from xenon22.um.es (xenon22.um.es [155.54.212.162]) by ietfa.amsl.com (Postfix) with ESMTP id 1A8A31B2C1B for ; Fri, 16 Oct 2015 07:28:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon22.um.es (Postfix) with ESMTP id 661AE518; Fri, 16 Oct 2015 16:28:56 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon22.um.es Received: from xenon22.um.es ([127.0.0.1]) by localhost (xenon22.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id rqGJIdOingR5; Fri, 16 Oct 2015 16:28:56 +0200 (CEST) Received: from [192.168.1.102] (84.121.15.122.dyn.user.ono.com [84.121.15.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: alex) by xenon22.um.es (Postfix) with ESMTPSA id E2554131; Fri, 16 Oct 2015 16:28:54 +0200 (CEST) To: "Cantor, Scott" , "abfab@ietf.org" References: <9846A6064BD102419D06814DD0D78DE112712074@CIO-TNC-D2MBX02.osuad.osu.edu> <5620C974.30400@um.es> <9846A6064BD102419D06814DD0D78DE1127144C9@CIO-TNC-D2MBX02.osuad.osu.edu> From: =?UTF-8?Q?Alejandro_P=c3=a9rez_M=c3=a9ndez?= Message-ID: <562109A6.90203@um.es> Date: Fri, 16 Oct 2015 16:28:54 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <9846A6064BD102419D06814DD0D78DE1127144C9@CIO-TNC-D2MBX02.osuad.osu.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [abfab] Review of draft-ietf-abfab-aaa-saml-11 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2015 14:28:58 -0000 El 16/10/15 a las 15:16, Cantor, Scott escribió: >> Does it read better? > I think Sam's suggestion works, and now I understand what you were trying to say, thanks. I agree. > >> It'd be great if you could do that, thanks! > I can take an edit pass within the next few days to get the XML fixed, can you pass me a copy of the WD XML source? Or if you want to finish up your edits and then pass it along, that's fine. Whichever works better for you. It might be better if you do the XML fixes before, so I can adapt the text afterwards. Let me send you the XML file in a private mail. > >> Section 10 indicates ML signatures and encryption are optional, so I'd >> say they are not ruled out entirely. > In that case I'd use wording that says " or ". Or just use "assertion" in lower case. I think using assertion might be better, since this might happen in other places along the document. > >> Would the following be clearer? >> >> The ABFAB Authentication Profile is a profile of the SAML V2.0 >> Authentication Request Protocol [OASIS.saml-core-2.0-os]. Where both >> specifications conflict, the ABFAB Authentication Profile takes >> precedence. > That's fine. Regards, Alejandro > -- Scott > From nobody Mon Oct 19 11:15:23 2015 Return-Path: X-Original-To: abfab@ietf.org Delivered-To: abfab@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 99EB01B2B05; Mon, 19 Oct 2015 11:15:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.6.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151019181520.24106.42077.idtracker@ietfa.amsl.com> Date: Mon, 19 Oct 2015 11:15:20 -0700 Archived-At: Cc: abfab@ietf.org Subject: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-12.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 18:15:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Application Bridging for Federated Access Beyond web Working Group of the IETF. Title : A RADIUS Attribute, Binding, Profiles, Name Identifier Format, and Confirmation Methods for SAML Authors : Josh Howlett Sam Hartman Alejandro Perez-Mendez Filename : draft-ietf-abfab-aaa-saml-12.txt Pages : 31 Date : 2015-10-19 Abstract: This document describes the use of the Security Assertion Mark-up Language (SAML) with RADIUS in the context of the ABFAB architecture. It defines two RADIUS attributes, a SAML binding, a SAML name identifier format, two SAML profiles, and two SAML confirmation methods. The RADIUS attributes permit encapsulation of SAML assertions and protocol messages within RADIUS, allowing SAML entities to communicate using the binding. The two profiles describe the application of this binding for ABFAB authentication and assertion query/request, enabling a Relying Party to request authentication of, or assertions for, users or machines (Clients). These Clients may be named using a NAI name identifier format. Finally, the subject confirmation methods allow requests and queries to be issued for a previously authenticated user or machine without needing to explicitly identify them as the subject. These artifacts have been defined to permit application in AAA scenarios other than ABFAB, such as network access. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-abfab-aaa-saml/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-abfab-aaa-saml-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-abfab-aaa-saml-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 19 11:34:04 2015 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CEE31B2B07 for ; Mon, 19 Oct 2015 11:34:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.911 X-Spam-Level: X-Spam-Status: No, score=-3.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bNfoaYMSWUDh for ; Mon, 19 Oct 2015 11:34:00 -0700 (PDT) Received: from xenon23.um.es (xenon23.um.es [155.54.212.163]) by ietfa.amsl.com (Postfix) with ESMTP id A58551B2AE3 for ; Mon, 19 Oct 2015 11:33:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon23.um.es (Postfix) with ESMTP id DF3B92C0E for ; Mon, 19 Oct 2015 20:33:56 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon23.um.es Received: from xenon23.um.es ([127.0.0.1]) by localhost (xenon23.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 9df2-a2KMR7f for ; Mon, 19 Oct 2015 20:33:56 +0200 (CEST) Received: from [192.168.1.5] (79.109.150.87.dyn.user.ono.com [79.109.150.87]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: alex) by xenon23.um.es (Postfix) with ESMTPSA id AFB072C3B for ; Mon, 19 Oct 2015 20:33:54 +0200 (CEST) To: abfab@ietf.org References: <20151019181520.24106.42077.idtracker@ietfa.amsl.com> From: =?UTF-8?Q?Alejandro_P=c3=a9rez_M=c3=a9ndez?= Message-ID: <56253791.3010403@um.es> Date: Mon, 19 Oct 2015 20:33:53 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151019181520.24106.42077.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-12.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 18:34:02 -0000 Dear all, today ended the WGLC period for this draft, so we have addressed all the comments we have received since -11 version and submitted a new version. The most relevant changes include an updated and revised version of the SAML metadata and XML schema (thanks Scott!), as well as the change of the name of the "SAML-Message" RADIUS attribute to "SAML-Protocol". If I haven't missed anything, I think this should be the version to move to the next step. Best regards, Alejandro > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Application Bridging for Federated Access Beyond web Working Group of the IETF. > > Title : A RADIUS Attribute, Binding, Profiles, Name Identifier Format, and Confirmation Methods for SAML > Authors : Josh Howlett > Sam Hartman > Alejandro Perez-Mendez > Filename : draft-ietf-abfab-aaa-saml-12.txt > Pages : 31 > Date : 2015-10-19 > > Abstract: > This document describes the use of the Security Assertion Mark-up > Language (SAML) with RADIUS in the context of the ABFAB architecture. > It defines two RADIUS attributes, a SAML binding, a SAML name > identifier format, two SAML profiles, and two SAML confirmation > methods. The RADIUS attributes permit encapsulation of SAML > assertions and protocol messages within RADIUS, allowing SAML > entities to communicate using the binding. The two profiles describe > the application of this binding for ABFAB authentication and > assertion query/request, enabling a Relying Party to request > authentication of, or assertions for, users or machines (Clients). > These Clients may be named using a NAI name identifier format. > Finally, the subject confirmation methods allow requests and queries > to be issued for a previously authenticated user or machine without > needing to explicitly identify them as the subject. These artifacts > have been defined to permit application in AAA scenarios other than > ABFAB, such as network access. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-abfab-aaa-saml/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-abfab-aaa-saml-12 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-abfab-aaa-saml-12 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From nobody Mon Oct 19 12:33:17 2015 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A5EA1B2C02 for ; Mon, 19 Oct 2015 12:32:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.661 X-Spam-Level: X-Spam-Status: No, score=-1.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ts249GUy_Wdx for ; Mon, 19 Oct 2015 12:32:56 -0700 (PDT) Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [IPv6:2001:6b0:8:2::201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 430391B2B98 for ; Mon, 19 Oct 2015 12:32:54 -0700 (PDT) Received: from smtp1.sunet.se (smtp1.sunet.se [192.36.171.214]) by e-mailfilter01.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id t9JJWpjN007580 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Mon, 19 Oct 2015 21:32:51 +0200 Received: from kerio.sunet.se (kerio.sunet.se [192.36.171.210]) by smtp1.sunet.se (8.14.9/8.14.7) with ESMTP id t9JJWmV0004351 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 19 Oct 2015 21:32:51 +0200 (CEST) VBR-Info: md=sunet.se; mc=all; mv=swamid.se DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sunet.se; s=default; t=1445283171; bh=6WiUPtBUQGLT/EogySkGpV575Frs5JD9/CC9v/qZaT4=; h=Subject:To:References:From:Date:In-Reply-To; b=yjgH4IbgQ+EKGNEWWLudyFXSGReDVJdVwP1G5Y9Ski6y0zYMWpsujAsOMZSq26kZb dapxqjxXkwruQutcFA/jVHgxd5q0VmbPumt5VQEL4AGHYCIIzcEH6xm5sDav7wQsb/ X/ItHyezfomuY7pNqMmxyAalgbro+exEVXp6najw= X-Footer: c3VuZXQuc2U= Received: from [10.0.0.120] ([62.102.145.131]) (authenticated user leifj@sunet.se) by kerio.sunet.se (Kerio Connect 8.5.2) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128 bits)) for abfab@ietf.org; Mon, 19 Oct 2015 21:32:45 +0200 To: abfab@ietf.org References: <20151019181520.24106.42077.idtracker@ietfa.amsl.com> <56253791.3010403@um.es> From: Leif Johansson Message-ID: <5625455D.20707@sunet.se> Date: Mon, 19 Oct 2015 21:32:45 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <56253791.3010403@um.es> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, outbound-sunet-se:default, sunet-se:default, base:default, @@RPTN) X-CanIt-Geo: ip=192.36.171.210; country=SE; latitude=59.3294; longitude=18.0686; http://maps.google.com/maps?q=59.3294,18.0686&z=6 X-CanItPRO-Stream: outbound-sunet-se:outbound (inherits from outbound-sunet-se:default, sunet-se:default, base:default) X-Canit-Stats-ID: 09Pv7wPfi - 590c0b32f057 - 20151019 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw Received-SPF: neutral (e-mailfilter01.sunet.se: 192.36.171.210 is neither permitted nor denied by domain leifj@sunet.se) receiver=e-mailfilter01.sunet.se; client-ip=192.36.171.210; envelope-from=; helo=smtp1.sunet.se; identity=mailfrom X-Scanned-By: CanIt (www . roaringpenguin . com) on 192.36.171.201 Archived-At: Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-12.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 19:32:59 -0000 On 2015-10-19 20:33, Alejandro Pérez Méndez wrote: > Dear all, > > today ended the WGLC period for this draft, so we have addressed all the > comments we have received since -11 version and submitted a new version. > The most relevant changes include an updated and revised version of the > SAML metadata and XML schema (thanks Scott!), as well as the change of > the name of the "SAML-Message" RADIUS attribute to "SAML-Protocol". > > If I haven't missed anything, I think this should be the version to move > to the next step. Thx. I agree. We'll proceed to drop this in the lap of the IESG. This represents a major milestone for abfab and has been a long time coming. Thank you all for your tireless efforts! Cheers Leif & Klaas From nobody Mon Oct 19 13:11:41 2015 Return-Path: X-Original-To: abfab@ietf.org Delivered-To: abfab@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 23AD31A90D4; Mon, 19 Oct 2015 13:11:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.6.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151019201124.12966.66828.idtracker@ietfa.amsl.com> Date: Mon, 19 Oct 2015 13:11:24 -0700 Archived-At: Cc: abfab@ietf.org Subject: [abfab] I-D Action: draft-ietf-abfab-usability-ui-considerations-03.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 20:11:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Application Bridging for Federated Access Beyond web Working Group of the IETF. Title : Application Bridging for Federated Access Beyond web (ABFAB) Usability and User Interface Considerations Authors : Dr. Rhys Smith Mark Donnelly Filename : draft-ietf-abfab-usability-ui-considerations-03.txt Pages : 28 Date : 2015-10-19 Abstract: The real world use of ABFAB-based technologies requires that any identity that is to be used for authentication has to be configured on the ABFAB-enabled client device. Achieving this requires software on that device (either built into the operating system or a standalone utility) that will interact with the user, managing their identity information and identity-to-service mappings. All designers of software to fulfil this role will face the same set of challenges. This document aims to document these challenges with the aim of producing well-thought out UIs with some degree of consistency between implementations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-abfab-usability-ui-considerations/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-abfab-usability-ui-considerations-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-abfab-usability-ui-considerations-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 19 14:39:16 2015 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4A9F1B2D07 for ; Mon, 19 Oct 2015 14:39:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PQKsSiXzCtkB for ; Mon, 19 Oct 2015 14:38:58 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [146.101.78.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 020821B2D03 for ; Mon, 19 Oct 2015 14:38:54 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lrp0082.outbound.protection.outlook.com [213.199.154.82]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-13-eKMT0TmBRdCZrMjyIP4nAw-1; Mon, 19 Oct 2015 22:38:50 +0100 Received: from VI1PR07MB1391.eurprd07.prod.outlook.com (10.164.92.157) by VI1PR07MB1391.eurprd07.prod.outlook.com (10.164.92.157) with Microsoft SMTP Server (TLS) id 15.1.300.14; Mon, 19 Oct 2015 21:38:48 +0000 Received: from VI1PR07MB1391.eurprd07.prod.outlook.com ([10.164.92.157]) by VI1PR07MB1391.eurprd07.prod.outlook.com ([10.164.92.157]) with mapi id 15.01.0300.010; Mon, 19 Oct 2015 21:38:48 +0000 From: Stefan Paetow To: Sam Hartman , =?iso-8859-1?Q?Alejandro_P=E9rez_M=E9ndez?= Thread-Topic: [abfab] Review of draft-ietf-abfab-aaa-saml-11 Thread-Index: AdEHswO8BUpjHdymSS6jZh1XsrZH3QARbTQAAAZRl6YAoB2ZAA== Date: Mon, 19 Oct 2015 21:38:48 +0000 Message-ID: References: <9846A6064BD102419D06814DD0D78DE112712074@CIO-TNC-D2MBX02.osuad.osu.edu> <5620C974.30400@um.es> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [109.176.232.150] x-microsoft-exchange-diagnostics: 1; VI1PR07MB1391; 5:Ny7d8d6v8A6ItTWBaACpXUqLfSokieYgg28usWBFhibTD6X2ejLZwbaR28emBZkwga46iL05jFkXPiZMOU3cf3Gp6ojO9pJpg+IMkE0OkULL9zcBNk5vi3CvOonyEIEPz4tTj5hMWfbja9uplLWypg==; 24:YUYxHTawKav0DMyi6LUIPVzw697+Iod2+AHRNtKgVILDbHVjwK1L0MeZ0s8U10gV7A4l8gVP0RSizbzJ0m4/E/17G3WrMTnDSi/uwmG4WPk=; 20:bctFDu6iYV7w03uXbKBIr9ElqFJXqiUfplj/H0mbb+ldQ19njxUAVx1eGJlfw9RMutl8SnjJC9rERJ3b6MMH4WgarIOfCajMp2seWwYw197yO8kzmKaDEr4zsD+akY2bNswjrL1l5jmkVzLnbwC/2HL4bqmXQCr0Pt7qIa4kcl4= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR07MB1391; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(274715658323672)(151762989364857); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(520078)(3002001); SRVR:VI1PR07MB1391; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB1391; x-forefront-prvs: 07349BFAD2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(199003)(189002)(101416001)(19580405001)(19580395003)(87936001)(64706001)(10400500002)(97736004)(11100500001)(66066001)(92566002)(86362001)(5001960100002)(5001770100001)(81156007)(36756003)(74482002)(105586002)(189998001)(76176999)(46102003)(2950100001)(54356999)(2900100001)(50986999)(230783001)(5007970100001)(102836002)(77096005)(5008740100001)(5002640100001)(5004730100002)(40100003)(106356001)(122556002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB1391; H:VI1PR07MB1391.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-ID: <3E8933A7A90BF04F87C4FC73064C4518@eurprd07.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Oct 2015 21:38:48.3745 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB1391 X-MC-Unique: eKMT0TmBRdCZrMjyIP4nAw-1 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "abfab@ietf.org" Subject: Re: [abfab] Review of draft-ietf-abfab-aaa-saml-11 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 21:39:01 -0000 > "In the case of a SAML processing error, the RADIUS > server MAY include a SAML response message with an > appropriate value for the element within > the Access-Accept or Access-Reject packet to notify the client. > Alternatively, the RADIUS server can respond without a SAML-Message >attribute.". > >Or did we end up calling it SAML-Protocol? Which? The RADIUS attribute? SAML-AAA-Assertion. I don't see any other SAML-named attributes anywhere in a FR dictionary. Stefan Paetow Moonshot Industry & Research Liaison Coordinator t: +44 (0)1235 822 125 gpg: 0x3FCE5142 xmpp: stefanp@jabber.dev.ja.net skype: stefan.paetow.janet jisc.ac.uk Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc=B9s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800. Jisc Collections and Janet Ltd. is a wholly owned Jisc subsidiary and a company limited by guarantee which is registered in England under Company No. number 2881024, VAT No. GB 197 0632 86. The registered office is: Lumen House, Library Avenue, Harwell, Didcot, Oxfordshire, OX11 0SG. T 01235 822200. From nobody Tue Oct 20 00:27:50 2015 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBCA01ACE7F for ; Tue, 20 Oct 2015 00:27:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.911 X-Spam-Level: X-Spam-Status: No, score=-3.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z3R6E3MkNKfM for ; Tue, 20 Oct 2015 00:27:45 -0700 (PDT) Received: from xenon21.um.es (xenon21.um.es [155.54.212.161]) by ietfa.amsl.com (Postfix) with ESMTP id F06BD1ACE0F for ; Tue, 20 Oct 2015 00:27:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon21.um.es (Postfix) with ESMTP id 92F53402AB; Tue, 20 Oct 2015 09:27:42 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon21.um.es Received: from xenon21.um.es ([127.0.0.1]) by localhost (xenon21.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Wp46fS9w2CRJ; Tue, 20 Oct 2015 09:27:42 +0200 (CEST) Received: from [192.168.1.5] (79.109.150.87.dyn.user.ono.com [79.109.150.87]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: alex) by xenon21.um.es (Postfix) with ESMTPSA id 8D73440279; Tue, 20 Oct 2015 09:27:39 +0200 (CEST) To: Stefan Paetow , Sam Hartman References: <9846A6064BD102419D06814DD0D78DE112712074@CIO-TNC-D2MBX02.osuad.osu.edu> <5620C974.30400@um.es> From: =?UTF-8?Q?Alejandro_P=c3=a9rez_M=c3=a9ndez?= Message-ID: <5625ECEB.6060007@um.es> Date: Tue, 20 Oct 2015 09:27:39 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "abfab@ietf.org" Subject: Re: [abfab] Review of draft-ietf-abfab-aaa-saml-11 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2015 07:27:48 -0000 El 19/10/15 a las 23:38, Stefan Paetow escribió: >> "In the case of a SAML processing error, the RADIUS >> server MAY include a SAML response message with an >> appropriate value for the element within >> the Access-Accept or Access-Reject packet to notify the client. >> Alternatively, the RADIUS server can respond without a SAML-Message >> attribute.". >> >> Or did we end up calling it SAML-Protocol? > Which? The RADIUS attribute? SAML-AAA-Assertion. I don't see any other > SAML-named attributes anywhere in a FR dictionary. The "SAML-Message" attribute is now called "SAML-Protocol". The "SAML-Assertion" keeps the name. The attribute in FR is a Vendor-Specific one, assigned to UKERNA, so it can be called whichever they want, since the one in the IETF draft has not been standardized yet. When the RFC is published, that will change to the proper name. Something similar happended with RFC 7055's attributes. They were moved from dictionary.ukerna to dictionary.7055, with proper asignements of attribute numbers. Regards, Alejandro > > Stefan Paetow > Moonshot Industry & Research Liaison Coordinator > > t: +44 (0)1235 822 125 > gpg: 0x3FCE5142 > xmpp: stefanp@jabber.dev.ja.net > skype: stefan.paetow.janet > > jisc.ac.uk > > Jisc is a registered charity (number 1149740) and a company limited by > guarantee which is registered in England under Company No. 5747339, VAT > No. GB 197 0632 86. Jisc¹s registered office is: One Castlepark, Tower > Hill, Bristol, BS2 0JA. T 0203 697 5800. > > Jisc Collections and Janet Ltd. is a wholly owned Jisc subsidiary and a > company limited by guarantee which is registered in England under Company > No. number 2881024, VAT No. GB 197 0632 86. The registered office is: > Lumen House, Library Avenue, Harwell, Didcot, Oxfordshire, OX11 0SG. T > 01235 822200. > > > From nobody Tue Oct 20 00:58:57 2015 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C4431B2BEB for ; Tue, 20 Oct 2015 00:58:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q5VpuMdxLZa4 for ; Tue, 20 Oct 2015 00:58:50 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [146.101.78.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39F841B2BD2 for ; Tue, 20 Oct 2015 00:58:50 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lrp0010.outbound.protection.outlook.com [213.199.154.10]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-21-mdkFQLNUReykbjJc3MY91A-1; Tue, 20 Oct 2015 08:58:46 +0100 X-MC-Unique: mdkFQLNUReykbjJc3MY91A-1 Received: from VI1PR07MB1391.eurprd07.prod.outlook.com (10.164.92.157) by VI1PR07MB1392.eurprd07.prod.outlook.com (10.164.92.158) with Microsoft SMTP Server (TLS) id 15.1.300.14; Tue, 20 Oct 2015 07:58:44 +0000 Received: from VI1PR07MB1391.eurprd07.prod.outlook.com ([10.164.92.157]) by VI1PR07MB1391.eurprd07.prod.outlook.com ([10.164.92.157]) with mapi id 15.01.0300.010; Tue, 20 Oct 2015 07:58:44 +0000 From: Stefan Paetow To: =?Windows-1252?Q?Alejandro_P=E9rez_M=E9ndez?= Thread-Topic: [abfab] Review of draft-ietf-abfab-aaa-saml-11 Thread-Index: AdEHswO8BUpjHdymSS6jZh1XsrZH3QARbTQAAAZRl6YAoB2ZAAAdldCAAAEVwoA= Date: Tue, 20 Oct 2015 07:58:44 +0000 Message-ID: References: <9846A6064BD102419D06814DD0D78DE112712074@CIO-TNC-D2MBX02.osuad.osu.edu> <5620C974.30400@um.es> <5625ECEB.6060007@um.es> In-Reply-To: <5625ECEB.6060007@um.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1878.6) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Stefan.Paetow@jisc.ac.uk; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2001:630:50:d019:5810:1c54:2e60:5122] x-microsoft-exchange-diagnostics: 1; VI1PR07MB1392; 5:IvNTBX4il7DT2x2Z8c0MB/3hOOeyTZnL4tihQuOSd85xShbfEDgGpmKi/62ZRPgWpcdxfwS/J0HHn2HgzZWj5Y9B9aqili8o5Aev61K57DFxUW8OB+gFFQ2xfhpIv/09ZZhDnzyyLJdQ74jRX3rZ0w==; 24:F4yAYauoxTy7mu9D+2+T7e94Gx9RiTbx8HbDfOnqJaQORaGNKrCWIL7H3i+nnsZQCGikk25oKAFHb+YuFRjPHVPfY9LvjxNiuV13jVfhkbw=; 20:ZIxbWCv52DgF6bHYRfU097Z98GkGLnkq1m/oeVQEsVmdSZ4HRURgibCqUo4eQvXXHOG3PMj9AmqA7lv7PoLVkUys0doEjQDXM+l8HMpw82XYwhjmFFhMB8Gea7S2nT27osj88buPZVR2JAFFbYInoof5kMkqePyf2ijvlInlvZw= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR07MB1392; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(274715658323672)(151762989364857); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001); SRVR:VI1PR07MB1392; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB1392; x-forefront-prvs: 073515755F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(189002)(199003)(102836002)(77096005)(93886004)(50986999)(99936001)(105586002)(74482002)(10400500002)(46102003)(86362001)(33656002)(5002640100001)(5001960100002)(110136002)(36756003)(83716003)(92566002)(5007970100001)(189998001)(106356001)(40100003)(230783001)(64706001)(19580395003)(122556002)(11100500001)(19580405001)(76176999)(50226001)(2950100001)(97736004)(82746002)(81156007)(87936001)(101416001)(5008740100001)(57306001)(2900100001)(5004730100002)(3826002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB1392; H:VI1PR07MB1391.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: jisc.ac.uk does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; boundary="Apple-Mail=_31A09BB3-C40D-4396-9972-B7AC4F5E82FD"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Oct 2015 07:58:44.4985 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB1392 Archived-At: Cc: "abfab@ietf.org" Subject: Re: [abfab] Review of draft-ietf-abfab-aaa-saml-11 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2015 07:58:55 -0000 --Apple-Mail=_31A09BB3-C40D-4396-9972-B7AC4F5E82FD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > The "SAML-Message" attribute is now called "SAML-Protocol". The = "SAML-Assertion" keeps the name. >=20 > The attribute in FR is a Vendor-Specific one, assigned to UKERNA, so = it can be called whichever they want, since the one in the IETF draft = has not been standardized yet. > When the RFC is published, that will change to the proper name. = Something similar happended with RFC 7055's attributes. They were moved = from dictionary.ukerna to dictionary.7055, with proper asignements of = attribute numbers. That may be the case, but I checked the UKERNA dictionary and didn't = find it there... In fact that's the first place I looked because I = assumed the above. So it's probably a good idea to submit a pull request to make sure this = is in FR. Stefan Paetow Moonshot Industry & Research Liaison Coordinator t: +44 (0)1235 822 125 gpg: 0x3FCE5142 xmpp: stefanp@jabber.dev.ja.net skype: stefan.paetow.janet Lumen House, Library Avenue, Harwell Oxford, Didcot, OX11 0SG jisc.ac.uk Jisc is a registered charity (number 1149740) and a company limited by = guarantee which is registered in England under Company No. 5747339, VAT = No. GB 197 0632 86. Jisc=92s registered office is: One Castlepark, Tower = Hill, Bristol, BS2 0JA. T 0203 697 5800. Jisc Collections and Janet Ltd. is a wholly owned Jisc subsidiary and a = company limited by guarantee which is registered in England under = Company No. number 2881024, VAT No. GB 197 0632 86. The registered = office is: Lumen House, Library Avenue, Harwell, Didcot, Oxfordshire, = OX11 0SG. T 01235 822200. --Apple-Mail=_31A09BB3-C40D-4396-9972-B7AC4F5E82FD Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJWJfQzAAoJEBlaw7k/zlFCddEH/RLACRvZ2zJnZ83t6iOQFkU0 i1J1F6ie44toA3/e0ES8lGC1C7etO8nUaG/OJjziP6pb7DK3BKpJcuB29+QFJ8g6 op5Ap4pBMaZ9rDQTs+2vZXln6G/IV1TCjz71i69EKKIi0sv/cq0KsgOFDsqATaFw aQyvfVazSwroadW/FBfh6FR4VSqz+jyp2L04HRcK4zD+pHh8di5fJK9OCxuOtF3x 7fLDKrGxFPg9cyp+38EgPrrG4/AdZMb+NN+YjOG/1YFxwbXldU6T+/lzNRltnP+y +WDLyGfgegH0aPoTdUrStigm/5KormjfbNgwNQaSO7ik144mEx3uCM/aSkt/OdQ= =pk9F -----END PGP SIGNATURE----- --Apple-Mail=_31A09BB3-C40D-4396-9972-B7AC4F5E82FD--