From nobody Mon Nov 2 22:13:43 2015 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A61171B2A1B; Mon, 2 Nov 2015 22:13:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 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, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id chISM_Kcbenz; Mon, 2 Nov 2015 22:13:41 -0800 (PST) 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 B04AB1B2A21; Mon, 2 Nov 2015 22:13:37 -0800 (PST) Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id tA36Dbwo005708 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 3 Nov 2015 06:13:37 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id tA36Da6t028882 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 3 Nov 2015 06:13:37 GMT Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by userv0122.oracle.com (8.13.8/8.13.8) with ESMTP id tA36DaTa025593; Tue, 3 Nov 2015 06:13:36 GMT Received: from dhcp-87-184.meeting.ietf94.jp (/133.93.87.184) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 02 Nov 2015 22:13:36 -0800 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_F4E79D77-BE9B-4C59-8A8B-E7FF162C9C2B" Date: Tue, 3 Nov 2015 15:13:33 +0900 Message-Id: <3BAF1EB4-4398-47DD-A353-E6B07CC4CC38@oracle.com> To: SCIM WG , "" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Cc: id-event@ietf.org Subject: [Id-event] Announcing new Identity Events Discussion List (id-event) X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 06:13:42 -0000 --Apple-Mail=_F4E79D77-BE9B-4C59-8A8B-E7FF162C9C2B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii At IETF94, a number of us got together to discuss the emerging event = work that is emerging in the Identity space: * OIDF RISC * OIDC Logout * SCIM Notify Events * OAuth Token Revocations * Consent Events The Id-Event discussion list is intended to begin discussion around = developing new IDs (and potentially form a WG) for the purpose of = defining a JWT message format for Identity Events and to define a = possible approach for distribution. The list was formed after several participants noticed common event = requirements that have emerged from SCIM provisioning, OIDC (eg. = Logout), RISC Events (e.g. account suspension, reset, take-over), as = well as OAuth2 (e.g. token revocations), and consent notification (e.g. = consent from a distributes OAuth/UMA system). At this time, the process and route to standardization for identity = events has not been determined. I expect that to be one of the = discussions we will have on the list. The web page for the mailing list is:=20 https://www.ietf.org/mailman/listinfo/id-event = Regards, Phil @independentid www.independentid.com phil.hunt@oracle.com --Apple-Mail=_F4E79D77-BE9B-4C59-8A8B-E7FF162C9C2B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii At IETF94, a number of us got together to discuss the = emerging event work that is emerging in the Identity space:

* OIDF RISC
* OIDC Logout
* SCIM Notify = Events
* OAuth Token Revocations
* Consent Events

The Id-Event discussion list is intended to begin discussion = around developing new IDs (and potentially form a WG) for the = purpose of defining a JWT message format for Identity Events and to = define a possible approach for distribution.

The list was formed after several participants noticed common = event requirements that have emerged from SCIM provisioning, OIDC = (eg. Logout), RISC Events (e.g. account suspension, reset, = take-over), as well as OAuth2 (e.g. token revocations), and consent = notification (e.g. consent from a distributes OAuth/UMA = system).

At = this time, the process and route to standardization for identity events = has not been determined. I expect that to be one of the discussions we = will have on the list.

The web page for the mailing list is: 

   https://www.ietf.org/mailman/listinfo/id-event

Regards,

Phil

= --Apple-Mail=_F4E79D77-BE9B-4C59-8A8B-E7FF162C9C2B-- From nobody Tue Nov 3 21:19:25 2015 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8EC31ACD24 for ; Tue, 3 Nov 2015 21:19:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3humrTu8NVQ4 for ; Tue, 3 Nov 2015 21:19:21 -0800 (PST) Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B56D1ACD17 for ; Tue, 3 Nov 2015 21:19:21 -0800 (PST) Received: by qgbb65 with SMTP id b65so32299077qgb.2 for ; Tue, 03 Nov 2015 21:19:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=Veq4uBtUV4PG7xkM5KiLKt13C7n+ZaCNO16P7McJtmk=; b=SJzpiz6BrOXM+O/GQ4YJ/75urr/lIymkjqQ6UZfLudTBMQ5yKDKVUjmL5w3zWFDmlO /sQ95SSx2vmKHuDiofKpcV5t0aJO6OT2d5PQEq8PW6hcCQXTg8PCxOsOTMuBn9S1OOfh vgUZOasp/vwEW4wlFrCNrT/I1YpRJ2Je6mq5+KquKxqimpkIUSu8auocfOv9X1qZsgeY +98Mqq6m4yAJQZ7w4Egw7a7LngBnkFV+daHXg6yR9utPOCxn6Um1Ij8XA7svWie8A3+E l/o3nJ+St6APkUcjlltl9qCEQ3i6IF/X1DX+mb949pfyZNIyySoIEMUZDeBNr1IWyhht 7D2Q== 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 :content-type; bh=Veq4uBtUV4PG7xkM5KiLKt13C7n+ZaCNO16P7McJtmk=; b=myWFMOO84g6DO6Yde0eChZ6m2g7XebdBruOVt3771qRUwvipCrdp/qL+WHgOolvOQU BOE06+/3u4ZJ5O9uUS6r8u2bZNXxe3LeI0+XyKYvASPjvcQtpDGa+Ujlx0CVTrqTxs/9 PeKIjh4LaYPr11fh9g0bbaXmSu4E2B9Vr0WvhXiItNWxXO26UYboe86t/DWf+r6eHVnd v8puykmYtcsUYiF3U+IwUeqAQ1O3+d6o5aOdBnlOiJXwR7fyidfenC4MltSav2mDHRmp 4bQn6hNrfo8OSitqRAj0ZvmAu4yh5hDiFSvB77k73kY87mK1hYzwumQfFyJAt8FfknOc Z9JA== X-Gm-Message-State: ALoCoQkp/CZMN9FT+IfddbmbTBwfgsezyJGD4e7W9u0u7LSWMCga4TOWFJ42Yz4rAyTowpc2mlbY X-Received: by 10.140.93.139 with SMTP id d11mr42474119qge.83.1446614360708; Tue, 03 Nov 2015 21:19:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.102.18 with HTTP; Tue, 3 Nov 2015 21:19:01 -0800 (PST) From: William Denniss Date: Wed, 4 Nov 2015 14:19:01 +0900 Message-ID: To: id-event@ietf.org Content-Type: multipart/alternative; boundary=001a113958c8191b6e0523b02753 Archived-At: Subject: [Id-event] Distinguishing different JWT types X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2015 05:19:23 -0000 --001a113958c8191b6e0523b02753 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Everyone, It was good talking to many of you at Yokohama earlier in the week about using JWTs for event messages like Logout, Risk Signals, SCIM profile updates and more. Thank you Phil for starting this conversation and spinning up the list! We're all doing related things with events, and it makes sense to collaborate and unify our approaches. An issue with JWT reuse currently is that ID Tokens are defined by OpenID Connect to require only a few standard JWT claims , and the required claims are highly re-usable and contain nothing that actually sets them apart as an "ID Token". The risk of this is that a JWT for an event like logout can be a valid ID Token for login. An attacker in possession of a logout token could replay it against a login endpoint, and gain access. One mitigation is to change the issuer, or audience. To me this is undesirable as the events (e.g. logout) do relate to the same issuer and audience. Like matter and anti-matter, yin and yang =E2=80=93 logout should= simply reverse the login. It seems wasteful to spin up a new issuer, new key rotations, and more just to manage each different type of event, if they would otherwise be related by issuer. Currently the Backchannel Logout draft attempts to "break" this utility of a logout JWT for authentication by prohibiting the 'nonce' field: The following Claim MUST NOT be used within the Logout Token: noncePROHIBITED. A nonce Claim MUST NOT be present. Its use is prohibited to make a Logout Token syntactically invalid if used in a forged Authentication Response in place of an ID Token. I'm concerned that this may not always work as intended, as 'nonce' is not a required field of the ID Token. ID Tokens obtained from Google using the code flow (on our OpenID Connect certified endpoints) do not contain 'nonce' today, for example. And I'm a little worried that RPs may not be strictly checking for a 'nonce', even when they should (e.g. when using the implicit flow). Even if this approach works in this specific case, it's not scalable. So I propose that we move to adopt a new standard claim that can be used to indicate the intended purpose of the JWT. 'typ' is an obvious choice for a claim name, although the word 'type' may be a little overloaded already. Another option could be "cat" for category. Whatever we decide, I think such a claim should be used in all JWT specs going forward, and added to OpenID Connect ID Tokens in a future revision. William --001a113958c8191b6e0523b02753 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Everyone,

It was good talking to man= y of you at Yokohama earlier in the week about using JWTs for event message= s like Logout, Risk Signals, SCIM profile updates and more. Thank you Phil = for starting this conversation and spinning up the list! We're all doin= g related things with events, and it makes sense to collaborate and unify o= ur approaches.

An issue with JWT reuse currently i= s that ID Tokens are defined=C2=A0by OpenID Connect to require only a few= standard JWT cla= ims, and the required claims are highly re-usable and contain nothing t= hat actually sets them apart as an "ID Token".

The risk of this is that a JWT for an event like logout can be a val= id ID Token for login.=C2=A0 An attacker in possession of a logout token co= uld replay it against a login endpoint, and gain access.

One mitigation is to change the issuer, or audience. To me this is u= ndesirable as the events (e.g. logout) do relate to the same issuer and aud= ience. Like matter and anti-matter, yin and yang =E2=80=93 logout should si= mply reverse the login.=C2=A0 It seems wasteful to spin up a new issuer, ne= w key rotations, and more just to manage each different type of event, if t= hey would otherwise be related by issuer.

Currentl= y the Backchannel Logout draft attempts to "break" this utility = of a logout JWT for authentication by prohibiting the=C2=A0'nonce' = field:

The following Claim M= UST NOT be used within the Logout Token:

nonce
PROHI= BITED. A=C2=A0nonce=C2=A0Claim MUST NOT be present. Its use= is prohibited to make a Logout Token syntactically invalid if used in a fo= rged Authentication Response in place of an ID Token.

I'm concerned that this may not always work = as intended, as 'nonce' is not a required field of the ID Token. ID= Tokens obtained from Google using the code flow (on our OpenID Connect cer= tified endpoints) do not contain 'nonce' today, for example. And I&= #39;m a little worried that RPs may not be strictly checking for a 'non= ce', even when they should (e.g. when using the implicit flow).

Even if this approach works in this specific case, it'= ;s not scalable. So I propose that we move to adopt a new standard claim th= at can be used to indicate the intended purpose of the JWT.

<= /div>
'typ' is an obvious choice for a claim name, although the= word 'type' may be a little overloaded already. Another option cou= ld be "cat" for category.=C2=A0 Whatever we decide, I think such = a claim should be used in all JWT specs going forward, and added to OpenID = Connect ID Tokens in a future revision.

William



--001a113958c8191b6e0523b02753-- From nobody Tue Nov 3 21:36:58 2015 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 037F01ACD9D for ; Tue, 3 Nov 2015 21:36:56 -0800 (PST) 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 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 9UBfYfHqb8IB for ; Tue, 3 Nov 2015 21:36:52 -0800 (PST) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) by ietfa.amsl.com (Postfix) with ESMTP id 7C2511AC3CA for ; Tue, 3 Nov 2015 21:36:51 -0800 (PST) X-AuditID: 12074422-f79976d0000078ca-98-563999725723 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 dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 61.41.30922.27999365; Wed, 4 Nov 2015 00:36:50 -0500 (EST) 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 tA45anUg012025; Wed, 4 Nov 2015 00:36:50 -0500 Received: from dhcp-29-147.meeting.ietf94.jp (dhcp-29-147.meeting.ietf94.jp [133.93.29.147]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id tA45ajaZ027572 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 4 Nov 2015 00:36:48 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_F4443EBD-E7DA-47DF-95A3-DA964740D571" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Justin Richer In-Reply-To: Date: Wed, 4 Nov 2015 14:36:44 +0900 Message-Id: <7A2911BB-0B39-4A61-8767-6A0D24012363@mit.edu> References: To: William Denniss X-Mailer: Apple Mail (2.2104) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAKsWRmVeSWpSXmKPExsUixCmqrFs00zLMYNliMYuOBd1MFpvmNLM7 MHks2FTqsWTJT6YApigum5TUnMyy1CJ9uwSujPvLFrAWzPGs2HKnl72B8ZFtFyMnh4SAicSa s2vYIWwxiQv31rN1MXJxCAksZpI4sWg6M4SzgVFi/rHZLBDODSaJn91tLCAtzAIJEufWPWYF sXkF9CRe3boMZgsLWElMmTgDrIZNQFVi+poWJhCbUyBQ4ubGXjCbRUBF4t3XaWwQc0Qlpjya wAIxx0ri9bRnzCC2kECAxIr5z8HiIgKaEi/PHmCBOFVWYvfvR0wTGAVmITljFpIzIOLaEssW vmaGsDUl9ncvZ8EU15Do/DaRdQEj2ypG2ZTcKt3cxMyc4tRk3eLkxLy81CJdU73czBK91JTS TYyggGd3UdrB+POg0iFGAQ5GJR7eG4yWYUKsiWXFlbmHGCU5mJREeUvagUJ8SfkplRmJxRnx RaU5qcWHGCU4mJVEeCv9gHK8KYmVValF+TApaQ4WJXHeTT/4QoQE0hNLUrNTUwtSi2CyMhwc ShK8H6cDNQoWpaanVqRl5pQgpJk4OEGG8wANVwap4S0uSMwtzkyHyJ9iVJQS502YAZQQAElk lObB9YISUmus7ORXjOJArwjzzgOp4gEmM7juV0CDmYAGM7VagAwuSURISTUw5iuKv9JyrQmI FBLlfybuVt29+M28aVnTE7nMmHnDbt6dXcdr/D0g0/z2XQ3HF1871zZrCj4TMPC7y/CmZ/+5 J/0Lw2Vba26F6Xo/C3l5ZqPSWmmz7bsMn/1deFK9Y8ffPV4d72JKzBa0rUtTsG+snjXTjH3W 9nWJCw5rud9/882h5tGy/xHBSizFGYmGWsxFxYkA5qfCdCMDAAA= Archived-At: Cc: id-event@ietf.org Subject: Re: [Id-event] Distinguishing different JWT types X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2015 05:36:56 -0000 --Apple-Mail=_F4443EBD-E7DA-47DF-95A3-DA964740D571 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I think a real question with regard to the login/logout case is, = succinctly, =E2=80=9CWhy is an application accepting an ID token from an = unknown third-party as proof of login=E2=80=9D? In the normal OIDC = process, the client will only get the ID token in response to an = authentication request, so it shouldn=E2=80=99t ever be just listening = for incoming ID tokens. =E2=80=94 Justin > On Nov 4, 2015, at 2:19 PM, William Denniss = wrote: >=20 > Hi Everyone, >=20 > It was good talking to many of you at Yokohama earlier in the week = about using JWTs for event messages like Logout, Risk Signals, SCIM = profile updates and more. Thank you Phil for starting this conversation = and spinning up the list! We're all doing related things with events, = and it makes sense to collaborate and unify our approaches. >=20 > An issue with JWT reuse currently is that ID Tokens are defined = by OpenID = Connect to require only a few standard JWT claims = , and the required claims = are highly re-usable and contain nothing that actually sets them apart = as an "ID Token". >=20 > The risk of this is that a JWT for an event like logout can be a valid = ID Token for login. An attacker in possession of a logout token could = replay it against a login endpoint, and gain access. >=20 > One mitigation is to change the issuer, or audience. To me this is = undesirable as the events (e.g. logout) do relate to the same issuer and = audience. Like matter and anti-matter, yin and yang =E2=80=93 logout = should simply reverse the login. It seems wasteful to spin up a new = issuer, new key rotations, and more just to manage each different type = of event, if they would otherwise be related by issuer. >=20 > Currently the Backchannel Logout draft = attempts = to "break" this utility of a logout JWT for authentication by = prohibiting the 'nonce' field: > The following Claim MUST NOT be used within the Logout Token: >=20 >=20 > nonce > PROHIBITED. A nonce Claim MUST NOT be present. Its use is prohibited = to make a Logout Token syntactically invalid if used in a forged = Authentication Response in place of an ID Token. >=20 > I'm concerned that this may not always work as intended, as 'nonce' is = not a required field of the ID Token. ID Tokens obtained from Google = using the code flow (on our OpenID Connect certified endpoints) do not = contain 'nonce' today, for example. And I'm a little worried that RPs = may not be strictly checking for a 'nonce', even when they should (e.g. = when using the implicit flow). >=20 > Even if this approach works in this specific case, it's not scalable. = So I propose that we move to adopt a new standard claim that can be used = to indicate the intended purpose of the JWT. >=20 > 'typ' is an obvious choice for a claim name, although the word 'type' = may be a little overloaded already. Another option could be "cat" for = category. Whatever we decide, I think such a claim should be used in = all JWT specs going forward, and added to OpenID Connect ID Tokens in a = future revision. >=20 > William >=20 >=20 >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event --Apple-Mail=_F4443EBD-E7DA-47DF-95A3-DA964740D571 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I think a real question with regard to the login/logout case = is, succinctly, =E2=80=9CWhy is an application accepting an ID token = from an unknown third-party as proof of login=E2=80=9D? In the normal = OIDC process, the client will only get the ID token in response to an = authentication request, so it shouldn=E2=80=99t ever be just listening = for incoming ID tokens.

 =E2=80=94 Justin

On = Nov 4, 2015, at 2:19 PM, William Denniss <wdenniss@google.com>= wrote:

Hi Everyone,

It was good talking to many of you at = Yokohama earlier in the week about using JWTs for event messages like = Logout, Risk Signals, SCIM profile updates and more. Thank you Phil for = starting this conversation and spinning up the list! We're all doing = related things with events, and it makes sense to collaborate and unify = our approaches.

An issue with JWT reuse currently is that ID Tokens are defined by OpenID Connect to require only a few standard= JWT claims, and the required claims are highly re-usable and = contain nothing that actually sets them apart as an "ID = Token".

The = risk of this is that a JWT for an event like logout can be a valid ID = Token for login.  An attacker in possession of a logout token could = replay it against a login endpoint, and gain access.

One mitigation is to = change the issuer, or audience. To me this is undesirable as the events = (e.g. logout) do relate to the same issuer and audience. Like matter and = anti-matter, yin and yang =E2=80=93 logout should simply reverse the = login.  It seems wasteful to spin up a new issuer, new key = rotations, and more just to manage each different type of event, if they = would otherwise be related by issuer.

Currently the Backchannel Logout draft attempts to "break" this utility = of a logout JWT for authentication by prohibiting the 'nonce' = field:

The following Claim MUST NOT be used within the Logout = Token:


nonce
PROHIBITED. A nonce Claim MUST NOT be = present. Its use is prohibited to make a Logout Token syntactically = invalid if used in a forged Authentication Response in place of an ID = Token.

I'm concerned = that this may not always work as intended, as 'nonce' is not a required = field of the ID Token. ID Tokens obtained from Google using the code = flow (on our OpenID Connect certified endpoints) do not contain 'nonce' = today, for example. And I'm a little worried that RPs may not be = strictly checking for a 'nonce', even when they should (e.g. when using = the implicit flow).

Even if this approach works in this specific case, it's not = scalable. So I propose that we move to adopt a new standard claim that = can be used to indicate the intended purpose of the JWT.

'typ' is an obvious = choice for a claim name, although the word 'type' may be a little = overloaded already. Another option could be "cat" for category.  = Whatever we decide, I think such a claim should be used in all JWT specs = going forward, and added to OpenID Connect ID Tokens in a future = revision.

William



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

= --Apple-Mail=_F4443EBD-E7DA-47DF-95A3-DA964740D571-- From nobody Tue Nov 3 23:07:11 2015 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 841601AD1FE for ; Tue, 3 Nov 2015 23:07:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ekpRGyX0C9yD for ; Tue, 3 Nov 2015 23:07:04 -0800 (PST) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF2851AD248 for ; Tue, 3 Nov 2015 23:07:04 -0800 (PST) Received: by pacdm15 with SMTP id dm15so20009734pac.3 for ; Tue, 03 Nov 2015 23:07:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb_com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=T9aasVfZATAwCgrNKJRMRIQJt256ddgnOjUoI7rcsO8=; b=h24nF7ovwtXv3CwuWdfqa5Ik9mMH8mjbvjsNxTLETpQ32UJ3/DH5/5w8Mhp1RWBXSM 2nQbEhQFxQjOLSU4rR+Xv6DhiSSsDNBQtCWdpWHEEtXQhC5C5GS6DC6kLOypYCL4SCgn FDx5K8N1XPZ0G7OgxglZVwpnOcctTWm+HxC6WUHDSehkVCD5RucIixxyH4Uh8XiJn/I+ WBvfZzseKNQzPqTw+VSB2mrs8OYFk4XhHC46Z7U2tDvOiy4DgrcTXeSI0Uv7D5EVgyqy B+bdqJtbUhCJp7Sh5wC3vDO80qPQvRAo+QNjTvRrBQuIvV2QsUY/D6/ud3ffx9Btu5Ad Ip3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=T9aasVfZATAwCgrNKJRMRIQJt256ddgnOjUoI7rcsO8=; b=cSGOEOYO66AawIfshns5OAHxPmjfryJiF7HfS8Tfi61B2UyV+NG5agfnOm3CcKol3d lPFfJZXLi7jL7czxz5YDnclbnuAbDliVXjZL3XJLdjtBsBVRtk4+yH1C9W3pzq+ixS1P yyz5Sh44Kk/ndSptPrkBKUWTqv4X8GAdLD3bq6skz6XpTeHNijKVkYgWlKWrnF9lJBqD pBJDchSKm0uvW90bBM8BBYkC63XGy4g8hsn8+Uvoc39DON5Af4AneR63oYGrXuNcEsmp 4KIah1ZjzXCclouzIOW2xcbAZoWPhz+Uzel9s/D1GWhAfjzpHwm2Ggu1aC89Z4A82VU5 Y2qA== X-Gm-Message-State: ALoCoQk8sOodvhqj2oD8lTsmjRejS1Ad8DcGd+bCdYeCNBHuJKGvf6I63Ka+8xF6sS/9MvetReZU X-Received: by 10.66.62.198 with SMTP id a6mr39456603pas.68.1446620824242; Tue, 03 Nov 2015 23:07:04 -0800 (PST) Received: from t20010c4000003024ad255d1379eb6fb2.v6.meeting.ietf94.jp (t20010c4000003024ad255d1379eb6fb2.v6.meeting.ietf94.jp. [2001:c40:0:3024:ad25:5d13:79eb:6fb2]) by smtp.gmail.com with ESMTPSA id kw16sm21629902pab.34.2015.11.03.23.07.02 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 03 Nov 2015 23:07:03 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_1B71C562-FFD5-4897-9D6F-0E2609C228C9" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: John Bradley In-Reply-To: <7A2911BB-0B39-4A61-8767-6A0D24012363@mit.edu> Date: Wed, 4 Nov 2015 16:01:27 +0900 Message-Id: References: <7A2911BB-0B39-4A61-8767-6A0D24012363@mit.edu> To: Justin Richer X-Mailer: Apple Mail (2.2104) Archived-At: Cc: William Denniss , id-event@ietf.org Subject: Re: [Id-event] Distinguishing different JWT types X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2015 07:07:09 -0000 --Apple-Mail=_1B71C562-FFD5-4897-9D6F-0E2609C228C9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 In principal a client gets a token two ways. =20 1 via a token endpoint in a direct communication. 2 via the authorization endpoint, In this case a client needs to check = the nonce value to correlate the token with the user agent that the = request was made via. I think it is fair not to have a nonce in the other tokens as they are = not requested via the browser. Nonce would also not be appropriate for = a JWT assertion. I would be more worried about other sorts of assertions being confused, = or at-least not easily differentiated.=20 I don=E2=80=99t think having a explicit JWT token type being a bad = thing. Adding it would not disrupt existing clients. =20 I think it is more a case of determining if this will be useful for = other things. In connect it would really only help badly coded clients = who are unlikely to check it anyway. John B. > On Nov 4, 2015, at 2:36 PM, Justin Richer > wrote: >=20 > I think a real question with regard to the login/logout case is, = succinctly, =E2=80=9CWhy is an application accepting an ID token from an = unknown third-party as proof of login=E2=80=9D? In the normal OIDC = process, the client will only get the ID token in response to an = authentication request, so it shouldn=E2=80=99t ever be just listening = for incoming ID tokens. >=20 > =E2=80=94 Justin >=20 >> On Nov 4, 2015, at 2:19 PM, William Denniss > wrote: >>=20 >> Hi Everyone, >>=20 >> It was good talking to many of you at Yokohama earlier in the week = about using JWTs for event messages like Logout, Risk Signals, SCIM = profile updates and more. Thank you Phil for starting this conversation = and spinning up the list! We're all doing related things with events, = and it makes sense to collaborate and unify our approaches. >>=20 >> An issue with JWT reuse currently is that ID Tokens are defined = by OpenID = Connect to require only a few standard JWT claims = , and the required claims = are highly re-usable and contain nothing that actually sets them apart = as an "ID Token". >>=20 >> The risk of this is that a JWT for an event like logout can be a = valid ID Token for login. An attacker in possession of a logout token = could replay it against a login endpoint, and gain access. >>=20 >> One mitigation is to change the issuer, or audience. To me this is = undesirable as the events (e.g. logout) do relate to the same issuer and = audience. Like matter and anti-matter, yin and yang =E2=80=93 logout = should simply reverse the login. It seems wasteful to spin up a new = issuer, new key rotations, and more just to manage each different type = of event, if they would otherwise be related by issuer. >>=20 >> Currently the Backchannel Logout draft = attempts = to "break" this utility of a logout JWT for authentication by = prohibiting the 'nonce' field: >> The following Claim MUST NOT be used within the Logout Token: >>=20 >>=20 >> nonce >> PROHIBITED. A nonce Claim MUST NOT be present. Its use is prohibited = to make a Logout Token syntactically invalid if used in a forged = Authentication Response in place of an ID Token. >>=20 >> I'm concerned that this may not always work as intended, as 'nonce' = is not a required field of the ID Token. ID Tokens obtained from Google = using the code flow (on our OpenID Connect certified endpoints) do not = contain 'nonce' today, for example. And I'm a little worried that RPs = may not be strictly checking for a 'nonce', even when they should (e.g. = when using the implicit flow). >>=20 >> Even if this approach works in this specific case, it's not scalable. = So I propose that we move to adopt a new standard claim that can be used = to indicate the intended purpose of the JWT. >>=20 >> 'typ' is an obvious choice for a claim name, although the word 'type' = may be a little overloaded already. Another option could be "cat" for = category. Whatever we decide, I think such a claim should be used in = all JWT specs going forward, and added to OpenID Connect ID Tokens in a = future revision. >>=20 >> William >>=20 >>=20 >>=20 >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://www.ietf.org/mailman/listinfo/id-event = >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event --Apple-Mail=_1B71C562-FFD5-4897-9D6F-0E2609C228C9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 In principal a client gets a token two ways.  
1 via a token endpoint in a direct communication.
2 via the authorization endpoint, In this case a client needs = to check the nonce value to correlate the token with the user agent that = the request was made via.

I think it is fair not to have a nonce in the other tokens as = they are not requested via the browser.  Nonce would also not be = appropriate for a JWT assertion.

I would be more worried about other = sorts of assertions being confused, or at-least not easily = differentiated. 

I don=E2=80=99t think having a explicit JWT token type being = a bad thing.   Adding it would not disrupt existing clients. =  

I think = it is more a case of determining if this will be useful for other = things.   In connect it would really only help badly coded clients = who are unlikely to check it anyway.

John B.

On Nov 4, 2015, at 2:36 PM, Justin Richer <jricher@mit.edu> = wrote:

I think a real = question with regard to the login/logout case is, succinctly, =E2=80=9CWhy= is an application accepting an ID token from an unknown third-party as = proof of login=E2=80=9D? In the normal OIDC process, the client will = only get the ID token in response to an authentication request, so it = shouldn=E2=80=99t ever be just listening for incoming ID tokens.

 =E2=80=94 = Justin

On Nov 4, 2015, at 2:19 PM, = William Denniss <wdenniss@google.com> wrote:

Hi Everyone,

It was good talking to many of you at = Yokohama earlier in the week about using JWTs for event messages like = Logout, Risk Signals, SCIM profile updates and more. Thank you Phil for = starting this conversation and spinning up the list! We're all doing = related things with events, and it makes sense to collaborate and unify = our approaches.

An issue with JWT reuse currently is that ID Tokens are defined by OpenID Connect to require only a few standard= JWT claims, and the required claims are highly re-usable and = contain nothing that actually sets them apart as an "ID = Token".

The = risk of this is that a JWT for an event like logout can be a valid ID = Token for login.  An attacker in possession of a logout token could = replay it against a login endpoint, and gain access.

One mitigation is to = change the issuer, or audience. To me this is undesirable as the events = (e.g. logout) do relate to the same issuer and audience. Like matter and = anti-matter, yin and yang =E2=80=93 logout should simply reverse the = login.  It seems wasteful to spin up a new issuer, new key = rotations, and more just to manage each different type of event, if they = would otherwise be related by issuer.

Currently the Backchannel Logout draft attempts to "break" this utility = of a logout JWT for authentication by prohibiting the 'nonce' = field:

The following Claim MUST NOT be used within the Logout = Token:


nonce
PROHIBITED. A nonce Claim MUST NOT be = present. Its use is prohibited to make a Logout Token syntactically = invalid if used in a forged Authentication Response in place of an ID = Token.

I'm concerned = that this may not always work as intended, as 'nonce' is not a required = field of the ID Token. ID Tokens obtained from Google using the code = flow (on our OpenID Connect certified endpoints) do not contain 'nonce' = today, for example. And I'm a little worried that RPs may not be = strictly checking for a 'nonce', even when they should (e.g. when using = the implicit flow).

Even if this approach works in this specific case, it's not = scalable. So I propose that we move to adopt a new standard claim that = can be used to indicate the intended purpose of the JWT.

'typ' is an obvious = choice for a claim name, although the word 'type' may be a little = overloaded already. Another option could be "cat" for category.  = Whatever we decide, I think such a claim should be used in all JWT specs = going forward, and added to OpenID Connect ID Tokens in a future = revision.

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

= --Apple-Mail=_1B71C562-FFD5-4897-9D6F-0E2609C228C9-- From nobody Tue Nov 3 23:08:52 2015 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EDF91AD1EE for ; Tue, 3 Nov 2015 23:08:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TyvG3yVjtfbh for ; Tue, 3 Nov 2015 23:08:48 -0800 (PST) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::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 DF14B1AD359 for ; Tue, 3 Nov 2015 23:08:47 -0800 (PST) Received: by pabfh17 with SMTP id fh17so44389921pab.0 for ; Tue, 03 Nov 2015 23:08:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb_com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=YWNOJ/jxyrRX9db3fL/LWRWarS8v5m0pjatpdaV2Vm8=; b=TCoymt1WpgPWEayx44UUg9yp/epnRLiGNWKJqjTDWEavBnktpuJQpzZFE2RfIODwQk 6QUOdiN1/EWVsglRvZIjvnU5wG2ZILvw+JWeoSSSsz2TwjDUlCRfJGLD0DVdMzFaP15P 2Wbooi6a7NGuDpYJmvoovpfXj7mvCV6yxr2ioUdmCkgi7z4Ltuodoo4gAi2qAgArftLi w5+Oz2qaSN1W/JHyafcCKR/rDSEV3TNZQzVuNzf9WRnXULtND7tNvmDiXFAfF5Li7HUe MIvAjL5LHjiPNPldxwd4ggPBdtc6YTlJF6a/vxOJpl7KOmQ6x8ALeuxFotf0z02adHzJ kHJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=YWNOJ/jxyrRX9db3fL/LWRWarS8v5m0pjatpdaV2Vm8=; b=LytAf2siLQtKw+uEHGlMeCPiwHZIAtSswBiRIiBGT+yVIFlVeRqdMa7ovS7KC3sN2R /gEYRPCIQuqwDnPytVFyTMF9tQJpegjqjD1tC7WK0K5ysSkDdZZUYGUQVXUNjIvKdpk9 ISsXZtKMATwy7LRi55TzZm4C2N3FFHSnoB3Ui52kd3Eue+s1G1/9idTqvsLO2s0ECW57 xgJzJD3TRYBLJez55fill1+ZAtRzLLAw0jhRuisrt3BrLjBezIkYI9UbogVezd04vNm5 QdmjuJ1AT1LAevKZsAM06NgdufN0fTcTWNyVpl6gzJ3Ff5sK0oc8V1+ht7xOvuUzLBNE odjA== X-Gm-Message-State: ALoCoQnjxVMOZV/iwOFEntilluF/KqN0Uyei1qa0fBaFo5v6WGAm8sPzd2MTVlYMcSJM/bY5P5wZ X-Received: by 10.68.136.69 with SMTP id py5mr39579446pbb.94.1446620927499; Tue, 03 Nov 2015 23:08:47 -0800 (PST) Received: from t20010c4000003024ad255d1379eb6fb2.v6.meeting.ietf94.jp (t20010c4000003024ad255d1379eb6fb2.v6.meeting.ietf94.jp. [2001:c40:0:3024:ad25:5d13:79eb:6fb2]) by smtp.gmail.com with ESMTPSA id ns1sm33300869pbc.67.2015.11.03.23.08.45 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 03 Nov 2015 23:08:46 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_9B37F1C8-BB3B-48B7-9F3F-D1956BBD835B" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: John Bradley In-Reply-To: <7A2911BB-0B39-4A61-8767-6A0D24012363@mit.edu> Date: Wed, 4 Nov 2015 16:06:03 +0900 Message-Id: References: <7A2911BB-0B39-4A61-8767-6A0D24012363@mit.edu> To: Justin Richer X-Mailer: Apple Mail (2.2104) Archived-At: Cc: William Denniss , id-event@ietf.org Subject: Re: [Id-event] Distinguishing different JWT types X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2015 07:08:51 -0000 --Apple-Mail=_9B37F1C8-BB3B-48B7-9F3F-D1956BBD835B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 In principal a client gets a token two ways. =20 1 via a token endpoint in a direct communication. 2 via the authorization endpoint, In this case a client needs to check = the nonce value to correlate the token with the user agent that the = request was made via. I think it is fair not to have a nonce in the other tokens as they are = not requested via the browser. Nonce would also not be appropriate for = a JWT assertion. I would be more worried about other sorts of assertions being confused, = or at-least not easily differentiated.=20 I don=E2=80=99t think having a explicit JWT token type being a bad = thing. Adding it would not disrupt existing clients. =20 I think it is more a case of determining if this will be useful for = other things. In connect it would really only help badly coded clients = who are unlikely to check it anyway. John B. > On Nov 4, 2015, at 2:36 PM, Justin Richer > wrote: >=20 > I think a real question with regard to the login/logout case is, = succinctly, =E2=80=9CWhy is an application accepting an ID token from an = unknown third-party as proof of login=E2=80=9D? In the normal OIDC = process, the client will only get the ID token in response to an = authentication request, so it shouldn=E2=80=99t ever be just listening = for incoming ID tokens. >=20 > =E2=80=94 Justin >=20 >> On Nov 4, 2015, at 2:19 PM, William Denniss > wrote: >>=20 >> Hi Everyone, >>=20 >> It was good talking to many of you at Yokohama earlier in the week = about using JWTs for event messages like Logout, Risk Signals, SCIM = profile updates and more. Thank you Phil for starting this conversation = and spinning up the list! We're all doing related things with events, = and it makes sense to collaborate and unify our approaches. >>=20 >> An issue with JWT reuse currently is that ID Tokens are defined = by OpenID = Connect to require only a few standard JWT claims = , and the required claims = are highly re-usable and contain nothing that actually sets them apart = as an "ID Token". >>=20 >> The risk of this is that a JWT for an event like logout can be a = valid ID Token for login. An attacker in possession of a logout token = could replay it against a login endpoint, and gain access. >>=20 >> One mitigation is to change the issuer, or audience. To me this is = undesirable as the events (e.g. logout) do relate to the same issuer and = audience. Like matter and anti-matter, yin and yang =E2=80=93 logout = should simply reverse the login. It seems wasteful to spin up a new = issuer, new key rotations, and more just to manage each different type = of event, if they would otherwise be related by issuer. >>=20 >> Currently the Backchannel Logout draft = attempts = to "break" this utility of a logout JWT for authentication by = prohibiting the 'nonce' field: >> The following Claim MUST NOT be used within the Logout Token: >>=20 >>=20 >> nonce >> PROHIBITED. A nonce Claim MUST NOT be present. Its use is prohibited = to make a Logout Token syntactically invalid if used in a forged = Authentication Response in place of an ID Token. >>=20 >> I'm concerned that this may not always work as intended, as 'nonce' = is not a required field of the ID Token. ID Tokens obtained from Google = using the code flow (on our OpenID Connect certified endpoints) do not = contain 'nonce' today, for example. And I'm a little worried that RPs = may not be strictly checking for a 'nonce', even when they should (e.g. = when using the implicit flow). >>=20 >> Even if this approach works in this specific case, it's not scalable. = So I propose that we move to adopt a new standard claim that can be used = to indicate the intended purpose of the JWT. >>=20 >> 'typ' is an obvious choice for a claim name, although the word 'type' = may be a little overloaded already. Another option could be "cat" for = category. Whatever we decide, I think such a claim should be used in = all JWT specs going forward, and added to OpenID Connect ID Tokens in a = future revision. >>=20 >> William >>=20 >>=20 >>=20 >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://www.ietf.org/mailman/listinfo/id-event = >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event = --Apple-Mail=_9B37F1C8-BB3B-48B7-9F3F-D1956BBD835B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 In principal a client gets a token two ways.  
1 via a token endpoint in a direct communication.
2 via the authorization endpoint, In this case a client needs = to check the nonce value to correlate the token with the user agent that = the request was made via.

I think it is fair not to have a nonce in the other tokens as = they are not requested via the browser.  Nonce would also not be = appropriate for a JWT assertion.

I would be more worried about other = sorts of assertions being confused, or at-least not easily = differentiated. 

I don=E2=80=99t think having a explicit JWT token type being = a bad thing.   Adding it would not disrupt existing clients. =  

I think = it is more a case of determining if this will be useful for other = things.   In connect it would really only help badly coded clients = who are unlikely to check it anyway.

John B.

On Nov 4, 2015, at 2:36 PM, Justin Richer <jricher@mit.edu> = wrote:

I think a real = question with regard to the login/logout case is, succinctly, =E2=80=9CWhy= is an application accepting an ID token from an unknown third-party as = proof of login=E2=80=9D? In the normal OIDC process, the client will = only get the ID token in response to an authentication request, so it = shouldn=E2=80=99t ever be just listening for incoming ID tokens.

 =E2=80=94 = Justin

On Nov 4, 2015, at 2:19 PM, = William Denniss <wdenniss@google.com> wrote:

Hi Everyone,

It was good talking to many of you at = Yokohama earlier in the week about using JWTs for event messages like = Logout, Risk Signals, SCIM profile updates and more. Thank you Phil for = starting this conversation and spinning up the list! We're all doing = related things with events, and it makes sense to collaborate and unify = our approaches.

An issue with JWT reuse currently is that ID Tokens are defined by OpenID Connect to require only a few standard= JWT claims, and the required claims are highly re-usable and = contain nothing that actually sets them apart as an "ID = Token".

The = risk of this is that a JWT for an event like logout can be a valid ID = Token for login.  An attacker in possession of a logout token could = replay it against a login endpoint, and gain access.

One mitigation is to = change the issuer, or audience. To me this is undesirable as the events = (e.g. logout) do relate to the same issuer and audience. Like matter and = anti-matter, yin and yang =E2=80=93 logout should simply reverse the = login.  It seems wasteful to spin up a new issuer, new key = rotations, and more just to manage each different type of event, if they = would otherwise be related by issuer.

Currently the Backchannel Logout draft attempts to "break" this utility = of a logout JWT for authentication by prohibiting the 'nonce' = field:

The following Claim MUST NOT be used within the Logout = Token:


nonce
PROHIBITED. A nonce Claim MUST NOT be = present. Its use is prohibited to make a Logout Token syntactically = invalid if used in a forged Authentication Response in place of an ID = Token.

I'm concerned = that this may not always work as intended, as 'nonce' is not a required = field of the ID Token. ID Tokens obtained from Google using the code = flow (on our OpenID Connect certified endpoints) do not contain 'nonce' = today, for example. And I'm a little worried that RPs may not be = strictly checking for a 'nonce', even when they should (e.g. when using = the implicit flow).

Even if this approach works in this specific case, it's not = scalable. So I propose that we move to adopt a new standard claim that = can be used to indicate the intended purpose of the JWT.

'typ' is an obvious = choice for a claim name, although the word 'type' may be a little = overloaded already. Another option could be "cat" for category.  = Whatever we decide, I think such a claim should be used in all JWT specs = going forward, and added to OpenID Connect ID Tokens in a future = revision.

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

= --Apple-Mail=_9B37F1C8-BB3B-48B7-9F3F-D1956BBD835B-- From nobody Tue Nov 3 23:25:09 2015 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2F891B29E5 for ; Tue, 3 Nov 2015 23:25:07 -0800 (PST) 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 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 0cZ-8AJxeUuU for ; Tue, 3 Nov 2015 23:25:04 -0800 (PST) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA83B1B29E2 for ; Tue, 3 Nov 2015 23:25:03 -0800 (PST) X-AuditID: 1209190e-f79296d00000051c-e7-5639b2ceacad 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 dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 0B.4B.01308.EC2B9365; Wed, 4 Nov 2015 02:25:02 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id tA47P12W000832; Wed, 4 Nov 2015 02:25:01 -0500 Received: from dhcp-29-147.meeting.ietf94.jp (dhcp-29-147.meeting.ietf94.jp [133.93.29.147]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id tA47Op1h023343 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 4 Nov 2015 02:24:58 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_0CCB9D68-5320-4E63-B7E4-77F5C85367D6" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Justin Richer In-Reply-To: Date: Wed, 4 Nov 2015 16:24:50 +0900 Message-Id: <0EE00ED6-D344-4B92-9A05-8FFB7BCB6BF0@mit.edu> References: <7A2911BB-0B39-4A61-8767-6A0D24012363@mit.edu> To: John Bradley X-Mailer: Apple Mail (2.2104) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBKsWRmVeSWpSXmKPExsUixCmqrXtuk2WYwbO5QhYdC7qZLFbf/ctm sWlOM7sDs8eCTaUeS5b8ZPK4fXsjSwBzFJdNSmpOZllqkb5dAlfG0v3zWAsWVVTM6DjH0sD4 ObWLkYNDQsBE4vIRhS5GTiBTTOLCvfVsXYxcHEICi5kkzu8/zQrhbGCUmL9vGQuEc4NJYtax LewgLcwCCRLrtr9hBbF5BfQkXt26DGYLC1hJTJk4gwXEZhNQlZi+poUJxOYUsJNYd+UHC8hm FgEViT2vbSDG2Ei83faBEWKMlcSNlmVgtpDARkaJpZMVQWwRoPJ9+x4xQlwqK7H79yOmCYwC s5BcMQvJFRBxbYllC18zQ9iaEvu7l7NgimtIdH6byLqAkW0Vo2xKbpVubmJmTnFqsm5xcmJe XmqRrrFebmaJXmpK6SZGcARI8u1g/HpQ6RCjAAejEg9vw3+LMCHWxLLiytxDjJIcTEqivM9n W4YJ8SXlp1RmJBZnxBeV5qQWH2KU4GBWEuFtWgKU401JrKxKLcqHSUlzsCiJ8276wRciJJCe WJKanZpakFoEk5Xh4FCS4F2wEahRsCg1PbUiLTOnBCHNxMEJMpwHaHgpSA1vcUFibnFmOkT+ FKOilDhvF0hCACSRUZoH1wtKUK2xspNfMYoDvSLMmwpSxQNMbnDdr4AGMwENZmq1ABlckoiQ kmpgdJjza9nsd/me9deWCAYH2d6dwrQ6pWv73Y0bGaV6Li3WbVefnsw2a0vqlO1q5z5c1uWL ilYQjKhxeDlNWk319p86ifa/Lzu/HXWZwfnm9NWq8+9/JZs8sEn44rTH7csR6ejTUpxCa+0W fm3aHJ++oIlNkHNeilPuAZW8dqa+jidznJe9tanRUmIpzkg01GIuKk4EADfNyYkrAwAA Archived-At: Cc: William Denniss , id-event@ietf.org Subject: Re: [Id-event] Distinguishing different JWT types X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2015 07:25:07 -0000 --Apple-Mail=_0CCB9D68-5320-4E63-B7E4-77F5C85367D6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I=E2=80=99m very much in favor of having a JWT token type key, but for = other reasons and uses.=20 I=E2=80=99m just taking issue with the assertion that a logout token = could be easily confused by a functioning OIDC client. Even then I think it=E2=80=99s a good idea to have a =E2=80=9Ctyp": = =E2=80=9Clogout=E2=80=9D tag in it. The current guideline to take the = =E2=80=9Cnonce=E2=80=9D out is a profoundly stupid hack that=E2=80=99s = not likely to make much difference in the real world, or at least even = less of a difference than a type parameter. Along those lines, I=E2=80=99d suggest we use =E2=80=9Cjtt" or =E2=80=9CJS= ON (web) Token Type=E2=80=9D as the field name, so we don=E2=80=99t = cause confusion with the header =E2=80=9Ctyp=E2=80=9D parameter. =E2=80=94 Justin > On Nov 4, 2015, at 4:06 PM, John Bradley wrote: >=20 > In principal a client gets a token two ways. =20 > 1 via a token endpoint in a direct communication. > 2 via the authorization endpoint, In this case a client needs to check = the nonce value to correlate the token with the user agent that the = request was made via. >=20 > I think it is fair not to have a nonce in the other tokens as they are = not requested via the browser. Nonce would also not be appropriate for = a JWT assertion. >=20 > I would be more worried about other sorts of assertions being = confused, or at-least not easily differentiated.=20 >=20 > I don=E2=80=99t think having a explicit JWT token type being a bad = thing. Adding it would not disrupt existing clients. =20 >=20 > I think it is more a case of determining if this will be useful for = other things. In connect it would really only help badly coded clients = who are unlikely to check it anyway. >=20 > John B. >=20 >> On Nov 4, 2015, at 2:36 PM, Justin Richer > wrote: >>=20 >> I think a real question with regard to the login/logout case is, = succinctly, =E2=80=9CWhy is an application accepting an ID token from an = unknown third-party as proof of login=E2=80=9D? In the normal OIDC = process, the client will only get the ID token in response to an = authentication request, so it shouldn=E2=80=99t ever be just listening = for incoming ID tokens. >>=20 >> =E2=80=94 Justin >>=20 >>> On Nov 4, 2015, at 2:19 PM, William Denniss > wrote: >>>=20 >>> Hi Everyone, >>>=20 >>> It was good talking to many of you at Yokohama earlier in the week = about using JWTs for event messages like Logout, Risk Signals, SCIM = profile updates and more. Thank you Phil for starting this conversation = and spinning up the list! We're all doing related things with events, = and it makes sense to collaborate and unify our approaches. >>>=20 >>> An issue with JWT reuse currently is that ID Tokens are defined = by OpenID = Connect to require only a few standard JWT claims = , and the required claims = are highly re-usable and contain nothing that actually sets them apart = as an "ID Token". >>>=20 >>> The risk of this is that a JWT for an event like logout can be a = valid ID Token for login. An attacker in possession of a logout token = could replay it against a login endpoint, and gain access. >>>=20 >>> One mitigation is to change the issuer, or audience. To me this is = undesirable as the events (e.g. logout) do relate to the same issuer and = audience. Like matter and anti-matter, yin and yang =E2=80=93 logout = should simply reverse the login. It seems wasteful to spin up a new = issuer, new key rotations, and more just to manage each different type = of event, if they would otherwise be related by issuer. >>>=20 >>> Currently the Backchannel Logout draft = attempts = to "break" this utility of a logout JWT for authentication by = prohibiting the 'nonce' field: >>> The following Claim MUST NOT be used within the Logout Token: >>>=20 >>>=20 >>> nonce >>> PROHIBITED. A nonce Claim MUST NOT be present. Its use is prohibited = to make a Logout Token syntactically invalid if used in a forged = Authentication Response in place of an ID Token. >>>=20 >>> I'm concerned that this may not always work as intended, as 'nonce' = is not a required field of the ID Token. ID Tokens obtained from Google = using the code flow (on our OpenID Connect certified endpoints) do not = contain 'nonce' today, for example. And I'm a little worried that RPs = may not be strictly checking for a 'nonce', even when they should (e.g. = when using the implicit flow). >>>=20 >>> Even if this approach works in this specific case, it's not = scalable. So I propose that we move to adopt a new standard claim that = can be used to indicate the intended purpose of the JWT. >>>=20 >>> 'typ' is an obvious choice for a claim name, although the word = 'type' may be a little overloaded already. Another option could be "cat" = for category. Whatever we decide, I think such a claim should be used = in all JWT specs going forward, and added to OpenID Connect ID Tokens in = a future revision. >>>=20 >>> William >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> Id-event mailing list >>> Id-event@ietf.org >>> https://www.ietf.org/mailman/listinfo/id-event = >>=20 >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://www.ietf.org/mailman/listinfo/id-event = >=20 --Apple-Mail=_0CCB9D68-5320-4E63-B7E4-77F5C85367D6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I=E2=80=99m very much in favor of having a JWT token type = key, but for other reasons and uses. 

I=E2=80=99m just taking issue with the = assertion that a logout token could be easily confused by a functioning = OIDC client.

Even = then I think it=E2=80=99s a good idea to have a =E2=80=9Ctyp": = =E2=80=9Clogout=E2=80=9D tag in it. The current guideline to take the = =E2=80=9Cnonce=E2=80=9D out is a profoundly stupid hack that=E2=80=99s = not likely to make much difference in the real world, or at least even = less of a difference than a type parameter.

Along those lines, I=E2=80=99d suggest = we use =E2=80=9Cjtt" or =E2=80=9CJSON (web) Token Type=E2=80=9D as the = field name, so we don=E2=80=99t cause confusion with the header = =E2=80=9Ctyp=E2=80=9D parameter.

 =E2=80=94 Justin

On Nov 4, 2015, at 4:06 PM, John Bradley <ve7jtb@ve7jtb.com> = wrote:

In principal a = client gets a token two ways.  
1 via a token = endpoint in a direct communication.
2 via the = authorization endpoint, In this case a client needs to check the nonce = value to correlate the token with the user agent that the request was = made via.

I = think it is fair not to have a nonce in the other tokens as they are not = requested via the browser.  Nonce would also not be appropriate for = a JWT assertion.

I would be more worried about other sorts of assertions being = confused, or at-least not easily differentiated. 

I don=E2=80=99t think = having a explicit JWT token type being a bad thing.   Adding it = would not disrupt existing clients.  

I think it is more a case of = determining if this will be useful for other things.   In connect = it would really only help badly coded clients who are unlikely to check = it anyway.

John = B.

On Nov 4, 2015, at 2:36 PM, = Justin Richer <jricher@mit.edu> wrote:

I think a real = question with regard to the login/logout case is, succinctly, =E2=80=9CWhy= is an application accepting an ID token from an unknown third-party as = proof of login=E2=80=9D? In the normal OIDC process, the client will = only get the ID token in response to an authentication request, so it = shouldn=E2=80=99t ever be just listening for incoming ID tokens.

 =E2=80=94 = Justin

On Nov 4, 2015, at 2:19 PM, = William Denniss <wdenniss@google.com> wrote:

Hi Everyone,

It was good talking to many of you at Yokohama earlier in the = week about using JWTs for event messages like Logout, Risk Signals, SCIM = profile updates and more. Thank you Phil for starting this conversation = and spinning up the list! We're all doing related things with events, = and it makes sense to collaborate and unify our approaches.

An issue with JWT reuse = currently is that ID Tokens are defined by OpenID Connect to require only a few standard= JWT claims, and the required claims are highly re-usable and = contain nothing that actually sets them apart as an "ID = Token".

The = risk of this is that a JWT for an event like logout can be a valid ID = Token for login.  An attacker in possession of a logout token could = replay it against a login endpoint, and gain access.

One mitigation is to = change the issuer, or audience. To me this is undesirable as the events = (e.g. logout) do relate to the same issuer and audience. Like matter and = anti-matter, yin and yang =E2=80=93 logout should simply reverse the = login.  It seems wasteful to spin up a new issuer, new key = rotations, and more just to manage each different type of event, if they = would otherwise be related by issuer.

Currently the Backchannel Logout draft attempts to "break" this utility = of a logout JWT for authentication by prohibiting the 'nonce' = field:

The following Claim MUST NOT be used within the Logout = Token:


nonce
PROHIBITED. A nonce Claim MUST NOT be = present. Its use is prohibited to make a Logout Token syntactically = invalid if used in a forged Authentication Response in place of an ID = Token.

I'm concerned = that this may not always work as intended, as 'nonce' is not a required = field of the ID Token. ID Tokens obtained from Google using the code = flow (on our OpenID Connect certified endpoints) do not contain 'nonce' = today, for example. And I'm a little worried that RPs may not be = strictly checking for a 'nonce', even when they should (e.g. when using = the implicit flow).

Even if this approach works in this specific case, it's not = scalable. So I propose that we move to adopt a new standard claim that = can be used to indicate the intended purpose of the JWT.

'typ' is an obvious = choice for a claim name, although the word 'type' may be a little = overloaded already. Another option could be "cat" for category.  = Whatever we decide, I think such a claim should be used in all JWT specs = going forward, and added to OpenID Connect ID Tokens in a future = revision.

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


= --Apple-Mail=_0CCB9D68-5320-4E63-B7E4-77F5C85367D6-- From nobody Tue Nov 3 23:41:53 2015 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8B7B1B2A0B for ; Tue, 3 Nov 2015 23:41:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x2E6nkiCu27a for ; Tue, 3 Nov 2015 23:41:48 -0800 (PST) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 645C31ACF1B for ; Tue, 3 Nov 2015 23:41:48 -0800 (PST) Received: by pacdm15 with SMTP id dm15so20969536pac.3 for ; Tue, 03 Nov 2015 23:41:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb_com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=CeI+OXZUkxHjOQgiZMjSfpBTivsezgtqZKkgb5mRwho=; b=XkwSD7ju/R1agei9AU0wPDEZhVr+hSmy+dc50MA2oHNpPjvGtUBjZpIb0kjaAqWxGF 4J0zvdjUEcVK5athSba7qVO4VeomR6UShYro20MsKalqyk9INDbTnF1kNY62jra+n+zP 17G+eblmt1vT6aIzNNGLGdmEtKNkyr009ai0lNbdvnhQKhMcGkQYsz1cZ70lcSunT25R nv4yo5WecFXO4xtvzdvgGuWwO+NxjKX9QHzC1qUUtH5vWSGUWZTcx5avT27Fey1m7sp1 PmxLWpgAZCqHBAZBjhXmn8iEqTMaPom+2XFdly+560PboNJ7rvEDWYx/YhH6Wc6643PT NITQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=CeI+OXZUkxHjOQgiZMjSfpBTivsezgtqZKkgb5mRwho=; b=fHqIOGHKdAOKtFZU0aYXNF4olCNvMmiZFexcZPVQVY3mG8huQMTYk2o4RpqTE6Srt5 TfTZh6RFMeOIQdSaLsZJFfl6UhQiyWaItSSpMQQ8H3sQzpcc45RSlgRNp0mjzMcek9xO zCSkDDWky+/3W64qrixsSe66MPwsYDBaOaz7fXjY7eaAoO66h/bncz7Gv51Mfk/6FN2d t7GtGR1cVMkZTqIbGSNPbKz5TP6vEoiS05jxjTQGmw6IAFLRaWaNWt7D0Xt4G5+7DzaL utEsinFinn5k38NXtAIvaOtzm76oDNhDpJ+xKjZUc9JXHmJBqwhw61zeirWp64xC9Q/9 f8GQ== X-Gm-Message-State: ALoCoQnD8DrMGOjgbThHYu121LmG0JTj++F12SDHpF8f92UxW3U5+t2N1cQzaACc8cK7fYwIxXtZ X-Received: by 10.66.188.231 with SMTP id gd7mr76623pac.9.1446622907849; Tue, 03 Nov 2015 23:41:47 -0800 (PST) Received: from t20010c4000003024ad255d1379eb6fb2.v6.meeting.ietf94.jp (t20010c4000003024ad255d1379eb6fb2.v6.meeting.ietf94.jp. [2001:c40:0:3024:ad25:5d13:79eb:6fb2]) by smtp.gmail.com with ESMTPSA id fl1sm192339pab.10.2015.11.03.23.41.46 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 03 Nov 2015 23:41:47 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_4E5E8DF2-6C79-4525-94C3-1E23A4C499F4" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: John Bradley In-Reply-To: <0EE00ED6-D344-4B92-9A05-8FFB7BCB6BF0@mit.edu> Date: Wed, 4 Nov 2015 16:41:45 +0900 Message-Id: <752553F8-BF2B-4C96-BEFC-204EA67FE17E@ve7jtb.com> References: <7A2911BB-0B39-4A61-8767-6A0D24012363@mit.edu> <0EE00ED6-D344-4B92-9A05-8FFB7BCB6BF0@mit.edu> To: Justin Richer X-Mailer: Apple Mail (2.2104) Archived-At: Cc: William Denniss , id-event@ietf.org Subject: Re: [Id-event] Distinguishing different JWT types X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2015 07:41:51 -0000 --Apple-Mail=_4E5E8DF2-6C79-4525-94C3-1E23A4C499F4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Nonce is only required for tokens being delivered in the front channel. = Saying don=E2=80=99t try to store it on the server side to send as part = of the backchannel logout where it makes no sense, and that the client = shouldn't look for it to verify, is reasonable. =20 I agree that characterizing it as a way to keep a token from being = accepted in the implicit flow is probably confusing. It is true that as it is now, a client MUST not take a id_token in the = front channel with a missing or invalid nonce. Unfortunately that may = not be perfectly implemented in all clients. The various possible distribution methods for these other sorts of = tokens may have different security characteristics and may not be kept = perfectly secret via a hub etc. Those tokens should not be accepted in the front channel no matter what = there claims as long as the client implements nonce correctly. John B. > On Nov 4, 2015, at 4:24 PM, Justin Richer wrote: >=20 > I=E2=80=99m very much in favor of having a JWT token type key, but for = other reasons and uses.=20 >=20 > I=E2=80=99m just taking issue with the assertion that a logout token = could be easily confused by a functioning OIDC client. >=20 > Even then I think it=E2=80=99s a good idea to have a =E2=80=9Ctyp": = =E2=80=9Clogout=E2=80=9D tag in it. The current guideline to take the = =E2=80=9Cnonce=E2=80=9D out is a profoundly stupid hack that=E2=80=99s = not likely to make much difference in the real world, or at least even = less of a difference than a type parameter. >=20 > Along those lines, I=E2=80=99d suggest we use =E2=80=9Cjtt" or =E2=80=9C= JSON (web) Token Type=E2=80=9D as the field name, so we don=E2=80=99t = cause confusion with the header =E2=80=9Ctyp=E2=80=9D parameter. >=20 > =E2=80=94 Justin >=20 >> On Nov 4, 2015, at 4:06 PM, John Bradley > wrote: >>=20 >> In principal a client gets a token two ways. =20 >> 1 via a token endpoint in a direct communication. >> 2 via the authorization endpoint, In this case a client needs to = check the nonce value to correlate the token with the user agent that = the request was made via. >>=20 >> I think it is fair not to have a nonce in the other tokens as they = are not requested via the browser. Nonce would also not be appropriate = for a JWT assertion. >>=20 >> I would be more worried about other sorts of assertions being = confused, or at-least not easily differentiated.=20 >>=20 >> I don=E2=80=99t think having a explicit JWT token type being a bad = thing. Adding it would not disrupt existing clients. =20 >>=20 >> I think it is more a case of determining if this will be useful for = other things. In connect it would really only help badly coded clients = who are unlikely to check it anyway. >>=20 >> John B. >>=20 >>> On Nov 4, 2015, at 2:36 PM, Justin Richer > wrote: >>>=20 >>> I think a real question with regard to the login/logout case is, = succinctly, =E2=80=9CWhy is an application accepting an ID token from an = unknown third-party as proof of login=E2=80=9D? In the normal OIDC = process, the client will only get the ID token in response to an = authentication request, so it shouldn=E2=80=99t ever be just listening = for incoming ID tokens. >>>=20 >>> =E2=80=94 Justin >>>=20 >>>> On Nov 4, 2015, at 2:19 PM, William Denniss > wrote: >>>>=20 >>>> Hi Everyone, >>>>=20 >>>> It was good talking to many of you at Yokohama earlier in the week = about using JWTs for event messages like Logout, Risk Signals, SCIM = profile updates and more. Thank you Phil for starting this conversation = and spinning up the list! We're all doing related things with events, = and it makes sense to collaborate and unify our approaches. >>>>=20 >>>> An issue with JWT reuse currently is that ID Tokens are defined = by OpenID = Connect to require only a few standard JWT claims = , and the required claims = are highly re-usable and contain nothing that actually sets them apart = as an "ID Token". >>>>=20 >>>> The risk of this is that a JWT for an event like logout can be a = valid ID Token for login. An attacker in possession of a logout token = could replay it against a login endpoint, and gain access. >>>>=20 >>>> One mitigation is to change the issuer, or audience. To me this is = undesirable as the events (e.g. logout) do relate to the same issuer and = audience. Like matter and anti-matter, yin and yang =E2=80=93 logout = should simply reverse the login. It seems wasteful to spin up a new = issuer, new key rotations, and more just to manage each different type = of event, if they would otherwise be related by issuer. >>>>=20 >>>> Currently the Backchannel Logout draft = attempts = to "break" this utility of a logout JWT for authentication by = prohibiting the 'nonce' field: >>>> The following Claim MUST NOT be used within the Logout Token: >>>>=20 >>>>=20 >>>> nonce >>>> PROHIBITED. A nonce Claim MUST NOT be present. Its use is = prohibited to make a Logout Token syntactically invalid if used in a = forged Authentication Response in place of an ID Token. >>>>=20 >>>> I'm concerned that this may not always work as intended, as 'nonce' = is not a required field of the ID Token. ID Tokens obtained from Google = using the code flow (on our OpenID Connect certified endpoints) do not = contain 'nonce' today, for example. And I'm a little worried that RPs = may not be strictly checking for a 'nonce', even when they should (e.g. = when using the implicit flow). >>>>=20 >>>> Even if this approach works in this specific case, it's not = scalable. So I propose that we move to adopt a new standard claim that = can be used to indicate the intended purpose of the JWT. >>>>=20 >>>> 'typ' is an obvious choice for a claim name, although the word = 'type' may be a little overloaded already. Another option could be "cat" = for category. Whatever we decide, I think such a claim should be used = in all JWT specs going forward, and added to OpenID Connect ID Tokens in = a future revision. >>>>=20 >>>> William >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> Id-event mailing list >>>> Id-event@ietf.org >>>> https://www.ietf.org/mailman/listinfo/id-event = >>>=20 >>> _______________________________________________ >>> Id-event mailing list >>> Id-event@ietf.org >>> https://www.ietf.org/mailman/listinfo/id-event = >>=20 >=20 --Apple-Mail=_4E5E8DF2-6C79-4525-94C3-1E23A4C499F4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Nonce is only required for tokens being delivered in the = front channel.   Saying don=E2=80=99t try to store it on the server = side to send as part of the backchannel logout where it makes no sense, = and that the client shouldn't look for it to verify, is reasonable. =   

I agree = that characterizing it as a way to keep a token from being accepted in = the implicit flow is probably confusing.

It is true that as it is now, a client = MUST not take a id_token in the front channel with a missing or invalid = nonce.   Unfortunately that may not be perfectly implemented in all = clients.

The = various possible distribution methods for these other sorts of tokens = may have different security characteristics and may not be kept = perfectly secret via a hub etc.

Those tokens should not be accepted in = the front channel no matter what there claims as long as the client = implements nonce correctly.

John B.


On Nov 4, 2015, at 4:24 PM, Justin Richer <jricher@mit.edu> = wrote:

I=E2=80=99m = very much in favor of having a JWT token type key, but for other reasons = and uses. 

I=E2=80= =99m just taking issue with the assertion that a logout token could be = easily confused by a functioning OIDC client.

Even then I think it=E2=80=99s a good = idea to have a =E2=80=9Ctyp": =E2=80=9Clogout=E2=80=9D tag in it. The = current guideline to take the =E2=80=9Cnonce=E2=80=9D out is a = profoundly stupid hack that=E2=80=99s not likely to make much difference = in the real world, or at least even less of a difference than a type = parameter.

Along= those lines, I=E2=80=99d suggest we use =E2=80=9Cjtt" or =E2=80=9CJSON = (web) Token Type=E2=80=9D as the field name, so we don=E2=80=99t cause = confusion with the header =E2=80=9Ctyp=E2=80=9D parameter.

 =E2=80=94 = Justin

On Nov 4, 2015, at 4:06 PM, = John Bradley <ve7jtb@ve7jtb.com> wrote:

In principal a = client gets a token two ways.  
1 via a token = endpoint in a direct communication.
2 via the = authorization endpoint, In this case a client needs to check the nonce = value to correlate the token with the user agent that the request was = made via.

I = think it is fair not to have a nonce in the other tokens as they are not = requested via the browser.  Nonce would also not be appropriate for = a JWT assertion.

I would be more worried about other sorts of assertions being = confused, or at-least not easily differentiated. 

I don=E2=80=99t think = having a explicit JWT token type being a bad thing.   Adding it = would not disrupt existing clients.  

I think it is more a case of = determining if this will be useful for other things.   In connect = it would really only help badly coded clients who are unlikely to check = it anyway.

John = B.

On Nov 4, 2015, at 2:36 PM, = Justin Richer <jricher@mit.edu> wrote:

I think a real = question with regard to the login/logout case is, succinctly, =E2=80=9CWhy= is an application accepting an ID token from an unknown third-party as = proof of login=E2=80=9D? In the normal OIDC process, the client will = only get the ID token in response to an authentication request, so it = shouldn=E2=80=99t ever be just listening for incoming ID tokens.

 =E2=80=94 = Justin

On Nov 4, 2015, at 2:19 PM, = William Denniss <wdenniss@google.com> wrote:

Hi Everyone,

It was good talking to many of you at Yokohama earlier in the = week about using JWTs for event messages like Logout, Risk Signals, SCIM = profile updates and more. Thank you Phil for starting this conversation = and spinning up the list! We're all doing related things with events, = and it makes sense to collaborate and unify our approaches.

An issue with JWT reuse = currently is that ID Tokens are defined by OpenID Connect to require only a few standard= JWT claims, and the required claims are highly re-usable and = contain nothing that actually sets them apart as an "ID = Token".

The = risk of this is that a JWT for an event like logout can be a valid ID = Token for login.  An attacker in possession of a logout token could = replay it against a login endpoint, and gain access.

One mitigation is to = change the issuer, or audience. To me this is undesirable as the events = (e.g. logout) do relate to the same issuer and audience. Like matter and = anti-matter, yin and yang =E2=80=93 logout should simply reverse the = login.  It seems wasteful to spin up a new issuer, new key = rotations, and more just to manage each different type of event, if they = would otherwise be related by issuer.

Currently the Backchannel Logout draft attempts to "break" this utility = of a logout JWT for authentication by prohibiting the 'nonce' = field:

The following Claim MUST NOT be used within the Logout = Token:


nonce
PROHIBITED. A nonce Claim MUST NOT be = present. Its use is prohibited to make a Logout Token syntactically = invalid if used in a forged Authentication Response in place of an ID = Token.

I'm concerned = that this may not always work as intended, as 'nonce' is not a required = field of the ID Token. ID Tokens obtained from Google using the code = flow (on our OpenID Connect certified endpoints) do not contain 'nonce' = today, for example. And I'm a little worried that RPs may not be = strictly checking for a 'nonce', even when they should (e.g. when using = the implicit flow).

Even if this approach works in this specific case, it's not = scalable. So I propose that we move to adopt a new standard claim that = can be used to indicate the intended purpose of the JWT.

'typ' is an obvious = choice for a claim name, although the word 'type' may be a little = overloaded already. Another option could be "cat" for category.  = Whatever we decide, I think such a claim should be used in all JWT specs = going forward, and added to OpenID Connect ID Tokens in a future = revision.

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



= --Apple-Mail=_4E5E8DF2-6C79-4525-94C3-1E23A4C499F4-- From nobody Tue Nov 3 23:54:10 2015 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E94B1B2B07 for ; Tue, 3 Nov 2015 23:54:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r6DvkYZ6hM3Y for ; Tue, 3 Nov 2015 23:54:06 -0800 (PST) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (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 D23CD1B2B02 for ; Tue, 3 Nov 2015 23:54:05 -0800 (PST) Received: by qkcn129 with SMTP id n129so17225328qkc.1 for ; Tue, 03 Nov 2015 23:54:05 -0800 (PST) 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 :cc:content-type; bh=c4wHFY0Geb9zHXibxLN1t/ljuzRyH0ego0ZkcC6ksgc=; b=LuJ14uhmxZSValjuqe1QPed6OYeoMvfV/fbq67RikuyG6S8II9Pfmrti7rNsu9Yaml imMn6UjG4OzBrzPAGupSNw10VSxzfiak4XinHjRrpWwiz/pm50gCcwCtzj9y7VvSagSI 1ZE8mUEfBXpkCmoA2A4Is4G8hj7c0C+Yi/Y8MKxoj6dpbLIjXf+laWlHIKhxrshWcOyq mB885ZNvB2GC+mW3QT9E8uSOWlLt01rPeHURb6pKEC/Qs8yz4Bq3YRBd5Ot1IIAOJiGw AgtEJNmvin9NEmUSrSdKFOJIVa4RwibV87o700zT6W175z5SLHqWhalNgPoWdI8Qa3c0 PEhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=c4wHFY0Geb9zHXibxLN1t/ljuzRyH0ego0ZkcC6ksgc=; b=ZJVisM9oz65274vaFFuGQxndMe6basDRtMYXIOiUg2QJqPpCqve6Mi781ciEyDGt8g fG1lj22WWhnttKc0U3FF+45AjNqk/nfR5eMx7v6C/PxU7g6Kpu7SndrrbmJ6NfoYwWqh 6sx+QAarSjeCURpLiupCHv3M7e7Hfu+7uxSM1PSk6sgGxlOpl4rx5J+impNEzu+9gnfg nJtN/ti/afELXFP+mhgnbmWZpNOggWy3P6csS5rvt83FUKsKP2K/foGLXtPICr6bihu0 LV9Zv7hCFTXfIKnJrV8ZEZIoFjQx5kBTsz5yLZWGm0GMIHQa57peG6K92r/kGuLW7XEp FEOA== X-Gm-Message-State: ALoCoQmOpG9OKGMf+cJVJSbmwbhSpcL3Wd5072LVHWX4WKKvbpmuPsW2HOs/scA7/fmWY7+afe2m X-Received: by 10.55.20.4 with SMTP id e4mr72924qkh.61.1446623644928; Tue, 03 Nov 2015 23:54:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.102.18 with HTTP; Tue, 3 Nov 2015 23:53:45 -0800 (PST) In-Reply-To: <0EE00ED6-D344-4B92-9A05-8FFB7BCB6BF0@mit.edu> References: <7A2911BB-0B39-4A61-8767-6A0D24012363@mit.edu> <0EE00ED6-D344-4B92-9A05-8FFB7BCB6BF0@mit.edu> From: William Denniss Date: Wed, 4 Nov 2015 16:53:45 +0900 Message-ID: To: Justin Richer Content-Type: multipart/alternative; boundary=001a1144bc4a7afe410523b25004 Archived-At: Cc: John Bradley , id-event@ietf.org Subject: Re: [Id-event] Distinguishing different JWT types X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2015 07:54:08 -0000 --001a1144bc4a7afe410523b25004 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Fair points. My main concern is that we don't always know how people treat ID Tokens (or JWTs more generally), and one of their nice properties is that they are designed to be verifiable if transmitted over an untrusted medium. I think we can build in more protection going forward by having a clear type indicator. Imagine having 6 different JWT types, all potentially validating as the other types. It seems dangerous if the only protection is that they shouldn't be accepted outside their intended flows, and also downright confusing as they all look similar. Removing fields to break potential re-use doesn't scale, and doesn't help understandability either. On Wed, Nov 4, 2015 at 4:24 PM, Justin Richer wrote: > I=E2=80=99m very much in favor of having a JWT token type key, but for ot= her > reasons and uses. > > I=E2=80=99m just taking issue with the assertion that a logout token coul= d be > easily confused by a functioning OIDC client. > > Even then I think it=E2=80=99s a good idea to have a =E2=80=9Ctyp": =E2= =80=9Clogout=E2=80=9D tag in it. > The current guideline to take the =E2=80=9Cnonce=E2=80=9D out is a profou= ndly stupid hack > that=E2=80=99s not likely to make much difference in the real world, or a= t least > even less of a difference than a type parameter. > > Along those lines, I=E2=80=99d suggest we use =E2=80=9Cjtt" or =E2=80=9CJ= SON (web) Token Type=E2=80=9D as > the field name, so we don=E2=80=99t cause confusion with the header =E2= =80=9Ctyp=E2=80=9D parameter. > > =E2=80=94 Justin > > On Nov 4, 2015, at 4:06 PM, John Bradley wrote: > > In principal a client gets a token two ways. > 1 via a token endpoint in a direct communication. > 2 via the authorization endpoint, In this case a client needs to check th= e > nonce value to correlate the token with the user agent that the request w= as > made via. > > I think it is fair not to have a nonce in the other tokens as they are no= t > requested via the browser. Nonce would also not be appropriate for a JWT > assertion. > > I would be more worried about other sorts of assertions being confused, o= r > at-least not easily differentiated. > > I don=E2=80=99t think having a explicit JWT token type being a bad thing.= Adding > it would not disrupt existing clients. > > I think it is more a case of determining if this will be useful for other > things. In connect it would really only help badly coded clients who ar= e > unlikely to check it anyway. > > John B. > > On Nov 4, 2015, at 2:36 PM, Justin Richer wrote: > > I think a real question with regard to the login/logout case is, > succinctly, =E2=80=9CWhy is an application accepting an ID token from an = unknown > third-party as proof of login=E2=80=9D? In the normal OIDC process, the c= lient will > only get the ID token in response to an authentication request, so it > shouldn=E2=80=99t ever be just listening for incoming ID tokens. > > =E2=80=94 Justin > > On Nov 4, 2015, at 2:19 PM, William Denniss wrote: > > Hi Everyone, > > It was good talking to many of you at Yokohama earlier in the week about > using JWTs for event messages like Logout, Risk Signals, SCIM profile > updates and more. Thank you Phil for starting this conversation and > spinning up the list! We're all doing related things with events, and it > makes sense to collaborate and unify our approaches. > > An issue with JWT reuse currently is that ID Tokens are defined > by OpenID > Connect to require only a few standard JWT claims > , and the required claims > are highly re-usable and contain nothing that actually sets them apart as > an "ID Token". > > The risk of this is that a JWT for an event like logout can be a valid ID > Token for login. An attacker in possession of a logout token could repla= y > it against a login endpoint, and gain access. > > One mitigation is to change the issuer, or audience. To me this is > undesirable as the events (e.g. logout) do relate to the same issuer and > audience. Like matter and anti-matter, yin and yang =E2=80=93 logout shou= ld simply > reverse the login. It seems wasteful to spin up a new issuer, new key > rotations, and more just to manage each different type of event, if they > would otherwise be related by issuer. > > Currently the Backchannel Logout draft > attempts to > "break" this utility of a logout JWT for authentication by prohibiting > the 'nonce' field: > > The following Claim MUST NOT be used within the Logout Token: > > noncePROHIBITED. A nonce Claim MUST NOT be present. Its use is prohibited > to make a Logout Token syntactically invalid if used in a forged > Authentication Response in place of an ID Token. > > I'm concerned that this may not always work as intended, as 'nonce' is no= t > a required field of the ID Token. ID Tokens obtained from Google using th= e > code flow (on our OpenID Connect certified endpoints) do not contain > 'nonce' today, for example. And I'm a little worried that RPs may not be > strictly checking for a 'nonce', even when they should (e.g. when using t= he > implicit flow). > > Even if this approach works in this specific case, it's not scalable. So = I > propose that we move to adopt a new standard claim that can be used to > indicate the intended purpose of the JWT. > > 'typ' is an obvious choice for a claim name, although the word 'type' may > be a little overloaded already. Another option could be "cat" for > category. Whatever we decide, I think such a claim should be used in all > JWT specs going forward, and added to OpenID Connect ID Tokens in a futur= e > revision. > > 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 > > > > --001a1144bc4a7afe410523b25004 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Fair points. My main concern is that we don't alw= ays know how people treat ID Tokens (or JWTs more generally), and one of th= eir nice properties is that they are designed to be verifiable if transmitt= ed over an untrusted medium.

I think we can build = in more protection going forward by having a clear type indicator. Imagine = having 6 different JWT types, all potentially validating as the other types= . It seems dangerous if the only protection is that they shouldn't be a= ccepted outside their intended flows, and also downright confusing as they = all look similar.

Removing fields to break potenti= al re-use doesn't scale, and doesn't help understandability either.=


On Wed, Nov 4, 2015 at 4:24 PM, Justin Richer &= lt;jricher@mit.edu= > wrote:
I=E2=80=99m very much in favor of having a JWT token type key= , but for other reasons and uses.=C2=A0

I=E2=80=99m just= taking issue with the assertion that a logout token could be easily confus= ed by a functioning OIDC client.

Even then I think it=E2= =80=99s a good idea to have a =E2=80=9Ctyp": =E2=80=9Clogout=E2=80=9D = tag in it. The current guideline to take the =E2=80=9Cnonce=E2=80=9D out is= a profoundly stupid hack that=E2=80=99s not likely to make much difference= in the real world, or at least even less of a difference than a type param= eter.

Along those lines, I=E2=80=99d suggest we us= e =E2=80=9Cjtt" or =E2=80=9CJSON (web) Token Type=E2=80=9D as the fiel= d name, so we don=E2=80=99t cause confusion with the header =E2=80=9Ctyp=E2= =80=9D parameter.
=
=C2=A0=E2=80=94 Justin

On Nov 4, 2015, at 4:06 P= M, John Bradley <= ve7jtb@ve7jtb.com> wrote:

In principal a client gets a token two = ways. =C2=A0
1 via a token endpoint in a direct communication.
2 via the authorization endpoint, In this case a client needs to check th= e nonce value to correlate the token with the user agent that the request w= as made via.

I think it is fair not to have a nonc= e in the other tokens as they are not requested via the browser.=C2=A0 Nonc= e would also not be appropriate for a JWT assertion.

I would be more worried about other sorts of assertions being confused, = or at-least not easily differentiated.=C2=A0

I don= =E2=80=99t think having a explicit JWT token type being a bad thing. =C2=A0= Adding it would not disrupt existing clients. =C2=A0

<= div>I think it is more a case of determining if this will be useful for oth= er things. =C2=A0 In connect it would really only help badly coded clients = who are unlikely to check it anyway.

John B.
=

On Nov 4, 2015, at 2:36 PM, Ju= stin Richer <jriche= r@mit.edu> wrote:

= I think a real question with regard to the login/logout case is, succinctly= , =E2=80=9CWhy is an application accepting an ID token from an unknown thir= d-party as proof of login=E2=80=9D? In the normal OIDC process, the client = will only get the ID token in response to an authentication request, so it = shouldn=E2=80=99t ever be just listening for incoming ID tokens.

=C2=A0=E2=80=94 Justin

On Nov 4, 2015, at 2:19 PM, William Denniss <wdenniss@google.com> wrote:
Hi Everyone,

It was good tal= king to many of you at Yokohama earlier in the week about using JWTs for ev= ent messages like Logout, Risk Signals, SCIM profile updates and more. Than= k you Phil for starting this conversation and spinning up the list! We'= re all doing related things with events, and it makes sense to collaborate = and unify our approaches.

An issue with JWT reuse = currently is that ID Tokens are defined=C2=A0by OpenID = Connect to require only a few standard JWT claims, and the required cl= aims are highly re-usable and contain nothing that actually sets them apart= as an "ID Token".

The risk of this is t= hat a JWT for an event like logout can be a valid ID Token for login.=C2=A0= An attacker in possession of a logout token could replay it against a logi= n endpoint, and gain access.

One mitigation is to = change the issuer, or audience. To me this is undesirable as the events (e.= g. logout) do relate to the same issuer and audience. Like matter and anti-= matter, yin and yang =E2=80=93 logout should simply reverse the login.=C2= =A0 It seems wasteful to spin up a new issuer, new key rotations, and more = just to manage each different type of event, if they would otherwise be rel= ated by issuer.

Currently the Backc= hannel Logout draft attempts to "break" this utility of a log= out JWT for authentication by prohibiting the=C2=A0'nonce' field:

The following Claim MUST NOT be used within th= e Logout Token:


nonce<= /dt>
PROHIBITED. A=C2=A0nonce=C2=A0Claim MUST NOT be pre= sent. Its use is prohibited to make a Logout Token syntactically invalid if= used in a forged Authentication Response in place of an ID Token.

I'm concerned that this may not= always work as intended, as 'nonce' is not a required field of the= ID Token. ID Tokens obtained from Google using the code flow (on our OpenI= D Connect certified endpoints) do not contain 'nonce' today, for ex= ample. And I'm a little worried that RPs may not be strictly checking f= or a 'nonce', even when they should (e.g. when using the implicit f= low).

Even if this approach works in this specific= case, it's not scalable. So I propose that we move to adopt a new stan= dard claim that can be used to indicate the intended purpose of the JWT.

'typ' is an obvious choice for a claim name,= although the word 'type' may be a little overloaded already. Anoth= er option could be "cat" for category.=C2=A0 Whatever we decide, = I think such a claim should be used in all JWT specs going forward, and add= ed to OpenID Connect ID Tokens in a future revision.

William



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

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

=

--001a1144bc4a7afe410523b25004-- From nobody Wed Nov 4 00:04:49 2015 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 295DD1B2B56 for ; Wed, 4 Nov 2015 00:04:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nbZ2ZKtWBNhz for ; Wed, 4 Nov 2015 00:04:44 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0140.outbound.protection.outlook.com [207.46.100.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 616DE1B2B41 for ; Wed, 4 Nov 2015 00:04:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Tqo9PSO4dyvyU4Krtyolc5bUtZUlSrrGfiXKeSQcZyg=; b=E94Eq2GNa+04+rHTVplTpzmBHp4o6sVBJU4WlmYAdJ4xhIuvfdWL9tamyYQXsHcuBEwA5lsTttHBqvkd6xbR7uuZJ6YX7ihf0RabEErcePBV7yHVhKBly5lT4oTRJXFwOViCKH9p8cIoJf+HLSnrhgdqHf6UWOztZCpOm0NS7Fs= Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB441.namprd03.prod.outlook.com (10.141.141.142) with Microsoft SMTP Server (TLS) id 15.1.312.18; Wed, 4 Nov 2015 08:04:39 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0318.003; Wed, 4 Nov 2015 08:04:39 +0000 From: Mike Jones To: William Denniss , Justin Richer Thread-Topic: [Id-event] Distinguishing different JWT types Thread-Index: AQHRFsBg3BNM3t3kCUixIip7hsf4KJ6LWBMAgAAY9ICAAAVAAIAACBSAgAAAgnA= Date: Wed, 4 Nov 2015 08:04:38 +0000 Message-ID: References: <7A2911BB-0B39-4A61-8767-6A0D24012363@mit.edu> <0EE00ED6-D344-4B92-9A05-8FFB7BCB6BF0@mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [2001:c40:0:3032:91d0:60c:fcfc:5727] x-microsoft-exchange-diagnostics: 1; BY2PR03MB441; 5:+n7wdWZxCTyZjUrdv2hpJz5SLg6gSsfLs9IfsOghRqHpTyum8UZfqH2f23I0PelD+B40+b7ljwp2ef8zscPDyyOQM5047EujyyulYQePdqYNjGHnPocWOBctCxivP/+qgJoa9VaIRvI+i2XYS62xUw==; 24:6mDDi56weqh4H3PmZXRwcVMuAUZ8jD4KuVSCk7aSZzX78TTQb2lvC14+v63RbZtA2JP8zoqbWVaPp89QOsX3YT5WP8vR3FcID09eUC68g4Y=; 20:y4KUS3LdDA2Ak3THmfzuoKPiIytU6644OsAEOZr4sO1RBb6lIjPmAQfdR7HJbGa+FJJLv0lBZiBMVdjDA/qOXQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB441; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(240460790083961)(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425024)(601004)(2401047)(520078)(5005006)(8121501046)(3002001)(10201501046)(61426024)(61427024); SRVR:BY2PR03MB441; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB441; x-forefront-prvs: 0750463DC9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(53754006)(24454002)(189002)(377454003)(199003)(122556002)(40100003)(5004730100002)(76576001)(5007970100001)(81156007)(15975445007)(8990500004)(5005710100001)(10400500002)(10290500002)(102836002)(2950100001)(5001770100001)(2900100001)(97736004)(99286002)(77096005)(106356001)(105586002)(106116001)(74316001)(5002640100001)(87936001)(19609705001)(19625215002)(19580405001)(93886004)(5001960100002)(92566002)(189998001)(5003600100002)(19617315012)(10090500001)(86612001)(2171001)(5008740100001)(86362001)(33656002)(11100500001)(19580395003)(19300405004)(54356999)(15395725005)(101416001)(76176999)(50986999)(16236675004)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB441; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR03MB442BBC876D242428FFB244AF52A0BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Nov 2015 08:04:38.4633 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB441 Archived-At: Cc: John Bradley , "id-event@ietf.org" Subject: Re: [Id-event] Distinguishing different JWT types X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2015 08:04:48 -0000 --_000_BY2PR03MB442BBC876D242428FFB244AF52A0BY2PR03MB442namprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIHBhcnQgb2YgdGhpcyB0aHJlYWQgZGVhbGluZyB3aXRoIGxvZ291dCBzaG91bGQgaGF2ZSBp bmNsdWRlZCBhIHJlZmVyZW5jZSB0byB0aGlzIHRleHQgaW4gaHR0cDovL29wZW5pZC5uZXQvc3Bl Y3Mvb3BlbmlkLWNvbm5lY3QtYmFja2NoYW5uZWwtMV8wLTAxLmh0bWwjTG9nb3V0VG9rZW46DQoN CmxvZ291dF9vbmx5DQpSRVFVSVJFRC4gVmFsdWUgZGVjbGFyaW5nIHRoYXQgdGhpcyBKV1QgaXMg b25seSB0byBiZSB1c2VkIGFzIGEgTG9nb3V0IFRva2VuLiBJbiBwYXJ0aWN1bGFyLCB0aGlzIEpX VCBjYW5ub3QgYmUgdXNlZCBpbiBhbnkgY29udGV4dCB3aGVyZSBhbiBJRCBUb2tlbiBpcyB1c2Vk LiBUaGUgdmFsdWUgb2YgdGhpcyBDbGFpbSBNVVNUIGJlIHRoZSBKU09OIGJvb2xlYW4gdmFsdWUg dHJ1ZS4NCg0KVGhpcyBjbGFpbSBpcyBjdXJyZW50bHkgdXNlZCB0byDigJx0eXBl4oCdIHRoZSBs b2dvdXQgdG9rZW4uICBDaGFuZ2luZyBmcm9tIOKAnGxvZ291dF9vbmx54oCdOnRydWUgdG8g4oCc anR54oCdOiDigJxsb2dvdXTigJ0gb3Igc29tZXRoaW5nIHNpbWlsYXIgd291bGQgYmUgZmluZS4N Cg0KSm9obiBzdWdnZXN0ZWQgdGhhdCB3ZSBwcm9oaWJpdCB0aGUgaW5jbHVzaW9uIG9mIOKAnG5v bmNl4oCdIGFzIGEgc2Vjb25kIHdheSBvZiBlbnN1cmluZyB0aGF0IHRoYXQgdG9rZW4gY291bGRu 4oCZdCBiZSByZXB1cnBvc2VkIGFzIGFuIElEIFRva2VuLiAgVGhhdCB3b3VsZCB3b3JrIGV2ZW4g aWYgdGhlIGNvZGUgd2FzbuKAmXQgY2hlY2tpbmcgZm9yIOKAnGxvZ291dF9vbmx54oCdIG9yIOKA nGp0eeKAnS4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBJZC1ldmVudCBbbWFpbHRvOmlkLWV2ZW50 LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBXaWxsaWFtIERlbm5pc3MNClNlbnQ6IFdl ZG5lc2RheSwgTm92ZW1iZXIgMDQsIDIwMTUgNDo1NCBQTQ0KVG86IEp1c3RpbiBSaWNoZXINCkNj OiBKb2huIEJyYWRsZXk7IGlkLWV2ZW50QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0lkLWV2ZW50 XSBEaXN0aW5ndWlzaGluZyBkaWZmZXJlbnQgSldUIHR5cGVzDQoNCkZhaXIgcG9pbnRzLiBNeSBt YWluIGNvbmNlcm4gaXMgdGhhdCB3ZSBkb24ndCBhbHdheXMga25vdyBob3cgcGVvcGxlIHRyZWF0 IElEIFRva2VucyAob3IgSldUcyBtb3JlIGdlbmVyYWxseSksIGFuZCBvbmUgb2YgdGhlaXIgbmlj ZSBwcm9wZXJ0aWVzIGlzIHRoYXQgdGhleSBhcmUgZGVzaWduZWQgdG8gYmUgdmVyaWZpYWJsZSBp ZiB0cmFuc21pdHRlZCBvdmVyIGFuIHVudHJ1c3RlZCBtZWRpdW0uDQoNCkkgdGhpbmsgd2UgY2Fu IGJ1aWxkIGluIG1vcmUgcHJvdGVjdGlvbiBnb2luZyBmb3J3YXJkIGJ5IGhhdmluZyBhIGNsZWFy IHR5cGUgaW5kaWNhdG9yLiBJbWFnaW5lIGhhdmluZyA2IGRpZmZlcmVudCBKV1QgdHlwZXMsIGFs bCBwb3RlbnRpYWxseSB2YWxpZGF0aW5nIGFzIHRoZSBvdGhlciB0eXBlcy4gSXQgc2VlbXMgZGFu Z2Vyb3VzIGlmIHRoZSBvbmx5IHByb3RlY3Rpb24gaXMgdGhhdCB0aGV5IHNob3VsZG4ndCBiZSBh Y2NlcHRlZCBvdXRzaWRlIHRoZWlyIGludGVuZGVkIGZsb3dzLCBhbmQgYWxzbyBkb3ducmlnaHQg Y29uZnVzaW5nIGFzIHRoZXkgYWxsIGxvb2sgc2ltaWxhci4NCg0KUmVtb3ZpbmcgZmllbGRzIHRv IGJyZWFrIHBvdGVudGlhbCByZS11c2UgZG9lc24ndCBzY2FsZSwgYW5kIGRvZXNuJ3QgaGVscCB1 bmRlcnN0YW5kYWJpbGl0eSBlaXRoZXIuDQoNCg0KT24gV2VkLCBOb3YgNCwgMjAxNSBhdCA0OjI0 IFBNLCBKdXN0aW4gUmljaGVyIDxqcmljaGVyQG1pdC5lZHU8bWFpbHRvOmpyaWNoZXJAbWl0LmVk dT4+IHdyb3RlOg0KSeKAmW0gdmVyeSBtdWNoIGluIGZhdm9yIG9mIGhhdmluZyBhIEpXVCB0b2tl biB0eXBlIGtleSwgYnV0IGZvciBvdGhlciByZWFzb25zIGFuZCB1c2VzLg0KDQpJ4oCZbSBqdXN0 IHRha2luZyBpc3N1ZSB3aXRoIHRoZSBhc3NlcnRpb24gdGhhdCBhIGxvZ291dCB0b2tlbiBjb3Vs ZCBiZSBlYXNpbHkgY29uZnVzZWQgYnkgYSBmdW5jdGlvbmluZyBPSURDIGNsaWVudC4NCg0KRXZl biB0aGVuIEkgdGhpbmsgaXTigJlzIGEgZ29vZCBpZGVhIHRvIGhhdmUgYSDigJx0eXAiOiDigJxs b2dvdXTigJ0gdGFnIGluIGl0LiBUaGUgY3VycmVudCBndWlkZWxpbmUgdG8gdGFrZSB0aGUg4oCc bm9uY2XigJ0gb3V0IGlzIGEgcHJvZm91bmRseSBzdHVwaWQgaGFjayB0aGF04oCZcyBub3QgbGlr ZWx5IHRvIG1ha2UgbXVjaCBkaWZmZXJlbmNlIGluIHRoZSByZWFsIHdvcmxkLCBvciBhdCBsZWFz dCBldmVuIGxlc3Mgb2YgYSBkaWZmZXJlbmNlIHRoYW4gYSB0eXBlIHBhcmFtZXRlci4NCg0KQWxv bmcgdGhvc2UgbGluZXMsIEnigJlkIHN1Z2dlc3Qgd2UgdXNlIOKAnGp0dCIgb3Ig4oCcSlNPTiAo d2ViKSBUb2tlbiBUeXBl4oCdIGFzIHRoZSBmaWVsZCBuYW1lLCBzbyB3ZSBkb27igJl0IGNhdXNl IGNvbmZ1c2lvbiB3aXRoIHRoZSBoZWFkZXIg4oCcdHlw4oCdIHBhcmFtZXRlci4NCg0KIOKAlCBK dXN0aW4NCg0KT24gTm92IDQsIDIwMTUsIGF0IDQ6MDYgUE0sIEpvaG4gQnJhZGxleSA8dmU3anRi QHZlN2p0Yi5jb208bWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29tPj4gd3JvdGU6DQoNCkluIHByaW5j aXBhbCBhIGNsaWVudCBnZXRzIGEgdG9rZW4gdHdvIHdheXMuDQoxIHZpYSBhIHRva2VuIGVuZHBv aW50IGluIGEgZGlyZWN0IGNvbW11bmljYXRpb24uDQoyIHZpYSB0aGUgYXV0aG9yaXphdGlvbiBl bmRwb2ludCwgSW4gdGhpcyBjYXNlIGEgY2xpZW50IG5lZWRzIHRvIGNoZWNrIHRoZSBub25jZSB2 YWx1ZSB0byBjb3JyZWxhdGUgdGhlIHRva2VuIHdpdGggdGhlIHVzZXIgYWdlbnQgdGhhdCB0aGUg cmVxdWVzdCB3YXMgbWFkZSB2aWEuDQoNCkkgdGhpbmsgaXQgaXMgZmFpciBub3QgdG8gaGF2ZSBh IG5vbmNlIGluIHRoZSBvdGhlciB0b2tlbnMgYXMgdGhleSBhcmUgbm90IHJlcXVlc3RlZCB2aWEg dGhlIGJyb3dzZXIuICBOb25jZSB3b3VsZCBhbHNvIG5vdCBiZSBhcHByb3ByaWF0ZSBmb3IgYSBK V1QgYXNzZXJ0aW9uLg0KDQpJIHdvdWxkIGJlIG1vcmUgd29ycmllZCBhYm91dCBvdGhlciBzb3J0 cyBvZiBhc3NlcnRpb25zIGJlaW5nIGNvbmZ1c2VkLCBvciBhdC1sZWFzdCBub3QgZWFzaWx5IGRp ZmZlcmVudGlhdGVkLg0KDQpJIGRvbuKAmXQgdGhpbmsgaGF2aW5nIGEgZXhwbGljaXQgSldUIHRv a2VuIHR5cGUgYmVpbmcgYSBiYWQgdGhpbmcuICAgQWRkaW5nIGl0IHdvdWxkIG5vdCBkaXNydXB0 IGV4aXN0aW5nIGNsaWVudHMuDQoNCkkgdGhpbmsgaXQgaXMgbW9yZSBhIGNhc2Ugb2YgZGV0ZXJt aW5pbmcgaWYgdGhpcyB3aWxsIGJlIHVzZWZ1bCBmb3Igb3RoZXIgdGhpbmdzLiAgIEluIGNvbm5l Y3QgaXQgd291bGQgcmVhbGx5IG9ubHkgaGVscCBiYWRseSBjb2RlZCBjbGllbnRzIHdobyBhcmUg dW5saWtlbHkgdG8gY2hlY2sgaXQgYW55d2F5Lg0KDQpKb2huIEIuDQoNCk9uIE5vdiA0LCAyMDE1 LCBhdCAyOjM2IFBNLCBKdXN0aW4gUmljaGVyIDxqcmljaGVyQG1pdC5lZHU8bWFpbHRvOmpyaWNo ZXJAbWl0LmVkdT4+IHdyb3RlOg0KDQpJIHRoaW5rIGEgcmVhbCBxdWVzdGlvbiB3aXRoIHJlZ2Fy ZCB0byB0aGUgbG9naW4vbG9nb3V0IGNhc2UgaXMsIHN1Y2NpbmN0bHksIOKAnFdoeSBpcyBhbiBh cHBsaWNhdGlvbiBhY2NlcHRpbmcgYW4gSUQgdG9rZW4gZnJvbSBhbiB1bmtub3duIHRoaXJkLXBh cnR5IGFzIHByb29mIG9mIGxvZ2lu4oCdPyBJbiB0aGUgbm9ybWFsIE9JREMgcHJvY2VzcywgdGhl IGNsaWVudCB3aWxsIG9ubHkgZ2V0IHRoZSBJRCB0b2tlbiBpbiByZXNwb25zZSB0byBhbiBhdXRo ZW50aWNhdGlvbiByZXF1ZXN0LCBzbyBpdCBzaG91bGRu4oCZdCBldmVyIGJlIGp1c3QgbGlzdGVu aW5nIGZvciBpbmNvbWluZyBJRCB0b2tlbnMuDQoNCiDigJQgSnVzdGluDQoNCk9uIE5vdiA0LCAy MDE1LCBhdCAyOjE5IFBNLCBXaWxsaWFtIERlbm5pc3MgPHdkZW5uaXNzQGdvb2dsZS5jb208bWFp bHRvOndkZW5uaXNzQGdvb2dsZS5jb20+PiB3cm90ZToNCg0KSGkgRXZlcnlvbmUsDQoNCkl0IHdh cyBnb29kIHRhbGtpbmcgdG8gbWFueSBvZiB5b3UgYXQgWW9rb2hhbWEgZWFybGllciBpbiB0aGUg d2VlayBhYm91dCB1c2luZyBKV1RzIGZvciBldmVudCBtZXNzYWdlcyBsaWtlIExvZ291dCwgUmlz ayBTaWduYWxzLCBTQ0lNIHByb2ZpbGUgdXBkYXRlcyBhbmQgbW9yZS4gVGhhbmsgeW91IFBoaWwg Zm9yIHN0YXJ0aW5nIHRoaXMgY29udmVyc2F0aW9uIGFuZCBzcGlubmluZyB1cCB0aGUgbGlzdCEg V2UncmUgYWxsIGRvaW5nIHJlbGF0ZWQgdGhpbmdzIHdpdGggZXZlbnRzLCBhbmQgaXQgbWFrZXMg c2Vuc2UgdG8gY29sbGFib3JhdGUgYW5kIHVuaWZ5IG91ciBhcHByb2FjaGVzLg0KDQpBbiBpc3N1 ZSB3aXRoIEpXVCByZXVzZSBjdXJyZW50bHkgaXMgdGhhdCBJRCBUb2tlbnMgYXJlIGRlZmluZWQ8 aHR0cDovL29wZW5pZC5uZXQvc3BlY3Mvb3BlbmlkLWNvbm5lY3QtY29yZS0xXzAuaHRtbCNJRFRv a2VuPiBieSBPcGVuSUQgQ29ubmVjdCB0byByZXF1aXJlIG9ubHkgYSBmZXcgc3RhbmRhcmQgSldU IGNsYWltczxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzUxOSNzZWN0aW9uLTQ+LCBh bmQgdGhlIHJlcXVpcmVkIGNsYWltcyBhcmUgaGlnaGx5IHJlLXVzYWJsZSBhbmQgY29udGFpbiBu b3RoaW5nIHRoYXQgYWN0dWFsbHkgc2V0cyB0aGVtIGFwYXJ0IGFzIGFuICJJRCBUb2tlbiIuDQoN ClRoZSByaXNrIG9mIHRoaXMgaXMgdGhhdCBhIEpXVCBmb3IgYW4gZXZlbnQgbGlrZSBsb2dvdXQg Y2FuIGJlIGEgdmFsaWQgSUQgVG9rZW4gZm9yIGxvZ2luLiAgQW4gYXR0YWNrZXIgaW4gcG9zc2Vz c2lvbiBvZiBhIGxvZ291dCB0b2tlbiBjb3VsZCByZXBsYXkgaXQgYWdhaW5zdCBhIGxvZ2luIGVu ZHBvaW50LCBhbmQgZ2FpbiBhY2Nlc3MuDQoNCk9uZSBtaXRpZ2F0aW9uIGlzIHRvIGNoYW5nZSB0 aGUgaXNzdWVyLCBvciBhdWRpZW5jZS4gVG8gbWUgdGhpcyBpcyB1bmRlc2lyYWJsZSBhcyB0aGUg ZXZlbnRzIChlLmcuIGxvZ291dCkgZG8gcmVsYXRlIHRvIHRoZSBzYW1lIGlzc3VlciBhbmQgYXVk aWVuY2UuIExpa2UgbWF0dGVyIGFuZCBhbnRpLW1hdHRlciwgeWluIGFuZCB5YW5nIOKAkyBsb2dv dXQgc2hvdWxkIHNpbXBseSByZXZlcnNlIHRoZSBsb2dpbi4gIEl0IHNlZW1zIHdhc3RlZnVsIHRv IHNwaW4gdXAgYSBuZXcgaXNzdWVyLCBuZXcga2V5IHJvdGF0aW9ucywgYW5kIG1vcmUganVzdCB0 byBtYW5hZ2UgZWFjaCBkaWZmZXJlbnQgdHlwZSBvZiBldmVudCwgaWYgdGhleSB3b3VsZCBvdGhl cndpc2UgYmUgcmVsYXRlZCBieSBpc3N1ZXIuDQoNCkN1cnJlbnRseSB0aGUgQmFja2NoYW5uZWwg TG9nb3V0IGRyYWZ0PGh0dHA6Ly9vcGVuaWQubmV0L3NwZWNzL29wZW5pZC1jb25uZWN0LWJhY2tj aGFubmVsLTFfMC5odG1sPiBhdHRlbXB0cyB0byAiYnJlYWsiIHRoaXMgdXRpbGl0eSBvZiBhIGxv Z291dCBKV1QgZm9yIGF1dGhlbnRpY2F0aW9uIGJ5IHByb2hpYml0aW5nIHRoZSAnbm9uY2UnIGZp ZWxkOg0KDQpUaGUgZm9sbG93aW5nIENsYWltIE1VU1QgTk9UIGJlIHVzZWQgd2l0aGluIHRoZSBM b2dvdXQgVG9rZW46DQoNCm5vbmNlDQpQUk9ISUJJVEVELiBBIG5vbmNlIENsYWltIE1VU1QgTk9U IGJlIHByZXNlbnQuIEl0cyB1c2UgaXMgcHJvaGliaXRlZCB0byBtYWtlIGEgTG9nb3V0IFRva2Vu IHN5bnRhY3RpY2FsbHkgaW52YWxpZCBpZiB1c2VkIGluIGEgZm9yZ2VkIEF1dGhlbnRpY2F0aW9u IFJlc3BvbnNlIGluIHBsYWNlIG9mIGFuIElEIFRva2VuLg0KDQpJJ20gY29uY2VybmVkIHRoYXQg dGhpcyBtYXkgbm90IGFsd2F5cyB3b3JrIGFzIGludGVuZGVkLCBhcyAnbm9uY2UnIGlzIG5vdCBh IHJlcXVpcmVkIGZpZWxkIG9mIHRoZSBJRCBUb2tlbi4gSUQgVG9rZW5zIG9idGFpbmVkIGZyb20g R29vZ2xlIHVzaW5nIHRoZSBjb2RlIGZsb3cgKG9uIG91ciBPcGVuSUQgQ29ubmVjdCBjZXJ0aWZp ZWQgZW5kcG9pbnRzKSBkbyBub3QgY29udGFpbiAnbm9uY2UnIHRvZGF5LCBmb3IgZXhhbXBsZS4g QW5kIEknbSBhIGxpdHRsZSB3b3JyaWVkIHRoYXQgUlBzIG1heSBub3QgYmUgc3RyaWN0bHkgY2hl Y2tpbmcgZm9yIGEgJ25vbmNlJywgZXZlbiB3aGVuIHRoZXkgc2hvdWxkIChlLmcuIHdoZW4gdXNp bmcgdGhlIGltcGxpY2l0IGZsb3cpLg0KDQpFdmVuIGlmIHRoaXMgYXBwcm9hY2ggd29ya3MgaW4g dGhpcyBzcGVjaWZpYyBjYXNlLCBpdCdzIG5vdCBzY2FsYWJsZS4gU28gSSBwcm9wb3NlIHRoYXQg d2UgbW92ZSB0byBhZG9wdCBhIG5ldyBzdGFuZGFyZCBjbGFpbSB0aGF0IGNhbiBiZSB1c2VkIHRv IGluZGljYXRlIHRoZSBpbnRlbmRlZCBwdXJwb3NlIG9mIHRoZSBKV1QuDQoNCid0eXAnIGlzIGFu IG9idmlvdXMgY2hvaWNlIGZvciBhIGNsYWltIG5hbWUsIGFsdGhvdWdoIHRoZSB3b3JkICd0eXBl JyBtYXkgYmUgYSBsaXR0bGUgb3ZlcmxvYWRlZCBhbHJlYWR5LiBBbm90aGVyIG9wdGlvbiBjb3Vs ZCBiZSAiY2F0IiBmb3IgY2F0ZWdvcnkuICBXaGF0ZXZlciB3ZSBkZWNpZGUsIEkgdGhpbmsgc3Vj aCBhIGNsYWltIHNob3VsZCBiZSB1c2VkIGluIGFsbCBKV1Qgc3BlY3MgZ29pbmcgZm9yd2FyZCwg YW5kIGFkZGVkIHRvIE9wZW5JRCBDb25uZWN0IElEIFRva2VucyBpbiBhIGZ1dHVyZSByZXZpc2lv bi4NCg0KV2lsbGlhbQ0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCklkLWV2ZW50IG1haWxpbmcgbGlzdA0KSWQtZXZlbnRAaWV0Zi5vcmc8bWFp bHRvOklkLWV2ZW50QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9pZC1ldmVudA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KSWQtZXZlbnQgbWFpbGluZyBsaXN0DQpJZC1ldmVudEBpZXRmLm9yZzxtYWlsdG86 SWQtZXZlbnRAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2lkLWV2ZW50DQoNCg0KDQo= --_000_BY2PR03MB442BBC876D242428FFB244AF52A0BY2PR03MB442namprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDE0IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7 DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpWZXJkYW5hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0 O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBk aXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZv bnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0K CW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KdHQN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0K c3Bhbi5ob2VuemINCgl7bXNvLXN0eWxlLW5hbWU6aG9lbnpiO30NCnNwYW4uRW1haWxTdHlsZTIw DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzAwMjA2MDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46 MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+ PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxp bms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDIwNjAiPlRoZSBwYXJ0 IG9mIHRoaXMgdGhyZWFkIGRlYWxpbmcgd2l0aCBsb2dvdXQgc2hvdWxkIGhhdmUgaW5jbHVkZWQg YSByZWZlcmVuY2UgdG8gdGhpcyB0ZXh0IGluDQo8YSBocmVmPSJodHRwOi8vb3BlbmlkLm5ldC9z cGVjcy9vcGVuaWQtY29ubmVjdC1iYWNrY2hhbm5lbC0xXzAtMDEuaHRtbCNMb2dvdXRUb2tlbiI+ DQpodHRwOi8vb3BlbmlkLm5ldC9zcGVjcy9vcGVuaWQtY29ubmVjdC1iYWNrY2hhbm5lbC0xXzAt MDEuaHRtbCNMb2dvdXRUb2tlbjwvYT46PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDIwNjAiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPmxvZ291dF9vbmx5PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymxh Y2siPlJFUVVJUkVELiBWYWx1ZSBkZWNsYXJpbmcgdGhhdCB0aGlzIEpXVCBpcyBvbmx5IHRvIGJl IHVzZWQgYXMgYSBMb2dvdXQgVG9rZW4uIEluIHBhcnRpY3VsYXIsIHRoaXMgSldUIGNhbm5vdCBi ZSB1c2VkIGluIGFueQ0KIGNvbnRleHQgd2hlcmUgYW4gSUQgVG9rZW4gaXMgdXNlZC4gVGhlIHZh bHVlIG9mIHRoaXMgQ2xhaW0gTVVTVCBiZSB0aGUgSlNPTiBib29sZWFuIHZhbHVlDQo8L3NwYW4+ PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMwMDMzNjYiPnRydWU8L3NwYW4+PHNwYW4gbGFuZz0i RU4iIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Lg0KPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDAyMDYwIj5UaGlz IGNsYWltIGlzIGN1cnJlbnRseSB1c2VkIHRvIOKAnHR5cGXigJ0gdGhlIGxvZ291dCB0b2tlbi4m bmJzcDsgQ2hhbmdpbmcgZnJvbSDigJxsb2dvdXRfb25seeKAnTp0cnVlIHRvIOKAnGp0eeKAnTog 4oCcbG9nb3V04oCdIG9yIHNvbWV0aGluZyBzaW1pbGFyIHdvdWxkIGJlIGZpbmUuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDAyMDYw Ij5Kb2huIHN1Z2dlc3RlZCB0aGF0IHdlIHByb2hpYml0IHRoZSBpbmNsdXNpb24gb2Yg4oCcbm9u Y2XigJ0gYXMgYSBzZWNvbmQgd2F5IG9mIGVuc3VyaW5nIHRoYXQgdGhhdCB0b2tlbiBjb3VsZG7i gJl0IGJlIHJlcHVycG9zZWQgYXMgYW4gSUQgVG9rZW4uJm5ic3A7IFRoYXQgd291bGQgd29yaw0K IGV2ZW4gaWYgdGhlIGNvZGUgd2FzbuKAmXQgY2hlY2tpbmcgZm9yIOKAnGxvZ291dF9vbmx54oCd IG9yIOKAnGp0eeKAnS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMwMDIwNjAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBJZC1ldmVudCBbbWFpbHRvOmlkLWV2ZW50 LWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPldpbGxpYW0gRGVubmlzczxi cj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIE5vdmVtYmVyIDA0LCAyMDE1IDQ6NTQgUE08YnI+ DQo8Yj5Ubzo8L2I+IEp1c3RpbiBSaWNoZXI8YnI+DQo8Yj5DYzo8L2I+IEpvaG4gQnJhZGxleTsg aWQtZXZlbnRAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtJZC1ldmVudF0gRGlz dGluZ3Vpc2hpbmcgZGlmZmVyZW50IEpXVCB0eXBlczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5GYWlyIHBvaW50cy4gTXkgbWFpbiBjb25jZXJuIGlzIHRoYXQg d2UgZG9uJ3QgYWx3YXlzIGtub3cgaG93IHBlb3BsZSB0cmVhdCBJRCBUb2tlbnMgKG9yIEpXVHMg bW9yZSBnZW5lcmFsbHkpLCBhbmQgb25lIG9mIHRoZWlyIG5pY2UgcHJvcGVydGllcyBpcyB0aGF0 IHRoZXkgYXJlIGRlc2lnbmVkIHRvIGJlIHZlcmlmaWFibGUgaWYgdHJhbnNtaXR0ZWQgb3ZlciBh biB1bnRydXN0ZWQgbWVkaXVtLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5JIHRoaW5rIHdlIGNhbiBidWlsZCBpbiBtb3JlIHByb3RlY3Rpb24g Z29pbmcgZm9yd2FyZCBieSBoYXZpbmcgYSBjbGVhciB0eXBlIGluZGljYXRvci4gSW1hZ2luZSBo YXZpbmcgNiBkaWZmZXJlbnQgSldUIHR5cGVzLCBhbGwgcG90ZW50aWFsbHkgdmFsaWRhdGluZyBh cyB0aGUgb3RoZXIgdHlwZXMuIEl0IHNlZW1zIGRhbmdlcm91cyBpZiB0aGUgb25seSBwcm90ZWN0 aW9uIGlzIHRoYXQgdGhleSBzaG91bGRuJ3QNCiBiZSBhY2NlcHRlZCBvdXRzaWRlIHRoZWlyIGlu dGVuZGVkIGZsb3dzLCBhbmQgYWxzbyBkb3ducmlnaHQgY29uZnVzaW5nIGFzIHRoZXkgYWxsIGxv b2sgc2ltaWxhci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+UmVtb3ZpbmcgZmllbGRzIHRvIGJyZWFrIHBvdGVudGlhbCByZS11c2UgZG9lc24n dCBzY2FsZSwgYW5kIGRvZXNuJ3QgaGVscCB1bmRlcnN0YW5kYWJpbGl0eSBlaXRoZXIuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gV2Vk LCBOb3YgNCwgMjAxNSBhdCA0OjI0IFBNLCBKdXN0aW4gUmljaGVyICZsdDs8YSBocmVmPSJtYWls dG86anJpY2hlckBtaXQuZWR1IiB0YXJnZXQ9Il9ibGFuayI+anJpY2hlckBtaXQuZWR1PC9hPiZn dDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SeKA mW0gdmVyeSBtdWNoIGluIGZhdm9yIG9mIGhhdmluZyBhIEpXVCB0b2tlbiB0eXBlIGtleSwgYnV0 IGZvciBvdGhlciByZWFzb25zIGFuZCB1c2VzLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SeKAmW0ganVzdCB0YWtpbmcgaXNzdWUgd2l0aCB0aGUg YXNzZXJ0aW9uIHRoYXQgYSBsb2dvdXQgdG9rZW4gY291bGQgYmUgZWFzaWx5IGNvbmZ1c2VkIGJ5 IGEgZnVuY3Rpb25pbmcgT0lEQyBjbGllbnQuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5FdmVuIHRoZW4gSSB0aGluayBpdOKAmXMgYSBnb29kIGlkZWEgdG8g aGF2ZSBhIOKAnHR5cCZxdW90Ozog4oCcbG9nb3V04oCdIHRhZyBpbiBpdC4gVGhlIGN1cnJlbnQg Z3VpZGVsaW5lIHRvIHRha2UgdGhlIOKAnG5vbmNl4oCdIG91dCBpcyBhIHByb2ZvdW5kbHkgc3R1 cGlkIGhhY2sgdGhhdOKAmXMgbm90IGxpa2VseSB0byBtYWtlIG11Y2ggZGlmZmVyZW5jZSBpbiB0 aGUgcmVhbCB3b3JsZCwgb3IgYXQgbGVhc3QgZXZlbiBsZXNzIG9mIGEgZGlmZmVyZW5jZQ0KIHRo YW4gYSB0eXBlIHBhcmFtZXRlci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+QWxvbmcgdGhvc2UgbGluZXMsIEnigJlkIHN1Z2dlc3Qgd2UgdXNl IOKAnGp0dCZxdW90OyBvciDigJxKU09OICh3ZWIpIFRva2VuIFR5cGXigJ0gYXMgdGhlIGZpZWxk IG5hbWUsIHNvIHdlIGRvbuKAmXQgY2F1c2UgY29uZnVzaW9uIHdpdGggdGhlIGhlYWRlciDigJx0 eXDigJ0gcGFyYW1ldGVyLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjojODg4ODg4Ij4mbmJzcDvigJQgSnVzdGluPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5P biBOb3YgNCwgMjAxNSwgYXQgNDowNiBQTSwgSm9obiBCcmFkbGV5ICZsdDs8YSBocmVmPSJtYWls dG86dmU3anRiQHZlN2p0Yi5jb20iIHRhcmdldD0iX2JsYW5rIj52ZTdqdGJAdmU3anRiLmNvbTwv YT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SW4gcHJpbmNpcGFsIGEgY2xpZW50IGdldHMgYSB0b2tlbiB0d28gd2F5cy4gJm5ic3A7PG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MSB2aWEgYSB0b2tlbiBl bmRwb2ludCBpbiBhIGRpcmVjdCBjb21tdW5pY2F0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MiB2aWEgdGhlIGF1dGhvcml6YXRpb24gZW5k cG9pbnQsIEluIHRoaXMgY2FzZSBhIGNsaWVudCBuZWVkcyB0byBjaGVjayB0aGUgbm9uY2UgdmFs dWUgdG8gY29ycmVsYXRlIHRoZSB0b2tlbiB3aXRoIHRoZSB1c2VyIGFnZW50IHRoYXQgdGhlIHJl cXVlc3Qgd2FzIG1hZGUgdmlhLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5JIHRoaW5rIGl0IGlzIGZhaXIgbm90IHRvIGhhdmUgYSBub25jZSBp biB0aGUgb3RoZXIgdG9rZW5zIGFzIHRoZXkgYXJlIG5vdCByZXF1ZXN0ZWQgdmlhIHRoZSBicm93 c2VyLiZuYnNwOyBOb25jZSB3b3VsZCBhbHNvIG5vdCBiZSBhcHByb3ByaWF0ZSBmb3IgYSBKV1Qg YXNzZXJ0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5JIHdvdWxkIGJlIG1vcmUgd29ycmllZCBhYm91dCBvdGhlciBzb3J0cyBvZiBhc3Nl cnRpb25zIGJlaW5nIGNvbmZ1c2VkLCBvciBhdC1sZWFzdCBub3QgZWFzaWx5IGRpZmZlcmVudGlh dGVkLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5JIGRvbuKAmXQgdGhpbmsgaGF2aW5nIGEgZXhwbGljaXQgSldUIHRva2VuIHR5cGUg YmVpbmcgYSBiYWQgdGhpbmcuICZuYnNwOyBBZGRpbmcgaXQgd291bGQgbm90IGRpc3J1cHQgZXhp c3RpbmcgY2xpZW50cy4gJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkkgdGhpbmsgaXQgaXMgbW9yZSBhIGNhc2Ugb2YgZGV0ZXJtaW5p bmcgaWYgdGhpcyB3aWxsIGJlIHVzZWZ1bCBmb3Igb3RoZXIgdGhpbmdzLiAmbmJzcDsgSW4gY29u bmVjdCBpdCB3b3VsZCByZWFsbHkgb25seSBoZWxwIGJhZGx5IGNvZGVkIGNsaWVudHMgd2hvIGFy ZSB1bmxpa2VseSB0byBjaGVjayBpdCBhbnl3YXkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkpvaG4gQi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE5vdiA0LCAyMDE1LCBhdCAyOjM2 IFBNLCBKdXN0aW4gUmljaGVyICZsdDs8YSBocmVmPSJtYWlsdG86anJpY2hlckBtaXQuZWR1IiB0 YXJnZXQ9Il9ibGFuayI+anJpY2hlckBtaXQuZWR1PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRoaW5rIGEgcmVhbCBxdWVzdGlv biB3aXRoIHJlZ2FyZCB0byB0aGUgbG9naW4vbG9nb3V0IGNhc2UgaXMsIHN1Y2NpbmN0bHksIOKA nFdoeSBpcyBhbiBhcHBsaWNhdGlvbiBhY2NlcHRpbmcgYW4gSUQgdG9rZW4gZnJvbSBhbiB1bmtu b3duIHRoaXJkLXBhcnR5IGFzIHByb29mIG9mIGxvZ2lu4oCdPyBJbiB0aGUgbm9ybWFsIE9JREMg cHJvY2VzcywgdGhlIGNsaWVudCB3aWxsIG9ubHkgZ2V0IHRoZSBJRCB0b2tlbg0KIGluIHJlc3Bv bnNlIHRvIGFuIGF1dGhlbnRpY2F0aW9uIHJlcXVlc3QsIHNvIGl0IHNob3VsZG7igJl0IGV2ZXIg YmUganVzdCBsaXN0ZW5pbmcgZm9yIGluY29taW5nIElEIHRva2Vucy48bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwO+KAlCBKdXN0aW48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE5vdiA0LCAy MDE1LCBhdCAyOjE5IFBNLCBXaWxsaWFtIERlbm5pc3MgJmx0OzxhIGhyZWY9Im1haWx0bzp3ZGVu bmlzc0Bnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+d2Rlbm5pc3NAZ29vZ2xlLmNvbTwvYT4m Z3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SGkgRXZlcnlvbmUsPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5JdCB3YXMgZ29vZCB0YWxraW5nIHRvIG1hbnkgb2YgeW91IGF0IFlva29oYW1hIGVhcmxpZXIg aW4gdGhlIHdlZWsgYWJvdXQgdXNpbmcgSldUcyBmb3IgZXZlbnQgbWVzc2FnZXMgbGlrZSBMb2dv dXQsIFJpc2sgU2lnbmFscywgU0NJTSBwcm9maWxlIHVwZGF0ZXMgYW5kIG1vcmUuIFRoYW5rIHlv dSBQaGlsIGZvciBzdGFydGluZyB0aGlzIGNvbnZlcnNhdGlvbiBhbmQgc3Bpbm5pbmcgdXAgdGhl IGxpc3QhIFdlJ3JlDQogYWxsIGRvaW5nIHJlbGF0ZWQgdGhpbmdzIHdpdGggZXZlbnRzLCBhbmQg aXQgbWFrZXMgc2Vuc2UgdG8gY29sbGFib3JhdGUgYW5kIHVuaWZ5IG91ciBhcHByb2FjaGVzLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbiBp c3N1ZSB3aXRoIEpXVCByZXVzZSBjdXJyZW50bHkgaXMgdGhhdCBJRCBUb2tlbnMgYXJlIDxhIGhy ZWY9Imh0dHA6Ly9vcGVuaWQubmV0L3NwZWNzL29wZW5pZC1jb25uZWN0LWNvcmUtMV8wLmh0bWwj SURUb2tlbiIgdGFyZ2V0PSJfYmxhbmsiPg0KZGVmaW5lZDwvYT4mbmJzcDtieSBPcGVuSUQgQ29u bmVjdCB0byByZXF1aXJlIG9ubHkgYSBmZXcgPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL3JmYzc1MTkjc2VjdGlvbi00IiB0YXJnZXQ9Il9ibGFuayI+DQpzdGFuZGFyZCBKV1Qg Y2xhaW1zPC9hPiwgYW5kIHRoZSByZXF1aXJlZCBjbGFpbXMgYXJlIGhpZ2hseSByZS11c2FibGUg YW5kIGNvbnRhaW4gbm90aGluZyB0aGF0IGFjdHVhbGx5IHNldHMgdGhlbSBhcGFydCBhcyBhbiAm cXVvdDtJRCBUb2tlbiZxdW90Oy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+VGhlIHJpc2sgb2YgdGhpcyBpcyB0aGF0IGEgSldUIGZvciBhbiBl dmVudCBsaWtlIGxvZ291dCBjYW4gYmUgYSB2YWxpZCBJRCBUb2tlbiBmb3IgbG9naW4uJm5ic3A7 IEFuIGF0dGFja2VyIGluIHBvc3Nlc3Npb24gb2YgYSBsb2dvdXQgdG9rZW4gY291bGQgcmVwbGF5 IGl0IGFnYWluc3QgYSBsb2dpbiBlbmRwb2ludCwgYW5kIGdhaW4gYWNjZXNzLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbmUgbWl0aWdhdGlv biBpcyB0byBjaGFuZ2UgdGhlIGlzc3Vlciwgb3IgYXVkaWVuY2UuIFRvIG1lIHRoaXMgaXMgdW5k ZXNpcmFibGUgYXMgdGhlIGV2ZW50cyAoZS5nLiBsb2dvdXQpIGRvIHJlbGF0ZSB0byB0aGUgc2Ft ZSBpc3N1ZXIgYW5kIGF1ZGllbmNlLiBMaWtlIG1hdHRlciBhbmQgYW50aS1tYXR0ZXIsIHlpbiBh bmQgeWFuZyDigJMgbG9nb3V0IHNob3VsZCBzaW1wbHkgcmV2ZXJzZSB0aGUgbG9naW4uJm5ic3A7 IEl0DQogc2VlbXMgd2FzdGVmdWwgdG8gc3BpbiB1cCBhIG5ldyBpc3N1ZXIsIG5ldyBrZXkgcm90 YXRpb25zLCBhbmQgbW9yZSBqdXN0IHRvIG1hbmFnZSBlYWNoIGRpZmZlcmVudCB0eXBlIG9mIGV2 ZW50LCBpZiB0aGV5IHdvdWxkIG90aGVyd2lzZSBiZSByZWxhdGVkIGJ5IGlzc3Vlci48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q3VycmVudGx5 IHRoZSA8YSBocmVmPSJodHRwOi8vb3BlbmlkLm5ldC9zcGVjcy9vcGVuaWQtY29ubmVjdC1iYWNr Y2hhbm5lbC0xXzAuaHRtbCIgdGFyZ2V0PSJfYmxhbmsiPg0KQmFja2NoYW5uZWwgTG9nb3V0IGRy YWZ0PC9hPiBhdHRlbXB0cyB0byAmcXVvdDticmVhayZxdW90OyB0aGlzIHV0aWxpdHkgb2YgYSBs b2dvdXQgSldUIGZvciBhdXRoZW50aWNhdGlvbiBieSBwcm9oaWJpdGluZyB0aGUmbmJzcDsnbm9u Y2UnIGZpZWxkOjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDo1 LjBwdDttYXJnaW4tcmlnaHQ6MjQuMHB0O21hcmdpbi1ib3R0b206NS4wcHQ7bWFyZ2luLWxlZnQ6 MjQuMHB0Ij4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPlRoZSBmb2xsb3dpbmcgQ2xhaW0gTVVTVCBOT1QgYmUgdXNl ZCB3aXRoaW4gdGhlIExvZ291dCBUb2tlbjo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0 eWxlPSJtYXJnaW4tbGVmdDoyNC4wcHQ7bWFyZ2luLXJpZ2h0OjI0LjBwdCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+bm9uY2U8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+UFJPSElCSVRFRC4gQSZuYnNwOzwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Y29sb3I6IzAwMzM2NiI+bm9uY2U8L3NwYW4+PC90dD48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij4mbmJzcDtDbGFpbSBNVVNUIE5PVCBiZSBwcmVzZW50Lg0KIEl0cyB1c2UgaXMgcHJvaGliaXRl ZCB0byBtYWtlIGEgTG9nb3V0IFRva2VuIHN5bnRhY3RpY2FsbHkgaW52YWxpZCBpZiB1c2VkIGlu IGEgZm9yZ2VkIEF1dGhlbnRpY2F0aW9uIFJlc3BvbnNlIGluIHBsYWNlIG9mIGFuIElEIFRva2Vu LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkknbSBjb25jZXJuZWQgdGhh dCB0aGlzIG1heSBub3QgYWx3YXlzIHdvcmsgYXMgaW50ZW5kZWQsIGFzICdub25jZScgaXMgbm90 IGEgcmVxdWlyZWQgZmllbGQgb2YgdGhlIElEIFRva2VuLiBJRCBUb2tlbnMgb2J0YWluZWQgZnJv bSBHb29nbGUgdXNpbmcgdGhlIGNvZGUgZmxvdyAob24gb3VyIE9wZW5JRCBDb25uZWN0IGNlcnRp ZmllZCBlbmRwb2ludHMpIGRvIG5vdCBjb250YWluICdub25jZScgdG9kYXksIGZvcg0KIGV4YW1w bGUuIEFuZCBJJ20gYSBsaXR0bGUgd29ycmllZCB0aGF0IFJQcyBtYXkgbm90IGJlIHN0cmljdGx5 IGNoZWNraW5nIGZvciBhICdub25jZScsIGV2ZW4gd2hlbiB0aGV5IHNob3VsZCAoZS5nLiB3aGVu IHVzaW5nIHRoZSBpbXBsaWNpdCBmbG93KS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RXZlbiBpZiB0aGlzIGFwcHJvYWNoIHdvcmtzIGluIHRo aXMgc3BlY2lmaWMgY2FzZSwgaXQncyBub3Qgc2NhbGFibGUuIFNvIEkgcHJvcG9zZSB0aGF0IHdl IG1vdmUgdG8gYWRvcHQgYSBuZXcgc3RhbmRhcmQgY2xhaW0gdGhhdCBjYW4gYmUgdXNlZCB0byBp bmRpY2F0ZSB0aGUgaW50ZW5kZWQgcHVycG9zZSBvZiB0aGUgSldULjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4ndHlwJyBpcyBhbiBvYnZpb3Vz IGNob2ljZSBmb3IgYSBjbGFpbSBuYW1lLCBhbHRob3VnaCB0aGUgd29yZCAndHlwZScgbWF5IGJl IGEgbGl0dGxlIG92ZXJsb2FkZWQgYWxyZWFkeS4gQW5vdGhlciBvcHRpb24gY291bGQgYmUgJnF1 b3Q7Y2F0JnF1b3Q7IGZvciBjYXRlZ29yeS4mbmJzcDsgV2hhdGV2ZXIgd2UgZGVjaWRlLCBJIHRo aW5rIHN1Y2ggYSBjbGFpbSBzaG91bGQgYmUgdXNlZCBpbiBhbGwgSldUIHNwZWNzIGdvaW5nIGZv cndhcmQsDQogYW5kIGFkZGVkIHRvIE9wZW5JRCBDb25uZWN0IElEIFRva2VucyBpbiBhIGZ1dHVy ZSByZXZpc2lvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+V2lsbGlhbTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPGJyPg0KSWQtZXZlbnQgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRv OklkLWV2ZW50QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+SWQtZXZlbnRAaWV0Zi5vcmc8L2E+ PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZC1l dmVudCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vaWQtZXZlbnQ8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188YnI+DQpJZC1ldmVudCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBo cmVmPSJtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5JZC1ldmVudEBp ZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2lkLWV2ZW50IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9pZC1ldmVudDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BY2PR03MB442BBC876D242428FFB244AF52A0BY2PR03MB442namprd_-- From nobody Wed Nov 4 00:09:19 2015 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FF961B2B73 for ; Wed, 4 Nov 2015 00:09:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0LkAu2J01nLk for ; Wed, 4 Nov 2015 00:09:14 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0123.outbound.protection.outlook.com [65.55.169.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F09B31B2B6F for ; Wed, 4 Nov 2015 00:09:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=BoEislwAOht+uQiN/jpZbCX/CxtwGnLZnNIwWRFR/x0=; b=VF4sJnZNebvWF0f8e2jiFO2oKJPjApOF0pAesZUymN1kAN7ni9p4qQIfaDP1jxP13XWRZJCeLBTu5jIBHjHyYcdIO6hF/fB3oH4/yBHG8+7WMoUbkWGbsJDgLXvYw5W3olZUmW5Lnhmpzz0ttg6+OcLsuh+ihsEQNAOVe5kndRU= Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB441.namprd03.prod.outlook.com (10.141.141.142) with Microsoft SMTP Server (TLS) id 15.1.312.18; Wed, 4 Nov 2015 08:09:11 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0318.003; Wed, 4 Nov 2015 08:09:11 +0000 From: Mike Jones To: William Denniss , Justin Richer Thread-Topic: [Id-event] Distinguishing different JWT types Thread-Index: AQHRFsBg3BNM3t3kCUixIip7hsf4KJ6LWBMAgAAY9ICAAAVAAIAACBSAgAAAgnCAAAMi4A== Date: Wed, 4 Nov 2015 08:09:11 +0000 Message-ID: References: <7A2911BB-0B39-4A61-8767-6A0D24012363@mit.edu> <0EE00ED6-D344-4B92-9A05-8FFB7BCB6BF0@mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [2001:c40:0:3032:91d0:60c:fcfc:5727] x-microsoft-exchange-diagnostics: 1; BY2PR03MB441; 5:/YbH88ghH6rfm/IlJ7b/T7pOxRgP5VVCIYSUnWsnHqJdK/cI/V0dmKDPLd9hwAKM1iZmEyP1UbmYOkdCwKh5Zl7gambgENMRyD8ASAIqf/c7pXj3Qo+YnIy1UXM1jzv8d25in1Xn4rYwhaEEZjSh3w==; 24:TeYMfoNb1ru4FdTGlFS6ChVMrlIp5pTRYrcKPwR2W9HhY7Qt24Qr2WuTBKybEZcV1QfI3G+Mm92PXGsX8Q21/XaFk6LSnaEgYylbMxYfvNo=; 20:SChskebyLBrg/zAp74colreFeSi2fRXlcmlCK9f4kHBY2OXWqAgcScU0ovh9dcwPg3grTTcL2oEvRt+vK615pQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB441; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(240460790083961)(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425024)(601004)(2401047)(520078)(5005006)(8121501046)(3002001)(10201501046)(61426024)(61427024); SRVR:BY2PR03MB441; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB441; x-forefront-prvs: 0750463DC9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(189002)(199003)(377454003)(53754006)(24454002)(92566002)(93886004)(5001960100002)(189998001)(10090500001)(19617315012)(5003600100002)(5002640100001)(19625215002)(19609705001)(87936001)(19580405001)(15395725005)(101416001)(54356999)(19580395003)(19300405004)(50986999)(16236675004)(76176999)(86362001)(33656002)(86612001)(2171001)(5008740100001)(11100500001)(81156007)(40100003)(122556002)(76576001)(5007970100001)(5004730100002)(99286002)(77096005)(106356001)(74316001)(105586002)(106116001)(5005710100001)(10400500002)(10290500002)(102836002)(15975445007)(8990500004)(2950100001)(97736004)(5001770100001)(2900100001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB441; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR03MB4426EDB56EC4CA0B4922662F52A0BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Nov 2015 08:09:11.1245 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB441 Archived-At: Cc: John Bradley , "id-event@ietf.org" Subject: Re: [Id-event] Distinguishing different JWT types X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2015 08:09:18 -0000 --_000_BY2PR03MB4426EDB56EC4CA0B4922662F52A0BY2PR03MB442namprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U29tZSBvZiB5b3UgaGF2ZSBzZWVuIG15IHJlbWFyayBiZWxvdyBidXQgSeKAmW0gcmVzZW5kaW5n IGl0IHRvIGdldCBpdCBvbiB0aGUgcmVjb3JkIGZvciB0aG9zZSBvZiB5b3UgaGF2ZSBub3TigKYN Cg0KSSB3YW50IHRvIHN0YXkgY29tcGxldGVseSBjbGVhciBvZiBzaXR1YXRpb25zIGluIHdoaWNo IG11bHRpcGxlIGtpbmRzIG9mIG1lc3NhZ2VzIGFyZSBzZW50IHRvIHRoZSBzYW1lIGVuZHBvaW50 IGFuZCB0aGVuIGRpc3BhdGNoZWQgdG8gZG8gZGlmZmVyZW50IHRoaW5ncyBiYXNlZCBvbiB0aGUg bWVzc2FnZSB0eXBlLiAgVGhhdCBpcyB0aGUgcGF0dGVybiB0aGF0IGxlZCBwZW9wbGUgdG8gYWJh bmRvbiBTT0FQL1dTLSogZm9yIFJFU1QuICBJIGRvbuKAmXQgd2FudCB0byBiZSBwYXJ0IG9mIHJl Y3JlYXRpbmcgaXQuDQoNCkZvciBpbnN0YW5jZSwgSSBvbmx5IHdhbnQgbG9nb3V0IG1lc3NhZ2Ug dG8gYmUgc2VudCB0byB0aGUgT3BlbklEIENvbm5lY3QgbG9nb3V0IGVuZHBvaW50LiAgSXTigJlz IGFwcHJvcHJpYXRlIGZvciB0aGUgZW5kcG9pbnQgdG8gKnZhbGlkYXRlKiB0aGF0IHRoZSBtZXNz YWdlIGNvbmZvcm1zIHRvIHRoZSBzcGVjaWZpZWQgbG9nb3V0IG1lc3NhZ2Ugc3ludGF4IGFuZCBv dGhlcndpc2UgcmVqZWN0IHRoZSBtZXNzYWdlLiAgQnV0IHRoZSBvbmx5IGFjdGlvbiB0YWtlbiBm b3IgbWVzc2FnZXMgb2Ygb3RoZXIgdHlwZXMgc2hvdWxkIGJlIHRvIGRyb3AgdGhlbSDigJMgbm90 IGRpc3BhdGNoIHRoZW0uDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTogSWQtZXZlbnQgW21haWx0bzpp ZC1ldmVudC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTWlrZSBKb25lcw0KU2VudDog V2VkbmVzZGF5LCBOb3ZlbWJlciAwNCwgMjAxNSA1OjA1IFBNDQpUbzogV2lsbGlhbSBEZW5uaXNz OyBKdXN0aW4gUmljaGVyDQpDYzogSm9obiBCcmFkbGV5OyBpZC1ldmVudEBpZXRmLm9yZw0KU3Vi amVjdDogUmU6IFtJZC1ldmVudF0gRGlzdGluZ3Vpc2hpbmcgZGlmZmVyZW50IEpXVCB0eXBlcw0K DQpUaGUgcGFydCBvZiB0aGlzIHRocmVhZCBkZWFsaW5nIHdpdGggbG9nb3V0IHNob3VsZCBoYXZl IGluY2x1ZGVkIGEgcmVmZXJlbmNlIHRvIHRoaXMgdGV4dCBpbiBodHRwOi8vb3BlbmlkLm5ldC9z cGVjcy9vcGVuaWQtY29ubmVjdC1iYWNrY2hhbm5lbC0xXzAtMDEuaHRtbCNMb2dvdXRUb2tlbjoN Cg0KbG9nb3V0X29ubHkNClJFUVVJUkVELiBWYWx1ZSBkZWNsYXJpbmcgdGhhdCB0aGlzIEpXVCBp cyBvbmx5IHRvIGJlIHVzZWQgYXMgYSBMb2dvdXQgVG9rZW4uIEluIHBhcnRpY3VsYXIsIHRoaXMg SldUIGNhbm5vdCBiZSB1c2VkIGluIGFueSBjb250ZXh0IHdoZXJlIGFuIElEIFRva2VuIGlzIHVz ZWQuIFRoZSB2YWx1ZSBvZiB0aGlzIENsYWltIE1VU1QgYmUgdGhlIEpTT04gYm9vbGVhbiB2YWx1 ZSB0cnVlLg0KDQpUaGlzIGNsYWltIGlzIGN1cnJlbnRseSB1c2VkIHRvIOKAnHR5cGXigJ0gdGhl IGxvZ291dCB0b2tlbi4gIENoYW5naW5nIGZyb20g4oCcbG9nb3V0X29ubHnigJ06dHJ1ZSB0byDi gJxqdHnigJ06IOKAnGxvZ291dOKAnSBvciBzb21ldGhpbmcgc2ltaWxhciB3b3VsZCBiZSBmaW5l Lg0KDQpKb2huIHN1Z2dlc3RlZCB0aGF0IHdlIHByb2hpYml0IHRoZSBpbmNsdXNpb24gb2Yg4oCc bm9uY2XigJ0gYXMgYSBzZWNvbmQgd2F5IG9mIGVuc3VyaW5nIHRoYXQgdGhhdCB0b2tlbiBjb3Vs ZG7igJl0IGJlIHJlcHVycG9zZWQgYXMgYW4gSUQgVG9rZW4uICBUaGF0IHdvdWxkIHdvcmsgZXZl biBpZiB0aGUgY29kZSB3YXNu4oCZdCBjaGVja2luZyBmb3Ig4oCcbG9nb3V0X29ubHnigJ0gb3Ig 4oCcanR54oCdLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNCkZyb206IElkLWV2ZW50IFttYWlsdG86aWQtZXZl bnQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFdpbGxpYW0gRGVubmlzcw0KU2VudDog V2VkbmVzZGF5LCBOb3ZlbWJlciAwNCwgMjAxNSA0OjU0IFBNDQpUbzogSnVzdGluIFJpY2hlcg0K Q2M6IEpvaG4gQnJhZGxleTsgaWQtZXZlbnRAaWV0Zi5vcmc8bWFpbHRvOmlkLWV2ZW50QGlldGYu b3JnPg0KU3ViamVjdDogUmU6IFtJZC1ldmVudF0gRGlzdGluZ3Vpc2hpbmcgZGlmZmVyZW50IEpX VCB0eXBlcw0KDQpGYWlyIHBvaW50cy4gTXkgbWFpbiBjb25jZXJuIGlzIHRoYXQgd2UgZG9uJ3Qg YWx3YXlzIGtub3cgaG93IHBlb3BsZSB0cmVhdCBJRCBUb2tlbnMgKG9yIEpXVHMgbW9yZSBnZW5l cmFsbHkpLCBhbmQgb25lIG9mIHRoZWlyIG5pY2UgcHJvcGVydGllcyBpcyB0aGF0IHRoZXkgYXJl IGRlc2lnbmVkIHRvIGJlIHZlcmlmaWFibGUgaWYgdHJhbnNtaXR0ZWQgb3ZlciBhbiB1bnRydXN0 ZWQgbWVkaXVtLg0KDQpJIHRoaW5rIHdlIGNhbiBidWlsZCBpbiBtb3JlIHByb3RlY3Rpb24gZ29p bmcgZm9yd2FyZCBieSBoYXZpbmcgYSBjbGVhciB0eXBlIGluZGljYXRvci4gSW1hZ2luZSBoYXZp bmcgNiBkaWZmZXJlbnQgSldUIHR5cGVzLCBhbGwgcG90ZW50aWFsbHkgdmFsaWRhdGluZyBhcyB0 aGUgb3RoZXIgdHlwZXMuIEl0IHNlZW1zIGRhbmdlcm91cyBpZiB0aGUgb25seSBwcm90ZWN0aW9u IGlzIHRoYXQgdGhleSBzaG91bGRuJ3QgYmUgYWNjZXB0ZWQgb3V0c2lkZSB0aGVpciBpbnRlbmRl ZCBmbG93cywgYW5kIGFsc28gZG93bnJpZ2h0IGNvbmZ1c2luZyBhcyB0aGV5IGFsbCBsb29rIHNp bWlsYXIuDQoNClJlbW92aW5nIGZpZWxkcyB0byBicmVhayBwb3RlbnRpYWwgcmUtdXNlIGRvZXNu J3Qgc2NhbGUsIGFuZCBkb2Vzbid0IGhlbHAgdW5kZXJzdGFuZGFiaWxpdHkgZWl0aGVyLg0KDQoN Ck9uIFdlZCwgTm92IDQsIDIwMTUgYXQgNDoyNCBQTSwgSnVzdGluIFJpY2hlciA8anJpY2hlckBt aXQuZWR1PG1haWx0bzpqcmljaGVyQG1pdC5lZHU+PiB3cm90ZToNCknigJltIHZlcnkgbXVjaCBp biBmYXZvciBvZiBoYXZpbmcgYSBKV1QgdG9rZW4gdHlwZSBrZXksIGJ1dCBmb3Igb3RoZXIgcmVh c29ucyBhbmQgdXNlcy4NCg0KSeKAmW0ganVzdCB0YWtpbmcgaXNzdWUgd2l0aCB0aGUgYXNzZXJ0 aW9uIHRoYXQgYSBsb2dvdXQgdG9rZW4gY291bGQgYmUgZWFzaWx5IGNvbmZ1c2VkIGJ5IGEgZnVu Y3Rpb25pbmcgT0lEQyBjbGllbnQuDQoNCkV2ZW4gdGhlbiBJIHRoaW5rIGl04oCZcyBhIGdvb2Qg aWRlYSB0byBoYXZlIGEg4oCcdHlwIjog4oCcbG9nb3V04oCdIHRhZyBpbiBpdC4gVGhlIGN1cnJl bnQgZ3VpZGVsaW5lIHRvIHRha2UgdGhlIOKAnG5vbmNl4oCdIG91dCBpcyBhIHByb2ZvdW5kbHkg c3R1cGlkIGhhY2sgdGhhdOKAmXMgbm90IGxpa2VseSB0byBtYWtlIG11Y2ggZGlmZmVyZW5jZSBp biB0aGUgcmVhbCB3b3JsZCwgb3IgYXQgbGVhc3QgZXZlbiBsZXNzIG9mIGEgZGlmZmVyZW5jZSB0 aGFuIGEgdHlwZSBwYXJhbWV0ZXIuDQoNCkFsb25nIHRob3NlIGxpbmVzLCBJ4oCZZCBzdWdnZXN0 IHdlIHVzZSDigJxqdHQiIG9yIOKAnEpTT04gKHdlYikgVG9rZW4gVHlwZeKAnSBhcyB0aGUgZmll bGQgbmFtZSwgc28gd2UgZG9u4oCZdCBjYXVzZSBjb25mdXNpb24gd2l0aCB0aGUgaGVhZGVyIOKA nHR5cOKAnSBwYXJhbWV0ZXIuDQoNCiDigJQgSnVzdGluDQoNCk9uIE5vdiA0LCAyMDE1LCBhdCA0 OjA2IFBNLCBKb2huIEJyYWRsZXkgPHZlN2p0YkB2ZTdqdGIuY29tPG1haWx0bzp2ZTdqdGJAdmU3 anRiLmNvbT4+IHdyb3RlOg0KDQpJbiBwcmluY2lwYWwgYSBjbGllbnQgZ2V0cyBhIHRva2VuIHR3 byB3YXlzLg0KMSB2aWEgYSB0b2tlbiBlbmRwb2ludCBpbiBhIGRpcmVjdCBjb21tdW5pY2F0aW9u Lg0KMiB2aWEgdGhlIGF1dGhvcml6YXRpb24gZW5kcG9pbnQsIEluIHRoaXMgY2FzZSBhIGNsaWVu dCBuZWVkcyB0byBjaGVjayB0aGUgbm9uY2UgdmFsdWUgdG8gY29ycmVsYXRlIHRoZSB0b2tlbiB3 aXRoIHRoZSB1c2VyIGFnZW50IHRoYXQgdGhlIHJlcXVlc3Qgd2FzIG1hZGUgdmlhLg0KDQpJIHRo aW5rIGl0IGlzIGZhaXIgbm90IHRvIGhhdmUgYSBub25jZSBpbiB0aGUgb3RoZXIgdG9rZW5zIGFz IHRoZXkgYXJlIG5vdCByZXF1ZXN0ZWQgdmlhIHRoZSBicm93c2VyLiAgTm9uY2Ugd291bGQgYWxz byBub3QgYmUgYXBwcm9wcmlhdGUgZm9yIGEgSldUIGFzc2VydGlvbi4NCg0KSSB3b3VsZCBiZSBt b3JlIHdvcnJpZWQgYWJvdXQgb3RoZXIgc29ydHMgb2YgYXNzZXJ0aW9ucyBiZWluZyBjb25mdXNl ZCwgb3IgYXQtbGVhc3Qgbm90IGVhc2lseSBkaWZmZXJlbnRpYXRlZC4NCg0KSSBkb27igJl0IHRo aW5rIGhhdmluZyBhIGV4cGxpY2l0IEpXVCB0b2tlbiB0eXBlIGJlaW5nIGEgYmFkIHRoaW5nLiAg IEFkZGluZyBpdCB3b3VsZCBub3QgZGlzcnVwdCBleGlzdGluZyBjbGllbnRzLg0KDQpJIHRoaW5r IGl0IGlzIG1vcmUgYSBjYXNlIG9mIGRldGVybWluaW5nIGlmIHRoaXMgd2lsbCBiZSB1c2VmdWwg Zm9yIG90aGVyIHRoaW5ncy4gICBJbiBjb25uZWN0IGl0IHdvdWxkIHJlYWxseSBvbmx5IGhlbHAg YmFkbHkgY29kZWQgY2xpZW50cyB3aG8gYXJlIHVubGlrZWx5IHRvIGNoZWNrIGl0IGFueXdheS4N Cg0KSm9obiBCLg0KDQpPbiBOb3YgNCwgMjAxNSwgYXQgMjozNiBQTSwgSnVzdGluIFJpY2hlciA8 anJpY2hlckBtaXQuZWR1PG1haWx0bzpqcmljaGVyQG1pdC5lZHU+PiB3cm90ZToNCg0KSSB0aGlu ayBhIHJlYWwgcXVlc3Rpb24gd2l0aCByZWdhcmQgdG8gdGhlIGxvZ2luL2xvZ291dCBjYXNlIGlz LCBzdWNjaW5jdGx5LCDigJxXaHkgaXMgYW4gYXBwbGljYXRpb24gYWNjZXB0aW5nIGFuIElEIHRv a2VuIGZyb20gYW4gdW5rbm93biB0aGlyZC1wYXJ0eSBhcyBwcm9vZiBvZiBsb2dpbuKAnT8gSW4g dGhlIG5vcm1hbCBPSURDIHByb2Nlc3MsIHRoZSBjbGllbnQgd2lsbCBvbmx5IGdldCB0aGUgSUQg dG9rZW4gaW4gcmVzcG9uc2UgdG8gYW4gYXV0aGVudGljYXRpb24gcmVxdWVzdCwgc28gaXQgc2hv dWxkbuKAmXQgZXZlciBiZSBqdXN0IGxpc3RlbmluZyBmb3IgaW5jb21pbmcgSUQgdG9rZW5zLg0K DQog4oCUIEp1c3Rpbg0KDQpPbiBOb3YgNCwgMjAxNSwgYXQgMjoxOSBQTSwgV2lsbGlhbSBEZW5u aXNzIDx3ZGVubmlzc0Bnb29nbGUuY29tPG1haWx0bzp3ZGVubmlzc0Bnb29nbGUuY29tPj4gd3Jv dGU6DQoNCkhpIEV2ZXJ5b25lLA0KDQpJdCB3YXMgZ29vZCB0YWxraW5nIHRvIG1hbnkgb2YgeW91 IGF0IFlva29oYW1hIGVhcmxpZXIgaW4gdGhlIHdlZWsgYWJvdXQgdXNpbmcgSldUcyBmb3IgZXZl bnQgbWVzc2FnZXMgbGlrZSBMb2dvdXQsIFJpc2sgU2lnbmFscywgU0NJTSBwcm9maWxlIHVwZGF0 ZXMgYW5kIG1vcmUuIFRoYW5rIHlvdSBQaGlsIGZvciBzdGFydGluZyB0aGlzIGNvbnZlcnNhdGlv biBhbmQgc3Bpbm5pbmcgdXAgdGhlIGxpc3QhIFdlJ3JlIGFsbCBkb2luZyByZWxhdGVkIHRoaW5n cyB3aXRoIGV2ZW50cywgYW5kIGl0IG1ha2VzIHNlbnNlIHRvIGNvbGxhYm9yYXRlIGFuZCB1bmlm eSBvdXIgYXBwcm9hY2hlcy4NCg0KQW4gaXNzdWUgd2l0aCBKV1QgcmV1c2UgY3VycmVudGx5IGlz IHRoYXQgSUQgVG9rZW5zIGFyZSBkZWZpbmVkPGh0dHA6Ly9vcGVuaWQubmV0L3NwZWNzL29wZW5p ZC1jb25uZWN0LWNvcmUtMV8wLmh0bWwjSURUb2tlbj4gYnkgT3BlbklEIENvbm5lY3QgdG8gcmVx dWlyZSBvbmx5IGEgZmV3IHN0YW5kYXJkIEpXVCBjbGFpbXM8aHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL3JmYzc1MTkjc2VjdGlvbi00PiwgYW5kIHRoZSByZXF1aXJlZCBjbGFpbXMgYXJlIGhp Z2hseSByZS11c2FibGUgYW5kIGNvbnRhaW4gbm90aGluZyB0aGF0IGFjdHVhbGx5IHNldHMgdGhl bSBhcGFydCBhcyBhbiAiSUQgVG9rZW4iLg0KDQpUaGUgcmlzayBvZiB0aGlzIGlzIHRoYXQgYSBK V1QgZm9yIGFuIGV2ZW50IGxpa2UgbG9nb3V0IGNhbiBiZSBhIHZhbGlkIElEIFRva2VuIGZvciBs b2dpbi4gIEFuIGF0dGFja2VyIGluIHBvc3Nlc3Npb24gb2YgYSBsb2dvdXQgdG9rZW4gY291bGQg cmVwbGF5IGl0IGFnYWluc3QgYSBsb2dpbiBlbmRwb2ludCwgYW5kIGdhaW4gYWNjZXNzLg0KDQpP bmUgbWl0aWdhdGlvbiBpcyB0byBjaGFuZ2UgdGhlIGlzc3Vlciwgb3IgYXVkaWVuY2UuIFRvIG1l IHRoaXMgaXMgdW5kZXNpcmFibGUgYXMgdGhlIGV2ZW50cyAoZS5nLiBsb2dvdXQpIGRvIHJlbGF0 ZSB0byB0aGUgc2FtZSBpc3N1ZXIgYW5kIGF1ZGllbmNlLiBMaWtlIG1hdHRlciBhbmQgYW50aS1t YXR0ZXIsIHlpbiBhbmQgeWFuZyDigJMgbG9nb3V0IHNob3VsZCBzaW1wbHkgcmV2ZXJzZSB0aGUg bG9naW4uICBJdCBzZWVtcyB3YXN0ZWZ1bCB0byBzcGluIHVwIGEgbmV3IGlzc3VlciwgbmV3IGtl eSByb3RhdGlvbnMsIGFuZCBtb3JlIGp1c3QgdG8gbWFuYWdlIGVhY2ggZGlmZmVyZW50IHR5cGUg b2YgZXZlbnQsIGlmIHRoZXkgd291bGQgb3RoZXJ3aXNlIGJlIHJlbGF0ZWQgYnkgaXNzdWVyLg0K DQpDdXJyZW50bHkgdGhlIEJhY2tjaGFubmVsIExvZ291dCBkcmFmdDxodHRwOi8vb3BlbmlkLm5l dC9zcGVjcy9vcGVuaWQtY29ubmVjdC1iYWNrY2hhbm5lbC0xXzAuaHRtbD4gYXR0ZW1wdHMgdG8g ImJyZWFrIiB0aGlzIHV0aWxpdHkgb2YgYSBsb2dvdXQgSldUIGZvciBhdXRoZW50aWNhdGlvbiBi eSBwcm9oaWJpdGluZyB0aGUgJ25vbmNlJyBmaWVsZDoNCg0KVGhlIGZvbGxvd2luZyBDbGFpbSBN VVNUIE5PVCBiZSB1c2VkIHdpdGhpbiB0aGUgTG9nb3V0IFRva2VuOg0KDQpub25jZQ0KUFJPSElC SVRFRC4gQSBub25jZSBDbGFpbSBNVVNUIE5PVCBiZSBwcmVzZW50LiBJdHMgdXNlIGlzIHByb2hp Yml0ZWQgdG8gbWFrZSBhIExvZ291dCBUb2tlbiBzeW50YWN0aWNhbGx5IGludmFsaWQgaWYgdXNl ZCBpbiBhIGZvcmdlZCBBdXRoZW50aWNhdGlvbiBSZXNwb25zZSBpbiBwbGFjZSBvZiBhbiBJRCBU b2tlbi4NCg0KSSdtIGNvbmNlcm5lZCB0aGF0IHRoaXMgbWF5IG5vdCBhbHdheXMgd29yayBhcyBp bnRlbmRlZCwgYXMgJ25vbmNlJyBpcyBub3QgYSByZXF1aXJlZCBmaWVsZCBvZiB0aGUgSUQgVG9r ZW4uIElEIFRva2VucyBvYnRhaW5lZCBmcm9tIEdvb2dsZSB1c2luZyB0aGUgY29kZSBmbG93IChv biBvdXIgT3BlbklEIENvbm5lY3QgY2VydGlmaWVkIGVuZHBvaW50cykgZG8gbm90IGNvbnRhaW4g J25vbmNlJyB0b2RheSwgZm9yIGV4YW1wbGUuIEFuZCBJJ20gYSBsaXR0bGUgd29ycmllZCB0aGF0 IFJQcyBtYXkgbm90IGJlIHN0cmljdGx5IGNoZWNraW5nIGZvciBhICdub25jZScsIGV2ZW4gd2hl biB0aGV5IHNob3VsZCAoZS5nLiB3aGVuIHVzaW5nIHRoZSBpbXBsaWNpdCBmbG93KS4NCg0KRXZl biBpZiB0aGlzIGFwcHJvYWNoIHdvcmtzIGluIHRoaXMgc3BlY2lmaWMgY2FzZSwgaXQncyBub3Qg c2NhbGFibGUuIFNvIEkgcHJvcG9zZSB0aGF0IHdlIG1vdmUgdG8gYWRvcHQgYSBuZXcgc3RhbmRh cmQgY2xhaW0gdGhhdCBjYW4gYmUgdXNlZCB0byBpbmRpY2F0ZSB0aGUgaW50ZW5kZWQgcHVycG9z ZSBvZiB0aGUgSldULg0KDQondHlwJyBpcyBhbiBvYnZpb3VzIGNob2ljZSBmb3IgYSBjbGFpbSBu YW1lLCBhbHRob3VnaCB0aGUgd29yZCAndHlwZScgbWF5IGJlIGEgbGl0dGxlIG92ZXJsb2FkZWQg YWxyZWFkeS4gQW5vdGhlciBvcHRpb24gY291bGQgYmUgImNhdCIgZm9yIGNhdGVnb3J5LiAgV2hh dGV2ZXIgd2UgZGVjaWRlLCBJIHRoaW5rIHN1Y2ggYSBjbGFpbSBzaG91bGQgYmUgdXNlZCBpbiBh bGwgSldUIHNwZWNzIGdvaW5nIGZvcndhcmQsIGFuZCBhZGRlZCB0byBPcGVuSUQgQ29ubmVjdCBJ RCBUb2tlbnMgaW4gYSBmdXR1cmUgcmV2aXNpb24uDQoNCldpbGxpYW0NCg0KDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpJZC1ldmVudCBtYWlsaW5n IGxpc3QNCklkLWV2ZW50QGlldGYub3JnPG1haWx0bzpJZC1ldmVudEBpZXRmLm9yZz4NCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWQtZXZlbnQNCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCklkLWV2ZW50IG1haWxpbmcgbGlz dA0KSWQtZXZlbnRAaWV0Zi5vcmc8bWFpbHRvOklkLWV2ZW50QGlldGYub3JnPg0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZC1ldmVudA0KDQoNCg0K --_000_BY2PR03MB4426EDB56EC4CA0B4922662F52A0BY2PR03MB442namprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDE0IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7 DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpWZXJkYW5hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0 O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBk aXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZv bnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0K CW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KdHQN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0K cC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJn aW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9u dC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uaG9lbnpiDQoJe21zby1zdHls ZS1uYW1lOmhvZW56Yjt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMwMDIw NjA7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMDAyMDYwO30N CnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hh ciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRl eHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBw YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4w aW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2 OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAg djpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZd LS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBs ZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDIwNjAiPlNvbWUgb2YgeW91IGhhdmUg c2VlbiBteSByZW1hcmsgYmVsb3cgYnV0IEnigJltIHJlc2VuZGluZyBpdCB0byBnZXQgaXQgb24g dGhlIHJlY29yZCBmb3IgdGhvc2Ugb2YgeW91IGhhdmUgbm904oCmPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDAyMDYwIj5JIHdhbnQg dG8gc3RheSBjb21wbGV0ZWx5IGNsZWFyIG9mIHNpdHVhdGlvbnMgaW4gd2hpY2ggbXVsdGlwbGUg a2luZHMgb2YgbWVzc2FnZXMgYXJlIHNlbnQgdG8gdGhlIHNhbWUgZW5kcG9pbnQgYW5kIHRoZW4g ZGlzcGF0Y2hlZCB0byBkbyBkaWZmZXJlbnQgdGhpbmdzIGJhc2VkDQogb24gdGhlIG1lc3NhZ2Ug dHlwZS4mbmJzcDsgVGhhdCBpcyB0aGUgcGF0dGVybiB0aGF0IGxlZCBwZW9wbGUgdG8gYWJhbmRv biBTT0FQL1dTLSogZm9yIFJFU1QuJm5ic3A7IEkgZG9u4oCZdCB3YW50IHRvIGJlIHBhcnQgb2Yg cmVjcmVhdGluZyBpdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMwMDIwNjAiPkZvciBpbnN0YW5jZSwgSSBvbmx5IHdhbnQgbG9nb3V0 IG1lc3NhZ2UgdG8gYmUgc2VudCB0byB0aGUgT3BlbklEIENvbm5lY3QgbG9nb3V0IGVuZHBvaW50 LiZuYnNwOyBJdOKAmXMgYXBwcm9wcmlhdGUgZm9yIHRoZSBlbmRwb2ludCB0bw0KPGI+KnZhbGlk YXRlKjwvYj4gdGhhdCB0aGUgbWVzc2FnZSBjb25mb3JtcyB0byB0aGUgc3BlY2lmaWVkIGxvZ291 dCBtZXNzYWdlIHN5bnRheCBhbmQgb3RoZXJ3aXNlIHJlamVjdCB0aGUgbWVzc2FnZS4mbmJzcDsg QnV0IHRoZSBvbmx5IGFjdGlvbiB0YWtlbiBmb3IgbWVzc2FnZXMgb2Ygb3RoZXIgdHlwZXMgc2hv dWxkIGJlIHRvIGRyb3AgdGhlbSDigJMgbm90IGRpc3BhdGNoIHRoZW0uPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDAyMDYwIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDstLSBNaWtlPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMDAyMDYwIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBJZC1ldmVudCBbbWFpbHRvOmlkLWV2 ZW50LWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPk1pa2UgSm9uZXM8YnI+ DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBOb3ZlbWJlciAwNCwgMjAxNSA1OjA1IFBNPGJyPg0K PGI+VG86PC9iPiBXaWxsaWFtIERlbm5pc3M7IEp1c3RpbiBSaWNoZXI8YnI+DQo8Yj5DYzo8L2I+ IEpvaG4gQnJhZGxleTsgaWQtZXZlbnRAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6 IFtJZC1ldmVudF0gRGlzdGluZ3Vpc2hpbmcgZGlmZmVyZW50IEpXVCB0eXBlczxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMDAyMDYwIj5UaGUgcGFydCBvZiB0aGlzIHRocmVhZCBkZWFsaW5nIHdp dGggbG9nb3V0IHNob3VsZCBoYXZlIGluY2x1ZGVkIGEgcmVmZXJlbmNlIHRvIHRoaXMgdGV4dCBp bg0KPGEgaHJlZj0iaHR0cDovL29wZW5pZC5uZXQvc3BlY3Mvb3BlbmlkLWNvbm5lY3QtYmFja2No YW5uZWwtMV8wLTAxLmh0bWwjTG9nb3V0VG9rZW4iPg0KaHR0cDovL29wZW5pZC5uZXQvc3BlY3Mv b3BlbmlkLWNvbm5lY3QtYmFja2NoYW5uZWwtMV8wLTAxLmh0bWwjTG9nb3V0VG9rZW48L2E+Ojxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOmJsYWNrIj5sb2dvdXRfb25seTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBsYW5nPSJFTiIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5SRVFVSVJFRC4gVmFsdWUgZGVjbGFy aW5nIHRoYXQgdGhpcyBKV1QgaXMgb25seSB0byBiZSB1c2VkIGFzIGEgTG9nb3V0IFRva2VuLiBJ biBwYXJ0aWN1bGFyLCB0aGlzIEpXVCBjYW5ub3QgYmUgdXNlZCBpbiBhbnkNCiBjb250ZXh0IHdo ZXJlIGFuIElEIFRva2VuIGlzIHVzZWQuIFRoZSB2YWx1ZSBvZiB0aGlzIENsYWltIE1VU1QgYmUg dGhlIEpTT04gYm9vbGVhbiB2YWx1ZQ0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjoj MDAzMzY2Ij50cnVlPC9zcGFuPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6YmxhY2siPi4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzAwMjA2MCI+VGhpcyBjbGFpbSBpcyBjdXJyZW50bHkgdXNlZCB0 byDigJx0eXBl4oCdIHRoZSBsb2dvdXQgdG9rZW4uJm5ic3A7IENoYW5naW5nIGZyb20g4oCcbG9n b3V0X29ubHnigJ06dHJ1ZSB0byDigJxqdHnigJ06IOKAnGxvZ291dOKAnSBvciBzb21ldGhpbmcg c2ltaWxhciB3b3VsZCBiZSBmaW5lLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDAyMDYwIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwMjA2MCI+Sm9obiBzdWdnZXN0ZWQgdGhhdCB3ZSBw cm9oaWJpdCB0aGUgaW5jbHVzaW9uIG9mIOKAnG5vbmNl4oCdIGFzIGEgc2Vjb25kIHdheSBvZiBl bnN1cmluZyB0aGF0IHRoYXQgdG9rZW4gY291bGRu4oCZdCBiZSByZXB1cnBvc2VkIGFzIGFuIElE IFRva2VuLiZuYnNwOyBUaGF0IHdvdWxkIHdvcmsNCiBldmVuIGlmIHRoZSBjb2RlIHdhc27igJl0 IGNoZWNraW5nIGZvciDigJxsb2dvdXRfb25seeKAnSBvciDigJxqdHnigJ0uPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDAyMDYwIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgLS0gTWlrZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDAyMDYwIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij4gSWQtZXZlbnQgWzxhIGhyZWY9Im1haWx0bzppZC1ldmVudC1ib3VuY2VzQGlldGYub3Jn Ij5tYWlsdG86aWQtZXZlbnQtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2Yg PC9iPldpbGxpYW0gRGVubmlzczxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIE5vdmVtYmVy IDA0LCAyMDE1IDQ6NTQgUE08YnI+DQo8Yj5Ubzo8L2I+IEp1c3RpbiBSaWNoZXI8YnI+DQo8Yj5D Yzo8L2I+IEpvaG4gQnJhZGxleTsgPGEgaHJlZj0ibWFpbHRvOmlkLWV2ZW50QGlldGYub3JnIj5p ZC1ldmVudEBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtJZC1ldmVudF0g RGlzdGluZ3Vpc2hpbmcgZGlmZmVyZW50IEpXVCB0eXBlczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5GYWlyIHBvaW50cy4gTXkgbWFpbiBjb25jZXJuIGlzIHRo YXQgd2UgZG9uJ3QgYWx3YXlzIGtub3cgaG93IHBlb3BsZSB0cmVhdCBJRCBUb2tlbnMgKG9yIEpX VHMgbW9yZSBnZW5lcmFsbHkpLCBhbmQgb25lIG9mIHRoZWlyIG5pY2UgcHJvcGVydGllcyBpcyB0 aGF0IHRoZXkgYXJlIGRlc2lnbmVkIHRvIGJlIHZlcmlmaWFibGUgaWYgdHJhbnNtaXR0ZWQgb3Zl ciBhbiB1bnRydXN0ZWQgbWVkaXVtLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRoaW5rIHdlIGNhbiBidWlsZCBpbiBtb3JlIHByb3RlY3Rp b24gZ29pbmcgZm9yd2FyZCBieSBoYXZpbmcgYSBjbGVhciB0eXBlIGluZGljYXRvci4gSW1hZ2lu ZSBoYXZpbmcgNiBkaWZmZXJlbnQgSldUIHR5cGVzLCBhbGwgcG90ZW50aWFsbHkgdmFsaWRhdGlu ZyBhcyB0aGUgb3RoZXIgdHlwZXMuIEl0IHNlZW1zIGRhbmdlcm91cyBpZiB0aGUgb25seSBwcm90 ZWN0aW9uIGlzIHRoYXQgdGhleSBzaG91bGRuJ3QNCiBiZSBhY2NlcHRlZCBvdXRzaWRlIHRoZWly IGludGVuZGVkIGZsb3dzLCBhbmQgYWxzbyBkb3ducmlnaHQgY29uZnVzaW5nIGFzIHRoZXkgYWxs IGxvb2sgc2ltaWxhci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+UmVtb3ZpbmcgZmllbGRzIHRvIGJyZWFrIHBvdGVudGlhbCByZS11c2UgZG9l c24ndCBzY2FsZSwgYW5kIGRvZXNuJ3QgaGVscCB1bmRlcnN0YW5kYWJpbGl0eSBlaXRoZXIuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24g V2VkLCBOb3YgNCwgMjAxNSBhdCA0OjI0IFBNLCBKdXN0aW4gUmljaGVyICZsdDs8YSBocmVmPSJt YWlsdG86anJpY2hlckBtaXQuZWR1IiB0YXJnZXQ9Il9ibGFuayI+anJpY2hlckBtaXQuZWR1PC9h PiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SeKAmW0gdmVyeSBtdWNoIGluIGZhdm9yIG9mIGhhdmluZyBhIEpXVCB0b2tlbiB0eXBlIGtleSwg YnV0IGZvciBvdGhlciByZWFzb25zIGFuZCB1c2VzLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SeKAmW0ganVzdCB0YWtpbmcgaXNzdWUgd2l0aCB0 aGUgYXNzZXJ0aW9uIHRoYXQgYSBsb2dvdXQgdG9rZW4gY291bGQgYmUgZWFzaWx5IGNvbmZ1c2Vk IGJ5IGEgZnVuY3Rpb25pbmcgT0lEQyBjbGllbnQuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5FdmVuIHRoZW4gSSB0aGluayBpdOKAmXMgYSBnb29kIGlkZWEg dG8gaGF2ZSBhIOKAnHR5cCZxdW90Ozog4oCcbG9nb3V04oCdIHRhZyBpbiBpdC4gVGhlIGN1cnJl bnQgZ3VpZGVsaW5lIHRvIHRha2UgdGhlIOKAnG5vbmNl4oCdIG91dCBpcyBhIHByb2ZvdW5kbHkg c3R1cGlkIGhhY2sgdGhhdOKAmXMgbm90IGxpa2VseSB0byBtYWtlIG11Y2ggZGlmZmVyZW5jZSBp biB0aGUgcmVhbCB3b3JsZCwgb3IgYXQgbGVhc3QgZXZlbiBsZXNzIG9mIGEgZGlmZmVyZW5jZQ0K IHRoYW4gYSB0eXBlIHBhcmFtZXRlci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+QWxvbmcgdGhvc2UgbGluZXMsIEnigJlkIHN1Z2dlc3Qgd2Ug dXNlIOKAnGp0dCZxdW90OyBvciDigJxKU09OICh3ZWIpIFRva2VuIFR5cGXigJ0gYXMgdGhlIGZp ZWxkIG5hbWUsIHNvIHdlIGRvbuKAmXQgY2F1c2UgY29uZnVzaW9uIHdpdGggdGhlIGhlYWRlciDi gJx0eXDigJ0gcGFyYW1ldGVyLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjojODg4ODg4Ij4mbmJzcDvigJQgSnVzdGluPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5PbiBOb3YgNCwgMjAxNSwgYXQgNDowNiBQTSwgSm9obiBCcmFkbGV5ICZsdDs8YSBocmVmPSJt YWlsdG86dmU3anRiQHZlN2p0Yi5jb20iIHRhcmdldD0iX2JsYW5rIj52ZTdqdGJAdmU3anRiLmNv bTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+SW4gcHJpbmNpcGFsIGEgY2xpZW50IGdldHMgYSB0b2tlbiB0d28gd2F5cy4gJm5ic3A7 PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MSB2aWEgYSB0b2tl biBlbmRwb2ludCBpbiBhIGRpcmVjdCBjb21tdW5pY2F0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MiB2aWEgdGhlIGF1dGhvcml6YXRpb24g ZW5kcG9pbnQsIEluIHRoaXMgY2FzZSBhIGNsaWVudCBuZWVkcyB0byBjaGVjayB0aGUgbm9uY2Ug dmFsdWUgdG8gY29ycmVsYXRlIHRoZSB0b2tlbiB3aXRoIHRoZSB1c2VyIGFnZW50IHRoYXQgdGhl IHJlcXVlc3Qgd2FzIG1hZGUgdmlhLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRoaW5rIGl0IGlzIGZhaXIgbm90IHRvIGhhdmUgYSBub25j ZSBpbiB0aGUgb3RoZXIgdG9rZW5zIGFzIHRoZXkgYXJlIG5vdCByZXF1ZXN0ZWQgdmlhIHRoZSBi cm93c2VyLiZuYnNwOyBOb25jZSB3b3VsZCBhbHNvIG5vdCBiZSBhcHByb3ByaWF0ZSBmb3IgYSBK V1QgYXNzZXJ0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5JIHdvdWxkIGJlIG1vcmUgd29ycmllZCBhYm91dCBvdGhlciBzb3J0cyBvZiBh c3NlcnRpb25zIGJlaW5nIGNvbmZ1c2VkLCBvciBhdC1sZWFzdCBub3QgZWFzaWx5IGRpZmZlcmVu dGlhdGVkLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5JIGRvbuKAmXQgdGhpbmsgaGF2aW5nIGEgZXhwbGljaXQgSldUIHRva2VuIHR5 cGUgYmVpbmcgYSBiYWQgdGhpbmcuICZuYnNwOyBBZGRpbmcgaXQgd291bGQgbm90IGRpc3J1cHQg ZXhpc3RpbmcgY2xpZW50cy4gJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgdGhpbmsgaXQgaXMgbW9yZSBhIGNhc2Ugb2YgZGV0ZXJt aW5pbmcgaWYgdGhpcyB3aWxsIGJlIHVzZWZ1bCBmb3Igb3RoZXIgdGhpbmdzLiAmbmJzcDsgSW4g Y29ubmVjdCBpdCB3b3VsZCByZWFsbHkgb25seSBoZWxwIGJhZGx5IGNvZGVkIGNsaWVudHMgd2hv IGFyZSB1bmxpa2VseSB0byBjaGVjayBpdCBhbnl3YXkuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkpvaG4gQi48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE5vdiA0LCAyMDE1LCBhdCAy OjM2IFBNLCBKdXN0aW4gUmljaGVyICZsdDs8YSBocmVmPSJtYWlsdG86anJpY2hlckBtaXQuZWR1 IiB0YXJnZXQ9Il9ibGFuayI+anJpY2hlckBtaXQuZWR1PC9hPiZndDsgd3JvdGU6PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRoaW5rIGEgcmVhbCBxdWVz dGlvbiB3aXRoIHJlZ2FyZCB0byB0aGUgbG9naW4vbG9nb3V0IGNhc2UgaXMsIHN1Y2NpbmN0bHks IOKAnFdoeSBpcyBhbiBhcHBsaWNhdGlvbiBhY2NlcHRpbmcgYW4gSUQgdG9rZW4gZnJvbSBhbiB1 bmtub3duIHRoaXJkLXBhcnR5IGFzIHByb29mIG9mIGxvZ2lu4oCdPyBJbiB0aGUgbm9ybWFsIE9J REMgcHJvY2VzcywgdGhlIGNsaWVudCB3aWxsIG9ubHkgZ2V0IHRoZSBJRCB0b2tlbg0KIGluIHJl c3BvbnNlIHRvIGFuIGF1dGhlbnRpY2F0aW9uIHJlcXVlc3QsIHNvIGl0IHNob3VsZG7igJl0IGV2 ZXIgYmUganVzdCBsaXN0ZW5pbmcgZm9yIGluY29taW5nIElEIHRva2Vucy48bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwO+KAlCBKdXN0aW48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE5vdiA0 LCAyMDE1LCBhdCAyOjE5IFBNLCBXaWxsaWFtIERlbm5pc3MgJmx0OzxhIGhyZWY9Im1haWx0bzp3 ZGVubmlzc0Bnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+d2Rlbm5pc3NAZ29vZ2xlLmNvbTwv YT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SGkgRXZlcnlvbmUsPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5JdCB3YXMgZ29vZCB0YWxraW5nIHRvIG1hbnkgb2YgeW91IGF0IFlva29oYW1hIGVhcmxp ZXIgaW4gdGhlIHdlZWsgYWJvdXQgdXNpbmcgSldUcyBmb3IgZXZlbnQgbWVzc2FnZXMgbGlrZSBM b2dvdXQsIFJpc2sgU2lnbmFscywgU0NJTSBwcm9maWxlIHVwZGF0ZXMgYW5kIG1vcmUuIFRoYW5r IHlvdSBQaGlsIGZvciBzdGFydGluZyB0aGlzIGNvbnZlcnNhdGlvbiBhbmQgc3Bpbm5pbmcgdXAg dGhlIGxpc3QhIFdlJ3JlDQogYWxsIGRvaW5nIHJlbGF0ZWQgdGhpbmdzIHdpdGggZXZlbnRzLCBh bmQgaXQgbWFrZXMgc2Vuc2UgdG8gY29sbGFib3JhdGUgYW5kIHVuaWZ5IG91ciBhcHByb2FjaGVz LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5B biBpc3N1ZSB3aXRoIEpXVCByZXVzZSBjdXJyZW50bHkgaXMgdGhhdCBJRCBUb2tlbnMgYXJlIDxh IGhyZWY9Imh0dHA6Ly9vcGVuaWQubmV0L3NwZWNzL29wZW5pZC1jb25uZWN0LWNvcmUtMV8wLmh0 bWwjSURUb2tlbiIgdGFyZ2V0PSJfYmxhbmsiPg0KZGVmaW5lZDwvYT4mbmJzcDtieSBPcGVuSUQg Q29ubmVjdCB0byByZXF1aXJlIG9ubHkgYSBmZXcgPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL3JmYzc1MTkjc2VjdGlvbi00IiB0YXJnZXQ9Il9ibGFuayI+DQpzdGFuZGFyZCBK V1QgY2xhaW1zPC9hPiwgYW5kIHRoZSByZXF1aXJlZCBjbGFpbXMgYXJlIGhpZ2hseSByZS11c2Fi bGUgYW5kIGNvbnRhaW4gbm90aGluZyB0aGF0IGFjdHVhbGx5IHNldHMgdGhlbSBhcGFydCBhcyBh biAmcXVvdDtJRCBUb2tlbiZxdW90Oy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIHJpc2sgb2YgdGhpcyBpcyB0aGF0IGEgSldUIGZvciBh biBldmVudCBsaWtlIGxvZ291dCBjYW4gYmUgYSB2YWxpZCBJRCBUb2tlbiBmb3IgbG9naW4uJm5i c3A7IEFuIGF0dGFja2VyIGluIHBvc3Nlc3Npb24gb2YgYSBsb2dvdXQgdG9rZW4gY291bGQgcmVw bGF5IGl0IGFnYWluc3QgYSBsb2dpbiBlbmRwb2ludCwgYW5kIGdhaW4gYWNjZXNzLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbmUgbWl0aWdh dGlvbiBpcyB0byBjaGFuZ2UgdGhlIGlzc3Vlciwgb3IgYXVkaWVuY2UuIFRvIG1lIHRoaXMgaXMg dW5kZXNpcmFibGUgYXMgdGhlIGV2ZW50cyAoZS5nLiBsb2dvdXQpIGRvIHJlbGF0ZSB0byB0aGUg c2FtZSBpc3N1ZXIgYW5kIGF1ZGllbmNlLiBMaWtlIG1hdHRlciBhbmQgYW50aS1tYXR0ZXIsIHlp biBhbmQgeWFuZyDigJMgbG9nb3V0IHNob3VsZCBzaW1wbHkgcmV2ZXJzZSB0aGUgbG9naW4uJm5i c3A7IEl0DQogc2VlbXMgd2FzdGVmdWwgdG8gc3BpbiB1cCBhIG5ldyBpc3N1ZXIsIG5ldyBrZXkg cm90YXRpb25zLCBhbmQgbW9yZSBqdXN0IHRvIG1hbmFnZSBlYWNoIGRpZmZlcmVudCB0eXBlIG9m IGV2ZW50LCBpZiB0aGV5IHdvdWxkIG90aGVyd2lzZSBiZSByZWxhdGVkIGJ5IGlzc3Vlci48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q3VycmVu dGx5IHRoZSA8YSBocmVmPSJodHRwOi8vb3BlbmlkLm5ldC9zcGVjcy9vcGVuaWQtY29ubmVjdC1i YWNrY2hhbm5lbC0xXzAuaHRtbCIgdGFyZ2V0PSJfYmxhbmsiPg0KQmFja2NoYW5uZWwgTG9nb3V0 IGRyYWZ0PC9hPiBhdHRlbXB0cyB0byAmcXVvdDticmVhayZxdW90OyB0aGlzIHV0aWxpdHkgb2Yg YSBsb2dvdXQgSldUIGZvciBhdXRoZW50aWNhdGlvbiBieSBwcm9oaWJpdGluZyB0aGUmbmJzcDsn bm9uY2UnIGZpZWxkOjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDo1LjBwdDttYXJnaW4tcmlnaHQ6MjQuMHB0O21hcmdpbi1ib3R0b206NS4wcHQ7bWFyZ2luLWxl ZnQ6MjQuMHB0Ij4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlRoZSBmb2xsb3dpbmcgQ2xhaW0gTVVTVCBOT1QgYmUg dXNlZCB3aXRoaW4gdGhlIExvZ291dCBUb2tlbjo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 IHN0eWxlPSJtYXJnaW4tbGVmdDoyNC4wcHQ7bWFyZ2luLXJpZ2h0OjI0LjBwdCI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+bm9uY2U8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+UFJPSElCSVRFRC4gQSZuYnNwOzwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6IzAwMzM2NiI+bm9uY2U8L3NwYW4+PC90dD48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij4mbmJzcDtDbGFpbSBNVVNUIE5PVCBiZSBwcmVzZW50Lg0KIEl0cyB1c2UgaXMgcHJvaGli aXRlZCB0byBtYWtlIGEgTG9nb3V0IFRva2VuIHN5bnRhY3RpY2FsbHkgaW52YWxpZCBpZiB1c2Vk IGluIGEgZm9yZ2VkIEF1dGhlbnRpY2F0aW9uIFJlc3BvbnNlIGluIHBsYWNlIG9mIGFuIElEIFRv a2VuLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkknbSBjb25jZXJuZWQg dGhhdCB0aGlzIG1heSBub3QgYWx3YXlzIHdvcmsgYXMgaW50ZW5kZWQsIGFzICdub25jZScgaXMg bm90IGEgcmVxdWlyZWQgZmllbGQgb2YgdGhlIElEIFRva2VuLiBJRCBUb2tlbnMgb2J0YWluZWQg ZnJvbSBHb29nbGUgdXNpbmcgdGhlIGNvZGUgZmxvdyAob24gb3VyIE9wZW5JRCBDb25uZWN0IGNl cnRpZmllZCBlbmRwb2ludHMpIGRvIG5vdCBjb250YWluICdub25jZScgdG9kYXksIGZvcg0KIGV4 YW1wbGUuIEFuZCBJJ20gYSBsaXR0bGUgd29ycmllZCB0aGF0IFJQcyBtYXkgbm90IGJlIHN0cmlj dGx5IGNoZWNraW5nIGZvciBhICdub25jZScsIGV2ZW4gd2hlbiB0aGV5IHNob3VsZCAoZS5nLiB3 aGVuIHVzaW5nIHRoZSBpbXBsaWNpdCBmbG93KS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RXZlbiBpZiB0aGlzIGFwcHJvYWNoIHdvcmtzIGlu IHRoaXMgc3BlY2lmaWMgY2FzZSwgaXQncyBub3Qgc2NhbGFibGUuIFNvIEkgcHJvcG9zZSB0aGF0 IHdlIG1vdmUgdG8gYWRvcHQgYSBuZXcgc3RhbmRhcmQgY2xhaW0gdGhhdCBjYW4gYmUgdXNlZCB0 byBpbmRpY2F0ZSB0aGUgaW50ZW5kZWQgcHVycG9zZSBvZiB0aGUgSldULjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4ndHlwJyBpcyBhbiBvYnZp b3VzIGNob2ljZSBmb3IgYSBjbGFpbSBuYW1lLCBhbHRob3VnaCB0aGUgd29yZCAndHlwZScgbWF5 IGJlIGEgbGl0dGxlIG92ZXJsb2FkZWQgYWxyZWFkeS4gQW5vdGhlciBvcHRpb24gY291bGQgYmUg JnF1b3Q7Y2F0JnF1b3Q7IGZvciBjYXRlZ29yeS4mbmJzcDsgV2hhdGV2ZXIgd2UgZGVjaWRlLCBJ IHRoaW5rIHN1Y2ggYSBjbGFpbSBzaG91bGQgYmUgdXNlZCBpbiBhbGwgSldUIHNwZWNzIGdvaW5n IGZvcndhcmQsDQogYW5kIGFkZGVkIHRvIE9wZW5JRCBDb25uZWN0IElEIFRva2VucyBpbiBhIGZ1 dHVyZSByZXZpc2lvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+V2lsbGlhbTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPGJyPg0KSWQtZXZlbnQgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFp bHRvOklkLWV2ZW50QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+SWQtZXZlbnRAaWV0Zi5vcmc8 L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9p ZC1ldmVudCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vaWQtZXZlbnQ8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188YnI+DQpJZC1ldmVudCBtYWlsaW5nIGxpc3Q8YnI+DQo8 YSBocmVmPSJtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5JZC1ldmVu dEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2lkLWV2ZW50IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9pZC1ldmVudDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BY2PR03MB4426EDB56EC4CA0B4922662F52A0BY2PR03MB442namprd_-- From nobody Wed Nov 4 00:17:07 2015 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63F071A0045 for ; Wed, 4 Nov 2015 00:17:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V6ODtJ1UOazY for ; Wed, 4 Nov 2015 00:16:59 -0800 (PST) Received: from mail-qg0-x235.google.com (mail-qg0-x235.google.com [IPv6:2607:f8b0:400d:c04::235]) (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 E3C8A1A000B for ; Wed, 4 Nov 2015 00:16:58 -0800 (PST) Received: by qgbb65 with SMTP id b65so34408477qgb.2 for ; Wed, 04 Nov 2015 00:16:58 -0800 (PST) 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 :cc:content-type; bh=UjpAdJhcDaO1oWU18FsiErgmVOZzRANlmhfXYLg3COE=; b=duIxR5wf5CPWyZcdSQkt+855/lS0xHiCC5rURol98XS5fSPpnOBKhqD9QfGjYpvjTK bsxnIF4r+UtC46uscaWoptXMBSJkXJPui3StCujpuQK7QBwJLlQqk2N3RoXJS/q87VA8 Whx9TM7BSv4xZAOTYSbnQylqUwfpGwlYPVAnw4qH9jMpK3wSaXkK09Jq4Bykt5KSrozO zVp5FpuD0gZXbYY9xYozK+4gEe9ezqb7aIkhx1sqyu775L0vxGVO6VF3D5JYRob4+ZRu QaKAF2VaZw64sXEmV1yZRV7NpLExqheF2C44MzDTkH7SmJM/TZMWBHUAgGkTj1WvbA3y AwMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=UjpAdJhcDaO1oWU18FsiErgmVOZzRANlmhfXYLg3COE=; b=Hwr1A3H8/qiFoXyfchpRRcwA8OavVBZExun1lpR6I0LI3QiWtlfIA4YHjou/VP7yDx QG0zvEW8rj7j9d8+BTbqi+v2aABJ2Git82snJ9+gBj1+zFsd/p2/jELPxjSaiMunQNZs iBX2r6aHXxm+acYDiQfXThuk7IEz3FMicDndtcI2Qmnhk/8w4uhGjf0Z0XtkP1NQSos5 Cu2ebctQw8X29KUDuOVgIdhrRPLcqxldAYLs1P0jmj/J9mtmR9YIrIC1DRYTTqpIK8Vy gZGBGNHkRr0FjsV7dXW5akxkQQXNh4goiVF7GrN2qUTG+JqWc/eQBzbdimJ/20Jlm3qH 0LMA== X-Gm-Message-State: ALoCoQn1S1CwfjcpMYNeVNQGPi6+b6lxbn180EhqmtHoCsQXmrsyHPckImu1XklAPqkgu7pPhYDB X-Received: by 10.140.82.213 with SMTP id h79mr188701qgd.26.1446625017905; Wed, 04 Nov 2015 00:16:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.102.18 with HTTP; Wed, 4 Nov 2015 00:16:38 -0800 (PST) In-Reply-To: References: <7A2911BB-0B39-4A61-8767-6A0D24012363@mit.edu> <0EE00ED6-D344-4B92-9A05-8FFB7BCB6BF0@mit.edu> From: William Denniss Date: Wed, 4 Nov 2015 17:16:38 +0900 Message-ID: To: Mike Jones Content-Type: multipart/alternative; boundary=001a11c12fd6510cda0523b2a2a0 Archived-At: Cc: John Bradley , "id-event@ietf.org" , Justin Richer Subject: Re: [Id-event] Distinguishing different JWT types X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2015 08:17:06 -0000 --001a11c12fd6510cda0523b2a2a0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sounds good to me, I like that "jty":"logout" is more extensible than "logout_only":true I support trying to prevent repurposing of the backchannel logout JWT, and not including "nonce" seems reasonable. It just makes me wish OIDC ID Tokens had a "jty":"id_token" claim, as that is a lot more clear. Going forward, each new token type shouldn't be removing claims other types use just to break potential cross-type usage, hence why I proposed this. btw. I was also thinking of 'jty' ("JWT Type") as the claim name. Reads well to me, and isn't ambiguous :) On Wed, Nov 4, 2015 at 5:04 PM, Mike Jones wrote: > The part of this thread dealing with logout should have included a > reference to this text in > http://openid.net/specs/openid-connect-backchannel-1_0-01.html#LogoutToke= n > : > > > > logout_only > > REQUIRED. Value declaring that this JWT is only to be used as a Logout > Token. In particular, this JWT cannot be used in any context where an ID > Token is used. The value of this Claim MUST be the JSON boolean value tru= e. > > > > > This claim is currently used to =E2=80=9Ctype=E2=80=9D the logout token. = Changing from > =E2=80=9Clogout_only=E2=80=9D:true to =E2=80=9Cjty=E2=80=9D: =E2=80=9Clog= out=E2=80=9D or something similar would be fine. > > > > John suggested that we prohibit the inclusion of =E2=80=9Cnonce=E2=80=9D = as a second way > of ensuring that that token couldn=E2=80=99t be repurposed as an ID Token= . That > would work even if the code wasn=E2=80=99t checking for =E2=80=9Clogout_o= nly=E2=80=9D or =E2=80=9Cjty=E2=80=9D. > > > > -- Mike > > > > *From:* Id-event [mailto:id-event-bounces@ietf.org] *On Behalf Of *Willia= m > Denniss > *Sent:* Wednesday, November 04, 2015 4:54 PM > *To:* Justin Richer > *Cc:* John Bradley; id-event@ietf.org > *Subject:* Re: [Id-event] Distinguishing different JWT types > > > > Fair points. My main concern is that we don't always know how people trea= t > ID Tokens (or JWTs more generally), and one of their nice properties is > that they are designed to be verifiable if transmitted over an untrusted > medium. > > > > I think we can build in more protection going forward by having a clear > type indicator. Imagine having 6 different JWT types, all potentially > validating as the other types. It seems dangerous if the only protection = is > that they shouldn't be accepted outside their intended flows, and also > downright confusing as they all look similar. > > > > Removing fields to break potential re-use doesn't scale, and doesn't help > understandability either. > > > > > > On Wed, Nov 4, 2015 at 4:24 PM, Justin Richer wrote: > > I=E2=80=99m very much in favor of having a JWT token type key, but for ot= her > reasons and uses. > > > > I=E2=80=99m just taking issue with the assertion that a logout token coul= d be > easily confused by a functioning OIDC client. > > > > Even then I think it=E2=80=99s a good idea to have a =E2=80=9Ctyp": =E2= =80=9Clogout=E2=80=9D tag in it. > The current guideline to take the =E2=80=9Cnonce=E2=80=9D out is a profou= ndly stupid hack > that=E2=80=99s not likely to make much difference in the real world, or a= t least > even less of a difference than a type parameter. > > > > Along those lines, I=E2=80=99d suggest we use =E2=80=9Cjtt" or =E2=80=9CJ= SON (web) Token Type=E2=80=9D as > the field name, so we don=E2=80=99t cause confusion with the header =E2= =80=9Ctyp=E2=80=9D parameter. > > > > =E2=80=94 Justin > > > > On Nov 4, 2015, at 4:06 PM, John Bradley wrote: > > > > In principal a client gets a token two ways. > > 1 via a token endpoint in a direct communication. > > 2 via the authorization endpoint, In this case a client needs to check th= e > nonce value to correlate the token with the user agent that the request w= as > made via. > > > > I think it is fair not to have a nonce in the other tokens as they are no= t > requested via the browser. Nonce would also not be appropriate for a JWT > assertion. > > > > I would be more worried about other sorts of assertions being confused, o= r > at-least not easily differentiated. > > > > I don=E2=80=99t think having a explicit JWT token type being a bad thing.= Adding > it would not disrupt existing clients. > > > > I think it is more a case of determining if this will be useful for other > things. In connect it would really only help badly coded clients who ar= e > unlikely to check it anyway. > > > > John B. > > > > On Nov 4, 2015, at 2:36 PM, Justin Richer wrote: > > > > I think a real question with regard to the login/logout case is, > succinctly, =E2=80=9CWhy is an application accepting an ID token from an = unknown > third-party as proof of login=E2=80=9D? In the normal OIDC process, the c= lient will > only get the ID token in response to an authentication request, so it > shouldn=E2=80=99t ever be just listening for incoming ID tokens. > > > > =E2=80=94 Justin > > > > On Nov 4, 2015, at 2:19 PM, William Denniss wrote: > > > > Hi Everyone, > > > > It was good talking to many of you at Yokohama earlier in the week about > using JWTs for event messages like Logout, Risk Signals, SCIM profile > updates and more. Thank you Phil for starting this conversation and > spinning up the list! We're all doing related things with events, and it > makes sense to collaborate and unify our approaches. > > > > An issue with JWT reuse currently is that ID Tokens are defined > by OpenID > Connect to require only a few standard JWT claims > , and the required claims > are highly re-usable and contain nothing that actually sets them apart as > an "ID Token". > > > > The risk of this is that a JWT for an event like logout can be a valid ID > Token for login. An attacker in possession of a logout token could repla= y > it against a login endpoint, and gain access. > > > > One mitigation is to change the issuer, or audience. To me this is > undesirable as the events (e.g. logout) do relate to the same issuer and > audience. Like matter and anti-matter, yin and yang =E2=80=93 logout shou= ld simply > reverse the login. It seems wasteful to spin up a new issuer, new key > rotations, and more just to manage each different type of event, if they > would otherwise be related by issuer. > > > > Currently the Backchannel Logout draft > attempts to > "break" this utility of a logout JWT for authentication by prohibiting > the 'nonce' field: > > The following Claim MUST NOT be used within the Logout Token: > > > > nonce > > PROHIBITED. A nonce Claim MUST NOT be present. Its use is prohibited to > make a Logout Token syntactically invalid if used in a forged > Authentication Response in place of an ID Token. > > > > I'm concerned that this may not always work as intended, as 'nonce' is no= t > a required field of the ID Token. ID Tokens obtained from Google using th= e > code flow (on our OpenID Connect certified endpoints) do not contain > 'nonce' today, for example. And I'm a little worried that RPs may not be > strictly checking for a 'nonce', even when they should (e.g. when using t= he > implicit flow). > > > > Even if this approach works in this specific case, it's not scalable. So = I > propose that we move to adopt a new standard claim that can be used to > indicate the intended purpose of the JWT. > > > > 'typ' is an obvious choice for a claim name, although the word 'type' may > be a little overloaded already. Another option could be "cat" for > category. Whatever we decide, I think such a claim should be used in all > JWT specs going forward, and added to OpenID Connect ID Tokens in a futur= e > revision. > > > > 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 > > > > > > > --001a11c12fd6510cda0523b2a2a0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sounds good to me, I like that "jty":"logou= t" is more extensible than "logout_only":true

=
I support trying to prevent repurposing of the backchannel logout JWT,= and not including "nonce" seems reasonable. It just makes me wis= h OIDC ID Tokens had a "jty":"id_token" claim, as that = is a lot more clear.=C2=A0 Going forward, each new token type shouldn't= be removing claims other types use just to break potential cross-type usag= e, hence why I proposed this.

btw. I was = also thinking of 'jty' ("JWT Type") as the claim name. Re= ads well to me, and isn't ambiguous :)

On Wed, Nov 4, 2015 at 5:04 PM, = Mike Jones <Michael.Jones@microsoft.com> wrote:

The part of this thread d= ealing with logout should have included a reference to this text in http://openid.net/specs/openid-connect-backchannel-1_0-01.html#LogoutToken<= /a>:

=C2=A0

logout_only<= /u>

REQUIRED. Value declaring that this JWT is only to be used as= a Logout Token. In particular, this JWT cannot be used in any context where an ID Token is used. The value of this Claim MUST be the JSO= N boolean value true= .

=C2=A0

This claim is currently u= sed to =E2=80=9Ctype=E2=80=9D the logout token.=C2=A0 Changing from =E2=80= =9Clogout_only=E2=80=9D:true to =E2=80=9Cjty=E2=80=9D: =E2=80=9Clogout=E2= =80=9D or something similar would be fine.

=C2=A0

John suggested that we pr= ohibit the inclusion of =E2=80=9Cnonce=E2=80=9D as a second way of ensuring= that that token couldn=E2=80=99t be repurposed as an ID Token.=C2=A0 That = would work even if the code wasn=E2=80=99t checking for =E2=80=9Clogout_only=E2=80=9D= or =E2=80=9Cjty=E2=80=9D.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mike

=C2=A0

From: Id-event= [mailto:id-= event-bounces@ietf.org] On Behalf Of William Denniss
Sent: Wednesday, November 04, 2015 4:54 PM
To: Justin Richer
Cc: John Bradley; id-event@ietf.org
Subject: Re: [Id-event] Distinguishing different JWT types=

=C2=A0

Fair points. My main concern is that we don't al= ways know how people treat ID Tokens (or JWTs more generally), and one of t= heir nice properties is that they are designed to be verifiable if transmit= ted over an untrusted medium.

=C2=A0

I think we can build in more protection going forwar= d by having a clear type indicator. Imagine having 6 different JWT types, a= ll potentially validating as the other types. It seems dangerous if the onl= y protection is that they shouldn't be accepted outside their intended flows, and also downright confusing as = they all look similar.

=C2=A0

Removing fields to break potential re-use doesn'= t scale, and doesn't help understandability either.

=C2=A0

=C2=A0

On Wed, Nov 4, 2015 at 4:24 PM, Justin Richer <jricher@mit.edu> = wrote:

I=E2=80=99m very much in favor of having a JWT token= type key, but for other reasons and uses.=C2=A0

=C2=A0

I=E2=80=99m just taking issue with the assertion tha= t a logout token could be easily confused by a functioning OIDC client.<= /u>

=C2=A0

Even then I think it=E2=80=99s a good idea to have a= =E2=80=9Ctyp": =E2=80=9Clogout=E2=80=9D tag in it. The current guidel= ine to take the =E2=80=9Cnonce=E2=80=9D out is a profoundly stupid hack tha= t=E2=80=99s not likely to make much difference in the real world, or at lea= st even less of a difference than a type parameter.

=C2=A0

Along those lines, I=E2=80=99d suggest we use =E2=80= =9Cjtt" or =E2=80=9CJSON (web) Token Type=E2=80=9D as the field name, = so we don=E2=80=99t cause confusion with the header =E2=80=9Ctyp=E2=80=9D p= arameter.

=C2=A0

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

=C2=A0

On Nov 4, 2015, at 4:06 PM, John Bradley <ve7jtb@ve7jtb.com> w= rote:

=C2=A0

In principal a client gets a token two ways. =C2=A0<= u>

1 via a token endpoint in a direct communication.=

2 via the authorization endpoint, In this case a cli= ent needs to check the nonce value to correlate the token with the user age= nt that the request was made via.

=C2=A0

I think it is fair not to have a nonce in the other = tokens as they are not requested via the browser.=C2=A0 Nonce would also no= t be appropriate for a JWT assertion.

=C2=A0

I would be more worried about other sorts of asserti= ons being confused, or at-least not easily differentiated.=C2=A0<= /u>

=C2=A0

I don=E2=80=99t think having a explicit JWT token ty= pe being a bad thing. =C2=A0 Adding it would not disrupt existing clients. = =C2=A0

=C2=A0

I think it is more a case of determining if this wil= l be useful for other things. =C2=A0 In connect it would really only help b= adly coded clients who are unlikely to check it anyway.

=C2=A0

John B.

=C2=A0

On Nov 4, 2015, at 2:36 PM, Justin Richer <jricher@mit.edu> wrot= e:

=C2=A0

I think a real question with regard to the login/log= out case is, succinctly, =E2=80=9CWhy is an application accepting an ID tok= en from an unknown third-party as proof of login=E2=80=9D? In the normal OI= DC process, the client will only get the ID token in response to an authentication request, so it shouldn=E2=80=99t ever be = just listening for incoming ID tokens.

=C2=A0

=C2=A0=E2=80=94 Justin

=C2=A0

On Nov 4, 2015, at 2:19 PM, William Denniss <wdenniss@google.com> wrote:

=C2=A0

Hi Everyone,

=C2=A0

It was good talking to many of you at Yokohama earli= er in the week about using JWTs for event messages like Logout, Risk Signal= s, SCIM profile updates and more. Thank you Phil for starting this conversa= tion and spinning up the list! We're all doing related things with events, and it makes sense to collaborate an= d unify our approaches.

=C2=A0

An issue with JWT reuse currently is that ID Tokens = are defined=C2=A0by OpenID Connect to require only a few standard JWT claims, and the required claims are highly re-usable and c= ontain nothing that actually sets them apart as an "ID Token".=

=C2=A0

The risk of this is that a JWT for an event like log= out can be a valid ID Token for login.=C2=A0 An attacker in possession of a= logout token could replay it against a login endpoint, and gain access.=

=C2=A0

One mitigation is to change the issuer, or audience.= To me this is undesirable as the events (e.g. logout) do relate to the sam= e issuer and audience. Like matter and anti-matter, yin and yang =E2=80=93 = logout should simply reverse the login.=C2=A0 It seems wasteful to spin up a new issuer, new key rotations, and more just t= o manage each different type of event, if they would otherwise be related b= y issuer.

=C2=A0

Currently the Backchannel Logout draft attempts to "break" this utility of = a logout JWT for authentication by prohibiting the=C2=A0'nonce' fie= ld:

The = following Claim MUST NOT be used within the Logout Token:

=C2=A0

nonce

PROHIBITED. A=C2=A0nonce=C2=A0Claim MU= ST NOT be present. Its use is prohibited to make a Logout Token syntactically invalid if used= in a forged Authentication Response in place of an ID Token.=

=C2=A0

I'm concerned that this may not always work as i= ntended, as 'nonce' is not a required field of the ID Token. ID Tok= ens obtained from Google using the code flow (on our OpenID Connect certifi= ed endpoints) do not contain 'nonce' today, for example. And I'm a little worried that RPs may not be strictly checkin= g for a 'nonce', even when they should (e.g. when using the implici= t flow).

=C2=A0

Even if this approach works in this specific case, i= t's not scalable. So I propose that we move to adopt a new standard cla= im that can be used to indicate the intended purpose of the JWT.<= /u>

=C2=A0

'typ' is an obvious choice for a claim name,= although the word 'type' may be a little overloaded already. Anoth= er option could be "cat" for category.=C2=A0 Whatever we decide, = I think such a claim should be used in all JWT specs going forward, and added to OpenID Connect ID Tokens in a future revision.<= /p>

=C2=A0

William

=C2=A0

=C2=A0

=C2=A0

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

=C2=A0

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

=C2=A0

=C2=A0

=C2=A0


--001a11c12fd6510cda0523b2a2a0-- From nobody Wed Nov 4 00:17:21 2015 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24CB71A004D for ; Wed, 4 Nov 2015 00:17:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ckumhVwwkgKm for ; Wed, 4 Nov 2015 00:17:17 -0800 (PST) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D449D1A0045 for ; Wed, 4 Nov 2015 00:17:16 -0800 (PST) Received: by oies66 with SMTP id s66so23917366oie.1 for ; Wed, 04 Nov 2015 00:17:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QmFLZcInMRZiPaWXv6iGeiLeXWaDwASc79Rgq9rl/Ao=; b=XpyYb4boDBlrPhyryNAkCnoNVqeWRVKlo3aYXnTmoCwWAKWs/tqQ1b52axW3XyPdPv 8l52Io/OANHQz0hSWRrCuMH64W4dpVLo98Mp1g0wscv1PQ2DWw9VcobLI+oQ0xY1GW57 uOcqPobfCXOzuJZlATA/MZYd2UeIsiyX9BJzBQnWp9kqvNjYyUdDfwxbwMwfyi8yOka1 sg9u1TDlyUnpJW2aH2bEbm5AmgH7HVdFR4KyquvJX3buFmXbT4ZFWzPSSy6ufDfvKxCw FVLM+73uaZuhwjAGDuMf13PEHkDqpj9TxYMJmE5habfANcWfQ3Tirk5DRpbGil6BFPFo oUGQ== MIME-Version: 1.0 X-Received: by 10.202.50.215 with SMTP id y206mr121623oiy.62.1446625036159; Wed, 04 Nov 2015 00:17:16 -0800 (PST) Received: by 10.182.236.196 with HTTP; Wed, 4 Nov 2015 00:17:16 -0800 (PST) In-Reply-To: References: <7A2911BB-0B39-4A61-8767-6A0D24012363@mit.edu> <0EE00ED6-D344-4B92-9A05-8FFB7BCB6BF0@mit.edu> Date: Wed, 4 Nov 2015 17:17:16 +0900 Message-ID: From: Nat Sakimura To: William Denniss Content-Type: multipart/alternative; boundary=001a113ce2c06755510523b2a35a Archived-At: Cc: John Bradley , id-event@ietf.org, Justin Richer Subject: Re: [Id-event] Distinguishing different JWT types X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2015 08:17:20 -0000 --001a113ce2c06755510523b2a35a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable When I proposed type, which morephed into typ and cty, I meant what you discribe here - an indication of what the token is. It was kind of rejecte being an application layer stuff, which is a fair point in a sense but we have limited ourselves apparently. +1 to something that represent its type. In Web Linking term, something akin of "self". Nat 2015-11-04 16:53 GMT+09:00 William Denniss : > Fair points. My main concern is that we don't always know how people trea= t > ID Tokens (or JWTs more generally), and one of their nice properties is > that they are designed to be verifiable if transmitted over an untrusted > medium. > > I think we can build in more protection going forward by having a clear > type indicator. Imagine having 6 different JWT types, all potentially > validating as the other types. It seems dangerous if the only protection = is > that they shouldn't be accepted outside their intended flows, and also > downright confusing as they all look similar. > > Removing fields to break potential re-use doesn't scale, and doesn't help > understandability either. > > > On Wed, Nov 4, 2015 at 4:24 PM, Justin Richer wrote: > >> I=E2=80=99m very much in favor of having a JWT token type key, but for o= ther >> reasons and uses. >> >> I=E2=80=99m just taking issue with the assertion that a logout token cou= ld be >> easily confused by a functioning OIDC client. >> >> Even then I think it=E2=80=99s a good idea to have a =E2=80=9Ctyp": =E2= =80=9Clogout=E2=80=9D tag in it. >> The current guideline to take the =E2=80=9Cnonce=E2=80=9D out is a profo= undly stupid hack >> that=E2=80=99s not likely to make much difference in the real world, or = at least >> even less of a difference than a type parameter. >> >> Along those lines, I=E2=80=99d suggest we use =E2=80=9Cjtt" or =E2=80=9C= JSON (web) Token Type=E2=80=9D as >> the field name, so we don=E2=80=99t cause confusion with the header =E2= =80=9Ctyp=E2=80=9D parameter. >> >> =E2=80=94 Justin >> >> On Nov 4, 2015, at 4:06 PM, John Bradley wrote: >> >> In principal a client gets a token two ways. >> 1 via a token endpoint in a direct communication. >> 2 via the authorization endpoint, In this case a client needs to check >> the nonce value to correlate the token with the user agent that the requ= est >> was made via. >> >> I think it is fair not to have a nonce in the other tokens as they are >> not requested via the browser. Nonce would also not be appropriate for = a >> JWT assertion. >> >> I would be more worried about other sorts of assertions being confused, >> or at-least not easily differentiated. >> >> I don=E2=80=99t think having a explicit JWT token type being a bad thing= . >> Adding it would not disrupt existing clients. >> >> I think it is more a case of determining if this will be useful for othe= r >> things. In connect it would really only help badly coded clients who a= re >> unlikely to check it anyway. >> >> John B. >> >> On Nov 4, 2015, at 2:36 PM, Justin Richer wrote: >> >> I think a real question with regard to the login/logout case is, >> succinctly, =E2=80=9CWhy is an application accepting an ID token from an= unknown >> third-party as proof of login=E2=80=9D? In the normal OIDC process, the = client will >> only get the ID token in response to an authentication request, so it >> shouldn=E2=80=99t ever be just listening for incoming ID tokens. >> >> =E2=80=94 Justin >> >> On Nov 4, 2015, at 2:19 PM, William Denniss wrote: >> >> Hi Everyone, >> >> It was good talking to many of you at Yokohama earlier in the week about >> using JWTs for event messages like Logout, Risk Signals, SCIM profile >> updates and more. Thank you Phil for starting this conversation and >> spinning up the list! We're all doing related things with events, and it >> makes sense to collaborate and unify our approaches. >> >> An issue with JWT reuse currently is that ID Tokens are defined >> by OpenID >> Connect to require only a few standard JWT claims >> , and the required claims >> are highly re-usable and contain nothing that actually sets them apart a= s >> an "ID Token". >> >> The risk of this is that a JWT for an event like logout can be a valid I= D >> Token for login. An attacker in possession of a logout token could repl= ay >> it against a login endpoint, and gain access. >> >> One mitigation is to change the issuer, or audience. To me this is >> undesirable as the events (e.g. logout) do relate to the same issuer and >> audience. Like matter and anti-matter, yin and yang =E2=80=93 logout sho= uld simply >> reverse the login. It seems wasteful to spin up a new issuer, new key >> rotations, and more just to manage each different type of event, if they >> would otherwise be related by issuer. >> >> Currently the Backchannel Logout draft >> attempts >> to "break" this utility of a logout JWT for authentication by prohibitin= g >> the 'nonce' field: >> >> The following Claim MUST NOT be used within the Logout Token: >> >> noncePROHIBITED. A nonce Claim MUST NOT be present. Its use is >> prohibited to make a Logout Token syntactically invalid if used in a for= ged >> Authentication Response in place of an ID Token. >> >> I'm concerned that this may not always work as intended, as 'nonce' is >> not a required field of the ID Token. ID Tokens obtained from Google usi= ng >> the code flow (on our OpenID Connect certified endpoints) do not contain >> 'nonce' today, for example. And I'm a little worried that RPs may not be >> strictly checking for a 'nonce', even when they should (e.g. when using = the >> implicit flow). >> >> Even if this approach works in this specific case, it's not scalable. So >> I propose that we move to adopt a new standard claim that can be used to >> indicate the intended purpose of the JWT. >> >> 'typ' is an obvious choice for a claim name, although the word 'type' ma= y >> be a little overloaded already. Another option could be "cat" for >> category. Whatever we decide, I think such a claim should be used in al= l >> JWT specs going forward, and added to OpenID Connect ID Tokens in a futu= re >> revision. >> >> 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 > > --=20 Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --001a113ce2c06755510523b2a35a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
When I proposed type, which morephed into typ and cty, I m= eant what you discribe here - an indication of what the token is. It was ki= nd of rejecte being an application layer stuff, which is a fair point in a = sense but we have limited ourselves apparently. +1 to something that repres= ent its type. In Web Linking term, something akin of "self".=C2= =A0

Nat

2015-11-04 16:53 GMT+09:00 William Denniss <wdenn= iss@google.com>:
Fair points. My main concern is that we don't always know= how people treat ID Tokens (or JWTs more generally), and one of their nice= properties is that they are designed to be verifiable if transmitted over = an untrusted medium.

I think we can build in more = protection going forward by having a clear type indicator. Imagine having 6= different JWT types, all potentially validating as the other types. It see= ms dangerous if the only protection is that they shouldn't be accepted = outside their intended flows, and also downright confusing as they all look= similar.

Removing fields to break potential re-us= e doesn't scale, and doesn't help understandability either.


On Wed, Nov 4, 2015 at 4:24 PM, J= ustin Richer <jricher@mit.edu> wrote:
I=E2=80=99m very much in favo= r of having a JWT token type key, but for other reasons and uses.=C2=A0
I=E2=80=99m just taking issue with the assertion that a log= out token could be easily confused by a functioning OIDC client.

Even then I think it=E2=80=99s a good idea to have a =E2=80=9Ctyp&= quot;: =E2=80=9Clogout=E2=80=9D tag in it. The current guideline to take th= e =E2=80=9Cnonce=E2=80=9D out is a profoundly stupid hack that=E2=80=99s no= t likely to make much difference in the real world, or at least even less o= f a difference than a type parameter.

Along those = lines, I=E2=80=99d suggest we use =E2=80=9Cjtt" or =E2=80=9CJSON (web)= Token Type=E2=80=9D as the field name, so we don=E2=80=99t cause confusion= with the header =E2=80=9Ctyp=E2=80=9D parameter.

=C2=A0=E2=80=94 Justin

On Nov 4, 2015, at 4:06= PM, John Bradley <ve7jtb@ve7jtb.com> wrote:

In principal a client gets a token two = ways. =C2=A0
1 via a token endpoint in a direct communication.
2 via the authorization endpoint, In this case a client needs to check th= e nonce value to correlate the token with the user agent that the request w= as made via.

I think it is fair not to have a nonc= e in the other tokens as they are not requested via the browser.=C2=A0 Nonc= e would also not be appropriate for a JWT assertion.

I would be more worried about other sorts of assertions being confused, = or at-least not easily differentiated.=C2=A0

I don= =E2=80=99t think having a explicit JWT token type being a bad thing. =C2=A0= Adding it would not disrupt existing clients. =C2=A0

<= div>I think it is more a case of determining if this will be useful for oth= er things. =C2=A0 In connect it would really only help badly coded clients = who are unlikely to check it anyway.

John B.
=

On Nov 4, 2015, at 2:36 PM, Ju= stin Richer <jriche= r@mit.edu> wrote:

= I think a real question with regard to the login/logout case is, succinctly= , =E2=80=9CWhy is an application accepting an ID token from an unknown thir= d-party as proof of login=E2=80=9D? In the normal OIDC process, the client = will only get the ID token in response to an authentication request, so it = shouldn=E2=80=99t ever be just listening for incoming ID tokens.

=C2=A0=E2=80=94 Justin

On Nov 4, 2015, at 2:19 PM, William Denniss <wdenniss@google.com> wrote:
Hi Everyone,

It was good tal= king to many of you at Yokohama earlier in the week about using JWTs for ev= ent messages like Logout, Risk Signals, SCIM profile updates and more. Than= k you Phil for starting this conversation and spinning up the list! We'= re all doing related things with events, and it makes sense to collaborate = and unify our approaches.

An issue with JWT reuse = currently is that ID Tokens are defined=C2=A0by OpenID = Connect to require only a few standard JWT claims, and the required cl= aims are highly re-usable and contain nothing that actually sets them apart= as an "ID Token".

The risk of this is t= hat a JWT for an event like logout can be a valid ID Token for login.=C2=A0= An attacker in possession of a logout token could replay it against a logi= n endpoint, and gain access.

One mitigation is to = change the issuer, or audience. To me this is undesirable as the events (e.= g. logout) do relate to the same issuer and audience. Like matter and anti-= matter, yin and yang =E2=80=93 logout should simply reverse the login.=C2= =A0 It seems wasteful to spin up a new issuer, new key rotations, and more = just to manage each different type of event, if they would otherwise be rel= ated by issuer.

Currently the Backc= hannel Logout draft attempts to "break" this utility of a log= out JWT for authentication by prohibiting the=C2=A0'nonce' field:

The following Claim MUST NOT be used within th= e Logout Token:


nonce<= /dt>
PROHIBITED. A=C2=A0nonce=C2=A0Claim MUST NOT be pre= sent. Its use is prohibited to make a Logout Token syntactically invalid if= used in a forged Authentication Response in place of an ID Token.

I'm concerned that this may not= always work as intended, as 'nonce' is not a required field of the= ID Token. ID Tokens obtained from Google using the code flow (on our OpenI= D Connect certified endpoints) do not contain 'nonce' today, for ex= ample. And I'm a little worried that RPs may not be strictly checking f= or a 'nonce', even when they should (e.g. when using the implicit f= low).

Even if this approach works in this specific= case, it's not scalable. So I propose that we move to adopt a new stan= dard claim that can be used to indicate the intended purpose of the JWT.

'typ' is an obvious choice for a claim name,= although the word 'type' may be a little overloaded already. Anoth= er option could be "cat" for category.=C2=A0 Whatever we decide, = I think such a claim should be used in all JWT specs going forward, and add= ed to OpenID Connect ID Tokens in a future revision.

William



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

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

=



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




--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundatio= n
http://nat.saki= mura.org/
@_nat_en
--001a113ce2c06755510523b2a35a-- From nobody Wed Nov 4 00:19:05 2015 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F4DB1A004D for ; Wed, 4 Nov 2015 00:19:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IagPXMUGuzST for ; Wed, 4 Nov 2015 00:18:58 -0800 (PST) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) (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 1D71E1A0045 for ; Wed, 4 Nov 2015 00:18:58 -0800 (PST) Received: by pacdm15 with SMTP id dm15so21951857pac.3 for ; Wed, 04 Nov 2015 00:18:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb_com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=nPFvSmSlgnucmrdKeTUUecayE9Q3AgNUoxcU7OfgNyw=; b=SuSr1GVPdWkk9HWsWOyrE8DFJxhglY2k4zoRKdeYVsztgOZ0U+9obQMpooCmuLa4FG OOYMzDLvwnkS0MHf06YqSdQL+HG7rDxmk5WccXZFyUIS+1cDUvzztVwjwO25EI4r4uCA tATzkQP3QwuEs1JovE2Gnp9LBLlo0PM2GASu7b5dy3X+H15RXjNNoC8xGSkGtZAogmyS AQ1B6d3hCqMJb4gy3Lb7f9nl5WaL5eJ98too1fKuh+2anT5QxPhkcLNzK7+jpojm3LQ3 b9xaIPitU1DldYkHwBihEN8dV62/XU7lungL8CaO+fPof6ReUf07XAxIpG1JLSR7U+7a U9Cg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=nPFvSmSlgnucmrdKeTUUecayE9Q3AgNUoxcU7OfgNyw=; b=IOGSHz2IBhqXBPbEyarkkA/2P7yDJz4bRkSHjXanMLyPOrDW5JZkyQWQqfeeIWHZiP 7hX397S3PpwJLgcekw8tk3F29ZjyowDEOtsQzSzEuX8waZ/UTnGm/EqCUZ8h8AaWZMQ4 AEAll2v1q7G3hT5FqmJnLQvy36S1W9G2Lo5ERWpXHY/LVGqKy80yN9VwIsdMFS7iNSJj p3ulMkK4CuOxZ5R+G88C+yGad1/evBTQRtLSzLosDHEp7zNvZzRxsVRORPF+HSFq1Vks 86uJEqPJxh1T4d6rUVPwCPHaes7+XkfA3htlK2Fwlu9VDhM5Kf4yVj2O77LPAZS2mkba ePnw== X-Gm-Message-State: ALoCoQkCAow2D/YKTpXhm3EvGST8S5WNaJ0p/6PXDLc6Q9RMxHbryP+Nd342RbSQPayj+Pfm7+Fx X-Received: by 10.69.0.129 with SMTP id ay1mr231094pbd.21.1446625137677; Wed, 04 Nov 2015 00:18:57 -0800 (PST) Received: from dhcp-28-134.meeting.ietf94.jp (dhcp-28-134.meeting.ietf94.jp. [133.93.28.134]) by smtp.gmail.com with ESMTPSA id qv5sm360326pbc.71.2015.11.04.00.18.55 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Nov 2015 00:18:57 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_0BD7769F-DAE4-4090-8BF7-D310E4346DD8" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: John Bradley In-Reply-To: Date: Wed, 4 Nov 2015 17:18:54 +0900 Message-Id: <46E458D5-B70E-4F84-BC0B-0AEAC1B4BB69@ve7jtb.com> References: <7A2911BB-0B39-4A61-8767-6A0D24012363@mit.edu> <0EE00ED6-D344-4B92-9A05-8FFB7BCB6BF0@mit.edu> To: Michael Jones X-Mailer: Apple Mail (2.2104) Archived-At: Cc: William Denniss , "id-event@ietf.org" , Justin Richer Subject: Re: [Id-event] Distinguishing different JWT types X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2015 08:19:02 -0000 --Apple-Mail=_0BD7769F-DAE4-4090-8BF7-D310E4346DD8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 nonce is used to bind the token to a browser instance for delivery in = the front channel. Perhaps at some point Token binding will make it = redundant, but it is the best we have at this point. It makes no sense to have it in backchannel assertions or unsolicited = assertions. To my mind not including nonce is just stopping people from doing = nonsensical things that may be confusing to debug. =20 The IdP doesn=E2=80=99t currently need to maintain the nonce value = beyond issuing the id_token. Saving the nonce value to put it in a = id_token a day or week later provides no value. Even if a IdP puts nonce in the token, the client will reject it if the = value is incorrect for a new authentication, different browser.=20 I guess a attacker could get a logout token and somehow send it to the = client via redirect assuming they can get a correct state value. They would however be logging the correct user back in, and there are = probably simpler attacks to try and do that via kicking off a login via = cross site scripting. I don=E2=80=99t think precluding nonce is a foolproof security measure = to differentiate the tokens, but validating it is important for front = channel delivered tokens. John B. > On Nov 4, 2015, at 5:04 PM, Mike Jones = wrote: >=20 > The part of this thread dealing with logout should have included a = reference to this text = inhttp://openid.net/specs/openid-connect-backchannel-1_0-01.html#LogoutTok= en = : > =20 > logout_only > REQUIRED. Value declaring that this JWT is only to be used as a Logout = Token. In particular, this JWT cannot be used in any context where an ID = Token is used. The value of this Claim MUST be the JSON boolean value = true. > =20 > This claim is currently used to =E2=80=9Ctype=E2=80=9D the logout = token. Changing from =E2=80=9Clogout_only=E2=80=9D:true to =E2=80=9Cjty=E2= =80=9D: =E2=80=9Clogout=E2=80=9D or something similar would be fine. > =20 > John suggested that we prohibit the inclusion of =E2=80=9Cnonce=E2=80=9D= as a second way of ensuring that that token couldn=E2=80=99t be = repurposed as an ID Token. That would work even if the code wasn=E2=80=99= t checking for =E2=80=9Clogout_only=E2=80=9D or =E2=80=9Cjty=E2=80=9D. > =20 > -- Mike > =20 > From: Id-event [mailto:id-event-bounces@ietf.org] On Behalf Of William = Denniss > Sent: Wednesday, November 04, 2015 4:54 PM > To: Justin Richer > Cc: John Bradley; id-event@ietf.org > Subject: Re: [Id-event] Distinguishing different JWT types > =20 > Fair points. My main concern is that we don't always know how people = treat ID Tokens (or JWTs more generally), and one of their nice = properties is that they are designed to be verifiable if transmitted = over an untrusted medium. > =20 > I think we can build in more protection going forward by having a = clear type indicator. Imagine having 6 different JWT types, all = potentially validating as the other types. It seems dangerous if the = only protection is that they shouldn't be accepted outside their = intended flows, and also downright confusing as they all look similar. > =20 > Removing fields to break potential re-use doesn't scale, and doesn't = help understandability either. > =20 > =20 > On Wed, Nov 4, 2015 at 4:24 PM, Justin Richer > wrote: > I=E2=80=99m very much in favor of having a JWT token type key, but for = other reasons and uses.=20 > =20 > I=E2=80=99m just taking issue with the assertion that a logout token = could be easily confused by a functioning OIDC client. > =20 > Even then I think it=E2=80=99s a good idea to have a =E2=80=9Ctyp": = =E2=80=9Clogout=E2=80=9D tag in it. The current guideline to take the = =E2=80=9Cnonce=E2=80=9D out is a profoundly stupid hack that=E2=80=99s = not likely to make much difference in the real world, or at least even = less of a difference than a type parameter. > =20 > Along those lines, I=E2=80=99d suggest we use =E2=80=9Cjtt" or =E2=80=9C= JSON (web) Token Type=E2=80=9D as the field name, so we don=E2=80=99t = cause confusion with the header =E2=80=9Ctyp=E2=80=9D parameter. > =20 > =E2=80=94 Justin > =20 > On Nov 4, 2015, at 4:06 PM, John Bradley > wrote: > =20 > In principal a client gets a token two ways. =20 > 1 via a token endpoint in a direct communication. > 2 via the authorization endpoint, In this case a client needs to check = the nonce value to correlate the token with the user agent that the = request was made via. > =20 > I think it is fair not to have a nonce in the other tokens as they are = not requested via the browser. Nonce would also not be appropriate for = a JWT assertion. > =20 > I would be more worried about other sorts of assertions being = confused, or at-least not easily differentiated.=20 > =20 > I don=E2=80=99t think having a explicit JWT token type being a bad = thing. Adding it would not disrupt existing clients. =20 > =20 > I think it is more a case of determining if this will be useful for = other things. In connect it would really only help badly coded clients = who are unlikely to check it anyway. > =20 > John B. > =20 > On Nov 4, 2015, at 2:36 PM, Justin Richer > wrote: > =20 > I think a real question with regard to the login/logout case is, = succinctly, =E2=80=9CWhy is an application accepting an ID token from an = unknown third-party as proof of login=E2=80=9D? In the normal OIDC = process, the client will only get the ID token in response to an = authentication request, so it shouldn=E2=80=99t ever be just listening = for incoming ID tokens. > =20 > =E2=80=94 Justin > =20 > On Nov 4, 2015, at 2:19 PM, William Denniss > wrote: > =20 > Hi Everyone, > =20 > It was good talking to many of you at Yokohama earlier in the week = about using JWTs for event messages like Logout, Risk Signals, SCIM = profile updates and more. Thank you Phil for starting this conversation = and spinning up the list! We're all doing related things with events, = and it makes sense to collaborate and unify our approaches. > =20 > An issue with JWT reuse currently is that ID Tokens are defined = by OpenID = Connect to require only a few standard JWT claims = , and the required claims = are highly re-usable and contain nothing that actually sets them apart = as an "ID Token". > =20 > The risk of this is that a JWT for an event like logout can be a valid = ID Token for login. An attacker in possession of a logout token could = replay it against a login endpoint, and gain access. > =20 > One mitigation is to change the issuer, or audience. To me this is = undesirable as the events (e.g. logout) do relate to the same issuer and = audience. Like matter and anti-matter, yin and yang =E2=80=93 logout = should simply reverse the login. It seems wasteful to spin up a new = issuer, new key rotations, and more just to manage each different type = of event, if they would otherwise be related by issuer. > =20 > Currently the Backchannel Logout draft = attempts = to "break" this utility of a logout JWT for authentication by = prohibiting the 'nonce' field: > The following Claim MUST NOT be used within the Logout Token: > =20 > nonce > PROHIBITED. A nonce Claim MUST NOT be present. Its use is prohibited = to make a Logout Token syntactically invalid if used in a forged = Authentication Response in place of an ID Token. > =20 > I'm concerned that this may not always work as intended, as 'nonce' is = not a required field of the ID Token. ID Tokens obtained from Google = using the code flow (on our OpenID Connect certified endpoints) do not = contain 'nonce' today, for example. And I'm a little worried that RPs = may not be strictly checking for a 'nonce', even when they should (e.g. = when using the implicit flow). > =20 > Even if this approach works in this specific case, it's not scalable. = So I propose that we move to adopt a new standard claim that can be used = to indicate the intended purpose of the JWT. > =20 > 'typ' is an obvious choice for a claim name, although the word 'type' = may be a little overloaded already. Another option could be "cat" for = category. Whatever we decide, I think such a claim should be used in = all JWT specs going forward, and added to OpenID Connect ID Tokens in a = future revision. > =20 > William > =20 > =20 > =20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event = > =20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event = --Apple-Mail=_0BD7769F-DAE4-4090-8BF7-D310E4346DD8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 nonce is used to bind the token to a browser instance for = delivery in the front channel.  Perhaps at some point Token binding = will make it redundant, but it is the best we have at this point.

It makes no sense to = have it in backchannel assertions or unsolicited assertions.

To my mind not including = nonce is just stopping people from doing nonsensical things that may be = confusing to debug.  

The IdP doesn=E2=80=99t currently need to maintain the nonce = value beyond issuing the id_token.   Saving the nonce value to put = it in a id_token a day or week later provides no value.

Even if a IdP puts nonce = in the token, the client will reject it if the value is incorrect for a = new authentication, different browser. 

I guess a attacker could get a logout = token and somehow send it to the client via redirect assuming they can = get a correct state value.
They would however be = logging the correct user back in, and there are probably simpler attacks = to try and do that via kicking off a login via cross site = scripting.

I = don=E2=80=99t think precluding nonce is a foolproof security measure to = differentiate the tokens, but validating it is important for front = channel delivered tokens.

John B.
On Nov 4, 2015, at 5:04 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

The part of this thread dealing with logout = should have included a reference to this text inhttp://openid.net/specs/openid-connect-backchannel-1_0-01.html#= LogoutToken:
 
logout_only
REQUIRED. Value declaring that this JWT = is only to be used as a Logout Token. In particular, this JWT cannot be = used in any context where an ID Token is used. The value of this Claim = MUST be the JSON boolean value true.
 
This claim is currently = used to =E2=80=9Ctype=E2=80=9D the logout token.  Changing from = =E2=80=9Clogout_only=E2=80=9D:true to =E2=80=9Cjty=E2=80=9D: = =E2=80=9Clogout=E2=80=9D or something similar would be fine.
 
John suggested that we = prohibit the inclusion of =E2=80=9Cnonce=E2=80=9D as a second way of = ensuring that that token couldn=E2=80=99t be repurposed as an ID = Token.  That would work even if the code wasn=E2=80=99t checking = for =E2=80=9Clogout_only=E2=80=9D or =E2=80=9Cjty=E2=80=9D.
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;            -- = Mike
 
From: Id-event = [mailto:id-event-bounces@ietf.org] On Behalf = Of William = Denniss
Sent: Wednesday, November 04, = 2015 4:54 PM
To: Justin Richer
Cc: John Bradley; id-event@ietf.org
Subject: Re: [Id-event] = Distinguishing different JWT types
 
Fair = points. My main concern is that we don't always know how people treat ID = Tokens (or JWTs more generally), and one of their nice properties is = that they are designed to be verifiable if transmitted over an untrusted = medium.
 
I think we can build in more protection going forward = by having a clear type indicator. Imagine having 6 different JWT types, = all potentially validating as the other types. It seems dangerous if the = only protection is that they shouldn't be accepted outside their = intended flows, and also downright confusing as they all look = similar.
 
Removing fields to break potential re-use doesn't = scale, and doesn't help understandability either.
 
 
On Wed, Nov 4, 2015 at 4:24 PM, Justin Richer <jricher@mit.edu> = wrote:
I=E2=80=99m very much in favor of having a JWT token = type key, but for other reasons and uses. 
 
I=E2=80=99m just taking issue with the = assertion that a logout token could be easily confused by a functioning = OIDC client.
 
Even then I think it=E2=80=99s a good idea to have a = =E2=80=9Ctyp": =E2=80=9Clogout=E2=80=9D tag in it. The current guideline = to take the =E2=80=9Cnonce=E2=80=9D out is a profoundly stupid hack = that=E2=80=99s not likely to make much difference in the real world, or = at least even less of a difference than a type parameter.
 
Along those lines, I=E2=80=99d suggest we = use =E2=80=9Cjtt" or =E2=80=9CJSON (web) Token Type=E2=80=9D as the = field name, so we don=E2=80=99t cause confusion with the header = =E2=80=9Ctyp=E2=80=9D parameter.
 
 =E2=80=94 Justin
 
On Nov 4, 2015, at = 4:06 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
 
In principal a client gets a token two = ways.  
1 via a token endpoint in a direct = communication.
2 via the authorization endpoint, In this = case a client needs to check the nonce value to correlate the token with = the user agent that the request was made via.
 
I think it is fair not to have a nonce in = the other tokens as they are not requested via the browser.  Nonce = would also not be appropriate for a JWT assertion.
 
I would be more worried about other sorts = of assertions being confused, or at-least not easily = differentiated. 
 
I don=E2=80=99t think having a explicit JWT token = type being a bad thing.   Adding it would not disrupt existing = clients.  
 
I think it is more a case of determining if this will = be useful for other things.   In connect it would really only help = badly coded clients who are unlikely to check it anyway.
 
John B.
 
On Nov 4, 2015, at = 2:36 PM, Justin Richer <jricher@mit.edu> wrote:
 
I think a real question with regard to = the login/logout case is, succinctly, =E2=80=9CWhy is an application = accepting an ID token from an unknown third-party as proof of login=E2=80=9D= ? In the normal OIDC process, the client will only get the ID token in = response to an authentication request, so it shouldn=E2=80=99t ever be = just listening for incoming ID tokens.
 
 =E2=80=94 Justin
 
On Nov 4, 2015, at = 2:19 PM, William Denniss <wdenniss@google.com> wrote:
 
Hi Everyone,
 
It was good talking to many of you at = Yokohama earlier in the week about using JWTs for event messages like = Logout, Risk Signals, SCIM profile updates and more. Thank you Phil for = starting this conversation and spinning up the list! We're all doing = related things with events, and it makes sense to collaborate and unify = our approaches.
 
An issue with JWT reuse currently is that ID Tokens = are defined by OpenID Connect to require only a few standard = JWT claims, and the required claims are highly re-usable and contain = nothing that actually sets them apart as an "ID Token".
 
The risk of this is that a JWT for an = event like logout can be a valid ID Token for login.  An attacker = in possession of a logout token could replay it against a login = endpoint, and gain access.
 
One mitigation is to change the issuer, or audience. = To me this is undesirable as the events (e.g. logout) do relate to the = same issuer and audience. Like matter and anti-matter, yin and yang =E2=80= =93 logout should simply reverse the login.  It seems wasteful to = spin up a new issuer, new key rotations, and more just to manage each = different type of event, if they would otherwise be related by = issuer.
 
Currently the Backchannel Logout draft attempts to "break" this = utility of a logout JWT for authentication by prohibiting = the 'nonce' field:

The following Claim MUST NOT be used within the Logout = Token:

 
nonce
PROHIBITED. A nonce Claim MUST NOT be present. Its use is = prohibited to make a Logout Token syntactically invalid if used in a = forged Authentication Response in place of an ID Token.
 
I'm concerned that = this may not always work as intended, as 'nonce' is not a required field = of the ID Token. ID Tokens obtained from Google using the code flow (on = our OpenID Connect certified endpoints) do not contain 'nonce' today, = for example. And I'm a little worried that RPs may not be strictly = checking for a 'nonce', even when they should (e.g. when using the = implicit flow).
 
Even if this approach works in this specific case, = it's not scalable. So I propose that we move to adopt a new standard = claim that can be used to indicate the intended purpose of the JWT.
 
'typ' is an obvious choice for a claim = name, although the word 'type' may be a little overloaded already. = Another option could be "cat" for category.  Whatever we decide, I = think such a claim should be used in all JWT specs going forward, and = added to OpenID Connect ID Tokens in a future revision.
 
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
<= /blockquote>
<= /div>

= --Apple-Mail=_0BD7769F-DAE4-4090-8BF7-D310E4346DD8-- From nobody Wed Nov 4 00:31:11 2015 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57F971A0180 for ; Wed, 4 Nov 2015 00:31:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zwtSw30jYvLd for ; Wed, 4 Nov 2015 00:31:06 -0800 (PST) Received: from mail-qg0-x22e.google.com (mail-qg0-x22e.google.com [IPv6:2607:f8b0:400d:c04::22e]) (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 4D8EA1A00CA for ; Wed, 4 Nov 2015 00:31:06 -0800 (PST) Received: by qgad10 with SMTP id d10so34587309qga.3 for ; Wed, 04 Nov 2015 00:31:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=bcZkwnjI0oE/E7DVALJjLDTErSRsz6T9Ip38lkCAb+c=; b=Mxu07F/aeF9x6q2s46fke/Tfa1YG2MLaKVdCYTnEsYUSXrQ+vzUvkqHrBFgrsxCa/b YYs3+SJ9Qz17fBqrVVeueazL1oQ9B6MLEuj2uo2TmPOBGIoDU8WoYzCJRx94CGQkvlrC sPNQr9Py0c3RurrRhHdZ3CAquBg1ultQj7sXykDEhWSDrlxgh8iL0b/tn1MET6xtbpdD mzxwAFKVQWaYINO2+SpdeYqzXcYjWq7jeeciXdz4lOOdOQqlf37SytgrmL2W/83zCwdv Y3KgugUek8LSjoskkKYeHP3wLTWPTCc1a77jZ56HvbHX/vCujZJswY3Qu8dWgLb6FmU3 qaug== 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:cc :content-type; bh=bcZkwnjI0oE/E7DVALJjLDTErSRsz6T9Ip38lkCAb+c=; b=T43peehVv0BdrGeNbguzfsS8Hs2F4+PEjxD7cgAFl9t3Opx0CYo2hwS4Yye7c4CKHG vfIx3Neh0egHM+1l8VZb44X9bekRRtO50lGhATq1woOW0bvJxoIpWfl4XtLSWUTB6gpW GzVMTRrOSX/Qa5lOFtuO8JLm/ngrPSvQ47T/jEBc9L7oIl+x+XZ4rYuVF3kGPZUxNO/Z K39xduOhQ0lpxOrnOhx1tWFruYV0NE/NLAtzmjVAmFauBwrCWVs5AtH8YfwtXuCxSFgN K8cccWKL4ZuzYim8s5IcRlKgWkY1p5hfuJCVRcEn88ErkVuVxzWXJ0hI+rrj8fWScFX7 ChmA== X-Gm-Message-State: ALoCoQm8o3TF6UqvkwzD5P48sUdbN1AkWxMSEMzQ4+WUCC8MOq0+n0zfTQ6PiFSIbgkHYQsitVoO X-Received: by 10.140.233.196 with SMTP id e187mr209087qhc.86.1446625864516; Wed, 04 Nov 2015 00:31:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.102.18 with HTTP; Wed, 4 Nov 2015 00:30:45 -0800 (PST) From: William Denniss Date: Wed, 4 Nov 2015 17:30:45 +0900 Message-ID: To: Mike Jones Content-Type: multipart/alternative; boundary=001a11376c08c7502d0523b2d4a0 Archived-At: Cc: John Bradley , "id-event@ietf.org" , Justin Richer Subject: [Id-event] Events and endpoints X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2015 08:31:10 -0000 --001a11376c08c7502d0523b2d4a0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Branching this topic, to keep the other thread clean. Mike and I had a conversation off-list, where I asked about potentially using the logout back-channel to send other events (e.g. risk signals). I wasn't trying to suggest it should be a generic messaging pipe =E2=80=93 bu= t was wondering if it could be re-used for other messages related to the user session. I don't have a strong opinion on this. If people see more fuzzy events like risk signals, and the explicit "logout" instructions as very different, then it seems wise to have different endpoints to process them. To me there's a bit of overlap, as some risk signals end up resulting in a "logout" instruction which was why I mooted this idea. Thanks for your feedback Mike! I'm also not convinced we want to have a completely generic messaging pipe as part of OAuth or OIDC, and understand that you want to stay well away of the SOAP/WS-* pattern! On Wed, Nov 4, 2015 at 5:09 PM, Mike Jones wrote: > Some of you have seen my remark below but I=E2=80=99m resending it to get= it on > the record for those of you have not=E2=80=A6 > > > > I want to stay completely clear of situations in which multiple kinds of > messages are sent to the same endpoint and then dispatched to do differen= t > things based on the message type. That is the pattern that led people to > abandon SOAP/WS-* for REST. I don=E2=80=99t want to be part of recreatin= g it. > > > > For instance, I only want logout message to be sent to the OpenID Connect > logout endpoint. It=E2=80=99s appropriate for the endpoint to **validate= ** that > the message conforms to the specified logout message syntax and otherwise > reject the message. But the only action taken for messages of other type= s > should be to drop them =E2=80=93 not dispatch them. > > > > -- Mike > > > > *From:* Id-event [mailto:id-event-bounces@ietf.org] *On Behalf Of *Mike > Jones > *Sent:* Wednesday, November 04, 2015 5:05 PM > *To:* William Denniss; Justin Richer > > *Cc:* John Bradley; id-event@ietf.org > *Subject:* Re: [Id-event] Distinguishing different JWT types > > > > The part of this thread dealing with logout should have included a > reference to this text in > http://openid.net/specs/openid-connect-backchannel-1_0-01.html#LogoutToke= n > : > > > > logout_only > > REQUIRED. Value declaring that this JWT is only to be used as a Logout > Token. In particular, this JWT cannot be used in any context where an ID > Token is used. The value of this Claim MUST be the JSON boolean value tru= e. > > > > > This claim is currently used to =E2=80=9Ctype=E2=80=9D the logout token. = Changing from > =E2=80=9Clogout_only=E2=80=9D:true to =E2=80=9Cjty=E2=80=9D: =E2=80=9Clog= out=E2=80=9D or something similar would be fine. > > > > John suggested that we prohibit the inclusion of =E2=80=9Cnonce=E2=80=9D = as a second way > of ensuring that that token couldn=E2=80=99t be repurposed as an ID Token= . That > would work even if the code wasn=E2=80=99t checking for =E2=80=9Clogout_o= nly=E2=80=9D or =E2=80=9Cjty=E2=80=9D. > > > > -- Mike > > > > *From:* Id-event [mailto:id-event-bounces@ietf.org > ] *On Behalf Of *William Denniss > *Sent:* Wednesday, November 04, 2015 4:54 PM > *To:* Justin Richer > *Cc:* John Bradley; id-event@ietf.org > *Subject:* Re: [Id-event] Distinguishing different JWT types > > > > Fair points. My main concern is that we don't always know how people trea= t > ID Tokens (or JWTs more generally), and one of their nice properties is > that they are designed to be verifiable if transmitted over an untrusted > medium. > > > > I think we can build in more protection going forward by having a clear > type indicator. Imagine having 6 different JWT types, all potentially > validating as the other types. It seems dangerous if the only protection = is > that they shouldn't be accepted outside their intended flows, and also > downright confusing as they all look similar. > > > > Removing fields to break potential re-use doesn't scale, and doesn't help > understandability either. > > > > > > On Wed, Nov 4, 2015 at 4:24 PM, Justin Richer wrote: > > I=E2=80=99m very much in favor of having a JWT token type key, but for ot= her > reasons and uses. > > > > I=E2=80=99m just taking issue with the assertion that a logout token coul= d be > easily confused by a functioning OIDC client. > > > > Even then I think it=E2=80=99s a good idea to have a =E2=80=9Ctyp": =E2= =80=9Clogout=E2=80=9D tag in it. > The current guideline to take the =E2=80=9Cnonce=E2=80=9D out is a profou= ndly stupid hack > that=E2=80=99s not likely to make much difference in the real world, or a= t least > even less of a difference than a type parameter. > > > > Along those lines, I=E2=80=99d suggest we use =E2=80=9Cjtt" or =E2=80=9CJ= SON (web) Token Type=E2=80=9D as > the field name, so we don=E2=80=99t cause confusion with the header =E2= =80=9Ctyp=E2=80=9D parameter. > > > > =E2=80=94 Justin > > > > On Nov 4, 2015, at 4:06 PM, John Bradley wrote: > > > > In principal a client gets a token two ways. > > 1 via a token endpoint in a direct communication. > > 2 via the authorization endpoint, In this case a client needs to check th= e > nonce value to correlate the token with the user agent that the request w= as > made via. > > > > I think it is fair not to have a nonce in the other tokens as they are no= t > requested via the browser. Nonce would also not be appropriate for a JWT > assertion. > > > > I would be more worried about other sorts of assertions being confused, o= r > at-least not easily differentiated. > > > > I don=E2=80=99t think having a explicit JWT token type being a bad thing.= Adding > it would not disrupt existing clients. > > > > I think it is more a case of determining if this will be useful for other > things. In connect it would really only help badly coded clients who ar= e > unlikely to check it anyway. > > > > John B. > > > > On Nov 4, 2015, at 2:36 PM, Justin Richer wrote: > > > > I think a real question with regard to the login/logout case is, > succinctly, =E2=80=9CWhy is an application accepting an ID token from an = unknown > third-party as proof of login=E2=80=9D? In the normal OIDC process, the c= lient will > only get the ID token in response to an authentication request, so it > shouldn=E2=80=99t ever be just listening for incoming ID tokens. > > > > =E2=80=94 Justin > > > > On Nov 4, 2015, at 2:19 PM, William Denniss wrote: > > > > Hi Everyone, > > > > It was good talking to many of you at Yokohama earlier in the week about > using JWTs for event messages like Logout, Risk Signals, SCIM profile > updates and more. Thank you Phil for starting this conversation and > spinning up the list! We're all doing related things with events, and it > makes sense to collaborate and unify our approaches. > > > > An issue with JWT reuse currently is that ID Tokens are defined > by OpenID > Connect to require only a few standard JWT claims > , and the required claims > are highly re-usable and contain nothing that actually sets them apart as > an "ID Token". > > > > The risk of this is that a JWT for an event like logout can be a valid ID > Token for login. An attacker in possession of a logout token could repla= y > it against a login endpoint, and gain access. > > > > One mitigation is to change the issuer, or audience. To me this is > undesirable as the events (e.g. logout) do relate to the same issuer and > audience. Like matter and anti-matter, yin and yang =E2=80=93 logout shou= ld simply > reverse the login. It seems wasteful to spin up a new issuer, new key > rotations, and more just to manage each different type of event, if they > would otherwise be related by issuer. > > > > Currently the Backchannel Logout draft > attempts to > "break" this utility of a logout JWT for authentication by prohibiting > the 'nonce' field: > > The following Claim MUST NOT be used within the Logout Token: > > > > nonce > > PROHIBITED. A nonce Claim MUST NOT be present. Its use is prohibited to > make a Logout Token syntactically invalid if used in a forged > Authentication Response in place of an ID Token. > > > > I'm concerned that this may not always work as intended, as 'nonce' is no= t > a required field of the ID Token. ID Tokens obtained from Google using th= e > code flow (on our OpenID Connect certified endpoints) do not contain > 'nonce' today, for example. And I'm a little worried that RPs may not be > strictly checking for a 'nonce', even when they should (e.g. when using t= he > implicit flow). > > > > Even if this approach works in this specific case, it's not scalable. So = I > propose that we move to adopt a new standard claim that can be used to > indicate the intended purpose of the JWT. > > > > 'typ' is an obvious choice for a claim name, although the word 'type' may > be a little overloaded already. Another option could be "cat" for > category. Whatever we decide, I think such a claim should be used in all > JWT specs going forward, and added to OpenID Connect ID Tokens in a futur= e > revision. > > > > 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 > > > > > > > --001a11376c08c7502d0523b2d4a0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Branching this topic, to keep the other thread clean.
=
Mike and I had a conversation off-list, where I asked about = potentially using the logout back-channel to send other events (e.g. risk s= ignals).=C2=A0 I wasn't trying to suggest it should be a generic messag= ing pipe =E2=80=93 but was wondering if it could be re-used for other messa= ges related to the user session.

I don't have = a strong opinion on this. If people see more fuzzy events like risk signals= , and the explicit "logout" instructions as very different, then = it seems wise to have different endpoints to process them.=C2=A0 To me ther= e's a bit of overlap, as some risk signals end up resulting in a "= logout" instruction which was why I mooted this idea.

Thanks for your feedback Mike!=C2=A0 I'm also not convinced we= want to have a completely generic messaging pipe as part of OAuth or OIDC,= and understand that you want to stay well away of the SOAP/WS-* pattern!


On Wed, Nov 4, 2015 at 5:09 PM, Mike Jones <Mic= hael.Jones@microsoft.com> wrote:

Some of you have seen my remark below but I=E2= =80=99m resending it to get it on the record for those of you have not=E2= =80=A6

=C2=A0

I want to stay completely clear of situations = in which multiple kinds of messages are sent to the same endpoint and then = dispatched to do different things based on the message type.=C2=A0 That is the pattern that led people to abandon = SOAP/WS-* for REST.=C2=A0 I don=E2=80=99t want to be part of recreating it.=

=C2=A0

For instance, I only want logout message to be= sent to the OpenID Connect logout endpoint.=C2=A0 It=E2=80=99s appropriate= for the endpoint to *validate* that the message conforms to the specified logout message= syntax and otherwise reject the message.=C2=A0 But the only action taken f= or messages of other types should be to drop them =E2=80=93 not dispatch th= em.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0-- Mike

=C2=A0

From: Id-event [mailto:id-event-bounces@ietf.org] On Behalf Of Mike Jones
Sent: Wednesday, November 04, 2015 5:05 PM
To: William Denniss; Justin Richer

=
Cc: John Bradley; id-event@ietf.org
Subject: Re: [Id-event] Distinguishing different JWT types=

=C2=A0

The part of this thread dealing with logout sh= ould have included a reference to this text in http://openid.net/specs/openid-connect-backchannel-1_0-01.html#LogoutToken<= /a>:

=C2=A0

logout_only

REQUIRED. Va= lue declaring that this JWT is only to be used as a Logout Token. In partic= ular, this JWT cannot be used in any context where an ID Token is used. The value of this Claim MUST be the JSO= N boolean value true.

=C2=A0

This claim is currently used to =E2=80=9Ctype= =E2=80=9D the logout token.=C2=A0 Changing from =E2=80=9Clogout_only=E2=80= =9D:true to =E2=80=9Cjty=E2=80=9D: =E2=80=9Clogout=E2=80=9D or something si= milar would be fine.

=C2=A0

John suggested that we prohibit the inclusion = of =E2=80=9Cnonce=E2=80=9D as a second way of ensuring that that token coul= dn=E2=80=99t be repurposed as an ID Token.=C2=A0 That would work even if the code wasn=E2=80=99t checking for =E2=80=9Clogout_only=E2=80=9D= or =E2=80=9Cjty=E2=80=9D.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 -- Mike

=C2=A0

From: Id-event [mailto:id-event-bounces@ietf.org] On Behalf Of William Denniss
Sent: Wednesday, November 04, 2015 4:54 PM
To: Justin Richer
Cc: John Bradley; id-event@ietf.org
Subject: Re: [Id-event] Distinguishing different JWT types=

=C2=A0

Fair points. My main concern is that we don't al= ways know how people treat ID Tokens (or JWTs more generally), and one of t= heir nice properties is that they are designed to be verifiable if transmit= ted over an untrusted medium.

=C2=A0

I think we can build in more protection going forwar= d by having a clear type indicator. Imagine having 6 different JWT types, a= ll potentially validating as the other types. It seems dangerous if the onl= y protection is that they shouldn't be accepted outside their intended flows, and also downright confusing as = they all look similar.

=C2=A0

Removing fields to break potential re-use doesn'= t scale, and doesn't help understandability either.

=C2=A0

=C2=A0

On Wed, Nov 4, 2015 at 4:24 PM, Justin Richer <jricher@mit.edu> = wrote:

I=E2=80=99m very much in favor of having a JWT token= type key, but for other reasons and uses.=C2=A0

=C2=A0

I=E2=80=99m just taking issue with the assertion tha= t a logout token could be easily confused by a functioning OIDC client.<= /u>

=C2=A0

Even then I think it=E2=80=99s a good idea to have a= =E2=80=9Ctyp": =E2=80=9Clogout=E2=80=9D tag in it. The current guidel= ine to take the =E2=80=9Cnonce=E2=80=9D out is a profoundly stupid hack tha= t=E2=80=99s not likely to make much difference in the real world, or at lea= st even less of a difference than a type parameter.

=C2=A0

Along those lines, I=E2=80=99d suggest we use =E2=80= =9Cjtt" or =E2=80=9CJSON (web) Token Type=E2=80=9D as the field name, = so we don=E2=80=99t cause confusion with the header =E2=80=9Ctyp=E2=80=9D p= arameter.

=C2=A0=

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

=C2=A0

On Nov 4, 2015, at 4:06 PM, John Bradley <ve7jtb@ve7jtb.com> w= rote:

=C2=A0

In principal a client gets a token two ways. =C2=A0<= u>

1 via a token endpoint in a direct communication.=

2 via the authorization endpoint, In this case a cli= ent needs to check the nonce value to correlate the token with the user age= nt that the request was made via.

=C2=A0

I think it is fair not to have a nonce in the other = tokens as they are not requested via the browser.=C2=A0 Nonce would also no= t be appropriate for a JWT assertion.

=C2=A0

I would be more worried about other sorts of asserti= ons being confused, or at-least not easily differentiated.=C2=A0<= /u>

=C2=A0

I don=E2=80=99t think having a explicit JWT token ty= pe being a bad thing. =C2=A0 Adding it would not disrupt existing clients. = =C2=A0

=C2=A0

I think it is more a case of determining if this wil= l be useful for other things. =C2=A0 In connect it would really only help b= adly coded clients who are unlikely to check it anyway.

=C2=A0

John B.

=C2=A0

On Nov 4, 2015, at 2:36 PM, Justin Richer <jricher@mit.edu> wrot= e:

=C2=A0

I think a real question with regard to the login/log= out case is, succinctly, =E2=80=9CWhy is an application accepting an ID tok= en from an unknown third-party as proof of login=E2=80=9D? In the normal OI= DC process, the client will only get the ID token in response to an authentication request, so it shouldn=E2=80=99t ever be = just listening for incoming ID tokens.

=C2=A0

=C2=A0=E2=80=94 Justin

=C2=A0

On Nov 4, 2015, at 2:19 PM, William Denniss <wdenniss@google.com> wrote:

=C2=A0

Hi Everyone,

=C2=A0

It was good talking to many of you at Yokohama earli= er in the week about using JWTs for event messages like Logout, Risk Signal= s, SCIM profile updates and more. Thank you Phil for starting this conversa= tion and spinning up the list! We're all doing related things with events, and it makes sense to collaborate an= d unify our approaches.

=C2=A0

An issue with JWT reuse currently is that ID Tokens = are defined=C2=A0by OpenID Connect to require only a few standard JWT claims, and the required claims are highly re-usable and c= ontain nothing that actually sets them apart as an "ID Token".=

=C2=A0

The risk of this is that a JWT for an event like log= out can be a valid ID Token for login.=C2=A0 An attacker in possession of a= logout token could replay it against a login endpoint, and gain access.=

=C2=A0

One mitigation is to change the issuer, or audience.= To me this is undesirable as the events (e.g. logout) do relate to the sam= e issuer and audience. Like matter and anti-matter, yin and yang =E2=80=93 = logout should simply reverse the login.=C2=A0 It seems wasteful to spin up a new issuer, new key rotations, and more just t= o manage each different type of event, if they would otherwise be related b= y issuer.

=C2=A0

Currently the Backchannel Logout draft attempts to "break" this utility of = a logout JWT for authentication by prohibiting the=C2=A0'nonce' fie= ld:

The following Claim MUST NOT= be used within the Logout Token:

=C2=A0

nonce=

PROHIBITED. A=C2=A0nonce=C2=A0Claim MUST NOT be present. Its use is prohibited to make a Logout Token syntactically invalid if used= in a forged Authentication Response in place of an ID Token.=

=C2=A0

I'm concerned that this may not always work as i= ntended, as 'nonce' is not a required field of the ID Token. ID Tok= ens obtained from Google using the code flow (on our OpenID Connect certifi= ed endpoints) do not contain 'nonce' today, for example. And I'm a little worried that RPs may not be strictly checkin= g for a 'nonce', even when they should (e.g. when using the implici= t flow).

=C2=A0

Even if this approach works in this specific case, i= t's not scalable. So I propose that we move to adopt a new standard cla= im that can be used to indicate the intended purpose of the JWT.<= /u>

=C2=A0

'typ' is an obvious choice for a claim name,= although the word 'type' may be a little overloaded already. Anoth= er option could be "cat" for category.=C2=A0 Whatever we decide, = I think such a claim should be used in all JWT specs going forward, and added to OpenID Connect ID Tokens in a future revision.<= /p>

=C2=A0

William

=C2=A0

=C2=A0

=C2=A0

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

=C2=A0

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

=C2=A0

=C2=A0

=C2=A0


--001a11376c08c7502d0523b2d4a0-- From nobody Wed Nov 4 00:41:28 2015 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3BE61A8F42 for ; Wed, 4 Nov 2015 00:41:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 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, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8DZI4ijgRXid for ; Wed, 4 Nov 2015 00:41:23 -0800 (PST) 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 BA6471A92BC for ; Wed, 4 Nov 2015 00:41:23 -0800 (PST) Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id tA48fNFY011456 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 4 Nov 2015 08:41:23 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id tA48fM4k019080 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 4 Nov 2015 08:41:23 GMT Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24]) by userv0122.oracle.com (8.13.8/8.13.8) with ESMTP id tA48fMgw001706 for ; Wed, 4 Nov 2015 08:41:22 GMT Received: from dhcp-87-184.meeting.ietf94.jp (/133.93.87.184) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 04 Nov 2015 00:41:22 -0800 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_C84FEB0D-364B-46E8-B647-1A5749007352" Message-Id: <042B7448-7BCF-496C-87E3-1928F24B6E2C@oracle.com> Date: Wed, 4 Nov 2015 17:41:21 +0900 To: id-event@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Subject: [Id-event] Summary of initial discussion and what do we want to achieve X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2015 08:41:26 -0000 --Apple-Mail=_C84FEB0D-364B-46E8-B647-1A5749007352 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Sorry I did not get this out earlier. Good to see everyone on the list = already! To get the discussion going, here are some notes from the informal = meeting that spawned this group. I=E2=80=99ve combined a bunch of = comments from our offline thread. Apologies if I have missed anything. Before we go much further, I want to remind folks that this is not yet a = work group. Part of what we want to discuss is: * What drafts (if any) should be written * Where do we want to do the work (it does not necessarily fit with = OAuth or SCIM) e.g. This could end-up in a WG where we do the foundational pieces and = then each interested group then profiles for their area. * What is the problem and what are the common themes that unite the = common effort? As usual all of this stuff falls under the IETF Notewell rules. Summary: there are a number of different initiatives that are all = starting to generate events around identity. We got together to talk = about whether we should be aligning our efforts. The areas that may be = interested are: OIDC - Session Logout / Revocation OAuth - Token Revocation RISC - Account events (take over, account reset, etc) SCIM - Provisioning events (has overlap with RISC) Consent - Tracking and delivery of consent events (e.g. in a distributed = healthcare system). The group had agreement that there should be a core =E2=80=9Cevent=E2=80=9D= JWT specification developed at the IETF. This becomes the basic = information packet that can be delivered via HTTP and other protocols. = Once the Event JWT is defined, each group can create profiles = appropriate to their constituency.=20 The general feeling was that all cases need a publish and subscribe = model, but that different areas might have widely varying types of = subscriptions. E.g. * 1:1 - a web app getting notifications about changes to a user=E2=80=99s= profile or a de-provisioning notification * 1:secured set of RPs - e.g. notifying RPs about session or token = revocations * 1:domain - inter-domain state change notifications - broadcast - e.g. sending out a RISC event to interested subscriber = domains. While I suggested the Pub/Sub/Hub model that initial proposal "SCIM = Notify" has (see https://tools.ietf.org/html/draft-hunt-scim-notify-00), = there was no immediate consensus that this was the right approach. We = since discussed that we don=E2=80=99t necessarily need to include the = publisher to hub portion. The main part of the hub functionality that = describes how feeds and subscriptions work are the more important parts = - whether a hub is implemented is really something up to the implementer = and isn=E2=80=99t really an important inter-op point. We talked about some of the issues with using JWT tokens. More = specifically around type indicators. Since that discussion is already = started I won=E2=80=99t re-hash it here. We also talked that the message system should be self-healing. There = might need to be a way for a subscriber to detect or confirm if it has = missed any messages. E.g. clients could check message-id numbers etc. We = would also like to ensure, for scalability and security reasons, that = messages are not kept for long periods of time. Other comments were made in direct emails between the attendees. I see = some of those comments have already started happening. Thanks everyone! Phil @independentid www.independentid.com phil.hunt@oracle.com --Apple-Mail=_C84FEB0D-364B-46E8-B647-1A5749007352 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Sorry I did not get this out earlier. Good to = see everyone on the list already!

To get the discussion going, here are some notes from = the informal meeting that spawned this group.  I=E2=80=99ve = combined a bunch of comments from our offline thread. Apologies if I = have missed anything.

Before we go much further, I want to remind folks that this = is not yet a work group. Part of what we want to discuss is:
* What drafts (if any) should be written
*= Where do we want to do the work (it does not necessarily fit with OAuth = or SCIM)
  e.g. This could end-up in a WG = where we do the foundational pieces and then each interested group then = profiles for their area.
* What is the problem and = what are the common themes that unite the common effort?

As usual all of this = stuff falls under the IETF Notewell rules.

Summary:  there = are a number of different initiatives that are all starting to generate = events around identity. We got together to talk about whether we should = be aligning our efforts. The areas that may be interested are:

OIDC - Session Logout / = Revocation
OAuth - Token Revocation
RISC - Account events (take over, account reset, = etc)
SCIM - Provisioning events (has overlap with = RISC)
Consent - Tracking and delivery of consent = events (e.g. in a distributed healthcare system).
The group had agreement that there = should be a core =E2=80=9Cevent=E2=80=9D JWT specification developed at = the IETF. This becomes the basic information packet that can be = delivered via HTTP and other protocols.  Once the Event JWT is = defined, each group can create profiles appropriate to their = constituency. 

The general feeling was that all cases need a publish and = subscribe model, but that different areas might have widely varying = types of subscriptions.  E.g.
*  1:1 - a = web app getting notifications about changes to a user=E2=80=99s profile = or a de-provisioning notification
*  1:secured = set of RPs - e.g. notifying RPs about session or token = revocations
*  1:domain - inter-domain state = change notifications
-  broadcast - e.g. = sending out a RISC event to interested subscriber domains.

While I suggested the = Pub/Sub/Hub model that initial proposal "SCIM Notify" has (see https://tools.ietf.org/html/draft-hunt-scim-notify-00), = there was no immediate consensus that this was the right approach. We = since discussed that we don=E2=80=99t necessarily need to include the = publisher to hub portion. The main part of the hub functionality that = describes how feeds and subscriptions work are the more important parts = - whether a hub is implemented is really something up to the implementer = and isn=E2=80=99t really an important inter-op point.

We talked about some of = the issues with using JWT tokens. More specifically around type = indicators. Since that discussion is already started I won=E2=80=99t = re-hash it here.

We also talked that the message system should be = self-healing. There might need to be a way for a subscriber to detect or = confirm if it has missed any messages. E.g. clients could check = message-id numbers etc. We would also like to ensure, for scalability = and security reasons, that messages are not kept for long periods of = time.

Other = comments were made in direct emails between the attendees. I see some of = those comments have already started happening.

Thanks everyone!

= --Apple-Mail=_C84FEB0D-364B-46E8-B647-1A5749007352-- From nobody Wed Nov 4 00:55:52 2015 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A771E1A1A69 for ; Wed, 4 Nov 2015 00:55:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Zynms1ILihW for ; Wed, 4 Nov 2015 00:55:46 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 689911AD0BB for ; Wed, 4 Nov 2015 00:55:46 -0800 (PST) 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 tA48tiBf013457 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 4 Nov 2015 08:55:44 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0022.oracle.com (8.13.8/8.13.8) with ESMTP id tA48thEc011800 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 4 Nov 2015 08:55:43 GMT Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id tA48th8D018723; Wed, 4 Nov 2015 08:55:43 GMT Received: from [133.93.87.170] (/133.93.87.170) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 04 Nov 2015 00:55:42 -0800 Content-Type: multipart/alternative; boundary=Apple-Mail-153B7E29-33F8-46F0-BCB2-28891D43760A Mime-Version: 1.0 (1.0) From: Phil Hunt X-Mailer: iPhone Mail (13B143) In-Reply-To: Date: Wed, 4 Nov 2015 17:55:40 +0900 Content-Transfer-Encoding: 7bit Message-Id: References: To: William Denniss X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Cc: John Bradley , Mike Jones , "id-event@ietf.org" , Justin Richer Subject: Re: [Id-event] Events and endpoints X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2015 08:55:50 -0000 --Apple-Mail-153B7E29-33F8-46F0-BCB2-28891D43760A Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I think this is the wrong way to think about it. =20 We should define these as "feeds" that endpoints can subscribe to. Eg. So wh= en someone logs out of an OP, subscribing endpoints will get the notice.=20 Deciding what endpoint is for what is really reverse to saying a subscriber w= ants to receive risc events from one source and logouts from an OP. The re= ceiver can self select to get multiple feeds if it wants.=20 Phil > On Nov 4, 2015, at 17:30, William Denniss wrote: >=20 > Branching this topic, to keep the other thread clean. >=20 > Mike and I had a conversation off-list, where I asked about potentially us= ing the logout back-channel to send other events (e.g. risk signals). I was= n't trying to suggest it should be a generic messaging pipe =E2=80=93 but wa= s wondering if it could be re-used for other messages related to the user se= ssion. >=20 > I don't have a strong opinion on this. If people see more fuzzy events lik= e risk signals, and the explicit "logout" instructions as very different, th= en it seems wise to have different endpoints to process them. To me there's= a bit of overlap, as some risk signals end up resulting in a "logout" instr= uction which was why I mooted this idea. >=20 > Thanks for your feedback Mike! I'm also not convinced we want to have a c= ompletely generic messaging pipe as part of OAuth or OIDC, and understand th= at you want to stay well away of the SOAP/WS-* pattern! >=20 >=20 >> On Wed, Nov 4, 2015 at 5:09 PM, Mike Jones w= rote: >> Some of you have seen my remark below but I=E2=80=99m resending it to get= it on the record for those of you have not=E2=80=A6 >>=20 >> =20 >>=20 >> I want to stay completely clear of situations in which multiple kinds of m= essages are sent to the same endpoint and then dispatched to do different th= ings based on the message type. That is the pattern that led people to aban= don SOAP/WS-* for REST. I don=E2=80=99t want to be part of recreating it. >>=20 >> =20 >>=20 >> For instance, I only want logout message to be sent to the OpenID Connect= logout endpoint. It=E2=80=99s appropriate for the endpoint to *validate* t= hat the message conforms to the specified logout message syntax and otherwis= e reject the message. But the only action taken for messages of other types= should be to drop them =E2=80=93 not dispatch them. >>=20 >> =20 >>=20 >> -- Mike >>=20 >> =20 >>=20 >> From: Id-event [mailto:id-event-bounces@ietf.org] On Behalf Of Mike Jones= >> Sent: Wednesday, November 04, 2015 5:05 PM >> To: William Denniss; Justin Richer >>=20 >>=20 >> Cc: John Bradley; id-event@ietf.org >> Subject: Re: [Id-event] Distinguishing different JWT types >> =20 >>=20 >> The part of this thread dealing with logout should have included a refere= nce to this text in http://openid.net/specs/openid-connect-backchannel-1_0-0= 1.html#LogoutToken: >>=20 >> =20 >>=20 >> logout_only >>=20 >> REQUIRED. Value declaring that this JWT is only to be used as a Logout To= ken. In particular, this JWT cannot be used in any context where an ID Token= is used. The value of this Claim MUST be the JSON boolean value true. >>=20 >> =20 >>=20 >> This claim is currently used to =E2=80=9Ctype=E2=80=9D the logout token. = Changing from =E2=80=9Clogout_only=E2=80=9D:true to =E2=80=9Cjty=E2=80=9D: =E2= =80=9Clogout=E2=80=9D or something similar would be fine. >>=20 >> =20 >>=20 >> John suggested that we prohibit the inclusion of =E2=80=9Cnonce=E2=80=9D a= s a second way of ensuring that that token couldn=E2=80=99t be repurposed as= an ID Token. That would work even if the code wasn=E2=80=99t checking for =E2= =80=9Clogout_only=E2=80=9D or =E2=80=9Cjty=E2=80=9D. >>=20 >> =20 >>=20 >> -- Mike >>=20 >> =20 >>=20 >> From: Id-event [mailto:id-event-bounces@ietf.org] On Behalf Of William De= nniss >> Sent: Wednesday, November 04, 2015 4:54 PM >> To: Justin Richer >> Cc: John Bradley; id-event@ietf.org >> Subject: Re: [Id-event] Distinguishing different JWT types >>=20 >> =20 >>=20 >> Fair points. My main concern is that we don't always know how people trea= t ID Tokens (or JWTs more generally), and one of their nice properties is th= at they are designed to be verifiable if transmitted over an untrusted mediu= m. >>=20 >> =20 >>=20 >> I think we can build in more protection going forward by having a clear t= ype indicator. Imagine having 6 different JWT types, all potentially validat= ing as the other types. It seems dangerous if the only protection is that th= ey shouldn't be accepted outside their intended flows, and also downright co= nfusing as they all look similar. >>=20 >> =20 >>=20 >> Removing fields to break potential re-use doesn't scale, and doesn't help= understandability either. >>=20 >> =20 >>=20 >> =20 >>=20 >> On Wed, Nov 4, 2015 at 4:24 PM, Justin Richer wrote: >>=20 >> I=E2=80=99m very much in favor of having a JWT token type key, but for ot= her reasons and uses.=20 >>=20 >> =20 >>=20 >> I=E2=80=99m just taking issue with the assertion that a logout token coul= d be easily confused by a functioning OIDC client. >>=20 >> =20 >>=20 >> Even then I think it=E2=80=99s a good idea to have a =E2=80=9Ctyp": =E2=80= =9Clogout=E2=80=9D tag in it. The current guideline to take the =E2=80=9Cnon= ce=E2=80=9D out is a profoundly stupid hack that=E2=80=99s not likely to mak= e much difference in the real world, or at least even less of a difference t= han a type parameter. >>=20 >> =20 >>=20 >> Along those lines, I=E2=80=99d suggest we use =E2=80=9Cjtt" or =E2=80=9CJ= SON (web) Token Type=E2=80=9D as the field name, so we don=E2=80=99t cause c= onfusion with the header =E2=80=9Ctyp=E2=80=9D parameter. >>=20 >> =20 >>=20 >> =E2=80=94 Justin >>=20 >> =20 >>=20 >> On Nov 4, 2015, at 4:06 PM, John Bradley wrote: >>=20 >> =20 >>=20 >> In principal a client gets a token two ways. =20 >>=20 >> 1 via a token endpoint in a direct communication. >>=20 >> 2 via the authorization endpoint, In this case a client needs to check th= e nonce value to correlate the token with the user agent that the request wa= s made via. >>=20 >> =20 >>=20 >> I think it is fair not to have a nonce in the other tokens as they are no= t requested via the browser. Nonce would also not be appropriate for a JWT a= ssertion. >>=20 >> =20 >>=20 >> I would be more worried about other sorts of assertions being confused, o= r at-least not easily differentiated.=20 >>=20 >> =20 >>=20 >> I don=E2=80=99t think having a explicit JWT token type being a bad thing.= Adding it would not disrupt existing clients. =20 >>=20 >> =20 >>=20 >> I think it is more a case of determining if this will be useful for other= things. In connect it would really only help badly coded clients who are u= nlikely to check it anyway. >>=20 >> =20 >>=20 >> John B. >>=20 >> =20 >>=20 >> On Nov 4, 2015, at 2:36 PM, Justin Richer wrote: >>=20 >> =20 >>=20 >> I think a real question with regard to the login/logout case is, succinct= ly, =E2=80=9CWhy is an application accepting an ID token from an unknown thi= rd-party as proof of login=E2=80=9D? In the normal OIDC process, the client w= ill only get the ID token in response to an authentication request, so it sh= ouldn=E2=80=99t ever be just listening for incoming ID tokens. >>=20 >> =20 >>=20 >> =E2=80=94 Justin >>=20 >> =20 >>=20 >> On Nov 4, 2015, at 2:19 PM, William Denniss wrote: >>=20 >> =20 >>=20 >> Hi Everyone, >>=20 >> =20 >>=20 >> It was good talking to many of you at Yokohama earlier in the week about u= sing JWTs for event messages like Logout, Risk Signals, SCIM profile updates= and more. Thank you Phil for starting this conversation and spinning up the= list! We're all doing related things with events, and it makes sense to col= laborate and unify our approaches. >>=20 >> =20 >>=20 >> An issue with JWT reuse currently is that ID Tokens are defined by OpenID= Connect to require only a few standard JWT claims, and the required claims a= re highly re-usable and contain nothing that actually sets them apart as an "= ID Token". >>=20 >> =20 >>=20 >> The risk of this is that a JWT for an event like logout can be a valid ID= Token for login. An attacker in possession of a logout token could replay i= t against a login endpoint, and gain access. >>=20 >> =20 >>=20 >> One mitigation is to change the issuer, or audience. To me this is undesi= rable as the events (e.g. logout) do relate to the same issuer and audience.= Like matter and anti-matter, yin and yang =E2=80=93 logout should simply re= verse the login. It seems wasteful to spin up a new issuer, new key rotatio= ns, and more just to manage each different type of event, if they would othe= rwise be related by issuer. >>=20 >> =20 >>=20 >> Currently the Backchannel Logout draft attempts to "break" this utility o= f a logout JWT for authentication by prohibiting the 'nonce' field: >>=20 >> The following Claim MUST NOT be used within the Logout Token: >> =20 >>=20 >> nonce >>=20 >> PROHIBITED. A nonce Claim MUST NOT be present. Its use is prohibited to m= ake a Logout Token syntactically invalid if used in a forged Authentication R= esponse in place of an ID Token. >>=20 >> =20 >>=20 >> I'm concerned that this may not always work as intended, as 'nonce' is no= t a required field of the ID Token. ID Tokens obtained from Google using the= code flow (on our OpenID Connect certified endpoints) do not contain 'nonce= ' today, for example. And I'm a little worried that RPs may not be strictly c= hecking for a 'nonce', even when they should (e.g. when using the implicit f= low). >>=20 >> =20 >>=20 >> Even if this approach works in this specific case, it's not scalable. So I= propose that we move to adopt a new standard claim that can be used to indi= cate the intended purpose of the JWT. >>=20 >> =20 >>=20 >> 'typ' is an obvious choice for a claim name, although the word 'type' may= be a little overloaded already. Another option could be "cat" for category.= Whatever we decide, I think such a claim should be used in all JWT specs g= oing forward, and added to OpenID Connect ID Tokens in a future revision. >>=20 >> =20 >>=20 >> William >>=20 >> =20 >>=20 >> =20 >>=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 >>=20 >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event --Apple-Mail-153B7E29-33F8-46F0-BCB2-28891D43760A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I think this is the wrong way to think= about it.  

We should define these as "feeds" that endpoints can subs= cribe to. Eg. So when someone logs out of an OP, subscribing endpoints will g= et the notice. 

Deciding what endpoint is for what is really reverse to= saying a subscriber wants to receive risc events from one source and  = logouts from an OP.  The receiver can self select to get multiple feeds= if it wants. 

Phil

On Nov 4, 2015, at 17:30, Will= iam Denniss <wdenniss@google.com> wrote:

B= ranching this topic, to keep the other thread clean.

Mike= and I had a conversation off-list, where I asked about potentially using th= e logout back-channel to send other events (e.g. risk signals).  I wasn= 't trying to suggest it should be a generic messaging pipe =E2=80=93 but was= wondering if it could be re-used for other messages related to the user ses= sion.

I don't have a strong opinion on this. If peo= ple see more fuzzy events like risk signals, and the explicit "logout" instr= uctions as very different, then it seems wise to have different endpoints to= process them.  To me there's a bit of overlap, as some risk signals en= d up resulting in a "logout" instruction which was why I mooted this idea.

Thanks for your feedback Mike!  I'm also not co= nvinced we want to have a completely generic messaging pipe as part of OAuth= or OIDC, and understand that you want to stay well away of the SOAP/WS-* pa= ttern!


On Wed, Nov 4, 2015 at 5:09 PM, Mike Jones <M= ichael.Jones@microsoft.com> wrote:

Some of you have seen my remark below but I=E2=80= =99m resending it to get it on the record for those of you have not=E2=80=A6=

 

I want to stay completely clear of situations in= which multiple kinds of messages are sent to the same endpoint and then dis= patched to do different things based on the message type.  That is the pattern that led people to abandon S= OAP/WS-* for REST.  I don=E2=80=99t want to be part of recreating it.

 

For instance, I only want logout message to be s= ent to the OpenID Connect logout endpoint.  It=E2=80=99s appropriate fo= r the endpoint to *validate* that the message conforms to the specified logout message s= yntax and otherwise reject the message.  But the only action taken for m= essages of other types should be to drop them =E2=80=93 not dispatch them.

 

        =             &nbs= p;            &n= bsp;            =             &nbs= p; -- Mike

 

From: Id-event [mailto:id-event-bounces@ietf.org] On Behalf Of Mike Jones
Sent: Wednesday, November 04, 2015 5:05 PM
To: William Denniss; Justin Richer

<= br> Cc: John Bradley; id-event@ietf.org
Subject: Re: [Id-event] Distinguishing different JWT types<= /u>

 

The part of this thread dealing with logout shou= ld have included a reference to this text in http://openid.net/specs/openid-connect-backchannel-1_0-01.html#LogoutToken:

 

logout_only

REQUIRED. Value d= eclaring that this JWT is only to be used as a Logout Token. In particular, t= his JWT cannot be used in any context where an ID Token is used. The value of this Claim MUST be the JSON= boolean value true.

 

This claim is currently used to =E2=80=9Ctype=E2= =80=9D the logout token.  Changing from =E2=80=9Clogout_only=E2=80=9D:t= rue to =E2=80=9Cjty=E2=80=9D: =E2=80=9Clogout=E2=80=9D or something similar w= ould be fine.

 

John suggested that we prohibit the inclusion of= =E2=80=9Cnonce=E2=80=9D as a second way of ensuring that that token couldn=E2= =80=99t be repurposed as an ID Token.  That would work even if the code wasn=E2=80=99t checking for =E2=80=9Clogout_only=E2=80=9D o= r =E2=80=9Cjty=E2=80=9D.

 

        =             &nbs= p;            &n= bsp;            =             &nbs= p; -- Mike

 

From: Id-event [mailto:id-event-bounces@ietf.org] On Behalf Of William Denniss
Sent: Wednesday, November 04, 2015 4:54 PM
To: Justin Richer
Cc: John Bradley; id-event@ietf.org
Subject: Re: [Id-event] Distinguishing different JWT types<= /u>

 

Fair points. My main concern is that we don't always k= now how people treat ID Tokens (or JWTs more generally), and one of their ni= ce properties is that they are designed to be verifiable if transmitted over= an untrusted medium.

 

I think we can build in more protection going forward= by having a clear type indicator. Imagine having 6 different JWT types, all= potentially validating as the other types. It seems dangerous if the only p= rotection is that they shouldn't be accepted outside their intended flows, and also downright confusing as t= hey all look similar.

 

Removing fields to break potential re-use doesn't sca= le, and doesn't help understandability either.

 

 

On Wed, Nov 4, 2015 at 4:24 PM, Justin Richer <jricher@mit.edu> wro= te:

I=E2=80=99m very much in favor of having a JWT token t= ype key, but for other reasons and uses. 

 

I=E2=80=99m just taking issue with the assertion that= a logout token could be easily confused by a functioning OIDC client.

 

Even then I think it=E2=80=99s a good idea to have a =E2= =80=9Ctyp": =E2=80=9Clogout=E2=80=9D tag in it. The current guideline to tak= e the =E2=80=9Cnonce=E2=80=9D out is a profoundly stupid hack that=E2=80=99s= not likely to make much difference in the real world, or at least even less= of a difference than a type parameter.

 

Along those lines, I=E2=80=99d suggest we use =E2=80=9C= jtt" or =E2=80=9CJSON (web) Token Type=E2=80=9D as the field name, so we don= =E2=80=99t cause confusion with the header =E2=80=9Ctyp=E2=80=9D parameter.<= u>

 <= u>

 =E2=80=94= Justin

 

On Nov 4, 2015, at 4:06 PM, John Bradley <ve7jtb@ve7jtb.com> wrote= :

 

In principal a client gets a token two ways.  

1 via a token endpoint in a direct communication.<= /u>

2 via the authorization endpoint, In this case a clie= nt needs to check the nonce value to correlate the token with the user agent= that the request was made via.

 

I think it is fair not to have a nonce in the other t= okens as they are not requested via the browser.  Nonce would also not b= e appropriate for a JWT assertion.

 

I would be more worried about other sorts of assertio= ns being confused, or at-least not easily differentiated. 

 

I don=E2=80=99t think having a explicit JWT token typ= e being a bad thing.   Adding it would not disrupt existing clients. &n= bsp;

 

I think it is more a case of determining if this will= be useful for other things.   In connect it would really only help bad= ly coded clients who are unlikely to check it anyway.

 

John B.

 

On Nov 4, 2015, at 2:36 PM, Justin Richer <jricher@mit.edu> wrote:=

 

I think a real question with regard to the login/logo= ut case is, succinctly, =E2=80=9CWhy is an application accepting an ID token= from an unknown third-party as proof of login=E2=80=9D? In the normal OIDC p= rocess, the client will only get the ID token in response to an authentication request, so it shouldn=E2=80=99t ever be j= ust listening for incoming ID tokens.

 

 =E2=80=94 Justin

 

On Nov 4, 2015, at 2:19 PM, William Denniss <wdenniss@google.com&= gt; wrote:

 

Hi Everyone,

 

It was good talking to many of you at Yokohama earlie= r in the week about using JWTs for event messages like Logout, Risk Signals,= SCIM profile updates and more. Thank you Phil for starting this conversatio= n and spinning up the list! We're all doing related things with events, and it makes sense to collaborate and= unify our approaches.

 

An issue with JWT reuse currently is that ID Tokens a= re defined by OpenID Connect to require only a few standard JWT claims, and the required claims are highly re-usable and co= ntain nothing that actually sets them apart as an "ID Token".<= /p>

 

The risk of this is that a JWT for an event like logo= ut can be a valid ID Token for login.  An attacker in possession of a l= ogout token could replay it against a login endpoint, and gain access.

 

One mitigation is to change the issuer, or audience. T= o me this is undesirable as the events (e.g. logout) do relate to the same i= ssuer and audience. Like matter and anti-matter, yin and yang =E2=80=93 logo= ut should simply reverse the login.  It seems wasteful to spin up a new issuer, new key rotations, and more just to= manage each different type of event, if they would otherwise be related by i= ssuer.

 

Currently the Backchannel Logout draft attempts to "break" this utility of a logout JW= T for authentication by prohibiting the 'nonce' field:

The following Claim MUST NOT b= e used within the Logout Token:

 

nonce<= u>

PROHIBITED. A nonce Claim MUST NOT be present. Its use is prohibited to make a Logout Token syntactically invalid if used i= n a forged Authentication Response in place of an ID Token.

 

I'm concerned that this may not always work as intend= ed, as 'nonce' is not a required field of the ID Token. ID Tokens obtained f= rom Google using the code flow (on our OpenID Connect certified endpoints) d= o not contain 'nonce' today, for example. And I'm a little worried that RPs may not be strictly checking for= a 'nonce', even when they should (e.g. when using the implicit flow).

 

Even if this approach works in this specific case, it= 's not scalable. So I propose that we move to adopt a new standard claim tha= t can be used to indicate the intended purpose of the JWT.

=

 

'typ' is an obvious choice for a claim name, although= the word 'type' may be a little overloaded already. Another option could be= "cat" for category.  Whatever we decide, I think such a claim should b= e used in all JWT specs going forward, and added to OpenID Connect ID Tokens in a future revision.

 

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
<= span>https://www.= ietf.org/mailman/listinfo/id-event
<= /html>= --Apple-Mail-153B7E29-33F8-46F0-BCB2-28891D43760A-- From nobody Wed Nov 4 18:08:33 2015 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 608271B37DC for ; Wed, 4 Nov 2015 18:08:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 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, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fFux6Vly7z8G for ; Wed, 4 Nov 2015 18:08:30 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAEC21B37CE for ; Wed, 4 Nov 2015 18:08:29 -0800 (PST) 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 tA528Qpp017504 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 5 Nov 2015 02:08:26 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id tA528Qw9012236 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 5 Nov 2015 02:08:26 GMT Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id tA528PmT011558 for ; Thu, 5 Nov 2015 02:08:26 GMT Received: from dhcp-87-184.meeting.ietf94.jp (/133.93.87.184) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 04 Nov 2015 18:08:25 -0800 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_283394E3-4255-41D6-A8B2-394E522314C8" Message-Id: <1FD8DEED-5526-4E7C-BD3E-8FD3DF482FAB@oracle.com> Date: Thu, 5 Nov 2015 11:08:23 +0900 To: id-event@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Subject: [Id-event] Getting going some new drafts... X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 02:08:32 -0000 --Apple-Mail=_283394E3-4255-41D6-A8B2-394E522314C8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I propose we initially plan to write 2 individual contribution drafts: * ID Event Protocol - based on a set of RESTful Publish and Subscribe and event = pickup/delivery endpoints as well as defining Feeds * ID Event Token - based on JWT and JOSE upon which different areas can build domain = specific events (e.g. SCIM, OIDC Logout, OAuth Token Revocation, RISC, = and so on) There is a fair amount of text that can be re-used from = https://tools.ietf.org/html/draft-hunt-scim-notify-00 = . However the = architecture described in the document will likely be different. The = publisher to hub portion isn=E2=80=99t needed, however much of the = functionality described in the hub is needed (e.g. how a client = registers for subscription and how a client receives events). I=E2=80=99m happy to get started on the protocol stuff. Would anyone = like to volunteer on starting the Event Token spec? Note: Please don=E2=80=99t stop discussing. As a writer, I don=E2=80=99t = mind adjusting as we go. In particular what do you like or hate about = the notify mechanisms for delivery? Phil @independentid www.independentid.com phil.hunt@oracle.com --Apple-Mail=_283394E3-4255-41D6-A8B2-394E522314C8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
I propose we initially plan to write 2 = individual contribution drafts:

* ID Event Protocol
  - based on a set of RESTful Publish and Subscribe and = event pickup/delivery endpoints as well as defining Feeds
* ID Event Token
  - based on JWT = and JOSE upon which different areas can build domain specific events = (e.g. SCIM, OIDC Logout, OAuth Token Revocation, RISC, and so = on)

There is a = fair amount of text that can be re-used from https://tools.ietf.org/html/draft-hunt-scim-notify-00. = However the architecture described in the document will likely be = different. The publisher to hub portion isn=E2=80=99t needed, however = much of the functionality described in the hub is needed (e.g. how a = client registers for subscription and how a client receives = events).

I=E2=80=99= m happy to get started on the protocol stuff. Would anyone like to = volunteer on starting the Event Token spec?

Note:  Please don=E2=80=99t stop = discussing. As a writer, I don=E2=80=99t mind adjusting as we go. In = particular what do you like or hate about the notify mechanisms for = delivery?

Phil

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

= --Apple-Mail=_283394E3-4255-41D6-A8B2-394E522314C8-- From nobody Wed Nov 4 18:17:01 2015 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C769C1B3653 for ; Wed, 4 Nov 2015 18:16:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.661 X-Spam-Level: X-Spam-Status: No, score=-1.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1kaL3R6L0NWK for ; Wed, 4 Nov 2015 18:16:57 -0800 (PST) Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [IPv6:2001:6b0:8:2::201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A90E1A6FEC for ; Wed, 4 Nov 2015 18:16:56 -0800 (PST) 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 tA52GqNt004524 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Thu, 5 Nov 2015 03:16:52 +0100 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 tA52GnM7011492 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 5 Nov 2015 03:16:52 +0100 (CET) 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=1446689812; bh=DUiFfbTx7UDUhDetOoP9/EO2WxqRW65SUll9RDN42GE=; h=Subject:To:References:From:Date:In-Reply-To; b=aI0eM20JJkNUIBKvc+n4IPyMXMjtcmiiNEFfm/Ea+tFPVPCCooX7iFoG/KhGYRUxe AaGRwN+qScLh+Z+55tAU83lPrDIPY6d76RK/hg13HBhjMdYqT6hae6kwLBRdRbm1pT 7EFJveDAnYoq5jml8DZdeOUXE6x0J2CrBrNHHY34= X-Footer: c3VuZXQuc2U= Received: from [133.93.30.168] ([133.93.30.168]) (authenticated user leifj@sunet.se) by kerio.sunet.se (Kerio Connect 8.5.2) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128 bits)) for id-event@ietf.org; Thu, 5 Nov 2015 03:16:47 +0100 To: id-event@ietf.org References: <1FD8DEED-5526-4E7C-BD3E-8FD3DF482FAB@oracle.com> From: Leif Johansson Message-ID: <563ABC0B.3020903@sunet.se> Date: Thu, 5 Nov 2015 03:16:43 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <1FD8DEED-5526-4E7C-BD3E-8FD3DF482FAB@oracle.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, outbound-sunet-se:default, sunet-se:default, base:default, @@RPTN) X-CanIt-Geo: ip=192.36.171.210; country=SE; latitude=59.3294; longitude=18.0686; http://maps.google.com/maps?q=59.3294,18.0686&z=6 X-CanItPRO-Stream: outbound-sunet-se:outbound (inherits from outbound-sunet-se:default, sunet-se:default, base:default) X-Canit-Stats-ID: 09PBCgQ70 - 314218c9d76c - 20151105 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] Getting going some new drafts... X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 02:17:00 -0000 On 2015-11-05 03:08, Phil Hunt wrote: > I propose we initially plan to write 2 individual contribution drafts: > > * ID Event Protocol > - based on a set of RESTful Publish and Subscribe and event > pickup/delivery endpoints as well as defining Feeds My standard question: where does webpush go? > * ID Event Token > - based on JWT and JOSE upon which different areas can build domain > specific events (e.g. SCIM, OIDC Logout, OAuth Token Revocation, RISC, > and so on) > > There is a fair amount of text that can be re-used > from https://tools.ietf.org/html/draft-hunt-scim-notify-00. However the > architecture described in the document will likely be different. The > publisher to hub portion isn’t needed, however much of the functionality > described in the hub is needed (e.g. how a client registers for > subscription and how a client receives events). > > I’m happy to get started on the protocol stuff. Would anyone like to > volunteer on starting the Event Token spec? > > Note: Please don’t stop discussing. As a writer, I don’t mind adjusting > as we go. In particular what do you like or hate about the notify > mechanisms for delivery? > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > From nobody Wed Nov 4 18:23:33 2015 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A49F1B38DC for ; Wed, 4 Nov 2015 18:23:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F304seQqrz9S for ; Wed, 4 Nov 2015 18:23:30 -0800 (PST) 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 0E3821B3691 for ; Wed, 4 Nov 2015 18:23:30 -0800 (PST) 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 tA52NSpD012950 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 5 Nov 2015 02:23:28 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0022.oracle.com (8.13.8/8.13.8) with ESMTP id tA52NRYc027913 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 5 Nov 2015 02:23:27 GMT Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id tA52NQkS030990; Thu, 5 Nov 2015 02:23:26 GMT Received: from dhcp-87-184.meeting.ietf94.jp (/133.93.87.184) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 04 Nov 2015 18:23:26 -0800 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Phil Hunt In-Reply-To: <563ABC0B.3020903@sunet.se> Date: Thu, 5 Nov 2015 11:23:24 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <0ECC7327-B2CE-45EA-B619-822646697627@oracle.com> References: <1FD8DEED-5526-4E7C-BD3E-8FD3DF482FAB@oracle.com> <563ABC0B.3020903@sunet.se> To: Leif Johansson X-Mailer: Apple Mail (2.2104) X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Cc: id-event@ietf.org Subject: Re: [Id-event] Getting going some new drafts... X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 02:23:31 -0000 WebPUSH really has a completely differnt objective. They seem to want = assured delivery for mobile. They don=92t have a subscription concept and thus have indicated they = will not consider cases beyond 1:1. Phil @independentid www.independentid.com phil.hunt@oracle.com > On Nov 5, 2015, at 11:16 AM, Leif Johansson wrote: >=20 > On 2015-11-05 03:08, Phil Hunt wrote: >> I propose we initially plan to write 2 individual contribution = drafts: >>=20 >> * ID Event Protocol >> - based on a set of RESTful Publish and Subscribe and event >> pickup/delivery endpoints as well as defining Feeds >=20 > My standard question: where does webpush go? >=20 >> * ID Event Token >> - based on JWT and JOSE upon which different areas can build domain >> specific events (e.g. SCIM, OIDC Logout, OAuth Token Revocation, = RISC, >> and so on) >>=20 >> There is a fair amount of text that can be re-used >> from https://tools.ietf.org/html/draft-hunt-scim-notify-00. However = the >> architecture described in the document will likely be different. The >> publisher to hub portion isn=92t needed, however much of the = functionality >> described in the hub is needed (e.g. how a client registers for >> subscription and how a client receives events). >>=20 >> I=92m happy to get started on the protocol stuff. Would anyone like = to >> volunteer on starting the Event Token spec? >>=20 >> Note: Please don=92t stop discussing. As a writer, I don=92t mind = adjusting >> as we go. In particular what do you like or hate about the notify >> mechanisms for delivery? >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=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 From nobody Wed Nov 4 18:27:25 2015 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FC7C1B38FD for ; Wed, 4 Nov 2015 18:27:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wr35fCHgDR_j for ; Wed, 4 Nov 2015 18:27:22 -0800 (PST) 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 D88C21B38D7 for ; Wed, 4 Nov 2015 18:27:22 -0800 (PST) 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 tA52RM4u016153 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 5 Nov 2015 02:27:22 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0022.oracle.com (8.13.8/8.13.8) with ESMTP id tA52RLcs006496 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 5 Nov 2015 02:27:22 GMT Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id tA52RLLp016965; Thu, 5 Nov 2015 02:27:21 GMT Received: from [133.93.87.170] (/133.93.87.170) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 04 Nov 2015 18:27:21 -0800 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Phil Hunt X-Mailer: iPhone Mail (13B143) In-Reply-To: <0ECC7327-B2CE-45EA-B619-822646697627@oracle.com> Date: Thu, 5 Nov 2015 11:27:19 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <7F7BE7B2-0C10-4BE0-9924-29D4A7241826@oracle.com> References: <1FD8DEED-5526-4E7C-BD3E-8FD3DF482FAB@oracle.com> <563ABC0B.3020903@sunet.se> <0ECC7327-B2CE-45EA-B619-822646697627@oracle.com> To: Leif Johansson X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Cc: id-event@ietf.org Subject: Re: [Id-event] Getting going some new drafts... X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 02:27:24 -0000 Sorry. More importantly, webpush does not have a publish and subscribe conc= ept around feeds. I did however include webpush in the notify spec to show how it might tie in= . =20 Phil > On Nov 5, 2015, at 11:23, Phil Hunt wrote: >=20 > WebPUSH really has a completely differnt objective. They seem to want ass= ured delivery for mobile. >=20 > They don=E2=80=99t have a subscription concept and thus have indicated the= y will not consider cases beyond 1:1. >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >> On Nov 5, 2015, at 11:16 AM, Leif Johansson wrote: >>=20 >> On 2015-11-05 03:08, Phil Hunt wrote: >>> I propose we initially plan to write 2 individual contribution drafts: >>>=20 >>> * ID Event Protocol >>> - based on a set of RESTful Publish and Subscribe and event >>> pickup/delivery endpoints as well as defining Feeds >>=20 >> My standard question: where does webpush go? >>=20 >>> * ID Event Token >>> - based on JWT and JOSE upon which different areas can build domain >>> specific events (e.g. SCIM, OIDC Logout, OAuth Token Revocation, RISC, >>> and so on) >>>=20 >>> There is a fair amount of text that can be re-used >>> from https://tools.ietf.org/html/draft-hunt-scim-notify-00. However the >>> architecture described in the document will likely be different. The >>> publisher to hub portion isn=E2=80=99t needed, however much of the funct= ionality >>> described in the hub is needed (e.g. how a client registers for >>> subscription and how a client receives events). >>>=20 >>> I=E2=80=99m happy to get started on the protocol stuff. Would anyone lik= e to >>> volunteer on starting the Event Token spec? >>>=20 >>> Note: Please don=E2=80=99t stop discussing. As a writer, I don=E2=80=99= t mind adjusting >>> as we go. In particular what do you like or hate about the notify >>> mechanisms for delivery? >>>=20 >>> Phil >>>=20 >>> @independentid >>> www.independentid.com >>> phil.hunt@oracle.com >>>=20 >>>=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 >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event From nobody Wed Nov 4 18:30:05 2015 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 567E11B390C for ; Wed, 4 Nov 2015 18:30:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 36Kx--FKljTx for ; Wed, 4 Nov 2015 18:30:01 -0800 (PST) Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::233]) (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 98FAC1B38F5 for ; Wed, 4 Nov 2015 18:30:01 -0800 (PST) Received: by qgbb65 with SMTP id b65so56189478qgb.2 for ; Wed, 04 Nov 2015 18:30:00 -0800 (PST) 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 :cc:content-type; bh=oTKYonh3LFUWKgQbFi6Rc2csDrIzDPppf4uVEC1pJAw=; b=KfBdVQPLSlV7DTD0zC5SXONpj2S+5tVRbW6enSOkW1jP7thk/IPzlIIAmgOtRVxYO3 1E4xX3G1TvmqQiVKkPBDU8AFZU6AzGKj+fiYlVD4I3q7Laj36rnm0w0x5VgwLUpkf3Np VmThk/Y8SQi13BctN8vZotNS2sSWwvfa3nr5bI1MKR658ocUQd3APOEHWRVWiIshNiZ0 DJ60u7ShibBPgPfGkO03KngnoQc6Db/OZKIxVJwinTH6/nCd14ZnZ5dXSouy/F79+tWl LMj39pLlygexW65+QHzE5DD+d91oiA7U/RyYpPEzfvZRNgzK/WdEJON+uINICRDwWWps b/2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=oTKYonh3LFUWKgQbFi6Rc2csDrIzDPppf4uVEC1pJAw=; b=b5B+Sb5K0YyuTIc9UUcmMAtokfcpla48DyAMG39usXX0hW3Yr/jos792ufnSOkOkK/ EtFbEuv/9qrCiUMLOAX5EKDF9rkzMYSELdCs8TkudA1793wf7qDrEObk51V+Ga2fpZn4 Bjrlp7tzEvYOv6rbwMWc+KHfsaHmk0PhTZuDXLL3qzGMVU6CzAqUlP6RsqfvpJxUACp7 +P8AKyYGVW6L6FEZHIFAAySZB9EIS4jKpNlYaM0f5zyCYi8mghK/vUoB6V2fdRqeMbuA 6ULBbbTkfyrpuyByiPF3h3xGpx0Z+sZrMuO1wP8NcjT8k03AR/SsRf4LjSAFUUhpL2YV p0KA== X-Gm-Message-State: ALoCoQlDDBLMUShSuqBNvJST4tMuLV7/4kY3V01bAtaEkQh/rJNQmxrXbM3eonnW1hB3/47SKzST X-Received: by 10.140.21.133 with SMTP id 5mr4914320qgl.36.1446690600614; Wed, 04 Nov 2015 18:30:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.81.99 with HTTP; Wed, 4 Nov 2015 18:29:41 -0800 (PST) In-Reply-To: <1FD8DEED-5526-4E7C-BD3E-8FD3DF482FAB@oracle.com> References: <1FD8DEED-5526-4E7C-BD3E-8FD3DF482FAB@oracle.com> From: William Denniss Date: Thu, 5 Nov 2015 11:29:41 +0900 Message-ID: To: Phil Hunt Content-Type: multipart/alternative; boundary=001a11c123ea59cfa60523c1e7c7 Archived-At: Cc: id-event@ietf.org Subject: Re: [Id-event] Getting going some new drafts... X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 02:30:03 -0000 --001a11c123ea59cfa60523c1e7c7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sounds good to me. I'm happy to volunteer to write the Event Token spec. On Thu, Nov 5, 2015 at 11:08 AM, Phil Hunt wrote: > I propose we initially plan to write 2 individual contribution drafts: > > * ID Event Protocol > - based on a set of RESTful Publish and Subscribe and event > pickup/delivery endpoints as well as defining Feeds > * ID Event Token > - based on JWT and JOSE upon which different areas can build domain > specific events (e.g. SCIM, OIDC Logout, OAuth Token Revocation, RISC, an= d > so on) > > There is a fair amount of text that can be re-used from > https://tools.ietf.org/html/draft-hunt-scim-notify-00. However the > architecture described in the document will likely be different. The > publisher to hub portion isn=E2=80=99t needed, however much of the functi= onality > described in the hub is needed (e.g. how a client registers for > subscription and how a client receives events). > > I=E2=80=99m happy to get started on the protocol stuff. Would anyone like= to > volunteer on starting the Event Token spec? > > Note: Please don=E2=80=99t stop discussing. As a writer, I don=E2=80=99t= mind adjusting > as we go. In particular what do you like or hate about the notify > mechanisms for delivery? > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > --001a11c123ea59cfa60523c1e7c7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sounds good to me.

I'm happy to vol= unteer to write the Event Token spec.

On Thu, Nov 5, 2015 at 11:08 AM, Phil Hunt = <phil.hunt@oracle.com> wrote:
I propose we initially plan= to write 2 individual contribution drafts:

* ID E= vent Protocol
=C2=A0 - based on a set of RESTful Publish and Subs= cribe and event pickup/delivery endpoints as well as defining Feeds
* ID Event Token
=C2=A0 - based on JWT and JOSE upon which dif= ferent areas can build domain specific events (e.g. SCIM, OIDC Logout, OAut= h Token Revocation, RISC, and so on)

There is a fa= ir amount of text that can be re-used from=C2=A0https://tools.ietf= .org/html/draft-hunt-scim-notify-00. However the architecture described= in the document will likely be different. The publisher to hub portion isn= =E2=80=99t needed, however much of the functionality described in the hub i= s needed (e.g. how a client registers for subscription and how a client rec= eives events).
=

I=E2=80=99m happy to get started on the protocol stuff. Would anyone = like to volunteer on starting the Event Token spec?

Note: =C2=A0Please don=E2=80=99t stop discussing. As a writer, I don=E2= =80=99t mind adjusting as we go. In particular what do you like or hate abo= ut the notify mechanisms for delivery?

Phil
<= div>
@independentid
phil.hunt@oracle.com=


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


--001a11c123ea59cfa60523c1e7c7-- From nobody Wed Nov 4 21:18:20 2015 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 498301B3973 for ; Wed, 4 Nov 2015 21:18:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.661 X-Spam-Level: X-Spam-Status: No, score=-1.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ajEMVIU3xU10 for ; Wed, 4 Nov 2015 21:18:17 -0800 (PST) Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [IPv6:2001:6b0:8:2::201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D73F31ABD3C for ; Wed, 4 Nov 2015 21:18:16 -0800 (PST) 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 tA55IDR0027807 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 5 Nov 2015 06:18:13 +0100 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 tA55IARl015941 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Nov 2015 06:18:13 +0100 (CET) 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=1446700693; bh=xTt1MnVOltWwjzJkIyuK5vR0SHh3eCcB47+CRDOcPI4=; h=Subject:To:References:Cc:From:Date:In-Reply-To; b=W38bMkQXEKn9qegibpTtWvr3emxhWNR5XelQF72G+nLGVnzEDsAGdVt9h3z7NM6Eg 7mWhXHrStPUYYURwcsFRv5X2aDm3wavPg/ZPx2L808cguvGJ+Gvm6nSv9M14de/NC+ bMASWtcPC09Rlwf15VwOeOxN5ZOiu30ejvE4ZsNU= X-Footer: c3VuZXQuc2U= Received: from [133.93.30.168] ([133.93.30.168]) (authenticated user leifj@sunet.se) by kerio.sunet.se (Kerio Connect 8.5.2) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128 bits)); Thu, 5 Nov 2015 06:18:08 +0100 To: Phil Hunt References: <1FD8DEED-5526-4E7C-BD3E-8FD3DF482FAB@oracle.com> <563ABC0B.3020903@sunet.se> <0ECC7327-B2CE-45EA-B619-822646697627@oracle.com> <7F7BE7B2-0C10-4BE0-9924-29D4A7241826@oracle.com> From: Leif Johansson Message-ID: <563AE68D.6080602@sunet.se> Date: Thu, 5 Nov 2015 06:18:05 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <7F7BE7B2-0C10-4BE0-9924-29D4A7241826@oracle.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, outbound-sunet-se:default, sunet-se:default, base:default, @@RPTN) X-CanIt-Geo: ip=192.36.171.210; country=SE; latitude=59.3294; longitude=18.0686; http://maps.google.com/maps?q=59.3294,18.0686&z=6 X-CanItPRO-Stream: outbound-sunet-se:outbound (inherits from outbound-sunet-se:default, sunet-se:default, base:default) X-Canit-Stats-ID: 09PBFidPH - df52102d293c - 20151105 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: Cc: id-event@ietf.org Subject: Re: [Id-event] Getting going some new drafts... X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 05:18:19 -0000 On 2015-11-05 03:27, Phil Hunt wrote: > Sorry. More importantly, webpush does not have a publish and subscribe concept around feeds. > but isn't that just a management layer for a bunch of webpush 1-1's? > I did however include webpush in the notify spec to show how it might tie in. > > Phil > >> On Nov 5, 2015, at 11:23, Phil Hunt wrote: >> >> WebPUSH really has a completely differnt objective. They seem to want assured delivery for mobile. >> >> They don’t have a subscription concept and thus have indicated they will not consider cases beyond 1:1. >> >> Phil >> >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >> >>> On Nov 5, 2015, at 11:16 AM, Leif Johansson wrote: >>> >>> On 2015-11-05 03:08, Phil Hunt wrote: >>>> I propose we initially plan to write 2 individual contribution drafts: >>>> >>>> * ID Event Protocol >>>> - based on a set of RESTful Publish and Subscribe and event >>>> pickup/delivery endpoints as well as defining Feeds >>> >>> My standard question: where does webpush go? >>> >>>> * ID Event Token >>>> - based on JWT and JOSE upon which different areas can build domain >>>> specific events (e.g. SCIM, OIDC Logout, OAuth Token Revocation, RISC, >>>> and so on) >>>> >>>> There is a fair amount of text that can be re-used >>>> from https://tools.ietf.org/html/draft-hunt-scim-notify-00. However the >>>> architecture described in the document will likely be different. The >>>> publisher to hub portion isn’t needed, however much of the functionality >>>> described in the hub is needed (e.g. how a client registers for >>>> subscription and how a client receives events). >>>> >>>> I’m happy to get started on the protocol stuff. Would anyone like to >>>> volunteer on starting the Event Token spec? >>>> >>>> Note: Please don’t stop discussing. As a writer, I don’t mind adjusting >>>> as we go. In particular what do you like or hate about the notify >>>> mechanisms for delivery? >>>> >>>> Phil >>>> >>>> @independentid >>>> www.independentid.com >>>> phil.hunt@oracle.com >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 From nobody Wed Nov 4 21:25:11 2015 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F41341B39B2 for ; Wed, 4 Nov 2015 21:25:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lF5DpGegNCcQ for ; Wed, 4 Nov 2015 21:25:07 -0800 (PST) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5F511B399E for ; Wed, 4 Nov 2015 21:25:07 -0800 (PST) Received: by pasz6 with SMTP id z6so78657785pas.2 for ; Wed, 04 Nov 2015 21:25:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb_com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=UBst5Xrt+oLriSzi7PwXqgaefZEMlDMQmSdUoy+xZCM=; b=E1muCZYFRBnEbqrIguor5supXA+++NPwCBEcnAM3cRQZ70L5u8TkXtT3wrvaPI833h 8RnkmLV43vUKRWeixf3kn+QZE1LTSPVX7w5x+1OkfEfN2Pe9AoG57x+BUXAqFuxQeldU NoTBH0SFiIOv3wK8M4MUvdIKoCDSIU3rp+c6DdBpq9HnJr92wb5SKXTIkXWbRgsVwDfX HPwtSsKqRcmw5umfd1mQMadM2wZtDkoWHXiqA5gZFp1MYwESFqgFFGNj6XhP9Jm8XWXK fjE7Q5+KaPWcnyndYzhfREi/Sm8OinQSbjk41wNhXtlhb0oFCmFdE4xxkKZi2UqqvoKF xlVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=UBst5Xrt+oLriSzi7PwXqgaefZEMlDMQmSdUoy+xZCM=; b=Vp98hNAPMshlSW+YJr/FhbFYmgj8qJf0PVy/2SV8/PaOgVMHf519/I9alEzBsHq3by AfmYF9gF7D4dWWDZ/PreVsZ5mqlmS018EsN2cdryFC7ykoyrRDZJu3QGZvR2w9tpBzBH yi2DLhQMC2gD9S5Am6IAfCvhv5cBBasTXPU71VQ9lz217NT9fPATE8IDRvS3gtJCMUnq bw7DAKnwRggwO6N4bxm4mKxsSxhufSH8WzjPAy83+AlkA2QpPiofbpIXDIHBD0mYZyL0 9tetketod6kylRj0M0OAi8krbZJdcjMMVTBRnhZiB3JVWv46EeooxZnzut4ADijYsRdt 2/FA== X-Gm-Message-State: ALoCoQlvgddaWqGl4/JcqRoiJHhlNmaMqxeCt/s0ORoNiZgQYXT+Ns8uEvinE/xePMZ3BzxZ7n1E X-Received: by 10.68.65.104 with SMTP id w8mr7062569pbs.48.1446701107300; Wed, 04 Nov 2015 21:25:07 -0800 (PST) Received: from t20010c400000300870f266d8f63b746c.v6.meeting.ietf94.jp (t20010c400000300870f266d8f63b746c.v6.meeting.ietf94.jp. [2001:c40:0:3008:70f2:66d8:f63b:746c]) by smtp.gmail.com with ESMTPSA id f3sm5250540pas.36.2015.11.04.21.25.05 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Nov 2015 21:25:06 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: John Bradley In-Reply-To: <563AE68D.6080602@sunet.se> Date: Thu, 5 Nov 2015 14:25:05 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1FD8DEED-5526-4E7C-BD3E-8FD3DF482FAB@oracle.com> <563ABC0B.3020903@sunet.se> <0ECC7327-B2CE-45EA-B619-822646697627@oracle.com> <7F7BE7B2-0C10-4BE0-9924-29D4A7241826@oracle.com> <563AE68D.6080602@sunet.se> To: Leif Johansson X-Mailer: Apple Mail (2.2104) Archived-At: Cc: id-event@ietf.org, Phil Hunt Subject: Re: [Id-event] Getting going some new drafts... X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 05:25:10 -0000 Most of this is server to server communication. I don=E2=80=99t know = that webpush adds that much for servers. If we are trying to push to = native apps or browsers then I could see webpush making more sense. John B. > On Nov 5, 2015, at 2:18 PM, Leif Johansson wrote: >=20 > On 2015-11-05 03:27, Phil Hunt wrote: >> Sorry. More importantly, webpush does not have a publish and = subscribe concept around feeds. >>=20 >=20 > but isn't that just a management layer for a bunch of webpush 1-1's? >=20 >> I did however include webpush in the notify spec to show how it might = tie in. =20 >>=20 >> Phil >>=20 >>> On Nov 5, 2015, at 11:23, Phil Hunt wrote: >>>=20 >>> WebPUSH really has a completely differnt objective. They seem to = want assured delivery for mobile. >>>=20 >>> They don=E2=80=99t have a subscription concept and thus have = indicated they will not consider cases beyond 1:1. >>>=20 >>> Phil >>>=20 >>> @independentid >>> www.independentid.com >>> phil.hunt@oracle.com >>>=20 >>>> On Nov 5, 2015, at 11:16 AM, Leif Johansson wrote: >>>>=20 >>>> On 2015-11-05 03:08, Phil Hunt wrote: >>>>> I propose we initially plan to write 2 individual contribution = drafts: >>>>>=20 >>>>> * ID Event Protocol >>>>> - based on a set of RESTful Publish and Subscribe and event >>>>> pickup/delivery endpoints as well as defining Feeds >>>>=20 >>>> My standard question: where does webpush go? >>>>=20 >>>>> * ID Event Token >>>>> - based on JWT and JOSE upon which different areas can build = domain >>>>> specific events (e.g. SCIM, OIDC Logout, OAuth Token Revocation, = RISC, >>>>> and so on) >>>>>=20 >>>>> There is a fair amount of text that can be re-used >>>>> from https://tools.ietf.org/html/draft-hunt-scim-notify-00. = However the >>>>> architecture described in the document will likely be different. = The >>>>> publisher to hub portion isn=E2=80=99t needed, however much of the = functionality >>>>> described in the hub is needed (e.g. how a client registers for >>>>> subscription and how a client receives events). >>>>>=20 >>>>> I=E2=80=99m happy to get started on the protocol stuff. Would = anyone like to >>>>> volunteer on starting the Event Token spec? >>>>>=20 >>>>> Note: Please don=E2=80=99t stop discussing. As a writer, I = don=E2=80=99t mind adjusting >>>>> as we go. In particular what do you like or hate about the notify >>>>> mechanisms for delivery? >>>>>=20 >>>>> Phil >>>>>=20 >>>>> @independentid >>>>> www.independentid.com >>>>> phil.hunt@oracle.com >>>>>=20 >>>>>=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 >>>=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 From nobody Wed Nov 4 21:47:48 2015 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A40D1B3A01 for ; Wed, 4 Nov 2015 21:47:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.661 X-Spam-Level: X-Spam-Status: No, score=-1.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IadHo84CrYhZ for ; Wed, 4 Nov 2015 21:47:44 -0800 (PST) Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [IPv6:2001:6b0:8:2::201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 594A41A8978 for ; Wed, 4 Nov 2015 21:47:44 -0800 (PST) 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 tA55lgMc001184 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 5 Nov 2015 06:47:42 +0100 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 tA55lcNU007263 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Nov 2015 06:47:41 +0100 (CET) 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=1446702461; bh=BV0OieAhocJi4BEXRaMJVUShgZ89YhLscrGFtJPqDEo=; h=Subject:To:References:Cc:From:Date:In-Reply-To; b=GU8s2mMB8x3Li4T1/nVte2jb/sY1yoqtxwJaqa9mInE6bKjjnmwT5f1P/aF8/RFUZ 4cuSSbrsp3kKuZhnxjj+PAqUQA5DnMqkB5BPPLp5PxbE7yP4dEtNYStYolZI49zSO0 0CGGpGg+6Kwb61CYOBD4A13NeTRqd/DNFGwrrVY0= X-Footer: c3VuZXQuc2U= Received: from [133.93.30.168] ([133.93.30.168]) (authenticated user leifj@sunet.se) by kerio.sunet.se (Kerio Connect 8.5.2) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128 bits)); Thu, 5 Nov 2015 06:47:36 +0100 To: John Bradley References: <1FD8DEED-5526-4E7C-BD3E-8FD3DF482FAB@oracle.com> <563ABC0B.3020903@sunet.se> <0ECC7327-B2CE-45EA-B619-822646697627@oracle.com> <7F7BE7B2-0C10-4BE0-9924-29D4A7241826@oracle.com> <563AE68D.6080602@sunet.se> From: Leif Johansson Message-ID: <563AED73.9060105@sunet.se> Date: Thu, 5 Nov 2015 06:47:31 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, outbound-sunet-se:default, sunet-se:default, base:default, @@RPTN) X-CanIt-Geo: ip=192.36.171.210; country=SE; latitude=59.3294; longitude=18.0686; http://maps.google.com/maps?q=59.3294,18.0686&z=6 X-CanItPRO-Stream: outbound-sunet-se:outbound (inherits from outbound-sunet-se:default, sunet-se:default, base:default) X-Canit-Stats-ID: 09PBFLG4M - 2794008c92ff - 20151105 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: Cc: id-event@ietf.org, Phil Hunt Subject: Re: [Id-event] Getting going some new drafts... X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 05:47:46 -0000 On 2015-11-05 06:25, John Bradley wrote: > Most of this is server to server communication. I don’t know that webpush adds that much for servers. If we are trying to push to native apps or browsers then I could see webpush making more sense. > hmm .. I guess I'm wondering how many ways you can skin a cat^H^H^Hnotification protocol If we wind up spec:ing something that is semantically equivalent to something that already exists I'm gona blame you guys :-) Cheers Leif From nobody Wed Nov 4 21:57:06 2015 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 620D21B3A2A for ; Wed, 4 Nov 2015 21:57:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UHXnLhQQYl9p for ; Wed, 4 Nov 2015 21:57:03 -0800 (PST) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::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 DBC5E1B3A1F for ; Wed, 4 Nov 2015 21:57:03 -0800 (PST) Received: by padhx2 with SMTP id hx2so68786473pad.1 for ; Wed, 04 Nov 2015 21:57:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb_com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=6vxROP0ZQejINLwcNsGSJ9A7+T09Ioa3G5geacv+g4M=; b=ZMgTO7l0R0oKqV2c1BpW6RDahRV0zS7rG9Gn2lZYYh8s1Oefn4XInCvRsg9d0fPTDO zBGF4zjfD7e9Z0xx/Amq+IcAJZARF09J4P2fqlk5WRhyx5BwcXYZ8aMDNAPkTazkaLzC mahV6TmDXGhspAY1W0G06DAMWx9tf+RQnb5R9q6a8vZYqVGcdkO3lewTXuy3Qi/ScCZw 3PDAYPg1K8oMjIvmNYg1ux30X7FmAEotC9Pt6RFU3/f8RRIw+C+H7GVMCL8mh0tMzOPF 5FH4hJCS6q3lZgBkVB0L8mXCDzQ3iKpnCVq6+yBmLpoTattTvmV3SQzLbrsFalMwj4+D /eGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=6vxROP0ZQejINLwcNsGSJ9A7+T09Ioa3G5geacv+g4M=; b=ENAbXSv119ZRaMlajCXKXMlbtFklozZv5lMGS8gU3YYRO1mxWpNhwUDtMBpHszemCb QxYQzRS6uoHoKq2+RB/fOVVhPuEKlDYuGWj5lCtpnP3GEzm6j4t4FVeCvx+6rVTsZdQ2 JSHahktQf4VLh+ZFoR3hjT00tymMnlgAe9TeSARwryFRa/U1vqRexjfAsA+vz6CW6fKL tweZvppUPv93Wwf62XqnIBZYSWLZY2Iy236F9Vs8nF5hendx1Rhjhci/R7iVcBOAB35A lORdhDhPhXgeWzuFWjl0oepbki4s8qIy8X1z76pmOEehOlY+nwGJ99HvW3y8HuvJskGm 6g/g== X-Gm-Message-State: ALoCoQmvs68Y+e31XqKdyWhhT+icV4CpgUL7f99G5f5NctaF1GjnHkU/DMZryP3ciJgOAM0N+SRi X-Received: by 10.68.238.100 with SMTP id vj4mr7116775pbc.103.1446703023451; Wed, 04 Nov 2015 21:57:03 -0800 (PST) Received: from t20010c400000302429dca54bd11e92e6.v6.meeting.ietf94.jp (t20010c400000302429dca54bd11e92e6.v6.meeting.ietf94.jp. [2001:c40:0:3024:29dc:a54b:d11e:92e6]) by smtp.gmail.com with ESMTPSA id ix1sm5467169pbd.40.2015.11.04.21.57.01 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Nov 2015 21:57:02 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: John Bradley In-Reply-To: <563AED73.9060105@sunet.se> Date: Thu, 5 Nov 2015 14:57:01 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1FD8DEED-5526-4E7C-BD3E-8FD3DF482FAB@oracle.com> <563ABC0B.3020903@sunet.se> <0ECC7327-B2CE-45EA-B619-822646697627@oracle.com> <7F7BE7B2-0C10-4BE0-9924-29D4A7241826@oracle.com> <563AE68D.6080602@sunet.se> <563AED73.9060105@sunet.se> To: Leif Johansson X-Mailer: Apple Mail (2.2104) Archived-At: Cc: id-event@ietf.org, Phil Hunt Subject: Re: [Id-event] Getting going some new drafts... X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 05:57:05 -0000 In Connect, we were considering a simple rest API for delivering tokens = using post. =20 Phil has indicated a need for the client to also poll to catch up on = messages. =20 It may be that the transport will wind up being different for the = different use cases.=20 I don=E2=80=99t think we have come to a conclusion on that. > On Nov 5, 2015, at 2:47 PM, Leif Johansson wrote: >=20 > On 2015-11-05 06:25, John Bradley wrote: >> Most of this is server to server communication. I don=E2=80=99t = know that webpush adds that much for servers. If we are trying to push = to native apps or browsers then I could see webpush making more sense. >>=20 >=20 > hmm .. >=20 > I guess I'm wondering how many ways you can skin a = cat^H^H^Hnotification > protocol >=20 > If we wind up spec:ing something that is semantically > equivalent to something that already exists I'm gona > blame you guys :-) >=20 > Cheers Leif >=20 From nobody Wed Nov 4 22:10:11 2015 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0D101B3A57 for ; Wed, 4 Nov 2015 22:10:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2WEf752i3heU for ; Wed, 4 Nov 2015 22:10:08 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68DD81B3A34 for ; Wed, 4 Nov 2015 22:10:08 -0800 (PST) Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id tA56A7ea002781 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 5 Nov 2015 06:10:07 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 tA56A6lm021046 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 5 Nov 2015 06:10:06 GMT Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by userv0122.oracle.com (8.13.8/8.13.8) with ESMTP id tA56A6EX024883; Thu, 5 Nov 2015 06:10:06 GMT Received: from dhcp-87-184.meeting.ietf94.jp (/133.93.87.184) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 04 Nov 2015 22:10:06 -0800 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Phil Hunt In-Reply-To: <563AED73.9060105@sunet.se> Date: Thu, 5 Nov 2015 15:10:01 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <04331CC2-2729-49E2-9D38-74CADCFB376C@oracle.com> References: <1FD8DEED-5526-4E7C-BD3E-8FD3DF482FAB@oracle.com> <563ABC0B.3020903@sunet.se> <0ECC7327-B2CE-45EA-B619-822646697627@oracle.com> <7F7BE7B2-0C10-4BE0-9924-29D4A7241826@oracle.com> <563AE68D.6080602@sunet.se> <563AED73.9060105@sunet.se> To: Leif Johansson X-Mailer: Apple Mail (2.2104) X-Source-IP: aserv0021.oracle.com [141.146.126.233] Archived-At: Cc: John Bradley , id-event@ietf.org Subject: Re: [Id-event] Getting going some new drafts... X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 06:10:09 -0000 Of course, I think this is something the ADs should monitor. The reluctance does not come from me. I tried to open that door with the = WebPUSH WG twice now. They want to keep their scope focused on messaging = to mobile clients. They don=E2=80=99t want anything dealing with 1 to = many subscriptions. FWIW, I think we care less about the delivery protocol and more about = the management aspects such as how to define a feed and how a client = subscribes, not to mention what an event looks like. I don=E2=80=99t = think web push is looking at formalize specific messages either. Phil @independentid www.independentid.com phil.hunt@oracle.com > On Nov 5, 2015, at 2:47 PM, Leif Johansson wrote: >=20 > On 2015-11-05 06:25, John Bradley wrote: >> Most of this is server to server communication. I don=E2=80=99t = know that webpush adds that much for servers. If we are trying to push = to native apps or browsers then I could see webpush making more sense. >>=20 >=20 > hmm .. >=20 > I guess I'm wondering how many ways you can skin a = cat^H^H^Hnotification > protocol >=20 > If we wind up spec:ing something that is semantically > equivalent to something that already exists I'm gona > blame you guys :-) >=20 > Cheers Leif >=20 From nobody Wed Nov 4 22:42:55 2015 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1535D1B3AC7 for ; Wed, 4 Nov 2015 22:42:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.661 X-Spam-Level: X-Spam-Status: No, score=-1.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8s80GAUxTmzt for ; Wed, 4 Nov 2015 22:42:51 -0800 (PST) Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [IPv6:2001:6b0:8:2::201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 163641B3AC5 for ; Wed, 4 Nov 2015 22:42:50 -0800 (PST) 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 tA56gmv8003202 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 5 Nov 2015 07:42:48 +0100 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 tA56giQU014909 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Nov 2015 07:42:47 +0100 (CET) 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=1446705768; bh=fb30Xi0D8E3z7iKe//BwVUS3vz+eXfCdgxNQQ0Zu5W0=; h=Subject:To:References:Cc:From:Date:In-Reply-To; b=MzGwcCWl6Fz9TCCQvzjKcrvG/YqGN0CMr6KA3yRtMyjRxZ92Xw6sFNmU/88V+TIpD eECvxL5fcIBeIzjCoakZSKyvPnc5jvDeUj9FHDkmMk7itLfN8vSsqq7Jsj12GAE5nv 2dWtACeRFq6UpNXqyqSwlJb4LXvyGxPHNw9NOrlA= X-Footer: c3VuZXQuc2U= Received: from [133.93.30.168] ([133.93.30.168]) (authenticated user leifj@sunet.se) by kerio.sunet.se (Kerio Connect 8.5.2) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128 bits)); Thu, 5 Nov 2015 07:42:41 +0100 To: Phil Hunt References: <1FD8DEED-5526-4E7C-BD3E-8FD3DF482FAB@oracle.com> <563ABC0B.3020903@sunet.se> <0ECC7327-B2CE-45EA-B619-822646697627@oracle.com> <7F7BE7B2-0C10-4BE0-9924-29D4A7241826@oracle.com> <563AE68D.6080602@sunet.se> <563AED73.9060105@sunet.se> <04331CC2-2729-49E2-9D38-74CADCFB376C@oracle.com> From: Leif Johansson Message-ID: <563AFA5E.60002@sunet.se> Date: Thu, 5 Nov 2015 07:42:38 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <04331CC2-2729-49E2-9D38-74CADCFB376C@oracle.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, outbound-sunet-se:default, sunet-se:default, base:default, @@RPTN) X-CanIt-Geo: ip=192.36.171.210; country=SE; latitude=59.3294; longitude=18.0686; http://maps.google.com/maps?q=59.3294,18.0686&z=6 X-CanItPRO-Stream: outbound-sunet-se:outbound (inherits from outbound-sunet-se:default, sunet-se:default, base:default) X-Canit-Stats-ID: 09PBGGMfb - b32b25e107da - 20151105 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: Cc: John Bradley , id-event@ietf.org Subject: Re: [Id-event] Getting going some new drafts... X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 06:42:53 -0000 On 2015-11-05 07:10, Phil Hunt wrote: > Of course, I think this is something the ADs should monitor. > > The reluctance does not come from me. I tried to open that door with the WebPUSH WG twice now. They want to keep their scope focused on messaging to mobile clients. They don’t want anything dealing with 1 to many subscriptions. > > FWIW, I think we care less about the delivery protocol and more about the management aspects such as how to define a feed and how a client subscribes, not to mention what an event looks like. I don’t think web push is looking at formalize specific messages either. > ok > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > >> On Nov 5, 2015, at 2:47 PM, Leif Johansson wrote: >> >> On 2015-11-05 06:25, John Bradley wrote: >>> Most of this is server to server communication. I don’t know that webpush adds that much for servers. If we are trying to push to native apps or browsers then I could see webpush making more sense. >>> >> >> hmm .. >> >> I guess I'm wondering how many ways you can skin a cat^H^H^Hnotification >> protocol >> >> If we wind up spec:ing something that is semantically >> equivalent to something that already exists I'm gona >> blame you guys :-) >> >> Cheers Leif >> > From nobody Wed Nov 4 23:08:23 2015 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 654CE1B3B19 for ; Wed, 4 Nov 2015 23:08:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nm6A-p5BA6WG for ; Wed, 4 Nov 2015 23:08:20 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C8261B3B30 for ; Wed, 4 Nov 2015 23:08:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4021; q=dns/txt; s=iport; t=1446707299; x=1447916899; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=LujHnSHsbbXdhHMpG2YmXNIYShr/FDiyElVXu60uunw=; b=m+OmJM3XR/PrpYQC8NLGCgIqc1rWagwjDbTuRVUO+MF3RCufeQ2x3rjK MLZDOy2M7cvtbJNF0zxu1taaYv/N9ebITvQ8AKiV1i+0PxYHgvUPwMHfe OHEaHuZYAXwLPQbx4L9ZdF1lYutqdWoGyOJkBtNfK/ExcOza9B/i0376p A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D9AQDt/zpW/4gNJK1egztTbwa9aQENgV4XCoVxAoE0OBQBAQEBAQEBgQqENgEBBAEBAUYlCxACAQgOBAYMARoHJwsUAw4CBAENBYguDcF9AQEBAQEBAQEBAQEBAQEBAQEBAQEBGIZUhH6EQheEXwWNVIh0AYUciAaBWoQ/licBHwEBQoIRHYFWcoQYgQcBAQE X-IronPort-AV: E=Sophos;i="5.20,246,1444694400"; d="scan'208";a="205112073" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-5.cisco.com with ESMTP; 05 Nov 2015 07:08:18 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id tA578Iia012116 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 5 Nov 2015 07:08:18 GMT Received: from xch-rcd-004.cisco.com (173.37.102.14) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 5 Nov 2015 01:08:17 -0600 Received: from xch-rcd-004.cisco.com ([173.37.102.14]) by XCH-RCD-004.cisco.com ([173.37.102.14]) with mapi id 15.00.1104.000; Thu, 5 Nov 2015 01:08:17 -0600 From: "Morteza Ansari (moransar)" To: John Bradley , Leif Johansson Thread-Topic: [Id-event] Getting going some new drafts... Thread-Index: AQHRF27h+taCwFOWMEezzyUmsLe/+56NFb6AgAAB3gCAAAEYgIAAL7aAgAAB9YD//5a0gA== Date: Thu, 5 Nov 2015 07:08:17 +0000 Message-ID: References: <1FD8DEED-5526-4E7C-BD3E-8FD3DF482FAB@oracle.com> <563ABC0B.3020903@sunet.se> <0ECC7327-B2CE-45EA-B619-822646697627@oracle.com> <7F7BE7B2-0C10-4BE0-9924-29D4A7241826@oracle.com> <563AE68D.6080602@sunet.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.7.151005 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.100.29] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "id-event@ietf.org" , Phil Hunt Subject: Re: [Id-event] Getting going some new drafts... X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 07:08:22 -0000 I think there are many cases where clients might also want to subscribe to the notifications so we can=B9t rule that use case out. I don=B9t know if webpush is going to be appropriate or not yet, but I think it is worth thinking through the use cases and applicability of webpush for them. On 11/4/15, 9:25 PM, "Id-event on behalf of John Bradley" wrote: >Most of this is server to server communication. I don=B9t know that >webpush adds that much for servers. If we are trying to push to native >apps or browsers then I could see webpush making more sense. > >John B. >> On Nov 5, 2015, at 2:18 PM, Leif Johansson wrote: >>=20 >> On 2015-11-05 03:27, Phil Hunt wrote: >>> Sorry. More importantly, webpush does not have a publish and >>>subscribe concept around feeds. >>>=20 >>=20 >> but isn't that just a management layer for a bunch of webpush 1-1's? >>=20 >>> I did however include webpush in the notify spec to show how it might >>>tie in. =20 >>>=20 >>> Phil >>>=20 >>>> On Nov 5, 2015, at 11:23, Phil Hunt wrote: >>>>=20 >>>> WebPUSH really has a completely differnt objective. They seem to >>>>want assured delivery for mobile. >>>>=20 >>>> They don=B9t have a subscription concept and thus have indicated they >>>>will not consider cases beyond 1:1. >>>>=20 >>>> Phil >>>>=20 >>>> @independentid >>>> www.independentid.com >>>> phil.hunt@oracle.com >>>>=20 >>>>> On Nov 5, 2015, at 11:16 AM, Leif Johansson wrote: >>>>>=20 >>>>> On 2015-11-05 03:08, Phil Hunt wrote: >>>>>> I propose we initially plan to write 2 individual contribution >>>>>>drafts: >>>>>>=20 >>>>>> * ID Event Protocol >>>>>> - based on a set of RESTful Publish and Subscribe and event >>>>>> pickup/delivery endpoints as well as defining Feeds >>>>>=20 >>>>> My standard question: where does webpush go? >>>>>=20 >>>>>> * ID Event Token >>>>>> - based on JWT and JOSE upon which different areas can build domain >>>>>> specific events (e.g. SCIM, OIDC Logout, OAuth Token Revocation, >>>>>>RISC, >>>>>> and so on) >>>>>>=20 >>>>>> There is a fair amount of text that can be re-used >>>>>> from https://tools.ietf.org/html/draft-hunt-scim-notify-00. However >>>>>>the >>>>>> architecture described in the document will likely be different. The >>>>>> publisher to hub portion isn=B9t needed, however much of the >>>>>>functionality >>>>>> described in the hub is needed (e.g. how a client registers for >>>>>> subscription and how a client receives events). >>>>>>=20 >>>>>> I=B9m happy to get started on the protocol stuff. Would anyone like = to >>>>>> volunteer on starting the Event Token spec? >>>>>>=20 >>>>>> Note: Please don=B9t stop discussing. As a writer, I don=B9t mind >>>>>>adjusting >>>>>> as we go. In particular what do you like or hate about the notify >>>>>> mechanisms for delivery? >>>>>>=20 >>>>>> Phil >>>>>>=20 >>>>>> @independentid >>>>>> www.independentid.com >>>>>> phil.hunt@oracle.com >>>>>>=20 >>>>>>=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 >>>>=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 > >_______________________________________________ >Id-event mailing list >Id-event@ietf.org >https://www.ietf.org/mailman/listinfo/id-event From nobody Wed Nov 4 23:19:05 2015 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E806D1B3B49 for ; Wed, 4 Nov 2015 23:19:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.661 X-Spam-Level: X-Spam-Status: No, score=-1.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eBsZTnLaiuWp for ; Wed, 4 Nov 2015 23:19:00 -0800 (PST) Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [IPv6:2001:6b0:8:2::201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50D0B1B3B45 for ; Wed, 4 Nov 2015 23:19:00 -0800 (PST) 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 tA57Iqn8020985 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 5 Nov 2015 08:18:53 +0100 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 tA57ImoD021688 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Nov 2015 08:18:51 +0100 (CET) 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=1446707932; bh=iOqwXWZXhf2bCcLSHuEONb41RBhKBsWqzqYMe7nBK0s=; h=Subject:To:References:Cc:From:Date:In-Reply-To; b=cPcJxRE26mff5YQrxTPc+k7S7u6bOBRIHZpmpMAt8XzCzFh0ZCIYePuP8E9R9PebR 32QcK5xUlcNHPgEmeIZc3D0xyURMfUoCrWFiHgKpfVHK9fgc+oLgCR60XO8XMRIVAW gSxDNe9FgQYJd+UbYpwumYKSLynPDLHMvArn/nso= X-Footer: c3VuZXQuc2U= Received: from [133.93.48.79] ([133.93.48.79]) (authenticated user leifj@sunet.se) by kerio.sunet.se (Kerio Connect 8.5.2) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128 bits)); Thu, 5 Nov 2015 08:18:46 +0100 To: "Morteza Ansari (moransar)" , John Bradley References: <1FD8DEED-5526-4E7C-BD3E-8FD3DF482FAB@oracle.com> <563ABC0B.3020903@sunet.se> <0ECC7327-B2CE-45EA-B619-822646697627@oracle.com> <7F7BE7B2-0C10-4BE0-9924-29D4A7241826@oracle.com> <563AE68D.6080602@sunet.se> From: Leif Johansson Message-ID: <563B02D1.2020207@sunet.se> Date: Thu, 5 Nov 2015 08:18:41 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, outbound-sunet-se:default, sunet-se:default, base:default, @@RPTN) X-CanIt-Geo: ip=192.36.171.210; country=SE; latitude=59.3294; longitude=18.0686; http://maps.google.com/maps?q=59.3294,18.0686&z=6 X-CanItPRO-Stream: outbound-sunet-se:outbound (inherits from outbound-sunet-se:default, sunet-se:default, base:default) X-Canit-Stats-ID: 09PBHiRlP - c516af2ab7ec - 20151105 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: Cc: "id-event@ietf.org" , Phil Hunt Subject: Re: [Id-event] Getting going some new drafts... X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 07:19:03 -0000 On 2015-11-05 08:08, Morteza Ansari (moransar) wrote: > I think there are many cases where clients might also want to subscribe to > the notifications so we can¹t rule that use case out. I don¹t know if > webpush is going to be appropriate or not yet, but I think it is worth > thinking through the use cases and applicability of webpush for them. My point (which I will stop wining about) is this: subscription/feeds etc is just a REST api and what is left is a channel to each subscriber and how much difference is there really between a "mobile client" and a "server". Its all HTTP. > > On 11/4/15, 9:25 PM, "Id-event on behalf of John Bradley" > wrote: > >> Most of this is server to server communication. I don¹t know that >> webpush adds that much for servers. If we are trying to push to native >> apps or browsers then I could see webpush making more sense. >> >> John B. >>> On Nov 5, 2015, at 2:18 PM, Leif Johansson wrote: >>> >>> On 2015-11-05 03:27, Phil Hunt wrote: >>>> Sorry. More importantly, webpush does not have a publish and >>>> subscribe concept around feeds. >>>> >>> >>> but isn't that just a management layer for a bunch of webpush 1-1's? >>> >>>> I did however include webpush in the notify spec to show how it might >>>> tie in. >>>> >>>> Phil >>>> >>>>> On Nov 5, 2015, at 11:23, Phil Hunt wrote: >>>>> >>>>> WebPUSH really has a completely differnt objective. They seem to >>>>> want assured delivery for mobile. >>>>> >>>>> They don¹t have a subscription concept and thus have indicated they >>>>> will not consider cases beyond 1:1. >>>>> >>>>> Phil >>>>> >>>>> @independentid >>>>> www.independentid.com >>>>> phil.hunt@oracle.com >>>>> >>>>>> On Nov 5, 2015, at 11:16 AM, Leif Johansson wrote: >>>>>> >>>>>> On 2015-11-05 03:08, Phil Hunt wrote: >>>>>>> I propose we initially plan to write 2 individual contribution >>>>>>> drafts: >>>>>>> >>>>>>> * ID Event Protocol >>>>>>> - based on a set of RESTful Publish and Subscribe and event >>>>>>> pickup/delivery endpoints as well as defining Feeds >>>>>> >>>>>> My standard question: where does webpush go? >>>>>> >>>>>>> * ID Event Token >>>>>>> - based on JWT and JOSE upon which different areas can build domain >>>>>>> specific events (e.g. SCIM, OIDC Logout, OAuth Token Revocation, >>>>>>> RISC, >>>>>>> and so on) >>>>>>> >>>>>>> There is a fair amount of text that can be re-used >>>>>>> from https://tools.ietf.org/html/draft-hunt-scim-notify-00. However >>>>>>> the >>>>>>> architecture described in the document will likely be different. The >>>>>>> publisher to hub portion isn¹t needed, however much of the >>>>>>> functionality >>>>>>> described in the hub is needed (e.g. how a client registers for >>>>>>> subscription and how a client receives events). >>>>>>> >>>>>>> I¹m happy to get started on the protocol stuff. Would anyone like to >>>>>>> volunteer on starting the Event Token spec? >>>>>>> >>>>>>> Note: Please don¹t stop discussing. As a writer, I don¹t mind >>>>>>> adjusting >>>>>>> as we go. In particular what do you like or hate about the notify >>>>>>> mechanisms for delivery? >>>>>>> >>>>>>> Phil >>>>>>> >>>>>>> @independentid >>>>>>> www.independentid.com >>>>>>> phil.hunt@oracle.com >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >> >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://www.ietf.org/mailman/listinfo/id-event > From nobody Wed Nov 4 23:28:03 2015 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 540581B3B61 for ; Wed, 4 Nov 2015 23:28:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BsqPK_CaBWCG for ; Wed, 4 Nov 2015 23:28:00 -0800 (PST) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::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 C40AE1B3B5A for ; Wed, 4 Nov 2015 23:27:59 -0800 (PST) Received: by pasz6 with SMTP id z6so82236916pas.2 for ; Wed, 04 Nov 2015 23:27:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb_com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=nDhy7uPqwNsSu4dTmQY0YTNbHxvG/SVxYGL/hEDUov0=; b=M1a5pEzsMkApBeQka/c7Ko5+8sPqNfrTrM+KnFMU1OGORLXLjOfk0fzcaKu80DNGrZ 3viy/yqAsg0S8BKDHAL+7xiLjy1yh4waQDEJT0L/42/HP7s5Wv/Q37ArmKv9uX63yZro +aZEKEiiRfGVwM796mtn3b7+06GYHEAp/loZCJZfU/VAnnF+OQDvjP9rZDO4rWBkmC/W a+aSXTx8SptdTQClRfEB1lPNgvczEEGOerHg2mqmBB3eJg+aOYi7qOtiqDTKroMfHj5m 1syiwZVeZ8aHgQs5caOFCc4KhEiNUZyssF8C4SIIl+d9bQAzgLE4MWXqrQnZa5mpj5a9 DFUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=nDhy7uPqwNsSu4dTmQY0YTNbHxvG/SVxYGL/hEDUov0=; b=X4Qhw/+6YkF6qvCk4Z5obSE7oI8kh5Qz4qceyNoLXUR2+wUpm7BErljKkFdZSLRbEA KtiELffFSeg31QdX54eBCQq/HAiT7GqAE64l1jA9/Cn7GtGq1YvfOsahLWvA8iq/gvyu t2ePW2oTyZk4Ll5tSr0+/Uzjg2p9gaIu83VITibtstfTgyk5LqkEnnMtqSJ9Ln3AN9hQ WQqOBTCVjbfouclHc818QtB4Dkc5WIvu9y8mLD6+pjR7hKCZYhlQ9Oel4xnpVgJPzuog WRYQJGqEsalsOi02Lq83Y5by1Fc/m7g5nDFMVEOI9qZCFtG7KltFt3OmNDhiOcZO+M90 o/5A== X-Gm-Message-State: ALoCoQk3YexsIO7i90BMugebZn6bQmZFbmLZ1Ek9NiySWzgij2xqOj3OvZz7Osit2ODiQOhtN5uL X-Received: by 10.68.241.65 with SMTP id wg1mr7545989pbc.101.1446708479259; Wed, 04 Nov 2015 23:27:59 -0800 (PST) Received: from t20010c4000003008e06fc7ad375cdcbe.v6.meeting.ietf94.jp (t20010c4000003008e06fc7ad375cdcbe.v6.meeting.ietf94.jp. [2001:c40:0:3008:e06f:c7ad:375c:dcbe]) by smtp.gmail.com with ESMTPSA id x15sm6035168pbt.38.2015.11.04.23.27.57 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Nov 2015 23:27:58 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: John Bradley In-Reply-To: <563B02D1.2020207@sunet.se> Date: Thu, 5 Nov 2015 16:27:57 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1FD8DEED-5526-4E7C-BD3E-8FD3DF482FAB@oracle.com> <563ABC0B.3020903@sunet.se> <0ECC7327-B2CE-45EA-B619-822646697627@oracle.com> <7F7BE7B2-0C10-4BE0-9924-29D4A7241826@oracle.com> <563AE68D.6080602@sunet.se> <563B02D1.2020207@sunet.se> To: Leif Johansson X-Mailer: Apple Mail (2.2104) Archived-At: Cc: Phil Hunt , "Morteza Ansari \(moransar\)" , "id-event@ietf.org" Subject: Re: [Id-event] Getting going some new drafts... X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 07:28:02 -0000 The difference is that the mobile client doesn=92t have a permanent web = address for the AS to send https posts to. As I understand it web-push has several methods to open a channel to the = AS that it then leaves open for the server to push messages on. I am not philosophically opposed to web push, but it will be more = resource intensive, and will require the client authenticate itself to = the AS to get the correct messages. That is a larger problem. Not impossible but larger. My question is = for SSO is there really a demand to send a push to the client to log out = the user.=20 I think web-push to apps on the device from the AS should be looked at = but we do need to decide if it is a real use-case. John B. > On Nov 5, 2015, at 4:18 PM, Leif Johansson wrote: >=20 > On 2015-11-05 08:08, Morteza Ansari (moransar) wrote: >> I think there are many cases where clients might also want to = subscribe to >> the notifications so we can=B9t rule that use case out. I don=B9t = know if >> webpush is going to be appropriate or not yet, but I think it is = worth >> thinking through the use cases and applicability of webpush for them. >=20 >=20 > My point (which I will stop wining about) is this: subscription/feeds > etc is just a REST api and what is left is a channel to each = subscriber > and how much difference is there really between a "mobile client" and > a "server". Its all HTTP. >=20 >>=20 >> On 11/4/15, 9:25 PM, "Id-event on behalf of John Bradley" >> wrote: >>=20 >>> Most of this is server to server communication. I don=B9t know = that >>> webpush adds that much for servers. If we are trying to push to = native >>> apps or browsers then I could see webpush making more sense. >>>=20 >>> John B. >>>> On Nov 5, 2015, at 2:18 PM, Leif Johansson wrote: >>>>=20 >>>> On 2015-11-05 03:27, Phil Hunt wrote: >>>>> Sorry. More importantly, webpush does not have a publish and >>>>> subscribe concept around feeds. >>>>>=20 >>>>=20 >>>> but isn't that just a management layer for a bunch of webpush = 1-1's? >>>>=20 >>>>> I did however include webpush in the notify spec to show how it = might >>>>> tie in. =20 >>>>>=20 >>>>> Phil >>>>>=20 >>>>>> On Nov 5, 2015, at 11:23, Phil Hunt wrote: >>>>>>=20 >>>>>> WebPUSH really has a completely differnt objective. They seem to >>>>>> want assured delivery for mobile. >>>>>>=20 >>>>>> They don=B9t have a subscription concept and thus have indicated = they >>>>>> will not consider cases beyond 1:1. >>>>>>=20 >>>>>> Phil >>>>>>=20 >>>>>> @independentid >>>>>> www.independentid.com >>>>>> phil.hunt@oracle.com >>>>>>=20 >>>>>>> On Nov 5, 2015, at 11:16 AM, Leif Johansson = wrote: >>>>>>>=20 >>>>>>> On 2015-11-05 03:08, Phil Hunt wrote: >>>>>>>> I propose we initially plan to write 2 individual contribution >>>>>>>> drafts: >>>>>>>>=20 >>>>>>>> * ID Event Protocol >>>>>>>> - based on a set of RESTful Publish and Subscribe and event >>>>>>>> pickup/delivery endpoints as well as defining Feeds >>>>>>>=20 >>>>>>> My standard question: where does webpush go? >>>>>>>=20 >>>>>>>> * ID Event Token >>>>>>>> - based on JWT and JOSE upon which different areas can build = domain >>>>>>>> specific events (e.g. SCIM, OIDC Logout, OAuth Token = Revocation, >>>>>>>> RISC, >>>>>>>> and so on) >>>>>>>>=20 >>>>>>>> There is a fair amount of text that can be re-used >>>>>>>> from https://tools.ietf.org/html/draft-hunt-scim-notify-00. = However >>>>>>>> the >>>>>>>> architecture described in the document will likely be = different. The >>>>>>>> publisher to hub portion isn=B9t needed, however much of the >>>>>>>> functionality >>>>>>>> described in the hub is needed (e.g. how a client registers for >>>>>>>> subscription and how a client receives events). >>>>>>>>=20 >>>>>>>> I=B9m happy to get started on the protocol stuff. Would anyone = like to >>>>>>>> volunteer on starting the Event Token spec? >>>>>>>>=20 >>>>>>>> Note: Please don=B9t stop discussing. As a writer, I don=B9t = mind >>>>>>>> adjusting >>>>>>>> as we go. In particular what do you like or hate about the = notify >>>>>>>> mechanisms for delivery? >>>>>>>>=20 >>>>>>>> Phil >>>>>>>>=20 >>>>>>>> @independentid >>>>>>>> www.independentid.com >>>>>>>> phil.hunt@oracle.com >>>>>>>>=20 >>>>>>>>=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 >>>>>>=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 >>>=20 >>> _______________________________________________ >>> Id-event mailing list >>> Id-event@ietf.org >>> https://www.ietf.org/mailman/listinfo/id-event >>=20 >=20 >=20 From nobody Wed Nov 4 23:30:18 2015 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 100191B3B64 for ; Wed, 4 Nov 2015 23:30:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DQqC61-O19Z4 for ; Wed, 4 Nov 2015 23:30:13 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC0FC1B3B67 for ; Wed, 4 Nov 2015 23:30:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=33592; q=dns/txt; s=iport; t=1446708612; x=1447918212; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=+zCvELJvR87K2EgvGngyUCLrB6Z+67LmcdS0cysYPxQ=; b=fvNtQ8dOh/kPrtCNB5LMe/zkNNbGECesafYQU7gbaNvI7bop1R7/w9tP M1UMmmxw/ayc35By7piRZRj7u2/5scjCTary1bAYOpajsAGS2EMpGfPBb O2iipbbka5yULA1QRPwEhZCF8O8hVRAHFuA05pAGKUZvbH3ey6oz8zrkU o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D/AQCWBDtW/4ENJK1egm5NU28GvWoBDYFbAxcBC4VvAoE0OBQBAQEBAQEBgQqENQEBAQQBAQFpAgIGAxACAQgOAwMBAQEXAQkBBgcnCxQJCAIEAQ0FiC4NwXgBAQEBAQEBAQEBAQEBAQEBAQEBAQEYhlSEfoRhGg0JEgGEFAWNG4VMg2EBhRyFQYJFgVpIli2DcQEfAQFChARyg1cHFwccgQcBAQE X-IronPort-AV: E=Sophos;i="5.20,246,1444694400"; d="scan'208,217";a="205444987" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 Nov 2015 07:30:11 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id tA57UBdU009542 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 5 Nov 2015 07:30:11 GMT Received: from xch-rcd-004.cisco.com (173.37.102.14) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 5 Nov 2015 01:30:10 -0600 Received: from xch-rcd-004.cisco.com ([173.37.102.14]) by XCH-RCD-004.cisco.com ([173.37.102.14]) with mapi id 15.00.1104.000; Thu, 5 Nov 2015 01:30:10 -0600 From: "Morteza Ansari (moransar)" To: William Denniss , Mike Jones Thread-Topic: [Id-event] Events and endpoints Thread-Index: AQHRFtsrqpy2w6ZCiEe93Rupxx88s56M6FaA Date: Thu, 5 Nov 2015 07:30:10 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.7.151005 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.100.29] Content-Type: multipart/alternative; boundary="_000_D26044E911655moransarciscocom_" MIME-Version: 1.0 Archived-At: Cc: John Bradley , "id-event@ietf.org" , Justin Richer Subject: Re: [Id-event] Events and endpoints X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 07:30:17 -0000 --_000_D26044E911655moransarciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Phil and I also had an offline conversation with Mike to clarify this. I to= tally agree that we don=92t want to repeat SOAP model, but as you mentioned= we shouldn=92t rule out the possibility of implementors choosing to merge = multiple notification endpoints together if it makes sense for them. From: Id-event = > on behalf of William Denniss > Date: Wednesday, November 4, 2015 at 12:30 AM To: Mike Jones > Cc: John Bradley >, "id-event@i= etf.org" >, Justin Richer > Subject: [Id-event] Events and endpoints Branching this topic, to keep the other thread clean. Mike and I had a conversation off-list, where I asked about potentially usi= ng the logout back-channel to send other events (e.g. risk signals). I was= n't trying to suggest it should be a generic messaging pipe =96 but was won= dering if it could be re-used for other messages related to the user sessio= n. I don't have a strong opinion on this. If people see more fuzzy events like= risk signals, and the explicit "logout" instructions as very different, th= en it seems wise to have different endpoints to process them. To me there'= s a bit of overlap, as some risk signals end up resulting in a "logout" ins= truction which was why I mooted this idea. Thanks for your feedback Mike! I'm also not convinced we want to have a co= mpletely generic messaging pipe as part of OAuth or OIDC, and understand th= at you want to stay well away of the SOAP/WS-* pattern! On Wed, Nov 4, 2015 at 5:09 PM, Mike Jones > wrote: Some of you have seen my remark below but I=92m resending it to get it on t= he record for those of you have not=85 I want to stay completely clear of situations in which multiple kinds of me= ssages are sent to the same endpoint and then dispatched to do different th= ings based on the message type. That is the pattern that led people to aba= ndon SOAP/WS-* for REST. I don=92t want to be part of recreating it. For instance, I only want logout message to be sent to the OpenID Connect l= ogout endpoint. It=92s appropriate for the endpoint to *validate* that the= message conforms to the specified logout message syntax and otherwise reje= ct the message. But the only action taken for messages of other types shou= ld be to drop them =96 not dispatch them. -- Mike From: Id-event [mailto:id-event-bounces@ietf.org] On Behalf Of Mike Jones Sent: Wednesday, November 04, 2015 5:05 PM To: William Denniss; Justin Richer Cc: John Bradley; id-event@ietf.org Subject: Re: [Id-event] Distinguishing different JWT types The part of this thread dealing with logout should have included a referenc= e to this text in http://openid.net/specs/openid-connect-backchannel-1_0-01= .html#LogoutToken: logout_only REQUIRED. Value declaring that this JWT is only to be used as a Logout Toke= n. In particular, this JWT cannot be used in any context where an ID Token = is used. The value of this Claim MUST be the JSON boolean value true. This claim is currently used to =93type=94 the logout token. Changing from= =93logout_only=94:true to =93jty=94: =93logout=94 or something similar wou= ld be fine. John suggested that we prohibit the inclusion of =93nonce=94 as a second wa= y of ensuring that that token couldn=92t be repurposed as an ID Token. Tha= t would work even if the code wasn=92t checking for =93logout_only=94 or = =93jty=94. -- Mike From: Id-event [mailto:id-event-bounces@ietf.org] On Behalf Of William Denn= iss Sent: Wednesday, November 04, 2015 4:54 PM To: Justin Richer Cc: John Bradley; id-event@ietf.org Subject: Re: [Id-event] Distinguishing different JWT types Fair points. My main concern is that we don't always know how people treat = ID Tokens (or JWTs more generally), and one of their nice properties is tha= t they are designed to be verifiable if transmitted over an untrusted mediu= m. I think we can build in more protection going forward by having a clear typ= e indicator. Imagine having 6 different JWT types, all potentially validati= ng as the other types. It seems dangerous if the only protection is that th= ey shouldn't be accepted outside their intended flows, and also downright c= onfusing as they all look similar. Removing fields to break potential re-use doesn't scale, and doesn't help u= nderstandability either. On Wed, Nov 4, 2015 at 4:24 PM, Justin Richer > wrote: I=92m very much in favor of having a JWT token type key, but for other reas= ons and uses. I=92m just taking issue with the assertion that a logout token could be eas= ily confused by a functioning OIDC client. Even then I think it=92s a good idea to have a =93typ": =93logout=94 tag in= it. The current guideline to take the =93nonce=94 out is a profoundly stup= id hack that=92s not likely to make much difference in the real world, or a= t least even less of a difference than a type parameter. Along those lines, I=92d suggest we use =93jtt" or =93JSON (web) Token Type= =94 as the field name, so we don=92t cause confusion with the header =93typ= =94 parameter. =97 Justin On Nov 4, 2015, at 4:06 PM, John Bradley > wrote: In principal a client gets a token two ways. 1 via a token endpoint in a direct communication. 2 via the authorization endpoint, In this case a client needs to check the = nonce value to correlate the token with the user agent that the request was= made via. I think it is fair not to have a nonce in the other tokens as they are not = requested via the browser. Nonce would also not be appropriate for a JWT a= ssertion. I would be more worried about other sorts of assertions being confused, or = at-least not easily differentiated. I don=92t think having a explicit JWT token type being a bad thing. Addin= g it would not disrupt existing clients. I think it is more a case of determining if this will be useful for other t= hings. In connect it would really only help badly coded clients who are u= nlikely to check it anyway. John B. On Nov 4, 2015, at 2:36 PM, Justin Richer > wrote: I think a real question with regard to the login/logout case is, succinctly= , =93Why is an application accepting an ID token from an unknown third-part= y as proof of login=94? In the normal OIDC process, the client will only ge= t the ID token in response to an authentication request, so it shouldn=92t = ever be just listening for incoming ID tokens. =97 Justin On Nov 4, 2015, at 2:19 PM, William Denniss > wrote: Hi Everyone, It was good talking to many of you at Yokohama earlier in the week about us= ing JWTs for event messages like Logout, Risk Signals, SCIM profile updates= and more. Thank you Phil for starting this conversation and spinning up th= e list! We're all doing related things with events, and it makes sense to c= ollaborate and unify our approaches. An issue with JWT reuse currently is that ID Tokens are defined by OpenID Connect to req= uire only a few standard JWT claims, and the required claims are highly re-usable and contain nothing t= hat actually sets them apart as an "ID Token". The risk of this is that a JWT for an event like logout can be a valid ID T= oken for login. An attacker in possession of a logout token could replay i= t against a login endpoint, and gain access. One mitigation is to change the issuer, or audience. To me this is undesira= ble as the events (e.g. logout) do relate to the same issuer and audience. = Like matter and anti-matter, yin and yang =96 logout should simply reverse = the login. It seems wasteful to spin up a new issuer, new key rotations, a= nd more just to manage each different type of event, if they would otherwis= e be related by issuer. Currently the Backchannel Logout draft attempts to "break" this utility of a logout JWT f= or authentication by prohibiting the 'nonce' field: The following Claim MUST NOT be used within the Logout Token: nonce PROHIBITED. A nonce Claim MUST NOT be present. Its use is prohibited to mak= e a Logout Token syntactically invalid if used in a forged Authentication R= esponse in place of an ID Token. I'm concerned that this may not always work as intended, as 'nonce' is not = a required field of the ID Token. ID Tokens obtained from Google using the = code flow (on our OpenID Connect certified endpoints) do not contain 'nonce= ' today, for example. And I'm a little worried that RPs may not be strictly= checking for a 'nonce', even when they should (e.g. when using the implici= t flow). Even if this approach works in this specific case, it's not scalable. So I = propose that we move to adopt a new standard claim that can be used to indi= cate the intended purpose of the JWT. 'typ' is an obvious choice for a claim name, although the word 'type' may b= e a little overloaded already. Another option could be "cat" for category. = Whatever we decide, I think such a claim should be used in all JWT specs g= oing forward, and added to OpenID Connect ID Tokens in a future revision. 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 --_000_D26044E911655moransarciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <517E6ECE6ACABE41BC6EE92DE4E929D3@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Phil and I also had an offline conversation with Mike to clarify this.= I totally agree that we don=92t want to repeat SOAP model, but as you ment= ioned we shouldn=92t rule out the possibility of implementors choosing to m= erge multiple notification endpoints together if it makes sense for them.

From: Id-event <id-event-bounces@ietf.org> on behalf of= William Denniss <wdenniss@google= .com>
Date: Wednesday, November 4, 2015 a= t 12:30 AM
To: Mike Jones <Michael.Jones@microsoft.com>
Cc: John Bradley <ve7jtb@ve7jtb.com>, "id-event@ietf.org" <id-event@ietf.org>, Justin Richer <jricher@mit.edu>
Subject: [Id-event] Events and endp= oints

Branching this topic, to keep the other thread clean.

Mike and I had a conversation off-list, where I asked about potentiall= y using the logout back-channel to send other events (e.g. risk signals).&n= bsp; I wasn't trying to suggest it should be a generic messaging pipe =96 b= ut was wondering if it could be re-used for other messages related to the user session.

I don't have a strong opinion on this. If people see more fuzzy events= like risk signals, and the explicit "logout" instructions as ver= y different, then it seems wise to have different endpoints to process them= .  To me there's a bit of overlap, as some risk signals end up resulting in a "logout" instruction which wa= s why I mooted this idea.

Thanks for your feedback Mike!  I'm also not convinced we want to= have a completely generic messaging pipe as part of OAuth or OIDC, and und= erstand that you want to stay well away of the SOAP/WS-* pattern!


On Wed, Nov 4, 2015 at 5:09 PM, Mike Jones <Michae= l.Jones@microsoft.com> wrote:

Some of you have seen my remark below but I=92= m resending it to get it on the record for those of you have not=85<= u>

 

I want to stay completely clear of situations = in which multiple kinds of messages are sent to the same endpoint and then = dispatched to do different things based on the message type.  That is the pattern that led people to abandon = SOAP/WS-* for REST.  I don=92t want to be part of recreating it.

 

For instance, I only want logout message to be= sent to the OpenID Connect logout endpoint.  It=92s appropriate for t= he endpoint to *validate* that the message conforms to the specified logout message= syntax and otherwise reject the message.  But the only action taken f= or messages of other types should be to drop them =96 not dispatch them.=

 

       &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;  -- Mike

 

From: Id-event [mailto:id-event-bounces@ietf.org] On Behalf Of Mike Jones
Sent: Wednesday, November 04, 2015 5:05 PM
To: William Denniss; Justin Richer


Cc: John Bradley; id-event@ietf.org
Subject: Re: [Id-event] Distinguishing different JWT types=

 

The part of this thread dealing with logout sh= ould have included a reference to this text in http://openid.net/specs/openid-connect-backchannel-1_0-01.html#LogoutToken<= /a>:

 

logout_only

REQUIRED. Va= lue declaring that this JWT is only to be used as a Logout Token. In partic= ular, this JWT cannot be used in any context where an ID Token is used. The value of this Claim MUST be the JSON boolea= n value true.

 

This claim is currently used to =93type=94 the= logout token.  Changing from =93logout_only=94:true to =93jty=94: =93= logout=94 or something similar would be fine.

 

John suggested that we prohibit the inclusion = of =93nonce=94 as a second way of ensuring that that token couldn=92t be re= purposed as an ID Token.  That would work even if the code wasn=92t checking for =93logout_only=94 or =93jty=94.<= /u>

 

       &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;  -- Mike

 

From: Id-event [mailto:id-event-bounces@ietf.org] On Behalf Of William Denniss
Sent: Wednesday, November 04, 2015 4:54 PM
To: Justin Richer
Cc: John Bradley; id-event@ietf.org
Subject: Re: [Id-event] Distinguishing different JWT types=

 

Fair points. My main concern is that we don't always= know how people treat ID Tokens (or JWTs more generally), and one of their= nice properties is that they are designed to be verifiable if transmitted = over an untrusted medium.

 

I think we can build in more protection going forwar= d by having a clear type indicator. Imagine having 6 different JWT types, a= ll potentially validating as the other types. It seems dangerous if the onl= y protection is that they shouldn't be accepted outside their intended flows, and also downright confusing as = they all look similar.

 

Removing fields to break potential re-use doesn't sc= ale, and doesn't help understandability either.

 

 

On Wed, Nov 4, 2015 at 4:24 PM, Justin Richer <jricher@mit.edu> = wrote:

I=92m very much in favor of having a JWT token type = key, but for other reasons and uses. 

 

I=92m just taking issue with the assertion that a lo= gout token could be easily confused by a functioning OIDC client.=

 

Even then I think it=92s a good idea to have a =93ty= p": =93logout=94 tag in it. The current guideline to take the =93nonce= =94 out is a profoundly stupid hack that=92s not likely to make much differ= ence in the real world, or at least even less of a difference than a type parameter.

 

Along those lines, I=92d suggest we use =93jtt"= or =93JSON (web) Token Type=94 as the field name, so we don=92t cause conf= usion with the header =93typ=94 parameter.

 =

 =97 Jus= tin

 

On Nov 4, 2015, at 4:06 PM, John Bradley <ve7jtb@ve7jtb.com> w= rote:

 

In principal a client gets a token two ways.  <= u>

1 via a token endpoint in a direct communication.=

2 via the authorization endpoint, In this case a cli= ent needs to check the nonce value to correlate the token with the user age= nt that the request was made via.

 

I think it is fair not to have a nonce in the other = tokens as they are not requested via the browser.  Nonce would also no= t be appropriate for a JWT assertion.

 

I would be more worried about other sorts of asserti= ons being confused, or at-least not easily differentiated. <= /u>

 

I don=92t think having a explicit JWT token type bei= ng a bad thing.   Adding it would not disrupt existing clients.  =

 

I think it is more a case of determining if this wil= l be useful for other things.   In connect it would really only help b= adly coded clients who are unlikely to check it anyway.

 

John B.

 

On Nov 4, 2015, at 2:36 PM, Justin Richer <jricher@mit.edu> wrot= e:

 

I think a real question with regard to the login/log= out case is, succinctly, =93Why is an application accepting an ID token fro= m an unknown third-party as proof of login=94? In the normal OIDC process, = the client will only get the ID token in response to an authentication request, so it shouldn=92t ever be just l= istening for incoming ID tokens.

 

 =97 Justin

 

On Nov 4, 2015, at 2:19 PM, William Denniss <wdenniss@google.com> wrote:

 

Hi Everyone,

 

It was good talking to many of you at Yokohama earli= er in the week about using JWTs for event messages like Logout, Risk Signal= s, SCIM profile updates and more. Thank you Phil for starting this conversa= tion and spinning up the list! We're all doing related things with events, and it makes sense to collaborate an= d unify our approaches.

 

An issue with JWT reuse currently is that ID Tokens = are defined by OpenID Connect to require only a few standard JWT claims, and the required claims are highly re-usable and c= ontain nothing that actually sets them apart as an "ID Token".=

 

The risk of this is that a JWT for an event like log= out can be a valid ID Token for login.  An attacker in possession of a= logout token could replay it against a login endpoint, and gain access.=

 

One mitigation is to change the issuer, or audience.= To me this is undesirable as the events (e.g. logout) do relate to the sam= e issuer and audience. Like matter and anti-matter, yin and yang =96 logout= should simply reverse the login.  It seems wasteful to spin up a new issuer, new key rotations, and more just t= o manage each different type of event, if they would otherwise be related b= y issuer.

 

Currently the Backchannel Logout draft attempts to "break" this utility of = a logout JWT for authentication by prohibiting the 'nonce' field:

The following Claim MUST NOT be used = within the Logout Token:

 

nonce=

PROHIBITED. A nonce Claim MUST NOT be present. Its use is prohibited to make a Logout Token syntactically invalid if used in = a forged Authentication Response in place of an ID Token.

 

I'm concerned that this may not always work as inten= ded, as 'nonce' is not a required field of the ID Token. ID Tokens obtained= from Google using the code flow (on our OpenID Connect certified endpoints= ) do not contain 'nonce' today, for example. And I'm a little worried that RPs may not be strictly checking fo= r a 'nonce', even when they should (e.g. when using the implicit flow).<= /u>

 

Even if this approach works in this specific case, i= t's not scalable. So I propose that we move to adopt a new standard claim t= hat can be used to indicate the intended purpose of the JWT.<= /p>

 

'typ' is an obvious choice for a claim name, althoug= h the word 'type' may be a little overloaded already. Another option could = be "cat" for category.  Whatever we decide, I think such a c= laim should be used in all JWT specs going forward, and added to OpenID Connect ID Tokens in a future revision.<= /p>

 

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

 

 

 


--_000_D26044E911655moransarciscocom_-- From nobody Wed Nov 4 23:53:31 2015 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43ED41B3BC4 for ; Wed, 4 Nov 2015 23:53:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.661 X-Spam-Level: X-Spam-Status: No, score=-1.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4KFx1HThaP_p for ; Wed, 4 Nov 2015 23:53:28 -0800 (PST) Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [IPv6:2001:6b0:8:2::201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E15C1B3BC0 for ; Wed, 4 Nov 2015 23:53:28 -0800 (PST) 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 tA57rQFs005520 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Thu, 5 Nov 2015 08:53:26 +0100 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 tA57rMrZ007772 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 5 Nov 2015 08:53:25 +0100 (CET) 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=1446710005; bh=AZvH6CAKyJDCWcxfHCNfkQdi36bOsKfdBwjcU4HZZDs=; h=Subject:To:References:From:Date:In-Reply-To; b=Y/eFYzk3W5vpeEltPNVypwKgSpnma3s7Zvb8MLcHSOJiWDQoKfqR/zt2oeHZ5Y9FW okQf/fe3AIKZc9NldUCdAnot4BaeFKmVAqcmj5cvEf15dkZ55LR24I2wWNIZGr7rCH bREAAecC/YViIGbTfvJ29ge3v7+I/uyR9yj67+n4= X-Footer: c3VuZXQuc2U= Received: from [133.93.48.79] ([133.93.48.79]) (authenticated user leifj@sunet.se) by kerio.sunet.se (Kerio Connect 8.5.2) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128 bits)) for id-event@ietf.org; Thu, 5 Nov 2015 08:53:20 +0100 To: id-event@ietf.org References: <1FD8DEED-5526-4E7C-BD3E-8FD3DF482FAB@oracle.com> <563ABC0B.3020903@sunet.se> <0ECC7327-B2CE-45EA-B619-822646697627@oracle.com> <7F7BE7B2-0C10-4BE0-9924-29D4A7241826@oracle.com> <563AE68D.6080602@sunet.se> <563B02D1.2020207@sunet.se> From: Leif Johansson Message-ID: <563B0AEB.3010208@sunet.se> Date: Thu, 5 Nov 2015 08:53:15 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, outbound-sunet-se:default, sunet-se:default, base:default, @@RPTN) X-CanIt-Geo: ip=192.36.171.210; country=SE; latitude=59.3294; longitude=18.0686; http://maps.google.com/maps?q=59.3294,18.0686&z=6 X-CanItPRO-Stream: outbound-sunet-se:outbound (inherits from outbound-sunet-se:default, sunet-se:default, base:default) X-Canit-Stats-ID: 09PBHRqqP - 5483ecfc2862 - 20151105 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] Getting going some new drafts... X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 07:53:30 -0000 On 2015-11-05 08:27, John Bradley wrote: > The difference is that the mobile client doesn’t have a permanent web address for the AS to send https posts to. > point From nobody Sat Nov 7 07:59:53 2015 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91B431A9029 for ; Sat, 7 Nov 2015 07:59:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aXUsfD6LZ-SX for ; Sat, 7 Nov 2015 07:59:50 -0800 (PST) Received: from secure.think-privacy.com (secure.think-privacy.com [85.10.202.54]) by ietfa.amsl.com (Postfix) with ESMTP id 005411A9028 for ; Sat, 7 Nov 2015 07:59:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by secure.think-privacy.com (Postfix) with ESMTP id 9977611408C6 for ; Sat, 7 Nov 2015 16:59:48 +0100 (CET) Received: from secure.think-privacy.com ([127.0.0.1]) by localhost (secure.think-privacy.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BxUtzE9Erg3r for ; Sat, 7 Nov 2015 16:59:48 +0100 (CET) Received: from [192.168.1.2] (host-84-13-46-165.opaltelecom.net [84.13.46.165]) by secure.think-privacy.com (Postfix) with ESMTPSA id 4F009114044F for ; Sat, 7 Nov 2015 16:59:45 +0100 (CET) From: Mark Lizar Content-Type: multipart/signed; boundary="Apple-Mail=_F5B28C12-1E7C-40D6-B39B-D3724F886B8B"; protocol="application/pkcs7-signature"; micalg=sha1 Message-Id: Date: Sat, 7 Nov 2015 15:58:57 +0000 To: id-event@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\)) X-Mailer: Apple Mail (2.3094) Archived-At: Subject: [Id-event] "Events Data" X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Nov 2015 15:59:51 -0000 --Apple-Mail=_F5B28C12-1E7C-40D6-B39B-D3724F886B8B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 This might be of some interest.=20 s193 of the new UK surveillance bill this is something that I found out = which is the introductions into legislation of the notions of =E2=80=9Cen= tity data=E2=80=9D and =E2=80=9Cevents data=E2=80=9D. =E2=80=9CEvents = data=E2=80=9D, broadly, relates to a specific event on a = telecommunications system, and =E2=80=9Centity data=E2=80=9D describes a = person or thing, or an association between that person or thing and a = telecommunications service or system. s193(5)(c) also introduces a = concept of =E2=80=9Carchitecture of a communications system=E2=80=9D, a = notion which is not within the current scope of RIPA, and which = presumably relates to information about, for example, cell tower = location and active element configuration =E2=80=94 information to which = there is no specific access power by authorities.=20 So, it would seem that the term =E2=80=9CEvent=E2=80=9D is appearing in = the legal language as well.=20 - Mark=20 --Apple-Mail=_F5B28C12-1E7C-40D6-B39B-D3724F886B8B Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKBjCCBK8w ggOXoAMCAQICEQDgI8sVEoNTia1hbnpUZ2shMA0GCSqGSIb3DQEBCwUAMG8xCzAJBgNVBAYTAlNF MRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5l dHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMTQxMjIyMDAwMDAw WhcNMjAwNTMwMTA0ODM4WjCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAibEN2npTGU5wUh28VqYGJre4SeCW 51Gr8fBaE0kVo7SMG2C8elFCp3mMpCLfF2FOkdV2IwoU00oCf7YdCYBupQQ92bq7Fv6hh6kuQ1JD FnyvMlDIpk9a6QjYz5MlnHuI6DBk5qT4VoD9KiQUMxeZrETlaYujRgZLwjPU6UCfBrCxrJNAubUI kzqcKlOjENs9IGE8VQOO2U52JQIhKfqjfHF2T+7hX4Hp+1SA28N7NVK3hN4iPSwwLTF/Wb1SN7Az aS1D6/rWpfGXd2dRjNnuJ+u8pQc4doykqTj/34z1A6xJvsr3c5k6DzKrnJU6Ez0ORjpXdGFQvsZA P8vk4p+iIQIDAQABo4IBFzCCARMwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD VR0OBBYEFJJha4LhoqCqT+xn8cKj97SAAMHsMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAG AQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAw RAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJu YWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNl cnRydXN0LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAGypurFXBOquIxdjtzVXzqmthK8AJECOZD8Vm am+x9bS1d14PAmEA330F/hKzpICAAPz7HVtqcgIKQbwFusFY1SbC6tVNhPv+gpjPWBvjImOcUvi7 BTarfVil3qs7Y+Xa1XPv7OD7e+Kj//BCI5zKto1NPuRLGAOyqC3U2LtCS5BphRDbpjc06HvgARCl nMo6x59PiDRuimXQGoq7qdzKyjbR9PzCZCk1r9axp3ER0gNDsY8+muyeMlP0dpLKhjQHuSzK5hxK 2JkNwYbikJL7WkJqIyEQ6WXH9dW7fuqMhSACYurROgcsWcWZM/I4ieW26RZ6H3kU9koQGib6fIr7 mzCCBU8wggQ3oAMCAQICEBQNtoHcXYhFjdHZtIQDZl8wDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNTA2MDkwMDAwMDBaFw0xNjA2 MDgyMzU5NTlaMC0xKzApBgkqhkiG9w0BCQEWHG0ubGl6YXJAb3BlbmNvbnNlbnRncm91cC5jb20w ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDoM+TQc085/rTddj2h/cwqO01sP5pGLRMt /P6ei7pO6xPs4iKG0g1aqKJ3ImR+vJ3ng5hvB0D74IsidLjOiEUwKbUNIKd5rWEVJ2jUrHDBOouF OQtyXY3LdHQfDU0hSmeaCx4uA2Dqtv2IQDrZuVMZRbpAeJ05avtRbwcqH44EG7zI+xdDEo3ocOar 96MfZzapWJJOUjVGle479ysyltfpS5sSOK1LaZVGc5WlHmXl4WNlzWTrNhlfwPJaw9CDI0zDf0fI ooTZI9T3gdVdKq1dTY4ajWyUZrFvRnp2uNihTctVGNESsvhzUDh0v1z1wt6Sj92lGwD8gy+yAVAp +y33AgMBAAGjggH6MIIB9jAfBgNVHSMEGDAWgBSSYWuC4aKgqk/sZ/HCo/e0gADB7DAdBgNVHQ4E FgQUHqQm//C/LQDwmvzKsYY3MVLouzcwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYD VR0lBBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAE PzA9MDsGDCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8u bmV0L0NQUzBdBgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9T SEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGQBggrBgEFBQcB AQSBgzCBgDBYBggrBgEFBQcwAoZMaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2 Q2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0 cDovL29jc3AuY29tb2RvY2EuY29tMCcGA1UdEQQgMB6BHG0ubGl6YXJAb3BlbmNvbnNlbnRncm91 cC5jb20wDQYJKoZIhvcNAQELBQADggEBAGnxbOn0WI+7c6/hl0zozi80YiXe/CThJmzXhDwH25Co mq+MKSnxSM6mjFzwkS8L5hTueeKsaMgGqVz5/XQDvZQjNdNApCIyG7lfdfjbiTje4iUa7ZzYdbSO bKgpkiPo6VpnttWNlqhPaIAXLsnfExSupXNuDLU/pl8Ci4ajKx0ZJt4k6vo/6hsc/X+Ow3m9QqdY fpUk7UlRH7PrWN7OmX89KPpdDLvV962geX7veqUcTi3DnDR1/8I0o6Rb5QdmTKUL/5TXuiEvo5MJ QR/MOoFm9GAK8+q6M9QHKf/EloP1NpOAYs0DiFrb3J77qc5Kw8FAcoy8/bcwak4kQ0hedfkxggPD MIIDvwIBATCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQ MA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENP TU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAU DbaB3F2IRY3R2bSEA2ZfMAkGBSsOAwIaBQCgggHnMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTE1MTEwNzE1NTg1OFowIwYJKoZIhvcNAQkEMRYEFLEu7kyA522yFap/ sq5bNNH7tKJ+MIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBM aW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5k IFNlY3VyZSBFbWFpbCBDQQIQFA22gdxdiEWN0dm0hANmXzCBwwYLKoZIhvcNAQkQAgsxgbOggbAw gZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1Nh bGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1 NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQFA22gdxdiEWN0dm0 hANmXzANBgkqhkiG9w0BAQEFAASCAQDQPJEwUe6kqp6KcZWmpgzc0blNHve4PBRLUESQa/tyc8KU d3EsrWVJjDRZ5rRzaoYb1yp+rhVdZ4gSbrtAlwyFUjbW07cKOuzwJAbBNO/9SSDrKufUxVAh3TAw 80eui7sM5qmYY3pV5/urWiYgIM4hMUcjJzBC3RK7bsyXnqCYeerCx/+HpfQabTpP01IZ9MA2w/9V ljiMYhkwWtDnkaqFo5WE9qlajUsF4YA1tRzOmy0I5305GAuMhUCMngCYQrLowsu+1+UY7d5E4rOi 8inBcpaRsQ7T1Hd9z8YMzhkP/XNsovwwya10dvM6Pjj67/NXN3bMmcbC2XjABTMn2J5aAAAAAAAA --Apple-Mail=_F5B28C12-1E7C-40D6-B39B-D3724F886B8B-- From nobody Tue Nov 24 13:39:35 2015 Return-Path: X-Original-To: id-event@ietf.org Delivered-To: id-event@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BA351A8AE9; Tue, 24 Nov 2015 13:36:37 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: "IETF Announcement List" X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151124213637.18211.47210.idtracker@ietfa.amsl.com> Date: Tue, 24 Nov 2015 13:36:37 -0800 Archived-At: X-Mailman-Approved-At: Tue, 24 Nov 2015 13:39:33 -0800 Cc: id-event@ietf.org, phil.hunt@oracle.com Subject: [Id-event] Id-event -- A mailing list to discuss the potential solution for a common identity event messaging format and distribution system. X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org 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, 24 Nov 2015 21:36:37 -0000 A new IETF non-working group email list has been created. List address: id-event@ietf.org Archive: https://mailarchive.ietf.org/arch/search/?email_list=id-event To subscribe: https://www.ietf.org/mailman/listinfo/id-event Purpose: The Id-Event discussion list is intended to begin discussion around developing new IDs (and potentially form a WG) for the purpose of defining a JWT message format for Identity Events and to define a possible approach for distribution. The list was formed after several participants noticed common event requirements that have emerged from SCIM provisioning, OIDC (eg. Logout), RISC Events (e.g. account suspension, reset, take-over), as well as OAuth2 (e.g. token revocations), and consent notification (e.g. consent from a distributes OAuth/UMA system). For additional information, please contact the list administrators. From nobody Tue Nov 24 13:43:29 2015 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A82A51A8F40 for ; Tue, 24 Nov 2015 13:43:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.785 X-Spam-Level: X-Spam-Status: No, score=-4.785 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id blV3tR5EdunY for ; Tue, 24 Nov 2015 13:43:27 -0800 (PST) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECC251A8F46 for ; Tue, 24 Nov 2015 13:43:26 -0800 (PST) X-AuditID: 1209190f-f79d06d000004b20-5e-5654d9fdb58b 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 dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id B5.36.19232.DF9D4565; Tue, 24 Nov 2015 16:43:25 -0500 (EST) 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 tAOLhOgs025526 for ; Tue, 24 Nov 2015 16:43:25 -0500 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 tAOLhNIq001726 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 24 Nov 2015 16:43:24 -0500 From: Justin Richer Content-Type: multipart/alternative; boundary="Apple-Mail=_01D4E0AC-5661-4270-8AC0-EFA414E29BE9" Message-Id: <845D43B0-FADC-43C4-9BFE-41C33EC6807D@mit.edu> Date: Tue, 24 Nov 2015 16:43:22 -0500 To: id-event@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMIsWRmVeSWpSXmKPExsUixCmqrPv3ZkiYwcNj8hYdC7qZHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVsfLFZ8aCVfwV19vmMDcwTuftYuTkkBAwkVgx+w8rhC0mceHe erYuRi4OIYHFTBLX985mhnBOMkq8O/2HBcL5ySTR8H4aO0gLm4CqxPyVt5hAbGaBBImdXbfA 4sICShI/5y0Bs3kFrCTuN29jAbFZgOrntd8Ei4sIiErsm7iaFaJGT+LVrctQZ8hK7P79iGkC I+8sJGNnISmDiGtLLFv4mhnC1pTY372cBVNcQ6Lz20TWBYxsqxhlU3KrdHMTM3OKU5N1i5MT 8/JSi3RN9HIzS/RSU0o3MYLDUpJ/B+O3g0qHGAU4GJV4eGcUBYcJsSaWFVfmHmKU5GBSEuX9 eC0kTIgvKT+lMiOxOCO+qDQntfgQowQHs5IIr9FWoBxvSmJlVWpRPkxKmoNFSZx37hffMCGB 9MSS1OzU1ILUIpisDAeHkgSvxg2gRsGi1PTUirTMnBKENBMHJ8hwHqDhOiA1vMUFibnFmekQ +VOMilLivD0gCQGQREZpHlwvKG0kvD1s+opRHOgVYd5qkCoeYMqB634FNJgJaPCRkkCQwSWJ CCmpBkbXLX+b94hcyXtzZ9vWfJ7Xm/Z4SgkHGPaWm6xftKagb5n74qPNbJWH4hznX057JMR7 dUVul7rFmiBb0Va3+9xsP12FJ30yZNfn2V6wSLHSOjdup3dfsPDf66vjC8su3WSRMk9Z7vGt s8lJwUmkdrKT5ynVecWnlbp2sL/4tjbLVixj+r3+CUosxRmJhlrMRcWJAP0iu8T2AgAA Archived-At: Subject: [Id-event] Consent Receipt Demo Site X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2015 21:43:28 -0000 --Apple-Mail=_01D4E0AC-5661-4270-8AC0-EFA414E29BE9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 To give you a rough idea of one version of the Consent Receipt concept = from the Kantara working groups, this is a site that Sarah Squire and I = put together earlier this year. It=E2=80=99s a simple form that shows = the parts that go into a receipt and lets you download the receipt = itself. http://api.consentreceipt.org/ The consent receipt working group is continuing to work on both the = specification and the demonstration site, but this relatively simple = demo can show some of the concepts. =E2=80=94 Justin --Apple-Mail=_01D4E0AC-5661-4270-8AC0-EFA414E29BE9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 To give you a rough idea of one version of the Consent = Receipt concept from the Kantara working groups, this is a site that = Sarah Squire and I put together earlier this year. It=E2=80=99s a simple = form that shows the parts that go into a receipt and lets you download = the receipt itself.

http://api.consentreceipt.org/

The consent receipt working group is = continuing to work on both the specification and the demonstration site, = but this relatively simple demo can show some of the concepts.

 =E2=80=94 = Justin

= --Apple-Mail=_01D4E0AC-5661-4270-8AC0-EFA414E29BE9--