From nobody Mon Feb 1 09:36:00 2016 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30C2F1B3318 for ; Mon, 1 Feb 2016 09:36:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.423 X-Spam-Level: * X-Spam-Status: No, score=1.423 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UzyZHur1hkww for ; Mon, 1 Feb 2016 09:35:58 -0800 (PST) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 781461B331A for ; Mon, 1 Feb 2016 09:35:58 -0800 (PST) Received: by mail-lf0-x22d.google.com with SMTP id j78so31618182lfb.1 for ; Mon, 01 Feb 2016 09:35:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=engageidentity-com.20150623.gappssmtp.com; s=20150623; h=mime-version:date:message-id:subject:from:to:content-type; bh=Ll7MsMepzqRqIT4DMjI4a6A6lxLpP7sCMZWxOtRxLD8=; b=Y8rI/N+8YUIuqQD0lBrTWStwfu3NP7D4RSvaTDh5RAThpSKtixigPJ6qu/lZhcrlpV TJ0fAidlOkkgfOw1lHXXoatTNbPqwVAmB29LeqHI5cgyIW9QP/6AxtXwZq7MntJszNsP 8gPNybTZcSOnbglnAAY2/9NG1Qp1xQ7Xz5NZTQSsZyWe2tkwGKvhVWuZislwxy+D1upB GDV9Cg3oTG42jEBt1PgqON7HkOv/yqY+K+QBBYBM5knG3HOSn/PBAsD0WiTZuhLQxxvs NbR2bE4iMgXP0pVFLh0igE+7N+5bt8dowVd5j9tSookXYtTMWQ8TIHRXMeKT8jxqVlFh N2cQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=Ll7MsMepzqRqIT4DMjI4a6A6lxLpP7sCMZWxOtRxLD8=; b=Bth+aSYZIRczdOiL3rFjsyEP4Jvp5puedtAlfs7qOuFWl4ZyaEIv9MHDCU6QywgrON 4FFodqwVKxwQ1BYaqYZqZzkW5RQncvGO7aFNJzN2/dTnc3tV1AcdnPMuY/h8PaVY22xW SjMlyMZI2hZFWECuGN7p644ZX69h8+MAw+ZOCocgXQ52va7fO5mstz5cz7PROj1KPLSN NZSKMOI3tCfQ1ZDQBMXWo6biHBUCjXqPGosz9Sg0idIbwdvCAxyWTYGDCtQUOOAsdM4i MyxbR1XgtLQPrpsP7N4MeDszW2s4Pm5Xp7Xl4cGNMqDigXCbobaWdmmWFUmuq+tw9Au5 VD+Q== X-Gm-Message-State: AG10YOSl70gJrDOIkmLf0/19kH5ZD+kmH00olzdnQcu3RiyEJBHi4EUKotJuyNEDu5kFQ1deH3d0Eaa46thBVcub MIME-Version: 1.0 X-Received: by 10.25.89.208 with SMTP id n199mr9260126lfb.160.1454348156669; Mon, 01 Feb 2016 09:35:56 -0800 (PST) Received: by 10.114.199.81 with HTTP; Mon, 1 Feb 2016 09:35:56 -0800 (PST) Date: Mon, 1 Feb 2016 09:35:56 -0800 Message-ID: From: Sarah Squire To: id-event@ietf.org Content-Type: multipart/alternative; boundary=001a11400e2042298b052ab8d162 Archived-At: Subject: [Id-event] Proposal for Identity Event Standard X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 17:36:00 -0000 --001a11400e2042298b052ab8d162 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi all, I=E2=80=99ve been mulling the idea of identity events and have run into sev= eral situations with different clients where they could be useful. I have a strawman that I would love for you all to take a few torches to. I propose that we create a new standard for a JSON Web Log, or JWL. The problem I=E2=80=99m running into is that in distributed access manageme= nt protocols like OAuth and UMA, different ecosystem parties are often in different security domains and have no language to talk to each other outside of prescribed transactions. There are many cases in which only one party has a log of an identity event, and it would be helpful if they had some way to transmit that log to other parties in the ecosystem. Here is a list of a few things that a relying party might want to say to an identity provider: - This user=E2=80=99s behavior is inconsistent with past heuristics and I = suspect fraud - the RP did parallel authentication of a second factor (e.g. My employee Susan has verified that this user matches (or does not match) the photo = on file at the IdP) - Here is a privacy policy that this user consented to Here is a list of a few things that an identity provider might want to say to a relying party: - This user=E2=80=99s email changed since the last time you called the Use= rInfo endpoint - A user account we have authenticated for you in the past has been compromised - This user has revoked your access token My proposal is that a JWL standard be developed based on the form of a JWT, though with some different fields. It should require iss, sub, aud, and iat, and the optional fields I think would fall into four categories: suspected fraud, userinfo update, consent information, and parallel authentication. Both RPs and IdPs would implement a JWL endpoint to receive JWLs from other members of the ecosystem. Thoughts? Would this be helpful? Sarah Sarah Squire Engage Identity http://engageidentity.com --001a11400e2042298b052ab8d162 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi all,


I=E2=80=99ve been mulling the idea of identity event= s and have run into several situations with different clients where they co= uld be useful. I have a strawman that I would love for you all to take a fe= w torches to.


I propose that we create a new standard for a JSON W= eb Log, or JWL.


The problem I=E2=80=99m running into is that in di= stributed access management protocols like OAuth and UMA, different ecosyst= em parties are often in different security domains and have no language to = talk to each other outside of prescribed transactions. There are many cases= in which only one party has a log of an identity event, and it would be he= lpful if they had some way to transmit that log to other parties in the eco= system.


Here is a list of a few things that a relying party might = want to say to an identity provider:


  • This user=E2= =80=99s behavior is inconsistent with past heuristics and I suspect fraud

  • the RP did parallel a= uthentication of a second factor (e.g. My employee Susan has verified that = this user matches (or does not match) the photo on file at the IdP)<= /p>

  • Here is a privacy policy th= at this user consented to


Here is a list of a few things= that an identity provider might want to say to a relying party:

=

  • This user=E2=80=99s email changed since the last time you c= alled the UserInfo endpoint

  • A user account we have authenticated for you in the past has been c= ompromised

  • This user= has revoked your access token


My proposal is that a JWL= standard be developed based on the form of a JWT, though with some differe= nt fields. It should require iss, sub, aud, and iat, and the optional field= s I think would fall into four categories: suspected fraud, userinfo update= , consent information, and parallel authentication. Both RPs and IdPs would= implement a JWL endpoint to receive JWLs from other members of the ecosyst= em.


Thoughts? Would this be helpful?


Sarah


Sarah Squire
Engage Identity<= /div>
--001a11400e2042298b052ab8d162-- From nobody Mon Feb 1 11:01:03 2016 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EC481B3482 for ; Mon, 1 Feb 2016 11:01:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.099 X-Spam-Level: X-Spam-Status: No, score=0.099 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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 9caoQ9NbjXt9 for ; Mon, 1 Feb 2016 11:00:59 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B6B71B3484 for ; Mon, 1 Feb 2016 11:00:59 -0800 (PST) Received: from [192.168.10.133] ([80.92.118.18]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0M0gww-1a4nG53wb8-00usgH; Mon, 01 Feb 2016 20:00:56 +0100 To: Sarah Squire , id-event@ietf.org References: From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <56AFAB66.8030305@gmx.net> Date: Mon, 1 Feb 2016 20:00:54 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="RCRqf4aI5A247PE3B3gEvcrgHswuujWCr" X-Provags-ID: V03:K0:6j11qIrpz0GCvRUFb8e4m1nMEu2R1xqkNOwRy1f7CadKq1mg6tB ANVdKheL/xh0lVrpIxBadY2NbTEXlaBmjv9TxIHAadGAj/N9rdb8vWssoJrHqB75Od1ylcX LLhsPS8BWlyNn+Msvqof+B5jT7JyE3s4OGPUl4cBqN8OFzRdHhdINb+qIq6NXYixVwf5eaz iWZtCQpHZylcn6Rfzjv+g== X-UI-Out-Filterresults: notjunk:1;V01:K0:tU8v/OmiWZ4=:BYV2gh2I0EKmZ4B62o4qzR Gg2vInCbj8rVlxDL/y+VnavR2QMjM5QK7e0AcR6V2KM7FTWYk+niegCPTKkQwG167AeHDcL1l Y5qqr6O9hsaY43IwsxPx60URP9U+1p1Y0iyzVvH6ItLwyopXc4vzgBNh0BmYOxP7adBzi4Vax 6OyeyOq4AAWyKP2RQWfHI/fqQCzELJ/tYktUMyQSfkrHmP9uR27HwSu3SgYp99TvrzXd1Wa56 m+k0tFkSTSFE7BR7G5pZH80pLOK1yIhvJ8kiGmksqphXuve+79twjisLaqnJSLxlMSL+R46Fs Ux3O7DQVvkkDD6dAi6MAE7iVNJKLof/Osy1Mj84IJgfBU/HCRy3SoWVb8ba/quciF+w/HWtIM qQuyyQU6Fj0bfY62/eW9Bu4SVcoenoNhYQtGSMiZwOa2jlEVGKmttVZhPqSWekj+bhBE01Qtb +3Hf68Ulh8h+hamRjK1AuGE6UFdndKdC8gDYZjwE2G2VeADNhnv8Xaqly+JVNW0Gl5lk0nB2T +7r2ynXaPJh3YwEiS7G0Idv1j8sKmWY3eENU/dv4OLu7YZT0mLkAqd75C71osQqvvN6kYotME gg5G5eleZB0QhWc7prI/O9HsrxVJxmv2q7b2U1xTssoJh8UXaJ/1DblQFE1xjPrrf4IHsS586 J624IetC4M+i5z6EuKGv2PC39rZwPwAHKY3pj2PN/IsvZ6n/7K1+pQhtXagyvvHwDrxgtf4fb WbgCc8SXpTIrhU+1iDgl/QSqHVmx4O4ZVspWmLeW0xUw7h7G9ocaqjU+A34= Archived-At: Subject: Re: [Id-event] Proposal for Identity Event Standard X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 19:01:02 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --RCRqf4aI5A247PE3B3gEvcrgHswuujWCr Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable It makes sense what you write, Sarah. I believe you might find this work in the OpenID Foundation relevant to your ideas: http://openid.net/wg/risc/ Ciao Hannes On 02/01/2016 06:35 PM, Sarah Squire wrote: > Hi all, >=20 >=20 > I=92ve been mulling the idea of identity events and have run into sever= al > situations with different clients where they could be useful. I have a > strawman that I would love for you all to take a few torches to. >=20 >=20 > I propose that we create a new standard for a JSON Web Log, or JWL. >=20 >=20 > The problem I=92m running into is that in distributed access management= > protocols like OAuth and UMA, different ecosystem parties are often in > different security domains and have no language to talk to each other > outside of prescribed transactions. There are many cases in which only > one party has a log of an identity event, and it would be helpful if > they had some way to transmit that log to other parties in the ecosyste= m. >=20 >=20 > Here is a list of a few things that a relying party might want to say t= o > an identity provider: >=20 >=20 > * >=20 > This user=92s behavior is inconsistent with past heuristics and I > suspect fraud >=20 > * >=20 > the RP did parallel authentication of a second factor (e.g. My > employee Susan has verified that this user matches (or does not > match) the photo on file at the IdP) >=20 > * >=20 > Here is a privacy policy that this user consented to >=20 >=20 > Here is a list of a few things that an identity provider might want to > say to a relying party: >=20 >=20 > * >=20 > This user=92s email changed since the last time you called the > UserInfo endpoint >=20 > * >=20 > A user account we have authenticated for you in the past has been > compromised >=20 > * >=20 > This user has revoked your access token >=20 >=20 > My proposal is that a JWL standard be developed based on the form of a > JWT, though with some different fields. It should require iss, sub, aud= , > and iat, and the optional fields I think would fall into four > categories: suspected fraud, userinfo update, consent information, and > parallel authentication. Both RPs and IdPs would implement a JWL > endpoint to receive JWLs from other members of the ecosystem. >=20 >=20 > Thoughts? Would this be helpful? >=20 >=20 > Sarah >=20 >=20 > Sarah Squire > Engage Identity > http://engageidentity.com >=20 >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event >=20 --RCRqf4aI5A247PE3B3gEvcrgHswuujWCr Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJWr6tmAAoJEGhJURNOOiAtjAEIAIKUjkwcaA+NId7k67sWqupE sRUJs7/3n4FT6GZ42H4EQmDRsfEwY6Sgrb0qwo/2sO6jNEcn5i3aC2UeZXddhxgr yAaiJ8W8YbmQboP8pdeajLbuyTO8xLSAIvQn48tb8FiCVQdrCRbIKgqiQYo8L4aF I67qy1nLfDsG6eaGkvUbOWjrWFRjIHO4XwqNlrZ7Uzu7Z4VTfMSOAqEwLPhMCKpK P3EWDFb8hhYR0DrArgdHinw0pDIljyGTsg5Ha9NF4wJUL6MEupvM2czILbyFAJvm nQkHwrtKSf5csrrx4b6hznhQPOeKTsGmDqLtX0zui85TqaGCWL2XJJLDLrGadqs= =Z7hA -----END PGP SIGNATURE----- --RCRqf4aI5A247PE3B3gEvcrgHswuujWCr-- From nobody Mon Feb 1 11:57:02 2016 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D9441B358B for ; Mon, 1 Feb 2016 11:57:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7m0i4bJ3zqay for ; Mon, 1 Feb 2016 11:56:57 -0800 (PST) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFAD91B3589 for ; Mon, 1 Feb 2016 11:56:56 -0800 (PST) Received: by mail-io0-x22a.google.com with SMTP id f81so169497385iof.0 for ; Mon, 01 Feb 2016 11:56:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wunderlich-ca.20150623.gappssmtp.com; s=20150623; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to:content-type; bh=mHKM+oQ9NwxY5LRYfpBP3jZ+o54fOjZWeZFg6pGPnlE=; b=EB3tkdFQSqS/dFAUp/L6ELd+49s0+fVPWnG2V6f4Y4QgNd1ktRk/8k5Wd38hchqBkP TUqnxSFqxCWR1ugwrOL6bOa2076LIn93Zo4NAda6pxR6Xn+djJNUvqeHYRzutXPgqHGQ nVQgxqwz4yzsDMRVb+Ng2s+Q4b1JvNoHqK8G/ywfOnubkUYM/AER7ik0uzrABnn2GZMT dDvDNo5KcHtqknM7RguGYEpA/+OufFKxyNEI8PAd7g04/oE5BWYm1SejKDtsG+M+/AKq rfLC5jQVjdqwyn5cy9UKz6G7Q0I/q6zWmlkjdJGi932A4Bq9rM30MQ08ROI+wW9MrQb6 sDhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to:content-type; bh=mHKM+oQ9NwxY5LRYfpBP3jZ+o54fOjZWeZFg6pGPnlE=; b=C9bOJJdBSK3/lj78NzZrsgerY6MIXz/otHRb4Nk+C+r5u16ntRWZv2sAfWYMtDXCV6 sgNkts0Xcd0vgzWY9ZuiLAobNLSA31ATLOKkOnn10MTLzVEqhV7zOoQwnst01S++QofL MSNiPAMOPHC9DEGjeAQ65CMR13Nw34XfK0oVuCmhAv2ybUc9uZk8FA40tExGGLI1AXyz 8HiPPVv8nLVtQ1r3HQoZcZnzSgZkfyWtDTKoMtq6/WKmZ0jyOIBYHGW0OTvwhJWZ0KnW n4lvll0cHTwd5lEOHjfRwzqVL1lHbTGCJA7c0mpiYkrcotZYBLijYtR8jW84Xpj616n7 Iyow== X-Gm-Message-State: AG10YORsth7i4tVcg6I68CpduuivwY7U+v+p/Yg8mgI9CBioidxrxsxYzg6kZZku2aE3/ZihmFnYvAC/Xnvare9erUnViXsbNHzi2PB/r4XdXsC5paEY+UMUplR/ X-Received: by 10.107.8.72 with SMTP id 69mr29897631ioi.122.1454356615963; Mon, 01 Feb 2016 11:56:55 -0800 (PST) Received: from [10.0.1.186] (dsl-173-206-88-229.tor.primus.ca. [173.206.88.229]) by smtp.gmail.com with ESMTPSA id is5sm4879935igb.11.2016.02.01.11.56.53 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 01 Feb 2016 11:56:54 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Pgp-Agent: GPGMail 2.6b2 From: John Wunderlich In-Reply-To: Date: Mon, 1 Feb 2016 14:56:52 -0500 Message-Id: <1FDBF3DD-6CEA-4E2E-AA7E-F3C12EB2B32A@wunderlich.ca> References: To: Sarah Squire X-Mailer: Apple Mail (2.3112) Content-Type: multipart/mixed; boundary=001a113fba167e47fe052abac9c5 Archived-At: Cc: Justin Richer Subject: Re: [Id-event] Proposal for Identity Event Standard X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 19:57:00 -0000 --001a113fba167e47fe052abac9c5 Content-Type: multipart/related; type="text/html"; boundary="Apple-Mail=_C14CF280-44E8-48D1-8955-40F979BE8908" --Apple-Mail=_C14CF280-44E8-48D1-8955-40F979BE8908 Content-Type: multipart/alternative; boundary="Apple-Mail=_61854D04-CC1C-4423-9F6F-4CEE2DDB52DC" --Apple-Mail=_61854D04-CC1C-4423-9F6F-4CEE2DDB52DC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Sarah; Are you replicating the problem of =E2=80=9C..no language to talk to each o= ther outside of prescribed transactions=E2=80=9D at a higher level by presc= ribing a set of four categories? It seems an appropriate solution to the ca= ses you describe, but are there other cases that would necessitate addition= al categories? When I read the first part of your strawman, I thought your = reference to a JSON Web Log was starting down the road to a distributed dat= abase (must still have blockchain on my mind from the last IIW). Or am I mi= sunderstanding and is what you are proposing a semantic solution to the pro= blem you pose? Sincerely, John Wunderlich (@PrivacyCDN) Privacist & PbD Ambassador > On Feb 1, 2016, at 12:35, Sarah Squire wrote: >=20 > Hi all, >=20 > I=E2=80=99ve been mulling the idea of identity events and have run into s= everal situations with different clients where they could be useful. I have= a strawman that I would love for you all to take a few torches to. >=20 > I propose that we create a new standard for a JSON Web Log, or JWL. >=20 > The problem I=E2=80=99m running into is that in distributed access manage= ment protocols like OAuth and UMA, different ecosystem parties are often in= different security domains and have no language to talk to each other outs= ide of prescribed transactions. There are many cases in which only one part= y has a log of an identity event, and it would be helpful if they had some = way to transmit that log to other parties in the ecosystem. >=20 > Here is a list of a few things that a relying party might want to say to = an identity provider: >=20 > This user=E2=80=99s behavior is inconsistent with past heuristics and I s= uspect fraud > the RP did parallel authentication of a second factor (e.g. My employee S= usan has verified that this user matches (or does not match) the photo on f= ile at the IdP) > Here is a privacy policy that this user consented to >=20 > Here is a list of a few things that an identity provider might want to sa= y to a relying party: >=20 > This user=E2=80=99s email changed since the last time you called the User= Info endpoint > A user account we have authenticated for you in the past has been comprom= ised > This user has revoked your access token >=20 > My proposal is that a JWL standard be developed based on the form of a JW= T, though with some different fields. It should require iss, sub, aud, and = iat, and the optional fields I think would fall into four categories: suspe= cted fraud, userinfo update, consent information, and parallel authenticati= on. Both RPs and IdPs would implement a JWL endpoint to receive JWLs from o= ther members of the ecosystem. >=20 > Thoughts? Would this be helpful? >=20 > Sarah >=20 > Sarah Squire > Engage Identity > http://engageidentity.com ___________________= ____________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event --=20 This email and any files transmitted with it are confidential and intended= =20 solely for the use of the individual or entity to whom they are addressed.= =20 If you have received this email in error please notify the system manager.= =20 This message contains confidential information and is intended only for the= =20 individual named. If you are not the named addressee you should not=20 disseminate, distribute or copy this e-mail. Please notify the sender=20 immediately by e-mail if you have received this e-mail by mistake and=20 delete this e-mail from your system. If you are not the intended recipient= =20 you are notified that disclosing, copying, distributing or taking any=20 action in reliance on the contents of this information is strictly=20 prohibited. --Apple-Mail=_61854D04-CC1C-4423-9F6F-4CEE2DDB52DC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 Sarah;

Are you replicating the problem = of =E2=80=9C..no language to talk to each other outside of prescribed trans= actions=E2=80=9D at a higher level by prescribing a set of four categories?= It seems an appropriate solution to the cases you describe, but are there = other cases that would necessitate additional categories? When I read the f= irst part of your strawman, I thought your reference to a JSON Web Log was = starting down the road to a distributed database (must still have blockchai= n on my mind from the last IIW). Or am I misunderstanding and is what you a= re proposing a semantic solution to the problem you pose?

=
Sincerely,<= /div>
John Wunderlich
(@PrivacyCDN)

<= /span>=


Priv= acist & PbD Ambassador




=
On Feb 1, 2016, at 12:35, Sarah Squire <sarah@engageidentity.com> wro= te:

Hi all,

I= =E2=80=99ve been mulling the idea of identity events and have run into seve= ral situations with different clients where they could be useful. I have a = strawman that I would love for you all to take a few torches to.
I propose that we create a new standard for a JSON W= eb Log, or JWL.

The problem I=E2=80=99m ru= nning into is that in distributed access management protocols like OAuth an= d UMA, different ecosystem parties are often in different security domains = and have no language to talk to each other outside of prescribed transactio= ns. There are many cases in which only one party has a log of an identity e= vent, and it would be helpful if they had some way to transmit that log to = other parties in the ecosystem.

Here is a = list of a few things that a relying party might want to say to an identity = provider:

  • This user=E2=80=99s behavior is inconsistent with past heuristics an= d I suspect fraud
  • the RP did parallel authentication of a second factor= (e.g. My employee Susan has verified that this user matches (or does not m= atch) the photo on file at the IdP)
  • Here is a privacy policy that th= is user consented to

Here is a l= ist of a few things that an identity provider might want to say to a relyin= g party:

  • This user=E2=80=99s email changed since the last time you called the = UserInfo endpoint
  • A user account we have authenticated for you in the p= ast has been compromised
  • This user has revoked your access token=

My proposal is that a JWL standard be = developed based on the form of a JWT, though with some different fields. It= should require iss, sub, aud, and iat, and the optional fields I think wou= ld fall into four categories: suspected fraud, userinfo update, consent inf= ormation, and parallel authentication. Both RPs and IdPs would implement a = JWL endpoint to receive JWLs from other members of the ecosystem.
Thoughts? Would this be helpful?

Sarah

Sarah Squire
Engage Identity
http://engageidentity.com
_______________________________________________
Id-event mail= ing list
Id-e= vent@ietf.org
https://www.ietf.org/mailman/listinfo/id-ev= ent



<= /div>
This email= and any files transmitted with it are confidential and intended solely for= the use of the individual or entity to whom they are addressed. If you hav= e received this email in error please notify the system manager. This messa= ge contains confidential information and is intended only for the individua= l named. If you are not the named addressee you should not disseminate, dis= tribute or copy this e-mail. Please notify the sender immediately by e-mail= if you have received this e-mail by mistake and delete this e-mail from yo= ur system. If you are not the intended recipient you are notified that disc= losing, copying, distributing or taking any action in reliance on the conte= nts of this information is strictly prohibited.
--Apple-Mail=_61854D04-CC1C-4423-9F6F-4CEE2DDB52DC-- --Apple-Mail=_C14CF280-44E8-48D1-8955-40F979BE8908 Content-Transfer-Encoding: base64 Content-Disposition: inline; filename=PastedGraphic-4.tiff Content-Type: image/tiff; name="PastedGraphic-4.tiff" Content-Id: TU0AKgAAIpyAIGBACCQWDQeEQmFQuGQ2HQ+IQYynY7BIqqJRAAcBURCAYicPD9vOp0gB3vZ7gB+v 5/A0WBULFcDgQBhx8P1+g6cP2Fv+CggCAQAB0KBMAOZ2u5uKBmNE8EYUiQPBoFA0ACYPBujul0tZ UtlqstVFUqgBBWd3RG1Wu2W23W2BIG33O6XQ/XcCKdvOMQutxuQdAcHgwauR0uwJBsHg4oPB8Sl+ P1/gkK5UAPd9voAP4AAEAOWuABVM9pJ4bh0Nj8SBgLCMAZGCz5/z4AAPbQQBAIAPV+PwAO14vJ4O F3vFsEEXiwcAYBZ4Hg0HAB8PV6697PV8BEGAt/ut4PJiAiZtoTBYLgBwu12qsXhkKuZgqRSNu6/X 7feCXH8fu6vIdB8GALgMAwuASAwDh4ALPBsfKWACA4EgU356OqeZ5nkAACgEAYAHge6UnwfR9gAm cOQ03QGAQBAAAbFqTHlDChJ8BcBgA2gAAUBIEgAdh4niZJknEcphnYep7AAFQLgsDQgBUE4tHhHy VJYABuKSZJznieZ9MUBoegCoLOgIAoAPEA8yzCfrHxIzx/HynxZg2BYFHWebZk4PYgB2d5DLObT+ UA+79UDQiCg4I4lh0dR7nyJwDgOAwfNmf4cn+255nwfAAS0elNnvTR9N6zqCnyfrfH82YAAJDcbV Sex9xGe0RM3VMFIJVNaJ9VEboI20OH23rM1MfIFALMgHRUAQIgVZgEgKoQENuap0HSXNIAKeoeA+ DolwPR5tHSdZlgbAYWn4lgEVKnl1IIA0V1W3R/n5EYIWe7MWl0FILAkVwohQExTrOQTNULgqEUHg y6H8HAfCWB4FAQOoDxUH56H2nh3HtI53HgeEO0+AB81EfScNqALdHofTNZInlJ5DUSCM8ADm1yzc qARHQAQHM7ms9nuZ1tWzpQ/VuY5plyWJ8yKeALR7OtyAAEgWBeZ6gekLNefNNH9lQAArFwKRzNCh AHmjdM8x1QSpBrOQjqgDtuBIBgCaQc22YgxBgFhKYEa+E0BhG/ocf4eCCJAGAKAw6n7sohHlWcon i6VYVGgh8VEeUQpNojMRHXbatulbOANCIAAZnJ/Xmgh9Hzr2pgADIIggo53HeaB2pQbIOsWAAMAc BgABACXZgddx/l4bhtk+bJ1nWd61C8GYZCr34Gg8cB1HUAB0HpTpvHZ54IASBAYx0BQTG40J8gFG Tb6ueedVtYsObhDmRJ4fZ/J5mNVRVHD43gnbHmD0EQIRRhbBYCcSbAhsOCLe4GBwAAVhWCwEocA7 h4hzH2T4ISWzNPvAAAtYxnWZD0HyZobztQADyHy60esJ2nm6J4Z4CYEQIkEa0UMCADx9D2MeMAFo HgPDhAmqsbYy1qCzC6CsFQAAgAmBEQYcDAlNQRLYXcPwDyCgZDeLQXgAAUgTAeFIbY8x6AgH4pkJ o5x5j1AmhgAK2HKD2e6bVVLczPEzKEyJEY9CVgAA0TAAAMAIgOHSFIFwKA6i5E6J0UcViIQQUCFQ MoZQPjSHUO4Tw6VgBCHGcFGzRANgNeAPxVI2h1jtABCl548VMsxM8P9k4AIaw3Ae2UAAHnTjsAoB ECYqQQgJAOLkKIMwXDREUWccUkJmFviwBUYA4x1gOkyOoL4vxwDhAsZkfgVh1QnAiPRKgB39IsWe SqP46kKAAnEZwGwJQSAABrIURYZAbAyD4wJgkzQASSPuDaCgXhyD2HyJIcBKAHjyHYOxhYHgOQ+J YAwYg3hwgAGquEACoTfQkTKnMAAEEagjAgA0dIKQOAdFUD0DgGhgAuAuBMYDAi0z8ppFaLAExfDe HAEUYo5R0A/GwOYdAUR2wnPOrYARmVVK2HhDABTrwZgZAsNQKAKwUCSBqBkC4pGBEpcFP6K5dwDC cGWNILg8x+j7E6OVzROh+jMB4VkYAyRzDnCwLYa42wODzHukcmiJmcgehsAAElIxjgXQiJANwOwa i2YEp2mtkbJEOiwAwQowBhhOHaowOY5DsAyHXOupJmgEM0H4mMAAF4dgAAkc0agRAPghDCM4WAqB mMGrAQ+LAChejdHCLEaMbQiDiHOOcf4LyiidAaxAAophojUCcN8dg7gIgCVQZ2c4GgJASSQBIB4y ghAhA8I0ZAqBTCqsnem9RdYsACGDNkKgqBojXCKOlIwWh3qwAUAR1QCjbnVIIBAoI/wnguBUKcLo LgVh0YEOc/FuSFRYAaL2igrhn3CG3NkbQVwWApF8Mccg5gZC4GyNwGw92uj/j/L67gKJSDqBkBoC 4bxyC3FmKi9eOcdMFBsFwLgLhdDaHCG4b5SQtDuREAkBo/zOIbN0AUBx0QOrPGgHMHYOgzifEmI4 ZRdcIEJBqFYLIrBqMkCmNMbI2hohUBYCYYgps0BBG8O8eAKh/yvH8AMoQJgNgaAADKl4ng6g6Bsn 0s43SHBpCGEsGAFQNgcAuO1q5nEwlvo2AVxCqpzj3He/ACcQiCPFGqwIc2O9TFvCOGEMoRxjDlHM IkX43xxAvHYx0AAIQHFWHiqkEV2wABbBaCYNIuRPifEwW7L5BAWhQCsF4aQ8h4icHAOsdg0gZgVA oNUX6QgtSfHkUJ1jM2cAABQBMCA8FtAdDIObGwrS1BhB+EsFI2xKipGkPwcY5iaABAMdLcKCmZER N8ZoC0TIQgfAwAAb4tRetRAOVYdddRzgPkCOACAKgRi1B2JsP4mmBDrPwFQEIMgcjaEIJsSI7Bzj lKsPgf7KjMj1Q4bohxPB9KsAKA+OJNDXj+HwAoDgFh8AfB4DMfg8dqC2BYFcJA2AQBkCmL9gUqi7 ViFkNocAWBhDeG8JYZI5RzgLA+xBGz7DagGTIFwFYJg1XlFMJctVuQf4+BaNIdo8hpDhHYO0foJg IgPF0K4aw2QhjqSMjVXqBwABIBQCQeAWwVAlCaKQS4lxiFuDb5kBgzQrB4BMMAXgmh+BEDAH0Pg5 BTi5CrU2VRukOEORG60DQKgZAAAcCUDoABsCxFebVMvv9+tkTKA1HYEgZgtHICsPoYg+CdGILsUJ dQqAQBkBEbwlRMpJCwEcL49RtjkB8OgV4vwTtadabgg7SoQ1aIIBEBovmgDvAInMFoCKCAmHcNOB qIyfATBKBCRsAqAcHEAcBQBEEuCAE6EEEyYEee6qD8BIEOGCGMEsGWHcHkCKA49eNyN0JSM8CAq0 BwG2FqFgGSIcggiwAWFGGeGmF2GKHGHKBkB4A2AyH+FmG2G+AQXAJKbkQ45cJ8BoocH0EkCOCCCE EVCQGKYMCgAgBCCcG8EaFQFiHOHEHAZmVUIeRGOqBSB8CCAAAoBcBMAAGMEoEyVGQkM84CVuM2Z1 DYAsBwBmSQDUC0BaFIG+GUGoUCCOH0AkDQHOE4FkEuWo1KM89eRshCcSAABGDUCsFyF2AkHwCQIM iwAOHwGSGsBQGWFEFck2FUF2BkHOHYHKaiRIdMAei0AwCGB0L4DOCmDUFCGQF2FovYLuAWzgGuEG EyGMGUDgBuW2ACBMAy4SAAVgG8HIe4BwAEGcF65AISggCGC8C+DIGG7uE2H2HcHcHAGoHUHWAIG2 HaHeA4WiM8fuAAA2Aw4SCiBEA8EkHGxsDegcCSH8AoCyHIE6FmFMHQHImWN0KEIU/UAYA2AuH0BS DOCuE8AkBWBIHWGcEKE0DIHaGcGtBrCuIYJ8QkN0AcB2BgFECeGIFADEYEf2PsCCHaAODmHWFOF2 EZG4HQVHEMJ8eKaoBQD6DGFWFmH8HMCssoLuAsGgEEE2FyGsEYE6BgU4crFKIIAqmMHyA2DMCiCm FmHQGuFqPwHsBsB4C4GWHOHUE+CLHWHSCyBmBeGGHcQuGSFmE2E2EgIUP0sqEsGKGUGkHIU+BCA2 AYQkE6GUGcfiTaVSAgAoAoAACExkFaH0GEF6ComZHlHpHtHxH1H5CwIRIuAETIBEDKCkF0F6A0H6 COIMDCB4CODeGgDGEIEgHGHA0QRMJ6ZCAAAsBmBgH6B6E8EEBOEutq0QPvJLJPJTJXJbJeNiRYAM QkBMDyC+FcFsAEHWCmLUiwAsF0CSDYGQHGFwGABCN8Q4Nk98M0BACCB+HwBoEoDmCCEmFYFQGQPw A6CSCaEsF0HUHeDSBkbkDuDqCEB+48LOY9GcIGCaDGDKDWFkG+HGEoAsbmAAF4G2G84UY4RI54H2 lmCKBMBGHOEOCKB+CEgZMXHnHrHvHzH3CvH8IStKN0BGDQCqGGF8AuH4B9M/NCD6GcDCLOHMHEG/ CuTIIUliNqbEAMH8AKA+G+DyCMmXN1JNJRJVJYHXJdELOCXJOJONOROVOYLaCWAaA+DYHCEQFIEm HSHU1LH7EOM4AaAG36AiCUB2FwGYBoAoCSPwiwAiDyF6GEFYk+HqBsCwBQBOBIGcFYFIJLP2LkAg CGCMEuHjMqDQAOhyFONITKhGYuJ4BGA6A4AADOgSDSGIvM2OppMZQ5MfQ/S+IUM4RGAwBCiiAoCW B2DuAEUgF+HoGQ20HAGKGSapMkIfTCAWOiBgEUDcDqFYHYGyEYPxN3SNN9STOBDXSaKvSfOTOWLc D88yAaFSBkC2GSHqHAHIBSRHDVEON8AoA0A4H6BCDUCuB6FqH6HIGOPwCWx8BIE4GyHAG2AKHyHu EgAoGkGaDiIUHcNmAaEyF8GGGajiAMBEG+eyAGGOHEHIRwhGH+tQCOBFR+ECCMCABaYEwAn5U3Md Q9MjRCIYeAQ4AqCeB8FQAMAcAUFoHeFeGIFIe4LS9cIe4CQGAMH+BWDeC0CeFuAYHmFnWDSLN7SR SU99WPOHWTOPWXSkLmByGoHmF+HOFWF6CAJTJHDWJ8AYTCA+DGCkFsF+A0H8CWUCHk5IE8HybKCy EeCSB+BWT6ENQUIKG6HMHuAoE6GiGMHWAMKCGcomHABWhYHyTOVsu8AeH8CwScDSHDBIE0vTYxQ7 MhRAIbaoAOQkBQD2DED0A0CEBmF+GICoDwF6HcHQHOQlaDccNeAAAfUidgCKB0BCGEA+ADCtSJN5 SPN/SXaFSdaLSiLqBoGOHODOHaF2GWEwHsrSIW36IIAZDCGwGuCmBaBSUCBCCWCgB8GWzoGCAMHw HsBqAcGcGUtuIKF2HcG6AWFoGEeYBRGEASFCGUGaVa/UIIBWAtMEEQCeCSA2E3CQ1KsncVU7Y2IX VCd6BIniBGDaCqBaFgHgG+GoBCEyGCG2H2HMHYBIRGIgN0RGAkBgBaHACmGeFSByYFJddhWHZ/WN EPWROLdvWYLoBwGaHaCKHiGOGoF0HaHWJLdoIKM4M0A6BcBeHuCIF8E0CYEUEqEg/gPusqCaFCFS GMe+HbXEHqHY8uIKFuGqGqB0GMHQHcGEAgPEAGFLL2Qy54H8TCBUdkGgFACuChQwLPAcslf1Y1cb RxdIAqwUHKCiGaFMCEVUAIHGF8C0DyGsG6FOFiBAM5RuISM4J4AsAWhuAwDMCeE6F6AgHsDIUDWF Z9dndEJ9hLWVdwLoCg7ECYG6EsFbKkG8G5RsIOXWAAA+BUBagkEEDWCuFEGqGEvQUAHmBkBuGiF+ ooDgGYDcDNCUIIH2FaGiGqEAF2HGHODktae2F2ooBKAGyYVUAYeAH8SME0COHaHIDOx1jbcZU+IS 4CH+TIHmA6CEB0HdZIAWAIHOGKGcAuHqHMHUAJhranCwRGAmBkBiHOCKFWESB+EcFIE+PoUBkrdl WLhrkzaHhNShhQLmCgASA9lAEvlGHQG+0QyeIPf8AuA7AAA6DGCWCmFuACHYFcUCBuCuC0EQGy72 FqCOBMBIDqWeAEDSFQGcGiDSF/nkEgAw7QHwFoGwG0AcAKVsHwuuCCBCA6HqEcCaCQBSYEHHcTQ3 Yzm/VoIYM4U0A0BcBgNqQMlWGSGGQyhDEOJ8KEM836N0BICWCI1uDoC0DOE6GEFvcQYLoNWJaBJh OFdtobaOLfohokG7opKlovlOINf8AwA+iiA8DOCgCmFrgdpMYKDax8AsFsHgHqF4CU8iCSBEEAEA AsBoBGBWHEBbBoAOFeGlDyAMNug2J8BQAoAkH6D0CQCEA4FYEmEng/jZqncXU9qsIXlSAsBeBctT HWAAHSGUGg98KEAKmEN2H6H0HiA2B8BoGmBLlgEeEyFuFdsib/rthFoTr1aJr4LqClk+G3lFlJlN oyIMN8daBIBeBiAABYEgDkCzriFuxwYKBWCakpK2HMCIEQCUCICwDcFmFmAiHSQ8HMBMAwAuAQF4 zSVoVuVSX2AkH8DaBqBiDEvKFI+jfzt5f3jeIaM4daAq4MBYDgC6DwHmHAHPYSSoA5IUdgB8B4GO EEE+EdbYn5u/kvrzk1hPr6LcCGHOAGCWHOFkGEFoHYHNYSM9Y498M4AcW2HECsGwFcB4EFCRqiYK AKB6CCF3bsAIHeHqF+F2CsUmAoDaFgFqHQAWZwAGGSHCmWxRgkIKATFOAACNBoFYH2GKF+LLxBMb t7f4cGozC+BXeaCGFUEYA5PKFJFGIaBKE4GOBzH8AGBmD4DEGlZWGuQxrrZ7oPrxSZoXk3ocLeBC EwGGCOAE06FwHpeuILW036M4AwCWB+GmGWBsAtuIYKCOC4DKBeFhlKGcBghqCaGyFnOQUmAKDqFo F0FgH2QGCUHQ2oAAlQlURKZCSoBwBAA8H0EsCcCQBmYFDzU1xDjdnBIt0OAp0SAABuEQDcBYE+Gc GEGqIUC4BsB8BYGmDeEiGmAGZEAABED0DEB+FYHQGmGEYNx7oRkxvFoZaMLqB0GwHuE6HO9SDESP alDYJ4AoAgu4BADgC4EBpGHQLkUAiwASEFcyF4HmhaAyEWCQCH3JjUP0A/PWDWGMfAEoAQH2daGG G8mX20c+AaAgdmCuBKBEFUDLDgCyYEM4khm9t9yhH/3Z3d3h3l3p3sIUDCBsB+BUGQDcEaGr4CN9 ckDCB74QGvigUL4b1HdrvH4kLaiwAoFwCQDSGQHKFyGIBGN85p1l0OAuBsBoHOCeGSFHqeLOckUA AsCGCODaGgOwElcHDEBeAkAiC2EmEYEUFNLcLuAeC2FKzIA6AsAqA4GiHFqiSKr8agcuN8BiBINc C8BMBCDGGEvME9Q10HxF3VNYM13beb6z3n3r3uIT697AGP7H7L4EBSD37T7X7aUJ7fhHoVr37mLY CwA+BgCCGyEKE+F8HGG2gaQ436N8U1gAiaA2DmC0D4FcHUGuELkoC8C8C4EurKFABTwcAGBeIAEw g5Hy93oMmutVq60DDQBD4e8BkODY9QGBEmDH6+wAv243wABouAACAYe/AEAgALAwF3KZBYKSYvVQ pGhEJxOZ1O55OyS/goWXInVmpnQ5HEAJUBJ7OH+AH0AAoKxSABuiDcLE+zmE1Z4YRsPxUxzcjWqB Hy/QAOVMhxYGR2Lm0714zQSAHe7wAESqRH4gsA9qbTSC7QOc3Wp12jHU63RJAAA4hTwaBgUABMej CrlsAXSU8HOT9owsvyqdVk3VYthvaqZanyAAsFQwABCaCsthmgjUWMAgnnoeFECCXi+XFAz2qo30 /H4ACWMBaAALBTa1VcrEpOIagdFowcZlctGqEQcDg47LyAGe5XOAAOBKY//pDwOCAAPxCHnUeB6F wkEmRRJme4cDJ2JZ/gwKRxk4WBWnOchwqUACmNCp6ogoFgVKsQQ2hIT5pmEbqvrCFRjLKap/nuqI NiaHpPnMYJlNaeJ7hAf5+o2CAVBCeAPiQHpLFce5wkVA4hnkBo5nSUZbMYdT3pMySHqeBzLAAFBA DIVZZn2cwrNC0Y/AsZo/kuXJvEuVIYMadMKH8AAPA+EYAAwLQlN0Qw2Cm358QO0IPCSKAuF8cRxF GeR7nuAAfBGEQAASAR/mgNIbhoH7fnk7iHJ4FIpCoMBWGsbZOBQCIHgGaZzzebx2r0BQCtef84gG BLLh0DoNHUJoQhKJJglQrdAJ3MYJogCBfDCPgmnSVpfEeeB5ngyEqMGp7YgoFCqiOWJIiSBwTBAb DfnAnCwLEZA6kkap2GoawAA4CgNgAfFYgAfJ/H4cp/H2foMgEdJ1gECgRBCAALjQKJLlme5xjU0I eG0fQ0HeWpiEudZ4HZarJgABQBALj4YBIXIjlORg1AYEwOgAaRLFOAB3Gaa4eHwbhzDmdhjmgFx6 H2eIAAcA4IgABAXUgEIliEPwYj+MxGN/RliO+PwFkiY5mEGWRqmuOAGAQBAAhyDwOaEBQFgAEQDA YGhlFgUhmp47rhAeIIileaJ5nsKAUgU/BjHCcYAG+dy9ASAuRH9xaSASu4RgaBp1CKEIOi8cRclq XMDhCThhhICoVBKZoKAwCwHHUaZtAAeRuwmksLQMp61AKBO0guHIXAAf+RQqDoMlWHJFjkLBvFeY ASGaPhJGyepuG8AASCuJhdhGNYrEKDIbhcYhzloYIWGsSpWEYcxcGAIgJBsGJ8iWZJRBaWgpDOAA JAWC5Dncc7HnSZJogsAQz8E5z04k8KfAd3ZUgZAsaMQJ1g3Ckj9HMxwAQ/E4gEA+BUyIFQHjlA+E cHwzARBdCeJARwphNjAaoT1MYCQ/i9GELEZo7x5hFAMPcwQM1dIVAMAYAAGgDgHDUN8WosBLmhbo mI0YFQ+i8GCLEdA+R+A5BkeYAAvHngAHCO9oIBQBkqPoU8lBkgTgZNqDt34kg1A1BiIo345SeAyG WOUCo+xwDtCOPIdY7R9gMAqBMf4BwLARgLCsh6/SODzHAOcyQ+B9ABBMGsKoBgah/DUKMbwtBgAn GYHIRw1wCD6TiDUUofQaifF6LkZhPA5BlDSDQXAPQxjGAKPQfABQRh6C6EYdo5hujqAKOIfYqx4j xWoP85w9x/kXHqSokyFwAD+gqPUe4Ah+j6I4BIETLQBgTAcPEborheCcCAIQN4/QPhgCcMM36b5D FNB+FgMIKhVDXGoI8cA9x8hGAcP054JALgWAAP0ARkh5j0HmGoCo0BlRHQNElAwbaJAQD+MUZYth /AFAMDkEgCgDgAGgOZN40BznvPiyIlRD5RJxAoBNY4LAIAOHEDoD4HQ0nYFULad9O6droLGikAg+ 04goEEGgGYrBvjOGcTxMYDhVAwCoOgAI3B0AJAiEYGwUBjAwAgLGnlX6wKAhaJ0Zo0BIi/G6OILo 8B9j7AQBQAhKgLgPAeABqa+B6j2DSBsaozhMQrogsQJYXAuAQF2OQdItRxD2HwDoDwBmRDpHqPQA Ax3BFKACSofqtJoj9gLRoAAHQIgQJWBYCYvgkgmBCIwXYnxPi3rDbEnNPhjhwEcNUAI7jggrD8GU MQrB3DbE+TwLgHgaBtk6IoSACSBACBkJ4PYUBOi/FvV62V16eJjAQKAZozwwDCHAOQNw6R8j7BSP 8fRsQLNhaFXR3czwCj6H0GoCFDKHTvsDIZMYEhQjPGmLQYw6B1g5AoAEp5IjJDHHEORfBzqBuMHw Ps55aiHgIbQAAEcDgaAZAuLwGYHwNhkF6JsTaE7sQrp8MgOQjxqjrGuNIAAEwPAnKADsF4rSngAF uAOyANR2jFGcFoe43BwAPA6FwKA3wgCjEKDBTWJ8oGDhaJQYYxwuDYHcPAOA35qAqHePUeuMQCGS AsAwBhUHEnwJSNYIYGwMiMG3EW4dYb83ZNGBIWo2xuyaHOOwHNJRzYYtGAAeI+DYuFL0PjBw9psL 1wcPw+oDHIsIAOAYdwLAOAbE6F4GYLRhCkEcI4WmUSmhpB+EsFo1hACbGkPcdQ7a7APAOfQag4gA gO0mPcd6mx9Q+fqEAGg5wVB9DKFwTItRWC+1JssAAejRguFWNUbIbRiDfHEEUbjhgPjrHpmEBNnA PUxAA5EBruyRgnAeA0ZoYwaAvCagIRR77sZ1rDfsW42xviAGSOQcwbRujvWoBEAZJsy5nHVt0AA6 R6WURsbEeo+yoyOI4P4AZkgIAPtIBsBhl20gAF8BzdIuVxAbFMFUEQIh5m/aDvUMoZQKjhGONYNo B1blSCCDUVgxA1iEB0OwX4ywNwEAACoLwUR6AuEAGYTpv2ObMrAmMCgtBsDaCSL8cA5Qfjt4WFux Y9wEDtmK0I+UPwG5nAREE6mZiSD5HwNoIAIgQCGC2C4FQqDfmx1JvTKINgsBcCiXMeAfx0YSBeOM ckcAL8baN2MdHCEbJ/qEnEeg+So+TNiWl2jjgAAQAW2kA8/h6AoAoBIeB5gHCrA2AoBQswvgzBcN 035SenezuumMDItnnhBGeOgdgQhxjpHUFUcY9h7gOHfo0e9kypXsAx2UkMPV68VQrhIeoOQRAfFF UYFwiTf4m9oQ/vWzAuUSAwLwb45A4jzraHYdvxAAZnTiAf6X7VGDy0M6z+48x8mx0Uc9fxOIeq+Q AA54kzSAp6P4CR3YewwQEBVCbBHQWwGADQDIdIeAfAe4T4OgIgIAeLM4AAcBPz767BMYFAQIXiFQ DY84LoYwcodADIfUC4KSPgfoB4ew+oeAeBoLWRkQCYBAu4CABjjrsaggyTz4foegEACYCQUQNQHQ GYSgSYQwQwa8EQpr8MKoAAHALgLwJBVYdQOoe6zwIQpQlQBAfwtQBLMYAECw2Id79wdz9zQpP6Cw tSCxbDBweryi94lSlZj7zpSL6AfqHDDACoCiu0C4aBoYBIbKjhg4bwdAdIVwdQeofAb4GYDSDQEQ Cpor/qK4bzQIZAbx1bBwAAF6HYDIBLcpKoAAdYfhP4aIcTQIKYqgHQCa0YHIZwb5cwcweQeYCYCp yIIgbodrWAfIkYtQkyhA4JK5kQBUNQCa9xsKj4kglQeoeRRQBDioaIEIDYDAToPoHYG4Yw35eELC h5Tscw4YCQIYI4JYcMXoOge5OIICaQlQCwA5kS9Y/CLwlQdIebMIcjsIcMHIAD/4AEAIqLHInKMI nIksPifw6g+5SK9jMcPj/ZSL6QBrSo+DschgeAe5P8CxP8hgBkjYkR2KMQfwp7yYqIAjNKjRkSzx OK8ojiyayhsEfYko+EjYCwCC0ifw54CT1UVgd4dwbID6lwcwAjs4VIIwDwDIY7T4UjGEdKr8K8qo 0IGgKwLQJgY4cYcYMocAdweIHRyIBgCgDTi794iB2IcoeJTYZwcrQL/QqI5o54AUnQBBWTB6A4+o e7BxxYp8nQh8nSuIyUlROKCxOI+onKL4kyuIlQAzsaZ6aI+slQp8vCZ6zMAcM4qDB0Hwy4BCyBj7 NLWZOIDzQb4gfAaJtABQaMMwfwZQC42gaIOZ7YaI344MrDvMdE3ar5MYDoSgZYaQGzbgeYKKa4fI JgBSHrjEnz976AcYdQdQAEtxTYfEzcM7CbCTxYyQAwlIkL6Rn4jhHQfwfUj4fAf7yIA8jUmMlUhY iEyiL4lUxx3bHKzYp4e6toe7+wfAeYB69gDYCUBJjQeAZIDIB6b4GoEADwA4cAdgdYWYGYEoEwdQ Exv4GK0wCIakDwZw37QM3z78q9ELeo0YDoPEE4B4FsJQMD44fQCoDRtAKpv7mgax/YWweTygEwfy zIDcOAewBIDQC4C7NQlQCMIJoTiAdTCIfgeYAzSoEZHItUfyygeytp+oBI/EAwAAeb+7BEwgh4Bs P7hYeoaikgdIY0oQBIBgFUCYAAdoeYeIbIC5yIDgFIDgDgEoa7fgXAc4eYebPxXUCQC4DIV4fgfY e4a4VgSYSbeVEjp1EdR72gKgOwO0BJRgDYFQCIBCOAh4ewYofBewcQbQbRDjCwGoYwbAbgAAblCB RoEAEAMC0YCAFwdMYjQj/NUMMiMExgyAlIk0hgkwk1ACj4ECMwAD3gdgZQab4AWQGoDwDxhBsIe4 TwYgY4VwM4JIIAfob4VgVhwdSVcIh4gIAAASAQAAAwAAAAEAVAAAAQEAAwAAAAEAMgAAAQIAAwAA AAQAACN6AQMAAwAAAAEABQAAAQYAAwAAAAEAAgAAAREABAAAAAEAAAAIARIAAwAAAAEAAQAAARUA AwAAAAEABAAAARYAAwAAAAEAMgAAARcABAAAAAEAACKTARoABQAAAAEAACOCARsABQAAAAEAACOK ARwAAwAAAAEAAQAAASgAAwAAAAEAAgAAAT0AAwAAAAEAAgAAAVIAAwAAAAEAAgAAAVMAAwAAAAQA ACOSh3MABwAADEgAACOaAAAAAAAIAAgACAAIYAAAAAEAAABgAo+AAQAAAAABAAEAAQABAAAMSExp bm8CEAAAbW50clJHQiBYWVogB84AAgAJAAYAMQAAYWNzcE1TRlQAAAAASUVDIHNSR0IAAAAAAAAA AAAAAAAAAPbWAAEAAAAA0y1IUCAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAARY3BydAAAAVAAAAAzZGVzYwAAAYQAAABsd3RwdAAAAfAAAAAUYmtwdAAAAgQA AAAUclhZWgAAAhgAAAAUZ1hZWgAAAiwAAAAUYlhZWgAAAkAAAAAUZG1uZAAAAlQAAABwZG1kZAAA AsQAAACIdnVlZAAAA0wAAACGdmlldwAAA9QAAAAkbHVtaQAAA/gAAAAUbWVhcwAABAwAAAAkdGVj aAAABDAAAAAMclRSQwAABDwAAAgMZ1RSQwAABDwAAAgMYlRSQwAABDwAAAgMdGV4dAAAAABDb3B5 cmlnaHQgKGMpIDE5OTggSGV3bGV0dC1QYWNrYXJkIENvbXBhbnkAAGRlc2MAAAAAAAAAEnNSR0Ig SUVDNjE5NjYtMi4xAAAAAAAAAAAAAAASc1JHQiBJRUM2MTk2Ni0yLjEAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFhZWiAAAAAAAADzUQABAAAAARbMWFla IAAAAAAAAAAAAAAAAAAAAABYWVogAAAAAAAAb6IAADj1AAADkFhZWiAAAAAAAABimQAAt4UAABja WFlaIAAAAAAAACSgAAAPhAAAts9kZXNjAAAAAAAAABZJRUMgaHR0cDovL3d3dy5pZWMuY2gAAAAA AAAAAAAAABZJRUMgaHR0cDovL3d3dy5pZWMuY2gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAZGVzYwAAAAAAAAAuSUVDIDYxOTY2LTIuMSBEZWZhdWx0IFJHQiBj b2xvdXIgc3BhY2UgLSBzUkdCAAAAAAAAAAAAAAAuSUVDIDYxOTY2LTIuMSBEZWZhdWx0IFJHQiBj b2xvdXIgc3BhY2UgLSBzUkdCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGRlc2MAAAAAAAAALFJlZmVy ZW5jZSBWaWV3aW5nIENvbmRpdGlvbiBpbiBJRUM2MTk2Ni0yLjEAAAAAAAAAAAAAACxSZWZlcmVu Y2UgVmlld2luZyBDb25kaXRpb24gaW4gSUVDNjE5NjYtMi4xAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAB2aWV3AAAAAAATpP4AFF8uABDPFAAD7cwABBMLAANcngAAAAFYWVogAAAAAABMCVYAUAAA AFcf521lYXMAAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAKPAAAAAnNpZyAAAAAAQ1JUIGN1cnYA AAAAAAAEAAAAAAUACgAPABQAGQAeACMAKAAtADIANwA7AEAARQBKAE8AVABZAF4AYwBoAG0AcgB3 AHwAgQCGAIsAkACVAJoAnwCkAKkArgCyALcAvADBAMYAywDQANUA2wDgAOUA6wDwAPYA+wEBAQcB DQETARkBHwElASsBMgE4AT4BRQFMAVIBWQFgAWcBbgF1AXwBgwGLAZIBmgGhAakBsQG5AcEByQHR AdkB4QHpAfIB+gIDAgwCFAIdAiYCLwI4AkECSwJUAl0CZwJxAnoChAKOApgCogKsArYCwQLLAtUC 4ALrAvUDAAMLAxYDIQMtAzgDQwNPA1oDZgNyA34DigOWA6IDrgO6A8cD0wPgA+wD+QQGBBMEIAQt BDsESARVBGMEcQR+BIwEmgSoBLYExATTBOEE8AT+BQ0FHAUrBToFSQVYBWcFdwWGBZYFpgW1BcUF 1QXlBfYGBgYWBicGNwZIBlkGagZ7BowGnQavBsAG0QbjBvUHBwcZBysHPQdPB2EHdAeGB5kHrAe/ B9IH5Qf4CAsIHwgyCEYIWghuCIIIlgiqCL4I0gjnCPsJEAklCToJTwlkCXkJjwmkCboJzwnlCfsK EQonCj0KVApqCoEKmAquCsUK3ArzCwsLIgs5C1ELaQuAC5gLsAvIC+EL+QwSDCoMQwxcDHUMjgyn DMAM2QzzDQ0NJg1ADVoNdA2ODakNww3eDfgOEw4uDkkOZA5/DpsOtg7SDu4PCQ8lD0EPXg96D5YP sw/PD+wQCRAmEEMQYRB+EJsQuRDXEPURExExEU8RbRGMEaoRyRHoEgcSJhJFEmQShBKjEsMS4xMD EyMTQxNjE4MTpBPFE+UUBhQnFEkUahSLFK0UzhTwFRIVNBVWFXgVmxW9FeAWAxYmFkkWbBaPFrIW 1hb6Fx0XQRdlF4kXrhfSF/cYGxhAGGUYihivGNUY+hkgGUUZaxmRGbcZ3RoEGioaURp3Gp4axRrs GxQbOxtjG4obshvaHAIcKhxSHHscoxzMHPUdHh1HHXAdmR3DHeweFh5AHmoelB6+HukfEx8+H2kf lB+/H+ogFSBBIGwgmCDEIPAhHCFIIXUhoSHOIfsiJyJVIoIiryLdIwojOCNmI5QjwiPwJB8kTSR8 JKsk2iUJJTglaCWXJccl9yYnJlcmhya3JugnGCdJJ3onqyfcKA0oPyhxKKIo1CkGKTgpaymdKdAq Aio1KmgqmyrPKwIrNitpK50r0SwFLDksbiyiLNctDC1BLXYtqy3hLhYuTC6CLrcu7i8kL1ovkS/H L/4wNTBsMKQw2zESMUoxgjG6MfIyKjJjMpsy1DMNM0YzfzO4M/E0KzRlNJ402DUTNU01hzXCNf02 NzZyNq426TckN2A3nDfXOBQ4UDiMOMg5BTlCOX85vDn5OjY6dDqyOu87LTtrO6o76DwnPGU8pDzj PSI9YT2hPeA+ID5gPqA+4D8hP2E/oj/iQCNAZECmQOdBKUFqQaxB7kIwQnJCtUL3QzpDfUPARANE R0SKRM5FEkVVRZpF3kYiRmdGq0bwRzVHe0fASAVIS0iRSNdJHUljSalJ8Eo3Sn1KxEsMS1NLmkvi TCpMcky6TQJNSk2TTdxOJU5uTrdPAE9JT5NP3VAnUHFQu1EGUVBRm1HmUjFSfFLHUxNTX1OqU/ZU QlSPVNtVKFV1VcJWD1ZcVqlW91dEV5JX4FgvWH1Yy1kaWWlZuFoHWlZaplr1W0VblVvlXDVchlzW XSddeF3JXhpebF69Xw9fYV+zYAVgV2CqYPxhT2GiYfViSWKcYvBjQ2OXY+tkQGSUZOllPWWSZedm PWaSZuhnPWeTZ+loP2iWaOxpQ2maafFqSGqfavdrT2una/9sV2yvbQhtYG25bhJua27Ebx5veG/R cCtwhnDgcTpxlXHwcktypnMBc11zuHQUdHB0zHUodYV14XY+dpt2+HdWd7N4EXhueMx5KnmJeed6 RnqlewR7Y3vCfCF8gXzhfUF9oX4BfmJ+wn8jf4R/5YBHgKiBCoFrgc2CMIKSgvSDV4O6hB2EgITj hUeFq4YOhnKG14c7h5+IBIhpiM6JM4mZif6KZIrKizCLlov8jGOMyo0xjZiN/45mjs6PNo+ekAaQ bpDWkT+RqJIRknqS45NNk7aUIJSKlPSVX5XJljSWn5cKl3WX4JhMmLiZJJmQmfyaaJrVm0Kbr5wc nImc951kndKeQJ6unx2fi5/6oGmg2KFHobaiJqKWowajdqPmpFakx6U4pammGqaLpv2nbqfgqFKo xKk3qamqHKqPqwKrdavprFys0K1ErbiuLa6hrxavi7AAsHWw6rFgsdayS7LCszizrrQltJy1E7WK tgG2ebbwt2i34LhZuNG5SrnCuju6tbsuu6e8IbybvRW9j74KvoS+/796v/XAcMDswWfB48JfwtvD WMPUxFHEzsVLxcjGRsbDx0HHv8g9yLzJOsm5yjjKt8s2y7bMNcy1zTXNtc42zrbPN8+40DnQutE8 0b7SP9LB00TTxtRJ1MvVTtXR1lXW2Ndc1+DYZNjo2WzZ8dp22vvbgNwF3IrdEN2W3hzeot8p36/g NuC94UThzOJT4tvjY+Pr5HPk/OWE5g3mlucf56noMui86Ubp0Opb6uXrcOv77IbtEe2c7ijutO9A 78zwWPDl8XLx//KM8xnzp/Q09ML1UPXe9m32+/eK+Bn4qPk4+cf6V/rn+3f8B/yY/Sn9uv5L/tz/ bf// --Apple-Mail=_C14CF280-44E8-48D1-8955-40F979BE8908-- --001a113fba167e47fe052abac9c5 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----- Version: GnuPG/MacGPG2 v2.0.28 Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJWr7iEAAoJEOC76zanEdQWfy8QAI0aov6rgJ/lCF+2zBcUli7q hvNLVvRzK/gIRsBEojz4TdUPMe/U/HRnri2/vIrnIndgQ7GSgkKtlWiyuh9Ie/zx dWFeeDXJe9dHUGdIjS19sFVa9qpzwx6z9K880LKVnlg5YotsocrN+GUvnZrhuzEG 847h5khqYnA3AhtfAZgutuV9e4BxsFnSSBy7uVkrqNSTgpe02bhdPox4A+0Qmo4p 6RjIyKVCB3UCTKGDT/obEUqOFElfRMauUzfMjIMRhYI+tyGKu+Nh7iSwG/t+oks3 JWdHuchwARKsogodwoXoXJDKNYXXG8zGSSNEQYCSNIcFclI0+SPUwsz2zcQJ//6d f2DMtGPTPAS58E6eclmKnRx6PKrC2zSgTjqwXXCIsG324+0voHaHmjwcsEXG843V E2je8Q5OP8F3NDMr5OfN+uhUG3WtHgsaJJQ+ltgrjFjr7wJN/k70lccfcwchNH7L DN6gfBoSmbdERdTN+xBbXQU0GIb84Y4DNd3oTF04j2HDlOHQZugf6ExOXIkY0fLk VzF61b4zak6w72F4NUB77x2w5FMK48BcBQrhMaPx9L6ZOVeNIzr1XPGXP9EfRxwG jWGIh01If97XJd+Swo60uH1ZEbeWl1b6n9tve0XBO+Tgz7qrbpLWTdThkkytmNTA 9G8T6BUYpVyTaHVVz45+ =BJB6 -----END PGP SIGNATURE----- --001a113fba167e47fe052abac9c5-- From nobody Mon Feb 1 12:09:46 2016 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E82051B35D7 for ; Mon, 1 Feb 2016 12:09:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.267 X-Spam-Level: X-Spam-Status: No, score=-1.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, T_REMOTE_IMAGE=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A0ryBPaL41vM for ; Mon, 1 Feb 2016 12:09:42 -0800 (PST) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10DB11B35D5 for ; Mon, 1 Feb 2016 12:09:42 -0800 (PST) Received: by mail-lb0-x22c.google.com with SMTP id bc4so81864503lbc.2 for ; Mon, 01 Feb 2016 12:09:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=engageidentity-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3oeII3sl+HIlO2Vp+remmhUd+WRgr/N1GzoYyWD43LA=; b=HUCyKb/Z68RawGV2rZ2uuUogasnNbQ5iOgWrVRmCSy/0eE9TX08cAAdP5dMSthgFTX Pk2j0NHw9saztns5q0298xqbbGSo0CYJnlWO6/EkwwxCu8TKCVnJqyayko75T1d5IrNl 9+Pukh8rYYszjmu9JfQZE8OABqCAPiJUKnXESgTRw+h0nb4/r0pfoOZdFss4f1i9ve2P mrHL3GsB1UvqrgiFXLQOFz7ce8MjPf34gj4zDKTGV07QdOoAfm7zW/EszdX+1/dGXwaD yQ65juHQWw1iZ4rOUWvXL06Cl+NHAqbtss/stvDo5ntGBEcSmKRayN5B5sJ/Waehjupk wiwQ== 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=3oeII3sl+HIlO2Vp+remmhUd+WRgr/N1GzoYyWD43LA=; b=ebDErqFzbVvGyjOD9VL1p9AFiF3MTCp93Q1S3UozppbiGowXhy/RFlVQ1L+7D6QX44 u/dbItS583mYSl3J7F8WZZbsj1nCX7X8R/yeTdTGgsNGUfF35VfsqnRWhJ3PJmKNSluZ TIzdMn0Ds9E5FAy5RlyfS6Y7iwUNHKOdcoi1XPATbM3oV+rbzuO0ixI1aRUJ8/Bgw9zE SoGizk1KyS8LJ/pmQbrRxOb5E5yX3LcU1VrH9MH6I6zQc5F06/ZxPfJGIM0t/5yWazui TWJEz0VE7AQhyPj/Ao6G1pl8naoDmpOPDXMC/C3DX+wIQsnzuATC1HOi5vAkhN7Lv7u9 FmvA== X-Gm-Message-State: AG10YOThIMJja2wPiqeVX37oym1kXwmjoxFlX3+zFB0wKdTG8+DAseQe8v11WZk20n7sPU+6nDIo6MQcs7sIwJy7 MIME-Version: 1.0 X-Received: by 10.112.55.72 with SMTP id q8mr2346243lbp.8.1454357380223; Mon, 01 Feb 2016 12:09:40 -0800 (PST) Received: by 10.114.199.81 with HTTP; Mon, 1 Feb 2016 12:09:39 -0800 (PST) In-Reply-To: <1FDBF3DD-6CEA-4E2E-AA7E-F3C12EB2B32A@wunderlich.ca> References: <1FDBF3DD-6CEA-4E2E-AA7E-F3C12EB2B32A@wunderlich.ca> Date: Mon, 1 Feb 2016 12:09:39 -0800 Message-ID: From: Sarah Squire To: John Wunderlich Content-Type: multipart/related; boundary=001a11c3ee2006e074052abaf7bd Archived-At: Cc: Justin Richer Subject: Re: [Id-event] Proposal for Identity Event Standard X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 20:09:45 -0000 --001a11c3ee2006e074052abaf7bd Content-Type: multipart/alternative; boundary=001a11c3ee2006e070052abaf7bc --001a11c3ee2006e070052abaf7bc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi John, Good questions. I'm not proposing a distributed database or anything blockchain-like. I am merely suggesting, as you say, that we add a few more prescribed transactions and an endpoint for them to the existing standards. These seem to be high-value communications that currently aren't happening or are happening out of band in non-standardized communications. There may well be additional categories. I'd be curious if other folks on this list have more use cases that this standard could address. Sarah Sarah Squire Engage Identity http://engageidentity.com On Mon, Feb 1, 2016 at 11:56 AM, John Wunderlich wrote= : > Sarah; > > Are you replicating the problem of =E2=80=9C..no language to talk to each= other > outside of prescribed transactions=E2=80=9D at a higher level by prescrib= ing a set > of four categories? It seems an appropriate solution to the cases you > describe, but are there other cases that would necessitate additional > categories? When I read the first part of your strawman, I thought your > reference to a JSON Web Log was starting down the road to a distributed > database (must still have blockchain on my mind from the last IIW). Or am= I > misunderstanding and is what you are proposing a semantic solution to the > problem you pose? > > Sincerely, > *John Wunderlich* > *(@PrivacyCDN)* > > > > > Privacist & PbD Ambassador > > > > > > On Feb 1, 2016, at 12:35, Sarah Squire wrote: > > Hi all, > > I=E2=80=99ve been mulling the idea of identity events and have run into s= everal > situations with different clients where they could be useful. I have a > strawman that I would love for you all to take a few torches to. > > I propose that we create a new standard for a JSON Web Log, or JWL. > > The problem I=E2=80=99m running into is that in distributed access manage= ment > protocols like OAuth and UMA, different ecosystem parties are often in > different security domains and have no language to talk to each other > outside of prescribed transactions. There are many cases in which only on= e > party has a log of an identity event, and it would be helpful if they had > some way to transmit that log to other parties in the ecosystem. > > Here is a list of a few things that a relying party might want to say to > an identity provider: > > > - This user=E2=80=99s behavior is inconsistent with past heuristics an= d I > suspect fraud > - the RP did parallel authentication of a second factor (e.g. My > employee Susan has verified that this user matches (or does not match)= the > photo on file at the IdP) > - Here is a privacy policy that this user consented to > > > Here is a list of a few things that an identity provider might want to sa= y > to a relying party: > > > - This user=E2=80=99s email changed since the last time you called the > UserInfo endpoint > - A user account we have authenticated for you in the past has been > compromised > - This user has revoked your access token > > > My proposal is that a JWL standard be developed based on the form of a > JWT, though with some different fields. It should require iss, sub, aud, > and iat, and the optional fields I think would fall into four categories: > suspected fraud, userinfo update, consent information, and parallel > authentication. Both RPs and IdPs would implement a JWL endpoint to recei= ve > JWLs from other members of the ecosystem. > > Thoughts? Would this be helpful? > > Sarah > > Sarah Squire > Engage Identity > http://engageidentity.com > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > > > > This email and any files transmitted with it are confidential and intende= d > solely for the use of the individual or entity to whom they are addressed= . > If you have received this email in error please notify the system manager= . > This message contains confidential information and is intended only for t= he > individual named. If you are not the named addressee you should not > disseminate, distribute or copy this e-mail. Please notify the sender > immediately by e-mail if you have received this e-mail by mistake and > delete this e-mail from your system. If you are not the intended recipien= t > you are notified that disclosing, copying, distributing or taking any > action in reliance on the contents of this information is strictly > prohibited. > --001a11c3ee2006e070052abaf7bc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi John,

Good questions. I'm = not proposing a distributed database or anything blockchain-like. I am mere= ly suggesting, as you say, that we add a few more prescribed transactions a= nd an endpoint for them to the existing standards. These seem to be high-va= lue communications that currently aren't happening or are happening out= of band in non-standardized communications.

There may w= ell be additional categories. I'd be curious if other folks on this lis= t have more use cases that this standard could address.

Sarah

Sarah Squire
Engage Ide= ntity

On Mon, Feb 1, 2016 at 11:56 AM, John Wunder= lich <john@wunderlich.ca> wrote:
Sarah;

Are y= ou replicating the problem of =E2=80=9C..no language to talk to each other = outside of prescribed transactions=E2=80=9D at a higher level by prescribin= g a set of four categories? It seems an appropriate solution to the cases y= ou describe, but are there other cases that would necessitate additional ca= tegories? When I read the first part of your strawman, I thought your refer= ence to a JSON Web Log was starting down the road to a distributed database= (must still have blockchain on my mind from the last IIW). Or am I misunde= rstanding and is what you are proposing a semantic solution to the problem = you pose?

Sincerely,
John Wunderlich
(@PrivacyCDN)

On Feb 1, 2016, at 12:35, Sarah Squire <sarah@engageidentity.com> wrote:=

Hi all,

I=E2=80=99ve been mulling the idea of ide= ntity events and have run into several situations with different clients wh= ere they could be useful. I have a strawman that I would love for you all t= o take a few torches to.

I propose that we create a new standard for a JSON Web Log, or JWL= .

The problem I= =E2=80=99m running into is that in distributed access management protocols = like OAuth and UMA, different ecosystem parties are often in different secu= rity domains and have no language to talk to each other outside of prescrib= ed transactions. There are many cases in which only one party has a log of = an identity event, and it would be helpful if they had some way to transmit= that log to other parties in the ecosystem.

Here is a list of a few things that a relying = party might want to say to an identity provider:

  • This user=E2=80=99s beha= vior is inconsistent with past heuristics and I suspect fraud
    <= /li>
  • the RP did parallel authentication of a second factor (e.g= . My employee Susan has verified that this user matches (or does not match)= the photo on file at the IdP)
  • Here is a priv= acy policy that this user consented to

Here is a list of a few things that an ide= ntity provider might want to say to a relying party:

  • This user=E2=80=99s e= mail changed since the last time you called the UserInfo endpoint
  • A user account we have authenticated for you in the pa= st has been compromised
  • This user has revoked= your access token

    • My proposal is that a JWL standard be developed based on the f= orm of a JWT, though with some different fields. It should require iss, sub= , aud, and iat, and the optional fields I think would fall into four catego= ries: suspected fraud, userinfo update, consent information, and parallel a= uthentication. Both RPs and IdPs would implement a JWL endpoint to receive = JWLs from other members of the ecosystem.

    Thoughts? Would this be helpful?

    =
    Sarah
    <= font face=3D"Arial">
    Sarah Squire
    Engage Identity
    _______________________________________________
    Id-event mailing listId-event@ietf.org
    https://www.ietf.org/mailman/listinfo/id-event
    =



    <= /div>
    This email= and any files transmitted with it are confidential and intended solely for= the use of the individual or entity to whom they are addressed. If you hav= e received this email in error please notify the system manager. This messa= ge contains confidential information and is intended only for the individua= l named. If you are not the named addressee you should not disseminate, dis= tribute or copy this e-mail. Please notify the sender immediately by e-mail= if you have received this e-mail by mistake and delete this e-mail from yo= ur system. If you are not the intended recipient you are notified that disc= losing, copying, distributing or taking any action in reliance on the conte= nts of this information is strictly prohibited.

    --001a11c3ee2006e070052abaf7bc-- --001a11c3ee2006e074052abaf7bd Content-Type: image/tiff; name="PastedGraphic-4.tiff" Content-Disposition: inline; filename="PastedGraphic-4.tiff" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: a3636125525a503b_0.0.1 TU0AKgAAIpyAIGBACCQWDQeEQmFQuGQ2HQ+IQYynY7BIqqJRAAcBURCAYicPD9vOp0gB3vZ7gB+v 5/A0WBULFcDgQBhx8P1+g6cP2Fv+CggCAQAB0KBMAOZ2u5uKBmNE8EYUiQPBoFA0ACYPBujul0tZ UtlqstVFUqgBBWd3RG1Wu2W23W2BIG33O6XQ/XcCKdvOMQutxuQdAcHgwauR0uwJBsHg4oPB8Sl+ P1/gkK5UAPd9voAP4AAEAOWuABVM9pJ4bh0Nj8SBgLCMAZGCz5/z4AAPbQQBAIAPV+PwAO14vJ4O F3vFsEEXiwcAYBZ4Hg0HAB8PV6697PV8BEGAt/ut4PJiAiZtoTBYLgBwu12qsXhkKuZgqRSNu6/X 7feCXH8fu6vIdB8GALgMAwuASAwDh4ALPBsfKWACA4EgU356OqeZ5nkAACgEAYAHge6UnwfR9gAm cOQ03QGAQBAAAbFqTHlDChJ8BcBgA2gAAUBIEgAdh4niZJknEcphnYep7AAFQLgsDQgBUE4tHhHy VJYABuKSZJznieZ9MUBoegCoLOgIAoAPEA8yzCfrHxIzx/HynxZg2BYFHWebZk4PYgB2d5DLObT+ UA+79UDQiCg4I4lh0dR7nyJwDgOAwfNmf4cn+255nwfAAS0elNnvTR9N6zqCnyfrfH82YAAJDcbV Sex9xGe0RM3VMFIJVNaJ9VEboI20OH23rM1MfIFALMgHRUAQIgVZgEgKoQENuap0HSXNIAKeoeA+ DolwPR5tHSdZlgbAYWn4lgEVKnl1IIA0V1W3R/n5EYIWe7MWl0FILAkVwohQExTrOQTNULgqEUHg y6H8HAfCWB4FAQOoDxUH56H2nh3HtI53HgeEO0+AB81EfScNqALdHofTNZInlJ5DUSCM8ADm1yzc qARHQAQHM7ms9nuZ1tWzpQ/VuY5plyWJ8yKeALR7OtyAAEgWBeZ6gekLNefNNH9lQAArFwKRzNCh AHmjdM8x1QSpBrOQjqgDtuBIBgCaQc22YgxBgFhKYEa+E0BhG/ocf4eCCJAGAKAw6n7sohHlWcon i6VYVGgh8VEeUQpNojMRHXbatulbOANCIAAZnJ/Xmgh9Hzr2pgADIIggo53HeaB2pQbIOsWAAMAc BgABACXZgddx/l4bhtk+bJ1nWd61C8GYZCr34Gg8cB1HUAB0HpTpvHZ54IASBAYx0BQTG40J8gFG Tb6ueedVtYsObhDmRJ4fZ/J5mNVRVHD43gnbHmD0EQIRRhbBYCcSbAhsOCLe4GBwAAVhWCwEocA7 h4hzH2T4ISWzNPvAAAtYxnWZD0HyZobztQADyHy60esJ2nm6J4Z4CYEQIkEa0UMCADx9D2MeMAFo HgPDhAmqsbYy1qCzC6CsFQAAgAmBEQYcDAlNQRLYXcPwDyCgZDeLQXgAAUgTAeFIbY8x6AgH4pkJ o5x5j1AmhgAK2HKD2e6bVVLczPEzKEyJEY9CVgAA0TAAAMAIgOHSFIFwKA6i5E6J0UcViIQQUCFQ MoZQPjSHUO4Tw6VgBCHGcFGzRANgNeAPxVI2h1jtABCl548VMsxM8P9k4AIaw3Ae2UAAHnTjsAoB ECYqQQgJAOLkKIMwXDREUWccUkJmFviwBUYA4x1gOkyOoL4vxwDhAsZkfgVh1QnAiPRKgB39IsWe SqP46kKAAnEZwGwJQSAABrIURYZAbAyD4wJgkzQASSPuDaCgXhyD2HyJIcBKAHjyHYOxhYHgOQ+J YAwYg3hwgAGquEACoTfQkTKnMAAEEagjAgA0dIKQOAdFUD0DgGhgAuAuBMYDAi0z8ppFaLAExfDe HAEUYo5R0A/GwOYdAUR2wnPOrYARmVVK2HhDABTrwZgZAsNQKAKwUCSBqBkC4pGBEpcFP6K5dwDC cGWNILg8x+j7E6OVzROh+jMB4VkYAyRzDnCwLYa42wODzHukcmiJmcgehsAAElIxjgXQiJANwOwa i2YEp2mtkbJEOiwAwQowBhhOHaowOY5DsAyHXOupJmgEM0H4mMAAF4dgAAkc0agRAPghDCM4WAqB mMGrAQ+LAChejdHCLEaMbQiDiHOOcf4LyiidAaxAAophojUCcN8dg7gIgCVQZ2c4GgJASSQBIB4y ghAhA8I0ZAqBTCqsnem9RdYsACGDNkKgqBojXCKOlIwWh3qwAUAR1QCjbnVIIBAoI/wnguBUKcLo LgVh0YEOc/FuSFRYAaL2igrhn3CG3NkbQVwWApF8Mccg5gZC4GyNwGw92uj/j/L67gKJSDqBkBoC 4bxyC3FmKi9eOcdMFBsFwLgLhdDaHCG4b5SQtDuREAkBo/zOIbN0AUBx0QOrPGgHMHYOgzifEmI4 ZRdcIEJBqFYLIrBqMkCmNMbI2hohUBYCYYgps0BBG8O8eAKh/yvH8AMoQJgNgaAADKl4ng6g6Bsn 0s43SHBpCGEsGAFQNgcAuO1q5nEwlvo2AVxCqpzj3He/ACcQiCPFGqwIc2O9TFvCOGEMoRxjDlHM IkX43xxAvHYx0AAIQHFWHiqkEV2wABbBaCYNIuRPifEwW7L5BAWhQCsF4aQ8h4icHAOsdg0gZgVA oNUX6QgtSfHkUJ1jM2cAABQBMCA8FtAdDIObGwrS1BhB+EsFI2xKipGkPwcY5iaABAMdLcKCmZER N8ZoC0TIQgfAwAAb4tRetRAOVYdddRzgPkCOACAKgRi1B2JsP4mmBDrPwFQEIMgcjaEIJsSI7Bzj lKsPgf7KjMj1Q4bohxPB9KsAKA+OJNDXj+HwAoDgFh8AfB4DMfg8dqC2BYFcJA2AQBkCmL9gUqi7 ViFkNocAWBhDeG8JYZI5RzgLA+xBGz7DagGTIFwFYJg1XlFMJctVuQf4+BaNIdo8hpDhHYO0foJg IgPF0K4aw2QhjqSMjVXqBwABIBQCQeAWwVAlCaKQS4lxiFuDb5kBgzQrB4BMMAXgmh+BEDAH0Pg5 BTi5CrU2VRukOEORG60DQKgZAAAcCUDoABsCxFebVMvv9+tkTKA1HYEgZgtHICsPoYg+CdGILsUJ dQqAQBkBEbwlRMpJCwEcL49RtjkB8OgV4vwTtadabgg7SoQ1aIIBEBovmgDvAInMFoCKCAmHcNOB qIyfATBKBCRsAqAcHEAcBQBEEuCAE6EEEyYEee6qD8BIEOGCGMEsGWHcHkCKA49eNyN0JSM8CAq0 BwG2FqFgGSIcggiwAWFGGeGmF2GKHGHKBkB4A2AyH+FmG2G+AQXAJKbkQ45cJ8BoocH0EkCOCCCE EVCQGKYMCgAgBCCcG8EaFQFiHOHEHAZmVUIeRGOqBSB8CCAAAoBcBMAAGMEoEyVGQkM84CVuM2Z1 DYAsBwBmSQDUC0BaFIG+GUGoUCCOH0AkDQHOE4FkEuWo1KM89eRshCcSAABGDUCsFyF2AkHwCQIM iwAOHwGSGsBQGWFEFck2FUF2BkHOHYHKaiRIdMAei0AwCGB0L4DOCmDUFCGQF2FovYLuAWzgGuEG EyGMGUDgBuW2ACBMAy4SAAVgG8HIe4BwAEGcF65AISggCGC8C+DIGG7uE2H2HcHcHAGoHUHWAIG2 HaHeA4WiM8fuAAA2Aw4SCiBEA8EkHGxsDegcCSH8AoCyHIE6FmFMHQHImWN0KEIU/UAYA2AuH0BS DOCuE8AkBWBIHWGcEKE0DIHaGcGtBrCuIYJ8QkN0AcB2BgFECeGIFADEYEf2PsCCHaAODmHWFOF2 EZG4HQVHEMJ8eKaoBQD6DGFWFmH8HMCssoLuAsGgEEE2FyGsEYE6BgU4crFKIIAqmMHyA2DMCiCm FmHQGuFqPwHsBsB4C4GWHOHUE+CLHWHSCyBmBeGGHcQuGSFmE2E2EgIUP0sqEsGKGUGkHIU+BCA2 AYQkE6GUGcfiTaVSAgAoAoAACExkFaH0GEF6ComZHlHpHtHxH1H5CwIRIuAETIBEDKCkF0F6A0H6 COIMDCB4CODeGgDGEIEgHGHA0QRMJ6ZCAAAsBmBgH6B6E8EEBOEutq0QPvJLJPJTJXJbJeNiRYAM QkBMDyC+FcFsAEHWCmLUiwAsF0CSDYGQHGFwGABCN8Q4Nk98M0BACCB+HwBoEoDmCCEmFYFQGQPw A6CSCaEsF0HUHeDSBkbkDuDqCEB+48LOY9GcIGCaDGDKDWFkG+HGEoAsbmAAF4G2G84UY4RI54H2 lmCKBMBGHOEOCKB+CEgZMXHnHrHvHzH3CvH8IStKN0BGDQCqGGF8AuH4B9M/NCD6GcDCLOHMHEG/ CuTIIUliNqbEAMH8AKA+G+DyCMmXN1JNJRJVJYHXJdELOCXJOJONOROVOYLaCWAaA+DYHCEQFIEm HSHU1LH7EOM4AaAG36AiCUB2FwGYBoAoCSPwiwAiDyF6GEFYk+HqBsCwBQBOBIGcFYFIJLP2LkAg CGCMEuHjMqDQAOhyFONITKhGYuJ4BGA6A4AADOgSDSGIvM2OppMZQ5MfQ/S+IUM4RGAwBCiiAoCW B2DuAEUgF+HoGQ20HAGKGSapMkIfTCAWOiBgEUDcDqFYHYGyEYPxN3SNN9STOBDXSaKvSfOTOWLc D88yAaFSBkC2GSHqHAHIBSRHDVEON8AoA0A4H6BCDUCuB6FqH6HIGOPwCWx8BIE4GyHAG2AKHyHu EgAoGkGaDiIUHcNmAaEyF8GGGajiAMBEG+eyAGGOHEHIRwhGH+tQCOBFR+ECCMCABaYEwAn5U3Md Q9MjRCIYeAQ4AqCeB8FQAMAcAUFoHeFeGIFIe4LS9cIe4CQGAMH+BWDeC0CeFuAYHmFnWDSLN7SR SU99WPOHWTOPWXSkLmByGoHmF+HOFWF6CAJTJHDWJ8AYTCA+DGCkFsF+A0H8CWUCHk5IE8HybKCy EeCSB+BWT6ENQUIKG6HMHuAoE6GiGMHWAMKCGcomHABWhYHyTOVsu8AeH8CwScDSHDBIE0vTYxQ7 MhRAIbaoAOQkBQD2DED0A0CEBmF+GICoDwF6HcHQHOQlaDccNeAAAfUidgCKB0BCGEA+ADCtSJN5 SPN/SXaFSdaLSiLqBoGOHODOHaF2GWEwHsrSIW36IIAZDCGwGuCmBaBSUCBCCWCgB8GWzoGCAMHw HsBqAcGcGUtuIKF2HcG6AWFoGEeYBRGEASFCGUGaVa/UIIBWAtMEEQCeCSA2E3CQ1KsncVU7Y2IX VCd6BIniBGDaCqBaFgHgG+GoBCEyGCG2H2HMHYBIRGIgN0RGAkBgBaHACmGeFSByYFJddhWHZ/WN EPWROLdvWYLoBwGaHaCKHiGOGoF0HaHWJLdoIKM4M0A6BcBeHuCIF8E0CYEUEqEg/gPusqCaFCFS GMe+HbXEHqHY8uIKFuGqGqB0GMHQHcGEAgPEAGFLL2Qy54H8TCBUdkGgFACuChQwLPAcslf1Y1cb RxdIAqwUHKCiGaFMCEVUAIHGF8C0DyGsG6FOFiBAM5RuISM4J4AsAWhuAwDMCeE6F6AgHsDIUDWF Z9dndEJ9hLWVdwLoCg7ECYG6EsFbKkG8G5RsIOXWAAA+BUBagkEEDWCuFEGqGEvQUAHmBkBuGiF+ ooDgGYDcDNCUIIH2FaGiGqEAF2HGHODktae2F2ooBKAGyYVUAYeAH8SME0COHaHIDOx1jbcZU+IS 4CH+TIHmA6CEB0HdZIAWAIHOGKGcAuHqHMHUAJhranCwRGAmBkBiHOCKFWESB+EcFIE+PoUBkrdl WLhrkzaHhNShhQLmCgASA9lAEvlGHQG+0QyeIPf8AuA7AAA6DGCWCmFuACHYFcUCBuCuC0EQGy72 FqCOBMBIDqWeAEDSFQGcGiDSF/nkEgAw7QHwFoGwG0AcAKVsHwuuCCBCA6HqEcCaCQBSYEHHcTQ3 Yzm/VoIYM4U0A0BcBgNqQMlWGSGGQyhDEOJ8KEM836N0BICWCI1uDoC0DOE6GEFvcQYLoNWJaBJh OFdtobaOLfohokG7opKlovlOINf8AwA+iiA8DOCgCmFrgdpMYKDax8AsFsHgHqF4CU8iCSBEEAEA AsBoBGBWHEBbBoAOFeGlDyAMNug2J8BQAoAkH6D0CQCEA4FYEmEng/jZqncXU9qsIXlSAsBeBctT HWAAHSGUGg98KEAKmEN2H6H0HiA2B8BoGmBLlgEeEyFuFdsib/rthFoTr1aJr4LqClk+G3lFlJlN oyIMN8daBIBeBiAABYEgDkCzriFuxwYKBWCakpK2HMCIEQCUCICwDcFmFmAiHSQ8HMBMAwAuAQF4 zSVoVuVSX2AkH8DaBqBiDEvKFI+jfzt5f3jeIaM4daAq4MBYDgC6DwHmHAHPYSSoA5IUdgB8B4GO EEE+EdbYn5u/kvrzk1hPr6LcCGHOAGCWHOFkGEFoHYHNYSM9Y498M4AcW2HECsGwFcB4EFCRqiYK AKB6CCF3bsAIHeHqF+F2CsUmAoDaFgFqHQAWZwAGGSHCmWxRgkIKATFOAACNBoFYH2GKF+LLxBMb t7f4cGozC+BXeaCGFUEYA5PKFJFGIaBKE4GOBzH8AGBmD4DEGlZWGuQxrrZ7oPrxSZoXk3ocLeBC EwGGCOAE06FwHpeuILW036M4AwCWB+GmGWBsAtuIYKCOC4DKBeFhlKGcBghqCaGyFnOQUmAKDqFo F0FgH2QGCUHQ2oAAlQlURKZCSoBwBAA8H0EsCcCQBmYFDzU1xDjdnBIt0OAp0SAABuEQDcBYE+Gc GEGqIUC4BsB8BYGmDeEiGmAGZEAABED0DEB+FYHQGmGEYNx7oRkxvFoZaMLqB0GwHuE6HO9SDESP alDYJ4AoAgu4BADgC4EBpGHQLkUAiwASEFcyF4HmhaAyEWCQCH3JjUP0A/PWDWGMfAEoAQH2daGG G8mX20c+AaAgdmCuBKBEFUDLDgCyYEM4khm9t9yhH/3Z3d3h3l3p3sIUDCBsB+BUGQDcEaGr4CN9 ckDCB74QGvigUL4b1HdrvH4kLaiwAoFwCQDSGQHKFyGIBGN85p1l0OAuBsBoHOCeGSFHqeLOckUA AsCGCODaGgOwElcHDEBeAkAiC2EmEYEUFNLcLuAeC2FKzIA6AsAqA4GiHFqiSKr8agcuN8BiBINc C8BMBCDGGEvME9Q10HxF3VNYM13beb6z3n3r3uIT697AGP7H7L4EBSD37T7X7aUJ7fhHoVr37mLY CwA+BgCCGyEKE+F8HGG2gaQ436N8U1gAiaA2DmC0D4FcHUGuELkoC8C8C4EurKFABTwcAGBeIAEw g5Hy93oMmutVq60DDQBD4e8BkODY9QGBEmDH6+wAv243wABouAACAYe/AEAgALAwF3KZBYKSYvVQ pGhEJxOZ1O55OyS/goWXInVmpnQ5HEAJUBJ7OH+AH0AAoKxSABuiDcLE+zmE1Z4YRsPxUxzcjWqB Hy/QAOVMhxYGR2Lm0714zQSAHe7wAESqRH4gsA9qbTSC7QOc3Wp12jHU63RJAAA4hTwaBgUABMej CrlsAXSU8HOT9owsvyqdVk3VYthvaqZanyAAsFQwABCaCsthmgjUWMAgnnoeFECCXi+XFAz2qo30 /H4ACWMBaAALBTa1VcrEpOIagdFowcZlctGqEQcDg47LyAGe5XOAAOBKY//pDwOCAAPxCHnUeB6F wkEmRRJme4cDJ2JZ/gwKRxk4WBWnOchwqUACmNCp6ogoFgVKsQQ2hIT5pmEbqvrCFRjLKap/nuqI NiaHpPnMYJlNaeJ7hAf5+o2CAVBCeAPiQHpLFce5wkVA4hnkBo5nSUZbMYdT3pMySHqeBzLAAFBA DIVZZn2cwrNC0Y/AsZo/kuXJvEuVIYMadMKH8AAPA+EYAAwLQlN0Qw2Cm358QO0IPCSKAuF8cRxF GeR7nuAAfBGEQAASAR/mgNIbhoH7fnk7iHJ4FIpCoMBWGsbZOBQCIHgGaZzzebx2r0BQCtef84gG BLLh0DoNHUJoQhKJJglQrdAJ3MYJogCBfDCPgmnSVpfEeeB5ngyEqMGp7YgoFCqiOWJIiSBwTBAb DfnAnCwLEZA6kkap2GoawAA4CgNgAfFYgAfJ/H4cp/H2foMgEdJ1gECgRBCAALjQKJLlme5xjU0I eG0fQ0HeWpiEudZ4HZarJgABQBALj4YBIXIjlORg1AYEwOgAaRLFOAB3Gaa4eHwbhzDmdhjmgFx6 H2eIAAcA4IgABAXUgEIliEPwYj+MxGN/RliO+PwFkiY5mEGWRqmuOAGAQBAAhyDwOaEBQFgAEQDA YGhlFgUhmp47rhAeIIileaJ5nsKAUgU/BjHCcYAG+dy9ASAuRH9xaSASu4RgaBp1CKEIOi8cRclq XMDhCThhhICoVBKZoKAwCwHHUaZtAAeRuwmksLQMp61AKBO0guHIXAAf+RQqDoMlWHJFjkLBvFeY ASGaPhJGyepuG8AASCuJhdhGNYrEKDIbhcYhzloYIWGsSpWEYcxcGAIgJBsGJ8iWZJRBaWgpDOAA JAWC5Dncc7HnSZJogsAQz8E5z04k8KfAd3ZUgZAsaMQJ1g3Ckj9HMxwAQ/E4gEA+BUyIFQHjlA+E cHwzARBdCeJARwphNjAaoT1MYCQ/i9GELEZo7x5hFAMPcwQM1dIVAMAYAAGgDgHDUN8WosBLmhbo mI0YFQ+i8GCLEdA+R+A5BkeYAAvHngAHCO9oIBQBkqPoU8lBkgTgZNqDt34kg1A1BiIo345SeAyG WOUCo+xwDtCOPIdY7R9gMAqBMf4BwLARgLCsh6/SODzHAOcyQ+B9ABBMGsKoBgah/DUKMbwtBgAn GYHIRw1wCD6TiDUUofQaifF6LkZhPA5BlDSDQXAPQxjGAKPQfABQRh6C6EYdo5hujqAKOIfYqx4j xWoP85w9x/kXHqSokyFwAD+gqPUe4Ah+j6I4BIETLQBgTAcPEborheCcCAIQN4/QPhgCcMM36b5D FNB+FgMIKhVDXGoI8cA9x8hGAcP054JALgWAAP0ARkh5j0HmGoCo0BlRHQNElAwbaJAQD+MUZYth /AFAMDkEgCgDgAGgOZN40BznvPiyIlRD5RJxAoBNY4LAIAOHEDoD4HQ0nYFULad9O6droLGikAg+ 04goEEGgGYrBvjOGcTxMYDhVAwCoOgAI3B0AJAiEYGwUBjAwAgLGnlX6wKAhaJ0Zo0BIi/G6OILo 8B9j7AQBQAhKgLgPAeABqa+B6j2DSBsaozhMQrogsQJYXAuAQF2OQdItRxD2HwDoDwBmRDpHqPQA Ax3BFKACSofqtJoj9gLRoAAHQIgQJWBYCYvgkgmBCIwXYnxPi3rDbEnNPhjhwEcNUAI7jggrD8GU MQrB3DbE+TwLgHgaBtk6IoSACSBACBkJ4PYUBOi/FvV62V16eJjAQKAZozwwDCHAOQNw6R8j7BSP 8fRsQLNhaFXR3czwCj6H0GoCFDKHTvsDIZMYEhQjPGmLQYw6B1g5AoAEp5IjJDHHEORfBzqBuMHw Ps55aiHgIbQAAEcDgaAZAuLwGYHwNhkF6JsTaE7sQrp8MgOQjxqjrGuNIAAEwPAnKADsF4rSngAF uAOyANR2jFGcFoe43BwAPA6FwKA3wgCjEKDBTWJ8oGDhaJQYYxwuDYHcPAOA35qAqHePUeuMQCGS AsAwBhUHEnwJSNYIYGwMiMG3EW4dYb83ZNGBIWo2xuyaHOOwHNJRzYYtGAAeI+DYuFL0PjBw9psL 1wcPw+oDHIsIAOAYdwLAOAbE6F4GYLRhCkEcI4WmUSmhpB+EsFo1hACbGkPcdQ7a7APAOfQag4gA gO0mPcd6mx9Q+fqEAGg5wVB9DKFwTItRWC+1JssAAejRguFWNUbIbRiDfHEEUbjhgPjrHpmEBNnA PUxAA5EBruyRgnAeA0ZoYwaAvCagIRR77sZ1rDfsW42xviAGSOQcwbRujvWoBEAZJsy5nHVt0AA6 R6WURsbEeo+yoyOI4P4AZkgIAPtIBsBhl20gAF8BzdIuVxAbFMFUEQIh5m/aDvUMoZQKjhGONYNo B1blSCCDUVgxA1iEB0OwX4ywNwEAACoLwUR6AuEAGYTpv2ObMrAmMCgtBsDaCSL8cA5Qfjt4WFux Y9wEDtmK0I+UPwG5nAREE6mZiSD5HwNoIAIgQCGC2C4FQqDfmx1JvTKINgsBcCiXMeAfx0YSBeOM ckcAL8baN2MdHCEbJ/qEnEeg+So+TNiWl2jjgAAQAW2kA8/h6AoAoBIeB5gHCrA2AoBQswvgzBcN 035SenezuumMDItnnhBGeOgdgQhxjpHUFUcY9h7gOHfo0e9kypXsAx2UkMPV68VQrhIeoOQRAfFF UYFwiTf4m9oQ/vWzAuUSAwLwb45A4jzraHYdvxAAZnTiAf6X7VGDy0M6z+48x8mx0Uc9fxOIeq+Q AA54kzSAp6P4CR3YewwQEBVCbBHQWwGADQDIdIeAfAe4T4OgIgIAeLM4AAcBPz767BMYFAQIXiFQ DY84LoYwcodADIfUC4KSPgfoB4ew+oeAeBoLWRkQCYBAu4CABjjrsaggyTz4foegEACYCQUQNQHQ GYSgSYQwQwa8EQpr8MKoAAHALgLwJBVYdQOoe6zwIQpQlQBAfwtQBLMYAECw2Id79wdz9zQpP6Cw tSCxbDBweryi94lSlZj7zpSL6AfqHDDACoCiu0C4aBoYBIbKjhg4bwdAdIVwdQeofAb4GYDSDQEQ Cpor/qK4bzQIZAbx1bBwAAF6HYDIBLcpKoAAdYfhP4aIcTQIKYqgHQCa0YHIZwb5cwcweQeYCYCp yIIgbodrWAfIkYtQkyhA4JK5kQBUNQCa9xsKj4kglQeoeRRQBDioaIEIDYDAToPoHYG4Yw35eELC h5Tscw4YCQIYI4JYcMXoOge5OIICaQlQCwA5kS9Y/CLwlQdIebMIcjsIcMHIAD/4AEAIqLHInKMI nIksPifw6g+5SK9jMcPj/ZSL6QBrSo+DschgeAe5P8CxP8hgBkjYkR2KMQfwp7yYqIAjNKjRkSzx OK8ojiyayhsEfYko+EjYCwCC0ifw54CT1UVgd4dwbID6lwcwAjs4VIIwDwDIY7T4UjGEdKr8K8qo 0IGgKwLQJgY4cYcYMocAdweIHRyIBgCgDTi794iB2IcoeJTYZwcrQL/QqI5o54AUnQBBWTB6A4+o e7BxxYp8nQh8nSuIyUlROKCxOI+onKL4kyuIlQAzsaZ6aI+slQp8vCZ6zMAcM4qDB0Hwy4BCyBj7 NLWZOIDzQb4gfAaJtABQaMMwfwZQC42gaIOZ7YaI344MrDvMdE3ar5MYDoSgZYaQGzbgeYKKa4fI JgBSHrjEnz976AcYdQdQAEtxTYfEzcM7CbCTxYyQAwlIkL6Rn4jhHQfwfUj4fAf7yIA8jUmMlUhY iEyiL4lUxx3bHKzYp4e6toe7+wfAeYB69gDYCUBJjQeAZIDIB6b4GoEADwA4cAdgdYWYGYEoEwdQ Exv4GK0wCIakDwZw37QM3z78q9ELeo0YDoPEE4B4FsJQMD44fQCoDRtAKpv7mgax/YWweTygEwfy zIDcOAewBIDQC4C7NQlQCMIJoTiAdTCIfgeYAzSoEZHItUfyygeytp+oBI/EAwAAeb+7BEwgh4Bs P7hYeoaikgdIY0oQBIBgFUCYAAdoeYeIbIC5yIDgFIDgDgEoa7fgXAc4eYebPxXUCQC4DIV4fgfY e4a4VgSYSbeVEjp1EdR72gKgOwO0BJRgDYFQCIBCOAh4ewYofBewcQbQbRDjCwGoYwbAbgAAblCB RoEAEAMC0YCAFwdMYjQj/NUMMiMExgyAlIk0hgkwk1ACj4ECMwAD3gdgZQab4AWQGoDwDxhBsIe4 TwYgY4VwM4JIIAfob4VgVhwdSVcIh4gIAAASAQAAAwAAAAEAVAAAAQEAAwAAAAEAMgAAAQIAAwAA AAQAACN6AQMAAwAAAAEABQAAAQYAAwAAAAEAAgAAAREABAAAAAEAAAAIARIAAwAAAAEAAQAAARUA AwAAAAEABAAAARYAAwAAAAEAMgAAARcABAAAAAEAACKTARoABQAAAAEAACOCARsABQAAAAEAACOK ARwAAwAAAAEAAQAAASgAAwAAAAEAAgAAAT0AAwAAAAEAAgAAAVIAAwAAAAEAAgAAAVMAAwAAAAQA ACOSh3MABwAADEgAACOaAAAAAAAIAAgACAAIYAAAAAEAAABgAo+AAQAAAAABAAEAAQABAAAMSExp bm8CEAAAbW50clJHQiBYWVogB84AAgAJAAYAMQAAYWNzcE1TRlQAAAAASUVDIHNSR0IAAAAAAAAA AAAAAAAAAPbWAAEAAAAA0y1IUCAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAARY3BydAAAAVAAAAAzZGVzYwAAAYQAAABsd3RwdAAAAfAAAAAUYmtwdAAAAgQA AAAUclhZWgAAAhgAAAAUZ1hZWgAAAiwAAAAUYlhZWgAAAkAAAAAUZG1uZAAAAlQAAABwZG1kZAAA AsQAAACIdnVlZAAAA0wAAACGdmlldwAAA9QAAAAkbHVtaQAAA/gAAAAUbWVhcwAABAwAAAAkdGVj aAAABDAAAAAMclRSQwAABDwAAAgMZ1RSQwAABDwAAAgMYlRSQwAABDwAAAgMdGV4dAAAAABDb3B5 cmlnaHQgKGMpIDE5OTggSGV3bGV0dC1QYWNrYXJkIENvbXBhbnkAAGRlc2MAAAAAAAAAEnNSR0Ig SUVDNjE5NjYtMi4xAAAAAAAAAAAAAAASc1JHQiBJRUM2MTk2Ni0yLjEAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFhZWiAAAAAAAADzUQABAAAAARbMWFla IAAAAAAAAAAAAAAAAAAAAABYWVogAAAAAAAAb6IAADj1AAADkFhZWiAAAAAAAABimQAAt4UAABja WFlaIAAAAAAAACSgAAAPhAAAts9kZXNjAAAAAAAAABZJRUMgaHR0cDovL3d3dy5pZWMuY2gAAAAA AAAAAAAAABZJRUMgaHR0cDovL3d3dy5pZWMuY2gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAZGVzYwAAAAAAAAAuSUVDIDYxOTY2LTIuMSBEZWZhdWx0IFJHQiBj b2xvdXIgc3BhY2UgLSBzUkdCAAAAAAAAAAAAAAAuSUVDIDYxOTY2LTIuMSBEZWZhdWx0IFJHQiBj b2xvdXIgc3BhY2UgLSBzUkdCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGRlc2MAAAAAAAAALFJlZmVy ZW5jZSBWaWV3aW5nIENvbmRpdGlvbiBpbiBJRUM2MTk2Ni0yLjEAAAAAAAAAAAAAACxSZWZlcmVu Y2UgVmlld2luZyBDb25kaXRpb24gaW4gSUVDNjE5NjYtMi4xAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAB2aWV3AAAAAAATpP4AFF8uABDPFAAD7cwABBMLAANcngAAAAFYWVogAAAAAABMCVYAUAAA AFcf521lYXMAAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAKPAAAAAnNpZyAAAAAAQ1JUIGN1cnYA AAAAAAAEAAAAAAUACgAPABQAGQAeACMAKAAtADIANwA7AEAARQBKAE8AVABZAF4AYwBoAG0AcgB3 AHwAgQCGAIsAkACVAJoAnwCkAKkArgCyALcAvADBAMYAywDQANUA2wDgAOUA6wDwAPYA+wEBAQcB DQETARkBHwElASsBMgE4AT4BRQFMAVIBWQFgAWcBbgF1AXwBgwGLAZIBmgGhAakBsQG5AcEByQHR AdkB4QHpAfIB+gIDAgwCFAIdAiYCLwI4AkECSwJUAl0CZwJxAnoChAKOApgCogKsArYCwQLLAtUC 4ALrAvUDAAMLAxYDIQMtAzgDQwNPA1oDZgNyA34DigOWA6IDrgO6A8cD0wPgA+wD+QQGBBMEIAQt BDsESARVBGMEcQR+BIwEmgSoBLYExATTBOEE8AT+BQ0FHAUrBToFSQVYBWcFdwWGBZYFpgW1BcUF 1QXlBfYGBgYWBicGNwZIBlkGagZ7BowGnQavBsAG0QbjBvUHBwcZBysHPQdPB2EHdAeGB5kHrAe/ B9IH5Qf4CAsIHwgyCEYIWghuCIIIlgiqCL4I0gjnCPsJEAklCToJTwlkCXkJjwmkCboJzwnlCfsK EQonCj0KVApqCoEKmAquCsUK3ArzCwsLIgs5C1ELaQuAC5gLsAvIC+EL+QwSDCoMQwxcDHUMjgyn DMAM2QzzDQ0NJg1ADVoNdA2ODakNww3eDfgOEw4uDkkOZA5/DpsOtg7SDu4PCQ8lD0EPXg96D5YP sw/PD+wQCRAmEEMQYRB+EJsQuRDXEPURExExEU8RbRGMEaoRyRHoEgcSJhJFEmQShBKjEsMS4xMD EyMTQxNjE4MTpBPFE+UUBhQnFEkUahSLFK0UzhTwFRIVNBVWFXgVmxW9FeAWAxYmFkkWbBaPFrIW 1hb6Fx0XQRdlF4kXrhfSF/cYGxhAGGUYihivGNUY+hkgGUUZaxmRGbcZ3RoEGioaURp3Gp4axRrs GxQbOxtjG4obshvaHAIcKhxSHHscoxzMHPUdHh1HHXAdmR3DHeweFh5AHmoelB6+HukfEx8+H2kf lB+/H+ogFSBBIGwgmCDEIPAhHCFIIXUhoSHOIfsiJyJVIoIiryLdIwojOCNmI5QjwiPwJB8kTSR8 JKsk2iUJJTglaCWXJccl9yYnJlcmhya3JugnGCdJJ3onqyfcKA0oPyhxKKIo1CkGKTgpaymdKdAq Aio1KmgqmyrPKwIrNitpK50r0SwFLDksbiyiLNctDC1BLXYtqy3hLhYuTC6CLrcu7i8kL1ovkS/H L/4wNTBsMKQw2zESMUoxgjG6MfIyKjJjMpsy1DMNM0YzfzO4M/E0KzRlNJ402DUTNU01hzXCNf02 NzZyNq426TckN2A3nDfXOBQ4UDiMOMg5BTlCOX85vDn5OjY6dDqyOu87LTtrO6o76DwnPGU8pDzj PSI9YT2hPeA+ID5gPqA+4D8hP2E/oj/iQCNAZECmQOdBKUFqQaxB7kIwQnJCtUL3QzpDfUPARANE R0SKRM5FEkVVRZpF3kYiRmdGq0bwRzVHe0fASAVIS0iRSNdJHUljSalJ8Eo3Sn1KxEsMS1NLmkvi TCpMcky6TQJNSk2TTdxOJU5uTrdPAE9JT5NP3VAnUHFQu1EGUVBRm1HmUjFSfFLHUxNTX1OqU/ZU QlSPVNtVKFV1VcJWD1ZcVqlW91dEV5JX4FgvWH1Yy1kaWWlZuFoHWlZaplr1W0VblVvlXDVchlzW XSddeF3JXhpebF69Xw9fYV+zYAVgV2CqYPxhT2GiYfViSWKcYvBjQ2OXY+tkQGSUZOllPWWSZedm PWaSZuhnPWeTZ+loP2iWaOxpQ2maafFqSGqfavdrT2una/9sV2yvbQhtYG25bhJua27Ebx5veG/R cCtwhnDgcTpxlXHwcktypnMBc11zuHQUdHB0zHUodYV14XY+dpt2+HdWd7N4EXhueMx5KnmJeed6 RnqlewR7Y3vCfCF8gXzhfUF9oX4BfmJ+wn8jf4R/5YBHgKiBCoFrgc2CMIKSgvSDV4O6hB2EgITj hUeFq4YOhnKG14c7h5+IBIhpiM6JM4mZif6KZIrKizCLlov8jGOMyo0xjZiN/45mjs6PNo+ekAaQ bpDWkT+RqJIRknqS45NNk7aUIJSKlPSVX5XJljSWn5cKl3WX4JhMmLiZJJmQmfyaaJrVm0Kbr5wc nImc951kndKeQJ6unx2fi5/6oGmg2KFHobaiJqKWowajdqPmpFakx6U4pammGqaLpv2nbqfgqFKo xKk3qamqHKqPqwKrdavprFys0K1ErbiuLa6hrxavi7AAsHWw6rFgsdayS7LCszizrrQltJy1E7WK tgG2ebbwt2i34LhZuNG5SrnCuju6tbsuu6e8IbybvRW9j74KvoS+/796v/XAcMDswWfB48JfwtvD WMPUxFHEzsVLxcjGRsbDx0HHv8g9yLzJOsm5yjjKt8s2y7bMNcy1zTXNtc42zrbPN8+40DnQutE8 0b7SP9LB00TTxtRJ1MvVTtXR1lXW2Ndc1+DYZNjo2WzZ8dp22vvbgNwF3IrdEN2W3hzeot8p36/g NuC94UThzOJT4tvjY+Pr5HPk/OWE5g3mlucf56noMui86Ubp0Opb6uXrcOv77IbtEe2c7ijutO9A 78zwWPDl8XLx//KM8xnzp/Q09ML1UPXe9m32+/eK+Bn4qPk4+cf6V/rn+3f8B/yY/Sn9uv5L/tz/ bf// --001a11c3ee2006e074052abaf7bd-- From nobody Mon Feb 1 12:11:57 2016 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37CBA1B35AE for ; Mon, 1 Feb 2016 12:11:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q2TNLEKoqkdN for ; Mon, 1 Feb 2016 12:11:52 -0800 (PST) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1E271B35A3 for ; Mon, 1 Feb 2016 12:11:52 -0800 (PST) Received: by mail-ig0-x22d.google.com with SMTP id z14so44714091igp.0 for ; Mon, 01 Feb 2016 12:11:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wunderlich-ca.20150623.gappssmtp.com; s=20150623; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to:content-type; bh=+4eLsJyWrMNT/0jGmYmCjcV1BitGbYj+qu6o3cKAWxc=; b=0t+hYeMz0opET+Zzv+mBk8906NaPN0Yc+60B8ftGVCq7PNGMAERup259UuXuzQDU+S GBr1nnRHv8RBv+rt2a7P7P+Mp76OrmX6zVsB8aUQnXq/sGBbD4KoZS7pS1v5H6zVnYJh pJ11NneFmWgIppswL00ypajPHV3DYBBoefMC7kIHwoQDpZKBorWwYRyNRIXDa1KhXoJi RX8iP6N5BlnuD+bWXEBIHt17dsAAdo0RXUZJyn3oGNqYtEYf5wLIhau3XWcWtsSr01qj +aZ95bk1EprDImdriJ+hHx9b+JuphL9dc9g/s61Oisd0TqpJWUNQ5QMGBs6M/TXw1p1N h2zA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to:content-type; bh=+4eLsJyWrMNT/0jGmYmCjcV1BitGbYj+qu6o3cKAWxc=; b=LIWWUbW8nU1nencUwpMO393kkqNLYSxdKf4yObvuyWv3RuOTKm3H1JZxbatQL6s7dc +kpRrjbkHf25EDlqWhfo8pSgluZMffSANRawrEPDjooYSZldg0PNXW8pnAxAP7iZnsdz GzdWS3zR9V1UPqIjEXhHl5Yzh/GVmjENFViAlPOKIYpvBHUg3DXHyjkfDQ+esy9S1XZv TTeUTTexdgEzMsGTR2gyrh4ipCmyGSfUpCJYFJwnIozaX7NQQ3275TIzkbNzwlwoWS8r FDXbdq62PXcH7Mh24TIL4AY/eliT6m0gW4Fj5tbVt9ViOf3b/aDx+09IrYarWT01BRP7 gjiQ== X-Gm-Message-State: AG10YOQU7XniYzV3YgmGTf25/WZcctqKtq0+Izrb+GkW1PG1FTw6ZfQwd/oUv8578QbYCM+QVIJlOyKix447zjQqVCkdnS5HTfWssqeRNnlXZW/c6SP+e6QyJXT8 X-Received: by 10.50.78.165 with SMTP id c5mr12488103igx.29.1454357511913; Mon, 01 Feb 2016 12:11:51 -0800 (PST) Received: from [10.0.1.186] (dsl-173-206-88-229.tor.primus.ca. [173.206.88.229]) by smtp.gmail.com with ESMTPSA id nq10sm4916225igb.2.2016.02.01.12.11.50 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 01 Feb 2016 12:11:50 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Pgp-Agent: GPGMail 2.6b2 From: John Wunderlich In-Reply-To: Date: Mon, 1 Feb 2016 15:11:49 -0500 Message-Id: References: <1FDBF3DD-6CEA-4E2E-AA7E-F3C12EB2B32A@wunderlich.ca> To: Sarah Squire X-Mailer: Apple Mail (2.3112) Content-Type: multipart/mixed; boundary=089e013c6ee6e38961052abafe91 Archived-At: Cc: Justin Richer Subject: Re: [Id-event] Proposal for Identity Event Standard X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 20:11:56 -0000 --089e013c6ee6e38961052abafe91 Content-Type: multipart/related; type="text/html"; boundary="Apple-Mail=_E7B31ABE-9022-4D45-879B-D1461CC62007" --Apple-Mail=_E7B31ABE-9022-4D45-879B-D1461CC62007 Content-Type: multipart/alternative; boundary="Apple-Mail=_824AB518-AC77-4F18-940C-45C0CEF0DF9F" --Apple-Mail=_824AB518-AC77-4F18-940C-45C0CEF0DF9F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Thanks. It sounds like a useful incremental improvement, as you say, but it does po= int to a more interesting general problem down the road. Sincerely, John Wunderlich (@PrivacyCDN) Privacist & PbD Ambassador > On Feb 1, 2016, at 15:09, Sarah Squire wrote: >=20 > Hi John, >=20 > Good questions. I'm not proposing a distributed database or anything bloc= kchain-like. I am merely suggesting, as you say, that we add a few more pre= scribed transactions and an endpoint for them to the existing standards. Th= ese seem to be high-value communications that currently aren't happening or= are happening out of band in non-standardized communications. >=20 > There may well be additional categories. I'd be curious if other folks on= this list have more use cases that this standard could address. >=20 > Sarah >=20 > Sarah Squire > Engage Identity > http://engageidentity.com > On Mon, Feb 1, 2016 at 11:56 AM, John Wunderlich > wrote: > Sarah; >=20 > Are you replicating the problem of =E2=80=9C..no language to talk to each= other outside of prescribed transactions=E2=80=9D at a higher level by pre= scribing a set of four categories? It seems an appropriate solution to the = cases you describe, but are there other cases that would necessitate additi= onal categories? When I read the first part of your strawman, I thought you= r reference to a JSON Web Log was starting down the road to a distributed d= atabase (must still have blockchain on my mind from the last IIW). Or am I = misunderstanding and is what you are proposing a semantic solution to the p= roblem you pose? >=20 > Sincerely, > John Wunderlich > (@PrivacyCDN) >=20 > >=20 >=20 > Privacist & PbD Ambassador >=20 >=20 >=20 >=20 >> On Feb 1, 2016, at 12:35, Sarah Squire > wrote: >>=20 >> Hi all, >>=20 >> I=E2=80=99ve been mulling the idea of identity events and have run into = several situations with different clients where they could be useful. I hav= e a strawman that I would love for you all to take a few torches to. >>=20 >> I propose that we create a new standard for a JSON Web Log, or JWL. >>=20 >> The problem I=E2=80=99m running into is that in distributed access manag= ement protocols like OAuth and UMA, different ecosystem parties are often i= n different security domains and have no language to talk to each other out= side of prescribed transactions. There are many cases in which only one par= ty has a log of an identity event, and it would be helpful if they had some= way to transmit that log to other parties in the ecosystem. >>=20 >> Here is a list of a few things that a relying party might want to say to= an identity provider: >>=20 >> This user=E2=80=99s behavior is inconsistent with past heuristics and I = suspect fraud >> the RP did parallel authentication of a second factor (e.g. My employee = Susan has verified that this user matches (or does not match) the photo on = file at the IdP) >> Here is a privacy policy that this user consented to >>=20 >> Here is a list of a few things that an identity provider might want to s= ay to a relying party: >>=20 >> This user=E2=80=99s email changed since the last time you called the Use= rInfo endpoint >> A user account we have authenticated for you in the past has been compro= mised >> This user has revoked your access token >>=20 >> My proposal is that a JWL standard be developed based on the form of a J= WT, though with some different fields. It should require iss, sub, aud, and= iat, and the optional fields I think would fall into four categories: susp= ected fraud, userinfo update, consent information, and parallel authenticat= ion. Both RPs and IdPs would implement a JWL endpoint to receive JWLs from = other members of the ecosystem. >>=20 >> Thoughts? Would this be helpful? >>=20 >> Sarah >>=20 >> Sarah Squire >> Engage Identity >> http://engageidentity.com __________________= _____________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://www.ietf.org/mailman/listinfo/id-event >=20 >=20 >=20 > This email and any files transmitted with it are confidential and intende= d solely for the use of the individual or entity to whom they are addressed= . If you have received this email in error please notify the system manager= . This message contains confidential information and is intended only for t= he individual named. If you are not the named addressee you should not diss= eminate, distribute or copy this e-mail. Please notify the sender immediate= ly by e-mail if you have received this e-mail by mistake and delete this e-= mail from your system. If you are not the intended recipient you are notifi= ed that disclosing, copying, distributing or taking any action in reliance = on the contents of this information is strictly prohibited. >=20 --=20 This email and any files transmitted with it are confidential and intended= =20 solely for the use of the individual or entity to whom they are addressed.= =20 If you have received this email in error please notify the system manager.= =20 This message contains confidential information and is intended only for the= =20 individual named. If you are not the named addressee you should not=20 disseminate, distribute or copy this e-mail. Please notify the sender=20 immediately by e-mail if you have received this e-mail by mistake and=20 delete this e-mail from your system. If you are not the intended recipient= =20 you are notified that disclosing, copying, distributing or taking any=20 action in reliance on the contents of this information is strictly=20 prohibited. --Apple-Mail=_824AB518-AC77-4F18-940C-45C0CEF0DF9F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 Thanks.

    It sounds like a useful incremen= tal improvement, as you say, but it does point to a more interesting genera= l problem down the road.

    =
    On Feb 1, 2016, at 15:09, Sarah Squire <sarah@engageidentity.com> wro= te:

    Hi John,

    Good questions. I'm not proposing a distributed database or any= thing blockchain-like. I am merely suggesting, as you say, that we add a fe= w more prescribed transactions and an endpoint for them to the existing sta= ndards. These seem to be high-value communications that currently aren't ha= ppening or are happening out of band in non-standardized communications.
    There may well be additio= nal categories. I'd be curious if other folks on this list have more use ca= ses that this standard could address.

    <= /div>
    Sarah

    Sarah = Squire
    Engage Identit= y
    http://engageidentity.com

    On Mon, Feb 1, 2016 at 11:56 AM, = John Wunderlich <john@wunderlich.ca> = wrote:
    Sarah;

    Are you replicating the problem of =E2=80=9C..no language to talk t= o each other outside of prescribed transactions=E2=80=9D at a higher level = by prescribing a set of four categories? It seems an appropriate solution t= o the cases you describe, but are there other cases that would necessitate = additional categories? When I read the first part of your strawman, I thoug= ht your reference to a JSON Web Log was starting down the road to a distrib= uted database (must still have blockchain on my mind from the last IIW). Or= am I misunderstanding and is what you are proposing a semantic solution to= the problem you pose?

    Sincerely,
    <= div class=3D"">

    On Feb 1, 2016= , at 12:35, Sarah Squire <sarah@engageidentity.com> wrote:
    <= div dir=3D"ltr" class=3D"">
    Hi all,

    I=E2=80=99ve bee= n mulling the idea of identity events and have run into several situations = with different clients where they could be useful. I have a strawman that I= would love for you all to take a few torches to.

    I propos= e that we create a new standard for a JSON Web Log, or JWL.
    The problem I=E2=80=99m running into is that in distributed access manage= ment protocols like OAuth and UMA, different ecosystem parties are often in= different security domains and have no language to talk to each other outs= ide of prescribed transactions. There are many cases in which only one part= y has a log of an identity event, and it would be helpful if they had some = way to transmit that log to other parties in the ecosystem.
    Here is a list of a few things that a relying party might want to say to = an identity provider:

    • This user=E2=80=99s behavior is inconsistent with past heuristics and I = suspect fraud
    • the RP did parallel authentication of a second factor (e.g. My employee S= usan has verified that this user matches (or does not match) the photo on f= ile at the IdP)
    • Here is a privacy policy that this user consented to

    Here is a list of a few things that an identity provider might w= ant to say to a relying party:

    • This user=E2=80=99s email changed since the last time you calle= d the UserInfo endpoint
    • A user account we have authenticated for you in the past has be= en compromised
    • This user has revoked your access token

    My p= roposal is that a JWL standard be developed based on the form of a JWT, tho= ugh with some different fields. It should require iss, sub, aud, and iat, a= nd the optional fields I think would fall into four categories: suspected f= raud, userinfo update, consent information, and parallel authentication. Bo= th RPs and IdPs would implement a JWL endpoint to receive JWLs from other m= embers of the ecosystem.

    Thoughts? Would this be helpful?<= /span>

    Sarah

    Sarah Squire
    Engage Identity
    http://engageidentity.com
    _______________________________________________
    Id-event mail= ing list
    Id-event@ietf.org
    https://www.= ietf.org/mailman/listinfo/id-event



    This email and any files transmitted with= it are confidential and intended solely for the use of the individual or e= ntity to whom they are addressed. If you have received this email in error = please notify the system manager. This message contains confidential inform= ation and is intended only for the individual named. If you are not the nam= ed addressee you should not disseminate, distribute or copy this e-mail. Pl= ease notify the sender immediately by e-mail if you have received this e-ma= il by mistake and delete this e-mail from your system. If you are not the i= ntended recipient you are notified that disclosing, copying, distributing o= r taking any action in reliance on the contents of this information is stri= ctly prohibited.




    <= /div>
    This email= and any files transmitted with it are confidential and intended solely for= the use of the individual or entity to whom they are addressed. If you hav= e received this email in error please notify the system manager. This messa= ge contains confidential information and is intended only for the individua= l named. If you are not the named addressee you should not disseminate, dis= tribute or copy this e-mail. Please notify the sender immediately by e-mail= if you have received this e-mail by mistake and delete this e-mail from yo= ur system. If you are not the intended recipient you are notified that disc= losing, copying, distributing or taking any action in reliance on the conte= nts of this information is strictly prohibited.
    --Apple-Mail=_824AB518-AC77-4F18-940C-45C0CEF0DF9F-- --Apple-Mail=_E7B31ABE-9022-4D45-879B-D1461CC62007 Content-Transfer-Encoding: base64 Content-Disposition: inline; filename=PastedGraphic-4.tiff Content-Type: image/tiff; name="PastedGraphic-4.tiff" Content-Id: TU0AKgAAIpyAIGBACCQWDQeEQmFQuGQ2HQ+IQYynY7BIqqJRAAcBURCAYicPD9vOp0gB3vZ7gB+v 5/A0WBULFcDgQBhx8P1+g6cP2Fv+CggCAQAB0KBMAOZ2u5uKBmNE8EYUiQPBoFA0ACYPBujul0tZ UtlqstVFUqgBBWd3RG1Wu2W23W2BIG33O6XQ/XcCKdvOMQutxuQdAcHgwauR0uwJBsHg4oPB8Sl+ P1/gkK5UAPd9voAP4AAEAOWuABVM9pJ4bh0Nj8SBgLCMAZGCz5/z4AAPbQQBAIAPV+PwAO14vJ4O F3vFsEEXiwcAYBZ4Hg0HAB8PV6697PV8BEGAt/ut4PJiAiZtoTBYLgBwu12qsXhkKuZgqRSNu6/X 7feCXH8fu6vIdB8GALgMAwuASAwDh4ALPBsfKWACA4EgU356OqeZ5nkAACgEAYAHge6UnwfR9gAm cOQ03QGAQBAAAbFqTHlDChJ8BcBgA2gAAUBIEgAdh4niZJknEcphnYep7AAFQLgsDQgBUE4tHhHy VJYABuKSZJznieZ9MUBoegCoLOgIAoAPEA8yzCfrHxIzx/HynxZg2BYFHWebZk4PYgB2d5DLObT+ UA+79UDQiCg4I4lh0dR7nyJwDgOAwfNmf4cn+255nwfAAS0elNnvTR9N6zqCnyfrfH82YAAJDcbV Sex9xGe0RM3VMFIJVNaJ9VEboI20OH23rM1MfIFALMgHRUAQIgVZgEgKoQENuap0HSXNIAKeoeA+ DolwPR5tHSdZlgbAYWn4lgEVKnl1IIA0V1W3R/n5EYIWe7MWl0FILAkVwohQExTrOQTNULgqEUHg y6H8HAfCWB4FAQOoDxUH56H2nh3HtI53HgeEO0+AB81EfScNqALdHofTNZInlJ5DUSCM8ADm1yzc qARHQAQHM7ms9nuZ1tWzpQ/VuY5plyWJ8yKeALR7OtyAAEgWBeZ6gekLNefNNH9lQAArFwKRzNCh AHmjdM8x1QSpBrOQjqgDtuBIBgCaQc22YgxBgFhKYEa+E0BhG/ocf4eCCJAGAKAw6n7sohHlWcon i6VYVGgh8VEeUQpNojMRHXbatulbOANCIAAZnJ/Xmgh9Hzr2pgADIIggo53HeaB2pQbIOsWAAMAc BgABACXZgddx/l4bhtk+bJ1nWd61C8GYZCr34Gg8cB1HUAB0HpTpvHZ54IASBAYx0BQTG40J8gFG Tb6ueedVtYsObhDmRJ4fZ/J5mNVRVHD43gnbHmD0EQIRRhbBYCcSbAhsOCLe4GBwAAVhWCwEocA7 h4hzH2T4ISWzNPvAAAtYxnWZD0HyZobztQADyHy60esJ2nm6J4Z4CYEQIkEa0UMCADx9D2MeMAFo HgPDhAmqsbYy1qCzC6CsFQAAgAmBEQYcDAlNQRLYXcPwDyCgZDeLQXgAAUgTAeFIbY8x6AgH4pkJ o5x5j1AmhgAK2HKD2e6bVVLczPEzKEyJEY9CVgAA0TAAAMAIgOHSFIFwKA6i5E6J0UcViIQQUCFQ MoZQPjSHUO4Tw6VgBCHGcFGzRANgNeAPxVI2h1jtABCl548VMsxM8P9k4AIaw3Ae2UAAHnTjsAoB ECYqQQgJAOLkKIMwXDREUWccUkJmFviwBUYA4x1gOkyOoL4vxwDhAsZkfgVh1QnAiPRKgB39IsWe SqP46kKAAnEZwGwJQSAABrIURYZAbAyD4wJgkzQASSPuDaCgXhyD2HyJIcBKAHjyHYOxhYHgOQ+J YAwYg3hwgAGquEACoTfQkTKnMAAEEagjAgA0dIKQOAdFUD0DgGhgAuAuBMYDAi0z8ppFaLAExfDe HAEUYo5R0A/GwOYdAUR2wnPOrYARmVVK2HhDABTrwZgZAsNQKAKwUCSBqBkC4pGBEpcFP6K5dwDC cGWNILg8x+j7E6OVzROh+jMB4VkYAyRzDnCwLYa42wODzHukcmiJmcgehsAAElIxjgXQiJANwOwa i2YEp2mtkbJEOiwAwQowBhhOHaowOY5DsAyHXOupJmgEM0H4mMAAF4dgAAkc0agRAPghDCM4WAqB mMGrAQ+LAChejdHCLEaMbQiDiHOOcf4LyiidAaxAAophojUCcN8dg7gIgCVQZ2c4GgJASSQBIB4y ghAhA8I0ZAqBTCqsnem9RdYsACGDNkKgqBojXCKOlIwWh3qwAUAR1QCjbnVIIBAoI/wnguBUKcLo LgVh0YEOc/FuSFRYAaL2igrhn3CG3NkbQVwWApF8Mccg5gZC4GyNwGw92uj/j/L67gKJSDqBkBoC 4bxyC3FmKi9eOcdMFBsFwLgLhdDaHCG4b5SQtDuREAkBo/zOIbN0AUBx0QOrPGgHMHYOgzifEmI4 ZRdcIEJBqFYLIrBqMkCmNMbI2hohUBYCYYgps0BBG8O8eAKh/yvH8AMoQJgNgaAADKl4ng6g6Bsn 0s43SHBpCGEsGAFQNgcAuO1q5nEwlvo2AVxCqpzj3He/ACcQiCPFGqwIc2O9TFvCOGEMoRxjDlHM IkX43xxAvHYx0AAIQHFWHiqkEV2wABbBaCYNIuRPifEwW7L5BAWhQCsF4aQ8h4icHAOsdg0gZgVA oNUX6QgtSfHkUJ1jM2cAABQBMCA8FtAdDIObGwrS1BhB+EsFI2xKipGkPwcY5iaABAMdLcKCmZER N8ZoC0TIQgfAwAAb4tRetRAOVYdddRzgPkCOACAKgRi1B2JsP4mmBDrPwFQEIMgcjaEIJsSI7Bzj lKsPgf7KjMj1Q4bohxPB9KsAKA+OJNDXj+HwAoDgFh8AfB4DMfg8dqC2BYFcJA2AQBkCmL9gUqi7 ViFkNocAWBhDeG8JYZI5RzgLA+xBGz7DagGTIFwFYJg1XlFMJctVuQf4+BaNIdo8hpDhHYO0foJg IgPF0K4aw2QhjqSMjVXqBwABIBQCQeAWwVAlCaKQS4lxiFuDb5kBgzQrB4BMMAXgmh+BEDAH0Pg5 BTi5CrU2VRukOEORG60DQKgZAAAcCUDoABsCxFebVMvv9+tkTKA1HYEgZgtHICsPoYg+CdGILsUJ dQqAQBkBEbwlRMpJCwEcL49RtjkB8OgV4vwTtadabgg7SoQ1aIIBEBovmgDvAInMFoCKCAmHcNOB qIyfATBKBCRsAqAcHEAcBQBEEuCAE6EEEyYEee6qD8BIEOGCGMEsGWHcHkCKA49eNyN0JSM8CAq0 BwG2FqFgGSIcggiwAWFGGeGmF2GKHGHKBkB4A2AyH+FmG2G+AQXAJKbkQ45cJ8BoocH0EkCOCCCE EVCQGKYMCgAgBCCcG8EaFQFiHOHEHAZmVUIeRGOqBSB8CCAAAoBcBMAAGMEoEyVGQkM84CVuM2Z1 DYAsBwBmSQDUC0BaFIG+GUGoUCCOH0AkDQHOE4FkEuWo1KM89eRshCcSAABGDUCsFyF2AkHwCQIM iwAOHwGSGsBQGWFEFck2FUF2BkHOHYHKaiRIdMAei0AwCGB0L4DOCmDUFCGQF2FovYLuAWzgGuEG EyGMGUDgBuW2ACBMAy4SAAVgG8HIe4BwAEGcF65AISggCGC8C+DIGG7uE2H2HcHcHAGoHUHWAIG2 HaHeA4WiM8fuAAA2Aw4SCiBEA8EkHGxsDegcCSH8AoCyHIE6FmFMHQHImWN0KEIU/UAYA2AuH0BS DOCuE8AkBWBIHWGcEKE0DIHaGcGtBrCuIYJ8QkN0AcB2BgFECeGIFADEYEf2PsCCHaAODmHWFOF2 EZG4HQVHEMJ8eKaoBQD6DGFWFmH8HMCssoLuAsGgEEE2FyGsEYE6BgU4crFKIIAqmMHyA2DMCiCm FmHQGuFqPwHsBsB4C4GWHOHUE+CLHWHSCyBmBeGGHcQuGSFmE2E2EgIUP0sqEsGKGUGkHIU+BCA2 AYQkE6GUGcfiTaVSAgAoAoAACExkFaH0GEF6ComZHlHpHtHxH1H5CwIRIuAETIBEDKCkF0F6A0H6 COIMDCB4CODeGgDGEIEgHGHA0QRMJ6ZCAAAsBmBgH6B6E8EEBOEutq0QPvJLJPJTJXJbJeNiRYAM QkBMDyC+FcFsAEHWCmLUiwAsF0CSDYGQHGFwGABCN8Q4Nk98M0BACCB+HwBoEoDmCCEmFYFQGQPw A6CSCaEsF0HUHeDSBkbkDuDqCEB+48LOY9GcIGCaDGDKDWFkG+HGEoAsbmAAF4G2G84UY4RI54H2 lmCKBMBGHOEOCKB+CEgZMXHnHrHvHzH3CvH8IStKN0BGDQCqGGF8AuH4B9M/NCD6GcDCLOHMHEG/ CuTIIUliNqbEAMH8AKA+G+DyCMmXN1JNJRJVJYHXJdELOCXJOJONOROVOYLaCWAaA+DYHCEQFIEm HSHU1LH7EOM4AaAG36AiCUB2FwGYBoAoCSPwiwAiDyF6GEFYk+HqBsCwBQBOBIGcFYFIJLP2LkAg CGCMEuHjMqDQAOhyFONITKhGYuJ4BGA6A4AADOgSDSGIvM2OppMZQ5MfQ/S+IUM4RGAwBCiiAoCW B2DuAEUgF+HoGQ20HAGKGSapMkIfTCAWOiBgEUDcDqFYHYGyEYPxN3SNN9STOBDXSaKvSfOTOWLc D88yAaFSBkC2GSHqHAHIBSRHDVEON8AoA0A4H6BCDUCuB6FqH6HIGOPwCWx8BIE4GyHAG2AKHyHu EgAoGkGaDiIUHcNmAaEyF8GGGajiAMBEG+eyAGGOHEHIRwhGH+tQCOBFR+ECCMCABaYEwAn5U3Md Q9MjRCIYeAQ4AqCeB8FQAMAcAUFoHeFeGIFIe4LS9cIe4CQGAMH+BWDeC0CeFuAYHmFnWDSLN7SR SU99WPOHWTOPWXSkLmByGoHmF+HOFWF6CAJTJHDWJ8AYTCA+DGCkFsF+A0H8CWUCHk5IE8HybKCy EeCSB+BWT6ENQUIKG6HMHuAoE6GiGMHWAMKCGcomHABWhYHyTOVsu8AeH8CwScDSHDBIE0vTYxQ7 MhRAIbaoAOQkBQD2DED0A0CEBmF+GICoDwF6HcHQHOQlaDccNeAAAfUidgCKB0BCGEA+ADCtSJN5 SPN/SXaFSdaLSiLqBoGOHODOHaF2GWEwHsrSIW36IIAZDCGwGuCmBaBSUCBCCWCgB8GWzoGCAMHw HsBqAcGcGUtuIKF2HcG6AWFoGEeYBRGEASFCGUGaVa/UIIBWAtMEEQCeCSA2E3CQ1KsncVU7Y2IX VCd6BIniBGDaCqBaFgHgG+GoBCEyGCG2H2HMHYBIRGIgN0RGAkBgBaHACmGeFSByYFJddhWHZ/WN EPWROLdvWYLoBwGaHaCKHiGOGoF0HaHWJLdoIKM4M0A6BcBeHuCIF8E0CYEUEqEg/gPusqCaFCFS GMe+HbXEHqHY8uIKFuGqGqB0GMHQHcGEAgPEAGFLL2Qy54H8TCBUdkGgFACuChQwLPAcslf1Y1cb RxdIAqwUHKCiGaFMCEVUAIHGF8C0DyGsG6FOFiBAM5RuISM4J4AsAWhuAwDMCeE6F6AgHsDIUDWF Z9dndEJ9hLWVdwLoCg7ECYG6EsFbKkG8G5RsIOXWAAA+BUBagkEEDWCuFEGqGEvQUAHmBkBuGiF+ ooDgGYDcDNCUIIH2FaGiGqEAF2HGHODktae2F2ooBKAGyYVUAYeAH8SME0COHaHIDOx1jbcZU+IS 4CH+TIHmA6CEB0HdZIAWAIHOGKGcAuHqHMHUAJhranCwRGAmBkBiHOCKFWESB+EcFIE+PoUBkrdl WLhrkzaHhNShhQLmCgASA9lAEvlGHQG+0QyeIPf8AuA7AAA6DGCWCmFuACHYFcUCBuCuC0EQGy72 FqCOBMBIDqWeAEDSFQGcGiDSF/nkEgAw7QHwFoGwG0AcAKVsHwuuCCBCA6HqEcCaCQBSYEHHcTQ3 Yzm/VoIYM4U0A0BcBgNqQMlWGSGGQyhDEOJ8KEM836N0BICWCI1uDoC0DOE6GEFvcQYLoNWJaBJh OFdtobaOLfohokG7opKlovlOINf8AwA+iiA8DOCgCmFrgdpMYKDax8AsFsHgHqF4CU8iCSBEEAEA AsBoBGBWHEBbBoAOFeGlDyAMNug2J8BQAoAkH6D0CQCEA4FYEmEng/jZqncXU9qsIXlSAsBeBctT HWAAHSGUGg98KEAKmEN2H6H0HiA2B8BoGmBLlgEeEyFuFdsib/rthFoTr1aJr4LqClk+G3lFlJlN oyIMN8daBIBeBiAABYEgDkCzriFuxwYKBWCakpK2HMCIEQCUCICwDcFmFmAiHSQ8HMBMAwAuAQF4 zSVoVuVSX2AkH8DaBqBiDEvKFI+jfzt5f3jeIaM4daAq4MBYDgC6DwHmHAHPYSSoA5IUdgB8B4GO EEE+EdbYn5u/kvrzk1hPr6LcCGHOAGCWHOFkGEFoHYHNYSM9Y498M4AcW2HECsGwFcB4EFCRqiYK AKB6CCF3bsAIHeHqF+F2CsUmAoDaFgFqHQAWZwAGGSHCmWxRgkIKATFOAACNBoFYH2GKF+LLxBMb t7f4cGozC+BXeaCGFUEYA5PKFJFGIaBKE4GOBzH8AGBmD4DEGlZWGuQxrrZ7oPrxSZoXk3ocLeBC EwGGCOAE06FwHpeuILW036M4AwCWB+GmGWBsAtuIYKCOC4DKBeFhlKGcBghqCaGyFnOQUmAKDqFo F0FgH2QGCUHQ2oAAlQlURKZCSoBwBAA8H0EsCcCQBmYFDzU1xDjdnBIt0OAp0SAABuEQDcBYE+Gc GEGqIUC4BsB8BYGmDeEiGmAGZEAABED0DEB+FYHQGmGEYNx7oRkxvFoZaMLqB0GwHuE6HO9SDESP alDYJ4AoAgu4BADgC4EBpGHQLkUAiwASEFcyF4HmhaAyEWCQCH3JjUP0A/PWDWGMfAEoAQH2daGG G8mX20c+AaAgdmCuBKBEFUDLDgCyYEM4khm9t9yhH/3Z3d3h3l3p3sIUDCBsB+BUGQDcEaGr4CN9 ckDCB74QGvigUL4b1HdrvH4kLaiwAoFwCQDSGQHKFyGIBGN85p1l0OAuBsBoHOCeGSFHqeLOckUA AsCGCODaGgOwElcHDEBeAkAiC2EmEYEUFNLcLuAeC2FKzIA6AsAqA4GiHFqiSKr8agcuN8BiBINc C8BMBCDGGEvME9Q10HxF3VNYM13beb6z3n3r3uIT697AGP7H7L4EBSD37T7X7aUJ7fhHoVr37mLY CwA+BgCCGyEKE+F8HGG2gaQ436N8U1gAiaA2DmC0D4FcHUGuELkoC8C8C4EurKFABTwcAGBeIAEw g5Hy93oMmutVq60DDQBD4e8BkODY9QGBEmDH6+wAv243wABouAACAYe/AEAgALAwF3KZBYKSYvVQ pGhEJxOZ1O55OyS/goWXInVmpnQ5HEAJUBJ7OH+AH0AAoKxSABuiDcLE+zmE1Z4YRsPxUxzcjWqB Hy/QAOVMhxYGR2Lm0714zQSAHe7wAESqRH4gsA9qbTSC7QOc3Wp12jHU63RJAAA4hTwaBgUABMej CrlsAXSU8HOT9owsvyqdVk3VYthvaqZanyAAsFQwABCaCsthmgjUWMAgnnoeFECCXi+XFAz2qo30 /H4ACWMBaAALBTa1VcrEpOIagdFowcZlctGqEQcDg47LyAGe5XOAAOBKY//pDwOCAAPxCHnUeB6F wkEmRRJme4cDJ2JZ/gwKRxk4WBWnOchwqUACmNCp6ogoFgVKsQQ2hIT5pmEbqvrCFRjLKap/nuqI NiaHpPnMYJlNaeJ7hAf5+o2CAVBCeAPiQHpLFce5wkVA4hnkBo5nSUZbMYdT3pMySHqeBzLAAFBA DIVZZn2cwrNC0Y/AsZo/kuXJvEuVIYMadMKH8AAPA+EYAAwLQlN0Qw2Cm358QO0IPCSKAuF8cRxF GeR7nuAAfBGEQAASAR/mgNIbhoH7fnk7iHJ4FIpCoMBWGsbZOBQCIHgGaZzzebx2r0BQCtef84gG BLLh0DoNHUJoQhKJJglQrdAJ3MYJogCBfDCPgmnSVpfEeeB5ngyEqMGp7YgoFCqiOWJIiSBwTBAb DfnAnCwLEZA6kkap2GoawAA4CgNgAfFYgAfJ/H4cp/H2foMgEdJ1gECgRBCAALjQKJLlme5xjU0I eG0fQ0HeWpiEudZ4HZarJgABQBALj4YBIXIjlORg1AYEwOgAaRLFOAB3Gaa4eHwbhzDmdhjmgFx6 H2eIAAcA4IgABAXUgEIliEPwYj+MxGN/RliO+PwFkiY5mEGWRqmuOAGAQBAAhyDwOaEBQFgAEQDA YGhlFgUhmp47rhAeIIileaJ5nsKAUgU/BjHCcYAG+dy9ASAuRH9xaSASu4RgaBp1CKEIOi8cRclq XMDhCThhhICoVBKZoKAwCwHHUaZtAAeRuwmksLQMp61AKBO0guHIXAAf+RQqDoMlWHJFjkLBvFeY ASGaPhJGyepuG8AASCuJhdhGNYrEKDIbhcYhzloYIWGsSpWEYcxcGAIgJBsGJ8iWZJRBaWgpDOAA JAWC5Dncc7HnSZJogsAQz8E5z04k8KfAd3ZUgZAsaMQJ1g3Ckj9HMxwAQ/E4gEA+BUyIFQHjlA+E cHwzARBdCeJARwphNjAaoT1MYCQ/i9GELEZo7x5hFAMPcwQM1dIVAMAYAAGgDgHDUN8WosBLmhbo mI0YFQ+i8GCLEdA+R+A5BkeYAAvHngAHCO9oIBQBkqPoU8lBkgTgZNqDt34kg1A1BiIo345SeAyG WOUCo+xwDtCOPIdY7R9gMAqBMf4BwLARgLCsh6/SODzHAOcyQ+B9ABBMGsKoBgah/DUKMbwtBgAn GYHIRw1wCD6TiDUUofQaifF6LkZhPA5BlDSDQXAPQxjGAKPQfABQRh6C6EYdo5hujqAKOIfYqx4j xWoP85w9x/kXHqSokyFwAD+gqPUe4Ah+j6I4BIETLQBgTAcPEborheCcCAIQN4/QPhgCcMM36b5D FNB+FgMIKhVDXGoI8cA9x8hGAcP054JALgWAAP0ARkh5j0HmGoCo0BlRHQNElAwbaJAQD+MUZYth /AFAMDkEgCgDgAGgOZN40BznvPiyIlRD5RJxAoBNY4LAIAOHEDoD4HQ0nYFULad9O6droLGikAg+ 04goEEGgGYrBvjOGcTxMYDhVAwCoOgAI3B0AJAiEYGwUBjAwAgLGnlX6wKAhaJ0Zo0BIi/G6OILo 8B9j7AQBQAhKgLgPAeABqa+B6j2DSBsaozhMQrogsQJYXAuAQF2OQdItRxD2HwDoDwBmRDpHqPQA Ax3BFKACSofqtJoj9gLRoAAHQIgQJWBYCYvgkgmBCIwXYnxPi3rDbEnNPhjhwEcNUAI7jggrD8GU MQrB3DbE+TwLgHgaBtk6IoSACSBACBkJ4PYUBOi/FvV62V16eJjAQKAZozwwDCHAOQNw6R8j7BSP 8fRsQLNhaFXR3czwCj6H0GoCFDKHTvsDIZMYEhQjPGmLQYw6B1g5AoAEp5IjJDHHEORfBzqBuMHw Ps55aiHgIbQAAEcDgaAZAuLwGYHwNhkF6JsTaE7sQrp8MgOQjxqjrGuNIAAEwPAnKADsF4rSngAF uAOyANR2jFGcFoe43BwAPA6FwKA3wgCjEKDBTWJ8oGDhaJQYYxwuDYHcPAOA35qAqHePUeuMQCGS AsAwBhUHEnwJSNYIYGwMiMG3EW4dYb83ZNGBIWo2xuyaHOOwHNJRzYYtGAAeI+DYuFL0PjBw9psL 1wcPw+oDHIsIAOAYdwLAOAbE6F4GYLRhCkEcI4WmUSmhpB+EsFo1hACbGkPcdQ7a7APAOfQag4gA gO0mPcd6mx9Q+fqEAGg5wVB9DKFwTItRWC+1JssAAejRguFWNUbIbRiDfHEEUbjhgPjrHpmEBNnA PUxAA5EBruyRgnAeA0ZoYwaAvCagIRR77sZ1rDfsW42xviAGSOQcwbRujvWoBEAZJsy5nHVt0AA6 R6WURsbEeo+yoyOI4P4AZkgIAPtIBsBhl20gAF8BzdIuVxAbFMFUEQIh5m/aDvUMoZQKjhGONYNo B1blSCCDUVgxA1iEB0OwX4ywNwEAACoLwUR6AuEAGYTpv2ObMrAmMCgtBsDaCSL8cA5Qfjt4WFux Y9wEDtmK0I+UPwG5nAREE6mZiSD5HwNoIAIgQCGC2C4FQqDfmx1JvTKINgsBcCiXMeAfx0YSBeOM ckcAL8baN2MdHCEbJ/qEnEeg+So+TNiWl2jjgAAQAW2kA8/h6AoAoBIeB5gHCrA2AoBQswvgzBcN 035SenezuumMDItnnhBGeOgdgQhxjpHUFUcY9h7gOHfo0e9kypXsAx2UkMPV68VQrhIeoOQRAfFF UYFwiTf4m9oQ/vWzAuUSAwLwb45A4jzraHYdvxAAZnTiAf6X7VGDy0M6z+48x8mx0Uc9fxOIeq+Q AA54kzSAp6P4CR3YewwQEBVCbBHQWwGADQDIdIeAfAe4T4OgIgIAeLM4AAcBPz767BMYFAQIXiFQ DY84LoYwcodADIfUC4KSPgfoB4ew+oeAeBoLWRkQCYBAu4CABjjrsaggyTz4foegEACYCQUQNQHQ GYSgSYQwQwa8EQpr8MKoAAHALgLwJBVYdQOoe6zwIQpQlQBAfwtQBLMYAECw2Id79wdz9zQpP6Cw tSCxbDBweryi94lSlZj7zpSL6AfqHDDACoCiu0C4aBoYBIbKjhg4bwdAdIVwdQeofAb4GYDSDQEQ Cpor/qK4bzQIZAbx1bBwAAF6HYDIBLcpKoAAdYfhP4aIcTQIKYqgHQCa0YHIZwb5cwcweQeYCYCp yIIgbodrWAfIkYtQkyhA4JK5kQBUNQCa9xsKj4kglQeoeRRQBDioaIEIDYDAToPoHYG4Yw35eELC h5Tscw4YCQIYI4JYcMXoOge5OIICaQlQCwA5kS9Y/CLwlQdIebMIcjsIcMHIAD/4AEAIqLHInKMI nIksPifw6g+5SK9jMcPj/ZSL6QBrSo+DschgeAe5P8CxP8hgBkjYkR2KMQfwp7yYqIAjNKjRkSzx OK8ojiyayhsEfYko+EjYCwCC0ifw54CT1UVgd4dwbID6lwcwAjs4VIIwDwDIY7T4UjGEdKr8K8qo 0IGgKwLQJgY4cYcYMocAdweIHRyIBgCgDTi794iB2IcoeJTYZwcrQL/QqI5o54AUnQBBWTB6A4+o e7BxxYp8nQh8nSuIyUlROKCxOI+onKL4kyuIlQAzsaZ6aI+slQp8vCZ6zMAcM4qDB0Hwy4BCyBj7 NLWZOIDzQb4gfAaJtABQaMMwfwZQC42gaIOZ7YaI344MrDvMdE3ar5MYDoSgZYaQGzbgeYKKa4fI JgBSHrjEnz976AcYdQdQAEtxTYfEzcM7CbCTxYyQAwlIkL6Rn4jhHQfwfUj4fAf7yIA8jUmMlUhY iEyiL4lUxx3bHKzYp4e6toe7+wfAeYB69gDYCUBJjQeAZIDIB6b4GoEADwA4cAdgdYWYGYEoEwdQ Exv4GK0wCIakDwZw37QM3z78q9ELeo0YDoPEE4B4FsJQMD44fQCoDRtAKpv7mgax/YWweTygEwfy zIDcOAewBIDQC4C7NQlQCMIJoTiAdTCIfgeYAzSoEZHItUfyygeytp+oBI/EAwAAeb+7BEwgh4Bs P7hYeoaikgdIY0oQBIBgFUCYAAdoeYeIbIC5yIDgFIDgDgEoa7fgXAc4eYebPxXUCQC4DIV4fgfY e4a4VgSYSbeVEjp1EdR72gKgOwO0BJRgDYFQCIBCOAh4ewYofBewcQbQbRDjCwGoYwbAbgAAblCB RoEAEAMC0YCAFwdMYjQj/NUMMiMExgyAlIk0hgkwk1ACj4ECMwAD3gdgZQab4AWQGoDwDxhBsIe4 TwYgY4VwM4JIIAfob4VgVhwdSVcIh4gIAAASAQAAAwAAAAEAVAAAAQEAAwAAAAEAMgAAAQIAAwAA AAQAACN6AQMAAwAAAAEABQAAAQYAAwAAAAEAAgAAAREABAAAAAEAAAAIARIAAwAAAAEAAQAAARUA AwAAAAEABAAAARYAAwAAAAEAMgAAARcABAAAAAEAACKTARoABQAAAAEAACOCARsABQAAAAEAACOK ARwAAwAAAAEAAQAAASgAAwAAAAEAAgAAAT0AAwAAAAEAAgAAAVIAAwAAAAEAAgAAAVMAAwAAAAQA ACOSh3MABwAADEgAACOaAAAAAAAIAAgACAAIYAAAAAEAAABgAo+AAQAAAAABAAEAAQABAAAMSExp bm8CEAAAbW50clJHQiBYWVogB84AAgAJAAYAMQAAYWNzcE1TRlQAAAAASUVDIHNSR0IAAAAAAAAA AAAAAAAAAPbWAAEAAAAA0y1IUCAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAARY3BydAAAAVAAAAAzZGVzYwAAAYQAAABsd3RwdAAAAfAAAAAUYmtwdAAAAgQA AAAUclhZWgAAAhgAAAAUZ1hZWgAAAiwAAAAUYlhZWgAAAkAAAAAUZG1uZAAAAlQAAABwZG1kZAAA AsQAAACIdnVlZAAAA0wAAACGdmlldwAAA9QAAAAkbHVtaQAAA/gAAAAUbWVhcwAABAwAAAAkdGVj aAAABDAAAAAMclRSQwAABDwAAAgMZ1RSQwAABDwAAAgMYlRSQwAABDwAAAgMdGV4dAAAAABDb3B5 cmlnaHQgKGMpIDE5OTggSGV3bGV0dC1QYWNrYXJkIENvbXBhbnkAAGRlc2MAAAAAAAAAEnNSR0Ig SUVDNjE5NjYtMi4xAAAAAAAAAAAAAAASc1JHQiBJRUM2MTk2Ni0yLjEAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFhZWiAAAAAAAADzUQABAAAAARbMWFla IAAAAAAAAAAAAAAAAAAAAABYWVogAAAAAAAAb6IAADj1AAADkFhZWiAAAAAAAABimQAAt4UAABja WFlaIAAAAAAAACSgAAAPhAAAts9kZXNjAAAAAAAAABZJRUMgaHR0cDovL3d3dy5pZWMuY2gAAAAA AAAAAAAAABZJRUMgaHR0cDovL3d3dy5pZWMuY2gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAZGVzYwAAAAAAAAAuSUVDIDYxOTY2LTIuMSBEZWZhdWx0IFJHQiBj b2xvdXIgc3BhY2UgLSBzUkdCAAAAAAAAAAAAAAAuSUVDIDYxOTY2LTIuMSBEZWZhdWx0IFJHQiBj b2xvdXIgc3BhY2UgLSBzUkdCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGRlc2MAAAAAAAAALFJlZmVy ZW5jZSBWaWV3aW5nIENvbmRpdGlvbiBpbiBJRUM2MTk2Ni0yLjEAAAAAAAAAAAAAACxSZWZlcmVu Y2UgVmlld2luZyBDb25kaXRpb24gaW4gSUVDNjE5NjYtMi4xAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAB2aWV3AAAAAAATpP4AFF8uABDPFAAD7cwABBMLAANcngAAAAFYWVogAAAAAABMCVYAUAAA AFcf521lYXMAAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAKPAAAAAnNpZyAAAAAAQ1JUIGN1cnYA AAAAAAAEAAAAAAUACgAPABQAGQAeACMAKAAtADIANwA7AEAARQBKAE8AVABZAF4AYwBoAG0AcgB3 AHwAgQCGAIsAkACVAJoAnwCkAKkArgCyALcAvADBAMYAywDQANUA2wDgAOUA6wDwAPYA+wEBAQcB DQETARkBHwElASsBMgE4AT4BRQFMAVIBWQFgAWcBbgF1AXwBgwGLAZIBmgGhAakBsQG5AcEByQHR AdkB4QHpAfIB+gIDAgwCFAIdAiYCLwI4AkECSwJUAl0CZwJxAnoChAKOApgCogKsArYCwQLLAtUC 4ALrAvUDAAMLAxYDIQMtAzgDQwNPA1oDZgNyA34DigOWA6IDrgO6A8cD0wPgA+wD+QQGBBMEIAQt BDsESARVBGMEcQR+BIwEmgSoBLYExATTBOEE8AT+BQ0FHAUrBToFSQVYBWcFdwWGBZYFpgW1BcUF 1QXlBfYGBgYWBicGNwZIBlkGagZ7BowGnQavBsAG0QbjBvUHBwcZBysHPQdPB2EHdAeGB5kHrAe/ B9IH5Qf4CAsIHwgyCEYIWghuCIIIlgiqCL4I0gjnCPsJEAklCToJTwlkCXkJjwmkCboJzwnlCfsK EQonCj0KVApqCoEKmAquCsUK3ArzCwsLIgs5C1ELaQuAC5gLsAvIC+EL+QwSDCoMQwxcDHUMjgyn DMAM2QzzDQ0NJg1ADVoNdA2ODakNww3eDfgOEw4uDkkOZA5/DpsOtg7SDu4PCQ8lD0EPXg96D5YP sw/PD+wQCRAmEEMQYRB+EJsQuRDXEPURExExEU8RbRGMEaoRyRHoEgcSJhJFEmQShBKjEsMS4xMD EyMTQxNjE4MTpBPFE+UUBhQnFEkUahSLFK0UzhTwFRIVNBVWFXgVmxW9FeAWAxYmFkkWbBaPFrIW 1hb6Fx0XQRdlF4kXrhfSF/cYGxhAGGUYihivGNUY+hkgGUUZaxmRGbcZ3RoEGioaURp3Gp4axRrs GxQbOxtjG4obshvaHAIcKhxSHHscoxzMHPUdHh1HHXAdmR3DHeweFh5AHmoelB6+HukfEx8+H2kf lB+/H+ogFSBBIGwgmCDEIPAhHCFIIXUhoSHOIfsiJyJVIoIiryLdIwojOCNmI5QjwiPwJB8kTSR8 JKsk2iUJJTglaCWXJccl9yYnJlcmhya3JugnGCdJJ3onqyfcKA0oPyhxKKIo1CkGKTgpaymdKdAq Aio1KmgqmyrPKwIrNitpK50r0SwFLDksbiyiLNctDC1BLXYtqy3hLhYuTC6CLrcu7i8kL1ovkS/H L/4wNTBsMKQw2zESMUoxgjG6MfIyKjJjMpsy1DMNM0YzfzO4M/E0KzRlNJ402DUTNU01hzXCNf02 NzZyNq426TckN2A3nDfXOBQ4UDiMOMg5BTlCOX85vDn5OjY6dDqyOu87LTtrO6o76DwnPGU8pDzj PSI9YT2hPeA+ID5gPqA+4D8hP2E/oj/iQCNAZECmQOdBKUFqQaxB7kIwQnJCtUL3QzpDfUPARANE R0SKRM5FEkVVRZpF3kYiRmdGq0bwRzVHe0fASAVIS0iRSNdJHUljSalJ8Eo3Sn1KxEsMS1NLmkvi TCpMcky6TQJNSk2TTdxOJU5uTrdPAE9JT5NP3VAnUHFQu1EGUVBRm1HmUjFSfFLHUxNTX1OqU/ZU QlSPVNtVKFV1VcJWD1ZcVqlW91dEV5JX4FgvWH1Yy1kaWWlZuFoHWlZaplr1W0VblVvlXDVchlzW XSddeF3JXhpebF69Xw9fYV+zYAVgV2CqYPxhT2GiYfViSWKcYvBjQ2OXY+tkQGSUZOllPWWSZedm PWaSZuhnPWeTZ+loP2iWaOxpQ2maafFqSGqfavdrT2una/9sV2yvbQhtYG25bhJua27Ebx5veG/R cCtwhnDgcTpxlXHwcktypnMBc11zuHQUdHB0zHUodYV14XY+dpt2+HdWd7N4EXhueMx5KnmJeed6 RnqlewR7Y3vCfCF8gXzhfUF9oX4BfmJ+wn8jf4R/5YBHgKiBCoFrgc2CMIKSgvSDV4O6hB2EgITj hUeFq4YOhnKG14c7h5+IBIhpiM6JM4mZif6KZIrKizCLlov8jGOMyo0xjZiN/45mjs6PNo+ekAaQ bpDWkT+RqJIRknqS45NNk7aUIJSKlPSVX5XJljSWn5cKl3WX4JhMmLiZJJmQmfyaaJrVm0Kbr5wc nImc951kndKeQJ6unx2fi5/6oGmg2KFHobaiJqKWowajdqPmpFakx6U4pammGqaLpv2nbqfgqFKo xKk3qamqHKqPqwKrdavprFys0K1ErbiuLa6hrxavi7AAsHWw6rFgsdayS7LCszizrrQltJy1E7WK tgG2ebbwt2i34LhZuNG5SrnCuju6tbsuu6e8IbybvRW9j74KvoS+/796v/XAcMDswWfB48JfwtvD WMPUxFHEzsVLxcjGRsbDx0HHv8g9yLzJOsm5yjjKt8s2y7bMNcy1zTXNtc42zrbPN8+40DnQutE8 0b7SP9LB00TTxtRJ1MvVTtXR1lXW2Ndc1+DYZNjo2WzZ8dp22vvbgNwF3IrdEN2W3hzeot8p36/g NuC94UThzOJT4tvjY+Pr5HPk/OWE5g3mlucf56noMui86Ubp0Opb6uXrcOv77IbtEe2c7ijutO9A 78zwWPDl8XLx//KM8xnzp/Q09ML1UPXe9m32+/eK+Bn4qPk4+cf6V/rn+3f8B/yY/Sn9uv5L/tz/ bf// --Apple-Mail=_E7B31ABE-9022-4D45-879B-D1461CC62007-- --089e013c6ee6e38961052abafe91 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----- Version: GnuPG/MacGPG2 v2.0.28 Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJWr7wFAAoJEOC76zanEdQWSp8P/Ahaw+CUYfvJrxDBR4yol73S D5NHqwXyUyWMF7/cedzNNbUE1aw63k8zbW64gNUtYhoZrSSMtiD12xZrJ4oG1p+n zrgR+ghwrJX3PD8V6Jp4WnCuR2AfOr6QsaOP/AIFFIXEyfNTu65RI1PXy1Z9j1Ai LpulqpObTdNkoqeUl/ljnMVs5Gu2tyozKMy6qNw3y73dNES75b0MHe7bcIAjw+NF Oy+R/nqBtSgVyG6uMkZUFTOMaV20YW+tfk34E3QErgypUeWz4Ei8eRJq9pYYp55d 7m7tcJaJDV9wcIF0A39Q7S9LJ9GyB1VLJ+nOB3Gq1BccBoN+Qzeejikh/zzsfHFj GbgVmejzN8yM4wwx38b5mjvlFid5n2HeBlXCg5Rlntk9xh7QGSz1tQClqEvwuY2G HgIw3owJU5g44Q4/jEGrZp3BUWpVF4isGRx31ji6r4tYbds9Rnni02N9MbGJ1jok c/v8+uKf65jWHuZzVnKChfumGeCjWGqE5daPJ4FRNjeaBS6nxSHX7vTZqRSkrO/N CayDoGbCfwPwS/50f0lpqUTo1LGiQN7qx37GhVVdkNsJs/NgDqDUxHPVy/4+q+sH zNVVa6XT3kp+XrE+YwMvh4crRz3vweBO6RlyEahj7HWNmhBBzo0DPthSiENf/fak vlNJniT4rDTobbeGa3Pp =sy9x -----END PGP SIGNATURE----- --089e013c6ee6e38961052abafe91-- From nobody Mon Feb 1 14:03:28 2016 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CD6C1B3796 for ; Mon, 1 Feb 2016 14:03:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 PV2o31nZjZPQ for ; Mon, 1 Feb 2016 14:03:24 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (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 B410B1B3795 for ; Mon, 1 Feb 2016 14:03:23 -0800 (PST) Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u11M3HAb020037 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 1 Feb 2016 22:03:17 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u11M3GRx020483 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 1 Feb 2016 22:03:16 GMT Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u11M3FhQ000867; Mon, 1 Feb 2016 22:03:15 GMT Received: from [192.168.1.22] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 01 Feb 2016 14:03:15 -0800 Content-Type: multipart/alternative; boundary="Apple-Mail=_F1BFFA34-D3E3-476D-9531-D241E0D62384" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Phil Hunt In-Reply-To: Date: Mon, 1 Feb 2016 14:03:13 -0800 Message-Id: <51E9B4BE-F6DF-476A-9D0C-917E2E9B7433@oracle.com> References: <1FDBF3DD-6CEA-4E2E-AA7E-F3C12EB2B32A@wunderlich.ca> To: John Wunderlich X-Mailer: Apple Mail (2.3112) X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Cc: Sarah Squire , Justin Richer Subject: Re: [Id-event] Proposal for Identity Event Standard X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 22:03:27 -0000 --Apple-Mail=_F1BFFA34-D3E3-476D-9531-D241E0D62384 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 What we are working on new is a generic event system that has the = following traits: * Events (that may be extended for different purposes) that are based on = JWT (JSON Web Token). * JWT gives us the ability to have: plain text, signed, and/or encrypted = events that may be transported over different protocols like HTTP or = mobile messaging platforms. * A RESTful publish and subscribe system where interested parties may = register interest in certain event types. * Many use cases are inter-domain notifications (e.g. RISC and SCIM = events). Others are events for things like mobile apps (a profile or = subscription change). The generic event spec should be extensible for Sarah=E2=80=99s case (if = not I=E2=80=99d like to find out why). Though I would check in with the = existing types to see if some of the groups like OpenID aren=E2=80=99t = already covering something similar. Phil @independentid www.independentid.com = phil.hunt@oracle.com = > On Feb 1, 2016, at 12:11 PM, John Wunderlich = wrote: >=20 > Thanks. >=20 > It sounds like a useful incremental improvement, as you say, but it = does point to a more interesting general problem down the road. >=20 > Sincerely, > John Wunderlich > (@PrivacyCDN) >=20 > = >=20 >=20 > Privacist & PbD Ambassador = >=20 >=20 >=20 >=20 >> On Feb 1, 2016, at 15:09, Sarah Squire > wrote: >>=20 >> Hi John, >>=20 >> Good questions. I'm not proposing a distributed database or anything = blockchain-like. I am merely suggesting, as you say, that we add a few = more prescribed transactions and an endpoint for them to the existing = standards. These seem to be high-value communications that currently = aren't happening or are happening out of band in non-standardized = communications. >>=20 >> There may well be additional categories. I'd be curious if other = folks on this list have more use cases that this standard could address. >>=20 >> Sarah >>=20 >> Sarah Squire >> Engage Identity >> http://engageidentity.com >> On Mon, Feb 1, 2016 at 11:56 AM, John Wunderlich > wrote: >> Sarah; >>=20 >> Are you replicating the problem of =E2=80=9C..no language to talk to = each other outside of prescribed transactions=E2=80=9D at a higher level = by prescribing a set of four categories? It seems an appropriate = solution to the cases you describe, but are there other cases that would = necessitate additional categories? When I read the first part of your = strawman, I thought your reference to a JSON Web Log was starting down = the road to a distributed database (must still have blockchain on my = mind from the last IIW). Or am I misunderstanding and is what you are = proposing a semantic solution to the problem you pose? >>=20 >> Sincerely, >> John Wunderlich >> (@PrivacyCDN) >>=20 >> = >>=20 >>=20 >> Privacist & PbD Ambassador = >>=20 >>=20 >>=20 >>=20 >>> On Feb 1, 2016, at 12:35, Sarah Squire > wrote: >>>=20 >>> Hi all, >>>=20 >>> I=E2=80=99ve been mulling the idea of identity events and have run = into several situations with different clients where they could be = useful. I have a strawman that I would love for you all to take a few = torches to. >>>=20 >>> I propose that we create a new standard for a JSON Web Log, or JWL. >>>=20 >>> The problem I=E2=80=99m running into is that in distributed access = management protocols like OAuth and UMA, different ecosystem parties are = often in different security domains and have no language to talk to each = other outside of prescribed transactions. There are many cases in which = only one party has a log of an identity event, and it would be helpful = if they had some way to transmit that log to other parties in the = ecosystem. >>>=20 >>> Here is a list of a few things that a relying party might want to = say to an identity provider: >>>=20 >>> This user=E2=80=99s behavior is inconsistent with past heuristics = and I suspect fraud >>> the RP did parallel authentication of a second factor (e.g. My = employee Susan has verified that this user matches (or does not match) = the photo on file at the IdP) >>> Here is a privacy policy that this user consented to >>>=20 >>> Here is a list of a few things that an identity provider might want = to say to a relying party: >>>=20 >>> This user=E2=80=99s email changed since the last time you called the = UserInfo endpoint >>> A user account we have authenticated for you in the past has been = compromised >>> This user has revoked your access token >>>=20 >>> My proposal is that a JWL standard be developed based on the form of = a JWT, though with some different fields. It should require iss, sub, = aud, and iat, and the optional fields I think would fall into four = categories: suspected fraud, userinfo update, consent information, and = parallel authentication. Both RPs and IdPs would implement a JWL = endpoint to receive JWLs from other members of the ecosystem. >>>=20 >>> Thoughts? Would this be helpful? >>>=20 >>> Sarah=20 >>>=20 >>> Sarah Squire >>> Engage Identity >>> http://engageidentity.com = ______________________________________________= _ >>> Id-event mailing list >>> Id-event@ietf.org >>> https://www.ietf.org/mailman/listinfo/id-event = >>=20 >>=20 >>=20 >> This email and any files transmitted with it are confidential and = intended solely for the use of the individual or entity to whom they are = addressed. If you have received this email in error please notify the = system manager. This message contains confidential information and is = intended only for the individual named. If you are not the named = addressee you should not disseminate, distribute or copy this e-mail. = Please notify the sender immediately by e-mail if you have received this = e-mail by mistake and delete this e-mail from your system. If you are = not the intended recipient you are notified that disclosing, copying, = distributing or taking any action in reliance on the contents of this = information is strictly prohibited. >>=20 >=20 >=20 >=20 > This email and any files transmitted with it are confidential and = intended solely for the use of the individual or entity to whom they are = addressed. If you have received this email in error please notify the = system manager. This message contains confidential information and is = intended only for the individual named. If you are not the named = addressee you should not disseminate, distribute or copy this e-mail. = Please notify the sender immediately by e-mail if you have received this = e-mail by mistake and delete this e-mail from your system. If you are = not the intended recipient you are notified that disclosing, copying, = distributing or taking any action in reliance on the contents of this = information is strictly prohibited. > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event = --Apple-Mail=_F1BFFA34-D3E3-476D-9531-D241E0D62384 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 What we are working on new is a generic event system that has = the following traits:

    * Events (that may be extended for different purposes) that = are based on JWT (JSON Web Token).
    * JWT gives us = the ability to have: plain text, signed, and/or encrypted events that = may be transported over different protocols like HTTP or mobile = messaging platforms.
    * A RESTful publish and = subscribe system where interested parties may register interest in = certain event types.
    * Many use cases are = inter-domain notifications (e.g. RISC and SCIM events).  Others are = events for things like mobile apps (a profile or subscription = change).

    The = generic event spec should be extensible for Sarah=E2=80=99s case (if not = I=E2=80=99d like to find out why). Though I would check in with the = existing types to see if some of the groups like OpenID aren=E2=80=99t = already covering something similar.




    On Feb 1, 2016, at 12:11 PM, John Wunderlich <john@wunderlich.ca> = wrote:

    Thanks.

    It sounds like a useful incremental = improvement, as you say, but it does point to a more interesting general = problem down the road.

    Sincerely,
    John = Wunderlich
    (@PrivacyCDN)

    <PastedGraphic-4.ti= ff>


    Privacist & PbD Ambassador




    On Feb 1, 2016, at 15:09, Sarah Squire <sarah@engageidentity.com> wrote:

    Hi John,

    Good questions. I'm not proposing a distributed = database or anything blockchain-like. I am merely suggesting, as you = say, that we add a few more prescribed transactions and an endpoint for = them to the existing standards. These seem to be high-value = communications that currently aren't happening or are happening out of = band in non-standardized communications.

    There may well be additional = categories. I'd be curious if other folks on this list have more use = cases that this standard could address.

    Sarah

    Sarah Squire
    Engage Identity
    http://engageidentity.com

    On Mon, Feb 1, 2016 at 11:56 AM, = John Wunderlich <john@wunderlich.ca> wrote:
    Sarah;

    Are you replicating the problem of = =E2=80=9C..no language to talk to each other outside of prescribed = transactions=E2=80=9D at a higher level by prescribing a set of four = categories? It seems an appropriate solution to the cases you describe, = but are there other cases that would necessitate additional categories? = When I read the first part of your strawman, I thought your reference to = a JSON Web Log was starting down the road to a distributed database = (must still have blockchain on my mind from the last IIW). Or am I = misunderstanding and is what you are proposing a semantic solution to = the problem you pose?

    Sincerely,
    John Wunderlich
    (@PrivacyCDN)

    <PastedGraphic-4.tiff>=


    Privacist & PbD Ambassador




    On Feb 1, 2016, at 12:35, Sarah Squire = <sarah@engageidentity.com> wrote:

    Hi all,

    I=E2=80=99ve been mulling the idea of identity events and = have run into several situations with different clients where they could = be useful. I have a strawman that I would love for you all to take a few = torches to.

    I propose that we create a new standard for a JSON Web = Log, or JWL.

    The problem I=E2=80=99m running into is that in = distributed access management protocols like OAuth and UMA, different = ecosystem parties are often in different security domains and have no = language to talk to each other outside of prescribed transactions. There = are many cases in which only one party has a log of an identity event, = and it would be helpful if they had some way to transmit that log to = other parties in the ecosystem.

    Here is a list of a few things that a relying party might = want to say to an identity provider:

    • This user=E2=80=99s behavior is = inconsistent with past heuristics and I suspect = fraud
    • the RP = did parallel authentication of a second factor (e.g. My employee Susan = has verified that this user matches (or does not match) the photo on = file at the IdP)
    • Here is = a privacy policy that this user consented to

    Here is a list of a few things that an = identity provider might want to say to a relying party:

    • This user=E2=80=99s email = changed since the last time you called the UserInfo = endpoint
    • A user = account we have authenticated for you in the past has been = compromised
    • This = user has revoked your access token

    My proposal is that a JWL standard be = developed based on the form of a JWT, though with some different fields. = It should require iss, sub, aud, and iat, and the optional fields I = think would fall into four categories: suspected fraud, userinfo update, = consent information, and parallel authentication. Both RPs and IdPs = would implement a JWL endpoint to receive JWLs from other members of the = ecosystem.

    Thoughts? Would this be helpful?

    Sarah

    Sarah = Squire
    Engage = Identity
    http://engageidentity.com
    _______________________________________________
    Id-event mailing list
    Id-event@ietf.org
    https://www.ietf.org/mailman/listinfo/id-event



    This email = and any files transmitted with it are confidential and intended solely = for the use of the individual or entity to whom they are addressed. If = you have received this email in error please notify the system manager. = This message contains confidential information and is intended only for = the individual named. If you are not the named addressee you should not = disseminate, distribute or copy this e-mail. Please notify the sender = immediately by e-mail if you have received this e-mail by mistake and = delete this e-mail from your system. If you are not the intended = recipient you are notified that disclosing, copying, distributing or = taking any action in reliance on the contents of this information is = strictly prohibited.




    This email and any files = transmitted with it are confidential and intended solely for the use of = the individual or entity to whom they are addressed. If you have = received this email in error please notify the system manager. This = message contains confidential information and is intended only for the = individual named. If you are not the named addressee you should not = disseminate, distribute or copy this e-mail. Please notify the sender = immediately by e-mail if you have received this e-mail by mistake and = delete this e-mail from your system. If you are not the intended = recipient you are notified that disclosing, copying, distributing or = taking any action in reliance on the contents of this information is = strictly prohibited.
    <signa= ture.asc>_______________________________________________
    Id-event mailing = list
    Id-event@ietf.org
    https://www.ietf.org/mailman/listinfo/id-event
    = --Apple-Mail=_F1BFFA34-D3E3-476D-9531-D241E0D62384-- From nobody Tue Feb 2 00:48:06 2016 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 348BF1AC41F for ; Tue, 2 Feb 2016 00:48:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.621 X-Spam-Level: X-Spam-Status: No, score=0.621 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M0_-Xm9xQLt8 for ; Tue, 2 Feb 2016 00:47:59 -0800 (PST) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 896401AC406 for ; Tue, 2 Feb 2016 00:47:58 -0800 (PST) Received: by mail-wm0-x22c.google.com with SMTP id l66so11526538wml.0 for ; Tue, 02 Feb 2016 00:47:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bbva-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nYYJdFczk1OspjldgJGZF2Zyul1AiWd/8UneDDTvLX0=; b=CyFy4EpK3vLlzxz8U9+PfgF3jluXNNG0kDYsoQBLo1jXWvfOgPaOZY5rTKoV/hZ2vv wFc+OjHiDPBLXX7IJqG/WstuFAfuiMwLsCc6xGCHjl2AMPUYz3WtsF3ZzXbPqfLN5jdI rp4Oiz1TZLBXVyApADMnwmuIZN/jms+2lts8+Bb46Gq91/vW4zzSFRWWuAaNAxvDrkBp JYCdQ2u1zSsP8BFBM7TGYI6jdMa2N3HgS/VsIW7iCPS3dXtrkxjOzASpD4/M98AQ02jR gLbYyQpZ0he8oAjc2qCfWwFn7VszNj6VEYB+0Vw0TwcuMQ8eNbzQnv8Tc/BthxYzS89+ FzGw== 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=nYYJdFczk1OspjldgJGZF2Zyul1AiWd/8UneDDTvLX0=; b=IXSsvbIi2HFKhrdpA7DvHyioqtpoL30DLNhdaCvHIPJPEUEtABeWHDfhtAmeB+qzZs w1RNPJCYrx1EVeAySVnEDAzD85qR9bZapQ1ri98Xtz5i4nXSAzyYY0TmzvrIR1zAKy9F 1Uw97DyZp7IquhFfTJhMPoeCu3Te3s2cIhdA5E8uLoEaETNeofd3Fa4ZCUMtEasH1z9B 2LHixXNEE2ZmjPDguPkFlM28hlD+y8VaJyEuc8Jyjp1cUHN3+ekLNrcorpFzvZUyvKcb mY0vvQ+ckcU241wk8lu3Xn8SsZXK6mxfhOzWpc0DUq/yqYXVrETOV2nsCW+3RBbMhxdV S18g== X-Gm-Message-State: AG10YOTVgLxm6WfHbjLgmg/1DpjDUVNwUzTYnmsG/fVKoz04zolmYHjJJuK5IH/pLUcGQA/NrB0uJ9VF1OmUB0sFGNFahnTwEf8+XWRrrAWymlpuYN80QhuNcE9JCqd4hI8gq/zxfV6c+A== MIME-Version: 1.0 X-Received: by 10.28.172.193 with SMTP id v184mr17857907wme.94.1454402876235; Tue, 02 Feb 2016 00:47:56 -0800 (PST) Received: by 10.28.225.139 with HTTP; Tue, 2 Feb 2016 00:47:56 -0800 (PST) In-Reply-To: <51E9B4BE-F6DF-476A-9D0C-917E2E9B7433@oracle.com> References: <1FDBF3DD-6CEA-4E2E-AA7E-F3C12EB2B32A@wunderlich.ca> <51E9B4BE-F6DF-476A-9D0C-917E2E9B7433@oracle.com> Date: Tue, 2 Feb 2016 09:47:56 +0100 Message-ID: From: Luis SAIZ GIMENO To: Phil Hunt Content-Type: multipart/alternative; boundary=001a1140d744ce3333052ac58e46 Archived-At: Cc: John Wunderlich , Sarah Squire , Justin Richer Subject: Re: [Id-event] Proposal for Identity Event Standard X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 08:48:04 -0000 --001a1140d744ce3333052ac58e46 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I'm not an active member in the list but as a customer of this kind of solutions having an standard way to emit/receive events from/to IdP/RP is something that we'll appreciate a lot Phil, how it's organized the work in progress you mention? 2016-02-01 23:03 GMT+01:00 Phil Hunt : > What we are working on new is a generic event system that has the > following traits: > > * Events (that may be extended for different purposes) that are based on > JWT (JSON Web Token). > * JWT gives us the ability to have: plain text, signed, and/or encrypted > events that may be transported over different protocols like HTTP or mobi= le > messaging platforms. > * A RESTful publish and subscribe system where interested parties may > register interest in certain event types. > * Many use cases are inter-domain notifications (e.g. RISC and SCIM > events). Others are events for things like mobile apps (a profile or > subscription change). > > The generic event spec should be extensible for Sarah=E2=80=99s case (if = not I=E2=80=99d > like to find out why). Though I would check in with the existing types to > see if some of the groups like OpenID aren=E2=80=99t already covering som= ething > similar. > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > > On Feb 1, 2016, at 12:11 PM, John Wunderlich wrote: > > Thanks. > > It sounds like a useful incremental improvement, as you say, but it does > point to a more interesting general problem down the road. > > Sincerely, > *John Wunderlich* > *(@PrivacyCDN)* > > > > > > Privacist & PbD Ambassador > > > > > > On Feb 1, 2016, at 15:09, Sarah Squire wrote: > > Hi John, > > Good questions. I'm not proposing a distributed database or anything > blockchain-like. I am merely suggesting, as you say, that we add a few mo= re > prescribed transactions and an endpoint for them to the existing standard= s. > These seem to be high-value communications that currently aren't happenin= g > or are happening out of band in non-standardized communications. > > There may well be additional categories. I'd be curious if other folks on > this list have more use cases that this standard could address. > > Sarah > > Sarah Squire > Engage Identity > http://engageidentity.com > > On Mon, Feb 1, 2016 at 11:56 AM, John Wunderlich > wrote: > >> Sarah; >> >> Are you replicating the problem of =E2=80=9C..no language to talk to eac= h other >> outside of prescribed transactions=E2=80=9D at a higher level by prescri= bing a set >> of four categories? It seems an appropriate solution to the cases you >> describe, but are there other cases that would necessitate additional >> categories? When I read the first part of your strawman, I thought your >> reference to a JSON Web Log was starting down the road to a distributed >> database (must still have blockchain on my mind from the last IIW). Or a= m I >> misunderstanding and is what you are proposing a semantic solution to th= e >> problem you pose? >> >> Sincerely, >> *John Wunderlich* >> *(@PrivacyCDN)* >> >> >> >> >> >> Privacist & PbD Ambassador >> >> >> >> >> >> On Feb 1, 2016, at 12:35, Sarah Squire wrote: >> >> Hi all, >> >> I=E2=80=99ve been mulling the idea of identity events and have run into = several >> situations with different clients where they could be useful. I have a >> strawman that I would love for you all to take a few torches to. >> >> I propose that we create a new standard for a JSON Web Log, or JWL. >> >> The problem I=E2=80=99m running into is that in distributed access manag= ement >> protocols like OAuth and UMA, different ecosystem parties are often in >> different security domains and have no language to talk to each other >> outside of prescribed transactions. There are many cases in which only o= ne >> party has a log of an identity event, and it would be helpful if they ha= d >> some way to transmit that log to other parties in the ecosystem. >> >> Here is a list of a few things that a relying party might want to say to >> an identity provider: >> >> >> - This user=E2=80=99s behavior is inconsistent with past heuristics a= nd I >> suspect fraud >> - the RP did parallel authentication of a second factor (e.g. My >> employee Susan has verified that this user matches (or does not match= ) the >> photo on file at the IdP) >> - Here is a privacy policy that this user consented to >> >> >> Here is a list of a few things that an identity provider might want to >> say to a relying party: >> >> >> - This user=E2=80=99s email changed since the last time you called th= e >> UserInfo endpoint >> - A user account we have authenticated for you in the past has been >> compromised >> - This user has revoked your access token >> >> >> My proposal is that a JWL standard be developed based on the form of a >> JWT, though with some different fields. It should require iss, sub, aud, >> and iat, and the optional fields I think would fall into four categories= : >> suspected fraud, userinfo update, consent information, and parallel >> authentication. Both RPs and IdPs would implement a JWL endpoint to rece= ive >> JWLs from other members of the ecosystem. >> >> Thoughts? Would this be helpful? >> >> Sarah >> >> Sarah Squire >> Engage Identity >> http://engageidentity.com >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://www.ietf.org/mailman/listinfo/id-event >> >> >> >> >> This email and any files transmitted with it are confidential and >> intended solely for the use of the individual or entity to whom they are >> addressed. If you have received this email in error please notify the >> system manager. This message contains confidential information and is >> intended only for the individual named. If you are not the named address= ee >> you should not disseminate, distribute or copy this e-mail. Please notif= y >> the sender immediately by e-mail if you have received this e-mail by >> mistake and delete this e-mail from your system. If you are not the >> intended recipient you are notified that disclosing, copying, distributi= ng >> or taking any action in reliance on the contents of this information is >> strictly prohibited. >> > > > > > This email and any files transmitted with it are confidential and intende= d > solely for the use of the individual or entity to whom they are addressed= . > If you have received this email in error please notify the system manager= . > This message contains confidential information and is intended only for t= he > individual named. If you are not the named addressee you should not > disseminate, distribute or copy this e-mail. Please notify the sender > immediately by e-mail if you have received this e-mail by mistake and > delete this e-mail from your system. If you are not the intended recipien= t > you are notified that disclosing, copying, distributing or taking any > action in reliance on the contents of this information is strictly > prohibited. > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > --=20 *BBVA* *Luis Saiz Gimeno* *Innovation in Security* M=C3=B3vil +34 609703264 - Tel. +34 918073152 - luis.saiz@bbva.com *Engineering - Architecture & Global Deployment *=E2=80=93 Monforte de Lemo= s, s/n, 28029 Maps: https://www.google.es/maps/place/Av.+de+Monforte+de+Lemos,+28,+28029+Madrid= / Antes de imprimir este mensaje, por favor comprueba que es necesario hacerlo. Before you print this message please consider if it is really necessary. --=20 "Este mensaje est=C3=A1 dirigido de manera exclusiva a su destinatario y pu= ede=20 contener informaci=C3=B3n privada y confidencial. No lo reenv=C3=ADe, copie= o=20 distribuya a terceros que no deban conocer su contenido. En caso de haberlo= =20 recibido por error, rogamos lo notifique al remitente y proceda a su=20 borrado, as=C3=AD como al de cualquier documento que pudiera adjuntarse. Por favor tenga en cuenta que los correos enviados v=C3=ADa Internet no=20 permiten garantizar la confidencialidad de los mensajes ni su transmisi=C3= =B3n=20 de forma =C3=ADntegra. Las opiniones expresadas en el presente correo pertenecen =C3=BAnicamente = al=20 remitente y no representan necesariamente la opini=C3=B3n del Grupo BBVA." "This message is intended exclusively for the adressee and may contain=20 privileged and confidential information. Please, do not disseminate, copy= =20 or distribute it to third parties who should not receive it. In case you=20 have received it by mistake, please inform the sender and delete the=20 message and attachments from your system. Please keep in mind that e-mails sent by Internet do not allow to=20 guarantee neither the confidentiality or the integrity of the messages=20 sent." --001a1140d744ce3333052ac58e46 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    I'm not an active member in the list but as a customer= of this kind of solutions having an standard way to emit/receive events fr= om/to IdP/RP is something that we'll appreciate a lot


    Phil, how it's organized the work in progress you ment= ion?

    2= 016-02-01 23:03 GMT+01:00 Phil Hunt <phil.hunt@oracle.com>:
    Wh= at we are working on new is a generic event system that has the following t= raits:

    * Events (that may be extended for different purp= oses) that are based on JWT (JSON Web Token).
    * JWT gives us the = ability to have: plain text, signed, and/or encrypted events that may be tr= ansported over different protocols like HTTP or mobile messaging platforms.=
    * A RESTful publish and subscribe system where interested partie= s may register interest in certain event types.
    * Many use cases = are inter-domain notifications (e.g. RISC and SCIM events).=C2=A0 Others ar= e events for things like mobile apps (a profile or subscription change).

    The generic event spec should be extensible for Sara= h=E2=80=99s case (if not I=E2=80=99d like to find out why). Though I would = check in with the existing types to see if some of the groups like OpenID a= ren=E2=80=99t already covering something similar.

    =
    On Feb 1, 2016, at= 12:11 PM, John Wunderlich <john@wunderlich.ca> wrote:

    Thanks.

    It sounds like a use= ful incremental improvement, as you say, but it does point to a more intere= sting general problem down the road.

    Sincerely,
    John Wunderlich
    (@PrivacyCDN)
    <= div style=3D"font-family:'Avenir Next';font-style:normal;font-varia= nt:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-= align:-webkit-auto;text-indent:0px;text-transform:none;white-space:normal;w= ord-spacing:0px;word-wrap:break-word">
    <PastedGra= phic-4.tiff>

    On Feb 1, 2016, at 15:09, Sarah Squire <sarah@engageidentity.com&= gt; wrote:

    Hi John,

    Good questions. I'm not proposing a distributed database or anything b= lockchain-like. I am merely suggesting, as you say, that we add a few more = prescribed transactions and an endpoint for them to the existing standards.= These seem to be high-value communications that currently aren't happe= ning or are happening out of band in non-standardized communications.
    <= br>
    There may well be additional categories. I'd be curious i= f other folks on this list have more use cases that this standard could add= ress.

    Sarah
    =
    Sarah Squire
    Engage Iden= tity

    On Mo= n, Feb 1, 2016 at 11:56 AM, John Wunderlich=C2=A0<john@wunde= rlich.ca>=C2=A0wrote:
    Sarah;

    Are you replicating= the problem of =E2=80=9C..no language to talk to each other outside of pre= scribed transactions=E2=80=9D at a higher level by prescribing a set of fou= r categories? It seems an appropriate solution to the cases you describe, b= ut are there other cases that would necessitate additional categories? When= I read the first part of your strawman, I thought your reference to a JSON= Web Log was starting down the road to a distributed database (must still h= ave blockchain on my mind from the last IIW). Or am I misunderstanding and = is what you are proposing a semantic solution to the problem you pose?

    Sincerely,

    On Feb 1, 2016, at 12:35, Sarah Squire <sarah@engageiden= tity.com> wrote:

    Hi all,

    =
    I=E2=80=99ve been mulling the id= ea of identity events and have run into several situations with different c= lients where they could be useful. I have a strawman that I would love for = you all to take a few torches to.

    I propose that we create a new standard for a JSON Web Lo= g, or JWL.

    The p= roblem I=E2=80=99m running into is that in distributed access management pr= otocols like OAuth and UMA, different ecosystem parties are often in differ= ent security domains and have no language to talk to each other outside of = prescribed transactions. There are many cases in which only one party has a= log of an identity event, and it would be helpful if they had some way to = transmit that log to other parties in the ecosystem.

    Here is a list of a few things that a = relying party might want to say to an identity provider:

  • This user=E2=80= =99s behavior is inconsistent with past heuristics and I suspect fraud
  • the RP did parallel authentication of a second fa= ctor (e.g. My employee Susan has verified that this user matches (or does n= ot match) the photo on file at the IdP)
  • Here = is a privacy policy that this user consented to

    • <= div style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt">Here is a list of a few things th= at an identity provider might want to say to a relying party:
    <= br>
    • This user=E2= =80=99s email changed since the last time you called the UserInfo endpoint<= /span>
    • A user account we have authenticated for you = in the past has been compromised
    • This user ha= s revoked your access token

    My proposal is that a JWL standard be developed based= on the form of a JWT, though with some different fields. It should require= iss, sub, aud, and iat, and the optional fields I think would fall into fo= ur categories: suspected fraud, userinfo update, consent information, and p= arallel authentication. Both RPs and IdPs would implement a JWL endpoint to= receive JWLs from other members of the ecosystem.

    Thoughts? Would this be helpful?<= /div>
    <= span style=3D"font-size:14.6667px;font-family:Arial;vertical-align:baseline= ;white-space:pre-wrap;background-color:transparent">Sarah

    Sarah Squire
    Engage Identity
    http://engageidentity.com
    _______________________________________________
    Id-e= vent mailing list
    Id-event@ietf.org
    https://www.ietf.org/mailman/listinfo/id-event<= /a>



    This email and any files t= ransmitted with it are confidential and intended solely for the use of the = individual or entity to whom they are addressed. If you have received this = email in error please notify the system manager. This message contains conf= idential information and is intended only for the individual named. If you = are not the named addressee you should not disseminate, distribute or copy = this e-mail. Please notify the sender immediately by e-mail if you have rec= eived this e-mail by mistake and delete this e-mail from your system. If yo= u are not the intended recipient you are notified that disclosing, copying,= distributing or taking any action in reliance on the contents of this info= rmation is strictly prohibited.


    <= br style=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-var= iant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-= indent:0px;text-transform:none;white-space:normal;word-spacing:0px">

    This emai= l and any files transmitted with it are confidential and intended solely fo= r the use of the individual or entity to whom they are addressed. If you ha= ve received this email in error please notify the system manager. This mess= age contains confidential information and is intended only for the individu= al named. If you are not the named addressee you should not disseminate, di= stribute or copy this e-mail. Please notify the sender immediately by e-mai= l if you have received this e-mail by mistake and delete this e-mail from y= our system. If you are not the intended recipient you are notified that dis= closing, copying, distributing or taking any action in reliance on the cont= ents of this information is strictly prohibited.
    <signature.asc>___________= ____________________________________
    Id-event mailing list
    Id-event@ietf.org
    https://www.ietf.org/mailman/listinfo/id-event
    =


    ____________________________________= ___________
    Id-event mailing list
    Id-event@ietf.org
    https://www.ietf.org/mailman/listinfo/id-event




    --

    BBVA

    Luis Saiz Gimeno

    Innovation i= n Security

    <= span style=3D"color:rgb(9,79,164);font-family:Arial;font-size:10pt;line-hei= ght:150%">M=C3=B3vil +34=C2=A0609703264=C2=A0- Tel. +34=C2=A0918073152 -=C2= =A0luis.saiz@bbva.com

    Engineering - Architecture & = Global Deployment =E2=80=93 Monforte de Lemos, s= /n, 28029

    Maps: https://www.google.es/maps/place/Av.+de+Monforte+d= e+Lemos,+28,+28029+Madrid/

    Antes de imprimir este mensaje, por favor comprueba que es necesario ha= cerlo. Before you print this message please consider if it= is really necessary.

    <= /div>

    "Este mensaje es= t=C3=A1 dirigido de manera exclusiva a su destinatario y puede contener informaci= =C3=B3n privada y confidencial. No lo reenv=C3=ADe, copie o distribuya a terceros q= ue no deban conocer su contenido.=C2=A0En caso de haberlo recibido por error,=C2= =A0=C2=A0rogamos lo notifique al remitente y proceda a su borrado, as=C3=AD como al de cualq= uier documento que pudiera adjuntarse.

    =C2=A0P= or favor tenga en cuenta que los correos enviados v=C3=ADa Internet no permiten garantizar la confidenci= alidad de los mensajes ni su transmisi=C3=B3n de forma =C3=ADntegra.

    =C2=A0L= as opiniones expresadas en el presente correo pertenecen =C3=BAnicamente al remitente y no representan necesariamente la opini=C3=B3n del Grupo BBVA."

    =C2=A0&= quot;This message is intended exclusively for the adressee and may contain privileged= and confidential information. Please, do not disseminate, copy or distribute it= to third parties who should not receive it. In case you have received it by mistake, please inform the sender and delete the message and attachments fr= om your system.

    =C2=A0= Please keep in mind that e-mails sent by Internet do not allow to guarantee neithe= r the confidentiality or the integrity of the messages sent."

    --001a1140d744ce3333052ac58e46-- From nobody Tue Feb 2 01:04:11 2016 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 606811AC445 for ; Tue, 2 Feb 2016 01:04:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.911 X-Spam-Level: X-Spam-Status: No, score=0.911 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zJ4ADLxXwB7b for ; Tue, 2 Feb 2016 01:04:01 -0800 (PST) Received: from a2nlsmtp01-04.prod.iad2.secureserver.net (a2nlsmtp01-04.prod.iad2.secureserver.net [198.71.225.38]) (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 89B701A8A28 for ; Tue, 2 Feb 2016 01:04:00 -0800 (PST) Received: from n1plcpnl0071.prod.ams1.secureserver.net ([188.121.57.8]) by : HOSTING RELAY : with SMTP id QWsQa3kO4YEvGQWsRabGQf; Tue, 02 Feb 2016 02:03:59 -0700 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=openconsentgroup.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To:From:Content-Type:Mime-Version:Subject; bh=XYnT0eENuJjm27p5DavlLHspwPxy7o8UZASyB2L8lSU=; b=aY0HveMxvFsQ+30Ur0oqWYxo3zyDf67l1+U1B3hObvoCQMmVUiXX0gSJU5q2+kSRw4fO8BLzCVvplsQrd11/tXKtnjMrr0qGOHfb2Xydy5X/odI16avTuEEyk/J02G9JqxL1BGKyBvzNIVAktwcQWGub8/PmNL6JwODx+jZ71IjGlEKCQA/wZk0sh4Xp1kK+EJE5ZJqI8X5K0oIeEMKXwktELiOpW2erFgcfzKPYBMg2dnVDPb1dKS6ucwuyRtpSrpsvgSMZPBN+giTzZo3OskolaQTX2wLl+dE75TnPXHe/IhrgV2fepQjtCdApVAGAPLHSTV0e51Te23E7ddDLeA==; Received: from host-78-146-24-24.as13285.net ([78.146.24.24]:49539 helo=[192.168.1.14]) by n1plcpnl0071.prod.ams1.secureserver.net with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.85) (envelope-from ) id 1aQWsQ-002izg-8N; Tue, 02 Feb 2016 02:03:58 -0700 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: multipart/signed; boundary="Apple-Mail=_F7822C8D-EB30-4139-9F9C-69D854E742CD"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: Mark Lizar - OCG In-Reply-To: Date: Tue, 2 Feb 2016 09:03:52 +0000 Message-Id: References: <1FDBF3DD-6CEA-4E2E-AA7E-F3C12EB2B32A@wunderlich.ca> <51E9B4BE-F6DF-476A-9D0C-917E2E9B7433@oracle.com> To: Luis SAIZ GIMENO X-Mailer: Apple Mail (2.3112) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - n1plcpnl0071.prod.ams1.secureserver.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - openconsentgroup.com X-Get-Message-Sender-Via: n1plcpnl0071.prod.ams1.secureserver.net: authenticated_id: m.lizar@openconsentgroup.com X-Source: X-Source-Args: X-Source-Dir: X-CMAE-Envelope: MS4wfK7T881U82HEXG4t+Aajgf5EMb4dB1e6BKl8yiEEfqiPICxjHE1UOdGDTbag2fvJ7QX404F9wLVx7kQn/flIdrcfhgjRvsaqyHvS9oDZEC5kQ6eOmRmz CSoNdPyz9eWKLlz/KtE8k7JCBXvvJScNEloxsFMgKn3yrHDzIntrgJYRWIIuZ/ryWdjdxVyKZEWxJ6t2chnaUPfHQn4t0DQedsc= Archived-At: Cc: John Wunderlich , Sarah Squire , id-event@ietf.org, Phil Hunt Subject: Re: [Id-event] Proposal for Identity Event Standard X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 09:04:09 -0000 --Apple-Mail=_F7822C8D-EB30-4139-9F9C-69D854E742CD Content-Type: multipart/alternative; boundary="Apple-Mail=_6BADE2F2-6AD6-4075-9A5E-BDDA86BA2F34" --Apple-Mail=_6BADE2F2-6AD6-4075-9A5E-BDDA86BA2F34 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Sarah, I think it is terrific thinking and very insightful. We are very = interested in this for consent events and the delegation of consent for = a wide array of access control notices and transactions which relate to = consent records. It appears work like this would extend the core of = the consent work we are doing and I think its very well timed, a super = efficient and technically great approach to the set of problems in this = space. The JWT logging is brilliant :-) Personally, I think the Consent and = Information Sharing WG would be very happy to see your work move in = this direction and I would hope that we could compliment it. Mark Lizar Executive Director Open Consent Group Email: m.lizar@openconsentgroup.com Twitter: @smartopian > On 2 Feb 2016, at 08:47, Luis SAIZ GIMENO wrote: >=20 > I'm not an active member in the list but as a customer of this kind of = solutions having an standard way to emit/receive events from/to IdP/RP = is something that we'll appreciate a lot >=20 >=20 > Phil, how it's organized the work in progress you mention? >=20 > 2016-02-01 23:03 GMT+01:00 Phil Hunt >: > What we are working on new is a generic event system that has the = following traits: >=20 > * Events (that may be extended for different purposes) that are based = on JWT (JSON Web Token). > * JWT gives us the ability to have: plain text, signed, and/or = encrypted events that may be transported over different protocols like = HTTP or mobile messaging platforms. > * A RESTful publish and subscribe system where interested parties may = register interest in certain event types. > * Many use cases are inter-domain notifications (e.g. RISC and SCIM = events). Others are events for things like mobile apps (a profile or = subscription change). >=20 > The generic event spec should be extensible for Sarah=E2=80=99s case = (if not I=E2=80=99d like to find out why). Though I would check in with = the existing types to see if some of the groups like OpenID aren=E2=80=99t= already covering something similar. >=20 > Phil >=20 > @independentid > www.independentid.com = phil.hunt@oracle.com = >=20 >=20 >=20 >=20 >=20 >> On Feb 1, 2016, at 12:11 PM, John Wunderlich > wrote: >>=20 >> Thanks. >>=20 >> It sounds like a useful incremental improvement, as you say, but it = does point to a more interesting general problem down the road. >>=20 >> Sincerely, >> John Wunderlich >> (@PrivacyCDN) >>=20 >> = >>=20 >>=20 >> Privacist & PbD Ambassador = >>=20 >>=20 >>=20 >>=20 >>> On Feb 1, 2016, at 15:09, Sarah Squire > wrote: >>>=20 >>> Hi John, >>>=20 >>> Good questions. I'm not proposing a distributed database or anything = blockchain-like. I am merely suggesting, as you say, that we add a few = more prescribed transactions and an endpoint for them to the existing = standards. These seem to be high-value communications that currently = aren't happening or are happening out of band in non-standardized = communications. >>>=20 >>> There may well be additional categories. I'd be curious if other = folks on this list have more use cases that this standard could address. >>>=20 >>> Sarah >>>=20 >>> Sarah Squire >>> Engage Identity >>> http://engageidentity.com >>> On Mon, Feb 1, 2016 at 11:56 AM, John Wunderlich > wrote: >>> Sarah; >>>=20 >>> Are you replicating the problem of =E2=80=9C..no language to talk to = each other outside of prescribed transactions=E2=80=9D at a higher level = by prescribing a set of four categories? It seems an appropriate = solution to the cases you describe, but are there other cases that would = necessitate additional categories? When I read the first part of your = strawman, I thought your reference to a JSON Web Log was starting down = the road to a distributed database (must still have blockchain on my = mind from the last IIW). Or am I misunderstanding and is what you are = proposing a semantic solution to the problem you pose? >>>=20 >>> Sincerely, >>> John Wunderlich >>> (@PrivacyCDN) >>>=20 >>> = >>>=20 >>>=20 >>> Privacist & PbD Ambassador = >>>=20 >>>=20 >>>=20 >>>=20 >>>> On Feb 1, 2016, at 12:35, Sarah Squire > wrote: >>>>=20 >>>> Hi all, >>>>=20 >>>> I=E2=80=99ve been mulling the idea of identity events and have run = into several situations with different clients where they could be = useful. I have a strawman that I would love for you all to take a few = torches to. >>>>=20 >>>> I propose that we create a new standard for a JSON Web Log, or JWL. >>>>=20 >>>> The problem I=E2=80=99m running into is that in distributed access = management protocols like OAuth and UMA, different ecosystem parties are = often in different security domains and have no language to talk to each = other outside of prescribed transactions. There are many cases in which = only one party has a log of an identity event, and it would be helpful = if they had some way to transmit that log to other parties in the = ecosystem. >>>>=20 >>>> Here is a list of a few things that a relying party might want to = say to an identity provider: >>>>=20 >>>> This user=E2=80=99s behavior is inconsistent with past heuristics = and I suspect fraud >>>> the RP did parallel authentication of a second factor (e.g. My = employee Susan has verified that this user matches (or does not match) = the photo on file at the IdP) >>>> Here is a privacy policy that this user consented to >>>>=20 >>>> Here is a list of a few things that an identity provider might want = to say to a relying party: >>>>=20 >>>> This user=E2=80=99s email changed since the last time you called = the UserInfo endpoint >>>> A user account we have authenticated for you in the past has been = compromised >>>> This user has revoked your access token >>>>=20 >>>> My proposal is that a JWL standard be developed based on the form = of a JWT, though with some different fields. It should require iss, sub, = aud, and iat, and the optional fields I think would fall into four = categories: suspected fraud, userinfo update, consent information, and = parallel authentication. Both RPs and IdPs would implement a JWL = endpoint to receive JWLs from other members of the ecosystem. >>>>=20 >>>> Thoughts? Would this be helpful? >>>>=20 >>>> Sarah >>>>=20 >>>> Sarah Squire >>>> Engage Identity >>>> http://engageidentity.com = ______________________________________________= _ >>>> Id-event mailing list >>>> Id-event@ietf.org >>>> https://www.ietf.org/mailman/listinfo/id-event = >>>=20 >>>=20 >>>=20 >>> This email and any files transmitted with it are confidential and = intended solely for the use of the individual or entity to whom they are = addressed. If you have received this email in error please notify the = system manager. This message contains confidential information and is = intended only for the individual named. If you are not the named = addressee you should not disseminate, distribute or copy this e-mail. = Please notify the sender immediately by e-mail if you have received this = e-mail by mistake and delete this e-mail from your system. If you are = not the intended recipient you are notified that disclosing, copying, = distributing or taking any action in reliance on the contents of this = information is strictly prohibited. >>>=20 >>=20 >>=20 >>=20 >> This email and any files transmitted with it are confidential and = intended solely for the use of the individual or entity to whom they are = addressed. If you have received this email in error please notify the = system manager. This message contains confidential information and is = intended only for the individual named. If you are not the named = addressee you should not disseminate, distribute or copy this e-mail. = Please notify the sender immediately by e-mail if you have received this = e-mail by mistake and delete this e-mail from your system. If you are = not the intended recipient you are notified that disclosing, copying, = distributing or taking any action in reliance on the contents of this = information is strictly prohibited. >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://www.ietf.org/mailman/listinfo/id-event = >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event = >=20 >=20 >=20 >=20 > -- > BBVA > Luis Saiz Gimeno > Innovation in Security > M=C3=B3vil +34 609703264 - Tel. +34 918073152 - luis.saiz@bbva.com = > Engineering - Architecture & Global Deployment =E2=80=93 Monforte de = Lemos, s/n, 28029 > Maps: = https://www.google.es/maps/place/Av.+de+Monforte+de+Lemos,+28,+28029+Madri= d/ = > Antes de imprimir este mensaje, por favor comprueba que es necesario = hacerlo. Before you print this message please consider if it is really = necessary. >=20 > "Este mensaje est=C3=A1 dirigido de manera exclusiva a su destinatario = y puede contener informaci=C3=B3n privada y confidencial. No lo = reenv=C3=ADe, copie o distribuya a terceros que no deban conocer su = contenido. En caso de haberlo recibido por error, rogamos lo notifique = al remitente y proceda a su borrado, as=C3=AD como al de cualquier = documento que pudiera adjuntarse. >=20 > Por favor tenga en cuenta que los correos enviados v=C3=ADa Internet = no permiten garantizar la confidencialidad de los mensajes ni su = transmisi=C3=B3n de forma =C3=ADntegra. >=20 > Las opiniones expresadas en el presente correo pertenecen =C3=BAnicamen= te al remitente y no representan necesariamente la opini=C3=B3n del = Grupo BBVA." >=20 > "This message is intended exclusively for the adressee and may = contain privileged and confidential information. Please, do not = disseminate, copy or distribute it to third parties who should not = receive it. In case you have received it by mistake, please inform the = sender and delete the message and attachments from your system. >=20 > Please keep in mind that e-mails sent by Internet do not allow to = guarantee neither the confidentiality or the integrity of the messages = sent." >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event --Apple-Mail=_6BADE2F2-6AD6-4075-9A5E-BDDA86BA2F34 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
    Sarah, 

    I think it is terrific thinking and = very insightful.  We are very interested in this for consent events = and the delegation of consent for a wide array of access control notices = and transactions which relate to consent records.  It appears work = like this  would extend the core of the consent work we are doing = and I think its very well timed, a super efficient and technically great = approach to the set of problems in this space. 

    The JWT logging is brilliant :-)   =   Personally, I think the Consent and Information Sharing  WG = would be very happy to see your work move in this direction and I would = hope that we could compliment it. 

    Mark Lizar
    Executive Director
    Open Consent Group

    Email: m.lizar@openconsentgroup.com
    Twitter: @smartopian

    On 2 Feb 2016, at 08:47, Luis SAIZ GIMENO = <luis.saiz@bbva.com> wrote:

    I'm not an active member in the list but as a customer of = this kind of solutions having an standard way to emit/receive events = from/to IdP/RP is something that we'll appreciate a lot

    Phil, how it's organized the work in progress you = mention?

    2016-02-01 23:03 GMT+01:00 Phil Hunt <phil.hunt@oracle.com>:
    What we are working on new is = a generic event system that has the following traits:

    * Events (that may be extended for = different purposes) that are based on JWT (JSON Web Token).
    * JWT gives us the ability to have: plain text, signed, = and/or encrypted events that may be transported over different protocols = like HTTP or mobile messaging platforms.
    * A = RESTful publish and subscribe system where interested parties may = register interest in certain event types.
    * Many = use cases are inter-domain notifications (e.g. RISC and SCIM = events).  Others are events for things like mobile apps (a profile = or subscription change).

    The generic event spec should be extensible for Sarah=E2=80=99s= case (if not I=E2=80=99d like to find out why). Though I would check in = with the existing types to see if some of the groups like OpenID = aren=E2=80=99t already covering something similar.

    Phil

    @independentid
    www.independentid.com
    phil.hunt@oracle.com




    =

    On Feb 1, 2016, at 12:11 PM, John Wunderlich = <john@wunderlich.ca> wrote:

    Thanks.

    It sounds like a useful incremental = improvement, as you say, but it does point to a more interesting general = problem down the road.

    Sincerely,
    John Wunderlich
    (@PrivacyCDN)

    On Feb 1, 2016, at 15:09, Sarah Squire <sarah@engageidentity.com> wrote:

    Hi = John,

    Good questions. I'm not = proposing a distributed database or anything blockchain-like. I am = merely suggesting, as you say, that we add a few more prescribed = transactions and an endpoint for them to the existing standards. These = seem to be high-value communications that currently aren't happening or = are happening out of band in non-standardized communications.

    There may well be = additional categories. I'd be curious if other folks on this list have = more use cases that this standard could address.

    Sarah

    Sarah Squire
    Engage Identity
    http://engageidentity.com

    On Mon, Feb 1, 2016 at 11:56 AM, = John Wunderlich <john@wunderlich.ca> wrote:
    Sarah;

    Are = you replicating the problem of =E2=80=9C..no language to talk to each = other outside of prescribed transactions=E2=80=9D at a higher level by = prescribing a set of four categories? It seems an appropriate solution = to the cases you describe, but are there other cases that would = necessitate additional categories? When I read the first part of your = strawman, I thought your reference to a JSON Web Log was starting down = the road to a distributed database (must still have blockchain on my = mind from the last IIW). Or am I misunderstanding and is what you are = proposing a semantic solution to the problem you pose?

    Sincerely,
    John Wunderlich
    (@PrivacyCDN)

    On Feb 1, 2016, at 12:35, Sarah Squire <sarah@engageidentity.com> wrote:

    Hi = all,

    I=E2=80=99ve = been mulling the idea of identity events and have run into several = situations with different clients where they could be useful. I have a = strawman that I would love for you all to take a few torches = to.

    I propose = that we create a new standard for a JSON Web Log, or = JWL.

    The problem = I=E2=80=99m running into is that in distributed access management = protocols like OAuth and UMA, different ecosystem parties are often in = different security domains and have no language to talk to each other = outside of prescribed transactions. There are many cases in which only = one party has a log of an identity event, and it would be helpful if = they had some way to transmit that log to other parties in the = ecosystem.

    Here is a = list of a few things that a relying party might want to say to an = identity provider:

    • This user=E2=80=99s behavior is = inconsistent with past heuristics and I suspect = fraud
    • the RP did parallel = authentication of a second factor (e.g. My employee Susan has verified = that this user matches (or does not match) the photo on file at the = IdP)
    • Here is a privacy policy that = this user consented to

    Here is a = list of a few things that an identity provider might want to say to a = relying party:

    • This user=E2=80=99s email = changed since the last time you called the UserInfo = endpoint
    • A user account we have = authenticated for you in the past has been = compromised
    • This user has revoked your = access token

    My proposal = is that a JWL standard be developed based on the form of a JWT, though = with some different fields. It should require iss, sub, aud, and iat, = and the optional fields I think would fall into four categories: = suspected fraud, userinfo update, consent information, and parallel = authentication. Both RPs and IdPs would implement a JWL endpoint to = receive JWLs from other members of the ecosystem.

    Thoughts? = Would this be helpful?

    Sarah =

    Sarah Squire
    Engage Identity
    http://engageidentity.com
    _______________________________________________
    Id-event mailing list
    Id-event@ietf.org
    https://www.ietf.org/mailman/listinfo/id-event



    This email and any files = transmitted with it are confidential and intended solely for the use of = the individual or entity to whom they are addressed. If you have = received this email in error please notify the system manager. This = message contains confidential information and is intended only for the = individual named. If you are not the named addressee you should not = disseminate, distribute or copy this e-mail. Please notify the sender = immediately by e-mail if you have received this e-mail by mistake and = delete this e-mail from your system. If you are not the intended = recipient you are notified that disclosing, copying, distributing or = taking any action in reliance on the contents of this information is = strictly prohibited.




    This email and any files transmitted with it are confidential = and intended solely for the use of the individual or entity to whom they = are addressed. If you have received this email in error please notify = the system manager. This message contains confidential information and = is intended only for the individual named. If you are not the named = addressee you should not disseminate, distribute or copy this e-mail. = Please notify the sender immediately by e-mail if you have received this = e-mail by mistake and delete this e-mail from your system. If you are = not the intended recipient you are notified that disclosing, copying, = distributing or taking any action in reliance on the contents of this = information is strictly prohibited.
    <signature.asc>_______________________________________________
    Id-event mailing list
    Id-event@ietf.org
    https://www.ietf.org/mailman/listinfo/id-event
    =


    _______________________________________________
    Id-event mailing list
    Id-event@ietf.org
    https://www.ietf.org/mailman/listinfo/id-event




    --
    BBVA
    Luis = Saiz Gimeno
    Innovation in = Security
    M=C3=B3vil +34 609703264 - Tel. = +34 918073152 - luis.saiz@bbva.com
    Engineering - = Architecture & Global Deployment =E2=80=93 Monforte de Lemos, s/n, = 28029
    Maps: https://www.google.es/maps/place/Av.+de+Monforte+de+Lemos,+28,+= 28029+Madrid/
    Antes de imprimir este mensaje, por favor comprueba que es = necesario hacerlo. Before you print this message please consider if it is really = necessary.

    "Este mensaje est=C3=A1 dirigido de manera exclusiva a su destinatario y puede contener = informaci=C3=B3n privada y confidencial. No lo reenv=C3=ADe, copie o distribuya a = terceros que no deban conocer su contenido. En caso de haberlo recibido por = error,  rogamos lo notifique al remitente y proceda a su borrado, as=C3=AD como al de = cualquier documento que pudiera adjuntarse.

     Por favor tenga en cuenta que los correos enviados v=C3=ADa Internet no permiten garantizar la = confidencialidad de los mensajes ni su transmisi=C3=B3n de forma =C3=ADntegra.

     Las opiniones expresadas en el presente correo pertenecen =C3=BAnicamente al remitente y no representan necesariamente la opini=C3=B3n del Grupo BBVA."

     "This message is intended exclusively for the adressee and may contain = privileged and confidential information. Please, do not disseminate, copy or distribute = it to third parties who should not receive it. In case you have received it by mistake, please inform the sender and delete the message and attachments = from your system.

     Please keep in mind that e-mails sent by Internet do not allow to guarantee = neither the confidentiality or the integrity of the messages = sent."

    _______________________________________________
    Id-event mailing list
    Id-event@ietf.org
    https://www.ietf.org/mailman/listinfo/id-event

    = --Apple-Mail=_6BADE2F2-6AD6-4075-9A5E-BDDA86BA2F34-- --Apple-Mail=_F7822C8D-EB30-4139-9F9C-69D854E742CD Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJWsHD4AAoJEAHAha6nEqcZcr8QAJvad/T/8BL1OmcZUaZ9U4FV 7dz29yYPTzhGl304hZaFVKaNvuY1I/K9AoKbLVnuCEFtvyti/EEsl1abift3Aene HOi8oEdii6D5C+tm40vze6k8as+pnbYyiUhrPYWVgx8BCtWosnvGlQB+tSXrV16r yiMxomk1hZ0YiEdxplsKfXPQTOl3JlozhvWQHQ4xtQ1SwJetttHJWlZ8L6QW2r4E jVz7P3/M+sBHxwKnAO0NfymNcXC19JOS0UeFVGMOVcCU3G5KGQNuxoSWZHTFkcoM pcnW65TrIsr+6ADmN1CVe6Pveh1+AtGWa92K0WZ7AdML7lTeFB8+wP070B6Bt1Xw sSbOlZrtru6XlX+WVeWxpo4ZfQBGU1D90kwATw9D2+4qKj0oo8YzLPDIjczo44xN CAyy+BKdz3c59qhT/hcrVLItfbO5Z9G8/TpPOfozJ1gLaMbjnwvNqGJnAk9KPi1g 9sD+Iwz9pCvdtzQ9yiGvL1YxlMb+3EuPmP2fBklwvKdRjfm4gbqi1khadh/4fZow IGoWeCpiUA1MmZ4SjLRzK/0PWgZJEUHekOefyRv0lpLUMhT/syyK5wv3DXwaBsOv D2L6WAwW2iTBdBe75SpPWN2PS0qrd8HsBaHlpPnY0MhFMe4HgVkHblVdUzAaK4nz 7Q5L+qJwyeG/5DvAKYy3 =jq/V -----END PGP SIGNATURE----- --Apple-Mail=_F7822C8D-EB30-4139-9F9C-69D854E742CD-- From nobody Wed Feb 3 14:52:34 2016 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63A801B3605 for ; Wed, 3 Feb 2016 14:52:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.501 X-Spam-Level: X-Spam-Status: No, score=-1.501 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 RhJ4iFL2sLrJ for ; Wed, 3 Feb 2016 14:52:27 -0800 (PST) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (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 CDC161B2C76 for ; Wed, 3 Feb 2016 14:52:26 -0800 (PST) X-AuditID: 1209190f-193ff7000000099f-3e-56b284a7991e Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 7F.4E.02463.7A482B65; Wed, 3 Feb 2016 17:52:23 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id u13MqM4d019558; Wed, 3 Feb 2016 17:52:22 -0500 Received: from [192.168.128.48] (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u13MqItJ032756 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 3 Feb 2016 17:52:20 -0500 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/signed; boundary="Apple-Mail=_6A0D185A-D318-44B9-8876-422A57F8E853"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail 2.5.2 From: Justin Richer In-Reply-To: Date: Wed, 3 Feb 2016 17:52:18 -0500 Message-Id: <64D812FD-305F-41F6-9EB7-EEFACF961667@mit.edu> References: <1FDBF3DD-6CEA-4E2E-AA7E-F3C12EB2B32A@wunderlich.ca> <51E9B4BE-F6DF-476A-9D0C-917E2E9B7433@oracle.com> To: Mark Lizar - OCG X-Mailer: Apple Mail (2.2104) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmk+LIzCtJLcpLzFFi42IR4hTV1l3esinM4FKTvEXHgm4miy/X0y0u XD7JbrG4awGLxYL5jewWu7cdYHdg8zjzYSeTx4wdk1g8liz5yeQxc9dtNo+PT2+xeEyYd4El gC2KyyYlNSezLLVI3y6BK6N5SS9rwbONzBW/l7UwNjA2NzF3MXJySAiYSKztOMrYxcjFISTQ xiTR8/wWG4SzgVHiaMtUdgjnFpPE5a61rCAtwgI2Eo1vOlhAbF4BPYlXty6zghQxC0xhlNjS uA9oLgfQXCmJGfsFQGrYBFQlpq9pYQIJcwp4SBw5DxZmEVCRuLlwASNE6wlGifbvE1hAangF rCSWLVaH2LuJWeLj69VsIA0iAsYS12b0sEGcLSux+/cjpgmMArOQnDEL2RkgCWaBJIkZ51pY IWxtiWULX0PFNSX2dy9nwRTXkOj8NhGqXl5i+9s5UHFLicUzb0DV20rc6lvABGHbSTyatoh1 ASP3KkbZlNwq3dzEzJzi1GTd4uTEvLzUIl0TvdzMEr3UlNJNjOD4leTfwfjtoNIhRgEORiUe 3gbPTWFCrIllxZW5hxglOZiURHkLQ4FCfEn5KZUZicUZ8UWlOanFhxhVgHY92rD6AqMUS15+ XqqSCG9PCVAdb0piZVVqUT5MmTQHi5I4rxE/UEogPbEkNTs1tSC1CCYrw8GhJME7uRkoK1iU mp5akZaZU4KQZuLgPMQowcEDNPw6SA1vcUFibnFmOkT+FKOilDjvM5CEAEgiozQPrheUdhPe HjZ9xSgO9JYwbx9IFQ8wZcN1vwIazAQ0eDbfepDBJYkIKakGRrn0j8ttp+3MPpgmsCxxaX7P 8RqLSKX7bXPPHd3Defb+ugld/65L+gfv3VoyX+utY27DkZvtFXKexgl/1u/wi/db8M6iV/Ue a5nyIt8NT57y8JiysCZLM85jnjZ/W83ch1cvntuavmrb5PdHy/r+xK+1U9rPrjV/9wSPO1uE XB7FqWbMcvD/r6rEUpyRaKjFXFScCAAsL2SolgMAAA== Archived-At: Cc: Luis SAIZ GIMENO , John Wunderlich , Phil Hunt , Sarah Squire , id-event@ietf.org Subject: Re: [Id-event] Proposal for Identity Event Standard X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2016 22:52:32 -0000 --Apple-Mail=_6A0D185A-D318-44B9-8876-422A57F8E853 Content-Type: multipart/alternative; boundary="Apple-Mail=_BFBAD2A8-426D-4009-82AC-1403439554EB" --Apple-Mail=_BFBAD2A8-426D-4009-82AC-1403439554EB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I think this is a really great idea. It=E2=80=99s the kind of = abstraction that the =E2=80=9CID Events=E2=80=9D conversation was = pointing towards initially, by my view. I actually see the JWL as the = superset, since the events aren=E2=80=99t always =E2=80=9CID related=E2=80= =9D. I think an important next step would be to start defining payloads for = different use cases. Like: =E2=80=9CI=E2=80=99m an RP and someone just deleted their account with = me, I need to tell the IDP.=E2=80=9D =E2=80=9CI=E2=80=99m an AS and a user just revoked access to an app, I = need to tell the app.=E2=80=9D =E2=80=9CI=E2=80=99m an AS and a user=E2=80=99s account was = compromised, I need to tell all downstream apps to watch out.=E2=80=9D =E2=80=9CI=E2=80=99m an AS and a third-party account was used to access = a user=E2=80=99s resources by their policy (think UMA), I need to record = something and tell the user at their designated endpoint.=E2=80=9D What would each of these strawmen look like as JSON objects inside of a = JWL? Can we start to extract common claims? I don=E2=80=99t think that = JWT is necessarily going to be a good base, but it might be reasonable = to start there. What=E2=80=99s the issuer, subject, and audience of each = statement? How do we record the kind of action? Do we have an ontology = or registry? Lots of very important questions will start to fall out, and hopefully = their answers too, once we start putting JSON to the page. =E2=80=94 Justin > On Feb 2, 2016, at 4:03 AM, Mark Lizar - OCG = wrote: >=20 > Sarah, >=20 > I think it is terrific thinking and very insightful. We are very = interested in this for consent events and the delegation of consent for = a wide array of access control notices and transactions which relate to = consent records. It appears work like this would extend the core of = the consent work we are doing and I think its very well timed, a super = efficient and technically great approach to the set of problems in this = space. >=20 > The JWT logging is brilliant :-) Personally, I think the Consent = and Information Sharing WG would be very happy to see your work move in = this direction and I would hope that we could compliment it. >=20 > Mark Lizar > Executive Director > Open Consent Group >=20 > Email: m.lizar@openconsentgroup.com = > Twitter: @smartopian >=20 >> On 2 Feb 2016, at 08:47, Luis SAIZ GIMENO > wrote: >>=20 >> I'm not an active member in the list but as a customer of this kind = of solutions having an standard way to emit/receive events from/to = IdP/RP is something that we'll appreciate a lot >>=20 >>=20 >> Phil, how it's organized the work in progress you mention? >>=20 >> 2016-02-01 23:03 GMT+01:00 Phil Hunt >: >> What we are working on new is a generic event system that has the = following traits: >>=20 >> * Events (that may be extended for different purposes) that are based = on JWT (JSON Web Token). >> * JWT gives us the ability to have: plain text, signed, and/or = encrypted events that may be transported over different protocols like = HTTP or mobile messaging platforms. >> * A RESTful publish and subscribe system where interested parties may = register interest in certain event types. >> * Many use cases are inter-domain notifications (e.g. RISC and SCIM = events). Others are events for things like mobile apps (a profile or = subscription change). >>=20 >> The generic event spec should be extensible for Sarah=E2=80=99s case = (if not I=E2=80=99d like to find out why). Though I would check in with = the existing types to see if some of the groups like OpenID aren=E2=80=99t= already covering something similar. >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com = phil.hunt@oracle.com = >>=20 >>=20 >>=20 >>=20 >>=20 >>> On Feb 1, 2016, at 12:11 PM, John Wunderlich > wrote: >>>=20 >>> Thanks. >>>=20 >>> It sounds like a useful incremental improvement, as you say, but it = does point to a more interesting general problem down the road. >>>=20 >>> Sincerely, >>> John Wunderlich >>> (@PrivacyCDN) >>>=20 >>> = >>>=20 >>>=20 >>> Privacist & PbD Ambassador = >>>=20 >>>=20 >>>=20 >>>=20 >>>> On Feb 1, 2016, at 15:09, Sarah Squire > wrote: >>>>=20 >>>> Hi John, >>>>=20 >>>> Good questions. I'm not proposing a distributed database or = anything blockchain-like. I am merely suggesting, as you say, that we = add a few more prescribed transactions and an endpoint for them to the = existing standards. These seem to be high-value communications that = currently aren't happening or are happening out of band in = non-standardized communications. >>>>=20 >>>> There may well be additional categories. I'd be curious if other = folks on this list have more use cases that this standard could address. >>>>=20 >>>> Sarah >>>>=20 >>>> Sarah Squire >>>> Engage Identity >>>> http://engageidentity.com >>>> On Mon, Feb 1, 2016 at 11:56 AM, John Wunderlich = > wrote: >>>> Sarah; >>>>=20 >>>> Are you replicating the problem of =E2=80=9C..no language to talk = to each other outside of prescribed transactions=E2=80=9D at a higher = level by prescribing a set of four categories? It seems an appropriate = solution to the cases you describe, but are there other cases that would = necessitate additional categories? When I read the first part of your = strawman, I thought your reference to a JSON Web Log was starting down = the road to a distributed database (must still have blockchain on my = mind from the last IIW). Or am I misunderstanding and is what you are = proposing a semantic solution to the problem you pose? >>>>=20 >>>> Sincerely, >>>> John Wunderlich >>>> (@PrivacyCDN) >>>>=20 >>>> = >>>>=20 >>>>=20 >>>> Privacist & PbD Ambassador = >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>> On Feb 1, 2016, at 12:35, Sarah Squire > wrote: >>>>>=20 >>>>> Hi all, >>>>>=20 >>>>> I=E2=80=99ve been mulling the idea of identity events and have run = into several situations with different clients where they could be = useful. I have a strawman that I would love for you all to take a few = torches to. >>>>>=20 >>>>> I propose that we create a new standard for a JSON Web Log, or = JWL. >>>>>=20 >>>>> The problem I=E2=80=99m running into is that in distributed access = management protocols like OAuth and UMA, different ecosystem parties are = often in different security domains and have no language to talk to each = other outside of prescribed transactions. There are many cases in which = only one party has a log of an identity event, and it would be helpful = if they had some way to transmit that log to other parties in the = ecosystem. >>>>>=20 >>>>> Here is a list of a few things that a relying party might want to = say to an identity provider: >>>>>=20 >>>>> This user=E2=80=99s behavior is inconsistent with past heuristics = and I suspect fraud >>>>> the RP did parallel authentication of a second factor (e.g. My = employee Susan has verified that this user matches (or does not match) = the photo on file at the IdP) >>>>> Here is a privacy policy that this user consented to >>>>>=20 >>>>> Here is a list of a few things that an identity provider might = want to say to a relying party: >>>>>=20 >>>>> This user=E2=80=99s email changed since the last time you called = the UserInfo endpoint >>>>> A user account we have authenticated for you in the past has been = compromised >>>>> This user has revoked your access token >>>>>=20 >>>>> My proposal is that a JWL standard be developed based on the form = of a JWT, though with some different fields. It should require iss, sub, = aud, and iat, and the optional fields I think would fall into four = categories: suspected fraud, userinfo update, consent information, and = parallel authentication. Both RPs and IdPs would implement a JWL = endpoint to receive JWLs from other members of the ecosystem. >>>>>=20 >>>>> Thoughts? Would this be helpful? >>>>>=20 >>>>> Sarah >>>>>=20 >>>>> Sarah Squire >>>>> Engage Identity >>>>> http://engageidentity.com = ______________________________________________= _ >>>>> Id-event mailing list >>>>> Id-event@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/id-event = >>>>=20 >>>>=20 >>>>=20 >>>> This email and any files transmitted with it are confidential and = intended solely for the use of the individual or entity to whom they are = addressed. If you have received this email in error please notify the = system manager. This message contains confidential information and is = intended only for the individual named. If you are not the named = addressee you should not disseminate, distribute or copy this e-mail. = Please notify the sender immediately by e-mail if you have received this = e-mail by mistake and delete this e-mail from your system. If you are = not the intended recipient you are notified that disclosing, copying, = distributing or taking any action in reliance on the contents of this = information is strictly prohibited. >>>>=20 >>>=20 >>>=20 >>>=20 >>> This email and any files transmitted with it are confidential and = intended solely for the use of the individual or entity to whom they are = addressed. If you have received this email in error please notify the = system manager. This message contains confidential information and is = intended only for the individual named. If you are not the named = addressee you should not disseminate, distribute or copy this e-mail. = Please notify the sender immediately by e-mail if you have received this = e-mail by mistake and delete this e-mail from your system. If you are = not the intended recipient you are notified that disclosing, copying, = distributing or taking any action in reliance on the contents of this = information is strictly prohibited. >>> _______________________________________________ >>> Id-event mailing list >>> Id-event@ietf.org >>> https://www.ietf.org/mailman/listinfo/id-event = >>=20 >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://www.ietf.org/mailman/listinfo/id-event = >>=20 >>=20 >>=20 >>=20 >> -- >> BBVA >> Luis Saiz Gimeno >> Innovation in Security >> M=C3=B3vil +34 609703264 - Tel. +34 918073152 - luis.saiz@bbva.com = >> Engineering - Architecture & Global Deployment =E2=80=93 Monforte de = Lemos, s/n, 28029 >> Maps: = https://www.google.es/maps/place/Av.+de+Monforte+de+Lemos,+28,+28029+Madri= d/ = >> Antes de imprimir este mensaje, por favor comprueba que es necesario = hacerlo. Before you print this message please consider if it is really = necessary. >>=20 >> "Este mensaje est=C3=A1 dirigido de manera exclusiva a su = destinatario y puede contener informaci=C3=B3n privada y confidencial. = No lo reenv=C3=ADe, copie o distribuya a terceros que no deban conocer = su contenido. En caso de haberlo recibido por error, rogamos lo = notifique al remitente y proceda a su borrado, as=C3=AD como al de = cualquier documento que pudiera adjuntarse. >>=20 >> Por favor tenga en cuenta que los correos enviados v=C3=ADa Internet = no permiten garantizar la confidencialidad de los mensajes ni su = transmisi=C3=B3n de forma =C3=ADntegra. >>=20 >> Las opiniones expresadas en el presente correo pertenecen = =C3=BAnicamente al remitente y no representan necesariamente la opini=C3=B3= n del Grupo BBVA." >>=20 >> "This message is intended exclusively for the adressee and may = contain privileged and confidential information. Please, do not = disseminate, copy or distribute it to third parties who should not = receive it. In case you have received it by mistake, please inform the = sender and delete the message and attachments from your system. >>=20 >> Please keep in mind that e-mails sent by Internet do not allow to = guarantee neither the confidentiality or the integrity of the messages = sent." >>=20 >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://www.ietf.org/mailman/listinfo/id-event >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event --Apple-Mail=_BFBAD2A8-426D-4009-82AC-1403439554EB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I think this is a really great idea. It=E2=80=99s the kind of = abstraction that the =E2=80=9CID Events=E2=80=9D conversation was = pointing towards initially, by my view. I actually see the JWL as the = superset, since the events aren=E2=80=99t always =E2=80=9CID = related=E2=80=9D. 

    I think an important next step would be to start defining = payloads for different use cases. Like:


     =E2=80=9CI=E2=80=99m an RP and someone just deleted = their account with me, I need to tell the IDP.=E2=80=9D

     =E2=80=9CI=E2=80=99m= an AS and a user just revoked access to an app, I need to tell the = app.=E2=80=9D

     =E2=80=9CI=E2=80=99m an AS and a user=E2=80=99s account = was compromised, I need to tell all downstream apps to watch = out.=E2=80=9D

     =E2=80=9CI=E2=80=99m an AS and a third-party account = was used to access a user=E2=80=99s resources by their policy (think = UMA), I need to record something and tell the user at their designated = endpoint.=E2=80=9D


    What would each of these = strawmen look like as JSON objects inside of a JWL? Can we start to = extract common claims? I don=E2=80=99t think that JWT is necessarily = going to be a good base, but it might be reasonable to start there. = What=E2=80=99s the issuer, subject, and audience of each statement? How = do we record the kind of action? Do we have an ontology or = registry?

    Lots = of very important questions will start to fall out, and hopefully their = answers too, once we start putting JSON to the page.

     =E2=80=94 = Justin


    On = Feb 2, 2016, at 4:03 AM, Mark Lizar - OCG <m.lizar@openconsentgroup.com> wrote:

    Sarah, 

    I think it is terrific thinking and very insightful.  We = are very interested in this for consent events and the delegation of = consent for a wide array of access control notices and transactions = which relate to consent records.  It appears work like this =  would extend the core of the consent work we are doing and I think = its very well timed, a super efficient and technically great approach to = the set of problems in this space. 

    The JWT logging is brilliant :-)   =   Personally, I think the Consent and Information Sharing  WG = would be very happy to see your work move in this direction and I would = hope that we could compliment it. 

    Mark Lizar
    Executive Director
    Open Consent Group

    Email: m.lizar@openconsentgroup.com
    Twitter: @smartopian

    On 2 Feb 2016, at 08:47, Luis = SAIZ GIMENO <luis.saiz@bbva.com> wrote:

    I'm not an active member in the list but as a customer of = this kind of solutions having an standard way to emit/receive events = from/to IdP/RP is something that we'll appreciate a lot

    Phil, how it's organized the work in progress you = mention?

    2016-02-01 23:03 GMT+01:00 Phil Hunt <phil.hunt@oracle.com>:
    What we are working on new is = a generic event system that has the following traits:

    * Events (that may be extended for = different purposes) that are based on JWT (JSON Web Token).
    * JWT gives us the ability to have: plain text, signed, = and/or encrypted events that may be transported over different protocols = like HTTP or mobile messaging platforms.
    * A = RESTful publish and subscribe system where interested parties may = register interest in certain event types.
    * Many = use cases are inter-domain notifications (e.g. RISC and SCIM = events).  Others are events for things like mobile apps (a profile = or subscription change).

    The generic event spec should be extensible for Sarah=E2=80=99s= case (if not I=E2=80=99d like to find out why). Though I would check in = with the existing types to see if some of the groups like OpenID = aren=E2=80=99t already covering something similar.

    Phil

    @independentid
    www.independentid.com
    phil.hunt@oracle.com




    =

    On Feb 1, 2016, at 12:11 PM, John Wunderlich = <john@wunderlich.ca> wrote:

    Thanks.

    It sounds like a useful incremental = improvement, as you say, but it does point to a more interesting general = problem down the road.

    Sincerely,
    John Wunderlich
    (@PrivacyCDN)

    On Feb 1, 2016, at 15:09, Sarah Squire <sarah@engageidentity.com> wrote:

    Hi = John,

    Good questions. I'm not = proposing a distributed database or anything blockchain-like. I am = merely suggesting, as you say, that we add a few more prescribed = transactions and an endpoint for them to the existing standards. These = seem to be high-value communications that currently aren't happening or = are happening out of band in non-standardized communications.

    There may well be = additional categories. I'd be curious if other folks on this list have = more use cases that this standard could address.

    Sarah

    Sarah Squire
    Engage Identity
    http://engageidentity.com

    On Mon, Feb 1, 2016 at 11:56 AM, = John Wunderlich <john@wunderlich.ca> wrote:
    Sarah;

    Are = you replicating the problem of =E2=80=9C..no language to talk to each = other outside of prescribed transactions=E2=80=9D at a higher level by = prescribing a set of four categories? It seems an appropriate solution = to the cases you describe, but are there other cases that would = necessitate additional categories? When I read the first part of your = strawman, I thought your reference to a JSON Web Log was starting down = the road to a distributed database (must still have blockchain on my = mind from the last IIW). Or am I misunderstanding and is what you are = proposing a semantic solution to the problem you pose?

    Sincerely,
    John Wunderlich
    (@PrivacyCDN)

    On Feb 1, 2016, at 12:35, Sarah Squire <sarah@engageidentity.com> wrote:

    Hi = all,

    I=E2=80=99ve = been mulling the idea of identity events and have run into several = situations with different clients where they could be useful. I have a = strawman that I would love for you all to take a few torches = to.

    I propose = that we create a new standard for a JSON Web Log, or = JWL.

    The problem = I=E2=80=99m running into is that in distributed access management = protocols like OAuth and UMA, different ecosystem parties are often in = different security domains and have no language to talk to each other = outside of prescribed transactions. There are many cases in which only = one party has a log of an identity event, and it would be helpful if = they had some way to transmit that log to other parties in the = ecosystem.

    Here is a = list of a few things that a relying party might want to say to an = identity provider:

    • This user=E2=80=99s behavior is = inconsistent with past heuristics and I suspect = fraud
    • the RP did parallel = authentication of a second factor (e.g. My employee Susan has verified = that this user matches (or does not match) the photo on file at the = IdP)
    • Here is a privacy policy that = this user consented to

    Here is a = list of a few things that an identity provider might want to say to a = relying party:

    • This user=E2=80=99s email = changed since the last time you called the UserInfo = endpoint
    • A user account we have = authenticated for you in the past has been = compromised
    • This user has revoked your = access token

    My proposal = is that a JWL standard be developed based on the form of a JWT, though = with some different fields. It should require iss, sub, aud, and iat, = and the optional fields I think would fall into four categories: = suspected fraud, userinfo update, consent information, and parallel = authentication. Both RPs and IdPs would implement a JWL endpoint to = receive JWLs from other members of the ecosystem.

    Thoughts? = Would this be helpful?

    Sarah =

    Sarah Squire
    Engage Identity
    http://engageidentity.com
    _______________________________________________
    Id-event mailing list
    Id-event@ietf.org
    https://www.ietf.org/mailman/listinfo/id-event



    This email and any files = transmitted with it are confidential and intended solely for the use of = the individual or entity to whom they are addressed. If you have = received this email in error please notify the system manager. This = message contains confidential information and is intended only for the = individual named. If you are not the named addressee you should not = disseminate, distribute or copy this e-mail. Please notify the sender = immediately by e-mail if you have received this e-mail by mistake and = delete this e-mail from your system. If you are not the intended = recipient you are notified that disclosing, copying, distributing or = taking any action in reliance on the contents of this information is = strictly prohibited.




    This email and any files transmitted with it are confidential = and intended solely for the use of the individual or entity to whom they = are addressed. If you have received this email in error please notify = the system manager. This message contains confidential information and = is intended only for the individual named. If you are not the named = addressee you should not disseminate, distribute or copy this e-mail. = Please notify the sender immediately by e-mail if you have received this = e-mail by mistake and delete this e-mail from your system. If you are = not the intended recipient you are notified that disclosing, copying, = distributing or taking any action in reliance on the contents of this = information is strictly prohibited.
    <signature.asc>_______________________________________________
    Id-event mailing list
    Id-event@ietf.org
    https://www.ietf.org/mailman/listinfo/id-event
    =


    _______________________________________________
    Id-event mailing list
    Id-event@ietf.org
    https://www.ietf.org/mailman/listinfo/id-event




    --
    BBVA
    Luis = Saiz Gimeno
    Innovation in = Security
    M=C3=B3vil +34 609703264 - Tel. = +34 918073152 - luis.saiz@bbva.com
    Engineering - = Architecture & Global Deployment =E2=80=93 Monforte de Lemos, s/n, = 28029
    Maps: https://www.google.es/maps/place/Av.+de+Monforte+de+Lemos,+28,+= 28029+Madrid/
    Antes de imprimir este mensaje, por favor comprueba que es = necesario hacerlo. Before you print this message please consider if it is really = necessary.

    "Este mensaje est=C3=A1 dirigido de manera exclusiva a su destinatario y puede contener = informaci=C3=B3n privada y confidencial. No lo reenv=C3=ADe, copie o distribuya a = terceros que no deban conocer su contenido. En caso de haberlo recibido por = error,  rogamos lo notifique al remitente y proceda a su borrado, as=C3=AD como al de = cualquier documento que pudiera adjuntarse.

     Por favor tenga en cuenta que los correos enviados v=C3=ADa Internet no permiten garantizar la = confidencialidad de los mensajes ni su transmisi=C3=B3n de forma =C3=ADntegra.

     Las opiniones expresadas en el presente correo pertenecen =C3=BAnicamente al remitente y no representan necesariamente la opini=C3=B3n del Grupo BBVA."

     "This message is intended exclusively for the adressee and may contain = privileged and confidential information. Please, do not disseminate, copy or distribute = it to third parties who should not receive it. In case you have received it by mistake, please inform the sender and delete the message and attachments = from your system.

     Please keep in mind that e-mails sent by Internet do not allow to guarantee = neither the confidentiality or the integrity of the messages = sent."

    _______________________________________________
    Id-event mailing list
    Id-event@ietf.org
    https://www.ietf.org/mailman/listinfo/id-event

    _______________________________________________
    Id-event mailing list
    Id-event@ietf.org
    https://www.ietf.org/mailman/listinfo/id-event

    = --Apple-Mail=_BFBAD2A8-426D-4009-82AC-1403439554EB-- --Apple-Mail=_6A0D185A-D318-44B9-8876-422A57F8E853 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----- iQEcBAEBCAAGBQJWsoSiAAoJEDPAngkbd+w9pnIIAIoRN1PWiDcKfrynb6cVKm63 NMCqRkyIdvKQ9E4WnLPdpBnb9+R/OmTaX46n4otAfgZ6pNjaTGJWrj3aw3hfo8rO UJrXd/tSo6pvFXtWFBI2h7OjcO7exeypkQgGXJur+xI2KJzdWu4OuuTWNa5MhUOJ zqmgscMbomq2vQbDnWH54oe9lirC8XPe1T7Zt672j0jl8IDQnxJIeXThDAfWiUa/ qaCb/66uJIkhXuceqoWKjB0VgrBozqB4dpDgDADyaa8wSpNuG6xO9uCYrWuAQkf5 3wkD+94/b4SUe1LAljGl5U0EWl8UaZMVqPh2jHBz7+hmZOkrxTP/wjYZGJluRUI= =UNJ4 -----END PGP SIGNATURE----- --Apple-Mail=_6A0D185A-D318-44B9-8876-422A57F8E853-- From nobody Wed Feb 3 15:10:12 2016 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EDD51B3644 for ; Wed, 3 Feb 2016 15:10:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 LbcqUDcpWEwC for ; Wed, 3 Feb 2016 15:10:06 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (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 27DDB1B3646 for ; Wed, 3 Feb 2016 15:10:06 -0800 (PST) Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u13N9vc3024208 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 3 Feb 2016 23:09:57 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u13N9vgS023900 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 3 Feb 2016 23:09:57 GMT Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id u13N9ufm021627; Wed, 3 Feb 2016 23:09:56 GMT Received: from [10.0.1.3] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 03 Feb 2016 15:09:55 -0800 Content-Type: multipart/alternative; boundary=Apple-Mail-3EC84EAC-3583-4F65-A0F2-C19F6A760862 Mime-Version: 1.0 (1.0) From: "Phil Hunt (IDM)" X-Mailer: iPhone Mail (13D15) In-Reply-To: <64D812FD-305F-41F6-9EB7-EEFACF961667@mit.edu> Date: Wed, 3 Feb 2016 15:09:53 -0800 Content-Transfer-Encoding: 7bit Message-Id: <876356CB-3663-4C58-9DAC-546679EE285B@oracle.com> References: <1FDBF3DD-6CEA-4E2E-AA7E-F3C12EB2B32A@wunderlich.ca> <51E9B4BE-F6DF-476A-9D0C-917E2E9B7433@oracle.com> <64D812FD-305F-41F6-9EB7-EEFACF961667@mit.edu> To: Justin Richer X-Source-IP: aserv0021.oracle.com [141.146.126.233] Archived-At: Cc: Luis SAIZ GIMENO , John Wunderlich , Mark Lizar - OCG , Sarah Squire , id-event@ietf.org Subject: Re: [Id-event] Proposal for Identity Event Standard X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2016 23:10:11 -0000 --Apple-Mail-3EC84EAC-3583-4F65-A0F2-C19F6A760862 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable +1 Phil > On Feb 3, 2016, at 14:52, Justin Richer wrote: >=20 > I think this is a really great idea. It=E2=80=99s the kind of abstraction t= hat the =E2=80=9CID Events=E2=80=9D conversation was pointing towards initia= lly, by my view. I actually see the JWL as the superset, since the events ar= en=E2=80=99t always =E2=80=9CID related=E2=80=9D.=20 >=20 > I think an important next step would be to start defining payloads for dif= ferent use cases. Like: >=20 >=20 > =E2=80=9CI=E2=80=99m an RP and someone just deleted their account with me= , I need to tell the IDP.=E2=80=9D >=20 > =E2=80=9CI=E2=80=99m an AS and a user just revoked access to an app, I ne= ed to tell the app.=E2=80=9D >=20 > =E2=80=9CI=E2=80=99m an AS and a user=E2=80=99s account was compromised, I= need to tell all downstream apps to watch out.=E2=80=9D >=20 > =E2=80=9CI=E2=80=99m an AS and a third-party account was used to access a= user=E2=80=99s resources by their policy (think UMA), I need to record some= thing and tell the user at their designated endpoint.=E2=80=9D >=20 >=20 > What would each of these strawmen look like as JSON objects inside of a JW= L? Can we start to extract common claims? I don=E2=80=99t think that JWT is n= ecessarily going to be a good base, but it might be reasonable to start ther= e. What=E2=80=99s the issuer, subject, and audience of each statement? How d= o we record the kind of action? Do we have an ontology or registry? >=20 > Lots of very important questions will start to fall out, and hopefully the= ir answers too, once we start putting JSON to the page. >=20 > =E2=80=94 Justin >=20 >=20 >> On Feb 2, 2016, at 4:03 AM, Mark Lizar - OCG wrote: >>=20 >> Sarah,=20 >>=20 >> I think it is terrific thinking and very insightful. We are very interes= ted in this for consent events and the delegation of consent for a wide arra= y of access control notices and transactions which relate to consent records= . It appears work like this would extend the core of the consent work we a= re doing and I think its very well timed, a super efficient and technically g= reat approach to the set of problems in this space.=20 >>=20 >> The JWT logging is brilliant :-) Personally, I think the Consent and I= nformation Sharing WG would be very happy to see your work move in this dir= ection and I would hope that we could compliment it.=20 >>=20 >> Mark Lizar >> Executive Director >> Open Consent Group >>=20 >> Email: m.lizar@openconsentgroup.com >> Twitter: @smartopian >>=20 >>> On 2 Feb 2016, at 08:47, Luis SAIZ GIMENO wrote: >>>=20 >>> I'm not an active member in the list but as a customer of this kind of s= olutions having an standard way to emit/receive events from/to IdP/RP is som= ething that we'll appreciate a lot >>>=20 >>>=20 >>> Phil, how it's organized the work in progress you mention? >>>=20 >>> 2016-02-01 23:03 GMT+01:00 Phil Hunt : >>>> What we are working on new is a generic event system that has the follo= wing traits: >>>>=20 >>>> * Events (that may be extended for different purposes) that are based o= n JWT (JSON Web Token). >>>> * JWT gives us the ability to have: plain text, signed, and/or encrypte= d events that may be transported over different protocols like HTTP or mobil= e messaging platforms. >>>> * A RESTful publish and subscribe system where interested parties may r= egister interest in certain event types. >>>> * Many use cases are inter-domain notifications (e.g. RISC and SCIM eve= nts). Others are events for things like mobile apps (a profile or subscript= ion change). >>>>=20 >>>> The generic event spec should be extensible for Sarah=E2=80=99s case (i= f not I=E2=80=99d like to find out why). Though I would check in with the ex= isting types to see if some of the groups like OpenID aren=E2=80=99t already= covering something similar. >>>>=20 >>>> Phil >>>>=20 >>>> @independentid >>>> www.independentid.com >>>> phil.hunt@oracle.com >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>> On Feb 1, 2016, at 12:11 PM, John Wunderlich wrot= e: >>>>>=20 >>>>> Thanks. >>>>>=20 >>>>> It sounds like a useful incremental improvement, as you say, but it do= es point to a more interesting general problem down the road. >>>>>=20 >>>>> Sincerely, >>>>> John Wunderlich >>>>> (@PrivacyCDN) >>>>>=20 >>>>> >>>>>=20 >>>>>=20 >>>>> Privacist & PbD Ambassador >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>> On Feb 1, 2016, at 15:09, Sarah Squire wro= te: >>>>>>=20 >>>>>> Hi John, >>>>>>=20 >>>>>> Good questions. I'm not proposing a distributed database or anything b= lockchain-like. I am merely suggesting, as you say, that we add a few more p= rescribed transactions and an endpoint for them to the existing standards. T= hese seem to be high-value communications that currently aren't happening or= are happening out of band in non-standardized communications. >>>>>>=20 >>>>>> There may well be additional categories. I'd be curious if other folk= s on this list have more use cases that this standard could address. >>>>>>=20 >>>>>> Sarah >>>>>>=20 >>>>>> Sarah Squire >>>>>> Engage Identity >>>>>> http://engageidentity.com >>>>>>=20 >>>>>>> On Mon, Feb 1, 2016 at 11:56 AM, John Wunderlich wrote: >>>>>>> Sarah; >>>>>>>=20 >>>>>>> Are you replicating the problem of =E2=80=9C..no language to talk to= each other outside of prescribed transactions=E2=80=9D at a higher level by= prescribing a set of four categories? It seems an appropriate solution to t= he cases you describe, but are there other cases that would necessitate addi= tional categories? When I read the first part of your strawman, I thought yo= ur reference to a JSON Web Log was starting down the road to a distributed d= atabase (must still have blockchain on my mind from the last IIW). Or am I m= isunderstanding and is what you are proposing a semantic solution to the pro= blem you pose? >>>>>>>=20 >>>>>>> Sincerely, >>>>>>> John Wunderlich >>>>>>> (@PrivacyCDN) >>>>>>>=20 >>>>>>> >>>>>>>=20 >>>>>>>=20 >>>>>>> Privacist & PbD Ambassador >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>> On Feb 1, 2016, at 12:35, Sarah Squire w= rote: >>>>>>>>=20 >>>>>>>> Hi all, >>>>>>>>=20 >>>>>>>> I=E2=80=99ve been mulling the idea of identity events and have run i= nto several situations with different clients where they could be useful. I h= ave a strawman that I would love for you all to take a few torches to. >>>>>>>>=20 >>>>>>>> I propose that we create a new standard for a JSON Web Log, or JWL.= >>>>>>>>=20 >>>>>>>> The problem I=E2=80=99m running into is that in distributed access m= anagement protocols like OAuth and UMA, different ecosystem parties are ofte= n in different security domains and have no language to talk to each other o= utside of prescribed transactions. There are many cases in which only one pa= rty has a log of an identity event, and it would be helpful if they had some= way to transmit that log to other parties in the ecosystem. >>>>>>>>=20 >>>>>>>> Here is a list of a few things that a relying party might want to s= ay to an identity provider: >>>>>>>>=20 >>>>>>>> This user=E2=80=99s behavior is inconsistent with past heuristics a= nd I suspect fraud >>>>>>>> the RP did parallel authentication of a second factor (e.g. My empl= oyee Susan has verified that this user matches (or does not match) the photo= on file at the IdP) >>>>>>>> Here is a privacy policy that this user consented to >>>>>>>>=20 >>>>>>>> Here is a list of a few things that an identity provider might want= to say to a relying party: >>>>>>>>=20 >>>>>>>> This user=E2=80=99s email changed since the last time you called th= e UserInfo endpoint >>>>>>>> A user account we have authenticated for you in the past has been c= ompromised >>>>>>>> This user has revoked your access token >>>>>>>>=20 >>>>>>>> My proposal is that a JWL standard be developed based on the form o= f a JWT, though with some different fields. It should require iss, sub, aud,= and iat, and the optional fields I think would fall into four categories: s= uspected fraud, userinfo update, consent information, and parallel authentic= ation. Both RPs and IdPs would implement a JWL endpoint to receive JWLs from= other members of the ecosystem. >>>>>>>>=20 >>>>>>>> Thoughts? Would this be helpful? >>>>>>>>=20 >>>>>>>> Sarah=20 >>>>>>>>=20 >>>>>>>> Sarah Squire >>>>>>>> Engage Identity >>>>>>>> http://engageidentity.com >>>>>>>> _______________________________________________ >>>>>>>> Id-event mailing list >>>>>>>> Id-event@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/id-event >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> This email and any files transmitted with it are confidential and in= tended solely for the use of the individual or entity to whom they are addre= ssed. If you have received this email in error please notify the system mana= ger. This message contains confidential information and is intended only for= the individual named. If you are not the named addressee you should not dis= seminate, distribute or copy this e-mail. Please notify the sender immediate= ly by e-mail if you have received this e-mail by mistake and delete this e-m= ail from your system. If you are not the intended recipient you are notified= that disclosing, copying, distributing or taking any action in reliance on t= he contents of this information is strictly prohibited. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> This email and any files transmitted with it are confidential and inte= nded solely for the use of the individual or entity to whom they are address= ed. If you have received this email in error please notify the system manage= r. This message contains confidential information and is intended only for t= he individual named. If you are not the named addressee you should not disse= minate, distribute or copy this e-mail. Please notify the sender immediately= by e-mail if you have received this e-mail by mistake and delete this e-mai= l from your system. If you are not the intended recipient you are notified t= hat disclosing, copying, distributing or taking any action in reliance on th= e contents of this information is strictly prohibited. >>>>> _______________________________________________ >>>>> Id-event mailing list >>>>> Id-event@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/id-event >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> Id-event mailing list >>>> Id-event@ietf.org >>>> https://www.ietf.org/mailman/listinfo/id-event >>>=20 >>>=20 >>>=20 >>> --=20 >>> BBVA >>> Luis Saiz Gimeno >>> Innovation in Security >>> M=C3=B3vil +34 609703264 - Tel. +34 918073152 - luis.saiz@bbva.com >>> Engineering - Architecture & Global Deployment =E2=80=93 Monforte de Lem= os, s/n, 28029 >>> Maps: https://www.google.es/maps/place/Av.+de+Monforte+de+Lemos,+28,+280= 29+Madrid/ >>> Antes de imprimir este mensaje, por favor comprueba que es necesario hac= erlo. Before you print this message please consider if it is really necessar= y. >>>=20 >>> "Este mensaje est=C3=A1 dirigido de manera exclusiva a su destinatario y= puede contener informaci=C3=B3n privada y confidencial. No lo reenv=C3=ADe,= copie o distribuya a terceros que no deban conocer su contenido. En caso de= haberlo recibido por error, rogamos lo notifique al remitente y proceda a s= u borrado, as=C3=AD como al de cualquier documento que pudiera adjuntarse. >>>=20 >>> Por favor tenga en cuenta que los correos enviados v=C3=ADa Internet no= permiten garantizar la confidencialidad de los mensajes ni su transmisi=C3=B3= n de forma =C3=ADntegra. >>>=20 >>> Las opiniones expresadas en el presente correo pertenecen =C3=BAnicamen= te al remitente y no representan necesariamente la opini=C3=B3n del Grupo BB= VA." >>>=20 >>> "This message is intended exclusively for the adressee and may contain p= rivileged and confidential information. Please, do not disseminate, copy or d= istribute it to third parties who should not receive it. In case you have re= ceived it by mistake, please inform the sender and delete the message and at= tachments from your system. >>>=20 >>> Please keep in mind that e-mails sent by Internet do not allow to guara= ntee neither the confidentiality or the integrity of the messages sent." >>>=20 >>> _______________________________________________ >>> Id-event mailing list >>> Id-event@ietf.org >>> https://www.ietf.org/mailman/listinfo/id-event >>=20 >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://www.ietf.org/mailman/listinfo/id-event >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event --Apple-Mail-3EC84EAC-3583-4F65-A0F2-C19F6A760862 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
    +1

    Phil

    On Feb 3,= 2016, at 14:52, Justin Richer <jriche= r@mit.edu> wrote:

    I think thi= s is a really great idea. It=E2=80=99s the kind of abstraction that the =E2=80= =9CID Events=E2=80=9D conversation was pointing towards initially, by my vie= w. I actually see the JWL as the superset, since the events aren=E2=80=99t a= lways =E2=80=9CID related=E2=80=9D. 

    I think an important next step would be to start defining p= ayloads for different use cases. Like:

    <= /div>

     =E2=80=9CI=E2= =80=99m an RP and someone just deleted their account with me, I need to tell= the IDP.=E2=80=9D

     =E2=80=9CI=E2=80=99m an AS and a user just revoked access to an app, I= need to tell the app.=E2=80=9D

     =E2=80=9CI=E2=80=99m an AS and a user=E2=80=99s account w= as compromised, I need to tell all downstream apps to watch out.=E2=80=9D

     =E2=80=9CI=E2=80= =99m an AS and a third-party account was used to access a user=E2=80=99s res= ources by their policy (think UMA), I need to record something and tell the u= ser at their designated endpoint.=E2=80=9D


    What would eac= h of these strawmen look like as JSON objects inside of a JWL? Can we start t= o extract common claims? I don=E2=80=99t think that JWT is necessarily going= to be a good base, but it might be reasonable to start there. What=E2=80=99= s the issuer, subject, and audience of each statement? How do we record the k= ind of action? Do we have an ontology or registry?

    Lots of very important questions will start t= o fall out, and hopefully their answers too, once we start putting JSON to t= he page.

     =E2= =80=94 Justin


    On Feb 2= , 2016, at 4:03 AM, Mark Lizar - OCG <m.lizar@openconsentgroup.com> wrote:
    Sarah, 

    I think it is terrific thinking and very insightful= .  We are very interested in this for consent events and the delegation= of consent for a wide array of access control notices and transactions whic= h relate to consent records.  It appears work like this  would ext= end the core of the consent work we are doing and I think its very well time= d, a super efficient and technically great approach to the set of problems i= n this space. 

    The J= WT logging is brilliant :-)     Personally, I think the Consent an= d Information Sharing  WG would be very happy to see your work move in t= his direction and I would hope that we could compliment it. 

    Mark Lizar
    Exe= cutive Director
    Open Consent Group

    Email: m.lizar@openconsentgroup.com
    Twitter: @smartopian

    On 2 Feb 2016, at 08:47, Luis SAIZ GIMENO <luis.saiz@bbva.com> wrote:

    I'm not an active member in the list but as a customer of this kind of so= lutions having an standard way to emit/receive events from/to IdP/RP is some= thing that we'll appreciate a lot


    Phil, how it's organized the w= ork in progress you mention?

    2016-02-01 23:03 GMT+01:00 Phil Hunt <phil.hunt@oracle.com>:
    What w= e are working on new is a generic event system that has the following traits= :

    * Events (that may be e= xtended for different purposes) that are based on JWT (JSON Web Token).
    * JWT gives us the ability to have: plain text, signed, and= /or encrypted events that may be transported over different protocols like H= TTP or mobile messaging platforms.
    * A RESTful publish a= nd subscribe system where interested parties may register interest in certai= n event types.
    * Many use cases are inter-domain notifi= cations (e.g. RISC and SCIM events).  Others are events for things like= mobile apps (a profile or subscription change).

    The generic event spec should be extensible f= or Sarah=E2=80=99s case (if not I=E2=80=99d like to find out why). Though I w= ould check in with the existing types to see if some of the groups like Open= ID aren=E2=80=99t already covering something similar.
    <= br class=3D"">
    Phil

    @= independentid
    www.independentid.com
    phil.hunt@oracle.com

    =



    On Feb 1, 2016, at 12:11 PM, John Wunderlich <john@wunder= lich.ca> wrote:

    Thanks.

    It sounds like a useful incremental improvement, as you say, but= it does point to a more interesting general problem down the road.

    S= incerely,
    John Wunderl= ich
    (@PrivacyCDN)

    <PastedGraphic-4.tiff>=     <= /a>


    Privacist & PbD Ambassador




    On Feb 1, 2016, at 15:09, Sarah Squire <sarah@engageidentity.co= m> wrote:

    Hi John,

    Good q= uestions. I'm not proposing a distributed database or anything blockchain-li= ke. I am merely suggesting, as you say, that we add a few more prescribed tr= ansactions and an endpoint for them to the existing standards. These seem to= be high-value communications that currently aren't happening or are happeni= ng out of band in non-standardized communications.

    There may well be additional categories. I'd be cur= ious if other folks on this list have more use cases that this standard coul= d address.

    Sarah

    Sarah Squire
    Engage Identity

    On Mon, Feb 1, 2016 at 11:= 56 AM, John Wunderlich <jo= hn@wunderlich.ca> wrote:
    Sarah;
    Are you replicating the p= roblem of =E2=80=9C..no language to talk to each other outside of prescribed= transactions=E2=80=9D at a higher level by prescribing a set of four catego= ries? It seems an appropriate solution to the cases you describe, but are th= ere other cases that would necessitate additional categories? When I read th= e first part of your strawman, I thought your reference to a JSON Web Log wa= s starting down the road to a distributed database (must still have blockcha= in on my mind from the last IIW). Or am I misunderstanding and is what you a= re proposing a semantic solution to the problem you pose?

    Since= rely,
    <= font class=3D"">John Wunderlich<= /div>
    (@PrivacyCDN= )

    <PastedGraphic-4.tiff>


    Privacist & PbD Ambassador



    <= /div>

    On Feb 1, 201= 6, at 12:35, Sarah Squire <sarah@engageidentity.com> wrote:

    Hi all,

    I=E2=80=99ve been mulling th= e idea of identity events and have run into several situations with differen= t clients where they could be useful. I have a strawman that I would love fo= r you all to take a few torches to.

    I propose that we create a n= ew standard for a JSON Web Log, or JWL.

    The problem I=E2=80=99= m running into is that in distributed access management protocols like OAuth= and UMA, different ecosystem parties are often in different security domain= s and have no language to talk to each other outside of prescribed transacti= ons. There are many cases in which only one party has a log of an identity e= vent, and it would be helpful if they had some way to transmit that log to o= ther parties in the ecosystem.

    Here is a list of a few things t= hat a relying party might want to say to an identity provider:
    <= br class=3D"">
    • This user=E2=80=99s behavior is inconsi= stent with past heuristics and I suspect fraud
    • the RP did parallel authentication of a second= factor (e.g. My employee Susan has verified that this user matches (or does= not match) the photo on file at the IdP)
    • Here is a privacy policy that this user consented t= o

    Here is a list of a few things that an identity pr= ovider might want to say to a relying party:

    • This user=E2=80=99s email changed since the last time you c= alled the UserInfo endpoint
    • A user account we have authenticated for you in the past has been c= ompromised
    • This u= ser has revoked your access token

    My proposal is that a= JWL standard be developed based on the form of a JWT, though with some diff= erent fields. It should require iss, sub, aud, and iat, and the optional fie= lds I think would fall into four categories: suspected fraud, userinfo updat= e, consent information, and parallel authentication. Both RPs and IdPs would= implement a JWL endpoint to receive JWLs from other members of the ecosyste= m.

    Thoughts? Would this be helpful?

    Sarah

    Sarah Squire
    Engage Identity
    http://engageiden= tity.com
    _______________________________________________
    Id-event mail= ing list
    Id-event@ietf.org
    https://www.iet= f.org/mailman/listinfo/id-event
    =



    This email and any files transmitted with it are confidential and intende= d solely for the use of the individual or entity to whom they are addressed.= If you have received this email in error please notify the system manager. T= his message contains confidential information and is intended only for the i= ndividual named. If you are not the named addressee you should not dissemina= te, distribute or copy this e-mail. Please notify the sender immediately by e= -mail if you have received this e-mail by mistake and delete this e-mail fro= m your system. If you are not the intended recipient you are notified that d= isclosing, copying, distributing or taking any action in reliance on the con= tents of this information is strictly prohibited.
    <= /div>



    This email and any files transmitted with it are confidential and i= ntended solely for the use of the individual or entity to whom they are addr= essed. If you have received this email in error please notify the system man= ager. This message contains confidential information and is intended only fo= r the individual named. If you are not the named addressee you should not di= sseminate, distribute or copy this e-mail. Please notify the sender immediat= ely by e-mail if you have received this e-mail by mistake and delete this e-= mail from your system. If you are not the intended recipient you are notifie= d that disclosing, copying, distributing or taking any action in reliance on= the contents of this information is strictly prohibited.
    =
    <signature.asc>_______________________________________________
    Id-event mailing list
    Id-event@ietf.org=
    https://www.ietf.org/mailman/listinfo/id-event


    _________________________= ______________________
    Id-event mailing list
    Id-event@ietf.org
    https://www.ietf.org/mailman/listinfo/id-even= t




    --
    BBVA
    Luis Saiz Gimeno
    = Innovation in Security
    M=C3=B3vil +34 609703= 264 - Tel. +34 918073152 - luis.saiz@bbva.com
    Engineering - Architecture & Global Deployment =E2=80=93 Monforte de Lemos, s/n, 28029
    Ma= ps: https://www.google.es/maps/pla= ce/Av.+de+Monforte+de+Lemos,+28,+28029+Madrid/
    Antes de imprim= ir este mensaje, por favor comprueba que es necesario hacerlo. Before you print this message please consider if it is really n= ecessary.
    =

    "Este mensaje est=C3=A1 dirigido de manera exclusiva a su destinatario y puede contener informaci=C3= =B3n privada y confidencial. No lo reenv=C3=ADe, copie o distribuya a terceros qu= e no deban conocer su contenido. En caso de haberlo recibido por error, = ; rogamos lo notifique al remitente y proceda a su borrado, as=C3=AD como al de cualqu= ier documento que pudiera adjuntarse.

     Por= favor tenga en cuenta que los correos enviados v=C3=ADa Internet no permiten garantizar la confidencia= lidad de los mensajes ni su transmisi=C3=B3n de forma =C3=ADntegra.

     Las opiniones expresadas en el presente correo pertenecen =C3=BAnicamente al remitente y no representan necesariamente la opini=C3=B3n del Grupo BBVA."

     "This message is intended exclusively for the adressee and may contain privileged a= nd confidential information. Please, do not disseminate, copy or distribute it t= o third parties who should not receive it. In case you have received it by mistake, please inform the sender and delete the message and attachments fro= m your system.

     Please keep in mind that e-mails sent by Internet do not allow to guarantee neither= the confidentiality or the integrity of the messages sent."

    ______= _________________________________________
    Id-event mailing lis= t
    Id-event@iet= f.org
    https://www.ietf.org/mailman/listinfo/id-event

    _________________= ______________________________
    Id-event mailing list
    Id-event@ietf.org
    https:/= /www.ietf.org/mailman/listinfo/id-event

    _______________________________________________
    Id-e= vent mailing list
    Id-ev= ent@ietf.org
    https://www.ietf.org/mailman/listinfo/id-event
    = --Apple-Mail-3EC84EAC-3583-4F65-A0F2-C19F6A760862-- From nobody Wed Feb 3 17:16:35 2016 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA4371B37D2 for ; Wed, 3 Feb 2016 17:16:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 FFx6KTRwkpoL for ; Wed, 3 Feb 2016 17:16:29 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8068A1B35B3 for ; Wed, 3 Feb 2016 17:16:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=57331; q=dns/txt; s=iport; t=1454548589; x=1455758189; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=mrhgaHDbT3/tQlXWGgMOrOAO2iHr7lTGNrQWn0R19kw=; b=j1BA16KC1CtrSL3eBpnTyn53vV+bG5BByftnqDUtCzA8SbUWnfYzdK/d aixF0Gpg8k5iX1j5+lyA4W/6V7ew8WqT4Tt+DtoBsLvyS+NjGM2gGkIay hXqiYcXP5RuEhE+vdXkuD0Bcmk93EB5Tq53AM2qmszjMmOxq7X4MJ0vsD I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A6AgDqpbJW/5FdJa1VCQ6CYExSbQaFO?= =?us-ascii?q?IMdoTWPZgENgWYXAQuEE4FXAoFBOBQBAQEBAQEBgQqEQQEBAQQBAQEJDi8QFQU?= =?us-ascii?q?GEAIBCAcKAQIBAg0BCAsBBgcnAgkUAwYIAgQBDQUbhXaCCg6rRZU/AQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBFYYShDeEAgcKAR8FCREMAQEIAgYBg3sFkmyEBQGFSGm?= =?us-ascii?q?FQYFagVtKg3iDJoUuhXCEfoNRAR4BAUKBTDcZgQ07aogyCRcCG3wBAQE?= X-IronPort-AV: E=Sophos;i="5.22,392,1449532800"; d="scan'208,217";a="234663607" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Feb 2016 01:16:27 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u141GRIh009504 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 4 Feb 2016 01:16:27 GMT Received: from xch-rcd-004.cisco.com (173.37.102.14) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 3 Feb 2016 19:16:26 -0600 Received: from xch-rcd-004.cisco.com ([173.37.102.14]) by XCH-RCD-004.cisco.com ([173.37.102.14]) with mapi id 15.00.1104.009; Wed, 3 Feb 2016 19:16:26 -0600 From: "Morteza Ansari (moransar)" To: "Phil Hunt (IDM)" , Justin Richer Thread-Topic: [Id-event] Proposal for Identity Event Standard Thread-Index: AQHRXRcHYNWIkfZE70iwWtCo9sX/Rp8X/8oAgAADkoCAAACbgIAAHyCAgAC0IgCAAARzAIACecsAgAAE6oD//509AA== Date: Thu, 4 Feb 2016 01:16:26 +0000 Message-ID: References: <1FDBF3DD-6CEA-4E2E-AA7E-F3C12EB2B32A@wunderlich.ca> <51E9B4BE-F6DF-476A-9D0C-917E2E9B7433@oracle.com> <64D812FD-305F-41F6-9EB7-EEFACF961667@mit.edu> <876356CB-3663-4C58-9DAC-546679EE285B@oracle.com> In-Reply-To: <876356CB-3663-4C58-9DAC-546679EE285B@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.0.151221 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.155.85.249] Content-Type: multipart/alternative; boundary="_000_D2D7E5C318A9Fmoransarciscocom_" MIME-Version: 1.0 Archived-At: Cc: Luis SAIZ GIMENO , John Wunderlich , Mark Lizar - OCG , Sarah Squire , "id-event@ietf.org" Subject: Re: [Id-event] Proposal for Identity Event Standard X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2016 01:16:34 -0000 --_000_D2D7E5C318A9Fmoransarciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable +1 I definitely like the idea of expanding the scope of =93ID events=94, but I= think we still somehow need to somehow anchor it to a loose definition of = identity where all identity related events are included but no worry about = any type of events. I am a bit afraid of going beyond that might significan= tly slow down progress. Cheers, Morteza From: Id-event = > on behalf of Phil Hunt = > Date: Wednesday, February 3, 2016 at 3:09 PM To: Justin Richer > Cc: Luis SAIZ GIMENO >, John = Wunderlich >, Mark Lizar - OC= G >, Sara= h Squire >, "id-e= vent@ietf.org" > Subject: Re: [Id-event] Proposal for Identity Event Standard +1 Phil On Feb 3, 2016, at 14:52, Justin Richer > wrote: I think this is a really great idea. It=92s the kind of abstraction that th= e =93ID Events=94 conversation was pointing towards initially, by my view. = I actually see the JWL as the superset, since the events aren=92t always = =93ID related=94. I think an important next step would be to start defining payloads for diff= erent use cases. Like: =93I=92m an RP and someone just deleted their account with me, I need to t= ell the IDP.=94 =93I=92m an AS and a user just revoked access to an app, I need to tell th= e app.=94 =93I=92m an AS and a user=92s account was compromised, I need to tell all = downstream apps to watch out.=94 =93I=92m an AS and a third-party account was used to access a user=92s res= ources by their policy (think UMA), I need to record something and tell the= user at their designated endpoint.=94 What would each of these strawmen look like as JSON objects inside of a JWL= ? Can we start to extract common claims? I don=92t think that JWT is necess= arily going to be a good base, but it might be reasonable to start there. W= hat=92s the issuer, subject, and audience of each statement? How do we reco= rd the kind of action? Do we have an ontology or registry? Lots of very important questions will start to fall out, and hopefully thei= r answers too, once we start putting JSON to the page. =97 Justin On Feb 2, 2016, at 4:03 AM, Mark Lizar - OCG > wrote: Sarah, I think it is terrific thinking and very insightful. We are very intereste= d in this for consent events and the delegation of consent for a wide array= of access control notices and transactions which relate to consent records= . It appears work like this would extend the core of the consent work we = are doing and I think its very well timed, a super efficient and technicall= y great approach to the set of problems in this space. The JWT logging is brilliant :-) Personally, I think the Consent and In= formation Sharing WG would be very happy to see your work move in this dir= ection and I would hope that we could compliment it. Mark Lizar Executive Director Open Consent Group Email: m.lizar@openconsentgroup.com Twitter: @smartopian On 2 Feb 2016, at 08:47, Luis SAIZ GIMENO > wrote: I'm not an active member in the list but as a customer of this kind of solu= tions having an standard way to emit/receive events from/to IdP/RP is somet= hing that we'll appreciate a lot Phil, how it's organized the work in progress you mention? 2016-02-01 23:03 GMT+01:00 Phil Hunt >: What we are working on new is a generic event system that has the following= traits: * Events (that may be extended for different purposes) that are based on JW= T (JSON Web Token). * JWT gives us the ability to have: plain text, signed, and/or encrypted ev= ents that may be transported over different protocols like HTTP or mobile m= essaging platforms. * A RESTful publish and subscribe system where interested parties may regis= ter interest in certain event types. * Many use cases are inter-domain notifications (e.g. RISC and SCIM events)= . Others are events for things like mobile apps (a profile or subscription= change). The generic event spec should be extensible for Sarah=92s case (if not I=92= d like to find out why). Though I would check in with the existing types to= see if some of the groups like OpenID aren=92t already covering something = similar. Phil @independentid www.independentid.com phil.hunt@oracle.com On Feb 1, 2016, at 12:11 PM, John Wunderlich > wrote: Thanks. It sounds like a useful incremental improvement, as you say, but it does po= int to a more interesting general problem down the road. Sincerely, John Wunderlich (@PrivacyCDN) Privacist & PbD Ambassador On Feb 1, 2016, at 15:09, Sarah Squire > wrote: Hi John, Good questions. I'm not proposing a distributed database or anything blockc= hain-like. I am merely suggesting, as you say, that we add a few more presc= ribed transactions and an endpoint for them to the existing standards. Thes= e seem to be high-value communications that currently aren't happening or a= re happening out of band in non-standardized communications. There may well be additional categories. I'd be curious if other folks on t= his list have more use cases that this standard could address. Sarah Sarah Squire Engage Identity http://engageidentity.com On Mon, Feb 1, 2016 at 11:56 AM, John Wunderlich > wrote: Sarah; Are you replicating the problem of =93..no language to talk to each other o= utside of prescribed transactions=94 at a higher level by prescribing a set= of four categories? It seems an appropriate solution to the cases you desc= ribe, but are there other cases that would necessitate additional categorie= s? When I read the first part of your strawman, I thought your reference to= a JSON Web Log was starting down the road to a distributed database (must = still have blockchain on my mind from the last IIW). Or am I misunderstandi= ng and is what you are proposing a semantic solution to the problem you pos= e? Sincerely, John Wunderlich (@PrivacyCDN) Privacist & PbD Ambassador On Feb 1, 2016, at 12:35, Sarah Squire > wrote: Hi all, I=92ve been mulling the idea of identity events and have run into several s= ituations with different clients where they could be useful. I have a straw= man that I would love for you all to take a few torches to. I propose that we create a new standard for a JSON Web Log, or JWL. The problem I=92m running into is that in distributed access management pro= tocols like OAuth and UMA, different ecosystem parties are often in differe= nt security domains and have no language to talk to each other outside of p= rescribed transactions. There are many cases in which only one party has a = log of an identity event, and it would be helpful if they had some way to t= ransmit that log to other parties in the ecosystem. Here is a list of a few things that a relying party might want to say to an= identity provider: * This user=92s behavior is inconsistent with past heuristics and I suspect f= raud * the RP did parallel authentication of a second factor (e.g. My employee Sus= an has verified that this user matches (or does not match) the photo on fil= e at the IdP) * Here is a privacy policy that this user consented to Here is a list of a few things that an identity provider might want to say = to a relying party: * This user=92s email changed since the last time you called the UserInfo end= point * A user account we have authenticated for you in the past has been compromis= ed * This user has revoked your access token My proposal is that a JWL standard be developed based on the form of a JWT,= though with some different fields. It should require iss, sub, aud, and ia= t, and the optional fields I think would fall into four categories: suspect= ed fraud, userinfo update, consent information, and parallel authentication= . Both RPs and IdPs would implement a JWL endpoint to receive JWLs from oth= er members of the ecosystem. Thoughts? Would this be helpful? Sarah Sarah Squire Engage Identity http://engageidentity.com _______________________________________________ Id-event mailing list Id-event@ietf.org https://www.ietf.org/mailman/listinfo/id-event This email and any files transmitted with it are confidential and intended = solely for the use of the individual or entity to whom they are addressed. = If you have received this email in error please notify the system manager. = This message contains confidential information and is intended only for the= individual named. If you are not the named addressee you should not dissem= inate, distribute or copy this e-mail. Please notify the sender immediately= by e-mail if you have received this e-mail by mistake and delete this e-ma= il from your system. If you are not the intended recipient you are notified= that disclosing, copying, distributing or taking any action in reliance on= the contents of this information is strictly prohibited. This email and any files transmitted with it are confidential and intended = solely for the use of the individual or entity to whom they are addressed. = If you have received this email in error please notify the system manager. = This message contains confidential information and is intended only for the= individual named. If you are not the named addressee you should not dissem= inate, distribute or copy this e-mail. Please notify the sender immediately= by e-mail if you have received this e-mail by mistake and delete this e-ma= il from your system. If you are not the intended recipient you are notified= that disclosing, copying, distributing or taking any action in reliance on= the contents of this information is strictly prohibited. _______________________________________________ Id-event mailing list Id-event@ietf.org https://www.ietf.org/mailman/listinfo/id-event _______________________________________________ Id-event mailing list Id-event@ietf.org https://www.ietf.org/mailman/listinfo/id-event -- BBVA Luis Saiz Gimeno Innovation in Security M=F3vil +34 609703264 - Tel. +34 918073152 - luis.saiz@bbva.com Engineering - Architecture & Global Deployment =96 Monforte de Lemos, s/n, = 28029 Maps: https://www.google.es/maps/place/Av.+de+Monforte+de+Lemos,+28,+28029+= Madrid/ Antes de imprimir este mensaje, por favor comprueba que es necesario hacerl= o. Before you print this message please consider if it is really necessary. "Este mensaje est=E1 dirigido de manera exclusiva a su destinatario y puede= contener informaci=F3n privada y confidencial. No lo reenv=EDe, copie o di= stribuya a terceros que no deban conocer su contenido. En caso de haberlo r= ecibido por error, rogamos lo notifique al remitente y proceda a su borrad= o, as=ED como al de cualquier documento que pudiera adjuntarse. Por favor tenga en cuenta que los correos enviados v=EDa Internet no permi= ten garantizar la confidencialidad de los mensajes ni su transmisi=F3n de f= orma =EDntegra. Las opiniones expresadas en el presente correo pertenecen =FAnicamente al = remitente y no representan necesariamente la opini=F3n del Grupo BBVA." "This message is intended exclusively for the adressee and may contain pri= vileged and confidential information. Please, do not disseminate, copy or d= istribute it to third parties who should not receive it. In case you have r= eceived it by mistake, please inform the sender and delete the message and = attachments from your system. Please keep in mind that e-mails sent by Internet do not allow to guarante= e neither the confidentiality or the integrity of the messages sent." _______________________________________________ Id-event mailing list Id-event@ietf.org https://www.ietf.org/mailman/listinfo/id-event _______________________________________________ Id-event mailing list Id-event@ietf.org https://www.ietf.org/mailman/listinfo/id-event _______________________________________________ Id-event mailing list Id-event@ietf.org https://www.ietf.org/mailman/listinfo/id-event --_000_D2D7E5C318A9Fmoransarciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <9C111114B53F4044A2B57974F3B7065E@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
    +1

    I definitely like the idea of expanding the scope of =93ID events=94, = but I think we still somehow need to somehow anchor it to a loose definitio= n of identity where all identity related events are included but no worry a= bout any type of events. I am a bit afraid of going beyond that might significantly slow down progress.


    Cheers,
    Morteza

    From: Id-event <id-event-bounces@ietf.org> on behalf of= Phil Hunt <phil.hunt@oracle.com= >
    Date: Wednesday, February 3, 2016 a= t 3:09 PM
    To: Justin Richer <jricher@mit.edu>
    Cc: Luis SAIZ GIMENO <luis.saiz@bbva.com>, John Wunderlich <= ;john@wunderlich.ca>, Mark Liz= ar - OCG <m.lizar@openco= nsentgroup.com>, Sarah Squire <sarah@engagei= dentity.com>, "id-event@ie= tf.org" <id-event@ietf.org= >
    Subject: Re: [Id-event] Proposal fo= r Identity Event Standard

    +1

    Phil

    On Feb 3, 2016, at 14:52, Justin Richer <jricher@mit.edu> wrote:

    I think this is a really great idea. It=92s the kind of abstraction th= at the =93ID Events=94 conversation was pointing towards initially, by my v= iew. I actually see the JWL as the superset, since the events aren=92t alwa= ys =93ID related=94. 

    I think an important next step would be to start defining p= ayloads for different use cases. Like:


     =93I=92m an RP and someone just deleted their account= with me, I need to tell the IDP.=94

     =93I=92m an AS and a user just revoked access to an a= pp, I need to tell the app.=94

     =93I=92m an AS and a user=92s account was compromised= , I need to tell all downstream apps to watch out.=94

     =93I=92m an AS and a third-party account was used to = access a user=92s resources by their policy (think UMA), I need to record s= omething and tell the user at their designated endpoint.=94


    What would each of these strawmen look like as JSON objects= inside of a JWL? Can we start to extract common claims? I don=92t think th= at JWT is necessarily going to be a good base, but it might be reasonable t= o start there. What=92s the issuer, subject, and audience of each statement? How do we record the kind of action? Do we= have an ontology or registry?

    Lots of very important questions will start to fall out, an= d hopefully their answers too, once we start putting JSON to the page.

     =97 Justin


    On Feb 2, 2016, at 4:03 AM, Mark Lizar - OCG <m.lizar@openconsentgroup.c= om> wrote:

    Sarah, 

    I think it is terrific thinking and very insightful.  = We are very interested in this for consent events and the delegation of con= sent for a wide array of access control notices and transactions which rela= te to consent records.  It appears work like this  would extend the core of the consent work we are doing and= I think its very well timed, a super efficient and technically great appro= ach to the set of problems in this space. 

    The JWT logging is brilliant :-)     Personally, = I think the Consent and Information Sharing  WG would be very happy to= see your work move in this direction and I would hope that we could compli= ment it. 

    Mark Lizar
    Executive Director
    Open Consent Group

    Email: m.lizar@openconsentgroup.com
    Twitter: @smartopian

    On 2 Feb 2016, at 08:47, Luis SAIZ GIMENO <luis.saiz@bbva.com> wrote:

    I'm not an active member in the list but as a c= ustomer of this kind of solutions having an standard way to emit/receive ev= ents from/to IdP/RP is something that we'll appreciate a lot


    Phil, how it's organized the work in progress you mention?<= /div>

    2016-02-01 23:03 GMT+01:00 Phil Hunt <ph= il.hunt@oracle.com>:
    What we are working on new i= s a generic event system that has the following traits:

    * Events (that may be extended for different purposes) that= are based on JWT (JSON Web Token).
    * JWT gives us the ability to have: plain text, signed, and= /or encrypted events that may be transported over different protocols like = HTTP or mobile messaging platforms.
    * A RESTful publish and subscribe system where interested p= arties may register interest in certain event types.
    * Many use cases are inter-domain notifications (e.g. RISC = and SCIM events).  Others are events for things like mobile apps (a pr= ofile or subscription change).

    The generic event spec should be extensible for Sarah=92s c= ase (if not I=92d like to find out why). Though I would check in with the e= xisting types to see if some of the groups like OpenID aren=92t already cov= ering something similar.

    Phil

    @independentid
    www.independentid.com
    phil.hunt@oracle.com





    On Feb 1, 2016, at 12:11 PM, John Wunderlich <john@wunderlich.ca= > wrote:
    Thanks.

    It sounds like a useful incremental improvement, as you sa= y, but it does point to a more interesting general problem down the road.

    Sincerely,
    John Wunderlich
    (@PrivacyCDN)

    <PastedGraphic-4.tiff>


    Privacist & PbD Ambassador




    On Feb 1, 2016, at 15:09, Sarah Squire <sarah@engageidenti= ty.com> wrote:

    Hi John,

    Good questions. I'm not proposing a distributed database or anything blockc= hain-like. I am merely suggesting, as you say, that we add a few more presc= ribed transactions and an endpoint for them to the existing standards. Thes= e seem to be high-value communications that currently aren't happening or are happening out of band in non-standa= rdized communications.

    There may well be additional categories. I'd be curious if = other folks on this list have more use cases that this standard could addre= ss.

    Sarah

    Sarah Squire
    Engage Identity
    ht= tp://engageidentity.com

    On Mon, Feb 1, 2016 at 11:56 AM, John Wunderlich=  <john@wunderlich.ca> wrote:
    Sarah;

    Are you replicating the problem of =93..no language to talk= to each other outside of prescribed transactions=94 at a higher level by p= rescribing a set of four categories? It seems an appropriate solution to th= e cases you describe, but are there other cases that would necessitate additional categories? When I read the first = part of your strawman, I thought your reference to a JSON Web Log was start= ing down the road to a distributed database (must still have blockchain on = my mind from the last IIW). Or am I misunderstanding and is what you are proposing a semantic solution to th= e problem you pose?

    Sincerely,
    John Wunderlich=
    (@PrivacyCDN)

    <PastedGraphic-4.tiff>


    Privacist & PbD Ambassador




    On Feb 1, 2016, at 12:35, Sarah Squire <sarah@engageidenti= ty.com> wrote:

    Hi all,

    I=92ve bee= n mulling the idea of identity events and have run into several situations with different clients where they could b= e useful. I have a strawman that I would love for you all to take a few tor= ches to.

    I propose = that we create a new standard for a JSON Web Log, or JWL.

    The proble= m I=92m running into is that in distributed access management protocols like OAuth and UMA, different ecosystem partie= s are often in different security domains and have no language to talk to e= ach other outside of prescribed transactions. There are many cases in which= only one party has a log of an identity event, and it would be helpful if they had some way to transmit t= hat log to other parties in the ecosystem.

    Here is a = list of a few things that a relying party might want to say to an identity provider:

    • This user=92s behavior is in= consistent with past heuristics and I suspect fraud
    • the RP did parallel authenti= cation of a second factor (e.g. My employee Susan has verified that this user matches (or does not match) the photo on= file at the IdP)
    • Here is a privacy policy tha= t this user consented to

    Here is a = list of a few things that an identity provider might want to say to a relying party:

    • This user=92s email changed = since the last time you called the UserInfo endpoint
    • A user account we have authe= nticated for you in the past has been compromised
    • This user has revoked your a= ccess token

    My proposa= l is that a JWL standard be developed based on the form of a JWT, though with some different fields. It should require= iss, sub, aud, and iat, and the optional fields I think would fall into fo= ur categories: suspected fraud, userinfo update, consent information, and p= arallel authentication. Both RPs and IdPs would implement a JWL endpoint to receive JWLs from other members= of the ecosystem.

    Thoughts? = Would this be helpful?

    Sarah

    Sarah Squire
    Engage Identity
    ht= tp://engageidentity.com
    _______________________________________________
    Id-event mailing list
    Id-event@= ietf.org
    https://www.ietf.org/mailman/listinfo/id-event



    This email and any files transmitted with it are confidential and int= ended solely for the use of the individual or entity to whom they are addre= ssed. If you have received this email in error please notify the system manager. This message contains confidential= information and is intended only for the individual named. If you are not = the named addressee you should not disseminate, distribute or copy this e-m= ail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-ma= il from your system. If you are not the intended recipient you are notified= that disclosing, copying, distributing or taking any action in reliance on= the contents of this information is strictly prohibited.




    This email = and any files transmitted with it are confidential and intended solely for = the use of the individual or entity to whom they are addressed. If you have= received this email in error please notify the system manager. This message contains confidential information and is = intended only for the individual named. If you are not the named addressee = you should not disseminate, distribute or copy this e-mail. Please notify t= he sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from yo= ur system. If you are not the intended recipient you are notified that disc= losing, copying, distributing or taking any action in reliance on the conte= nts of this information is strictly prohibited.
    <signature.asc>_______________________________________________
    Id-event mailing list
    Id-event@ietf.org
    https://www.ietf.org/mailman/listinfo/id-event


    _______________________________________________
    Id-event mailing list
    Id-event@ietf.org
    https://www.ietf.org/mailman/listinfo/id-ev= ent




    --
    BBVA=
    Luis Saiz Gimen= o
    Innovation in Security
    M=F3vil +34 609703264 - Tel. +34 918073= 152 - luis.= saiz@bbva.com
    = Engineering - Architecture & Global Deployment =96 Monforte de Lemos, s/n, 28029
    Maps: https://www.google.es/maps/place/Av.+de+Monforte+de+Lemos,&= #43;28,+28029+Madrid/
    Antes de imprimir este= mensaje, por favor comprueba que es necesario hacerlo. Before you print this message please consider i= f it is really necessary.

    "E= ste mensaje est=E1 dirigido de manera exclusiva a su destinatario y puede c= ontener informaci=F3n privada y confidencial. No lo reenv=EDe, copie o distribuya a terceros que no deban conocer su conten= ido. En caso de haberlo recibido por error,  rogamos lo noti= fique al remitente y proceda a su borrado, as=ED como al de cualquier docum= ento que pudiera adjuntarse.

     <= /span>Por favor tenga en cuenta que los correos enviados v=EDa Internet no permiten garantizar la confiden= cialidad de los mensajes ni su transmisi=F3n de forma =EDntegra.

     <= /span>Las opiniones expresadas en el presente correo pertenecen =FAnicamente al remitente y no representa= n necesariamente la opini=F3n del Grupo BBVA."

     <= /span>"This message is intended exclusively for the adressee and may contain privileged and confidential i= nformation. Please, do not disseminate, copy or distribute it to third part= ies who should not receive it. In case you have received it by mistake, ple= ase inform the sender and delete the message and attachments from your system.

     Please keep in mind that e-mails sent by Internet do not allow to guarantee neither th= e confidentiality or the integrity of the messages sent."

    _______________________________________________
    Id-event mailing list
    Id-event@ietf.org
    https= ://www.ietf.org/mailman/listinfo/id-event

    _______________________________________________
    Id-event mailing list
    Id-event@ietf.org
    https://www.ietf= .org/mailman/listinfo/id-event

    _______________________________________________
    Id-event mailing list
    Id-event@ietf.org
    https://ww= w.ietf.org/mailman/listinfo/id-event
     --_000_D2D7E5C318A9Fmoransarciscocom_-- From nobody Thu Feb 4 07:34:47 2016 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6011A1B3197 for ; Thu, 4 Feb 2016 07:34:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NSOoPFitWFRw for ; Thu, 4 Feb 2016 07:34:41 -0800 (PST) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED6CB1B317F for ; Thu, 4 Feb 2016 07:34:40 -0800 (PST) Received: by mail-ig0-x22f.google.com with SMTP id 5so63039417igt.0 for ; Thu, 04 Feb 2016 07:34:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salesforce.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=3Z725jiCzR11p9fW7o77RUuuUIH3i8N4nsYIlvhPLWY=; b=MeKJVrmcxXj7R7f4vXJPQ9CmUGlNwQCHsqvgd1fvxD1phe4cunVfEAfoLZgU2EJJEu udLxEn1FqEdkZbaRlrDxHBRLX87L+101L95Wtlo7T+oO2wGk+m9MHHENOWO7RJmcf58n lIWz4+JwKMm6G/C88KXSaUGCelxHQCr3s5rgs= 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=3Z725jiCzR11p9fW7o77RUuuUIH3i8N4nsYIlvhPLWY=; b=AEWai35U1EsrYVvoJ36vgROxBPobLfLfxgqcEIrhlbXl10KZ+FMyEkBctT+TMKkl0O exAl25qJKvicQblOqdNv6QKxc2QujN1+obHFNnUAnqGSq7F4F3AypvEFIfKqW1qr6MlC /VJgVUl5ubNo3IaoaElk6ezog9xekizFn6ZJTNnltEtsM0NjDqF4ReA7PQzPXcJ6aIML RQ8AanBvypB8IZ9NaNhZDYsZIyjPaZkciqLy3ph3rRoqxkIB7V2wx6Mt1IsfUwpBE/sn Umrbre4gMh5eaWZx6PnC8pjpiSCh36W8HAeG/DKjAN8ozXaxTIYdRDf+lqzgsVYGVSKD iwBQ== X-Gm-Message-State: AG10YOSrhU+rmZJBdwLjqcbFXZJXR2+ZWVTOz3BcV8Au+U4dF774LKBKuUeaYBob9mkUX4FwuH18eMOY0hJLkuD2 X-Received: by 10.50.28.20 with SMTP id x20mr4726550igg.87.1454600072422; Thu, 04 Feb 2016 07:34:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.36.61.16 with HTTP; Thu, 4 Feb 2016 07:34:12 -0800 (PST) In-Reply-To: <64D812FD-305F-41F6-9EB7-EEFACF961667@mit.edu> References: <1FDBF3DD-6CEA-4E2E-AA7E-F3C12EB2B32A@wunderlich.ca> <51E9B4BE-F6DF-476A-9D0C-917E2E9B7433@oracle.com> <64D812FD-305F-41F6-9EB7-EEFACF961667@mit.edu> From: Ian Glazer Date: Thu, 4 Feb 2016 10:34:12 -0500 Message-ID: To: Justin Richer Content-Type: multipart/alternative; boundary=089e01538d989ba2e0052af37804 Archived-At: Cc: John Wunderlich , id-event@ietf.org, Luis SAIZ GIMENO , Mark Lizar - OCG , Sarah Squire , Phil Hunt Subject: Re: [Id-event] Proposal for Identity Event Standard X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2016 15:34:45 -0000 --089e01538d989ba2e0052af37804 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Overall I like the idea. But we have to separate format from content. Sarah's idea for JWL sounds like a proposal for syslog in the JSON era, and that is a very good thing. If we think about JWL like syslog, then it fixes just enough format for multiple producers and consumers to use and also allows multiple organizations to design specific content types, like Justin points to, independently. This would allow SCIM WG, OpenID RISC, etc to do their things. Just my $0.02 On Wed, Feb 3, 2016 at 5:52 PM, Justin Richer wrote: > I think this is a really great idea. It=E2=80=99s the kind of abstraction= that the > =E2=80=9CID Events=E2=80=9D conversation was pointing towards initially, = by my view. I > actually see the JWL as the superset, since the events aren=E2=80=99t alw= ays =E2=80=9CID > related=E2=80=9D. > > I think an important next step would be to start defining payloads for > different use cases. Like: > > > =E2=80=9CI=E2=80=99m an RP and someone just deleted their account with m= e, I need to tell > the IDP.=E2=80=9D > > =E2=80=9CI=E2=80=99m an AS and a user just revoked access to an app, I n= eed to tell the > app.=E2=80=9D > > =E2=80=9CI=E2=80=99m an AS and a user=E2=80=99s account was compromised,= I need to tell all > downstream apps to watch out.=E2=80=9D > > =E2=80=9CI=E2=80=99m an AS and a third-party account was used to access = a user=E2=80=99s > resources by their policy (think UMA), I need to record something and tel= l > the user at their designated endpoint.=E2=80=9D > > > What would each of these strawmen look like as JSON objects inside of a > JWL? Can we start to extract common claims? I don=E2=80=99t think that JW= T is > necessarily going to be a good base, but it might be reasonable to start > there. What=E2=80=99s the issuer, subject, and audience of each statement= ? How do > we record the kind of action? Do we have an ontology or registry? > > Lots of very important questions will start to fall out, and hopefully > their answers too, once we start putting JSON to the page. > > =E2=80=94 Justin > > > On Feb 2, 2016, at 4:03 AM, Mark Lizar - OCG > wrote: > > Sarah, > > I think it is terrific thinking and very insightful. We are very > interested in this for consent events and the delegation of consent for a > wide array of access control notices and transactions which relate to > consent records. It appears work like this would extend the core of the > consent work we are doing and I think its very well timed, a super > efficient and technically great approach to the set of problems in this > space. > > The JWT logging is brilliant :-) Personally, I think the Consent and > Information Sharing WG would be very happy to see your work move in this > direction and I would hope that we could compliment it. > > Mark Lizar > Executive Director > Open Consent Group > > Email: m.lizar@openconsentgroup.com > Twitter: @smartopian > > On 2 Feb 2016, at 08:47, Luis SAIZ GIMENO wrote: > > I'm not an active member in the list but as a customer of this kind of > solutions having an standard way to emit/receive events from/to IdP/RP is > something that we'll appreciate a lot > > > Phil, how it's organized the work in progress you mention? > > 2016-02-01 23:03 GMT+01:00 Phil Hunt : > >> What we are working on new is a generic event system that has the >> following traits: >> >> * Events (that may be extended for different purposes) that are based on >> JWT (JSON Web Token). >> * JWT gives us the ability to have: plain text, signed, and/or encrypted >> events that may be transported over different protocols like HTTP or mob= ile >> messaging platforms. >> * A RESTful publish and subscribe system where interested parties may >> register interest in certain event types. >> * Many use cases are inter-domain notifications (e.g. RISC and SCIM >> events). Others are events for things like mobile apps (a profile or >> subscription change). >> >> The generic event spec should be extensible for Sarah=E2=80=99s case (if= not I=E2=80=99d >> like to find out why). Though I would check in with the existing types t= o >> see if some of the groups like OpenID aren=E2=80=99t already covering so= mething >> similar. >> >> Phil >> >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >> >> >> >> >> >> On Feb 1, 2016, at 12:11 PM, John Wunderlich wrote: >> >> Thanks. >> >> It sounds like a useful incremental improvement, as you say, but it does >> point to a more interesting general problem down the road. >> >> Sincerely, >> *John Wunderlich* >> *(@PrivacyCDN)* >> >> >> >> >> >> Privacist & PbD Ambassador >> >> >> >> >> >> On Feb 1, 2016, at 15:09, Sarah Squire wrote: >> >> Hi John, >> >> Good questions. I'm not proposing a distributed database or anything >> blockchain-like. I am merely suggesting, as you say, that we add a few m= ore >> prescribed transactions and an endpoint for them to the existing standar= ds. >> These seem to be high-value communications that currently aren't happeni= ng >> or are happening out of band in non-standardized communications. >> >> There may well be additional categories. I'd be curious if other folks o= n >> this list have more use cases that this standard could address. >> >> Sarah >> >> Sarah Squire >> Engage Identity >> http://engageidentity.com >> >> On Mon, Feb 1, 2016 at 11:56 AM, John Wunderlich >> wrote: >> >>> Sarah; >>> >>> Are you replicating the problem of =E2=80=9C..no language to talk to ea= ch other >>> outside of prescribed transactions=E2=80=9D at a higher level by prescr= ibing a set >>> of four categories? It seems an appropriate solution to the cases you >>> describe, but are there other cases that would necessitate additional >>> categories? When I read the first part of your strawman, I thought your >>> reference to a JSON Web Log was starting down the road to a distributed >>> database (must still have blockchain on my mind from the last IIW). Or = am I >>> misunderstanding and is what you are proposing a semantic solution to t= he >>> problem you pose? >>> >>> Sincerely, >>> *John Wunderlich* >>> *(@PrivacyCDN)* >>> >>> >>> >>> >>> >>> Privacist & PbD Ambassador >>> >>> >>> >>> >>> >>> On Feb 1, 2016, at 12:35, Sarah Squire wrote= : >>> >>> Hi all, >>> >>> I=E2=80=99ve been mulling the idea of identity events and have run into= several >>> situations with different clients where they could be useful. I have a >>> strawman that I would love for you all to take a few torches to. >>> >>> I propose that we create a new standard for a JSON Web Log, or JWL. >>> >>> The problem I=E2=80=99m running into is that in distributed access mana= gement >>> protocols like OAuth and UMA, different ecosystem parties are often in >>> different security domains and have no language to talk to each other >>> outside of prescribed transactions. There are many cases in which only = one >>> party has a log of an identity event, and it would be helpful if they h= ad >>> some way to transmit that log to other parties in the ecosystem. >>> >>> Here is a list of a few things that a relying party might want to say t= o >>> an identity provider: >>> >>> >>> - This user=E2=80=99s behavior is inconsistent with past heuristics = and I >>> suspect fraud >>> - the RP did parallel authentication of a second factor (e.g. My >>> employee Susan has verified that this user matches (or does not matc= h) the >>> photo on file at the IdP) >>> - Here is a privacy policy that this user consented to >>> >>> >>> Here is a list of a few things that an identity provider might want to >>> say to a relying party: >>> >>> >>> - This user=E2=80=99s email changed since the last time you called t= he >>> UserInfo endpoint >>> - A user account we have authenticated for you in the past has been >>> compromised >>> - This user has revoked your access token >>> >>> >>> My proposal is that a JWL standard be developed based on the form of a >>> JWT, though with some different fields. It should require iss, sub, aud= , >>> and iat, and the optional fields I think would fall into four categorie= s: >>> suspected fraud, userinfo update, consent information, and parallel >>> authentication. Both RPs and IdPs would implement a JWL endpoint to rec= eive >>> JWLs from other members of the ecosystem. >>> >>> Thoughts? Would this be helpful? >>> >>> Sarah >>> >>> Sarah Squire >>> Engage Identity >>> http://engageidentity.com >>> _______________________________________________ >>> Id-event mailing list >>> Id-event@ietf.org >>> https://www.ietf.org/mailman/listinfo/id-event >>> >>> >>> >>> >>> This email and any files transmitted with it are confidential and >>> intended solely for the use of the individual or entity to whom they ar= e >>> addressed. If you have received this email in error please notify the >>> system manager. This message contains confidential information and is >>> intended only for the individual named. If you are not the named addres= see >>> you should not disseminate, distribute or copy this e-mail. Please noti= fy >>> the sender immediately by e-mail if you have received this e-mail by >>> mistake and delete this e-mail from your system. If you are not the >>> intended recipient you are notified that disclosing, copying, distribut= ing >>> or taking any action in reliance on the contents of this information is >>> strictly prohibited. >>> >> >> >> >> >> This email and any files transmitted with it are confidential and >> intended solely for the use of the individual or entity to whom they are >> addressed. If you have received this email in error please notify the >> system manager. This message contains confidential information and is >> intended only for the individual named. If you are not the named address= ee >> you should not disseminate, distribute or copy this e-mail. Please notif= y >> the sender immediately by e-mail if you have received this e-mail by >> mistake and delete this e-mail from your system. If you are not the >> intended recipient you are notified that disclosing, copying, distributi= ng >> or taking any action in reliance on the contents of this information is >> strictly prohibited. >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://www.ietf.org/mailman/listinfo/id-event >> >> >> >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://www.ietf.org/mailman/listinfo/id-event >> >> > > > -- > *BBVA* > *Luis Saiz Gimeno* > *Innovation in Security* > M=C3=B3vil +34 609703264 - Tel. +34 918073152 - luis.saiz@bbva.com > *Engineering - Architecture & Global Deployment *=E2=80=93 Monforte de Le= mos, > s/n, 28029 > Maps: > https://www.google.es/maps/place/Av.+de+Monforte+de+Lemos,+28,+28029+Madr= id/ > Antes de imprimir este mensaje, por favor comprueba que es necesario > hacerlo. Before you print this message please consider if it is really > necessary. > > "Este mensaje est=C3=A1 dirigido de manera exclusiva a su destinatario y = puede > contener informaci=C3=B3n privada y confidencial. No lo reenv=C3=ADe, cop= ie o > distribuya a terceros que no deban conocer su contenido. En caso de haber= lo > recibido por error, rogamos lo notifique al remitente y proceda a su > borrado, as=C3=AD como al de cualquier documento que pudiera adjuntarse. > > Por favor tenga en cuenta que los correos enviados v=C3=ADa Internet no > permiten garantizar la confidencialidad de los mensajes ni su transmisi= =C3=B3n > de forma =C3=ADntegra. > > Las opiniones expresadas en el presente correo pertenecen =C3=BAnicament= e al > remitente y no representan necesariamente la opini=C3=B3n del Grupo BBVA.= " > > "This message is intended exclusively for the adressee and may contain > privileged and confidential information. Please, do not disseminate, copy > or distribute it to third parties who should not receive it. In case you > have received it by mistake, please inform the sender and delete the > message and attachments from your system. > > Please keep in mind that e-mails sent by Internet do not allow to > guarantee neither the confidentiality or the integrity of the messages > sent." > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > --=20 Ian Glazer Senior Director, Identity +1 202 255 3166 @iglazer --089e01538d989ba2e0052af37804 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    ___= ____________________________________________
    Id-event mailing list
    Id-event@ietf.org
    https://www.ietf.org/mailman/listinfo/id-event




    --
    Ian Glazer
    Senio= r Director, Identity
    +1 202 255 3166
    --089e01538d989ba2e0052af37804--
    Overall I like the idea. But we have to separate format fr= om content. Sarah's idea for JWL sounds like a proposal for syslog in t= he JSON era, and that is a very good thing.=C2=A0

    If we = think about JWL like syslog, then it fixes just enough format for multiple = producers and consumers to use and also allows multiple organizations to de= sign specific content types, like Justin points to, independently. This wou= ld allow SCIM WG, OpenID RISC, etc to do their things.

    Just my $0.02

    On Wed, Feb 3, 2016 at 5:52 PM, Justin Richer <jricher@mit.= edu> wrote:
    I think this is a really great idea. It=E2=80=99s the = kind of abstraction that the =E2=80=9CID Events=E2=80=9D conversation was p= ointing towards initially, by my view. I actually see the JWL as the supers= et, since the events aren=E2=80=99t always =E2=80=9CID related=E2=80=9D.=C2= =A0

    I think an important next step would be to start def= ining payloads for different use cases. Like:


    =
    =C2=A0=E2=80=9CI=E2=80=99m an RP and someone just deleted their = account with me, I need to tell the IDP.=E2=80=9D

    = =C2=A0=E2=80=9CI=E2=80=99m an AS and a user just revoked access to an app, = I need to tell the app.=E2=80=9D

    =C2=A0=E2=80=9CI= =E2=80=99m an AS and a user=E2=80=99s account was compromised, I need to te= ll all downstream apps to watch out.=E2=80=9D

    =C2= =A0=E2=80=9CI=E2=80=99m an AS and a third-party account was used to access = a user=E2=80=99s resources by their policy (think UMA), I need to record so= mething and tell the user at their designated endpoint.=E2=80=9D
    =

    What would each of these strawmen look like a= s JSON objects inside of a JWL? Can we start to extract common claims? I do= n=E2=80=99t think that JWT is necessarily going to be a good base, but it m= ight be reasonable to start there. What=E2=80=99s the issuer, subject, and = audience of each statement? How do we record the kind of action? Do we have= an ontology or registry?

    Lots of very important q= uestions will start to fall out, and hopefully their answers too, once we s= tart putting JSON to the page.

    =C2=A0=E2=80=94 Justin
    =


    On Feb 2, 2016, at 4:03 AM, Mark Lizar - OCG <m.lizar@openconsentgroup.com= > wrote:

    Sarah,= =C2=A0

    I think it is terrific thinking and very insightf= ul.=C2=A0 We are very interested in this for consent events and the delegat= ion of consent for a wide array of access control notices and transactions = which relate to consent records.=C2=A0 It appears work like this =C2=A0woul= d extend the core of the consent work we are doing and I think its very wel= l timed, a super efficient and technically great approach to the set of pro= blems in this space.=C2=A0

    The JWT logging is brilliant = :-) =C2=A0 =C2=A0 Personally, I think the Consent and Information Sharing = =C2=A0WG would be very happy to see your work move in this direction and I = would hope that we could compliment it.=C2=A0

    Mark Lizar
    Executive Direc= tor
    Open Consent Group

    Twitter: @smartopian
    <= /div>

    On 2 Feb 2016, at 08:47, Luis SAIZ GIMENO <luis.saiz@bbva.com> wrote:
    =
    I'm not an active member in the list but as a= customer of this kind of solutions having an standard way to emit/receive = events from/to IdP/RP is something that we'll appreciate a lot

    =

    Phil, how it's organized the work in progress= you mention?

    2016-02-01 23:03 GMT+01:00 Phil Hunt <phil.hunt@oracle.com= >:
    What we are working on new is a generic event system that has the f= ollowing traits:

    * Events (that may be extended for diff= erent purposes) that are based on JWT (JSON Web Token).
    * JWT giv= es us the ability to have: plain text, signed, and/or encrypted events that= may be transported over different protocols like HTTP or mobile messaging = platforms.
    * A RESTful publish and subscribe system where interes= ted parties may register interest in certain event types.
    * Many = use cases are inter-domain notifications (e.g. RISC and SCIM events).=C2=A0= Others are events for things like mobile apps (a profile or subscription c= hange).

    The generic event spec should be extensibl= e for Sarah=E2=80=99s case (if not I=E2=80=99d like to find out why). Thoug= h I would check in with the existing types to see if some of the groups lik= e OpenID aren=E2=80=99t already covering something similar.

    <= /div>
    <= span style=3D"border-collapse:separate;line-height:normal;border-spacing:0p= x">





    On Feb 1, 2016, at 12:11 PM, = John Wunderlich <john@wunderlich.ca> wrote:

    Thanks.

    It sounds like a useful incremental improv= ement, as you say, but it does point to a more interesting general problem = down the road.

    Sinc= erely,
    John Wunderlich
    (@PrivacyCDN)
    <PastedGraphic-4.tiff>=


    Privacist & PbD Ambassador



    =

    On Feb 1, 2016, at = 15:09, Sarah Squire <sarah@engageidentity.com> wrote:

    Hi John,

    Good questions. I'm not prop= osing a distributed database or anything blockchain-like. I am merely sugge= sting, as you say, that we add a few more prescribed transactions and an en= dpoint for them to the existing standards. These seem to be high-value comm= unications that currently aren't happening or are happening out of band= in non-standardized communications.

    There may well be a= dditional categories. I'd be curious if other folks on this list have m= ore use cases that this standard could address.

    Sa= rah

    Sarah Squire
    Engage Identity
    =

    On Mon, Feb 1, 2016 at 11:56 AM, John = Wunderlich=C2=A0<john@wunderlich.ca>=C2= =A0wrote:
    Sa= rah;

    Are you replicating the problem of =E2=80=9C..no la= nguage to talk to each other outside of prescribed transactions=E2=80=9D at= a higher level by prescribing a set of four categories? It seems an approp= riate solution to the cases you describe, but are there other cases that wo= uld necessitate additional categories? When I read the first part of your s= trawman, I thought your reference to a JSON Web Log was starting down the r= oad to a distributed database (must still have blockchain on my mind from t= he last IIW). Or am I misunderstanding and is what you are proposing a sema= ntic solution to the problem you pose?

    = Sincerely,

    On Fe= b 1, 2016, at 12:35, Sarah Squire <sarah@engageidentity.com> wrote:

    <= /div>
    Hi all,

    I=E2=80=99ve been mulling the idea of identity events and have run= into several situations with different clients where they could be useful.= I have a strawman that I would love for you all to take a few torches to.<= /span>

    I propose that w= e create a new standard for a JSON Web Log, or JWL.

    The problem I=E2=80=99m running into is= that in distributed access management protocols like OAuth and UMA, differ= ent ecosystem parties are often in different security domains and have no l= anguage to talk to each other outside of prescribed transactions. There are= many cases in which only one party has a log of an identity event, and it = would be helpful if they had some way to transmit that log to other parties= in the ecosystem.

    Here is a list of a few things that a relying party might want to say to= an identity provider:

    • <= div style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt">This user=E2=80=99s behavior is inconsistent with p= ast heuristics and I suspect fraud
  • the RP d= id parallel authentication of a second factor (e.g. My employee Susan has v= erified that this user matches (or does not match) the photo on file at the= IdP)
  • Here is a privacy policy that this user= consented to

    • Here is a list of a few things that an identity provider might want= to say to a relying party:

    • This user=E2=80=99s email changed since the la= st time you called the UserInfo endpoint
    • A us= er account we have authenticated for you in the past has been compromised
    • This user has revoked your access token=

    My proposal = is that a JWL standard be developed based on the form of a JWT, though with= some different fields. It should require iss, sub, aud, and iat, and the o= ptional fields I think would fall into four categories: suspected fraud, us= erinfo update, consent information, and parallel authentication. Both RPs a= nd IdPs would implement a JWL endpoint to receive JWLs from other members o= f the ecosystem.

    Thoughts? Would this be helpful?

    Sarah

    S= arah Squire
    _______________= ________________________________
    Id-event mailing list
    Id-event@ietf.org
    https= ://www.ietf.org/mailman/listinfo/id-event
    =



    This email and any files transmitted with it are confidenti= al and intended solely for the use of the individual or entity to whom they= are addressed. If you have received this email in error please notify the = system manager. This message contains confidential information and is inten= ded only for the individual named. If you are not the named addressee you s= hould not disseminate, distribute or copy this e-mail. Please notify the se= nder immediately by e-mail if you have received this e-mail by mistake and = delete this e-mail from your system. If you are not the intended recipient = you are notified that disclosing, copying, distributing or taking any actio= n in reliance on the contents of this information is strictly prohibited.


    =


    This email and any files transmitted with it are confid= ential and intended solely for the use of the individual or entity to whom = they are addressed. If you have received this email in error please notify = the system manager. This message contains confidential information and is i= ntended only for the individual named. If you are not the named addressee y= ou should not disseminate, distribute or copy this e-mail. Please notify th= e sender immediately by e-mail if you have received this e-mail by mistake = and delete this e-mail from your system. If you are not the intended recipi= ent you are notified that disclosing, copying, distributing or taking any a= ction in reliance on the contents of this information is strictly prohibite= d.
    <signature.asc>_______________________________________________
    Id-event mailing list
    Id-event@ietf.org
    https://www.ietf.org/mailman/listinfo/id-event<= /a>


    ____________________= ___________________________
    Id-event mailing list
    Id-event@ietf.org
    https://www.ietf.org/mailman/listinfo/id-event




    --
    BBVA
    Luis Saiz Gimeno
    Innovation in Security
    M=C3=B3vil= +34=C2=A0609703264=C2=A0- Tel. +34=C2=A0918073152 -=C2=A0luis.saiz@bbva.com
    Engineering - Architecture &a= mp; Global Deployment =E2=80=93 Monforte de Lemo= s, s/n, 28029
    Maps: <= a href=3D"https://www.google.es/maps/place/Av.+de+Monforte+de+Lemos,+28,+28= 029+Madrid/" target=3D"_blank">https://www.google.es/maps/place/Av.+de+Monf= orte+de+Lemos,+28,+28029+Madrid/
    Antes de imprimir este mensaje, por favor comprueba que es ne= cesario hacerlo. Before you print this message please cons= ider if it is really necessary.
    <= /div>

    "Este mensaj= e est=C3=A1 dirigido de manera exclusiva a su destinatario y puede contener informaci= =C3=B3n privada y confidencial. No lo reenv=C3=ADe, copie o distribuya a terceros q= ue no deban conocer su contenido.=C2=A0En caso de haberlo recibido por error,=C2= =A0=C2=A0rogamos lo notifique al remitente y proceda a su borrado, as=C3=AD como al de cualq= uier documento que pudiera adjuntarse.

    <= span style=3D"font-size:7.0pt;font-family:"Arial","sans-seri= f";color:#758087">=C2=A0Por favor tenga en cuenta que los correos enviados v=C3=ADa Internet no permiten garantizar la confidenci= alidad de los mensajes ni su transmisi=C3=B3n de forma =C3=ADntegra.

    =C2=A0Las opi= niones expresadas en el presente correo pertenecen =C3=BAnicamente al remitente y no representan necesariamente la opini=C3=B3n del Grupo BBVA."

    =C2=A0"This message is intended exclusively for the adressee and may contain privileged= and confidential information. Please, do not disseminate, copy or distribute it= to third parties who should not receive it. In case you have received it by mistake, please inform the sender and delete the message and attachments fr= om your system.

    =C2=A0Please keep in mind that e-mails sent by Internet do not allow to guarantee neithe= r the confidentiality or the integrity of the messages sent."

    = _______________________________________________
    Id-event mailing listId-event@ietf.org
    https://www.ietf.org/mailman/listinfo/id-event

    _______________________________________________=
    Id-event mailing list
    Id-event@ietf.org
    https://www.ietf.org/mailman/listinfo/i= d-event