From nobody Mon Apr 3 04:52:34 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38C761250B8 for ; Mon, 3 Apr 2017 04:52:33 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SUYkXzlXLgkA for ; Mon, 3 Apr 2017 04:52:30 -0700 (PDT) Received: from mail-pg0-x236.google.com (mail-pg0-x236.google.com [IPv6:2607:f8b0:400e:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B937127B57 for ; Mon, 3 Apr 2017 04:52:30 -0700 (PDT) Received: by mail-pg0-x236.google.com with SMTP id 81so118313532pgh.2 for ; Mon, 03 Apr 2017 04:52:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=SSLaJpgoLknT0TJ4bRsTGFPmMzXQizwxA1aKO8iEfVw=; b=JpsnhCy5CXKZN2M8KcTv0eZUJWaVIpm6SQh0n1KzjOWxyv8LRfCOJFOMfJmbTak2wX ftR0Abobf24RyQucNbS0nsE91i8qTD5lPsahrNq3aj33AtML04bOcHSOuSO34gBgORZB tZ0eaVljbtwXdVO24iBtEkKGGOETDQL5AQMXY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=SSLaJpgoLknT0TJ4bRsTGFPmMzXQizwxA1aKO8iEfVw=; b=FHh74kCzTS0Bg+l/SGAz0Cvw+MDvA64NpB6lrF00tSE7ZYycxInznOmATtysFw2D8b uloTfJYwP/3iVPcHOoItKOU3jFVPmhnF5CCiyiF/EFakWZxJmwZEji/E3th/+7PANAZG iZzFEwk9+UqHdHKUPAt7CEli7IY1jFEhCGihDOuGuu81I01UKjnUfeQwqGVWJad/gL+i 6ouN4zDU+gOBqsTVKwdWPT7NlIIb77Pfh8/7nzVfWxyq38yPlQgPYJB5xm0Vftiiwbhc pbmUg7KTrNuhtNWwdNuXJaA5chjNnShWNkOAI7PsC1xQXuFFxXslhGa4FL6yG6U2zDgi o03w== X-Gm-Message-State: AFeK/H2ojIIlCSZ8ZNWRYBOUI707Yi/DHO1agdjSpCf/hoQ9grujW8Mitw8ZKSQA6WnaPGb9RpMAPWRUtwD3e+vs X-Received: by 10.84.232.131 with SMTP id i3mr21286803plk.172.1491220349743; Mon, 03 Apr 2017 04:52:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.165.172 with HTTP; Mon, 3 Apr 2017 04:51:59 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Mon, 3 Apr 2017 05:51:59 -0600 Message-ID: To: oauth Content-Type: multipart/alternative; boundary=f40304361d103a91f0054c41cb0a Archived-At: Subject: [OAUTH-WG] Fwd: Token Binding Demo Online X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 11:52:33 -0000 --f40304361d103a91f0054c41cb0a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Below is the Token Binding demo that I mentioned and said I share on the list during the Friday meeting in Chicago. ---------- Forwarded message ---------- From: Brian Campbell Date: Fri, Mar 24, 2017 at 3:11 PM Subject: Token Binding Demo Online To: IETF Tokbind WG I put up a demonstration of some token binding functionality that I wanted to share. There are a few parts to it, which I'll attempt to describe below. At https://unbearable-bc.ping-eng.com:3000/open/ is a token binding capable reverse proxy (of sorts) that is proxying requests to http://httpbin.org/ with a little path rewriting. If you go to https://unbearable-bc.ping- eng.com:3000/open/headers with a token binding (-10 to -13) capable browser, for example, you should see the a dump of the request headers including "Sec-Token-Binding". The reverse proxy is also set up with some access control and will proxy from https://unbearable-bc.ping-eng.com:3000/ to http://httpbin.org/ but require an authenticated session to do so. And it's using OpenID Connect Token Bound Authentication with an IDP at https://token-provider-bc.ping-eng.com:9031 to authenticate users. So, for example, if you go to https://unbearable-bc.ping- eng.com:3000/headers without a session you will be redirected to the authorization endpoint at that IDP and presented with a login page. Use USERNAME: brian and PASSWORD: Test5555 on that page. After login, you'll be sent back to the relying party via the Form Post Response Mode where the ID Token is sent though the browser. If you grab that token and decode it, there should be a confirmation method claim that has the hash of the Token Binding ID used with the relying party (i.e. "cnf": {"tbh": "...hash..."}). The relying party sets up its own session from the OIDC SSO, which is a cookie named PA.unbearable that is a JWT. The page at https://unbearable-bc.ping-eng.com:3000/headers will dump the headers including that cookie. If you decode that JWT, you should also see that the local session is token bound with the confirmation method claim. Things will still work when using a non token binding capable browser but none of the tokens will be token bound. As a reminder, you can enable Token Binding in Chrome by putting chrome://flags/#enable-token-binding into the address bar. Chrome and Chrom= e Canary=E2=80=8E are what I've been using to play with this. I'm hopping som= eone with the TB enabled Edge/IE can poke around on this demo too. --f40304361d103a91f0054c41cb0a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Below is the Token Binding demo that I mentioned and said = I share on the list during the Friday meeting in Chicago.

---------- Forwarded message ----------From: Brian Campbell &= lt;bcampbell@pingidentity.com= >
Date: Fri, Mar 24, 2017 at 3:11 PM
Subject: Token Bin= ding Demo Online
To: IETF Tokbind WG <unbearable@ietf.org>


I put = up a demonstration of some token binding functionality that I wanted to sha= re. There are a few parts to it, which I'll attempt to describe below. =

At https://unbearable-bc.ping-eng.com:3000/open/ is a token binding capable reverse proxy (of sorts) that is proxying req= uests to http://httpbin.o= rg/ with a little path rewriting. If you go to https://unbearab= le-bc.ping-eng.com:3000/open/headers with a token binding (-10 to = -13) capable browser, for example, you should see the a dump of the request= headers including "Sec-Token-Binding".

The re= verse proxy is also set up with some access control and will proxy from https:/= /unbearable-bc.ping-eng.com:3000/ to http://httpbin.org/ but require an authenticated s= ession to do so. And it's using OpenID Co= nnect Token Bound Authentication with an IDP at https://token-provider-b= c.ping-eng.com:9031 to authenticate users.

So, = for example, if you go to https://unbearable-bc.ping-eng.com:3000/h= eaders without a session you will be redirected to the authorization en= dpoint at that IDP and presented with a login page.=20 Use USERNAME: brian and PASSWORD: Test5555 on that page. After login, you&#= 39;ll be sent back to the relying party via the Form = Post Response Mode where the ID Token is sent though the browser. If yo= u grab that token and decode it, there should be a confirmation method clai= m that has the hash of the Token Binding ID used with the relying party (i.= e. "cnf": {"tbh": "...hash..."}).

The relying party sets up its own session from the OIDC SSO, which i= s a cookie named PA.unbearable that is a JWT. The page at https://unbear= able-bc.ping-eng.com:3000/headers will dump the headers including = that cookie. If you decode that JWT, you should also see that the local ses= sion is token bound with the confirmation method claim.

T= hings will still work when using a non token binding capable browser but no= ne of the tokens will be token bound.

As a re= minder, you can enable= Token Binding in Chrome by putting chrome://flags/#enable-token-binding into the address ba= r. Chrome and Chrome Canary=E2=80=8E are what I've been using to play= with this. I'm hopping someone with the TB enabled Edge/IE can poke ar= ound on this demo too.







--f40304361d103a91f0054c41cb0a-- From nobody Mon Apr 3 11:37:34 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A77E31294D8 for ; Mon, 3 Apr 2017 11:37:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id obh0_44BeIjT for ; Mon, 3 Apr 2017 11:37:31 -0700 (PDT) Received: from mail-pg0-x231.google.com (mail-pg0-x231.google.com [IPv6:2607:f8b0:400e:c05::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 95F361294D4 for ; Mon, 3 Apr 2017 11:37:30 -0700 (PDT) Received: by mail-pg0-x231.google.com with SMTP id g2so126867388pge.3 for ; Mon, 03 Apr 2017 11:37:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tx4pTSmiCVevros58vsLYLmf021w5abF8aEiCYDkCOU=; b=d8pxKcFkkuqv8trfOusPe0AxDMegiE9xivtC4VOLnqTA1vKA/HzHqK8+9bayq0p5UF Vkv9FKLuyLUfM93cIjOobXJJ3QIXzwUVowMnV8g2dIjk9HhY4wT1erhA7CUUh4JaXH+1 LQBQ/GTVgfGtCbZI3VipbKR7EV5tnXwuTH1qE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tx4pTSmiCVevros58vsLYLmf021w5abF8aEiCYDkCOU=; b=cZp0NK/YG2aVppe3jUyvwPMi+bJSx6h+ujDZBavX8QY5yO+XtV0Swg9qkqe6SwbCPF fhV3I/wSM/ytr+GQX1Nr/9+E8RAdvBdiU+1OqTyDwCmkdLER/FG72vCpGbc0vktLAInF 8jeMwtB8kHwQlmucb1oDgneTS54ZbOsX699UBiO/V7eUVmfcC1wXFglW5qGDjQKcWRSN Og7uZVNdFPX2kpfWbJwgSZRnA4dQIrvUxIugg+ik8ZxEMl4pTiIPkHjgNiO87BAZueCp 5k7e3WT4ND1oze7Qd3pKNwFoTxo9K4svSIsECGu6hILiUcQfzqlr6kl/h0cFPjKrkoBk 5kFA== X-Gm-Message-State: AFeK/H37gO9HiVR4YDc1USf0ofb3dI8L6LK1vYLxBnEp8PtytPv8JdsdWSinRkkdUHKrly3W7fizPS3q3f11cEnL X-Received: by 10.84.217.142 with SMTP id p14mr23423143pli.164.1491244650111; Mon, 03 Apr 2017 11:37:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.165.172 with HTTP; Mon, 3 Apr 2017 11:36:59 -0700 (PDT) In-Reply-To: References: <149090694651.9027.6337833834024757190.idtracker@ietfa.amsl.com> From: Brian Campbell Date: Mon, 3 Apr 2017 12:36:59 -0600 Message-ID: To: Dave Tonge Cc: oauth Content-Type: multipart/alternative; boundary=f403045c7934a4bb8a054c47739c Archived-At: Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-mtls-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 18:37:34 -0000 --f403045c7934a4bb8a054c47739c Content-Type: text/plain; charset=UTF-8 Hi Dave, Thanks for the review, support, and feedback. I've already removed the extraneous "can" in the source. The easy part... I did struggle with terminology for many of the reasons you point out about there being somewhat established terms that aren't quite the same as those defined in the RFC. And apparently I wasn't terribly consistent with the terminology I did use. I think the phrasing you suggest is pretty good and yes possibly more clear. I'd happily take a pull request with such changes. Thank you. The XML source of the document currently in a bitbucket git repo at https://bitbucket.org/b_c/internet-drafts/src/master/draft-campbell-oauth-mtls.xml?at=master&fileviewer=file-view-default Thanks, Brian On Fri, Mar 31, 2017 at 10:07 AM, Dave Tonge wrote: > Hi Brian > > Thanks for this - it will be very useful for open banking in Europe where > cert based auth is required by law. > > I have a few suggestions around wording. > Happy to submit these via pull request if it's helpful. > > 1. Typo - remove can from 1: > > Mutual TLS sender constrained access tokens and mutual TLS client > authentication are distinct mechanisms that *can* don't necessarily > need to be deployed together. > > > 2. Consistency of terminology in 2 (and throughout the document). > In section 2 the following phrases are used: > > - Mutual TLS for Client Authentication > - Mutual TLS Client Authentication to the Token Endpoint > - mutual TLS as client credentials > - mutual X.509 certificate authentication > > Interestingly RFC5246 does not refer to "mutual authentication" at all, > but does refer to "client authentication". > From an OAuth perspective, surely we are more interested in the fact that > it is TLS client auth - than the fact that it is mutual. However referring > to TLS Client Authentication would bring confusion as we would have two > client definitions in play: the TLS Client and the OAuth Client > > "TLS Mutual Auth" and "Mutual TLS" are established phrases in the industry > - even though they don't seem to be defined in any of the relevant specs, > however, "Mutual TLS Client Auth" isn't. > > I'm not sure of the best solution for this, but would be interested as to > whether the authors considered this phrasing to be clearer? > > - Mutual TLS for Client Authentication > -> TLS Mutual Auth for Client Authentication > > - Mutual TLS Client Authentication to the Token Endpoint > -> TLS Mutual Auth for Client Authentication to the Token Endpoint > > - mutual TLS as client credentials > -> TLS X509 client certificate as client credentials > > Or alternatively, a definition of "Mutual TLS" could be provided earlier > on in the document. > > Thanks again for your work on this spec. > > Dave Tonge > > > --f403045c7934a4bb8a054c47739c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Dave,

Thanks for the r= eview, support, and feedback.

I've already removed the extraneo= us "can" in the source. The easy part...

I did strug= gle with terminology for many of the reasons you point out about there bein= g somewhat established terms that aren't quite the same as those define= d in the RFC.=C2=A0 And apparently I wasn't terribly consistent with th= e terminology I did use.

I think the phrasing you suggest is = pretty good and yes possibly more clear. I'd happily take a pull reques= t with such changes. Thank you.

The XML source of the document= currently in a bitbucket git repo at https://bitbucket.org/b_c/internet-drafts/src= /master/draft-campbell-oauth-mtls.xml?at=3Dmaster&fileviewer=3Dfile-vie= w-default=C2=A0

Thanks,
Brian
=C2=A0

On Fri, Mar 31, 2017 at 10:07 AM, Dave Tonge <d= ave.tonge@momentumft.co.uk> wrote:
Hi Brian

Thanks for this - it will be very useful for open banking in Euro= pe where cert based auth is required by law.

I have a few suggestions around wording.
Happy to= submit these via pull request if it's helpful.

1. Typo - remove can from 1:
 
Mutual TLS sender constrained access tokens and =
mutual TLS client
authentication are distinct mechanisms that can don't necessaril=
y
need to be deployed together.

In section 2 the following phrases are used:
  • Mutual TLS fo= r Client Authentication
  • Mutual TLS Client Authentication to the Token Endpoint
  • mutual TLS as client credent= ials
  • mutual X.509 ce= rtificate authentication
Interestingl= y RFC5246 does not refer to "mutual authentication" at all, but d= oes refer to "client authentication".
From an OA= uth perspective, surely we are more interested in the fact that it is TLS c= lient auth - than the fact that it is mutual. However referring to TLS Clie= nt Authentication would bring confusion as we would have two client definit= ions in play: the TLS Client and the OAuth Client

"TLS Mutual Auth" and "Mutual TLS" are es= tablished phrases in the industry - even though they don't seem to be d= efined in any of the relevant specs, however, "Mutual TLS Client Auth&= quot; isn't.

I'm not sure of= the best solution for this, but would be interested as to whether the auth= ors considered this phrasing to be clearer?
  • Mutual TLS for Client Auth= entication
    -> TLS Mutual Auth for Client Authe= ntication

  • = Mutual TLS Client Authentication to the Token Endpoint
    -> TLS Mutual Auth for Client Authentication to the Token Endpoint=

  • mutual TL= S as client credentials
    -> TLS X509 client cer= tificate as client credentials
Or alternatively, a defin= ition of "Mutual TLS" could be provided earlier on in the documen= t.

Thanks again for your work on this sp= ec.
<= font face=3D"trebuchet ms, sans-serif">

Dave Tonge



--f403045c7934a4bb8a054c47739c-- From nobody Mon Apr 3 16:57:03 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F1D51292FD for ; Mon, 3 Apr 2017 16:57:01 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y1ulCln2zvEG for ; Mon, 3 Apr 2017 16:56:59 -0700 (PDT) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::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 249A2126B7F for ; Mon, 3 Apr 2017 16:56:59 -0700 (PDT) Received: by mail-qt0-x22e.google.com with SMTP id x35so126187918qtc.2 for ; Mon, 03 Apr 2017 16:56:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=U1RJJKXVUW+3h7geAtQdyRyWZ4702IEBh1OZ8IG+xn4=; b=fz8gCzT3Kn/GYPUQPKrtXmGfzVYAO86aBRsqJI32ZKcDhCuDil1CqeWlyFmGrqBzQQ rokCfCpSigR74UoGfRNa8xFJV3w3X4+PHibvmP7xSTMq5gHIV84rJdB16GTAt1/x535J ZSCElvveIWO2j24jeKz71xVRmkKzngu/VXEXFXg/SHSh1mQ+j5u4Ak/+ps8SVsKHYvIC dYlNj2Mq7KIroZNJuB2DpX/95LziUHCGHj+LHpqxfffjaAmG61FQzCEGcDwOxkXwlnfh TecAtPwDrkKPypXdDtJYsfVhKLbX0t/8iz2TxcaLDIRbQoMluMl+cTx1gPh2/dIEZ3C2 FuDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=U1RJJKXVUW+3h7geAtQdyRyWZ4702IEBh1OZ8IG+xn4=; b=uhgaX5kOZzBki5V4Qf+jUzWR51aSllwC81xqehlznOkUKA9AIsjIjFjzS4TK1p6DeJ rHCjjuUkUX1yURSKoBS+WKwhRGVGVmOPzDJYlXszjQ0FM3RqDrFFnIN9fl+y15HQViyl VVO5MxiSrqSMuKC9wcRv4vgczR5DKnYSfqSvQrtb91kKjyQDbF7UdxyI8x/JGUANivT7 xz5pwGwQ/YzT5gw2kbtXQr/wilgC21+Ze42QNg5f6lktFdJOCGSg0tG9lUkl9AePGx39 AFlwdwsYoo+WanCCSHyjkYCCg34KgG27xcBvHpDJEUZbAgVQ7ml3fucN1yPYEOONmXw+ hWjA== X-Gm-Message-State: AFeK/H060pApoAhL3h1aTgw1O68OTONi2NBCuPjDnSnobII6o9hWPyVQzEz7LZS8pp0ut88Zq6aczgqXBASB5A== X-Received: by 10.200.1.6 with SMTP id e6mr19459842qtg.21.1491263818086; Mon, 03 Apr 2017 16:56:58 -0700 (PDT) MIME-Version: 1.0 References: <4602a58b-58c1-d41e-26cb-025eec8a6d8b@gmx.net> <4935886D-8E92-45AB-9EF8-BDA4E38C86A9@ve7jtb.com> In-Reply-To: From: Nat Sakimura Date: Mon, 03 Apr 2017 23:56:47 +0000 Message-ID: To: Mike Jones , John Bradley , Hannes Tschofenig Cc: "oauth@ietf.org" Content-Type: multipart/alternative; boundary=f403045f39ec254ed1054c4bea93 Archived-At: Subject: Re: [OAUTH-WG] OAuth 2.0 Authorization Server Metadata: IPR Confirmation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 23:57:01 -0000 --f403045f39ec254ed1054c4bea93 Content-Type: text/plain; charset=UTF-8 I am not aware of any IPR encumbrances for this spec. On Wed, Mar 8, 2017 at 3:05 AM Mike Jones wrote: > I am aware of no IPR encumbrances for this specification. > > -----Original Message----- > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of John Bradley > Sent: Tuesday, March 7, 2017 10:02 AM > To: Hannes Tschofenig > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] OAuth 2.0 Authorization Server Metadata: IPR > Confirmation > > I have no IPR disclosures to make. > > John B. > > On Mar 7, 2017, at 2:50 PM, Hannes Tschofenig > wrote: > > > > Hi John, Mike, Nat, > > > > I am working on the shepherd writeup for the "OAuth 2.0 Authorization > > Server Metadata" document: > > https://tools.ietf.org/html/draft-ietf-oauth-discovery-05 > > > > One item in the template requires me to indicate whether each document > > author has confirmed that any and all appropriate IPR disclosures > > required for full conformance with the provisions of BCP 78 and BCP 79 > > have already been filed. > > > > Could you please confirm? > > > > Ciao > > Hannes > > > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- Nat Sakimura Chairman of the Board, OpenID Foundation --f403045f39ec254ed1054c4bea93 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I am not aware of any IPR encumbrances for this spec.=C2= =A0

On Wed, Mar 8, 201= 7 at 3:05 AM Mike Jones <= Michael.Jones@microsoft.com> wrote:
I am aware of no IPR encumbrances for this specification.

-----Original Message-----
From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of John Brad= ley
Sent: Tuesday, March 7, 2017 10:02 AM
To: Hannes Tschofenig <hannes.tschofenig@gmx.net>
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth 2.0 Authorization Server Metadata: IPR Confir= mation

I have no IPR disclosures to make.

John B.
> On Mar 7, 2017, at 2:50 PM, Hannes Tschofenig <hannes.tscho= fenig@gmx.net> wrote:
>
> Hi John, Mike, Nat,
>
> I am working on the shepherd writeup for the "OAuth 2.0 Authoriza= tion
> Server Metadata" document:
> https://tools.ietf= .org/html/draft-ietf-oauth-discovery-05
>
> One item in the template requires me to indicate whether each document=
> author has confirmed that any and all appropriate IPR disclosures
> required for full conformance with the provisions of BCP 78 and BCP 79=
> have already been filed.
>
> Could you please confirm?
>
> Ciao
> Hannes
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/lis= tinfo/oauth

_______________________________________________
OAuth mailing list
OAu= th@ietf.org
https://www.ietf.org/mailman/listinfo= /oauth
--

Nat Sakimura

Chairman of the Board, OpenID Foundation

--f403045f39ec254ed1054c4bea93-- From nobody Tue Apr 4 08:41:33 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B8D112944E for ; Tue, 4 Apr 2017 08:41:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.22 X-Spam-Level: X-Spam-Status: No, score=-1.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id blzE2VH5bM4R for ; Tue, 4 Apr 2017 08:41:22 -0700 (PDT) Received: from mail-qt0-f171.google.com (mail-qt0-f171.google.com [209.85.216.171]) (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 5C6BE129445 for ; Tue, 4 Apr 2017 08:41:21 -0700 (PDT) Received: by mail-qt0-f171.google.com with SMTP id r45so141975476qte.3 for ; Tue, 04 Apr 2017 08:41:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ofIZZRs+f+YhxasLuQ/h1fo6h0rL5Tsu5Rg4nF2uvsI=; b=oKTuW93kC5UNm62DyITQ1DjSNCbqPqQd3+nDmt1MqiVlV+jxjJjlNyNLCFRRq6+jjU GMQozNZtpLE7umM8nzgIhBY8bIYHZQGGlpgi36o2Noi1at+2p9r2vYpVmdO9ZfH6LiaE /4omQnE/wDLF91RAYbPX2mWzvaU/4egyijhrkchON1s5NB7t8m3v6lKT//MdHksTVOY6 J9t/5VeFC0tLUVU5/Ei2tHdC+QmNfqJDS8+pPeEhj1tFIfo3P/GZXtmi2tYDnevtp21U ZSJxG/Xkd+z4Kyd13mxzoJCmaurnjs/N0CyaPNUvNQobZezT+eBQZ/So1dmChJUR0zut yioA== X-Gm-Message-State: AFeK/H2ekxKXPANA256hQ+eZSmmvx9FhYhEQ6P5HX4d2K45Od8ZY6hk0I8DGZ0eXERQwh/ldThqZIOvw4+Wj+w== X-Received: by 10.200.44.36 with SMTP id d33mr25702280qta.198.1491320480201; Tue, 04 Apr 2017 08:41:20 -0700 (PDT) MIME-Version: 1.0 References: <58ddcfc3.5c2e6b0a.7b9e3.bbc6@mx.google.com> <58ddd7a5.e4886b0a.bf30d.bce7@mx.google.com> In-Reply-To: From: Nat Sakimura Date: Tue, 04 Apr 2017 15:41:09 +0000 Message-ID: To: Brian Campbell , John Bradley Cc: IETF oauth WG Content-Type: multipart/alternative; boundary=001a1140298c782ee4054c591bd8 Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-13.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 15:41:30 -0000 --001a1140298c782ee4054c591bd8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks Brian for spotting these. I will make the corrections in -14. Best, Nat On Fri, Mar 31, 2017 at 10:40 PM Brian Campbell wrote: and a typo - "If thie location is" should say "If this location is" On Fri, Mar 31, 2017 at 8:37 AM, Brian Campbell wrote: BTW, the intro still has text about 'dynamic parameters such as "state"' that need to be cleaned up. https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-13#section-1 On Fri, Mar 31, 2017 at 8:36 AM, Brian Campbell wrote: "The current text causes the AS to ignore them and not return a error. " - except that I don't believe the current text actually specifies that anywhere. And I think that the intent of Mike's original comment was that -13 doesn't specify the behavior but that it needs to be revised to do so. I'd suggest that the doc say that the client must include in the request object (request or request_uri) all the oauth parameters that it sends. And when request or request_uri is sent, that the AS must/should only rely on parameter values from the request object. I think being semi or somewhat compatible or tolerant of the Connect variation or request/request_uri is good because it uses the same parameter names, the same endpoint, and the same metadata names. On Thu, Mar 30, 2017 at 11:14 PM, John Bradley wrote: They are mutually exclusive. However there are two options as to how the authorization endpoint would treat extra query parameters like state if they are sent. The current text causes the AS to ignore them and not return a error. This would be more backwards compatible with the request object in OpenID Connect, however in reality it may cause connect clients to send parameters as query parameters that would be processed by a connect server that would be ignored by a OAuth server without any obvious error. There may however be subtle errors downstream from missing parameters. The other option is to have a cleaner breaking change from Connect and have the Authorization endpoint return a error if anything other than the two new parameters are sent to the authorization endpoint. I am leaning towards the latter as it is easier to debug, and wont allow incompatible Connect requests to be accepted without a error. We would have done this in Connect but couldn=E2=80=99t drop required parameters fro= m OAuth in a Connect spec. The downside for the latter is that the client would need to know if the AS is supporting The Connect version or the OAuth version. One of the typical conundrums around how to deal with doing the best going forward thing vs not blowing up older implementations. In the current proposal a client could put the required parameters both places and the same request would work on servers supporting both the Connect and OAuth versions. John B. Sent from Mail for Windo= ws 10 *From: *Torsten Lodderstedt *Sent: *March 30, 2017 11:01 PM *To: *John Bradley *Cc: *Nat Sakimura ; Nat Sakimura ; I= ETF oauth WG *Subject: *Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-13.txt I had assumed using the request object is mutual exclusive to use of URI query parameters. Did I misinterpret the draft? Am 30.03.2017 um 22:40 schrieb John Bradley : It is a trade off between compatibility with Connect and possible configuration errors. In reality it may not be compatible with Connect if the client is sending some parameters outside the object without including them in the object as a Connect client might. You would potentially wind up dropping state or nonce without an error. I asked Mike and he was leaning to making it a error to send them as query parameters as that would be a clean change. I think the choice is a bit of a grey area. Sent from Mail for Windo= ws 10 *From: *sakimura@gmail.com *Sent: *March 30, 2017 9:57 PM *To: *John Bradley ; Nat Sakimura *Cc: *IETF oauth WG *Subject: *Re: [OAUTH-WG] FW: I-D Action: draft-ietf-oauth-jwsreq-13.txt +1 Sent from my Huawei Mobile -------- Original Message -------- Subject: Re: [OAUTH-WG] FW: I-D Action: draft-ietf-oauth-jwsreq-13.txt From: John Bradley To: Nat Sakimura CC: IETF oauth WG So I think we need to make the must ignore clearer for the additional paramaters on the authorization endpoint. On Mar 30, 2017 17:33, "Nat Sakimura" wrote: Not right now. As of this writing, a client can still send duplicate parameters in the query but they get ignored by the servers honoring OAuth JAR. So, it is backwards compatible with OpenID Connect in that sense (OpenID Connect sends duplicate manatory RFC6749 parameters as the query parameters as well just to be compliant to RFC6749). Conversely, servers that do not support OAuth JAR will ignore request_uri etc. On Mar 30, 2017, at 4:47 PM, Mike Jones wrote= : Is there a clear statement somewhere along the lines of =E2=80=9Cparameters= (other than =E2=80=9Crequest=E2=80=9D or =E2=80=9Crequest_uri=E2=80=9D) are only a= llowed to be in the signed object if a signed object is used=E2=80=9D? That=E2=80=99s the kind of thi= ng I was looking for and didn=E2=80=99t find. -- Mike *From:* John Bradley [mailto:ve7jtb@ve7jtb.com] *Sent:* Thursday, March 30, 2017 4:44 PM *To:* Mike Jones *Cc:* Nat Sakimura ; IETF oauth WG *Subject:* RE: [OAUTH-WG] FW: I-D Action: draft-ietf-oauth-jwsreq-13.txt The intent of the change is to only allow the paramaters to be in the signed object if a signed object is used. This requires State, nonce etc to be in the JWT. Only one place to check will hopefully reduce implimentation errors. This also allows us to remove the caching text as we now have one JWT per request, so caching won't happen. John B. On Mar 30, 2017 4:36 PM, "Mike Jones" wrote: I **believe** the intent is that **all** parameters must be in the request object, but the spec doesn=E2=80=99t actually say that, as far as I can tel= l. Or maybe the intent is that parameters must not be duplicated between the query parameters and the request object. One or the other of these statements should be explicitly included in the specification. Of course, I could have missed the statement I=E2=80=99m as= king for in my review, in which case please let me know what I missed. Thanks, -- Mike *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *John Bradley *Sent:* Thursday, March 30, 2017 3:00 PM *To:* IETF OAUTH *Subject:* [OAUTH-WG] FW: I-D Action: draft-ietf-oauth-jwsreq-13.txt Based on feeback from the IESG we have removed some of the optionality in the draft. It is a shorter read than draft 12. John B. Sent from Mail for Windo= ws 10 *From: *internet-drafts@ietf.org *Sent: *March 30, 2017 1:38 PM *To: *i-d-announce@ietf.org *Cc: *oauth@ietf.org *Subject: *[OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-13.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol of the IETF. Title : The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request (JAR) Authors : Nat Sakimura John Bradley Filename : draft-ietf-oauth-jwsreq-13.txt Pages : 27 Date : 2017-03-30 Abstract: The authorization request in OAuth 2.0 described in RFC 6749 utilizes query parameter serialization, which means that Authorization Request parameters are encoded in the URI of the request and sent through user agents such as web browsers. While it is easy to implement, it means that (a) the communication through the user agents are not integrity protected and thus the parameters can be tainted, and (b) the source of the communication is not authenticated. Because of these weaknesses, several attacks to the protocol have now been put forward. This document introduces the ability to send request parameters in a JSON Web Token (JWT) instead, which allows the request to be signed with JSON Web Signature (JWS) and/or encrypted with JSON Web Encryption (JWE) so that the integrity, source authentication and confidentiality property of the Authorization Request is attained. The request can be sent by value or by reference. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-13 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwsreq-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-jwsreq-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --=20 Nat Sakimura Chairman of the Board, OpenID Foundation --001a1140298c782ee4054c591bd8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks Brian for spot= ting these. I will make the corrections in -14.=C2=A0

Best,=C2=A0
=

Nat

On Fri, Mar 31, 2017 at 10:40 PM Brian Campbell <bca= mpbell@pingidentity.com> wrote:
and a typo - "If thie location is" should sa= y "If this location is"

On Fri, Mar 31, 2017 at 8:37 AM, Brian Campbell <bcampbell@pingidentity.com>= ; wrote:
BTW, the intro still has text abo= ut 'dynamic parameters such as "state"' that need to be c= leaned up.=C2=A0 https://tools.ietf= .org/html/draft-ietf-oauth-jwsreq-13#section-1
=

On Fri, Mar 31, 2017 at 8:36 AM, Brian Campbell = <bcampbell@pingidentity.c= om> wrote:
"The current text causes the AS to ignore th= em and not return a error. " - except that I don't believe the cur= rent text actually specifies that anywhere. And I think that the intent of = Mike's original comment was that -13 doesn't specify the behavior b= ut that it needs to be revised to do so.

I'd suggest that the doc say that the client must = include in the request object (request or request_uri) all the oauth parame= ters that it sends. And when request or request_uri is sent, that the AS mu= st/should only rely on parameter values from the request object.

I think being semi or somewhat= compatible or tolerant of the Connect variation or request/request_uri is = good because it uses the same parameter names, the same endpoint, and the s= ame metadata names.




=C2=A0
=

On Thu, Mar 30, 2017 at 11:14 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:

They are mutually exclusive.

=C2=A0

However there are two options as to how the autho= rization endpoint would treat extra query parameters like state if they are= sent.

=C2= =A0

The curr= ent text causes the AS to ignore them and not return a error.=C2=A0 This wo= uld be more backwards compatible with the request object in OpenID Connect,= however in reality it may cause connect clients to send parameters as quer= y parameters =C2=A0that would be processed by a connect server that would b= e ignored by a OAuth server without any obvious error.=C2=A0 There may howe= ver be subtle errors downstream from missing parameters.

=C2=A0<= /u>

The other option is to have a clean= er breaking change from Connect and have the Authorization endpoint return = a error if anything other than the two new parameters are sent to the autho= rization endpoint.

=C2=A0

=C2=A0

The downside for the latter is that the client wo= uld need to know if the AS is supporting The Connect version or the OAuth v= ersion.

=C2= =A0

One of t= he typical conundrums around how to deal with doing the best going forward = thing vs not blowing up older implementations.

=C2=A0

In the current proposal a client could put th= e required parameters both places and the same request would work on server= s supporting both the Connect and OAuth versions.

=C2=A0

John B.

Sent from= Mail for Windows 10

=C2=A0

<= /span>

From: Torsten= Lodderstedt
Sent: Ma= rch 30, 2017 11:01 PM
To: John Bradley
Cc: Na= t Sakimura; Nat Sakimura; IETF oauth WG
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth= -jwsreq-13.txt

= =C2=A0

I had= assumed using the request object is mutual exclusive to use of URI query p= arameters. Did I misinterpret the draft?

=C2=A0

Am 30.03.2017 um 22:40 schrieb John Bradley <ve7jtb@ve7jtb.com>:

=C2=A0

It is a trade off between compatibility with Conne= ct and possible configuration errors.

=C2=A0

= In reality it may not be compatible with Connect if the client is sending s= ome parameters outside the object without including them in the object as a= Connect client might.=C2=A0=C2=A0=C2=A0 You would potentially wind up drop= ping state or nonce without an error.=C2=A0

=C2=A0

I asked Mike and he was leaning to making it a error to send them a= s query parameters as that would be a clean change.<= /u>

=C2=A0

I think the choice is a bit of a grey area.

= =C2=A0

Sent from Mail for Window= s 10

=C2=A0

From: sakimura@gmail.com
Sent: March 30, 2017 9:57 PM
To: John Bradley; Nat Sakimura
Cc: IETF oauth WG
Subject: Re: [OAUTH-WG] FW: I-D Acti= on: draft-ietf-oauth-jwsreq-13.txt

=C2=A0

+1

Sent from my Huawei Mo= bile



-------- Original Message = --------
Subject: Re: [OAUTH-WG] FW: I-D Action: dra= ft-ietf-oauth-jwsreq-13.txt
From: John Bradley
To: Nat Sakimura
CC: IETF oauth = WG

<= /u>

So I think we need to make the must ignore clearer for the additional = paramaters on the authorization endpoint. =C2=A0=

=C2=A0

On Mar 30, 2017 17:33, &q= uot;Nat Sakimura" <nat@sakimura.org> wrote:

<= div class=3D"gmail_msg">

N= ot right now.

As of this writing, a client can still send duplicate parame= ters in the query but they get ignored by the servers honoring OAuth JAR. S= o, it is backwards compatible with OpenID Connect in that sense (OpenID Con= nect sends duplicate manatory RFC6749 parameters as the query parameters as= well just to be compliant to RFC6749). Conversely, servers that do not sup= port OAuth JAR will ignore request_uri etc.

On Mar 30, 2017, at 4:47 PM, M= ike Jones <Michael.Jones@microsoft.com> wrote:

Is t= here a clear statement somewhere along the lines of =E2=80=9Cparamet= ers (other than =E2=80=9Crequest=E2=80=9D or =E2=80=9Crequest_uri=E2=80=9D)= are only allowed to be in the signed object if a signed object is used=E2=80=9D?=C2=A0 That=E2=80= =99s the kind of thing I was looking for and didn=E2=80=99t find.

=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

<= b class=3D"gmail_msg">From: John Bradley [mailto:ve7jtb@ve7jtb.com]=
Sent: Thursday, March 3= 0, 2017 4:44 PM
To: Mike = Jones <Michael.Jones@microsoft.com>
Cc: Nat Sakimura <nat@sakimura.org>= ; IETF oauth WG <oauth@ietf.org>
Subject: RE: [OAUTH-WG] FW: I-D Action: draft-ietf-oauth-jws= req-13.txt

=C2=A0

The intent of the change is to only allow the paramaters to b= e in the signed object if a signed object is used. =C2=A0

=C2=A0

<= /div>

This requires State, nonce etc to be in the JWT.=C2=A0 Onl= y one place to check will hopefully reduce implimentation errors. =C2=A0

=C2=A0

This also allows us to remove the cac= hing text as we now have one JWT per request, so caching won't happen. = =C2=A0=C2=A0

=C2=A0

John B. =C2=A0

=C2=A0

=C2=A0

=C2=A0

On Mar 30, 2017 4:36 PM, "Mike J= ones" <Michael.Jones@microsoft.com> wrote:

I *believe* the intent is = that *all* parameters must be in the request obj= ect, but the spec doesn=E2=80=99t actually say that, as far as I can tell.= =C2=A0 Or maybe the intent is that parameters must not be duplicated betwee= n the query parameters and the request object.

=C2=A0

One or th= e other of these statements should be explicitly included in the specificat= ion.=C2=A0 Of course, I could have missed the statement I=E2=80=99m asking = for in my review, in which case please let me know what I missed.

=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 Thanks,

=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: OAuth [mailto:oauth-bounces@iet= f.org] On Behalf Of John Bradley
Sent: Thursday, March 30, 2017 3:00 = PM
To: IETF OAUTH <oauth@= ietf.org>
Subject:= [OAUTH-WG] FW: I-D Action: draft-ietf-oauth-jwsreq-13.txt

=C2=A0

Based on feeback from the = IESG we have removed some of the optionality in the draft.

=C2=A0

It is a shorter read than draft 12.=C2= =A0=C2=A0

=C2=A0

John B.

=C2=A0

Sent from Mail for Windows 10

=C2=A0

From: internet-drafts@ietf.org
Sent: March 30, 2017 1:38 PM
To: i-d-announce@ietf.org
Cc: oauth@ietf.org
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-13.= txt

=C2=A0

=C2=A0 <= /p>

A Ne= w Internet-Draft is available from the on-line Internet-Drafts directories.=

This draft is a work item of = the Web Authorization Protocol of the IETF.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Title=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : The OAuth 2.0 A= uthorization Framework: JWT Secured Authorization Request (JAR)

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Authors=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : Nat Sakimura =

=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 John Bradley

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 Filename=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : draft-= ietf-oauth-jwsreq-13.txt =

=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Pages=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : 27

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 Date=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 : 2017-03-30 <= /p>

=C2=A0

Ab= stract:

=C2=A0=C2=A0 The auth= orization request in OAuth 2.0 described in RFC 6749 utilizes

=C2=A0=C2=A0 query parameter serialization,= which means that Authorization Request

=C2=A0=C2=A0 parameters are encoded in the URI of the request and= sent through

=C2=A0=C2=A0user= agents such as web browsers.=C2=A0 While it is easy to implement, it

=C2=A0=C2=A0 means that (a) the com= munication through the user agents are not

=C2=A0=C2=A0 integrity protected and thus the parameters can b= e tainted, and (b)

=C2=A0=C2= =A0 the source of the communication is not authenticated.=C2=A0 Because of =

=C2=A0=C2=A0 these weaknesses,= several attacks to the protocol have now been put <= /u>

=C2=A0=C2=A0 forward.

=C2=A0

=C2=A0=C2=A0 This document introduces the ability to s= end request parameters in a

= =C2=A0=C2=A0 JSON Web Token (JWT) instead, which allows the request to be s= igned

=C2=A0=C2=A0 with JSON W= eb Signature (JWS) and/or encrypted with JSON Web

=C2=A0=C2=A0 Encryption (JWE) so that the integrity, so= urce authentication and <= /u>

=C2=A0= =C2=A0 confidentiality property of the Authorization Request is attained. <= u class=3D"gmail_msg">

=C2=A0=C2=A0 The request can be= sent by value or by reference.

=C2=A0

=C2=A0

The IETF datatracker status page for this draft is:

ht= tps://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/

=C2=A0

There are also htmlized versions avai= lable at:

https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-13

https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwsreq-13 =

=C2= =A0

A diff from the prev= ious version is available at:

= https://www.ietf.org/rfcdiff?url2=3Dd= raft-ietf-oauth-jwsreq-13

=C2=A0

=C2=A0

Please note that it may take a couple of minutes from the t= ime of submission

until the ht= mlized version and diff are available at tools.ietf.org.

=C2=A0

Internet-Drafts are also available by = anonymous FTP at:

f= tp://ftp.ietf.org/internet-drafts/

=C2=A0

_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oaut= h

=C2=A0

=C2=A0<= /p>

_________________________________= ______________
OAuth mailing list
OAuth@ietf.org
https://www.= ietf.org/mailman/listinfo/oauth

=C2=A0

=C2=A0


_________= ______________________________________
OAuth mailing list
OAu= th@ietf.org
https://www.ietf.org/mailman/listinfo= /oauth




_______________________________________________
OAuth mailing list
OAu= th@ietf.org
https://www.ietf.org/mailman/listinfo= /oauth
--

Nat Sakimura

Chairman of the Board, OpenID Foundation

--001a1140298c782ee4054c591bd8-- From nobody Thu Apr 6 00:54:43 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7119A127011 for ; Thu, 6 Apr 2017 00:54:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rMd8gAThkQIn for ; Thu, 6 Apr 2017 00:54:39 -0700 (PDT) Received: from p3plsmtpa07-07.prod.phx3.secureserver.net (p3plsmtpa07-07.prod.phx3.secureserver.net [173.201.192.236]) (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 5B08A12704A for ; Thu, 6 Apr 2017 00:54:39 -0700 (PDT) Received: from [192.168.1.3] ([95.43.38.143]) by :SMTPAUTH: with SMTP id w2F4cFGmW9O79w2F5c3VmF; Thu, 06 Apr 2017 00:54:08 -0700 To: oauth@ietf.org References: <149090694651.9027.6337833834024757190.idtracker@ietfa.amsl.com> From: Vladimir Dzhuvinov Organization: Connect2id Ltd. Message-ID: Date: Thu, 6 Apr 2017 10:54:05 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------5C8464C87233BAB322E9874C" X-CMAE-Envelope: MS4wfB0/1DymYdygoCVvfEolisseINLbgyjaaxGBRfxwKpjuFQjh9FXqoksSrt9XH2teP8sbAtxwQTLQylSjfr/jtO9FeJFrHpfvHyFUHU1s0IaUT7VMqq5U JPYWpx7M3iGZAIp/bxSc35Um+Q+s/cYpoU8y5bPweb8TSzp9wR0wVMcS Archived-At: Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-mtls-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 07:54:41 -0000 This is a multi-part message in MIME format. --------------5C8464C87233BAB322E9874C Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable The cert / token binding is a significant upgrade on the previous version, and I hope it will become an official WG item. I also see that the comments about which certificate fields to use to identify the client were addressed, this is important for interop. Thanks for the great work, Vladimir On 31/03/17 00:15, Brian Campbell wrote: > This document, which I hope to present and discuss briefly at tomorrow'= s > meeting, replaces (but keeps the feature) the Mutual TLS Authentication= for > OAuth Clients > t= hat > was published leading up to the Seoul meeting > and= > adds mutual TLS sender constrained access to OAuth protected resources.= The > concept for the latter was largely derived from one of the options in t= he > JPOP draft . = I > apologize for the 11th hour publication but hope some folks will have a= > chance to read it. > > ---------- Forwarded message ---------- > From: > Date: Thu, Mar 30, 2017 at 3:49 PM > Subject: New Version Notification for draft-campbell-oauth-mtls-00.txt > To: Brian Campbell , Nat Sakimura < > n-sakimura@nri.co.jp>, Torsten Lodderstedt , J= ohn > Bradley > > > > A new version of I-D, draft-campbell-oauth-mtls-00.txt > has been successfully submitted by Brian Campbell and posted to the > IETF repository. > > Name: draft-campbell-oauth-mtls > Revision: 00 > Title: Mutual TLS Profiles for OAuth Clients > Document date: 2017-03-30 > Group: Individual Submission > Pages: 10 > URL: https://www.ietf.org/internet-drafts/draft-campbell-oau= th-mt > ls-00.txt > Status: https://datatracker.ietf.org/doc/draft-campbell-oauth-m= tls/ > Htmlized: https://tools.ietf.org/html/draft-campbell-oauth-mtls-0= 0 > Htmlized: https://datatracker.ietf.org/doc/html/draft-campbell-oa= uth- > mtls-00 > > > Abstract: > This document describes Transport Layer Security (TLS) mutual > authentication using X.509 certificates as a mechanism for both OAut= h > client authentication to the token endpoint as well as for sender > constrained access to OAuth protected resources. > > > > > Please note that it may take a couple of minutes from the time of submi= ssion > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --=20 Vladimir Dzhuvinov :: vladimir@connect2id.com --------------5C8464C87233BAB322E9874C Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

The cert / token binding is a significant upgrade on the previous version, and I hope it will become an official WG item.

I also see that the comments about which certificate fields to use to identify the client were addressed, this is important for interop.

Thanks for the great work,

Vladimir


On 31/03/17 00:15, Brian Campbell wrote:
This document, which I hope to present and discuss briefly at tomorrow's
meeting, replaces (but keeps the feature) the Mutual TLS Authentication for
OAuth Clients
<https://tools.ietf.org/html/draft-campbell-oauth-tls-client-auth-00> that
was published leading up to the Seoul meeting
<https://www.ietf.org/mail-archive/web/oauth/current/msg16704.html> and
adds mutual TLS sender constrained access to OAuth protected resources. The
concept for the latter was largely derived from one of the options in the
JPOP draft <https://tools.ietf.org/html/draft-sakimura-oauth-jpop-04>. I
apologize for the 11th hour publication but hope some folks will have a
chance to read it.

---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Thu, Mar 30, 2017 at 3:49 PM
Subject: New Version Notification for draft-campbell-oauth-mtls-00.txt
To: Brian Campbell <brian.d.campbell@gmail.com>, Nat Sakimura <
n-sakimura@nri.co.jp>, Torsten Lodderstedt <torsten@lodderstedt.net>, John
Bradley <ve7jtb@ve7jtb.com>



A new version of I-D, draft-campbell-oauth-mtls-00.txt
has been successfully submitted by Brian Campbell and posted to the
IETF repository.

Name:           draft-campbell-oauth-mtls
Revision:       00
Title:          Mutual TLS Profiles for OAuth Clients
Document date:  2017-03-30
Group:          Individual Submission
Pages:          10
URL:            https://www.ietf.org/internet-drafts/draft-campbell-oauth-mt
ls-00.txt
Status:         https://datatracker.ietf.org/doc/draft-campbell-oauth-mtls/
Htmlized:       https://tools.ietf.org/html/draft-campbell-oauth-mtls-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-campbell-oauth-
mtls-00


Abstract:
   This document describes Transport Layer Security (TLS) mutual
   authentication using X.509 certificates as a mechanism for both OAuth
   client authentication to the token endpoint as well as for sender
   constrained access to OAuth protected resources.




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

The IETF Secretariat




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


-- 
Vladimir Dzhuvinov :: vladimir@connect2id.com
--------------5C8464C87233BAB322E9874C-- From nobody Fri Apr 7 05:58:36 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB00F129461 for ; Fri, 7 Apr 2017 05:58:34 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jxXmFHtKP7JK for ; Fri, 7 Apr 2017 05:58:31 -0700 (PDT) Received: from mail-wr0-x229.google.com (mail-wr0-x229.google.com [IPv6:2a00:1450:400c:c0c::229]) (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 1F204129411 for ; Fri, 7 Apr 2017 05:58:31 -0700 (PDT) Received: by mail-wr0-x229.google.com with SMTP id c55so33046995wrc.3 for ; Fri, 07 Apr 2017 05:58:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=69vOhMmiD5iqaGShHTxbiPt1kiR9Fl3iE6jXRS3RiGk=; b=RJDtCEXEhYtd7NNmcKMUnnVegj3U0DNPCZLBtT3JyM1NubTwrBpNXLnCTxkEsFxaOJ yAM08DSHJJgpimjvtnIJ9JC5m92TIYNIRJaMBkOZZ+Xl/AszNS+Uo6oLlAYKuTw3GmBW jSo7RJwMDRfBUySEJY/CPA0wLhbyJRwXfx2fOQ1/+QOANc9OLIb599Rp/JIPvQjV3Hl/ KZ1BML0j2aLMc52bQtl9S/Rh+WmcgUm6L2Ob5xDKMMpLBoeyo3pICa45YSrjdc2XpJJX Hs8r5p9NPuLA12GRnUGk2fAuKh5RxlXyHnric3lp4edE/OnZgrM/+DeGLq/fpkqP9WyQ ILug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=69vOhMmiD5iqaGShHTxbiPt1kiR9Fl3iE6jXRS3RiGk=; b=EHiIBn5Fr9cZEinPnixwSp6XP+96t3cIeAEMdaGbo+oYVt8NRx5VNWDPNZzBKnOhVD zspR8KE2lqXw1cTGQVkyIgXY0U4mYHeZrHvQiJNrP7shG3znYPw/FcChHfy1XWRxlo3p F9NYw0T77P9JUyD0pJynV6X5yybORSrwRy8upWYnS9P7vNPAFAdu+gUBBLGkjbJcfysw qF0Wty47HPJbojPB3Nt5XSfmD1xV4ak/R8KhkOXJIS3AxQbd7hJb6ImSl5OSS/djxHuc 1vS1iNnrs+EGwSS+p7O7xwFPc+8brRFV5fYH7pII+CU/elMcZKbhFkeVD0FDnyUPVXoK 0RHQ== X-Gm-Message-State: AFeK/H2U/YMRrvV9vvb6NCCr5AoPwPz1tfXNOvYIGlNlKsYYTzBxSgdMCx2Ctx42/fPsww== X-Received: by 10.28.137.211 with SMTP id l202mr29155974wmd.118.1491569909296; Fri, 07 Apr 2017 05:58:29 -0700 (PDT) Received: from [10.36.226.98] ([80.169.137.53]) by smtp.googlemail.com with ESMTPSA id 140sm30258169wmg.18.2017.04.07.05.58.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Apr 2017 05:58:28 -0700 (PDT) To: Brian Campbell , oauth References: <149090694651.9027.6337833834024757190.idtracker@ietfa.amsl.com> From: Sergey Beryozkin Message-ID: Date: Fri, 7 Apr 2017 13:58:28 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-mtls-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 12:58:35 -0000 Hi Brian Thanks, a minor typo in the example, "x5t#s256" as opposed to "x5t#S256" (sorry if it was already reported, might've missed it) Cheers, Sergey On 30/03/17 22:15, Brian Campbell wrote: > This document, which I hope to present and discuss briefly at tomorrow's > meeting, replaces (but keeps the feature) the Mutual TLS Authentication > for OAuth Clients > > that was published leading up to the Seoul meeting > and > adds mutual TLS sender constrained access to OAuth protected resources. > The concept for the latter was largely derived from one of the options > in the JPOP draft > . I apologize > for the 11th hour publication but hope some folks will have a chance to > read it. > > ---------- Forwarded message ---------- > From: ** > > Date: Thu, Mar 30, 2017 at 3:49 PM > Subject: New Version Notification for draft-campbell-oauth-mtls-00.txt > To: Brian Campbell >, Nat Sakimura >, Torsten Lodderstedt > >, John Bradley > > > > > > A new version of I-D, draft-campbell-oauth-mtls-00.txt > has been successfully submitted by Brian Campbell and posted to the > IETF repository. > > Name: draft-campbell-oauth-mtls > Revision: 00 > Title: Mutual TLS Profiles for OAuth Clients > Document date: 2017-03-30 > Group: Individual Submission > Pages: 10 > URL: > https://www.ietf.org/internet-drafts/draft-campbell-oauth-mtls-00.txt > > Status: > https://datatracker.ietf.org/doc/draft-campbell-oauth-mtls/ > > Htmlized: https://tools.ietf.org/html/draft-campbell-oauth-mtls-00 > > Htmlized: > https://datatracker.ietf.org/doc/html/draft-campbell-oauth-mtls-00 > > > > Abstract: > This document describes Transport Layer Security (TLS) mutual > authentication using X.509 certificates as a mechanism for both OAuth > client authentication to the token endpoint as well as for sender > constrained access to OAuth protected resources. > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org > . > > The IETF Secretariat > > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From nobody Fri Apr 7 06:54:29 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7021F127241 for ; Fri, 7 Apr 2017 06:54:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.339 X-Spam-Level: X-Spam-Status: No, score=-2.339 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sv3g1RrFSLMb for ; Fri, 7 Apr 2017 06:54:25 -0700 (PDT) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::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 3B2991294C5 for ; Fri, 7 Apr 2017 06:54:21 -0700 (PDT) Received: by mail-it0-x231.google.com with SMTP id a140so43035720ita.0 for ; Fri, 07 Apr 2017 06:54:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=nQh2LAxt5R/wF2ev2LAvhKJJNhjRsvn8LmwLllayCdg=; b=z2UVQhLnRWyBtWyDpFjpGIKICLHRifBga1wQyggC85jpLULocrbF/04+77fXAwmHbe sBY4u2/9PyTL8N+JFN6BbNsO670kSHOUV3OrQqgHwHdUbytiuBYi7gjZSxlm3KfBoe01 sodY6EBq/aU9GmJiXGPxz5atPXTxhguWg6WIXptuEx7//SqcSQOC/mi/A6Bff8/Q2oai 0jOK4Yh5nLs/EXMm/B5h3S5bbarttQS9ML8Zq4yPK4OFySIacp6khDgSR0T6GAjZ+HBu TMf4d6Rp5oq8aSZ6JDekZavPY/61i5xU4C5YWTE/DpQdwmEdmQoteHvT7vtpGMA5qtEH Fkkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=nQh2LAxt5R/wF2ev2LAvhKJJNhjRsvn8LmwLllayCdg=; b=sjThJa31iC1GPm0g5chID8wxOwz3W/xE/xkFTpVv0L2C5vRXfoEYHocrv1npKHxq5G qu4S06rSkZLZAkWXhr4+lce8qUvzQtI9gtzCPUt8Yp5VI51zbgB+Yf0UReTE7yA8mnIx TMrxJ06r6SJS3+d21uFVCjdyoYD6p4SNK5t2xoctQ+XoJuCiEY2JQ2m17hU8J1irQKqz G+PlamilOt26WVUW3gIoB5IeNEJ0hownvGJUQOXmLcuKJm/nLSOJIvhzptIKT8uYzncT bqjl5hpieSa0OtdRndnduuMeYqCy3rWpJKIwAXia7oURpqC8igWB9nxoRJO4cO6o4qQM 16tQ== X-Gm-Message-State: AFeK/H3O6GNLo45ZC+F33l4wO0zYQjAhkJ6BINuWowGimOdwN/FuRHuk bV19vndAkVRv3uqgZJzyV14lvWDZLwdb X-Received: by 10.36.91.76 with SMTP id g73mr33582593itb.75.1491573260416; Fri, 07 Apr 2017 06:54:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.167.139 with HTTP; Fri, 7 Apr 2017 06:54:20 -0700 (PDT) In-Reply-To: References: <149090694651.9027.6337833834024757190.idtracker@ietfa.amsl.com> From: John Bradley Date: Fri, 7 Apr 2017 14:54:20 +0100 Message-ID: To: Sergey Beryozkin Cc: Brian Campbell , oauth Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a1144ca765bc25d054c93f62e" Archived-At: Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-mtls-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 13:54:28 -0000 --001a1144ca765bc25d054c93f62e Content-Type: multipart/alternative; boundary=001a1144ca7658117d054c93f626 --001a1144ca7658117d054c93f626 Content-Type: text/plain; charset=UTF-8 It was a test to see who was really reading it:) On Fri, Apr 7, 2017 at 1:58 PM, Sergey Beryozkin wrote: > Hi Brian > > Thanks, a minor typo in the example, > "x5t#s256" as opposed to "x5t#S256" > > (sorry if it was already reported, might've missed it) > > Cheers, Sergey > On 30/03/17 22:15, Brian Campbell wrote: > >> This document, which I hope to present and discuss briefly at tomorrow's >> meeting, replaces (but keeps the feature) the Mutual TLS Authentication >> for OAuth Clients >> >> that was published leading up to the Seoul meeting >> and >> adds mutual TLS sender constrained access to OAuth protected resources. >> The concept for the latter was largely derived from one of the options >> in the JPOP draft >> . I apologize >> for the 11th hour publication but hope some folks will have a chance to >> read it. >> >> ---------- Forwarded message ---------- >> From: ** > >> Date: Thu, Mar 30, 2017 at 3:49 PM >> Subject: New Version Notification for draft-campbell-oauth-mtls-00.txt >> To: Brian Campbell > >, Nat Sakimura > >, Torsten Lodderstedt >> >, John Bradley >> > >> >> >> >> A new version of I-D, draft-campbell-oauth-mtls-00.txt >> has been successfully submitted by Brian Campbell and posted to the >> IETF repository. >> >> Name: draft-campbell-oauth-mtls >> Revision: 00 >> Title: Mutual TLS Profiles for OAuth Clients >> Document date: 2017-03-30 >> Group: Individual Submission >> Pages: 10 >> URL: >> https://www.ietf.org/internet-drafts/draft-campbell-oauth-mtls-00.txt >> >> Status: >> https://datatracker.ietf.org/doc/draft-campbell-oauth-mtls/ >> >> Htmlized: https://tools.ietf.org/html/draft-campbell-oauth-mtls-00 >> >> Htmlized: >> https://datatracker.ietf.org/doc/html/draft-campbell-oauth-mtls-00 >> >> >> >> Abstract: >> This document describes Transport Layer Security (TLS) mutual >> authentication using X.509 certificates as a mechanism for both OAuth >> client authentication to the token endpoint as well as for sender >> constrained access to OAuth protected resources. >> >> >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org >> . >> >> The IETF Secretariat >> >> >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --001a1144ca7658117d054c93f626 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It was a test to see who was really reading it:)

On Fri, Apr 7, 2017 a= t 1:58 PM, Sergey Beryozkin <sberyozkin@gmail.com> wrote:=
Hi Brian

Thanks, a minor typo in the example,
"x5t#s256" as opposed to "x5t#S256"

(sorry if it was already reported, might've missed it)

Cheers, Sergey
On 30/03/17 22:15, Brian Campbell wrote:
This document, which I hope to present and discuss briefly at tomorrow'= s
meeting, replaces (but keeps the feature) the Mutual TLS Authentication
for OAuth Clients
 <https://tools.ietf.org/html/d= raft-campbell-oauth-tls-client-auth-00> that was published leading up to the Seoul meeting
 <https://www.ietf.org/mail-archive/web/oauth/current/msg16704.html> and adds mutual TLS sender constrained access to OAuth protected resources.
The concept for the latter was largely derived from one of the options
in the JPOP draft
 <https://tools.ietf.org/html/draft-s= akimura-oauth-jpop-04>. I apologize
for the 11th hour publication but hope some folks will have a chance to
read it.

---------- Forwarded message ----------
 From: ** <= internet-drafts@ietf.org <mailto:internet-drafts@ietf.org>>
Date: Thu, Mar 30, 2017 at 3:49 PM
Subject: New Version Notification for draft-campbell-oauth-mtls-00.txt=
To: Brian Campbell <brian.d.campbell@gmail.com
<mailto:= brian.d.campbell@gmail.com>>, Nat Sakimura <n-sakimura@nri.co.jp
<mailto:n-saki= mura@nri.co.jp>>, Torsten Lodderstedt
<torsten@lo= dderstedt.net <mailto:torsten@lodderstedt.net>>, John Bradley
<ve7jtb@ve7jtb.co= m <mailto:ve7= jtb@ve7jtb.com>>



A new version of I-D, draft-campbell-oauth-mtls-00.txt
has been successfully submitted by Brian Campbell and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-campbell-oauth-mtls
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Mutual TLS Profiles for OAuth Clie= nts
Document date:=C2=A0 2017-03-30
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 10
URL:
https://www.ietf.org/internet-<= wbr>drafts/draft-campbell-oauth-mtls-00.txt
<https://www.ietf.org/intern= et-drafts/draft-campbell-oauth-mtls-00.txt>
Status:
=C2=A0https://datatracker.ietf.org/d= oc/draft-campbell-oauth-mtls/
<https://datatracker.ietf.org/doc= /draft-campbell-oauth-mtls/>
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://= tools.ietf.org/html/draft-campbell-oauth-mtls-00
<https://tools.ietf.org/html/draft-c= ampbell-oauth-mtls-00>
Htmlized:
=C2=A0https://datatracker.ietf.org= /doc/html/draft-campbell-oauth-mtls-00
<https://datatracker.ietf.org/<= wbr>doc/html/draft-campbell-oauth-mtls-00>


Abstract:
=C2=A0 =C2=A0This document describes Transport Layer Security (TLS) mutual<= br> =C2=A0 =C2=A0authentication using X.509 certificates as a mechanism for bot= h OAuth
=C2=A0 =C2=A0client authentication to the token endpoint as well as for sen= der
=C2=A0 =C2=A0constrained access to OAuth protected resources.




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

The IETF Secretariat





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


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

--001a1144ca7658117d054c93f626-- --001a1144ca765bc25d054c93f62e Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIRGwYJKoZIhvcNAQcCoIIRDDCCEQgCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg gg4rMIIErzCCA5egAwIBAgIRAOAjyxUSg1OJrWFuelRnayEwDQYJKoZIhvcNAQELBQAwbzELMAkG A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0xNDEy MjIwMDAwMDBaFw0yMDA1MzAxMDQ4MzhaMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRl ZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1 cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCJsQ3aelMZTnBSHbxW pgYmt7hJ4JbnUavx8FoTSRWjtIwbYLx6UUKneYykIt8XYU6R1XYjChTTSgJ/th0JgG6lBD3ZursW /qGHqS5DUkMWfK8yUMimT1rpCNjPkyWce4joMGTmpPhWgP0qJBQzF5msROVpi6NGBkvCM9TpQJ8G sLGsk0C5tQiTOpwqU6MQ2z0gYTxVA47ZTnYlAiEp+qN8cXZP7uFfgen7VIDbw3s1UreE3iI9LDAt MX9ZvVI3sDNpLUPr+tal8Zd3Z1GM2e4n67ylBzh2jKSpOP/fjPUDrEm+yvdzmToPMquclToTPQ5G Old0YVC+xkA/y+Tin6IhAgMBAAGjggEXMIIBEzAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73g JMtUGjAdBgNVHQ4EFgQUkmFrguGioKpP7GfxwqP3tIAAwewwDgYDVR0PAQH/BAQDAgGGMBIGA1Ud EwEB/wQIMAYBAf8CAQAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBEGA1UdIAQKMAgw BgYEVR0gADBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vQWRkVHJ1 c3RFeHRlcm5hbENBUm9vdC5jcmwwNQYIKwYBBQUHAQEEKTAnMCUGCCsGAQUFBzABhhlodHRwOi8v b2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBCwUAA4IBAQAbKm6sVcE6q4jF2O3NVfOqa2Er wAkQI5kPxWZqb7H1tLV3Xg8CYQDffQX+ErOkgIAA/PsdW2pyAgpBvAW6wVjVJsLq1U2E+/6CmM9Y G+MiY5xS+LsFNqt9WKXeqztj5drVc+/s4Pt74qP/8EIjnMq2jU0+5EsYA7KoLdTYu0JLkGmFENum NzToe+ABEKWcyjrHn0+ING6KZdAairup3MrKNtH0/MJkKTWv1rGncRHSA0Oxjz6a7J4yU/R2ksqG NAe5LMrmHErYmQ3BhuKQkvtaQmojIRDpZcf11bt+6oyFIAJi6tE6ByxZxZkz8jiJ5bbpFnofeRT2 ShAaJvp8ivubMIIENjCCAx6gAwIBAgIBATANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEU MBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3 b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTAwMDUzMDEwNDgzOFoX DTIwMDUzMDEwNDgzOFowbzELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYD VQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0 ZXJuYWwgQ0EgUm9vdDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALf3GjPm8gAELTng TlvtH7xsD821+iO2zt6bETOXpClMfZOfvUq8k+0DGuOPz+VtUFrWlymUWoCwSXrbLpX9uMq/Nzgt Hj6RQa1wVsfwTz/oMp50ysiQVOnGXw94nZpAPA6sYapeFI+eh6FqUNzXmk6vBbOmcZSccbNQYArH E504B4YCqOmoaSYYkKtMsE8jqzpPhNjfzp/haW+710LXa0Tkx63ubUFfclpxCDezeWWkWaCUN/cA Lw3CknLa0Dhy2xSoRcRdKn23tNbE7qzNE0S3ySvdQwAl+mG5aWpYIxG3pzOPVnVZ9c0p10a3Citl ttNCbxWyuHv77+ldU9U0WicCAwEAAaOB3DCB2TAdBgNVHQ4EFgQUrb2YejS0Jvf6xCZU7wO94CTL VBowCwYDVR0PBAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wgZkGA1UdIwSBkTCBjoAUrb2YejS0Jvf6 xCZU7wO94CTLVBqhc6RxMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4 dGVybmFsIENBIFJvb3SCAQEwDQYJKoZIhvcNAQEFBQADggEBALCb4IUlwtYj4g+WBpKdQZic2YR5 gdkeWxQHIzZlj7DYd7usQWxHYINRsPkyPef89iYTx4AWpb9a/IfPeHmJIZriTAcKhjW88t5RxNKW t9x+Tu5w/Rw56wwCURQtjr0W4MHfRnXnJK3s9EK0hZNwEGe6nQY1ShjTK3rMUUKhemPR5ruhxSvC Nr4TDea9Y355e6cJDUCrat2PisP29owaQgVR1EX1n6diIWgVIEM8med8vSTYqZEXc4g/VhsxOBi0 cQ+azcgOno4uG+GMmIPLHzHxREzGBHNJdmAPx/i9F4BrLunMTA5amnkPIAou1Z5jJh5VkpTYghda e9C8x49OhgQwggU6MIIEIqADAgECAhEA2TLMtWuXNcB2cbqZ/VgVujANBgkqhkiG9w0BAQsFADCB mzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2 IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE3MDEwOTAwMDAw MFoXDTE4MDEwOTIzNTk1OVowIjEgMB4GCSqGSIb3DQEJARYRdmU3anRiQHZlN2p0Yi5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDW2rqobOFQ/XmzH3DG2UK1Dt6jtc+OFZ71KQoB o8IZa/V94Ey12BPjBcoj+cjHNVsLd2QiUpMcf5sZFMX1cmvpR7TiUISgVcHe8zgiUUvN5Jn5tPDM Kb4E34TtDEG2X5FyY35AwCl8NV/loj2D5KLid9BLdVTJjfqokjLQ/4qCQjWBjfTpIdAdr3lXfg5f a5UPyIkphEIplM8/yGfX0W/PBl804XAL0gesLrfEMdgG58UCN1wJMgH4uRKmKU/U2Ap4W9hTpioN M722U8x7N6P1v6MqTAWCUaskdOp+ktNxFGxOlCE7BEo/EIaWbEt5RHwDePctScDLsi56+VI3TysR AgMBAAGjggHvMIIB6zAfBgNVHSMEGDAWgBSSYWuC4aKgqk/sZ/HCo/e0gADB7DAdBgNVHQ4EFgQU Yg3SsFWhMro4Abonbn1IX4JKj5QwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0l BBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9 MDsGDCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0 L0NQUzBdBgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9TSEEy NTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDBYBggrBgEFBQcwAoZMaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xp ZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDov L29jc3AuY29tb2RvY2EuY29tMBwGA1UdEQQVMBOBEXZlN2p0YkB2ZTdqdGIuY29tMA0GCSqGSIb3 DQEBCwUAA4IBAQCC26y+6/+SJoRQWepca+rB9eSSwaCAb8nNqA+00ZiOHb+6UbbV1xa7Z8wDIuEL 5UKbNtQ2NDArvzF9YI0xNafoV1AEmP/3+ljxQHSEI0U1p2h401sOx+nSjcwtTzACso1lw+I0oJYM JFITOIfZy8HgFpCipBrQAp9jMJ+KSKDX3xu/hzPosfdnXp7sV1KAjkFrAtR3AnQYfJ5W8QrsmC4N BbiAKoYWUSdklqn3v1neTG/+oOhcw7hcGZo+YmPyF9Cdy0gBtwSHPt8hluhg2TlzmqYfi0dVL/mU jCBNUY/BFH+MBqKF7sOIRMv8ALWceVaM/NEcBciKs4eR99A4cw9ZMYICtDCCArACAQEwgbEwgZsx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRANkyzLVrlzXAdnG6mf1Y FbowDQYJYIZIAWUDBAIBBQCggdQwLwYJKoZIhvcNAQkEMSIEIFhZDPv2LyPC8wGqXi9wbuLjSYiu l0DPqUdKlE/KlESNMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE3 MDQwNzEzNTQyMFowaQYJKoZIhvcNAQkPMVwwWjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzALBgkqhkiG9w0BAQowCwYJKoZIhvcNAQEHMAsGCWCGSAFl AwQCATANBgkqhkiG9w0BAQEFAASCAQBdEtTux3fbum43LQ/dX7zPIQjE0zeoXUvvFZ1XTYObhSgV Im3On3HTEPkNu6W+mJ+D/9NsUqgOmlGlAhI7/LAiLWgvsolk2uM5RSP9kLPfaLO2Vl/Z+XhkxaDn hxb13MRPq//NB3qmy4ChXHBR2F85jXu+3yeox/yFSizI9IMnAB35mAouTl/BRmRRZj8MNerTf90h EWUlOGrt9qVo+3ijcFHoqcahLBthfMekETTqd8ZOAQEWduX0NNLjPXC83QUfwCu9DQ+a1fFKbGI1 ztOYLuJ2+Bv1VkV2JXAWqdE/FvKfnaCfvB/evmUFxT4+3xQItx6L6aej65q09dacsKlS --001a1144ca765bc25d054c93f62e-- From nobody Fri Apr 7 07:37:22 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3C71126C3D for ; Fri, 7 Apr 2017 07:37:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.739 X-Spam-Level: X-Spam-Status: No, score=-1.739 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, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dg9YRQ53cAOI for ; Fri, 7 Apr 2017 07:37:18 -0700 (PDT) Received: from mail-pg0-x234.google.com (mail-pg0-x234.google.com [IPv6:2607:f8b0:400e:c05::234]) (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 1A60C127F0E for ; Fri, 7 Apr 2017 07:37:18 -0700 (PDT) Received: by mail-pg0-x234.google.com with SMTP id 81so68581424pgh.2 for ; Fri, 07 Apr 2017 07:37:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=aKBe0QH96sgNdl+2VAbxjl5JevBBxLl+n1dNCwW74II=; b=X7jKrDnlna7kOOQOdob5yYqKqI+xQ2Xp4M7OBgQwK3J+Wf4eSFUePrFkrB4BRNWKfx 6vDjRx7Yg59vYfaMLM/7aJu0TXjAgN7PXl3/piomL/0S9uKiEq58Vv1uxTwunwlDat0Y TKaqgEYBHCBAlSqCPMAYH/l6sPR254hKDSuao= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=aKBe0QH96sgNdl+2VAbxjl5JevBBxLl+n1dNCwW74II=; b=IvsEA79UKlXsVDjg3vd05doA8vjdPdWB4xtYBUkMWsrv/ORI0eV3YyYBDR5LYzqcri MRrThr24ehTsZd2Utx3Eo9nC/ZeGm63/HuLaCy+StVAFxt3uWasv/61yh4DL7UzG0P6O EI6ZG4+dqfZIPIBZaqfVZY3GeUl34DTq+quHl7WqrXd4GVp4yMqK7fFiu1HGeSSFLhEt rFlIKEul7aSmy9GJA4DI6/6B/HakRpMbnm4rpLYj58JzpT0BET+WggKK3NltndGH9AcT 0QGofVRIcC/akxD+7tK9MdYNFpnqM29gL4vKFJn+BSEANojlroDp5mmuFlgBymN/ZPCv 2K0w== X-Gm-Message-State: AFeK/H3jSif7xi5WYnzu+4Un/Z3ONoifNw64Zf2DsBSeSQZZnAfv/Dcf4jZxAlEI9qhGQCPx9dNoonF4aRsCCK/z X-Received: by 10.98.67.89 with SMTP id q86mr39716032pfa.237.1491575837642; Fri, 07 Apr 2017 07:37:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.155.9 with HTTP; Fri, 7 Apr 2017 07:36:47 -0700 (PDT) In-Reply-To: References: <149090694651.9027.6337833834024757190.idtracker@ietfa.amsl.com> From: Brian Campbell Date: Fri, 7 Apr 2017 08:36:47 -0600 Message-ID: To: John Bradley Cc: Sergey Beryozkin , oauth Content-Type: multipart/alternative; boundary=001a11499a58f57032054c948f60 Archived-At: Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-mtls-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 14:37:21 -0000 --001a11499a58f57032054c948f60 Content-Type: text/plain; charset=UTF-8 And Sergey is the only person to pass the test... Thanks for catching that, Sergey. I'll get it fixed in the next revision. On Fri, Apr 7, 2017 at 7:54 AM, John Bradley wrote: > It was a test to see who was really reading it:) > > On Fri, Apr 7, 2017 at 1:58 PM, Sergey Beryozkin > wrote: > >> Hi Brian >> >> Thanks, a minor typo in the example, >> "x5t#s256" as opposed to "x5t#S256" >> >> (sorry if it was already reported, might've missed it) >> >> Cheers, Sergey >> On 30/03/17 22:15, Brian Campbell wrote: >> >>> This document, which I hope to present and discuss briefly at tomorrow's >>> meeting, replaces (but keeps the feature) the Mutual TLS Authentication >>> for OAuth Clients >>> >>> that was published leading up to the Seoul meeting >>> and >>> adds mutual TLS sender constrained access to OAuth protected resources. >>> The concept for the latter was largely derived from one of the options >>> in the JPOP draft >>> . I apologize >>> for the 11th hour publication but hope some folks will have a chance to >>> read it. >>> >>> ---------- Forwarded message ---------- >>> From: ** > >>> Date: Thu, Mar 30, 2017 at 3:49 PM >>> Subject: New Version Notification for draft-campbell-oauth-mtls-00.txt >>> To: Brian Campbell >> >, Nat Sakimura >> >, Torsten Lodderstedt >>> >, John Bradley >>> > >>> >>> >>> >>> A new version of I-D, draft-campbell-oauth-mtls-00.txt >>> has been successfully submitted by Brian Campbell and posted to the >>> IETF repository. >>> >>> Name: draft-campbell-oauth-mtls >>> Revision: 00 >>> Title: Mutual TLS Profiles for OAuth Clients >>> Document date: 2017-03-30 >>> Group: Individual Submission >>> Pages: 10 >>> URL: >>> https://www.ietf.org/internet-drafts/draft-campbell-oauth-mtls-00.txt >>> >>> Status: >>> https://datatracker.ietf.org/doc/draft-campbell-oauth-mtls/ >>> >>> Htmlized: https://tools.ietf.org/html/draft-campbell-oauth-mtls-00 >>> >>> Htmlized: >>> https://datatracker.ietf.org/doc/html/draft-campbell-oauth-mtls-00 >>> >>> >>> >>> Abstract: >>> This document describes Transport Layer Security (TLS) mutual >>> authentication using X.509 certificates as a mechanism for both OAuth >>> client authentication to the token endpoint as well as for sender >>> constrained access to OAuth protected resources. >>> >>> >>> >>> >>> Please note that it may take a couple of minutes from the time of >>> submission >>> until the htmlized version and diff are available at tools.ietf.org >>> . >>> >>> The IETF Secretariat >>> >>> >>> >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > --001a11499a58f57032054c948f60 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
And Sergey is the only person to pass the test..= .

Thanks for catching that, = Sergey. I'll get it fixed in the next revision.

On Fri, Apr 7, 2= 017 at 7:54 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
It was a test to see who was= really reading it:)

On Fri, Apr 7, 2017 at 1:5= 8 PM, Sergey Beryozkin <sberyozkin@gmail.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">Hi Brian

Thanks, a minor typo in the example,
"x5t#s256" as opposed to "x5t#S256"

(sorry if it was already reported, might've missed it)

Cheers, Sergey
On 30/03/17 22:15, Brian Campbell wrote:
This document, which I hope to present and discuss briefly at tomorrow'= s
meeting, replaces (but keeps the feature) the Mutual TLS Authentication
for OAuth Clients
 <https://tools.ietf.org/html/d= raft-campbell-oauth-tls-client-auth-00>
that was published leading up to the Seoul meeting
 <https://www.ietf.org/mail-archive/web/oauth/current/msg16704.html> and
adds mutual TLS sender constrained access to OAuth protected resources.
The concept for the latter was largely derived from one of the options
in the JPOP draft
 <https://tools.ietf.org/html/draft-s= akimura-oauth-jpop-04>. I apologize
for the 11th hour publication but hope some folks will have a chance to
read it.

---------- Forwarded message ----------
 From: ** <= internet-drafts@ietf.org <mailto:internet-drafts@ietf.org>>
Date: Thu, Mar 30, 2017 at 3:49 PM
Subject: New Version Notification for draft-campbell-oauth-mtls-00.txt=
To: Brian Campbell <brian.d.campbell@gmail.com
<mailto:= brian.d.campbell@gmail.com>>, Nat Sakimura <n-sakimura@nri.co.jp
<mailto:n-saki= mura@nri.co.jp>>, Torsten Lodderstedt
<torsten@lo= dderstedt.net <mailto:torsten@lodderstedt.net>>, John Bradley
<ve7jtb@ve7jtb.co= m <mailto:ve7= jtb@ve7jtb.com>>



A new version of I-D, draft-campbell-oauth-mtls-00.txt
has been successfully submitted by Brian Campbell and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-campbell-oauth-mtls
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Mutual TLS Profiles for OAuth Clie= nts
Document date:=C2=A0 2017-03-30
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 10
URL:
https://www.ietf.org/internet-<= wbr>drafts/draft-campbell-oauth-mtls-00.txt
<https://www.ietf.org/intern= et-drafts/draft-campbell-oauth-mtls-00.txt>
Status:
=C2=A0https://datatracker.ietf.org/d= oc/draft-campbell-oauth-mtls/
<https://datatracker.ietf.org/doc= /draft-campbell-oauth-mtls/>
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://= tools.ietf.org/html/draft-campbell-oauth-mtls-00
<https://tools.ietf.org/html/draft-c= ampbell-oauth-mtls-00>
Htmlized:
=C2=A0https://datatracker.ietf.org= /doc/html/draft-campbell-oauth-mtls-00
<https://datatracker.ietf.org/<= wbr>doc/html/draft-campbell-oauth-mtls-00>


Abstract:
=C2=A0 =C2=A0This document describes Transport Layer Security (TLS) mutual<= br> =C2=A0 =C2=A0authentication using X.509 certificates as a mechanism for bot= h OAuth
=C2=A0 =C2=A0client authentication to the token endpoint as well as for sen= der
=C2=A0 =C2=A0constrained access to OAuth protected resources.




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

The IETF Secretariat





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


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


--001a11499a58f57032054c948f60-- From nobody Fri Apr 7 07:42:17 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53CD31294C0 for ; Fri, 7 Apr 2017 07:42:15 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ROdsa_jDnjMO for ; Fri, 7 Apr 2017 07:42:11 -0700 (PDT) Received: from mail-wr0-x22d.google.com (mail-wr0-x22d.google.com [IPv6:2a00:1450:400c:c0c::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 1398C1286B2 for ; Fri, 7 Apr 2017 07:42:10 -0700 (PDT) Received: by mail-wr0-x22d.google.com with SMTP id o21so82487411wrb.2 for ; Fri, 07 Apr 2017 07:42:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=LEaAm3L2U5BLsF2ZqvGOysrfOlICJDC1P3GCH3Av+T4=; b=A3OMeazHx3eKOZN7dQkRnfFPsBs5EovzauTYcYh3DehVFhDhwz1yL5zxywzhvdh+k+ SLFXJxrSCypO5zsezTTQaygtdOQTR4as6wCpf4hhmQZfj0LJ5ysVR0PLc3yytxUs768d Ly/T7D2lwAnSTkmMuyD9TG6k308XSr4eJnCGB8iwNtwpJazVVfSQSILRSmUwXGm+EyCA wrrI6w9fyPQz50GMP0w4N18Acj73hh3rNrMeW94FcErzSpocZyL7eywzSu8gKdf5th8o 4QMmVBsoRPFQWmSxguTO0feRyyeCSnL4sRSOyJ0Rlgs0jn2vDWccoUxuwfILRlR1tbSG RxpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=LEaAm3L2U5BLsF2ZqvGOysrfOlICJDC1P3GCH3Av+T4=; b=rM4iXtLqMhHdBJCrR0KfqPJKRdr+5zYIu/ptMh7m8YWOeeO0L/v1L1RdKg6sswOtfO dZE23ee4yFzzkNDQ2YRzSNxjW0gw4C+PEWuVwANojOKJL9HedfRzy9s+Wv8dIxeIK2Yo PB6XLl/2+n4TwRCX2X3v+hbw7LwNndJxV/GFk0ChWfvvS68mA268tt44TFlgUbhjXHWl sZSiNdnffXo/gMPEnwnYt46XyFAnzhZxaF/cpKH/CmcZPrhUw0zYAxwLmbj2CZNOmnmQ RmlfJl1bYzU+I5ykUDaXJoZGCGS60zjupVNHgarAoSuKjrnsxwsdqbHod6BC+/GjHH9A 2eow== X-Gm-Message-State: AFeK/H3+B7GUmMC7/r9i/CP5BlD3UD0k2qJEgt2k8AQ9ZB2+u9dq19DV89U5I55bHFx3Qw== X-Received: by 10.223.142.143 with SMTP id q15mr13935390wrb.180.1491576128215; Fri, 07 Apr 2017 07:42:08 -0700 (PDT) Received: from [10.36.226.98] ([80.169.137.53]) by smtp.googlemail.com with ESMTPSA id y66sm6239643wrb.39.2017.04.07.07.42.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Apr 2017 07:42:07 -0700 (PDT) To: John Bradley References: <149090694651.9027.6337833834024757190.idtracker@ietfa.amsl.com> Cc: Brian Campbell , oauth From: Sergey Beryozkin Message-ID: Date: Fri, 7 Apr 2017 15:42:06 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-mtls-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 14:42:15 -0000 Hi John I spotted it probably after the 10th iteration :-) Cheers, Sergey On 07/04/17 14:54, John Bradley wrote: > It was a test to see who was really reading it:) > > On Fri, Apr 7, 2017 at 1:58 PM, Sergey Beryozkin > wrote: > > Hi Brian > > Thanks, a minor typo in the example, > "x5t#s256" as opposed to "x5t#S256" > > (sorry if it was already reported, might've missed it) > > Cheers, Sergey > On 30/03/17 22:15, Brian Campbell wrote: > > This document, which I hope to present and discuss briefly at > tomorrow's > meeting, replaces (but keeps the feature) the Mutual TLS > Authentication > for OAuth Clients > > > that was published leading up to the Seoul meeting > > > and > adds mutual TLS sender constrained access to OAuth protected > resources. > The concept for the latter was largely derived from one of the > options > in the JPOP draft > >. I > apologize > for the 11th hour publication but hope some folks will have a > chance to > read it. > > ---------- Forwarded message ---------- > From: ** > >> > Date: Thu, Mar 30, 2017 at 3:49 PM > Subject: New Version Notification for > draft-campbell-oauth-mtls-00.txt > To: Brian Campbell > >>, Nat Sakimura > > >>, > Torsten Lodderstedt > > >>, John Bradley > > >> > > > > A new version of I-D, draft-campbell-oauth-mtls-00.txt > has been successfully submitted by Brian Campbell and posted to the > IETF repository. > > Name: draft-campbell-oauth-mtls > Revision: 00 > Title: Mutual TLS Profiles for OAuth Clients > Document date: 2017-03-30 > Group: Individual Submission > Pages: 10 > URL: > https://www.ietf.org/internet-drafts/draft-campbell-oauth-mtls-00.txt > > > > Status: > https://datatracker.ietf.org/doc/draft-campbell-oauth-mtls/ > > > > Htmlized: > https://tools.ietf.org/html/draft-campbell-oauth-mtls-00 > > > > Htmlized: > https://datatracker.ietf.org/doc/html/draft-campbell-oauth-mtls-00 > > > > > > Abstract: > This document describes Transport Layer Security (TLS) mutual > authentication using X.509 certificates as a mechanism for > both OAuth > client authentication to the token endpoint as well as for sender > constrained access to OAuth protected resources. > > > > > Please note that it may take a couple of minutes from the time > of submission > until the htmlized version and diff are available at > tools.ietf.org > . > > The IETF Secretariat > > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > From nobody Fri Apr 7 09:29:20 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11D3E1294F6 for ; Fri, 7 Apr 2017 09:29:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hIQCHjhQf_b3 for ; Fri, 7 Apr 2017 09:29:16 -0700 (PDT) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (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 6F04F12951D for ; Fri, 7 Apr 2017 09:28:37 -0700 (PDT) Received: by mail-lf0-x229.google.com with SMTP id q141so14909838lfe.2 for ; Fri, 07 Apr 2017 09:28:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=s19N5Gg6J6RNVEuAdz/WkT6VHNFYxhqUbhaIk8m+8Rs=; b=gpXJlBknXITX+vzF9AyOuu5gukeSOWW37YRfA652/+930MCFxzbMlsUAlrSbctE+2G Eg5TRfUfF7wCQHXrqCzRt0QafBxWQmB0mQah/soo8+QTi91uC0uuaEoq/+6mh0ZIjbjz U6Imt+VP+/DrTJWFmTZsozJVGnAs1GlQkPySJIJ5Ym7zEGJbGQxBN4rsXUyF7WTTQx+p YTRRS3gDz575CCat3zPsKVtRu1romszjeznyA5+OwL/gvCQE8o0irkvqsU257MbIlizu xGmeTZA5bfaBRrOB6zEfbxr9Zw5Rtj1x24zKz4encTv1lxOwxeyjaRVowNQj+Vgw/Vow JWgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=s19N5Gg6J6RNVEuAdz/WkT6VHNFYxhqUbhaIk8m+8Rs=; b=gy+bPBoFrnm0DGsG+mji1Ne8t2DWpY8Vqhw9RQQZSDue72kjnld7CvrIWc54x+LIo8 jmNt2xEv3IQPgYN3UNn8AS62q6XeUcd4z2Xksfm0H4xb2deb3QVsQa+plx4JwIEoJRQH 3tyaW47Bd6pXlo2J/wdrQAzQhZbP3YtXsRbw4cNmmnhuOGaI1oNuIQaVfT5AnO4Jegqs 4Zl/z4gpjYPc+h+w9yYmELc3apLvMAPIpvgUS6VBPdSnindJinehXEMA3fQ0cKYZ8erK kj44QsoCBlgSfHRkd+VBWpXYk1Dxtf/WAmORG+yOewGYJV5//BjkRGmmjgXFGBulXSQI Gg+Q== X-Gm-Message-State: AFeK/H1+fXjCVYliyfY146bCBcbOhHHg8lB9HyeGUGWhyoE/6c7iwMEmuvYe5uv+L9E7dpn0BbuB5yoj35v7+A== X-Received: by 10.25.217.153 with SMTP id s25mr11690590lfi.8.1491582515572; Fri, 07 Apr 2017 09:28:35 -0700 (PDT) MIME-Version: 1.0 References: <149090694651.9027.6337833834024757190.idtracker@ietfa.amsl.com> In-Reply-To: From: Steve Hutchinson Date: Fri, 07 Apr 2017 16:28:24 +0000 Message-ID: To: John Bradley , Sergey Beryozkin Cc: oauth Content-Type: multipart/alternative; boundary=94eb2c0638f0fe739f054c961db6 Archived-At: Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-mtls-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 16:29:20 -0000 --94eb2c0638f0fe739f054c961db6 Content-Type: text/plain; charset=UTF-8 Every time I think I couldn't be more impressed with the people who do actual standards work, someone raises the bar. Thanks Sergey! Hutch On Fri, Apr 7, 2017 at 10:42 AM Sergey Beryozkin wrote: > Hi John > > I spotted it probably after the 10th iteration :-) > > Cheers, Sergey > On 07/04/17 14:54, John Bradley wrote: > > It was a test to see who was really reading it:) > > > > On Fri, Apr 7, 2017 at 1:58 PM, Sergey Beryozkin > > wrote: > > > > Hi Brian > > > > Thanks, a minor typo in the example, > > "x5t#s256" as opposed to "x5t#S256" > > > > (sorry if it was already reported, might've missed it) > > > > Cheers, Sergey > > On 30/03/17 22:15, Brian Campbell wrote: > > > > This document, which I hope to present and discuss briefly at > > tomorrow's > > meeting, replaces (but keeps the feature) the Mutual TLS > > Authentication > > for OAuth Clients > > < > https://tools.ietf.org/html/draft-campbell-oauth-tls-client-auth-00 > > < > https://tools.ietf.org/html/draft-campbell-oauth-tls-client-auth-00>> > > that was published leading up to the Seoul meeting > > < > https://www.ietf.org/mail-archive/web/oauth/current/msg16704.html > > < > https://www.ietf.org/mail-archive/web/oauth/current/msg16704.html>> > > and > > adds mutual TLS sender constrained access to OAuth protected > > resources. > > The concept for the latter was largely derived from one of the > > options > > in the JPOP draft > > > >. I > > apologize > > for the 11th hour publication but hope some folks will have a > > chance to > > read it. > > > > ---------- Forwarded message ---------- > > From: ** > > > internet-drafts@ietf.org>>> > > Date: Thu, Mar 30, 2017 at 3:49 PM > > Subject: New Version Notification for > > draft-campbell-oauth-mtls-00.txt > > To: Brian Campbell > > > > >>, Nat Sakimura > > > > >>, > > Torsten Lodderstedt > > > > > >>, John Bradley > > > > >> > > > > > > > > A new version of I-D, draft-campbell-oauth-mtls-00.txt > > has been successfully submitted by Brian Campbell and posted to > the > > IETF repository. > > > > Name: draft-campbell-oauth-mtls > > Revision: 00 > > Title: Mutual TLS Profiles for OAuth Clients > > Document date: 2017-03-30 > > Group: Individual Submission > > Pages: 10 > > URL: > > > https://www.ietf.org/internet-drafts/draft-campbell-oauth-mtls-00.txt > > < > https://www.ietf.org/internet-drafts/draft-campbell-oauth-mtls-00.txt> > > < > https://www.ietf.org/internet-drafts/draft-campbell-oauth-mtls-00.txt > > < > https://www.ietf.org/internet-drafts/draft-campbell-oauth-mtls-00.txt>> > > Status: > > https://datatracker.ietf.org/doc/draft-campbell-oauth-mtls/ > > > > > > > > Htmlized: > > https://tools.ietf.org/html/draft-campbell-oauth-mtls-00 > > > > > > > > Htmlized: > > > https://datatracker.ietf.org/doc/html/draft-campbell-oauth-mtls-00 > > < > https://datatracker.ietf.org/doc/html/draft-campbell-oauth-mtls-00> > > < > https://datatracker.ietf.org/doc/html/draft-campbell-oauth-mtls-00 > > < > https://datatracker.ietf.org/doc/html/draft-campbell-oauth-mtls-00>> > > > > > > Abstract: > > This document describes Transport Layer Security (TLS) mutual > > authentication using X.509 certificates as a mechanism for > > both OAuth > > client authentication to the token endpoint as well as for > sender > > constrained access to OAuth protected resources. > > > > > > > > > > Please note that it may take a couple of minutes from the time > > of submission > > until the htmlized version and diff are available at > > tools.ietf.org > > . > > > > The IETF Secretariat > > > > > > > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --94eb2c0638f0fe739f054c961db6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Every time I think I couldn't be more impressed with the people wh= o do actual standards work, someone raises the bar.

Thanks Sergey!

Hutch

On Fri, Apr 7, 2017 at 10:42 AM Sergey Be= ryozkin <sberyozkin@gmail.com> wrote:
Hi John

I spotted it probably after the 10th iteration :-)

Cheers, Sergey
On 07/04/17 14:54, John Bradley wrote:
> It was a test to see who was really reading it:)
>
> On Fri, Apr 7, 2017 at 1:58 PM, Sergey Beryozkin <sberyozkin@gma= il.com
> <mailto:sberyozkin@gmail.com>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0Hi Brian
>
>=C2=A0 =C2=A0 =C2=A0Thanks, a minor typo in the example,
>=C2=A0 =C2=A0 =C2=A0"x5t#s256" as opposed to "x5t#S256&q= uot;
>
>=C2=A0 =C2=A0 =C2=A0(sorry if it was already reported, might've mis= sed it)
>
>=C2=A0 =C2=A0 =C2=A0Cheers, Sergey
>=C2=A0 =C2=A0 =C2=A0On 30/03/17 22:15, Brian Campbell wrote:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0This document, which I hope to presen= t and discuss briefly at
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0tomorrow's
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0meeting, replaces (but keeps the feat= ure) the Mutual TLS
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Authentication
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0for OAuth Clients
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://tools.ietf.org/html/draft-campbell-oau= th-tls-client-auth-00
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://tools.ietf.org/html/draft-campbell-oau= th-tls-client-auth-00>>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0that was published leading up to the = Seoul meeting
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://www.ietf.org/mail-archive/web/oauth/curr= ent/msg16704.html
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://www.ietf.org/mail-archive/web/oauth/curr= ent/msg16704.html>>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0adds mutual TLS sender constrained ac= cess to OAuth protected
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0resources.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The concept for the latter was largel= y derived from one of the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0options
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0in the JPOP draft
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://tools.ietf.org/html/draft-sakimura-oauth-jpop-04<= /a>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://tools.ietf.org/html/draft-sakimura-oauth-jpop-04<= /a>>>. I
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0apologize
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0for the 11th hour publication but hop= e some folks will have a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0chance to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0read it.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0---------- Forwarded message --------= --
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0From: ** <internet-drafts@i= etf.org
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:internet-drafts@iet= f.org>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:internet-drafts@iet= f.org <mailto:internet-drafts@ietf.org>>>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Date: Thu, Mar 30, 2017 at 3:49 PM >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Subject: New Version Notification for=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-campbell-oauth-mtls-00.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0To: Brian Campbell <brian= .d.campbell@gmail.com
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:brian.d.campbell@= gmail.com>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:brian.d.campbell@= gmail.com
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:brian.d.campbell@= gmail.com>>>, Nat Sakimura
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<n-sakimura@nri.co.jp <m= ailto:n-sakimura@nri.co.jp>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:n-sakimura@nri.co.jp <mailto:n-sakimura@nri.co.jp>>>,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Torsten Lodderstedt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<torsten@lodderstedt.net= <mailto:torsten@lodderstedt.net>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:torsten@lodderstedt.= net
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:torsten@lodderstedt.= net>>>, John Bradley
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<ve7jtb@ve7jtb.com <mailto:= = ve7jtb@ve7jtb.com>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:ve7jtb@ve7jtb.com <= mailto:ve7jtb@ve7jtb.com>>>
>
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0A new version of I-D, draft-campbell-= oauth-mtls-00.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0has been successfully submitted by Br= ian Campbell and posted to the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0IETF repository.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0draft-campbell-oauth-mtls
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A00= 0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 Mutual TLS Profiles for OAuth Clients
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Document date:=C2=A0 2017-03-30
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 Individual Submission
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 10
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0URL:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/internet-drafts/draft-campb= ell-oauth-mtls-00.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://www.ietf.org/internet-drafts/draft= -campbell-oauth-mtls-00.txt>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://www.ietf.org/internet-drafts/draft= -campbell-oauth-mtls-00.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://www.ietf.org/internet-drafts/draft= -campbell-oauth-mtls-00.txt>>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Status:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://datatracker.ietf.org/doc/draft-campbell-oauth-mtl= s/
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://datatracker.ietf.org/doc/draft-campbell-oauth-= mtls/>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://datatracker.ietf.org/doc/draft-campbell-oauth-= mtls/
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://datatracker.ietf.org/doc/draft-campbell-oauth-= mtls/>>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Htmlized:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://tools.ietf.org/html/draft-campbell-oauth-mtls-00=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://tools.ietf.org/html/draft-campbell-oauth-mtls-00<= /a>>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://tools.ietf.org/html/draft-campbell-oauth-mtls-00<= /a>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://tools.ietf.org/html/draft-campbell-oauth-mtls-00<= /a>>>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Htmlized:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://datatracker.ietf.org/doc/html/draft-campbe= ll-oauth-mtls-00
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://datatracker.ietf.org/doc/html/draft-cam= pbell-oauth-mtls-00>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://datatracker.ietf.org/doc/html/draft-cam= pbell-oauth-mtls-00
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://datatracker.ietf.org/doc/html/draft-cam= pbell-oauth-mtls-00>>
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Abstract:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 This document describes Trans= port Layer Security (TLS) mutual
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 authentication using X.509 ce= rtificates as a mechanism for
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0both OAuth
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 client authentication to the = token endpoint as well as for sender
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 constrained access to OAuth p= rotected resources.
>
>
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Please note that it may take a couple= of minutes from the time
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0of submission
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0until the htmlized version and diff a= re available at
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0tools.ietf.org &l= t;http://tools.ietf.org>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<http://tools.ietf= .org>.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The IETF Secretariat
>
>
>
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0_____________________________________= __________
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0OAuth mailing list
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0OAuth@ietf.org <mailto:OAuth@ietf.or= g>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/listinfo/oauth
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://www.ietf.org/mailman/listinfo/oauth>
>
>
>=C2=A0 =C2=A0 =C2=A0_______________________________________________
>=C2=A0 =C2=A0 =C2=A0OAuth mailing list
>=C2=A0 =C2=A0 =C2=A0OAuth@ietf.org <mailto:OAuth@ietf.org>
>=C2=A0 =C2=A0 =C2=A0https://www.i= etf.org/mailman/listinfo/oauth
>=C2=A0 =C2=A0 =C2=A0<https://w= ww.ietf.org/mailman/listinfo/oauth>
>
>

_______________________________________________
OAuth mailing list
OAu= th@ietf.org
https://www.ietf.org/mailman/listinfo= /oauth
--94eb2c0638f0fe739f054c961db6-- From nobody Fri Apr 7 13:51:40 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E81C127869 for ; Fri, 7 Apr 2017 13:51:39 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DzNIk4a8OcKK for ; Fri, 7 Apr 2017 13:51:36 -0700 (PDT) Received: from mail-wr0-x235.google.com (mail-wr0-x235.google.com [IPv6:2a00:1450:400c:c0c::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 20D9B127866 for ; Fri, 7 Apr 2017 13:51:36 -0700 (PDT) Received: by mail-wr0-x235.google.com with SMTP id t20so116454904wra.1 for ; Fri, 07 Apr 2017 13:51:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=uXhBjOBDM6KVyipRsQ6iplinvv3GcjbrU7qAfN3twyk=; b=eHn7skuPVOpWmLGXmK+Pnpu8IGwhZi3HVFZiBfyWtU2DsFWDwI0Cmt44+AC4F95r9x HlaVRv0jxEuqihTIxRhqzTIDKi6DU/ICSZMFzt741v/CXcGof4IfeFhrthshlVRzgQdl pTrX2GVFEG+tPmQ3wW4+U8U7FR7zktgYYEfuPJ/S11Ee42APyaoZoJBt5IINHzAtMxe/ de7Qq7d8m0XA4/2yUwbD+a/L1eDOKGuTyZrXSgddzIm+5QkJre3icbr3zFC5ZmVwSbrf pzZTrr8CUgZUjYSMJY4LO4wlWhU0S+BkYYxwwdA+7k2iT1GVdQytjSH3pGLxqXk0Ey9+ U/OA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=uXhBjOBDM6KVyipRsQ6iplinvv3GcjbrU7qAfN3twyk=; b=FBGctoyKskXkO5p7T93FQhpI0w8J+V9WnKBo4RQcRceRa9HVLzjUJaloaOO4oxs+0x 0+kUQ0E+WccztLpi2oJ4vE29ryzAFSWR8thHAi83p/XuiApZG2g9ZQWVRWGIYS17Ll3N p/brkh6QdZOph8RtgTd5oxDGSQMlvIYPFn3a85s8xh+Q88neyvF798Ysl783CVvjEOTd D9NkhNr6ygb+UiDEozd7qW6LeDABb9r7yvQt1vVdq3ffktv4s2633CUk0Q3jebMNrx+w XXcC1yZOSSxPr2GTmDWh/okjKBqYCz1JEt6FCBOHhC6yC2bF13VdJgGhhnd6QsD36cxc GtKg== X-Gm-Message-State: AFeK/H2taDdfx+qX48xTsnAa8LE8Ce5gOng0sZZQq4MAx/t08YfcJvqsVKH3Pl+X1TGu+w== X-Received: by 10.223.164.83 with SMTP id e19mr38537331wra.154.1491598294595; Fri, 07 Apr 2017 13:51:34 -0700 (PDT) Received: from [192.168.2.7] ([46.7.75.128]) by smtp.googlemail.com with ESMTPSA id 186sm195142wml.2.2017.04.07.13.51.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Apr 2017 13:51:32 -0700 (PDT) To: Steve Hutchinson , John Bradley References: <149090694651.9027.6337833834024757190.idtracker@ietfa.amsl.com> Cc: oauth From: Sergey Beryozkin Message-ID: Date: Fri, 7 Apr 2017 21:51:17 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-mtls-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 20:51:39 -0000 Hi All I'm starting really believing now doing OAuth2 is as simple as spotting a difference between 'S' and 's' :-) Thanks, Sergey On 07/04/17 17:28, Steve Hutchinson wrote: > Every time I think I couldn't be more impressed with the people who do > actual standards work, someone raises the bar. > > Thanks Sergey! > > Hutch > > > On Fri, Apr 7, 2017 at 10:42 AM Sergey Beryozkin > wrote: > > Hi John > > I spotted it probably after the 10th iteration :-) > > Cheers, Sergey > On 07/04/17 14:54, John Bradley wrote: > > It was a test to see who was really reading it:) > > > > On Fri, Apr 7, 2017 at 1:58 PM, Sergey Beryozkin > > > >> wrote: > > > > Hi Brian > > > > Thanks, a minor typo in the example, > > "x5t#s256" as opposed to "x5t#S256" > > > > (sorry if it was already reported, might've missed it) > > > > Cheers, Sergey > > On 30/03/17 22:15, Brian Campbell wrote: > > > > This document, which I hope to present and discuss briefly at > > tomorrow's > > meeting, replaces (but keeps the feature) the Mutual TLS > > Authentication > > for OAuth Clients > > > > > > > > that was published leading up to the Seoul meeting > > > > > > > > and > > adds mutual TLS sender constrained access to OAuth protected > > resources. > > The concept for the latter was largely derived from one of the > > options > > in the JPOP draft > > > >. I > > apologize > > for the 11th hour publication but hope some folks will have a > > chance to > > read it. > > > > ---------- Forwarded message ---------- > > From: ** > > > > > >>> > > Date: Thu, Mar 30, 2017 at 3:49 PM > > Subject: New Version Notification for > > draft-campbell-oauth-mtls-00.txt > > To: Brian Campbell > > > > > > > >>>, Nat Sakimura > > > > > > > >>>, > > Torsten Lodderstedt > > > > > > > > >>>, John Bradley > > > > > > > >>> > > > > > > > > A new version of I-D, draft-campbell-oauth-mtls-00.txt > > has been successfully submitted by Brian Campbell and > posted to the > > IETF repository. > > > > Name: draft-campbell-oauth-mtls > > Revision: 00 > > Title: Mutual TLS Profiles for OAuth Clients > > Document date: 2017-03-30 > > Group: Individual Submission > > Pages: 10 > > URL: > > > https://www.ietf.org/internet-drafts/draft-campbell-oauth-mtls-00.txt > > > > > > > > > > > Status: > > https://datatracker.ietf.org/doc/draft-campbell-oauth-mtls/ > > > > > > > > Htmlized: > > https://tools.ietf.org/html/draft-campbell-oauth-mtls-00 > > > > > > > > Htmlized: > > > https://datatracker.ietf.org/doc/html/draft-campbell-oauth-mtls-00 > > > > > > > > > > > > > > > Abstract: > > This document describes Transport Layer Security (TLS) > mutual > > authentication using X.509 certificates as a mechanism for > > both OAuth > > client authentication to the token endpoint as well as > for sender > > constrained access to OAuth protected resources. > > > > > > > > > > Please note that it may take a couple of minutes from the time > > of submission > > until the htmlized version and diff are available at > > tools.ietf.org > > . > > > > The IETF Secretariat > > > > > > > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From nobody Mon Apr 10 04:02:19 2017 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C082129478 for ; Mon, 10 Apr 2017 04:02:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149182213830.3200.9363194015088777422.idtracker@ietfa.amsl.com> Date: Mon, 10 Apr 2017 04:02:18 -0700 From: IETF Secretariat Archived-At: Subject: [OAUTH-WG] Milestones changed for oauth WG X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 11:02:18 -0000 Changed milestone "Submit 'OAuth 2.0 Authorization Server Discovery Metadata' to the IESG", resolved as "Done". URL: https://datatracker.ietf.org/wg/oauth/about/ From nobody Mon Apr 10 05:40:37 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3C6A128959 for ; Mon, 10 Apr 2017 05:40:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ayws3YGWNfdR for ; Mon, 10 Apr 2017 05:40:33 -0700 (PDT) Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C41E12940D for ; Mon, 10 Apr 2017 05:40:33 -0700 (PDT) Received: by mail-pf0-x22b.google.com with SMTP id c198so21722872pfc.1 for ; Mon, 10 Apr 2017 05:40:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=bQi2jkOw/qA/h5KCuvb2qRaAAlavHXdCx7KUvNUGL1Q=; b=YL7igDo653I8vBc8YilTsVd407WyAz/5Z/v5DStLdIlmo9O8L5r4NA6hdURFaYzBOn e6DAnMf3hr6P44fVWVtNNs2mviOM8mqZPot1ZecURFQuJEjRExcJkN3YQIjiBuvIAunO IfM72aWjGIWfVqRy5fnCE78X4App8o0ABjUu8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=bQi2jkOw/qA/h5KCuvb2qRaAAlavHXdCx7KUvNUGL1Q=; b=nVBR8OH6Y32XQLPxlTIWAQO/UvnQhiV047SOcIpVvbmCBvXHwr/798o4h+4ljMf1iq TCMXpBP27Q33Qe4wazAETciTq6dfhsPCv8BlLkWHRn7Cv++EL3i5dZEIfTpQXsU/1scE +MdSRruo1AusUBKi6nxvW8+GKsKqfetyvAppBYWaO11M4sPWczV2CgvO7PXpsDqxIRJ9 GNJFpRpEqFikvEx4rss/Q1m6sMAKRWmkqJ7xmlvHIL8iT6HEReoOpMGercCI0hlYU2f+ 1b5BBf4t6sHETOOKIVbt3WQ+DEKSMSFZ4ySImHfn+T1X3PSQcSDkvSCeb49G7guDqglE tqCg== X-Gm-Message-State: AFeK/H3IGg/6YfsdfJdMVGp50HHFrHBHesmfUmET6agw8/X1BiXa9yDRvJ1XEEbQ8Zg7a9+1f9iSitpoVkAAY39M X-Received: by 10.99.112.18 with SMTP id l18mr56191506pgc.142.1491828032649; Mon, 10 Apr 2017 05:40:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.155.9 with HTTP; Mon, 10 Apr 2017 05:40:02 -0700 (PDT) In-Reply-To: References: <149182782785.3176.276412643903148951.idtracker@ietfa.amsl.com> From: Brian Campbell Date: Mon, 10 Apr 2017 06:40:02 -0600 Message-ID: To: oauth Content-Type: multipart/alternative; boundary=f403045c7b0af3d61c054ccf47e9 Archived-At: Subject: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-mtls-01.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 12:40:35 -0000 --f403045c7b0af3d61c054ccf47e9 Content-Type: text/plain; charset=UTF-8 -01 just fixes a couple typos and adds a few people to the Acknowledgements. ---------- Forwarded message ---------- From: Date: Mon, Apr 10, 2017 at 6:37 AM Subject: New Version Notification for draft-campbell-oauth-mtls-01.txt To:<...> A new version of I-D, draft-campbell-oauth-mtls-01.txt has been successfully submitted by Brian Campbell and posted to the IETF repository. Name: draft-campbell-oauth-mtls Revision: 01 Title: Mutual TLS Profiles for OAuth Clients Document date: 2017-04-10 Group: Individual Submission Pages: 10 URL: https://www.ietf.org/internet-drafts/draft-campbell-oauth-mt ls-01.txt Status: https://datatracker.ietf.org/doc/draft-campbell-oauth-mtls/ Htmlized: https://tools.ietf.org/html/draft-campbell-oauth-mtls-01 Htmlized: https://datatracker.ietf.org/doc/html/draft-campbell-oauth- mtls-01 Diff: https://www.ietf.org/rfcdiff?url2=draft-campbell-oauth-mtls -01 Abstract: This document describes Transport Layer Security (TLS) mutual authentication using X.509 certificates as a mechanism for both OAuth client authentication to the token endpoint as well as for sender constrained access to OAuth protected resources. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --f403045c7b0af3d61c054ccf47e9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
-01 just fixes a couple typos and adds a few people to the= Acknowledgements.


---------- Forwarded message ----------
= From: <internet-drafts@ietf.org<= /a>>
Date: Mon, Apr 10, 2017 at 6:37 AM
Subject: New Versio= n Notification for draft-campbell-oauth-mtls-01.txt
To:<...><= br>

A new version of I-D, draft-campbell-oauth-mtls-01.txt
has been successfully submitted by Brian Campbell and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-campbell-oauth-mtls
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A001
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Mutual TLS Profiles for OAuth Clie= nts
Document date:=C2=A0 2017-04-10
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 10
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-campbell-oau= th-mtls-01.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= https://datatracker.ietf.org/doc/draft-campbell-oauth-mtls/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://= tools.ietf.org/html/draft-campbell-oauth-mtls-01
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-campbell-oauth-mtls= -01
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-campbell-oauth-m= tls-01

Abstract:
=C2=A0 =C2=A0This document describes Transport Layer Security (TLS) mutual<= br> =C2=A0 =C2=A0authentication using X.509 certificates as a mechanism for bot= h OAuth
=C2=A0 =C2=A0client authentication to the token endpoint as well as for sen= der
=C2=A0 =C2=A0constrained access to OAuth protected resources.




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

The IETF Secretariat



--f403045c7b0af3d61c054ccf47e9-- From nobody Mon Apr 10 10:47:25 2017 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C68F2129AB3; Mon, 10 Apr 2017 10:47:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , draft-ietf-oauth-amr-values@ietf.org, oauth@ietf.org, Kathleen.Moriarty.ietf@gmail.com, Hannes Tschofenig , Hannes.Tschofenig@gmx.net, oauth-chairs@ietf.org, rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Message-ID: <149184642980.3056.4025326913736470102.idtracker@ietfa.amsl.com> Date: Mon, 10 Apr 2017 10:47:09 -0700 Archived-At: Subject: [OAUTH-WG] Protocol Action: 'Authentication Method Reference Values' to Proposed Standard (draft-ietf-oauth-amr-values-08.txt) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 17:47:10 -0000 The IESG has approved the following document: - 'Authentication Method Reference Values' (draft-ietf-oauth-amr-values-08.txt) as Proposed Standard This document is the product of the Web Authorization Protocol Working Group. The IESG contact persons are Kathleen Moriarty and Eric Rescorla. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-amr-values/ Technical Summary The "amr" (Authentication Methods References) claim is defined and registered in the IANA "JSON Web Token Claims" registry but no standard Authentication Method Reference values are currently defined. This specification establishes a registry for Authentication Method Reference values and defines an initial set of Authentication Method Reference values. Working Group Summary The working group had solid consensus, no issues. Document Quality A number of implementations exist and include: Implementations of the OpenID Mobile Authentication Profile, which is defined by the MODRNA working group, use “amr” values. This includes all the GSMA Mobile Connect deployments. Microsoft Azure Active Directory and Microsoft Active Directory Federation Services (ADFS) use “amr” values. Google’s identity provider uses “amr” values. There is one downref noted in the shepherd report and last call announcement: The following document is a non-IETF document that may require a downward reference: [OpenID.Core] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, "OpenID Connect Core 1.0", November 2014, . Personnel Hannes Tschofenig is the document shepherd and the responsible area director is Kathleen Moriarty. If the document requires IANA experts(s), insert 'The IANA Expert(s) for the registries in this document are John Bradley, Brian Campbell, Michael B. Jones, and Chuck Mortimore. The DEs match that of the IANA "JSON Web Token Claims" registry [IANA.JWT.Claims] IANA Note The document creates a new registry for Authentication Method Reference (AMR) values and populates the registry with an initial set of values. Values are registered on an Expert Review [RFC5226] basis after a three-week review period on the jwt-reg-review@ietf.org mailing list, on the advice of one or more Designated Experts. From nobody Wed Apr 12 09:50:54 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76DFA131799 for ; Wed, 12 Apr 2017 09:50:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OIpRNoAuNF0s for ; Wed, 12 Apr 2017 09:50:51 -0700 (PDT) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::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 55546131794 for ; Wed, 12 Apr 2017 09:50:48 -0700 (PDT) Received: by mail-yw0-x22a.google.com with SMTP id j9so14620934ywj.3 for ; Wed, 12 Apr 2017 09:50:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zrBnJs/Fkc5hTpA3yp+xq7qUsm3Egakl94WRxmsVzI8=; b=Y6Dz63VT9D4rdQSNmItCpeRmjhPZJWBkyubwe/FeX/nOzHXBjfWMeh195h0101HVnb 6/9mxluVwOV7jdxGuPjeY+4f1GvC01Lkw7egx+Q4TOkuLDM9Uqcg13+xEXWD9q99tavq klqzjH0wJuwGJNf9Hz25ag+s4U3vhw6IWDwj602bi461eMnJRePacLHZTH7C2rwoCKVe vNldAzmacCXf9g9/vZOFddSPk98k3bDkCZ0rNIPfXcjZ1TNJajbxEIGsn1XRLeTYNXBj o1HErlyYtShCTC0xoU2ryg5pvMDoue99pvktEtwDhXtQYhIG+LI2L6SkYgeqYGkVkzcx pWpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=zrBnJs/Fkc5hTpA3yp+xq7qUsm3Egakl94WRxmsVzI8=; b=WbVaniTzuO+2sMTPDFLWVvz9nCnyp33VeGQFdkZBADeaKALcvx3iOzH7ETN8sA7PrD RDzujOfZK6efIiqfr/B1FVIgwhm6S+DqvE7Y3zZbCGv15VY9g8xPSWbN9uFrJudXoh1j UXDft6TGJvoho6286xq+bVMG3Qx24bGrPRIGknA6Pwqe6M5MO5qyaTpMrApvlekOY8oE kRqDhanxmbcRxdfxUWVOBnh87iaGQk/Cepd/0XKUgExJteUeUq+WKvst/V/c4F8sIkXp /KxmaNomnUD7TzX/Tl9S+qeM5K2gbZqZHPTri8wON+W9XtYFXRuyl8Bvx8RC9PL9ZbId 3uVw== X-Gm-Message-State: AFeK/H28dR5gqCvov0iQK5k+E5Ze0pO1UpXsb/e4TTuQPe+zznC2W1p0ypLCx46rp6YNAlTjl+BTjmhnKMqJ9g== X-Received: by 10.129.125.5 with SMTP id y5mr43349022ywc.120.1492015847610; Wed, 12 Apr 2017 09:50:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.113.7 with HTTP; Wed, 12 Apr 2017 09:50:07 -0700 (PDT) In-Reply-To: References: <0b495b42-50a8-62da-499a-351fdd2eada3@gmx.net> From: Eric Rescorla Date: Wed, 12 Apr 2017 09:50:07 -0700 Message-ID: To: Derek Atkins Cc: Hannes Tschofenig , "oauth@ietf.org" Content-Type: multipart/alternative; boundary=001a1149364498b672054cfb0271 Archived-At: Subject: Re: [OAUTH-WG] Chair volunteers X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 16:50:53 -0000 --001a1149364498b672054cfb0271 Content-Type: text/plain; charset=UTF-8 I am pleased to (somewhat belatedly) announce that Rifaat Shekh-Yusef has agreed to serve as chair. Thanks to Derek for his service and Rifaat for being willing to step up! -Ekr On Thu, Mar 30, 2017 at 8:03 AM, Derek Atkins wrote: > Hi everyone, > > Hannes Tschofenig writes: > > > On 03/21/2017 06:39 PM, Kathleen Moriarty wrote: > >> A big thank you to Derek for his work in OAuth and we hope to have his > >> continued participation in the working group! > > > > Big thanks to Derek for doing the job for such a long time. It has been > > a pleasure to work with you! > > I must apologize for having effectively disappeared from the OAuth > group; my current position has limited my ability to do IETF work, and > lately I've had even less time to put in, and alas OAuth was a major > casualty. I do plan to continue my involvement to the best of my ability. > > I encourage people to step up and volunteer to co-chair the group. > > > Ciao > > Hannes > > -derek > > -- > Derek Atkins 617-623-3745 > derek@ihtfp.com www.ihtfp.com > Computer and Internet Security Consultant > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --001a1149364498b672054cfb0271 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I am pleased to (somewhat belatedly) announce that=C2=A0Rifaat Shekh-Yusef has agreed to
= serve as chair. Thanks to Derek for his se= rvice and Rifaat for being willing to step up!

-Ekr

<= /div>

On Thu, Mar = 30, 2017 at 8:03 AM, Derek Atkins <derek@ihtfp.com> wrote:
=
Hi everyone,

Hannes Tschofenig <hannes.t= schofenig@gmx.net> writes:

> On 03/21/2017 06:39 PM, Kathleen Moriarty wrote:
>> A big thank you to Derek for his work in OAuth and we hope to have= his
>> continued participation in the working group!
>
> Big thanks to Derek for doing the job for such a long time. It has bee= n
> a pleasure to work with you!

I must apologize for having effectively disappeared from the OAuth group; my current position has limited my ability to do IETF work, and
lately I've had even less time to put in, and alas OAuth was a major casualty.=C2=A0 I do plan to continue my involvement to the best of my abil= ity.

I encourage people to step up and volunteer to co-chair the group.

> Ciao
> Hannes

-derek

--
=C2=A0 =C2=A0 =C2=A0 =C2=A0Derek Atkins=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0617-623-3745
=C2=A0 =C2=A0 =C2=A0 =C2=A0derek@ihtfp.c= om=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0www.ihtfp.com
=C2=A0 =C2=A0 =C2=A0 =C2=A0Computer and Internet Security Consultant

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

--001a1149364498b672054cfb0271-- From nobody Wed Apr 12 12:19:06 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 106E112957F for ; Wed, 12 Apr 2017 12:19:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e2DILPWyhl2o for ; Wed, 12 Apr 2017 12:19:03 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 766B4127077 for ; Wed, 12 Apr 2017 12:19:03 -0700 (PDT) X-AuditID: 1209190f-64bff7000000706b-ee-58ee7da45885 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 32.7F.28779.4AD7EE85; Wed, 12 Apr 2017 15:19:00 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id v3CJIxTC019479 for ; Wed, 12 Apr 2017 15:19:00 -0400 Received: from artemisia.richer.local (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v3CJIvuw010135 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 12 Apr 2017 15:18:59 -0400 From: Justin Richer Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 12 Apr 2017 15:18:57 -0400 References: <84F3FF68-9020-402E-B0AF-4F28ADBD377C@mit.edu> To: "" In-Reply-To: <84F3FF68-9020-402E-B0AF-4F28ADBD377C@mit.edu> Message-Id: <93A646E7-076B-4101-BC3F-A1D56BB1D6F7@mit.edu> X-Mailer: Apple Mail (2.3273) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPIsWRmVeSWpSXmKPExsUixG6nrruk9l2Eweo1chYn375ic2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxua1rYwFV9gqvh1/ydzAeIS1i5GTQ0LAROJL4wKmLkYuDiGB NiaJ19e3skE4xxglXs5YApX5xiSx8FMTC0gLm4CqxPQ1LUwgNrOAusSfeZeYIWxtiWULXwPZ HBy8AvoSvc8ZQcLCAtYSG6fNYQEJswC1vl9nChIWErCSuNt7FaxEBGjKmvM/wSZyApVf2Pqc DWKKlcSG5TIQd8pK3Jp9iXkCI/8sJHtnIdk7C2HvAkbmVYyyKblVurmJmTnFqcm6xcmJeXmp RbomermZJXqpKaWbGEFhxynJv4NxToP3IUYBDkYlHt4C6XcRQqyJZcWVuYcYJTmYlER5Lyu8 jRDiS8pPqcxILM6ILyrNSS0+xCjBwawkwitTAVTOm5JYWZValA+TkuZgURLnFddojBASSE8s Sc1OTS1ILYLJynBwKEnwBtcANQoWpaanVqRl5pQgpJk4OEGG8wANDwOp4S0uSMwtzkyHyJ9i 1OWYc+/reyYhlrz8vFQpcd4L1UBFAiBFGaV5cHNA6SLh7WHTV4ziQG8J86aBjOIBphq4Sa+A ljABLVm79y3IkpJEhJRUA+MeaaE7m+U5Z60yEzZeb3lJbtbn+e+sVitdrHvbfsvU4ECYe/cu D11r3z2mRYd5lodK9HdIL3+/vzVy57yAe34M81fPej/j2eTEqMuPprob5cS+C3M/6VVm1iVf cXCvjCjjlh1l71oWmdVmf/D9Iz/78wr9va3P/3Y2zhY+/nRB8iS1LZKKEaFKLMUZiYZazEXF iQBjU/yl8gIAAA== Archived-At: Subject: Re: [OAUTH-WG] Error Responses in Device Code Spec X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 19:19:05 -0000 Raising this point again. We=E2=80=99ve got a use case where people are = wanting to do custom error codes from the device endpoint and would like = the spec to have clear guidance. At the moment, it doesn=E2=80=99t even = have examples for errors from the device endpoint. =E2=80=94 Justin > On Mar 15, 2017, at 12:33 PM, Justin Richer wrote: >=20 > Unless I=E2=80=99m missing something, the current device code spec = doesn=E2=80=99t specify errors from the device code endpoint, only from = the token endpoint. What are people implementing in practice? We=E2=80=99r= e using token endpoint style errors (invalid_client, inavlid_grant_type, = etc). >=20 > =E2=80=94 Justin > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Wed Apr 12 13:20:22 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FBFA12EAA4 for ; Wed, 12 Apr 2017 13:20:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 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_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wLMPU4b8uqyb for ; Wed, 12 Apr 2017 13:20:03 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0127.outbound.protection.outlook.com [104.47.42.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97214129A99 for ; Wed, 12 Apr 2017 13:20:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=IZsoCHBzFnI2lfQQCK3eZDJtXDy/7bkbdyXQOxUnsac=; b=Mm1jS8TYPrrhTDXdB5+2fZ2aA0XGNxwb3N0DtxRawcXyZOOU/qv5xLLQdhbAwK7JAETn1HgzJcFUlYcaga+5ri5QM12OkvP9+lI+FwwOinGwwj2nvB7DKkjeUI+sZNFzsokAo5BPCV/KpwVFES0tEyktePGqjx/xz8+jJvM41kY= Received: from CY4PR21MB0504.namprd21.prod.outlook.com (10.172.122.14) by CY4PR21MB0501.namprd21.prod.outlook.com (10.172.122.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.1; Wed, 12 Apr 2017 20:20:02 +0000 Received: from CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) by CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) with mapi id 15.01.1034.012; Wed, 12 Apr 2017 20:20:02 +0000 From: Mike Jones To: Justin Richer , "" Thread-Topic: [OAUTH-WG] Error Responses in Device Code Spec Thread-Index: AQHSnaoNKw4KL6LY5EqBEteIUeS0M6HCR++AgAAQ1BA= Date: Wed, 12 Apr 2017 20:20:02 +0000 Message-ID: References: <84F3FF68-9020-402E-B0AF-4F28ADBD377C@mit.edu> <93A646E7-076B-4101-BC3F-A1D56BB1D6F7@mit.edu> In-Reply-To: <93A646E7-076B-4101-BC3F-A1D56BB1D6F7@mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Ref=https://api.informationprotection.azure.com/api/72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetBy=mbj@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2017-04-12T13:20:01.3925297-07:00; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General authentication-results: mit.edu; dkim=none (message not signed) header.d=none;mit.edu; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:c::36] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0501; 7:FIxsQ2DwGAXS58ULRaiRYZKmzG6vCnL8CzHE1QkHrqaYiP4/s9IIBLN5iiJHhNmKW7mL8cgAyqUjWHqhpD4Gdx/gfpYW7RQUwt21KdG21THB2TfRMkuxzaKJ44+vu91zWR+KYzEUiCJ/M/g4YIf1GvSAl7hjH1flXqG2/Qjn6PDiApSw4mj8pnkh+BcbvWLOLnhP31waGgV53zwv03r2VCiz6VrYGpIRzpvQ4hrWl2Xi/1KUyg14yIk/6e1qs9ZrHU9P7Smj8H86e0/TtrC0scdeeUKaSh+MsmczNBODiUQk+z8BZH6Y3lJx6M0yk2ZTMiUNcWl1K9nFmauVeMdwGMGPA7Ymyy7NsCRtzxgSxI8= x-ms-office365-filtering-correlation-id: f6364038-ed2b-47bb-da83-08d481e14d06 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:CY4PR21MB0501; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123560025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(20161123562025)(20161123555025)(6072148); SRVR:CY4PR21MB0501; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0501; x-forefront-prvs: 027578BB13 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39400400002)(39850400002)(39410400002)(39450400003)(39860400002)(39840400002)(13464003)(24454002)(377454003)(2950100002)(53936002)(25786009)(2900100001)(10090500001)(74316002)(102836003)(6116002)(77096006)(99286003)(9686003)(6306002)(2906002)(7696004)(8936002)(5660300001)(53546009)(2171002)(86612001)(86362001)(33656002)(229853002)(6506006)(8676002)(55016002)(81166006)(122556002)(38730400002)(6436002)(3280700002)(6246003)(5005710100001)(10290500002)(3660700001)(305945005)(189998001)(50986999)(76176999)(54356999); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0501; H:CY4PR21MB0504.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Apr 2017 20:20:02.4580 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0501 Archived-At: Subject: Re: [OAUTH-WG] Error Responses in Device Code Spec X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 20:20:05 -0000 SXQgc2VlbXMgcmVhc29uYWJsZSB0byBoYXZlIHRoZSBzcGVjIHNheSB0aGF0IFRva2VuIEVuZHBv aW50IGVycm9ycyBjYW4gYWxzbyBiZSByZXR1cm5lZCBmcm9tIHRoZSBEZXZpY2UgRW5kcG9pbnQu DQoNCgkJCQktLSBNaWtlDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBPQXV0 aCBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKdXN0aW4gUmlj aGVyDQpTZW50OiBXZWRuZXNkYXksIEFwcmlsIDEyLCAyMDE3IDEyOjE5IFBNDQpUbzogPG9hdXRo QGlldGYub3JnPiA8b2F1dGhAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBFcnJv ciBSZXNwb25zZXMgaW4gRGV2aWNlIENvZGUgU3BlYw0KDQpSYWlzaW5nIHRoaXMgcG9pbnQgYWdh aW4uIFdl4oCZdmUgZ290IGEgdXNlIGNhc2Ugd2hlcmUgcGVvcGxlIGFyZSB3YW50aW5nIHRvIGRv IGN1c3RvbSBlcnJvciBjb2RlcyBmcm9tIHRoZSBkZXZpY2UgZW5kcG9pbnQgYW5kIHdvdWxkIGxp a2UgdGhlIHNwZWMgdG8gaGF2ZSBjbGVhciBndWlkYW5jZS4gQXQgdGhlIG1vbWVudCwgaXQgZG9l c27igJl0IGV2ZW4gaGF2ZSBleGFtcGxlcyBmb3IgZXJyb3JzIGZyb20gdGhlIGRldmljZSBlbmRw b2ludC4NCg0KIOKAlCBKdXN0aW4NCg0KPiBPbiBNYXIgMTUsIDIwMTcsIGF0IDEyOjMzIFBNLCBK dXN0aW4gUmljaGVyIDxqcmljaGVyQE1JVC5FRFU+IHdyb3RlOg0KPiANCj4gVW5sZXNzIEnigJlt IG1pc3Npbmcgc29tZXRoaW5nLCB0aGUgY3VycmVudCBkZXZpY2UgY29kZSBzcGVjIGRvZXNu4oCZ dCBzcGVjaWZ5IGVycm9ycyBmcm9tIHRoZSBkZXZpY2UgY29kZSBlbmRwb2ludCwgb25seSBmcm9t IHRoZSB0b2tlbiBlbmRwb2ludC4gV2hhdCBhcmUgcGVvcGxlIGltcGxlbWVudGluZyBpbiBwcmFj dGljZT8gV2XigJlyZSB1c2luZyB0b2tlbiBlbmRwb2ludCBzdHlsZSBlcnJvcnMgKGludmFsaWRf Y2xpZW50LCBpbmF2bGlkX2dyYW50X3R5cGUsIGV0YykuDQo+IA0KPiDigJQgSnVzdGluDQo+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IE9BdXRoIG1h aWxpbmcgbGlzdA0KPiBPQXV0aEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL29hdXRoDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnDQpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQo= From nobody Wed Apr 12 13:57:42 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2252129ACC for ; Wed, 12 Apr 2017 13:57:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NzPEZrOF2rOy for ; Wed, 12 Apr 2017 13:57:34 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (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 327031273B1 for ; Wed, 12 Apr 2017 13:57:34 -0700 (PDT) X-AuditID: 1209190e-19fff70000001836-ba-58ee94bb8e6d Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 77.5F.06198.BB49EE85; Wed, 12 Apr 2017 16:57:33 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id v3CKvUhO027145; Wed, 12 Apr 2017 16:57:31 -0400 Received: from artemisia.richer.local (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v3CKvSxt000796 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 12 Apr 2017 16:57:29 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Justin Richer In-Reply-To: Date: Wed, 12 Apr 2017 16:57:28 -0400 Cc: "" Content-Transfer-Encoding: quoted-printable Message-Id: <845E3F04-D851-4E9E-B296-2F840C874FAE@mit.edu> References: <84F3FF68-9020-402E-B0AF-4F28ADBD377C@mit.edu> <93A646E7-076B-4101-BC3F-A1D56BB1D6F7@mit.edu> To: Mike Jones X-Mailer: Apple Mail (2.3273) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFIsWRmVeSWpSXmKPExsUixCmqrLt3yrsIg+lT2Sz2TvvEYnHy7Ss2 ByaPJUt+Mnm07vjLHsAUxWWTkpqTWZZapG+XwJXx7dEfxoI7PBWPOzqZGhiPcHUxcnJICJhI zG77xtTFyMUhJNDGJPFoXRszhLORUWLy3jcsEM5DJol7J24zgbQwC6hL/Jl3CaiKg4NXQF+i 9zkjSFhYwFpi47Q5LCA2m4CqxPQ1LWDlnAKxEg/nPWAFsVmA4sf6+5lAWkHGtJ90gZioLbFs 4WuoiVYSk2+KQGzdxyhxb+9SsDEiAjoSjy9+Y4M4Wlbi1uxLzBMYBWYhOWgWwkGzkExdwMi8 ilE2JbdKNzcxM6c4NVm3ODkxLy+1SNdYLzezRC81pXQTIzhIJfl2ME5q8D7EKMDBqMTDWyD9 LkKINbGsuDL3EKMkB5OSKO9lhbcRQnxJ+SmVGYnFGfFFpTmpxYcYJTiYlUR4uScBlfOmJFZW pRblw6SkOViUxHnFNRojhATSE0tSs1NTC1KLYLIyHBxKErz8wGgUEixKTU+tSMvMKUFIM3Fw ggznARr+YzLI8OKCxNzizHSI/ClGRSlx3m0gCQGQREZpHlwvKIkkvD1s+opRHOgVYd5WkCoe YAKC634FNJgJaPDavW9BBpckIqSkGhh3cVS3n3vf3mf9sUY51Xd/eDK7mMwhLjubnomedxYt u8aySnECn6LFp70WwWLNG9KNe2bxq4v3XupXYp7hWNDzOV4weaLjn/uM5eVmVtqbdhyYkW/k ekTx3/KqJUvcGtQ0rr7fk8cp4NQk+GbZ3PxiBfP2Xx9tV9kmXTKf+u53udC10JwsDSWW4oxE Qy3mouJEAJxMhwr9AgAA Archived-At: Subject: Re: [OAUTH-WG] Error Responses in Device Code Spec X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 20:57:36 -0000 FWIW I=E2=80=99m fine with that solution if that=E2=80=99s where the = editor and group go. =E2=80=94 Justin > On Apr 12, 2017, at 4:20 PM, Mike Jones = wrote: >=20 > It seems reasonable to have the spec say that Token Endpoint errors = can also be returned from the Device Endpoint. >=20 > -- Mike >=20 > -----Original Message----- > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Justin Richer > Sent: Wednesday, April 12, 2017 12:19 PM > To: > Subject: Re: [OAUTH-WG] Error Responses in Device Code Spec >=20 > Raising this point again. We=E2=80=99ve got a use case where people = are wanting to do custom error codes from the device endpoint and would = like the spec to have clear guidance. At the moment, it doesn=E2=80=99t = even have examples for errors from the device endpoint. >=20 > =E2=80=94 Justin >=20 >> On Mar 15, 2017, at 12:33 PM, Justin Richer wrote: >>=20 >> Unless I=E2=80=99m missing something, the current device code spec = doesn=E2=80=99t specify errors from the device code endpoint, only from = the token endpoint. What are people implementing in practice? We=E2=80=99r= e using token endpoint style errors (invalid_client, inavlid_grant_type, = etc). >>=20 >> =E2=80=94 Justin >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Wed Apr 12 16:37:52 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68AE1128BBB for ; Wed, 12 Apr 2017 16:37:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id smJC1DfyRke5 for ; Wed, 12 Apr 2017 16:37:48 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0137.outbound.protection.outlook.com [104.47.33.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C906712786A for ; Wed, 12 Apr 2017 16:37:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=WW3xC0L1SYH58FjfJiEtNBxe94nl6TOAMSVpzDccc0Y=; b=nmIxSYkdlZdUTheJrE6jqSI3f9oxS1rV6oJ2LFBNZ3ys46plScjRsviVs0lfX9LoSGLiaVsvupe4hBfQqsImXdkRgHs6cLWU6C+G0e442SBH6obcvHacuispElVUGj3LRuhFJ3R7KAI8hUWqIPsOfW3vM8lzhABkiT4i58vTUq4= Received: from CY4PR21MB0504.namprd21.prod.outlook.com (10.172.122.14) by CY4PR21MB0504.namprd21.prod.outlook.com (10.172.122.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.1; Wed, 12 Apr 2017 23:37:45 +0000 Received: from CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) by CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) with mapi id 15.01.1034.012; Wed, 12 Apr 2017 23:37:45 +0000 From: Mike Jones To: Rifaat Shekh-Yusef , Derek Atkins CC: Eric Rescorla , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Chair volunteers Thread-Index: AQHSomo6hDRKtFlJyEOAN4u2Q9YsG6GhdSwAgAwT05iAFIvagIAAb59A Date: Wed, 12 Apr 2017 23:37:45 +0000 Message-ID: References: <0b495b42-50a8-62da-499a-351fdd2eada3@gmx.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Ref=https://api.informationprotection.azure.com/api/72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetBy=mbj@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2017-04-12T16:35:54.2479644-07:00; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [167.220.1.119] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0504; 7:z6hQhjwGVcCwjjVRYYtuDtMLMRxhJ4HtwjNGV3GDCaZDLFeh591tfiewiIKuwTz1dQTKqAKhPyKY+MqUZDWESVdpp/rA1y1DzZ9t9jaarP3A0yM6FD/Jw+eMAYFE9p8KUxdjOHcmxb+FsBstMrCQBlxm0l2NCwNtSZZpeBwMM+3ezf6LWMCVBr/XedcvLf3qQ02MnpQJYrhkp7buqabu/9ebfFmEw6huWj6dDb7NY8iQrraItZm6hV+Ze9jLnN6ZpFcPY0OCakLyYbB9spBjanDkWJmjoah+c3BSXzt8MKuYkTshttiqn1eiVL8PZ5PvctNBDeXpQe8YW3znXesGe/z4dyvvLvHNDomETDQmHHk= x-ms-office365-filtering-correlation-id: 51797c0d-9dac-4986-14f5-08d481fcec20 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081)(201702281549075); SRVR:CY4PR21MB0504; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(248736688235697)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123562025)(20161123560025)(20161123555025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(6072148); SRVR:CY4PR21MB0504; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0504; x-forefront-prvs: 027578BB13 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(39850400002)(39450400003)(39400400002)(39410400002)(39840400002)(51414003)(53754006)(43784003)(377454003)(24454002)(3846002)(8990500004)(33656002)(229853002)(102836003)(19609705001)(6116002)(86362001)(790700001)(5660300001)(25786009)(236005)(2906002)(53936002)(86612001)(10290500002)(53546009)(5005710100001)(10090500001)(3280700002)(2950100002)(7696004)(3660700001)(5880100001)(8936002)(81156014)(7736002)(7906003)(66066001)(4326008)(8676002)(2900100001)(54356999)(74316002)(53386004)(76176999)(6246003)(38730400002)(93886004)(50986999)(6506006)(122556002)(9686003)(39060400002)(77096006)(189998001)(54906002)(606005)(54896002)(55016002)(6306002)(6436002)(99286003)(81166006); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0504; H:CY4PR21MB0504.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB050414D1321D9DD8B0086CACF5030CY4PR21MB0504namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Apr 2017 23:37:45.7418 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0504 Archived-At: Subject: Re: [OAUTH-WG] Chair volunteers X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 23:37:50 -0000 --_000_CY4PR21MB050414D1321D9DD8B0086CACF5030CY4PR21MB0504namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Q29uZ3JhdHVsYXRpb25zLCBSaWZhYXQhICBJIGxvb2sgZm9yd2FyZCB0byB3b3JraW5nIHdpdGgg eW91Lg0KDQpBbmQgRGVyZWssIHRoYW5rcyBhZ2FpbiBmb3IgYWxsIHlvdSBkaWQhICBJ4oCZbSBz dXJlIG91ciBwYXRocyB3aWxsIGNvbnRpbnVlIHRvIGNyb3NzLg0KDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBP QXV0aCBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBFcmljIFJl c2NvcmxhDQpTZW50OiBXZWRuZXNkYXksIEFwcmlsIDEyLCAyMDE3IDk6NTAgQU0NClRvOiBEZXJl ayBBdGtpbnMgPGRlcmVrQGlodGZwLmNvbT4NCkNjOiBvYXV0aEBpZXRmLm9yZw0KU3ViamVjdDog UmU6IFtPQVVUSC1XR10gQ2hhaXIgdm9sdW50ZWVycw0KDQpJIGFtIHBsZWFzZWQgdG8gKHNvbWV3 aGF0IGJlbGF0ZWRseSkgYW5ub3VuY2UgdGhhdCBSaWZhYXQgU2hla2gtWXVzZWYgaGFzIGFncmVl ZCB0bw0Kc2VydmUgYXMgY2hhaXIuIFRoYW5rcyB0byBEZXJlayBmb3IgaGlzIHNlcnZpY2UgYW5k IFJpZmFhdCBmb3IgYmVpbmcgd2lsbGluZyB0byBzdGVwIHVwIQ0KDQotRWtyDQoNCg0KT24gVGh1 LCBNYXIgMzAsIDIwMTcgYXQgODowMyBBTSwgRGVyZWsgQXRraW5zIDxkZXJla0BpaHRmcC5jb208 bWFpbHRvOmRlcmVrQGlodGZwLmNvbT4+IHdyb3RlOg0KSGkgZXZlcnlvbmUsDQoNCkhhbm5lcyBU c2Nob2ZlbmlnIDxoYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0PG1haWx0bzpoYW5uZXMudHNjaG9m ZW5pZ0BnbXgubmV0Pj4gd3JpdGVzOg0KDQo+IE9uIDAzLzIxLzIwMTcgMDY6MzkgUE0sIEthdGhs ZWVuIE1vcmlhcnR5IHdyb3RlOg0KPj4gQSBiaWcgdGhhbmsgeW91IHRvIERlcmVrIGZvciBoaXMg d29yayBpbiBPQXV0aCBhbmQgd2UgaG9wZSB0byBoYXZlIGhpcw0KPj4gY29udGludWVkIHBhcnRp Y2lwYXRpb24gaW4gdGhlIHdvcmtpbmcgZ3JvdXAhDQo+DQo+IEJpZyB0aGFua3MgdG8gRGVyZWsg Zm9yIGRvaW5nIHRoZSBqb2IgZm9yIHN1Y2ggYSBsb25nIHRpbWUuIEl0IGhhcyBiZWVuDQo+IGEg cGxlYXN1cmUgdG8gd29yayB3aXRoIHlvdSENCg0KSSBtdXN0IGFwb2xvZ2l6ZSBmb3IgaGF2aW5n IGVmZmVjdGl2ZWx5IGRpc2FwcGVhcmVkIGZyb20gdGhlIE9BdXRoDQpncm91cDsgbXkgY3VycmVu dCBwb3NpdGlvbiBoYXMgbGltaXRlZCBteSBhYmlsaXR5IHRvIGRvIElFVEYgd29yaywgYW5kDQps YXRlbHkgSSd2ZSBoYWQgZXZlbiBsZXNzIHRpbWUgdG8gcHV0IGluLCBhbmQgYWxhcyBPQXV0aCB3 YXMgYSBtYWpvcg0KY2FzdWFsdHkuICBJIGRvIHBsYW4gdG8gY29udGludWUgbXkgaW52b2x2ZW1l bnQgdG8gdGhlIGJlc3Qgb2YgbXkgYWJpbGl0eS4NCg0KSSBlbmNvdXJhZ2UgcGVvcGxlIHRvIHN0 ZXAgdXAgYW5kIHZvbHVudGVlciB0byBjby1jaGFpciB0aGUgZ3JvdXAuDQoNCj4gQ2lhbw0KPiBI YW5uZXMNCg0KLWRlcmVrDQoNCi0tDQogICAgICAgRGVyZWsgQXRraW5zICAgICAgICAgICAgICAg ICA2MTctNjIzLTM3NDU8dGVsOjYxNy02MjMtMzc0NT4NCiAgICAgICBkZXJla0BpaHRmcC5jb208 bWFpbHRvOmRlcmVrQGlodGZwLmNvbT4gICAgICAgICAgICAgd3d3LmlodGZwLmNvbTxodHRwOi8v d3d3LmlodGZwLmNvbT4NCiAgICAgICBDb21wdXRlciBhbmQgSW50ZXJuZXQgU2VjdXJpdHkgQ29u c3VsdGFudA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5v cmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg== --_000_CY4PR21MB050414D1321D9DD8B0086CACF5030CY4PR21MB0504namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uaG9lbnpiDQoJe21zby1zdHls ZS1uYW1lOmhvZW56Yjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjoj MDAyMDYwO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9 IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9k eSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJX b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMw MDIwNjAiPkNvbmdyYXR1bGF0aW9ucywgUmlmYWF0ISZuYnNwOyBJIGxvb2sgZm9yd2FyZCB0byB3 b3JraW5nIHdpdGggeW91LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+QW5k IERlcmVrLCB0aGFua3MgYWdhaW4gZm9yIGFsbCB5b3UgZGlkISZuYnNwOyBJ4oCZbSBzdXJlIG91 ciBwYXRocyB3aWxsIGNvbnRpbnVlIHRvIGNyb3NzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6IzAwMjA2MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1p a2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJf TWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L2E+PC9wPg0KPHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbEVuZENv bXBvc2UiPjwvc3Bhbj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBPQXV0aCBb bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddIDxiPk9uIEJlaGFsZiBPZg0KPC9iPkVyaWMg UmVzY29ybGE8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBBcHJpbCAxMiwgMjAxNyA5OjUw IEFNPGJyPg0KPGI+VG86PC9iPiBEZXJlayBBdGtpbnMgJmx0O2RlcmVrQGlodGZwLmNvbSZndDs8 YnI+DQo8Yj5DYzo8L2I+IG9hdXRoQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBb T0FVVEgtV0ddIENoYWlyIHZvbHVudGVlcnM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkkgYW0gcGxlYXNlZCB0byAoc29tZXdoYXQgYmVsYXRlZGx5KSBhbm5vdW5jZSB0aGF0Jm5ic3A7 PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdCI+UmlmYWF0IFNoZWtoLVl1c2VmIGhhcyBhZ3Jl ZWQgdG88L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdCI+c2VydmUgYXMgY2hhaXIuIFRoYW5rcyB0byBE ZXJlayBmb3IgaGlzIHNlcnZpY2UgYW5kIFJpZmFhdCBmb3IgYmVpbmcgd2lsbGluZyB0byBzdGVw IHVwITwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdCI+LUVrcjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUs IE1hciAzMCwgMjAxNyBhdCA4OjAzIEFNLCBEZXJlayBBdGtpbnMgJmx0OzxhIGhyZWY9Im1haWx0 bzpkZXJla0BpaHRmcC5jb20iIHRhcmdldD0iX2JsYW5rIj5kZXJla0BpaHRmcC5jb208L2E+Jmd0 OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7 bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5IaSBldmVyeW9uZSw8YnI+DQo8YnI+DQpIYW5uZXMgVHNjaG9mZW5pZyAmbHQ7PGEgaHJlZj0i bWFpbHRvOmhhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXQiPmhhbm5lcy50c2Nob2ZlbmlnQGdteC5u ZXQ8L2E+Jmd0OyB3cml0ZXM6PGJyPg0KPGJyPg0KJmd0OyBPbiAwMy8yMS8yMDE3IDA2OjM5IFBN LCBLYXRobGVlbiBNb3JpYXJ0eSB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyBBIGJpZyB0aGFuayB5b3Ug dG8gRGVyZWsgZm9yIGhpcyB3b3JrIGluIE9BdXRoIGFuZCB3ZSBob3BlIHRvIGhhdmUgaGlzPGJy Pg0KJmd0OyZndDsgY29udGludWVkIHBhcnRpY2lwYXRpb24gaW4gdGhlIHdvcmtpbmcgZ3JvdXAh PGJyPg0KJmd0Ozxicj4NCiZndDsgQmlnIHRoYW5rcyB0byBEZXJlayBmb3IgZG9pbmcgdGhlIGpv YiBmb3Igc3VjaCBhIGxvbmcgdGltZS4gSXQgaGFzIGJlZW48YnI+DQomZ3Q7IGEgcGxlYXN1cmUg dG8gd29yayB3aXRoIHlvdSE8YnI+DQo8YnI+DQpJIG11c3QgYXBvbG9naXplIGZvciBoYXZpbmcg ZWZmZWN0aXZlbHkgZGlzYXBwZWFyZWQgZnJvbSB0aGUgT0F1dGg8YnI+DQpncm91cDsgbXkgY3Vy cmVudCBwb3NpdGlvbiBoYXMgbGltaXRlZCBteSBhYmlsaXR5IHRvIGRvIElFVEYgd29yaywgYW5k PGJyPg0KbGF0ZWx5IEkndmUgaGFkIGV2ZW4gbGVzcyB0aW1lIHRvIHB1dCBpbiwgYW5kIGFsYXMg T0F1dGggd2FzIGEgbWFqb3I8YnI+DQpjYXN1YWx0eS4mbmJzcDsgSSBkbyBwbGFuIHRvIGNvbnRp bnVlIG15IGludm9sdmVtZW50IHRvIHRoZSBiZXN0IG9mIG15IGFiaWxpdHkuPGJyPg0KPGJyPg0K SSBlbmNvdXJhZ2UgcGVvcGxlIHRvIHN0ZXAgdXAgYW5kIHZvbHVudGVlciB0byBjby1jaGFpciB0 aGUgZ3JvdXAuPGJyPg0KPGJyPg0KJmd0OyBDaWFvPGJyPg0KJmd0OyBIYW5uZXM8YnI+DQo8c3Bh biBzdHlsZT0iY29sb3I6Izg4ODg4OCI+PGJyPg0KPHNwYW4gY2xhc3M9ImhvZW56YiI+LWRlcmVr PC9zcGFuPjxicj4NCjxicj4NCjxzcGFuIGNsYXNzPSJob2VuemIiPi0tPC9zcGFuPjxicj4NCjxz cGFuIGNsYXNzPSJob2VuemIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0RlcmVrIEF0a2lu cyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7PGEgaHJlZj0idGVsOjYxNy02MjMtMzc0NSI+NjE3LTYyMy0zNzQ1PC9hPjwvc3Bhbj48 YnI+DQo8c3BhbiBjbGFzcz0iaG9lbnpiIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8YSBo cmVmPSJtYWlsdG86ZGVyZWtAaWh0ZnAuY29tIj5kZXJla0BpaHRmcC5jb208L2E+Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PGEgaHJlZj0iaHR0cDovL3d3 dy5paHRmcC5jb20iIHRhcmdldD0iX2JsYW5rIj53d3cuaWh0ZnAuY29tPC9hPjwvc3Bhbj48YnI+ DQo8c3BhbiBjbGFzcz0iaG9lbnpiIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtDb21wdXRl ciBhbmQgSW50ZXJuZXQgU2VjdXJpdHkgQ29uc3VsdGFudDwvc3Bhbj48L3NwYW4+PG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGlu ZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj5PQXV0aEBpZXRmLm9y ZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_CY4PR21MB050414D1321D9DD8B0086CACF5030CY4PR21MB0504namp_-- From nobody Wed Apr 12 17:37:08 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDC2012786A for ; Wed, 12 Apr 2017 17:37:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C1TbF4gl35jB for ; Wed, 12 Apr 2017 17:37:04 -0700 (PDT) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::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 8EE0812741D for ; Wed, 12 Apr 2017 17:37:04 -0700 (PDT) Received: by mail-vk0-x22c.google.com with SMTP id z204so21695126vkd.1 for ; Wed, 12 Apr 2017 17:37:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9/aQo/UgjD2U+u+ptuUu+cFI3D1ICe1a3fOb0kLQhLM=; b=JIBNKy84ioTCBVcxktwicRm/LOqoiLeRDu/dpiEsP4knk+e63nArCFxH9hjmoFivCy ZplcWZor07odivEqPwO+Sw8IZNneAPRChIhRNVxybAL6hRzXLTjEl2O5ncSdSEqCgWSP wAi5Ot8xDhgl1vRoAh2P45T6uSXQu0gG4wdJ3CAkml0wEU0qGzkbpeBAfQpBJBR3M7+A hODnYB29B5+EiG9GdjEouGhLG8gbb7JwtqJ2av9urlsavcRdeYNeMYcX7A295b9RdedC 4LpTn4V/u0EMeo0QbGRy8rlIOYcq/3TQrqRo1u80UFY0W/QV6rBOg9jVZsC2zDVK4lpJ MIvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9/aQo/UgjD2U+u+ptuUu+cFI3D1ICe1a3fOb0kLQhLM=; b=CjHq8T8ll7SHmyLZ1rCwNbTk6U38wf2XCvYcCNZnAFcZ2J9sIUkEtlDWicqsTCHgBX JWON89sUvd3smq2sgxexB3Vm7q6/WDmUjCZeNLqvCRgUg+LLsDNou3H43ZBfZoPsfipp P7dq854b/So7+HxD6o2UgPOwuOMPRkm4Wy+tGEz6p0UBO+OscwBJQ9vo8TiYYxhaRpi3 IpEHY+xeeD8/mvpT6Arfe9YSrpRRwUMIW+vhI4I5x2PARA2hyebsquVH17S5eYW3Her4 5TfIIgjFhCAb141e7BmroDESN/rFFJ8uw1oo6WuwS1BuQCiZIjeTAQKl/tvYvuAtsrO9 2mXw== X-Gm-Message-State: AN3rC/4F3xnCZnC5aTkGOFyLWsCoVyAWn4ZPABW9ji0AB1EaiWV+7zLn a+ePnQcqgNaJFE0n+fR97Vtfws0Wlg== X-Received: by 10.31.82.3 with SMTP id g3mr213875vkb.88.1492043823746; Wed, 12 Apr 2017 17:37:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.85.208 with HTTP; Wed, 12 Apr 2017 17:37:03 -0700 (PDT) In-Reply-To: References: <0b495b42-50a8-62da-499a-351fdd2eada3@gmx.net> From: Rifaat Shekh-Yusef Date: Wed, 12 Apr 2017 20:37:03 -0400 Message-ID: To: Mike Jones Cc: Derek Atkins , Eric Rescorla , "oauth@ietf.org" Content-Type: multipart/alternative; boundary=001a114e509e1a976f054d0186e3 Archived-At: Subject: Re: [OAUTH-WG] Chair volunteers X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 00:37:07 -0000 --001a114e509e1a976f054d0186e3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks Mike! I am too looking forward to working with you and the rest of this very interesting and important WG. Regards, Rifaat On Wednesday, April 12, 2017, Mike Jones wrote: > Congratulations, Rifaat! I look forward to working with you. > > > > And Derek, thanks again for all you did! I=E2=80=99m sure our paths will= continue > to cross. > > > > -- Mike > > > > *From:* OAuth [mailto:oauth-bounces@ietf.org > ] *On Behalf Of *= Eric > Rescorla > *Sent:* Wednesday, April 12, 2017 9:50 AM > *To:* Derek Atkins > > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Chair volunteers > > > > I am pleased to (somewhat belatedly) announce that Rifaat Shekh-Yusef has > agreed to > > serve as chair. Thanks to Derek for his service and Rifaat for being > willing to step up! > > > > -Ekr > > > > > > On Thu, Mar 30, 2017 at 8:03 AM, Derek Atkins > wrote: > > Hi everyone, > > Hannes Tschofenig > writes: > > > On 03/21/2017 06:39 PM, Kathleen Moriarty wrote: > >> A big thank you to Derek for his work in OAuth and we hope to have his > >> continued participation in the working group! > > > > Big thanks to Derek for doing the job for such a long time. It has been > > a pleasure to work with you! > > I must apologize for having effectively disappeared from the OAuth > group; my current position has limited my ability to do IETF work, and > lately I've had even less time to put in, and alas OAuth was a major > casualty. I do plan to continue my involvement to the best of my ability= . > > I encourage people to step up and volunteer to co-chair the group. > > > Ciao > > Hannes > > -derek > > -- > Derek Atkins 617-623-3745 > derek@ihtfp.com > www.ihtfp.com > Computer and Internet Security Consultant > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > --001a114e509e1a976f054d0186e3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks Mike!

I am too looking forward to working with yo= u and the rest of=C2=A0this very interesting and important WG.
Regards,
=C2=A0Rifaat


O= n Wednesday, April 12, 2017, Mike Jones <Michael.Jones@microsoft.com> wrote:

Congratulations, Rifaa= t!=C2=A0 I look forward to working with you.

=C2=A0

And Derek, thanks agai= n for all you did!=C2=A0 I=E2=80=99m sure our paths will continue to cross.=

=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: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Eric Rescorla
Sent: Wednesday, April 12, 2017 9:50 AM
To: Derek Atkins <derek@ihtfp.com>
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Chair volunteers

=C2=A0

I am pleased to (somewhat belatedly) announce that= =C2=A0Rifaat Shekh-Yusef has agreed to

serve as chair. Than= ks to Derek for his service and Rifaat for being willing to step up!=

=C2=A0

-Ekr

=C2=A0

=C2=A0

On Thu, Mar 30, 2017 at 8:03 AM, Derek Atkins <derek@ihtfp.com> wrote:

Hi everyone,

Hannes Tschofenig <hannes.tschofenig@gmx.ne= t> writes:

> On 03/21/2017 06:39 PM, Kathleen Moriarty wrote:
>> A big thank you to Derek for his work in OAuth and we hope to have= his
>> continued participation in the working group!
>
> Big thanks to Derek for doing the job for such a long time. It has bee= n
> a pleasure to work with you!

I must apologize for having effectively disappeared from the OAuth
group; my current position has limited my ability to do IETF work, and
lately I've had even less time to put in, and alas OAuth was a major casualty.=C2=A0 I do plan to continue my involvement to the best of my abil= ity.

I encourage people to step up and volunteer to co-chair the group.

> Ciao
> Hannes

-derek

--
=C2=A0 =C2=A0 =C2=A0 =C2=A0Derek Atkins=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0617-623-3745
=C2=A0 =C2=A0 =C2=A0 =C2=A0derek@ihtfp.com=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0www.ihtfp.com
=C2=A0 =C2=A0 =C2=A0 =C2=A0Computer and Internet Security Consultant<= /span>


_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

=C2=A0

--001a114e509e1a976f054d0186e3-- From nobody Thu Apr 20 09:33:03 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2AFD129AA1 for ; Thu, 20 Apr 2017 09:33:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.901 X-Spam-Level: X-Spam-Status: No, score=-4.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wO0lDRj2ROJ9 for ; Thu, 20 Apr 2017 09:33:00 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 AD3C112422F for ; Thu, 20 Apr 2017 09:32:59 -0700 (PDT) Received: from [192.168.91.191] ([195.149.223.176]) by mail.gmx.com (mrgmx003 [212.227.17.190]) with ESMTPSA (Nemesis) id 0LqALY-1cNWTQ2yFE-00dmNH for ; Thu, 20 Apr 2017 18:32:56 +0200 To: "oauth@ietf.org" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <95776354-79e3-caa7-ba60-84cfec7f899f@gmx.net> Date: Thu, 20 Apr 2017 18:32:55 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="HpJTLtHbSBRxxoEuIRl9bUssODgaPafok" X-Provags-ID: V03:K0:GuM48BE90REPhtM/YbS4ysTioCIQrpz3oxuardZZ+K+xhDma1O4 2oKNFfKvCW8HXY68m374rnpxQlGQ/8i+tby1gDhnZPnTIfANU6MjgHlwW6p+NNu21oCVHQJ 6MZIa81hTFZHjuF2CqTt0nWm9FiPYgY2MRhCEkpYkTnP32DZ2UAVuOOboDbwjjETY4YQIs1 PRwmJI0TZoigt2IjCVJPQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:AY/udUdjtTY=:TKe+M02d9x/z2fxrHUUAyc BgxCGoDgKeNpPnIAWE+Kd+g6C5CdIGYknNyqQ0xmIEudgq5CbEjw5eNbdhwpMMtGgaZwisIpb lYf18C3ldu2Ep4nFA404h4iXe+VWblKnnFNq0UHXHdVMDzohfrJNijNjPDxKAbZPZPy56Dc+x 5KVHN0GsRREKRLe02dVe75+sCWhS93X7CIhA5qYDUPDTmvAcmqUpPw4jvwNHXbg3MWk2WrMPD GivzyDp2f5yhWW2FODNBfEJ+WN4DXT7+xu7GyVElt8t4YmPXcNP1R9PelOPI2OTiNFWkNfJQv 62QIKiU5oidqmePsjf6LIf8EWPhp4mEdSk3fbLPLqaYqjIFlssrgVyDLm4l2DYeUQEqlrLunp VTKZ+qVqRoAyJ0eHeW/3P/Ww4kL44Bb7gOG7VVr0+0fekh08T7/cW7+4A3qPo52KkXmPdj0lS 7xj10QPJ6N903gFtyGW9Noz8hUnWBMsRJDNVA+V3yaRFVrl3YmhJpfvVR3bPpE4pznQkSpIne siDCNT87TZUjaDixVZcBGGb3rMFrQxPOBLVV3dSws37GdGKaSAG6DCFLwXgoV2EJBP/+0Pp7c +/KlO1CmSGFp6r/QEXiqw1/H9gX2o6c9jAE1IKtEK50dDWoh4UCP/00Xmyg4qO58OjswJpmhT t/xHpOaUSu+iu6fbGPrcvIBxc1RvCp5gWrNPbXI+RyGhp4FiXKnaWuSIEIDIYBosxQP1q4x2S nv9jEpmpHF5qGh0Q3pPzjG1U2eCPjR5JWz0DFTElAPZdm/UfyBn2hPTS1CQ= Archived-At: Subject: [OAUTH-WG] Call for Adoption: Mutual TLS Profiles for OAuth Clients X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 16:33:02 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --HpJTLtHbSBRxxoEuIRl9bUssODgaPafok Content-Type: multipart/mixed; boundary="4U0ADrbISkjTuuTbbJBrsSTAB3rRcSugI"; protected-headers="v1" From: Hannes Tschofenig To: "oauth@ietf.org" Message-ID: <95776354-79e3-caa7-ba60-84cfec7f899f@gmx.net> Subject: Call for Adoption: Mutual TLS Profiles for OAuth Clients --4U0ADrbISkjTuuTbbJBrsSTAB3rRcSugI Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, based on the strong support for this document at the Chicago IETF meeting we are issuing a call for adoption of the "Mutual TLS Profiles for OAuth Clients" document, see https://tools.ietf.org/html/draft-campbell-oauth-mtls-01 Please let us know by May 4th whether you accept / object to the adoption of this document as a starting point for work in the OAuth working group. Ciao Hannes & Rifaat --4U0ADrbISkjTuuTbbJBrsSTAB3rRcSugI-- --HpJTLtHbSBRxxoEuIRl9bUssODgaPafok Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJY+OK3AAoJEGhJURNOOiAtapYH+wZpft/9eYdjPUM30AidO9ui N924FbE8DQ3qiykl+Nb4UvfyV65Mr/Mtp+DPM5ms6ebPN/ggFmZwXtKmoeidv0Yt Cx2S98oayxUO/+puvRki3QsTp7tBy6vO7LbCES2OQktjr4vDVaGLp4cqTCkHYF1W 1UluDwN76s+idx2r+tdHZyR2kWNDk7hqyMuKTfCXXxUVINm/74voZz5hzLh3//3c XgrUJLA573/Y8RDhDwYdaRbCVtlXbNkuUsY/tE48uA8QposwVWi2u6WH/TLbbWrZ d46ZwcFaN6DMzc7fQlFbvusHsKYcQ2/vhIKIlmaC6hHKYS3wbWVSCBQYBcLNNG8= =F/+F -----END PGP SIGNATURE----- --HpJTLtHbSBRxxoEuIRl9bUssODgaPafok-- From nobody Thu Apr 20 09:48:24 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 387E013147F for ; Thu, 20 Apr 2017 09:48:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uZKAAKWMH-QO for ; Thu, 20 Apr 2017 09:48:21 -0700 (PDT) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BE72129436 for ; Thu, 20 Apr 2017 09:48:21 -0700 (PDT) Received: by mail-io0-x230.google.com with SMTP id a103so78531410ioj.1 for ; Thu, 20 Apr 2017 09:48:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=f18W/BY9wbfec0k/GhyIFy/VNzZBfPhol0BfrrUxeoU=; b=YDB6UFwJI9QmaTcr0Na7LkgF7jAaCvQTlz4Z5S5aWI70xiEC/A17HVG3mN7rwaGPnn tYb8J+WHqbLXS1F9OyZH8SpbrfhNnmObfjJP9QF13osSQ31LohQJrB+HjGpbXeaccRqe twvYitkIaaw8dm/whEApDWiH8sguofj44WBxs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=f18W/BY9wbfec0k/GhyIFy/VNzZBfPhol0BfrrUxeoU=; b=ZnHEJIw+6xnSpKlXMlVdg9hFQiYxRNlyCNkrk5Y/trkSrw8eZWeNjxkJbZpzuyTO3X QPKUGjiB6k2eC/6oR5aeMvgNlrcgZ5X5ACxORstrqblp/AZ36QUdOMDcuRX6yPOH0I7x xGMg5/eF235cAwb4kLpjXu5r6z+qNF6R8jKhnAp00XUHocYv350ZDtM8Y4U5G3aiqrGZ h88jQ4urTu4nvPetA2eMoSVxADle1juGfMeLvp9Zls1IYT4d51mbDn+SzNrMUsgkiIXq AyZ0qcERDH4FXL7u96xrTCdZW56kay9QoPbnaFl50as2V32HHK4l9xRroGIBs7yB3f0J n2GQ== X-Gm-Message-State: AN3rC/5STTgvs4GVWxACr5R/ub2M5azS6ChlUen536bylLwdK8uTAI84 KjAZvyZcRdQ2kWqu+50LkUxqxu7FRhkG X-Received: by 10.99.105.10 with SMTP id e10mr8680327pgc.142.1492706900588; Thu, 20 Apr 2017 09:48:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.170.13 with HTTP; Thu, 20 Apr 2017 09:47:50 -0700 (PDT) In-Reply-To: <95776354-79e3-caa7-ba60-84cfec7f899f@gmx.net> References: <95776354-79e3-caa7-ba60-84cfec7f899f@gmx.net> From: Brian Campbell Date: Thu, 20 Apr 2017 10:47:50 -0600 Message-ID: To: Hannes Tschofenig Cc: "oauth@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c13f278906107054d9be894 Archived-At: Subject: Re: [OAUTH-WG] Call for Adoption: Mutual TLS Profiles for OAuth Clients X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 16:48:23 -0000 --94eb2c13f278906107054d9be894 Content-Type: text/plain; charset=UTF-8 I accept adoption of this document as a starting point for work in the OAuth working group! On Thu, Apr 20, 2017 at 10:32 AM, Hannes Tschofenig < hannes.tschofenig@gmx.net> wrote: > Hi all, > > based on the strong support for this document at the Chicago IETF > meeting we are issuing a call for adoption of the "Mutual TLS Profiles > for OAuth Clients" document, see > https://tools.ietf.org/html/draft-campbell-oauth-mtls-01 > > Please let us know by May 4th whether you accept / object to the > adoption of this document as a starting point for work in the OAuth > working group. > > Ciao > Hannes & Rifaat > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --94eb2c13f278906107054d9be894 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I accept adoption of this = document as a starting point for work in the OAuth working group!

On Thu, Apr 20, 2017 = at 10:32 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net><= /span> wrote:
Hi all,

based on the strong support for this document at the Chicago IETF
meeting we are issuing a call for adoption of the "Mutual TLS Profiles=
for OAuth Clients" document, see
https://tools.ietf.org/html/draft-campb= ell-oauth-mtls-01

Please let us know by May 4th whether you accept / object to the
adoption of this document as a starting point for work in the OAuth
working group.

Ciao
Hannes & Rifaat


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


--94eb2c13f278906107054d9be894-- From nobody Thu Apr 20 10:00:12 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B3CB129B3C for ; Thu, 20 Apr 2017 10:00:10 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b5JIe2B_hhWe for ; Thu, 20 Apr 2017 10:00:09 -0700 (PDT) Received: from mail-ua0-x22a.google.com (mail-ua0-x22a.google.com [IPv6:2607:f8b0:400c:c08::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 714E9129B2F for ; Thu, 20 Apr 2017 10:00:08 -0700 (PDT) Received: by mail-ua0-x22a.google.com with SMTP id j59so14014982uad.0 for ; Thu, 20 Apr 2017 10:00:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=SpjNaSuEkH/q+4Hn4ZCok3metB4K63IiH4fNMWcnORU=; b=AmDONhrb92BsQ1XNHa2DMOWHFDyQlqO/3jRuTiP5zMhkBGOHQXrBoSiYLZJG0P3Bf/ X4iSOU2TAoN0lGigaICwApOhnGVs0eM9wXcY/Sjm0aA8fBDMyBOHWHT0CFJ5hOWjN+fb 8xVJnYZW9SRZ8KgvcKnVrr23X8zkQPhXk8uscEvcj+dWPsnNVcnIG/o9ENNR+ooKKVgL R6V/oiuU+3kyIca0o01I8DQxEod0hdBXUpbDacrCJNkqME19Z9C8UeSFJpe9vCBpe6YW b+EFIeujHrOA6cyef7xdxiCSHeLANvmF7KdXsYWxFD8aMH7U/ROWH7/7O9ZAf3teWtUg e/1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=SpjNaSuEkH/q+4Hn4ZCok3metB4K63IiH4fNMWcnORU=; b=Jtl+YaLZOKDX7b08TU93Ln6mLOcjO6Y48O/kGX+mdxOzWhHRrorURzGAAH7kJPxyiF k4zIEsG67NbmqXaaGtgu5FhcIXT4SIr+jQ4rkN1viJTt+QVOeDdoGCuz5OVlwDG9WWHI UVMt5PzlsAednCaJ1qH6zO5/xEoTvXXmbLpyRRHq2FR5uny36xusgDhBdJk34MiAuJw7 G7u5JFfnPszDpsjlKdrdpycGcBm3N92S5zexawKNuYf2Vz0rn9yVcHvs9JDjTTDR7qe9 FU1eWR6pWlVQ41Fhl4/OqCr/nKFbk0NYv8LcILlRoN9v6EvID7VJKcN+yaRhp15lr7YS qIiw== X-Gm-Message-State: AN3rC/6h6sycxIdKkF6exbSLPGCvXx30U+ZXSj+b8bRKNnHX4dUshmoQ lyB/Hvi//jie2/yDuTmCEN/98OQPI2A5 X-Received: by 10.31.177.131 with SMTP id a125mr3168597vkf.80.1492707607314; Thu, 20 Apr 2017 10:00:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.80.17 with HTTP; Thu, 20 Apr 2017 10:00:06 -0700 (PDT) From: Rifaat Shekh-Yusef Date: Thu, 20 Apr 2017 13:00:06 -0400 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary=001a114419f0b03ec9054d9c124c Archived-At: Subject: [OAUTH-WG] Meetings Minutes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 17:00:10 -0000 --001a114419f0b03ec9054d9c124c Content-Type: text/plain; charset=UTF-8 Hi, We have uploaded the minutes to the following link: https://www.ietf.org/proceedings/98/minutes/minutes-98-oauth-00 Thanks to Jeff Hodges for taking the notes. Please, let us know if you have any feedback. Regards, Rifaat & Hannes --001a114419f0b03ec9054d9c124c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

We have uploaded the min= utes to the following link:

Thanks to Jeff Hod= ges for taking the notes.

Please, let us know if y= ou have any feedback.

Regards,
=C2=A0Rif= aat & Hannes

--001a114419f0b03ec9054d9c124c-- From nobody Thu Apr 20 10:40:27 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E3C31314B6 for ; Thu, 20 Apr 2017 10:40:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R-Zy7O3Drrft for ; Thu, 20 Apr 2017 10:40:24 -0700 (PDT) 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 547E2129B3A for ; Thu, 20 Apr 2017 10:40:24 -0700 (PDT) Received: by mail-qk0-x232.google.com with SMTP id h67so52973908qke.0 for ; Thu, 20 Apr 2017 10:40:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=j6qLS2LuE/2ZrVecIWPY7NivV6cOxtL0f1XlGYTLRBI=; b=T9sT1vfuuuW9t2epvlIMeLl9mjLNtB0tbG0VsGtYchXju7GvGD4TOCTGJsq2ui9W7N 0L7MDso6TTxBNGk1eJA51viFjZ0WR9fQaFz7fWgv7UC7eujHZC8sRNg0IXk+3o6usrgG i7LHWAWrsFf9ljtgHgxiU7QiVsFFdEMO45WeaFyaGgtydgYZf6y+MC+QgIG9eJvXjuok 5zF/SBonoG2d4V0XZrqXQ+F647845QU0kgu/bMal2U+W6wh42skeL+vbuDDHXB2XecN7 a7IsaG5LeCb+CE2IG4MC0gd3tuBp8cRz9ABf8Gssz8PCsgeSkRzfIR8qR5rM1tWyN+Dv 84LQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=j6qLS2LuE/2ZrVecIWPY7NivV6cOxtL0f1XlGYTLRBI=; b=oX2LOtnCihOqwgAASiKoCgDQHLd7CuxQC+1Ls5kXPAIP1dqAVs3b1bIcNdSXWfM8v/ cRseNlmdN8+lR1QPlfS6LDiCsU6iuN2gD6hS1Emm4BmTpoaR2jIKoIju9Ux8/lfteovx w3/J6TumkdEvTWOg62oUBMHdAbZm462yVA3UOqUf5GMtL1eqdEiMr9GxJWcezIWrq2v7 yj+gKk5xcoa1wAKmQA/0hTIsxKFcnWvaiovABr7U/qB/vqtQ/OzaEjjAjNeiKxohzM9r kVQs/TN4rEw+qQTdpLQNt7fV69ORQtiENNNgsWUoshxM2RZ5gseKeICzm2cqIsOxzhzZ LaIw== X-Gm-Message-State: AN3rC/7BIAsdLlJArhd1udtcDd+OFO4yHW7hcObdtAsW8oKepnS3S/TY nU6hPcU0o8S95SIe X-Received: by 10.55.142.69 with SMTP id q66mr8672592qkd.13.1492710023425; Thu, 20 Apr 2017 10:40:23 -0700 (PDT) Received: from [192.168.8.100] ([181.201.153.78]) by smtp.gmail.com with ESMTPSA id s10sm4578939qke.53.2017.04.20.10.40.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Apr 2017 10:40:22 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: John Bradley In-Reply-To: <95776354-79e3-caa7-ba60-84cfec7f899f@gmx.net> Date: Thu, 20 Apr 2017 14:40:20 -0300 Cc: "oauth@ietf.org" Message-Id: <05BD7891-FEA8-4D18-A2A4-258C0A353621@ve7jtb.com> References: <95776354-79e3-caa7-ba60-84cfec7f899f@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.3273) Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="94eb2c083c7ab5c249054d9ca24e" Archived-At: Subject: Re: [OAUTH-WG] Call for Adoption: Mutual TLS Profiles for OAuth Clients X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 17:40:26 -0000 --94eb2c083c7ab5c249054d9ca24e Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable I accept the adoption as a starting point. John B. > On Apr 20, 2017, at 1:32 PM, Hannes Tschofenig = wrote: >=20 > Hi all, >=20 > based on the strong support for this document at the Chicago IETF > meeting we are issuing a call for adoption of the "Mutual TLS Profiles > for OAuth Clients" document, see > https://tools.ietf.org/html/draft-campbell-oauth-mtls-01 >=20 > Please let us know by May 4th whether you accept / object to the > adoption of this document as a starting point for work in the OAuth > working group. >=20 > Ciao > Hannes & Rifaat >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --94eb2c083c7ab5c249054d9ca24e Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIRGwYJKoZIhvcNAQcCoIIRDDCCEQgCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg gg4rMIIErzCCA5egAwIBAgIRAOAjyxUSg1OJrWFuelRnayEwDQYJKoZIhvcNAQELBQAwbzELMAkG A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0xNDEy MjIwMDAwMDBaFw0yMDA1MzAxMDQ4MzhaMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRl ZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1 cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCJsQ3aelMZTnBSHbxW pgYmt7hJ4JbnUavx8FoTSRWjtIwbYLx6UUKneYykIt8XYU6R1XYjChTTSgJ/th0JgG6lBD3ZursW /qGHqS5DUkMWfK8yUMimT1rpCNjPkyWce4joMGTmpPhWgP0qJBQzF5msROVpi6NGBkvCM9TpQJ8G sLGsk0C5tQiTOpwqU6MQ2z0gYTxVA47ZTnYlAiEp+qN8cXZP7uFfgen7VIDbw3s1UreE3iI9LDAt MX9ZvVI3sDNpLUPr+tal8Zd3Z1GM2e4n67ylBzh2jKSpOP/fjPUDrEm+yvdzmToPMquclToTPQ5G Old0YVC+xkA/y+Tin6IhAgMBAAGjggEXMIIBEzAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73g JMtUGjAdBgNVHQ4EFgQUkmFrguGioKpP7GfxwqP3tIAAwewwDgYDVR0PAQH/BAQDAgGGMBIGA1Ud EwEB/wQIMAYBAf8CAQAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBEGA1UdIAQKMAgw BgYEVR0gADBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vQWRkVHJ1 c3RFeHRlcm5hbENBUm9vdC5jcmwwNQYIKwYBBQUHAQEEKTAnMCUGCCsGAQUFBzABhhlodHRwOi8v b2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBCwUAA4IBAQAbKm6sVcE6q4jF2O3NVfOqa2Er wAkQI5kPxWZqb7H1tLV3Xg8CYQDffQX+ErOkgIAA/PsdW2pyAgpBvAW6wVjVJsLq1U2E+/6CmM9Y G+MiY5xS+LsFNqt9WKXeqztj5drVc+/s4Pt74qP/8EIjnMq2jU0+5EsYA7KoLdTYu0JLkGmFENum NzToe+ABEKWcyjrHn0+ING6KZdAairup3MrKNtH0/MJkKTWv1rGncRHSA0Oxjz6a7J4yU/R2ksqG NAe5LMrmHErYmQ3BhuKQkvtaQmojIRDpZcf11bt+6oyFIAJi6tE6ByxZxZkz8jiJ5bbpFnofeRT2 ShAaJvp8ivubMIIENjCCAx6gAwIBAgIBATANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEU MBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3 b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTAwMDUzMDEwNDgzOFoX DTIwMDUzMDEwNDgzOFowbzELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYD VQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0 ZXJuYWwgQ0EgUm9vdDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALf3GjPm8gAELTng TlvtH7xsD821+iO2zt6bETOXpClMfZOfvUq8k+0DGuOPz+VtUFrWlymUWoCwSXrbLpX9uMq/Nzgt Hj6RQa1wVsfwTz/oMp50ysiQVOnGXw94nZpAPA6sYapeFI+eh6FqUNzXmk6vBbOmcZSccbNQYArH E504B4YCqOmoaSYYkKtMsE8jqzpPhNjfzp/haW+710LXa0Tkx63ubUFfclpxCDezeWWkWaCUN/cA Lw3CknLa0Dhy2xSoRcRdKn23tNbE7qzNE0S3ySvdQwAl+mG5aWpYIxG3pzOPVnVZ9c0p10a3Citl ttNCbxWyuHv77+ldU9U0WicCAwEAAaOB3DCB2TAdBgNVHQ4EFgQUrb2YejS0Jvf6xCZU7wO94CTL VBowCwYDVR0PBAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wgZkGA1UdIwSBkTCBjoAUrb2YejS0Jvf6 xCZU7wO94CTLVBqhc6RxMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4 dGVybmFsIENBIFJvb3SCAQEwDQYJKoZIhvcNAQEFBQADggEBALCb4IUlwtYj4g+WBpKdQZic2YR5 gdkeWxQHIzZlj7DYd7usQWxHYINRsPkyPef89iYTx4AWpb9a/IfPeHmJIZriTAcKhjW88t5RxNKW t9x+Tu5w/Rw56wwCURQtjr0W4MHfRnXnJK3s9EK0hZNwEGe6nQY1ShjTK3rMUUKhemPR5ruhxSvC Nr4TDea9Y355e6cJDUCrat2PisP29owaQgVR1EX1n6diIWgVIEM8med8vSTYqZEXc4g/VhsxOBi0 cQ+azcgOno4uG+GMmIPLHzHxREzGBHNJdmAPx/i9F4BrLunMTA5amnkPIAou1Z5jJh5VkpTYghda e9C8x49OhgQwggU6MIIEIqADAgECAhEA2TLMtWuXNcB2cbqZ/VgVujANBgkqhkiG9w0BAQsFADCB mzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2 IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE3MDEwOTAwMDAw MFoXDTE4MDEwOTIzNTk1OVowIjEgMB4GCSqGSIb3DQEJARYRdmU3anRiQHZlN2p0Yi5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDW2rqobOFQ/XmzH3DG2UK1Dt6jtc+OFZ71KQoB o8IZa/V94Ey12BPjBcoj+cjHNVsLd2QiUpMcf5sZFMX1cmvpR7TiUISgVcHe8zgiUUvN5Jn5tPDM Kb4E34TtDEG2X5FyY35AwCl8NV/loj2D5KLid9BLdVTJjfqokjLQ/4qCQjWBjfTpIdAdr3lXfg5f a5UPyIkphEIplM8/yGfX0W/PBl804XAL0gesLrfEMdgG58UCN1wJMgH4uRKmKU/U2Ap4W9hTpioN M722U8x7N6P1v6MqTAWCUaskdOp+ktNxFGxOlCE7BEo/EIaWbEt5RHwDePctScDLsi56+VI3TysR AgMBAAGjggHvMIIB6zAfBgNVHSMEGDAWgBSSYWuC4aKgqk/sZ/HCo/e0gADB7DAdBgNVHQ4EFgQU Yg3SsFWhMro4Abonbn1IX4JKj5QwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0l BBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9 MDsGDCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0 L0NQUzBdBgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9TSEEy NTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDBYBggrBgEFBQcwAoZMaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xp ZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDov L29jc3AuY29tb2RvY2EuY29tMBwGA1UdEQQVMBOBEXZlN2p0YkB2ZTdqdGIuY29tMA0GCSqGSIb3 DQEBCwUAA4IBAQCC26y+6/+SJoRQWepca+rB9eSSwaCAb8nNqA+00ZiOHb+6UbbV1xa7Z8wDIuEL 5UKbNtQ2NDArvzF9YI0xNafoV1AEmP/3+ljxQHSEI0U1p2h401sOx+nSjcwtTzACso1lw+I0oJYM JFITOIfZy8HgFpCipBrQAp9jMJ+KSKDX3xu/hzPosfdnXp7sV1KAjkFrAtR3AnQYfJ5W8QrsmC4N BbiAKoYWUSdklqn3v1neTG/+oOhcw7hcGZo+YmPyF9Cdy0gBtwSHPt8hluhg2TlzmqYfi0dVL/mU jCBNUY/BFH+MBqKF7sOIRMv8ALWceVaM/NEcBciKs4eR99A4cw9ZMYICtDCCArACAQEwgbEwgZsx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRANkyzLVrlzXAdnG6mf1Y FbowDQYJYIZIAWUDBAIBBQCggdQwLwYJKoZIhvcNAQkEMSIEIK+YtdmMC/CWImREjI6UOF1IwK94 gPJrlBjo+1tbp5cIMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE3 MDQyMDE3NDAyM1owaQYJKoZIhvcNAQkPMVwwWjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzALBgkqhkiG9w0BAQowCwYJKoZIhvcNAQEHMAsGCWCGSAFl AwQCATANBgkqhkiG9w0BAQEFAASCAQBpTxZxfQNyn1HuWWwkLnWdYw1ihWHGsaT0gdD4d5oPI5k/ r4kWeWsvSQ477p6CtJ/5QKHaeB2hOAgyWac+rSA+dMm8Vr2TfippbRDy1/AEd84fMA7NT2fO0UxE h13t3eRvfBHgBuoXFC0phs3QkmUdi+h5dxFYuMhGdZHPPccr9D5QKc0RnHuY3wqGN1jMIQOtFKkR bTrnmFZbqP7znuwfFvwCFPO6DDkCZibjPGW44XMqCmmGdSqrhm78CcXWsw25popQ3XqlQmOOD1hn K4z4UoEOItfTJHMet59pj1ZZL9hIQVSzUwBT3bc0lPVq+dAlwRe0AFgkSpHWWc5ZtZhb --94eb2c083c7ab5c249054d9ca24e-- From nobody Thu Apr 20 10:42:33 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F2DF127F0E for ; Thu, 20 Apr 2017 10:42:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JVpUB1Dpg5D1 for ; Thu, 20 Apr 2017 10:42:27 -0700 (PDT) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.29.28]) (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 B4B73129B6A for ; Thu, 20 Apr 2017 10:42:26 -0700 (PDT) Received: from [46.183.103.17] (helo=[172.16.241.144]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84) (envelope-from ) id 1d1G63-0005ER-90; Thu, 20 Apr 2017 19:42:24 +0200 From: Torsten Lodderstedt Message-Id: <4ACE4772-E01B-4D9A-8AED-7926B9E87615@lodderstedt.net> Content-Type: multipart/signed; boundary="Apple-Mail=_06316783-E862-4822-9811-7DC10AEBF640"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 20 Apr 2017 19:42:17 +0200 In-Reply-To: <3A9170DD-0861-478D-A9DD-9A55DC930B8D@ve7jtb.com> To: "oauth@ietf.org" References: <269DD0EC-FCBF-4691-9BAA-2B8F144C0353@lodderstedt.net> <3A9170DD-0861-478D-A9DD-9A55DC930B8D@ve7jtb.com> X-Mailer: Apple Mail (2.3273) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] Second OAuth Security Workshop (Call for Papers) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 17:42:30 -0000 --Apple-Mail=_06316783-E862-4822-9811-7DC10AEBF640 Content-Type: multipart/alternative; boundary="Apple-Mail=_A07F901A-E103-45E3-B64A-035CA0EC2416" --Apple-Mail=_A07F901A-E103-45E3-B64A-035CA0EC2416 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi all, I'm pleased to announce the hosts managed to change the date of the = security workshop to the end of the week before IETF-99, July 13-14.=20 Please find the updated CfP below. kind regards, Torsten. = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D C a l l F o r P a p e r s Second OAuth Security Workshop (OSW 2017) Zurich, Switzerland -- July 13-14, 2017 (note the changed event date) WWW: https://zisc.ethz.ch/oauth-security-workshop-2017-cfp/ = Position paper submission deadline: May 2, 2017 (AoE, UTC-12). = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D Overview The OAuth Security Workshop (OSW) focuses on improving security of the OAuth standard and related Internet protocols. This workshop brings together the IETF OAuth Working Group and security experts from research, industry, and standardization to this end. The workshop is hosted by the Zurich Information Security and Privacy Center at ETH = Zurich. While the standardization process of OAuth ensures extensive reviews (both security and non-security related), further analysis by security experts from academia and industry is essential to ensure high quality specifications. Contributions to this workshop can help to improve the security of the Web and the Internet. Scope We seek position papers related to the security of OAuth, OpenID Connect, and other technologies using OAuth under the hood. Contributions regarding technologies that are used in OAuth, such as JOSE, or impact the security of OAuth, such as Web technology, are also welcome. Important Dates Position paper submission deadline: May 2, 2017 (AoE, UTC-12). Author notification: May 15, 2017. Registration deadline: June 16, 2017. Workshop: July 13 and July 14, 2017. Invited Speakers Cas Cremers, University of Oxford Submission We welcome position papers that describe existing work, raise new requirements, highlight challenges, write-ups of implementation and deployment experience, lessons-learned from successful or failed attempts, and ideas on how to improve OAuth and OAuth extensions. Position papers submitted to the OAuth Security Workshop may report on (unpublished) work in progress, be submitted to other places, and may even have already appeared or been accepted elsewhere. Submissions must be in PDF format and should feature reasonable margins and formatting. There is no page limit, but the submission should be brief (ideally not more than 3-5 pages). Submissions should not be anonymized. Submission Website: https://easychair.org/conferences/?conf=3Dosw17 = Publication and Presentation One of the authors of the accepted position paper is expected to present the paper at the workshop. All presentations and papers will be put online but there will be no formal proceedings. Authors of accepted papers will have the option to revise their papers before they are put online. IPR Policy The workshop will have no expectation of IPR disclosure or licensing related to its submissions. Authors are responsible for obtaining appropriate publication clearances. Program Committee Chairs David Basin (ETH Zurich) Torsten Lodderstedt (YES Europe) Members John Bradley (Ping Identity) Ralf K=C3=BCsters (University of Stuttgart) Chris Mitchell (Royal Holloway University of London) Anthony Nadalin (Microsoft) Nat Sakimura (Nomura Research Institute) Ralf Sasse (ETH Zurich) J=C3=B6rg Schwenk (Ruhr University Bochum) Hannes Tschofenig (IETF OAuth Working Group Co-Chair) > Am 13.03.2017 um 21:01 schrieb John Bradley : >=20 > I did point out earlier when I discovered the dates, that I similarly = asked for it to be later in the week. > It is probably fine for Europeans but it will stop many people from = being able to attend including myself unless I can come up with other = meetings in Europe to fill those days. >=20 > If we cant move it then we will have to live with it and attend or = not. >=20 > John B. >=20 >> On Mar 13, 2017, at 4:46 PM, Torsten Lodderstedt = wrote: >>=20 >> Hi Mike, >>=20 >> yes, those are the right dates. There are restrictions from the = host's side, that=E2=80=99s why the workshop needs to take place on = Monday and Tuesday. As far as I remember the host was clear about that = from the beginning.=20 >>=20 >> best regards, >> Torsten. >>=20 >>> Am 12.03.2017 um 22:15 schrieb Mike Jones = : >>>=20 >>> Are Monday-Tuesday, July 10-11 really the right dates? I'm asking = because IETF in Prague doesn't start until Sunday, July 16th. That = leaves 4 days dead time in between for those of us who are attending = both. >>>=20 >>> When I was first told about this workshop, I was told that it would = be sometime Wednesday-Friday that week. Can it be moved back to those = dates? That would be a big help for those of us travelling distances to = attend. >>>=20 >>> Or is there also another event in the Wednesday-Friday timeframe = that people should also be considering attending? >>>=20 >>> Thanks, >>> -- Mike >>>=20 >>> -----Original Message----- >>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Torsten = Lodderstedt >>> Sent: Sunday, March 12, 2017 12:28 PM >>> To: oauth@ietf.org >>> Subject: [OAUTH-WG] Second OAuth Security Workshop (Call for Papers) >>>=20 >>> Hi all, >>>=20 >>> the OAuth WG and the ETH Zurich will organize another workshop on = OAuth security (after the one last year in Trier). >>>=20 >>> Please find the Call for Papers below. >>>=20 >>> kind regards, >>> Torsten. >>>=20 >>> C a l l F o r P a p e r s >>>=20 >>> Second OAuth Security Workshop (OSW 2017) >>>=20 >>> Zurich, Switzerland -- July 10-11, 2017 >>>=20 >>> WWW:https://zisc.ethz.ch/oauth-security-workshop-2017-cfp/ >>>=20 >>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >>>=20 >>> Overview >>>=20 >>> The OAuth Security Workshop (OSW) focuses on improving security of = the OAuth standard and related Internet protocols. This workshop brings = together the IETF OAuth Working Group and security experts from = research, industry, and standardization to this end. The workshop is = hosted by the Zurich Information Security and Privacy Center at ETH = Zurich. >>>=20 >>> While the standardization process of OAuth ensures extensive reviews = (both security and non-security related), further analysis by security = experts from academia and industry is essential to ensure high quality = specifications. Contributions to this workshop can help to improve the = security of the Web and the Internet. >>>=20 >>>=20 >>> Scope >>>=20 >>> We seek position papers related to the security of OAuth, OpenID = Connect, and other technologies using OAuth under the hood. >>> Contributions regarding technologies that are used in OAuth, such as = JOSE, or impact the security of OAuth, such as Web technology, are also = welcome. >>>=20 >>>=20 >>> Important Dates >>>=20 >>> Position paper submission deadline: May 2, 2017 (AoE, UTC-12). >>> Author notification: May 15, 2017. >>> Registration deadline: June 16, 2017. >>> Workshop: July 10 and July 11, 2017. >>>=20 >>>=20 >>> Invited Speakers >>>=20 >>> Cas Cremers, University of Oxford >>>=20 >>>=20 >>> Submission >>>=20 >>> We welcome position papers that describe existing work, raise new = requirements, highlight challenges, write-ups of implementation and = deployment experience, lessons-learned from successful or failed = attempts, and ideas on how to improve OAuth and OAuth extensions. >>>=20 >>> Position papers submitted to the OAuth Security Workshop may report = on >>> (unpublished) work in progress, be submitted to other places, and = may even have already appeared or been accepted elsewhere. >>>=20 >>> Submissions must be in PDF format and should feature reasonable = margins and formatting. There is no page limit, but the submission = should be brief (ideally not more than 3-5 pages). Submissions should = not be anonymized. >>>=20 >>> Submission Website:https://easychair.org/conferences/?conf=3Dosw17 >>>=20 >>>=20 >>> Publication and Presentation >>>=20 >>> One of the authors of the accepted position paper is expected to = present the paper at the workshop. >>>=20 >>> All presentations and papers will be put online but there will be no = formal proceedings. Authors of accepted papers will have the option to = revise their papers before they are put online. >>>=20 >>>=20 >>> IPR Policy >>>=20 >>> The workshop will have no expectation of IPR disclosure or licensing = related to its submissions. Authors are responsible for obtaining = appropriate publication clearances. >>>=20 >>>=20 >>> Program Committee >>>=20 >>> Chairs >>> David Basin (ETH Zurich) >>> Torsten Lodderstedt (YES Europe) >>>=20 >>> Members >>> John Bradley (Ping Identity) >>> Ralf K=C3=BCsters (University of Stuttgart) >>> Chris Mitchell (Royal Holloway University of London) Anthony Nadalin = (Microsoft) Nat Sakimura (Nomura Research Institute) Ralf Sasse (ETH = Zurich) J=C3=B6rg Schwenk (Ruhr University Bochum) Hannes Tschofenig = (IETF OAuth Working Group Co-Chair) >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 --Apple-Mail=_A07F901A-E103-45E3-B64A-035CA0EC2416 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi all,

I'm= pleased to announce the hosts managed to change the date of the = security workshop to the end of the week before IETF-99, July = 13-14. 

Please find the updated CfP below.

kind regards,
Torsten.

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

C a l l =     F o r     P a p e r s

Second OAuth Security Workshop (OSW 2017)

Zurich, Switzerland -- July 13-14, 2017 (note = the changed event date)

WWW: https://zisc.ethz.ch/oauth-security-workshop-2017-cfp/

Position paper submission deadline: May 2, = 2017 (AoE, UTC-12).

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

Overview

The OAuth Security Workshop (OSW) focuses on = improving security of the
OAuth standard and related = Internet protocols. This workshop brings
together the IETF = OAuth Working Group and security experts from
research, = industry, and standardization to this end. The workshop is
hosted by the Zurich Information Security and Privacy Center = at ETH Zurich.

While the standardization = process of OAuth ensures extensive reviews
(both security = and non-security related), further analysis by security
experts from academia and industry is essential to ensure = high quality
specifications. Contributions to this = workshop can help to improve the
security of the Web and = the Internet.


Scope

We seek position papers related to the = security of OAuth, OpenID
Connect, and other technologies = using OAuth under the hood.
Contributions regarding = technologies that are used in OAuth, such as
JOSE, or = impact the security of OAuth, such as Web technology, are also
welcome.


Important = Dates

Position paper submission deadline: = May 2, 2017 (AoE, UTC-12).
Author notification: May 15, = 2017.
Registration deadline: June 16, 2017.
Workshop: July 13 and July 14, 2017.


Invited Speakers

Cas Cremers, University of Oxford


Submission

We = welcome position papers that describe existing work, raise new
requirements, highlight challenges, write-ups of = implementation and
deployment experience, lessons-learned = from successful or failed
attempts, and ideas on how to = improve OAuth and OAuth extensions.

Position = papers submitted to the OAuth Security Workshop may report on
(unpublished) work in progress, be submitted to other places, = and may
even have already appeared or been accepted = elsewhere.

Submissions must be in PDF = format and should feature reasonable margins
and = formatting. There is no page limit, but the submission should be
brief (ideally not more than 3-5 pages). Submissions should = not be
anonymized.

Submission = Website: https://easychair.org/conferences/?conf=3Dosw17


Publication and Presentation

One of the authors of the accepted position = paper is expected to present
the paper at the workshop.

All presentations and papers will be put = online but there will be no
formal proceedings. Authors of = accepted papers will have the option to
revise their = papers before they are put online.


IPR Policy

The workshop will = have no expectation of IPR disclosure or licensing
related = to its submissions. Authors are responsible for obtaining
appropriate publication clearances.


Program Committee

Chairs
David Basin (ETH Zurich)
Torsten Lodderstedt (YES Europe)

Members
John Bradley (Ping Identity)
Ralf K=C3=BCsters (University of Stuttgart)
Chris= Mitchell (Royal Holloway University of London)
Anthony = Nadalin (Microsoft)
Nat Sakimura (Nomura Research = Institute)
Ralf Sasse (ETH Zurich)
J=C3=B6rg = Schwenk (Ruhr University Bochum)
Hannes Tschofenig (IETF = OAuth Working Group Co-Chair)

Am = 13.03.2017 um 21:01 schrieb John Bradley <ve7jtb@ve7jtb.com>:

I = did point out earlier when I discovered the dates, that I similarly = asked for it to be later in the week.
It is probably fine = for Europeans but it will stop many people from being able to attend = including myself unless I can come up with other meetings in Europe to = fill those days.

If we cant move it then we = will have to live with it and attend or not.

John B.

On Mar 13, 2017, at 4:46 PM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

Hi Mike,

yes, those are the = right dates. There are restrictions from the host's side, that=E2=80=99s = why the workshop needs to take place on Monday and Tuesday. As far as I = remember the host was clear about that from the beginning.

best regards,
Torsten.

Am = 12.03.2017 um 22:15 schrieb Mike Jones <Michael.Jones@microsoft.com>:

Are Monday-Tuesday, July 10-11 really the right dates? =  I'm asking because IETF in Prague doesn't start until Sunday, July = 16th.  That leaves 4 days dead time in between for those of us who = are attending both.

When I was first told = about this workshop, I was told that it would be sometime = Wednesday-Friday that week.  Can it be moved back to those dates? =  That would be a big help for those of us travelling distances to = attend.

Or is there also another event in = the Wednesday-Friday timeframe that people should also be considering = attending?

Thanks,
-- = Mike

-----Original Message-----
From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Torsten = Lodderstedt
Sent: Sunday, March 12, 2017 12:28 PM
To: oauth@ietf.org
Subject: [OAUTH-WG] Second = OAuth Security Workshop (Call for Papers)

Hi = all,

the OAuth WG and the ETH Zurich will = organize another workshop on OAuth security (after the one last year in = Trier).

Please find the Call for Papers = below.

kind regards,
Torsten.

C a l l =     F o r     P a p e r s

Second OAuth Security Workshop (OSW 2017)

Zurich, Switzerland -- July 10-11, 2017

WWW:https://zisc.ethz.ch/oauth-security-workshop-2017-cfp/

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

Overview

The OAuth Security Workshop (OSW) focuses on = improving security of the OAuth standard and related Internet protocols. = This workshop brings together the IETF OAuth Working Group and security = experts from research, industry, and standardization to this end. The = workshop is hosted by the Zurich Information Security and Privacy Center = at ETH Zurich.

While the standardization = process of OAuth ensures extensive reviews (both security and = non-security related), further analysis by security experts from = academia and industry is essential to ensure high quality = specifications. Contributions to this workshop can help to improve the = security of the Web and the Internet.


Scope

We seek position papers = related to the security of OAuth, OpenID Connect, and other technologies = using OAuth under the hood.
Contributions regarding = technologies that are used in OAuth, such as JOSE, or impact the = security of OAuth, such as Web technology, are also welcome.


Important Dates
Position paper submission deadline: May 2, 2017 (AoE, = UTC-12).
Author notification: May 15, 2017.
Registration deadline: June 16, 2017.
Workshop: = July 10 and July 11, 2017.


Invited Speakers

Cas Cremers, = University of Oxford


Submission

We welcome position = papers that describe existing work, raise new requirements, highlight = challenges, write-ups of implementation and deployment experience, = lessons-learned from successful or failed attempts, and ideas on how to = improve OAuth and OAuth extensions.

Position = papers submitted to the OAuth Security Workshop may report on
(unpublished) work in progress, be submitted to other places, = and may even have already appeared or been accepted elsewhere.

Submissions must be in PDF format and should = feature reasonable margins and formatting. There is no page limit, but = the submission should be brief (ideally not more than 3-5 pages). = Submissions should not be anonymized.

Submission Website:https://easychair.org/conferences/?conf=3Dosw17


Publication and Presentation

One of the authors of the accepted position = paper is expected to present the paper at the workshop.

All presentations and papers will be put online but there = will be no formal proceedings. Authors of accepted papers will have the = option to revise their papers before they are put online.


IPR Policy

The workshop will have no expectation of IPR disclosure or = licensing related to its submissions. Authors are responsible for = obtaining appropriate publication clearances.


Program Committee

Chairs
David Basin (ETH Zurich)
Torsten Lodderstedt (YES Europe)

Members
John Bradley (Ping Identity)
Ralf K=C3=BCsters (University of Stuttgart)
Chris= Mitchell (Royal Holloway University of London) Anthony Nadalin = (Microsoft) Nat Sakimura (Nomura Research Institute) Ralf Sasse (ETH = Zurich) J=C3=B6rg Schwenk (Ruhr University Bochum) Hannes Tschofenig = (IETF OAuth Working Group Co-Chair)

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

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


= --Apple-Mail=_A07F901A-E103-45E3-B64A-035CA0EC2416-- --Apple-Mail=_06316783-E862-4822-9811-7DC10AEBF640 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ/DCCBK8w 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 mzCCBUUwggQtoAMCAQICEDPbmsaqwjeZa3PxA3uZ8LQwDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNzAxMDkwMDAwMDBaFw0xODAx MDkyMzU5NTlaMCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArsGSzZyz9Lq9SRW9Sve5K8n5lWhplOCE6HH3gMye 12DjOpkFFZt0b73t27G17Xsp6WUxHhNevf7ck0AUpvYUPCHBqVGJSIWF9hWAoSFCgQACOoh/cDFb zz1PsMY8El7OmIus4JXtY4/VdoSIhFP3hzATbNAg32Kp+N8vtTuKTwbgnizJSyzZTYrsttn3LmwY 17HU+U9vXloMus5U/ln4ADZx0zyyDSsA6gtPxXYJpbgSTnHckVZ5zfR80guIZ538Y2qqsqt5VaSR SR2oQzE/HETkKc/odPVhqBrXLyvnSFkCPrAXV07rcvwkPvHZeYVu4QdVWyO2HIQ4i2x9r5m7SwID AQABo4IB9TCCAfEwHwYDVR0jBBgwFoAUkmFrguGioKpP7GfxwqP3tIAAwewwHQYDVR0OBBYEFPng HgVxOZ7GSji/IW4YJMBj02PHMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZ MBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7 BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9D UFMwXQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2 Q2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBkAYIKwYBBQUHAQEEgYMw gYAwWAYIKwYBBQUHMAKGTGh0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNsaWVu dEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9v Y3NwLmNvbW9kb2NhLmNvbTAiBgNVHREEGzAZgRd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDANBgkq hkiG9w0BAQsFAAOCAQEAAmueyHjiyL1qYgfe+hVSsGuKlgcvjCAfG8Jaq48tC0IjP8pH/tGi4uL9 CHVfLnV3pLDnjg6M2uvpEBp7crZZcnSPLeVss+tkhwv+F7ISYQyT4flNkqVUb8nfewbCPcIN13Ob fpU7rlXoIarEEplQo4SuymYVluQxTLOFKm5QOMF4JBMw/rjy4t95J7Mdp9NFUzQrKPJDaJ2Jr/Tc TXFcjLvNVmMBjK0959a9v1/1miRHd1DBsTh1KvBigEOUNMxvT5uUtB6/tioDZqBDDk8Gvdno/xmy e3YiasS7JgMREq5WcXqpWGu5kMFZMGPEvyPHeBZeqxx3amf4ImVnZ6WvgzGCA8MwggO/AgEBMIGw MIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdT YWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0y NTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEDPbmsaqwjeZa3Px A3uZ8LQwCQYFKw4DAhoFAKCCAecwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMTcwNDIwMTc0MjE3WjAjBgkqhkiG9w0BCQQxFgQUCODv9yKn/jKi6QcU1zlgQPvdEiMw gcEGCSsGAQQBgjcQBDGBszCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/ BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVt YWlsIENBAhAz25rGqsI3mWtz8QN7mfC0MIHDBgsqhkiG9w0BCRACCzGBs6CBsDCBmzELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBB dXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAz25rGqsI3mWtz8QN7mfC0MA0GCSqG SIb3DQEBAQUABIIBAF0dbBKCsnAYeOwza0OP1lh/UpHrK/xNsvcJ6rY5F4akxufFMplbsGXR0l0e +uCf4mPQ1wbRtGAiiDzhcaelRlI4TGmNqKlZA5bpp944YJPHaRjUsZJNyGf2Y+YVWpg6h6PjuS0b gJzeQAfk6ZSwqCRKFTy6Weg+xAHYjJQvmQ2ivWIFVH8FwvOcyzeNENF5HCDjHAvxEwSoU6+7UJz8 JaT0NUmRxPeRvD0ZoanvblpLq1O8ZZAevGWFNPU2C3TqvRpeKruIQCvFoenpVZUYrQLl983w0rtU TS0Geevip3QzlgoQgKcF58qqG6cFFY6AcMmlcqteKl05SSmbw3jNiikAAAAAAAA= --Apple-Mail=_06316783-E862-4822-9811-7DC10AEBF640-- From nobody Thu Apr 20 10:49:29 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC3511314AA for ; Thu, 20 Apr 2017 10:49:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.801 X-Spam-Level: X-Spam-Status: No, score=-4.801 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, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id doNX4h3lLFpo for ; Thu, 20 Apr 2017 10:49:24 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0129.outbound.protection.outlook.com [104.47.41.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 172CD128ACA for ; Thu, 20 Apr 2017 10:49:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=QfNfU6MCFVSc3cgbDdJrfYYEFrPJI61fi1AAe91Izg8=; b=NeNeebetZoe3V4VuV/fgSlpF2axmZtF8rDaTic175+Bf4HbqyUc2l3MnY0UPcGIcBZS3ogcmZTwJEL7+T5gY9cVLYVwWdwunD7MOI49qqQn20I9gKCqtmhA33SSdfCNXZY94UutTdzEN7tztKRq3M6z0OMQ1OvLEkG4sJ25tJ/I= Received: from BN6PR21MB0500.namprd21.prod.outlook.com (10.172.112.10) by BN6PR21MB0500.namprd21.prod.outlook.com (10.172.112.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1061.1; Thu, 20 Apr 2017 17:49:22 +0000 Received: from BN6PR21MB0500.namprd21.prod.outlook.com ([10.172.112.10]) by BN6PR21MB0500.namprd21.prod.outlook.com ([10.172.112.10]) with mapi id 15.01.1061.003; Thu, 20 Apr 2017 17:49:22 +0000 From: Mike Jones To: Torsten Lodderstedt , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Second OAuth Security Workshop (Call for Papers) Thread-Index: AQHSm2bQLtnJM11UhkObPM0YZgvrwaGRs9MggAF6bgCAAAQiAIA7kbeAgAAB78A= Date: Thu, 20 Apr 2017 17:49:22 +0000 Message-ID: References: <269DD0EC-FCBF-4691-9BAA-2B8F144C0353@lodderstedt.net> <3A9170DD-0861-478D-A9DD-9A55DC930B8D@ve7jtb.com> <4ACE4772-E01B-4D9A-8AED-7926B9E87615@lodderstedt.net> In-Reply-To: <4ACE4772-E01B-4D9A-8AED-7926B9E87615@lodderstedt.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Ref=https://api.informationprotection.azure.com/api/72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetBy=mbj@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2017-04-20T10:49:18.6247858-07:00; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General authentication-results: lodderstedt.net; dkim=none (message not signed) header.d=none;lodderstedt.net; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [50.47.93.167] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR21MB0500; 7:8VwK4qs0tULotMS166aOFMnm0Et/gPYgEL+BzQm+V1LSsWO7aTISIDZ6BiQKwJzYD8r8aMSjsWoXWQL0OAOu3uGpx//xp+6/QiQegXSG9o8FCfxrvY9EOPmaq3aNGT9aNYLBytMH4h6B8y8SThH3PRWc9phGp3HG/AEhRqWLy6s4SRjmHHwSE5xc3pcZ7y5+McHx+FYJbhFR+9EwnYBbiPJiVgYCL1JY9sjtZW1hxXlaaZMAn/n7fIYEw3whVpooGkgLoFqwY6ttyjMxtHyfkJdQwdg4tS9IyJbloOfJN9VtuclRnGxZNhFWvWwnVhneui3kcr212tzq57pTDbf2yoZN+ZP+5/51Fyp+2llWDzw= x-ms-office365-filtering-correlation-id: 408ca1f3-fc42-4ea4-fccc-08d4881593e6 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081)(201702281549075); SRVR:BN6PR21MB0500; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(209352067349851)(192374486261705)(21748063052155)(21532816269658); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406096)(20161123558043)(20161123564025)(20161123562025)(20161123560025)(20161123555025)(6072148); SRVR:BN6PR21MB0500; BCL:0; PCL:0; RULEID:; SRVR:BN6PR21MB0500; x-forefront-prvs: 02830F0362 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39840400002)(39450400003)(39860400002)(39850400002)(39410400002)(39400400002)(377454003)(13464003)(24454002)(86362001)(7736002)(122556002)(2900100001)(7906003)(15650500001)(38730400002)(5660300001)(66066001)(229853002)(53936002)(55016002)(236005)(606005)(6306002)(54896002)(76176999)(2420400007)(54356999)(9686003)(50986999)(99286003)(81166006)(8936002)(8676002)(6246003)(33656002)(6506006)(2950100002)(2501003)(25786009)(19609705001)(3280700002)(53546009)(2906002)(10710500007)(7696004)(77096006)(3660700001)(74316002)(5005710100001)(7110500001)(10090500001)(6116002)(790700001)(3846002)(93886004)(102836003)(189998001)(10290500002)(4326008)(8990500004)(225293001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR21MB0500; H:BN6PR21MB0500.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR21MB05003104D5B83C1B921AC8CAF51B0BN6PR21MB0500namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Apr 2017 17:49:22.1880 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR21MB0500 Archived-At: Subject: Re: [OAUTH-WG] Second OAuth Security Workshop (Call for Papers) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 17:49:28 -0000 --_000_BN6PR21MB05003104D5B83C1B921AC8CAF51B0BN6PR21MB0500namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RXhjZWxsZW50IQ0KDQpGcm9tOiBUb3JzdGVuIExvZGRlcnN0ZWR0IFttYWlsdG86dG9yc3RlbkBs b2RkZXJzdGVkdC5uZXRdDQpTZW50OiBUaHVyc2RheSwgQXByaWwgMjAsIDIwMTcgMTA6NDIgQU0N ClRvOiBvYXV0aEBpZXRmLm9yZw0KQ2M6IE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9z b2Z0LmNvbT47IEpvaG4gQnJhZGxleSA8dmU3anRiQHZlN2p0Yi5jb20+DQpTdWJqZWN0OiBSZTog W09BVVRILVdHXSBTZWNvbmQgT0F1dGggU2VjdXJpdHkgV29ya3Nob3AgKENhbGwgZm9yIFBhcGVy cykNCg0KSGkgYWxsLA0KDQpJJ20gcGxlYXNlZCB0byBhbm5vdW5jZSB0aGUgaG9zdHMgbWFuYWdl ZCB0byBjaGFuZ2UgdGhlIGRhdGUgb2YgdGhlIHNlY3VyaXR5IHdvcmtzaG9wIHRvIHRoZSBlbmQg b2YgdGhlIHdlZWsgYmVmb3JlIElFVEYtOTksIEp1bHkgMTMtMTQuDQoNClBsZWFzZSBmaW5kIHRo ZSB1cGRhdGVkIENmUCBiZWxvdy4NCg0Ka2luZCByZWdhcmRzLA0KVG9yc3Rlbi4NCg0KPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PQ0KDQpDIGEgbCBsICAgICBGIG8gciAgICAgUCBhIHAgZSByIHMNCg0K U2Vjb25kIE9BdXRoIFNlY3VyaXR5IFdvcmtzaG9wIChPU1cgMjAxNykNCg0KWnVyaWNoLCBTd2l0 emVybGFuZCAtLSBKdWx5IDEzLTE0LCAyMDE3IChub3RlIHRoZSBjaGFuZ2VkIGV2ZW50IGRhdGUp DQoNCldXVzogaHR0cHM6Ly96aXNjLmV0aHouY2gvb2F1dGgtc2VjdXJpdHktd29ya3Nob3AtMjAx Ny1jZnAvDQoNClBvc2l0aW9uIHBhcGVyIHN1Ym1pc3Npb24gZGVhZGxpbmU6IE1heSAyLCAyMDE3 IChBb0UsIFVUQy0xMikuDQoNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCg0KT3ZlcnZpZXcNCg0K VGhlIE9BdXRoIFNlY3VyaXR5IFdvcmtzaG9wIChPU1cpIGZvY3VzZXMgb24gaW1wcm92aW5nIHNl Y3VyaXR5IG9mIHRoZQ0KT0F1dGggc3RhbmRhcmQgYW5kIHJlbGF0ZWQgSW50ZXJuZXQgcHJvdG9j b2xzLiBUaGlzIHdvcmtzaG9wIGJyaW5ncw0KdG9nZXRoZXIgdGhlIElFVEYgT0F1dGggV29ya2lu ZyBHcm91cCBhbmQgc2VjdXJpdHkgZXhwZXJ0cyBmcm9tDQpyZXNlYXJjaCwgaW5kdXN0cnksIGFu ZCBzdGFuZGFyZGl6YXRpb24gdG8gdGhpcyBlbmQuIFRoZSB3b3Jrc2hvcCBpcw0KaG9zdGVkIGJ5 IHRoZSBadXJpY2ggSW5mb3JtYXRpb24gU2VjdXJpdHkgYW5kIFByaXZhY3kgQ2VudGVyIGF0IEVU SCBadXJpY2guDQoNCldoaWxlIHRoZSBzdGFuZGFyZGl6YXRpb24gcHJvY2VzcyBvZiBPQXV0aCBl bnN1cmVzIGV4dGVuc2l2ZSByZXZpZXdzDQooYm90aCBzZWN1cml0eSBhbmQgbm9uLXNlY3VyaXR5 IHJlbGF0ZWQpLCBmdXJ0aGVyIGFuYWx5c2lzIGJ5IHNlY3VyaXR5DQpleHBlcnRzIGZyb20gYWNh ZGVtaWEgYW5kIGluZHVzdHJ5IGlzIGVzc2VudGlhbCB0byBlbnN1cmUgaGlnaCBxdWFsaXR5DQpz cGVjaWZpY2F0aW9ucy4gQ29udHJpYnV0aW9ucyB0byB0aGlzIHdvcmtzaG9wIGNhbiBoZWxwIHRv IGltcHJvdmUgdGhlDQpzZWN1cml0eSBvZiB0aGUgV2ViIGFuZCB0aGUgSW50ZXJuZXQuDQoNCg0K U2NvcGUNCg0KV2Ugc2VlayBwb3NpdGlvbiBwYXBlcnMgcmVsYXRlZCB0byB0aGUgc2VjdXJpdHkg b2YgT0F1dGgsIE9wZW5JRA0KQ29ubmVjdCwgYW5kIG90aGVyIHRlY2hub2xvZ2llcyB1c2luZyBP QXV0aCB1bmRlciB0aGUgaG9vZC4NCkNvbnRyaWJ1dGlvbnMgcmVnYXJkaW5nIHRlY2hub2xvZ2ll cyB0aGF0IGFyZSB1c2VkIGluIE9BdXRoLCBzdWNoIGFzDQpKT1NFLCBvciBpbXBhY3QgdGhlIHNl Y3VyaXR5IG9mIE9BdXRoLCBzdWNoIGFzIFdlYiB0ZWNobm9sb2d5LCBhcmUgYWxzbw0Kd2VsY29t ZS4NCg0KDQpJbXBvcnRhbnQgRGF0ZXMNCg0KUG9zaXRpb24gcGFwZXIgc3VibWlzc2lvbiBkZWFk bGluZTogTWF5IDIsIDIwMTcgKEFvRSwgVVRDLTEyKS4NCkF1dGhvciBub3RpZmljYXRpb246IE1h eSAxNSwgMjAxNy4NClJlZ2lzdHJhdGlvbiBkZWFkbGluZTogSnVuZSAxNiwgMjAxNy4NCldvcmtz aG9wOiBKdWx5IDEzIGFuZCBKdWx5IDE0LCAyMDE3Lg0KDQoNCkludml0ZWQgU3BlYWtlcnMNCg0K Q2FzIENyZW1lcnMsIFVuaXZlcnNpdHkgb2YgT3hmb3JkDQoNCg0KU3VibWlzc2lvbg0KDQpXZSB3 ZWxjb21lIHBvc2l0aW9uIHBhcGVycyB0aGF0IGRlc2NyaWJlIGV4aXN0aW5nIHdvcmssIHJhaXNl IG5ldw0KcmVxdWlyZW1lbnRzLCBoaWdobGlnaHQgY2hhbGxlbmdlcywgd3JpdGUtdXBzIG9mIGlt cGxlbWVudGF0aW9uIGFuZA0KZGVwbG95bWVudCBleHBlcmllbmNlLCBsZXNzb25zLWxlYXJuZWQg ZnJvbSBzdWNjZXNzZnVsIG9yIGZhaWxlZA0KYXR0ZW1wdHMsIGFuZCBpZGVhcyBvbiBob3cgdG8g aW1wcm92ZSBPQXV0aCBhbmQgT0F1dGggZXh0ZW5zaW9ucy4NCg0KUG9zaXRpb24gcGFwZXJzIHN1 Ym1pdHRlZCB0byB0aGUgT0F1dGggU2VjdXJpdHkgV29ya3Nob3AgbWF5IHJlcG9ydCBvbg0KKHVu cHVibGlzaGVkKSB3b3JrIGluIHByb2dyZXNzLCBiZSBzdWJtaXR0ZWQgdG8gb3RoZXIgcGxhY2Vz LCBhbmQgbWF5DQpldmVuIGhhdmUgYWxyZWFkeSBhcHBlYXJlZCBvciBiZWVuIGFjY2VwdGVkIGVs c2V3aGVyZS4NCg0KU3VibWlzc2lvbnMgbXVzdCBiZSBpbiBQREYgZm9ybWF0IGFuZCBzaG91bGQg ZmVhdHVyZSByZWFzb25hYmxlIG1hcmdpbnMNCmFuZCBmb3JtYXR0aW5nLiBUaGVyZSBpcyBubyBw YWdlIGxpbWl0LCBidXQgdGhlIHN1Ym1pc3Npb24gc2hvdWxkIGJlDQpicmllZiAoaWRlYWxseSBu b3QgbW9yZSB0aGFuIDMtNSBwYWdlcykuIFN1Ym1pc3Npb25zIHNob3VsZCBub3QgYmUNCmFub255 bWl6ZWQuDQoNClN1Ym1pc3Npb24gV2Vic2l0ZTogaHR0cHM6Ly9lYXN5Y2hhaXIub3JnL2NvbmZl cmVuY2VzLz9jb25mPW9zdzE3DQoNCg0KUHVibGljYXRpb24gYW5kIFByZXNlbnRhdGlvbg0KDQpP bmUgb2YgdGhlIGF1dGhvcnMgb2YgdGhlIGFjY2VwdGVkIHBvc2l0aW9uIHBhcGVyIGlzIGV4cGVj dGVkIHRvIHByZXNlbnQNCnRoZSBwYXBlciBhdCB0aGUgd29ya3Nob3AuDQoNCkFsbCBwcmVzZW50 YXRpb25zIGFuZCBwYXBlcnMgd2lsbCBiZSBwdXQgb25saW5lIGJ1dCB0aGVyZSB3aWxsIGJlIG5v DQpmb3JtYWwgcHJvY2VlZGluZ3MuIEF1dGhvcnMgb2YgYWNjZXB0ZWQgcGFwZXJzIHdpbGwgaGF2 ZSB0aGUgb3B0aW9uIHRvDQpyZXZpc2UgdGhlaXIgcGFwZXJzIGJlZm9yZSB0aGV5IGFyZSBwdXQg b25saW5lLg0KDQoNCklQUiBQb2xpY3kNCg0KVGhlIHdvcmtzaG9wIHdpbGwgaGF2ZSBubyBleHBl Y3RhdGlvbiBvZiBJUFIgZGlzY2xvc3VyZSBvciBsaWNlbnNpbmcNCnJlbGF0ZWQgdG8gaXRzIHN1 Ym1pc3Npb25zLiBBdXRob3JzIGFyZSByZXNwb25zaWJsZSBmb3Igb2J0YWluaW5nDQphcHByb3By aWF0ZSBwdWJsaWNhdGlvbiBjbGVhcmFuY2VzLg0KDQoNClByb2dyYW0gQ29tbWl0dGVlDQoNCkNo YWlycw0KRGF2aWQgQmFzaW4gKEVUSCBadXJpY2gpDQpUb3JzdGVuIExvZGRlcnN0ZWR0IChZRVMg RXVyb3BlKQ0KDQpNZW1iZXJzDQpKb2huIEJyYWRsZXkgKFBpbmcgSWRlbnRpdHkpDQpSYWxmIEvD vHN0ZXJzIChVbml2ZXJzaXR5IG9mIFN0dXR0Z2FydCkNCkNocmlzIE1pdGNoZWxsIChSb3lhbCBI b2xsb3dheSBVbml2ZXJzaXR5IG9mIExvbmRvbikNCkFudGhvbnkgTmFkYWxpbiAoTWljcm9zb2Z0 KQ0KTmF0IFNha2ltdXJhIChOb211cmEgUmVzZWFyY2ggSW5zdGl0dXRlKQ0KUmFsZiBTYXNzZSAo RVRIIFp1cmljaCkNCkrDtnJnIFNjaHdlbmsgKFJ1aHIgVW5pdmVyc2l0eSBCb2NodW0pDQpIYW5u ZXMgVHNjaG9mZW5pZyAoSUVURiBPQXV0aCBXb3JraW5nIEdyb3VwIENvLUNoYWlyKQ0KDQpBbSAx My4wMy4yMDE3IHVtIDIxOjAxIHNjaHJpZWIgSm9obiBCcmFkbGV5IDx2ZTdqdGJAdmU3anRiLmNv bTxtYWlsdG86dmU3anRiQHZlN2p0Yi5jb20+PjoNCg0KSSBkaWQgcG9pbnQgb3V0IGVhcmxpZXIg d2hlbiBJIGRpc2NvdmVyZWQgdGhlIGRhdGVzLCB0aGF0IEkgc2ltaWxhcmx5IGFza2VkIGZvciBp dCB0byBiZSBsYXRlciBpbiB0aGUgd2Vlay4NCkl0IGlzIHByb2JhYmx5IGZpbmUgZm9yIEV1cm9w ZWFucyBidXQgaXQgd2lsbCBzdG9wIG1hbnkgcGVvcGxlIGZyb20gYmVpbmcgYWJsZSB0byBhdHRl bmQgaW5jbHVkaW5nIG15c2VsZiB1bmxlc3MgSSBjYW4gY29tZSB1cCB3aXRoIG90aGVyIG1lZXRp bmdzIGluIEV1cm9wZSB0byBmaWxsIHRob3NlIGRheXMuDQoNCklmIHdlIGNhbnQgbW92ZSBpdCB0 aGVuIHdlIHdpbGwgaGF2ZSB0byBsaXZlIHdpdGggaXQgYW5kIGF0dGVuZCBvciBub3QuDQoNCkpv aG4gQi4NCg0KDQpPbiBNYXIgMTMsIDIwMTcsIGF0IDQ6NDYgUE0sIFRvcnN0ZW4gTG9kZGVyc3Rl ZHQgPHRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0PG1haWx0bzp0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5l dD4+IHdyb3RlOg0KDQpIaSBNaWtlLA0KDQp5ZXMsIHRob3NlIGFyZSB0aGUgcmlnaHQgZGF0ZXMu IFRoZXJlIGFyZSByZXN0cmljdGlvbnMgZnJvbSB0aGUgaG9zdCdzIHNpZGUsIHRoYXTigJlzIHdo eSB0aGUgd29ya3Nob3AgbmVlZHMgdG8gdGFrZSBwbGFjZSBvbiBNb25kYXkgYW5kIFR1ZXNkYXku IEFzIGZhciBhcyBJIHJlbWVtYmVyIHRoZSBob3N0IHdhcyBjbGVhciBhYm91dCB0aGF0IGZyb20g dGhlIGJlZ2lubmluZy4NCg0KYmVzdCByZWdhcmRzLA0KVG9yc3Rlbi4NCg0KDQpBbSAxMi4wMy4y MDE3IHVtIDIyOjE1IHNjaHJpZWIgTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQu Y29tPG1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+PjoNCg0KQXJlIE1vbmRheS1U dWVzZGF5LCBKdWx5IDEwLTExIHJlYWxseSB0aGUgcmlnaHQgZGF0ZXM/ICBJJ20gYXNraW5nIGJl Y2F1c2UgSUVURiBpbiBQcmFndWUgZG9lc24ndCBzdGFydCB1bnRpbCBTdW5kYXksIEp1bHkgMTZ0 aC4gIFRoYXQgbGVhdmVzIDQgZGF5cyBkZWFkIHRpbWUgaW4gYmV0d2VlbiBmb3IgdGhvc2Ugb2Yg dXMgd2hvIGFyZSBhdHRlbmRpbmcgYm90aC4NCg0KV2hlbiBJIHdhcyBmaXJzdCB0b2xkIGFib3V0 IHRoaXMgd29ya3Nob3AsIEkgd2FzIHRvbGQgdGhhdCBpdCB3b3VsZCBiZSBzb21ldGltZSBXZWRu ZXNkYXktRnJpZGF5IHRoYXQgd2Vlay4gIENhbiBpdCBiZSBtb3ZlZCBiYWNrIHRvIHRob3NlIGRh dGVzPyAgVGhhdCB3b3VsZCBiZSBhIGJpZyBoZWxwIGZvciB0aG9zZSBvZiB1cyB0cmF2ZWxsaW5n IGRpc3RhbmNlcyB0byBhdHRlbmQuDQoNCk9yIGlzIHRoZXJlIGFsc28gYW5vdGhlciBldmVudCBp biB0aGUgV2VkbmVzZGF5LUZyaWRheSB0aW1lZnJhbWUgdGhhdCBwZW9wbGUgc2hvdWxkIGFsc28g YmUgY29uc2lkZXJpbmcgYXR0ZW5kaW5nPw0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBUaGFua3MsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCkZyb206IE9BdXRoIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mIFRvcnN0ZW4gTG9kZGVyc3RlZHQNClNlbnQ6IFN1bmRheSwgTWFyY2ggMTIsIDIw MTcgMTI6MjggUE0NClRvOiBvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+DQpT dWJqZWN0OiBbT0FVVEgtV0ddIFNlY29uZCBPQXV0aCBTZWN1cml0eSBXb3Jrc2hvcCAoQ2FsbCBm b3IgUGFwZXJzKQ0KDQpIaSBhbGwsDQoNCnRoZSBPQXV0aCBXRyBhbmQgdGhlIEVUSCBadXJpY2gg d2lsbCBvcmdhbml6ZSBhbm90aGVyIHdvcmtzaG9wIG9uIE9BdXRoIHNlY3VyaXR5IChhZnRlciB0 aGUgb25lIGxhc3QgeWVhciBpbiBUcmllcikuDQoNClBsZWFzZSBmaW5kIHRoZSBDYWxsIGZvciBQ YXBlcnMgYmVsb3cuDQoNCmtpbmQgcmVnYXJkcywNClRvcnN0ZW4uDQoNCkMgYSBsIGwgICAgIEYg byByICAgICBQIGEgcCBlIHIgcw0KDQpTZWNvbmQgT0F1dGggU2VjdXJpdHkgV29ya3Nob3AgKE9T VyAyMDE3KQ0KDQpadXJpY2gsIFN3aXR6ZXJsYW5kIC0tIEp1bHkgMTAtMTEsIDIwMTcNCg0KV1dX Omh0dHBzOi8vemlzYy5ldGh6LmNoL29hdXRoLXNlY3VyaXR5LXdvcmtzaG9wLTIwMTctY2ZwLw0K DQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09DQoNCk92ZXJ2aWV3DQoNClRoZSBPQXV0aCBTZWN1cml0 eSBXb3Jrc2hvcCAoT1NXKSBmb2N1c2VzIG9uIGltcHJvdmluZyBzZWN1cml0eSBvZiB0aGUgT0F1 dGggc3RhbmRhcmQgYW5kIHJlbGF0ZWQgSW50ZXJuZXQgcHJvdG9jb2xzLiBUaGlzIHdvcmtzaG9w IGJyaW5ncyB0b2dldGhlciB0aGUgSUVURiBPQXV0aCBXb3JraW5nIEdyb3VwIGFuZCBzZWN1cml0 eSBleHBlcnRzIGZyb20gcmVzZWFyY2gsIGluZHVzdHJ5LCBhbmQgc3RhbmRhcmRpemF0aW9uIHRv IHRoaXMgZW5kLiBUaGUgd29ya3Nob3AgaXMgaG9zdGVkIGJ5IHRoZSBadXJpY2ggSW5mb3JtYXRp b24gU2VjdXJpdHkgYW5kIFByaXZhY3kgQ2VudGVyIGF0IEVUSCBadXJpY2guDQoNCldoaWxlIHRo ZSBzdGFuZGFyZGl6YXRpb24gcHJvY2VzcyBvZiBPQXV0aCBlbnN1cmVzIGV4dGVuc2l2ZSByZXZp ZXdzIChib3RoIHNlY3VyaXR5IGFuZCBub24tc2VjdXJpdHkgcmVsYXRlZCksIGZ1cnRoZXIgYW5h bHlzaXMgYnkgc2VjdXJpdHkgZXhwZXJ0cyBmcm9tIGFjYWRlbWlhIGFuZCBpbmR1c3RyeSBpcyBl c3NlbnRpYWwgdG8gZW5zdXJlIGhpZ2ggcXVhbGl0eSBzcGVjaWZpY2F0aW9ucy4gQ29udHJpYnV0 aW9ucyB0byB0aGlzIHdvcmtzaG9wIGNhbiBoZWxwIHRvIGltcHJvdmUgdGhlIHNlY3VyaXR5IG9m IHRoZSBXZWIgYW5kIHRoZSBJbnRlcm5ldC4NCg0KDQpTY29wZQ0KDQpXZSBzZWVrIHBvc2l0aW9u IHBhcGVycyByZWxhdGVkIHRvIHRoZSBzZWN1cml0eSBvZiBPQXV0aCwgT3BlbklEIENvbm5lY3Qs IGFuZCBvdGhlciB0ZWNobm9sb2dpZXMgdXNpbmcgT0F1dGggdW5kZXIgdGhlIGhvb2QuDQpDb250 cmlidXRpb25zIHJlZ2FyZGluZyB0ZWNobm9sb2dpZXMgdGhhdCBhcmUgdXNlZCBpbiBPQXV0aCwg c3VjaCBhcyBKT1NFLCBvciBpbXBhY3QgdGhlIHNlY3VyaXR5IG9mIE9BdXRoLCBzdWNoIGFzIFdl YiB0ZWNobm9sb2d5LCBhcmUgYWxzbyB3ZWxjb21lLg0KDQoNCkltcG9ydGFudCBEYXRlcw0KDQpQ b3NpdGlvbiBwYXBlciBzdWJtaXNzaW9uIGRlYWRsaW5lOiBNYXkgMiwgMjAxNyAoQW9FLCBVVEMt MTIpLg0KQXV0aG9yIG5vdGlmaWNhdGlvbjogTWF5IDE1LCAyMDE3Lg0KUmVnaXN0cmF0aW9uIGRl YWRsaW5lOiBKdW5lIDE2LCAyMDE3Lg0KV29ya3Nob3A6IEp1bHkgMTAgYW5kIEp1bHkgMTEsIDIw MTcuDQoNCg0KSW52aXRlZCBTcGVha2Vycw0KDQpDYXMgQ3JlbWVycywgVW5pdmVyc2l0eSBvZiBP eGZvcmQNCg0KDQpTdWJtaXNzaW9uDQoNCldlIHdlbGNvbWUgcG9zaXRpb24gcGFwZXJzIHRoYXQg ZGVzY3JpYmUgZXhpc3Rpbmcgd29yaywgcmFpc2UgbmV3IHJlcXVpcmVtZW50cywgaGlnaGxpZ2h0 IGNoYWxsZW5nZXMsIHdyaXRlLXVwcyBvZiBpbXBsZW1lbnRhdGlvbiBhbmQgZGVwbG95bWVudCBl eHBlcmllbmNlLCBsZXNzb25zLWxlYXJuZWQgZnJvbSBzdWNjZXNzZnVsIG9yIGZhaWxlZCBhdHRl bXB0cywgYW5kIGlkZWFzIG9uIGhvdyB0byBpbXByb3ZlIE9BdXRoIGFuZCBPQXV0aCBleHRlbnNp b25zLg0KDQpQb3NpdGlvbiBwYXBlcnMgc3VibWl0dGVkIHRvIHRoZSBPQXV0aCBTZWN1cml0eSBX b3Jrc2hvcCBtYXkgcmVwb3J0IG9uDQoodW5wdWJsaXNoZWQpIHdvcmsgaW4gcHJvZ3Jlc3MsIGJl IHN1Ym1pdHRlZCB0byBvdGhlciBwbGFjZXMsIGFuZCBtYXkgZXZlbiBoYXZlIGFscmVhZHkgYXBw ZWFyZWQgb3IgYmVlbiBhY2NlcHRlZCBlbHNld2hlcmUuDQoNClN1Ym1pc3Npb25zIG11c3QgYmUg aW4gUERGIGZvcm1hdCBhbmQgc2hvdWxkIGZlYXR1cmUgcmVhc29uYWJsZSBtYXJnaW5zIGFuZCBm b3JtYXR0aW5nLiBUaGVyZSBpcyBubyBwYWdlIGxpbWl0LCBidXQgdGhlIHN1Ym1pc3Npb24gc2hv dWxkIGJlIGJyaWVmIChpZGVhbGx5IG5vdCBtb3JlIHRoYW4gMy01IHBhZ2VzKS4gU3VibWlzc2lv bnMgc2hvdWxkIG5vdCBiZSBhbm9ueW1pemVkLg0KDQpTdWJtaXNzaW9uIFdlYnNpdGU6aHR0cHM6 Ly9lYXN5Y2hhaXIub3JnL2NvbmZlcmVuY2VzLz9jb25mPW9zdzE3DQoNCg0KUHVibGljYXRpb24g YW5kIFByZXNlbnRhdGlvbg0KDQpPbmUgb2YgdGhlIGF1dGhvcnMgb2YgdGhlIGFjY2VwdGVkIHBv c2l0aW9uIHBhcGVyIGlzIGV4cGVjdGVkIHRvIHByZXNlbnQgdGhlIHBhcGVyIGF0IHRoZSB3b3Jr c2hvcC4NCg0KQWxsIHByZXNlbnRhdGlvbnMgYW5kIHBhcGVycyB3aWxsIGJlIHB1dCBvbmxpbmUg YnV0IHRoZXJlIHdpbGwgYmUgbm8gZm9ybWFsIHByb2NlZWRpbmdzLiBBdXRob3JzIG9mIGFjY2Vw dGVkIHBhcGVycyB3aWxsIGhhdmUgdGhlIG9wdGlvbiB0byByZXZpc2UgdGhlaXIgcGFwZXJzIGJl Zm9yZSB0aGV5IGFyZSBwdXQgb25saW5lLg0KDQoNCklQUiBQb2xpY3kNCg0KVGhlIHdvcmtzaG9w IHdpbGwgaGF2ZSBubyBleHBlY3RhdGlvbiBvZiBJUFIgZGlzY2xvc3VyZSBvciBsaWNlbnNpbmcg cmVsYXRlZCB0byBpdHMgc3VibWlzc2lvbnMuIEF1dGhvcnMgYXJlIHJlc3BvbnNpYmxlIGZvciBv YnRhaW5pbmcgYXBwcm9wcmlhdGUgcHVibGljYXRpb24gY2xlYXJhbmNlcy4NCg0KDQpQcm9ncmFt IENvbW1pdHRlZQ0KDQpDaGFpcnMNCkRhdmlkIEJhc2luIChFVEggWnVyaWNoKQ0KVG9yc3RlbiBM b2RkZXJzdGVkdCAoWUVTIEV1cm9wZSkNCg0KTWVtYmVycw0KSm9obiBCcmFkbGV5IChQaW5nIElk ZW50aXR5KQ0KUmFsZiBLw7xzdGVycyAoVW5pdmVyc2l0eSBvZiBTdHV0dGdhcnQpDQpDaHJpcyBN aXRjaGVsbCAoUm95YWwgSG9sbG93YXkgVW5pdmVyc2l0eSBvZiBMb25kb24pIEFudGhvbnkgTmFk YWxpbiAoTWljcm9zb2Z0KSBOYXQgU2FraW11cmEgKE5vbXVyYSBSZXNlYXJjaCBJbnN0aXR1dGUp IFJhbGYgU2Fzc2UgKEVUSCBadXJpY2gpIErDtnJnIFNjaHdlbmsgKFJ1aHIgVW5pdmVyc2l0eSBC b2NodW0pIEhhbm5lcyBUc2Nob2ZlbmlnIChJRVRGIE9BdXRoIFdvcmtpbmcgR3JvdXAgQ28tQ2hh aXIpDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpP QXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4N Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlz dA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQoNCg== --_000_BN6PR21MB05003104D5B83C1B921AC8CAF51B0BN6PR21MB0500namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uYXBwbGUtdGFiLXNwYW4NCgl7 bXNvLXN0eWxlLW5hbWU6YXBwbGUtdGFiLXNwYW47fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt c2VyaWY7DQoJY29sb3I6IzAwMjA2MDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw ZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9 IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9k eSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJX b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMw MDIwNjAiPkV4Y2VsbGVudCE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYw Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9wPg0KPHNwYW4gc3R5bGU9Im1zby1ib29r bWFyazpfTWFpbEVuZENvbXBvc2UiPjwvc3Bhbj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGlu IDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gVG9yc3RlbiBMb2RkZXJz dGVkdCBbbWFpbHRvOnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0XQ0KPGJyPg0KPGI+U2VudDo8L2I+ IFRodXJzZGF5LCBBcHJpbCAyMCwgMjAxNyAxMDo0MiBBTTxicj4NCjxiPlRvOjwvYj4gb2F1dGhA aWV0Zi5vcmc8YnI+DQo8Yj5DYzo8L2I+IE1pa2UgSm9uZXMgJmx0O01pY2hhZWwuSm9uZXNAbWlj cm9zb2Z0LmNvbSZndDs7IEpvaG4gQnJhZGxleSAmbHQ7dmU3anRiQHZlN2p0Yi5jb20mZ3Q7PGJy Pg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIFNlY29uZCBPQXV0aCBTZWN1cml0eSBX b3Jrc2hvcCAoQ2FsbCBmb3IgUGFwZXJzKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+SGkgYWxsLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+SSdtIHBsZWFzZWQgdG8gYW5ub3VuY2UgdGhlIGhvc3RzIG1hbmFnZWQgdG8gY2hhbmdl IHRoZSBkYXRlIG9mIHRoZSBzZWN1cml0eSB3b3Jrc2hvcCB0byB0aGUgZW5kIG9mIHRoZSB3ZWVr IGJlZm9yZSBJRVRGLTk5LCBKdWx5IDEzLTE0LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QbGVhc2UgZmluZCB0aGUgdXBkYXRlZCBD ZlAgYmVsb3cuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPmtpbmQgcmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlRvcnN0ZW4uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08YnI+DQo8YnI+DQpD IGEgbCBsICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO0YgbyByICZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwO1AgYSBwIGUgciBzPGJyPg0KPGJyPg0KU2Vjb25kIE9BdXRoIFNlY3VyaXR5IFdvcmtzaG9w IChPU1cgMjAxNyk8YnI+DQo8YnI+DQpadXJpY2gsIFN3aXR6ZXJsYW5kIC0tIEp1bHkgMTMtMTQs IDIwMTcgKG5vdGUgdGhlIGNoYW5nZWQgZXZlbnQgZGF0ZSk8YnI+DQo8YnI+DQpXV1c6Jm5ic3A7 PGEgaHJlZj0iaHR0cHM6Ly96aXNjLmV0aHouY2gvb2F1dGgtc2VjdXJpdHktd29ya3Nob3AtMjAx Ny1jZnAvIj5odHRwczovL3ppc2MuZXRoei5jaC9vYXV0aC1zZWN1cml0eS13b3Jrc2hvcC0yMDE3 LWNmcC88L2E+PGJyPg0KPGJyPg0KUG9zaXRpb24gcGFwZXIgc3VibWlzc2lvbiBkZWFkbGluZTog TWF5IDIsIDIwMTcgKEFvRSwgVVRDLTEyKS48YnI+DQo8YnI+DQo9PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PGJyPg0KPGJyPg0KT3ZlcnZpZXc8YnI+DQo8YnI+DQpUaGUgT0F1dGggU2VjdXJpdHkgV29y a3Nob3AgKE9TVykgZm9jdXNlcyBvbiBpbXByb3Zpbmcgc2VjdXJpdHkgb2YgdGhlPGJyPg0KT0F1 dGggc3RhbmRhcmQgYW5kIHJlbGF0ZWQgSW50ZXJuZXQgcHJvdG9jb2xzLiBUaGlzIHdvcmtzaG9w IGJyaW5nczxicj4NCnRvZ2V0aGVyIHRoZSBJRVRGIE9BdXRoIFdvcmtpbmcgR3JvdXAgYW5kIHNl Y3VyaXR5IGV4cGVydHMgZnJvbTxicj4NCnJlc2VhcmNoLCBpbmR1c3RyeSwgYW5kIHN0YW5kYXJk aXphdGlvbiB0byB0aGlzIGVuZC4gVGhlIHdvcmtzaG9wIGlzPGJyPg0KaG9zdGVkIGJ5IHRoZSBa dXJpY2ggSW5mb3JtYXRpb24gU2VjdXJpdHkgYW5kIFByaXZhY3kgQ2VudGVyIGF0IEVUSCBadXJp Y2guPGJyPg0KPGJyPg0KV2hpbGUgdGhlIHN0YW5kYXJkaXphdGlvbiBwcm9jZXNzIG9mIE9BdXRo IGVuc3VyZXMgZXh0ZW5zaXZlIHJldmlld3M8YnI+DQooYm90aCBzZWN1cml0eSBhbmQgbm9uLXNl Y3VyaXR5IHJlbGF0ZWQpLCBmdXJ0aGVyIGFuYWx5c2lzIGJ5IHNlY3VyaXR5PGJyPg0KZXhwZXJ0 cyBmcm9tIGFjYWRlbWlhIGFuZCBpbmR1c3RyeSBpcyBlc3NlbnRpYWwgdG8gZW5zdXJlIGhpZ2gg cXVhbGl0eTxicj4NCnNwZWNpZmljYXRpb25zLiBDb250cmlidXRpb25zIHRvIHRoaXMgd29ya3No b3AgY2FuIGhlbHAgdG8gaW1wcm92ZSB0aGU8YnI+DQpzZWN1cml0eSBvZiB0aGUgV2ViIGFuZCB0 aGUgSW50ZXJuZXQuPGJyPg0KPGJyPg0KPGJyPg0KU2NvcGU8YnI+DQo8YnI+DQpXZSBzZWVrIHBv c2l0aW9uIHBhcGVycyByZWxhdGVkIHRvIHRoZSBzZWN1cml0eSBvZiBPQXV0aCwgT3BlbklEPGJy Pg0KQ29ubmVjdCwgYW5kIG90aGVyIHRlY2hub2xvZ2llcyB1c2luZyBPQXV0aCB1bmRlciB0aGUg aG9vZC48YnI+DQpDb250cmlidXRpb25zIHJlZ2FyZGluZyB0ZWNobm9sb2dpZXMgdGhhdCBhcmUg dXNlZCBpbiBPQXV0aCwgc3VjaCBhczxicj4NCkpPU0UsIG9yIGltcGFjdCB0aGUgc2VjdXJpdHkg b2YgT0F1dGgsIHN1Y2ggYXMgV2ViIHRlY2hub2xvZ3ksIGFyZSBhbHNvPGJyPg0Kd2VsY29tZS48 YnI+DQo8YnI+DQo8YnI+DQpJbXBvcnRhbnQgRGF0ZXM8YnI+DQo8YnI+DQpQb3NpdGlvbiBwYXBl ciBzdWJtaXNzaW9uIGRlYWRsaW5lOiBNYXkgMiwgMjAxNyAoQW9FLCBVVEMtMTIpLjxicj4NCkF1 dGhvciBub3RpZmljYXRpb246IE1heSAxNSwgMjAxNy48YnI+DQpSZWdpc3RyYXRpb24gZGVhZGxp bmU6IEp1bmUgMTYsIDIwMTcuPGJyPg0KV29ya3Nob3A6IEp1bHkgMTMgYW5kIEp1bHkgMTQsIDIw MTcuPGJyPg0KPGJyPg0KPGJyPg0KSW52aXRlZCBTcGVha2Vyczxicj4NCjxicj4NCkNhcyBDcmVt ZXJzLCBVbml2ZXJzaXR5IG9mIE94Zm9yZDxicj4NCjxicj4NCjxicj4NClN1Ym1pc3Npb248YnI+ DQo8YnI+DQpXZSB3ZWxjb21lIHBvc2l0aW9uIHBhcGVycyB0aGF0IGRlc2NyaWJlIGV4aXN0aW5n IHdvcmssIHJhaXNlIG5ldzxicj4NCnJlcXVpcmVtZW50cywgaGlnaGxpZ2h0IGNoYWxsZW5nZXMs IHdyaXRlLXVwcyBvZiBpbXBsZW1lbnRhdGlvbiBhbmQ8YnI+DQpkZXBsb3ltZW50IGV4cGVyaWVu Y2UsIGxlc3NvbnMtbGVhcm5lZCBmcm9tIHN1Y2Nlc3NmdWwgb3IgZmFpbGVkPGJyPg0KYXR0ZW1w dHMsIGFuZCBpZGVhcyBvbiBob3cgdG8gaW1wcm92ZSBPQXV0aCBhbmQgT0F1dGggZXh0ZW5zaW9u cy48YnI+DQo8YnI+DQpQb3NpdGlvbiBwYXBlcnMgc3VibWl0dGVkIHRvIHRoZSBPQXV0aCBTZWN1 cml0eSBXb3Jrc2hvcCBtYXkgcmVwb3J0IG9uPGJyPg0KKHVucHVibGlzaGVkKSB3b3JrIGluIHBy b2dyZXNzLCBiZSBzdWJtaXR0ZWQgdG8gb3RoZXIgcGxhY2VzLCBhbmQgbWF5PGJyPg0KZXZlbiBo YXZlIGFscmVhZHkgYXBwZWFyZWQgb3IgYmVlbiBhY2NlcHRlZCBlbHNld2hlcmUuPGJyPg0KPGJy Pg0KU3VibWlzc2lvbnMgbXVzdCBiZSBpbiBQREYgZm9ybWF0IGFuZCBzaG91bGQgZmVhdHVyZSBy ZWFzb25hYmxlIG1hcmdpbnM8YnI+DQphbmQgZm9ybWF0dGluZy4gVGhlcmUgaXMgbm8gcGFnZSBs aW1pdCwgYnV0IHRoZSBzdWJtaXNzaW9uIHNob3VsZCBiZTxicj4NCmJyaWVmIChpZGVhbGx5IG5v dCBtb3JlIHRoYW4gMy01IHBhZ2VzKS4gU3VibWlzc2lvbnMgc2hvdWxkIG5vdCBiZTxicj4NCmFu b255bWl6ZWQuPGJyPg0KPGJyPg0KU3VibWlzc2lvbiBXZWJzaXRlOiZuYnNwOzxhIGhyZWY9Imh0 dHBzOi8vZWFzeWNoYWlyLm9yZy9jb25mZXJlbmNlcy8/Y29uZj1vc3cxNyI+aHR0cHM6Ly9lYXN5 Y2hhaXIub3JnL2NvbmZlcmVuY2VzLz9jb25mPW9zdzE3PC9hPjxicj4NCjxicj4NCjxicj4NClB1 YmxpY2F0aW9uIGFuZCBQcmVzZW50YXRpb248YnI+DQo8YnI+DQpPbmUgb2YgdGhlIGF1dGhvcnMg b2YgdGhlIGFjY2VwdGVkIHBvc2l0aW9uIHBhcGVyIGlzIGV4cGVjdGVkIHRvIHByZXNlbnQ8YnI+ DQp0aGUgcGFwZXIgYXQgdGhlIHdvcmtzaG9wLjxicj4NCjxicj4NCkFsbCBwcmVzZW50YXRpb25z IGFuZCBwYXBlcnMgd2lsbCBiZSBwdXQgb25saW5lIGJ1dCB0aGVyZSB3aWxsIGJlIG5vPGJyPg0K Zm9ybWFsIHByb2NlZWRpbmdzLiBBdXRob3JzIG9mIGFjY2VwdGVkIHBhcGVycyB3aWxsIGhhdmUg dGhlIG9wdGlvbiB0bzxicj4NCnJldmlzZSB0aGVpciBwYXBlcnMgYmVmb3JlIHRoZXkgYXJlIHB1 dCBvbmxpbmUuPGJyPg0KPGJyPg0KPGJyPg0KSVBSIFBvbGljeTxicj4NCjxicj4NClRoZSB3b3Jr c2hvcCB3aWxsIGhhdmUgbm8gZXhwZWN0YXRpb24gb2YgSVBSIGRpc2Nsb3N1cmUgb3IgbGljZW5z aW5nPGJyPg0KcmVsYXRlZCB0byBpdHMgc3VibWlzc2lvbnMuIEF1dGhvcnMgYXJlIHJlc3BvbnNp YmxlIGZvciBvYnRhaW5pbmc8YnI+DQphcHByb3ByaWF0ZSBwdWJsaWNhdGlvbiBjbGVhcmFuY2Vz Ljxicj4NCjxicj4NCjxicj4NClByb2dyYW0gQ29tbWl0dGVlPGJyPg0KPGJyPg0KQ2hhaXJzPGJy Pg0KRGF2aWQgQmFzaW4gKEVUSCBadXJpY2gpPGJyPg0KVG9yc3RlbiBMb2RkZXJzdGVkdCAoWUVT IEV1cm9wZSk8YnI+DQo8YnI+DQpNZW1iZXJzPGJyPg0KSm9obiBCcmFkbGV5IChQaW5nIElkZW50 aXR5KTxicj4NClJhbGYgS8O8c3RlcnMgKFVuaXZlcnNpdHkgb2YgU3R1dHRnYXJ0KTxicj4NCkNo cmlzIE1pdGNoZWxsIChSb3lhbCBIb2xsb3dheSBVbml2ZXJzaXR5IG9mIExvbmRvbik8YnI+DQpB bnRob255IE5hZGFsaW4gKE1pY3Jvc29mdCk8YnI+DQpOYXQgU2FraW11cmEgKE5vbXVyYSBSZXNl YXJjaCBJbnN0aXR1dGUpPGJyPg0KUmFsZiBTYXNzZSAoRVRIIFp1cmljaCk8YnI+DQpKw7ZyZyBT Y2h3ZW5rIChSdWhyIFVuaXZlcnNpdHkgQm9jaHVtKTxicj4NCkhhbm5lcyBUc2Nob2ZlbmlnIChJ RVRGIE9BdXRoIFdvcmtpbmcgR3JvdXAgQ28tQ2hhaXIpPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbSAxMy4wMy4yMDE3IHVtIDIxOjAxIHNj aHJpZWIgSm9obiBCcmFkbGV5ICZsdDs8YSBocmVmPSJtYWlsdG86dmU3anRiQHZlN2p0Yi5jb20i PnZlN2p0YkB2ZTdqdGIuY29tPC9hPiZndDs6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5JIGRpZCBwb2ludCBvdXQgZWFybGllciB3aGVuIEkgZGlzY292ZXJl ZCB0aGUgZGF0ZXMsIHRoYXQgSSBzaW1pbGFybHkgYXNrZWQgZm9yIGl0IHRvIGJlIGxhdGVyIGlu IHRoZSB3ZWVrLjxicj4NCkl0IGlzIHByb2JhYmx5IGZpbmUgZm9yIEV1cm9wZWFucyBidXQgaXQg d2lsbCBzdG9wIG1hbnkgcGVvcGxlIGZyb20gYmVpbmcgYWJsZSB0byBhdHRlbmQgaW5jbHVkaW5n IG15c2VsZiB1bmxlc3MgSSBjYW4gY29tZSB1cCB3aXRoIG90aGVyIG1lZXRpbmdzIGluIEV1cm9w ZSB0byBmaWxsIHRob3NlIGRheXMuPGJyPg0KPGJyPg0KSWYgd2UgY2FudCBtb3ZlIGl0IHRoZW4g d2Ugd2lsbCBoYXZlIHRvIGxpdmUgd2l0aCBpdCBhbmQgYXR0ZW5kIG9yIG5vdC48YnI+DQo8YnI+ DQpKb2huIEIuPGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPk9uIE1hciAxMywgMjAxNywgYXQgNDo0NiBQTSwgVG9yc3RlbiBMb2RkZXJzdGVk dCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0Ij50b3JzdGVuQGxv ZGRlcnN0ZWR0Lm5ldDwvYT4mZ3Q7IHdyb3RlOjxicj4NCjxicj4NCkhpIE1pa2UsPGJyPg0KPGJy Pg0KeWVzLCB0aG9zZSBhcmUgdGhlIHJpZ2h0IGRhdGVzLiBUaGVyZSBhcmUgcmVzdHJpY3Rpb25z IGZyb20gdGhlIGhvc3QncyBzaWRlLCB0aGF04oCZcyB3aHkgdGhlIHdvcmtzaG9wIG5lZWRzIHRv IHRha2UgcGxhY2Ugb24gTW9uZGF5IGFuZCBUdWVzZGF5LiBBcyBmYXIgYXMgSSByZW1lbWJlciB0 aGUgaG9zdCB3YXMgY2xlYXIgYWJvdXQgdGhhdCBmcm9tIHRoZSBiZWdpbm5pbmcuDQo8YnI+DQo8 YnI+DQpiZXN0IHJlZ2FyZHMsPGJyPg0KVG9yc3Rlbi48YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwv bzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW0gMTIuMDMuMjAxNyB1bSAyMjoxNSBz Y2hyaWViIE1pa2UgSm9uZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jv c29mdC5jb20iPk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7Ojxicj4NCjxicj4N CkFyZSBNb25kYXktVHVlc2RheSwgSnVseSAxMC0xMSByZWFsbHkgdGhlIHJpZ2h0IGRhdGVzPyAm bmJzcDtJJ20gYXNraW5nIGJlY2F1c2UgSUVURiBpbiBQcmFndWUgZG9lc24ndCBzdGFydCB1bnRp bCBTdW5kYXksIEp1bHkgMTZ0aC4gJm5ic3A7VGhhdCBsZWF2ZXMgNCBkYXlzIGRlYWQgdGltZSBp biBiZXR3ZWVuIGZvciB0aG9zZSBvZiB1cyB3aG8gYXJlIGF0dGVuZGluZyBib3RoLjxicj4NCjxi cj4NCldoZW4gSSB3YXMgZmlyc3QgdG9sZCBhYm91dCB0aGlzIHdvcmtzaG9wLCBJIHdhcyB0b2xk IHRoYXQgaXQgd291bGQgYmUgc29tZXRpbWUgV2VkbmVzZGF5LUZyaWRheSB0aGF0IHdlZWsuICZu YnNwO0NhbiBpdCBiZSBtb3ZlZCBiYWNrIHRvIHRob3NlIGRhdGVzPyAmbmJzcDtUaGF0IHdvdWxk IGJlIGEgYmlnIGhlbHAgZm9yIHRob3NlIG9mIHVzIHRyYXZlbGxpbmcgZGlzdGFuY2VzIHRvIGF0 dGVuZC48YnI+DQo8YnI+DQpPciBpcyB0aGVyZSBhbHNvIGFub3RoZXIgZXZlbnQgaW4gdGhlIFdl ZG5lc2RheS1GcmlkYXkgdGltZWZyYW1lIHRoYXQgcGVvcGxlIHNob3VsZCBhbHNvIGJlIGNvbnNp ZGVyaW5nIGF0dGVuZGluZz88YnI+DQo8YnI+DQo8c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4i PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+DQpUaGFua3Ms PGJyPg0KPHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsNCjwvc3Bhbj4tLSBNaWtlPGJyPg0KPGJyPg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS08YnI+DQpGcm9tOiBPQXV0aCBbPGEgaHJlZj0ibWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0 Zi5vcmciPm1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnPC9hPl0gT24gQmVoYWxmIE9mIFRv cnN0ZW4gTG9kZGVyc3RlZHQ8YnI+DQpTZW50OiBTdW5kYXksIE1hcmNoIDEyLCAyMDE3IDEyOjI4 IFBNPGJyPg0KVG86IDxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyI+b2F1dGhAaWV0Zi5v cmc8L2E+PGJyPg0KU3ViamVjdDogW09BVVRILVdHXSBTZWNvbmQgT0F1dGggU2VjdXJpdHkgV29y a3Nob3AgKENhbGwgZm9yIFBhcGVycyk8YnI+DQo8YnI+DQpIaSBhbGwsPGJyPg0KPGJyPg0KdGhl IE9BdXRoIFdHIGFuZCB0aGUgRVRIIFp1cmljaCB3aWxsIG9yZ2FuaXplIGFub3RoZXIgd29ya3No b3Agb24gT0F1dGggc2VjdXJpdHkgKGFmdGVyIHRoZSBvbmUgbGFzdCB5ZWFyIGluIFRyaWVyKS48 YnI+DQo8YnI+DQpQbGVhc2UgZmluZCB0aGUgQ2FsbCBmb3IgUGFwZXJzIGJlbG93Ljxicj4NCjxi cj4NCmtpbmQgcmVnYXJkcyw8YnI+DQpUb3JzdGVuLjxicj4NCjxicj4NCkMgYSBsIGwgJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7RiBvIHIgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7UCBhIHAgZSBy IHM8YnI+DQo8YnI+DQpTZWNvbmQgT0F1dGggU2VjdXJpdHkgV29ya3Nob3AgKE9TVyAyMDE3KTxi cj4NCjxicj4NClp1cmljaCwgU3dpdHplcmxhbmQgLS0gSnVseSAxMC0xMSwgMjAxNzxicj4NCjxi cj4NCldXVzo8YSBocmVmPSJodHRwczovL3ppc2MuZXRoei5jaC9vYXV0aC1zZWN1cml0eS13b3Jr c2hvcC0yMDE3LWNmcC8iPmh0dHBzOi8vemlzYy5ldGh6LmNoL29hdXRoLXNlY3VyaXR5LXdvcmtz aG9wLTIwMTctY2ZwLzwvYT48YnI+DQo8YnI+DQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PGJyPg0K PGJyPg0KT3ZlcnZpZXc8YnI+DQo8YnI+DQpUaGUgT0F1dGggU2VjdXJpdHkgV29ya3Nob3AgKE9T VykgZm9jdXNlcyBvbiBpbXByb3Zpbmcgc2VjdXJpdHkgb2YgdGhlIE9BdXRoIHN0YW5kYXJkIGFu ZCByZWxhdGVkIEludGVybmV0IHByb3RvY29scy4gVGhpcyB3b3Jrc2hvcCBicmluZ3MgdG9nZXRo ZXIgdGhlIElFVEYgT0F1dGggV29ya2luZyBHcm91cCBhbmQgc2VjdXJpdHkgZXhwZXJ0cyBmcm9t IHJlc2VhcmNoLCBpbmR1c3RyeSwgYW5kIHN0YW5kYXJkaXphdGlvbiB0byB0aGlzIGVuZC4gVGhl DQogd29ya3Nob3AgaXMgaG9zdGVkIGJ5IHRoZSBadXJpY2ggSW5mb3JtYXRpb24gU2VjdXJpdHkg YW5kIFByaXZhY3kgQ2VudGVyIGF0IEVUSCBadXJpY2guPGJyPg0KPGJyPg0KV2hpbGUgdGhlIHN0 YW5kYXJkaXphdGlvbiBwcm9jZXNzIG9mIE9BdXRoIGVuc3VyZXMgZXh0ZW5zaXZlIHJldmlld3Mg KGJvdGggc2VjdXJpdHkgYW5kIG5vbi1zZWN1cml0eSByZWxhdGVkKSwgZnVydGhlciBhbmFseXNp cyBieSBzZWN1cml0eSBleHBlcnRzIGZyb20gYWNhZGVtaWEgYW5kIGluZHVzdHJ5IGlzIGVzc2Vu dGlhbCB0byBlbnN1cmUgaGlnaCBxdWFsaXR5IHNwZWNpZmljYXRpb25zLiBDb250cmlidXRpb25z IHRvIHRoaXMgd29ya3Nob3ANCiBjYW4gaGVscCB0byBpbXByb3ZlIHRoZSBzZWN1cml0eSBvZiB0 aGUgV2ViIGFuZCB0aGUgSW50ZXJuZXQuPGJyPg0KPGJyPg0KPGJyPg0KU2NvcGU8YnI+DQo8YnI+ DQpXZSBzZWVrIHBvc2l0aW9uIHBhcGVycyByZWxhdGVkIHRvIHRoZSBzZWN1cml0eSBvZiBPQXV0 aCwgT3BlbklEIENvbm5lY3QsIGFuZCBvdGhlciB0ZWNobm9sb2dpZXMgdXNpbmcgT0F1dGggdW5k ZXIgdGhlIGhvb2QuPGJyPg0KQ29udHJpYnV0aW9ucyByZWdhcmRpbmcgdGVjaG5vbG9naWVzIHRo YXQgYXJlIHVzZWQgaW4gT0F1dGgsIHN1Y2ggYXMgSk9TRSwgb3IgaW1wYWN0IHRoZSBzZWN1cml0 eSBvZiBPQXV0aCwgc3VjaCBhcyBXZWIgdGVjaG5vbG9neSwgYXJlIGFsc28gd2VsY29tZS48YnI+ DQo8YnI+DQo8YnI+DQpJbXBvcnRhbnQgRGF0ZXM8YnI+DQo8YnI+DQpQb3NpdGlvbiBwYXBlciBz dWJtaXNzaW9uIGRlYWRsaW5lOiBNYXkgMiwgMjAxNyAoQW9FLCBVVEMtMTIpLjxicj4NCkF1dGhv ciBub3RpZmljYXRpb246IE1heSAxNSwgMjAxNy48YnI+DQpSZWdpc3RyYXRpb24gZGVhZGxpbmU6 IEp1bmUgMTYsIDIwMTcuPGJyPg0KV29ya3Nob3A6IEp1bHkgMTAgYW5kIEp1bHkgMTEsIDIwMTcu PGJyPg0KPGJyPg0KPGJyPg0KSW52aXRlZCBTcGVha2Vyczxicj4NCjxicj4NCkNhcyBDcmVtZXJz LCBVbml2ZXJzaXR5IG9mIE94Zm9yZDxicj4NCjxicj4NCjxicj4NClN1Ym1pc3Npb248YnI+DQo8 YnI+DQpXZSB3ZWxjb21lIHBvc2l0aW9uIHBhcGVycyB0aGF0IGRlc2NyaWJlIGV4aXN0aW5nIHdv cmssIHJhaXNlIG5ldyByZXF1aXJlbWVudHMsIGhpZ2hsaWdodCBjaGFsbGVuZ2VzLCB3cml0ZS11 cHMgb2YgaW1wbGVtZW50YXRpb24gYW5kIGRlcGxveW1lbnQgZXhwZXJpZW5jZSwgbGVzc29ucy1s ZWFybmVkIGZyb20gc3VjY2Vzc2Z1bCBvciBmYWlsZWQgYXR0ZW1wdHMsIGFuZCBpZGVhcyBvbiBo b3cgdG8gaW1wcm92ZSBPQXV0aCBhbmQgT0F1dGggZXh0ZW5zaW9ucy48YnI+DQo8YnI+DQpQb3Np dGlvbiBwYXBlcnMgc3VibWl0dGVkIHRvIHRoZSBPQXV0aCBTZWN1cml0eSBXb3Jrc2hvcCBtYXkg cmVwb3J0IG9uPGJyPg0KKHVucHVibGlzaGVkKSB3b3JrIGluIHByb2dyZXNzLCBiZSBzdWJtaXR0 ZWQgdG8gb3RoZXIgcGxhY2VzLCBhbmQgbWF5IGV2ZW4gaGF2ZSBhbHJlYWR5IGFwcGVhcmVkIG9y IGJlZW4gYWNjZXB0ZWQgZWxzZXdoZXJlLjxicj4NCjxicj4NClN1Ym1pc3Npb25zIG11c3QgYmUg aW4gUERGIGZvcm1hdCBhbmQgc2hvdWxkIGZlYXR1cmUgcmVhc29uYWJsZSBtYXJnaW5zIGFuZCBm b3JtYXR0aW5nLiBUaGVyZSBpcyBubyBwYWdlIGxpbWl0LCBidXQgdGhlIHN1Ym1pc3Npb24gc2hv dWxkIGJlIGJyaWVmIChpZGVhbGx5IG5vdCBtb3JlIHRoYW4gMy01IHBhZ2VzKS4gU3VibWlzc2lv bnMgc2hvdWxkIG5vdCBiZSBhbm9ueW1pemVkLjxicj4NCjxicj4NClN1Ym1pc3Npb24gV2Vic2l0 ZTo8YSBocmVmPSJodHRwczovL2Vhc3ljaGFpci5vcmcvY29uZmVyZW5jZXMvP2NvbmY9b3N3MTci Pmh0dHBzOi8vZWFzeWNoYWlyLm9yZy9jb25mZXJlbmNlcy8/Y29uZj1vc3cxNzwvYT48YnI+DQo8 YnI+DQo8YnI+DQpQdWJsaWNhdGlvbiBhbmQgUHJlc2VudGF0aW9uPGJyPg0KPGJyPg0KT25lIG9m IHRoZSBhdXRob3JzIG9mIHRoZSBhY2NlcHRlZCBwb3NpdGlvbiBwYXBlciBpcyBleHBlY3RlZCB0 byBwcmVzZW50IHRoZSBwYXBlciBhdCB0aGUgd29ya3Nob3AuPGJyPg0KPGJyPg0KQWxsIHByZXNl bnRhdGlvbnMgYW5kIHBhcGVycyB3aWxsIGJlIHB1dCBvbmxpbmUgYnV0IHRoZXJlIHdpbGwgYmUg bm8gZm9ybWFsIHByb2NlZWRpbmdzLiBBdXRob3JzIG9mIGFjY2VwdGVkIHBhcGVycyB3aWxsIGhh dmUgdGhlIG9wdGlvbiB0byByZXZpc2UgdGhlaXIgcGFwZXJzIGJlZm9yZSB0aGV5IGFyZSBwdXQg b25saW5lLjxicj4NCjxicj4NCjxicj4NCklQUiBQb2xpY3k8YnI+DQo8YnI+DQpUaGUgd29ya3No b3Agd2lsbCBoYXZlIG5vIGV4cGVjdGF0aW9uIG9mIElQUiBkaXNjbG9zdXJlIG9yIGxpY2Vuc2lu ZyByZWxhdGVkIHRvIGl0cyBzdWJtaXNzaW9ucy4gQXV0aG9ycyBhcmUgcmVzcG9uc2libGUgZm9y IG9idGFpbmluZyBhcHByb3ByaWF0ZSBwdWJsaWNhdGlvbiBjbGVhcmFuY2VzLjxicj4NCjxicj4N Cjxicj4NClByb2dyYW0gQ29tbWl0dGVlPGJyPg0KPGJyPg0KQ2hhaXJzPGJyPg0KRGF2aWQgQmFz aW4gKEVUSCBadXJpY2gpPGJyPg0KVG9yc3RlbiBMb2RkZXJzdGVkdCAoWUVTIEV1cm9wZSk8YnI+ DQo8YnI+DQpNZW1iZXJzPGJyPg0KSm9obiBCcmFkbGV5IChQaW5nIElkZW50aXR5KTxicj4NClJh bGYgS8O8c3RlcnMgKFVuaXZlcnNpdHkgb2YgU3R1dHRnYXJ0KTxicj4NCkNocmlzIE1pdGNoZWxs IChSb3lhbCBIb2xsb3dheSBVbml2ZXJzaXR5IG9mIExvbmRvbikgQW50aG9ueSBOYWRhbGluIChN aWNyb3NvZnQpIE5hdCBTYWtpbXVyYSAoTm9tdXJhIFJlc2VhcmNoIEluc3RpdHV0ZSkgUmFsZiBT YXNzZSAoRVRIIFp1cmljaCkgSsO2cmcgU2Nod2VuayAoUnVociBVbml2ZXJzaXR5IEJvY2h1bSkg SGFubmVzIFRzY2hvZmVuaWcgKElFVEYgT0F1dGggV29ya2luZyBHcm91cCBDby1DaGFpcik8YnI+ DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxi cj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9y ZyI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9vYXV0aCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRo QGlldGYub3JnIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BN6PR21MB05003104D5B83C1B921AC8CAF51B0BN6PR21MB0500namp_-- From nobody Thu Apr 20 22:17:28 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AD7A12940F for ; Thu, 20 Apr 2017 22:17:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=manicode-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qV8jT5QOQF-0 for ; Thu, 20 Apr 2017 22:17:24 -0700 (PDT) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::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 B5E5D124BFA for ; Thu, 20 Apr 2017 22:17:24 -0700 (PDT) Received: by mail-io0-x22c.google.com with SMTP id a103so104659454ioj.1 for ; Thu, 20 Apr 2017 22:17:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=manicode-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=0w1h8vlVoJCayqjTO/w1Mp67JJLvIH7oX7omvKc82Rk=; b=lto00yRgLgVfSQFAvDbr4hqLO/Aq7Fsnlr4mEfWJgahxPKgv8Rl38wQ0CHbFt1gCEC vg4WQbPXi5o8iBVULjAHiiliE5365KV/RnQ/r7kaBmuMuMyX146aPsX6zkzyDTBRmTva fqFarpgAadOvLLIJqpXc2lqMeDbZa1ht3b5tj4a3GXAPRNDA1pNUYOfr4bXPjzjfcmAj FudJ5F1mZVa9ZhWlGJsPfqdlBUmjJQpV9aDKsaROxg3Zat9ceOmi1A8y4c+uf8UlysWV onc9HrHxbihFCTPGkovTqTI/9HF0ofJPcVr8itmHNaP5LCIT+wmGJomDcqneM0hAe526 ng0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=0w1h8vlVoJCayqjTO/w1Mp67JJLvIH7oX7omvKc82Rk=; b=DU5qtLfhOMlEOzgM3GQ1fUjyFqUT7lsR8r/NkZDY8ac22RopiLEQA2GtkzOBY+thCi I1DsOjHbX9Agtgb+qpUXOaOfvwgTcbNEnQ/ZY1Xd/YA6Zy4YUvF4LqmGpWUkZHB2NU7Y zQBRDNmb8UdgFytSNzibVC1I0a3QN4SXnAXKnXXVOUIAHyIqr0T1wHa+4Y37qFTeyJ6q RBuqRcFH90QCqeyL5fbQhD55VyfJXgLQWH4KDiy0oaFVKQEe7B18EtetRR2VwxS3Vpiz UhyYzxORBdX0jqSF4JVx6S9OQshgcVDKoR+mHzMlSiygp+SJ6iouaqZqetQeRQTFq0Oi bIRw== X-Gm-Message-State: AN3rC/60Z+jtoRV79VvrZucmba/K5Ioaq3gJZkWmiIdSGWH75TyZjcME OTVdMeN1pjP24BTBX1tFTQ== X-Received: by 10.98.44.142 with SMTP id s136mr10911045pfs.244.1492751842067; Thu, 20 Apr 2017 22:17:22 -0700 (PDT) Received: from [10.67.240.225] (mobile-166-170-39-35.mycingular.net. [166.170.39.35]) by smtp.gmail.com with ESMTPSA id b74sm13323110pfl.58.2017.04.20.22.17.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Apr 2017 22:17:21 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-CE543B2F-05F0-4150-A2C2-52E191D24B11 Mime-Version: 1.0 (1.0) From: Jim Manico X-Mailer: iPhone Mail (14E304) In-Reply-To: <4ACE4772-E01B-4D9A-8AED-7926B9E87615@lodderstedt.net> Date: Fri, 21 Apr 2017 07:17:16 +0200 Cc: "oauth@ietf.org" Content-Transfer-Encoding: 7bit Message-Id: <7F32DADA-E665-4C1A-BD7F-244C63CE0F2C@manicode.com> References: <269DD0EC-FCBF-4691-9BAA-2B8F144C0353@lodderstedt.net> <3A9170DD-0861-478D-A9DD-9A55DC930B8D@ve7jtb.com> <4ACE4772-E01B-4D9A-8AED-7926B9E87615@lodderstedt.net> To: Torsten Lodderstedt Archived-At: Subject: Re: [OAUTH-WG] Second OAuth Security Workshop (Call for Papers) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 05:17:27 -0000 --Apple-Mail-CE543B2F-05F0-4150-A2C2-52E191D24B11 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I'd love to attend. 1) Can you handle remote participants? 2) Any chance you want to move this to Hawaii? I can host the work space. Se= riously. Aloha, -- Jim Manico @Manicode > On Apr 20, 2017, at 7:42 PM, Torsten Lodderstedt = wrote: >=20 > Hi all, >=20 > I'm pleased to announce the hosts managed to change the date of the securi= ty workshop to the end of the week before IETF-99, July 13-14.=20 >=20 > Please find the updated CfP below. >=20 > kind regards, > Torsten. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D >=20 > C a l l F o r P a p e r s >=20 > Second OAuth Security Workshop (OSW 2017) >=20 > Zurich, Switzerland -- July 13-14, 2017 (note the changed event date) >=20 > WWW: https://zisc.ethz.ch/oauth-security-workshop-2017-cfp/ >=20 > Position paper submission deadline: May 2, 2017 (AoE, UTC-12). >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D >=20 > Overview >=20 > The OAuth Security Workshop (OSW) focuses on improving security of the > OAuth standard and related Internet protocols. This workshop brings > together the IETF OAuth Working Group and security experts from > research, industry, and standardization to this end. The workshop is > hosted by the Zurich Information Security and Privacy Center at ETH Zurich= . >=20 > While the standardization process of OAuth ensures extensive reviews > (both security and non-security related), further analysis by security > experts from academia and industry is essential to ensure high quality > specifications. Contributions to this workshop can help to improve the > security of the Web and the Internet. >=20 >=20 > Scope >=20 > We seek position papers related to the security of OAuth, OpenID > Connect, and other technologies using OAuth under the hood. > Contributions regarding technologies that are used in OAuth, such as > JOSE, or impact the security of OAuth, such as Web technology, are also > welcome. >=20 >=20 > Important Dates >=20 > Position paper submission deadline: May 2, 2017 (AoE, UTC-12). > Author notification: May 15, 2017. > Registration deadline: June 16, 2017. > Workshop: July 13 and July 14, 2017. >=20 >=20 > Invited Speakers >=20 > Cas Cremers, University of Oxford >=20 >=20 > Submission >=20 > We welcome position papers that describe existing work, raise new > requirements, highlight challenges, write-ups of implementation and > deployment experience, lessons-learned from successful or failed > attempts, and ideas on how to improve OAuth and OAuth extensions. >=20 > Position papers submitted to the OAuth Security Workshop may report on > (unpublished) work in progress, be submitted to other places, and may > even have already appeared or been accepted elsewhere. >=20 > Submissions must be in PDF format and should feature reasonable margins > and formatting. There is no page limit, but the submission should be > brief (ideally not more than 3-5 pages). Submissions should not be > anonymized. >=20 > Submission Website: https://easychair.org/conferences/?conf=3Dosw17 >=20 >=20 > Publication and Presentation >=20 > One of the authors of the accepted position paper is expected to present > the paper at the workshop. >=20 > All presentations and papers will be put online but there will be no > formal proceedings. Authors of accepted papers will have the option to > revise their papers before they are put online. >=20 >=20 > IPR Policy >=20 > The workshop will have no expectation of IPR disclosure or licensing > related to its submissions. Authors are responsible for obtaining > appropriate publication clearances. >=20 >=20 > Program Committee >=20 > Chairs > David Basin (ETH Zurich) > Torsten Lodderstedt (YES Europe) >=20 > Members > John Bradley (Ping Identity) > Ralf K=C3=BCsters (University of Stuttgart) > Chris Mitchell (Royal Holloway University of London) > Anthony Nadalin (Microsoft) > Nat Sakimura (Nomura Research Institute) > Ralf Sasse (ETH Zurich) > J=C3=B6rg Schwenk (Ruhr University Bochum) > Hannes Tschofenig (IETF OAuth Working Group Co-Chair) >=20 >> Am 13.03.2017 um 21:01 schrieb John Bradley : >>=20 >> I did point out earlier when I discovered the dates, that I similarly ask= ed for it to be later in the week. >> It is probably fine for Europeans but it will stop many people from being= able to attend including myself unless I can come up with other meetings in= Europe to fill those days. >>=20 >> If we cant move it then we will have to live with it and attend or not. >>=20 >> John B. >>=20 >>> On Mar 13, 2017, at 4:46 PM, Torsten Lodderstedt wrote: >>>=20 >>> Hi Mike, >>>=20 >>> yes, those are the right dates. There are restrictions from the host's s= ide, that=E2=80=99s why the workshop needs to take place on Monday and Tuesd= ay. As far as I remember the host was clear about that from the beginning.=20= >>>=20 >>> best regards, >>> Torsten. >>>=20 >>>> Am 12.03.2017 um 22:15 schrieb Mike Jones = : >>>>=20 >>>> Are Monday-Tuesday, July 10-11 really the right dates? I'm asking beca= use IETF in Prague doesn't start until Sunday, July 16th. That leaves 4 day= s dead time in between for those of us who are attending both. >>>>=20 >>>> When I was first told about this workshop, I was told that it would be s= ometime Wednesday-Friday that week. Can it be moved back to those dates? T= hat would be a big help for those of us travelling distances to attend. >>>>=20 >>>> Or is there also another event in the Wednesday-Friday timeframe that p= eople should also be considering attending? >>>>=20 >>>> Thanks, >>>> -- Mike >>>>=20 >>>> -----Original Message----- >>>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Torsten Lodder= stedt >>>> Sent: Sunday, March 12, 2017 12:28 PM >>>> To: oauth@ietf.org >>>> Subject: [OAUTH-WG] Second OAuth Security Workshop (Call for Papers) >>>>=20 >>>> Hi all, >>>>=20 >>>> the OAuth WG and the ETH Zurich will organize another workshop on OAuth= security (after the one last year in Trier). >>>>=20 >>>> Please find the Call for Papers below. >>>>=20 >>>> kind regards, >>>> Torsten. >>>>=20 >>>> C a l l F o r P a p e r s >>>>=20 >>>> Second OAuth Security Workshop (OSW 2017) >>>>=20 >>>> Zurich, Switzerland -- July 10-11, 2017 >>>>=20 >>>> WWW:https://zisc.ethz.ch/oauth-security-workshop-2017-cfp/ >>>>=20 >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Overview >>>>=20 >>>> The OAuth Security Workshop (OSW) focuses on improving security of the O= Auth standard and related Internet protocols. This workshop brings together t= he IETF OAuth Working Group and security experts from research, industry, an= d standardization to this end. The workshop is hosted by the Zurich Informat= ion Security and Privacy Center at ETH Zurich. >>>>=20 >>>> While the standardization process of OAuth ensures extensive reviews (b= oth security and non-security related), further analysis by security experts= from academia and industry is essential to ensure high quality specificatio= ns. Contributions to this workshop can help to improve the security of the W= eb and the Internet. >>>>=20 >>>>=20 >>>> Scope >>>>=20 >>>> We seek position papers related to the security of OAuth, OpenID Connec= t, and other technologies using OAuth under the hood. >>>> Contributions regarding technologies that are used in OAuth, such as JO= SE, or impact the security of OAuth, such as Web technology, are also welcom= e. >>>>=20 >>>>=20 >>>> Important Dates >>>>=20 >>>> Position paper submission deadline: May 2, 2017 (AoE, UTC-12). >>>> Author notification: May 15, 2017. >>>> Registration deadline: June 16, 2017. >>>> Workshop: July 10 and July 11, 2017. >>>>=20 >>>>=20 >>>> Invited Speakers >>>>=20 >>>> Cas Cremers, University of Oxford >>>>=20 >>>>=20 >>>> Submission >>>>=20 >>>> We welcome position papers that describe existing work, raise new requi= rements, highlight challenges, write-ups of implementation and deployment ex= perience, lessons-learned from successful or failed attempts, and ideas on h= ow to improve OAuth and OAuth extensions. >>>>=20 >>>> Position papers submitted to the OAuth Security Workshop may report on >>>> (unpublished) work in progress, be submitted to other places, and may e= ven have already appeared or been accepted elsewhere. >>>>=20 >>>> Submissions must be in PDF format and should feature reasonable margins= and formatting. There is no page limit, but the submission should be brief (= ideally not more than 3-5 pages). Submissions should not be anonymized. >>>>=20 >>>> Submission Website:https://easychair.org/conferences/?conf=3Dosw17 >>>>=20 >>>>=20 >>>> Publication and Presentation >>>>=20 >>>> One of the authors of the accepted position paper is expected to presen= t the paper at the workshop. >>>>=20 >>>> All presentations and papers will be put online but there will be no fo= rmal proceedings. Authors of accepted papers will have the option to revise t= heir papers before they are put online. >>>>=20 >>>>=20 >>>> IPR Policy >>>>=20 >>>> The workshop will have no expectation of IPR disclosure or licensing re= lated to its submissions. Authors are responsible for obtaining appropriate p= ublication clearances. >>>>=20 >>>>=20 >>>> Program Committee >>>>=20 >>>> Chairs >>>> David Basin (ETH Zurich) >>>> Torsten Lodderstedt (YES Europe) >>>>=20 >>>> Members >>>> John Bradley (Ping Identity) >>>> Ralf K=C3=BCsters (University of Stuttgart) >>>> Chris Mitchell (Royal Holloway University of London) Anthony Nadalin (M= icrosoft) Nat Sakimura (Nomura Research Institute) Ralf Sasse (ETH Zurich) J= =C3=B6rg Schwenk (Ruhr University Bochum) Hannes Tschofenig (IETF OAuth Work= ing Group Co-Chair) >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-CE543B2F-05F0-4150-A2C2-52E191D24B11 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I'd love to attend.

1) Can you handle= remote participants?
2) Any chance you w= ant to move this to Hawaii? I can host the work space. Seriously.

Aloha,
--
Jim Manico
@Man= icode

On Apr 20, 2017, at 7:42 PM, Torsten Lodderstedt &= lt;torsten@lodderstedt.net>= ; wrote:

Hi all,

I'm pleased to announce the hosts managed to= change the date of the security workshop to the end of the week before IETF-= 99, July 13-14. 

Please find the updated CfP below.

kind regards,
Torsten.

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

C a l l     F o r     P a p e r s=

Second OAuth Security Workshop (OSW 2017)

Zurich, Switzerland -- July 13-14, 2017 (note the c= hanged event date)

WWW: https://zisc.eth= z.ch/oauth-security-workshop-2017-cfp/

Posi= tion paper submission deadline: May 2, 2017 (AoE, UTC-12).
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D

Overview

The OAuth Security Workshop (OSW) focuses on improving security of th= e
OAuth standard and related Internet protocols. This workshop= brings
together the IETF OAuth Working Group and security exp= erts from
research, industry, and standardization to this end.= The workshop is
hosted by the Zurich Information Security and= Privacy Center at ETH Zurich.

While the standa= rdization process of OAuth ensures extensive reviews
(both sec= urity and non-security related), further analysis by security
= experts from academia and industry is essential to ensure high quality
specifications. Contributions to this workshop can help to improve t= he
security of the Web and the Internet.


Scope

We seek position p= apers related to the security of OAuth, OpenID
Connect, and ot= her technologies using OAuth under the hood.
Contributions reg= arding technologies that are used in OAuth, such as
JOSE, or i= mpact the security of OAuth, such as Web technology, are also
= welcome.


Important Dates

Position paper submission deadline: May 2, 2017 (AoE, U= TC-12).
Author notification: May 15, 2017.
Regis= tration deadline: June 16, 2017.
Workshop: July 13 and July 14= , 2017.


Invited Speakers

Cas Cremers, University of Oxford


Submission

We welcome p= osition papers that describe existing work, raise new
requirem= ents, highlight challenges, write-ups of implementation and
de= ployment experience, lessons-learned from successful or failed
attempts, and ideas on how to improve OAuth and OAuth extensions.

Position papers submitted to the OAuth Security Workshop m= ay report on
(unpublished) work in progress, be submitted to o= ther places, and may
even have already appeared or been accept= ed elsewhere.

Submissions must be in PDF format= and should feature reasonable margins
and formatting. There i= s no page limit, but the submission should be
brief (ideally n= ot more than 3-5 pages). Submissions should not be
anonymized.=

Submission Website: https://easychair.org/conf= erences/?conf=3Dosw17


Public= ation and Presentation

One of the authors of th= e accepted position paper is expected to present
the paper at t= he workshop.

All presentations and papers will b= e put online but there will be no
formal proceedings. Authors o= f accepted papers will have the option to
revise their papers b= efore they are put online.


IPR P= olicy

The workshop will have no expectation of I= PR disclosure or licensing
related to its submissions. Authors= are responsible for obtaining
appropriate publication clearan= ces.


Program Committee

Chairs
David Basin (ETH Zurich)
Torsten Lodderstedt (YES Europe)

Members
John Bradley (Ping Identity)
Ralf K=C3=BCsters (Univ= ersity of Stuttgart)
Chris Mitchell (Royal Holloway University= of London)
Anthony Nadalin (Microsoft)
Nat Saki= mura (Nomura Research Institute)
Ralf Sasse (ETH Zurich)
J=C3=B6rg Schwenk (Ruhr University Bochum)
Hannes Tsc= hofenig (IETF OAuth Working Group Co-Chair)

Am 13.03.2017 u= m 21:01 schrieb John Bradley <ve7jtb@ve7jtb.com>:

<= div class=3D"">
I did point out earlier when I discovered the= dates, that I similarly asked for it to be later in the week.
It is probably fine for Europeans but it will stop many people from being a= ble to attend including myself unless I can come up with other meetings in E= urope to fill those days.

If we cant move it th= en we will have to live with it and attend or not.

John B.

On Mar 13, 2017, at 4:46 PM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

Hi Mike,

yes, those are= the right dates. There are restrictions from the host's side, that=E2=80=99= s why the workshop needs to take place on Monday and Tuesday. As far as I re= member the host was clear about that from the beginning.

best regards,
Torsten.

=
Am 12.03.2017 um 22:15 schrieb Mike Jon= es <Michael.Jon= es@microsoft.com>:

Are Monday-Tuesday, J= uly 10-11 really the right dates?  I'm asking because IETF in Prague do= esn't start until Sunday, July 16th.  That leaves 4 days dead time in b= etween for those of us who are attending both.

= When I was first told about this workshop, I was told that it would be somet= ime Wednesday-Friday that week.  Can it be moved back to those dates? &= nbsp;That would be a big help for those of us travelling distances to attend= .

Or is there also another event in the Wednesd= ay-Friday timeframe that people should also be considering attending?

= Than= ks,
= -- Mike

-----Original Message-----
From: OAut= h [mailto:oauth-bounces= @ietf.org] On Behalf Of Torsten Lodderstedt
Sent: Sunday, M= arch 12, 2017 12:28 PM
To: oauth@ietf.org
Subject: [OAUTH-WG] Second OAuth S= ecurity Workshop (Call for Papers)

Hi all,

the OAuth WG and the ETH Zurich will organize anoth= er workshop on OAuth security (after the one last year in Trier).

Please find the Call for Papers below.

kind regards,
Torsten.

= C a l l     F o r     P a p e r s
Second OAuth Security Workshop (OSW 2017)

Zurich, Switzerland -- July 10-11, 2017
=
WWW:https://zisc.ethz.ch/oauth-security-workshop-2017-cfp/<= /a>

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

Overview
The OAuth Security Workshop (OSW) focuses on imp= roving security of the OAuth standard and related Internet protocols. This w= orkshop brings together the IETF OAuth Working Group and security experts fr= om research, industry, and standardization to this end. The workshop is host= ed by the Zurich Information Security and Privacy Center at ETH Zurich.

While the standardization process of OAuth ensures e= xtensive reviews (both security and non-security related), further analysis b= y security experts from academia and industry is essential to ensure high qu= ality specifications. Contributions to this workshop can help to improve the= security of the Web and the Internet.


Scope

We seek position papers related to= the security of OAuth, OpenID Connect, and other technologies using OAuth u= nder the hood.
Contributions regarding technologies that are u= sed in OAuth, such as JOSE, or impact the security of OAuth, such as Web tec= hnology, are also welcome.


Impor= tant Dates

Position paper submission deadline: M= ay 2, 2017 (AoE, UTC-12).
Author notification: May 15, 2017.Registration deadline: June 16, 2017.
Workshop: J= uly 10 and July 11, 2017.


Invite= d Speakers

Cas Cremers, University of Oxford

Submission

We welcome position papers that describe existing work, raise new requ= irements, highlight challenges, write-ups of implementation and deployment e= xperience, lessons-learned from successful or failed attempts, and ideas on h= ow to improve OAuth and OAuth extensions.

Posit= ion papers submitted to the OAuth Security Workshop may report on
(unpublished) work in progress, be submitted to other places, and may eve= n have already appeared or been accepted elsewhere.

Submissions must be in PDF format and should feature reasonable margins a= nd formatting. There is no page limit, but the submission should be brief (i= deally not more than 3-5 pages). Submissions should not be anonymized.

Submission Website:https://easychair.org/conferences/?con= f=3Dosw17


Publication and Pr= esentation

One of the authors of the accepted p= osition paper is expected to present the paper at the workshop.

All presentations and papers will be put online but there w= ill be no formal proceedings. Authors of accepted papers will have the optio= n to revise their papers before they are put online.


IPR Policy

The workshop wi= ll have no expectation of IPR disclosure or licensing related to its submiss= ions. Authors are responsible for obtaining appropriate publication clearanc= es.


Program Committee

Chairs
David Basin (ETH Zurich)
Torsten Lodderstedt (YES Europe)

Members
John Bradley (Ping Identity)
Ralf K=C3=BCsters (Univ= ersity of Stuttgart)
Chris Mitchell (Royal Holloway University= of London) Anthony Nadalin (Microsoft) Nat Sakimura (Nomura Research Instit= ute) Ralf Sasse (ETH Zurich) J=C3=B6rg Schwenk (Ruhr University Bochum) Hann= es Tschofenig (IETF OAuth Working Group Co-Chair)

_______________________________________________
OAuth maili= ng list
OAuth@iet= f.org
https://www.ietf.org/mailman/listinfo/oauth

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


=
______________= _________________________________
OAuth mailing list<= br>OAuth@ietf.org
https://www.ietf.o= rg/mailman/listinfo/oauth
= --Apple-Mail-CE543B2F-05F0-4150-A2C2-52E191D24B11-- From nobody Thu Apr 20 22:36:49 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CC9C124BFA for ; Thu, 20 Apr 2017 22:36:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=teamtelstra.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eAMXY56YzNlG for ; Thu, 20 Apr 2017 22:36:45 -0700 (PDT) Received: from ipxdno.tcif.telstra.com.au (ipxdno.tcif.telstra.com.au [203.35.82.212]) (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 548631252BA for ; Thu, 20 Apr 2017 22:36:45 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.37,228,1488805200"; d="scan'208";a="5468263" Received: from unknown (HELO ipcbni.tcif.telstra.com.au) ([10.97.216.204]) by ipodni.tcif.telstra.com.au with ESMTP; 21 Apr 2017 15:36:42 +1000 X-IronPort-AV: E=McAfee;i="5800,7501,8504"; a="350776310" Received: from wsmsg3755.srv.dir.telstra.com ([172.49.40.196]) by ipcbni.tcif.telstra.com.au with ESMTP; 21 Apr 2017 15:36:37 +1000 Received: from wsapp5585.srv.dir.telstra.com (10.75.3.67) by wsmsg3755.srv.dir.telstra.com (172.49.40.196) with Microsoft SMTP Server (TLS) id 8.3.485.1; Fri, 21 Apr 2017 15:34:01 +1000 Received: from wsapp5584.srv.dir.telstra.com (10.75.131.20) by wsapp5585.srv.dir.telstra.com (10.75.3.67) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Fri, 21 Apr 2017 15:34:00 +1000 Received: from AUS01-ME1-obe.outbound.protection.outlook.com (10.172.229.125) by wsapp5584.srv.dir.telstra.com (10.75.131.20) with Microsoft SMTP Server (TLS) id 15.0.1236.3 via Frontend Transport; Fri, 21 Apr 2017 15:34:00 +1000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=teamtelstra.onmicrosoft.com; s=selector1-team-telstra-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=1K0KXohMZAB38bnd5BzJhscuhVfp/RLlpbAeEk4iGzk=; b=njeRTS07wa8gc5PbXfBe2eE+c3J1AGORFnKZZUiqsQfTmn089o/5AnOP8SsS+qOZ17gD/k2HzCkKr5Q9BK/DPs7FAcaR2aacNeIpNcB0YqyGbqnh1V3SKrjMmt9WapT4BWl9xQTcTSeo3BDzpv5Nwp4ulfP6LirBwJJ9dIaeh/w= Received: from MEXPR01MB1382.ausprd01.prod.outlook.com (10.171.18.21) by MEXPR01MB1383.ausprd01.prod.outlook.com (10.171.18.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.10; Fri, 21 Apr 2017 05:33:59 +0000 Received: from MEXPR01MB1382.ausprd01.prod.outlook.com ([10.171.18.21]) by MEXPR01MB1382.ausprd01.prod.outlook.com ([10.171.18.21]) with mapi id 15.01.1034.018; Fri, 21 Apr 2017 05:33:59 +0000 From: "Manger, James" To: "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Call for Adoption: Mutual TLS Profiles for OAuth Clients Thread-Index: AQHSufPijMHl+jcM50+lEDouBjGFMKHPP5Jw Date: Fri, 21 Apr 2017 05:33:59 +0000 Message-ID: References: <95776354-79e3-caa7-ba60-84cfec7f899f@gmx.net> In-Reply-To: <95776354-79e3-caa7-ba60-84cfec7f899f@gmx.net> Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=team.telstra.com; x-originating-ip: [203.35.185.244] x-microsoft-exchange-diagnostics: 1; MEXPR01MB1383; 7:vJvdlozNVjC1phWArXN2ZwYVJW0itv9A6GtkbMtXfGBaQ54ldgmZ0l9S15w4dwaLq6dilOhT/dwtN04vKPgulQMCVgAlhyqioD3v75e+agX1gnghWwh8l0JYL0Un0Co2ppeL0077YBUFzhxflA15HaumKGtvAV5DelNk1UhHwG2KLzfcDroW9sYBuAxJAIZstODtofQi6UuGyeGX9lnbohDeg7hxEOzf+nxHGmGnTAfZDOrMufsVGR7Gw1swU8OLAi9uwnKZawfesdzmyomSSkGkJwF/x4CTJP6TlmRWlGLK5BhqlFn9skgjoOKsCD/UMogkeptBmJoH00aDjmmOoA== x-ms-office365-filtering-correlation-id: 2f41b710-2c4b-4bcf-cfcb-08d48878032e x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:MEXPR01MB1383; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(6041248)(20161123562025)(20161123560025)(20161123564025)(20161123555025)(201703131423075)(201703061421075)(201703161042150)(6072148)(6042181); SRVR:MEXPR01MB1383; BCL:0; PCL:0; RULEID:; SRVR:MEXPR01MB1383; x-forefront-prvs: 02843AA9E0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(1730700003)(8936002)(2501003)(2900100001)(8676002)(122556002)(5660300001)(50986999)(76176999)(6116002)(2906002)(54356999)(102836003)(3280700002)(3846002)(3660700001)(110136004)(38730400002)(189998001)(53936002)(86362001)(7736002)(6506006)(74316002)(6306002)(2351001)(55016002)(305945005)(9686003)(66066001)(33656002)(99286003)(25786009)(7696004)(2950100002)(6916009)(77096006)(229853002)(42882006)(6436002)(6246003)(5640700003); DIR:OUT; SFP:1102; SCL:1; SRVR:MEXPR01MB1383; H:MEXPR01MB1382.ausprd01.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Apr 2017 05:33:59.5203 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 49dfc6a3-5fb7-49f4-adea-c54e725bb854 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MEXPR01MB1383 X-OriginatorOrg: team.telstra.com Archived-At: Subject: Re: [OAUTH-WG] Call for Adoption: Mutual TLS Profiles for OAuth Clients X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 05:36:48 -0000 SSBzdXBwb3J0IGFkb3B0aW9uIG9mIGRyYWZ0LWNhbXBiZWxsLW9hdXRoLW10bHMuDQoNCk5vdyBz b21lIGNvbW1lbnRzIG9uIHRoZSBkb2M6DQoNCjEuIFvCpzIuM10gVGhlIHN5bnRheCBvZiB0bHNf Y2xpZW50X2F1dGhfc3ViamVjdF9kbiBpcyBub3Qgc3BlY2lmaWVkLiBQZXJoYXBzIExEQVAncyAi U3RyaW5nIFJlcHJlc2VudGF0aW9uIG9mIERpc3Rpbmd1aXNoZWQgTmFtZXMiIFtSRkM0NTE0XT8g UGVyaGFwcyBhIGJhc2U2NHVybC1lbmNvZGluZyBvZiBhIERFUi1lbmNvZGVkIEROPw0KSXQgd291 bGQgYWN0dWFsbHkgYmUgYmV0dGVyIHRvIGFsbG93IGFueSBzdWJqZWN0QWx0TmFtZSB0byBiZSBz cGVjaWZpZWQsIGluc3RlYWQgb2YgYSBETi4NCg0KMi4gW8KnMi4zXSBDaGFuZ2UgdGhlIG5hbWUg b2YgdGxzX2NsaWVudF9hdXRoX2lzc3Vlcl9kbiAobWF5YmUgdGxzX2NsaWVudF9hdXRoX3Jvb3Rf ZG4pLiBHaXZlbiB0bHNfY2xpZW50X2F1dGhfY2xpZW50X2RuLCBpdCB3aWxsIGJlIHRvbyBlYXN5 IHRvIGFzc3VtZSB0aGlzIHBhaXIgcmVmZXIgdG8gdGhlIGlzc3VlciBhbmQgc3ViamVjdCBmaWVs ZHMgb2YgdGhlIGNlcnQuDQpQS0kgY2hhaW5zIGNhbiBiZSBjb21wbGV4IHNvIHRoZSBleHBlY3Rl ZCByb290IG1pZ2h0IG5vdCBiZSBzdWNoIGEgc3RhYmxlIGNvbmNlcHQuIEZvciBleGFtcGxlLCB0 aGUgTGV0J3MgRW5jcnlwdCBDQSBjaGFpbnMgdG8gYW4gSVNSRyBSb290IGFuZCBhbiBJZGVuVHJ1 c3QgRFNUIFJvb3QgW2h0dHBzOi8vbGV0c2VuY3J5cHQub3JnL2NlcnRpZmljYXRlcy9dLg0KDQoz LiBbwqcyLjNdIElmIGEgY2xpZW50IGR5bmFtaWNhbGx5IHJlZ2lzdGVycyBhICJqd2tzX3VyaSIg ZG9lcyB0aGlzIG1lYW4gdGhlIGF1dGh6IHNlcnZlciBNVVNUIGF1dG9tYXRpY2FsbHkgY29wZSB3 aGVuIHRoZSBjbGllbnQgdXBkYXRlcyB0aGUga2V5KHMpIGl0IHB1Ymxpc2hlcyB0aGVyZT8NCg0K NC4gW8KnM10gQW4gYWNjZXNzIHRva2VuIGlzIGJvdW5kIHRvIGEgc3BlY2lmaWMgY2xpZW50IGNl cnRpZmljYXRlLiBUaGF0IGlzIHByb2JhYmx5IG9rLCBidXQgZG9lcyBtZWFuIGFsbCBhY2Nlc3Mg dG9rZW5zIGRpZSB3aGVuIHRoZSBjbGllbnQgdXBkYXRlcyB0aGVpciBjZXJ0aWZpY2F0ZSAod2hp Y2ggY291bGQgYmUgZXZlcnkgMiBtb250aHMgaWYgdXNpbmcgTGV0J3MgRW5jcnlwdCkuIFRoaXMg YXQgbGVhc3Qgd2FycmFudHMgYSBwYXJhZ3JhcGggaW4gdGhlIFNlY3VyaXR5IENvbnNpZGVyYXRp b25zLg0KDQo1LiBbwqczLjFdICJleHAiIGFuZCAibmJmIiB2YWx1ZXMgaW4gdGhlIGV4YW1wbGUg bmVlZCB0byBiZSBudW1iZXJzLCBub3Qgc3RyaW5ncyAoZHJvcCB0aGUgcXVvdGVzKS4NCg0KNi4g QW4gYWNjZXNzIHRva2VuIGxpbmtlZCB0byBhIGNsaWVudCBUTFMgY2VydCBpc24ndCBhIGJlYXJl ciB0b2tlbi4gVGhlIHNwZWMgc2hvdWxkIHJlYWxseSBkZWZpbmUgYSBuZXcgdG9rZW5fdHlwZSBm b3IgcmVzcG9uc2VzIGZyb20gdGhlIHRva2VuIGVuZHBvaW50LiBUaGF0IG1pZ2h0IG5vdCBuZWNl c3NhcmlseSBtZWFuIHdlIG5lZWRzIGEgbmV3IEhUVFAgYXV0aGVudGljYXRpb24gc2NoZW1lIGFz IHdlbGwgKGl0IG1pZ2h0IGp1c3QgaGludCB0aGF0ICJCZWFyZXIiIHdhc24ndCBxdWl0ZSB0aGUg cmlnaHQgbmFtZSkuDQoNCi0tDQpKYW1lcyBNYW5nZXINCg== From nobody Thu Apr 20 22:47:43 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E07D12704B for ; Thu, 20 Apr 2017 22:47:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-2.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g5YJiNK8SVck for ; Thu, 20 Apr 2017 22:47:40 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6776124BFA for ; Thu, 20 Apr 2017 22:47:40 -0700 (PDT) Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v3L5lbbb031016 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 21 Apr 2017 05:47:37 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id v3L5laH7025207 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 21 Apr 2017 05:47:36 GMT Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id v3L5lanW001192; Fri, 21 Apr 2017 05:47:36 GMT Received: from [192.168.1.13] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 20 Apr 2017 22:47:35 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: "Phil Hunt (IDM)" X-Mailer: iPhone Mail (14E304) In-Reply-To: <05BD7891-FEA8-4D18-A2A4-258C0A353621@ve7jtb.com> Date: Thu, 20 Apr 2017 22:47:34 -0700 Cc: Hannes Tschofenig , "oauth@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <0065D823-8429-4B6A-ADCB-5B5217DA3F80@oracle.com> References: <95776354-79e3-caa7-ba60-84cfec7f899f@gmx.net> <05BD7891-FEA8-4D18-A2A4-258C0A353621@ve7jtb.com> To: John Bradley X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Subject: Re: [OAUTH-WG] Call for Adoption: Mutual TLS Profiles for OAuth Clients X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 05:47:42 -0000 +1 for adoption=20 Phil > On Apr 20, 2017, at 10:40 AM, John Bradley wrote: >=20 > I accept the adoption as a starting point. >=20 > John B. >=20 >> On Apr 20, 2017, at 1:32 PM, Hannes Tschofenig wrote: >>=20 >> Hi all, >>=20 >> based on the strong support for this document at the Chicago IETF >> meeting we are issuing a call for adoption of the "Mutual TLS Profiles >> for OAuth Clients" document, see >> https://tools.ietf.org/html/draft-campbell-oauth-mtls-01 >>=20 >> Please let us know by May 4th whether you accept / object to the >> adoption of this document as a starting point for work in the OAuth >> working group. >>=20 >> Ciao >> Hannes & Rifaat >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Fri Apr 21 02:32:05 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 620F7129426 for ; Fri, 21 Apr 2017 02:32:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.688 X-Spam-Level: X-Spam-Status: No, score=-2.688 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=momentumft.co.uk 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 NKztIKbqoJja for ; Fri, 21 Apr 2017 02:32:02 -0700 (PDT) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::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 DA40A129A8D for ; Fri, 21 Apr 2017 02:32:01 -0700 (PDT) Received: by mail-io0-x22c.google.com with SMTP id r16so106764925ioi.2 for ; Fri, 21 Apr 2017 02:32:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=momentumft.co.uk; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6XsbT481k3Tl5pkgzwkbkacj6B+FdzOPf0Qi4iqhdrk=; b=NgCFLBRTJMFqjNWJ9Qg8JupvdUI0JI9fvSYUVYS4Mgq4+AAJbkVAgHJrxHOctdRXPW FCzgmpJ6DjyaxEWLFMNlAZYprGUn5b2S7Tbs3AZweXs6nr2GoZknPwUNGIbuuLmaEZ4M zRnBBN6v5dhcCgYWLXzsUBVUpt3MrcqtoqDbE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=6XsbT481k3Tl5pkgzwkbkacj6B+FdzOPf0Qi4iqhdrk=; b=a7iJNIZKXlJW98QWFN8zpAq5sVupj2N4GkkzdYcNASv6g6wmfGdCW1P1Y5PHJw3fb9 pcikf0syYtpoC50UTSVODKDyFsfbPfSekOwCrBbyFIeK3P+45Ox72VneW3mElWc6/r1k pTaM4T9mQcSwlYf8Vro6+po8xa5UyrLjoK3KvorawU7JTfZ6DG720hW5BX1waOlxIRRb WTLxpHw/vTo7CKh/zNa/LcejrQy+VTetKPwzSWalPcoHd3hZn62/tpoGbopWg79f3aks 0o80Glsp/vtuz2F6XcBqf6smSPwt2kPqDct0Pztxjsbro2vGh0Eivtpes7qN43ax4Co9 /Yiw== X-Gm-Message-State: AN3rC/5c13x0ygJsmb9Lriuhv60DyY8A+Ei+HVdX3KISIgy4tXZByOHA c+yHl6WsLBMJzzxT+E+1eIIaLza3xypJ X-Received: by 10.36.230.5 with SMTP id e5mr9510837ith.0.1492767120102; Fri, 21 Apr 2017 02:32:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.170 with HTTP; Fri, 21 Apr 2017 02:31:39 -0700 (PDT) In-Reply-To: <95776354-79e3-caa7-ba60-84cfec7f899f@gmx.net> References: <95776354-79e3-caa7-ba60-84cfec7f899f@gmx.net> From: Dave Tonge Date: Fri, 21 Apr 2017 10:31:39 +0100 Message-ID: To: Hannes Tschofenig Cc: "oauth@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c11c82eed5ed4054da9edb9 Archived-At: Subject: Re: [OAUTH-WG] Call for Adoption: Mutual TLS Profiles for OAuth Clients X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 09:32:04 -0000 --94eb2c11c82eed5ed4054da9edb9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I support adoption of draft-campbell-oauth-mtls As previously mentioned this spec will be very useful for Europe where there is legislation requiring the use of certificate-based authentication and many financial groups and institutions are considering OAuth2. The UK Open Banking Implementation Entity has a strong interest in using this spec. Dave On 20 April 2017 at 17:32, Hannes Tschofenig wrote: > Hi all, > > based on the strong support for this document at the Chicago IETF > meeting we are issuing a call for adoption of the "Mutual TLS Profiles > for OAuth Clients" document, see > https://tools.ietf.org/html/draft-campbell-oauth-mtls-01 > > Please let us know by May 4th whether you accept / object to the > adoption of this document as a starting point for work in the OAuth > working group. > > Ciao > Hannes & Rifaat > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --=20 Dave Tonge CTO [image: Moneyhub Enterprise] 10 Temple Back, Bristol, BS1 6FL t: +44 (0)117 280 5120 Moneyhub Enterprise is a trading style of Momentum Financial Technology Limited which is authorised and regulated by the Financial Conduct Authority ("FCA"). Momentum Financial Technology is entered on the Financial Services Register (FRN 561538) at fca.org.uk/register. Momentum Financial Technology is registered in England & Wales, company registration number 06909772 =C2=A9 . Momentum Financial Technology Limited 2016. DISCLA= IMER: This email (including any attachments) is subject to copyright, and the information in it is confidential. Use of this email or of any information in it other than by the addressee is unauthorised and unlawful. Whilst reasonable efforts are made to ensure that any attachments are virus-free, it is the recipient's sole responsibility to scan all attachments for viruses. All calls and emails to and from this company may be monitored and recorded for legitimate purposes relating to this company's business. Any opinions expressed in this email (or in any attachments) are those of the author and do not necessarily represent the opinions of Momentum Financial Technology Limited or of any other group company. --94eb2c11c82eed5ed4054da9edb9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I support adoption of draft-campbell-oauth-mtls
<= /div>

As previously mentioned this spec will be very useful f= or Europe where there is legislation requiring the use of certificate-based= authentication and many financial groups and institutions are considering = OAuth2.
=C2=A0
The UK Open Banking Implementation Ent= ity=C2=A0has a strong interest in using this spec.

=
Dave

On 20 April 2017 at 17:32, Hannes Tschofenig &= lt;hannes.ts= chofenig@gmx.net> wrote:
Hi= all,

based on the strong support for this document at the Chicago IETF
meeting we are issuing a call for adoption of the "Mutual TLS Profiles=
for OAuth Clients" document, see
https://tools.ietf.org/html/draft-campb= ell-oauth-mtls-01

Please let us know by May 4th whether you accept / object to the
adoption of this document as a starting point for work in the OAuth
working group.

Ciao
Hannes & Rifaat


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




--
=
Dave Tonge<= /div>
CTO
3D"Moneyhub
10 Temple Back, Bristol, BS1 6FL
t:=C2=A0+44 (0)117 280 5120

Moneyhub Enterprise is a trading= style of Momentum Financial Technology Limited which is authorised and reg= ulated by the Financial Conduct Authority ("FCA").=C2=A0Momentum = Financial Technology is entered on the Financial Services Register=C2=A0(FRN=C2= =A0561538) at fca.org.uk/register. Momentum Financial Technolog= y is registered in England & Wales, company registration number=C2=A006909772=C2=A0=C2=A9=C2=A0.=C2=A0Momentum Financial Technology Limited 2016.=C2=A0DISCLAIMER: This email (including any attachments) is subject t= o copyright, and the information in it is confidential. Use of this email o= r of any information in it other than by the addressee is unauthorised and = unlawful. Whilst reasonable efforts are made to ensure that any attachments= are virus-free, it is the recipient's sole responsibility to scan all = attachments for viruses. All calls and emails to and from this company may = be monitored and recorded for legitimate purposes relating to this company&= #39;s business. Any opinions expressed in this email (or in any attachments= ) are those of the author and do not necessarily represent the opinions of = Momentum Financial Technology Limited or of any other group company.=
--94eb2c11c82eed5ed4054da9edb9-- From nobody Fri Apr 21 12:43:33 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89B0212706D for ; Fri, 21 Apr 2017 12:43:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 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, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cPZZivfKv0Jv for ; Fri, 21 Apr 2017 12:43:30 -0700 (PDT) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (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 E808D12932A for ; Fri, 21 Apr 2017 12:43:26 -0700 (PDT) Received: by mail-qt0-x229.google.com with SMTP id y33so77521471qta.2 for ; Fri, 21 Apr 2017 12:43:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=oyGhRj0Q8B+b3KOvw5rIMoGBEXEmbBlEo0hbS4rp6/s=; b=rl9310eBKERiHj78R3rUdh0hos7zQO3RRqllmKPDiWwIA+QM6Dy9IRwRofWOh9kJxn s0vsnUZ18ehkDv+h5g3/pODpdj8TuuPQWdpGHpCrIcNGLHOyC9xXDIuJhJKLvhClQgPE +LyvHeBIj5/ezqxnezgCUFGtc0JAdnyr6nPeQ28UQ0TovdnqJ3DNiML34L8D/q2SkirP JVrydzTQbtJ81eROPCS4/CSjC1wxsmSsbVCsEGF6UObZEiuFUGDsXy6nL9pOmYzQ07zI nJBYlRuqihxKBt7CrnNqSLqHqgi3jhLnXaq76EyOsRzJFa6O5wp9CV/Y+h9LHJP6dgyR dIUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=oyGhRj0Q8B+b3KOvw5rIMoGBEXEmbBlEo0hbS4rp6/s=; b=F70Ce6fKcqIdymINBiPIcGXvsnfwEeCwmVdzx9MTv2Ew+mPtFMiFDaAMPMZru98E+3 4aC1eXm8CRDRoCNLaFYfi1SjTFvTfP95GDLOXlLOFkcvFEXPfNunQdnXNk/F1AQp9A47 L7yzvc6FBIktBhroM+K8T4X/4XfOfpRdStLRriYDjmbOTqJ5iX1l3shZdPd1tExcNqyf Jo1Jf55HpMTR+l9Bikv8uOVjhjyKsygfclAkhCKQQjIhHH9cvLUXN6+F1A2BiBUOruGj nLfA9sqj6fnmMlNpEPytWJOLtVRY8xqZMZT171ad7UfDFwhoNPJEow3Z2Nlpmg/21xAC 8BLg== X-Gm-Message-State: AN3rC/7/i5UGLipWt8QrppoVJYFhWsPdnfHONxFpbwUCyeRjedkR18ds GACqtepbg5L4araUjGMIQCT+1hz2Bg== X-Received: by 10.237.32.238 with SMTP id 101mr14743083qtb.162.1492803805690; Fri, 21 Apr 2017 12:43:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.48.180 with HTTP; Fri, 21 Apr 2017 12:43:23 -0700 (PDT) Received: by 10.200.48.180 with HTTP; Fri, 21 Apr 2017 12:43:23 -0700 (PDT) In-Reply-To: References: <95776354-79e3-caa7-ba60-84cfec7f899f@gmx.net> From: Nat Sakimura Date: Sat, 22 Apr 2017 04:43:23 +0900 Message-ID: To: Dave Tonge Cc: Hannes , oauth Content-Type: multipart/alternative; boundary=94eb2c0c5f208ec247054db27850 Archived-At: Subject: Re: [OAUTH-WG] Call for Adoption: Mutual TLS Profiles for OAuth Clients X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 19:43:32 -0000 --94eb2c0c5f208ec247054db27850 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 for adoption On Apr 21, 2017 9:32 PM, "Dave Tonge" wrote: > I support adoption of draft-campbell-oauth-mtls > > As previously mentioned this spec will be very useful for Europe where > there is legislation requiring the use of certificate-based authenticatio= n > and many financial groups and institutions are considering OAuth2. > > The UK Open Banking Implementation Entity has a strong interest in using > this spec. > > Dave > > On 20 April 2017 at 17:32, Hannes Tschofenig > wrote: > >> Hi all, >> >> based on the strong support for this document at the Chicago IETF >> meeting we are issuing a call for adoption of the "Mutual TLS Profiles >> for OAuth Clients" document, see >> https://tools.ietf.org/html/draft-campbell-oauth-mtls-01 >> >> Please let us know by May 4th whether you accept / object to the >> adoption of this document as a starting point for work in the OAuth >> working group. >> >> Ciao >> Hannes & Rifaat >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > > > -- > Dave Tonge > CTO > [image: Moneyhub Enterprise] > > 10 Temple Back, Bristol, BS1 6FL > t: +44 (0)117 280 5120 <+44%20117%20280%205120> > > Moneyhub Enterprise is a trading style of Momentum Financial Technology > Limited which is authorised and regulated by the Financial Conduct > Authority ("FCA"). Momentum Financial Technology is entered on the > Financial Services Register (FRN 561538) at fca.org.uk/register. Momentum > Financial Technology is registered in England & Wales, company registrati= on > number 06909772 =C2=A9 . Momentum Financial Technology Limited 2016. DISC= LAIMER: > This email (including any attachments) is subject to copyright, and the > information in it is confidential. Use of this email or of any informatio= n > in it other than by the addressee is unauthorised and unlawful. Whilst > reasonable efforts are made to ensure that any attachments are virus-free= , > it is the recipient's sole responsibility to scan all attachments for > viruses. All calls and emails to and from this company may be monitored a= nd > recorded for legitimate purposes relating to this company's business. Any > opinions expressed in this email (or in any attachments) are those of the > author and do not necessarily represent the opinions of Momentum Financia= l > Technology Limited or of any other group company. > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --94eb2c0c5f208ec247054db27850 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1 for adoption

On Apr 21, 2017 9:32 PM, "Dave Tonge" <<= a href=3D"mailto:dave.tonge@momentumft.co.uk">dave.tonge@momentumft.co.uk> wrote:
I support adoption of draft-campbell-oauth-mtls
<= div class=3D"gmail_default" style=3D"font-family:"trebuchet ms",s= ans-serif">
As previously mentioned this spec will be very useful for Eur= ope where there is legislation requiring the use of certificate-based authe= ntication and many financial groups and institutions are considering OAuth2= .
=C2=A0
The UK Open Banking Implementation Entity=C2= =A0has a strong interest in using this spec.

Dav= e

On 20 April 2017 at 17:32, Hannes Tschofenig <hannes.tschofenig= @gmx.net> wrote:
Hi all,<= br>
based on the strong support for this document at the Chicago IETF
meeting we are issuing a call for adoption of the "Mutual TLS Profiles=
for OAuth Clients" document, see
https://tools.ietf.org/html/draft-campb= ell-oauth-mtls-01

Please let us know by May 4th whether you accept / object to the
adoption of this document as a starting point for work in the OAuth
working group.

Ciao
Hannes & Rifaat


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




--
Dave Tonge
CTO
10 Temple Back, Bristol, BS= 1 6FL
t:=C2=A0+44 (0)117 280 5120

M= oneyhub Enterprise is a trading style of Momentum Financial Technology Limi= ted which is authorised and regulated by the Financial Conduct Authority (&= quot;FCA").=C2=A0Momentum Financial Technology is entered on the Finan= cial Services Register=C2=A0(FRN=C2=A0561538) at fca.org.uk/register.= Momentum Financial Technology is registered in England & Wales, compan= y registration number=C2=A006909772<= span style=3D"font-size:0.75em;background-color:transparent">=C2=A0<= span style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;background-c= olor:transparent">=C2=A9=C2=A0.=C2=A0Momentum Financial Techn= ology Limited 2016.=C2=A0DISCLAIMER: This email (including= any attachments) is subject to copyright, and the information in it is con= fidential. Use of this email or of any information in it other than by the = addressee is unauthorised and unlawful. Whilst reasonable efforts are made = to ensure that any attachments are virus-free, it is the recipient's so= le responsibility to scan all attachments for viruses. All calls and emails= to and from this company may be monitored and recorded for legitimate purp= oses relating to this company's business. Any opinions expressed in thi= s email (or in any attachments) are those of the author and do not necessar= ily represent the opinions of Momentum Financial Technology Limited or of a= ny other group company.

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

--94eb2c0c5f208ec247054db27850-- From nobody Fri Apr 21 15:42:22 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C17812940B for ; Fri, 21 Apr 2017 15:42:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id viPZ8aeXMtet for ; Fri, 21 Apr 2017 15:42:19 -0700 (PDT) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 044CF120726 for ; Fri, 21 Apr 2017 15:42:19 -0700 (PDT) Received: by mail-it0-x236.google.com with SMTP id g66so2747217ite.1 for ; Fri, 21 Apr 2017 15:42:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:from:date:message-id:subject:to:cc; bh=9MfHoq/HJx3WaSWp/4cf1xACZBsjK8L76zQwmswMA0Y=; b=KYqPDYpe1cqK3vzSmEZRYo5Cdz3uwlNePUvj3cyOC2Ad+Kj8S5I1xpI93AfcuCcB95 b2RVvnzVml9l+MeGYNOP21AMtZSXJ+/JWRqHO/0bCm6/8tT28vKXrsaj32ca9qyw2Gi5 3+HLfJWiYmJm29fyzmzEDORtJ9v6ZTRDFXqZM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=9MfHoq/HJx3WaSWp/4cf1xACZBsjK8L76zQwmswMA0Y=; b=d3UGRl0OuSDySpF97iWyxIyX/O/SfVAh2HskysiQ10BBO7KYs5JfmdEZQLUzoyQvd+ eANW+WnFD05Pu2tYBsgNQt5aUrLv7a4ptjYKbQfNhcqimxr9/yb5VD9hvaI+5iMTZtZq esn1njh5A74fv1QdwTqedz6HpHDPTRRgxoEDCk3+eU4J6712m+yzNz6ne6eTf/XkLhIi PZdk8uLS6E16qKAuEdWHWsYRtAeGZTUD2O2qIY1w4/o+Rb3gviStMAeMPbQZEqd1AjPv qwzxvxRxjnAjLM4FBdemEh062QZicubiTYimmin6I3cCGURLbtgBcPDFBl8CQqCVpKj7 rNUw== X-Gm-Message-State: AN3rC/6I29dVbvhyw/7rMgevQIaQczN+5WpxrAp/mdv9c/F5HgN72Lbu fm5UTnLzY3QvLQ/57SXvrc2QYIG7J86075A= X-Received: by 10.99.125.18 with SMTP id y18mr14539327pgc.32.1492814538173; Fri, 21 Apr 2017 15:42:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.170.13 with HTTP; Fri, 21 Apr 2017 15:41:47 -0700 (PDT) From: Brian Campbell Date: Fri, 21 Apr 2017 16:41:47 -0600 Message-ID: To: "Manger, James" Cc: "oauth@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c1b65e2438cc4054db4f8a5 Archived-At: Subject: [OAUTH-WG] re comments on MTLS (was Re: Call for Adoption: Mutual TLS Profiles for OAuth Clients) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 22:42:21 -0000 --94eb2c1b65e2438cc4054db4f8a5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks, James, for the adoption support as well as the review and comments. I've tried to respond to the comments inline below. On Thu, Apr 20, 2017 at 11:33 PM, Manger, James < James.H.Manger@team.telstra.com> wrote: > I support adoption of draft-campbell-oauth-mtls. > > Now some comments on the doc: > > 1. [=C2=A72.3] The syntax of tls_client_auth_subject_dn is not specified. > Perhaps LDAP's "String Representation of Distinguished Names" [RFC4514]? > Perhaps a base64url-encoding of a DER-encoded DN? It would actually be > better to allow any subjectAltName to be specified, instead of a DN. > How about calling it tls_client_auth_subject and defining it as a string and allowing it to represent the expected subject which could be in the cert as the subject DN or a subjectAltName? For Subject DN and DN subjectAltNames it would be the "String Representation of Distinguished Names" and an appropriate string for the other subjectAltName types (I'll have to look at what's there 'cause I don't know off hand and guidance or suggested text is always more than welcome). > 2. [=C2=A72.3] Change the name of tls_client_auth_issuer_dn (maybe > tls_client_auth_root_dn). Given tls_client_auth_client_dn, it will be too > easy to assume this pair refer to the issuer and subject fields of the ce= rt. > The accompanying text tries to make it clear that it's the root issuer but the tls_client_auth_issuer_dn name can certainly be changed to tls_client_auth_root_dn or something along those lines, if folks think the name in -01 is liable to cause confusion? PKI chains can be complex so the expected root might not be such a stable > concept. For example, the Let's Encrypt CA chains to an ISRG Root and an > IdenTrust DST Root [https://letsencrypt.org/certificates/]. > The goal was to provide a metadata field to express some constraint for what is kind of expected to be a common deployment of a number of entities participating in some OAuth API thing and are being issued certificates from a common issuer for the group of participants. Perhaps it should be an array of strings rather than a single value? Or do you have suggestions for some alternative? > 3. [=C2=A72.3] If a client dynamically registers a "jwks_uri" does this m= ean > the authz server MUST automatically cope when the client updates the key(= s) > it publishes there? > If the authz server supports that kind of trust model as well as dynamically registration, then I would expect so, yes. > 4. [=C2=A73] An access token is bound to a specific client certificate. T= hat is > probably ok, but does mean all access tokens die when the client updates > their certificate (which could be every 2 months if using Let's Encrypt). > This at least warrants a paragraph in the Security Considerations. > In my own mind that was implied and okay because it's likely that access tokens will have a shorter lifespan than certificates and refreshing or getting a new access token is typically easy anyhow. Anyway, it doesn't hurt to be explicit about it, can you propose some such text for the Security Considerations? > > 5. [=C2=A73.1] "exp" and "nbf" values in the example need to be numbers, = not > strings (drop the quotes). > Silly mistake on my part. Thanks for catching that. Will fix. > > 6. An access token linked to a client TLS cert isn't a bearer token. The > spec should really define a new token_type for responses from the token > endpoint. That might not necessarily mean we needs a new HTTP > authentication scheme as well (it might just hint that "Bearer" wasn't > quite the right name). > Indeed "Bearer" isn't quite right and very likely a name that would be different with the benefit of hindsight. But other than having names on the wire that are more true to the nature of the tokens, I don't know that a new token_type or HTTP auth scheme adds value to the use cases here. However, they would likely make deployment of this stuff more cumbersome and take longer. Whereas many systems can likely plug in mutual TLS on top of the existing token_type and HTTP auth scheme without major changes. I'm strongly inclined to not introduce a new token_type and more inclined to not do a new HTTP auth scheme. --94eb2c1b65e2438cc4054db4f8a5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks, James, for the adoption support as well as the rev= iew and comments. I've tried to respond to the comments inline below. <= br>
On Thu, A= pr 20, 2017 at 11:33 PM, Manger, James <James.H.Manger@team.= telstra.com> wrote:
I support adoption of draft-campbell-oauth-mtls.

Now some comments on the doc:

1. [=C2=A72.3] The syntax of tls_client_auth_subject_dn is not specified. P= erhaps LDAP's "String Representation of Distinguished Names" = [RFC4514]? Perhaps a base64url-encoding of a DER-encoded DN? It would actua= lly be better to allow any subjectAltName to be specified, instead of a DN.=

How about calling it tls_client_auth_s= ubject and defining it as a string and allowing it to represent the expecte= d subject which could be in the cert as the subject DN or a subjectAltName?= For Subject DN and DN subjectAltNames it would be the "String Represe= ntation of Distinguished Names" and an appropriate string for the othe= r subjectAltName types (I'll have to look at what's there 'caus= e I don't know off hand and guidance or suggested text is always more t= han welcome).
=C2=A0



2. [=C2=A72.3] Change the name of tls_client_auth_issuer_dn (maybe tls_clie= nt_auth_root_dn). Given tls_client_auth_client_dn, it will be too easy to a= ssume this pair refer to the issuer and subject fields of the cert.

The accompanying text tries to make it clear t= hat it's the root issuer but the tls_client_auth_issuer_dn name can cer= tainly be changed to tls_client_auth_root_dn or something along those lines= , if folks think the name in -01 is liable to cause confusion?
=C2=A0


PKI chains can be complex so the expected root might not be such a stable c= oncept. For example, the Let's Encrypt CA chains to an ISRG Root and an= IdenTrust DST Root [https://letsencrypt.org/certificates= /].

The goal was to provide a metad= ata field to express some constraint for what is kind of expected to be a c= ommon deployment of a number of entities participating in some OAuth API th= ing and are being issued certificates from a common issuer for the group of= participants.

Perhaps it should be an array of strings = rather than a single value?

Or do you have suggestions fo= r some alternative?




3. [=C2=A72.3] If a client dynamically registers a "jwks_uri" doe= s this mean the authz server MUST automatically cope when the client update= s the key(s) it publishes there?

If the= authz server supports that kind of trust model as well as dynamically regi= stration, then I would expect so, yes.
=C2=A0



4. [=C2=A73] An access token is bound to a specific client certificate. Tha= t is probably ok, but does mean all access tokens die when the client updat= es their certificate (which could be every 2 months if using Let's Encr= ypt). This at least warrants a paragraph in the Security Considerations.

In my own mind that was implied and okay = because it's likely that access tokens will have a shorter lifespan tha= n certificates and refreshing or getting a new access token is typically ea= sy anyhow.

Anyway, it doesn't hurt to be explicit abo= ut it, can you propose some such text for the Security Considerations?
<= br>
=C2=A0

5. [=C2=A73.1] "exp" and "nbf" values in the example ne= ed to be numbers, not strings (drop the quotes).

<= /div>
Silly mistake on my part. Thanks for catching that. Will fix.
=C2=A0

6. An access token linked to a client TLS cert isn't a bearer token. Th= e spec should really define a new token_type for responses from the token e= ndpoint. That might not necessarily mean we needs a new HTTP authentication= scheme as well (it might just hint that "Bearer" wasn't quit= e the right name).

Indeed "Bearer&= quot; isn't quite right and very likely a name that would be different = with the benefit of hindsight. But other than having names on the wire that= are more true to the nature of the tokens, I don't know that a new tok= en_type or HTTP auth scheme adds value to the use cases here. However, they= would likely make deployment of this stuff more cumbersome and take longer= .=C2=A0 Whereas many systems can likely plug in mutual TLS on top of the ex= isting token_type and HTTP auth scheme without major changes. I'm stron= gly inclined to not introduce a new token_type and more inclined to not do = a new HTTP auth scheme.



--94eb2c1b65e2438cc4054db4f8a5-- From nobody Fri Apr 21 17:18:50 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 231E91293FD for ; Fri, 21 Apr 2017 17:18:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gT5Ry5mKcSID for ; Fri, 21 Apr 2017 17:18:46 -0700 (PDT) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4D6A127A97 for ; Fri, 21 Apr 2017 17:18:45 -0700 (PDT) Received: by mail-qt0-x230.google.com with SMTP id m36so81098013qtb.0 for ; Fri, 21 Apr 2017 17:18:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=2dQcnM9VAlQ2v/CXXNLjjOg5Etcaiah3HxiB6o3jenc=; b=MsEpwP9XIOv7iIyve8trp4QqvNm0HrLMiUj8C1dhaEEnp0aLDlQbL3fA58eHKYfkyn sRE0EqN6kZSGECnwbDeDHeiSI41baDKPqOP3uNg/Qeoy6DLq/ULoComEOe8eCmU8OTCU na7hqMBMRHInlh3FMGvvNHoApp7qRfgzQeQagZNSi4yBVbrr5xMLyXurH8nY9sKixFYC 8ZS4yUqeUEgRukLSjuezlVf596EIkYrOyEFl3oNjE1CauE/Jyn6T0zjeYLPO3iB+j5WM Gw/VqFay5huQCaV7lTu3oULVJRFd5vysHHU1NNhqxuO5iIZQc/XpUe6xIgK24rxjqrkR 7KKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=2dQcnM9VAlQ2v/CXXNLjjOg5Etcaiah3HxiB6o3jenc=; b=t0mFzEoZveJJUD77b1ACNykYo8o4C8X8OhaeDcXDp1Do3S9P/H3cSvvIMnr0bqbfyD AePplOSwH8/XsOZN+gYC/G41efH9pnVLTGsbkR0jCG9kWcd/9aWDW8V1hFjn10qAEjXc NU5ayuLvBpeGmoikR5jh1lcwVzAfmaWqFz3usfphJhg6xiTovm9paXBcBSV9CWvMIRlt +aacPvztHOkT8/V2FK8DpdpGMVAYDOeyyQLty2syK+I7ieOuOtk/1VfDHIfwybgLZc1S a6U3tIhl4UePkd5T13u5dORR8wdcrp/IqH3Q9WUqcTJwiqM/EcUfDqLsHg3s5Jp+pWgL nhoA== X-Gm-Message-State: AN3rC/4bTS4uyku843A/snTRSTKIoAE7a8pXfGH34IEe6NENS0HSN0hF P7wsJZowImjk0Oaw X-Received: by 10.237.53.236 with SMTP id d41mr17311524qte.158.1492820324777; Fri, 21 Apr 2017 17:18:44 -0700 (PDT) Received: from [192.168.8.100] ([181.201.182.20]) by smtp.gmail.com with ESMTPSA id k65sm7478675qkf.18.2017.04.21.17.18.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 21 Apr 2017 17:18:43 -0700 (PDT) From: John Bradley Message-Id: <698E4B80-754F-42E1-AD2B-602CD605C680@ve7jtb.com> Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 21 Apr 2017 21:18:40 -0300 In-Reply-To: Cc: "Manger, James" , "oauth@ietf.org" To: Brian Campbell References: X-Mailer: Apple Mail (2.3273) Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a11c111e4301003054db65113" Archived-At: Subject: Re: [OAUTH-WG] re comments on MTLS (was Re: Call for Adoption: Mutual TLS Profiles for OAuth Clients) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Apr 2017 00:18:49 -0000 --001a11c111e4301003054db65113 Content-Type: multipart/alternative; boundary="Apple-Mail=_840B8432-0CB7-427A-A1F9-EC5EE6CBB69A" --Apple-Mail=_840B8432-0CB7-427A-A1F9-EC5EE6CBB69A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I agree with Brian. Trying to do anything with PKIX opens up cans of worms. One of the = reasons we have resisted to this point. However there are server to server use cases that legitimately need = this. I agree that in general DN is a mess, I suspect that telling people to = directly use the DER encoded version wont fly, so my thought was to use = the RFC 4514 string representation that most tools produce. We did talk about subject alt DNS Names, however those may not be = present in eIDAS certificates that some people may need to use for legal = reasons, or if it is present it might be an email. I suspect that users of this will fall into two camps. One that has a = small set of trusted CA that are configured out of band and any = certificate from those roots with the correct DN is OK. The other group will be trying to do something more dynamic with SSL = server certs (May or may not be EV) I could see those people = preferring DNS Name subject alt, or using JWKS to publish there certs. The problem is finding the right balance of flexibility without too many = options to confuse people. I am inclined towards DN for those that are willing to suffer the pain, = and JWKS_uri for everyone else. One advantage of the JWKS_URI approach = is that self signed certs should work just fine, that is something that = the R&E people will want if they use this. =20 For most proof of possession we should be promoting token binding as the = most flexible approach as it also works with mobile without per instance = registration. John B. > On Apr 21, 2017, at 7:41 PM, Brian Campbell = wrote: >=20 > Thanks, James, for the adoption support as well as the review and = comments. I've tried to respond to the comments inline below.=20 >=20 > On Thu, Apr 20, 2017 at 11:33 PM, Manger, James = > wrote: > I support adoption of draft-campbell-oauth-mtls. >=20 > Now some comments on the doc: >=20 > 1. [=C2=A72.3] The syntax of tls_client_auth_subject_dn is not = specified. Perhaps LDAP's "String Representation of Distinguished Names" = [RFC4514]? Perhaps a base64url-encoding of a DER-encoded DN? It would = actually be better to allow any subjectAltName to be specified, instead = of a DN. >=20 > How about calling it tls_client_auth_subject and defining it as a = string and allowing it to represent the expected subject which could be = in the cert as the subject DN or a subjectAltName? For Subject DN and DN = subjectAltNames it would be the "String Representation of Distinguished = Names" and an appropriate string for the other subjectAltName types = (I'll have to look at what's there 'cause I don't know off hand and = guidance or suggested text is always more than welcome).=20 > =20 >=20 >=20 >=20 > 2. [=C2=A72.3] Change the name of tls_client_auth_issuer_dn (maybe = tls_client_auth_root_dn). Given tls_client_auth_client_dn, it will be = too easy to assume this pair refer to the issuer and subject fields of = the cert. >=20 > The accompanying text tries to make it clear that it's the root issuer = but the tls_client_auth_issuer_dn name can certainly be changed to = tls_client_auth_root_dn or something along those lines, if folks think = the name in -01 is liable to cause confusion? > =20 >=20 >=20 > PKI chains can be complex so the expected root might not be such a = stable concept. For example, the Let's Encrypt CA chains to an ISRG Root = and an IdenTrust DST Root [https://letsencrypt.org/certificates/ = ]. >=20 > The goal was to provide a metadata field to express some constraint = for what is kind of expected to be a common deployment of a number of = entities participating in some OAuth API thing and are being issued = certificates from a common issuer for the group of participants.=20 >=20 > Perhaps it should be an array of strings rather than a single value? >=20 > Or do you have suggestions for some alternative? >=20 >=20 >=20 >=20 > 3. [=C2=A72.3] If a client dynamically registers a "jwks_uri" does = this mean the authz server MUST automatically cope when the client = updates the key(s) it publishes there? >=20 > If the authz server supports that kind of trust model as well as = dynamically registration, then I would expect so, yes.=20 > =20 >=20 >=20 >=20 > 4. [=C2=A73] An access token is bound to a specific client = certificate. That is probably ok, but does mean all access tokens die = when the client updates their certificate (which could be every 2 months = if using Let's Encrypt). This at least warrants a paragraph in the = Security Considerations. >=20 > In my own mind that was implied and okay because it's likely that = access tokens will have a shorter lifespan than certificates and = refreshing or getting a new access token is typically easy anyhow. >=20 > Anyway, it doesn't hurt to be explicit about it, can you propose some = such text for the Security Considerations? >=20 >=20 > =20 >=20 > 5. [=C2=A73.1] "exp" and "nbf" values in the example need to be = numbers, not strings (drop the quotes). >=20 > Silly mistake on my part. Thanks for catching that. Will fix.=20 >=20 > =20 >=20 > 6. An access token linked to a client TLS cert isn't a bearer token. = The spec should really define a new token_type for responses from the = token endpoint. That might not necessarily mean we needs a new HTTP = authentication scheme as well (it might just hint that "Bearer" wasn't = quite the right name). >=20 > Indeed "Bearer" isn't quite right and very likely a name that would be = different with the benefit of hindsight. But other than having names on = the wire that are more true to the nature of the tokens, I don't know = that a new token_type or HTTP auth scheme adds value to the use cases = here. However, they would likely make deployment of this stuff more = cumbersome and take longer. Whereas many systems can likely plug in = mutual TLS on top of the existing token_type and HTTP auth scheme = without major changes. I'm strongly inclined to not introduce a new = token_type and more inclined to not do a new HTTP auth scheme. >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_840B8432-0CB7-427A-A1F9-EC5EE6CBB69A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I agree with Brian.

Trying to do anything with PKIX opens up cans of worms. =  One of the reasons we have resisted to this point.

However there are server = to server use cases that legitimately need this.

I agree that in general DN is a mess, I = suspect that telling people to directly use the DER encoded version wont = fly, so my thought was to use the RFC 4514 string representation that = most tools produce.

We did talk about subject alt DNS Names, however those may = not be present in eIDAS certificates that some people may need to use = for legal reasons, or if it is present it might be an email.

I suspect that users of = this will fall into two camps.  One that has a small set of trusted = CA that are configured out of band and any certificate from those roots = with the correct DN is OK.

The other group will be trying to do something more dynamic = with SSL server certs (May or may not be EV)   I could see those = people preferring DNS Name subject alt, or using JWKS to publish there = certs.

The = problem is finding the right balance of flexibility without too many = options to confuse people.

I am inclined towards DN for those that are willing to suffer = the pain, and JWKS_uri for everyone else.   One advantage of the = JWKS_URI approach is that self signed certs should work just fine, that = is something that the R&E people will want if they use this. =  

For = most proof of possession we should be promoting token binding as the = most flexible approach as it also works with mobile without per instance = registration.

John B.


On Apr 21, 2017, at 7:41 PM, = Brian Campbell <bcampbell@pingidentity.com> wrote:

Thanks, James, for the adoption support as well as the review = and comments. I've tried to respond to the comments inline below.

On Thu, Apr 20, 2017 at 11:33 PM, Manger, James = <James.H.Manger@team.telstra.com> wrote:
I support = adoption of draft-campbell-oauth-mtls.

Now some comments on the doc:

1. [=C2=A72.3] The syntax of tls_client_auth_subject_dn is not = specified. Perhaps LDAP's "String Representation of Distinguished Names" = [RFC4514]? Perhaps a base64url-encoding of a DER-encoded DN? It would = actually be better to allow any subjectAltName to be specified, instead = of a DN.

How about calling it = tls_client_auth_subject and defining it as a string and allowing it to = represent the expected subject which could be in the cert as the subject = DN or a subjectAltName? For Subject DN and DN subjectAltNames it would = be the "String Representation of Distinguished Names" and an appropriate = string for the other subjectAltName types (I'll have to look at what's = there 'cause I don't know off hand and guidance or suggested text is = always more than welcome).
 



2. [=C2=A72.3] Change the name of tls_client_auth_issuer_dn (maybe = tls_client_auth_root_dn). Given tls_client_auth_client_dn, it will be = too easy to assume this pair refer to the issuer and subject fields of = the cert.

The accompanying text tries to make it = clear that it's the root issuer but the tls_client_auth_issuer_dn name = can certainly be changed to tls_client_auth_root_dn or something along = those lines, if folks think the name in -01 is liable to cause = confusion?
 


PKI chains can be complex so the expected root might not be such a = stable concept. For example, the Let's Encrypt CA chains to an ISRG Root = and an IdenTrust DST Root [https://letsencrypt.org/certificates/].

The goal was to provide = a metadata field to express some constraint for what is kind of expected = to be a common deployment of a number of entities participating in some = OAuth API thing and are being issued certificates from a common issuer = for the group of participants.

Perhaps it should be an array of strings rather than a single = value?

Or do you have = suggestions for some alternative?




3. [=C2=A72.3] If a client dynamically registers a "jwks_uri" does this = mean the authz server MUST automatically cope when the client updates = the key(s) it publishes there?

If the authz server = supports that kind of trust model as well as dynamically registration, = then I would expect so, yes.
 



4. [=C2=A73] An access token is bound to a specific client certificate. = That is probably ok, but does mean all access tokens die when the client = updates their certificate (which could be every 2 months if using Let's = Encrypt). This at least warrants a paragraph in the Security = Considerations.

In my own mind that was implied and = okay because it's likely that access tokens will have a shorter lifespan = than certificates and refreshing or getting a new access token is = typically easy anyhow.

Anyway, it doesn't hurt to be explicit about it, can you = propose some such text for the Security Considerations?


 

5. [=C2=A73.1] "exp" and "nbf" values in the example need to be numbers, = not strings (drop the quotes).

Silly mistake on my = part. Thanks for catching that. Will fix.

 

6. An access token linked to a client TLS cert isn't a bearer token. The = spec should really define a new token_type for responses from the token = endpoint. That might not necessarily mean we needs a new HTTP = authentication scheme as well (it might just hint that "Bearer" wasn't = quite the right name).

Indeed "Bearer" isn't quite right and = very likely a name that would be different with the benefit of = hindsight. But other than having names on the wire that are more true to = the nature of the tokens, I don't know that a new token_type or HTTP = auth scheme adds value to the use cases here. However, they would likely = make deployment of this stuff more cumbersome and take longer.  = Whereas many systems can likely plug in mutual TLS on top of the = existing token_type and HTTP auth scheme without major changes. I'm = strongly inclined to not introduce a new token_type and more inclined to = not do a new HTTP auth scheme.



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

= --Apple-Mail=_840B8432-0CB7-427A-A1F9-EC5EE6CBB69A-- --001a11c111e4301003054db65113 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIRGwYJKoZIhvcNAQcCoIIRDDCCEQgCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg gg4rMIIErzCCA5egAwIBAgIRAOAjyxUSg1OJrWFuelRnayEwDQYJKoZIhvcNAQELBQAwbzELMAkG A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0xNDEy MjIwMDAwMDBaFw0yMDA1MzAxMDQ4MzhaMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRl ZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1 cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCJsQ3aelMZTnBSHbxW pgYmt7hJ4JbnUavx8FoTSRWjtIwbYLx6UUKneYykIt8XYU6R1XYjChTTSgJ/th0JgG6lBD3ZursW /qGHqS5DUkMWfK8yUMimT1rpCNjPkyWce4joMGTmpPhWgP0qJBQzF5msROVpi6NGBkvCM9TpQJ8G sLGsk0C5tQiTOpwqU6MQ2z0gYTxVA47ZTnYlAiEp+qN8cXZP7uFfgen7VIDbw3s1UreE3iI9LDAt MX9ZvVI3sDNpLUPr+tal8Zd3Z1GM2e4n67ylBzh2jKSpOP/fjPUDrEm+yvdzmToPMquclToTPQ5G Old0YVC+xkA/y+Tin6IhAgMBAAGjggEXMIIBEzAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73g JMtUGjAdBgNVHQ4EFgQUkmFrguGioKpP7GfxwqP3tIAAwewwDgYDVR0PAQH/BAQDAgGGMBIGA1Ud EwEB/wQIMAYBAf8CAQAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBEGA1UdIAQKMAgw BgYEVR0gADBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vQWRkVHJ1 c3RFeHRlcm5hbENBUm9vdC5jcmwwNQYIKwYBBQUHAQEEKTAnMCUGCCsGAQUFBzABhhlodHRwOi8v b2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBCwUAA4IBAQAbKm6sVcE6q4jF2O3NVfOqa2Er wAkQI5kPxWZqb7H1tLV3Xg8CYQDffQX+ErOkgIAA/PsdW2pyAgpBvAW6wVjVJsLq1U2E+/6CmM9Y G+MiY5xS+LsFNqt9WKXeqztj5drVc+/s4Pt74qP/8EIjnMq2jU0+5EsYA7KoLdTYu0JLkGmFENum NzToe+ABEKWcyjrHn0+ING6KZdAairup3MrKNtH0/MJkKTWv1rGncRHSA0Oxjz6a7J4yU/R2ksqG NAe5LMrmHErYmQ3BhuKQkvtaQmojIRDpZcf11bt+6oyFIAJi6tE6ByxZxZkz8jiJ5bbpFnofeRT2 ShAaJvp8ivubMIIENjCCAx6gAwIBAgIBATANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEU MBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3 b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTAwMDUzMDEwNDgzOFoX DTIwMDUzMDEwNDgzOFowbzELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYD VQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0 ZXJuYWwgQ0EgUm9vdDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALf3GjPm8gAELTng TlvtH7xsD821+iO2zt6bETOXpClMfZOfvUq8k+0DGuOPz+VtUFrWlymUWoCwSXrbLpX9uMq/Nzgt Hj6RQa1wVsfwTz/oMp50ysiQVOnGXw94nZpAPA6sYapeFI+eh6FqUNzXmk6vBbOmcZSccbNQYArH E504B4YCqOmoaSYYkKtMsE8jqzpPhNjfzp/haW+710LXa0Tkx63ubUFfclpxCDezeWWkWaCUN/cA Lw3CknLa0Dhy2xSoRcRdKn23tNbE7qzNE0S3ySvdQwAl+mG5aWpYIxG3pzOPVnVZ9c0p10a3Citl ttNCbxWyuHv77+ldU9U0WicCAwEAAaOB3DCB2TAdBgNVHQ4EFgQUrb2YejS0Jvf6xCZU7wO94CTL VBowCwYDVR0PBAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wgZkGA1UdIwSBkTCBjoAUrb2YejS0Jvf6 xCZU7wO94CTLVBqhc6RxMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4 dGVybmFsIENBIFJvb3SCAQEwDQYJKoZIhvcNAQEFBQADggEBALCb4IUlwtYj4g+WBpKdQZic2YR5 gdkeWxQHIzZlj7DYd7usQWxHYINRsPkyPef89iYTx4AWpb9a/IfPeHmJIZriTAcKhjW88t5RxNKW t9x+Tu5w/Rw56wwCURQtjr0W4MHfRnXnJK3s9EK0hZNwEGe6nQY1ShjTK3rMUUKhemPR5ruhxSvC Nr4TDea9Y355e6cJDUCrat2PisP29owaQgVR1EX1n6diIWgVIEM8med8vSTYqZEXc4g/VhsxOBi0 cQ+azcgOno4uG+GMmIPLHzHxREzGBHNJdmAPx/i9F4BrLunMTA5amnkPIAou1Z5jJh5VkpTYghda e9C8x49OhgQwggU6MIIEIqADAgECAhEA2TLMtWuXNcB2cbqZ/VgVujANBgkqhkiG9w0BAQsFADCB mzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2 IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE3MDEwOTAwMDAw MFoXDTE4MDEwOTIzNTk1OVowIjEgMB4GCSqGSIb3DQEJARYRdmU3anRiQHZlN2p0Yi5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDW2rqobOFQ/XmzH3DG2UK1Dt6jtc+OFZ71KQoB o8IZa/V94Ey12BPjBcoj+cjHNVsLd2QiUpMcf5sZFMX1cmvpR7TiUISgVcHe8zgiUUvN5Jn5tPDM Kb4E34TtDEG2X5FyY35AwCl8NV/loj2D5KLid9BLdVTJjfqokjLQ/4qCQjWBjfTpIdAdr3lXfg5f a5UPyIkphEIplM8/yGfX0W/PBl804XAL0gesLrfEMdgG58UCN1wJMgH4uRKmKU/U2Ap4W9hTpioN M722U8x7N6P1v6MqTAWCUaskdOp+ktNxFGxOlCE7BEo/EIaWbEt5RHwDePctScDLsi56+VI3TysR AgMBAAGjggHvMIIB6zAfBgNVHSMEGDAWgBSSYWuC4aKgqk/sZ/HCo/e0gADB7DAdBgNVHQ4EFgQU Yg3SsFWhMro4Abonbn1IX4JKj5QwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0l BBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9 MDsGDCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0 L0NQUzBdBgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9TSEEy NTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDBYBggrBgEFBQcwAoZMaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xp ZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDov L29jc3AuY29tb2RvY2EuY29tMBwGA1UdEQQVMBOBEXZlN2p0YkB2ZTdqdGIuY29tMA0GCSqGSIb3 DQEBCwUAA4IBAQCC26y+6/+SJoRQWepca+rB9eSSwaCAb8nNqA+00ZiOHb+6UbbV1xa7Z8wDIuEL 5UKbNtQ2NDArvzF9YI0xNafoV1AEmP/3+ljxQHSEI0U1p2h401sOx+nSjcwtTzACso1lw+I0oJYM JFITOIfZy8HgFpCipBrQAp9jMJ+KSKDX3xu/hzPosfdnXp7sV1KAjkFrAtR3AnQYfJ5W8QrsmC4N BbiAKoYWUSdklqn3v1neTG/+oOhcw7hcGZo+YmPyF9Cdy0gBtwSHPt8hluhg2TlzmqYfi0dVL/mU jCBNUY/BFH+MBqKF7sOIRMv8ALWceVaM/NEcBciKs4eR99A4cw9ZMYICtDCCArACAQEwgbEwgZsx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRANkyzLVrlzXAdnG6mf1Y FbowDQYJYIZIAWUDBAIBBQCggdQwLwYJKoZIhvcNAQkEMSIEIHzmQdt0V+AEQdzQEYTAQK1qTVJu U+AU9DDyHeSpEdx6MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE3 MDQyMjAwMTg0NVowaQYJKoZIhvcNAQkPMVwwWjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzALBgkqhkiG9w0BAQowCwYJKoZIhvcNAQEHMAsGCWCGSAFl AwQCATANBgkqhkiG9w0BAQEFAASCAQBAfVcTL+JxRRPVklE8lNtx6jWKoZ/QcalY4dbefFLvkrbn mqZEfiUIsJSbllnynk5P9h7zUe3tMChh1dktEJZKntunYONG4c+rzRg5wFgB+O8hcCkTWlH6X7ih n2ivChPj2zU/6z/EULT30oTRaeYBIXHIAy7nj5QskEXBA794CKPML7pM9lVfpiZMD+FbDt7v9f6R cTrm+CaivvjLU3qsC0JRD/etU89u7Nz+8+0ZdrLrEszFx4w7Cf4OB6ITr4/KUCi9lt12qGuFqQ+t 7t0hX7riS/1UiMfrUGhG4aVFW/S7Wxf5W9e0MDX7x5B/a/qyArGWl8yWo5NjQaAII2qy --001a11c111e4301003054db65113-- From nobody Fri Apr 21 17:46:14 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF7A4129BDB for ; Fri, 21 Apr 2017 17:46:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.129 X-Spam-Level: X-Spam-Status: No, score=-0.129 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, EMPTY_MESSAGE=2.32, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JkCAuzzxcQCk for ; Fri, 21 Apr 2017 17:46:11 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::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 A1881129BB0 for ; Fri, 21 Apr 2017 17:46:11 -0700 (PDT) Received: by mail-oi0-x22e.google.com with SMTP id w12so3748782oiw.3 for ; Fri, 21 Apr 2017 17:46:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=AeANCiGYkXs5TJLijZtG45hMHKcnt3svmilulQXpH7o=; b=Wn6rrTpXYdRj9Sy2O31OwRMRZC+tZiVl0PmNtXyLB3ct6POtN+uTmpqqWYG26IrchD MmRCe+N56uIJzCuCMNtwti80WWivfEFig0rxw+vbVAVQPQf2LSKHHRarNocDDOkV/rVZ PjR+b5gTYzJvJB4RTylHH+EUANdSxXH4SnDAZcdIt1xFoqJYK9B6EQEIxtszkfk53ehV vRHUbdxHfJ+IEehOO/v5hiEIFTtyIoKvQtXdiymvhNc1UqPMRsSimRQZABfUAnIHg6T5 cmGI47PrBU/GLi7ZxQRhDPUlUYAEF47tT7Rp5HNkIuZ1HNqu6UY901/qsf9By7H9+aJd 4XRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=AeANCiGYkXs5TJLijZtG45hMHKcnt3svmilulQXpH7o=; b=bbm5uLHdgg3QojmXqLnFpQMUmhNkEz2x6gVlZRDq3V3q2eOvO2mkEr2L0fQ98WDINB Hg+GA+1QCZufQAaMXLUHmxh3VbiLO7H1IBrZ5CkJwJGXkx1jumHgZsDw73cIEIZwLXQa tbuDf7kYggetSy54vT2igR8cJqPLWevj7K/We/AskVtGwY/cU+A4tE0FbEcVqPMWSHR+ HEUsaQN0GSaTP5e48zM6sD+EK9Onfg9pfJEOxVC07sUmaFJ/wFiVCm9/MHh4y63VQZA7 +8Kw3hyUepToFMZCWhLczSh1+vy96vWy/+EMA7KAnJpvSSnQTx0gO18HzoViM/vqjetc q6Pw== X-Gm-Message-State: AN3rC/5R455PZehXAkbsUFPSRUiQbTCd7bJ2pGYGQnYBVpMeUyuBR13U fWcF8l6tUWZuqdMVgr8/hpE+fcihJw== X-Received: by 10.202.95.137 with SMTP id t131mr8496374oib.53.1492821971124; Fri, 21 Apr 2017 17:46:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.98.10 with HTTP; Fri, 21 Apr 2017 17:46:10 -0700 (PDT) Received: by 10.202.98.10 with HTTP; Fri, 21 Apr 2017 17:46:10 -0700 (PDT) From: =?UTF-8?B?0KLQsCDQpyDQmtC70LDRgdGB0L3Qvg==?= Date: Sat, 22 Apr 2017 03:46:10 +0300 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary=001a113cd04e4d465b054db6b332 Archived-At: Subject: [OAUTH-WG] (no subject) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Apr 2017 00:46:13 -0000 --001a113cd04e4d465b054db6b332 Content-Type: text/plain; charset=UTF-8 --001a113cd04e4d465b054db6b332 Content-Type: text/html; charset=UTF-8
--001a113cd04e4d465b054db6b332-- From nobody Sun Apr 23 09:11:36 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF2321273B1 for ; Sun, 23 Apr 2017 09:11:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6PrkbAHOg0rt for ; Sun, 23 Apr 2017 09:11:30 -0700 (PDT) Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.31.100]) (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 753051201FA for ; Sun, 23 Apr 2017 09:11:30 -0700 (PDT) Received: from [80.140.199.98] (helo=[192.168.71.161]) by smtprelay05.ispgateway.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84) (envelope-from ) id 1d2K6f-0001W1-V2; Sun, 23 Apr 2017 18:11:26 +0200 From: Torsten Lodderstedt Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_070318FE-0032-499F-973C-D7349D161BEA"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Sun, 23 Apr 2017 18:11:24 +0200 In-Reply-To: To: oauth References: <95776354-79e3-caa7-ba60-84cfec7f899f@gmx.net> X-Mailer: Apple Mail (2.3273) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] Call for Adoption: Mutual TLS Profiles for OAuth Clients X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Apr 2017 16:11:34 -0000 --Apple-Mail=_070318FE-0032-499F-973C-D7349D161BEA Content-Type: multipart/alternative; boundary="Apple-Mail=_DF775C6E-1352-4647-8FCE-7A8D580034A5" --Apple-Mail=_DF775C6E-1352-4647-8FCE-7A8D580034A5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 +1 for adoption > Am 21.04.2017 um 21:43 schrieb Nat Sakimura : >=20 > +1 for adoption >=20 > On Apr 21, 2017 9:32 PM, "Dave Tonge" > wrote: > I support adoption of draft-campbell-oauth-mtls >=20 > As previously mentioned this spec will be very useful for Europe where = there is legislation requiring the use of certificate-based = authentication and many financial groups and institutions are = considering OAuth2. > =20 > The UK Open Banking Implementation Entity has a strong interest in = using this spec. >=20 > Dave >=20 > On 20 April 2017 at 17:32, Hannes Tschofenig = > wrote: > Hi all, >=20 > based on the strong support for this document at the Chicago IETF > meeting we are issuing a call for adoption of the "Mutual TLS Profiles > for OAuth Clients" document, see > https://tools.ietf.org/html/draft-campbell-oauth-mtls-01 = >=20 > Please let us know by May 4th whether you accept / object to the > adoption of this document as a starting point for work in the OAuth > working group. >=20 > Ciao > Hannes & Rifaat >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = >=20 >=20 >=20 >=20 > --=20 > Dave Tonge > CTO > = > 10 Temple Back, Bristol, BS1 6FL > t: +44 (0)117 280 5120 >=20 > Moneyhub Enterprise is a trading style of Momentum Financial = Technology Limited which is authorised and regulated by the Financial = Conduct Authority ("FCA"). Momentum Financial Technology is entered on = the Financial Services Register (FRN 561538) at fca.org.uk/register = . Momentum Financial Technology is = registered in England & Wales, company registration number 06909772 =C2=A9= . Momentum Financial Technology Limited 2016. DISCLAIMER: This email = (including any attachments) is subject to copyright, and the information = in it is confidential. Use of this email or of any information in it = other than by the addressee is unauthorised and unlawful. Whilst = reasonable efforts are made to ensure that any attachments are = virus-free, it is the recipient's sole responsibility to scan all = attachments for viruses. All calls and emails to and from this company = may be monitored and recorded for legitimate purposes relating to this = company's business. Any opinions expressed in this email (or in any = attachments) are those of the author and do not necessarily represent = the opinions of Momentum Financial Technology Limited or of any other = group company. >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_DF775C6E-1352-4647-8FCE-7A8D580034A5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 +1 for adoption

Am 21.04.2017 um 21:43 schrieb = Nat Sakimura <sakimura@gmail.com>:

+1 for adoption

On Apr 21, 2017 9:32 PM, "Dave = Tonge" <dave.tonge@momentumft.co.uk> wrote:
I = support adoption of draft-campbell-oauth-mtls

As = previously mentioned this spec will be very useful for Europe where = there is legislation requiring the use of certificate-based = authentication and many financial groups and institutions are = considering OAuth2.
 
The = UK Open Banking Implementation Entity has a strong interest in = using this spec.

Dave

On 20 April 2017 at 17:32, Hannes = Tschofenig <hannes.tschofenig@gmx.net> wrote:
Hi all,

based on the strong support for this document at the Chicago IETF
meeting we are issuing a call for adoption of the "Mutual TLS = Profiles
for OAuth Clients" document, see
https://tools.ietf.org/html/draft-campbell-oauth-mtls-01

Please let us know by May 4th whether you accept / object to the
adoption of this document as a starting point for work in the OAuth
working group.

Ciao
Hannes & Rifaat


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




--
Dave Tonge
CTO
3D"Moneyhub
10 Temple Back, Bristol, BS1 6FL
t: +44 (0)117 280 5120

Moneyhub Enterprise is a trading = style of Momentum Financial Technology Limited which is authorised and = regulated by the Financial Conduct Authority ("FCA"). Momentum = Financial Technology is entered on the Financial Services = Register (FRN 561538) at = fca.org.uk/register. Momentum Financial Technology is = registered in England & Wales, company registration = number 06909772 =C2=A9<= span style=3D"font-size:0.75em;background-color:transparent" = class=3D""> . Momentum Financial Technology Limited 2016. DISCLAIMER: This email (including any attachments) is = subject to copyright, and the information in it is confidential. Use of = this email or of any information in it other than by the addressee is = unauthorised and unlawful. Whilst reasonable efforts are made to ensure = that any attachments are virus-free, it is the recipient's sole = responsibility to scan all attachments for viruses. All calls and emails = to and from this company may be monitored and recorded for legitimate = purposes relating to this company's business. Any opinions expressed in = this email (or in any attachments) are those of the author and do not = necessarily represent the opinions of Momentum Financial Technology = Limited or of any other group = company.

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

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

= --Apple-Mail=_DF775C6E-1352-4647-8FCE-7A8D580034A5-- --Apple-Mail=_070318FE-0032-499F-973C-D7349D161BEA Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ/DCCBK8w 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 mzCCBUUwggQtoAMCAQICEDPbmsaqwjeZa3PxA3uZ8LQwDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNzAxMDkwMDAwMDBaFw0xODAx MDkyMzU5NTlaMCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArsGSzZyz9Lq9SRW9Sve5K8n5lWhplOCE6HH3gMye 12DjOpkFFZt0b73t27G17Xsp6WUxHhNevf7ck0AUpvYUPCHBqVGJSIWF9hWAoSFCgQACOoh/cDFb zz1PsMY8El7OmIus4JXtY4/VdoSIhFP3hzATbNAg32Kp+N8vtTuKTwbgnizJSyzZTYrsttn3LmwY 17HU+U9vXloMus5U/ln4ADZx0zyyDSsA6gtPxXYJpbgSTnHckVZ5zfR80guIZ538Y2qqsqt5VaSR SR2oQzE/HETkKc/odPVhqBrXLyvnSFkCPrAXV07rcvwkPvHZeYVu4QdVWyO2HIQ4i2x9r5m7SwID AQABo4IB9TCCAfEwHwYDVR0jBBgwFoAUkmFrguGioKpP7GfxwqP3tIAAwewwHQYDVR0OBBYEFPng HgVxOZ7GSji/IW4YJMBj02PHMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZ MBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7 BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9D UFMwXQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2 Q2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBkAYIKwYBBQUHAQEEgYMw gYAwWAYIKwYBBQUHMAKGTGh0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNsaWVu dEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9v Y3NwLmNvbW9kb2NhLmNvbTAiBgNVHREEGzAZgRd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDANBgkq hkiG9w0BAQsFAAOCAQEAAmueyHjiyL1qYgfe+hVSsGuKlgcvjCAfG8Jaq48tC0IjP8pH/tGi4uL9 CHVfLnV3pLDnjg6M2uvpEBp7crZZcnSPLeVss+tkhwv+F7ISYQyT4flNkqVUb8nfewbCPcIN13Ob fpU7rlXoIarEEplQo4SuymYVluQxTLOFKm5QOMF4JBMw/rjy4t95J7Mdp9NFUzQrKPJDaJ2Jr/Tc TXFcjLvNVmMBjK0959a9v1/1miRHd1DBsTh1KvBigEOUNMxvT5uUtB6/tioDZqBDDk8Gvdno/xmy e3YiasS7JgMREq5WcXqpWGu5kMFZMGPEvyPHeBZeqxx3amf4ImVnZ6WvgzGCA8MwggO/AgEBMIGw MIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdT YWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0y NTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEDPbmsaqwjeZa3Px A3uZ8LQwCQYFKw4DAhoFAKCCAecwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMTcwNDIzMTYxMTI1WjAjBgkqhkiG9w0BCQQxFgQUd28ZnoCaLzMgrirHCfolekH2O4Mw gcEGCSsGAQQBgjcQBDGBszCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/ BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVt YWlsIENBAhAz25rGqsI3mWtz8QN7mfC0MIHDBgsqhkiG9w0BCRACCzGBs6CBsDCBmzELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBB dXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAz25rGqsI3mWtz8QN7mfC0MA0GCSqG SIb3DQEBAQUABIIBAFosuoPeY/RxyARoBHOjPFSB7kZeh7EAX8zfWg42/SPOMVbTxXhhbmSE+mMc 1o/NylAo7bIHnlddAk43acLS039FvgKIoPx1r3MeopOxtbsmEJ0hGxNe3u2RTypn7/oO66gkm6oM 5tpW5yqNy8DqciMnvjfuATcf62PRBislRRnIZbC2YLyBN8kHefz0fxK3xwPtB97UZ55CjgY+yWPa zP1KssQBam/RdGG4VAzfd+riftNyT1lLdrRNuvWgnLaz27I9OkldgFOIM946WbRHa0H4AqylYubx yJ5w9WLpF8pLXqIxUx+79mjXhmKoLgjJa7BKXbOeXsI16sfjNlekEUoAAAAAAAA= --Apple-Mail=_070318FE-0032-499F-973C-D7349D161BEA-- From nobody Mon Apr 24 00:03:00 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C133D128BA2 for ; Mon, 24 Apr 2017 00:02:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.691 X-Spam-Level: X-Spam-Status: No, score=-2.691 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DYMIoLcu73EV for ; Mon, 24 Apr 2017 00:02:56 -0700 (PDT) Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::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 46E3E1286B2 for ; Mon, 24 Apr 2017 00:02:56 -0700 (PDT) Received: by mail-it0-x235.google.com with SMTP id 70so47125729ita.0 for ; Mon, 24 Apr 2017 00:02:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xnZ5RVln/cxI4aieH6SaRD54K9NfxmYqoHxuGqZ7dY8=; b=ej30OyRl3x3LJgfbLqx/xG/WQPAE+DLGJaKNpBht+8Fsk3jEF8ttbMEDcdzN2u0syU dOVwEJNRQXyRoOPG3KFzzoP/rLBquhpTnkIXEimOwc/Pt5Edb0xMSLKefXVoa0tFsdBj QJNNq6xmXLhFG4JA/WXuP98sHp3v7lTTCZIKzrcw1qjJCUE7wOgbgFrMPGDYNV9d1wOY V3wYHI0daBU4RGMSpYU8ej5rK76Ud1fJI5d0PnCFjVc1iXdfvISDmFyRzoH5Uch1loHd sQzLXCFuB9tl6ZeIu2peyGXWtPhzvjIXB9pbXfA3K3hqXYOll87Taz6RTXXdB0DQd9gb UaQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xnZ5RVln/cxI4aieH6SaRD54K9NfxmYqoHxuGqZ7dY8=; b=SZxqCoQatE91dJH0adaFRKEUY4JCgCf/QteNcJEy8Ltarnwwvjdy6XyEXFhxzCnnBv 85T86h/0+hKN7HMt7mgEEAKTdLPG2XW3tHYGOgzd6ghbgYRKOjPh4vhOsgxkOYB4h+kW ncUx6ezejkynVgwBWMnuf275gZ4xEKRw2DnTR6EW2fDcXOnhh6Si2Fpa3UHRcEzCIFHi 7Au8JSLS9ix3WgeslAfutZFQ9r5dvN2YOKrzJM3NrXlMS48HyHoV/qJzWDkDqDyfc8Qj KbQo+I0ATcuMtWLFXOpqtjAdGrCfpohgxlps8D8HZ42IOuXyd5rT5PFkrTCSZlUx9Etp ENkQ== X-Gm-Message-State: AN3rC/6235qNmBsiKuRImFFi+/87jEoxhjtnq182E6yFjz7x1rWrVbrr EA7JodwYBbTdiC/gQL3tQpYVXH9FLTDyVyE= X-Received: by 10.36.21.195 with SMTP id 186mr11530297itq.115.1493017375078; Mon, 24 Apr 2017 00:02:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.156.210 with HTTP; Mon, 24 Apr 2017 00:02:34 -0700 (PDT) In-Reply-To: References: <95776354-79e3-caa7-ba60-84cfec7f899f@gmx.net> From: William Denniss Date: Mon, 24 Apr 2017 00:02:34 -0700 Message-ID: To: Torsten Lodderstedt Cc: oauth Content-Type: multipart/alternative; boundary=001a11449c264949ef054de4323a Archived-At: Subject: Re: [OAUTH-WG] Call for Adoption: Mutual TLS Profiles for OAuth Clients X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 07:02:59 -0000 --001a11449c264949ef054de4323a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I support the adoption of this draft by the working group. On Sun, Apr 23, 2017 at 9:11 AM, Torsten Lodderstedt < torsten@lodderstedt.net> wrote: > +1 for adoption > > Am 21.04.2017 um 21:43 schrieb Nat Sakimura : > > +1 for adoption > > On Apr 21, 2017 9:32 PM, "Dave Tonge" wrote= : > >> I support adoption of draft-campbell-oauth-mtls >> >> As previously mentioned this spec will be very useful for Europe where >> there is legislation requiring the use of certificate-based authenticati= on >> and many financial groups and institutions are considering OAuth2. >> >> The UK Open Banking Implementation Entity has a strong interest in using >> this spec. >> >> Dave >> >> On 20 April 2017 at 17:32, Hannes Tschofenig >> wrote: >> >>> Hi all, >>> >>> based on the strong support for this document at the Chicago IETF >>> meeting we are issuing a call for adoption of the "Mutual TLS Profiles >>> for OAuth Clients" document, see >>> https://tools.ietf.org/html/draft-campbell-oauth-mtls-01 >>> >>> Please let us know by May 4th whether you accept / object to the >>> adoption of this document as a starting point for work in the OAuth >>> working group. >>> >>> Ciao >>> Hannes & Rifaat >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >> >> >> -- >> Dave Tonge >> CTO >> [image: Moneyhub Enterprise] >> >> 10 Temple Back, Bristol, BS1 6FL >> t: +44 (0)117 280 5120 <+44%20117%20280%205120> >> >> Moneyhub Enterprise is a trading style of Momentum Financial Technology >> Limited which is authorised and regulated by the Financial Conduct >> Authority ("FCA"). Momentum Financial Technology is entered on the >> Financial Services Register (FRN 561538) at fca.org.uk/register. >> Momentum Financial Technology is registered in England & Wales, company >> registration number 06909772 =C2=A9 . Momentum Financial Technology Limi= ted >> 2016. DISCLAIMER: This email (including any attachments) is subject to >> copyright, and the information in it is confidential. Use of this email = or >> of any information in it other than by the addressee is unauthorised and >> unlawful. Whilst reasonable efforts are made to ensure that any attachme= nts >> are virus-free, it is the recipient's sole responsibility to scan all >> attachments for viruses. All calls and emails to and from this company m= ay >> be monitored and recorded for legitimate purposes relating to this >> company's business. Any opinions expressed in this email (or in any >> attachments) are those of the author and do not necessarily represent th= e >> opinions of Momentum Financial Technology Limited or of any other group >> company. >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --001a11449c264949ef054de4323a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I support the adoption of= this draft by the working group.

=
On Sun, Apr 23, 2017 at 9:11 AM, Torsten Lodders= tedt <torsten@lodderstedt.net> wrote:
+1 for adoption
<= div class=3D"m_-1937308524016735479h5">

Am 21.04.2017 um 21:43 schrieb Nat Sakimura <sakimura@gmail.com>:

+1 for adoption
=
On Apr 21, 2017 9:32 PM, "Dave Tonge&qu= ot; <da= ve.tonge@momentumft.co.uk> wrote:
I support adoption of draft-campbell-o= auth-mtls

As previously mentioned this spec = will be very useful for Europe where there is legislation requiring the use= of certificate-based authentication and many financial groups and institut= ions are considering OAuth2.
=C2=A0
The UK Open Banki= ng Implementation Entity=C2=A0has a strong interest in using this spec.

Dave
<= br>
On 20 April 2017 at 17:32, Hannes Tschofenig = <hannes.tschofenig@gmx.net> wrote:
Hi all,

based on the strong support for this document at the Chicago IETF
meeting we are issuing a call for adoption of the "Mutual TLS Profiles=
for OAuth Clients" document, see
https://tools.ietf.org/html/draft-campb= ell-oauth-mtls-01

Please let us know by May 4th whether you accept / object to the
adoption of this document as a starting point for work in the OAuth
working group.

Ciao
Hannes & Rifaat


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




--
=
Dave Tonge
CTO
3D"Moneyhub
10 Temple Back, Bristol, BS1 6FL
t:=C2=A0+= 44 (0)117 280 5120

Moneyhub Enterprise is a trading = style of Momentum Financial Technology Limited which is authorised and regu= lated by the Financial Conduct Authority ("FCA").=C2=A0Momentum F= inancial Technology is entered on the Financial Services Register=C2=A0(FRN=C2=A0= 561538) at fca.org.uk/register. Momentum Financial Technology i= s registered in England & Wales, company registration number=C2=A006909772=C2=A0=C2=A9=C2=A0.=C2=A0Momentum Financial Technology Limited 2016.=C2=A0DISCLAIMER: This email (including any attachments) is subject to co= pyright, and the information in it is confidential. Use of this email or of= any information in it other than by the addressee is unauthorised and unla= wful. Whilst reasonable efforts are made to ensure that any attachments are= virus-free, it is the recipient's sole responsibility to scan all atta= chments for viruses. All calls and emails to and from this company may be m= onitored and recorded for legitimate purposes relating to this company'= s business. Any opinions expressed in this email (or in any attachments) ar= e those of the author and do not necessarily represent the opinions of Mome= ntum Financial Technology Limited or of any other group company.

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

_______________________________________________
OAuth mailing list<= br>OAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth


_______________________________= ________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


--001a11449c264949ef054de4323a-- From nobody Mon Apr 24 03:16:33 2017 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D73EA12EC21; Mon, 24 Apr 2017 03:16:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alexey Melnikov To: "The IESG" Cc: draft-ietf-oauth-jwsreq@ietf.org, oauth-chairs@ietf.org, Hannes.Tschofenig@gmx.net, oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149302898487.25852.14603447850318285300.idtracker@ietfa.amsl.com> Date: Mon, 24 Apr 2017 03:16:24 -0700 Archived-At: Subject: [OAUTH-WG] Alexey Melnikov's Discuss on draft-ietf-oauth-jwsreq-13: (with DISCUSS) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 10:16:25 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-oauth-jwsreq-13: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thank you for addressing my DISCUSS about use of RFC 6125. I have one new small issue from your recent change in In 5.2.3 (that was addressing my comment to include a response example): the example doesn't include Content-Type and (possibly) Transfer-Encoding header fields. Without these it doesn't look syntactically correct. From nobody Mon Apr 24 04:13:20 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A818131467 for ; Mon, 24 Apr 2017 04:13:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MNwP87udUtb9 for ; Mon, 24 Apr 2017 04:13:17 -0700 (PDT) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B25E012EB15 for ; Mon, 24 Apr 2017 04:13:17 -0700 (PDT) Received: by mail-it0-x230.google.com with SMTP id x188so50549564itb.0 for ; Mon, 24 Apr 2017 04:13:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=AwRTpe8E6go3NXKVUVoZ8pM6JTeGA7HKomguqfue38I=; b=F2KM4rCLf4picn+hP8jpaG2rPPndnsqzSVMZXr0evkX51j4sG+/jBJolIHgo2aP23C +oZC9sLJ/6bG0Q2SvKFjrnC7MioQ5Ggdfc/G7//YkrGJSD8sKb5PsyE5G/NrQh6OZn+5 zlrEmx5aQlvM2YmFYyOd6n5NUOrSnAkyzuHlZHQAiJhoSEfETD1gxS2ODOF9cNcreQ+g bXHcMUeXf+pgfh39QgrdiHfHDgC5S1DVcJJAEQeqkfyeL3Q5A+of6fr2fAUb/Jz3qk3f 6NRCQ4Q1/MDpJ84lN/I3hPjbSrd/Tojud33iwZRXblXghYJ0/j7enUPasF9QMDdGiJsl AviA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=AwRTpe8E6go3NXKVUVoZ8pM6JTeGA7HKomguqfue38I=; b=d1vFSCM0L0Ne2HV6spQH5RkSvGuuNKNRIi+E82P59/g/mdYcXzJ7Rg1Wzav7uOFKOR GDPV1FqbUGRnBXiWTekaBttivGzoYfAtuREIpIMCE6aEQkcoDXN+KOc+eBugGEhB5r73 zGiazydaa9UmUsbVk7ajCRfm8gxp1Y5/agpvl1YzP/jV+UjGeB7K3XGslQ8mbqzII9Jy Fm41/iTLXQM35Ja3ZWgM0RPiM3167fTmzdUk7cMC2LGpfa51GwVa9uSPD1o6MxoEVION znB3SUSYsEahJnLniy+/H2vdvYHq/gUM9yOmgwisBjypbc5kwq0CcW80O/ZffAIK4rLP mjPQ== X-Gm-Message-State: AN3rC/6DJaCl+X//DX6POtoi8cgLG/DNi0WFm+Na89uWtK8oezTqn25G 9IxZbDuFlzKF7VAiNFRzKs7ORvSyFhwojRA= X-Received: by 10.36.41.7 with SMTP id p7mr12463966itp.92.1493032303101; Mon, 24 Apr 2017 04:11:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.147.135 with HTTP; Mon, 24 Apr 2017 04:11:41 -0700 (PDT) Received: by 10.107.147.135 with HTTP; Mon, 24 Apr 2017 04:11:41 -0700 (PDT) In-Reply-To: <149302898487.25852.14603447850318285300.idtracker@ietfa.amsl.com> References: <149302898487.25852.14603447850318285300.idtracker@ietfa.amsl.com> From: John Bradley Date: Mon, 24 Apr 2017 08:11:41 -0300 Message-ID: To: Alexey Melnikov Cc: IESG , IETF oauth WG , Hannes.Tschofenig@gmx.net, draft-ietf-oauth-jwsreq@ietf.org, oauth-chairs@ietf.org Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a11441d2c13ab0f054de7acfb" Archived-At: Subject: Re: [OAUTH-WG] Alexey Melnikov's Discuss on draft-ietf-oauth-jwsreq-13: (with DISCUSS) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 11:13:19 -0000 --001a11441d2c13ab0f054de7acfb Content-Type: multipart/alternative; boundary=001a11441d2c10c1f1054de7acfd --001a11441d2c10c1f1054de7acfd Content-Type: text/plain; charset=UTF-8 Thanks. We will try to address that today. John B. On Apr 24, 2017 7:16 AM, "Alexey Melnikov" wrote: > Alexey Melnikov has entered the following ballot position for > draft-ietf-oauth-jwsreq-13: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Thank you for addressing my DISCUSS about use of RFC 6125. > > I have one new small issue from your recent change in In 5.2.3 (that was > addressing my comment to include a response example): the example doesn't > include Content-Type and (possibly) Transfer-Encoding header fields. > Without these it doesn't look syntactically correct. > > > > > --001a11441d2c10c1f1054de7acfd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks.=C2=A0 We will try to address that today. =C2=A0
John B. =C2=A0

On Apr 24, 2017 7:16 A= M, "Alexey Melnikov" <aamelnikov@fastmail.fm> wrote:
Alexey Melnikov has entered the following ballot positi= on for
draft-ietf-oauth-jwsreq-13: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/<= wbr>statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/dra= ft-ietf-oauth-jwsreq/



-----------------------------------------------------------------= -----
DISCUSS:
-----------------------------------------------------------------= -----

Thank you for addressing my DISCUSS about use of RFC 6125.

I have one=C2=A0 new small issue from your recent change in In 5.2.3 (that = was
addressing my comment to include a response example): the example doesn'= ;t
include Content-Type and (possibly) Transfer-Encoding header fields.
Without these it doesn't look syntactically correct.




--001a11441d2c10c1f1054de7acfd-- --001a11441d2c13ab0f054de7acfb Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIRGwYJKoZIhvcNAQcCoIIRDDCCEQgCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg gg4rMIIErzCCA5egAwIBAgIRAOAjyxUSg1OJrWFuelRnayEwDQYJKoZIhvcNAQELBQAwbzELMAkG A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0xNDEy MjIwMDAwMDBaFw0yMDA1MzAxMDQ4MzhaMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRl ZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1 cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCJsQ3aelMZTnBSHbxW pgYmt7hJ4JbnUavx8FoTSRWjtIwbYLx6UUKneYykIt8XYU6R1XYjChTTSgJ/th0JgG6lBD3ZursW /qGHqS5DUkMWfK8yUMimT1rpCNjPkyWce4joMGTmpPhWgP0qJBQzF5msROVpi6NGBkvCM9TpQJ8G sLGsk0C5tQiTOpwqU6MQ2z0gYTxVA47ZTnYlAiEp+qN8cXZP7uFfgen7VIDbw3s1UreE3iI9LDAt MX9ZvVI3sDNpLUPr+tal8Zd3Z1GM2e4n67ylBzh2jKSpOP/fjPUDrEm+yvdzmToPMquclToTPQ5G Old0YVC+xkA/y+Tin6IhAgMBAAGjggEXMIIBEzAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73g JMtUGjAdBgNVHQ4EFgQUkmFrguGioKpP7GfxwqP3tIAAwewwDgYDVR0PAQH/BAQDAgGGMBIGA1Ud EwEB/wQIMAYBAf8CAQAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBEGA1UdIAQKMAgw BgYEVR0gADBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vQWRkVHJ1 c3RFeHRlcm5hbENBUm9vdC5jcmwwNQYIKwYBBQUHAQEEKTAnMCUGCCsGAQUFBzABhhlodHRwOi8v b2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBCwUAA4IBAQAbKm6sVcE6q4jF2O3NVfOqa2Er wAkQI5kPxWZqb7H1tLV3Xg8CYQDffQX+ErOkgIAA/PsdW2pyAgpBvAW6wVjVJsLq1U2E+/6CmM9Y G+MiY5xS+LsFNqt9WKXeqztj5drVc+/s4Pt74qP/8EIjnMq2jU0+5EsYA7KoLdTYu0JLkGmFENum NzToe+ABEKWcyjrHn0+ING6KZdAairup3MrKNtH0/MJkKTWv1rGncRHSA0Oxjz6a7J4yU/R2ksqG NAe5LMrmHErYmQ3BhuKQkvtaQmojIRDpZcf11bt+6oyFIAJi6tE6ByxZxZkz8jiJ5bbpFnofeRT2 ShAaJvp8ivubMIIENjCCAx6gAwIBAgIBATANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEU MBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3 b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTAwMDUzMDEwNDgzOFoX DTIwMDUzMDEwNDgzOFowbzELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYD VQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0 ZXJuYWwgQ0EgUm9vdDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALf3GjPm8gAELTng TlvtH7xsD821+iO2zt6bETOXpClMfZOfvUq8k+0DGuOPz+VtUFrWlymUWoCwSXrbLpX9uMq/Nzgt Hj6RQa1wVsfwTz/oMp50ysiQVOnGXw94nZpAPA6sYapeFI+eh6FqUNzXmk6vBbOmcZSccbNQYArH E504B4YCqOmoaSYYkKtMsE8jqzpPhNjfzp/haW+710LXa0Tkx63ubUFfclpxCDezeWWkWaCUN/cA Lw3CknLa0Dhy2xSoRcRdKn23tNbE7qzNE0S3ySvdQwAl+mG5aWpYIxG3pzOPVnVZ9c0p10a3Citl ttNCbxWyuHv77+ldU9U0WicCAwEAAaOB3DCB2TAdBgNVHQ4EFgQUrb2YejS0Jvf6xCZU7wO94CTL VBowCwYDVR0PBAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wgZkGA1UdIwSBkTCBjoAUrb2YejS0Jvf6 xCZU7wO94CTLVBqhc6RxMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4 dGVybmFsIENBIFJvb3SCAQEwDQYJKoZIhvcNAQEFBQADggEBALCb4IUlwtYj4g+WBpKdQZic2YR5 gdkeWxQHIzZlj7DYd7usQWxHYINRsPkyPef89iYTx4AWpb9a/IfPeHmJIZriTAcKhjW88t5RxNKW t9x+Tu5w/Rw56wwCURQtjr0W4MHfRnXnJK3s9EK0hZNwEGe6nQY1ShjTK3rMUUKhemPR5ruhxSvC Nr4TDea9Y355e6cJDUCrat2PisP29owaQgVR1EX1n6diIWgVIEM8med8vSTYqZEXc4g/VhsxOBi0 cQ+azcgOno4uG+GMmIPLHzHxREzGBHNJdmAPx/i9F4BrLunMTA5amnkPIAou1Z5jJh5VkpTYghda e9C8x49OhgQwggU6MIIEIqADAgECAhEA2TLMtWuXNcB2cbqZ/VgVujANBgkqhkiG9w0BAQsFADCB mzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2 IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE3MDEwOTAwMDAw MFoXDTE4MDEwOTIzNTk1OVowIjEgMB4GCSqGSIb3DQEJARYRdmU3anRiQHZlN2p0Yi5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDW2rqobOFQ/XmzH3DG2UK1Dt6jtc+OFZ71KQoB o8IZa/V94Ey12BPjBcoj+cjHNVsLd2QiUpMcf5sZFMX1cmvpR7TiUISgVcHe8zgiUUvN5Jn5tPDM Kb4E34TtDEG2X5FyY35AwCl8NV/loj2D5KLid9BLdVTJjfqokjLQ/4qCQjWBjfTpIdAdr3lXfg5f a5UPyIkphEIplM8/yGfX0W/PBl804XAL0gesLrfEMdgG58UCN1wJMgH4uRKmKU/U2Ap4W9hTpioN M722U8x7N6P1v6MqTAWCUaskdOp+ktNxFGxOlCE7BEo/EIaWbEt5RHwDePctScDLsi56+VI3TysR AgMBAAGjggHvMIIB6zAfBgNVHSMEGDAWgBSSYWuC4aKgqk/sZ/HCo/e0gADB7DAdBgNVHQ4EFgQU Yg3SsFWhMro4Abonbn1IX4JKj5QwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0l BBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9 MDsGDCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0 L0NQUzBdBgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9TSEEy NTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDBYBggrBgEFBQcwAoZMaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xp ZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDov L29jc3AuY29tb2RvY2EuY29tMBwGA1UdEQQVMBOBEXZlN2p0YkB2ZTdqdGIuY29tMA0GCSqGSIb3 DQEBCwUAA4IBAQCC26y+6/+SJoRQWepca+rB9eSSwaCAb8nNqA+00ZiOHb+6UbbV1xa7Z8wDIuEL 5UKbNtQ2NDArvzF9YI0xNafoV1AEmP/3+ljxQHSEI0U1p2h401sOx+nSjcwtTzACso1lw+I0oJYM JFITOIfZy8HgFpCipBrQAp9jMJ+KSKDX3xu/hzPosfdnXp7sV1KAjkFrAtR3AnQYfJ5W8QrsmC4N BbiAKoYWUSdklqn3v1neTG/+oOhcw7hcGZo+YmPyF9Cdy0gBtwSHPt8hluhg2TlzmqYfi0dVL/mU jCBNUY/BFH+MBqKF7sOIRMv8ALWceVaM/NEcBciKs4eR99A4cw9ZMYICtDCCArACAQEwgbEwgZsx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRANkyzLVrlzXAdnG6mf1Y FbowDQYJYIZIAWUDBAIBBQCggdQwLwYJKoZIhvcNAQkEMSIEIG0s5xb0LGAqeWWAO8hEMYqvWg3I y9Gg168QsYDzjbjgMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE3 MDQyNDExMTE0M1owaQYJKoZIhvcNAQkPMVwwWjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzALBgkqhkiG9w0BAQowCwYJKoZIhvcNAQEHMAsGCWCGSAFl AwQCATANBgkqhkiG9w0BAQEFAASCAQDB17Z/7rjflJuBL1CAp7A5GMgMeo28pZeKkveM+A8+2vl6 I6XV+q4NIWYryplS3UcyGyQOVOGcLTlaJV23kywkIXW6MwhRZ7szwS84yEKB13G6WjVDzRQdJ6wu P4loDxLQM1pElGbJ1NLuB4JKncecjdBBhoohJP02+bvfLUf2/5G4Da3PuXxd93c8/sd1x7+fVoXR WW87QO7Dk58MeWvQYRivEc2ZbBB2naxzJTF2hFk3wtlEJsEqbd0h+pNc2sCfWe0ZFbpz8NEUW8TU gMtgKZSsm1nrzXrKCST5LgDkFVgoetu4dsIinC3v9SGnXQefsIzGFmBmC2WB0wtMNElT --001a11441d2c13ab0f054de7acfb-- From nobody Mon Apr 24 14:46:00 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CB75126E01 for ; Mon, 24 Apr 2017 14:45:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7oujfc7hryCY for ; Mon, 24 Apr 2017 14:45:52 -0700 (PDT) Received: from mail-pg0-x229.google.com (mail-pg0-x229.google.com [IPv6:2607:f8b0:400e:c05::229]) (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 A7B16120227 for ; Mon, 24 Apr 2017 14:45:52 -0700 (PDT) Received: by mail-pg0-x229.google.com with SMTP id 63so18867887pgh.0 for ; Mon, 24 Apr 2017 14:45:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=j8PYYbic1d7mx+xft1edzFMB2MAJvtqOwYaVu9jRxTc=; b=S4vSOYvt6vpGtRtCPJhNvPPOP5ML049B5fKEF7PNyJH+SiSNqyrExiwiM5AsIPJhsh +9bVRDRBFXul1hJq5qDyn1HMmkUhXzD5HgeRrQHQA3ayhOuHjBJpoUnv7bAxuEzptKJR 1SjY7qmNv8/JEagq4Ar49LZ0UzFHF2FXcLMuc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=j8PYYbic1d7mx+xft1edzFMB2MAJvtqOwYaVu9jRxTc=; b=X5mRV6f/esls97TjY+PManB+vqVICawxCFl5ow9PSn6gDypOPagf4lXWL/dqVbQEiA 5nfGC7AQbarT8EhkQqkbZtFdFpJfc+6zWCR+xlb9Kq76TkBm57/tIjzhSDBey1DXGQ6A KB5pO/FROMaDTBJil9w1koOMz3IeOIcXdX3PO8OrVG/Gm6hC26thjTXj6hS650Se22c0 C1/3wb3VyI+Nloo80Kw4aDOir7BIfsXZ9rwZBfqreJS8JgduSH9TcV1JP/CjtlCVgaS6 f765b9gFKN0/gDmnaMBs4J3Yx3LZs9lyjasAQriG6GvGeSerZrlS/T/T9fc+KofmsFOC iWog== X-Gm-Message-State: AN3rC/6i2dWfC99MfQTkluyTpn+0+p2WsvBy4ZB7UaKENtKMu+mHBv8e 0r4yvov0rQkSFJgS+lSRCqmKrf6Eyrqg X-Received: by 10.98.93.147 with SMTP id n19mr26989653pfj.226.1493070352074; Mon, 24 Apr 2017 14:45:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.170.13 with HTTP; Mon, 24 Apr 2017 14:45:21 -0700 (PDT) In-Reply-To: References: <58ddcfc3.5c2e6b0a.7b9e3.bbc6@mx.google.com> <58ddd7a5.e4886b0a.bf30d.bce7@mx.google.com> From: Brian Campbell Date: Mon, 24 Apr 2017 15:45:21 -0600 Message-ID: To: Nat Sakimura Cc: John Bradley , IETF oauth WG Content-Type: multipart/alternative; boundary=001a113ede16f5e25e054df0870a Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-13.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 21:45:56 -0000 --001a113ede16f5e25e054df0870a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable One more thing, this document really should register "iss", "aud", and "exp" (and maybe other common JWT claims that are about the token itself like "jti", "iat", etc) as authorization request parameters in https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#pa= rameters because the parameter names and claim names collide when using a JWT Secured Authorization Request. On Tue, Apr 4, 2017 at 9:41 AM, Nat Sakimura wrote: > Thanks Brian for spotting these. I will make the corrections in -14. > > Best, > > Nat > > On Fri, Mar 31, 2017 at 10:40 PM Brian Campbell < > bcampbell@pingidentity.com> wrote: > > and a typo - "If thie location is" should say "If this location is" > > On Fri, Mar 31, 2017 at 8:37 AM, Brian Campbell < > bcampbell@pingidentity.com> wrote: > > BTW, the intro still has text about 'dynamic parameters such as "state"' > that need to be cleaned up. https://tools.ietf.org/html/ > draft-ietf-oauth-jwsreq-13#section-1 > > On Fri, Mar 31, 2017 at 8:36 AM, Brian Campbell < > bcampbell@pingidentity.com> wrote: > > "The current text causes the AS to ignore them and not return a error. " = - > except that I don't believe the current text actually specifies that > anywhere. And I think that the intent of Mike's original comment was that > -13 doesn't specify the behavior but that it needs to be revised to do so= . > > I'd suggest that the doc say that the client must include in the request > object (request or request_uri) all the oauth parameters that it sends. A= nd > when request or request_uri is sent, that the AS must/should only rely on > parameter values from the request object. > > I think being semi or somewhat compatible or tolerant of the Connect > variation or request/request_uri is good because it uses the same paramet= er > names, the same endpoint, and the same metadata names. > > > > > > > On Thu, Mar 30, 2017 at 11:14 PM, John Bradley wrote: > > They are mutually exclusive. > > > > However there are two options as to how the authorization endpoint would > treat extra query parameters like state if they are sent. > > > > The current text causes the AS to ignore them and not return a error. > This would be more backwards compatible with the request object in OpenID > Connect, however in reality it may cause connect clients to send paramete= rs > as query parameters that would be processed by a connect server that wou= ld > be ignored by a OAuth server without any obvious error. There may howeve= r > be subtle errors downstream from missing parameters. > > > > The other option is to have a cleaner breaking change from Connect and > have the Authorization endpoint return a error if anything other than the > two new parameters are sent to the authorization endpoint. > > > > I am leaning towards the latter as it is easier to debug, and wont allow > incompatible Connect requests to be accepted without a error. We would > have done this in Connect but couldn=E2=80=99t drop required parameters f= rom OAuth > in a Connect spec. > > > > The downside for the latter is that the client would need to know if the > AS is supporting The Connect version or the OAuth version. > > > > One of the typical conundrums around how to deal with doing the best goin= g > forward thing vs not blowing up older implementations. > > > > In the current proposal a client could put the required parameters both > places and the same request would work on servers supporting both the > Connect and OAuth versions. > > > > John B. > > Sent from Mail for > Windows 10 > > > > *From: *Torsten Lodderstedt > *Sent: *March 30, 2017 11:01 PM > *To: *John Bradley > *Cc: *Nat Sakimura ; Nat Sakimura ;= IETF > oauth WG > *Subject: *Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-13.txt > > > > I had assumed using the request object is mutual exclusive to use of URI > query parameters. Did I misinterpret the draft? > > > > Am 30.03.2017 um 22:40 schrieb John Bradley : > > > > It is a trade off between compatibility with Connect and possible > configuration errors. > > > > In reality it may not be compatible with Connect if the client is sending > some parameters outside the object without including them in the object a= s > a Connect client might. You would potentially wind up dropping state o= r > nonce without an error. > > > > I asked Mike and he was leaning to making it a error to send them as quer= y > parameters as that would be a clean change. > > > > I think the choice is a bit of a grey area. > > > > Sent from Mail for > Windows 10 > > > > *From: *sakimura@gmail.com > *Sent: *March 30, 2017 9:57 PM > *To: *John Bradley ; Nat Sakimura > *Cc: *IETF oauth WG > *Subject: *Re: [OAUTH-WG] FW: I-D Action: draft-ietf-oauth-jwsreq-13.txt > > > > +1 > > Sent from my Huawei Mobile > > > > -------- Original Message -------- > Subject: Re: [OAUTH-WG] FW: I-D Action: draft-ietf-oauth-jwsreq-13.txt > From: John Bradley > To: Nat Sakimura > CC: IETF oauth WG > > So I think we need to make the must ignore clearer for the additional > paramaters on the authorization endpoint. > > > > On Mar 30, 2017 17:33, "Nat Sakimura" wrote: > > Not right now. > > As of this writing, a client can still send duplicate parameters in the > query but they get ignored by the servers honoring OAuth JAR. So, it is > backwards compatible with OpenID Connect in that sense (OpenID Connect > sends duplicate manatory RFC6749 parameters as the query parameters as we= ll > just to be compliant to RFC6749). Conversely, servers that do not support > OAuth JAR will ignore request_uri etc. > > On Mar 30, 2017, at 4:47 PM, Mike Jones > wrote: > > Is there a clear statement somewhere along the lines of =E2=80=9Cparamete= rs > (other than =E2=80=9Crequest=E2=80=9D or =E2=80=9Crequest_uri=E2=80=9D) a= re only allowed to be in the > signed object if a signed object is used=E2=80=9D? That=E2=80=99s the ki= nd of thing I > was looking for and didn=E2=80=99t find. > > > > -- Mike > > *From:* John Bradley [mailto:ve7jtb@ve7jtb.com] > *Sent:* Thursday, March 30, 2017 4:44 PM > *To:* Mike Jones > *Cc:* Nat Sakimura ; IETF oauth WG > *Subject:* RE: [OAUTH-WG] FW: I-D Action: draft-ietf-oauth-jwsreq-13.txt > > > > The intent of the change is to only allow the paramaters to be in the > signed object if a signed object is used. > > > > This requires State, nonce etc to be in the JWT. Only one place to check > will hopefully reduce implimentation errors. > > > > This also allows us to remove the caching text as we now have one JWT per > request, so caching won't happen. > > > > John B. > > > > > > > > On Mar 30, 2017 4:36 PM, "Mike Jones" > wrote: > > I **believe** the intent is that **all** parameters must be in the > request object, but the spec doesn=E2=80=99t actually say that, as far as= I can > tell. Or maybe the intent is that parameters must not be duplicated > between the query parameters and the request object. > > > > One or the other of these statements should be explicitly included in the > specification. Of course, I could have missed the statement I=E2=80=99m = asking for > in my review, in which case please let me know what I missed. > > > > Thanks, > > -- Mike > > > > *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *John Bradley > *Sent:* Thursday, March 30, 2017 3:00 PM > *To:* IETF OAUTH > *Subject:* [OAUTH-WG] FW: I-D Action: draft-ietf-oauth-jwsreq-13.txt > > > > Based on feeback from the IESG we have removed some of the optionality in > the draft. > > > > It is a shorter read than draft 12. > > > > John B. > > > > Sent from Mail for > Windows 10 > > > > *From: *internet-drafts@ietf.org > *Sent: *March 30, 2017 1:38 PM > *To: *i-d-announce@ietf.org > *Cc: *oauth@ietf.org > *Subject: *[OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-13.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Web Authorization Protocol of the IETF. > > > > Title : The OAuth 2.0 Authorization Framework: JWT > Secured Authorization Request (JAR) > > Authors : Nat Sakimura > > John Bradley > > Filename : draft-ietf-oauth-jwsreq-13.txt > > Pages : 27 > > Date : 2017-03-30 > > > > Abstract: > > The authorization request in OAuth 2.0 described in RFC 6749 utilizes > > query parameter serialization, which means that Authorization Request > > parameters are encoded in the URI of the request and sent through > > user agents such as web browsers. While it is easy to implement, it > > means that (a) the communication through the user agents are not > > integrity protected and thus the parameters can be tainted, and (b) > > the source of the communication is not authenticated. Because of > > these weaknesses, several attacks to the protocol have now been put > > forward. > > > > This document introduces the ability to send request parameters in a > > JSON Web Token (JWT) instead, which allows the request to be signed > > with JSON Web Signature (JWS) and/or encrypted with JSON Web > > Encryption (JWE) so that the integrity, source authentication and > > confidentiality property of the Authorization Request is attained. > > The request can be sent by value or by reference. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-13 > > https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwsreq-13 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-jwsreq-13 > > > > > > Please note that it may take a couple of minutes from the time of > submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > -- > > Nat Sakimura > > Chairman of the Board, OpenID Foundation > --001a113ede16f5e25e054df0870a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
One more thing, this document really should register "= ;iss", "aud", and "exp" (and maybe other common JW= T claims that are about the token itself like "jti", "iat&qu= ot;, etc) as authorization request parameters in https= ://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#paramet= ers because the parameter names and claim names collide when using a JW= T Secured Authorization Request.

<= div class=3D"gmail_quote">On Tue, Apr 4, 2017 at 9:41 AM, Nat Sakimura <nat= @sakimura.org> wrote:
Than= ks Brian for spotting these. I will make the corrections in -14.=C2=A0

Best,=C2= =A0
<= div class=3D"m_-8087006312547883924gmail_msg">
Nat

On Fri, Mar 31, 2017 at 10:4= 0 PM Brian Campbell <bcampbell@pingidenti= ty.com> wrote:
and a typo - "If thie location is" should say &q= uot;If this location is"
=

On Fri, Mar 31, 2017 at 8:37 AM, Brian Campbell <= span dir=3D"ltr" class=3D"m_-8087006312547883924gmail_msg"><bcampbell@pingidentity.com> wrote:
BTW, the intro still has text about 'dynamic parameters such = as "state"' that need to be cleaned up.=C2=A0 https://tools.ietf.org/html/= draft-ietf-oauth-jwsreq-13#section-1

On Fri, Mar 31, 2017 a= t 8:36 AM, Brian Campbell <bcampbell@pingidentity.com> wrote:
"The current t= ext causes the AS to ignore them and not return a error. " - except th= at I don't believe the current text actually specifies that anywhere. A= nd I think that the intent of Mike's original comment was that -13 does= n't specify the behavior but that it needs to be revised to do so.

I'd suggest that the doc say that the client must inc= lude in the request object (request or request_uri) all the oauth parameter= s that it sends. And when request or request_uri is sent, that the AS must/= should only rely on parameter values from the request object.

I think being semi or somewhat compatible or tolerant of the Conne= ct variation or request/request_uri is good because it uses the same parame= ter names, the same endpoint, and the same metadata names.




= =C2=A0

On Thu, Mar 30, 2017 at 11:14 PM, John Bradley <ve7jtb@ve7= jtb.com> wrote:
=

They are mutually exclusive.

=C2=A0

However there are two o= ptions as to how the authorization endpoint would treat extra query paramet= ers like state if they are sent.

=C2=A0

The current text causes the AS to ignore them = and not return a error.=C2=A0 This would be more backwards compatible with = the request object in OpenID Connect, however in reality it may cause conne= ct clients to send parameters as query parameters =C2=A0that would be proce= ssed by a connect server that would be ignored by a OAuth server without an= y obvious error.=C2=A0 There may however be subtle errors downstream from m= issing parameters.

=C2=A0

The other option is to have a cleaner breaking change from C= onnect and have the Authorization endpoint return a error if anything other= than the two new parameters are sent to the authorization endpoint.

=C2=A0

I am leani= ng towards the latter as it is easier to debug,=C2=A0 and wont allow incomp= atible Connect requests to be accepted without a error.=C2=A0=C2=A0 We woul= d have done this in Connect but couldn=E2=80=99t drop required parameters f= rom OAuth in a Connect spec.

=C2=A0

The downside for the latter is that the client wou= ld need to know if the AS is supporting The Connect version or the OAuth ve= rsion.

=C2=A0

One of the typical conundrums around how to deal with doing the best g= oing forward thing vs not blowing up older implementations.

=C2=A0

In the current prop= osal a client could put the required parameters both places and the same re= quest would work on servers supporting both the Connect and OAuth versions.=

=C2=A0

John B.

Sent from Mail for Windows 10

=C2=A0

From: Torsten LodderstedtSent: March 30, 2017 11:01 PM
To: John Bradley
Cc: Nat Sakimura; Nat Sakimura; IETF oauth WG
Subject: Re: [OAUTH-WG] I-D Act= ion: draft-ietf-oauth-jwsreq-13.txt

=C2=A0

I had assumed using the request object is mutual exclusi= ve to use of URI query parameters. Did I misinterpret the draft?

=C2=A0

<= div class=3D"m_-8087006312547883924gmail_msg">

Am 30.03.2017 um 22:40 schrieb John Bradley <<= a href=3D"mailto:ve7jtb@ve7jtb.com" class=3D"m_-8087006312547883924gmail_ms= g" target=3D"_blank">ve7jtb@ve7jtb.com>:

<= /div>

=C2=A0

It is a trade off between compatibility with Connect and p= ossible configuration errors.<= /u>

=C2=A0

In reality it may not be c= ompatible with Connect if the client is sending some parameters outside the= object without including them in the object as a Connect client might.=C2= =A0=C2=A0=C2=A0 You would potentially wind up dropping state or nonce witho= ut an error.=C2=A0

=C2=A0

I asked Mike and he was leaning to m= aking it a error to send them as query parameters as that would be a clean = change.

=C2=A0

I think the choice is a bit of a grey area.

Sent from Mail= for Windows 10

=C2=A0

From: sakimura@gmail.com
Sent: March 3= 0, 2017 9:57 PM
To: John Bradley; Nat Sakimura
Cc: IETF oauth WG
Subject: Re: [OAUTH-WG] FW: I= -D Action: draft-ietf-oauth-jwsreq-13.txt

<= p class=3D"MsoNormal m_-8087006312547883924gmail_msg">=C2=A0

+1

Sent from my Huawei Mobile



-------- O= riginal Message --------
Subje= ct: Re: [OAUTH-WG] FW: I-D Action: draft-ietf-oauth-jwsreq-13.txt
From: John Bradley
To: Nat Sakimura
CC: IETF oauth WG

So I think we need to make the must = ignore clearer for the additional paramaters on the authorization endpoint.= =C2=A0

=C2=A0

On Mar 30, 2017 17:33, "Nat Sakimur= a" <nat@sakimura.org> wrote:

Not right no= w.

As of this writing, a client can still send duplicate para= meters in the query but they get ignored by the servers honoring OAuth JAR.= So, it is backwards compatible with OpenID Connect in that sense (OpenID C= onnect sends duplicate manatory RFC6749 parameters as the query parameters = as well just to be compliant to RFC6749). Conversely, servers that do not s= upport OAuth JAR will ignore request_uri etc.

On Mar 30, 2017= , at 4:47 PM, Mike Jones <Michael.Jones@= microsoft.com> wrote:

Is there a clear statement somewhere along the lines of =E2= =80=9Cparameters (other than =E2=80=9Crequest=E2=80=9D or =E2=80=9Cr= equest_uri=E2=80=9D) are only allowed to be in the signed object if a signe= d object is used=E2=80=9D?=C2=A0 That=E2=80=99s the kind of thing I was lookin= g for and didn=E2=80=99t find.

=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

From: John Bradley [mailto:ve7jtb@ve7jtb.com]
Sent: Thursday, March 30, 2017 4:44 PM
To: Mike Jones <Michael.Jones@micr= osoft.com>
Cc: Nat Sakimura <nat@sakimura.org>; IETF oauth WG <oauth@ie= tf.org>
Subject: RE: [OAUTH-WG] FW: I-D Action: d= raft-ietf-oauth-jwsreq-13.txt =

=C2=A0

The intent of th= e change is to only allow the paramaters to be in the signed object if a si= gned object is used. =C2=A0

<= p class=3D"MsoNormal m_-8087006312547883924gmail_msg" style=3D"margin-left:= 50.4pt">=C2=A0

This requires State, nonce etc to be in = the JWT.=C2=A0 Only one place to check will hopefully reduce implimentation= errors. =C2=A0

=C2=A0

This also allows us to remove the caching te= xt as we now have one JWT per request, so caching won't happen. =C2=A0= =C2=A0

=C2=A0 =

John B. =C2=A0

=C2=A0

=C2=A0

=C2=A0

On Mar 30, 2017 4:36 PM, &quo= t;Mike Jones" <Michael.Jones@micros= oft.com> wrote:

I *believe* the intent is that *all* parameters must be in the request = object, but the spec doesn=E2=80=99t actually say that, as far as I can tel= l.=C2=A0 Or maybe the intent is that parameters must not be duplicated betw= een the query parameters and the request object. =

=C2=A0 =

One or the other of these statements= should be explicitly included in the specification.=C2=A0 Of course, I cou= ld have missed the statement I=E2=80=99m asking for in my review, in which = case please let me know what I missed.

=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 Thanks,

=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: OAut= h [mailto:oauth-bounces@ietf.org] On Behalf Of John Bradley
Sent: Thursday, March 30, 2017 3:00 PM
To:= IETF OAUTH <oauth@ietf.org>
Su= bject: [OAUTH-WG] FW: I-D Action: draft-ietf-oauth-jwsreq-13.txt

=C2=A0

Based on fee= back from the IESG we have removed some of the optionality in the draft.

=C2=A0

It is a shorter read= than draft 12.=C2=A0=C2=A0

=C2=A0

John B.

=C2=A0

Sent from Mail for Windo= ws 10

=C2=A0

From: internet-drafts@ietf.org
Sent: March 30, 2017 1:38 PM
To: i-d-announce@ietf.org
Cc: oauth@ietf.org
Subject: [OAUTH-WG] = I-D Action: draft-ietf-oauth-jwsreq-13.txt

=C2=A0

=C2=A0

A New Internet-Draft is= available from the on-line Internet-Drafts directories.

This draft is a work item of the Web Authorization Protoc= ol of the IETF.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Title=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : The OAuth 2.0 Authorization Framewor= k: JWT Secured Authorization Request (JAR)

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Authors=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 : Nat Sakimura

=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 John Bradley

=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Filename=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 : draft-ietf-oauth-jwsreq-13.txt =

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 P= ages=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : 27

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 Date=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 : 2017-03-30 <= /u>

=C2=A0

Abstract:

=C2=A0=C2=A0 The a= uthorization request in OAuth 2.0 described in RFC 6749 utilizes

=C2=A0=C2=A0 query parameter serialization, whi= ch means that Authorization Request

=C2= =A0=C2=A0 parameters are encoded in the URI of the request and sent through=

=C2=A0=C2=A0user agents such as web br= owsers.=C2=A0 While it is easy to implement, it

=

=C2=A0=C2=A0 means that (a) the communication through the user age= nts are not

=C2=A0=C2=A0 integrity prot= ected and thus the parameters can be tainted, and (b)

=C2=A0=C2=A0 the source of the communication is not authenti= cated.=C2=A0 Because of

=C2=A0=C2=A0 th= ese weaknesses, several attacks to the protocol have now been put

=C2=A0=C2=A0 forward.

=C2=A0

=C2=A0=C2=A0 This document introduces the= ability to send request parameters in a

=C2=A0=C2=A0 JSON Web Token (JWT) instead, which allows the request to be= signed

=C2=A0=C2=A0 with JSON Web Sign= ature (JWS) and/or encrypted with JSON Web

=C2=A0=C2=A0 Encryption (JWE) so that the integrity, source authenticat= ion and

=C2=A0=C2=A0 confidentiality pr= operty of the Authorization Request is attained.

=C2=A0=C2=A0 The request can be sent by value or by reference.

=C2=A0

=C2=A0

The IETF datatracker status page for this draft is:

https:= //datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/

=C2=A0=

There are also htmlized versions= available at:

https://tools.ietf.org/html/draft-ietf-oau= th-jwsreq-13

https://datatracker.ietf.org/= doc/html/draft-ietf-oauth-jwsreq-13

=C2=A0

A diff from the previous version is available at= :

https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-= oauth-jwsreq-13 <= u class=3D"m_-8087006312547883924gmail_msg">

=C2=A0

=C2=A0

Please note that it may take a couple of minute= s from the time of submission =

until the= htmlized version and diff are available at tools.ietf.= org.

=C2=A0

Internet-= Drafts are also available by anonymous FTP at:

<= p class=3D"MsoNormal m_-8087006312547883924gmail_msg" style=3D"margin-left:= 55.2pt">ftp://ftp.ietf.org/internet-d= rafts/

=C2=A0 =

_______= ________________________________________

OAuth mailing list =

OAuth@ietf.org <= u class=3D"m_-8087006312547883924gmail_msg">

https://www.ietf.org/mailman/listinfo/oauth=

=

=C2= =A0

=C2=A0

__________________________________= _____________
OAuth mailing li= st
OAuth@ie= tf.org
https://www.ietf.org/mailman/listinfo/oauth<= u class=3D"m_-8087006312547883924gmail_msg">

=C2=A0

=C2=A0=


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.iet= f.org/mailman/listinfo/oauth




_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.iet= f.org/mailman/listinfo/oauth
--

Nat Sakimura

Chairman of the Board, OpenID Foundation


--001a113ede16f5e25e054df0870a-- From nobody Mon Apr 24 18:47:50 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 901BC1319A3 for ; Mon, 24 Apr 2017 18:47:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BUUxQIFWwFJh for ; Mon, 24 Apr 2017 18:47:47 -0700 (PDT) Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::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 2DDB11319A2 for ; Mon, 24 Apr 2017 18:47:47 -0700 (PDT) Received: by mail-pf0-x233.google.com with SMTP id a188so19743129pfa.0 for ; Mon, 24 Apr 2017 18:47:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=oY1yEwrmW3jg9K9LdvKtPNDwazLzoaeT4KoM5ufo8vI=; b=eg/qs+ySvNiehX7hgdW2Mv8SvCBvtJ20wY+4oLPHPtvGN9rvawwIkC+MtxeLBgcA9X ZNYRNHae7LzgDi+0+29Z7O3zsXZMnjlTlifnhLm/SZ0E2/b4lG/FN+OwqDzfuCfZeymz zk1K3XQMBf/2FU6t5RQOajFcFtD3M7vAoyHxI82f8U54p6srmq7yp57GobZ1FD69S6Hb oa+2MR31HLpwckfD5dcbgsH3+CGT5koRBlaxM3ZDwLDGX1y6WrHa4O0a6cGRLgiQMpu0 kALSVMVi1EMyyjrYZN1KDYdu5wY6FZEDqQ0Cu0v68EuYRxEqDFeaOtknjMKLH0m1mvwx ZRxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=oY1yEwrmW3jg9K9LdvKtPNDwazLzoaeT4KoM5ufo8vI=; b=Vrx1DuU3gP063m8qKwRc8kNe0/jHAPxa6/BgAQD5GIfLTWYUmGU7t8GwFebuaxpuEi 1n32LUOhsu++08xbiZ4M+HJ9LkybQ+6O2i+5E9U8OJswpkrToYkFMYfO6UQJSCNjZV98 371Yftpydd1lNNb9RAkZE5/+UirA1g2loHVpAGAgHxOhDLlFP1STeTE6GoGFxfsGLrFE i+wD8+IpuK1zT19qxD6ULC9TznXH3xdgZFKHBCXTI2HhiUJ7ntV0/sHZj1S+aukwN6o7 XtcR2mU9P2l4uvwc3nFh7RHGA2OsSdjM0Ghi9yOphKifsbDSGWlp0kRJVrBdchWVFifa 75Dg== X-Gm-Message-State: AN3rC/7aaiZzosIrGklJ0D2+grCxcocfaucaHqqjfVgTd4fdEVvCJ9l8 d2Ic52d2Ja9rWDA3g108n1PWnYV9oQLz X-Received: by 10.98.92.2 with SMTP id q2mr6508523pfb.244.1493084866602; Mon, 24 Apr 2017 18:47:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.185.143 with HTTP; Mon, 24 Apr 2017 18:47:05 -0700 (PDT) From: Kathleen Moriarty Date: Mon, 24 Apr 2017 21:47:05 -0400 Message-ID: To: "oauth@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [OAUTH-WG] AD review of draft-ietf-oauth-native-apps X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 01:47:48 -0000 Hello, Thanks for taking the time to document this best practice and the implementations in the appendix. I have one comment and a few nits. Security Considerations: I think it would go a long way to organize these as ones that apply to this best practice and ones (8.1 and the example in 8.2) about alternate solutions. This could also be done through some added text, but making this clear would be helpful. Maybe moving 8.1 and 8.2 until after the rest of the sections would be enough and then clearly state the intent of this text. IANA Section: Just a note - you might get some questions about this, but i do think it's fine to leave that text, although unnecessary. Nits: Section 5, punctuation OLD: By applying the same principles from the web to native apps, we gain benefits seen on the web like the usability of a single sign-on session, and the security of a separate authentication context. NEW: By applying the same principles from the web to native apps, we gain benefits seen on the web, like the usability of a single sign-on session and the security of a separate authentication context. The document has text that says 'native app' in some places and 'app' in others, I assume these are used interchangeably? It seems that they are used interchangeably. Really nitty: Section 7.2, Since you are still in the example, did you mean URL in the following: Such claimed HTTPS URIs can be used as OAuth redirect URIs. Such claimed HTTPS URLs can be used as OAuth redirect URIs. And again in the last paragraph of this section. I'm only asking since you specify URL earlier in this section, so you were more specific for the example and then drop back to URI (which is correct, but wondering if you wanted to continue at the same level of specificity or if there was a reason to just say URI here. Section 8.11 s/uri/URI/ -- Best regards, Kathleen From nobody Tue Apr 25 06:10:14 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43DE112EE8D for ; Tue, 25 Apr 2017 06:10:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BbQwe494Jgn8 for ; Tue, 25 Apr 2017 06:10:10 -0700 (PDT) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16F7112EC70 for ; Tue, 25 Apr 2017 06:10:09 -0700 (PDT) Received: by mail-qk0-x22c.google.com with SMTP id f76so63674765qke.2 for ; Tue, 25 Apr 2017 06:10:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=mmSeoUkSmoTsk8wv4ofxFqZW1VZE1Tfvubi+L5oO/7c=; b=DWgZrEPAN12FBy5vYmR4c9lXrkHK2hepXV31DNx4Ss9HmAyIzcdxvSncMtRBSp8gaF i3pLyX6tX8G0cSdiDI0HCKYwpFvwi8OcJZXBCXeJFhHinsIYandZPC5V1n5HpWYwVBLk /dYe7x75JpXrzGWtXaH8x7qB6HkGYZNODr9pLZsTnwidfiyUGVdC4KzSSpoqLtulKxZS JFV/Bk8yk6eExX+G/RIbQwjezSG6Jzus9UO3wta5/BDOLoA6PvnMYGsJQbJAiMU+MTAi 5VyTz0dgSKhMYeAY57+tvhrNKY8n19kAXHYA5OWiYmD51x/P3Ljr/Zqxyn7t4u1rjYob Hgjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=mmSeoUkSmoTsk8wv4ofxFqZW1VZE1Tfvubi+L5oO/7c=; b=YVcX+o0a65ZBHby+Kaq+y/k0uWNrO+gifwx+J4ZtPWJSCgi57x58M/RmDYBJxoCkbe rS+JsL/mTkNtQXELm3TTZE6pbEXOmfnBydhaY2JmCOaAzTKPkaHvrJBJh0quru6yooX3 Tosmus1QFlQ19q+uiXP5ecDSj5XAHMWdtQE89hDLPUndInrQ4J2APCXi7ESImv46agmi 64DJGSc86SConGfps7MoMS71wCKdddW5eSqNdUovy5h9lEmcRr7OuDrXieeCudC3qI15 zBbqNz8trlgMhqtl1x+CfhYYPZ/T2ZMBABte3zAbNG1HgANTqYO+03iZJHjPHlcpm4EN qCgg== X-Gm-Message-State: AN3rC/4squDUug0GzAPK5HfFJef4+xsJ0ObBhQXHJADBLQx58ZzSPnZj qLnplmoxsMDlLaKV X-Received: by 10.55.176.135 with SMTP id z129mr29334577qke.308.1493125808997; Tue, 25 Apr 2017 06:10:08 -0700 (PDT) Received: from [192.168.86.100] ([191.115.231.88]) by smtp.gmail.com with ESMTPSA id h37sm6610718qtc.47.2017.04.25.06.10.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 25 Apr 2017 06:10:08 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: John Bradley In-Reply-To: Date: Tue, 25 Apr 2017 10:09:56 -0300 Cc: "oauth@ietf.org" Message-Id: <48ED0D2A-37C6-4EDB-9570-CF47C4A851DE@ve7jtb.com> References: To: Kathleen Moriarty X-Mailer: Apple Mail (2.3273) Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="94eb2c06569477b940054dfd71b5" Archived-At: Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-native-apps X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 13:10:13 -0000 --94eb2c06569477b940054dfd71b5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Thanks Kathleen, William and I will address these shortly. We can take out the IANA section completely if you think it is better. In the current implementations on Android and iOS Universal Links/App = Links and are only http or HTTPS schema URI making them URL. So while all URL are URI, we could be more specific if that is OK with = the style police. I thought the URL term was currently discouraged.. John B. > On Apr 24, 2017, at 10:47 PM, Kathleen Moriarty = wrote: >=20 > Hello, >=20 > Thanks for taking the time to document this best practice and the > implementations in the appendix. I have one comment and a few nits. >=20 > Security Considerations: > I think it would go a long way to organize these as ones that apply to > this best practice and ones (8.1 and the example in 8.2) about > alternate solutions. This could also be done through some added text, > but making this clear would be helpful. Maybe moving 8.1 and 8.2 > until after the rest of the sections would be enough and then clearly > state the intent of this text. >=20 > IANA Section: > Just a note - you might get some questions about this, but i do think > it's fine to leave that text, although unnecessary. >=20 > Nits: > Section 5, punctuation > OLD: > By applying the same principles from the web to native apps, we gain > benefits seen on the web like the usability of a single sign-on > session, and the security of a separate authentication context. > NEW: > By applying the same principles from the web to native apps, we gain > benefits seen on the web, like the usability of a single sign-on > session and the security of a separate authentication context. >=20 > The document has text that says 'native app' in some places and 'app' > in others, I assume these are used interchangeably? It seems that > they are used interchangeably. >=20 >=20 > Really nitty: > Section 7.2, > Since you are still in the example, did you mean URL in the following: >=20 > Such claimed HTTPS URIs can be used as OAuth redirect URIs. > Such claimed HTTPS URLs can be used as OAuth redirect URIs. >=20 > And again in the last paragraph of this section. >=20 > I'm only asking since you specify URL earlier in this section, so you > were more specific for the example and then drop back to URI (which is > correct, but wondering if you wanted to continue at the same level of > specificity or if there was a reason to just say URI here. >=20 > Section 8.11 > s/uri/URI/ >=20 >=20 > --=20 >=20 > Best regards, > Kathleen >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --94eb2c06569477b940054dfd71b5 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIRGwYJKoZIhvcNAQcCoIIRDDCCEQgCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg gg4rMIIErzCCA5egAwIBAgIRAOAjyxUSg1OJrWFuelRnayEwDQYJKoZIhvcNAQELBQAwbzELMAkG A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0xNDEy MjIwMDAwMDBaFw0yMDA1MzAxMDQ4MzhaMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRl ZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1 cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCJsQ3aelMZTnBSHbxW pgYmt7hJ4JbnUavx8FoTSRWjtIwbYLx6UUKneYykIt8XYU6R1XYjChTTSgJ/th0JgG6lBD3ZursW /qGHqS5DUkMWfK8yUMimT1rpCNjPkyWce4joMGTmpPhWgP0qJBQzF5msROVpi6NGBkvCM9TpQJ8G sLGsk0C5tQiTOpwqU6MQ2z0gYTxVA47ZTnYlAiEp+qN8cXZP7uFfgen7VIDbw3s1UreE3iI9LDAt MX9ZvVI3sDNpLUPr+tal8Zd3Z1GM2e4n67ylBzh2jKSpOP/fjPUDrEm+yvdzmToPMquclToTPQ5G Old0YVC+xkA/y+Tin6IhAgMBAAGjggEXMIIBEzAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73g JMtUGjAdBgNVHQ4EFgQUkmFrguGioKpP7GfxwqP3tIAAwewwDgYDVR0PAQH/BAQDAgGGMBIGA1Ud EwEB/wQIMAYBAf8CAQAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBEGA1UdIAQKMAgw BgYEVR0gADBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vQWRkVHJ1 c3RFeHRlcm5hbENBUm9vdC5jcmwwNQYIKwYBBQUHAQEEKTAnMCUGCCsGAQUFBzABhhlodHRwOi8v b2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBCwUAA4IBAQAbKm6sVcE6q4jF2O3NVfOqa2Er wAkQI5kPxWZqb7H1tLV3Xg8CYQDffQX+ErOkgIAA/PsdW2pyAgpBvAW6wVjVJsLq1U2E+/6CmM9Y G+MiY5xS+LsFNqt9WKXeqztj5drVc+/s4Pt74qP/8EIjnMq2jU0+5EsYA7KoLdTYu0JLkGmFENum NzToe+ABEKWcyjrHn0+ING6KZdAairup3MrKNtH0/MJkKTWv1rGncRHSA0Oxjz6a7J4yU/R2ksqG NAe5LMrmHErYmQ3BhuKQkvtaQmojIRDpZcf11bt+6oyFIAJi6tE6ByxZxZkz8jiJ5bbpFnofeRT2 ShAaJvp8ivubMIIENjCCAx6gAwIBAgIBATANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEU MBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3 b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTAwMDUzMDEwNDgzOFoX DTIwMDUzMDEwNDgzOFowbzELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYD VQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0 ZXJuYWwgQ0EgUm9vdDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALf3GjPm8gAELTng TlvtH7xsD821+iO2zt6bETOXpClMfZOfvUq8k+0DGuOPz+VtUFrWlymUWoCwSXrbLpX9uMq/Nzgt Hj6RQa1wVsfwTz/oMp50ysiQVOnGXw94nZpAPA6sYapeFI+eh6FqUNzXmk6vBbOmcZSccbNQYArH E504B4YCqOmoaSYYkKtMsE8jqzpPhNjfzp/haW+710LXa0Tkx63ubUFfclpxCDezeWWkWaCUN/cA Lw3CknLa0Dhy2xSoRcRdKn23tNbE7qzNE0S3ySvdQwAl+mG5aWpYIxG3pzOPVnVZ9c0p10a3Citl ttNCbxWyuHv77+ldU9U0WicCAwEAAaOB3DCB2TAdBgNVHQ4EFgQUrb2YejS0Jvf6xCZU7wO94CTL VBowCwYDVR0PBAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wgZkGA1UdIwSBkTCBjoAUrb2YejS0Jvf6 xCZU7wO94CTLVBqhc6RxMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4 dGVybmFsIENBIFJvb3SCAQEwDQYJKoZIhvcNAQEFBQADggEBALCb4IUlwtYj4g+WBpKdQZic2YR5 gdkeWxQHIzZlj7DYd7usQWxHYINRsPkyPef89iYTx4AWpb9a/IfPeHmJIZriTAcKhjW88t5RxNKW t9x+Tu5w/Rw56wwCURQtjr0W4MHfRnXnJK3s9EK0hZNwEGe6nQY1ShjTK3rMUUKhemPR5ruhxSvC Nr4TDea9Y355e6cJDUCrat2PisP29owaQgVR1EX1n6diIWgVIEM8med8vSTYqZEXc4g/VhsxOBi0 cQ+azcgOno4uG+GMmIPLHzHxREzGBHNJdmAPx/i9F4BrLunMTA5amnkPIAou1Z5jJh5VkpTYghda e9C8x49OhgQwggU6MIIEIqADAgECAhEA2TLMtWuXNcB2cbqZ/VgVujANBgkqhkiG9w0BAQsFADCB mzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2 IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE3MDEwOTAwMDAw MFoXDTE4MDEwOTIzNTk1OVowIjEgMB4GCSqGSIb3DQEJARYRdmU3anRiQHZlN2p0Yi5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDW2rqobOFQ/XmzH3DG2UK1Dt6jtc+OFZ71KQoB o8IZa/V94Ey12BPjBcoj+cjHNVsLd2QiUpMcf5sZFMX1cmvpR7TiUISgVcHe8zgiUUvN5Jn5tPDM Kb4E34TtDEG2X5FyY35AwCl8NV/loj2D5KLid9BLdVTJjfqokjLQ/4qCQjWBjfTpIdAdr3lXfg5f a5UPyIkphEIplM8/yGfX0W/PBl804XAL0gesLrfEMdgG58UCN1wJMgH4uRKmKU/U2Ap4W9hTpioN M722U8x7N6P1v6MqTAWCUaskdOp+ktNxFGxOlCE7BEo/EIaWbEt5RHwDePctScDLsi56+VI3TysR AgMBAAGjggHvMIIB6zAfBgNVHSMEGDAWgBSSYWuC4aKgqk/sZ/HCo/e0gADB7DAdBgNVHQ4EFgQU Yg3SsFWhMro4Abonbn1IX4JKj5QwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0l BBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9 MDsGDCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0 L0NQUzBdBgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9TSEEy NTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDBYBggrBgEFBQcwAoZMaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xp ZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDov L29jc3AuY29tb2RvY2EuY29tMBwGA1UdEQQVMBOBEXZlN2p0YkB2ZTdqdGIuY29tMA0GCSqGSIb3 DQEBCwUAA4IBAQCC26y+6/+SJoRQWepca+rB9eSSwaCAb8nNqA+00ZiOHb+6UbbV1xa7Z8wDIuEL 5UKbNtQ2NDArvzF9YI0xNafoV1AEmP/3+ljxQHSEI0U1p2h401sOx+nSjcwtTzACso1lw+I0oJYM JFITOIfZy8HgFpCipBrQAp9jMJ+KSKDX3xu/hzPosfdnXp7sV1KAjkFrAtR3AnQYfJ5W8QrsmC4N BbiAKoYWUSdklqn3v1neTG/+oOhcw7hcGZo+YmPyF9Cdy0gBtwSHPt8hluhg2TlzmqYfi0dVL/mU jCBNUY/BFH+MBqKF7sOIRMv8ALWceVaM/NEcBciKs4eR99A4cw9ZMYICtDCCArACAQEwgbEwgZsx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRANkyzLVrlzXAdnG6mf1Y FbowDQYJYIZIAWUDBAIBBQCggdQwLwYJKoZIhvcNAQkEMSIEIP0L13FT4Siln+YS0VJh+InmnmRo c9Qg2+PBg4yNiEo6MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE3 MDQyNTEzMTAwOVowaQYJKoZIhvcNAQkPMVwwWjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzALBgkqhkiG9w0BAQowCwYJKoZIhvcNAQEHMAsGCWCGSAFl AwQCATANBgkqhkiG9w0BAQEFAASCAQACyeQAptjWzawY/RDPOref4pNZChulDjOQSvmdzrq/XQfD 4lfWJX27Ax5oJEZpJe+Mu20sOWTWJufbnsALWNuw0cJLnlQhVwSWfTW6+dd3ZVmlq39zZ4wSgyu3 gEj3qAjWzJA05ZTTXXzpKIypwfh8pCdc1MMARcrJYMCy9gxsUux5ybCnKuD6B+HBWdDVFOW3QPPh 1lJceMPuU9uM9NykYwfA2v3l6FPw9N+qvkPOTENFIPTdKeHdFk0wiOHlklP6MgOGlfUQbTBxjYYI 84g8oaY9LHflMctIajL/asOZlM7uyc3mJIBR1hi2VuMvrkVdWYdnpdKBu7VvSSIhzOT1 --94eb2c06569477b940054dfd71b5-- From nobody Tue Apr 25 07:40:30 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E8B2131B89 for ; Tue, 25 Apr 2017 07:40:29 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6bgcIEnpKl7Y for ; Tue, 25 Apr 2017 07:40:27 -0700 (PDT) Received: from mail-pg0-x236.google.com (mail-pg0-x236.google.com [IPv6:2607:f8b0:400e:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C531131BA1 for ; Tue, 25 Apr 2017 07:37:42 -0700 (PDT) Received: by mail-pg0-x236.google.com with SMTP id g2so29542029pge.3 for ; Tue, 25 Apr 2017 07:37:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DH2soQi4fuDGXBL3W++U3QyXeaaPmVpB0Lclqnf0/w8=; b=NKA7o4eOCl8VFg5zV/zgaDm5UONGb0A3esDYdzSZ4hv08dNcEyZ77Mf4VX/+w/oX62 t/LaYRvyUYvwkOZyPmtoao7r79F8Vu/nd6ybJailcchJf3ySTLp/1dFHf5dJfUgXr24A QU2CC3oBYpt1qiWIDtOe6S3nZn00eOcAQw/CpQlhvG2azKpXI0V5LMaQEfs8mQH+Ss0F n7za0GnbZIg9UNqzQ8k1tknQAiDl2TPI49bCeGLYd7DAOYYPsnsnX1B1pm+fcT2LFuzK WrKeSCxEt0GXHIUiwAYteTfDAImzSScz8yIEDu8DQ7j4uz2KIRSY0FHd/0b/SOuwP+Od gUjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=DH2soQi4fuDGXBL3W++U3QyXeaaPmVpB0Lclqnf0/w8=; b=OYnzxcu2GaJZyn7O1UOFCafgnNZJtz/cFO37gCEswaDpVQ4pvpYjJzVbeqCFpKce8C SgfXWNagAv6bSOqpZa5uvmnhFgDE0o/xa65ymevsgdDUFPDX9uNs6TXe2mRT8yd0CR6V pBuK/aR+kNifzBLDRJ8VsgW9jauBKDAlWDGL+AMHK1VQa5N+vEiCifmZEWYIPff+374K mj0D+gg1zyC7JPAWDgJaUm55DMhbeyDt8le/6qPOEW7B3/jtqKPAXfuNGZHdQnCiqFLg Sq+uIsLisPnEi/L5ISbH+saVhURuI5bCUKNdFZNB4JEFpO0EnYnQDv4rCvUuvOcAlv+s eqag== X-Gm-Message-State: AN3rC/77DEwbvpMLKcblxlAmzuYWwkQxKbc8yF14uxilVV/Pdehsd6Hd 3Ai8mH2XErx5Exin8sdGBqr1359k1g== X-Received: by 10.84.194.165 with SMTP id h34mr3371449pld.129.1493131062093; Tue, 25 Apr 2017 07:37:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.185.143 with HTTP; Tue, 25 Apr 2017 07:37:01 -0700 (PDT) In-Reply-To: <48ED0D2A-37C6-4EDB-9570-CF47C4A851DE@ve7jtb.com> References: <48ED0D2A-37C6-4EDB-9570-CF47C4A851DE@ve7jtb.com> From: Kathleen Moriarty Date: Tue, 25 Apr 2017 10:37:01 -0400 Message-ID: To: John Bradley Cc: "oauth@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-native-apps X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 14:40:29 -0000 Hi, On Tue, Apr 25, 2017 at 9:09 AM, John Bradley wrote: > Thanks Kathleen, > > William and I will address these shortly. > > We can take out the IANA section completely if you think it is better. No, I think it's fine. Let's see what happens. It could be helpful text for some readers, I was just pointing out that some questions may arise. > > In the current implementations on Android and iOS Universal Links/App Links and are only http or HTTPS schema URI making them URL. > > So while all URL are URI, we could be more specific if that is OK with the style police. I thought the URL term was currently discouraged.. You have it in a couple of places already, so consistency would be easier to argue if you felt it was needed in the places where it is already, hence my comment. I can't be sure what the URI style police will say, but consistency helps in most situations. If this is specific to an example, that's fine. If the general pattern could be a URI (not a URL), then just be sure that is clear in the text. Please let me know when it is ready and I'll start the IETF last call. Thanks, Kathleen > > John B. > > >> On Apr 24, 2017, at 10:47 PM, Kathleen Moriarty wrote: >> >> Hello, >> >> Thanks for taking the time to document this best practice and the >> implementations in the appendix. I have one comment and a few nits. >> >> Security Considerations: >> I think it would go a long way to organize these as ones that apply to >> this best practice and ones (8.1 and the example in 8.2) about >> alternate solutions. This could also be done through some added text, >> but making this clear would be helpful. Maybe moving 8.1 and 8.2 >> until after the rest of the sections would be enough and then clearly >> state the intent of this text. >> >> IANA Section: >> Just a note - you might get some questions about this, but i do think >> it's fine to leave that text, although unnecessary. >> >> Nits: >> Section 5, punctuation >> OLD: >> By applying the same principles from the web to native apps, we gain >> benefits seen on the web like the usability of a single sign-on >> session, and the security of a separate authentication context. >> NEW: >> By applying the same principles from the web to native apps, we gain >> benefits seen on the web, like the usability of a single sign-on >> session and the security of a separate authentication context. >> >> The document has text that says 'native app' in some places and 'app' >> in others, I assume these are used interchangeably? It seems that >> they are used interchangeably. >> >> >> Really nitty: >> Section 7.2, >> Since you are still in the example, did you mean URL in the following: >> >> Such claimed HTTPS URIs can be used as OAuth redirect URIs. >> Such claimed HTTPS URLs can be used as OAuth redirect URIs. >> >> And again in the last paragraph of this section. >> >> I'm only asking since you specify URL earlier in this section, so you >> were more specific for the example and then drop back to URI (which is >> correct, but wondering if you wanted to continue at the same level of >> specificity or if there was a reason to just say URI here. >> >> Section 8.11 >> s/uri/URI/ >> >> >> -- >> >> Best regards, >> Kathleen >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > -- Best regards, Kathleen From nobody Tue Apr 25 12:45:28 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6521A1316D3 for ; Tue, 25 Apr 2017 12:45:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=erdtman-se.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GSioVOKzHnUb for ; Tue, 25 Apr 2017 12:45:23 -0700 (PDT) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::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 795B81317A4 for ; Tue, 25 Apr 2017 12:45:22 -0700 (PDT) Received: by mail-oi0-x22c.google.com with SMTP id y11so152535910oie.0 for ; Tue, 25 Apr 2017 12:45:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=erdtman-se.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=N8jJ8hPXWXf+lPbdNGbjr68QmCn4JCGTgLyn7yrHdIk=; b=TjxN6cJD85zuDzF8oyuchn+8HShL+Vo4yIH3Z6oZI9cNR1eK/3w1+Zkl4r8hn+Bz0J ZHSSyJKXYfMdmodSZg+qPC2rebMZfZLt6fjLtHgmfWf3mpwLqCy+46acqnadbFu+eoAm nrORiJQZk01sFGcjiabltx+7htdxSKZI2EWfkaKlmGrCp/UQKWpsrPaPWhVf1YPP0Z8N GNx4MdsGWXt8F+VuI28NATrttxYd2KgUxA+v1yJU/Tu2QmvMfe2k4nh+FRXhKjh4g3A6 MemTL9PLRrYwWsjQ8goFE2LtIls3pz/4DSSGHhznKY59oW6HjjV5lank0nqRL/Fd1b4L tkOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=N8jJ8hPXWXf+lPbdNGbjr68QmCn4JCGTgLyn7yrHdIk=; b=jYUR+ak2gRo/TaLNb9hdHcJDTvF0MxNqT85Xq/0lEXXjU+RycXO8PlAiqRnRVf9a3Y IDgVKeWJcNR72+j4uyjYVJ9AYUYZjJpnjiGR+MCnUrZd1LTeUGXTl8yvRpfLSJDcsv8q lSTGfGsRGZ0ua+V2886SeGs7RNKeJHrm2S5RTl/cl4Gd3w8wo4qWlCi4AI6PpP04mBeO SDWO/qwlCWyXDk86kGn3X5wX1YmAYd32F++0EE99VXjbwDEcd73CXkx5CQT9oOqBJxRV qT6DqNaGIjYtlQdCuOpi1BIYJlGjHE/2P7u5vIgKI5jxyKcHOPJ76Khj2uSDZy5NRZpV vQzQ== X-Gm-Message-State: AN3rC/4TFdnvRSsmYzwXxuDo77tgyW2QY8WeUqlz/G4qLj3R48rbNcpa z0j7Fp+C6zL4v9LWrEQ0yUHDxNDlFg== X-Received: by 10.157.44.137 with SMTP id p9mr11764831otb.252.1493149522180; Tue, 25 Apr 2017 12:45:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.8.34 with HTTP; Tue, 25 Apr 2017 12:45:21 -0700 (PDT) In-Reply-To: References: <95776354-79e3-caa7-ba60-84cfec7f899f@gmx.net> From: Samuel Erdtman Date: Tue, 25 Apr 2017 21:45:21 +0200 Message-ID: To: William Denniss Cc: Torsten Lodderstedt , oauth Content-Type: multipart/alternative; boundary=001a113de872dde3eb054e02f6ee Archived-At: Subject: Re: [OAUTH-WG] Call for Adoption: Mutual TLS Profiles for OAuth Clients X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 19:45:26 -0000 --001a113de872dde3eb054e02f6ee Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 for adoption On Mon, Apr 24, 2017 at 9:02 AM, William Denniss wrote: > I support the adoption of this draft by the working group. > > > On Sun, Apr 23, 2017 at 9:11 AM, Torsten Lodderstedt < > torsten@lodderstedt.net> wrote: > >> +1 for adoption >> >> Am 21.04.2017 um 21:43 schrieb Nat Sakimura : >> >> +1 for adoption >> >> On Apr 21, 2017 9:32 PM, "Dave Tonge" >> wrote: >> >>> I support adoption of draft-campbell-oauth-mtls >>> >>> As previously mentioned this spec will be very useful for Europe where >>> there is legislation requiring the use of certificate-based authenticat= ion >>> and many financial groups and institutions are considering OAuth2. >>> >>> The UK Open Banking Implementation Entity has a strong interest in usin= g >>> this spec. >>> >>> Dave >>> >>> On 20 April 2017 at 17:32, Hannes Tschofenig >>> wrote: >>> >>>> Hi all, >>>> >>>> based on the strong support for this document at the Chicago IETF >>>> meeting we are issuing a call for adoption of the "Mutual TLS Profiles >>>> for OAuth Clients" document, see >>>> https://tools.ietf.org/html/draft-campbell-oauth-mtls-01 >>>> >>>> Please let us know by May 4th whether you accept / object to the >>>> adoption of this document as a starting point for work in the OAuth >>>> working group. >>>> >>>> Ciao >>>> Hannes & Rifaat >>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>> >>> >>> -- >>> Dave Tonge >>> CTO >>> [image: Moneyhub Enterprise] >>> >>> 10 Temple Back, Bristol, BS1 6FL >>> t: +44 (0)117 280 5120 <+44%20117%20280%205120> >>> >>> Moneyhub Enterprise is a trading style of Momentum Financial Technology >>> Limited which is authorised and regulated by the Financial Conduct >>> Authority ("FCA"). Momentum Financial Technology is entered on the >>> Financial Services Register (FRN 561538) at fca.org.uk/register. >>> Momentum Financial Technology is registered in England & Wales, company >>> registration number 06909772 =C2=A9 . Momentum Financial Technology Lim= ited >>> 2016. DISCLAIMER: This email (including any attachments) is subject to >>> copyright, and the information in it is confidential. Use of this email= or >>> of any information in it other than by the addressee is unauthorised an= d >>> unlawful. Whilst reasonable efforts are made to ensure that any attachm= ents >>> are virus-free, it is the recipient's sole responsibility to scan all >>> attachments for viruses. All calls and emails to and from this company = may >>> be monitored and recorded for legitimate purposes relating to this >>> company's business. Any opinions expressed in this email (or in any >>> attachments) are those of the author and do not necessarily represent t= he >>> opinions of Momentum Financial Technology Limited or of any other group >>> company. >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --001a113de872dde3eb054e02f6ee Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1 for adoption

On Mon, Apr 24, 2017 at 9:02 AM, William Denniss <w= denniss@google.com> wrote:
=
I support the adoption of= this draft by the working group.


On Sun, Apr 23, 2017 at 9= :11 AM, Torsten Lodderstedt <torsten@lodderstedt.net> = wrote:
+1 for adoption

Am 21.04.2017 um 21:4= 3 schrieb Nat Sakimura <sakimura@gmail.com>:

+1 for adoption

On Apr 21, 2017 9:32 PM, "Dave Tonge" <= dave.tonge= @momentumft.co.uk> wrote:
I support adoption of draft-campbell-oauth-mt= ls

As previously mentioned this spec will be= very useful for Europe where there is legislation requiring the use of cer= tificate-based authentication and many financial groups and institutions ar= e considering OAuth2.
=C2=A0
The UK Open Banking Impl= ementation Entity=C2=A0has a strong interest in using this spec.

Dave

On 20 April 2017 at 17:32, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
Hi all,

based on the strong support for this document at the Chicago IETF
meeting we are issuing a call for adoption of the "Mutual TLS Profiles=
for OAuth Clients" document, see
https://tools.ietf.org/html/draft-campb= ell-oauth-mtls-01

Please let us know by May 4th whether you accept / object to the
adoption of this document as a starting point for work in the OAuth
working group.

Ciao
Hannes & Rifaat


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




--
= Dave Tonge
CTO
=
3D"Moneyh=
=
10 Temple Back, Bristol, BS1 6FL
t:=C2=A0+44 (0)117 280 5120

Moneyhub Ent= erprise is a trading style of Momentum Financial Technology Limited which i= s authorised and regulated by the Financial Conduct Authority ("FCA&qu= ot;).=C2=A0Momentum Financial Technology is entered on the Financial Servic= es Register=C2=A0(FRN=C2=A0561538) at fca.org.uk/register. Momentum F= inancial Technology is registered in England & Wales, company registrat= ion number=C2=A006909772=C2=A0=C2=A9=C2=A0.=C2=A0Momentum Financial Technology Limite= d 2016.=C2=A0DISCLAIMER: This email (including any attachm= ents) is subject to copyright, and the information in it is confidential. U= se of this email or of any information in it other than by the addressee is= unauthorised and unlawful. Whilst reasonable efforts are made to ensure th= at any attachments are virus-free, it is the recipient's sole responsib= ility to scan all attachments for viruses. All calls and emails to and from= this company may be monitored and recorded for legitimate purposes relatin= g to this company's business. Any opinions expressed in this email (or = in any attachments) are those of the author and do not necessarily represen= t the opinions of Momentum Financial Technology Limited or of any other gro= up company.

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

_______________________________________________
OAuth mailing list<= br>OAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth


_______________________________= ________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



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


--001a113de872dde3eb054e02f6ee-- From nobody Wed Apr 26 14:45:07 2017 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9611212EB55; Wed, 26 Apr 2017 14:44:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149324309858.3036.10468366092291499731@ietfa.amsl.com> Date: Wed, 26 Apr 2017 14:44:58 -0700 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-native-apps-10.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 21:44:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol of the IETF. Title : OAuth 2.0 for Native Apps Authors : William Denniss John Bradley Filename : draft-ietf-oauth-native-apps-10.txt Pages : 19 Date : 2017-04-26 Abstract: OAuth 2.0 authorization requests from native apps should only be made through external user-agents, primarily the user's browser. This specification details the security and usability reasons why this is the case, and how native apps and authorization servers can implement this best practice. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-native-apps/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-native-apps-10 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-native-apps-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-native-apps-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Apr 26 14:51:20 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E528128B91 for ; Wed, 26 Apr 2017 14:51:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xgk6cw25ox-X for ; Wed, 26 Apr 2017 14:51:17 -0700 (PDT) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::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 B41BB12709D for ; Wed, 26 Apr 2017 14:51:17 -0700 (PDT) Received: by mail-io0-x231.google.com with SMTP id r16so11655710ioi.2 for ; Wed, 26 Apr 2017 14:51:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RNaKdhp4tjMUJv71ArKpAYf4EowaJM18DXFyvBHdqNQ=; b=dXLccAOZnHG4VQQZ/vnFPCw1UxQfed/xilcuOsZjPbEFI/jX8cFvHoODR8HnaWtxgg W2g3vjaizUNl8AyRZ5Ocy12SmghNXpvWDmdCZJoRGA/uVvZFXiAlgwujZGLlbgiSAvel 6ao981qx9xwV2HtFWM4PZA2yO4uqhpPYquEvZcDgAKb1Y+TIQrdhjK1wzcPH9lPtOnAY PcQtLryiGrnmB2dRW+frUm0KSgD/VA00dTA9y+kwvKyRJIjHnjofJ8oVYhVrPo0IyYrX Uhdtnz7TjSStmS2pdf/+wunOYnMMxUtqLaCfVHVJ2R40DOwsA5bl1OBuQRcg+K2CKuMR CScQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=RNaKdhp4tjMUJv71ArKpAYf4EowaJM18DXFyvBHdqNQ=; b=LP/F0lt9AGCvIc8x9hxr2VjOF/fy/IdlFBbT/P8HNBQfE1NLmmfw7VlHFn2EHYX5GP MNO9RQxFLiq8d4eH431AG12N6pPpy9o1Io1/ran2A0U0vUj20oH9xnZpqn5BhF4OTOfX jXuTE0pQsdn2Vf+x2JfDixm2Lx13v+3bCU/9o5WvnOBFuxBxGngErLMOxp8q0xUVVCsV m8pxt2GdQV3GMvF4gKZNQLmWie5yX2MU4mVySYsidFb0fKhEGXoYV74yyPZZDe/q7LNO 24y51HdD0tPGUX2P2xhzvyAWeTkkBdwBSHTThFndFv0H2RwsPsYnj0VL3GQrl2SvxJJ3 x9Pw== X-Gm-Message-State: AN3rC/58zbWV7D7FVnk7r9KbywwnPBVFRn4NisRiRA0n1/IkloOJvAyq swSR/i/MkFmQ4RdXq4/8Wd27DX3oSZzJ X-Received: by 10.107.6.147 with SMTP id f19mr1985465ioi.53.1493243476629; Wed, 26 Apr 2017 14:51:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.156.210 with HTTP; Wed, 26 Apr 2017 14:50:56 -0700 (PDT) In-Reply-To: References: From: William Denniss Date: Wed, 26 Apr 2017 14:50:56 -0700 Message-ID: To: Kathleen Moriarty Cc: "oauth@ietf.org" Content-Type: multipart/alternative; boundary=001a113f9bb6fd7008054e18d6b2 Archived-At: Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-native-apps X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 21:51:19 -0000 --001a113f9bb6fd7008054e18d6b2 Content-Type: text/plain; charset=UTF-8 Thank you for your review Kathleen. Version 10 which addresses your comments is out: https://tools.ietf.org/html/draft-ietf-oauth-native-apps-10 Replies inline: On Mon, Apr 24, 2017 at 6:47 PM, Kathleen Moriarty < kathleen.moriarty.ietf@gmail.com> wrote: > Hello, > > Thanks for taking the time to document this best practice and the > implementations in the appendix. I have one comment and a few nits. > > Security Considerations: > I think it would go a long way to organize these as ones that apply to > this best practice and ones (8.1 and the example in 8.2) about > alternate solutions. This could also be done through some added text, > but making this clear would be helpful. Maybe moving 8.1 and 8.2 > until after the rest of the sections would be enough and then clearly > state the intent of this text. Good idea, I think that will help with the readability a lot. I have moved the "Embedded User-Agent" section to the end, and clarified the purpose. The reason it's included at all, is that OAuth itself documents two ways to do native OAuth. This document recommends only one of those ways, and I thought that detailing why the other way is no longer best-practice would be helpful to readers. IANA Section: > Just a note - you might get some questions about this, but i do think > it's fine to leave that text, although unnecessary. > > I think I may have mis-read https://tools.ietf.org/html/rfc5226#section-6.1. There is an example of a document that has no IANA actions but still provides a justification for why that is the case, but in that example it uses a non-IANA registry unlike this BCP. In our case, we are definitely operating in an IANA-controlled namespace, but using a private section of the namespace designed for that purpose. The intent was to point out that we are following IANA guidelines correctly. Happy to remove it (or indicate that it should be removed during publication) if it seems superfluous. For now, in the latest update I have clearly stated "This document has no IANA actions.", but retained the discussion. > Nits: > Section 5, punctuation > OLD: > By applying the same principles from the web to native apps, we gain > benefits seen on the web like the usability of a single sign-on > session, and the security of a separate authentication context. > NEW: > By applying the same principles from the web to native apps, we gain > benefits seen on the web, like the usability of a single sign-on > session and the security of a separate authentication context. > Fixed. > The document has text that says 'native app' in some places and 'app' > in others, I assume these are used interchangeably? It seems that > they are used interchangeably. > Yes, they are. In the definition section, "app" is defined as "shorthand for native app". Is that OK, or should I revise? > Really nitty: > Section 7.2, > Since you are still in the example, did you mean URL in the following: > > Such claimed HTTPS URIs can be used as OAuth redirect URIs. > Such claimed HTTPS URLs can be used as OAuth redirect URIs. > I have migrated to use URI exclusively, other than 2 references to URL where I'm referring to platform-specific naming / colloquialisms. I also changed instances of "custom URI scheme" to "private-use URI scheme", the latter being the terminology used by RFC7595. And again in the last paragraph of this section. > > I'm only asking since you specify URL earlier in this section, so you > were more specific for the example and then drop back to URI (which is > correct, but wondering if you wanted to continue at the same level of > specificity or if there was a reason to just say URI here. > I believe this is addressed now. Section 8.11 > s/uri/URI/ > > Fixed. Best, William > > -- > > Best regards, > Kathleen > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --001a113f9bb6fd7008054e18d6b2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thank you for your review Kathl= een.

V= ersion 10 which addresses your comments is out:=C2=A0https://tools.ietf.org/ht= ml/draft-ietf-oauth-native-apps-10

=
Replies inline:

On Mon, Apr 24, 2017 at 6:47 PM, Kathl= een Moriarty <kathleen.moriarty.ietf@gmail.com>= wrote:
Hello,<= br>
Thanks for taking the time to document this best practice and the
implementations in the appendix. I have one comment and a few nits.

Security Considerations:
I think it would go a long way to organize these as ones that apply to
this best practice and ones (8.1 and the example in 8.2) about
alternate solutions.=C2=A0 This could also be done through some added text,=
but making this clear would be helpful.=C2=A0 Maybe moving 8.1 and 8.2
until after the rest of the sections would be enough and then clearly
state the intent of this text.

Good idea, I= think that will help with the readability a lot. I have moved the "Em= bedded User-Agent" section to the end, and clarified the purpose.

The reason it's included at all, is that OAuth its= elf documents two ways to do native OAuth. This document recommends only on= e of those ways, and I thought that detailing why the other way is no longe= r best-practice would be helpful to readers.=C2=A0

IANA Section:
Just a note - you might get some questions about this, but i do think
it's fine to leave that text, although unnecessary.


I think I may have mis-read=C2=A0ht= tps://tools.ietf.org/html/rfc5226#section-6.1. There is an example= of a document that has no IANA actions but still provides a justification = for why that is the case, but in that example it uses a non-IANA registry u= nlike this BCP.

In our case, we are definitely ope= rating in an IANA-controlled namespace, but using a private section of the = namespace designed for that purpose.=C2=A0 The intent was to point out that= we are following IANA guidelines correctly.=C2=A0 Happy to remove it (or i= ndicate that it should be removed during publication) if it seems superfluo= us.

For now, in the latest update I have clearly s= tated "This document has no IANA actions.", but retained the disc= ussion.
=C2=A0
Nits:
Section 5, punctuation
OLD:
=C2=A0 =C2=A0By applying the same principles from the web to native apps, w= e gain
=C2=A0 =C2=A0benefits seen on the web like the usability of a single sign-o= n
=C2=A0 =C2=A0session, and the security of a separate authentication context= .
NEW:
=C2=A0 =C2=A0By applying the same principles from the web to native apps, w= e gain
=C2=A0 =C2=A0benefits seen on the web, like the usability of a single sign-= on
=C2=A0 =C2=A0session and the security of a separate authentication context.=

Fixed.
=C2=A0
The document has text that says 'native app' in some places and = 9;app'
in others, I assume these are used interchangeably?=C2=A0 It seems that
they are used interchangeably.

Yes, the= y are. In the definition section, "app" is defined as "short= hand for native app". Is that OK, or should I revise?
=C2=A0=
Really nitty:
Section 7.2,
Since you are still in the example, did you mean URL in the following:

Such claimed HTTPS URIs can be used as OAuth redirect URIs.
Such claimed HTTPS URLs can be used as OAuth redirect URIs.

I have migrated to use URI exclusively, other than 2 r= eferences to URL where I'm referring to platform-specific naming /=C2= =A0colloquialisms.

I also changed instances of &qu= ot;custom URI scheme" to "private-use URI scheme", the latte= r being the terminology used by RFC7595.

And again in the last paragraph of this section.

I'm only asking since you specify URL earlier in this section, so you were more specific for the example and then drop back to URI (which is
correct, but wondering if you wanted to continue at the same level of
specificity or if there was a reason to just say URI here.
=

I believe this is addressed now.

Section 8.11
s/uri/URI/


Fixed.

Best,
William
= =C2=A0

--

Best regards,
Kathleen

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

--001a113f9bb6fd7008054e18d6b2-- From nobody Wed Apr 26 14:53:00 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DD2812EB24 for ; Wed, 26 Apr 2017 14:52:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.608 X-Spam-Level: X-Spam-Status: No, score=-2.608 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, HTML_OBFUSCATE_10_20=0.093, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VXA3oMJIUMLL for ; Wed, 26 Apr 2017 14:52:56 -0700 (PDT) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::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 A13B5128B8F for ; Wed, 26 Apr 2017 14:52:56 -0700 (PDT) Received: by mail-it0-x22c.google.com with SMTP id f187so1336924ite.1 for ; Wed, 26 Apr 2017 14:52:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=NSoZGIm/khZApf+7xflTaY+9UPE8XXga1Z2sCe5nhR8=; b=Vgm8GxoiAfNzuzhc8w26gN4+yKYX/yifaLiHK75sb9Esj+KSG47vi/RXAapEdcDgKr Z+XvCv4yic4jeEPOQBLGf/jpGqZ1NEKVc4Sz41xzyHzKtgfJNMIuFVkcqmUCOM7yGd86 exZTBgM+fxyfIAA826qgujeaWkdruXVpjFBNEllq5xiPSm+PiEcVTJDdV7P08BdDeuBB azmY7CoeVXQe3xqiH36MBw9XNge13ZyYrWkknsCUisUXmCbKvzH63HeJuPxsqzavdOat 1EHYofkU6/OQ7lMy117DvfWyEuGbY5KUGa9m2iKlcfwWMJKfFHzVch6N8tq+i0f6pNp7 f0+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=NSoZGIm/khZApf+7xflTaY+9UPE8XXga1Z2sCe5nhR8=; b=nrNOAXzY4BG0mZQrMWvnmaohCU4lqyBZreoV2I3vYlECyhFyZiNCEnVyR2eCeBN42S Vh2RDceirVacGz8Eo4o6Xvld9Gv3aRrYKQjrI5LxHWZWAgsrz0fm5DS5VwEJ1AIsxGqG WvhZId1VVuqs5oyvijACeNk0uMhDeOquOtmZOOFD09GuftwgAlovmZwkfbZ5yy7znMKj lk7sjysM9BrzYpCE4wt9BoA6XEO+E4QiHImKgdjOjWNEPfwUuJWzQ6mqVC0FKxvu/xN5 ah/gN21mWTwuWFc93LqT1wGcUWCHABlW/KM8kLpMEshEMniinIrADg1AjJPsJt2d12vC 4Sfg== X-Gm-Message-State: AN3rC/4N8aXatwOG3yPx3SFuHscthypXusyoS0gx4tXveUoykZOqAd1E mwNBreKG/GKbGohfFL5/QVeIOBOsi6m9ZFPxFA== X-Received: by 10.36.253.8 with SMTP id m8mr54736ith.101.1493243575501; Wed, 26 Apr 2017 14:52:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.156.210 with HTTP; Wed, 26 Apr 2017 14:52:35 -0700 (PDT) In-Reply-To: <149324309858.3036.10468366092291499731@ietfa.amsl.com> References: <149324309858.3036.10468366092291499731@ietfa.amsl.com> From: William Denniss Date: Wed, 26 Apr 2017 14:52:35 -0700 Message-ID: To: "oauth@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c030f2ce200b4054e18dc49 Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-native-apps-10.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 21:52:58 -0000 --94eb2c030f2ce200b4054e18dc49 Content-Type: text/plain; charset=UTF-8 This version addresses comments from Kathleen Moriarty's AD review. The changes are editorial in nature. On Wed, Apr 26, 2017 at 2:44 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Web Authorization Protocol of the IETF. > > Title : OAuth 2.0 for Native Apps > Authors : William Denniss > John Bradley > Filename : draft-ietf-oauth-native-apps-10.txt > Pages : 19 > Date : 2017-04-26 > > Abstract: > OAuth 2.0 authorization requests from native apps should only be made > through external user-agents, primarily the user's browser. This > specification details the security and usability reasons why this is > the case, and how native apps and authorization servers can implement > this best practice. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-oauth-native-apps/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-oauth-native-apps-10 > https://datatracker.ietf.org/doc/html/draft-ietf-oauth-native-apps-10 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-native-apps-10 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --94eb2c030f2ce200b4054e18dc49 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This version addresses comments from Kathleen Moriarty'= ;s AD review.

The changes are editorial in nature.

On Wed, Apr 26, 201= 7 at 2:44 PM, <internet-drafts@ietf.org> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Web Authorization Protocol of the IETF.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= OAuth 2.0 for Native Apps
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Will= iam Denniss
=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 John Bradley
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-oauth-native-apps-10.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 19
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2017-04-26

Abstract:
=C2=A0 =C2=A0OAuth 2.0 authorization requests from native apps should only = be made
=C2=A0 =C2=A0through external user-agents, primarily the user's browser= .=C2=A0 This
=C2=A0 =C2=A0specification details the security and usability reasons why t= his is
=C2=A0 =C2=A0the case, and how native apps and authorization servers can im= plement
=C2=A0 =C2=A0this best practice.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/= draft-ietf-oauth-native-apps/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ie= tf-oauth-native-apps-10
https://datatracker.ietf.org/d<= wbr>oc/html/draft-ietf-oauth-native-apps-10

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-native-apps-10


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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

--94eb2c030f2ce200b4054e18dc49-- From nobody Thu Apr 27 22:55:10 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10767129C34 for ; Thu, 27 Apr 2017 22:55:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, TVD_SPACE_RATIO=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TlAG4Vl0EpeC for ; Thu, 27 Apr 2017 22:55:07 -0700 (PDT) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29E43129C12 for ; Thu, 27 Apr 2017 22:52:25 -0700 (PDT) Received: by mail-io0-x22a.google.com with SMTP id k87so50257684ioi.0 for ; Thu, 27 Apr 2017 22:52:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=o5UG24dDWmKYKgJ2yPKhggLB0DmEhMt4VEjDsVl8D2Q=; b=NUrvUYxDtSUeL3W4MSU0tcFOgOTB+SCmaX838h2M2BCY4RPmT8HbxtKvAOI23qI0P7 faF4tfrgtQsrbuz4V0O5nl+bq2xR2t5WtTwkSVEPDMm5tWvp6nHbxukBGYK9casITOAF K7cSV9P+jG45UEr6H0XbZEmhSFi1TG4mv6Cg9yT3PZ6ZUSSZmyPLoliSBPshwzI1DB4Q ov3WskVFS83URZmAgbPZ9Gyc2R6TBT+qf+12IgLvuhHN2IaeBuXt4KsKqNkbdqc8OOIB 6f9p+SMtfLTumCevOwQgLnkhgcHYbxEkxgRSA8GX+gR2/NZts7VZV1jtkqOEEez35q98 RPug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=o5UG24dDWmKYKgJ2yPKhggLB0DmEhMt4VEjDsVl8D2Q=; b=S8OnKqOqoKPw4fAWSrSyx4xhoRkv81f6RTFYJGrBXMadQr4q/pAw44ODT6lOG6GIr5 1UfKq/PPudpsL/UQo1Q73fhZOBc5B8jDXpPc4s2ky2M/HLlqw1VoGGlSc6ebkwAL56sr uPbTiucF2ZH2DSSlre5DDIQs8g+OigQ2yoi9PCMAHkXuvqxLC5G/hxg4Yvwu5plu48rq YuSSwxF7WJbOAjGRomotyHH8IgC0GKKanjpj/kegHoyixvksc3x9BVb0TkJwztvNgk/0 e97vmDYb85r97G6WTkRGiJhKB19EkMC/XrJIiCxFtpeMGHnlSDrPYNNgUGBcSN8JU+Rj ZfjQ== X-Gm-Message-State: AN3rC/6u/MUiBWOMQlf0F5BtL0L3PIIrxlUvNdYzmiCfODlFOrF0sOLe 4Trz9Mx9Meois68rsieGVFbrjDSAWxMByVI= X-Received: by 10.157.66.29 with SMTP id q29mr4003672ote.2.1493358744331; Thu, 27 Apr 2017 22:52:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.107.6 with HTTP; Thu, 27 Apr 2017 22:52:24 -0700 (PDT) From: yan tan Date: Thu, 27 Apr 2017 22:52:24 -0700 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary=f403043794c87a6bdd054e33ad20 Archived-At: Subject: [OAUTH-WG] (no subject) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2017 05:55:09 -0000 --f403043794c87a6bdd054e33ad20 Content-Type: text/plain; charset=UTF-8 OAuth --f403043794c87a6bdd054e33ad20 Content-Type: text/html; charset=UTF-8
OAuth
--f403043794c87a6bdd054e33ad20-- From nobody Fri Apr 28 13:42:11 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73B181293FB for ; Fri, 28 Apr 2017 13:42:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KVrKaoB7tylX for ; Fri, 28 Apr 2017 13:42:04 -0700 (PDT) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::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 ABC91129BBF for ; Fri, 28 Apr 2017 13:39:42 -0700 (PDT) Received: by mail-it0-x233.google.com with SMTP id 70so49347586ita.0 for ; Fri, 28 Apr 2017 13:39:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=PY4B2rToOhiczJwUvSC08tz6mafqQs2pV7avs58djng=; b=L8HqNCRcb6xUxszJndQO2ZnmRAJ6II8CCqfA9yG1mgPSTgRRoyZ8cl0TNh0Tdq7eGQ k07AL232cFO2AevKOQXMtomR2hurBVY9d8tLPV2fJWEBzmThE30R6c+RknwbbO8gsff9 FPwvZ/TpEn+LoHn7JrObymillrioJyiTOYn40cZV+s2KIPQ4AOTmXIez70UDZmHIwXz1 BxHTvJxahCfAeEdQITnGx+Hl6vQ7nszEJ6LWvZ4phGGGGljnkkj2xb52TdwqEXqC5WfR dNx9SH4ypXJUPb0QnyCnVPuawse0TqTBLWYvGVaW321cS4U2aCl9qn9LzznyaVjdeW6Y 4ZiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=PY4B2rToOhiczJwUvSC08tz6mafqQs2pV7avs58djng=; b=HXcIx5lDepsmremH+xV7YYbrpXyaix6cSGGud0NYv4KGp2QEcTrGD14XI7QGr+1r6H hUvU2q6WCv5ZtbYr+uScJMh/NQVYyJwNMOIHntxmkKrE6cmP7rohDWypH4JzEAwkNSTp N9Y1VxSXggnZG3gn41MgImZ2M8WDxZZwRksfeaV218sspRt6d467QI+DUzU8DstuXpnw 2u3vneKK5FFOHweG2oPvWOeUzDTOj6j1/6xRdHBIjwPoj2kR2/YcZEW/WImFgqyZHyja 3yPLkUjv4KTqVXicBtWkpMi0KgUcdPbeVCnYoLXu2Z+1SeUklokt+ngega/ByepAVjUd GRKA== X-Gm-Message-State: AN3rC/502lzr2RT/52eH8wMauyCXu9eHvy46c9IWp+lHmuGtK5jRoUJl XEGr/uqbqKdqf0kOKeLGHqPAXJ1Tfb+4tBk= X-Received: by 10.36.230.5 with SMTP id e5mr12290553ith.101.1493411981497; Fri, 28 Apr 2017 13:39:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.156.72 with HTTP; Fri, 28 Apr 2017 13:39:20 -0700 (PDT) From: William Denniss Date: Fri, 28 Apr 2017 13:39:20 -0700 Message-ID: To: "oauth@ietf.org" , John Bradley , Hannes Tschofenig , Mike Jones Content-Type: multipart/alternative; boundary=94eb2c11c82ea98b52054e40126b Archived-At: Subject: [OAUTH-WG] OAuth 2.0 Device Flow: IETF98 Follow-up X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2017 20:42:08 -0000 --94eb2c11c82ea98b52054e40126b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks all who joined us in Chicago in person and remotely last month for the discussion on the device flow. [recording here , presentation starts at about 7min in]. The most contentious topic was addition of the user_code URI param extension (introduced in version 05, documented in Section 3.3 ). I'd like to close out that discussion with a decision soon so we can advance to a WG last call on the draft. To summarise my thoughts on the param: 1. It can be can be used to improve usability =E2=80=93 QR codes and NFC= can be used with this feature to create a more delightful user authorization experience. 2. It may increase the potential phishing risk (which we can document), as the user has less typing. This risk assessment is likely not one-size-fits-all, it may vary widely due to different the different potential applications of this standard. 3. The way it's worded makes it completely optional, leaving it up to the discretion of the authorization server on whether to offer the optimisation, allowing them to secure it as best they see it. 4. I do believe it is possible to design a secure user experiance that includes this optimization. I think on the balance, it's worthwhile feature to include, and one that benefits interop. The authorization server has complete control over whether to enable this feature =E2=80=93 as Justin pointed out in the meeti= ng, it degrades really nicely =E2=80=93 and should they enable it, they have contr= ol over the user experiance and can add whatever phishing mitigations their use-case warrants. Rarely is there a one-size-fits-all risk profile, use-cases of this flow range widely from mass-market TV apps to internal-only device bootstrapping by employees, so I don't think we should be overly prescriptive. Mitigating phishing is already something that is in the domain of the authorization server with OAuth generally, and I know that this is an extremely important consideration when designing user authorization flows. This spec will be no exception to that, with or without this optimization. That's my opinion. I'm keen to continue the discussion from Chicago and reach rough consensus so we can progress forward. Best, William --94eb2c11c82ea98b52054e40126b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks all who joined us in Chicago in person and remotely= last month for the discussion on the device flow. [recording= here, presentation starts at about 7min in].

The mo= st contentious topic was addition of the user_code URI param extension (int= roduced in version 05, documented in=C2=A0Section 3.3).
<= div>
I'd like to close out that discussion with a decisio= n soon so we can advance to a WG last call on the draft.

To summarise my thoughts on the param:
  1. It can be c= an be used to improve usability =E2=80=93 QR codes and NFC can be used with= this feature to create a more delightful user authorization experience.
  2. It may increase the potential phishing risk (which we can document), = as the user has less typing. This risk assessment is likely not one-size-fi= ts-all, it may vary widely due to different the different potential applica= tions of this standard.
  3. The way it's worded makes it completely= optional, leaving it up to the discretion of the authorization server on w= hether to offer the optimisation, allowing them to secure it as best they s= ee it.
  4. I do believe it is possible to design a secure user expe= riance that includes this optimization.
I think on the balanc= e, it's worthwhile feature to include, and one that benefits interop. T= he authorization server has complete control over whether to enable this fe= ature =E2=80=93 as Justin pointed out in the meeting, it degrades really ni= cely =E2=80=93 and should they enable it, they have control over the user e= xperiance and can add whatever phishing mitigations their use-case warrants= .=C2=A0 Rarely is there a one-size-fits-all risk profile, use-cases of this= flow range widely from mass-market TV apps to internal-only device bootstr= apping by employees, so I don't think we should be overly prescriptive.=

Mitigating phishing is already something that is = in the domain of the authorization server with OAuth generally, and I know = that this is an extremely important consideration when designing user autho= rization flows. This spec will be no exception to that, with or without thi= s optimization.

That's my opinion. I'= ;m keen to continue the discussion from Chicago and reach rough consensus s= o we can progress forward.

Best,
William
<= div>
--94eb2c11c82ea98b52054e40126b-- From nobody Fri Apr 28 15:03:35 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48C3D129473 for ; Fri, 28 Apr 2017 15:03:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rCXdQz8GedM2 for ; Fri, 28 Apr 2017 15:03:31 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0120.outbound.protection.outlook.com [104.47.40.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3CE6129BE6 for ; Fri, 28 Apr 2017 15:00:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Itp6bN+mEig/n9UPcLExByY387Kg5Gu8n9KChFVaLi4=; b=mWpeXbHNbxZSEVEXoOGnmaZ0gE7nc8HE8YlvWc9V310s0vsWAwk7qnBoK+XuHLbRQ+gZZwYX8/ZYYNae1RnZ9xCl9HrEipo55WaRamm6ladQ9AjW3sQ6fVdy9aNLwMasP+cnQXoMr8lY42odQDt8zYnmUYaAxNP0V6HHnPG7HrE= Received: from CY4PR21MB0504.namprd21.prod.outlook.com (10.172.122.14) by CY4PR21MB0502.namprd21.prod.outlook.com (10.172.122.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1075.0; Fri, 28 Apr 2017 22:00:41 +0000 Received: from CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) by CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) with mapi id 15.01.1075.005; Fri, 28 Apr 2017 22:00:41 +0000 From: Mike Jones To: William Denniss , "oauth@ietf.org" , John Bradley , Hannes Tschofenig Thread-Topic: OAuth 2.0 Device Flow: IETF98 Follow-up Thread-Index: AQHSwF+RTVKjJdH3N0ez9GThgKKoNqHbVOGQ Date: Fri, 28 Apr 2017 22:00:41 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Ref=https://api.informationprotection.azure.com/api/72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetBy=mbj@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2017-04-28T15:00:39.0253890-07:00; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General authentication-results: google.com; dkim=none (message not signed) header.d=none;google.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:2::7cb] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0502; 7:sDP70NPObdRLl77D6pQsvwlptV+0e8QzobD7+9ifAs0pCbq7sRNQt5pjL+jdDM6TaEv+3vSIrpGNuEEEa2iqAzePp+MqtryFaNS8zAGUcEaM1Zcqpp87XrHoMd7p5PU3GGCmwEiZg/MxwBqJj/e75+Crim1XaCCQoL4ite+qtN7fy4juecw1wvmPn52kepthFqyK/Kh8QVSpwBqrUHdFyPD1ohADDfkk5ivmsLnSVhR7yMFrEb+ipkrpyGd79y8awMKWmf6/kXQFUY0lxBhw1OdsZ1BPhX+DmqHVhW89DdfdLT41hMCD65yaP4mUIPD8NxfW44W2HVNmhfcbaLWn3DgK3JUxneOE/lSRLQPnDt8= x-ms-office365-filtering-correlation-id: 68f24911-c7e0-4633-f360-08d48e82031f x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:CY4PR21MB0502; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(278428928389397)(211936372134217)(100405760836317)(21748063052155)(248736688235697); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123562025)(20161123555025)(20161123564025)(6072148); SRVR:CY4PR21MB0502; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0502; x-forefront-prvs: 029174C036 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39840400002)(39410400002)(39450400003)(39850400002)(39860400002)(39400400002)(377454003)(6246003)(7906003)(53936002)(33656002)(76176999)(10090500001)(9686003)(6306002)(236005)(54896002)(81166006)(8676002)(99286003)(2906002)(606005)(54356999)(38730400002)(7736002)(122556002)(8936002)(6436002)(55016002)(50986999)(2900100001)(3280700002)(6506006)(77096006)(5660300001)(25786009)(53546009)(229853002)(7696004)(19609705001)(5005710100001)(2950100002)(189998001)(86612001)(74316002)(10290500003)(790700001)(102836003)(6116002)(2501003)(3660700001)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0502; H:CY4PR21MB0504.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB0504A4BA6BFB6351A64169A8F5130CY4PR21MB0504namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Apr 2017 22:00:41.2868 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0502 Archived-At: Subject: Re: [OAUTH-WG] OAuth 2.0 Device Flow: IETF98 Follow-up X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2017 22:03:34 -0000 --_000_CY4PR21MB0504A4BA6BFB6351A64169A8F5130CY4PR21MB0504namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB0aGluayB0aGUgc3BlYyBpcyBiZXR0ZXIgd2l0aCB0aGUgKG9wdGlvbmFsKSB1c2VyX2NvZGUg aW4gaXQuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAtLSBNaWtlDQoNCkZyb206IFdpbGxpYW0gRGVubmlzcyBbbWFpbHRvOndkZW5u aXNzQGdvb2dsZS5jb21dDQpTZW50OiBGcmlkYXksIEFwcmlsIDI4LCAyMDE3IDE6MzkgUE0NClRv OiBvYXV0aEBpZXRmLm9yZzsgSm9obiBCcmFkbGV5IDx2ZTdqdGJAdmU3anRiLmNvbT47IEhhbm5l cyBUc2Nob2ZlbmlnIDxoYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0PjsgTWlrZSBKb25lcyA8TWlj aGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPg0KU3ViamVjdDogT0F1dGggMi4wIERldmljZSBGbG93 OiBJRVRGOTggRm9sbG93LXVwDQoNClRoYW5rcyBhbGwgd2hvIGpvaW5lZCB1cyBpbiBDaGljYWdv IGluIHBlcnNvbiBhbmQgcmVtb3RlbHkgbGFzdCBtb250aCBmb3IgdGhlIGRpc2N1c3Npb24gb24g dGhlIGRldmljZSBmbG93LiBbcmVjb3JkaW5nIGhlcmU8aHR0cHM6Ly9wbGF5LmNvbmYubWVldGVj aG8uY29tL1BsYXlvdXQvP3Nlc3Npb249SUVURjk4LU9BVVRILTIwMTcwMzI3LTE3MTA+LCBwcmVz ZW50YXRpb24gc3RhcnRzIGF0IGFib3V0IDdtaW4gaW5dLg0KDQpUaGUgbW9zdCBjb250ZW50aW91 cyB0b3BpYyB3YXMgYWRkaXRpb24gb2YgdGhlIHVzZXJfY29kZSBVUkkgcGFyYW0gZXh0ZW5zaW9u IChpbnRyb2R1Y2VkIGluIHZlcnNpb24gMDUsIGRvY3VtZW50ZWQgaW4gU2VjdGlvbiAzLjM8aHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtZGV2aWNlLWZsb3ctMDUj c2VjdGlvbi0zLjM+KS4NCg0KSSdkIGxpa2UgdG8gY2xvc2Ugb3V0IHRoYXQgZGlzY3Vzc2lvbiB3 aXRoIGEgZGVjaXNpb24gc29vbiBzbyB3ZSBjYW4gYWR2YW5jZSB0byBhIFdHIGxhc3QgY2FsbCBv biB0aGUgZHJhZnQuDQoNClRvIHN1bW1hcmlzZSBteSB0aG91Z2h0cyBvbiB0aGUgcGFyYW06DQoN CiAgMS4gIEl0IGNhbiBiZSBjYW4gYmUgdXNlZCB0byBpbXByb3ZlIHVzYWJpbGl0eSDigJMgUVIg Y29kZXMgYW5kIE5GQyBjYW4gYmUgdXNlZCB3aXRoIHRoaXMgZmVhdHVyZSB0byBjcmVhdGUgYSBt b3JlIGRlbGlnaHRmdWwgdXNlciBhdXRob3JpemF0aW9uIGV4cGVyaWVuY2UuDQogIDIuICBJdCBt YXkgaW5jcmVhc2UgdGhlIHBvdGVudGlhbCBwaGlzaGluZyByaXNrICh3aGljaCB3ZSBjYW4gZG9j dW1lbnQpLCBhcyB0aGUgdXNlciBoYXMgbGVzcyB0eXBpbmcuIFRoaXMgcmlzayBhc3Nlc3NtZW50 IGlzIGxpa2VseSBub3Qgb25lLXNpemUtZml0cy1hbGwsIGl0IG1heSB2YXJ5IHdpZGVseSBkdWUg dG8gZGlmZmVyZW50IHRoZSBkaWZmZXJlbnQgcG90ZW50aWFsIGFwcGxpY2F0aW9ucyBvZiB0aGlz IHN0YW5kYXJkLg0KICAzLiAgVGhlIHdheSBpdCdzIHdvcmRlZCBtYWtlcyBpdCBjb21wbGV0ZWx5 IG9wdGlvbmFsLCBsZWF2aW5nIGl0IHVwIHRvIHRoZSBkaXNjcmV0aW9uIG9mIHRoZSBhdXRob3Jp emF0aW9uIHNlcnZlciBvbiB3aGV0aGVyIHRvIG9mZmVyIHRoZSBvcHRpbWlzYXRpb24sIGFsbG93 aW5nIHRoZW0gdG8gc2VjdXJlIGl0IGFzIGJlc3QgdGhleSBzZWUgaXQuDQogIDQuICBJIGRvIGJl bGlldmUgaXQgaXMgcG9zc2libGUgdG8gZGVzaWduIGEgc2VjdXJlIHVzZXIgZXhwZXJpYW5jZSB0 aGF0IGluY2x1ZGVzIHRoaXMgb3B0aW1pemF0aW9uLg0KSSB0aGluayBvbiB0aGUgYmFsYW5jZSwg aXQncyB3b3J0aHdoaWxlIGZlYXR1cmUgdG8gaW5jbHVkZSwgYW5kIG9uZSB0aGF0IGJlbmVmaXRz IGludGVyb3AuIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBoYXMgY29tcGxldGUgY29udHJvbCBv dmVyIHdoZXRoZXIgdG8gZW5hYmxlIHRoaXMgZmVhdHVyZSDigJMgYXMgSnVzdGluIHBvaW50ZWQg b3V0IGluIHRoZSBtZWV0aW5nLCBpdCBkZWdyYWRlcyByZWFsbHkgbmljZWx5IOKAkyBhbmQgc2hv dWxkIHRoZXkgZW5hYmxlIGl0LCB0aGV5IGhhdmUgY29udHJvbCBvdmVyIHRoZSB1c2VyIGV4cGVy aWFuY2UgYW5kIGNhbiBhZGQgd2hhdGV2ZXIgcGhpc2hpbmcgbWl0aWdhdGlvbnMgdGhlaXIgdXNl LWNhc2Ugd2FycmFudHMuICBSYXJlbHkgaXMgdGhlcmUgYSBvbmUtc2l6ZS1maXRzLWFsbCByaXNr IHByb2ZpbGUsIHVzZS1jYXNlcyBvZiB0aGlzIGZsb3cgcmFuZ2Ugd2lkZWx5IGZyb20gbWFzcy1t YXJrZXQgVFYgYXBwcyB0byBpbnRlcm5hbC1vbmx5IGRldmljZSBib290c3RyYXBwaW5nIGJ5IGVt cGxveWVlcywgc28gSSBkb24ndCB0aGluayB3ZSBzaG91bGQgYmUgb3Zlcmx5IHByZXNjcmlwdGl2 ZS4NCg0KTWl0aWdhdGluZyBwaGlzaGluZyBpcyBhbHJlYWR5IHNvbWV0aGluZyB0aGF0IGlzIGlu IHRoZSBkb21haW4gb2YgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIHdpdGggT0F1dGggZ2VuZXJh bGx5LCBhbmQgSSBrbm93IHRoYXQgdGhpcyBpcyBhbiBleHRyZW1lbHkgaW1wb3J0YW50IGNvbnNp ZGVyYXRpb24gd2hlbiBkZXNpZ25pbmcgdXNlciBhdXRob3JpemF0aW9uIGZsb3dzLiBUaGlzIHNw ZWMgd2lsbCBiZSBubyBleGNlcHRpb24gdG8gdGhhdCwgd2l0aCBvciB3aXRob3V0IHRoaXMgb3B0 aW1pemF0aW9uLg0KDQpUaGF0J3MgbXkgb3Bpbmlvbi4gSSdtIGtlZW4gdG8gY29udGludWUgdGhl IGRpc2N1c3Npb24gZnJvbSBDaGljYWdvIGFuZCByZWFjaCByb3VnaCBjb25zZW5zdXMgc28gd2Ug Y2FuIHByb2dyZXNzIGZvcndhcmQuDQpCZXN0LA0KV2lsbGlhbQ0KDQo= --_000_CY4PR21MB0504A4BA6BFB6351A64169A8F5130CY4PR21MB0504namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOiMwMDIwNjA7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBh Z2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBp biAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N Ci8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjIxNDAzMDEy MjI7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjc2OTA1NjYxMDt9DQpvbA0KCXttYXJnaW4tYm90 dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0i MTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEi IC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBs YW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3Jk U2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIw NjAiPkkgdGhpbmsgdGhlIHNwZWMgaXMgYmV0dGVyIHdpdGggdGhlIChvcHRpb25hbCkgdXNlcl9j b2RlIGluIGl0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFp bEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L2E+PC9wPg0KPHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbEVuZENvbXBv c2UiPjwvc3Bhbj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBXaWxsaWFtIERl bm5pc3MgW21haWx0bzp3ZGVubmlzc0Bnb29nbGUuY29tXSA8YnI+DQo8Yj5TZW50OjwvYj4gRnJp ZGF5LCBBcHJpbCAyOCwgMjAxNyAxOjM5IFBNPGJyPg0KPGI+VG86PC9iPiBvYXV0aEBpZXRmLm9y ZzsgSm9obiBCcmFkbGV5ICZsdDt2ZTdqdGJAdmU3anRiLmNvbSZndDs7IEhhbm5lcyBUc2Nob2Zl bmlnICZsdDtoYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0Jmd0OzsgTWlrZSBKb25lcyAmbHQ7TWlj aGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBPQXV0aCAy LjAgRGV2aWNlIEZsb3c6IElFVEY5OCBGb2xsb3ctdXA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlRoYW5rcyBhbGwgd2hvIGpvaW5lZCB1cyBpbiBDaGljYWdvIGluIHBlcnNvbiBhbmQg cmVtb3RlbHkgbGFzdCBtb250aCBmb3IgdGhlIGRpc2N1c3Npb24gb24gdGhlIGRldmljZSBmbG93 LiBbPGEgaHJlZj0iaHR0cHM6Ly9wbGF5LmNvbmYubWVldGVjaG8uY29tL1BsYXlvdXQvP3Nlc3Np b249SUVURjk4LU9BVVRILTIwMTcwMzI3LTE3MTAiPnJlY29yZGluZyBoZXJlPC9hPiwgcHJlc2Vu dGF0aW9uIHN0YXJ0cyBhdA0KIGFib3V0IDdtaW4gaW5dLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIG1vc3QgY29udGVudGlvdXMgdG9waWMgd2FzIGFk ZGl0aW9uIG9mIHRoZSB1c2VyX2NvZGUgVVJJIHBhcmFtIGV4dGVuc2lvbiAoaW50cm9kdWNlZCBp biB2ZXJzaW9uIDA1LCBkb2N1bWVudGVkIGluJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtZGV2aWNlLWZsb3ctMDUjc2VjdGlvbi0zLjMi PlNlY3Rpb24gMy4zPC9hPikuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkknZCBsaWtlIHRvIGNsb3NlIG91dCB0aGF0IGRpc2N1c3Npb24gd2l0 aCBhIGRlY2lzaW9uIHNvb24gc28gd2UgY2FuIGFkdmFuY2UgdG8gYSBXRyBsYXN0IGNhbGwgb24g dGhlIGRyYWZ0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5UbyBzdW1tYXJpc2UgbXkgdGhvdWdodHMgb24gdGhlIHBhcmFtOjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPG9sIHN0YXJ0PSIxIiB0eXBlPSIxIj4NCjxsaSBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCkl0 IGNhbiBiZSBjYW4gYmUgdXNlZCB0byBpbXByb3ZlIHVzYWJpbGl0eSDigJMgUVIgY29kZXMgYW5k IE5GQyBjYW4gYmUgdXNlZCB3aXRoIHRoaXMgZmVhdHVyZSB0byBjcmVhdGUgYSBtb3JlIGRlbGln aHRmdWwgdXNlciBhdXRob3JpemF0aW9uIGV4cGVyaWVuY2UuPG86cD48L286cD48L2xpPjxsaSBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBsZm8x Ij4NCkl0IG1heSBpbmNyZWFzZSB0aGUgcG90ZW50aWFsIHBoaXNoaW5nIHJpc2sgKHdoaWNoIHdl IGNhbiBkb2N1bWVudCksIGFzIHRoZSB1c2VyIGhhcyBsZXNzIHR5cGluZy4gVGhpcyByaXNrIGFz c2Vzc21lbnQgaXMgbGlrZWx5IG5vdCBvbmUtc2l6ZS1maXRzLWFsbCwgaXQgbWF5IHZhcnkgd2lk ZWx5IGR1ZSB0byBkaWZmZXJlbnQgdGhlIGRpZmZlcmVudCBwb3RlbnRpYWwgYXBwbGljYXRpb25z IG9mIHRoaXMgc3RhbmRhcmQuPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 bWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NClRoZSB3YXkgaXQncyB3 b3JkZWQgbWFrZXMgaXQgY29tcGxldGVseSBvcHRpb25hbCwgbGVhdmluZyBpdCB1cCB0byB0aGUg ZGlzY3JldGlvbiBvZiB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgb24gd2hldGhlciB0byBvZmZl ciB0aGUgb3B0aW1pc2F0aW9uLCBhbGxvd2luZyB0aGVtIHRvIHNlY3VyZSBpdCBhcyBiZXN0IHRo ZXkgc2VlIGl0LjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1s ZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQpJIGRvIGJlbGlldmUgaXQgaXMgcG9z c2libGUgdG8gZGVzaWduIGEgc2VjdXJlIHVzZXIgZXhwZXJpYW5jZSB0aGF0IGluY2x1ZGVzIHRo aXMgb3B0aW1pemF0aW9uLjxvOnA+PC9vOnA+PC9saT48L29sPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkkgdGhpbmsgb24gdGhlIGJhbGFuY2UsIGl0J3Mgd29ydGh3aGlsZSBmZWF0dXJl IHRvIGluY2x1ZGUsIGFuZCBvbmUgdGhhdCBiZW5lZml0cyBpbnRlcm9wLiBUaGUgYXV0aG9yaXph dGlvbiBzZXJ2ZXIgaGFzIGNvbXBsZXRlIGNvbnRyb2wgb3ZlciB3aGV0aGVyIHRvIGVuYWJsZSB0 aGlzIGZlYXR1cmUg4oCTIGFzIEp1c3RpbiBwb2ludGVkIG91dCBpbiB0aGUgbWVldGluZywgaXQg ZGVncmFkZXMgcmVhbGx5IG5pY2VseQ0KIOKAkyBhbmQgc2hvdWxkIHRoZXkgZW5hYmxlIGl0LCB0 aGV5IGhhdmUgY29udHJvbCBvdmVyIHRoZSB1c2VyIGV4cGVyaWFuY2UgYW5kIGNhbiBhZGQgd2hh dGV2ZXIgcGhpc2hpbmcgbWl0aWdhdGlvbnMgdGhlaXIgdXNlLWNhc2Ugd2FycmFudHMuJm5ic3A7 IFJhcmVseSBpcyB0aGVyZSBhIG9uZS1zaXplLWZpdHMtYWxsIHJpc2sgcHJvZmlsZSwgdXNlLWNh c2VzIG9mIHRoaXMgZmxvdyByYW5nZSB3aWRlbHkgZnJvbSBtYXNzLW1hcmtldCBUViBhcHBzIHRv IGludGVybmFsLW9ubHkNCiBkZXZpY2UgYm9vdHN0cmFwcGluZyBieSBlbXBsb3llZXMsIHNvIEkg ZG9uJ3QgdGhpbmsgd2Ugc2hvdWxkIGJlIG92ZXJseSBwcmVzY3JpcHRpdmUuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk1pdGlnYXRpbmcgcGhp c2hpbmcgaXMgYWxyZWFkeSBzb21ldGhpbmcgdGhhdCBpcyBpbiB0aGUgZG9tYWluIG9mIHRoZSBh dXRob3JpemF0aW9uIHNlcnZlciB3aXRoIE9BdXRoIGdlbmVyYWxseSwgYW5kIEkga25vdyB0aGF0 IHRoaXMgaXMgYW4gZXh0cmVtZWx5IGltcG9ydGFudCBjb25zaWRlcmF0aW9uIHdoZW4gZGVzaWdu aW5nIHVzZXIgYXV0aG9yaXphdGlvbiBmbG93cy4gVGhpcyBzcGVjIHdpbGwgYmUgbm8NCiBleGNl cHRpb24gdG8gdGhhdCwgd2l0aCBvciB3aXRob3V0IHRoaXMgb3B0aW1pemF0aW9uLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+VGhhdCdzIG15IG9waW5pb24uIEknbSBrZWVuIHRv IGNvbnRpbnVlIHRoZSBkaXNjdXNzaW9uIGZyb20gQ2hpY2FnbyBhbmQgcmVhY2ggcm91Z2ggY29u c2Vuc3VzIHNvIHdlIGNhbiBwcm9ncmVzcyBmb3J3YXJkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QmVzdCw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldpbGxpYW08bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_CY4PR21MB0504A4BA6BFB6351A64169A8F5130CY4PR21MB0504namp_-- From nobody Fri Apr 28 15:40:52 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8745A129B62 for ; Fri, 28 Apr 2017 15:40:50 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QsvrH6bu7ikx for ; Fri, 28 Apr 2017 15:40:48 -0700 (PDT) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::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 382FD129AAC for ; Fri, 28 Apr 2017 15:38:19 -0700 (PDT) Received: by mail-qt0-x22c.google.com with SMTP id c45so61153087qtb.1 for ; Fri, 28 Apr 2017 15:38:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=i+xXLHXvlGIawjK8domAKrUOqObEAzANjnu1sW/DrQE=; b=J7446tsOrtutsQTsBT8GvG+p2Jf3DCaaejEIAD465Ui8C9c1ZlRr2nAtuQ8ZswudD2 rGiRT0taXk35P+Rl4k/5gK8eA+6EuDVhztVkh6F3nl1cr1FHRQ9Ky09YaXHJFPIY1eMf cnhaJPM0d2xCXg4KazfmXsG2SV29HbWiY4G/P1t2H8YTjGkaUkX1+NTEMwbhBV+zJKbR ZgE2/h+wyZvdLvBkLg4Y/tKDJp0B5BTukM0LmgJWdMu8EiPtuR/087rFXBYLCQowg81B tzI7gKAtMaO2VseDFaqQgbmvan0ocj9qyXztMR1mHiwQTFV34th9vIkXVC8kMW5b5ABd I1rQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=i+xXLHXvlGIawjK8domAKrUOqObEAzANjnu1sW/DrQE=; b=HS5ZQ0J1bfJZR0ksHCjJEOvCjZXI2nhh06T7LxTBf7k+eDTIXeHAbp6fCKeFdK10Gx 4WYwAr4gb9gzTrjC6OVza+a9qk9lnkcxrzIZ8TRbkt/1aH/3DuPNAqjSNNd7mvD29Qo2 Pk06daAMNc0OkGn76QFnLrNsXBPVmu9L3oFe5bEFGeq7Epwqz0PSQ/5ZlA85vnj88Jz4 sj4/VrnQ5os8fVFUxr7lAJ5cft3yJ0BIJvR4HHtUoe1DlAqLDMU0tXRgzQoGmdLBbhDe M5SpKtkDRglwVdvFgZAW44uNa5gP22YWDMscK10cLbx15kE81QXF6rT9eYq5Bq4z/DIx hxEA== X-Gm-Message-State: AN3rC/4vmDGCwF4pyQwi+ir1UdahfXb/Tk/g5ebCJTu8HspVdKevyXqj tZ/Wx4md8OhM83uJ X-Received: by 10.200.42.199 with SMTP id c7mr13310401qta.102.1493419098087; Fri, 28 Apr 2017 15:38:18 -0700 (PDT) Received: from [192.168.8.100] ([181.201.77.247]) by smtp.gmail.com with ESMTPSA id v64sm5390538qkg.38.2017.04.28.15.38.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Apr 2017 15:38:17 -0700 (PDT) From: John Bradley Message-Id: <77856AF4-9B2E-4478-9509-1459037C24E4@ve7jtb.com> Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 28 Apr 2017 19:38:14 -0300 In-Reply-To: Cc: "oauth@ietf.org" , Hannes Tschofenig , Michael Jones To: William Denniss References: X-Mailer: Apple Mail (2.3273) Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a11404eb0db1159054e41bac8" Archived-At: Subject: Re: [OAUTH-WG] OAuth 2.0 Device Flow: IETF98 Follow-up X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2017 22:40:50 -0000 --001a11404eb0db1159054e41bac8 Content-Type: multipart/alternative; boundary="Apple-Mail=_21D95259-3554-4C9C-A8BA-640F1139497C" --Apple-Mail=_21D95259-3554-4C9C-A8BA-640F1139497C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I would like to keep the optional parameter. It is useful enough that = if we don=E2=80=99t have it people will add it on there own as a custom = parameter. =20 Better to document any issues.=20 John B. > On Apr 28, 2017, at 5:39 PM, William Denniss = wrote: >=20 > Thanks all who joined us in Chicago in person and remotely last month = for the discussion on the device flow. [recording here = , presentation starts at about 7min in]. >=20 > The most contentious topic was addition of the user_code URI param = extension (introduced in version 05, documented in Section 3.3 = )= . >=20 > I'd like to close out that discussion with a decision soon so we can = advance to a WG last call on the draft. >=20 > To summarise my thoughts on the param: > It can be can be used to improve usability =E2=80=93 QR codes and NFC = can be used with this feature to create a more delightful user = authorization experience. > It may increase the potential phishing risk (which we can document), = as the user has less typing. This risk assessment is likely not = one-size-fits-all, it may vary widely due to different the different = potential applications of this standard. > The way it's worded makes it completely optional, leaving it up to the = discretion of the authorization server on whether to offer the = optimisation, allowing them to secure it as best they see it. > I do believe it is possible to design a secure user experiance that = includes this optimization. > I think on the balance, it's worthwhile feature to include, and one = that benefits interop. The authorization server has complete control = over whether to enable this feature =E2=80=93 as Justin pointed out in = the meeting, it degrades really nicely =E2=80=93 and should they enable = it, they have control over the user experiance and can add whatever = phishing mitigations their use-case warrants. Rarely is there a = one-size-fits-all risk profile, use-cases of this flow range widely from = mass-market TV apps to internal-only device bootstrapping by employees, = so I don't think we should be overly prescriptive. >=20 > Mitigating phishing is already something that is in the domain of the = authorization server with OAuth generally, and I know that this is an = extremely important consideration when designing user authorization = flows. This spec will be no exception to that, with or without this = optimization. >=20 > That's my opinion. I'm keen to continue the discussion from Chicago = and reach rough consensus so we can progress forward. >=20 > Best, > William >=20 --Apple-Mail=_21D95259-3554-4C9C-A8BA-640F1139497C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I would like to keep the optional parameter.   It is = useful enough that if we don=E2=80=99t have it people will add it on = there own as a custom parameter.  
Better to = document any issues. 

John B.
On Apr 28, 2017, at 5:39 PM, William Denniss = <wdenniss@google.com> wrote:

Thanks all who joined us in Chicago in person and remotely = last month for the discussion on the device flow. [recording here, presentation starts at about = 7min in].

The most = contentious topic was addition of the user_code URI param extension = (introduced in version 05, documented in Section 3.3).

I'd like to close out that discussion = with a decision soon so we can advance to a WG last call on the = draft.

To = summarise my thoughts on the param:
  1. It can be can be used to improve usability =E2=80= =93 QR codes and NFC can be used with this feature to create a more = delightful user authorization experience.
  2. It may = increase the potential phishing risk (which we can document), as the = user has less typing. This risk assessment is likely not = one-size-fits-all, it may vary widely due to different the different = potential applications of this standard.
  3. The way it's = worded makes it completely optional, leaving it up to the discretion of = the authorization server on whether to offer the optimisation, allowing = them to secure it as best they see it.
  4. I= do believe it is possible to design a secure user experiance that = includes this optimization.
I think on the = balance, it's worthwhile feature to include, and one that benefits = interop. The authorization server has complete control over whether to = enable this feature =E2=80=93 as Justin pointed out in the meeting, it = degrades really nicely =E2=80=93 and should they enable it, they have = control over the user experiance and can add whatever phishing = mitigations their use-case warrants.  Rarely is there a = one-size-fits-all risk profile, use-cases of this flow range widely from = mass-market TV apps to internal-only device bootstrapping by employees, = so I don't think we should be overly prescriptive.

Mitigating phishing is = already something that is in the domain of the authorization server with = OAuth generally, and I know that this is an extremely important = consideration when designing user authorization flows. This spec will be = no exception to that, with or without this optimization.

That's my opinion. = I'm keen to continue the discussion from Chicago and reach rough = consensus so we can progress forward.

Best,
William


= --Apple-Mail=_21D95259-3554-4C9C-A8BA-640F1139497C-- --001a11404eb0db1159054e41bac8 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIRGwYJKoZIhvcNAQcCoIIRDDCCEQgCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg gg4rMIIErzCCA5egAwIBAgIRAOAjyxUSg1OJrWFuelRnayEwDQYJKoZIhvcNAQELBQAwbzELMAkG A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0xNDEy MjIwMDAwMDBaFw0yMDA1MzAxMDQ4MzhaMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRl ZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1 cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCJsQ3aelMZTnBSHbxW pgYmt7hJ4JbnUavx8FoTSRWjtIwbYLx6UUKneYykIt8XYU6R1XYjChTTSgJ/th0JgG6lBD3ZursW /qGHqS5DUkMWfK8yUMimT1rpCNjPkyWce4joMGTmpPhWgP0qJBQzF5msROVpi6NGBkvCM9TpQJ8G sLGsk0C5tQiTOpwqU6MQ2z0gYTxVA47ZTnYlAiEp+qN8cXZP7uFfgen7VIDbw3s1UreE3iI9LDAt MX9ZvVI3sDNpLUPr+tal8Zd3Z1GM2e4n67ylBzh2jKSpOP/fjPUDrEm+yvdzmToPMquclToTPQ5G Old0YVC+xkA/y+Tin6IhAgMBAAGjggEXMIIBEzAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73g JMtUGjAdBgNVHQ4EFgQUkmFrguGioKpP7GfxwqP3tIAAwewwDgYDVR0PAQH/BAQDAgGGMBIGA1Ud EwEB/wQIMAYBAf8CAQAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBEGA1UdIAQKMAgw BgYEVR0gADBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vQWRkVHJ1 c3RFeHRlcm5hbENBUm9vdC5jcmwwNQYIKwYBBQUHAQEEKTAnMCUGCCsGAQUFBzABhhlodHRwOi8v b2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBCwUAA4IBAQAbKm6sVcE6q4jF2O3NVfOqa2Er wAkQI5kPxWZqb7H1tLV3Xg8CYQDffQX+ErOkgIAA/PsdW2pyAgpBvAW6wVjVJsLq1U2E+/6CmM9Y G+MiY5xS+LsFNqt9WKXeqztj5drVc+/s4Pt74qP/8EIjnMq2jU0+5EsYA7KoLdTYu0JLkGmFENum NzToe+ABEKWcyjrHn0+ING6KZdAairup3MrKNtH0/MJkKTWv1rGncRHSA0Oxjz6a7J4yU/R2ksqG NAe5LMrmHErYmQ3BhuKQkvtaQmojIRDpZcf11bt+6oyFIAJi6tE6ByxZxZkz8jiJ5bbpFnofeRT2 ShAaJvp8ivubMIIENjCCAx6gAwIBAgIBATANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEU MBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3 b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTAwMDUzMDEwNDgzOFoX DTIwMDUzMDEwNDgzOFowbzELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYD VQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0 ZXJuYWwgQ0EgUm9vdDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALf3GjPm8gAELTng TlvtH7xsD821+iO2zt6bETOXpClMfZOfvUq8k+0DGuOPz+VtUFrWlymUWoCwSXrbLpX9uMq/Nzgt Hj6RQa1wVsfwTz/oMp50ysiQVOnGXw94nZpAPA6sYapeFI+eh6FqUNzXmk6vBbOmcZSccbNQYArH E504B4YCqOmoaSYYkKtMsE8jqzpPhNjfzp/haW+710LXa0Tkx63ubUFfclpxCDezeWWkWaCUN/cA Lw3CknLa0Dhy2xSoRcRdKn23tNbE7qzNE0S3ySvdQwAl+mG5aWpYIxG3pzOPVnVZ9c0p10a3Citl ttNCbxWyuHv77+ldU9U0WicCAwEAAaOB3DCB2TAdBgNVHQ4EFgQUrb2YejS0Jvf6xCZU7wO94CTL VBowCwYDVR0PBAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wgZkGA1UdIwSBkTCBjoAUrb2YejS0Jvf6 xCZU7wO94CTLVBqhc6RxMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4 dGVybmFsIENBIFJvb3SCAQEwDQYJKoZIhvcNAQEFBQADggEBALCb4IUlwtYj4g+WBpKdQZic2YR5 gdkeWxQHIzZlj7DYd7usQWxHYINRsPkyPef89iYTx4AWpb9a/IfPeHmJIZriTAcKhjW88t5RxNKW t9x+Tu5w/Rw56wwCURQtjr0W4MHfRnXnJK3s9EK0hZNwEGe6nQY1ShjTK3rMUUKhemPR5ruhxSvC Nr4TDea9Y355e6cJDUCrat2PisP29owaQgVR1EX1n6diIWgVIEM8med8vSTYqZEXc4g/VhsxOBi0 cQ+azcgOno4uG+GMmIPLHzHxREzGBHNJdmAPx/i9F4BrLunMTA5amnkPIAou1Z5jJh5VkpTYghda e9C8x49OhgQwggU6MIIEIqADAgECAhEA2TLMtWuXNcB2cbqZ/VgVujANBgkqhkiG9w0BAQsFADCB mzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2 IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE3MDEwOTAwMDAw MFoXDTE4MDEwOTIzNTk1OVowIjEgMB4GCSqGSIb3DQEJARYRdmU3anRiQHZlN2p0Yi5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDW2rqobOFQ/XmzH3DG2UK1Dt6jtc+OFZ71KQoB o8IZa/V94Ey12BPjBcoj+cjHNVsLd2QiUpMcf5sZFMX1cmvpR7TiUISgVcHe8zgiUUvN5Jn5tPDM Kb4E34TtDEG2X5FyY35AwCl8NV/loj2D5KLid9BLdVTJjfqokjLQ/4qCQjWBjfTpIdAdr3lXfg5f a5UPyIkphEIplM8/yGfX0W/PBl804XAL0gesLrfEMdgG58UCN1wJMgH4uRKmKU/U2Ap4W9hTpioN M722U8x7N6P1v6MqTAWCUaskdOp+ktNxFGxOlCE7BEo/EIaWbEt5RHwDePctScDLsi56+VI3TysR AgMBAAGjggHvMIIB6zAfBgNVHSMEGDAWgBSSYWuC4aKgqk/sZ/HCo/e0gADB7DAdBgNVHQ4EFgQU Yg3SsFWhMro4Abonbn1IX4JKj5QwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0l BBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9 MDsGDCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0 L0NQUzBdBgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9TSEEy NTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDBYBggrBgEFBQcwAoZMaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xp ZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDov L29jc3AuY29tb2RvY2EuY29tMBwGA1UdEQQVMBOBEXZlN2p0YkB2ZTdqdGIuY29tMA0GCSqGSIb3 DQEBCwUAA4IBAQCC26y+6/+SJoRQWepca+rB9eSSwaCAb8nNqA+00ZiOHb+6UbbV1xa7Z8wDIuEL 5UKbNtQ2NDArvzF9YI0xNafoV1AEmP/3+ljxQHSEI0U1p2h401sOx+nSjcwtTzACso1lw+I0oJYM JFITOIfZy8HgFpCipBrQAp9jMJ+KSKDX3xu/hzPosfdnXp7sV1KAjkFrAtR3AnQYfJ5W8QrsmC4N BbiAKoYWUSdklqn3v1neTG/+oOhcw7hcGZo+YmPyF9Cdy0gBtwSHPt8hluhg2TlzmqYfi0dVL/mU jCBNUY/BFH+MBqKF7sOIRMv8ALWceVaM/NEcBciKs4eR99A4cw9ZMYICtDCCArACAQEwgbEwgZsx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRANkyzLVrlzXAdnG6mf1Y FbowDQYJYIZIAWUDBAIBBQCggdQwLwYJKoZIhvcNAQkEMSIEICq211c8nbwgml8IYIsj6psW4n6m yJrRbzZeMv7X78U/MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE3 MDQyODIyMzgxOFowaQYJKoZIhvcNAQkPMVwwWjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzALBgkqhkiG9w0BAQowCwYJKoZIhvcNAQEHMAsGCWCGSAFl AwQCATANBgkqhkiG9w0BAQEFAASCAQCb+qkYP6xnw7HV0Tk/Y/afPG3RDt/t6zvLN6rLPCGJhP28 irVfQ3Ir1Rq6BbsFctu/IoFx5nwyYXE50n3PigYtaUvxQKp8no9WY6eViSK+EeBixVElzw/Ge4/z qmWhGI7Q5GYIA6xLiRvLxCYf+4s7aBMZvSd4lGDVmUv24BsRLAeCWUEgntaGyUWG237cMRUHILfG pxIepy/ie6xrMC2DQeRRESHGouyfGujS9KdaYRa1wMfvjalyh76WreqAG1O632eN4vJ2RyJtljaP FhUGnRdqsD++exybvC7Eg8AtxFhIUXFu5N4rl1zuRhSMhWp/5mxD1VoCVR5eSNbVEz37 --001a11404eb0db1159054e41bac8-- From nobody Sat Apr 29 06:12:59 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF587129438 for ; Sat, 29 Apr 2017 06:12:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C4vBjGn-mBu8 for ; Sat, 29 Apr 2017 06:12:55 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBF80127136 for ; Sat, 29 Apr 2017 06:12:26 -0700 (PDT) X-AuditID: 1209190f-6afff70000006010-bf-59049139027c Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id B8.5B.24592.93194095; Sat, 29 Apr 2017 09:12:25 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id v3TDCO7Q024273; Sat, 29 Apr 2017 09:12:24 -0400 Received: from [192.168.128.57] (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 v3TDCL0N031845 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 29 Apr 2017 09:12:23 -0400 To: John Bradley , William Denniss Cc: "oauth@ietf.org" References: <77856AF4-9B2E-4478-9509-1459037C24E4@ve7jtb.com> From: Justin Richer Message-ID: <22d06952-94ab-e6a9-d2b2-f96f8252bf5e@mit.edu> Date: Sat, 29 Apr 2017 09:12:10 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.0.1 MIME-Version: 1.0 In-Reply-To: <77856AF4-9B2E-4478-9509-1459037C24E4@ve7jtb.com> Content-Type: multipart/alternative; boundary="------------5C7FE7964D71EAF9D5E6EDC7" Content-Language: en-US X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCKsWRmVeSWpSXmKPExsUixG6nrms5kSXS4PRaBYuTb1+xWay++5fN YtOcZnYHZo8Fm0o9liz5yeRx+/ZGlgDmKC6blNSczLLUIn27BK6MRe9/sRZsS61Y+KyJsYHx sHsXIyeHhICJxKz+7cxdjFwcQgJtTBJfr29mhXA2Mkpc2LqRCaRKSOA2k0T/f28QW1jAXuLy nC4WEFtEwFvi3fe/jCA2s4CqxJcF75kgmlsYJTbMXs4MkmADSkxf0wKU4ODgFbCS+HyrBiTM AhS+1zKLDcQWFYiReNmzFaycV0BQ4uTMJ2DzOQXsJLo+3mKHmB8m8edCLwuELS5x68l8pgmM ArOQtMxCUjYLSRmEbSYxb/NDZghbXqJ562wgmwPIVpNY1qqELLyAkX0Vo2xKbpVubmJmTnFq sm5xcmJeXmqRrolebmaJXmpK6SZGUGRwSvLvYJzT4H2IUYCDUYmHt8ODOVKINbGsuDL3EKMk B5OSKG8VB0ukEF9SfkplRmJxRnxRaU5q8SFGCQ5mJRHev+1AOd6UxMqq1KJ8mJQ0B4uSOK+4 RmOEkEB6YklqdmpqQWoRTFaGg0NJgtdsAlCjYFFqempFWmZOCUKaiYMTZDgP0HAOkBre4oLE 3OLMdIj8KUZFKXHeyH6ghABIIqM0D64XlLgS3h42fcUoDvSKMG8mSDsPMOnBdb8CGswENLhe DWxwSSJCSqqBcae+Y6yPnMvDxaGT7mx9f8VCSnXCL4Gq3LsyHzb8Ociz/ZrO9advFny1irGf w1r2/FGnbV5BxqeW0z6Mq49LcMy8Puuh5aqrZ0N+tGdty76bMnUJf+bdfZv9Kx7cDDhc8GHr tIAJy79Z7l0r/YDBa8OToh2lj8KS91tr+yxOPX3vq6qUa9vjr7uVWIozEg21mIuKEwEX0/Ai NwMAAA== Archived-At: Subject: Re: [OAUTH-WG] OAuth 2.0 Device Flow: IETF98 Follow-up X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Apr 2017 13:12:58 -0000 This is a multi-part message in MIME format. --------------5C7FE7964D71EAF9D5E6EDC7 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit +1, documentation is better. Though we also need to keep in mind that this was the justification for the password flow in 6749, which has been abused all over the place (and continues to this day). Still, it would be arguably worse without that so I'm good with keeping the parameter in there as long as we're careful. Namely: So long as the user code is *also* delivered separately to the user, we would have interoperability between the two. What I don't think we want is some systems that *require* the URI parameter on the approval URL and other implementations that *forbid* it. That case could end up with something like: I've got a set-top system that's incapable of displaying a separate user code because it always assumes it's baked into the URL, and then I try to put it on a server that requires the code be entered separately. The resulting spec needs to be clear that the box MUST be able to display both the URL and the code separately, in case the URL does not include the code. In fact, maybe we'd even want to introduce a new parameter from the endpoint for the pre-composed URL: user_code REQUIRED. The end-user verification code. verification_uri REQUIRED. The end-user verification URI on the authorization server. The URI should be short and easy to remember as end- users will be asked to manually type it into their user-agent. composite_verification_uri OPTIONAL. The end-user verification URI with the end-user verification code already included. See discussion in [blah] for its use. -- Justin On 4/28/2017 6:38 PM, John Bradley wrote: > I would like to keep the optional parameter. It is useful enough > that if we don’t have it people will add it on there own as a custom > parameter. > Better to document any issues. > > John B. >> On Apr 28, 2017, at 5:39 PM, William Denniss > > wrote: >> >> Thanks all who joined us in Chicago in person and remotely last month >> for the discussion on the device flow. [recording here >> , >> presentation starts at about 7min in]. >> >> The most contentious topic was addition of the user_code URI param >> extension (introduced in version 05, documented in Section 3.3 >> ). >> >> I'd like to close out that discussion with a decision soon so we can >> advance to a WG last call on the draft. >> >> To summarise my thoughts on the param: >> >> 1. It can be can be used to improve usability – QR codes and NFC can >> be used with this feature to create a more delightful user >> authorization experience. >> 2. It may increase the potential phishing risk (which we can >> document), as the user has less typing. This risk assessment is >> likely not one-size-fits-all, it may vary widely due to different >> the different potential applications of this standard. >> 3. The way it's worded makes it completely optional, leaving it up >> to the discretion of the authorization server on whether to offer >> the optimisation, allowing them to secure it as best they see it. >> 4. I do believe it is possible to design a secure user experiance >> that includes this optimization. >> >> I think on the balance, it's worthwhile feature to include, and one >> that benefits interop. The authorization server has complete control >> over whether to enable this feature – as Justin pointed out in the >> meeting, it degrades really nicely – and should they enable it, they >> have control over the user experiance and can add whatever phishing >> mitigations their use-case warrants. Rarely is there a >> one-size-fits-all risk profile, use-cases of this flow range widely >> from mass-market TV apps to internal-only device bootstrapping by >> employees, so I don't think we should be overly prescriptive. >> >> Mitigating phishing is already something that is in the domain of the >> authorization server with OAuth generally, and I know that this is an >> extremely important consideration when designing user authorization >> flows. This spec will be no exception to that, with or without this >> optimization. >> >> That's my opinion. I'm keen to continue the discussion from Chicago >> and reach rough consensus so we can progress forward. >> >> Best, >> William >> > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------5C7FE7964D71EAF9D5E6EDC7 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

+1, documentation is better. Though we also need to keep in mind that this was the justification for the password flow in 6749, which has been abused all over the place (and continues to this day). Still, it would be arguably worse without that so I'm good with keeping the parameter in there as long as we're careful.

Namely: So long as the user code is *also* delivered separately to the user, we would have interoperability between the two. What I don't think we want is some systems that *require* the URI parameter on the approval URL and other implementations that *forbid* it. That case could end up with something like: I've got a set-top system that's incapable of displaying a separate user code because it always assumes it's baked into the URL, and then I try to put it on a server that requires the code be entered separately.

The resulting spec needs to be clear that the box MUST be able to display both the URL and the code separately, in case the URL does not include the code. In fact, maybe we'd even want to introduce a new parameter from the endpoint for the pre-composed URL:

   user_code
      REQUIRED.  The end-user verification code.

   verification_uri
      REQUIRED.  The end-user verification URI on the authorization
      server.  The URI should be short and easy to remember as end-
      users will be asked to manually type it into their user-agent.

   composite_verification_uri
      OPTIONAL.  The end-user verification URI with the end-user 
      verification code already included. See discussion in [blah]
      for its use.

 -- Justin
On 4/28/2017 6:38 PM, John Bradley wrote:
I would like to keep the optional parameter.   It is useful enough that if we don’t have it people will add it on there own as a custom parameter.  
Better to document any issues. 

John B.
On Apr 28, 2017, at 5:39 PM, William Denniss <wdenniss@google.com> wrote:

Thanks all who joined us in Chicago in person and remotely last month for the discussion on the device flow. [recording here, presentation starts at about 7min in].

The most contentious topic was addition of the user_code URI param extension (introduced in version 05, documented in Section 3.3).

I'd like to close out that discussion with a decision soon so we can advance to a WG last call on the draft.

To summarise my thoughts on the param:
  1. It can be can be used to improve usability – QR codes and NFC can be used with this feature to create a more delightful user authorization experience.
  2. It may increase the potential phishing risk (which we can document), as the user has less typing. This risk assessment is likely not one-size-fits-all, it may vary widely due to different the different potential applications of this standard.
  3. The way it's worded makes it completely optional, leaving it up to the discretion of the authorization server on whether to offer the optimisation, allowing them to secure it as best they see it.
  4. I do believe it is possible to design a secure user experiance that includes this optimization.
I think on the balance, it's worthwhile feature to include, and one that benefits interop. The authorization server has complete control over whether to enable this feature – as Justin pointed out in the meeting, it degrades really nicely – and should they enable it, they have control over the user experiance and can add whatever phishing mitigations their use-case warrants.  Rarely is there a one-size-fits-all risk profile, use-cases of this flow range widely from mass-market TV apps to internal-only device bootstrapping by employees, so I don't think we should be overly prescriptive.

Mitigating phishing is already something that is in the domain of the authorization server with OAuth generally, and I know that this is an extremely important consideration when designing user authorization flows. This spec will be no exception to that, with or without this optimization.

That's my opinion. I'm keen to continue the discussion from Chicago and reach rough consensus so we can progress forward.

Best,
William




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

--------------5C7FE7964D71EAF9D5E6EDC7--