From nobody Fri Apr 1 11:11:03 2016 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8579E12D172; Fri, 1 Apr 2016 11:10:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=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 Nj0etGOlVd-U; Fri, 1 Apr 2016 11:10:57 -0700 (PDT) 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 B0FB412D0E6; Fri, 1 Apr 2016 11:10:57 -0700 (PDT) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u31IAu4J025336 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 1 Apr 2016 18:10:56 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id u31IAtFP012365 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 1 Apr 2016 18:10:56 GMT Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u31IAtwX019190; Fri, 1 Apr 2016 18:10:55 GMT Received: from [10.0.1.20] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 01 Apr 2016 11:10:55 -0700 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_89A68BBF-56ED-4A16-AD88-E5E5701CF6B5" Date: Fri, 1 Apr 2016 11:10:53 -0700 Message-Id: <0A230B0A-93C2-4CA7-8BB8-18AD0573F34F@oracle.com> To: id-event@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Mailer: Apple Mail (2.3112) X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Cc: "scim@ietf.org WG" , openid-general@lists.openid.net Subject: [Id-event] Identity Events - GitHub site X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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: Fri, 01 Apr 2016 18:10:59 -0000 --Apple-Mail=_89A68BBF-56ED-4A16-AD88-E5E5701CF6B5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii In order to provide more time for access prior to the Tuesday discussion = (during the SCIM slot at IETF95), I have posted all of the drafts that = have been worked on in github at: https://github.com/independentid/Identity-Events = The following drafts are available: draft-hunt-idevent-token-00 (published to IETF) - The event token format = based on JWT draft-hunt-idevent-scim-00 (published to IETF) - Event token extension = for SCIM draft-hunt-idevent-distribution-00 (unpublished) - Metadata and methods = for distributing events Also available (historical only): draft-hunt-scim-notify-00 (published to IETF) - An old SCIM submission = for historical purposes. draft-hunt-idevent-subscription-00 - An initial re-work of notify. = Replaced by draft-hunt-idevent-distribution. As I mentioned in an earlier email this week, the distribution draft = removes all of the protocol around how subscriptions are managed and = updated. It only defines the metadata and sets up a registry for = defining distribution methods. The draft includes the following methods = so far: - webCallback - Where the publisher uses HTTP POST to distribute events = to registered subscriber - poll - Where a subscriber uses HTTP GET to pick up events at a = subscriber endpoint from the publisher. This draft is still very preliminary, but I think it does serve the = purpose of getting discussion going. It also removes all of the SCIM specific semantics and focuses on general JSON and JWT = formatted messages. I will publish the distribution draft on Monday = when the submission window re-opens.=20 The work presented here has not yet been specifically implemented but is = strongly informed based on feedback from current production systems and = experience. Thanks for your comments and feedback.=20 Phil @independentid www.independentid.com = phil.hunt@oracle.com = --Apple-Mail=_89A68BBF-56ED-4A16-AD88-E5E5701CF6B5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii In order to provide more time for access prior to the Tuesday = discussion (during the SCIM slot at IETF95), I have posted all of the = drafts that have been worked on in github at:
https://github.com/independentid/Identity-Events

The following drafts are = available:

draft-hunt-idevent-token-00 (published to IETF) - The event = token format based on JWT
draft-hunt-idevent-scim-00 = (published to IETF) - Event token extension for SCIM
draft-hunt-idevent-distribution-00 (unpublished) - Metadata = and methods for distributing events

Also available (historical = only):
draft-hunt-scim-notify-00 (published to = IETF) - An old SCIM submission for historical purposes.
draft-hunt-idevent-subscription-00 - An initial re-work of = notify. Replaced by draft-hunt-idevent-distribution.

As I mentioned in an = earlier email this week, the distribution draft removes all of the = protocol around how subscriptions are managed and updated. It only = defines the metadata and sets up a registry for defining distribution = methods.  The draft includes the following methods so = far:
 - webCallback - Where the publisher uses = HTTP POST to distribute events to registered subscriber
 - poll - Where a subscriber uses HTTP GET to pick up = events at a subscriber endpoint from the publisher.

This draft is still very = preliminary, but I think it does serve the purpose of getting discussion = going. It also removes all
of the SCIM specific = semantics and focuses on general JSON and JWT formatted messages. =  I will publish the distribution draft on Monday when the = submission window re-opens. 

The work presented here has not yet = been specifically implemented but is strongly informed based on feedback = from current production systems and experience.

Thanks for your comments and = feedback. 

Phil

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





= --Apple-Mail=_89A68BBF-56ED-4A16-AD88-E5E5701CF6B5-- From nobody Mon Apr 4 19:15:26 2016 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A4E212D60A; Mon, 4 Apr 2016 19:15:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=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 rfyLqiteIycA; Mon, 4 Apr 2016 19:15:22 -0700 (PDT) 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 EAED112D5A9; Mon, 4 Apr 2016 19:15:21 -0700 (PDT) Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u352FKZZ012557 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 5 Apr 2016 02:15:21 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0022.oracle.com (8.14.4/8.13.8) with ESMTP id u352FJX5011038 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 5 Apr 2016 02:15:20 GMT Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u352FJcX000566; Tue, 5 Apr 2016 02:15:19 GMT Received: from dhcp-896a.meeting.ietf.org (/31.133.138.106) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 04 Apr 2016 19:15:19 -0700 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_8A22F07C-487E-4CB1-BB28-E9280F05E240" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Date: Mon, 4 Apr 2016 23:15:15 -0300 References: <20160405021126.13977.45272.idtracker@ietfa.amsl.com> To: "scim@ietf.org WG" , id-event@ietf.org, "" , openid-general@lists.openid.net X-Mailer: Apple Mail (2.3112) X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Subject: [Id-event] New Version Notification for draft-hunt-idevent-distribution-00.txt X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 05 Apr 2016 02:15:24 -0000 --Apple-Mail=_8A22F07C-487E-4CB1-BB28-E9280F05E240 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 FYI=E2=80=A6 I previously announced this draft as available in github. I=E2=80=99ve = published it tonight in advance of tomorrows discussion. Note that this is very preliminary and I=E2=80=99ve already had some = excellent feedback on improvements.=20 Looking forward to a good discussion tomorrow. Cheers, Phil @independentid www.independentid.com = phil.hunt@oracle.com = > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-hunt-idevent-distribution-00.txt > Date: April 4, 2016 at 11:11:26 PM GMT-3 > To: "Phil Hunt" , "Morteza Ansari" = >=20 >=20 > A new version of I-D, draft-hunt-idevent-distribution-00.txt > has been successfully submitted by Phil Hunt and posted to the > IETF repository. >=20 > Name: draft-hunt-idevent-distribution > Revision: 00 > Title: Identity Event Subscription Protocol > Document date: 2016-04-04 > Group: Individual Submission > Pages: 22 > URL: = https://www.ietf.org/internet-drafts/draft-hunt-idevent-distribution-00.tx= t > Status: = https://datatracker.ietf.org/doc/draft-hunt-idevent-distribution/ > Htmlized: = https://tools.ietf.org/html/draft-hunt-idevent-distribution-00 >=20 >=20 > Abstract: > This specification defines a registry to define methods to = distribute > identity events to subscribers. It includes a definition for > publishers to use HTTP POST to push events to clients via web > callback, and a method for subscribers to use HTTP GET to retrieve > events in a feed queue. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 --Apple-Mail=_8A22F07C-487E-4CB1-BB28-E9280F05E240 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 FYI=E2=80=A6

I previously announced this draft as available in github. = I=E2=80=99ve published it tonight in advance of tomorrows = discussion.

Note= that this is very preliminary and I=E2=80=99ve already had some = excellent feedback on improvements. 

Looking forward to a good discussion = tomorrow.

Cheers,




Begin forwarded message:

From: = internet-drafts@ietf.org
Subject: = New Version = Notification for draft-hunt-idevent-distribution-00.txt
Date: = April 4, 2016 at 11:11:26 PM = GMT-3
To: = "Phil Hunt" <phil.hunt@yahoo.com>, "Morteza Ansari" <morteza.ansari@cisco.com>

A new version = of I-D, draft-hunt-idevent-distribution-00.txt
has been = successfully submitted by Phil Hunt and posted to the
IETF = repository.

Name: = draft-hunt-idevent-distribution
Revision: 00
Title:= = Identity Event Subscription Protocol
Document = date: = 2016-04-04
Group: Individual Submission
Pages:= = 22
URL: =            https://www.ietf.org/internet-drafts/draft-hunt-idevent-distrib= ution-00.txt
Status: =         https://datatracker.ietf.org/doc/draft-hunt-idevent-distributio= n/
Htmlized:       https://tools.ietf.org/html/draft-hunt-idevent-distribution-00<= /a>


Abstract:
=   This specification defines a registry to define methods to = distribute
  identity events to subscribers. =  It includes a definition for
  publishers = to use HTTP POST to push events to clients via web
=   callback, and a method for subscribers to use HTTP GET to = retrieve
  events in a feed queue.




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

The IETF = Secretariat


