From nobody Fri Jan 9 12:49:44 2015 Return-Path: X-Original-To: vot@ietfa.amsl.com Delivered-To: vot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75E7C1A9066 for ; Fri, 9 Jan 2015 12:49:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.254 X-Spam-Level: ** X-Spam-Status: No, score=2.254 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.793, SPF_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 RTFNQjPegVwv for ; Fri, 9 Jan 2015 12:49:42 -0800 (PST) Received: from v2.bluepopcorn.net (unknown [IPv6:2607:f2f8:a994::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A04B1A9061 for ; Fri, 9 Jan 2015 12:49:42 -0800 (PST) Received: from splunge.local (c-50-136-244-117.hsd1.ca.comcast.net [50.136.244.117]) (authenticated bits=0) by v2.bluepopcorn.net (8.14.3/8.14.3/Debian-9.4) with ESMTP id t09KneEr010260 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Fri, 9 Jan 2015 12:49:41 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1420836581; bh=GQzLvFJ4HtimWLdiktkxT0FCPTJhKmK/ozBp/GppuD8=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type: Content-Transfer-Encoding; b=eNDiCLfK4xmHn3n4OXOTLQyYp47oZ8sSToVoaVkXJUZ6Cty1UPB/MV2+O4pVTA5ab jl0J1WMq6/QncuzNnG7Q0HncZlKzPAUMih5KknlbtOafrwDAnlZ2154TJkiOjcjTZC 3Pt2w9IWpmcc3fkm5g2slq8sozIbNDER2eoiDWLw= Message-ID: <54B03EE4.3060909@bluepopcorn.net> Date: Fri, 09 Jan 2015 12:49:40 -0800 From: Jim Fenton User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: vot@ietf.org Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [VoT] A modest proposal to replace LOA X-BeenThere: vot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Vectors of Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 20:49:43 -0000 I posted some ideas yesterday on a somewhat constrained possible replacement for Levels of Assurance: https://altmode.wordpress.com/2015/01/08/level-of-assurance-alternatives-a-modest-proposal/ tl;dr: One dimension (LOA) isn't enough, but we don't want too many dimensions or levels because that gets unwieldy. I'm proposing 3 levels each of two dimensions: Level of Strength (authentication) and Level of Reliability (attribute binding/proofing). Any thoughts would be appreciated. -Jim From nobody Fri Jan 9 13:03:03 2015 Return-Path: X-Original-To: vot@ietfa.amsl.com Delivered-To: vot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8F4A1A90C4 for ; Fri, 9 Jan 2015 13:02:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.951 X-Spam-Level: X-Spam-Status: No, score=0.951 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_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 CT8amZRzXK1l for ; Fri, 9 Jan 2015 13:02:58 -0800 (PST) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C21C1A90C9 for ; Fri, 9 Jan 2015 13:02:58 -0800 (PST) Received: by mail-pa0-f51.google.com with SMTP id ey11so20599213pad.10 for ; Fri, 09 Jan 2015 13:02:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ARBwKV9yhIxS4YiCIxkMcljX90DaivxKuf9OEKHTvXQ=; b=iN6g+45ijU/rg3GuO1kBWdoGQE3OejHZ/1Estv+3KqNm2Ot2uq4J1fuTrcb6ysJ1Cf dXdBp2Y0dXrzBQMAKawXRhQ25dAh7RxALoSF3rxgFL/c3L5Kr2Nsk9rM3DEk7+cGXjfC PjshVwjHQQlT7cxxwDuxqdIsX64zGn7YtG05ZyBfSQwajHkXHskCX8yEcjEfEBaLQxNB o+CUDN9uJ3L3jyXO6m5V1C2P7e7MAk5rBIVyvEHf4WfAGKwU44ADRAIhpJGu9dKs0TzP cu7RArhSysTZKSh3RNQydMDOWjFj4Zo4Wp2ImYM6cijikR+FKPP3URPQ0AoQgCXOEwmc wPOg== MIME-Version: 1.0 X-Received: by 10.70.34.196 with SMTP id b4mr26322285pdj.120.1420837377303; Fri, 09 Jan 2015 13:02:57 -0800 (PST) Received: by 10.70.59.36 with HTTP; Fri, 9 Jan 2015 13:02:57 -0800 (PST) In-Reply-To: <54B03EE4.3060909@bluepopcorn.net> References: <54B03EE4.3060909@bluepopcorn.net> Date: Fri, 9 Jan 2015 13:02:57 -0800 Message-ID: From: Andrew Hughes To: Jim Fenton Content-Type: multipart/alternative; boundary=089e0102e91a286d39050c3e7b85 Archived-At: Cc: vot@ietf.org Subject: Re: [VoT] A modest proposal to replace LOA X-BeenThere: vot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Vectors of Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 21:03:00 -0000 --089e0102e91a286d39050c3e7b85 Content-Type: text/plain; charset=UTF-8 Hey Jim - have you seen the Government of Canada (GC) Standard on Identity and Credential Assurance? http://www.tbs-sct.gc.ca/pol/doc-eng.aspx?id=26776 It is architected with the concept of decoupling Identification assurance and Authentication assurance (among other design factors). The significant material here is that GC didn't just issue a standard on assurance levels, they also developed guidance on how to evaluate and treat risks related to those assurance levels. That's the magic part. IMO The problem with 'Assurance Levels' is that they tend to be discussed separately from the acceptable risk/impact related to receiving those assured levels of assertion. That's why the LOA's appear strange - they are only half (or less) of the story. Also, FWIW, since the OMB M04-04 LOAs are predicated on the US Federal risk management requirements and profile, attempting to apply them to other 'vertical's is problematic. Which is often overlooked. But I know that you know all of this :-) Andrew Hughes *Andrew Hughes *CISM CISSP Independent Consultant *In Turn Information Management Consulting* +1 250.888.9474 1249 Palmer Road, Victoria, BC V8P 2H8 AndrewHughes3000@gmail.com ca.linkedin.com/pub/andrew-hughes/a/58/682/ *Identity Management | IT Governance | Information Security * On Fri, Jan 9, 2015 at 12:49 PM, Jim Fenton wrote: > I posted some ideas yesterday on a somewhat constrained possible > replacement for Levels of Assurance: > > > https://altmode.wordpress.com/2015/01/08/level-of-assurance-alternatives-a-modest-proposal/ > > tl;dr: One dimension (LOA) isn't enough, but we don't want too many > dimensions or levels because that gets unwieldy. I'm proposing 3 levels > each of two dimensions: Level of Strength (authentication) and Level of > Reliability (attribute binding/proofing). > > Any thoughts would be appreciated. > > -Jim > > _______________________________________________ > vot mailing list > vot@ietf.org > https://www.ietf.org/mailman/listinfo/vot > --089e0102e91a286d39050c3e7b85 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hey Jim - have you seen the Government of Canada (GC) Stan= dard on Identity and Credential Assurance?


It is archit= ected with the concept of decoupling Identification assurance and Authentic= ation assurance (among other design factors).

The = significant material here is that GC didn't just issue a standard on as= surance levels, they also developed guidance on how to evaluate and treat r= isks related to those assurance levels. That's the magic part.

IMO The problem with 'Assurance Levels' is that th= ey tend to be discussed separately from the acceptable risk/impact related = to receiving those assured levels of assertion. That's why the LOA'= s appear strange - they are only half (or less) of the story. Also, FWIW, s= ince the OMB M04-04 LOAs are predicated on the US Federal risk management r= equirements and profile, attempting to apply them to other 'vertical= 9;s is problematic. Which is often overlooked. But I know that you know all= of this :-)

Andrew Hughes

Andrew Hughes=C2=A0CISM CISSP= =C2=A0
Independent Consultant
In Turn Information Ma= nagement Consulting

+1 250.888.9474
1249 Palmer Road,
Victoria, BC V8P 2H8
AndrewHughe= s3000@gmail.com=C2=A0
ca.linkedin.com/pub/andrew-hughes/a/58/682/=
Identity Management | IT Governance | Inform= ation Security=C2=A0


On Fri, Jan 9, 2015 at 12:49 PM, Jim Fenton = <fenton@bluepopcorn.net> wrote:
I posted some ideas yesterday on a somewhat constrained possible=
replacement for Levels of Assurance:

https://altmode.wordpress.co= m/2015/01/08/level-of-assurance-alternatives-a-modest-proposal/

tl;dr: One dimension (LOA) isn't enough, but we don't want too many=
dimensions or levels because that gets unwieldy. I'm proposing 3 levels=
each of two dimensions: Level of Strength (authentication) and Level of
Reliability (attribute binding/proofing).

Any thoughts would be appreciated.

-Jim

_______________________________________________
vot mailing list
vot@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/vot

--089e0102e91a286d39050c3e7b85-- From nobody Fri Jan 9 14:20:01 2015 Return-Path: X-Original-To: vot@ietfa.amsl.com Delivered-To: vot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62EE71A1A6F for ; Fri, 9 Jan 2015 14:19:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.801 X-Spam-Level: X-Spam-Status: No, score=0.801 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 KNhOIbBg0odx for ; Fri, 9 Jan 2015 14:19:55 -0800 (PST) Received: from smtp69.iad3a.emailsrvr.com (smtp69.iad3a.emailsrvr.com [173.203.187.69]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09ACB1A1AA8 for ; Fri, 9 Jan 2015 14:19:54 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp17.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 1ABC8180348 for ; Fri, 9 Jan 2015 17:19:54 -0500 (EST) X-Virus-Scanned: OK Received: from app58.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp17.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id F3336180251 for ; Fri, 9 Jan 2015 17:19:53 -0500 (EST) X-Sender-Id: swilson@lockstep.com.au Received: from app58.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.4.2); Fri, 09 Jan 2015 22:19:54 GMT Received: from lockstep.com.au (localhost.localdomain [127.0.0.1]) by app58.wa-webapps.iad3a (Postfix) with ESMTP id 02DE0380061 for ; Fri, 9 Jan 2015 17:19:56 -0500 (EST) Received: by apps.rackspace.com (Authenticated sender: swilson@lockstep.com.au, from: swilson@lockstep.com.au) with HTTP; Sat, 10 Jan 2015 09:19:56 +1100 (EST) Date: Sat, 10 Jan 2015 09:19:56 +1100 (EST) From: swilson@lockstep.com.au To: vot@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_20150110091956000000_30494" Importance: Normal X-Priority: 3 (Normal) X-Type: html In-Reply-To: <54B03EE4.3060909@bluepopcorn.net> References: <54B03EE4.3060909@bluepopcorn.net> X-Auth-ID: swilson@lockstep.com.au Message-ID: <1420841996.009725149@apps.rackspace.com> X-Mailer: webmail/11.3.8-RC Archived-At: Subject: Re: [VoT] A modest proposal to replace LOA X-BeenThere: vot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Vectors of Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 22:19:59 -0000 ------=_20150110091956000000_30494 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0A =0AIf we're going to improve upon LOAs, then may I suggest the first th= ing to do is set out the objectives? =0A =0A- What is something like LOA re= ally for? =0A- Who uses a simplified "Risk Gauge", and how exactly? =0A- Ho= w much original risk analysis is an RP expected to do before they bin their= situation into Risk Gauge=0A- Is using a Risk Gauge supposed to save time = in risk analysis?=0A- When an IdP claims a certain Risk Gauge, what does th= at really mean - contractually?=0A- If an RP at Gauge X finds an IdP at Gau= ge X (or higher), what's next? How much further analysis is needed before t= he RP can sign up the IdP? =0A- If an IdP claims Risk Gauge X, how is that = assured?=0A =0AI suggest that LOAs were intended, net-net, to save time. I= t was thought that by binning risk, RPs would be able to short list and the= n contract with suitable IdPs more quickly. If there is any time saved in = using LOAs then I suspect it gets gobbled up by the negotiating the fine pr= int when signing up an IdP. The very fact that RPs have asked for "LOA 2 a= nd a half" tells us that the RP-IdP negotiation tends to be customised. Th= an it, LOAs are difficult to standardise. =0A =0ABefore we add dimensions, = can we look at what its trying to achieve?=0A =0ACheers, =0A =0ASteve.=0A = =0A=0AStephen Wilson=0ALockstep Group =0Ahttp://lockstep.com.au=0ALockstep = Consulting provides independent specialist advice and analysis =0Aon digita= l identity and privacy. Lockstep Technologies develops unique =0Anew smart= ID solutions that enhance privacy and prevent identity theft.=0A =0A =0A = =0A-----Original Message-----=0AFrom: "Jim Fenton" = =0ASent: Saturday, 10 January, 2015 7:49am=0ATo: vot@ietf.org=0ASubject: [V= oT] A modest proposal to replace LOA=0A=0A=0A=0AI posted some ideas yesterd= ay on a somewhat constrained possible=0Areplacement for Levels of Assurance= :=0A=0Ahttps://altmode.wordpress.com/2015/01/08/level-of-assurance-alternat= ives-a-modest-proposal/=0A=0Atl;dr: One dimension (LOA) isn't enough, but w= e don't want too many=0Adimensions or levels because that gets unwieldy. I'= m proposing 3 levels=0Aeach of two dimensions: Level of Strength (authentic= ation) and Level of=0AReliability (attribute binding/proofing).=0A=0AAny th= oughts would be appreciated.=0A=0A-Jim=0A=0A_______________________________= ________________=0Avot mailing list=0Avot@ietf.org=0Ahttps://www.ietf.org/m= ailman/listinfo/vot ------=_20150110091956000000_30494 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

 

=0A

If we're going to improve upon LOAs, then may I suggest the first th= ing to do is set out the objectives? 

=0A

 =0A

- What is something like LOA really for? 

= =0A

- Who uses a simplified "Risk Gauge", and how exactly?=  

=0A

- How much original risk analysis is an RP e= xpected to do before they bin their situation into Risk Gauge

=0A

- Is using a Risk Gauge supposed to save time in risk analysis?<= /p>=0A

- When an IdP claims a certain Risk Gauge, what doe= s that really mean - contractually?

=0A

- If an RP at G= auge X finds an IdP at Gauge X (or higher), what's next? How much further a= nalysis is needed before the RP can sign up the IdP? 

=0A

- If an IdP claims Risk Gauge X, how is that assured?

=0A

 

=0A

I suggest that LOAs were intend= ed, net-net, to save time.  It was thought that by binning risk, RPs w= ould be able to short list and then contract with suitable IdPs more quickl= y.  If there is any time saved in using LOAs then I suspect it ge= ts gobbled up by the negotiating the fine print when signing up an IdP= .  The very fact that RPs have asked for "LOA 2 and a half" tells us t= hat the RP-IdP negotiation tends to be customised.  Than it, LOAs are = difficult to standardise. 

=0A

 

=0A

Before we add dimensions, can we look at what its trying to ach= ieve?

=0A

 

=0A

Cheers, <= /p>=0A

 

=0A

Steve.

=0A

 

=0A


Stephen Wilson
Lockste= p Group 
http://lockstep.com.au

=0A

Lockstep = Consulting provides independent specialist advice and analysis
on dig= ital identity and privacy.  Lockstep Technologies develops unique
new smart ID solutions that enhance privacy and prevent identity theft.=0A

 

=0A

 

=0A

 

=0A

-----Original Message-----
From: "Jim Fenton" <fenton= @bluepopcorn.net>
Sent: Saturday, 10 January, 2015 7:49am
To: = vot@ietf.org
Subject: [VoT] A modest proposal to replace LOA

=0A
=0A

I posted som= e ideas yesterday on a somewhat constrained possible
replacement for L= evels of Assurance:

https://altmode.wordpress.com/2015/01/08/lev= el-of-assurance-alternatives-a-modest-proposal/

tl;dr: One dimen= sion (LOA) isn't enough, but we don't want too many
dimensions or leve= ls because that gets unwieldy. I'm proposing 3 levels
each of two dime= nsions: Level of Strength (authentication) and Level of
Reliability (a= ttribute binding/proofing).

Any thoughts would be appreciated.
-Jim

_______________________________________________vot mailing list
vot@ietf.org
https://www.ietf.org/mailman/li= stinfo/vot

=0A
 ------=_20150110091956000000_30494-- From nobody Fri Jan 9 14:26:53 2015 Return-Path: X-Original-To: vot@ietfa.amsl.com Delivered-To: vot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CA2A1A1A75 for ; Fri, 9 Jan 2015 14:26:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 O_-sQDtqJAEd for ; Fri, 9 Jan 2015 14:26:49 -0800 (PST) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23D9E1A0193 for ; Fri, 9 Jan 2015 14:26:49 -0800 (PST) Received: from splunge.local ([12.250.97.26]) (authenticated bits=0) by v2.bluepopcorn.net (8.14.3/8.14.3/Debian-9.4) with ESMTP id t09MQis3011110 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 9 Jan 2015 14:26:45 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1420842406; bh=BKojj7wxCRqzFXTZat4DJUF0T/Vm5RfjQ9SoMaJou8w=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=B33OfdByRq7zxNZHa1efkxmQM0Mc+cOeFvY9EU6i+DiJ7yV5u6bMBFGpCeSM8RHC7 AqzX9oJn9ZeF4947U2+qKfqJFNJrg69O5OiAHxEf1+9Mao848H9ptbYSDJR/hq++GT 1TmnnuD3Y35S9nmvb1X9uikrAaTKau4R7OQFporE= Message-ID: <54B0559F.20704@bluepopcorn.net> Date: Fri, 09 Jan 2015 14:26:39 -0800 From: Jim Fenton User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Andrew Hughes References: <54B03EE4.3060909@bluepopcorn.net> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: vot@ietf.org Subject: Re: [VoT] A modest proposal to replace LOA X-BeenThere: vot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Vectors of Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 22:26:51 -0000 On 1/9/15 1:02 PM, Andrew Hughes wrote: > Hey Jim - have you seen the Government of Canada (GC) Standard on > Identity and Credential Assurance? > > http://www.tbs-sct.gc.ca/pol/doc-eng.aspx?id=3D26776 > > It is architected with the concept of decoupling Identification > assurance and Authentication assurance (among other design factors). Thanks; I hadn't seen this particular standard. It looks like it slices things up a little differently and uses a little different terminology, such as the emphasis on "maintaining control over a credential". And it uses 4 levels rather than 3. I came up with 3 by looking at the authentication and attribute aspects of the current 4-level LOA separately, and finding really only 3 meaningful levels of each. LOA 1 and 2 aren't all that different in authentication (both single-factor), and LOA 2 and 3 aren't all that different in identity proofing requirements (small differences in remote identity proofing requirements). But if 4 levels are useful, and we can establish meaningful distinctions between each of the levels, that can be done. > > The significant material here is that GC didn't just issue a standard > on assurance levels, they also developed guidance on how to evaluate > and treat risks related to those assurance levels. That's the magic par= t. > > IMO The problem with 'Assurance Levels' is that they tend to be > discussed separately from the acceptable risk/impact related to > receiving those assured levels of assertion. That's why the LOA's > appear strange - they are only half (or less) of the story. Also, > FWIW, since the OMB M04-04 LOAs are predicated on the US Federal risk > management requirements and profile, attempting to apply them to other > 'vertical's is problematic. Which is often overlooked. But I know that > you know all of this :-) In many ways, the LOA framework is a victim of its own success, because it was just designed for US Federal requirements. The part of the risk structure that I don't see in this Canadian standard is some more detail about what constitutes, for example, "moderate to serious harm." M-04-04 breaks that down more specifically by category and defines risks by category, e.g. by treating personal safety risks as more sensitive than financial losses. Is there a companion document somewhere that has the corresponding definitions for the Canadian risk levels? -Jim From nobody Fri Jan 9 14:27:02 2015 Return-Path: X-Original-To: vot@ietfa.amsl.com Delivered-To: vot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31D541A1AAE for ; Fri, 9 Jan 2015 14:26:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_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 dnGm-EYgPt8n for ; Fri, 9 Jan 2015 14:26:52 -0800 (PST) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EA991A0193 for ; Fri, 9 Jan 2015 14:26:52 -0800 (PST) Received: by mail-wi0-f169.google.com with SMTP id r20so4876521wiv.0 for ; Fri, 09 Jan 2015 14:26:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=bUsRTyqW6v2iVb94/Kt5boXI9GrgekDcQw2pPDcsxYc=; b=Ya3hEq6HMGPsM7FqJi0YhLU4Ap+ig1ILzNGugffn6wXBZgOETIohTx0a+K/UMQYwYF DDwMwnqskHsXMI2A3lHHCJ5QwHXRaWjt7qb44LKL+GcirWp/+gHUcrii3YPgKYbgvip4 TpHNFa2QHstPXT0e1U/Cn527SKOi3bhGTb6kRH3aZbrd9pq2oozdB1GY5O7MB7PFBNS1 scWvYuHACi5ykmOmpyk0a94sNW/A4h5mfX6xgJZGlEsHOqB6l/IUuwSPnlKrzeyt7qHg YrEpmJHEnZ2Z8HOitV8Ojap0ILyX4yaezwFAoZVv5eMzyKPQ4bPvPIUwrU3AaYO5vQnS eqtA== X-Received: by 10.180.91.36 with SMTP id cb4mr8995167wib.30.1420842411105; Fri, 09 Jan 2015 14:26:51 -0800 (PST) MIME-Version: 1.0 Sender: jonibrennan@gmail.com Received: by 10.216.110.201 with HTTP; Fri, 9 Jan 2015 14:26:20 -0800 (PST) In-Reply-To: <1420841996.009725149@apps.rackspace.com> References: <54B03EE4.3060909@bluepopcorn.net> <1420841996.009725149@apps.rackspace.com> From: Joni Brennan Date: Fri, 9 Jan 2015 14:26:20 -0800 X-Google-Sender-Auth: 3ZtxO5KBw4-XDvMemabiIIZMULo Message-ID: To: Stephen Wilson Content-Type: multipart/alternative; boundary=f46d043d6711322487050c3fa7e7 Archived-At: Cc: "vot@ietf.org" Subject: Re: [VoT] A modest proposal to replace LOA X-BeenThere: vot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Vectors of Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 22:26:55 -0000 --f46d043d6711322487050c3fa7e7 Content-Type: text/plain; charset=ISO-8859-1 +1 to the suggestions so far and the comments around defining objectives. Apologies if this comment has already been made. It may also be of use to pop up in the stack as well regarding objectives. One layer abstraction removed from Steve's well pointed examples... I don't believe we need specific architecture for each but rather simply to be aware of the varying communities / priorities. LoAs (or something like VoTs) - Security - Risk Management - Interoperability (policy and tech) - Commercial (regulated / non) - Government (public service - and what is a public services varies nationally) Best Regards, Joni Brennan Kantara Initiative | Executive Director email: joni @ kantarainitiative.org Connecting Identity for a more trustworthy Internet - Overview On Fri, Jan 9, 2015 at 2:19 PM, wrote: > > > If we're going to improve upon LOAs, then may I suggest the first thing to > do is set out the objectives? > > > > - What is something like LOA really for? > > - Who uses a simplified "Risk Gauge", and how exactly? > > - How much original risk analysis is an RP expected to do before they bin > their situation into Risk Gauge > > - Is using a Risk Gauge supposed to save time in risk analysis? > > - When an IdP claims a certain Risk Gauge, what does that really mean - > contractually? > > - If an RP at Gauge X finds an IdP at Gauge X (or higher), what's next? > How much further analysis is needed before the RP can sign up the IdP? > > - If an IdP claims Risk Gauge X, how is that assured? > > > > I suggest that LOAs were intended, net-net, to save time. It was thought > that by binning risk, RPs would be able to short list and then contract > with suitable IdPs more quickly. If there is any time saved in using > LOAs then I suspect it gets gobbled up by the negotiating the fine print > when signing up an IdP. The very fact that RPs have asked for "LOA 2 and a > half" tells us that the RP-IdP negotiation tends to be customised. Than > it, LOAs are difficult to standardise. > > > > Before we add dimensions, can we look at what its trying to achieve? > > > > Cheers, > > > > Steve. > > > > > Stephen Wilson > Lockstep Group > http://lockstep.com.au > > Lockstep Consulting provides independent specialist advice and analysis > on digital identity and privacy. Lockstep Technologies develops unique > new smart ID solutions that enhance privacy and prevent identity theft. > > > > > > > > -----Original Message----- > From: "Jim Fenton" > Sent: Saturday, 10 January, 2015 7:49am > To: vot@ietf.org > Subject: [VoT] A modest proposal to replace LOA > > I posted some ideas yesterday on a somewhat constrained possible > replacement for Levels of Assurance: > > > https://altmode.wordpress.com/2015/01/08/level-of-assurance-alternatives-a-modest-proposal/ > > tl;dr: One dimension (LOA) isn't enough, but we don't want too many > dimensions or levels because that gets unwieldy. I'm proposing 3 levels > each of two dimensions: Level of Strength (authentication) and Level of > Reliability (attribute binding/proofing). > > Any thoughts would be appreciated. > > -Jim > > _______________________________________________ > vot mailing list > vot@ietf.org > https://www.ietf.org/mailman/listinfo/vot > > _______________________________________________ > vot mailing list > vot@ietf.org > https://www.ietf.org/mailman/listinfo/vot > > --f46d043d6711322487050c3fa7e7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
+1 to the suggestions so far and the comments around defin= ing objectives. =A0

Apologies if this comment has alread= y been made.=A0 It may also be of use to pop up in the stack as well regard= ing objectives.=A0 One layer abstraction removed from Steve's well poin= ted examples... I don't believe we need specific architecture for each = but rather simply to be aware of the varying communities / priorities.=A0=A0=A0
LoAs (or something like VoTs)=A0
- Secur= ity
- Risk Management
- Interoperability (policy and te= ch)=A0
- Commercial (regulated / non)
- Government (pub= lic service - and what is a public services varies nationally)
<= /div>

Best Rega= rds,

Joni Brennan
Kantara Initiative | Execut= ive Director
email: joni @ kantarainitiative.org

Connecting Identity fo= r a more trustworthy Internet - Overview



On Fri, Jan 9, 2015 at 2:19 PM, <s= wilson@lockstep.com.au> wrote:

=A0

If we're going to improve upon LOAs, then may I suggest the= first thing to do is set out the objectives?=A0

=A0

- What is something like LOA really for?=A0

- Who uses a simplified "Risk Gauge", and how exactly= ?=A0

- How much original risk analysis is an RP expected to do befor= e they bin their situation into Risk Gauge

- Is using a Risk Gauge supposed to save time in risk analysis?=

- When an IdP claims a certain Risk Gauge, what does that reall= y mean - contractually?

- If an RP at Gauge X finds an IdP at Gauge X (or higher), what= 's next? How much further analysis is needed before the RP can sign up = the IdP?=A0

- If an IdP claims Risk Gauge X, how is that assured?

=A0

I suggest that LOAs were intended, net-net, to save time.=A0 It= was thought that by binning risk, RPs would be able to short list and then= contract with suitable IdPs more quickly.=A0 If there is any time saved in= using LOAs=A0then I suspect it gets=A0gobbled up by the negotiating the fi= ne print when signing up an IdP.=A0 The very fact that RPs have asked for &= quot;LOA 2 and a half" tells us that the RP-IdP negotiation tends to b= e customised.=A0 Than it, LOAs are difficult to standardise.=A0

=A0

Before we add dimensions, can we look at what its trying to ach= ieve?

=A0

Cheers,=A0

=A0

Steve.

=A0


Stephen Wilson
Lockstep Group=A0
http://lockstep.com.au

Lockstep Consulting provides independent specialist advice and = analysis
on digital identity and privacy.=A0 Lockstep Technologies deve= lops unique
new smart ID solutions that enhance privacy and prevent ide= ntity theft.

=A0

=A0

=A0

-----Original Message-----
From: "Jim Fenton" <= fenton@bluepopc= orn.net>
Sent: Saturday, 10 January, 2015 7:49am
To: vot@ietf.org
Subject: [Vo= T] A modest proposal to replace LOA

I posted some ideas yesterday on a somewhat constrained possibl= e
replacement for Levels of Assurance:

https://altmode.wordpress.com/2015/01/08/level-of-assu= rance-alternatives-a-modest-proposal/

tl;dr: One dimension (LOA)= isn't enough, but we don't want too many
dimensions or levels b= ecause that gets unwieldy. I'm proposing 3 levels
each of two dimens= ions: Level of Strength (authentication) and Level of
Reliability (attri= bute binding/proofing).

Any thoughts would be appreciated.

-J= im

_______________________________________________
vot mailing li= st
vot@ietf.orght= tps://www.ietf.org/mailman/listinfo/vot


______________________________________________= _
vot mailing list
vot@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/vot


--f46d043d6711322487050c3fa7e7-- From nobody Fri Jan 9 15:00:02 2015 Return-Path: X-Original-To: vot@ietfa.amsl.com Delivered-To: vot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 698461A1A9B for ; Fri, 9 Jan 2015 15:00:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 zRcQgOvxLncW for ; Fri, 9 Jan 2015 14:59:58 -0800 (PST) Received: from smtpvbsrv1.mitre.org (smtpvbsrv1.mitre.org [198.49.146.234]) by ietfa.amsl.com (Postfix) with ESMTP id 3D83A1A1A75 for ; Fri, 9 Jan 2015 14:59:57 -0800 (PST) Received: from smtpvbsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 727BC3320A5; Fri, 9 Jan 2015 17:59:57 -0500 (EST) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpvbsrv1.mitre.org (Postfix) with ESMTP id 6611272E52E; Fri, 9 Jan 2015 17:59:57 -0500 (EST) Received: from IMCMBX01.MITRE.ORG ([169.254.1.185]) by IMCCAS03.MITRE.ORG ([129.83.29.80]) with mapi id 14.03.0224.002; Fri, 9 Jan 2015 17:59:57 -0500 From: "Richer, Justin P." To: Joni Brennan Thread-Topic: [VoT] A modest proposal to replace LOA Thread-Index: AQHQLE3MWZ9Fs5TMOky75/Y8HntyWZy4sAEAgAABygCAAAligA== Date: Fri, 9 Jan 2015 22:59:56 +0000 Message-ID: <945D72BA-415D-42C8-BEC2-E9B74531D004@mitre.org> References: <54B03EE4.3060909@bluepopcorn.net> <1420841996.009725149@apps.rackspace.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.55.131] Content-Type: multipart/alternative; boundary="_000_945D72BA415D42C8BEC2E9B74531D004mitreorg_" MIME-Version: 1.0 Archived-At: Cc: "vot@ietf.org" , Stephen Wilson Subject: Re: [VoT] A modest proposal to replace LOA X-BeenThere: vot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Vectors of Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 23:00:01 -0000 --_000_945D72BA415D42C8BEC2E9B74531D004mitreorg_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To me, a lot of it comes down to helping the RPs answer one question: "Someone just logged in. Now what?" I think that binning risk is part of the issue (as Steve states), but it's = also (as a corollary) a matter of setting the context of an authentication.= It's not just about "do I trust the display name" or whatever other attrib= ute, but also about communicating to the RP what just happened. This can gi= ve the RP a chance at correctly deciding what to do about it. There are really two parts of the whole conversation that I think getting w= ound up in each other: - Things the RP needs to know about the IdP (i.e.: do I trust this IdP? wh= at risk do I have in doing so?) - Things the RP needs to know about the authentication transaction (i.e.: = do I trust this log in?) The VoT proposal tries to address this with the two different parts of the = protocol: the vector as conveyed by the protocol, and the "trust mark provi= der" discovery portion. To me, everything else is an aspect of answering these fundamental question= s. -- Justin On Jan 9, 2015, at 5:26 PM, Joni Brennan > wrote: +1 to the suggestions so far and the comments around defining objectives. Apologies if this comment has already been made. It may also be of use to = pop up in the stack as well regarding objectives. One layer abstraction re= moved from Steve's well pointed examples... I don't believe we need specifi= c architecture for each but rather simply to be aware of the varying commun= ities / priorities. LoAs (or something like VoTs) - Security - Risk Management - Interoperability (policy and tech) - Commercial (regulated / non) - Government (public service - and what is a public services varies nationa= lly) Best Regards, Joni Brennan Kantara Initiative | Executive Director email: joni @ kantarainitiative.org Connecting Identity for a more trustworthy Internet - Overview On Fri, Jan 9, 2015 at 2:19 PM, > wrote: If we're going to improve upon LOAs, then may I suggest the first thing to = do is set out the objectives? - What is something like LOA really for? - Who uses a simplified "Risk Gauge", and how exactly? - How much original risk analysis is an RP expected to do before they bin t= heir situation into Risk Gauge - Is using a Risk Gauge supposed to save time in risk analysis? - When an IdP claims a certain Risk Gauge, what does that really mean - con= tractually? - If an RP at Gauge X finds an IdP at Gauge X (or higher), what's next? How= much further analysis is needed before the RP can sign up the IdP? - If an IdP claims Risk Gauge X, how is that assured? I suggest that LOAs were intended, net-net, to save time. It was thought t= hat by binning risk, RPs would be able to short list and then contract with= suitable IdPs more quickly. If there is any time saved in using LOAs then= I suspect it gets gobbled up by the negotiating the fine print when signin= g up an IdP. The very fact that RPs have asked for "LOA 2 and a half" tell= s us that the RP-IdP negotiation tends to be customised. Than it, LOAs are= difficult to standardise. Before we add dimensions, can we look at what its trying to achieve? Cheers, Steve. Stephen Wilson Lockstep Group http://lockstep.com.au Lockstep Consulting provides independent specialist advice and analysis on digital identity and privacy. Lockstep Technologies develops unique new smart ID solutions that enhance privacy and prevent identity theft. -----Original Message----- From: "Jim Fenton" > Sent: Saturday, 10 January, 2015 7:49am To: vot@ietf.org Subject: [VoT] A modest proposal to replace LOA I posted some ideas yesterday on a somewhat constrained possible replacement for Levels of Assurance: https://altmode.wordpress.com/2015/01/08/level-of-assurance-alternatives-a-= modest-proposal/ tl;dr: One dimension (LOA) isn't enough, but we don't want too many dimensions or levels because that gets unwieldy. I'm proposing 3 levels each of two dimensions: Level of Strength (authentication) and Level of Reliability (attribute binding/proofing). Any thoughts would be appreciated. -Jim _______________________________________________ vot mailing list vot@ietf.org https://www.ietf.org/mailman/listinfo/vot _______________________________________________ vot mailing list vot@ietf.org https://www.ietf.org/mailman/listinfo/vot _______________________________________________ vot mailing list vot@ietf.org https://www.ietf.org/mailman/listinfo/vot --_000_945D72BA415D42C8BEC2E9B74531D004mitreorg_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable To me, a lot of it comes down to helping the RPs answer one question:

"Someone just logged in. Now what?"

I think that binning risk is part of the issue (as Steve states), but = it's also (as a corollary) a matter of setting the context of an authentica= tion. It's not just about "do I trust the display name" or whatev= er other attribute, but also about communicating to the RP what just happened. This can give the RP a chance at correctly d= eciding what to do about it.

There are really two parts of the whole conversation that I think gett= ing wound up in each other:
 - Things the RP needs to know about the IdP (i.e.: do I trust th= is IdP? what risk do I have in doing so?)
 - Things the RP needs to know about the authentication transacti= on (i.e.: do I trust this log in?)

The VoT proposal tries to address this with the two different parts of= the protocol: the vector as conveyed by the protocol, and the "trust = mark provider" discovery portion.

To me, everything else is an aspect of answering these fundamental que= stions.

 -- Justin

On Jan 9, 2015, at 5:26 PM, Joni Brennan <joni@kantarainitiative.org> wrote:

+1 to the suggestions so far and the comments around d= efining objectives.  

Apologies if this comment has already been made.  It may also be = of use to pop up in the stack as well regarding objectives.  One layer= abstraction removed from Steve's well pointed examples... I don't believe = we need specific architecture for each but rather simply to be aware of the varying communities / priorities. 
  
LoAs (or something like VoTs) 
- Security
- Risk Management
- Interoperability (policy and tech) 
- Commercial (regulated / non)
- Government (public service - and what is a public services varies na= tionally)

Best Regards,

Joni Brennan
Kantara Initiative | Executive Director
email: joni @ k= antarainitiative.org

Connecting Identity for a more trustworthy Internet - Overview




On Fri, Jan 9, 2015 at 2:19 PM, <swilson@= lockstep.com.au> wrote:

 

If we're going to improve upon LOAs, then may I suggest the first thing to = do is set out the objectives? 

 

- What is something like LOA really for? 
- Who uses a simplified "Risk Gauge", and how exactly? 
- How much original risk analysis is an RP expected to do before they bin t= heir situation into Risk Gauge
- Is using a Risk Gauge supposed to save time in risk analysis?
- When an IdP claims a certain Risk Gauge, what does that really mean - con= tractually?
- If an RP at Gauge X finds an IdP at Gauge X (or higher), what's next? How= much further analysis is needed before the RP can sign up the IdP? 
- If an IdP claims Risk Gauge X, how is that assured?

 

I suggest that LOAs were intended, net-net, to save time.  It was thou= ght that by binning risk, RPs would be able to short list and then contract= with suitable IdPs more quickly.  If there is any time saved in using= LOAs then I suspect it gets gobbled up by the negotiating the fine print when signing up an IdP.  The very fact= that RPs have asked for "LOA 2 and a half" tells us that the RP-= IdP negotiation tends to be customised.  Than it, LOAs are difficult t= o standardise. 

 

Before we add dimensions, can we look at what its trying to achieve?

 

Cheers, 

 

Steve.

 


Stephen Wilson
Lockstep Group 
http://lockstep.com.a= u
Lockstep Consulting provides independent specialist advice and analysis on digital identity and privacy.  Lockstep Technologies develops uniqu= e
new smart ID solutions that enhance privacy and prevent identity theft.
 

 

 

-----Original Message-----
From: "Jim Fenton" <fenton@bluepopcorn.net>
Sent: Saturday, 10 January, 2015 7:49am
To: vot@ietf.org
Subject: [VoT] A modest proposal to replace LOA

I posted some ideas yesterday on a somewhat constrained possible
replacement for Levels of Assurance:

https://altmode.wordpress.co= m/2015/01/08/level-of-assurance-alternatives-a-modest-proposal/

tl;dr: One dimension (LOA) isn't enough, but we don't want too many
dimensions or levels because that gets unwieldy. I'm proposing 3 levels
each of two dimensions: Level of Strength (authentication) and Level of
Reliability (attribute binding/proofing).

Any thoughts would be appreciated.

-Jim

_______________________________________________
vot mailing list
vot@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/vot

_______________________________________________
vot mailing list
vot@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/vot


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

--_000_945D72BA415D42C8BEC2E9B74531D004mitreorg_-- From nobody Fri Jan 9 17:38:12 2015 Return-Path: X-Original-To: vot@ietfa.amsl.com Delivered-To: vot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 406BF1A01A8 for ; Fri, 9 Jan 2015 17:38:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 bUkzpOLcYf5r for ; Fri, 9 Jan 2015 17:38:02 -0800 (PST) Received: from mail-yh0-x230.google.com (mail-yh0-x230.google.com [IPv6:2607:f8b0:4002:c01::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 880811A0A85 for ; Fri, 9 Jan 2015 17:38:02 -0800 (PST) Received: by mail-yh0-f48.google.com with SMTP id i57so5653509yha.7 for ; Fri, 09 Jan 2015 17:38:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4Y4r8AjgiLAl7siwkmHa3jqNCrjO+LNy7p5G+356qqo=; b=JKC/qclP5RCgq4N0ZQQDaRBKmx+vOj6leQURlnCvxAQwmXFTy23gu1GgK4/hX7zprN I2gFu0pL0S7DHR0OYWQk7PBYDtkYnqQFf/tLwaxn3/8MmVaxEC2aB7BLQJ3vWBx0EmCo 29jdtQ3nuUPfDv4ZUkc/42oZsLPP+lhUc8jW4AA9FSrc9GuRz/KTm0uxy/683DBap8q7 rabShZh9K8PqAq4CQEvSgVu1+2qhMkZttVMDtj+YWhy0LBneIV8cukXRjqMb7MYiVR42 CoZdf3drqb9mhEpZDiHL/rUTbnmUH6aUw5qFxFe08XTKM3e3eVKkYFxGHZ/tViOjg6rk qjmw== MIME-Version: 1.0 X-Received: by 10.236.36.35 with SMTP id v23mr13444507yha.193.1420853881655; Fri, 09 Jan 2015 17:38:01 -0800 (PST) Received: by 10.170.95.130 with HTTP; Fri, 9 Jan 2015 17:38:01 -0800 (PST) In-Reply-To: <945D72BA-415D-42C8-BEC2-E9B74531D004@mitre.org> References: <54B03EE4.3060909@bluepopcorn.net> <1420841996.009725149@apps.rackspace.com> <945D72BA-415D-42C8-BEC2-E9B74531D004@mitre.org> Date: Fri, 9 Jan 2015 20:38:01 -0500 Message-ID: From: Ken Dagg To: "Richer, Justin P." Content-Type: multipart/alternative; boundary=089e0158c43ae4d970050c42525f Archived-At: Cc: Joni Brennan , "vot@ietf.org" , Stephen Wilson Subject: Re: [VoT] A modest proposal to replace LOA X-BeenThere: vot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Vectors of Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jan 2015 01:38:07 -0000 --089e0158c43ae4d970050c42525f Content-Type: text/plain; charset=UTF-8 Justin, IMO you have hit the nail on the head with those questions. At the end of the day, it is the RP's decision because, IMO, it is ultimately the RP that bears the consequences of something going wrong. The interesting direction taken in the GC approach is the RP decides, based upon the GC standard and its supporting guidance, on their risk tolerance and categorizes it into a LOA bucket. The standard and guidance then identifies, based on that categorization, what the RP needs to do to mitigate that risk. Part of that mitigation could include accepting assertions from external organizations, such as authoritative parties, who provide assertions about something. It does not presume that any authoritative party will provide the "total" assertion. An important part of the standard is that it does not specify specific authoritative sources. Rather, it identifies what types of sources and how many of those sources should be used. In this context, the answers to Steve's questions are, IMO, rather simple: - What is something like LOA really for? [[KD: IMO: LOAs are a simple means of communicating / characterizing a RP's identity assurance risk tolerance. >From an IdP's perspective, it is a mechanism for specifying/communicating what mechanisms they have undertaken.]] - Who uses a simplified "Risk Gauge", and how exactly? [[see above]] - How much original risk analysis is an RP expected to do before they bin their situation into Risk Gauge [[KD: IMO a RP should not do any "original" risk analysis beyond the risk analysis they currently do to identify the risk of something going wrong based on an incorrect identity. It should be noted, the GC does not take into account the probability of something going wrong - they assume it is going to go wrong and identify the consequences of that happening.]] - Is using a Risk Gauge supposed to save time in risk analysis? [[KD: No. Risk analysis still takes the same amount of time. And it still must be done.]] - When an IdP claims a certain Risk Gauge, what does that really mean - contractually? [[KD: IMO, it means that if an IdP can be shown not to have done everything that is specified to provide an assertion then they are liable for all damages. Otherwise, the RP is liable.]] - If an RP at Gauge X finds an IdP at Gauge X (or higher), what's next? How much further analysis is needed before the RP can sign up the IdP? [[KD: no further analysis should be required if the RP can trust that the IdP is telling the truth. An independent certification by an organization such as Kantara Initiative could provide that assurance. That being said, the RP should NOT be expected to use that assertion as the only thing required to mitigate their identity assurance risk. The RP needs to be in control of how much they need to do.]] - If an IdP claims Risk Gauge X, how is that assured? [[KD: as I said above, a certification by an independent third party could provide assurance to a RP.]] What is important, IMO, about the Government of Canada's approach is that they have looked at the whole situation from the RP's perspective ... From the RP being in control of their destiny. It is their problem if something goes wrong. That, and they assume something will go wrong without taking into account the probability of it occuring - it is of little comfort to users to have an RP say, after a break, "we considered that risk but did not think it was too likely to occur." Ken On Friday, January 9, 2015, Richer, Justin P. wrote: > To me, a lot of it comes down to helping the RPs answer one question: > > "Someone just logged in. Now what?" > > I think that binning risk is part of the issue (as Steve states), but > it's also (as a corollary) a matter of setting the context of an > authentication. It's not just about "do I trust the display name" or > whatever other attribute, but also about communicating to the RP what just > happened. This can give the RP a chance at correctly deciding what to do > about it. > > There are really two parts of the whole conversation that I think > getting wound up in each other: > - Things the RP needs to know about the IdP (i.e.: do I trust this IdP? > what risk do I have in doing so?) > - Things the RP needs to know about the authentication transaction (i.e.: > do I trust this log in?) > > The VoT proposal tries to address this with the two different parts of > the protocol: the vector as conveyed by the protocol, and the "trust mark > provider" discovery portion. > > To me, everything else is an aspect of answering these fundamental > questions. > > -- Justin > > On Jan 9, 2015, at 5:26 PM, Joni Brennan > wrote: > > +1 to the suggestions so far and the comments around defining > objectives. > > Apologies if this comment has already been made. It may also be of use > to pop up in the stack as well regarding objectives. One layer abstraction > removed from Steve's well pointed examples... I don't believe we need > specific architecture for each but rather simply to be aware of the varying > communities / priorities. > > LoAs (or something like VoTs) > - Security > - Risk Management > - Interoperability (policy and tech) > - Commercial (regulated / non) > - Government (public service - and what is a public services varies > nationally) > > Best Regards, > > Joni Brennan > Kantara Initiative | Executive Director > email: joni @ kantarainitiative.org > > Connecting Identity for a more trustworthy Internet - Overview > > > > > > On Fri, Jan 9, 2015 at 2:19 PM, > wrote: > >> >> If we're going to improve upon LOAs, then may I suggest the first thing >> to do is set out the objectives? >> >> >> - What is something like LOA really for? >> - Who uses a simplified "Risk Gauge", and how exactly? >> - How much original risk analysis is an RP expected to do before they >> bin their situation into Risk Gauge >> - Is using a Risk Gauge supposed to save time in risk analysis? >> - When an IdP claims a certain Risk Gauge, what does that really mean - >> contractually? >> - If an RP at Gauge X finds an IdP at Gauge X (or higher), what's next? >> How much further analysis is needed before the RP can sign up the IdP? >> - If an IdP claims Risk Gauge X, how is that assured? >> >> >> I suggest that LOAs were intended, net-net, to save time. It was >> thought that by binning risk, RPs would be able to short list and then >> contract with suitable IdPs more quickly. If there is any time saved in >> using LOAs then I suspect it gets gobbled up by the negotiating the fine >> print when signing up an IdP. The very fact that RPs have asked for "LOA 2 >> and a half" tells us that the RP-IdP negotiation tends to be customised. >> Than it, LOAs are difficult to standardise. >> >> >> Before we add dimensions, can we look at what its trying to achieve? >> >> >> Cheers, >> >> >> Steve. >> >> >> >> Stephen Wilson >> Lockstep Group >> http://lockstep.com.au >> Lockstep Consulting provides independent specialist advice and analysis >> on digital identity and privacy. Lockstep Technologies develops unique >> new smart ID solutions that enhance privacy and prevent identity theft. >> >> >> >> >> >> -----Original Message----- >> From: "Jim Fenton" > > >> Sent: Saturday, 10 January, 2015 7:49am >> To: vot@ietf.org >> Subject: [VoT] A modest proposal to replace LOA >> >> I posted some ideas yesterday on a somewhat constrained possible >> replacement for Levels of Assurance: >> >> >> https://altmode.wordpress.com/2015/01/08/level-of-assurance-alternatives-a-modest-proposal/ >> >> tl;dr: One dimension (LOA) isn't enough, but we don't want too many >> dimensions or levels because that gets unwieldy. I'm proposing 3 levels >> each of two dimensions: Level of Strength (authentication) and Level of >> Reliability (attribute binding/proofing). >> >> Any thoughts would be appreciated. >> >> -Jim >> >> _______________________________________________ >> vot mailing list >> vot@ietf.org >> https://www.ietf.org/mailman/listinfo/vot >> >> _______________________________________________ >> vot mailing list >> vot@ietf.org >> https://www.ietf.org/mailman/listinfo/vot >> >> > _______________________________________________ > vot mailing list > vot@ietf.org > https://www.ietf.org/mailman/listinfo/vot > > > --089e0158c43ae4d970050c42525f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Justin,

IMO you have hit the nail on the head with those= questions. At the end of the day, it is the RP's decision because, IMO= , it is ultimately the RP that bears the consequences of something going wr= ong.

The interesting direction taken in the GC app= roach is the RP decides, based upon the GC standard and its supporting guid= ance, on=C2=A0their risk tolerance and categorizes it into a=C2=A0LOA bucke= t. The standard and guidance then=C2=A0identifies, based on that categoriza= tion, what the RP needs to do to mitigate that risk. Part of that mitigatio= n could include accepting assertions from external organizations,=C2=A0such= as authoritative parties,=C2=A0who provide assertions about something. It = does not presume that any authoritative party will provide the "total&= quot; assertion. An important part of the standard is that it does not=C2= =A0specify specific authoritative sources.=C2=A0Rather, it identifies what = types of sources and how many of those=C2=A0sources should be=C2=A0used.

In this context, the answers to Steve's question= s are, IMO, rather simple:
- What is something like LOA really for? [[K= D: IMO: LOAs are a simple means of communicating / characterizing a RP'= s identity assurance risk tolerance. From an IdP's perspective, it is a= mechanism for specifying/communicating=C2=A0what mechanisms they have unde= rtaken.]]
- Who uses a simplified "Risk Gauge", and h= ow exactly? [[see above]]
- How much original risk analysis is = an RP expected to do before they bin their situation into Risk Gauge [[KD: = IMO a RP should not do any "original" risk analysis beyond the ri= sk analysis they currently do to identify the risk of something going wrong= based on an incorrect identity. It should be noted, the GC does not take i= nto account the probability of something going wrong - they assume it is go= ing to go wrong and identify the consequences of that happening.]]
- Is using a Risk Gauge supposed to save time in risk analysis? [[KD: N= o. Risk analysis still takes the same=C2=A0 amount of time. And it still mu= st be done.]]
- When an IdP claims a certain Risk Gauge, what does that re= ally mean - contractually? [[KD: IMO, it means that if an IdP can be shown = not to have done everything that is specified to provide an assertion then = they are liable=C2=A0for=C2=A0all damages. Otherwise, the RP is liable.]]
-=C2=A0If an = RP at Gauge X finds an IdP at Gauge X (or higher), what's next? How muc= h further analysis is needed before the RP can sign up the IdP? [[KD: no fu= rther analysis should be required if=C2=A0the RP can trust that the IdP=C2= =A0is telling the truth. An independent certification by an organization su= ch as Kantara Initiative could provide that assurance. That being said, the= RP should NOT be expected to use that assertion as the only thing required= to mitigate their identity assurance risk. The RP needs to be in control o= f how much they need to do.]]
- If an IdP claims Risk Gauge X, = how is that assured? [[KD: as I said above, a certification by an=C2=A0inde= pendent third party=C2=A0could provide assurance to a RP.]]

=
What is important, IMO, about the Government of=C2=A0Canada'= ;s approach is that they have looked at the whole=C2=A0situation from the R= P's perspective ... From the RP being in control of their destiny. It i= s their problem if something goes wrong. That, and they assume something wi= ll go wrong without taking into account the probability of it occuring - it= is of little comfort to users to have an RP say, after a break, "we c= onsidered that risk but did not think it was too likely to occur."

Ken

On Friday, January 9, 2015= , Richer, Justin P. <jricher@mitre.= org> wrote:
To me, a lot of it comes down to helping the RPs answer one question:

"Someone just logged in. Now what?"

I think that binning risk is part of the issue (as Steve states), but = it's also (as a corollary) a matter of setting the context of an authen= tication. It's not just about "do I trust the display name" o= r whatever other attribute, but also about communicating to the RP what just happened. This can give the RP a chance at correctly d= eciding what to do about it.

There are really two parts of the whole conversation that I think gett= ing wound up in each other:
=C2=A0- Things the RP needs to know about the IdP (i.e.: do I trust th= is IdP? what risk do I have in doing so?)
=C2=A0- Things the RP needs to know about the authentication transacti= on (i.e.: do I trust this log in?)

The VoT proposal tries to address this with the two different parts of= the protocol: the vector as conveyed by the protocol, and the "trust = mark provider" discovery portion.

To me, everything else is an aspect of answering these fundamental que= stions.

=C2=A0-- Justin

On Jan 9, 2015, at 5:26 PM, Joni Brennan <joni@kantarainitiative.org> wrote:

+1 to the suggestions so far and the comments around defin= ing objectives. =C2=A0

Apologies if this comment has already been made.=C2=A0 It may also be = of use to pop up in the stack as well regarding objectives.=C2=A0 One layer= abstraction removed from Steve's well pointed examples... I don't = believe we need specific architecture for each but rather simply to be aware of the varying communities / priorities.=C2=A0
=C2=A0=C2=A0
LoAs (or something like VoTs)=C2=A0
- Security
- Risk Management
- Interoperability (policy and tech)=C2=A0
- Commercial (regulated / non)
- Government (public service - and what is a public services varies na= tionally)

Best Regards,

Joni Brennan
Kantara Initiative | Executive Director
email: joni @ k= antarainitiative.org

Connecting Identity for a more trustworthy Internet - Overview




On Fri, Jan 9, 2015 at 2:19 PM, <swilson@lockstep.com.au> wro= te:

=C2=A0

If we're going to improve upon LOAs, then may I suggest the first thing= to do is set out the objectives?=C2=A0

=C2=A0

- What is something like LOA really for?=C2=A0
- Who uses a simplified "Risk Gauge", and how exactly?=C2=A0
- How much original risk analysis is an RP expected to do before they bin t= heir situation into Risk Gauge
- Is using a Risk Gauge supposed to save time in risk analysis?
- When an IdP claims a certain Risk Gauge, what does that really mean - con= tractually?
- If an RP at Gauge X finds an IdP at Gauge X (or higher), what's next?= How much further analysis is needed before the RP can sign up the IdP?=C2= =A0
- If an IdP claims Risk Gauge X, how is that assured?

=C2=A0

I suggest that LOAs were intended, net-net, to save time.=C2=A0 It was thou= ght that by binning risk, RPs would be able to short list and then contract= with suitable IdPs more quickly.=C2=A0 If there is any time saved in using= LOAs=C2=A0then I suspect it gets=C2=A0gobbled up by the negotiating the fine print when signing up an IdP.=C2=A0 The very fact= that RPs have asked for "LOA 2 and a half" tells us that the RP-= IdP negotiation tends to be customised.=C2=A0 Than it, LOAs are difficult t= o standardise.=C2=A0

=C2=A0

Before we add dimensions, can we look at what its trying to achieve?

=C2=A0

Cheers,=C2=A0

=C2=A0

Steve.

=C2=A0


Stephen Wilson
Lockstep Group=C2=A0
http://lockstep.com.a= u
Lockstep Consulting provides independent specialist advice and analysis on digital identity and privacy.=C2=A0 Lockstep Technologies develops uniqu= e
new smart ID solutions that enhance privacy and prevent identity theft.
=C2=A0

=C2=A0

=C2=A0

-----Original Message-----
From: "Jim Fenton" <fenton@bluepopco= rn.net>
Sent: Saturday, 10 January, 2015 7:49am
To: vot@ietf.org
Subject: [VoT] A modest proposal to replace LOA

I posted some ideas yesterday on a somewhat constrained possible
replacement for Levels of Assurance:

https://altmode.wordpress.co= m/2015/01/08/level-of-assurance-alternatives-a-modest-proposal/

tl;dr: One dimension (LOA) isn't enough, but we don't want too many=
dimensions or levels because that gets unwieldy. I'm proposing 3 levels=
each of two dimensions: Level of Strength (authentication) and Level of
Reliability (attribute binding/proofing).

Any thoughts would be appreciated.

-Jim

_______________________________________________
vot mailing list
vot@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/vot

_______________________________________________
vot mailing list
vot@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/vot


_______________________________________________
vot mailing list
vot@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/vot

--089e0158c43ae4d970050c42525f-- From nobody Sun Jan 11 18:24:13 2015 Return-Path: X-Original-To: vot@ietfa.amsl.com Delivered-To: vot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5E1D1A8A12 for ; Sun, 11 Jan 2015 18:24:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 wRIylr9V36jP for ; Sun, 11 Jan 2015 18:24:09 -0800 (PST) Received: from mta5.uth.tmc.edu (mta5.uth.tmc.edu [129.106.149.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58B431A89B4 for ; Sun, 11 Jan 2015 18:24:08 -0800 (PST) Received: from pps.filterd (mta5.uth.tmc.edu [127.0.0.1]) by mta5.uth.tmc.edu (8.14.5/8.14.5) with SMTP id t0C2O0fT018241; Sun, 11 Jan 2015 20:24:00 -0600 Received: from uthmail3.uthouston.edu (admin4-6.hsc.uth.tmc.edu [129.106.4.6]) by mta5.uth.tmc.edu with ESMTP id 1rv3sf861s-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 11 Jan 2015 20:23:59 -0600 Received: from UTHMAIL1.uthouston.edu ([fe80::c1d2:3f6a:4f56:4fa4]) by UTHMAIL3.uthouston.edu ([fe80::fd74:5f7a:1426:e687%22]) with mapi id 14.03.0210.002; Sun, 11 Jan 2015 20:23:58 -0600 From: "Jones, Mark B" To: Jim Fenton , "vot@ietf.org" Thread-Topic: [VoT] A modest proposal to replace LOA Thread-Index: AQHQLE3NIVccl7Oe9EyjUXstdR0255y7QHEA Date: Mon, 12 Jan 2015 02:23:57 +0000 Message-ID: <38AAF00EA635514CA6667ACA60C7F0A53153A573@UTHMAIL1.uthouston.edu> References: <54B03EE4.3060909@bluepopcorn.net> In-Reply-To: <54B03EE4.3060909@bluepopcorn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [129.106.149.128] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00BB_01D02DDC.856099E0" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2015-01-12_01:2015-01-10,2015-01-11,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 kscore.is_bulkscore=1.5182299861749e-13 kscore.compositescore=0 circleOfTrustscore=0 compositescore=0.51925478421192 urlsuspect_oldscore=0.091998239371726 suspectscore=0 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=0 rbsscore=0.51925478421192 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1501120025 Archived-At: Subject: Re: [VoT] A modest proposal to replace LOA X-BeenThere: vot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Vectors of Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2015 02:24:12 -0000 ------=_NextPart_000_00BB_01D02DDC.856099E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit It is my opinion that the levels of assurance in 800-63 are meant to describe specific sets of threats that should be addressed at specific, common risk levels and to describe how to mitigate those threats. It is not clear what specific threats your proposed levels are meant to address. (I think the VoT discussion in general is also lacking in references to what specific threats are meant to be addressed by specific vectors.) Though 800-63 has language that talks about including verified attributes in credentials and assertions it makes it clear that inclusion of attributes is optional. I feel that 800-63 works just fine in a model where authentication and attribute providers are separate because it does not specify any limits on how attributes can be communicated. It is my opinion that 'authentication' and the communication of attributes must be conceptualized as very separate processes and that your concept of "Attribute Reliability" inappropriately conflates 'Registration and Credential Issuance' with attribute assertions. The threats associated with inappropriate registration and credential issuance are very different from those associated with receiving inaccurate attribute assertions. Though some have reasonable arguments for assigning levels of assurance to attributes, I believe that relying parties must trust 'attribute providers' as opposed to trusting specific attribute assertions. It is my opinion that relying parties should only request attributes from providers they consider to be (or accept as) authoritative for the attributes requested. So in my view attributes have little to do with LOA discussion. In summary I feel that any scheme for expressing LOA needs to describe the threats that are mitigated, the strength of those mitigations, and trust of authentication should be kept separate from trust of attribute assertions. After all, authentication establishes trust in the PERSON on the other end of a transaction while trust in an attribute assertion represents trust in the PROVIDER to collect and assert good attributes. > -----Original Message----- > From: vot [mailto:vot-bounces@ietf.org] On Behalf Of Jim Fenton > Sent: Friday, January 09, 2015 2:50 PM > To: vot@ietf.org > Subject: [VoT] A modest proposal to replace LOA > > I posted some ideas yesterday on a somewhat constrained possible > replacement for Levels of Assurance: > > https://urldefense.proofpoint.com/v2/url?u=https- > 3A__altmode.wordpress.com_2015_01_08_level-2Dof-2Dassurance- > 2Dalternatives-2Da-2Dmodest- > 2Dproposal_&d=AwICAg&c=6vgNTiRn9_pqCD9hKx9JgXN1VapJQ8JVoF8oWH > 1AgfQ&r=jgMu8DNgV_dycz0rYwkNbEQq36F0BI5_Zpblz7C5LhM&m=2E_n- > hMMZrra2XwK7mj_KrpU8b-c3PcCa45FsWVh0bE&s=Af4ObdyoFr4e6yoEMT- > aIfNHcCZsmGzZZMyr1LnD5Oo&e= > > tl;dr: One dimension (LOA) isn't enough, but we don't want too many > dimensions or levels because that gets unwieldy. I'm proposing 3 levels each > of two dimensions: Level of Strength (authentication) and Level of Reliability > (attribute binding/proofing). > > Any thoughts would be appreciated. > > -Jim > > _______________________________________________ > vot mailing list > vot@ietf.org > https://urldefense.proofpoint.com/v2/url?u=https- > 3A__www.ietf.org_mailman_listinfo_vot&d=AwICAg&c=6vgNTiRn9_pqCD9h > Kx9JgXN1VapJQ8JVoF8oWH1AgfQ&r=jgMu8DNgV_dycz0rYwkNbEQq36F0BI5 > _Zpblz7C5LhM&m=2E_n-hMMZrra2XwK7mj_KrpU8b- > c3PcCa45FsWVh0bE&s=M7Gbma252T4WErXbcfD- > 69cOz3ZwOSUUCxEP2QIPklg&e= ------=_NextPart_000_00BB_01D02DDC.856099E0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITvjCCBDYw ggMeoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRy dXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZ QWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wMDA1MzAxMDQ4MzhaFw0yMDA1MzAxMDQ4Mzha MG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3Qg RXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3Qw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC39xoz5vIABC054E5b7R+8bA/Ntfojts7e mxEzl6QpTH2Tn71KvJPtAxrjj8/lbVBa1pcplFqAsEl62y6V/bjKvzc4LR4+kUGtcFbH8E8/6DKe dMrIkFTpxl8PeJ2aQDwOrGGqXhSPnoehalDc15pOrwWzpnGUnHGzUGAKxxOdOAeGAqjpqGkmGJCr TLBPI6s6T4TY386f4Wlvu9dC12tE5Met7m1BX3JacQg3s3llpFmglDf3AC8NwpJy2tA4ctsUqEXE XSp9t7TWxO6szRNEt8kr3UMAJfphuWlqWCMRt6czj1Z1WfXNKddGtworZbbTQm8Vsrh7++/pXVPV NFonAgMBAAGjgdwwgdkwHQYDVR0OBBYEFK29mHo0tCb3+sQmVO8DveAky1QaMAsGA1UdDwQEAwIB BjAPBgNVHRMBAf8EBTADAQH/MIGZBgNVHSMEgZEwgY6AFK29mHo0tCb3+sQmVO8DveAky1QaoXOk cTBvMQswCQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0 IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 ggEBMA0GCSqGSIb3DQEBBQUAA4IBAQCwm+CFJcLWI+IPlgaSnUGYnNmEeYHZHlsUByM2ZY+w2He7 rEFsR2CDUbD5Mj3n/PYmE8eAFqW/WvyHz3h5iSGa4kwHCoY1vPLeUcTSlrfcfk7ucP0cOesMAlEU LY69FuDB30Z15ySt7PRCtIWTcBBnup0GNUoY0yt6zFFCoXpj0ea7ocUrwja+Ew3mvWN+eXunCQ1A q2rdj4rD9vaMGkIFUdRF9Z+nYiFoFSBDPJnnfL0k2KmRF3OIP1YbMTgYtHEPms3IDp6OLhvhjJiD yx8x8URMxgRzSXZgD8f4vReAay7pzEwOWpp5DyAKLtWeYyYeVZKU2IIXWnvQvMePToYEMIIEnTCC A4WgAwIBAgIQND3pK6wnNP+PyzSU+8xwVDANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEU MBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3 b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTA1MDYwNzA4MDkxMFoX DTIwMDUzMDEwNDgzOFowga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2Fs dCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0 cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRo ZW50aWNhdGlvbiBhbmQgRW1haWwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCyOYWk 8n2rQTtiRjeuzcFgdbw5ZflKGkeiucxIzGqY1U01GbmkQuXOSeKKLx580jEHx060g2SdLinVomTE hb2FUTV5pE5okHsceqSSqBfymBXyk8zJpDKVuwxPML2YoAuL5W4bokb6eLyib6tZXqUvz8rabaov 66yhs2qqty5nNYt54R5piOLmRs2gpeq+C852OnoOm+r82idbPXMfIuZIYcZM82mxqC4bttQxICy8 goqOpA6l14lD/BZarx1x1xFZ2rqHDa/68+HC8KTFZ4zW1lQ63gqkugN3s2XI/R7TdGKqGMpokx6h hX71R2XL+E1XKHTSNP8wtu72YjAUjCzrAgMBAAGjgfQwgfEwHwYDVR0jBBgwFoAUrb2YejS0Jvf6 xCZU7wO94CTLVBowHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59MA4GA1UdDwEB/wQEAwIB BjAPBgNVHRMBAf8EBTADAQH/MBEGA1UdIAQKMAgwBgYEVR0gADBEBgNVHR8EPTA7MDmgN6A1hjNo dHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vQWRkVHJ1c3RFeHRlcm5hbENBUm9vdC5jcmwwNQYIKwYB BQUHAQEEKTAnMCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3 DQEBBQUAA4IBAQABvJzjYyiw8zEBwt973WKgAZ0jMQ+cknNTUeofTPrWn8TKL2d+eDMPdBa5kYeR 9Yom+mRwANge+QsEYlCHk4HU2vUj2zS7hVa0cDRueIM3HoUcxREVkl+HF72sav3xwtHMiV+xfPA+ UfI183zsYJhrOivg79+zfYbrtRv1W+yifJgT1wBQudEtc94DeHThBYUxXsuauZ2UxrmUN3Vy3ET7 Z+jw+iUeUqfaJelH4KDHPKBOsQo2+3dIn++Xivu0/uOUFKiDvFwtP9JgcWDuwnGCDOmINuPaILSj oGyqlku4gI51ykkH9jsUut/cBdmf2+Cy5k2geCbn5y1uf1/GHogVMIIFJTCCBA2gAwIBAgIQRIUc GfetDxT4xHWGNMR0xzANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVU MRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3Jr MSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmly c3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0xMDEyMDIwMDAwMDBaFw0yMDA1 MzAxMDQ4MzhaMIGWMQswCQYDVQQGEwJVUzFBMD8GA1UEChM4VGhlIFVuaXZlcnNpdHkgb2YgVGV4 YXMgSGVhbHRoIFNjaWVuY2UgQ2VudGVyIGF0IEhvdXN0b24xRDBCBgNVBAMTO1RoZSBVbml2ZXJz aXR5IG9mIFRleGFzIEhlYWx0aCBTY2llbmNlIENlbnRlciBhdCBIb3VzdG9uIENBMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxElj8A/NxSnbcaHKOvWlDt5+EbJMPZFayMmRcR5BbEqw M9PLQPTH1yJIZp+7Afgi6CZ/GrJcOEIRsfP43H3VK5O5FI6zIT6ZEEjj+huZ0hWey6Cg/ZNU22Mr XXCGEc0W4afqSXNX2mkck2oQW3xrDTaifCWBFQDki+k5d8wKQ2buk/aIFJO0qomzxq1cdJqAS/sF PWR3aRdJrn5IsjZeDsnsWZFpKCRiAybgcogM0f2mWDLATusRoL41DiOlJfH22NObHcFTQmsoAnXj X+FwJwdZ5H+kiiUCH9tXOHdPyKOoQoBqg+mdkCb4wviJsVTrq4lffBGe+xyeK2dlYngQSQIDAQAB o4IBUzCCAU8wHwYDVR0jBBgwFoAUiYJnfcSdJnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFJkX0AQh Sm6R8Ydeb3ZvO93EMh4gMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEAMBkGA1Ud IAQSMBAwDgYMKwYBBAGyMQECAiQFMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRy dXN0LmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQG CCsGAQUFBwEBBGgwZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFk ZFRydXN0Q2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNv bTANBgkqhkiG9w0BAQUFAAOCAQEAKqKCLV43+zEwBp/AHeelxnJikiO6zfHH7lNSvtwBPyGm4ZuI v6WHl669XQpMLcUxy8b0B8gHZ00AA+mZ7r2YP7HrUiuTEWssdA859PYHeIulfBfLhSP28On7C1Mx aODD9UQtj1j3NUGCy2kCGB2xupUjEXtNWSTgEGWhMiv5V+EvjLEns59Rpm5BHWgsycFOSyztjJYQ kRIFx3Yi6IX5b7s+lxMt96yVwaatlI+xMWPJpxeWlBzq/nIhPfREJmKf0RzZh58Gi6TnIPjmSsIV BZJhUxdTIJkfaJkajOy539WRMM9k04gBH4ZIFd2VwqwB9aZl27LgfvYOeeoswzPpRzCCBbYwggSe oAMCAQICEQC2CAUBCn9+NClEHZu5j+aOMA0GCSqGSIb3DQEBBQUAMIGWMQswCQYDVQQGEwJVUzFB MD8GA1UEChM4VGhlIFVuaXZlcnNpdHkgb2YgVGV4YXMgSGVhbHRoIFNjaWVuY2UgQ2VudGVyIGF0 IEhvdXN0b24xRDBCBgNVBAMTO1RoZSBVbml2ZXJzaXR5IG9mIFRleGFzIEhlYWx0aCBTY2llbmNl IENlbnRlciBhdCBIb3VzdG9uIENBMB4XDTE0MDkxNTAwMDAwMFoXDTE1MDkxNTIzNTk1OVowgbMx DjAMBgNVBBETBTc3MDMwMRwwGgYDVQQKExNVVEhFQUxUSCBOT04tRVNDUk9XMRQwEgYDVQQJEws3 MDAwIEZhbm5pbjEOMAwGA1UECBMFVGV4YXMxEDAOBgNVBAcTB0hvdXN0b24xCzAJBgNVBAYTAlVT MRUwEwYDVQQDEwxNYXJrIEIgSm9uZXMxJzAlBgkqhkiG9w0BCQEWGG1hcmsuYi5qb25lc0B1dGgu dG1jLmVkdTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAIsD9b8/H96eboYROkoZaA2/ QEXxNACieGhSr+CQzUfSlhWcL4M69uA938pqeKvzGWWJBEkb46tzTMhnbWuvbNfqUT+PBShIvkSr ndy7BE0ozkKjFVU/6jTsj2klnDyfq3wn0+GA/e+FTzYaDdj7ts6fij74De2GDPdNlVJa6uzzMaTd 7cS3T87ht0Yr03NStJRAl+IdN4cpJ9+Xn14NG7PnlZy5fyXDWM88kd/guUpdfK6XIjEud01vjDco NpN3ihRXl8LnEP700dosa2r897emtg8XJaSnw4k/GJUfSuGgW2rbYpUOyR9JPzZQMlLPqptNRjF5 WAzp2neDcl2fb0kCAwEAAaOCAd4wggHaMB8GA1UdIwQYMBaAFJkX0AQhSm6R8Ydeb3ZvO93EMh4g MB0GA1UdDgQWBBTk8/IYWxQfOajleb+QbNEs5R1HCzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/ BAIwADAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwQwYDVR0gBDwwOjA4BgwrBgEEAbIx AQICJAUwKDAmBggrBgEFBQcCARYaaHR0cDovL3d3dy51dGgudG1jLmVkdS9jcHMwXgYDVR0fBFcw VTBToFGgT4ZNaHR0cDovL2NybC51dGgudG1jLmVkdS9UaGVVbml2ZXJzaXR5b2ZUZXhhc0hlYWx0 aFNjaWVuY2VDZW50ZXJhdEhvdXN0b25DQS5jcmwwgZAGCCsGAQUFBwEBBIGDMIGAMFkGCCsGAQUF BzAChk1odHRwOi8vY3J0LnV0aC50bWMuZWR1L1RoZVVuaXZlcnNpdHlvZlRleGFzSGVhbHRoU2Np ZW5jZUNlbnRlcmF0SG91c3RvbkNBLmNydDAjBggrBgEFBQcwAYYXaHR0cDovL29jc3AudXRoLnRt Yy5lZHUwIwYDVR0RBBwwGoEYbWFyay5iLmpvbmVzQHV0aC50bWMuZWR1MA0GCSqGSIb3DQEBBQUA A4IBAQCB5ypKawPDBa1lkt5Kv3priYCzwt5kUJA9MaQArIbAnpH2OoPnaUcnaGFNhgbm7TMJmC4V spP7uBsrtUGzywRe7AXwrRLX5WKxT4KKDdIonoftE0zVJGCP8SelTnlCOYk1/aa7blWsLtEan/AG sgJwFo8IjrWI95DqimKhH7qOU5KIbPovEksE6NFE0EcHdBLDEWmH1iCaZvl2qNJyrERtVYxG7wTA UTlMG6Tr2tkm1f6NJizvUSCaxCVVpZ4QSHYb6edNYI25w/D2yoDeGCvyq9lyRA/h5QooHdxu+8tG JZpxA9fSKDewjKNIJoirGOhrLM9t8/NxXw40sd7vZdTZMYIEFDCCBBACAQEwgawwgZYxCzAJBgNV BAYTAlVTMUEwPwYDVQQKEzhUaGUgVW5pdmVyc2l0eSBvZiBUZXhhcyBIZWFsdGggU2NpZW5jZSBD ZW50ZXIgYXQgSG91c3RvbjFEMEIGA1UEAxM7VGhlIFVuaXZlcnNpdHkgb2YgVGV4YXMgSGVhbHRo IFNjaWVuY2UgQ2VudGVyIGF0IEhvdXN0b24gQ0ECEQC2CAUBCn9+NClEHZu5j+aOMAkGBSsOAwIa BQCgggI8MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDExMjAy MjM1NFowIwYJKoZIhvcNAQkEMRYEFAblPQIYgt9sPUrjaKvn/l2l7Kx4MFsGCSqGSIb3DQEJDzFO MEwwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G CCqGSIb3DQMCAgEoMAcGBSsOAwIaMIG9BgkrBgEEAYI3EAQxga8wgawwgZYxCzAJBgNVBAYTAlVT MUEwPwYDVQQKEzhUaGUgVW5pdmVyc2l0eSBvZiBUZXhhcyBIZWFsdGggU2NpZW5jZSBDZW50ZXIg YXQgSG91c3RvbjFEMEIGA1UEAxM7VGhlIFVuaXZlcnNpdHkgb2YgVGV4YXMgSGVhbHRoIFNjaWVu Y2UgQ2VudGVyIGF0IEhvdXN0b24gQ0ECEQC2CAUBCn9+NClEHZu5j+aOMIG/BgsqhkiG9w0BCRAC CzGBr6CBrDCBljELMAkGA1UEBhMCVVMxQTA/BgNVBAoTOFRoZSBVbml2ZXJzaXR5IG9mIFRleGFz IEhlYWx0aCBTY2llbmNlIENlbnRlciBhdCBIb3VzdG9uMUQwQgYDVQQDEztUaGUgVW5pdmVyc2l0 eSBvZiBUZXhhcyBIZWFsdGggU2NpZW5jZSBDZW50ZXIgYXQgSG91c3RvbiBDQQIRALYIBQEKf340 KUQdm7mP5o4wDQYJKoZIhvcNAQEBBQAEggEAY0O5LKVytTO7G1WKGWUuU+vRNMl15n2+haX0RHtm Ng7CklSPQsemuxa7uvFfqw8G0k19on+PAqncmMMhp2osMIaismYUkgFWW7pVzgYXEQ5skmpPDDYB ngis2ic+gM+PjB2CUwyAJXDLjyUkT80Hn7+t9jkxJdzqRHz87jqSBVPSBynlOOimWzIzCiLmh/oK r8CKdXP5myXVyQzXEgbMfw8/hCMDtbNfOFPZxB+lpbFqN/JEzlh3wo780qdnDL8qsQLcD9vr3l8h asSl5CUekI2AangHR1OzUGX5hw+wTKfPUcB7PrBv0I2OmrF+21cVe+P45kP+/7H3XxlSV+rbGQAA AAAAAA== ------=_NextPart_000_00BB_01D02DDC.856099E0-- From nobody Mon Jan 12 06:07:05 2015 Return-Path: X-Original-To: vot@ietfa.amsl.com Delivered-To: vot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01F3C1A9132 for ; Mon, 12 Jan 2015 06:07:02 -0800 (PST) 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, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, 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 0F9r56gmVAQK for ; Mon, 12 Jan 2015 06:06:53 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0640.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:640]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74C901A90E5 for ; Mon, 12 Jan 2015 06:06:52 -0800 (PST) Received: from CO2PR0601MB0983.namprd06.prod.outlook.com (25.160.7.28) by CO2PR0601MB0983.namprd06.prod.outlook.com (25.160.7.28) with Microsoft SMTP Server (TLS) id 15.1.53.17; Mon, 12 Jan 2015 14:06:27 +0000 Received: from CO2PR0601MB0983.namprd06.prod.outlook.com ([25.160.7.28]) by CO2PR0601MB0983.namprd06.prod.outlook.com ([25.160.7.28]) with mapi id 15.01.0053.000; Mon, 12 Jan 2015 14:06:27 +0000 From: Robin Wilton To: "vot@ietf.org" Thread-Topic: vot Digest, Vol 5, Issue 2 Thread-Index: AQHQLHYb4EInGI0jEkSX5ORdWuVAkJy8iZqA Date: Mon, 12 Jan 2015 14:06:27 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [94.174.34.240] authentication-results: spf=none (sender IP is ) smtp.mailfrom=wilton@isoc.org; x-dmarcaction-test: None x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005003);SRVR:CO2PR0601MB0983; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:CO2PR0601MB0983; x-forefront-prvs: 0454444834 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(189002)(252514010)(10533003)(57704003)(5403001)(13464003)(377454003)(199003)(24454002)(129404003)(27574002)(87936001)(101416001)(19580405001)(102836002)(19617315012)(2950100001)(2900100001)(15975445007)(19580395003)(64706001)(68736005)(110136001)(82746002)(92566002)(122556002)(66066001)(36756003)(106116001)(450100001)(99286002)(105586002)(2656002)(106356001)(83716003)(77156002)(2501002)(97736003)(54356999)(99936001)(46102003)(50986999)(76176999)(561944003)(33656002)(551934003)(16236675004)(15395725005)(86362001)(16601075003)(2351001)(40100003)(62966003)(107886001)(104396002)(579004); DIR:OUT; SFP:1101; SCL:1; SRVR:CO2PR0601MB0983; H:CO2PR0601MB0983.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: isoc.org does not designate permitted sender hosts) Content-Type: multipart/signed; boundary="Apple-Mail=_918B9DEF-70FC-4755-BD21-B8B2CD42F80D"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jan 2015 14:06:27.0390 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR0601MB0983 Archived-At: Subject: Re: [VoT] vot Digest, Vol 5, Issue 2 X-BeenThere: vot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Vectors of Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2015 14:07:02 -0000 --Apple-Mail=_918B9DEF-70FC-4755-BD21-B8B2CD42F80D Content-Type: multipart/alternative; boundary="Apple-Mail=_A6614B90-5829-4377-9521-B0CC0F972BBD" --Apple-Mail=_A6614B90-5829-4377-9521-B0CC0F972BBD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 This thread raises several important topics=85 just as a practical = matter, it might be worth trying to spin some of them off separately, so = that we address them all, and minimise the risk of talking at = cross-purposes. =20 It feels like it would be worth trying to put together some *very short* = straw-man docs/pages/paragraphs to try and get a consensus version on = specific points, so that we avoid re-hashing the same = arguments/discussions over time, or at least have something we can refer = to - and amend if necessary. I think this is aiming at the same = end-point as Steve=92s request for a statement of requirements, but will = ensure we=92re expressing our requirements in a consistent set of terms. By the looks of it, these would make for a good starting point (I think = the answers to most of these are implicit in various people=92s = contributions to the thread=85 but that doesn=92t mean everyone agrees = ;^) ): 1 - what do we mean by authentication and authorisation? Are there other = decisions (e.g. access control, entitlement) which need to be called out = explicitly? This reflects the purpose of Justin=92s questions. = Classically, the reason for authenticating a user is to answer a yes/no = question (is this the person to whom this credential was originally = issued); if yes, what do I want to do about it (at which point the = further entitlements are usually determined by retrieving a user = profile, ACL or whatever)? However, as we know, these days access control and entitlement decisions = also need to be made on the basis of input other than classic = credentials, and that=92s one of the two cores of this discussion, I = believe. 2 - what=92s the classic lifecycle of a credential - i.e. a artefact = intended to provide evidence in support of an assertion of identity. = (e.g. registration/verification/enrolment, credential issue, credential = presentation/authentication, credential = amendment/revocation/destruction=85)?=20 3 - How does (2) relate to other assertions (e.g. attribute assertions) = we would like to make reliably? With that starter set, I think we can confirm the subset of requirements = that 800-63-1 still meets, and define the delta that requires new = design. 4 - What=92s the right way to update current thinking on LOAs, to = account for the change Jim describes in his proposal - i.e., the case = where "credentials (used in authentication) and attribute information = (established through identity proofing) could be provided by different = parties.=94 5 - =46rom Jim=92s proposal: =93Attribute reliability refers to the = quality of the identity proofing process, as well as the strength of the = binding of the identifying attributes to the authentication.=94 Do we = need/want to expand on this a little? This seems to cater well for the = case where, say, vehicle entitlements are being established so that they = can be encapsulated in a driving licence. It=92s not so clear how this = addresses, say, third party assertions that do not arise from an = identity proofing process - =93I have no idea *who* this user is, but I = can reliably assert the following about them: ... =94. I think this might make it easier for us to put Steve=92s requirements = analysis and Ken=92s liability model (which are both excellent, btw) = into a shared conceptual framework, and also reduce the effort required = to explain VoT to other stakeholders/contributors. Hope this helps -=20 R Robin Wilton Technical Outreach Director - Identity and Privacy Internet Society email: wilton@isoc.org Phone: +44 705 005 2931 Twitter: @futureidentity On 10 Jan 2015, at 01:38, vot-request@ietf.org wrote: > Send vot mailing list submissions to > vot@ietf.org >=20 > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/vot > or, via email, send a message with subject or body 'help' to > vot-request@ietf.org >=20 > You can reach the person managing the list at > vot-owner@ietf.org >=20 > When replying, please edit your Subject line so it is more specific > than "Re: Contents of vot digest..." > Today's Topics: >=20 > 1. Re: A modest proposal to replace LOA (Richer, Justin P.) > 2. Re: A modest proposal to replace LOA (Ken Dagg) >=20 > From: "Richer, Justin P." > Subject: Re: [VoT] A modest proposal to replace LOA > Date: 9 January 2015 22:59:56 GMT > To: Joni Brennan > Cc: "vot@ietf.org" , Stephen Wilson = >=20 >=20 > To me, a lot of it comes down to helping the RPs answer one question: >=20 > "Someone just logged in. Now what?" >=20 > I think that binning risk is part of the issue (as Steve states), but = it's also (as a corollary) a matter of setting the context of an = authentication. It's not just about "do I trust the display name" or = whatever other attribute, but also about communicating to the RP what = just happened. This can give the RP a chance at correctly deciding what = to do about it. >=20 > There are really two parts of the whole conversation that I think = getting wound up in each other: > - Things the RP needs to know about the IdP (i.e.: do I trust this = IdP? what risk do I have in doing so?) > - Things the RP needs to know about the authentication transaction = (i.e.: do I trust this log in?) >=20 > The VoT proposal tries to address this with the two different parts of = the protocol: the vector as conveyed by the protocol, and the "trust = mark provider" discovery portion. >=20 > To me, everything else is an aspect of answering these fundamental = questions. >=20 > -- Justin >=20 > On Jan 9, 2015, at 5:26 PM, Joni Brennan = wrote: >=20 >> +1 to the suggestions so far and the comments around defining = objectives. =20 >>=20 >> Apologies if this comment has already been made. It may also be of = use to pop up in the stack as well regarding objectives. One layer = abstraction removed from Steve's well pointed examples... I don't = believe we need specific architecture for each but rather simply to be = aware of the varying communities / priorities.=20 >> =20 >> LoAs (or something like VoTs)=20 >> - Security >> - Risk Management >> - Interoperability (policy and tech)=20 >> - Commercial (regulated / non) >> - Government (public service - and what is a public services varies = nationally) >>=20 >> Best Regards, >>=20 >> Joni Brennan >> Kantara Initiative | Executive Director >> email: joni @ kantarainitiative.org >>=20 >> Connecting Identity for a more trustworthy Internet - Overview >>=20 >>=20 >>=20 >>=20 >> On Fri, Jan 9, 2015 at 2:19 PM, wrote: >> =20 >> If we're going to improve upon LOAs, then may I suggest the first = thing to do is set out the objectives?=20 >> =20 >> - What is something like LOA really for?=20 >> - Who uses a simplified "Risk Gauge", and how exactly?=20 >> - How much original risk analysis is an RP expected to do before they = bin their situation into Risk Gauge >> - Is using a Risk Gauge supposed to save time in risk analysis? >> - When an IdP claims a certain Risk Gauge, what does that really mean = - contractually? >> - If an RP at Gauge X finds an IdP at Gauge X (or higher), what's = next? How much further analysis is needed before the RP can sign up the = IdP?=20 >> - If an IdP claims Risk Gauge X, how is that assured? >> =20 >> I suggest that LOAs were intended, net-net, to save time. It was = thought that by binning risk, RPs would be able to short list and then = contract with suitable IdPs more quickly. If there is any time saved in = using LOAs then I suspect it gets gobbled up by the negotiating the fine = print when signing up an IdP. The very fact that RPs have asked for = "LOA 2 and a half" tells us that the RP-IdP negotiation tends to be = customised. Than it, LOAs are difficult to standardise.=20 >> =20 >> Before we add dimensions, can we look at what its trying to achieve? >> =20 >> Cheers,=20 >> =20 >> Steve. >> =20 >>=20 >> Stephen Wilson >> Lockstep Group=20 >> http://lockstep.com.au >> Lockstep Consulting provides independent specialist advice and = analysis=20 >> on digital identity and privacy. Lockstep Technologies develops = unique=20 >> new smart ID solutions that enhance privacy and prevent identity = theft. >> =20 >> =20 >> =20 >> -----Original Message----- >> From: "Jim Fenton" >> Sent: Saturday, 10 January, 2015 7:49am >> To: vot@ietf.org >> Subject: [VoT] A modest proposal to replace LOA >>=20 >> I posted some ideas yesterday on a somewhat constrained possible >> replacement for Levels of Assurance: >>=20 >> = https://altmode.wordpress.com/2015/01/08/level-of-assurance-alternatives-a= -modest-proposal/ >>=20 >> tl;dr: One dimension (LOA) isn't enough, but we don't want too many >> dimensions or levels because that gets unwieldy. I'm proposing 3 = levels >> each of two dimensions: Level of Strength (authentication) and Level = of >> Reliability (attribute binding/proofing). >>=20 >> Any thoughts would be appreciated. >>=20 >> -Jim >>=20 >> _______________________________________________ >> vot mailing list >> vot@ietf.org >> https://www.ietf.org/mailman/listinfo/vot >>=20 >> _______________________________________________ >> vot mailing list >> vot@ietf.org >> https://www.ietf.org/mailman/listinfo/vot >>=20 >>=20 >> _______________________________________________ >> vot mailing list >> vot@ietf.org >> https://www.ietf.org/mailman/listinfo/vot >=20 >=20 >=20 >=20 > From: Ken Dagg > Subject: Re: [VoT] A modest proposal to replace LOA > Date: 10 January 2015 01:38:01 GMT > To: "Richer, Justin P." > Cc: Joni Brennan , "vot@ietf.org" = , Stephen Wilson >=20 >=20 > Justin, >=20 > IMO you have hit the nail on the head with those questions. At the end = of the day, it is the RP's decision because, IMO, it is ultimately the = RP that bears the consequences of something going wrong. >=20 > The interesting direction taken in the GC approach is the RP decides, = based upon the GC standard and its supporting guidance, on their risk = tolerance and categorizes it into a LOA bucket. The standard and = guidance then identifies, based on that categorization, what the RP = needs to do to mitigate that risk. Part of that mitigation could include = accepting assertions from external organizations, such as authoritative = parties, who provide assertions about something. It does not presume = that any authoritative party will provide the "total" assertion. An = important part of the standard is that it does not specify specific = authoritative sources. Rather, it identifies what types of sources and = how many of those sources should be used. >=20 > In this context, the answers to Steve's questions are, IMO, rather = simple: > - What is something like LOA really for? [[KD: IMO: LOAs are a simple = means of communicating / characterizing a RP's identity assurance risk = tolerance. =46rom an IdP's perspective, it is a mechanism for = specifying/communicating what mechanisms they have undertaken.]] > - Who uses a simplified "Risk Gauge", and how exactly? [[see above]] > - How much original risk analysis is an RP expected to do before they = bin their situation into Risk Gauge [[KD: IMO a RP should not do any = "original" risk analysis beyond the risk analysis they currently do to = identify the risk of something going wrong based on an incorrect = identity. It should be noted, the GC does not take into account the = probability of something going wrong - they assume it is going to go = wrong and identify the consequences of that happening.]] > - Is using a Risk Gauge supposed to save time in risk analysis? [[KD: = No. Risk analysis still takes the same amount of time. And it still = must be done.]] > - When an IdP claims a certain Risk Gauge, what does that really mean = - contractually? [[KD: IMO, it means that if an IdP can be shown not to = have done everything that is specified to provide an assertion then they = are liable for all damages. Otherwise, the RP is liable.]] > - If an RP at Gauge X finds an IdP at Gauge X (or higher), what's = next? How much further analysis is needed before the RP can sign up the = IdP? [[KD: no further analysis should be required if the RP can trust = that the IdP is telling the truth. An independent certification by an = organization such as Kantara Initiative could provide that assurance. = That being said, the RP should NOT be expected to use that assertion as = the only thing required to mitigate their identity assurance risk. The = RP needs to be in control of how much they need to do.]] > - If an IdP claims Risk Gauge X, how is that assured? [[KD: as I said = above, a certification by an independent third party could provide = assurance to a RP.]] >=20 > What is important, IMO, about the Government of Canada's approach is = that they have looked at the whole situation from the RP's perspective = ... =46rom the RP being in control of their destiny. It is their problem = if something goes wrong. That, and they assume something will go wrong = without taking into account the probability of it occuring - it is of = little comfort to users to have an RP say, after a break, "we considered = that risk but did not think it was too likely to occur." >=20 > Ken >=20 > On Friday, January 9, 2015, Richer, Justin P. = wrote: > To me, a lot of it comes down to helping the RPs answer one question: >=20 > "Someone just logged in. Now what?" >=20 > I think that binning risk is part of the issue (as Steve states), but = it's also (as a corollary) a matter of setting the context of an = authentication. It's not just about "do I trust the display name" or = whatever other attribute, but also about communicating to the RP what = just happened. This can give the RP a chance at correctly deciding what = to do about it. >=20 > There are really two parts of the whole conversation that I think = getting wound up in each other: > - Things the RP needs to know about the IdP (i.e.: do I trust this = IdP? what risk do I have in doing so?) > - Things the RP needs to know about the authentication transaction = (i.e.: do I trust this log in?) >=20 > The VoT proposal tries to address this with the two different parts of = the protocol: the vector as conveyed by the protocol, and the "trust = mark provider" discovery portion. >=20 > To me, everything else is an aspect of answering these fundamental = questions. >=20 > -- Justin >=20 > On Jan 9, 2015, at 5:26 PM, Joni Brennan = wrote: >=20 >> +1 to the suggestions so far and the comments around defining = objectives. =20 >>=20 >> Apologies if this comment has already been made. It may also be of = use to pop up in the stack as well regarding objectives. One layer = abstraction removed from Steve's well pointed examples... I don't = believe we need specific architecture for each but rather simply to be = aware of the varying communities / priorities.=20 >> =20 >> LoAs (or something like VoTs)=20 >> - Security >> - Risk Management >> - Interoperability (policy and tech)=20 >> - Commercial (regulated / non) >> - Government (public service - and what is a public services varies = nationally) >>=20 >> Best Regards, >>=20 >> Joni Brennan >> Kantara Initiative | Executive Director >> email: joni @ kantarainitiative.org >>=20 >> Connecting Identity for a more trustworthy Internet - Overview >>=20 >>=20 >>=20 >>=20 >> On Fri, Jan 9, 2015 at 2:19 PM, wrote: >> =20 >> If we're going to improve upon LOAs, then may I suggest the first = thing to do is set out the objectives?=20 >> =20 >> - What is something like LOA really for?=20 >> - Who uses a simplified "Risk Gauge", and how exactly?=20 >> - How much original risk analysis is an RP expected to do before they = bin their situation into Risk Gauge >> - Is using a Risk Gauge supposed to save time in risk analysis? >> - When an IdP claims a certain Risk Gauge, what does that really mean = - contractually? >> - If an RP at Gauge X finds an IdP at Gauge X (or higher), what's = next? How much further analysis is needed before the RP can sign up the = IdP?=20 >> - If an IdP claims Risk Gauge X, how is that assured? >> =20 >> I suggest that LOAs were intended, net-net, to save time. It was = thought that by binning risk, RPs would be able to short list and then = contract with suitable IdPs more quickly. If there is any time saved in = using LOAs then I suspect it gets gobbled up by the negotiating the fine = print when signing up an IdP. The very fact that RPs have asked for = "LOA 2 and a half" tells us that the RP-IdP negotiation tends to be = customised. Than it, LOAs are difficult to standardise.=20 >> =20 >> Before we add dimensions, can we look at what its trying to achieve? >> =20 >> Cheers,=20 >> =20 >> Steve. >> =20 >>=20 >> Stephen Wilson >> Lockstep Group=20 >> http://lockstep.com.au >> Lockstep Consulting provides independent specialist advice and = analysis=20 >> on digital identity and privacy. Lockstep Technologies develops = unique=20 >> new smart ID solutions that enhance privacy and prevent identity = theft. >> =20 >> =20 >> =20 >> -----Original Message----- >> From: "Jim Fenton" >> Sent: Saturday, 10 January, 2015 7:49am >> To: vot@ietf.org >> Subject: [VoT] A modest proposal to replace LOA >>=20 >> I posted some ideas yesterday on a somewhat constrained possible >> replacement for Levels of Assurance: >>=20 >> = https://altmode.wordpress.com/2015/01/08/level-of-assurance-alternatives-a= -modest-proposal/ >>=20 >> tl;dr: One dimension (LOA) isn't enough, but we don't want too many >> dimensions or levels because that gets unwieldy. I'm proposing 3 = levels >> each of two dimensions: Level of Strength (authentication) and Level = of >> Reliability (attribute binding/proofing). >>=20 >> Any thoughts would be appreciated. >>=20 >> -Jim >>=20 >> _______________________________________________ >> vot mailing list >> vot@ietf.org >> https://www.ietf.org/mailman/listinfo/vot >>=20 >> _______________________________________________ >> vot mailing list >> vot@ietf.org >> https://www.ietf.org/mailman/listinfo/vot >>=20 >>=20 >> _______________________________________________ >> vot mailing list >> vot@ietf.org >> https://www.ietf.org/mailman/listinfo/vot >=20 >=20 >=20 > _______________________________________________ > vot mailing list > vot@ietf.org > https://www.ietf.org/mailman/listinfo/vot --Apple-Mail=_A6614B90-5829-4377-9521-B0CC0F972BBD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 This = thread raises several important topics=85 just as a practical matter, it = might be worth trying to spin some of them off separately, so that we = address them all, and minimise the risk of talking at cross-purposes. =  
It feels like it would be worth = trying to put together some *very short* straw-man docs/pages/paragraphs = to try and get a consensus version on specific points, so that we avoid = re-hashing the same arguments/discussions over time, or at least have = something we can refer to - and amend if necessary. I think this is = aiming at the same end-point as Steve=92s request for a statement of = requirements, but will ensure we=92re expressing our requirements in a = consistent set of terms.

By the looks of it, these would = make for a good starting point (I think the answers to most of these are = implicit in various people=92s contributions to the thread=85 but that = doesn=92t mean everyone agrees ;^)  ):

1 - what do we mean by = authentication and authorisation? Are there other decisions (e.g. access = control, entitlement) which need to be called out explicitly? This = reflects the purpose of Justin=92s questions. Classically, the reason = for authenticating a user is to answer a yes/no question (is this the = person to whom this credential was originally issued); if yes, what do I = want to do about it (at which point the further entitlements are usually = determined by retrieving a user profile, ACL or = whatever)?
However, as we know, these days = access control and entitlement decisions also need to be made on the = basis of input other than classic credentials, and that=92s one of the = two cores of this discussion, I believe.

2 - what=92s the classic = lifecycle of a credential - i.e. a artefact intended to provide evidence = in support of an assertion of identity. (e.g. = registration/verification/enrolment, credential issue, credential = presentation/authentication, credential = amendment/revocation/destruction=85)? 

3 - How does (2) relate to = other assertions (e.g. attribute assertions) we would like to make = reliably?

With = that starter set, I think we can confirm the subset of requirements that = 800-63-1 still meets, and define the delta that requires new = design.

4 - What=92s the right way to update = current thinking on LOAs, to account for the change Jim describes in his = proposal - i.e., the case where "credentials = (used in authentication) and attribute information (established through = identity proofing) could be provided by different parties.=94
5 - =46rom Jim=92s proposal: =93Attribute reliability refers to the quality of the identity = proofing process, as well as the strength of the binding of the = identifying attributes to the authentication.=94 Do we need/want = to expand on this a little? This seems to cater well for the case where, = say, vehicle entitlements are being established so that they can be = encapsulated in a driving licence. It=92s not so clear how this = addresses, say, third party assertions that do not arise from an = identity proofing process - =93I have no idea *who* this user is, but I = can reliably assert the following about them: ... =94.

I think this might make it easier for = us to put Steve=92s requirements analysis and Ken=92s liability model = (which are both excellent, btw) into a shared conceptual framework, and = also reduce the effort required to explain VoT to other = stakeholders/contributors.

Hope this helps - 
R

Robin = Wilton
Technical Outreach Director - = Identity and Privacy
Internet Society

email: wilton@isoc.org
Phone: +44 705 = 005 2931
Twitter: @futureidentity

On 10 Jan 2015, at 01:38, vot-request@ietf.org = wrote:

Send vot mailing list submissions to
vot@ietf.org

To subscribe or = unsubscribe via the World Wide Web, visit
= https://www.ietf.org/mailman/listinfo/vot
or, via email, send = a message with subject or body 'help' to
vot-request@ietf.org

You = can reach the person managing the list at
= vot-owner@ietf.org

When replying, please edit your Subject = line so it is more specific
than "Re: Contents of vot = digest..."
Today's Topics:

  1. Re: A modest = proposal to replace LOA (Richer, Justin P.)
  2. Re: A = modest proposal to replace LOA (Ken Dagg)

From: "Richer, Justin P." = <jricher@mitre.org>
Subject: Re: [VoT] A modest proposal to = replace LOA
Date: 9 = January 2015 22:59:56 GMT
To: Joni = Brennan <joni@kantarainitiative.org>
Cc: "vot@ietf.org" <vot@ietf.org>, = Stephen Wilson <swilson@lockstep.com.au>


To me, a lot of it comes down to helping the RPs answer one question:

"Someone just logged in. Now what?"

I think that binning risk is part of the issue (as Steve states), = but it's also (as a corollary) a matter of setting the context of an = authentication. It's not just about "do I trust the display name" or = whatever other attribute, but also about communicating to the RP what just happened. This can give the RP a chance at = correctly deciding what to do about it.

There are really two parts of the whole conversation that I think = getting wound up in each other:
 - Things the RP needs to know about the IdP (i.e.: do I trust = this IdP? what risk do I have in doing so?)
 - Things the RP needs to know about the authentication = transaction (i.e.: do I trust this log in?)

The VoT proposal tries to address this with the two different parts = of the protocol: the vector as conveyed by the protocol, and the "trust = mark provider" discovery portion.

To me, everything else is an aspect of answering these fundamental = questions.

 -- Justin

On Jan 9, 2015, at 5:26 PM, Joni Brennan <joni@kantarainitiative.org&= gt; wrote:

+1 to the suggestions so far and the comments around = defining objectives.  

Apologies if this comment has already been made.  It may also = be of use to pop up in the stack as well regarding objectives.  One = layer abstraction removed from Steve's well pointed examples... I don't = believe we need specific architecture for each but rather simply to be aware of the varying communities / = priorities. 
  
LoAs (or something like VoTs) 
- Security
- Risk Management
- Interoperability (policy and tech) 
- Commercial (regulated / non)
- Government (public service - and what is a public services varies = nationally)

Best Regards,

Joni Brennan
Kantara Initiative | Executive Director
email: joni @ kantarainitiative.org

Connecting Identity for a more trustworthy Internet - Overview




On Fri, Jan 9, 2015 at 2:19 PM, <swilson@lockstep.com.au> wrote:

 

If we're going to improve upon LOAs, then may I suggest the first thing = to do is set out the objectives? 

 

- What is something like LOA really for? 
- Who uses a simplified "Risk Gauge", and how exactly? 
- How much original risk analysis is an RP expected to do before they = bin their situation into Risk Gauge
- Is using a Risk Gauge supposed to save time in risk analysis?
- When an IdP claims a certain Risk Gauge, what does that really mean - = contractually?
- If an RP at Gauge X finds an IdP at Gauge X (or higher), what's next? = How much further analysis is needed before the RP can sign up the = IdP? 
- If an IdP claims Risk Gauge X, how is that assured?

 

I suggest that LOAs were intended, net-net, to save time.  It was = thought that by binning risk, RPs would be able to short list and then = contract with suitable IdPs more quickly.  If there is any time = saved in using LOAs then I suspect it gets gobbled up by the negotiating the fine print when signing up an IdP.  The very = fact that RPs have asked for "LOA 2 and a half" tells us that the RP-IdP = negotiation tends to be customised.  Than it, LOAs are difficult to = standardise. 

 

Before we add dimensions, can we look at what its trying to = achieve?

 

Cheers, 

 

Steve.

 


Stephen Wilson
Lockstep Group 
http://lockstep.com.au
Lockstep Consulting provides independent specialist advice and analysis =
on digital identity and privacy.  Lockstep Technologies develops = unique
new smart ID solutions that enhance privacy and prevent identity = theft.
 

 

 

-----Original Message-----
From: "Jim Fenton" <fenton@bluepopcorn.net>
Sent: Saturday, 10 January, 2015 7:49am
To: vot@ietf.org
= Subject: [VoT] A modest proposal to replace LOA

I posted some ideas yesterday on a somewhat constrained possible
replacement for Levels of Assurance:

https://altmode.wordpress.com/2015/01/08/level-of-assura= nce-alternatives-a-modest-proposal/

tl;dr: One dimension (LOA) isn't enough, but we don't want too many
dimensions or levels because that gets unwieldy. I'm proposing 3 = levels
each of two dimensions: Level of Strength (authentication) and Level = of
Reliability (attribute binding/proofing).

Any thoughts would be appreciated.

-Jim

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

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


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




From: Ken = Dagg <kendaggtbs@gmail.com>
Subject: Re: [VoT] A modest proposal to = replace LOA
Date: 10 = January 2015 01:38:01 GMT
To: "Richer,= Justin P." <jricher@mitre.org>
Cc: Joni Brennan = <joni@kantarainitiative.org>, "vot@ietf.org" <vot@ietf.org>, = Stephen Wilson = <swilson@lockstep.com.au>


Justin,

IMO you have hit the nail on = the head with those questions. At the end of the day, it is the RP's = decision because, IMO, it is ultimately the RP that bears the = consequences of something going wrong.

The = interesting direction taken in the GC approach is the RP decides, based = upon the GC standard and its supporting guidance, on their risk = tolerance and categorizes it into a LOA bucket. The standard and = guidance then identifies, based on that categorization, what the RP = needs to do to mitigate that risk. Part of that mitigation could include = accepting assertions from external organizations, such as = authoritative parties, who provide assertions about something. It = does not presume that any authoritative party will provide the "total" = assertion. An important part of the standard is that it does = not specify specific authoritative sources. Rather, it = identifies what types of sources and how many of those sources = should be used.

In this context, the = answers to Steve's questions are, IMO, rather simple:
- What is = something like LOA really for? [[KD: IMO: LOAs are a simple means of = communicating / characterizing a RP's identity assurance risk tolerance. = =46rom an IdP's perspective, it is a mechanism for = specifying/communicating what mechanisms they have = undertaken.]]
- Who = uses a simplified "Risk Gauge", and how exactly? [[see = above]]
- How = much original risk analysis is an RP expected to do before they bin = their situation into Risk Gauge [[KD: IMO a RP should not do any = "original" risk analysis beyond the risk analysis they currently do to = identify the risk of something going wrong based on an incorrect = identity. It should be noted, the GC does not take into account the = probability of something going wrong - they assume it is going to go = wrong and identify the consequences of that = happening.]]
- Is = using a Risk Gauge supposed to save time in risk analysis? [[KD: No. = Risk analysis still takes the same  amount of time. And it still = must be done.]]
- When an IdP claims a = certain Risk Gauge, what does that really mean - contractually? [[KD: = IMO, it means that if an IdP can be shown not to have done everything = that is specified to provide an assertion then they are = liable for all damages. Otherwise, the RP is = liable.]]
- If = an RP at Gauge X finds an IdP at Gauge X (or higher), what's next? How = much further analysis is needed before the RP can sign up the IdP? [[KD: = no further analysis should be required if the RP can trust that the = IdP is telling the truth. An independent certification by an = organization such as Kantara Initiative could provide that assurance. = That being said, the RP should NOT be expected to use that assertion as = the only thing required to mitigate their identity assurance risk. The = RP needs to be in control of how much they need to = do.]]
- If an = IdP claims Risk Gauge X, how is that assured? [[KD: as I said above, a = certification by an independent third party could provide = assurance to a RP.]]

=
What is = important, IMO, about the Government of Canada's approach is that = they have looked at the whole situation from the RP's perspective = ... =46rom the RP being in control of their destiny. It is their problem = if something goes wrong. That, and they assume something will go wrong = without taking into account the probability of it occuring - it is of = little comfort to users to have an RP say, after a break, "we considered = that risk but did not think it was too likely to = occur."

=
Ken<= /div>

On Friday, January 9, 2015, Richer, Justin P. <jricher@mitre.org> = wrote:
To me, a lot of it comes down to helping the RPs answer one question:

"Someone just logged in. Now what?"

I think that binning risk is part of the issue (as Steve states), = but it's also (as a corollary) a matter of setting the context of an = authentication. It's not just about "do I trust the display name" or = whatever other attribute, but also about communicating to the RP what just happened. This can give the RP a chance at = correctly deciding what to do about it.

There are really two parts of the whole conversation that I think = getting wound up in each other:
 - Things the RP needs to know about the IdP (i.e.: do I trust = this IdP? what risk do I have in doing so?)
 - Things the RP needs to know about the authentication = transaction (i.e.: do I trust this log in?)

The VoT proposal tries to address this with the two different parts = of the protocol: the vector as conveyed by the protocol, and the "trust = mark provider" discovery portion.

To me, everything else is an aspect of answering these fundamental = questions.

 -- Justin

On Jan 9, 2015, at 5:26 PM, Joni Brennan <joni@kantarainitiative.org> wrote:

+1 to the suggestions so far and the comments around = defining objectives.  

Apologies if this comment has already been made.  It may also = be of use to pop up in the stack as well regarding objectives.  One = layer abstraction removed from Steve's well pointed examples... I don't = believe we need specific architecture for each but rather simply to be aware of the varying communities / = priorities. 
  
LoAs (or something like VoTs) 
- Security
- Risk Management
- Interoperability (policy and tech) 
- Commercial (regulated / non)
- Government (public service - and what is a public services varies = nationally)

Best Regards,

Joni Brennan
Kantara Initiative | Executive Director
email: joni @ kantarainitiative.org

Connecting Identity for a more trustworthy Internet - Overview




On Fri, Jan 9, 2015 at 2:19 PM, <swilson@lockstep.com.au> wrote:

 

If we're going to improve upon LOAs, then may I suggest the first thing = to do is set out the objectives? 

 

- What is something like LOA really for? 
- Who uses a simplified "Risk Gauge", and how exactly? 
- How much original risk analysis is an RP expected to do before they = bin their situation into Risk Gauge
- Is using a Risk Gauge supposed to save time in risk analysis?
- When an IdP claims a certain Risk Gauge, what does that really mean - = contractually?
- If an RP at Gauge X finds an IdP at Gauge X (or higher), what's next? = How much further analysis is needed before the RP can sign up the = IdP? 
- If an IdP claims Risk Gauge X, how is that assured?

 

I suggest that LOAs were intended, net-net, to save time.  It was = thought that by binning risk, RPs would be able to short list and then = contract with suitable IdPs more quickly.  If there is any time = saved in using LOAs then I suspect it gets gobbled up by the negotiating the fine print when signing up an IdP.  The very = fact that RPs have asked for "LOA 2 and a half" tells us that the RP-IdP = negotiation tends to be customised.  Than it, LOAs are difficult to = standardise. 

 

Before we add dimensions, can we look at what its trying to = achieve?

 

Cheers, 

 

Steve.

 


Stephen Wilson
Lockstep Group 
http://lockstep.com.au
Lockstep Consulting provides independent specialist advice and analysis =
on digital identity and privacy.  Lockstep Technologies develops = unique
new smart ID solutions that enhance privacy and prevent identity = theft.
 

 

 

-----Original Message-----
From: "Jim Fenton" <fenton@bluepopcorn.net>
Sent: Saturday, 10 January, 2015 7:49am
To: vot@ietf.org
Subject: [VoT] A modest proposal to replace LOA

I posted some ideas yesterday on a somewhat constrained possible
replacement for Levels of Assurance:

https://altmode.wordpress.com/2015/01/08/level-of-assura= nce-alternatives-a-modest-proposal/

tl;dr: One dimension (LOA) isn't enough, but we don't want too many
dimensions or levels because that gets unwieldy. I'm proposing 3 = levels
each of two dimensions: Level of Strength (authentication) and Level = of
Reliability (attribute binding/proofing).

Any thoughts would be appreciated.

-Jim

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

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


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



_______________________________________________
vot mailing = list
vot@ietf.org
https://www.ietf.org/mailman/listinfo/vot

= --Apple-Mail=_A6614B90-5829-4377-9521-B0CC0F972BBD-- --Apple-Mail=_918B9DEF-70FC-4755-BD21-B8B2CD42F80D 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----- iEYEARECAAYFAlSz1WcACgkQx1kEWLxmyT3E3gCdGA3aW4nUrqIcWDmP0iBCmHQl T38An2GvPSJjYYYhDxB89SbgwhutROPa =IA7a -----END PGP SIGNATURE----- --Apple-Mail=_918B9DEF-70FC-4755-BD21-B8B2CD42F80D-- From nobody Mon Jan 12 13:20:48 2015 Return-Path: X-Original-To: vot@ietfa.amsl.com Delivered-To: vot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DE6F1A6FFC for ; Mon, 12 Jan 2015 13:20:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 04yLpfG99EnH for ; Mon, 12 Jan 2015 13:20:44 -0800 (PST) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10E7E1A6FD5 for ; Mon, 12 Jan 2015 13:20:44 -0800 (PST) Received: from splunge.local ([12.250.97.26]) (authenticated bits=0) by v2.bluepopcorn.net (8.14.3/8.14.3/Debian-9.4) with ESMTP id t0CLKfYC013545 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 12 Jan 2015 13:20:43 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1421097643; bh=c9hxVp2yauQxonfb+HngQM4O7qTRig4mWdUZwLEzuyM=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=PWQuKLqBsoIaXRgPaoPoQOq9uEuKpqZLsia9978Sghb0dC971qp8KnLGnNhJag394 q4m9xSfqgshUBxyiyfaPY93KJ3OtZO9PyJFGcpH/i28UQB6E4fM2jMUXID/PaKw6I2 QKr1honh7olMrUONSVtg688tV8HNu4H7s+qNLtFw= Message-ID: <54B43AA4.3030005@bluepopcorn.net> Date: Mon, 12 Jan 2015 13:20:36 -0800 From: Jim Fenton User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "Jones, Mark B" , "vot@ietf.org" References: <54B03EE4.3060909@bluepopcorn.net> <38AAF00EA635514CA6667ACA60C7F0A53153A573@UTHMAIL1.uthouston.edu> In-Reply-To: <38AAF00EA635514CA6667ACA60C7F0A53153A573@UTHMAIL1.uthouston.edu> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [VoT] A modest proposal to replace LOA X-BeenThere: vot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Vectors of Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2015 21:20:46 -0000 Mark, On 1/11/15 6:23 PM, Jones, Mark B wrote: > It is my opinion that the levels of assurance in 800-63 are meant to > describe specific sets of threats that should be addressed at specific,= > common risk levels and to describe how to mitigate those threats. It i= s not > clear what specific threats your proposed levels are meant to address. = (I > think the VoT discussion in general is also lacking in references to wh= at > specific threats are meant to be addressed by specific vectors.) You're right, what I wrote doesn't address specific threats at all. But before doing that, a structure is needed -- that's what I was trying to address in my proposal. Similarly, M-04-04, the OMB specification that 800-63 responds to, doesn't address specific threats. If this (or any other) structure looks promising, it will need to be fleshed out in a document like 800-63 with specific requirements at each level, and an analysis of what threats are addressed at each. > > Though 800-63 has language that talks about including verified attribut= es in > credentials and assertions it makes it clear that inclusion of attribut= es is > optional. I feel that 800-63 works just fine in a model where > authentication and attribute providers are separate because it does not= > specify any limits on how attributes can be communicated. It is my opi= nion > that 'authentication' and the communication of attributes must be > conceptualized as very separate processes and that your concept of > "Attribute Reliability" inappropriately conflates 'Registration and > Credential Issuance' with attribute assertions. The threats associated= with > inappropriate registration and credential issuance are very different f= rom > those associated with receiving inaccurate attribute assertions. Perhaps the disconnect here is what is included in the definition of "attributes" -- I include identifying attributes (name, address, etc.) as attributes, while others focus on descriptive attributes (student at some school, veteran status, employment, etc.). Yes, the threats associated with credential issuance, etc. are different from those associated with receiving inaccurate assertions, but the end result is the same: the transaction is in error. At this level of abstraction, I'm focused on the result, not (yet) the threats that we need to prevent. Believe me, I'm not forgetting that. > > Though some have reasonable arguments for assigning levels of assurance= to > attributes, I believe that relying parties must trust 'attribute provid= ers' > as opposed to trusting specific attribute assertions. It is my opinion= that > relying parties should only request attributes from providers they cons= ider > to be (or accept as) authoritative for the attributes requested. So in= my > view attributes have little to do with LOA discussion. But there may be circumstances where attribute providers have different levels of confidence (do differing levels of diligence) on attributes and therefore may need to assert something at a lower level of trust than they hold. There may also be business drivers, such as attribute providers charging more for higher-confidence assertions. > > In summary I feel that any scheme for expressing LOA needs to describe = the > threats that are mitigated, the strength of those mitigations, and trus= t of > authentication should be kept separate from trust of attribute assertio= ns. > After all, authentication establishes trust in the PERSON on the other = end > of a transaction while trust in an attribute assertion represents trust= in > the PROVIDER to collect and assert good attributes. =20 Agree, we will need to describe the threats, but we need to agree on a direction first. -Jim From nobody Mon Jan 12 13:45:08 2015 Return-Path: X-Original-To: vot@ietfa.amsl.com Delivered-To: vot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD2A21A6FD5 for ; Mon, 12 Jan 2015 13:45:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 Pw2xFAxTCxzc for ; Mon, 12 Jan 2015 13:45:03 -0800 (PST) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 598AE1A6F0A for ; Mon, 12 Jan 2015 13:45:03 -0800 (PST) Received: from splunge.local ([12.250.97.26]) (authenticated bits=0) by v2.bluepopcorn.net (8.14.3/8.14.3/Debian-9.4) with ESMTP id t0CLj1af013741 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 12 Jan 2015 13:45:03 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1421099103; bh=9hUGPDF+PNf/2DJaMoUk5fFV0BHNwB7NwFi1JzOpKyI=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type; b=I4QCznqNj70TWS28iIV25L92eZcXEeBFcHC08jfTerglOoej6REDIyvoR3zc22/Ep TchsH6HXYfLxajveUvOIA6Gew5N7NH1oOemQtYvAOzUVZANEbo+sWRCQBx+PuczJuh sJClNqzJErF+U01UmIXnG3UrhUm2TOKpWZDDt/b8= Message-ID: <54B44058.8080407@bluepopcorn.net> Date: Mon, 12 Jan 2015 13:44:56 -0800 From: Jim Fenton User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Robin Wilton , "vot@ietf.org" References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------000103060705040105010504" Archived-At: Subject: Re: [VoT] vot Digest, Vol 5, Issue 2 X-BeenThere: vot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Vectors of Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2015 21:45:06 -0000 This is a multi-part message in MIME format. --------------000103060705040105010504 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Maybe I should be breaking these apart as Robin suggests, but for now I'll keep this in one reply: On 1/12/15 6:06 AM, Robin Wilton wrote: > This thread raises several important topics=85 just as a practical > matter, it might be worth trying to spin some of them off separately, > so that we address them all, and minimise the risk of talking at > cross-purposes. =20 > It feels like it would be worth trying to put together some *very > short* straw-man docs/pages/paragraphs to try and get a consensus > version on specific points, so that we avoid re-hashing the same > arguments/discussions over time, or at least have something we can > refer to - and amend if necessary. I think this is aiming at the same > end-point as Steve=92s request for a statement of requirements, but wil= l > ensure we=92re expressing our requirements in a consistent set of terms= =2E > > By the looks of it, these would make for a good starting point (I > think the answers to most of these are implicit in various people=92s > contributions to the thread=85 but that doesn=92t mean everyone agrees = ;^) ): > > 1 - what do we mean by authentication and authorisation? Are there > other decisions (e.g. access control, entitlement) which need to be > called out explicitly? This reflects the purpose of Justin=92s > questions. Classically, the reason for authenticating a user is to > answer a yes/no question (is this the person to whom this credential > was originally issued); if yes, what do I want to do about it (at > which point the further entitlements are usually determined by > retrieving a user profile, ACL or whatever)? Access control and entitlement as distinct from authorisation? Is there a distinction, or are people just using different terminology? I think of authentication as providing more than a yes/no answer: it provides an identifier. If the relying party has enough information (perhaps on the basis of previous interactions) to authorize something with just that, fine. Otherwise some attributes are needed to make an authorisation decision. > However, as we know, these days access control and entitlement > decisions also need to be made on the basis of input other than > classic credentials, and that=92s one of the two cores of this > discussion, I believe. Example of an "input other than classic credentials"? > > 2 - what=92s the classic lifecycle of a credential - i.e. a artefact > intended to provide evidence in support of an assertion of identity. > (e.g. registration/verification/enrolment, credential issue, > credential presentation/authentication, credential > amendment/revocation/destruction=85)? Credential is another of those tricky words. Sometimes it means the same as an authentication token. Sometimes it has some attributes bound to it, which means it has both an authentication and attribute provision flavor to it. I find it simpler to talk about tokens, where one doesn't have to deal with revocation when some attribute (employment, for example) changes. > > 3 - How does (2) relate to other assertions (e.g. attribute > assertions) we would like to make reliably? > > With that starter set, I think we can confirm the subset of > requirements that 800-63-1 still meets, and define the delta that > requires new design. > > 4 - What=92s the right way to update current thinking on LOAs, to > account for the change Jim describes in his proposal - i.e., the case > where "credentials (used in authentication) and attribute information > (established through identity proofing) could be provided by different > parties.=94 > > 5 - From Jim=92s proposal: =93Attribute reliability refers to the quali= ty > of the identity proofing process, as well as the strength of the > binding of the identifying attributes to the authentication.=94 Do we > need/want to expand on this a little? This seems to cater well for the > case where, say, vehicle entitlements are being established so that > they can be encapsulated in a driving licence. It=92s not so clear how > this addresses, say, third party assertions that do not arise from an > identity proofing process - =93I have no idea *who* this user is, but I= > can reliably assert the following about them: ... =94. You're right; that will need to be defined. But it should be possible to define analogous requirements to describe the strength of the binding to the token. When you show up to enroll at school, it should be possible to use your token to allow your school to make LOR 3 asserts that you're there student. But maybe remote students only get LOR 2? -Jim --------------000103060705040105010504 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Maybe I should be breaking these apart as Robin suggests, but for now I'll keep this in one reply:

On 1/12/15 6:06 AM, Robin Wilton wrote:
This thread raises several important topics… just as a practical matter, it might be worth trying to spin some of them off separately, so that we address them all, and minimise the risk of talking at cross-purposes.  
It feels like it would be worth trying to put together some *very short* straw-man docs/pages/paragraphs to try and get a consensus version on specific points, so that we avoid re-hashing the same arguments/discussions over time, or at least have something we can refer to - and amend if necessary. I think this is aiming at the same end-point as Steve’s request for a statement of requirements, but will ensure we’re expressing our requirements in a consistent set of terms.

By the looks of it, these would make for a good starting point (I think the answers to most of these are implicit in various people’s contributions to the thread… but that doesn’t mean everyone agrees ;^)  ):

1 - what do we mean by authentication and authorisation? Are there other decisions (e.g. access control, entitlement) which need to be called out explicitly? This reflects the purpose of Justin’s questions. Classically, the reason for authenticating a user is to answer a yes/no question (is this the person to whom this credential was originally issued); if yes, what do I want to do about it (at which point the further entitlements are usually determined by retrieving a user profile, ACL or whatever)?

Access control and entitlement as distinct from authorisation? Is there a distinction, or are people just using different terminology?

I think of authentication as providing more than a yes/no answer: it provides an identifier. If the relying party has enough information (perhaps on the basis of previous interactions) to authorize something with just that, fine. Otherwise some attributes are needed to make an authorisation decision.

However, as we know, these days access control and entitlement decisions also need to be made on the basis of input other than classic credentials, and that’s one of the two cores of this discussion, I believe.

Example of an "input other than classic credentials"?


2 - what’s the classic lifecycle of a credential - i.e. a artefact intended to provide evidence in support of an assertion of identity. (e.g. registration/verification/enrolment, credential issue, credential presentation/authentication, credential amendment/revocation/destruction…)?

Credential is another of those tricky words. Sometimes it means the same as an authentication token. Sometimes it has some attributes bound to it, which means it has both an authentication and attribute provision flavor to it. I find it simpler to talk about tokens, where one doesn't have to deal with revocation when some attribute (employment, for example) changes.

3 - How does (2) relate to other assertions (e.g. attribute assertions) we would like to make reliably?

With that starter set, I think we can confirm the subset of requirements that 800-63-1 still meets, and define the delta that requires new design.

4 - What’s the right way to update current thinking on LOAs, to account for the change Jim describes in his proposal - i.e., the case where "credentials (used in authentication) and attribute information (established through identity proofing) could be provided by different parties.”

5 - From Jim’s proposal: “Attribute reliability refers to the quality of the identity proofing process, as well as the strength of the binding of the identifying attributes to the authentication.” Do we need/want to expand on this a little? This seems to cater well for the case where, say, vehicle entitlements are being established so that they can be encapsulated in a driving licence. It’s not so clear how this addresses, say, third party assertions that do not arise from an identity proofing process - “I have no idea *who* this user is, but I can reliably assert the following about them: ... ”.

You're right; that will need to be defined. But it should be possible to define analogous requirements to describe the strength of the binding to the token. When you show up to enroll at school, it should be possible to use your token to allow your school to make LOR 3 asserts that you're there student. But maybe remote students only get LOR 2?

-Jim

--------------000103060705040105010504-- From nobody Mon Jan 12 14:22:31 2015 Return-Path: X-Original-To: vot@ietfa.amsl.com Delivered-To: vot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12E3C1ACDEE for ; Mon, 12 Jan 2015 14:22:28 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, 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 HST9N5AP4kaA for ; Mon, 12 Jan 2015 14:22:20 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0087.outbound.protection.outlook.com [65.55.169.87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C5851ACDB7 for ; Mon, 12 Jan 2015 14:22:20 -0800 (PST) Received: from CO2PR0601MB0981.namprd06.prod.outlook.com (25.160.7.26) by CO2PR0601MB0920.namprd06.prod.outlook.com (10.141.248.28) with Microsoft SMTP Server (TLS) id 15.1.53.17; Mon, 12 Jan 2015 22:22:17 +0000 Received: from CO2PR0601MB0983.namprd06.prod.outlook.com (25.160.7.28) by CO2PR0601MB0981.namprd06.prod.outlook.com (25.160.7.26) with Microsoft SMTP Server (TLS) id 15.1.53.17; Mon, 12 Jan 2015 22:22:13 +0000 Received: from CO2PR0601MB0983.namprd06.prod.outlook.com ([25.160.7.28]) by CO2PR0601MB0983.namprd06.prod.outlook.com ([25.160.7.28]) with mapi id 15.01.0053.000; Mon, 12 Jan 2015 22:22:14 +0000 From: Robin Wilton To: Jim Fenton Thread-Topic: capturing the threads of the discussion Thread-Index: AQHQLrY3sEp+wHMzN02xqbjWxRWn8Q== Date: Mon, 12 Jan 2015 22:22:13 +0000 Message-ID: References: , <54B44058.8080407@bluepopcorn.net> In-Reply-To: <54B44058.8080407@bluepopcorn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [94.174.34.240] authentication-results: spf=none (sender IP is ) smtp.mailfrom=wilton@isoc.org; x-dmarcaction-test: None x-microsoft-antispam: BCL:0; PCL:0; RULEID:(3005003); SRVR:CO2PR0601MB0981; UriScan:; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:CO2PR0601MB0981; x-forefront-prvs: 0454444834 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(24454002)(189002)(479174004)(377454003)(199003)(86362001)(62966003)(46102003)(77156002)(66066001)(64706001)(102836002)(36756003)(2950100001)(2900100001)(101416001)(68736005)(33656002)(87936001)(16236675004)(105586002)(106356001)(19580395003)(19580405001)(99286002)(97736003)(122556002)(110136001)(106116001)(40100003)(54356999)(2656002)(82746002)(50986999)(92566002)(83716003)(76176999)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:CO2PR0601MB0981; H:CO2PR0601MB0983.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: isoc.org does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_B5801746AEB2493C87DA278069E80B18isocorg_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jan 2015 22:22:13.6458 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR0601MB0981 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:CO2PR0601MB0920; X-OriginatorOrg: isoc.org Archived-At: Cc: "vot@ietf.org" Subject: Re: [VoT] capturing the threads of the discussion X-BeenThere: vot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Vectors of Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2015 22:22:28 -0000 --_000_B5801746AEB2493C87DA278069E80B18isocorg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Jim, I won't give a substantive response here; just to note that I think it's wo= rth considering a repository so that we can capture 'static' versions of an= y straw-man docs, to complement what we it into the mail thread... Sorry to be brief at this stage - just tying up some loose ends before an a= bsence from the office. R Robin Wilton Technical Outreach Director - Identity and Privacy On 12 Jan 2015, at 21:45, "Jim Fenton" > wrote: Maybe I should be breaking these apart as Robin suggests, but for now I'll = keep this in one reply: On 1/12/15 6:06 AM, Robin Wilton wrote: This thread raises several important topics... just as a practical matter, = it might be worth trying to spin some of them off separately, so that we ad= dress them all, and minimise the risk of talking at cross-purposes. It feels like it would be worth trying to put together some *very short* st= raw-man docs/pages/paragraphs to try and get a consensus version on specifi= c points, so that we avoid re-hashing the same arguments/discussions over t= ime, or at least have something we can refer to - and amend if necessary. I= think this is aiming at the same end-point as Steve's request for a statem= ent of requirements, but will ensure we're expressing our requirements in a= consistent set of terms. By the looks of it, these would make for a good starting point (I think the= answers to most of these are implicit in various people's contributions to= the thread... but that doesn't mean everyone agrees ;^) ): 1 - what do we mean by authentication and authorisation? Are there other de= cisions (e.g. access control, entitlement) which need to be called out expl= icitly? This reflects the purpose of Justin's questions. Classically, the r= eason for authenticating a user is to answer a yes/no question (is this the= person to whom this credential was originally issued); if yes, what do I w= ant to do about it (at which point the further entitlements are usually det= ermined by retrieving a user profile, ACL or whatever)? Access control and entitlement as distinct from authorisation? Is there a d= istinction, or are people just using different terminology? I think of authentication as providing more than a yes/no answer: it provid= es an identifier. If the relying party has enough information (perhaps on t= he basis of previous interactions) to authorize something with just that, f= ine. Otherwise some attributes are needed to make an authorisation decision= . However, as we know, these days access control and entitlement decisions al= so need to be made on the basis of input other than classic credentials, an= d that's one of the two cores of this discussion, I believe. Example of an "input other than classic credentials"? 2 - what's the classic lifecycle of a credential - i.e. a artefact intended= to provide evidence in support of an assertion of identity. (e.g. registra= tion/verification/enrolment, credential issue, credential presentation/auth= entication, credential amendment/revocation/destruction...)? Credential is another of those tricky words. Sometimes it means the same as= an authentication token. Sometimes it has some attributes bound to it, whi= ch means it has both an authentication and attribute provision flavor to it= . I find it simpler to talk about tokens, where one doesn't have to deal wi= th revocation when some attribute (employment, for example) changes. 3 - How does (2) relate to other assertions (e.g. attribute assertions) we = would like to make reliably? With that starter set, I think we can confirm the subset of requirements th= at 800-63-1 still meets, and define the delta that requires new design. 4 - What's the right way to update current thinking on LOAs, to account for= the change Jim describes in his proposal - i.e., the case where "credentia= ls (used in authentication) and attribute information (established through = identity proofing) could be provided by different parties." 5 - From Jim's proposal: "Attribute reliability refers to the quality of th= e identity proofing process, as well as the strength of the binding of the = identifying attributes to the authentication." Do we need/want to expand on= this a little? This seems to cater well for the case where, say, vehicle e= ntitlements are being established so that they can be encapsulated in a dri= ving licence. It's not so clear how this addresses, say, third party assert= ions that do not arise from an identity proofing process - "I have no idea = *who* this user is, but I can reliably assert the following about them: ...= ". You're right; that will need to be defined. But it should be possible to de= fine analogous requirements to describe the strength of the binding to the = token. When you show up to enroll at school, it should be possible to use y= our token to allow your school to make LOR 3 asserts that you're there stud= ent. But maybe remote students only get LOR 2? -Jim --_000_B5801746AEB2493C87DA278069E80B18isocorg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Thanks Jim,

I won't give a substantive response here; just to note that I think it= 's worth considering a repository so that we can capture 'static' versions = of any straw-man docs, to complement what we it into the mail thread...

Sorry to be brief at this stage - just tying up some loose ends before= an absence from the office.

R

Robin Wilton

Technical Outreach Director - Identity and Privacy

On 12 Jan 2015, at 21:45, "Jim Fenton" <fenton@bluepopcorn.net> wrote:

Maybe I should be breaking these apart as Ro= bin suggests, but for now I'll keep this in one reply:

On 1/12/15 6:06 AM, Robin Wilton wrote:
This thread raises several important topics… just as a practical matt= er, it might be worth trying to spin some of them off separately, so that w= e address them all, and minimise the risk of talking at cross-purposes. &nb= sp;
It feels like it would be w= orth trying to put together some *very short* straw-man docs/pages/paragrap= hs to try and get a consensus version on specific points, so that we avoid re-hashing the same arguments/discussions over ti= me, or at least have something we can refer to - and amend if necessary. I = think this is aiming at the same end-point as Steve’s request for a s= tatement of requirements, but will ensure we’re expressing our requirements in a consistent set of terms.

By the looks of it, these would make for a good starting point (I think the a= nswers to most of these are implicit in various people’s contribution= s to the thread… but that doesn’t mean everyone agrees ;^) &nbs= p;):

1 - what do we mean by authentication and authorisation? Are there other dec= isions (e.g. access control, entitlement) which need to be called out expli= citly? This reflects the purpose of Justin’s questions. Classically, = the reason for authenticating a user is to answer a yes/no question (is this the person to whom this credential wa= s originally issued); if yes, what do I want to do about it (at which point= the further entitlements are usually determined by retrieving a user profi= le, ACL or whatever)?

Access control and entitlement as distinct from authorisation? Is there a d= istinction, or are people just using different terminology?

I think of authentication as providing more than a yes/no answer: it provid= es an identifier. If the relying party has enough information (perhaps on t= he basis of previous interactions) to authorize something with just that, f= ine. Otherwise some attributes are needed to make an authorisation decision.

However, as we know, these days access control and entitlement decisions also need = to be made on the basis of input other than classic credentials, and that&#= 8217;s one of the two cores of this discussion, I believe.

Example of an "input other than classic credentials"?


2 - what’s the classic lifecycle of a credential - i.e. a artefact int= ended to provide evidence in support of an assertion of identity. (e.g. reg= istration/verification/enrolment, credential issue, credential presentation= /authentication, credential amendment/revocation/destruction…)?

Credential is another of those tricky words. Sometimes it means the same as= an authentication token. Sometimes it has some attributes bound to it, whi= ch means it has both an authentication and attribute provision flavor to it= . I find it simpler to talk about tokens, where one doesn't have to deal with revocation when some attribute= (employment, for example) changes.

3 - How does (2) relate to other assertions (e.g. attribute assertions) we w= ould like to make reliably?

With t= hat starter set, I think we can confirm the subset of requirements that 800= -63-1 still meets, and define the delta that requires new design.

4 - Wh= at’s the right way to update current thinking on LOAs, to account for= the change Jim describes in his proposal - i.e., the case where "credentials (used in authentication) and attribute information (established through id= entity proofing) could be provided by different parties.”

5 - Fr= om Jim’s proposal: “Attri= bute reliability refers to the quality of the identity proofing process, as wel= l as the strength of the binding of the identifying attributes to the authe= ntication.” Do we need/want to expand on this a little? This s= eems to cater well for the case where, say, vehicle entitlements are being established so that they can be encaps= ulated in a driving licence. It’s not so clear how this addresses, sa= y, third party assertions that do not arise from an identity proofing proce= ss - “I have no idea *who* this user is, but I can reliably assert the following about them: ... ”.

You're right; that will need to be defined. But it should be possible to de= fine analogous requirements to describe the strength of the binding to the = token. When you show up to enroll at school, it should be possible to use y= our token to allow your school to make LOR 3 asserts that you're there student. But maybe remote students on= ly get LOR 2?

-Jim

--_000_B5801746AEB2493C87DA278069E80B18isocorg_-- From nobody Mon Jan 12 15:43:46 2015 Return-Path: X-Original-To: vot@ietfa.amsl.com Delivered-To: vot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1280B1ACE0F for ; Mon, 12 Jan 2015 15:43:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.402 X-Spam-Level: X-Spam-Status: No, score=0.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MANGLED_MARKET=2.3, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 cv8b8jYuLsxX for ; Mon, 12 Jan 2015 15:43:37 -0800 (PST) Received: from smtp.safecom.net.nz (smtp.safecom.net.nz [125.236.41.139]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29F761ACE0D for ; Mon, 12 Jan 2015 15:43:36 -0800 (PST) Received: from s111-0006-lnv01 (Not Verified[127.0.0.1]) by smtp.safecom.net.nz (using TLS: SSLv23) id ; Tue, 13 Jan 2015 12:39:37 +1300 Message-ID: <147EE18440E5AF44834B220ED35BA530D332445B@WLGPRDMBX01.dia.govt.nz> MIME-Version: 1.0 X-MessageIsInfected: false Received: from 161-65-142-21.ip.fx.net.nz (EHLO WLGPRDMM01.dia.govt.nz) ([127.0.0.1]) by s111-0006-lnv01 (JAMES SMTP Server ) with ESMTP ID 340151478; Tue, 13 Jan 2015 12:43:33 +1300 (NZDT) Received: from WLGPRDCAS02.dia.govt.nz (Not Verified[127.0.0.1]) by WLGPRDMM01.dia.govt.nz with MailMarshal (v7, 1, 1, 5205) (using TLS: SSLv23) id ; Tue, 13 Jan 2015 12:43:17 +1300 Received: from WLGPRDMBX01.dia.govt.nz ([fe80::13e:8e96:252b:e0d1]) by WLGPRDCAS02.dia.govt.nz ([127.0.0.1]) with mapi id 14.03.0146.000; Tue, 13 Jan 2015 12:43:33 +1300 From: Colin Wallis To: 'Robin Wilton' , Jim Fenton Thread-Topic: capturing the threads of the discussion Thread-Index: AQHQLrZFOKzNRWGFTEqiArzVnDNTzJy9ILqQ Date: Mon, 12 Jan 2015 23:43:15 +0000 References: , <54B44058.8080407@bluepopcorn.net> In-Reply-To: Accept-Language: en-US, en-NZ Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [172.29.0.162] Content-Type: multipart/mixed; boundary="_004_147EE18440E5AF44834B220ED35BA530D332445BWLGPRDMBX01diag_" X-sdp.mm2006: true Archived-At: Cc: "vot@ietf.org" Subject: Re: [VoT] capturing the threads of the discussion X-BeenThere: vot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Vectors of Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2015 23:43:43 -0000 --_004_147EE18440E5AF44834B220ED35BA530D332445BWLGPRDMBX01diag_ Content-Type: multipart/alternative; boundary="_000_147EE18440E5AF44834B220ED35BA530D332445BWLGPRDMBX01diag_" --_000_147EE18440E5AF44834B220ED35BA530D332445BWLGPRDMBX01diag_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Well as Steve O pointed out in this attached email in November, the wiki se= t up for this work might be a place to start.. There may be some jiggery pokery to get the folks on this list who want to = contribute (who were not attendees at Utrecht) access rights, but it would = seem to me to be the obvious starter option for a repository. Cheers Colin PS: BTW this is a good discussion and indeed an opportunistic time to bring= it together since so much of what Justin, Jim, Scott, Ken, Steve W, Mark e= t al have commented recently is complementary (well at least not completely= contradictory or orthogonal) so let's grab it! From: vot [mailto:vot-bounces@ietf.org] On Behalf Of Robin Wilton Sent: Tuesday, 13 January 2015 11:22 a.m. To: Jim Fenton Cc: vot@ietf.org Subject: Re: [VoT] capturing the threads of the discussion Thanks Jim, I won't give a substantive response here; just to note that I think it's wo= rth considering a repository so that we can capture 'static' versions of an= y straw-man docs, to complement what we it into the mail thread... Sorry to be brief at this stage - just tying up some loose ends before an a= bsence from the office. R Robin Wilton Technical Outreach Director - Identity and Privacy On 12 Jan 2015, at 21:45, "Jim Fenton" > wrote: Maybe I should be breaking these apart as Robin suggests, but for now I'll = keep this in one reply: On 1/12/15 6:06 AM, Robin Wilton wrote: This thread raises several important topics... just as a practical matter, = it might be worth trying to spin some of them off separately, so that we ad= dress them all, and minimise the risk of talking at cross-purposes. It feels like it would be worth trying to put together some *very short* st= raw-man docs/pages/paragraphs to try and get a consensus version on specifi= c points, so that we avoid re-hashing the same arguments/discussions over t= ime, or at least have something we can refer to - and amend if necessary. I= think this is aiming at the same end-point as Steve's request for a statem= ent of requirements, but will ensure we're expressing our requirements in a= consistent set of terms. By the looks of it, these would make for a good starting point (I think the= answers to most of these are implicit in various people's contributions to= the thread... but that doesn't mean everyone agrees ;^) ): 1 - what do we mean by authentication and authorisation? Are there other de= cisions (e.g. access control, entitlement) which need to be called out expl= icitly? This reflects the purpose of Justin's questions. Classically, the r= eason for authenticating a user is to answer a yes/no question (is this the= person to whom this credential was originally issued); if yes, what do I w= ant to do about it (at which point the further entitlements are usually det= ermined by retrieving a user profile, ACL or whatever)? Access control and entitlement as distinct from authorisation? Is there a d= istinction, or are people just using different terminology? I think of authentication as providing more than a yes/no answer: it provid= es an identifier. If the relying party has enough information (perhaps on t= he basis of previous interactions) to authorize something with just that, f= ine. Otherwise some attributes are needed to make an authorisation decision= . However, as we know, these days access control and entitlement decisions al= so need to be made on the basis of input other than classic credentials, an= d that's one of the two cores of this discussion, I believe. Example of an "input other than classic credentials"? 2 - what's the classic lifecycle of a credential - i.e. a artefact intended= to provide evidence in support of an assertion of identity. (e.g. registra= tion/verification/enrolment, credential issue, credential presentation/auth= entication, credential amendment/revocation/destruction...)? Credential is another of those tricky words. Sometimes it means the same as= an authentication token. Sometimes it has some attributes bound to it, whi= ch means it has both an authentication and attribute provision flavor to it= . I find it simpler to talk about tokens, where one doesn't have to deal wi= th revocation when some attribute (employment, for example) changes. 3 - How does (2) relate to other assertions (e.g. attribute assertions) we = would like to make reliably? With that starter set, I think we can confirm the subset of requirements th= at 800-63-1 still meets, and define the delta that requires new design. 4 - What's the right way to update current thinking on LOAs, to account for= the change Jim describes in his proposal - i.e., the case where "credentia= ls (used in authentication) and attribute information (established through = identity proofing) could be provided by different parties." 5 - From Jim's proposal: "Attribute reliability refers to the quality of th= e identity proofing process, as well as the strength of the binding of the = identifying attributes to the authentication." Do we need/want to expand on= this a little? This seems to cater well for the case where, say, vehicle e= ntitlements are being established so that they can be encapsulated in a dri= ving licence. It's not so clear how this addresses, say, third party assert= ions that do not arise from an identity proofing process - "I have no idea = *who* this user is, but I can reliably assert the following about them: ...= ". You're right; that will need to be defined. But it should be possible to de= fine analogous requirements to describe the strength of the binding to the = token. When you show up to enroll at school, it should be possible to use y= our token to allow your school to make LOR 3 asserts that you're there stud= ent. But maybe remote students only get LOR 2? -Jim --_000_147EE18440E5AF44834B220ED35BA530D332445BWLGPRDMBX01diag_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Well as Steve O pointed o= ut in this attached email in November, the wiki set up for this work might = be a place to start..

There may be some jiggery= pokery to get the folks on this list who want to contribute (who were not = attendees at Utrecht) access rights, but it would seem to me to be the obvious starter option for a repository.

Cheers<= /p>

Colin

PS: BTW this is a good discussion and indeed an opportunistic time to b= ring it together since so much of what Justin, Jim, Scott, Ken, Steve W, Mark et al have commented recently is complementary (well at= least not completely contradictory or orthogonal) so let’s grab it!

 <= /p>

From: vot [mailto:vot-bounces@ietf.org] On Behalf Of Robin Wilton
Sent: Tuesday, 13 January 2015 11:22 a.m.
To: Jim Fenton
Cc: vot@ietf.org
Subject: Re: [VoT] capturing the threads of the discussion

 

Thanks Jim,

 

I won't give a substantive response here; just to no= te that I think it's worth considering a repository so that we can capture = 'static' versions of any straw-man docs, to complement what we it into the = mail thread...

 

Sorry to be brief at this stage - just tying up some= loose ends before an absence from the office.

 

R

Robin Wilton

 

Technical Outreach Director - Identity and Privacy


On 12 Jan 2015, at 21:45, "Jim Fenton" <fenton@bluepopcorn.net> wrote:

Maybe I should be breaking these apart as Robin sugg= ests, but for now I'll keep this in one reply:

On 1/12/15 6:06 AM, Robin Wilton wrote:

This thread raises several important topics… j= ust as a practical matter, it might be worth trying to spin some of them of= f separately, so that we address them all, and minimise the risk of talking= at cross-purposes.  

It feels like it would be worth trying to put togeth= er some *very short* straw-man docs/pages/paragraphs to try and get a conse= nsus version on specific points, so that we avoid re-hashing the same argum= ents/discussions over time, or at least have something we can refer to - and amend if necessary. I think thi= s is aiming at the same end-point as Steve’s request for a statement = of requirements, but will ensure we’re expressing our requirements in= a consistent set of terms.



By the lo= oks of it, these would make for a good starting point (I think the answers = to most of these are implicit in various people’s contributions to the thread… but that doesn’t mean everyone agrees ;^)  = ;):



1 - what = do we mean by authentication and authorisation? Are there other decisions (= e.g. access control, entitlement) which need to be called out explicitly? This reflects the purpose of Justin’s questions. Cla= ssically, the reason for authenticating a user is to answer a yes/no questi= on (is this the person to whom this credential was originally issued); if y= es, what do I want to do about it (at which point the further entitlements are usually determined by retrieving = a user profile, ACL or whatever)?


Access control and entitlement as distinct from authorisation? Is there a d= istinction, or are people just using different terminology?

I think of authentication as providing more than a yes/no answer: it provid= es an identifier. If the relying party has enough information (perhaps on t= he basis of previous interactions) to authorize something with just that, f= ine. Otherwise some attributes are needed to make an authorisation decision.


However, = as we know, these days access control and entitlement decisions also need t= o be made on the basis of input other than classic credentials, and that’s one of the two cores of this discussion, I believe.


Example of an "input other than classic credentials"?




2 - what&= #8217;s the classic lifecycle of a credential - i.e. a artefact intended to= provide evidence in support of an assertion of identity. (e.g. registration/verification/enrolment, credential issue, credential presenta= tion/authentication, credential amendment/revocation/destruction…)?


Credential is another of those tricky words. Sometimes it means the same as= an authentication token. Sometimes it has some attributes bound to it, whi= ch means it has both an authentication and attribute provision flavor to it= . I find it simpler to talk about tokens, where one doesn't have to deal with revocation when some attribute= (employment, for example) changes.



3 - How d= oes (2) relate to other assertions (e.g. attribute assertions) we would lik= e to make reliably?



With that starter set, I think we can confirm the su= bset of requirements that 800-63-1 still meets, and define the delta that r= equires new design.

 

4 - What’s the right way to update current thi= nking on LOAs, to account for the change Jim describes in his proposal - i.= e., the case where "credenti= als (used in authentication) and attribute information (established through id= entity proofing) could be provided by different parties.”

 

5 - From Jim’s proposal: “Attribute reliability refers to the quality of the identity proo= fing process, as well as the strength of the binding of the identifying attributes to the authentication.” Do we need/want to expand = on this a little? This seems to cater well for the case where, say, vehicle= entitlements are being established so that they can be encapsulated in a d= riving licence. It’s not so clear how this addresses, say, third party assertions that do not arise from an iden= tity proofing process - “I have no idea *who* this user is, but I can= reliably assert the following about them: ... ”.


You're right; that will need to be defined. But it should be possible to de= fine analogous requirements to describe the strength of the binding to the = token. When you show up to enroll at school, it should be possible to use y= our token to allow your school to make LOR 3 asserts that you're there student. But maybe remote students on= ly get LOR 2?

-Jim

--_000_147EE18440E5AF44834B220ED35BA530D332445BWLGPRDMBX01diag_-- --_004_147EE18440E5AF44834B220ED35BA530D332445BWLGPRDMBX01diag_ Content-Type: message/rfc822 Content-Disposition: attachment; creation-date="Mon, 12 Jan 2015 23:26:25 GMT"; modification-date="Mon, 12 Jan 2015 23:26:25 GMT" Received: from WLGPRDMM01.dia.govt.nz (172.29.0.162) by wlgprdcas02.dia.govt.nz (172.29.0.70) with Microsoft SMTP Server id 14.3.146.0; Fri, 21 Nov 2014 03:33:53 +1300 Received: from s111-0006-lnv01 (Not Verified[161.65.142.225]) by WLGPRDMM01.dia.govt.nz with MailMarshal (v7,1,1,5205) (using TLS: SSLv23) id ; Fri, 21 Nov 2014 03:32:54 +1300 Received: from smtp.safecom.net.nz (EHLO smtp.safecom.net.nz) ([125.236.41.139]) by s111-0006-lnv01 (JAMES SMTP Server ) with ESMTP ID 571890630 for ; Fri, 21 Nov 2014 03:33:52 +1300 (NZDT) Received: from elists.isoc.org ([4.31.198.48]) by smtp.safecom.net.nz id ; Fri, 21 Nov 2014 03:33:49 +1300 Received: from localhost (localhost [127.0.0.1]) by elists.isoc.org (Postfix) with ESMTP id A3BB81A7AC0; Thu, 20 Nov 2014 06:32:52 -0800 (PST) Received: from elists.isoc.org ([127.0.0.1]) by localhost (isoca.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aFdN9rcAEBwo; Thu, 20 Nov 2014 06:32:51 -0800 (PST) Received: from isoca.amsl.com (localhost [IPv6:::1]) by elists.isoc.org (Postfix) with ESMTP id 59CB91A7AC8; Thu, 20 Nov 2014 06:32:51 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by elists.isoc.org (Postfix) with ESMTP id 94AD41A79E0 for ; Thu, 20 Nov 2014 06:32:49 -0800 (PST) Received: from elists.isoc.org ([127.0.0.1]) by localhost (isoca.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vWX4aOORO-gE for ; Thu, 20 Nov 2014 06:32:48 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0072.outbound.protection.outlook.com [157.56.111.72]) by elists.isoc.org (Postfix) with ESMTP id 412B01A2D2E for ; Thu, 20 Nov 2014 06:32:48 -0800 (PST) Received: from BLUPR06MB243.namprd06.prod.outlook.com (10.242.191.154) by BLUPR06MB242.namprd06.prod.outlook.com (10.242.191.142) with Microsoft SMTP Server (TLS) id 15.1.26.15; Thu, 20 Nov 2014 14:33:42 +0000 Received: from BLUPR06MB243.namprd06.prod.outlook.com ([169.254.7.121]) by BLUPR06MB243.namprd06.prod.outlook.com ([169.254.7.121]) with mapi id 15.01.0016.006; Thu, 20 Nov 2014 14:33:42 +0000 From: Steve Olshansky To: "ideco-fab@elists.isoc.org" Subject: [Ideco-fab] About the InterFed+Attributes wiki Thread-Topic: About the InterFed+Attributes wiki Thread-Index: AQHQBM8CzQBRRzk67U2yXzuwV+PhrA== Sender: Ideco-fab Date: Thu, 20 Nov 2014 14:33:41 +0000 Message-ID: <35ECE4C4-BB83-4461-ABA4-B1237F63B3BD@isoc.org> References: <544E933D.7080805@isoc.org> <6D46D491-3593-46D4-A40B-A37FBD086218@isoc.org> <872E069D-4D13-48DB-92C1-EF6A1EC04716@isoc.org> <152EC01A-A8E7-44AF-95F2-3236FBF95D83@switch.ch> List-Help: List-Subscribe: , List-Unsubscribe: , In-Reply-To: <152EC01A-A8E7-44AF-95F2-3236FBF95D83@switch.ch> Accept-Language: en-US Content-Language: en-US X-MS-Exchange-Organization-AuthAs: Internal X-MS-Exchange-Organization-AuthMechanism: 10 X-MS-Exchange-Organization-AuthSource: WLGPRDCAS02.dia.govt.nz X-MS-Has-Attach: yes X-Auto-Response-Suppress: All X-MS-TNEF-Correlator: list-id: list-post: list-archive: x-beenthere: ideco-fab@elists.isoc.org x-mailman-version: 2.1.15 errors-to: ideco-fab-bounces@elists.isoc.org delivered-to: ideco-fab@elists.isoc.org x-originating-ip: [97.124.189.208] x-virus-scanned: amavisd-new at amsl.com dkim-signature: v=1; a=rsa-sha256; c=relaxed/simple; d=elists.isoc.org; s=eisoc1; t=1416493969; bh=roRUFM1rdXsE5WuxiPZKetCT1IT5P7ihoc/LjT1qAdw=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=irRgrK3DfhiTo8qqxOAD4Z8kqyphpMgILk7evvIBwjwehaEPmWFNf545T/heJq8Zt 3YgieYJ+TQj3djUyyz4SHazxHTrDyQ73fdWKoZm9DG7SmrDso1kvCCRD4Q5RxiV9Bs SJCmo9tpAPf0KNFUOmlOR3plIXaqKlNc2RnswsAc= x-sdp.mm2006: true x-original-to: ideco-fab@elists.isoc.org x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(189002)(199003)(92726001)(92566001)(101416001)(77156002)(2351001)(107046002)(107886001)(20776003)(66066001)(99936001)(120916001)(50986999)(33656002)(46102003)(64706001)(450100001)(229853001)(77096003)(95666004)(31966008)(62966003)(99286002)(40100003)(93886004)(21056001)(106116001)(105586002)(106356001)(19580395003)(83716003)(2656002)(86362001)(87936001)(122556002)(15974865002)(4396001)(97736003)(82746002)(15975445006)(36756003)(99396003)(54356999)(76176999)(110136001)(104396001)(18886075002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR06MB242; H:BLUPR06MB243.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: multipart/mixed; boundary="_003_35ECE4C4BB834461ABA4B1237F63B3BDisocorg_" MIME-Version: 1.0 --_003_35ECE4C4BB834461ABA4B1237F63B3BDisocorg_ Content-Type: text/plain; charset="Windows-1252" Content-ID: <7ADDD0ED91F7C641985539DA645B2E16@dia.govt.nz> Content-Transfer-Encoding: quoted-printable All- There unfortunately is a long-standing bug in Confluence. You must be logge= d in before that link, or any link to a restricted page, will work. The wiki space for workshop attendees only, which you all have full edit ac= cess to and which is not publicly viewable, is athttps://tid.isoc.org/confl= uence/display/interfedgen/ The *PUBLIC* wiki space, containing the agenda, presentations, and contribu= tions/references, is at https://tid.isoc.org/confluence/display/interfed/ As we make progress on work items and are ready to move them to the public = wiki, I will be happy to do that. Our goal is of course to make as much of = our work as possible available to the public, but this restricted wiki spac= e gives us a place to work on things before revealing them to the world. As always, if anyone has questions or problems related to the wiki, or anyt= hing else, please do let me know. Steve -- Steve Olshansky Trust & Identity Program Lead Internet Society www.internetsociety.org --_003_35ECE4C4BB834461ABA4B1237F63B3BDisocorg_ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail.asc Content-Disposition: attachment; filename="signature.asc"; size=465; creation-date="Thu, 20 Nov 2014 14:32:54 GMT"; modification-date="Thu, 20 Nov 2014 14:32:54 GMT" Content-ID: Content-Transfer-Encoding: base64 LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0NCg0KaVFFY0JBRUJBZ0FHQlFKVWJmdkRBQW9K RU9KTzQrODc3ZzNIRUwwSC9qb2owNm52OUtRYkhaYWR3dkZqblpjRw0KTU9NTVhNMkgwQ1VvV3NP elpYS3F3SmJHQkFwVnM5Z0VtV0pMa0xVMDY3dUxmcUZGRlRxOWxiVDV6OFpYWGlvTw0Kb1dKTURw RnE4MHF4dDg2Mm1uSGsyWDR3SGpsd0RqMUZGcHZCRkdsZXJ6eG82Q0ZMK3YvTy95RE1jd3BSRGEy NQ0KaW5hN1BuYnJKRmxDcFdwYVhEbTl5d2Y5bzN0bnhFa3lncmlmLzBYVnZ1ZnpELzRPbzludWpO MzMzZVpqMnp0eA0KU0F3WEZsa1lpVWtBMElUYUlpNis4VFcvVlFrT3UzTDFCYXZ0S1JzdlNvNEVE bElBTytxU0VDN0FqSUNLR200Uw0KaWpDK1NIcVcybTR1ZFNsSG5LbDZvVXhoSlVaQmlYNUFnSHpH eEVFNEY5a0N5YTljbjl1TlVyMzUwQ0dVL2xzPQ0KPVhDanoNCi0tLS0tRU5EIFBHUCBTSUdOQVRV UkUtLS0tLQ0K --_003_35ECE4C4BB834461ABA4B1237F63B3BDisocorg_ Content-Type: text/plain; name="ATT00001.txt" Content-Description: ATT00001.txt Content-Disposition: attachment; filename="ATT00001.txt"; size=152; creation-date="Thu, 20 Nov 2014 14:32:54 GMT"; modification-date="Thu, 20 Nov 2014 14:32:54 GMT" Content-ID: Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCklkZWNvLWZh YiBtYWlsaW5nIGxpc3QNCklkZWNvLWZhYkBlbGlzdHMuaXNvYy5vcmcNCmh0dHBzOi8vZWxpc3Rz Lmlzb2Mub3JnL21haWxtYW4vbGlzdGluZm8vaWRlY28tZmFiDQo= --_003_35ECE4C4BB834461ABA4B1237F63B3BDisocorg_-- --_004_147EE18440E5AF44834B220ED35BA530D332445BWLGPRDMBX01diag_-- From nobody Tue Jan 13 01:32:30 2015 Return-Path: X-Original-To: vot@ietfa.amsl.com Delivered-To: vot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFE2F1ACD55 for ; Tue, 13 Jan 2015 01:32:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.399 X-Spam-Level: X-Spam-Status: No, score=0.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MANGLED_MARKET=2.3, SPF_HELO_PASS=-0.001, SPF_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 0x85XjPOIIdd for ; Tue, 13 Jan 2015 01:32:24 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0675.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::675]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5577C1A8A78 for ; Tue, 13 Jan 2015 01:32:24 -0800 (PST) Received: from CO2PR0601MB0983.namprd06.prod.outlook.com (25.160.7.28) by CO2PR0601MB0984.namprd06.prod.outlook.com (25.160.8.11) with Microsoft SMTP Server (TLS) id 15.1.53.17; Tue, 13 Jan 2015 09:31:59 +0000 Received: from CO2PR0601MB0983.namprd06.prod.outlook.com ([25.160.7.28]) by CO2PR0601MB0983.namprd06.prod.outlook.com ([25.160.7.28]) with mapi id 15.01.0053.000; Tue, 13 Jan 2015 09:31:59 +0000 From: Robin Wilton To: Colin Wallis Thread-Topic: capturing the threads of the discussion Thread-Index: AQHQLrY3sEp+wHMzN02xqbjWxRWn8Zy9JaSAgACkfjs= Date: Tue, 13 Jan 2015 09:31:59 +0000 Message-ID: References: , <54B44058.8080407@bluepopcorn.net> , <147EE18440E5AF44834B220ED35BA530D332445B@WLGPRDMBX01.dia.govt.nz> In-Reply-To: <147EE18440E5AF44834B220ED35BA530D332445B@WLGPRDMBX01.dia.govt.nz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [94.174.34.240] authentication-results: spf=none (sender IP is ) smtp.mailfrom=wilton@isoc.org; x-dmarcaction-test: None x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005003);SRVR:CO2PR0601MB0984; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:CO2PR0601MB0984; x-forefront-prvs: 045584D28C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(189002)(51444003)(377454003)(24454002)(199003)(479174004)(2950100001)(2900100001)(82746002)(93886004)(19580405001)(19580395003)(92566002)(99286002)(110136001)(105586002)(106116001)(106356001)(16236675004)(68736005)(122556002)(40100003)(15975445007)(102836002)(101416001)(64706001)(46102003)(76176999)(54356999)(97736003)(50986999)(561944003)(33656002)(19625215002)(87936001)(2656002)(83716003)(62966003)(77156002)(86362001)(19617315012)(16601075003)(36756003)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:CO2PR0601MB0984; H:CO2PR0601MB0983.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: isoc.org does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_D11B9167F1294662864DCC717D417F81isocorg_" MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jan 2015 09:31:59.3136 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR0601MB0984 Archived-At: Cc: Jim Fenton , "vot@ietf.org" Subject: Re: [VoT] capturing the threads of the discussion X-BeenThere: vot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Vectors of Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2015 09:32:29 -0000 --_000_D11B9167F1294662864DCC717D417F81isocorg_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Oops - I'd forgotten about the wiki: apologies! Yes, I think that's the pla= ce to start... R Robin Wilton Technical Outreach Director - Identity and Privacy On 12 Jan 2015, at 23:43, "Colin Wallis" > wrote: Well as Steve O pointed out in this attached email in November, the wiki se= t up for this work might be a place to start.. There may be some jiggery pokery to get the folks on this list who want to = contribute (who were not attendees at Utrecht) access rights, but it would = seem to me to be the obvious starter option for a repository. Cheers Colin PS: BTW this is a good discussion and indeed an opportunistic time to bring= it together since so much of what Justin, Jim, Scott, Ken, Steve W, Mark e= t al have commented recently is complementary (well at least not completely= contradictory or orthogonal) so let=92s grab it! From: vot [mailto:vot-bounces@ietf.org] On Behalf Of Robin Wilton Sent: Tuesday, 13 January 2015 11:22 a.m. To: Jim Fenton Cc: vot@ietf.org Subject: Re: [VoT] capturing the threads of the discussion Thanks Jim, I won't give a substantive response here; just to note that I think it's wo= rth considering a repository so that we can capture 'static' versions of an= y straw-man docs, to complement what we it into the mail thread... Sorry to be brief at this stage - just tying up some loose ends before an a= bsence from the office. R Robin Wilton Technical Outreach Director - Identity and Privacy On 12 Jan 2015, at 21:45, "Jim Fenton" > wrote: Maybe I should be breaking these apart as Robin suggests, but for now I'll = keep this in one reply: On 1/12/15 6:06 AM, Robin Wilton wrote: This thread raises several important topics=85 just as a practical matter, = it might be worth trying to spin some of them off separately, so that we ad= dress them all, and minimise the risk of talking at cross-purposes. It feels like it would be worth trying to put together some *very short* st= raw-man docs/pages/paragraphs to try and get a consensus version on specifi= c points, so that we avoid re-hashing the same arguments/discussions over t= ime, or at least have something we can refer to - and amend if necessary. I= think this is aiming at the same end-point as Steve=92s request for a stat= ement of requirements, but will ensure we=92re expressing our requirements = in a consistent set of terms. By the looks of it, these would make for a good starting point (I think the= answers to most of these are implicit in various people=92s contributions = to the thread=85 but that doesn=92t mean everyone agrees ;^) ): 1 - what do we mean by authentication and authorisation? Are there other de= cisions (e.g. access control, entitlement) which need to be called out expl= icitly? This reflects the purpose of Justin=92s questions. Classically, the= reason for authenticating a user is to answer a yes/no question (is this t= he person to whom this credential was originally issued); if yes, what do I= want to do about it (at which point the further entitlements are usually d= etermined by retrieving a user profile, ACL or whatever)? Access control and entitlement as distinct from authorisation? Is there a d= istinction, or are people just using different terminology? I think of authentication as providing more than a yes/no answer: it provid= es an identifier. If the relying party has enough information (perhaps on t= he basis of previous interactions) to authorize something with just that, f= ine. Otherwise some attributes are needed to make an authorisation decision= . However, as we know, these days access control and entitlement decisions al= so need to be made on the basis of input other than classic credentials, an= d that=92s one of the two cores of this discussion, I believe. Example of an "input other than classic credentials"? 2 - what=92s the classic lifecycle of a credential - i.e. a artefact intend= ed to provide evidence in support of an assertion of identity. (e.g. regist= ration/verification/enrolment, credential issue, credential presentation/au= thentication, credential amendment/revocation/destruction=85)? Credential is another of those tricky words. Sometimes it means the same as= an authentication token. Sometimes it has some attributes bound to it, whi= ch means it has both an authentication and attribute provision flavor to it= . I find it simpler to talk about tokens, where one doesn't have to deal wi= th revocation when some attribute (employment, for example) changes. 3 - How does (2) relate to other assertions (e.g. attribute assertions) we = would like to make reliably? With that starter set, I think we can confirm the subset of requirements th= at 800-63-1 still meets, and define the delta that requires new design. 4 - What=92s the right way to update current thinking on LOAs, to account f= or the change Jim describes in his proposal - i.e., the case where "credent= ials (used in authentication) and attribute information (established throug= h identity proofing) could be provided by different parties.=94 5 - From Jim=92s proposal: =93Attribute reliability refers to the quality o= f the identity proofing process, as well as the strength of the binding of = the identifying attributes to the authentication.=94 Do we need/want to exp= and on this a little? This seems to cater well for the case where, say, veh= icle entitlements are being established so that they can be encapsulated in= a driving licence. It=92s not so clear how this addresses, say, third part= y assertions that do not arise from an identity proofing process - =93I hav= e no idea *who* this user is, but I can reliably assert the following about= them: ... =94. You're right; that will need to be defined. But it should be possible to de= fine analogous requirements to describe the strength of the binding to the = token. When you show up to enroll at school, it should be possible to use y= our token to allow your school to make LOR 3 asserts that you're there stud= ent. But maybe remote students only get LOR 2? -Jim All- There unfortunately is a long-standing bug in Confluence. You must be logge= d in before that link, or any link to a restricted page, will work. The wiki space for workshop attendees only, which you all have full edit ac= cess to and which is not publicly viewable, is athttps://tid.isoc.org/confl= uence/display/interfedgen/ The *PUBLIC* wiki space, containing the agenda, presentations, and contribu= tions/references, is at https://tid.isoc.org/confluence/display/interfed/ As we make progress on work items and are ready to move them to the public = wiki, I will be happy to do that. Our goal is of course to make as much of = our work as possible available to the public, but this restricted wiki spac= e gives us a place to work on things before revealing them to the world. As always, if anyone has questions or problems related to the wiki, or anyt= hing else, please do let me know. Steve -- Steve Olshansky Trust & Identity Program Lead Internet Society www.internetsociety.org _______________________________________________ Ideco-fab mailing list Ideco-fab@elists.isoc.org https://elists.isoc.org/mailman/listinfo/ideco-fab --_000_D11B9167F1294662864DCC717D417F81isocorg_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Oops - I'd forgotten about the wiki: apologies! Yes, I think that's th= e place to start...

R

Robin Wilton

Technical Outreach Director - Identity and Privacy

On 12 Jan 2015, at 23:43, "Colin Wallis" <Colin.Wallis@dia.govt.nz> wrote:

Well as Steve O pointed o= ut in this attached email in November, the wiki set up for this work might = be a place to start..

There may be some jiggery= pokery to get the folks on this list who want to contribute (who were not = attendees at Utrecht) access rights, but it would seem to me to be the obvious starter option for a repository.

Cheers<= /p>

Colin

PS: BTW this is a good discussion and indeed an opportunistic time to b= ring it together since so much of what Justin, Jim, Scott, Ken, Steve W, Mark et al have commented recently is complementary (well at= least not completely contradictory or orthogonal) so let=92s grab it!

 <= /p>

From: vot [mailto:vot-bounces@ietf.org] On Behalf Of Robin Wilton
Sent: Tuesday, 13 January 2015 11:22 a.m.
To: Jim Fenton
Cc: vot@ietf.org
Subject: Re: [VoT] capturing the threads of the discussion

 

Thanks Jim,

 

I won't give a substantive response here; just to no= te that I think it's worth considering a repository so that we can capture = 'static' versions of any straw-man docs, to complement what we it into the = mail thread...

 

Sorry to be brief at this stage - just tying up some= loose ends before an absence from the office.

 

R

Robin Wilton

 

Technical Outreach Director - Identity and Privacy


On 12 Jan 2015, at 21:45, "Jim Fenton" <fenton@bluepopcorn.net> wrote:

Maybe I should be breaking these apart as Robin sugg= ests, but for now I'll keep this in one reply:

On 1/12/15 6:06 AM, Robin Wilton wrote:

This thread raises several important topics=85 just = as a practical matter, it might be worth trying to spin some of them off se= parately, so that we address them all, and minimise the risk of talking at = cross-purposes.  

It feels like it would be worth trying to put togeth= er some *very short* straw-man docs/pages/paragraphs to try and get a conse= nsus version on specific points, so that we avoid re-hashing the same argum= ents/discussions over time, or at least have something we can refer to - and amend if necessary. I think thi= s is aiming at the same end-point as Steve=92s request for a statement of r= equirements, but will ensure we=92re expressing our requirements in a consi= stent set of terms.



By the lo= oks of it, these would make for a good starting point (I think the answers = to most of these are implicit in various people=92s contributions to the thread=85 but that doesn=92t mean everyone agrees ;^)  ):



1 - what = do we mean by authentication and authorisation? Are there other decisions (= e.g. access control, entitlement) which need to be called out explicitly? This reflects the purpose of Justin=92s questions. Classic= ally, the reason for authenticating a user is to answer a yes/no question (= is this the person to whom this credential was originally issued); if yes, = what do I want to do about it (at which point the further entitlements are usually determined by retrieving = a user profile, ACL or whatever)?


Access control and entitlement as distinct from authorisation? Is there a d= istinction, or are people just using different terminology?

I think of authentication as providing more than a yes/no answer: it provid= es an identifier. If the relying party has enough information (perhaps on t= he basis of previous interactions) to authorize something with just that, f= ine. Otherwise some attributes are needed to make an authorisation decision.


However, = as we know, these days access control and entitlement decisions also need t= o be made on the basis of input other than classic credentials, and that=92s one of the two cores of this discussion, I believe.


Example of an "input other than classic credentials"?




2 - what= =92s the classic lifecycle of a credential - i.e. a artefact intended to pr= ovide evidence in support of an assertion of identity. (e.g. registration/verification/enrolment, credential issue, credential presenta= tion/authentication, credential amendment/revocation/destruction=85)?


Credential is another of those tricky words. Sometimes it means the same as= an authentication token. Sometimes it has some attributes bound to it, whi= ch means it has both an authentication and attribute provision flavor to it= . I find it simpler to talk about tokens, where one doesn't have to deal with revocation when some attribute= (employment, for example) changes.



3 - How d= oes (2) relate to other assertions (e.g. attribute assertions) we would lik= e to make reliably?



With that starter set, I think we can confirm the su= bset of requirements that 800-63-1 still meets, and define the delta that r= equires new design.

 

4 - What=92s the right way to update current thinkin= g on LOAs, to account for the change Jim describes in his proposal - i.e., = the case where "credentials (used in authentication) and attribute information (established through id= entity proofing) could be provided by different parties.=94

 

5 - From Jim=92s proposal: =93Attribute reliability refers to the quality of the identity proofing pro= cess, as well as the strength of the binding of the identifying attributes to the authentication.=94 Do we need/want to expand on t= his a little? This seems to cater well for the case where, say, vehicle ent= itlements are being established so that they can be encapsulated in a drivi= ng licence. It=92s not so clear how this addresses, say, third party assertions that do not arise from an iden= tity proofing process - =93I have no idea *who* this user is, but I can rel= iably assert the following about them: ... =94.


You're right; that will need to be defined. But it should be possible to de= fine analogous requirements to describe the strength of the binding to the = token. When you show up to enroll at school, it should be possible to use y= our token to allow your school to make LOR 3 asserts that you're there student. But maybe remote students on= ly get LOR 2?

-Jim

All-
There unfortunately is a long-standing bug in Confluence. You must be= logged in before that link, or any link to a restricted page, will work.

The wiki space for workshop attendees only, which you all have full e= dit access to and which is not publicly viewable, is athttps://tid.isoc.org= /confluence/display/interfedgen/

The *PUBLIC* wiki space, containing the agenda, presentations, and co= ntributions/references, is at
https:/= /tid.isoc.org/confluence/display/interfed/

As we make progress on work items and are ready to move them to the p= ublic wiki, I will be happy to do that. Our goal is of course to make as mu= ch of our work as possible available to the public, but this restricted wik= i space gives us a place to work on things before revealing them to the world.

As always, if anyone has questions or problems related to the wiki, o= r anything else, please do let me know.
       Steve

--
Steve Olshansky
Trust & Identity Program Lead
Internet Society
www.internetsociety.org


<signature.asc>
--_000_D11B9167F1294662864DCC717D417F81isocorg_-- From nobody Tue Jan 13 05:19:58 2015 Return-Path: X-Original-To: vot@ietfa.amsl.com Delivered-To: vot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F15691A8ADA for ; Tue, 13 Jan 2015 05:19:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.398 X-Spam-Level: X-Spam-Status: No, score=0.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_MARKET=2.3, SPF_HELO_PASS=-0.001, SPF_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 aKRi0yCFnGTL for ; Tue, 13 Jan 2015 05:19:52 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0669.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::669]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DC7A1A8ADD for ; Tue, 13 Jan 2015 05:19:50 -0800 (PST) Received: from BLUPR06MB244.namprd06.prod.outlook.com (10.242.191.153) by BLUPR06MB388.namprd06.prod.outlook.com (10.141.26.25) with Microsoft SMTP Server (TLS) id 15.1.53.17; Tue, 13 Jan 2015 13:19:27 +0000 Received: from BLUPR06MB243.namprd06.prod.outlook.com (10.242.191.154) by BLUPR06MB244.namprd06.prod.outlook.com (10.242.191.153) with Microsoft SMTP Server (TLS) id 15.1.53.17; Tue, 13 Jan 2015 13:19:23 +0000 Received: from BLUPR06MB243.namprd06.prod.outlook.com ([169.254.7.154]) by BLUPR06MB243.namprd06.prod.outlook.com ([169.254.7.154]) with mapi id 15.01.0053.000; Tue, 13 Jan 2015 13:19:23 +0000 From: Steve Olshansky To: "vot@ietf.org" Thread-Topic: VoT wiki Thread-Index: AQHQLzOLqVjgQ0sfDk6+7bgAArVlfw== Date: Tue, 13 Jan 2015 13:19:22 +0000 Message-ID: <5DADD66B-B15F-4148-9D96-433E721D4C5A@isoc.org> References: , <54B44058.8080407@bluepopcorn.net> , <147EE18440E5AF44834B220ED35BA530D332445B@WLGPRDMBX01.dia.govt.nz> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [97.124.189.208] authentication-results: spf=none (sender IP is ) smtp.mailfrom=olshansky@isoc.org; x-dmarcaction-test: None x-microsoft-antispam: BCL:0; PCL:0; RULEID:(3005003); SRVR:BLUPR06MB244; UriScan:; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:BLUPR06MB244; x-forefront-prvs: 045584D28C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(24454002)(51704005)(377454003)(479174004)(189002)(199003)(19580395003)(19580405001)(87936001)(66066001)(82746002)(83716003)(2656002)(221733001)(101416001)(76176999)(99936001)(50986999)(54356999)(122556002)(40100003)(92566002)(77156002)(62966003)(450100001)(33656002)(561944003)(93886004)(2501002)(97736003)(106116001)(106356001)(105586002)(99286002)(86362001)(46102003)(64706001)(15975445007)(102836002)(2950100001)(2900100001)(2351001)(107886001)(68736005)(229853001)(110136001)(15974865002)(36756003)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR06MB244; H:BLUPR06MB243.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:3; A:3; LANG:en; received-spf: None (protection.outlook.com: isoc.org does not designate permitted sender hosts) Content-Type: multipart/signed; boundary="Apple-Mail=_B51A7D67-E376-4884-B3CB-898DD32BE7B9"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jan 2015 13:19:22.2110 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB244 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BLUPR06MB388; X-OriginatorOrg: isoc.org Archived-At: Subject: [VoT] VoT wiki X-BeenThere: vot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Vectors of Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2015 13:19:55 -0000 --Apple-Mail=_B51A7D67-E376-4884-B3CB-898DD32BE7B9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 All- This is a great discussion, and the stars seem to be aligning now for = the development of some documents or any other related artifacts. I setup a dedicated wiki space for use by this group. It is open to the = world for viewing, but we can easily make restricted areas for the = purpose of working on documents before publishing. Anyone would would = like edit access is welcome to contact me directly (off-list). https://tid.isoc.org/confluence/display/vot/VoT+Home Steve -- Steve Olshansky Trust & Identity Program Lead Internet Society www.internetsociety.org On Jan 13, 2015, at 2:31 AM, Robin Wilton wrote: > Oops - I'd forgotten about the wiki: apologies! Yes, I think that's = the place to start... >=20 > R >=20 > Robin Wilton >=20 > Technical Outreach Director - Identity and Privacy >=20 > On 12 Jan 2015, at 23:43, "Colin Wallis" = wrote: >=20 >> Well as Steve O pointed out in this attached email in November, the = wiki set up for this work might be a place to start.. >> There may be some jiggery pokery to get the folks on this list who = want to contribute (who were not attendees at Utrecht) access rights, = but it would seem to me to be the obvious starter option for a = repository. >> Cheers >> Colin >> PS: BTW this is a good discussion and indeed an opportunistic time to = bring it together since so much of what Justin, Jim, Scott, Ken, Steve = W, Mark et al have commented recently is complementary (well at least = not completely contradictory or orthogonal) so let=92s grab it! >> =20 >> From: vot [mailto:vot-bounces@ietf.org] On Behalf Of Robin Wilton >> Sent: Tuesday, 13 January 2015 11:22 a.m. >> To: Jim Fenton >> Cc: vot@ietf.org >> Subject: Re: [VoT] capturing the threads of the discussion >> =20 >> Thanks Jim, >> =20 >> I won't give a substantive response here; just to note that I think = it's worth considering a repository so that we can capture 'static' = versions of any straw-man docs, to complement what we it into the mail = thread... >> =20 >> Sorry to be brief at this stage - just tying up some loose ends = before an absence from the office. >> =20 >> R >>=20 >> Robin Wilton >> =20 >> Technical Outreach Director - Identity and Privacy >>=20 >> On 12 Jan 2015, at 21:45, "Jim Fenton" = wrote: >>=20 >> Maybe I should be breaking these apart as Robin suggests, but for now = I'll keep this in one reply: >>=20 >> On 1/12/15 6:06 AM, Robin Wilton wrote: >> This thread raises several important topics=85 just as a practical = matter, it might be worth trying to spin some of them off separately, so = that we address them all, and minimise the risk of talking at = cross-purposes. =20 >> It feels like it would be worth trying to put together some *very = short* straw-man docs/pages/paragraphs to try and get a consensus = version on specific points, so that we avoid re-hashing the same = arguments/discussions over time, or at least have something we can refer = to - and amend if necessary. I think this is aiming at the same = end-point as Steve=92s request for a statement of requirements, but will = ensure we=92re expressing our requirements in a consistent set of terms. >>=20 >>=20 >> By the looks of it, these would make for a good starting point (I = think the answers to most of these are implicit in various people=92s = contributions to the thread=85 but that doesn=92t mean everyone agrees = ;^) ): >>=20 >>=20 >> 1 - what do we mean by authentication and authorisation? Are there = other decisions (e.g. access control, entitlement) which need to be = called out explicitly? This reflects the purpose of Justin=92s = questions. Classically, the reason for authenticating a user is to = answer a yes/no question (is this the person to whom this credential was = originally issued); if yes, what do I want to do about it (at which = point the further entitlements are usually determined by retrieving a = user profile, ACL or whatever)? >>=20 >> Access control and entitlement as distinct from authorisation? Is = there a distinction, or are people just using different terminology? >>=20 >> I think of authentication as providing more than a yes/no answer: it = provides an identifier. If the relying party has enough information = (perhaps on the basis of previous interactions) to authorize something = with just that, fine. Otherwise some attributes are needed to make an = authorisation decision. >>=20 >>=20 >> However, as we know, these days access control and entitlement = decisions also need to be made on the basis of input other than classic = credentials, and that=92s one of the two cores of this discussion, I = believe. >>=20 >> Example of an "input other than classic credentials"? >>=20 >>=20 >>=20 >>=20 >> 2 - what=92s the classic lifecycle of a credential - i.e. a artefact = intended to provide evidence in support of an assertion of identity. = (e.g. registration/verification/enrolment, credential issue, credential = presentation/authentication, credential = amendment/revocation/destruction=85)?=20 >>=20 >>=20 >> Credential is another of those tricky words. Sometimes it means the = same as an authentication token. Sometimes it has some attributes bound = to it, which means it has both an authentication and attribute provision = flavor to it. I find it simpler to talk about tokens, where one doesn't = have to deal with revocation when some attribute (employment, for = example) changes. >>=20 >>=20 >>=20 >> 3 - How does (2) relate to other assertions (e.g. attribute = assertions) we would like to make reliably? >>=20 >>=20 >> With that starter set, I think we can confirm the subset of = requirements that 800-63-1 still meets, and define the delta that = requires new design. >> =20 >> 4 - What=92s the right way to update current thinking on LOAs, to = account for the change Jim describes in his proposal - i.e., the case = where "credentials (used in authentication) and attribute information = (established through identity proofing) could be provided by different = parties.=94 >> =20 >> 5 - =46rom Jim=92s proposal: =93Attribute reliability refers to the = quality of the identity proofing process, as well as the strength of the = binding of the identifying attributes to the authentication.=94 Do we = need/want to expand on this a little? This seems to cater well for the = case where, say, vehicle entitlements are being established so that they = can be encapsulated in a driving licence. It=92s not so clear how this = addresses, say, third party assertions that do not arise from an = identity proofing process - =93I have no idea *who* this user is, but I = can reliably assert the following about them: ... =94. >>=20 >> You're right; that will need to be defined. But it should be possible = to define analogous requirements to describe the strength of the binding = to the token. When you show up to enroll at school, it should be = possible to use your token to allow your school to make LOR 3 asserts = that you're there student. But maybe remote students only get LOR 2? >>=20 >> -Jim >>=20 > vot mailing list > vot@ietf.org > https://www.ietf.org/mailman/listinfo/vot --Apple-Mail=_B51A7D67-E376-4884-B3CB-898DD32BE7B9 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----- iQEcBAEBAgAGBQJUtRtZAAoJEOJO4+877g3H7v4H/irqIcqOlV/FVs+zK6iHVNU8 gNYHfKMncOZI2cG2kihWEE5T5B1tD5IUvDzGglw55YZ9TzpmA96WaQnyFdNJp/6i RS+Cem8z1dcBBKIbLnMWKrVfSsi2HJXqZCbVQzi5qRMz/ogWM6TxAu4qENy2o6KV 13XmnVjrKHyiQuMu6J+fhotoWA33DHv6VpXELLiveN7z4leOTtb3jR1sjNCWm2yf hPPTNG1uED55Zxa514Yz8pUsVlM3Yigotd9xxFp65YW4uGfUUKsI1BFV/2jU4Pto 6paA8DvotICs7Ves+Hu+UYOszNTwQMl13VQ8qPZc4qJ3z0LV4gbAqM0INr+IJ/o= =xiYB -----END PGP SIGNATURE----- --Apple-Mail=_B51A7D67-E376-4884-B3CB-898DD32BE7B9-- From nobody Tue Jan 13 10:00:35 2015 Return-Path: X-Original-To: vot@ietfa.amsl.com Delivered-To: vot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F19A1A902D for ; Tue, 13 Jan 2015 10:00:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.322 X-Spam-Level: X-Spam-Status: No, score=0.322 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MANGLED_MARKET=2.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_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 lvN61maXWw6P for ; Tue, 13 Jan 2015 10:00:27 -0800 (PST) Received: from mail-oi0-f46.google.com (mail-oi0-f46.google.com [209.85.218.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D34B11A9029 for ; Tue, 13 Jan 2015 10:00:26 -0800 (PST) Received: by mail-oi0-f46.google.com with SMTP id a3so3527297oib.5 for ; Tue, 13 Jan 2015 10:00:26 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=zoO7BuxHn/3XiyDaBAclMBvFZyYpCSWPoJxcVMl43bY=; b=BM8fSp+8W2lht6NAGttmVFx8Mt7vkvOkWkjJ78R8BMtv3VbfsGrREO0Djqu0hmHXJH ig1UiCpCKCMH2n4PFQ61Zg4b3nIdo6QQQHl9q/F/jo69re4SlfabnFArFIR9mvAFJFtl 7EYjXP0XEKy1UFN1el7PdTLEjvHW597bOOWx+0o3iR/sQ0xummJA2ORL3pD6IJt5Op3F c1osExfqBo/ZDrzXJdNSLq9MskClFnTW1kTEuiGZbVkhIQFQhDx3l50BVGzGYchM/2Qh LI2jhQzELCzjVm9a40i/skAFzkXKzjzc/gBsn3UeU5fkEfe/ZvX4LuEO8PR/pvXasj+u r3Mw== X-Gm-Message-State: ALoCoQnsDOz3k7WWH08YaYbUwMz/KNTxniy1awsTOfWzSrjfDNMKXged3ZnY12yFo+0k3yS4vcEs MIME-Version: 1.0 X-Received: by 10.60.155.195 with SMTP id vy3mr21755323oeb.62.1421172026001; Tue, 13 Jan 2015 10:00:26 -0800 (PST) Received: by 10.202.66.87 with HTTP; Tue, 13 Jan 2015 10:00:25 -0800 (PST) In-Reply-To: References: Date: Tue, 13 Jan 2015 13:00:25 -0500 Message-ID: From: Peter Alterman To: vot@ietf.org Content-Type: multipart/alternative; boundary=089e0102dc32c662b8050c8c65ed Archived-At: Subject: Re: [VoT] vot Digest, Vol 5, Issue 6 X-BeenThere: vot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Vectors of Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2015 18:00:33 -0000 --089e0102dc32c662b8050c8c65ed Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =E2=80=8BHappy new year to you all. I've been reading the mail but unable = to break away long enough to comment until now. As I read it, the issue on the table is how to express trustworthiness. If Abbie was here he'd point you all to the one-to-one correlation between trust and threat/threat vector mitigation.=E2=80=8B I recommend to you the = Third Deliverable of the OASIS Trust Elevation TC - link provided upon demonstration of curiosity ;-) An RP trusts an external assertion of identity (or even extended attributes) to the extent that the assertion is created and/or can be verified to a predetermined degree of threat/risk mitigation. This degree is baked into policy or contract or some other pre-existing agreement (think banking regulations, etc.) and is locally determined based upon local considerations, e.g., no global standard is appropriate. So far as I can see, vectors of trust are the same thing as the threats and threat vectors that are enumerated in ISO 29115 and other places, not least of which are controls in NIST 800-53-4 and in ISO 27001/2. I really don't see the vectors as anything different from these and considering trustworthiness as the inverse of threat in this context is pretty much what everybody seems to be saying. If we just use 29115 as our baseline of threats and threat vectors, there are roughly a dozen or so of them associated with authentication of identity assertion. I don't think any of us believe that a twelve-dimensional assertion is practically viable, even if we could agree on a common metric for degree of threat mitigation (fat chance that). This has also already been addressed by the community: think of the factor model, one to four factors (the fourth is context, which may be expressed as "Where or when you are," according to our colleagues). What this does is boil down the trust/threat algorithm to no more than four dimensions and shifts the discussion to the aforementioned conundrum, e.g., how to evaluate and rate the degree of threat mitigation. Various communities have developed policies and practices to address this question, the most recent of which, I think, is EU Regulation 910/2014 (eIDAS). IMO, the greatest opportunity open to us is to find a way to normalize all the various community policies and practices so that RPs can assess whether assertions issued under one community's metrics align with their adopted risk mitigation requirements. I think that has to be addressed in the context of how effective a particular mitigation action is on a recognized threat vector. I would be most interested in your thoughts on that problem. regards, Peter ------------------------------------------------------------ Peter Alterman, Ph.D. Chief Operating Officer SAFE-BioPharma Association cell: 301-943-7452 On Tue, Jan 13, 2015 at 8:19 AM, wrote: > Send vot mailing list submissions to > vot@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/vot > or, via email, send a message with subject or body 'help' to > vot-request@ietf.org > > You can reach the person managing the list at > vot-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of vot digest..." > > Today's Topics: > > 1. Re: capturing the threads of the discussion (Robin Wilton) > 2. VoT wiki (Steve Olshansky) > > > ---------- Forwarded message ---------- > From: Robin Wilton > To: Colin Wallis > Cc: Jim Fenton , "vot@ietf.org" > Date: Tue, 13 Jan 2015 09:31:59 +0000 > Subject: Re: [VoT] capturing the threads of the discussion > Oops - I'd forgotten about the wiki: apologies! Yes, I think that's the > place to start... > > R > > Robin Wilton > > Technical Outreach Director - Identity and Privacy > > On 12 Jan 2015, at 23:43, "Colin Wallis" wrote= : > > Well as Steve O pointed out in this attached email in November, the > wiki set up for this work might be a place to start.. > > There may be some jiggery pokery to get the folks on this list who want t= o > contribute (who were not attendees at Utrecht) access rights, but it woul= d > seem to me to be the obvious starter option for a repository. > > Cheers > > Colin > > PS: BTW this is a good discussion and indeed an opportunistic time to > bring it together since so much of what Justin, Jim, Scott, Ken, Steve W, > Mark et al have commented recently is complementary (well at least not > completely contradictory or orthogonal) so let=E2=80=99s grab it! > > > > *From:* vot [mailto:vot-bounces@ietf.org] *On Behalf Of *Robin Wilton > *Sent:* Tuesday, 13 January 2015 11:22 a.m. > *To:* Jim Fenton > *Cc:* vot@ietf.org > *Subject:* Re: [VoT] capturing the threads of the discussion > > > > Thanks Jim, > > > > I won't give a substantive response here; just to note that I think it's > worth considering a repository so that we can capture 'static' versions o= f > any straw-man docs, to complement what we it into the mail thread... > > > > Sorry to be brief at this stage - just tying up some loose ends before an > absence from the office. > > > > R > > Robin Wilton > > > > Technical Outreach Director - Identity and Privacy > > > On 12 Jan 2015, at 21:45, "Jim Fenton" wrote: > > Maybe I should be breaking these apart as Robin suggests, but for now > I'll keep this in one reply: > > On 1/12/15 6:06 AM, Robin Wilton wrote: > > This thread raises several important topics=E2=80=A6 just as a practical = matter, > it might be worth trying to spin some of them off separately, so that we > address them all, and minimise the risk of talking at cross-purposes. > > It feels like it would be worth trying to put together some *very short* > straw-man docs/pages/paragraphs to try and get a consensus version on > specific points, so that we avoid re-hashing the same arguments/discussio= ns > over time, or at least have something we can refer to - and amend if > necessary. I think this is aiming at the same end-point as Steve=E2=80=99= s request > for a statement of requirements, but will ensure we=E2=80=99re expressing= our > requirements in a consistent set of terms. > > > > By the looks of it, these would make for a good starting point (I think > the answers to most of these are implicit in various people=E2=80=99s con= tributions > to the thread=E2=80=A6 but that doesn=E2=80=99t mean everyone agrees ;^) = ): > > > > 1 - what do we mean by authentication and authorisation? Are there > other decisions (e.g. access control, entitlement) which need to be calle= d > out explicitly? This reflects the purpose of Justin=E2=80=99s questions. > Classically, the reason for authenticating a user is to answer a yes/no > question (is this the person to whom this credential was originally > issued); if yes, what do I want to do about it (at which point the furthe= r > entitlements are usually determined by retrieving a user profile, ACL or > whatever)? > > > Access control and entitlement as distinct from authorisation? Is there a > distinction, or are people just using different terminology? > > I think of authentication as providing more than a yes/no answer: it > provides an identifier. If the relying party has enough information > (perhaps on the basis of previous interactions) to authorize something wi= th > just that, fine. Otherwise some attributes are needed to make an > authorisation decision. > > > However, as we know, these days access control and entitlement decisions > also need to be made on the basis of input other than classic credentials= , > and that=E2=80=99s one of the two cores of this discussion, I believe. > > > Example of an "input other than classic credentials"? > > > > > 2 - what=E2=80=99s the classic lifecycle of a credential - i.e. a artef= act > intended to provide evidence in support of an assertion of identity. (e.g= . > registration/verification/enrolment, credential issue, credential > presentation/authentication, credential amendment/revocation/destruction= =E2=80=A6)? > > > Credential is another of those tricky words. Sometimes it means the same > as an authentication token. Sometimes it has some attributes bound to it, > which means it has both an authentication and attribute provision flavor = to > it. I find it simpler to talk about tokens, where one doesn't have to dea= l > with revocation when some attribute (employment, for example) changes. > > > > 3 - How does (2) relate to other assertions (e.g. attribute assertions) > we would like to make reliably? > > > > With that starter set, I think we can confirm the subset of > requirements that 800-63-1 still meets, and define the delta that require= s > new design. > > > > 4 - What=E2=80=99s the right way to update current thinking on LOAs, to a= ccount > for the change Jim describes in his proposal - i.e., the case where "cred= entials > (used in authentication) and attribute information (established through > identity proofing) could be provided by different parties.=E2=80=9D > > > > 5 - From Jim=E2=80=99s proposal: =E2=80=9CAttribute reliability refers to= the quality of > the identity proofing process, as well as the strength of the binding of > the identifying attributes to the authentication.=E2=80=9D Do we need/wan= t to > expand on this a little? This seems to cater well for the case where, say= , > vehicle entitlements are being established so that they can be encapsulat= ed > in a driving licence. It=E2=80=99s not so clear how this addresses, say, = third > party assertions that do not arise from an identity proofing process - = =E2=80=9CI > have no idea *who* this user is, but I can reliably assert the following > about them: ... =E2=80=9D. > > > You're right; that will need to be defined. But it should be possible to > define analogous requirements to describe the strength of the binding to > the token. When you show up to enroll at school, it should be possible to > use your token to allow your school to make LOR 3 asserts that you're the= re > student. But maybe remote students only get LOR 2? > > -Jim > > All- > There unfortunately is a long-standing bug in Confluence. You must be > logged in before that link, or any link to a restricted page, will work. > > The wiki space for workshop attendees only, which you all have full edit > access to and which is not publicly viewable, is athttps:// > tid.isoc.org/confluence/display/interfedgen/ > > The *PUBLIC* wiki space, containing the agenda, presentations, and > contributions/references, is at > https://tid.isoc.org/confluence/display/interfed/ > > As we make progress on work items and are ready to move them to the publi= c > wiki, I will be happy to do that. Our goal is of course to make as much o= f > our work as possible available to the public, but this restricted wiki > space gives us a place to work on things before revealing them to the wor= ld. > > As always, if anyone has questions or problems related to the wiki, or > anything else, please do let me know. > Steve > > -- > Steve Olshansky > Trust & Identity Program Lead > Internet Society > www.internetsociety.org > > > > > _______________________________________________ > Ideco-fab mailing list > Ideco-fab@elists.isoc.org > https://elists.isoc.org/mailman/listinfo/ideco-fab > > > > ---------- Forwarded message ---------- > From: Steve Olshansky > To: "vot@ietf.org" > Cc: > Date: Tue, 13 Jan 2015 13:19:22 +0000 > Subject: [VoT] VoT wiki > All- > This is a great discussion, and the stars seem to be aligning now for the > development of some documents or any other related artifacts. > > I setup a dedicated wiki space for use by this group. It is open to the > world for viewing, but we can easily make restricted areas for the purpos= e > of working on documents before publishing. Anyone would would like edit > access is welcome to contact me directly (off-list). > https://tid.isoc.org/confluence/display/vot/VoT+Home > Steve > > -- > Steve Olshansky > Trust & Identity Program Lead > Internet Society > www.internetsociety.org > > On Jan 13, 2015, at 2:31 AM, Robin Wilton wrote: > > > Oops - I'd forgotten about the wiki: apologies! Yes, I think that's the > place to start... > > > > R > > > > Robin Wilton > > > > Technical Outreach Director - Identity and Privacy > > > > On 12 Jan 2015, at 23:43, "Colin Wallis" > wrote: > > > >> Well as Steve O pointed out in this attached email in November, the > wiki set up for this work might be a place to start.. > >> There may be some jiggery pokery to get the folks on this list who wan= t > to contribute (who were not attendees at Utrecht) access rights, but it > would seem to me to be the obvious starter option for a repository. > >> Cheers > >> Colin > >> PS: BTW this is a good discussion and indeed an opportunistic time to > bring it together since so much of what Justin, Jim, Scott, Ken, Steve W, > Mark et al have commented recently is complementary (well at least not > completely contradictory or orthogonal) so let=E2=80=99s grab it! > >> > >> From: vot [mailto:vot-bounces@ietf.org] On Behalf Of Robin Wilton > >> Sent: Tuesday, 13 January 2015 11:22 a.m. > >> To: Jim Fenton > >> Cc: vot@ietf.org > >> Subject: Re: [VoT] capturing the threads of the discussion > >> > >> Thanks Jim, > >> > >> I won't give a substantive response here; just to note that I think > it's worth considering a repository so that we can capture 'static' > versions of any straw-man docs, to complement what we it into the mail > thread... > >> > >> Sorry to be brief at this stage - just tying up some loose ends before > an absence from the office. > >> > >> R > >> > >> Robin Wilton > >> > >> Technical Outreach Director - Identity and Privacy > >> > >> On 12 Jan 2015, at 21:45, "Jim Fenton" wrote: > >> > >> Maybe I should be breaking these apart as Robin suggests, but for now > I'll keep this in one reply: > >> > >> On 1/12/15 6:06 AM, Robin Wilton wrote: > >> This thread raises several important topics=E2=80=A6 just as a practic= al > matter, it might be worth trying to spin some of them off separately, so > that we address them all, and minimise the risk of talking at > cross-purposes. > >> It feels like it would be worth trying to put together some *very > short* straw-man docs/pages/paragraphs to try and get a consensus version > on specific points, so that we avoid re-hashing the same > arguments/discussions over time, or at least have something we can refer = to > - and amend if necessary. I think this is aiming at the same end-point as > Steve=E2=80=99s request for a statement of requirements, but will ensure = we=E2=80=99re > expressing our requirements in a consistent set of terms. > >> > >> > >> By the looks of it, these would make for a good starting point (I thin= k > the answers to most of these are implicit in various people=E2=80=99s con= tributions > to the thread=E2=80=A6 but that doesn=E2=80=99t mean everyone agrees ;^) = ): > >> > >> > >> 1 - what do we mean by authentication and authorisation? Are there > other decisions (e.g. access control, entitlement) which need to be calle= d > out explicitly? This reflects the purpose of Justin=E2=80=99s questions. > Classically, the reason for authenticating a user is to answer a yes/no > question (is this the person to whom this credential was originally > issued); if yes, what do I want to do about it (at which point the furthe= r > entitlements are usually determined by retrieving a user profile, ACL or > whatever)? > >> > >> Access control and entitlement as distinct from authorisation? Is ther= e > a distinction, or are people just using different terminology? > >> > >> I think of authentication as providing more than a yes/no answer: it > provides an identifier. If the relying party has enough information > (perhaps on the basis of previous interactions) to authorize something wi= th > just that, fine. Otherwise some attributes are needed to make an > authorisation decision. > >> > >> > >> However, as we know, these days access control and entitlement > decisions also need to be made on the basis of input other than classic > credentials, and that=E2=80=99s one of the two cores of this discussion, = I believe. > >> > >> Example of an "input other than classic credentials"? > >> > >> > >> > >> > >> 2 - what=E2=80=99s the classic lifecycle of a credential - i.e. a arte= fact > intended to provide evidence in support of an assertion of identity. (e.g= . > registration/verification/enrolment, credential issue, credential > presentation/authentication, credential amendment/revocation/destruction= =E2=80=A6)? > >> > >> > >> Credential is another of those tricky words. Sometimes it means the > same as an authentication token. Sometimes it has some attributes bound t= o > it, which means it has both an authentication and attribute provision > flavor to it. I find it simpler to talk about tokens, where one doesn't > have to deal with revocation when some attribute (employment, for example= ) > changes. > >> > >> > >> > >> 3 - How does (2) relate to other assertions (e.g. attribute assertions= ) > we would like to make reliably? > >> > >> > >> With that starter set, I think we can confirm the subset of > requirements that 800-63-1 still meets, and define the delta that require= s > new design. > >> > >> 4 - What=E2=80=99s the right way to update current thinking on LOAs, t= o account > for the change Jim describes in his proposal - i.e., the case where > "credentials (used in authentication) and attribute information > (established through identity proofing) could be provided by different > parties.=E2=80=9D > >> > >> 5 - From Jim=E2=80=99s proposal: =E2=80=9CAttribute reliability refers= to the quality > of the identity proofing process, as well as the strength of the binding = of > the identifying attributes to the authentication.=E2=80=9D Do we need/wan= t to > expand on this a little? This seems to cater well for the case where, say= , > vehicle entitlements are being established so that they can be encapsulat= ed > in a driving licence. It=E2=80=99s not so clear how this addresses, say, = third > party assertions that do not arise from an identity proofing process - = =E2=80=9CI > have no idea *who* this user is, but I can reliably assert the following > about them: ... =E2=80=9D. > >> > >> You're right; that will need to be defined. But it should be possible > to define analogous requirements to describe the strength of the binding = to > the token. When you show up to enroll at school, it should be possible to > use your token to allow your school to make LOR 3 asserts that you're the= re > student. But maybe remote students only get LOR 2? > >> > >> -Jim > >> > > vot mailing list > > vot@ietf.org > > https://www.ietf.org/mailman/listinfo/vot > > > _______________________________________________ > vot mailing list > vot@ietf.org > https://www.ietf.org/mailman/listinfo/vot > > --089e0102dc32c662b8050c8c65ed Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
= =E2=80=8BHappy new year to you all.=C2=A0 I've been reading the mail bu= t unable to break away long enough to comment until now. As I read it, the = issue on the table is how to express trustworthiness.=C2=A0

If Abbie was here he'd point you a= ll to the one-to-one correlation between trust and threat/threat vector mit= igation.=E2=80=8B I recommend to you the Third Deliverable of the OASIS Tru= st Elevation TC =C2=A0- link provided upon demonstration of curiosity ;-)

=C2=A0An RP trusts an ex= ternal assertion of identity (or even extended attributes) to the extent th= at the assertion is created and/or can be verified to a predetermined degre= e of threat/risk mitigation. This degree is baked into policy or contract o= r some other pre-existing agreement (think banking regulations, etc.) and i= s locally determined based upon local considerations, e.g., no global stand= ard is appropriate.=C2=A0 So far as I can see, vectors of trust are the sam= e thing as the threats and threat vectors that are enumerated in ISO 29115 = and other places, not least of which are controls in NIST 800-53-4 and in I= SO 27001/2. I really don't see the vectors as anything different from t= hese and considering trustworthiness as the inverse of threat in this conte= xt is pretty much what everybody seems to be saying.=C2=A0

If we just use 29115 as our baselin= e of threats and threat vectors, there are roughly a dozen or so of them as= sociated with authentication of identity assertion. I don't think any o= f us believe that a twelve-dimensional assertion is practically viable, eve= n if we could agree on a common metric for degree of threat mitigation (fat= chance that). This has also already been addressed by the community: think= of the factor model, one to four factors (the fourth is context, which may= be expressed as "Where or when you are," according to our collea= gues). What this does is boil down the trust/threat algorithm to no more th= an four dimensions and shifts the discussion to the aforementioned conundru= m, e.g., how to evaluate and rate the degree of threat mitigation. Various = communities have developed policies and practices to address this question,= the most recent of which, I think, is EU Regulation 910/2014 (eIDAS).=C2= =A0

=
IMO, the greatest o= pportunity open to us is to find a way to normalize all the various communi= ty policies and practices so that RPs can assess whether assertions issued = under one community's metrics align with their adopted risk mitigation = requirements. I think that has to be addressed in the context of how effect= ive a particular mitigation action is on a recognized threat vector. =C2=A0= I would be most interested in your thoughts on that problem.

regards,

Peter

=
------------------------------------------------------------
= Peter Alterman, Ph.D.
Chief Operating Officer
SAFE-BioPharma As= sociation
cell: 301-943-7452


On Tue, Jan 13, 2015 at 8:19 AM, <vot-= request@ietf.org> wrote:
Se= nd vot mailing list submissions to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 vot@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/vot
or, via email, send a message with subject or body 'help' to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 vot-req= uest@ietf.org

You can reach the person managing the list at
=C2=A0 =C2=A0 =C2=A0 =C2=A0 vot-owner= @ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of vot digest..."

Today's Topics:

=C2=A0 =C2=A01. Re: capturing the threads of the discussion (Robin Wilton)<= br> =C2=A0 =C2=A02. VoT wiki (Steve Olshansky)


---------- Forwarded message ----------
From:=C2=A0Robin Wilton = <wilton@isoc.org>
To:=C2=A0= Colin Wallis <Colin.Wallis@d= ia.govt.nz>
Cc:=C2=A0Jim Fenton <fenton@bluepopcorn.net>, "vot@ietf.org" <vot@ietf= .org>
Date:=C2=A0Tue, 13 Jan 2015 09:31:59 +0000
Subject:=C2= =A0Re: [VoT] capturing the threads of the discussion
Oops - I'd forgotten about the wiki: apologies! Yes, I think that&= #39;s the place to start...

R

Robin Wilton

Technical Outreach Director - Identity and Privacy

On 12 Jan 2015, at 23:43, "Colin Wallis" <Colin.Wallis@dia.govt.nz> = wrote:

Well as Steve O pointed o= ut in this attached email in November, the wiki set up for this work might = be a place to start..

There may be some jiggery= pokery to get the folks on this list who want to contribute (who were not = attendees at Utrecht) access rights, but it would seem to me to be the obvious starter option for a repository.=

Cheers

Colin

PS: BTW this is a good discussion and indeed an opportunistic time to b= ring it together since so much of what Justin, Jim, Scott, Ken, Steve W, Mark et al have commented recently is complementary (well at= least not completely contradictory or orthogonal) so let=E2=80=99s grab it= !

=C2=A0

From: vot [mailto:vot-bounces@ietf.org] On Behalf Of Robin Wilton
Sent: Tuesday, 13 January 2015 11:22 a.m.
To: Jim Fenton
Cc: vot@ietf.org
Subject: Re: [VoT] capturing the threads of the discussion=

=C2=A0

Thanks Jim,

=C2=A0

I won't give a substantive response here; just t= o note that I think it's worth considering a repository so that we can = capture 'static' versions of any straw-man docs, to complement what= we it into the mail thread...

=C2=A0

Sorry to be brief at this stage - just tying up some= loose ends before an absence from the office.

=C2=A0

R

Robin Wilton

=C2=A0

Technical Outreach Director - Identity and Privacy

Maybe I should be breaking these apart as Robin sugg= ests, but for now I'll keep this in one reply:

On 1/12/15 6:06 AM, Robin Wilton wrote:

This thread raises several important topics=E2=80=A6= just as a practical matter, it might be worth trying to spin some of them = off separately, so that we address them all, and minimise the risk of talki= ng at cross-purposes. =C2=A0

It feels like it would be worth trying to put togeth= er some *very short* straw-man docs/pages/paragraphs to try and get a conse= nsus version on specific points, so that we avoid re-hashing the same argum= ents/discussions over time, or at least have something we can refer to - and amend if necessary. I think thi= s is aiming at the same end-point as Steve=E2=80=99s request for a statemen= t of requirements, but will ensure we=E2=80=99re expressing our requirement= s in a consistent set of terms.



By the looks of it, these would make= for a good starting point (I think the answers to most of these are implic= it in various people=E2=80=99s contributions to the thread=E2=80=A6 but that doesn=E2=80=99t mean everyone agrees ;^) = =C2=A0):



1 - what do we mean by authenticatio= n and authorisation? Are there other decisions (e.g. access control, entitl= ement) which need to be called out explicitly? This reflects the purpose of Justin=E2=80=99s questions. C= lassically, the reason for authenticating a user is to answer a yes/no ques= tion (is this the person to whom this credential was originally issued); if= yes, what do I want to do about it (at which point the further entitlements are usually determined by retrieving = a user profile, ACL or whatever)?


Access control and entitlement as distinct from authorisation? Is there a d= istinction, or are people just using different terminology?

I think of authentication as providing more than a yes/no answer: it provid= es an identifier. If the relying party has enough information (perhaps on t= he basis of previous interactions) to authorize something with just that, f= ine. Otherwise some attributes are needed to make an authorisation decision.


However, as we know, these days acce= ss control and entitlement decisions also need to be made on the basis of i= nput other than classic credentials, and that=E2=80=99s one of the two cores of this discussion, I believe.


Example of an "input other than classic credentials"?




2 - what=E2=80=99s the classic lifec= ycle of a credential - i.e. a artefact intended to provide evidence in supp= ort of an assertion of identity. (e.g. registration/verification/enrolment, credential issue, credential presenta= tion/authentication, credential amendment/revocation/destruction=E2=80=A6)?


Credential is another of those tricky words. Sometimes it means the same as= an authentication token. Sometimes it has some attributes bound to it, whi= ch means it has both an authentication and attribute provision flavor to it= . I find it simpler to talk about tokens, where one doesn't have to deal with revocation when some attri= bute (employment, for example) changes.



3 - How does (2) relate to other ass= ertions (e.g. attribute assertions) we would like to make reliably?<= /span>



With that starter set, I think we can confirm the su= bset of requirements that 800-63-1 still meets, and define the delta that r= equires new design.

=C2=A0

4 - What=E2=80=99s the right way to update current t= hinking on LOAs, to account for the change Jim describes in his proposal - = i.e., the case where "creden= tials (used in authentication) and attribute information (established through id= entity proofing) could be provided by different parties.=E2=80=9D

=C2=A0

5 - From Jim=E2=80=99s proposal: =E2=80=9CAttribute reliability refers to the quality of the identity = proofing process, as well as the strength of the binding of the identifying attributes to the authentication.=E2=80=9D Do we need/want to expan= d on this a little? This seems to cater well for the case where, say, vehic= le entitlements are being established so that they can be encapsulated in a= driving licence. It=E2=80=99s not so clear how this addresses, say, third party assertions that do not arise from an iden= tity proofing process - =E2=80=9CI have no idea *who* this user is, but I c= an reliably assert the following about them: ... =E2=80=9D.


You're right; that will need to be defined. But it should be possible t= o define analogous requirements to describe the strength of the binding to = the token. When you show up to enroll at school, it should be possible to u= se your token to allow your school to make LOR 3 asserts that you're there student. But maybe remote student= s only get LOR 2?

-Jim

All-
There unfortunately is a long-standing bug in Confluence. You must be= logged in before that link, or any link to a restricted page, will work.

The wiki space for workshop attendees only, which you all have full e= dit access to and which is not publicly viewable, is athttps://tid.i= soc.org/confluence/display/interfedgen/

The *PUBLIC* wiki space, containing the agenda, presentations, and co= ntributions/references, is at
https://tid.isoc.org/confluence/display/interfed/
As we make progress on work items and are ready to move them to the p= ublic wiki, I will be happy to do that. Our goal is of course to make as mu= ch of our work as possible available to the public, but this restricted wik= i space gives us a place to work on things before revealing them to the world.

As always, if anyone has questions or problems related to the wiki, o= r anything else, please do let me know.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Steve

--
Steve Olshansky
Trust & Identity Program Lead
Internet Society
www.inte= rnetsociety.org


<signature.asc>
_______________________________________________
Ideco-fab mailing list
Ideco-= fab@elists.isoc.org
https://elists.isoc.org/mailman/listinfo/ideco-fab


---------- Forwarded message ----------
From:=C2=A0Steve Olshans= ky <olshansky@isoc.org>
= To:=C2=A0"vot@ietf.org" <<= a href=3D"mailto:vot@ietf.org">vot@ietf.org>
Cc:=C2=A0
Date:= =C2=A0Tue, 13 Jan 2015 13:19:22 +0000
Subject:=C2=A0[VoT] VoT wiki
Al= l-
This is a great discussion, and the stars seem to be aligning now for the d= evelopment of some documents or any other related artifacts.

I setup a dedicated wiki space for use by this group. It is open to the wor= ld for viewing, but we can easily make restricted areas for the purpose of = working on documents before publishing. Anyone would would like edit access= is welcome to contact me directly (off-list).
https://tid.isoc.org/confluence/display/vot/VoT+Home
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Steve

--
Steve Olshansky
Trust & Identity Program Lead
Internet Society
www.internetso= ciety.org

On Jan 13, 2015, at 2:31 AM, Robin Wilton <wilton@isoc.org> wrote:

> Oops - I'd forgotten about the wiki: apologies! Yes, I think that&= #39;s the place to start...
>
> R
>
> Robin Wilton
>
> Technical Outreach Director - Identity and Privacy
>
> On 12 Jan 2015, at 23:43, "Colin Wallis" <Colin.Wallis@dia.govt.nz> wrote:
>
>> Well as Steve O pointed out in this attached email in November, th= e wiki set up for this work might be a place to start..
>> There may be some jiggery pokery to get the folks on this list who= want to contribute (who were not attendees at Utrecht) access rights, but = it would seem to me to be the obvious starter option for a repository.
>> Cheers
>> Colin
>> PS: BTW this is a good discussion and indeed an opportunistic time= to bring it together since so much of what Justin, Jim, Scott, Ken, Steve = W, Mark et al have commented recently is complementary (well at least not c= ompletely contradictory or orthogonal) so let=E2=80=99s grab it!
>>
>> From: vot [mailto:vot-boun= ces@ietf.org] On Behalf Of Robin Wilton
>> Sent: Tuesday, 13 January 2015 11:22 a.m.
>> To: Jim Fenton
>> Cc: vot@ietf.org
>> Subject: Re: [VoT] capturing the threads of the discussion
>>
>> Thanks Jim,
>>
>> I won't give a substantive response here; just to note that I = think it's worth considering a repository so that we can capture 's= tatic' versions of any straw-man docs, to complement what we it into th= e mail thread...
>>
>> Sorry to be brief at this stage - just tying up some loose ends be= fore an absence from the office.
>>
>> R
>>
>> Robin Wilton
>>
>> Technical Outreach Director - Identity and Privacy
>>
>> On 12 Jan 2015, at 21:45, "Jim Fenton" <fenton@bluepopcorn.net> wrote:
>>
>> Maybe I should be breaking these apart as Robin suggests, but for = now I'll keep this in one reply:
>>
>> On 1/12/15 6:06 AM, Robin Wilton wrote:
>> This thread raises several important topics=E2=80=A6 just as a pra= ctical matter, it might be worth trying to spin some of them off separately= , so that we address them all, and minimise the risk of talking at cross-pu= rposes.
>> It feels like it would be worth trying to put together some *very = short* straw-man docs/pages/paragraphs to try and get a consensus version o= n specific points, so that we avoid re-hashing the same arguments/discussio= ns over time, or at least have something we can refer to - and amend if nec= essary. I think this is aiming at the same end-point as Steve=E2=80=99s req= uest for a statement of requirements, but will ensure we=E2=80=99re express= ing our requirements in a consistent set of terms.
>>
>>
>> By the looks of it, these would make for a good starting point (I = think the answers to most of these are implicit in various people=E2=80=99s= contributions to the thread=E2=80=A6 but that doesn=E2=80=99t mean everyon= e agrees ;^)=C2=A0 ):
>>
>>
>> 1 - what do we mean by authentication and authorisation? Are there= other decisions (e.g. access control, entitlement) which need to be called= out explicitly? This reflects the purpose of Justin=E2=80=99s questions. C= lassically, the reason for authenticating a user is to answer a yes/no ques= tion (is this the person to whom this credential was originally issued); if= yes, what do I want to do about it (at which point the further entitlement= s are usually determined by retrieving a user profile, ACL or whatever)? >>
>> Access control and entitlement as distinct from authorisation? Is = there a distinction, or are people just using different terminology?
>>
>> I think of authentication as providing more than a yes/no answer: = it provides an identifier. If the relying party has enough information (per= haps on the basis of previous interactions) to authorize something with jus= t that, fine. Otherwise some attributes are needed to make an authorisation= decision.
>>
>>
>> However, as we know, these days access control and entitlement dec= isions also need to be made on the basis of input other than classic creden= tials, and that=E2=80=99s one of the two cores of this discussion, I believ= e.
>>
>> Example of an "input other than classic credentials"? >>
>>
>>
>>
>> 2 - what=E2=80=99s the classic lifecycle of a credential - i.e. a = artefact intended to provide evidence in support of an assertion of identit= y. (e.g. registration/verification/enrolment, credential issue, credential = presentation/authentication, credential amendment/revocation/destruction=E2= =80=A6)?
>>
>>
>> Credential is another of those tricky words. Sometimes it means th= e same as an authentication token. Sometimes it has some attributes bound t= o it, which means it has both an authentication and attribute provision fla= vor to it. I find it simpler to talk about tokens, where one doesn't ha= ve to deal with revocation when some attribute (employment, for example) ch= anges.
>>
>>
>>
>> 3 - How does (2) relate to other assertions (e.g. attribute assert= ions) we would like to make reliably?
>>
>>
>> With that starter set, I think we can confirm the subset of requir= ements that 800-63-1 still meets, and define the delta that requires new de= sign.
>>
>> 4 - What=E2=80=99s the right way to update current thinking on LOA= s, to account for the change Jim describes in his proposal - i.e., the case= where "credentials (used in authentication) and attribute information= (established through identity proofing) could be provided by different par= ties.=E2=80=9D
>>
>> 5 - From Jim=E2=80=99s proposal: =E2=80=9CAttribute reliability re= fers to the quality of the identity proofing process, as well as the streng= th of the binding of the identifying attributes to the authentication.=E2= =80=9D Do we need/want to expand on this a little? This seems to cater well= for the case where, say, vehicle entitlements are being established so tha= t they can be encapsulated in a driving licence. It=E2=80=99s not so clear = how this addresses, say, third party assertions that do not arise from an i= dentity proofing process - =E2=80=9CI have no idea *who* this user is, but = I can reliably assert the following about them: ... =E2=80=9D.
>>
>> You're right; that will need to be defined. But it should be p= ossible to define analogous requirements to describe the strength of the bi= nding to the token. When you show up to enroll at school, it should be poss= ible to use your token to allow your school to make LOR 3 asserts that you&= #39;re there student. But maybe remote students only get LOR 2?
>>
>> -Jim
>>
> vot mailing list
> vot@ietf.org
> https://www.ietf.org/mailman/listinfo/vot


_______________________________________________
vot mailing list
vot@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/vot


--089e0102dc32c662b8050c8c65ed-- From nobody Tue Jan 13 10:21:33 2015 Return-Path: X-Original-To: vot@ietfa.amsl.com Delivered-To: vot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66F1E1A9034 for ; Tue, 13 Jan 2015 10:21:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_MARKET=2.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 3OkEUwbWeFeI for ; Tue, 13 Jan 2015 10:21:21 -0800 (PST) Received: from mta6.uth.tmc.edu (mta6.uth.tmc.edu [129.106.163.164]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C13931A902D for ; Tue, 13 Jan 2015 10:21:20 -0800 (PST) Received: from pps.filterd (mta6.uth.tmc.edu [127.0.0.1]) by mta6.uth.tmc.edu (8.14.5/8.14.5) with SMTP id t0DICs64001100; Tue, 13 Jan 2015 12:21:20 -0600 Received: from uthmail3.uthouston.edu (admin4-6.hsc.uth.tmc.edu [129.106.4.6]) by mta6.uth.tmc.edu with ESMTP id 1rw7d28ea7-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 13 Jan 2015 12:21:19 -0600 Received: from UTHMAIL1.uthouston.edu ([fe80::c1d2:3f6a:4f56:4fa4]) by UTHMAIL3.uthouston.edu ([fe80::fd74:5f7a:1426:e687%22]) with mapi id 14.03.0210.002; Tue, 13 Jan 2015 12:21:18 -0600 From: "Jones, Mark B" To: Peter Alterman Thread-Topic: [VoT] vot Digest, Vol 5, Issue 6 Thread-Index: AQHQL1rW789c+MN2zUauEOP7MuQgPpy+wU8A Date: Tue, 13 Jan 2015 18:21:17 +0000 Message-ID: <6FD710F3-28D3-481E-B5A5-7444ECB7FBE0@uth.tmc.edu> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2015-01-13_07:2015-01-13,2015-01-13,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 kscore.is_bulkscore=1.07137382875933e-05 kscore.compositescore=0 circleOfTrustscore=0 compositescore=0.51925478421192 urlsuspect_oldscore=0.51925478421192 suspectscore=0 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=0 rbsscore=0.51925478421192 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1501130174 Archived-At: Cc: "vot@ietf.org" Subject: Re: [VoT] vot Digest, Vol 5, Issue 6 X-BeenThere: vot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Vectors of Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2015 18:21:29 -0000 KzENCg0KUGxlYXNlIGNvbnNpZGVyIHRoaXMgYSBkZW1vbnN0cmF0aW9uIG9mIGN1cmlvc2l0eSBp biB0aGUgbGluayB5b3Ugb2ZmZXJlZC4NCg0KU2VudCBmcm9tIG15IGlQaG9uZQ0KDQpPbiBKYW4g MTMsIDIwMTUsIGF0IDEyOjAwIFBNLCBQZXRlciBBbHRlcm1hbiA8cGFsdGVybWFuQHNhZmUtYmlv cGhhcm1hLm9yZzxtYWlsdG86cGFsdGVybWFuQHNhZmUtYmlvcGhhcm1hLm9yZz4+IHdyb3RlOg0K DQrigItIYXBweSBuZXcgeWVhciB0byB5b3UgYWxsLiAgSSd2ZSBiZWVuIHJlYWRpbmcgdGhlIG1h aWwgYnV0IHVuYWJsZSB0byBicmVhayBhd2F5IGxvbmcgZW5vdWdoIHRvIGNvbW1lbnQgdW50aWwg bm93LiBBcyBJIHJlYWQgaXQsIHRoZSBpc3N1ZSBvbiB0aGUgdGFibGUgaXMgaG93IHRvIGV4cHJl c3MgdHJ1c3R3b3J0aGluZXNzLg0KDQpJZiBBYmJpZSB3YXMgaGVyZSBoZSdkIHBvaW50IHlvdSBh bGwgdG8gdGhlIG9uZS10by1vbmUgY29ycmVsYXRpb24gYmV0d2VlbiB0cnVzdCBhbmQgdGhyZWF0 L3RocmVhdCB2ZWN0b3IgbWl0aWdhdGlvbi7igIsgSSByZWNvbW1lbmQgdG8geW91IHRoZSBUaGly ZCBEZWxpdmVyYWJsZSBvZiB0aGUgT0FTSVMgVHJ1c3QgRWxldmF0aW9uIFRDICAtIGxpbmsgcHJv dmlkZWQgdXBvbiBkZW1vbnN0cmF0aW9uIG9mIGN1cmlvc2l0eSA7LSkNCg0KIEFuIFJQIHRydXN0 cyBhbiBleHRlcm5hbCBhc3NlcnRpb24gb2YgaWRlbnRpdHkgKG9yIGV2ZW4gZXh0ZW5kZWQgYXR0 cmlidXRlcykgdG8gdGhlIGV4dGVudCB0aGF0IHRoZSBhc3NlcnRpb24gaXMgY3JlYXRlZCBhbmQv b3IgY2FuIGJlIHZlcmlmaWVkIHRvIGEgcHJlZGV0ZXJtaW5lZCBkZWdyZWUgb2YgdGhyZWF0L3Jp c2sgbWl0aWdhdGlvbi4gVGhpcyBkZWdyZWUgaXMgYmFrZWQgaW50byBwb2xpY3kgb3IgY29udHJh Y3Qgb3Igc29tZSBvdGhlciBwcmUtZXhpc3RpbmcgYWdyZWVtZW50ICh0aGluayBiYW5raW5nIHJl Z3VsYXRpb25zLCBldGMuKSBhbmQgaXMgbG9jYWxseSBkZXRlcm1pbmVkIGJhc2VkIHVwb24gbG9j YWwgY29uc2lkZXJhdGlvbnMsIGUuZy4sIG5vIGdsb2JhbCBzdGFuZGFyZCBpcyBhcHByb3ByaWF0 ZS4gIFNvIGZhciBhcyBJIGNhbiBzZWUsIHZlY3RvcnMgb2YgdHJ1c3QgYXJlIHRoZSBzYW1lIHRo aW5nIGFzIHRoZSB0aHJlYXRzIGFuZCB0aHJlYXQgdmVjdG9ycyB0aGF0IGFyZSBlbnVtZXJhdGVk IGluIElTTyAyOTExNSBhbmQgb3RoZXIgcGxhY2VzLCBub3QgbGVhc3Qgb2Ygd2hpY2ggYXJlIGNv bnRyb2xzIGluIE5JU1QgODAwLTUzLTQgYW5kIGluIElTTyAyNzAwMS8yLiBJIHJlYWxseSBkb24n dCBzZWUgdGhlIHZlY3RvcnMgYXMgYW55dGhpbmcgZGlmZmVyZW50IGZyb20gdGhlc2UgYW5kIGNv bnNpZGVyaW5nIHRydXN0d29ydGhpbmVzcyBhcyB0aGUgaW52ZXJzZSBvZiB0aHJlYXQgaW4gdGhp cyBjb250ZXh0IGlzIHByZXR0eSBtdWNoIHdoYXQgZXZlcnlib2R5IHNlZW1zIHRvIGJlIHNheWlu Zy4NCg0KSWYgd2UganVzdCB1c2UgMjkxMTUgYXMgb3VyIGJhc2VsaW5lIG9mIHRocmVhdHMgYW5k IHRocmVhdCB2ZWN0b3JzLCB0aGVyZSBhcmUgcm91Z2hseSBhIGRvemVuIG9yIHNvIG9mIHRoZW0g YXNzb2NpYXRlZCB3aXRoIGF1dGhlbnRpY2F0aW9uIG9mIGlkZW50aXR5IGFzc2VydGlvbi4gSSBk b24ndCB0aGluayBhbnkgb2YgdXMgYmVsaWV2ZSB0aGF0IGEgdHdlbHZlLWRpbWVuc2lvbmFsIGFz c2VydGlvbiBpcyBwcmFjdGljYWxseSB2aWFibGUsIGV2ZW4gaWYgd2UgY291bGQgYWdyZWUgb24g YSBjb21tb24gbWV0cmljIGZvciBkZWdyZWUgb2YgdGhyZWF0IG1pdGlnYXRpb24gKGZhdCBjaGFu Y2UgdGhhdCkuIFRoaXMgaGFzIGFsc28gYWxyZWFkeSBiZWVuIGFkZHJlc3NlZCBieSB0aGUgY29t bXVuaXR5OiB0aGluayBvZiB0aGUgZmFjdG9yIG1vZGVsLCBvbmUgdG8gZm91ciBmYWN0b3JzICh0 aGUgZm91cnRoIGlzIGNvbnRleHQsIHdoaWNoIG1heSBiZSBleHByZXNzZWQgYXMgIldoZXJlIG9y IHdoZW4geW91IGFyZSwiIGFjY29yZGluZyB0byBvdXIgY29sbGVhZ3VlcykuIFdoYXQgdGhpcyBk b2VzIGlzIGJvaWwgZG93biB0aGUgdHJ1c3QvdGhyZWF0IGFsZ29yaXRobSB0byBubyBtb3JlIHRo YW4gZm91ciBkaW1lbnNpb25zIGFuZCBzaGlmdHMgdGhlIGRpc2N1c3Npb24gdG8gdGhlIGFmb3Jl bWVudGlvbmVkIGNvbnVuZHJ1bSwgZS5nLiwgaG93IHRvIGV2YWx1YXRlIGFuZCByYXRlIHRoZSBk ZWdyZWUgb2YgdGhyZWF0IG1pdGlnYXRpb24uIFZhcmlvdXMgY29tbXVuaXRpZXMgaGF2ZSBkZXZl bG9wZWQgcG9saWNpZXMgYW5kIHByYWN0aWNlcyB0byBhZGRyZXNzIHRoaXMgcXVlc3Rpb24sIHRo ZSBtb3N0IHJlY2VudCBvZiB3aGljaCwgSSB0aGluaywgaXMgRVUgUmVndWxhdGlvbiA5MTAvMjAx NCAoZUlEQVMpLg0KDQpJTU8sIHRoZSBncmVhdGVzdCBvcHBvcnR1bml0eSBvcGVuIHRvIHVzIGlz IHRvIGZpbmQgYSB3YXkgdG8gbm9ybWFsaXplIGFsbCB0aGUgdmFyaW91cyBjb21tdW5pdHkgcG9s aWNpZXMgYW5kIHByYWN0aWNlcyBzbyB0aGF0IFJQcyBjYW4gYXNzZXNzIHdoZXRoZXIgYXNzZXJ0 aW9ucyBpc3N1ZWQgdW5kZXIgb25lIGNvbW11bml0eSdzIG1ldHJpY3MgYWxpZ24gd2l0aCB0aGVp ciBhZG9wdGVkIHJpc2sgbWl0aWdhdGlvbiByZXF1aXJlbWVudHMuIEkgdGhpbmsgdGhhdCBoYXMg dG8gYmUgYWRkcmVzc2VkIGluIHRoZSBjb250ZXh0IG9mIGhvdyBlZmZlY3RpdmUgYSBwYXJ0aWN1 bGFyIG1pdGlnYXRpb24gYWN0aW9uIGlzIG9uIGEgcmVjb2duaXplZCB0aHJlYXQgdmVjdG9yLiAg IEkgd291bGQgYmUgbW9zdCBpbnRlcmVzdGVkIGluIHlvdXIgdGhvdWdodHMgb24gdGhhdCBwcm9i bGVtLg0KDQpyZWdhcmRzLA0KDQpQZXRlcg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClBldGVyIEFsdGVybWFuLCBQaC5ELg0K Q2hpZWYgT3BlcmF0aW5nIE9mZmljZXINClNBRkUtQmlvUGhhcm1hIEFzc29jaWF0aW9uDQpjZWxs OiAzMDEtOTQzLTc0NTINCg0KDQpPbiBUdWUsIEphbiAxMywgMjAxNSBhdCA4OjE5IEFNLCA8dm90 LXJlcXVlc3RAaWV0Zi5vcmc8bWFpbHRvOnZvdC1yZXF1ZXN0QGlldGYub3JnPj4gd3JvdGU6DQpT ZW5kIHZvdCBtYWlsaW5nIGxpc3Qgc3VibWlzc2lvbnMgdG8NCiAgICAgICAgdm90QGlldGYub3Jn PG1haWx0bzp2b3RAaWV0Zi5vcmc+DQoNClRvIHN1YnNjcmliZSBvciB1bnN1YnNjcmliZSB2aWEg dGhlIFdvcmxkIFdpZGUgV2ViLCB2aXNpdA0KICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3ZvdDxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIv dXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX3ZvdCZkPUF3TUZh USZjPTZ2Z05UaVJuOV9wcUNEOWhLeDlKZ1hOMVZhcEpROEpWb0Y4b1dIMUFnZlEmcj1qZ011OERO Z1ZfZHljejByWXdrTmJFUXEzNkYwQkk1X1pwYmx6N0M1TGhNJm09NFEweXdtZFpPbXE0ZUp6RmNL LVpVRTJnck05NmlaV09QaG9MU3dwSktpSSZzPXVjOTEzcXNMQTZiWjM0ckxmdVNjM3NpZzdaY0l5 a0dEUmVaNzNXeDIxTDAmZT0+DQpvciwgdmlhIGVtYWlsLCBzZW5kIGEgbWVzc2FnZSB3aXRoIHN1 YmplY3Qgb3IgYm9keSAnaGVscCcgdG8NCiAgICAgICAgdm90LXJlcXVlc3RAaWV0Zi5vcmc8bWFp bHRvOnZvdC1yZXF1ZXN0QGlldGYub3JnPg0KDQpZb3UgY2FuIHJlYWNoIHRoZSBwZXJzb24gbWFu YWdpbmcgdGhlIGxpc3QgYXQNCiAgICAgICAgdm90LW93bmVyQGlldGYub3JnPG1haWx0bzp2b3Qt b3duZXJAaWV0Zi5vcmc+DQoNCldoZW4gcmVwbHlpbmcsIHBsZWFzZSBlZGl0IHlvdXIgU3ViamVj dCBsaW5lIHNvIGl0IGlzIG1vcmUgc3BlY2lmaWMNCnRoYW4gIlJlOiBDb250ZW50cyBvZiB2b3Qg ZGlnZXN0Li4uIg0KDQpUb2RheSdzIFRvcGljczoNCg0KICAgMS4gUmU6IGNhcHR1cmluZyB0aGUg dGhyZWFkcyBvZiB0aGUgZGlzY3Vzc2lvbiAoUm9iaW4gV2lsdG9uKQ0KICAgMi4gVm9UIHdpa2kg KFN0ZXZlIE9sc2hhbnNreSkNCg0KDQotLS0tLS0tLS0tIEZvcndhcmRlZCBtZXNzYWdlIC0tLS0t LS0tLS0NCkZyb206IFJvYmluIFdpbHRvbiA8d2lsdG9uQGlzb2Mub3JnPG1haWx0bzp3aWx0b25A aXNvYy5vcmc+Pg0KVG86IENvbGluIFdhbGxpcyA8Q29saW4uV2FsbGlzQGRpYS5nb3Z0Lm56PG1h aWx0bzpDb2xpbi5XYWxsaXNAZGlhLmdvdnQubno+Pg0KQ2M6IEppbSBGZW50b24gPGZlbnRvbkBi bHVlcG9wY29ybi5uZXQ8bWFpbHRvOmZlbnRvbkBibHVlcG9wY29ybi5uZXQ+PiwgInZvdEBpZXRm Lm9yZzxtYWlsdG86dm90QGlldGYub3JnPiIgPHZvdEBpZXRmLm9yZzxtYWlsdG86dm90QGlldGYu b3JnPj4NCkRhdGU6IFR1ZSwgMTMgSmFuIDIwMTUgMDk6MzE6NTkgKzAwMDANClN1YmplY3Q6IFJl OiBbVm9UXSBjYXB0dXJpbmcgdGhlIHRocmVhZHMgb2YgdGhlIGRpc2N1c3Npb24NCk9vcHMgLSBJ J2QgZm9yZ290dGVuIGFib3V0IHRoZSB3aWtpOiBhcG9sb2dpZXMhIFllcywgSSB0aGluayB0aGF0 J3MgdGhlIHBsYWNlIHRvIHN0YXJ0Li4uDQoNClINCg0KUm9iaW4gV2lsdG9uDQoNClRlY2huaWNh bCBPdXRyZWFjaCBEaXJlY3RvciAtIElkZW50aXR5IGFuZCBQcml2YWN5DQoNCk9uIDEyIEphbiAy MDE1LCBhdCAyMzo0MywgIkNvbGluIFdhbGxpcyIgPENvbGluLldhbGxpc0BkaWEuZ292dC5uejxt YWlsdG86Q29saW4uV2FsbGlzQGRpYS5nb3Z0Lm56Pj4gd3JvdGU6DQoNCldlbGwgYXMgU3RldmUg TyBwb2ludGVkIG91dCBpbiB0aGlzIGF0dGFjaGVkIGVtYWlsIGluIE5vdmVtYmVyLCB0aGUgd2lr aSBzZXQgdXAgZm9yIHRoaXMgd29yayBtaWdodCBiZSBhIHBsYWNlIHRvIHN0YXJ0Li4NClRoZXJl IG1heSBiZSBzb21lIGppZ2dlcnkgcG9rZXJ5IHRvIGdldCB0aGUgZm9sa3Mgb24gdGhpcyBsaXN0 IHdobyB3YW50IHRvIGNvbnRyaWJ1dGUgKHdobyB3ZXJlIG5vdCBhdHRlbmRlZXMgYXQgVXRyZWNo dCkgYWNjZXNzIHJpZ2h0cywgYnV0IGl0IHdvdWxkIHNlZW0gdG8gbWUgdG8gYmUgdGhlIG9idmlv dXMgc3RhcnRlciBvcHRpb24gZm9yIGEgcmVwb3NpdG9yeS4NCkNoZWVycw0KQ29saW4NClBTOiBC VFcgdGhpcyBpcyBhIGdvb2QgZGlzY3Vzc2lvbiBhbmQgaW5kZWVkIGFuIG9wcG9ydHVuaXN0aWMg dGltZSB0byBicmluZyBpdCB0b2dldGhlciBzaW5jZSBzbyBtdWNoIG9mIHdoYXQgSnVzdGluLCBK aW0sIFNjb3R0LCBLZW4sIFN0ZXZlIFcsIE1hcmsgZXQgYWwgaGF2ZSBjb21tZW50ZWQgcmVjZW50 bHkgaXMgY29tcGxlbWVudGFyeSAod2VsbCBhdCBsZWFzdCBub3QgY29tcGxldGVseSBjb250cmFk aWN0b3J5IG9yIG9ydGhvZ29uYWwpIHNvIGxldOKAmXMgZ3JhYiBpdCENCg0KRnJvbTogdm90IFtt YWlsdG86dm90LWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnZvdC1ib3VuY2VzQGlldGYub3JnPl0g T24gQmVoYWxmIE9mIFJvYmluIFdpbHRvbg0KU2VudDogVHVlc2RheSwgMTMgSmFudWFyeSAyMDE1 IDExOjIyIGEubS4NClRvOiBKaW0gRmVudG9uDQpDYzogdm90QGlldGYub3JnPG1haWx0bzp2b3RA aWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW1ZvVF0gY2FwdHVyaW5nIHRoZSB0aHJlYWRzIG9mIHRo ZSBkaXNjdXNzaW9uDQoNClRoYW5rcyBKaW0sDQoNCkkgd29uJ3QgZ2l2ZSBhIHN1YnN0YW50aXZl IHJlc3BvbnNlIGhlcmU7IGp1c3QgdG8gbm90ZSB0aGF0IEkgdGhpbmsgaXQncyB3b3J0aCBjb25z aWRlcmluZyBhIHJlcG9zaXRvcnkgc28gdGhhdCB3ZSBjYW4gY2FwdHVyZSAnc3RhdGljJyB2ZXJz aW9ucyBvZiBhbnkgc3RyYXctbWFuIGRvY3MsIHRvIGNvbXBsZW1lbnQgd2hhdCB3ZSBpdCBpbnRv IHRoZSBtYWlsIHRocmVhZC4uLg0KDQpTb3JyeSB0byBiZSBicmllZiBhdCB0aGlzIHN0YWdlIC0g anVzdCB0eWluZyB1cCBzb21lIGxvb3NlIGVuZHMgYmVmb3JlIGFuIGFic2VuY2UgZnJvbSB0aGUg b2ZmaWNlLg0KDQpSDQoNClJvYmluIFdpbHRvbg0KDQpUZWNobmljYWwgT3V0cmVhY2ggRGlyZWN0 b3IgLSBJZGVudGl0eSBhbmQgUHJpdmFjeQ0KDQpPbiAxMiBKYW4gMjAxNSwgYXQgMjE6NDUsICJK aW0gRmVudG9uIiA8ZmVudG9uQGJsdWVwb3Bjb3JuLm5ldDxtYWlsdG86ZmVudG9uQGJsdWVwb3Bj b3JuLm5ldD4+IHdyb3RlOg0KTWF5YmUgSSBzaG91bGQgYmUgYnJlYWtpbmcgdGhlc2UgYXBhcnQg YXMgUm9iaW4gc3VnZ2VzdHMsIGJ1dCBmb3Igbm93IEknbGwga2VlcCB0aGlzIGluIG9uZSByZXBs eToNCg0KT24gMS8xMi8xNSA2OjA2IEFNLCBSb2JpbiBXaWx0b24gd3JvdGU6DQpUaGlzIHRocmVh ZCByYWlzZXMgc2V2ZXJhbCBpbXBvcnRhbnQgdG9waWNz4oCmIGp1c3QgYXMgYSBwcmFjdGljYWwg bWF0dGVyLCBpdCBtaWdodCBiZSB3b3J0aCB0cnlpbmcgdG8gc3BpbiBzb21lIG9mIHRoZW0gb2Zm IHNlcGFyYXRlbHksIHNvIHRoYXQgd2UgYWRkcmVzcyB0aGVtIGFsbCwgYW5kIG1pbmltaXNlIHRo ZSByaXNrIG9mIHRhbGtpbmcgYXQgY3Jvc3MtcHVycG9zZXMuDQpJdCBmZWVscyBsaWtlIGl0IHdv dWxkIGJlIHdvcnRoIHRyeWluZyB0byBwdXQgdG9nZXRoZXIgc29tZSAqdmVyeSBzaG9ydCogc3Ry YXctbWFuIGRvY3MvcGFnZXMvcGFyYWdyYXBocyB0byB0cnkgYW5kIGdldCBhIGNvbnNlbnN1cyB2 ZXJzaW9uIG9uIHNwZWNpZmljIHBvaW50cywgc28gdGhhdCB3ZSBhdm9pZCByZS1oYXNoaW5nIHRo ZSBzYW1lIGFyZ3VtZW50cy9kaXNjdXNzaW9ucyBvdmVyIHRpbWUsIG9yIGF0IGxlYXN0IGhhdmUg c29tZXRoaW5nIHdlIGNhbiByZWZlciB0byAtIGFuZCBhbWVuZCBpZiBuZWNlc3NhcnkuIEkgdGhp bmsgdGhpcyBpcyBhaW1pbmcgYXQgdGhlIHNhbWUgZW5kLXBvaW50IGFzIFN0ZXZl4oCZcyByZXF1 ZXN0IGZvciBhIHN0YXRlbWVudCBvZiByZXF1aXJlbWVudHMsIGJ1dCB3aWxsIGVuc3VyZSB3ZeKA mXJlIGV4cHJlc3Npbmcgb3VyIHJlcXVpcmVtZW50cyBpbiBhIGNvbnNpc3RlbnQgc2V0IG9mIHRl cm1zLg0KDQoNCkJ5IHRoZSBsb29rcyBvZiBpdCwgdGhlc2Ugd291bGQgbWFrZSBmb3IgYSBnb29k IHN0YXJ0aW5nIHBvaW50IChJIHRoaW5rIHRoZSBhbnN3ZXJzIHRvIG1vc3Qgb2YgdGhlc2UgYXJl IGltcGxpY2l0IGluIHZhcmlvdXMgcGVvcGxl4oCZcyBjb250cmlidXRpb25zIHRvIHRoZSB0aHJl YWTigKYgYnV0IHRoYXQgZG9lc27igJl0IG1lYW4gZXZlcnlvbmUgYWdyZWVzIDteKSAgKToNCg0K DQoxIC0gd2hhdCBkbyB3ZSBtZWFuIGJ5IGF1dGhlbnRpY2F0aW9uIGFuZCBhdXRob3Jpc2F0aW9u PyBBcmUgdGhlcmUgb3RoZXIgZGVjaXNpb25zIChlLmcuIGFjY2VzcyBjb250cm9sLCBlbnRpdGxl bWVudCkgd2hpY2ggbmVlZCB0byBiZSBjYWxsZWQgb3V0IGV4cGxpY2l0bHk/IFRoaXMgcmVmbGVj dHMgdGhlIHB1cnBvc2Ugb2YgSnVzdGlu4oCZcyBxdWVzdGlvbnMuIENsYXNzaWNhbGx5LCB0aGUg cmVhc29uIGZvciBhdXRoZW50aWNhdGluZyBhIHVzZXIgaXMgdG8gYW5zd2VyIGEgeWVzL25vIHF1 ZXN0aW9uIChpcyB0aGlzIHRoZSBwZXJzb24gdG8gd2hvbSB0aGlzIGNyZWRlbnRpYWwgd2FzIG9y aWdpbmFsbHkgaXNzdWVkKTsgaWYgeWVzLCB3aGF0IGRvIEkgd2FudCB0byBkbyBhYm91dCBpdCAo YXQgd2hpY2ggcG9pbnQgdGhlIGZ1cnRoZXIgZW50aXRsZW1lbnRzIGFyZSB1c3VhbGx5IGRldGVy bWluZWQgYnkgcmV0cmlldmluZyBhIHVzZXIgcHJvZmlsZSwgQUNMIG9yIHdoYXRldmVyKT8NCg0K QWNjZXNzIGNvbnRyb2wgYW5kIGVudGl0bGVtZW50IGFzIGRpc3RpbmN0IGZyb20gYXV0aG9yaXNh dGlvbj8gSXMgdGhlcmUgYSBkaXN0aW5jdGlvbiwgb3IgYXJlIHBlb3BsZSBqdXN0IHVzaW5nIGRp ZmZlcmVudCB0ZXJtaW5vbG9neT8NCg0KSSB0aGluayBvZiBhdXRoZW50aWNhdGlvbiBhcyBwcm92 aWRpbmcgbW9yZSB0aGFuIGEgeWVzL25vIGFuc3dlcjogaXQgcHJvdmlkZXMgYW4gaWRlbnRpZmll ci4gSWYgdGhlIHJlbHlpbmcgcGFydHkgaGFzIGVub3VnaCBpbmZvcm1hdGlvbiAocGVyaGFwcyBv biB0aGUgYmFzaXMgb2YgcHJldmlvdXMgaW50ZXJhY3Rpb25zKSB0byBhdXRob3JpemUgc29tZXRo aW5nIHdpdGgganVzdCB0aGF0LCBmaW5lLiBPdGhlcndpc2Ugc29tZSBhdHRyaWJ1dGVzIGFyZSBu ZWVkZWQgdG8gbWFrZSBhbiBhdXRob3Jpc2F0aW9uIGRlY2lzaW9uLg0KDQoNCkhvd2V2ZXIsIGFz IHdlIGtub3csIHRoZXNlIGRheXMgYWNjZXNzIGNvbnRyb2wgYW5kIGVudGl0bGVtZW50IGRlY2lz aW9ucyBhbHNvIG5lZWQgdG8gYmUgbWFkZSBvbiB0aGUgYmFzaXMgb2YgaW5wdXQgb3RoZXIgdGhh biBjbGFzc2ljIGNyZWRlbnRpYWxzLCBhbmQgdGhhdOKAmXMgb25lIG9mIHRoZSB0d28gY29yZXMg b2YgdGhpcyBkaXNjdXNzaW9uLCBJIGJlbGlldmUuDQoNCkV4YW1wbGUgb2YgYW4gImlucHV0IG90 aGVyIHRoYW4gY2xhc3NpYyBjcmVkZW50aWFscyI/DQoNCg0KDQoNCjIgLSB3aGF04oCZcyB0aGUg Y2xhc3NpYyBsaWZlY3ljbGUgb2YgYSBjcmVkZW50aWFsIC0gaS5lLiBhIGFydGVmYWN0IGludGVu ZGVkIHRvIHByb3ZpZGUgZXZpZGVuY2UgaW4gc3VwcG9ydCBvZiBhbiBhc3NlcnRpb24gb2YgaWRl bnRpdHkuIChlLmcuIHJlZ2lzdHJhdGlvbi92ZXJpZmljYXRpb24vZW5yb2xtZW50LCBjcmVkZW50 aWFsIGlzc3VlLCBjcmVkZW50aWFsIHByZXNlbnRhdGlvbi9hdXRoZW50aWNhdGlvbiwgY3JlZGVu dGlhbCBhbWVuZG1lbnQvcmV2b2NhdGlvbi9kZXN0cnVjdGlvbuKApik/DQoNCg0KQ3JlZGVudGlh bCBpcyBhbm90aGVyIG9mIHRob3NlIHRyaWNreSB3b3Jkcy4gU29tZXRpbWVzIGl0IG1lYW5zIHRo ZSBzYW1lIGFzIGFuIGF1dGhlbnRpY2F0aW9uIHRva2VuLiBTb21ldGltZXMgaXQgaGFzIHNvbWUg YXR0cmlidXRlcyBib3VuZCB0byBpdCwgd2hpY2ggbWVhbnMgaXQgaGFzIGJvdGggYW4gYXV0aGVu dGljYXRpb24gYW5kIGF0dHJpYnV0ZSBwcm92aXNpb24gZmxhdm9yIHRvIGl0LiBJIGZpbmQgaXQg c2ltcGxlciB0byB0YWxrIGFib3V0IHRva2Vucywgd2hlcmUgb25lIGRvZXNuJ3QgaGF2ZSB0byBk ZWFsIHdpdGggcmV2b2NhdGlvbiB3aGVuIHNvbWUgYXR0cmlidXRlIChlbXBsb3ltZW50LCBmb3Ig ZXhhbXBsZSkgY2hhbmdlcy4NCg0KDQoNCjMgLSBIb3cgZG9lcyAoMikgcmVsYXRlIHRvIG90aGVy IGFzc2VydGlvbnMgKGUuZy4gYXR0cmlidXRlIGFzc2VydGlvbnMpIHdlIHdvdWxkIGxpa2UgdG8g bWFrZSByZWxpYWJseT8NCg0KDQpXaXRoIHRoYXQgc3RhcnRlciBzZXQsIEkgdGhpbmsgd2UgY2Fu IGNvbmZpcm0gdGhlIHN1YnNldCBvZiByZXF1aXJlbWVudHMgdGhhdCA4MDAtNjMtMSBzdGlsbCBt ZWV0cywgYW5kIGRlZmluZSB0aGUgZGVsdGEgdGhhdCByZXF1aXJlcyBuZXcgZGVzaWduLg0KDQo0 IC0gV2hhdOKAmXMgdGhlIHJpZ2h0IHdheSB0byB1cGRhdGUgY3VycmVudCB0aGlua2luZyBvbiBM T0FzLCB0byBhY2NvdW50IGZvciB0aGUgY2hhbmdlIEppbSBkZXNjcmliZXMgaW4gaGlzIHByb3Bv c2FsIC0gaS5lLiwgdGhlIGNhc2Ugd2hlcmUgImNyZWRlbnRpYWxzICh1c2VkIGluIGF1dGhlbnRp Y2F0aW9uKSBhbmQgYXR0cmlidXRlIGluZm9ybWF0aW9uIChlc3RhYmxpc2hlZCB0aHJvdWdoIGlk ZW50aXR5IHByb29maW5nKSBjb3VsZCBiZSBwcm92aWRlZCBieSBkaWZmZXJlbnQgcGFydGllcy7i gJ0NCg0KNSAtIEZyb20gSmlt4oCZcyBwcm9wb3NhbDog4oCcQXR0cmlidXRlIHJlbGlhYmlsaXR5 IHJlZmVycyB0byB0aGUgcXVhbGl0eSBvZiB0aGUgaWRlbnRpdHkgcHJvb2ZpbmcgcHJvY2Vzcywg YXMgd2VsbCBhcyB0aGUgc3RyZW5ndGggb2YgdGhlIGJpbmRpbmcgb2YgdGhlIGlkZW50aWZ5aW5n IGF0dHJpYnV0ZXMgdG8gdGhlIGF1dGhlbnRpY2F0aW9uLuKAnSBEbyB3ZSBuZWVkL3dhbnQgdG8g ZXhwYW5kIG9uIHRoaXMgYSBsaXR0bGU/IFRoaXMgc2VlbXMgdG8gY2F0ZXIgd2VsbCBmb3IgdGhl IGNhc2Ugd2hlcmUsIHNheSwgdmVoaWNsZSBlbnRpdGxlbWVudHMgYXJlIGJlaW5nIGVzdGFibGlz aGVkIHNvIHRoYXQgdGhleSBjYW4gYmUgZW5jYXBzdWxhdGVkIGluIGEgZHJpdmluZyBsaWNlbmNl LiBJdOKAmXMgbm90IHNvIGNsZWFyIGhvdyB0aGlzIGFkZHJlc3Nlcywgc2F5LCB0aGlyZCBwYXJ0 eSBhc3NlcnRpb25zIHRoYXQgZG8gbm90IGFyaXNlIGZyb20gYW4gaWRlbnRpdHkgcHJvb2Zpbmcg cHJvY2VzcyAtIOKAnEkgaGF2ZSBubyBpZGVhICp3aG8qIHRoaXMgdXNlciBpcywgYnV0IEkgY2Fu IHJlbGlhYmx5IGFzc2VydCB0aGUgZm9sbG93aW5nIGFib3V0IHRoZW06IC4uLiDigJ0uDQoNCllv dSdyZSByaWdodDsgdGhhdCB3aWxsIG5lZWQgdG8gYmUgZGVmaW5lZC4gQnV0IGl0IHNob3VsZCBi ZSBwb3NzaWJsZSB0byBkZWZpbmUgYW5hbG9nb3VzIHJlcXVpcmVtZW50cyB0byBkZXNjcmliZSB0 aGUgc3RyZW5ndGggb2YgdGhlIGJpbmRpbmcgdG8gdGhlIHRva2VuLiBXaGVuIHlvdSBzaG93IHVw IHRvIGVucm9sbCBhdCBzY2hvb2wsIGl0IHNob3VsZCBiZSBwb3NzaWJsZSB0byB1c2UgeW91ciB0 b2tlbiB0byBhbGxvdyB5b3VyIHNjaG9vbCB0byBtYWtlIExPUiAzIGFzc2VydHMgdGhhdCB5b3Un cmUgdGhlcmUgc3R1ZGVudC4gQnV0IG1heWJlIHJlbW90ZSBzdHVkZW50cyBvbmx5IGdldCBMT1Ig Mj8NCg0KLUppbQ0KQWxsLQ0KVGhlcmUgdW5mb3J0dW5hdGVseSBpcyBhIGxvbmctc3RhbmRpbmcg YnVnIGluIENvbmZsdWVuY2UuIFlvdSBtdXN0IGJlIGxvZ2dlZCBpbiBiZWZvcmUgdGhhdCBsaW5r LCBvciBhbnkgbGluayB0byBhIHJlc3RyaWN0ZWQgcGFnZSwgd2lsbCB3b3JrLg0KDQpUaGUgd2lr aSBzcGFjZSBmb3Igd29ya3Nob3AgYXR0ZW5kZWVzIG9ubHksIHdoaWNoIHlvdSBhbGwgaGF2ZSBm dWxsIGVkaXQgYWNjZXNzIHRvIGFuZCB3aGljaCBpcyBub3QgcHVibGljbHkgdmlld2FibGUsIGlz IGF0aHR0cHM6Ly90aWQuaXNvYy5vcmcvY29uZmx1ZW5jZS9kaXNwbGF5L2ludGVyZmVkZ2VuLzxo dHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cC0zQV9fdGlkLmlz b2Mub3JnX2NvbmZsdWVuY2VfZGlzcGxheV9pbnRlcmZlZGdlbl8mZD1Bd01GYVEmYz02dmdOVGlS bjlfcHFDRDloS3g5SmdYTjFWYXBKUThKVm9GOG9XSDFBZ2ZRJnI9amdNdThETmdWX2R5Y3owcll3 a05iRVFxMzZGMEJJNV9acGJsejdDNUxoTSZtPTRRMHl3bWRaT21xNGVKekZjSy1aVUUyZ3JNOTZp WldPUGhvTFN3cEpLaUkmcz05T2Ewb1o4VHpRSVl3R3pidk5pellZekM5Q0JYaTFqWXZOTWZIMk9I OFJRJmU9Pg0KDQpUaGUgKlBVQkxJQyogd2lraSBzcGFjZSwgY29udGFpbmluZyB0aGUgYWdlbmRh LCBwcmVzZW50YXRpb25zLCBhbmQgY29udHJpYnV0aW9ucy9yZWZlcmVuY2VzLCBpcyBhdA0KaHR0 cHM6Ly90aWQuaXNvYy5vcmcvY29uZmx1ZW5jZS9kaXNwbGF5L2ludGVyZmVkLzxodHRwczovL3Vy bGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3RpZC5pc29jLm9yZ19j b25mbHVlbmNlX2Rpc3BsYXlfaW50ZXJmZWRfJmQ9QXdNRmFRJmM9NnZnTlRpUm45X3BxQ0Q5aEt4 OUpnWE4xVmFwSlE4SlZvRjhvV0gxQWdmUSZyPWpnTXU4RE5nVl9keWN6MHJZd2tOYkVRcTM2RjBC STVfWnBibHo3QzVMaE0mbT00UTB5d21kWk9tcTRlSnpGY0stWlVFMmdyTTk2aVpXT1Bob0xTd3BK S2lJJnM9MTNBZERsa2R3U1ZuS01yek5uTWpTNlhHdmx1YlpVdXVMUnhqWG5DZnlRcyZlPT4NCg0K QXMgd2UgbWFrZSBwcm9ncmVzcyBvbiB3b3JrIGl0ZW1zIGFuZCBhcmUgcmVhZHkgdG8gbW92ZSB0 aGVtIHRvIHRoZSBwdWJsaWMgd2lraSwgSSB3aWxsIGJlIGhhcHB5IHRvIGRvIHRoYXQuIE91ciBn b2FsIGlzIG9mIGNvdXJzZSB0byBtYWtlIGFzIG11Y2ggb2Ygb3VyIHdvcmsgYXMgcG9zc2libGUg YXZhaWxhYmxlIHRvIHRoZSBwdWJsaWMsIGJ1dCB0aGlzIHJlc3RyaWN0ZWQgd2lraSBzcGFjZSBn aXZlcyB1cyBhIHBsYWNlIHRvIHdvcmsgb24gdGhpbmdzIGJlZm9yZSByZXZlYWxpbmcgdGhlbSB0 byB0aGUgd29ybGQuDQoNCkFzIGFsd2F5cywgaWYgYW55b25lIGhhcyBxdWVzdGlvbnMgb3IgcHJv YmxlbXMgcmVsYXRlZCB0byB0aGUgd2lraSwgb3IgYW55dGhpbmcgZWxzZSwgcGxlYXNlIGRvIGxl dCBtZSBrbm93Lg0KICAgICAgIFN0ZXZlDQoNCi0tDQpTdGV2ZSBPbHNoYW5za3kNClRydXN0ICYg SWRlbnRpdHkgUHJvZ3JhbSBMZWFkDQpJbnRlcm5ldCBTb2NpZXR5DQp3d3cuaW50ZXJuZXRzb2Np ZXR5Lm9yZzxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cC0z QV9fd3d3LmludGVybmV0c29jaWV0eS5vcmcmZD1Bd01GYVEmYz02dmdOVGlSbjlfcHFDRDloS3g5 SmdYTjFWYXBKUThKVm9GOG9XSDFBZ2ZRJnI9amdNdThETmdWX2R5Y3owcll3a05iRVFxMzZGMEJJ NV9acGJsejdDNUxoTSZtPTRRMHl3bWRaT21xNGVKekZjSy1aVUUyZ3JNOTZpWldPUGhvTFN3cEpL aUkmcz1uaHRHUjd1YXg3OHItdmpUX1FPd3RoZ1Z4NXZGSzJvY1JVS2NQZzRGNjVrJmU9Pg0KDQoN CjxzaWduYXR1cmUuYXNjPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCklkZWNvLWZhYiBtYWlsaW5nIGxpc3QNCklkZWNvLWZhYkBlbGlzdHMuaXNvYy5v cmc8bWFpbHRvOklkZWNvLWZhYkBlbGlzdHMuaXNvYy5vcmc+DQpodHRwczovL2VsaXN0cy5pc29j Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkZWNvLWZhYjxodHRwczovL3VybGRlZmVuc2UucHJvb2Zw b2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX2VsaXN0cy5pc29jLm9yZ19tYWlsbWFuX2xpc3Rp bmZvX2lkZWNvLTJEZmFiJmQ9QXdNRmFRJmM9NnZnTlRpUm45X3BxQ0Q5aEt4OUpnWE4xVmFwSlE4 SlZvRjhvV0gxQWdmUSZyPWpnTXU4RE5nVl9keWN6MHJZd2tOYkVRcTM2RjBCSTVfWnBibHo3QzVM aE0mbT00UTB5d21kWk9tcTRlSnpGY0stWlVFMmdyTTk2aVpXT1Bob0xTd3BKS2lJJnM9UlNIU0JH UUhFVzVFWHloTENpR0VMNkMwSDNyZFBEMTJsbnJqLS1qSmVrayZlPT4NCg0KDQotLS0tLS0tLS0t IEZvcndhcmRlZCBtZXNzYWdlIC0tLS0tLS0tLS0NCkZyb206IFN0ZXZlIE9sc2hhbnNreSA8b2xz aGFuc2t5QGlzb2Mub3JnPG1haWx0bzpvbHNoYW5za3lAaXNvYy5vcmc+Pg0KVG86ICJ2b3RAaWV0 Zi5vcmc8bWFpbHRvOnZvdEBpZXRmLm9yZz4iIDx2b3RAaWV0Zi5vcmc8bWFpbHRvOnZvdEBpZXRm Lm9yZz4+DQpDYzoNCkRhdGU6IFR1ZSwgMTMgSmFuIDIwMTUgMTM6MTk6MjIgKzAwMDANClN1Ympl Y3Q6IFtWb1RdIFZvVCB3aWtpDQpBbGwtDQpUaGlzIGlzIGEgZ3JlYXQgZGlzY3Vzc2lvbiwgYW5k IHRoZSBzdGFycyBzZWVtIHRvIGJlIGFsaWduaW5nIG5vdyBmb3IgdGhlIGRldmVsb3BtZW50IG9m IHNvbWUgZG9jdW1lbnRzIG9yIGFueSBvdGhlciByZWxhdGVkIGFydGlmYWN0cy4NCg0KSSBzZXR1 cCBhIGRlZGljYXRlZCB3aWtpIHNwYWNlIGZvciB1c2UgYnkgdGhpcyBncm91cC4gSXQgaXMgb3Bl biB0byB0aGUgd29ybGQgZm9yIHZpZXdpbmcsIGJ1dCB3ZSBjYW4gZWFzaWx5IG1ha2UgcmVzdHJp Y3RlZCBhcmVhcyBmb3IgdGhlIHB1cnBvc2Ugb2Ygd29ya2luZyBvbiBkb2N1bWVudHMgYmVmb3Jl IHB1Ymxpc2hpbmcuIEFueW9uZSB3b3VsZCB3b3VsZCBsaWtlIGVkaXQgYWNjZXNzIGlzIHdlbGNv bWUgdG8gY29udGFjdCBtZSBkaXJlY3RseSAob2ZmLWxpc3QpLg0KaHR0cHM6Ly90aWQuaXNvYy5v cmcvY29uZmx1ZW5jZS9kaXNwbGF5L3ZvdC9Wb1QrSG9tZTxodHRwczovL3VybGRlZmVuc2UucHJv b2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3RpZC5pc29jLm9yZ19jb25mbHVlbmNlX2Rp c3BsYXlfdm90X1ZvVC0yQkhvbWUmZD1Bd01GYVEmYz02dmdOVGlSbjlfcHFDRDloS3g5SmdYTjFW YXBKUThKVm9GOG9XSDFBZ2ZRJnI9amdNdThETmdWX2R5Y3owcll3a05iRVFxMzZGMEJJNV9acGJs ejdDNUxoTSZtPTRRMHl3bWRaT21xNGVKekZjSy1aVUUyZ3JNOTZpWldPUGhvTFN3cEpLaUkmcz1v MUdFYno0MFJtTWZTNTFGZXFvVFc3RkktVk9PWnhyZ3k5b1VwUHBVZ2RrJmU9Pg0KICAgICAgICBT dGV2ZQ0KDQotLQ0KU3RldmUgT2xzaGFuc2t5DQpUcnVzdCAmIElkZW50aXR5IFByb2dyYW0gTGVh ZA0KSW50ZXJuZXQgU29jaWV0eQ0Kd3d3LmludGVybmV0c29jaWV0eS5vcmc8aHR0cHM6Ly91cmxk ZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAtM0FfX3d3dy5pbnRlcm5ldHNvY2ll dHkub3JnJmQ9QXdNRmFRJmM9NnZnTlRpUm45X3BxQ0Q5aEt4OUpnWE4xVmFwSlE4SlZvRjhvV0gx QWdmUSZyPWpnTXU4RE5nVl9keWN6MHJZd2tOYkVRcTM2RjBCSTVfWnBibHo3QzVMaE0mbT00UTB5 d21kWk9tcTRlSnpGY0stWlVFMmdyTTk2aVpXT1Bob0xTd3BKS2lJJnM9bmh0R1I3dWF4NzhyLXZq VF9RT3d0aGdWeDV2Rksyb2NSVUtjUGc0RjY1ayZlPT4NCg0KT24gSmFuIDEzLCAyMDE1LCBhdCAy OjMxIEFNLCBSb2JpbiBXaWx0b24gPHdpbHRvbkBpc29jLm9yZzxtYWlsdG86d2lsdG9uQGlzb2Mu b3JnPj4gd3JvdGU6DQoNCj4gT29wcyAtIEknZCBmb3Jnb3R0ZW4gYWJvdXQgdGhlIHdpa2k6IGFw b2xvZ2llcyEgWWVzLCBJIHRoaW5rIHRoYXQncyB0aGUgcGxhY2UgdG8gc3RhcnQuLi4NCj4NCj4g Ug0KPg0KPiBSb2JpbiBXaWx0b24NCj4NCj4gVGVjaG5pY2FsIE91dHJlYWNoIERpcmVjdG9yIC0g SWRlbnRpdHkgYW5kIFByaXZhY3kNCj4NCj4gT24gMTIgSmFuIDIwMTUsIGF0IDIzOjQzLCAiQ29s aW4gV2FsbGlzIiA8Q29saW4uV2FsbGlzQGRpYS5nb3Z0Lm56PG1haWx0bzpDb2xpbi5XYWxsaXNA ZGlhLmdvdnQubno+PiB3cm90ZToNCj4NCj4+IFdlbGwgYXMgU3RldmUgTyBwb2ludGVkIG91dCBp biB0aGlzIGF0dGFjaGVkIGVtYWlsIGluIE5vdmVtYmVyLCB0aGUgd2lraSBzZXQgdXAgZm9yIHRo aXMgd29yayBtaWdodCBiZSBhIHBsYWNlIHRvIHN0YXJ0Li4NCj4+IFRoZXJlIG1heSBiZSBzb21l IGppZ2dlcnkgcG9rZXJ5IHRvIGdldCB0aGUgZm9sa3Mgb24gdGhpcyBsaXN0IHdobyB3YW50IHRv IGNvbnRyaWJ1dGUgKHdobyB3ZXJlIG5vdCBhdHRlbmRlZXMgYXQgVXRyZWNodCkgYWNjZXNzIHJp Z2h0cywgYnV0IGl0IHdvdWxkIHNlZW0gdG8gbWUgdG8gYmUgdGhlIG9idmlvdXMgc3RhcnRlciBv cHRpb24gZm9yIGEgcmVwb3NpdG9yeS4NCj4+IENoZWVycw0KPj4gQ29saW4NCj4+IFBTOiBCVFcg dGhpcyBpcyBhIGdvb2QgZGlzY3Vzc2lvbiBhbmQgaW5kZWVkIGFuIG9wcG9ydHVuaXN0aWMgdGlt ZSB0byBicmluZyBpdCB0b2dldGhlciBzaW5jZSBzbyBtdWNoIG9mIHdoYXQgSnVzdGluLCBKaW0s IFNjb3R0LCBLZW4sIFN0ZXZlIFcsIE1hcmsgZXQgYWwgaGF2ZSBjb21tZW50ZWQgcmVjZW50bHkg aXMgY29tcGxlbWVudGFyeSAod2VsbCBhdCBsZWFzdCBub3QgY29tcGxldGVseSBjb250cmFkaWN0 b3J5IG9yIG9ydGhvZ29uYWwpIHNvIGxldOKAmXMgZ3JhYiBpdCENCj4+DQo+PiBGcm9tOiB2b3Qg W21haWx0bzp2b3QtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86dm90LWJvdW5jZXNAaWV0Zi5vcmc+ XSBPbiBCZWhhbGYgT2YgUm9iaW4gV2lsdG9uDQo+PiBTZW50OiBUdWVzZGF5LCAxMyBKYW51YXJ5 IDIwMTUgMTE6MjIgYS5tLg0KPj4gVG86IEppbSBGZW50b24NCj4+IENjOiB2b3RAaWV0Zi5vcmc8 bWFpbHRvOnZvdEBpZXRmLm9yZz4NCj4+IFN1YmplY3Q6IFJlOiBbVm9UXSBjYXB0dXJpbmcgdGhl IHRocmVhZHMgb2YgdGhlIGRpc2N1c3Npb24NCj4+DQo+PiBUaGFua3MgSmltLA0KPj4NCj4+IEkg d29uJ3QgZ2l2ZSBhIHN1YnN0YW50aXZlIHJlc3BvbnNlIGhlcmU7IGp1c3QgdG8gbm90ZSB0aGF0 IEkgdGhpbmsgaXQncyB3b3J0aCBjb25zaWRlcmluZyBhIHJlcG9zaXRvcnkgc28gdGhhdCB3ZSBj YW4gY2FwdHVyZSAnc3RhdGljJyB2ZXJzaW9ucyBvZiBhbnkgc3RyYXctbWFuIGRvY3MsIHRvIGNv bXBsZW1lbnQgd2hhdCB3ZSBpdCBpbnRvIHRoZSBtYWlsIHRocmVhZC4uLg0KPj4NCj4+IFNvcnJ5 IHRvIGJlIGJyaWVmIGF0IHRoaXMgc3RhZ2UgLSBqdXN0IHR5aW5nIHVwIHNvbWUgbG9vc2UgZW5k cyBiZWZvcmUgYW4gYWJzZW5jZSBmcm9tIHRoZSBvZmZpY2UuDQo+Pg0KPj4gUg0KPj4NCj4+IFJv YmluIFdpbHRvbg0KPj4NCj4+IFRlY2huaWNhbCBPdXRyZWFjaCBEaXJlY3RvciAtIElkZW50aXR5 IGFuZCBQcml2YWN5DQo+Pg0KPj4gT24gMTIgSmFuIDIwMTUsIGF0IDIxOjQ1LCAiSmltIEZlbnRv biIgPGZlbnRvbkBibHVlcG9wY29ybi5uZXQ8bWFpbHRvOmZlbnRvbkBibHVlcG9wY29ybi5uZXQ+ PiB3cm90ZToNCj4+DQo+PiBNYXliZSBJIHNob3VsZCBiZSBicmVha2luZyB0aGVzZSBhcGFydCBh cyBSb2JpbiBzdWdnZXN0cywgYnV0IGZvciBub3cgSSdsbCBrZWVwIHRoaXMgaW4gb25lIHJlcGx5 Og0KPj4NCj4+IE9uIDEvMTIvMTUgNjowNiBBTSwgUm9iaW4gV2lsdG9uIHdyb3RlOg0KPj4gVGhp cyB0aHJlYWQgcmFpc2VzIHNldmVyYWwgaW1wb3J0YW50IHRvcGljc+KApiBqdXN0IGFzIGEgcHJh Y3RpY2FsIG1hdHRlciwgaXQgbWlnaHQgYmUgd29ydGggdHJ5aW5nIHRvIHNwaW4gc29tZSBvZiB0 aGVtIG9mZiBzZXBhcmF0ZWx5LCBzbyB0aGF0IHdlIGFkZHJlc3MgdGhlbSBhbGwsIGFuZCBtaW5p bWlzZSB0aGUgcmlzayBvZiB0YWxraW5nIGF0IGNyb3NzLXB1cnBvc2VzLg0KPj4gSXQgZmVlbHMg bGlrZSBpdCB3b3VsZCBiZSB3b3J0aCB0cnlpbmcgdG8gcHV0IHRvZ2V0aGVyIHNvbWUgKnZlcnkg c2hvcnQqIHN0cmF3LW1hbiBkb2NzL3BhZ2VzL3BhcmFncmFwaHMgdG8gdHJ5IGFuZCBnZXQgYSBj b25zZW5zdXMgdmVyc2lvbiBvbiBzcGVjaWZpYyBwb2ludHMsIHNvIHRoYXQgd2UgYXZvaWQgcmUt aGFzaGluZyB0aGUgc2FtZSBhcmd1bWVudHMvZGlzY3Vzc2lvbnMgb3ZlciB0aW1lLCBvciBhdCBs ZWFzdCBoYXZlIHNvbWV0aGluZyB3ZSBjYW4gcmVmZXIgdG8gLSBhbmQgYW1lbmQgaWYgbmVjZXNz YXJ5LiBJIHRoaW5rIHRoaXMgaXMgYWltaW5nIGF0IHRoZSBzYW1lIGVuZC1wb2ludCBhcyBTdGV2 ZeKAmXMgcmVxdWVzdCBmb3IgYSBzdGF0ZW1lbnQgb2YgcmVxdWlyZW1lbnRzLCBidXQgd2lsbCBl bnN1cmUgd2XigJlyZSBleHByZXNzaW5nIG91ciByZXF1aXJlbWVudHMgaW4gYSBjb25zaXN0ZW50 IHNldCBvZiB0ZXJtcy4NCj4+DQo+Pg0KPj4gQnkgdGhlIGxvb2tzIG9mIGl0LCB0aGVzZSB3b3Vs ZCBtYWtlIGZvciBhIGdvb2Qgc3RhcnRpbmcgcG9pbnQgKEkgdGhpbmsgdGhlIGFuc3dlcnMgdG8g bW9zdCBvZiB0aGVzZSBhcmUgaW1wbGljaXQgaW4gdmFyaW91cyBwZW9wbGXigJlzIGNvbnRyaWJ1 dGlvbnMgdG8gdGhlIHRocmVhZOKApiBidXQgdGhhdCBkb2VzbuKAmXQgbWVhbiBldmVyeW9uZSBh Z3JlZXMgO14pICApOg0KPj4NCj4+DQo+PiAxIC0gd2hhdCBkbyB3ZSBtZWFuIGJ5IGF1dGhlbnRp Y2F0aW9uIGFuZCBhdXRob3Jpc2F0aW9uPyBBcmUgdGhlcmUgb3RoZXIgZGVjaXNpb25zIChlLmcu IGFjY2VzcyBjb250cm9sLCBlbnRpdGxlbWVudCkgd2hpY2ggbmVlZCB0byBiZSBjYWxsZWQgb3V0 IGV4cGxpY2l0bHk/IFRoaXMgcmVmbGVjdHMgdGhlIHB1cnBvc2Ugb2YgSnVzdGlu4oCZcyBxdWVz dGlvbnMuIENsYXNzaWNhbGx5LCB0aGUgcmVhc29uIGZvciBhdXRoZW50aWNhdGluZyBhIHVzZXIg aXMgdG8gYW5zd2VyIGEgeWVzL25vIHF1ZXN0aW9uIChpcyB0aGlzIHRoZSBwZXJzb24gdG8gd2hv bSB0aGlzIGNyZWRlbnRpYWwgd2FzIG9yaWdpbmFsbHkgaXNzdWVkKTsgaWYgeWVzLCB3aGF0IGRv IEkgd2FudCB0byBkbyBhYm91dCBpdCAoYXQgd2hpY2ggcG9pbnQgdGhlIGZ1cnRoZXIgZW50aXRs ZW1lbnRzIGFyZSB1c3VhbGx5IGRldGVybWluZWQgYnkgcmV0cmlldmluZyBhIHVzZXIgcHJvZmls ZSwgQUNMIG9yIHdoYXRldmVyKT8NCj4+DQo+PiBBY2Nlc3MgY29udHJvbCBhbmQgZW50aXRsZW1l bnQgYXMgZGlzdGluY3QgZnJvbSBhdXRob3Jpc2F0aW9uPyBJcyB0aGVyZSBhIGRpc3RpbmN0aW9u LCBvciBhcmUgcGVvcGxlIGp1c3QgdXNpbmcgZGlmZmVyZW50IHRlcm1pbm9sb2d5Pw0KPj4NCj4+ IEkgdGhpbmsgb2YgYXV0aGVudGljYXRpb24gYXMgcHJvdmlkaW5nIG1vcmUgdGhhbiBhIHllcy9u byBhbnN3ZXI6IGl0IHByb3ZpZGVzIGFuIGlkZW50aWZpZXIuIElmIHRoZSByZWx5aW5nIHBhcnR5 IGhhcyBlbm91Z2ggaW5mb3JtYXRpb24gKHBlcmhhcHMgb24gdGhlIGJhc2lzIG9mIHByZXZpb3Vz IGludGVyYWN0aW9ucykgdG8gYXV0aG9yaXplIHNvbWV0aGluZyB3aXRoIGp1c3QgdGhhdCwgZmlu ZS4gT3RoZXJ3aXNlIHNvbWUgYXR0cmlidXRlcyBhcmUgbmVlZGVkIHRvIG1ha2UgYW4gYXV0aG9y aXNhdGlvbiBkZWNpc2lvbi4NCj4+DQo+Pg0KPj4gSG93ZXZlciwgYXMgd2Uga25vdywgdGhlc2Ug ZGF5cyBhY2Nlc3MgY29udHJvbCBhbmQgZW50aXRsZW1lbnQgZGVjaXNpb25zIGFsc28gbmVlZCB0 byBiZSBtYWRlIG9uIHRoZSBiYXNpcyBvZiBpbnB1dCBvdGhlciB0aGFuIGNsYXNzaWMgY3JlZGVu dGlhbHMsIGFuZCB0aGF04oCZcyBvbmUgb2YgdGhlIHR3byBjb3JlcyBvZiB0aGlzIGRpc2N1c3Np b24sIEkgYmVsaWV2ZS4NCj4+DQo+PiBFeGFtcGxlIG9mIGFuICJpbnB1dCBvdGhlciB0aGFuIGNs YXNzaWMgY3JlZGVudGlhbHMiPw0KPj4NCj4+DQo+Pg0KPj4NCj4+IDIgLSB3aGF04oCZcyB0aGUg Y2xhc3NpYyBsaWZlY3ljbGUgb2YgYSBjcmVkZW50aWFsIC0gaS5lLiBhIGFydGVmYWN0IGludGVu ZGVkIHRvIHByb3ZpZGUgZXZpZGVuY2UgaW4gc3VwcG9ydCBvZiBhbiBhc3NlcnRpb24gb2YgaWRl bnRpdHkuIChlLmcuIHJlZ2lzdHJhdGlvbi92ZXJpZmljYXRpb24vZW5yb2xtZW50LCBjcmVkZW50 aWFsIGlzc3VlLCBjcmVkZW50aWFsIHByZXNlbnRhdGlvbi9hdXRoZW50aWNhdGlvbiwgY3JlZGVu dGlhbCBhbWVuZG1lbnQvcmV2b2NhdGlvbi9kZXN0cnVjdGlvbuKApik/DQo+Pg0KPj4NCj4+IENy ZWRlbnRpYWwgaXMgYW5vdGhlciBvZiB0aG9zZSB0cmlja3kgd29yZHMuIFNvbWV0aW1lcyBpdCBt ZWFucyB0aGUgc2FtZSBhcyBhbiBhdXRoZW50aWNhdGlvbiB0b2tlbi4gU29tZXRpbWVzIGl0IGhh cyBzb21lIGF0dHJpYnV0ZXMgYm91bmQgdG8gaXQsIHdoaWNoIG1lYW5zIGl0IGhhcyBib3RoIGFu IGF1dGhlbnRpY2F0aW9uIGFuZCBhdHRyaWJ1dGUgcHJvdmlzaW9uIGZsYXZvciB0byBpdC4gSSBm aW5kIGl0IHNpbXBsZXIgdG8gdGFsayBhYm91dCB0b2tlbnMsIHdoZXJlIG9uZSBkb2Vzbid0IGhh dmUgdG8gZGVhbCB3aXRoIHJldm9jYXRpb24gd2hlbiBzb21lIGF0dHJpYnV0ZSAoZW1wbG95bWVu dCwgZm9yIGV4YW1wbGUpIGNoYW5nZXMuDQo+Pg0KPj4NCj4+DQo+PiAzIC0gSG93IGRvZXMgKDIp IHJlbGF0ZSB0byBvdGhlciBhc3NlcnRpb25zIChlLmcuIGF0dHJpYnV0ZSBhc3NlcnRpb25zKSB3 ZSB3b3VsZCBsaWtlIHRvIG1ha2UgcmVsaWFibHk/DQo+Pg0KPj4NCj4+IFdpdGggdGhhdCBzdGFy dGVyIHNldCwgSSB0aGluayB3ZSBjYW4gY29uZmlybSB0aGUgc3Vic2V0IG9mIHJlcXVpcmVtZW50 cyB0aGF0IDgwMC02My0xIHN0aWxsIG1lZXRzLCBhbmQgZGVmaW5lIHRoZSBkZWx0YSB0aGF0IHJl cXVpcmVzIG5ldyBkZXNpZ24uDQo+Pg0KPj4gNCAtIFdoYXTigJlzIHRoZSByaWdodCB3YXkgdG8g dXBkYXRlIGN1cnJlbnQgdGhpbmtpbmcgb24gTE9BcywgdG8gYWNjb3VudCBmb3IgdGhlIGNoYW5n ZSBKaW0gZGVzY3JpYmVzIGluIGhpcyBwcm9wb3NhbCAtIGkuZS4sIHRoZSBjYXNlIHdoZXJlICJj cmVkZW50aWFscyAodXNlZCBpbiBhdXRoZW50aWNhdGlvbikgYW5kIGF0dHJpYnV0ZSBpbmZvcm1h dGlvbiAoZXN0YWJsaXNoZWQgdGhyb3VnaCBpZGVudGl0eSBwcm9vZmluZykgY291bGQgYmUgcHJv dmlkZWQgYnkgZGlmZmVyZW50IHBhcnRpZXMu4oCdDQo+Pg0KPj4gNSAtIEZyb20gSmlt4oCZcyBw cm9wb3NhbDog4oCcQXR0cmlidXRlIHJlbGlhYmlsaXR5IHJlZmVycyB0byB0aGUgcXVhbGl0eSBv ZiB0aGUgaWRlbnRpdHkgcHJvb2ZpbmcgcHJvY2VzcywgYXMgd2VsbCBhcyB0aGUgc3RyZW5ndGgg b2YgdGhlIGJpbmRpbmcgb2YgdGhlIGlkZW50aWZ5aW5nIGF0dHJpYnV0ZXMgdG8gdGhlIGF1dGhl bnRpY2F0aW9uLuKAnSBEbyB3ZSBuZWVkL3dhbnQgdG8gZXhwYW5kIG9uIHRoaXMgYSBsaXR0bGU/ IFRoaXMgc2VlbXMgdG8gY2F0ZXIgd2VsbCBmb3IgdGhlIGNhc2Ugd2hlcmUsIHNheSwgdmVoaWNs ZSBlbnRpdGxlbWVudHMgYXJlIGJlaW5nIGVzdGFibGlzaGVkIHNvIHRoYXQgdGhleSBjYW4gYmUg ZW5jYXBzdWxhdGVkIGluIGEgZHJpdmluZyBsaWNlbmNlLiBJdOKAmXMgbm90IHNvIGNsZWFyIGhv dyB0aGlzIGFkZHJlc3Nlcywgc2F5LCB0aGlyZCBwYXJ0eSBhc3NlcnRpb25zIHRoYXQgZG8gbm90 IGFyaXNlIGZyb20gYW4gaWRlbnRpdHkgcHJvb2ZpbmcgcHJvY2VzcyAtIOKAnEkgaGF2ZSBubyBp ZGVhICp3aG8qIHRoaXMgdXNlciBpcywgYnV0IEkgY2FuIHJlbGlhYmx5IGFzc2VydCB0aGUgZm9s bG93aW5nIGFib3V0IHRoZW06IC4uLiDigJ0uDQo+Pg0KPj4gWW91J3JlIHJpZ2h0OyB0aGF0IHdp bGwgbmVlZCB0byBiZSBkZWZpbmVkLiBCdXQgaXQgc2hvdWxkIGJlIHBvc3NpYmxlIHRvIGRlZmlu ZSBhbmFsb2dvdXMgcmVxdWlyZW1lbnRzIHRvIGRlc2NyaWJlIHRoZSBzdHJlbmd0aCBvZiB0aGUg YmluZGluZyB0byB0aGUgdG9rZW4uIFdoZW4geW91IHNob3cgdXAgdG8gZW5yb2xsIGF0IHNjaG9v bCwgaXQgc2hvdWxkIGJlIHBvc3NpYmxlIHRvIHVzZSB5b3VyIHRva2VuIHRvIGFsbG93IHlvdXIg c2Nob29sIHRvIG1ha2UgTE9SIDMgYXNzZXJ0cyB0aGF0IHlvdSdyZSB0aGVyZSBzdHVkZW50LiBC dXQgbWF5YmUgcmVtb3RlIHN0dWRlbnRzIG9ubHkgZ2V0IExPUiAyPw0KPj4NCj4+IC1KaW0NCj4+ DQo+IHZvdCBtYWlsaW5nIGxpc3QNCj4gdm90QGlldGYub3JnPG1haWx0bzp2b3RAaWV0Zi5vcmc+ DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdm90PGh0dHBzOi8vdXJs ZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21h aWxtYW5fbGlzdGluZm9fdm90JmQ9QXdNRmFRJmM9NnZnTlRpUm45X3BxQ0Q5aEt4OUpnWE4xVmFw SlE4SlZvRjhvV0gxQWdmUSZyPWpnTXU4RE5nVl9keWN6MHJZd2tOYkVRcTM2RjBCSTVfWnBibHo3 QzVMaE0mbT00UTB5d21kWk9tcTRlSnpGY0stWlVFMmdyTTk2aVpXT1Bob0xTd3BKS2lJJnM9dWM5 MTNxc0xBNmJaMzRyTGZ1U2Mzc2lnN1pjSXlrR0RSZVo3M1d4MjFMMCZlPT4NCg0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kdm90IG1haWxpbmcgbGlz dA0Kdm90QGlldGYub3JnPG1haWx0bzp2b3RAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3ZvdDxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20v djIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX3ZvdCZkPUF3 TUZhUSZjPTZ2Z05UaVJuOV9wcUNEOWhLeDlKZ1hOMVZhcEpROEpWb0Y4b1dIMUFnZlEmcj1qZ011 OEROZ1ZfZHljejByWXdrTmJFUXEzNkYwQkk1X1pwYmx6N0M1TGhNJm09NFEweXdtZFpPbXE0ZUp6 RmNLLVpVRTJnck05NmlaV09QaG9MU3dwSktpSSZzPXVjOTEzcXNMQTZiWjM0ckxmdVNjM3NpZzda Y0l5a0dEUmVaNzNXeDIxTDAmZT0+DQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCnZvdCBtYWlsaW5nIGxpc3QNCnZvdEBpZXRmLm9yZzxtYWlsdG86 dm90QGlldGYub3JnPg0KaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91 PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb192b3QmZD1Bd0lDQWcmYz02 dmdOVGlSbjlfcHFDRDloS3g5SmdYTjFWYXBKUThKVm9GOG9XSDFBZ2ZRJnI9amdNdThETmdWX2R5 Y3owcll3a05iRVFxMzZGMEJJNV9acGJsejdDNUxoTSZtPTRRMHl3bWRaT21xNGVKekZjSy1aVUUy Z3JNOTZpWldPUGhvTFN3cEpLaUkmcz11YzkxM3FzTEE2YlozNHJMZnVTYzNzaWc3WmNJeWtHRFJl WjczV3gyMUwwJmU9DQo= From nobody Tue Jan 13 10:52:30 2015 Return-Path: X-Original-To: vot@ietfa.amsl.com Delivered-To: vot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 361201A90F5 for ; Tue, 13 Jan 2015 10:52:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.398 X-Spam-Level: X-Spam-Status: No, score=0.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_MARKET=2.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_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 jRiR1pH0rJVu for ; Tue, 13 Jan 2015 10:52:18 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0088.outbound.protection.outlook.com [207.46.100.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 827EC1A90F1 for ; Tue, 13 Jan 2015 10:52:18 -0800 (PST) Received: from BLUPR06MB243.namprd06.prod.outlook.com (10.242.191.154) by BLUPR06MB243.namprd06.prod.outlook.com (10.242.191.154) with Microsoft SMTP Server (TLS) id 15.1.53.17; Tue, 13 Jan 2015 18:52:16 +0000 Received: from BLUPR06MB243.namprd06.prod.outlook.com ([169.254.7.154]) by BLUPR06MB243.namprd06.prod.outlook.com ([169.254.7.154]) with mapi id 15.01.0053.000; Tue, 13 Jan 2015 18:52:16 +0000 From: Steve Olshansky To: "vot@ietf.org" Thread-Topic: Electronic Identity Credential Trust Elevation Framework Version 1.0 Thread-Index: AQHQL2IMVKpR99U1sEi9+uiLQ8bY/Q== Date: Tue, 13 Jan 2015 18:52:16 +0000 Message-ID: <05B62D2C-82A6-42C9-B28A-1AB20C718D12@isoc.org> References: <6FD710F3-28D3-481E-B5A5-7444ECB7FBE0@uth.tmc.edu> In-Reply-To: <6FD710F3-28D3-481E-B5A5-7444ECB7FBE0@uth.tmc.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [97.124.189.208] authentication-results: spf=none (sender IP is ) smtp.mailfrom=olshansky@isoc.org; x-dmarcaction-test: None x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005003);SRVR:BLUPR06MB243; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:BLUPR06MB243; x-forefront-prvs: 045584D28C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(24454002)(479174004)(51444003)(24433001)(27574002)(377454003)(48184003)(189002)(199003)(51704005)(15974865002)(83716003)(62966003)(450100001)(77156002)(122556002)(40100003)(15188555004)(2900100001)(92566002)(102836002)(2950100001)(15975445007)(68736005)(36756003)(2501002)(97736003)(82746002)(19580405001)(2351001)(110136001)(107886001)(229853001)(99286002)(19580395003)(561944003)(105586002)(76176999)(54356999)(86362001)(575784001)(101416001)(50986999)(99936001)(2656002)(66066001)(46102003)(87936001)(16799955002)(106356001)(33656002)(106116001)(64706001)(104396002)(579004); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR06MB243; H:BLUPR06MB243.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: isoc.org does not designate permitted sender hosts) Content-Type: multipart/signed; boundary="Apple-Mail=_E03F2421-3B42-4EFE-90E6-2C2CD30E3237"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jan 2015 18:52:16.2078 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB243 Archived-At: Subject: [VoT] Electronic Identity Credential Trust Elevation Framework Version 1.0 X-BeenThere: vot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Vectors of Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2015 18:52:23 -0000 --Apple-Mail=_E03F2421-3B42-4EFE-90E6-2C2CD30E3237 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Here is the direct link to the document Peter referenced: = http://docs.oasis-open.org/trust-el/trust-el-framework/v1.0/cs01/trust-el-= framework-v1.0-cs01.html TC page: https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=3Dtrust-el Steve -- Steve Olshansky Trust & Identity Program Lead Internet Society www.internetsociety.org On Jan 13, 2015, at 11:21 AM, Jones, Mark B = wrote: > +1 >=20 > Please consider this a demonstration of curiosity in the link you = offered. >=20 > Sent from my iPhone >=20 > On Jan 13, 2015, at 12:00 PM, Peter Alterman = > = wrote: >=20 > =E2=80=8BHappy new year to you all. I've been reading the mail but = unable to break away long enough to comment until now. As I read it, the = issue on the table is how to express trustworthiness. >=20 > If Abbie was here he'd point you all to the one-to-one correlation = between trust and threat/threat vector mitigation.=E2=80=8B I recommend = to you the Third Deliverable of the OASIS Trust Elevation TC - link = provided upon demonstration of curiosity ;-) >=20 > An RP trusts an external assertion of identity (or even extended = attributes) to the extent that the assertion is created and/or can be = verified to a predetermined degree of threat/risk mitigation. This = degree is baked into policy or contract or some other pre-existing = agreement (think banking regulations, etc.) and is locally determined = based upon local considerations, e.g., no global standard is = appropriate. So far as I can see, vectors of trust are the same thing = as the threats and threat vectors that are enumerated in ISO 29115 and = other places, not least of which are controls in NIST 800-53-4 and in = ISO 27001/2. I really don't see the vectors as anything different from = these and considering trustworthiness as the inverse of threat in this = context is pretty much what everybody seems to be saying. >=20 > If we just use 29115 as our baseline of threats and threat vectors, = there are roughly a dozen or so of them associated with authentication = of identity assertion. I don't think any of us believe that a = twelve-dimensional assertion is practically viable, even if we could = agree on a common metric for degree of threat mitigation (fat chance = that). This has also already been addressed by the community: think of = the factor model, one to four factors (the fourth is context, which may = be expressed as "Where or when you are," according to our colleagues). = What this does is boil down the trust/threat algorithm to no more than = four dimensions and shifts the discussion to the aforementioned = conundrum, e.g., how to evaluate and rate the degree of threat = mitigation. Various communities have developed policies and practices to = address this question, the most recent of which, I think, is EU = Regulation 910/2014 (eIDAS). >=20 > IMO, the greatest opportunity open to us is to find a way to normalize = all the various community policies and practices so that RPs can assess = whether assertions issued under one community's metrics align with their = adopted risk mitigation requirements. I think that has to be addressed = in the context of how effective a particular mitigation action is on a = recognized threat vector. I would be most interested in your thoughts = on that problem. >=20 > regards, >=20 > Peter >=20 > ------------------------------------------------------------ > Peter Alterman, Ph.D. > Chief Operating Officer > SAFE-BioPharma Association > cell: 301-943-7452 >=20 >=20 > On Tue, Jan 13, 2015 at 8:19 AM, = > wrote: > Send vot mailing list submissions to > vot@ietf.org >=20 > To subscribe or unsubscribe via the World Wide Web, visit > = https://www.ietf.org/mailman/listinfo/vot > or, via email, send a message with subject or body 'help' to > vot-request@ietf.org >=20 > You can reach the person managing the list at > vot-owner@ietf.org >=20 > When replying, please edit your Subject line so it is more specific > than "Re: Contents of vot digest..." >=20 > Today's Topics: >=20 > 1. Re: capturing the threads of the discussion (Robin Wilton) > 2. VoT wiki (Steve Olshansky) >=20 >=20 > ---------- Forwarded message ---------- > From: Robin Wilton > > To: Colin Wallis = > > Cc: Jim Fenton = >, = "vot@ietf.org" > > Date: Tue, 13 Jan 2015 09:31:59 +0000 > Subject: Re: [VoT] capturing the threads of the discussion > Oops - I'd forgotten about the wiki: apologies! Yes, I think that's = the place to start... >=20 > R >=20 > Robin Wilton >=20 > Technical Outreach Director - Identity and Privacy >=20 > On 12 Jan 2015, at 23:43, "Colin Wallis" = > wrote: >=20 > Well as Steve O pointed out in this attached email in November, the = wiki set up for this work might be a place to start.. > There may be some jiggery pokery to get the folks on this list who = want to contribute (who were not attendees at Utrecht) access rights, = but it would seem to me to be the obvious starter option for a = repository. > Cheers > Colin > PS: BTW this is a good discussion and indeed an opportunistic time to = bring it together since so much of what Justin, Jim, Scott, Ken, Steve = W, Mark et al have commented recently is complementary (well at least = not completely contradictory or orthogonal) so let=E2=80=99s grab it! >=20 > From: vot [mailto:vot-bounces@ietf.org] = On Behalf Of Robin Wilton > Sent: Tuesday, 13 January 2015 11:22 a.m. > To: Jim Fenton > Cc: vot@ietf.org > Subject: Re: [VoT] capturing the threads of the discussion >=20 > Thanks Jim, >=20 > I won't give a substantive response here; just to note that I think = it's worth considering a repository so that we can capture 'static' = versions of any straw-man docs, to complement what we it into the mail = thread... >=20 > Sorry to be brief at this stage - just tying up some loose ends before = an absence from the office. >=20 > R >=20 > Robin Wilton >=20 > Technical Outreach Director - Identity and Privacy >=20 > On 12 Jan 2015, at 21:45, "Jim Fenton" = > wrote: > Maybe I should be breaking these apart as Robin suggests, but for now = I'll keep this in one reply: >=20 > On 1/12/15 6:06 AM, Robin Wilton wrote: > This thread raises several important topics=E2=80=A6 just as a = practical matter, it might be worth trying to spin some of them off = separately, so that we address them all, and minimise the risk of = talking at cross-purposes. > It feels like it would be worth trying to put together some *very = short* straw-man docs/pages/paragraphs to try and get a consensus = version on specific points, so that we avoid re-hashing the same = arguments/discussions over time, or at least have something we can refer = to - and amend if necessary. I think this is aiming at the same = end-point as Steve=E2=80=99s request for a statement of requirements, = but will ensure we=E2=80=99re expressing our requirements in a = consistent set of terms. >=20 >=20 > By the looks of it, these would make for a good starting point (I = think the answers to most of these are implicit in various people=E2=80=99= s contributions to the thread=E2=80=A6 but that doesn=E2=80=99t mean = everyone agrees ;^) ): >=20 >=20 > 1 - what do we mean by authentication and authorisation? Are there = other decisions (e.g. access control, entitlement) which need to be = called out explicitly? This reflects the purpose of Justin=E2=80=99s = questions. Classically, the reason for authenticating a user is to = answer a yes/no question (is this the person to whom this credential was = originally issued); if yes, what do I want to do about it (at which = point the further entitlements are usually determined by retrieving a = user profile, ACL or whatever)? >=20 > Access control and entitlement as distinct from authorisation? Is = there a distinction, or are people just using different terminology? >=20 > I think of authentication as providing more than a yes/no answer: it = provides an identifier. If the relying party has enough information = (perhaps on the basis of previous interactions) to authorize something = with just that, fine. Otherwise some attributes are needed to make an = authorisation decision. >=20 >=20 > However, as we know, these days access control and entitlement = decisions also need to be made on the basis of input other than classic = credentials, and that=E2=80=99s one of the two cores of this discussion, = I believe. >=20 > Example of an "input other than classic credentials"? >=20 >=20 >=20 >=20 > 2 - what=E2=80=99s the classic lifecycle of a credential - i.e. a = artefact intended to provide evidence in support of an assertion of = identity. (e.g. registration/verification/enrolment, credential issue, = credential presentation/authentication, credential = amendment/revocation/destruction=E2=80=A6)? >=20 >=20 > Credential is another of those tricky words. Sometimes it means the = same as an authentication token. Sometimes it has some attributes bound = to it, which means it has both an authentication and attribute provision = flavor to it. I find it simpler to talk about tokens, where one doesn't = have to deal with revocation when some attribute (employment, for = example) changes. >=20 >=20 >=20 > 3 - How does (2) relate to other assertions (e.g. attribute = assertions) we would like to make reliably? >=20 >=20 > With that starter set, I think we can confirm the subset of = requirements that 800-63-1 still meets, and define the delta that = requires new design. >=20 > 4 - What=E2=80=99s the right way to update current thinking on LOAs, = to account for the change Jim describes in his proposal - i.e., the case = where "credentials (used in authentication) and attribute information = (established through identity proofing) could be provided by different = parties.=E2=80=9D >=20 > 5 - =46rom Jim=E2=80=99s proposal: =E2=80=9CAttribute reliability = refers to the quality of the identity proofing process, as well as the = strength of the binding of the identifying attributes to the = authentication.=E2=80=9D Do we need/want to expand on this a little? = This seems to cater well for the case where, say, vehicle entitlements = are being established so that they can be encapsulated in a driving = licence. It=E2=80=99s not so clear how this addresses, say, third party = assertions that do not arise from an identity proofing process - =E2=80=9C= I have no idea *who* this user is, but I can reliably assert the = following about them: ... =E2=80=9D. >=20 > You're right; that will need to be defined. But it should be possible = to define analogous requirements to describe the strength of the binding = to the token. When you show up to enroll at school, it should be = possible to use your token to allow your school to make LOR 3 asserts = that you're there student. But maybe remote students only get LOR 2? >=20 > -Jim > All- > There unfortunately is a long-standing bug in Confluence. You must be = logged in before that link, or any link to a restricted page, will work. >=20 > The wiki space for workshop attendees only, which you all have full = edit access to and which is not publicly viewable, is = athttps://tid.isoc.org/confluence/display/interfedgen/ >=20 > The *PUBLIC* wiki space, containing the agenda, presentations, and = contributions/references, is at > = https://tid.isoc.org/confluence/display/interfed/ >=20 > As we make progress on work items and are ready to move them to the = public wiki, I will be happy to do that. Our goal is of course to make = as much of our work as possible available to the public, but this = restricted wiki space gives us a place to work on things before = revealing them to the world. >=20 > As always, if anyone has questions or problems related to the wiki, or = anything else, please do let me know. > Steve >=20 > -- > Steve Olshansky > Trust & Identity Program Lead > Internet Society > = www.internetsociety.org >=20 >=20 > > _______________________________________________ > Ideco-fab mailing list > Ideco-fab@elists.isoc.org > = https://elists.isoc.org/mailman/listinfo/ideco-fab >=20 >=20 > ---------- Forwarded message ---------- > From: Steve Olshansky > > To: "vot@ietf.org" = > > Cc: > Date: Tue, 13 Jan 2015 13:19:22 +0000 > Subject: [VoT] VoT wiki > All- > This is a great discussion, and the stars seem to be aligning now for = the development of some documents or any other related artifacts. >=20 > I setup a dedicated wiki space for use by this group. It is open to = the world for viewing, but we can easily make restricted areas for the = purpose of working on documents before publishing. Anyone would would = like edit access is welcome to contact me directly (off-list). > = https://tid.isoc.org/confluence/display/vot/VoT+Home > Steve >=20 > -- > Steve Olshansky > Trust & Identity Program Lead > Internet Society > = www.internetsociety.org >=20 > On Jan 13, 2015, at 2:31 AM, Robin Wilton = > wrote: >=20 >> Oops - I'd forgotten about the wiki: apologies! Yes, I think that's = the place to start... >>=20 >> R >>=20 >> Robin Wilton >>=20 >> Technical Outreach Director - Identity and Privacy >>=20 >> On 12 Jan 2015, at 23:43, "Colin Wallis" = > wrote: >>=20 >>> Well as Steve O pointed out in this attached email in November, the = wiki set up for this work might be a place to start.. >>> There may be some jiggery pokery to get the folks on this list who = want to contribute (who were not attendees at Utrecht) access rights, = but it would seem to me to be the obvious starter option for a = repository. >>> Cheers >>> Colin >>> PS: BTW this is a good discussion and indeed an opportunistic time = to bring it together since so much of what Justin, Jim, Scott, Ken, = Steve W, Mark et al have commented recently is complementary (well at = least not completely contradictory or orthogonal) so let=E2=80=99s grab = it! >>>=20 >>> From: vot [mailto:vot-bounces@ietf.org] = On Behalf Of Robin Wilton >>> Sent: Tuesday, 13 January 2015 11:22 a.m. >>> To: Jim Fenton >>> Cc: vot@ietf.org >>> Subject: Re: [VoT] capturing the threads of the discussion >>>=20 >>> Thanks Jim, >>>=20 >>> I won't give a substantive response here; just to note that I think = it's worth considering a repository so that we can capture 'static' = versions of any straw-man docs, to complement what we it into the mail = thread... >>>=20 >>> Sorry to be brief at this stage - just tying up some loose ends = before an absence from the office. >>>=20 >>> R >>>=20 >>> Robin Wilton >>>=20 >>> Technical Outreach Director - Identity and Privacy >>>=20 >>> On 12 Jan 2015, at 21:45, "Jim Fenton" = > wrote: >>>=20 >>> Maybe I should be breaking these apart as Robin suggests, but for = now I'll keep this in one reply: >>>=20 >>> On 1/12/15 6:06 AM, Robin Wilton wrote: >>> This thread raises several important topics=E2=80=A6 just as a = practical matter, it might be worth trying to spin some of them off = separately, so that we address them all, and minimise the risk of = talking at cross-purposes. >>> It feels like it would be worth trying to put together some *very = short* straw-man docs/pages/paragraphs to try and get a consensus = version on specific points, so that we avoid re-hashing the same = arguments/discussions over time, or at least have something we can refer = to - and amend if necessary. I think this is aiming at the same = end-point as Steve=E2=80=99s request for a statement of requirements, = but will ensure we=E2=80=99re expressing our requirements in a = consistent set of terms. >>>=20 >>>=20 >>> By the looks of it, these would make for a good starting point (I = think the answers to most of these are implicit in various people=E2=80=99= s contributions to the thread=E2=80=A6 but that doesn=E2=80=99t mean = everyone agrees ;^) ): >>>=20 >>>=20 >>> 1 - what do we mean by authentication and authorisation? Are there = other decisions (e.g. access control, entitlement) which need to be = called out explicitly? This reflects the purpose of Justin=E2=80=99s = questions. Classically, the reason for authenticating a user is to = answer a yes/no question (is this the person to whom this credential was = originally issued); if yes, what do I want to do about it (at which = point the further entitlements are usually determined by retrieving a = user profile, ACL or whatever)? >>>=20 >>> Access control and entitlement as distinct from authorisation? Is = there a distinction, or are people just using different terminology? >>>=20 >>> I think of authentication as providing more than a yes/no answer: it = provides an identifier. If the relying party has enough information = (perhaps on the basis of previous interactions) to authorize something = with just that, fine. Otherwise some attributes are needed to make an = authorisation decision. >>>=20 >>>=20 >>> However, as we know, these days access control and entitlement = decisions also need to be made on the basis of input other than classic = credentials, and that=E2=80=99s one of the two cores of this discussion, = I believe. >>>=20 >>> Example of an "input other than classic credentials"? >>>=20 >>>=20 >>>=20 >>>=20 >>> 2 - what=E2=80=99s the classic lifecycle of a credential - i.e. a = artefact intended to provide evidence in support of an assertion of = identity. (e.g. registration/verification/enrolment, credential issue, = credential presentation/authentication, credential = amendment/revocation/destruction=E2=80=A6)? >>>=20 >>>=20 >>> Credential is another of those tricky words. Sometimes it means the = same as an authentication token. Sometimes it has some attributes bound = to it, which means it has both an authentication and attribute provision = flavor to it. I find it simpler to talk about tokens, where one doesn't = have to deal with revocation when some attribute (employment, for = example) changes. >>>=20 >>>=20 >>>=20 >>> 3 - How does (2) relate to other assertions (e.g. attribute = assertions) we would like to make reliably? >>>=20 >>>=20 >>> With that starter set, I think we can confirm the subset of = requirements that 800-63-1 still meets, and define the delta that = requires new design. >>>=20 >>> 4 - What=E2=80=99s the right way to update current thinking on LOAs, = to account for the change Jim describes in his proposal - i.e., the case = where "credentials (used in authentication) and attribute information = (established through identity proofing) could be provided by different = parties.=E2=80=9D >>>=20 >>> 5 - =46rom Jim=E2=80=99s proposal: =E2=80=9CAttribute reliability = refers to the quality of the identity proofing process, as well as the = strength of the binding of the identifying attributes to the = authentication.=E2=80=9D Do we need/want to expand on this a little? = This seems to cater well for the case where, say, vehicle entitlements = are being established so that they can be encapsulated in a driving = licence. It=E2=80=99s not so clear how this addresses, say, third party = assertions that do not arise from an identity proofing process - =E2=80=9C= I have no idea *who* this user is, but I can reliably assert the = following about them: ... =E2=80=9D. >>>=20 >>> You're right; that will need to be defined. But it should be = possible to define analogous requirements to describe the strength of = the binding to the token. When you show up to enroll at school, it = should be possible to use your token to allow your school to make LOR 3 = asserts that you're there student. But maybe remote students only get = LOR 2? >>>=20 >>> -Jim >>>=20 >> vot mailing list >> vot@ietf.org >> = https://www.ietf.org/mailman/listinfo/vot >=20 >=20 > _______________________________________________ > vot mailing list > vot@ietf.org > = https://www.ietf.org/mailman/listinfo/vot >=20 >=20 > _______________________________________________ > vot mailing list > vot@ietf.org > = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_vot&d=3DAwICAg&c=3D6vgNTiRn9_pqCD9hKx9JgXN1VapJQ8JVoF8oWH1AgfQ&= r=3DjgMu8DNgV_dycz0rYwkNbEQq36F0BI5_Zpblz7C5LhM&m=3D4Q0ywmdZOmq4eJzFcK-ZUE= 2grM96iZWOPhoLSwpJKiI&s=3Duc913qsLA6bZ34rLfuSc3sig7ZcIykGDReZ73Wx21L0&e=3D= > _______________________________________________ > vot mailing list > vot@ietf.org > https://www.ietf.org/mailman/listinfo/vot --Apple-Mail=_E03F2421-3B42-4EFE-90E6-2C2CD30E3237 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----- iQEcBAEBAgAGBQJUtWleAAoJEOJO4+877g3HG0UH/Rug9uebnWEfXb/JkDR9fddh PDBfYYm0+7ccKMdRxfAjQoDwehXg3DPS/bKXHoJhEfFq05SkPPUUwpc0JKfeCPLe kHHani+RL/o3HT8uLm2mBiyD9lEezsH59QZ+2RNGQfpMg2fT4NSQnbhcg8GszYTM /rku5+UDBHJvq/Hi6PqSwdYQRh5AyxeABGdM2/+5QuhDZya+gATIjagWizXIRnzN ZIyHnkD4EZNdmbOCgP5tL1ouSdawJMDwQM2S/o3EBu5bEl1Qmt5Nys0jpEcs0Lay Ke+IWu4axZZW5+xAm0nM7p8ivFoOk8BabP0Q1LAlAirikiXb1GaP9mmjb4NjOJI= =J4GM -----END PGP SIGNATURE----- --Apple-Mail=_E03F2421-3B42-4EFE-90E6-2C2CD30E3237-- From nobody Thu Jan 15 12:48:31 2015 Return-Path: X-Original-To: vot@ietfa.amsl.com Delivered-To: vot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD4641B330B for ; Thu, 15 Jan 2015 12:48:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.091 X-Spam-Level: *** X-Spam-Status: No, score=3.091 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, MANGLED_MARKET=2.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 l2G-0qDOliHU for ; Thu, 15 Jan 2015 12:48:21 -0800 (PST) Received: from office.sk.ee (office.sk.ee [213.35.160.18]) by ietfa.amsl.com (Postfix) with ESMTP id D73D41B330A for ; Thu, 15 Jan 2015 12:48:18 -0800 (PST) Received: from office.sk.ee (localhost.localdomain [127.0.0.1]) by postfix.imss71 (Postfix) with ESMTP id C18BEE06E1; Thu, 15 Jan 2015 22:48:15 +0200 (EET) Received: by mail.sk.sise (Postfix, from userid 559) id B295CE06E4; Thu, 15 Jan 2015 22:48:15 +0200 (EET) Received: from tarviliistakas (40.vpn.sk.sise [192.168.50.40]) by mail.sk.sise (Postfix) with ESMTP id 1D20DE06E1; Thu, 15 Jan 2015 22:48:11 +0200 (EET) From: "Tarvi Martens" To: "'Peter Alterman'" , References: In-Reply-To: Date: Thu, 15 Jan 2015 22:48:20 +0200 Message-ID: <06c901d03104$998031d0$cc809570$@sk.ee> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_06CA_01D03115.5D1536D0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIe1umpvASgiitYzzLOf788+Z3gVgKnxs2fnA8aumA= Content-Language: et X-TM-AS-MML: No Archived-At: Subject: Re: [VoT] vot Digest, Vol 5, Issue 6 X-BeenThere: vot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Vectors of Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2015 20:48:28 -0000 This is a multipart message in MIME format. ------=_NextPart_000_06CA_01D03115.5D1536D0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, =20 The principle of Eurpean eIDAS eID recognition is mainly that = =E2=80=9Eif you trust this in your country then other EU states shall it = trust as well in their e-services=E2=80=9C. Oh well, when it is sort of = =E2=80=9Eregistered and assessed=E2=80=9C. =20 In general terms it comes down to community (read: RP-s) trust. For = example hardly anyone would question Estonian ID-card for it security = after living 13 years of harmless life, =20 Tarvi=20 =20 From: vot [mailto:vot-bounces@ietf.org] On Behalf Of Peter Alterman Sent: Tuesday, January 13, 2015 8:00 PM To: vot@ietf.org Subject: Re: [VoT] vot Digest, Vol 5, Issue 6 =20 =E2=80=8BHappy new year to you all. I've been reading the mail but = unable to break away long enough to comment until now. As I read it, the = issue on the table is how to express trustworthiness.=20 =20 If Abbie was here he'd point you all to the one-to-one correlation = between trust and threat/threat vector mitigation.=E2=80=8B I recommend = to you the Third Deliverable of the OASIS Trust Elevation TC - link = provided upon demonstration of curiosity ;-) =20 An RP trusts an external assertion of identity (or even extended = attributes) to the extent that the assertion is created and/or can be = verified to a predetermined degree of threat/risk mitigation. This = degree is baked into policy or contract or some other pre-existing = agreement (think banking regulations, etc.) and is locally determined = based upon local considerations, e.g., no global standard is = appropriate. So far as I can see, vectors of trust are the same thing = as the threats and threat vectors that are enumerated in ISO 29115 and = other places, not least of which are controls in NIST 800-53-4 and in = ISO 27001/2. I really don't see the vectors as anything different from = these and considering trustworthiness as the inverse of threat in this = context is pretty much what everybody seems to be saying.=20 =20 If we just use 29115 as our baseline of threats and threat vectors, = there are roughly a dozen or so of them associated with authentication = of identity assertion. I don't think any of us believe that a = twelve-dimensional assertion is practically viable, even if we could = agree on a common metric for degree of threat mitigation (fat chance = that). This has also already been addressed by the community: think of = the factor model, one to four factors (the fourth is context, which may = be expressed as "Where or when you are," according to our colleagues). = What this does is boil down the trust/threat algorithm to no more than = four dimensions and shifts the discussion to the aforementioned = conundrum, e.g., how to evaluate and rate the degree of threat = mitigation. Various communities have developed policies and practices to = address this question, the most recent of which, I think, is EU = Regulation 910/2014 (eIDAS).=20 =20 IMO, the greatest opportunity open to us is to find a way to normalize = all the various community policies and practices so that RPs can assess = whether assertions issued under one community's metrics align with their = adopted risk mitigation requirements. I think that has to be addressed = in the context of how effective a particular mitigation action is on a = recognized threat vector. I would be most interested in your thoughts = on that problem. =20 regards, =20 Peter ------------------------------------------------------------ Peter Alterman, Ph.D. Chief Operating Officer SAFE-BioPharma Association cell: 301-943-7452 =20 On Tue, Jan 13, 2015 at 8:19 AM, wrote: Send vot mailing list submissions to vot@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/vot or, via email, send a message with subject or body 'help' to vot-request@ietf.org You can reach the person managing the list at vot-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of vot digest..." Today's Topics: 1. Re: capturing the threads of the discussion (Robin Wilton) 2. VoT wiki (Steve Olshansky) ---------- Forwarded message ---------- From: Robin Wilton To: Colin Wallis Cc: Jim Fenton , "vot@ietf.org" Date: Tue, 13 Jan 2015 09:31:59 +0000 Subject: Re: [VoT] capturing the threads of the discussion Oops - I'd forgotten about the wiki: apologies! Yes, I think that's the = place to start... =20 R Robin Wilton=20 =20 Technical Outreach Director - Identity and Privacy On 12 Jan 2015, at 23:43, "Colin Wallis" = wrote: Well as Steve O pointed out in this attached email in November, the wiki = set up for this work might be a place to start.. There may be some jiggery pokery to get the folks on this list who want = to contribute (who were not attendees at Utrecht) access rights, but it = would seem to me to be the obvious starter option for a repository. Cheers Colin=20 PS: BTW this is a good discussion and indeed an opportunistic time to = bring it together since so much of what Justin, Jim, Scott, Ken, Steve = W, Mark et al have commented recently is complementary (well at least = not completely contradictory or orthogonal) so let=E2=80=99s grab it!=20 =20 From: vot [mailto:vot-bounces@ietf.org] On Behalf Of Robin Wilton Sent: Tuesday, 13 January 2015 11:22 a.m. To: Jim Fenton Cc: vot@ietf.org Subject: Re: [VoT] capturing the threads of the discussion =20 Thanks Jim, =20 I won't give a substantive response here; just to note that I think it's = worth considering a repository so that we can capture 'static' versions = of any straw-man docs, to complement what we it into the mail thread... =20 Sorry to be brief at this stage - just tying up some loose ends before = an absence from the office. =20 R Robin Wilton=20 =20 Technical Outreach Director - Identity and Privacy On 12 Jan 2015, at 21:45, "Jim Fenton" wrote: Maybe I should be breaking these apart as Robin suggests, but for now = I'll keep this in one reply: On 1/12/15 6:06 AM, Robin Wilton wrote: This thread raises several important topics=E2=80=A6 just as a practical = matter, it might be worth trying to spin some of them off separately, so = that we address them all, and minimise the risk of talking at = cross-purposes. =20 It feels like it would be worth trying to put together some *very short* = straw-man docs/pages/paragraphs to try and get a consensus version on = specific points, so that we avoid re-hashing the same = arguments/discussions over time, or at least have something we can refer = to - and amend if necessary. I think this is aiming at the same = end-point as Steve=E2=80=99s request for a statement of requirements, = but will ensure we=E2=80=99re expressing our requirements in a = consistent set of terms. =20 By the looks of it, these would make for a good starting point (I think = the answers to most of these are implicit in various people=E2=80=99s = contributions to the thread=E2=80=A6 but that doesn=E2=80=99t mean = everyone agrees ;^) ): =20 1 - what do we mean by authentication and authorisation? Are there other = decisions (e.g. access control, entitlement) which need to be called out = explicitly? This reflects the purpose of Justin=E2=80=99s questions. = Classically, the reason for authenticating a user is to answer a yes/no = question (is this the person to whom this credential was originally = issued); if yes, what do I want to do about it (at which point the = further entitlements are usually determined by retrieving a user = profile, ACL or whatever)? Access control and entitlement as distinct from authorisation? Is there = a distinction, or are people just using different terminology? I think of authentication as providing more than a yes/no answer: it = provides an identifier. If the relying party has enough information = (perhaps on the basis of previous interactions) to authorize something = with just that, fine. Otherwise some attributes are needed to make an = authorisation decision. However, as we know, these days access control and entitlement decisions = also need to be made on the basis of input other than classic = credentials, and that=E2=80=99s one of the two cores of this discussion, = I believe. Example of an "input other than classic credentials"? =20 2 - what=E2=80=99s the classic lifecycle of a credential - i.e. a = artefact intended to provide evidence in support of an assertion of = identity. (e.g. registration/verification/enrolment, credential issue, = credential presentation/authentication, credential = amendment/revocation/destruction=E2=80=A6)?=20 Credential is another of those tricky words. Sometimes it means the same = as an authentication token. Sometimes it has some attributes bound to = it, which means it has both an authentication and attribute provision = flavor to it. I find it simpler to talk about tokens, where one doesn't = have to deal with revocation when some attribute (employment, for = example) changes. =20 3 - How does (2) relate to other assertions (e.g. attribute assertions) = we would like to make reliably? =20 With that starter set, I think we can confirm the subset of requirements = that 800-63-1 still meets, and define the delta that requires new = design. =20 4 - What=E2=80=99s the right way to update current thinking on LOAs, to = account for the change Jim describes in his proposal - i.e., the case = where "credentials (used in authentication) and attribute information = (established through identity proofing) could be provided by different = parties.=E2=80=9D =20 5 - From Jim=E2=80=99s proposal: =E2=80=9CAttribute reliability refers = to the quality of the identity proofing process, as well as the strength = of the binding of the identifying attributes to the = authentication.=E2=80=9D Do we need/want to expand on this a little? = This seems to cater well for the case where, say, vehicle entitlements = are being established so that they can be encapsulated in a driving = licence. It=E2=80=99s not so clear how this addresses, say, third party = assertions that do not arise from an identity proofing process - = =E2=80=9CI have no idea *who* this user is, but I can reliably assert = the following about them: ... =E2=80=9D. You're right; that will need to be defined. But it should be possible to = define analogous requirements to describe the strength of the binding to = the token. When you show up to enroll at school, it should be possible = to use your token to allow your school to make LOR 3 asserts that you're = there student. But maybe remote students only get LOR 2? -Jim All- There unfortunately is a long-standing bug in Confluence. You must be = logged in before that link, or any link to a restricted page, will work. The wiki space for workshop attendees only, which you all have full edit = access to and which is not publicly viewable, is = athttps://tid.isoc.org/confluence/display/interfedgen/ The *PUBLIC* wiki space, containing the agenda, presentations, and = contributions/references, is at https://tid.isoc.org/confluence/display/interfed/ As we make progress on work items and are ready to move them to the = public wiki, I will be happy to do that. Our goal is of course to make = as much of our work as possible available to the public, but this = restricted wiki space gives us a place to work on things before = revealing them to the world. As always, if anyone has questions or problems related to the wiki, or = anything else, please do let me know. Steve -- Steve Olshansky Trust & Identity Program Lead Internet Society www.internetsociety.org _______________________________________________ Ideco-fab mailing list Ideco-fab@elists.isoc.org https://elists.isoc.org/mailman/listinfo/ideco-fab ---------- Forwarded message ---------- From: Steve Olshansky To: "vot@ietf.org" Cc:=20 Date: Tue, 13 Jan 2015 13:19:22 +0000 Subject: [VoT] VoT wiki All- This is a great discussion, and the stars seem to be aligning now for = the development of some documents or any other related artifacts. I setup a dedicated wiki space for use by this group. It is open to the = world for viewing, but we can easily make restricted areas for the = purpose of working on documents before publishing. Anyone would would = like edit access is welcome to contact me directly (off-list). https://tid.isoc.org/confluence/display/vot/VoT+Home Steve -- Steve Olshansky Trust & Identity Program Lead Internet Society www.internetsociety.org On Jan 13, 2015, at 2:31 AM, Robin Wilton wrote: > Oops - I'd forgotten about the wiki: apologies! Yes, I think that's = the place to start... > > R > > Robin Wilton > > Technical Outreach Director - Identity and Privacy > > On 12 Jan 2015, at 23:43, "Colin Wallis" = wrote: > >> Well as Steve O pointed out in this attached email in November, the = wiki set up for this work might be a place to start.. >> There may be some jiggery pokery to get the folks on this list who = want to contribute (who were not attendees at Utrecht) access rights, = but it would seem to me to be the obvious starter option for a = repository. >> Cheers >> Colin >> PS: BTW this is a good discussion and indeed an opportunistic time to = bring it together since so much of what Justin, Jim, Scott, Ken, Steve = W, Mark et al have commented recently is complementary (well at least = not completely contradictory or orthogonal) so let=E2=80=99s grab it! >> >> From: vot [mailto:vot-bounces@ietf.org] On Behalf Of Robin Wilton >> Sent: Tuesday, 13 January 2015 11:22 a.m. >> To: Jim Fenton >> Cc: vot@ietf.org >> Subject: Re: [VoT] capturing the threads of the discussion >> >> Thanks Jim, >> >> I won't give a substantive response here; just to note that I think = it's worth considering a repository so that we can capture 'static' = versions of any straw-man docs, to complement what we it into the mail = thread... >> >> Sorry to be brief at this stage - just tying up some loose ends = before an absence from the office. >> >> R >> >> Robin Wilton >> >> Technical Outreach Director - Identity and Privacy >> >> On 12 Jan 2015, at 21:45, "Jim Fenton" = wrote: >> >> Maybe I should be breaking these apart as Robin suggests, but for now = I'll keep this in one reply: >> >> On 1/12/15 6:06 AM, Robin Wilton wrote: >> This thread raises several important topics=E2=80=A6 just as a = practical matter, it might be worth trying to spin some of them off = separately, so that we address them all, and minimise the risk of = talking at cross-purposes. >> It feels like it would be worth trying to put together some *very = short* straw-man docs/pages/paragraphs to try and get a consensus = version on specific points, so that we avoid re-hashing the same = arguments/discussions over time, or at least have something we can refer = to - and amend if necessary. I think this is aiming at the same = end-point as Steve=E2=80=99s request for a statement of requirements, = but will ensure we=E2=80=99re expressing our requirements in a = consistent set of terms. >> >> >> By the looks of it, these would make for a good starting point (I = think the answers to most of these are implicit in various = people=E2=80=99s contributions to the thread=E2=80=A6 but that = doesn=E2=80=99t mean everyone agrees ;^) ): >> >> >> 1 - what do we mean by authentication and authorisation? Are there = other decisions (e.g. access control, entitlement) which need to be = called out explicitly? This reflects the purpose of Justin=E2=80=99s = questions. Classically, the reason for authenticating a user is to = answer a yes/no question (is this the person to whom this credential was = originally issued); if yes, what do I want to do about it (at which = point the further entitlements are usually determined by retrieving a = user profile, ACL or whatever)? >> >> Access control and entitlement as distinct from authorisation? Is = there a distinction, or are people just using different terminology? >> >> I think of authentication as providing more than a yes/no answer: it = provides an identifier. If the relying party has enough information = (perhaps on the basis of previous interactions) to authorize something = with just that, fine. Otherwise some attributes are needed to make an = authorisation decision. >> >> >> However, as we know, these days access control and entitlement = decisions also need to be made on the basis of input other than classic = credentials, and that=E2=80=99s one of the two cores of this discussion, = I believe. >> >> Example of an "input other than classic credentials"? >> >> >> >> >> 2 - what=E2=80=99s the classic lifecycle of a credential - i.e. a = artefact intended to provide evidence in support of an assertion of = identity. (e.g. registration/verification/enrolment, credential issue, = credential presentation/authentication, credential = amendment/revocation/destruction=E2=80=A6)? >> >> >> Credential is another of those tricky words. Sometimes it means the = same as an authentication token. Sometimes it has some attributes bound = to it, which means it has both an authentication and attribute provision = flavor to it. I find it simpler to talk about tokens, where one doesn't = have to deal with revocation when some attribute (employment, for = example) changes. >> >> >> >> 3 - How does (2) relate to other assertions (e.g. attribute = assertions) we would like to make reliably? >> >> >> With that starter set, I think we can confirm the subset of = requirements that 800-63-1 still meets, and define the delta that = requires new design. >> >> 4 - What=E2=80=99s the right way to update current thinking on LOAs, = to account for the change Jim describes in his proposal - i.e., the case = where "credentials (used in authentication) and attribute information = (established through identity proofing) could be provided by different = parties.=E2=80=9D >> >> 5 - From Jim=E2=80=99s proposal: =E2=80=9CAttribute reliability = refers to the quality of the identity proofing process, as well as the = strength of the binding of the identifying attributes to the = authentication.=E2=80=9D Do we need/want to expand on this a little? = This seems to cater well for the case where, say, vehicle entitlements = are being established so that they can be encapsulated in a driving = licence. It=E2=80=99s not so clear how this addresses, say, third party = assertions that do not arise from an identity proofing process - = =E2=80=9CI have no idea *who* this user is, but I can reliably assert = the following about them: ... =E2=80=9D. >> >> You're right; that will need to be defined. But it should be possible = to define analogous requirements to describe the strength of the binding = to the token. When you show up to enroll at school, it should be = possible to use your token to allow your school to make LOR 3 asserts = that you're there student. But maybe remote students only get LOR 2? >> >> -Jim >> > vot mailing list > vot@ietf.org > https://www.ietf.org/mailman/listinfo/vot _______________________________________________ vot mailing list vot@ietf.org https://www.ietf.org/mailman/listinfo/vot =20 ------=_NextPart_000_06CA_01D03115.5D1536D0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi,

 

The principle of Eurpean eIDAS eID recognition is mainly that = =E2=80=9Eif you trust this in your country then other EU states shall it = trust as well in their e-services=E2=80=9C. Oh well, when it is sort of = =E2=80=9Eregistered and assessed=E2=80=9C.

 

In general terms it comes down to community (read: RP-s) trust. For = example hardly anyone would question Estonian ID-card for it security = after living 13 years of harmless life,

 

Tarvi

 

From:= vot = [mailto:vot-bounces@ietf.org] On Behalf Of Peter = Alterman
Sent: Tuesday, January 13, 2015 8:00 PM
To: = vot@ietf.org
Subject: Re: [VoT] vot Digest, Vol 5, Issue = 6

 

=E2=80=8BHappy new year to = you all.  I've been reading the mail but unable to break away long = enough to comment until now. As I read it, the issue on the table is how = to express trustworthiness. 

 

If Abbie was here he'd = point you all to the one-to-one correlation between trust and = threat/threat vector mitigation.=E2=80=8B I recommend to you the Third = Deliverable of the OASIS Trust Elevation TC  - link provided upon = demonstration of curiosity ;-)

 

 An RP trusts an = external assertion of identity (or even extended attributes) to the = extent that the assertion is created and/or can be verified to a = predetermined degree of threat/risk mitigation. This degree is baked = into policy or contract or some other pre-existing agreement (think = banking regulations, etc.) and is locally determined based upon local = considerations, e.g., no global standard is appropriate.  So far as = I can see, vectors of trust are the same thing as the threats and threat = vectors that are enumerated in ISO 29115 and other places, not least of = which are controls in NIST 800-53-4 and in ISO 27001/2. I really don't = see the vectors as anything different from these and considering = trustworthiness as the inverse of threat in this context is pretty much = what everybody seems to be = saying. 

 

If we just use 29115 as = our baseline of threats and threat vectors, there are roughly a dozen or = so of them associated with authentication of identity assertion. I don't = think any of us believe that a twelve-dimensional assertion is = practically viable, even if we could agree on a common metric for degree = of threat mitigation (fat chance that). This has also already been = addressed by the community: think of the factor model, one to four = factors (the fourth is context, which may be expressed as "Where or = when you are," according to our colleagues). What this does is boil = down the trust/threat algorithm to no more than four dimensions and = shifts the discussion to the aforementioned conundrum, e.g., how to = evaluate and rate the degree of threat mitigation. Various communities = have developed policies and practices to address this question, the most = recent of which, I think, is EU Regulation 910/2014 = (eIDAS). 

 

IMO, the greatest = opportunity open to us is to find a way to normalize all the various = community policies and practices so that RPs can assess whether = assertions issued under one community's metrics align with their adopted = risk mitigation requirements. I think that has to be addressed in the = context of how effective a particular mitigation action is on a = recognized threat vector.   I would be most interested in your = thoughts on that problem.

 

regards,

 

Peter


-------------------------------------------------------= -----

Peter Alterman, = Ph.D.

Chief Operating = Officer
SAFE-BioPharma Association

cell: = 301-943-7452

 

On Tue, = Jan 13, 2015 at 8:19 AM, <vot-request@ietf.org> wrote:

Send vot mailing list submissions to
    =     vot@ietf.org

To = subscribe or unsubscribe via the World Wide Web, visit
    =     https://www.ietf.org/mailman/listinfo/vot
or, = via email, send a message with subject or body 'help' to
  =       vot-request@ietf.org

You = can reach the person managing the list at
        = vot-owner@ietf.org

When = replying, please edit your Subject line so it is more specific
than = "Re: Contents of vot digest..."

Today's = Topics:

   1. Re: capturing the threads of the = discussion (Robin Wilton)
   2. VoT wiki (Steve = Olshansky)


---------- Forwarded message = ----------
From: Robin Wilton <wilton@isoc.org>
To: Colin= Wallis <Colin.Wallis@dia.govt.nz>=
Cc: Jim Fenton <fenton@bluepopcorn.net>, = "vot@ietf.org" <vot@ietf.org>
Date: Tue, 13 = Jan 2015 09:31:59 +0000
Subject: Re: [VoT] capturing the threads = of the discussion

Oops - = I'd forgotten about the wiki: apologies! Yes, I think that's the place = to start...

 

R

Robin Wilton

 

Technical Outreach Director - Identity and = Privacy


On 12 Jan 2015, at 23:43, "Colin = Wallis" <Colin.Wallis@dia.govt.nz> = wrote:

Well as Steve O pointed out in this attached email in November, the = wiki set up for this work might be a place to = start..

There may be some jiggery pokery to get the folks on this list who = want to contribute (who were not attendees at Utrecht) access rights, = but it would seem to me to be the obvious starter option for a = repository.

Cheers

Colin

PS: BTW this is a good discussion and indeed an opportunistic time to = bring it together since so much of what Justin, Jim, Scott, Ken, Steve = W, Mark et al have commented recently is complementary (well at least = not completely contradictory or orthogonal) so let=E2=80=99s grab it! =

 

From:= vot = [mailto:vot-bounces@ietf.org] On Behalf Of Robin = Wilton
Sent: Tuesday, 13 January 2015 11:22 a.m.
To: = Jim Fenton
Cc: vot@ietf.org
Subject: Re: [VoT] = capturing the threads of the = discussion

 <= /o:p>

Thanks = Jim,

 <= /o:p>

I won't = give a substantive response here; just to note that I think it's worth = considering a repository so that we can capture 'static' versions of any = straw-man docs, to complement what we it into the mail = thread...

 <= /o:p>

Sorry to be = brief at this stage - just tying up some loose ends before an absence = from the office.

 <= /o:p>

R

Rob= in Wilton

 <= /o:p>

Technical = Outreach Director - Identity and = Privacy


On 12 Jan = 2015, at 21:45, "Jim Fenton" <fenton@bluepopcorn.net> = wrote:

Maybe I = should be breaking these apart as Robin suggests, but for now I'll keep = this in one reply:

On 1/12/15 6:06 AM, Robin Wilton = wrote:

This thread = raises several important topics=E2=80=A6 just as a practical matter, it = might be worth trying to spin some of them off separately, so that we = address them all, and minimise the risk of talking at cross-purposes. =  

It feels = like it would be worth trying to put together some *very short* = straw-man docs/pages/paragraphs to try and get a consensus version on = specific points, so that we avoid re-hashing the same = arguments/discussions over time, or at least have something we can refer = to - and amend if necessary. I think this is aiming at the same = end-point as Steve=E2=80=99s request for a statement of requirements, = but will ensure we=E2=80=99re expressing our requirements in a = consistent set of terms.

 <= /p>

By the looks = of it, these would make for a good starting point (I think the answers = to most of these are implicit in various people=E2=80=99s contributions = to the thread=E2=80=A6 but that doesn=E2=80=99t mean everyone agrees ;^) =  ):

 <= /p>

1 - what do = we mean by authentication and authorisation? Are there other decisions = (e.g. access control, entitlement) which need to be called out = explicitly? This reflects the purpose of Justin=E2=80=99s questions. = Classically, the reason for authenticating a user is to answer a yes/no = question (is this the person to whom this credential was originally = issued); if yes, what do I want to do about it (at which point the = further entitlements are usually determined by retrieving a user = profile, ACL or whatever)?


Access = control and entitlement as distinct from authorisation? Is there a = distinction, or are people just using different terminology?

I = think of authentication as providing more than a yes/no answer: it = provides an identifier. If the relying party has enough information = (perhaps on the basis of previous interactions) to authorize something = with just that, fine. Otherwise some attributes are needed to make an = authorisation decision.

However, as = we know, these days access control and entitlement decisions also need = to be made on the basis of input other than classic credentials, and = that=E2=80=99s one of the two cores of this discussion, I = believe.


Example of an = "input other than classic = credentials"?

 <= /p>

2 - = what=E2=80=99s the classic lifecycle of a credential - i.e. a artefact = intended to provide evidence in support of an assertion of identity. = (e.g. registration/verification/enrolment, credential issue, credential = presentation/authentication, credential = amendment/revocation/destruction=E2=80=A6)? =


Credential is = another of those tricky words. Sometimes it means the same as an = authentication token. Sometimes it has some attributes bound to it, = which means it has both an authentication and attribute provision flavor = to it. I find it simpler to talk about tokens, where one doesn't have to = deal with revocation when some attribute (employment, for example) = changes.

 <= /p>

3 - How does = (2) relate to other assertions (e.g. attribute assertions) we would like = to make reliably?

 <= /p>

With that = starter set, I think we can confirm the subset of requirements that = 800-63-1 still meets, and define the delta that requires new = design.

 <= /o:p>

4 - = What=E2=80=99s the right way to update current thinking on LOAs, to = account for the change Jim describes in his proposal - i.e., the case = where "credentials (used in authentication) and attribute = information (established through identity proofing) could be provided by = different parties.=E2=80=9D

 <= /o:p>

5 - From = Jim=E2=80=99s proposal: =E2=80=9CAttribute reliability refers to the quality of the identity proofing = process, as well as the strength of the binding of the identifying = attributes to the authentication.=E2=80=9D Do we need/want to = expand on this a little? This seems to cater well for the case where, = say, vehicle entitlements are being established so that they can be = encapsulated in a driving licence. It=E2=80=99s not so clear how this = addresses, say, third party assertions that do not arise from an = identity proofing process - =E2=80=9CI have no idea *who* this user is, = but I can reliably assert the following about them: ... = =E2=80=9D.


You're right; = that will need to be defined. But it should be possible to define = analogous requirements to describe the strength of the binding to the = token. When you show up to enroll at school, it should be possible to = use your token to allow your school to make LOR 3 asserts that you're = there student. But maybe remote students only get LOR = 2?

-Jim

=

All-
There = unfortunately is a long-standing bug in Confluence. You must be logged = in before that link, or any link to a restricted page, will = work.

The wiki space for workshop attendees only, which you all = have full edit access to and which is not publicly viewable, is = athttps://tid.isoc.org/confluence/display/interfedgen/
The *PUBLIC* wiki space, containing the agenda, presentations, and = contributions/references, is at
https://tid.isoc.org/confluence/display/interfed/
As we make progress on work items and are ready to move them to = the public wiki, I will be happy to do that. Our goal is of course to = make as much of our work as possible available to the public, but this = restricted wiki space gives us a place to work on things before = revealing them to the world.

As always, if anyone has questions = or problems related to the wiki, or anything else, please do let me = know.
       Steve

--
Ste= ve Olshansky
Trust & Identity Program Lead
Internet = Society
www.internetsociety.org

<signature.asc>

=

_______________________________________________
Idec= o-fab mailing list
Ideco-fab@elists.isoc.org
https://elists.isoc.org/mailman/listinfo/ideco-fab<= o:p>



---------- Forwarded message = ----------
From: Steve Olshansky <olshansky@isoc.org>
To: = ;"vot@ietf.org" <vot@ietf.org>
Cc: 
Date:&n= bsp;Tue, 13 Jan 2015 13:19:22 +0000
Subject: [VoT] VoT = wiki
All-
This is a great discussion, and the stars seem to be = aligning now for the development of some documents or any other related = artifacts.

I setup a dedicated wiki space for use by this group. = It is open to the world for viewing, but we can easily make restricted = areas for the purpose of working on documents before publishing. Anyone = would would like edit access is welcome to contact me directly = (off-list).
https://tid.isoc.org/confluence/display/vot/VoT+Home
        Steve

--
Steve = Olshansky
Trust & Identity Program Lead
Internet Society
www.internetsociety.org

On Jan 13, 2015, at = 2:31 AM, Robin Wilton <wilton@isoc.org> = wrote:

> Oops - I'd forgotten about the wiki: apologies! Yes, = I think that's the place to start...
>
> R
>
> = Robin Wilton
>
> Technical Outreach Director - Identity and = Privacy
>
> On 12 Jan 2015, at 23:43, "Colin = Wallis" <Colin.Wallis@dia.govt.nz>= wrote:
>
>> Well as Steve O pointed out in this attached = email in November, the wiki set up for this work might be a place to = start..
>> There may be some jiggery pokery to get the folks on = this list who want to contribute (who were not attendees at Utrecht) = access rights, but it would seem to me to be the obvious starter option = for a repository.
>> Cheers
>> Colin
>> PS: = BTW this is a good discussion and indeed an opportunistic time to bring = it together since so much of what Justin, Jim, Scott, Ken, Steve W, Mark = et al have commented recently is complementary (well at least not = completely contradictory or orthogonal) so let=E2=80=99s grab = it!
>>
>> From: vot [mailto:vot-bounces@ietf.org] On Behalf = Of Robin Wilton
>> Sent: Tuesday, 13 January 2015 11:22 = a.m.
>> To: Jim Fenton
>> Cc: vot@ietf.org
>> Subject: Re: = [VoT] capturing the threads of the discussion
>>
>> = Thanks Jim,
>>
>> I won't give a substantive response = here; just to note that I think it's worth considering a repository so = that we can capture 'static' versions of any straw-man docs, to = complement what we it into the mail thread...
>>
>> = Sorry to be brief at this stage - just tying up some loose ends before = an absence from the office.
>>
>> = R
>>
>> Robin Wilton
>>
>> Technical = Outreach Director - Identity and Privacy
>>
>> On 12 = Jan 2015, at 21:45, "Jim Fenton" <fenton@bluepopcorn.net> = wrote:
>>
>> Maybe I should be breaking these apart as = Robin suggests, but for now I'll keep this in one = reply:
>>
>> On 1/12/15 6:06 AM, Robin Wilton = wrote:
>> This thread raises several important topics=E2=80=A6 = just as a practical matter, it might be worth trying to spin some of = them off separately, so that we address them all, and minimise the risk = of talking at cross-purposes.
>> It feels like it would be = worth trying to put together some *very short* straw-man = docs/pages/paragraphs to try and get a consensus version on specific = points, so that we avoid re-hashing the same arguments/discussions over = time, or at least have something we can refer to - and amend if = necessary. I think this is aiming at the same end-point as = Steve=E2=80=99s request for a statement of requirements, but will ensure = we=E2=80=99re expressing our requirements in a consistent set of = terms.
>>
>>
>> By the looks of it, these = would make for a good starting point (I think the answers to most of = these are implicit in various people=E2=80=99s contributions to the = thread=E2=80=A6 but that doesn=E2=80=99t mean everyone agrees ;^)  = ):
>>
>>
>> 1 - what do we mean by = authentication and authorisation? Are there other decisions (e.g. access = control, entitlement) which need to be called out explicitly? This = reflects the purpose of Justin=E2=80=99s questions. Classically, the = reason for authenticating a user is to answer a yes/no question (is this = the person to whom this credential was originally issued); if yes, what = do I want to do about it (at which point the further entitlements are = usually determined by retrieving a user profile, ACL or = whatever)?
>>
>> Access control and entitlement as = distinct from authorisation? Is there a distinction, or are people just = using different terminology?
>>
>> I think of = authentication as providing more than a yes/no answer: it provides an = identifier. If the relying party has enough information (perhaps on the = basis of previous interactions) to authorize something with just that, = fine. Otherwise some attributes are needed to make an authorisation = decision.
>>
>>
>> However, as we know, these = days access control and entitlement decisions also need to be made on = the basis of input other than classic credentials, and that=E2=80=99s = one of the two cores of this discussion, I = believe.
>>
>> Example of an "input other than = classic = credentials"?
>>
>>
>>
>>
>= ;> 2 - what=E2=80=99s the classic lifecycle of a credential - i.e. a = artefact intended to provide evidence in support of an assertion of = identity. (e.g. registration/verification/enrolment, credential issue, = credential presentation/authentication, credential = amendment/revocation/destruction=E2=80=A6)?
>>
>>
&g= t;> Credential is another of those tricky words. Sometimes it means = the same as an authentication token. Sometimes it has some attributes = bound to it, which means it has both an authentication and attribute = provision flavor to it. I find it simpler to talk about tokens, where = one doesn't have to deal with revocation when some attribute = (employment, for example) = changes.
>>
>>
>>
>> 3 - How does = (2) relate to other assertions (e.g. attribute assertions) we would like = to make reliably?
>>
>>
>> With that starter = set, I think we can confirm the subset of requirements that 800-63-1 = still meets, and define the delta that requires new = design.
>>
>> 4 - What=E2=80=99s the right way to = update current thinking on LOAs, to account for the change Jim describes = in his proposal - i.e., the case where "credentials (used in = authentication) and attribute information (established through identity = proofing) could be provided by different = parties.=E2=80=9D
>>
>> 5 - From Jim=E2=80=99s = proposal: =E2=80=9CAttribute reliability refers to the quality of the = identity proofing process, as well as the strength of the binding of the = identifying attributes to the authentication.=E2=80=9D Do we need/want = to expand on this a little? This seems to cater well for the case where, = say, vehicle entitlements are being established so that they can be = encapsulated in a driving licence. It=E2=80=99s not so clear how this = addresses, say, third party assertions that do not arise from an = identity proofing process - =E2=80=9CI have no idea *who* this user is, = but I can reliably assert the following about them: ... = =E2=80=9D.
>>
>> You're right; that will need to be = defined. But it should be possible to define analogous requirements to = describe the strength of the binding to the token. When you show up to = enroll at school, it should be possible to use your token to allow your = school to make LOR 3 asserts that you're there student. But maybe remote = students only get LOR 2?
>>
>> = -Jim
>>
> vot mailing list
> vot@ietf.org
> https://www.ietf.org/mailman/listinfo/vot

_______________________________________________
vot mailing = list
vot@ietf.org
https://www.ietf.org/mailman/listinfo/vot

 

------=_NextPart_000_06CA_01D03115.5D1536D0-- From nobody Thu Jan 15 12:54:26 2015 Return-Path: X-Original-To: vot@ietfa.amsl.com Delivered-To: vot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2F991B29CD for ; Thu, 15 Jan 2015 12:54:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.022 X-Spam-Level: *** X-Spam-Status: No, score=3.022 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MANGLED_MARKET=2.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_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 UOhH3KIX_Iuu for ; Thu, 15 Jan 2015 12:54:12 -0800 (PST) Received: from mail-oi0-f51.google.com (mail-oi0-f51.google.com [209.85.218.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C73F01B29CC for ; Thu, 15 Jan 2015 12:54:11 -0800 (PST) Received: by mail-oi0-f51.google.com with SMTP id h136so14328619oig.10 for ; Thu, 15 Jan 2015 12:54:11 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=uYg7w2pLbM49zGimQN+l5H2koQ9P+SMPPDCw5EvpZNs=; b=aMXs0E6LpZMtOnP/A4I+5kqcIthvs3PCUOZIFX1yGTiEFLgjFac8gc4y9pIPSVtzVF U9wjSDPTsCPZVhRNjj5GERPXA37AwlnElJEhI05P0lv7s0f6xC10OX3fCt6htNL9SfI0 inxnHDiO5c5tL/kjx+T/y5ul084AuIfdsZOKziC8UAahSxRQ/z+6s0cSC0WenVcy4QRj HuqAhUj0EbdqcOQu+varv4OsWOO3yFZui14JWLr0LoSbZKsVi7s3ZxVtVr/BPcvhLY5L 1Ny4oH8z2MuaId4jYN06BM9oqWfE8T1r/Q62WPMtdxFrfKkmE2M/WtqQSc5cu//WYLDo dyMg== X-Gm-Message-State: ALoCoQkCkPz2MMjB2+4NSpqijkZH1f0HJD5yvLfmGA9bWk0FMf8evvuX3qTbddi/inS5wR5PFFXu MIME-Version: 1.0 X-Received: by 10.60.155.195 with SMTP id vy3mr7263603oeb.62.1421355251110; Thu, 15 Jan 2015 12:54:11 -0800 (PST) Received: by 10.202.66.87 with HTTP; Thu, 15 Jan 2015 12:54:11 -0800 (PST) In-Reply-To: <06c901d03104$998031d0$cc809570$@sk.ee> References: <06c901d03104$998031d0$cc809570$@sk.ee> Date: Thu, 15 Jan 2015 15:54:11 -0500 Message-ID: From: Peter Alterman To: Tarvi Martens Content-Type: multipart/alternative; boundary=089e0102dc32d7aa5d050cb70ecd Archived-At: Cc: vot@ietf.org Subject: Re: [VoT] vot Digest, Vol 5, Issue 6 X-BeenThere: vot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Vectors of Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2015 20:54:19 -0000 --089e0102dc32d7aa5d050cb70ecd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Tarvi, Agreed, and it gets more interesting this year and next, when the EC plans to certify services against the Low and Substantial levels, leaving High to the QCP (which includes Estonia, an example to us all). Peter ------------------------------------------------------------ Peter Alterman, Ph.D. Chief Operating Officer SAFE-BioPharma Association cell: 301-943-7452 On Thu, Jan 15, 2015 at 3:48 PM, Tarvi Martens wrote: > Hi, > > > > The principle of Eurpean eIDAS eID recognition is mainly that =E2=80=9Eif= you > trust this in your country then other EU states shall it trust as well in > their e-services=E2=80=9C. Oh well, when it is sort of =E2=80=9Eregistere= d and assessed=E2=80=9C. > > > > In general terms it comes down to community (read: RP-s) trust. For > example hardly anyone would question Estonian ID-card for it security aft= er > living 13 years of harmless life, > > > > Tarvi > > > > *From:* vot [mailto:vot-bounces@ietf.org] *On Behalf Of *Peter Alterman > *Sent:* Tuesday, January 13, 2015 8:00 PM > *To:* vot@ietf.org > *Subject:* Re: [VoT] vot Digest, Vol 5, Issue 6 > > > > =E2=80=8BHappy new year to you all. I've been reading the mail but unabl= e to > break away long enough to comment until now. As I read it, the issue on t= he > table is how to express trustworthiness. > > > > If Abbie was here he'd point you all to the one-to-one correlation betwee= n > trust and threat/threat vector mitigation.=E2=80=8B I recommend to you th= e Third > Deliverable of the OASIS Trust Elevation TC - link provided upon > demonstration of curiosity ;-) > > > > An RP trusts an external assertion of identity (or even extended > attributes) to the extent that the assertion is created and/or can be > verified to a predetermined degree of threat/risk mitigation. This degree > is baked into policy or contract or some other pre-existing agreement > (think banking regulations, etc.) and is locally determined based upon > local considerations, e.g., no global standard is appropriate. So far as= I > can see, vectors of trust are the same thing as the threats and threat > vectors that are enumerated in ISO 29115 and other places, not least of > which are controls in NIST 800-53-4 and in ISO 27001/2. I really don't se= e > the vectors as anything different from these and considering > trustworthiness as the inverse of threat in this context is pretty much > what everybody seems to be saying. > > > > If we just use 29115 as our baseline of threats and threat vectors, there > are roughly a dozen or so of them associated with authentication of > identity assertion. I don't think any of us believe that a > twelve-dimensional assertion is practically viable, even if we could agre= e > on a common metric for degree of threat mitigation (fat chance that). Thi= s > has also already been addressed by the community: think of the factor > model, one to four factors (the fourth is context, which may be expressed > as "Where or when you are," according to our colleagues). What this does = is > boil down the trust/threat algorithm to no more than four dimensions and > shifts the discussion to the aforementioned conundrum, e.g., how to > evaluate and rate the degree of threat mitigation. Various communities ha= ve > developed policies and practices to address this question, the most recen= t > of which, I think, is EU Regulation 910/2014 (eIDAS). > > > > IMO, the greatest opportunity open to us is to find a way to normalize al= l > the various community policies and practices so that RPs can assess wheth= er > assertions issued under one community's metrics align with their adopted > risk mitigation requirements. I think that has to be addressed in the > context of how effective a particular mitigation action is on a recognize= d > threat vector. I would be most interested in your thoughts on that > problem. > > > > regards, > > > > Peter > > > ------------------------------------------------------------ > > Peter Alterman, Ph.D. > > Chief Operating Officer > SAFE-BioPharma Association > > cell: 301-943-7452 > > > > On Tue, Jan 13, 2015 at 8:19 AM, wrote: > > Send vot mailing list submissions to > vot@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/vot > or, via email, send a message with subject or body 'help' to > vot-request@ietf.org > > You can reach the person managing the list at > vot-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of vot digest..." > > Today's Topics: > > 1. Re: capturing the threads of the discussion (Robin Wilton) > 2. VoT wiki (Steve Olshansky) > > > ---------- Forwarded message ---------- > From: Robin Wilton > To: Colin Wallis > Cc: Jim Fenton , "vot@ietf.org" > Date: Tue, 13 Jan 2015 09:31:59 +0000 > Subject: Re: [VoT] capturing the threads of the discussion > > Oops - I'd forgotten about the wiki: apologies! Yes, I think that's the > place to start... > > > > R > > Robin Wilton > > > > Technical Outreach Director - Identity and Privacy > > > On 12 Jan 2015, at 23:43, "Colin Wallis" wrote= : > > Well as Steve O pointed out in this attached email in November, the wiki > set up for this work might be a place to start.. > > There may be some jiggery pokery to get the folks on this list who want t= o > contribute (who were not attendees at Utrecht) access rights, but it woul= d > seem to me to be the obvious starter option for a repository. > > Cheers > > Colin > > PS: BTW this is a good discussion and indeed an opportunistic time to > bring it together since so much of what Justin, Jim, Scott, Ken, Steve W, > Mark et al have commented recently is complementary (well at least not > completely contradictory or orthogonal) so let=E2=80=99s grab it! > > > > *From:* vot [mailto:vot-bounces@ietf.org] *On Behalf Of *Robin Wilton > *Sent:* Tuesday, 13 January 2015 11:22 a.m. > *To:* Jim Fenton > *Cc:* vot@ietf.org > *Subject:* Re: [VoT] capturing the threads of the discussion > > > > Thanks Jim, > > > > I won't give a substantive response here; just to note that I think it's > worth considering a repository so that we can capture 'static' versions o= f > any straw-man docs, to complement what we it into the mail thread... > > > > Sorry to be brief at this stage - just tying up some loose ends before an > absence from the office. > > > > R > > Robin Wilton > > > > Technical Outreach Director - Identity and Privacy > > > On 12 Jan 2015, at 21:45, "Jim Fenton" wrote: > > Maybe I should be breaking these apart as Robin suggests, but for now I'l= l > keep this in one reply: > > On 1/12/15 6:06 AM, Robin Wilton wrote: > > This thread raises several important topics=E2=80=A6 just as a practical = matter, > it might be worth trying to spin some of them off separately, so that we > address them all, and minimise the risk of talking at cross-purposes. > > It feels like it would be worth trying to put together some *very short* > straw-man docs/pages/paragraphs to try and get a consensus version on > specific points, so that we avoid re-hashing the same arguments/discussio= ns > over time, or at least have something we can refer to - and amend if > necessary. I think this is aiming at the same end-point as Steve=E2=80=99= s request > for a statement of requirements, but will ensure we=E2=80=99re expressing= our > requirements in a consistent set of terms. > > > > By the looks of it, these would make for a good starting point (I think > the answers to most of these are implicit in various people=E2=80=99s con= tributions > to the thread=E2=80=A6 but that doesn=E2=80=99t mean everyone agrees ;^) = ): > > > > 1 - what do we mean by authentication and authorisation? Are there other > decisions (e.g. access control, entitlement) which need to be called out > explicitly? This reflects the purpose of Justin=E2=80=99s questions. Clas= sically, > the reason for authenticating a user is to answer a yes/no question (is > this the person to whom this credential was originally issued); if yes, > what do I want to do about it (at which point the further entitlements ar= e > usually determined by retrieving a user profile, ACL or whatever)? > > > Access control and entitlement as distinct from authorisation? Is there a > distinction, or are people just using different terminology? > > I think of authentication as providing more than a yes/no answer: it > provides an identifier. If the relying party has enough information > (perhaps on the basis of previous interactions) to authorize something wi= th > just that, fine. Otherwise some attributes are needed to make an > authorisation decision. > > However, as we know, these days access control and entitlement decisions > also need to be made on the basis of input other than classic credentials= , > and that=E2=80=99s one of the two cores of this discussion, I believe. > > > Example of an "input other than classic credentials"? > > > > 2 - what=E2=80=99s the classic lifecycle of a credential - i.e. a artefac= t > intended to provide evidence in support of an assertion of identity. (e.g= . > registration/verification/enrolment, credential issue, credential > presentation/authentication, credential amendment/revocation/destruction= =E2=80=A6)? > > > Credential is another of those tricky words. Sometimes it means the same > as an authentication token. Sometimes it has some attributes bound to it, > which means it has both an authentication and attribute provision flavor = to > it. I find it simpler to talk about tokens, where one doesn't have to dea= l > with revocation when some attribute (employment, for example) changes. > > > > 3 - How does (2) relate to other assertions (e.g. attribute assertions) w= e > would like to make reliably? > > > > With that starter set, I think we can confirm the subset of requirements > that 800-63-1 still meets, and define the delta that requires new design. > > > > 4 - What=E2=80=99s the right way to update current thinking on LOAs, to a= ccount > for the change Jim describes in his proposal - i.e., the case where "cred= entials > (used in authentication) and attribute information (established through > identity proofing) could be provided by different parties.=E2=80=9D > > > > 5 - From Jim=E2=80=99s proposal: =E2=80=9CAttribute reliability refers to= the quality of > the identity proofing process, as well as the strength of the binding of > the identifying attributes to the authentication.=E2=80=9D Do we need/wan= t to > expand on this a little? This seems to cater well for the case where, say= , > vehicle entitlements are being established so that they can be encapsulat= ed > in a driving licence. It=E2=80=99s not so clear how this addresses, say, = third > party assertions that do not arise from an identity proofing process - = =E2=80=9CI > have no idea *who* this user is, but I can reliably assert the following > about them: ... =E2=80=9D. > > > You're right; that will need to be defined. But it should be possible to > define analogous requirements to describe the strength of the binding to > the token. When you show up to enroll at school, it should be possible to > use your token to allow your school to make LOR 3 asserts that you're the= re > student. But maybe remote students only get LOR 2? > > -Jim > > All- > There unfortunately is a long-standing bug in Confluence. You must be > logged in before that link, or any link to a restricted page, will work. > > The wiki space for workshop attendees only, which you all have full edit > access to and which is not publicly viewable, is athttps:// > tid.isoc.org/confluence/display/interfedgen/ > > The *PUBLIC* wiki space, containing the agenda, presentations, and > contributions/references, is at > https://tid.isoc.org/confluence/display/interfed/ > > As we make progress on work items and are ready to move them to the publi= c > wiki, I will be happy to do that. Our goal is of course to make as much o= f > our work as possible available to the public, but this restricted wiki > space gives us a place to work on things before revealing them to the wor= ld. > > As always, if anyone has questions or problems related to the wiki, or > anything else, please do let me know. > Steve > > -- > Steve Olshansky > Trust & Identity Program Lead > Internet Society > www.internetsociety.org > > > > _______________________________________________ > Ideco-fab mailing list > Ideco-fab@elists.isoc.org > https://elists.isoc.org/mailman/listinfo/ideco-fab > > > > ---------- Forwarded message ---------- > From: Steve Olshansky > To: "vot@ietf.org" > Cc: > Date: Tue, 13 Jan 2015 13:19:22 +0000 > Subject: [VoT] VoT wiki > All- > This is a great discussion, and the stars seem to be aligning now for the > development of some documents or any other related artifacts. > > I setup a dedicated wiki space for use by this group. It is open to the > world for viewing, but we can easily make restricted areas for the purpos= e > of working on documents before publishing. Anyone would would like edit > access is welcome to contact me directly (off-list). > https://tid.isoc.org/confluence/display/vot/VoT+Home > Steve > > -- > Steve Olshansky > Trust & Identity Program Lead > Internet Society > www.internetsociety.org > > On Jan 13, 2015, at 2:31 AM, Robin Wilton wrote: > > > Oops - I'd forgotten about the wiki: apologies! Yes, I think that's the > place to start... > > > > R > > > > Robin Wilton > > > > Technical Outreach Director - Identity and Privacy > > > > On 12 Jan 2015, at 23:43, "Colin Wallis" > wrote: > > > >> Well as Steve O pointed out in this attached email in November, the > wiki set up for this work might be a place to start.. > >> There may be some jiggery pokery to get the folks on this list who wan= t > to contribute (who were not attendees at Utrecht) access rights, but it > would seem to me to be the obvious starter option for a repository. > >> Cheers > >> Colin > >> PS: BTW this is a good discussion and indeed an opportunistic time to > bring it together since so much of what Justin, Jim, Scott, Ken, Steve W, > Mark et al have commented recently is complementary (well at least not > completely contradictory or orthogonal) so let=E2=80=99s grab it! > >> > >> From: vot [mailto:vot-bounces@ietf.org] On Behalf Of Robin Wilton > >> Sent: Tuesday, 13 January 2015 11:22 a.m. > >> To: Jim Fenton > >> Cc: vot@ietf.org > >> Subject: Re: [VoT] capturing the threads of the discussion > >> > >> Thanks Jim, > >> > >> I won't give a substantive response here; just to note that I think > it's worth considering a repository so that we can capture 'static' > versions of any straw-man docs, to complement what we it into the mail > thread... > >> > >> Sorry to be brief at this stage - just tying up some loose ends before > an absence from the office. > >> > >> R > >> > >> Robin Wilton > >> > >> Technical Outreach Director - Identity and Privacy > >> > >> On 12 Jan 2015, at 21:45, "Jim Fenton" wrote: > >> > >> Maybe I should be breaking these apart as Robin suggests, but for now > I'll keep this in one reply: > >> > >> On 1/12/15 6:06 AM, Robin Wilton wrote: > >> This thread raises several important topics=E2=80=A6 just as a practic= al > matter, it might be worth trying to spin some of them off separately, so > that we address them all, and minimise the risk of talking at > cross-purposes. > >> It feels like it would be worth trying to put together some *very > short* straw-man docs/pages/paragraphs to try and get a consensus version > on specific points, so that we avoid re-hashing the same > arguments/discussions over time, or at least have something we can refer = to > - and amend if necessary. I think this is aiming at the same end-point as > Steve=E2=80=99s request for a statement of requirements, but will ensure = we=E2=80=99re > expressing our requirements in a consistent set of terms. > >> > >> > >> By the looks of it, these would make for a good starting point (I thin= k > the answers to most of these are implicit in various people=E2=80=99s con= tributions > to the thread=E2=80=A6 but that doesn=E2=80=99t mean everyone agrees ;^) = ): > >> > >> > >> 1 - what do we mean by authentication and authorisation? Are there > other decisions (e.g. access control, entitlement) which need to be calle= d > out explicitly? This reflects the purpose of Justin=E2=80=99s questions. > Classically, the reason for authenticating a user is to answer a yes/no > question (is this the person to whom this credential was originally > issued); if yes, what do I want to do about it (at which point the furthe= r > entitlements are usually determined by retrieving a user profile, ACL or > whatever)? > >> > >> Access control and entitlement as distinct from authorisation? Is ther= e > a distinction, or are people just using different terminology? > >> > >> I think of authentication as providing more than a yes/no answer: it > provides an identifier. If the relying party has enough information > (perhaps on the basis of previous interactions) to authorize something wi= th > just that, fine. Otherwise some attributes are needed to make an > authorisation decision. > >> > >> > >> However, as we know, these days access control and entitlement > decisions also need to be made on the basis of input other than classic > credentials, and that=E2=80=99s one of the two cores of this discussion, = I believe. > >> > >> Example of an "input other than classic credentials"? > >> > >> > >> > >> > >> 2 - what=E2=80=99s the classic lifecycle of a credential - i.e. a arte= fact > intended to provide evidence in support of an assertion of identity. (e.g= . > registration/verification/enrolment, credential issue, credential > presentation/authentication, credential amendment/revocation/destruction= =E2=80=A6)? > >> > >> > >> Credential is another of those tricky words. Sometimes it means the > same as an authentication token. Sometimes it has some attributes bound t= o > it, which means it has both an authentication and attribute provision > flavor to it. I find it simpler to talk about tokens, where one doesn't > have to deal with revocation when some attribute (employment, for example= ) > changes. > >> > >> > >> > >> 3 - How does (2) relate to other assertions (e.g. attribute assertions= ) > we would like to make reliably? > >> > >> > >> With that starter set, I think we can confirm the subset of > requirements that 800-63-1 still meets, and define the delta that require= s > new design. > >> > >> 4 - What=E2=80=99s the right way to update current thinking on LOAs, t= o account > for the change Jim describes in his proposal - i.e., the case where > "credentials (used in authentication) and attribute information > (established through identity proofing) could be provided by different > parties.=E2=80=9D > >> > >> 5 - From Jim=E2=80=99s proposal: =E2=80=9CAttribute reliability refers= to the quality > of the identity proofing process, as well as the strength of the binding = of > the identifying attributes to the authentication.=E2=80=9D Do we need/wan= t to > expand on this a little? This seems to cater well for the case where, say= , > vehicle entitlements are being established so that they can be encapsulat= ed > in a driving licence. It=E2=80=99s not so clear how this addresses, say, = third > party assertions that do not arise from an identity proofing process - = =E2=80=9CI > have no idea *who* this user is, but I can reliably assert the following > about them: ... =E2=80=9D. > >> > >> You're right; that will need to be defined. But it should be possible > to define analogous requirements to describe the strength of the binding = to > the token. When you show up to enroll at school, it should be possible to > use your token to allow your school to make LOR 3 asserts that you're the= re > student. But maybe remote students only get LOR 2? > >> > >> -Jim > >> > > vot mailing list > > vot@ietf.org > > https://www.ietf.org/mailman/listinfo/vot > > > _______________________________________________ > vot mailing list > vot@ietf.org > https://www.ietf.org/mailman/listinfo/vot > > > --089e0102dc32d7aa5d050cb70ecd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Ta= rvi,

Agreed, and it gets more= interesting this year and next, when the EC plans to certify services agai= nst the Low and Substantial levels, leaving High to the QCP (which includes= Estonia, an example to us all).

Peter

----------------= --------------------------------------------
Peter Alterman, Ph.D.=
Chief Operating Officer
SAFE-BioPharma Association
ce= ll: 301-943-7452


On Thu, Jan 15, 2015 at 3:48 PM, Tarvi Marte= ns <t= arvi@sk.ee> wrote:

Hi,

=C2=A0

The principle of Eurpean eIDAS eID recognition= is mainly that =E2=80=9Eif you trust this in your country then other EU st= ates shall it trust as well in their e-services=E2=80=9C. Oh well, when it = is sort of =E2=80=9Eregistered and assessed=E2=80=9C.<= /p>

=C2=A0

In general terms= it comes down to community (read: RP-s) trust. For example hardly anyone w= ould question Estonian ID-card for it security after living 13 years of har= mless life,

=C2=A0

Tarvi

=C2=A0

From: vot [mailto:vot= -bounces@ietf.org] On Behalf Of Peter Alterman
Sent: T= uesday, January 13, 2015 8:00 PM
To: vot@ietf.org
Subject: Re: [VoT] vot Dig= est, Vol 5, Issue 6

= =C2=A0

=E2=80=8BHappy new year to you all.=C2=A0 I've been reading the mail= but unable to break away long enough to comment until now. As I read it, t= he issue on the table is how to express trustworthiness.=C2=A0

<= u>=C2=A0

If Abbie was here he'd point you all to the one-to-one= correlation between trust and threat/threat vector mitigation.=E2=80=8B I = recommend to you the Third Deliverable of the OASIS Trust Elevation TC =C2= =A0- link provided upon demonstration of curiosity ;-)=

= =C2=A0

=C2=A0An RP trusts an external assertion of identity (or even ex= tended attributes) to the extent that the assertion is created and/or can b= e verified to a predetermined degree of threat/risk mitigation. This degree= is baked into policy or contract or some other pre-existing agreement (thi= nk banking regulations, etc.) and is locally determined based upon local co= nsiderations, e.g., no global standard is appropriate.=C2=A0 So far as I ca= n see, vectors of trust are the same thing as the threats and threat vector= s that are enumerated in ISO 29115 and other places, not least of which are= controls in NIST 800-53-4 and in ISO 27001/2. I really don't see the v= ectors as anything different from these and considering trustworthiness as = the inverse of threat in this context is pretty much what everybody seems t= o be saying.=C2=A0

=C2=A0

If we just use 29115 as our= baseline of threats and threat vectors, there are roughly a dozen or so of= them associated with authentication of identity assertion. I don't thi= nk any of us believe that a twelve-dimensional assertion is practically via= ble, even if we could agree on a common metric for degree of threat mitigat= ion (fat chance that). This has also already been addressed by the communit= y: think of the factor model, one to four factors (the fourth is context, w= hich may be expressed as "Where or when you are," according to ou= r colleagues). What this does is boil down the trust/threat algorithm to no= more than four dimensions and shifts the discussion to the aforementioned = conundrum, e.g., how to evaluate and rate the degree of threat mitigation. = Various communities have developed policies and practices to address this q= uestion, the most recent of which, I think, is EU Regulation 910/2014 (eIDA= S).=C2=A0

=C2=A0

IMO, the greatest opportunity open t= o us is to find a way to normalize all the various community policies and p= ractices so that RPs can assess whether assertions issued under one communi= ty's metrics align with their adopted risk mitigation requirements. I t= hink that has to be addressed in the context of how effective a particular = mitigation action is on a recognized threat vector. =C2=A0 I would be most = interested in your thoughts on that problem.

=

=C2=A0

r= egards,

=C2=A0

Peter


-----------------------------= -------------------------------

Peter Alterman, Ph.D.

Chie= f Operating Officer
SAFE-BioPharma Association

cell: 301-943-7452

=C2=A0

On Tue, Jan 13, 2015 at 8:19 AM, <vot-request@ietf.org= > wrote:

Send vot mailing list s= ubmissions to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 vot@ietf.org

To subscribe or unsubscribe via= the World Wide Web, visit
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org= /mailman/listinfo/vot
or, via email, send a message with subject or = body 'help' to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 vot-request@ietf.org

You ca= n reach the person managing the list at
=C2=A0 =C2=A0 =C2=A0 =C2=A0 vot-owner@ietf.org<= br>
When replying, please edit your Subject line so it is more specific<= br>than "Re: Contents of vot digest..."

Today's Topics= :

=C2=A0 =C2=A01. Re: capturing the threads of the discussion (Robin= Wilton)
=C2=A0 =C2=A02. VoT wiki (Steve Olshansky)


---------= - Forwarded message ----------
From:=C2=A0Robin Wilton <wilton@isoc.org>
To:=C2= =A0Colin Wallis <Colin.Wallis@dia.govt.nz>
Cc:=C2=A0Jim Fenton <fenton@bluepopcorn.net= >, "vot@ietf.= org" <vot@iet= f.org>
Date:=C2=A0Tue, 13 Jan 2015 09:31:59 +0000
Subject:=C2= =A0Re: [VoT] capturing the threads of the discussion

=

Oops - I'd forgotten about the wiki: apolog= ies! Yes, I think that's the place to start...

<= div>

=C2=A0

R

Robin Wilton

=C2=A0

Technical Outreach D= irector - Identity and Privacy


On 12 Jan 2015, at 23= :43, "Colin Wallis" <Colin.Wallis@dia.govt.nz> wrote:<= /p>

Well as Steve O pointe= d out in this attached email in November, the wiki set up for this work mig= ht be a place to start..

There may be some jiggery pokery to get the folks o= n this list who want to contribute (who were not attendees at Utrecht) acce= ss rights, but it would seem to me to be the obvious starter option for a r= epository.

Cheers

Colin

PS: BTW this is a good d= iscussion and indeed an opportunistic time to bring it together since so mu= ch of what Justin, Jim, Scott, Ken, Steve W, Mark et al have commented rece= ntly is complementary (well at least not completely contradictory or orthog= onal) so let=E2=80=99s grab it!

=C2=A0

From: vot [mailto:vot-bounces@ietf.org] On Behalf Of Robin Wilt= on
Sent: Tuesday, 13 January 2015 11:22 a.m.
To: Jim Fe= nton
Cc: vot@ie= tf.org
Subject: Re: [VoT] capturing the threads of the discus= sion

=C2=A0

Thanks Jim,

=C2=A0

I won't give a substantive response here; just to note that= I think it's worth considering a repository so that we can capture = 9;static' versions of any straw-man docs, to complement what we it into= the mail thread...

=C2= =A0

Sorry to be brief at= this stage - just tying up some loose ends before an absence from the offi= ce.

=C2=A0=

R

Robin Wilton <= /p>

=C2=A0

Technical Outreach Director - Identity and Privacy


On 12 Jan 2015, at 21:45, "Jim Fenton" <fenton@bluepopcorn.net>= wrote:

Maybe I should be breaking = these apart as Robin suggests, but for now I'll keep this in one reply:=

On 1/12/15 6:06 AM, Robin Wilton wrote:

This thread raises several important topics=E2=80=A6 just as a practical= matter, it might be worth trying to spin some of them off separately, so t= hat we address them all, and minimise the risk of talking at cross-purposes= . =C2=A0

It feels like it woul= d be worth trying to put together some *very short* straw-man docs/pages/pa= ragraphs to try and get a consensus version on specific points, so that we = avoid re-hashing the same arguments/discussions over time, or at least have= something we can refer to - and amend if necessary. I think this is aiming= at the same end-point as Steve=E2=80=99s request for a statement of requir= ements, but will ensure we=E2=80=99re expressing our requirements in a cons= istent set of terms.

=C2=A0

By the looks of it, these would make for a good starti= ng point (I think the answers to most of these are implicit in various peop= le=E2=80=99s contributions to the thread=E2=80=A6 but that doesn=E2=80=99t = mean everyone agrees ;^) =C2=A0):

=C2=A0

1 - what do we mean by authenticat= ion and authorisation? Are there other decisions (e.g. access control, enti= tlement) which need to be called out explicitly? This reflects the purpose = of Justin=E2=80=99s questions. Classically, the reason for authenticating a= user is to answer a yes/no question (is this the person to whom this crede= ntial was originally issued); if yes, what do I want to do about it (at whi= ch point the further entitlements are usually determined by retrieving a us= er profile, ACL or whatever)?


Access control and = entitlement as distinct from authorisation? Is there a distinction, or are = people just using different terminology?

I think of authentication a= s providing more than a yes/no answer: it provides an identifier. If the re= lying party has enough information (perhaps on the basis of previous intera= ctions) to authorize something with just that, fine. Otherwise some attribu= tes are needed to make an authorisation decision.

=

However, as we know, these days acces= s control and entitlement decisions also need to be made on the basis of in= put other than classic credentials, and that=E2=80=99s one of the two cores= of this discussion, I believe.


Example of an "input othe= r than classic credentials"?

=C2=A0

2 - what= =E2=80=99s the classic lifecycle of a credential - i.e. a artefact intended= to provide evidence in support of an assertion of identity. (e.g. registra= tion/verification/enrolment, credential issue, credential presentation/auth= entication, credential amendment/revocation/destruction=E2=80=A6)? <= u>


Credential is another of those tricky words. Sometimes it means the s= ame as an authentication token. Sometimes it has some attributes bound to i= t, which means it has both an authentication and attribute provision flavor= to it. I find it simpler to talk about tokens, where one doesn't have = to deal with revocation when some attribute (employment, for example) chang= es.

=C2=A0

3= - How does (2) relate to other assertions (e.g. attribute assertions) we w= ould like to make reliably?

=C2=A0

With that starter set, I think we can confirm the = subset of requirements that 800-63-1 still meets, and define the delta that= requires new design.

= =C2=A0

4 - What=E2=80=99= s the right way to update current thinking on LOAs, to account for the chan= ge Jim describes in his proposal - i.e., the case where "credentials (used in authentication) and att= ribute information (established through identity proofing) could be provide= d by different parties.=E2=80=9D<= /u>

=C2=A0

5 - From Jim=E2=80=99s proposal: =E2=80=9CAttribute reliability refers to the quality of the i= dentity proofing process, as well as the strength of the binding of the ide= ntifying attributes to the authentication.=E2=80=9D Do we need/want = to expand on this a little? This seems to cater well for the case where, sa= y, vehicle entitlements are being established so that they can be encapsula= ted in a driving licence. It=E2=80=99s not so clear how this addresses, say= , third party assertions that do not arise from an identity proofing proces= s - =E2=80=9CI have no idea *who* this user is, but I can reliably assert t= he following about them: ... =E2=80=9D.


You're right; that will n= eed to be defined. But it should be possible to define analogous requiremen= ts to describe the strength of the binding to the token. When you show up t= o enroll at school, it should be possible to use your token to allow your s= chool to make LOR 3 asserts that you're there student. But maybe remote= students only get LOR 2?

-Jim

<= /div>

All-
= There unfortunately is a long-standing bug in Confluence. You must be logge= d in before that link, or any link to a restricted page, will work.

= The wiki space for workshop attendees only, which you all have full edit ac= cess to and which is not publicly viewable, is athttps://tid.isoc.or= g/confluence/display/interfedgen/

The *PUBLIC* wiki space, conta= ining the agenda, presentations, and contributions/references, is at
https://tid.isoc.org/confluence/display/interfed/

As we make p= rogress on work items and are ready to move them to the public wiki, I will= be happy to do that. Our goal is of course to make as much of our work as = possible available to the public, but this restricted wiki space gives us a= place to work on things before revealing them to the world.

As alwa= ys, if anyone has questions or problems related to the wiki, or anything el= se, please do let me know.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Ste= ve

--
Steve Olshansky
Trust & Identity Program Lead
Int= ernet Society
www.internetsociety.org

=

<signature.asc>

_______________________________________________
Ideco-fab mailing= list
Ide= co-fab@elists.isoc.org
https://elists.isoc.org/mailman/listinf= o/ideco-fab



---------- Forwarded message -= ---------
From:=C2=A0Steve Olshansky <olshansky@isoc.org>
To:=C2=A0"vot@ietf.org" <vot@ietf.org>
Cc:= =C2=A0
Date:=C2=A0Tue, 13 Jan 2015 13:19:22 +0000
Subject:=C2=A0[VoT]= VoT wiki
All-
This is a great discussion, and the stars seem to be a= ligning now for the development of some documents or any other related arti= facts.

I setup a dedicated wiki space for use by this group. It is o= pen to the world for viewing, but we can easily make restricted areas for t= he purpose of working on documents before publishing. Anyone would would li= ke edit access is welcome to contact me directly (off-list).
htt= ps://tid.isoc.org/confluence/display/vot/VoT+Home
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 Steve

--
Steve Olshansky
Trust & Identity Progr= am Lead
Internet Society
www.internetsociety.org

On Jan 13, 2015, at 2:3= 1 AM, Robin Wilton <wilton@isoc.org> wrote:

> Oops - I'd forgotten about = the wiki: apologies! Yes, I think that's the place to start...
><= br>> R
>
> Robin Wilton
>
> Technical Outreach D= irector - Identity and Privacy
>
> On 12 Jan 2015, at 23:43, &q= uot;Colin Wallis" <Colin.Wallis@dia.govt.nz> wrote:
>
>> W= ell as Steve O pointed out in this attached email in November, the wiki set= up for this work might be a place to start..
>> There may be some= jiggery pokery to get the folks on this list who want to contribute (who w= ere not attendees at Utrecht) access rights, but it would seem to me to be = the obvious starter option for a repository.
>> Cheers
>>= Colin
>> PS: BTW this is a good discussion and indeed an opportun= istic time to bring it together since so much of what Justin, Jim, Scott, K= en, Steve W, Mark et al have commented recently is complementary (well at l= east not completely contradictory or orthogonal) so let=E2=80=99s grab it!<= br>>>
>> From: vot [mailto:vot-bounces@ietf.org] On Behalf Of Robin Wilto= n
>> Sent: Tuesday, 13 January 2015 11:22 a.m.
>> To: Jim= Fenton
>> Cc: v= ot@ietf.org
>> Subject: Re: [VoT] capturing the threads of the= discussion
>>
>> Thanks Jim,
>>
>> I w= on't give a substantive response here; just to note that I think it'= ;s worth considering a repository so that we can capture 'static' v= ersions of any straw-man docs, to complement what we it into the mail threa= d...
>>
>> Sorry to be brief at this stage - just tying u= p some loose ends before an absence from the office.
>>
>>= ; R
>>
>> Robin Wilton
>>
>> Technical = Outreach Director - Identity and Privacy
>>
>> On 12 Jan = 2015, at 21:45, "Jim Fenton" <fenton@bluepopcorn.net> wrote:
>&g= t;
>> Maybe I should be breaking these apart as Robin suggests, bu= t for now I'll keep this in one reply:
>>
>> On 1/12/= 15 6:06 AM, Robin Wilton wrote:
>> This thread raises several impo= rtant topics=E2=80=A6 just as a practical matter, it might be worth trying = to spin some of them off separately, so that we address them all, and minim= ise the risk of talking at cross-purposes.
>> It feels like it wou= ld be worth trying to put together some *very short* straw-man docs/pages/p= aragraphs to try and get a consensus version on specific points, so that we= avoid re-hashing the same arguments/discussions over time, or at least hav= e something we can refer to - and amend if necessary. I think this is aimin= g at the same end-point as Steve=E2=80=99s request for a statement of requi= rements, but will ensure we=E2=80=99re expressing our requirements in a con= sistent set of terms.
>>
>>
>> By the looks of i= t, these would make for a good starting point (I think the answers to most = of these are implicit in various people=E2=80=99s contributions to the thre= ad=E2=80=A6 but that doesn=E2=80=99t mean everyone agrees ;^)=C2=A0 ):
&= gt;>
>>
>> 1 - what do we mean by authentication and a= uthorisation? Are there other decisions (e.g. access control, entitlement) = which need to be called out explicitly? This reflects the purpose of Justin= =E2=80=99s questions. Classically, the reason for authenticating a user is = to answer a yes/no question (is this the person to whom this credential was= originally issued); if yes, what do I want to do about it (at which point = the further entitlements are usually determined by retrieving a user profil= e, ACL or whatever)?
>>
>> Access control and entitlement= as distinct from authorisation? Is there a distinction, or are people just= using different terminology?
>>
>> I think of authentica= tion as providing more than a yes/no answer: it provides an identifier. If = the relying party has enough information (perhaps on the basis of previous = interactions) to authorize something with just that, fine. Otherwise some a= ttributes are needed to make an authorisation decision.
>>
>= >
>> However, as we know, these days access control and entitle= ment decisions also need to be made on the basis of input other than classi= c credentials, and that=E2=80=99s one of the two cores of this discussion, = I believe.
>>
>> Example of an "input other than cla= ssic credentials"?
>>
>>
>>
>>
= >> 2 - what=E2=80=99s the classic lifecycle of a credential - i.e. a = artefact intended to provide evidence in support of an assertion of identit= y. (e.g. registration/verification/enrolment, credential issue, credential = presentation/authentication, credential amendment/revocation/destruction=E2= =80=A6)?
>>
>>
>> Credential is another of those= tricky words. Sometimes it means the same as an authentication token. Some= times it has some attributes bound to it, which means it has both an authen= tication and attribute provision flavor to it. I find it simpler to talk ab= out tokens, where one doesn't have to deal with revocation when some at= tribute (employment, for example) changes.
>>
>>
>&= gt;
>> 3 - How does (2) relate to other assertions (e.g. attribute= assertions) we would like to make reliably?
>>
>>
>= ;> With that starter set, I think we can confirm the subset of requireme= nts that 800-63-1 still meets, and define the delta that requires new desig= n.
>>
>> 4 - What=E2=80=99s the right way to update curre= nt thinking on LOAs, to account for the change Jim describes in his proposa= l - i.e., the case where "credentials (used in authentication) and att= ribute information (established through identity proofing) could be provide= d by different parties.=E2=80=9D
>>
>> 5 - From Jim=E2=80= =99s proposal: =E2=80=9CAttribute reliability refers to the quality of the = identity proofing process, as well as the strength of the binding of the id= entifying attributes to the authentication.=E2=80=9D Do we need/want to exp= and on this a little? This seems to cater well for the case where, say, veh= icle entitlements are being established so that they can be encapsulated in= a driving licence. It=E2=80=99s not so clear how this addresses, say, thir= d party assertions that do not arise from an identity proofing process - = =E2=80=9CI have no idea *who* this user is, but I can reliably assert the f= ollowing about them: ... =E2=80=9D.
>>
>> You're righ= t; that will need to be defined. But it should be possible to define analog= ous requirements to describe the strength of the binding to the token. When= you show up to enroll at school, it should be possible to use your token t= o allow your school to make LOR 3 asserts that you're there student. Bu= t maybe remote students only get LOR 2?
>>
>> -Jim
>= ;>
> vot mailing list
> vot@ietf.org
> https://www.ietf.org/mailman/listinfo/v= ot


_______________________________________________
vot ma= iling list
vot@ietf.or= g
https://www.ietf.org/mailman/listinfo/vot

=

=C2=A0


--089e0102dc32d7aa5d050cb70ecd-- From nobody Fri Jan 16 10:00:35 2015 Return-Path: X-Original-To: vot@ietfa.amsl.com Delivered-To: vot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A9C81ACE72 for ; Fri, 16 Jan 2015 10:00:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.511 X-Spam-Level: X-Spam-Status: No, score=-1.511 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 ForvRoi-3c_e for ; Fri, 16 Jan 2015 10:00:27 -0800 (PST) Received: from mailgate-02.ucop.edu (imail-03.ucop.edu [128.48.123.91]) by ietfa.amsl.com (Postfix) with ESMTP id EBCC51AD248 for ; Fri, 16 Jan 2015 10:00:26 -0800 (PST) X-WSS-ID: 0NIA7CL-06-HYZ-02 X-M-MSG: X-TMWD-Spam-Summary: TS=20150116180021; ID=1; SEV=2.4.5; DFV=B2014050338; IFV=NA; AIF=B2014050338; RPD=NA; ENG=NA; RPDID=NA; CAT=NONE; CON=NONE; SIG=AAAAAAAAAAAAAAAAgDB7CAAAfQ== Received: from p-its-excas04.AD.UCOP.EDU (netscaler-01-vl-123.ucop.edu [128.48.123.8]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailgate-02.ucop.edu (Axway MailGate 5.3.0) with ESMTPS id 293DE421E51 for ; Fri, 16 Jan 2015 10:00:20 -0800 (PST) Received: from P-IRC-EXMBX03.AD.UCOP.EDU ([169.254.2.199]) by p-its-excas04.AD.UCOP.EDU ([::1]) with mapi id 14.03.0210.002; Fri, 16 Jan 2015 10:00:21 -0800 From: Eric Goodman To: "vot@ietf.org" Thread-Topic: [VoT] A modest proposal to replace LOA Thread-Index: AQHQLE3NlhDiU8tHYE6GLcs1RZzpnJy8SyOAgAE9kwCABYl0sA== Date: Fri, 16 Jan 2015 18:00:20 +0000 Message-ID: References: <54B03EE4.3060909@bluepopcorn.net> <38AAF00EA635514CA6667ACA60C7F0A53153A573@UTHMAIL1.uthouston.edu> <54B43AA4.3030005@bluepopcorn.net> In-Reply-To: <54B43AA4.3030005@bluepopcorn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.48.122.8] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [VoT] A modest proposal to replace LOA X-BeenThere: vot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Vectors of Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2015 18:00:34 -0000 >>I believe that relying parties must trust 'attribute providers' >> as opposed to trusting specific attribute assertions. It is my=20 >> opinion that relying parties should only request attributes from=20 >> providers they consider to be (or accept as) authoritative for the=20 >> attributes requested. So in my view attributes have little to do with L= OA discussion. >But there may be circumstances where attribute providers have different=20 >levels of confidence (do differing levels of diligence) on attributes and= =20 >therefore may need to assert something at a lower level of trust than=20 >they hold. There may also be business drivers, such as attribute providers= =20 >charging more for higher-confidence assertions. Asserting Silver or NIST LOA 2 *is* an "attribute assertion", even though i= t's applied globally to the attributes in that assertion (and not per-attri= bute). Whether you codify this with NIST-style LoA profiles or via "attribu= te-specific vector" measures doesn't change the fact that you are making pe= r-user attribute assertions. --- Eric From nobody Fri Jan 16 12:32:07 2015 Return-Path: X-Original-To: vot@ietfa.amsl.com Delivered-To: vot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C93531B2B80 for ; Fri, 16 Jan 2015 12:32:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 7fAj6xSfSUVf for ; Fri, 16 Jan 2015 12:32:04 -0800 (PST) Received: from mta5.uth.tmc.edu (mta5.uth.tmc.edu [129.106.149.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10A701B2B82 for ; Fri, 16 Jan 2015 12:32:03 -0800 (PST) Received: from pps.filterd (mta5.uth.tmc.edu [127.0.0.1]) by mta5.uth.tmc.edu (8.14.5/8.14.5) with SMTP id t0GKMl1O027095; Fri, 16 Jan 2015 14:32:02 -0600 Received: from uthmail2.uthouston.edu ([129.106.175.239]) by mta5.uth.tmc.edu with ESMTP id 1ry6w0rwe8-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 16 Jan 2015 14:32:02 -0600 Received: from UTHMAIL1.uthouston.edu ([fe80::c1d2:3f6a:4f56:4fa4]) by UTHMAIL2.uthouston.edu ([fe80::78fb:d7a3:fc1f:7b1e%21]) with mapi id 14.03.0210.002; Fri, 16 Jan 2015 14:32:01 -0600 From: "Jones, Mark B" To: Eric Goodman , "vot@ietf.org" Thread-Topic: [VoT] A modest proposal to replace LOA Thread-Index: AQHQLE3NIVccl7Oe9EyjUXstdR0255y7QHEAgAImvgCABhFfAP//wMgA Date: Fri, 16 Jan 2015 20:32:01 +0000 Message-ID: <38AAF00EA635514CA6667ACA60C7F0A531547B9C@UTHMAIL1.uthouston.edu> References: <54B03EE4.3060909@bluepopcorn.net> <38AAF00EA635514CA6667ACA60C7F0A53153A573@UTHMAIL1.uthouston.edu> <54B43AA4.3030005@bluepopcorn.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [129.106.8.25] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_01A5_01D03199.300CFFE0" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2015-01-16_07:2015-01-16,2015-01-16,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1501160195 Archived-At: Subject: Re: [VoT] A modest proposal to replace LOA X-BeenThere: vot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Vectors of Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2015 20:32:06 -0000 ------=_NextPart_000_01A5_01D03199.300CFFE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > -----Original Message----- > From: vot [mailto:vot-bounces@ietf.org] On Behalf Of Eric Goodman > Sent: Friday, January 16, 2015 12:00 PM > To: vot@ietf.org > Subject: Re: [VoT] A modest proposal to replace LOA > > >>I believe that relying parties must trust 'attribute providers' > >> as opposed to trusting specific attribute assertions. It is my > >>opinion that relying parties should only request attributes from > >>providers they consider to be (or accept as) authoritative for the > >>attributes requested. So in my view attributes have little to do with LOA > discussion. > > >But there may be circumstances where attribute providers have different > >levels of confidence (do differing levels of diligence) on attributes > >and therefore may need to assert something at a lower level of trust > >than they hold. There may also be business drivers, such as attribute > >providers charging more for higher-confidence assertions. > > Asserting Silver or NIST LOA 2 *is* an "attribute assertion", even though it's > applied globally to the attributes in that assertion (and not per-attribute). > Whether you codify this with NIST-style LoA profiles or via "attribute-specific > vector" measures doesn't change the fact that you are making per-user > attribute assertions. > > --- Eric [Jones, Mark B] Eric, 800-63 is very clear in stating that its scope only applies to authentication. Your statement above is a perfect example of why levels of assurance should only apply to the authentication and not the attributes. It is circular logic to say: I told you to trust me, so now you trust me. How can the assertion of an attribute establish trust in itself? If you are trusting the attribute provider when it self asserts LOA haven't you simply decided to trust any attribute it provides? Isn't it reasonable to assume that an attribute provider that you trust will supply any attribute assertion in good faith? Under what circumstances would you not trust a provider that you have requested attributes from, and if such a circumstance exists why are you requesting anything from them? Note that I'm not expecting trusted attribute providers to be perfect, but it is my opinion that you should expect providers to assert the best information they have or nothing. The purpose of LOA is not to tell you how much to trust the attribute provider, it is to tell you how much to trust the user at the other end of the transaction (in my opinion). ------=_NextPart_000_01A5_01D03199.300CFFE0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITvjCCBDYw ggMeoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRy dXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZ QWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wMDA1MzAxMDQ4MzhaFw0yMDA1MzAxMDQ4Mzha MG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3Qg RXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3Qw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC39xoz5vIABC054E5b7R+8bA/Ntfojts7e mxEzl6QpTH2Tn71KvJPtAxrjj8/lbVBa1pcplFqAsEl62y6V/bjKvzc4LR4+kUGtcFbH8E8/6DKe dMrIkFTpxl8PeJ2aQDwOrGGqXhSPnoehalDc15pOrwWzpnGUnHGzUGAKxxOdOAeGAqjpqGkmGJCr TLBPI6s6T4TY386f4Wlvu9dC12tE5Met7m1BX3JacQg3s3llpFmglDf3AC8NwpJy2tA4ctsUqEXE XSp9t7TWxO6szRNEt8kr3UMAJfphuWlqWCMRt6czj1Z1WfXNKddGtworZbbTQm8Vsrh7++/pXVPV NFonAgMBAAGjgdwwgdkwHQYDVR0OBBYEFK29mHo0tCb3+sQmVO8DveAky1QaMAsGA1UdDwQEAwIB BjAPBgNVHRMBAf8EBTADAQH/MIGZBgNVHSMEgZEwgY6AFK29mHo0tCb3+sQmVO8DveAky1QaoXOk cTBvMQswCQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0 IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 ggEBMA0GCSqGSIb3DQEBBQUAA4IBAQCwm+CFJcLWI+IPlgaSnUGYnNmEeYHZHlsUByM2ZY+w2He7 rEFsR2CDUbD5Mj3n/PYmE8eAFqW/WvyHz3h5iSGa4kwHCoY1vPLeUcTSlrfcfk7ucP0cOesMAlEU LY69FuDB30Z15ySt7PRCtIWTcBBnup0GNUoY0yt6zFFCoXpj0ea7ocUrwja+Ew3mvWN+eXunCQ1A q2rdj4rD9vaMGkIFUdRF9Z+nYiFoFSBDPJnnfL0k2KmRF3OIP1YbMTgYtHEPms3IDp6OLhvhjJiD yx8x8URMxgRzSXZgD8f4vReAay7pzEwOWpp5DyAKLtWeYyYeVZKU2IIXWnvQvMePToYEMIIEnTCC A4WgAwIBAgIQND3pK6wnNP+PyzSU+8xwVDANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEU MBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3 b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTA1MDYwNzA4MDkxMFoX DTIwMDUzMDEwNDgzOFowga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2Fs dCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0 cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRo ZW50aWNhdGlvbiBhbmQgRW1haWwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCyOYWk 8n2rQTtiRjeuzcFgdbw5ZflKGkeiucxIzGqY1U01GbmkQuXOSeKKLx580jEHx060g2SdLinVomTE hb2FUTV5pE5okHsceqSSqBfymBXyk8zJpDKVuwxPML2YoAuL5W4bokb6eLyib6tZXqUvz8rabaov 66yhs2qqty5nNYt54R5piOLmRs2gpeq+C852OnoOm+r82idbPXMfIuZIYcZM82mxqC4bttQxICy8 goqOpA6l14lD/BZarx1x1xFZ2rqHDa/68+HC8KTFZ4zW1lQ63gqkugN3s2XI/R7TdGKqGMpokx6h hX71R2XL+E1XKHTSNP8wtu72YjAUjCzrAgMBAAGjgfQwgfEwHwYDVR0jBBgwFoAUrb2YejS0Jvf6 xCZU7wO94CTLVBowHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59MA4GA1UdDwEB/wQEAwIB BjAPBgNVHRMBAf8EBTADAQH/MBEGA1UdIAQKMAgwBgYEVR0gADBEBgNVHR8EPTA7MDmgN6A1hjNo dHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vQWRkVHJ1c3RFeHRlcm5hbENBUm9vdC5jcmwwNQYIKwYB BQUHAQEEKTAnMCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3 DQEBBQUAA4IBAQABvJzjYyiw8zEBwt973WKgAZ0jMQ+cknNTUeofTPrWn8TKL2d+eDMPdBa5kYeR 9Yom+mRwANge+QsEYlCHk4HU2vUj2zS7hVa0cDRueIM3HoUcxREVkl+HF72sav3xwtHMiV+xfPA+ UfI183zsYJhrOivg79+zfYbrtRv1W+yifJgT1wBQudEtc94DeHThBYUxXsuauZ2UxrmUN3Vy3ET7 Z+jw+iUeUqfaJelH4KDHPKBOsQo2+3dIn++Xivu0/uOUFKiDvFwtP9JgcWDuwnGCDOmINuPaILSj oGyqlku4gI51ykkH9jsUut/cBdmf2+Cy5k2geCbn5y1uf1/GHogVMIIFJTCCBA2gAwIBAgIQRIUc GfetDxT4xHWGNMR0xzANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVU MRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3Jr MSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmly c3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0xMDEyMDIwMDAwMDBaFw0yMDA1 MzAxMDQ4MzhaMIGWMQswCQYDVQQGEwJVUzFBMD8GA1UEChM4VGhlIFVuaXZlcnNpdHkgb2YgVGV4 YXMgSGVhbHRoIFNjaWVuY2UgQ2VudGVyIGF0IEhvdXN0b24xRDBCBgNVBAMTO1RoZSBVbml2ZXJz aXR5IG9mIFRleGFzIEhlYWx0aCBTY2llbmNlIENlbnRlciBhdCBIb3VzdG9uIENBMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxElj8A/NxSnbcaHKOvWlDt5+EbJMPZFayMmRcR5BbEqw M9PLQPTH1yJIZp+7Afgi6CZ/GrJcOEIRsfP43H3VK5O5FI6zIT6ZEEjj+huZ0hWey6Cg/ZNU22Mr XXCGEc0W4afqSXNX2mkck2oQW3xrDTaifCWBFQDki+k5d8wKQ2buk/aIFJO0qomzxq1cdJqAS/sF PWR3aRdJrn5IsjZeDsnsWZFpKCRiAybgcogM0f2mWDLATusRoL41DiOlJfH22NObHcFTQmsoAnXj X+FwJwdZ5H+kiiUCH9tXOHdPyKOoQoBqg+mdkCb4wviJsVTrq4lffBGe+xyeK2dlYngQSQIDAQAB o4IBUzCCAU8wHwYDVR0jBBgwFoAUiYJnfcSdJnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFJkX0AQh Sm6R8Ydeb3ZvO93EMh4gMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEAMBkGA1Ud IAQSMBAwDgYMKwYBBAGyMQECAiQFMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRy dXN0LmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQG CCsGAQUFBwEBBGgwZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFk ZFRydXN0Q2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNv bTANBgkqhkiG9w0BAQUFAAOCAQEAKqKCLV43+zEwBp/AHeelxnJikiO6zfHH7lNSvtwBPyGm4ZuI v6WHl669XQpMLcUxy8b0B8gHZ00AA+mZ7r2YP7HrUiuTEWssdA859PYHeIulfBfLhSP28On7C1Mx aODD9UQtj1j3NUGCy2kCGB2xupUjEXtNWSTgEGWhMiv5V+EvjLEns59Rpm5BHWgsycFOSyztjJYQ kRIFx3Yi6IX5b7s+lxMt96yVwaatlI+xMWPJpxeWlBzq/nIhPfREJmKf0RzZh58Gi6TnIPjmSsIV BZJhUxdTIJkfaJkajOy539WRMM9k04gBH4ZIFd2VwqwB9aZl27LgfvYOeeoswzPpRzCCBbYwggSe oAMCAQICEQC2CAUBCn9+NClEHZu5j+aOMA0GCSqGSIb3DQEBBQUAMIGWMQswCQYDVQQGEwJVUzFB MD8GA1UEChM4VGhlIFVuaXZlcnNpdHkgb2YgVGV4YXMgSGVhbHRoIFNjaWVuY2UgQ2VudGVyIGF0 IEhvdXN0b24xRDBCBgNVBAMTO1RoZSBVbml2ZXJzaXR5IG9mIFRleGFzIEhlYWx0aCBTY2llbmNl IENlbnRlciBhdCBIb3VzdG9uIENBMB4XDTE0MDkxNTAwMDAwMFoXDTE1MDkxNTIzNTk1OVowgbMx DjAMBgNVBBETBTc3MDMwMRwwGgYDVQQKExNVVEhFQUxUSCBOT04tRVNDUk9XMRQwEgYDVQQJEws3 MDAwIEZhbm5pbjEOMAwGA1UECBMFVGV4YXMxEDAOBgNVBAcTB0hvdXN0b24xCzAJBgNVBAYTAlVT MRUwEwYDVQQDEwxNYXJrIEIgSm9uZXMxJzAlBgkqhkiG9w0BCQEWGG1hcmsuYi5qb25lc0B1dGgu dG1jLmVkdTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAIsD9b8/H96eboYROkoZaA2/ QEXxNACieGhSr+CQzUfSlhWcL4M69uA938pqeKvzGWWJBEkb46tzTMhnbWuvbNfqUT+PBShIvkSr ndy7BE0ozkKjFVU/6jTsj2klnDyfq3wn0+GA/e+FTzYaDdj7ts6fij74De2GDPdNlVJa6uzzMaTd 7cS3T87ht0Yr03NStJRAl+IdN4cpJ9+Xn14NG7PnlZy5fyXDWM88kd/guUpdfK6XIjEud01vjDco NpN3ihRXl8LnEP700dosa2r897emtg8XJaSnw4k/GJUfSuGgW2rbYpUOyR9JPzZQMlLPqptNRjF5 WAzp2neDcl2fb0kCAwEAAaOCAd4wggHaMB8GA1UdIwQYMBaAFJkX0AQhSm6R8Ydeb3ZvO93EMh4g MB0GA1UdDgQWBBTk8/IYWxQfOajleb+QbNEs5R1HCzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/ BAIwADAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwQwYDVR0gBDwwOjA4BgwrBgEEAbIx AQICJAUwKDAmBggrBgEFBQcCARYaaHR0cDovL3d3dy51dGgudG1jLmVkdS9jcHMwXgYDVR0fBFcw VTBToFGgT4ZNaHR0cDovL2NybC51dGgudG1jLmVkdS9UaGVVbml2ZXJzaXR5b2ZUZXhhc0hlYWx0 aFNjaWVuY2VDZW50ZXJhdEhvdXN0b25DQS5jcmwwgZAGCCsGAQUFBwEBBIGDMIGAMFkGCCsGAQUF BzAChk1odHRwOi8vY3J0LnV0aC50bWMuZWR1L1RoZVVuaXZlcnNpdHlvZlRleGFzSGVhbHRoU2Np ZW5jZUNlbnRlcmF0SG91c3RvbkNBLmNydDAjBggrBgEFBQcwAYYXaHR0cDovL29jc3AudXRoLnRt Yy5lZHUwIwYDVR0RBBwwGoEYbWFyay5iLmpvbmVzQHV0aC50bWMuZWR1MA0GCSqGSIb3DQEBBQUA A4IBAQCB5ypKawPDBa1lkt5Kv3priYCzwt5kUJA9MaQArIbAnpH2OoPnaUcnaGFNhgbm7TMJmC4V spP7uBsrtUGzywRe7AXwrRLX5WKxT4KKDdIonoftE0zVJGCP8SelTnlCOYk1/aa7blWsLtEan/AG sgJwFo8IjrWI95DqimKhH7qOU5KIbPovEksE6NFE0EcHdBLDEWmH1iCaZvl2qNJyrERtVYxG7wTA UTlMG6Tr2tkm1f6NJizvUSCaxCVVpZ4QSHYb6edNYI25w/D2yoDeGCvyq9lyRA/h5QooHdxu+8tG JZpxA9fSKDewjKNIJoirGOhrLM9t8/NxXw40sd7vZdTZMYIEFDCCBBACAQEwgawwgZYxCzAJBgNV BAYTAlVTMUEwPwYDVQQKEzhUaGUgVW5pdmVyc2l0eSBvZiBUZXhhcyBIZWFsdGggU2NpZW5jZSBD ZW50ZXIgYXQgSG91c3RvbjFEMEIGA1UEAxM7VGhlIFVuaXZlcnNpdHkgb2YgVGV4YXMgSGVhbHRo IFNjaWVuY2UgQ2VudGVyIGF0IEhvdXN0b24gQ0ECEQC2CAUBCn9+NClEHZu5j+aOMAkGBSsOAwIa BQCgggI8MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDExNjIw MzE1OVowIwYJKoZIhvcNAQkEMRYEFJvg7RgSwsIYtV0wJCcJEUlaNN3kMFsGCSqGSIb3DQEJDzFO MEwwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G CCqGSIb3DQMCAgEoMAcGBSsOAwIaMIG9BgkrBgEEAYI3EAQxga8wgawwgZYxCzAJBgNVBAYTAlVT MUEwPwYDVQQKEzhUaGUgVW5pdmVyc2l0eSBvZiBUZXhhcyBIZWFsdGggU2NpZW5jZSBDZW50ZXIg YXQgSG91c3RvbjFEMEIGA1UEAxM7VGhlIFVuaXZlcnNpdHkgb2YgVGV4YXMgSGVhbHRoIFNjaWVu Y2UgQ2VudGVyIGF0IEhvdXN0b24gQ0ECEQC2CAUBCn9+NClEHZu5j+aOMIG/BgsqhkiG9w0BCRAC CzGBr6CBrDCBljELMAkGA1UEBhMCVVMxQTA/BgNVBAoTOFRoZSBVbml2ZXJzaXR5IG9mIFRleGFz IEhlYWx0aCBTY2llbmNlIENlbnRlciBhdCBIb3VzdG9uMUQwQgYDVQQDEztUaGUgVW5pdmVyc2l0 eSBvZiBUZXhhcyBIZWFsdGggU2NpZW5jZSBDZW50ZXIgYXQgSG91c3RvbiBDQQIRALYIBQEKf340 KUQdm7mP5o4wDQYJKoZIhvcNAQEBBQAEggEAJuV2hUoB+DgufkAz7iaMy1tJqxBxW8+kInkF5CcL EMAepxYHIzXfPsphYIL2sOa7rJjw0wCotTrzFVyY4gQEc0QUsxkfzUk4qavV01J1pVGWsjh8pYTD xqcUZiBD3XYMkaJX4H9cL/2qvWRxUB7tck3gQ2edSflPZuVtfckGgoIyXImigJCU0wphZh/wVulB yl+TGIVYEp4XEDX5dk4ldkB7igazYkwXSgHTp+tTT6oqohEkL5jXS4MCUrUm+FAV28//TlD8B46v dT8HKaRaUNqKhveiFwPsxBtCT2i6gmRwx+6ZPnwQQjBIPQCNvd01Cz0tAjTqombczGH7somZxAAA AAAAAA== ------=_NextPart_000_01A5_01D03199.300CFFE0-- From nobody Fri Jan 16 12:48:00 2015 Return-Path: X-Original-To: vot@ietfa.amsl.com Delivered-To: vot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EC661B2C02 for ; Fri, 16 Jan 2015 12:47:50 -0800 (PST) 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, 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 mH6TVO4bckC7 for ; Fri, 16 Jan 2015 12:47:47 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0762.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::762]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84FE31B2BFE for ; Fri, 16 Jan 2015 12:47:32 -0800 (PST) Received: from BL2FFO11FD046.protection.gbl (10.173.160.32) by BL2FFO11HUB006.protection.gbl (10.173.160.226) with Microsoft SMTP Server (TLS) id 15.1.59.14; Fri, 16 Jan 2015 20:47:09 +0000 Received: from cio-tnc-pf06.osuad.osu.edu (164.107.81.220) by BL2FFO11FD046.mail.protection.outlook.com (10.173.161.208) with Microsoft SMTP Server (TLS) id 15.1.49.13 via Frontend Transport; Fri, 16 Jan 2015 20:47:09 +0000 Received: from CIO-TNC-HT08.osuad.osu.edu (cio-tnc-ht08.osuad.osu.edu [164.107.81.177]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by cio-tnc-pf06.osuad.osu.edu (Postfix) with ESMTPS id 1FF3A3C0036; Fri, 16 Jan 2015 15:47:06 -0500 (EST) 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.0174.001; Fri, 16 Jan 2015 15:47:08 -0500 From: "Cantor, Scott" To: "Jones, Mark B" , Eric Goodman , "vot@ietf.org" Thread-Topic: [VoT] A modest proposal to replace LOA Thread-Index: AQHQLE3ctuj9rJBN0EyoeCVXVMLiBZy8GNiAgAE9lACABhFfAIAAKmGA//+t0HA= Date: Fri, 16 Jan 2015 20:47:07 +0000 Message-ID: <9846A6064BD102419D06814DD0D78DE1068C80@CIO-TNC-D2MBX02.osuad.osu.edu> References: <54B03EE4.3060909@bluepopcorn.net> <38AAF00EA635514CA6667ACA60C7F0A53153A573@UTHMAIL1.uthouston.edu> <54B43AA4.3030005@bluepopcorn.net> <38AAF00EA635514CA6667ACA60C7F0A531547B9C@UTHMAIL1.uthouston.edu> In-Reply-To: <38AAF00EA635514CA6667ACA60C7F0A531547B9C@UTHMAIL1.uthouston.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.146.94.22] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 Received-SPF: Pass (protection.outlook.com: domain of osu.edu designates 164.107.81.220 as permitted sender) receiver=protection.outlook.com; client-ip=164.107.81.220; helo=cio-tnc-pf06.osuad.osu.edu; Authentication-Results: spf=pass (sender IP is 164.107.81.220) smtp.mailfrom=cantor.2@osu.edu; X-Forefront-Antispam-Report: CIP:164.107.81.220; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(438002)(199003)(189002)(106116001)(106466001)(93886004)(54356999)(93346002)(76176999)(46102003)(2656002)(87936001)(23726002)(90282001)(6806004)(2501002)(107886001)(97756001)(109096001)(86362001)(55846006)(551934003)(102836002)(50466002)(88552001)(2920100001)(2950100001)(2171001)(46406003)(2900100001)(66066001)(50986999)(89122001)(92566002)(64706001)(75432002)(33656002)(62966003)(77156002)(47776003); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2FFO11HUB006; H:cio-tnc-pf06.osuad.osu.edu; FPR:; SPF:Pass; MLV:sfv; PTR:cio-tnc-pf06.osuad.osu.edu; A:1; MX:1; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BL2FFO11HUB006; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:BL2FFO11HUB006; X-Forefront-PRVS: 04583CED1A X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:BL2FFO11HUB006; X-OriginatorOrg: osu.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Jan 2015 20:47:09.5661 (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.220] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2FFO11HUB006 Archived-At: Subject: Re: [VoT] A modest proposal to replace LOA X-BeenThere: vot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Vectors of Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2015 20:47:50 -0000 > Eric, > 800-63 is very clear in stating that its scope only applies to > authentication.=20 Which is why it's nonsensical to start with, because there is no way to com= municate an "identity" without an attribute digitally. It's defining its ow= n scope as zero. > Your statement above is a perfect example of why levels of > assurance should only apply to the authentication and not the attributes. The other way around, in my personal opinion. Authentication means nothing = to an app. The "truth" and risk in accepting the data being consumed is wha= t matters to any RP. > Under what circumstances would you not trust a provider that you have > requested attributes from, and if such a circumstance exists why are you > requesting anything from them? Replace attributes with authentication in that sentence and it's the same q= uestion. The answer of course is that not all authentication is equal, just= as not all assertions of data are equal in their confidence level. Why is = authentication a transactional consideration but attributes are exactly con= sistent across the provider? Both are transactional considerations. > The purpose of LOA is not to tell you how much to trust the attribute > provider, it is to tell you how much to trust the user at the other end o= f > the transaction (in my opinion). Disagree strenuously. LOA is about the trust placed in an assertion of data= by somebody in terms of risk mitigation. It's all data and all attributes.= Identity is irelevant except as a consequence of how particular data might= be applied and used. -- Scott From nobody Fri Jan 16 23:10:19 2015 Return-Path: X-Original-To: vot@ietfa.amsl.com Delivered-To: vot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E98C1A9245 for ; Fri, 16 Jan 2015 23:10:17 -0800 (PST) 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 ksLquwIBpfzl for ; Fri, 16 Jan 2015 23:10:14 -0800 (PST) Received: from smtpvbsrv1.mitre.org (smtpvbsrv1.mitre.org [198.49.146.234]) by ietfa.amsl.com (Postfix) with ESMTP id BACC41A9231 for ; Fri, 16 Jan 2015 23:10:14 -0800 (PST) Received: from smtpvbsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id C7A8AB2E1E3; Sat, 17 Jan 2015 02:10:13 -0500 (EST) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpvbsrv1.mitre.org (Postfix) with ESMTP id BC757B2E1C7; Sat, 17 Jan 2015 02:10:13 -0500 (EST) Received: from IMCMBX01.MITRE.ORG ([169.254.1.185]) by IMCCAS02.MITRE.ORG ([129.83.29.69]) with mapi id 14.03.0224.002; Sat, 17 Jan 2015 02:10:13 -0500 From: "Natale, Bob" To: "Jones, Mark B" Thread-Topic: [VoT] A modest proposal to replace LOA Thread-Index: AQHQLE3MiYAfUf9fFUazHPm0Q2t3zZy8GNiAgAfWQIA= Date: Sat, 17 Jan 2015 07:10:12 +0000 Message-ID: References: <54B03EE4.3060909@bluepopcorn.net> <38AAF00EA635514CA6667ACA60C7F0A53153A573@UTHMAIL1.uthouston.edu> In-Reply-To: <38AAF00EA635514CA6667ACA60C7F0A53153A573@UTHMAIL1.uthouston.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.140.19.249] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Jim Fenton , "vot@ietf.org" Subject: Re: [VoT] A modest proposal to replace LOA X-BeenThere: vot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Vectors of Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jan 2015 07:10:17 -0000 Hi Mark, I realize that this is a relatively small point in the context of the threa= d at this stage, but I believe that your comment below that "authentication= establishes trust in the PERSON on the other end of a transaction" needs t= o be expanded to read "authentication establishes trust [i.e., level of con= fidence] in the ENTITY on the other end of a transaction" since we have to = account for non-person entities as well as human users and authentication i= s only one link in the chain of establishing trust in the entity for a part= icular transaction in a particular context. Avanti, BobN -----Original Message----- From: vot [mailto:vot-bounces@ietf.org] On Behalf Of Jones, Mark B Sent: Sunday, January 11, 2015 9:24 PM To: Jim Fenton; vot@ietf.org Subject: Re: [VoT] A modest proposal to replace LOA It is my opinion that the levels of assurance in 800-63 are meant to descri= be specific sets of threats that should be addressed at specific, common ri= sk levels and to describe how to mitigate those threats. It is not clear w= hat specific threats your proposed levels are meant to address. (I think t= he VoT discussion in general is also lacking in references to what specific= threats are meant to be addressed by specific vectors.) Though 800-63 has language that talks about including verified attributes i= n credentials and assertions it makes it clear that inclusion of attributes= is optional. I feel that 800-63 works just fine in a model where authenti= cation and attribute providers are separate because it does not specify any= limits on how attributes can be communicated. It is my opinion that 'auth= entication' and the communication of attributes must be conceptualized as v= ery separate processes and that your concept of "Attribute Reliability" ina= ppropriately conflates 'Registration and Credential Issuance' with attribut= e assertions. The threats associated with inappropriate registration and c= redential issuance are very different from those associated with receiving = inaccurate attribute assertions. Though some have reasonable arguments for assigning levels of assurance to = attributes, I believe that relying parties must trust 'attribute providers' as opposed to trusting specific attribute assertions. It is my opinion tha= t relying parties should only request attributes from providers they consid= er to be (or accept as) authoritative for the attributes requested. So in = my view attributes have little to do with LOA discussion. In summary I feel that any scheme for expressing LOA needs to describe the = threats that are mitigated, the strength of those mitigations, and trust of= authentication should be kept separate from trust of attribute assertions. After all, authentication establishes trust in the PERSON on the other end = of a transaction while trust in an attribute assertion represents trust in = the PROVIDER to collect and assert good attributes. =20 > -----Original Message----- > From: vot [mailto:vot-bounces@ietf.org] On Behalf Of Jim Fenton > Sent: Friday, January 09, 2015 2:50 PM > To: vot@ietf.org > Subject: [VoT] A modest proposal to replace LOA >=20 > I posted some ideas yesterday on a somewhat constrained possible=20 > replacement for Levels of Assurance: >=20 > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__altmode.wordpress.com_2015_01_08_level-2Dof-2Dassurance- > 2Dalternatives-2Da-2Dmodest- > 2Dproposal_&d=3DAwICAg&c=3D6vgNTiRn9_pqCD9hKx9JgXN1VapJQ8JVoF8oWH > 1AgfQ&r=3DjgMu8DNgV_dycz0rYwkNbEQq36F0BI5_Zpblz7C5LhM&m=3D2E_n- > hMMZrra2XwK7mj_KrpU8b-c3PcCa45FsWVh0bE&s=3DAf4ObdyoFr4e6yoEMT- > aIfNHcCZsmGzZZMyr1LnD5Oo&e=3D >=20 > tl;dr: One dimension (LOA) isn't enough, but we don't want too many=20 > dimensions or levels because that gets unwieldy. I'm proposing 3=20 > levels each > of two dimensions: Level of Strength (authentication) and Level of Reliability > (attribute binding/proofing). >=20 > Any thoughts would be appreciated. >=20 > -Jim >=20 > _______________________________________________ > vot mailing list > vot@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__www.ietf.org_mailman_listinfo_vot&d=3DAwICAg&c=3D6vgNTiRn9_pqCD9h > Kx9JgXN1VapJQ8JVoF8oWH1AgfQ&r=3DjgMu8DNgV_dycz0rYwkNbEQq36F0BI5 > _Zpblz7C5LhM&m=3D2E_n-hMMZrra2XwK7mj_KrpU8b- > c3PcCa45FsWVh0bE&s=3DM7Gbma252T4WErXbcfD- > 69cOz3ZwOSUUCxEP2QIPklg&e=3D From nobody Sat Jan 17 17:28:54 2015 Return-Path: X-Original-To: vot@ietfa.amsl.com Delivered-To: vot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C76FC1ACE23 for ; Sat, 17 Jan 2015 17:28:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, 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 2Qws4asas_hj for ; Sat, 17 Jan 2015 17:28:49 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0095.outbound.protection.outlook.com [65.55.169.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAFED1A886C for ; Sat, 17 Jan 2015 17:28:48 -0800 (PST) Received: from CO2PR0601MB0983.namprd06.prod.outlook.com (25.160.7.28) by CO2PR0601MB0982.namprd06.prod.outlook.com (25.160.7.27) with Microsoft SMTP Server (TLS) id 15.1.59.20; Sun, 18 Jan 2015 01:28:45 +0000 Received: from CO2PR0601MB0983.namprd06.prod.outlook.com ([25.160.7.28]) by CO2PR0601MB0983.namprd06.prod.outlook.com ([25.160.7.28]) with mapi id 15.01.0059.007; Sun, 18 Jan 2015 01:28:45 +0000 From: Robin Wilton To: "vot@ietf.org" CC: "vot@ietf.org" Thread-Topic: discussion of 800-63, below Thread-Index: AQHQMr4ZNYwOcHsqmEenmXrnIerBvA== Date: Sun, 18 Jan 2015 01:28:45 +0000 Message-ID: <3FD42939-4BE0-4AB4-A170-8A8E359643EC@isoc.org> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [125.253.96.133] authentication-results: spf=none (sender IP is ) smtp.mailfrom=wilton@isoc.org; x-dmarcaction-test: None x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005004);SRVR:CO2PR0601MB0982; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:CO2PR0601MB0982; x-forefront-prvs: 046060344D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(189002)(199003)(377454003)(13464003)(24454002)(51704005)(27574002)(86362001)(68736005)(99286002)(66066001)(575784001)(64706001)(2900100001)(46102003)(2351001)(82746002)(15975445007)(2501002)(76176999)(2950100001)(110136001)(106116001)(33656002)(102836002)(106356001)(92566002)(2656002)(561944003)(40100003)(551934003)(87936001)(83716003)(19580405001)(19580395003)(62966003)(77156002)(50986999)(105586002)(54356999)(450100001)(122556002)(101416001)(36756003)(97736003)(104396002)(19627235001); DIR:OUT; SFP:1101; SCL:1; SRVR:CO2PR0601MB0982; H:CO2PR0601MB0983.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: isoc.org does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jan 2015 01:28:45.2819 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR0601MB0982 Archived-At: Subject: Re: [VoT] discussion of 800-63, below X-BeenThere: vot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Vectors of Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jan 2015 01:28:53 -0000 Folks,=20 Just a quick "weekend" thought... in the sense that I want to float somethi= ng for you to think about, rather than try to hammer home a specific opinio= n. 800-63 is good as far as it goes, but I think we'd all acknowledge that it = is an attempt to systematise a subset of trust factors relating to a specif= ic, relatively simple model of how credentials and authentication are meant= to work.=20 I think the value that VoT can bring is=20 (i) looking at how to systematise more trust factors, and/or more complex m= odels of how credentials and authentication are meant to work (and I think = much of the discussion below goes towards that); (ii) looking at emerging trust models (for instance, in Open Data contexts,= where data controllers just publish an API and say "have at it"...). I thi= nk emerging trust models challenge some of the fundamental assumptions in t= he current discussion. For instance: - there's an implication, below, that trust is binary. You either trust the= source of an attribute to be authoritative/accurate/reliable/timely or you= don't. But the more dynamic online relationships are, the more likely it i= s that their trust status might be partial (you trust them to a certain ext= ent) or indeterminate (you don't know whether this specific feed of data is= trustworthy or not, but if you compare it with others, you might form a vi= ew). There are examples of this in, for example, privacy-preserving monitor= ing of vehicle traffic flows. As I say, I'm not trying to lobby for a specific solution here, just trying= to see if there are areas where VoT can add value that is unlikely to come= from groups less intelligent and well-informed than this one. R=20 Robin Wilton Technical Outreach Director - Identity and Privacy On 18 Jan 2015, at 07:00, "vot-request@ietf.org" wro= te: > Send vot mailing list submissions to > vot@ietf.org >=20 > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/vot > or, via email, send a message with subject or body 'help' to > vot-request@ietf.org >=20 > You can reach the person managing the list at > vot-owner@ietf.org >=20 > When replying, please edit your Subject line so it is more specific > than "Re: Contents of vot digest..." > Today's Topics: >=20 > 1. Re: A modest proposal to replace LOA (Jones, Mark B) > 2. Re: A modest proposal to replace LOA (Cantor, Scott) > 3. Re: A modest proposal to replace LOA (Natale, Bob) >> -----Original Message----- >> From: vot [mailto:vot-bounces@ietf.org] On Behalf Of Eric Goodman >> Sent: Friday, January 16, 2015 12:00 PM >> To: vot@ietf.org >> Subject: Re: [VoT] A modest proposal to replace LOA >>=20 >>>> I believe that relying parties must trust 'attribute providers' >>>> as opposed to trusting specific attribute assertions. It is my >>>> opinion that relying parties should only request attributes from >>>> providers they consider to be (or accept as) authoritative for the >>>> attributes requested. So in my view attributes have little to do with > LOA >> discussion. >>=20 >>> But there may be circumstances where attribute providers have different >>> levels of confidence (do differing levels of diligence) on attributes >>> and therefore may need to assert something at a lower level of trust >>> than they hold. There may also be business drivers, such as attribute >>> providers charging more for higher-confidence assertions. >>=20 >> Asserting Silver or NIST LOA 2 *is* an "attribute assertion", even thoug= h > it's >> applied globally to the attributes in that assertion (and not > per-attribute). >> Whether you codify this with NIST-style LoA profiles or via > "attribute-specific >> vector" measures doesn't change the fact that you are making per-user >> attribute assertions. >>=20 >> --- Eric >=20 > [Jones, Mark B]=20 > Eric, > 800-63 is very clear in stating that its scope only applies to > authentication. Your statement above is a perfect example of why levels = of > assurance should only apply to the authentication and not the attributes. > It is circular logic to say: I told you to trust me, so now you trust me= . > How can the assertion of an attribute establish trust in itself? If you = are > trusting the attribute provider when it self asserts LOA haven't you simp= ly > decided to trust any attribute it provides? Isn't it reasonable to assum= e > that an attribute provider that you trust will supply any attribute > assertion in good faith? >=20 > Under what circumstances would you not trust a provider that you have > requested attributes from, and if such a circumstance exists why are you > requesting anything from them? Note that I'm not expecting trusted > attribute providers to be perfect, but it is my opinion that you should > expect providers to assert the best information they have or nothing. =20 >=20 > The purpose of LOA is not to tell you how much to trust the attribute > provider, it is to tell you how much to trust the user at the other end o= f > the transaction (in my opinion). >> Eric, >> 800-63 is very clear in stating that its scope only applies to >> authentication.=20 >=20 > Which is why it's nonsensical to start with, because there is no way to c= ommunicate an "identity" without an attribute digitally. It's defining its = own scope as zero. >=20 >> Your statement above is a perfect example of why levels of >> assurance should only apply to the authentication and not the attributes= . >=20 > The other way around, in my personal opinion. Authentication means nothin= g to an app. The "truth" and risk in accepting the data being consumed is w= hat matters to any RP. >=20 >> Under what circumstances would you not trust a provider that you have >> requested attributes from, and if such a circumstance exists why are you >> requesting anything from them? >=20 > Replace attributes with authentication in that sentence and it's the same= question. The answer of course is that not all authentication is equal, ju= st as not all assertions of data are equal in their confidence level. Why i= s authentication a transactional consideration but attributes are exactly c= onsistent across the provider? Both are transactional considerations. >=20 >> The purpose of LOA is not to tell you how much to trust the attribute >> provider, it is to tell you how much to trust the user at the other end = of >> the transaction (in my opinion). >=20 > Disagree strenuously. LOA is about the trust placed in an assertion of da= ta by somebody in terms of risk mitigation. It's all data and all attribute= s. Identity is irelevant except as a consequence of how particular data mig= ht be applied and used. >=20 > -- Scott >=20 >=20 > Hi Mark, >=20 > I realize that this is a relatively small point in the context of the thr= ead at this stage, but I believe that your comment below that "authenticati= on establishes trust in the PERSON on the other end of a transaction" needs= to be expanded to read "authentication establishes trust [i.e., level of c= onfidence] in the ENTITY on the other end of a transaction" since we have t= o account for non-person entities as well as human users and authentication= is only one link in the chain of establishing trust in the entity for a pa= rticular transaction in a particular context. >=20 > Avanti, > BobN >=20 > -----Original Message----- > From: vot [mailto:vot-bounces@ietf.org] On Behalf Of Jones, Mark B > Sent: Sunday, January 11, 2015 9:24 PM > To: Jim Fenton; vot@ietf.org > Subject: Re: [VoT] A modest proposal to replace LOA >=20 > It is my opinion that the levels of assurance in 800-63 are meant to desc= ribe specific sets of threats that should be addressed at specific, common = risk levels and to describe how to mitigate those threats. It is not clear= what specific threats your proposed levels are meant to address. (I think= the VoT discussion in general is also lacking in references to what specif= ic threats are meant to be addressed by specific vectors.) >=20 > Though 800-63 has language that talks about including verified attributes= in credentials and assertions it makes it clear that inclusion of attribut= es is optional. I feel that 800-63 works just fine in a model where authen= tication and attribute providers are separate because it does not specify a= ny limits on how attributes can be communicated. It is my opinion that 'au= thentication' and the communication of attributes must be conceptualized as= very separate processes and that your concept of "Attribute Reliability" i= nappropriately conflates 'Registration and Credential Issuance' with attrib= ute assertions. The threats associated with inappropriate registration and= credential issuance are very different from those associated with receivin= g inaccurate attribute assertions. >=20 > Though some have reasonable arguments for assigning levels of assurance t= o attributes, I believe that relying parties must trust 'attribute provider= s' > as opposed to trusting specific attribute assertions. It is my opinion t= hat relying parties should only request attributes from providers they cons= ider to be (or accept as) authoritative for the attributes requested. So i= n my view attributes have little to do with LOA discussion. >=20 > In summary I feel that any scheme for expressing LOA needs to describe th= e threats that are mitigated, the strength of those mitigations, and trust = of authentication should be kept separate from trust of attribute assertion= s. > After all, authentication establishes trust in the PERSON on the other en= d of a transaction while trust in an attribute assertion represents trust i= n the PROVIDER to collect and assert good attributes. =20 >=20 >> -----Original Message----- >> From: vot [mailto:vot-bounces@ietf.org] On Behalf Of Jim Fenton >> Sent: Friday, January 09, 2015 2:50 PM >> To: vot@ietf.org >> Subject: [VoT] A modest proposal to replace LOA >>=20 >> I posted some ideas yesterday on a somewhat constrained possible=20 >> replacement for Levels of Assurance: >>=20 >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps- >> 3A__altmode.wordpress.com_2015_01_08_level-2Dof-2Dassurance- >> 2Dalternatives-2Da-2Dmodest- >> 2Dproposal_&d=3DAwICAg&c=3D6vgNTiRn9_pqCD9hKx9JgXN1VapJQ8JVoF8oWH >> 1AgfQ&r=3DjgMu8DNgV_dycz0rYwkNbEQq36F0BI5_Zpblz7C5LhM&m=3D2E_n- >> hMMZrra2XwK7mj_KrpU8b-c3PcCa45FsWVh0bE&s=3DAf4ObdyoFr4e6yoEMT- >> aIfNHcCZsmGzZZMyr1LnD5Oo&e=3D >>=20 >> tl;dr: One dimension (LOA) isn't enough, but we don't want too many=20 >> dimensions or levels because that gets unwieldy. I'm proposing 3=20 >> levels > each >> of two dimensions: Level of Strength (authentication) and Level of > Reliability >> (attribute binding/proofing). >>=20 >> Any thoughts would be appreciated. >>=20 >> -Jim >>=20 >> _______________________________________________ >> vot mailing list >> vot@ietf.org >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps- >> 3A__www.ietf.org_mailman_listinfo_vot&d=3DAwICAg&c=3D6vgNTiRn9_pqCD9h >> Kx9JgXN1VapJQ8JVoF8oWH1AgfQ&r=3DjgMu8DNgV_dycz0rYwkNbEQq36F0BI5 >> _Zpblz7C5LhM&m=3D2E_n-hMMZrra2XwK7mj_KrpU8b- >> c3PcCa45FsWVh0bE&s=3DM7Gbma252T4WErXbcfD- >> 69cOz3ZwOSUUCxEP2QIPklg&e=3D >=20 >=20 > _______________________________________________ > vot mailing list > vot@ietf.org > https://www.ietf.org/mailman/listinfo/vot From nobody Sun Jan 18 17:21:06 2015 Return-Path: X-Original-To: vot@ietfa.amsl.com Delivered-To: vot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FDEC1ACE8B for ; Sun, 18 Jan 2015 17:21:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 QuWj8fB0TWxQ for ; Sun, 18 Jan 2015 17:20:59 -0800 (PST) Received: from mta6.uth.tmc.edu (mta6.uth.tmc.edu [129.106.163.164]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A26C41ACE7C for ; Sun, 18 Jan 2015 17:20:59 -0800 (PST) Received: from pps.filterd (mta6.uth.tmc.edu [127.0.0.1]) by mta6.uth.tmc.edu (8.14.5/8.14.5) with SMTP id t0J1D1d8015686; Sun, 18 Jan 2015 19:20:58 -0600 Received: from uthmail3.uthouston.edu (admin4-6.hsc.uth.tmc.edu [129.106.4.6]) by mta6.uth.tmc.edu with ESMTP id 1s0n3are5w-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 18 Jan 2015 19:20:58 -0600 Received: from UTHMAIL1.uthouston.edu ([fe80::c1d2:3f6a:4f56:4fa4]) by UTHMAIL3.uthouston.edu ([fe80::fd74:5f7a:1426:e687%22]) with mapi id 14.03.0210.002; Sun, 18 Jan 2015 19:20:57 -0600 From: "Jones, Mark B" To: "Cantor, Scott" , Eric Goodman , "vot@ietf.org" Thread-Topic: [VoT] A modest proposal to replace LOA Thread-Index: AQHQLE3NIVccl7Oe9EyjUXstdR0255y7QHEAgAImvgCABhFfAP//wMgAgABt0oCAAulJQA== Date: Mon, 19 Jan 2015 01:20:56 +0000 Message-ID: <38AAF00EA635514CA6667ACA60C7F0A548A08BE5@UTHMAIL1.uthouston.edu> References: <54B03EE4.3060909@bluepopcorn.net> <38AAF00EA635514CA6667ACA60C7F0A53153A573@UTHMAIL1.uthouston.edu> <54B43AA4.3030005@bluepopcorn.net> <38AAF00EA635514CA6667ACA60C7F0A531547B9C@UTHMAIL1.uthouston.edu> <9846A6064BD102419D06814DD0D78DE1068C80@CIO-TNC-D2MBX02.osuad.osu.edu> In-Reply-To: <9846A6064BD102419D06814DD0D78DE1068C80@CIO-TNC-D2MBX02.osuad.osu.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [129.106.149.128] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0066_01D03353.DFDD5170" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2015-01-19_01:2015-01-18,2015-01-18,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 kscore.is_bulkscore=2.65653004150046e-07 kscore.compositescore=0 circleOfTrustscore=0 compositescore=0.484113431473537 urlsuspect_oldscore=0.484113431473537 suspectscore=0 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=0 rbsscore=0.484113431473537 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1501190013 Archived-At: Subject: Re: [VoT] A modest proposal to replace LOA X-BeenThere: vot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Vectors of Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2015 01:21:02 -0000 ------=_NextPart_000_0066_01D03353.DFDD5170 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > > 800-63 is very clear in stating that its scope only applies to > > authentication. > > Which is why it's nonsensical to start with, because there is no way to > communicate an "identity" without an attribute digitally. It's defining its own > scope as zero. > [Jones, Mark B] Communicating an identity (attributes) is not the goal of 800-63. I think it makes perfect sense to consider authentication and the communication of attributes very separately. I'm not saying that communication of the 'identity' is optional or not important, but that it should be conceptualized as a very separate process even if it occurs alongside authentication. 800-63 is not nonsensical, it is just concerned with only one of two distinct processes. > > Your statement above is a perfect example of why levels of assurance > > should only apply to the authentication and not the attributes. > > The other way around, in my personal opinion. Authentication means > nothing to an app. The "truth" and risk in accepting the data being consumed > is what matters to any RP. > [Jones, Mark B] We just disagree here. I concede that attributes are essential for personalization and authorization decisions at the RP, but RPs (especially those that deal with PHI or other sensitive data) care very much about authentication. The fact that an attribute provider has well vetted attributes about a real, natural person means nothing if that identity is not strongly bound to the authentication credential. > > Under what circumstances would you not trust a provider that you have > > requested attributes from, and if such a circumstance exists why are > > you requesting anything from them? > > Replace attributes with authentication in that sentence and it's the same > question. The answer of course is that not all authentication is equal, just as > not all assertions of data are equal in their confidence level. Why is > authentication a transactional consideration but attributes are exactly > consistent across the provider? Both are transactional considerations. > [Jones, Mark B] Though you could make similar statements about authentication, I was talking about the communication of attributes. But in both cases, if a RP decides to accept either an authentication or an attribute, the RP has made a binary decision to trust that provider. It does not matter if the authentication is LOA 1 or LOA 4, the RP has decided to trust the authentication provider to authenticate the user. When you say that "not all authentication is equal" I assume you are talking about LOA. It is true that after a RP has trusted an authentication provider to authenticate a user, and after that RP has trusted the authentication provider to communicate an appropriate expression of the LOA for that authentication, the RP can use this to decide if the LOA is sufficient for the access requested. So even if the user is turned away by the RP, the RP made that decision based on trust in the provider. But if an RP requests attributes that are to be used to make authorization decisions, the RP should only request such attributes from providers it trusts and considers to be authoritative. It does not make any sense for an attribute provider to offer the same attribute at varying levels of assurance. Even if an attribute provider has better vetting procedures for one attribute over another, it is reasonable to believe that provider will communicate the best data it has. I also think that if a RP has requested the attribute, it has already decided to trust the provider and decided that the provider's vetting procedures (known or unknown) are 'good enough'. > > The purpose of LOA is not to tell you how much to trust the attribute > > provider, it is to tell you how much to trust the user at the other > > end of the transaction (in my opinion). > > Disagree strenuously. LOA is about the trust placed in an assertion of data by > somebody in terms of risk mitigation. It's all data and all attributes. Identity is > irelevant except as a consequence of how particular data might be applied > and used. > [Jones, Mark B] The way I read this is that your definition of LOA is different than mine. You seem to focus only on the communication of attributes (which is in line with your stated view that "authentication means nothing to an app") where I focus only on authentication. But if you are concerned about risk mitigation then I think that is an excellent place to start finding common ground. My question to you is, in what way does the communication of any attribute address any of the threats itemized in 800-63? It is my opinion that these threats only apply to authentication and have nothing to do with how attributes are communicated. In your view of LOA, what threats are being mitigated and how? > -- Scott ------=_NextPart_000_0066_01D03353.DFDD5170 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIYTDCCBDYw ggMeoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRy dXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZ QWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wMDA1MzAxMDQ4MzhaFw0yMDA1MzAxMDQ4Mzha MG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3Qg RXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3Qw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC39xoz5vIABC054E5b7R+8bA/Ntfojts7e mxEzl6QpTH2Tn71KvJPtAxrjj8/lbVBa1pcplFqAsEl62y6V/bjKvzc4LR4+kUGtcFbH8E8/6DKe dMrIkFTpxl8PeJ2aQDwOrGGqXhSPnoehalDc15pOrwWzpnGUnHGzUGAKxxOdOAeGAqjpqGkmGJCr TLBPI6s6T4TY386f4Wlvu9dC12tE5Met7m1BX3JacQg3s3llpFmglDf3AC8NwpJy2tA4ctsUqEXE XSp9t7TWxO6szRNEt8kr3UMAJfphuWlqWCMRt6czj1Z1WfXNKddGtworZbbTQm8Vsrh7++/pXVPV NFonAgMBAAGjgdwwgdkwHQYDVR0OBBYEFK29mHo0tCb3+sQmVO8DveAky1QaMAsGA1UdDwQEAwIB BjAPBgNVHRMBAf8EBTADAQH/MIGZBgNVHSMEgZEwgY6AFK29mHo0tCb3+sQmVO8DveAky1QaoXOk cTBvMQswCQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0 IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 ggEBMA0GCSqGSIb3DQEBBQUAA4IBAQCwm+CFJcLWI+IPlgaSnUGYnNmEeYHZHlsUByM2ZY+w2He7 rEFsR2CDUbD5Mj3n/PYmE8eAFqW/WvyHz3h5iSGa4kwHCoY1vPLeUcTSlrfcfk7ucP0cOesMAlEU LY69FuDB30Z15ySt7PRCtIWTcBBnup0GNUoY0yt6zFFCoXpj0ea7ocUrwja+Ew3mvWN+eXunCQ1A q2rdj4rD9vaMGkIFUdRF9Z+nYiFoFSBDPJnnfL0k2KmRF3OIP1YbMTgYtHEPms3IDp6OLhvhjJiD yx8x8URMxgRzSXZgD8f4vReAay7pzEwOWpp5DyAKLtWeYyYeVZKU2IIXWnvQvMePToYEMIIEijCC A3KgAwIBAgIQJ/TqEfR6hsRunbtuqRcHBzANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEU MBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3 b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTA1MDYwNzA4MDkxMFoX DTIwMDUzMDEwNDgzOFowga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2Fs dCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0 cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRo ZW50aWNhdGlvbiBhbmQgRW1haWwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCyOYWk 8n2rQTtiRjeuzcFgdbw5ZflKGkeiucxIzGqY1U01GbmkQuXOSeKKLx580jEHx060g2SdLinVomTE hb2FUTV5pE5okHsceqSSqBfymBXyk8zJpDKVuwxPML2YoAuL5W4bokb6eLyib6tZXqUvz8rabaov 66yhs2qqty5nNYt54R5piOLmRs2gpeq+C852OnoOm+r82idbPXMfIuZIYcZM82mxqC4bttQxICy8 goqOpA6l14lD/BZarx1x1xFZ2rqHDa/68+HC8KTFZ4zW1lQ63gqkugN3s2XI/R7TdGKqGMpokx6h hX71R2XL+E1XKHTSNP8wtu72YjAUjCzrAgMBAAGjgeEwgd4wHwYDVR0jBBgwFoAUrb2YejS0Jvf6 xCZU7wO94CTLVBowHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59MA4GA1UdDwEB/wQEAwIB BjAPBgNVHRMBAf8EBTADAQH/MHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2Eu Y29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5u ZXQvQWRkVHJ1c3RFeHRlcm5hbENBUm9vdC5jcmwwDQYJKoZIhvcNAQEFBQADggEBABnYiRFvKKym AKLnh8GbkAPbfqES/R7z4vABqZRUQmuaCcSgbdeQkgQDZnlDcfz4b6/bdkXiNxo93eRZBHisHPSD RvN6z1uEci3lRsG6GBEp88tJeYc8um0FnaRtaE+tchQ2qLmx/b/Pf/CkapQ1UI/PgW1Vsd1ZMErf baCcZB9JfO82u/TjafT4OY9arUuFOrcO7dPPDUSi+wS/5C9wjiX7WlQGs9DEvG2N+3MyLOmbhCQt 1n+RemgCUB8OP03pzPW7Z+jcHC47/E7N/gKO46gTCqUmRGXpEPJNUqeu3D7KazJcQWz+9V2g6v/R +puGWG09lkfl/i6VBMIAzI6h8rswggSdMIIDhaADAgECAhA0PekrrCc0/4/LNJT7zHBUMA0GCSqG SIb3DQEBBQUAMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMd QWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFs IENBIFJvb3QwHhcNMDUwNjA3MDgwOTEwWhcNMjAwNTMwMTA0ODM4WjCBrjELMAkGA1UEBhMCVVMx CzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJU UlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMT LVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjMapjVTTUZ uaRC5c5J4oovHnzSMQfHTrSDZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKTzMmkMpW7DE8w vZigC4vlbhuiRvp4vKJvq1lepS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZGzaCl6r4LznY6eg6b 6vzaJ1s9cx8i5khhxkzzabGoLhu21DEgLLyCio6kDqXXiUP8FlqvHXHXEVnauocNr/rz4cLwpMVn jNbWVDreCqS6A3ezZcj9HtN0YqoYymiTHqGFfvVHZcv4TVcodNI0/zC27vZiMBSMLOsCAwEAAaOB 9DCB8TAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73gJMtUGjAdBgNVHQ4EFgQUiYJnfcSdJnAA S7RQSHzePa4Ebn0wDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wEQYDVR0gBAowCDAG BgRVHSAAMEQGA1UdHwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVz dEV4dGVybmFsQ0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9v Y3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQEFBQADggEBAAG8nONjKLDzMQHC33vdYqABnSMx D5ySc1NR6h9M+tafxMovZ354Mw90FrmRh5H1iib6ZHAA2B75CwRiUIeTgdTa9SPbNLuFVrRwNG54 gzcehRzFERWSX4cXvaxq/fHC0cyJX7F88D5R8jXzfOxgmGs6K+Dv37N9huu1G/Vb7KJ8mBPXAFC5 0S1z3gN4dOEFhTFey5q5nZTGuZQ3dXLcRPtn6PD6JR5Sp9ol6UfgoMc8oE6xCjb7d0if75eK+7T+ 45QUqIO8XC0/0mBxYO7CcYIM6Yg249ogtKOgbKqWS7iAjnXKSQf2OxS639wF2Z/b4LLmTaB4Jufn LW5/X8YeiBUwggUlMIIEDaADAgECAhBEhRwZ960PFPjEdYY0xHTHMA0GCSqGSIb3DQEBBQUAMIGu MQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYD VQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0 LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVt YWlsMB4XDTEwMTIwMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZYxCzAJBgNVBAYTAlVTMUEwPwYD VQQKEzhUaGUgVW5pdmVyc2l0eSBvZiBUZXhhcyBIZWFsdGggU2NpZW5jZSBDZW50ZXIgYXQgSG91 c3RvbjFEMEIGA1UEAxM7VGhlIFVuaXZlcnNpdHkgb2YgVGV4YXMgSGVhbHRoIFNjaWVuY2UgQ2Vu dGVyIGF0IEhvdXN0b24gQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDESWPwD83F Kdtxoco69aUO3n4Rskw9kVrIyZFxHkFsSrAz08tA9MfXIkhmn7sB+CLoJn8aslw4QhGx8/jcfdUr k7kUjrMhPpkQSOP6G5nSFZ7LoKD9k1TbYytdcIYRzRbhp+pJc1faaRyTahBbfGsNNqJ8JYEVAOSL 6Tl3zApDZu6T9ogUk7SqibPGrVx0moBL+wU9ZHdpF0mufkiyNl4OyexZkWkoJGIDJuByiAzR/aZY MsBO6xGgvjUOI6Ul8fbY05sdwVNCaygCdeNf4XAnB1nkf6SKJQIf21c4d0/Io6hCgGqD6Z2QJvjC +ImxVOuriV98EZ77HJ4rZ2VieBBJAgMBAAGjggFTMIIBTzAfBgNVHSMEGDAWgBSJgmd9xJ0mcABL tFBIfN49rgRufTAdBgNVHQ4EFgQUmRfQBCFKbpHxh15vdm873cQyHiAwDgYDVR0PAQH/BAQDAgEG MBIGA1UdEwEB/wQIMAYBAf8CAQAwGQYDVR0gBBIwEDAOBgwrBgEEAbIxAQICJAUwWAYDVR0fBFEw TzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3QuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0 aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYIKwYBBQUHAQEEaDBmMD0GCCsGAQUFBzAChjFodHRw Oi8vY3J0LnVzZXJ0cnVzdC5jb20vVVROQWRkVHJ1c3RDbGllbnRfQ0EuY3J0MCUGCCsGAQUFBzAB hhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQAqooItXjf7MTAG n8Ad56XGcmKSI7rN8cfuU1K+3AE/Iabhm4i/pYeXrr1dCkwtxTHLxvQHyAdnTQAD6ZnuvZg/setS K5MRayx0Dzn09gd4i6V8F8uFI/bw6fsLUzFo4MP1RC2PWPc1QYLLaQIYHbG6lSMRe01ZJOAQZaEy K/lX4S+MsSezn1GmbkEdaCzJwU5LLO2MlhCREgXHdiLohflvuz6XEy33rJXBpq2Uj7ExY8mnF5aU HOr+ciE99EQmYp/RHNmHnwaLpOcg+OZKwhUFkmFTF1MgmR9omRqM7Lnf1ZEwz2TTiAEfhkgV3ZXC rAH1pmXbsuB+9g556izDM+lHMIIFtjCCBJ6gAwIBAgIRALYIBQEKf340KUQdm7mP5o4wDQYJKoZI hvcNAQEFBQAwgZYxCzAJBgNVBAYTAlVTMUEwPwYDVQQKEzhUaGUgVW5pdmVyc2l0eSBvZiBUZXhh cyBIZWFsdGggU2NpZW5jZSBDZW50ZXIgYXQgSG91c3RvbjFEMEIGA1UEAxM7VGhlIFVuaXZlcnNp dHkgb2YgVGV4YXMgSGVhbHRoIFNjaWVuY2UgQ2VudGVyIGF0IEhvdXN0b24gQ0EwHhcNMTQwOTE1 MDAwMDAwWhcNMTUwOTE1MjM1OTU5WjCBszEOMAwGA1UEERMFNzcwMzAxHDAaBgNVBAoTE1VUSEVB TFRIIE5PTi1FU0NST1cxFDASBgNVBAkTCzcwMDAgRmFubmluMQ4wDAYDVQQIEwVUZXhhczEQMA4G A1UEBxMHSG91c3RvbjELMAkGA1UEBhMCVVMxFTATBgNVBAMTDE1hcmsgQiBKb25lczEnMCUGCSqG SIb3DQEJARYYbWFyay5iLmpvbmVzQHV0aC50bWMuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAiwP1vz8f3p5uhhE6ShloDb9ARfE0AKJ4aFKv4JDNR9KWFZwvgzr24D3fymp4q/MZ ZYkESRvjq3NMyGdta69s1+pRP48FKEi+RKud3LsETSjOQqMVVT/qNOyPaSWcPJ+rfCfT4YD974VP NhoN2Pu2zp+KPvgN7YYM902VUlrq7PMxpN3txLdPzuG3RivTc1K0lECX4h03hykn35efXg0bs+eV nLl/JcNYzzyR3+C5Sl18rpciMS53TW+MNyg2k3eKFFeXwucQ/vTR2ixravz3t6a2DxclpKfDiT8Y lR9K4aBbattilQ7JH0k/NlAyUs+qm01GMXlYDOnad4NyXZ9vSQIDAQABo4IB3jCCAdowHwYDVR0j BBgwFoAUmRfQBCFKbpHxh15vdm873cQyHiAwHQYDVR0OBBYEFOTz8hhbFB85qOV5v5Bs0SzlHUcL MA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEF BQcDBDBDBgNVHSAEPDA6MDgGDCsGAQQBsjEBAgIkBTAoMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3 LnV0aC50bWMuZWR1L2NwczBeBgNVHR8EVzBVMFOgUaBPhk1odHRwOi8vY3JsLnV0aC50bWMuZWR1 L1RoZVVuaXZlcnNpdHlvZlRleGFzSGVhbHRoU2NpZW5jZUNlbnRlcmF0SG91c3RvbkNBLmNybDCB kAYIKwYBBQUHAQEEgYMwgYAwWQYIKwYBBQUHMAKGTWh0dHA6Ly9jcnQudXRoLnRtYy5lZHUvVGhl VW5pdmVyc2l0eW9mVGV4YXNIZWFsdGhTY2llbmNlQ2VudGVyYXRIb3VzdG9uQ0EuY3J0MCMGCCsG AQUFBzABhhdodHRwOi8vb2NzcC51dGgudG1jLmVkdTAjBgNVHREEHDAagRhtYXJrLmIuam9uZXNA dXRoLnRtYy5lZHUwDQYJKoZIhvcNAQEFBQADggEBAIHnKkprA8MFrWWS3kq/emuJgLPC3mRQkD0x pACshsCekfY6g+dpRydoYU2GBubtMwmYLhWyk/u4Gyu1QbPLBF7sBfCtEtflYrFPgooN0iieh+0T TNUkYI/xJ6VOeUI5iTX9prtuVawu0Rqf8AayAnAWjwiOtYj3kOqKYqEfuo5Tkohs+i8SSwTo0UTQ Rwd0EsMRaYfWIJpm+Xao0nKsRG1VjEbvBMBROUwbpOva2SbV/o0mLO9RIJrEJVWlnhBIdhvp501g jbnD8PbKgN4YK/Kr2XJED+HlCigd3G77y0YlmnED19IoN7CMo0gmiKsY6Gssz23z83FfDjSx3u9l 1NkxggQUMIIEEAIBATCBrDCBljELMAkGA1UEBhMCVVMxQTA/BgNVBAoTOFRoZSBVbml2ZXJzaXR5 IG9mIFRleGFzIEhlYWx0aCBTY2llbmNlIENlbnRlciBhdCBIb3VzdG9uMUQwQgYDVQQDEztUaGUg VW5pdmVyc2l0eSBvZiBUZXhhcyBIZWFsdGggU2NpZW5jZSBDZW50ZXIgYXQgSG91c3RvbiBDQQIR ALYIBQEKf340KUQdm7mP5o4wCQYFKw4DAhoFAKCCAjwwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTUwMTE5MDEyMDUyWjAjBgkqhkiG9w0BCQQxFgQU8QS0jdErV7IU I1d9sx/CwQ0kr18wWwYJKoZIhvcNAQkPMU4wTDAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAw DQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwBwYFKw4DAhowgb0GCSsGAQQB gjcQBDGBrzCBrDCBljELMAkGA1UEBhMCVVMxQTA/BgNVBAoTOFRoZSBVbml2ZXJzaXR5IG9mIFRl eGFzIEhlYWx0aCBTY2llbmNlIENlbnRlciBhdCBIb3VzdG9uMUQwQgYDVQQDEztUaGUgVW5pdmVy c2l0eSBvZiBUZXhhcyBIZWFsdGggU2NpZW5jZSBDZW50ZXIgYXQgSG91c3RvbiBDQQIRALYIBQEK f340KUQdm7mP5o4wgb8GCyqGSIb3DQEJEAILMYGvoIGsMIGWMQswCQYDVQQGEwJVUzFBMD8GA1UE ChM4VGhlIFVuaXZlcnNpdHkgb2YgVGV4YXMgSGVhbHRoIFNjaWVuY2UgQ2VudGVyIGF0IEhvdXN0 b24xRDBCBgNVBAMTO1RoZSBVbml2ZXJzaXR5IG9mIFRleGFzIEhlYWx0aCBTY2llbmNlIENlbnRl ciBhdCBIb3VzdG9uIENBAhEAtggFAQp/fjQpRB2buY/mjjANBgkqhkiG9w0BAQEFAASCAQCF9I64 BJQgNDmJ68ZPaH9/PrBSfZoTGAfiRP97Lp74ZwYRuIRpkx1QpKOoC2yksIov6b31Nbf/EealugRh NgNflbMp4WHAw7YbCZ2PXwxz/5wR6R6uqs5kq0q0tBDi0X3KDClIHI2kJnsjHHcxTHCLtwhPcDoR 9YSG7I+xDbZPB0YPWkI8cbzEkC0GTQ2+pcKCdoRmA3+OdGJ/6jcwCp8Ltnw5OKNouE51lvarfghU 3TSrA+B3jTXM5RuM2Zhmv4tkNVnvJAHsw8Y5f/nzbqC0z8PRWwAafyF50cYAmOTaiTx64alkf2WS SXVcUXzVnDmLpEHATx+ccbB+vcgT9VrPAAAAAAAA ------=_NextPart_000_0066_01D03353.DFDD5170-- From nobody Mon Jan 19 08:52:23 2015 Return-Path: X-Original-To: vot@ietfa.amsl.com Delivered-To: vot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C24571B2ABE for ; Mon, 19 Jan 2015 08:52:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 nIyQLpJbXHct for ; Mon, 19 Jan 2015 08:52:20 -0800 (PST) Received: from mta6.uth.tmc.edu (mta6.uth.tmc.edu [129.106.163.164]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 334AF1B2A0D for ; Mon, 19 Jan 2015 08:52:20 -0800 (PST) Received: from pps.filterd (mta6.uth.tmc.edu [127.0.0.1]) by mta6.uth.tmc.edu (8.14.5/8.14.5) with SMTP id t0JGgZHw005516; Mon, 19 Jan 2015 10:52:12 -0600 Received: from uthmail3.uthouston.edu (admin4-6.hsc.uth.tmc.edu [129.106.4.6]) by mta6.uth.tmc.edu with ESMTP id 1s0n3atqvh-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 19 Jan 2015 10:52:12 -0600 Received: from UTHMAIL1.uthouston.edu ([fe80::c1d2:3f6a:4f56:4fa4]) by UTHMAIL3.uthouston.edu ([fe80::fd74:5f7a:1426:e687%22]) with mapi id 14.03.0210.002; Mon, 19 Jan 2015 10:52:11 -0600 From: "Jones, Mark B" To: "Natale, Bob" Thread-Topic: [VoT] A modest proposal to replace LOA Thread-Index: AQHQLE3NIVccl7Oe9EyjUXstdR0255y7QHEAgAkUzQCAA2JTYA== Date: Mon, 19 Jan 2015 16:52:10 +0000 Message-ID: <38AAF00EA635514CA6667ACA60C7F0A548A0A2F6@UTHMAIL1.uthouston.edu> References: <54B03EE4.3060909@bluepopcorn.net> <38AAF00EA635514CA6667ACA60C7F0A53153A573@UTHMAIL1.uthouston.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [129.106.149.128] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0027_01D033D5.FA6BE510" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2015-01-19_02:2015-01-19,2015-01-19,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1501190168 Archived-At: Cc: Jim Fenton , "vot@ietf.org" Subject: Re: [VoT] A modest proposal to replace LOA X-BeenThere: vot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Vectors of Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2015 16:52:22 -0000 ------=_NextPart_000_0027_01D033D5.FA6BE510 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > I realize that this is a relatively small point in the context of the thread at this > stage, but I believe that your comment below that "authentication > establishes trust in the PERSON on the other end of a transaction" needs to > be expanded to read "authentication establishes trust [i.e., level of > confidence] in the ENTITY on the other end of a transaction" since we have > to account for non-person entities as well as human users and authentication > is only one link in the chain of establishing trust in the entity for a particular > transaction in a particular context. > > Avanti, > BobN > [Jones, Mark B] Agreed. ------=_NextPart_000_0027_01D033D5.FA6BE510 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITvjCCBDYw ggMeoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRy dXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZ QWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wMDA1MzAxMDQ4MzhaFw0yMDA1MzAxMDQ4Mzha MG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3Qg RXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3Qw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC39xoz5vIABC054E5b7R+8bA/Ntfojts7e mxEzl6QpTH2Tn71KvJPtAxrjj8/lbVBa1pcplFqAsEl62y6V/bjKvzc4LR4+kUGtcFbH8E8/6DKe dMrIkFTpxl8PeJ2aQDwOrGGqXhSPnoehalDc15pOrwWzpnGUnHGzUGAKxxOdOAeGAqjpqGkmGJCr TLBPI6s6T4TY386f4Wlvu9dC12tE5Met7m1BX3JacQg3s3llpFmglDf3AC8NwpJy2tA4ctsUqEXE XSp9t7TWxO6szRNEt8kr3UMAJfphuWlqWCMRt6czj1Z1WfXNKddGtworZbbTQm8Vsrh7++/pXVPV NFonAgMBAAGjgdwwgdkwHQYDVR0OBBYEFK29mHo0tCb3+sQmVO8DveAky1QaMAsGA1UdDwQEAwIB BjAPBgNVHRMBAf8EBTADAQH/MIGZBgNVHSMEgZEwgY6AFK29mHo0tCb3+sQmVO8DveAky1QaoXOk cTBvMQswCQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0 IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 ggEBMA0GCSqGSIb3DQEBBQUAA4IBAQCwm+CFJcLWI+IPlgaSnUGYnNmEeYHZHlsUByM2ZY+w2He7 rEFsR2CDUbD5Mj3n/PYmE8eAFqW/WvyHz3h5iSGa4kwHCoY1vPLeUcTSlrfcfk7ucP0cOesMAlEU LY69FuDB30Z15ySt7PRCtIWTcBBnup0GNUoY0yt6zFFCoXpj0ea7ocUrwja+Ew3mvWN+eXunCQ1A q2rdj4rD9vaMGkIFUdRF9Z+nYiFoFSBDPJnnfL0k2KmRF3OIP1YbMTgYtHEPms3IDp6OLhvhjJiD yx8x8URMxgRzSXZgD8f4vReAay7pzEwOWpp5DyAKLtWeYyYeVZKU2IIXWnvQvMePToYEMIIEnTCC A4WgAwIBAgIQND3pK6wnNP+PyzSU+8xwVDANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEU MBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3 b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTA1MDYwNzA4MDkxMFoX DTIwMDUzMDEwNDgzOFowga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2Fs dCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0 cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRo ZW50aWNhdGlvbiBhbmQgRW1haWwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCyOYWk 8n2rQTtiRjeuzcFgdbw5ZflKGkeiucxIzGqY1U01GbmkQuXOSeKKLx580jEHx060g2SdLinVomTE hb2FUTV5pE5okHsceqSSqBfymBXyk8zJpDKVuwxPML2YoAuL5W4bokb6eLyib6tZXqUvz8rabaov 66yhs2qqty5nNYt54R5piOLmRs2gpeq+C852OnoOm+r82idbPXMfIuZIYcZM82mxqC4bttQxICy8 goqOpA6l14lD/BZarx1x1xFZ2rqHDa/68+HC8KTFZ4zW1lQ63gqkugN3s2XI/R7TdGKqGMpokx6h hX71R2XL+E1XKHTSNP8wtu72YjAUjCzrAgMBAAGjgfQwgfEwHwYDVR0jBBgwFoAUrb2YejS0Jvf6 xCZU7wO94CTLVBowHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59MA4GA1UdDwEB/wQEAwIB BjAPBgNVHRMBAf8EBTADAQH/MBEGA1UdIAQKMAgwBgYEVR0gADBEBgNVHR8EPTA7MDmgN6A1hjNo dHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vQWRkVHJ1c3RFeHRlcm5hbENBUm9vdC5jcmwwNQYIKwYB BQUHAQEEKTAnMCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3 DQEBBQUAA4IBAQABvJzjYyiw8zEBwt973WKgAZ0jMQ+cknNTUeofTPrWn8TKL2d+eDMPdBa5kYeR 9Yom+mRwANge+QsEYlCHk4HU2vUj2zS7hVa0cDRueIM3HoUcxREVkl+HF72sav3xwtHMiV+xfPA+ UfI183zsYJhrOivg79+zfYbrtRv1W+yifJgT1wBQudEtc94DeHThBYUxXsuauZ2UxrmUN3Vy3ET7 Z+jw+iUeUqfaJelH4KDHPKBOsQo2+3dIn++Xivu0/uOUFKiDvFwtP9JgcWDuwnGCDOmINuPaILSj oGyqlku4gI51ykkH9jsUut/cBdmf2+Cy5k2geCbn5y1uf1/GHogVMIIFJTCCBA2gAwIBAgIQRIUc GfetDxT4xHWGNMR0xzANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVU MRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3Jr MSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmly c3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0xMDEyMDIwMDAwMDBaFw0yMDA1 MzAxMDQ4MzhaMIGWMQswCQYDVQQGEwJVUzFBMD8GA1UEChM4VGhlIFVuaXZlcnNpdHkgb2YgVGV4 YXMgSGVhbHRoIFNjaWVuY2UgQ2VudGVyIGF0IEhvdXN0b24xRDBCBgNVBAMTO1RoZSBVbml2ZXJz aXR5IG9mIFRleGFzIEhlYWx0aCBTY2llbmNlIENlbnRlciBhdCBIb3VzdG9uIENBMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxElj8A/NxSnbcaHKOvWlDt5+EbJMPZFayMmRcR5BbEqw M9PLQPTH1yJIZp+7Afgi6CZ/GrJcOEIRsfP43H3VK5O5FI6zIT6ZEEjj+huZ0hWey6Cg/ZNU22Mr XXCGEc0W4afqSXNX2mkck2oQW3xrDTaifCWBFQDki+k5d8wKQ2buk/aIFJO0qomzxq1cdJqAS/sF PWR3aRdJrn5IsjZeDsnsWZFpKCRiAybgcogM0f2mWDLATusRoL41DiOlJfH22NObHcFTQmsoAnXj X+FwJwdZ5H+kiiUCH9tXOHdPyKOoQoBqg+mdkCb4wviJsVTrq4lffBGe+xyeK2dlYngQSQIDAQAB o4IBUzCCAU8wHwYDVR0jBBgwFoAUiYJnfcSdJnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFJkX0AQh Sm6R8Ydeb3ZvO93EMh4gMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEAMBkGA1Ud IAQSMBAwDgYMKwYBBAGyMQECAiQFMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRy dXN0LmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQG CCsGAQUFBwEBBGgwZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFk ZFRydXN0Q2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNv bTANBgkqhkiG9w0BAQUFAAOCAQEAKqKCLV43+zEwBp/AHeelxnJikiO6zfHH7lNSvtwBPyGm4ZuI v6WHl669XQpMLcUxy8b0B8gHZ00AA+mZ7r2YP7HrUiuTEWssdA859PYHeIulfBfLhSP28On7C1Mx aODD9UQtj1j3NUGCy2kCGB2xupUjEXtNWSTgEGWhMiv5V+EvjLEns59Rpm5BHWgsycFOSyztjJYQ kRIFx3Yi6IX5b7s+lxMt96yVwaatlI+xMWPJpxeWlBzq/nIhPfREJmKf0RzZh58Gi6TnIPjmSsIV BZJhUxdTIJkfaJkajOy539WRMM9k04gBH4ZIFd2VwqwB9aZl27LgfvYOeeoswzPpRzCCBbYwggSe oAMCAQICEQC2CAUBCn9+NClEHZu5j+aOMA0GCSqGSIb3DQEBBQUAMIGWMQswCQYDVQQGEwJVUzFB MD8GA1UEChM4VGhlIFVuaXZlcnNpdHkgb2YgVGV4YXMgSGVhbHRoIFNjaWVuY2UgQ2VudGVyIGF0 IEhvdXN0b24xRDBCBgNVBAMTO1RoZSBVbml2ZXJzaXR5IG9mIFRleGFzIEhlYWx0aCBTY2llbmNl IENlbnRlciBhdCBIb3VzdG9uIENBMB4XDTE0MDkxNTAwMDAwMFoXDTE1MDkxNTIzNTk1OVowgbMx DjAMBgNVBBETBTc3MDMwMRwwGgYDVQQKExNVVEhFQUxUSCBOT04tRVNDUk9XMRQwEgYDVQQJEws3 MDAwIEZhbm5pbjEOMAwGA1UECBMFVGV4YXMxEDAOBgNVBAcTB0hvdXN0b24xCzAJBgNVBAYTAlVT MRUwEwYDVQQDEwxNYXJrIEIgSm9uZXMxJzAlBgkqhkiG9w0BCQEWGG1hcmsuYi5qb25lc0B1dGgu dG1jLmVkdTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAIsD9b8/H96eboYROkoZaA2/ QEXxNACieGhSr+CQzUfSlhWcL4M69uA938pqeKvzGWWJBEkb46tzTMhnbWuvbNfqUT+PBShIvkSr ndy7BE0ozkKjFVU/6jTsj2klnDyfq3wn0+GA/e+FTzYaDdj7ts6fij74De2GDPdNlVJa6uzzMaTd 7cS3T87ht0Yr03NStJRAl+IdN4cpJ9+Xn14NG7PnlZy5fyXDWM88kd/guUpdfK6XIjEud01vjDco NpN3ihRXl8LnEP700dosa2r897emtg8XJaSnw4k/GJUfSuGgW2rbYpUOyR9JPzZQMlLPqptNRjF5 WAzp2neDcl2fb0kCAwEAAaOCAd4wggHaMB8GA1UdIwQYMBaAFJkX0AQhSm6R8Ydeb3ZvO93EMh4g MB0GA1UdDgQWBBTk8/IYWxQfOajleb+QbNEs5R1HCzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/ BAIwADAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwQwYDVR0gBDwwOjA4BgwrBgEEAbIx AQICJAUwKDAmBggrBgEFBQcCARYaaHR0cDovL3d3dy51dGgudG1jLmVkdS9jcHMwXgYDVR0fBFcw VTBToFGgT4ZNaHR0cDovL2NybC51dGgudG1jLmVkdS9UaGVVbml2ZXJzaXR5b2ZUZXhhc0hlYWx0 aFNjaWVuY2VDZW50ZXJhdEhvdXN0b25DQS5jcmwwgZAGCCsGAQUFBwEBBIGDMIGAMFkGCCsGAQUF BzAChk1odHRwOi8vY3J0LnV0aC50bWMuZWR1L1RoZVVuaXZlcnNpdHlvZlRleGFzSGVhbHRoU2Np ZW5jZUNlbnRlcmF0SG91c3RvbkNBLmNydDAjBggrBgEFBQcwAYYXaHR0cDovL29jc3AudXRoLnRt Yy5lZHUwIwYDVR0RBBwwGoEYbWFyay5iLmpvbmVzQHV0aC50bWMuZWR1MA0GCSqGSIb3DQEBBQUA A4IBAQCB5ypKawPDBa1lkt5Kv3priYCzwt5kUJA9MaQArIbAnpH2OoPnaUcnaGFNhgbm7TMJmC4V spP7uBsrtUGzywRe7AXwrRLX5WKxT4KKDdIonoftE0zVJGCP8SelTnlCOYk1/aa7blWsLtEan/AG sgJwFo8IjrWI95DqimKhH7qOU5KIbPovEksE6NFE0EcHdBLDEWmH1iCaZvl2qNJyrERtVYxG7wTA UTlMG6Tr2tkm1f6NJizvUSCaxCVVpZ4QSHYb6edNYI25w/D2yoDeGCvyq9lyRA/h5QooHdxu+8tG JZpxA9fSKDewjKNIJoirGOhrLM9t8/NxXw40sd7vZdTZMYIEFDCCBBACAQEwgawwgZYxCzAJBgNV BAYTAlVTMUEwPwYDVQQKEzhUaGUgVW5pdmVyc2l0eSBvZiBUZXhhcyBIZWFsdGggU2NpZW5jZSBD ZW50ZXIgYXQgSG91c3RvbjFEMEIGA1UEAxM7VGhlIFVuaXZlcnNpdHkgb2YgVGV4YXMgSGVhbHRo IFNjaWVuY2UgQ2VudGVyIGF0IEhvdXN0b24gQ0ECEQC2CAUBCn9+NClEHZu5j+aOMAkGBSsOAwIa BQCgggI8MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDExOTE2 NTIxMVowIwYJKoZIhvcNAQkEMRYEFMLyIsmJn9evK956jLcia0gPkihlMFsGCSqGSIb3DQEJDzFO MEwwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G CCqGSIb3DQMCAgEoMAcGBSsOAwIaMIG9BgkrBgEEAYI3EAQxga8wgawwgZYxCzAJBgNVBAYTAlVT MUEwPwYDVQQKEzhUaGUgVW5pdmVyc2l0eSBvZiBUZXhhcyBIZWFsdGggU2NpZW5jZSBDZW50ZXIg YXQgSG91c3RvbjFEMEIGA1UEAxM7VGhlIFVuaXZlcnNpdHkgb2YgVGV4YXMgSGVhbHRoIFNjaWVu Y2UgQ2VudGVyIGF0IEhvdXN0b24gQ0ECEQC2CAUBCn9+NClEHZu5j+aOMIG/BgsqhkiG9w0BCRAC CzGBr6CBrDCBljELMAkGA1UEBhMCVVMxQTA/BgNVBAoTOFRoZSBVbml2ZXJzaXR5IG9mIFRleGFz IEhlYWx0aCBTY2llbmNlIENlbnRlciBhdCBIb3VzdG9uMUQwQgYDVQQDEztUaGUgVW5pdmVyc2l0 eSBvZiBUZXhhcyBIZWFsdGggU2NpZW5jZSBDZW50ZXIgYXQgSG91c3RvbiBDQQIRALYIBQEKf340 KUQdm7mP5o4wDQYJKoZIhvcNAQEBBQAEggEAN4ewdvl5rrw85qaYNyXjUTTMwjh3QwIfbUZv/AS8 ZSnKXjpMF62jUsI/yjDaJwwdZstgJVVE/EaToBqh4XBOzfOIqMnSZkBRexDNqUXu+iEsROuIza9B um4vxEd14a4zetW8HnMWnZ1ztAwrgeY0g+tt9MQ917HmBcLL18zNMSmbR014mZJnNRKMzH+Jxzcr 3xHgrT2qJxCpjkyTs4Jo43M/THFOUg3C8DzJKwMqMLiKOjfyrb3CAhwfPxuEpRW0DxRd4NMHDbSN c03UjIPvGKTSWTUbYFWMCNxTgMa2UZRfrwkpzaAeMj9BitdmY/I2lSDS2RQ2CzZ5DA+vOKs97wAA AAAAAA== ------=_NextPart_000_0027_01D033D5.FA6BE510-- From nobody Mon Jan 19 12:00:17 2015 Return-Path: X-Original-To: vot@ietfa.amsl.com Delivered-To: vot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85E791B2C4D for ; Mon, 19 Jan 2015 12:00:08 -0800 (PST) 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 H3MS8UrRdIhe for ; Mon, 19 Jan 2015 12:00:02 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0145.outbound.protection.outlook.com [207.46.100.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77FE71B2AB0 for ; Mon, 19 Jan 2015 12:00:02 -0800 (PST) Received: from BY2FFO11FD051.protection.gbl (10.1.14.33) by BY2FFO11HUB045.protection.gbl (10.1.14.85) with Microsoft SMTP Server (TLS) id 15.1.49.13; Mon, 19 Jan 2015 20:00:00 +0000 Received: from cio-tnc-pf02.osuad.osu.edu (164.107.81.216) by BY2FFO11FD051.mail.protection.outlook.com (10.1.15.188) with Microsoft SMTP Server (TLS) id 15.1.59.14 via Frontend Transport; Mon, 19 Jan 2015 20:00:00 +0000 Received: from CIO-TNC-HT08.osuad.osu.edu (cio-tnc-ht08.osuad.osu.edu [164.107.81.177]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by cio-tnc-pf02.osuad.osu.edu (Postfix) with ESMTPS id 702902003A; Mon, 19 Jan 2015 14:59:59 -0500 (EST) 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.0174.001; Mon, 19 Jan 2015 14:59:58 -0500 From: "Cantor, Scott" To: "Jones, Mark B" , Eric Goodman , "vot@ietf.org" Thread-Topic: [VoT] A modest proposal to replace LOA Thread-Index: AQHQLE3ctuj9rJBN0EyoeCVXVMLiBZy8GNiAgAE9lACABhFfAIAAKmGA//+t0HCAA8eTAIAA4Wvw Date: Mon, 19 Jan 2015 19:59:57 +0000 Message-ID: <9846A6064BD102419D06814DD0D78DE106A329@CIO-TNC-D2MBX02.osuad.osu.edu> References: <54B03EE4.3060909@bluepopcorn.net> <38AAF00EA635514CA6667ACA60C7F0A53153A573@UTHMAIL1.uthouston.edu> <54B43AA4.3030005@bluepopcorn.net> <38AAF00EA635514CA6667ACA60C7F0A531547B9C@UTHMAIL1.uthouston.edu> <9846A6064BD102419D06814DD0D78DE1068C80@CIO-TNC-D2MBX02.osuad.osu.edu> <38AAF00EA635514CA6667ACA60C7F0A548A08BE5@UTHMAIL1.uthouston.edu> In-Reply-To: <38AAF00EA635514CA6667ACA60C7F0A548A08BE5@UTHMAIL1.uthouston.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.146.14.74] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 Received-SPF: Pass (protection.outlook.com: domain of osu.edu designates 164.107.81.216 as permitted sender) receiver=protection.outlook.com; client-ip=164.107.81.216; helo=cio-tnc-pf02.osuad.osu.edu; Authentication-Results: spf=pass (sender IP is 164.107.81.216) smtp.mailfrom=cantor.2@osu.edu; X-Forefront-Antispam-Report: CIP:164.107.81.216; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(438002)(199003)(51444003)(189002)(47776003)(50986999)(88552001)(2656002)(6806004)(2171001)(75432002)(2501002)(90282001)(97756001)(46406003)(66066001)(54356999)(87936001)(77156002)(55846006)(89122001)(106116001)(107886001)(46102003)(92566002)(50466002)(86362001)(33656002)(76176999)(62966003)(106466001)(64706001)(23726002)(2950100001)(93346002)(2900100001)(102836002)(2920100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2FFO11HUB045; H:cio-tnc-pf02.osuad.osu.edu; FPR:; SPF:Pass; MLV:sfv; PTR:cio-tnc-pf02.osuad.osu.edu; A:1; MX:1; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BY2FFO11HUB045; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:BY2FFO11HUB045; X-Forefront-PRVS: 046164D5C4 X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:BY2FFO11HUB045; X-OriginatorOrg: osu.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Jan 2015 20:00:00.7910 (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.216] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2FFO11HUB045 Archived-At: Subject: Re: [VoT] A modest proposal to replace LOA X-BeenThere: vot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Vectors of Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2015 20:00:10 -0000 > Communicating an identity (attributes) is not the goal of 800-63. I thin= k > it makes perfect sense to consider authentication and the communication o= f > attributes very separately. Then please explain how to communicate the identity of an authenticated sub= ject to somebody else without an attribute (of some kind) to identify them.= That's why they're not separate. The point of the authentication is to co= mmunicate an attribute (or more than one) with some assurance behind it. Sa= me as any other attribute use case. They boil down to the same end goal. > We just disagree here. I concede that attributes are essential for > personalization and authorization decisions at the RP Those are secondary. The primary use case of attributes is to *identify* th= e authenticated subject in the first place. > But if an RP requests attributes that are to be used to make > authorization decisions, the RP should only request such attributes from > providers it trusts and considers to be authoritative. And why does that same logic not hold for the attributes that communicate t= he identity? > It does not make any > sense for an attribute provider to offer the same attribute at varying > levels of assurance. Sure it does. If not, it makes no more sense for an identity provider to of= fer authentication at different levels. > The way I read this is that your definition of LOA is different than mine= . > You seem to focus only on the communication of attributes (which is in li= ne > with your stated view that "authentication means nothing to an app") wher= e > I focus only on authentication. If you can tell me how the latter can be communicated without the former, I= 'll concede the point. If not, my argument is that one boils down to the ot= her, so I don't see the point of treating it separately. What I'm arguing i= s that the "assurance" one has in identifiers and other "authentication-rel= ated" attributes is just a special case of assurance in any other attribute= s. Any given attribute has a set of risks associated with its promulgation = and use. That's all I'm trying to say. > But if you are concerned about risk > mitigation then I think that is an excellent place to start finding commo= n > ground. My question to you is, in what way does the communication of any > attribute address any of the threats itemized in 800-63? 800-63 is dealing with the threats to the accurate determination and commun= ication of a specific set of unnamed attributes. That vagueness is why I ha= ve a problem with it. -- Scott From nobody Mon Jan 19 12:19:35 2015 Return-Path: X-Original-To: vot@ietfa.amsl.com Delivered-To: vot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 609251B2C42 for ; Mon, 19 Jan 2015 12:19:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 ZmTb55cl1O2f for ; Mon, 19 Jan 2015 12:19:30 -0800 (PST) Received: from mail-oi0-f44.google.com (mail-oi0-f44.google.com [209.85.218.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D20B1B2C3F for ; Mon, 19 Jan 2015 12:19:30 -0800 (PST) Received: by mail-oi0-f44.google.com with SMTP id a3so4694433oib.3 for ; Mon, 19 Jan 2015 12:19:29 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=lGhJO3dil7cUkSbAkcc16ilHugJ44MvLzqu2ck6Znx8=; b=SN+xFBgqsiOlVJoBakwyDbrLcrGsM6IClu4/7KhFrsg9/FFWhgku/nxRMVW9/Gm/my /p0gv6JMmQE9saPKyG0+l8pknP6yL1cba3Ft5J3HfmJ/UIiZlnm7ZcSxU+fjQIp9x3Hc ugD+0b/h2DBhMwOmnAz8O6OoU38ZHXp5fwSDFLGgfHcB004lfjz4YCi9OEZcPNAxh6cv o03JgUkr/jwRumLU38FHbF1Wt5PLmL4SklfxuJgjVpZu7KteGPQyZExR75Eu5kwENlbX WmijDgJl9f/FMA4A7a2nhatu185pfs3u3lp41PE/6pn8qYiCboHkwN/lVHFK79NYQOUd wydA== X-Gm-Message-State: ALoCoQmR8Byk6FexmgSVREbgM0QX3sVm2Dbw8xgkG8o94VgfifZD1Ce8BOtNc5RnGWvte98LQQgQ MIME-Version: 1.0 X-Received: by 10.60.155.195 with SMTP id vy3mr19502509oeb.62.1421698769770; Mon, 19 Jan 2015 12:19:29 -0800 (PST) Received: by 10.202.66.87 with HTTP; Mon, 19 Jan 2015 12:19:29 -0800 (PST) In-Reply-To: References: Date: Mon, 19 Jan 2015 15:19:29 -0500 Message-ID: From: Peter Alterman To: vot@ietf.org Content-Type: multipart/alternative; boundary=089e0102dc32266f41050d070a6e Archived-At: Subject: Re: [VoT] vot Digest, Vol 5, Issue 16 X-BeenThere: vot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Vectors of Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2015 20:19:33 -0000 --089e0102dc32266f41050d070a6e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =E2=80=8BWell, friends, we seem to be at it again: the infamous Rat Hole of identity vs. attribute. I, for one, am getting tired of the same old rodomontade. Right now and for the forseeable future there are attributes that by general agreement are part of establishing identity and there are other (extended) attributes that are part of establishing rights or privileges. Note I said "by general agreement" but I seem to remember ANSI addressing this issue a couple of years ago and ISO doing so currently. None of the discussion I'm seeing on this thread suggests any useful reason to dive back into the Rat Hole as it does nothing to address the core algorithm, which is trust =3D 1/risk. Peter ------------------------------------------------------------ Peter Alterman, Ph.D. Chief Operating Officer SAFE-BioPharma Association cell: 301-943-7452 On Mon, Jan 19, 2015 at 3:03 PM, wrote: > Send vot mailing list submissions to > vot@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/vot > or, via email, send a message with subject or body 'help' to > vot-request@ietf.org > > You can reach the person managing the list at > vot-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of vot digest..." > > Today's Topics: > > 1. Re: A modest proposal to replace LOA (Cantor, Scott) > > > ---------- Forwarded message ---------- > From: "Cantor, Scott" > To: "Jones, Mark B" , Eric Goodman < > Eric.Goodman@ucop.edu>, "vot@ietf.org" > Cc: > Date: Mon, 19 Jan 2015 19:59:57 +0000 > Subject: Re: [VoT] A modest proposal to replace LOA > > Communicating an identity (attributes) is not the goal of 800-63. I > think > > it makes perfect sense to consider authentication and the communication > of > > attributes very separately. > > Then please explain how to communicate the identity of an authenticated > subject to somebody else without an attribute (of some kind) to identify > them. That's why they're not separate. The point of the authentication i= s > to communicate an attribute (or more than one) with some assurance behind > it. Same as any other attribute use case. They boil down to the same end > goal. > > > We just disagree here. I concede that attributes are essential for > > personalization and authorization decisions at the RP > > Those are secondary. The primary use case of attributes is to *identify* > the authenticated subject in the first place. > > > But if an RP requests attributes that are to be used to make > > authorization decisions, the RP should only request such attributes fro= m > > providers it trusts and considers to be authoritative. > > And why does that same logic not hold for the attributes that communicate > the identity? > > > It does not make any > > sense for an attribute provider to offer the same attribute at varying > > levels of assurance. > > Sure it does. If not, it makes no more sense for an identity provider to > offer authentication at different levels. > > > The way I read this is that your definition of LOA is different than > mine. > > You seem to focus only on the communication of attributes (which is in > line > > with your stated view that "authentication means nothing to an app") > where > > I focus only on authentication. > > If you can tell me how the latter can be communicated without the former, > I'll concede the point. If not, my argument is that one boils down to the > other, so I don't see the point of treating it separately. What I'm argui= ng > is that the "assurance" one has in identifiers and other > "authentication-related" attributes is just a special case of assurance i= n > any other attributes. Any given attribute has a set of risks associated > with its promulgation and use. That's all I'm trying to say. > > > But if you are concerned about risk > > mitigation then I think that is an excellent place to start finding > common > > ground. My question to you is, in what way does the communication of a= ny > > attribute address any of the threats itemized in 800-63? > > 800-63 is dealing with the threats to the accurate determination and > communication of a specific set of unnamed attributes. That vagueness is > why I have a problem with it. > > -- Scott > > > > _______________________________________________ > vot mailing list > vot@ietf.org > https://www.ietf.org/mailman/listinfo/vot > > --089e0102dc32266f41050d070a6e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

=E2=80=8BWell, friends, we seem to be at it again: the in= famous Rat Hole of identity vs. attribute.

I, for one, am getting tired of the same old rodomont= ade.

Right now and for = the forseeable future there are attributes that by general agreement are pa= rt of establishing identity and there are other (extended) attributes that = are part of establishing rights or privileges. Note I said "by general= agreement" but I seem to remember ANSI addressing this issue a couple= of years ago and ISO doing so currently.
=C2=A0
None of the discussion I'm seeing on this thread = suggests any useful reason to dive back into the Rat Hole as it does nothin= g to address the core algorithm, which is trust =3D 1/risk.

Peter


-----------------------------------------------= -------------
Peter Alterman, Ph.D.
Chief Operating Offic= er
SAFE-BioPharma Association
cell: 301-943-7452

<= /div>

On Mon, Jan 19, 2015 at 3:03 PM, <vot-= request@ietf.org> wrote:
Se= nd vot mailing list submissions to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 vot@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/vot
or, via email, send a message with subject or body 'help' to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 vot-req= uest@ietf.org

You can reach the person managing the list at
=C2=A0 =C2=A0 =C2=A0 =C2=A0 vot-owner= @ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of vot digest..."

Today's Topics:

=C2=A0 =C2=A01. Re: A modest proposal to replace LOA (Cantor, Scott)


---------- Forwarded message ----------
From:=C2=A0"Cantor,= Scott" <cantor.2@osu.edu&g= t;
To:=C2=A0"Jones, Mark B" <Mark.B.Jones@uth.tmc.edu>, Eric Goodman <Eric.Goodman@ucop.edu>, "vot@ietf.org" <vot@ietf.org>
Cc:=C2=A0
Date:=C2=A0Mon, 19 Jan 2015 1= 9:59:57 +0000
Subject:=C2=A0Re: [VoT] A modest proposal to replace LOA> Communicating an identity (attributes) is not the goal of 800-63.=C2= =A0 I think
> it makes perfect sense to consider authentication and the communicatio= n of
> attributes very separately.

Then please explain how to communicate the identity of an authenticated sub= ject to somebody else without an attribute (of some kind) to identify them.= =C2=A0 That's why they're not separate. The point of the authentica= tion is to communicate an attribute (or more than one) with some assurance = behind it. Same as any other attribute use case. They boil down to the same= end goal.

> We just disagree here.=C2=A0 I concede that attributes are essential f= or
> personalization and authorization decisions at the RP

Those are secondary. The primary use case of attributes is to *identify* th= e authenticated subject in the first place.

> But if an RP requests attributes that are to be used to make
> authorization decisions, the RP should only request such attributes fr= om
> providers it trusts and considers to be authoritative.

And why does that same logic not hold for the attributes that communicate t= he identity?

>=C2=A0 It does not make any
> sense for an attribute provider to offer the same attribute at varying=
> levels of assurance.

Sure it does. If not, it makes no more sense for an identity provider to of= fer authentication at different levels.

> The way I read this is that your definition of LOA is different than m= ine.
> You seem to focus only on the communication of attributes (which is in= line
> with your stated view that "authentication means nothing to an ap= p") where
> I focus only on authentication.

If you can tell me how the latter can be communicated without the former, I= 'll concede the point. If not, my argument is that one boils down to th= e other, so I don't see the point of treating it separately. What I'= ;m arguing is that the "assurance" one has in identifiers and oth= er "authentication-related" attributes is just a special case of = assurance in any other attributes. Any given attribute has a set of risks a= ssociated with its promulgation and use. That's all I'm trying to s= ay.

>=C2=A0 But if you are concerned about risk
> mitigation then I think that is an excellent place to start finding co= mmon
> ground.=C2=A0 My question to you is, in what way does the communicatio= n of any
> attribute address any of the threats itemized in 800-63?

800-63 is dealing with the threats to the accurate determination and commun= ication of a specific set of unnamed attributes. That vagueness is why I ha= ve a problem with it.

-- Scott



_______________________________________________
vot mailing list
vot@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/vot


--089e0102dc32266f41050d070a6e-- From nobody Mon Jan 19 15:09:24 2015 Return-Path: X-Original-To: vot@ietfa.amsl.com Delivered-To: vot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 129E11B2D13 for ; Mon, 19 Jan 2015 15:09:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 38NMS1ekeyZm for ; Mon, 19 Jan 2015 15:09:19 -0800 (PST) Received: from mail-yh0-x232.google.com (mail-yh0-x232.google.com [IPv6:2607:f8b0:4002:c01::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B109C1B2CF9 for ; Mon, 19 Jan 2015 15:09:18 -0800 (PST) Received: by mail-yh0-f50.google.com with SMTP id b6so16518157yha.9 for ; Mon, 19 Jan 2015 15:09:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xQhFcGvFhV+E2KAX9nVSciV3vYv8wTJ5HB0g1Yjd4Ug=; b=HsDjXqoes4BHRuaWXnazFCCw7v0aEdsaVAi/+5jZiUcRgKBDtkWSYAYNFZguSKjMnT kWN0Yx9bPFH+OcremfRVPLSXBnEAqL3LMCmQSd4oJK77G3t8NXetRHRkX8aIOsUkoZhc IuJwso5btflJn+Arr7EFxBujCgAW07pS/mXBnH51JFu9xjKDMyg2LBcZyKcJ8Dor3tJj n2agyR624NnhiSd+5tdsYs6JRu4T6HLFu57GaDZzeFyt1jkcGGd7ZFztTM1/UJ+U4VNL Vh/uIuJrgjFwgNj1R23sawkwhi6UnTNXCklDLYIQv0lbdiloDaw9cDLK/f7MdK54NWLJ V/xQ== MIME-Version: 1.0 X-Received: by 10.170.121.76 with SMTP id n73mr10260143ykb.119.1421708957874; Mon, 19 Jan 2015 15:09:17 -0800 (PST) Received: by 10.170.53.15 with HTTP; Mon, 19 Jan 2015 15:09:17 -0800 (PST) In-Reply-To: References: Date: Mon, 19 Jan 2015 18:09:17 -0500 Message-ID: From: Ken Dagg To: Peter Alterman Content-Type: multipart/alternative; boundary=001a1137bf6a688111050d096966 Archived-At: Cc: "vot@ietf.org" Subject: Re: [VoT] vot Digest, Vol 5, Issue 16 X-BeenThere: vot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Vectors of Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2015 23:09:22 -0000 --001a1137bf6a688111050d096966 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Here here Peter - I agree wholeheartedly!!! KeN On Monday, January 19, 2015, Peter Alterman wrote: > > =E2=80=8BWell, friends, we seem to be at it again: the infamous Rat Hole = of > identity vs. attribute. > > I, for one, am getting tired of the same old rodomontade. > > Right now and for the forseeable future there are attributes that by > general agreement are part of establishing identity and there are other > (extended) attributes that are part of establishing rights or privileges. > Note I said "by general agreement" but I seem to remember ANSI addressing > this issue a couple of years ago and ISO doing so currently. > > None of the discussion I'm seeing on this thread suggests any useful > reason to dive back into the Rat Hole as it does nothing to address the > core algorithm, which is trust =3D 1/risk. > > Peter > > > ------------------------------------------------------------ > Peter Alterman, Ph.D. > Chief Operating Officer > SAFE-BioPharma Association > cell: 301-943-7452 > > > On Mon, Jan 19, 2015 at 3:03 PM, > wrote: > >> Send vot mailing list submissions to >> vot@ietf.org >> >> To subscribe or unsubscribe via the World Wide Web, visit >> https://www.ietf.org/mailman/listinfo/vot >> or, via email, send a message with subject or body 'help' to >> vot-request@ietf.org >> >> >> You can reach the person managing the list at >> vot-owner@ietf.org >> >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of vot digest..." >> >> Today's Topics: >> >> 1. Re: A modest proposal to replace LOA (Cantor, Scott) >> >> >> ---------- Forwarded message ---------- >> From: "Cantor, Scott" > > >> To: "Jones, Mark B" > >, Eric >> Goodman > >, "vot@ietf.org >> " > > >> Cc: >> Date: Mon, 19 Jan 2015 19:59:57 +0000 >> Subject: Re: [VoT] A modest proposal to replace LOA >> > Communicating an identity (attributes) is not the goal of 800-63. I >> think >> > it makes perfect sense to consider authentication and the communicatio= n >> of >> > attributes very separately. >> >> Then please explain how to communicate the identity of an authenticated >> subject to somebody else without an attribute (of some kind) to identify >> them. That's why they're not separate. The point of the authentication = is >> to communicate an attribute (or more than one) with some assurance behin= d >> it. Same as any other attribute use case. They boil down to the same end >> goal. >> >> > We just disagree here. I concede that attributes are essential for >> > personalization and authorization decisions at the RP >> >> Those are secondary. The primary use case of attributes is to *identify* >> the authenticated subject in the first place. >> >> > But if an RP requests attributes that are to be used to make >> > authorization decisions, the RP should only request such attributes fr= om >> > providers it trusts and considers to be authoritative. >> >> And why does that same logic not hold for the attributes that communicat= e >> the identity? >> >> > It does not make any >> > sense for an attribute provider to offer the same attribute at varying >> > levels of assurance. >> >> Sure it does. If not, it makes no more sense for an identity provider to >> offer authentication at different levels. >> >> > The way I read this is that your definition of LOA is different than >> mine. >> > You seem to focus only on the communication of attributes (which is in >> line >> > with your stated view that "authentication means nothing to an app") >> where >> > I focus only on authentication. >> >> If you can tell me how the latter can be communicated without the former= , >> I'll concede the point. If not, my argument is that one boils down to th= e >> other, so I don't see the point of treating it separately. What I'm argu= ing >> is that the "assurance" one has in identifiers and other >> "authentication-related" attributes is just a special case of assurance = in >> any other attributes. Any given attribute has a set of risks associated >> with its promulgation and use. That's all I'm trying to say. >> >> > But if you are concerned about risk >> > mitigation then I think that is an excellent place to start finding >> common >> > ground. My question to you is, in what way does the communication of >> any >> > attribute address any of the threats itemized in 800-63? >> >> 800-63 is dealing with the threats to the accurate determination and >> communication of a specific set of unnamed attributes. That vagueness is >> why I have a problem with it. >> >> -- Scott >> >> >> >> _______________________________________________ >> vot mailing list >> vot@ietf.org >> https://www.ietf.org/mailman/listinfo/vot >> >> > --001a1137bf6a688111050d096966 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Here here Peter - I agree wholeheartedly!!! KeN



= On Monday, January 19, 2015, Peter Alterman <palterman@safe-biopharma.org> wrote:

=E2=80=8BWell, friends, we seem t= o be at it again: the infamous Rat Hole of identity vs. attribute.

I, for one, am getting tired = of the same old rodomontade.

Right now and for the forseeable future there are attributes that by = general agreement are part of establishing identity and there are other (ex= tended) attributes that are part of establishing rights or privileges. Note= I said "by general agreement" but I seem to remember ANSI addres= sing this issue a couple of years ago and ISO doing so currently.
=C2=A0
None of the discussion I'= m seeing on this thread suggests any useful reason to dive back into the Ra= t Hole as it does nothing to address the core algorithm, which is trust =3D= 1/risk.

<= /div>
Peter

--------------------------------------------------= ----------
Peter Alterman, Ph.D.
Chief Operating Officer<= br>SAFE-BioPharma Association
cell: 301-943-7452


On Mon, Jan 19, 2015 at 3:03 PM, <vot-request@ietf.org> wr= ote:
Send vot mailing list submissions to=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 vot@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/vot
or, via email, send a message with subject or body 'help' to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 vot-request@ietf.org

You can reach the person managing the list at
=C2=A0 =C2=A0 =C2=A0 =C2=A0 vot-owner@ietf.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of vot digest..."

Today's Topics:

=C2=A0 =C2=A01. Re: A modest proposal to replace LOA (Cantor, Scott)


---------- Forwarded message ----------
From:=C2=A0"Cantor,= Scott" <cantor.2@osu.edu>
To:=C2=A0&= quot;Jones, Mark B" <Mark.B.Jones@uth.t= mc.edu>, Eric Goodman <Eric.Goodman@ucop= .edu>, "vot@ietf.org" <vot@ietf.org>
Cc:=C2=A0
Date:=C2=A0Mon, 19 Jan 2015 19:59:= 57 +0000
Subject:=C2=A0Re: [VoT] A modest proposal to replace LOA
>= ; Communicating an identity (attributes) is not the goal of 800-63.=C2=A0 I= think
> it makes perfect sense to consider authentication and the communicatio= n of
> attributes very separately.

Then please explain how to communicate the identity of an authenticated sub= ject to somebody else without an attribute (of some kind) to identify them.= =C2=A0 That's why they're not separate. The point of the authentica= tion is to communicate an attribute (or more than one) with some assurance = behind it. Same as any other attribute use case. They boil down to the same= end goal.

> We just disagree here.=C2=A0 I concede that attributes are essential f= or
> personalization and authorization decisions at the RP

Those are secondary. The primary use case of attributes is to *identify* th= e authenticated subject in the first place.

> But if an RP requests attributes that are to be used to make
> authorization decisions, the RP should only request such attributes fr= om
> providers it trusts and considers to be authoritative.

And why does that same logic not hold for the attributes that communicate t= he identity?

>=C2=A0 It does not make any
> sense for an attribute provider to offer the same attribute at varying=
> levels of assurance.

Sure it does. If not, it makes no more sense for an identity provider to of= fer authentication at different levels.

> The way I read this is that your definition of LOA is different than m= ine.
> You seem to focus only on the communication of attributes (which is in= line
> with your stated view that "authentication means nothing to an ap= p") where
> I focus only on authentication.

If you can tell me how the latter can be communicated without the former, I= 'll concede the point. If not, my argument is that one boils down to th= e other, so I don't see the point of treating it separately. What I'= ;m arguing is that the "assurance" one has in identifiers and oth= er "authentication-related" attributes is just a special case of = assurance in any other attributes. Any given attribute has a set of risks a= ssociated with its promulgation and use. That's all I'm trying to s= ay.

>=C2=A0 But if you are concerned about risk
> mitigation then I think that is an excellent place to start finding co= mmon
> ground.=C2=A0 My question to you is, in what way does the communicatio= n of any
> attribute address any of the threats itemized in 800-63?

800-63 is dealing with the threats to the accurate determination and commun= ication of a specific set of unnamed attributes. That vagueness is why I ha= ve a problem with it.

-- Scott



_______________________________________________
vot mailing list
vot@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/vot


--001a1137bf6a688111050d096966-- From nobody Mon Jan 19 15:35:05 2015 Return-Path: X-Original-To: vot@ietfa.amsl.com Delivered-To: vot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5F711B2CF9 for ; Mon, 19 Jan 2015 15:35:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 lwgESPMOmSQB for ; Mon, 19 Jan 2015 15:34:59 -0800 (PST) Received: from mta5.uth.tmc.edu (mta5.uth.tmc.edu [129.106.149.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0601C1ACE82 for ; Mon, 19 Jan 2015 15:34:58 -0800 (PST) Received: from pps.filterd (mta5.uth.tmc.edu [127.0.0.1]) by mta5.uth.tmc.edu (8.14.5/8.14.5) with SMTP id t0JNWSDM002488; Mon, 19 Jan 2015 17:34:58 -0600 Received: from uthmail3.uthouston.edu (admin4-6.hsc.uth.tmc.edu [129.106.4.6]) by mta5.uth.tmc.edu with ESMTP id 1s1ahn08bh-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 19 Jan 2015 17:34:58 -0600 Received: from UTHMAIL1.uthouston.edu ([fe80::c1d2:3f6a:4f56:4fa4]) by UTHMAIL3.uthouston.edu ([fe80::fd74:5f7a:1426:e687%22]) with mapi id 14.03.0210.002; Mon, 19 Jan 2015 17:34:57 -0600 From: "Jones, Mark B" To: "Cantor, Scott" , Eric Goodman , "vot@ietf.org" Thread-Topic: [VoT] A modest proposal to replace LOA Thread-Index: AQHQLE3NIVccl7Oe9EyjUXstdR0255y7QHEAgAImvgCABhFfAP//wMgAgABt0oCAAulJQIABwIiA//+/0tA= Date: Mon, 19 Jan 2015 23:34:55 +0000 Message-ID: <38AAF00EA635514CA6667ACA60C7F0A548A0A9A8@UTHMAIL1.uthouston.edu> References: <54B03EE4.3060909@bluepopcorn.net> <38AAF00EA635514CA6667ACA60C7F0A53153A573@UTHMAIL1.uthouston.edu> <54B43AA4.3030005@bluepopcorn.net> <38AAF00EA635514CA6667ACA60C7F0A531547B9C@UTHMAIL1.uthouston.edu> <9846A6064BD102419D06814DD0D78DE1068C80@CIO-TNC-D2MBX02.osuad.osu.edu> <38AAF00EA635514CA6667ACA60C7F0A548A08BE5@UTHMAIL1.uthouston.edu> <9846A6064BD102419D06814DD0D78DE106A329@CIO-TNC-D2MBX02.osuad.osu.edu> In-Reply-To: <9846A6064BD102419D06814DD0D78DE106A329@CIO-TNC-D2MBX02.osuad.osu.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [129.106.149.129] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_002C_01D0340E.3E042570" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2015-01-19_04:2015-01-19,2015-01-19,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1501190244 Archived-At: Subject: Re: [VoT] A modest proposal to replace LOA X-BeenThere: vot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Vectors of Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2015 23:35:02 -0000 ------=_NextPart_000_002C_01D0340E.3E042570 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > > Communicating an identity (attributes) is not the goal of 800-63. I > > think it makes perfect sense to consider authentication and the > > communication of attributes very separately. > > Then please explain how to communicate the identity of an authenticated > subject to somebody else without an attribute (of some kind) to identify > them. That's why they're not separate. The point of the authentication is to > communicate an attribute (or more than one) with some assurance behind it. > Same as any other attribute use case. They boil down to the same end goal. > [Jones, Mark B] You can't communicate identity without one or more attributes. I disagree that the point of authentication is to communicate attributes. The purpose of authentication, in my opinion, is to connect a remote entity that is known to the authentication provider with a RP. Then the communication of attributes follows. > > But if an RP requests attributes that are to be used to make > > authorization decisions, the RP should only request such attributes > > from providers it trusts and considers to be authoritative. > > And why does that same logic not hold for the attributes that communicate > the identity? > [Jones, Mark B] If you are not making decisions based on the values then, authoritative or not, whatever the provider has is likely good enough. > > It does not make any > > sense for an attribute provider to offer the same attribute at varying > > levels of assurance. > > Sure it does. If not, it makes no more sense for an identity provider to offer > authentication at different levels. > [Jones, Mark B] We must be miscommunicating on this. A provider is not going to provide different RPs different values depending on the LOA requested. > > The way I read this is that your definition of LOA is different than mine. > > You seem to focus only on the communication of attributes (which is in > > line with your stated view that "authentication means nothing to an > > app") where I focus only on authentication. > > If you can tell me how the latter can be communicated without the former, > I'll concede the point. If not, my argument is that one boils down to the > other, so I don't see the point of treating it separately. What I'm arguing is > that the "assurance" one has in identifiers and other "authentication- > related" attributes is just a special case of assurance in any other attributes. > Any given attribute has a set of risks associated with its promulgation and > use. That's all I'm trying to say. > [Jones, Mark B] Isn't this the extreme privacy preserving use case for Shibboleth? Isn't this the library use case minus the affiliation attribute? > > But if you are concerned about risk > > mitigation then I think that is an excellent place to start finding > > common ground. My question to you is, in what way does the > > communication of any attribute address any of the threats itemized in 800- > 63? > > 800-63 is dealing with the threats to the accurate determination and > communication of a specific set of unnamed attributes. That vagueness is > why I have a problem with it. > [Jones, Mark B] 800-63 does not specify any requirements for communicating attributes to RPs. It specifies identity proofing for the purpose of registration only. " The registration and identity proofing processes are designed based on the required assurance level, to ensure that the RA/CSP knows the true identity of the Applicant." ------=_NextPart_000_002C_01D0340E.3E042570 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITvjCCBDYw ggMeoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRy dXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZ QWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wMDA1MzAxMDQ4MzhaFw0yMDA1MzAxMDQ4Mzha MG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3Qg RXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3Qw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC39xoz5vIABC054E5b7R+8bA/Ntfojts7e mxEzl6QpTH2Tn71KvJPtAxrjj8/lbVBa1pcplFqAsEl62y6V/bjKvzc4LR4+kUGtcFbH8E8/6DKe dMrIkFTpxl8PeJ2aQDwOrGGqXhSPnoehalDc15pOrwWzpnGUnHGzUGAKxxOdOAeGAqjpqGkmGJCr TLBPI6s6T4TY386f4Wlvu9dC12tE5Met7m1BX3JacQg3s3llpFmglDf3AC8NwpJy2tA4ctsUqEXE XSp9t7TWxO6szRNEt8kr3UMAJfphuWlqWCMRt6czj1Z1WfXNKddGtworZbbTQm8Vsrh7++/pXVPV NFonAgMBAAGjgdwwgdkwHQYDVR0OBBYEFK29mHo0tCb3+sQmVO8DveAky1QaMAsGA1UdDwQEAwIB BjAPBgNVHRMBAf8EBTADAQH/MIGZBgNVHSMEgZEwgY6AFK29mHo0tCb3+sQmVO8DveAky1QaoXOk cTBvMQswCQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0 IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 ggEBMA0GCSqGSIb3DQEBBQUAA4IBAQCwm+CFJcLWI+IPlgaSnUGYnNmEeYHZHlsUByM2ZY+w2He7 rEFsR2CDUbD5Mj3n/PYmE8eAFqW/WvyHz3h5iSGa4kwHCoY1vPLeUcTSlrfcfk7ucP0cOesMAlEU LY69FuDB30Z15ySt7PRCtIWTcBBnup0GNUoY0yt6zFFCoXpj0ea7ocUrwja+Ew3mvWN+eXunCQ1A q2rdj4rD9vaMGkIFUdRF9Z+nYiFoFSBDPJnnfL0k2KmRF3OIP1YbMTgYtHEPms3IDp6OLhvhjJiD yx8x8URMxgRzSXZgD8f4vReAay7pzEwOWpp5DyAKLtWeYyYeVZKU2IIXWnvQvMePToYEMIIEnTCC A4WgAwIBAgIQND3pK6wnNP+PyzSU+8xwVDANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEU MBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3 b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTA1MDYwNzA4MDkxMFoX DTIwMDUzMDEwNDgzOFowga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2Fs dCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0 cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRo ZW50aWNhdGlvbiBhbmQgRW1haWwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCyOYWk 8n2rQTtiRjeuzcFgdbw5ZflKGkeiucxIzGqY1U01GbmkQuXOSeKKLx580jEHx060g2SdLinVomTE hb2FUTV5pE5okHsceqSSqBfymBXyk8zJpDKVuwxPML2YoAuL5W4bokb6eLyib6tZXqUvz8rabaov 66yhs2qqty5nNYt54R5piOLmRs2gpeq+C852OnoOm+r82idbPXMfIuZIYcZM82mxqC4bttQxICy8 goqOpA6l14lD/BZarx1x1xFZ2rqHDa/68+HC8KTFZ4zW1lQ63gqkugN3s2XI/R7TdGKqGMpokx6h hX71R2XL+E1XKHTSNP8wtu72YjAUjCzrAgMBAAGjgfQwgfEwHwYDVR0jBBgwFoAUrb2YejS0Jvf6 xCZU7wO94CTLVBowHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59MA4GA1UdDwEB/wQEAwIB BjAPBgNVHRMBAf8EBTADAQH/MBEGA1UdIAQKMAgwBgYEVR0gADBEBgNVHR8EPTA7MDmgN6A1hjNo dHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vQWRkVHJ1c3RFeHRlcm5hbENBUm9vdC5jcmwwNQYIKwYB BQUHAQEEKTAnMCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3 DQEBBQUAA4IBAQABvJzjYyiw8zEBwt973WKgAZ0jMQ+cknNTUeofTPrWn8TKL2d+eDMPdBa5kYeR 9Yom+mRwANge+QsEYlCHk4HU2vUj2zS7hVa0cDRueIM3HoUcxREVkl+HF72sav3xwtHMiV+xfPA+ UfI183zsYJhrOivg79+zfYbrtRv1W+yifJgT1wBQudEtc94DeHThBYUxXsuauZ2UxrmUN3Vy3ET7 Z+jw+iUeUqfaJelH4KDHPKBOsQo2+3dIn++Xivu0/uOUFKiDvFwtP9JgcWDuwnGCDOmINuPaILSj oGyqlku4gI51ykkH9jsUut/cBdmf2+Cy5k2geCbn5y1uf1/GHogVMIIFJTCCBA2gAwIBAgIQRIUc GfetDxT4xHWGNMR0xzANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVU MRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3Jr MSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmly c3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0xMDEyMDIwMDAwMDBaFw0yMDA1 MzAxMDQ4MzhaMIGWMQswCQYDVQQGEwJVUzFBMD8GA1UEChM4VGhlIFVuaXZlcnNpdHkgb2YgVGV4 YXMgSGVhbHRoIFNjaWVuY2UgQ2VudGVyIGF0IEhvdXN0b24xRDBCBgNVBAMTO1RoZSBVbml2ZXJz aXR5IG9mIFRleGFzIEhlYWx0aCBTY2llbmNlIENlbnRlciBhdCBIb3VzdG9uIENBMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxElj8A/NxSnbcaHKOvWlDt5+EbJMPZFayMmRcR5BbEqw M9PLQPTH1yJIZp+7Afgi6CZ/GrJcOEIRsfP43H3VK5O5FI6zIT6ZEEjj+huZ0hWey6Cg/ZNU22Mr XXCGEc0W4afqSXNX2mkck2oQW3xrDTaifCWBFQDki+k5d8wKQ2buk/aIFJO0qomzxq1cdJqAS/sF PWR3aRdJrn5IsjZeDsnsWZFpKCRiAybgcogM0f2mWDLATusRoL41DiOlJfH22NObHcFTQmsoAnXj X+FwJwdZ5H+kiiUCH9tXOHdPyKOoQoBqg+mdkCb4wviJsVTrq4lffBGe+xyeK2dlYngQSQIDAQAB o4IBUzCCAU8wHwYDVR0jBBgwFoAUiYJnfcSdJnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFJkX0AQh Sm6R8Ydeb3ZvO93EMh4gMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEAMBkGA1Ud IAQSMBAwDgYMKwYBBAGyMQECAiQFMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRy dXN0LmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQG CCsGAQUFBwEBBGgwZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFk ZFRydXN0Q2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNv bTANBgkqhkiG9w0BAQUFAAOCAQEAKqKCLV43+zEwBp/AHeelxnJikiO6zfHH7lNSvtwBPyGm4ZuI v6WHl669XQpMLcUxy8b0B8gHZ00AA+mZ7r2YP7HrUiuTEWssdA859PYHeIulfBfLhSP28On7C1Mx aODD9UQtj1j3NUGCy2kCGB2xupUjEXtNWSTgEGWhMiv5V+EvjLEns59Rpm5BHWgsycFOSyztjJYQ kRIFx3Yi6IX5b7s+lxMt96yVwaatlI+xMWPJpxeWlBzq/nIhPfREJmKf0RzZh58Gi6TnIPjmSsIV BZJhUxdTIJkfaJkajOy539WRMM9k04gBH4ZIFd2VwqwB9aZl27LgfvYOeeoswzPpRzCCBbYwggSe oAMCAQICEQC2CAUBCn9+NClEHZu5j+aOMA0GCSqGSIb3DQEBBQUAMIGWMQswCQYDVQQGEwJVUzFB MD8GA1UEChM4VGhlIFVuaXZlcnNpdHkgb2YgVGV4YXMgSGVhbHRoIFNjaWVuY2UgQ2VudGVyIGF0 IEhvdXN0b24xRDBCBgNVBAMTO1RoZSBVbml2ZXJzaXR5IG9mIFRleGFzIEhlYWx0aCBTY2llbmNl IENlbnRlciBhdCBIb3VzdG9uIENBMB4XDTE0MDkxNTAwMDAwMFoXDTE1MDkxNTIzNTk1OVowgbMx DjAMBgNVBBETBTc3MDMwMRwwGgYDVQQKExNVVEhFQUxUSCBOT04tRVNDUk9XMRQwEgYDVQQJEws3 MDAwIEZhbm5pbjEOMAwGA1UECBMFVGV4YXMxEDAOBgNVBAcTB0hvdXN0b24xCzAJBgNVBAYTAlVT MRUwEwYDVQQDEwxNYXJrIEIgSm9uZXMxJzAlBgkqhkiG9w0BCQEWGG1hcmsuYi5qb25lc0B1dGgu dG1jLmVkdTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAIsD9b8/H96eboYROkoZaA2/ QEXxNACieGhSr+CQzUfSlhWcL4M69uA938pqeKvzGWWJBEkb46tzTMhnbWuvbNfqUT+PBShIvkSr ndy7BE0ozkKjFVU/6jTsj2klnDyfq3wn0+GA/e+FTzYaDdj7ts6fij74De2GDPdNlVJa6uzzMaTd 7cS3T87ht0Yr03NStJRAl+IdN4cpJ9+Xn14NG7PnlZy5fyXDWM88kd/guUpdfK6XIjEud01vjDco NpN3ihRXl8LnEP700dosa2r897emtg8XJaSnw4k/GJUfSuGgW2rbYpUOyR9JPzZQMlLPqptNRjF5 WAzp2neDcl2fb0kCAwEAAaOCAd4wggHaMB8GA1UdIwQYMBaAFJkX0AQhSm6R8Ydeb3ZvO93EMh4g MB0GA1UdDgQWBBTk8/IYWxQfOajleb+QbNEs5R1HCzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/ BAIwADAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwQwYDVR0gBDwwOjA4BgwrBgEEAbIx AQICJAUwKDAmBggrBgEFBQcCARYaaHR0cDovL3d3dy51dGgudG1jLmVkdS9jcHMwXgYDVR0fBFcw VTBToFGgT4ZNaHR0cDovL2NybC51dGgudG1jLmVkdS9UaGVVbml2ZXJzaXR5b2ZUZXhhc0hlYWx0 aFNjaWVuY2VDZW50ZXJhdEhvdXN0b25DQS5jcmwwgZAGCCsGAQUFBwEBBIGDMIGAMFkGCCsGAQUF BzAChk1odHRwOi8vY3J0LnV0aC50bWMuZWR1L1RoZVVuaXZlcnNpdHlvZlRleGFzSGVhbHRoU2Np ZW5jZUNlbnRlcmF0SG91c3RvbkNBLmNydDAjBggrBgEFBQcwAYYXaHR0cDovL29jc3AudXRoLnRt Yy5lZHUwIwYDVR0RBBwwGoEYbWFyay5iLmpvbmVzQHV0aC50bWMuZWR1MA0GCSqGSIb3DQEBBQUA A4IBAQCB5ypKawPDBa1lkt5Kv3priYCzwt5kUJA9MaQArIbAnpH2OoPnaUcnaGFNhgbm7TMJmC4V spP7uBsrtUGzywRe7AXwrRLX5WKxT4KKDdIonoftE0zVJGCP8SelTnlCOYk1/aa7blWsLtEan/AG sgJwFo8IjrWI95DqimKhH7qOU5KIbPovEksE6NFE0EcHdBLDEWmH1iCaZvl2qNJyrERtVYxG7wTA UTlMG6Tr2tkm1f6NJizvUSCaxCVVpZ4QSHYb6edNYI25w/D2yoDeGCvyq9lyRA/h5QooHdxu+8tG JZpxA9fSKDewjKNIJoirGOhrLM9t8/NxXw40sd7vZdTZMYIEFDCCBBACAQEwgawwgZYxCzAJBgNV BAYTAlVTMUEwPwYDVQQKEzhUaGUgVW5pdmVyc2l0eSBvZiBUZXhhcyBIZWFsdGggU2NpZW5jZSBD ZW50ZXIgYXQgSG91c3RvbjFEMEIGA1UEAxM7VGhlIFVuaXZlcnNpdHkgb2YgVGV4YXMgSGVhbHRo IFNjaWVuY2UgQ2VudGVyIGF0IEhvdXN0b24gQ0ECEQC2CAUBCn9+NClEHZu5j+aOMAkGBSsOAwIa BQCgggI8MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDExOTIz MzQ1NlowIwYJKoZIhvcNAQkEMRYEFHAcd4tqK7MXXOohmXdWRinOYu4FMFsGCSqGSIb3DQEJDzFO MEwwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G CCqGSIb3DQMCAgEoMAcGBSsOAwIaMIG9BgkrBgEEAYI3EAQxga8wgawwgZYxCzAJBgNVBAYTAlVT MUEwPwYDVQQKEzhUaGUgVW5pdmVyc2l0eSBvZiBUZXhhcyBIZWFsdGggU2NpZW5jZSBDZW50ZXIg YXQgSG91c3RvbjFEMEIGA1UEAxM7VGhlIFVuaXZlcnNpdHkgb2YgVGV4YXMgSGVhbHRoIFNjaWVu Y2UgQ2VudGVyIGF0IEhvdXN0b24gQ0ECEQC2CAUBCn9+NClEHZu5j+aOMIG/BgsqhkiG9w0BCRAC CzGBr6CBrDCBljELMAkGA1UEBhMCVVMxQTA/BgNVBAoTOFRoZSBVbml2ZXJzaXR5IG9mIFRleGFz IEhlYWx0aCBTY2llbmNlIENlbnRlciBhdCBIb3VzdG9uMUQwQgYDVQQDEztUaGUgVW5pdmVyc2l0 eSBvZiBUZXhhcyBIZWFsdGggU2NpZW5jZSBDZW50ZXIgYXQgSG91c3RvbiBDQQIRALYIBQEKf340 KUQdm7mP5o4wDQYJKoZIhvcNAQEBBQAEggEAd4A4vgt8836wtui7v58+pf1xQ1ttX+jrIWqI/3M2 +Wy/8LO+TcccssL3UE3oJJTHnKmb1S71ITC1EUi4e0w1xiE69yawOZQMsbZMzcYo0aGJy4gSfV4f 33+QBtNimgzyoWT11JPssRmb6JC0YLomB/lDUGx7qJTf7Qgc8yZM1HRWRgGLnSSw/jXF094ZPZIy IKPidFhk3sk0ZP1JeTl4VvxcPcvxfJIimKQZocmIq672tEbKkPDtmk9UpgafyGzl+xLkHNg5awzB ff4ktCMuU8IFvwoe/2gh0ptJBAlOsX4Xt6PyYW74T+8YSuTOgsffk9/6CHpt95/sLWrGidqOfQAA AAAAAA== ------=_NextPart_000_002C_01D0340E.3E042570-- From nobody Wed Jan 21 07:48:56 2015 Return-Path: X-Original-To: vot@ietfa.amsl.com Delivered-To: vot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A7E71A1AE7 for ; Wed, 21 Jan 2015 07:48:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.001 X-Spam-Level: *** X-Spam-Status: No, score=3.001 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MANGLED_MARKET=2.3, SPF_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 srFbqjg7uyvb for ; Wed, 21 Jan 2015 07:48:42 -0800 (PST) Received: from mail-yh0-x22e.google.com (mail-yh0-x22e.google.com [IPv6:2607:f8b0:4002:c01::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF4C71A1AE8 for ; Wed, 21 Jan 2015 07:48:40 -0800 (PST) Received: by mail-yh0-f46.google.com with SMTP id c41so1824233yho.5 for ; Wed, 21 Jan 2015 07:48:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uNgKBedcLja16HM6CdQtS4yzY5FgTSid5qlqiOl+oIE=; b=AOG6eyIr4kj/e70exq31nWSOENLiAnj878Su/NAkdMGMyxmLrYIh/cnJzg3KQTlh+d C/zkjvCU2EDiAWTMV+65vtOtVeJI8ZxlUpKjDC5FyQ3IfiaFVV4mBGDY1hxr62Okk+kS 6Kwu4fEYPmjn7JYhkvoXmNmWZc9Zc5b+iCCiBhpdtmZXoV3o7p2il6W1ZAHO4N7LKcYc qshlBJnKCCEBQCR4J+/nCDK7TI3B0YD9hVgOJ0/3mT/ycG1MpPMVf8KXaangmhiMnANt 8ypwL50K0evGal7aNDeQghrLvJpajGjTX1ZnLCHniEg1kn0edg5f3h54OjlEZzeh/7Qm bZXg== MIME-Version: 1.0 X-Received: by 10.236.20.113 with SMTP id o77mr24564074yho.183.1421855320081; Wed, 21 Jan 2015 07:48:40 -0800 (PST) Received: by 10.170.53.15 with HTTP; Wed, 21 Jan 2015 07:48:40 -0800 (PST) In-Reply-To: References: Date: Wed, 21 Jan 2015 10:48:40 -0500 Message-ID: From: Ken Dagg To: Peter Alterman Content-Type: multipart/alternative; boundary=089e01634dda468cd0050d2b7d77 Archived-At: Cc: "vot@ietf.org" Subject: Re: [VoT] vot Digest, Vol 5, Issue 6 X-BeenThere: vot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Vectors of Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 15:48:50 -0000 --089e01634dda468cd0050d2b7d77 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Peter, It has taken me a while to get the time to read and reflect on what is contained in your email. Having finally thought about it, and the rest of the thread, I must say bravo! I believe that I agree fully with you: "the greatest opportunity open to us is to find a way to normalize all the various community policies and practices so that RPs can assess whether assertions issued under one community's metrics align with their adopted risk mitigation requirements. I think that has to be addressed in the context of how effective a particular mitigation action is on a recognized threat vector." If I am reading this correctly I think that you are saying is: how can community 2 understand the risk mitigation processes undertaken by community 1 so that it (community 2) can use the assertion made by community 1 as one (possibly the sole) of the risk mitigation actions it requires to allow some action. In this context, 800-63 defines what the U.S. Federal Government expects to have been done in order to accept assertions. In my opinion, it is up to other communities to describe their specific requirements to accept assertions and then compare and contrast those requirements to 800-63. Once that analysis is completed these other communities can make the decision as to whether they will accept assertions based on 800-63. Is there a normalized set of assertion requirements? I don't know. There are a few communities that have described their requirements but, in my opinion, I am not sure how easy it is to compare and contrast these descriptions In a manner that might generate a normalized set. This might be a fantastic Masters degree analysis that some enterprising student might undertake. Or, if some federation could find the funding, that a consultant could undertake. Ken On Tuesday, January 13, 2015, Peter Alterman wrote: > =E2=80=8BHappy new year to you all. I've been reading the mail but unabl= e to > break away long enough to comment until now. As I read it, the issue on t= he > table is how to express trustworthiness. > > If Abbie was here he'd point you all to the one-to-one correlation betwee= n > trust and threat/threat vector mitigation.=E2=80=8B I recommend to you th= e Third > Deliverable of the OASIS Trust Elevation TC - link provided upon > demonstration of curiosity ;-) > > An RP trusts an external assertion of identity (or even extended > attributes) to the extent that the assertion is created and/or can be > verified to a predetermined degree of threat/risk mitigation. This degree > is baked into policy or contract or some other pre-existing agreement > (think banking regulations, etc.) and is locally determined based upon > local considerations, e.g., no global standard is appropriate. So far as= I > can see, vectors of trust are the same thing as the threats and threat > vectors that are enumerated in ISO 29115 and other places, not least of > which are controls in NIST 800-53-4 and in ISO 27001/2. I really don't se= e > the vectors as anything different from these and considering > trustworthiness as the inverse of threat in this context is pretty much > what everybody seems to be saying. > > If we just use 29115 as our baseline of threats and threat vectors, there > are roughly a dozen or so of them associated with authentication of > identity assertion. I don't think any of us believe that a > twelve-dimensional assertion is practically viable, even if we could agre= e > on a common metric for degree of threat mitigation (fat chance that). Thi= s > has also already been addressed by the community: think of the factor > model, one to four factors (the fourth is context, which may be expressed > as "Where or when you are," according to our colleagues). What this does = is > boil down the trust/threat algorithm to no more than four dimensions and > shifts the discussion to the aforementioned conundrum, e.g., how to > evaluate and rate the degree of threat mitigation. Various communities ha= ve > developed policies and practices to address this question, the most recen= t > of which, I think, is EU Regulation 910/2014 (eIDAS). > > IMO, the greatest opportunity open to us is to find a way to normalize al= l > the various community policies and practices so that RPs can assess wheth= er > assertions issued under one community's metrics align with their adopted > risk mitigation requirements. I think that has to be addressed in the > context of how effective a particular mitigation action is on a recognize= d > threat vector. I would be most interested in your thoughts on that > problem. > > regards, > > Peter > > ------------------------------------------------------------ > Peter Alterman, Ph.D. > Chief Operating Officer > SAFE-BioPharma Association > cell: 301-943-7452 > > > On Tue, Jan 13, 2015 at 8:19 AM, > wrote: > >> Send vot mailing list submissions to >> vot@ietf.org >> >> To subscribe or unsubscribe via the World Wide Web, visit >> https://www.ietf.org/mailman/listinfo/vot >> or, via email, send a message with subject or body 'help' to >> vot-request@ietf.org >> >> >> You can reach the person managing the list at >> vot-owner@ietf.org >> >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of vot digest..." >> >> Today's Topics: >> >> 1. Re: capturing the threads of the discussion (Robin Wilton) >> 2. VoT wiki (Steve Olshansky) >> >> >> ---------- Forwarded message ---------- >> From: Robin Wilton > > >> To: Colin Wallis > > >> Cc: Jim Fenton > >, "vot@ietf.org >> " > > >> Date: Tue, 13 Jan 2015 09:31:59 +0000 >> Subject: Re: [VoT] capturing the threads of the discussion >> Oops - I'd forgotten about the wiki: apologies! Yes, I think that's the >> place to start... >> >> R >> >> Robin Wilton >> >> Technical Outreach Director - Identity and Privacy >> >> On 12 Jan 2015, at 23:43, "Colin Wallis" > > wrote: >> >> Well as Steve O pointed out in this attached email in November, the >> wiki set up for this work might be a place to start.. >> >> There may be some jiggery pokery to get the folks on this list who want >> to contribute (who were not attendees at Utrecht) access rights, but it >> would seem to me to be the obvious starter option for a repository. >> >> Cheers >> >> Colin >> >> PS: BTW this is a good discussion and indeed an opportunistic time to >> bring it together since so much of what Justin, Jim, Scott, Ken, Steve W= , >> Mark et al have commented recently is complementary (well at least not >> completely contradictory or orthogonal) so let=E2=80=99s grab it! >> >> >> >> *From:* vot [mailto:vot-bounces@ietf.org >> ] *On Behalf Of *R= obin >> Wilton >> *Sent:* Tuesday, 13 January 2015 11:22 a.m. >> *To:* Jim Fenton >> *Cc:* vot@ietf.org >> *Subject:* Re: [VoT] capturing the threads of the discussion >> >> >> >> Thanks Jim, >> >> >> >> I won't give a substantive response here; just to note that I think it's >> worth considering a repository so that we can capture 'static' versions = of >> any straw-man docs, to complement what we it into the mail thread... >> >> >> >> Sorry to be brief at this stage - just tying up some loose ends before a= n >> absence from the office. >> >> >> >> R >> >> Robin Wilton >> >> >> >> Technical Outreach Director - Identity and Privacy >> >> >> On 12 Jan 2015, at 21:45, "Jim Fenton" > > wrote: >> >> Maybe I should be breaking these apart as Robin suggests, but for now >> I'll keep this in one reply: >> >> On 1/12/15 6:06 AM, Robin Wilton wrote: >> >> This thread raises several important topics=E2=80=A6 just as a practical= matter, >> it might be worth trying to spin some of them off separately, so that we >> address them all, and minimise the risk of talking at cross-purposes. >> >> It feels like it would be worth trying to put together some *very short* >> straw-man docs/pages/paragraphs to try and get a consensus version on >> specific points, so that we avoid re-hashing the same arguments/discussi= ons >> over time, or at least have something we can refer to - and amend if >> necessary. I think this is aiming at the same end-point as Steve=E2=80= =99s request >> for a statement of requirements, but will ensure we=E2=80=99re expressin= g our >> requirements in a consistent set of terms. >> >> >> >> By the looks of it, these would make for a good starting point (I >> think the answers to most of these are implicit in various people=E2=80= =99s >> contributions to the thread=E2=80=A6 but that doesn=E2=80=99t mean every= one agrees ;^) ): >> >> >> >> 1 - what do we mean by authentication and authorisation? Are there >> other decisions (e.g. access control, entitlement) which need to be call= ed >> out explicitly? This reflects the purpose of Justin=E2=80=99s questions. >> Classically, the reason for authenticating a user is to answer a yes/no >> question (is this the person to whom this credential was originally >> issued); if yes, what do I want to do about it (at which point the furth= er >> entitlements are usually determined by retrieving a user profile, ACL or >> whatever)? >> >> >> Access control and entitlement as distinct from authorisation? Is there = a >> distinction, or are people just using different terminology? >> >> I think of authentication as providing more than a yes/no answer: it >> provides an identifier. If the relying party has enough information >> (perhaps on the basis of previous interactions) to authorize something w= ith >> just that, fine. Otherwise some attributes are needed to make an >> authorisation decision. >> >> >> However, as we know, these days access control and entitlement >> decisions also need to be made on the basis of input other than classic >> credentials, and that=E2=80=99s one of the two cores of this discussion,= I believe. >> >> >> Example of an "input other than classic credentials"? >> >> >> >> >> 2 - what=E2=80=99s the classic lifecycle of a credential - i.e. a arte= fact >> intended to provide evidence in support of an assertion of identity. (e.= g. >> registration/verification/enrolment, credential issue, credential >> presentation/authentication, credential amendment/revocation/destruction= =E2=80=A6)? >> >> >> Credential is another of those tricky words. Sometimes it means the same >> as an authentication token. Sometimes it has some attributes bound to it= , >> which means it has both an authentication and attribute provision flavor= to >> it. I find it simpler to talk about tokens, where one doesn't have to de= al >> with revocation when some attribute (employment, for example) changes. >> >> >> >> 3 - How does (2) relate to other assertions (e.g. attribute >> assertions) we would like to make reliably? >> >> >> >> With that starter set, I think we can confirm the subset of >> requirements that 800-63-1 still meets, and define the delta that requir= es >> new design. >> >> >> >> 4 - What=E2=80=99s the right way to update current thinking on LOAs, to = account >> for the change Jim describes in his proposal - i.e., the case where "cre= dentials >> (used in authentication) and attribute information (established through >> identity proofing) could be provided by different parties.=E2=80=9D >> >> >> >> 5 - From Jim=E2=80=99s proposal: =E2=80=9CAttribute reliability refers t= o the quality of >> the identity proofing process, as well as the strength of the binding of >> the identifying attributes to the authentication.=E2=80=9D Do we need/wa= nt to >> expand on this a little? This seems to cater well for the case where, sa= y, >> vehicle entitlements are being established so that they can be encapsula= ted >> in a driving licence. It=E2=80=99s not so clear how this addresses, say,= third >> party assertions that do not arise from an identity proofing process - = =E2=80=9CI >> have no idea *who* this user is, but I can reliably assert the following >> about them: ... =E2=80=9D. >> >> >> You're right; that will need to be defined. But it should be possible to >> define analogous requirements to describe the strength of the binding to >> the token. When you show up to enroll at school, it should be possible t= o >> use your token to allow your school to make LOR 3 asserts that you're th= ere >> student. But maybe remote students only get LOR 2? >> >> -Jim >> >> All- >> There unfortunately is a long-standing bug in Confluence. You must be >> logged in before that link, or any link to a restricted page, will work. >> >> The wiki space for workshop attendees only, which you all have full edit >> access to and which is not publicly viewable, is athttps:// >> tid.isoc.org/confluence/display/interfedgen/ >> >> The *PUBLIC* wiki space, containing the agenda, presentations, and >> contributions/references, is at >> https://tid.isoc.org/confluence/display/interfed/ >> >> As we make progress on work items and are ready to move them to the >> public wiki, I will be happy to do that. Our goal is of course to make a= s >> much of our work as possible available to the public, but this restricte= d >> wiki space gives us a place to work on things before revealing them to t= he >> world. >> >> As always, if anyone has questions or problems related to the wiki, or >> anything else, please do let me know. >> Steve >> >> -- >> Steve Olshansky >> Trust & Identity Program Lead >> Internet Society >> www.internetsociety.org >> >> >> >> >> _______________________________________________ >> Ideco-fab mailing list >> Ideco-fab@elists.isoc.org >> >> https://elists.isoc.org/mailman/listinfo/ideco-fab >> >> >> >> ---------- Forwarded message ---------- >> From: Steve Olshansky > > >> To: "vot@ietf.org " < >> vot@ietf.org > >> Cc: >> Date: Tue, 13 Jan 2015 13:19:22 +0000 >> Subject: [VoT] VoT wiki >> All- >> This is a great discussion, and the stars seem to be aligning now for th= e >> development of some documents or any other related artifacts. >> >> I setup a dedicated wiki space for use by this group. It is open to the >> world for viewing, but we can easily make restricted areas for the purpo= se >> of working on documents before publishing. Anyone would would like edit >> access is welcome to contact me directly (off-list). >> https://tid.isoc.org/confluence/display/vot/VoT+Home >> Steve >> >> -- >> Steve Olshansky >> Trust & Identity Program Lead >> Internet Society >> www.internetsociety.org >> >> On Jan 13, 2015, at 2:31 AM, Robin Wilton > > wrote: >> >> > Oops - I'd forgotten about the wiki: apologies! Yes, I think that's th= e >> place to start... >> > >> > R >> > >> > Robin Wilton >> > >> > Technical Outreach Director - Identity and Privacy >> > >> > On 12 Jan 2015, at 23:43, "Colin Wallis" > > wrote: >> > >> >> Well as Steve O pointed out in this attached email in November, the >> wiki set up for this work might be a place to start.. >> >> There may be some jiggery pokery to get the folks on this list who >> want to contribute (who were not attendees at Utrecht) access rights, bu= t >> it would seem to me to be the obvious starter option for a repository. >> >> Cheers >> >> Colin >> >> PS: BTW this is a good discussion and indeed an opportunistic time to >> bring it together since so much of what Justin, Jim, Scott, Ken, Steve W= , >> Mark et al have commented recently is complementary (well at least not >> completely contradictory or orthogonal) so let=E2=80=99s grab it! >> >> >> >> From: vot [mailto:vot-bounces@ietf.org >> ] On Behalf Of >> Robin Wilton >> >> Sent: Tuesday, 13 January 2015 11:22 a.m. >> >> To: Jim Fenton >> >> Cc: vot@ietf.org >> >> Subject: Re: [VoT] capturing the threads of the discussion >> >> >> >> Thanks Jim, >> >> >> >> I won't give a substantive response here; just to note that I think >> it's worth considering a repository so that we can capture 'static' >> versions of any straw-man docs, to complement what we it into the mail >> thread... >> >> >> >> Sorry to be brief at this stage - just tying up some loose ends befor= e >> an absence from the office. >> >> >> >> R >> >> >> >> Robin Wilton >> >> >> >> Technical Outreach Director - Identity and Privacy >> >> >> >> On 12 Jan 2015, at 21:45, "Jim Fenton" > > wrote: >> >> >> >> Maybe I should be breaking these apart as Robin suggests, but for now >> I'll keep this in one reply: >> >> >> >> On 1/12/15 6:06 AM, Robin Wilton wrote: >> >> This thread raises several important topics=E2=80=A6 just as a practi= cal >> matter, it might be worth trying to spin some of them off separately, so >> that we address them all, and minimise the risk of talking at >> cross-purposes. >> >> It feels like it would be worth trying to put together some *very >> short* straw-man docs/pages/paragraphs to try and get a consensus versio= n >> on specific points, so that we avoid re-hashing the same >> arguments/discussions over time, or at least have something we can refer= to >> - and amend if necessary. I think this is aiming at the same end-point a= s >> Steve=E2=80=99s request for a statement of requirements, but will ensure= we=E2=80=99re >> expressing our requirements in a consistent set of terms. >> >> >> >> >> >> By the looks of it, these would make for a good starting point (I >> think the answers to most of these are implicit in various people=E2=80= =99s >> contributions to the thread=E2=80=A6 but that doesn=E2=80=99t mean every= one agrees ;^) ): >> >> >> >> >> >> 1 - what do we mean by authentication and authorisation? Are there >> other decisions (e.g. access control, entitlement) which need to be call= ed >> out explicitly? This reflects the purpose of Justin=E2=80=99s questions. >> Classically, the reason for authenticating a user is to answer a yes/no >> question (is this the person to whom this credential was originally >> issued); if yes, what do I want to do about it (at which point the furth= er >> entitlements are usually determined by retrieving a user profile, ACL or >> whatever)? >> >> >> >> Access control and entitlement as distinct from authorisation? Is >> there a distinction, or are people just using different terminology? >> >> >> >> I think of authentication as providing more than a yes/no answer: it >> provides an identifier. If the relying party has enough information >> (perhaps on the basis of previous interactions) to authorize something w= ith >> just that, fine. Otherwise some attributes are needed to make an >> authorisation decision. >> >> >> >> >> >> However, as we know, these days access control and entitlement >> decisions also need to be made on the basis of input other than classic >> credentials, and that=E2=80=99s one of the two cores of this discussion,= I believe. >> >> >> >> Example of an "input other than classic credentials"? >> >> >> >> >> >> >> >> >> >> 2 - what=E2=80=99s the classic lifecycle of a credential - i.e. a art= efact >> intended to provide evidence in support of an assertion of identity. (e.= g. >> registration/verification/enrolment, credential issue, credential >> presentation/authentication, credential amendment/revocation/destruction= =E2=80=A6)? >> >> >> >> >> >> Credential is another of those tricky words. Sometimes it means the >> same as an authentication token. Sometimes it has some attributes bound = to >> it, which means it has both an authentication and attribute provision >> flavor to it. I find it simpler to talk about tokens, where one doesn't >> have to deal with revocation when some attribute (employment, for exampl= e) >> changes. >> >> >> >> >> >> >> >> 3 - How does (2) relate to other assertions (e.g. attribute >> assertions) we would like to make reliably? >> >> >> >> >> >> With that starter set, I think we can confirm the subset of >> requirements that 800-63-1 still meets, and define the delta that requir= es >> new design. >> >> >> >> 4 - What=E2=80=99s the right way to update current thinking on LOAs, = to >> account for the change Jim describes in his proposal - i.e., the case wh= ere >> "credentials (used in authentication) and attribute information >> (established through identity proofing) could be provided by different >> parties.=E2=80=9D >> >> >> >> 5 - From Jim=E2=80=99s proposal: =E2=80=9CAttribute reliability refer= s to the quality >> of the identity proofing process, as well as the strength of the binding= of >> the identifying attributes to the authentication.=E2=80=9D Do we need/wa= nt to >> expand on this a little? This seems to cater well for the case where, sa= y, >> vehicle entitlements are being established so that they can be encapsula= ted >> in a driving licence. It=E2=80=99s not so clear how this addresses, say,= third >> party assertions that do not arise from an identity proofing process - = =E2=80=9CI >> have no idea *who* this user is, but I can reliably assert the following >> about them: ... =E2=80=9D. >> >> >> >> You're right; that will need to be defined. But it should be possible >> to define analogous requirements to describe the strength of the binding= to >> the token. When you show up to enroll at school, it should be possible t= o >> use your token to allow your school to make LOR 3 asserts that you're th= ere >> student. But maybe remote students only get LOR 2? >> >> >> >> -Jim >> >> >> > vot mailing list >> > vot@ietf.org >> > https://www.ietf.org/mailman/listinfo/vot >> >> >> _______________________________________________ >> vot mailing list >> vot@ietf.org >> https://www.ietf.org/mailman/listinfo/vot >> >> > --089e01634dda468cd0050d2b7d77 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Peter,

It has taken me a while to get the time to read a= nd reflect on what is contained in your email.

Having f= inally thought about it, and the rest of the thread, I must say bravo!
=
I believe that I=C2=A0agree fully with you: "the greatest opportunity o= pen to us is to find a way to normalize all the various community policies = and practices so that RPs can assess whether assertions issued under one co= mmunity's metrics align with their adopted risk mitigation requirements= . I think that has to be addressed in the context of how effective a partic= ular mitigation action is on a recognized threat vector."

If I am readi= ng this correctly I think that you are saying is:=C2=A0how can community 2 = understand the risk mitigation processes undertaken by community 1 so that = it (community 2) can use=C2=A0the assertion made by community 1 as one (pos= sibly the sole) of the=C2=A0risk mitigation actions it requires to allow so= me action.

In this context, 800-63 defines what=C2=A0the U.S.= Federal Government expects to have been done in order to accept assertions= .

In my opinion, it is up to other communities to=C2=A0descri= be their specific requirements to accept assertions and then compare and co= ntrast those requirements to 800-63. Once that analysis is completed these = other communities can make the decision as to whether they will accept asse= rtions based on 800-63.

Is there a normalized set of assertio= n requirements? I don't know. There are a few communities that have des= cribed their requirements but, in my opinion, I am not sure how easy it is = to compare and contrast these=C2=A0descriptions In a manner that might gene= rate a normalized=C2=A0set. This might be a fantastic Masters degree analys= is that some enterprising student might undertake. Or, if some federation c= ould find the funding, that a consultant could undertake.

Ken=

On Tuesday, January 13, 2015, Peter Alterman <= ;palterman@safe-biopharma.o= rg> wrote:
=E2=80=8BHappy new year t= o you all.=C2=A0 I've been reading the mail but unable to break away lo= ng enough to comment until now. As I read it, the issue on the table is how= to express trustworthiness.=C2=A0

If Abbie was here he'd point you all to the one-to-one cor= relation between trust and threat/threat vector mitigation.=E2=80=8B I reco= mmend to you the Third Deliverable of the OASIS Trust Elevation TC =C2=A0- = link provided upon demonstration of curiosity ;-)

=C2=A0An RP trusts an external assertion of iden= tity (or even extended attributes) to the extent that the assertion is crea= ted and/or can be verified to a predetermined degree of threat/risk mitigat= ion. This degree is baked into policy or contract or some other pre-existin= g agreement (think banking regulations, etc.) and is locally determined bas= ed upon local considerations, e.g., no global standard is appropriate.=C2= =A0 So far as I can see, vectors of trust are the same thing as the threats= and threat vectors that are enumerated in ISO 29115 and other places, not = least of which are controls in NIST 800-53-4 and in ISO 27001/2. I really d= on't see the vectors as anything different from these and considering t= rustworthiness as the inverse of threat in this context is pretty much what= everybody seems to be saying.=C2=A0

If we just use 29115 as our baseline of threats and threa= t vectors, there are roughly a dozen or so of them associated with authenti= cation of identity assertion. I don't think any of us believe that a tw= elve-dimensional assertion is practically viable, even if we could agree on= a common metric for degree of threat mitigation (fat chance that). This ha= s also already been addressed by the community: think of the factor model, = one to four factors (the fourth is context, which may be expressed as "= ;Where or when you are," according to our colleagues). What this does = is boil down the trust/threat algorithm to no more than four dimensions and= shifts the discussion to the aforementioned conundrum, e.g., how to evalua= te and rate the degree of threat mitigation. Various communities have devel= oped policies and practices to address this question, the most recent of wh= ich, I think, is EU Regulation 910/2014 (eIDAS).=C2=A0

IMO, the greatest opportunity open to us is= to find a way to normalize all the various community policies and practice= s so that RPs can assess whether assertions issued under one community'= s metrics align with their adopted risk mitigation requirements. I think th= at has to be addressed in the context of how effective a particular mitigat= ion action is on a recognized threat vector. =C2=A0 I would be most interes= ted in your thoughts on that problem.

regards,

Peter

---------------------------------------------= ---------------
Peter Alterman, Ph.D.
Chief Operating Off= icer
SAFE-BioPharma Association
cell: 301-943-7452


On Tue, Jan 13, 2015 at 8:19 AM, <vot-request@ietf.org> wr= ote:
Send vot mailing list submissions to=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 vot@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/vot
or, via email, send a message with subject or body 'help' to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 vot-request@ietf.org

You can reach the person managing the list at
=C2=A0 =C2=A0 =C2=A0 =C2=A0 vot-owner@ietf.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of vot digest..."

Today's Topics:

=C2=A0 =C2=A01. Re: capturing the threads of the discussion (Robin Wilton)<= br> =C2=A0 =C2=A02. VoT wiki (Steve Olshansky)


---------- Forwarded message ----------
From:=C2=A0Robin Wilton = <wilton@isoc.org>
To:=C2=A0Colin Wallis <= ;Colin.Wallis@dia.govt.nz>
Cc:=C2=A0J= im Fenton <fenton@bluepopcorn.net>, &qu= ot;vot@ietf.org" <vot@ietf.org<= /a>>
Date:=C2=A0Tue, 13 Jan 2015 09:31:59 +0000
Subject:=C2=A0Re: = [VoT] capturing the threads of the discussion
Oops - I'd forgotten about the wiki: apologies! Yes, I think that&= #39;s the place to start...

R

Robin Wilton

Technical Outreach Director - Identity and Privacy

Well as Steve O pointed o= ut in this attached email in November, the wiki set up for this work might = be a place to start..

There may be some jiggery= pokery to get the folks on this list who want to contribute (who were not = attendees at Utrecht) access rights, but it would seem to me to be the obvious starter option for a repository.=

Cheers

Colin

PS: BTW this is a good discussion and indeed an opportunistic time to b= ring it together since so much of what Justin, Jim, Scott, Ken, Steve W, Mark et al have commented recently is complementary (well at= least not completely contradictory or orthogonal) so let=E2=80=99s grab it= !

=C2=A0

From: vot [mailto:vot-bounces@ietf.= org] On Behalf Of Robin Wilton
Sent: Tuesday, 13 January 2015 11:22 a.m.
To: Jim Fenton
Cc: vot@ietf.org
Subject: Re: [VoT] capturing the threads of the discussion=

=C2=A0

Thanks Jim,

=C2=A0

I won't give a substantive response here; just t= o note that I think it's worth considering a repository so that we can = capture 'static' versions of any straw-man docs, to complement what= we it into the mail thread...

=C2=A0

Sorry to be brief at this stage - just tying up some= loose ends before an absence from the office.

=C2=A0

R

Robin Wilton

=C2=A0

Technical Outreach Director - Identity and Privacy


On 12 Jan 2015, at 21:45, "Jim Fenton" <fenton@bluepopcorn.net> wrote:

Maybe I should be breaking these apart as Robin sugg= ests, but for now I'll keep this in one reply:

On 1/12/15 6:06 AM, Robin Wilton wrote:

This thread raises several important topics=E2=80=A6= just as a practical matter, it might be worth trying to spin some of them = off separately, so that we address them all, and minimise the risk of talki= ng at cross-purposes. =C2=A0

It feels like it would be worth trying to put togeth= er some *very short* straw-man docs/pages/paragraphs to try and get a conse= nsus version on specific points, so that we avoid re-hashing the same argum= ents/discussions over time, or at least have something we can refer to - and amend if necessary. I think thi= s is aiming at the same end-point as Steve=E2=80=99s request for a statemen= t of requirements, but will ensure we=E2=80=99re expressing our requirement= s in a consistent set of terms.



By the looks of it, these would make= for a good starting point (I think the answers to most of these are implic= it in various people=E2=80=99s contributions to the thread=E2=80=A6 but that doesn=E2=80=99t mean everyone agrees ;^) = =C2=A0):



1 - what do we mean by authenticatio= n and authorisation? Are there other decisions (e.g. access control, entitl= ement) which need to be called out explicitly? This reflects the purpose of Justin=E2=80=99s questions. C= lassically, the reason for authenticating a user is to answer a yes/no ques= tion (is this the person to whom this credential was originally issued); if= yes, what do I want to do about it (at which point the further entitlements are usually determined by retrieving = a user profile, ACL or whatever)?


Access control and entitlement as distinct from authorisation? Is there a d= istinction, or are people just using different terminology?

I think of authentication as providing more than a yes/no answer: it provid= es an identifier. If the relying party has enough information (perhaps on t= he basis of previous interactions) to authorize something with just that, f= ine. Otherwise some attributes are needed to make an authorisation decision.


However, as we know, these days acce= ss control and entitlement decisions also need to be made on the basis of i= nput other than classic credentials, and that=E2=80=99s one of the two cores of this discussion, I believe.


Example of an "input other than classic credentials"?




2 - what=E2=80=99s the classic lifec= ycle of a credential - i.e. a artefact intended to provide evidence in supp= ort of an assertion of identity. (e.g. registration/verification/enrolment, credential issue, credential presenta= tion/authentication, credential amendment/revocation/destruction=E2=80=A6)?


Credential is another of those tricky words. Sometimes it means the same as= an authentication token. Sometimes it has some attributes bound to it, whi= ch means it has both an authentication and attribute provision flavor to it= . I find it simpler to talk about tokens, where one doesn't have to deal with revocation when some attri= bute (employment, for example) changes.



3 - How does (2) relate to other ass= ertions (e.g. attribute assertions) we would like to make reliably?<= /span>



With that starter set, I think we can confirm the su= bset of requirements that 800-63-1 still meets, and define the delta that r= equires new design.

=C2=A0

4 - What=E2=80=99s the right way to update current t= hinking on LOAs, to account for the change Jim describes in his proposal - = i.e., the case where "creden= tials (used in authentication) and attribute information (established through id= entity proofing) could be provided by different parties.=E2=80=9D

=C2=A0

5 - From Jim=E2=80=99s proposal: =E2=80=9CAttribute reliability refers to the quality of the identity = proofing process, as well as the strength of the binding of the identifying attributes to the authentication.=E2=80=9D Do we need/want to expan= d on this a little? This seems to cater well for the case where, say, vehic= le entitlements are being established so that they can be encapsulated in a= driving licence. It=E2=80=99s not so clear how this addresses, say, third party assertions that do not arise from an iden= tity proofing process - =E2=80=9CI have no idea *who* this user is, but I c= an reliably assert the following about them: ... =E2=80=9D.


You're right; that will need to be defined. But it should be possible t= o define analogous requirements to describe the strength of the binding to = the token. When you show up to enroll at school, it should be possible to u= se your token to allow your school to make LOR 3 asserts that you're there student. But maybe remote student= s only get LOR 2?

-Jim

All-
There unfortunately is a long-standing bug in Confluence. You must be= logged in before that link, or any link to a restricted page, will work.

The wiki space for workshop attendees only, which you all have full e= dit access to and which is not publicly viewable, is athttps://tid.i= soc.org/confluence/display/interfedgen/

The *PUBLIC* wiki space, containing the agenda, presentations, and co= ntributions/references, is at
https://tid.isoc.org/confluence/display/interfed/
As we make progress on work items and are ready to move them to the p= ublic wiki, I will be happy to do that. Our goal is of course to make as mu= ch of our work as possible available to the public, but this restricted wik= i space gives us a place to work on things before revealing them to the world.

As always, if anyone has questions or problems related to the wiki, o= r anything else, please do let me know.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Steve

--
Steve Olshansky
Trust & Identity Program Lead
Internet Society
www.inte= rnetsociety.org


<signature.asc>
_______________________________________________
Ideco-fab mailing list
Ideco-fab@elists.isoc.org
https://elists.isoc.org/mailman/listinfo/ideco-fab


---------- Forwarded message ----------
From:=C2=A0Steve Olshans= ky <olshansky@isoc.org>
To:=C2=A0"<= a href=3D"javascript:_e(%7B%7D,'cvml','vot@ietf.org');" tar= get=3D"_blank">vot@ietf.org" <vot@ietf.org&= gt;
Cc:=C2=A0
Date:=C2=A0Tue, 13 Jan 2015 13:19:22 +0000
Subject:= =C2=A0[VoT] VoT wiki
All-
This is a great discussion, and the stars seem to be aligning now for the d= evelopment of some documents or any other related artifacts.

I setup a dedicated wiki space for use by this group. It is open to the wor= ld for viewing, but we can easily make restricted areas for the purpose of = working on documents before publishing. Anyone would would like edit access= is welcome to contact me directly (off-list).
https://tid.isoc.org/confluence/display/vot/VoT+Home
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Steve

--
Steve Olshansky
Trust & Identity Program Lead
Internet Society
www.internetso= ciety.org

On Jan 13, 2015, at 2:31 AM, Robin Wilton <wilton@iso= c.org> wrote:

> Oops - I'd forgotten about the wiki: apologies! Yes, I think that&= #39;s the place to start...
>
> R
>
> Robin Wilton
>
> Technical Outreach Director - Identity and Privacy
>
> On 12 Jan 2015, at 23:43, "Colin Wallis" <Colin.Wallis@dia.govt.nz> wrote:
>
>> Well as Steve O pointed out in this attached email in November, th= e wiki set up for this work might be a place to start..
>> There may be some jiggery pokery to get the folks on this list who= want to contribute (who were not attendees at Utrecht) access rights, but = it would seem to me to be the obvious starter option for a repository.
>> Cheers
>> Colin
>> PS: BTW this is a good discussion and indeed an opportunistic time= to bring it together since so much of what Justin, Jim, Scott, Ken, Steve = W, Mark et al have commented recently is complementary (well at least not c= ompletely contradictory or orthogonal) so let=E2=80=99s grab it!
>>
>> From: vot [mailto:vot-bounces@ietf.org= ] On Behalf Of Robin Wilton
>> Sent: Tuesday, 13 January 2015 11:22 a.m.
>> To: Jim Fenton
>> Cc: vot@ietf.org
>> Subject: Re: [VoT] capturing the threads of the discussion
>>
>> Thanks Jim,
>>
>> I won't give a substantive response here; just to note that I = think it's worth considering a repository so that we can capture 's= tatic' versions of any straw-man docs, to complement what we it into th= e mail thread...
>>
>> Sorry to be brief at this stage - just tying up some loose ends be= fore an absence from the office.
>>
>> R
>>
>> Robin Wilton
>>
>> Technical Outreach Director - Identity and Privacy
>>
>> On 12 Jan 2015, at 21:45, "Jim Fenton" <fenton@bluepopcorn.net> wrote:
>>
>> Maybe I should be breaking these apart as Robin suggests, but for = now I'll keep this in one reply:
>>
>> On 1/12/15 6:06 AM, Robin Wilton wrote:
>> This thread raises several important topics=E2=80=A6 just as a pra= ctical matter, it might be worth trying to spin some of them off separately= , so that we address them all, and minimise the risk of talking at cross-pu= rposes.
>> It feels like it would be worth trying to put together some *very = short* straw-man docs/pages/paragraphs to try and get a consensus version o= n specific points, so that we avoid re-hashing the same arguments/discussio= ns over time, or at least have something we can refer to - and amend if nec= essary. I think this is aiming at the same end-point as Steve=E2=80=99s req= uest for a statement of requirements, but will ensure we=E2=80=99re express= ing our requirements in a consistent set of terms.
>>
>>
>> By the looks of it, these would make for a good starting point (I = think the answers to most of these are implicit in various people=E2=80=99s= contributions to the thread=E2=80=A6 but that doesn=E2=80=99t mean everyon= e agrees ;^)=C2=A0 ):
>>
>>
>> 1 - what do we mean by authentication and authorisation? Are there= other decisions (e.g. access control, entitlement) which need to be called= out explicitly? This reflects the purpose of Justin=E2=80=99s questions. C= lassically, the reason for authenticating a user is to answer a yes/no ques= tion (is this the person to whom this credential was originally issued); if= yes, what do I want to do about it (at which point the further entitlement= s are usually determined by retrieving a user profile, ACL or whatever)? >>
>> Access control and entitlement as distinct from authorisation? Is = there a distinction, or are people just using different terminology?
>>
>> I think of authentication as providing more than a yes/no answer: = it provides an identifier. If the relying party has enough information (per= haps on the basis of previous interactions) to authorize something with jus= t that, fine. Otherwise some attributes are needed to make an authorisation= decision.
>>
>>
>> However, as we know, these days access control and entitlement dec= isions also need to be made on the basis of input other than classic creden= tials, and that=E2=80=99s one of the two cores of this discussion, I believ= e.
>>
>> Example of an "input other than classic credentials"? >>
>>
>>
>>
>> 2 - what=E2=80=99s the classic lifecycle of a credential - i.e. a = artefact intended to provide evidence in support of an assertion of identit= y. (e.g. registration/verification/enrolment, credential issue, credential = presentation/authentication, credential amendment/revocation/destruction=E2= =80=A6)?
>>
>>
>> Credential is another of those tricky words. Sometimes it means th= e same as an authentication token. Sometimes it has some attributes bound t= o it, which means it has both an authentication and attribute provision fla= vor to it. I find it simpler to talk about tokens, where one doesn't ha= ve to deal with revocation when some attribute (employment, for example) ch= anges.
>>
>>
>>
>> 3 - How does (2) relate to other assertions (e.g. attribute assert= ions) we would like to make reliably?
>>
>>
>> With that starter set, I think we can confirm the subset of requir= ements that 800-63-1 still meets, and define the delta that requires new de= sign.
>>
>> 4 - What=E2=80=99s the right way to update current thinking on LOA= s, to account for the change Jim describes in his proposal - i.e., the case= where "credentials (used in authentication) and attribute information= (established through identity proofing) could be provided by different par= ties.=E2=80=9D
>>
>> 5 - From Jim=E2=80=99s proposal: =E2=80=9CAttribute reliability re= fers to the quality of the identity proofing process, as well as the streng= th of the binding of the identifying attributes to the authentication.=E2= =80=9D Do we need/want to expand on this a little? This seems to cater well= for the case where, say, vehicle entitlements are being established so tha= t they can be encapsulated in a driving licence. It=E2=80=99s not so clear = how this addresses, say, third party assertions that do not arise from an i= dentity proofing process - =E2=80=9CI have no idea *who* this user is, but = I can reliably assert the following about them: ... =E2=80=9D.
>>
>> You're right; that will need to be defined. But it should be p= ossible to define analogous requirements to describe the strength of the bi= nding to the token. When you show up to enroll at school, it should be poss= ible to use your token to allow your school to make LOR 3 asserts that you&= #39;re there student. But maybe remote students only get LOR 2?
>>
>> -Jim
>>
> vot mailing list
> vot@ietf.org
> https://www.ietf.org/mailman/listinfo/vot


_______________________________________________
vot mailing list
vot@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/vot


--089e01634dda468cd0050d2b7d77-- From nobody Wed Jan 21 11:17:04 2015 Return-Path: X-Original-To: vot@ietfa.amsl.com Delivered-To: vot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A5AB1A7D85 for ; Wed, 21 Jan 2015 11:17:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.023 X-Spam-Level: *** X-Spam-Status: No, score=3.023 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MANGLED_MARKET=2.3, RCVD_IN_DNSWL_LOW=-0.7] 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 1Pvl883I38jz for ; Wed, 21 Jan 2015 11:16:55 -0800 (PST) Received: from mail-lb0-f173.google.com (mail-lb0-f173.google.com [209.85.217.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBE7B1A7031 for ; Wed, 21 Jan 2015 11:16:54 -0800 (PST) Received: by mail-lb0-f173.google.com with SMTP id p9so17783144lbv.4 for ; Wed, 21 Jan 2015 11:16:53 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=MedrRqMJUkDyr6hnUP6mceLn0PE99cdT32iqmaWsxX0=; b=RTRaQ9tkCQ2GoM+MqK9Jb4bnDc3JIWqXgpBMqgSKrom924z56wHJosYqrgz20nxE0w k29xmIT1fr+HbPDYI4eR4k37DqkcXVkWKyRkx95Pong/aAaJg+LG2NE9d0zjxU0Ripa3 2Dg9pTFou/5vUmybHwHVN69HDh8kKy/ZmDPMMetuU1zSQX+L2NeYG4uah8qlFL7bgC5x NOJB8e5KZYGwrm8g/F5Jwu91fXER3vivZ6WmM1x/CQKPGbMcOnGyqmxe/kRhjQSzz2n7 Ek9xf9/LFDZabLEnlpU2TURSLMBIcJ3xDBd4l7XsCKc81CmRC+Y1ZUxKhb2mslXbTlHS cwRw== X-Gm-Message-State: ALoCoQnmeeX6wc31wX2/fomn7Ey1DV2uYT28F9USSq528PqhG3duuLQ5iV5ekC8nrV55zPhLpV5Z MIME-Version: 1.0 X-Received: by 10.112.204.233 with SMTP id lb9mr46382819lbc.43.1421867813259; Wed, 21 Jan 2015 11:16:53 -0800 (PST) Received: by 10.25.169.79 with HTTP; Wed, 21 Jan 2015 11:16:53 -0800 (PST) In-Reply-To: References: <06c901d03104$998031d0$cc809570$@sk.ee> Date: Wed, 21 Jan 2015 14:16:53 -0500 Message-ID: From: Scott Shorter To: Peter Alterman Content-Type: multipart/alternative; boundary=001a11c3cb04ed629d050d2e65be Archived-At: Cc: Tarvi Martens , vot@ietf.org Subject: Re: [VoT] vot Digest, Vol 5, Issue 6 X-BeenThere: vot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Vectors of Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 19:17:02 -0000 --001a11c3cb04ed629d050d2e65be Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Speaking of Estonia, we coincidentally just blogged on the topic of the Estonian ID card and electronic residency program over at the Electrosoft blog . Peter, thanks for bringing up the topic. Tarvi, welcome to the discussion! - Scott On Thu, Jan 15, 2015 at 3:54 PM, Peter Alterman < palterman@safe-biopharma.org> wrote: > Hi Tarvi, > > Agreed, and it gets more interesting this year and next, when the EC plan= s > to certify services against the Low and Substantial levels, leaving High = to > the QCP (which includes Estonia, an example to us all). > > Peter > > ------------------------------------------------------------ > Peter Alterman, Ph.D. > Chief Operating Officer > SAFE-BioPharma Association > cell: 301-943-7452 > > > On Thu, Jan 15, 2015 at 3:48 PM, Tarvi Martens wrote: > >> Hi, >> >> >> >> The principle of Eurpean eIDAS eID recognition is mainly that =E2=80=9Ei= f you >> trust this in your country then other EU states shall it trust as well i= n >> their e-services=E2=80=9C. Oh well, when it is sort of =E2=80=9Eregister= ed and assessed=E2=80=9C. >> >> >> >> In general terms it comes down to community (read: RP-s) trust. For >> example hardly anyone would question Estonian ID-card for it security af= ter >> living 13 years of harmless life, >> >> >> >> Tarvi >> >> >> >> *From:* vot [mailto:vot-bounces@ietf.org] *On Behalf Of *Peter Alterman >> *Sent:* Tuesday, January 13, 2015 8:00 PM >> *To:* vot@ietf.org >> *Subject:* Re: [VoT] vot Digest, Vol 5, Issue 6 >> >> >> >> =E2=80=8BHappy new year to you all. I've been reading the mail but unab= le to >> break away long enough to comment until now. As I read it, the issue on = the >> table is how to express trustworthiness. >> >> >> >> If Abbie was here he'd point you all to the one-to-one correlation >> between trust and threat/threat vector mitigation.=E2=80=8B I recommend = to you the >> Third Deliverable of the OASIS Trust Elevation TC - link provided upon >> demonstration of curiosity ;-) >> >> >> >> An RP trusts an external assertion of identity (or even extended >> attributes) to the extent that the assertion is created and/or can be >> verified to a predetermined degree of threat/risk mitigation. This degre= e >> is baked into policy or contract or some other pre-existing agreement >> (think banking regulations, etc.) and is locally determined based upon >> local considerations, e.g., no global standard is appropriate. So far a= s I >> can see, vectors of trust are the same thing as the threats and threat >> vectors that are enumerated in ISO 29115 and other places, not least of >> which are controls in NIST 800-53-4 and in ISO 27001/2. I really don't s= ee >> the vectors as anything different from these and considering >> trustworthiness as the inverse of threat in this context is pretty much >> what everybody seems to be saying. >> >> >> >> If we just use 29115 as our baseline of threats and threat vectors, ther= e >> are roughly a dozen or so of them associated with authentication of >> identity assertion. I don't think any of us believe that a >> twelve-dimensional assertion is practically viable, even if we could agr= ee >> on a common metric for degree of threat mitigation (fat chance that). Th= is >> has also already been addressed by the community: think of the factor >> model, one to four factors (the fourth is context, which may be expresse= d >> as "Where or when you are," according to our colleagues). What this does= is >> boil down the trust/threat algorithm to no more than four dimensions and >> shifts the discussion to the aforementioned conundrum, e.g., how to >> evaluate and rate the degree of threat mitigation. Various communities h= ave >> developed policies and practices to address this question, the most rece= nt >> of which, I think, is EU Regulation 910/2014 (eIDAS). >> >> >> >> IMO, the greatest opportunity open to us is to find a way to normalize >> all the various community policies and practices so that RPs can assess >> whether assertions issued under one community's metrics align with their >> adopted risk mitigation requirements. I think that has to be addressed i= n >> the context of how effective a particular mitigation action is on a >> recognized threat vector. I would be most interested in your thoughts = on >> that problem. >> >> >> >> regards, >> >> >> >> Peter >> >> >> ------------------------------------------------------------ >> >> Peter Alterman, Ph.D. >> >> Chief Operating Officer >> SAFE-BioPharma Association >> >> cell: 301-943-7452 >> >> >> >> On Tue, Jan 13, 2015 at 8:19 AM, wrote: >> >> Send vot mailing list submissions to >> vot@ietf.org >> >> To subscribe or unsubscribe via the World Wide Web, visit >> https://www.ietf.org/mailman/listinfo/vot >> or, via email, send a message with subject or body 'help' to >> vot-request@ietf.org >> >> You can reach the person managing the list at >> vot-owner@ietf.org >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of vot digest..." >> >> Today's Topics: >> >> 1. Re: capturing the threads of the discussion (Robin Wilton) >> 2. VoT wiki (Steve Olshansky) >> >> >> ---------- Forwarded message ---------- >> From: Robin Wilton >> To: Colin Wallis >> Cc: Jim Fenton , "vot@ietf.org" >> Date: Tue, 13 Jan 2015 09:31:59 +0000 >> Subject: Re: [VoT] capturing the threads of the discussion >> >> Oops - I'd forgotten about the wiki: apologies! Yes, I think that's the >> place to start... >> >> >> >> R >> >> Robin Wilton >> >> >> >> Technical Outreach Director - Identity and Privacy >> >> >> On 12 Jan 2015, at 23:43, "Colin Wallis" >> wrote: >> >> Well as Steve O pointed out in this attached email in November, the wiki >> set up for this work might be a place to start.. >> >> There may be some jiggery pokery to get the folks on this list who want >> to contribute (who were not attendees at Utrecht) access rights, but it >> would seem to me to be the obvious starter option for a repository. >> >> Cheers >> >> Colin >> >> PS: BTW this is a good discussion and indeed an opportunistic time to >> bring it together since so much of what Justin, Jim, Scott, Ken, Steve W= , >> Mark et al have commented recently is complementary (well at least not >> completely contradictory or orthogonal) so let=E2=80=99s grab it! >> >> >> >> *From:* vot [mailto:vot-bounces@ietf.org] *On Behalf Of *Robin Wilton >> *Sent:* Tuesday, 13 January 2015 11:22 a.m. >> *To:* Jim Fenton >> *Cc:* vot@ietf.org >> *Subject:* Re: [VoT] capturing the threads of the discussion >> >> >> >> Thanks Jim, >> >> >> >> I won't give a substantive response here; just to note that I think it's >> worth considering a repository so that we can capture 'static' versions = of >> any straw-man docs, to complement what we it into the mail thread... >> >> >> >> Sorry to be brief at this stage - just tying up some loose ends before a= n >> absence from the office. >> >> >> >> R >> >> Robin Wilton >> >> >> >> Technical Outreach Director - Identity and Privacy >> >> >> On 12 Jan 2015, at 21:45, "Jim Fenton" wrote: >> >> Maybe I should be breaking these apart as Robin suggests, but for now >> I'll keep this in one reply: >> >> On 1/12/15 6:06 AM, Robin Wilton wrote: >> >> This thread raises several important topics=E2=80=A6 just as a practical= matter, >> it might be worth trying to spin some of them off separately, so that we >> address them all, and minimise the risk of talking at cross-purposes. >> >> It feels like it would be worth trying to put together some *very short* >> straw-man docs/pages/paragraphs to try and get a consensus version on >> specific points, so that we avoid re-hashing the same arguments/discussi= ons >> over time, or at least have something we can refer to - and amend if >> necessary. I think this is aiming at the same end-point as Steve=E2=80= =99s request >> for a statement of requirements, but will ensure we=E2=80=99re expressin= g our >> requirements in a consistent set of terms. >> >> >> >> By the looks of it, these would make for a good starting point (I think >> the answers to most of these are implicit in various people=E2=80=99s co= ntributions >> to the thread=E2=80=A6 but that doesn=E2=80=99t mean everyone agrees ;^)= ): >> >> >> >> 1 - what do we mean by authentication and authorisation? Are there other >> decisions (e.g. access control, entitlement) which need to be called out >> explicitly? This reflects the purpose of Justin=E2=80=99s questions. Cla= ssically, >> the reason for authenticating a user is to answer a yes/no question (is >> this the person to whom this credential was originally issued); if yes, >> what do I want to do about it (at which point the further entitlements a= re >> usually determined by retrieving a user profile, ACL or whatever)? >> >> >> Access control and entitlement as distinct from authorisation? Is there = a >> distinction, or are people just using different terminology? >> >> I think of authentication as providing more than a yes/no answer: it >> provides an identifier. If the relying party has enough information >> (perhaps on the basis of previous interactions) to authorize something w= ith >> just that, fine. Otherwise some attributes are needed to make an >> authorisation decision. >> >> However, as we know, these days access control and entitlement decisions >> also need to be made on the basis of input other than classic credential= s, >> and that=E2=80=99s one of the two cores of this discussion, I believe. >> >> >> Example of an "input other than classic credentials"? >> >> >> >> 2 - what=E2=80=99s the classic lifecycle of a credential - i.e. a artefa= ct >> intended to provide evidence in support of an assertion of identity. (e.= g. >> registration/verification/enrolment, credential issue, credential >> presentation/authentication, credential amendment/revocation/destruction= =E2=80=A6)? >> >> >> Credential is another of those tricky words. Sometimes it means the same >> as an authentication token. Sometimes it has some attributes bound to it= , >> which means it has both an authentication and attribute provision flavor= to >> it. I find it simpler to talk about tokens, where one doesn't have to de= al >> with revocation when some attribute (employment, for example) changes. >> >> >> >> 3 - How does (2) relate to other assertions (e.g. attribute assertions) >> we would like to make reliably? >> >> >> >> With that starter set, I think we can confirm the subset of requirements >> that 800-63-1 still meets, and define the delta that requires new design= . >> >> >> >> 4 - What=E2=80=99s the right way to update current thinking on LOAs, to = account >> for the change Jim describes in his proposal - i.e., the case where "cre= dentials >> (used in authentication) and attribute information (established through >> identity proofing) could be provided by different parties.=E2=80=9D >> >> >> >> 5 - From Jim=E2=80=99s proposal: =E2=80=9CAttribute reliability refers t= o the quality of >> the identity proofing process, as well as the strength of the binding of >> the identifying attributes to the authentication.=E2=80=9D Do we need/wa= nt to >> expand on this a little? This seems to cater well for the case where, sa= y, >> vehicle entitlements are being established so that they can be encapsula= ted >> in a driving licence. It=E2=80=99s not so clear how this addresses, say,= third >> party assertions that do not arise from an identity proofing process - = =E2=80=9CI >> have no idea *who* this user is, but I can reliably assert the following >> about them: ... =E2=80=9D. >> >> >> You're right; that will need to be defined. But it should be possible to >> define analogous requirements to describe the strength of the binding to >> the token. When you show up to enroll at school, it should be possible t= o >> use your token to allow your school to make LOR 3 asserts that you're th= ere >> student. But maybe remote students only get LOR 2? >> >> -Jim >> >> All- >> There unfortunately is a long-standing bug in Confluence. You must be >> logged in before that link, or any link to a restricted page, will work. >> >> The wiki space for workshop attendees only, which you all have full edit >> access to and which is not publicly viewable, is athttps:// >> tid.isoc.org/confluence/display/interfedgen/ >> >> The *PUBLIC* wiki space, containing the agenda, presentations, and >> contributions/references, is at >> https://tid.isoc.org/confluence/display/interfed/ >> >> As we make progress on work items and are ready to move them to the >> public wiki, I will be happy to do that. Our goal is of course to make a= s >> much of our work as possible available to the public, but this restricte= d >> wiki space gives us a place to work on things before revealing them to t= he >> world. >> >> As always, if anyone has questions or problems related to the wiki, or >> anything else, please do let me know. >> Steve >> >> -- >> Steve Olshansky >> Trust & Identity Program Lead >> Internet Society >> www.internetsociety.org >> >> >> >> _______________________________________________ >> Ideco-fab mailing list >> Ideco-fab@elists.isoc.org >> https://elists.isoc.org/mailman/listinfo/ideco-fab >> >> >> >> ---------- Forwarded message ---------- >> From: Steve Olshansky >> To: "vot@ietf.org" >> Cc: >> Date: Tue, 13 Jan 2015 13:19:22 +0000 >> Subject: [VoT] VoT wiki >> All- >> This is a great discussion, and the stars seem to be aligning now for th= e >> development of some documents or any other related artifacts. >> >> I setup a dedicated wiki space for use by this group. It is open to the >> world for viewing, but we can easily make restricted areas for the purpo= se >> of working on documents before publishing. Anyone would would like edit >> access is welcome to contact me directly (off-list). >> https://tid.isoc.org/confluence/display/vot/VoT+Home >> Steve >> >> -- >> Steve Olshansky >> Trust & Identity Program Lead >> Internet Society >> www.internetsociety.org >> >> On Jan 13, 2015, at 2:31 AM, Robin Wilton wrote: >> >> > Oops - I'd forgotten about the wiki: apologies! Yes, I think that's th= e >> place to start... >> > >> > R >> > >> > Robin Wilton >> > >> > Technical Outreach Director - Identity and Privacy >> > >> > On 12 Jan 2015, at 23:43, "Colin Wallis" >> wrote: >> > >> >> Well as Steve O pointed out in this attached email in November, the >> wiki set up for this work might be a place to start.. >> >> There may be some jiggery pokery to get the folks on this list who >> want to contribute (who were not attendees at Utrecht) access rights, bu= t >> it would seem to me to be the obvious starter option for a repository. >> >> Cheers >> >> Colin >> >> PS: BTW this is a good discussion and indeed an opportunistic time to >> bring it together since so much of what Justin, Jim, Scott, Ken, Steve W= , >> Mark et al have commented recently is complementary (well at least not >> completely contradictory or orthogonal) so let=E2=80=99s grab it! >> >> >> >> From: vot [mailto:vot-bounces@ietf.org] On Behalf Of Robin Wilton >> >> Sent: Tuesday, 13 January 2015 11:22 a.m. >> >> To: Jim Fenton >> >> Cc: vot@ietf.org >> >> Subject: Re: [VoT] capturing the threads of the discussion >> >> >> >> Thanks Jim, >> >> >> >> I won't give a substantive response here; just to note that I think >> it's worth considering a repository so that we can capture 'static' >> versions of any straw-man docs, to complement what we it into the mail >> thread... >> >> >> >> Sorry to be brief at this stage - just tying up some loose ends befor= e >> an absence from the office. >> >> >> >> R >> >> >> >> Robin Wilton >> >> >> >> Technical Outreach Director - Identity and Privacy >> >> >> >> On 12 Jan 2015, at 21:45, "Jim Fenton" wrote= : >> >> >> >> Maybe I should be breaking these apart as Robin suggests, but for now >> I'll keep this in one reply: >> >> >> >> On 1/12/15 6:06 AM, Robin Wilton wrote: >> >> This thread raises several important topics=E2=80=A6 just as a practi= cal >> matter, it might be worth trying to spin some of them off separately, so >> that we address them all, and minimise the risk of talking at >> cross-purposes. >> >> It feels like it would be worth trying to put together some *very >> short* straw-man docs/pages/paragraphs to try and get a consensus versio= n >> on specific points, so that we avoid re-hashing the same >> arguments/discussions over time, or at least have something we can refer= to >> - and amend if necessary. I think this is aiming at the same end-point a= s >> Steve=E2=80=99s request for a statement of requirements, but will ensure= we=E2=80=99re >> expressing our requirements in a consistent set of terms. >> >> >> >> >> >> By the looks of it, these would make for a good starting point (I >> think the answers to most of these are implicit in various people=E2=80= =99s >> contributions to the thread=E2=80=A6 but that doesn=E2=80=99t mean every= one agrees ;^) ): >> >> >> >> >> >> 1 - what do we mean by authentication and authorisation? Are there >> other decisions (e.g. access control, entitlement) which need to be call= ed >> out explicitly? This reflects the purpose of Justin=E2=80=99s questions. >> Classically, the reason for authenticating a user is to answer a yes/no >> question (is this the person to whom this credential was originally >> issued); if yes, what do I want to do about it (at which point the furth= er >> entitlements are usually determined by retrieving a user profile, ACL or >> whatever)? >> >> >> >> Access control and entitlement as distinct from authorisation? Is >> there a distinction, or are people just using different terminology? >> >> >> >> I think of authentication as providing more than a yes/no answer: it >> provides an identifier. If the relying party has enough information >> (perhaps on the basis of previous interactions) to authorize something w= ith >> just that, fine. Otherwise some attributes are needed to make an >> authorisation decision. >> >> >> >> >> >> However, as we know, these days access control and entitlement >> decisions also need to be made on the basis of input other than classic >> credentials, and that=E2=80=99s one of the two cores of this discussion,= I believe. >> >> >> >> Example of an "input other than classic credentials"? >> >> >> >> >> >> >> >> >> >> 2 - what=E2=80=99s the classic lifecycle of a credential - i.e. a art= efact >> intended to provide evidence in support of an assertion of identity. (e.= g. >> registration/verification/enrolment, credential issue, credential >> presentation/authentication, credential amendment/revocation/destruction= =E2=80=A6)? >> >> >> >> >> >> Credential is another of those tricky words. Sometimes it means the >> same as an authentication token. Sometimes it has some attributes bound = to >> it, which means it has both an authentication and attribute provision >> flavor to it. I find it simpler to talk about tokens, where one doesn't >> have to deal with revocation when some attribute (employment, for exampl= e) >> changes. >> >> >> >> >> >> >> >> 3 - How does (2) relate to other assertions (e.g. attribute >> assertions) we would like to make reliably? >> >> >> >> >> >> With that starter set, I think we can confirm the subset of >> requirements that 800-63-1 still meets, and define the delta that requir= es >> new design. >> >> >> >> 4 - What=E2=80=99s the right way to update current thinking on LOAs, = to >> account for the change Jim describes in his proposal - i.e., the case wh= ere >> "credentials (used in authentication) and attribute information >> (established through identity proofing) could be provided by different >> parties.=E2=80=9D >> >> >> >> 5 - From Jim=E2=80=99s proposal: =E2=80=9CAttribute reliability refer= s to the quality >> of the identity proofing process, as well as the strength of the binding= of >> the identifying attributes to the authentication.=E2=80=9D Do we need/wa= nt to >> expand on this a little? This seems to cater well for the case where, sa= y, >> vehicle entitlements are being established so that they can be encapsula= ted >> in a driving licence. It=E2=80=99s not so clear how this addresses, say,= third >> party assertions that do not arise from an identity proofing process - = =E2=80=9CI >> have no idea *who* this user is, but I can reliably assert the following >> about them: ... =E2=80=9D. >> >> >> >> You're right; that will need to be defined. But it should be possible >> to define analogous requirements to describe the strength of the binding= to >> the token. When you show up to enroll at school, it should be possible t= o >> use your token to allow your school to make LOR 3 asserts that you're th= ere >> student. But maybe remote students only get LOR 2? >> >> >> >> -Jim >> >> >> > vot mailing list >> > vot@ietf.org >> > https://www.ietf.org/mailman/listinfo/vot >> >> >> _______________________________________________ >> vot mailing list >> vot@ietf.org >> https://www.ietf.org/mailman/listinfo/vot >> >> >> > > > _______________________________________________ > vot mailing list > vot@ietf.org > https://www.ietf.org/mailman/listinfo/vot > > --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D *Scott Shorter, Principal Security Engineer* Electrosoft *=E2=80=93* Fueling Customer Success Through Outstanding Value = and Trust! *Woman-Owned, Minority-Owned Small Business | ISO 9001 | CMMI Level 2 * 1893 Metro Center Drive; Ste 228; Reston, VA 20190 (703) 437-9451 x21 (office); (240) 994-7793 (cell) sshorter@electrosoft-inc.com (Email); http://www.electrosoft-inc.com (Web= ) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --001a11c3cb04ed629d050d2e65be Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Speaking of Estonia, we coincidentally just blogged on the= topic of the Estonian ID card and electronic residency program over at the= Electrosoft blog.

Peter, thanks for bringing up the topic. Tarvi, welc= ome to the discussion!
-
Scott

On Thu, Jan 15, 2015 at 3:54 P= M, Peter Alterman <palterman@safe-biopharma.org> = wrote:
Hi Tarvi,

Agreed, and it gets more interesting this year and next,= when the EC plans to certify services against the Low and Substantial leve= ls, leaving High to the QCP (which includes Estonia, an example to us all).=

Peter

<= div>------------------------------------------------------------
P= eter Alterman, Ph.D.
Chief Operating Officer
SAFE-BioPharma Ass= ociation
cell: 301-943-7452


On Thu, Jan 15= , 2015 at 3:48 PM, Tarvi Martens <tarvi@sk.ee> wrote:
=

Hi,<= /p>

=C2=A0

The principle of= Eurpean eIDAS eID recognition is mainly that =E2=80=9Eif you trust this in= your country then other EU states shall it trust as well in their e-servic= es=E2=80=9C. Oh well, when it is sort of =E2=80=9Eregistered and assessed= =E2=80=9C.

=C2=A0

In general terms it comes down to community (read: RP-s) tr= ust. For example hardly anyone would question Estonian ID-card for it secur= ity after living 13 years of harmless life,

=C2=A0

<= p class=3D"MsoNormal">Tarvi

=C2=A0=

From: vot [mailto:vot-bounces@ietf.org] On Behalf Of P= eter Alterman
Sent: Tuesday, January 13, 2015 8:00 PM
To: vot@ietf.org
Subject: Re: [VoT] vot Digest, Vol 5, Issue 6

=

=C2=A0

=E2=80=8BHappy new year to you all.=C2=A0 = I've been reading the mail but unable to break away long enough to comm= ent until now. As I read it, the issue on the table is how to express trust= worthiness.=C2=A0

=C2=A0

If Abbie was here he'd p= oint you all to the one-to-one correlation between trust and threat/threat = vector mitigation.=E2=80=8B I recommend to you the Third Deliverable of the= OASIS Trust Elevation TC =C2=A0- link provided upon demonstration of curio= sity ;-)

=C2=A0

=C2=A0An RP trusts an external assert= ion of identity (or even extended attributes) to the extent that the assert= ion is created and/or can be verified to a predetermined degree of threat/r= isk mitigation. This degree is baked into policy or contract or some other = pre-existing agreement (think banking regulations, etc.) and is locally det= ermined based upon local considerations, e.g., no global standard is approp= riate.=C2=A0 So far as I can see, vectors of trust are the same thing as th= e threats and threat vectors that are enumerated in ISO 29115 and other pla= ces, not least of which are controls in NIST 800-53-4 and in ISO 27001/2. I= really don't see the vectors as anything different from these and cons= idering trustworthiness as the inverse of threat in this context is pretty = much what everybody seems to be saying.=C2=A0

=C2=A0

= If we just use 29115 as our baseline of threats and threat vectors, there a= re roughly a dozen or so of them associated with authentication of identity= assertion. I don't think any of us believe that a twelve-dimensional a= ssertion is practically viable, even if we could agree on a common metric f= or degree of threat mitigation (fat chance that). This has also already bee= n addressed by the community: think of the factor model, one to four factor= s (the fourth is context, which may be expressed as "Where or when you= are," according to our colleagues). What this does is boil down the t= rust/threat algorithm to no more than four dimensions and shifts the discus= sion to the aforementioned conundrum, e.g., how to evaluate and rate the de= gree of threat mitigation. Various communities have developed policies and = practices to address this question, the most recent of which, I think, is E= U Regulation 910/2014 (eIDAS).=C2=A0

=C2=A0=

IMO, the = greatest opportunity open to us is to find a way to normalize all the vario= us community policies and practices so that RPs can assess whether assertio= ns issued under one community's metrics align with their adopted risk m= itigation requirements. I think that has to be addressed in the context of = how effective a particular mitigation action is on a recognized threat vect= or. =C2=A0 I would be most interested in your thoughts on that problem.<= /u>

=C2=A0

regards,

=C2=A0

Peter


--= ----------------------------------------------------------

Peter Alterman, Ph.D.

=

Chief Operating Officer
SAFE-BioPharma Associatio= n

cell: 301-943-7452

=C2=A0

On Tue, Jan 13, 20= 15 at 8:19 AM, <vot-request@ietf.org> wrote:

Send vot mailing list submissions to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 vot@ietf.org

To su= bscribe or unsubscribe via the World Wide Web, visit
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 https://www.ietf.org/mailman/listinfo/vot
or, via email, sen= d a message with subject or body 'help' to
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 vot-reques= t@ietf.org

You can reach the person managing the list at
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 vot-owner@ietf.org

When replying, please edit your Subject= line so it is more specific
than "Re: Contents of vot digest...&qu= ot;

Today's Topics:

=C2=A0 =C2=A01. Re: capturing the thr= eads of the discussion (Robin Wilton)
=C2=A0 =C2=A02. VoT wiki (Steve Ol= shansky)


---------- Forwarded message ----------
From:=C2=A0R= obin Wilton <wilton= @isoc.org>
To:=C2=A0Colin Wallis <Colin.Wallis@dia.govt.nz>
Cc:= =C2=A0Jim Fenton <fenton@bluepopcorn.net>, "vot@ietf.org" <vot@ietf.org>
Date:=C2=A0Tue, 13 Jan 2015 09= :31:59 +0000
Subject:=C2=A0Re: [VoT] capturing the threads of the discus= sion

Oops - I'd forgo= tten about the wiki: apologies! Yes, I think that's the place to start.= ..

=C2=A0<= /p>

R

Robin Wilton

=C2=A0

Technical Outreach Director - Identity and Privacy

=


On 12 Jan 2015, at 23:43, "Colin Wallis" <Colin.Wallis@dia.govt.nz> wrote:

Well as Steve O pointed out in this attached email in November, the wi= ki set up for this work might be a place to start..

There may be some jigger= y pokery to get the folks on this list who want to contribute (who were not= attendees at Utrecht) access rights, but it would seem to me to be the obv= ious starter option for a repository.

Cheers

Colin

<= p class=3D"MsoNormal" style=3D"margin-left:36.0pt">PS: BTW this is a good discussion and indeed an opportunistic time to br= ing it together since so much of what Justin, Jim, Scott, Ken, Steve W, Mar= k et al have commented recently is complementary (well at least not complet= ely contradictory or orthogonal) so let=E2=80=99s grab it!

=C2=A0=

From: vot [mailto:vot-bounces@ietf.org] = On Behalf Of Robin Wilton
Sent: Tuesday, 13 January 2015 11:2= 2 a.m.
To: Jim Fenton
Cc: vot@ietf.org
Subject: Re: [VoT] capturin= g the threads of the discussion

=C2=A0

Thanks = Jim,

=C2=A0

I won't give a substantive respo= nse here; just to note that I think it's worth considering a repository= so that we can capture 'static' versions of any straw-man docs, to= complement what we it into the mail thread...

=

=C2=A0

Sorry to be brief at this stage - just tying up some loose ends befor= e an absence from the office.

=C2=A0

R

Ro= bin Wilton

=C2=A0

Technical Outreach Director - Identity an= d Privacy


On 12 Jan 2015, at 21:45, "Jim Fenton= " <fent= on@bluepopcorn.net> wrote:

= Maybe I should be breaking these apart as Robin suggests, but for now I'= ;ll keep this in one reply:

On 1/12/15 6:06 AM, Robin Wilton wrote:<= u>

This thread raises several important topics= =E2=80=A6 just as a practical matter, it might be worth trying to spin some= of them off separately, so that we address them all, and minimise the risk= of talking at cross-purposes. =C2=A0

It feels like it would be worth trying to put together some *very s= hort* straw-man docs/pages/paragraphs to try and get a consensus version on= specific points, so that we avoid re-hashing the same arguments/discussion= s over time, or at least have something we can refer to - and amend if nece= ssary. I think this is aiming at the same end-point as Steve=E2=80=99s requ= est for a statement of requirements, but will ensure we=E2=80=99re expressi= ng our requirements in a consistent set of terms.

=C2=A0

By the looks of it, these= would make for a good starting point (I think the answers to most of these= are implicit in various people=E2=80=99s contributions to the thread=E2=80= =A6 but that doesn=E2=80=99t mean everyone agrees ;^) =C2=A0):

=C2=A0

1 - w= hat do we mean by authentication and authorisation? Are there other decisio= ns (e.g. access control, entitlement) which need to be called out explicitl= y? This reflects the purpose of Justin=E2=80=99s questions. Classically, th= e reason for authenticating a user is to answer a yes/no question (is this = the person to whom this credential was originally issued); if yes, what do = I want to do about it (at which point the further entitlements are usually = determined by retrieving a user profile, ACL or whatever)?=


Access control and entitlement as distinct from authorisation? Is= there a distinction, or are people just using different terminology?
I think of authentication as providing more than a yes/no answer: it prov= ides an identifier. If the relying party has enough information (perhaps on= the basis of previous interactions) to authorize something with just that,= fine. Otherwise some attributes are needed to make an authorisation decisi= on.

However,= as we know, these days access control and entitlement decisions also need = to be made on the basis of input other than classic credentials, and that= =E2=80=99s one of the two cores of this discussion, I believe.

Example of an "input other than classic credentials"?

=

<= u>=C2=A0

2 - what=E2=80=99s the classic lifecycle of a creden= tial - i.e. a artefact intended to provide evidence in support of an assert= ion of identity. (e.g. registration/verification/enrolment, credential issu= e, credential presentation/authentication, credential amendment/revocation/= destruction=E2=80=A6)?


Credential is another of those tricky = words. Sometimes it means the same as an authentication token. Sometimes it= has some attributes bound to it, which means it has both an authentication= and attribute provision flavor to it. I find it simpler to talk about toke= ns, where one doesn't have to deal with revocation when some attribute = (employment, for example) changes.

=C2=A0

3 - How does (2) relate to other assertions (e= .g. attribute assertions) we would like to make reliably?<= /u>

= =C2=A0

With that starter se= t, I think we can confirm the subset of requirements that 800-63-1 still me= ets, and define the delta that requires new design.

=

=C2=A0

4 - What=E2=80=99s the right way to update current thinking on L= OAs, to account for the change Jim describes in his proposal - i.e., the ca= se where "credentials (used = in authentication) and attribute information (established through identity = proofing) could be provided by different parties.=E2=80=9D

= =C2=A0

5 - From Jim=E2= =80=99s proposal: =E2=80=9CAttribute reliability r= efers to the quality of the identity proofing process, as well as the stren= gth of the binding of the identifying attributes to the authentication.=E2=80=9D Do we need/want to expand on this a little? This seems to cate= r well for the case where, say, vehicle entitlements are being established = so that they can be encapsulated in a driving licence. It=E2=80=99s not so = clear how this addresses, say, third party assertions that do not arise fro= m an identity proofing process - =E2=80=9CI have no idea *who* this user is= , but I can reliably assert the following about them: ... =E2=80=9D.=


= You're right; that will need to be defined. But it should be possible t= o define analogous requirements to describe the strength of the binding to = the token. When you show up to enroll at school, it should be possible to u= se your token to allow your school to make LOR 3 asserts that you're th= ere student. But maybe remote students only get LOR 2?

-Jim

All-
There unfortunately is a long-standing bug in = Confluence. You must be logged in before that link, or any link to a restri= cted page, will work.

The wiki space for workshop attendees only, wh= ich you all have full edit access to and which is not publicly viewable, is= athttps://tid.isoc.org/confluence/display/interfedgen/

T= he *PUBLIC* wiki space, containing the agenda, presentations, and contribut= ions/references, is at
https://tid.isoc.org/confluence/display/inte= rfed/

As we make progress on work items and are ready to move th= em to the public wiki, I will be happy to do that. Our goal is of course to= make as much of our work as possible available to the public, but this res= tricted wiki space gives us a place to work on things before revealing them= to the world.

As always, if anyone has questions or problems relate= d to the wiki, or anything else, please do let me know.
=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0Steve

--
Steve Olshansky
Trust &= ; Identity Program Lead
Internet Society
www.internetsociety.org

=

<signature.asc>

______________________________________= _________
Ideco-fab mailing list
Ideco-fab@elists.isoc.org
https://e= lists.isoc.org/mailman/listinfo/ideco-fab



= ---------- Forwarded message ----------
From:=C2=A0Steve Olshansky <<= a href=3D"mailto:olshansky@isoc.org" target=3D"_blank">olshansky@isoc.org>
To:=C2=A0"= vot@ietf.org" <vot@ietf.org>
Cc:=C2=A0
Date:=C2=A0Tue, 13 Jan 2015 13:19:22= +0000
Subject:=C2=A0[VoT] VoT wiki
All-
This is a great discussio= n, and the stars seem to be aligning now for the development of some docume= nts or any other related artifacts.

I setup a dedicated wiki space f= or use by this group. It is open to the world for viewing, but we can easil= y make restricted areas for the purpose of working on documents before publ= ishing. Anyone would would like edit access is welcome to contact me direct= ly (off-list).
https://tid.isoc.org/confluence/display/vot/VoT+H= ome
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Steve

--
Steve OlshanskyTrust & Identity Program Lead
Internet Society
www.internetsociety.org
On Jan 13, 2015, at 2:31 AM, Robin Wilton <wilton@isoc.org> wrote:

> Oop= s - I'd forgotten about the wiki: apologies! Yes, I think that's th= e place to start...
>
> R
>
> Robin Wilton
><= br>> Technical Outreach Director - Identity and Privacy
>
> = On 12 Jan 2015, at 23:43, "Colin Wallis" <Colin.Wallis@dia.govt.nz> = wrote:
>
>> Well as Steve O pointed out in this attached ema= il in November, the wiki set up for this work might be a place to start..>> There may be some jiggery pokery to get the folks on this list w= ho want to contribute (who were not attendees at Utrecht) access rights, bu= t it would seem to me to be the obvious starter option for a repository.>> Cheers
>> Colin
>> PS: BTW this is a good discu= ssion and indeed an opportunistic time to bring it together since so much o= f what Justin, Jim, Scott, Ken, Steve W, Mark et al have commented recently= is complementary (well at least not completely contradictory or orthogonal= ) so let=E2=80=99s grab it!
>>
>> From: vot [mailto:vot-bounces@ietf.org] On Behalf Of Robin Wilton
>> Sent: Tuesday, 13 January 2015 11= :22 a.m.
>> To: Jim Fenton
>> Cc: vot@ietf.org
>> Subject: Re: [VoT] = capturing the threads of the discussion
>>
>> Thanks Jim,=
>>
>> I won't give a substantive response here; just= to note that I think it's worth considering a repository so that we ca= n capture 'static' versions of any straw-man docs, to complement wh= at we it into the mail thread...
>>
>> Sorry to be brief = at this stage - just tying up some loose ends before an absence from the of= fice.
>>
>> R
>>
>> Robin Wilton
>= ;>
>> Technical Outreach Director - Identity and Privacy
>= ;>
>> On 12 Jan 2015, at 21:45, "Jim Fenton" <fenton@bluepopcorn.= net> wrote:
>>
>> Maybe I should be breaking these= apart as Robin suggests, but for now I'll keep this in one reply:
&= gt;>
>> On 1/12/15 6:06 AM, Robin Wilton wrote:
>> Thi= s thread raises several important topics=E2=80=A6 just as a practical matte= r, it might be worth trying to spin some of them off separately, so that we= address them all, and minimise the risk of talking at cross-purposes.
&= gt;> It feels like it would be worth trying to put together some *very s= hort* straw-man docs/pages/paragraphs to try and get a consensus version on= specific points, so that we avoid re-hashing the same arguments/discussion= s over time, or at least have something we can refer to - and amend if nece= ssary. I think this is aiming at the same end-point as Steve=E2=80=99s requ= est for a statement of requirements, but will ensure we=E2=80=99re expressi= ng our requirements in a consistent set of terms.
>>
>>>> By the looks of it, these would make for a good starting point (= I think the answers to most of these are implicit in various people=E2=80= =99s contributions to the thread=E2=80=A6 but that doesn=E2=80=99t mean eve= ryone agrees ;^)=C2=A0 ):
>>
>>
>> 1 - what do w= e mean by authentication and authorisation? Are there other decisions (e.g.= access control, entitlement) which need to be called out explicitly? This = reflects the purpose of Justin=E2=80=99s questions. Classically, the reason= for authenticating a user is to answer a yes/no question (is this the pers= on to whom this credential was originally issued); if yes, what do I want t= o do about it (at which point the further entitlements are usually determin= ed by retrieving a user profile, ACL or whatever)?
>>
>> = Access control and entitlement as distinct from authorisation? Is there a d= istinction, or are people just using different terminology?
>>
= >> I think of authentication as providing more than a yes/no answer: = it provides an identifier. If the relying party has enough information (per= haps on the basis of previous interactions) to authorize something with jus= t that, fine. Otherwise some attributes are needed to make an authorisation= decision.
>>
>>
>> However, as we know, these d= ays access control and entitlement decisions also need to be made on the ba= sis of input other than classic credentials, and that=E2=80=99s one of the = two cores of this discussion, I believe.
>>
>> Example of= an "input other than classic credentials"?
>>
>&g= t;
>>
>>
>> 2 - what=E2=80=99s the classic lifec= ycle of a credential - i.e. a artefact intended to provide evidence in supp= ort of an assertion of identity. (e.g. registration/verification/enrolment,= credential issue, credential presentation/authentication, credential amend= ment/revocation/destruction=E2=80=A6)?
>>
>>
>> = Credential is another of those tricky words. Sometimes it means the same as= an authentication token. Sometimes it has some attributes bound to it, whi= ch means it has both an authentication and attribute provision flavor to it= . I find it simpler to talk about tokens, where one doesn't have to dea= l with revocation when some attribute (employment, for example) changes.>>
>>
>>
>> 3 - How does (2) relate to ot= her assertions (e.g. attribute assertions) we would like to make reliably?<= br>>>
>>
>> With that starter set, I think we can c= onfirm the subset of requirements that 800-63-1 still meets, and define the= delta that requires new design.
>>
>> 4 - What=E2=80=99s= the right way to update current thinking on LOAs, to account for the chang= e Jim describes in his proposal - i.e., the case where "credentials (u= sed in authentication) and attribute information (established through ident= ity proofing) could be provided by different parties.=E2=80=9D
>><= br>>> 5 - From Jim=E2=80=99s proposal: =E2=80=9CAttribute reliability= refers to the quality of the identity proofing process, as well as the str= ength of the binding of the identifying attributes to the authentication.= =E2=80=9D Do we need/want to expand on this a little? This seems to cater w= ell for the case where, say, vehicle entitlements are being established so = that they can be encapsulated in a driving licence. It=E2=80=99s not so cle= ar how this addresses, say, third party assertions that do not arise from a= n identity proofing process - =E2=80=9CI have no idea *who* this user is, b= ut I can reliably assert the following about them: ... =E2=80=9D.
>&g= t;
>> You're right; that will need to be defined. But it shoul= d be possible to define analogous requirements to describe the strength of = the binding to the token. When you show up to enroll at school, it should b= e possible to use your token to allow your school to make LOR 3 asserts tha= t you're there student. But maybe remote students only get LOR 2?
&g= t;>
>> -Jim
>>
> vot mailing list
> vot@ietf.org
> https://w= ww.ietf.org/mailman/listinfo/vot


___________________________= ____________________
vot mailing list
vot@ietf.org
https://www.ietf.org/mailman/listinfo/v= ot

=C2=A0



_______________________________________________
vot mailing list
vot@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/vot




--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Scott Shorter, Principal Security Eng= ineer
Electrosoft=C2=A0=E2=80=93=C2=A0Fueling Custome= r Success Through Outstanding Value and Trust!
Woman-Owned, Minority-Owne= d Small Business | ISO 9001 | CMMI Level 2=C2=A0
1893 Metro Center Drive; Ste 2= 28; Reston, VA 20190
(703)=C2=A0437-9451 x21=C2=A0(office);=C2=A0=C2=A0= =C2=A0(240) 994-7793=C2=A0(cell)
sshorter@electrosoft-inc.com=C2=A0(Email);=C2=A0=C2=A0= =C2=A0http://www.electrosoft-i= nc.com=C2=A0(Web)
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--001a11c3cb04ed629d050d2e65be-- From nobody Wed Jan 21 11:52:38 2015 Return-Path: X-Original-To: vot@ietfa.amsl.com Delivered-To: vot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03D251A875E for ; Wed, 21 Jan 2015 11:52:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.779 X-Spam-Level: ** X-Spam-Status: No, score=2.779 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, MANGLED_MARKET=2.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 iuHSJUrcAh3w for ; Wed, 21 Jan 2015 11:52:28 -0800 (PST) Received: from mta5.uth.tmc.edu (mta5.uth.tmc.edu [129.106.149.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D51681A8759 for ; Wed, 21 Jan 2015 11:52:27 -0800 (PST) Received: from pps.filterd (mta5.uth.tmc.edu [127.0.0.1]) by mta5.uth.tmc.edu (8.14.5/8.14.5) with SMTP id t0LJqA1p002022; Wed, 21 Jan 2015 13:52:26 -0600 Received: from uthmail2.uthouston.edu ([129.106.175.239]) by mta5.uth.tmc.edu with ESMTP id 1s2h400kpx-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 21 Jan 2015 13:52:24 -0600 Received: from UTHMAIL1.uthouston.edu ([fe80::c1d2:3f6a:4f56:4fa4]) by UTHMAIL2.uthouston.edu ([fe80::78fb:d7a3:fc1f:7b1e%21]) with mapi id 14.03.0210.002; Wed, 21 Jan 2015 13:52:23 -0600 From: "Jones, Mark B" To: Scott Shorter , Peter Alterman Thread-Topic: [VoT] vot Digest, Vol 5, Issue 6 Thread-Index: AQHQL1rW789c+MN2zUauEOP7MuQgPpzCDxAAgAABooCACVLOgP//pKSQ Date: Wed, 21 Jan 2015 19:52:22 +0000 Message-ID: <38AAF00EA635514CA6667ACA60C7F0A548A10EA6@UTHMAIL1.uthouston.edu> References: <06c901d03104$998031d0$cc809570$@sk.ee> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [129.106.8.25] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00E4_01D03581.7A9A72E0" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2015-01-21_04:2015-01-21,2015-01-21,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 kscore.is_bulkscore=5.00997843211337e-09 kscore.compositescore=0 circleOfTrustscore=0 compositescore=0.473913523325043 urlsuspect_oldscore=0.473913523325043 suspectscore=0 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=0 rbsscore=0.473913523325043 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1501210193 Archived-At: Cc: Tarvi Martens , "vot@ietf.org" Subject: Re: [VoT] vot Digest, Vol 5, Issue 6 X-BeenThere: vot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Vectors of Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 19:52:36 -0000 ------=_NextPart_000_00E4_01D03581.7A9A72E0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_00E5_01D03581.7A9A72E0" ------=_NextPart_001_00E5_01D03581.7A9A72E0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Scott, Thanks for that link. I=E2=80=99m already considering a trip to the = Estonian Embassy to get an ID. =20 From: vot [mailto:vot-bounces@ietf.org] On Behalf Of Scott Shorter Sent: Wednesday, January 21, 2015 1:17 PM To: Peter Alterman Cc: Tarvi Martens; vot@ietf.org Subject: Re: [VoT] vot Digest, Vol 5, Issue 6 =20 Speaking of Estonia, we coincidentally just blogged on the topic of the = Estonian ID card and electronic residency program over at the = Electrosoft blog = . =20 Peter, thanks for bringing up the topic. Tarvi, welcome to the = discussion! - Scott =20 On Thu, Jan 15, 2015 at 3:54 PM, Peter Alterman = wrote: Hi Tarvi, =20 Agreed, and it gets more interesting this year and next, when the EC = plans to certify services against the Low and Substantial levels, = leaving High to the QCP (which includes Estonia, an example to us all). =20 Peter ------------------------------------------------------------ Peter Alterman, Ph.D. Chief Operating Officer SAFE-BioPharma Association cell: 301-943-7452 =20 On Thu, Jan 15, 2015 at 3:48 PM, Tarvi Martens wrote: Hi, =20 The principle of Eurpean eIDAS eID recognition is mainly that = =E2=80=9Eif you trust this in your country then other EU states shall it = trust as well in their e-services=E2=80=9C. Oh well, when it is sort of = =E2=80=9Eregistered and assessed=E2=80=9C. =20 In general terms it comes down to community (read: RP-s) trust. For = example hardly anyone would question Estonian ID-card for it security = after living 13 years of harmless life, =20 Tarvi=20 =20 From: vot [mailto:vot-bounces@ietf.org] On Behalf Of Peter Alterman Sent: Tuesday, January 13, 2015 8:00 PM To: vot@ietf.org Subject: Re: [VoT] vot Digest, Vol 5, Issue 6 =20 =E2=80=8BHappy new year to you all. I've been reading the mail but = unable to break away long enough to comment until now. As I read it, the = issue on the table is how to express trustworthiness.=20 =20 If Abbie was here he'd point you all to the one-to-one correlation = between trust and threat/threat vector mitigation.=E2=80=8B I recommend = to you the Third Deliverable of the OASIS Trust Elevation TC - link = provided upon demonstration of curiosity ;-) =20 An RP trusts an external assertion of identity (or even extended = attributes) to the extent that the assertion is created and/or can be = verified to a predetermined degree of threat/risk mitigation. This = degree is baked into policy or contract or some other pre-existing = agreement (think banking regulations, etc.) and is locally determined = based upon local considerations, e.g., no global standard is = appropriate. So far as I can see, vectors of trust are the same thing = as the threats and threat vectors that are enumerated in ISO 29115 and = other places, not least of which are controls in NIST 800-53-4 and in = ISO 27001/2. I really don't see the vectors as anything different from = these and considering trustworthiness as the inverse of threat in this = context is pretty much what everybody seems to be saying.=20 =20 If we just use 29115 as our baseline of threats and threat vectors, = there are roughly a dozen or so of them associated with authentication = of identity assertion. I don't think any of us believe that a = twelve-dimensional assertion is practically viable, even if we could = agree on a common metric for degree of threat mitigation (fat chance = that). This has also already been addressed by the community: think of = the factor model, one to four factors (the fourth is context, which may = be expressed as "Where or when you are," according to our colleagues). = What this does is boil down the trust/threat algorithm to no more than = four dimensions and shifts the discussion to the aforementioned = conundrum, e.g., how to evaluate and rate the degree of threat = mitigation. Various communities have developed policies and practices to = address this question, the most recent of which, I think, is EU = Regulation 910/2014 (eIDAS).=20 =20 IMO, the greatest opportunity open to us is to find a way to normalize = all the various community policies and practices so that RPs can assess = whether assertions issued under one community's metrics align with their = adopted risk mitigation requirements. I think that has to be addressed = in the context of how effective a particular mitigation action is on a = recognized threat vector. I would be most interested in your thoughts = on that problem. =20 regards, =20 Peter ------------------------------------------------------------ Peter Alterman, Ph.D. Chief Operating Officer SAFE-BioPharma Association cell: 301-943-7452 =20 On Tue, Jan 13, 2015 at 8:19 AM, wrote: Send vot mailing list submissions to vot@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/vot = =20 or, via email, send a message with subject or body 'help' to vot-request@ietf.org You can reach the person managing the list at vot-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of vot digest..." Today's Topics: 1. Re: capturing the threads of the discussion (Robin Wilton) 2. VoT wiki (Steve Olshansky) ---------- Forwarded message ---------- From: Robin Wilton To: Colin Wallis Cc: Jim Fenton , "vot@ietf.org" Date: Tue, 13 Jan 2015 09:31:59 +0000 Subject: Re: [VoT] capturing the threads of the discussion Oops - I'd forgotten about the wiki: apologies! Yes, I think that's the = place to start... =20 R Robin Wilton=20 =20 Technical Outreach Director - Identity and Privacy On 12 Jan 2015, at 23:43, "Colin Wallis" = wrote: Well as Steve O pointed out in this attached email in November, the wiki = set up for this work might be a place to start.. There may be some jiggery pokery to get the folks on this list who want = to contribute (who were not attendees at Utrecht) access rights, but it = would seem to me to be the obvious starter option for a repository. Cheers Colin=20 PS: BTW this is a good discussion and indeed an opportunistic time to = bring it together since so much of what Justin, Jim, Scott, Ken, Steve = W, Mark et al have commented recently is complementary (well at least = not completely contradictory or orthogonal) so let=E2=80=99s grab it!=20 =20 From: vot [mailto:vot-bounces@ietf.org] On Behalf Of Robin Wilton Sent: Tuesday, 13 January 2015 11:22 a.m. To: Jim Fenton Cc: vot@ietf.org Subject: Re: [VoT] capturing the threads of the discussion =20 Thanks Jim, =20 I won't give a substantive response here; just to note that I think it's = worth considering a repository so that we can capture 'static' versions = of any straw-man docs, to complement what we it into the mail thread... =20 Sorry to be brief at this stage - just tying up some loose ends before = an absence from the office. =20 R Robin Wilton=20 =20 Technical Outreach Director - Identity and Privacy On 12 Jan 2015, at 21:45, "Jim Fenton" wrote: Maybe I should be breaking these apart as Robin suggests, but for now = I'll keep this in one reply: On 1/12/15 6:06 AM, Robin Wilton wrote: This thread raises several important topics=E2=80=A6 just as a practical = matter, it might be worth trying to spin some of them off separately, so = that we address them all, and minimise the risk of talking at = cross-purposes. =20 It feels like it would be worth trying to put together some *very short* = straw-man docs/pages/paragraphs to try and get a consensus version on = specific points, so that we avoid re-hashing the same = arguments/discussions over time, or at least have something we can refer = to - and amend if necessary. I think this is aiming at the same = end-point as Steve=E2=80=99s request for a statement of requirements, = but will ensure we=E2=80=99re expressing our requirements in a = consistent set of terms. =20 By the looks of it, these would make for a good starting point (I think = the answers to most of these are implicit in various people=E2=80=99s = contributions to the thread=E2=80=A6 but that doesn=E2=80=99t mean = everyone agrees ;^) ): =20 1 - what do we mean by authentication and authorisation? Are there other = decisions (e.g. access control, entitlement) which need to be called out = explicitly? This reflects the purpose of Justin=E2=80=99s questions. = Classically, the reason for authenticating a user is to answer a yes/no = question (is this the person to whom this credential was originally = issued); if yes, what do I want to do about it (at which point the = further entitlements are usually determined by retrieving a user = profile, ACL or whatever)? Access control and entitlement as distinct from authorisation? Is there = a distinction, or are people just using different terminology? I think of authentication as providing more than a yes/no answer: it = provides an identifier. If the relying party has enough information = (perhaps on the basis of previous interactions) to authorize something = with just that, fine. Otherwise some attributes are needed to make an = authorisation decision. However, as we know, these days access control and entitlement decisions = also need to be made on the basis of input other than classic = credentials, and that=E2=80=99s one of the two cores of this discussion, = I believe. Example of an "input other than classic credentials"? =20 2 - what=E2=80=99s the classic lifecycle of a credential - i.e. a = artefact intended to provide evidence in support of an assertion of = identity. (e.g. registration/verification/enrolment, credential issue, = credential presentation/authentication, credential = amendment/revocation/destruction=E2=80=A6)?=20 Credential is another of those tricky words. Sometimes it means the same = as an authentication token. Sometimes it has some attributes bound to = it, which means it has both an authentication and attribute provision = flavor to it. I find it simpler to talk about tokens, where one doesn't = have to deal with revocation when some attribute (employment, for = example) changes. =20 3 - How does (2) relate to other assertions (e.g. attribute assertions) = we would like to make reliably? =20 With that starter set, I think we can confirm the subset of requirements = that 800-63-1 still meets, and define the delta that requires new = design. =20 4 - What=E2=80=99s the right way to update current thinking on LOAs, to = account for the change Jim describes in his proposal - i.e., the case = where "credentials (used in authentication) and attribute information = (established through identity proofing) could be provided by different = parties.=E2=80=9D =20 5 - From Jim=E2=80=99s proposal: =E2=80=9CAttribute reliability refers = to the quality of the identity proofing process, as well as the strength = of the binding of the identifying attributes to the = authentication.=E2=80=9D Do we need/want to expand on this a little? = This seems to cater well for the case where, say, vehicle entitlements = are being established so that they can be encapsulated in a driving = licence. It=E2=80=99s not so clear how this addresses, say, third party = assertions that do not arise from an identity proofing process - = =E2=80=9CI have no idea *who* this user is, but I can reliably assert = the following about them: ... =E2=80=9D. You're right; that will need to be defined. But it should be possible to = define analogous requirements to describe the strength of the binding to = the token. When you show up to enroll at school, it should be possible = to use your token to allow your school to make LOR 3 asserts that you're = there student. But maybe remote students only get LOR 2? -Jim All- There unfortunately is a long-standing bug in Confluence. You must be = logged in before that link, or any link to a restricted page, will work. The wiki space for workshop attendees only, which you all have full edit = access to and which is not publicly viewable, is = athttps://tid.isoc.org/confluence/display/interfedgen/ = =20 The *PUBLIC* wiki space, containing the agenda, presentations, and = contributions/references, is at https://tid.isoc.org/confluence/display/interfed/ = =20 As we make progress on work items and are ready to move them to the = public wiki, I will be happy to do that. Our goal is of course to make = as much of our work as possible available to the public, but this = restricted wiki space gives us a place to work on things before = revealing them to the world. As always, if anyone has questions or problems related to the wiki, or = anything else, please do let me know. Steve -- Steve Olshansky Trust & Identity Program Lead Internet Society www.internetsociety.org = =20 _______________________________________________ Ideco-fab mailing list Ideco-fab@elists.isoc.org https://elists.isoc.org/mailman/listinfo/ideco-fab = =20 ---------- Forwarded message ---------- From: Steve Olshansky To: "vot@ietf.org" Cc:=20 Date: Tue, 13 Jan 2015 13:19:22 +0000 Subject: [VoT] VoT wiki All- This is a great discussion, and the stars seem to be aligning now for = the development of some documents or any other related artifacts. I setup a dedicated wiki space for use by this group. It is open to the = world for viewing, but we can easily make restricted areas for the = purpose of working on documents before publishing. Anyone would would = like edit access is welcome to contact me directly (off-list). https://tid.isoc.org/confluence/display/vot/VoT+Home = =20 Steve -- Steve Olshansky Trust & Identity Program Lead Internet Society www.internetsociety.org = =20 On Jan 13, 2015, at 2:31 AM, Robin Wilton wrote: > Oops - I'd forgotten about the wiki: apologies! Yes, I think that's = the place to start... > > R > > Robin Wilton > > Technical Outreach Director - Identity and Privacy > > On 12 Jan 2015, at 23:43, "Colin Wallis" = wrote: > >> Well as Steve O pointed out in this attached email in November, the = wiki set up for this work might be a place to start.. >> There may be some jiggery pokery to get the folks on this list who = want to contribute (who were not attendees at Utrecht) access rights, = but it would seem to me to be the obvious starter option for a = repository. >> Cheers >> Colin >> PS: BTW this is a good discussion and indeed an opportunistic time to = bring it together since so much of what Justin, Jim, Scott, Ken, Steve = W, Mark et al have commented recently is complementary (well at least = not completely contradictory or orthogonal) so let=E2=80=99s grab it! >> >> From: vot [mailto:vot-bounces@ietf.org] On Behalf Of Robin Wilton >> Sent: Tuesday, 13 January 2015 11:22 a.m. >> To: Jim Fenton >> Cc: vot@ietf.org >> Subject: Re: [VoT] capturing the threads of the discussion >> >> Thanks Jim, >> >> I won't give a substantive response here; just to note that I think = it's worth considering a repository so that we can capture 'static' = versions of any straw-man docs, to complement what we it into the mail = thread... >> >> Sorry to be brief at this stage - just tying up some loose ends = before an absence from the office. >> >> R >> >> Robin Wilton >> >> Technical Outreach Director - Identity and Privacy >> >> On 12 Jan 2015, at 21:45, "Jim Fenton" = wrote: >> >> Maybe I should be breaking these apart as Robin suggests, but for now = I'll keep this in one reply: >> >> On 1/12/15 6:06 AM, Robin Wilton wrote: >> This thread raises several important topics=E2=80=A6 just as a = practical matter, it might be worth trying to spin some of them off = separately, so that we address them all, and minimise the risk of = talking at cross-purposes. >> It feels like it would be worth trying to put together some *very = short* straw-man docs/pages/paragraphs to try and get a consensus = version on specific points, so that we avoid re-hashing the same = arguments/discussions over time, or at least have something we can refer = to - and amend if necessary. I think this is aiming at the same = end-point as Steve=E2=80=99s request for a statement of requirements, = but will ensure we=E2=80=99re expressing our requirements in a = consistent set of terms. >> >> >> By the looks of it, these would make for a good starting point (I = think the answers to most of these are implicit in various = people=E2=80=99s contributions to the thread=E2=80=A6 but that = doesn=E2=80=99t mean everyone agrees ;^) ): >> >> >> 1 - what do we mean by authentication and authorisation? Are there = other decisions (e.g. access control, entitlement) which need to be = called out explicitly? This reflects the purpose of Justin=E2=80=99s = questions. Classically, the reason for authenticating a user is to = answer a yes/no question (is this the person to whom this credential was = originally issued); if yes, what do I want to do about it (at which = point the further entitlements are usually determined by retrieving a = user profile, ACL or whatever)? >> >> Access control and entitlement as distinct from authorisation? Is = there a distinction, or are people just using different terminology? >> >> I think of authentication as providing more than a yes/no answer: it = provides an identifier. If the relying party has enough information = (perhaps on the basis of previous interactions) to authorize something = with just that, fine. Otherwise some attributes are needed to make an = authorisation decision. >> >> >> However, as we know, these days access control and entitlement = decisions also need to be made on the basis of input other than classic = credentials, and that=E2=80=99s one of the two cores of this discussion, = I believe. >> >> Example of an "input other than classic credentials"? >> >> >> >> >> 2 - what=E2=80=99s the classic lifecycle of a credential - i.e. a = artefact intended to provide evidence in support of an assertion of = identity. (e.g. registration/verification/enrolment, credential issue, = credential presentation/authentication, credential = amendment/revocation/destruction=E2=80=A6)? >> >> >> Credential is another of those tricky words. Sometimes it means the = same as an authentication token. Sometimes it has some attributes bound = to it, which means it has both an authentication and attribute provision = flavor to it. I find it simpler to talk about tokens, where one doesn't = have to deal with revocation when some attribute (employment, for = example) changes. >> >> >> >> 3 - How does (2) relate to other assertions (e.g. attribute = assertions) we would like to make reliably? >> >> >> With that starter set, I think we can confirm the subset of = requirements that 800-63-1 still meets, and define the delta that = requires new design. >> >> 4 - What=E2=80=99s the right way to update current thinking on LOAs, = to account for the change Jim describes in his proposal - i.e., the case = where "credentials (used in authentication) and attribute information = (established through identity proofing) could be provided by different = parties.=E2=80=9D >> >> 5 - From Jim=E2=80=99s proposal: =E2=80=9CAttribute reliability = refers to the quality of the identity proofing process, as well as the = strength of the binding of the identifying attributes to the = authentication.=E2=80=9D Do we need/want to expand on this a little? = This seems to cater well for the case where, say, vehicle entitlements = are being established so that they can be encapsulated in a driving = licence. It=E2=80=99s not so clear how this addresses, say, third party = assertions that do not arise from an identity proofing process - = =E2=80=9CI have no idea *who* this user is, but I can reliably assert = the following about them: ... =E2=80=9D. >> >> You're right; that will need to be defined. But it should be possible = to define analogous requirements to describe the strength of the binding = to the token. When you show up to enroll at school, it should be = possible to use your token to allow your school to make LOR 3 asserts = that you're there student. But maybe remote students only get LOR 2? >> >> -Jim >> > vot mailing list > vot@ietf.org > https://www.ietf.org/mailman/listinfo/vot = =20 _______________________________________________ vot mailing list vot@ietf.org https://www.ietf.org/mailman/listinfo/vot = =20 =20 =20 _______________________________________________ vot mailing list vot@ietf.org https://www.ietf.org/mailman/listinfo/vot = =20 =20 --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Scott Shorter, Principal Security Engineer Electrosoft =E2=80=93 Fueling Customer Success Through Outstanding Value = and Trust! Woman-Owned, Minority-Owned Small Business | ISO 9001 | CMMI Level 2=20 1893 Metro Center Drive; Ste 228; Reston, VA 20190 (703) 437-9451 x21 (office); (240) 994-7793 (cell) sshorter@electrosoft-inc.com (Email); http://www.electrosoft-inc.com = = (Web) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ------=_NextPart_001_00E5_01D03581.7A9A72E0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Scott,

Thanks for that link.=C2=A0 I=E2=80=99m already considering a trip to = the Estonian Embassy to get an ID.

 

From:= = vot [mailto:vot-bounces@ietf.org] On Behalf Of Scott = Shorter
Sent: Wednesday, January 21, 2015 1:17 = PM
To: Peter Alterman
Cc: Tarvi Martens; = vot@ietf.org
Subject: Re: [VoT] vot Digest, Vol 5, Issue = 6

 

Speaking of Estonia, we coincidentally just blogged on = the topic of the Estonian ID card and electronic residency program over = at the Electrosoft = blog.

 

Peter, thanks for bringing up the topic. Tarvi, = welcome to the discussion!

-

Scott

 

On Thu, = Jan 15, 2015 at 3:54 PM, Peter Alterman <palterman@safe-biopharma.org> = wrote:

Hi Tarvi,

 

Agreed, and it gets more = interesting this year and next, when the EC plans to certify services = against the Low and Substantial levels, leaving High to the QCP (which = includes Estonia, an example to us = all).

 

Peter


-------------------------------------------------------= -----

Peter Alterman, = Ph.D.

Chief Operating = Officer
SAFE-BioPharma Association

cell: 301-943-7452

 

On Thu, Jan 15, 2015 at 3:48 PM, Tarvi Martens <tarvi@sk.ee> = wrote:

Hi,

 

The principle of Eurpean eIDAS eID recognition is mainly that = =E2=80=9Eif you trust this in your country then other EU states shall it = trust as well in their e-services=E2=80=9C. Oh well, when it is sort of = =E2=80=9Eregistered and assessed=E2=80=9C.

 

In general terms it comes down to community (read: RP-s) trust. For = example hardly anyone would question Estonian ID-card for it security = after living 13 years of harmless life,

 

Tarvi

 

From:= = vot [mailto:vot-bounces@ietf.org] On Behalf Of Peter = Alterman
Sent: Tuesday, January 13, 2015 8:00 PM
To: = vot@ietf.org
Subject: Re: [VoT] vot = Digest, Vol 5, Issue 6

 

=E2=80=8BHappy new year to you = all.  I've been reading the mail but unable to break away long = enough to comment until now. As I read it, the issue on the table is how = to express trustworthiness. 

 

If Abbie was here he'd point you all to = the one-to-one correlation between trust and threat/threat vector = mitigation.=E2=80=8B I recommend to you the Third Deliverable of the = OASIS Trust Elevation TC  - link provided upon demonstration of = curiosity ;-)

 

 An RP trusts an external assertion = of identity (or even extended attributes) to the extent that the = assertion is created and/or can be verified to a predetermined degree of = threat/risk mitigation. This degree is baked into policy or contract or = some other pre-existing agreement (think banking regulations, etc.) and = is locally determined based upon local considerations, e.g., no global = standard is appropriate.  So far as I can see, vectors of trust are = the same thing as the threats and threat vectors that are enumerated in = ISO 29115 and other places, not least of which are controls in NIST = 800-53-4 and in ISO 27001/2. I really don't see the vectors as anything = different from these and considering trustworthiness as the inverse of = threat in this context is pretty much what everybody seems to be = saying. 

 

If we just use 29115 as our baseline of = threats and threat vectors, there are roughly a dozen or so of them = associated with authentication of identity assertion. I don't think any = of us believe that a twelve-dimensional assertion is practically viable, = even if we could agree on a common metric for degree of threat = mitigation (fat chance that). This has also already been addressed by = the community: think of the factor model, one to four factors (the = fourth is context, which may be expressed as "Where or when you = are," according to our colleagues). What this does is boil down the = trust/threat algorithm to no more than four dimensions and shifts the = discussion to the aforementioned conundrum, e.g., how to evaluate and = rate the degree of threat mitigation. Various communities have developed = policies and practices to address this question, the most recent of = which, I think, is EU Regulation 910/2014 (eIDAS). 

 

IMO, the greatest opportunity open to us = is to find a way to normalize all the various community policies and = practices so that RPs can assess whether assertions issued under one = community's metrics align with their adopted risk mitigation = requirements. I think that has to be addressed in the context of how = effective a particular mitigation action is on a recognized threat = vector.   I would be most interested in your thoughts on that = problem.

 

regards,

 

Peter


------------------------------------------------------------

Peter Alterman, Ph.D.

Chief Operating Officer
SAFE-BioPharma = Association

cell: 301-943-7452

 

On Tue, Jan 13, 2015 at 8:19 AM, <vot-request@ietf.org> = wrote:

Send vot mailing list submissions to
      =   vot@ietf.org

To subscribe or unsubscribe = via the World Wide Web, visit
        https://www.ietf.org/mailman/listinfo/vot
or, = via email, send a message with subject or body 'help' to
  =       vot-request@ietf.org

You can reach the = person managing the list at
        vot-owner@ietf.org

When replying, please = edit your Subject line so it is more specific
than "Re: Contents = of vot digest..."

Today's Topics:

   1. Re: = capturing the threads of the discussion (Robin Wilton)
  =  2. VoT wiki (Steve Olshansky)


---------- Forwarded = message ----------
From: Robin Wilton <wilton@isoc.org>
To: Colin Wallis = <Colin.Wallis@dia.govt.nz>
Cc: Jim = Fenton <fenton@bluepopcorn.net>, "vot@ietf.org" = <vot@ietf.org>
Date: Tue, 13 Jan 2015 = 09:31:59 +0000
Subject: Re: [VoT] capturing the threads of the = discussion

Oops - I'd forgotten about the wiki: apologies! Yes, I think = that's the place to start...

 

R

Robin Wilton

 

Technical Outreach Director - Identity and = Privacy


On 12 Jan 2015, at 23:43, "Colin Wallis" <Colin.Wallis@dia.govt.nz> = wrote:

Well as Steve O pointed out in this attached email in November, the = wiki set up for this work might be a place to start..

There may be some jiggery pokery to get the folks on this list who = want to contribute (who were not attendees at Utrecht) access rights, = but it would seem to me to be the obvious starter option for a = repository.

Cheers

Colin

PS: BTW this is a good discussion and indeed an opportunistic time to = bring it together since so much of what Justin, Jim, Scott, Ken, Steve = W, Mark et al have commented recently is complementary (well at least = not completely contradictory or orthogonal) so let=E2=80=99s grab it! =

 

From:= = vot [mailto:vot-bounces@ietf.org] On Behalf Of Robin = Wilton
Sent: Tuesday, 13 January 2015 11:22 a.m.
To: = Jim Fenton
Cc: vot@ietf.org
Subject: Re: [VoT] = capturing the threads of the discussion

 

Thanks Jim,

 

I won't give a substantive response here; just to note that I = think it's worth considering a repository so that we can capture = 'static' versions of any straw-man docs, to complement what we it into = the mail thread...

 

Sorry to be brief at this stage - just tying up some loose = ends before an absence from the = office.

 

R

Robin Wilton

 

Technical Outreach Director - Identity and = Privacy


On 12 Jan 2015, at 21:45, "Jim Fenton" <fenton@bluepopcorn.net> = wrote:

Maybe I should be breaking these apart as Robin suggests, but = for now I'll keep this in one reply:

On 1/12/15 6:06 AM, Robin = Wilton wrote:

This thread raises several important topics=E2=80=A6 just as a = practical matter, it might be worth trying to spin some of them off = separately, so that we address them all, and minimise the risk of = talking at cross-purposes.  

It feels like it would be worth trying to put together some = *very short* straw-man docs/pages/paragraphs to try and get a consensus = version on specific points, so that we avoid re-hashing the same = arguments/discussions over time, or at least have something we can refer = to - and amend if necessary. I think this is aiming at the same = end-point as Steve=E2=80=99s request for a statement of requirements, = but will ensure we=E2=80=99re expressing our requirements in a = consistent set of terms.

 

By = the looks of it, these would make for a good starting point (I think the = answers to most of these are implicit in various people=E2=80=99s = contributions to the thread=E2=80=A6 but that doesn=E2=80=99t mean = everyone agrees ;^)  ):

 

1 - = what do we mean by authentication and authorisation? Are there other = decisions (e.g. access control, entitlement) which need to be called out = explicitly? This reflects the purpose of Justin=E2=80=99s questions. = Classically, the reason for authenticating a user is to answer a yes/no = question (is this the person to whom this credential was originally = issued); if yes, what do I want to do about it (at which point the = further entitlements are usually determined by retrieving a user = profile, ACL or whatever)?


Access control and entitlement as distinct from = authorisation? Is there a distinction, or are people just using = different terminology?

I think of authentication as providing = more than a yes/no answer: it provides an identifier. If the relying = party has enough information (perhaps on the basis of previous = interactions) to authorize something with just that, fine. Otherwise = some attributes are needed to make an authorisation = decision.

However, as = we know, these days access control and entitlement decisions also need = to be made on the basis of input other than classic credentials, and = that=E2=80=99s one of the two cores of this discussion, I = believe.


Example of an "input other than classic = credentials"?

 

2 - = what=E2=80=99s the classic lifecycle of a credential - i.e. a artefact = intended to provide evidence in support of an assertion of identity. = (e.g. registration/verification/enrolment, credential issue, credential = presentation/authentication, credential = amendment/revocation/destruction=E2=80=A6)?


Credential is another of those tricky words. Sometimes it = means the same as an authentication token. Sometimes it has some = attributes bound to it, which means it has both an authentication and = attribute provision flavor to it. I find it simpler to talk about = tokens, where one doesn't have to deal with revocation when some = attribute (employment, for example) = changes.

 

3 - = How does (2) relate to other assertions (e.g. attribute assertions) we = would like to make reliably?

 

With that starter set, I think we can confirm the subset of = requirements that 800-63-1 still meets, and define the delta that = requires new design.

 

4 - What=E2=80=99s the right way to update current thinking on = LOAs, to account for the change Jim describes in his proposal - i.e., = the case where "credentials (used in authentication) and attribute = information (established through identity proofing) could be provided by = different parties.=E2=80=9D

 

5 - From Jim=E2=80=99s proposal: =E2=80=9CAttribute reliability refers to the quality of the identity proofing = process, as well as the strength of the binding of the identifying = attributes to the authentication.=E2=80=9D Do we = need/want to expand on this a little? This seems to cater well for the = case where, say, vehicle entitlements are being established so that they = can be encapsulated in a driving licence. It=E2=80=99s not so clear how = this addresses, say, third party assertions that do not arise from an = identity proofing process - =E2=80=9CI have no idea *who* this user is, = but I can reliably assert the following about them: ... = =E2=80=9D.


You're right; that will need to be defined. But it should = be possible to define analogous requirements to describe the strength of = the binding to the token. When you show up to enroll at school, it = should be possible to use your token to allow your school to make LOR 3 = asserts that you're there student. But maybe remote students only get = LOR = 2?

-Jim

All-
There unfortunately is a long-standing bug in = Confluence. You must be logged in before that link, or any link to a = restricted page, will work.

The wiki space for workshop attendees = only, which you all have full edit access to and which is not publicly = viewable, is athttps://tid.isoc.org/confluence/display/interfedgen/
The *PUBLIC* wiki space, containing the agenda, presentations, and = contributions/references, is at
https://tid.isoc.org/confluence/display/interfed/
As we make progress on work items and are ready to move them to = the public wiki, I will be happy to do that. Our goal is of course to = make as much of our work as possible available to the public, but this = restricted wiki space gives us a place to work on things before = revealing them to the world.

As always, if anyone has questions = or problems related to the wiki, or anything else, please do let me = know.
       Steve

--
Ste= ve Olshansky
Trust & Identity Program Lead
Internet = Society
www.internetsociety.org

=

<signature.asc>

<= blockquote style=3D'margin-top:5.0pt;margin-bottom:5.0pt'>

_______________________________________________
Ideco-fab = mailing list
Ideco-fab@elists.isoc.org
https://elists.isoc.org/mailman/listinfo/ideco-fab<= o:p>



---------- Forwarded message = ----------
From: Steve Olshansky <olshansky@isoc.org>
To: "vot@ietf.org" = <vot@ietf.org>
Cc: 
Date: Tue, = 13 Jan 2015 13:19:22 +0000
Subject: [VoT] VoT = wiki
All-
This is a great discussion, and the stars seem to be = aligning now for the development of some documents or any other related = artifacts.

I setup a dedicated wiki space for use by this group. = It is open to the world for viewing, but we can easily make restricted = areas for the purpose of working on documents before publishing. Anyone = would would like edit access is welcome to contact me directly = (off-list).
https://tid.isoc.org/confluence/display/vot/VoT+Home
        Steve

--
Steve = Olshansky
Trust & Identity Program Lead
Internet Society
www.internetsociety.org

On Jan 13, 2015, at = 2:31 AM, Robin Wilton <wilton@isoc.org> wrote:

> Oops - I'd = forgotten about the wiki: apologies! Yes, I think that's the place to = start...
>
> R
>
> Robin Wilton
>
> = Technical Outreach Director - Identity and Privacy
>
> On 12 = Jan 2015, at 23:43, "Colin Wallis" <Colin.Wallis@dia.govt.nz> = wrote:
>
>> Well as Steve O pointed out in this attached = email in November, the wiki set up for this work might be a place to = start..
>> There may be some jiggery pokery to get the folks on = this list who want to contribute (who were not attendees at Utrecht) = access rights, but it would seem to me to be the obvious starter option = for a repository.
>> Cheers
>> Colin
>> PS: = BTW this is a good discussion and indeed an opportunistic time to bring = it together since so much of what Justin, Jim, Scott, Ken, Steve W, Mark = et al have commented recently is complementary (well at least not = completely contradictory or orthogonal) so let=E2=80=99s grab = it!
>>
>> From: vot [mailto:vot-bounces@ietf.org] On Behalf Of Robin = Wilton
>> Sent: Tuesday, 13 January 2015 11:22 a.m.
>> = To: Jim Fenton
>> Cc: vot@ietf.org
>> Subject: Re: [VoT] = capturing the threads of the discussion
>>
>> Thanks = Jim,
>>
>> I won't give a substantive response here; = just to note that I think it's worth considering a repository so that we = can capture 'static' versions of any straw-man docs, to complement what = we it into the mail thread...
>>
>> Sorry to be brief = at this stage - just tying up some loose ends before an absence from the = office.
>>
>> R
>>
>> Robin = Wilton
>>
>> Technical Outreach Director - Identity = and Privacy
>>
>> On 12 Jan 2015, at 21:45, "Jim = Fenton" <fenton@bluepopcorn.net> = wrote:
>>
>> Maybe I should be breaking these apart as = Robin suggests, but for now I'll keep this in one = reply:
>>
>> On 1/12/15 6:06 AM, Robin Wilton = wrote:
>> This thread raises several important topics=E2=80=A6 = just as a practical matter, it might be worth trying to spin some of = them off separately, so that we address them all, and minimise the risk = of talking at cross-purposes.
>> It feels like it would be = worth trying to put together some *very short* straw-man = docs/pages/paragraphs to try and get a consensus version on specific = points, so that we avoid re-hashing the same arguments/discussions over = time, or at least have something we can refer to - and amend if = necessary. I think this is aiming at the same end-point as = Steve=E2=80=99s request for a statement of requirements, but will ensure = we=E2=80=99re expressing our requirements in a consistent set of = terms.
>>
>>
>> By the looks of it, these = would make for a good starting point (I think the answers to most of = these are implicit in various people=E2=80=99s contributions to the = thread=E2=80=A6 but that doesn=E2=80=99t mean everyone agrees ;^)  = ):
>>
>>
>> 1 - what do we mean by = authentication and authorisation? Are there other decisions (e.g. access = control, entitlement) which need to be called out explicitly? This = reflects the purpose of Justin=E2=80=99s questions. Classically, the = reason for authenticating a user is to answer a yes/no question (is this = the person to whom this credential was originally issued); if yes, what = do I want to do about it (at which point the further entitlements are = usually determined by retrieving a user profile, ACL or = whatever)?
>>
>> Access control and entitlement as = distinct from authorisation? Is there a distinction, or are people just = using different terminology?
>>
>> I think of = authentication as providing more than a yes/no answer: it provides an = identifier. If the relying party has enough information (perhaps on the = basis of previous interactions) to authorize something with just that, = fine. Otherwise some attributes are needed to make an authorisation = decision.
>>
>>
>> However, as we know, these = days access control and entitlement decisions also need to be made on = the basis of input other than classic credentials, and that=E2=80=99s = one of the two cores of this discussion, I = believe.
>>
>> Example of an "input other than = classic = credentials"?
>>
>>
>>
>>
>= ;> 2 - what=E2=80=99s the classic lifecycle of a credential - i.e. a = artefact intended to provide evidence in support of an assertion of = identity. (e.g. registration/verification/enrolment, credential issue, = credential presentation/authentication, credential = amendment/revocation/destruction=E2=80=A6)?
>>
>>
&g= t;> Credential is another of those tricky words. Sometimes it means = the same as an authentication token. Sometimes it has some attributes = bound to it, which means it has both an authentication and attribute = provision flavor to it. I find it simpler to talk about tokens, where = one doesn't have to deal with revocation when some attribute = (employment, for example) = changes.
>>
>>
>>
>> 3 - How does = (2) relate to other assertions (e.g. attribute assertions) we would like = to make reliably?
>>
>>
>> With that starter = set, I think we can confirm the subset of requirements that 800-63-1 = still meets, and define the delta that requires new = design.
>>
>> 4 - What=E2=80=99s the right way to = update current thinking on LOAs, to account for the change Jim describes = in his proposal - i.e., the case where "credentials (used in = authentication) and attribute information (established through identity = proofing) could be provided by different = parties.=E2=80=9D
>>
>> 5 - From Jim=E2=80=99s = proposal: =E2=80=9CAttribute reliability refers to the quality of the = identity proofing process, as well as the strength of the binding of the = identifying attributes to the authentication.=E2=80=9D Do we need/want = to expand on this a little? This seems to cater well for the case where, = say, vehicle entitlements are being established so that they can be = encapsulated in a driving licence. It=E2=80=99s not so clear how this = addresses, say, third party assertions that do not arise from an = identity proofing process - =E2=80=9CI have no idea *who* this user is, = but I can reliably assert the following about them: ... = =E2=80=9D.
>>
>> You're right; that will need to be = defined. But it should be possible to define analogous requirements to = describe the strength of the binding to the token. When you show up to = enroll at school, it should be possible to use your token to allow your = school to make LOR 3 asserts that you're there student. But maybe remote = students only get LOR 2?
>>
>> = -Jim
>>
> vot mailing list
> vot@ietf.org
> = https://www.ietf.org/mailman/listinfo/vot

_______________________________________________
vot mailing = list
vot@ietf.org
https://www.ietf.org/mailman/listinfo/vot

 

 


______________________________________= _________
vot mailing list
vot@ietf.org
https://www.ietf.org/mailman/listinfo/vot



 

-- =

=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D

Scott Shorter, = Principal Security Engineer
Electrosoft =E2=80=93 Fueling Customer Success = Through Outstanding Value and Trust!
Woman-Owned, Minority-Owned Small = Business | ISO 9001 | CMMI Level 2 
1893 = Metro Center Drive; Ste 228; Reston, VA 20190
(703) 437-9451 = x21 (office);   (240) 994-7793 (cell)
sshorter@electrosoft-inc.com (Email); &nb= sp; http://www.electrosoft-inc.com (Web)
=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

------=_NextPart_001_00E5_01D03581.7A9A72E0-- ------=_NextPart_000_00E4_01D03581.7A9A72E0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITvjCCBDYw ggMeoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRy dXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZ QWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wMDA1MzAxMDQ4MzhaFw0yMDA1MzAxMDQ4Mzha MG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3Qg RXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3Qw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC39xoz5vIABC054E5b7R+8bA/Ntfojts7e mxEzl6QpTH2Tn71KvJPtAxrjj8/lbVBa1pcplFqAsEl62y6V/bjKvzc4LR4+kUGtcFbH8E8/6DKe dMrIkFTpxl8PeJ2aQDwOrGGqXhSPnoehalDc15pOrwWzpnGUnHGzUGAKxxOdOAeGAqjpqGkmGJCr TLBPI6s6T4TY386f4Wlvu9dC12tE5Met7m1BX3JacQg3s3llpFmglDf3AC8NwpJy2tA4ctsUqEXE XSp9t7TWxO6szRNEt8kr3UMAJfphuWlqWCMRt6czj1Z1WfXNKddGtworZbbTQm8Vsrh7++/pXVPV NFonAgMBAAGjgdwwgdkwHQYDVR0OBBYEFK29mHo0tCb3+sQmVO8DveAky1QaMAsGA1UdDwQEAwIB BjAPBgNVHRMBAf8EBTADAQH/MIGZBgNVHSMEgZEwgY6AFK29mHo0tCb3+sQmVO8DveAky1QaoXOk cTBvMQswCQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0 IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 ggEBMA0GCSqGSIb3DQEBBQUAA4IBAQCwm+CFJcLWI+IPlgaSnUGYnNmEeYHZHlsUByM2ZY+w2He7 rEFsR2CDUbD5Mj3n/PYmE8eAFqW/WvyHz3h5iSGa4kwHCoY1vPLeUcTSlrfcfk7ucP0cOesMAlEU LY69FuDB30Z15ySt7PRCtIWTcBBnup0GNUoY0yt6zFFCoXpj0ea7ocUrwja+Ew3mvWN+eXunCQ1A q2rdj4rD9vaMGkIFUdRF9Z+nYiFoFSBDPJnnfL0k2KmRF3OIP1YbMTgYtHEPms3IDp6OLhvhjJiD yx8x8URMxgRzSXZgD8f4vReAay7pzEwOWpp5DyAKLtWeYyYeVZKU2IIXWnvQvMePToYEMIIEnTCC A4WgAwIBAgIQND3pK6wnNP+PyzSU+8xwVDANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEU MBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3 b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTA1MDYwNzA4MDkxMFoX DTIwMDUzMDEwNDgzOFowga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2Fs dCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0 cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRo ZW50aWNhdGlvbiBhbmQgRW1haWwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCyOYWk 8n2rQTtiRjeuzcFgdbw5ZflKGkeiucxIzGqY1U01GbmkQuXOSeKKLx580jEHx060g2SdLinVomTE hb2FUTV5pE5okHsceqSSqBfymBXyk8zJpDKVuwxPML2YoAuL5W4bokb6eLyib6tZXqUvz8rabaov 66yhs2qqty5nNYt54R5piOLmRs2gpeq+C852OnoOm+r82idbPXMfIuZIYcZM82mxqC4bttQxICy8 goqOpA6l14lD/BZarx1x1xFZ2rqHDa/68+HC8KTFZ4zW1lQ63gqkugN3s2XI/R7TdGKqGMpokx6h hX71R2XL+E1XKHTSNP8wtu72YjAUjCzrAgMBAAGjgfQwgfEwHwYDVR0jBBgwFoAUrb2YejS0Jvf6 xCZU7wO94CTLVBowHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59MA4GA1UdDwEB/wQEAwIB BjAPBgNVHRMBAf8EBTADAQH/MBEGA1UdIAQKMAgwBgYEVR0gADBEBgNVHR8EPTA7MDmgN6A1hjNo dHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vQWRkVHJ1c3RFeHRlcm5hbENBUm9vdC5jcmwwNQYIKwYB BQUHAQEEKTAnMCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3 DQEBBQUAA4IBAQABvJzjYyiw8zEBwt973WKgAZ0jMQ+cknNTUeofTPrWn8TKL2d+eDMPdBa5kYeR 9Yom+mRwANge+QsEYlCHk4HU2vUj2zS7hVa0cDRueIM3HoUcxREVkl+HF72sav3xwtHMiV+xfPA+ UfI183zsYJhrOivg79+zfYbrtRv1W+yifJgT1wBQudEtc94DeHThBYUxXsuauZ2UxrmUN3Vy3ET7 Z+jw+iUeUqfaJelH4KDHPKBOsQo2+3dIn++Xivu0/uOUFKiDvFwtP9JgcWDuwnGCDOmINuPaILSj oGyqlku4gI51ykkH9jsUut/cBdmf2+Cy5k2geCbn5y1uf1/GHogVMIIFJTCCBA2gAwIBAgIQRIUc GfetDxT4xHWGNMR0xzANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVU MRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3Jr MSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmly c3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0xMDEyMDIwMDAwMDBaFw0yMDA1 MzAxMDQ4MzhaMIGWMQswCQYDVQQGEwJVUzFBMD8GA1UEChM4VGhlIFVuaXZlcnNpdHkgb2YgVGV4 YXMgSGVhbHRoIFNjaWVuY2UgQ2VudGVyIGF0IEhvdXN0b24xRDBCBgNVBAMTO1RoZSBVbml2ZXJz aXR5IG9mIFRleGFzIEhlYWx0aCBTY2llbmNlIENlbnRlciBhdCBIb3VzdG9uIENBMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxElj8A/NxSnbcaHKOvWlDt5+EbJMPZFayMmRcR5BbEqw M9PLQPTH1yJIZp+7Afgi6CZ/GrJcOEIRsfP43H3VK5O5FI6zIT6ZEEjj+huZ0hWey6Cg/ZNU22Mr XXCGEc0W4afqSXNX2mkck2oQW3xrDTaifCWBFQDki+k5d8wKQ2buk/aIFJO0qomzxq1cdJqAS/sF PWR3aRdJrn5IsjZeDsnsWZFpKCRiAybgcogM0f2mWDLATusRoL41DiOlJfH22NObHcFTQmsoAnXj X+FwJwdZ5H+kiiUCH9tXOHdPyKOoQoBqg+mdkCb4wviJsVTrq4lffBGe+xyeK2dlYngQSQIDAQAB o4IBUzCCAU8wHwYDVR0jBBgwFoAUiYJnfcSdJnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFJkX0AQh Sm6R8Ydeb3ZvO93EMh4gMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEAMBkGA1Ud IAQSMBAwDgYMKwYBBAGyMQECAiQFMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRy dXN0LmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQG CCsGAQUFBwEBBGgwZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFk ZFRydXN0Q2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNv bTANBgkqhkiG9w0BAQUFAAOCAQEAKqKCLV43+zEwBp/AHeelxnJikiO6zfHH7lNSvtwBPyGm4ZuI v6WHl669XQpMLcUxy8b0B8gHZ00AA+mZ7r2YP7HrUiuTEWssdA859PYHeIulfBfLhSP28On7C1Mx aODD9UQtj1j3NUGCy2kCGB2xupUjEXtNWSTgEGWhMiv5V+EvjLEns59Rpm5BHWgsycFOSyztjJYQ kRIFx3Yi6IX5b7s+lxMt96yVwaatlI+xMWPJpxeWlBzq/nIhPfREJmKf0RzZh58Gi6TnIPjmSsIV BZJhUxdTIJkfaJkajOy539WRMM9k04gBH4ZIFd2VwqwB9aZl27LgfvYOeeoswzPpRzCCBbYwggSe oAMCAQICEQC2CAUBCn9+NClEHZu5j+aOMA0GCSqGSIb3DQEBBQUAMIGWMQswCQYDVQQGEwJVUzFB MD8GA1UEChM4VGhlIFVuaXZlcnNpdHkgb2YgVGV4YXMgSGVhbHRoIFNjaWVuY2UgQ2VudGVyIGF0 IEhvdXN0b24xRDBCBgNVBAMTO1RoZSBVbml2ZXJzaXR5IG9mIFRleGFzIEhlYWx0aCBTY2llbmNl IENlbnRlciBhdCBIb3VzdG9uIENBMB4XDTE0MDkxNTAwMDAwMFoXDTE1MDkxNTIzNTk1OVowgbMx DjAMBgNVBBETBTc3MDMwMRwwGgYDVQQKExNVVEhFQUxUSCBOT04tRVNDUk9XMRQwEgYDVQQJEws3 MDAwIEZhbm5pbjEOMAwGA1UECBMFVGV4YXMxEDAOBgNVBAcTB0hvdXN0b24xCzAJBgNVBAYTAlVT MRUwEwYDVQQDEwxNYXJrIEIgSm9uZXMxJzAlBgkqhkiG9w0BCQEWGG1hcmsuYi5qb25lc0B1dGgu dG1jLmVkdTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAIsD9b8/H96eboYROkoZaA2/ QEXxNACieGhSr+CQzUfSlhWcL4M69uA938pqeKvzGWWJBEkb46tzTMhnbWuvbNfqUT+PBShIvkSr ndy7BE0ozkKjFVU/6jTsj2klnDyfq3wn0+GA/e+FTzYaDdj7ts6fij74De2GDPdNlVJa6uzzMaTd 7cS3T87ht0Yr03NStJRAl+IdN4cpJ9+Xn14NG7PnlZy5fyXDWM88kd/guUpdfK6XIjEud01vjDco NpN3ihRXl8LnEP700dosa2r897emtg8XJaSnw4k/GJUfSuGgW2rbYpUOyR9JPzZQMlLPqptNRjF5 WAzp2neDcl2fb0kCAwEAAaOCAd4wggHaMB8GA1UdIwQYMBaAFJkX0AQhSm6R8Ydeb3ZvO93EMh4g MB0GA1UdDgQWBBTk8/IYWxQfOajleb+QbNEs5R1HCzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/ BAIwADAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwQwYDVR0gBDwwOjA4BgwrBgEEAbIx AQICJAUwKDAmBggrBgEFBQcCARYaaHR0cDovL3d3dy51dGgudG1jLmVkdS9jcHMwXgYDVR0fBFcw VTBToFGgT4ZNaHR0cDovL2NybC51dGgudG1jLmVkdS9UaGVVbml2ZXJzaXR5b2ZUZXhhc0hlYWx0 aFNjaWVuY2VDZW50ZXJhdEhvdXN0b25DQS5jcmwwgZAGCCsGAQUFBwEBBIGDMIGAMFkGCCsGAQUF BzAChk1odHRwOi8vY3J0LnV0aC50bWMuZWR1L1RoZVVuaXZlcnNpdHlvZlRleGFzSGVhbHRoU2Np ZW5jZUNlbnRlcmF0SG91c3RvbkNBLmNydDAjBggrBgEFBQcwAYYXaHR0cDovL29jc3AudXRoLnRt Yy5lZHUwIwYDVR0RBBwwGoEYbWFyay5iLmpvbmVzQHV0aC50bWMuZWR1MA0GCSqGSIb3DQEBBQUA A4IBAQCB5ypKawPDBa1lkt5Kv3priYCzwt5kUJA9MaQArIbAnpH2OoPnaUcnaGFNhgbm7TMJmC4V spP7uBsrtUGzywRe7AXwrRLX5WKxT4KKDdIonoftE0zVJGCP8SelTnlCOYk1/aa7blWsLtEan/AG sgJwFo8IjrWI95DqimKhH7qOU5KIbPovEksE6NFE0EcHdBLDEWmH1iCaZvl2qNJyrERtVYxG7wTA UTlMG6Tr2tkm1f6NJizvUSCaxCVVpZ4QSHYb6edNYI25w/D2yoDeGCvyq9lyRA/h5QooHdxu+8tG JZpxA9fSKDewjKNIJoirGOhrLM9t8/NxXw40sd7vZdTZMYIEFDCCBBACAQEwgawwgZYxCzAJBgNV BAYTAlVTMUEwPwYDVQQKEzhUaGUgVW5pdmVyc2l0eSBvZiBUZXhhcyBIZWFsdGggU2NpZW5jZSBD ZW50ZXIgYXQgSG91c3RvbjFEMEIGA1UEAxM7VGhlIFVuaXZlcnNpdHkgb2YgVGV4YXMgSGVhbHRo IFNjaWVuY2UgQ2VudGVyIGF0IEhvdXN0b24gQ0ECEQC2CAUBCn9+NClEHZu5j+aOMAkGBSsOAwIa BQCgggI8MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDEyMTE5 NTIyMVowIwYJKoZIhvcNAQkEMRYEFIWFCXXHRUf/i6CGkHv1Zvllr1THMFsGCSqGSIb3DQEJDzFO MEwwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G CCqGSIb3DQMCAgEoMAcGBSsOAwIaMIG9BgkrBgEEAYI3EAQxga8wgawwgZYxCzAJBgNVBAYTAlVT MUEwPwYDVQQKEzhUaGUgVW5pdmVyc2l0eSBvZiBUZXhhcyBIZWFsdGggU2NpZW5jZSBDZW50ZXIg YXQgSG91c3RvbjFEMEIGA1UEAxM7VGhlIFVuaXZlcnNpdHkgb2YgVGV4YXMgSGVhbHRoIFNjaWVu Y2UgQ2VudGVyIGF0IEhvdXN0b24gQ0ECEQC2CAUBCn9+NClEHZu5j+aOMIG/BgsqhkiG9w0BCRAC CzGBr6CBrDCBljELMAkGA1UEBhMCVVMxQTA/BgNVBAoTOFRoZSBVbml2ZXJzaXR5IG9mIFRleGFz IEhlYWx0aCBTY2llbmNlIENlbnRlciBhdCBIb3VzdG9uMUQwQgYDVQQDEztUaGUgVW5pdmVyc2l0 eSBvZiBUZXhhcyBIZWFsdGggU2NpZW5jZSBDZW50ZXIgYXQgSG91c3RvbiBDQQIRALYIBQEKf340 KUQdm7mP5o4wDQYJKoZIhvcNAQEBBQAEggEANJpXyFInZwWFYnR87agnxpqOrWu7cjzEqWtnIesv FF73ZOI9KUd5Xr5ux+qdzj77EHI2aqxw5aUIKOOmVVdC2LbWgI/kPO2WAUZiLe2KS88xaHWkpHnX RLtYPayU/fCAxh9xCHyQoAF2XDSdDM8pssYgXMYz+OcEkHP8aJT8JgMNVv2o8ExM/MoavE+Ph3h0 pRTNMmAV0qS+lGu0xoNNUeuCkv+qPufDlgP1e2ZBJtpmb6FLh6aBFtXR1agwyNzA+puzUBYqWFw4 uX7fEFcl57NcYTL5buR3qFcoZv0GWE/T5ttwNlJLS/6ZCzpJBAu64q9cRzD+yNsqRcYMyX1dXAAA AAAAAA== ------=_NextPart_000_00E4_01D03581.7A9A72E0-- From nobody Wed Jan 21 13:05:18 2015 Return-Path: X-Original-To: vot@ietfa.amsl.com Delivered-To: vot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 089701A886C for ; Wed, 21 Jan 2015 13:05:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.511 X-Spam-Level: X-Spam-Status: No, score=-1.511 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 2q6yUnp4Ou8Q for ; Wed, 21 Jan 2015 13:05:15 -0800 (PST) Received: from mailgate-02.ucop.edu (imail-03.ucop.edu [128.48.123.91]) by ietfa.amsl.com (Postfix) with ESMTP id A6AF21A8877 for ; Wed, 21 Jan 2015 13:05:12 -0800 (PST) X-WSS-ID: 0NIJP8F-06-JTT-02 X-M-MSG: X-TMWD-Spam-Summary: TS=20150121210503; ID=1; SEV=2.4.5; DFV=B2014050338; IFV=NA; AIF=B2014050338; RPD=NA; ENG=NA; RPDID=NA; CAT=NONE; CON=NONE; SIG=AAAAAAAAAAAAAAAAgDB7CAAAfQ== Received: from p-irc-excas02.AD.UCOP.EDU (netscaler-01-vl-123.ucop.edu [128.48.123.8]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailgate-02.ucop.edu (Axway MailGate 5.3.0) with ESMTPS id 298BB406F83 for ; Wed, 21 Jan 2015 13:05:02 -0800 (PST) Received: from P-IRC-EXMBX03.AD.UCOP.EDU ([169.254.2.199]) by p-irc-excas02.AD.UCOP.EDU ([2002:8030:7ae8::8030:7ae8]) with mapi id 14.03.0210.002; Wed, 21 Jan 2015 13:05:06 -0800 From: Eric Goodman To: "vot@ietf.org" Thread-Topic: Trust Framework Comparisons Thread-Index: AdA1vXUNDVpJR/vWSgGpjsz0Pg5s1A== Date: Wed, 21 Jan 2015 21:05:05 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.48.122.8] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [VoT] Trust Framework Comparisons X-BeenThere: vot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Vectors of Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 21:05:17 -0000 PklzIHRoZXJlIGEgbm9ybWFsaXplZCBzZXQgb2YgYXNzZXJ0aW9uIHJlcXVpcmVtZW50cz8gSSBk b24ndCBrbm93LiANCj5UaGVyZSBhcmUgYSBmZXcgY29tbXVuaXRpZXMgdGhhdCBoYXZlIGRlc2Ny aWJlZCB0aGVpciByZXF1aXJlbWVudHMgDQo+YnV0LCBpbiBteSBvcGluaW9uLCBJIGFtIG5vdCBz dXJlIGhvdyBlYXN5IGl0IGlzIHRvIGNvbXBhcmUgYW5kIA0KPmNvbnRyYXN0IHRoZXNlwqBkZXNj cmlwdGlvbnMgSW4gYSBtYW5uZXIgdGhhdCBtaWdodCBnZW5lcmF0ZSBhIG5vcm1hbGl6ZWTCoA0K PnNldC4gVGhpcyBtaWdodCBiZSBhIGZhbnRhc3RpYyBNYXN0ZXJzIGRlZ3JlZSBhbmFseXNpcyB0 aGF0IHNvbWUgZW50ZXJwcmlzaW5nIA0KPnN0dWRlbnQgbWlnaHQgdW5kZXJ0YWtlLiBPciwgaWYg c29tZSBmZWRlcmF0aW9uIGNvdWxkIGZpbmQgdGhlIGZ1bmRpbmcsIA0KPnRoYXQgYSBjb25zdWx0 YW50IGNvdWxkIHVuZGVydGFrZS4NCg0KQXQgUkVGRURzIEkgaGVhcmQgbWVudGlvbiBvZiBhIGNv bXBhcmlzb24gZG9jdW1lbnQgc29tZW9uZSAoTmljb2xlIEhhcnJpcz8pIG1heSBoYXZlIHB1dCB0 b2dldGhlciBjb21wYXJpbmcg4oCcNiBkaWZmZXJlbnQgdHJ1c3QgZnJhbWV3b3Jrc+KAnS4gSeKA mXZlIGJlZW4gc3VjY2Vzc2Z1bCBhdCBmaW5kaW5nIGxpbmtzIHRoYXQgc2VlbSB0byBpbXBseSBz dWNoIGEgdGhpbmcgZXhpc3RzLCBidXQgaGF2ZW7igJl0IGJlZW4gYWJsZSB0byBmaW5kIHRoZSBh Y3R1YWwgZG9jdW1lbnQsIHNvIEnigJltIG5vdCBzdXJlIGlmIGl04oCZcyByZWxldmFudC4gSSdt IGludGVyZXN0ZWQgaW4gc2VlaW5nIGEgc2ltaWxhciBjb21wYXJpc29uLiBDYW4gc29tZW9uZSBp ZGVudGlmeSBmcm9tIG15IHZhZ3VlIGRlc2NyaXB0aW9uIHdoYXQgdGhlIGRvY3VtZW50IGlzIHRo YXQgd2FzIG1lbnRpb25lZCwgaWYgaXQncyByZWxldmFudCB0byB0aGlzIGRpc2N1c3Npb24sIGFu ZCBwZXJoYXBzIHdoZXJlIHRoYXQgZG9jdW1lbnQgY2FuIGJlIGZvdW5kPw0KDQpUaGFua3MsDQoN Ci0tLSBFcmljDQoNCg0KDQo= From nobody Wed Jan 21 18:48:32 2015 Return-Path: X-Original-To: vot@ietfa.amsl.com Delivered-To: vot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5987F1A907C for ; Wed, 21 Jan 2015 18:48:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MSGID_FROM_MTA_HEADER=0.001, 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 xgo2-SgxeUF5 for ; Wed, 21 Jan 2015 18:48:26 -0800 (PST) Received: from smtp.safecom.net.nz (smtp.safecom.net.nz [125.236.41.139]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B3AA1A0070 for ; Wed, 21 Jan 2015 18:48:25 -0800 (PST) Received: from s111-0006-lnv01 (Not Verified[127.0.0.1]) by smtp.safecom.net.nz (using TLS: SSLv23) id ; Thu, 22 Jan 2015 15:48:23 +1300 Message-ID: <147EE18440E5AF44834B220ED35BA530D3329B47@WLGPRDMBX01.dia.govt.nz> MIME-Version: 1.0 X-MessageIsInfected: false Received: from 161-65-142-21.ip.fx.net.nz (EHLO WLGPRDMM01.dia.govt.nz) ([127.0.0.1]) by s111-0006-lnv01 (JAMES SMTP Server ) with ESMTP ID 1696155404; Thu, 22 Jan 2015 15:48:23 +1300 (NZDT) Received: from WLGPRDCAS02.dia.govt.nz (Not Verified[127.0.0.1]) by WLGPRDMM01.dia.govt.nz with MailMarshal (v7, 1, 1, 5205) (using TLS: SSLv23) id ; Thu, 22 Jan 2015 15:48:18 +1300 Received: from WLGPRDMBX01.dia.govt.nz ([fe80::13e:8e96:252b:e0d1]) by WLGPRDCAS02.dia.govt.nz ([127.0.0.1]) with mapi id 14.03.0146.000; Thu, 22 Jan 2015 15:48:22 +1300 From: Colin Wallis To: 'Eric Goodman' , "vot@ietf.org" Thread-Topic: [VoT] Trust Framework Comparisons Thread-Index: AdA1vXUNDVpJR/vWSgGpjsz0Pg5s1AAMDDGw Date: Thu, 22 Jan 2015 02:48:17 +0000 References: In-Reply-To: Accept-Language: en-US, en-NZ Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.0.162] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-sdp.mm2006: true Archived-At: Subject: Re: [VoT] Trust Framework Comparisons X-BeenThere: vot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Vectors of Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2015 02:48:29 -0000 aHR0cHM6Ly9yZWZlZHMudGVyZW5hLm9yZy9pbmRleC5waHAvRmVkZXJhdGlvbnMNCg0KQ29taW5n IHRvIHlvdSBjb3VydGVzeSBvZiB0aGUgS2FudGFyYSBlR292IFdHLi4NCg0KQ2hlZXJzDQpDb2xp bg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogdm90IFttYWlsdG86dm90LWJv dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBFcmljIEdvb2RtYW4NClNlbnQ6IFRodXJzZGF5 LCAyMiBKYW51YXJ5IDIwMTUgMTA6MDUgYS5tLg0KVG86IHZvdEBpZXRmLm9yZw0KU3ViamVjdDog UmU6IFtWb1RdIFRydXN0IEZyYW1ld29yayBDb21wYXJpc29ucw0KDQo+SXMgdGhlcmUgYSBub3Jt YWxpemVkIHNldCBvZiBhc3NlcnRpb24gcmVxdWlyZW1lbnRzPyBJIGRvbid0IGtub3cuIA0KPlRo ZXJlIGFyZSBhIGZldyBjb21tdW5pdGllcyB0aGF0IGhhdmUgZGVzY3JpYmVkIHRoZWlyIHJlcXVp cmVtZW50cyBidXQsIA0KPmluIG15IG9waW5pb24sIEkgYW0gbm90IHN1cmUgaG93IGVhc3kgaXQg aXMgdG8gY29tcGFyZSBhbmQgY29udHJhc3QgDQo+dGhlc2XCoGRlc2NyaXB0aW9ucyBJbiBhIG1h bm5lciB0aGF0IG1pZ2h0IGdlbmVyYXRlIGEgbm9ybWFsaXplZCBzZXQuIA0KPlRoaXMgbWlnaHQg YmUgYSBmYW50YXN0aWMgTWFzdGVycyBkZWdyZWUgYW5hbHlzaXMgdGhhdCBzb21lIA0KPmVudGVy cHJpc2luZyBzdHVkZW50IG1pZ2h0IHVuZGVydGFrZS4gT3IsIGlmIHNvbWUgZmVkZXJhdGlvbiBj b3VsZCBmaW5kIA0KPnRoZSBmdW5kaW5nLCB0aGF0IGEgY29uc3VsdGFudCBjb3VsZCB1bmRlcnRh a2UuDQoNCkF0IFJFRkVEcyBJIGhlYXJkIG1lbnRpb24gb2YgYSBjb21wYXJpc29uIGRvY3VtZW50 IHNvbWVvbmUgKE5pY29sZSBIYXJyaXM/KSBtYXkgaGF2ZSBwdXQgdG9nZXRoZXIgY29tcGFyaW5n IOKAnDYgZGlmZmVyZW50IHRydXN0IGZyYW1ld29ya3PigJ0uIEnigJl2ZSBiZWVuIHN1Y2Nlc3Nm dWwgYXQgZmluZGluZyBsaW5rcyB0aGF0IHNlZW0gdG8gaW1wbHkgc3VjaCBhIHRoaW5nIGV4aXN0 cywgYnV0IGhhdmVu4oCZdCBiZWVuIGFibGUgdG8gZmluZCB0aGUgYWN0dWFsIGRvY3VtZW50LCBz byBJ4oCZbSBub3Qgc3VyZSBpZiBpdOKAmXMgcmVsZXZhbnQuIEknbSBpbnRlcmVzdGVkIGluIHNl ZWluZyBhIHNpbWlsYXIgY29tcGFyaXNvbi4gQ2FuIHNvbWVvbmUgaWRlbnRpZnkgZnJvbSBteSB2 YWd1ZSBkZXNjcmlwdGlvbiB3aGF0IHRoZSBkb2N1bWVudCBpcyB0aGF0IHdhcyBtZW50aW9uZWQs IGlmIGl0J3MgcmVsZXZhbnQgdG8gdGhpcyBkaXNjdXNzaW9uLCBhbmQgcGVyaGFwcyB3aGVyZSB0 aGF0IGRvY3VtZW50IGNhbiBiZSBmb3VuZD8NCg0KVGhhbmtzLA0KDQotLS0gRXJpYw0KDQoNCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnZvdCBtYWls aW5nIGxpc3QNCnZvdEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby92b3QNCg== From nobody Thu Jan 22 00:21:09 2015 Return-Path: X-Original-To: vot@ietfa.amsl.com Delivered-To: vot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B0B31A8A1E for ; Thu, 22 Jan 2015 00:21:05 -0800 (PST) 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 Ofips28CvdKX for ; Thu, 22 Jan 2015 00:21:02 -0800 (PST) Received: from mail-wg0-f53.google.com (mail-wg0-f53.google.com [74.125.82.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 9B8F01A1B81 for ; Thu, 22 Jan 2015 00:21:02 -0800 (PST) Received: by mail-wg0-f53.google.com with SMTP id a1so238877wgh.12 for ; Thu, 22 Jan 2015 00:21:01 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=VXHwg3sAbUQjcIMPdRJuvji6WSRhM7iBPNDz7uxyRzQ=; b=J2k3mijNNw2sVREmB4eE1/30pE4+iSgSLfm0wPorBncX9/y6houRjvCkoYr4LfwRD5 RoaVarsuJ4vq0TZYrGIltlAd+ZITb5h7+Lma1iKnDpPufhYi5wRXOO8EHXp6jONNRWGF LYJnDwBK0hKlBCl/A+ctA3wY3Bqhur+iRwA9ookAwoO6dO0yA0yUbdzmV4EsSXpIXYLi 5kywbSQeNZ3DN2eD4leth9sUnGT4kV+7ljD5BzhSz5D13uMgP+Bc4xigaxLPA0GJ+q9E C5oMQCWKvUP0/W9M9JVxpDD4ypiTCisvR1p4wMl5ysiw4pfDkUhj9UqgNq/uJfFE/sMC FpEw== X-Gm-Message-State: ALoCoQmyS44Tu2a8T0SxTKzEn1qJhIXsPSiv5L5rdM4tgfMlq+jZ4ZetOOfDEtsGWHWZPeEgS59R X-Received: by 10.194.109.9 with SMTP id ho9mr286584wjb.29.1421914860873; Thu, 22 Jan 2015 00:21:00 -0800 (PST) Received: from MacbookAir-harris.local ([188.65.164.2]) by mx.google.com with ESMTPSA id u9sm2899680wjy.37.2015.01.22.00.20.59 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 22 Jan 2015 00:20:59 -0800 (PST) Message-ID: <54C0B2E9.2070608@terena.org> Date: Thu, 22 Jan 2015 09:20:57 +0100 From: Nicole Harris User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: vot@ietf.org References: <147EE18440E5AF44834B220ED35BA530D3329B47@WLGPRDMBX01.dia.govt.nz> In-Reply-To: <147EE18440E5AF44834B220ED35BA530D3329B47@WLGPRDMBX01.dia.govt.nz> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [VoT] Trust Framework Comparisons X-BeenThere: vot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Vectors of Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2015 08:21:05 -0000 Hi Eric I think that might have got a bit lost in translation. I carried out a comparison of all the policies used by the different R&E Federations.=20 That work is available over on the wiki: https://wiki.refeds.org/display/FBP/Federation+Policy+Best+Practice. It is more an exercise in trying to bring the R&E space to a standard baseline. We also took several of the more mature and compared them to the Kantara Assurance Framework and the OIX-FICAM framework. That info is on the wiki under the assurance tab....it is all very R&E specific.=20 In terms of assurance, REFEDS is doing 2 things at the moment. Firstly trying to make it easier to identify what "baseline R&E federation assurance" looks like to other people as we have been absolutely rubbish at documenting well enough in the insular world of R&E.=20 Secondly, we have pretty much thrown out all discussions on frameworks, authentication strength, profiles etc and instead we are asking the communities that we are working with what risks they are trying to mitigate and what the business impact is...so we are working with people like the SIRTFI folk on a profile looking at security incident response: https://wiki.refeds.org/display/GROUPS/SIRTFI. This goes a bit beyond the notion of having "confidence in the asserted identity"....but is more about confidence in a system as a whole and a belief that this can be done to a high level of assurance for that given community, but doesn't necessarily mean that an organisation has one time passwords, has verified the signature on a governmentID etc. So what we will probably end up with is a limited set of assurance profiles (not levels) that work for large cases in our community, and we of course then need to ensure that these can be well understood / mapped outside that space where necessary and that for me is where VoT comes in. That's a horribly simplistic way of describing things I know....I'm often guilty of over-simplifying :-) Overall, we may have some reasonably well developed case-studies on what risks our communities are trying to mitigate and what they need to be assured of to let users in that I hope might be interesting to this group in the long-term.=20 Cheers Nicole On 22/01/2015 03:48, Colin Wallis wrote: > https://refeds.terena.org/index.php/Federations > > Coming to you courtesy of the Kantara eGov WG.. > > Cheers > Colin > > -----Original Message----- > From: vot [mailto:vot-bounces@ietf.org] On Behalf Of Eric Goodman > Sent: Thursday, 22 January 2015 10:05 a.m. > To: vot@ietf.org > Subject: Re: [VoT] Trust Framework Comparisons > >> Is there a normalized set of assertion requirements? I don't know.=20 >> There are a few communities that have described their requirements but= ,=20 >> in my opinion, I am not sure how easy it is to compare and contrast=20 >> these descriptions In a manner that might generate a normalized set.=20 >> This might be a fantastic Masters degree analysis that some=20 >> enterprising student might undertake. Or, if some federation could fin= d=20 >> the funding, that a consultant could undertake. > At REFEDs I heard mention of a comparison document someone (Nicole Harr= is?) may have put together comparing =E2=80=9C6 different trust framework= s=E2=80=9D. I=E2=80=99ve been successful at finding links that seem to im= ply such a thing exists, but haven=E2=80=99t been able to find the actual= document, so I=E2=80=99m not sure if it=E2=80=99s relevant. I'm interest= ed in seeing a similar comparison. Can someone identify from my vague des= cription what the document is that was mentioned, if it's relevant to thi= s discussion, and perhaps where that document can be found? > > Thanks, > > --- Eric > > > > _______________________________________________ > vot mailing list > vot@ietf.org > https://www.ietf.org/mailman/listinfo/vot > _______________________________________________ > vot mailing list > vot@ietf.org > https://www.ietf.org/mailman/listinfo/vot --=20 Nicole Harris Project Development Officer G=C3=89ANT Association Amsterdam Office (formerly TERENA) Singel 468 D, 1017 AW Amsterdam The Netherlands Skype: harrisnv M:+31 64 610 53 95 From nobody Thu Jan 22 09:30:38 2015 Return-Path: X-Original-To: vot@ietfa.amsl.com Delivered-To: vot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 767921ACD77 for ; Thu, 22 Jan 2015 09:30:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 YKQJ6nZxv5TV for ; Thu, 22 Jan 2015 09:30:33 -0800 (PST) Received: from mail-yk0-x230.google.com (mail-yk0-x230.google.com [IPv6:2607:f8b0:4002:c07::230]) (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 5DC101A1B16 for ; Thu, 22 Jan 2015 09:30:31 -0800 (PST) Received: by mail-yk0-f176.google.com with SMTP id 20so1238186yks.7 for ; Thu, 22 Jan 2015 09:30:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zBzXW3wIzxLTRhs05C747yc9iXaOvwERyN54R4vqMKo=; b=YlLh5b2WfAuL7VtAUmVMsSYUAGI7D7bVGLzjU+ZaCPclgReidjO2Ksx821ZLmadgyi +g2bmcT2JXXWLYSbM1tW/d2YyKagHuPKHBxlwuIGaC4ChYe9Bv0ZptVhiIquG5yNsIMp hUwXrisjlSaOHmHAw07P2abB6SKkAsQenumMxyzpWttsoLlSZczWLnoOblmO7L5/zzj6 D+AkG0bPN4QZTJE04W+7B9hQ1CfhvQ5J874S5x7P8VVPpJpkQlzdY8/d9EHRPw7pSOip 3zX2aBFswvz+0rq/LjLHVwNyLFDktQ7HlJZTcFCxE5HnqWJIOzM/zsTHppa2d8mvyR1o HPVw== MIME-Version: 1.0 X-Received: by 10.236.111.7 with SMTP id v7mr1492260yhg.24.1421947830558; Thu, 22 Jan 2015 09:30:30 -0800 (PST) Received: by 10.170.53.15 with HTTP; Thu, 22 Jan 2015 09:30:30 -0800 (PST) In-Reply-To: <54C0B2E9.2070608@terena.org> References: <147EE18440E5AF44834B220ED35BA530D3329B47@WLGPRDMBX01.dia.govt.nz> <54C0B2E9.2070608@terena.org> Date: Thu, 22 Jan 2015 12:30:30 -0500 Message-ID: From: Ken Dagg To: Nicole Harris Content-Type: multipart/alternative; boundary=001a1132f2f05467ca050d410778 Archived-At: Cc: "vot@ietf.org" Subject: Re: [VoT] Trust Framework Comparisons X-BeenThere: vot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Vectors of Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2015 17:30:36 -0000 --001a1132f2f05467ca050d410778 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Nicole, I am not sure of this work that was done by the Government of Canada to standardize how this community defined the risks associated with identity assurance. It might prove useful to your communities. http://www.tbs-sct.gc.ca/pol/doc-eng.aspx?id=3D26776 Ken On Thursday, January 22, 2015, Nicole Harris wrote: > Hi Eric > > I think that might have got a bit lost in translation. I carried out a > comparison of all the policies used by the different R&E Federations. > That work is available over on the wiki: > https://wiki.refeds.org/display/FBP/Federation+Policy+Best+Practice. It > is more an exercise in trying to bring the R&E space to a standard > baseline. We also took several of the more mature and compared them to > the Kantara Assurance Framework and the OIX-FICAM framework. That info > is on the wiki under the assurance tab....it is all very R&E specific. > > In terms of assurance, REFEDS is doing 2 things at the moment. Firstly > trying to make it easier to identify what "baseline R&E federation > assurance" looks like to other people as we have been absolutely rubbish > at documenting well enough in the insular world of R&E. > > Secondly, we have pretty much thrown out all discussions on frameworks, > authentication strength, profiles etc and instead we are asking the > communities that we are working with what risks they are trying to > mitigate and what the business impact is...so we are working with people > like the SIRTFI folk on a profile looking at security incident response: > https://wiki.refeds.org/display/GROUPS/SIRTFI. This goes a bit beyond > the notion of having "confidence in the asserted identity"....but is > more about confidence in a system as a whole and a belief that this can > be done to a high level of assurance for that given community, but > doesn't necessarily mean that an organisation has one time passwords, > has verified the signature on a governmentID etc. > > So what we will probably end up with is a limited set of assurance > profiles (not levels) that work for large cases in our community, and we > of course then need to ensure that these can be well understood / mapped > outside that space where necessary and that for me is where VoT comes > in. That's a horribly simplistic way of describing things I know....I'm > often guilty of over-simplifying :-) > > Overall, we may have some reasonably well developed case-studies on what > risks our communities are trying to mitigate and what they need to be > assured of to let users in that I hope might be interesting to this > group in the long-term. > > Cheers > > Nicole > > On 22/01/2015 03:48, Colin Wallis wrote: > > https://refeds.terena.org/index.php/Federations > > > > Coming to you courtesy of the Kantara eGov WG.. > > > > Cheers > > Colin > > > > -----Original Message----- > > From: vot [mailto:vot-bounces@ietf.org ] On Behalf Of > Eric Goodman > > Sent: Thursday, 22 January 2015 10:05 a.m. > > To: vot@ietf.org > > Subject: Re: [VoT] Trust Framework Comparisons > > > >> Is there a normalized set of assertion requirements? I don't know. > >> There are a few communities that have described their requirements but= , > >> in my opinion, I am not sure how easy it is to compare and contrast > >> these descriptions In a manner that might generate a normalized set. > >> This might be a fantastic Masters degree analysis that some > >> enterprising student might undertake. Or, if some federation could fin= d > >> the funding, that a consultant could undertake. > > At REFEDs I heard mention of a comparison document someone (Nicole > Harris?) may have put together comparing =E2=80=9C6 different trust frame= works=E2=80=9D. > I=E2=80=99ve been successful at finding links that seem to imply such a t= hing > exists, but haven=E2=80=99t been able to find the actual document, so I= =E2=80=99m not sure > if it=E2=80=99s relevant. I'm interested in seeing a similar comparison. = Can > someone identify from my vague description what the document is that was > mentioned, if it's relevant to this discussion, and perhaps where that > document can be found? > > > > Thanks, > > > > --- Eric > > > > > > > > _______________________________________________ > > vot mailing list > > vot@ietf.org > > https://www.ietf.org/mailman/listinfo/vot > > _______________________________________________ > > vot mailing list > > vot@ietf.org > > https://www.ietf.org/mailman/listinfo/vot > > > -- > Nicole Harris > Project Development Officer > G=C3=89ANT Association Amsterdam Office (formerly TERENA) > Singel 468 D, 1017 AW Amsterdam > The Netherlands > Skype: harrisnv > M:+31 64 610 53 95 > > > _______________________________________________ > vot mailing list > vot@ietf.org > https://www.ietf.org/mailman/listinfo/vot > --001a1132f2f05467ca050d410778 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Nicole,

I am not sure of this work that was done by the = Government of Canada to standardize how this community defined=C2=A0the ris= ks associated with identity assurance. It might prove useful to your commun= ities.


Ken

On Thursday, January 22, 2015, Nico= le Harris <harris@terena.org>= ; wrote:
Hi Eric

I think that might have got a bit lost in translation.=C2=A0 I carried out = a
comparison of all the policies used by the different R&E Federations. That work is available over on the wiki:
https://wiki.refeds.org/display/FBP/Federation+Polic= y+Best+Practice.=C2=A0 It
is more an exercise in trying to bring the R&E space to a standard
baseline.=C2=A0 We also took several of the more mature and compared them t= o
the Kantara Assurance Framework and the OIX-FICAM framework.=C2=A0 That inf= o
is on the wiki under the assurance tab....it is all very R&E specific.<= br>
In terms of assurance, REFEDS is doing 2 things at the moment.=C2=A0 Firstl= y
trying to make it easier to identify what "baseline R&E federation=
assurance" looks like to other people as we have been absolutely rubbi= sh
at documenting well enough in the insular world of R&E.

Secondly, we have pretty much thrown out all discussions on frameworks,
authentication strength, profiles etc and instead we are asking the
communities that we are working with what risks they are trying to
mitigate and what the business impact is...so we are working with people like the SIRTFI folk on a profile looking at security incident response: https://wiki.refeds.org/display/GROUPS/SIRTFI.=C2=A0 This goes a bit b= eyond
the notion of having "confidence in the asserted identity"....but= is
more about confidence in a system as a whole and a belief that this can
be done to a high level of assurance for that given community, but
doesn't necessarily mean that an organisation has one time passwords, has verified the signature on a governmentID etc.

So what we will probably end up with is a limited set of assurance
profiles (not levels) that work for large cases in our community, and we of course then need to ensure that these can be well understood / mapped outside that space where necessary and that for me is where VoT comes
in.=C2=A0 That's a horribly simplistic way of describing things I know.= ...I'm
often guilty of over-simplifying :-)

Overall, we may have some reasonably well developed case-studies on what risks our communities are trying to mitigate and what they need to be
assured of to let users in that I hope might be interesting to this
group in the long-term.

Cheers

Nicole

On 22/01/2015 03:48, Colin Wallis wrote:
> https://refeds.terena.org/index.php/Federations
>
> Coming to you courtesy of the Kantara eGov WG..
>
> Cheers
> Colin
>
> -----Original Message-----
> From: vot [mailto:vot-bounces@ietf.org] On Beh= alf Of Eric Goodman
> Sent: Thursday, 22 January 2015 10:05 a.m.
> To: vot@ietf.org
> Subject: Re: [VoT] Trust Framework Comparisons
>
>> Is there a normalized set of assertion requirements? I don't k= now.
>> There are a few communities that have described their requirements= but,
>> in my opinion, I am not sure how easy it is to compare and contras= t
>> these descriptions In a manner that might generate a normalized se= t.
>> This might be a fantastic Masters degree analysis that some
>> enterprising student might undertake. Or, if some federation could= find
>> the funding, that a consultant could undertake.
> At REFEDs I heard mention of a comparison document someone (Nicole Har= ris?) may have put together comparing =E2=80=9C6 different trust frameworks= =E2=80=9D. I=E2=80=99ve been successful at finding links that seem to imply= such a thing exists, but haven=E2=80=99t been able to find the actual docu= ment, so I=E2=80=99m not sure if it=E2=80=99s relevant. I'm interested = in seeing a similar comparison. Can someone identify from my vague descript= ion what the document is that was mentioned, if it's relevant to this d= iscussion, and perhaps where that document can be found?
>
> Thanks,
>
> --- Eric
>
>
>
> _______________________________________________
> vot mailing list
> vot@ietf.org
> https://www.ietf.org/mailman/listinfo/vot
> _______________________________________________
> vot mailing list
> vot@ietf.org
> https://www.ietf.org/mailman/listinfo/vot


--
Nicole Harris
Project Development Officer
G=C3=89ANT Association Amsterdam Office (formerly TERENA)
Singel 468 D, 1017 AW Amsterdam
The Netherlands
Skype: harrisnv
M:+31 64 610 53 95


_______________________________________________
vot mailing list
vot@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/vot
--001a1132f2f05467ca050d410778-- From nobody Thu Jan 22 09:44:26 2015 Return-Path: X-Original-To: vot@ietfa.amsl.com Delivered-To: vot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAD251ACE14 for ; Thu, 22 Jan 2015 09:44:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 c1TjpkXBTaMU for ; Thu, 22 Jan 2015 09:44:20 -0800 (PST) Received: from mail-oi0-f52.google.com (mail-oi0-f52.google.com [209.85.218.52]) (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 9143C1ACE1D for ; Thu, 22 Jan 2015 09:44:12 -0800 (PST) Received: by mail-oi0-f52.google.com with SMTP id h136so589248oig.11 for ; Thu, 22 Jan 2015 09:44:12 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=cEcwxiUt86d9lG3VPc694wytORepbRRAw4Sj1X7s2Sg=; b=J3nahxnNf3ixYU3on6UZa0fxctx4wwgpT6uOOJjBFyoaRSqC7oBPngqcsegNYu+dex UZTQf/kRfFtxb+++FF1jin5qa85qWRZX6D72pagSWgtwrI/anh5AQvpBDGMwsiuELqEY t4pAafWVT7IwQs90P/QkJ63WN89mUVXXH9JuV763dBtmlktSRPnYluDjTN7febpq5ob0 6pel23sW2URsQkBFuTtpAvA/y7f/u+4kd9SM8TyhQKoHLLQB1JwHcLoC64cf+hYKkWKS LmCiPnNzjG+3VoeVemmcJpiIW94QDwYjDzthqaZJlpvQSYEo4fZ6Xi5pQ18K2BrFStG2 boSA== X-Gm-Message-State: ALoCoQl3w1tSlXmLqOIBKMBeaoiePOL4SZzECT4/EAOKXfcf0qgJf3b+5Tuyb0uiyI/88C9BlZ5E MIME-Version: 1.0 X-Received: by 10.182.211.70 with SMTP id na6mr1711099obc.13.1421948651968; Thu, 22 Jan 2015 09:44:11 -0800 (PST) Received: by 10.202.66.87 with HTTP; Thu, 22 Jan 2015 09:44:11 -0800 (PST) Received: by 10.202.66.87 with HTTP; Thu, 22 Jan 2015 09:44:11 -0800 (PST) In-Reply-To: References: Date: Thu, 22 Jan 2015 12:44:11 -0500 Message-ID: From: Peter Alterman To: vot@ietf.org Content-Type: multipart/alternative; boundary=e89a8f838df74a365e050d4138ee Archived-At: Subject: Re: [VoT] vot Digest, Vol 5, Issue 22 X-BeenThere: vot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Vectors of Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2015 17:44:25 -0000 --e89a8f838df74a365e050d4138ee Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Very useful. Thanks. On Jan 22, 2015 12:30 PM, wrote: > Send vot mailing list submissions to > vot@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/vot > or, via email, send a message with subject or body 'help' to > vot-request@ietf.org > > You can reach the person managing the list at > vot-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of vot digest..." > > Today's Topics: > > 1. Re: Trust Framework Comparisons (Eric Goodman) > 2. Re: Trust Framework Comparisons (Colin Wallis) > 3. Re: Trust Framework Comparisons (Nicole Harris) > 4. Re: Trust Framework Comparisons (Ken Dagg) > > > ---------- Forwarded message ---------- > From: Eric Goodman > To: "vot@ietf.org" > Cc: > Date: Wed, 21 Jan 2015 21:05:05 +0000 > Subject: Re: [VoT] Trust Framework Comparisons > >Is there a normalized set of assertion requirements? I don't know. > >There are a few communities that have described their requirements > >but, in my opinion, I am not sure how easy it is to compare and > >contrast these descriptions In a manner that might generate a normalized > >set. This might be a fantastic Masters degree analysis that some > enterprising > >student might undertake. Or, if some federation could find the funding, > >that a consultant could undertake. > > At REFEDs I heard mention of a comparison document someone (Nicole > Harris?) may have put together comparing =E2=80=9C6 different trust frame= works=E2=80=9D. > I=E2=80=99ve been successful at finding links that seem to imply such a t= hing > exists, but haven=E2=80=99t been able to find the actual document, so I= =E2=80=99m not sure > if it=E2=80=99s relevant. I'm interested in seeing a similar comparison. = Can > someone identify from my vague description what the document is that was > mentioned, if it's relevant to this discussion, and perhaps where that > document can be found? > > Thanks, > > --- Eric > > > > > > ---------- Forwarded message ---------- > From: Colin Wallis > To: "'Eric Goodman'" , "vot@ietf.org" > > Cc: > Date: Thu, 22 Jan 2015 02:48:17 +0000 > Subject: Re: [VoT] Trust Framework Comparisons > https://refeds.terena.org/index.php/Federations > > Coming to you courtesy of the Kantara eGov WG.. > > Cheers > Colin > > -----Original Message----- > From: vot [mailto:vot-bounces@ietf.org] On Behalf Of Eric Goodman > Sent: Thursday, 22 January 2015 10:05 a.m. > To: vot@ietf.org > Subject: Re: [VoT] Trust Framework Comparisons > > >Is there a normalized set of assertion requirements? I don't know. > >There are a few communities that have described their requirements but, > >in my opinion, I am not sure how easy it is to compare and contrast > >these descriptions In a manner that might generate a normalized set. > >This might be a fantastic Masters degree analysis that some > >enterprising student might undertake. Or, if some federation could find > >the funding, that a consultant could undertake. > > At REFEDs I heard mention of a comparison document someone (Nicole > Harris?) may have put together comparing =E2=80=9C6 different trust frame= works=E2=80=9D. > I=E2=80=99ve been successful at finding links that seem to imply such a t= hing > exists, but haven=E2=80=99t been able to find the actual document, so I= =E2=80=99m not sure > if it=E2=80=99s relevant. I'm interested in seeing a similar comparison. = Can > someone identify from my vague description what the document is that was > mentioned, if it's relevant to this discussion, and perhaps where that > document can be found? > > Thanks, > > --- Eric > > > > _______________________________________________ > vot mailing list > vot@ietf.org > https://www.ietf.org/mailman/listinfo/vot > > > ---------- Forwarded message ---------- > From: Nicole Harris > To: vot@ietf.org > Cc: > Date: Thu, 22 Jan 2015 09:20:57 +0100 > Subject: Re: [VoT] Trust Framework Comparisons > Hi Eric > > I think that might have got a bit lost in translation. I carried out a > comparison of all the policies used by the different R&E Federations. > That work is available over on the wiki: > https://wiki.refeds.org/display/FBP/Federation+Policy+Best+Practice. It > is more an exercise in trying to bring the R&E space to a standard > baseline. We also took several of the more mature and compared them to > the Kantara Assurance Framework and the OIX-FICAM framework. That info > is on the wiki under the assurance tab....it is all very R&E specific. > > In terms of assurance, REFEDS is doing 2 things at the moment. Firstly > trying to make it easier to identify what "baseline R&E federation > assurance" looks like to other people as we have been absolutely rubbish > at documenting well enough in the insular world of R&E. > > Secondly, we have pretty much thrown out all discussions on frameworks, > authentication strength, profiles etc and instead we are asking the > communities that we are working with what risks they are trying to > mitigate and what the business impact is...so we are working with people > like the SIRTFI folk on a profile looking at security incident response: > https://wiki.refeds.org/display/GROUPS/SIRTFI. This goes a bit beyond > the notion of having "confidence in the asserted identity"....but is > more about confidence in a system as a whole and a belief that this can > be done to a high level of assurance for that given community, but > doesn't necessarily mean that an organisation has one time passwords, > has verified the signature on a governmentID etc. > > So what we will probably end up with is a limited set of assurance > profiles (not levels) that work for large cases in our community, and we > of course then need to ensure that these can be well understood / mapped > outside that space where necessary and that for me is where VoT comes > in. That's a horribly simplistic way of describing things I know....I'm > often guilty of over-simplifying :-) > > Overall, we may have some reasonably well developed case-studies on what > risks our communities are trying to mitigate and what they need to be > assured of to let users in that I hope might be interesting to this > group in the long-term. > > Cheers > > Nicole > > On 22/01/2015 03:48, Colin Wallis wrote: > > https://refeds.terena.org/index.php/Federations > > > > Coming to you courtesy of the Kantara eGov WG.. > > > > Cheers > > Colin > > > > -----Original Message----- > > From: vot [mailto:vot-bounces@ietf.org] On Behalf Of Eric Goodman > > Sent: Thursday, 22 January 2015 10:05 a.m. > > To: vot@ietf.org > > Subject: Re: [VoT] Trust Framework Comparisons > > > >> Is there a normalized set of assertion requirements? I don't know. > >> There are a few communities that have described their requirements but= , > >> in my opinion, I am not sure how easy it is to compare and contrast > >> these descriptions In a manner that might generate a normalized set. > >> This might be a fantastic Masters degree analysis that some > >> enterprising student might undertake. Or, if some federation could fin= d > >> the funding, that a consultant could undertake. > > At REFEDs I heard mention of a comparison document someone (Nicole > Harris?) may have put together comparing =E2=80=9C6 different trust frame= works=E2=80=9D. > I=E2=80=99ve been successful at finding links that seem to imply such a t= hing > exists, but haven=E2=80=99t been able to find the actual document, so I= =E2=80=99m not sure > if it=E2=80=99s relevant. I'm interested in seeing a similar comparison. = Can > someone identify from my vague description what the document is that was > mentioned, if it's relevant to this discussion, and perhaps where that > document can be found? > > > > Thanks, > > > > --- Eric > > > > > > > > _______________________________________________ > > vot mailing list > > vot@ietf.org > > https://www.ietf.org/mailman/listinfo/vot > > _______________________________________________ > > vot mailing list > > vot@ietf.org > > https://www.ietf.org/mailman/listinfo/vot > > > -- > Nicole Harris > Project Development Officer > G=C3=89ANT Association Amsterdam Office (formerly TERENA) > Singel 468 D, 1017 AW Amsterdam > The Netherlands > Skype: harrisnv > M:+31 64 610 53 95 > > > > > > ---------- Forwarded message ---------- > From: Ken Dagg > To: Nicole Harris > Cc: "vot@ietf.org" > Date: Thu, 22 Jan 2015 12:30:30 -0500 > Subject: Re: [VoT] Trust Framework Comparisons > Nicole, > > I am not sure of this work that was done by the Government of Canada to > standardize how this community defined the risks associated with identity > assurance. It might prove useful to your communities. > > http://www.tbs-sct.gc.ca/pol/doc-eng.aspx?id=3D26776 > > Ken > > On Thursday, January 22, 2015, Nicole Harris wrote: > >> Hi Eric >> >> I think that might have got a bit lost in translation. I carried out a >> comparison of all the policies used by the different R&E Federations. >> That work is available over on the wiki: >> https://wiki.refeds.org/display/FBP/Federation+Policy+Best+Practice. It >> is more an exercise in trying to bring the R&E space to a standard >> baseline. We also took several of the more mature and compared them to >> the Kantara Assurance Framework and the OIX-FICAM framework. That info >> is on the wiki under the assurance tab....it is all very R&E specific. >> >> In terms of assurance, REFEDS is doing 2 things at the moment. Firstly >> trying to make it easier to identify what "baseline R&E federation >> assurance" looks like to other people as we have been absolutely rubbish >> at documenting well enough in the insular world of R&E. >> >> Secondly, we have pretty much thrown out all discussions on frameworks, >> authentication strength, profiles etc and instead we are asking the >> communities that we are working with what risks they are trying to >> mitigate and what the business impact is...so we are working with people >> like the SIRTFI folk on a profile looking at security incident response: >> https://wiki.refeds.org/display/GROUPS/SIRTFI. This goes a bit beyond >> the notion of having "confidence in the asserted identity"....but is >> more about confidence in a system as a whole and a belief that this can >> be done to a high level of assurance for that given community, but >> doesn't necessarily mean that an organisation has one time passwords, >> has verified the signature on a governmentID etc. >> >> So what we will probably end up with is a limited set of assurance >> profiles (not levels) that work for large cases in our community, and we >> of course then need to ensure that these can be well understood / mapped >> outside that space where necessary and that for me is where VoT comes >> in. That's a horribly simplistic way of describing things I know....I'm >> often guilty of over-simplifying :-) >> >> Overall, we may have some reasonably well developed case-studies on what >> risks our communities are trying to mitigate and what they need to be >> assured of to let users in that I hope might be interesting to this >> group in the long-term. >> >> Cheers >> >> Nicole >> >> On 22/01/2015 03:48, Colin Wallis wrote: >> > https://refeds.terena.org/index.php/Federations >> > >> > Coming to you courtesy of the Kantara eGov WG.. >> > >> > Cheers >> > Colin >> > >> > -----Original Message----- >> > From: vot [mailto:vot-bounces@ietf.org] On Behalf Of Eric Goodman >> > Sent: Thursday, 22 January 2015 10:05 a.m. >> > To: vot@ietf.org >> > Subject: Re: [VoT] Trust Framework Comparisons >> > >> >> Is there a normalized set of assertion requirements? I don't know. >> >> There are a few communities that have described their requirements bu= t, >> >> in my opinion, I am not sure how easy it is to compare and contrast >> >> these descriptions In a manner that might generate a normalized set. >> >> This might be a fantastic Masters degree analysis that some >> >> enterprising student might undertake. Or, if some federation could fi= nd >> >> the funding, that a consultant could undertake. >> > At REFEDs I heard mention of a comparison document someone (Nicole >> Harris?) may have put together comparing =E2=80=9C6 different trust fram= eworks=E2=80=9D. >> I=E2=80=99ve been successful at finding links that seem to imply such a = thing >> exists, but haven=E2=80=99t been able to find the actual document, so I= =E2=80=99m not sure >> if it=E2=80=99s relevant. I'm interested in seeing a similar comparison.= Can >> someone identify from my vague description what the document is that was >> mentioned, if it's relevant to this discussion, and perhaps where that >> document can be found? >> > >> > Thanks, >> > >> > --- Eric >> > >> > >> > >> > _______________________________________________ >> > vot mailing list >> > vot@ietf.org >> > https://www.ietf.org/mailman/listinfo/vot >> > _______________________________________________ >> > vot mailing list >> > vot@ietf.org >> > https://www.ietf.org/mailman/listinfo/vot >> >> >> -- >> Nicole Harris >> Project Development Officer >> G=C3=89ANT Association Amsterdam Office (formerly TERENA) >> Singel 468 D, 1017 AW Amsterdam >> The Netherlands >> Skype: harrisnv >> M:+31 64 610 53 95 >> >> >> _______________________________________________ >> vot mailing list >> vot@ietf.org >> https://www.ietf.org/mailman/listinfo/vot >> > > _______________________________________________ > vot mailing list > vot@ietf.org > https://www.ietf.org/mailman/listinfo/vot > > --e89a8f838df74a365e050d4138ee Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Very useful. Thanks.

On Jan 22, 2015 12:30 PM, <vot-request@ietf.org> wrote:
Send vot mailing list submissions to=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 vot@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/vot
or, via email, send a message with subject or body 'help' to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 vot-req= uest@ietf.org

You can reach the person managing the list at
=C2=A0 =C2=A0 =C2=A0 =C2=A0 vot-owner= @ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of vot digest..."

Today's Topics:

=C2=A0 =C2=A01. Re: Trust Framework Comparisons (Eric Goodman)
=C2=A0 =C2=A02. Re: Trust Framework Comparisons (Colin Wallis)
=C2=A0 =C2=A03. Re: Trust Framework Comparisons (Nicole Harris)
=C2=A0 =C2=A04. Re: Trust Framework Comparisons (Ken Dagg)


---------- Forwarded message ----------
From:=C2=A0Eric Goodman = <Eric.Goodman@ucop.edu><= br>To:=C2=A0"vot@ietf.org" &l= t;vot@ietf.org>
Cc:=C2=A0
Date= :=C2=A0Wed, 21 Jan 2015 21:05:05 +0000
Subject:=C2=A0Re: [VoT] Trust Fra= mework Comparisons
>Is there a normalized set of assertion requiremen= ts? I don't know.
>There are a few communities that have described their requirements
>but, in my opinion, I am not sure how easy it is to compare and
>contrast these=C2=A0descriptions In a manner that might generate a norm= alized=C2=A0
>set. This might be a fantastic Masters degree analysis that some enterp= rising
>student might undertake. Or, if some federation could find the funding,=
>that a consultant could undertake.

At REFEDs I heard mention of a comparison document someone (Nicole Harris?)= may have put together comparing =E2=80=9C6 different trust frameworks=E2= =80=9D. I=E2=80=99ve been successful at finding links that seem to imply su= ch a thing exists, but haven=E2=80=99t been able to find the actual documen= t, so I=E2=80=99m not sure if it=E2=80=99s relevant. I'm interested in = seeing a similar comparison. Can someone identify from my vague description= what the document is that was mentioned, if it's relevant to this disc= ussion, and perhaps where that document can be found?

Thanks,

--- Eric





---------- Forwarded message ----------
From:=C2=A0Colin Wallis = <Colin.Wallis@dia.govt.nz>
To:=C2=A0"'Eric Goodman'" <Eric.Goodman@ucop.edu>, "vot@ietf.org" <vot@ietf.org>
Cc:=C2=A0
Date:=C2=A0Thu, 22 Jan 2015 02:48:17 = +0000
Subject:=C2=A0Re: [VoT] Trust Framework Comparisons
https://= refeds.terena.org/index.php/Federations

Coming to you courtesy of the Kantara eGov WG..

Cheers
Colin

-----Original Message-----
From: vot [mailto:vot-bounces@ietf.= org] On Behalf Of Eric Goodman
Sent: Thursday, 22 January 2015 10:05 a.m.
To: vot@ietf.org
Subject: Re: [VoT] Trust Framework Comparisons

>Is there a normalized set of assertion requirements? I don't know.<= br> >There are a few communities that have described their requirements but,=
>in my opinion, I am not sure how easy it is to compare and contrast
>these=C2=A0descriptions In a manner that might generate a normalized se= t.
>This might be a fantastic Masters degree analysis that some
>enterprising student might undertake. Or, if some federation could find=
>the funding, that a consultant could undertake.

At REFEDs I heard mention of a comparison document someone (Nicole Harris?)= may have put together comparing =E2=80=9C6 different trust frameworks=E2= =80=9D. I=E2=80=99ve been successful at finding links that seem to imply su= ch a thing exists, but haven=E2=80=99t been able to find the actual documen= t, so I=E2=80=99m not sure if it=E2=80=99s relevant. I'm interested in = seeing a similar comparison. Can someone identify from my vague description= what the document is that was mentioned, if it's relevant to this disc= ussion, and perhaps where that document can be found?

Thanks,

--- Eric



_______________________________________________
vot mailing list
vot@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/vot


---------- Forwarded message ----------
From:=C2=A0Nicole Harris= <harris@terena.org>
To:= =C2=A0vot@ietf.org
Cc:=C2=A0
Date= :=C2=A0Thu, 22 Jan 2015 09:20:57 +0100
Subject:=C2=A0Re: [VoT] Trust Fra= mework Comparisons
Hi Eric

I think that might have got a bit lost in translation.=C2=A0 I carried out = a
comparison of all the policies used by the different R&E Federations. That work is available over on the wiki:
https://wiki.refeds.org/display/FBP/Federation+Polic= y+Best+Practice.=C2=A0 It
is more an exercise in trying to bring the R&E space to a standard
baseline.=C2=A0 We also took several of the more mature and compared them t= o
the Kantara Assurance Framework and the OIX-FICAM framework.=C2=A0 That inf= o
is on the wiki under the assurance tab....it is all very R&E specific.<= br>
In terms of assurance, REFEDS is doing 2 things at the moment.=C2=A0 Firstl= y
trying to make it easier to identify what "baseline R&E federation=
assurance" looks like to other people as we have been absolutely rubbi= sh
at documenting well enough in the insular world of R&E.

Secondly, we have pretty much thrown out all discussions on frameworks,
authentication strength, profiles etc and instead we are asking the
communities that we are working with what risks they are trying to
mitigate and what the business impact is...so we are working with people like the SIRTFI folk on a profile looking at security incident response: https://wiki.refeds.org/display/GROUPS/SIRTFI.=C2=A0 This goes a bit b= eyond
the notion of having "confidence in the asserted identity"....but= is
more about confidence in a system as a whole and a belief that this can
be done to a high level of assurance for that given community, but
doesn't necessarily mean that an organisation has one time passwords, has verified the signature on a governmentID etc.

So what we will probably end up with is a limited set of assurance
profiles (not levels) that work for large cases in our community, and we of course then need to ensure that these can be well understood / mapped outside that space where necessary and that for me is where VoT comes
in.=C2=A0 That's a horribly simplistic way of describing things I know.= ...I'm
often guilty of over-simplifying :-)

Overall, we may have some reasonably well developed case-studies on what risks our communities are trying to mitigate and what they need to be
assured of to let users in that I hope might be interesting to this
group in the long-term.

Cheers

Nicole

On 22/01/2015 03:48, Colin Wallis wrote:
> https://refeds.terena.org/index.php/Federations
>
> Coming to you courtesy of the Kantara eGov WG..
>
> Cheers
> Colin
>
> -----Original Message-----
> From: vot [mailto:vot-bounces@= ietf.org] On Behalf Of Eric Goodman
> Sent: Thursday, 22 January 2015 10:05 a.m.
> To: vot@ietf.org
> Subject: Re: [VoT] Trust Framework Comparisons
>
>> Is there a normalized set of assertion requirements? I don't k= now.
>> There are a few communities that have described their requirements= but,
>> in my opinion, I am not sure how easy it is to compare and contras= t
>> these descriptions In a manner that might generate a normalized se= t.
>> This might be a fantastic Masters degree analysis that some
>> enterprising student might undertake. Or, if some federation could= find
>> the funding, that a consultant could undertake.
> At REFEDs I heard mention of a comparison document someone (Nicole Har= ris?) may have put together comparing =E2=80=9C6 different trust frameworks= =E2=80=9D. I=E2=80=99ve been successful at finding links that seem to imply= such a thing exists, but haven=E2=80=99t been able to find the actual docu= ment, so I=E2=80=99m not sure if it=E2=80=99s relevant. I'm interested = in seeing a similar comparison. Can someone identify from my vague descript= ion what the document is that was mentioned, if it's relevant to this d= iscussion, and perhaps where that document can be found?
>
> Thanks,
>
> --- Eric
>
>
>
> _______________________________________________
> vot mailing list
> vot@ietf.org
> https://www.ietf.org/mailman/listinfo/vot
> _______________________________________________
> vot mailing list
> vot@ietf.org
> https://www.ietf.org/mailman/listinfo/vot


--
Nicole Harris
Project Development Officer
G=C3=89ANT Association Amsterdam Office (formerly TERENA)
Singel 468 D, 1017 AW Amsterdam
The Netherlands
Skype: harrisnv
M:+31 64 = 610 53 95





---------- Forwarded message ----------
From:=C2=A0Ken Dagg <= kendaggtbs@gmail.com>
To:= =C2=A0Nicole Harris <harris@terena.= org>
Cc:=C2=A0"vot@ietf.org<= /a>" <vot@ietf.org>
Date:= =C2=A0Thu, 22 Jan 2015 12:30:30 -0500
Subject:=C2=A0Re: [VoT] Trust Fram= ework Comparisons
Nicole,

I am not sure of this work = that was done by the Government of Canada to standardize how this community= defined=C2=A0the risks associated with identity assurance. It might prove = useful to your communities.


Ken
=
On Thursday, January 22, 2015, Nicole Harris <harris@terena.org> wrote:
Hi Eric

I think that might have got a bit lost in translation.=C2=A0 I carried out = a
comparison of all the policies used by the different R&E Federations. That work is available over on the wiki:
https://wiki.refeds.org/display/FBP/Federation+Polic= y+Best+Practice.=C2=A0 It
is more an exercise in trying to bring the R&E space to a standard
baseline.=C2=A0 We also took several of the more mature and compared them t= o
the Kantara Assurance Framework and the OIX-FICAM framework.=C2=A0 That inf= o
is on the wiki under the assurance tab....it is all very R&E specific.<= br>
In terms of assurance, REFEDS is doing 2 things at the moment.=C2=A0 Firstl= y
trying to make it easier to identify what "baseline R&E federation=
assurance" looks like to other people as we have been absolutely rubbi= sh
at documenting well enough in the insular world of R&E.

Secondly, we have pretty much thrown out all discussions on frameworks,
authentication strength, profiles etc and instead we are asking the
communities that we are working with what risks they are trying to
mitigate and what the business impact is...so we are working with people like the SIRTFI folk on a profile looking at security incident response: https://wiki.refeds.org/display/GROUPS/SIRTFI.=C2=A0 This goes a bit b= eyond
the notion of having "confidence in the asserted identity"....but= is
more about confidence in a system as a whole and a belief that this can
be done to a high level of assurance for that given community, but
doesn't necessarily mean that an organisation has one time passwords, has verified the signature on a governmentID etc.

So what we will probably end up with is a limited set of assurance
profiles (not levels) that work for large cases in our community, and we of course then need to ensure that these can be well understood / mapped outside that space where necessary and that for me is where VoT comes
in.=C2=A0 That's a horribly simplistic way of describing things I know.= ...I'm
often guilty of over-simplifying :-)

Overall, we may have some reasonably well developed case-studies on what risks our communities are trying to mitigate and what they need to be
assured of to let users in that I hope might be interesting to this
group in the long-term.

Cheers

Nicole

On 22/01/2015 03:48, Colin Wallis wrote:
> https://refeds.terena.org/index.php/Federations
>
> Coming to you courtesy of the Kantara eGov WG..
>
> Cheers
> Colin
>
> -----Original Message-----
> From: vot [mailto:vot-bounces@ietf.org] On Behalf Of Eric Goodm= an
> Sent: Thursday, 22 January 2015 10:05 a.m.
> To: vot@ietf.org
> Subject: Re: [VoT] Trust Framework Comparisons
>
>> Is there a normalized set of assertion requirements? I don't k= now.
>> There are a few communities that have described their requirements= but,
>> in my opinion, I am not sure how easy it is to compare and contras= t
>> these descriptions In a manner that might generate a normalized se= t.
>> This might be a fantastic Masters degree analysis that some
>> enterprising student might undertake. Or, if some federation could= find
>> the funding, that a consultant could undertake.
> At REFEDs I heard mention of a comparison document someone (Nicole Har= ris?) may have put together comparing =E2=80=9C6 different trust frameworks= =E2=80=9D. I=E2=80=99ve been successful at finding links that seem to imply= such a thing exists, but haven=E2=80=99t been able to find the actual docu= ment, so I=E2=80=99m not sure if it=E2=80=99s relevant. I'm interested = in seeing a similar comparison. Can someone identify from my vague descript= ion what the document is that was mentioned, if it's relevant to this d= iscussion, and perhaps where that document can be found?
>
> Thanks,
>
> --- Eric
>
>
>
> _______________________________________________
> vot mailing list
> vot@ietf.org
> https://www.ietf.org/mailman/listinfo/vot
> _______________________________________________
> vot mailing list
> vot@ietf.org
> https://www.ietf.org/mailman/listinfo/vot


--
Nicole Harris
Project Development Officer
G=C3=89ANT Association Amsterdam Office (formerly TERENA)
Singel 468 D, 1017 AW Amsterdam
The Netherlands
Skype: harrisnv
M:+31 64 610 53 95


_______________________________________________
vot mailing list
vot@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/vot

_______________________________________________
vot mailing list
vot@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/vot

--e89a8f838df74a365e050d4138ee--