From nobody Wed Nov 5 10:20:59 2014 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 80E011A90EB for ; Wed, 5 Nov 2014 10:20:56 -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, 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 VcIbZGcW2tWE for ; Wed, 5 Nov 2014 10:20:54 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0629.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:629]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4708F1A90DA for ; Wed, 5 Nov 2014 10:20:54 -0800 (PST) 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.6.9; Wed, 5 Nov 2014 18:20:30 +0000 Received: from BLUPR06MB243.namprd06.prod.outlook.com ([169.254.7.56]) by BLUPR06MB243.namprd06.prod.outlook.com ([169.254.7.56]) with mapi id 15.01.0006.000; Wed, 5 Nov 2014 18:20:30 +0000 From: Steve Olshansky To: "vot@ietf.org" Thread-Topic: bof @ IETF91 Thread-Index: AQHP+SUubFngpzNcIEOtDBuHYDDdxA== Date: Wed, 5 Nov 2014 18:20:29 +0000 Message-ID: <64400027-E8FD-42FB-8A07-199BA1537447@isoc.org> References: <54515707.3050704@sunet.se> <7B384730-5281-4EDB-BDE8-0BE4CBF3469C@sunet.se> <1FC55179-A286-4DB3-A16D-AE2F43B6D343@wierenga.net> <76EFAB58-BAFE-4A62-BCCB-B19AF8C9DDD1@sunet.se> <2B8556F1-10C4-4AF6-AE76-E7BECF637B1D@mitre.org> <545169C6.7050105@isoc.org> <3E8A42F6-0567-48FC-AC28-F7713E2411BD@isoc.org> <5451884E.6010702@sunet.se> In-Reply-To: <5451884E.6010702@sunet.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [70.59.7.227] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BLUPR06MB244; x-exchange-antispam-report-test: UriScan:; x-forefront-prvs: 0386B406AA x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(189002)(243025005)(199003)(377424004)(377454003)(51704005)(24454002)(50986999)(76176999)(99936001)(54356999)(86362001)(4396001)(66066001)(20776003)(87936001)(83716003)(15202345003)(2656002)(36756003)(64706001)(31966008)(229853001)(77156002)(19580405001)(19580395003)(15975445006)(120916001)(62966003)(15974865002)(21056001)(93886004)(107886001)(33656002)(92566001)(110136001)(2501002)(92726001)(77096003)(82746002)(97736003)(106356001)(99396003)(95666004)(122556002)(101416001)(105586002)(2351001)(450100001)(46102003)(99286002)(106116001)(107046002)(40100003)(104396001); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR06MB244; H:BLUPR06MB243.namprd06.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: multipart/signed; boundary="Apple-Mail=_526BB998-4850-4F0A-AAB7-1FA074D681AA"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 X-OriginatorOrg: isoc.org Archived-At: http://mailarchive.ietf.org/arch/msg/vot/OxJlaKrMSYb0ciZ_wMLFwOWxeFo Subject: [VoT] bof @ IETF91 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, 05 Nov 2014 18:20:56 -0000 --Apple-Mail=_526BB998-4850-4F0A-AAB7-1FA074D681AA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii All- We have a room (apparently near the reg desk) Monday night after the = plenary from 7:45 on as late as we want it: Sea Pearl 3 http://www.ietf.org/meeting/91/floor-plans.pdf There is a projector and flipchart in the room.=20 Steve -- Steve Olshansky Trust & Identity Program Lead Internet Society www.internetsociety.org On Oct 29, 2014, at 6:37 PM, Leif Johansson wrote: > Signed PGP part > On 2014-10-29 23:32, Steve Olshansky wrote: > > Same - Monday or Thursday with a slight preference for Monday. > > Steve >=20 > That settles it - monday night it is. Lets meet by the registration > after the plenary. >=20 >=20 > _______________________________________________ > vot mailing list > vot@ietf.org > https://www.ietf.org/mailman/listinfo/vot --Apple-Mail=_526BB998-4850-4F0A-AAB7-1FA074D681AA 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----- iQEcBAEBAgAGBQJUWmpsAAoJEOJO4+877g3HrdAIAKq1oGlNg/3Om3BOE8MeblkH 5XxamHW/hqdxMw433OZ/pAZmDN5w5Q7RREJ/hT0zUrHdbDXl/wLsm5vGCG5Gg9kD R0sLqlftFCBjLtqLQ4gQMWmRPXY+F20EmrqKlkl9lbgtjW/16qiN/YNDO0P1ZHnp KpGFJZ6F667+rUn2XmtRuyXY/Qb8FSyhLgxk5H6tsZT0yBrDoCSXIHPj20j/D/qm xM0B4Q+Gcjp3TzhY/5i2wYh1Tw6YCB0TZqZaB5Zwx/T0oegZDI670KjMCQeQCobG hID7MC115onpHnsPOZ08qDtQmF6VdJsKWHoDigMK4zqbpUNOX8lmy6eb7O7AuXE= =hWUS -----END PGP SIGNATURE----- --Apple-Mail=_526BB998-4850-4F0A-AAB7-1FA074D681AA-- From nobody Mon Nov 10 11:19:47 2014 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 6F4541A0233 for ; Mon, 10 Nov 2014 11:19:38 -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, 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 oxj8eFIhv0yk for ; Mon, 10 Nov 2014 11:19:34 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0685.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:685]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85A571A1ABA for ; Mon, 10 Nov 2014 11:19:34 -0800 (PST) Received: from BLUPR06MB244.namprd06.prod.outlook.com (10.242.191.153) by BLUPR06MB035.namprd06.prod.outlook.com (10.242.191.15) with Microsoft SMTP Server (TLS) id 15.1.16.15; Mon, 10 Nov 2014 19:19:12 +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.16.15; Mon, 10 Nov 2014 19:19:10 +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; Mon, 10 Nov 2014 19:19:10 +0000 From: Steve Olshansky To: "vot@ietf.org" Thread-Topic: Reminder: bof @ IETF91 - this evening after the plenary Thread-Index: AQHP/Rs0Qu65dPtjZ0+X+DkdGPmlRQ== Date: Mon, 10 Nov 2014 19:19:09 +0000 Message-ID: <4A0CDC39-5746-44F8-A825-2A7BA258D3B7@isoc.org> References: <54515707.3050704@sunet.se> <7B384730-5281-4EDB-BDE8-0BE4CBF3469C@sunet.se> <1FC55179-A286-4DB3-A16D-AE2F43B6D343@wierenga.net> <76EFAB58-BAFE-4A62-BCCB-B19AF8C9DDD1@sunet.se> <2B8556F1-10C4-4AF6-AE76-E7BECF637B1D@mitre.org> <545169C6.7050105@isoc.org> <3E8A42F6-0567-48FC-AC28-F7713E2411BD@isoc.org> <5451884E.6010702@sunet.se> <64400027-E8FD-42FB-8A07-199BA1537447@isoc.org> In-Reply-To: <64400027-E8FD-42FB-8A07-199BA1537447@isoc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [31.133.179.235] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BLUPR06MB244;UriScan:; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa: BCL:0;PCL:0;RULEID:;SRVR:BLUPR06MB244; x-forefront-prvs: 039178EF4A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(24454002)(51414003)(189002)(199003)(377424004)(243025005)(377454003)(12213003)(51704005)(2501002)(4396001)(97736003)(19580405001)(19580395003)(82746002)(110136001)(15202345003)(15975445006)(2656002)(36756003)(99286002)(95666004)(62966003)(77096003)(450100001)(77156002)(99396003)(31966008)(106356001)(46102003)(105586002)(106116001)(99936001)(54356999)(76176999)(93886004)(87936001)(33656002)(83716003)(21056001)(101416001)(50986999)(92726001)(107046002)(64706001)(20776003)(120916001)(122556002)(107886001)(2351001)(66066001)(15974865002)(86362001)(92566001)(40100003)(229853001)(104396001); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR06MB244; H:BLUPR06MB243.namprd06.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: multipart/signed; boundary="Apple-Mail=_18B578C2-E63D-4D34-8F24-F545394EA5AA"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BLUPR06MB035; X-OriginatorOrg: isoc.org Archived-At: http://mailarchive.ietf.org/arch/msg/vot/D0uVOz8PBt0VEDlmDpY7XDVox7o Subject: [VoT] Reminder: bof @ IETF91 - this evening after the plenary 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, 10 Nov 2014 19:19:38 -0000 --Apple-Mail=_18B578C2-E63D-4D34-8F24-F545394EA5AA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii All- If you are in the IETF registration area, take the escalator up to the = next level and turn left. The meeting room is down the hall, on the left = side. We will start in the room but may well migrate to a bar after a while, = if we can find one that works and that isn't encumbered with loud live = music. I look forward to seeing you there. Steve -- Steve Olshansky Trust & Identity Program Lead Internet Society www.internetsociety.org On Nov 5, 2014, at 8:20 AM, Steve Olshansky wrote: > All- > We have a room (apparently near the reg desk) Monday night after the = plenary from 7:45 on as late as we want it: Sea Pearl 3 > http://www.ietf.org/meeting/91/floor-plans.pdf >=20 > There is a projector and flipchart in the room.=20 > Steve >=20 > -- > Steve Olshansky > Trust & Identity Program Lead > Internet Society > www.internetsociety.org >=20 > On Oct 29, 2014, at 6:37 PM, Leif Johansson wrote: >=20 >> Signed PGP part >> On 2014-10-29 23:32, Steve Olshansky wrote: >>> Same - Monday or Thursday with a slight preference for Monday. >>> Steve >>=20 >> That settles it - monday night it is. Lets meet by the registration >> after the plenary. >>=20 >>=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 --Apple-Mail=_18B578C2-E63D-4D34-8F24-F545394EA5AA 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----- iQEcBAEBAgAGBQJUYQ+vAAoJEOJO4+877g3HpysH/jVRnBEtv8vDrhojOyMlhOoe YrhukeyQY3fnojXCTDwCJuNxO9LjIKcbAB8fR6zY0PO0G7gbui/frriEJ/Wmxy55 Y2ybzH4RoUOSPc6JnltE65jwzOiBeZovnAfGI8ThK1pjQbRMY8AYso8HraQ2EEN6 0m1bi1OH4YC8BDcBTfhWJhsr6BNPRbXbGdkpc2PQhWycZvtLn2NooLmU7CV7e4rg 37S40tTS5brpGFCfi4TBeo2l0QXvqUIStnBWrg/2oTOH2CBZuYeQ1X7GLuq05Wmx CDZH+Gpprrf1/VOSE2wcN2dslxTtTRqabedesc/NZ7yfinmh2+YRHB+U77p4U1Y= =jnWT -----END PGP SIGNATURE----- --Apple-Mail=_18B578C2-E63D-4D34-8F24-F545394EA5AA-- From nobody Mon Nov 10 13:08:00 2014 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 BDA791ACDF3 for ; Mon, 10 Nov 2014 13:07:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] 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 Rdv_arpLuG2B for ; Mon, 10 Nov 2014 13:07:56 -0800 (PST) Received: from smtpvbsrv1.mitre.org (smtpvbsrv1.mitre.org [198.49.146.234]) by ietfa.amsl.com (Postfix) with ESMTP id C42CC1A6F5D for ; Mon, 10 Nov 2014 13:07:55 -0800 (PST) Received: from smtpvbsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 0F32172E081 for ; Mon, 10 Nov 2014 16:07:55 -0500 (EST) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpvbsrv1.mitre.org (Postfix) with ESMTP id 0925E72E07D for ; Mon, 10 Nov 2014 16:07:55 -0500 (EST) Received: from IMCMBX01.MITRE.ORG ([169.254.1.102]) by IMCCAS04.MITRE.ORG ([129.83.29.81]) with mapi id 14.03.0174.001; Mon, 10 Nov 2014 16:07:54 -0500 From: "Richer, Justin P." To: "vot@ietf.org" Thread-Topic: Document in GitHub Thread-Index: Ac/9KmS9gn4MrtIsS7yUt5HATvDKwQ== Date: Mon, 10 Nov 2014 21:07:53 +0000 Message-ID: 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: http://mailarchive.ietf.org/arch/msg/vot/LC5v2d4bmHu4dCg-CfqYZGSWJwE Subject: [VoT] Document in GitHub 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, 10 Nov 2014 21:07:57 -0000 I've started the work of translating much of my original strawman document = to Markdown and pushing it to GitHub so that we can start taking edits via = pull request:=0A= =0A= https://github.com/vectorsoftrust/strawman/blob/master/VectorsOfTrust.md= =0A= =0A= Clone and fork away!=0A= =0A= -- Justin= From nobody Tue Nov 11 12:25:55 2014 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 19DFA1A19F9 for ; Tue, 11 Nov 2014 12:25:52 -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 gYYU5MjraS8J for ; Tue, 11 Nov 2014 12:25:46 -0800 (PST) Received: from mail-ob0-f170.google.com (mail-ob0-f170.google.com [209.85.214.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F17B71A6EE4 for ; Tue, 11 Nov 2014 12:25:30 -0800 (PST) Received: by mail-ob0-f170.google.com with SMTP id nt9so8716475obb.15 for ; Tue, 11 Nov 2014 12:25:30 -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=UHC5HOHcjFnIYhjAitRYaJpLFAU+x1CGOtxpX5X1rsI=; b=WGF/pUw1n1H+tGP6CG4SLw7MRCXWFt5poTNoMvzNwu63ZNUEjLhIGCx5wd1ipi+6b5 HuqWQgi4227f3gJltWRhjm86wqqE0NV3EljGf3VdOxpXcGMgj95N9iFUapiKC3btQGFq CTwFmLPoXPAKGK+yllQ8agPwsoPYsKrbWhTnhcouAd2bx0nvZy0l0T+msjHGZbC5hDAo e/L+IoYkWE8sophRQX0eBpyiT/e3VyfJBVOALRwGE7VLB+61wWsCr/fgKrAEmkvQKfnZ aHNxIof3+dio4KoFHsT/5Z62oU1lCoXudRXLtBj6Nm3Ga1lgcD7dlbYxjgDO90EU169Y nnaA== X-Gm-Message-State: ALoCoQmAAyNWtxZBMWtRdLGdRXASAkP5CV0DCkBn6Levco8xvPHjEgK+KOQX8rcsrwAa8uor16ko MIME-Version: 1.0 X-Received: by 10.202.227.73 with SMTP id a70mr9464208oih.59.1415737530338; Tue, 11 Nov 2014 12:25:30 -0800 (PST) Received: by 10.202.187.70 with HTTP; Tue, 11 Nov 2014 12:25:30 -0800 (PST) In-Reply-To: References: Date: Tue, 11 Nov 2014 15:25:30 -0500 Message-ID: From: Peter Alterman To: vot@ietf.org Content-Type: multipart/alternative; boundary=001a114093d2976a7705079b1452 Archived-At: http://mailarchive.ietf.org/arch/msg/vot/8wjTrPM8JX2qBaoMonNk9ti7rQ8 Subject: Re: [VoT] vot Digest, Vol 3, Issue 3 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, 11 Nov 2014 20:25:52 -0000 --001a114093d2976a7705079b1452 Content-Type: text/plain; charset=UTF-8 Pardon me not diddling with the strawman. A quick read generated the comments following. Hope they are helpful in evolving the document. What is immediately missing is a value for the quality of the credential technology because some credential types are inherently less secure - or risk mitigating - than others. My second observation is that it is not yet clear to me why these elements are called vectors. Vectors are expressions of quantities in spacio-temporal directions. So far I see three (and the fourth I recommend here) factors. In order to consider them vectors, please show me a plot on a graph and label the axes and the measurement units. My third observation is that I do not see any straightforward way for the factors to be collapsed. There are no approaches to do so presented, either. First question to ask here is whether the ecosystem will need to deploy both a transmission protocol and a receiving protocol? If the methodology requires broad uptake of RP software in order to decode the transmitted factors, the Hydra is unleashed. thanks, Peter ------------------------------------------------------------ Peter Alterman, Ph.D. Chief Operating Officer SAFE-BioPharma Association cell: 301-943-7452 On Tue, Nov 11, 2014 at 3:02 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. Document in GitHub (Richer, Justin P.) > > > ---------- Forwarded message ---------- > From: "Richer, Justin P." > To: "vot@ietf.org" > Cc: > Date: Mon, 10 Nov 2014 21:07:53 +0000 > Subject: [VoT] Document in GitHub > I've started the work of translating much of my original strawman document > to Markdown and pushing it to GitHub so that we can start taking edits via > pull request: > > https://github.com/vectorsoftrust/strawman/blob/master/VectorsOfTrust.md > > Clone and fork away! > > -- Justin > > > _______________________________________________ > vot mailing list > vot@ietf.org > https://www.ietf.org/mailman/listinfo/vot > > --001a114093d2976a7705079b1452 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Pardo= n me not diddling with the strawman. A quick read generated the comments fo= llowing. Hope they are helpful in evolving the document.

What is immediately missing is a value for the = quality of the credential technology because some credential types are inhe= rently less secure - or risk mitigating - than others.=C2=A0

My second observation is that it is not yet= clear to me why these elements are called vectors. Vectors are expressions= of quantities in spacio-temporal directions. So far I see three (and the f= ourth I recommend here) factors. In order to consider them vectors, please = show me a plot on a graph and label the axes and the measurement units.

My third observation is that I d= o not see any straightforward way for the factors to be collapsed. There ar= e no approaches to do so presented, either. First question to ask here is w= hether the ecosystem will need to deploy both a transmission protocol and a= receiving protocol? If the methodology requires broad uptake of RP softwar= e in order to decode the transmitted factors, the Hydra is unleashed.
=

thanks,

Peter

------------------------------------------------------------
Pet= er Alterman, Ph.D.
Chief Operating Officer
SAFE-BioPharma Assoc= iation
cell: 301-943-7452


On Tue, Nov 11, 2014 at 3:02 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. Document in GitHub (Richer, Justin P.)


---------- Forwarded message ----------
From:=C2=A0"Richer,= Justin P." <jricher@mitre.org= >
To:=C2=A0"vot@ietf.org= " <vot@ietf.org>
Cc:=C2= =A0
Date:=C2=A0Mon, 10 Nov 2014 21:07:53 +0000
Subject:=C2=A0[VoT] Do= cument in GitHub
I've started the work of translating much of my ori= ginal strawman document to Markdown and pushing it to GitHub so that we can= start taking edits via pull request:

=C2=A0 https://github.com/vectorsoftrust/strawm= an/blob/master/VectorsOfTrust.md

Clone and fork away!

=C2=A0-- Justin


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


--001a114093d2976a7705079b1452-- From nobody Tue Nov 11 13:35:06 2014 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 715E71A9129 for ; Tue, 11 Nov 2014 13:35:04 -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 eT5gNUlWijVh for ; Tue, 11 Nov 2014 13:35:01 -0800 (PST) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 274561ACD54 for ; Tue, 11 Nov 2014 13:35:01 -0800 (PST) Received: by mail-ig0-f181.google.com with SMTP id l13so1929637iga.8 for ; Tue, 11 Nov 2014 13:35:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:from:date:message-id:subject:to :content-type; bh=MJufhIWhtZjuWQJWvCmnJEn3Am06JsB2ZQLAMmNUE10=; b=K0kPIn8jJUnLood1ZTOHBnwGrR7yJSVdh44uvWN3Lgp9CpHvhAEku20jAEnQ66Un5c tyNEoLR/H1N992DyyVFz1SiNemLHKpH2OSOEOiSpiJcuSsjIOlLces7K88eyO2YvtgQy wHUUj2b/lv7gAic9YBGKUugQq7zB5xfrqFcnW+UyVOoiztCOoXLJ9L9xpIT2Rgx6yONI eUK7sikNVKuq3jeYgujfo+MLtlsfQL2u/rYO8iZeo1hBUKnAU9Bw9RsfAkUeKWRXDUwk H0/5zf0135Ek1OAoX8Z2maIh8F/6OmOTwJrJyEk4xGem+U/Us1ane8AD7p4jLR9q9m0e GJXg== X-Received: by 10.51.17.73 with SMTP id gc9mr804835igd.24.1415741700176; Tue, 11 Nov 2014 13:35:00 -0800 (PST) MIME-Version: 1.0 References: From: Nat Sakimura Date: Tue, 11 Nov 2014 21:34:59 +0000 Message-ID: To: Peter Alterman , vot@ietf.org Content-Type: multipart/alternative; boundary=001a1134b8b822053405079c0dec Archived-At: http://mailarchive.ietf.org/arch/msg/vot/esFDraOKj1-hYf91DTMN1iaAX8o Subject: Re: [VoT] vot Digest, Vol 3, Issue 3 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, 11 Nov 2014 21:35:04 -0000 --001a1134b8b822053405079c0dec Content-Type: text/plain; charset=UTF-8 We had a bar-bof last night at IETF 91. There was a discussion that perhaps instead of three dimension "Identity Proofing / Credential Binding / Assertion Transmission", perhaps 4 dimension "Enrollment/Credential management/Authentication/Assertion Transmission" is more appropriate. The reason was that Identity Proofing is only a step in Enrollment, Credential Binding is only a step in Credential Management, and the use of credential, i.e., Authentication, is important enough to separate out from Credential Management. Then, there followed a lengthy discussion about whether to pull Authentication out. As to the "vector" is concerned, it indeed seem to be a vector to me in the sense that: *v* = (e, c, a, t) where e:=scalar value for expressing Enrollment quality c:=scalar value for expressing Credential Management quality a:=scalar value for expressing Authentication quality t:=scalar value for expressing Assertion Transmission quality. There was discussion on how to obtain these values as well. The room opinion was that we should define the response format and then use it to define the request format. Also, there was a discussion around the nature of the value of each scalar above, and the granularity desired. We were not even sure if the values are going to be an ordered set. Everybody agreed that simplicity is a requirement for widespread adoption. If granularity were sought, then it should be defined as a subset of parent value so that implementation that do not care about these can safely ignore them. Apart from the above, importance of the operational quality of IdPs were expressed. This seem to be the quality which should be transmitted not per authentication transaction but separately, perhaps from .well-known resource. FYI, the room also had the opinion that we should not get into the "quality of attributes" in general but focus only to the entity authentication, at least for this round. Cheers, Nat On Wed Nov 12 2014 at 5:25:56 Peter Alterman wrote: > Pardon me not diddling with the strawman. A quick read generated the > comments following. Hope they are helpful in evolving the document. > > What is immediately missing is a value for the quality of the credential > technology because some credential types are inherently less secure - or > risk mitigating - than others. > > My second observation is that it is not yet clear to me why these elements > are called vectors. Vectors are expressions of quantities in > spacio-temporal directions. So far I see three (and the fourth I recommend > here) factors. In order to consider them vectors, please show me a plot on > a graph and label the axes and the measurement units. > > My third observation is that I do not see any straightforward way for the > factors to be collapsed. There are no approaches to do so presented, > either. First question to ask here is whether the ecosystem will need to > deploy both a transmission protocol and a receiving protocol? If the > methodology requires broad uptake of RP software in order to decode the > transmitted factors, the Hydra is unleashed. > > thanks, > > Peter > > ------------------------------------------------------------ > Peter Alterman, Ph.D. > Chief Operating Officer > SAFE-BioPharma Association > cell: 301-943-7452 > > > On Tue, Nov 11, 2014 at 3:02 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. Document in GitHub (Richer, Justin P.) >> >> >> ---------- Forwarded message ---------- >> From: "Richer, Justin P." >> To: "vot@ietf.org" >> Cc: >> Date: Mon, 10 Nov 2014 21:07:53 +0000 >> Subject: [VoT] Document in GitHub >> I've started the work of translating much of my original strawman >> document to Markdown and pushing it to GitHub so that we can start taking >> edits via pull request: >> >> >> https://github.com/vectorsoftrust/strawman/blob/master/VectorsOfTrust.md >> >> Clone and fork away! >> >> -- Justin >> >> >> _______________________________________________ >> 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 > --001a1134b8b822053405079c0dec Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable We had a bar-bof last night at IETF 91.=C2=A0

There was a discu= ssion that perhaps instead of three dimension "Identity Proofing / Cre= dential Binding / Assertion Transmission", perhaps 4 dimension "E= nrollment/Credential management/Authentication/Assertion Transmission"= is more appropriate. The reason was that Identity Proofing is only a step = in Enrollment, Credential Binding is only a step in Credential Management, = and the use of credential, i.e., Authentication, is important enough to sep= arate out from Credential Management. Then, there followed a lengthy discus= sion about whether to pull Authentication out.=C2=A0

As to the "vector" is concerned, it indeed seem to be a vector= to me in the sense that:=C2=A0

v =3D (e, c= , a, t)=C2=A0
=C2=A0where e:=3Dscalar value for expressing Enroll= ment quality
=C2=A0c:=3Dscalar value for expressing Credential Ma= nagement quality
=C2=A0a:=3Dscalar value for expressing Authentic= ation quality
=C2=A0t:=3Dscalar value for expressing Assertion Tr= ansmission quality.=C2=A0

There was discussion on = how to obtain these values as well. The room opinion was that we should def= ine the response format and then use it to define the request format.=C2=A0=

Also, there was a discussion around the nature of= the value of each scalar above, and the granularity desired.=C2=A0
We were not even sure if the values are going to be an ordered set. Ever= ybody agreed that simplicity is a requirement for widespread adoption. If g= ranularity were sought, then it should be defined as a subset of parent val= ue so that implementation that do not care about these can safely ignore th= em.=C2=A0

Apart from the above, importance of the = operational quality of IdPs were expressed. This seem to be the quality whi= ch should be transmitted not per authentication transaction but separately,= perhaps from .well-known resource.=C2=A0

FYI, the= room also had the opinion that we should not get into the "quality of= attributes" in general but focus only to the entity authentication, a= t least for this round.=C2=A0

Cheers,=C2=A0
<= div>
Nat



On Wed Nov 12 2014 at 5:25:56 Peter Alterman &= lt;palterman@safe-biopharma= .org> wrote:
Pardon me not diddling wit= h the strawman. A quick read generated the comments following. Hope they ar= e helpful in evolving the document.

What is immediately missing is a value for the quality of the creden= tial technology because some credential types are inherently less secure - = or risk mitigating - than others.=C2=A0

My second observation is that it is not yet clear to me why thes= e elements are called vectors. Vectors are expressions of quantities in spa= cio-temporal directions. So far I see three (and the fourth I recommend her= e) factors. In order to consider them vectors, please show me a plot on a g= raph and label the axes and the measurement units.

My third observation is that I do not see any straigh= tforward way for the factors to be collapsed. There are no approaches to do= so presented, either. First question to ask here is whether the ecosystem = will need to deploy both a transmission protocol and a receiving protocol? = If the methodology requires broad uptake of RP software in order to decode = the transmitted factors, the Hydra is unleashed.

thanks,

P= eter

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

<= /div>

On Tue, Nov 11, 2014 at 3:02 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-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. Document in GitHub (Richer, Justin P.)


---------- Forwarded message ----------
From:=C2=A0"Richer,= Justin P." <jricher@mitre.org>
To:=C2=A0"vot@ietf.org" <vot@ietf.org>
Cc:=C2=A0
Date:=C2=A0Mon, = 10 Nov 2014 21:07:53 +0000
Subject:=C2=A0[VoT] Document in GitHub
I&#= 39;ve started the work of translating much of my original strawman document= to Markdown and pushing it to GitHub so that we can start taking edits via= pull request:

=C2=A0 https://github.com/vectorsoftrust/strawm= an/blob/master/VectorsOfTrust.md

Clone and fork away!

=C2=A0-- Justin


_______________________________________________
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
--001a1134b8b822053405079c0dec-- From nobody Tue Nov 11 13:53:21 2014 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 A4A321ACEE8 for ; Tue, 11 Nov 2014 13:53:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.594 X-Spam-Level: X-Spam-Status: No, score=-2.594 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, RP_MATCHES_RCVD=-0.594, 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 PI0RFjg5CPlV for ; Tue, 11 Nov 2014 13:53:16 -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 3BBBE1ACEEC for ; Tue, 11 Nov 2014 13:53:13 -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 sABLr9l6013588 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 11 Nov 2014 13:53:10 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1415742790; bh=ibBg+cqXy61VOFxpae2u2d3L0JxN/kx/f9pPY/THyMw=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type; b=b+rxvkaSn03N9NcjSDWSBxjzI34t44gOomE5DkdP6mE1dvenCfDR26XykbHrX+AiW vQDoXd5fch1hTsUkMpT6TQTguuH63dkdYyrEblG3jVLRXZ+6OnQ3+/ce0qRRLS5PbS jGmb2QYtwK0NzvNgoAXx4nKp87Aw4i7hd72Cq1ck= Message-ID: <54628544.8040801@bluepopcorn.net> Date: Tue, 11 Nov 2014 13:53:08 -0800 From: Jim Fenton User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Nat Sakimura , Peter Alterman , vot@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------060305050707040509000508" Archived-At: http://mailarchive.ietf.org/arch/msg/vot/pJT6MZ1d6Zl5gsniWQicx-4dVnU Subject: Re: [VoT] vot Digest, Vol 3, Issue 3 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, 11 Nov 2014 21:53:19 -0000 This is a multi-part message in MIME format. --------------060305050707040509000508 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable One of the requirements should be that there be only as many dimensions to the vector as would be actionable by a Relying Party to make an authorization decision. Otherwise, the model is more complex than it needs to be. I'm not sure I understand how Enrollment, Credential Management, Authentication, and Assertion Transmission are defined (if that was discussed on the list, I'd appreciate a pointer to it). But as a relying party, if the quality of an attribute I receive is limited by something, I probably don't care whether it was because the credential management or the assertion transmission was the cause. So if this retains 4 dimensions, there should be use cases that justify the need for 4. I can do that for 2 dimensions (authentication strength/attribute reliability) by considering uses like strong pseudonymous authentication with a trustable assertion of an attribute like age. I don't have any good examples for more than 2. -Jim On 11/11/14 1:34 PM, Nat Sakimura wrote: > We had a bar-bof last night at IETF 91.=20 > > There was a discussion that perhaps instead of three dimension > "Identity Proofing / Credential Binding / Assertion Transmission", > perhaps 4 dimension "Enrollment/Credential > management/Authentication/Assertion Transmission" is more appropriate. > The reason was that Identity Proofing is only a step in Enrollment, > Credential Binding is only a step in Credential Management, and the > use of credential, i.e., Authentication, is important enough to > separate out from Credential Management. Then, there followed a > lengthy discussion about whether to pull Authentication out.=20 > > As to the "vector" is concerned, it indeed seem to be a vector to me > in the sense that:=20 > > *v* =3D (e, c, a, t)=20 > where e:=3Dscalar value for expressing Enrollment quality > c:=3Dscalar value for expressing Credential Management quality > a:=3Dscalar value for expressing Authentication quality > t:=3Dscalar value for expressing Assertion Transmission quality.=20 > > There was discussion on how to obtain these values as well. The room > opinion was that we should define the response format and then use it > to define the request format.=20 > > Also, there was a discussion around the nature of the value of each > scalar above, and the granularity desired.=20 > We were not even sure if the values are going to be an ordered set. > Everybody agreed that simplicity is a requirement for widespread > adoption. If granularity were sought, then it should be defined as a > subset of parent value so that implementation that do not care about > these can safely ignore them.=20 > > Apart from the above, importance of the operational quality of IdPs > were expressed. This seem to be the quality which should be > transmitted not per authentication transaction but separately, perhaps > from .well-known resource.=20 > > FYI, the room also had the opinion that we should not get into the > "quality of attributes" in general but focus only to the entity > authentication, at least for this round.=20 > > Cheers,=20 > > Nat > > > > > On Wed Nov 12 2014 at 5:25:56 Peter Alterman > > > wrote: > > Pardon me not diddling with the strawman. A quick read generated > the comments following. Hope they are helpful in evolving the > document. > > What is immediately missing is a value for the quality of the > credential technology because some credential types are inherently > less secure - or risk mitigating - than others.=20 > > My second observation is that it is not yet clear to me why these > elements are called vectors. Vectors are expressions of quantities > in spacio-temporal directions. So far I see three (and the fourth > I recommend here) factors. In order to consider them vectors, > please show me a plot on a graph and label the axes and the > measurement units. > > My third observation is that I do not see any straightforward way > for the factors to be collapsed. There are no approaches to do so > presented, either. First question to ask here is whether the > ecosystem will need to deploy both a transmission protocol and a > receiving protocol? If the methodology requires broad uptake of RP > software in order to decode the transmitted factors, the Hydra is > unleashed. > > thanks, > > Peter > > ------------------------------------------------------------ > Peter Alterman, Ph.D. > Chief Operating Officer > SAFE-BioPharma Association > cell: 301-943-7452 > > > On Tue, Nov 11, 2014 at 3:02 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. Document in GitHub (Richer, Justin P.) > > > ---------- Forwarded message ---------- > From: "Richer, Justin P." > > To: "vot@ietf.org " > > Cc:=20 > Date: Mon, 10 Nov 2014 21:07:53 +0000 > Subject: [VoT] Document in GitHub > I've started the work of translating much of my original > strawman document to Markdown and pushing it to GitHub so that > we can start taking edits via pull request: > > =20 > https://github.com/vectorsoftrust/strawman/blob/master/VectorsO= fTrust.md > > Clone and fork away! > > -- Justin > > > _______________________________________________ > 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 --------------060305050707040509000508 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
One of the requirements should be that there be only as many dimensions to the vector as would be actionable by a Relying Party to make an authorization decision. Otherwise, the model is more complex than it needs to be.

I'm not sure I understand how Enrollment, Credential Management, Authentication, and Assertion Transmission are defined (if that was discussed on the list, I'd appreciate a pointer to it). But as a relying party, if the quality of an attribute I receive is limited by something, I probably don't care whether it was because the credential management or the assertion transmission was the cause.

So if this retains 4 dimensions, there should be use cases that justify the need for 4. I can do that for 2 dimensions (authentication strength/attribute reliability) by considering uses like strong pseudonymous authentication with a trustable assertion of an attribute like age. I don't have any good examples for more than 2.

-Jim

On 11/11/14 1:34 PM, Nat Sakimura wrote:
We had a bar-bof last night at IETF 91. 

There was a discussion that perhaps instead of three dimension "Identity Proofing / Credential Binding / Assertion Transmission", perhaps 4 dimension "Enrollment/Credential management/Authentication/Assertion Transmission" is more appropriate. The reason was that Identity Proofing is only a step in Enrollment, Credential Binding is only a step in Credential Management, and the use of credential, i.e., Authentication, is important enough to separate out from Credential Management. Then, there followed a lengthy discussion about whether to pull Authentication out. 

As to the "vector" is concerned, it indeed seem to be a vector to me in the sense that: 

v = (e, c, a, t) 
 where e:=scalar value for expressing Enrollment quality
 c:=scalar value for expressing Credential Management quality
 a:=scalar value for expressing Authentication quality
 t:=scalar value for expressing Assertion Transmission quality. 

There was discussion on how to obtain these values as well. The room opinion was that we should define the response format and then use it to define the request format. 

Also, there was a discussion around the nature of the value of each scalar above, and the granularity desired. 
We were not even sure if the values are going to be an ordered set. Everybody agreed that simplicity is a requirement for widespread adoption. If granularity were sought, then it should be defined as a subset of parent value so that implementation that do not care about these can safely ignore them. 

Apart from the above, importance of the operational quality of IdPs were expressed. This seem to be the quality which should be transmitted not per authentication transaction but separately, perhaps from .well-known resource. 

FYI, the room also had the opinion that we should not get into the "quality of attributes" in general but focus only to the entity authentication, at least for this round. 

Cheers, 

Nat




On Wed Nov 12 2014 at 5:25:56 Peter Alterman <palterman@safe-biopharma.org> wrote:
Pardon me not diddling with the strawman. A quick read generated the comments following. Hope they are helpful in evolving the document.

What is immediately missing is a value for the quality of the credential technology because some credential types are inherently less secure - or risk mitigating - than others. 

My second observation is that it is not yet clear to me why these elements are called vectors. Vectors are expressions of quantities in spacio-temporal directions. So far I see three (and the fourth I recommend here) factors. In order to consider them vectors, please show me a plot on a graph and label the axes and the measurement units.

My third observation is that I do not see any straightforward way for the factors to be collapsed. There are no approaches to do so presented, either. First question to ask here is whether the ecosystem will need to deploy both a transmission protocol and a receiving protocol? If the methodology requires broad uptake of RP software in order to decode the transmitted factors, the Hydra is unleashed.

thanks,

Peter

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


On Tue, Nov 11, 2014 at 3:02 PM, <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. Document in GitHub (Richer, Justin P.)


---------- Forwarded message ----------
From: "Richer, Justin P." <jricher@mitre.org>
To: "vot@ietf.org" <vot@ietf.org>
Cc: 
Date: Mon, 10 Nov 2014 21:07:53 +0000
Subject: [VoT] Document in GitHub
I've started the work of translating much of my original strawman document to Markdown and pushing it to GitHub so that we can start taking edits via pull request:

  https://github.com/vectorsoftrust/strawman/blob/master/VectorsOfTrust.md

Clone and fork away!

 -- Justin


_______________________________________________
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

--------------060305050707040509000508-- From nobody Tue Nov 11 14:28:37 2014 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 A649B1A1AF4 for ; Tue, 11 Nov 2014 14:28:35 -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 IacE2S5QtWOm for ; Tue, 11 Nov 2014 14:28:32 -0800 (PST) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5CD21A1AC5 for ; Tue, 11 Nov 2014 14:28:31 -0800 (PST) Received: by mail-ig0-f176.google.com with SMTP id l13so2017716iga.15 for ; Tue, 11 Nov 2014 14:28:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:from:date:message-id:subject:to :content-type; bh=hPMqsi8EFnoaXoCzv64TgETacj0L9FEU2pAe4pgjwR0=; b=s7hZkddEaIq0rRYe8Bbkmbn4mImz49L4HmIS0eJWtLYZO/0G3onAEW0zJSSqzt7tTu tPJ9mabC/GDWZAZvF/IE+yrAxmwgZUZh1lw4YS2BILruBHRRbXqX+HiypXSxli7AfRwW gIZ9tJKs2pD6/4Nz6nPvuiVfdnHlHY3gHd/IRo+IYlLdvOb6CZLevF1HedpR3Egdim1n 3U99xWXaQYNWcvLQKv9YVYhDS7pTLRYfiDYNTnjjXlliOAyjV2LkTVhvhxEbAcP056kv sIHXXiiTekbpVxLNjT6SsrpaJ2UsBZbz621u0FV6AhLhwd7jMFwfjIkLI3YhxvgjUddi YVeQ== X-Received: by 10.42.177.9 with SMTP id bg9mr4664901icb.81.1415744910838; Tue, 11 Nov 2014 14:28:30 -0800 (PST) MIME-Version: 1.0 References: <54628544.8040801@bluepopcorn.net> From: Nat Sakimura Date: Tue, 11 Nov 2014 22:28:30 +0000 Message-ID: To: Jim Fenton , Peter Alterman , vot@ietf.org Content-Type: multipart/alternative; boundary=90e6ba61389a80f6b705079ccc4f Archived-At: http://mailarchive.ietf.org/arch/msg/vot/daZEtB6iDbM2EcPQiFNRlxWl2i0 Subject: Re: [VoT] vot Digest, Vol 3, Issue 3 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, 11 Nov 2014 22:28:35 -0000 --90e6ba61389a80f6b705079ccc4f Content-Type: text/plain; charset=UTF-8 In many cases, people do not care about Identity Proofing. As long as the credential management and after is done right, it should not matter in many commercial use case. So, in the previous expression, to some of my use cases, I am indifferent with (1, 2, 2, 2) and (4, 2, 2, 2). In the traditional SP800-63 case, however, the former is 0 and later is 2, making (1, 2, 2, 2) and (1, 1, 1, 1) indifferent, losing the information I was interested in. Also, I may want to accept (1,2,2,1) on a intranet while I am only willing to accept (1,2,2,2) over the internet. Justin was arguing to collapse the middle two, and that may well be a good simplification. In this case, I still care those three dimensions instead of four. As to the attribute reliability is concerned, the room concluded that it is out of scope for VoT for now, that we should only concentrate on entity authentication assurance. The quality of attribute should be treated more like a metadata about each attribute instead. For the Enrollment, Credential Management, Authentication, refer to ISO/IEC 29115 or ITU-T X.1254, which are almost identical apart from the formatting and 3 words. X.1254 is freely available. You can find them here: https://www.itu.int/rec/T-REC-X.1254-201209-I/en Nat On Wed Nov 12 2014 at 6:53:11 Jim Fenton wrote: > One of the requirements should be that there be only as many dimensions > to the vector as would be actionable by a Relying Party to make an > authorization decision. Otherwise, the model is more complex than it needs > to be. > > I'm not sure I understand how Enrollment, Credential Management, > Authentication, and Assertion Transmission are defined (if that was > discussed on the list, I'd appreciate a pointer to it). But as a relying > party, if the quality of an attribute I receive is limited by something, I > probably don't care whether it was because the credential management or the > assertion transmission was the cause. > > So if this retains 4 dimensions, there should be use cases that justify > the need for 4. I can do that for 2 dimensions (authentication > strength/attribute reliability) by considering uses like strong > pseudonymous authentication with a trustable assertion of an attribute like > age. I don't have any good examples for more than 2. > > > -Jim > > > On 11/11/14 1:34 PM, Nat Sakimura wrote: > > We had a bar-bof last night at IETF 91. > > There was a discussion that perhaps instead of three dimension "Identity > Proofing / Credential Binding / Assertion Transmission", perhaps 4 > dimension "Enrollment/Credential management/Authentication/Assertion > Transmission" is more appropriate. The reason was that Identity Proofing is > only a step in Enrollment, Credential Binding is only a step in Credential > Management, and the use of credential, i.e., Authentication, is important > enough to separate out from Credential Management. Then, there followed a > lengthy discussion about whether to pull Authentication out. > > As to the "vector" is concerned, it indeed seem to be a vector to me in > the sense that: > > *v* = (e, c, a, t) > where e:=scalar value for expressing Enrollment quality > c:=scalar value for expressing Credential Management quality > a:=scalar value for expressing Authentication quality > t:=scalar value for expressing Assertion Transmission quality. > > There was discussion on how to obtain these values as well. The room > opinion was that we should define the response format and then use it to > define the request format. > > Also, there was a discussion around the nature of the value of each > scalar above, and the granularity desired. > We were not even sure if the values are going to be an ordered set. > Everybody agreed that simplicity is a requirement for widespread adoption. > If granularity were sought, then it should be defined as a subset of parent > value so that implementation that do not care about these can safely ignore > them. > > Apart from the above, importance of the operational quality of IdPs were > expressed. This seem to be the quality which should be transmitted not per > authentication transaction but separately, perhaps from .well-known > resource. > > FYI, the room also had the opinion that we should not get into the > "quality of attributes" in general but focus only to the entity > authentication, at least for this round. > > Cheers, > > Nat > > > > > On Wed Nov 12 2014 at 5:25:56 Peter Alterman > wrote: > >> Pardon me not diddling with the strawman. A quick read generated the >> comments following. Hope they are helpful in evolving the document. >> >> What is immediately missing is a value for the quality of the >> credential technology because some credential types are inherently less >> secure - or risk mitigating - than others. >> >> My second observation is that it is not yet clear to me why these >> elements are called vectors. Vectors are expressions of quantities in >> spacio-temporal directions. So far I see three (and the fourth I recommend >> here) factors. In order to consider them vectors, please show me a plot on >> a graph and label the axes and the measurement units. >> >> My third observation is that I do not see any straightforward way for >> the factors to be collapsed. There are no approaches to do so presented, >> either. First question to ask here is whether the ecosystem will need to >> deploy both a transmission protocol and a receiving protocol? If the >> methodology requires broad uptake of RP software in order to decode the >> transmitted factors, the Hydra is unleashed. >> >> thanks, >> >> Peter >> >> ------------------------------------------------------------ >> Peter Alterman, Ph.D. >> Chief Operating Officer >> SAFE-BioPharma Association >> cell: 301-943-7452 >> >> >> On Tue, Nov 11, 2014 at 3:02 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. Document in GitHub (Richer, Justin P.) >>> >>> >>> ---------- Forwarded message ---------- >>> From: "Richer, Justin P." >>> To: "vot@ietf.org" >>> Cc: >>> Date: Mon, 10 Nov 2014 21:07:53 +0000 >>> Subject: [VoT] Document in GitHub >>> I've started the work of translating much of my original strawman >>> document to Markdown and pushing it to GitHub so that we can start taking >>> edits via pull request: >>> >>> >>> https://github.com/vectorsoftrust/strawman/blob/master/VectorsOfTrust.md >>> >>> Clone and fork away! >>> >>> -- Justin >>> >>> >>> _______________________________________________ >>> 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 listvot@ietf.orghttps://www.ietf.org/mailman/listinfo/vot > > > --90e6ba61389a80f6b705079ccc4f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable In many cases, people do not care about Identity Proofing. As long as the c= redential management and after is done right, it should not matter in many = commercial use case. So, in the previous expression, to some of my use case= s, I am indifferent with (1, 2, 2, 2) and (4, 2, 2, 2). In the traditional = SP800-63 case, however, the former is 0 and later is 2, making (1, 2, 2, 2)= and (1, 1, 1, 1) indifferent, losing the information I was interested in. = Also, I may want to accept (1,2,2,1) on a intranet while I am only willing = to accept (1,2,2,2) over the internet. Justin was arguing to collapse the m= iddle two, and that may well be a good simplification. In this case, I stil= l care those three dimensions instead of four.=C2=A0

As to the attribute reliability is concerned, the room concluded that it i= s out of scope for VoT for now, that we should only concentrate on entity a= uthentication assurance. The quality of attribute should be treated more li= ke a metadata about each attribute instead.=C2=A0

= For the=C2=A0Enrollment, Cre= dential Management, Authentication, refer to ISO/IEC 29115 or ITU-T X.1254,= which are almost identical apart from the formatting and 3 words. X.1254 i= s freely available. You can find them here:=C2=A0https://www.itu.int/rec/T-REC-X.1= 254-201209-I/en

Nat


On Wed Nov 12 2014 at 6:53:11 Jim Fenton <fenton@bluepopcorn.net> wrote:
=20 =20 =20
One of the requirements should be that there be only as many dimensions to the vector as would be actionable by a Relying Party to make an authorization decision. Otherwise, the model is more complex than it needs to be.

I'm not sure I understand how Enrollment, Credential Management, Authentication, and Assertion Transmission are defined (if that was discussed on the list, I'd appreciate a pointer to it). But a= s a relying party, if the quality of an attribute I receive is limited by something, I probably don't care whether it was becaus= e the credential management or the assertion transmission was the cause.

So if this retains 4 dimensions, there should be use cases that justify the need for 4. I can do that for 2 dimensions (authentication strength/attribute reliability) by considering uses like strong pseudonymous authentication with a trustable assertion of an attribute like age. I don't have any good example= s for more than 2.


-Jim


On 11/11/14 1:34 PM, Nat Sakimura wrote:
We had a bar-bof last night at IETF 91.=C2=A0=

There was a discussion that perhaps instead of three dimension "Identity Proofing / Credential Binding / Assertion Transmission", perhaps 4 dimension "Enrollment/Credential management/Authentication/Assertion Transmission" is more appropriate. The reason was that Identity Proofing is only a step in Enrollment, Credential Binding is only a step in Credential Management, and the use of credential, i.e., Authentication, is important enough to separate out from Credential Management. Then, there followed a lengthy discussion about whether to pull Authentication out.=C2=A0

As to the "vector" is concerned, it indeed seem to be = a vector to me in the sense that:=C2=A0

v =3D (e, c, a, t)=C2=A0
=C2=A0where e:=3Dscalar value for expressing Enrollment quality<= /div>
=C2=A0c:=3Dscalar value for expressing Credential Management qua= lity
=C2=A0a:=3Dscalar value for expressing Authentication quality
=C2=A0t:=3Dscalar value for expressing Assertion Transmission quality.=C2=A0

There was discussion on how to obtain these values as well. The room opinion was that we should define the response format and then use it to define the request format.=C2=A0

Also, there was a discussion around the nature of the value of each scalar above, and the granularity desired.=C2=A0
We were not even sure if the values are going to be an ordered set. Everybody agreed that simplicity is a requirement for widespread adoption. If granularity were sought, then it should be defined as a subset of parent value so that implementation that do not care about these can safely ignore them.=C2=A0

Apart from the above, importance of the operational quality of IdPs were expressed. This seem to be the quality which should be transmitted not per authentication transaction but separately, perhaps from .well-known resource.=C2=A0

FYI, the room also had the opinion that we should not get into the "quality of attributes" in general but focus onl= y to the entity authentication, at least for this round.=C2=A0

Cheers,=C2=A0

Nat




On Wed Nov 12 2014 at 5:25:56 Peter Alterman <palterman@safe-biopharma.org> wrote:
Pardon me not diddling with the strawman. A quick read generated the comments following. Hope they are helpful in evolving the document.

What is immediately missing is a value for the quality of the credential technology because some credential types are inherently less secure - or risk mitigating - than others.=C2=A0

My second observation is that it is not yet clear to me why these elements are called vectors. Vectors are expressions of quantities in spacio-temporal directions. So far I see three (and the fourth I recommend here) factors. In order to consider them vectors, please show me a plot on a graph and label the axes and the measurement units.

My third observation is that I do not see any straightforward way for the factors to be collapsed. There are no approaches to do so presented, either. First question to ask here is whether the ecosystem will need to deploy both a transmission protocol and a receiving protocol? If the methodology requires broad uptake of RP software in order to decode the transmitted factors, the Hydra is unleashed.

thanks,

Peter

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


On Tue, Nov 11, 2014 at 3:02 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/listi= nfo/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. Document in GitHub (Richer, Justin P.)


---------- Forwarded message ----------
From:=C2=A0"Richer, Justin P." <jricher@mitre.org>
To:=C2=A0"vot@ietf.org" <vot@i= etf.org>
Cc:=C2=A0
Date:=C2=A0Mon, 10 Nov 2014 21:07:53 +0000
Subject:=C2=A0[VoT] Document in GitHub
I've started the work of translating much of my origina= l strawman document to Markdown and pushing it to GitHub so that we can start taking edits via pull request:

=C2=A0 https://github.com/vecto= rsoftrust/strawman/blob/master/VectorsOfTrust.md

Clone and fork away!

=C2=A0-- Justin


_______________________________________________
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
htt=
ps://www.ietf.org/mailman/listinfo/vot

--90e6ba61389a80f6b705079ccc4f-- From nobody Tue Nov 11 15:09:39 2014 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 E55451A1B6B for ; Tue, 11 Nov 2014 15:09:36 -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 toEAPAkXxNAL for ; Tue, 11 Nov 2014 15:09:30 -0800 (PST) Received: from mail-ob0-f173.google.com (mail-ob0-f173.google.com [209.85.214.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89F101A1B11 for ; Tue, 11 Nov 2014 15:09:30 -0800 (PST) Received: by mail-ob0-f173.google.com with SMTP id wn1so8228700obc.18 for ; Tue, 11 Nov 2014 15:09:30 -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=Im7XoJ3DXfAR2Gy1EIEZ0nTL69qOvLWKRMqackZ1Pas=; b=MqZa61vOksIgMiYWcq9a0Al1I986SFWKhK0a1XjdzIoFDNbaQH+rwwkqVQUUPOSW5s ULLwwscU6X8HuX7oFqqmj1gEPkk/lrbR084FaGNc7JrmQSUu9kva4N3CQdaxyLUg0uwN +CFz6nkV6wNBS8G5+XQGzGY5nsGbI5OzDFVUnYFQuKcTiWfDHcwVEGulXv6RF/2YPL79 ghsYEssKve9l0/0yu6EU8l/ofpj5OjQuBJu6ry/wzDdy1mMFjYxO26AEmeMYhbJCnEIw Gud9YutXrx+YXQVYWJk10uSRx3nMuk0WYi7etk3RY7Tz0CzX787bLKG3fZv5Zlej+6qj n9bw== X-Gm-Message-State: ALoCoQloYR1lNVu0tROhOlZ8ZX8Gmmah+Ws+k1haG/U94H7k6eJUQlWeUTtWp5t3trHK/U+zu4+g MIME-Version: 1.0 X-Received: by 10.202.197.199 with SMTP id v190mr33286033oif.2.1415747369800; Tue, 11 Nov 2014 15:09:29 -0800 (PST) Received: by 10.202.187.70 with HTTP; Tue, 11 Nov 2014 15:09:29 -0800 (PST) In-Reply-To: References: <54628544.8040801@bluepopcorn.net> Date: Tue, 11 Nov 2014 18:09:29 -0500 Message-ID: From: Peter Alterman To: Nat Sakimura Content-Type: multipart/alternative; boundary=001a11352dfc11ad5805079d5faf Archived-At: http://mailarchive.ietf.org/arch/msg/vot/B_75I9TXDXJpo54NEO1y1QKZQSU Cc: Jim Fenton , vot@ietf.org Subject: Re: [VoT] vot Digest, Vol 3, Issue 3 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, 11 Nov 2014 23:09:37 -0000 --001a11352dfc11ad5805079d5faf Content-Type: text/plain; charset=UTF-8 Nat et. al. Let's not reason backwards from use cases but forwards from expertise. There are a zillion use cases out there that can be generated for any model (sort of like a cost/benefit analysis - just tell the analyst what answer you want and let him/her crank out the sausage). Rather, what are the legitimate components of an identity assertion; what's the nature of the relationship among them? Nothing I've seen so far changes my opinion that there are four variables: strength of identity proofing (measured against a benchmark that incorporates *both* 800-63 and 29115); intrinsic resistance of credential type to attack (see prior benchmarking comment); credential management (how well it addresses the threat vectors in 29115 and aligns with 800-63 processes, and exchange, which incorporates mitigation of data in motion threat vectors listed in 29115 relevant to AuthN. I fear there is a fair amount of rat hole diving in process, and I'm urging a pragmatic eye here. Strongly support putting off any discussion of extended attributes until this particular effort has been completed. No further work on attributes should go forward without benchmarking the myriad efforts in that arena in the past 3 years so we don't reinvent any wheels or redefine the meaning of "round." Also agree that the AuthN process is not part of determining the trustworthiness (rat hole warning) of an online identity assertion but the process of making such a determination. Finally, scalar is not vector. C'mon guys, give an old man a break. We're talking factors, not vectors. As an example, a threat vector is an identity assertion threat aimed at someone or some process: it has strength and it has direction. regards, Peter ------------------------------------------------------------ Peter Alterman, Ph.D. Chief Operating Officer SAFE-BioPharma Association cell: 301-943-7452 On Tue, Nov 11, 2014 at 5:28 PM, Nat Sakimura wrote: > In many cases, people do not care about Identity Proofing. As long as the > credential management and after is done right, it should not matter in many > commercial use case. So, in the previous expression, to some of my use > cases, I am indifferent with (1, 2, 2, 2) and (4, 2, 2, 2). In the > traditional SP800-63 case, however, the former is 0 and later is 2, making > (1, 2, 2, 2) and (1, 1, 1, 1) indifferent, losing the information I was > interested in. Also, I may want to accept (1,2,2,1) on a intranet while I > am only willing to accept (1,2,2,2) over the internet. Justin was arguing > to collapse the middle two, and that may well be a good simplification. In > this case, I still care those three dimensions instead of four. > > As to the attribute reliability is concerned, the room concluded that it > is out of scope for VoT for now, that we should only concentrate on entity > authentication assurance. The quality of attribute should be treated more > like a metadata about each attribute instead. > > For the Enrollment, Credential Management, Authentication, refer to > ISO/IEC 29115 or ITU-T X.1254, which are almost identical apart from the > formatting and 3 words. X.1254 is freely available. You can find them here: > https://www.itu.int/rec/T-REC-X.1254-201209-I/en > > Nat > > > On Wed Nov 12 2014 at 6:53:11 Jim Fenton wrote: > >> One of the requirements should be that there be only as many dimensions >> to the vector as would be actionable by a Relying Party to make an >> authorization decision. Otherwise, the model is more complex than it needs >> to be. >> >> I'm not sure I understand how Enrollment, Credential Management, >> Authentication, and Assertion Transmission are defined (if that was >> discussed on the list, I'd appreciate a pointer to it). But as a relying >> party, if the quality of an attribute I receive is limited by something, I >> probably don't care whether it was because the credential management or the >> assertion transmission was the cause. >> >> So if this retains 4 dimensions, there should be use cases that justify >> the need for 4. I can do that for 2 dimensions (authentication >> strength/attribute reliability) by considering uses like strong >> pseudonymous authentication with a trustable assertion of an attribute like >> age. I don't have any good examples for more than 2. >> >> >> -Jim >> >> >> On 11/11/14 1:34 PM, Nat Sakimura wrote: >> >> We had a bar-bof last night at IETF 91. >> >> There was a discussion that perhaps instead of three dimension "Identity >> Proofing / Credential Binding / Assertion Transmission", perhaps 4 >> dimension "Enrollment/Credential management/Authentication/Assertion >> Transmission" is more appropriate. The reason was that Identity Proofing is >> only a step in Enrollment, Credential Binding is only a step in Credential >> Management, and the use of credential, i.e., Authentication, is important >> enough to separate out from Credential Management. Then, there followed a >> lengthy discussion about whether to pull Authentication out. >> >> As to the "vector" is concerned, it indeed seem to be a vector to me in >> the sense that: >> >> *v* = (e, c, a, t) >> where e:=scalar value for expressing Enrollment quality >> c:=scalar value for expressing Credential Management quality >> a:=scalar value for expressing Authentication quality >> t:=scalar value for expressing Assertion Transmission quality. >> >> There was discussion on how to obtain these values as well. The room >> opinion was that we should define the response format and then use it to >> define the request format. >> >> Also, there was a discussion around the nature of the value of each >> scalar above, and the granularity desired. >> We were not even sure if the values are going to be an ordered set. >> Everybody agreed that simplicity is a requirement for widespread adoption. >> If granularity were sought, then it should be defined as a subset of parent >> value so that implementation that do not care about these can safely ignore >> them. >> >> Apart from the above, importance of the operational quality of IdPs >> were expressed. This seem to be the quality which should be transmitted not >> per authentication transaction but separately, perhaps from .well-known >> resource. >> >> FYI, the room also had the opinion that we should not get into the >> "quality of attributes" in general but focus only to the entity >> authentication, at least for this round. >> >> Cheers, >> >> Nat >> >> >> >> >> On Wed Nov 12 2014 at 5:25:56 Peter Alterman < >> palterman@safe-biopharma.org> wrote: >> >>> Pardon me not diddling with the strawman. A quick read generated the >>> comments following. Hope they are helpful in evolving the document. >>> >>> What is immediately missing is a value for the quality of the >>> credential technology because some credential types are inherently less >>> secure - or risk mitigating - than others. >>> >>> My second observation is that it is not yet clear to me why these >>> elements are called vectors. Vectors are expressions of quantities in >>> spacio-temporal directions. So far I see three (and the fourth I recommend >>> here) factors. In order to consider them vectors, please show me a plot on >>> a graph and label the axes and the measurement units. >>> >>> My third observation is that I do not see any straightforward way for >>> the factors to be collapsed. There are no approaches to do so presented, >>> either. First question to ask here is whether the ecosystem will need to >>> deploy both a transmission protocol and a receiving protocol? If the >>> methodology requires broad uptake of RP software in order to decode the >>> transmitted factors, the Hydra is unleashed. >>> >>> thanks, >>> >>> Peter >>> >>> ------------------------------------------------------------ >>> Peter Alterman, Ph.D. >>> Chief Operating Officer >>> SAFE-BioPharma Association >>> cell: 301-943-7452 >>> >>> >>> On Tue, Nov 11, 2014 at 3:02 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. Document in GitHub (Richer, Justin P.) >>>> >>>> >>>> ---------- Forwarded message ---------- >>>> From: "Richer, Justin P." >>>> To: "vot@ietf.org" >>>> Cc: >>>> Date: Mon, 10 Nov 2014 21:07:53 +0000 >>>> Subject: [VoT] Document in GitHub >>>> I've started the work of translating much of my original strawman >>>> document to Markdown and pushing it to GitHub so that we can start taking >>>> edits via pull request: >>>> >>>> >>>> https://github.com/vectorsoftrust/strawman/blob/master/VectorsOfTrust.md >>>> >>>> Clone and fork away! >>>> >>>> -- Justin >>>> >>>> >>>> _______________________________________________ >>>> 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 listvot@ietf.orghttps://www.ietf.org/mailman/listinfo/vot >> >> >> --001a11352dfc11ad5805079d5faf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Na= t et. al.

=
Let's not= reason backwards from use cases but forwards from expertise. There are a z= illion use cases out there that can be generated for any model (sort of lik= e a cost/benefit analysis - just tell the analyst what answer you want and = let him/her crank out the sausage). Rather, what are the legitimate compone= nts of an identity assertion; what's the nature of the relationship amo= ng them? Nothing I've seen so far changes my opinion that there are fou= r variables: strength of identity proofing (measured against a benchmark th= at incorporates *both* 800-63 and 29115); intrinsic resistance of credentia= l type to attack (see prior benchmarking comment); credential management (h= ow well it addresses the threat vectors in 29115 and aligns with 800-63 pro= cesses, and exchange, which incorporates mitigation of data in motion threa= t vectors listed in 29115 relevant to AuthN.=C2=A0

I fear there is a fair amount of rat hole d= iving in process, and I'm urging a pragmatic eye here. Strongly support= putting off any discussion of extended attributes until this particular ef= fort has been completed. No further work on attributes should go forward wi= thout benchmarking the myriad efforts in that arena in the past 3 years so = we don't reinvent any wheels or redefine the meaning of "round.&qu= ot; Also agree that the AuthN process is not part of determining the trustw= orthiness (rat hole warning) of an online identity assertion but the proces= s of making such a determination.

Finally, scalar is not vector. C'mon guys, give an old man= a break. We're talking factors, not vectors. As an example, a threat v= ector is an identity assertion threat aimed at someone or some process: it = has strength and it has direction.

regards,

Peter


---------------------------= ---------------------------------
Peter Alterman, Ph.D.
C= hief Operating Officer
SAFE-BioPharma Association
cell: 301-943= -7452


On Tue, Nov 11, 2014 at 5:28 PM, Nat Sakimur= a <sakimura@gmail.com> wrote:
In many cases, people do not care about Identity Proofing. As long as = the credential management and after is done right, it should not matter in = many commercial use case. So, in the previous expression, to some of my use= cases, I am indifferent with (1, 2, 2, 2) and (4, 2, 2, 2). In the traditi= onal SP800-63 case, however, the former is 0 and later is 2, making (1, 2, = 2, 2) and (1, 1, 1, 1) indifferent, losing the information I was interested= in. Also, I may want to accept (1,2,2,1) on a intranet while I am only wil= ling to accept (1,2,2,2) over the internet. Justin was arguing to collapse = the middle two, and that may well be a good simplification. In this case, I= still care those three dimensions instead of four.=C2=A0

As to the attribute reliability is concerned, the room concluded that= it is out of scope for VoT for now, that we should only concentrate on ent= ity authentication assurance. The quality of attribute should be treated mo= re like a metadata about each attribute instead.=C2=A0

=
For the=C2=A0Enrollment= , Credential Management, Authentication, refer to ISO/IEC 29115 or ITU-T X.= 1254, which are almost identical apart from the formatting and 3 words. X.1= 254 is freely available. You can find them here:=C2=A0https://ww= w.itu.int/rec/T-REC-X.1254-201209-I/en

Nat


=
On Wed Nov 12 2014 at 6:53:11 Jim Fenton <fenton@bluepopcorn= .net> wrote:
=20 =20 =20
One of the requirements should be that there be only as many dimensions to the vector as would be actionable by a Relying Party to make an authorization decision. Otherwise, the model is more complex than it needs to be.

I'm not sure I understand how Enrollment, Credential Management, Authentication, and Assertion Transmission are defined (if that was discussed on the list, I'd appreciate a pointer to it). But a= s a relying party, if the quality of an attribute I receive is limited by something, I probably don't care whether it was becaus= e the credential management or the assertion transmission was the cause.

So if this retains 4 dimensions, there should be use cases that justify the need for 4. I can do that for 2 dimensions (authentication strength/attribute reliability) by considering uses like strong pseudonymous authentication with a trustable assertion of an attribute like age. I don't have any good example= s for more than 2.


-Jim


On 11/11/14 1:34 PM, Nat Sakimura wrote:
We had a bar-bof last night at IETF 91.=C2=A0=

There was a discussion that perhaps instead of three dimension "Identity Proofing / Credential Binding / Assertion Transmission", perhaps 4 dimension "Enrollment/Credential management/Authentication/Assertion Transmission" is more appropriate. The reason was that Identity Proofing is only a step in Enrollment, Credential Binding is only a step in Credential Management, and the use of credential, i.e., Authentication, is important enough to separate out from Credential Management. Then, there followed a lengthy discussion about whether to pull Authentication out.=C2=A0

As to the "vector" is concerned, it indeed seem to be = a vector to me in the sense that:=C2=A0

v =3D (e, c, a, t)=C2=A0
=C2=A0where e:=3Dscalar value for expressing Enrollment quality<= /div>
=C2=A0c:=3Dscalar value for expressing Credential Management qua= lity
=C2=A0a:=3Dscalar value for expressing Authentication quality
=C2=A0t:=3Dscalar value for expressing Assertion Transmission quality.=C2=A0

There was discussion on how to obtain these values as well. The room opinion was that we should define the response format and then use it to define the request format.=C2=A0

Also, there was a discussion around the nature of the value of each scalar above, and the granularity desired.=C2=A0
We were not even sure if the values are going to be an ordered set. Everybody agreed that simplicity is a requirement for widespread adoption. If granularity were sought, then it should be defined as a subset of parent value so that implementation that do not care about these can safely ignore them.=C2=A0

Apart from the above, importance of the operational quality of IdPs were expressed. This seem to be the quality which should be transmitted not per authentication transaction but separately, perhaps from .well-known resource.=C2=A0

FYI, the room also had the opinion that we should not get into the "quality of attributes" in general but focus onl= y to the entity authentication, at least for this round.=C2=A0

Cheers,=C2=A0

Nat




On Wed Nov 12 2014 at 5:25:56 Peter Alterman <palterman@safe-biopharma.org> wrote:
Pardon me not diddling with the strawman. A quick read generated the comments following. Hope they are helpful in evolving the document.

What is immediately missing is a value for the quality of the credential technology because some credential types are inherently less secure - or risk mitigating - than others.=C2=A0

My second observation is that it is not yet clear to me why these elements are called vectors. Vectors are expressions of quantities in spacio-temporal directions. So far I see three (and the fourth I recommend here) factors. In order to consider them vectors, please show me a plot on a graph and label the axes and the measurement units.

My third observation is that I do not see any straightforward way for the factors to be collapsed. There are no approaches to do so presented, either. First question to ask here is whether the ecosystem will need to deploy both a transmission protocol and a receiving protocol? If the methodology requires broad uptake of RP software in order to decode the transmitted factors, the Hydra is unleashed.

thanks,

Peter

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


On Tue, Nov 11, 2014 at 3:02 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/listi= nfo/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. Document in GitHub (Richer, Justin P.)


---------- Forwarded message ----------
From:=C2=A0"Richer, Justin P." <jricher@mitre.org>
To:=C2=A0"vot@ietf.org" <vot@i= etf.org>
Cc:=C2=A0
Date:=C2=A0Mon, 10 Nov 2014 21:07:53 +0000
Subject:=C2=A0[VoT] Document in GitHub
I've started the work of translating much of my origina= l strawman document to Markdown and pushing it to GitHub so that we can start taking edits via pull request:

=C2=A0 https://github.com/vecto= rsoftrust/strawman/blob/master/VectorsOfTrust.md

Clone and fork away!

=C2=A0-- Justin


_______________________________________________
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
htt=
ps://www.ietf.org/mailman/listinfo/vot


--001a11352dfc11ad5805079d5faf-- From nobody Tue Nov 11 15:09:56 2014 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 189E51A1B11 for ; Tue, 11 Nov 2014 15:09:52 -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 MzNg84oSkPKs for ; Tue, 11 Nov 2014 15:09:41 -0800 (PST) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C93531A6FA3 for ; Tue, 11 Nov 2014 15:09:40 -0800 (PST) Received: by mail-la0-f52.google.com with SMTP id pv20so10195405lab.39 for ; Tue, 11 Nov 2014 15:09:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ge3nLPvCA9KyA2NYAHqItGsfppeo3Kn8V3i/U7JfooI=; b=GDUg99aEqJQ/gM/V+rpMczVyDceU9LKuHjs9bSL/cZmLFbYZKtSG0I1Gv5J/Y10YuK tQDaExEtiIzBwM4JFj1RPzoy8IbGBVr9ZsoT9rBCuXJCQKZbrkuhY6gSMjegbwljOLNX 5oLUlXHBXUKn5/zmsBxVQceVQL5Ykhdorg3xFATkf21dYFd6OVs4ceXLzRUX3goW5arH 2Q0AUk0JfXk/51+3cfQ0wR5/PZBYh+UGzzwx8Mk4lFzVWgq31pB7TobsAmaavuvLz1CG aPhVK8ogBvvewww7n4VxHYFmjRtiSIVqhSfR1g/0v3YTxORN+TtKaH9Ed3wIjxqXqH45 7XBw== 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:from:date :message-id:subject:to:cc:content-type; bh=ge3nLPvCA9KyA2NYAHqItGsfppeo3Kn8V3i/U7JfooI=; b=XooX8JJ/gzWqdlSnYwToPZseVK3LO/xrnEVoP1S3gL6jHlo2VPScFPy3aQR7trIzv1 4osJZlhVuY43vIph+Vw1zhek6rihMLdrRKF1mGFAR9PUeEFYjCoufYz78PXX5q09JUwj I4nixtcUAlaC5awv3SjqcyHaEuMuUuA/uYqoI3tVPOn7gw2qeIhDXnHHfwtmnNYrMFVE 3dDA7pscmFtw8G9Lb0xomp23t50jOZMlzw7q5BzUAoi6HXddYP5La3NzGwvmxZQ8Up9N JWO2Bmu/+rwykpICxYHBGOLKhT1aaSjJIg4W/FxUisIL4OKdhaOhtyYxOl1ESWvEsHX3 033Q== X-Received: by 10.152.206.11 with SMTP id lk11mr39528279lac.42.1415747379154; Tue, 11 Nov 2014 15:09:39 -0800 (PST) Received: from mail-lb0-f171.google.com (mail-lb0-f171.google.com. [209.85.217.171]) by mx.google.com with ESMTPSA id vr7sm6308091lbb.21.2014.11.11.15.09.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 11 Nov 2014 15:09:37 -0800 (PST) Received: by mail-lb0-f171.google.com with SMTP id b6so8350149lbj.2 for ; Tue, 11 Nov 2014 15:09:37 -0800 (PST) X-Gm-Message-State: ALoCoQlUaO/8da+5fnaBEzh8XVKYZc9WzOrIrm0phRAOnySI5OZOhbcuYBwraW4qyClK9ZZlVLpV X-Received: by 10.112.235.196 with SMTP id uo4mr29277593lbc.66.1415747377300; Tue, 11 Nov 2014 15:09:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.134.213 with HTTP; Tue, 11 Nov 2014 15:08:57 -0800 (PST) In-Reply-To: References: <54628544.8040801@bluepopcorn.net> From: Anil John Date: Tue, 11 Nov 2014 18:08:57 -0500 Message-ID: To: Nat Sakimura Content-Type: multipart/alternative; boundary=001a11c3daf4841ac405079d5f5b Archived-At: http://mailarchive.ietf.org/arch/msg/vot/XB8a8lZyS-oQhcITWLKDDRxC8R4 Cc: Jim Fenton , Peter Alterman , "vot@ietf.org" Subject: Re: [VoT] vot Digest, Vol 3, Issue 3 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, 11 Nov 2014 23:09:52 -0000 --001a11c3daf4841ac405079d5f5b Content-Type: text/plain; charset=UTF-8 >In many cases, people do not care about Identity Proofing. As long as the credential management >and after is done right, it should not matter in many commercial use case. An interesting perspective Nat. So the focus of the VoT appears to be about Authentication and Token Assurance and to make it easier for developers to consume the results (per earlier conversational threads). If that is indeed so, given the work that the Trust Elevation TC at OASIS had done / is doing and the work that FIDO is doing, I am unsure of the value add here. Regards, - Anil :- Anil John :- *Making Digital Services Secure and Trustworthy* :- https://blog.aniljohn.com On Tue, Nov 11, 2014 at 5:28 PM, Nat Sakimura wrote: > In many cases, people do not care about Identity Proofing. As long as the > credential management and after is done right, it should not matter in many > commercial use case. So, in the previous expression, to some of my use > cases, I am indifferent with (1, 2, 2, 2) and (4, 2, 2, 2). In the > traditional SP800-63 case, however, the former is 0 and later is 2, making > (1, 2, 2, 2) and (1, 1, 1, 1) indifferent, losing the information I was > interested in. Also, I may want to accept (1,2,2,1) on a intranet while I > am only willing to accept (1,2,2,2) over the internet. Justin was arguing > to collapse the middle two, and that may well be a good simplification. In > this case, I still care those three dimensions instead of four. > > As to the attribute reliability is concerned, the room concluded that it > is out of scope for VoT for now, that we should only concentrate on entity > authentication assurance. The quality of attribute should be treated more > like a metadata about each attribute instead. > > For the Enrollment, Credential Management, Authentication, refer to > ISO/IEC 29115 or ITU-T X.1254, which are almost identical apart from the > formatting and 3 words. X.1254 is freely available. You can find them here: > https://www.itu.int/rec/T-REC-X.1254-201209-I/en > > Nat > > > On Wed Nov 12 2014 at 6:53:11 Jim Fenton wrote: > >> One of the requirements should be that there be only as many dimensions >> to the vector as would be actionable by a Relying Party to make an >> authorization decision. Otherwise, the model is more complex than it needs >> to be. >> >> I'm not sure I understand how Enrollment, Credential Management, >> Authentication, and Assertion Transmission are defined (if that was >> discussed on the list, I'd appreciate a pointer to it). But as a relying >> party, if the quality of an attribute I receive is limited by something, I >> probably don't care whether it was because the credential management or the >> assertion transmission was the cause. >> >> So if this retains 4 dimensions, there should be use cases that justify >> the need for 4. I can do that for 2 dimensions (authentication >> strength/attribute reliability) by considering uses like strong >> pseudonymous authentication with a trustable assertion of an attribute like >> age. I don't have any good examples for more than 2. >> >> >> -Jim >> >> >> On 11/11/14 1:34 PM, Nat Sakimura wrote: >> >> We had a bar-bof last night at IETF 91. >> >> There was a discussion that perhaps instead of three dimension "Identity >> Proofing / Credential Binding / Assertion Transmission", perhaps 4 >> dimension "Enrollment/Credential management/Authentication/Assertion >> Transmission" is more appropriate. The reason was that Identity Proofing is >> only a step in Enrollment, Credential Binding is only a step in Credential >> Management, and the use of credential, i.e., Authentication, is important >> enough to separate out from Credential Management. Then, there followed a >> lengthy discussion about whether to pull Authentication out. >> >> As to the "vector" is concerned, it indeed seem to be a vector to me in >> the sense that: >> >> *v* = (e, c, a, t) >> where e:=scalar value for expressing Enrollment quality >> c:=scalar value for expressing Credential Management quality >> a:=scalar value for expressing Authentication quality >> t:=scalar value for expressing Assertion Transmission quality. >> >> There was discussion on how to obtain these values as well. The room >> opinion was that we should define the response format and then use it to >> define the request format. >> >> Also, there was a discussion around the nature of the value of each >> scalar above, and the granularity desired. >> We were not even sure if the values are going to be an ordered set. >> Everybody agreed that simplicity is a requirement for widespread adoption. >> If granularity were sought, then it should be defined as a subset of parent >> value so that implementation that do not care about these can safely ignore >> them. >> >> Apart from the above, importance of the operational quality of IdPs >> were expressed. This seem to be the quality which should be transmitted not >> per authentication transaction but separately, perhaps from .well-known >> resource. >> >> FYI, the room also had the opinion that we should not get into the >> "quality of attributes" in general but focus only to the entity >> authentication, at least for this round. >> >> Cheers, >> >> Nat >> >> >> >> >> On Wed Nov 12 2014 at 5:25:56 Peter Alterman < >> palterman@safe-biopharma.org> wrote: >> >>> Pardon me not diddling with the strawman. A quick read generated the >>> comments following. Hope they are helpful in evolving the document. >>> >>> What is immediately missing is a value for the quality of the >>> credential technology because some credential types are inherently less >>> secure - or risk mitigating - than others. >>> >>> My second observation is that it is not yet clear to me why these >>> elements are called vectors. Vectors are expressions of quantities in >>> spacio-temporal directions. So far I see three (and the fourth I recommend >>> here) factors. In order to consider them vectors, please show me a plot on >>> a graph and label the axes and the measurement units. >>> >>> My third observation is that I do not see any straightforward way for >>> the factors to be collapsed. There are no approaches to do so presented, >>> either. First question to ask here is whether the ecosystem will need to >>> deploy both a transmission protocol and a receiving protocol? If the >>> methodology requires broad uptake of RP software in order to decode the >>> transmitted factors, the Hydra is unleashed. >>> >>> thanks, >>> >>> Peter >>> >>> ------------------------------------------------------------ >>> Peter Alterman, Ph.D. >>> Chief Operating Officer >>> SAFE-BioPharma Association >>> cell: 301-943-7452 >>> >>> >>> On Tue, Nov 11, 2014 at 3:02 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. Document in GitHub (Richer, Justin P.) >>>> >>>> >>>> ---------- Forwarded message ---------- >>>> From: "Richer, Justin P." >>>> To: "vot@ietf.org" >>>> Cc: >>>> Date: Mon, 10 Nov 2014 21:07:53 +0000 >>>> Subject: [VoT] Document in GitHub >>>> I've started the work of translating much of my original strawman >>>> document to Markdown and pushing it to GitHub so that we can start taking >>>> edits via pull request: >>>> >>>> >>>> https://github.com/vectorsoftrust/strawman/blob/master/VectorsOfTrust.md >>>> >>>> Clone and fork away! >>>> >>>> -- Justin >>>> >>>> >>>> _______________________________________________ >>>> 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 listvot@ietf.orghttps://www.ietf.org/mailman/listinfo/vot >> >> >> > _______________________________________________ > vot mailing list > vot@ietf.org > https://www.ietf.org/mailman/listinfo/vot > > --001a11c3daf4841ac405079d5f5b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
>In many cases, people do not care about Identity Proofing.=C2=A0As long as th= e credential management=C2=A0
>and after is done right, it should not matter= in many commercial use case.=C2=A0

An interestin= g perspective Nat.=C2=A0

So the focus of the VoT a= ppears to be about Authentication and Token Assurance and to make it easier= for developers to consume the results (per earlier conversational threads)= .

If that is indeed so, given the work that the Tr= ust Elevation TC at OASIS had done / is doing and the work that FIDO is doi= ng, I am unsure of the value add here.

Regards,

- Anil
=C2=A0
:- Anil John
=
:- Making Digital Services Secure and Trustworthy


On Tue, Nov 11, 2014 at 5:28 PM, Nat Sakimur= a <sakimura@gmail.com> wrote:
In many c= ases, people do not care about Identity Proofing. As long as the credential= management and after is done right, it should not matter in many commercia= l use case. So, in the previous expression, to some of my use cases, I am i= ndifferent with (1, 2, 2, 2) and (4, 2, 2, 2). In the traditional SP800-63 = case, however, the former is 0 and later is 2, making (1, 2, 2, 2) and (1, = 1, 1, 1) indifferent, losing the information I was interested in. Also, I m= ay want to accept (1,2,2,1) on a intranet while I am only willing to accept= (1,2,2,2) over the internet. Justin was arguing to collapse the middle two= , and that may well be a good simplification. In this case, I still care th= ose three dimensions instead of four.=C2=A0

As to th= e attribute reliability is concerned, the room concluded that it is out of = scope for VoT for now, that we should only concentrate on entity authentica= tion assurance. The quality of attribute should be treated more like a meta= data about each attribute instead.=C2=A0

For the= =C2=A0Enrollment, Credential= Management, Authentication, refer to ISO/IEC 29115 or ITU-T X.1254, which = are almost identical apart from the formatting and 3 words. X.1254 is freel= y available. You can find them here:=C2=A0https://www.itu.int/re= c/T-REC-X.1254-201209-I/en

Nat

On Wed Nov 12 2014 at 6:53:11 Jim Fenton <<= a href=3D"mailto:fenton@bluepopcorn.net" target=3D"_blank">fenton@bluepopco= rn.net> wrote:
=20 =20 =20
One of the requirements should be that there be only as many dimensions to the vector as would be actionable by a Relying Party to make an authorization decision. Otherwise, the model is more complex than it needs to be.

I'm not sure I understand how Enrollment, Credential Management, Authentication, and Assertion Transmission are defined (if that was discussed on the list, I'd appreciate a pointer to it). But a= s a relying party, if the quality of an attribute I receive is limited by something, I probably don't care whether it was becaus= e the credential management or the assertion transmission was the cause.

So if this retains 4 dimensions, there should be use cases that justify the need for 4. I can do that for 2 dimensions (authentication strength/attribute reliability) by considering uses like strong pseudonymous authentication with a trustable assertion of an attribute like age. I don't have any good example= s for more than 2.


-Jim


On 11/11/14 1:34 PM, Nat Sakimura wrote:
We had a bar-bof last night at IETF 91.=C2=A0=

There was a discussion that perhaps instead of three dimension "Identity Proofing / Credential Binding / Assertion Transmission", perhaps 4 dimension "Enrollment/Credential management/Authentication/Assertion Transmission" is more appropriate. The reason was that Identity Proofing is only a step in Enrollment, Credential Binding is only a step in Credential Management, and the use of credential, i.e., Authentication, is important enough to separate out from Credential Management. Then, there followed a lengthy discussion about whether to pull Authentication out.=C2=A0

As to the "vector" is concerned, it indeed seem to be = a vector to me in the sense that:=C2=A0

v =3D (e, c, a, t)=C2=A0
=C2=A0where e:=3Dscalar value for expressing Enrollment quality<= /div>
=C2=A0c:=3Dscalar value for expressing Credential Management qua= lity
=C2=A0a:=3Dscalar value for expressing Authentication quality
=C2=A0t:=3Dscalar value for expressing Assertion Transmission quality.=C2=A0

There was discussion on how to obtain these values as well. The room opinion was that we should define the response format and then use it to define the request format.=C2=A0

Also, there was a discussion around the nature of the value of each scalar above, and the granularity desired.=C2=A0
We were not even sure if the values are going to be an ordered set. Everybody agreed that simplicity is a requirement for widespread adoption. If granularity were sought, then it should be defined as a subset of parent value so that implementation that do not care about these can safely ignore them.=C2=A0

Apart from the above, importance of the operational quality of IdPs were expressed. This seem to be the quality which should be transmitted not per authentication transaction but separately, perhaps from .well-known resource.=C2=A0

FYI, the room also had the opinion that we should not get into the "quality of attributes" in general but focus onl= y to the entity authentication, at least for this round.=C2=A0

Cheers,=C2=A0

Nat




On Wed Nov 12 2014 at 5:25:56 Peter Alterman <palterman@safe-biopharma.org> wrote:
Pardon me not diddling with the strawman. A quick read generated the comments following. Hope they are helpful in evolving the document.

What is immediately missing is a value for the quality of the credential technology because some credential types are inherently less secure - or risk mitigating - than others.=C2=A0

My second observation is that it is not yet clear to me why these elements are called vectors. Vectors are expressions of quantities in spacio-temporal directions. So far I see three (and the fourth I recommend here) factors. In order to consider them vectors, please show me a plot on a graph and label the axes and the measurement units.

My third observation is that I do not see any straightforward way for the factors to be collapsed. There are no approaches to do so presented, either. First question to ask here is whether the ecosystem will need to deploy both a transmission protocol and a receiving protocol? If the methodology requires broad uptake of RP software in order to decode the transmitted factors, the Hydra is unleashed.

thanks,

Peter

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


On Tue, Nov 11, 2014 at 3:02 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/listi= nfo/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. Document in GitHub (Richer, Justin P.)


---------- Forwarded message ----------
From:=C2=A0"Richer, Justin P." <jricher@mitre.org>
To:=C2=A0"vot@ietf.org" <vot@i= etf.org>
Cc:=C2=A0
Date:=C2=A0Mon, 10 Nov 2014 21:07:53 +0000
Subject:=C2=A0[VoT] Document in GitHub
I've started the work of translating much of my origina= l strawman document to Markdown and pushing it to GitHub so that we can start taking edits via pull request:

=C2=A0 https://github.com/vecto= rsoftrust/strawman/blob/master/VectorsOfTrust.md

Clone and fork away!

=C2=A0-- Justin


_______________________________________________
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
htt=
ps://www.ietf.org/mailman/listinfo/vot


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


--001a11c3daf4841ac405079d5f5b-- From nobody Tue Nov 11 15:51:01 2014 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 77E911A6FE2 for ; Tue, 11 Nov 2014 15:50:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.365 X-Spam-Level: X-Spam-Status: No, score=-1.365 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.594, SPF_NEUTRAL=0.779] 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 XCE2FkMnBW9Q for ; Tue, 11 Nov 2014 15:50:54 -0800 (PST) Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [IPv6:2001:6b0:8:2::201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16E141A6FD2 for ; Tue, 11 Nov 2014 15:50:53 -0800 (PST) Received: from smtp1.sunet.se (smtp1.sunet.se [IPv6:2001:6b0:8:2::214]) by e-mailfilter01.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id sABNoqUO030741 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 12 Nov 2014 00:50:52 +0100 Received: from kerio.sunet.se (kerio.sunet.se [192.36.171.210]) by smtp1.sunet.se (8.14.7/8.14.7) with ESMTP id sABNonv8009600 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 12 Nov 2014 00:50:52 +0100 (CET) X-Footer: c3VuZXQuc2U= Received: from [31.133.167.69] ([31.133.167.69]) (authenticated user leifj@sunet.se) by kerio.sunet.se (Kerio Connect 8.3.4 patch 1) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256 bits)) for vot@ietf.org; Wed, 12 Nov 2014 00:50:48 +0100 Message-ID: <5462A0D6.2000708@sunet.se> Date: Wed, 12 Nov 2014 00:50:46 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: vot@ietf.org References: <54628544.8040801@bluepopcorn.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, outbound-sunet-se:default, sunet-se:default, base:default, @@RPTN) X-CanIt-Geo: ip=192.36.171.210; country=SE; latitude=62.0000; longitude=15.0000; http://maps.google.com/maps?q=62.0000,15.0000&z=6 X-CanItPRO-Stream: outbound-sunet-se:outbound (inherits from outbound-sunet-se:default, sunet-se:default, base:default) X-Canit-Stats-ID: 09NenOQ8T - 0eecc66ee02b - 20141112 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw X-Scanned-By: CanIt (www . roaringpenguin . com) Archived-At: http://mailarchive.ietf.org/arch/msg/vot/DLEqTLMeWbjUyoFaDZUFHUTvajc Subject: Re: [VoT] vot Digest, Vol 3, Issue 3 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, 11 Nov 2014 23:50:58 -0000 On 2014-11-12 00:08, Anil John wrote: >>In many cases, people do not care about Identity Proofing. As long as > the credential management >>and after is done right, it should not matter in many commercial use case. > > An interesting perspective Nat. > > So the focus of the VoT appears to be about Authentication and Token > Assurance and to make it easier for developers to consume the results > (per earlier conversational threads). > > If that is indeed so, given the work that the Trust Elevation TC at > OASIS had done / is doing and the work that FIDO is doing, I am unsure > of the value add here. > No that is an oversimplification. From nobody Tue Nov 11 16:01:46 2014 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 2A5701A702D for ; Tue, 11 Nov 2014 16:01:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.594 X-Spam-Level: X-Spam-Status: No, score=-2.594 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, RP_MATCHES_RCVD=-0.594, 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 XM_hyOPJSTrY for ; Tue, 11 Nov 2014 16:01:38 -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 72A851A802C for ; Tue, 11 Nov 2014 16:01:38 -0800 (PST) Received: from unknownb8e856c21d75.att.net ([IPv6:2602:306:bd69:6ce0:e4c0:ec3f:5a3a:bde9]) (authenticated bits=0) by v2.bluepopcorn.net (8.14.3/8.14.3/Debian-9.4) with ESMTP id sAC01WIg014794 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 11 Nov 2014 16:01:34 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1415750495; bh=DHJy6eu08myvrgNBsZryfWv9ahy6jGHu0nI8eG+I5Kk=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=dRw2977tcZNQwU/0deoCB6hrOBZdYR2BrBfXXlUhMZDjW4I/lc58MOapvnfBiTK7/ FJn4AghAKd2EOsuiz49w463Ra+MHeHoKW2pFt/75Iq7LDjFONozjggyoCzmmX0PR5P BdesYCZOIGxwWSLD1OaXx9w//vJlHE/ai0KnT4PE= Message-ID: <5462A357.6060707@bluepopcorn.net> Date: Tue, 11 Nov 2014 16:01:27 -0800 From: Jim Fenton User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Peter Alterman , Nat Sakimura References: <54628544.8040801@bluepopcorn.net> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010108020408070501090004" Archived-At: http://mailarchive.ietf.org/arch/msg/vot/_u4RoKU6x4agyETAosVY30QN9tY Cc: vot@ietf.org Subject: Re: [VoT] vot Digest, Vol 3, Issue 3 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, 12 Nov 2014 00:01:43 -0000 This is a multi-part message in MIME format. --------------010108020408070501090004 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Peter, My point in suggesting use cases is that I have a sense that the model is already too complex. Maybe an analyst can turn the crank and come up with use cases that utilize all four of these factors independently, but if they're too obscure that tells us something too. I'm not clear on what you mean about extended attributes. When you talk about identity proofing, you're already talking about establishing a binding between an attribute (e.g., name) and an authentication token. Finally, it sounds like we're talking past each other on the word "vector". We're using the word in the mathematical sense, and it appears you're using it in the epidemiological sense. If there's a word here I have a quibble about, it's "trust". Nat, In using the word "reliability" I intentionally avoided the word "quality". I would include identity proofing as one aspect of attribute reliability, and since that's part of enrollment (per 29115) that must not be out of scope. -Jim On 11/11/14 3:09 PM, Peter Alterman wrote: > Nat et. al. > > Let's not reason backwards from use cases but forwards from expertise. > There are a zillion use cases out there that can be generated for any > model (sort of like a cost/benefit analysis - just tell the analyst > what answer you want and let him/her crank out the sausage). Rather, > what are the legitimate components of an identity assertion; what's > the nature of the relationship among them? Nothing I've seen so far > changes my opinion that there are four variables: strength of identity > proofing (measured against a benchmark that incorporates *both* 800-63 > and 29115); intrinsic resistance of credential type to attack (see > prior benchmarking comment); credential management (how well it > addresses the threat vectors in 29115 and aligns with 800-63 > processes, and exchange, which incorporates mitigation of data in > motion threat vectors listed in 29115 relevant to AuthN.=20 > > I fear there is a fair amount of rat hole diving in process, and I'm > urging a pragmatic eye here. Strongly support putting off any > discussion of extended attributes until this particular effort has > been completed. No further work on attributes should go forward > without benchmarking the myriad efforts in that arena in the past 3 > years so we don't reinvent any wheels or redefine the meaning of > "round." Also agree that the AuthN process is not part of determining > the trustworthiness (rat hole warning) of an online identity assertion > but the process of making such a determination. > > Finally, scalar is not vector. C'mon guys, give an old man a break. > We're talking factors, not vectors. As an example, a threat vector is > an identity assertion threat aimed at someone or some process: it has > strength and it has direction. > > regards, > > Peter > > > ------------------------------------------------------------ > Peter Alterman, Ph.D. > Chief Operating Officer > SAFE-BioPharma Association > cell: 301-943-7452 > > > On Tue, Nov 11, 2014 at 5:28 PM, Nat Sakimura > wrote: > > In many cases, people do not care about Identity Proofing. As long > as the credential management and after is done right, it should > not matter in many commercial use case. So, in the previous > expression, to some of my use cases, I am indifferent with (1, 2, > 2, 2) and (4, 2, 2, 2). In the traditional SP800-63 case, however, > the former is 0 and later is 2, making (1, 2, 2, 2) and (1, 1, 1, > 1) indifferent, losing the information I was interested in. Also, > I may want to accept (1,2,2,1) on a intranet while I am only > willing to accept (1,2,2,2) over the internet. Justin was arguing > to collapse the middle two, and that may well be a good > simplification. In this case, I still care those three dimensions > instead of four.=20 > > As to the attribute reliability is concerned, the room concluded > that it is out of scope for VoT for now, that we should only > concentrate on entity authentication assurance. The quality of > attribute should be treated more like a metadata about each > attribute instead.=20 > > For the Enrollment, Credential Management, Authentication, refer > to ISO/IEC 29115 or ITU-T X.1254, which are almost identical apart > from the formatting and 3 words. X.1254 is freely available. You > can find them here: https://www.itu.int/rec/T-REC-X.1254-201209-I/e= n > > Nat > > > On Wed Nov 12 2014 at 6:53:11 Jim Fenton > wrote: > > One of the requirements should be that there be only as many > dimensions to the vector as would be actionable by a Relying > Party to make an authorization decision. Otherwise, the model > is more complex than it needs to be. > > I'm not sure I understand how Enrollment, Credential > Management, Authentication, and Assertion Transmission are > defined (if that was discussed on the list, I'd appreciate a > pointer to it). But as a relying party, if the quality of an > attribute I receive is limited by something, I probably don't > care whether it was because the credential management or the > assertion transmission was the cause. > > So if this retains 4 dimensions, there should be use cases > that justify the need for 4. I can do that for 2 dimensions > (authentication strength/attribute reliability) by considering > uses like strong pseudonymous authentication with a trustable > assertion of an attribute like age. I don't have any good > examples for more than 2. > > > -Jim > > > On 11/11/14 1:34 PM, Nat Sakimura wrote: >> We had a bar-bof last night at IETF 91.=20 >> >> There was a discussion that perhaps instead of three >> dimension "Identity Proofing / Credential Binding / Assertion >> Transmission", perhaps 4 dimension "Enrollment/Credential >> management/Authentication/Assertion Transmission" is more >> appropriate. The reason was that Identity Proofing is only a >> step in Enrollment, Credential Binding is only a step in >> Credential Management, and the use of credential, i.e., >> Authentication, is important enough to separate out from >> Credential Management. Then, there followed a lengthy >> discussion about whether to pull Authentication out.=20 >> >> As to the "vector" is concerned, it indeed seem to be a >> vector to me in the sense that:=20 >> >> *v* =3D (e, c, a, t)=20 >> where e:=3Dscalar value for expressing Enrollment quality >> c:=3Dscalar value for expressing Credential Management qualit= y >> a:=3Dscalar value for expressing Authentication quality >> t:=3Dscalar value for expressing Assertion Transmission quali= ty.=20 >> >> There was discussion on how to obtain these values as well. >> The room opinion was that we should define the response >> format and then use it to define the request format.=20 >> >> Also, there was a discussion around the nature of the value >> of each scalar above, and the granularity desired.=20 >> We were not even sure if the values are going to be an >> ordered set. Everybody agreed that simplicity is a >> requirement for widespread adoption. If granularity were >> sought, then it should be defined as a subset of parent value >> so that implementation that do not care about these can >> safely ignore them.=20 >> >> Apart from the above, importance of the operational quality >> of IdPs were expressed. This seem to be the quality which >> should be transmitted not per authentication transaction but >> separately, perhaps from .well-known resource.=20 >> >> FYI, the room also had the opinion that we should not get >> into the "quality of attributes" in general but focus only to >> the entity authentication, at least for this round.=20 >> >> Cheers,=20 >> >> Nat >> >> >> >> >> On Wed Nov 12 2014 at 5:25:56 Peter Alterman >> > > wrote: >> >> Pardon me not diddling with the strawman. A quick read >> generated the comments following. Hope they are helpful >> in evolving the document. >> >> What is immediately missing is a value for the quality of >> the credential technology because some credential types >> are inherently less secure - or risk mitigating - than >> others.=20 >> >> My second observation is that it is not yet clear to me >> why these elements are called vectors. Vectors are >> expressions of quantities in spacio-temporal directions. >> So far I see three (and the fourth I recommend here) >> factors. In order to consider them vectors, please show >> me a plot on a graph and label the axes and the >> measurement units. >> >> My third observation is that I do not see any >> straightforward way for the factors to be collapsed. >> There are no approaches to do so presented, either. First >> question to ask here is whether the ecosystem will need >> to deploy both a transmission protocol and a receiving >> protocol? If the methodology requires broad uptake of RP >> software in order to decode the transmitted factors, the >> Hydra is unleashed. >> >> thanks, >> >> Peter >> >> ----------------------------------------------------------= -- >> Peter Alterman, Ph.D. >> Chief Operating Officer >> SAFE-BioPharma Association >> cell: 301-943-7452 >> >> >> On Tue, Nov 11, 2014 at 3:02 PM, > > wrote: >> >> Send vot mailing list submissions to >> vot@ietf.org >> >> To subscribe or unsubscribe via the World Wide Web, vi= sit >> 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. Document in GitHub (Richer, Justin P.) >> >> >> ---------- Forwarded message ---------- >> From: "Richer, Justin P." > > >> To: "vot@ietf.org " >> > >> Cc:=20 >> Date: Mon, 10 Nov 2014 21:07:53 +0000 >> Subject: [VoT] Document in GitHub >> I've started the work of translating much of my >> original strawman document to Markdown and pushing it >> to GitHub so that we can start taking edits via pull >> request: >> >> =20 >> https://github.com/vectorsoftrust/strawman/blob/master= /VectorsOfTrust.md >> >> Clone and fork away! >> >> -- Justin >> >> >> _______________________________________________ >> 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 --------------010108020408070501090004 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Peter,

My point in suggesting use cases is that I have a sense that the model is already too complex. Maybe an analyst can turn the crank and come up with use cases that utilize all four of these factors independently, but if they're too obscure that tells us something too.

I'm not clear on what you mean about extended attributes. When you talk about identity proofing, you're already talking about establishing a binding between an attribute (e.g., name) and an authentication token.

Finally, it sounds like we're talking past each other on the word "vector". We're using the word in the mathematical sense, and it appears you're using it in the epidemiological sense. If there's a word here I have a quibble about, it's "trust".

Nat,

In using the word "reliability" I intentionally avoided the word "quality". I would include identity proofing as one aspect of attribute reliability, and since that's part of enrollment (per 29115) that must not be out of scope.

-Jim

On 11/11/14 3:09 PM, Peter Alterman wrote:
Nat et. al.

Let's not reason backwards from use cases but forwards from expertise. There are a zillion use cases out there that can be generated for any model (sort of like a cost/benefit analysis - just tell the analyst what answer you want and let him/her crank out the sausage). Rather, what are the legitimate components of an identity assertion; what's the nature of the relationship among them? Nothing I've seen so far changes my opinion that there are four variables: strength of identity proofing (measured against a benchmark that incorporates *both* 800-63 and 29115); intrinsic resistance of credential type to attack (see prior benchmarking comment); credential management (how well it addresses the threat vectors in 29115 and aligns with 800-63 processes, and exchange, which incorporates mitigation of data in motion threat vectors listed in 29115 relevant to AuthN. 

I fear there is a fair amount of rat hole diving in process, and I'm urging a pragmatic eye here. Strongly support putting off any discussion of extended attributes until this particular effort has been completed. No further work on attributes should go forward without benchmarking the myriad efforts in that arena in the past 3 years so we don't reinvent any wheels or redefine the meaning of "round." Also agree that the AuthN process is not part of determining the trustworthiness (rat hole warning) of an online identity assertion but the process of making such a determination.

Finally, scalar is not vector. C'mon guys, give an old man a break. We're talking factors, not vectors. As an example, a threat vector is an identity assertion threat aimed at someone or some process: it has strength and it has direction.

regards,

Peter


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


On Tue, Nov 11, 2014 at 5:28 PM, Nat Sakimura <sakimura@gmail.com> wrote:
In many cases, people do not care about Identity Proofing. As long as the credential management and after is done right, it should not matter in many commercial use case. So, in the previous expression, to some of my use cases, I am indifferent with (1, 2, 2, 2) and (4, 2, 2, 2). In the traditional SP800-63 case, however, the former is 0 and later is 2, making (1, 2, 2, 2) and (1, 1, 1, 1) indifferent, losing the information I was interested in. Also, I may want to accept (1,2,2,1) on a intranet while I am only willing to accept (1,2,2,2) over the internet. Justin was arguing to collapse the middle two, and that may well be a good simplification. In this case, I still care those three dimensions instead of four. 

As to the attribute reliability is concerned, the room concluded that it is out of scope for VoT for now, that we should only concentrate on entity authentication assurance. The quality of attribute should be treated more like a metadata about each attribute instead. 

For the Enrollment, Credential Management, Authentication, refer to ISO/IEC 29115 or ITU-T X.1254, which are almost identical apart from the formatting and 3 words. X.1254 is freely available. You can find them here: https://www.itu.int/rec/T-REC-X.1254-201209-I/en

Nat


On Wed Nov 12 2014 at 6:53:11 Jim Fenton <fenton@bluepopcorn.net> wrote:
One of the requirements should be that there be only as many dimensions to the vector as would be actionable by a Relying Party to make an authorization decision. Otherwise, the model is more complex than it needs to be.

I'm not sure I understand how Enrollment, Credential Management, Authentication, and Assertion Transmission are defined (if that was discussed on the list, I'd appreciate a pointer to it). But as a relying party, if the quality of an attribute I receive is limited by something, I probably don't care whether it was because the credential management or the assertion transmission was the cause.

So if this retains 4 dimensions, there should be use cases that justify the need for 4. I can do that for 2 dimensions (authentication strength/attribute reliability) by considering uses like strong pseudonymous authentication with a trustable assertion of an attribute like age. I don't have any good examples for more than 2.


-Jim


On 11/11/14 1:34 PM, Nat Sakimura wrote:
We had a bar-bof last night at IETF 91. 

There was a discussion that perhaps instead of three dimension "Identity Proofing / Credential Binding / Assertion Transmission", perhaps 4 dimension "Enrollment/Credential management/Authentication/Assertion Transmission" is more appropriate. The reason was that Identity Proofing is only a step in Enrollment, Credential Binding is only a step in Credential Management, and the use of credential, i.e., Authentication, is important enough to separate out from Credential Management. Then, there followed a lengthy discussion about whether to pull Authentication out. 

As to the "vector" is concerned, it indeed seem to be a vector to me in the sense that: 

v = (e, c, a, t) 
 where e:=scalar value for expressing Enrollment quality
 c:=scalar value for expressing Credential Management quality
 a:=scalar value for expressing Authentication quality
 t:=scalar value for expressing Assertion Transmission quality. 

There was discussion on how to obtain these values as well. The room opinion was that we should define the response format and then use it to define the request format. 

Also, there was a discussion around the nature of the value of each scalar above, and the granularity desired. 
We were not even sure if the values are going to be an ordered set. Everybody agreed that simplicity is a requirement for widespread adoption. If granularity were sought, then it should be defined as a subset of parent value so that implementation that do not care about these can safely ignore them. 

Apart from the above, importance of the operational quality of IdPs were expressed. This seem to be the quality which should be transmitted not per authentication transaction but separately, perhaps from .well-known resource. 

FYI, the room also had the opinion that we should not get into the "quality of attributes" in general but focus only to the entity authentication, at least for this round. 

Cheers, 

Nat




On Wed Nov 12 2014 at 5:25:56 Peter Alterman <palterman@safe-biopharma.org> wrote:
Pardon me not diddling with the strawman. A quick read generated the comments following. Hope they are helpful in evolving the document.

What is immediately missing is a value for the quality of the credential technology because some credential types are inherently less secure - or risk mitigating - than others. 

My second observation is that it is not yet clear to me why these elements are called vectors. Vectors are expressions of quantities in spacio-temporal directions. So far I see three (and the fourth I recommend here) factors. In order to consider them vectors, please show me a plot on a graph and label the axes and the measurement units.

My third observation is that I do not see any straightforward way for the factors to be collapsed. There are no approaches to do so presented, either. First question to ask here is whether the ecosystem will need to deploy both a transmission protocol and a receiving protocol? If the methodology requires broad uptake of RP software in order to decode the transmitted factors, the Hydra is unleashed.

thanks,

Peter

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


On Tue, Nov 11, 2014 at 3:02 PM, <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. Document in GitHub (Richer, Justin P.)


---------- Forwarded message ----------
From: "Richer, Justin P." <jricher@mitre.org>
To: "vot@ietf.org" <vot@ietf.org>
Cc: 
Date: Mon, 10 Nov 2014 21:07:53 +0000
Subject: [VoT] Document in GitHub
I've started the work of translating much of my original strawman document to Markdown and pushing it to GitHub so that we can start taking edits via pull request:

  https://github.com/vectorsoftrust/strawman/blob/master/VectorsOfTrust.md

Clone and fork away!

 -- Justin


_______________________________________________
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

--------------010108020408070501090004-- From nobody Tue Nov 11 19:50:16 2014 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 2C97E1ACD8F for ; Tue, 11 Nov 2014 19:50:15 -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 JMN5m7aj0KbY for ; Tue, 11 Nov 2014 19:50:10 -0800 (PST) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 952C81ACD8D for ; Tue, 11 Nov 2014 19:50:09 -0800 (PST) Received: by mail-ig0-f172.google.com with SMTP id a13so2262929igq.5 for ; Tue, 11 Nov 2014 19:50:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:from:date:message-id:subject:to:cc :content-type; bh=im+9uSd7lvGFfCnKwnRnAGHOSMB6MWwi9XhTvA67QAk=; b=U9Eut078qCcgx0w4uIhecS8xiIoWpi0azt83K+sa07/F6O1KwIKjLfteftklzo22dK YPk166tJJUrZYBW/4dLrz6AfzdAInbX+SWfBtEE7NruC9yNS7C1LeqmwpCEx9w1gGHwX P01QgJQRu/jdgYXaG+wReUuGVc+00SI2klcsD1nWlAuMtt+31gQ2SHz9IWaPWvt8U1NB NcI6Hm5PCe145s6QYPygbdjSUDGfbR/ZbmEUMyaN2ChipLf1DjKuUv1/p3yVepsMxsUV VGNIiYyJI/9Zyb28P/jPbg55SPeFljvQRaour55/fc88BVTTNQz+3EDTSTdHvQEW6PS2 8N0w== X-Received: by 10.50.30.132 with SMTP id s4mr36666511igh.24.1415764208658; Tue, 11 Nov 2014 19:50:08 -0800 (PST) MIME-Version: 1.0 References: <54628544.8040801@bluepopcorn.net> <5462A357.6060707@bluepopcorn.net> From: Nat Sakimura Date: Wed, 12 Nov 2014 03:50:08 +0000 Message-ID: To: Jim Fenton , Peter Alterman Content-Type: multipart/alternative; boundary=047d7bdc1268be450c0507a14ae2 Archived-At: http://mailarchive.ietf.org/arch/msg/vot/boG-YIUawJJxFavOU8XH477szF4 Cc: vot@ietf.org Subject: Re: [VoT] vot Digest, Vol 3, Issue 3 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, 12 Nov 2014 03:50:15 -0000 --047d7bdc1268be450c0507a14ae2 Content-Type: text/plain; charset=UTF-8 Hi Jim, The scope of attribute assurance/reliability/quality that is needed for particular purpose identity proofing is fairly limited compared to the case of general purpose attribute proofing. Specifically, it would be policy bound for the purpose of identity proofing. The set of attributes needed to be verified/validated will be different from one case to another, and that's where policy comes in. Many people believe that identity proofing is about checking the name, dob, etc., but that is just one specific case. In general, identity proofing is nothing but corroborating the presented attribute value against the master database. In government use case, it happens to be name, dob, etc, since that is acting as a part of identifier. Suppose a case where the master database was set up around the retina patter on the person who paid for the service. Then, asking name, dob, etc. has no significance. In this case, the identity proofing is checking the person's retina pattern against the data stored in the database, perhaps after templating. Cheers, Nat On Wed Nov 12 2014 at 9:01:36 Jim Fenton wrote: > Peter, > > My point in suggesting use cases is that I have a sense that the model is > already too complex. Maybe an analyst can turn the crank and come up with > use cases that utilize all four of these factors independently, but if > they're too obscure that tells us something too. > > I'm not clear on what you mean about extended attributes. When you talk > about identity proofing, you're already talking about establishing a > binding between an attribute (e.g., name) and an authentication token. > > Finally, it sounds like we're talking past each other on the word > "vector". We're using the word in the mathematical sense, and it appears > you're using it in the epidemiological sense. If there's a word here I have > a quibble about, it's "trust". > > Nat, > > In using the word "reliability" I intentionally avoided the word > "quality". I would include identity proofing as one aspect of attribute > reliability, and since that's part of enrollment (per 29115) that must not > be out of scope. > > > -Jim > > > On 11/11/14 3:09 PM, Peter Alterman wrote: > > Nat et. al. > > Let's not reason backwards from use cases but forwards from expertise. > There are a zillion use cases out there that can be generated for any model > (sort of like a cost/benefit analysis - just tell the analyst what answer > you want and let him/her crank out the sausage). Rather, what are the > legitimate components of an identity assertion; what's the nature of the > relationship among them? Nothing I've seen so far changes my opinion that > there are four variables: strength of identity proofing (measured against a > benchmark that incorporates *both* 800-63 and 29115); intrinsic resistance > of credential type to attack (see prior benchmarking comment); credential > management (how well it addresses the threat vectors in 29115 and aligns > with 800-63 processes, and exchange, which incorporates mitigation of data > in motion threat vectors listed in 29115 relevant to AuthN. > > I fear there is a fair amount of rat hole diving in process, and I'm > urging a pragmatic eye here. Strongly support putting off any discussion of > extended attributes until this particular effort has been completed. No > further work on attributes should go forward without benchmarking the > myriad efforts in that arena in the past 3 years so we don't reinvent any > wheels or redefine the meaning of "round." Also agree that the AuthN > process is not part of determining the trustworthiness (rat hole warning) > of an online identity assertion but the process of making such a > determination. > > Finally, scalar is not vector. C'mon guys, give an old man a break. > We're talking factors, not vectors. As an example, a threat vector is an > identity assertion threat aimed at someone or some process: it has strength > and it has direction. > > regards, > > Peter > > > ------------------------------------------------------------ > Peter Alterman, Ph.D. > Chief Operating Officer > SAFE-BioPharma Association > cell: 301-943-7452 > > > On Tue, Nov 11, 2014 at 5:28 PM, Nat Sakimura wrote: > >> In many cases, people do not care about Identity Proofing. As long as the >> credential management and after is done right, it should not matter in many >> commercial use case. So, in the previous expression, to some of my use >> cases, I am indifferent with (1, 2, 2, 2) and (4, 2, 2, 2). In the >> traditional SP800-63 case, however, the former is 0 and later is 2, making >> (1, 2, 2, 2) and (1, 1, 1, 1) indifferent, losing the information I was >> interested in. Also, I may want to accept (1,2,2,1) on a intranet while I >> am only willing to accept (1,2,2,2) over the internet. Justin was arguing >> to collapse the middle two, and that may well be a good simplification. In >> this case, I still care those three dimensions instead of four. >> >> As to the attribute reliability is concerned, the room concluded that >> it is out of scope for VoT for now, that we should only concentrate on >> entity authentication assurance. The quality of attribute should be treated >> more like a metadata about each attribute instead. >> >> For the Enrollment, Credential Management, Authentication, refer to >> ISO/IEC 29115 or ITU-T X.1254, which are almost identical apart from the >> formatting and 3 words. X.1254 is freely available. You can find them here: >> https://www.itu.int/rec/T-REC-X.1254-201209-I/en >> >> Nat >> >> >> On Wed Nov 12 2014 at 6:53:11 Jim Fenton wrote: >> >>> One of the requirements should be that there be only as many >>> dimensions to the vector as would be actionable by a Relying Party to make >>> an authorization decision. Otherwise, the model is more complex than it >>> needs to be. >>> >>> I'm not sure I understand how Enrollment, Credential Management, >>> Authentication, and Assertion Transmission are defined (if that was >>> discussed on the list, I'd appreciate a pointer to it). But as a relying >>> party, if the quality of an attribute I receive is limited by something, I >>> probably don't care whether it was because the credential management or the >>> assertion transmission was the cause. >>> >>> So if this retains 4 dimensions, there should be use cases that justify >>> the need for 4. I can do that for 2 dimensions (authentication >>> strength/attribute reliability) by considering uses like strong >>> pseudonymous authentication with a trustable assertion of an attribute like >>> age. I don't have any good examples for more than 2. >>> >>> >>> -Jim >>> >>> >>> On 11/11/14 1:34 PM, Nat Sakimura wrote: >>> >>> We had a bar-bof last night at IETF 91. >>> >>> There was a discussion that perhaps instead of three dimension "Identity >>> Proofing / Credential Binding / Assertion Transmission", perhaps 4 >>> dimension "Enrollment/Credential management/Authentication/Assertion >>> Transmission" is more appropriate. The reason was that Identity Proofing is >>> only a step in Enrollment, Credential Binding is only a step in Credential >>> Management, and the use of credential, i.e., Authentication, is important >>> enough to separate out from Credential Management. Then, there followed a >>> lengthy discussion about whether to pull Authentication out. >>> >>> As to the "vector" is concerned, it indeed seem to be a vector to me >>> in the sense that: >>> >>> *v* = (e, c, a, t) >>> where e:=scalar value for expressing Enrollment quality >>> c:=scalar value for expressing Credential Management quality >>> a:=scalar value for expressing Authentication quality >>> t:=scalar value for expressing Assertion Transmission quality. >>> >>> There was discussion on how to obtain these values as well. The room >>> opinion was that we should define the response format and then use it to >>> define the request format. >>> >>> Also, there was a discussion around the nature of the value of each >>> scalar above, and the granularity desired. >>> We were not even sure if the values are going to be an ordered set. >>> Everybody agreed that simplicity is a requirement for widespread adoption. >>> If granularity were sought, then it should be defined as a subset of parent >>> value so that implementation that do not care about these can safely ignore >>> them. >>> >>> Apart from the above, importance of the operational quality of IdPs >>> were expressed. This seem to be the quality which should be transmitted not >>> per authentication transaction but separately, perhaps from .well-known >>> resource. >>> >>> FYI, the room also had the opinion that we should not get into the >>> "quality of attributes" in general but focus only to the entity >>> authentication, at least for this round. >>> >>> Cheers, >>> >>> Nat >>> >>> >>> >>> >>> On Wed Nov 12 2014 at 5:25:56 Peter Alterman < >>> palterman@safe-biopharma.org> wrote: >>> >>>> Pardon me not diddling with the strawman. A quick read generated the >>>> comments following. Hope they are helpful in evolving the document. >>>> >>>> What is immediately missing is a value for the quality of the >>>> credential technology because some credential types are inherently less >>>> secure - or risk mitigating - than others. >>>> >>>> My second observation is that it is not yet clear to me why these >>>> elements are called vectors. Vectors are expressions of quantities in >>>> spacio-temporal directions. So far I see three (and the fourth I recommend >>>> here) factors. In order to consider them vectors, please show me a plot on >>>> a graph and label the axes and the measurement units. >>>> >>>> My third observation is that I do not see any straightforward way for >>>> the factors to be collapsed. There are no approaches to do so presented, >>>> either. First question to ask here is whether the ecosystem will need to >>>> deploy both a transmission protocol and a receiving protocol? If the >>>> methodology requires broad uptake of RP software in order to decode the >>>> transmitted factors, the Hydra is unleashed. >>>> >>>> thanks, >>>> >>>> Peter >>>> >>>> ------------------------------------------------------------ >>>> Peter Alterman, Ph.D. >>>> Chief Operating Officer >>>> SAFE-BioPharma Association >>>> cell: 301-943-7452 >>>> >>>> >>>> On Tue, Nov 11, 2014 at 3:02 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. Document in GitHub (Richer, Justin P.) >>>>> >>>>> >>>>> ---------- Forwarded message ---------- >>>>> From: "Richer, Justin P." >>>>> To: "vot@ietf.org" >>>>> Cc: >>>>> Date: Mon, 10 Nov 2014 21:07:53 +0000 >>>>> Subject: [VoT] Document in GitHub >>>>> I've started the work of translating much of my original strawman >>>>> document to Markdown and pushing it to GitHub so that we can start taking >>>>> edits via pull request: >>>>> >>>>> >>>>> https://github.com/vectorsoftrust/strawman/blob/master/VectorsOfTrust.md >>>>> >>>>> Clone and fork away! >>>>> >>>>> -- Justin >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 listvot@ietf.orghttps://www.ietf.org/mailman/listinfo/vot >>> >>> >>> > > > _______________________________________________ > vot mailing listvot@ietf.orghttps://www.ietf.org/mailman/listinfo/vot > > > --047d7bdc1268be450c0507a14ae2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Jim,=C2=A0

The scope of attribute assurance/reliability/quality t= hat is needed for particular purpose identity proofing is fairly limited co= mpared to the case of general purpose attribute proofing. Specifically, it = would be policy bound for the purpose of identity proofing. The set of attr= ibutes needed to be verified/validated will be different from one case to a= nother, and that's where policy comes in. Many people believe that iden= tity proofing is about checking the name, dob, etc., but that is just one s= pecific case. In general, identity proofing is nothing but corroborating th= e presented attribute value against the master database. In government use = case, it happens to be name, dob, etc, since that is acting as a part of id= entifier. Suppose a case where the master database was set up around the re= tina patter on the person who paid for the service. Then, asking name, dob,= etc. has no significance. In this case, the identity proofing is checking = the person's retina pattern against the data stored in the database, pe= rhaps after templating.=C2=A0

Cheers,=C2=A0
Nat

=C2=A0

On Wed Nov 12 2014 at 9:01:36 Jim Fenton <fenton@bluepopcorn.net> wrote:
=20 =20 =20
Peter,

My point in suggesting use cases is that I have a sense that the model is already too complex. Maybe an analyst can turn the crank and come up with use cases that utilize all four of these factors independently, but if they're too obscure that tells us something too.

I'm not clear on what you mean about extended attributes. When yo= u talk about identity proofing, you're already talking about establishing a binding between an attribute (e.g., name) and an authentication token.

Finally, it sounds like we're talking past each other on the word "vector". We're using the word in the mathematical sens= e, and it appears you're using it in the epidemiological sense. If there= 9;s a word here I have a quibble about, it's "trust".

Nat,

In using the word "reliability" I intentionally avoided the= word "quality". I would include identity proofing as one aspect = of attribute reliability, and since that's part of enrollment (per 29115) that must not be out of scope.


-Jim


On 11/11/14 3:09 PM, Peter Alterman wrote:
Nat et. al.=

Let's n= ot reason backwards from use cases but forwards from expertise. There are a zillion use cases out there that can be generated for any model (sort of like a cost/benefit analysis - just tell the analyst what answer you want and let him/her crank out the sausage). Rather, what are the legitimate components of an identity assertion; what's the nature of the relationship among them? Nothing I've seen so far changes my opinion that there are four variables: strength of identity proofing (measured against a benchmark that incorporates *both* 800-63 and 29115); intrinsic resistance of credential type to attack (see prior benchmarking comment); credential management (how well it addresses the threat vectors in 29115 and aligns with 800-63 processes, and exchange, which incorporates mitigation of data in motion threat vectors listed in 29115 relevant to AuthN.=C2=A0

I fear ther= e is a fair amount of rat hole diving in process, and I'm urgin= g a pragmatic eye here. Strongly support putting off any discussion of extended attributes until this particular effort has been completed. No further work on attributes should go forward without benchmarking the myriad efforts in that arena in the past 3 years so we don't reinvent any wheels or redefine the meaning of "round." Also agree that the Au= thN process is not part of determining the trustworthiness (rat hole warning) of an online identity assertion but the process of making such a determination.

Finally, scalar is not vector. C'mon guys, give an old man a break. We're talking factors, not vectors. As an example, a threat vector is an identity assertion threat aimed at someone or some process: it has strength and it has direction.

regards,

Peter


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


On Tue, Nov 11, 2014 at 5:28 PM, Nat Sakimura <sakimura@gmail.com> wrote:
In many cases, people do not care about Identity Proofing. As long as the credential management and after is done right, it should not matter in many commercial use case. So, in the previous expression, to some of my use cases, I am indifferent with (1, 2, 2, 2) and (4, 2, 2, 2). In the traditional SP800-63 case, however, the former is 0 and later is 2, making (1, 2, 2, 2) and (1, 1, 1, 1) indifferent, losing the information I was interested in. Also, I may want to accept (1,2,2,1) on a intranet while I am only willing to accept (1,2,2,2) over the internet. Justin was arguing to collapse the middle two, and that may well be a good simplification. In this case, I still care those three dimensions instead of four.=C2=A0

As to the attribute reliability is concerned, the room concluded that it is out of scope for VoT for now, that we should only concentrate on entity authentication assurance. The quality of attribute should be treated more like a metadata about each attribute instead.=C2=A0

For the=C2=A0Enrollment, Credential Management, Authentication, refer to ISO/IEC 29115 or ITU-T X.1254, which are almost identical apart from the formatting and 3 words. X.1254 is freely available. You can find them here:=C2=A0https://= www.itu.int/rec/T-REC-X.1254-201209-I/en

Nat


On Wed Nov 12 2014 at 6:53:11 Jim Fenton <fenton@bluepopcorn.net> wrote:
One of the requirements should be that there be only as many dimensions to the vector as would be actionable by a Relying Party to make an authorization decision. Otherwise, the model is more complex than it needs to be.

I'm not sure I understand how Enrollment, Credentia= l Management, Authentication, and Assertion Transmission are defined (if that was discussed on the list, I'd appreciate a pointer to it). But as a relying party, if the quality of an attribute I receive is limited by something, I probably don't care whether it was because the credential management or the assertion transmission was the cause.

So if this retains 4 dimensions, there should be use cases that justify the need for 4. I can do that for 2 dimensions (authentication strength/attribute reliability) by considering uses like strong pseudonymous authentication with a trustable assertion of an attribute like age. I don't have an= y good examples for more than 2.


-Jim


On 11/11/14 1:34 PM, Nat Sakimura wrote:
We had a bar-bof last night at IETF 91.=C2=A0

There was a discussion that perhaps instead of three dimension "Identity Proofing / Credential Binding / Assertion Transmission", perhaps 4 dimension "Enrollment/Credential management/Authentication/Assertion Transmission"= ; is more appropriate. The reason was that Identity Proofing is only a step in Enrollment, Credential Binding is only a step in Credential Management, and the use of credential, i.e., Authentication, is important enough to separate out from Credential Management. Then, there followed a lengthy discussion about whether to pull Authentication out.=C2=A0

As to the "vector" is concerned, it inde= ed seem to be a vector to me in the sense that:=C2=A0

v =3D (e, c, a, t)=C2=A0
=C2=A0where e:=3Dscalar value for expressing Enrollment quality
=C2=A0c:=3Dscalar value for expressing Credential Management quality
=C2=A0a:=3Dscalar value for expressing Authenticat= ion quality
=C2=A0t:=3Dscalar value for expressing Assertion Transmission quality.=C2=A0

There was discussion on how to obtain these values as well. The room opinion was that we should define the response format and then use it to define the request format.=C2=A0

Also, there was a discussion around the nature of the value of each scalar above, and the granularity desired.=C2=A0
We were not even sure if the values are going to be an ordered set. Everybody agreed that simplicity is a requirement for widespread adoption. If granularity were sought, then it should be defined as a subset of parent value so that implementation that do not care about these can safely ignore them.=C2=A0

Apart from the above, importance of the operational quality of IdPs were expressed. This seem to be the quality which should be transmitted not per authentication transaction but separately, perhaps from .well-known resource.=C2=A0

FYI, the room also had the opinion that we should not get into the "quality of attributes&q= uot; in general but focus only to the entity authentication, at least for this round.=C2=A0

Cheers,=C2=A0

Nat




On Wed Nov 12 2014 at 5:25:56 Peter Alterman <palterman@safe-biopharma.org>= ; wrote:
Pardon me not diddling with the strawman. A quick read generated the comments following. Hope they are helpful in evolving the document.

What is immediately missing is a value for the quality of the credential technology because some credential types are inherently less secure - or risk mitigating - than others.=C2=A0

My second observation is that it is not yet clear to me why these elements are called vectors. Vectors are expressions of quantities in spacio-temporal directions. So far I see three (and the fourth I recommend here) factors. In order to consider them vectors, please show me a plot on a graph and label the axes and the measurement units.

My third observation is that I do not see any straightforward way for the factors to be collapsed. There are no approaches to do so presented, either. First question to ask here is whether the ecosystem will need to deploy both a transmission protocol and a receiving protocol? If the methodology requires broad uptake of RP software in order to decode the transmitted factors, the Hydra is unleashed.

thanks,

Peter

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


On Tue, Nov 11, 2014 at 3:02 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-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. Document in GitHub (Richer, J= ustin P.)


---------- Forwarded message ----------
From:=C2=A0"Richer, Justin P." <= jricher@mitre.org>
To:=C2=A0"vot@ietf.org" <vot@ietf.org>
Cc:=C2=A0
Date:=C2=A0Mon, 10 Nov 2014 21:07:53 +0000 Subject:=C2=A0[VoT] Document in GitHub
I've started the work of translating much of my original strawman document to Markdown and pushing it to GitHub so that we can start taking edits via pull request:

=C2=A0 https://gi= thub.com/vectorsoftrust/strawman/blob/master/VectorsOfTrust.md

Clone and fork away!

=C2=A0-- Justin


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

_______________________________________________
vot mailing list
v= ot@ietf.org
https://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

--047d7bdc1268be450c0507a14ae2-- From nobody Tue Nov 11 20:06:15 2014 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 788E01AC40B for ; Tue, 11 Nov 2014 20:06:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=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 xXeoFmz3odCY for ; Tue, 11 Nov 2014 20:06:02 -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 2EB971A888C for ; Tue, 11 Nov 2014 20:06:01 -0800 (PST) Received: from s111-0006-lnv01 (Not Verified[127.0.0.1]) by smtp.safecom.net.nz (using TLS: SSLv23) id ; Wed, 12 Nov 2014 17:05:58 +1300 Message-ID: <569AD906E45DB44A8AFF11D61F5DA791D34E1885@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 1587592135; Wed, 12 Nov 2014 17:05:58 +1300 (NZDT) Received: from WLGPRDCAS01.dia.govt.nz (Not Verified[127.0.0.1]) by WLGPRDMM01.dia.govt.nz with MailMarshal (v7, 1, 1, 5205) (using TLS: SSLv23) id ; Wed, 12 Nov 2014 17:04:30 +1300 Received: from WLGPRDMBX01.dia.govt.nz ([fe80::13e:8e96:252b:e0d1]) by WLGPRDCAS01.dia.govt.nz ([127.0.0.1]) with mapi id 14.03.0146.000; Wed, 12 Nov 2014 17:05:57 +1300 From: Joanne Knight To: 'Jim Fenton' , 'Peter Alterman' , 'Nat Sakimura' Thread-Topic: [VoT] vot Digest, Vol 3, Issue 3 Thread-Index: AQHP/hy8tu8aCDTxCkCkVLKpLLJ2WQ== Date: Wed, 12 Nov 2014 04:04:29 +0000 References: <54628544.8040801@bluepopcorn.net> <5462A357.6060707@bluepopcorn.net> In-Reply-To: <5462A357.6060707@bluepopcorn.net> Accept-Language: en-NZ, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [172.29.0.162] Content-Type: multipart/related; boundary="_004_569AD906E45DB44A8AFF11D61F5DA791D34E1885WLGPRDMBX01diag_"; type="multipart/alternative" X-sdp.mm2006: true Archived-At: http://mailarchive.ietf.org/arch/msg/vot/x6tHA4cV1CqAHoJSISdBsi66mrc Cc: "'vot@ietf.org'" Subject: Re: [VoT] vot Digest, Vol 3, Issue 3 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, 12 Nov 2014 04:06:13 -0000 --_004_569AD906E45DB44A8AFF11D61F5DA791D34E1885WLGPRDMBX01diag_ Content-Type: multipart/alternative; boundary="_000_569AD906E45DB44A8AFF11D61F5DA791D34E1885WLGPRDMBX01diag_" --_000_569AD906E45DB44A8AFF11D61F5DA791D34E1885WLGPRDMBX01diag_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Greetings All I am new to this group so for the benefit of those who do not know me... I am Joanne Knight (probably the real me but not what you will find on any = official register) ;-) Currently working for the Department of Internal Affairs - New Zealand My role is to look after New Zealand's Evidence of Identity Standard, carry= ing out Identity-related risk assessments on government services and genera= lly providing advice on the practice of Identity Management. Lately I have become entwined with the writing of ISO/IEC 29003 - Identity = Proofing. As life has emerged in the vot@ietf.org group the last= couple of days and I have started to see content on which I am encouraged = to comment, here goes my initial thoughts - from a very non-technical appro= ach. I read Justin Richer's strawman and noted that he has identified a differen= t number of levels in each dimension. My thinking so far is that this may v= ery well be the case and that will have an interesting impact on the abilit= y to have 4 (or any number) LoAs. The identity subject (aka user) is associated with an identity provider whi= ch acts as a trusted 3rd party on behalf of the user wrt to a relying party= by making identity assertions about the user to the relying party. The fir= st time I have registered a clear indication that the context is limited to= the creation of an (electronic) identity credential. Thank you. In my worl= d I have a wider scope that encompasses identity and authentication in all = contexts and channels and I have had trouble understanding all the bits tha= t (to me) are missing. When considering who the audience is for LoA this co= ntext is the only time I have calculated that it is relevant. i.e. if you a= re not in the business of providing identity assertion services to other pa= rties, you do not care what your resulting LoA might be. And no one else wi= ll really care either. See comment on VoT below. The dimensions I have noted are 4: identity proofing, credential management= (which includes credential issuance, credential strength etc) and authentic= ation (the use of the credential). For the purposes of assessing LoA I am i= nclined to want to split credential strength from the other aspects of cred= ential management. I disagree that identity proofing should be expanded to = Enrolment as this often begins to introduce elements of eligibility (outsid= e of identity) for a service and the danger is that this then adds elements= into credential management that could see a credential revoked for reasons= other than user choice, death (or destruction) and fraud detection. I agree with Nat that we must be able to accept the scenario that identity = may not matter to a relying party but that the persistence of an identity e= ntity credential binding may require a high level of assurance. This is req= uired for single or binary assertions based on identity such as 'entity is = over 18 years' or 'entity is a citizen'. Depending of course on the breadth= of attributes in the identity service. In regards to Identity proofing, which is my current focus, I am currently = writing a paper that extends the 0-3 introduced by Justin. It has 4 levels = including the zero level described, however level 3 has an A and B. I will = forward for your opinion as soon as I can. VoT - this is a complex way to express the factual outcome of each dimensio= n. In the real world I would say 'who is the audience for this value?' The = (business people in a) relying party probably do not care which individual = element is at what level. However if the scales for each dimension are like= ly to be different then this may be the only realistic way to express an ov= erarching LoA. Thanks for listening (reading). PS. Peter loved your blog ' Why LOA for Attributes Don't Really Exist' Joanne Knight | Evidence of Identity (EOI) Standard Custodian | Digital Tra= nsformation | Result 10 | RealMe The Department of Internal Affairs Te Tari Taiwhenua Direct Dial: +64 4 382 3596 | Extn: 4596 120 Victoria St | PO Box 10-526, Wellington 6143, New Zealand | www.dia.go= vt.nz [http://www.dia.govt.nz/diawebsite.nsf/Files/DIAlogo/$file/DIAlogo.png] From: Jim Fenton [mailto:fenton@bluepopcorn.net] Sent: Wednesday, 12 November 2014 1:01 p.m. To: Peter Alterman; Nat Sakimura Cc: vot@ietf.org Subject: Re: [VoT] vot Digest, Vol 3, Issue 3 Peter, My point in suggesting use cases is that I have a sense that the model is a= lready too complex. Maybe an analyst can turn the crank and come up with us= e cases that utilize all four of these factors independently, but if they'r= e too obscure that tells us something too. I'm not clear on what you mean about extended attributes. When you talk abo= ut identity proofing, you're already talking about establishing a binding b= etween an attribute (e.g., name) and an authentication token. Finally, it sounds like we're talking past each other on the word "vector".= We're using the word in the mathematical sense, and it appears you're usin= g it in the epidemiological sense. If there's a word here I have a quibble = about, it's "trust". Nat, In using the word "reliability" I intentionally avoided the word "quality".= I would include identity proofing as one aspect of attribute reliability, = and since that's part of enrollment (per 29115) that must not be out of sco= pe. -Jim On 11/11/14 3:09 PM, Peter Alterman wrote: Nat et. al. Let's not reason backwards from use cases but forwards from expertise. Ther= e are a zillion use cases out there that can be generated for any model (so= rt of like a cost/benefit analysis - just tell the analyst what answer you = want and let him/her crank out the sausage). Rather, what are the legitimat= e components of an identity assertion; what's the nature of the relationshi= p among them? Nothing I've seen so far changes my opinion that there are fo= ur variables: strength of identity proofing (measured against a benchmark t= hat incorporates *both* 800-63 and 29115); intrinsic resistance of credenti= al type to attack (see prior benchmarking comment); credential management (= how well it addresses the threat vectors in 29115 and aligns with 800-63 pr= ocesses, and exchange, which incorporates mitigation of data in motion thre= at vectors listed in 29115 relevant to AuthN. I fear there is a fair amount of rat hole diving in process, and I'm urging= a pragmatic eye here. Strongly support putting off any discussion of exten= ded attributes until this particular effort has been completed. No further = work on attributes should go forward without benchmarking the myriad effort= s in that arena in the past 3 years so we don't reinvent any wheels or rede= fine the meaning of "round." Also agree that the AuthN process is not part = of determining the trustworthiness (rat hole warning) of an online identity= assertion but the process of making such a determination. Finally, scalar is not vector. C'mon guys, give an old man a break. We're t= alking factors, not vectors. As an example, a threat vector is an identity = assertion threat aimed at someone or some process: it has strength and it h= as direction. regards, Peter ------------------------------------------------------------ Peter Alterman, Ph.D. Chief Operating Officer SAFE-BioPharma Association cell: 301-943-7452 On Tue, Nov 11, 2014 at 5:28 PM, Nat Sakimura > wrote: In many cases, people do not care about Identity Proofing. As long as the c= redential management and after is done right, it should not matter in many = commercial use case. So, in the previous expression, to some of my use case= s, I am indifferent with (1, 2, 2, 2) and (4, 2, 2, 2). In the traditional = SP800-63 case, however, the former is 0 and later is 2, making (1, 2, 2, 2)= and (1, 1, 1, 1) indifferent, losing the information I was interested in. = Also, I may want to accept (1,2,2,1) on a intranet while I am only willing = to accept (1,2,2,2) over the internet. Justin was arguing to collapse the m= iddle two, and that may well be a good simplification. In this case, I stil= l care those three dimensions instead of four. As to the attribute reliability is concerned, the room concluded that it is= out of scope for VoT for now, that we should only concentrate on entity au= thentication assurance. The quality of attribute should be treated more lik= e a metadata about each attribute instead. For the Enrollment, Credential Management, Authentication, refer to ISO/IEC= 29115 or ITU-T X.1254, which are almost identical apart from the formattin= g and 3 words. X.1254 is freely available. You can find them here: https://= www.itu.int/rec/T-REC-X.1254-201209-I/en Nat On Wed Nov 12 2014 at 6:53:11 Jim Fenton > wrote: One of the requirements should be that there be only as many dimensions to = the vector as would be actionable by a Relying Party to make an authorizati= on decision. Otherwise, the model is more complex than it needs to be. I'm not sure I understand how Enrollment, Credential Management, Authentica= tion, and Assertion Transmission are defined (if that was discussed on the = list, I'd appreciate a pointer to it). But as a relying party, if the quali= ty of an attribute I receive is limited by something, I probably don't care= whether it was because the credential management or the assertion transmis= sion was the cause. So if this retains 4 dimensions, there should be use cases that justify the= need for 4. I can do that for 2 dimensions (authentication strength/attrib= ute reliability) by considering uses like strong pseudonymous authenticatio= n with a trustable assertion of an attribute like age. I don't have any goo= d examples for more than 2. -Jim On 11/11/14 1:34 PM, Nat Sakimura wrote: We had a bar-bof last night at IETF 91. There was a discussion that perhaps instead of three dimension "Identity Pr= oofing / Credential Binding / Assertion Transmission", perhaps 4 dimension = "Enrollment/Credential management/Authentication/Assertion Transmission" is= more appropriate. The reason was that Identity Proofing is only a step in = Enrollment, Credential Binding is only a step in Credential Management, and= the use of credential, i.e., Authentication, is important enough to separa= te out from Credential Management. Then, there followed a lengthy discussio= n about whether to pull Authentication out. As to the "vector" is concerned, it indeed seem to be a vector to me in the= sense that: v =3D (e, c, a, t) where e:=3Dscalar value for expressing Enrollment quality c:=3Dscalar value for expressing Credential Management quality a:=3Dscalar value for expressing Authentication quality t:=3Dscalar value for expressing Assertion Transmission quality. There was discussion on how to obtain these values as well. The room opinio= n was that we should define the response format and then use it to define t= he request format. Also, there was a discussion around the nature of the value of each scalar = above, and the granularity desired. We were not even sure if the values are going to be an ordered set. Everybo= dy agreed that simplicity is a requirement for widespread adoption. If gran= ularity were sought, then it should be defined as a subset of parent value = so that implementation that do not care about these can safely ignore them. Apart from the above, importance of the operational quality of IdPs were ex= pressed. This seem to be the quality which should be transmitted not per au= thentication transaction but separately, perhaps from .well-known resource. FYI, the room also had the opinion that we should not get into the "quality= of attributes" in general but focus only to the entity authentication, at = least for this round. Cheers, Nat On Wed Nov 12 2014 at 5:25:56 Peter Alterman > wrote: Pardon me not diddling with the strawman. A quick read generated the commen= ts following. Hope they are helpful in evolving the document. What is immediately missing is a value for the quality of the credential te= chnology because some credential types are inherently less secure - or risk= mitigating - than others. My second observation is that it is not yet clear to me why these elements = are called vectors. Vectors are expressions of quantities in spacio-tempora= l directions. So far I see three (and the fourth I recommend here) factors.= In order to consider them vectors, please show me a plot on a graph and la= bel the axes and the measurement units. My third observation is that I do not see any straightforward way for the f= actors to be collapsed. There are no approaches to do so presented, either.= First question to ask here is whether the ecosystem will need to deploy bo= th a transmission protocol and a receiving protocol? If the methodology req= uires broad uptake of RP software in order to decode the transmitted factor= s, the Hydra is unleashed. thanks, Peter ------------------------------------------------------------ Peter Alterman, Ph.D. Chief Operating Officer SAFE-BioPharma Association cell: 301-943-7452 On Tue, Nov 11, 2014 at 3:02 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. Document in GitHub (Richer, Justin P.) ---------- Forwarded message ---------- From: "Richer, Justin P." > To: "vot@ietf.org" > Cc: Date: Mon, 10 Nov 2014 21:07:53 +0000 Subject: [VoT] Document in GitHub I've started the work of translating much of my original strawman document = to Markdown and pushing it to GitHub so that we can start taking edits via = pull request: https://github.com/vectorsoftrust/strawman/blob/master/VectorsOfTrust.md Clone and fork away! -- Justin _______________________________________________ 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 --_000_569AD906E45DB44A8AFF11D61F5DA791D34E1885WLGPRDMBX01diag_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Greetings All<= /span>

 <= /p>

I am new to this group so= for the benefit of those who do not know me…

 <= /p>

I am Joanne Knight (proba= bly the real me but not what you will find on any official register) ;-)

Currently working for the= Department of Internal Affairs – New Zealand

My role is to look after = New Zealand’s Evidence of Identity Standard, carrying out Identity-re= lated risk assessments on government services and generally providing advice on the practice of Identity Management.

Lately I have become entw= ined with the writing of ISO/IEC 29003 – Identity Proofing.

 <= /p>

As life has emerged in th= e vot@ietf.org group the last couple of d= ays and I have started to see content on which I am encouraged to comment, = here goes my initial thoughts – from a very non-technical approach.

 <= /p>

I read Justin Richer̵= 7;s strawman and noted that he has identified a different number of levels = in each dimension. My thinking so far is that this may very well be the case and that will have an interesting impact on the ability to hav= e 4 (or any number) LoAs.

The iden= tity subject (aka us= er) is associated with an iden= tity provider which = acts as a trusted 3rd party on behalf of the user wrt to a rely= ing party by making iden= tity assertions abou= t the user to the relying party. The first time I have registered a clear = indication that the context is limited to the creation of an (electronic) i= dentity credential. Thank you. In my world I have a wider scope that encompasses identity and authentication in all contexts and cha= nnels and I have had trouble understanding all the bits that (to me) are mi= ssing. When considering who the audience is for LoA this context is the onl= y time I have calculated that it is relevant. i.e. if you are not in the business of providing identity ass= ertion services to other parties, you do not care what your resulting LoA m= ight be. And no one else will really care either.  See comment on VoT = below.

The dimensions I have noted are 4: identity proofing, credential management(w= hich includes credential issuance, credential strength etc) and authentication (the use of the credential). For the purposes of assessing LoA I am in= clined to want to split credential strength from the other aspects of crede= ntial management. I disagree that identity proofing should be expanded to Enrolment as this often begins to introduce elements of eli= gibility (outside of identity) for a service and the danger is that this th= en adds elements into credential management that could see a credential rev= oked for reasons other than user choice, death (or destruction) and fraud detection.

I agree with Nat that we must be able to acce= pt the scenario that identity may not matter to a relying party but that th= e persistence of an identity entity credential binding may require a high level of assurance. This is required for single or bina= ry assertions based on identity such as ‘entity is over 18 years̵= 7; or ‘entity is a citizen’. Depending of course on the breadth= of attributes in the identity service.

In regards to Identity proofing, which is my = current focus, I am currently writing a paper that extends the 0-3 introduc= ed by Justin. It has 4 levels including the zero level described, however level 3 has an A and B. I will forward for your opinion= as soon as I can.

VoT - this is a complex way to express the fa= ctual outcome of each dimension. In the real world I would say ‘who i= s the audience for this value?’ The (business people in a) relying party probably do not care which individual element is at what level. Howe= ver if the scales for each dimension are likely to be different then this m= ay be the only realistic way to express an overarching  LoA.  &nb= sp;

Thanks for listening (reading).

PS. Peter loved your blog ‘ Why LOA for= Attributes Don’t Really Exist’

 <= /p>

 

Joanne Knight= | Evidence of Identity (EOI) Standard Custodian |= Digital Transformation | Result 10 | RealMe   
The Department of Internal Affairs Te Tari Taiwhenua    <= /b>
Direct Dial: +64 4 382 3596 | Extn: 4596 
120 Victoria St | PO Box 10-526, Wellington 6143, New Zealand |  www.dia.govt.nz


3D"ht=

 <= /p>

 <= /p>

 <= /p>

 <= /p>

From:= Jim Fenton [mailto:= fenton@bluepopcorn.net]
Sent: Wednesday, 12 November 2014 1:01 p.m.
To: Peter Alterman; Nat Sakimura
Cc: vot@ietf.org
Subject: Re: [VoT] vot Digest, Vol 3, Issue 3

 

Peter,

My point in suggesting use cases is that I have a sense that the model is a= lready too complex. Maybe an analyst can turn the crank and come up with us= e cases that utilize all four of these factors independently, but if they'r= e too obscure that tells us something too.

I'm not clear on what you mean about extended attributes. When you talk abo= ut identity proofing, you're already talking about establishing a binding b= etween an attribute (e.g., name) and an authentication token.

Finally, it sounds like we're talking past each other on the word "vec= tor". We're using the word in the mathematical sense, and it appears y= ou're using it in the epidemiological sense. If there's a word here I have = a quibble about, it's "trust".

Nat,

In using the word "reliability" I intentionally avoided the word = "quality". I would include identity proofing as one aspect of att= ribute reliability, and since that's part of enrollment (per 29115) that mu= st not be out of scope.

-Jim

On 11/11/14 3:09 PM, Peter Alterman wrote:

Nat et. al.

 

Let's not reason backwards from use cases but forwar= ds from expertise. There are a zillion use cases out there that can be gene= rated for any model (sort of like a cost/benefit analysis - just tell the a= nalyst what answer you want and let him/her crank out the sausage). Rather, what are the legitimate components= of an identity assertion; what's the nature of the relationship among them= ? Nothing I've seen so far changes my opinion that there are four variables= : strength of identity proofing (measured against a benchmark that incorporates *both* 800-63 and 29115); = intrinsic resistance of credential type to attack (see prior benchmarking c= omment); credential management (how well it addresses the threat vectors in= 29115 and aligns with 800-63 processes, and exchange, which incorporates mitigation of data in motion threat vecto= rs listed in 29115 relevant to AuthN. 

 

I fear there is a fair amount of rat hole diving in = process, and I'm urging a pragmatic eye here. Strongly support putting off = any discussion of extended attributes until this particular effort has been= completed. No further work on attributes should go forward without benchmarking the myriad efforts in that arena in= the past 3 years so we don't reinvent any wheels or redefine the meaning o= f "round." Also agree that the AuthN process is not part of deter= mining the trustworthiness (rat hole warning) of an online identity assertion but the process of making such a determina= tion.

 

Finally, scalar is not vector. C'mon guys, give an o= ld man a break. We're talking factors, not vectors. As an example, a threat= vector is an identity assertion threat aimed at someone or some process: i= t has strength and it has direction.

 

regards,

 

Peter

 


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

Peter Alterman, Ph.D.

Chief Operating Officer
SAFE-BioPharma Association

cell: 301-943-7452

 

On Tue, Nov 11, 2014 at 5:28 PM, Nat Sakimura <sakimura@gmail.com> wrote:

In many cases, people do not care about Identity Pro= ofing. As long as the credential management and after is done right, it sho= uld not matter in many commercial use case. So, in the previous expression,= to some of my use cases, I am indifferent with (1, 2, 2, 2) and (4, 2, 2, 2). In the traditional SP800-63 case, howe= ver, the former is 0 and later is 2, making (1, 2, 2, 2) and (1, 1, 1, 1) i= ndifferent, losing the information I was interested in. Also, I may want to= accept (1,2,2,1) on a intranet while I am only willing to accept (1,2,2,2) over the internet. Justin was = arguing to collapse the middle two, and that may well be a good simplificat= ion. In this case, I still care those three dimensions instead of four.&nbs= p;

 

As to the attribute reliability is concerned, the ro= om concluded that it is out of scope for VoT for now, that we should only c= oncentrate on entity authentication assurance. The quality of attribute sho= uld be treated more like a metadata about each attribute instead. 

 

For the Enrollment, Credential Management, Auth= entication, refer to ISO/IEC 29115 or ITU-T X.1254, which are almost identi= cal apart from the formatting and 3 words. X.1254 is freely available. You = can find them here: https://www.itu.int/rec/T-REC-X.1254-201209-I/= en

 

Nat

 

 

On Wed Nov 12 2014 at 6:53:11 Jim Fenton <fenton@bluepopcorn.net= > wrote:

One of the requirements should be that there be only= as many dimensions to the vector as would be actionable by a Relying Party= to make an authorization decision. Otherwise, the model is more complex th= an it needs to be.

I'm not sure I understand how Enrollment, Credential Management, Authentica= tion, and Assertion Transmission are defined (if that was discussed on the = list, I'd appreciate a pointer to it). But as a relying party, if the quali= ty of an attribute I receive is limited by something, I probably don't care whether it was because the cre= dential management or the assertion transmission was the cause.

So if this retains 4 dimensions, there should be use cases that justify the= need for 4. I can do that for 2 dimensions (authentication strength/attrib= ute reliability) by considering uses like strong pseudonymous authenticatio= n with a trustable assertion of an attribute like age. I don't have any good examples for more than 2.



-Jim



On 11/11/14 1:34 PM, Nat Sakimura wrote:

We had a bar-bof last= night at IETF 91. 

There was a discussion that perhaps instead of three= dimension "Identity Proofing / Credential Binding / Assertion Transmi= ssion", perhaps 4 dimension "Enrollment/Credential management/Aut= hentication/Assertion Transmission" is more appropriate. The reason was that Identity Proofing is only a step in Enrollment, Creden= tial Binding is only a step in Credential Management, and the use of creden= tial, i.e., Authentication, is important enough to separate out from Creden= tial Management. Then, there followed a lengthy discussion about whether to pull Authentication out. <= /o:p>

 

As to the "vector" is concerned, it indeed= seem to be a vector to me in the sense that: 

 

v =3D (e, c, a, t) 

 where e:=3Dscalar value for expressing Enrollm= ent quality

 c:=3Dscalar value for expressing Credential Ma= nagement quality

 a:=3Dscalar value for expressing Authenticatio= n quality

 t:=3Dscalar value for expressing Assertion Tra= nsmission quality. 

 

There was discussion on how to obtain these values a= s well. The room opinion was that we should define the response format and = then use it to define the request format. 

 

Also, there was a discussion around the nature of th= e value of each scalar above, and the granularity desired. =

We were not even sure if the values are going to be = an ordered set. Everybody agreed that simplicity is a requirement for wides= pread adoption. If granularity were sought, then it should be defined as a = subset of parent value so that implementation that do not care about these can safely ignore them. 

 

Apart from the above, importance of the operational = quality of IdPs were expressed. This seem to be the quality which should be= transmitted not per authentication transaction but separately, perhaps fro= m .well-known resource. 

 

FYI, the room also had the opinion that we should no= t get into the "quality of attributes" in general but focus only = to the entity authentication, at least for this round. 

 

Cheers, 

 

Nat

 

 

 

 

On Wed Nov 12 2014 at 5:25:56 Peter Alterman <palterman@sa= fe-biopharma.org> wrote:

Pardon me not diddling with the strawman. A quick re= ad generated the comments following. Hope they are helpful in evolving the = document.

 

What is immediately missing is a value for the quali= ty of the credential technology because some credential types are inherentl= y less secure - or risk mitigating - than others. 

 

My second observation is that it is not yet clear to= me why these elements are called vectors. Vectors are expressions of quant= ities in spacio-temporal directions. So far I see three (and the fourth I r= ecommend here) factors. In order to consider them vectors, please show me a plot on a graph and label the axes= and the measurement units.

 

My third observation is that I do not see any straig= htforward way for the factors to be collapsed. There are no approaches to d= o so presented, either. First question to ask here is whether the ecosystem= will need to deploy both a transmission protocol and a receiving protocol? If the methodology requires broad uptak= e of RP software in order to decode the transmitted factors, the Hydra is u= nleashed.

 

thanks,

 

Peter


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

Peter Alterman, Ph.D.

Chief Operating Officer
SAFE-BioPharma Association

cell: 301-943-7452

 

On Tue, Nov 11, 2014 at 3:02 PM, <vot-request@ietf.org> wro= te:

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. Document in GitHub (Richer, Justin P.)


---------- Forwarded message ----------
From: "Richer, Justin P." <jricher@mitre.org>
To: "vot@ietf.o= rg" <vot@ietf= .org>
Cc: 
Date: Mon, 10 Nov 2014 21:07:53 +0000
Subject: [VoT] Document in GitHub
I've started the work of translating much of my original strawman document = to Markdown and pushing it to GitHub so that we can start taking edits via = pull request:

  https://github.com/vectorsoftrust/strawman/blob/master/VectorsOfTrust.md

Clone and fork away!

 -- Justin


_______________________________________________
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

 

 




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

 

--_000_569AD906E45DB44A8AFF11D61F5DA791D34E1885WLGPRDMBX01diag_-- --_004_569AD906E45DB44A8AFF11D61F5DA791D34E1885WLGPRDMBX01diag_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=4047; creation-date="Wed, 12 Nov 2014 04:04:28 GMT"; modification-date="Wed, 12 Nov 2014 04:04:28 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAARMAAAAwCAMAAAAFOG6mAAAB0VBMVEUAAAAFBAPfmBnnnRvdlxoB AQHclxr///8RERK1tbUqKiqgoKA2NjbroRzqoBvtoRvjmxrgmRl4eHj8/PzlnBrpnxsiIiIeHh6S kpIXFxc7OzrGxsavr6/+/v4wMDGAgIAbGhoUFBNhYWEKCgqmpqb34r3hmhrw8PC8vLxHR0fgnipM TEzV1dWcaxK9gRfTkBn09PQkGAQuLi4mJiabnJwNDQ1ycnPCwsLq6uo1JAaXl5fi4uLQ0NA/KgYT DQIHBwc0NDMaEQMMCAFDQkIgFQNQUFFGLwfEhhc/Pj739/eqqqvY2NhNNAkpGwSvdxPNzcyysrLJ ycldPwq3iTze3t75+flqamuMXw4wIATLihfa2tpnXEqocxTZlBkKDRWMjI5fX1+shUTl5uZVTUOH h4iFWxC5uLiEhIRuSgxXV1dNRz51Twu0exVvYUzmoisDBQt8fHx8a05lZWbW1taSZBFUOQhubm/P jReTeU3AjTbLki7UlSZUVFSGcU5+VxCdfUg1MStnRgpaWlpjQghcU0gwJxhgV0p5Uw/1px0oIRU7 LhjvoxxKPitxUx/t27zl2sfspyvXzblbQhnUmDFgSSHXmi2vfyrcnCmabySeeDnIwrYBrI4FAAAN uUlEQVRo3tyYC1cSQRTHZ9ldLqKLYOCCGEl6UEORhyD4QgLxkfjKDCs1LYvSstJSs3dp73M61enx bbszs/QS7PQ+x7/nsDs7M7s7v733zr2SyrBhr8jND68vXz506NDlD7x559UhqpcGg+MDu/5+qPLR PYNhq4+2Xt3cCl3aYgOfvWfd79yVxED2jIS4zI5DklkvScqqwFo5m0WSdGKOND/XS3qxJbZ8cX1z SOhTcIzJlwipH1qyhCrWItJLw0/3EBM5HjZwDF3TVkmSypt5677oQShKLrsm6sW17AwisXqGhjxm SVnqJiWDWVNLhlBlpmwS5bR3mAiIpEaN80++JlJLaT7MWuMWtBudLRfoe9KXIaH1TYtk1qW7pp+f 6iZu//mHNnEtRqhSPoSiv7yHmITdNZXBe2HWCPTZqB8sJb7YjU45nloNUEQ2tBuP+DB2HJEdhJ5h q96qHyJU3cOKJB3aO0zksFpp7Onvd2tQuB+k8lCY3XBnekidyWJaJKi2zowV443Zc51DOaXsJSZE dgR7qpIXz9SwVsKnoB+IfTRUOBxZFj+VU9SZ1JnrHupMygIhPTAfyikWZjfYFQ8dblb2EhMiq/2I ZPvkU+2TmyiUqRjp2riqZpgzKcMJMr5xciY9beVQ6gAmXPet1JmsOdLdPFcVP/5qLzEhpPLMmUcn L119xgNMs0K/fzqts928Gkr4THrciTM5m3XjJLcbZbEXUPXqEIXyfDWxVK6/m1xe+F9MhLggkz8v 4zYiub3+Ig/FbE4Pmc2S5+ZtB0IR1zKLik7ybFxaxmTENlzZAagxgYybzeXHcdfRW/RzVYYdTCqd I0by92VomD9P/oKMFMndubccyqqn6zoLqOUvZdK9tBZ4jEj0VjPuMtmWtUAJUCVpmmddSLGoXL4U 3snEuA/KyD/QOZj/GyYqbFEkR988Zq3DqXEWK8QcizCpOwzJdJplaIFZoGrnqUm2T0QkCqYsv8tE Fn7V8/0AB39+xT9+nPwUkdzUm3hmv2iz0PB5fVmmhJoVHcvuZTawFajGwkI+sWepr1yUSbLVHmJN tf0BIZF2u33Wbre3XiOksd2Oaj+AdyorHZvoaGrtJ6jw2dbThCkyW6udtObhJksbyXe6AgDV2kIr 7FStiEi1M/GJk+zO7Ky6iv02TUw4r6iEqcw+sjI66SY7tXX0zTRPYoXjCEEym6/PbL+VeUKGSLIz ZzAIu7njzIdqHj2lJZKVl0jBM4liTAxN0Olmj4ZSTGxA0w1CDgDTIPZVwPxoyRGA84wAAIfSOaDd 8jyUEK4KOEC+08ixQfBXciYrwDRJn8Y0EOKz2gjXKDUpoQnGRhuiEK3indAx5scXKqBYC3cDOfcE IVh16ZlHc7YF0vwEa0DbVGbmzN3N8eURjiRo2J5riQWsop4murLx0oZvq5jvoGE1hPNMHKohAqNu VY1TJqVhh6OG9lXQPtLLJxiPwYCXrTbP5BzsKyvGpB8a1Hq4kmeSNOAt4/RpnQ48czPjHuThD1XN mKwA0oi3M9KhAb8Xrfx8YffLTtkYlADuxmJLFyLRWZSFDO4rNl/KgEjM4nhvPQCcCLq35yRxumvc 7LGId4TgpaMW281iTEphAAZlzoTqNNTx/gNaUNKYoJxwms3bDwPJr5h4oR7qijEpxTl1sFKrMXER rjIY+wqbH0Z3MCE9MIGzesG5WzhL+LRyZ+HJVIa4P4q03FlNDD8Z7ibqXckiWWwPXfPQ4CD3jnp0 eqwI0xbTfSJf3PBgDVicyYET0P6FycGiTIz+/S56AGcrRENfmDTsP+0fMBZmovqjbtII0KgxCRZg Ug2no/t7djCJsDDk2gdn3aS4upcUtBSbL5CLUbvRyuTU4wS20mYPRbTomqXG/rhcR6PwUNdDltGU Yw1YnEmjyw9XCjHpGC05V1fLljpYo/av8AUboU0uwSCUZ5KEalzL2cJMImBHN+iEOo3JBaPLFWRW 2RR0uXpUhqcBX6L9GyYXatQb++qZQ84C1LeHfgBFL6KVEA6FOhNaCSEXrqV1ZgplgSeNiyZe7uTT PN0uTHqRAzwI7mTin+iIVvOlUkW9fB5ac9gJDbVjnMkoVCGXqKMQE6ETIq6q4CCm1YQFT6pRBoLp Gp7WQSM2cQBnog3bD+dUwtTbtg+ORUgRuY20wmUbL7aeGnmZbPMl6EtPxlo+l8nCvRlW7lhsi5Tk vfhxZVcmZBIG2gv5jiAI2sZwoWLgWPIzE+JYgZImv4GZyUpjo7cDKgox8UJeFdxOIt5bD0KMyUTv rVu3DPSsw9vYeATOfm0nZy9UgzNMNKl2AC8pqNi721jMsQRNnybjm+uu7mETElrLlAJqNjallclC 88b2zJCF2o1pgaR8c8nlxVe7MeFZxO7xBH/qezQm9HceIGpgy9jPPuuJ2p1MsHN0MhKJTOKGLxSJ J6Xa/Hn3N/Gktg1K4iSvNpglhdQ1LW5c7a9dUHTIpGvcat1cL8PsxDqVYkhgX38KoSCTxKlyz9Ht GXQmvU65E+gzSXMXl1/uzoTYizKR8zG2FSZUjQmqqh6Z0NZIEENE2QR4ORM+hSs0oG00kwDJ7/ad ES3NPXbEFcS/Jpj8NsaqE2CnnlNJDWwE7ayA0nqrZNm4HSQLijgdGxdxm9lcVw8PWzJnubdjaM/0 mZTmBGZxOPKRnNaLymIGOekkrAF/wEQu3ckk2uZ0OsfK8kzi56AtzJlQeY/VGyio01q62sCYdOCc ziuE6zxeZHJE6V2FIzuZ2LVs7AY45S9M+umQegriANRFKjrhRA3ZKeYKFuUlTrwzFbvPs/vXhCSy EaDqYFYZ8K2mlkzsf3EBtKy1XFbL7msL1MWf2LPa3qShKHxbcjcg22RJIRmYpUjAlwBSCS5sqSBh 8AEjk6IoFVQWm4W5IB/UhC0TXOJ0IIsm+6C/1tNz2ows/IJm50Nv7xs3PL33nuc8pxr3mn99i66J 3A65ju0OlexFM95sNreMHODUwc8f9nQ+wrw4gceOQm4mVw0i+PKzeBoG0hzr8As79SMbnfpGmAk3 YQyZt0LIh0Mbbnq5UwG83nS2GQxrriPolUqQ5asp+N6b8yDBqE907WOlcLxisnsR5da7BIm1GFeS KE+iM2KCSjJTY168wzin52WVCm7Xyew2LCN8dsZMrEavnMzuF/jlWtR9ZfGZ+TjAXs5uysEjI8sR Nsf+XKDYukdDKeARSz34lQz6t9QSy6cpc0H+udDDzSVK6J+FHnM7S2djbAJBMbCNEe2ShMncpJba 1n8JjE7OWwYEHrpVW6FN6xARArcnypLXFadhMgH1RDuM1QiS1yYkQFHa398tNzL1RfSiD3TN598r lMfmUUkIAV1bKCk+AAgoCl/vD16dOQoTPjSVx6+aSkEPUll/WVnTtdWVxi10OXLmQBOBjJwCizNF ai/0QSJDXZBiUo0v9QerrkMnYcK9oNoDKD+tpN4KUtcic//1i5IKYTbKGmcLeJkeP07+2GcQA/pQ dMq2pE+MTwY+R+UBGZfzwe6ursszmcDlZBHfx8l06vbzRYwpVQKlodQ41EZ+ZPYnL5/gnTwWHZXz ikBqNNjthi0JxWXlc4iMtLKb3x5aFEolJmJnk2PI7E8J1/f+VQdhwnOZtcBwGLGlNjuJbiWCpayi fjaJoDAJKGXs/fAIOrrtEu6bG6aAq3R7I7+DMGFcyKzJArF7zA/7GlQjH/Ql4aLjcdEPFJOwN0Bz KhSeDg7a6n2guiDGAmXRdnsn95jhcY4ZhlVOo6ZNjdk+swUafkej51XjXxTNwBq04XDPFGohzzlb vLardo3J/+7p50VRMAzgeHtYvo52StDGftkkqOghJk2poCACbQ8WVIe5FEsU3sKBOc1p/vLd0QZm 2fYyJ9nPTR+e9/Dlff+PJm6Dv/WtmE8aAV9UviaBJy0NyXO5Sn5/LyUv4RNHBAglyVhK0qpFzqqs +eSw4IvK1+QS2VPR0VZceZrd0x3N4JONC/A8t5WeHe0oxOv4jyZvfFH5mkCsSwDbLVfKEK5/Wi1a 0OKqNiMnb1tAMWgVe68ZHzM+Nt7XIZY/TrutjE1MoQlIWrV5TaF3ALk+V2vEjmRbvB4pZBGAYQ8O 0HRk1lpIdqb+CnatKe6AidM+Qu1lXXVMQi3BsGXY7iO1w21lbBL6FjTu3YNNrt8dgezMLHXIdqDq LuKQwsIBdsqd8wreoIXVCxl0OCvg3KeZ3sdURpJvkk2jWi8hFAKGImxtLRgcua2MTTZ+Auluo4/I mf4K6vcmyh7z3gCUDgUthZP/TPoA9UdYdfsoErVqPrpTY0bKz+gN0oEZChPGQkI2g73aRxlxWxmb JP74/T44TQphzwJtyFaVCHUXZNWjIGaQ2uC8wLkKni7HukVaA3GJocgcvs33MtgvPAnPuL/7vTkg DjEFg9vK2OTkm4T+kg8/pmtkdU8o3OHqIcT6ioLyAvMhVC9Qi+CskEwTWQyI1ROeCNEb77QLE2FD MB2jZWz1EeNvK24rY5Nmt0+se0gBucb3CbQfnuxKgNU1wexa5GS9AwttfKiMYGdDTQna363zAkIh yF/TwuYkQftIIoScvi/TyoWWkv2IKha3lbKJFkNd1+YTcoGygb0/qz+uOc36YLbX5OKqAUtB3Nse DB8g0KvWQV2EELZdRvb7crW6BEcieQx5UlQpvcDR1/ZKg3/5BVTj62hFf+02AAAAAElFTkSuQmCC --_004_569AD906E45DB44A8AFF11D61F5DA791D34E1885WLGPRDMBX01diag_-- From nobody Tue Nov 11 23:34:31 2014 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 702231A6FA9 for ; Tue, 11 Nov 2014 23:34:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.794 X-Spam-Level: X-Spam-Status: No, score=-4.794 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, 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 2MpabDBRhXk5 for ; Tue, 11 Nov 2014 23:34:27 -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 BFFDF1A6F91 for ; Tue, 11 Nov 2014 23:34:26 -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 sAC7XMRH000395 for ; Wed, 12 Nov 2014 01:34:25 -0600 Received: from uthmail3.uthouston.edu (admin4-6.hsc.uth.tmc.edu [129.106.4.6]) by mta6.uth.tmc.edu with ESMTP id 1qky68rnfd-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Wed, 12 Nov 2014 01:34:25 -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; Wed, 12 Nov 2014 01:34:24 -0600 From: "Jones, Mark B" To: "vot@ietf.org" Thread-Topic: [VoT] vot Digest, Vol 3, Issue 3 Thread-Index: AQHP/e5JQaga2Npb6ECy3ntv8rvPL5xb801egABpLQD//6VY/YAAb/2AgAAS92A= Date: Wed, 12 Nov 2014 07:34:22 +0000 Message-ID: <38AAF00EA635514CA6667ACA60C7F0A531502DBD@UTHMAIL1.uthouston.edu> References: <54628544.8040801@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.149.129] Content-Type: multipart/signed; boundary="----=_NextPart_000_004B_01CFFE18.C8011CA0"; protocol="application/x-pkcs7-signature"; micalg=SHA1 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.28, 0.0.0000 definitions=2014-11-12_04:2014-11-11,2014-11-12,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 kscore.is_bulkscore=2.39632802490064e-09 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-1411120068 Archived-At: http://mailarchive.ietf.org/arch/msg/vot/yVBOInWmKtAxfmoRFoNPYbZwvZg Cc: "Weems, William A" Subject: Re: [VoT] vot Digest, Vol 3, Issue 3 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, 12 Nov 2014 07:34:29 -0000 ------=_NextPart_000_004B_01CFFE18.C8011CA0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_004C_01CFFE18.C8011CA0" ------=_NextPart_001_004C_01CFFE18.C8011CA0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable After attending Lief=E2=80=99s session on VoT in Indianapolis I was left = with the idea that the foundation for this effort should be threats (or = groups of threats). It was my impression that a =E2=80=98Vector of = Trust=E2=80=99 would get its direction from a specific threat or group = of threats and its magnitude from how these threats are mitigated. For = example, I would propose that the =E2=80=98vector=E2=80=99 that Peter = identified as missing would be the set of =E2=80=98authentication = phase=E2=80=99 threats and the credential technology used to mitigate = these threats. Visually, the use of different credential technologies = would move you along this vector where use of simple passwords would be = a magnitude near the origin and use of cryptographic hard tokens would = be a magnitude far from the origin. =20 All of the frameworks I have seen that are comparable to 800-63 have = similar sections that outline threats and define levels of assurance by = grouping these threats and prescribing methods for mitigating them in = order to address predefined risk profiles. If the goal is to improve = interoperability between these frameworks and remove the assumption of = predefined risk profiles, I suggest that this effort needs to look at = how the various frameworks group threats, and then standardize these = groupings and mitigation methods. =20 =20 =20 ------=_NextPart_001_004C_01CFFE18.C8011CA0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

After attending Lief=E2=80=99s session on VoT in Indianapolis I was = left with the idea that the foundation for this effort should be threats = (or groups of threats).=C2=A0 It was my impression that a = =E2=80=98Vector of Trust=E2=80=99 would get its direction from a = specific threat or group of threats and its magnitude from how these = threats are mitigated.=C2=A0 For example, I would propose that the = =E2=80=98vector=E2=80=99 that Peter identified as missing would be the = set of =E2=80=98authentication phase=E2=80=99 threats and the credential = technology used to mitigate these threats.=C2=A0 Visually, the use of = different credential technologies would move you along this vector where = use of simple passwords would be a magnitude near the origin and use of = cryptographic hard tokens would be a magnitude far from the = origin.

 

All of the frameworks I have seen that are comparable to 800-63 have = similar sections that outline threats and define levels of assurance by = grouping these threats and prescribing methods for mitigating them in = order to address predefined risk profiles. =C2=A0If the goal is to = improve interoperability between these frameworks and remove the = assumption of predefined risk profiles, I suggest that this effort needs = to look at how the various frameworks group threats, and then = standardize these groupings and mitigation = methods.

 

 

 

------=_NextPart_001_004C_01CFFE18.C8011CA0-- ------=_NextPart_000_004B_01CFFE18.C8011CA0 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 BQCgggI8MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MTExMjA3 MzQyMFowIwYJKoZIhvcNAQkEMRYEFBPchgpLL6fjbWHjG4WWnt+ezoKNMFsGCSqGSIb3DQEJDzFO MEwwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G CCqGSIb3DQMCAgEoMAcGBSsOAwIaMIG9BgkrBgEEAYI3EAQxga8wgawwgZYxCzAJBgNVBAYTAlVT MUEwPwYDVQQKEzhUaGUgVW5pdmVyc2l0eSBvZiBUZXhhcyBIZWFsdGggU2NpZW5jZSBDZW50ZXIg YXQgSG91c3RvbjFEMEIGA1UEAxM7VGhlIFVuaXZlcnNpdHkgb2YgVGV4YXMgSGVhbHRoIFNjaWVu Y2UgQ2VudGVyIGF0IEhvdXN0b24gQ0ECEQC2CAUBCn9+NClEHZu5j+aOMIG/BgsqhkiG9w0BCRAC CzGBr6CBrDCBljELMAkGA1UEBhMCVVMxQTA/BgNVBAoTOFRoZSBVbml2ZXJzaXR5IG9mIFRleGFz IEhlYWx0aCBTY2llbmNlIENlbnRlciBhdCBIb3VzdG9uMUQwQgYDVQQDEztUaGUgVW5pdmVyc2l0 eSBvZiBUZXhhcyBIZWFsdGggU2NpZW5jZSBDZW50ZXIgYXQgSG91c3RvbiBDQQIRALYIBQEKf340 KUQdm7mP5o4wDQYJKoZIhvcNAQEBBQAEggEAZV2YICYtiqQ0qwxITzWV2VPUDVMzp2loLklRl6+U rTcAuCh7O0l3LaXf1lKxKSfszczAijJE14aWsKk2yD+1bObwFFqHWTmMgYH3yBDejooC0GOax0BY xMBRDAzyb17/RaKMhALUBTWUluQnBXzxlVNFD3I7j4s9RSicRmWPuT/BeLJRALCRzcFP5mNZ+mkf WmxoE4oC0bg8JWDFYLQOZEdfx3d+KUT+V2tTznSdxJL+6P2W3tEDT/ZbHTMRvATWjFFeL48a7pjc b2TUGBmjyicXXhT+SfsJkKX/n9ia3vlsJ3e9o6rfmbuqYyXvqrBw8+LLxmIMtG03cqJokL6CzQAA AAAAAA== ------=_NextPart_000_004B_01CFFE18.C8011CA0-- From nobody Tue Nov 11 23:38:39 2014 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 BE8E21A6FBF for ; Tue, 11 Nov 2014 23:38:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.794 X-Spam-Level: X-Spam-Status: No, score=-4.794 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, 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 dMHc485Uup1k for ; Tue, 11 Nov 2014 23:38:35 -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 002F91A6FAC for ; Tue, 11 Nov 2014 23:38:34 -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 sAC7Xm02023728; Wed, 12 Nov 2014 01:38:26 -0600 Received: from uthmail4.uthouston.edu ([129.106.175.240]) by mta5.uth.tmc.edu with ESMTP id 1qkyhn0n03-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 12 Nov 2014 01:38:26 -0600 Received: from UTHMAIL1.uthouston.edu ([fe80::c1d2:3f6a:4f56:4fa4]) by UTHMAIL4.uthouston.edu ([fe80::c5ef:d941:6689:80df%21]) with mapi id 14.03.0210.002; Wed, 12 Nov 2014 01:38:25 -0600 From: "Jones, Mark B" To: Jim Fenton , Nat Sakimura , Peter Alterman , "vot@ietf.org" Thread-Topic: [VoT] vot Digest, Vol 3, Issue 3 Thread-Index: AQHP/e5JQaga2Npb6ECy3ntv8rvPL5xb801egABpLQCAAD4/sA== Date: Wed, 12 Nov 2014 07:38:24 +0000 Message-ID: <38AAF00EA635514CA6667ACA60C7F0A531502DD7@UTHMAIL1.uthouston.edu> References: <54628544.8040801@bluepopcorn.net> In-Reply-To: <54628544.8040801@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.129] Content-Type: multipart/signed; boundary="----=_NextPart_000_0057_01CFFE19.585AFFF0"; protocol="application/x-pkcs7-signature"; micalg=SHA1 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.28, 0.0.0000 definitions=2014-11-12_04:2014-11-11,2014-11-12,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 kscore.is_bulkscore=2.2735147098274e-12 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-1411120068 Archived-At: http://mailarchive.ietf.org/arch/msg/vot/lD_j5awVyAxV-KzvOv9xEa7bSb8 Subject: Re: [VoT] vot Digest, Vol 3, Issue 3 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, 12 Nov 2014 07:38:37 -0000 ------=_NextPart_000_0057_01CFFE19.585AFFF0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0058_01CFFE19.585AFFF0" ------=_NextPart_001_0058_01CFFE19.585AFFF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit One of the requirements should be that there be only as many dimensions to the vector as would be actionable by a Relying Party to make an authorization decision. Otherwise, the model is more complex than it needs to be. [Jones, Mark B] Isn't 'authorization' out of scope here? The strawman document does not mention authorization. ------=_NextPart_001_0058_01CFFE19.585AFFF0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

One of the requirements should be that there be only = as many dimensions to the vector as would be actionable by a Relying = Party to make an authorization decision. Otherwise, the model is more = complex than it needs to be.

[Jones, Mark B]

Isn’t ‘authorization’ out of scope here?  The = strawman document does not mention authorization.

------=_NextPart_001_0058_01CFFE19.585AFFF0-- ------=_NextPart_000_0057_01CFFE19.585AFFF0 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 BQCgggI8MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MTExMjA3 MzgyMlowIwYJKoZIhvcNAQkEMRYEFGuht1xGyQ7Hu+AbZpROiTqdNVxmMFsGCSqGSIb3DQEJDzFO MEwwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G CCqGSIb3DQMCAgEoMAcGBSsOAwIaMIG9BgkrBgEEAYI3EAQxga8wgawwgZYxCzAJBgNVBAYTAlVT MUEwPwYDVQQKEzhUaGUgVW5pdmVyc2l0eSBvZiBUZXhhcyBIZWFsdGggU2NpZW5jZSBDZW50ZXIg YXQgSG91c3RvbjFEMEIGA1UEAxM7VGhlIFVuaXZlcnNpdHkgb2YgVGV4YXMgSGVhbHRoIFNjaWVu Y2UgQ2VudGVyIGF0IEhvdXN0b24gQ0ECEQC2CAUBCn9+NClEHZu5j+aOMIG/BgsqhkiG9w0BCRAC CzGBr6CBrDCBljELMAkGA1UEBhMCVVMxQTA/BgNVBAoTOFRoZSBVbml2ZXJzaXR5IG9mIFRleGFz IEhlYWx0aCBTY2llbmNlIENlbnRlciBhdCBIb3VzdG9uMUQwQgYDVQQDEztUaGUgVW5pdmVyc2l0 eSBvZiBUZXhhcyBIZWFsdGggU2NpZW5jZSBDZW50ZXIgYXQgSG91c3RvbiBDQQIRALYIBQEKf340 KUQdm7mP5o4wDQYJKoZIhvcNAQEBBQAEggEAYH39Aim470R5tjYTMTGn50np3f26ofukescWLQJh AgD85ffY626yDVcucsxYE431gUYQpgXotWRuyfhmYvqMmRGLbhhXCXR7o2gYsuJJTZYsjIK3D26z DCMzKi/DjABkoRQ95+5/M9mBxf6ZBD5OdEpRRhdEwc8r6oZe6YcH4KQ58D9Mu7/fkqb7ZTNf/lVb v5E3ohwtXdWNSrhlrpnjvnwm37WGf+LOzpTYxcUW+IGA9vFSlXEvf2xBo452lYxLoJBqmZQ6RD2Q pFN2ikQT3LfddL6RUh8+mV79m1/k41/9Z9RYLyEl+HyjV+BdD9ze4WNpsY6PEAblMumG9xm84QAA AAAAAA== ------=_NextPart_000_0057_01CFFE19.585AFFF0-- From nobody Tue Nov 11 23:59:46 2014 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 376D41A87C1 for ; Tue, 11 Nov 2014 23:59:45 -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 iCr-nq2r9ro7 for ; Tue, 11 Nov 2014 23:59:43 -0800 (PST) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95D0E1A802B for ; Tue, 11 Nov 2014 23:59:43 -0800 (PST) Received: by mail-ig0-f179.google.com with SMTP id r10so2507757igi.0 for ; Tue, 11 Nov 2014 23:59:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:from:date:message-id:subject:to :content-type; bh=V/nW/Kl2nwAT0hGBFwutz6wnm0F8ayv8IGBVowd8cc0=; b=V8AbM0NPd/ppl/CL0sxlcxOyXCTucUgftQiMOBwh/1BkUPc2EBLDzwBuvKAjGkyeh8 +RRTvYxwTWk+AR5+viT2m0/op5bely4SlxCYf/3BlOh97NxBZUoUMQyeNbB6Ga1ss/rQ 4zpy8Y0/nCtslafJN2K1V2im4+t2/8ZStklOS1Ddjaq4KxAauDVQ3uGBqGhIEQmspX8O 6Lmg05rftXcaLqnbOh8QZe7SGP/8Lx3VX+VGv9F237duBwsp66vNb4F7b8aClZPuNtCP U3+SUoNNilhflJuCF08FAH2iY7s0cumgJU0262OyzC3sRZKcZ/qw8HZ0zN+Z8zTia1fA wGWA== X-Received: by 10.51.17.73 with SMTP id gc9mr2643338igd.24.1415779182822; Tue, 11 Nov 2014 23:59:42 -0800 (PST) MIME-Version: 1.0 References: <54628544.8040801@bluepopcorn.net> <38AAF00EA635514CA6667ACA60C7F0A531502DD7@UTHMAIL1.uthouston.edu> From: Nat Sakimura Date: Wed, 12 Nov 2014 07:59:42 +0000 Message-ID: To: "Jones, Mark B" , Jim Fenton , Peter Alterman , "vot@ietf.org" Content-Type: multipart/alternative; boundary=001a1134b8b845f3290507a4c7e7 Archived-At: http://mailarchive.ietf.org/arch/msg/vot/xkiTbulrl0-lKonxDMAbHXY11jQ Subject: Re: [VoT] vot Digest, Vol 3, Issue 3 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, 12 Nov 2014 07:59:45 -0000 --001a1134b8b845f3290507a4c7e7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable IMHO, everybody here should read X.1254 - ISO/IEC 29115 as a starting point. It has got problems, but it still is a good starting point and we do not have to repeat arguing what are there without knowing them. In it, clause 10 lays out threats and controls. One of the biggest problem about the 29115 is that it is too prescriptive as to the controls are concerned. There can be multiple ways of implementing controls and there always are going to be new and more shiny ones. It should have been constructed like 27002 that everything is optional but has to achieve the objectives. (In fact, we did so for authentication phase, but other phases remained pretty prescriptive.) Nat On Wed Nov 12 2014 at 16:38:34 Jones, Mark B wrote: > One of the requirements should be that there be only as many dimensions t= o > the vector as would be actionable by a Relying Party to make an > authorization decision. Otherwise, the model is more complex than it need= s > to be. > > *[Jones, Mark B] * > > *Isn=E2=80=99t =E2=80=98authorization=E2=80=99 out of scope here? The st= rawman document does not > mention authorization.* > --001a1134b8b845f3290507a4c7e7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable IMHO, everybody here should read X.1254 - ISO/IEC 29115 as a starting point= . It has got problems, but it still is a good starting point and we do not = have to repeat arguing what are there without knowing them.=C2=A0
<= br>
In it, clause 10 lays out threats and controls. One of the bi= ggest problem about the 29115 is that it is too prescriptive as to the cont= rols are concerned. There can be multiple ways of implementing controls and= there always are going to be new and more shiny ones. It should have been = constructed like 27002 that everything is optional but has to achieve the o= bjectives.=C2=A0

(In fact, we did so for authentic= ation phase, but other phases remained pretty prescriptive.)=C2=A0

Nat

On Wed Nov 12 2014= at 16:38:34 Jones, Mark B <Mark.B.Jones@uth.tmc.edu> wrote:

One of the requirements should be t= hat there be only as many dimensions to the vector as would be actionable b= y a Relying Party to make an authorization decision. Otherwise, the model i= s more complex than it needs to be.

[Jones, Mark B]

Isn=E2=80=99t =E2=80=98authorization=E2=80=99 out of scope here?=C2= =A0 The strawman document does not mention authorization.

<= /div> --001a1134b8b845f3290507a4c7e7-- From nobody Wed Nov 12 04:16:39 2014 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 A9DCA1A88FA for ; Wed, 12 Nov 2014 04:16:33 -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 miZ8j5_WxJ0I for ; Wed, 12 Nov 2014 04:16:28 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0672.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:672]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D9341A895D for ; Wed, 12 Nov 2014 04:16:27 -0800 (PST) Received: from BN1PR06MB119.namprd06.prod.outlook.com (10.255.204.25) by BN1PR06MB120.namprd06.prod.outlook.com (10.255.204.27) with Microsoft SMTP Server (TLS) id 15.1.16.15; Wed, 12 Nov 2014 12:16:03 +0000 Received: from BN1PR06MB119.namprd06.prod.outlook.com ([169.254.14.195]) by BN1PR06MB119.namprd06.prod.outlook.com ([169.254.14.195]) with mapi id 15.01.0016.006; Wed, 12 Nov 2014 12:16:03 +0000 From: Robin Wilton To: "vot@ietf.org" Thread-Topic: Three things... Thread-Index: AQHP/nJtMse26Hj/EkOKHWAqijtd8Q== Date: Wed, 12 Nov 2014 12:16:03 +0000 Message-ID: <54CF4FE4-003B-4075-BEAD-D0A454E57425@isoc.org> 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] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR06MB120; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:BN1PR06MB120; x-forefront-prvs: 03932714EB x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(479174003)(189002)(377454003)(199003)(22974006)(27574002)(24454002)(48184003)(69234005)(51444003)(2656002)(36756003)(83716003)(31966008)(21056001)(95666004)(2351001)(87936001)(105586002)(106116001)(107886001)(107046002)(106356001)(99286002)(229853001)(2501002)(97736003)(92726001)(92566001)(66066001)(4396001)(20776003)(16236675004)(551934003)(33656002)(64706001)(46102003)(19617315012)(99936001)(120916001)(110136001)(82746002)(54356999)(15975445006)(122556002)(86362001)(50986999)(40100003)(76176999)(19580395003)(19580405001)(101416001)(450100001)(77156002)(77096003)(62966003)(99396003)(104396001); DIR:OUT; SFP:1101; SCL:1; SRVR:BN1PR06MB120; H:BN1PR06MB119.namprd06.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: multipart/signed; boundary="Apple-Mail=_59B60234-D7E1-4916-AABD-CE9F457028E3"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 X-OriginatorOrg: isoc.org Archived-At: http://mailarchive.ietf.org/arch/msg/vot/XgnlZGFcr6mYJ58_XgSjFbFvkpQ Subject: [VoT] Three things... 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, 12 Nov 2014 12:16:34 -0000 --Apple-Mail=_59B60234-D7E1-4916-AABD-CE9F457028E3 Content-Type: multipart/alternative; boundary="Apple-Mail=_97697584-DC96-48F1-8FBA-8855331332A1" --Apple-Mail=_97697584-DC96-48F1-8FBA-8855331332A1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 >=20 > From: Joanne Knight > Subject: Re: [VoT] vot Digest, Vol 3, Issue 3 > Date: 12 November 2014 04:04:29 GMT > To: 'Jim Fenton' , 'Peter Alterman' = , 'Nat Sakimura' > Cc: "'vot@ietf.org'" >=20 >=20 > Greetings All > =20 > I am new to this group so for the benefit of those who do not know me=85= > =20 > I am Joanne Knight (probably the real me but not what you will find on = any official register) ;-) Hi Joanne, and welcome. Unless =93Joanne Knight=94 is actually another = of Colin Wallis=92 personas, in which case, nice try and welcome back. >=20 > =20 > =20 > =20 > From: Jim Fenton [mailto:fenton@bluepopcorn.net]=20 > Sent: Wednesday, 12 November 2014 1:01 p.m. > To: Peter Alterman; Nat Sakimura > Cc: vot@ietf.org > Subject: Re: [VoT] vot Digest, Vol 3, Issue 3 > =20 > Peter, >=20 >=20 > Finally, it sounds like we're talking past each other on the word = "vector". We're using the word in the mathematical sense, and it appears = you're using it in the epidemiological sense. If there's a word here I = have a quibble about, it's "trust=94. IIRC, Leif has already made the point that =93vector=94 was chosen more = or less on the spur of the moment during the Utrecht workshop; looking = at the kinds of thing people are grouping under that term, it feels to = me (as to Peter) that =93factor=94 would serve as well. I know that=92s = not very helpful now that the mailing list already has a V in it, sorry. Unless I misunderstand it, we are talking about =93the things that = contribute, positively or negatively, to the trustworthiness of an = identity assertion=94. This also relates partly to a further comment, = below, on something Peter said. >=20 > On 11/11/14 3:09 PM, Peter Alterman wrote: > Nat et. al. > =20 > Let's not reason backwards from use cases but forwards from expertise. = There are a zillion use cases out there that can be generated for any = model (sort of like a cost/benefit analysis - just tell the analyst what = answer you want and let him/her crank out the sausage). Rather, what are = the legitimate components of an identity assertion; what's the nature of = the relationship among them? Nothing I've seen so far changes my opinion = that there are four variables: strength of identity proofing (measured = against a benchmark that incorporates *both* 800-63 and 29115); = intrinsic resistance of credential type to attack (see prior = benchmarking comment); credential management (how well it addresses the = threat vectors in 29115 and aligns with 800-63 processes, and exchange, = which incorporates mitigation of data in motion threat vectors listed in = 29115 relevant to AuthN.=20 > =20 > Also agree that the AuthN process is not part of determining the = trustworthiness (rat hole warning) of an online identity assertion but = the process of making such a determination. I mostly agree, but I think that the lifecycle of a credential gives us = a good basis for drawing up a shortlist of the things that make the = resulting assertions of identity trustworthy. If you do, you get a very = similar list to the one Nat mentions, and phases that reflect Joanne=92s = comments too. the initial registration/verification/enrolment phase ("proofing") the issue of credentials (encapsulating attributes and binding the = result to the individual somehow) presentation of the credentials over time validation of the credentials (a.k.a. Authentication)=20 other lifecycle bits like revocation/amendment/destruction (Nat makes the point, below, that most RPs don=92t care about identity = proofing. I=92m sure he is right, but since we=92re trying to tease out = all the things that underpin the reliability of an identity assertion, I = think we need to be more explicit; RPs don=92t care because they will = assume either that proofing has been done adequately, or that if they = rely on a valid credential that has been incorrectly issued, the = liability will rest with the issuer. But I=92d argue that those are = trust factors too.) Last: I=92m worried that Peter=92s final sentence above is open to = misinterpretation. If any of the phases I=92ve just listed is not = reliable, it undermines trust in the outcome (which is, ideally, = justified reliance on an assertion of identity). If the authentication = step is trivial, cursory, superficial, spoofable, insecure, call it what = you will - then someone relying on its outcome could be mistaken. > =20 > Finally, scalar is not vector. C'mon guys, give an old man a break. = We're talking factors, not vectors. As an example, a threat vector is an = identity assertion threat aimed at someone or some process: it has = strength and it has direction. > =20 > regards, > =20 > Peter > =20 >=20 > ------------------------------------------------------------ > Peter Alterman, Ph.D. > Chief Operating Officer > SAFE-BioPharma Association > cell: 301-943-7452 >=20 > =20 > On Tue, Nov 11, 2014 at 5:28 PM, Nat Sakimura = wrote: > In many cases, people do not care about Identity Proofing. As long as = the credential management and after is done right, it should not matter = in many commercial use case. So, in the previous expression, to some of = my use cases, I am indifferent with (1, 2, 2, 2) and (4, 2, 2, 2). In = the traditional SP800-63 case, however, the former is 0 and later is 2, = making (1, 2, 2, 2) and (1, 1, 1, 1) indifferent, losing the information = I was interested in. Also, I may want to accept (1,2,2,1) on a intranet = while I am only willing to accept (1,2,2,2) over the internet. Justin = was arguing to collapse the middle two, and that may well be a good = simplification. In this case, I still care those three dimensions = instead of four.=20 > =20 > As to the attribute reliability is concerned, the room concluded that = it is out of scope for VoT for now, that we should only concentrate on = entity authentication assurance. The quality of attribute should be = treated more like a metadata about each attribute instead.=20 > =20 > For the Enrollment, Credential Management, Authentication, refer to = ISO/IEC 29115 or ITU-T X.1254, which are almost identical apart from the = formatting and 3 words. X.1254 is freely available. You can find them = here: https://www.itu.int/rec/T-REC-X.1254-201209-I/en > =20 > Nat > =20 > =20 > On Wed Nov 12 2014 at 6:53:11 Jim Fenton = wrote: > One of the requirements should be that there be only as many = dimensions to the vector as would be actionable by a Relying Party to = make an authorization decision. Otherwise, the model is more complex = than it needs to be. >=20 > I'm not sure I understand how Enrollment, Credential Management, = Authentication, and Assertion Transmission are defined (if that was = discussed on the list, I'd appreciate a pointer to it). But as a relying = party, if the quality of an attribute I receive is limited by something, = I probably don't care whether it was because the credential management = or the assertion transmission was the cause. >=20 > So if this retains 4 dimensions, there should be use cases that = justify the need for 4. I can do that for 2 dimensions (authentication = strength/attribute reliability) by considering uses like strong = pseudonymous authentication with a trustable assertion of an attribute = like age. I don't have any good examples for more than 2. >=20 >=20 > -Jim >=20 >=20 > On 11/11/14 1:34 PM, Nat Sakimura wrote: > We had a bar-bof last night at IETF 91.=20 >=20 > There was a discussion that perhaps instead of three dimension = "Identity Proofing / Credential Binding / Assertion Transmission", = perhaps 4 dimension "Enrollment/Credential = management/Authentication/Assertion Transmission" is more appropriate. = The reason was that Identity Proofing is only a step in Enrollment, = Credential Binding is only a step in Credential Management, and the use = of credential, i.e., Authentication, is important enough to separate out = from Credential Management. Then, there followed a lengthy discussion = about whether to pull Authentication out.=20 > =20 > As to the "vector" is concerned, it indeed seem to be a vector to me = in the sense that:=20 > =20 > v =3D (e, c, a, t)=20 > where e:=3Dscalar value for expressing Enrollment quality > c:=3Dscalar value for expressing Credential Management quality > a:=3Dscalar value for expressing Authentication quality > t:=3Dscalar value for expressing Assertion Transmission quality.=20 > =20 > There was discussion on how to obtain these values as well. The room = opinion was that we should define the response format and then use it to = define the request format.=20 > =20 > Also, there was a discussion around the nature of the value of each = scalar above, and the granularity desired.=20 > We were not even sure if the values are going to be an ordered set. = Everybody agreed that simplicity is a requirement for widespread = adoption. If granularity were sought, then it should be defined as a = subset of parent value so that implementation that do not care about = these can safely ignore them.=20 > =20 > Apart from the above, importance of the operational quality of IdPs = were expressed. This seem to be the quality which should be transmitted = not per authentication transaction but separately, perhaps from = .well-known resource.=20 > =20 > FYI, the room also had the opinion that we should not get into the = "quality of attributes" in general but focus only to the entity = authentication, at least for this round.=20 > =20 > Cheers,=20 > =20 > Nat > =20 > =20 > =20 > =20 > On Wed Nov 12 2014 at 5:25:56 Peter Alterman = wrote: > Pardon me not diddling with the strawman. A quick read generated the = comments following. Hope they are helpful in evolving the document. > =20 > What is immediately missing is a value for the quality of the = credential technology because some credential types are inherently less = secure - or risk mitigating - than others.=20 > =20 > My second observation is that it is not yet clear to me why these = elements are called vectors. Vectors are expressions of quantities in = spacio-temporal directions. So far I see three (and the fourth I = recommend here) factors. In order to consider them vectors, please show = me a plot on a graph and label the axes and the measurement units. > =20 > My third observation is that I do not see any straightforward way for = the factors to be collapsed. There are no approaches to do so presented, = either. First question to ask here is whether the ecosystem will need to = deploy both a transmission protocol and a receiving protocol? If the = methodology requires broad uptake of RP software in order to decode the = transmitted factors, the Hydra is unleashed. > =20 > thanks, > =20 > Peter >=20 > ------------------------------------------------------------ > Peter Alterman, Ph.D. > Chief Operating Officer > SAFE-BioPharma Association > cell: 301-943-7452 >=20 > =20 > On Tue, Nov 11, 2014 at 3:02 PM, 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. Document in GitHub (Richer, Justin P.) >=20 >=20 > ---------- Forwarded message ---------- > From: "Richer, Justin P." > To: "vot@ietf.org" > Cc:=20 > Date: Mon, 10 Nov 2014 21:07:53 +0000 > Subject: [VoT] Document in GitHub > I've started the work of translating much of my original strawman = document to Markdown and pushing it to GitHub so that we can start = taking edits via pull request: >=20 > = https://github.com/vectorsoftrust/strawman/blob/master/VectorsOfTrust.md >=20 > Clone and fork away! >=20 > -- Justin >=20 >=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://www.ietf.org/mailman/listinfo/vot > =20 > =20 >=20 >=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=_97697584-DC96-48F1-8FBA-8855331332A1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

From: Joanne Knight <Joanne.Knight@dia.govt.nz>
Subject: Re: [VoT] vot Digest, Vol 3, Issue = 3
Date: 12 November 2014 04:04:29 = GMT
To: 'Jim Fenton' <fenton@bluepopcorn.net>, 'Peter = Alterman' <palterman@safe-biopharma.org>, 'Nat Sakimura' <sakimura@gmail.com>


Greetings = All
 
I am new to this group so for the benefit of those = who do not know me=85
 
I am Joanne Knight = (probably the real me but not what you will find on any official = register) = ;-)

Hi Joanne, = and welcome. Unless =93Joanne Knight=94 is actually another of Colin = Wallis=92 personas, in which case, nice try and welcome = back.



 
 
 
From: Jim = Fenton [mailto:fenton@bluepopcorn.net] 
Sent: Wednesday, 12 November 2014 = 1:01 p.m.
To: Peter Alterman; Nat = Sakimura
Cc: vot@ietf.org
Subject: Re: [VoT] vot Digest, Vol = 3, Issue 3
 
Peter,


Finally, it sounds like we're talking past = each other on the word "vector". We're using the word in the = mathematical sense, and it appears you're using it in the = epidemiological sense. If there's a word here I have a quibble about, = it's = "trust=94.

IIRC, Leif has already made the point that =93vector=94 was = chosen more or less on the spur of the moment during the Utrecht = workshop; looking at the kinds of thing people are grouping under that = term, it feels to me (as to Peter) that =93factor=94 would serve as = well. I know that=92s not very helpful now that the mailing list already = has a V in it, sorry.

Unless I misunderstand = it, we are talking about =93the things that contribute, positively or = negatively, to the trustworthiness of an identity assertion=94. This = also relates partly to a further comment, below, on something Peter = said.





On 11/11/14 3:09 PM, Peter Alterman = wrote:
Nat et. = al.
 
Let's = not reason backwards from use cases but forwards from expertise. There = are a zillion use cases out there that can be generated for any model = (sort of like a cost/benefit analysis - just tell the analyst what = answer you want and let him/her crank out the sausage). Rather, what are = the legitimate components of an identity assertion; what's the nature of = the relationship among them? Nothing I've seen so far changes my opinion = that there are four variables: strength of identity proofing (measured = against a benchmark that incorporates *both* 800-63 and 29115); = intrinsic resistance of credential type to attack (see prior = benchmarking comment); credential management (how well it addresses the = threat vectors in 29115 and aligns with 800-63 processes, and exchange, = which incorporates mitigation of data in motion threat vectors listed in = 29115 relevant to AuthN. 
 
 Also agree that the AuthN process is not part = of determining the trustworthiness (rat hole warning) of an online = identity assertion but the process of making such a = determination.

I mostly agree, but I think that the lifecycle of a = credential gives us a good basis for drawing up a shortlist of the = things that make the resulting assertions of identity trustworthy. If = you do, you get a very similar list to the one Nat mentions, and phases = that reflect Joanne=92s comments too.

  • the initial = registration/verification/enrolment phase ("proofing")
  • the issue = of credentials (encapsulating attributes and binding the result to the = individual somehow)
  • presentation of the credentials over = time
  • validation of the credentials (a.k.a. = Authentication) 
  • other lifecycle bits like = revocation/amendment/destruction

(Nat makes = the point, below, that most RPs don=92t care about identity proofing. = I=92m sure he is right, but since we=92re trying to tease out all the = things that underpin the reliability of an identity assertion, I think = we need to be more explicit; RPs don=92t care because they will assume = either that proofing has been done adequately, or that if they rely on a = valid credential that has been incorrectly issued, the liability will = rest with the issuer. But I=92d argue that those are trust factors = too.)

Last: I=92m worried that Peter=92s final = sentence above is open to misinterpretation. If any of the phases I=92ve = just listed is not reliable, it undermines trust in the outcome (which = is, ideally, justified reliance on an assertion of identity). If the = authentication step is trivial, cursory, superficial, spoofable, = insecure, call it what you will - then someone relying on its outcome = could be mistaken.


 
Finally, scalar is not vector. C'mon guys, give an old man a = break. We're talking factors, not vectors. As an example, a threat = vector is an identity assertion threat aimed at someone or some process: = it has strength and it has direction.
 
regards,
 
Peter
 

------------------------------------------------------------<= /o:p>
Peter Alterman, = Ph.D.
Chief Operating = Officer
SAFE-BioPharma Association

cell: = 301-943-7452

 
On = Tue, Nov 11, 2014 at 5:28 PM, Nat Sakimura <sakimura@gmail.com> = wrote:
In many cases, = people do not care about Identity Proofing. As long as the credential = management and after is done right, it should not matter in many = commercial use case. So, in the previous expression, to some of my use = cases, I am indifferent with (1, 2, 2, 2) and (4, 2, 2, 2). In the = traditional SP800-63 case, however, the former is 0 and later is 2, = making (1, 2, 2, 2) and (1, 1, 1, 1) indifferent, losing the information = I was interested in. Also, I may want to accept (1,2,2,1) on a intranet = while I am only willing to accept (1,2,2,2) over the internet. Justin = was arguing to collapse the middle two, and that may well be a good = simplification. In this case, I still care those three dimensions = instead of four. 
 
As to = the attribute reliability is concerned, the room concluded that it is = out of scope for VoT for now, that we should only concentrate on entity = authentication assurance. The quality of attribute should be treated = more like a metadata about each attribute = instead. 
 
For = the Enrollment, Credential Management, Authentication, refer to = ISO/IEC 29115 or ITU-T X.1254, which are almost identical apart from the = formatting and 3 words. X.1254 is freely available. You can find them = here: https://www.itu.int/rec/T-REC-X.1254-201209-I/en
 
Nat
 
 
On = Wed Nov 12 2014 at 6:53:11 Jim Fenton <fenton@bluepopcorn.net> = wrote:
One of the = requirements should be that there be only as many dimensions to the = vector as would be actionable by a Relying Party to make an = authorization decision. Otherwise, the model is more complex than it = needs to be.

I'm not sure I understand how Enrollment, Credential = Management, Authentication, and Assertion Transmission are defined (if = that was discussed on the list, I'd appreciate a pointer to it). But as = a relying party, if the quality of an attribute I receive is limited by = something, I probably don't care whether it was because the credential = management or the assertion transmission was the cause.

So if = this retains 4 dimensions, there should be use cases that justify the = need for 4. I can do that for 2 dimensions (authentication = strength/attribute reliability) by considering uses like strong = pseudonymous authentication with a trustable assertion of an attribute = like age. I don't have any good examples for more than = 2.


-Jim


On 11/11/14 1:34 PM, Nat Sakimura = wrote:

We had a = bar-bof last night at IETF 91. 

There was a discussion that perhaps instead of three = dimension "Identity Proofing / Credential Binding / Assertion = Transmission", perhaps 4 dimension "Enrollment/Credential = management/Authentication/Assertion Transmission" is more appropriate. = The reason was that Identity Proofing is only a step in Enrollment, = Credential Binding is only a step in Credential Management, and the use = of credential, i.e., Authentication, is important enough to separate out = from Credential Management. Then, there followed a lengthy discussion = about whether to pull Authentication = out. 
 
As to = the "vector" is concerned, it indeed seem to be a vector to me in the = sense that: 
 
v =3D = (e, c, a, t) 
 where e:=3Dscalar value for expressing Enrollment = quality
 c:=3Dscalar value for expressing Credential Management = quality
 a:=3Dscalar value for expressing Authentication = quality
 t:=3Dscalar value for expressing Assertion Transmission = quality. 
 
There = was discussion on how to obtain these values as well. The room opinion = was that we should define the response format and then use it to define = the request format. 
 
Also, = there was a discussion around the nature of the value of each scalar = above, and the granularity = desired. 
We = were not even sure if the values are going to be an ordered set. = Everybody agreed that simplicity is a requirement for widespread = adoption. If granularity were sought, then it should be defined as a = subset of parent value so that implementation that do not care about = these can safely ignore them. 
 
Apart from the above, importance of the operational = quality of IdPs were expressed. This seem to be the quality which should = be transmitted not per authentication transaction but separately, = perhaps from .well-known resource. 
 
FYI, the room also had the opinion that we should = not get into the "quality of attributes" in general but focus only to = the entity authentication, at least for this = round. 
 
Cheers, 
 
Nat
 
 
 
 
On = Wed Nov 12 2014 at 5:25:56 Peter Alterman <palterman@safe-biopharma.org> = wrote:
Pardon me not = diddling with the strawman. A quick read generated the comments = following. Hope they are helpful in evolving the = document.
 
What = is immediately missing is a value for the quality of the credential = technology because some credential types are inherently less secure - or = risk mitigating - than others. 
 
My second observation is that it is not yet clear to = me why these elements are called vectors. Vectors are expressions of = quantities in spacio-temporal directions. So far I see three (and the = fourth I recommend here) factors. In order to consider them vectors, = please show me a plot on a graph and label the axes and the measurement = units.
 
My = third observation is that I do not see any straightforward way for the = factors to be collapsed. There are no approaches to do so presented, = either. First question to ask here is whether the ecosystem will need to = deploy both a transmission protocol and a receiving protocol? If the = methodology requires broad uptake of RP software in order to decode the = transmitted factors, the Hydra is = unleashed.
 
thanks,
 
Peter

------------------------------------------------------------<= /o:p>
Peter Alterman, = Ph.D.
Chief Operating = Officer
SAFE-BioPharma Association

cell: 301-943-7452

 
On = Tue, Nov 11, 2014 at 3:02 PM, <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. Document in GitHub (Richer, Justin P.)


---------- = Forwarded message ----------
From: "Richer, Justin P." <jricher@mitre.org>
To: "vot@ietf.org" <vot@ietf.org>
Cc: 
Date: Mon, 10 Nov = 2014 21:07:53 +0000
Subject: [VoT] Document in GitHub
I've = started the work of translating much of my original strawman document to = Markdown and pushing it to GitHub so that we can start taking edits via = pull request:

  https://github.com/vectorsoftrust/strawman/blob/master/Vectors= OfTrust.md

Clone and fork away!

 -- = Justin


_______________________________________________
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
=
 


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

= --Apple-Mail=_97697584-DC96-48F1-8FBA-8855331332A1-- --Apple-Mail=_59B60234-D7E1-4916-AABD-CE9F457028E3 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----- iEYEARECAAYFAlRjT+gACgkQx1kEWLxmyT30GgCcDAAv/t7v+0O+jYv7g/LjLyTM AkoAmwfabOK1pZHZ3Qv2akR/kubk7HWs =Ef2m -----END PGP SIGNATURE----- --Apple-Mail=_59B60234-D7E1-4916-AABD-CE9F457028E3-- From nobody Wed Nov 12 07:33:54 2014 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 C8FA11A1AFB for ; Wed, 12 Nov 2014 07:33:51 -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 nyCT50KPJZB4 for ; Wed, 12 Nov 2014 07:33:49 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0755.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::755]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D5CA1A036F for ; Wed, 12 Nov 2014 07:33:47 -0800 (PST) Received: from BL2FFO11FD059.protection.gbl (10.173.160.31) by BL2FFO11HUB061.protection.gbl (10.173.161.161) with Microsoft SMTP Server (TLS) id 15.1.6.13; Wed, 12 Nov 2014 15:33:24 +0000 Received: from cio-krc-pf07.osuad.osu.edu (164.107.81.214) by BL2FFO11FD059.mail.protection.outlook.com (10.173.161.187) with Microsoft SMTP Server (TLS) id 15.1.6.13 via Frontend Transport; Wed, 12 Nov 2014 15:33:24 +0000 Received: from CIO-TNC-HT05.osuad.osu.edu (cio-tnc-ht05.osuad.osu.edu [164.107.81.168]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by cio-krc-pf07.osuad.osu.edu (Postfix) with ESMTPS id 4BE0D500036; Wed, 12 Nov 2014 10:33:24 -0500 (EST) Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-TNC-HT05.osuad.osu.edu ([fe80::d0be:603:484c:5a2f%10]) with mapi id 14.03.0174.001; Wed, 12 Nov 2014 10:33:23 -0500 From: "Cantor, Scott" To: Robin Wilton , "vot@ietf.org" Thread-Topic: [VoT] Three things... Thread-Index: AQHP/o3+kyTw6Wp1Y0u6yXjL2DR0vw== Date: Wed, 12 Nov 2014 15:33:22 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [140.254.59.82] Content-Type: text/plain; charset="utf-8" Content-ID: <7047EED567CFD64AB959EE68E72FDCDE@osu.edu> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:164.107.81.214; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(438002)(199003)(377454003)(479174003)(24454002)(189002)(51704005)(106466001)(54356999)(92726001)(4396001)(21056001)(19580395003)(88552001)(33656002)(93346002)(96286002)(20776003)(23676002)(19580405001)(86362001)(47776003)(44976005)(66066001)(95666004)(36756003)(75432002)(50986999)(109096001)(82746002)(6806004)(92566001)(50466002)(120916001)(87936001)(31966008)(107046002)(2501002)(83716003)(89122001)(77096003)(77156002)(64706001)(107886001)(46102003)(90282001)(99396003)(106116001)(2656002)(551544002)(62966003)(104396001)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2FFO11HUB061; H:cio-krc-pf07.osuad.osu.edu; FPR:; MLV:sfv; PTR:cio-krc-pf07.osuad.osu.edu; A:1; MX:1; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BL2FFO11HUB061; X-Exchange-Antispam-Report-CFA: BCL:0; PCL:0; RULEID:(1)(2); SRVR:BL2FFO11HUB061; X-Forefront-PRVS: 03932714EB Received-SPF: Pass (protection.outlook.com: domain of osu.edu designates 164.107.81.214 as permitted sender) receiver=protection.outlook.com; client-ip=164.107.81.214; helo=cio-krc-pf07.osuad.osu.edu; Authentication-Results: spf=pass (sender IP is 164.107.81.214) smtp.mailfrom=cantor.2@osu.edu; X-Exchange-Antispam-Report-CFA: BCL:0;PCL:0;RULEID:;SRVR:BL2FFO11HUB061; X-OriginatorOrg: osu.edu Archived-At: http://mailarchive.ietf.org/arch/msg/vot/sA0-rvuAxSd0LrIGED7SGEnm90Y Subject: Re: [VoT] Three things... 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, 12 Nov 2014 15:33:52 -0000 T24gMTEvMTIvMTQsIDEyOjE2IFBNLCAiUm9iaW4gV2lsdG9uIiA8d2lsdG9uQGlzb2Mub3JnPiB3 cm90ZToNCj4NCj4oTmF0IG1ha2VzIHRoZSBwb2ludCwgYmVsb3csIHRoYXQgbW9zdCBSUHMgZG9u 4oCZdCBjYXJlIGFib3V0IGlkZW50aXR5IA0KPnByb29maW5nLiBJ4oCZbSBzdXJlIGhlIGlzIHJp Z2h0LCBidXQgc2luY2Ugd2XigJlyZSB0cnlpbmcgdG8gdGVhc2Ugb3V0IGFsbCANCj50aGUgdGhp bmdzIHRoYXQgdW5kZXJwaW4gdGhlIHJlbGlhYmlsaXR5IG9mIGFuIGlkZW50aXR5IGFzc2VydGlv biwgSSANCj50aGluayB3ZSBuZWVkIHRvIGJlIG1vcmUgZXhwbGljaXQ7IFJQcyBkb27igJl0IGNh cmUgYmVjYXVzZSB0aGV5IHdpbGwgDQo+YXNzdW1lIGVpdGhlciB0aGF0IHByb29maW5nIGhhcyBi ZWVuIGRvbmUgYWRlcXVhdGVseSwgb3IgdGhhdCBpZiB0aGV5IA0KPnJlbHkgb24gYSB2YWxpZCBj cmVkZW50aWFsIHRoYXQgaGFzIGJlZW4gaW5jb3JyZWN0bHkgaXNzdWVkLCB0aGUgDQo+bGlhYmls aXR5IHdpbGwgcmVzdCB3aXRoIHRoZSBpc3N1ZXIuIEJ1dCBJ4oCZZCBhcmd1ZSB0aGF0IHRob3Nl IGFyZSB0cnVzdCANCj5mYWN0b3JzIHRvby4pDQoNClRoZSBtb3N0IGNvbW1vbiByZWFzb24gaXMg dGhhdCBwcm9vZmluZyBpcyBkb25lIGJ5IHNvbWVib2R5IGVsc2UsIGVpdGhlciBhIA0KdXNlciBv ZiB0aGUgc2VydmljZSBvciB0aGUgUlAgb3BlcmF0b3IgaXRzZWxmLiBJdCdzIG91dHNpZGUgdGhl IHNjb3BlIG9mIA0KdGhlIGlkZW50aXR5IGFzc2VydGlvbi9leGNoYW5nZS4NCg0KVGhlIGJ5LWZh ciBtb3N0IGNvbW1vbiBjYXNlIGluIHRoZSB3b3JsZCB0b2RheSBpcyB0aGF0IHJlc291cmNlcyBh cmUgDQphdXRob3JpemVkIG9uIHRoZSBiYXNpcyBvZiBpZGVudGlmaWVycyB3aGljaCBvbmx5IHRo ZSB1c2VycyBvZiBhbiANCmFwcGxpY2F0aW9uIGFjdHVhbGx5IGNvbm5lY3QgdG8gcmVhbCBwZW9w bGUuIFRoZSBhcHBsaWNhdGlvbiAob3IgdGhlIFJQIGlmIA0KeW91IGxpa2UpIGhhcyBubyBpbnRl cmVzdCBpbiB3aG8gcGVvcGxlIGFyZSB3aGF0c29ldmVyLCBvbmx5IHRoYXQgdGhlIA0KdXNlcnMg b2YgdGhhdCBzeXN0ZW0gaGF2ZSBlbm91Z2ggaW5mb3JtYXRpb24gdG8gY29ubmVjdCBpZGVudGl0 aWVzIHRvIHRoZSANCnJ1bGVzIHRoZXkgY3JlYXRlLg0KDQpUaGUgbW9zdCBwcmVzc2luZyBwcm9i bGVtIHdpdGggODAwLTYzLWRlcml2ZWQgc2NoZW1lcyBpcyB0aGF0IHRoZXkgDQpvdmVyLWVtcGhh c2l6ZSBpZGVudGl0eSBwcm9vZmluZyBhbmQgb3Zlci1lbXBoYXNpemUgcGFzc3dvcmRzLiBUaGUg bW9zdCANCmNyaXRpY2FsIG5lZWQgdG9kYXkgaXMgdG8gaGF2ZSBhIHdheSB0byBleHByZXNzICJu byBwcm9vZmluZywgDQpzdHJvbmdlci10aGFuLXBhc3N3b3JkIGF1dGhlbnRpY2F0aW9uIi4gVGhl IGVmZm9ydCBoZXJlIHdhcyBwcmltYXJpbHkgdG8gDQp0ZWFzZSBvdXQgaG93IHRvIGV4cHJlc3Mg dGhhdCBzaW1wbHkgd2l0aG91dCBsb3NpbmcgdGhlIGNhcGFjaXR5IHRvIA0KYWRkcmVzcyBvdGhl ciBjYXNlcy4NCg0KLS0gU2NvdHQNCg0K From nobody Wed Nov 12 07:45:57 2014 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 5CC1E1A1AE4 for ; Wed, 12 Nov 2014 07:45:55 -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, 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 L4nv1p6V3DeX for ; Wed, 12 Nov 2014 07:45:53 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0654.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:654]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4ED2F1A1AB2 for ; Wed, 12 Nov 2014 07:45:53 -0800 (PST) Received: from BN1PR06MB119.namprd06.prod.outlook.com (10.255.204.25) by BN1PR06MB119.namprd06.prod.outlook.com (10.255.204.25) with Microsoft SMTP Server (TLS) id 15.1.16.15; Wed, 12 Nov 2014 15:45:24 +0000 Received: from BN1PR06MB119.namprd06.prod.outlook.com ([169.254.14.195]) by BN1PR06MB119.namprd06.prod.outlook.com ([169.254.14.195]) with mapi id 15.01.0016.006; Wed, 12 Nov 2014 15:45:24 +0000 From: Robin Wilton To: "Cantor, Scott" Thread-Topic: [VoT] Three things... Thread-Index: AQHP/o3+kyTw6Wp1Y0u6yXjL2DR0v5xdIrSA Date: Wed, 12 Nov 2014 15:45:24 +0000 Message-ID: <12B80039-A4F9-481C-900B-CE56EFA12C3B@isoc.org> 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] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR06MB119; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:BN1PR06MB119; x-forefront-prvs: 03932714EB x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(199003)(189002)(24454002)(51704005)(377454003)(479174003)(50986999)(99936001)(21056001)(120916001)(99396003)(122556002)(107046002)(95666004)(76176999)(99286002)(54356999)(20776003)(64706001)(77156002)(62966003)(66066001)(40100003)(77096003)(36756003)(106356001)(106116001)(105586002)(97736003)(551544002)(101416001)(2171001)(2656002)(83716003)(31966008)(33656002)(87936001)(46102003)(4396001)(110136001)(92726001)(92566001)(86362001)(82746002)(19580395003)(19580405001)(104396001)(7059030); DIR:OUT; SFP:1101; SCL:1; SRVR:BN1PR06MB119; H:BN1PR06MB119.namprd06.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/signed; boundary="Apple-Mail=_ED50B59D-62CB-4967-BB0E-A0BD4EF1C5A4"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 X-OriginatorOrg: isoc.org Archived-At: http://mailarchive.ietf.org/arch/msg/vot/2OKWCSnxI7GWxxC1B4umrypauOM Cc: "vot@ietf.org" Subject: Re: [VoT] Three things... 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, 12 Nov 2014 15:45:55 -0000 --Apple-Mail=_ED50B59D-62CB-4967-BB0E-A0BD4EF1C5A4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 12 Nov 2014, at 15:33, Cantor, Scott wrote: > On 11/12/14, 12:16 PM, "Robin Wilton" wrote: >>=20 >> (Nat makes the point, below, that most RPs don=92t care about = identity=20 >> proofing. I=92m sure he is right, but since we=92re trying to tease = out all=20 >> the things that underpin the reliability of an identity assertion, I=20= >> think we need to be more explicit; RPs don=92t care because they will=20= >> assume either that proofing has been done adequately, or that if they=20= >> rely on a valid credential that has been incorrectly issued, the=20 >> liability will rest with the issuer. But I=92d argue that those are = trust=20 >> factors too.) >=20 > The most common reason is that proofing is done by somebody else, = either a=20 > user of the service or the RP operator itself. It's outside the scope = of=20 > the identity assertion/exchange. Right=85 it=92s outside the scope, but it=92s a trust factor that=92s = upstream of any subsequent authentication. If it is faulty, the = downstream pollution needs to end up in someone=92s risk assessment. >=20 > The by-far most common case in the world today is that resources are=20= > authorized on the basis of identifiers which only the users of an=20 > application actually connect to real people. The application (or the = RP if=20 > you like) has no interest in who people are whatsoever, only that the=20= > users of that system have enough information to connect identities to = the=20 > rules they create. OK - understood=85 and I think this goes to the remarks Joanne made = about the different perspective when one comes at this from a background = of =93government=94 credential issue. >=20 > The most pressing problem with 800-63-derived schemes is that they=20 > over-emphasize identity proofing and over-emphasize passwords. The = most=20 > critical need today is to have a way to express "no proofing,=20 > stronger-than-password authentication". The effort here was primarily = to=20 > tease out how to express that simply without losing the capacity to=20 > address other cases. That=92s a very useful requirement to tease out [and pin to the = cork-board=85]. When you say =93no proofing=94, then, do you mean none at all, or = proofing which is not reflected in any way in the authentication = request? I think the former corresponds to the way Dick Hardt *originally* = described the OpenID concept (in about 2007=85 i.e. no prior = relationship between an IDP and an RP, just the passing of an = authentication token), and the latter corresponds to =93authentication = with no LoA expressed or implied to the RP=94. >=20 > -- Scott >=20 --Apple-Mail=_ED50B59D-62CB-4967-BB0E-A0BD4EF1C5A4 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----- iEYEARECAAYFAlRjgPkACgkQx1kEWLxmyT3WtwCdFapvcCBJF2OMz6XQBuzTyMgA VUcAoKUmNfXZhsqCGDfQ8E1lKtxZN90k =9IP9 -----END PGP SIGNATURE----- --Apple-Mail=_ED50B59D-62CB-4967-BB0E-A0BD4EF1C5A4-- From nobody Wed Nov 12 07:55:49 2014 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 92F821A1BDD for ; Wed, 12 Nov 2014 07:55:46 -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 mQZpfWpJm-V1 for ; Wed, 12 Nov 2014 07:55:39 -0800 (PST) Received: from mail-ob0-f169.google.com (mail-ob0-f169.google.com [209.85.214.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F24EB1A1BAE for ; Wed, 12 Nov 2014 07:55:38 -0800 (PST) Received: by mail-ob0-f169.google.com with SMTP id va2so9431681obc.0 for ; Wed, 12 Nov 2014 07:55:38 -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=UpHi9EehE/J09SNiZxCXo6ndB2IiQPEkcahI92zgjMY=; b=eQHgc4K9N0/zpLhTuYK8vwWPdikoNiufxR4gtSF9ossoYC8MqfVEpDbVz6GUTu/RMI S9rqTm5icqnH/o3sQLIFm7rWeN4ViAmkFvKvhuKdfkbpv2JwmtPGJaanHzUGuKg4ydhc 6YgulebON8ziqpLfMtegO7GUYRRml+n8me+ofT3TmW6dXKXbQSjrwXnm6eihI8F7KrrO JVJSB6WS781WJBiFghUAWP0yueCiQsQgc56CMYuNAPdV9/uEcaQfFd79YtFvhnb0HEvA AYa9SyyzIBhwW0/fnOcgtIfbUjfqug/z+imgD6x03ahPaWq8E0sbVx4Nl8b25T7N7bhm JZDw== X-Gm-Message-State: ALoCoQmTZeXKAqheEGQetgVMTRfYRqD9YELjqr4J5E7Jl7KwUqi7BqtoHWtc6Nt7lyhECcPlpR8I MIME-Version: 1.0 X-Received: by 10.182.245.225 with SMTP id xr1mr39413043obc.13.1415807737939; Wed, 12 Nov 2014 07:55:37 -0800 (PST) Received: by 10.202.187.70 with HTTP; Wed, 12 Nov 2014 07:55:37 -0800 (PST) In-Reply-To: References: Date: Wed, 12 Nov 2014 10:55:37 -0500 Message-ID: From: Peter Alterman To: vot@ietf.org Content-Type: multipart/alternative; boundary=001a11c1c9704a66f60507ab6d0e Archived-At: http://mailarchive.ietf.org/arch/msg/vot/KW9zIWKPJQVfzp5Z_9tV-_6QfkM Subject: Re: [VoT] vot Digest, Vol 3, Issue 11 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, 12 Nov 2014 15:55:46 -0000 --001a11c1c9704a66f60507ab6d0e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Joanne. Thanks for the shout out. Here are a few thoughts on the various comments I read over morning coffee: first, I use vector in the Physics 101 sense, Nat, but I will now leave this annoyance behind and allow you the terminology you feel comfortable using. (Yes, before I got all these pesky literature degrees I majored in physics and even attended lectures on chirality by C.N. Yang.) Next, before addressing the quite legitimate question of what we mean by extended attributes, etc., we must resist reinventing/re-conceiving operational models. In principle the set of attributes required by a RP may vary from case to case but there already exists a vast operating ecosystem that has already determined what that set of attributes is and how to deal with it. I resist any attempt to fiddle with that, while I am open to new, useful, practical ways to measure identity attributes and to express them. Many use cases care not a whit for this set, many will want others, as Nat has described (I agree we are in that strange window of argumentative mutual agreement). Currently, this is handled on a relationship-by-relationship basis with attributes that are not included in the generic identity attribute set or which are included but ignored by a general-purpose AuthN process. Extended attributes are the kitchen sink of online AuthN + AuthZ and they can consist of any unit of data about a natural person or a thing. To avoid the rat hole, simply accept the fact that there is a widely-used set of personal (or machine or code) attributes generally accepted as identity-asserting attributes and move on. Other attributes simply add to the utility of the online identity assertion and beg a universal method of expression. +1 on the comment that RPs may have little or no interest in an online identity assertion reliability rating of {3:1:2:4}. This is, to me, the place where the theoretical crosses the line to useless. The social domain cares less than nothing about any of this, the e-commerce domain cares about the history of my credit card account paying for things bought online, governments and financial institutions need high assurances of identity addressed by ETSI QCP and Fed PKI and FICAM. While I do appreciate the work that GTRI has done under grant from NSTIC to decompose AuthN, I think it results in a conceptual model that doesn't align with the needs of the real world. Now, show me a way to collapse {3:1:2:4} into something an e-commerce or e-gov RP can use and I'm all on board. Preferably using existing tools such as SAML, XACML, WS-Fed, etc. Finally, regarding use cases: I thank you Jim for your desire to simplify all this. I believe that use cases are valuable to test models, not to build them. Too often they are misused for the latter, not the former, IMO, and that leads to destructive stuff like a health care group lobbying NIST to define an LOA of 2.5 to satisfy the use cases they created. That's all I am saying. regards, Peter ------------------------------------------------------------ Peter Alterman, Ph.D. Chief Operating Officer SAFE-BioPharma Association cell: 301-943-7452 On Wed, Nov 12, 2014 at 7:16 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: vot Digest, Vol 3, Issue 3 (Nat Sakimura) > 2. Three things... (Robin Wilton) > > > ---------- Forwarded message ---------- > From: Nat Sakimura > To: "Jones, Mark B" , Jim Fenton < > fenton@bluepopcorn.net>, Peter Alterman , " > vot@ietf.org" > Cc: > Date: Wed, 12 Nov 2014 07:59:42 +0000 > Subject: Re: [VoT] vot Digest, Vol 3, Issue 3 > IMHO, everybody here should read X.1254 - ISO/IEC 29115 as a starting > point. It has got problems, but it still is a good starting point and we = do > not have to repeat arguing what are there without knowing them. > > In it, clause 10 lays out threats and controls. One of the biggest proble= m > about the 29115 is that it is too prescriptive as to the controls are > concerned. There can be multiple ways of implementing controls and there > always are going to be new and more shiny ones. It should have been > constructed like 27002 that everything is optional but has to achieve the > objectives. > > (In fact, we did so for authentication phase, but other phases remained > pretty prescriptive.) > > Nat > > On Wed Nov 12 2014 at 16:38:34 Jones, Mark B > wrote: > >> One of the requirements should be that there be only as many dimensions >> to the vector as would be actionable by a Relying Party to make an >> authorization decision. Otherwise, the model is more complex than it nee= ds >> to be. >> >> *[Jones, Mark B] * >> >> *Isn=E2=80=99t =E2=80=98authorization=E2=80=99 out of scope here? The s= trawman document does not >> mention authorization.* >> > > > ---------- Forwarded message ---------- > From: Robin Wilton > To: "vot@ietf.org" > Cc: > Date: Wed, 12 Nov 2014 12:16:03 +0000 > Subject: [VoT] Three things... > > > *From: *Joanne Knight > *Subject: **Re: [VoT] vot Digest, Vol 3, Issue 3* > *Date: *12 November 2014 04:04:29 GMT > *To: *'Jim Fenton' , 'Peter Alterman' < > palterman@safe-biopharma.org>, 'Nat Sakimura' > *Cc: *"'vot@ietf.org'" > > > Greetings All > > I am new to this group so for the benefit of those who do not know me=E2= =80=A6 > > I am Joanne Knight (probably the real me but not what you will find on an= y > official register) ;-) > > > Hi Joanne, and welcome. Unless =E2=80=9CJoanne Knight=E2=80=9D is actuall= y another of > Colin Wallis=E2=80=99 personas, in which case, nice try and welcome back. > > > > > > > *From:* Jim Fenton [mailto:fenton@bluepopcorn.net > ] > *Sent:* Wednesday, 12 November 2014 1:01 p.m. > *To:* Peter Alterman; Nat Sakimura > *Cc:* vot@ietf.org > *Subject:* Re: [VoT] vot Digest, Vol 3, Issue 3 > > Peter, > > > Finally, it sounds like we're talking past each other on the word > "vector". We're using the word in the mathematical sense, and it appears > you're using it in the epidemiological sense. If there's a word here I ha= ve > a quibble about, it's "trust=E2=80=9D. > > > > IIRC, Leif has already made the point that =E2=80=9Cvector=E2=80=9D was c= hosen more or > less on the spur of the moment during the Utrecht workshop; looking at th= e > kinds of thing people are grouping under that term, it feels to me (as to > Peter) that =E2=80=9Cfactor=E2=80=9D would serve as well. I know that=E2= =80=99s not very helpful > now that the mailing list already has a V in it, sorry. > > Unless I misunderstand it, we are talking about =E2=80=9Cthe things that > contribute, positively or negatively, to the trustworthiness of an identi= ty > assertion=E2=80=9D. This also relates partly to a further comment, below,= on > something Peter said. > > > > > > On 11/11/14 3:09 PM, Peter Alterman wrote: > > Nat et. al. > > Let's not reason backwards from use cases but forwards from expertise. > There are a zillion use cases out there that can be generated for any mod= el > (sort of like a cost/benefit analysis - just tell the analyst what answer > you want and let him/her crank out the sausage). Rather, what are the > legitimate components of an identity assertion; what's the nature of the > relationship among them? Nothing I've seen so far changes my opinion that > there are four variables: strength of identity proofing (measured against= a > benchmark that incorporates *both* 800-63 and 29115); intrinsic resistanc= e > of credential type to attack (see prior benchmarking comment); credential > management (how well it addresses the threat vectors in 29115 and aligns > with 800-63 processes, and exchange, which incorporates mitigation of dat= a > in motion threat vectors listed in 29115 relevant to AuthN. > > Also agree that the AuthN process is not part of determining the > trustworthiness (rat hole warning) of an online identity assertion but th= e > process of making such a determination. > > > I mostly agree, but I think that the lifecycle of a credential gives us a > good basis for drawing up a shortlist of the things that make the resulti= ng > assertions of identity trustworthy. If you do, you get a very similar lis= t > to the one Nat mentions, and phases that reflect Joanne=E2=80=99s comment= s too. > > > - the initial registration/verification/enrolment phase ("proofing") > - the issue of credentials (encapsulating attributes and binding the > result to the individual somehow) > - presentation of the credentials over time > - validation of the credentials (a.k.a. Authentication) > - other lifecycle bits like revocation/amendment/destruction > > > (Nat makes the point, below, that most RPs don=E2=80=99t care about ident= ity > proofing. I=E2=80=99m sure he is right, but since we=E2=80=99re trying to= tease out all the > things that underpin the reliability of an identity assertion, I think we > need to be more explicit; RPs don=E2=80=99t care because they will assume= either > that proofing has been done adequately, or that if they rely on a valid > credential that has been incorrectly issued, the liability will rest with > the issuer. But I=E2=80=99d argue that those are trust factors too.) > > Last: I=E2=80=99m worried that Peter=E2=80=99s final sentence above is op= en to > misinterpretation. If any of the phases I=E2=80=99ve just listed is not r= eliable, > it undermines trust in the outcome (which is, ideally, justified reliance > on an assertion of identity). If the authentication step is trivial, > cursory, superficial, spoofable, insecure, call it what you will - then > someone relying on its outcome could be mistaken. > > > > Finally, scalar is not vector. C'mon guys, give an old man a break. We're > talking factors, not vectors. As an example, a threat vector is an identi= ty > assertion threat aimed at someone or some process: it has strength and it > has direction. > > regards, > > Peter > > > ------------------------------------------------------------ > Peter Alterman, Ph.D. > Chief Operating Officer > SAFE-BioPharma Association > > cell: 301-943-7452 > > On Tue, Nov 11, 2014 at 5:28 PM, Nat Sakimura wrote: > In many cases, people do not care about Identity Proofing. As long as the > credential management and after is done right, it should not matter in ma= ny > commercial use case. So, in the previous expression, to some of my use > cases, I am indifferent with (1, 2, 2, 2) and (4, 2, 2, 2). In the > traditional SP800-63 case, however, the former is 0 and later is 2, makin= g > (1, 2, 2, 2) and (1, 1, 1, 1) indifferent, losing the information I was > interested in. Also, I may want to accept (1,2,2,1) on a intranet while I > am only willing to accept (1,2,2,2) over the internet. Justin was arguing > to collapse the middle two, and that may well be a good simplification. I= n > this case, I still care those three dimensions instead of four. > > As to the attribute reliability is concerned, the room concluded that it > is out of scope for VoT for now, that we should only concentrate on entit= y > authentication assurance. The quality of attribute should be treated more > like a metadata about each attribute instead. > > For the Enrollment, Credential Management, Authentication, refer to > ISO/IEC 29115 or ITU-T X.1254, which are almost identical apart from the > formatting and 3 words. X.1254 is freely available. You can find them her= e: > https://www.itu.int/rec/T-REC-X.1254-201209-I/en > > Nat > > > On Wed Nov 12 2014 at 6:53:11 Jim Fenton wrote: > One of the requirements should be that there be only as many dimensions t= o > the vector as would be actionable by a Relying Party to make an > authorization decision. Otherwise, the model is more complex than it need= s > to be. > > I'm not sure I understand how Enrollment, Credential Management, > Authentication, and Assertion Transmission are defined (if that was > discussed on the list, I'd appreciate a pointer to it). But as a relying > party, if the quality of an attribute I receive is limited by something, = I > probably don't care whether it was because the credential management or t= he > assertion transmission was the cause. > > So if this retains 4 dimensions, there should be use cases that justify > the need for 4. I can do that for 2 dimensions (authentication > strength/attribute reliability) by considering uses like strong > pseudonymous authentication with a trustable assertion of an attribute li= ke > age. I don't have any good examples for more than 2. > > > -Jim > > > On 11/11/14 1:34 PM, Nat Sakimura wrote: > > We had a bar-bof last night at IETF 91. > There was a discussion that perhaps instead of three dimension "Identity > Proofing / Credential Binding / Assertion Transmission", perhaps 4 > dimension "Enrollment/Credential management/Authentication/Assertion > Transmission" is more appropriate. The reason was that Identity Proofing = is > only a step in Enrollment, Credential Binding is only a step in Credentia= l > Management, and the use of credential, i.e., Authentication, is important > enough to separate out from Credential Management. Then, there followed a > lengthy discussion about whether to pull Authentication out. > > As to the "vector" is concerned, it indeed seem to be a vector to me in > the sense that: > > *v* =3D (e, c, a, t) > where e:=3Dscalar value for expressing Enrollment quality > c:=3Dscalar value for expressing Credential Management quality > a:=3Dscalar value for expressing Authentication quality > t:=3Dscalar value for expressing Assertion Transmission quality. > > There was discussion on how to obtain these values as well. The room > opinion was that we should define the response format and then use it to > define the request format. > > Also, there was a discussion around the nature of the value of each scala= r > above, and the granularity desired. > We were not even sure if the values are going to be an ordered set. > Everybody agreed that simplicity is a requirement for widespread adoption= . > If granularity were sought, then it should be defined as a subset of pare= nt > value so that implementation that do not care about these can safely igno= re > them. > > Apart from the above, importance of the operational quality of IdPs were > expressed. This seem to be the quality which should be transmitted not pe= r > authentication transaction but separately, perhaps from .well-known > resource. > > FYI, the room also had the opinion that we should not get into the > "quality of attributes" in general but focus only to the entity > authentication, at least for this round. > > Cheers, > > Nat > > > > > On Wed Nov 12 2014 at 5:25:56 Peter Alterman > wrote: > Pardon me not diddling with the strawman. A quick read generated the > comments following. Hope they are helpful in evolving the document. > > What is immediately missing is a value for the quality of the credential > technology because some credential types are inherently less secure - or > risk mitigating - than others. > > My second observation is that it is not yet clear to me why these element= s > are called vectors. Vectors are expressions of quantities in > spacio-temporal directions. So far I see three (and the fourth I recommen= d > here) factors. In order to consider them vectors, please show me a plot o= n > a graph and label the axes and the measurement units. > > My third observation is that I do not see any straightforward way for the > factors to be collapsed. There are no approaches to do so presented, > either. First question to ask here is whether the ecosystem will need to > deploy both a transmission protocol and a receiving protocol? If the > methodology requires broad uptake of RP software in order to decode the > transmitted factors, the Hydra is unleashed. > > thanks, > > Peter > > ------------------------------------------------------------ > Peter Alterman, Ph.D. > Chief Operating Officer > SAFE-BioPharma Association > > cell: 301-943-7452 > > On Tue, Nov 11, 2014 at 3:02 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. Document in GitHub (Richer, Justin P.) > > > ---------- Forwarded message ---------- > From: "Richer, Justin P." > To: "vot@ietf.org" > Cc: > Date: Mon, 10 Nov 2014 21:07:53 +0000 > Subject: [VoT] Document in GitHub > I've started the work of translating much of my original strawman documen= t > to Markdown and pushing it to GitHub so that we can start taking edits vi= a > pull request: > > https://github.com/vectorsoftrust/strawman/blob/master/VectorsOfTrust.m= d > > Clone and fork away! > > -- Justin > > > _______________________________________________ > 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 > > > > > _______________________________________________ > 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 > > --001a11c1c9704a66f60507ab6d0e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Jo= anne. Thanks for the shout out.=C2=A0

Here are a few thoughts on the various comments I read over mornin= g coffee: first, I use vector in the Physics 101 sense, Nat, but I will now= leave this annoyance behind and allow you the terminology you feel comfort= able using. (Yes, before I got all these pesky literature degrees I majored= in physics and even attended lectures on chirality by C.N. Yang.)=C2=A0

Next, before addressing the qui= te legitimate question of what we mean by extended attributes, etc., we mus= t resist reinventing/re-conceiving operational models. In principle the set= of attributes required by a RP may vary from case to case but there alread= y exists a vast operating ecosystem that has already determined what that s= et of attributes is and how to deal with it. I resist any attempt to fiddle= with that, while I am open to new, useful, practical ways to measure ident= ity attributes and to express them. Many use cases care not a whit for this= set, many will want others, as Nat has described (I agree we are in that s= trange window of argumentative mutual agreement). Currently, this is handle= d on a relationship-by-relationship basis with attributes that are not incl= uded in the generic identity attribute set or which are included but ignore= d by a general-purpose AuthN process. Extended attributes are the kitchen s= ink of online AuthN + AuthZ and they can consist of any unit of data about = a natural person or a thing. To avoid the rat hole, simply accept the fact = that there is a widely-used set of personal (or machine or code) attributes= generally accepted as identity-asserting attributes and move on. Other att= ributes simply add to the utility of the online identity assertion and beg = a universal method of expression.

+1 on the comment that RPs may have little or no interest in an onli= ne identity assertion reliability rating of {3:1:2:4}. This is, to me, the = place where the theoretical crosses the line to useless. The social domain = cares less than nothing about any of this, the e-commerce domain cares abou= t the history of my credit card account paying for things bought online, go= vernments and financial institutions need high assurances of identity addre= ssed by ETSI QCP and Fed PKI and FICAM. While I do appreciate the work that= GTRI has done under grant from NSTIC to decompose AuthN, I think it result= s in a conceptual model that doesn't align with the needs of the real w= orld. Now, show me a way to collapse {3:1:2:4} into something an e-commerce= or e-gov RP can use and I'm all on board. Preferably using existing to= ols such as SAML, XACML, WS-Fed, etc.

Finally, regarding use cases: I thank you Jim for your desire to s= implify all this. I believe that use cases are valuable to test models, not= to build them. Too often they are misused for the latter, not the former, = IMO, and that leads to destructive stuff like a health care group lobbying = NIST to define an LOA of 2.5 to satisfy the use cases they created. That= 9;s all I am saying.

regards,=

Peter


=
------------------------------------------------------------=
Peter Alterman, Ph.D.
Chief Operating Officer
SAFE-Bi= oPharma Association
cell: 301-943-7452


On Wed, Nov 12, 2014 at 7:16 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: vot Digest, Vol 3, Issue 3 (Nat Sakimura)
=C2=A0 =C2=A02. Three things... (Robin Wilton)


---------- Forwarded message ----------
From:=C2=A0Nat Sakimura = <sakimura@gmail.com>
To:= =C2=A0"Jones, Mark B" <Mark.B.Jones@uth.tmc.edu>, Jim Fenton <fenton@bluepopcorn.net>, Peter Alterman <palterman@safe-biopharma.org>, "vot@ietf.org" <vot@ietf.org>
Cc:=C2=A0
Date:=C2= =A0Wed, 12 Nov 2014 07:59:42 +0000
Subject:=C2=A0Re: [VoT] vot Digest, V= ol 3, Issue 3
IMHO, everybody here should read X.1254 - ISO/IEC 29115 as= a starting point. It has got problems, but it still is a good starting poi= nt and we do not have to repeat arguing what are there without knowing them= .=C2=A0

In it, clause 10 lays out threats and contro= ls. One of the biggest problem about the 29115 is that it is too prescripti= ve as to the controls are concerned. There can be multiple ways of implemen= ting controls and there always are going to be new and more shiny ones. It = should have been constructed like 27002 that everything is optional but has= to achieve the objectives.=C2=A0

(In fact, we did= so for authentication phase, but other phases remained pretty prescriptive= .)=C2=A0

Nat

O= n Wed Nov 12 2014 at 16:38:34 Jones, Mark B <Mark.B.Jones@uth.tmc.edu> wrote:<= br>

One of the requirem= ents should be that there be only as many dimensions to the vector as would= be actionable by a Relying Party to make an authorization decision. Otherw= ise, the model is more complex than it needs to be.

[Jones= , Mark B]

Isn=E2=80=99t =E2=80=98authorization=E2=80=99 out o= f scope here?=C2=A0 The strawman document does not mention authorization.



---------- Forwarded message ----------
From:=C2=A0Robin Wilton = <wilton@isoc.org>
To:=C2=A0= "vot@ietf.org" <vot@ietf.org>
Cc:=C2=A0
Date:=C2=A0Wed, = 12 Nov 2014 12:16:03 +0000
Subject:=C2=A0[VoT] Three things...

From:=C2=A0Joanne Knight <Joanne.Knigh= t@dia.govt.nz>
Subject:=C2=A0Re: [VoT] vot Dige= st, Vol 3, Issue 3
Date:=C2=A012 November 2014 04:04:= 29 GMT
Cc:=C2=A0"'vot@ietf.org'" <vot@ietf.org= >


Greetings = All
=C2=A0<= /div>
I am new to this group so for the benef= it of those who do not know me=E2=80=A6
=C2=A0
I a= m Joanne Knight (probably the real me but not what you will find on any off= icial register) ;-)

Hi Joanne, and welcome. Unless =E2=80=9CJoanne Knight=E2=80=9D is actuall= y another of Colin Wallis=E2=80=99 personas, in which case, nice try and we= lcome back.


=C2=A0
=C2=A0
=C2=A0<= /span>
From:=C2= =A0Jim Fenton [mailto:fenton@bluep= opcorn.net]=C2=A0
Sent:=C2=A0Wednes= day, 12 November 2014 1:01 p.m.
To:=C2=A0Peter Alter= man; Nat Sakimura
Cc:=C2=A0v= ot@ietf.org
Subject:=C2=A0Re: [VoT] vot Digest, = Vol 3, Issue 3
=C2=A0
Peter,


Fi= nally, it sounds like we're talking past each other on the word "v= ector". We're using the word in the mathematical sense, and it app= ears you're using it in the epidemiological sense. If there's a wor= d here I have a quibble about, it's "trust=E2=80=9D.


IIRC, Leif ha= s already made the point that =E2=80=9Cvector=E2=80=9D was chosen more or l= ess on the spur of the moment during the Utrecht workshop; looking at the k= inds of thing people are grouping under that term, it feels to me (as to Pe= ter) that =E2=80=9Cfactor=E2=80=9D would serve as well. I know that=E2=80= =99s not very helpful now that the mailing list already has a V in it, sorr= y.

Unless I misunderstand it, we are talking about= =E2=80=9Cthe things that contribute, positively or negatively, to the trus= tworthiness of an identity assertion=E2=80=9D. This also relates partly to = a further comment, below, on something Peter said.





On 11/11/14 3:09 PM, Peter Alterman wrote:
<= div>
Nat et. al.
=C2=A0
=C2=A0
=C2=A0Also agree that the AuthN process is not= part of determining the trustworthiness (rat hole warning) of an online id= entity assertion but the process of making such a determination.

I mostly a= gree, but I think that the lifecycle of a credential gives us a good basis = for drawing up a shortlist of the things that make the resulting assertions= of identity trustworthy. If you do, you get a very similar list to the one= Nat mentions, and phases that reflect Joanne=E2=80=99s comments too.
=

  • the initial registration/verification/enrolment= phase ("proofing")
  • the issue of credentials (encapsulati= ng attributes and binding the result to the individual somehow)
  • pre= sentation of the credentials over time
  • validation of the credential= s (a.k.a. Authentication)=C2=A0
  • other lifecycle bits like revocatio= n/amendment/destruction

(Nat makes the point, = below, that most RPs don=E2=80=99t care about identity proofing. I=E2=80=99= m sure he is right, but since we=E2=80=99re trying to tease out all the thi= ngs that underpin the reliability of an identity assertion, I think we need= to be more explicit; RPs don=E2=80=99t care because they will assume eithe= r that proofing has been done adequately, or that if they rely on a valid c= redential that has been incorrectly issued, the liability will rest with th= e issuer. But I=E2=80=99d argue that those are trust factors too.)

Last: I=E2=80=99m worried that Peter=E2=80=99s final sente= nce above is open to misinterpretation. If any of the phases I=E2=80=99ve j= ust listed is not reliable, it undermines trust in the outcome (which is, i= deally, justified reliance on an assertion of identity). If the authenticat= ion step is trivial, cursory, superficial, spoofable, insecure, call it wha= t you will - then someone relying on its outcome could be mistaken.


<= /u>
=C2=A0
Finally, scalar is not vector. C'mon= guys, give an old man a break. We're talking factors, not vectors. As = an example, a threat vector is an identity assertion threat aimed at someon= e or some process: it has strength and it has direction.
=C2=A0
regards,
=C2=A0
Peter=
=C2=A0

<= /div>
---------------------------= ---------------------------------
Peter Alterman, Ph.D.
cell: 301-943-7452<= /p>
=C2=A0
On Tue, Nov 11, 2014 at 5:28 PM, Nat Sakimura <sakimura@gmail.com> wrote:
In many cases, people do not care about Identity Proofin= g. As long as the credential management and after is done right, it should = not matter in many commercial use case. So, in the previous expression, to = some of my use cases, I am indifferent with (1, 2, 2, 2) and (4, 2, 2, 2). = In the traditional SP800-63 case, however, the former is 0 and later is 2, = making (1, 2, 2, 2) and (1, 1, 1, 1) indifferent, losing the information I = was interested in. Also, I may want to accept (1,2,2,1) on a intranet while= I am only willing to accept (1,2,2,2) over the internet. Justin was arguin= g to collapse the middle two, and that may well be a good simplification. I= n this case, I still care those three dimensions instead of four.=C2=A0<= /u>
=C2=A0
As to the attribute reliability is concerned, = the room concluded that it is out of scope for VoT for now, that we should = only concentrate on entity authentication assurance. The quality of attribu= te should be treated more like a metadata about each attribute instead.=C2= =A0
=C2=A0
For the=C2=A0Enrollment, Credenti= al Management, Authentication, refer to ISO/IEC 29115 or ITU-T X.1254, whic= h are almost identical apart from the formatting and 3 words. X.1254 is fre= ely available. You can find them here:=C2=A0https://www.itu.int/rec/T-REC-X.1254-201209-I/en<= u>
=C2=A0
Nat
=C2=A0
= =C2=A0
On Wed Nov 12 2014 at= 6:53:11 Jim Fenton <fenton@bluepopcor= n.net> wrote:
One of = the requirements should be that there be only as many dimensions to the vec= tor as would be actionable by a Relying Party to make an authorization deci= sion. Otherwise, the model is more complex than it needs to be.

I= 9;m not sure I understand how Enrollment, Credential Management, Authentica= tion, and Assertion Transmission are defined (if that was discussed on the = list, I'd appreciate a pointer to it). But as a relying party, if the q= uality of an attribute I receive is limited by something, I probably don= 9;t care whether it was because the credential management or the assertion = transmission was the cause.

So if this retains 4 dimensions, there s= hould be use cases that justify the need for 4. I can do that for 2 dimensi= ons (authentication strength/attribute reliability) by considering uses lik= e strong pseudonymous authentication with a trustable assertion of an attri= bute like age. I don't have any good examples for more than 2.


-Jim


On 11/11/14 1:34 PM, Nat Sakimu= ra wrote:

We had a bar-bof l= ast night at IETF 91.=C2=A0

Th= ere was a discussion that perhaps instead of three dimension "Identity= Proofing / Credential Binding / Assertion Transmission", perhaps 4 di= mension "Enrollment/Credential management/Authentication/Assertion Tra= nsmission" is more appropriate. The reason was that Identity Proofing = is only a step in Enrollment, Credential Binding is only a step in Credenti= al Management, and the use of credential, i.e., Authentication, is importan= t enough to separate out from Credential Management. Then, there followed a= lengthy discussion about whether to pull Authentication out.=C2=A0<= u>
=C2=A0
As to the "vector" is concerned, i= t indeed seem to be a vector to me in the sense that:=C2=A0
=C2=A0
=
v=C2=A0=3D (e, c, a, t)=C2=A0=
=C2=A0where e:=3Dscalar = value for expressing Enrollment quality
=C2=A0c:=3Dscalar value for expressing Credential Managem= ent quality
=C2=A0a:= =3Dscalar value for expressing Authentication quality
=C2=A0t:=3Dscalar value for expressing Asse= rtion Transmission quality.=C2=A0
=C2=A0
Th= ere was discussion on how to obtain these values as well. The room opinion = was that we should define the response format and then use it to define the= request format.=C2=A0
=C2=A0
Also, there wa= s a discussion around the nature of the value of each scalar above, and the= granularity desired.=C2=A0
We were not even sure if the values are going to be an ordered set. E= verybody agreed that simplicity is a requirement for widespread adoption. I= f granularity were sought, then it should be defined as a subset of parent = value so that implementation that do not care about these can safely ignore= them.=C2=A0
= =C2=A0
Apart from the above, = importance of the operational quality of IdPs were expressed. This seem to = be the quality which should be transmitted not per authentication transacti= on but separately, perhaps from .well-known resource.=C2=A0
=C2=A0
=
FYI, the room also had the opinion that we should no= t get into the "quality of attributes" in general but focus only = to the entity authentication, at least for this round.=C2=A0<= /div>
=C2=A0
Cheers,=C2=A0
=C2=A0
Nat
=C2=A0<= /u>
=C2=A0
=
=C2=A0
=C2=A0
On Wed Nov 12= 2014 at 5:25:56 Peter Alterman <palterman@safe-biopharma.org> wrote:
<= div style=3D"margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times = New Roman',serif">Pardon me not diddling with the strawman. A quick rea= d generated the comments following. Hope they are helpful in evolving the d= ocument.
=C2=A0=
What is immediately missing = is a value for the quality of the credential technology because some creden= tial types are inherently less secure - or risk mitigating - than others.= =C2=A0
=C2=A0
My second observation is that = it is not yet clear to me why these elements are called vectors. Vectors ar= e expressions of quantities in spacio-temporal directions. So far I see thr= ee (and the fourth I recommend here) factors. In order to consider them vec= tors, please show me a plot on a graph and label the axes and the measureme= nt units.
=C2= =A0
My third observation is t= hat I do not see any straightforward way for the factors to be collapsed. T= here are no approaches to do so presented, either. First question to ask he= re is whether the ecosystem will need to deploy both a transmission protoco= l and a receiving protocol? If the methodology requires broad uptake of RP = software in order to decode the transmitted factors, the Hydra is unleashed= .
=C2=A0=
thanks,
=C2=A0
Peter

------------------------------------------------------------
Peter Alterman, Ph.D.<= /u>
Chief Operating Officer
SAFE-BioPh= arma Association

cell:=C2=A0301-943-7452=

=C2=A0
On Tue, Nov 11, 2014 at 3:02 PM, <vot-request@ietf.org> wrote:

Send vot mailing list submissions to
=C2=A0= =C2=A0 =C2=A0 =C2=A0=C2=A0vot@ietf.or= g

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

You can reach the person managing the list at
= =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0vot-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. Document in GitHub (Richer= , Justin P.)


---------- Forwarded message ----------
From:=C2= =A0"Richer, Justin P." <jricher@m= itre.org>
To:=C2=A0"vot@ietf.org= " <vot@ietf.org>
Cc:=C2=A0
Dat= e:=C2=A0Mon, 10 Nov 2014 21:07:53 +0000
Subject:=C2=A0[VoT] Document in = GitHub
I've started the work of translating much of my original stra= wman document to Markdown and pushing it to GitHub so that we can start tak= ing edits via pull request:

=C2=A0=C2=A0https://githu= b.com/vectorsoftrust/strawman/blob/master/VectorsOfTrust.md

Clon= e and fork away!

=C2=A0-- Justin


________________________= _______________________
vot mailing list
vot@= ietf.org
https://www.i= etf.org/mailman/listinfo/vot

=C2=A0
________________= _______________________________
vot mailing list
vot@ietf.org
https= ://www.ietf.org/mailman/listinfo/vot


____________________=
___________________________
vot mailing lis=
t
vot@ietf.org<=
u>
https://www.ietf.org/mailman/listinfo/vot
=C2=A0
=C2=A0



_____________________________=
__________________
vot mailing list<=
u>
vot@ietf.org=

https:=
//www.ietf.org/mailman/listinfo/vot
=C2=A0


_______________= ________________________________
vot mailing list
vot@ietf.org
http= s://www.ietf.org/mailman/listinfo/vot

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


--001a11c1c9704a66f60507ab6d0e-- From nobody Wed Nov 12 08:04:05 2014 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 6482A1A1C00 for ; Wed, 12 Nov 2014 08:04:03 -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 6VQXRUptPVAr for ; Wed, 12 Nov 2014 08:04:02 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0764.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:764]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B60BB1A1BE1 for ; Wed, 12 Nov 2014 08:04:01 -0800 (PST) Received: from BN1BFFO11FD044.protection.gbl (10.58.144.33) by BN1BFFO11HUB033.protection.gbl (10.58.144.180) with Microsoft SMTP Server (TLS) id 15.1.6.13; Wed, 12 Nov 2014 16:03:38 +0000 Received: from cio-tnc-pf02.osuad.osu.edu (164.107.81.216) by BN1BFFO11FD044.mail.protection.outlook.com (10.58.144.107) with Microsoft SMTP Server (TLS) id 15.1.6.13 via Frontend Transport; Wed, 12 Nov 2014 16:03:38 +0000 Received: from CIO-TNC-HT06.osuad.osu.edu (cio-tnc-ht06.osuad.osu.edu [164.107.81.171]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by cio-tnc-pf02.osuad.osu.edu (Postfix) with ESMTPS id E341D20035; Wed, 12 Nov 2014 11:03:37 -0500 (EST) Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-TNC-HT06.osuad.osu.edu ([fe80::3d16:84bd:8d88:7cfd%12]) with mapi id 14.03.0174.001; Wed, 12 Nov 2014 11:03:37 -0500 From: "Cantor, Scott" To: Robin Wilton Thread-Topic: [VoT] Three things... Thread-Index: AQHP/o3+kyTw6Wp1Y0u6yXjL2DR0v5xdIrSAgAAEpIA= Date: Wed, 12 Nov 2014 16:03:36 +0000 Message-ID: References: <12B80039-A4F9-481C-900B-CE56EFA12C3B@isoc.org> In-Reply-To: <12B80039-A4F9-481C-900B-CE56EFA12C3B@isoc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [140.254.59.82] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:164.107.81.216; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(438002)(479174003)(377454003)(24454002)(51704005)(189002)(199003)(120916001)(77156002)(64706001)(95666004)(110136001)(107046002)(75432002)(62966003)(46102003)(88552001)(109096001)(77096003)(106116001)(106466001)(33656002)(47776003)(99396003)(66066001)(36756003)(20776003)(4396001)(50466002)(31966008)(2656002)(92726001)(19580395003)(6806004)(86362001)(44976005)(87936001)(19580405001)(89122001)(21056001)(92566001)(23676002)(76176999)(82746002)(83716003)(50986999)(93346002)(90282001)(54356999)(7059030)(104396001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1BFFO11HUB033; H:cio-tnc-pf02.osuad.osu.edu; FPR:; MLV:sfv; PTR:cio-tnc-pf02.osuad.osu.edu; MX:1; A:1; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1BFFO11HUB033; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA: BCL:0;PCL:0;RULEID:;SRVR:BN1BFFO11HUB033; X-Forefront-PRVS: 03932714EB 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-Exchange-Antispam-Report-CFA: BCL:0;PCL:0;RULEID:;SRVR:BN1BFFO11HUB033; X-OriginatorOrg: osu.edu Archived-At: http://mailarchive.ietf.org/arch/msg/vot/xyO6EAtNrvsocVRBw-Wv7-iwJvM Cc: "vot@ietf.org" Subject: Re: [VoT] Three things... 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, 12 Nov 2014 16:04:03 -0000 T24gMTEvMTIvMTQsIDM6NDUgUE0sICJSb2JpbiBXaWx0b24iIDx3aWx0b25AaXNvYy5vcmc+IHdy b3RlOg0KDQo+PlRoZSBtb3N0IGNvbW1vbiByZWFzb24gaXMgdGhhdCBwcm9vZmluZyBpcyBkb25l IGJ5IHNvbWVib2R5IGVsc2UsIGVpdGhlciANCj4+YSANCj4+IHVzZXIgb2YgdGhlIHNlcnZpY2Ug b3IgdGhlIFJQIG9wZXJhdG9yIGl0c2VsZi4gSXQncyBvdXRzaWRlIHRoZSBzY29wZSANCj4+b2Yg DQo+PiB0aGUgaWRlbnRpdHkgYXNzZXJ0aW9uL2V4Y2hhbmdlLg0KPg0KPlJpZ2h04oCmIGl04oCZ cyBvdXRzaWRlIHRoZSBzY29wZSwgYnV0IGl04oCZcyBhIHRydXN0IGZhY3RvciB0aGF04oCZcyB1 cHN0cmVhbSBvZiANCj5hbnkgc3Vic2VxdWVudCBhdXRoZW50aWNhdGlvbi4gSWYgaXQgaXMgZmF1 bHR5LCB0aGUgZG93bnN0cmVhbSBwb2xsdXRpb24gDQo+bmVlZHMgdG8gZW5kIHVwIGluIHNvbWVv bmXigJlzIHJpc2sgYXNzZXNzbWVudC4NCg0KSXQncyBpbnRlcm5hbCB0byB0aGUgUlAsIGl0IGhh cyBub3RoaW5nIHRvIGRvIHdpdGggdGhlIGVjb3N5c3RlbSBvZiBhY3RvcnMgDQp0aGF0IHRoZSBj b25jZXB0IG9mICJhc3N1cmFuY2UiIGRlYWxzIHdpdGguDQoNCj5PSyAtIHVuZGVyc3Rvb2TigKYg YW5kIEkgdGhpbmsgdGhpcyBnb2VzIHRvIHRoZSByZW1hcmtzIEpvYW5uZSBtYWRlIGFib3V0IA0K PnRoZSBkaWZmZXJlbnQgcGVyc3BlY3RpdmUgd2hlbiBvbmUgY29tZXMgYXQgdGhpcyBmcm9tIGEg YmFja2dyb3VuZCBvZiANCj7igJxnb3Zlcm5tZW504oCdIGNyZWRlbnRpYWwgaXNzdWUuDQoNClRo YXQgd291bGQgYmUgbW9yZSBwZXJzdXNhc2l2ZSB0byBtZSBpZiBJIGhhZG4ndCBoYWQgZGVhbGlu Z3Mgd2l0aCANCmdvdmVybm1lbnQgYWdlbmNpZXMuIEkga25vdyB3aGF0IG1vc3Qgb2YgdGhlbSBh Y3R1YWxseSBkby4NCg0KPldoZW4geW91IHNheSDigJxubyBwcm9vZmluZ+KAnSwgdGhlbiwgZG8g eW91IG1lYW4gbm9uZSBhdCBhbGwsIG9yIHByb29maW5nIA0KPndoaWNoIGlzIG5vdCByZWZsZWN0 ZWQgaW4gYW55IHdheSBpbiB0aGUgYXV0aGVudGljYXRpb24gcmVxdWVzdD8NCg0KSXQgZG9lc24n dCBtYXR0ZXIgZm9yIG91ciBwdXJwb3NlcywgYnV0IHRoZSBsYXR0ZXIgaWYgeW91IGxpa2UuDQoN Cj5JIHRoaW5rIHRoZSBmb3JtZXIgY29ycmVzcG9uZHMgdG8gdGhlIHdheSBEaWNrIEhhcmR0ICpv cmlnaW5hbGx5KiANCj5kZXNjcmliZWQgdGhlIE9wZW5JRCBjb25jZXB0IChpbiBhYm91dCAyMDA3 4oCmIGkuZS4gbm8gcHJpb3IgcmVsYXRpb25zaGlwIA0KPmJldHdlZW4gYW4gSURQIGFuZCBhbiBS UCwganVzdCB0aGUgcGFzc2luZyBvZiBhbiBhdXRoZW50aWNhdGlvbiB0b2tlbiksIA0KPmFuZCB0 aGUgbGF0dGVyIGNvcnJlc3BvbmRzIHRvIOKAnGF1dGhlbnRpY2F0aW9uIHdpdGggbm8gTG9BIGV4 cHJlc3NlZCBvciANCj5pbXBsaWVkIHRvIHRoZSBSUOKAnS4NCg0KVGhlIHJlbGF0aW9uc2hpcCBi ZXR3ZWVuIHRoZSBSUCBhbmQgSWRQIGlzIG5vdCBhYm91dCBwcm9vZmluZyANCnNwZWNpZmljYWxs eSwgYnV0IGFib3V0IGFjY2VwdGluZyAqYW55dGhpbmcqIHRoZSBJZFAgc2F5cy4gV2hldGhlciB0 aGUgDQoiYW55dGhpbmciIGluY2x1ZGVzIGp1c3QgYXV0aGVudGljYXRpb24gb3IgaGFzIHNvbWUg b3RoZXIgY29tcG9uZW50IGlzIGEgDQptYXR0ZXIgZm9yIHNwZWNpZmljIHVzZSBjYXNlcyB0byBh ZGRyZXNzLg0KDQpBZ2FpbiwgTE9BICE9IHByb29maW5nLg0KDQotLSBTY290dA0KDQo= From nobody Wed Nov 12 10:25:25 2014 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 24AD11AC3CF for ; Wed, 12 Nov 2014 10:25:20 -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 AZJE4VjQxxuO for ; Wed, 12 Nov 2014 10:25:15 -0800 (PST) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5807A1A8AC1 for ; Wed, 12 Nov 2014 10:25:15 -0800 (PST) Received: by mail-ie0-f177.google.com with SMTP id tp5so14067803ieb.22 for ; Wed, 12 Nov 2014 10:25:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:from:date:message-id:subject:to:cc :content-type; bh=+NVw7BuJGHl8iX3piSHAa9ffR57KIVWkEd4/Zcu+eWg=; b=uCjlIF/sUy94R8JdQDhVXLK77mB923FnqLDozmF3kqxNY2p6JfWF1z/JzhSOpa7TTE 0GERSEB1wvQANrMvLJ/2isvv38uYr6k/Obj5ZvfcpB7pIVe0Bg0LTRo4ONoQ3uJUHeKd dNJiP7qHlW0U6hW3FqVpGs8uAc7+Q9d33Myq8cH+OAVH23xRVSzXTg0QzWel4h1RYfd+ LQH52zHR0I5m482WMKzU90T7oZXiFttOOltirE/wOb6NBHWWXmgcbGzO0ZdZxEsJ/FFG SFKiN+v/C9gTSrc0XffMr2Np5wbj9NIvI9cGTzRQmJYX9Mc+knYvq0Dh3Po7xSE56OMZ /5HQ== X-Received: by 10.42.177.9 with SMTP id bg9mr170120icb.81.1415816714458; Wed, 12 Nov 2014 10:25:14 -0800 (PST) MIME-Version: 1.0 References: <12B80039-A4F9-481C-900B-CE56EFA12C3B@isoc.org> From: Nat Sakimura Date: Wed, 12 Nov 2014 18:25:13 +0000 Message-ID: To: "Cantor, Scott" , Robin Wilton Content-Type: multipart/alternative; boundary=90e6ba61389a551fc40507ad84bd Archived-At: http://mailarchive.ietf.org/arch/msg/vot/R33sTD0QueQBLRjDWvvQN7ESm3I Cc: "vot@ietf.org" Subject: Re: [VoT] Three things... 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, 12 Nov 2014 18:25:20 -0000 --90e6ba61389a551fc40507ad84bd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 We could as well start from distributing strong credential at seven-eleven without any identity proofing in the conventional sense and rely on it. On Thu Nov 13 2014 at 1:04:06 Cantor, Scott wrote: > On 11/12/14, 3:45 PM, "Robin Wilton" wrote: > > >>The most common reason is that proofing is done by somebody else, eithe= r > >>a > >> user of the service or the RP operator itself. It's outside the scope > >>of > >> the identity assertion/exchange. > > > >Right=E2=80=A6 it=E2=80=99s outside the scope, but it=E2=80=99s a trust = factor that=E2=80=99s upstream of > >any subsequent authentication. If it is faulty, the downstream pollution > >needs to end up in someone=E2=80=99s risk assessment. > > It's internal to the RP, it has nothing to do with the ecosystem of actor= s > that the concept of "assurance" deals with. > > >OK - understood=E2=80=A6 and I think this goes to the remarks Joanne mad= e about > >the different perspective when one comes at this from a background of > >=E2=80=9Cgovernment=E2=80=9D credential issue. > > That would be more persusasive to me if I hadn't had dealings with > government agencies. I know what most of them actually do. > > >When you say =E2=80=9Cno proofing=E2=80=9D, then, do you mean none at al= l, or proofing > >which is not reflected in any way in the authentication request? > > It doesn't matter for our purposes, but the latter if you like. > > >I think the former corresponds to the way Dick Hardt *originally* > >described the OpenID concept (in about 2007=E2=80=A6 i.e. no prior relat= ionship > >between an IDP and an RP, just the passing of an authentication token), > >and the latter corresponds to =E2=80=9Cauthentication with no LoA expres= sed or > >implied to the RP=E2=80=9D. > > The relationship between the RP and IdP is not about proofing > specifically, but about accepting *anything* the IdP says. Whether the > "anything" includes just authentication or has some other component is a > matter for specific use cases to address. > > Again, LOA !=3D proofing. > > -- Scott > > _______________________________________________ > vot mailing list > vot@ietf.org > https://www.ietf.org/mailman/listinfo/vot > --90e6ba61389a551fc40507ad84bd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1=C2=A0

We could as well start from distributing strong creden= tial at seven-eleven without any identity proofing in the conventional sens= e=C2=A0and rely on it.=C2=A0

On= Thu Nov 13 2014 at 1:04:06 Cantor, Scott <cantor.2@osu.edu> wrote:
On= 11/12/14, 3:45 PM, "Robin Wilton" <wilton@isoc.org> wrote:

>>The most common reason is that proofing is done by somebody else, e= ither
>>a
>> user of the service or the RP operator itself. It's outside th= e scope
>>of
>> the identity assertion/exchange.
>
>Right=E2=80=A6 it=E2=80=99s outside the scope, but it=E2=80=99s a trust= factor that=E2=80=99s upstream of
>any subsequent authentication. If it is faulty, the downstream pollutio= n
>needs to end up in someone=E2=80=99s risk assessment.

It's internal to the RP, it has nothing to do with the ecosystem of act= ors
that the concept of "assurance" deals with.

>OK - understood=E2=80=A6 and I think this goes to the remarks Joanne ma= de about
>the different perspective when one comes at this from a background of >=E2=80=9Cgovernment=E2=80=9D credential issue.

That would be more persusasive to me if I hadn't had dealings with
government agencies. I know what most of them actually do.

>When you say =E2=80=9Cno proofing=E2=80=9D, then, do you mean none at a= ll, or proofing
>which is not reflected in any way in the authentication request?

It doesn't matter for our purposes, but the latter if you like.

>I think the former corresponds to the way Dick Hardt *originally*
>described the OpenID concept (in about 2007=E2=80=A6 i.e. no prior rela= tionship
>between an IDP and an RP, just the passing of an authentication token),=
>and the latter corresponds to =E2=80=9Cauthentication with no LoA expre= ssed or
>implied to the RP=E2=80=9D.

The relationship between the RP and IdP is not about proofing
specifically, but about accepting *anything* the IdP says. Whether the
"anything" includes just authentication or has some other compone= nt is a
matter for specific use cases to address.

Again, LOA !=3D proofing.

-- Scott

_______________________________________________
vot mailing list
vot@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/vot
--90e6ba61389a551fc40507ad84bd-- From nobody Wed Nov 12 10:55:59 2014 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 40EF11ACEA2 for ; Wed, 12 Nov 2014 10:55:57 -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 PRBa8NpCq1RU for ; Wed, 12 Nov 2014 10:55:50 -0800 (PST) Received: from mail-vc0-x235.google.com (mail-vc0-x235.google.com [IPv6:2607:f8b0:400c:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67DAB1ACE99 for ; Wed, 12 Nov 2014 10:55:44 -0800 (PST) Received: by mail-vc0-f181.google.com with SMTP id le20so63578vcb.40 for ; Wed, 12 Nov 2014 10:55:43 -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=Ulf/eNLqJ8yl2V6u0l0wYUXYFPVAV7bJNhPBN4sH+Rw=; b=yN06ybuM9npVJrlB3Y2QIYsT7pM1bZG1uYvzaAgqupJhEQ/llmqmiOuXl9YiqH5cD5 upw8rrWrHSMuZ8h7L0Z6Z+JAn614y89etEkfdn4AIXMO8EjejTpYc6kVDtIMm4+fwYYa +WLaKWr0+w2239LbmvGBxuH8mbIfSu/8fyXT5vjv2L1OiyXtIyVw6izh74fc4pSZPLAy y2N21h1/Y6cKF2X7BCv8CnkMDasRW9gijzRE8ZCDLDJZ/B0630wtCdFvYMvbT+51cn8d eNyj915pSqOGiXwZ8C5BNxahmPBBefUSZn07dP12Xy/rKmHrRe+HIE/F/Q0LUO/vLjyD Vi2w== MIME-Version: 1.0 X-Received: by 10.221.46.196 with SMTP id up4mr35767531vcb.2.1415818543315; Wed, 12 Nov 2014 10:55:43 -0800 (PST) Received: by 10.221.44.136 with HTTP; Wed, 12 Nov 2014 10:55:43 -0800 (PST) In-Reply-To: References: Date: Wed, 12 Nov 2014 13:55:43 -0500 Message-ID: From: Ken Dagg To: Peter Alterman Content-Type: multipart/alternative; boundary=001a11339dae573f880507adf16c Archived-At: http://mailarchive.ietf.org/arch/msg/vot/IR9QudMCBewIaWT8jRyGQS786mc Cc: "vot@ietf.org" Subject: Re: [VoT] vot Digest, Vol 3, Issue 11 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, 12 Nov 2014 18:55:57 -0000 --001a11339dae573f880507adf16c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable My thoughts on Peter's thoughts inline [[KD: thought]]. I agree fully with what you said Peter. Ken On Wednesday, November 12, 2014, Peter Alterman < palterman@safe-biopharma.org> wrote: > Hi Joanne. Thanks for the shout out. > > [[KD: Here, here Peter. I am also not comfortable with the word but I too > want to move beyond what it is called and focus on what it is trying to > accomplish]] Here are a few thoughts on the various comments I read over > morning coffee: first, I use vector in the Physics 101 sense, Nat, but I > will now leave this annoyance behind and allow you the terminology you fe= el > comfortable using. (Yes, before I got all these pesky literature degrees = I > majored in physics and even attended lectures on chirality by C.N. Yang.) > > [[KD: Again here, here. There are several operational environments that > need to be accommodated ... rather than revolutionized. The RPs in those > environments have already made their decisions regarding what attributes > they need to mitigate their identity authentication requirements.]] Next, > before addressing the quite legitimate question of what we mean by extend= ed > attributes, etc., we must resist reinventing/re-conceiving operational > models. In principle the set of attributes required by a RP may vary from > case to case but there already exists a vast operating ecosystem that has > already determined what that set of attributes is and how to deal with it= . > I resist any attempt to fiddle with that, while I am open to new, useful, > practical ways to measure identity attributes and to express them. Many u= se > cases care not a whit for this set, many will want others, as Nat has > described (I agree we are in that strange window of argumentative mutual > agreement). Currently, this is handled on a relationship-by-relationship > basis with attributes that are not included in the generic identity > attribute set or which are included but ignored by a general-purpose Auth= N > process. Extended attributes are the kitchen sink of online AuthN + AuthZ > and they can consist of any unit of data about a natural person or a thin= g. > To avoid the rat hole, simply accept the fact that there is a widely-used > set of personal (or machine or code) attributes generally accepted as > identity-asserting attributes and move on. Other attributes simply add to > the utility of the online identity assertion and beg a universal method o= f > expression. > > [[KD: I too want to see a way to collapse {3:1:2:4} into something an > e-commerce or e-gov RP can use and I'm all on board. Preferably using > existing tools such as SAML, XACML, WS-Fed, etc. this is in line with my > "let's evolve rather than revolutionize. ]] +1 on the comment that RPs ma= y > have little or no interest in an online identity assertion reliability > rating of {3:1:2:4}. This is, to me, the place where the theoretical > crosses the line to useless. The social domain cares less than nothing > about any of this, the e-commerce domain cares about the history of my > credit card account paying for things bought online, governments and > financial institutions need high assurances of identity addressed by ETSI > QCP and Fed PKI and FICAM. While I do appreciate the work that GTRI has > done under grant from NSTIC to decompose AuthN, I think it results in a > conceptual model that doesn't align with the needs of the real world. Now= , > show me a way to collapse {3:1:2:4} into something an e-commerce or e-gov > RP can use and I'm all on board. Preferably using existing tools such as > SAML, XACML, WS-Fed, etc. > > [[KD: I agree fully Peter. Use cases have a place in testing models. > ]] Finally, regarding use cases: I thank you Jim for your desire to > simplify all this. I believe that use cases are valuable to test models, > not to build them. Too often they are misused for the latter, not the > former, IMO, and that leads to destructive stuff like a health care group > lobbying NIST to define an LOA of 2.5 to satisfy the use cases they > created. That's all I am saying. > > regards, > > Peter > > > ------------------------------------------------------------ > Peter Alterman, Ph.D. > Chief Operating Officer > SAFE-BioPharma Association > cell: 301-943-7452 > > > On Wed, Nov 12, 2014 at 7:16 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: vot Digest, Vol 3, Issue 3 (Nat Sakimura) >> 2. Three things... (Robin Wilton) >> >> >> ---------- Forwarded message ---------- >> From: Nat Sakimura > > >> To: "Jones, Mark B" > >, Jim Fenton = < >> fenton@bluepopcorn.net >> >, Peter >> Alterman > >, " >> vot@ietf.org " < >> vot@ietf.org > >> Cc: >> Date: Wed, 12 Nov 2014 07:59:42 +0000 >> Subject: Re: [VoT] vot Digest, Vol 3, Issue 3 >> IMHO, everybody here should read X.1254 - ISO/IEC 29115 as a starting >> point. It has got problems, but it still is a good starting point and we= do >> not have to repeat arguing what are there without knowing them. >> >> In it, clause 10 lays out threats and controls. One of the biggest >> problem about the 29115 is that it is too prescriptive as to the control= s >> are concerned. There can be multiple ways of implementing controls and >> there always are going to be new and more shiny ones. It should have bee= n >> constructed like 27002 that everything is optional but has to achieve th= e >> objectives. >> >> (In fact, we did so for authentication phase, but other phases remained >> pretty prescriptive.) >> >> Nat >> >> On Wed Nov 12 2014 at 16:38:34 Jones, Mark B > > wrote: >> >>> One of the requirements should be that there be only as many dimensions >>> to the vector as would be actionable by a Relying Party to make an >>> authorization decision. Otherwise, the model is more complex than it ne= eds >>> to be. >>> >>> *[Jones, Mark B] * >>> >>> *Isn=E2=80=99t =E2=80=98authorization=E2=80=99 out of scope here? The = strawman document does >>> not mention authorization.* >>> >> >> >> ---------- Forwarded message ---------- >> From: Robin Wilton > > >> To: "vot@ietf.org " < >> vot@ietf.org > >> Cc: >> Date: Wed, 12 Nov 2014 12:16:03 +0000 >> Subject: [VoT] Three things... >> >> >> *From: *Joanne Knight > > >> *Subject: **Re: [VoT] vot Digest, Vol 3, Issue 3* >> *Date: *12 November 2014 04:04:29 GMT >> *To: *'Jim Fenton' > >, 'Peter >> Alterman' > >, 'Nat >> Sakimura' > > >> *Cc: *"'vot@ietf.org '" < >> vot@ietf.org > >> >> >> Greetings All >> >> I am new to this group so for the benefit of those who do not know me=E2= =80=A6 >> >> I am Joanne Knight (probably the real me but not what you will find on >> any official register) ;-) >> >> >> Hi Joanne, and welcome. Unless =E2=80=9CJoanne Knight=E2=80=9D is actual= ly another of >> Colin Wallis=E2=80=99 personas, in which case, nice try and welcome back= . >> >> >> >> >> >> >> *From:* Jim Fenton [mailto:fenton@bluepopcorn.net >> ] >> *Sent:* Wednesday, 12 November 2014 1:01 p.m. >> *To:* Peter Alterman; Nat Sakimura >> *Cc:* vot@ietf.org >> *Subject:* Re: [VoT] vot Digest, Vol 3, Issue 3 >> >> Peter, >> >> >> Finally, it sounds like we're talking past each other on the word >> "vector". We're using the word in the mathematical sense, and it appears >> you're using it in the epidemiological sense. If there's a word here I h= ave >> a quibble about, it's "trust=E2=80=9D. >> >> >> >> IIRC, Leif has already made the point that =E2=80=9Cvector=E2=80=9D was = chosen more or >> less on the spur of the moment during the Utrecht workshop; looking at t= he >> kinds of thing people are grouping under that term, it feels to me (as t= o >> Peter) that =E2=80=9Cfactor=E2=80=9D would serve as well. I know that=E2= =80=99s not very helpful >> now that the mailing list already has a V in it, sorry. >> >> Unless I misunderstand it, we are talking about =E2=80=9Cthe things that >> contribute, positively or negatively, to the trustworthiness of an ident= ity >> assertion=E2=80=9D. This also relates partly to a further comment, below= , on >> something Peter said. >> >> >> >> >> >> On 11/11/14 3:09 PM, Peter Alterman wrote: >> >> Nat et. al. >> >> Let's not reason backwards from use cases but forwards from expertise. >> There are a zillion use cases out there that can be generated for any mo= del >> (sort of like a cost/benefit analysis - just tell the analyst what answe= r >> you want and let him/her crank out the sausage). Rather, what are the >> legitimate components of an identity assertion; what's the nature of the >> relationship among them? Nothing I've seen so far changes my opinion tha= t >> there are four variables: strength of identity proofing (measured agains= t a >> benchmark that incorporates *both* 800-63 and 29115); intrinsic resistan= ce >> of credential type to attack (see prior benchmarking comment); credentia= l >> management (how well it addresses the threat vectors in 29115 and aligns >> with 800-63 processes, and exchange, which incorporates mitigation of da= ta >> in motion threat vectors listed in 29115 relevant to AuthN. >> >> Also agree that the AuthN process is not part of determining the >> trustworthiness (rat hole warning) of an online identity assertion but t= he >> process of making such a determination. >> >> >> I mostly agree, but I think that the lifecycle of a credential gives us = a >> good basis for drawing up a shortlist of the things that make the result= ing >> assertions of identity trustworthy. If you do, you get a very similar li= st >> to the one Nat mentions, and phases that reflect Joanne=E2=80=99s commen= ts too. >> >> >> - the initial registration/verification/enrolment phase ("proofing") >> - the issue of credentials (encapsulating attributes and binding the >> result to the individual somehow) >> - presentation of the credentials over time >> - validation of the credentials (a.k.a. Authentication) >> - other lifecycle bits like revocation/amendment/destruction >> >> >> (Nat makes the point, below, that most RPs don=E2=80=99t care about iden= tity >> proofing. I=E2=80=99m sure he is right, but since we=E2=80=99re trying t= o tease out all the >> things that underpin the reliability of an identity assertion, I think w= e >> need to be more explicit; RPs don=E2=80=99t care because they will assum= e either >> that proofing has been done adequately, or that if they rely on a valid >> credential that has been incorrectly issued, the liability will rest wit= h >> the issuer. But I=E2=80=99d argue that those are trust factors too.) >> >> Last: I=E2=80=99m worried that Peter=E2=80=99s final sentence above is o= pen to >> misinterpretation. If any of the phases I=E2=80=99ve just listed is not = reliable, >> it undermines trust in the outcome (which is, ideally, justified relianc= e >> on an assertion of identity). If the authentication step is trivial, >> cursory, superficial, spoofable, insecure, call it what you will - then >> someone relying on its outcome could be mistaken. >> >> >> >> Finally, scalar is not vector. C'mon guys, give an old man a break. We'r= e >> talking factors, not vectors. As an example, a threat vector is an ident= ity >> assertion threat aimed at someone or some process: it has strength and i= t >> has direction. >> >> regards, >> >> Peter >> >> >> ------------------------------------------------------------ >> Peter Alterman, Ph.D. >> Chief Operating Officer >> SAFE-BioPharma Association >> >> cell: 301-943-7452 >> >> On Tue, Nov 11, 2014 at 5:28 PM, Nat Sakimura > > wrote: >> In many cases, people do not care about Identity Proofing. As long as th= e >> credential management and after is done right, it should not matter in m= any >> commercial use case. So, in the previous expression, to some of my use >> cases, I am indifferent with (1, 2, 2, 2) and (4, 2, 2, 2). In the >> traditional SP800-63 case, however, the former is 0 and later is 2, maki= ng >> (1, 2, 2, 2) and (1, 1, 1, 1) indifferent, losing the information I was >> interested in. Also, I may want to accept (1,2,2,1) on a intranet while = I >> am only willing to accept (1,2,2,2) over the internet. Justin was arguin= g >> to collapse the middle two, and that may well be a good simplification. = In >> this case, I still care those three dimensions instead of four. >> >> As to the attribute reliability is concerned, the room concluded that it >> is out of scope for VoT for now, that we should only concentrate on enti= ty >> authentication assurance. The quality of attribute should be treated mor= e >> like a metadata about each attribute instead. >> >> For the Enrollment, Credential Management, Authentication, refer to >> ISO/IEC 29115 or ITU-T X.1254, which are almost identical apart from the >> formatting and 3 words. X.1254 is freely available. You can find them he= re: >> https://www.itu.int/rec/T-REC-X.1254-201209-I/en >> >> Nat >> >> >> On Wed Nov 12 2014 at 6:53:11 Jim Fenton > > wrote: >> One of the requirements should be that there be only as many dimensions >> to the vector as would be actionable by a Relying Party to make an >> authorization decision. Otherwise, the model is more complex than it nee= ds >> to be. >> >> I'm not sure I understand how Enrollment, Credential Management, >> Authentication, and Assertion Transmission are defined (if that was >> discussed on the list, I'd appreciate a pointer to it). But as a relying >> party, if the quality of an attribute I receive is limited by something,= I >> probably don't care whether it was because the credential management or = the >> assertion transmission was the cause. >> >> So if this retains 4 dimensions, there should be use cases that justify >> the need for 4. I can do that for 2 dimensions (authentication >> strength/attribute reliability) by considering uses like strong >> pseudonymous authentication with a trustable assertion of an attribute l= ike >> age. I don't have any good examples for more than 2. >> >> >> -Jim >> >> >> On 11/11/14 1:34 PM, Nat Sakimura wrote: >> >> We had a bar-bof last night at IETF 91. >> There was a discussion that perhaps instead of three dimension "Identity >> Proofing / Credential Binding / Assertion Transmission", perhaps 4 >> dimension "Enrollment/Credential management/Authentication/Assertion >> Transmission" is more appropriate. The reason was that Identity Proofing= is >> only a step in Enrollment, Credential Binding is only a step in Credenti= al >> Management, and the use of credential, i.e., Authentication, is importan= t >> enough to separate out from Credential Management. Then, there followed = a >> lengthy discussion about whether to pull Authentication out. >> >> As to the "vector" is concerned, it indeed seem to be a vector to me in >> the sense that: >> >> *v* =3D (e, c, a, t) >> where e:=3Dscalar value for expressing Enrollment quality >> c:=3Dscalar value for expressing Credential Management quality >> a:=3Dscalar value for expressing Authentication quality >> t:=3Dscalar value for expressing Assertion Transmission quality. >> >> There was discussion on how to obtain these values as well. The room >> opinion was that we should define the response format and then use it to >> define the request format. >> >> Also, there was a discussion around the nature of the value of each >> scalar above, and the granularity desired. >> We were not even sure if the values are going to be an ordered set. >> Everybody agreed that simplicity is a requirement for widespread adoptio= n. >> If granularity were sought, then it should be defined as a subset of par= ent >> value so that implementation that do not care about these can safely ign= ore >> them. >> >> Apart from the above, importance of the operational quality of IdPs were >> expressed. This seem to be the quality which should be transmitted not p= er >> authentication transaction but separately, perhaps from .well-known >> resource. >> >> FYI, the room also had the opinion that we should not get into the >> "quality of attributes" in general but focus only to the entity >> authentication, at least for this round. >> >> Cheers, >> >> Nat >> >> >> >> >> On Wed Nov 12 2014 at 5:25:56 Peter Alterman < >> palterman@safe-biopharma.org >> > wrote: >> Pardon me not diddling with the strawman. A quick read generated the >> comments following. Hope they are helpful in evolving the document. >> >> What is immediately missing is a value for the quality of the credential >> technology because some credential types are inherently less secure - or >> risk mitigating - than others. >> >> My second observation is that it is not yet clear to me why these >> elements are called vectors. Vectors are expressions of quantities in >> spacio-temporal directions. So far I see three (and the fourth I recomme= nd >> here) factors. In order to consider them vectors, please show me a plot = on >> a graph and label the axes and the measurement units. >> >> My third observation is that I do not see any straightforward way for th= e >> factors to be collapsed. There are no approaches to do so presented, >> either. First question to ask here is whether the ecosystem will need to >> deploy both a transmission protocol and a receiving protocol? If the >> methodology requires broad uptake of RP software in order to decode the >> transmitted factors, the Hydra is unleashed. >> >> thanks, >> >> Peter >> >> ------------------------------------------------------------ >> Peter Alterman, Ph.D. >> Chief Operating Officer >> SAFE-BioPharma Association >> >> cell: 301-943-7452 >> >> On Tue, Nov 11, 2014 at 3:02 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. Document in GitHub (Richer, Justin P.) >> >> >> ---------- Forwarded message ---------- >> From: "Richer, Justin P." > > >> To: "vot@ietf.org " < >> vot@ietf.org > >> Cc: >> Date: Mon, 10 Nov 2014 21:07:53 +0000 >> Subject: [VoT] Document in GitHub >> I've started the work of translating much of my original strawman >> document to Markdown and pushing it to GitHub so that we can start takin= g >> edits via pull request: >> >> >> https://github.com/vectorsoftrust/strawman/blob/master/VectorsOfTrust.md >> >> Clone and fork away! >> >> -- Justin >> >> >> _______________________________________________ >> 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 >> >> >> >> >> _______________________________________________ >> 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 >> >> > --001a11339dae573f880507adf16c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable My thoughts on Peter's thoughts inline [[KD: thought]]. I agree fully w= ith what you said Peter. Ken


On Wednesday, November 12, 2014, P= eter Alterman <palterman= @safe-biopharma.org> wrote:
Hi Joanne. = Thanks for the shout out.=C2=A0

[[KD: Here, here=C2=A0Peter. I am also not comfortable with the word but= I too want to move beyond what it is called and focus on what it is trying= to accomplish]]=C2=A0Here are a few thoughts on the various comments I rea= d over morning coffee: first, I use vector in the Physics 101 sense, Nat, b= ut I will now leave this annoyance behind and allow you the terminology you= feel comfortable using. (Yes, before I got all these pesky literature degr= ees I majored in physics and even attended lectures on chirality by C.N. Ya= ng.)=C2=A0

[[KD: Again here, = here. There are several operational environments that need to be accommodat= ed ... rather than revolutionized. The RPs in those environments have alrea= dy made their decisions regarding what attributes they need to mitigate the= ir identity authentication requirements.]]=C2=A0Next, before addressing the= quite legitimate question of what we mean by extended attributes, etc., we= must resist reinventing/re-conceiving operational models. In principle the= set of attributes required by a RP may vary from case to case but there al= ready exists a vast operating ecosystem that has already determined what th= at set of attributes is and how to deal with it. I resist any attempt to fi= ddle with that, while I am open to new, useful, practical ways to measure i= dentity attributes and to express them. Many use cases care not a whit for = this set, many will want others, as Nat has described (I agree we are in th= at strange window of argumentative mutual agreement). Currently, this is ha= ndled on a relationship-by-relationship basis with attributes that are not = included in the generic identity attribute set or which are included but ig= nored by a general-purpose AuthN process. Extended attributes are the kitch= en sink of online AuthN + AuthZ and they can consist of any unit of data ab= out a natural person or a thing. To avoid the rat hole, simply accept the f= act that there is a widely-used set of personal (or machine or code) attrib= utes generally accepted as identity-asserting attributes and move on. Other= attributes simply add to the utility of the online identity assertion and = beg a universal method of expression.

[[KD: I too want to see a=C2=A0way to collapse {3:1:2:4} into so= mething an e-commerce or e-gov RP can use and I'm all on board. Prefera= bly using existing tools such as SAML, XACML, WS-Fed, etc.=C2= =A0this is in line with my "let's evolve rather than revolutionize= .=C2=A0]]=C2=A0+1 on the comment that RPs may have little or no interest in= an online identity assertion reliability rating of {3:1:2:4}. This is, to = me, the place where the theoretical crosses the line to useless. The social= domain cares less than nothing about any of this, the e-commerce domain ca= res about the history of my credit card account paying for things bought on= line, governments and financial institutions need high assurances of identi= ty addressed by ETSI QCP and Fed PKI and FICAM. While I do appreciate the w= ork that GTRI has done under grant from NSTIC to decompose AuthN, I think i= t results in a conceptual model that doesn't align with the needs of th= e real world. Now, show me a way to collapse {3:1:2:4} into something an e-= commerce or e-gov RP can use and I'm all on board. Preferably using exi= sting tools such as SAML, XACML, WS-Fed, etc.

[[KD: I agree fully Peter. Use cases have a place in tes= ting models. ]]=C2=A0Finally, regarding use cases: I thank you Jim for your= desire to simplify all this. I believe that use cases are valuable to test= models, not to build them. Too often they are misused for the latter, not = the former, IMO, and that leads to destructive stuff like a health care gro= up lobbying NIST to define an LOA of 2.5 to satisfy the use cases they crea= ted. That's all I am saying.

regards,

=
Peter


------------------------------------------------------------
Pet= er Alterman, Ph.D.
Chief Operating Officer
SAFE-BioPharma Assoc= iation
cell: 301-943-7452


On Wed, Nov 12, 2014 at 7:16 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: vot Digest, Vol 3, Issue 3 (Nat Sakimura)
=C2=A0 =C2=A02. Three things... (Robin Wilton)


---------- Forwarded message ----------
From:=C2=A0Nat Sakimura = <sakimura@gmail.com>
To:=C2=A0"Jone= s, Mark B" <Mark.B.Jones@uth.tmc.edu>, Jim Fenton <fenton@bluepopcorn.net&= gt;, Peter Alterman <palterman@safe-biop= harma.org>, "vot@ietf.org" <vot@ietf.org>
Cc:=C2=A0
Date:=C2=A0Wed, 12 Nov 2014 0= 7:59:42 +0000
Subject:=C2=A0Re: [VoT] vot Digest, Vol 3, Issue 3
IMHO= , everybody here should read X.1254 - ISO/IEC 29115 as a starting point. It= has got problems, but it still is a good starting point and we do not have= to repeat arguing what are there without knowing them.=C2=A0

<= /div>
In it, clause 10 lays out threats and controls. One of the bigges= t problem about the 29115 is that it is too prescriptive as to the controls= are concerned. There can be multiple ways of implementing controls and the= re always are going to be new and more shiny ones. It should have been cons= tructed like 27002 that everything is optional but has to achieve the objec= tives.=C2=A0

(In fact, we did so for authenticatio= n phase, but other phases remained pretty prescriptive.)=C2=A0
Nat

On Wed Nov 12 2014 at = 16:38:34 Jones, Mark B <Mark.B.Jones@uth.tmc= .edu> wrote:

One of the requirements should be that there be only as many dimensions to= the vector as would be actionable by a Relying Party to make an authorizat= ion decision. Otherwise, the model is more complex than it needs to be.
=

[Jones, Mark B]

Isn=E2=80=99t =E2=80=98auth= orization=E2=80=99 out of scope here?=C2=A0 The strawman document does not = mention authorization.<= /u>



---------- Forwarded message ----------
From:=C2=A0Robin Wilton = <wilton@isoc.org>
To:=C2=A0"vot@ietf.org" <vot@ietf.org>
Cc= :=C2=A0
Date:=C2=A0Wed, 12 Nov 2014 12:16:03 +0000
Subject:=C2=A0[VoT= ] Three things...

From:=C2=A0Joanne Knight <Joanne.Knight@dia.gov= t.nz>
Subject:=C2=A0= Re: [VoT] vot Digest, Vol 3= , Issue 3
Date:=C2=A012 November 2014 04:04:29 GMT
Cc:=C2=A0"'vot@ietf.org'" <vot@ietf.org>

=
Greetings All<= /div>
=C2=A0
I am new to this group so for the benefit of those who do not kn= ow me=E2=80=A6
=C2= =A0
I am Joanne Knight (probably= the real me but not what you will find on any official register) ;-)

Hi Joanne, and welcome.= Unless =E2=80=9CJoanne Knight=E2=80=9D is actually another of Colin Wallis= =E2=80=99 personas, in which case, nice try and welcome back.


=C2=A0
=C2=A0
=C2=A0
From:=C2=A0Jim Fenton [mailto= :fenton@bluepopcorn.net]=C2=A0
Sent:=C2=A0= Wednesday, 12 November 2014 1:01 p.m.
To:=C2=A0Peter Alterman; Nat Sakimura
Cc:=C2=A0vot@ietf.org
Subject:=C2=A0Re: [VoT] vot Digest, Vol 3, Issue 3=
=C2=A0=
Peter,


Finally, it sounds like= we're talking past each other on the word "vector". We'r= e using the word in the mathematical sense, and it appears you're using= it in the epidemiological sense. If there's a word here I have a quibb= le about, it's "trust=E2=80=9D.


IIRC, Leif has already made the po= int that =E2=80=9Cvector=E2=80=9D was chosen more or less on the spur of th= e moment during the Utrecht workshop; looking at the kinds of thing people = are grouping under that term, it feels to me (as to Peter) that =E2=80=9Cfa= ctor=E2=80=9D would serve as well. I know that=E2=80=99s not very helpful n= ow that the mailing list already has a V in it, sorry.

=
Unless I misunderstand it, we are talking about =E2=80=9Cthe things th= at contribute, positively or negatively, to the trustworthiness of an ident= ity assertion=E2=80=9D. This also relates partly to a further comment, belo= w, on something Peter said.





On= 11/11/14 3:09 PM, Peter Alterman wrote:
Nat et. al.
=C2=A0
Let's not reason = backwards from use cases but forwards from expertise. There are a zillion u= se cases out there that can be generated for any model (sort of like a cost= /benefit analysis - just tell the analyst what answer you want and let him/= her crank out the sausage). Rather, what are the legitimate components of a= n identity assertion; what's the nature of the relationship among them?= Nothing I've seen so far changes my opinion that there are four variab= les: strength of identity proofing (measured against a benchmark that incor= porates *both* 800-63 and 29115); intrinsic resistance of credential type t= o attack (see prior benchmarking comment); credential management (how well = it addresses the threat vectors in 29115 and aligns with 800-63 processes, = and exchange, which incorporates mitigation of data in motion threat vector= s listed in 29115 relevant to AuthN.=C2=A0
=C2=A0
=C2=A0Also agree that the AuthN process is not part of determining th= e trustworthiness (rat hole warning) of an online identity assertion but th= e process of making such a determination.

I mostly agree, but I think that = the lifecycle of a credential gives us a good basis for drawing up a shortl= ist of the things that make the resulting assertions of identity trustworth= y. If you do, you get a very similar list to the one Nat mentions, and phas= es that reflect Joanne=E2=80=99s comments too.

  • the initial registration/verification/enrolment phase ("proofing&= quot;)
  • the issue of credentials (encapsulating attributes and bindi= ng the result to the individual somehow)
  • presentation of the creden= tials over time
  • validation of the credentials (a.k.a. Authenticatio= n)=C2=A0
  • other lifecycle bits like revocation/amendment/destruction=

    • (Nat makes the point, below, that most RPs do= n=E2=80=99t care about identity proofing. I=E2=80=99m sure he is right, but= since we=E2=80=99re trying to tease out all the things that underpin the r= eliability of an identity assertion, I think we need to be more explicit; R= Ps don=E2=80=99t care because they will assume either that proofing has bee= n done adequately, or that if they rely on a valid credential that has been= incorrectly issued, the liability will rest with the issuer. But I=E2=80= =99d argue that those are trust factors too.)

    Last= : I=E2=80=99m worried that Peter=E2=80=99s final sentence above is open to = misinterpretation. If any of the phases I=E2=80=99ve just listed is not rel= iable, it undermines trust in the outcome (which is, ideally, justified rel= iance on an assertion of identity). If the authentication step is trivial, = cursory, superficial, spoofable, insecure, call it what you will - then som= eone relying on its outcome could be mistaken.

    =
    =C2=A0
    Finally, scalar is not vector. C'mon guys, give an old man= a break. We're talking factors, not vectors. As an example, a threat v= ector is an identity assertion threat aimed at someone or some process: it = has strength and it has direction.
    =C2=A0
    re= gards,
    =C2=A0
    Peter
    =C2=A0

    -------------------------------------------------= -----------
    Peter Alterman,= Ph.D.
    Chief Operating Offi= cer
    SAFE-BioPharma Association

    cell: 301-943-7452

    =C2=A0
    On Tue, Nov= 11, 2014 at 5:28 PM, Nat Sakimura <sakimura@gmail.com> wrote:=
    In many cases, people do not care about= Identity Proofing. As long as the credential management and after is done = right, it should not matter in many commercial use case. So, in the previou= s expression, to some of my use cases, I am indifferent with (1, 2, 2, 2) a= nd (4, 2, 2, 2). In the traditional SP800-63 case, however, the former is 0= and later is 2, making (1, 2, 2, 2) and (1, 1, 1, 1) indifferent, losing t= he information I was interested in. Also, I may want to accept (1,2,2,1) on= a intranet while I am only willing to accept (1,2,2,2) over the internet. = Justin was arguing to collapse the middle two, and that may well be a good = simplification. In this case, I still care those three dimensions instead o= f four.=C2=A0
    =C2=A0<= u>
    As to the attribute reliabili= ty is concerned, the room concluded that it is out of scope for VoT for now= , that we should only concentrate on entity authentication assurance. The q= uality of attribute should be treated more like a metadata about each attri= bute instead.=C2=A0
    =C2=A0
    For the=C2=A0Enro= llment, Credential Management, Authentication, refer to ISO/IEC 29115 or IT= U-T X.1254, which are almost identical apart from the formatting and 3 word= s. X.1254 is freely available. You can find them here:=C2=A0https://www.itu.int/rec/T-REC-X.1254-= 201209-I/en
    =C2=A0
    Nat
    =C2=A0
    =C2=A0
    On We= d Nov 12 2014 at 6:53:11 Jim Fenton <fenton@bluepopcorn.net> wrot= e:
    One of the requirements s= hould be that there be only as many dimensions to the vector as would be ac= tionable by a Relying Party to make an authorization decision. Otherwise, t= he model is more complex than it needs to be.

    I'm not sure I und= erstand how Enrollment, Credential Management, Authentication, and Assertio= n Transmission are defined (if that was discussed on the list, I'd appr= eciate a pointer to it). But as a relying party, if the quality of an attri= bute I receive is limited by something, I probably don't care whether i= t was because the credential management or the assertion transmission was t= he cause.

    So if this retains 4 dimensions, there should be use cases= that justify the need for 4. I can do that for 2 dimensions (authenticatio= n strength/attribute reliability) by considering uses like strong pseudonym= ous authentication with a trustable assertion of an attribute like age. I d= on't have any good examples for more than 2.
    <= div>


    -Jim


    On 11/11/14 1:34 PM, Nat Sakimura wrote:

    We had a bar-bof last night at IETF = 91.=C2=A0

    There was a discussi= on that perhaps instead of three dimension "Identity Proofing / Creden= tial Binding / Assertion Transmission", perhaps 4 dimension "Enro= llment/Credential management/Authentication/Assertion Transmission" is= more appropriate. The reason was that Identity Proofing is only a step in = Enrollment, Credential Binding is only a step in Credential Management, and= the use of credential, i.e., Authentication, is important enough to separa= te out from Credential Management. Then, there followed a lengthy discussio= n about whether to pull Authentication out.=C2=A0
    =
    =C2=A0
    As to the "vector" is concerned, it indeed seem to b= e a vector to me in the sense that:=C2=A0
    =C2=A0
    v=C2=A0=3D (e, c, a, t)=C2=A0
    <= /div>
    =C2=A0where e:=3Dscalar value for expressi= ng Enrollment quality
    = =C2=A0c:=3Dscalar value for expressing Credential Management quality=
    =C2=A0a:=3Dscalar value for = expressing Authentication quality
    =C2=A0t:=3Dscalar value for expressing Assertion Transmission = quality.=C2=A0
    = =C2=A0
    There was discussion o= n how to obtain these values as well. The room opinion was that we should d= efine the response format and then use it to define the request format.=C2= =A0
    =C2=A0
    Also, there was a discussion arou= nd the nature of the value of each scalar above, and the granularity desire= d.=C2=A0
    We were not e= ven sure if the values are going to be an ordered set. Everybody agreed tha= t simplicity is a requirement for widespread adoption. If granularity were = sought, then it should be defined as a subset of parent value so that imple= mentation that do not care about these can safely ignore them.=C2=A0=
    =C2=A0
    Apart from the above, importance of the ope= rational quality of IdPs were expressed. This seem to be the quality which = should be transmitted not per authentication transaction but separately, pe= rhaps from .well-known resource.=C2=A0
    =C2=A0
    =C2=A0
    Cheers,=C2=A0
    =C2=A0
    Nat
    =C2=A0
    <= div style=3D"margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times = New Roman',serif">=C2=A0
    =C2=A0
    =C2=A0=
    On Wed Nov 12 2014 at 5:25:56 Pete= r Alterman <palterman@safe-biopharma.org> wrote:<= /u>
    Pardon me not diddling with the s= trawman. A quick read generated the comments following. Hope they are helpf= ul in evolving the document.
    =C2=A0
    What is = immediately missing is a value for the quality of the credential technology= because some credential types are inherently less secure - or risk mitigat= ing - than others.=C2=A0
    =C2=A0
    My second ob= servation is that it is not yet clear to me why these elements are called v= ectors. Vectors are expressions of quantities in spacio-temporal directions= . So far I see three (and the fourth I recommend here) factors. In order to= consider them vectors, please show me a plot on a graph and label the axes= and the measurement units.
    =C2=A0
    My third = observation is that I do not see any straightforward way for the factors to= be collapsed. There are no approaches to do so presented, either. First qu= estion to ask here is whether the ecosystem will need to deploy both a tran= smission protocol and a receiving protocol? If the methodology requires bro= ad uptake of RP software in order to decode the transmitted factors, the Hy= dra is unleashed.
    <= /u>=C2=A0
    thanks,
    =C2=A0
    <= div>
    Peter

    =
    ----------------------------------------------------= --------
    Peter Alterman, Ph= .D.
    Chief Operating Officer=
    SAFE-BioPharma Association

    cell:=C2=A0301-943-7452=

    =C2=A0
    On Tue, Nov 11, 2014 at 3:02 PM, <vot-reque= st@ietf.org> wrote:

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

    To subscribe or unsubscribe via the Wor= ld Wide Web, visit
    =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0https://www.ietf.org/mailman/listinf= o/vot
    or, via email, send a message with subject or body 'help&#= 39; to
    =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0vot-request@ietf.org<= /a>

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

    When replying, pl= ease edit your Subject line so it is more specific
    than "Re: Conten= ts of vot digest..."

    Today's Topics:

    =C2=A0 =C2=A01.= Document in GitHub (Richer, Justin P.)


    ---------- Forwarded mes= sage ----------
    From:=C2=A0"Richer, Justin P." <jricher@mitre.or= g>
    To:=C2=A0"vot@ietf.org" <vot@ietf.org>
    Cc:=C2=A0
    Dat= e:=C2=A0Mon, 10 Nov 2014 21:07:53 +0000
    Subject:=C2=A0[VoT] Document in = GitHub
    I've started the work of translating much of my original stra= wman document to Markdown and pushing it to GitHub so that we can start tak= ing edits via pull request:

    =C2=A0=C2=A0https://githu= b.com/vectorsoftrust/strawman/blob/master/VectorsOfTrust.md

    Clon= e and fork away!

    =C2=A0-- Justin


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

    =C2=A0
    _______________________________________________vot mailing list
    vot@ietf.org
    https://www.ietf.org/mailman/listinfo/vot
    <= div style=3D"margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times = New Roman',serif">

    ____________=
___________________________________
    vot mai=
ling list
    vot@ietf.org
    https://www.ietf.org/ma=
ilman/listinfo/vot
    =C2=A0
    =C2=A0



    _______________________________________________<=
u>
    vot mailing list
    <=
a href=3D"javascript:_e(%7B%7D,'cvml','vot@ietf.org');" sty=
le=3D"color:purple;text-decoration:underline" target=3D"_blank">vot@ietf.or=
g
    https://www.ietf.org/mailman/listinfo/vot
    <= /blockquote>
    =C2=A0


    = _______________________________________________
    vot mailing list
    vot@ietf.org<= /a>
    https://www.ietf.org/m= ailman/listinfo/vot


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


    --001a11339dae573f880507adf16c-- From nobody Wed Nov 12 12:01:23 2014 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 A32321ACF58 for ; Wed, 12 Nov 2014 12:01:22 -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 IDnOkdjGYbMC for ; Wed, 12 Nov 2014 12:01:20 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0761.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::761]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 665001AD033 for ; Wed, 12 Nov 2014 12:00:59 -0800 (PST) Received: from BY2FFO11FD019.protection.gbl (10.1.14.30) by BY2FFO11HUB050.protection.gbl (10.1.14.89) with Microsoft SMTP Server (TLS) id 15.1.6.13; Wed, 12 Nov 2014 20:00:35 +0000 Received: from cio-tnc-pf08.osuad.osu.edu (164.107.81.222) by BY2FFO11FD019.mail.protection.outlook.com (10.1.14.107) with Microsoft SMTP Server (TLS) id 15.1.6.13 via Frontend Transport; Wed, 12 Nov 2014 20:00:35 +0000 Received: from CIO-TNC-HT05.osuad.osu.edu (cio-tnc-ht05.osuad.osu.edu [164.107.81.168]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by cio-tnc-pf08.osuad.osu.edu (Postfix) with ESMTPS id B6E282E0076; Wed, 12 Nov 2014 15:00:33 -0500 (EST) Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-TNC-HT05.osuad.osu.edu ([fe80::d0be:603:484c:5a2f%10]) with mapi id 14.03.0174.001; Wed, 12 Nov 2014 15:00:32 -0500 From: "Cantor, Scott" To: Peter Alterman , "vot@ietf.org" Thread-Topic: [VoT] vot Digest, Vol 3, Issue 11 Thread-Index: AQHP/pEjPHVyjGocgUC9zEt+lPt1EJxdaX+A Date: Wed, 12 Nov 2014 20:00:32 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [140.254.59.82] Content-Type: text/plain; charset="utf-8" Content-ID: <74FEB7ABA64761428B871F3FDB4ADCCE@osu.edu> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:164.107.81.222; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(438002)(24454002)(51704005)(10533002)(199003)(5403001)(189002)(18543002)(479174003)(377454003)(99396003)(6806004)(4396001)(19580395003)(120916001)(109096001)(76176999)(83716003)(90282001)(75432002)(50466002)(77096003)(44976005)(19580405001)(62966003)(2501002)(77156002)(20776003)(46102003)(54356999)(87936001)(31966008)(2656002)(106466001)(95666004)(21056001)(93346002)(86362001)(36756003)(66066001)(92726001)(89122001)(107886001)(23676002)(64706001)(106116001)(33656002)(88552001)(92566001)(47776003)(107046002)(50986999)(82746002)(104396001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2FFO11HUB050; H:cio-tnc-pf08.osuad.osu.edu; FPR:; MLV:sfv; PTR:cio-tnc-pf08.osuad.osu.edu; A:1; MX:1; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BY2FFO11HUB050; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA: BCL:0;PCL:0;RULEID:;SRVR:BY2FFO11HUB050; X-Forefront-PRVS: 03932714EB Received-SPF: Pass (protection.outlook.com: domain of osu.edu designates 164.107.81.222 as permitted sender) receiver=protection.outlook.com; client-ip=164.107.81.222; helo=cio-tnc-pf08.osuad.osu.edu; Authentication-Results: spf=pass (sender IP is 164.107.81.222) smtp.mailfrom=cantor.2@osu.edu; X-Exchange-Antispam-Report-CFA: BCL:0;PCL:0;RULEID:;SRVR:BY2FFO11HUB050; X-OriginatorOrg: osu.edu Archived-At: http://mailarchive.ietf.org/arch/msg/vot/HcRcI9gUOt-vRDmNAtPaOsOHmMM Subject: Re: [VoT] vot Digest, Vol 3, Issue 11 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, 12 Nov 2014 20:01:22 -0000 T24gMTEvMTIvMTQsIDM6NTUgUE0sICJQZXRlciBBbHRlcm1hbiIgPHBhbHRlcm1hbkBzYWZlLWJp b3BoYXJtYS5vcmc+IA0Kd3JvdGU6DQo+DQo+RmluYWxseSwgcmVnYXJkaW5nIHVzZSBjYXNlczog SSB0aGFuayB5b3UgSmltIGZvciB5b3VyIGRlc2lyZSB0byBzaW1wbGlmeSANCj5hbGwgdGhpcy4g SSBiZWxpZXZlIHRoYXQgdXNlIGNhc2VzIGFyZSB2YWx1YWJsZSB0byB0ZXN0IG1vZGVscywgbm90 IHRvIA0KPmJ1aWxkIHRoZW0uIFRvbyBvZnRlbiB0aGV5IGFyZSBtaXN1c2VkIGZvciB0aGUgbGF0 dGVyLCBub3QgdGhlDQo+IGZvcm1lciwgSU1PLCBhbmQgdGhhdCBsZWFkcyB0byBkZXN0cnVjdGl2 ZSBzdHVmZiBsaWtlIGEgaGVhbHRoIGNhcmUgDQo+Z3JvdXAgbG9iYnlpbmcgTklTVCB0byBkZWZp bmUgYW4gTE9BIG9mIDIuNSB0byBzYXRpc2Z5IHRoZSB1c2UgY2FzZXMgdGhleSANCj5jcmVhdGVk LiBUaGF0J3MgYWxsIEkgYW0gc2F5aW5nLg0KDQpUaGF0J3Mgbm90IGRlc3RydWN0aXZlLCB0aGF0 J3MganVzdCBldmlkZW5jZSB0aGF0IDgwMC02MyBpcyBub3QgdGhlIHJpZ2h0IA0KYmFzaXMgZm9y IGFuIGFzc3VyYW5jZSBmcmFtZXdvcmssIGJlY2F1c2UgcHJldHR5IG11Y2ggZXZlcnkgZ3JvdXAg SSd2ZSANCmV2ZXIgbWV0IHdpdGggaGFzIHJlYWNoZWQgdGhlIGNvbmNsdXNpb24gdGhhdCB0aGVp ciBuZWVkcyBhcmUgbWV0IGJ5IG5vbmUgDQpvZiB0aGUgZXhpc3RpbmcgbGV2ZWxzLiBQcmltYXJp bHkgYmVjYXVzZSBpdCBoaWRlcyBpbXBvcnRhbnQgZGV0YWlscyBhbmQgDQpjb21iaW5lcyB1bnJl bGF0ZWQgZmFjdG9ycy4NCg0KSWYgcGVvcGxlIGRvbid0IGFncmVlIDgwMC02MyBpcyBpbmFkZXF1 YXRlLCB0aGV5IGxpa2VseSB3b24ndCBhZ3JlZSB3aXRoIA0KYW55IG91dHB1dCBvZiB0aGlzIGNv bnZlcnNhdGlvbiwgd2hhdGV2ZXIgdGhlIHJlc3VsdCBtaWdodCBiZS4NCg0KVXNlIGNhc2VzIGFy ZSB3aGVyZSB5b3UgZ2VuZXJhbGl6ZSBmcm9tLiBJIGFtIG1vcmUgb2YgYSBnZW5lcmFsaXplciB0 aGFuIGEgDQpsb3Qgb2YgcGVvcGxlIGFyZSwgYnV0IEkgZG9uJ3QgZ28gc28gZmFyIGFzIHRvIHNh eSB0aGF0IEkgZG9uJ3Qgc3RhcnQgDQp0aGVyZS4NCg0KLS0gU2NvdHQNCg0K From nobody Wed Nov 12 13:31:44 2014 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 E45441A882C for ; Wed, 12 Nov 2014 13:31:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MSGID_FROM_MTA_HEADER=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 dW3Xn6dDVgAn for ; Wed, 12 Nov 2014 13:31:33 -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 28FDE1A914E for ; Wed, 12 Nov 2014 13:31:06 -0800 (PST) Received: from s111-0006-lnv01 (Not Verified[127.0.0.1]) by smtp.safecom.net.nz (using TLS: SSLv23) id ; Thu, 13 Nov 2014 10:31:04 +1300 Message-ID: <147EE18440E5AF44834B220ED35BA530D32FF7CC@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 2021321984; Thu, 13 Nov 2014 10:31:04 +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, 13 Nov 2014 10:29:34 +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, 13 Nov 2014 10:31:03 +1300 From: Colin Wallis To: "'Cantor, Scott'" , Peter Alterman , "vot@ietf.org" Thread-Topic: [VoT] vot Digest, Vol 3, Issue 11 Thread-Index: AQHP/pElxArq7jNp7U68PHGOyBrgipxcj5AAgADwZPA= Date: Wed, 12 Nov 2014 21:29:33 +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="us-ascii" Content-Transfer-Encoding: quoted-printable X-sdp.mm2006: true Archived-At: http://mailarchive.ietf.org/arch/msg/vot/OpnQxKMYHGiLcAosE3e42FZ7iW4 Subject: Re: [VoT] vot Digest, Vol 3, Issue 11 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, 12 Nov 2014 21:31:42 -0000 <> <> And that folks, was why this list was started. I appreciate that that would be much clearer to people in the room in Utrec= ht than others who joined in later. There was no intention to create something else that could map to 800-63. The intention was to brainstorm some ideas on alternative constructs to 800= -63. Cheers Colin -----Original Message----- From: vot [mailto:vot-bounces@ietf.org] On Behalf Of Cantor, Scott Sent: Thursday, 13 November 2014 9:01 a.m. To: Peter Alterman; vot@ietf.org Subject: Re: [VoT] vot Digest, Vol 3, Issue 11 On 11/12/14, 3:55 PM, "Peter Alterman" wrote: > >Finally, regarding use cases: I thank you Jim for your desire to=20 >simplify all this. I believe that use cases are valuable to test=20 >models, not to build them. Too often they are misused for the latter,=20 >not the former, IMO, and that leads to destructive stuff like a health=20 >care group lobbying NIST to define an LOA of 2.5 to satisfy the use=20 >cases they created. That's all I am saying. That's not destructive, that's just evidence that 800-63 is not the right b= asis for an assurance framework, because pretty much every group I've ever = met with has reached the conclusion that their needs are met by none of the= existing levels. Primarily because it hides important details and combines= unrelated factors. If people don't agree 800-63 is inadequate, they likely won't agree with an= y output of this conversation, whatever the result might be. Use cases are where you generalize from. I am more of a generalizer than a = lot of people are, but I don't go so far as to say that I don't start there= . -- Scott _______________________________________________ vot mailing list vot@ietf.org https://www.ietf.org/mailman/listinfo/vot From nobody Wed Nov 12 13:47:41 2014 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 35D9A1ACC81 for ; Wed, 12 Nov 2014 13:47:40 -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 AS3SUGqnzTRX for ; Wed, 12 Nov 2014 13:47:38 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0728.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::728]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7C031ACC8A for ; Wed, 12 Nov 2014 13:47:33 -0800 (PST) Received: from BN1AFFO11FD025.protection.gbl (10.58.52.30) by BN1AFFO11HUB044.protection.gbl (10.58.52.155) with Microsoft SMTP Server (TLS) id 15.1.6.13; Wed, 12 Nov 2014 21:47:11 +0000 Received: from cio-tnc-pf04.osuad.osu.edu (164.107.81.218) by BN1AFFO11FD025.mail.protection.outlook.com (10.58.52.85) with Microsoft SMTP Server (TLS) id 15.1.6.13 via Frontend Transport; Wed, 12 Nov 2014 21:47:11 +0000 Received: from CIO-TNC-HT07.osuad.osu.edu (cio-tnc-ht07.osuad.osu.edu [164.107.81.174]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by cio-tnc-pf04.osuad.osu.edu (Postfix) with ESMTPS id BDF0C380034; Wed, 12 Nov 2014 16:47:10 -0500 (EST) Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-TNC-HT07.osuad.osu.edu ([fe80::3ca1:e895:a165:1359%10]) with mapi id 14.03.0174.001; Wed, 12 Nov 2014 16:47:10 -0500 From: "Cantor, Scott" To: Colin Wallis , "vot@ietf.org" Thread-Topic: [VoT] vot Digest, Vol 3, Issue 11 Thread-Index: AQHP/pEjPHVyjGocgUC9zEt+lPt1EJxdaX+AgABssID//7EZgA== Date: Wed, 12 Nov 2014 21:47:09 +0000 Message-ID: <512ABD6D-4A7D-4707-BEE6-CEC23E1617CA@osu.edu> References: <147EE18440E5AF44834B220ED35BA530D32FF7CC@WLGPRDMBX01.dia.govt.nz> In-Reply-To: <147EE18440E5AF44834B220ED35BA530D32FF7CC@WLGPRDMBX01.dia.govt.nz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [140.254.59.82] Content-Type: text/plain; charset="utf-8" Content-ID: <9CBB15CD72ADBC4485D9198D30DB2C4A@osu.edu> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:164.107.81.218; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(438002)(199003)(10533002)(189002)(18543002)(377454003)(5403001)(24454002)(479174003)(4396001)(33656002)(77156002)(106466001)(44976005)(50466002)(106116001)(89122001)(86362001)(62966003)(92566001)(92726001)(36756003)(87936001)(19580405001)(19580395003)(23676002)(509002)(6806004)(88552001)(77096003)(2656002)(50986999)(93346002)(107886001)(109096001)(82746002)(99396003)(75432002)(47776003)(66066001)(90282001)(64706001)(46102003)(21056001)(95666004)(120916001)(83716003)(107046002)(2501002)(54356999)(93886004)(20776003)(76176999)(31966008)(104396001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1AFFO11HUB044; H:cio-tnc-pf04.osuad.osu.edu; FPR:; MLV:ovrnspm; PTR:cio-tnc-pf04.osuad.osu.edu; A:1; MX:1; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1AFFO11HUB044; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA: BCL:0;PCL:0;RULEID:;SRVR:BN1AFFO11HUB044; X-Forefront-PRVS: 03932714EB Received-SPF: Pass (protection.outlook.com: domain of osu.edu designates 164.107.81.218 as permitted sender) receiver=protection.outlook.com; client-ip=164.107.81.218; helo=cio-tnc-pf04.osuad.osu.edu; Authentication-Results: spf=pass (sender IP is 164.107.81.218) smtp.mailfrom=cantor.2@osu.edu; X-Exchange-Antispam-Report-CFA: BCL:0;PCL:0;RULEID:;SRVR:BN1AFFO11HUB044; X-OriginatorOrg: osu.edu Archived-At: http://mailarchive.ietf.org/arch/msg/vot/_FLOk3fdfipHNVsGQT_BBS78Yec Subject: Re: [VoT] vot Digest, Vol 3, Issue 11 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, 12 Nov 2014 21:47:40 -0000 T24gMTEvMTIvMTQsIDk6MjkgUE0sICJDb2xpbiBXYWxsaXMiIDxDb2xpbi5XYWxsaXNAZGlhLmdv dnQubno+IHdyb3RlOg0KDQo+VGhlcmUgd2FzIG5vIGludGVudGlvbiB0byBjcmVhdGUgc29tZXRo aW5nIGVsc2UgdGhhdCBjb3VsZCBtYXAgdG8gODAwLTYzLg0KPlRoZSBpbnRlbnRpb24gd2FzIHRv IGJyYWluc3Rvcm0gc29tZSBpZGVhcyBvbiBhbHRlcm5hdGl2ZSBjb25zdHJ1Y3RzIHRvIA0KPjgw MC02My4NCg0KSSB0aGluayBzb21lIHBlb3BsZSBmZWVsIHRoZXJlJ3MgdmFsdWUgaW4gYmVpbmcg YWJsZSB0byBkbyB0aGF0IG1hcHBpbmcsIA0KYW5kIEkgd29uJ3QgdHJ5IHRvIGRpc3N1YWRlIHRo ZW0sIHRob3VnaCBJJ20gbm90IGFtb25nIHRoZW0uDQoNCi0tIFNjb3R0DQoNCg== From nobody Mon Nov 17 11:35:07 2014 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 A298F1A01EA for ; Mon, 17 Nov 2014 11:34:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.595 X-Spam-Level: X-Spam-Status: No, score=-0.595 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RP_MATCHES_RCVD=-0.594] 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 YQy8FW2ZfLGV for ; Mon, 17 Nov 2014 11:34:51 -0800 (PST) Received: from smtpvbsrv1.mitre.org (smtpvbsrv1.mitre.org [198.49.146.234]) by ietfa.amsl.com (Postfix) with ESMTP id 6FC071A01EC for ; Mon, 17 Nov 2014 11:34:29 -0800 (PST) Received: from smtpvbsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id EF59DB2E061; Mon, 17 Nov 2014 14:34:28 -0500 (EST) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpvbsrv1.mitre.org (Postfix) with ESMTP id D4D89B2E067; Mon, 17 Nov 2014 14:34:28 -0500 (EST) Received: from IMCMBX01.MITRE.ORG ([169.254.1.102]) by IMCCAS01.MITRE.ORG ([129.83.29.68]) with mapi id 14.03.0174.001; Mon, 17 Nov 2014 14:34:28 -0500 From: "Richer, Justin P." To: "Cantor, Scott" Thread-Topic: [VoT] vot Digest, Vol 3, Issue 11 Thread-Index: AQHQAp2AmBhQ4hMTWU+XtZz9VROedA== Date: Mon, 17 Nov 2014 19:34:27 +0000 Message-ID: <4B90F149-A36B-49B4-91AD-371A5DF0F15D@mitre.org> References: <147EE18440E5AF44834B220ED35BA530D32FF7CC@WLGPRDMBX01.dia.govt.nz> <512ABD6D-4A7D-4707-BEE6-CEC23E1617CA@osu.edu> In-Reply-To: <512ABD6D-4A7D-4707-BEE6-CEC23E1617CA@osu.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.146.15.76] Content-Type: text/plain; charset="us-ascii" Content-ID: <7A259F27A12F424F8BA5D105981E241E@imc.mitre.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/vot/Ys4Q8aFvjfULAqpxr1DgbI0jJ3Y Cc: Colin Wallis , "vot@ietf.org" Subject: Re: [VoT] vot Digest, Vol 3, Issue 11 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, 17 Nov 2014 19:34:55 -0000 One important note about the mapping, to either 800-63 or any other trust c= onstruction: I think it's vitally important that we do *not* collapse the values before = they hit the RP. It's up to the RP (and its attendant policy engines) to ma= ke sense of {1:3:4:1} in its own context. As nat points out, the RP might d= ecide that {1:3:4:1} and {4:3:1:2} are equivalent because all it cares abou= t, for its purposes, are the the "3" value in the second field. And maybe i= t doesn't want a "0" in the first column, but the other two don't matter. O= r maybe it only believes a "4" in the first column from a single provider t= hat it knows about through a contractual relationship. I don't think we're = doing any favors of trying to prematurely project these vectors of values b= ack into single scalars, which has been called for a few times.=20 I think this is an artifact of thinking of this in terms of a "new way to d= efine LOA". Instead, what we're looking at is an alternative expression mec= hanism. Something that's more expressive than LoA 1-4, but not at the compl= exity level of an arbitrary set of attributes being tossed about.=20 Where the mapping does make sense is in the context of some kind of trust f= ramework, which can determine which vectors map to which things within the = trust framework. This would further simplify the processing for the RP, but= it is important that the IdP would communicate to the RP in un-mapped form= at. This will, I believe, help us avoid "LoA 2.5" because now the definitio= n of LoA or its equivalent are properly in the hands of the party making th= e final decision: the RP.=20 But that said, I still don't want to necessarily define that mapping here i= n this group, as I think it's premature at best and a disservice without co= ntext at worst. I'm not going to try to stand in the way of people who want= to do that, but it's not what we're after here.=20 -- Justin On Nov 12, 2014, at 4:47 PM, Cantor, Scott wrote: > On 11/12/14, 9:29 PM, "Colin Wallis" wrote: >=20 >> There was no intention to create something else that could map to 800-63= . >> The intention was to brainstorm some ideas on alternative constructs to= =20 >> 800-63. >=20 > I think some people feel there's value in being able to do that mapping,= =20 > and I won't try to dissuade them, though I'm not among them. >=20 > -- Scott >=20 > _______________________________________________ > vot mailing list > vot@ietf.org > https://www.ietf.org/mailman/listinfo/vot From nobody Mon Nov 17 12:49:02 2014 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 BDCC01A9128 for ; Mon, 17 Nov 2014 12:49:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MSGID_FROM_MTA_HEADER=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 CkGmKFJ0hq8J for ; Mon, 17 Nov 2014 12:48:58 -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 1DF111A9141 for ; Mon, 17 Nov 2014 12:48:36 -0800 (PST) Received: from s111-0006-lnv01 (Not Verified[127.0.0.1]) by smtp.safecom.net.nz (using TLS: SSLv23) id ; Tue, 18 Nov 2014 09:48:34 +1300 Message-ID: <569AD906E45DB44A8AFF11D61F5DA791D34F874F@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 1378097717; Tue, 18 Nov 2014 09:48:33 +1300 (NZDT) Received: from WLGPRDCAS01.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, 18 Nov 2014 09:47:45 +1300 Received: from WLGPRDMBX01.dia.govt.nz ([fe80::13e:8e96:252b:e0d1]) by WLGPRDCAS01.dia.govt.nz ([127.0.0.1]) with mapi id 14.03.0146.000; Tue, 18 Nov 2014 09:48:33 +1300 From: Joanne Knight To: "'Richer, Justin P.'" , "'Cantor, Scott'" Thread-Topic: In support of Justin Thread-Index: AdACp2wEqSQJpzSfQXKZQzDN5ORSJw== Date: Mon, 17 Nov 2014 20:47:44 +0000 Accept-Language: en-NZ, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.0.162] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-sdp.mm2006: true Archived-At: http://mailarchive.ietf.org/arch/msg/vot/q8IEWv6bi8cFY94qhycezNwfD1o Cc: Colin Wallis , "'vot@ietf.org'" Subject: [VoT] In support of Justin 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, 17 Nov 2014 20:49:00 -0000 Thank you Justin for expressing so well the conclusion that I have also com= e to. Rendering the {n:n:n:n} to a single scalar has very limited application and= tells a somewhat misleading story. I am also of a mind that each scale of values for each of the fields in {n:= n:n:n} may potentially be different. The identity proofing field, which I a= m working on for ISO/IEC 29003 currently has 1,2,3a,3b and 4. Whether we wi= ll be able to produce a hierarchy between 3a and 3b is yet to be seen, but = this would result in a scale of 5. Once I have refined it a little more I h= ope to be able to circulate it for your thoughts and debate.=20 Presentation as {n:n:n:n} will allow scales that are fit for purpose rathe= r than shaped by the proverbial cookie cutter. Vot digest is currently my favourite read - thanks all Joanne -----Original Message----- From: Richer, Justin P. [mailto:jricher@mitre.org]=20 Sent: Tuesday, 18 November 2014 8:34 a.m. To: Cantor, Scott Cc: Colin Wallis; vot@ietf.org Subject: Re: [VoT] vot Digest, Vol 3, Issue 11 One important note about the mapping, to either 800-63 or any other trust c= onstruction: I think it's vitally important that we do *not* collapse the values before = they hit the RP. It's up to the RP (and its attendant policy engines) to ma= ke sense of {1:3:4:1} in its own context. As nat points out, the RP might d= ecide that {1:3:4:1} and {4:3:1:2} are equivalent because all it cares abou= t, for its purposes, are the the "3" value in the second field. And maybe i= t doesn't want a "0" in the first column, but the other two don't matter. O= r maybe it only believes a "4" in the first column from a single provider t= hat it knows about through a contractual relationship. I don't think we're = doing any favors of trying to prematurely project these vectors of values b= ack into single scalars, which has been called for a few times.=20 I think this is an artifact of thinking of this in terms of a "new way to d= efine LOA". Instead, what we're looking at is an alternative expression mec= hanism. Something that's more expressive than LoA 1-4, but not at the compl= exity level of an arbitrary set of attributes being tossed about.=20 Where the mapping does make sense is in the context of some kind of trust f= ramework, which can determine which vectors map to which things within the = trust framework. This would further simplify the processing for the RP, but= it is important that the IdP would communicate to the RP in un-mapped form= at. This will, I believe, help us avoid "LoA 2.5" because now the definitio= n of LoA or its equivalent are properly in the hands of the party making th= e final decision: the RP.=20 But that said, I still don't want to necessarily define that mapping here i= n this group, as I think it's premature at best and a disservice without co= ntext at worst. I'm not going to try to stand in the way of people who want= to do that, but it's not what we're after here.=20 -- Justin On Nov 12, 2014, at 4:47 PM, Cantor, Scott wrote: > On 11/12/14, 9:29 PM, "Colin Wallis" wrote: >=20 >> There was no intention to create something else that could map to 800-63= . >> The intention was to brainstorm some ideas on alternative constructs=20 >> to 800-63. >=20 > I think some people feel there's value in being able to do that=20 > mapping, and I won't try to dissuade them, though I'm not among them. >=20 > -- Scott >=20 > _______________________________________________ > vot mailing list > vot@ietf.org > https://www.ietf.org/mailman/listinfo/vot