= --Apple-Mail=_8A22F07C-487E-4CB1-BB28-E9280F05E240-- From nobody Fri Apr 8 08:00:12 2016 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDC9712D772 for ; Fri, 8 Apr 2016 08:00:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 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_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 3qrAflAd7cvG for ; Fri, 8 Apr 2016 08:00:05 -0700 (PDT) Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::236]) (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 9FF1E12D61C for ; Fri, 8 Apr 2016 08:00:05 -0700 (PDT) Received: by mail-ob0-x236.google.com with SMTP id fp4so74112686obb.2 for ; Fri, 08 Apr 2016 08:00:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=kium5VP3GcJk+XsBbOYunLYxJLOQkf4fOlY92gyYsDQ=; b=gI41lA39d4bddPBfoTrKQ52/I/uASRYxDCPhZZmOpsDHVJPng4cgjIFmBJgyTFHXKr j+P7Qzk/I63WHlgD6FT48QCF4oOi+Lfq6XpcRmKVXy7V3jEPzDAADysTR5yVHQeUKAGn h047e9WZ0Mj3OXDhQ45T5CtVAUIgPX732r0NAuuM9EJAqSZ+IwoLkBUqTUYw8PXBAxuM wNRIsP+ifOGkjADe/80aY5hB+olzfr0PfolPwGdgIoF06z6KygmZesAc9Ov4UC3Ro7nz M6/MM96x0cOFOY8uROz9kLfxpXM7gLrVRKG0dkl7ytjC5Fg6r0Hmdua8JO3eyNnFOtG0 ohWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=kium5VP3GcJk+XsBbOYunLYxJLOQkf4fOlY92gyYsDQ=; b=JcVOKIeaBL45t+GVTNH+szpbIwfGUZyrgzudaTxLhR89pURXLgy8uAw2cgc0ucFbsn RGtFU1iOUNi1lBX9ysJbUIggWU2OiQCd3PeszExPJb8agNS+3JpczmE2VjJRB1FGqOj9 Ho4sg9cnjlWwYkZzHHNd0xqGbUqy/RUWyGmecRdNS20vXeJOUup3Ch0Otw7zKii6KSEz MMxp6PdyWducBswVERje5Fyx4EcXxQoUUaQ5IUahzyuhsTODKRPmLhBPWWQCWLATyOIx 90IiZk//O6ol7tQZnbqKRbOj2i1sBFl/q3/muYR8nMVK2I+OloldpHIahbGaUAeOkRTO Gqqg== X-Gm-Message-State: AD7BkJJZnpANQxLZfjTB93/bCRuu1YqhWuQzDHMGE8NMD5U3MohZwPfvKHPl/JUhvfyUoJg08EAu1Yy2h1yCNt4P X-Received: by 10.60.35.201 with SMTP id k9mr4672385oej.3.1460127604880; Fri, 08 Apr 2016 08:00:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.79.233 with HTTP; Fri, 8 Apr 2016 07:59:45 -0700 (PDT) From: William Denniss Date: Fri, 8 Apr 2016 11:59:45 -0300 Message-ID: To: id-event@ietf.org Content-Type: multipart/alternative; boundary=089e011613bc379eef052ffa7334 Archived-At: Subject: [Id-event] Proposed changes to the event spec X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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: Fri, 08 Apr 2016 15:00:11 -0000 --089e011613bc379eef052ffa7334 Content-Type: text/plain; charset=UTF-8 Yesterday, Mike, John, Nat and I workshopped the draft OpenID Back-Channel Logout Token format to see what it would look like formatted as an id-event. We used a URL for the event type (to avoid registering a URN, and also because URLs can be self-documenting which is nice, and we've used this structure before in OpenID). The outcome was pretty good, take a look at the post to the OpenID Connect WG here: http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20160404/006016.html Here's the example logout token we came up with: { "iss": "https://server.example.com", "aud": "s6BhdRkqt3", "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", "sub": "248289761001", "iat": 1458668180, "exp": 1458668580, "events": [ "https://specs.openid.net/logout" ], "https://specs.openid.net/logout": { "sid": "08a5019c-17e1-4977-8f42-65a12843ea02" } } I've made a few proposed changes to the id-events spec, including simplifying the claim name from "eventURIs" to just "events", and added this example to the spec, as well as some minor editorial changes. Please review my changes: https://github.com/independentid/Identity-Events/pull/1 William --089e011613bc379eef052ffa7334 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yesterday, Mike, John, Nat and I workshopped the draf= t OpenID=C2=A0Back-Channel Logout Token=C2=A0format to see what it would lo= ok like formatted as an id-event.

We used a URL fo= r the event type (to avoid registering a URN, and also because URLs can be = self-documenting which is nice, and we've used this structure before in= OpenID).=C2=A0 The outcome was pretty good, take a look at the post to the= OpenID Connect WG here:=C2=A0http://lists.openid.net/p= ipermail/openid-specs-ab/Week-of-Mon-20160404/006016.html
Here's the example logout token we came up with:
=

=C2=A0 {
=C2=A0 =C2=A0 =C2=A0= "iss": "https://ser= ver.example.com",
=C2=A0 =C2= =A0 =C2=A0 "aud": "s6BhdRkqt3",
=C2=A0 =C2=A0 =C2=A0 "jti": "3d0c3cf797584bd19= 3bd0fb1bd4e7d30",
=C2=A0 =C2=A0 = =C2=A0 "sub": "248289761001",
=C2=A0 =C2=A0 =C2=A0 "iat": 1458668180,
=C2=A0 =C2=A0 =C2=A0 "exp": 1458668580,
=C2=A0 =C2=A0 =C2=A0 "events"= : [
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= "https://specs.openid.net= /logout"
=C2=A0 =C2=A0 =C2=A0= ],
=C2=A0 =C2=A0 =C2=A0 "https://specs.openid.net/logout&qu= ot;: {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 "sid": "08a5019c-17e1-4977-8f42-65a12843ea02"
=
=C2=A0 =C2=A0 =C2=A0 }
=C2=A0 }

I've made a fe= w proposed changes to the id-events spec, including simplifying the claim n= ame from "eventURIs" to just "events", and added this e= xample to the spec, as well as some minor editorial changes.

=
Please review my changes:
https://github.com/independentid/Identit= y-Events/pull/1

William
--089e011613bc379eef052ffa7334-- From nobody Fri Apr 8 08:18:53 2016 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D86312D91C for ; Fri, 8 Apr 2016 08:18:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=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 E-WlayXLmsna for ; Fri, 8 Apr 2016 08:18:50 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (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 EE54A12D92C for ; Fri, 8 Apr 2016 08:18:48 -0700 (PDT) X-AuditID: 12074424-8bfff700000073db-c3-5707cbd79576 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 68.2C.29659.7DBC7075; Fri, 8 Apr 2016 11:18:47 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id u38FIl7t016154; Fri, 8 Apr 2016 11:18:47 -0400 Received: from artemisia.richer.local (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 u38FIj7A032000 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 8 Apr 2016 11:18:46 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_77D8BE67-DC61-442B-9CF8-0EB04EB3DA31" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Justin Richer In-Reply-To: Date: Fri, 8 Apr 2016 11:18:45 -0400 Message-Id: <0BBB465A-B002-41B0-A30D-C2DED8ADA933@mit.edu> References: To: William Denniss X-Mailer: Apple Mail (2.3112) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgleLIzCtJLcpLzFFi42IR4hRV1r1+mj3coPuzrkXHgm4mi01zmtkd mDwWbCr1WLLkJ1MAUxSXTUpqTmZZapG+XQJXxqNZzYwFXWYV//Y2szQwduh3MXJySAiYSEze cYi5i5GLQ0igjUni/rY+RghnA6NEy5J2KOcBk8THt81ADgcHs0CCxNw9CiDdvAJ6EidW7WYF sYUFrCRW7ZrOBGKzCahKTF/TAmZzCgRK9LybwgTSyiKgInHuWgZImFlAVGLKowksIGFeoNbG a5IgYSGBAIllf6eAdYoIaEq8PHuABeJOWYl9GxawTWDkn4VwwywkN8wCG6otsWzha2YIW1Ni f/dyFkxxDYnObxNZFzCyrWKUTcmt0s1NzMwpTk3WLU5OzMtLLdI118vNLNFLTSndxAgKaHYX lR2M3T3ehxgFOBiVeHgvvGcLF2JNLCuuzD3EKMnBpCTKq3OKPVyILyk/pTIjsTgjvqg0J7X4 EKMEB7OSCO98kBxvSmJlVWpRPkxKmoNFSZyXkYGBQUggPbEkNTs1tSC1CCYrw8GhJMHLBIxc IcGi1PTUirTMnBKENBMHJ8hwHqDhnCA1vMUFibnFmekQ+VOMilLivCEgWwVAEhmleXC9oIST 8Paw6StGcaBXhHmLQap4gMkKrvsV0GAmoMEX+NlABpckIqSkGhiTysxffdjtuXhK7b2AwG9a d8ocJqrscZL/dzv4qtbdY3PK9tQErbrkeoFrS/khk7TQm925Mqv8A05/Vg4p1orgn6gbpqD9 mpWtifExk01e+bWqhCf8chM5zmbnP2Sf9j77+vw39WU7/gqFXm72fPl1l43L4hV90cHSFZc2 WPy9ujbw2qSJOj5KLMUZiYZazEXFiQCHf6wHEwMAAA== Archived-At: Cc: id-event@ietf.org Subject: Re: [Id-event] Proposed changes to the event spec X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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: Fri, 08 Apr 2016 15:18:52 -0000 --Apple-Mail=_77D8BE67-DC61-442B-9CF8-0EB04EB3DA31 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I know I missed the discussion the other day, but I have a question = about the data structure: What=E2=80=99s the purpose of having the =E2=80=9Cevents=E2=80=9D array = below if the values of said array are going to be keys in the overlying = object? It seems unnecessary duplication of information. =E2=80=94 Justin > On Apr 8, 2016, at 10:59 AM, William Denniss = wrote: >=20 > Yesterday, Mike, John, Nat and I workshopped the draft OpenID = Back-Channel Logout Token format to see what it would look like = formatted as an id-event. >=20 > We used a URL for the event type (to avoid registering a URN, and also = because URLs can be self-documenting which is nice, and we've used this = structure before in OpenID). The outcome was pretty good, take a look = at the post to the OpenID Connect WG here: = http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20160404/006= 016.html = >=20 > Here's the example logout token we came up with: >=20 > { > "iss": "https://server.example.com = ", > "aud": "s6BhdRkqt3", > "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", > "sub": "248289761001", > "iat": 1458668180, > "exp": 1458668580, > "events": [ > "https://specs.openid.net/logout = " > ], > "https://specs.openid.net/logout = ": { > "sid": "08a5019c-17e1-4977-8f42-65a12843ea02" > } > } >=20 > I've made a few proposed changes to the id-events spec, including = simplifying the claim name from "eventURIs" to just "events", and added = this example to the spec, as well as some minor editorial changes. >=20 > Please review my changes: > https://github.com/independentid/Identity-Events/pull/1 = >=20 > William > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event --Apple-Mail=_77D8BE67-DC61-442B-9CF8-0EB04EB3DA31 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I know I missed the discussion the other day, but I have a = question about the data structure:

What=E2=80=99s the purpose of having = the =E2=80=9Cevents=E2=80=9D array below if the values of said array are = going to be keys in the overlying object? It seems unnecessary = duplication of information.

 =E2=80=94 Justin

On = Apr 8, 2016, at 10:59 AM, William Denniss <wdenniss@google.com>= wrote:

Yesterday, Mike, = John, Nat and I workshopped the draft OpenID Back-Channel Logout = Token format to see what it would look like formatted as an = id-event.

We = used a URL for the event type (to avoid registering a URN, and also = because URLs can be self-documenting which is nice, and we've used this = structure before in OpenID).  The outcome was pretty good, take a = look at the post to the OpenID Connect WG here: http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-2= 0160404/006016.html

Here's the example logout token we came up with:

  {
      "iss": "https://server.example.com",
      "aud": = "s6BhdRkqt3",
  =     "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30",
      "sub": = "248289761001",
  =     "iat": 1458668180,
      "exp": 1458668580,
      "events": = [
      =     "https://specs.openid.net/logout"
      ],
      "https://specs.openid.net/logout": {
          = "sid": "08a5019c-17e1-4977-8f42-65a12843ea02"
      }
  }

I've made a few proposed = changes to the id-events spec, including simplifying the claim name from = "eventURIs" to just "events", and added this example to the spec, as = well as some minor editorial changes.

Please review my changes:
https://github.com/independentid/Identity-Events/pull/1
William
_______________________________________________
Id-event = mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event

= --Apple-Mail=_77D8BE67-DC61-442B-9CF8-0EB04EB3DA31-- From nobody Fri Apr 8 08:20:12 2016 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C6B112D51D for ; Fri, 8 Apr 2016 08:20:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.541 X-Spam-Level: X-Spam-Status: No, score=-3.541 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sunet.se 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 AfHvWXkcNYhN for ; Fri, 8 Apr 2016 08:20:07 -0700 (PDT) Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [IPv6:2001:6b0:8:2::201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5909D12D548 for ; Fri, 8 Apr 2016 08:20:07 -0700 (PDT) Received: from smtp1.sunet.se (smtp1.sunet.se [192.36.171.214]) by e-mailfilter01.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id u38FK4oC018815 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Fri, 8 Apr 2016 17:20:04 +0200 Received: from kerio.sunet.se (kerio.sunet.se [192.36.171.210]) by smtp1.sunet.se (8.14.9/8.14.7) with ESMTP id u38FK19d019566 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 8 Apr 2016 17:20:04 +0200 (CEST) VBR-Info: md=sunet.se; mc=all; mv=swamid.se DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sunet.se; s=default; t=1460128804; bh=xE93hP7DcgioZQmLms3/GkWXseQCPwA04opJubuaCLc=; h=Subject:To:References:From:Date:In-Reply-To; b=RFZYRDd9EkvW8vMwYSrfQlgz7Sl1EOGNm8kxNIpYXTDi/6SA8MLOjgt7rJxeuRXhj qQOxdqbo049cE4xaj5yPU1i1cNfpxmgheYrdBrOpCsbbxhFPQZruFEFvocprx317PH gZaUp8SURoSXo4EBhx1NKfCZHet88Q4tfVpJx2JM= X-Footer: c3VuZXQuc2U= Received: from [172.16.4.7] ([200.61.9.66]) (authenticated user leifj@sunet.se) by kerio.sunet.se (Kerio Connect 9.0.1) with ESMTPSA (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128 bits)) for id-event@ietf.org; Fri, 8 Apr 2016 17:19:58 +0200 To: id-event@ietf.org References: <0BBB465A-B002-41B0-A30D-C2DED8ADA933@mit.edu> From: Leif Johansson Message-ID: <5707CC1B.20908@sunet.se> Date: Fri, 8 Apr 2016 17:19:55 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <0BBB465A-B002-41B0-A30D-C2DED8ADA933@mit.edu> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-CanIt-Geo: ip=192.36.171.210; country=SE; latitude=59.3294; longitude=18.0686; http://maps.google.com/maps?q=59.3294,18.0686&z=6 X-CanItPRO-Stream: outbound-sunet-se:outbound (inherits from outbound-sunet-se:default, sunet-se:default, base:default) X-Canit-Stats-ID: 09QDPk4q3 - b8a32340f7d9 - 20160408 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw Received-SPF: neutral (e-mailfilter01.sunet.se: 192.36.171.210 is neither permitted nor denied by domain leifj@sunet.se) receiver=e-mailfilter01.sunet.se; client-ip=192.36.171.210; envelope-from=; helo=smtp1.sunet.se; identity=mailfrom X-Scanned-By: CanIt (www . roaringpenguin . com) on 192.36.171.201 Archived-At: Subject: Re: [Id-event] Proposed changes to the event spec X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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: Fri, 08 Apr 2016 15:20:11 -0000 On 2016-04-08 17:18, Justin Richer wrote: > I know I missed the discussion the other day, but I have a question > about the data structure: > > What’s the purpose of having the “events” array below if the values of > said array are going to be keys in the overlying object? It seems > unnecessary duplication of information. I guess cause it allows you to identity what part of the structure you have to care about if you treat this as an "event" > > — Justin > >> On Apr 8, 2016, at 10:59 AM, William Denniss > > wrote: >> >> Yesterday, Mike, John, Nat and I workshopped the draft >> OpenID Back-Channel Logout Token format to see what it would look like >> formatted as an id-event. >> >> We used a URL for the event type (to avoid registering a URN, and also >> because URLs can be self-documenting which is nice, and we've used >> this structure before in OpenID). The outcome was pretty good, take a >> look at the post to the OpenID Connect WG >> here: http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20160404/006016.html >> >> Here's the example logout token we came up with: >> >> { >> "iss": "https://server.example.com ", >> "aud": "s6BhdRkqt3", >> "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", >> "sub": "248289761001", >> "iat": 1458668180, >> "exp": 1458668580, >> "events": [ >> "https://specs.openid.net/logout" >> ], >> "https://specs.openid.net/logout": { >> "sid": "08a5019c-17e1-4977-8f42-65a12843ea02" >> } >> } >> >> I've made a few proposed changes to the id-events spec, including >> simplifying the claim name from "eventURIs" to just "events", and >> added this example to the spec, as well as some minor editorial changes. >> >> Please review my changes: >> https://github.com/independentid/Identity-Events/pull/1 >> >> William >> _______________________________________________ >> 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 > From nobody Fri Apr 8 08:32:40 2016 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C88E12D8E2 for ; Fri, 8 Apr 2016 08:32:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=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 HV3u2Fklpgn6 for ; Fri, 8 Apr 2016 08:32:36 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (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 4D3B312D93C for ; Fri, 8 Apr 2016 08:32:31 -0700 (PDT) Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u38FWUBt003899 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 8 Apr 2016 15:32:30 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0022.oracle.com (8.14.4/8.13.8) with ESMTP id u38FWT1Y003345 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 8 Apr 2016 15:32:29 GMT Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id u38FWOUn026213; Fri, 8 Apr 2016 15:32:28 GMT Received: from dhcp-896a.meeting.ietf.org (/31.133.138.106) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 08 Apr 2016 08:32:24 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_8EFDA985-D621-4AEA-AEC5-C0EDA599EB5B" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Phil Hunt In-Reply-To: <5707CC1B.20908@sunet.se> Date: Fri, 8 Apr 2016 12:32:19 -0300 Message-Id: References: <0BBB465A-B002-41B0-A30D-C2DED8ADA933@mit.edu> <5707CC1B.20908@sunet.se> To: Leif Johansson X-Mailer: Apple Mail (2.3112) X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Cc: id-event@ietf.org Subject: Re: [Id-event] Proposed changes to the event spec X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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: Fri, 08 Apr 2016 15:32:38 -0000 --Apple-Mail=_8EFDA985-D621-4AEA-AEC5-C0EDA599EB5B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Justin, Some events will be self defining=85especially if all that is needed is = the =93sub=94 as the target of the event. E.g. sub could be a token id you want to revoke... { "iss": "https://server.example.com = >", "aud": "s6BhdRkqt3", "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", "sub": "248289761001", "iat": 1458668180, "exp": 1458668580, "events": [ "https://tools.ietf.org/html/rfc6749#revoke" ] } Phil @independentid www.independentid.com = phil.hunt@oracle.com = > On Apr 8, 2016, at 12:19 PM, Leif Johansson wrote: >=20 > On 2016-04-08 17:18, Justin Richer wrote: >> I know I missed the discussion the other day, but I have a question >> about the data structure: >>=20 >> What=92s the purpose of having the =93events=94 array below if the = values of >> said array are going to be keys in the overlying object? It seems >> unnecessary duplication of information. >=20 > I guess cause it allows you to identity what part of the structure you > have to care about if you treat this as an "event" >=20 >>=20 >> =97 Justin >>=20 >>> On Apr 8, 2016, at 10:59 AM, William Denniss >>> >> wrote: >>>=20 >>> Yesterday, Mike, John, Nat and I workshopped the draft >>> OpenID Back-Channel Logout Token format to see what it would look = like >>> formatted as an id-event. >>>=20 >>> We used a URL for the event type (to avoid registering a URN, and = also >>> because URLs can be self-documenting which is nice, and we've used >>> this structure before in OpenID). The outcome was pretty good, take = a >>> look at the post to the OpenID Connect WG >>> here: = http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20160404/006= 016.html = >>>=20 >>> Here's the example logout token we came up with: >>>=20 >>> { >>> "iss": "https://server.example.com = >", >>> "aud": "s6BhdRkqt3", >>> "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", >>> "sub": "248289761001", >>> "iat": 1458668180, >>> "exp": 1458668580, >>> "events": [ >>> "https://specs.openid.net/logout" >>> ], >>> "https://specs.openid.net/logout": { >>> "sid": "08a5019c-17e1-4977-8f42-65a12843ea02" >>> } >>> } >>>=20 >>> I've made a few proposed changes to the id-events spec, including >>> simplifying the claim name from "eventURIs" to just "events", and >>> added this example to the spec, as well as some minor editorial = changes. >>>=20 >>> Please review my changes: >>> https://github.com/independentid/Identity-Events/pull/1 >>>=20 >>> William >>> _______________________________________________ >>> Id-event mailing list >>> Id-event@ietf.org = > >>> https://www.ietf.org/mailman/listinfo/id-event = >>=20 >>=20 >>=20 >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://www.ietf.org/mailman/listinfo/id-event = >>=20 >=20 >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event = --Apple-Mail=_8EFDA985-D621-4AEA-AEC5-C0EDA599EB5B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Justin,

Some events will be self defining=85especially if all that is = needed is the =93sub=94 as the target of the event.

E.g. sub could be a = token id you want to revoke...

 {
     "iss": "https://server.example.com <https://server.example.com/>",
     "aud": "s6BhdRkqt3",
     "jti": = "3d0c3cf797584bd193bd0fb1bd4e7d30",
     "sub": "248289761001",
     "iat": 1458668180,
     "exp": 1458668580,
     "events": [
         "https://tools.ietf.org/html/rfc6749#revoke"
     ]
 }





On Apr 8, 2016, at 12:19 PM, Leif Johansson <leifj@sunet.se> = wrote:

On 2016-04-08 17:18, Justin Richer = wrote:
I know I = missed the discussion the other day, but I have a question
about the data structure:

What=92s= the purpose of having the =93events=94 array below if the values of
said array are going to be keys in the overlying object? It = seems
unnecessary duplication of information.

I guess cause it allows you to identity what = part of the structure you
have to care about if you treat this as an = "event"


=97 Justin

On Apr 8, = 2016, at 10:59 AM, William Denniss <wdenniss@google.com
<mailto:wdenniss@google.com>> wrote:
Yesterday, Mike, John, Nat and I workshopped the draft
OpenID Back-Channel Logout Token format to see what it would = look like
formatted as an id-event.

We used a URL for the event type (to avoid registering a URN, = and also
because URLs can be self-documenting which is = nice, and we've used
this structure before in OpenID). =  The outcome was pretty good, take a
look at the post = to the OpenID Connect WG
here: http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-2= 0160404/006016.html

Here's the example = logout token we came up with:

 {
     "iss": "https://server.example.com <https://server.example.com/>",
     "aud": "s6BhdRkqt3",
     "jti": = "3d0c3cf797584bd193bd0fb1bd4e7d30",
     "sub": "248289761001",
     "iat": 1458668180,
     "exp": 1458668580,
     "events": [
         "https://specs.openid.net/logout"
     ],
     "https://specs.openid.net/logout": {
         "sid": = "08a5019c-17e1-4977-8f42-65a12843ea02"
     }
 }

I've made a few proposed changes to the = id-events spec, including
simplifying the claim name from = "eventURIs" to just "events", and
added this example to = the spec, as well as some minor editorial changes.

Please review my changes:
https://github.com/independentid/Identity-Events/pull/1

William
_______________________________________________
Id-event mailing list
Id-event@ietf.org <mailto: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

= --Apple-Mail=_8EFDA985-D621-4AEA-AEC5-C0EDA599EB5B-- From nobody Fri Apr 8 08:38:39 2016 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BAFB12D955 for ; Fri, 8 Apr 2016 08:38:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 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_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 5mKgxwCxdNFx for ; Fri, 8 Apr 2016 08:38:34 -0700 (PDT) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003: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 5EA7912D8DF for ; Fri, 8 Apr 2016 08:38:34 -0700 (PDT) Received: by mail-oi0-x22a.google.com with SMTP id w85so140645558oiw.0 for ; Fri, 08 Apr 2016 08:38:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=9gVtDWTrhJl1IqcPyX+ewhQah7gZY6qw+HP+tlHqFoA=; b=K7bF8Fz3fhA/WNS8+Zv9hYqfRhy7hQuWBHz18/9l1WjC1qsh3fL/SN7HDpe67rIWyY Y7Dt5kXSU+iUihC51SQ4Dl64lSsBs2LAZnXGXeevX24SPMUhL89MULjmlc1s9mAg6LBv QihfKECniGv3balY3qT2t/SGPb9ZttBSDrcIUT8WJiH+0VEmgVTZLAMQmdlLN+L38Rcw dY2dA4fGV3hCeKwiHF8YxdGLECK0i4OV6Vr888Px5MeslJPFFqyhCGWkEjDdN3/BqHx1 elgX3furTcDHqXHOlCvFZXi3ZExYWUD0clNc1xeyrWOkDVI0bsKIXh0hBmLU5jaJUd7w zNVA== 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; bh=9gVtDWTrhJl1IqcPyX+ewhQah7gZY6qw+HP+tlHqFoA=; b=kLJr5RidkzXX6WDMaSnathCjXidlaQPzMX6NqW5b/H3lqUaaUfxc3wpDPbSsTd7/gr jL/cKIroEQCxG4NY9yvzrb4Asvy5rJAz68w3eIShsmDuMrSCJsIakJ/Yunjj4wpWqyFd in64Gm3NMDY6O29pm1IwxvLbJbnP0fc82rp4PnnzV63YBvJcK5UkORhO/wYY6XLdd5tj 0UyDWs8eJhG/lqmF88DKTPjvaHVqa3W0f8P+yngl7/YU669gC5uA4EoK40OdNoxLOxgw nbzETGFKBPiBDuqNcljejWFbzh+Wv08F+Jc8FhcLoN4CM6pZh2yA9QEHCFKFPSPCJRdv VMOw== X-Gm-Message-State: AD7BkJIltwR2DegLMFBQXQa8WJWEVdoV5YUSQMk6ObVLTfO9dPxHeyzyNfTlqX9ouQQ/NvyPq6Ky9NngUw7vPYqg X-Received: by 10.157.41.70 with SMTP id d64mr4843950otb.116.1460129913588; Fri, 08 Apr 2016 08:38:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.79.233 with HTTP; Fri, 8 Apr 2016 08:38:14 -0700 (PDT) In-Reply-To: <5707CC1B.20908@sunet.se> References: <0BBB465A-B002-41B0-A30D-C2DED8ADA933@mit.edu> <5707CC1B.20908@sunet.se> From: William Denniss Date: Fri, 8 Apr 2016 12:38:14 -0300 Message-ID: To: Leif Johansson , id-event@ietf.org Content-Type: multipart/alternative; boundary=94eb2c0349c4d390f0052ffafcae Archived-At: Subject: Re: [Id-event] Proposed changes to the event spec X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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: Fri, 08 Apr 2016 15:38:38 -0000 --94eb2c0349c4d390f0052ffafcae Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The "events" claim tells you that it's an event JWT without you needing to scan for all events you support (and it means you'll also be able to know if it's an event that perhaps you don't support). Otherwise they could be confused with collision-resistant public claims . Also, it's possible that the event is so simple it actually doesn't even need its own attribute dictionary. Thought of that after I sent the pull request, will make a new revision shortly. In this simple case, declaring the event's type is enough. E.g.: { "iss": "https://server.example.com", "aud": "s6BhdRkqt3", "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", "sub": "248289761001", "iat": 1458668180, "exp": 1458668580, "events": [ "https://specs.openid.net/logout" ], "sid": "08a5019c-17e1-4977-8f42-65a12843ea02" } NB. we expect "sid" (session id) to be a standard JWT claim in Connect going forward as it's needed by a few different specs in progress, hence why it wouldn't need to be an event-specific attribute. On Fri, Apr 8, 2016 at 12:20 PM Leif Johansson wrote: > On 2016-04-08 17:18, Justin Richer wrote: > > I know I missed the discussion the other day, but I have a question > > about the data structure: > > > > What=E2=80=99s the purpose of having the =E2=80=9Cevents=E2=80=9D array= below if the values of > > said array are going to be keys in the overlying object? It seems > > unnecessary duplication of information. > > I guess cause it allows you to identity what part of the structure you > have to care about if you treat this as an "event" > > > > > =E2=80=94 Justin > > > >> On Apr 8, 2016, at 10:59 AM, William Denniss >> > wrote: > >> > >> Yesterday, Mike, John, Nat and I workshopped the draft > >> OpenID Back-Channel Logout Token format to see what it would look like > >> formatted as an id-event. > >> > >> We used a URL for the event type (to avoid registering a URN, and also > >> because URLs can be self-documenting which is nice, and we've used > >> this structure before in OpenID). The outcome was pretty good, take a > >> look at the post to the OpenID Connect WG > >> here: > http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20160404/00= 6016.html > >> > >> Here's the example logout token we came up with: > >> > >> { > >> "iss": "https://server.example.com >", > >> "aud": "s6BhdRkqt3", > >> "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", > >> "sub": "248289761001", > >> "iat": 1458668180, > >> "exp": 1458668580, > >> "events": [ > >> "https://specs.openid.net/logout" > >> ], > >> "https://specs.openid.net/logout": { > >> "sid": "08a5019c-17e1-4977-8f42-65a12843ea02" > >> } > >> } > >> > >> I've made a few proposed changes to the id-events spec, including > >> simplifying the claim name from "eventURIs" to just "events", and > >> added this example to the spec, as well as some minor editorial change= s. > >> > >> Please review my changes: > >> https://github.com/independentid/Identity-Events/pull/1 > >> > >> William > >> _______________________________________________ > >> 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 > --94eb2c0349c4d390f0052ffafcae Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The "events"= claim tells you that it's an event JWT without you needing to scan for= all events you support (and it means you'll also be able to know if it= 's an event that perhaps you don't support). Otherwise they could b= e confused with collision-resistant public claims.

Also, it's possible= that the event is so simple it actually doesn't even need its own attr= ibute dictionary. Thought of that after I sent the pull request, will make= a new revision shortly. In this simple case, declaring the event's typ= e is enough.

E.g.:
{
=C2= =A0 "iss": "https://server.example.com",
=C2=A0 "au= d": "s6BhdRkqt3",
=C2=A0 "jti": "3d= 0c3cf797584bd193bd0fb1bd4e7d30",
=C2=A0 "sub": &qu= ot;248289761001",
=C2=A0 "iat": 1458668180,
<= div>=C2=A0 "exp": 1458668580,
=C2=A0 "events"= : [
= =C2=A0 ],
= =C2=A0 "sid": "08a5019c-17e1-4977-8f42-65a12843ea02"
}


NB. we expect "sid" (session id) to be a sta= ndard JWT claim in Connect going forward as it's needed by a few differ= ent specs in progress, hence why it wouldn't need to be an event-specif= ic attribute.


On Fri, Apr 8, 2016 at 12:20 PM Leif Johansson <leifj@sunet.se> wrote:
<= /div>
On 2016-04-08 17:18, Justin Richer wrote:
> I know I missed the discussion the other day, but I have a question > about the data structure:
>
> What=E2=80=99s the purpose of having the =E2=80=9Cevents=E2=80=9D arra= y below if the values of
> said array are going to be keys in the overlying object? It seems
> unnecessary duplication of information.

I guess cause it allows you to identity what part of the structure you
have to care about if you treat this as an "event"

>
>=C2=A0 =E2=80=94 Justin
>
>> On Apr 8, 2016, at 10:59 AM, William Denniss <wdenniss@google.com
>> <mailto:wdenniss@google.com>> wrote:
>>
>> Yesterday, Mike, John, Nat and I workshopped the draft
>> OpenID Back-Channel Logout Token format to see what it would look = like
>> formatted as an id-event.
>>
>> We used a URL for the event type (to avoid registering a URN, and = also
>> because URLs can be self-documenting which is nice, and we've = used
>> this structure before in OpenID).=C2=A0 The outcome was pretty goo= d, take a
>> look at the post to the OpenID Connect WG
>> here: htt= p://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20160404/006016.= html
>>
>> Here's the example logout token we came up with:
>>
>>=C2=A0 =C2=A0{
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0"iss": "https://server.e= xample.com <https://server.example.com/>",
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0"aud": "s6BhdRkqt3",=
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0"jti": "3d0c3cf797584bd19= 3bd0fb1bd4e7d30",
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0"sub": "248289761001"= ;,
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0"iat": 1458668180,
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0"exp": 1458668580,
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0"events": [
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"https://specs.= openid.net/logout"
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0],
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0"https://specs.openid.net/log= out": {
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"sid": "08a= 5019c-17e1-4977-8f42-65a12843ea02"
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0}
>>=C2=A0 =C2=A0}
>>
>> I've made a few proposed changes to the id-events spec, includ= ing
>> simplifying the claim name from "eventURIs" to just &quo= t;events", and
>> added this example to the spec, as well as some minor editorial ch= anges.
>>
>> Please review my changes:
>> https://github.com/independentid/Ide= ntity-Events/pull/1
>>
>> William
>> _______________________________________________
>> Id-event mailing list
>> Id-event@ie= tf.org <mailto:Id-event@ietf.org>
>> https://www.ietf.org/mailman/listinfo/id-even= t
>
>
>
> _______________________________________________
> Id-event mailing list
> Id-event@ietf.o= rg
> https://www.ietf.org/mailman/listinfo/id-event
>


_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event
--94eb2c0349c4d390f0052ffafcae-- From nobody Fri Apr 8 09:10:04 2016 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE0BB12D1AB for ; Fri, 8 Apr 2016 09:10:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=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 FmQMwQVpmrNz for ; Fri, 8 Apr 2016 09:10:00 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (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 D7E7212D196 for ; Fri, 8 Apr 2016 09:09:59 -0700 (PDT) X-AuditID: 1209190c-b4bff700000018df-10-5707d7d61d88 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 22.59.06367.6D7D7075; Fri, 8 Apr 2016 12:09:58 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id u38G9v1R026505; Fri, 8 Apr 2016 12:09:58 -0400 Received: from artemisia.richer.local (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 u38G9tmP021461 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 8 Apr 2016 12:09:57 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_44605C45-A313-42F9-8F6F-13038E691FC9" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Justin Richer In-Reply-To: Date: Fri, 8 Apr 2016 12:09:55 -0400 Message-Id: <547FBBB4-2FA7-4E21-ABDA-2C426D554B71@mit.edu> References: <0BBB465A-B002-41B0-A30D-C2DED8ADA933@mit.edu> <5707CC1B.20908@sunet.se> To: William Denniss X-Mailer: Apple Mail (2.3112) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplleLIzCtJLcpLzFFi42IR4hRV1r12nT3cYFmzrkXHgm4miwW9W5kt Ns1pZndg9liwqdRjyZKfTB57N/WxBzBHcdmkpOZklqUW6dslcGW0fu9hLmiuqfjR7NbA+DS7 i5GTQ0LAROLlkTPsXYxcHEICbUwSh9aeZoJwNjBK/Hz6jBHCecAkcbTzBxNIC7NAgsTHy0tY QWxeAT2JE6t2g9nCAlYSq3ZNB6thE1CVmL6mBczmFAiUeNu6Dcjm4GARUJH4s0IEYoyZRG/D FDaIMUCt556xQuy6xyjR9+0mWEJEQFPi5dkDLBCnykrs27CAbQIj/ywkZ8xCcgZEXFti2cLX zBC2psT+7uUsmOIaEp3fJrIuYGRbxSibklulm5uYmVOcmqxbnJyYl5dapGuol5tZopeaUrqJ ERzqkjw7GM+88TrEKMDBqMTDe+E9W7gQa2JZcWXuIUZJDiYlUV6dU+zhQnxJ+SmVGYnFGfFF pTmpxYcYJTiYlUR4Wa4A5XhTEiurUovyYVLSHCxK4ryF+0+HCQmkJ5akZqemFqQWwWRlODiU JHgPXQNqFCxKTU+tSMvMKUFIM3FwggznARreDVLDW1yQmFucmQ6RP8WoKCXOewYkIQCSyCjN g+sFpaKEt4dNXzGKA70izCsDTExCPMA0Btf9CmgwE9DgC/xsIINLEhFSUg2M12d83zu/VvD7 hbC7Nlr/bM4GMqafVlpzyNLJ64Hyau571x3V+gVStfYYdj9Q6TEz4lgz81VqzbLbik6KUma7 prI/Y9Z+uHtegmlU74/vM8yevA8tuhZgrPpd0Oz1GpNHE18FqH/+XbBRdw/XQmnmyS++9LC8 PG94aLm+52ZhV/FSXVGew6tElViKMxINtZiLihMBxF22BCADAAA= Archived-At: Cc: Leif Johansson , id-event@ietf.org Subject: Re: [Id-event] Proposed changes to the event spec X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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: Fri, 08 Apr 2016 16:10:04 -0000 --Apple-Mail=_44605C45-A313-42F9-8F6F-13038E691FC9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Then why not just have: { "iss": "https://server.example.com", "aud": "s6BhdRkqt3", "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", "sub": "248289761001", "iat": 1458668180, "exp": 1458668580, "events": { "https://specs.openid.net/logout=E2=80=9D: = = "08a5019c-17e1-4977-8f42-65a12843ea02=E2=80=9D } } =E2=80=94 Justin > On Apr 8, 2016, at 11:38 AM, William Denniss = wrote: >=20 > The "events" claim tells you that it's an event JWT without you = needing to scan for all events you support (and it means you'll also be = able to know if it's an event that perhaps you don't support). Otherwise = they could be confused with collision-resistant public claims = . >=20 > Also, it's possible that the event is so simple it actually doesn't = even need its own attribute dictionary. Thought of that after I sent = the pull request, will make a new revision shortly. In this simple case, = declaring the event's type is enough. >=20 > E.g.: >=20 > { > "iss": "https://server.example.com ", > "aud": "s6BhdRkqt3", > "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", > "sub": "248289761001", > "iat": 1458668180, > "exp": 1458668580, > "events": [ > "https://specs.openid.net/logout = " > ], > "sid": "08a5019c-17e1-4977-8f42-65a12843ea02" > } >=20 >=20 > NB. we expect "sid" (session id) to be a standard JWT claim in Connect = going forward as it's needed by a few different specs in progress, hence = why it wouldn't need to be an event-specific attribute. >=20 >=20 > On Fri, Apr 8, 2016 at 12:20 PM Leif Johansson > wrote: > On 2016-04-08 17:18, Justin Richer wrote: > > I know I missed the discussion the other day, but I have a question > > about the data structure: > > > > What=E2=80=99s the purpose of having the =E2=80=9Cevents=E2=80=9D = array below if the values of > > said array are going to be keys in the overlying object? It seems > > unnecessary duplication of information. >=20 > I guess cause it allows you to identity what part of the structure you > have to care about if you treat this as an "event" >=20 > > > > =E2=80=94 Justin > > > >> On Apr 8, 2016, at 10:59 AM, William Denniss > >> >> wrote: > >> > >> Yesterday, Mike, John, Nat and I workshopped the draft > >> OpenID Back-Channel Logout Token format to see what it would look = like > >> formatted as an id-event. > >> > >> We used a URL for the event type (to avoid registering a URN, and = also > >> because URLs can be self-documenting which is nice, and we've used > >> this structure before in OpenID). The outcome was pretty good, = take a > >> look at the post to the OpenID Connect WG > >> here: = http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20160404/006= 016.html = > >> > >> Here's the example logout token we came up with: > >> > >> { > >> "iss": "https://server.example.com = >", > >> "aud": "s6BhdRkqt3", > >> "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", > >> "sub": "248289761001", > >> "iat": 1458668180, > >> "exp": 1458668580, > >> "events": [ > >> "https://specs.openid.net/logout = " > >> ], > >> "https://specs.openid.net/logout = ": { > >> "sid": "08a5019c-17e1-4977-8f42-65a12843ea02" > >> } > >> } > >> > >> I've made a few proposed changes to the id-events spec, including > >> simplifying the claim name from "eventURIs" to just "events", and > >> added this example to the spec, as well as some minor editorial = changes. > >> > >> Please review my changes: > >> https://github.com/independentid/Identity-Events/pull/1 = > >> > >> William > >> _______________________________________________ > >> 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 >=20 > _______________________________________________ > 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=_44605C45-A313-42F9-8F6F-13038E691FC9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Then why not just have:

{
  "iss": "https://server.example.com",
  "aud": = "s6BhdRkqt3",
  "jti": = "3d0c3cf797584bd193bd0fb1bd4e7d30",
  "sub": = "248289761001",
  "iat": 1458668180,
  "exp": 1458668580,
  "events": {
    "https://specs.openid.net/logout=E2=80=9D: "08a5019c-17= e1-4977-8f42-65a12843ea02=E2=80=9D
  = }
}


 =E2=80=94 = Justin

On Apr 8, 2016, at 11:38 AM, William Denniss = <wdenniss@google.com> wrote:

The "events" claim tells you that it's an event JWT without = you needing to scan for all events you support (and it means you'll also = be able to know if it's an event that perhaps you don't support). = Otherwise they could be confused with collision-resistant public= claims.

Also, = it's possible that the event is so simple it actually doesn't even need = its own attribute dictionary. Thought of that after I sent the pull = request, will make a new revision shortly. In this simple case, = declaring the event's type is enough.

E.g.:

{
  "iss": "https://server.example.com",
  = "aud": "s6BhdRkqt3",
  "jti": = "3d0c3cf797584bd193bd0fb1bd4e7d30",
  "sub": = "248289761001",
  "iat": 1458668180,
  "exp": 1458668580,
  = "events": [
    "https://specs.openid.net/logout"
  ],
  "sid": = "08a5019c-17e1-4977-8f42-65a12843ea02"
}


NB. we expect "sid" (session id) to be a standard JWT claim = in Connect going forward as it's needed by a few different specs in = progress, hence why it wouldn't need to be an event-specific = attribute.


On= Fri, Apr 8, 2016 at 12:20 PM Leif Johansson <leifj@sunet.se> wrote:
On 2016-04-08 17:18, Justin Richer = wrote:
> I know I missed the discussion the other day, but I have a = question
> about the data structure:
>
> What=E2=80=99s the purpose of having the =E2=80=9Cevents=E2=80=9D = array below if the values of
> said array are going to be keys in the overlying object? It = seems
> unnecessary duplication of information.

I guess cause it allows you to identity what part of the structure = you
have to care about if you treat this as an "event"

>
>  =E2=80=94 Justin
>
>> On Apr 8, 2016, at 10:59 AM, William Denniss <wdenniss@google.com
>> <mailto:wdenniss@google.com>> wrote:
>>
>> Yesterday, Mike, John, Nat and I workshopped the draft
>> OpenID Back-Channel Logout Token format to see what it would = look like
>> formatted as an id-event.
>>
>> We used a URL for the event type (to avoid registering a URN, = and also
>> because URLs can be self-documenting which is nice, and we've = used
>> this structure before in OpenID).  The outcome was pretty = good, take a
>> look at the post to the OpenID Connect WG
>> here: http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-2= 0160404/006016.html
>>
>> Here's the example logout token we came up with:
>>
>>   {
>>       "iss": "https://server.example.com <https://server.example.com/>",
>>       "aud": "s6BhdRkqt3",
>>       "jti": = "3d0c3cf797584bd193bd0fb1bd4e7d30",
>>       "sub": "248289761001",
>>       "iat": 1458668180,
>>       "exp": 1458668580,
>>       "events": [
>>           "https://specs.openid.net/logout"
>>       ],
>>       "https://specs.openid.net/logout": {
>>           "sid": = "08a5019c-17e1-4977-8f42-65a12843ea02"
>>       }
>>   }
>>
>> I've made a few proposed changes to the id-events spec, = including
>> simplifying the claim name from "eventURIs" to just "events", = and
>> added this example to the spec, as well as some minor editorial = changes.
>>
>> Please review my changes:
>> https://github.com/independentid/Identity-Events/pull/1
>>
>> William
>> _______________________________________________
>> Id-event mailing list
>> Id-event@ietf.org <mailto: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
_______________________________________________
Id-event = mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event

= --Apple-Mail=_44605C45-A313-42F9-8F6F-13038E691FC9-- From nobody Fri Apr 8 09:15:10 2016 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF01B12D5CE for ; Fri, 8 Apr 2016 09:15:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 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_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 30j3NrP9gIP3 for ; Fri, 8 Apr 2016 09:15:06 -0700 (PDT) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81B7612D939 for ; Fri, 8 Apr 2016 09:14:37 -0700 (PDT) Received: by mail-oi0-x230.google.com with SMTP id p188so141445066oih.2 for ; Fri, 08 Apr 2016 09:14:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DA+/ZXpgXMZtbV1e5v74PP4ze/t4AUkrMs/F2B3jSC8=; b=JUSCzPCkxjDkj9PlRl9U98pci48BcKHrHEt4dh3pmKeFStdqj5nXo1zG0BBuK3Vjr5 cgOmBoxuZnkeoopV1582jMkf29sCheUsPJuj3Tek3KkYra/30FvJ3/sekey9CqrxiZjb s0lTE6xMMQHzOD6KjVMl2abjrFJAUWKyOWkIBW+Tuk0ehXIAzx1b3uo4QVag+iN8OwUC 0QlazikbunC9UKzc5BArRAvHDi8DXl70hyfUgRC52CC95fHDGE+GL9bk0F4jKxW2smvQ u4c8ymCF2pbwvQ1BEFjAZKvgycmXzw/mf87H9TnDfOLwPXOvTdKDgBwBX4U/SgGer/kp bTTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=DA+/ZXpgXMZtbV1e5v74PP4ze/t4AUkrMs/F2B3jSC8=; b=b+9rK/kdcwMf6Q2tA4PV+IMA9HMKNOT6iYIyt7WOENlYS6jrYviA2cmnQA0OwJ2Ldx kHIRvJ0ofFmv8R3jCqHj1EsWbBTp0Wplb0Fjk5uKIhVvHEqQKbDKdP/G/ots2+LItkD1 PXPtgQX+Su0U/OWCqDc/OJe5kAoy1l5ib5v7iKU2YLKBGv1omp9OBtfX6cbRkg5yt0B/ 5dWxFRdbudtO7TfuA7usJaOFY1/Jw7bXjE7Gn4/TIcAlqZ8qOGFh7ocS1AtVdAD83VCQ RfoUd3Fa2cQ0GRacEM7PE1ma0TZ4QZ7gPI1+ZXQq6iwkZdwyRZ+hsu6if1oghB8av50M hElQ== X-Gm-Message-State: AD7BkJK/Xc2GwmnXl86RP4hbWRNbRPFrl+FljnXFhCCG55Xxde5nhsyGJGGdEI2OsEs4p70MUTIfjmf93BRNMOic X-Received: by 10.157.13.9 with SMTP id 9mr5045312oti.39.1460132076758; Fri, 08 Apr 2016 09:14:36 -0700 (PDT) MIME-Version: 1.0 References: <0BBB465A-B002-41B0-A30D-C2DED8ADA933@mit.edu> <5707CC1B.20908@sunet.se> <547FBBB4-2FA7-4E21-ABDA-2C426D554B71@mit.edu> In-Reply-To: <547FBBB4-2FA7-4E21-ABDA-2C426D554B71@mit.edu> From: William Denniss Date: Fri, 08 Apr 2016 16:14:26 +0000 Message-ID: To: Justin Richer Content-Type: multipart/alternative; boundary=001a11352be6c2e115052ffb7d17 Archived-At: Cc: Leif Johansson , id-event@ietf.org Subject: Re: [Id-event] Proposed changes to the event spec X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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: Fri, 08 Apr 2016 16:15:09 -0000 --001a11352be6c2e115052ffb7d17 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable In this example, the event doesn't need to convey any data beyond the type, as it uses only standard claims (we plan to standardize "sid" for session-id, independent of back-channel logout). On Fri, Apr 8, 2016 at 1:09 PM Justin Richer wrote: > Then why not just have: > > { > "iss": "https://server.example.com", > "aud": "s6BhdRkqt3", > "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", > "sub": "248289761001", > "iat": 1458668180, > "exp": 1458668580, > "events": { > "https://specs.openid.net/logout=E2=80=9D: > "08a5019c-17e1-4977-8f42-65a12843ea02=E2=80=9D > } > } > > > =E2=80=94 Justin > > On Apr 8, 2016, at 11:38 AM, William Denniss wrote: > > The "events" claim tells you that it's an event JWT without you needing t= o > scan for all events you support (and it means you'll also be able to know > if it's an event that perhaps you don't support). Otherwise they could be > confused with collision-resistant public claims > . > > Also, it's possible that the event is so simple it actually doesn't even > need its own attribute dictionary. Thought of that after I sent the pull > request, will make a new revision shortly. In this simple case, declaring > the event's type is enough. > > E.g.: > > { > "iss": "https://server.example.com", > "aud": "s6BhdRkqt3", > "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", > "sub": "248289761001", > "iat": 1458668180, > "exp": 1458668580, > "events": [ > "https://specs.openid.net/logout" > ], > "sid": "08a5019c-17e1-4977-8f42-65a12843ea02" > } > > > NB. we expect "sid" (session id) to be a standard JWT claim in Connect > going forward as it's needed by a few different specs in progress, hence > why it wouldn't need to be an event-specific attribute. > > > On Fri, Apr 8, 2016 at 12:20 PM Leif Johansson wrote: > >> On 2016-04-08 17:18, Justin Richer wrote: >> > I know I missed the discussion the other day, but I have a question >> > about the data structure: >> > >> > What=E2=80=99s the purpose of having the =E2=80=9Cevents=E2=80=9D arra= y below if the values of >> > said array are going to be keys in the overlying object? It seems >> > unnecessary duplication of information. >> >> I guess cause it allows you to identity what part of the structure you >> have to care about if you treat this as an "event" >> >> > >> > =E2=80=94 Justin >> > >> >> On Apr 8, 2016, at 10:59 AM, William Denniss > >> > wrote: >> >> >> >> Yesterday, Mike, John, Nat and I workshopped the draft >> >> OpenID Back-Channel Logout Token format to see what it would look lik= e >> >> formatted as an id-event. >> >> >> >> We used a URL for the event type (to avoid registering a URN, and als= o >> >> because URLs can be self-documenting which is nice, and we've used >> >> this structure before in OpenID). The outcome was pretty good, take = a >> >> look at the post to the OpenID Connect WG >> >> here: >> http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20160404/0= 06016.html >> >> >> >> Here's the example logout token we came up with: >> >> >> >> { >> >> "iss": "https://server.example.com > >", >> >> "aud": "s6BhdRkqt3", >> >> "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", >> >> "sub": "248289761001", >> >> "iat": 1458668180, >> >> "exp": 1458668580, >> >> "events": [ >> >> "https://specs.openid.net/logout" >> >> ], >> >> "https://specs.openid.net/logout": { >> >> "sid": "08a5019c-17e1-4977-8f42-65a12843ea02" >> >> } >> >> } >> >> >> >> I've made a few proposed changes to the id-events spec, including >> >> simplifying the claim name from "eventURIs" to just "events", and >> >> added this example to the spec, as well as some minor editorial >> changes. >> >> >> >> Please review my changes: >> >> https://github.com/independentid/Identity-Events/pull/1 >> >> >> >> William >> >> _______________________________________________ >> >> 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 >> > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > > --001a11352be6c2e115052ffb7d17 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable In this example, the event doesn't need to convey any data beyond the t= ype, as it uses only standard claims (we plan to standardize "sid"= ; for session-id, independent of back-channel logout).
On Fri, Apr 8, 2016 at 1:09 PM Justin Richer <= ;jricher@mit.edu> wrote:
Then wh= y not just have:

{
=C2=A0 "iss": "https://server.example.com",
=C2= =A0 "aud": "s6BhdRkqt3",
=C2=A0 "jti": &qu= ot;3d0c3cf797584bd193bd0fb1bd4e7d30",
=C2=A0 "sub": "= ;248289761001",
=C2=A0 "iat": 1458668180,
=C2=A0 "= ;exp": 1458668580,
=C2=A0 "events": {
=C2=A0 =C2=A0 "https://specs.openid.= net/logout=E2=80=9D:=C2=A0"08a5019c-17e1-4977-8f42-65a12843ea02=E2= =80=9D
=C2=A0 }
}


=C2=A0=E2=80=94 Justin

On Apr 8, 2016, at 11:38 AM, William Denniss <wdenniss@google.com> wrote:
<= br>
The "even= ts" claim tells you that it's an event JWT without you needing to = scan for all events you support (and it means you'll also be able to kn= ow if it's an event that perhaps you don't support). Otherwise they= could be confused with collision-resistant public claims.

Also, it's possible that the event is so simple it actually doesn= 9;t even need its own attribute dictionary. Thought of that after I sent t= he pull request, will make a new revision shortly. In this simple case, dec= laring the event's type is enough.

E.g.:

{
=C2=A0 "iss": "https://server.example.com",
=C2=A0 "aud": "s6BhdRkqt3",
=C2=A0 &qu= ot;jti": "3d0c3cf797584bd193bd0fb1bd4e7d30",
=C2= =A0 "sub": "248289761001",
=C2=A0 "iat&q= uot;: 1458668180,
=C2=A0 "exp": 1458668580,
= =C2=A0 "events": [
=C2=A0 ],
=C2=A0 "sid": "08a5019c-17e1-4977-8f42-= 65a12843ea02"
= }


NB. we expect "sid" (se= ssion id) to be a standard JWT claim in Connect going forward as it's n= eeded by a few different specs in progress, hence why it wouldn't need = to be an event-specific attribute.


On Fri, Apr 8, 2016 at 12:20 PM Leif Joha= nsson <leifj@sunet.s= e> wrote:
On 2016-04-08 17:18, Justin Rich= er wrote:
> I know I missed the discussion the other day, but I have a question > about the data structure:
>
> What=E2=80=99s the purpose of having the =E2=80=9Cevents=E2=80=9D arra= y below if the values of
> said array are going to be keys in the overlying object? It seems
> unnecessary duplication of information.

I guess cause it allows you to identity what part of the structure you
have to care about if you treat this as an "event"

>
>=C2=A0 =E2=80=94 Justin
>
>> On Apr 8, 2016, at 10:59 AM, William Denniss <wdenniss@google.com
>> <mailto:wdenniss@google.com>> wrote:
>>
>> Yesterday, Mike, John, Nat and I workshopped the draft
>> OpenID Back-Channel Logout Token format to see what it would look = like
>> formatted as an id-event.
>>
>> We used a URL for the event type (to avoid registering a URN, and = also
>> because URLs can be self-documenting which is nice, and we've = used
>> this structure before in OpenID).=C2=A0 The outcome was pretty goo= d, take a
>> look at the post to the OpenID Connect WG
>> here: htt= p://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20160404/006016.= html
>>
>> Here's the example logout token we came up with:
>>
>>=C2=A0 =C2=A0{
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0"iss": "https://server.= example.com <https://server.example.com/>",
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0"aud": "s6BhdRkqt3",=
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0"jti": "3d0c3cf797584bd19= 3bd0fb1bd4e7d30",
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0"sub": "248289761001"= ;,
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0"iat": 1458668180,
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0"exp": 1458668580,
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0"events": [
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"https://specs.= openid.net/logout"
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0],
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0"https://specs.openid.net/log= out": {
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"sid": "08a= 5019c-17e1-4977-8f42-65a12843ea02"
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0}
>>=C2=A0 =C2=A0}
>>
>> I've made a few proposed changes to the id-events spec, includ= ing
>> simplifying the claim name from "eventURIs" to just &quo= t;events", and
>> added this example to the spec, as well as some minor editorial ch= anges.
>>
>> Please review my changes:
>> https://github.com/independentid/Ide= ntity-Events/pull/1
>>
>> William
>> _______________________________________________
>> Id-event mailing list
>> Id-event@ie= tf.org <mailto:Id-event@ietf.org>
>> https://www.ietf.org/mailman/listinfo/id-even= t
>
>
>
> _______________________________________________
> Id-event mailing list
> Id-event@ietf.o= rg
> 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 listId-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event

--001a11352be6c2e115052ffb7d17-- From nobody Fri Apr 8 09:19:13 2016 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 202D912D1AC for ; Fri, 8 Apr 2016 09:19:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.23 X-Spam-Level: X-Spam-Status: No, score=-4.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=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 4Ui0w0sur7jm for ; Fri, 8 Apr 2016 09:19:09 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (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 0766212D119 for ; Fri, 8 Apr 2016 09:19:08 -0700 (PDT) X-AuditID: 1209190d-02bff700000079a5-04-5707d9fbab52 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 5C.78.31141.BF9D7075; Fri, 8 Apr 2016 12:19:07 -0400 (EDT) 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 u38GJ65a028337; Fri, 8 Apr 2016 12:19:07 -0400 Received: from artemisia.richer.local (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 u38GJ59G024691 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 8 Apr 2016 12:19:06 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_090B1AD7-B67E-4427-93C5-87643A7F6DE7" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Justin Richer In-Reply-To: Date: Fri, 8 Apr 2016 12:19:04 -0400 Message-Id: <92E794C9-BB30-44D0-B22C-8BDFD19C1E1E@mit.edu> References: <0BBB465A-B002-41B0-A30D-C2DED8ADA933@mit.edu> <5707CC1B.20908@sunet.se> <547FBBB4-2FA7-4E21-ABDA-2C426D554B71@mit.edu> To: William Denniss X-Mailer: Apple Mail (2.3112) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprIKsWRmVeSWpSXmKPExsUixCmqrfv7Jnu4wcdJ6hYdC7qZLBb0bmW2 2DSnmd2B2WPBplKPJUt+Mnns3dTHHsAcxWWTkpqTWZZapG+XwJWxes5c5oKrUxkr2k4eYWpg /NnI2MXIySEhYCJxc91Rpi5GLg4hgTYmiV27rzBDOBsYJW7/72OFcB4wSezoPsMO0sIskCDx Yf8zFhCbV0BP4sSq3awgtrCAlcSqXdOZQGw2AVWJ6WtawGxOgUCJ5qa/zCA2i4CKxP9Da5gg 5phJ9DZMYYOYYyVxdfkXRohll5gkJj1dD7ZMREBT4uXZAywQt8pK7NuwgG0CI/8sJHfMQnIH RFxbYtnC18wQtqbE/u7lLJjiGhKd3yayLmBkW8Uom5JbpZubmJlTnJqsW5ycmJeXWqRrpJeb WaKXmlK6iREc8pK8Oxj/3fU6xCjAwajEw3vhPVu4EGtiWXFl7iFGSQ4mJVHewBvs4UJ8Sfkp lRmJxRnxRaU5qcWHGCU4mJVEeHeB5HhTEiurUovyYVLSHCxK4rwxN4+GCQmkJ5akZqemFqQW wWRlODiUJHifgTQKFqWmp1akZeaUIKSZODhBhvMADVe9CTK8uCAxtzgzHSJ/ilFRSpy3AKRZ ACSRUZoH1wtKSQlvD5u+YhQHekWYNxOkigeYzuC6XwENZgIafIGfDWRwSSJCSqqB8fHbwMdS 39cwMRenBe5miA4KrUh8aXle2+MBf2tP7mwfo8cX+HmPVPdb69Rw3xM9+ij0Hn9Bl8D6z9bP muNqZsU8nrNzY1DdnA0sh271SvZ3q4TOuRd69NURnt+Mm0U5u5IsC+JXN+2ersfmbvN3dcf9 P7r+Zg1KiR81ZksskJhpterrNPsYJZbijERDLeai4kQAL7+DOiQDAAA= Archived-At: Cc: Leif Johansson , id-event@ietf.org Subject: Re: [Id-event] Proposed changes to the event spec X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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: Fri, 08 Apr 2016 16:19:12 -0000 --Apple-Mail=_090B1AD7-B67E-4427-93C5-87643A7F6DE7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I guess part of what I=E2=80=99m questioning is whether the ID Events = really need to have all the JWT structures to begin with. People seem to = be allergic to using JWS to wrap any structure that=E2=80=99s not a JWT, = but if we took a step back from the assumption that we should be using = JWT claims we might find a better representation here.=20 These aren=E2=80=99t really tokens or assertions. They=E2=80=99re more = log entries designed to be carried in a protected way across the = network. =E2=80=94 Justin > On Apr 8, 2016, at 12:14 PM, William Denniss = wrote: >=20 > In this example, the event doesn't need to convey any data beyond the = type, as it uses only standard claims (we plan to standardize "sid" for = session-id, independent of back-channel logout). > On Fri, Apr 8, 2016 at 1:09 PM Justin Richer > wrote: > Then why not just have: >=20 > { > "iss": "https://server.example.com ", > "aud": "s6BhdRkqt3", > "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", > "sub": "248289761001", > "iat": 1458668180, > "exp": 1458668580, > "events": { > "https://specs.openid.net/logout=E2=80=9D: = = "08a5019c-17e1-4977-8f42-65a12843ea02=E2=80=9D > } > } >=20 >=20 > =E2=80=94 Justin >=20 >> On Apr 8, 2016, at 11:38 AM, William Denniss > wrote: >>=20 >> The "events" claim tells you that it's an event JWT without you = needing to scan for all events you support (and it means you'll also be = able to know if it's an event that perhaps you don't support). Otherwise = they could be confused with collision-resistant public claims = . >>=20 >> Also, it's possible that the event is so simple it actually doesn't = even need its own attribute dictionary. Thought of that after I sent = the pull request, will make a new revision shortly. In this simple case, = declaring the event's type is enough. >>=20 >> E.g.: >>=20 >> { >> "iss": "https://server.example.com ", >> "aud": "s6BhdRkqt3", >> "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", >> "sub": "248289761001", >> "iat": 1458668180, >> "exp": 1458668580, >> "events": [ >> "https://specs.openid.net/logout = " >> ], >> "sid": "08a5019c-17e1-4977-8f42-65a12843ea02" >> } >>=20 >>=20 >> NB. we expect "sid" (session id) to be a standard JWT claim in = Connect going forward as it's needed by a few different specs in = progress, hence why it wouldn't need to be an event-specific attribute. >>=20 >>=20 >> On Fri, Apr 8, 2016 at 12:20 PM Leif Johansson > wrote: >> On 2016-04-08 17:18, Justin Richer wrote: >> > I know I missed the discussion the other day, but I have a question >> > about the data structure: >> > >> > What=E2=80=99s the purpose of having the =E2=80=9Cevents=E2=80=9D = array below if the values of >> > said array are going to be keys in the overlying object? It seems >> > unnecessary duplication of information. >>=20 >> I guess cause it allows you to identity what part of the structure = you >> have to care about if you treat this as an "event" >>=20 >> > >> > =E2=80=94 Justin >> > >> >> On Apr 8, 2016, at 10:59 AM, William Denniss >> >> >> wrote: >> >> >> >> Yesterday, Mike, John, Nat and I workshopped the draft >> >> OpenID Back-Channel Logout Token format to see what it would look = like >> >> formatted as an id-event. >> >> >> >> We used a URL for the event type (to avoid registering a URN, and = also >> >> because URLs can be self-documenting which is nice, and we've used >> >> this structure before in OpenID). The outcome was pretty good, = take a >> >> look at the post to the OpenID Connect WG >> >> here: = http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20160404/006= 016.html = >> >> >> >> Here's the example logout token we came up with: >> >> >> >> { >> >> "iss": "https://server.example.com = >", >> >> "aud": "s6BhdRkqt3", >> >> "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", >> >> "sub": "248289761001", >> >> "iat": 1458668180, >> >> "exp": 1458668580, >> >> "events": [ >> >> "https://specs.openid.net/logout = " >> >> ], >> >> "https://specs.openid.net/logout = ": { >> >> "sid": "08a5019c-17e1-4977-8f42-65a12843ea02" >> >> } >> >> } >> >> >> >> I've made a few proposed changes to the id-events spec, including >> >> simplifying the claim name from "eventURIs" to just "events", and >> >> added this example to the spec, as well as some minor editorial = changes. >> >> >> >> Please review my changes: >> >> https://github.com/independentid/Identity-Events/pull/1 = >> >> >> >> William >> >> _______________________________________________ >> >> 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 >>=20 >> _______________________________________________ >> 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 --Apple-Mail=_090B1AD7-B67E-4427-93C5-87643A7F6DE7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I guess part of what I=E2=80=99m questioning is whether the = ID Events really need to have all the JWT structures to begin with. = People seem to be allergic to using JWS to wrap any structure that=E2=80=99= s not a JWT, but if we took a step back from the assumption that we = should be using JWT claims we might find a better representation = here. 

These = aren=E2=80=99t really tokens or assertions. They=E2=80=99re more log = entries designed to be carried in a protected way across the network.

 =E2=80= =94 Justin

On Apr 8, 2016, at 12:14 PM, = William Denniss <wdenniss@google.com> wrote:

In this example, the event doesn't need to convey any data = beyond the type, as it uses only standard claims (we plan to standardize = "sid" for session-id, independent of back-channel logout).
On = Fri, Apr 8, 2016 at 1:09 PM Justin Richer <jricher@mit.edu> = wrote:
Then why not just have:

{
  "iss": "https://server.example.com",
  "aud": "s6BhdRkqt3",
  "jti": = "3d0c3cf797584bd193bd0fb1bd4e7d30",
  "sub": = "248289761001",
  "iat": 1458668180,
  "exp": 1458668580,
  "events": {
    "https://specs.openid.net/logout=E2=80=9D: "08a5019c-17= e1-4977-8f42-65a12843ea02=E2=80=9D
  = }
}


 =E2=80=94 Justin

On Apr 8, 2016, at 11:38 AM, William Denniss <wdenniss@google.com> wrote:

The "events" claim tells you that it's an event JWT without = you needing to scan for all events you support (and it means you'll also = be able to know if it's an event that perhaps you don't support). = Otherwise they could be confused with collision-resistant public claims.

Also, it's possible that the event is so simple it actually = doesn't even need its own attribute dictionary. Thought of that after I = sent the pull request, will make a new revision shortly. In this simple = case, declaring the event's type is enough.

E.g.:

{
  "iss": "https://server.example.com",
  = "aud": "s6BhdRkqt3",
  "jti": = "3d0c3cf797584bd193bd0fb1bd4e7d30",
  "sub": = "248289761001",
  "iat": 1458668180,
  "exp": 1458668580,
  = "events": [
    "https://specs.openid.net/logout"
  ],
  "sid": = "08a5019c-17e1-4977-8f42-65a12843ea02"
}


NB. we expect "sid" (session id) to be a standard JWT claim = in Connect going forward as it's needed by a few different specs in = progress, hence why it wouldn't need to be an event-specific = attribute.


On= Fri, Apr 8, 2016 at 12:20 PM Leif Johansson <leifj@sunet.se> wrote:
On 2016-04-08 17:18, Justin Richer = wrote:
> I know I missed the discussion the other day, but I have a = question
> about the data structure:
>
> What=E2=80=99s the purpose of having the =E2=80=9Cevents=E2=80=9D = array below if the values of
> said array are going to be keys in the overlying object? It = seems
> unnecessary duplication of information.

I guess cause it allows you to identity what part of the structure = you
have to care about if you treat this as an "event"

>
>  =E2=80=94 Justin
>
>> On Apr 8, 2016, at 10:59 AM, William Denniss <wdenniss@google.com
>> <mailto:wdenniss@google.com>> wrote:
>>
>> Yesterday, Mike, John, Nat and I workshopped the draft
>> OpenID Back-Channel Logout Token format to see what it would = look like
>> formatted as an id-event.
>>
>> We used a URL for the event type (to avoid registering a URN, = and also
>> because URLs can be self-documenting which is nice, and we've = used
>> this structure before in OpenID).  The outcome was pretty = good, take a
>> look at the post to the OpenID Connect WG
>> here: http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-2= 0160404/006016.html
>>
>> Here's the example logout token we came up with:
>>
>>   {
>>       "iss": "https://server.example.com <https://server.example.com/>",
>>       "aud": "s6BhdRkqt3",
>>       "jti": = "3d0c3cf797584bd193bd0fb1bd4e7d30",
>>       "sub": "248289761001",
>>       "iat": 1458668180,
>>       "exp": 1458668580,
>>       "events": [
>>           "https://specs.openid.net/logout"
>>       ],
>>       "https://specs.openid.net/logout": {
>>           "sid": = "08a5019c-17e1-4977-8f42-65a12843ea02"
>>       }
>>   }
>>
>> I've made a few proposed changes to the id-events spec, = including
>> simplifying the claim name from "eventURIs" to just "events", = and
>> added this example to the spec, as well as some minor editorial = changes.
>>
>> Please review my changes:
>> https://github.com/independentid/Identity-Events/pull/1
>>
>> William
>> _______________________________________________
>> Id-event mailing list
>> Id-event@ietf.org <mailto: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
_______________________________________________
Id-event = mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event


= --Apple-Mail=_090B1AD7-B67E-4427-93C5-87643A7F6DE7-- From nobody Fri Apr 8 09:26:02 2016 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCD9412D89C for ; Fri, 8 Apr 2016 09:26:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=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 aEMe5LynW4aD for ; Fri, 8 Apr 2016 09:25:57 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (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 A9E0D12D5B4 for ; Fri, 8 Apr 2016 09:25:57 -0700 (PDT) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u38GPp62010205 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 8 Apr 2016 16:25:52 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id u38GPput013425 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 8 Apr 2016 16:25:51 GMT Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u38GPoKi014160; Fri, 8 Apr 2016 16:25:50 GMT Received: from dhcp-896a.meeting.ietf.org (/31.133.138.106) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 08 Apr 2016 09:25:50 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_2970387D-3DBB-4F40-B671-875BB295588B" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Phil Hunt In-Reply-To: <92E794C9-BB30-44D0-B22C-8BDFD19C1E1E@mit.edu> Date: Fri, 8 Apr 2016 13:25:44 -0300 Message-Id: References: <0BBB465A-B002-41B0-A30D-C2DED8ADA933@mit.edu> <5707CC1B.20908@sunet.se> <547FBBB4-2FA7-4E21-ABDA-2C426D554B71@mit.edu> <92E794C9-BB30-44D0-B22C-8BDFD19C1E1E@mit.edu> To: Justin Richer X-Mailer: Apple Mail (2.3112) X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Cc: William Denniss , Leif Johansson , id-event@ietf.org Subject: Re: [Id-event] Proposed changes to the event spec X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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: Fri, 08 Apr 2016 16:26:01 -0000 --Apple-Mail=_2970387D-3DBB-4F40-B671-875BB295588B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The dictionary model certainly makes it distinguished from a security = assertion. Phil @independentid www.independentid.com = phil.hunt@oracle.com = > On Apr 8, 2016, at 1:19 PM, Justin Richer wrote: >=20 > I guess part of what I=E2=80=99m questioning is whether the ID Events = really need to have all the JWT structures to begin with. People seem to = be allergic to using JWS to wrap any structure that=E2=80=99s not a JWT, = but if we took a step back from the assumption that we should be using = JWT claims we might find a better representation here.=20 >=20 > These aren=E2=80=99t really tokens or assertions. They=E2=80=99re more = log entries designed to be carried in a protected way across the = network. >=20 > =E2=80=94 Justin >=20 >> On Apr 8, 2016, at 12:14 PM, William Denniss > wrote: >>=20 >> In this example, the event doesn't need to convey any data beyond the = type, as it uses only standard claims (we plan to standardize "sid" for = session-id, independent of back-channel logout). >> On Fri, Apr 8, 2016 at 1:09 PM Justin Richer > wrote: >> Then why not just have: >>=20 >> { >> "iss": "https://server.example.com ", >> "aud": "s6BhdRkqt3", >> "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", >> "sub": "248289761001", >> "iat": 1458668180, >> "exp": 1458668580, >> "events": { >> "https://specs.openid.net/logout=E2=80=9D: = = "08a5019c-17e1-4977-8f42-65a12843ea02=E2=80=9D >> } >> } >>=20 >>=20 >> =E2=80=94 Justin >>=20 >>> On Apr 8, 2016, at 11:38 AM, William Denniss > wrote: >>>=20 >>> The "events" claim tells you that it's an event JWT without you = needing to scan for all events you support (and it means you'll also be = able to know if it's an event that perhaps you don't support). Otherwise = they could be confused with collision-resistant public claims = . >>>=20 >>> Also, it's possible that the event is so simple it actually doesn't = even need its own attribute dictionary. Thought of that after I sent = the pull request, will make a new revision shortly. In this simple case, = declaring the event's type is enough. >>>=20 >>> E.g.: >>>=20 >>> { >>> "iss": "https://server.example.com ", >>> "aud": "s6BhdRkqt3", >>> "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", >>> "sub": "248289761001", >>> "iat": 1458668180, >>> "exp": 1458668580, >>> "events": [ >>> "https://specs.openid.net/logout = " >>> ], >>> "sid": "08a5019c-17e1-4977-8f42-65a12843ea02" >>> } >>>=20 >>>=20 >>> NB. we expect "sid" (session id) to be a standard JWT claim in = Connect going forward as it's needed by a few different specs in = progress, hence why it wouldn't need to be an event-specific attribute. >>>=20 >>>=20 >>> On Fri, Apr 8, 2016 at 12:20 PM Leif Johansson > wrote: >>> On 2016-04-08 17:18, Justin Richer wrote: >>> > I know I missed the discussion the other day, but I have a = question >>> > about the data structure: >>> > >>> > What=E2=80=99s the purpose of having the =E2=80=9Cevents=E2=80=9D = array below if the values of >>> > said array are going to be keys in the overlying object? It seems >>> > unnecessary duplication of information. >>>=20 >>> I guess cause it allows you to identity what part of the structure = you >>> have to care about if you treat this as an "event" >>>=20 >>> > >>> > =E2=80=94 Justin >>> > >>> >> On Apr 8, 2016, at 10:59 AM, William Denniss >>> >> >> wrote: >>> >> >>> >> Yesterday, Mike, John, Nat and I workshopped the draft >>> >> OpenID Back-Channel Logout Token format to see what it would look = like >>> >> formatted as an id-event. >>> >> >>> >> We used a URL for the event type (to avoid registering a URN, and = also >>> >> because URLs can be self-documenting which is nice, and we've = used >>> >> this structure before in OpenID). The outcome was pretty good, = take a >>> >> look at the post to the OpenID Connect WG >>> >> here: = http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20160404/006= 016.html = >>> >> >>> >> Here's the example logout token we came up with: >>> >> >>> >> { >>> >> "iss": "https://server.example.com = >", >>> >> "aud": "s6BhdRkqt3", >>> >> "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", >>> >> "sub": "248289761001", >>> >> "iat": 1458668180, >>> >> "exp": 1458668580, >>> >> "events": [ >>> >> "https://specs.openid.net/logout = " >>> >> ], >>> >> "https://specs.openid.net/logout = ": { >>> >> "sid": "08a5019c-17e1-4977-8f42-65a12843ea02" >>> >> } >>> >> } >>> >> >>> >> I've made a few proposed changes to the id-events spec, including >>> >> simplifying the claim name from "eventURIs" to just "events", and >>> >> added this example to the spec, as well as some minor editorial = changes. >>> >> >>> >> Please review my changes: >>> >> https://github.com/independentid/Identity-Events/pull/1 = >>> >> >>> >> William >>> >> _______________________________________________ >>> >> 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 >>>=20 >>> _______________________________________________ >>> 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 >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event --Apple-Mail=_2970387D-3DBB-4F40-B671-875BB295588B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 The dictionary model certainly makes it distinguished from a = security assertion.





On Apr 8, 2016, at 1:19 PM, Justin Richer <jricher@mit.edu> = wrote:

I guess part = of what I=E2=80=99m questioning is whether the ID Events really need to = have all the JWT structures to begin with. People seem to be allergic to = using JWS to wrap any structure that=E2=80=99s not a JWT, but if we took = a step back from the assumption that we should be using JWT claims we = might find a better representation here. 

These aren=E2=80=99t really tokens or = assertions. They=E2=80=99re more log entries designed to be carried in a = protected way across the network.

 =E2=80=94 Justin

On Apr 8, 2016, at 12:14 PM, William Denniss = <wdenniss@google.com> wrote:

In this example, the event doesn't need to convey any data = beyond the type, as it uses only standard claims (we plan to standardize = "sid" for session-id, independent of back-channel logout).
On = Fri, Apr 8, 2016 at 1:09 PM Justin Richer <jricher@mit.edu> = wrote:
Then why not just have:

{
  "iss": "https://server.example.com",
  "aud": "s6BhdRkqt3",
  "jti": = "3d0c3cf797584bd193bd0fb1bd4e7d30",
  "sub": = "248289761001",
  "iat": 1458668180,
  "exp": 1458668580,
  "events": {
    "https://specs.openid.net/logout=E2=80=9D: "08a5019c-17= e1-4977-8f42-65a12843ea02=E2=80=9D
  = }
}


 =E2=80=94 Justin

On Apr 8, 2016, at 11:38 AM, William Denniss <wdenniss@google.com> wrote:

The "events" claim tells you that it's an event JWT without = you needing to scan for all events you support (and it means you'll also = be able to know if it's an event that perhaps you don't support). = Otherwise they could be confused with collision-resistant public claims.

Also, it's possible that the event is so simple it actually = doesn't even need its own attribute dictionary. Thought of that after I = sent the pull request, will make a new revision shortly. In this simple = case, declaring the event's type is enough.

E.g.:

{
  "iss": "https://server.example.com",
  = "aud": "s6BhdRkqt3",
  "jti": = "3d0c3cf797584bd193bd0fb1bd4e7d30",
  "sub": = "248289761001",
  "iat": 1458668180,
  "exp": 1458668580,
  = "events": [
    "https://specs.openid.net/logout"
  ],
  "sid": = "08a5019c-17e1-4977-8f42-65a12843ea02"
}


NB. we expect "sid" (session id) to be a standard JWT claim = in Connect going forward as it's needed by a few different specs in = progress, hence why it wouldn't need to be an event-specific = attribute.


On= Fri, Apr 8, 2016 at 12:20 PM Leif Johansson <leifj@sunet.se> wrote:
On 2016-04-08 17:18, Justin Richer = wrote:
> I know I missed the discussion the other day, but I have a = question
> about the data structure:
>
> What=E2=80=99s the purpose of having the =E2=80=9Cevents=E2=80=9D = array below if the values of
> said array are going to be keys in the overlying object? It = seems
> unnecessary duplication of information.

I guess cause it allows you to identity what part of the structure = you
have to care about if you treat this as an "event"

>
>  =E2=80=94 Justin
>
>> On Apr 8, 2016, at 10:59 AM, William Denniss <wdenniss@google.com
>> <mailto:wdenniss@google.com>> wrote:
>>
>> Yesterday, Mike, John, Nat and I workshopped the draft
>> OpenID Back-Channel Logout Token format to see what it would = look like
>> formatted as an id-event.
>>
>> We used a URL for the event type (to avoid registering a URN, = and also
>> because URLs can be self-documenting which is nice, and we've = used
>> this structure before in OpenID).  The outcome was pretty = good, take a
>> look at the post to the OpenID Connect WG
>> here: http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-2= 0160404/006016.html
>>
>> Here's the example logout token we came up with:
>>
>>   {
>>       "iss": "https://server.example.com <https://server.example.com/>",
>>       "aud": "s6BhdRkqt3",
>>       "jti": = "3d0c3cf797584bd193bd0fb1bd4e7d30",
>>       "sub": "248289761001",
>>       "iat": 1458668180,
>>       "exp": 1458668580,
>>       "events": [
>>           "https://specs.openid.net/logout"
>>       ],
>>       "https://specs.openid.net/logout": {
>>           "sid": = "08a5019c-17e1-4977-8f42-65a12843ea02"
>>       }
>>   }
>>
>> I've made a few proposed changes to the id-events spec, = including
>> simplifying the claim name from "eventURIs" to just "events", = and
>> added this example to the spec, as well as some minor editorial = changes.
>>
>> Please review my changes:
>> https://github.com/independentid/Identity-Events/pull/1
>>
>> William
>> _______________________________________________
>> Id-event mailing list
>> Id-event@ietf.org <mailto: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
_______________________________________________
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=_2970387D-3DBB-4F40-B671-875BB295588B-- From nobody Fri Apr 8 11:55:39 2016 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2CCA12D4FC for ; Fri, 8 Apr 2016 11:55:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=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 JCRfPRtuOmSa for ; Fri, 8 Apr 2016 11:55:35 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (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 7E2D512D1C0 for ; Fri, 8 Apr 2016 11:55:35 -0700 (PDT) Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u38ItYGP030364 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Fri, 8 Apr 2016 18:55:34 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0022.oracle.com (8.14.4/8.13.8) with ESMTP id u38ItYoK031516 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Fri, 8 Apr 2016 18:55:34 GMT Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id u38ItYmn015463 for ; Fri, 8 Apr 2016 18:55:34 GMT Received: from dhcp-8d4c.meeting.ietf.org (/31.133.141.76) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 08 Apr 2016 11:55:33 -0700 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_76E551B2-2A20-40BA-B255-40C1185DEF5A" Date: Fri, 8 Apr 2016 15:55:30 -0300 References: <20160408184624.23058.51335.idtracker@ietfa.amsl.com> To: id-event@ietf.org Message-Id: Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Mailer: Apple Mail (2.3112) X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Subject: [Id-event] Fwd: New Version Notification for draft-hunt-idevent-token-01.txt X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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: Fri, 08 Apr 2016 18:55:37 -0000 --Apple-Mail=_76E551B2-2A20-40BA-B255-40C1185DEF5A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 In this update to draft-hunt-idevent-token, William Denniss and John = Bradley proposed to generalize the event uri format to be any URI rather = than just URN. An example was also added for OIDC Logout (non-normative = - since the core spec won=E2=80=99t have normative events just = examples). Thanks William for revising the text. I think we may have to add some text around event type URIs. For = example, suggesting that fragments could be use to distinguish = individual events that may be specified in a parent specification. E.g. = So while Logout might define only one event, a RISC or SCIM events spec = will define many. Also, IETF has multiple paths to its RFCs and the = change to numbering. Not sure what will be best for SCIM events in this = regard - maybe using urn=E2=80=99s works best for IETF specs? Guidance = greatly welcomed! Phil @independentid www.independentid.com = phil.hunt@oracle.com = > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: New Version Notification for draft-hunt-idevent-token-01.txt > Date: April 8, 2016 at 3:46:24 PM GMT-3 > To: "William Denniss" , "Phil Hunt" = , "Morteza Ansari" >=20 >=20 > A new version of I-D, draft-hunt-idevent-token-01.txt > has been successfully submitted by Phil Hunt and posted to the > IETF repository. >=20 > Name: draft-hunt-idevent-token > Revision: 01 > Title: Identity Event Token > Document date: 2016-04-08 > Group: Individual Submission > Pages: 14 > URL: = https://www.ietf.org/internet-drafts/draft-hunt-idevent-token-01.txt > Status: = https://datatracker.ietf.org/doc/draft-hunt-idevent-token/ > Htmlized: = https://tools.ietf.org/html/draft-hunt-idevent-token-01 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-hunt-idevent-token-01 >=20 > Abstract: > This specification defines an Identity Event token which may be > distributed via a protocol such as HTTP. An identity event token is > based on the JSON Web Token and may be optionally signed and/or > encrypted. It describes a statement of fact that may be shared by = an > event publisher with registered subscribers. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 --Apple-Mail=_76E551B2-2A20-40BA-B255-40C1185DEF5A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 In this update to draft-hunt-idevent-token, William Denniss = and John Bradley proposed to generalize the event uri format to be any = URI rather than just URN. An example was also added for OIDC Logout = (non-normative - since the core spec won=E2=80=99t have normative events = just examples).  Thanks William for revising the text.

I think we may have to = add some text around event type URIs. For example, suggesting that = fragments could be use to distinguish individual events that may be = specified in a parent specification.  E.g. So while Logout might = define only one event, a RISC or SCIM events spec will define many. =  Also, IETF has multiple paths to its RFCs and the change to = numbering. Not sure what will be best for SCIM events in this regard - = maybe using urn=E2=80=99s works best for IETF specs?  Guidance = greatly welcomed!




Begin forwarded message:

From: = internet-drafts@ietf.org
Subject: = New Version = Notification for draft-hunt-idevent-token-01.txt
Date: = April 8, 2016 at 3:46:24 PM = GMT-3
To: = "William Denniss" <wdenniss@google.com>, "Phil Hunt" <phil.hunt@yahoo.com>, "Morteza Ansari" <morteza.ansari@cisco.com>

A new version = of I-D, draft-hunt-idevent-token-01.txt
has been = successfully submitted by Phil Hunt and posted to the
IETF = repository.

Name: = draft-hunt-idevent-token
Revision: 01
Title:= = Identity Event Token
Document date: = 2016-04-08
Group: Individual Submission
Pages:= = 14
URL: =            https://www.ietf.org/internet-drafts/draft-hunt-idevent-token-0= 1.txt
Status: =         https://datatracker.ietf.org/doc/draft-hunt-idevent-token/<= br class=3D"">Htmlized:       https://tools.ietf.org/html/draft-hunt-idevent-token-01
Diff: =           https://www.ietf.org/rfcdiff?url2=3Ddraft-hunt-idevent-token-01=

Abstract:
=   This specification defines an Identity Event token which may = be
  distributed via a protocol such as HTTP. =  An identity event token is
  based on the = JSON Web Token and may be optionally signed and/or
=   encrypted.  It describes a statement of fact that may = be shared by an
  event publisher with = registered subscribers.




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

The IETF = Secretariat


= --Apple-Mail=_76E551B2-2A20-40BA-B255-40C1185DEF5A-- From nobody Fri Apr 8 14:43:49 2016 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96EBF12D71F for ; Fri, 8 Apr 2016 14:43:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.com 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 EWeAKcteN0E3 for ; Fri, 8 Apr 2016 14:43:46 -0700 (PDT) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) (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 A83D912D0E2 for ; Fri, 8 Apr 2016 14:43:45 -0700 (PDT) Received: by mail-qg0-x231.google.com with SMTP id c6so101763348qga.1 for ; Fri, 08 Apr 2016 14:43:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=aD8bURQQyaBqCeeXXX2OHtYc74bliXhf/LuQgG7UlLY=; b=LvaZw94j+sdUWDq2vgOAFWdaf97NBSfi275UCcFZjDpAtI6Bh2pIGG3Gzdr3uIUaVS Z/mN2iq1Kqo1tAXtZVwbBBx9SvsyB+XSu1I4WvfGXtoLrV/QLAr53i9su2dbqbiK41Ed SLMTycbG5sxMNXYK+zDgMXBev54I5N3csF45HDnaVIrrpF7jtgPrToXknrw/iT21aWEU 8QS0Af0/opzQgtxU3Nj8j560XVIqyKaluXUU7MXL/C7/6Zp1WW1f6NhHtrmJ20tzV3a8 hPSUpGvUID9cT6hik12+rXWXEUhsXG3JCGTMpGreuE3gpjuB77duA9TrhT1vQZz+fPpX yJdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=aD8bURQQyaBqCeeXXX2OHtYc74bliXhf/LuQgG7UlLY=; b=btqv9XLetgd8wRO2X3SyowXkMDmu8Ngo1utiXRe9oBP5BatPLDREM5464E/T5ORbP+ h1OcsX74j7AY+YOOfUoVo3xOZlCzCSSIDCU+xPa3lGAoGiCOWRc0Vn+YrzSAMlv5dD2J 8SsdJ4x3EUVIs1+o8Isf7LAqSyb1d6WJ3Qlp+ytnpqvtldBZxyTrnZ5x1bLPzmUb7mTv 3D28ETWOPaIf6unb8F0tHs0Hg+5zK7aI27mg9hyoZrG5xNoVVHp9KnvfbJOoVVLJgWDx rsE6L7nfkDqSY9Ur4ADVpgBkIn2xB6YeTbuh9z/48LEycedmh9wfy33/LaeEJCDdIgiQ /V2w== X-Gm-Message-State: AD7BkJLOPjCmWnezL/RKAYmuasxu8K/PouPuG2ummKt41Ii6tUD7QwJgTfNHTDn2ZLTr7w== X-Received: by 10.140.44.8 with SMTP id f8mr14098400qga.42.1460151824491; Fri, 08 Apr 2016 14:43:44 -0700 (PDT) Received: from [192.168.125.52] (host146.181-15-121.telecom.net.ar. [181.15.121.146]) by smtp.gmail.com with ESMTPSA id r198sm6275558qhb.22.2016.04.08.14.43.42 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 08 Apr 2016 14:43:43 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_C558D1C1-CAC7-4EC6-9D8E-72E66BA497C4" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: John Bradley In-Reply-To: Date: Fri, 8 Apr 2016 18:43:41 -0300 Message-Id: References: <20160408184624.23058.51335.idtracker@ietfa.amsl.com> To: Phil Hunt X-Mailer: Apple Mail (2.3124) Archived-At: Cc: id-event@ietf.org Subject: Re: [Id-event] Fwd: New Version Notification for draft-hunt-idevent-token-01.txt X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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: Fri, 08 Apr 2016 21:43:48 -0000 --Apple-Mail=_C558D1C1-CAC7-4EC6-9D8E-72E66BA497C4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I asked the RFC editor about best practice for using URI, but she = didn=E2=80=99t know off hand. I will have to check into it some more. = Perhaps the only option for RFC is to use URN but that seems a bit = limiting. Other people like W3C and OIDF don=E2=80=99t seem to have a problem with = URI for namespaces. John B. > On Apr 8, 2016, at 3:55 PM, Phil Hunt wrote: >=20 > In this update to draft-hunt-idevent-token, William Denniss and John = Bradley proposed to generalize the event uri format to be any URI rather = than just URN. An example was also added for OIDC Logout (non-normative = - since the core spec won=E2=80=99t have normative events just = examples). Thanks William for revising the text. >=20 > I think we may have to add some text around event type URIs. For = example, suggesting that fragments could be use to distinguish = individual events that may be specified in a parent specification. E.g. = So while Logout might define only one event, a RISC or SCIM events spec = will define many. Also, IETF has multiple paths to its RFCs and the = change to numbering. Not sure what will be best for SCIM events in this = regard - maybe using urn=E2=80=99s works best for IETF specs? Guidance = greatly welcomed! >=20 > Phil >=20 > @independentid > www.independentid.com = phil.hunt@oracle.com = >=20 >=20 >=20 >=20 >=20 >> Begin forwarded message: >>=20 >> From: internet-drafts@ietf.org >> Subject: New Version Notification for draft-hunt-idevent-token-01.txt >> Date: April 8, 2016 at 3:46:24 PM GMT-3 >> To: "William Denniss" >, "Phil Hunt" >, "Morteza Ansari" = > >>=20 >>=20 >> A new version of I-D, draft-hunt-idevent-token-01.txt >> has been successfully submitted by Phil Hunt and posted to the >> IETF repository. >>=20 >> Name: draft-hunt-idevent-token >> Revision: 01 >> Title: Identity Event Token >> Document date: 2016-04-08 >> Group: Individual Submission >> Pages: 14 >> URL: = https://www.ietf.org/internet-drafts/draft-hunt-idevent-token-01.txt = >> Status: = https://datatracker.ietf.org/doc/draft-hunt-idevent-token/ = >> Htmlized: = https://tools.ietf.org/html/draft-hunt-idevent-token-01 = >> Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-hunt-idevent-token-01 = >>=20 >> Abstract: >> This specification defines an Identity Event token which may be >> distributed via a protocol such as HTTP. An identity event token = is >> based on the JSON Web Token and may be optionally signed and/or >> encrypted. It describes a statement of fact that may be shared by = an >> event publisher with registered subscribers. >>=20 >>=20 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at tools.ietf.org = . >>=20 >> The IETF Secretariat >>=20 >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event --Apple-Mail=_C558D1C1-CAC7-4EC6-9D8E-72E66BA497C4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I asked the RFC editor about best practice for using URI, but = she didn=E2=80=99t know off hand.  I will have to check into it = some more.  Perhaps the only option for RFC is to use URN but that = seems a bit limiting.

Other people like W3C and OIDF don=E2=80=99t seem to have a = problem with URI for namespaces.

John B.
On Apr 8, 2016, at 3:55 PM, = Phil Hunt <phil.hunt@oracle.com> wrote:

In this update = to draft-hunt-idevent-token, William Denniss and John Bradley proposed = to generalize the event uri format to be any URI rather than just URN. = An example was also added for OIDC Logout (non-normative - since the = core spec won=E2=80=99t have normative events just examples). =  Thanks William for revising the text.

I think we may have to add some text = around event type URIs. For example, suggesting that fragments could be = use to distinguish individual events that may be specified in a parent = specification.  E.g. So while Logout might define only one event, a = RISC or SCIM events spec will define many.  Also, IETF has multiple = paths to its RFCs and the change to numbering. Not sure what will be = best for SCIM events in this regard - maybe using urn=E2=80=99s works = best for IETF specs?  Guidance greatly welcomed!





Begin forwarded message:

From: internet-drafts@ietf.org
Subject: New Version Notification for = draft-hunt-idevent-token-01.txt
Date: April 8, 2016 at 3:46:24 PM GMT-3
To: "William Denniss" <wdenniss@google.com>, "Phil Hunt" <phil.hunt@yahoo.com>, "Morteza Ansari" <morteza.ansari@cisco.com>

A new version = of I-D, draft-hunt-idevent-token-01.txt
has been = successfully submitted by Phil Hunt and posted to the
IETF = repository.

Name: = draft-hunt-idevent-token
Revision: 01
Title:= = Identity Event Token
Document date: = 2016-04-08
Group: Individual Submission
Pages:= = 14
URL: =            https://www.ietf.org/internet-drafts/draft-hunt-idevent-token-0= 1.txt
Status: =         https://datatracker.ietf.org/doc/draft-hunt-idevent-token/<= br class=3D"">Htmlized:       https://tools.ietf.org/html/draft-hunt-idevent-token-01
Diff: =           https://www.ietf.org/rfcdiff?url2=3Ddraft-hunt-idevent-token-01=

Abstract:
=   This specification defines an Identity Event token which may = be
  distributed via a protocol such as HTTP. =  An identity event token is
  based on the = JSON Web Token and may be optionally signed and/or
=   encrypted.  It describes a statement of fact that may = be shared by an
  event publisher with = registered subscribers.




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

The IETF = Secretariat


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

= --Apple-Mail=_C558D1C1-CAC7-4EC6-9D8E-72E66BA497C4-- From nobody Fri Apr 8 14:54:01 2016 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5267712D11D for ; Fri, 8 Apr 2016 14:54:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=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 JgyxoSbicwZa for ; Fri, 8 Apr 2016 14:53:57 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0748.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:748]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFADF12D680 for ; Fri, 8 Apr 2016 14:53:55 -0700 (PDT) Received: from SN2PR0801MB558.namprd08.prod.outlook.com (10.160.15.148) by SN2PR0801MB559.namprd08.prod.outlook.com (10.160.15.149) with Microsoft SMTP Server (TLS) id 15.1.453.26; Fri, 8 Apr 2016 21:53:35 +0000 Received: from SN2PR0801MB558.namprd08.prod.outlook.com ([10.160.15.148]) by SN2PR0801MB558.namprd08.prod.outlook.com ([10.160.15.148]) with mapi id 15.01.0453.028; Fri, 8 Apr 2016 21:53:35 +0000 From: Nick Roy To: John Bradley , Phil Hunt Thread-Topic: [Id-event] Fwd: New Version Notification for draft-hunt-idevent-token-01.txt Thread-Index: AQHRkd/Aponm/bpmmU2NcJR/v89Uhp+AOeWA Date: Fri, 8 Apr 2016 21:53:35 +0000 Message-ID: References: <20160408184624.23058.51335.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ve7jtb.com; dkim=none (message not signed) header.d=none;ve7jtb.com; dmarc=none action=none header.from=internet2.edu; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2001:468:1f0c:1:c72:d5b5:4911:9199] x-ms-office365-filtering-correlation-id: 7c14c04f-3ce1-4e73-9202-08d35ff83c28 x-microsoft-exchange-diagnostics: 1; SN2PR0801MB559; 5:U2Sn2cJsn9g1SjcspXtz59/UjQMd5+UZ7OurhUpKfbyxiipIEJWUJevIJ4MnnmfZO/91ldMvdAI7JhsDlOb1/LAFDjiwClNM/0LB2023mfTcS67n3a4TdJG9LnWFkOqYxdRSmEVcCiuumBrE/vYHfw==; 24:BFHDygwJrdmMnGbtZKczOApp4FG0JvJimLKjzwiNH2gUgNtAgBy8iseBu+3r8d/M24YMR3bzfubJ0MNq65/PLWQcHqeni3BFSF0eL/YRzkw= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN2PR0801MB559; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:SN2PR0801MB559; BCL:0; PCL:0; RULEID:; SRVR:SN2PR0801MB559; x-forefront-prvs: 0906E83A25 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377424004)(377454003)(2473001)(24454002)(33656002)(87936001)(83716003)(16236675004)(5001770100001)(2900100001)(15975445007)(89122001)(106116001)(230783001)(2950100001)(99286002)(92566002)(86362001)(82746002)(5008740100001)(5002640100001)(586003)(76176999)(54356999)(77096005)(50986999)(6116002)(7110500001)(102836003)(189998001)(19580395003)(19580405001)(19617315012)(4326007)(88552002)(11100500001)(2906002)(3660700001)(10710500007)(15650500001)(10400500002)(5004730100002)(75432002)(1096002)(3280700002)(36756003)(1220700001)(2420400007)(90282001)(81166005)(122556002)(11970500006)(3826002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN2PR0801MB559; H:SN2PR0801MB558.namprd08.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_A6815628238B403BADB03885D333658Einternet2edu_" MIME-Version: 1.0 X-OriginatorOrg: internet2.edu X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Apr 2016 21:53:35.3629 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 78ea4b46-9f08-4ef5-949b-2dae057c55d8 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR0801MB559 Archived-At: Cc: "id-event@ietf.org" Subject: Re: [Id-event] Fwd: New Version Notification for draft-hunt-idevent-token-01.txt X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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: Fri, 08 Apr 2016 21:54:00 -0000 --_000_A6815628238B403BADB03885D333658Einternet2edu_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VVJJcyBpbiB0aGUgZm9ybSBvZiBVUkwgaGF2ZSB0aGUgYWRkaXRpb25hbCBwb3NzaWJsZSBiZW5l Zml0IG9mIGhvdXNpbmcgZG9jdW1lbnRhdGlvbiBhdCB0aGUgVVJMIHVzZWQgZm9yIHRoZSBuYW1l c3BhY2UsIHRoYXQgaXMsIHRoZXkgYXJlIHJlc29sdmFibGUuDQoNCk5pY2sNCg0KRnJvbTogSWQt ZXZlbnQgPGlkLWV2ZW50LWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmlkLWV2ZW50LWJvdW5jZXNA aWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2YgSm9obiBCcmFkbGV5IDx2ZTdqdGJAdmU3anRiLmNvbTxt YWlsdG86dmU3anRiQHZlN2p0Yi5jb20+Pg0KRGF0ZTogRnJpZGF5LCBBcHJpbCA4LCAyMDE2IGF0 IDM6NDMgUE0NClRvOiBQaGlsIEh1bnQgPHBoaWwuaHVudEBvcmFjbGUuY29tPG1haWx0bzpwaGls Lmh1bnRAb3JhY2xlLmNvbT4+DQpDYzogImlkLWV2ZW50QGlldGYub3JnPG1haWx0bzppZC1ldmVu dEBpZXRmLm9yZz4iIDxpZC1ldmVudEBpZXRmLm9yZzxtYWlsdG86aWQtZXZlbnRAaWV0Zi5vcmc+ Pg0KU3ViamVjdDogUmU6IFtJZC1ldmVudF0gRndkOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24g Zm9yIGRyYWZ0LWh1bnQtaWRldmVudC10b2tlbi0wMS50eHQNCg0KSSBhc2tlZCB0aGUgUkZDIGVk aXRvciBhYm91dCBiZXN0IHByYWN0aWNlIGZvciB1c2luZyBVUkksIGJ1dCBzaGUgZGlkbuKAmXQg a25vdyBvZmYgaGFuZC4gIEkgd2lsbCBoYXZlIHRvIGNoZWNrIGludG8gaXQgc29tZSBtb3JlLiAg UGVyaGFwcyB0aGUgb25seSBvcHRpb24gZm9yIFJGQyBpcyB0byB1c2UgVVJOIGJ1dCB0aGF0IHNl ZW1zIGEgYml0IGxpbWl0aW5nLg0KDQpPdGhlciBwZW9wbGUgbGlrZSBXM0MgYW5kIE9JREYgZG9u 4oCZdCBzZWVtIHRvIGhhdmUgYSBwcm9ibGVtIHdpdGggVVJJIGZvciBuYW1lc3BhY2VzLg0KDQpK b2huIEIuDQpPbiBBcHIgOCwgMjAxNiwgYXQgMzo1NSBQTSwgUGhpbCBIdW50IDxwaGlsLmh1bnRA b3JhY2xlLmNvbTxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+PiB3cm90ZToNCg0KSW4gdGhp cyB1cGRhdGUgdG8gZHJhZnQtaHVudC1pZGV2ZW50LXRva2VuLCBXaWxsaWFtIERlbm5pc3MgYW5k IEpvaG4gQnJhZGxleSBwcm9wb3NlZCB0byBnZW5lcmFsaXplIHRoZSBldmVudCB1cmkgZm9ybWF0 IHRvIGJlIGFueSBVUkkgcmF0aGVyIHRoYW4ganVzdCBVUk4uIEFuIGV4YW1wbGUgd2FzIGFsc28g YWRkZWQgZm9yIE9JREMgTG9nb3V0IChub24tbm9ybWF0aXZlIC0gc2luY2UgdGhlIGNvcmUgc3Bl YyB3b27igJl0IGhhdmUgbm9ybWF0aXZlIGV2ZW50cyBqdXN0IGV4YW1wbGVzKS4gIFRoYW5rcyBX aWxsaWFtIGZvciByZXZpc2luZyB0aGUgdGV4dC4NCg0KSSB0aGluayB3ZSBtYXkgaGF2ZSB0byBh ZGQgc29tZSB0ZXh0IGFyb3VuZCBldmVudCB0eXBlIFVSSXMuIEZvciBleGFtcGxlLCBzdWdnZXN0 aW5nIHRoYXQgZnJhZ21lbnRzIGNvdWxkIGJlIHVzZSB0byBkaXN0aW5ndWlzaCBpbmRpdmlkdWFs IGV2ZW50cyB0aGF0IG1heSBiZSBzcGVjaWZpZWQgaW4gYSBwYXJlbnQgc3BlY2lmaWNhdGlvbi4g IEUuZy4gU28gd2hpbGUgTG9nb3V0IG1pZ2h0IGRlZmluZSBvbmx5IG9uZSBldmVudCwgYSBSSVND IG9yIFNDSU0gZXZlbnRzIHNwZWMgd2lsbCBkZWZpbmUgbWFueS4gIEFsc28sIElFVEYgaGFzIG11 bHRpcGxlIHBhdGhzIHRvIGl0cyBSRkNzIGFuZCB0aGUgY2hhbmdlIHRvIG51bWJlcmluZy4gTm90 IHN1cmUgd2hhdCB3aWxsIGJlIGJlc3QgZm9yIFNDSU0gZXZlbnRzIGluIHRoaXMgcmVnYXJkIC0g bWF5YmUgdXNpbmcgdXJu4oCZcyB3b3JrcyBiZXN0IGZvciBJRVRGIHNwZWNzPyAgR3VpZGFuY2Ug Z3JlYXRseSB3ZWxjb21lZCENCg0KUGhpbA0KDQpAaW5kZXBlbmRlbnRpZA0Kd3d3LmluZGVwZW5k ZW50aWQuY29tPGh0dHA6Ly93d3cuaW5kZXBlbmRlbnRpZC5jb20vPg0KcGhpbC5odW50QG9yYWNs ZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPg0KDQoNCg0KDQoNCkJlZ2luIGZvcndh cmRlZCBtZXNzYWdlOg0KDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8bWFpbHRvOmlu dGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4NClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlv biBmb3IgZHJhZnQtaHVudC1pZGV2ZW50LXRva2VuLTAxLnR4dA0KRGF0ZTogQXByaWwgOCwgMjAx NiBhdCAzOjQ2OjI0IFBNIEdNVC0zDQpUbzogIldpbGxpYW0gRGVubmlzcyIgPHdkZW5uaXNzQGdv b2dsZS5jb208bWFpbHRvOndkZW5uaXNzQGdvb2dsZS5jb20+PiwgIlBoaWwgSHVudCIgPHBoaWwu aHVudEB5YWhvby5jb208bWFpbHRvOnBoaWwuaHVudEB5YWhvby5jb20+PiwgIk1vcnRlemEgQW5z YXJpIiA8bW9ydGV6YS5hbnNhcmlAY2lzY28uY29tPG1haWx0bzptb3J0ZXphLmFuc2FyaUBjaXNj by5jb20+Pg0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1odW50LWlkZXZlbnQtdG9r ZW4tMDEudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFBoaWwgSHVudCBh bmQgcG9zdGVkIHRvIHRoZQ0KSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOiBkcmFmdC1odW50LWlk ZXZlbnQtdG9rZW4NClJldmlzaW9uOiAwMQ0KVGl0bGU6IElkZW50aXR5IEV2ZW50IFRva2VuDQpE b2N1bWVudCBkYXRlOiAyMDE2LTA0LTA4DQpHcm91cDogSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpQ YWdlczogMTQNClVSTDogICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1k cmFmdHMvZHJhZnQtaHVudC1pZGV2ZW50LXRva2VuLTAxLnR4dA0KU3RhdHVzOiAgICAgICAgIGh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWh1bnQtaWRldmVudC10b2tlbi8N Ckh0bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaHVudC1p ZGV2ZW50LXRva2VuLTAxDQpEaWZmOiAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZj ZGlmZj91cmwyPWRyYWZ0LWh1bnQtaWRldmVudC10b2tlbi0wMQ0KDQpBYnN0cmFjdDoNCiAgVGhp cyBzcGVjaWZpY2F0aW9uIGRlZmluZXMgYW4gSWRlbnRpdHkgRXZlbnQgdG9rZW4gd2hpY2ggbWF5 IGJlDQogIGRpc3RyaWJ1dGVkIHZpYSBhIHByb3RvY29sIHN1Y2ggYXMgSFRUUC4gIEFuIGlkZW50 aXR5IGV2ZW50IHRva2VuIGlzDQogIGJhc2VkIG9uIHRoZSBKU09OIFdlYiBUb2tlbiBhbmQgbWF5 IGJlIG9wdGlvbmFsbHkgc2lnbmVkIGFuZC9vcg0KICBlbmNyeXB0ZWQuICBJdCBkZXNjcmliZXMg YSBzdGF0ZW1lbnQgb2YgZmFjdCB0aGF0IG1heSBiZSBzaGFyZWQgYnkgYW4NCiAgZXZlbnQgcHVi bGlzaGVyIHdpdGggcmVnaXN0ZXJlZCBzdWJzY3JpYmVycy4NCg0KDQoNCg0KUGxlYXNlIG5vdGUg dGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3Vi bWlzc2lvbg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJs ZSBhdCB0b29scy5pZXRmLm9yZzxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvPi4NCg0KVGhlIElFVEYg U2VjcmV0YXJpYXQNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KSWQtZXZlbnQgbWFpbGluZyBsaXN0DQpJZC1ldmVudEBpZXRmLm9yZzxtYWlsdG86 SWQtZXZlbnRAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2lkLWV2ZW50DQoNCg== --_000_A6815628238B403BADB03885D333658Einternet2edu_ Content-Type: text/html; charset="utf-8" Content-ID: <0369D9F1A13DE949834FA12F82FD0B14@namprd08.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2PlVSSXMgaW4gdGhlIGZvcm0gb2YgVVJMIGhhdmUgdGhlIGFkZGl0aW9uYWwgcG9zc2libGUg YmVuZWZpdCBvZiBob3VzaW5nIGRvY3VtZW50YXRpb24gYXQgdGhlIFVSTCB1c2VkIGZvciB0aGUg bmFtZXNwYWNlLCB0aGF0IGlzLCB0aGV5IGFyZSByZXNvbHZhYmxlLjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pk5pY2s8L2Rpdj4NCjxkaXY+PGJyPg0KPC9k aXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0KPGRpdiBzdHlsZT0iZm9udC1m YW1pbHk6Q2FsaWJyaTsgZm9udC1zaXplOjEycHQ7IHRleHQtYWxpZ246bGVmdDsgY29sb3I6Ymxh Y2s7IEJPUkRFUi1CT1RUT006IG1lZGl1bSBub25lOyBCT1JERVItTEVGVDogbWVkaXVtIG5vbmU7 IFBBRERJTkctQk9UVE9NOiAwaW47IFBBRERJTkctTEVGVDogMGluOyBQQURESU5HLVJJR0hUOiAw aW47IEJPUkRFUi1UT1A6ICNiNWM0ZGYgMXB0IHNvbGlkOyBCT1JERVItUklHSFQ6IG1lZGl1bSBu b25lOyBQQURESU5HLVRPUDogM3B0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5G cm9tOiA8L3NwYW4+SWQtZXZlbnQgJmx0OzxhIGhyZWY9Im1haWx0bzppZC1ldmVudC1ib3VuY2Vz QGlldGYub3JnIj5pZC1ldmVudC1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsgb24gYmVoYWxmIG9m IEpvaG4gQnJhZGxleSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29tIj52ZTdq dGJAdmU3anRiLmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQi PkRhdGU6IDwvc3Bhbj5GcmlkYXksIEFwcmlsIDgsIDIwMTYgYXQgMzo0MyBQTTxicj4NCjxzcGFu IHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5UbzogPC9zcGFuPlBoaWwgSHVudCAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIj5waGlsLmh1bnRAb3JhY2xlLmNvbTwvYT4m Z3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkNjOiA8L3NwYW4+JnF1b3Q7 PGEgaHJlZj0ibWFpbHRvOmlkLWV2ZW50QGlldGYub3JnIj5pZC1ldmVudEBpZXRmLm9yZzwvYT4m cXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzppZC1ldmVudEBpZXRmLm9yZyI+aWQtZXZlbnRAaWV0 Zi5vcmc8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5TdWJqZWN0 OiA8L3NwYW4+UmU6IFtJZC1ldmVudF0gRndkOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9y IGRyYWZ0LWh1bnQtaWRldmVudC10b2tlbi0wMS50eHQ8YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0 LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7 IiBjbGFzcz0iIj4NCkkgYXNrZWQgdGhlIFJGQyBlZGl0b3IgYWJvdXQgYmVzdCBwcmFjdGljZSBm b3IgdXNpbmcgVVJJLCBidXQgc2hlIGRpZG7igJl0IGtub3cgb2ZmIGhhbmQuICZuYnNwO0kgd2ls bCBoYXZlIHRvIGNoZWNrIGludG8gaXQgc29tZSBtb3JlLiAmbmJzcDtQZXJoYXBzIHRoZSBvbmx5 IG9wdGlvbiBmb3IgUkZDIGlzIHRvIHVzZSBVUk4gYnV0IHRoYXQgc2VlbXMgYSBiaXQgbGltaXRp bmcuDQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5P dGhlciBwZW9wbGUgbGlrZSBXM0MgYW5kIE9JREYgZG9u4oCZdCBzZWVtIHRvIGhhdmUgYSBwcm9i bGVtIHdpdGggVVJJIGZvciBuYW1lc3BhY2VzLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xh c3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Sm9obiBCLjxiciBjbGFzcz0iIj4NCjxkaXY+ DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+T24gQXBy IDgsIDIwMTYsIGF0IDM6NTUgUE0sIFBoaWwgSHVudCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBoaWwu aHVudEBvcmFjbGUuY29tIiBjbGFzcz0iIj5waGlsLmh1bnRAb3JhY2xlLmNvbTwvYT4mZ3Q7IHdy b3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYg Y2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJz cC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNs YXNzPSIiPg0KSW4gdGhpcyB1cGRhdGUgdG8gZHJhZnQtaHVudC1pZGV2ZW50LXRva2VuLCBXaWxs aWFtIERlbm5pc3MgYW5kIEpvaG4gQnJhZGxleSBwcm9wb3NlZCB0byBnZW5lcmFsaXplIHRoZSBl dmVudCB1cmkgZm9ybWF0IHRvIGJlIGFueSBVUkkgcmF0aGVyIHRoYW4ganVzdCBVUk4uIEFuIGV4 YW1wbGUgd2FzIGFsc28gYWRkZWQgZm9yIE9JREMgTG9nb3V0IChub24tbm9ybWF0aXZlIC0gc2lu Y2UgdGhlIGNvcmUgc3BlYyB3b27igJl0IGhhdmUgbm9ybWF0aXZlDQogZXZlbnRzIGp1c3QgZXhh bXBsZXMpLiAmbmJzcDtUaGFua3MgV2lsbGlhbSBmb3IgcmV2aXNpbmcgdGhlIHRleHQuDQo8ZGl2 IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5JIHRoaW5rIHdl IG1heSBoYXZlIHRvIGFkZCBzb21lIHRleHQgYXJvdW5kIGV2ZW50IHR5cGUgVVJJcy4gRm9yIGV4 YW1wbGUsIHN1Z2dlc3RpbmcgdGhhdCBmcmFnbWVudHMgY291bGQgYmUgdXNlIHRvIGRpc3Rpbmd1 aXNoIGluZGl2aWR1YWwgZXZlbnRzIHRoYXQgbWF5IGJlIHNwZWNpZmllZCBpbiBhIHBhcmVudCBz cGVjaWZpY2F0aW9uLiAmbmJzcDtFLmcuIFNvIHdoaWxlIExvZ291dCBtaWdodCBkZWZpbmUgb25s eSBvbmUgZXZlbnQsDQogYSBSSVNDIG9yIFNDSU0gZXZlbnRzIHNwZWMgd2lsbCBkZWZpbmUgbWFu eS4gJm5ic3A7QWxzbywgSUVURiBoYXMgbXVsdGlwbGUgcGF0aHMgdG8gaXRzIFJGQ3MgYW5kIHRo ZSBjaGFuZ2UgdG8gbnVtYmVyaW5nLiBOb3Qgc3VyZSB3aGF0IHdpbGwgYmUgYmVzdCBmb3IgU0NJ TSBldmVudHMgaW4gdGhpcyByZWdhcmQgLSBtYXliZSB1c2luZyB1cm7igJlzIHdvcmtzIGJlc3Qg Zm9yIElFVEYgc3BlY3M/ICZuYnNwO0d1aWRhbmNlIGdyZWF0bHkgd2VsY29tZWQhPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYg Y2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibGV0dGVyLXNwYWNpbmc6IG5v cm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7 IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87 IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHdvcmQt d3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUt YnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJsZXR0ZXIt c3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1p bmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdp ZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6 IDBweDsgd29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13 ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxkaXYgY2xh c3M9IiI+PHNwYW4gY2xhc3M9IkFwcGxlLXN0eWxlLXNwYW4iIHN0eWxlPSJib3JkZXItY29sbGFw c2U6IHNlcGFyYXRlOyBsaW5lLWhlaWdodDogbm9ybWFsOyBib3JkZXItc3BhY2luZzogMHB4OyI+ DQo8ZGl2IGNsYXNzPSIiIHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJz cC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiPg0K PGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPlBoaWw8L2Rpdj4N CjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkBpbmRl cGVuZGVudGlkPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxhIGhyZWY9Imh0dHA6Ly93d3cuaW5kZXBl bmRlbnRpZC5jb20vIiBjbGFzcz0iIj53d3cuaW5kZXBlbmRlbnRpZC5jb208L2E+PC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBv cmFjbGUuY29tIiBjbGFzcz0iIiBzdHlsZT0ib3JwaGFuczogMjsgd2lkb3dzOiAyOyI+cGhpbC5o dW50QG9yYWNsZS5jb208L2E+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwv ZGl2Pg0KPC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPC9k aXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGJyIGNsYXNzPSJB cHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xh c3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+ QmVnaW4gZm9yd2FyZGVkIG1lc3NhZ2U6PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hh bmdlLW5ld2xpbmUiPg0KPGRpdiBzdHlsZT0ibWFyZ2luLXRvcDogMHB4OyBtYXJnaW4tcmlnaHQ6 IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4OyBtYXJnaW4tbGVmdDogMHB4OyIgY2xhc3M9IiI+DQo8 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IC13ZWJraXQtc3lzdGVtLWZvbnQsICdIZWx2ZXRpY2Eg TmV1ZScsIEhlbHZldGljYSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPjxiIGNsYXNzPSIiPkZyb206 DQo8L2I+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogLXdlYmtpdC1zeXN0ZW0tZm9u dCwgSGVsdmV0aWNhIE5ldWUsIEhlbHZldGljYSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPjxhIGhy ZWY9Im1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciIGNsYXNzPSIiPmludGVybmV0LWRy YWZ0c0BpZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+DQo8L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxl PSJtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1yaWdodDogMHB4OyBtYXJnaW4tYm90dG9tOiAwcHg7 IG1hcmdpbi1sZWZ0OiAwcHg7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTog LXdlYmtpdC1zeXN0ZW0tZm9udCwgJ0hlbHZldGljYSBOZXVlJywgSGVsdmV0aWNhLCBzYW5zLXNl cmlmOyIgY2xhc3M9IiI+PGIgY2xhc3M9IiI+U3ViamVjdDoNCjwvYj48L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiAtd2Via2l0LXN5c3RlbS1mb250LCBIZWx2ZXRpY2EgTmV1ZSwgSGVs dmV0aWNhLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+PGIgY2xhc3M9IiI+TmV3IFZlcnNpb24gTm90 aWZpY2F0aW9uIGZvciBkcmFmdC1odW50LWlkZXZlbnQtdG9rZW4tMDEudHh0PC9iPjxiciBjbGFz cz0iIj4NCjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi10b3A6IDBweDsgbWFyZ2lu LXJpZ2h0OiAwcHg7IG1hcmdpbi1ib3R0b206IDBweDsgbWFyZ2luLWxlZnQ6IDBweDsiIGNsYXNz PSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiAtd2Via2l0LXN5c3RlbS1mb250LCAnSGVs dmV0aWNhIE5ldWUnLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj48YiBjbGFzcz0i Ij5EYXRlOg0KPC9iPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IC13ZWJraXQtc3lz dGVtLWZvbnQsIEhlbHZldGljYSBOZXVlLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IiBjbGFzcz0i Ij5BcHJpbCA4LCAyMDE2IGF0IDM6NDY6MjQgUE0gR01ULTM8YnIgY2xhc3M9IiI+DQo8L3NwYW4+ PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1yaWdodDogMHB4OyBt YXJnaW4tYm90dG9tOiAwcHg7IG1hcmdpbi1sZWZ0OiAwcHg7IiBjbGFzcz0iIj4NCjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTogLXdlYmtpdC1zeXN0ZW0tZm9udCwgJ0hlbHZldGljYSBOZXVlJywg SGVsdmV0aWNhLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+PGIgY2xhc3M9IiI+VG86DQo8L2I+PC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogLXdlYmtpdC1zeXN0ZW0tZm9udCwgSGVsdmV0 aWNhIE5ldWUsIEhlbHZldGljYSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPiZxdW90O1dpbGxpYW0g RGVubmlzcyZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOndkZW5uaXNzQGdvb2dsZS5jb20iIGNs YXNzPSIiPndkZW5uaXNzQGdvb2dsZS5jb208L2E+Jmd0OywgJnF1b3Q7UGhpbCBIdW50JnF1b3Q7 ICZsdDs8YSBocmVmPSJtYWlsdG86cGhpbC5odW50QHlhaG9vLmNvbSIgY2xhc3M9IiI+cGhpbC5o dW50QHlhaG9vLmNvbTwvYT4mZ3Q7LA0KICZxdW90O01vcnRlemEgQW5zYXJpJnF1b3Q7ICZsdDs8 YSBocmVmPSJtYWlsdG86bW9ydGV6YS5hbnNhcmlAY2lzY28uY29tIiBjbGFzcz0iIj5tb3J0ZXph LmFuc2FyaUBjaXNjby5jb208L2E+Jmd0OzxiciBjbGFzcz0iIj4NCjwvc3Bhbj48L2Rpdj4NCjxi ciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4N CkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1odW50LWlkZXZlbnQtdG9rZW4tMDEudHh0PGJy IGNsYXNzPSIiPg0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBQaGlsIEh1bnQg YW5kIHBvc3RlZCB0byB0aGU8YnIgY2xhc3M9IiI+DQpJRVRGIHJlcG9zaXRvcnkuPGJyIGNsYXNz PSIiPg0KPGJyIGNsYXNzPSIiPg0KTmFtZTo8c3BhbiBjbGFzcz0iQXBwbGUtdGFiLXNwYW4iIHN0 eWxlPSJ3aGl0ZS1zcGFjZTpwcmUiPiA8L3NwYW4+PHNwYW4gY2xhc3M9IkFwcGxlLXRhYi1zcGFu IiBzdHlsZT0id2hpdGUtc3BhY2U6cHJlIj48L3NwYW4+ZHJhZnQtaHVudC1pZGV2ZW50LXRva2Vu PGJyIGNsYXNzPSIiPg0KUmV2aXNpb246PHNwYW4gY2xhc3M9IkFwcGxlLXRhYi1zcGFuIiBzdHls ZT0id2hpdGUtc3BhY2U6cHJlIj4gPC9zcGFuPjAxPGJyIGNsYXNzPSIiPg0KVGl0bGU6PHNwYW4g Y2xhc3M9IkFwcGxlLXRhYi1zcGFuIiBzdHlsZT0id2hpdGUtc3BhY2U6cHJlIj4gPC9zcGFuPjxz cGFuIGNsYXNzPSJBcHBsZS10YWItc3BhbiIgc3R5bGU9IndoaXRlLXNwYWNlOnByZSI+PC9zcGFu PklkZW50aXR5IEV2ZW50IFRva2VuPGJyIGNsYXNzPSIiPg0KRG9jdW1lbnQgZGF0ZTo8c3BhbiBj bGFzcz0iQXBwbGUtdGFiLXNwYW4iIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUiPiA8L3NwYW4+MjAx Ni0wNC0wODxiciBjbGFzcz0iIj4NCkdyb3VwOjxzcGFuIGNsYXNzPSJBcHBsZS10YWItc3BhbiIg c3R5bGU9IndoaXRlLXNwYWNlOnByZSI+IDwvc3Bhbj48c3BhbiBjbGFzcz0iQXBwbGUtdGFiLXNw YW4iIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUiPjwvc3Bhbj5JbmRpdmlkdWFsIFN1Ym1pc3Npb248 YnIgY2xhc3M9IiI+DQpQYWdlczo8c3BhbiBjbGFzcz0iQXBwbGUtdGFiLXNwYW4iIHN0eWxlPSJ3 aGl0ZS1zcGFjZTpwcmUiPiA8L3NwYW4+PHNwYW4gY2xhc3M9IkFwcGxlLXRhYi1zcGFuIiBzdHls ZT0id2hpdGUtc3BhY2U6cHJlIj48L3NwYW4+MTQ8YnIgY2xhc3M9IiI+DQpVUkw6ICZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OzxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1odW50 LWlkZXZlbnQtdG9rZW4tMDEudHh0IiBjbGFzcz0iIj5odHRwczovL3d3dy5pZXRmLm9yZy9pbnRl cm5ldC1kcmFmdHMvZHJhZnQtaHVudC1pZGV2ZW50LXRva2VuLTAxLnR4dDwvYT48YnIgY2xhc3M9 IiI+DQpTdGF0dXM6ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOzxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWh1bnQt aWRldmVudC10b2tlbi8iIGNsYXNzPSIiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWh1bnQtaWRldmVudC10b2tlbi88L2E+PGJyIGNsYXNzPSIiPg0KSHRtbGl6ZWQ6ICZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1odW50LWlkZXZlbnQtdG9rZW4tMDEiIGNsYXNzPSIiPmh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1odW50LWlkZXZlbnQtdG9rZW4tMDE8L2E+PGJy IGNsYXNzPSIiPg0KRGlmZjogJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlm Zj91cmwyPWRyYWZ0LWh1bnQtaWRldmVudC10b2tlbi0wMSIgY2xhc3M9IiI+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWh1bnQtaWRldmVudC10b2tlbi0wMTwvYT48YnIg Y2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpBYnN0cmFjdDo8YnIgY2xhc3M9IiI+DQombmJzcDsm bmJzcDtUaGlzIHNwZWNpZmljYXRpb24gZGVmaW5lcyBhbiBJZGVudGl0eSBFdmVudCB0b2tlbiB3 aGljaCBtYXkgYmU8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDtkaXN0cmlidXRlZCB2aWEgYSBw cm90b2NvbCBzdWNoIGFzIEhUVFAuICZuYnNwO0FuIGlkZW50aXR5IGV2ZW50IHRva2VuIGlzPGJy IGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7YmFzZWQgb24gdGhlIEpTT04gV2ViIFRva2VuIGFuZCBt YXkgYmUgb3B0aW9uYWxseSBzaWduZWQgYW5kL29yPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7 ZW5jcnlwdGVkLiAmbmJzcDtJdCBkZXNjcmliZXMgYSBzdGF0ZW1lbnQgb2YgZmFjdCB0aGF0IG1h eSBiZSBzaGFyZWQgYnkgYW48YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDtldmVudCBwdWJsaXNo ZXIgd2l0aCByZWdpc3RlcmVkIHN1YnNjcmliZXJzLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0i Ij4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClBsZWFzZSBu b3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9m IHN1Ym1pc3Npb248YnIgY2xhc3M9IiI+DQp1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQg ZGlmZiBhcmUgYXZhaWxhYmxlIGF0IDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy8iIGNs YXNzPSIiPg0KdG9vbHMuaWV0Zi5vcmc8L2E+LjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4N ClRoZSBJRVRGIFNlY3JldGFyaWF0PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnIgY2xhc3M9IiI+DQpJZC1ldmVudCBtYWlsaW5nIGxpc3Q8YnIgY2xhc3M9IiI+DQo8 YSBocmVmPSJtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmciIGNsYXNzPSIiPklkLWV2ZW50QGlldGYu b3JnPC9hPjxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vaWQtZXZlbnQiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vaWQtZXZlbnQ8L2E+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp dj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvc3Bhbj4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_A6815628238B403BADB03885D333658Einternet2edu_-- From nobody Fri Apr 8 15:00:14 2016 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EAB812D916 for ; Fri, 8 Apr 2016 15:00:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.com 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 mHTJF576t4ep for ; Fri, 8 Apr 2016 15:00:10 -0700 (PDT) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) (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 82BEF12D658 for ; Fri, 8 Apr 2016 15:00:10 -0700 (PDT) Received: by mail-qg0-x231.google.com with SMTP id f105so78268654qge.2 for ; Fri, 08 Apr 2016 15:00:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=PK+jffO7W8huIWFhxBCy3T+wjWW5y8x17KSPFvMJ4As=; b=dW+38wIiBlS8UHf+Ge3scmsmsq+rTW5l6WaTfxKZ5H+/9taXsa4Dvbz16hPNeRPHa1 Be6XujiwSAP6If65JmDaPuBauMnyzch+lOh2W75ZjsOFfV8OtL4Al9ISduu92bNoL/9J 6cozYapZsTM9H+2s9ekTiQ1Pj3QIo6K+PP8L6kz9Vn8Dg0o7VHSWP/oEw87vGzzUrEwH e93FEIoQICv6z8aHnR5Ur9Kf2foeujgdqkZSCN+vY8gCRERuJmQSivaIjlCKwm15ue4y YdFcBwwnLmAn+zSp6X6eEHVx39TKmqbcSYDjCtJK8n+OaJ+SFXtzkByA7qMVjP8yHxx1 FqFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=PK+jffO7W8huIWFhxBCy3T+wjWW5y8x17KSPFvMJ4As=; b=YQt9ijvUlcFQZYEd5YAXrmjx9xpIKSZebdU39Juf0Moeep0vugFOjX+ijr53wrfYtT R4/w9+ITwrJrNLaXiuXk4CfyrMNL6n/RxxiJ3bhMtrm34GO6T6iEed3hNsXMxnRQdJ1s nmI5WaJQAmlvveT7DOA8Rp1g/JHQh6NryONnkUk2JC/7O1NMJPJQD6wgivoVgUMLNq8p +h0tkjY8ttiVYy7+rmqFE96LIjQXdeXIjzUBY2qP2r0mON42D6ojRa0oB+sYl0GST0R2 lveGmIfVw/ZB0HLkhzYXzkQ2cT+zMPPmyc5Igc0QGfthYqlqsmJduqpC0MthLMDDzbs7 WhkQ== X-Gm-Message-State: AD7BkJLbLmYiTvlW6ISeUl3rdu1wEWsbYtc89ZvB1//yPMaI8bQGBBVXeJE/P0i0KUsTRw== X-Received: by 10.140.201.130 with SMTP id w124mr15179140qha.57.1460152809513; Fri, 08 Apr 2016 15:00:09 -0700 (PDT) Received: from [192.168.125.52] (host146.181-15-121.telecom.net.ar. [181.15.121.146]) by smtp.gmail.com with ESMTPSA id h34sm6334949qge.30.2016.04.08.15.00.07 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 08 Apr 2016 15:00:09 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_354C06F2-AFA2-466D-ADF7-45657216A23A" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: John Bradley In-Reply-To: Date: Fri, 8 Apr 2016 19:00:05 -0300 Message-Id: References: <20160408184624.23058.51335.idtracker@ietfa.amsl.com> To: Nick Roy X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "id-event@ietf.org" , Phil Hunt Subject: Re: [Id-event] Fwd: New Version Notification for draft-hunt-idevent-token-01.txt X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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: Fri, 08 Apr 2016 22:00:13 -0000 --Apple-Mail=_354C06F2-AFA2-466D-ADF7-45657216A23A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Exactly. It also makes it posable for a university or someone to crate a local = namespace without jumping through a IANA hoop that they wouldn=E2=80=99t = do. It is way better to have developers use a URI in there own namespace = than make up unregistered URN that are going to collide. You know they will:) John B. > On Apr 8, 2016, at 6:53 PM, Nick Roy wrote: >=20 > URIs in the form of URL have the additional possible benefit of = housing documentation at the URL used for the namespace, that is, they = are resolvable. >=20 > Nick >=20 > From: Id-event > on behalf of John Bradley = > > Date: Friday, April 8, 2016 at 3:43 PM > To: Phil Hunt > > Cc: "id-event@ietf.org " > > Subject: Re: [Id-event] Fwd: New Version Notification for = draft-hunt-idevent-token-01.txt >=20 > I asked the RFC editor about best practice for using URI, but she = didn=E2=80=99t know off hand. I will have to check into it some more. = Perhaps the only option for RFC is to use URN but that seems a bit = limiting. >=20 > Other people like W3C and OIDF don=E2=80=99t seem to have a problem = with URI for namespaces. >=20 > John B. >> On Apr 8, 2016, at 3:55 PM, Phil Hunt > wrote: >>=20 >> In this update to draft-hunt-idevent-token, William Denniss and John = Bradley proposed to generalize the event uri format to be any URI rather = than just URN. An example was also added for OIDC Logout (non-normative = - since the core spec won=E2=80=99t have normative events just = examples). Thanks William for revising the text. >>=20 >> I think we may have to add some text around event type URIs. For = example, suggesting that fragments could be use to distinguish = individual events that may be specified in a parent specification. E.g. = So while Logout might define only one event, a RISC or SCIM events spec = will define many. Also, IETF has multiple paths to its RFCs and the = change to numbering. Not sure what will be best for SCIM events in this = regard - maybe using urn=E2=80=99s works best for IETF specs? Guidance = greatly welcomed! >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com = phil.hunt@oracle.com = >>=20 >>=20 >>=20 >>=20 >>=20 >>> Begin forwarded message: >>>=20 >>> From: internet-drafts@ietf.org >>> Subject: New Version Notification for = draft-hunt-idevent-token-01.txt >>> Date: April 8, 2016 at 3:46:24 PM GMT-3 >>> To: "William Denniss" >, "Phil Hunt" >, "Morteza Ansari" = > >>>=20 >>>=20 >>> A new version of I-D, draft-hunt-idevent-token-01.txt >>> has been successfully submitted by Phil Hunt and posted to the >>> IETF repository. >>>=20 >>> Name: draft-hunt-idevent-token >>> Revision: 01 >>> Title: Identity Event Token >>> Document date: 2016-04-08 >>> Group: Individual Submission >>> Pages: 14 >>> URL: = https://www.ietf.org/internet-drafts/draft-hunt-idevent-token-01.txt = >>> Status: = https://datatracker.ietf.org/doc/draft-hunt-idevent-token/ = >>> Htmlized: = https://tools.ietf.org/html/draft-hunt-idevent-token-01 = >>> Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-hunt-idevent-token-01 = >>>=20 >>> Abstract: >>> This specification defines an Identity Event token which may be >>> distributed via a protocol such as HTTP. An identity event token = is >>> based on the JSON Web Token and may be optionally signed and/or >>> encrypted. It describes a statement of fact that may be shared by = an >>> event publisher with registered subscribers. >>>=20 >>>=20 >>>=20 >>>=20 >>> Please note that it may take a couple of minutes from the time of = submission >>> until the htmlized version and diff are available at tools.ietf.org = . >>>=20 >>> The IETF Secretariat >>>=20 >>=20 >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://www.ietf.org/mailman/listinfo/id-event = >=20 --Apple-Mail=_354C06F2-AFA2-466D-ADF7-45657216A23A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Exactly.

It= also makes it posable for a university or someone to crate a local = namespace without jumping through a IANA hoop that they wouldn=E2=80=99t = do.

It is way = better to have developers use a URI in there own namespace than make up = unregistered URN that are going to collide.

You know they will:)

John B.

On Apr 8, 2016, at 6:53 PM, Nick Roy <nroy@internet2.edu> = wrote:

URIs in the form of URL have the additional possible = benefit of housing documentation at the URL used for the namespace, that = is, they are resolvable.

Nick

From: Id-event <id-event-bounces@ietf.org> on behalf of John Bradley = <ve7jtb@ve7jtb.com>
Date: Friday, April = 8, 2016 at 3:43 PM
To: Phil Hunt <phil.hunt@oracle.com>
Cc: "id-event@ietf.org" = <id-event@ietf.org>
Subject: Re: = [Id-event] Fwd: New Version Notification for = draft-hunt-idevent-token-01.txt

I asked the RFC editor about best practice for using URI, but she = didn=E2=80=99t know off hand.  I will have to check into it some = more.  Perhaps the only option for RFC is to use URN but that seems = a bit limiting.

Other people like W3C and OIDF don=E2=80=99t seem to = have a problem with URI for namespaces.

John B.
On Apr 8, 2016, at 3:55 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

In this update to draft-hunt-idevent-token, William Denniss and John = Bradley proposed to generalize the event uri format to be any URI rather = than just URN. An example was also added for OIDC Logout (non-normative = - since the core spec won=E2=80=99t have normative events just examples).  Thanks William for revising the text.

I think we may have to add some text around event type = URIs. For example, suggesting that fragments could be use to distinguish = individual events that may be specified in a parent specification. =  E.g. So while Logout might define only one event, a RISC or SCIM events spec will define many.  Also, IETF has = multiple paths to its RFCs and the change to numbering. Not sure what = will be best for SCIM events in this regard - maybe using urn=E2=80=99s = works best for IETF specs?  Guidance greatly welcomed!

Phil

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





Begin forwarded message:

From: internet-drafts@ietf.org
Subject: New Version = Notification for draft-hunt-idevent-token-01.txt
Date: April 8, 2016 at 3:46:24 PM = GMT-3
To: "William Denniss" <wdenniss@google.com>, "Phil Hunt" <phil.hunt@yahoo.com>, "Morteza Ansari" <morteza.ansari@cisco.com>


A new version of I-D, draft-hunt-idevent-token-01.txt
has been successfully submitted by Phil Hunt and posted to the
IETF repository.

Name: = draft-hunt-idevent-token
Revision: = 01
Title: = Identity Event Token
Document date: = 2016-04-08
Group: = Individual Submission
Pages: = 14
URL: =            https://www.ietf.org/internet-drafts/draft-hunt-idevent-token-0= 1.txt
Status:         https://datatracker.ietf.org/doc/draft-hunt-idevent-token/<= br class=3D""> Htmlized:       https://tools.ietf.org/html/draft-hunt-idevent-token-01
Diff:           https://www.ietf.org/rfcdiff?url2=3Ddraft-hunt-idevent-token-01=

Abstract:
  This specification defines an Identity Event token which may = be
  distributed via a protocol such as HTTP.  An identity = event token is
  based on the JSON Web Token and may be optionally signed = and/or
  encrypted.  It describes a statement of fact that may = be shared by an
  event publisher with registered subscribers.




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

The IETF Secretariat


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

= --Apple-Mail=_354C06F2-AFA2-466D-ADF7-45657216A23A-- From nobody Fri Apr 8 15:04:44 2016 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53ED312D11F for ; Fri, 8 Apr 2016 15:04:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=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 ePz-23wsxocw for ; Fri, 8 Apr 2016 15:04:40 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (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 E902812D11D for ; Fri, 8 Apr 2016 15:04:39 -0700 (PDT) Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u38M4cSR006509 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 8 Apr 2016 22:04:39 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u38M4bd6009645 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 8 Apr 2016 22:04:38 GMT Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u38M4ZPj026942; Fri, 8 Apr 2016 22:04:35 GMT Received: from dhcp-8d4c.meeting.ietf.org (/31.133.141.76) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 08 Apr 2016 15:04:34 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_A3452E04-B0D0-4C88-87AF-5C2EBD813D24" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Phil Hunt In-Reply-To: Date: Fri, 8 Apr 2016 19:04:29 -0300 Message-Id: <5E203F9A-46F8-452B-891F-E1B5830C09E2@oracle.com> References: <20160408184624.23058.51335.idtracker@ietfa.amsl.com> To: Nick Roy X-Mailer: Apple Mail (2.3112) X-Source-IP: aserv0021.oracle.com [141.146.126.233] Archived-At: Cc: John Bradley , "id-event@ietf.org" Subject: Re: [Id-event] Fwd: New Version Notification for draft-hunt-idevent-token-01.txt X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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: Fri, 08 Apr 2016 22:04:43 -0000 --Apple-Mail=_A3452E04-B0D0-4C88-87AF-5C2EBD813D24 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 That is why we are considering it. However it doesn=E2=80=99t work well = for IETF since there are multiple ways of referencing the same RFC. This would lead to processing complexity and confusion by subscribers as = they might not recognize the difference between say: https://tools.ietf.org/html/rfc6749 = https://tools.ietf.org/pdf/rfc6749.pdf = https://datatracker.ietf.org/doc/rfc6749/ = and https://tools.ietf.org/rfc/rfc6749.txt = So while the =E2=80=9Ctxt=E2=80=9D is considered normative, you can see = why some developers wanting to generate events might be as confused and = send something the subscriber can=E2=80=99t automatically recognize. Phil @independentid www.independentid.com = phil.hunt@oracle.com = > On Apr 8, 2016, at 6:53 PM, Nick Roy wrote: >=20 > URIs in the form of URL have the additional possible benefit of = housing documentation at the URL used for the namespace, that is, they = are resolvable. >=20 > Nick >=20 > From: Id-event > on behalf of John Bradley = > > Date: Friday, April 8, 2016 at 3:43 PM > To: Phil Hunt > > Cc: "id-event@ietf.org " > > Subject: Re: [Id-event] Fwd: New Version Notification for = draft-hunt-idevent-token-01.txt >=20 > I asked the RFC editor about best practice for using URI, but she = didn=E2=80=99t know off hand. I will have to check into it some more. = Perhaps the only option for RFC is to use URN but that seems a bit = limiting. >=20 > Other people like W3C and OIDF don=E2=80=99t seem to have a problem = with URI for namespaces. >=20 > John B. >> On Apr 8, 2016, at 3:55 PM, Phil Hunt > wrote: >>=20 >> In this update to draft-hunt-idevent-token, William Denniss and John = Bradley proposed to generalize the event uri format to be any URI rather = than just URN. An example was also added for OIDC Logout (non-normative = - since the core spec won=E2=80=99t have normative events just = examples). Thanks William for revising the text. >>=20 >> I think we may have to add some text around event type URIs. For = example, suggesting that fragments could be use to distinguish = individual events that may be specified in a parent specification. E.g. = So while Logout might define only one event, a RISC or SCIM events spec = will define many. Also, IETF has multiple paths to its RFCs and the = change to numbering. Not sure what will be best for SCIM events in this = regard - maybe using urn=E2=80=99s works best for IETF specs? Guidance = greatly welcomed! >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com = phil.hunt@oracle.com = >>=20 >>=20 >>=20 >>=20 >>=20 >>> Begin forwarded message: >>>=20 >>> From: internet-drafts@ietf.org >>> Subject: New Version Notification for = draft-hunt-idevent-token-01.txt >>> Date: April 8, 2016 at 3:46:24 PM GMT-3 >>> To: "William Denniss" >, "Phil Hunt" >, "Morteza Ansari" = > >>>=20 >>>=20 >>> A new version of I-D, draft-hunt-idevent-token-01.txt >>> has been successfully submitted by Phil Hunt and posted to the >>> IETF repository. >>>=20 >>> Name: draft-hunt-idevent-token >>> Revision: 01 >>> Title: Identity Event Token >>> Document date: 2016-04-08 >>> Group: Individual Submission >>> Pages: 14 >>> URL: = https://www.ietf.org/internet-drafts/draft-hunt-idevent-token-01.txt = >>> Status: = https://datatracker.ietf.org/doc/draft-hunt-idevent-token/ = >>> Htmlized: = https://tools.ietf.org/html/draft-hunt-idevent-token-01 = >>> Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-hunt-idevent-token-01 = >>>=20 >>> Abstract: >>> This specification defines an Identity Event token which may be >>> distributed via a protocol such as HTTP. An identity event token = is >>> based on the JSON Web Token and may be optionally signed and/or >>> encrypted. It describes a statement of fact that may be shared by = an >>> event publisher with registered subscribers. >>>=20 >>>=20 >>>=20 >>>=20 >>> Please note that it may take a couple of minutes from the time of = submission >>> until the htmlized version and diff are available at tools.ietf.org = . >>>=20 >>> The IETF Secretariat >>>=20 >>=20 >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://www.ietf.org/mailman/listinfo/id-event = >=20 --Apple-Mail=_A3452E04-B0D0-4C88-87AF-5C2EBD813D24 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 That is why we are considering it. However it doesn=E2=80=99t = work well for IETF since there are multiple ways of referencing the same = RFC.

This would lead = to processing complexity and confusion by subscribers as they might not = recognize the difference between say:
https://tools.ietf.org/html/rfc6749
https://tools.ietf.org/pdf/rfc6749.pdf
https://datatracker.ietf.org/doc/rfc6749/
and
https://tools.ietf.org/rfc/rfc6749.txt

So while the =E2=80=9Ctxt=E2= =80=9D is considered normative, you can see why some developers wanting = to generate events might be as confused and send something the = subscriber can=E2=80=99t automatically recognize.



On Apr 8, 2016, at 6:53 PM, Nick Roy <nroy@internet2.edu> = wrote:

URIs in the form of URL have the additional possible = benefit of housing documentation at the URL used for the namespace, that = is, they are resolvable.

Nick

From: Id-event <id-event-bounces@ietf.org> on behalf of John Bradley = <ve7jtb@ve7jtb.com>
Date: Friday, April = 8, 2016 at 3:43 PM
To: Phil Hunt <phil.hunt@oracle.com>
Cc: "id-event@ietf.org" = <id-event@ietf.org>
Subject: Re: = [Id-event] Fwd: New Version Notification for = draft-hunt-idevent-token-01.txt

I asked the RFC editor about best practice for using URI, but she = didn=E2=80=99t know off hand.  I will have to check into it some = more.  Perhaps the only option for RFC is to use URN but that seems = a bit limiting.

Other people like W3C and OIDF don=E2=80=99t seem to = have a problem with URI for namespaces.

John B.
On Apr 8, 2016, at 3:55 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

In this update to draft-hunt-idevent-token, William Denniss and John = Bradley proposed to generalize the event uri format to be any URI rather = than just URN. An example was also added for OIDC Logout (non-normative = - since the core spec won=E2=80=99t have normative events just examples).  Thanks William for revising the text.

I think we may have to add some text around event type = URIs. For example, suggesting that fragments could be use to distinguish = individual events that may be specified in a parent specification. =  E.g. So while Logout might define only one event, a RISC or SCIM events spec will define many.  Also, IETF has = multiple paths to its RFCs and the change to numbering. Not sure what = will be best for SCIM events in this regard - maybe using urn=E2=80=99s = works best for IETF specs?  Guidance greatly welcomed!

Phil

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





Begin forwarded message:

From: internet-drafts@ietf.org
Subject: New Version = Notification for draft-hunt-idevent-token-01.txt
Date: April 8, 2016 at 3:46:24 PM = GMT-3
To: "William Denniss" <wdenniss@google.com>, "Phil Hunt" <phil.hunt@yahoo.com>, "Morteza Ansari" <morteza.ansari@cisco.com>


A new version of I-D, draft-hunt-idevent-token-01.txt
has been successfully submitted by Phil Hunt and posted to the
IETF repository.

Name: = draft-hunt-idevent-token
Revision: = 01
Title: = Identity Event Token
Document date: = 2016-04-08
Group: = Individual Submission
Pages: = 14
URL: =            https://www.ietf.org/internet-drafts/draft-hunt-idevent-token-0= 1.txt
Status:         https://datatracker.ietf.org/doc/draft-hunt-idevent-token/<= br class=3D""> Htmlized:       https://tools.ietf.org/html/draft-hunt-idevent-token-01
Diff:           https://www.ietf.org/rfcdiff?url2=3Ddraft-hunt-idevent-token-01=

Abstract:
  This specification defines an Identity Event token which may = be
  distributed via a protocol such as HTTP.  An identity = event token is
  based on the JSON Web Token and may be optionally signed = and/or
  encrypted.  It describes a statement of fact that may = be shared by an
  event publisher with registered subscribers.




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

The IETF Secretariat


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

= --Apple-Mail=_A3452E04-B0D0-4C88-87AF-5C2EBD813D24-- From nobody Fri Apr 8 15:08:34 2016 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD86312D5D0 for ; Fri, 8 Apr 2016 15:08:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=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 lmW9fNiQgMgy for ; Fri, 8 Apr 2016 15:08:31 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (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 C80D412D11F for ; Fri, 8 Apr 2016 15:08:30 -0700 (PDT) Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u38M8Tkb009583 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 8 Apr 2016 22:08:29 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u38M8SFs021408 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 8 Apr 2016 22:08:28 GMT Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u38M8R4O009054; Fri, 8 Apr 2016 22:08:28 GMT Received: from dhcp-8d4c.meeting.ietf.org (/31.133.141.76) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 08 Apr 2016 15:08:27 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_38A13FC3-DF7A-4950-BA55-1408C588BFCA" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Phil Hunt In-Reply-To: <5E203F9A-46F8-452B-891F-E1B5830C09E2@oracle.com> Date: Fri, 8 Apr 2016 19:08:23 -0300 Message-Id: <91466650-CE2F-48B8-B913-180736FACFAF@oracle.com> References: <20160408184624.23058.51335.idtracker@ietfa.amsl.com> <5E203F9A-46F8-452B-891F-E1B5830C09E2@oracle.com> To: Nick Roy X-Mailer: Apple Mail (2.3112) X-Source-IP: aserv0021.oracle.com [141.146.126.233] Archived-At: Cc: John Bradley , "id-event@ietf.org" Subject: Re: [Id-event] New Version Notification for draft-hunt-idevent-token-01.txt X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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: Fri, 08 Apr 2016 22:08:34 -0000 --Apple-Mail=_38A13FC3-DF7A-4950-BA55-1408C588BFCA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I should add, that within reason, I think it is ok for different = organizations to use what they prefer to use editorially. So I see no = issue with IETF specs using urns while others might use an http = referenced spec. That=E2=80=99s why we opened it up a bit. Phil @independentid www.independentid.com = phil.hunt@oracle.com = > On Apr 8, 2016, at 7:04 PM, Phil Hunt wrote: >=20 > That is why we are considering it. However it doesn=E2=80=99t work = well for IETF since there are multiple ways of referencing the same RFC. >=20 > This would lead to processing complexity and confusion by subscribers = as they might not recognize the difference between say: > https://tools.ietf.org/html/rfc6749 = > https://tools.ietf.org/pdf/rfc6749.pdf = > https://datatracker.ietf.org/doc/rfc6749/ = > and > https://tools.ietf.org/rfc/rfc6749.txt = >=20 > So while the =E2=80=9Ctxt=E2=80=9D is considered normative, you can = see why some developers wanting to generate events might be as confused = and send something the subscriber can=E2=80=99t automatically recognize. >=20 > Phil >=20 > @independentid > www.independentid.com = phil.hunt@oracle.com = >=20 >=20 >=20 >=20 >=20 >> On Apr 8, 2016, at 6:53 PM, Nick Roy > wrote: >>=20 >> URIs in the form of URL have the additional possible benefit of = housing documentation at the URL used for the namespace, that is, they = are resolvable. >>=20 >> Nick >>=20 >> From: Id-event > on behalf of John Bradley = > >> Date: Friday, April 8, 2016 at 3:43 PM >> To: Phil Hunt > >> Cc: "id-event@ietf.org " > >> Subject: Re: [Id-event] Fwd: New Version Notification for = draft-hunt-idevent-token-01.txt >>=20 >> I asked the RFC editor about best practice for using URI, but she = didn=E2=80=99t know off hand. I will have to check into it some more. = Perhaps the only option for RFC is to use URN but that seems a bit = limiting. >>=20 >> Other people like W3C and OIDF don=E2=80=99t seem to have a problem = with URI for namespaces. >>=20 >> John B. >>> On Apr 8, 2016, at 3:55 PM, Phil Hunt > wrote: >>>=20 >>> In this update to draft-hunt-idevent-token, William Denniss and John = Bradley proposed to generalize the event uri format to be any URI rather = than just URN. An example was also added for OIDC Logout (non-normative = - since the core spec won=E2=80=99t have normative events just = examples). Thanks William for revising the text. >>>=20 >>> I think we may have to add some text around event type URIs. For = example, suggesting that fragments could be use to distinguish = individual events that may be specified in a parent specification. E.g. = So while Logout might define only one event, a RISC or SCIM events spec = will define many. Also, IETF has multiple paths to its RFCs and the = change to numbering. Not sure what will be best for SCIM events in this = regard - maybe using urn=E2=80=99s works best for IETF specs? Guidance = greatly welcomed! >>>=20 >>> Phil >>>=20 >>> @independentid >>> www.independentid.com = phil.hunt@oracle.com = >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>> Begin forwarded message: >>>>=20 >>>> From: internet-drafts@ietf.org >>>> Subject: New Version Notification for = draft-hunt-idevent-token-01.txt >>>> Date: April 8, 2016 at 3:46:24 PM GMT-3 >>>> To: "William Denniss" >, "Phil Hunt" >, "Morteza Ansari" = > >>>>=20 >>>>=20 >>>> A new version of I-D, draft-hunt-idevent-token-01.txt >>>> has been successfully submitted by Phil Hunt and posted to the >>>> IETF repository. >>>>=20 >>>> Name: draft-hunt-idevent-token >>>> Revision: 01 >>>> Title: Identity Event Token >>>> Document date: 2016-04-08 >>>> Group: Individual Submission >>>> Pages: 14 >>>> URL: = https://www.ietf.org/internet-drafts/draft-hunt-idevent-token-01.txt = >>>> Status: = https://datatracker.ietf.org/doc/draft-hunt-idevent-token/ = >>>> Htmlized: = https://tools.ietf.org/html/draft-hunt-idevent-token-01 = >>>> Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-hunt-idevent-token-01 = >>>>=20 >>>> Abstract: >>>> This specification defines an Identity Event token which may be >>>> distributed via a protocol such as HTTP. An identity event token = is >>>> based on the JSON Web Token and may be optionally signed and/or >>>> encrypted. It describes a statement of fact that may be shared = by an >>>> event publisher with registered subscribers. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> Please note that it may take a couple of minutes from the time of = submission >>>> until the htmlized version and diff are available at tools.ietf.org = . >>>>=20 >>>> The IETF Secretariat >>>>=20 >>>=20 >>> _______________________________________________ >>> 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 --Apple-Mail=_38A13FC3-DF7A-4950-BA55-1408C588BFCA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I should add, that within reason, I think it is ok for = different organizations to use what they prefer to use editorially. So I = see no issue with IETF specs using urns while others might use an http = referenced spec.  That=E2=80=99s why we opened it up a bit.




On Apr 8, 2016, at 7:04 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

That is why we = are considering it. However it doesn=E2=80=99t work well for IETF since = there are multiple ways of referencing the same RFC.

This would lead to processing = complexity and confusion by subscribers as they might not recognize the = difference between say:
https://tools.ietf.org/html/rfc6749
https://tools.ietf.org/pdf/rfc6749.pdf
https://datatracker.ietf.org/doc/rfc6749/
and
https://tools.ietf.org/rfc/rfc6749.txt

So while the =E2=80=9Ctxt=E2= =80=9D is considered normative, you can see why some developers wanting = to generate events might be as confused and send something the = subscriber can=E2=80=99t automatically recognize.




On Apr 8, 2016, at 6:53 PM, Nick Roy <nroy@internet2.edu> = wrote:

URIs in the form of URL have the additional possible = benefit of housing documentation at the URL used for the namespace, that = is, they are resolvable.

Nick

From: Id-event <id-event-bounces@ietf.org> on behalf of John Bradley = <ve7jtb@ve7jtb.com>
Date: Friday, April = 8, 2016 at 3:43 PM
To: Phil Hunt <phil.hunt@oracle.com>
Cc: "id-event@ietf.org" = <id-event@ietf.org>
Subject: Re: = [Id-event] Fwd: New Version Notification for = draft-hunt-idevent-token-01.txt

I asked the RFC editor about best practice for using URI, but she = didn=E2=80=99t know off hand.  I will have to check into it some = more.  Perhaps the only option for RFC is to use URN but that seems = a bit limiting.

Other people like W3C and OIDF don=E2=80=99t seem to = have a problem with URI for namespaces.

John B.
On Apr 8, 2016, at 3:55 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

In this update to draft-hunt-idevent-token, William Denniss and John = Bradley proposed to generalize the event uri format to be any URI rather = than just URN. An example was also added for OIDC Logout (non-normative = - since the core spec won=E2=80=99t have normative events just examples).  Thanks William for revising the text.

I think we may have to add some text around event type = URIs. For example, suggesting that fragments could be use to distinguish = individual events that may be specified in a parent specification. =  E.g. So while Logout might define only one event, a RISC or SCIM events spec will define many.  Also, IETF has = multiple paths to its RFCs and the change to numbering. Not sure what = will be best for SCIM events in this regard - maybe using urn=E2=80=99s = works best for IETF specs?  Guidance greatly welcomed!

Phil

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





Begin forwarded message:

From: internet-drafts@ietf.org
Subject: New Version = Notification for draft-hunt-idevent-token-01.txt
Date: April 8, 2016 at 3:46:24 PM = GMT-3
To: "William Denniss" <wdenniss@google.com>, "Phil Hunt" <phil.hunt@yahoo.com>, "Morteza Ansari" <morteza.ansari@cisco.com>


A new version of I-D, draft-hunt-idevent-token-01.txt
has been successfully submitted by Phil Hunt and posted to the
IETF repository.

Name: = draft-hunt-idevent-token
Revision: = 01
Title: = Identity Event Token
Document date: = 2016-04-08
Group: = Individual Submission
Pages: = 14
URL: =            https://www.ietf.org/internet-drafts/draft-hunt-idevent-token-0= 1.txt
Status:         https://datatracker.ietf.org/doc/draft-hunt-idevent-token/<= br class=3D""> Htmlized:       https://tools.ietf.org/html/draft-hunt-idevent-token-01
Diff:           https://www.ietf.org/rfcdiff?url2=3Ddraft-hunt-idevent-token-01=

Abstract:
  This specification defines an Identity Event token which may = be
  distributed via a protocol such as HTTP.  An identity = event token is
  based on the JSON Web Token and may be optionally signed = and/or
  encrypted.  It describes a statement of fact that may = be shared by an
  event publisher with registered subscribers.




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

The IETF Secretariat


_______________________________________________
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=_38A13FC3-DF7A-4950-BA55-1408C588BFCA-- From nobody Fri Apr 8 15:13:51 2016 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 047CB12D5E3 for ; Fri, 8 Apr 2016 15:13:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.122 X-Spam-Level: X-Spam-Status: No, score=-1.122 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=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 vwiPciZ1o1oM for ; Fri, 8 Apr 2016 15:13:47 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0140.outbound.protection.outlook.com [65.55.169.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FE6212D5BD for ; Fri, 8 Apr 2016 15:13:47 -0700 (PDT) Received: from SN2PR0801MB558.namprd08.prod.outlook.com (10.160.15.148) by SN2PR0801MB557.namprd08.prod.outlook.com (10.160.15.147) with Microsoft SMTP Server (TLS) id 15.1.453.26; Fri, 8 Apr 2016 22:13:45 +0000 Received: from SN2PR0801MB558.namprd08.prod.outlook.com ([10.160.15.148]) by SN2PR0801MB558.namprd08.prod.outlook.com ([10.160.15.148]) with mapi id 15.01.0453.028; Fri, 8 Apr 2016 22:13:45 +0000 From: Nick Roy To: Phil Hunt Thread-Topic: [Id-event] Fwd: New Version Notification for draft-hunt-idevent-token-01.txt Thread-Index: AQHRkd/Aponm/bpmmU2NcJR/v89Uhp+AOeWAgABnmYD//54JgA== Date: Fri, 8 Apr 2016 22:13:45 +0000 Message-ID: <7769D8B3-5D1F-48CD-B622-AC284CE55B6E@internet2.edu> References: <20160408184624.23058.51335.idtracker@ietfa.amsl.com> <5E203F9A-46F8-452B-891F-E1B5830C09E2@oracle.com> In-Reply-To: <5E203F9A-46F8-452B-891F-E1B5830C09E2@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: oracle.com; dkim=none (message not signed) header.d=none;oracle.com; dmarc=none action=none header.from=internet2.edu; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2001:468:1f0c:1:c72:d5b5:4911:9199] x-ms-office365-filtering-correlation-id: 7807aac2-06be-4371-3696-08d35ffb0d67 x-microsoft-exchange-diagnostics: 1; SN2PR0801MB557; 5:i1/XtnJ509ASCMWpbycVMWKljlr791dvwoMmiBABjZPwyWtAbNhOzVmXsZ1DDiDz2sSzChNGnGvu3PsPJ5k3cY+dZ21ICCMLwayqRerY1xH6pexqWSOXfTgXdiTQKx714oFZpftUaJi5smHC6ooMMA==; 24:2lDHGbYU6CZBL0I5A8UUfQC8oQ0h9BFckEEh0KuoegEUGM067AKg85JCNehJrjgBiwbXTwW7WzHcMg7cWZR38hm7D5wd5tP5nsXU01+UJxQ= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN2PR0801MB557; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:SN2PR0801MB557; BCL:0; PCL:0; RULEID:; SRVR:SN2PR0801MB557; x-forefront-prvs: 0906E83A25 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(24454002)(377454003)(377424004)(2473001)(19617315012)(122556002)(87936001)(89122001)(92566002)(93886004)(75432002)(5008740100001)(86362001)(2900100001)(15650500001)(33656002)(10710500007)(90282001)(83716003)(16236675004)(230783001)(50986999)(11100500001)(76176999)(54356999)(19580395003)(586003)(1096002)(7110500001)(99286002)(102836003)(1220700001)(5004730100002)(36756003)(6116002)(82746002)(2906002)(189998001)(2950100001)(5002640100001)(3660700001)(110136002)(3280700002)(81166005)(77096005)(4326007)(15975445007)(88552002)(106116001)(19580405001)(16601075003)(10400500002)(2420400007)(11970500006)(3826002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN2PR0801MB557; H:SN2PR0801MB558.namprd08.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_7769D8B35D1F48CDB622AC284CE55B6Einternet2edu_" MIME-Version: 1.0 X-OriginatorOrg: internet2.edu X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Apr 2016 22:13:45.4576 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 78ea4b46-9f08-4ef5-949b-2dae057c55d8 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR0801MB557 Archived-At: Cc: John Bradley , "id-event@ietf.org" Subject: Re: [Id-event] Fwd: New Version Notification for draft-hunt-idevent-token-01.txt X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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: Fri, 08 Apr 2016 22:13:50 -0000 --_000_7769D8B35D1F48CDB622AC284CE55B6Einternet2edu_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U2VlbXMgbGlrZSB0aGF0IGlzIGEgZG9jdW1lbnQgbmFtZXNwYWNpbmcgaXNzdWUgdGhhdCBzaG91 bGQgYmUgcHJldHR5IHN0cmFpZ2h0Zm9yd2FyZCBmb3IgSUVURiB0byByZXNvbHZlLiAgSXMgSGVh dGhlciBhd2FyZSB0aGF0IHRoaXMgaXMgYSBuZWVkPw0KDQpOaWNrDQoNCkZyb206IFBoaWwgSHVu dCA8cGhpbC5odW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPj4NCkRh dGU6IEZyaWRheSwgQXByaWwgOCwgMjAxNiBhdCA0OjA0IFBNDQpUbzogTmljayBSb3kgPG5yb3lA aW50ZXJuZXQyLmVkdTxtYWlsdG86bnJveUBpbnRlcm5ldDIuZWR1Pj4NCkNjOiBKb2huIEJyYWRs ZXkgPHZlN2p0YkB2ZTdqdGIuY29tPG1haWx0bzp2ZTdqdGJAdmU3anRiLmNvbT4+LCAiaWQtZXZl bnRAaWV0Zi5vcmc8bWFpbHRvOmlkLWV2ZW50QGlldGYub3JnPiIgPGlkLWV2ZW50QGlldGYub3Jn PG1haWx0bzppZC1ldmVudEBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW0lkLWV2ZW50XSBGd2Q6 IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaHVudC1pZGV2ZW50LXRva2VuLTAx LnR4dA0KDQpUaGF0IGlzIHdoeSB3ZSBhcmUgY29uc2lkZXJpbmcgaXQuIEhvd2V2ZXIgaXQgZG9l c27igJl0IHdvcmsgd2VsbCBmb3IgSUVURiBzaW5jZSB0aGVyZSBhcmUgbXVsdGlwbGUgd2F5cyBv ZiByZWZlcmVuY2luZyB0aGUgc2FtZSBSRkMuDQoNClRoaXMgd291bGQgbGVhZCB0byBwcm9jZXNz aW5nIGNvbXBsZXhpdHkgYW5kIGNvbmZ1c2lvbiBieSBzdWJzY3JpYmVycyBhcyB0aGV5IG1pZ2h0 IG5vdCByZWNvZ25pemUgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiBzYXk6DQpodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvcmZjNjc0OQ0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9wZGYvcmZjNjc0 OS5wZGYNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL3JmYzY3NDkvDQphbmQNCmh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvcmZjL3JmYzY3NDkudHh0DQoNClNvIHdoaWxlIHRoZSDigJx0 eHTigJ0gaXMgY29uc2lkZXJlZCBub3JtYXRpdmUsIHlvdSBjYW4gc2VlIHdoeSBzb21lIGRldmVs b3BlcnMgd2FudGluZyB0byBnZW5lcmF0ZSBldmVudHMgbWlnaHQgYmUgYXMgY29uZnVzZWQgYW5k IHNlbmQgc29tZXRoaW5nIHRoZSBzdWJzY3JpYmVyIGNhbuKAmXQgYXV0b21hdGljYWxseSByZWNv Z25pemUuDQoNClBoaWwNCg0KQGluZGVwZW5kZW50aWQNCnd3dy5pbmRlcGVuZGVudGlkLmNvbTxo dHRwOi8vd3d3LmluZGVwZW5kZW50aWQuY29tPg0KcGhpbC5odW50QG9yYWNsZS5jb208bWFpbHRv OnBoaWwuaHVudEBvcmFjbGUuY29tPg0KDQoNCg0KDQoNCk9uIEFwciA4LCAyMDE2LCBhdCA2OjUz IFBNLCBOaWNrIFJveSA8bnJveUBpbnRlcm5ldDIuZWR1PG1haWx0bzpucm95QGludGVybmV0Mi5l ZHU+PiB3cm90ZToNCg0KVVJJcyBpbiB0aGUgZm9ybSBvZiBVUkwgaGF2ZSB0aGUgYWRkaXRpb25h bCBwb3NzaWJsZSBiZW5lZml0IG9mIGhvdXNpbmcgZG9jdW1lbnRhdGlvbiBhdCB0aGUgVVJMIHVz ZWQgZm9yIHRoZSBuYW1lc3BhY2UsIHRoYXQgaXMsIHRoZXkgYXJlIHJlc29sdmFibGUuDQoNCk5p Y2sNCg0KRnJvbTogSWQtZXZlbnQgPGlkLWV2ZW50LWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmlk LWV2ZW50LWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2YgSm9obiBCcmFkbGV5IDx2ZTdq dGJAdmU3anRiLmNvbTxtYWlsdG86dmU3anRiQHZlN2p0Yi5jb20+Pg0KRGF0ZTogRnJpZGF5LCBB cHJpbCA4LCAyMDE2IGF0IDM6NDMgUE0NClRvOiBQaGlsIEh1bnQgPHBoaWwuaHVudEBvcmFjbGUu Y29tPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4+DQpDYzogImlkLWV2ZW50QGlldGYub3Jn PG1haWx0bzppZC1ldmVudEBpZXRmLm9yZz4iIDxpZC1ldmVudEBpZXRmLm9yZzxtYWlsdG86aWQt ZXZlbnRAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtJZC1ldmVudF0gRndkOiBOZXcgVmVyc2lv biBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWh1bnQtaWRldmVudC10b2tlbi0wMS50eHQNCg0KSSBh c2tlZCB0aGUgUkZDIGVkaXRvciBhYm91dCBiZXN0IHByYWN0aWNlIGZvciB1c2luZyBVUkksIGJ1 dCBzaGUgZGlkbuKAmXQga25vdyBvZmYgaGFuZC4gIEkgd2lsbCBoYXZlIHRvIGNoZWNrIGludG8g aXQgc29tZSBtb3JlLiAgUGVyaGFwcyB0aGUgb25seSBvcHRpb24gZm9yIFJGQyBpcyB0byB1c2Ug VVJOIGJ1dCB0aGF0IHNlZW1zIGEgYml0IGxpbWl0aW5nLg0KDQpPdGhlciBwZW9wbGUgbGlrZSBX M0MgYW5kIE9JREYgZG9u4oCZdCBzZWVtIHRvIGhhdmUgYSBwcm9ibGVtIHdpdGggVVJJIGZvciBu YW1lc3BhY2VzLg0KDQpKb2huIEIuDQpPbiBBcHIgOCwgMjAxNiwgYXQgMzo1NSBQTSwgUGhpbCBI dW50IDxwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+PiB3 cm90ZToNCg0KSW4gdGhpcyB1cGRhdGUgdG8gZHJhZnQtaHVudC1pZGV2ZW50LXRva2VuLCBXaWxs aWFtIERlbm5pc3MgYW5kIEpvaG4gQnJhZGxleSBwcm9wb3NlZCB0byBnZW5lcmFsaXplIHRoZSBl dmVudCB1cmkgZm9ybWF0IHRvIGJlIGFueSBVUkkgcmF0aGVyIHRoYW4ganVzdCBVUk4uIEFuIGV4 YW1wbGUgd2FzIGFsc28gYWRkZWQgZm9yIE9JREMgTG9nb3V0IChub24tbm9ybWF0aXZlIC0gc2lu Y2UgdGhlIGNvcmUgc3BlYyB3b27igJl0IGhhdmUgbm9ybWF0aXZlIGV2ZW50cyBqdXN0IGV4YW1w bGVzKS4gIFRoYW5rcyBXaWxsaWFtIGZvciByZXZpc2luZyB0aGUgdGV4dC4NCg0KSSB0aGluayB3 ZSBtYXkgaGF2ZSB0byBhZGQgc29tZSB0ZXh0IGFyb3VuZCBldmVudCB0eXBlIFVSSXMuIEZvciBl eGFtcGxlLCBzdWdnZXN0aW5nIHRoYXQgZnJhZ21lbnRzIGNvdWxkIGJlIHVzZSB0byBkaXN0aW5n dWlzaCBpbmRpdmlkdWFsIGV2ZW50cyB0aGF0IG1heSBiZSBzcGVjaWZpZWQgaW4gYSBwYXJlbnQg c3BlY2lmaWNhdGlvbi4gIEUuZy4gU28gd2hpbGUgTG9nb3V0IG1pZ2h0IGRlZmluZSBvbmx5IG9u ZSBldmVudCwgYSBSSVNDIG9yIFNDSU0gZXZlbnRzIHNwZWMgd2lsbCBkZWZpbmUgbWFueS4gIEFs c28sIElFVEYgaGFzIG11bHRpcGxlIHBhdGhzIHRvIGl0cyBSRkNzIGFuZCB0aGUgY2hhbmdlIHRv IG51bWJlcmluZy4gTm90IHN1cmUgd2hhdCB3aWxsIGJlIGJlc3QgZm9yIFNDSU0gZXZlbnRzIGlu IHRoaXMgcmVnYXJkIC0gbWF5YmUgdXNpbmcgdXJu4oCZcyB3b3JrcyBiZXN0IGZvciBJRVRGIHNw ZWNzPyAgR3VpZGFuY2UgZ3JlYXRseSB3ZWxjb21lZCENCg0KUGhpbA0KDQpAaW5kZXBlbmRlbnRp ZA0Kd3d3LmluZGVwZW5kZW50aWQuY29tPGh0dHA6Ly93d3cuaW5kZXBlbmRlbnRpZC5jb20vPg0K cGhpbC5odW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPg0KDQoNCg0K DQoNCkJlZ2luIGZvcndhcmRlZCBtZXNzYWdlOg0KDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0 Zi5vcmc8bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4NClN1YmplY3Q6IE5ldyBWZXJz aW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaHVudC1pZGV2ZW50LXRva2VuLTAxLnR4dA0KRGF0 ZTogQXByaWwgOCwgMjAxNiBhdCAzOjQ2OjI0IFBNIEdNVC0zDQpUbzogIldpbGxpYW0gRGVubmlz cyIgPHdkZW5uaXNzQGdvb2dsZS5jb208bWFpbHRvOndkZW5uaXNzQGdvb2dsZS5jb20+PiwgIlBo aWwgSHVudCIgPHBoaWwuaHVudEB5YWhvby5jb208bWFpbHRvOnBoaWwuaHVudEB5YWhvby5jb20+ PiwgIk1vcnRlemEgQW5zYXJpIiA8bW9ydGV6YS5hbnNhcmlAY2lzY28uY29tPG1haWx0bzptb3J0 ZXphLmFuc2FyaUBjaXNjby5jb20+Pg0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1o dW50LWlkZXZlbnQtdG9rZW4tMDEudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVk IGJ5IFBoaWwgSHVudCBhbmQgcG9zdGVkIHRvIHRoZQ0KSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1l OiBkcmFmdC1odW50LWlkZXZlbnQtdG9rZW4NClJldmlzaW9uOiAwMQ0KVGl0bGU6IElkZW50aXR5 IEV2ZW50IFRva2VuDQpEb2N1bWVudCBkYXRlOiAyMDE2LTA0LTA4DQpHcm91cDogSW5kaXZpZHVh bCBTdWJtaXNzaW9uDQpQYWdlczogMTQNClVSTDogICAgICAgICAgICBodHRwczovL3d3dy5pZXRm Lm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaHVudC1pZGV2ZW50LXRva2VuLTAxLnR4dA0KU3Rh dHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWh1bnQt aWRldmVudC10b2tlbi8NCkh0bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtaHVudC1pZGV2ZW50LXRva2VuLTAxDQpEaWZmOiAgICAgICAgICAgaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWh1bnQtaWRldmVudC10b2tlbi0wMQ0KDQpB YnN0cmFjdDoNCiAgVGhpcyBzcGVjaWZpY2F0aW9uIGRlZmluZXMgYW4gSWRlbnRpdHkgRXZlbnQg dG9rZW4gd2hpY2ggbWF5IGJlDQogIGRpc3RyaWJ1dGVkIHZpYSBhIHByb3RvY29sIHN1Y2ggYXMg SFRUUC4gIEFuIGlkZW50aXR5IGV2ZW50IHRva2VuIGlzDQogIGJhc2VkIG9uIHRoZSBKU09OIFdl YiBUb2tlbiBhbmQgbWF5IGJlIG9wdGlvbmFsbHkgc2lnbmVkIGFuZC9vcg0KICBlbmNyeXB0ZWQu ICBJdCBkZXNjcmliZXMgYSBzdGF0ZW1lbnQgb2YgZmFjdCB0aGF0IG1heSBiZSBzaGFyZWQgYnkg YW4NCiAgZXZlbnQgcHVibGlzaGVyIHdpdGggcmVnaXN0ZXJlZCBzdWJzY3JpYmVycy4NCg0KDQoN Cg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20g dGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRp ZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZzxodHRwOi8vdG9vbHMuaWV0Zi5vcmcv Pi4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KSWQtZXZlbnQgbWFpbGluZyBsaXN0DQpJZC1ldmVudEBp ZXRmLm9yZzxtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50DQoNCg0K --_000_7769D8B35D1F48CDB622AC284CE55B6Einternet2edu_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2PlNlZW1zIGxpa2UgdGhhdCBpcyBhIGRvY3VtZW50IG5hbWVzcGFjaW5nIGlzc3VlIHRoYXQg c2hvdWxkIGJlIHByZXR0eSBzdHJhaWdodGZvcndhcmQgZm9yIElFVEYgdG8gcmVzb2x2ZS4gJm5i c3A7SXMgSGVhdGhlciBhd2FyZSB0aGF0IHRoaXMgaXMgYSBuZWVkPzwvZGl2Pg0KPGRpdj48YnI+ DQo8L2Rpdj4NCjxkaXY+TmljazwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9k aXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0KPGRpdiBzdHlsZT0iZm9udC1m YW1pbHk6Q2FsaWJyaTsgZm9udC1zaXplOjEycHQ7IHRleHQtYWxpZ246bGVmdDsgY29sb3I6Ymxh Y2s7IEJPUkRFUi1CT1RUT006IG1lZGl1bSBub25lOyBCT1JERVItTEVGVDogbWVkaXVtIG5vbmU7 IFBBRERJTkctQk9UVE9NOiAwaW47IFBBRERJTkctTEVGVDogMGluOyBQQURESU5HLVJJR0hUOiAw aW47IEJPUkRFUi1UT1A6ICNiNWM0ZGYgMXB0IHNvbGlkOyBCT1JERVItUklHSFQ6IG1lZGl1bSBu b25lOyBQQURESU5HLVRPUDogM3B0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5G cm9tOiA8L3NwYW4+UGhpbCBIdW50ICZsdDs8YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNs ZS5jb20iPnBoaWwuaHVudEBvcmFjbGUuY29tPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9u dC13ZWlnaHQ6Ym9sZCI+RGF0ZTogPC9zcGFuPkZyaWRheSwgQXByaWwgOCwgMjAxNiBhdCA0OjA0 IFBNPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlRvOiA8L3NwYW4+TmljayBS b3kgJmx0OzxhIGhyZWY9Im1haWx0bzpucm95QGludGVybmV0Mi5lZHUiPm5yb3lAaW50ZXJuZXQy LmVkdTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkNjOiA8L3Nw YW4+Sm9obiBCcmFkbGV5ICZsdDs8YSBocmVmPSJtYWlsdG86dmU3anRiQHZlN2p0Yi5jb20iPnZl N2p0YkB2ZTdqdGIuY29tPC9hPiZndDssICZxdW90OzxhIGhyZWY9Im1haWx0bzppZC1ldmVudEBp ZXRmLm9yZyI+aWQtZXZlbnRAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86 aWQtZXZlbnRAaWV0Zi5vcmciPmlkLWV2ZW50QGlldGYub3JnPC9hPiZndDs8YnI+DQo8c3BhbiBz dHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDogPC9zcGFuPlJlOiBbSWQtZXZlbnRdIEZ3 ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1odW50LWlkZXZlbnQtdG9rZW4t MDEudHh0PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9 IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0 LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+DQpUaGF0IGlzIHdoeSB3 ZSBhcmUgY29uc2lkZXJpbmcgaXQuIEhvd2V2ZXIgaXQgZG9lc27igJl0IHdvcmsgd2VsbCBmb3Ig SUVURiBzaW5jZSB0aGVyZSBhcmUgbXVsdGlwbGUgd2F5cyBvZiByZWZlcmVuY2luZyB0aGUgc2Ft ZSBSRkMuDQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij5UaGlzIHdvdWxkIGxlYWQgdG8gcHJvY2Vzc2luZyBjb21wbGV4aXR5IGFuZCBjb25mdXNpb24g Ynkgc3Vic2NyaWJlcnMgYXMgdGhleSBtaWdodCBub3QgcmVjb2duaXplIHRoZSBkaWZmZXJlbmNl IGJldHdlZW4gc2F5OjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YSBocmVmPSJodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvcmZjNjc0OSIgY2xhc3M9IiI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL3JmYzY3NDk8L2E+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxhIGhyZWY9Imh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvcGRmL3JmYzY3NDkucGRmIiBjbGFzcz0iIj5odHRwczovL3Rvb2xzLmlldGYu b3JnL3BkZi9yZmM2NzQ5LnBkZjwvYT48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGEgaHJlZj0iaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvcmZjNjc0OS8iIGNsYXNzPSIiPmh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL3JmYzY3NDkvPC9hPjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij5hbmQ8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9yZmMvcmZjNjc0OS50eHQiIGNsYXNzPSIiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvcmZjL3Jm YzY3NDkudHh0PC9hPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4N CjxkaXYgY2xhc3M9IiI+U28gd2hpbGUgdGhlIOKAnHR4dOKAnSBpcyBjb25zaWRlcmVkIG5vcm1h dGl2ZSwgeW91IGNhbiBzZWUgd2h5IHNvbWUgZGV2ZWxvcGVycyB3YW50aW5nIHRvIGdlbmVyYXRl IGV2ZW50cyBtaWdodCBiZSBhcyBjb25mdXNlZCBhbmQgc2VuZCBzb21ldGhpbmcgdGhlIHN1YnNj cmliZXIgY2Fu4oCZdCBhdXRvbWF0aWNhbGx5IHJlY29nbml6ZS48L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+PGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2Io MCwgMCwgMCk7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxp Z246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUt c3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10 ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJz cC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNs YXNzPSIiPg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgbGV0dGVyLXNwYWNpbmc6 IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAw cHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1 dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHdv cmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxp bmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxz cGFuIGNsYXNzPSJBcHBsZS1zdHlsZS1zcGFuIiBzdHlsZT0iYm9yZGVyLWNvbGxhcHNlOiBzZXBh cmF0ZTsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgYm9yZGVyLXNwYWNpbmc6IDBweDsiPg0KPGRpdiBj bGFzcz0iIiBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTog c3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7Ij4NCjxkaXYgY2xh c3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5QaGlsPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5AaW5kZXBlbmRlbnRp ZDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YSBocmVmPSJodHRwOi8vd3d3LmluZGVwZW5kZW50aWQu Y29tIiBjbGFzcz0iIj53d3cuaW5kZXBlbmRlbnRpZC5jb208L2E+PC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29t IiBjbGFzcz0iIiBzdHlsZT0ib3JwaGFuczogMjsgd2lkb3dzOiAyOyI+cGhpbC5odW50QG9yYWNs ZS5jb208L2E+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9k aXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPC9kaXY+DQo8YnIg Y2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRl cmNoYW5nZS1uZXdsaW5lIj4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGRpdj4NCjxibG9ja3F1 b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBBcHIgOCwgMjAxNiwg YXQgNjo1MyBQTSwgTmljayBSb3kgJmx0OzxhIGhyZWY9Im1haWx0bzpucm95QGludGVybmV0Mi5l ZHUiIGNsYXNzPSIiPm5yb3lAaW50ZXJuZXQyLmVkdTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJy IGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2 IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsg LXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgZm9udC1zaXplOiAxNHB4OyBm b250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0i Ij4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPlVSSXMgaW4gdGhlIGZvcm0gb2YgVVJM IGhhdmUgdGhlIGFkZGl0aW9uYWwgcG9zc2libGUgYmVuZWZpdCBvZiBob3VzaW5nIGRvY3VtZW50 YXRpb24gYXQgdGhlIFVSTCB1c2VkIGZvciB0aGUgbmFtZXNwYWNlLCB0aGF0IGlzLCB0aGV5IGFy ZSByZXNvbHZhYmxlLjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNs YXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPk5pY2s8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iIGNs YXNzPSIiPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmk7IGZvbnQtc2l6ZTogMTJw dDsgdGV4dC1hbGlnbjogbGVmdDsgYm9yZGVyLXdpZHRoOiAxcHQgbWVkaXVtIG1lZGl1bTsgYm9y ZGVyLXN0eWxlOiBzb2xpZCBub25lIG5vbmU7IHBhZGRpbmc6IDNwdCAwaW4gMGluOyBib3JkZXIt dG9wLWNvbG9yOiByZ2IoMTgxLCAxOTYsIDIyMyk7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJm b250LXdlaWdodDpib2xkIiBjbGFzcz0iIj5Gcm9tOiA8L3NwYW4+SWQtZXZlbnQgJmx0OzxhIGhy ZWY9Im1haWx0bzppZC1ldmVudC1ib3VuY2VzQGlldGYub3JnIiBjbGFzcz0iIj5pZC1ldmVudC1i b3VuY2VzQGlldGYub3JnPC9hPiZndDsgb24gYmVoYWxmIG9mIEpvaG4gQnJhZGxleSAmbHQ7PGEg aHJlZj0ibWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29tIiBjbGFzcz0iIj52ZTdqdGJAdmU3anRiLmNv bTwvYT4mZ3Q7PGJyIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiIGNs YXNzPSIiPkRhdGU6IDwvc3Bhbj5GcmlkYXksIEFwcmlsIDgsIDIwMTYgYXQgMzo0MyBQTTxiciBj bGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIiBjbGFzcz0iIj5UbzogPC9z cGFuPlBoaWwgSHVudCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIiBj bGFzcz0iIj5waGlsLmh1bnRAb3JhY2xlLmNvbTwvYT4mZ3Q7PGJyIGNsYXNzPSIiPg0KPHNwYW4g c3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiIGNsYXNzPSIiPkNjOiA8L3NwYW4+JnF1b3Q7PGEgaHJl Zj0ibWFpbHRvOmlkLWV2ZW50QGlldGYub3JnIiBjbGFzcz0iIj5pZC1ldmVudEBpZXRmLm9yZzwv YT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzppZC1ldmVudEBpZXRmLm9yZyIgY2xhc3M9IiI+ aWQtZXZlbnRAaWV0Zi5vcmc8L2E+Jmd0OzxiciBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250 LXdlaWdodDpib2xkIiBjbGFzcz0iIj5TdWJqZWN0OiA8L3NwYW4+UmU6IFtJZC1ldmVudF0gRndk OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWh1bnQtaWRldmVudC10b2tlbi0w MS50eHQ8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0K PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3Jk OyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hp dGUtc3BhY2U7IiBjbGFzcz0iIj4NCkkgYXNrZWQgdGhlIFJGQyBlZGl0b3IgYWJvdXQgYmVzdCBw cmFjdGljZSBmb3IgdXNpbmcgVVJJLCBidXQgc2hlIGRpZG7igJl0IGtub3cgb2ZmIGhhbmQuICZu YnNwO0kgd2lsbCBoYXZlIHRvIGNoZWNrIGludG8gaXQgc29tZSBtb3JlLiAmbmJzcDtQZXJoYXBz IHRoZSBvbmx5IG9wdGlvbiBmb3IgUkZDIGlzIHRvIHVzZSBVUk4gYnV0IHRoYXQgc2VlbXMgYSBi aXQgbGltaXRpbmcuDQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj5PdGhlciBwZW9wbGUgbGlrZSBXM0MgYW5kIE9JREYgZG9u4oCZdCBzZWVtIHRvIGhh dmUgYSBwcm9ibGVtIHdpdGggVVJJIGZvciBuYW1lc3BhY2VzLjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Sm9obiBCLjxiciBjbGFzcz0i Ij4NCjxkaXYgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxk aXYgY2xhc3M9IiI+T24gQXByIDgsIDIwMTYsIGF0IDM6NTUgUE0sIFBoaWwgSHVudCAmbHQ7PGEg aHJlZj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIiBjbGFzcz0iIj5waGlsLmh1bnRAb3Jh Y2xlLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5n ZS1uZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFr LXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRl ci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSW4gdGhpcyB1cGRhdGUgdG8gZHJhZnQtaHVudC1p ZGV2ZW50LXRva2VuLCBXaWxsaWFtIERlbm5pc3MgYW5kIEpvaG4gQnJhZGxleSBwcm9wb3NlZCB0 byBnZW5lcmFsaXplIHRoZSBldmVudCB1cmkgZm9ybWF0IHRvIGJlIGFueSBVUkkgcmF0aGVyIHRo YW4ganVzdCBVUk4uIEFuIGV4YW1wbGUgd2FzIGFsc28gYWRkZWQgZm9yIE9JREMgTG9nb3V0IChu b24tbm9ybWF0aXZlIC0gc2luY2UgdGhlIGNvcmUgc3BlYyB3b27igJl0IGhhdmUgbm9ybWF0aXZl DQogZXZlbnRzIGp1c3QgZXhhbXBsZXMpLiAmbmJzcDtUaGFua3MgV2lsbGlhbSBmb3IgcmV2aXNp bmcgdGhlIHRleHQuDQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj5JIHRoaW5rIHdlIG1heSBoYXZlIHRvIGFkZCBzb21lIHRleHQgYXJvdW5kIGV2ZW50 IHR5cGUgVVJJcy4gRm9yIGV4YW1wbGUsIHN1Z2dlc3RpbmcgdGhhdCBmcmFnbWVudHMgY291bGQg YmUgdXNlIHRvIGRpc3Rpbmd1aXNoIGluZGl2aWR1YWwgZXZlbnRzIHRoYXQgbWF5IGJlIHNwZWNp ZmllZCBpbiBhIHBhcmVudCBzcGVjaWZpY2F0aW9uLiAmbmJzcDtFLmcuIFNvIHdoaWxlIExvZ291 dCBtaWdodCBkZWZpbmUgb25seSBvbmUgZXZlbnQsDQogYSBSSVNDIG9yIFNDSU0gZXZlbnRzIHNw ZWMgd2lsbCBkZWZpbmUgbWFueS4gJm5ic3A7QWxzbywgSUVURiBoYXMgbXVsdGlwbGUgcGF0aHMg dG8gaXRzIFJGQ3MgYW5kIHRoZSBjaGFuZ2UgdG8gbnVtYmVyaW5nLiBOb3Qgc3VyZSB3aGF0IHdp bGwgYmUgYmVzdCBmb3IgU0NJTSBldmVudHMgaW4gdGhpcyByZWdhcmQgLSBtYXliZSB1c2luZyB1 cm7igJlzIHdvcmtzIGJlc3QgZm9yIElFVEYgc3BlY3M/ICZuYnNwO0d1aWRhbmNlIGdyZWF0bHkg d2VsY29tZWQhPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRp diBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0i bGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7 IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9y bWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tl LXdpZHRoOiAwcHg7IHdvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNw YWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+DQo8 ZGl2IHN0eWxlPSJsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFs aWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRl LXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQt dGV4dC1zdHJva2Utd2lkdGg6IDBweDsgd29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5i c3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBj bGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+PHNwYW4gY2xhc3M9IkFwcGxlLXN0eWxlLXNwYW4iIHN0 eWxlPSJib3JkZXItY29sbGFwc2U6IHNlcGFyYXRlOyBsaW5lLWhlaWdodDogbm9ybWFsOyBib3Jk ZXItc3BhY2luZzogMHB4OyI+DQo8ZGl2IGNsYXNzPSIiIHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFr LXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRl ci13aGl0ZS1zcGFjZTsiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNs YXNzPSIiPlBoaWw8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPkBpbmRlcGVuZGVudGlkPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxhIGhyZWY9 Imh0dHA6Ly93d3cuaW5kZXBlbmRlbnRpZC5jb20vIiBjbGFzcz0iIj53d3cuaW5kZXBlbmRlbnRp ZC5jb208L2E+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L3NwYW4+PGEgaHJlZj0i bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIiBjbGFzcz0iIiBzdHlsZT0ib3JwaGFuczogMjsg d2lkb3dzOiAyOyI+cGhpbC5odW50QG9yYWNsZS5jb208L2E+PC9kaXY+DQo8ZGl2IGNsYXNzPSIi PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hh bmdlLW5ld2xpbmUiPg0KPC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xp bmUiPg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjwvZGl2Pg0KPGRp diBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0i Ij4NCjxkaXYgY2xhc3M9IiI+QmVnaW4gZm9yd2FyZGVkIG1lc3NhZ2U6PC9kaXY+DQo8YnIgY2xh c3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBzdHlsZT0ibWFyZ2luLXRvcDog MHB4OyBtYXJnaW4tcmlnaHQ6IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4OyBtYXJnaW4tbGVmdDog MHB4OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IC13ZWJraXQtc3lzdGVt LWZvbnQsICdIZWx2ZXRpY2EgTmV1ZScsIEhlbHZldGljYSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIi PjxiIGNsYXNzPSIiPkZyb206DQo8L2I+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTog LXdlYmtpdC1zeXN0ZW0tZm9udCwgSGVsdmV0aWNhIE5ldWUsIEhlbHZldGljYSwgc2Fucy1zZXJp ZjsiIGNsYXNzPSIiPjxhIGhyZWY9Im1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciIGNs YXNzPSIiPmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+DQo8L3NwYW4+ PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1yaWdodDogMHB4OyBt YXJnaW4tYm90dG9tOiAwcHg7IG1hcmdpbi1sZWZ0OiAwcHg7IiBjbGFzcz0iIj4NCjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTogLXdlYmtpdC1zeXN0ZW0tZm9udCwgJ0hlbHZldGljYSBOZXVlJywg SGVsdmV0aWNhLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+PGIgY2xhc3M9IiI+U3ViamVjdDoNCjwv Yj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiAtd2Via2l0LXN5c3RlbS1mb250LCBI ZWx2ZXRpY2EgTmV1ZSwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+PGIgY2xhc3M9 IiI+TmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1odW50LWlkZXZlbnQtdG9rZW4t MDEudHh0PC9iPjxiciBjbGFzcz0iIj4NCjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdp bi10b3A6IDBweDsgbWFyZ2luLXJpZ2h0OiAwcHg7IG1hcmdpbi1ib3R0b206IDBweDsgbWFyZ2lu LWxlZnQ6IDBweDsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiAtd2Via2l0 LXN5c3RlbS1mb250LCAnSGVsdmV0aWNhIE5ldWUnLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IiBj bGFzcz0iIj48YiBjbGFzcz0iIj5EYXRlOg0KPC9iPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6IC13ZWJraXQtc3lzdGVtLWZvbnQsIEhlbHZldGljYSBOZXVlLCBIZWx2ZXRpY2EsIHNh bnMtc2VyaWY7IiBjbGFzcz0iIj5BcHJpbCA4LCAyMDE2IGF0IDM6NDY6MjQgUE0gR01ULTM8YnIg Y2xhc3M9IiI+DQo8L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tdG9wOiAwcHg7IG1h cmdpbi1yaWdodDogMHB4OyBtYXJnaW4tYm90dG9tOiAwcHg7IG1hcmdpbi1sZWZ0OiAwcHg7IiBj bGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogLXdlYmtpdC1zeXN0ZW0tZm9udCwg J0hlbHZldGljYSBOZXVlJywgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+PGIgY2xh c3M9IiI+VG86DQo8L2I+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogLXdlYmtpdC1z eXN0ZW0tZm9udCwgSGVsdmV0aWNhIE5ldWUsIEhlbHZldGljYSwgc2Fucy1zZXJpZjsiIGNsYXNz PSIiPiZxdW90O1dpbGxpYW0gRGVubmlzcyZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOndkZW5u aXNzQGdvb2dsZS5jb20iIGNsYXNzPSIiPndkZW5uaXNzQGdvb2dsZS5jb208L2E+Jmd0OywgJnF1 b3Q7UGhpbCBIdW50JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86cGhpbC5odW50QHlhaG9vLmNv bSIgY2xhc3M9IiI+cGhpbC5odW50QHlhaG9vLmNvbTwvYT4mZ3Q7LA0KICZxdW90O01vcnRlemEg QW5zYXJpJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bW9ydGV6YS5hbnNhcmlAY2lzY28uY29t IiBjbGFzcz0iIj5tb3J0ZXphLmFuc2FyaUBjaXNjby5jb208L2E+Jmd0OzxiciBjbGFzcz0iIj4N Cjwvc3Bhbj48L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNz PSIiPjxiciBjbGFzcz0iIj4NCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1odW50LWlkZXZl bnQtdG9rZW4tMDEudHh0PGJyIGNsYXNzPSIiPg0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1p dHRlZCBieSBQaGlsIEh1bnQgYW5kIHBvc3RlZCB0byB0aGU8YnIgY2xhc3M9IiI+DQpJRVRGIHJl cG9zaXRvcnkuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KTmFtZTo8c3BhbiBjbGFzcz0i QXBwbGUtdGFiLXNwYW4iIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUiPiA8L3NwYW4+PHNwYW4gY2xh c3M9IkFwcGxlLXRhYi1zcGFuIiBzdHlsZT0id2hpdGUtc3BhY2U6cHJlIj48L3NwYW4+ZHJhZnQt aHVudC1pZGV2ZW50LXRva2VuPGJyIGNsYXNzPSIiPg0KUmV2aXNpb246PHNwYW4gY2xhc3M9IkFw cGxlLXRhYi1zcGFuIiBzdHlsZT0id2hpdGUtc3BhY2U6cHJlIj4gPC9zcGFuPjAxPGJyIGNsYXNz PSIiPg0KVGl0bGU6PHNwYW4gY2xhc3M9IkFwcGxlLXRhYi1zcGFuIiBzdHlsZT0id2hpdGUtc3Bh Y2U6cHJlIj4gPC9zcGFuPjxzcGFuIGNsYXNzPSJBcHBsZS10YWItc3BhbiIgc3R5bGU9IndoaXRl LXNwYWNlOnByZSI+PC9zcGFuPklkZW50aXR5IEV2ZW50IFRva2VuPGJyIGNsYXNzPSIiPg0KRG9j dW1lbnQgZGF0ZTo8c3BhbiBjbGFzcz0iQXBwbGUtdGFiLXNwYW4iIHN0eWxlPSJ3aGl0ZS1zcGFj ZTpwcmUiPiA8L3NwYW4+MjAxNi0wNC0wODxiciBjbGFzcz0iIj4NCkdyb3VwOjxzcGFuIGNsYXNz PSJBcHBsZS10YWItc3BhbiIgc3R5bGU9IndoaXRlLXNwYWNlOnByZSI+IDwvc3Bhbj48c3BhbiBj bGFzcz0iQXBwbGUtdGFiLXNwYW4iIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUiPjwvc3Bhbj5JbmRp dmlkdWFsIFN1Ym1pc3Npb248YnIgY2xhc3M9IiI+DQpQYWdlczo8c3BhbiBjbGFzcz0iQXBwbGUt dGFiLXNwYW4iIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUiPiA8L3NwYW4+PHNwYW4gY2xhc3M9IkFw cGxlLXRhYi1zcGFuIiBzdHlsZT0id2hpdGUtc3BhY2U6cHJlIj48L3NwYW4+MTQ8YnIgY2xhc3M9 IiI+DQpVUkw6ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0 LWRyYWZ0cy9kcmFmdC1odW50LWlkZXZlbnQtdG9rZW4tMDEudHh0IiBjbGFzcz0iIj5odHRwczov L3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaHVudC1pZGV2ZW50LXRva2VuLTAx LnR4dDwvYT48YnIgY2xhc3M9IiI+DQpTdGF0dXM6ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWh1bnQtaWRldmVudC10b2tlbi8iIGNsYXNzPSIiPmh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWh1bnQtaWRldmVudC10b2tlbi88L2E+PGJyIGNsYXNz PSIiPg0KSHRtbGl6ZWQ6ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhy ZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1odW50LWlkZXZlbnQtdG9rZW4t MDEiIGNsYXNzPSIiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1odW50LWlkZXZl bnQtdG9rZW4tMDE8L2E+PGJyIGNsYXNzPSIiPg0KRGlmZjogJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWh1bnQtaWRldmVudC10b2tlbi0wMSIgY2xh c3M9IiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWh1bnQtaWRldmVu dC10b2tlbi0wMTwvYT48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpBYnN0cmFjdDo8YnIg Y2xhc3M9IiI+DQombmJzcDsmbmJzcDtUaGlzIHNwZWNpZmljYXRpb24gZGVmaW5lcyBhbiBJZGVu dGl0eSBFdmVudCB0b2tlbiB3aGljaCBtYXkgYmU8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDtk aXN0cmlidXRlZCB2aWEgYSBwcm90b2NvbCBzdWNoIGFzIEhUVFAuICZuYnNwO0FuIGlkZW50aXR5 IGV2ZW50IHRva2VuIGlzPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7YmFzZWQgb24gdGhlIEpT T04gV2ViIFRva2VuIGFuZCBtYXkgYmUgb3B0aW9uYWxseSBzaWduZWQgYW5kL29yPGJyIGNsYXNz PSIiPg0KJm5ic3A7Jm5ic3A7ZW5jcnlwdGVkLiAmbmJzcDtJdCBkZXNjcmliZXMgYSBzdGF0ZW1l bnQgb2YgZmFjdCB0aGF0IG1heSBiZSBzaGFyZWQgYnkgYW48YnIgY2xhc3M9IiI+DQombmJzcDsm bmJzcDtldmVudCBwdWJsaXNoZXIgd2l0aCByZWdpc3RlcmVkIHN1YnNjcmliZXJzLjxiciBjbGFz cz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBj bGFzcz0iIj4NClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRl cyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb248YnIgY2xhc3M9IiI+DQp1bnRpbCB0aGUgaHRt bGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IDxhIGhyZWY9Imh0dHA6Ly90 b29scy5pZXRmLm9yZy8iIGNsYXNzPSIiPg0KdG9vbHMuaWV0Zi5vcmc8L2E+LjxiciBjbGFzcz0i Ij4NCjxiciBjbGFzcz0iIj4NClRoZSBJRVRGIFNlY3JldGFyaWF0PGJyIGNsYXNzPSIiPg0KPGJy IGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNs YXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188YnIgY2xhc3M9IiI+DQpJZC1ldmVudCBtYWlsaW5nIGxp c3Q8YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmciIGNsYXNz PSIiPklkLWV2ZW50QGlldGYub3JnPC9hPjxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Imh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWQtZXZlbnQiIGNsYXNzPSIiPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWQtZXZlbnQ8L2E+PGJyIGNsYXNzPSIiPg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+ DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L3NwYW4+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_7769D8B35D1F48CDB622AC284CE55B6Einternet2edu_-- From nobody Fri Apr 8 16:06:34 2016 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D600112D658 for ; Fri, 8 Apr 2016 16:06:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.com 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 TXvde-gxMg7E for ; Fri, 8 Apr 2016 16:06:30 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (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 A939E12D5E7 for ; Fri, 8 Apr 2016 16:06:30 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id d68so151630028ywe.1 for ; Fri, 08 Apr 2016 16:06:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=Ni3Xw0bYGtB5gF1LSx/XminCutdcSQ56sW3SNbwvksM=; b=KLdd3ueXHHhhEkCYauzsAiSNq9eaKeurG4xt68LZAs7vyDJ5IUwZmFCF1m6t2P2o/g tccpAXZVBctJQeJndfSkzB/T4IeJz1e7LuEM911IPAxrhhc4xoDtBgn5OipbxypI2lsj 2qV0hsNAWlSzRQ13RbGSZi5G2TlEDQ+hpr3DLyIIKcjdLsm+cx5WN1lWQGiYAxts1cxp dJlDR6evPvZ1plvMwJgSRO3fpHPwfQcEjFqN7T1QfZ5J1xcfzNPbFjws4nsv+3Ix5sIq mtqiitzwTMEYbuC3+lQRkXdh7N92iSFh+CAvKB2wsaOamM/GFpT//m1qXGoIbKtgJVZI MJ1A== 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; bh=Ni3Xw0bYGtB5gF1LSx/XminCutdcSQ56sW3SNbwvksM=; b=Pf/M//GdwO3Wv6fIc7CtpF1ip9Nx4UbORMqiINC+c0KWgyjjzWFnXDR3DCfOMVzWcB v1X7QLjO2PfsGNELhSYVNXy8Z+kxX6htSE12nZ9o0xER8Y2U4XLLD1t+wtXGFWEgIf8/ OQX0iTbQNXu3OFcU7hLVSy091i4+dbfY9ZlJ+lsQUIysqQ3SiXdmDAi4uiYywBAClQmq j/mDHAACoc0HoMmv28DTUsvjG2CBW7yXjunjyXh10jaO84hijK/6Dzqrck+QVk9Gbmdl gS92Yz29Po2lYWJFdp+dd6gCQRU1Hb0RAOxSZ3FBzftdUbaTM7P5JEcRhDgXixMiHPe1 Ebow== X-Gm-Message-State: AD7BkJJEt1hluCL2tUxKhqiFyk+EVkYvmZSLisFKOafI51KgpR5+H6/zuY2I4kLoFewL/dpLFOe3fKdn1tL9mA== MIME-Version: 1.0 X-Received: by 10.37.230.211 with SMTP id d202mr5600904ybh.26.1460156789689; Fri, 08 Apr 2016 16:06:29 -0700 (PDT) Received: by 10.37.207.6 with HTTP; Fri, 8 Apr 2016 16:06:28 -0700 (PDT) Received: by 10.37.207.6 with HTTP; Fri, 8 Apr 2016 16:06:28 -0700 (PDT) In-Reply-To: <5E203F9A-46F8-452B-891F-E1B5830C09E2@oracle.com> References: <20160408184624.23058.51335.idtracker@ietfa.amsl.com> <5E203F9A-46F8-452B-891F-E1B5830C09E2@oracle.com> Date: Fri, 8 Apr 2016 20:06:28 -0300 Message-ID: From: John Bradley To: Phil Hunt Content-Type: multipart/alternative; boundary=94eb2c0a7a3cc46b740530013ebd Archived-At: Cc: Nick Roy , id-event@ietf.org Subject: Re: [Id-event] Fwd: New Version Notification for draft-hunt-idevent-token-01.txt X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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: Fri, 08 Apr 2016 23:06:34 -0000 --94eb2c0a7a3cc46b740530013ebd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The spec needs to say what the URI is. The problem is you don't know the name of the spec untill it is done. There must be a way to do it. We just need to find the person who knows. There is a expired ID on the topic. On Apr 8, 2016 7:04 PM, "Phil Hunt" wrote: > That is why we are considering it. However it doesn=E2=80=99t work well f= or IETF > since there are multiple ways of referencing the same RFC. > > This would lead to processing complexity and confusion by subscribers as > they might not recognize the difference between say: > https://tools.ietf.org/html/rfc6749 > https://tools.ietf.org/pdf/rfc6749.pdf > https://datatracker.ietf.org/doc/rfc6749/ > and > https://tools.ietf.org/rfc/rfc6749.txt > > So while the =E2=80=9Ctxt=E2=80=9D is considered normative, you can see w= hy some > developers wanting to generate events might be as confused and send > something the subscriber can=E2=80=99t automatically recognize. > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > > On Apr 8, 2016, at 6:53 PM, Nick Roy wrote: > > URIs in the form of URL have the additional possible benefit of housing > documentation at the URL used for the namespace, that is, they are > resolvable. > > Nick > > From: Id-event on behalf of John Bradley < > ve7jtb@ve7jtb.com> > Date: Friday, April 8, 2016 at 3:43 PM > To: Phil Hunt > Cc: "id-event@ietf.org" > Subject: Re: [Id-event] Fwd: New Version Notification for > draft-hunt-idevent-token-01.txt > > I asked the RFC editor about best practice for using URI, but she didn=E2= =80=99t > know off hand. I will have to check into it some more. Perhaps the only > option for RFC is to use URN but that seems a bit limiting. > > Other people like W3C and OIDF don=E2=80=99t seem to have a problem with = URI for > namespaces. > > John B. > > On Apr 8, 2016, at 3:55 PM, Phil Hunt wrote: > > In this update to draft-hunt-idevent-token, William Denniss and John > Bradley proposed to generalize the event uri format to be any URI rather > than just URN. An example was also added for OIDC Logout (non-normative - > since the core spec won=E2=80=99t have normative events just examples). = Thanks > William for revising the text. > > I think we may have to add some text around event type URIs. For example, > suggesting that fragments could be use to distinguish individual events > that may be specified in a parent specification. E.g. So while Logout > might define only one event, a RISC or SCIM events spec will define many. > Also, IETF has multiple paths to its RFCs and the change to numbering. No= t > sure what will be best for SCIM events in this regard - maybe using urn= =E2=80=99s > works best for IETF specs? Guidance greatly welcomed! > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > > Begin forwarded message: > > *From: *internet-drafts@ietf.org > *Subject: **New Version Notification for draft-hunt-idevent-token-01.txt* > *Date: *April 8, 2016 at 3:46:24 PM GMT-3 > *To: *"William Denniss" , "Phil Hunt" < > phil.hunt@yahoo.com>, "Morteza Ansari" > > > A new version of I-D, draft-hunt-idevent-token-01.txt > has been successfully submitted by Phil Hunt and posted to the > IETF repository. > > Name: draft-hunt-idevent-token > Revision: 01 > Title: Identity Event Token > Document date: 2016-04-08 > Group: Individual Submission > Pages: 14 > URL: > https://www.ietf.org/internet-drafts/draft-hunt-idevent-token-01.txt > Status: https://datatracker.ietf.org/doc/draft-hunt-idevent-token= / > Htmlized: https://tools.ietf.org/html/draft-hunt-idevent-token-01 > Diff: > https://www.ietf.org/rfcdiff?url2=3Ddraft-hunt-idevent-token-01 > > Abstract: > This specification defines an Identity Event token which may be > distributed via a protocol such as HTTP. An identity event token is > based on the JSON Web Token and may be optionally signed and/or > encrypted. It describes a statement of fact that may be shared by an > event publisher with registered subscribers. > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > > > --94eb2c0a7a3cc46b740530013ebd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

The spec needs to say what the URI is.=C2=A0 The problem is = you don't know the name of the spec untill it is done.=C2=A0

There must be a way to do it.=C2=A0 We just need to find the= person who knows.=C2=A0 There is a expired ID on the topic.

On Apr 8, 2016 7:04 PM, "Phil Hunt" &l= t;phil.hunt@oracle.com> wrot= e:
That is why we are considering it. However it doesn=E2= =80=99t work well for IETF since there are multiple ways of referencing the= same RFC.

This would lead to processing complexity and = confusion by subscribers as they might not recognize the difference between= say:
https://datatracker.ietf.org/doc/rfc6749/
and

So while the =E2=80=9Ctxt=E2=80=9D is considered normative, you can= see why some developers wanting to generate events might be as confused an= d send something the subscriber can=E2=80=99t automatically recognize.


On Apr 8, 2016, at 6:53 PM, Nick Ro= y <nroy@internet= 2.edu> wrote:

URIs in the form of URL have the additional possible benefit of housin= g documentation at the URL used for the namespace, that is, they are resolv= able.

Nick

From: Id-event <id-event-bounces@ietf.org> on behalf of John Bradley <ve7jtb@ve7jtb.com>
Date: Friday, April 8, 2016 at 3:43= PM
To: Phil Hunt <phil.hunt@oracle.com>
Cc: "id-event@ietf.org" <id-event@ietf.org>
Subject: Re: [Id-event] Fwd: New Ve= rsion Notification for draft-hunt-idevent-token-01.txt

I asked the RFC editor about best practice for using URI, but she didn=E2= =80=99t know off hand.=C2=A0 I will have to check into it some more.=C2=A0 = Perhaps the only option for RFC is to use URN but that seems a bit limiting= .

Other people like W3C and OIDF don=E2=80=99t seem to have a problem wi= th URI for namespaces.

John B.
On Apr 8, 2016, at 3:55 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

In this update to draft-hunt-idevent-token, William Denniss and John Bradle= y proposed to generalize the event uri format to be any URI rather than jus= t URN. An example was also added for OIDC Logout (non-normative - since the= core spec won=E2=80=99t have normative events just examples).=C2=A0 Thanks William for revising the text.

I think we may have to add some text around event type URIs. For examp= le, suggesting that fragments could be use to distinguish individual events= that may be specified in a parent specification.=C2=A0 E.g. So while Logou= t might define only one event, a RISC or SCIM events spec will define many.=C2=A0 Also, IETF has multiple= paths to its RFCs and the change to numbering. Not sure what will be best = for SCIM events in this regard - maybe using urn=E2=80=99s works best for I= ETF specs?=C2=A0 Guidance greatly welcomed!


Begin forwarded message:

Subject: New Version Notification for draft-hunt-idevent-toke= n-01.txt
Date: April 8, 2016 at 3:46:24 PM GMT-3
To: "William Denniss" <wdenniss@google.com>, "Phil H= unt" <phil= .hunt@yahoo.com>, "Morteza Ansari" <morteza.ansari@cisco.com>


A new version of I-D, draft-hunt-idevent-token-01.txt
has been successfully submitted by Phil Hunt and posted to the
IETF repository.

Name: draft-hunt-idevent-token
Revision: 01
Title: Identity Event Token
Document date: 2016-04-08
Group: Individual Submission
Pages: 14
URL: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://www.ietf.org/internet-drafts/draft-hunt-idevent= -token-01.txt
Status: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https= ://datatracker.ietf.org/doc/draft-hunt-idevent-token/
Htmlized: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://tools.ietf= .org/html/draft-hunt-idevent-token-01
Diff: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-hunt-idevent-token-01=

Abstract:
=C2=A0=C2=A0This specification defines an Identity Event token which may be=
=C2=A0=C2=A0distributed via a protocol such as HTTP.=C2=A0 An identity even= t token is
=C2=A0=C2=A0based on the JSON Web Token and may be optionally signed and/or=
=C2=A0=C2=A0encrypted.=C2=A0 It describes a statement of fact that may be s= hared by an
=C2=A0=C2=A0event publisher with registered subscribers.




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

The IETF Secretariat


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

--94eb2c0a7a3cc46b740530013ebd-- From nobody Fri Apr 8 18:54:29 2016 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C45A212D0E9 for ; Fri, 8 Apr 2016 18:54:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=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 tBer-cFB7rUs for ; Fri, 8 Apr 2016 18:54:25 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (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 B16B912D0BA for ; Fri, 8 Apr 2016 18:54:24 -0700 (PDT) Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u391sLmm026231 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 9 Apr 2016 01:54:22 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u391sLPQ002184 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 9 Apr 2016 01:54:21 GMT Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id u391sKZA028417; Sat, 9 Apr 2016 01:54:20 GMT Received: from [25.23.208.186] (/24.114.56.185) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 08 Apr 2016 18:54:19 -0700 Content-Type: multipart/alternative; boundary=Apple-Mail-8DB0FCBB-3CC8-465B-94D6-F2DC659336B5 Mime-Version: 1.0 (1.0) From: "Phil Hunt (IDM)" X-Mailer: iPhone Mail (13E238) In-Reply-To: Date: Fri, 8 Apr 2016 22:54:04 -0300 Content-Transfer-Encoding: 7bit Message-Id: <889C5E37-F65F-40AF-9621-D78C5C578435@oracle.com> References: <20160408184624.23058.51335.idtracker@ietfa.amsl.com> <5E203F9A-46F8-452B-891F-E1B5830C09E2@oracle.com> To: John Bradley X-Source-IP: aserv0021.oracle.com [141.146.126.233] Archived-At: Cc: Nick Roy , id-event@ietf.org Subject: Re: [Id-event] Fwd: New Version Notification for draft-hunt-idevent-token-01.txt X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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: Sat, 09 Apr 2016 01:54:27 -0000 --Apple-Mail-8DB0FCBB-3CC8-465B-94D6-F2DC659336B5 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I think I know a way.=20 Phil > On Apr 8, 2016, at 20:06, John Bradley wrote: >=20 > The spec needs to say what the URI is. The problem is you don't know the n= ame of the spec untill it is done.=20 >=20 > There must be a way to do it. We just need to find the person who knows. = There is a expired ID on the topic.=20 >> On Apr 8, 2016 7:04 PM, "Phil Hunt" wrote: >> That is why we are considering it. However it doesn=E2=80=99t work well f= or IETF since there are multiple ways of referencing the same RFC. >>=20 >> This would lead to processing complexity and confusion by subscribers as t= hey might not recognize the difference between say: >> https://tools.ietf.org/html/rfc6749 >> https://tools.ietf.org/pdf/rfc6749.pdf >> https://datatracker.ietf.org/doc/rfc6749/ >> and >> https://tools.ietf.org/rfc/rfc6749.txt >>=20 >> So while the =E2=80=9Ctxt=E2=80=9D is considered normative, you can see w= hy some developers wanting to generate events might be as confused and send s= omething the subscriber can=E2=80=99t automatically recognize. >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >>=20 >>=20 >>> On Apr 8, 2016, at 6:53 PM, Nick Roy wrote: >>>=20 >>> URIs in the form of URL have the additional possible benefit of housing d= ocumentation at the URL used for the namespace, that is, they are resolvable= . >>>=20 >>> Nick >>>=20 >>> From: Id-event on behalf of John Bradley >>> Date: Friday, April 8, 2016 at 3:43 PM >>> To: Phil Hunt >>> Cc: "id-event@ietf.org" >>> Subject: Re: [Id-event] Fwd: New Version Notification for draft-hunt-ide= vent-token-01.txt >>>=20 >>> I asked the RFC editor about best practice for using URI, but she didn=E2= =80=99t know off hand. I will have to check into it some more. Perhaps the= only option for RFC is to use URN but that seems a bit limiting. >>>=20 >>> Other people like W3C and OIDF don=E2=80=99t seem to have a problem with= URI for namespaces. >>>=20 >>> John B. >>>> On Apr 8, 2016, at 3:55 PM, Phil Hunt wrote: >>>>=20 >>>> In this update to draft-hunt-idevent-token, William Denniss and John Br= adley proposed to generalize the event uri format to be any URI rather than j= ust URN. An example was also added for OIDC Logout (non-normative - since th= e core spec won=E2=80=99t have normative events just examples). Thanks Will= iam for revising the text. >>>>=20 >>>> I think we may have to add some text around event type URIs. For exampl= e, suggesting that fragments could be use to distinguish individual events t= hat may be specified in a parent specification. E.g. So while Logout might d= efine only one event, a RISC or SCIM events spec will define many. Also, IE= TF has multiple paths to its RFCs and the change to numbering. Not sure what= will be best for SCIM events in this regard - maybe using urn=E2=80=99s wor= ks best for IETF specs? Guidance greatly welcomed! >>>>=20 >>>> Phil >>>>=20 >>>> @independentid >>>> www.independentid.com >>>> phil.hunt@oracle.com >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>> Begin forwarded message: >>>>>=20 >>>>> From: internet-drafts@ietf.org >>>>> Subject: New Version Notification for draft-hunt-idevent-token-01.txt >>>>> Date: April 8, 2016 at 3:46:24 PM GMT-3 >>>>> To: "William Denniss" , "Phil Hunt" , "Morteza Ansari" >>>>>=20 >>>>>=20 >>>>> A new version of I-D, draft-hunt-idevent-token-01.txt >>>>> has been successfully submitted by Phil Hunt and posted to the >>>>> IETF repository. >>>>>=20 >>>>> Name: draft-hunt-idevent-token >>>>> Revision: 01 >>>>> Title: Identity Event Token >>>>> Document date: 2016-04-08 >>>>> Group: Individual Submission >>>>> Pages: 14 >>>>> URL: https://www.ietf.org/internet-drafts/draft-hunt-ideven= t-token-01.txt >>>>> Status: https://datatracker.ietf.org/doc/draft-hunt-idevent-to= ken/ >>>>> Htmlized: https://tools.ietf.org/html/draft-hunt-idevent-token-0= 1 >>>>> Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-hunt-idevent= -token-01 >>>>>=20 >>>>> Abstract: >>>>> This specification defines an Identity Event token which may be >>>>> distributed via a protocol such as HTTP. An identity event token is= >>>>> based on the JSON Web Token and may be optionally signed and/or >>>>> encrypted. It describes a statement of fact that may be shared by a= n >>>>> event publisher with registered subscribers. >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Please note that it may take a couple of minutes from the time of subm= ission >>>>> until the htmlized version and diff are available at tools.ietf.org. >>>>>=20 >>>>> The IETF Secretariat >>>>=20 >>>> _______________________________________________ >>>> 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-8DB0FCBB-3CC8-465B-94D6-F2DC659336B5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I think I know a way. 

Phil

On Apr 8, 2016, at 20:06, Jo= hn Bradley <ve7jtb@ve7jtb.com>= ; wrote:

The spec= needs to say what the URI is.  The problem is you don't know the name o= f the spec untill it is done. 

There must be a way to do it.  We just need to find the p= erson who knows.  There is a expired ID on the topic.

On Apr 8, 2016 7:04 PM, "Phil Hunt" <phil.hunt@oracle.com> wrote:
That is why we are considering it. However it doesn=E2=80=99t work well f= or IETF since there are multiple ways of referencing the same RFC.

<= /div>
This would lead to processing complexity and confusion by subscrib= ers as they might not recognize the difference between say:
<= div>= https://datatracker.ietf.org/doc/rfc6749/
and

So while the =E2=80=9C= txt=E2=80=9D is considered normative, you can see why some developers wantin= g to generate events might be as confused and send something the subscriber c= an=E2=80=99t automatically recognize.

On Apr 8, 2016, at 6:53 PM, Nick Roy= <nroy@internet2.= edu> wrote:

URIs in the form of URL have the additional possible benefit of housing= documentation at the URL used for the namespace, that is, they are resolvab= le.

Nick

From: Id-event <id-event-bounces@ietf.org&= gt; on behalf of John Bradley <ve7jtb@ve7jtb.com>
Date: Friday, April 8, 2016 at 3:43 P= M
To: Phil Hunt <phil.hunt@oracle.com>
Cc: "id-event@ietf.org" <id-event@ietf.org>
Subject: Re: [Id-event] Fwd: New Ver= sion Notification for draft-hunt-idevent-token-01.txt

I asked the RFC editor about best practice for using URI, but she didn=E2=80= =99t know off hand.  I will have to check into it some more.  Perh= aps the only option for RFC is to use URN but that seems a bit limiting.

Other people like W3C and OIDF don=E2=80=99t seem to have a problem wit= h URI for namespaces.

John B.
On Apr 8, 2016, at 3:55 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

In this update to draft-hunt-idevent-token, William Denniss and John Bradley= proposed to generalize the event uri format to be any URI rather than just U= RN. An example was also added for OIDC Logout (non-normative - since the cor= e spec won=E2=80=99t have normative events just examples).  Thanks William for revising the text.

I think we may have to add some text around event type URIs. For exampl= e, suggesting that fragments could be use to distinguish individual events t= hat may be specified in a parent specification.  E.g. So while Logout m= ight define only one event, a RISC or SCIM events spec will define many.  Also, IETF has multiple p= aths to its RFCs and the change to numbering. Not sure what will be best for= SCIM events in this regard - maybe using urn=E2=80=99s works best for IETF s= pecs?  Guidance greatly welcomed!


Begin forwarded message:

Subject: New Version Notification for draft-hunt-idevent-token-= 01.txt
Date: April 8, 2016 at 3:46:24 PM GMT-3
To: "William Denniss" <wdenniss@google.com>, "Phil Hunt" <phil.hunt@yahoo.com>, "Morteza Ansari" <morteza.ansari@cisco.com>


A new version of I-D, draft-hunt-idevent-token-01.txt
has been successfully submitted by Phil Hunt and posted to the
IETF repository.

Name: draft-hunt-idevent-token
Revision: 01
Title: Identity Event Token
Document date: 2016-04-08
Group: Individual Submission
Pages: 14
URL:            https://www.ietf.org/internet-drafts/draft-hunt-idevent-tok= en-01.txt
Status:         https:/= /datatracker.ietf.org/doc/draft-hunt-idevent-token/
Htmlized:       https://tools.ietf.o= rg/html/draft-hunt-idevent-token-01
Diff:           https://www.ietf.org/rfcdiff?url2=3Ddraft-hunt-idevent-token-01<= br>
Abstract:
  This specification defines an Identity Event token which may be<= br>   distributed via a protocol such as HTTP.  An identity event= token is
  based on the JSON Web Token and may be optionally signed and/or<= br>   encrypted.  It describes a statement of fact that may be sh= ared by an
  event publisher with registered subscribers.




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

The IETF Secretariat


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

____________________= ___________________________
Id-event mailing list
= Id-event@ietf.org
<= span>https://www.= ietf.org/mailman/listinfo/id-event
<= /html>= --Apple-Mail-8DB0FCBB-3CC8-465B-94D6-F2DC659336B5--