From nobody Wed Nov 8 03:34:56 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 DFD91131A08 for ; Wed, 8 Nov 2017 03:34:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.439 X-Spam-Level: X-Spam-Status: No, score=-2.439 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, HTML_OBFUSCATE_05_10=0.26, 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=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 KOYVZBl-3IlN for ; Wed, 8 Nov 2017 03:34:51 -0800 (PST) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B019F1319EF for ; Wed, 8 Nov 2017 03:34:51 -0800 (PST) Received: by mail-yw0-x22b.google.com with SMTP id w2so1995468ywa.9 for ; Wed, 08 Nov 2017 03:34:51 -0800 (PST) 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=N7gxKDOJDm3aLFqrtgcTVqobCxzT7YP1wjvCmwyDrOs=; b=lzuO6CLSa4KrExXBAt0gUKWomV5k2S2BCfQDAS+n54rG4Unbc5Gutgw7/IX2Jbl2M0 UGyVGNVrrrlaK72Ot1bKCN6AOWUKPOPrfH4xtYbaY1WqC99Iya5wNi9zkjR5ZDjQOHVF jeJ73vUkx8NM6knGW9g9iH7pS6d8pApEU+fe1ozLJvjoJ/b+zaXe7p4ecV2WDD2ckooR ZQGkwkE2toOg/Y97AZo6XRKwq8UJsRciLqhAkFnqx75kaV3wuSusJYRI5zcjKdl0L21T 7y/1Cs901I39Hut0oe/9KwWDWaldIOVTOiZqPBdihAh9zt8IftZ48BxW4sns3fXAeM3+ 6/hg== 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=N7gxKDOJDm3aLFqrtgcTVqobCxzT7YP1wjvCmwyDrOs=; b=Tj8LzFyJH75K4NQ6gB2b09t5wdd5U8moZqLkD7CMPYzIKELvwAyKjoN4JfFdazdjUM 4nOIp95n0XZmgC8dIiDuq7uLmgCbvdck3d5RULQmlYYeXL3K2KICRs4MmGU3kv0zcP1+ 2SLrULjb9BvJldGJoo7ufy+wEfzCEXvSPqHIAWl/qavkZQa7XA8EZCKIOPelPevK/RX8 W+yMPjvodKx0K18cf09YMGP6WNKXLMo0F5wybdPz6DfLXqqmJ7xjMMs2Qw0FCET/Fr9L nfuo/XFsvdr7+1s2d38ZpCnfJ7qF4wb9x9RegigNX0b6Vw9VZJ3y4jgc5lx6/c0+Bq2g Q0PA== X-Gm-Message-State: AJaThX5H1SSQrISm3mu3gCkxwout2KdmsFg/QmEFbY0r2erZu6vKYY7t DzSzjYOGP6dc9gG0gBZoWTmlQ0qI6a1oFgv+PTQ= X-Google-Smtp-Source: ABhQp+QrnvVWhfwJ5VhGCQiv9SmRj46Vh7hphi0MfRi2Az7DYtBhX9KnX0Gjt/Kxbwrq4zjTEHZeqKHrDmRF21gidKg= X-Received: by 10.37.162.142 with SMTP id c14mr103637ybi.406.1510140890795; Wed, 08 Nov 2017 03:34:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.248.32 with HTTP; Wed, 8 Nov 2017 03:34:50 -0800 (PST) In-Reply-To: References: <150784500346.16836.10053591552617872796@ietfa.amsl.com> <83c305ab-4c3b-b16e-1385-7e0e3af6a556@connect2id.com> From: Takahiko Kawasaki Date: Wed, 8 Nov 2017 11:34:50 +0000 Message-ID: To: Brian Campbell Cc: oauth Content-Type: multipart/alternative; boundary="089e0828b5545b532e055d7713c0" Archived-At: Subject: Re: [OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-mtls-04.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, 08 Nov 2017 11:34:55 -0000 --089e0828b5545b532e055d7713c0 Content-Type: text/plain; charset="UTF-8" Dear Brian, I'd like to make some small comments. 2. / 1st paragraph / 4th line "for client authentications" --> "for client authentication" (remove 's' at the end) 2.1.1. / 1st paragraph / 4th line "used to indicated" -> "used to indicate" (remove 'd' at the end) 2.2. / 1st paragraph / 3rd line "a X.509 certificate" -> "an X.509 certificate" (replace "a" with "an") 2.2. / 1st paragraph / 11th line "info of one the" -> "info of one of the" (insert "of" between "one" and "the") 2.2. / 1st paragraph / 17th line "directly with at the" -> "directly at the" (remove "with") 2.2.1. / 1st paragraph / 4th line "used to indicated" -> "used to indicate" (remove 'd' at the end) 3.1. / 1st paragraph / 1st line "as a JSON Web Tokens" -> "as JSON Web Tokens" (remove 'a') 3.1. / 2nd paragraph / 6th-7th lines "are also sometimes also" -> "are sometimes also" (remove one "also") 3.3. & 3.4. After reading the specification, for me, "certificate_bound_access_tokens" sounds more natural than "mutual_tls_sender_constrained_access_tokens". Is there any special reason for the parameter name? 4.3. / 1st paragraph / 1st line "allows for the use" -> "allows use" (remove "for the", but I'm not sure because I'm not a native English speaker.) 6.1. / 1st paragraph / 2nd line "it is latest" -> "it is the latest" (insert "the" between "is" and "latest") By the way, isn't it necessary to define rules for REFRESH tokens? For example, "if a refresh token is issued, it MUST/SHOULD/MAY be also bound to the same certificate. When the token endpoint of the authorization server receives a refresh token request with a certificate-bound refresh token, ..." Best Regards, Taka 2017-10-13 17:31 GMT+01:00 Brian Campbell : > Thanks for the review, Vladimir. And yes, sender-constrained access tokens > should also work in a token exchange scenario. > > On Fri, Oct 13, 2017 at 3:18 AM, Vladimir Dzhuvinov < > vladimir@connect2id.com> wrote: > >> Superb! Thanks for putting down everything that was discussed. I read the >> new version and have zero comments about it. >> >> Will sender-constrained access tokens also work in a token exchange >> scenario? >> >> (draft-ietf-oauth-token-exchange-09) >> >> Vladimir >> >> On 13/10/17 01:07, Brian Campbell wrote: >> >> I'm pleased to announce that a new draft of "Mutual TLS Profile for OAuth >> 2.0" has been published. The changes, based on feedback and discussion on >> this list over the last two months, are listed below. >> >> draft-ietf-oauth-mtls-04 >> >> o Change the name of the 'Public Key method' to the more accurate >> 'Self-Signed Certificate method' and also change the associated >> authentication method metadata value to >> "self_signed_tls_client_auth". >> o Removed the "tls_client_auth_root_dn" client metadata field as >> discussed in https://mailarchive.ietf.org/arch/msg/oauth/ >> swDV2y0be6o8czGKQi1eJV-g8qc >> o Update draft-ietf-oauth-discovery reference to >> -07 >> o Clarify that MTLS client authentication isn't exclusive to the >> token endpoint and can be used with other endpoints, e.g. RFC >> 7009 revocation and 7662 >> introspection, that utilize client >> authentication as discussed in >> https://mailarchive.ietf.org/arch/msg/oauth/ >> bZ6mft0G7D3ccebhOxnEYUv4puI >> >> o Reorganize the document somewhat in an attempt to more clearly >> make a distinction between mTLS client authentication and >> certificate bound access tokens as well as a more clear >> delineation between the two (PKI/Public key) methods for client >> authentication >> o Editorial fixes and clarifications >> >> >> ---------- Forwarded message ---------- >> From: >> Date: Thu, Oct 12, 2017 at 3:50 PM >> Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-mtls-04.txt >> To: i-d-announce@ietf.org >> Cc: oauth@ietf.org >> >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Web Authorization Protocol WG of the IETF. >> >> Title : Mutual TLS Profile for OAuth 2.0 >> Authors : Brian Campbell >> John Bradley >> Nat Sakimura >> Torsten Lodderstedt >> Filename : draft-ietf-oauth-mtls-04.txt >> Pages : 18 >> Date : 2017-10-12 >> >> Abstract: >> This document describes Transport Layer Security (TLS) mutual >> authentication using X.509 certificates as a mechanism for OAuth >> client authentication to the authorization sever as well as for >> certificate bound sender constrained access tokens. >> >> >> The IETF datatracker status page for this draft is:https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/ >> >> There are also htmlized versions available at:https://tools.ietf.org/html/draft-ietf-oauth-mtls-04https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-04 >> >> A diff from the previous version is available at:https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-mtls-04 >> >> >> 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 listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth >> >> >> >> _______________________________________________ >> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited. > If you have received this communication in error, please notify the sender > immediately by e-mail and delete the message and any file attachments from > your computer. Thank you.* > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --089e0828b5545b532e055d7713c0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Brian,

I'd like to make some s= mall comments.

2. / 1st paragraph / 4th line<= /div>
"for client authentications" --> "for client au= thentication"
(remove 's' at the end)

=
2.1.1. / 1st paragraph / 4th line
"used to indica= ted" -> "used to indicate"
(remove 'd' = at the end)

2.2. / 1st paragraph / 3rd line
<= div>"a X.509 certificate" -> "an X.509 certificate"<= /div>
(replace "a" with "an")

<= div>2.2. / 1st paragraph / 11th line
"info of one the" = -> "info of one of the"
(insert "of" betwe= en "one" and "the")

2.2. / 1st= paragraph / 17th line
"directly with at the" -> &qu= ot;directly at the"
(remove "with")

=
2.2.1. / 1st paragraph / 4th line
"used to indica= ted" -> "used to indicate"
(remove 'd' = at the end)

3.1. / 1st paragraph / 1st line
<= div>"as a JSON Web Tokens" -> "as JSON Web Tokens"
(remove 'a')

3.1. / 2nd paragraph= / 6th-7th lines
"are also sometimes also" -> "= are sometimes also"
(remove one "also")
=
3.3. & 3.4.
After reading the specification, f= or me, "certificate_bound_access_tokens" sounds more natural than= "mutual_tls_sender_constrained_access_tokens". Is there any spec= ial reason for the parameter name?

4.3. / 1st para= graph / 1st line
"allows for the use" -> "allow= s use"
(remove "for the", but I'm not sure bec= ause I'm not a native English speaker.)

6.1. /= 1st paragraph / 2nd line
"it is latest" -> "it= is the latest"
(insert "the" between "is&quo= t; and "latest")

By the way, isn't i= t necessary to define rules for REFRESH tokens? For example, "if a ref= resh token is issued, it MUST/SHOULD/MAY be also bound to the same certific= ate. When the token endpoint of the authorization server receives a refresh= token request with a certificate-bound refresh token, ..."
=
Best Regards,
Taka


2017-10-13 17:31= GMT+01:00 Brian Campbell <bcampbell@pingidentity.com>:
Thanks for the revi= ew, Vladimir. And yes, sender-constrained access tokens should also work in= a token exchange scenario.

On Fri, Oct 13, 2017 a= t 3:18 AM, Vladimir Dzhuvinov <vladimir@connect2id.com> wrote:
=20 =20 =20

Superb! Thanks for putting down everything that was discussed. I read the new version and have zero comments about it.

Will sender-constrained access tokens also work in a token exchange scenario?

(draft-ietf-oauth-token-exchange-09)

Vladimir


On 13/10/17 01:07, Brian Campbell wrote:
I'm pleased to announce that a new draft of "Mutu=
al TLS Profile for OAuth
2.0" has been published. The changes, based on feedback and discussion=
 on
this list over the last two months, are listed below.

   draft-ietf-oauth-mtls-04
<https://tools.ietf.org/html/draft-ietf-oauth-mtls-0=
4>

   o  Change the name of the 'Public Key method' to the more accura=
te
      'Self-Signed Certificate method' and also change the associat=
ed
      authentication method metadata value to
      "self_signed_tls_client_auth".
   o  Removed the "tls_client_auth_root_dn" client metadata field=
 as
      discussed in https://mailarchive.ietf.org/arch/msg/oauth/
<https://mailarchive.ietf.org/arc=
h/msg/oauth/swDV2y0be6o8czGKQi1eJV-g8qc>
      swDV2y0be6o8czGKQi1eJV-g8qc
<https://mailarchive.ietf.org/arch/msg/o=
auth/swDV2y0be6o8czGKQi1eJV-g8qc>
   o  Update draft-ietf-oauth-discovery
<https://tools.ietf.org/html/draft-ietf-oauth-discovery=
> reference to
-07
   o  Clarify that MTLS client authentication isn't exclusive to the
      token endpoint and can be used with other endpoints, e.g.  RFC
<https=
://tools.ietf.org/html/rfc7009>
      7009 <https://tools.ietf.org/html/rfc7009> revocation and 7662
introspection, that utilize client
      authentication as discussed in
      https://mailarchive.ietf.org/arch/msg/oauth/
<https://mailarchive.ietf.org/arch/msg/o=
auth/bZ6mft0G7D3ccebhOxnEYUv4puI>
      bZ6mft0G7D3ccebhOxnEYUv4puI
<https://mailarchive.ietf.org/arch/msg/o=
auth/bZ6mft0G7D3ccebhOxnEYUv4puI>

   o  Reorganize the document somewhat in an attempt to more clearly
      make a distinction between mTLS client authentication and
      certificate bound access tokens as well as a more clear
      delineation between the two (PKI/Public key) methods for client
      authentication
   o  Editorial fixes and clarifications


---------- Forwarded message ----------
From: <int=
ernet-drafts@ietf.org>
Date: Thu, Oct 12, 2017 at 3:50 PM
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-mtls-04.txt
To: i-d-annou=
nce@ietf.org
Cc: oauth@ietf.org



A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Web Authorization Protocol WG of the IETF.

        Title           : Mutual TLS Profile for OAuth 2.0
        Authors         : Brian Campbell
                          John Bradley
                          Nat Sakimura
                          Torsten Lodderstedt
        Filename        : draft-ietf-oauth-mtls-04.txt
        Pages           : 18
        Date            : 2017-10-12

Abstract:
   This document describes Transport Layer Security (TLS) mutual
   authentication using X.509 certificates as a mechanism for OAuth
   client authentication to the authorization sever as well as for
   certificate bound sender constrained access tokens.


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

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-oauth-mtls-04
https://datatracker.ietf.org/doc/html/draft-ietf-oau=
th-mtls-04

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


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
h=
ttps://www.ietf.org/mailman/listinfo/oauth




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


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



CONFI= DENTIALITY NOTICE: This email may contain confidential and privileged mater= ial for the sole use of the intended recipient(s). Any review, use, distrib= ution or disclosure by others is strictly prohibited.=C2=A0 If you have rec= eived this communication in error, please notify the sender immediately by = e-mail and delete the message and any file attachments from your computer. = Thank you.

______________________________<= wbr>_________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


--089e0828b5545b532e055d7713c0-- From nobody Wed Nov 8 07:13:19 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 6CA6F12706D for ; Wed, 8 Nov 2017 07:13:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.913 X-Spam-Level: X-Spam-Status: No, score=0.913 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, FSL_HELO_BARE_IP_2=1.499, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_NUMERIC_HELO=1.164, 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 Q1lwcGdsIxIa for ; Wed, 8 Nov 2017 07:13:16 -0800 (PST) Received: from mail-wm0-x244.google.com (mail-wm0-x244.google.com [IPv6:2a00:1450:400c:c09::244]) (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 935131270A7 for ; Wed, 8 Nov 2017 07:13:16 -0800 (PST) Received: by mail-wm0-x244.google.com with SMTP id b189so11035402wmd.4 for ; Wed, 08 Nov 2017 07:13:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:subject:message-id:from:to:mime-version :content-transfer-encoding; bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=; b=fIl3AxlTRceX3QlWlzUFKHB+11DDAlzj3wjxVkvMBLUzHwQ2Jwe0hhhOGfG+VgecSO t9qhKCDUudSsnnaAfnLO400pIaAYZraiAYsoSvtbxMa4hX3/xWzyn1bgQ/cDzc20kA4D ibiIij0HY/qrsldCEvbAqPcKOYYgVfyrUOgtUdnjLXdg6SruCHu0F002cr+juj9RaYu9 ukQps5RfFn29KhF7mCTjTQZaPUVSkTveKJ1rRbCZsJTHK85lsp2IZVGIrEB5jGoTdxui JRu57NbFNfuzAzDwMKqic12bwlw6bGPHVqBkNSVLyaTCJOzMExYpoFR8rWPq9Y8A7Pqn SGow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:subject:message-id:from:to:mime-version :content-transfer-encoding; bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=; b=qvkcNrBmXoDMeJUz9ABpXMx1KhlNGTmBbCvelmctyH0G51PahNVpv++5oUDMPCTvms z/XOMWES4G0ECfxz00VTX2dIa1YORYLgHwO1pzJFD8lVPoBDaRqOe0o5XmtgUlgDEQD9 ut1uymgL9nAADyizX5L3Ix9lmqiVgS0AlqHVxfBLMqWOEfp55ke6dlrHbBkWN+vMiVuT QvUhAKEKvv5OBByBRRr1s/noQTbG2qmFhyFWDPYkPSDjolWtnPqOc0Lx5p1h93s2FAAd WhwoH324141500SwymF13S7QDVs/fGttEAAffUDu/AIUmy62UudVMSx7WPPPRG5BCY5J kVug== X-Gm-Message-State: AJaThX4QR0AKCK6slOKsflGYeyTuc9eCIgnLG8bHMw7quqgZNjyNB8Tc pNscvikQi+R+DDhnEXHtFieqlXtFHw== X-Google-Smtp-Source: ABhQp+R5EOJl1zzt8Zq+edTuD3DQvmk2pTbJH8PhOWAIRV9E1aTI/QWCf1m+dlLRWsBoxvpXdyDYcQ== X-Received: by 10.80.182.118 with SMTP id c51mr1115828ede.204.1510153994860; Wed, 08 Nov 2017 07:13:14 -0800 (PST) Received: from 41.81.216.153 ([41.81.216.153]) by smtp.gmail.com with ESMTPSA id p91sm3838191edp.69.2017.11.08.07.12.56 for (version=TLS1 cipher=AES128-SHA bits=128/128); Wed, 08 Nov 2017 07:13:14 -0800 (PST) Date: Wed, 08 Nov 2017 18:12:27 +0300 Message-ID: From: awelmama64@gmail.com To: OAuth@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Subject: [OAUTH-WG] Make on google accaunt 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, 08 Nov 2017 15:13:17 -0000 From nobody Wed Nov 8 12:42:47 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 8A93F12957F for ; Wed, 8 Nov 2017 12:42:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 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_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 0j_P5qk9xS8F for ; Wed, 8 Nov 2017 12:42:41 -0800 (PST) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::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 BA956126579 for ; Wed, 8 Nov 2017 12:42:41 -0800 (PST) Received: by mail-it0-x234.google.com with SMTP id p138so8497390itp.2 for ; Wed, 08 Nov 2017 12:42:41 -0800 (PST) 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=laeZ77d06FxpnXiVTPI/PquaH8VmldQDFjhb70TiMao=; b=heYLfZ6jeNGWXvXcRCxvi0WB1A6HV3dyNMuxfpvUzlbQX0eMD+qP0D3jtO+nPxUwR6 BqKyLwetoj0PbJYtcRco4+RWIBLBKkfTXnyV5XH5uyFDBoTVU5F46WfCnuq8HOGKGVpe Ay6gRTh4BLTeExvX1/5NtmKvuj1VSvm93PA0c= 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=laeZ77d06FxpnXiVTPI/PquaH8VmldQDFjhb70TiMao=; b=ElcNHFH55+ebdso69nTdRwdYnd/o0EjKrxzVbSb7dfkTPkEGQTZidIEr2R1qTXmn+8 2ta+5i0sCVLU7M3FL22rKxywGvj9AnLtoIhOjMQV3VaW3q0DU1F275yfiUJjklMHJFc6 ciRKfOcPJ9fBo5j/mgx2ZUKZ4fUWZXLIMSeq5BgoAnkOtYCE60edPlgB/Y1F8gf6Bevl bEt4lPSi+6sYzvICYOr42ZWbBw6sICMWrIm/Quf57PgJtbcr4DtpJe2FQsd2535WFp37 JGRFTfnslhsoQmmyAIR8bjknvJCcN2z81kzZWS8q8O2UgckcGOENlKyo5Xt95Cg986QD 0fWA== X-Gm-Message-State: AJaThX7NoVbOKRcLMFHDH1FaalJvuY+6v2q3ThoucT0jgiCGJ3gkErsl Hn/pi4dxlPx6a/QRR6zNn5Intc8rO6F3oKmjj2ig7MmX/QFczi+g6kTuNaCcD/Unq049dzs+gmm enAdYA7niRT8DlA== X-Google-Smtp-Source: ABhQp+R1ke0KY+GinrCl8wb/7rZU7rimZmf7EVOyE6KLp0cLf/heo+2OO2GFxjVlPs3AbEjv8e4WvuH5IneNLy1zFS8= X-Received: by 10.36.23.215 with SMTP id 206mr2383533ith.62.1510173760921; Wed, 08 Nov 2017 12:42:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.2.106.34 with HTTP; Wed, 8 Nov 2017 12:42:10 -0800 (PST) In-Reply-To: References: <150784500346.16836.10053591552617872796@ietfa.amsl.com> <83c305ab-4c3b-b16e-1385-7e0e3af6a556@connect2id.com> From: Brian Campbell Date: Wed, 8 Nov 2017 13:42:10 -0700 Message-ID: To: Takahiko Kawasaki Cc: oauth Content-Type: multipart/alternative; boundary="001a114376ee91bdd7055d7eba1c" Archived-At: Subject: Re: [OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-mtls-04.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, 08 Nov 2017 20:42:44 -0000 --001a114376ee91bdd7055d7eba1c Content-Type: text/plain; charset="UTF-8" Thank you for the review and comments, Takahiko. I've made all the editorial fixes in the github working copy so they will be in the next draft. I'll plan to publish that when the publication window opens again. There is no special reason for the "mutual_tls_sender_constrained_access_tokens" name that I'm aware of. I believe Torsten chose the name and based it off of language in the draft. While "certificate_bound_access_tokens" does sound somewhat more natural, I'm hesitant to change it at this point. Unless there's support/consensus from the WG to make the change? Section 6 of The OAuth 2.0 Authorization Framework / RFC 6749 requires that refresh tokens be bound to the client to which they are issued. That indirectly binds the refresh token to the client credentials, which would be a certificate in the case of Mutual TLS OAuth Client Authentication. So I don't believe any additional treatment of refresh tokens is needed in the draft. On Wed, Nov 8, 2017 at 4:34 AM, Takahiko Kawasaki wrote: > Dear Brian, > > I'd like to make some small comments. > > 2. / 1st paragraph / 4th line > "for client authentications" --> "for client authentication" > (remove 's' at the end) > > 2.1.1. / 1st paragraph / 4th line > "used to indicated" -> "used to indicate" > (remove 'd' at the end) > > 2.2. / 1st paragraph / 3rd line > "a X.509 certificate" -> "an X.509 certificate" > (replace "a" with "an") > > 2.2. / 1st paragraph / 11th line > "info of one the" -> "info of one of the" > (insert "of" between "one" and "the") > > 2.2. / 1st paragraph / 17th line > "directly with at the" -> "directly at the" > (remove "with") > > 2.2.1. / 1st paragraph / 4th line > "used to indicated" -> "used to indicate" > (remove 'd' at the end) > > 3.1. / 1st paragraph / 1st line > "as a JSON Web Tokens" -> "as JSON Web Tokens" > (remove 'a') > > 3.1. / 2nd paragraph / 6th-7th lines > "are also sometimes also" -> "are sometimes also" > (remove one "also") > > 3.3. & 3.4. > After reading the specification, for me, "certificate_bound_access_tokens" > sounds more natural than "mutual_tls_sender_constrained_access_tokens". > Is there any special reason for the parameter name? > > 4.3. / 1st paragraph / 1st line > "allows for the use" -> "allows use" > (remove "for the", but I'm not sure because I'm not a native English > speaker.) > > 6.1. / 1st paragraph / 2nd line > "it is latest" -> "it is the latest" > (insert "the" between "is" and "latest") > > By the way, isn't it necessary to define rules for REFRESH tokens? For > example, "if a refresh token is issued, it MUST/SHOULD/MAY be also bound to > the same certificate. When the token endpoint of the authorization server > receives a refresh token request with a certificate-bound refresh token, > ..." > > Best Regards, > Taka > > > 2017-10-13 17:31 GMT+01:00 Brian Campbell : > >> Thanks for the review, Vladimir. And yes, sender-constrained access >> tokens should also work in a token exchange scenario. >> >> On Fri, Oct 13, 2017 at 3:18 AM, Vladimir Dzhuvinov < >> vladimir@connect2id.com> wrote: >> >>> Superb! Thanks for putting down everything that was discussed. I read >>> the new version and have zero comments about it. >>> >>> Will sender-constrained access tokens also work in a token exchange >>> scenario? >>> >>> (draft-ietf-oauth-token-exchange-09) >>> >>> Vladimir >>> >>> On 13/10/17 01:07, Brian Campbell wrote: >>> >>> I'm pleased to announce that a new draft of "Mutual TLS Profile for OAuth >>> 2.0" has been published. The changes, based on feedback and discussion on >>> this list over the last two months, are listed below. >>> >>> draft-ietf-oauth-mtls-04 >>> >>> o Change the name of the 'Public Key method' to the more accurate >>> 'Self-Signed Certificate method' and also change the associated >>> authentication method metadata value to >>> "self_signed_tls_client_auth". >>> o Removed the "tls_client_auth_root_dn" client metadata field as >>> discussed in https://mailarchive.ietf.org/arch/msg/oauth/ >>> swDV2y0be6o8czGKQi1eJV-g8qc >>> o Update draft-ietf-oauth-discovery reference to >>> -07 >>> o Clarify that MTLS client authentication isn't exclusive to the >>> token endpoint and can be used with other endpoints, e.g. RFC >>> 7009 revocation and 7662 >>> introspection, that utilize client >>> authentication as discussed in >>> https://mailarchive.ietf.org/arch/msg/oauth/ >>> bZ6mft0G7D3ccebhOxnEYUv4puI >>> >>> o Reorganize the document somewhat in an attempt to more clearly >>> make a distinction between mTLS client authentication and >>> certificate bound access tokens as well as a more clear >>> delineation between the two (PKI/Public key) methods for client >>> authentication >>> o Editorial fixes and clarifications >>> >>> >>> ---------- Forwarded message ---------- >>> From: >>> Date: Thu, Oct 12, 2017 at 3:50 PM >>> Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-mtls-04.txt >>> To: i-d-announce@ietf.org >>> Cc: oauth@ietf.org >>> >>> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the Web Authorization Protocol WG of the IETF. >>> >>> Title : Mutual TLS Profile for OAuth 2.0 >>> Authors : Brian Campbell >>> John Bradley >>> Nat Sakimura >>> Torsten Lodderstedt >>> Filename : draft-ietf-oauth-mtls-04.txt >>> Pages : 18 >>> Date : 2017-10-12 >>> >>> Abstract: >>> This document describes Transport Layer Security (TLS) mutual >>> authentication using X.509 certificates as a mechanism for OAuth >>> client authentication to the authorization sever as well as for >>> certificate bound sender constrained access tokens. >>> >>> >>> The IETF datatracker status page for this draft is:https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/ >>> >>> There are also htmlized versions available at:https://tools.ietf.org/html/draft-ietf-oauth-mtls-04https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-04 >>> >>> A diff from the previous version is available at:https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-mtls-04 >>> >>> >>> 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 listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> >>> _______________________________________________ >>> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >> >> *CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly prohibited. >> If you have received this communication in error, please notify the sender >> immediately by e-mail and delete the message and any file attachments from >> your computer. Thank you.* >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > -- *CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.* --001a114376ee91bdd7055d7eba1c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you for the review and comments, Taka= hiko.

I've made all the editorial fixes in the github work= ing copy so they will be in the next draft. I'll plan to publish that w= hen the publication window opens again.

There is no special r= eason for the "mutual_tls_sender_constrained_access_tokens" = name that I'm aware of. I believe Torsten chose the name and based it o= ff of language in the draft. While "certificate_bound_access_toke= ns" does sound somewhat more natural, I'm hesitant to change it at= this point. Unless there's support/consensus from the WG to make the c= hange?

Section 6 of The OAuth 2.0 Authorization Framework / RF= C 6749 requires that refresh tokens be bound to the client to which they ar= e issued. That indirectly binds the refresh token to the client credentials= , which would be a certificate in the case of Mutual TLS OAuth Client Authe= ntication. So I don't believe any additional treatment of refresh token= s is needed in the draft.



On Wed, Nov 8, 2017 at 4:34 AM, Takahiko = Kawasaki <daru.tk@gmail.com> wrote:
Dear Brian,

I'd like to = make some small comments.

2. / 1st paragraph = / 4th line
"for client authentications" --> "fo= r client authentication"
(remove 's' at the end)

2.1.1. / 1st paragraph / 4th line
"use= d to indicated" -> "used to indicate"
(remove &= #39;d' at the end)

2.2. / 1st paragraph / 3rd = line
"a X.509 certificate" -> "an X.509 certifi= cate"
(replace "a" with "an")
=
2.2. / 1st paragraph / 11th line
"info of one= the" -> "info of one of the"
(insert "of&= quot; between "one" and "the")

2.2. / 1st paragraph / 17th line
"directly with at the"= ; -> "directly at the"
(remove "with")

2.2.1. / 1st paragraph / 4th line
"use= d to indicated" -> "used to indicate"
(remove &= #39;d' at the end)

3.1. / 1st paragraph / 1st = line
"as a JSON Web Tokens" -> "as JSON Web Tok= ens"
(remove 'a')

3.1. / 2n= d paragraph / 6th-7th lines
"are also sometimes also" -= > "are sometimes also"
(remove one "also")=

3.3. & 3.4.
After reading the speci= fication, for me, "certificate_bound_access_tokens" sounds m= ore natural than "mutual_tls_sender_constrained_access_tokens&quo= t;. Is there any special reason for the parameter name?

4.3. / 1st paragraph / 1st line
"allows for the use&qu= ot; -> "allows use"
(remove "for the", but= I'm not sure because I'm not a native English speaker.)
=
6.1. / 1st paragraph / 2nd line
"it is latest= " -> "it is the latest"
(insert "the"= between "is" and "latest")

By= the way, isn't it necessary to define rules for REFRESH tokens? For ex= ample, "if a refresh token is issued, it MUST/SHOULD/MAY be also bound= to the same certificate. When the token endpoint of the authorization serv= er receives a refresh token request with a certificate-bound refresh token,= ..."

Best Regards,
Taka


2017-10-13 17:31 GMT+01:00 Brian Campbell <bcampbell@pingidentity.com>:
Thanks for the = review, Vladimir. And yes, sender-constrained access tokens should also wor= k in a token exchange scenario.

On Fri, Oct 13, 2017 at 3:18 AM, Vladimir Dzhuvinov <vladimir@connect2id.com> wrote:
=20 =20 =20

Superb! Thanks for putting down everything that was discussed. I read the new version and have zero comments about it.

Will sender-constrained access tokens also work in a token exchange scenario?

(draft-ietf-oauth-token-exchange-09)

Vladimir


On 13/10/17 01:07, Brian Campbell wrote:
I'm pleased to announce that a new draft of "Mutu=
al TLS Profile for OAuth
2.0" has been published. The changes, based on feedback and discussion=
 on
this list over the last two months, are listed below.

   draft-ietf-oauth-mtls-04
<https://tools.ietf.org/html/dr=
aft-ietf-oauth-mtls-04>

   o  Change the name of the 'Public Key method' to the more accura=
te
      'Self-Signed Certificate method' and also change the associat=
ed
      authentication method metadata value to
      "self_signed_tls_client_auth".
   o  Removed the "tls_client_auth_root_dn" client metadata field=
 as
      discussed in https://mailarchive.ietf.org/a=
rch/msg/oauth/
<https://mailarch=
ive.ietf.org/arch/msg/oauth/swDV2y0be6o8czGKQi1eJV-g8qc>
      swDV2y0be6o8czGKQi1eJV-g8qc
<https://mailarchive.iet=
f.org/arch/msg/oauth/swDV2y0be6o8czGKQi1eJV-g8qc>
   o  Update draft-ietf-oauth-discovery
<https://tools.ietf.org/html/draft-i=
etf-oauth-discovery> reference to
-07
   o  Clarify that MTLS client authentication isn't exclusive to the
      token endpoint and can be used with other endpoints, e.g.  RFC
<https://tools.ietf.org/html/rfc7009>
      7009 <https://tools.ietf.org/html/rfc7009>=
 revocation and 7662
introspection, that utilize client
      authentication as discussed in
      https://mailarchive.ietf.org/arch/msg/oauth=
/
<https://mailarchive.iet=
f.org/arch/msg/oauth/bZ6mft0G7D3ccebhOxnEYUv4puI>
      bZ6mft0G7D3ccebhOxnEYUv4puI
<https://mailarchive.iet=
f.org/arch/msg/oauth/bZ6mft0G7D3ccebhOxnEYUv4puI>

   o  Reorganize the document somewhat in an attempt to more clearly
      make a distinction between mTLS client authentication and
      certificate bound access tokens as well as a more clear
      delineation between the two (PKI/Public key) methods for client
      authentication
   o  Editorial fixes and clarifications


---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Thu, Oct 12, 2017 at 3:50 PM
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-mtls-04.txt
To: i-d-announce@ietf.org
Cc: oauth@ietf.org



A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Web Authorization Protocol WG of the IETF.

        Title           : Mutual TLS Profile for OAuth 2.0
        Authors         : Brian Campbell
                          John Bradley
                          Nat Sakimura
                          Torsten Lodderstedt
        Filename        : draft-ietf-oauth-mtls-04.txt
        Pages           : 18
        Date            : 2017-10-12

Abstract:
   This document describes Transport Layer Security (TLS) mutual
   authentication using X.509 certificates as a mechanism for OAuth
   client authentication to the authorization sever as well as for
   certificate bound sender constrained access tokens.


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

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-oa=
uth-mtls-04
https://datatracker.ietf.org/do=
c/html/draft-ietf-oauth-mtls-04

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


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




_______________________________________________
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



CONFIDENT= IALITY NOTICE: This email may contain confidential and privileged material = for the sole use of the intended recipient(s). Any review, use, distributio= n or disclosure by others is strictly prohibited.=C2=A0 If you have receive= d this communication in error, please notify the sender immediately by e-ma= il and delete the message and any file attachments from your computer. Than= k you.

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




<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --001a114376ee91bdd7055d7eba1c-- From nobody Sat Nov 11 19:55: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 9E929127078 for ; Sat, 11 Nov 2017 19:55:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 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_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 u_udDTf799MQ for ; Sat, 11 Nov 2017 19:55:11 -0800 (PST) Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.31.99]) (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 E39FD120721 for ; Sat, 11 Nov 2017 19:55:10 -0800 (PST) Received: from [42.61.210.59] (helo=[10.10.4.143]) by smtprelay05.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1eDjMR-0001Ub-SV; Sun, 12 Nov 2017 04:55:08 +0100 From: Torsten Lodderstedt Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_E02C8707-42B2-471D-A1A9-BB73C72A1767"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Sun, 12 Nov 2017 11:55:04 +0800 In-Reply-To: Cc: Takahiko Kawasaki , oauth To: Brian Campbell References: <150784500346.16836.10053591552617872796@ietfa.amsl.com> <83c305ab-4c3b-b16e-1385-7e0e3af6a556@connect2id.com> X-Mailer: Apple Mail (2.3273) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-mtls-04.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: Sun, 12 Nov 2017 03:55:14 -0000 --Apple-Mail=_E02C8707-42B2-471D-A1A9-BB73C72A1767 Content-Type: multipart/alternative; boundary="Apple-Mail=_3936CC32-66A5-4AD9-A7AB-685CD79703E1" --Apple-Mail=_3936CC32-66A5-4AD9-A7AB-685CD79703E1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > Am 09.11.2017 um 04:42 schrieb Brian Campbell = : >=20 > There is no special reason for the = "mutual_tls_sender_constrained_access_tokens" name that I'm aware of. I = believe Torsten chose the name and based it off of language in the = draft. While "certificate_bound_access_tokens" does sound somewhat more = natural, I'm hesitant to change it at this point. Unless there's = support/consensus from the WG to make the change? I choose =E2=80=9Esender" because this is the terminology John and I use = in = https://tools.ietf.org/html/draft-ietf-oauth-security-topics-03#section-4.= 4.1.2 = to describe a certain kind of mechanisms for token phishing = prevention. I=E2=80=99m fine with using =E2=80=9Ecertificate=E2=80=9C = instead of =E2=80=9Esender=E2=80=9C in this spec as the more precise = term. I feel we need to keep a suitable prefix to indicate the = connection to mutual tls or tls client auth, respectively, but I=E2=80=99m= not bound to it. --Apple-Mail=_3936CC32-66A5-4AD9-A7AB-685CD79703E1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Am 09.11.2017 um 04:42 schrieb Brian Campbell <bcampbell@pingidentity.com>:

There is no special reason for = the "mutual_tls_sender_constrained_access_tokens" name that I'm = aware of. I believe Torsten chose the name and based it off of language = in the draft. While "certificate_bound_access_tokens" does sound somewhat more natural, I'm = hesitant to change it at this point. Unless there's support/consensus = from the WG to make the change?

I choose =E2=80=9Esender" because this is the = terminology John and I use in https://tools.ietf.org/html/draft-ietf-oauth-security-topics-03= #section-4.4.1.2 to describe a certain kind of mechanisms for = token phishing prevention. I=E2=80=99m fine with using =E2=80=9Ecertificat= e=E2=80=9C instead of =E2=80=9Esender=E2=80=9C in this spec as the more = precise term. I feel we need to keep a suitable prefix to indicate the = connection to mutual tls or tls client auth, respectively, but I=E2=80=99m= not bound to it.


= --Apple-Mail=_3936CC32-66A5-4AD9-A7AB-685CD79703E1-- --Apple-Mail=_E02C8707-42B2-471D-A1A9-BB73C72A1767 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 CQUxDxcNMTcxMTEyMDM1NTA0WjAjBgkqhkiG9w0BCQQxFgQUOuJpW8FyBbPOCox0GBT+JhUSlKww gcEGCSsGAQQBgjcQBDGBszCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/ BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVt YWlsIENBAhAz25rGqsI3mWtz8QN7mfC0MIHDBgsqhkiG9w0BCRACCzGBs6CBsDCBmzELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBB dXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAz25rGqsI3mWtz8QN7mfC0MA0GCSqG SIb3DQEBAQUABIIBAKMPsbhQN1OjQeF2cAkVk9ped0ucU3bctdkro5bR1Iddd3Mhx7JjMSRnvgRm ptmHk7w8WG839fxuuJKU5lkPPpGwQRaY9hQEQ2avJ+eNmLOTPg1rVCJ/uGDqf7BB0CNISTGdyCCq teSPiHPxLTArdHn2BGhtCLuGvvZWyfwbvLY2jVxZNov2XCMuIJHA6fy+HT8mVGwjUzR5Sa+l70HW qSx4fbKFpdHCW+vizB8zl6Z3DkT6aaCpg5AqLThnWO6TmUGGCK8kCrWs/jK6fX7gB5KjChl04Fuq +XNbEVbXKaN6kTzyoH+Hv96YwOmYRUm+c0oEekDuDhbXLM36W6IRzZ4AAAAAAAA= --Apple-Mail=_E02C8707-42B2-471D-A1A9-BB73C72A1767-- From nobody Sun Nov 12 15:00: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 43F1F1200B9; Sun, 12 Nov 2017 15:00:11 -0800 (PST) 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.65.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151052761123.21482.65164674747418292@ietfa.amsl.com> Date: Sun, 12 Nov 2017 15:00:11 -0800 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-mtls-05.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: Sun, 12 Nov 2017 23:00:11 -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 WG of the IETF. Title : Mutual TLS Profile for OAuth 2.0 Authors : Brian Campbell John Bradley Nat Sakimura Torsten Lodderstedt Filename : draft-ietf-oauth-mtls-05.txt Pages : 18 Date : 2017-11-12 Abstract: This document describes Transport Layer Security (TLS) mutual authentication using X.509 certificates as a mechanism for OAuth client authentication to the authorization sever as well as for certificate bound sender constrained access tokens. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-mtls-05 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-mtls-05 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 Sun Nov 12 15:08: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 2CE871205F1 for ; Sun, 12 Nov 2017 15:08:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 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_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 eyUo6f2QxKyu for ; Sun, 12 Nov 2017 15:08:47 -0800 (PST) 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 6E8171200B9 for ; Sun, 12 Nov 2017 15:08:47 -0800 (PST) Received: by mail-it0-x236.google.com with SMTP id b5so1017499itc.3 for ; Sun, 12 Nov 2017 15:08:47 -0800 (PST) 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=bHlGLoaNrddLrRDKUFHcKS77wuUwjh/ZzUUIzrnVzFI=; b=Q8hLt/d5KHjFoZoUC/Lr0NqC/y5Q5bZcblyhWw7HMoDlmXoBO0z38YD4Xw1PSl66r9 e6S0cbY75zIcFmKcOiTyaznxA32w9AqZGWNdIbasjjQhAkmac3WXmz3AjDPhFLe7RXBk XkiLMBTjwuAgRhHSLPaG+Up6tjkyk33PGZQi8= 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=bHlGLoaNrddLrRDKUFHcKS77wuUwjh/ZzUUIzrnVzFI=; b=iKJIiE7GoznSYg6WCzn9cZAJDnXuywuELfmVPyhUXZuVwblQhEcGQw8BfX0MLNzQ3i cX3CgsVocP2DN35Mbm8/Mt+1SsXneQTeZs6bHXFVpGZB0yX4o6ONPWNYajY+eeQGdG0/ Sak76GZ1C7uG7giQmpZDVP90G42K2ZrMMrP6zAJDGMGMBXODAnbvn60uYBnPduMW4aQH NopdmYPbSD7ugEd5mdSuO1xGbjsxDUIrsLWQizO6AvSsfUTSIQtlFJfeCFubQ3smBj8M q6c6lqgQu2RyX7VRl4+QmU1ElX/kTPjIGKy08EgrCbqVy6k4Q0J8z6BkVEYXdKGjFCQd Au+g== X-Gm-Message-State: AJaThX6o/HfmiO8eHtH45JS1p130PHgP5COV5jmnwewgh9v70dTsV4Mb bK3li2RwVAn9RwE5doMafgdD1J2jTGAECaccLoTJfgUQTbUhZiQLz99OkO59ZcXPWLzCqKCp8k4 mOCwe2vOk0QmO751l X-Google-Smtp-Source: AGs4zMbIbKl57iPV13QUObU94Js7xKrWZ4ia11RchWnEV6HGHnYL/5PE++W6vUtRzmDGayU5stmZ3dUnoHASVa8/M8I= X-Received: by 10.36.215.3 with SMTP id y3mr8145437itg.22.1510528126427; Sun, 12 Nov 2017 15:08:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.2.106.34 with HTTP; Sun, 12 Nov 2017 15:08:15 -0800 (PST) In-Reply-To: <151052761123.21482.65164674747418292@ietfa.amsl.com> References: <151052761123.21482.65164674747418292@ietfa.amsl.com> From: Brian Campbell Date: Mon, 13 Nov 2017 07:08:15 +0800 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="94eb2c0b1b84663ddf055dd13c46" Archived-At: Subject: [OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-mtls-05.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: Sun, 12 Nov 2017 23:08:49 -0000 --94eb2c0b1b84663ddf055dd13c46 Content-Type: text/plain; charset="UTF-8" I've just published draft -05 of the "Mutual TLS Profile for OAuth 2.0" document. The updates in this draft consist only of editorial fixes (thanks Takahiko!). There are no normative changes. ---------- Forwarded message ---------- From: Date: Mon, Nov 13, 2017 at 7:00 AM Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-mtls-05.txt To: i-d-announce@ietf.org Cc: oauth@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol WG of the IETF. Title : Mutual TLS Profile for OAuth 2.0 Authors : Brian Campbell John Bradley Nat Sakimura Torsten Lodderstedt Filename : draft-ietf-oauth-mtls-05.txt Pages : 18 Date : 2017-11-12 Abstract: This document describes Transport Layer Security (TLS) mutual authentication using X.509 certificates as a mechanism for OAuth client authentication to the authorization sever as well as for certificate bound sender constrained access tokens. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-mtls-05 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-mtls-05 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 -- *CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.* --94eb2c0b1b84663ddf055dd13c46 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I've just published draft -05 of th= e "Mutual TLS Profile for OAuth 2.0&= quot; document.

The updates in this draft consist only of editorial = fixes (thanks Takahiko!). There are no normative changes.

---------- Forwarded message ----------
From: <internet-drafts@ietf.org>=
Date: Mon, Nov 13, 2017 at 7:00 AM
Subject: [OAUTH-WG] I-D Action: d= raft-ietf-oauth-mtls-05.txt
To: i-d-announce@ietf.org
Cc: oauth@ietf.org



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 WG of the IETF.=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Mutual TLS Profile for OAuth 2.0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Bria= n Campbell
=C2=A0 =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 =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 Torsten Lodderstedt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-oauth-mtls-05.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 18
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2017-11-12

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 OAu= th
=C2=A0 =C2=A0client authentication to the authorization sever as well as fo= r
=C2=A0 =C2=A0certificate bound sender constrained access tokens.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-i= etf-oauth-mtls/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-oaut= h-mtls-05
https://datatracker.ietf.org/doc/= html/draft-ietf-oauth-mtls-05

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


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


<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --94eb2c0b1b84663ddf055dd13c46-- From nobody Mon Nov 13 06:40: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 39763129439 for ; Mon, 13 Nov 2017 06:40:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, 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 a_F2a4j8FYOQ for ; Mon, 13 Nov 2017 06:40:00 -0800 (PST) Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::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 E6FD0124D37 for ; Mon, 13 Nov 2017 06:39:59 -0800 (PST) Received: by mail-ua0-x231.google.com with SMTP id r11so3914067uah.12 for ; Mon, 13 Nov 2017 06:39:59 -0800 (PST) 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=rINVQ1VeIlSWxdj7TeIdVok/iD6ZnDP0QFu67Z62MXQ=; b=q77m3uzX3XOK4j+prOrNOFoF1SPLOnLkGhnas3/9WDYdrxamt+eBpntWXML5WLNnDZ jMfxubq9Swm/6B4sqbc6CHrrY++4optzTsrM2E7BzICOrAVdNQLRm1Q3hpjKS0TzmyjO HOzYB95i8hI2bRplq34whzR1q1XggGIV0oSn6OPeGiMbR7f9qyQ8LxKZuVZa3joXmq3v UVMhqsSYsGR0m0yqpSDfomQGM3Q36PpOgCMQnIN7n4rWdxF7jtBElSVPycW+0skf6Vkc gptO3YGRLgaUqScoVof9pkyrBxS/+qAIVkke7nCwzjAhLe/N7ghBZPZ+D3uxSo/OkgzN K8qA== 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=rINVQ1VeIlSWxdj7TeIdVok/iD6ZnDP0QFu67Z62MXQ=; b=o9RNMCx7hdqTMQPAUUbUY15Bdxi8JerqUghA15MDrN++CerH2w0KHIp7N5UegbH9Ua g2iXTJB3SR56Jl3aLqDMu+6H4K5wqZ2W+fnuaJifQGzcI8ZxLzheMzyaIXHrhEOuH/5s PtwRI6DaBl6eR871yk59LxL/q8gngovi1nnoBCGylXttLSt9225ovqlmOyZx01Csy44c tI2UgT2RrN4yY+V1/60D9J3Y/rBJ8QJaAHIPy3TQQOsHpIgExksO4qwdGDHOUghv/d+7 7MIYD9QiW3uu0Rd3lGtTg9kMJIup20wXYqlUk316LjhKy967G0fKMqX3AzgudTQVyTiv Sg0w== X-Gm-Message-State: AJaThX7+1+D99wwYDrzkzP0Abq2hbc86B42nnv5p1XVq3AANryEr0GvG DVRlDUyxgzRYZkLReqaCTtxgCMlgMumAawXEB9iXhJwu694= X-Google-Smtp-Source: AGs4zMYaHxLG+u6zqdkohkCFInKcaa/eHjaYe488lOykGIcHN5AASXSFn6ABezbG49lbWMPIN5pj4k/WJUZelXiZ4oA= X-Received: by 10.176.89.81 with SMTP id o17mr7538207uad.12.1510583998862; Mon, 13 Nov 2017 06:39:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.68.162 with HTTP; Mon, 13 Nov 2017 06:39:58 -0800 (PST) From: Rifaat Shekh-Yusef Date: Mon, 13 Nov 2017 22:39:58 +0800 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="001a11465c36a7da71055dde3e58" Archived-At: Subject: [OAUTH-WG] Final Agenda 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, 13 Nov 2017 14:40:01 -0000 --001a11465c36a7da71055dde3e58 Content-Type: text/plain; charset="UTF-8" All, We have just published the final agenda for our two sessions: https://datatracker.ietf.org/doc/agenda-100-oauth/ Regards, Rifaat & Hannes --001a11465c36a7da71055dde3e58 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
All,

We have just published the final a= genda for our two sessions:

Regards,
=C2=A0Rifaat & Hannes
--001a11465c36a7da71055dde3e58-- From nobody Mon Nov 13 22:18: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 4E911126FB3 for ; Mon, 13 Nov 2017 22:18:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 vQRUd30qyLzy for ; Mon, 13 Nov 2017 22:18:38 -0800 (PST) Received: from mail-pg0-x233.google.com (mail-pg0-x233.google.com [IPv6:2607:f8b0:400e:c05::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 793CA124D6C for ; Mon, 13 Nov 2017 22:18:38 -0800 (PST) Received: by mail-pg0-x233.google.com with SMTP id 70so2097318pgf.6 for ; Mon, 13 Nov 2017 22:18:38 -0800 (PST) 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=ubwWnulNamopaJU48Byrs9/QyNS2qucPnAaIajFZF4U=; b=QYHepPB5/hswcbr4OeO7Cy8k0Va3zs7Bzw5X0BPCOpm7YR9RqOCbUAOhdxY4++N9fh E2GcaYdPnF70ijGpeClVtUv2ofHu7u2lsJ3OafVH6r5T1SH0mpnBHYBswuNieUy3Lfyq eGDqQPGrKbi98D8mHom/zXyzdWBUIyriWMOd7dGzLQICkH8oL7h6PVseuqwmO/+td57G Lq0UFeb22rj/fMHWyQ+bHeFXNLO9TDo0F4HmCbsyDs35uzO672swGzG6tn0zjcXoQmVV 9trPZp/o5P8vFOK4gFnq1zQxe+JEORJmSyrCXyWSHPHt7XqiTFpoU48iLLXm8aJ1fYr1 Awng== 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=ubwWnulNamopaJU48Byrs9/QyNS2qucPnAaIajFZF4U=; b=M0tfYCySYM3JWbvR+ulMElsIzxZ6S7JMCTyIJjxtFFgYs4kY1OJ4piIc8Fq65xdbZ5 Hk9PMMWO4EfXwoWMv+jO/xm2m1wSUJ80BjKU4pBislJdBTW+tNaW6nhHUPhFfvpXI5ru 2ZNPxVuJsyPpPku4qa6WVrQnf7mH3/LXspwy6bKBJbYAuXYT7VcG3qQ8DTKWyd2KDgsh FdqgFLTBmyrOS85mIXWaJ5rm0CPL2p6j8Vn6zHFeFSSnTY2/PHbvvCY63I1/Lb9ITXK8 YBbZX1PhvfFjsvtQChQx6F0hzr7ikloMN9J/Seyh48sBkIpEzwEIz/LeCzKLwR5D3t2c J0MQ== X-Gm-Message-State: AJaThX6jQ9ggPK/BvoghZnr1e2U/LPeOf965n3Xmm8KpxvVaabfykGLf 0YhFfZ/FfJnkvWfaAUqq9b11bgN4wlUrdna7omK07Q== X-Google-Smtp-Source: AGs4zMbPZBgO2QHgsBw54dI5jW2v/IQ7PWU8oh053OPB02EUriqXaQoiC+Uyh7E+tm2ibC/eVeB64ogGCMAdRE7TiIM= X-Received: by 10.99.127.85 with SMTP id p21mr11214480pgn.425.1510640317809; Mon, 13 Nov 2017 22:18:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.128.78 with HTTP; Mon, 13 Nov 2017 22:18:17 -0800 (PST) From: Dick Hardt Date: Tue, 14 Nov 2017 14:18:17 +0800 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary="94eb2c1b4bee86d377055deb5b3b" Archived-At: Subject: [OAUTH-WG] updated filenames for IDs 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, 14 Nov 2017 06:18:40 -0000 --94eb2c1b4bee86d377055deb5b3b Content-Type: text/plain; charset="UTF-8" https://datatracker.ietf.org/doc/draft-hardt-oauth-mutual/ https://datatracker.ietf.org/doc/draft-hardt-oauth-distributed/ -- Subscribe to the HARDTWARE mail list to learn about projects I am working on! --94eb2c1b4bee86d377055deb5b3b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


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


--
Subscribe to the HARDTWARE mail list to learn about projects I am wor= king on!
--94eb2c1b4bee86d377055deb5b3b-- From nobody Tue Nov 14 00:44:13 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 07C03126DCA for ; Tue, 14 Nov 2017 00:44:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=sunet-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 eo6WpbYJMJoX for ; Tue, 14 Nov 2017 00:44:07 -0800 (PST) Received: from mail-pg0-x233.google.com (mail-pg0-x233.google.com [IPv6:2607:f8b0:400e:c05::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 71B78127866 for ; Tue, 14 Nov 2017 00:44:06 -0800 (PST) Received: by mail-pg0-x233.google.com with SMTP id t10so13807557pgo.3 for ; Tue, 14 Nov 2017 00:44:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sunet-se.20150623.gappssmtp.com; s=20150623; h=to:from:subject:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=JBFCTE45pxiuGmV9/GLo01J71xLK1r/omereZ1rTJ3g=; b=uOchxGDfzktyWbPRk9jHcXSrabm9kIrfZBKgAUVtNoPdWao2ES5AgIjAie5IL48xBE J61vKwawdezhq11jEOxk9aBPiRyZLDGro+ueWlBbzaFChXHPRtBmc3emRd+WsB7uJHEL rUMo/KlVwEPMwhX3hkKJXPq3p11oSR17J7oKFtW9vzvo3CE4DPYar+zi58DrSFMfn2RL wNhFvFhc8naKGiIZAUIdi640HQm1KXZqC8Oz6SInRepUxnKGdrZqnjWrKUI+ggwJELSB QZENVaM2quLhwaFOS7d5e8ExPB2m3fwJ2X9pyyWzSAau1gEhY0OX5VL3dk+OL+vxjlrf eu/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=JBFCTE45pxiuGmV9/GLo01J71xLK1r/omereZ1rTJ3g=; b=YLFVP6RqDUYelhkPiGQZ+Kpx9qB3caC42ykUHoZWV61pXClF8f2FX+N31QKcL/YRxV tuwEB7VOKprXrqg3wiLXLvvqRPlAgWrw9l5BqS7KIi31322PMFIPmEnzJJBHqrIIgezN Sa5XRFgKV66+OpYKDlt0mHByXJj1rXFOoNj1fnThPhGKtt+jZwYxJIg0HtmotTpArm1u 31D66kV5XX7FnucEPsGo98PejAOYgC+9QbZ4V8CotUBf4U34C/AENOemGIox/N2kVben W2pGxpIBTDwlnHxQSgbJ8WlG0U2mAHQffMaiLR6YCunOxWqaXrd0UG6/Xe7BtuHNzpep t6Pw== X-Gm-Message-State: AJaThX6ZSn4+mS4mb4BQ+d/Eu8u8HqsB42U/kgNPfv6jHPxyYyKk0sXf 90TdKgfbI+vqVwiunKOWSNVPTT1Li04= X-Google-Smtp-Source: AGs4zMarEHwLZNTPnT0cv1cmNZHJAc4tYT9GhXQIWMKbdpJ6S8AxTG+oIH4tAktDyFNI3zO3PjMv7A== X-Received: by 10.84.192.37 with SMTP id b34mr11500431pld.221.1510649045667; Tue, 14 Nov 2017 00:44:05 -0800 (PST) Received: from ?IPv6:2001:67c:370:128:418a:5b2a:53f5:49b? ([2001:67c:370:128:418a:5b2a:53f5:49b]) by smtp.gmail.com with ESMTPSA id 77sm144891pfh.43.2017.11.14.00.44.04 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Nov 2017 00:44:05 -0800 (PST) To: oauth@ietf.org From: Leif Johansson Message-ID: <1bf08c5e-db95-03b5-9c7e-5ee0a6c7eb9e@sunet.se> Date: Tue, 14 Nov 2017 09:44:01 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: [OAUTH-WG] cert spoofing in mtls & short-lived certs 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, 14 Nov 2017 08:44:09 -0000 So I reviewed the security considerations text which basically sais that the server can avoid being spoofed by managing its set of trust anchors. The text is better than nothing. However this lead me to ask another question about the use of SubjectDN as an identifier for the subject in client metadata: don't we expect certificates to be issued as short-term credentials from an STS-like thing? If so the SubjectDN is probably going to change every time the STS gets called (say by including a serial number) and such a SubjectDN probably isn't the best thing to put in client metadata. Would it make sense to make it possible to identify subjects based on (say) SubjectAltName as an alternative for this case? I don't want to hold up the process on this but I'm curious if this has been raised or just overlooked...? Cheers Leif From nobody Tue Nov 14 01:02:45 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 9B9F112008A for ; Tue, 14 Nov 2017 01:02:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 DhwSxhHBnBTY for ; Tue, 14 Nov 2017 01:02:37 -0800 (PST) Received: from mail-pg0-x241.google.com (mail-pg0-x241.google.com [IPv6:2607:f8b0:400e:c05::241]) (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 F02CB120046 for ; Tue, 14 Nov 2017 01:02:36 -0800 (PST) Received: by mail-pg0-x241.google.com with SMTP id s11so9409407pgc.5 for ; Tue, 14 Nov 2017 01:02:36 -0800 (PST) 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=cYm/Nx/F+wKvj8SfoeNOibq4rqAsfc914e+bW7ARh0k=; b=OBKQUTdEGH9cqC/l1pztuqjW2fUF+Lrs0yRrx9szOdsiaGD2hDT55lZ+HVWBIoy0Hi Ot9SyAyLLaRAjLxvrM6NEFo3lNnWdeNAimEzsyyby4roaauR/5hvOhfgb9q30+CPWVIv P72KAbWS54fyTeu4mQVbj3gso8hP6gHr3dW6y+1q0PXV93egsGBre96q89pZ2C7HTfOI Mufqmdxzn3IG9S8I+HI4rvEM235NSe1/kPaAJ/5rMbeMbMNHr0+Qsijcfn9p1UgJ7bzB IxGVdVlTv3+QNzd3YsaVhJdD+8KOVpZeND8QjsUF+s0bD0gbAyJJHSnl4SmGB6FQXHTW Fh1g== 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=cYm/Nx/F+wKvj8SfoeNOibq4rqAsfc914e+bW7ARh0k=; b=gpl3V45CEffDUs3ZeQeR4NeVMbeIQLaJi1rZctCy60cuC8DwhMOHvI167YO8vnBsPC p3hdnP9TOeSwOSL7PsKL8p8VWkPnOnhv0IuxSVFu8q+xtrDXtocHGiQx7zl7VPqTDIto 76/+dV2zJvGAZVgN7SgyzZ+b5WwLbeIGOJBsdbbr+2ckpqY0OMIwUaKrO2nHDjf04Ff5 5P4++pj7rilU6ZppibUEyD/ToWBPOTXqlfc2fxTkvatFLpPvrek27XhAnohkzW6MT8as DN40IPIbNoJveAMfaomGPEOPgmf0LRsh16nJ4zE8CDoJGoxItdnes/AYB02xQuraz96E kkvQ== X-Gm-Message-State: AJaThX69u4LDafbK1cW3UvnBP4Vd2vEb64WYmCQozP0U3wr61bte6SLk GSlSI8eBi6c3UyKrMZAx7T3p7XCiOwPmJtX+0UKTpg== X-Google-Smtp-Source: AGs4zMaWrK0r1cgj1ep8p0UZ7XBKj/JRroFVmdd8HK9C5N4/Eb0SPOj3lAqR1TXtkU6gD2VMQFzMc8j+hwhN6oQJ4uo= X-Received: by 10.98.117.137 with SMTP id q131mr5415256pfc.165.1510650155971; Tue, 14 Nov 2017 01:02:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.190.1 with HTTP; Tue, 14 Nov 2017 01:02:15 -0800 (PST) From: Dick Hardt Date: Tue, 14 Nov 2017 17:02:15 +0800 Message-ID: To: oauth@ietf.org, Mike Jones Content-Type: multipart/alternative; boundary="94eb2c04fe1eed3e12055deda5e9" Archived-At: Subject: [OAUTH-WG] Question on REQUIRED metadata in https://tools.ietf.org/html/draft-ietf-oauth-discovery-07 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, 14 Nov 2017 09:02:39 -0000 --94eb2c04fe1eed3e12055deda5e9 Content-Type: text/plain; charset="UTF-8" I was reviewing https://tools.ietf.org/html/draft-ietf-oauth-discovery-07 and noticed that in https://tools.ietf.org/html/draft-ietf-oauth-discovery-07#section-2 that authorization_endpoint is REQUIRED. I am working on deployments that are two-legged OAuth where there is no authorization_endpoint, but having a discovery document would be super useful. Additionally, in https://tools.ietf.org/html/draft-hardt-oauth-distributed-00, discovery would be useful, but there may not be an authorization_endpoint may not be needed in the authorization server as it is a two legged OAuth flow (ie, there is no user granting permission, the client is requesting an access token to use at resources) Is there a reason why authorization_endpoint is REQUIRED? /Dick --94eb2c04fe1eed3e12055deda5e9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I was reviewing=C2=A0https://tools.ietf.org/html/draft-ietf-oauth-discovery= -07 and noticed that in=C2=A0https://tools.ietf.org/html/draft-iet= f-oauth-discovery-07#section-2 that=C2=A0authorization_endpoint is REQUIRED.

I am working on deplo= yments that are two-legged OAuth where there is no=C2=A0authorization_endpoint, but havin= g a discovery document would be super useful.=C2=A0

Additionally, in=C2=A0https://tools.ie= tf.org/html/draft-hardt-oauth-distributed-00, discovery would be useful= , but there may not be an=C2=A0authorization_endpoint may not be needed in the auth= orization server as it is a two legged OAuth flow (ie, there is no user gra= nting permission, the client is requesting an access token to use at resour= ces)
=
= Is there a reason why=C2=A0authorization_endpoint is REQUIRED?

/Dick

--94eb2c04fe1eed3e12055deda5e9-- From nobody Tue Nov 14 01:04: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 E7F43120046 for ; Tue, 14 Nov 2017 01:04:01 -0800 (PST) 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 ngtsk3t5AnxQ for ; Tue, 14 Nov 2017 01:03:59 -0800 (PST) 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 63CE3128D3E for ; Tue, 14 Nov 2017 01:03:59 -0800 (PST) Received: by mail-it0-x230.google.com with SMTP id m191so12787002itg.2 for ; Tue, 14 Nov 2017 01:03:59 -0800 (PST) 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=IoU084qkf9h94U3rd/KfFjhWuY/LN0houvP7xplXYqA=; b=b/Uayt13jcJ2DM7sygpW42Hut58tHp83fC3znuW8cCuQGpMcmeIFcAjpc2t/iXjE1n ulJwxmLJ0e4oVQBpCWe8kQSuXB8SL999Wglhy9qZYAhP4ijDgp9j0a7V2nf5DLnrGGCo gDkZD7WSJnf428vGOZoeO6YAUMOTbi5Q6hRfA= 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=IoU084qkf9h94U3rd/KfFjhWuY/LN0houvP7xplXYqA=; b=WDQyJUHme0qpCnLXS3+Ln87WrG/ZYUVQX5AjuCrNJZLrAYj4TOOMYS7bClxvarzgEd WM+YsDTi6/gDifaFcgCOPJEAtPnhLmzmmgWCza1Qg7pTs+mIiLwYyVV7J7JEKPOOqEIw 8gp80gTfTr0nU8Sdj6/IRo0i9bMDw20A73MoEdoO5H4Cp3iuaa3b5RjnImipMd4Zzse4 3RisEPtWB5LMh1ufY7QRjC7yM+l9cJYhGoJnruXNvnKYaPqeoSl6mFPal3UVb7lL+tyr /q8WVxe4mPVeV1R98zjx46l7sQOANrNjsSm9aWPxsTg98lNhi4G+7JLPLddl/lcZp7mU TOpQ== X-Gm-Message-State: AJaThX6k0KKMVzEGIRBsT7wxi/4pNifoYZNK7IIEMnBwejbk2ZCN3q9z 3oDQ7nMsnH2ChJ3XwgDAWD5YBh5vN4yRA+OWFYtgSY5HHPn1kPF1XXrjuzWPWrQtJVrt3g1HmFS nmBYzqB6oU9CniA== X-Google-Smtp-Source: AGs4zMYUNAqw8vxh8eaQEWqkDlnNTwe6AuWpoHQVzFPSbuuq2YL/rslvFkptb2ELpa+OxOz9Ki2B+2F+QQIg1JboK10= X-Received: by 10.36.23.215 with SMTP id 206mr13158610ith.62.1510650238651; Tue, 14 Nov 2017 01:03:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.2.106.34 with HTTP; Tue, 14 Nov 2017 01:03:28 -0800 (PST) In-Reply-To: References: <4524B6AF-E350-4D58-8ACC-1554D2506191@oracle.com> From: Brian Campbell Date: Tue, 14 Nov 2017 17:03:28 +0800 Message-ID: To: Mike Jones Cc: "Phil Hunt (IDM)" , "oauth@ietf.org" Content-Type: multipart/alternative; boundary="001a114376eedae66d055dedaaeb" Archived-At: Subject: Re: [OAUTH-WG] JSON Web Token Best Current Practices draft describing Explicit Typing 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, 14 Nov 2017 09:04:02 -0000 --001a114376eedae66d055dedaaeb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Resurrecting the thread that had a request for more guidance around how to use the explicit typing with nested JWTs. As discussed/requested during the WG meeting. On Mon, Jul 17, 2017 at 5:55 PM, Mike Jones wrote: > Good point. I=E2=80=99d had that thought as well at one point but failed= to > express it in the draft. Will do. > > > > -- Mike > > > > *From:* Brian Campbell [mailto:bcampbell@pingidentity.com] > *Sent:* Monday, July 17, 2017 11:53 AM > *To:* Phil Hunt (IDM) > *Cc:* Mike Jones ; oauth@ietf.org > *Subject:* Re: [OAUTH-WG] JSON Web Token Best Current Practices draft > describing Explicit Typing > > > > Could some more guidance be provided around how to use the explicit typin= g > with nested JWTs? > > I'd imagine that the "typ" header should be in the header of the JWT that > is integrity protected by the issuer? > > > > On Tue, Jul 4, 2017 at 9:58 PM, Phil Hunt (IDM) > wrote: > > +1 > > > > Thanks Mike. > > Phil > > > On Jul 4, 2017, at 12:43 PM, Mike Jones > wrote: > > The JWT BCP draft has been updated to describe the use of explicit typing > of JWTs as one of the ways to prevent confusion among different kinds of > JWTs. This is accomplished by including an explicit type for the JWT in > the =E2=80=9Ctyp=E2=80=9D header parameter. For instance, the Security E= vent Token (SET) > specification now uses the =E2=80=9C > application/secevent+jwt=E2=80=9D content type to explicitly type SETs. > > > > The specification is available at: > > - https://tools.ietf.org/html/draft-sheffer-oauth-jwt-bcp-01 > > > > An HTML-formatted version is also available at: > > - http://self-issued.info/docs/draft-sheffer-oauth-jwt-bcp-01.html > > > > -- Mike > > > > P.S. This notice was also posted at http://self-issued.info/?p=3D1714 an= d > as @selfissued . > > _______________________________________________ > 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 > > > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited. > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > --=20 *CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited. If you have= =20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you.* --001a114376eedae66d055dedaaeb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Resurrecting the thread that had a request for more guidan= ce around how to use the explicit typing with nested JWTs. As discussed/req= uested during the WG meeting.

On Mon, Jul 17, 2017 at 5:55 PM, Mike Jones <Mi= chael.Jones@microsoft.com> wrote:

Good point.=C2=A0 I=E2= =80=99d had that thought as well at one point but failed to express it in t= he draft.=C2=A0 Will do.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=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: Brian Campbell [mailto:bcampbell@pingidentity= .com]
Sent: Monday, July 17, 2017 11:53 AM
To: Phil Hunt (IDM) <phil.hunt@oracle.com>
Cc: Mike Jones <Michael.Jones@microsoft.com>; oauth@ietf.org
Subject: Re: [OAUTH-WG] JSON Web Token Best Current Practices draft = describing Explicit Typing

=C2=A0

Could some more guida= nce be provided around how to use the explicit typing with nested JWTs?

I'd imagine that the "typ" header shou= ld be in the header of the JWT that is integrity protected by the issuer?= =C2=A0

=C2=A0

On Tue, Jul 4, 2017 at 9:58 PM, Phil Hunt (IDM) <= phil.hunt@oracle.= com> wrote:

+1

=C2=A0

Thanks Mike.=C2=A0

Phil


On Jul 4, 2017, at 12:43 PM, Mike Jones <Michael.Jones@microsoft.com> wrote= :

The JWT BCP draft has been updated to describe the u= se of explicit typing of JWTs as one of the ways to prevent confusion among= different kinds of JWTs.=C2=A0 This is accomplished by including an explicit type for the JWT in the =E2=80=9Ctyp=E2=80=9D header parameter.=C2= =A0 For instance, the Security Ev= ent Token (SET) specification now uses the =E2=80=9Capplication/secevent+jwt=E2=80=9D c= ontent type to explicitly type SETs.

=C2=A0

The specification is available at:

=C2=A0

An HTML-formatted version is also available at:

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=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

P.S.=C2=A0 This notice was also posted at http://self= -issued.info/?p=3D1714 and as @selfissued.


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

=C2=A0


CONFIDENTIAL= ITY NOTICE: This email may contain confidential and privileged material for= the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibit= ed.=C2=A0 If you have received this communication in error, please notify t= he sender immediately by e-mail and delete the message and any file attachm= ents from your computer. Thank you.



<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --001a114376eedae66d055dedaaeb-- From nobody Tue Nov 14 01:14: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 1E5A7128D0D for ; Tue, 14 Nov 2017 01:14:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.8 X-Spam-Level: X-Spam-Status: No, score=-4.8 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_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 2sv_72FV2FYy for ; Tue, 14 Nov 2017 01:14:25 -0800 (PST) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0136.outbound.protection.outlook.com [104.47.38.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97D36127B31 for ; Tue, 14 Nov 2017 01:14:25 -0800 (PST) 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=G8kIBNCXGgTOKTmz0tHhP5exb8R4zFMZ6I16LZ+KVTY=; b=Gnb6xp8vwcJcpwZLYNXYy1hS32Rl7Dz5ypo9hYRBmI/4B34OSw8ZK0NWppIwfOhJC58xo8XEp45NynPGJZnQjXXJuXPdQ2I6pk5nj7nmeOCQTH2+/n627X6YtpjJ6Tr4cqa0h68AEyyMa3+GqriF32ilWB/j5iuiwy8v9Z6Gy9E= Received: from CY4PR21MB0504.namprd21.prod.outlook.com (10.172.122.14) by CY4PR21MB0757.namprd21.prod.outlook.com (10.173.192.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.260.0; Tue, 14 Nov 2017 09:14:24 +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.20.0260.000; Tue, 14 Nov 2017 09:14:24 +0000 From: Mike Jones To: Dick Hardt , "oauth@ietf.org" Thread-Topic: Question on REQUIRED metadata in https://tools.ietf.org/html/draft-ietf-oauth-discovery-07 Thread-Index: AQHTXSdSmQIDwr6b1kePKtCVWSTRe6MTlccw Date: Tue, 14 Nov 2017 09:14:23 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:67c:370:128:190c:f3cd:4b13:ffc5] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0757; 6:IIZXVcXO9Vas05JdNOEEXeqMtntVhvEIHex3J0C8oY/sL/UwvOjsENyb2hno7aA8ZMsI9aK5ncFvP7Hfah7cgKHJtfXJtXgC3+tsIs8PN5A+EvVIcpInhkmyK5OjUDMy6A4VUZ/7xngs4dddsKYTXLlzVcMptc4QTamN22Ea3RazbWQgiBJLngVF7I8bof27kGtuwe5uBxwMBVZJYl5xnrvAFGtUh7wUQ4BuuJsP8O//OAg2AMflj9GEmb+RKjpkAlR3Ye62xV7C6lqyECpc24sb/R1v4foZDGN72Q+7F/VMcPqMqpEBNPtSzonLGVg7LJs8abpcmlfvY8pvZljxDedCEqMp67GuRX3JIk1nZ2A=; 5:P19I8RfHXqA7MJmBI1RtnfzxB+YDXKAUinSq7K17RasOOT0eQTP8V1yMEzjA3fyhuCjsH8ChfI9WQScshbBJOz4xRCFtnuIRBtStx6nUQIhtfdEz/DudalrLr4U7UCCh1jgsyeF4FM8GOliLWKIMeodASALetWU0Mv7iYz+LI1g=; 24:71kH5HZSz1yuEbWk7ugv/f5lP+iKadwmJ9Qk93/Pq/vr7PbNTYkCW9vZETj0fMoWSb63zs4RAMVSp0qiPck0b1se15On+AwSvhQL0FlgGAc=; 7:9fhFp3STsUT76yQQxJqjcJ3eNve+PVjqp8KY4xAxUzZsjqLroAsIaX2p5n+0jy2o+bemSvJ39gLBlxEpt5euvTMq+EluI4D3F50pMtiap0E5gKLuwjQ1t64mFakdO10RMbL+A3ARwPTDLQ3b95hFC8uOkXWsawTpEKEKpoRxBgZGutDQErlXsAKP4Caf+QNQi/fvpaNcxJvVJvTDTtNMBqp0sWhHkYGvgXbYJBB7J1Wh8ZljcARukaL12n3YgAKW x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: f1d11fee-7c9e-4763-cf92-08d52b4018ff x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(2017052603258); SRVR:CY4PR21MB0757; x-ms-traffictypediagnostic: CY4PR21MB0757: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(89211679590171)(21748063052155)(227612066756510); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(3231022)(100000703101)(100105400095)(6055026)(61426038)(61427038)(6041248)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123562025)(20161123558100)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR21MB0757; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR21MB0757; x-forefront-prvs: 04916EA04C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(376002)(346002)(47760400005)(189002)(199003)(99286004)(966005)(14454004)(97736004)(86362001)(72206003)(316002)(53546010)(77096006)(86612001)(33656002)(19609705001)(68736007)(229853002)(2900100001)(5660300001)(10090500001)(6506006)(551544002)(478600001)(74316002)(110136005)(606006)(6436002)(22452003)(6306002)(230783001)(54896002)(105586002)(2906002)(55016002)(81156014)(7696004)(236005)(3660700001)(2950100002)(7736002)(9686003)(10290500003)(8936002)(81166006)(3280700002)(106356001)(8990500004)(6246003)(25786009)(53936002)(39060400002)(189998001)(6116002)(54356999)(101416001)(8676002)(790700001)(102836003)(76176999)(2501003)(50986999); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0757; H:CY4PR21MB0504.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB05044E0BFE6AE2B5CF88833BF5280CY4PR21MB0504namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: f1d11fee-7c9e-4763-cf92-08d52b4018ff X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Nov 2017 09:14:23.9018 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0757 Archived-At: Subject: Re: [OAUTH-WG] Question on REQUIRED metadata in https://tools.ietf.org/html/draft-ietf-oauth-discovery-07 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, 14 Nov 2017 09:14:28 -0000 --_000_CY4PR21MB05044E0BFE6AE2B5CF88833BF5280CY4PR21MB0504namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 R29vZCBjYXRjaC4gIFRoZSBhdXRob3JpemF0aW9uX2VuZHBvaW50IHNob3VsZCBvbmx5IGJlIHJl cXVpcmVkIGlmIGZsb3dzIGFyZSBzdXBwb3J0ZWQgdGhhdCBuZWVkIGl0LiAgT3VyIG9sZCBmYXZv cml0ZSwgdGhlIFJlc291cmNlIE93bmVyIFBhc3N3b3JkIENyZWRlbnRpYWxzIGZsb3cgZG9lc27i gJl0IHVzZSBpdCwgY29ycmVjdD8gIExpa2V3aXNlLCB0aGUgQ2xpZW50IENyZWRlbnRpYWxzIGZs b3cgZG9lc27igJl0LiAgSeKAmWxsIHBsYW4gdG8gbWFrZSBhcHByb3ByaWF0ZSB1cGRhdGVzIGlu IC0wOC4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIC0tIE1pa2UNCg0KRnJvbTogRGljayBIYXJkdCBbbWFpbHRvOmRpY2suaGFyZHRAZ21h aWwuY29tXQ0KU2VudDogVHVlc2RheSwgTm92ZW1iZXIgMTQsIDIwMTcgNTowMiBQTQ0KVG86IG9h dXRoQGlldGYub3JnOyBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+DQpT dWJqZWN0OiBRdWVzdGlvbiBvbiBSRVFVSVJFRCBtZXRhZGF0YSBpbiBodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1kaXNjb3ZlcnktMDcNCg0KSSB3YXMgcmV2aWV3 aW5nIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLWRpc2NvdmVy eS0wNyBhbmQgbm90aWNlZCB0aGF0IGluIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1pZXRmLW9hdXRoLWRpc2NvdmVyeS0wNyNzZWN0aW9uLTIgdGhhdCBhdXRob3JpemF0aW9uX2Vu ZHBvaW50IGlzIFJFUVVJUkVELg0KDQpJIGFtIHdvcmtpbmcgb24gZGVwbG95bWVudHMgdGhhdCBh cmUgdHdvLWxlZ2dlZCBPQXV0aCB3aGVyZSB0aGVyZSBpcyBubyBhdXRob3JpemF0aW9uX2VuZHBv aW50LCBidXQgaGF2aW5nIGEgZGlzY292ZXJ5IGRvY3VtZW50IHdvdWxkIGJlIHN1cGVyIHVzZWZ1 bC4NCg0KQWRkaXRpb25hbGx5LCBpbiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt aGFyZHQtb2F1dGgtZGlzdHJpYnV0ZWQtMDAsIGRpc2NvdmVyeSB3b3VsZCBiZSB1c2VmdWwsIGJ1 dCB0aGVyZSBtYXkgbm90IGJlIGFuIGF1dGhvcml6YXRpb25fZW5kcG9pbnQgbWF5IG5vdCBiZSBu ZWVkZWQgaW4gdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGFzIGl0IGlzIGEgdHdvIGxlZ2dlZCBP QXV0aCBmbG93IChpZSwgdGhlcmUgaXMgbm8gdXNlciBncmFudGluZyBwZXJtaXNzaW9uLCB0aGUg Y2xpZW50IGlzIHJlcXVlc3RpbmcgYW4gYWNjZXNzIHRva2VuIHRvIHVzZSBhdCByZXNvdXJjZXMp DQoNCklzIHRoZXJlIGEgcmVhc29uIHdoeSBhdXRob3JpemF0aW9uX2VuZHBvaW50IGlzIFJFUVVJ UkVEPw0KDQovRGljaw0KDQo= --_000_CY4PR21MB05044E0BFE6AE2B5CF88833BF5280CY4PR21MB0504namp_ 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 Ci0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6 ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2 OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0t LT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxl Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6IzAwMjA2MCI+R29vZCBjYXRjaC4mbmJzcDsgVGhlIGF1dGhvcml6YXRp b25fZW5kcG9pbnQgc2hvdWxkIG9ubHkgYmUgcmVxdWlyZWQgaWYgZmxvd3MgYXJlIHN1cHBvcnRl ZCB0aGF0IG5lZWQgaXQuJm5ic3A7IE91ciBvbGQgZmF2b3JpdGUsIHRoZSBSZXNvdXJjZSBPd25l ciBQYXNzd29yZCBDcmVkZW50aWFscyBmbG93IGRvZXNu4oCZdCB1c2UgaXQsIGNvcnJlY3Q/Jm5i c3A7IExpa2V3aXNlLCB0aGUgQ2xpZW50DQogQ3JlZGVudGlhbHMgZmxvdyBkb2VzbuKAmXQuJm5i c3A7IEnigJlsbCBwbGFuIHRvIG1ha2UgYXBwcm9wcmlhdGUgdXBkYXRlcyBpbiAtMDguPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y OiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImNvbG9yOiMw MDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8c3BhbiBzdHlsZT0ibXNv LWJvb2ttYXJrOl9NYWlsRW5kQ29tcG9zZSI+PC9zcGFuPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+RnJvbTo8L2I+IERpY2sgSGFyZHQgW21haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbV0gPGJy Pg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIE5vdmVtYmVyIDE0LCAyMDE3IDU6MDIgUE08YnI+DQo8 Yj5Ubzo8L2I+IG9hdXRoQGlldGYub3JnOyBNaWtlIEpvbmVzICZsdDtNaWNoYWVsLkpvbmVzQG1p Y3Jvc29mdC5jb20mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFF1ZXN0aW9uIG9uIFJFUVVJUkVE IG1ldGFkYXRhIGluIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRo LWRpc2NvdmVyeS0wNzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgd2Fz IHJldmlld2luZyZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1pZXRmLW9hdXRoLWRpc2NvdmVyeS0wNyI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWlldGYtb2F1dGgtZGlzY292ZXJ5LTA3PC9hPiBhbmQgbm90aWNlZCB0aGF0IGluJm5ic3A7 PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtZGlz Y292ZXJ5LTA3I3NlY3Rpb24tMiI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWll dGYtb2F1dGgtZGlzY292ZXJ5LTA3I3NlY3Rpb24tMjwvYT4NCiB0aGF0Jm5ic3A7PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6YmxhY2siPmF1dGhvcml6YXRpb25fZW5kcG9pbnQg aXMgUkVRVUlSRUQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjpibGFj ayI+SSBhbSB3b3JraW5nIG9uIGRlcGxveW1lbnRzIHRoYXQgYXJlIHR3by1sZWdnZWQgT0F1dGgg d2hlcmUgdGhlcmUgaXMgbm8mbmJzcDthdXRob3JpemF0aW9uX2VuZHBvaW50LCBidXQgaGF2aW5n IGEgZGlzY292ZXJ5IGRvY3VtZW50IHdvdWxkIGJlIHN1cGVyIHVzZWZ1bC4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOmJsYWNrIj5BZGRpdGlvbmFsbHksIGlu Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWhhcmR0LW9h dXRoLWRpc3RyaWJ1dGVkLTAwIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaGFy ZHQtb2F1dGgtZGlzdHJpYnV0ZWQtMDA8L2E+LCBkaXNjb3Zlcnkgd291bGQgYmUgdXNlZnVsLCBi dXQgdGhlcmUgbWF5DQogbm90IGJlIGFuJm5ic3A7YXV0aG9yaXphdGlvbl9lbmRwb2ludCBtYXkg bm90IGJlIG5lZWRlZCBpbiB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgYXMgaXQgaXMgYSB0d28g bGVnZ2VkIE9BdXRoIGZsb3cgKGllLCB0aGVyZSBpcyBubyB1c2VyIGdyYW50aW5nIHBlcm1pc3Np b24sIHRoZSBjbGllbnQgaXMgcmVxdWVzdGluZyBhbiBhY2Nlc3MgdG9rZW4gdG8gdXNlIGF0IHJl c291cmNlcyk8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOmJsYWNrIj5J cyB0aGVyZSBhIHJlYXNvbiB3aHkmbmJzcDthdXRob3JpemF0aW9uX2VuZHBvaW50IGlzIFJFUVVJ UkVEPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6YmxhY2siPi9EaWNr PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_CY4PR21MB05044E0BFE6AE2B5CF88833BF5280CY4PR21MB0504namp_-- From nobody Tue Nov 14 01:28:15 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 5745D128B4E for ; Tue, 14 Nov 2017 01:28:14 -0800 (PST) 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 4i8ClW9DUcNZ for ; Tue, 14 Nov 2017 01:28:12 -0800 (PST) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::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 1E0B4127078 for ; Tue, 14 Nov 2017 01:28:12 -0800 (PST) Received: by mail-it0-x22e.google.com with SMTP id f187so12864348itb.1 for ; Tue, 14 Nov 2017 01:28:12 -0800 (PST) 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=RJbMBcWFUfsv9F1vT5PKT2j/KmoMYOGej9iU3NANBZ0=; b=ILPD9nmeCGAcURSKZvcjX60szbaQk3CFgR82pCrAqGKFT3EDVgzcUYpRc+52F1ySAF EcxEqePffLKZU5/MFRlEXShwLEbgJLftwllwxyQPx38uQt92bDXEACzCKirHeDaQhokc ELArTbsDhm4+1APq1+wwrfTY7Eikw+hr+hKWo= 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=RJbMBcWFUfsv9F1vT5PKT2j/KmoMYOGej9iU3NANBZ0=; b=U2wDmGqOI2qNlizbP8sUc1Jr/w7ByZg0DPEeyNTQFy4HvngwFu+RWj2bXb3MNz975J 3TGk0GcXwx6KP/OeRX1qTAF9aBcajbeRgkoEImr+MMiU88PIVeDIOC9aKckFmE5hZvrh 7XEJrdf2zTodWACZ4PRwml2thbYuRqycYPtbIeEs7kpA9akMj+DEh3WwGE/bR43T8VQ+ c2ugYvGF8ZExOwlZbKRou93sDXK8JCCIXL8LXHjjtSRCscTZQdKIKB73g8vGuoY5Zcky HKXnNsRGAYkeg4JGVS65UdyZzaGHH/MILBQVoPVjku5R2YIRkQ8WLfKBKgdOa19puZ/O /Kew== X-Gm-Message-State: AJaThX7BIYFK7FRIAEcuj0VpiRxAEMZU8M258eFA2XQ/fM+WnUAPClbo bc01lIQTpdZqSRc3flfL2cLU3K6ZO1HRQkDHLArvSaBnbvRlJ3Vgb4bqfP/cUXTjc//xF5TyQSD GB062OpWAU3oJag== X-Google-Smtp-Source: AGs4zMY0/Mux3zVlBucvX38OCQEz2cfg2KBNbyL2BQZj4mDiLtxVLbb5f1ETOH75VkGvrfTFztcY6V5K5lLDUauinNk= X-Received: by 10.36.104.211 with SMTP id v202mr2204987itb.153.1510651691257; Tue, 14 Nov 2017 01:28:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.2.106.34 with HTTP; Tue, 14 Nov 2017 01:27:40 -0800 (PST) In-Reply-To: <1bf08c5e-db95-03b5-9c7e-5ee0a6c7eb9e@sunet.se> References: <1bf08c5e-db95-03b5-9c7e-5ee0a6c7eb9e@sunet.se> From: Brian Campbell Date: Tue, 14 Nov 2017 17:27:40 +0800 Message-ID: To: Leif Johansson Cc: oauth Content-Type: multipart/alternative; boundary="001a1143fb3e6feddb055dee01db" Archived-At: Subject: Re: [OAUTH-WG] cert spoofing in mtls & short-lived certs 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, 14 Nov 2017 09:28:14 -0000 --001a1143fb3e6feddb055dee01db Content-Type: text/plain; charset="UTF-8" The expectation/assumption is that the SubjectDN would be a stable identifier through re-issuance of certificates, regardless of whether they be short or long term. We've had basically this as a product feature for years and use of the SubjectDN as the identifier hasn't been an issue. And it's not been raised, that I'm aware of anyway, as a concern in the banking use-cases where there will be some central entity issuing these certificates to the participants. Not sure if that exactly addresses your question but that's how things got the way they are in the document. If there's some better or additional text you'd like to see for the security considerations, please do suggest it. On Tue, Nov 14, 2017 at 4:44 PM, Leif Johansson wrote: > > So I reviewed the security considerations text which basically sais > that the server can avoid being spoofed by managing its set of trust > anchors. The text is better than nothing. > > However this lead me to ask another question about the use of > SubjectDN as an identifier for the subject in client metadata: don't > we expect certificates to be issued as short-term credentials from > an STS-like thing? > > If so the SubjectDN is probably going to change every time the STS > gets called (say by including a serial number) and such a SubjectDN > probably isn't the best thing to put in client metadata. > > Would it make sense to make it possible to identify subjects based > on (say) SubjectAltName as an alternative for this case? > > I don't want to hold up the process on this but I'm curious if this > has been raised or just overlooked...? > > Cheers Leif > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- *CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.* --001a1143fb3e6feddb055dee01db Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The expectation/assumption is that the SubjectDN woul= d be a stable identifier through re-issuance of certificates, regardless of= whether they be short or long term. We've had basically this as a prod= uct feature for years and use of the SubjectDN as the identifier hasn't= been an issue. And it's not been raised, that I'm aware of anyway,= as a concern in the banking use-cases where there will be some central ent= ity issuing these certificates to the participants. Not sure if that exactl= y addresses your question but that's how things got the way they are in= the document.

If there's some better or additional= text you'd like to see for the security considerations, please do sugg= est it.

On Tue, Nov 14, 2017 at 4:44 PM, Leif Johansson <leifj@sunet.se> wrote:

So I reviewed the security considerations text which basically sais
that the server can avoid being spoofed by managing its set of trust
anchors. The text is better than nothing.

However this lead me to ask another question about the use of
SubjectDN as an identifier for the subject in client metadata: don't we expect certificates to be issued as short-term credentials from
an STS-like thing?

If so the SubjectDN is probably going to change every time the STS
gets called (say by including a serial number) and such a SubjectDN
probably isn't the best thing to put in client metadata.

Would it make sense to make it possible to identify subjects based
on (say) SubjectAltName as an alternative for this case?

I don't want to hold up the process on this but I'm curious if this=
has been raised or just overlooked...?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Cheers Leif

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


<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --001a1143fb3e6feddb055dee01db-- From nobody Tue Nov 14 02:12:51 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 DBA18126B6E for ; Tue, 14 Nov 2017 02:12:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 ul7ItEruiPiC for ; Tue, 14 Nov 2017 02:12:48 -0800 (PST) Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::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 4A4EB124B09 for ; Tue, 14 Nov 2017 02:12:48 -0800 (PST) Received: by mail-pf0-x234.google.com with SMTP id i15so3753193pfa.3 for ; Tue, 14 Nov 2017 02:12:48 -0800 (PST) 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=rxGrOaS74Gt6IVZuo2kSpR21mYjFb4GrS5UFrdyRLTA=; b=hS+SjLpiEYF2V3lahk8HBNXSZECjHh3OuoofO17yn7k8Vstw0OeCQ55x4Xs0fyAjQJ qMcmJvEWbSF93b57lXwDV6Lq7ri9EnyLdYLVoy9xf+JtpOxYWQZnstNhNiGlot+ZKesX wesPJVwHXTEcM20WrlmR8/haddpSU8rLA2eYL7c/QK8QWJScqfNsK3CPeggdkvvM6BIF nimYB6xS9+89vLS9zfyzI/qyJMxeCifiDthemCnT6N3ao9zVzT/q9SGpYgKrAmdLmfaz w9bLZbQtcRd/uKdBsI9Q47IceEc5vSyfIMg044HktVxfY5u2o4SX4j3QARkkLr02cpIg dr2w== 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=rxGrOaS74Gt6IVZuo2kSpR21mYjFb4GrS5UFrdyRLTA=; b=O7nsmCq2SKkwzXy2G3+nXVB22Uw8jWJOuWzdlW9rH+GPGrP5eF3CQziAjMNQblaS26 csMxt36vXW+Dx+INXm/lyXy9Rahx6GmvaEaL4zW4Z7cRWCu4IA4qIbCt9IJCChfbiodj 8CzPEDun5A2hJbWOXP5YD25qD/652fttQEAqgK/TzsrW1QGTr/YHs8NEsK+Ik9cM44jc FAXSr60Wyl83AYHeUXHruIY8dS3FTx8DEujsEIeWLrkMLS2NMTEgywKVTArHGlSru01w 5+2fctg8MYZAZBGqLYUmUOI0e35pFcnIE1h0teh9p+DOrU4pwJFghWox4eWVwmQ0amfa rPTg== X-Gm-Message-State: AJaThX7FYgITsDKCOHn0i6rkVkgiWLGxWDJ+6uUS21y3bKWVOqvceM3h RepIwcN/6uZZ+15Xxdg2u3C/sxBElS/BE7UAd9A= X-Google-Smtp-Source: AGs4zMYdXcGPrJXhMFw9RF1zZq+aYaB3eR0BXTfBu49oJ2L+duOGsZ2WWDsaSN4dbEU1ExABlxnJHdpF2afGqx++bn0= X-Received: by 10.98.117.137 with SMTP id q131mr5612603pfc.165.1510654367764; Tue, 14 Nov 2017 02:12:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.190.1 with HTTP; Tue, 14 Nov 2017 02:12:27 -0800 (PST) In-Reply-To: References: From: Dick Hardt Date: Tue, 14 Nov 2017 18:12:27 +0800 Message-ID: To: Mike Jones Cc: "oauth@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c04fe1ef81624055deea097" Archived-At: Subject: Re: [OAUTH-WG] Question on REQUIRED metadata in https://tools.ietf.org/html/draft-ietf-oauth-discovery-07 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, 14 Nov 2017 10:12:50 -0000 --94eb2c04fe1ef81624055deea097 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for the quick response Mike. Good to know I understand specs once in awhile. /Dick On Tue, Nov 14, 2017 at 5:14 PM, Mike Jones wrote: > Good catch. The authorization_endpoint should only be required if flows > are supported that need it. Our old favorite, the Resource Owner Passwor= d > Credentials flow doesn=E2=80=99t use it, correct? Likewise, the Client C= redentials > flow doesn=E2=80=99t. I=E2=80=99ll plan to make appropriate updates in -= 08. > > > > -- Mike > > > > *From:* Dick Hardt [mailto:dick.hardt@gmail.com] > *Sent:* Tuesday, November 14, 2017 5:02 PM > *To:* oauth@ietf.org; Mike Jones > *Subject:* Question on REQUIRED metadata in https://tools.ietf.org/html/ > draft-ietf-oauth-discovery-07 > > > > I was reviewing https://tools.ietf.org/html/draft-ietf-oauth-discovery-07 > and noticed that in https://tools.ietf.org/html/draft-ietf-oauth- > discovery-07#section-2 that authorization_endpoint is REQUIRED. > > > > I am working on deployments that are two-legged OAuth where there is > no authorization_endpoint, but having a discovery document would be super > useful. > > > > Additionally, in https://tools.ietf.org/html/draft-hardt-oauth- > distributed-00, discovery would be useful, but there may not be > an authorization_endpoint may not be needed in the authorization server a= s > it is a two legged OAuth flow (ie, there is no user granting permission, > the client is requesting an access token to use at resources) > > > > Is there a reason why authorization_endpoint is REQUIRED? > > > > /Dick > > > --=20 Subscribe to the HARDTWARE mail list to learn about projects I am working on! --94eb2c04fe1ef81624055deea097 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the quick response Mike. Good to know I underst= and specs once in awhile.

/Dick

On Tue, Nov 14, 2017 at 5:14 P= M, Mike Jones <Michael.Jones@microsoft.com> wrote:=

Good catch.=C2=A0 The = authorization_endpoint should only be required if flows are supported that = need it.=C2=A0 Our old favorite, the Resource Owner Password Credentials fl= ow doesn=E2=80=99t use it, correct?=C2=A0 Likewise, the Client Credentials flow doesn=E2=80=99t.=C2=A0 I=E2=80=99ll plan to make appropri= ate updates in -08.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=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: Dick Hardt [mailto:dick.hardt@gmail.com]
Sent: Tuesday, November 14, 2017 5:02 PM
To: oauth@ietf.o= rg; Mike Jones <Michael.Jones@microsoft.com>
Subject: Question on REQUIRED metadata in https://tools= .ietf.org/html/draft-ietf-oauth-discovery-07

=C2=A0

I was reviewing=C2=A0https://tools.ietf= .org/html/draft-ietf-oauth-discovery-07 and noticed that in= =C2=A0https://tools.ietf.org/html/draft-ietf-oa= uth-discovery-07#section-2 that=C2=A0authorization_endpo= int is REQUIRED.

=C2=A0

I am wo= rking on deployments that are two-legged OAuth where there is no=C2=A0autho= rization_endpoint, but having a discovery document would be super useful.= =C2=A0

=C2=A0

Additio= nally, in=C2=A0https://tools.ietf.org/html/draft-hardt= -oauth-distributed-00, discovery would be useful, but there may not be an=C2=A0authorization_endpoint may not be needed in the authorizati= on server as it is a two legged OAuth flow (ie, there is no user granting p= ermission, the client is requesting an access token to use at resources)

=C2=A0

Is ther= e a reason why=C2=A0authorization_endpoint is REQUIRED?

=C2=A0

/Dick

=C2=A0




--
Subscribe to the HARDTWARE mail list to learn about = projects I am working on!
--94eb2c04fe1ef81624055deea097-- From nobody Tue Nov 14 03:49:02 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 97575120726; Tue, 14 Nov 2017 03:49:00 -0800 (PST) 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.65.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151066014057.5874.14995601908173317919@ietfa.amsl.com> Date: Tue, 14 Nov 2017 03:49:00 -0800 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-04.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: Tue, 14 Nov 2017 11:49:00 -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 WG of the IETF. Title : OAuth Security Topics Authors : Torsten Lodderstedt John Bradley Andrey Labunets Filename : draft-ietf-oauth-security-topics-04.txt Pages : 26 Date : 2017-11-14 Abstract: This draft gives a comprehensive overview on open OAuth security topics. It is intended to serve as a working document for the OAuth working group to systematically capture and discuss these security topics and respective mitigations and eventually recommend best current practice and also OAuth extensions needed to cope with the respective security threats. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-security-topics-04 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-security-topics-04 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 Tue Nov 14 05:28:15 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 6246D1272E1 for ; Tue, 14 Nov 2017 05:28:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 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_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 ie77kBze1XZG for ; Tue, 14 Nov 2017 05:28:11 -0800 (PST) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.18.16]) (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 2A09B12025C for ; Tue, 14 Nov 2017 05:28:11 -0800 (PST) Received: from [42.61.210.59] (helo=[10.10.4.143]) by smtprelay04.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1eEbG6-00044x-DB for oauth@ietf.org; Tue, 14 Nov 2017 14:28:11 +0100 From: Torsten Lodderstedt Content-Type: multipart/signed; boundary="Apple-Mail=_308A43F6-CA73-450B-A568-F50DBEA1AB7C"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <9DE970FE-DE6D-4779-A32C-3AC0FDB569BF@lodderstedt.net> References: <151066014057.5874.14995601908173317919@ietfa.amsl.com> To: oauth Date: Tue, 14 Nov 2017 21:28:03 +0800 X-Mailer: Apple Mail (2.3273) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: [OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-security-topics-04.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, 14 Nov 2017 13:28:14 -0000 --Apple-Mail=_308A43F6-CA73-450B-A568-F50DBEA1AB7C Content-Type: multipart/alternative; boundary="Apple-Mail=_822C722E-6796-4321-A158-C6A3E1E40E8C" --Apple-Mail=_822C722E-6796-4321-A158-C6A3E1E40E8C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi all, I just published revision -04.=20 Changes: Added best practices on Token Leakage prevention Restructured document for better readability kind regards, Torsten.=20 > Anfang der weitergeleiteten Nachricht: >=20 > Von: internet-drafts@ietf.org > Betreff: [OAUTH-WG] I-D Action: = draft-ietf-oauth-security-topics-04.txt > Datum: 14. November 2017 um 19:49:00 GMT+8 > An: > Kopie: oauth@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Web Authorization Protocol WG of the = IETF. >=20 > Title : OAuth Security Topics > Authors : Torsten Lodderstedt > John Bradley > Andrey Labunets > Filename : draft-ietf-oauth-security-topics-04.txt > Pages : 26 > Date : 2017-11-14 >=20 > Abstract: > This draft gives a comprehensive overview on open OAuth security > topics. It is intended to serve as a working document for the OAuth > working group to systematically capture and discuss these security > topics and respective mitigations and eventually recommend best > current practice and also OAuth extensions needed to cope with the > respective security threats. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-oauth-security-topics-04 > = https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-04 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-security-topics-04 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_822C722E-6796-4321-A158-C6A3E1E40E8C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi all,

I = just published revision -04. 

Changes:
  • Added best practices on Token = Leakage prevention
  • Restructured document for better readability

kind = regards,
Torsten. 
Anfang = der weitergeleiteten Nachricht:

Von: = internet-drafts@ietf.org
Betreff: = [OAUTH-WG] I-D = Action: draft-ietf-oauth-security-topics-04.txt
Datum: = 14. November 2017 um 19:49:00 = GMT+8
An: = <i-d-announce@ietf.org>
Kopie: = oauth@ietf.org


A New = Internet-Draft is available from the on-line Internet-Drafts = directories.
This draft is a work item of the Web = Authorization Protocol WG of the IETF.

=        Title =           : OAuth = Security Topics
=        Authors =         : Torsten Lodderstedt
=             &n= bsp;           &nbs= p;John Bradley
=             &n= bsp;           &nbs= p;Andrey Labunets
Filename =        : = draft-ietf-oauth-security-topics-04.txt
Pages =           : 26
= Date =            : = 2017-11-14

Abstract:
=   This draft gives a comprehensive overview on open OAuth = security
  topics.  It is intended to = serve as a working document for the OAuth
=   working group to systematically capture and discuss these = security
  topics and respective mitigations = and eventually recommend best
  current = practice and also OAuth extensions needed to cope with the
=   respective security threats.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topi= cs/

There are also htmlized versions = available at:
https://tools.ietf.org/html/draft-ietf-oauth-security-topics-04=
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security= -topics-04

A diff from the previous version = is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-security-t= opics-04


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

= --Apple-Mail=_822C722E-6796-4321-A158-C6A3E1E40E8C-- --Apple-Mail=_308A43F6-CA73-450B-A568-F50DBEA1AB7C 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 CQUxDxcNMTcxMTE0MTMyODA0WjAjBgkqhkiG9w0BCQQxFgQUt3ec97TpE1myZvuUxpEU2vKcMc8w gcEGCSsGAQQBgjcQBDGBszCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/ BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVt YWlsIENBAhAz25rGqsI3mWtz8QN7mfC0MIHDBgsqhkiG9w0BCRACCzGBs6CBsDCBmzELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBB dXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAz25rGqsI3mWtz8QN7mfC0MA0GCSqG SIb3DQEBAQUABIIBADHqXW44FlQns8HsfIE3qyAGXnB2AptCUpbqpIvm+NRmiZrNaoyx59g8OAvc 55JsnnIF4KbPsA+u0G1lWXQCWqN1fy7wCgm/oEpHOEAT2hmzinj1zpYiD/f0tzYjjudR4A64Juvr 9sgOXiDi73KdJN4E4iS5W54xyLJr+pLqBUEcfyhvEeDobP6a678d2s9bmge2v7r6z6yIIasg/53r zi+5oETvXZn2SuGFanifF81xIOi4gbUt4HY6KPuPyHs72oV0kULW+CUzsrQUm+EqPOdl0F8S3C4i PoenFvZGnaq7vu7wiMKPVeezKULtrMzmzJHOufCC6TxXDs4AVXCVzYIAAAAAAAA= --Apple-Mail=_308A43F6-CA73-450B-A568-F50DBEA1AB7C-- From nobody Tue Nov 14 06:54:53 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 390E4124D6C for ; Tue, 14 Nov 2017 06:54:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnt-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 GBA-q4nEuMQg for ; Tue, 14 Nov 2017 06:54:48 -0800 (PST) Received: from mail-pg0-x22a.google.com (mail-pg0-x22a.google.com [IPv6:2607:f8b0:400e: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 3F8FC124C27 for ; Tue, 14 Nov 2017 06:54:47 -0800 (PST) Received: by mail-pg0-x22a.google.com with SMTP id c123so7511030pga.11 for ; Tue, 14 Nov 2017 06:54:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnt-se.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=J9ROcXn7BKdIWlN4m2304jzxaY3+x2IeFl2Euk+xL2A=; b=DgQ9d5BCvhXlJW5q2Qu5hxljA/aRTdhaNrCDTMgSG079LAHTOWD+cn49PFx+onvZB3 iaBRlLnM+FuSm/YgjjCLwSuC577dFsgyz0HBRFt5FvTb936TXnUljXWVE3CSb5tLTp0N rTlEsFLNOTwkax9/IZ298/3DHRREs2un92Ljf1z/Iy2NAzxOagj1GHyY1GPKNR2WVjxT i9Qto5+jzDDuWk5N1iVN0OCdL8FCj3kDYqryQBVarnrVElfI8WxbaI1fivLA5/p4S5Sk Qey1rdKkIhy1XkvxvaHS/8dj/ZmmEvXS2qosT653d+1xoxx13JSTmXRugKQhCTbXe2dT HRdA== 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-language :content-transfer-encoding; bh=J9ROcXn7BKdIWlN4m2304jzxaY3+x2IeFl2Euk+xL2A=; b=cpZkMdyXbd8okGwdgy6gqaZkMPu0rVJoq04G+bmcf4dSIq1s5jy8QQIQo3zFdX9nQf L9iIhDLA7jfj1SMoB+OgBoCdUGYrl51k8KdW0dH0DTmcujwkmXzYAGtu6PC6+0FvWnXl 4yLuXhCojys3NSH/1sk0ao1lUNRpuipUNmXKaObB8DmjyIBKbns2LrGJUaVeU9hcSIAP 36CcXkaZUEEPXRxUOgmC7S5YHA3SWKuk0h1Viijv4OY7Xjm3jq5RTBewnjOBJ+CjF23N hoUdvo4eas9NZ/c8k8FBx5WLzYRA1hrEgE6vVO0piWkFYp7HwSuLfTtIKMlj0N7Yk5RV 5JSw== X-Gm-Message-State: AJaThX4E2fSAZFCV+JltMoIgvLNW5+t3miqJq668rvYVaBSzWgI52VHD A5lIHPB1UYONMGv3rpXMtj/qR3h8MKo= X-Google-Smtp-Source: AGs4zMaN41VY0bUeSrzfSdrcy5TaldbgPSsP5cgj5MSiCkN7e6zq2dYO7hhTEpc6crwVmjMavK4gtQ== X-Received: by 10.98.107.133 with SMTP id g127mr13864498pfc.228.1510671286289; Tue, 14 Nov 2017 06:54:46 -0800 (PST) Received: from ?IPv6:2001:67c:1232:144:418a:5b2a:53f5:49b? ([2001:67c:1232:144:418a:5b2a:53f5:49b]) by smtp.gmail.com with ESMTPSA id f6sm30073518pgo.11.2017.11.14.06.54.44 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Nov 2017 06:54:45 -0800 (PST) To: oauth@ietf.org References: <1bf08c5e-db95-03b5-9c7e-5ee0a6c7eb9e@sunet.se> From: Leif Johansson Message-ID: <2181c550-0a2b-25be-1cf6-7a2bc31ca045@mnt.se> Date: Tue, 14 Nov 2017 15:54:43 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [OAUTH-WG] cert spoofing in mtls & short-lived certs 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, 14 Nov 2017 14:54:51 -0000 On 2017-11-14 10:27, Brian Campbell wrote: > The expectation/assumption is that the SubjectDN would be a stable > identifier through re-issuance of certificates, regardless of whether > they be short or long term. We've had basically this as a product > feature for years and use of the SubjectDN as the identifier hasn't been > an issue. And it's not been raised, that I'm aware of anyway, as a > concern in the banking use-cases where there will be some central entity > issuing these certificates to the participants. Not sure if that exactly > addresses your question but that's how things got the way they are in > the document. OK. That satisfies my curiosity. > > If there's some better or additional text you'd like to see for the > security considerations, please do suggest it. In addition to what is there I might add something like this: There is an assumption that the client and server agree on the set of trust anchors the server uses to create and validate the certificate chain. Without this assumption the use of a SubjectDN to identify the client certificate would open the server up to certificate spoofing attacks. > > On Tue, Nov 14, 2017 at 4:44 PM, Leif Johansson > wrote: > > > So I reviewed the security considerations text which basically sais > that the server can avoid being spoofed by managing its set of trust > anchors. The text is better than nothing. > > However this lead me to ask another question about the use of > SubjectDN as an identifier for the subject in client metadata: don't > we expect certificates to be issued as short-term credentials from > an STS-like thing? > > If so the SubjectDN is probably going to change every time the STS > gets called (say by including a serial number) and such a SubjectDN > probably isn't the best thing to put in client metadata. > > Would it make sense to make it possible to identify subjects based > on (say) SubjectAltName as an alternative for this case? > > I don't want to hold up the process on this but I'm curious if this > has been raised or just overlooked...? > >         Cheers Leif > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > /CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly > prohibited.  If you have received this communication in error, please > notify the sender immediately by e-mail and delete the message and any > file attachments from your computer. Thank you./ > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From nobody Tue Nov 14 08:44:53 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 4BD011293D8 for ; Tue, 14 Nov 2017 08:44:50 -0800 (PST) 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, FREEMAIL_FROM=0.001, 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=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 fC595t-SAX0H for ; Tue, 14 Nov 2017 08:44:47 -0800 (PST) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::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 BC59A128D44 for ; Tue, 14 Nov 2017 08:44:47 -0800 (PST) Received: by mail-it0-x22d.google.com with SMTP id n134so5767725itg.3 for ; Tue, 14 Nov 2017 08:44:47 -0800 (PST) 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=NGaGv7tSIk0MmEA8E97+WDTGaHHg7qXG4uJxNeh3908=; b=OALFNNDvXOWyvWq1W1pXC9Qb0hba/FYajHxZXZR9C0duy4a0FDTzm+kLpMTraswlS/ mZhB3gQTBmiEDLxpWyIg4R+8v1BgG0YbDcKD5pSQAqbJcBO+FLE51ycYV0XWNVqcT5G8 iomjY0BRZeEspuWHHhaMg6Pu29tbn9eKr41pXDrfmsLGF2a6SBMxTAOOUHFJ5tIawL+N 1g1QL5m5PvwQNj2B2z6uoueIL6kVByQUl0uBc3Rs6/BDKxObLHvCgar/mJ3m/Fn6TtK9 JDFFPAUdyq5b/Ib0DP76Wqbq6KY3D8CkRNRpFZL/F6UP9FYYFGsTn/kgSM/WrrU4Wj4q Z0cQ== 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=NGaGv7tSIk0MmEA8E97+WDTGaHHg7qXG4uJxNeh3908=; b=lTrx5GZmpXq6CUo77RLwWzxLQ1uKILmszB/6Upfc7JOoh+INFQLu2mbzbi53fsyixS xlCwBlL/gkIiUN75LWOl5DTrS3+FchkPsNGl8MEnU/vab4yraAGDQ/XawjihGPyPFlPC 4ztwVRvP20zL3ZM92Xe+/cQ/p7JAOwKGt4wfcm4BZ2mqGLkfnCO63+YksO21qFGeY9Zi 5/7kv7zZDwAu0XX0tk/o2Xqs4tmNrKmg672DZ67m7ucUfBHEy8IYYutiXehHls7OgivR bfjzgb1kr4mV3vv4+LQo+qauxYwwNlI5OmzoIa33EGS5cbSx06Q3E2fX9cEAWIPn4NgQ 8vdw== X-Gm-Message-State: AJaThX6yBwbnqYZSXa/vda/T7hB/Y71gcDyDBUfLFIGjveapv7U3vN7y 74lOmxm6rWomqEUUD2/EKvYkbVYkYhMHrrlEq1BFwg== X-Google-Smtp-Source: AGs4zMagMa3FJdU5XZidFEYQ92x/tHfSI087tt6SHvEaZQX18iI29DOIP6xzwJQYA3vAi9W9uqsv0g4Y15SpIA5mpHg= X-Received: by 10.36.129.136 with SMTP id q130mr15754714itd.60.1510677886822; Tue, 14 Nov 2017 08:44:46 -0800 (PST) MIME-Version: 1.0 References: <151066014057.5874.14995601908173317919@ietfa.amsl.com> <9DE970FE-DE6D-4779-A32C-3AC0FDB569BF@lodderstedt.net> In-Reply-To: <9DE970FE-DE6D-4779-A32C-3AC0FDB569BF@lodderstedt.net> From: Nat Sakimura Date: Tue, 14 Nov 2017 16:44:34 +0000 Message-ID: To: Torsten Lodderstedt Cc: oauth Content-Type: multipart/alternative; boundary="94eb2c058c58d06f4f055df41ae9" Archived-At: Subject: Re: [OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-security-topics-04.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, 14 Nov 2017 16:44:50 -0000 --94eb2c058c58d06f4f055df41ae9 Content-Type: text/plain; charset="UTF-8" Thanks, Torsten. In 4.11, you can probably add client_secret and code phishing explained in https://nat.sakimura.org/2016/01/22/code-phishing-attack-on-oauth-2-0-rfc6749/ . I do not like the mitigation strategy there at all, though. Now that we have MTLS draft, using that is much better. The current document is based on the known threat analysis. As Andrey pointed out in the Trier seminar, most problems actually arise from the failure of 1) Source authentication, 2) Destination authentication, and 3) Message authentication. This, I think, is a good viewpoint. The [BCM] paper further recommends to have 4) protocol version and message identifier, 5) full list of actor/roles in addition. It will probably make the protocol provably secure as well. Perhaps we can add these as a consideration to mitigating unknown attacks. Also, analysing each known attacks in light of 1) to 5) above will provide a uniform viewpoint to each attack, so it may be worthwhile to do. Nat [BCM] Basin, D., Cremers, C., Meier, S.: Provably Repairing the ISO/IEC 9798 Standard for Entity Authentication. Journal of Computer Security - Security and Trust Principles archive Volume 21 Issue 6, 817-846 (2013) On Tue, Nov 14, 2017 at 10:28 PM Torsten Lodderstedt < torsten@lodderstedt.net> wrote: > Hi all, > > I just published revision -04. > > Changes: > > - Added best practices on Token Leakage prevention > > > - Restructured document for better readability > > > kind regards, > Torsten. > > Anfang der weitergeleiteten Nachricht: > > *Von: *internet-drafts@ietf.org > *Betreff: **[OAUTH-WG] I-D Action: > draft-ietf-oauth-security-topics-04.txt* > *Datum: *14. November 2017 um 19:49:00 GMT+8 > *An: * > *Kopie: *oauth@ietf.org > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Web Authorization Protocol WG of the IETF. > > Title : OAuth Security Topics > Authors : Torsten Lodderstedt > John Bradley > Andrey Labunets > Filename : draft-ietf-oauth-security-topics-04.txt > Pages : 26 > Date : 2017-11-14 > > Abstract: > This draft gives a comprehensive overview on open OAuth security > topics. It is intended to serve as a working document for the OAuth > working group to systematically capture and discuss these security > topics and respective mitigations and eventually recommend best > current practice and also OAuth extensions needed to cope with the > respective security threats. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-oauth-security-topics-04 > https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-04 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-security-topics-04 > > > 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 > -- Nat Sakimura Chairman of the Board, OpenID Foundation --94eb2c058c58d06f4f055df41ae9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks, Torsten.=C2=A0

In 4.11, you can= probably add client_secret and code phishing explained in=C2=A0https://nat.sakimura.org/2016/01/22/code-phishing-attack-on-oauth-2-0-= rfc6749/.=C2=A0
I do not like the mitigation strategy there a= t all, though. Now that we have MTLS draft, using that is much better.=C2= =A0

The current document is based on the known thr= eat analysis. As Andrey pointed out in the Trier seminar, most problems act= ually arise=C2=A0from the failure of 1) Source authentication, 2) Destinati= on authentication, and 3) Message authentication. This, I think, is a good = viewpoint.=C2=A0
The [BCM] paper further recommends to have=C2=A0= 4) protocol version and message identifier,=C2=A0 5) full list of actor/rol= es in addition. It will probably make the protocol provably secure as well.= =C2=A0

Perhaps we can add these as a consideration= to mitigating unknown attacks. Also, analysing each known attacks in light= of 1) to 5) above will provide a uniform viewpoint to each attack, so it m= ay be worthwhile to do.=C2=A0

Nat

[BCM] Basin, D., Cremers, C., Meier, S.: Provably Repairing t= he ISO/IEC 9798
Standard for Entity Authentication. Journal of Co= mputer Security - Security and Trust Principles archive Volume 21 Issue 6, = 817-846 (2013)





On Tue, Nov 14, = 2017 at 10:28 PM Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
Hi all,

I just published revision -04.=C2=A0

Changes:
  • Added best prac= tices on Token Leakage prevention
  • Restructured document for better readability
<= div>
kind regards,
Torsten.=C2=A0
<= div>
Anfang der weitergeleiteten Nachrich= t:

Betreff: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-04.tx= t
Datum: 14. November 2017 um 19:49:00 GMT+8


A New Inter= net-Draft is available from the on-line Internet-Drafts directories.
Thi= s draft is a work item of the Web Authorization Protocol WG of the IETF.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Title =C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: OAuth Security Topics
=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Authors =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0: Torsten Lodderstedt
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0John Bradley
=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Andrey Labun= ets
Filename =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= : draft-ietf-oauth-security-topics-04.txt
Pages =C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: 26
<= /span>Date =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0: 2017-11-14

Abstract:
=C2=A0=C2=A0This draft gives a compreh= ensive overview on open OAuth security
=C2=A0=C2=A0topics.=C2=A0 It is = intended to serve as a working document for the OAuth
=C2=A0=C2=A0worki= ng group to systematically capture and discuss these security
=C2=A0=C2= =A0topics and respective mitigations and eventually recommend best
=C2= =A0=C2=A0current practice and also OAuth extensions needed to cope with the=
=C2=A0=C2=A0respective security threats.


The IETF datatrack= er status page for this draft is:
https://datatrac= ker.ietf.org/doc/draft-ietf-oauth-security-topics/

There are als= o htmlized versions available at:
https://tools.ietf.= org/html/draft-ietf-oauth-security-topics-04
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topic= s-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-s= ecurity-topics-04


Please note that it may take a couple of m= inutes from the time of submission
until the htmlized version and diff a= re available at tools.i= etf.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
--

Nat Sakimura

Chairman of the Board, OpenID Foundation

--94eb2c058c58d06f4f055df41ae9-- From nobody Tue Nov 14 22:52:58 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 988921294F7 for ; Tue, 14 Nov 2017 22:52:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 pCwYfAuUyysd for ; Tue, 14 Nov 2017 22:52:55 -0800 (PST) Received: from ipxcno.tcif.telstra.com.au (ipxcno.tcif.telstra.com.au [203.35.82.208]) (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 13BD61270A0 for ; Tue, 14 Nov 2017 22:52:53 -0800 (PST) X-IronPort-AV: E=Sophos; i="5.44,398,1505743200"; d="scan'208,217"; a="75910360" Received: from unknown (HELO ipcani.tcif.telstra.com.au) ([10.97.216.200]) by ipocni.tcif.telstra.com.au with ESMTP; 15 Nov 2017 17:52:51 +1100 X-IronPort-AV: E=McAfee;i="5900,7806,8679"; a="521585258" Received: from wsmsg3703.srv.dir.telstra.com ([172.49.40.171]) by ipcani.tcif.telstra.com.au with ESMTP; 15 Nov 2017 17:52:51 +1100 Received: from wsapp6782.srv.dir.telstra.com (10.75.131.37) by wsmsg3703.srv.dir.telstra.com (172.49.40.171) with Microsoft SMTP Server (TLS) id 8.3.485.1; Wed, 15 Nov 2017 17:52:51 +1100 Received: from wsapp5584.srv.dir.telstra.com (10.75.131.20) by wsapp6782.srv.dir.telstra.com (10.75.131.37) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 15 Nov 2017 17:52:50 +1100 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.1320.4 via Frontend Transport; Wed, 15 Nov 2017 17:52:50 +1100 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=C0PlZf1scqC5tPpbkrhxRYQ6tt7onZT+SiYSNB9Uy8Q=; b=rDKzaolX+ghcrh5XjY12Jm6nE8chCxmjQnR4M3bJTG8FRbSNk5V/BxUEsuReUzwCo/Dqqfkki7brOs+2IzyNctQomJjWDgu9Q85vipuRmQngH4r4Xi9TbEOvjzRt1HL4m0d8ynL9zAKYfF3VBMTkju5Hqqs+ln8BDCCXR2c4BIY= Received: from ME1PR01MB1076.ausprd01.prod.outlook.com (10.169.167.15) by ME1PR01MB1076.ausprd01.prod.outlook.com (10.169.167.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.239.5; Wed, 15 Nov 2017 06:52:49 +0000 Received: from ME1PR01MB1076.ausprd01.prod.outlook.com ([fe80::a16e:2cd3:57e3:8213]) by ME1PR01MB1076.ausprd01.prod.outlook.com ([fe80::a16e:2cd3:57e3:8213%17]) with mapi id 15.20.0239.005; Wed, 15 Nov 2017 06:52:49 +0000 From: "Manger, James" To: "oauth@ietf.org" Thread-Topic: Comments on draft-hardt-oauth-distributed Thread-Index: AdNdrcaf1mQmZ23SSFG/j8g0e9Ryfw== Date: Wed, 15 Nov 2017 06:52:49 +0000 Message-ID: Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=James.H.Manger@team.telstra.com; x-originating-ip: [203.35.185.244] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; ME1PR01MB1076; 6:KOVnOhiY6XqNl2fVLXkf42+xCQwKdJIT9HyzwdbU/wvsStLhvAfedoXpmvbNHq57ZTL+iRzK/Cwa1V6oSGC3ga4Sf31pbvYAO5wKKYKcs4q6AoGdmfEPZTURnzB60zg5erG9P2I8ckrsin5Mt5Glih2DNVRrdeBObdw5K8yV37dCYWmG76EffGNlQNjNiTJ+kG6KrQoWZ31zUX/HuJka55o9ITIlZcO7zcOcgBzYc0YFNU11ByPlZnxM+ckFY6LgYaET6jOBVmPpxBSqDe8WL+KgeBsW20RRTdqxQb53+SxdjxU6sQ7eLsSe5o93oUfD52/gOeyNYdlAyIMcQl9ocWPNLC3moppO4G4MXvOlBbU=; 5:XYWlO3LaquP2QHzC01yZw9ffqiHJ6ND8hEjU/s5ffe8BXjR/vEHEF7OSxvmfP5XrUrvps+ekru40WIIbKIukN1KGWTjvZidX9JxBp5m61JWsAT165BtP6yWV75JonKtEp3VjhQPZBn4JVkj+snAJ8U9sT/NTYTcX0eAgROP6w8w=; 24:1wAOtxVwbGS2YxqXnbkh3HVC6WEH+e5Vsr/loasUAfQ5yLK2Zw5vF4/8bs9Tov8cIIhGj0c2ewpMP2/Yhn1JzATdLAWb7fyjWFA7vwSjf50=; 7:XP7fhIiJKvGhQbZ8jYk56dE529SuTgC9r6bCdoLHvysbTfF5c0P54UsQU3Xy0oR6a+7kR82pHy/f83vGjxD+I5oRwDzAAXmoHw2gkC4AezSGDyZ9gH770Z2jMwtIygtQmnTef7xQfqgulu1z4nQQom5y+Bts263erDxrw7WOVcWz1d53vXxcdpSZs749Zk5+n5NhE+cCxz7LJb3nrLahRoLtJoQJzGkGVAE5m6M3NtTzrvMdfYEkNe6vLrdFW5wY x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: ccb5ceec-a3f6-4a1b-3d0c-08d52bf57c6f x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603258); SRVR:ME1PR01MB1076; x-ms-traffictypediagnostic: ME1PR01MB1076: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(227612066756510)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(3231022)(3002001)(6041248)(20161123562025)(20161123560025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:ME1PR01MB1076; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:ME1PR01MB1076; x-forefront-prvs: 0492FD61DD x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(199003)(189002)(101416001)(5250100002)(97736004)(8676002)(54356999)(102836003)(790700001)(6116002)(74316002)(33656002)(3846002)(50986999)(1730700003)(25786009)(99286004)(6916009)(42882006)(966005)(81166006)(316002)(86362001)(81156014)(3280700002)(5630700001)(2351001)(7736002)(7696004)(72206003)(106356001)(105586002)(55016002)(3660700001)(478600001)(5640700003)(5660300001)(54896002)(6506006)(6306002)(230783001)(189998001)(9686003)(236005)(606006)(8936002)(68736007)(6436002)(2501003)(66066001)(2906002)(2900100001)(14454004)(53936002); DIR:OUT; SFP:1102; SCL:1; SRVR:ME1PR01MB1076; H:ME1PR01MB1076.ausprd01.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; received-spf: None (protection.outlook.com: team.telstra.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_ME1PR01MB1076048CCFA21754B23DF8DAE5290ME1PR01MB1076ausp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: ccb5ceec-a3f6-4a1b-3d0c-08d52bf57c6f X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Nov 2017 06:52:49.6189 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 49dfc6a3-5fb7-49f4-adea-c54e725bb854 X-MS-Exchange-Transport-CrossTenantHeadersStamped: ME1PR01MB1076 X-OriginatorOrg: team.telstra.com Archived-At: Subject: [OAUTH-WG] Comments on draft-hardt-oauth-distributed 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, 15 Nov 2017 06:52:57 -0000 --_000_ME1PR01MB1076048CCFA21754B23DF8DAE5290ME1PR01MB1076ausp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable It is good to see this RESTful authorization server (AS) discovery mechanis= m. It takes me back to 2010 & 2011 when this idea was also discussed. The "iss" value in the WWW-Authenticate response header should presumably b= e an AS's real "iss" value, not an AS's token endpoint address. So HTTP/1.1 401 Unauthorized WWW-Authenticate: Bearer realm=3D"example_realm", iss=3D"https://issuer.example.com/", scope=3D"example_scope", error=3D"invalid_token" And then the client could get https://issuer.example.com/.well-known/openid= -configuration to find the token endpoint plus any other parameters it will= need. One concern earlier was that a client app is tricked into sending its clien= t secret to a bogus AS returned by a malicious resource. This doc mentions = mechanisms such as mutual TLS as a mitigation. But another mitigation shoul= d be that when you have a secret, always know where it can be used. The WWW-Authenticate header indicating that an OAuth2 delegation dance can = be used to get access is good. Ideally it shouldn't use the Bearer scheme. = The semantics are "one way to continue is to do OAuth 2.0 with this AS", wh= ich is independent of what type of temporary credential that OAuth2 dance d= elivers. -- James Manger --_000_ME1PR01MB1076048CCFA21754B23DF8DAE5290ME1PR01MB1076ausp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

It is good to see this RESTful authorization server = (AS) discovery mechanism. It takes me back to 2010 & 2011 when this ide= a was also discussed.

 

The “iss” value in the WWW-Authenticate = response header should presumably be an AS’s real “iss” v= alue, not an AS’s token endpoint address.

 

So

   &= nbsp;   HTTP/1.1 401 Unauthorized

   &= nbsp;   WWW-Authenticate: Bearer realm=3D"example_realm"= ;,

   &= nbsp;           &nbs= p;            &= nbsp;   iss=3D"https://issuer.example.com/",=

   &= nbsp;           &nbs= p;            &= nbsp;   scope=3D"example_scope",

   &= nbsp;           &nbs= p;            &= nbsp;   error=3D"invalid_token"

 

And then the client could get htt= ps://issuer.example.com/.well-known/openid-configuration to find= the token endpoint plus any other parameters it will need.

 

One concern earlier was that a client app is tricked= into sending its client secret to a bogus AS returned by a malicious resou= rce. This doc mentions mechanisms such as mutual TLS as a mitigation. But a= nother mitigation should be that when you have a secret, always know where it can be used.

 

The WWW-Authenticate header indicating that an OAuth= 2 delegation dance can be used to get access is good. Ideally it shouldn= 217;t use the Bearer scheme. The semantics are “one way to continue i= s to do OAuth 2.0 with this AS”, which is independent of what type of temporary credential that OAuth2 dance delivers.

 

--

James Man= ger

 

--_000_ME1PR01MB1076048CCFA21754B23DF8DAE5290ME1PR01MB1076ausp_-- From nobody Wed Nov 15 02:11: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 9B7E1126CE8 for ; Wed, 15 Nov 2017 02:11:50 -0800 (PST) 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 eYk1whRfEgXS for ; Wed, 15 Nov 2017 02:11:49 -0800 (PST) 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 E2E3212008A for ; Wed, 15 Nov 2017 02:11:48 -0800 (PST) Received: by mail-it0-x22c.google.com with SMTP id r127so1135026itb.5 for ; Wed, 15 Nov 2017 02:11:48 -0800 (PST) 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; bh=DHOv1tReiOmsRTYcJUWqFDTqHyijGyxHEkAXcpGYBUI=; b=Py2Ugjjz06Mm2cYZ+Hrvs3q00zSisOmXmCfTKgh3bWXj93PAFgdli+lw0J6B9jzBYG yqJI8eOXCE84RmtJrlyM2njvq/0UnN5KAn/HPx4i3GXvbjG+JVuUs3ogKoAL70u3aQlF Lp1BWgNVZ+kYxUz5MkvOJpijq2G1pPNj1pL/azXhChqAL0rpMNOj9LyEp6y5ERs+mMlt VlPkdIy24obMA4TE13iYGx2xcxnN9DcLTL4gq5a/GlZF0dN7/X6TrS+XQPF75ehXVBOo DZie+udHYr55hHZtyPTjZof1ReJRPOCFcXr8npOeYaH0zTjc880di64Fy6TaE5KpJZpj 1EFQ== 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; bh=DHOv1tReiOmsRTYcJUWqFDTqHyijGyxHEkAXcpGYBUI=; b=OGVMA4yHL7UXypKqXPxuUa1A23zrLzbrRm6AJ6od4FBYnirODNPWZf3z0JPmVCWrBx 40zn4Tu8YAe7ZxAryiIUA1NRmPzGtMMDmQCi0ziHc9+JJ9hw48fthaSYmhVxU7LzU3Hs bmGGe7h7lYHx4eoMCoICM/xQGRxjQ4pZ+Vt+15sKWqGxc1/sZ1nxxN5pruq9kvg1CDPd iAQV/S/NeTbEWT5Mt1qElB9PobgVPSm+q7G0X2ktenc+FzlL8EX6KC1tuImfdxUOLVDu C/EVIaug9SyCg2jzUXJdUOFLyJFSvPSVVT46J2S+NdK71XsM3S0uCJvoMj5xlhJQdxW0 lr+w== X-Gm-Message-State: AJaThX52YvAuXcO4zqEvGjOHS0oglZjKSk0lbBFJotiqeRwBC5LnuBAk qcgxhnGNDVuJVPsdPXzWrx4BNoG+vu62TSdIFE8AJw== X-Google-Smtp-Source: AGs4zMaGMkgvddfDFzusjmVJXFeGVPGqHsmSIxRyDAaE5OG8LzBNDFXJFefrbVqqijb2OY4N7KwZaj/nCk+tDe6++zw= X-Received: by 10.36.125.144 with SMTP id b138mr18174277itc.80.1510740707802; Wed, 15 Nov 2017 02:11:47 -0800 (PST) MIME-Version: 1.0 References: <151073460552.25907.1543803289545128597.idtracker@ietfa.amsl.com> In-Reply-To: <151073460552.25907.1543803289545128597.idtracker@ietfa.amsl.com> From: Nat Sakimura Date: Wed, 15 Nov 2017 10:11:37 +0000 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="001a114442fe3c827f055e02bb08" Archived-At: Subject: [OAUTH-WG] New Version of draft-sakimura-oauth-meta for the discussion of draft-hardt-oauth-distributed 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, 15 Nov 2017 10:11:50 -0000 --001a114442fe3c827f055e02bb08 Content-Type: text/plain; charset="UTF-8" I just revved the expired and archived draft so that it will be easier for discussion around draft-hardt-oauth-distributed . This is the draft I mentioned during the meeting. Previous versions had JSON response as "_links" as well. Best, Nat ---------- Forwarded message --------- From: Date: Wed, Nov 15, 2017 at 5:30 PM Subject: New Version Notification for draft-sakimura-oauth-meta-08.txt To: Nov Matake , Sascha Preibisch , Nat Sakimura , Sascha Preibisch < Sascha.Preibisch@gmail.com> A new version of I-D, draft-sakimura-oauth-meta-08.txt has been successfully submitted by Nat Sakimura and posted to the IETF repository. Name: draft-sakimura-oauth-meta Revision: 08 Title: OAuth Response Metadata Document date: 2017-11-15 Group: Individual Submission Pages: 10 URL: https://www.ietf.org/internet-drafts/draft-sakimura-oauth-meta-08.txt Status: https://datatracker.ietf.org/doc/draft-sakimura-oauth-meta/ Htmlized: https://tools.ietf.org/html/draft-sakimura-oauth-meta-08 Htmlized: https://datatracker.ietf.org/doc/html/draft-sakimura-oauth-meta-08 Diff: https://www.ietf.org/rfcdiff?url2=draft-sakimura-oauth-meta-08 Abstract: This specification defines an extensible metadata framework that may be inserted into the OAuth 2.0 responses to assist the clients to process those responses. It is expressed either as a link header, or query parameters. It will allow the client to learn the metadata about the particular response. For example, the client can learn where the members in the response could be used, what is the characteristics of the payload is, how it should be processed, and so on. Since they are just additional response header/query parameters, any client that does not understand this extension should not break and work normally while supporting clients can utilize the metadata to take the advantage of the extension. 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 -- Nat Sakimura Chairman of the Board, OpenID Foundation --001a114442fe3c827f055e02bb08 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I just revved the expired and archived draft so that it wi= ll be easier for discussion around=C2=A0draft-hardt-oauth-distributed=C2=A0.=C2=A0
This is the = draft I mentioned during the meeting.=C2=A0 Previous versions had JSON resp= onse as "_links" as well.=C2=A0

Best,=C2= =A0

Nat=C2=A0

---------- Forwarded message ---------
From: <internet-drafts@ietf.org>
Da= te: Wed, Nov 15, 2017 at 5:30 PM
Subject: New Version Notification for d= raft-sakimura-oauth-meta-08.txt
To: Nov Matake <nov@matake.jp>, Sascha Preibisch <sascha.preibisch@gmail.com>, Nat Sakimura= <sakimura@gmail.com>, Sasc= ha Preibisch <Sascha.Preib= isch@gmail.com>



A new version of I-D, draft-sakimura-oauth-meta-08.txt
has been successfully submitted by Nat Sakimura and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-sakimura-oauth-meta
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A008
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 OAuth Response Metadata
Document date:=C2=A0 2017-11-15
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-sakimura-oauth-me= ta-08.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= https://datatracker.ietf.org/doc/draft-sakimura-oauth-meta/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://= tools.ietf.org/html/draft-sakimura-oauth-meta-08
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-sakimura-oauth-meta-08 Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-sakimura-oauth-meta-0= 8

Abstract:
=C2=A0 =C2=A0This specification defines an extensible metadata framework th= at may
=C2=A0 =C2=A0be inserted into the OAuth 2.0 responses to assist the clients= to
=C2=A0 =C2=A0process those responses.=C2=A0 It is expressed either as a lin= k header, or
=C2=A0 =C2=A0query parameters.=C2=A0 It will allow the client to learn the = metadata
=C2=A0 =C2=A0about the particular response.=C2=A0 For example, the client c= an learn
=C2=A0 =C2=A0where the members in the response could be used, what is the =C2=A0 =C2=A0characteristics of the payload is, how it should be processed,= and so
=C2=A0 =C2=A0on.=C2=A0 Since they are just additional response header/query= parameters,
=C2=A0 =C2=A0any client that does not understand this extension should not = break
=C2=A0 =C2=A0and work normally while supporting clients can utilize the met= adata
=C2=A0 =C2=A0to take the advantage of the extension.




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

--

Nat Sakimura

Chairman of the Board, OpenID Foundation

--001a114442fe3c827f055e02bb08-- From nobody Wed Nov 15 03:53:18 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 82D4C126B6E for ; Wed, 15 Nov 2017 03:53:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.617 X-Spam-Level: X-Spam-Status: No, score=-2.617 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 jEw3KL6uuNp7 for ; Wed, 15 Nov 2017 03:53:14 -0800 (PST) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) (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 A77A0126FB3 for ; Wed, 15 Nov 2017 03:53:13 -0800 (PST) Received: from [192.168.0.13] (unknown [88.182.125.39]) by smtp6-g21.free.fr (Postfix) with ESMTP id F285A7802B2 for ; Wed, 15 Nov 2017 12:53:11 +0100 (CET) To: oauth@ietf.org References: <151066014057.5874.14995601908173317919@ietfa.amsl.com> From: Denis Message-ID: <17a930bd-fc0e-d2b7-a558-b2e8a7a975aa@free.fr> Date: Wed, 15 Nov 2017 12:53:11 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <151066014057.5874.14995601908173317919@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------D082280A4B9094AFA50262EA" Content-Language: en-US Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-04.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, 15 Nov 2017 11:53:16 -0000 This is a multi-part message in MIME format. --------------D082280A4B9094AFA50262EA Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Comments on draft-ietf-oauth-security-topics-04 1. Section 2.2 states: 2.2.  Token Leakage Prevention    Authorization servers _*shall*_ use TLS-based methods for sender    constraint access tokens as described in section Section 4.7.1.2,    such as token binding [I-D.ietf-oauth-token-binding] or Mutual TLS    for OAuth 2.0 [I-D.ietf-oauth-mtls].  It is also recommend to use    end-to-end TLS whenever possible. Since this draft is intended to be a Best Current Practice (BCP) document , "shall" should be replaced by "should". 2. Collusion between clients is not addressed but should be mentioned. It is proposed to add a section that would placed before section 4.7 (Access Token Leakage at the Resource Server) that would have the following content: Access Token Leakage at the client It’s been a while since the OAuth WG has published in RFC 6819 [RFC6819]. At this time, the threat model was considering various types of attacks performed by attackers or by Resource Servers but did not take into consideration collusion between clients. A client could legitimately obtain an access token and then could attempt to allow its use by another client. If the access token contains a sufficient number of attributes that allows to unambiguously identify the client, it is unlikely that the legitimate client will transmit it to another client since that other client would be able to impersonate the legitimate client. However, if it is not the case (e.g. the access token contains a single attribute like "over 18"), the legitimate owner of the access token may be willing to collaborate with another client because the collusion will not be seen by the Authorization server nor the Resource Server. While protecting private keys in secure elements or in TPMs is certainly necessary, it is insufficient since the legitimate owner of the access token would be able to perform all the cryptographic computations that the other client needs. The counter-measures described in section 4.7.1.2 (Sender Constrained Access Tokens) are unable to counter collusion between clients. 3. A section about privacy considerations is missing. It is proposed to add a section 8 with the following content: 8. Privacy considerations Techniques able to solve security concerns are not necessarily able to solve privacy concerns. The counter-measures described in section 4.7.1.3 (Audience Restricted Access Tokens) allow authorization servers to know where each token they issue will be used. This may be a privacy concern for some clients. Current techniques do not address a way to prevent authorization servers to know where the tokens they issue will be used. This leaves room to extend OAuth in order to add privacy properties. Denis > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Web Authorization Protocol WG of the IETF. > > Title : OAuth Security Topics > Authors : Torsten Lodderstedt > John Bradley > Andrey Labunets > Filename : draft-ietf-oauth-security-topics-04.txt > Pages : 26 > Date : 2017-11-14 > > Abstract: > This draft gives a comprehensive overview on open OAuth security > topics. It is intended to serve as a working document for the OAuth > working group to systematically capture and discuss these security > topics and respective mitigations and eventually recommend best > current practice and also OAuth extensions needed to cope with the > respective security threats. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-oauth-security-topics-04 > https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-04 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-security-topics-04 > > > 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 --------------D082280A4B9094AFA50262EA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Comments on draft-ietf-oauth-security-topics-04

1. Section 2.2 states:
2.2.  Token Leakage Prevention
   Authorization servers shall use TLS-based methods for sender
   constraint access tokens as described in section Section 4.7.1.2,
   such as token binding [I-D.ietf-oauth-token-binding] or Mutual TLS
   for OAuth 2.0 [I-D.ietf-oauth-mtls].  It is also recommend to use
   end-to-end TLS whenever possible.
Since this draft is intended to be a Best Current Practice (BCP) document , "shall" should be replaced by "should".


2. Collusion between clients is not addressed but should be mentioned. It is proposed to add a section
that would placed before section 4.7 (Access Token Leakage at the Resource Server) that would have the following content:
Access Token Leakage at the client

It’s been a while since the OAuth WG has published in RFC 6819 [RFC6819]. At this time, the threat model was considering
various types of attacks performed by attackers or by Resource Servers but did not take into consideration collusion between clients.

A client could legitimately obtain an access token and then could attempt to allow its use by another client. If the access token contains
a sufficient number of attributes that allows to unambiguously identify the client, it is unlikely that the legitimate client will transmit it
to another client since that other client would be able to impersonate the legitimate client. However, if it is not the case (e.g. the access token
contains a single attribute like "over 18"), the legitimate owner of the access token may be willing to collaborate with another client because
the collusion will not be seen by the Authorization server nor the Resource Server.

While protecting private keys in secure elements or in TPMs is certainly necessary, it is insufficient since the legitimate owner of the access token
would be able to perform all the cryptographic computations that the other client needs.

The counter-measures described in section 4.7.1.2 (Sender Constrained Access Tokens) are unable to counter collusion between clients.

3. A section about privacy considerations is missing. It is proposed to add a section 8 with the following content:
8. Privacy considerations

Techniques able to solve security concerns are not necessarily able to solve privacy concerns. The counter-measures described in section 4.7.1.3
(Audience Restricted Access Tokens) allow authorization servers to know where each token they issue will be used. This may be a privacy concern
for some clients. Current techniques do not address a way to prevent authorization servers to know where the tokens they issue will be used.
This leaves room to extend OAuth in order to add privacy properties.
Denis

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol WG of the IETF.

        Title           : OAuth Security Topics
        Authors         : Torsten Lodderstedt
                          John Bradley
                          Andrey Labunets
	Filename        : draft-ietf-oauth-security-topics-04.txt
	Pages           : 26
	Date            : 2017-11-14

Abstract:
   This draft gives a comprehensive overview on open OAuth security
   topics.  It is intended to serve as a working document for the OAuth
   working group to systematically capture and discuss these security
   topics and respective mitigations and eventually recommend best
   current practice and also OAuth extensions needed to cope with the
   respective security threats.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-oauth-security-topics-04
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-security-topics-04


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


--------------D082280A4B9094AFA50262EA-- From nobody Wed Nov 15 22:08: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 CA4E9127201 for ; Wed, 15 Nov 2017 22:08:03 -0800 (PST) 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 flwA2y6yKFl9 for ; Wed, 15 Nov 2017 22:08:01 -0800 (PST) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::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 640B412741D for ; Wed, 15 Nov 2017 22:08:01 -0800 (PST) Received: by mail-it0-x229.google.com with SMTP id n134so626247itg.0 for ; Wed, 15 Nov 2017 22:08:01 -0800 (PST) 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=VaZwkBC0xpdM8CByw+xte87MfSTLQCrlyL7yVWYcrtw=; b=NQ4ku0bz02SBnWUvMTLGsbGLjSXPoJoJpRqd1I3lmTTu/af0Q6aNI29fTDxsa6FlA1 wPmdch03/ekCrZ/W335qJYUpJPV/3cSHYcFZ3t7MK4gXWIywI4JczNskPfv4RYSq3Rfq vHCuVqpVUJxyI/4exyhKmqgQ2UJC9ZNtQ0bW4= 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=VaZwkBC0xpdM8CByw+xte87MfSTLQCrlyL7yVWYcrtw=; b=ruc8NzUmR0pXCo0QN8/ry0thlFllSddo331f47Gstb06eCxlKpyTzarTizceoUMmCf LvvCUS1XiN0wmWbsHBi7MdVPpaiJ9vjZK19UAtFuQx7q8aoclSuMzgDQOUIDNo5IGwdg +2MgiIfhN+HbBLU5epYdgmY3SGVfQqsHA+Yhko3kcI5u6NovoOq3yhCsyU8Ro83ohMlQ Tu5gm1xk8GFzRMM6pqaLM39W+kZgEcQ0DjxUykUayERGv9Sc291xJrJyo9JW8dvhlYid 8Newrkez1ucdc3SR4RPdLSrYCpNr7GBNXdPgoPrRwW5Vx2u95oUdH7SxYU2UfIvrYA3n ej0A== X-Gm-Message-State: AJaThX4ssvlq/HYA0TRh8Tbevx3BKvMCtc20uOmMpx07tt4n8BqwED4Y OqQELMoliEKW3BrZ5L8InRh8c5POKNojrN2gLEf8JUrGvMTizXgr6m+9yFvY0PSfBH5niftof5o rHCdaoqzkvj6iRIbq X-Google-Smtp-Source: AGs4zMb1pKrqKgSHcalIo1pnJosAO+0IGWvq6yOzgNAqDnrj8eD/8E/KqTVxsl5E1dVjUJwTXNGOARKq0MOE8hgZ0p0= X-Received: by 10.36.144.4 with SMTP id x4mr1060956itd.103.1510812480609; Wed, 15 Nov 2017 22:08:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.2.118.194 with HTTP; Wed, 15 Nov 2017 22:07:30 -0800 (PST) In-Reply-To: References: <151073460552.25907.1543803289545128597.idtracker@ietfa.amsl.com> From: Brian Campbell Date: Thu, 16 Nov 2017 14:07:30 +0800 Message-ID: To: Nat Sakimura Cc: oauth Content-Type: multipart/alternative; boundary="001a114fcc603abac7055e1371e4" Archived-At: Subject: Re: [OAUTH-WG] New Version of draft-sakimura-oauth-meta for the discussion of draft-hardt-oauth-distributed 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, 16 Nov 2017 06:08:04 -0000 --001a114fcc603abac7055e1371e4 Content-Type: text/plain; charset="UTF-8" And, for what it's worth, here's the (poorly named) resource indicators draft that was mentioned during the same discussion. https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-02 On Wed, Nov 15, 2017 at 6:11 PM, Nat Sakimura wrote: > I just revved the expired and archived draft so that it will be easier for > discussion around draft-hardt-oauth-distributed . > This is the draft I mentioned during the meeting. Previous versions had > JSON response as "_links" as well. > > Best, > > Nat > > ---------- Forwarded message --------- > From: > Date: Wed, Nov 15, 2017 at 5:30 PM > Subject: New Version Notification for draft-sakimura-oauth-meta-08.txt > To: Nov Matake , Sascha Preibisch < > sascha.preibisch@gmail.com>, Nat Sakimura , Sascha > Preibisch > > > > A new version of I-D, draft-sakimura-oauth-meta-08.txt > has been successfully submitted by Nat Sakimura and posted to the > IETF repository. > > Name: draft-sakimura-oauth-meta > Revision: 08 > Title: OAuth Response Metadata > Document date: 2017-11-15 > Group: Individual Submission > Pages: 10 > URL: https://www.ietf.org/internet-drafts/draft-sakimura-oauth- > meta-08.txt > Status: https://datatracker.ietf.org/ > doc/draft-sakimura-oauth-meta/ > Htmlized: https://tools.ietf.org/html/draft-sakimura-oauth-meta-08 > Htmlized: https://datatracker.ietf.org/ > doc/html/draft-sakimura-oauth-meta-08 > Diff: https://www.ietf.org/rfcdiff?url2=draft-sakimura-oauth- > meta-08 > > Abstract: > This specification defines an extensible metadata framework that may > be inserted into the OAuth 2.0 responses to assist the clients to > process those responses. It is expressed either as a link header, or > query parameters. It will allow the client to learn the metadata > about the particular response. For example, the client can learn > where the members in the response could be used, what is the > characteristics of the payload is, how it should be processed, and so > on. Since they are just additional response header/query parameters, > any client that does not understand this extension should not break > and work normally while supporting clients can utilize the metadata > to take the advantage of the extension. > > > > > 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 > > -- > > Nat Sakimura > > Chairman of the Board, OpenID Foundation > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > -- *CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.* --001a114fcc603abac7055e1371e4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
And, for what it's worth, here's the (poorly = named) resource indicators draft that was mentioned during the same discuss= ion.

https://tools.ietf.org/html/draft-campbell-oauth-reso= urce-indicators-02


On Wed, Nov 15, 2017 at 6:11 PM, Nat Sakimura <s= akimura@gmail.com> wrote:
<= div dir=3D"ltr">I just revved the expired and archived draft so that it wil= l be easier for discussion around=C2=A0draft-hardt-oauth-distributed=C2=A0.=C2=A0
This is = the draft I mentioned during the meeting.=C2=A0 Previous versions had JSON = response as "_links" as well.=C2=A0

Best= ,=C2=A0

Nat=C2=A0

---------- Forwarded message ---------
From: <internet-drafts@= ietf.org>
Date: Wed, Nov 15, 2017 at 5:30 PM
Subject: New Vers= ion Notification for draft-sakimura-oauth-meta-08.txt
To: Nov Matak= e <nov@matake.jp&= gt;, Sascha Preibisch <sascha.preibisch@gmail.com>, Nat Sakimura <sakimura@gmail.com>= , Sascha Preibisch <Sascha.Preibisch@gmail.com>



A new version of I-D, draft-sakimura-oauth-meta-08.txt
has been successfully submitted by Nat Sakimura and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-sakimura-oauth-meta
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A008
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 OAuth Response Metadata
Document date:=C2=A0 2017-11-15
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-sakimura-oau= th-meta-08.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= https://datatracker.ietf.org/doc/draft-sakimura-oauth-meta/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://= tools.ietf.org/html/draft-sakimura-oauth-meta-08
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-sakimura-oauth-meta= -08
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-sakimura-oauth-<= wbr>meta-08

Abstract:
=C2=A0 =C2=A0This specification defines an extensible metadata framework th= at may
=C2=A0 =C2=A0be inserted into the OAuth 2.0 responses to assist the clients= to
=C2=A0 =C2=A0process those responses.=C2=A0 It is expressed either as a lin= k header, or
=C2=A0 =C2=A0query parameters.=C2=A0 It will allow the client to learn the = metadata
=C2=A0 =C2=A0about the particular response.=C2=A0 For example, the client c= an learn
=C2=A0 =C2=A0where the members in the response could be used, what is the =C2=A0 =C2=A0characteristics of the payload is, how it should be processed,= and so
=C2=A0 =C2=A0on.=C2=A0 Since they are just additional response header/query= parameters,
=C2=A0 =C2=A0any client that does not understand this extension should not = break
=C2=A0 =C2=A0and work normally while supporting clients can utilize the met= adata
=C2=A0 =C2=A0to take the advantage of the extension.




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

--

Nat Sakimura

Chairman of the Board, OpenID Foundation


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



<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --001a114fcc603abac7055e1371e4-- From nobody Wed Nov 15 22:53:48 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 A273E1293E0; Wed, 15 Nov 2017 22:53:40 -0800 (PST) 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.66.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151081522062.28382.10994186814431971263@ietfa.amsl.com> Date: Wed, 15 Nov 2017 22:53:40 -0800 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-discovery-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: Thu, 16 Nov 2017 06:53:41 -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 WG of the IETF. Title : OAuth 2.0 Authorization Server Metadata Authors : Michael B. Jones Nat Sakimura John Bradley Filename : draft-ietf-oauth-discovery-08.txt Pages : 23 Date : 2017-11-15 Abstract: This specification defines a metadata format that an OAuth 2.0 client can use to obtain the information needed to interact with an OAuth 2.0 authorization server, including its endpoint locations and authorization server capabilities. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-discovery/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-discovery-08 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-discovery-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-discovery-08 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 Nov 15 22:59: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 47D5C12957B for ; Wed, 15 Nov 2017 22:59:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 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_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 d6t-0wyuRekl for ; Wed, 15 Nov 2017 22:59:50 -0800 (PST) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0122.outbound.protection.outlook.com [104.47.32.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 041B21293E0 for ; Wed, 15 Nov 2017 22:59:49 -0800 (PST) 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=jN/Ngl/o+cq4CnlTePywJMN2iFb0p3+jlkOiAAeatkY=; b=TKAwWm1bbWxPGClBNPy2VqfbAmuLAU4QHbqua/qii7TfvMk8QMbrBHklFWrrB3siIxKDOi/84f6IdGtExF1RMyi2MF2GfpBoMSojoIa8zlpp4szc1HsqRekXrIi/oCNOZ2n2bV9ZT8IaWsaKv6TBTjDRy+r5jnhGFFSSRArDkYw= Received: from CY4PR21MB0504.namprd21.prod.outlook.com (10.172.122.14) by CY4PR21MB0117.namprd21.prod.outlook.com (10.173.189.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.260.2; Thu, 16 Nov 2017 06:59:48 +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.20.0260.001; Thu, 16 Nov 2017 06:59:48 +0000 From: Mike Jones To: "oauth@ietf.org" CC: "Shwetha Bhandari (shwethab)" , Brian Carpenter , Donald Eastlake , Dick Hardt , Mark Nottingham , Eric Rescorla Thread-Topic: OAuth Authorization Server Metadata spec incorporating IETF last call feedback Thread-Index: AdNepUsPsB7099u/QHiIzNlnKZ7aUw== Date: Thu, 16 Nov 2017 06:59:48 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [31.133.132.12] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0117; 6:UX8e+Te2EdD/CP6k4SmewjFC54T9xTXBaYiPQKw471DNFRvO27a7cvtSdYUhAh2bf3Q86nTkOAbg7esOiIL5pXIhZ1pqQAL7L4wfAmyjGh6V8SwuorC7ccmZY1zKp6Z2u8gdpMiiRT/qGNtT46Y31GihVppGkLfbaBOTzIg5aCuVyelRCr65jLsVOy2SYbvpWPx91Lpx3uv79E/f0ACRqDk7qv8E13PILNWCcgdlgFoKZeW+iEL5orpCMpNcH++U7OIxepko3hdK27LNVkzB1jDQlj1fvoDtS2vGlwDroXL6aD/BwqGCU8FI27NAgnoSQ/p30HscNqpg3tu0AwtT4DgHEgiNA3i7juaO3DmzC5M=; 5:JgsELwDXDlE9HUKVJi9Wda3JvsJtBjeJxSmuERiZDx6/95AhEx2otz55CGhKB0yk+mzFTQTg1zPfDrF1lBfgH42MOiO3r4c6xrboO6egemzgvR/cFtP1q1ylUJYo50TY9TpSZQeETc+sj38uNQbzO7pe1Btn3yPs+AwaQmTXXPs=; 24:Cgty4Jz4mBI0gUySsOtPKW4RtUjNdd3Rriq5XKluzcbeJELb69H0MNWuF9kgEGfWTfBGObIQfP1WGOtxWNx1Qfv7gmZWehCCwWPCqZ+0MRA=; 7:71mxbPMWTz10Ci0Mysf8UAQs6DxDIo/psks/J7OGPdj1uOHoHoXyNfHZ7i2uCOGiZ/M/dyu9JY+aOsw5lIFoU2TP3p9VNDP/XyFmWeIZj4jjQ0iJVw9dTjUa7BxGVuNDBgzhHgZ8aSHTfv+SQz7/P4UJfY0Uyj4Vh8V0EE3IKV2baCZE8adGAWBymOlO1zZhnsiardu8/bEhdIWdv+4PfP3AUja6CtnJEns4Io55/l4yvgES1iVj7zg8Vz0CUkUM x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: b46c0fe1-2899-4538-e270-08d52cbfa07f x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(2017052603258); SRVR:CY4PR21MB0117; x-ms-traffictypediagnostic: CY4PR21MB0117: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(31418570063057)(227612066756510)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(2401047)(8121501046)(5005006)(3231022)(3002001)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123562025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123558100)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR21MB0117; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR21MB0117; x-forefront-prvs: 0493852DA9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(346002)(376002)(209900001)(47760400005)(199003)(189002)(3660700001)(10090500001)(22452003)(74316002)(54906003)(2351001)(105586002)(54356999)(50986999)(101416001)(33656002)(106356001)(316002)(25786009)(66066001)(8936002)(7736002)(606006)(5660300001)(53376002)(2900100001)(39060400002)(9686003)(236005)(6306002)(10290500003)(54896002)(5630700001)(53936002)(2906002)(478600001)(6916009)(790700001)(102836003)(6116002)(3846002)(72206003)(966005)(4326008)(14454004)(7696004)(97736004)(3280700002)(189998001)(5640700003)(55016002)(6436002)(81156014)(68736007)(81166006)(1730700003)(8676002)(6506006)(86612001)(77096006)(86362001)(2501003)(8990500004)(99286004)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0117; H:CY4PR21MB0504.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB0504782BC5F9B1626E1520FAF52E0CY4PR21MB0504namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: b46c0fe1-2899-4538-e270-08d52cbfa07f X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Nov 2017 06:59:48.4498 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0117 Archived-At: Subject: [OAUTH-WG] OAuth Authorization Server Metadata spec incorporating IETF last call feedback 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, 16 Nov 2017 06:59:52 -0000 --_000_CY4PR21MB0504782BC5F9B1626E1520FAF52E0CY4PR21MB0504namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The OAuth Authorization Server Metadata specification has been updated to i= ncorporate feedback received during IETF last call. Thanks to Shwetha Bhan= dari, Brian Carpenter, Donald Eastlake, Dick Hardt, and Mark Nottingham for= their reviews. See the Document History appendix for clarifications appli= ed. No normative changes were made. The specification is available at: * https://tools.ietf.org/html/draft-ietf-oauth-discovery-08 An HTML-formatted version is also available at: * http://self-issued.info/docs/draft-ietf-oauth-discovery-08.html -- Mike P.S. This notice was also posted at http://self-issued.info/?p=3D1751 and = as @selfissued. --_000_CY4PR21MB0504782BC5F9B1626E1520FAF52E0CY4PR21MB0504namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The OAuth Authorization Server Metadata specificatio= n has been updated to incorporate feedback received during IETF last call.&= nbsp; Thanks to Shwetha Bhandari, Brian Carpenter, Donald Eastlake, Dick Ha= rdt, and Mark Nottingham for their reviews.  See the Document History appendix for clarifications applied.  No nor= mative changes were made.

 

The specification is available at:

 

An HTML-formatted version is also available at:=

 

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

 

P.S.  This notice was also posted at http://self-issued.info/?p=3D1751 and as @selfissued.

 

--_000_CY4PR21MB0504782BC5F9B1626E1520FAF52E0CY4PR21MB0504namp_-- From nobody Sat Nov 18 04:01:56 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 5947412025C for ; Sat, 18 Nov 2017 04:01:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.698 X-Spam-Level: X-Spam-Status: No, score=-0.698 tagged_above=-999 required=5 tests=[FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 HGo6SAqwWxu5 for ; Sat, 18 Nov 2017 04:01:51 -0800 (PST) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [IPv6:2a01:e0c:1:1599::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 4E03E1267BB for ; Sat, 18 Nov 2017 04:01:51 -0800 (PST) Received: from [192.168.0.13] (unknown [88.182.125.39]) by smtp6-g21.free.fr (Postfix) with ESMTP id 02CBB7802D7; Sat, 18 Nov 2017 13:01:47 +0100 (CET) To: oauth@ietf.org References: <150906263563.22135.3314949761020043351@ietfa.amsl.com> From: Denis Message-ID: <233601c8-43c9-3674-cfb8-dd4f9e24c16c@free.fr> Date: Sat, 18 Nov 2017 13:01:50 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <150906263563.22135.3314949761020043351@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------B709837B79EAB49A6532D61C" Content-Language: en-US Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-binding-05.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: Sat, 18 Nov 2017 12:01:54 -0000 This is a multi-part message in MIME format. --------------B709837B79EAB49A6532D61C Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Comments on draft-ietf-oauth-token-binding-05 Comments have been posted on draft-ietf-oauth-token-binding-02 (OAuth 2.0 Token Binding) and as far as I know have not received any feedback. See: https://www.ietf.org/mail-archive/web/unbearable/current/msg01316.html Hereafter is an update of the same comments applied to draft-ietf-oauth-token-binding-05. 1) The abstract states: This use of Token Binding protects these tokens from man-in-the-middle and token export and replay attacks. The use of Token Binding does not protect these tokens from token export in case of collusion between clients since this mechanism is not resistant to the ABC attack (Alice and Bob collusion attack). Replace with: This use of Token Binding protects these tokens from man-in-the-middle and token export and replay attacks but does not protect against token export in case of collusion performed by clients. 2) The introduction states: This cryptographically binds these tokens to a client's Token Binding key pair, possession of which is proven on the TLS connections over which the tokens are intended to be used. This use of Token Binding protects these tokens from man-in-the-middle and token export and replay attacks. The first sentence is correct while the second sentence is incorrect. The mechanism is not resistant to the ABC attack (Alice and Bob collusion attack).See: https://www.ietf.org/mail-archive/web/oauth/current/msg16767.html Replace with: This cryptographically binds these tokens to a client's Token Binding key pair, possession of which is proven on the TLS connections over which the tokens are intended to be used. This use of Token Binding protects these tokens from man-in-the-middle attacks, token export and replay attacks but does not protect these tokens in case of collusion performed by clients. 3) In section 4.2, the text states: "This binding ensures that the authorization code cannot successfully be played or replayed to the web server client from a different browser than the one that made the authorization request". This is incorrect: the use of Token Binding does not protect these tokens in case of a collusion between web server clients, e.g. the ABC attack (Alice and Bob collusion attack). Add afterwards: "However, in case of collusion between web server clients, the authorization code can successfully be played to the web server client from a different browser than the one that made the authorization request ". 4) Section 7 (Security Considerations) includes the following two subsections: 7.1.Phasing in Token Binding 7.2.Binding of Refresh Tokens It is important to mention that the mechanism is not resistant in case of a collusion between clients. Add a subsection with the following text: 7.3.Collusion attacks performed by clients This mechanism does not protect these bound tokens in case of a deliberate collusion between clients. A client may intentionally export a bound token with the corresponding Token Binding private key or perform signatures using this key on behalf of another client and then transmit both the bound token and the results to the other client. Denis > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Web Authorization Protocol WG of the IETF. > > Title : OAuth 2.0 Token Binding > Authors : Michael B. Jones > Brian Campbell > John Bradley > William Denniss > Filename : draft-ietf-oauth-token-binding-05.txt > Pages : 30 > Date : 2017-10-26 > > Abstract: > This specification enables OAuth 2.0 implementations to apply Token > Binding to Access Tokens, Authorization Codes, Refresh Tokens, JWT > Authorization Grants, and JWT Client Authentication. This > cryptographically binds these tokens to a client's Token Binding key > pair, possession of which is proven on the TLS connections over which > the tokens are intended to be used. This use of Token Binding > protects these tokens from man-in-the-middle and token export and > replay attacks. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-oauth-token-binding/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-oauth-token-binding-05 > https://datatracker.ietf.org/doc/html/draft-ietf-oauth-token-binding-05 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-token-binding-05 > > > 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 --------------B709837B79EAB49A6532D61C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Comments on draft-ietf-oauth-token-binding-05

Comments have been posted on draft-ietf-oauth-token-binding-02 (OAuth 2.0 Token Binding)
and as far as I know have not received any feedback. 
See: https://www.ietf.org/mail-archive/web/unbearable/current/msg01316.html

Hereafter is an update of the same comments applied to draft-ietf-oauth-token-binding-05.

1) The abstract states:

This use of Token Binding protects these tokens from man-in-the-middle and token export and replay attacks.

The use of Token Binding does not protect these tokens from token export in case of collusion between clients
since this mechanism is not resistant to the ABC attack (Alice and Bob collusion attack).

Replace with:

This use of Token Binding protects these tokens from man-in-the-middle and token export and replay attacks
but does not protect against token export in case of collusion performed by clients.

2) The introduction states:

This cryptographically binds these tokens to a client's Token Binding key pair, possession of which is proven
on the TLS connections over which the tokens are intended to be used. This use of Token Binding protects
these tokens from man-in-the-middle and token export and replay attacks.

The first sentence is correct while the second sentence is incorrect. The mechanism is not resistant to the ABC attack
(Alice and Bob collusion attack).See: https://www.ietf.org/mail-archive/web/oauth/current/msg16767.html

Replace with:

This cryptographically binds these tokens to a client's Token Binding key pair, possession of which is proven
on the TLS connections over which the tokens are intended to be used. This use of Token Binding protects these tokens
from man-in-the-middle attacks, token export and replay attacks but does not protect these tokens in case of collusion
performed by clients.

3) In section 4.2, the text states:

"This binding ensures that the authorization code cannot successfully be played or replayed to the web server client
from a different browser than the one that made the authorization request".

This is incorrect: the use of Token Binding does not protect these tokens in case of a collusion between web server clients,
e.g. the ABC attack (Alice and Bob collusion attack).

Add afterwards:

"However, in case of collusion between web server clients, the authorization code can successfully be played
to the web server client from a different browser than the one that made the authorization request ".

 

4) Section 7 (Security Considerations) includes the following two subsections:

7.1.  Phasing in Token Binding

7.2.  Binding of Refresh Tokens


It is important to mention that the mechanism is not resistant in case of a collusion between clients.
Add a subsection with the following text:

7.3.  Collusion attacks performed by clients

This mechanism does not protect these bound tokens in case of a deliberate collusion between clients.
A client may intentionally export a bound token with the corresponding Token Binding private key or perform signatures
using this key on behalf of another client and then transmit both the bound token and the results to the other client.

Denis


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol WG of the IETF.

        Title           : OAuth 2.0 Token Binding
        Authors         : Michael B. Jones
                          Brian Campbell
                          John Bradley
                          William Denniss
	Filename        : draft-ietf-oauth-token-binding-05.txt
	Pages           : 30
	Date            : 2017-10-26

Abstract:
   This specification enables OAuth 2.0 implementations to apply Token
   Binding to Access Tokens, Authorization Codes, Refresh Tokens, JWT
   Authorization Grants, and JWT Client Authentication.  This
   cryptographically binds these tokens to a client's Token Binding key
   pair, possession of which is proven on the TLS connections over which
   the tokens are intended to be used.  This use of Token Binding
   protects these tokens from man-in-the-middle and token export and
   replay attacks.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-token-binding/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-oauth-token-binding-05
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-token-binding-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-token-binding-05


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


--------------B709837B79EAB49A6532D61C-- From nobody Tue Nov 21 02:19:15 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 48E0B129439 for ; Tue, 21 Nov 2017 02:19:13 -0800 (PST) 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=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 DVz8T01HPt8B for ; Tue, 21 Nov 2017 02:19:10 -0800 (PST) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8F8E129461 for ; Tue, 21 Nov 2017 02:19:10 -0800 (PST) Received: by mail-qk0-x232.google.com with SMTP id f63so11268900qke.8 for ; Tue, 21 Nov 2017 02:19:10 -0800 (PST) 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=OXfCmEvAzZDwbdAOt+QwSif1avj/YPBv3x8Zdig/fs8=; b=t3v0MYcyQlOtG9IUzcm04enb0KdtcUWbk86ZFQltp8i4V9WcrnGuLpn9103C2V+U9Y SbnfNCtKr35976wRbZs5BKboyKSga6SN71F1GoqfcZwJEKhAqlOHase0KWKkEWBVsoqD samx32oq1Df7p3VaRczdlmdQaAR5J34URYZ2DrafqRET2k+f21gMpECNaLGPHjgZzif2 ntr/n1nGinK7UvfAe9ZY8QxMVrtK6wl7FXBHQMXdaJaKmIcgFgntUHtBP+HuWyoivBsX Z87fVtPphTgkf5Mdff2Sh9QbJhXHbzS5E1ebX52bV8vjlcNbC51N38KFOGYmrKmfLtkC b5pg== 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=OXfCmEvAzZDwbdAOt+QwSif1avj/YPBv3x8Zdig/fs8=; b=XRAweanFsplxXnPalbYFfE4Bviylqf8k4qjEoHgb6x+gk/OJZVt4GKRF85WNRCZ1Ib 5oSYHAX28latgQbLk5RXCqkm16Ai76pH3lca4Z+VrWh28823vxo9iPk8MVdLk8x8FL+v iQUAILeF4zWpax7dpbDIHAYEuJrXAX7GwR2+wKuOFB4DmMgXEdEHZ06WQTSM5XcGoG4F 0fnLal3D7QbQPYazctkpX+FpytxkMCq+y/u1sdLFqksUIxuzFPJPqW2xxcps9vRtFEIV H8FgKHSRJEk9lODIHvycDzL1iFGR/nrupLowAlwsclXM2o1Y6qBZkGecKExo9mEQmmMo VEEw== X-Gm-Message-State: AJaThX5L2Uvlu3nJMtzhpvPRHLSP3ZOJvhgYxJ6xlaIfoK43BheeOFci 0zVB0rdR6l8bOlISMsUfvwwLp8oIBz3HUSJUPAg4n+mnxq8= X-Google-Smtp-Source: AGs4zMZhPf2eUdRQ7xR7fnkrf+QPXlOC5/EvXMUSi1ta6LD5mD/VuoHS2Lo9+jvXsRnegAoyx65XhjUFVM8fF0/TNvY= X-Received: by 10.55.71.5 with SMTP id u5mr9322992qka.166.1511259549579; Tue, 21 Nov 2017 02:19:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.3.84 with HTTP; Tue, 21 Nov 2017 02:19:09 -0800 (PST) In-Reply-To: References: <151125895956.14726.11740003659885129774.idtracker@ietfa.amsl.com> From: Samuel Erdtman Date: Tue, 21 Nov 2017 11:19:09 +0100 Message-ID: To: "" , ace Cc: Ludwig Seitz , Marco Tiloca Content-Type: multipart/alternative; boundary="001a114a8d4a9dcf0e055e7b881d" Archived-At: Subject: [OAUTH-WG] Fwd: New Version Notification for draft-erdtman-oauth-rpcc-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: Tue, 21 Nov 2017 10:19:13 -0000 --001a114a8d4a9dcf0e055e7b881d Content-Type: text/plain; charset="UTF-8" Hi, I have submitted draft-erdtman-oauth-rpcc under the OAuth WG as discussed during IETF 100. (Moved from ACE WG since the new credentials does not have any formal connection to the ACE documents, i.e. pure OAuth stuff) This document defines how to user Raw-Public-Key and Pre-Shared-Key with (D)TLS as client credentials. We think it is essential to define this for IoT devices since the classic client id and secret is not very suitable for devices with limited user interfaces. Comments, questions and reviews would be very appreciated. Cheers //Samuel ---------- Forwarded message --------- From: Date: Tue, 21 Nov 2017 at 11:09 Subject: New Version Notification for draft-erdtman-oauth-rpcc-00.txt To: Marco Tiloca , Ludwig Seitz , Samuel Erdtman A new version of I-D, draft-erdtman-oauth-rpcc-00.txt has been successfully submitted by Samuel Erdtman and posted to the IETF repository. Name: draft-erdtman-oauth-rpcc Revision: 00 Title: Raw-Public-Key and Pre-Shared-Key as OAuth client credentials Document date: 2017-11-20 Group: Individual Submission Pages: 6 URL: https://www.ietf.org/internet-drafts/draft-erdtman-oauth- rpcc-00.txt Status: https://datatracker.ietf.org/doc/draft-erdtman-oauth-rpcc/ Htmlized: https://tools.ietf.org/html/draft-erdtman-oauth-rpcc-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-erdtman-oauth- rpcc-00 Abstract: This document describes Transport Layer Security (TLS) authentication using Raw-Public-Key and Pre-Shared-Key as new mechanisms for OAuth client authentication. Although defined for TLS the mechanisms are equally applicable for DTLS. 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 --001a114a8d4a9dcf0e055e7b881d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I have submitted draft-erdtman-oa= uth-rpcc under the OAuth WG as discussed during IETF 100. (Moved from ACE W= G since the new credentials does not have any formal connection to the ACE = documents, i.e. pure OAuth stuff)

<= /div>
This document defines how to user Raw-Publi= c-Key and Pre-Shared-Key with (D)TLS as client credentials.

We think it is essent= ial to define this for IoT devices since the classic client id and secret i= s not very suitable for devices with limited user interfaces.

Comments, questions= and reviews would be very appreciated.
Cheers
//= Samuel



=
A new version of I-D, draft-erdtman-oauth-rpcc-00.txt
has been successfully submitted by Samuel Erdtman and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-erdtman-oauth-rpcc
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Raw-Public-Key and Pre-Shared-Key = as OAuth client credentials
Document date:=C2=A0 2017-11-20
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 6
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-erdtman-oauth= -rpcc-00.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0h= ttps://datatracker.ietf.org/doc/draft-erdtman-oauth-rpcc/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://t= ools.ietf.org/html/draft-erdtman-oauth-rpcc-00
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-erdtman-oauth-rpcc-0= 0


Abstract:
=C2=A0 =C2=A0This document describes Transport Layer Security (TLS) authent= ication
=C2=A0 =C2=A0using Raw-Public-Key and Pre-Shared-Key as new mechanisms for = OAuth
=C2=A0 =C2=A0client authentication.=C2=A0 Although defined for TLS the mech= anisms are
=C2=A0 =C2=A0equally applicable for DTLS.




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


--001a114a8d4a9dcf0e055e7b881d-- From nobody Thu Nov 23 08:14: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 639BA12EB56; Thu, 23 Nov 2017 08:14:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 eWFPeKHROdYw; Thu, 23 Nov 2017 08:14:25 -0800 (PST) Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D016C12EB4D; Thu, 23 Nov 2017 08:14:24 -0800 (PST) Received: by mail-ua0-x22f.google.com with SMTP id 21so13081059uas.13; Thu, 23 Nov 2017 08:14:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=PvNJARz11D82m72nNRQuQUfkbFaZpVO56j3LKxLq5qE=; b=ArrvrSl5pv4RclfcM74JfiVoTx8txMpngicLJHNATU+kFFgjvodKVVWHrOmrrtHM1x T/ggGu69Gf6zEA8Lgrn4qjtpWT/UxU79By0S876hH3e9MtZLnYbLaTND9kxbfZ0VjACE 5xn4t/qObh8JruJ5fLnCNspYWDdzWLpYa2Lj1t1fw2RZGwygJEiqqeebxd3+XjMag435 D22jAGKVduKlK5MhMa5NlbtW0pSdOLM0yVo768GLOkOK9XPKMu8sC8kJpoC8m4CZzWfx pAOPFqPQnd5e8Y5AolaLOf6pZq/Ih7/1LRShIYKq82bC2xvQjYwvvvotY+HuH7bVFuAE lDnw== 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=PvNJARz11D82m72nNRQuQUfkbFaZpVO56j3LKxLq5qE=; b=hond6QUwl2nCInw8EuHTKJqH7mvALDh7TlcEE8fCFyl1IXt4jqgWTzDtGensK4L2ZH g4nFKqKZVlKiQZlmkefy5fFjaxalPqPQGNhjKDYAxTxCkWy+yZXX1l1zWxNlRn7bcpAi KDmV5xVjVeAT73ltUhBAjZOue3H7mCYqWy5IZgtdCT9oi6PYlVzx9+Z/s0l8ny6y2Efl e5NFieENOp02qsekd86LfJA1UICq4CB+HOxeHj1LQwfqunZ+rVdcVX7R+CriVwbR+5jE TWCnzZSuh7LSUHFPkx8dtjpdGasxVO2LdxXru/nw41qh5Oo2fGXgQQxcaGFlge9Fv4KC J7/w== X-Gm-Message-State: AJaThX6coY/8TgN5lGiDd3+fKB0FvIUHTxNdCjDS58AoHZWFIyK+Lu2Z y0ai8VKA0w3ErBlkKuC0E8pIjh9tllDY/ctkO7txgGPZ X-Google-Smtp-Source: AGs4zMZOGOry+msjWO/TebWVC1miYCqT6XSupKfnOF81EHFOygizwDm/NkgKUYSGARp3zyd0z71vVfHUgwKYhK2NvUI= X-Received: by 10.176.93.25 with SMTP id u25mr19998478uaf.73.1511453663745; Thu, 23 Nov 2017 08:14:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.68.162 with HTTP; Thu, 23 Nov 2017 08:14:23 -0800 (PST) From: Rifaat Shekh-Yusef Date: Thu, 23 Nov 2017 11:14:23 -0500 Message-ID: To: draft-ietf-oauth-token-exchange.all@ietf.org, oauth Cc: Hannes Tschofenig Content-Type: multipart/alternative; boundary="f403045db38cb8dca7055ea8ba00" Archived-At: Subject: [OAUTH-WG] Token Exchange - IPR Disclosure 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, 23 Nov 2017 16:14:26 -0000 --f403045db38cb8dca7055ea8ba00 Content-Type: text/plain; charset="UTF-8" Authors, As part of the write-up for the Token Exchange document, we need an IPR disclosure from all of you. Are you aware of any IPR related to the following Token Exchange document? https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/ Regards, Rifaat --f403045db38cb8dca7055ea8ba00 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Authors,

As part of the write-up for th= e Token Exchange document, we need an IPR disclosure from all of you.
=

Are you aware of any IPR related to the following Token= Exchange document?

Regards,
=C2=A0Rifaat

--f403045db38cb8dca7055ea8ba00-- From nobody Thu Nov 23 08:18:01 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 3265E12EB64 for ; Thu, 23 Nov 2017 08:18:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 a4B0tnZdSHVC for ; Thu, 23 Nov 2017 08:17:59 -0800 (PST) Received: from mail-ua0-x234.google.com (mail-ua0-x234.google.com [IPv6:2607:f8b0:400c:c08::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 8733712EB75 for ; Thu, 23 Nov 2017 08:17:56 -0800 (PST) Received: by mail-ua0-x234.google.com with SMTP id f14so13096553uaa.5 for ; Thu, 23 Nov 2017 08:17:56 -0800 (PST) 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=VbJo0vASkmr9sQ1NHpEgV/UeP/Lt+sIIjeT0jsXG/ns=; b=HRoOvF+M2fSh4DNVhE9p10ep/bvdUOjfmyXKEVG1yrCwRtvuP9FPS8JKLPJpScl6tW cspH8oQlXiE6KODQzdJc473H0SVs2AK+YV6fHOkxCOuzjeSDQk2KaDVfzlRIZOkAeFnm 4k09JYxcm/jM6b0Mp2+NqgW9hk/lohk7uN+RYN8JtOGBtniZbao8gHHwepAqNo+sWFxM RupQO08ePpWO7p37IUfZVwx14OJg3Dp8DaC71XfCpMrabnbS6KcQ4ERU3gVYwCCML2UO /qBevLpeFOPjhH6+6UVyktCYHuJWkuQjdPZ5lSJoKGUS91B58XhgNqE0cA8Y68Nw1Qx8 svpw== 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=VbJo0vASkmr9sQ1NHpEgV/UeP/Lt+sIIjeT0jsXG/ns=; b=sDMjDkGgrRpeMiphycG/H0Ljcs3LPFY9yqEWJEho54014Lu3/PmJhGQXDepDZHeXao hPk7bykEsT7gx8XaCPFaEwf1c4n9TwYg2HRuhZ9398BFmLqGfRUjGPODQs2j21nqhEnq 19RfHwITROQoibogZqd5+xxbItmwzB4iM1u4oo+8q716XC66l1w1kKIJSehvTuCEJb2E sKr5FoVavvwNgBR7cQha+qYu4y5It4luuRsbiD6dy/BmVhzd0uE/s+gf5qkp9MJ2uPsY C1CjMEpLtCglrr0eMxB7PDC1Tc1xGCopcL2orfPBZIQfFIrQkccKz/aGRrWyF32/38ch 0n8A== X-Gm-Message-State: AJaThX46m2kLcQre5MSkz4vpibZ43rCHxml28+d8hEN0tDyQGGoUUv+i E81PWLx4Pczcx9/EgrOg2HLyfG61KOLaY4MpLrv4LDxq X-Google-Smtp-Source: AGs4zMYk46lVMZHwiYADzVSf5PO0RF9WDnn7j+ql4ChATs/C4ym11cVxSVs8XaKvpWA3o2sw7blorGf9P0ybEzETM6I= X-Received: by 10.176.89.176 with SMTP id g45mr1046046uad.196.1511453875407; Thu, 23 Nov 2017 08:17:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.68.162 with HTTP; Thu, 23 Nov 2017 08:17:54 -0800 (PST) From: Rifaat Shekh-Yusef Date: Thu, 23 Nov 2017 11:17:54 -0500 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="001a11465d5a568eda055ea8c709" Archived-At: Subject: [OAUTH-WG] Token Exchange Implementations 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, 23 Nov 2017 16:18:00 -0000 --001a11465d5a568eda055ea8c709 Content-Type: text/plain; charset="UTF-8" All, As part of the write-up for the Token Exchange document, we are looking for information about implementation for this document. We are aware of 3 implementations for this document by: Salesforce, Microsoft, and Box. Are people aware of any other implementation? Regards, Rifaat --001a11465d5a568eda055ea8c709 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
All,

A= s part of the write-up for the Token Exchange document, we are looking for = information about implementation for this document.
We are aware of 3 implementations for this document by: Salesf= orce, Microsoft, and Box.

Are people aware of = any other implementation?

Regards,
= =C2=A0Rifaat

--001a11465d5a568eda055ea8c709-- From nobody Thu Nov 23 09:36: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 A7D13129474; Thu, 23 Nov 2017 09:36:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.8 X-Spam-Level: X-Spam-Status: No, score=-4.8 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_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 LNaM_5gdnhf5; Thu, 23 Nov 2017 09:36:08 -0800 (PST) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0137.outbound.protection.outlook.com [104.47.37.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 C9A29129467; Thu, 23 Nov 2017 09:36:08 -0800 (PST) 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=p878iHKCdiSmvrt0LgFYj7VX3goppoNCuy4SIWevHZA=; b=I+9bhYUaYXYA6Co4jUg1cK2B9HBO4AIgq1pRM6MTEw/BXBZY0ar8Li8hBiptnp1duAUAKSNfLZdfuUpPs8A84Wh029ApJwExrU4rI0Ar487nAFG75z2Yj1bxP2fyP3k7H/7TTAAyKrpAVCVQCyBV352O+pqIb2NcVbp/cN41D2k= Received: from CY4PR21MB0504.namprd21.prod.outlook.com (10.172.122.14) by CY4PR21MB0789.namprd21.prod.outlook.com (10.175.121.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.282.3; Thu, 23 Nov 2017 17:36:06 +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.20.0282.004; Thu, 23 Nov 2017 17:36:06 +0000 From: Mike Jones To: "draft-ietf-oauth-token-exchange.all@ietf.org" , oauth , Rifaat Shekh-Yusef CC: Hannes Tschofenig Thread-Topic: Token Exchange - IPR Disclosure Thread-Index: AQHTZHYkTmuegnt/5EGudmbmLaDz+qMiOihw Date: Thu, 23 Nov 2017 17:36:06 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [104.208.33.187] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0789; 6:G+Q6AV0OirnJIxZG8itJWTaMxAq6DB93Y3Y3/j2yshWCOqkBLgolHgPz1edVcU2rP6cg1iTu3V+Fp91M+7HHxRB8I1ADYh6JF7gslpx/XgYcAz56bao/qK7NZQfFK4MFKOMRcMZpvR8W+Wd9fv7RVo9/Alj4vGsmy37zmXtY5rNs1jL/TdcYqwl5so6wF12LEHeSjVx+pekeDSbF9qRJjog4hXJeujtjZ7/40+Tu379eVwaqr85pKe64mvXK8cDtbFZ07bTD/+chJc/ehyCrB/Xf3HsolxEOD/8Rsr0Kotyk/9C+BEzVza5RkiyJnxVCTllbE+xlRCbjtIswmFqpjkYHRs00+dG8bfShE2NDQZg=; 5:WfSbZaB2iHzV+wJh31AZ7od1S4MYf6JcFjiJfJXZJ64GoqN95N+XK5oETsGr9Dz2xBx/R1Cu/0/J403Ql0jxcrgGLpfLv0Q5rhZuw2HeieoIwDfiZa+4tEwKuYUgTkfO7ZCGGqfWN0GhBAW62ckaLJ60IIkFV+KoG8ZZ0dN0RRQ=; 24:KNO1o154plFjM7uUiiRGLJw1OUu+Ky1woHDIVdrDPti876pp3QEi7W5Cz/jF2PL8I5Z2e+xteMdjMamrEFN76LCTetnh4FKzie253LYOZc4=; 7:frvJeZnDntoqAY7QXUhfWEoy6yrXzKszB0lGjUIUIjQVSXymN6Gpoy1Ns+SHufpa6zLOIzYyMvuoTYSCkxxr+grLHNXCiHXf/bdgdPxrPmhf8JjJZCzUG8FohubyluQmx5RUiDD/EoJLjanc/eMOzxUfSd/4Ubkzp+aZVlWFbTK2mfZBTI+adZwuWqKbpzwPbDP/akgLRZ2XjsQZnqdoANoxs4YGOsNtYHeu4SPejaZe4LmDqXV6na3XqUGnhCEU x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: f6c6f65b-e236-40d9-88da-08d53298ad1b x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600025)(4604075)(48565401081)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603258); SRVR:CY4PR21MB0789; x-ms-traffictypediagnostic: CY4PR21MB0789: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(3002001)(93006095)(93001095)(10201501046)(3231022)(6055026)(61426038)(61427038)(6041248)(20161123555025)(20161123564025)(20161123562025)(20161123558100)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR21MB0789; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR21MB0789; x-forefront-prvs: 05009853EF x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(366004)(376002)(39860400002)(47760400005)(189002)(199003)(189998001)(25786009)(4326008)(6246003)(10290500003)(99286004)(14454004)(72206003)(966005)(478600001)(66066001)(606006)(53546010)(7696005)(39060400002)(3846002)(81166006)(81156014)(102836003)(6116002)(10090500001)(101416001)(229853002)(54896002)(50986999)(76176999)(6306002)(54356999)(8676002)(110136005)(3660700001)(8936002)(55016002)(7736002)(77096006)(6506006)(2900100001)(74316002)(33656002)(6436002)(53936002)(97736004)(22452003)(2950100002)(86362001)(2906002)(106356001)(2501003)(236005)(5660300001)(105586002)(86612001)(8990500004)(316002)(3280700002)(9686003)(68736007); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0789; H:CY4PR21MB0504.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB05042B45BDE7A7EF350BBCABF5210CY4PR21MB0504namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: f6c6f65b-e236-40d9-88da-08d53298ad1b X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Nov 2017 17:36:06.1755 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0789 Archived-At: Subject: Re: [OAUTH-WG] Token Exchange - IPR Disclosure 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, 23 Nov 2017 17:36:11 -0000 --_000_CY4PR21MB05042B45BDE7A7EF350BBCABF5210CY4PR21MB0504namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am not aware of any IPR on the Token Exchange document. -- Mike ________________________________ From: Rifaat Shekh-Yusef Sent: Thursday, November 23, 2017 8:14:23 AM To: draft-ietf-oauth-token-exchange.all@ietf.org; oauth Cc: Hannes Tschofenig Subject: Token Exchange - IPR Disclosure Authors, As part of the write-up for the Token Exchange document, we need an IPR dis= closure from all of you. Are you aware of any IPR related to the following Token Exchange document? https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/ Regards, Rifaat --_000_CY4PR21MB05042B45BDE7A7EF350BBCABF5210CY4PR21MB0504namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I am not aware of any IPR on the Token Exchange document.

-- Mike
From: Rifaat Shekh-Yusef &l= t;rifaat.ietf@gmail.com>
Sent: Thursday, November 23, 2017 8:14:23 AM
To: draft-ietf-oauth-token-exchange.all@ietf.org; oauth
Cc: Hannes Tschofenig
Subject: Token Exchange - IPR Disclosure
 
Authors,

As part of the write-up for the Token Exchange document, we need an IP= R disclosure from all of you.

Are you aware of any IPR related to the following Token Exchange docum= ent?

Regards,
 Rifaat

--_000_CY4PR21MB05042B45BDE7A7EF350BBCABF5210CY4PR21MB0504namp_-- From nobody Thu Nov 23 12:14:02 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 B8648120727 for ; Thu, 23 Nov 2017 12:14:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 vyToMrf3JqUX for ; Thu, 23 Nov 2017 12:13:59 -0800 (PST) Received: from mail-ot0-x234.google.com (mail-ot0-x234.google.com [IPv6:2607:f8b0:4003:c0f::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 9A68D12708C for ; Thu, 23 Nov 2017 12:13:58 -0800 (PST) Received: by mail-ot0-x234.google.com with SMTP id o23so17152819otd.1 for ; Thu, 23 Nov 2017 12:13:58 -0800 (PST) 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=bfNNVgk9F5dO8LW0ubsgXMQAQP7FLueQDkJIJm0hwIc=; b=oqy5pjoXZLoiq174wfVVT6KufnxpjsUxlfcqMVYwz9As+WBjEtgfRyNd8wKhFfB7iI wkyq/vNzR4dOl/7HojMJO4t0EZRGQvDMUBjM0B2nD7O9+dhcwyrxQYHW19fBESoJsX1n BgaD2UD1+DF1saMAAb7Ss3seDcf4SDL/4ahGcCnhxA2etIxy0UxKnDSr4RRgT7TAVshO txh/pHqNaJlbJDjjfFLC0Sgz+VTlN2BNyGLWjCTAnVLGeGML1i5C6LREHTiYmwBwmByB ++cwPSbMCWF7a14b/A1dpGP1D46Bb0aOa5pKNfNEhQ+7MqKrdmaWqFl6302aE1dAvSXT vF+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:cc; bh=bfNNVgk9F5dO8LW0ubsgXMQAQP7FLueQDkJIJm0hwIc=; b=cnV25WnEkHJ6rW4hFDDMYv2djwSvEKe1uRvtaWAN+0rkVkBBWASCOmwnsRpMaZ281R xxJZj1fF4V7o58PS3LVRHxJrnOcRVS5c8OGRee4TGFPLIVY7G0OIoR9U2A+1iZTdndPG v+fu1ghI4q2muCiNhcqi1nvU+PLG/XmXvkx67+RdUSuXHMcXOwgrFweWHJqO1R76js/0 7XTB+uZWY1gLUS0WhrzzzyOdZIAqijsvMlrqDi7HpwXmB9WV3EvNAXHbHFR8TPhgx4Lm vR46/3R6IjGzLoQPzoNOZRyAyxX7IjmDdB/TTDwDMGpTcTchDBN6zdU0yzigmr8/ki3g 3OyA== X-Gm-Message-State: AJaThX6tnkllB+iibVwhNwoOxr0TqzbKzgdl6M8IegKB8vCgTLaH9Pn2 I53vF9J9hv1XGHUy0akWh9+JDayKoOXQ0e/pjINJgA== X-Google-Smtp-Source: AGs4zMb5lxRKqBcwU6kd2yeXpc+b41CG7a1W7oynrbLCDArG0Co7FtgSKWGzDWeXBXQ3SNAZpJV5OnkC6gIYpHc+RMI= X-Received: by 10.157.27.80 with SMTP id l74mr7825535otl.255.1511468037603; Thu, 23 Nov 2017 12:13:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.3.16 with HTTP; Thu, 23 Nov 2017 12:13:56 -0800 (PST) Received: by 10.157.3.16 with HTTP; Thu, 23 Nov 2017 12:13:56 -0800 (PST) In-Reply-To: References: From: John Bradley Date: Fri, 24 Nov 2017 05:13:56 +0900 Message-ID: To: Rifaat Shekh-Yusef Cc: draft-ietf-oauth-token-exchange.all@ietf.org, IETF oauth WG , Hannes Tschofenig Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="94eb2c0b8b02800d48055eac13e0" Archived-At: Subject: Re: [OAUTH-WG] Token Exchange - IPR Disclosure 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, 23 Nov 2017 20:14:01 -0000 --94eb2c0b8b02800d48055eac13e0 Content-Type: multipart/alternative; boundary="94eb2c0b8b0278b32b055eac1379" --94eb2c0b8b0278b32b055eac1379 Content-Type: text/plain; charset="UTF-8" I am not aware of any IPR on the token exchange document. On Nov 23, 2017 8:14 AM, "Rifaat Shekh-Yusef" wrote: > Authors, > > As part of the write-up for the Token Exchange document, we need an IPR > disclosure from all of you. > > Are you aware of any IPR related to the following Token Exchange document? > https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/ > > Regards, > Rifaat > > --94eb2c0b8b0278b32b055eac1379 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I am not aware of any IPR on the token exchange document.= =C2=A0

On No= v 23, 2017 8:14 AM, "Rifaat Shekh-Yusef" <rifaat.ietf@gmail.com> wrote:
Authors,

As part of the write-up for the Token Exchange document, we need an= IPR disclosure from all of you.

Are you aware of = any IPR related to the following Token Exchange document?

Regards,
=C2=A0Ri= faat

--94eb2c0b8b0278b32b055eac1379-- --94eb2c0b8b02800d48055eac13e0 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 FbowDQYJYIZIAWUDBAIBBQCggdQwLwYJKoZIhvcNAQkEMSIEILsBta4j2G/IrJU/Kn7HHW6PzkXH TeC5wNJOiBhhtqBxMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE3 MTEyMzIwMTM1OFowaQYJKoZIhvcNAQkPMVwwWjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzALBgkqhkiG9w0BAQowCwYJKoZIhvcNAQEHMAsGCWCGSAFl AwQCATANBgkqhkiG9w0BAQEFAASCAQCq+1bQKYnwTIh9BhaELaNecyIx9a7hBjwGAA1lV3ffjngi kSsS20o57tePQi6k7N5XFogJLfblc4pPTfYRUi/MvdT36YNJ4YP/QQpW/RgkvPiFCst/tFf4ypcp V+MrEleXkDi0oYerQEF4ATxHvGVt475EDVHhNHMz2MSNU6608GoRN0NTNUzQ4kTZazD0hsGHRCCp jOdvHTDbWItqnZEepFEeqIkEx3HigyvBARBIzBqnziooF92hi5UHprPud+F6Zzl3yn27jI5vCASN vx4hPuacCu5PL01W59ChB6I2I3E8cl/VtwXyBR5NBybV5C1Y0S00yCpgeuuIfARNx1+z --94eb2c0b8b02800d48055eac13e0-- From nobody Mon Nov 27 04:17:13 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 663B712896F for ; Mon, 27 Nov 2017 04:17:11 -0800 (PST) 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=unavailable 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 otX_56BEqTVG for ; Mon, 27 Nov 2017 04:17:09 -0800 (PST) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::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 ED5DE127011 for ; Mon, 27 Nov 2017 04:17:08 -0800 (PST) Received: by mail-io0-x234.google.com with SMTP id u42so36042896ioi.9 for ; Mon, 27 Nov 2017 04:17:08 -0800 (PST) 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=vcOV3rGnGI1u0f6AKj8zJ50DcQk+ZNgnP09oWOOfOF0=; b=jTstayphosc4Tovdz/cVpAIyrcZuRvrJRO32LtFeFDjEZOouurgw7TnTL+AsgpI7bh rHdmAhHERynGGRL75GB6pSZjkRdy0U2U62DRHQawaLyKKD4dmwZqPEmNO+AwMyFBRKdK P/eVhhNP/KiZMmqEpWFavJzhoRNq5xi8F0Wrg= 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=vcOV3rGnGI1u0f6AKj8zJ50DcQk+ZNgnP09oWOOfOF0=; b=s1sOUR7nh95smmoTruNeMFLC5euF1/6lY61d8PKuKbHqy88uV7hTjfFIElaylWRmRA aPOa9kSY14/6cECwQq2ANiPybJuBdbN5NgxwelyB+6RZix/LwWrg639ayJ7FQqoY35Vh eeSQN8F5+wN2uVA9IRsYIBVTGFJoXEBUAxuMeRnpLr7h6C7kMTUbT/wllY1gfIy1uwNk C2/+Xujn7AjyP0XJTxlqmOAuRRDQhEdc3Cds14Ici1oq8uSflJ8xc2PfEfMKNmVQ/VH5 EDKCH/IqlxeOK1D7Acr45L5xnzDL/yqpVArBNI9DUfMZD3fldJ0NKcoSKDNf5mC3BAuj 17+w== X-Gm-Message-State: AJaThX4h12tKtZ8O47ZqZYc7pFMTC1x5bCwu/MTEoel9HzWZvXoaem+m F+edGmywU7XGX3vEWZzuchGHnCKm3HDW5mTttPtwz49PH8Kn101Pba2xvTKIkmoXgFIToe0Kw+j vpRpTE6fgElThNw== X-Google-Smtp-Source: AGs4zMaGZYrvNHEhrO2AFCOQ/53xLvWejLzbjKjiAp+SOFIpgCqci4pAXUE6AERQ442ci4q8PC+fYO/j/fvZke27x5g= X-Received: by 10.107.170.40 with SMTP id t40mr44334081ioe.73.1511785028173; Mon, 27 Nov 2017 04:17:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.2.118.194 with HTTP; Mon, 27 Nov 2017 04:16:37 -0800 (PST) In-Reply-To: References: From: Brian Campbell Date: Mon, 27 Nov 2017 05:16:37 -0700 Message-ID: To: Rifaat Shekh-Yusef Cc: draft-ietf-oauth-token-exchange.all@ietf.org, oauth , Hannes Tschofenig Content-Type: multipart/alternative; boundary="001a1142d86e94de3c055ef5e1ee" Archived-At: Subject: Re: [OAUTH-WG] Token Exchange - IPR Disclosure 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, 27 Nov 2017 12:17:11 -0000 --001a1142d86e94de3c055ef5e1ee Content-Type: text/plain; charset="UTF-8" I am not aware of any IPR on the token exchange document. On Thu, Nov 23, 2017 at 9:14 AM, Rifaat Shekh-Yusef wrote: > Authors, > > As part of the write-up for the Token Exchange document, we need an IPR > disclosure from all of you. > > Are you aware of any IPR related to the following Token Exchange document? > https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/ > > Regards, > Rifaat > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > -- *CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.* --001a1142d86e94de3c055ef5e1ee Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I am not aware of any IPR on the token exchange document. =

On Thu,= Nov 23, 2017 at 9:14 AM, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:


<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --001a1142d86e94de3c055ef5e1ee-- From nobody Mon Nov 27 05:55: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 4E169128B8D for ; Mon, 27 Nov 2017 05:55:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 NVOcyQIiyFtF for ; Mon, 27 Nov 2017 05:55:27 -0800 (PST) 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 BE792128B37 for ; Mon, 27 Nov 2017 05:55:26 -0800 (PST) Received: by mail-ua0-x22a.google.com with SMTP id 31so13861557uaj.6 for ; Mon, 27 Nov 2017 05:55:26 -0800 (PST) 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=D7JkER18yqxo1G1Nwb9JnPSk7g/lzqtkmW1+fCpqaTc=; b=QgRnFhM6MKgNF0jyO8c3Cm6L5ATSILUxJDKTNAHN9BNBydaCqzZAYaeSXJl9CnurGb G4k7fXsYIndlJZtvZgk5SVi2iJQYPaZkochd/s2SRaGwAM7/kWEhIlL/fOOzyhdGImer tr+O+2YHAOA5frqNLATfFO6oneVOPLgQfDpVNX2HnqYVo9tLjp+ur7YczoOU5PWmpDx1 +N0RVi2BIOOrtEY6b0h0XrKIeb5u6eHi9K4k2WZp2svQA0owaoBPcdg2h13DmH680g14 kAlL6PsMaiBiX/m9bVZILm2kY4tU7keUJLp+GiHZ92sBKeDGm3P9EV0/kFF3xWppCQET qZNA== 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=D7JkER18yqxo1G1Nwb9JnPSk7g/lzqtkmW1+fCpqaTc=; b=Sta9Cjyj+Ucjj9dtKLSNxiiBJvEUO48y6d7mkgdeEtNfaSOI2vZUzrxyLH6fpMwYLk JC6ecY4wzKxz6qLY3+fKckgJgy7tVYgps59HW0RDzIWlNTxNvFcS7yfqJ6H8FZfgPLBR Cp+i2QK5gzDhZbh9djUDPg2VmqRxfBG02XNd0bGsVIyu5/HWa6zyBGAdu5xa+nUue45b K1dQel3+a8PnxWY66CaUNSSYO9doPy+ijZj1dvttIwKdPJP/tDi3FdXNgt6RAPZKDB7t HDbe/uoJsNdUKiZNMxu3q03jRasIKxdiB/NvlBvj+Oiv9/K420VtKFH/kkBSvJD4cWTq 7x9Q== X-Gm-Message-State: AJaThX7ufnj0x8+BEZFxOEjr9kBKpkxgOsHr3eaq6UdrGAHMdUzh8loP 3bm8zF3W5mGbBVabXZihl5R/p4vyEIlBMoQiETZ1Ywlo X-Google-Smtp-Source: AGs4zMZY6DV50KILQW+u+hQgvgp+o3AbJfm7mNuvLSB/95h4NOWbQRu61UocLmwp6LD0VXRp/e2YoBKkXomBmAY/AYk= X-Received: by 10.176.89.176 with SMTP id g45mr3798406uad.196.1511790925586; Mon, 27 Nov 2017 05:55:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.68.133 with HTTP; Mon, 27 Nov 2017 05:55:25 -0800 (PST) From: Rifaat Shekh-Yusef Date: Mon, 27 Nov 2017 08:55:25 -0500 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="001a11465d5a18263c055ef7417c" Archived-At: Subject: [OAUTH-WG] WGLC for OAuth 2.0 Device Flow for Browserless and Input Constrained Devices 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, 27 Nov 2017 13:55:29 -0000 --001a11465d5a18263c055ef7417c Content-Type: text/plain; charset="UTF-8" All, As discussed in Singapore, we are starting a WGLC for the *draft-ietf-oauth-device-flow-07* document, starting today and ending on December 11, 2018. https://datatracker.ietf.org/doc/draft-ietf-oauth-device-flow/ Please, review the document and provide feedback on the list. Regards, Rifaat & Hannes --001a11465d5a18263c055ef7417c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
All,

As discussed in Singapore, we are = starting a WGLC for the=C2=A0draft-ietf-oauth-device-flow-07 do= cument, starting today and ending on December 11, 2018.
<= br>
Please, review the document and provide feedback on the list.=

Regards,
=C2=A0Rifaat & Hannes<= /div>

--001a11465d5a18263c055ef7417c-- From nobody Mon Nov 27 05:57:26 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 B9CE9124D37 for ; Mon, 27 Nov 2017 05:57:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 ZynC9TYhtVFq for ; Mon, 27 Nov 2017 05:57:23 -0800 (PST) Received: from mail-ua0-x230.google.com (mail-ua0-x230.google.com [IPv6:2607:f8b0:400c:c08::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 CA02C1243FE for ; Mon, 27 Nov 2017 05:57:22 -0800 (PST) Received: by mail-ua0-x230.google.com with SMTP id j14so19008496uag.11 for ; Mon, 27 Nov 2017 05:57:22 -0800 (PST) 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; bh=BdQ/zYA9U0YPg6RS1ksnfj6EI9gXuU8QBGI2F0dWfTk=; b=MSOMPzOn3ASB8azzYQIgnJYqd1hHwUv1K01bgMzKQd3fbpUR2jDnoDLyemDjvGJPFJ clv2ApiifimuLWFKk6sahi8o8IemnYVCpENLLRzNSs0O0FmU1uWn5bbDtG3rnPc/GCKW RRe+m0HFjmwg4PPWu9iM5mMPMXy8xU8kL0Xhnpek44LkocjgVLo5jEluC8+3btohE2lK COqNwuX7jf082Z0oSHRc0d8FNcKTPycPWvuRUTsDugWuaHRxzgtTFS/JyUHMgLg4RW7E DVzQ6p4EzENFbEeZJhV9DrocVE22AXXJDy9CSr3X3g23SJjDH/q2BeJYKAcQCx7qcnFW hdww== 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=BdQ/zYA9U0YPg6RS1ksnfj6EI9gXuU8QBGI2F0dWfTk=; b=GBi2EgAXU1oFK3V1a5HBV7zh7vrrC+1y9mwZVsc2GRQzNYslIDC/LXNFRlH9PNkn+g vj4DBLyv2HtlAGCb3oDVZPt8N3ZHVP9ySy6OO+w85goD4tvmmA0/2OGvt6pitbW/paFC UQIEKPivozDEmageIP3OCE22Uy5FOO5DGW9YpjnrXYZskJQBzeppr8eAgbnHqaAdOZVB WOLWNkjSHbYRgrWSkzCaOMV0nM7DmG+NhhhfHj5t/hZSQJENSX7fpgAKeEE7co1uSg0+ a7o1uyNx8eQ9zaeHySxG0PKhqDTVqtlTAkk7uQIZS9pXHFQbaFY/pVQq56IMU8Z0yJt7 OL5A== X-Gm-Message-State: AJaThX74kxOZm529Q1aWqtxPR0zeK8NUci0E5Ox4mjhoHY+B7K3l6sw7 ReHnDOVchT0Kv5+P3txljHKn3ZDusN+YYlirH4v9ig== X-Google-Smtp-Source: AGs4zMZWlotwYKA7EcL74f93pKoBJAaVQGutijZaMlEksI1e5Q4i1UGjhZ8tUwjUe7nfcr1DhHRODFd+YPJ74IzKgRs= X-Received: by 10.159.37.69 with SMTP id 63mr29748686uaz.12.1511791041786; Mon, 27 Nov 2017 05:57:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.68.133 with HTTP; Mon, 27 Nov 2017 05:57:21 -0800 (PST) In-Reply-To: References: From: Rifaat Shekh-Yusef Date: Mon, 27 Nov 2017 08:57:21 -0500 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="94eb2c0476c60538ad055ef7489e" Archived-At: Subject: Re: [OAUTH-WG] WGLC for OAuth 2.0 Device Flow for Browserless and Input Constrained Devices 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, 27 Nov 2017 13:57:25 -0000 --94eb2c0476c60538ad055ef7489e Content-Type: text/plain; charset="UTF-8" Sorry, I did not mean to drag it to December next year :) The WGLC ends on *December 11, 2017*. Regards, Rifaat On Mon, Nov 27, 2017 at 8:55 AM, Rifaat Shekh-Yusef wrote: > All, > > As discussed in Singapore, we are starting a WGLC for the > *draft-ietf-oauth-device-flow-07* document, starting today and ending on > December 11, 2018. > https://datatracker.ietf.org/doc/draft-ietf-oauth-device-flow/ > > Please, review the document and provide feedback on the list. > > Regards, > Rifaat & Hannes > > --94eb2c0476c60538ad055ef7489e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sorry, I did not mean to drag it to December next yea= r :)

The WGLC ends on December 11, 2017.

Regards,
=C2=A0Rifaat


On Mon,= Nov 27, 2017 at 8:55 AM, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

--94eb2c0476c60538ad055ef7489e-- From nobody Mon Nov 27 06:32: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 065B5124D37 for ; Mon, 27 Nov 2017 06:32:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verisign.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 GuERk0IlzzYf for ; Mon, 27 Nov 2017 06:32:31 -0800 (PST) Received: from mail3.verisign.com (mail3.verisign.com [72.13.63.32]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFFA71242EA for ; Mon, 27 Nov 2017 06:32:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=530; q=dns/txt; s=VRSN; t=1511793150; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=ez4trYlIHRlAo4q0bEMehgzkwJYTzjx67/I7PsXwIUQ=; b=B+WFcMjfPeBbwbG92EDRbyM7J7+fvRJ9TBglWOiSkyI0T6yrJuLKNzQk B8zpp3Qwhri3TvKZdyl0/CuHm/RJWQZibj0YrY0e2qlQeo/g4AD2PzFlB fCWRYvQuDhNjzANSgYplZCpuISgUy9c6Cs/GfvUucWb+J3cIRuXfjQ5SJ Suo6nqVDLNz/ybbry1ZrJsf7w9a26DJy75e7zFT6a5xLvcYEvoGp3EFbq 3wjupBthJ1GdQED97v3vpJS7rTNUw8Xfv2ToNalvLewEzysWD9yzJEOkm KqBirEJRkKlthxOxIZ03HtVy9GNbtHwnvJ1Sz4gVNou/0EfT3U7fFvhlS w==; X-IronPort-AV: E=Sophos;i="5.44,465,1505779200"; d="scan'208";a="3246392" IronPort-PHdr: =?us-ascii?q?9a23=3A9ZUn3BznIHshJJHXCy+O+j09IxM/srCxBDY+r6Qd?= =?us-ascii?q?2+oSIJqq85mqBkHD//Il1AaPBtSLraocw8Pt8InYEVQa5piAtH1QOLdtbDQizf?= =?us-ascii?q?ssogo7HcSeAlf6JvO5JwYzHcBFSUM3tyrjaRsdF8nxfUDdrWOv5jAOBBr/KRB1?= =?us-ascii?q?JuPoEYLOksi7ze6/9pnQbglSmDaxfa55IQmrownWqsQYm5ZpJLwryhvOrHtIeu?= =?us-ascii?q?BWyn1tKFmOgRvy5dq+8YB6/ShItP0v68BPUaPhf6QlVrNYFygpM3o05MLwqxbO?= =?us-ascii?q?SxaE62YGXWUXlhpIBBXF7A3/U5zsvCb2qvZx1S+HNsDwULs6Wymt771zRRHoli?= =?us-ascii?q?kJKiI5/m/UhMxxkK1Vrx2uqgdjw47NZIyZKOZycr/Dcd4cWGFPXtxRVytEAo6k?= =?us-ascii?q?YYcBDe0BPeJcr4bjoVsBtgWxChWvBO/31zRGm2P53aom0+Q9Hw3NwQstH8kOsH?= =?us-ascii?q?TTqNX1MLkdUeauw6bW0TrDbOhb2Snj54jScxAhuvCMXb12ccbL1UYvEAbFg0yW?= =?us-ascii?q?pIf4PD2VzvwAv3WH4+Z6SO6iiWAqpxtsrjWvyMogkJfFi40ax1zc6Cl13Jw5Kc?= =?us-ascii?q?C6RUJne9KoDZRduiKAO4drQc4vRXxjtjwgxb0co5G7eTAHyJEgxxHCdfOKa5OI?= =?us-ascii?q?4hf/VOaJJjd4mW5ldKq/hxms9UigzfXxWdKu0FZMsyZFltbNtnUX2BzS7siHTe?= =?us-ascii?q?Z9/lu91TqSzQzT9P9LIVo1larAKp4hzbgwmoAPvkTEGy/6gET2jKmIeUU44uWk?= =?us-ascii?q?9vjrbq/7qpKeOYJ4kBzyP6Qgl8ClH+g1PQcDU3Ce+eum1b3j+UP5QK9Njv0ziq?= =?us-ascii?q?TZq5DaJcMfpq69HQBV1J0s5AijADely9kYg2cILEhEeBKcjojpNFfOLOrkAve4?= =?us-ascii?q?hlSgiC1ryOzePr39HpXNKWDOkLD7crZg905cyBE+zdFB6JJIBLENOvXzWlX+tI?= =?us-ascii?q?+QMhhseUOzyvv7CP18258QH2WVDeDTePfVuEKU5souLvWCIogPt2CuBeIi4quk?= =?us-ascii?q?rXg9nVIbd6Si3t9fU3u/AugsaxGCYX3ohtoHG2oBvSIgQfbrk1yNV3hYYHPkDP?= =?us-ascii?q?F03S0yFI/zVdSLfYuqmrHUhCo=3D?= X-IPAS-Result: =?us-ascii?q?A2FsAQCUIRxa//SZrQpcHAEBAQQBAQoBAYU+jhiUTJMzghE?= =?us-ascii?q?KE4UoAoUsGAEBAQEBAQEBAQECgRCCOCKDB1EBFRUUQiYBBBuyV4sGASWDNgSDX?= =?us-ascii?q?Yoxg0SCMgWiQAYClweRUZYNAgQLAhkBgTofggpvgniEVIoKgRQBAQE?= Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02 [10.173.152.206]) by brn1lxmailout01.verisign.com (8.13.8/8.13.8) with ESMTP id vAREWTm1024237 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 27 Nov 2017 09:32:29 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0301.000; Mon, 27 Nov 2017 09:32:36 -0500 From: "Hollenbeck, Scott" To: "'oauth@ietf.org'" Thread-Topic: OAuth 2.0 Device Flow LC Comment (and OpenID Connect) Thread-Index: AdNni6Noft1hu4gOT0W0OhL3sI0c9A== Date: Mon, 27 Nov 2017 14:32:35 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F7F8F16EA@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.170.148.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [OAUTH-WG] OAuth 2.0 Device Flow LC Comment (and OpenID Connect) 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, 27 Nov 2017 14:32:32 -0000 I have reviewed draft-ietf-oauth-device-flow-07. Just one comment regarding= Section 5.1: Would it be possible to suggest some minimally acceptable entropy value? Th= e text says "The user code SHOULD have enough entropy that when combined wi= th rate limiting makes a brute-force attack infeasible", but just how much = entropy is enough? A related question: the last call made me wonder if there are any plans to = add a device flow for OpenID Connect. Does anyone know if such a thing is i= n the works? Scott From nobody Mon Nov 27 08:54:58 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 E0386128C82 for ; Mon, 27 Nov 2017 08:54:56 -0800 (PST) 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 0dzSS4ZBcXSL for ; Mon, 27 Nov 2017 08:54:55 -0800 (PST) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::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 85B4F12420B for ; Mon, 27 Nov 2017 08:54:55 -0800 (PST) Received: by mail-io0-x234.google.com with SMTP id 79so29463484ioi.3 for ; Mon, 27 Nov 2017 08:54:55 -0800 (PST) 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=1xig0cE0Ofp66jyvXGac6G+aZerfTn7gy4x9JaEs4U8=; b=nuGII1jRnbC1UkwHm3BGPtyjz0zXppQTqn1xcwEtMzEdizpy3W1WEmsxUtp4optixk Ok1dfxtpnhBQg7o7olkwq83BKPKi8XPb2bPK5EZExJ7mMqiNxgVthxMXl371qKZazH+8 fQUzjo9BVFQL86of3esDg93eVQ2vlh6v0Hmao= 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=1xig0cE0Ofp66jyvXGac6G+aZerfTn7gy4x9JaEs4U8=; b=ljaaZq1nd5ZOmHMXqWZLpgzzarw/FYOnsnebsYenUJIgUdMdMfoYQJ/edkUEh2q+iX owPMNkMHwRbWZhjkBWIFag+cvPnYkcScjtsd2p2KN8sMHbEHSuEdAjsLJ/BqONfTecKu 1d6/4PevncWmWvzSl7Eh6VbouqQcJLwPDZFC+NIffCALeSy+7b0huTWGPcSKHy0/VdBy iMY6lmnuZsvziSWVK6NjFYFtAIjUvnO7lxlJlHBy8DsapxHzG0tqIqA5l1DVo3YNeQtk HQbcjpl9UK94vsOFGsW/ax+VkO9aA4C7vj1c4NEkzSXcvUKRDJ2vuJxLL8KEIa1u07tD GZnA== X-Gm-Message-State: AJaThX4T+IE024OYVK607AFtI4ombiF0oGbNIlwl2x9lX4kJbbidNXpY p9gmj8LakswlAAzL0WUzJgxOAEoJbUTn0vXxoOIRrMi1xGl2hpEZO8Gv6afQtwd0Tj5sRckAguh qI/jDeDOiNcbEgA== X-Google-Smtp-Source: AGs4zMYyFr9uj94t6Ypd1ov4vc9zcurfXFg2m3Qb0KkytGh0w7h/dZA7lgmNfvrqaMN99zt3io0ijMLHg0MOQVzNLxY= X-Received: by 10.107.48.197 with SMTP id w188mr41639482iow.301.1511801694762; Mon, 27 Nov 2017 08:54:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.2.118.194 with HTTP; Mon, 27 Nov 2017 08:54:24 -0800 (PST) In-Reply-To: References: From: Brian Campbell Date: Mon, 27 Nov 2017 09:54:24 -0700 Message-ID: To: Rifaat Shekh-Yusef Cc: oauth Content-Type: multipart/alternative; boundary="001a11444bfafcdf25055ef9c23b" Archived-At: Subject: Re: [OAUTH-WG] Token Exchange Implementations 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, 27 Nov 2017 16:54:57 -0000 --001a11444bfafcdf25055ef9c23b Content-Type: text/plain; charset="UTF-8" With a little searching I came across a couple other implementations: Indigo IAM https://indigo-dc.gitbooks.io/iam/content/doc/user-guide/oauth_token_exchange.html Unity IdM http://www.unity-idm.eu/documentation/unity-2.1.0/manual.html#_token_exchange On Thu, Nov 23, 2017 at 9:17 AM, Rifaat Shekh-Yusef wrote: > All, > > As part of the write-up for the Token Exchange document, we are looking > for information about implementation for this document. > > We are aware of 3 implementations for this document by: Salesforce, > Microsoft, and Box. > > Are people aware of any other implementation? > > Regards, > Rifaat > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > -- *CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.* --001a11444bfafcdf25055ef9c23b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Thu, Nov 23, 2017 at 9= :17 AM, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote= :
All,

As part of the write-up for the Token Ex= change document, we are looking for information about implementation for th= is document.

We are aware of 3 implemen= tations for this document by: Salesforce, Microsoft, and Box.

Are people aware of any other implementation?

Regards,
=C2=A0Rifaat


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



<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --001a11444bfafcdf25055ef9c23b-- From nobody Mon Nov 27 09:18: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 7820D128BBB for ; Mon, 27 Nov 2017 09:18:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 Xvpyl6BIZnxi for ; Mon, 27 Nov 2017 09:18:07 -0800 (PST) Received: from mail-ua0-f182.google.com (mail-ua0-f182.google.com [209.85.217.182]) (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 79A2112895E for ; Mon, 27 Nov 2017 09:18:07 -0800 (PST) Received: by mail-ua0-f182.google.com with SMTP id l25so19538159uag.8 for ; Mon, 27 Nov 2017 09:18:07 -0800 (PST) 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=tK9Xff/z166fSWd3YgTnlASuebzDNkt12UWCj3qJ2cc=; b=hNjO5S0CHjl2BlBsW2OYZ1EVmYHVFaEabCdM2cBnn3ItXcAxeocQteMxv6XseCMEq/ sMQRCeLUYgJDxEj+OmTKVnBBrkgWfZlwyv+4bRSkMygv3L6HTXdb7X0jOlZVRaewdEij yO0yX4MgAJHXCYB1IcjipFUircfDxzbo3/k5NtbNpThcvRXMYGtT3xtqel7dgUY/C3zm hdUyRaIhNOSLPB2crg65/xpPuUpMs85z59LwYpoyUne0nNxFzq1+uRcXVZ3juFVn2mM3 h28WTvWGKw9mSG8fLveWi2FJ39krblYQC+eulF5gExlxYY0t6FkVP/4uv9GNnr8R+qUE M94g== X-Gm-Message-State: AJaThX4UD0MYL0aALMilwBZDWzUBBA1R6LtXA8h8f1xGc6YFF0NJ2rmg 4cKJrAAJ/S5S6GAGa5f5Ys/Yg+6eMEVqSsePGfnJsQ== X-Google-Smtp-Source: AGs4zMZxC+OC0uYeV1CZcmA9O88Oe0z++YHLcwCaG276uCewEIVPIuVVDZ6+ITU7c+OWE3QwiB9XF+bclENWTGVKjRI= X-Received: by 10.176.90.216 with SMTP id x24mr24571773uae.179.1511803086506; Mon, 27 Nov 2017 09:18:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.68.86 with HTTP; Mon, 27 Nov 2017 09:18:06 -0800 (PST) In-Reply-To: References: From: Bill Burke Date: Mon, 27 Nov 2017 12:18:06 -0500 Message-ID: To: Rifaat Shekh-Yusef Cc: oauth Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [OAUTH-WG] Token Exchange Implementations 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, 27 Nov 2017 17:18:09 -0000 Red Hat has a partial implementation of this within the Keycloak project: http://www.keycloak.org/docs/latest/securing_apps/index.html#_token-exchange Been meaning to discuss this with this list as we added extensions to better support external token exchange, specifically "subject_issuer" and "requested_issuer" parameters. We also did not add support for actor tokens as we have not yet gotten requests for this level of complexity. On Thu, Nov 23, 2017 at 11:17 AM, Rifaat Shekh-Yusef wrote: > All, > > As part of the write-up for the Token Exchange document, we are looking for > information about implementation for this document. > > We are aware of 3 implementations for this document by: Salesforce, > Microsoft, and Box. > > Are people aware of any other implementation? > > Regards, > Rifaat > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- Bill Burke Red Hat From nobody Mon Nov 27 11:45: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 270C0127698 for ; Mon, 27 Nov 2017 11:45:17 -0800 (PST) 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=salesforce.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 gZYmCYI7X80y for ; Mon, 27 Nov 2017 11:45:15 -0800 (PST) Received: from mail-ot0-x22a.google.com (mail-ot0-x22a.google.com [IPv6:2607:f8b0:4003:c0f::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 BF80E12706D for ; Mon, 27 Nov 2017 11:45:15 -0800 (PST) Received: by mail-ot0-x22a.google.com with SMTP id g104so25307426otg.7 for ; Mon, 27 Nov 2017 11:45:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salesforce.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xGrIaPe1GY7LjORTwEbv4YvDqdEVdw4KDs8OKWv5cLQ=; b=N1UcGLneOp0rAooRYD9+gm7m/WA8BgZuBzIORHcC4A47UvkLK/sUr5KEdl1fo/Xh+R 6hggR9EXZFws4LdK980XY7ysS2Igp7jzFGb8U59824fir/Uadhb7WS+LdKWxaX2nsAVX SxLakTcK70GCSiQn3h8QznzljqiNHPGzyk+z0= 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=xGrIaPe1GY7LjORTwEbv4YvDqdEVdw4KDs8OKWv5cLQ=; b=aWc/Em/LOeED/Pzsmi3rbcgbUk8HjVedW9A4G7E0sJE33O/sYeiRNi5mdECDDcpOnR 0Rw9JLRrV8xVtii9BnB6tTiFc0VVydxOsr0H7TjKqaabXTkqmx63bhhtb7JXpQtFEUvw a7ltXpPKo2dPKsQSOiSNqC/gS9SGWScun0UxZfbIrdjT2uidHQyYT8x0ByjyLXBogKhM BWhVyerd4rQKgvGpNZHZdb3heorIcKgsexDfBI35uFdSX0mvAafbtVOBm1yXh7ziGqsh YMloRjTto7vclduznZx4TlZOxhBD6AWwdE8cbuWN6dH8+X/DFPO1VVv04fr5BF+g5thL EKDw== X-Gm-Message-State: AJaThX4u+KKV1MZNHMVHUjctLZt3qCYczVhsmsgDfKm5nSzJLEHcsorX CaFtzWS1fy0jHSJSt5leoEeDoxaeWkjZpGM0T2UpEP9k X-Google-Smtp-Source: AGs4zMYJL3Zs68tvJ83KTThciIwhQuD95HW7qS4+bFRiaNllfp6RLjDINAx/zJIvy6yYRRkAIgjeZte2FdEHKWluGb0= X-Received: by 10.157.41.74 with SMTP id d68mr26562434otb.184.1511811915062; Mon, 27 Nov 2017 11:45:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.74.179.66 with HTTP; Mon, 27 Nov 2017 11:45:14 -0800 (PST) In-Reply-To: References: From: Chuck Mortimore Date: Mon, 27 Nov 2017 11:45:14 -0800 Message-ID: To: Rifaat Shekh-Yusef Cc: draft-ietf-oauth-token-exchange.all@ietf.org, oauth , Hannes Tschofenig Content-Type: multipart/alternative; boundary="94eb2c11ed862a7d9c055efc2493" Archived-At: Subject: Re: [OAUTH-WG] Token Exchange - IPR Disclosure 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, 27 Nov 2017 19:45:17 -0000 --94eb2c11ed862a7d9c055efc2493 Content-Type: text/plain; charset="UTF-8" I am not aware of any IPR on the token exchange document. On Thu, Nov 23, 2017 at 8:14 AM, Rifaat Shekh-Yusef wrote: > Authors, > > As part of the write-up for the Token Exchange document, we need an IPR > disclosure from all of you. > > Are you aware of any IPR related to the following Token Exchange document? > https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/ > > Regards, > Rifaat > > --94eb2c11ed862a7d9c055efc2493 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I am not awar= e of any IPR on the token exchange document.=C2=A0

On Thu, Nov 23, = 2017 at 8:14 AM, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
Authors,
=
As part of the write-up for the Token Exchange document, we = need an IPR disclosure from all of you.

Are you aw= are of any IPR related to the following Token Exchange document?

Regards,
= =C2=A0Rifaat


--94eb2c11ed862a7d9c055efc2493-- From nobody Thu Nov 30 11:42:55 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 2FB86129447 for ; Thu, 30 Nov 2017 11:42:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 (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 SWnRO3rkB6v5 for ; Thu, 30 Nov 2017 11:42:51 -0800 (PST) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0107.outbound.protection.outlook.com [104.47.40.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04DBA126CE8 for ; Thu, 30 Nov 2017 11:42:50 -0800 (PST) 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=g5A9N9INQQGIXiIRV8a2BsRTg60Fj9aHcrvsZl6cIIk=; b=GxRlMjQB25VTHPTpiMkBO6jYEvTS6pDwuC1UlHOD+wzhVcPqCj0Kk3UvYWImzCTzE6aeGK679uZMmr9AsZbE0NRtULllc5mDjaJT0Hf3gkpgM13IS53Y0U+dllJxIlaSUk366vr3ASRJUmm6lUnwm/XPsQ5vQK9kIWpwSiUpv8U= Received: from CY4PR21MB0504.namprd21.prod.outlook.com (10.172.122.14) by CY4PR21MB0760.namprd21.prod.outlook.com (10.173.195.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.302.1; Thu, 30 Nov 2017 19:42:49 +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.20.0302.001; Thu, 30 Nov 2017 19:42:49 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: [OAUTH-WG] WGLC for OAuth 2.0 Device Flow for Browserless and Input Constrained Devices Thread-Index: AQHTZ4drm5+waW00Ek6dNR2Tcsv3tKMqkHdggAAPLy+AAPos4IABvR2A Date: Thu, 30 Nov 2017 19:42:49 +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_Owner=muali@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2017-11-29T17:15:39.9933792Z; 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 x-originating-ip: [2001:4898:80e8:d::36] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0760; 6:ivTbxxh4rihz9DjCuUMjeOfUy4G5tr1jQPI1SqEfLHFUWHygdedGDrruzpcmC1nBwav2VNCkTXgOHdauYDiL4IRElLdRXAR5zX00zOxKk4Dz2hDOPh2EkCnL/5oEHV9Z9sc+p3LI4JZnKuAJrpmnrJlpb6ldqBnGBlIT+J20RXM5VHk2RrVt+P3pT83F1RAEwrX9Y4lYOhcN9NeMdt2espm0mYCyRe/9Rz8rROza7HuumsJuYW4oX5kZ2p1YytrPgRW8Vyp5PVM7egYWPWkMsog21ZQdU/bVjYzG/Q7r7JgGLRfz3jX/rfLRCajeBcC9dKypPcleyIEaWKS8jXLQwfVK6yeeRNiZLD+rb0bxCLY=; 5:7aUSKBxyaRaW8yFHiH3pZs2qH9GNal4qYor8L8DuBD/sJYiyDmFS1OYknq/WOANvCeE4YCunHfb+5AE6e+zw5xrp1P4B+Eo+od34POOhcNjar17XiqPoycpXWZOqSHDyBX7Jp9oVgVhPSsXiP4VHw0f2vodoFw80F0Ffm7x04TI=; 24:MMMW74MhHibbP9Y0T4z7k7pUdoBpLo95Eg7KlL/eRFMg0+qIu62CCRqNktt1mlO8tas5tAlMAHWnRGZTNOIKJo9bSFochHUtQ2HT8IfRQgE=; 7:RcTMlV3im0F/gLG0Ds2kuR8Sjr6f2aLwzdWZpqZ6tWbL7L8s9o4M+/FI3EYCECsqbaktoclAiTcAQmutxjUBnTN8x0stfH0y9+3xcuvvcVO51M0B8NVbpECVdZQ6anZetViTwiSD3etACwK3O3VvB89Jen8u5tifdyHZvMsoCC0QDe8niU9rmeq0ZT7/Pubq/Q3nw4XVD9DS2k1vE9KOdGrkzwunPF/6Re31KiwNcpBlMKM9YwPPt69ygMkRZT2d x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: cdff451f-af18-49ec-3dba-08d5382a89f3 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(48565401081)(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603286); SRVR:CY4PR21MB0760; x-ms-traffictypediagnostic: CY4PR21MB0760: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(89211679590171)(120809045254105)(227612066756510)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040450)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(3231022)(6055026)(61426038)(61427038)(6041248)(20161123564025)(20161123562025)(20161123560025)(20161123558100)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:CY4PR21MB0760; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:CY4PR21MB0760; x-forefront-prvs: 05079D8470 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(39860400002)(376002)(346002)(47760400005)(199003)(189002)(22452003)(25786009)(8936002)(33656002)(8990500004)(101416001)(53936002)(2501003)(99286004)(97736004)(55016002)(10090500001)(14454004)(10290500003)(2950100002)(6916009)(2900100001)(74316002)(966005)(72206003)(478600001)(2351001)(606006)(106356001)(105586002)(53546010)(7736002)(189998001)(1730700003)(229853002)(102836003)(54896002)(2473003)(6306002)(9686003)(790700001)(6116002)(316002)(3280700002)(81166006)(6436002)(6506006)(5630700001)(81156014)(5660300001)(93886005)(50986010)(2906002)(7696005)(68736007)(86362001)(76176010)(236005)(86612001)(3660700001)(77096006)(5640700003)(8676002)(54356011); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0760; H:CY4PR21MB0504.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB05040F473126D3B22D48104BF5380CY4PR21MB0504namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: cdff451f-af18-49ec-3dba-08d5382a89f3 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Nov 2017 19:42:49.5901 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0760 Archived-At: Subject: [OAUTH-WG] FW: WGLC for OAuth 2.0 Device Flow for Browserless and Input Constrained Devices 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, 30 Nov 2017 19:42:53 -0000 --_000_CY4PR21MB05040F473126D3B22D48104BF5380CY4PR21MB0504namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable WGLC feedback from a Microsoft engineer using the device flow... From: ... Sent: Wednesday, November 29, 2017 9:16 AM To: Mike Jones Cc: ... Subject: RE: [OAUTH-WG] WGLC for OAuth 2.0 Device Flow for Browserless and = Input Constrained Devices Hi Mike, I got some comments around the user_code and its expiration which are not c= lear in the specs. The user_code is not a one time use right? It seems to me that the user sho= uld be able to use the code more than once until the authorization is compl= eted. Once the authorization is successful then the user_code should not be= valid anymore. The spec isn't clear about what if the user_code expires while the client i= s going through the authorization flow? Again, in my mind, the user_code is= valid until the authorization is successful and if it expires any time bef= ore that then we should not continue with the authorization and tell the us= er that the user_code has expired. And if the user finished authorization a= nd the user_code expires BEFORE the token is redeemed, then the 'expired_to= ken' response should be sent back from the token endpoint. Thanks, ... From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Rifaat Shekh-Yusef Sent: Monday, November 27, 2017 5:55 AM To: oauth > Subject: [OAUTH-WG] WGLC for OAuth 2.0 Device Flow for Browserless and Inpu= t Constrained Devices All, As discussed in Singapore, we are starting a WGLC for the draft-ietf-oauth-= device-flow-07 document, starting today and ending on December 11, 2017. https://datatracker.ietf.org/doc/draft-ietf-oauth-device-flow/ Please, review the document and provide feedback on the list. Regards, Rifaat & Hannes --_000_CY4PR21MB05040F473126D3B22D48104BF5380CY4PR21MB0504namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

WGLC feedback from a M= icrosoft engineer using the device flow…

 

From: …
Sent: Wednesday, November 29, 2017 9:16 AM
To: Mike Jones <Michael.Jones@microsoft.com>
Cc: …
Subject: RE: [OAUTH-WG] WGLC for OAuth 2.0 Device Flow for Browserle= ss and Input Constrained Devices

 

Hi Mike,

 

I got some comments around the user_code and its exp= iration which are not clear in the specs.

 

The user_code is not a one time use right? It seems = to me that the user should be able to use the code more than once until the= authorization is completed. Once the authorization is successful then the = user_code should not be valid anymore.

 

The spec isn’t clear about what if the user_co= de expires while the client is going through the authorization flow? Again,= in my mind, the user_code is valid until the authorization is successful a= nd if it expires any time before that then we should not continue with the authorization and tell the user that the u= ser_code has expired. And if the user finished authorization and the user_c= ode expires BEFORE the token is redeemed, then the ‘expired_tokenR= 17; response should be sent back from the token endpoint.

 

Thanks,

…

 

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Rifaat Shekh-Yusef
Sent: Monday, November 27, 2017 5:55 AM
To: oauth <oauth@ietf.org&g= t;
Subject: [OAUTH-WG] WGLC for OAuth 2.0 Device Flow for Browserless a= nd Input Constrained Devices

 

All,

 

As discussed in Singapore, we are starting a WGLC fo= r the draft-ietf-oauth-device-flow-07 document, starting today = and ending on December 11, 2017.<= /o:p>

 

Please, review the document and provide feedback on = the list.

 

Regards,

 Rifaat & Hannes

 

--_000_CY4PR21MB05040F473126D3B22D48104BF5380CY4PR21MB0504namp_-- From nobody Thu Nov 30 15:55:59 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 18FB6120046; Thu, 30 Nov 2017 15:55:54 -0800 (PST) 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.66.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151208615408.11802.12175452260900272912@ietfa.amsl.com> Date: Thu, 30 Nov 2017 15:55:54 -0800 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchange-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: Thu, 30 Nov 2017 23:55:54 -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 WG of the IETF. Title : OAuth 2.0 Token Exchange Authors : Michael B. Jones Anthony Nadalin Brian Campbell John Bradley Chuck Mortimore Filename : draft-ietf-oauth-token-exchange-10.txt Pages : 32 Date : 2017-11-30 Abstract: This specification defines a protocol for an HTTP- and JSON- based Security Token Service (STS) by defining how to request and obtain security tokens from OAuth 2.0 authorization servers, including security tokens employing impersonation and delegation. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-10 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-token-exchange-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-token-exchange-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 Thu Nov 30 16:03:04 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 727B21270A7 for ; Thu, 30 Nov 2017 16:03:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.019 X-Spam-Level: X-Spam-Status: No, score=-2.019 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=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 2Qx8tbDi06i4 for ; Thu, 30 Nov 2017 16:03:00 -0800 (PST) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0105.outbound.protection.outlook.com [104.47.42.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 534D8124D68 for ; Thu, 30 Nov 2017 16:03:00 -0800 (PST) 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=5PcwJqgdxeHh9z/PQFiK+Ed5TGdeuRdAsA+kwVzT9Zk=; b=kbWKeQOE2wVmGmzXvYaYSJOYHuFLENyhTt20qiMtGRaqJD7rClCSuFzwmmGD1b6BlKhtPBIujO72lKyVIuy6XiZ3YKEzF3mOLqvIRhF4XhM4Gvt5yItM6bvWYGuJjOny8eyDz+4Gnf2Ot7G7resd1T+yfVT+Hs4fC/HpwXtexs4= Received: from CY4PR21MB0504.namprd21.prod.outlook.com (10.172.122.14) by CY4PR21MB0824.namprd21.prod.outlook.com (10.173.192.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.302.1; Fri, 1 Dec 2017 00:02:59 +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.20.0302.001; Fri, 1 Dec 2017 00:02:59 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: OAuth Token Exchange spec adding URIs for SAML assertions Thread-Index: AdNqNc17FQiV4qGXTyGZfz5MiJ/0uw== Date: Fri, 1 Dec 2017 00:02:59 +0000 Message-ID: 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_Owner=mbj@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2017-12-01T00:02:58.0161288Z; 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 x-originating-ip: [2001:4898:80e8:d::36] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0824; 6:JnJZVVapJ7hKFKdnXD1UYHTRxMGtmdsZuv8giQKaNJgTtzr9za4j7qCCdR1MCDPJ7xvmFTZOH6kFDgBNmj7WIkRfq8hnZlV8ldWVJ4RpJo0pXVVAba+qOE8vEvssah39aktBirVw72qcfsRswO1uQVwS1nhl2vzqfNhSoijO2Z5PFavjO3vyE+mAde6y9A0HSXaxYwgLtXfu1GlMXtSrLCUxUHtjtXs65dXWj0aRSdqEBMFfwE/Ua7t7U+V90BeYZM3r8ZqJaZO2SbRLGBdBRjaF0s3s+hzoH52Jicaa3acPD1s/btQrIq2Io1qrcY4MBQnelIKq51BleUH/Kjb9RW/NGKfHlxvYbowIx57vgaA=; 5:FBhg9cjKc7kJE3MLtF1tsnuFhISihWbivqwyyKiElrwr5wbR+/0hBwd4wlzR4WcrBXVYJsztJOAQsYX5Ye12pXytowc9IF6wv5mNQbD+bu5sqNCOPyF0lj+N2B2GGA+JxpqsRB3nbbWO2wslV+gPllpnEtTpz0MfaBlX1QZiWIA=; 24:CPMTfIt7clahKd8fRbTjDPTrdQ2hIulewNQKwqwq7EzNwh9EzydVQKVet3mC6LkGwxFXGOXw0jl0t4FivsCG9a4zN86SGQtA5W1jU0/ckwU=; 7:0alYZsO8/a3FadoPlRALYtFKsTfXqMjU34I0zcki3m6uCFrt+LyHvQIv6cUesanByg18OXQAEr1e4cgDnscC3w2JMLU6YqtuqXL9eUvr5dhmTsxFq4rWlIFf8sEKEG6LviCNM4FiEu7V7R3yB1U1yKfSOHn12sw1IaxPY7etIF6NkQgVe2p3gVwzFxj3JcW2Xpgdk8UWNplj+3Tf/z5knQMp3QfnusetE0YKhqsHnSAbphsjfHMwHMpZ9hPtH8WK x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 6f9c85c2-a117-4a46-afa0-08d5384ee216 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(2017052603286); SRVR:CY4PR21MB0824; x-ms-traffictypediagnostic: CY4PR21MB0824: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(31418570063057)(227612066756510)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040450)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(3231022)(6055026)(61426038)(61427038)(6041248)(20161123560025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123564025)(20161123555025)(6072148)(201708071742011); SRVR:CY4PR21MB0824; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:CY4PR21MB0824; x-forefront-prvs: 05087F0C24 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(346002)(376002)(366004)(209900001)(47760400005)(189002)(199003)(966005)(10290500003)(72206003)(3660700001)(478600001)(3280700002)(8676002)(2906002)(74316002)(1730700003)(105586002)(189998001)(5660300001)(106356001)(81156014)(25786009)(7736002)(14454004)(86362001)(81166006)(86612001)(606006)(2351001)(101416001)(54356011)(33656002)(2900100001)(9686003)(54896002)(236005)(6306002)(790700001)(6116002)(102836003)(8990500004)(53376002)(68736007)(53936002)(99286004)(8936002)(10090500001)(7696005)(5630700001)(2501003)(55016002)(97736004)(316002)(6506006)(22452003)(5640700003)(6436002)(6916009)(77096006)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0824; H:CY4PR21MB0504.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB0504EEB06ED5E52C27F84294F5390CY4PR21MB0504namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6f9c85c2-a117-4a46-afa0-08d5384ee216 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Dec 2017 00:02:59.3285 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0824 Archived-At: Subject: [OAUTH-WG] OAuth Token Exchange spec adding URIs for SAML assertions 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, 01 Dec 2017 00:03:02 -0000 --_000_CY4PR21MB0504EEB06ED5E52C27F84294F5390CY4PR21MB0504namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable A new draft of the OAuth 2.0 Token Exchange specification has been publishe= d that adds token type URIs for SAML 1.1 and SAML 2.0 assertions. They wer= e added in response to actual developer use cases. These parallel the exis= ting token type URI for JWT tokens. The specification is available at: * https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-10 An HTML-formatted version is also available at: * http://self-issued.info/docs/draft-ietf-oauth-token-exchange-10.html -- Mike P.S. This notice was also posted at http://self-issued.info/?p=3D1755 and = as @selfissued. --_000_CY4PR21MB0504EEB06ED5E52C27F84294F5390CY4PR21MB0504namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

A new draft of the OAuth 2.0 Token Exchange specific= ation has been published that adds token type URIs for SAML 1.1 and SAML 2.= 0 assertions.  They were added in response to actual developer use cas= es.  These parallel the existing token type URI for JWT tokens.

 

The specification is available at:

 

An HTML-formatted version is also available at:=

 

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

 

P.S.  This notice was also posted at http://self-issued.info/?p=3D1755 and as @selfissued.

--_000_CY4PR21MB0504EEB06ED5E52C27F84294F5390CY4PR21MB0504namp_-- From nobody Thu Nov 30 16:05: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 9D96C12704B for ; Thu, 30 Nov 2017 16:05:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.019 X-Spam-Level: X-Spam-Status: No, score=-2.019 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_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=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 GyjDXY0-SSwP for ; Thu, 30 Nov 2017 16:05:30 -0800 (PST) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0111.outbound.protection.outlook.com [104.47.38.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED9BA124D68 for ; Thu, 30 Nov 2017 16:05:29 -0800 (PST) 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=GwvR2lReq0pCV9zXa95BN8Uovan3q8uKTabMFrb1604=; b=ktitkHfCYWKVG7l4nZQYb0H7fbFdlQJwnfe2Mmkg0qgCOKu8/IDF7iks83Get0CQMlFem6KamgwmAMPgqZ09OiE0ua6pQ8a8RxAOm+5xVBL1Jp9xGTL2l1TbPumJCNaXhsb1eWF50MGe6AVuEf/tbeXVJ+QJM+jpZpe+k9m9S7U= Received: from CY4PR21MB0504.namprd21.prod.outlook.com (10.172.122.14) by CY4PR21MB0693.namprd21.prod.outlook.com (10.175.121.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.302.1; Fri, 1 Dec 2017 00:05:28 +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.20.0302.001; Fri, 1 Dec 2017 00:05:28 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: Adding a SAML 2 token type to the OAuth Token Exchange spec Thread-Index: AdM8TmiMyZFiaKDRSBqiPBGbOdL9Lwt6SkYQ Date: Fri, 1 Dec 2017 00:05:28 +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_Owner=mbj@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2017-12-01T00:05:26.7988687Z; 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 x-originating-ip: [2001:4898:80e8:d::36] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0693; 6:DuPclTe1fXkmSEGPnlnlQ6Njzdxjjl+Cf7sgcg00r2V/veuz4YvPCfJn4Am0MtbZYaP/ziZBNLdiYSLBNf+UUJv35NxHBCUhaJ7WH34PvJUyzqiqoq8SlvEJo8yAoAtuMxJKx3L99gzwfsy2il5TodruJRem5STD4KK68CoqVYapzu/qjQyMjimcPDp0BRTA1OGB4M7PIlgZ0XUU4tA0yygN91JX77aVAPg7YRLB9NKlpuwdSbDWCZzQn3zSamIwZmnOgDzOKgM9IRlIXIaUsfVR3m6pxn2h1cKDOb/WZNUWc61HXMl2O44Pq++COEnt0BNB8d7K4PobSv0c/vFdEK8mAIYw22Idk9/K3NCbqRg=; 5:Y/CTRXfuSqEx1OUtH8B24c+fjBV77wkvvjo1bqSzmAK4C+OM8AXBHyZwdaq7Py6+nqCTS3UkgeAVc/hoR5YwDXGCHCqr1S0lBNqzlsGixZLX2m7bXPEFovBLM5KdZ2WnGodkBXKeR05yPCXltTw8uTk5Tnttw8bL/bbcyIKLwjE=; 24:1W6qIrU1MvW7Jix0e65hkZe7rgz/iuir0z4WS7Mv0cWWyowcAvshrdPNm7ckcXhYT23RhElRBzl4M047kpAcjsQJTcBiJ6xkBZFL7iRekN0=; 7:9Rb2OQ5vHjwq3kW3hrA/CNWd0c3U5XI0G/wnavA+unYaM7xujv7w8wJLg+M68UXa7OOlNRIMUWrr/Wah1hNsAOIwKrssGh+UNiGEJYt37XDp6g7QkZt9l34f+VFH+VZb3nOTqTaigkGVD6vDzTyfhLU/7QBQFNKtpcjoTqC4A//pETID1xHYxZ+L5/psyIdLYueb0luHPuq+xRdmLVzW1MuFR6ZUEEax7TE6RaHT0CrJGfsOJesdftQH1BzspGf0 x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: cb9716e7-75ab-4692-1334-08d5384f3ac5 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(48565401081)(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603286); SRVR:CY4PR21MB0693; x-ms-traffictypediagnostic: CY4PR21MB0693: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(227612066756510)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(3231022)(6055026)(61426038)(61427038)(6041248)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123555025)(20161123558100)(20161123564025)(6072148)(201708071742011); SRVR:CY4PR21MB0693; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:CY4PR21MB0693; x-forefront-prvs: 05087F0C24 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(366004)(39860400002)(47760400005)(199003)(189002)(1730700003)(606006)(6116002)(189998001)(9686003)(54896002)(790700001)(102836003)(316002)(106356001)(105586002)(229853002)(53546010)(7736002)(68736007)(86362001)(77096006)(5640700003)(54356011)(76176011)(8676002)(86612001)(3660700001)(236005)(6506006)(81166006)(3280700002)(81156014)(5630700001)(6436002)(2906002)(5660300001)(7696005)(53936002)(33656002)(22452003)(6306002)(8990500004)(25786009)(6246003)(8936002)(72206003)(74316002)(99286004)(2351001)(478600001)(101416001)(2900100001)(10090500001)(2950100002)(97736004)(2501003)(10290500003)(55016002)(14454004)(6916009); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0693; H:CY4PR21MB0504.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB0504E84EF80D0F0209979970F5390CY4PR21MB0504namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: cb9716e7-75ab-4692-1334-08d5384f3ac5 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Dec 2017 00:05:28.1421 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0693 Archived-At: Subject: Re: [OAUTH-WG] Adding a SAML 2 token type to the OAuth Token Exchange 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: Fri, 01 Dec 2017 00:05:33 -0000 --_000_CY4PR21MB0504E84EF80D0F0209979970F5390CY4PR21MB0504namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Draft -10 a= dded the token type URIs urn:ietf:params:oauth:token-type:saml1 and urn:iet= f:params:oauth:token-type:saml2 in response to actual developer token excha= nge use cases that needed identifiers for both kinds of SAML tokens. -- Mike From: Mike Jones Sent: Tuesday, October 3, 2017 6:51 AM To: oauth@ietf.org Subject: Adding a SAML 2 token type to the OAuth Token Exchange spec A Microsoft use case has come up in which people would like to perform a to= ken exchange for a SAML token. The spec already defines urn:ietf:params:oau= th:token-type:jwt for requesting JWT tokens. Would anybody object to us ad= ding urn:ietf:params:oauth:token-type:saml2 to the next draft to also give = us a standard way to ask for SAML 2.0 tokens? It could always be done in its own spec, but adding it in Token Exchange se= ems more expedient. -- Mik= e --_000_CY4PR21MB0504E84EF80D0F0209979970F5390CY4PR21MB0504namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Draft -10 added th= e token type URIs urn:ietf:params:= oauth:token-type:saml1 and urn:ietf:params:oauth:t= oken-type:saml2 in response to actual developer token exchange use c= ases that needed identifiers for both kinds of SAML tokens.

 

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

 

From: Mike Jones
Sent: Tuesday, October 3, 2017 6:51 AM
To: oauth@ietf.org
Subject: Adding a SAML 2 token type to the OAuth Token Exchange spec=

 

A Microsoft use case has come up in which people wou= ld like to perform a token exchange for a SAML token. The spec already defi= nes urn:ietf:params:oauth:t= oken-type:jwt for requesting JWT tokens.  Would anybody object = to us adding urn:ietf:params:oauth:t= oken-type:saml2 to the next draft to also give us a standard way to = ask for SAML 2.0 tokens?

 

It could always be done in its own spec, but adding = it in Token Exchange seems more expedient.

 

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

 

 

--_000_CY4PR21MB0504E84EF80D0F0209979970F5390CY4PR21MB0504namp_--