From nobody Mon Nov 2 04:06:35 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 328921A6F2F for ; Mon, 2 Nov 2015 04:06:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E7vxDMf2C1LP for ; Mon, 2 Nov 2015 04:06:31 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 940E61A6F32 for ; Mon, 2 Nov 2015 04:06:30 -0800 (PST) Received: from [192.168.10.233] ([118.243.125.63]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MQzUc-1a2YKz2QL0-00UKAM for ; Mon, 02 Nov 2015 13:06:28 +0100 To: "oauth@ietf.org" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <563751BF.4080808@gmx.net> Date: Mon, 2 Nov 2015 13:06:23 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="o0SqX1lBhwjmrfbALDDesobrpTw5m0FK0" X-Provags-ID: V03:K0:PHYY2QgD44fxdIMAa4vwR2oFeabPhdpnRl09k8JGP8paUiWR9HY vypKsSaq9WmCdDhoFJJNP6EeQq4KS5tEOJCllsfbc2n4uctLdhyMp4ngt23BsbljTjOplVG nt2Dt/EpD0p3l0LQPDOxkcN1l6yupD6FuXE/KqjGMGwZ1RPrrxkFUzUt2XRn5/TtAKFFuFt et4ctN4TL0AEkXssTuDUA== X-UI-Out-Filterresults: notjunk:1;V01:K0:WcVPCftTipA=:/OrgMd8BjUdBGH51Ll6RgK lp/mCKghNeC5jVj8TNE9x8IHoZhG9iFGC4pKkM24a+euBFW8jKgw38iK7oKxtCIjTKkN3Aqmt 4XmXqJMwgeFDxIeMvspBbhfKWvxTA/3vtXoGDQCLLRkzdMi3gRfZ1MGA+KVKdflpuZhxe5w8J jBBMDpalaf5B9CCoDMsS1Mt1IKVRaVSjF8uk23QbryHEDuUgPSiIDeoQ0P3cvXxL3Pe4oVkqC BCJXTgdSPqWMvhBI1z8WS6O4jOiyX5zKsdSeVZ/H9k1TmBXxY6+o2m7932hbgvjt6H5ZfnTV2 PRoJ+Tob0MlSzOsAsCoek9Hr4NCTuNNBgoAcZuOhp0QNJUMd87NqVKo3EGnXgbqe9/gIUDY2g qIXt7waJ0DNu2vw4zppKaOsgOYLw9Eumg92BCnZUre7dWJnvRRMCPA7QTGZ3y6Zg1TLGv7VLt A2kEIuFVHne1n65wWEIL79l6jg0SNjIHm0aZNwtceAvph9FRizPOgrtNH0vxlPRJiCzvclBJ/ lFX7/5a6NZBfwLBFJCSytJjbQtp+k2iDyUrDmegSRGTkbdzPSoGBTVaQokuwdkrtVcFOHVqfB ke3ZC/tsg+1OvKyLwiN6HSrNf2JhIzRQkzYLMurZ/yVpgToApk5Td6qmjJh4dvcZgn8X0jFJa SwXRlRz8zT4I5jJvvlK0YewR94fU6gHyHTPhKZAPJH99rs9L+JODNNUARj6KB96w8N0XPsSGz SWDWbvMFkynImAem6nf+pwF5nhXr+F+MCf2SN434rgCG9P+f5dOm8DmFuKs= Archived-At: Subject: [OAUTH-WG] Review of draft-ietf-oauth-jwsreq-06 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2015 12:06:34 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --o0SqX1lBhwjmrfbALDDesobrpTw5m0FK0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Nat, Hi John, thanks for the work on this document. I have started my review and wanted to post a few thoughts about the abstract and the introduction. I have some wording suggestions for the abstract. Here is the current abstract: " The authorization request in RFC6749 utilizes query parameter serialization. This specification defines the authorization request using JWT serialization. The request is sent by value through "request" parameter or by reference through "request_uri" parameter that points to the JWT, allowing the request to be optionally signed and encrypted. " Here is my new proposal: " The authorization request in OAuth 2.0 utilizes query parameter serialization, which means that parameters are encoded in the URI of the request. This document introduces the ability to send request parameters in form of a JSON Web Token (JWT) instead, which allows the request to be signed and encrypted. The request is sent by value or by reference. We call the 'JWT Authorization Request' extension JAR. " 1. Introduction I would expect the following structure of this section. a) A description on how things are done today. Here is a proposal: " The OAuth 2.0 specification [RFC 6749] defines the encoding of requests and responses and in case of the authorization request query parameter serialization has been chosen. For example, the parameters 'response_type', 'client_id', 'state', and 'redirect_uri' are encoded in the URI of the request: GET /authorize?response_type=3Dcode&client_id=3Ds6BhdRkqt3&state=3Dxyz &redirect_uri=3Dhttps%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1 Host: server.example.com " b) Why are we making changes / additions? What is wrong with the current way of doing things? Here is a proposal: " The encoding in the URI does not allow application layer security with confidentiality and integrity protection to be used. While TLS is used to offer communication security between the client and the resource server, TLS sessions are often terminated prematurely at some middlebox (such as a load balancer). The use of application layer security additionally allows requests to be prepared by a third party so that a client application cannot request more permissions than previously agreed. This offers an additional degree of privacy protection. " The request by reference allows to reduce the over-the-wire overhead. c) What is the solution (at a high level) described in the document? " The parameters "request" and "request_uri" are introduced as additional authorization request parameters for the OAuth 2.0 [RFC6749] flows. The "request" parameter is a JSON Web Token (JWT) [RFC7519] whose JWT Claims Set holds the JSON encoded OAuth 2.0 authorization request parameters. The JWT [RFC7519] can be passed to the authorization endpoint by reference, in which case the parameter "request_uri" is used instead of the "request". " You may want to explain why you have chosen the JWT format rather than something else, such as the CBOR format. I have a few comments regarding the benefits of the . You write: There are a few cases that request by reference are useful such as: 1. When it is detected that the User Agent does not support long URLs: Some extensions may extend the URL. For example, the client might want to send a public key with the request. [Hannes] I believe what you are trying to say in this section is that the use of the reference reduces the size of the transmitted request since the use of application layer security, and public key cryptography in particular, substantially increases the size. 2. Static signature: The client can make a signed Request Object and put it at a place that the Authorization Server can access. This may just be done by a client utility or other process, so that the private key does not have to reside on the client, simplifying programming. [Hannes] The downside of this approach is that it is vulnerable to reply protection and the signature only becomes a token. Another downside is that the developer(?) has to place the JWT at some server first. 3. When the server wants the requests to be cacheable: The request_uri may include a SHA-256 hash of the file, as defined in FIPS180-2 [FIPS180-2], the server knows if the file has changed without fetching it, so it does not have to re-fetch a same file, which is a win as well. [Hannes] I believe that this is a by-product of item #2. I am not sure what the hash of the file means here. 4. When the client wants to simplify the implementation without compromising the security. If the request parameters go through the browser, they may be tampered in the browser even if TLS was used. This implies we need to have signature on the request as well. However, if HTTPS "request_uri" was used, it is not going to be tampered, thus we now do not have to sign the request. This simplifies the implementation. [Hannes] Could you explain this threat a bit more? Is this aspect related to some prior OAuth work, such as PKCE? Ciao Hannes --o0SqX1lBhwjmrfbALDDesobrpTw5m0FK0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJWN1G/AAoJEGhJURNOOiAtvJsH/j6MvdFjFsN9+f3Zy0eYLknT +5JrSIJdDG0l8/XRo2UjV5SJjOYDggm9/nu543dN3CflUNsEG7FWzgmqnzhN1mSx GMRY9n54ph9u30OWSjW9Oycgw9RdESPL/4HMlGkS3bVZgJEeK2NCDGQuc3j3vq0F TpcC1dpx6CdLLYITpclWH0Zy1dZ8HhMLw/Ee0ZwrpaJhuMpJf4APMPcJGgP9yiNK LtsHnsaPKn7+lKjwj+hpIi4hfVuxLjKvtzY9UZrTR01tM5gWRwY+zEYn++udjAEi Z2nBTi4rXM/5VuOC1MNIUjv9S5Y3CDP28drbekuxhiRBocv63QNccFFjfvprdT8= =CqaW -----END PGP SIGNATURE----- --o0SqX1lBhwjmrfbALDDesobrpTw5m0FK0-- From michael.ciarlillo@gmail.com Sun Nov 1 10:17:10 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0C1B1B8AC8 for ; Sun, 1 Nov 2015 10:17:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8dUhkvN_3j2v for ; Sun, 1 Nov 2015 10:17:08 -0800 (PST) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::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 D7CE61B8A6F for ; Sun, 1 Nov 2015 10:17:07 -0800 (PST) Received: by qgeo38 with SMTP id o38so101434349qge.0 for ; Sun, 01 Nov 2015 10:17:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=ZK2ZejyGdi9Qi1nTveTW7EY6pY5aShJ4NQK6QPPl6eg=; b=D/r2O2aG4ZQFf6iYn1G1ln/1ePC+1XgTyQT9wJ5RnioCkuTu8iMOBz4ZaybvBVJ3yK ipxhksT6SZ8DJHMzO5E/NICzkIrs1TgJUvTp3pwEJfWpDaPdaSsLxUFuDV0DzK1mkrXm C9JSFy6b01NbalfbPNvhWpfY3u18gN+VPMtyUkqTxfqHpc4H431dI1TSTYhJPpoNBcQN qw5+6nviBIezPLiNOJ9f4D8hcDJH99cteyz1l8ssIZSt0VGUSi3n4hC019H2YmS/gm16 NhlHNPmMuX3as7ERBsOfSi7Q0JTtM39G7DVj5ShmcNhKt+VeUhY+abJdOiL0LYn22Xzp +UVg== MIME-Version: 1.0 X-Received: by 10.140.145.75 with SMTP id 72mr25736303qhr.81.1446401827065; Sun, 01 Nov 2015 10:17:07 -0800 (PST) Received: by 10.140.89.199 with HTTP; Sun, 1 Nov 2015 10:17:07 -0800 (PST) Date: Sun, 1 Nov 2015 13:17:07 -0500 Message-ID: From: Michael Ciarlillo To: oauth@ietf.org Content-Type: multipart/alternative; boundary=001a113560821ad50505237eab23 Archived-At: X-Mailman-Approved-At: Mon, 02 Nov 2015 08:05:51 -0800 Subject: [OAUTH-WG] OAuth 2.0 Introspection RFC Issues X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Nov 2015 18:19:09 -0000 --001a113560821ad50505237eab23 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello all, I have a couple of comments/issues with the RFC at https://tools.ietf.org/html/rfc7662. According to Section 2.1 (Introspection Request) says that "To prevent token scanning attacks, the endpoint MUST also require some form of authorization to access this endpoint..." This might make sense for token introspection requests only coming from Resource Servers, but to many implementers it makes sense to allow Clients access to the introspection endpoint since it would serve the same purpose (token validity checking, particularly for refresh tokens, but also for access tokens, or identity tokens in OpenID Connect, or possibly other token types in UMA and other specs). Unfortunately, this means that public clients should be accounted for in some way, as refresh tokens don't have an explicit requirement in the OAuth 2.0 spec that they be issued only to Confidential Clients. As such, many implementers don't feel like the Introspection spec fits well for Client consumption because of the "MUST" requirement on authentication, when public clients won't have a Client Secret to authenticate with. Further, token scanning attacks would not be mitigated for authenticated callers (be they Resource Servers or Clients). An example of a real-world implementer discussion talking about this topic is one I had with K=C3=A9vin Chalet: https://github.com/aspnet-contrib/AspNet.Security.OpenIdConnect.Server/pull= /159 We are not the only ones who see this as a problem with the spec, and there do not seem to be many concrete reasons for this endpoint ONLY being for Resource Servers themselves. Can some insight into why this is the case? Can the MUST be changed to a SHOULD with the Security Considerations section expanded to talk about the issue? If not, is there another spec or draft out there somewhere for OAuth token validity for which the intent is explicitly client consumption? Any and all feedback on this would be greatly appreciated as we develop the ASOS middleware project. Another (small) comment on the spec: Section 2.1 (Introspection Request) currently says that requests be HTTP POST method requests, however Section 4 (Security Considerations) mentions Authorization Servers explicitly disallowing the GET method due to server logs. What is the requirement here? POST with optional GET or explicitly only allowing POST requests? Sincerely, Michael Ciarlillo --001a113560821ad50505237eab23 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello all,

I have a couple of comments/= issues with the RFC at http= s://tools.ietf.org/html/rfc7662.

According to Sectio= n 2.1 (Introspection Request) says that "To prevent token scanning attacks, the endpoint MUS= T also require=C2=A0some form of authorization to access this endpoint..."=C2= =A0This might make sense for token introspection requests only coming from = Resource Servers, but to many implementers it makes sense to allow Clients = access to the introspection endpoint since it would serve the same purpose = (token validity checking, particularly for refresh tokens, but also for acc= ess tokens, or identity tokens in OpenID Connect, or possibly other token t= ypes in UMA and other specs). Unfortunately, this means that public clients= should be accounted for in some way, as refresh tokens don't have an e= xplicit requirement in the OAuth 2.0 spec that they be issued only to Confi= dential Clients. As such, many implementers don't feel like the Introsp= ection spec fits well for Client consumption because of the "MUST"= ; requirement on authentication, when public clients won't have a Clien= t Secret to authenticate with. Further, token scanning attacks would not be= mitigated for authenticated callers (be they Resource Servers or Clients).=

An example of a real-world implementer discussion= talking about this topic is one I had with=C2=A0K=C3=A9vin Chalet:=C2=A0https://github.com/aspnet-contrib/AspNet.Security.OpenIdConn= ect.Server/pull/159

We are not the only ones w= ho see this as a problem with the spec, and there do not seem to be many co= ncrete reasons for this endpoint ONLY being for Resource Servers themselves= . Can some insight into why this is the case? Can the MUST be changed to a = SHOULD with the Security Considerations section expanded to talk about the = issue? If not, is there another spec or draft out there somewhere for OAuth= token validity for which the intent is explicitly client consumption? Any = and all feedback on this would be greatly appreciated as we develop the ASO= S middleware project.

Another (small) comment on t= he spec: Section 2.1 (Introspection Request) currently says that requests b= e HTTP POST method requests, however Section 4 (Security Considerations) me= ntions Authorization Servers explicitly disallowing the GET method due to s= erver logs. What is the requirement here? POST with optional GET or explici= tly only allowing POST requests?

Sincerely,
<= div>Michael Ciarlillo
--001a113560821ad50505237eab23-- From nobody Mon Nov 2 08:42:57 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C06EA1B4988 for ; Mon, 2 Nov 2015 08:42:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TaoeEkQ7iiM8 for ; Mon, 2 Nov 2015 08:42:53 -0800 (PST) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A61781A039D for ; Mon, 2 Nov 2015 08:42:52 -0800 (PST) X-AuditID: 1209190e-f79296d00000051c-b6-5637928a01cc Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 65.72.01308.B8297365; Mon, 2 Nov 2015 11:42:51 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id tA2Ggocx017654; Mon, 2 Nov 2015 11:42:50 -0500 Received: from dhcp-70-134.meeting.ietf94.jp (dhcp-70-134.meeting.ietf94.jp [133.93.70.134]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id tA2GgKop004425 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 2 Nov 2015 11:42:37 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_D5B4C35B-3EAE-4F74-8FC4-7662FD013CE1" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Justin Richer In-Reply-To: Date: Tue, 3 Nov 2015 01:42:17 +0900 Message-Id: <6A84AF37-C6FC-41DD-99D6-32A8DDD7A18A@mit.edu> References: To: Michael Ciarlillo X-Mailer: Apple Mail (2.2104) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnleLIzCtJLcpLzFFi42IRYrdT1+2eZB5msGsbt8WavQuZLU6+fcXm wOSxc9Zddo8lS34yBTBFcdmkpOZklqUW6dslcGU0HjrIXrAvseLe8ztsDYzfArsYOTkkBEwk 7s6eywhhi0lcuLeerYuRi0NIYDGTxPM5r6CcDYwSXS+PMIFUCQncYJK4dNgLxGYWSJDoWbuF GcTmFdCTeHXrMiuILSxgJTH3BEQ9m4CqxPyVt8BsToFAiV0NG8BqWARUJJ78fsvexcgBNEdd ov2kC8QYK4l7v86yQKwKkLgysROsXETAWOLHhQ/MEIfKSuz+/YhpAqPALCRXzEJyBURcW2LZ wtfMELamxP7u5SyY4hoSnd8msi5gZFvFKJuSW6Wbm5iZU5yarFucnJiXl1qka6yXm1mil5pS uokRFO6cknw7GL8eVDrEKMDBqMTDe8DTLEyINbGsuDL3EKMkB5OSKG9Ir3mYEF9SfkplRmJx RnxRaU5q8SFGCQ5mJRHec/1AOd6UxMqq1KJ8mJQ0B4uSOO+mH3whQgLpiSWp2ampBalFMFkZ Dg4lCV6liUCNgkWp6akVaZk5JQhpJg5OkOE8QMPLQWp4iwsSc4sz0yHypxgVpcR5pUESAiCJ jNI8uF5QOmqNdWt7xSgO9Iow7xyQKh5gKoPrfgU0mAlocPg2U5DBJYkIKakGxpqdXswL18dM e6z35B/TtU6RyeurIyf3SXJy7kv7d1DN8K558187qb4zgtaaPH7r1LYcNvubz1u0+AFnc8J3 D/ZVh7R0Zk6RyZAy4l12gb/uT4vndMWnNT859S7z7dsbLKJ9curhCUIaHzIMrkW/+KlaYXFT 8nP47KNzVW7u8H2hKrl5DZvzFiWW4oxEQy3mouJEAH9JrTYiAwAA Archived-At: Cc: "" Subject: Re: [OAUTH-WG] OAuth 2.0 Introspection RFC Issues X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2015 16:42:55 -0000 --Apple-Mail=_D5B4C35B-3EAE-4F74-8FC4-7662FD013CE1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Michael, Thanks for the comments. First off, the text of an RFC is fixed and = cannot be changed. The spec can only be altered with a new document that = obsoletes RFC7662, which would have to go through the working group = process again from the very beginning. Authentication is required but we=E2=80=99re open to how it happens. The = introspection spec is targeted at resource servers, not clients, since a = client can always just *use* the token in order to see if it=E2=80=99s = valid or not. Why bother with the extra round trip to check if the token = is good before trying it, since trying it will also tell you if the = token=E2=80=99s good? The recovery process for a failed token is the = same in either state. We initially had this written for either clients = or protected resources, but that=E2=80=99s not how people were using it = and restricting its focus helped clarify the spec immensely. ID tokens are a slightly different case as they=E2=80=99re an assertion = targeted at the client itself, but in those cases an ID token is really = meant to be self-contained as a JWT, and generally has a short validity = period. If you=E2=80=99re looking to introspect an old ID token to check = an OIDC session status, then you might be better served implementing one = of the OIDC session spec components for that purpose. Also, we didn=E2=80=99t mandate a specific authentication technology. = Most people are going to use either client authentication or a specific = OAuth token designed for this purpose. The latter of these is = technically available for public clients, but then you have the question = of if you want to check the status of *that* token too. Still, I think = that for any clients (including public ones) the right thing to do is = just use the token and see if it works.=20 To the other comment, HTTP POST is the only defined verb and we=E2=80=99re= silent on the use of other verbs. That said, many HTTP implementation = frameworks don=E2=80=99t differentiate between verbs for requests and so = a POST with body form parameters and a GET with query parameters would = come out the same. We don=E2=80=99t outright prohibit this behavior, but = it=E2=80=99s off-label and there are security considerations for its = use. Hope this helps, =E2=80=94 Justin > On Nov 2, 2015, at 3:17 AM, Michael Ciarlillo = wrote: >=20 > Hello all, >=20 > I have a couple of comments/issues with the RFC at = https://tools.ietf.org/html/rfc7662 = . >=20 > According to Section 2.1 (Introspection Request) says that "To prevent = token scanning attacks, the endpoint MUST also require some form of = authorization to access this endpoint..." This might make sense for = token introspection requests only coming from Resource Servers, but to = many implementers it makes sense to allow Clients access to the = introspection endpoint since it would serve the same purpose (token = validity checking, particularly for refresh tokens, but also for access = tokens, or identity tokens in OpenID Connect, or possibly other token = types in UMA and other specs). Unfortunately, this means that public = clients should be accounted for in some way, as refresh tokens don't = have an explicit requirement in the OAuth 2.0 spec that they be issued = only to Confidential Clients. As such, many implementers don't feel like = the Introspection spec fits well for Client consumption because of the = "MUST" requirement on authentication, when public clients won't have a = Client Secret to authenticate with. Further, token scanning attacks = would not be mitigated for authenticated callers (be they Resource = Servers or Clients). >=20 > An example of a real-world implementer discussion talking about this = topic is one I had with K=C3=A9vin Chalet: = https://github.com/aspnet-contrib/AspNet.Security.OpenIdConnect.Server/pul= l/159 = >=20 > We are not the only ones who see this as a problem with the spec, and = there do not seem to be many concrete reasons for this endpoint ONLY = being for Resource Servers themselves. Can some insight into why this is = the case? Can the MUST be changed to a SHOULD with the Security = Considerations section expanded to talk about the issue? If not, is = there another spec or draft out there somewhere for OAuth token validity = for which the intent is explicitly client consumption? Any and all = feedback on this would be greatly appreciated as we develop the ASOS = middleware project. >=20 > Another (small) comment on the spec: Section 2.1 (Introspection = Request) currently says that requests be HTTP POST method requests, = however Section 4 (Security Considerations) mentions Authorization = Servers explicitly disallowing the GET method due to server logs. What = is the requirement here? POST with optional GET or explicitly only = allowing POST requests? >=20 > Sincerely, > Michael Ciarlillo > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_D5B4C35B-3EAE-4F74-8FC4-7662FD013CE1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Michael,

Thanks for the comments. First off, the text of an RFC is = fixed and cannot be changed. The spec can only be altered with a new = document that obsoletes RFC7662, which would have to go through the = working group process again from the very beginning.

Authentication is = required but we=E2=80=99re open to how it happens. The introspection = spec is targeted at resource servers, not clients, since a client can = always just *use* the token in order to see if it=E2=80=99s valid or = not. Why bother with the extra round trip to check if the token is good = before trying it, since trying it will also tell you if the token=E2=80=99= s good? The recovery process for a failed token is the same in either = state. We initially had this written for either clients or protected = resources, but that=E2=80=99s not how people were using it and = restricting its focus helped clarify the spec immensely.

ID tokens are a slightly = different case as they=E2=80=99re an assertion targeted at the client = itself, but in those cases an ID token is really meant to be = self-contained as a JWT, and generally has a short validity period. If = you=E2=80=99re looking to introspect an old ID token to check an OIDC = session status, then you might be better served implementing one of the = OIDC session spec components for that purpose.

Also, we didn=E2=80=99t mandate a = specific authentication technology. Most people are going to use either = client authentication or a specific OAuth token designed for this = purpose. The latter of these is technically available for public = clients, but then you have the question of if you want to check the = status of *that* token too. Still, I think that for any clients = (including public ones) the right thing to do is just use the token and = see if it works. 

To the other comment, HTTP POST is the only defined verb and = we=E2=80=99re silent on the use of other verbs. That said, many HTTP = implementation frameworks don=E2=80=99t differentiate between verbs for = requests and so a POST with body form parameters and a GET with query = parameters would come out the same. We don=E2=80=99t outright prohibit = this behavior, but it=E2=80=99s off-label and there are security = considerations for its use.

Hope this helps,
 =E2=80=94 = Justin

On Nov 2, 2015, at 3:17 AM, Michael Ciarlillo = <michael.ciarlillo@gmail.com> wrote:

Hello all,

I have a couple of comments/issues with = the RFC at https://tools.ietf.org/html/rfc7662.

According to Section 2.1 (Introspection = Request) says that "To = prevent token scanning attacks, the endpoint MUST also = require some = form of authorization to access this endpoint..." This might = make sense for token introspection requests only coming from Resource = Servers, but to many implementers it makes sense to allow Clients access = to the introspection endpoint since it would serve the same purpose = (token validity checking, particularly for refresh tokens, but also for = access tokens, or identity tokens in OpenID Connect, or possibly other = token types in UMA and other specs). Unfortunately, this means that = public clients should be accounted for in some way, as refresh tokens = don't have an explicit requirement in the OAuth 2.0 spec that they be = issued only to Confidential Clients. As such, many implementers don't = feel like the Introspection spec fits well for Client consumption = because of the "MUST" requirement on authentication, when public clients = won't have a Client Secret to authenticate with. Further, token scanning = attacks would not be mitigated for authenticated callers (be they = Resource Servers or Clients).

An example of a real-world implementer = discussion talking about this topic is one I had with K=C3=A9vin = Chalet: https://github.com/aspnet-contrib/AspNet.Security.OpenIdConnect= .Server/pull/159

We are not the only ones who see this as a problem with the = spec, and there do not seem to be many concrete reasons for this = endpoint ONLY being for Resource Servers themselves. Can some insight = into why this is the case? Can the MUST be changed to a SHOULD with the = Security Considerations section expanded to talk about the issue? If = not, is there another spec or draft out there somewhere for OAuth token = validity for which the intent is explicitly client consumption? Any and = all feedback on this would be greatly appreciated as we develop the ASOS = middleware project.

Another (small) comment on the spec: Section 2.1 = (Introspection Request) currently says that requests be HTTP POST method = requests, however Section 4 (Security Considerations) mentions = Authorization Servers explicitly disallowing the GET method due to = server logs. What is the requirement here? POST with optional GET or = explicitly only allowing POST requests?

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

= --Apple-Mail=_D5B4C35B-3EAE-4F74-8FC4-7662FD013CE1-- From nobody Mon Nov 2 15:58:41 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98ECB1A911F for ; Mon, 2 Nov 2015 15:58:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WSiyquEDIbbB for ; Mon, 2 Nov 2015 15:58:37 -0800 (PST) Received: from mail-qg0-x236.google.com (mail-qg0-x236.google.com [IPv6:2607:f8b0:400d:c04::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 E7A601A911E for ; Mon, 2 Nov 2015 15:58:36 -0800 (PST) Received: by qgem9 with SMTP id m9so336850qge.1 for ; Mon, 02 Nov 2015 15:58:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=97NRWgIpJjP8X11wdXjgTvpRD2gFfi/e/TSfCTJYIUo=; b=c0D7E1qj6FP+BAZdIiV1/6R5+zOR9ZGQJUpDkUaByaL7L+wqp9nn0APq+RPuYVlqE9 2tHWBTztIuehmwF/6+8q3x4QFATrB4YzFmM4BTiu3Y6sUbYd/XqddTXiAh4nlHXxOSo9 3ab+6onAHdNS4R5DN/5C3sSEQPuq2KLt020D2hfwl1EROSafiRjSO0TF30u3GFY3U7lK TPZlHAsh4t9QqO26SXbt87tm8Exd3xJD4OCaHQlSBOeEZvuWjAMj667U9LHAhTbXyYBr sBOGyLeUh2rYPGzZEVzWczqNCWdHO8XZXa2wiHMCxriKaxqNNbG9zizuAhIBn8UxKqJy 2VGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=97NRWgIpJjP8X11wdXjgTvpRD2gFfi/e/TSfCTJYIUo=; b=RtrwIcOkaAgMbZJdJo1EaOCRCU+ljxQui3Kl3VI3jGuWolobXAoTFDMm6+Vbonu5li QFfypjodAuJKezp4LEa8z9u633kJSHgsjcNIsRdv2oMs93l0xK7Du9567CAg34A9fTZV Q0dpZnT7ixKyEFYYJ5fagKearuUvwIMJ3bB2l0YDzwr0MleireY2PbDsdRcHqKoAFvRg QMPknQO6Toracxs5HE2qehmYg3JHGlKJsv4Z2JrOA2TSDAzDrbyxMMCViVqdJWJcNN+y FaAvHpGpBZmRhmfJQPlXPbJ6xPyFrdTMZvBNiJTMTCtJz/q8wa43vp2Fd8DvMl7pSNvP 4CxA== X-Gm-Message-State: ALoCoQl58+gwbCYz9APP011B86z2vh+SoBoEUgpeyoIJek6yClpD9jzUf6w/gh80k+aUSr+51GoR X-Received: by 10.140.93.139 with SMTP id d11mr33585752qge.83.1446508715972; Mon, 02 Nov 2015 15:58:35 -0800 (PST) MIME-Version: 1.0 References: <6A84AF37-C6FC-41DD-99D6-32A8DDD7A18A@mit.edu> In-Reply-To: <6A84AF37-C6FC-41DD-99D6-32A8DDD7A18A@mit.edu> From: William Denniss Date: Mon, 02 Nov 2015 23:58:25 +0000 Message-ID: To: Justin Richer , Michael Ciarlillo Content-Type: multipart/alternative; boundary=001a113958c82e5ddf0523978ea1 Archived-At: Cc: "" Subject: Re: [OAUTH-WG] OAuth 2.0 Introspection RFC Issues X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2015 23:58:39 -0000 --001a113958c82e5ddf0523978ea1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable We had a debate on that MUST at the last IETF, but the spec was too far along to change. The workaround is to treat the token you are introspecting as the authentication. With that workaround, the spec is quite usable for non-confidential clients, even if resource servers were the primary target. Google currently runs an introspection endpoint of sorts for clients, named "tokeninfo", and the latest version (v3) is close to the spec (coincidence - it's a good design pattern). Aimed mostly at debugging use-cases or if you don't have a JWT decoding library handy. On Tue, Nov 3, 2015 at 1:43 AM Justin Richer wrote: > Hi Michael, > > Thanks for the comments. First off, the text of an RFC is fixed and canno= t > be changed. The spec can only be altered with a new document that obsolet= es > RFC7662, which would have to go through the working group process again > from the very beginning. > > Authentication is required but we=E2=80=99re open to how it happens. The > introspection spec is targeted at resource servers, not clients, since a > client can always just *use* the token in order to see if it=E2=80=99s va= lid or > not. Why bother with the extra round trip to check if the token is good > before trying it, since trying it will also tell you if the token=E2=80= =99s good? > The recovery process for a failed token is the same in either state. We > initially had this written for either clients or protected resources, but > that=E2=80=99s not how people were using it and restricting its focus hel= ped > clarify the spec immensely. > > ID tokens are a slightly different case as they=E2=80=99re an assertion t= argeted > at the client itself, but in those cases an ID token is really meant to b= e > self-contained as a JWT, and generally has a short validity period. If > you=E2=80=99re looking to introspect an old ID token to check an OIDC ses= sion > status, then you might be better served implementing one of the OIDC > session spec components for that purpose. > > Also, we didn=E2=80=99t mandate a specific authentication technology. Mos= t people > are going to use either client authentication or a specific OAuth token > designed for this purpose. The latter of these is technically available f= or > public clients, but then you have the question of if you want to check th= e > status of *that* token too. Still, I think that for any clients (includin= g > public ones) the right thing to do is just use the token and see if it > works. > > To the other comment, HTTP POST is the only defined verb and we=E2=80=99r= e silent > on the use of other verbs. That said, many HTTP implementation frameworks > don=E2=80=99t differentiate between verbs for requests and so a POST with= body form > parameters and a GET with query parameters would come out the same. We > don=E2=80=99t outright prohibit this behavior, but it=E2=80=99s off-label= and there are > security considerations for its use. > > Hope this helps, > =E2=80=94 Justin > > On Nov 2, 2015, at 3:17 AM, Michael Ciarlillo > wrote: > > Hello all, > > I have a couple of comments/issues with the RFC at > https://tools.ietf.org/html/rfc7662. > > According to Section 2.1 (Introspection Request) says that "To prevent > token scanning attacks, the endpoint MUST also require some form of > authorization to access this endpoint..." This might make sense for token > introspection requests only coming from Resource Servers, but to many > implementers it makes sense to allow Clients access to the introspection > endpoint since it would serve the same purpose (token validity checking, > particularly for refresh tokens, but also for access tokens, or identity > tokens in OpenID Connect, or possibly other token types in UMA and other > specs). Unfortunately, this means that public clients should be accounted > for in some way, as refresh tokens don't have an explicit requirement in > the OAuth 2.0 spec that they be issued only to Confidential Clients. As > such, many implementers don't feel like the Introspection spec fits well > for Client consumption because of the "MUST" requirement on authenticatio= n, > when public clients won't have a Client Secret to authenticate with. > Further, token scanning attacks would not be mitigated for authenticated > callers (be they Resource Servers or Clients). > > An example of a real-world implementer discussion talking about this topi= c > is one I had with K=C3=A9vin Chalet: > https://github.com/aspnet-contrib/AspNet.Security.OpenIdConnect.Server/pu= ll/159 > > We are not the only ones who see this as a problem with the spec, and > there do not seem to be many concrete reasons for this endpoint ONLY bein= g > for Resource Servers themselves. Can some insight into why this is the > case? Can the MUST be changed to a SHOULD with the Security Consideration= s > section expanded to talk about the issue? If not, is there another spec o= r > draft out there somewhere for OAuth token validity for which the intent i= s > explicitly client consumption? Any and all feedback on this would be > greatly appreciated as we develop the ASOS middleware project. > > Another (small) comment on the spec: Section 2.1 (Introspection Request) > currently says that requests be HTTP POST method requests, however Sectio= n > 4 (Security Considerations) mentions Authorization Servers explicitly > disallowing the GET method due to server logs. What is the requirement > here? POST with optional GET or explicitly only allowing POST requests? > > Sincerely, > Michael Ciarlillo > _______________________________________________ > 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 > --001a113958c82e5ddf0523978ea1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable We had a debate on that MUST at the last IETF, but the spec was too far alo= ng to change. The workaround is to treat the token you are introspecting as= the authentication. With that workaround, the spec is quite usable for non= -confidential clients, even if resource servers were the primary target.
Google currently runs an introspection endpoint of sorts for clients, = named "tokeninfo", and the latest version (v3) is close to the sp= ec (coincidence - it's a good design pattern). Aimed mostly at debuggin= g use-cases or if you don't have a JWT decoding library handy.
On Tue, Nov 3, 2015 at 1:43 AM Just= in Richer <jricher@mit.edu> wr= ote:
Hi Michael,

Thanks for the comments. First off, th= e text of an RFC is fixed and cannot be changed. The spec can only be alter= ed with a new document that obsoletes RFC7662, which would have to go throu= gh the working group process again from the very beginning.

<= /div>
Authentication is required but we=E2=80=99re open to how it happe= ns. The introspection spec is targeted at resource servers, not clients, si= nce a client can always just *use* the token in order to see if it=E2=80=99= s valid or not. Why bother with the extra round trip to check if the token = is good before trying it, since trying it will also tell you if the token= =E2=80=99s good? The recovery process for a failed token is the same in eit= her state. We initially had this written for either clients or protected re= sources, but that=E2=80=99s not how people were using it and restricting it= s focus helped clarify the spec immensely.

ID toke= ns are a slightly different case as they=E2=80=99re an assertion targeted a= t the client itself, but in those cases an ID token is really meant to be s= elf-contained as a JWT, and generally has a short validity period. If you= =E2=80=99re looking to introspect an old ID token to check an OIDC session = status, then you might be better served implementing one of the OIDC sessio= n spec components for that purpose.

Also, we didn= =E2=80=99t mandate a specific authentication technology. Most people are go= ing to use either client authentication or a specific OAuth token designed = for this purpose. The latter of these is technically available for public c= lients, but then you have the question of if you want to check the status o= f *that* token too. Still, I think that for any clients (including public o= nes) the right thing to do is just use the token and see if it works.=C2=A0=

To the other comment, HTTP POST is the only defin= ed verb and we=E2=80=99re silent on the use of other verbs. That said, many= HTTP implementation frameworks don=E2=80=99t differentiate between verbs f= or requests and so a POST with body form parameters and a GET with query pa= rameters would come out the same. We don=E2=80=99t outright prohibit this b= ehavior, but it=E2=80=99s off-label and there are security considerations f= or its use.

Hope this helps,
=C2=A0=E2= =80=94 Justin

=
On Nov 2, 2015, at 3:17 AM, Michael Ciarlill= o <mich= ael.ciarlillo@gmail.com> wrote:

Hello= all,

I have a couple of comments/issues with the RFC at= https://= tools.ietf.org/html/rfc7662.

According to Section 2.= 1 (Introspection Request) says that "To prevent token scanning attacks, the endpoint MUST also require=C2=A0<= /span>some form of authorization to acc= ess this endpoint..."=C2=A0This might make sense for token intr= ospection requests only coming from Resource Servers, but to many implement= ers it makes sense to allow Clients access to the introspection endpoint si= nce it would serve the same purpose (token validity checking, particularly = for refresh tokens, but also for access tokens, or identity tokens in OpenI= D Connect, or possibly other token types in UMA and other specs). Unfortuna= tely, this means that public clients should be accounted for in some way, a= s refresh tokens don't have an explicit requirement in the OAuth 2.0 sp= ec that they be issued only to Confidential Clients. As such, many implemen= ters don't feel like the Introspection spec fits well for Client consum= ption because of the "MUST" requirement on authentication, when p= ublic clients won't have a Client Secret to authenticate with. Further,= token scanning attacks would not be mitigated for authenticated callers (b= e they Resource Servers or Clients).

An example of= a real-world implementer discussion talking about this topic is one I had = with=C2=A0K=C3=A9vin Chalet:=C2=A0https:= //github.com/aspnet-contrib/AspNet.Security.OpenIdConnect.Server/pull/159



_______________________________________________
OAuth mailing list
OAuth@ietf.org
http= s://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--001a113958c82e5ddf0523978ea1-- From nobody Mon Nov 2 16:45:28 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C6101AC3F2 for ; Mon, 2 Nov 2015 16:45:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qxs0RNIWeMQ9 for ; Mon, 2 Nov 2015 16:45:23 -0800 (PST) Received: from mail-qg0-x234.google.com (mail-qg0-x234.google.com [IPv6:2607:f8b0:400d:c04::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 8B8861AC3CF for ; Mon, 2 Nov 2015 16:45:23 -0800 (PST) Received: by qgeo38 with SMTP id o38so1153604qge.0 for ; Mon, 02 Nov 2015 16:45:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=hCq0aT3L1u8OwieTBeyPiA7yHgyEIdBN7bD/8/yUyH8=; b=j9UHCCQNcZm2b6YdEZv9Prnle3hbqh7EjyIXjwdDHaCFeK/B5XaLCwsD0p/JTwVWgS M08VSsBBwju5rALKDk881V0LRj3rO7xtR+DoOUnW/drJ9LrxufrIPsUj5lE5ItIRKFMJ s4hnE0zASSC/FCxBUuvf+vd0gESQrXMni2jJFMpUVmFa8zTBuiybh3f3t1h4S+2f2Ags usIxqUU+BikW7ucGWlELDRxiiFxMqm/q/5sOWQjxVrPuS1wAriUibMx0puLhLi45nUTo AkKpecIc59i+6RqXgMctkWSJzYTVhMkH8Uvry/fctOWyeV7ufpvEjJGAjeKYMCVmmsZr JV2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=hCq0aT3L1u8OwieTBeyPiA7yHgyEIdBN7bD/8/yUyH8=; b=FDhQZEQxPlLBwXlfEsiw2JMnBQNE6gLa1T60tm/FlQLj0rHZFiAdeiCHF0kNe5YLq5 wkgWXepx/qrNYpeByVuuCwrM/AUgCIm+K8kKMdavLOWyq0Yh2b5F9tQiNAovq7Eopabe 68hqZcQXrvT7ZkJTMe7KRuVkHlWJ48vUtg+Q7aGLPhE30urXJsHzO4tiiNyTcmRrd8UA t3tTTMg9hzmFjs444rSxWhZFqWqZmX+0t1vLblnEE9pcgURIrcOPPSIg64R598TczIvO pFWd0pvfsecQRyHHgKIvLdXLBu6AtVShXsejte5YgBBn9L/txubLs68sRcClM7Ktruuv jCHw== X-Gm-Message-State: ALoCoQl6ICUEsugF47gZz0flhVcw5TS8hEkatBWL8GEycGP94E5PDoC1ZzJ2cOotDt/HqJjA2jQ7 X-Received: by 10.140.39.105 with SMTP id u96mr21150634qgu.35.1446511522623; Mon, 02 Nov 2015 16:45:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.102.18 with HTTP; Mon, 2 Nov 2015 16:45:03 -0800 (PST) In-Reply-To: <5637feb5.611a450a.bf33d.4307@mx.google.com> References: <6A84AF37-C6FC-41DD-99D6-32A8DDD7A18A@mit.edu> <5637feb5.611a450a.bf33d.4307@mx.google.com> From: William Denniss Date: Tue, 3 Nov 2015 09:45:03 +0900 Message-ID: To: Michael Ciarlillo Content-Type: multipart/alternative; boundary=001a11c13044787dfd052398352a Archived-At: Cc: "" Subject: Re: [OAUTH-WG] OAuth 2.0 Introspection RFC Issues X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 00:45:27 -0000 --001a11c13044787dfd052398352a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I advocated a similar position as yours 4 months ago, in the thread titled [OAUTH-WG] Token introspection for public clients? . My impression at the time is that the primary use-case of the spec was the RS one, even though it could support these other use-cases but for that MUST. I agree that using the token for authentication as a workaround does kind of break the point of the MUST, but as it is, the spec defines the authentication as "The methods of managing and validating these authentication credentials are out of scope of this specification.", so it is open to interpretation. On Tue, Nov 3, 2015 at 9:24 AM, Michael Ciarlillo < michael.ciarlillo@gmail.com> wrote: > Thanks for the feedback. > > I agree that the spec is not badly designed over all. I just think that > the MUST is a bit too restrictive, especially with how none of the OAuth > grants requires authentication to begin with except when a client is > Confidential or when using Client Credential flow (for obvious reasons). > > I don't believe that simply using a token to determine its validity is a > good course of action. There may very well be unintended side-effects (li= ke > the issuance of a new refresh/access token when using a refresh token at > the Token endpoint, or one-time use access tokens). One use case presente= d > by K=C3=A9vin Chalet is when a client might need to determine and what us= ers it > has been authorized access on behalf of and possibly remove those that ar= e > no longer valid. Another might be something like determining if an initia= l > one-time use access token for registration requests is still active and > available to use for client registration. > > Not having available resources or libraries to validate JWTs or other > tokens on the client was another use case mentioned in discussions we had= . > I'm glad others have had similar discussions for this scenario. > > That being said, the idea of using the token itself for authentication > intrigues me, though doesn't that inherently break the entire point of > having the authentication be a MUST in the spec to begin with? How might = an > Authorization Server mitigate inherent security risks with this approach > for any type of tokens? > ------------------------------ > From: William Denniss > Sent: =E2=80=8E11/=E2=80=8E2/=E2=80=8E2015 6:58 PM > To: Justin Richer ; Michael Ciarlillo > > Cc: > Subject: Re: [OAUTH-WG] OAuth 2.0 Introspection RFC Issues > > We had a debate on that MUST at the last IETF, but the spec was too far > along to change. The workaround is to treat the token you are introspecti= ng > as the authentication. With that workaround, the spec is quite usable for > non-confidential clients, even if resource servers were the primary targe= t. > > Google currently runs an introspection endpoint of sorts for clients, > named "tokeninfo", and the latest version (v3) is close to the spec > (coincidence - it's a good design pattern). Aimed mostly at debugging > use-cases or if you don't have a JWT decoding library handy. > On Tue, Nov 3, 2015 at 1:43 AM Justin Richer wrote: > >> Hi Michael, >> >> Thanks for the comments. First off, the text of an RFC is fixed and >> cannot be changed. The spec can only be altered with a new document that >> obsoletes RFC7662, which would have to go through the working group proc= ess >> again from the very beginning. >> >> Authentication is required but we=E2=80=99re open to how it happens. The >> introspection spec is targeted at resource servers, not clients, since a >> client can always just *use* the token in order to see if it=E2=80=99s v= alid or >> not. Why bother with the extra round trip to check if the token is good >> before trying it, since trying it will also tell you if the token=E2=80= =99s good? >> The recovery process for a failed token is the same in either state. We >> initially had this written for either clients or protected resources, bu= t >> that=E2=80=99s not how people were using it and restricting its focus he= lped >> clarify the spec immensely. >> >> ID tokens are a slightly different case as they=E2=80=99re an assertion = targeted >> at the client itself, but in those cases an ID token is really meant to = be >> self-contained as a JWT, and generally has a short validity period. If >> you=E2=80=99re looking to introspect an old ID token to check an OIDC se= ssion >> status, then you might be better served implementing one of the OIDC >> session spec components for that purpose. >> >> Also, we didn=E2=80=99t mandate a specific authentication technology. Mo= st people >> are going to use either client authentication or a specific OAuth token >> designed for this purpose. The latter of these is technically available = for >> public clients, but then you have the question of if you want to check t= he >> status of *that* token too. Still, I think that for any clients (includi= ng >> public ones) the right thing to do is just use the token and see if it >> works. >> >> To the other comment, HTTP POST is the only defined verb and we=E2=80=99= re silent >> on the use of other verbs. That said, many HTTP implementation framework= s >> don=E2=80=99t differentiate between verbs for requests and so a POST wit= h body form >> parameters and a GET with query parameters would come out the same. We >> don=E2=80=99t outright prohibit this behavior, but it=E2=80=99s off-labe= l and there are >> security considerations for its use. >> >> Hope this helps, >> =E2=80=94 Justin >> >> On Nov 2, 2015, at 3:17 AM, Michael Ciarlillo < >> michael.ciarlillo@gmail.com> wrote: >> >> Hello all, >> >> I have a couple of comments/issues with the RFC at >> https://tools.ietf.org/html/rfc7662. >> >> According to Section 2.1 (Introspection Request) says that "To prevent >> token scanning attacks, the endpoint MUST also require some form of >> authorization to access this endpoint..." This might make sense for >> token introspection requests only coming from Resource Servers, but to m= any >> implementers it makes sense to allow Clients access to the introspection >> endpoint since it would serve the same purpose (token validity checking, >> particularly for refresh tokens, but also for access tokens, or identity >> tokens in OpenID Connect, or possibly other token types in UMA and other >> specs). Unfortunately, this means that public clients should be accounte= d >> for in some way, as refresh tokens don't have an explicit requirement in >> the OAuth 2.0 spec that they be issued only to Confidential Clients. As >> such, many implementers don't feel like the Introspection spec fits well >> for Client consumption because of the "MUST" requirement on authenticati= on, >> when public clients won't have a Client Secret to authenticate with. >> Further, token scanning attacks would not be mitigated for authenticated >> callers (be they Resource Servers or Clients). >> >> An example of a real-world implementer discussion talking about this >> topic is one I had with K=C3=A9vin Chalet: >> https://github.com/aspnet-contrib/AspNet.Security.OpenIdConnect.Server/p= ull/159 >> >> We are not the only ones who see this as a problem with the spec, and >> there do not seem to be many concrete reasons for this endpoint ONLY bei= ng >> for Resource Servers themselves. Can some insight into why this is the >> case? Can the MUST be changed to a SHOULD with the Security Consideratio= ns >> section expanded to talk about the issue? If not, is there another spec = or >> draft out there somewhere for OAuth token validity for which the intent = is >> explicitly client consumption? Any and all feedback on this would be >> greatly appreciated as we develop the ASOS middleware project. >> >> Another (small) comment on the spec: Section 2.1 (Introspection Request) >> currently says that requests be HTTP POST method requests, however Secti= on >> 4 (Security Considerations) mentions Authorization Servers explicitly >> disallowing the GET method due to server logs. What is the requirement >> here? POST with optional GET or explicitly only allowing POST requests? >> >> Sincerely, >> Michael Ciarlillo >> _______________________________________________ >> 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 >> > --001a11c13044787dfd052398352a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I advocated a similar position as yours 4 months ago, in t= he thread titled [OAUTH-W= G] Token introspection for public clients?.

My = impression at the time is that the primary use-case of the spec was the RS = one, even though it could support these other use-cases but for that MUST.= =C2=A0 I agree that using the token for authentication as a workaround does= kind of break the point of the MUST, but as it is, the spec defines the au= thentication as "The methods of managing and validating these authenti= cation credentials are out of scope of this specification.", so it is = open to interpretation.

On Tue, Nov 3, 2015 at 9:24 AM, Michael Ciarlillo <= span dir=3D"ltr"><michael.ciarlillo@gmail.com> wrote:
Thanks for the feedback.

I agree that the spec is n= ot badly designed over all. I just think that the MUST is a bit too restric= tive, especially with how none of the OAuth grants requires authentication = to begin with except when a client is Confidential or when using Client Cre= dential flow (for obvious reasons).

I don't believe that simply = using a token to determine its validity is a good course of action. There m= ay very well be unintended side-effects (like the issuance of a new refresh= /access token when using a refresh token at the Token endpoint, or one-time= use access tokens). One use case presented by K=C3=A9vin Chalet is when a = client might need to determine and what users it has been authorized access= on behalf of and possibly remove those that are no longer valid. Another m= ight be something like determining if an initial one-time use access token = for registration requests is still active and available to use for client r= egistration.

Not having available resources or libraries to validate= JWTs or other tokens on the client was another use case mentioned in discu= ssions we had. I'm glad others have had similar discussions for this sc= enario.

That being said, the idea of using the token itself for auth= entication intrigues me, though doesn't that inherently break the entir= e point of having the authentication be a MUST in the spec to begin with? H= ow might an Authorization Server mitigate inherent security risks with this= approach for any type of tokens?
From:= William Denniss
Sent: =E2=80=8E11/=E2=80=8E2/=E2=80=8E2015 6:58 PM
To: <= /span>Justin Richer; Michael Ciarlillo
Cc: <oauth= @ietf.org>
Subject: Re: [OAUTH-WG] OAuth 2.0 Introspection R= FC Issues

We had a debate on tha= t MUST at the last IETF, but the spec was too far along to change. The work= around is to treat the token you are introspecting as the authentication. W= ith that workaround, the spec is quite usable for non-confidential clients,= even if resource servers were the primary target.

Google currently = runs an introspection endpoint of sorts for clients, named "tokeninfo&= quot;, and the latest version (v3) is close to the spec (coincidence - it&#= 39;s a good design pattern). Aimed mostly at debugging use-cases or if you = don't have a JWT decoding library handy.
On Tue, Nov 3, 2015 at 1:43 AM Justin Richer <jricher@mit.edu> wrote= :
Hi Michael,

Thanks for = the comments. First off, the text of an RFC is fixed and cannot be changed.= The spec can only be altered with a new document that obsoletes RFC7662, w= hich would have to go through the working group process again from the very= beginning.

Authentication is required but we=E2= =80=99re open to how it happens. The introspection spec is targeted at reso= urce servers, not clients, since a client can always just *use* the token i= n order to see if it=E2=80=99s valid or not. Why bother with the extra roun= d trip to check if the token is good before trying it, since trying it will= also tell you if the token=E2=80=99s good? The recovery process for a fail= ed token is the same in either state. We initially had this written for eit= her clients or protected resources, but that=E2=80=99s not how people were = using it and restricting its focus helped clarify the spec immensely.
=

ID tokens are a slightly different case as they=E2=80= =99re an assertion targeted at the client itself, but in those cases an ID = token is really meant to be self-contained as a JWT, and generally has a sh= ort validity period. If you=E2=80=99re looking to introspect an old ID toke= n to check an OIDC session status, then you might be better served implemen= ting one of the OIDC session spec components for that purpose.
Also, we didn=E2=80=99t mandate a specific authentication tech= nology. Most people are going to use either client authentication or a spec= ific OAuth token designed for this purpose. The latter of these is technica= lly available for public clients, but then you have the question of if you = want to check the status of *that* token too. Still, I think that for any c= lients (including public ones) the right thing to do is just use the token = and see if it works.=C2=A0

To the other comment, H= TTP POST is the only defined verb and we=E2=80=99re silent on the use of ot= her verbs. That said, many HTTP implementation frameworks don=E2=80=99t dif= ferentiate between verbs for requests and so a POST with body form paramete= rs and a GET with query parameters would come out the same. We don=E2=80=99= t outright prohibit this behavior, but it=E2=80=99s off-label and there are= security considerations for its use.

Hope this he= lps,
=C2=A0=E2=80=94 Justin

On Nov 2, 2015, at 3:17 AM, Michael Ciarlillo <<= a href=3D"mailto:michael.ciarlillo@gmail.com" target=3D"_blank">michael.cia= rlillo@gmail.com> wrote:

Hello all,
I have a couple of comments/issues with the RFC at https://tools.i= etf.org/html/rfc7662.

According to Section 2.1 (Intr= ospection Request) says that "To pre= vent token scanning attacks, the endpoint MUST also require=C2=A0some form of authorization to access this en= dpoint..."=C2=A0This might make sense for token introspection r= equests only coming from Resource Servers, but to many implementers it make= s sense to allow Clients access to the introspection endpoint since it woul= d serve the same purpose (token validity checking, particularly for refresh= tokens, but also for access tokens, or identity tokens in OpenID Connect, = or possibly other token types in UMA and other specs). Unfortunately, this = means that public clients should be accounted for in some way, as refresh t= okens don't have an explicit requirement in the OAuth 2.0 spec that the= y be issued only to Confidential Clients. As such, many implementers don= 9;t feel like the Introspection spec fits well for Client consumption becau= se of the "MUST" requirement on authentication, when public clien= ts won't have a Client Secret to authenticate with. Further, token scan= ning attacks would not be mitigated for authenticated callers (be they Reso= urce Servers or Clients).

An example of a real-wor= ld implementer discussion talking about this topic is one I had with=C2=A0K= =C3=A9vin Chalet:=C2=A0https://github.co= m/aspnet-contrib/AspNet.Security.OpenIdConnect.Server/pull/159

We are not the only ones who see this as a problem with th= e spec, and there do not seem to be many concrete reasons for this endpoint= ONLY being for Resource Servers themselves. Can some insight into why this= is the case? Can the MUST be changed to a SHOULD with the Security Conside= rations section expanded to talk about the issue? If not, is there another = spec or draft out there somewhere for OAuth token validity for which the in= tent is explicitly client consumption? Any and all feedback on this would b= e greatly appreciated as we develop the ASOS middleware project.
=
Another (small) comment on the spec: Section 2.1 (Introspect= ion Request) currently says that requests be HTTP POST method requests, how= ever Section 4 (Security Considerations) mentions Authorization Servers exp= licitly disallowing the GET method due to server logs. What is the requirem= ent here? POST with optional GET or explicitly only allowing POST requests?=

Sincerely,
Michael Ciarlillo
_______________________________________________
OAuth mailing list
OAuth@ietf.org
http= s://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

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

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

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

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

The web page for the mailing list is: 

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

Regards,

Phil

= --Apple-Mail=_F4E79D77-BE9B-4C59-8A8B-E7FF162C9C2B-- From nobody Tue Nov 3 06:15:46 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14B601A92F4 for ; Mon, 2 Nov 2015 16:24: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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RfHfZXxwPm9B for ; Mon, 2 Nov 2015 16:24:22 -0800 (PST) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::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 B69831A92F1 for ; Mon, 2 Nov 2015 16:24:22 -0800 (PST) Received: by pabfh17 with SMTP id fh17so1067812pab.0 for ; Mon, 02 Nov 2015 16:24:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:mime-version:to:cc:from:subject:date:in-reply-to :references:content-type; bh=MCe7IsAxfu9r1vVbxWXjB/HyK5ElBHzJX5fOTo3nsns=; b=bE5Kst7AftjQ9vV6pPklRYVfrOzkEfZ6mWhk6D8VFC8B4YyExqMj1Tb02z8y/V5bQ+ xOQRxqjNV55x5NDZ9kIjw9pUMf4WhK1Zc2Tkme+hC1MvBOnxEmdfkxXIXXcXN6dju15E d8DODwiatSRLJ0gKA18L5apCTc35ba+v9pFN4Er7RrIXHy0hoqUIQExRKsJAuFgYtRuu 5NMdDYFqkeQn2df65dpGd72N8zDO65/DgQzP+cpq2c2938sTsYTFHkGf9wdKhR5Ohzw4 Y3LrmCtNMJ6BByOTlVRErXRHtiMkscGLsdcS0BHEPynm9NA1RS5JOxFGZfE5C+WAx+cV EVPg== X-Received: by 10.66.192.106 with SMTP id hf10mr30547375pac.16.1446510262375; Mon, 02 Nov 2015 16:24:22 -0800 (PST) Received: from [192.168.1.105] (ip68-225-93-187.cl.ri.cox.net. [68.225.93.187]) by smtp.gmail.com with ESMTPSA id ix1sm26127599pbd.40.2015.11.02.16.24.20 (version=SSLv3 cipher=RC4-SHA bits=128/128); Mon, 02 Nov 2015 16:24:21 -0800 (PST) Message-ID: <5637feb5.611a450a.bf33d.4307@mx.google.com> MIME-Version: 1.0 To: William Denniss , Justin Richer From: Michael Ciarlillo Date: Mon, 2 Nov 2015 19:24:17 -0500 In-Reply-To: References: <6A84AF37-C6FC-41DD-99D6-32A8DDD7A18A@mit.edu> Content-Type: multipart/alternative; boundary="_284A694B-C6FA-4D04-86A4-A214D635F9A4_" Archived-At: X-Mailman-Approved-At: Tue, 03 Nov 2015 06:15:44 -0800 Cc: "" Subject: Re: [OAUTH-WG] OAuth 2.0 Introspection RFC Issues X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 00:24:26 -0000 --_284A694B-C6FA-4D04-86A4-A214D635F9A4_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Thanks for the feedback. I agree that the spec is not badly designed over all. I just think that the= MUST is a bit too restrictive, especially with how none of the OAuth grant= s requires authentication to begin with except when a client is Confidentia= l or when using Client Credential flow (for obvious reasons). I don't believe that simply using a token to determine its validity is a go= od course of action. There may very well be unintended side-effects (like t= he issuance of a new refresh/access token when using a refresh token at the= Token endpoint, or one-time use access tokens). One use case presented by = K=C3=A9vin Chalet is when a client might need to determine and what users i= t has been authorized access on behalf of and possibly remove those that ar= e no longer valid. Another might be something like determining if an initia= l one-time use access token for registration requests is still active and a= vailable to use for client registration. Not having available resources or libraries to validate JWTs or other token= s on the client was another use case mentioned in discussions we had. I'm g= lad others have had similar discussions for this scenario. That being said, the idea of using the token itself for authentication intr= igues me, though doesn't that inherently break the entire point of having t= he authentication be a MUST in the spec to begin with? How might an Authori= zation Server mitigate inherent security risks with this approach for any t= ype of tokens? -----Original Message----- From: "William Denniss" Sent: =E2=80=8E11/=E2=80=8E2/=E2=80=8E2015 6:58 PM To: "Justin Richer" ; "Michael Ciarlillo" Cc: "" Subject: Re: [OAUTH-WG] OAuth 2.0 Introspection RFC Issues We had a debate on that MUST at the last IETF, but the spec was too far alo= ng to change. The workaround is to treat the token you are introspecting as= the authentication. With that workaround, the spec is quite usable for non= -confidential clients, even if resource servers were the primary target. Google currently runs an introspection endpoint of sorts for clients, named= "tokeninfo", and the latest version (v3) is close to the spec (coincidence= - it's a good design pattern). Aimed mostly at debugging use-cases or if y= ou don't have a JWT decoding library handy.=20 On Tue, Nov 3, 2015 at 1:43 AM Justin Richer wrote: Hi Michael, Thanks for the comments. First off, the text of an RFC is fixed and cannot = be changed. The spec can only be altered with a new document that obsoletes= RFC7662, which would have to go through the working group process again fr= om the very beginning. Authentication is required but we=E2=80=99re open to how it happens. The in= trospection spec is targeted at resource servers, not clients, since a clie= nt can always just *use* the token in order to see if it=E2=80=99s valid or= not. Why bother with the extra round trip to check if the token is good be= fore trying it, since trying it will also tell you if the token=E2=80=99s g= ood? The recovery process for a failed token is the same in either state. W= e initially had this written for either clients or protected resources, but= that=E2=80=99s not how people were using it and restricting its focus help= ed clarify the spec immensely. ID tokens are a slightly different case as they=E2=80=99re an assertion tar= geted at the client itself, but in those cases an ID token is really meant = to be self-contained as a JWT, and generally has a short validity period. I= f you=E2=80=99re looking to introspect an old ID token to check an OIDC ses= sion status, then you might be better served implementing one of the OIDC s= ession spec components for that purpose. Also, we didn=E2=80=99t mandate a specific authentication technology. Most = people are going to use either client authentication or a specific OAuth to= ken designed for this purpose. The latter of these is technically available= for public clients, but then you have the question of if you want to check= the status of *that* token too. Still, I think that for any clients (inclu= ding public ones) the right thing to do is just use the token and see if it= works.=20 To the other comment, HTTP POST is the only defined verb and we=E2=80=99re = silent on the use of other verbs. That said, many HTTP implementation frame= works don=E2=80=99t differentiate between verbs for requests and so a POST = with body form parameters and a GET with query parameters would come out th= e same. We don=E2=80=99t outright prohibit this behavior, but it=E2=80=99s = off-label and there are security considerations for its use. Hope this helps, =E2=80=94 Justin On Nov 2, 2015, at 3:17 AM, Michael Ciarlillo = wrote: Hello all, I have a couple of comments/issues with the RFC at https://tools.ietf.org/h= tml/rfc7662. According to Section 2.1 (Introspection Request) says that "To prevent toke= n scanning attacks, the endpoint MUST also require some form of authorizati= on to access this endpoint..." This might make sense for token introspectio= n requests only coming from Resource Servers, but to many implementers it m= akes sense to allow Clients access to the introspection endpoint since it w= ould serve the same purpose (token validity checking, particularly for refr= esh tokens, but also for access tokens, or identity tokens in OpenID Connec= t, or possibly other token types in UMA and other specs). Unfortunately, th= is means that public clients should be accounted for in some way, as refres= h tokens don't have an explicit requirement in the OAuth 2.0 spec that they= be issued only to Confidential Clients. As such, many implementers don't f= eel like the Introspection spec fits well for Client consumption because of= the "MUST" requirement on authentication, when public clients won't have a= Client Secret to authenticate with. Further, token scanning attacks would = not be mitigated for authenticated callers (be they Resource Servers or Cli= ents). An example of a real-world implementer discussion talking about this topic = is one I had with K=C3=A9vin Chalet: https://github.com/aspnet-contrib/AspN= et.Security.OpenIdConnect.Server/pull/159 We are not the only ones who see this as a problem with the spec, and there= do not seem to be many concrete reasons for this endpoint ONLY being for R= esource Servers themselves. Can some insight into why this is the case? Can= the MUST be changed to a SHOULD with the Security Considerations section e= xpanded to talk about the issue? If not, is there another spec or draft out= there somewhere for OAuth token validity for which the intent is explicitl= y client consumption? Any and all feedback on this would be greatly appreci= ated as we develop the ASOS middleware project. Another (small) comment on the spec: Section 2.1 (Introspection Request) cu= rrently says that requests be HTTP POST method requests, however Section 4 = (Security Considerations) mentions Authorization Servers explicitly disallo= wing the GET method due to server logs. What is the requirement here? POST = with optional GET or explicitly only allowing POST requests? Sincerely, Michael Ciarlillo _______________________________________________ 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= --_284A694B-C6FA-4D04-86A4-A214D635F9A4_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
Thanks for the feedback.

I agree that the spec is = not badly designed over all. I just think that the MUST is a bit too restri= ctive, especially with how none of the OAuth grants requires authentication= to begin with except when a client is Confidential or when using Client Cr= edential flow (for obvious reasons).

I don't believe that simply usi= ng a token to determine its validity is a good course of action. There may = very well be unintended side-effects (like the issuance of a new refresh/ac= cess token when using a refresh token at the Token endpoint, or one-time us= e access tokens). One use case presented by K=C3=A9vin Chalet is when a cli= ent might need to determine and what users it has been authorized access on= behalf of and possibly remove those that are no longer valid. Another migh= t be something like determining if an initial one-time use access token for= registration requests is still active and available to use for client regi= stration.

Not having available resources or libraries to validate JW= Ts or other tokens on the client was another use case mentioned in discussi= ons we had. I'm glad others have had similar discussions for this scenario.=

That being said, the idea of using the token itself for authenticat= ion intrigues me, though doesn't that inherently break the entire point of = having the authentication be a MUST in the spec to begin with? How might an= Authorization Server mitigate inherent security risks with this approach f= or any type of tokens?
From: William Denniss
S= ent: =E2=80=8E11/=E2=80=8E2/=E2=80=8E2015 6:58 PM
To: Justin Richer; Michael Ciarlillo
Cc: <= span style=3D"font-family: Calibri,sans-serif; font-size: 11pt;"><oauth@ietf.org>
Subj= ect: Re: [OAUTH-WG] OAuth 2.0 Introspection RFC Issues

We= had a debate on that MUST at the last IETF, but the spec was too far along= to change. The workaround is to treat the token you are introspecting as t= he authentication. With that workaround, the spec is quite usable for non-c= onfidential clients, even if resource servers were the primary target.
<= br>Google currently runs an introspection endpoint of sorts for clients, na= med "tokeninfo", and the latest version (v3) is close to the spec (coincide= nce - it's a good design pattern). Aimed mostly at debugging use-cases or i= f you don't have a JWT decoding library handy.
On Tue, Nov 3, 2015 at 1:43 AM Justin Richer <jricher@mit.edu> wrote:
Hi Michael= ,

Thanks for the comments. First off, the text of an RFC= is fixed and cannot be changed. The spec can only be altered with a new do= cument that obsoletes RFC7662, which would have to go through the working g= roup process again from the very beginning.

Authen= tication is required but we=E2=80=99re open to how it happens. The introspe= ction spec is targeted at resource servers, not clients, since a client can= always just *use* the token in order to see if it=E2=80=99s valid or not. = Why bother with the extra round trip to check if the token is good before t= rying it, since trying it will also tell you if the token=E2=80=99s good? T= he recovery process for a failed token is the same in either state. We init= ially had this written for either clients or protected resources, but that= =E2=80=99s not how people were using it and restricting its focus helped cl= arify the spec immensely.

ID tokens are a slightly= different case as they=E2=80=99re an assertion targeted at the client itse= lf, but in those cases an ID token is really meant to be self-contained as = a JWT, and generally has a short validity period. If you=E2=80=99re looking= to introspect an old ID token to check an OIDC session status, then you mi= ght be better served implementing one of the OIDC session spec components f= or that purpose.

Also, we didn=E2=80=99t mandate a= specific authentication technology. Most people are going to use either cl= ient authentication or a specific OAuth token designed for this purpose. Th= e latter of these is technically available for public clients, but then you= have the question of if you want to check the status of *that* token too. = Still, I think that for any clients (including public ones) the right thing= to do is just use the token and see if it works. 

To the other comment, HTTP POST is the only defined verb and we=E2=80= =99re silent on the use of other verbs. That said, many HTTP implementation= frameworks don=E2=80=99t differentiate between verbs for requests and so a= POST with body form parameters and a GET with query parameters would come = out the same. We don=E2=80=99t outright prohibit this behavior, but it=E2= =80=99s off-label and there are security considerations for its use.
<= div>
Hope this helps,
 =E2=80=94 Justin
<= /div>

On Nov 2, 2015, at 3:17 AM, Michael Ciarlillo <michael.ciarlillo= @gmail.com> wrote:

Hello all,
I have a couple of comments/issues with the RFC at https://tools.ietf.or= g/html/rfc7662.

According to Section 2.1 (Introspect= ion Request) says that "To prevent toke= n scanning attacks, the endpoint MUST also require some form of authorization to access this endpoint= ..." This might make sense for token introspection requests onl= y coming from Resource Servers, but to many implementers it makes sense to = allow Clients access to the introspection endpoint since it would serve the= same purpose (token validity checking, particularly for refresh tokens, bu= t also for access tokens, or identity tokens in OpenID Connect, or possibly= other token types in UMA and other specs). Unfortunately, this means that = public clients should be accounted for in some way, as refresh tokens don't= have an explicit requirement in the OAuth 2.0 spec that they be issued onl= y to Confidential Clients. As such, many implementers don't feel like the I= ntrospection spec fits well for Client consumption because of the "MUST" re= quirement on authentication, when public clients won't have a Client Secret= to authenticate with. Further, token scanning attacks would not be mitigat= ed for authenticated callers (be they Resource Servers or Clients).

An example of a real-world implementer discussion talking= about this topic is one I had with K=C3=A9vin Chalet: https://github.com/aspnet-contrib/AspNet.Security.= OpenIdConnect.Server/pull/159

We are not the o= nly ones who see this as a problem with the spec, and there do not seem to = be many concrete reasons for this endpoint ONLY being for Resource Servers = themselves. Can some insight into why this is the case? Can the MUST be cha= nged to a SHOULD with the Security Considerations section expanded to talk = about the issue? If not, is there another spec or draft out there somewhere= for OAuth token validity for which the intent is explicitly client consump= tion? Any and all feedback on this would be greatly appreciated as we devel= op the ASOS middleware project.

Another (small) co= mment on the spec: Section 2.1 (Introspection Request) currently says that = requests be HTTP POST method requests, however Section 4 (Security Consider= ations) mentions Authorization Servers explicitly disallowing the GET metho= d due to server logs. What is the requirement here? POST with optional GET = or explicitly only allowing POST requests?

Sincere= ly,
Michael Ciarlillo
=0A= _______________________________________________
OAuth mailing list
OAuth@ietf.org
http= s://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
=0A= OAuth mailing list
=0A= OAuth@ietf.org
= =0A= https://www.ietf.org/mailman/listinfo/oauth
=0A=
=0A= = --_284A694B-C6FA-4D04-86A4-A214D635F9A4_-- From nobody Tue Nov 3 16:49:07 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 908451A700A for ; Tue, 3 Nov 2015 16:49:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J6fpUhx9HOHD for ; Tue, 3 Nov 2015 16:49:00 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 739E01A1A0B for ; Tue, 3 Nov 2015 16:48:59 -0800 (PST) Received: from [192.168.10.238] ([133.93.52.154]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MLi1v-1Zu3N64BCF-000qJa for ; Wed, 04 Nov 2015 01:48:57 +0100 To: "oauth@ietf.org" References: <5634946A.4020607@gmx.net> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <563955F3.6020907@gmx.net> Date: Wed, 4 Nov 2015 01:48:51 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <5634946A.4020607@gmx.net> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="kmd6krGcve7PqXHaOCIpE8MuDjXuQpcng" X-Provags-ID: V03:K0:XIcZu+3nQqAg89oJjvcwuZdDE5OOuuxgbhD1YGHetspUkGGGof5 +fVlvHYyq737g82BYwLoUpU0YEWHjF4nNHvH2LZs1P2IQ80d+qEen177iqD1VEmBRnlT0Qu 9bz3GOZgI+9JQXIE7Ip2/5lAfIgoz/m/fzOZ1lEqNnQM4qjBlbK/Gw86wF45/oNFJTGj1Jm /nJ7L3NQDC9knUU23U21Q== X-UI-Out-Filterresults: notjunk:1;V01:K0:32RP71yeIQA=:6BKOUEKf+xBK01l/g5tf18 0/d312FVMCzQCin7l8yxSg+/dX0RhA8AJerh8g6Hyn4E26LJEOEnuItc7LmiLc5y7QqQVlWqM cZUjq+qzRQOZHFnfg859BkTo55FZnT/3K45SzSWyxvsPxy6dSVBDXZDIDlsrFYEs4gaQ/cd/s 2SUNFRyC2XyXW2t/3fhaavfFYxui7npfpdb80VM2rztbw+1Dy3fNgBvRmd+lx+ImnJl4teAJS 7O3Ix5iM1vpPuE5ke8PR0m0Z9qJj6H1n40WUc4hbjYGzGRjyG5T/yQqHqwvB+DjClra7TSEA0 V06IQ82LgLk9JTg0Nk/mTOTVXcDhY0leX22aRFjsJshDmdU6wbtlAXRKFhpaiA5gJqm5p2J+R 4aOI5RmfPM+giIEFvven4FJI5gzHDRfoiQUpkf8YOuoeMryPSV85SZ6OPrVTq9CUFWgueSS8X 54gvDTToYYQ+akmFLNalX9sTTIgH5kejKQo7O70uEe2UG9ETrG+YomSjLj9I7KKljgrk8HmE/ NNnoOMzfh3qr5LoeGW0pjjztEDJwrI4Ifs+29oN6tTWif/4ju7EGFXr1E//fMNJgRuai/l2PV 7F/9dqakefyQ63XORYQoDqRjmLC3xeh/44KMZP2Edh/XHOfF+tpHQXIWadlJhsOKYEJ1RT9KD l7BPGBZQaDuLYJRBtrHMSucQW5dycA+qSVr4N6KV2GVWlE91hqOPEgmWiuQtgVtutrZ+KNv3E EUedwV2+D7fiGs20BYPcJ9gWSoY4t3e8KIJtbFQ4/1XUslYBY6ZuYCrRWgU= Archived-At: Subject: Re: [OAUTH-WG] Meeting Agenda X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2015 00:49:02 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --kmd6krGcve7PqXHaOCIpE8MuDjXuQpcng Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi all, in addition to the agenda I posted last week I am suggesting to talk about re-chartering of the working group. In that context we will hear various short talks about work we could/should be doing. Ciao Hannes On 10/31/2015 11:14 AM, Hannes Tschofenig wrote: > Please have a look at the meeting agenda for our OAuth meeting: > https://www.ietf.org/proceedings/94/agenda/agenda-94-oauth >=20 > ----- >=20 > IETF 93 OAuth WG Meeting Agenda >=20 > Thursday, November 5, 2015 (JST) > Room 301 > 15:20-17:20 Thursday Afternoon session II >=20 > - Status Update (Hannes) >=20 > - OAuth 2.0 JWT Authorization Request (Nat) > http://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/ >=20 > Document is currently in WGLC. >=20 > - Proof-of-Possession (TBD) > http://datatracker.ietf.org/doc/draft-ietf-oauth-proof-of-possession/ > http://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architecture/ > http://datatracker.ietf.org/doc/draft-ietf-oauth-pop-key-distribution/ >=20 > - Token Exchange (Mike) > http://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/ >=20 > - OAuth 2.0 for Native Apps > http://datatracker.ietf.org/doc/draft-wdenniss-oauth-native-apps/ >=20 >=20 > ------ >=20 > Let us know if you would like to make some additions or changes. >=20 > Ciao > Hannes & Derek >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 --kmd6krGcve7PqXHaOCIpE8MuDjXuQpcng Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJWOVX0AAoJEGhJURNOOiAt/DsH/0GvFec9Hkrq3+9KBdmQF6QK DMcAHIFwvB2uF2colX0C9XC2VSSSZ8ar93tj0uGcqtuwx426yizUpPEvaKtMlckU RC5bsIZvKJUZ7TFduNYhVUNNZ+IFlaaOQxdhP5c+gBmkb6MrioGjmhMSCpjRE63n xRwYGe4sRcg7JObb5y+OY91hiy1fLLmhnh0pOqGPrQHp+npLkxCiRy1KnDIaAkoF e3hQLJUBo5DQSVTLolzCpzcHzfTcgCpM1h/TDTmbQZXjHT5cERqRnYO2yhdpf65x r2V62rvShWJIzclpfIoczeeVwwkSiO7iga34r34oCnrpcBUgnt4fVgUYtZ9NvBw= =UBqb -----END PGP SIGNATURE----- --kmd6krGcve7PqXHaOCIpE8MuDjXuQpcng-- From nobody Tue Nov 3 16:54:23 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C79D11A86FF for ; Tue, 3 Nov 2015 16:54:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dwk-8LSVNpZW for ; Tue, 3 Nov 2015 16:54:20 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC3931A701D for ; Tue, 3 Nov 2015 16:54:19 -0800 (PST) Received: from [192.168.10.238] ([133.93.52.154]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MgHHO-1a8XGg24QA-00Niht for ; Wed, 04 Nov 2015 01:54:17 +0100 To: "oauth@ietf.org" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <5639572D.4060908@gmx.net> Date: Wed, 4 Nov 2015 01:54:05 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="5RAH7b6mguhIpD7xiBHhjRW7SIpuO9xwc" X-Provags-ID: V03:K0:S3WWnh8TJgonVXgWz+tLSHIM0KgXtrRzsEFPLW9Y1aSNdi3uZMd wdos3m3kcUuREc+fkWZ/bGBMAlcR8ytb8J4U7ScZc7Q/tEJQ+5PqiG7cMCJ/T8A5DzOjfV4 cChWO+8UH5mGMtWbPXXekjIxoUA/TQs8iBI/CiaAVGoN1N/jWiklmiPn2lW2mts4jYdmE+U AQU3LosLFCpQLkLIbX35A== X-UI-Out-Filterresults: notjunk:1;V01:K0:Tzt9Ssz+yKo=:Z9+TV11HEDvRKM9oX348hw f0kv/G+t/FllGfaayywUpS9o9zSMID8ImgqfrmzWoX8m3oqpEVJ+RCu4G82UNss3rgYsJHWjN I+qt2zC/kQY0s5vbI3q8QvY8eBpfWPNLYx2CbMig6EHpDZdEhxE1nFcwJU2WFCrUEXqpPIjcO 3u7jO79QVvy0CipOacQ1zbkICpyIDnyi3Z2ghMBzPC9CI7VgAjIJTdy6S0hNNmKNsc+DdEkA1 R/DCpTRBg4Rexhvnr6fNDS5a33DfsEQJSdxSILNTFrwFUXHDB0/JD2jLYo5zZ4xUpAr1D3qMt Pzj0Jqm+i6uVdEtsw1AgB7ZkOtprJBSw46yrNpbktSWkIWPomAJS5ZoQN79+gJquUwmJ0IcST Ah5X69ZQ8Dv36XRyh46a9FU8mG9ixLTY83+95z/5tay/VgvYO9rE8ES3kGX89WkoEfyMOyrqw KZuCq/BFIMBmMbGlEFdcJTT4Rhj3LvA5BG2wJg+L/Eja7QnUB8ASuxw4ZK+Qbiiqv5egCTFfX x50qjZkV0Ix9k+D1FM+PSfyU1Ljalaw4lKXIsbqePsoF1kcAzzcHuD0jsbUvaZNfvb1NNQMS9 O2NPxyZN+ZIF4oUV6Mh/068gUoSvkh1nImL8ESjTt7CDGPEI7ofKQeWwz6f49TO0Om1kdokIy jDLKKwCGaHDaXXJMUW/D/s8quLDpzxwuNIFi732J8ZwdDG7xjaafStnC6D6hR0yM5VhT/EJ/B 2kB2JmxY1vyYEomIV8Gm3pjtyLngaL5186Vl7hFY+gv9qW9viNOyNyd7pDE= Archived-At: Subject: [OAUTH-WG] draft-ietf-oauth-jwsreq-06 Review Reminder X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2015 00:54:21 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --5RAH7b6mguhIpD7xiBHhjRW7SIpuO9xwc Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, note that the WGLC for expires tomorrow, Thursday, November 5th, as announced here: http://www.ietf.org/mail-archive/web/oauth/current/msg15056.html Please review the document in time for the OAuth WG meeting. Ciao Hannes --5RAH7b6mguhIpD7xiBHhjRW7SIpuO9xwc Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJWOVcuAAoJEGhJURNOOiAtJ5sH/irx9+Z78hp8MIn896XXNr7W lX3H8SVi7FUcSob2dDu/Sib7+hZjEQIfc5XRAJk3MN8tsWyKZoNTsoy8j0TiR7xe fDcqxuG5AqYAc3/eYd7EDy8JbTnXZjLgy7jo8Y84j8chg99GtW4gndNrfYd0PpGP nVs/J8p8gJuUNYdaJD0OXZAR353HUFS5BHU8keL9WFii76YD01/J39zPC1mjPEOe moTRWrSjxkXhqXDtouGqHGoNYmHC0X/FxklZd9JpsqSiGEQtqtS6oEGf0oxy/E2m QkKOWmhzuefJ8AjFdJS3NP+4lS5gJL7CEa+KLiUeUCrCGv+lWw7YJjRnjQvguZE= =fUAG -----END PGP SIGNATURE----- --5RAH7b6mguhIpD7xiBHhjRW7SIpuO9xwc-- From nobody Tue Nov 3 17:03:56 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC0381A878A for ; Tue, 3 Nov 2015 17:03:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mvZg9-YY5mu3 for ; Tue, 3 Nov 2015 17:03:54 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0CD81A8779 for ; Tue, 3 Nov 2015 17:03:53 -0800 (PST) Received: from [192.168.10.238] ([133.93.52.154]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LcFTN-1aLBD92y3B-00jZ2h for ; Wed, 04 Nov 2015 02:03:51 +0100 To: "oauth@ietf.org" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <56395972.8020208@gmx.net> Date: Wed, 4 Nov 2015 02:03:46 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="uVAgMJcNP8VL0fmnc2ViRIiIqKKEuSGP6" X-Provags-ID: V03:K0:fAQz9QfUErv3xbcj/83nSFv5dWho+RICb8idCiuyhIY1x/BKLSN ObTDMj4XMhNWQsLDk3JVVn2rvmWqZ30m3njm8dwv43EyDw+zVir0zdurqvLfXnsZ/qx0O9r HH1t5D1pE+eW5w0LaVyL4fC3h1V2FKdYBpOcsGiirGeLJLISuB368kGpj1P+6rg5rjmU4sb wx0NHM2F4PXcPk91tQiwA== X-UI-Out-Filterresults: notjunk:1;V01:K0:9tHqLxhvHTY=:izilcLnU6XqKPdaSX7guX5 CDPI0aDUoOhvT7xbKVH5i+ak8PhB8476hn9zAFyNl19TW6gv0MZzCJbdTWxz2idI7TfQjPtKc WiXbzpgOv62zNSbPuKOCZeyH5QXILDx6Vxdw8P9YSLTk6JxYXMxaV1qRR21Q8vVNxOpwelgPQ EEp0E1Pi1NKEu6qWd6P6cBbxzKe94HxJ3t0s/QwCg1wLXt0XAJngzPwPoq/lgta92RS3HPJJA 9f7h/VCFXPtS4tSbFaSCfvn4VPS0IXQ6o28caexnILU27GU5jSJqLZgFqzj1rx6ho1Tybngbu vgXi2r27MIVoNrmc1P2ItiY9HZ4yHrQ/3GUq9U7G6c2XdIddPxRELK1kFks4iAJCnUyrmXw2B SQ+ZSugcXBJeFSBnxkOGH0xMcYv4nACx4F4aR2zIhM5t+45m9U4YZy9rfS4Pnv5YzljcRzje7 ts7i71Yemd/EhmVl0nrhL4+Q9leBNf10kkfATTnhD10F4LdLla9mGF5aK/fcKm9wBP3cfJh+O j8vcNNeRyI4JgnBGq7UBiJFxfSO8vYLL008d7msoe0xfAZhkPnNrieAI1phYbpOiva//QXcnV yqxndaSJcqBa9lmERPCCUXMeLeabp91J5Wu8WWdRMhMOGZfk4maSvSijEiTnHErYQ2THDVaxT +D80NmslJOr8LktZAd/962QfD7V5O4B7zW37Fp9cLX5Pnb7thOkn2Ao25q52ID9B7CxIN+OfD ALnmgmu1DF4+zDGNm1la4UN4sxC5PKI3z/MlaxIjHyftanMxeWDe6hKB6Cc= Archived-At: Subject: [OAUTH-WG] OAuth Status Update X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2015 01:03:56 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --uVAgMJcNP8VL0fmnc2ViRIiIqKKEuSGP6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable In time for the WG meeting Derek and I produced a short status update. - Errata Hannes and John to look into it and propose resolution to the list. https://www.rfc-editor.org/errata_search.php?rfc=3D6749 https://www.rfc-editor.org/errata_search.php?rfc=3D6819 This item is still pending. - Token Exchange Draft update pending that includes the discussion at the Prague IETF meeting. Will discuss the status during the OAuth meeting. - PoP Shepherd write-ups by Kepeng regarding PoP architecture and PoP JWT claims. PoP architecture made it to the IESG already and PoP JWT claims will follow soon. - Request by JWT ver 1.0 for OAuth 2.0 (Nat) Nat provided a draft update and we started WGLC, which will at the time of the WG meeting. - Charter Update Hannes to submit an updated charter based on the outcome of the discussions at the Yokohama IETF meting. --uVAgMJcNP8VL0fmnc2ViRIiIqKKEuSGP6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJWOVlzAAoJEGhJURNOOiAt8sUH/RfsoOyInLslJqyO0MgG7dV/ Z39zVZGkTr9LScg9c2eiy+bfVYngXUb9KUPfMIlfGDTLuw9sdfw5J20Iwex0GX16 7NPPOJnFLgnuDTRWsTm7zIjO7ehVKGEvQMGxQSk3IjiRx2tD7vltB4uOMeXoM2cM zkDCmm/TherSD27WqzhRHCTffzxuHvV0qRN11JC4Olu9XpNJGCGacq4Iay+52nBB u6HNAjccMb3ArEzbVaznnAxu0YGSJu4BjQKHDr8Kyr9B/8RMoNz3FWr/efmrFosx 7+7cghfqhbi9h3jrKqqGDWOBQm4C05DEKnj0neRxVoROiPBxzfa30bAWKFVUCgM= =HXF1 -----END PGP SIGNATURE----- --uVAgMJcNP8VL0fmnc2ViRIiIqKKEuSGP6-- From nobody Wed Nov 4 07:08:02 2015 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 BBAF11B3145; Wed, 4 Nov 2015 07:07:59 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.8.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151104150759.28936.3918.idtracker@ietfa.amsl.com> Date: Wed, 04 Nov 2015 07:07:59 -0800 Archived-At: Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-proof-of-possession-06.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2015 15:07:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol Working Group of the IETF. Title : Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs) Authors : Michael B. Jones John Bradley Hannes Tschofenig Filename : draft-ietf-oauth-proof-of-possession-06.txt Pages : 17 Date : 2015-11-04 Abstract: This specification defines how to express a declaration in a JSON Web Token (JWT) that the presenter of the JWT possesses a particular key and that the recipient can cryptographically confirm proof-of- possession of the key by the presenter. Being able to prove possession of a key is also sometimes described as the presenter being a holder-of-key. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-proof-of-possession/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-proof-of-possession-06 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 4 07:32:47 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B62841B31C9 for ; Wed, 4 Nov 2015 07:32:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gLZiTqr1ipec for ; Wed, 4 Nov 2015 07:32:37 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0141.outbound.protection.outlook.com [207.46.100.141]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA4B71B31CC for ; Wed, 4 Nov 2015 07:32:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=tyTR4JWrKpaTYBppgB2jIa6xOoHzbJpWw6Va1gFzsms=; b=WK5tbyZ3QmdVYPRW0PuQu7wd28/hBHDYiaBgJb1kfQXzm0rtha/J7DfhM+thJzQ+k53tmEETwaB4iRlnlBSqR7+p9vY4UjT64xXAX2j28o9sZVE38Ad84M+vJILrmlfgrmwa+uydDh+dHDy+eikcb05eNqBH6RVV1SxZJVxYBAA= Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB441.namprd03.prod.outlook.com (10.141.141.142) with Microsoft SMTP Server (TLS) id 15.1.312.18; Wed, 4 Nov 2015 15:32:35 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0318.003; Wed, 4 Nov 2015 15:32:35 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment Thread-Index: AdEXFgZ+9CN0zPNjS1iUuZ0RolJO4Q== Date: Wed, 4 Nov 2015 15:32:35 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [115.125.248.66] x-microsoft-exchange-diagnostics: 1; BY2PR03MB441; 5:yO1lQ+u5KSejtEnuHPThw1uCvkc1p4yHBDopTHMfHp4ZfSQWNdyXTJHbEPdanqnyfX4nHw2La6+D92evmWP/yHaX5zhMFxhc48wbGVHFc8M+5yPhHquLDfcH15rMmRx05Y3u4uIOji9gQbg11O7oNA==; 24:Nqnkpe/T+LRtvkPB+atyh4nwZAr+Isq4JlGz38T9bFBzx/Nycs4aFZgDG0P5WXTtUCtoSTkHFN/W6wvCHd61mtZ4C5NagR2x9E38Hdpfaio=; 20:OOmPY+vu0lDtRe7/FIZxEElx9HhaYA+ZOmaSPql2mFvyoKVQxwXe4l2eDBQSpOa3hwP/WWRJ35ZGtNFrpndtQg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB441; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425024)(601004)(2401047)(520078)(5005006)(8121501046)(3002001)(10201501046)(61426024)(61427024); SRVR:BY2PR03MB441; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB441; x-forefront-prvs: 0750463DC9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(209900001)(189002)(199003)(122556002)(40100003)(5004730100002)(5007970100001)(76576001)(230783001)(81156007)(10290500002)(15975445007)(102836002)(8990500004)(2900100001)(97736004)(229853001)(2351001)(10400500002)(5005710100001)(99286002)(106356001)(2501003)(105586002)(77096005)(74316001)(19609705001)(5002640100001)(87936001)(19625215002)(5001960100002)(110136002)(92566002)(19617315012)(189998001)(10090500001)(5003600100002)(86612001)(11100500001)(33656002)(5008740100001)(86362001)(66066001)(19580395003)(101416001)(19300405004)(54356999)(50986999)(99936001)(16236675004)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB441; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/related; boundary="_004_BY2PR03MB442F6667C49F8CF260D504DF52A0BY2PR03MB442namprd_"; type="multipart/alternative" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Nov 2015 15:32:35.6716 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB441 Archived-At: Subject: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2015 15:32:44 -0000 --_004_BY2PR03MB442F6667C49F8CF260D504DF52A0BY2PR03MB442namprd_ Content-Type: multipart/alternative; boundary="_000_BY2PR03MB442F6667C49F8CF260D504DF52A0BY2PR03MB442namprd_" --_000_BY2PR03MB442F6667C49F8CF260D504DF52A0BY2PR03MB442namprd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Proof-of-Possession Key Semantics for JWTs draft -06 addresses the remainin= g document shepherd comment - adding use case diagrams to the introduction. The updated specification is available at: * http://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-06 An HTML formatted version is also available at: * https://self-issued.info/docs/draft-ietf-oauth-proof-of-possession= -06.html -- Mike P.S. This note was also posted at http://self-issued.info/?p=3D1471 and as= @selfissued. --_000_BY2PR03MB442F6667C49F8CF260D504DF52A0BY2PR03MB442namprd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Proof-of-Possession Key Semantics for JWTs draft -06= addresses the remaining document shepherd comment – adding use case = diagrams to the introduction.

 

The updated specification is available at:

·        http://tools.ietf.org/html/draft-ietf-oa= uth-proof-of-possession-06

 

An HTML formatted version is also available at:=

·        https://self-issued.info/docs/dr= aft-ietf-oauth-proof-of-possession-06.html

 

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

 

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

--_000_BY2PR03MB442F6667C49F8CF260D504DF52A0BY2PR03MB442namprd_-- --_004_BY2PR03MB442F6667C49F8CF260D504DF52A0BY2PR03MB442namprd_ Content-Type: image/gif; name="image001.gif" Content-Description: image001.gif Content-Disposition: inline; filename="image001.gif"; size=334; creation-date="Wed, 04 Nov 2015 15:32:34 GMT"; modification-date="Wed, 04 Nov 2015 15:32:34 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhFAAQANUAAKqqqrGxse7u7vX19ezs7PLy8urq6vDw8O7u7vX19ejo6Ozs7Pf39/Dw8Obm 5vb29vT09Pr6+uzs7Pf39+rq6uTk5Pv7+729vd7e3tbW1vv7+8XFxfDw8PX19efn5+7u7vT09Pn5 +fv7+8TExObm5u/v7+vr6/j4+LKysvHx8fj4+LS0tM7OzsDAwOrq6vT09Pn5+enp6fLy8ujo6Pf3 97q6uvLy8sPDw+3t7f///wAAAAAAAAAAAAAAAAAAAAAAACH5BAEAADkALAAAAAAUABAAAAZrwJxw SCwaj8ikUklAAZ7QlUBZc4g0MBUjgWkpAZbIafIYQBCBb4j26LwKh0U6CdiCZKmGwDBHAsw2HAIf BDN9RwBwJQgSJgYkh0YAejgLLjEKFZFFFxkEFAYKHg4sI0oFN1BQGwNLrq+wsUEAOw== --_004_BY2PR03MB442F6667C49F8CF260D504DF52A0BY2PR03MB442namprd_-- From nobody Wed Nov 4 07:57:27 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 566091B3233 for ; Wed, 4 Nov 2015 07:57:26 -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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NRTjgoS7kRYC for ; Wed, 4 Nov 2015 07:57:24 -0800 (PST) Received: from out4133-130.mail.aliyun.com (out4133-130.mail.aliyun.com [42.120.133.130]) by ietfa.amsl.com (Postfix) with ESMTP id C6CB61B3235 for ; Wed, 4 Nov 2015 07:57:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1446652642; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=VsnZMiq91+2GH2jbUGMdA8y8swHbLQD40JNdqxtCU5A=; b=s4a67z8DMw+BsNoRcZxxkiAdYnhnyLLOA673R5xYcjM8fuecBI4PGEdr5c8SkCoeJQg1528+H/bop7ph4CV8BYK3nN0b00TaVJr0mQQbTIcIJjRfxlD7Dz2/L1OhP52ERgdybmUIbgONfhefyOL4h3VTB2brhp7krCxofLWnYjw= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R811e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e02c03284; MF=kepeng.lkp@alibaba-inc.com; NM=1; PH=DS; RN=2; SR=0; Received: from 10.22.36.162(mailfrom:kepeng.lkp@alibaba-inc.com ip:42.120.73.207) by smtp.aliyun-inc.com(127.0.0.1); Wed, 04 Nov 2015 23:57:17 +0800 User-Agent: Microsoft-MacOutlook/14.4.8.150116 Date: Wed, 04 Nov 2015 23:57:09 +0800 From: "Kepeng Li" To: Mike Jones , "oauth@ietf.org" Message-ID: Thread-Topic: Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment References: In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3529529837_18435525" Archived-At: Subject: Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2015 15:57:26 -0000 > ´ËÓʼþʹÓà MIME ¸ñʽ¡£ÓÉÓÚÓʼþÔĶÁ³ÌÐò²»ÄÜʶ±ð ´Ë¸ñʽ£¬Òò´Ë£¬¿ÉÄÜÎÞ·¨Ê¶±ð¸ÃÓʼþµÄ·Ö²¿»ò²¿·ÖÄÚÈÝ¡£ --B_3529529837_18435525 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Thank you Mike. The diagrams look good to me. Kind Regards Kepeng =E5=8F=91=E4=BB=B6=E4=BA=BA: Mike Jones =E6=97=A5=E6=9C=9F: Thursday, 5 November, 2015 12:32 am =E8=87=B3: "oauth@ietf.org" =E6=8A=84=E9=80=81: Li Kepeng =E4=B8=BB=E9=A2=98: Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment Proof-of-Possession Key Semantics for JWTs draft -06 addresses the remainin= g document shepherd comment =E2=80=93 adding use case diagrams to the introduction. =20 The updated specification is available at: =C2=B7 http://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-06 =20 An HTML formatted version is also available at: =C2=B7 =20 https://self-issued.info/docs/draft-ietf-oauth-proof-of-possession-06.html =20 -- Mike =20 P.S. This note was also posted at http://self-issued.info/?p=3D1471 and as @selfissued . --B_3529529837_18435525 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable
Thank you Mike.

=
The diagrams look good to me.

Kind Regar= ds
Kepeng

=E5=8F=91=E4=BB=B6=E4=BA= =BA: Mike Jones <Micha= el.Jones@microsoft.com>
=E6=97=A5=E6=9C=9F: Thursday, 5 November, 2015 12:32 am
=E8= =87=B3: "oauth@ietf.org" <oauth@ietf.org>
=E6=8A=84=E9=80=81: Li Kepeng <kepeng.lkp@alibaba-inc.com>
=E4=B8=BB= =E9=A2=98: Proof-of-Possession Key Semantics for JWTs spec addressing fina= l shepherd comment

Proof-of-Possession Key S= emantics for JWTs draft -06 addresses the remaining document shepherd commen= t – adding use case diagrams to the introduction.

 

The updated specifi= cation is available at:

=C2=B7        http://tools.ietf.org/html/draft-ietf-o= auth-proof-of-possession-06

&nbs= p;

An HTML formatted version is also available= at:

=C2=B7        https://self-issued.info/docs/d= raft-ietf-oauth-proof-of-possession-06.html

 

    &nb= sp;            &= nbsp;            = ;            &nb= sp;            &= nbsp;    -- Mike

&nbs= p;

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

 --B_3529529837_18435525-- From nobody Wed Nov 4 08:01:21 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74DCE1B3245 for ; Wed, 4 Nov 2015 08:01:20 -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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TjqOtx2mIU29 for ; Wed, 4 Nov 2015 08:01:19 -0800 (PST) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B175E1B323A for ; Wed, 4 Nov 2015 08:01:18 -0800 (PST) Received: by wicll6 with SMTP id ll6so34962703wic.1 for ; Wed, 04 Nov 2015 08:01:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=/xW+jDMi4M11XCeBijQ0GOQy0muS/FJpxYRRgWEsGdM=; b=EOLNJ7oZlMpjkDmkWicB6ASpKhNT75w+w/UefjK21fBOfQdFkQHcr/q2tqBpDaUWRB tbw+E2pkjybIavzgIgq/YfEOaCHUiCgtpW+dc9j5QNJU2f3BB/EbmdCF7vciX+ZiAMAz r6UcamTmcQi/xK490do76+IFmDN8VOvVcZ8XiYJ4LQLtv4uvslD1I9bkIQ8pCNdpmnu4 RDGvEzTrvo3sy/cDXEUrsJltRiCO95T5cXrpz6PIh78zyffcdOsiLOnQIxl9MznNJHPU 0XsN7B455eRME+lUmMlcrLDevxyNPmblrbDpdzB/P6BlPpvMSx6xW+GhkhkkfqcLMEtW LTFA== X-Received: by 10.194.77.174 with SMTP id t14mr2820889wjw.23.1446652877132; Wed, 04 Nov 2015 08:01:17 -0800 (PST) Received: from [10.36.226.98] ([80.169.137.63]) by smtp.googlemail.com with ESMTPSA id kd8sm2245357wjc.27.2015.11.04.08.01.16 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Nov 2015 08:01:16 -0800 (PST) To: oauth@ietf.org References: <6A84AF37-C6FC-41DD-99D6-32A8DDD7A18A@mit.edu> <5637feb5.611a450a.bf33d.4307@mx.google.com> From: Sergey Beryozkin Message-ID: <563A2BCC.6030801@gmail.com> Date: Wed, 4 Nov 2015 16:01:16 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [OAUTH-WG] Sharing a client_id: is it good or bad ? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2015 16:01:20 -0000 Hi All I'm having a discussion with my colleagues on the pros and cons of sharing a client_id. For example, say we have N number of public mobile applications (the same application package, an application instance on an individual phone), and one approach is for each of these applications to have the same client_id. I've been trying to analyze why it can be bad and the only thing I can come up with is that there will be no (easy) way to track which application instance actually accessed a given RS. Can someone please explain what the pros and cons are of having the same client_id shared between public client applications. And what about multiple confidential clients being set up with the same id/secret. I suspect it is a bad idea but what is main line why it is a bad idea, lets say it is all done in the protected network, no chance of the bad clients interfering... Thanks, Sergey From nobody Wed Nov 4 08:04:19 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18FE31B3257 for ; Wed, 4 Nov 2015 08:04:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NAUwiUVzfawa for ; Wed, 4 Nov 2015 08:04:14 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0115.outbound.protection.outlook.com [65.55.169.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B655B1B3252 for ; Wed, 4 Nov 2015 08:04:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=oV6kwZTn82zN3FYm7LP+gTmKzrDEmpKHzldTV2wpgrg=; b=HLEPcU9c7mPA2Ylu1S0r3NMoUK/OCXx6YgQkM+wD9jrzTiGajBa8ch1CD8Ltg+HNLJEJ+7BQf/iVqD/KtxOJ8xApdcMGjSNuDbcOtWGYFXXY3bgVdbnw1fw857hoOQOZTh+YCs9uzQLiOWRr+9LrCicUg0FOisbxAzlVClOzCWA= Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB441.namprd03.prod.outlook.com (10.141.141.142) with Microsoft SMTP Server (TLS) id 15.1.312.18; Wed, 4 Nov 2015 16:04:11 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0318.003; Wed, 4 Nov 2015 16:04:11 +0000 From: Mike Jones To: Kepeng Li , "oauth@ietf.org" Thread-Topic: Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment Thread-Index: AdEXFgZ+9CN0zPNjS1iUuZ0RolJO4QAA29mAAAA+4ZA= Date: Wed, 4 Nov 2015 16:04:11 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [115.125.248.66] x-microsoft-exchange-diagnostics: 1; BY2PR03MB441; 5:ldZwsW/vTZcf/jvQ383Ql8tU181sB+Eb6xMLgWjITh47P904RmFncQ+6ghT5mH3YetAquZkUrL7H7vc+Kvvg9iLOkyOw1EQvZytAfaPt0GeUa0eEw1BsVemgNBTH9U5pVbnCFzsl6jTJ9a0m+HWLSQ==; 24:czCB2NdukLkOUnSXDwZBweVU3dxiRuW8Q2Y5Zwyufdho6QCmewAm+8iTsR4qw0X2H10HWOSgUYVMnma8iKQZHFBKwPwHgzBkvMZCoipmK0M=; 20:1GzLjjNx2y2kHX8ijb1Sq8SAmu9yCEhG33uRRZTzrmpwQwmRMsuFDqZXwTBaYxRpUyVcMD6h5WX/OYCn8jTmqw== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB441; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425024)(601004)(2401047)(520078)(5005006)(8121501046)(3002001)(10201501046)(61426024)(61427024); SRVR:BY2PR03MB441; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB441; x-forefront-prvs: 0750463DC9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(209900001)(71364002)(52604005)(189002)(377454003)(199003)(122556002)(40100003)(5004730100002)(5007970100001)(76576001)(81156007)(230783001)(10290500002)(15975445007)(2950100001)(102836002)(8990500004)(2900100001)(97736004)(10400500002)(5005710100001)(5001770100001)(99286002)(106356001)(2501003)(105586002)(77096005)(74316001)(16297215004)(5002640100001)(19580405001)(87936001)(19625215002)(107886002)(5001960100002)(92566002)(5003600100002)(19617315012)(189998001)(10090500001)(86612001)(11100500001)(33656002)(5008740100001)(86362001)(66066001)(19580395003)(101416001)(54356999)(50986999)(76176999)(16236675004)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB441; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR03MB4423CADD0E9897848961B99F52A0BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Nov 2015 16:04:11.1333 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB441 Archived-At: Subject: Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2015 16:04:18 -0000 --_000_BY2PR03MB4423CADD0E9897848961B99F52A0BY2PR03MB442namprd_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Thanks for suggesting the diagrams, Kepeng. They make the document more und= erstandable. -- Mike ________________________________ From: Kepeng Li Sent: =FD11/=FD5/=FD2015 12:57 AM To: Mike Jones; oauth@ietf.org Subject: Re: Proof-of-Possession Key Semantics for JWTs spec addressing fin= al shepherd comment Thank you Mike. The diagrams look good to me. Kind Regards Kepeng ???: Mike Jones > ??: Thursday, 5 November, 2015 12:32 am ?: "oauth@ietf.org" > ??: Li Kepeng > ??: Proof-of-Possession Key Semantics for JWTs spec addressing final shephe= rd comment Proof-of-Possession Key Semantics for JWTs draft -06 addresses the remainin= g document shepherd comment =96 adding use case diagrams to the introductio= n. The updated specification is available at: =B7 http://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-= 06 An HTML formatted version is also available at: =B7 https://self-issued.info/docs/draft-ietf-oauth-proof-of-possessi= on-06.html -- Mike P.S. This note was also posted at http://self-issued.info/?p=3D1471 and as= @selfissued. --_000_BY2PR03MB4423CADD0E9897848961B99F52A0BY2PR03MB442namprd_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
Thanks for su= ggesting the diagrams, Kepeng. They make the document more understandable.<= br>
-- Mike
From: Kepeng Li
Sent: =FD11= /=FD5/=FD2015 12:57 AM
To: Mike Jones; oauth@ietf.org
Subject: Re: P= roof-of-Possession Key Semantics for JWTs spec addressing final shepherd co= mment

Thank you Mike.

The diagrams look good to me.

Kind Regards
Kepeng

发件人: Mike Jone= s <Michael.Jones@microsof= t.com>
日期: Thursday, 5 Novem= ber, 2015 12:32 am
至: "oauth@ietf.org" <oauth@ietf.org>
抄送: Li Kepeng <kepeng.lkp@alibaba-inc.com&g= t;
主题: Proof-of-Possessi= on Key Semantics for JWTs spec addressing final shepherd comment

Proof-of-Possession Key Semantics for JWTs draft -06= addresses the remaining document shepherd comment =96 adding use case diag= rams to the introduction.

 

The updated specification is available at:

=B7        http://tools.ietf.org/html/draft-ietf-oauth-proof-= of-possession-06

 

An HTML formatted version is also available at:

=B7        https://self-issued.info/docs/draft-ietf-o= auth-proof-of-possession-06.html

 

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

 

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

--_000_BY2PR03MB4423CADD0E9897848961B99F52A0BY2PR03MB442namprd_-- From nobody Wed Nov 4 08:05:07 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D8911B3277 for ; Wed, 4 Nov 2015 08:05:05 -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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IpSFLUMkpL7V for ; Wed, 4 Nov 2015 08:05:02 -0800 (PST) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::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 6697E1B3269 for ; Wed, 4 Nov 2015 08:04:47 -0800 (PST) Received: by pabfh17 with SMTP id fh17so56755870pab.0 for ; Wed, 04 Nov 2015 08:04:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=manicode_com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=n4WciXV6ZqUFH2TaeNHWhyP3T2Te4joFnjs8B3wtp4s=; b=JqdWTWw/q3KqtWpuK7Lcg4a15IYIjCPyQ9Ksmy6pZC3wD5SWzRnLMIKMm7Rdgwfnlo Lqk1Oox5GXIA+c8c/JQS1lSAPdFADDAAF7AJTfkp7YSEQ/NTHc8kEtAOnBc0RMv/YsR/ GJ62QRhDVHCzo/9itEnKZ4Reozzt10PZMupNXNJ0etMkI9DW34UXoZ1isKCiju/v02Xx Ep34CQpIzPF7tQ5oRixW3C64tGLqbMp8esyztJj61P3AKiNUOXFjHS4Rlklk0IH3VMod kfAA3cOwJO2wjsBbx2pwEe2V03SM8v8tM2h9qbHYCgJ/HXZNIAB6rHkibBSjRndY/4m7 YL3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=n4WciXV6ZqUFH2TaeNHWhyP3T2Te4joFnjs8B3wtp4s=; b=K/nIBceBJSgSWvjqXtGVZ148vMjTmd+f7Yr8GiaizfpJgVn/cQutKunFwesKo8BzSD CVRuBUR/rZw/Wya0Ma0gvHu+IqCY1ceRtvz/vYIKCihQ0XjqZ0RzSjUgvjvgBCbtGQBd b0XscBBeHhMIHKaht3f6k0nJXE4nJq+bw//Pu0LVBknzoFKcBpFGLYhLQ1ZdRrZDLK1t oI3jvKYVRIydh2J/GoLjklxD0xOc5DxaoEmLa5tVuaDCvvZp0EBP1I2gCu8qviu/BPOR IllxWD6jiGWVznPt4o24uCjhAIwWhcm3Dh4uebwfWVGonRSENNNxDR6DPS8D2ycpA+2I bpmg== X-Gm-Message-State: ALoCoQlGywAJIHkXITHNLd1LwDaC+6LYtr+5QXnMGRjUbvn4qjPYj3Sx2o15aGIUCXoEDW+oJD/z X-Received: by 10.66.160.194 with SMTP id xm2mr2802269pab.68.1446653086854; Wed, 04 Nov 2015 08:04:46 -0800 (PST) Received: from [10.177.18.88] ([166.170.46.233]) by smtp.gmail.com with ESMTPSA id ir5sm2881390pbc.13.2015.11.04.08.04.46 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Nov 2015 08:04:46 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Jim Manico X-Mailer: iPhone Mail (13B143) In-Reply-To: <563A2BCC.6030801@gmail.com> Date: Wed, 4 Nov 2015 08:04:44 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <2C769211-60B3-43A4-AFAA-849D46515DA5@manicode.com> References: <6A84AF37-C6FC-41DD-99D6-32A8DDD7A18A@mit.edu> <5637feb5.611a450a.bf33d.4307@mx.google.com> <563A2BCC.6030801@gmail.com> To: Sergey Beryozkin Archived-At: Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Sharing a client_id: is it good or bad ? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2015 16:05:05 -0000 > And what about multiple confidential clients being set up with the same id= /secret.=20 Bad idea. For security when you see one confidential client doing bad things= you will need to revoke it individually. If multiple confidential clients h= ave the same client secrets, thats no longer possible. -- Jim Manico @Manicode Secure Coding Education +1 (808) 652-3805 > On Nov 4, 2015, at 8:01 AM, Sergey Beryozkin wrote:= >=20 > Hi All >=20 > I'm having a discussion with my colleagues on the pros and cons of sharing= a client_id. >=20 > For example, say we have N number of public mobile applications (the same a= pplication package, an application instance on an individual phone), and one= approach is for each of these applications to have the same client_id. >=20 > I've been trying to analyze why it can be bad and the only thing I can com= e up with is that there will be no (easy) way to track which application ins= tance actually accessed a given RS. >=20 > Can someone please explain what the pros and cons are of having the same c= lient_id shared between public client applications. >=20 > And what about multiple confidential clients being set up with the same id= /secret. I suspect it is a bad idea but what is main line why it is a bad id= ea, lets say it is all done in the protected network, no chance of the bad c= lients interfering... >=20 >=20 >=20 > Thanks, Sergey >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Wed Nov 4 09:03:32 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 464281B36E9 for ; Wed, 4 Nov 2015 09:03:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, TVD_SPACE_RATIO=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RuMzySsjiF9n for ; Wed, 4 Nov 2015 09:03:30 -0800 (PST) Received: from mail-yk0-x22a.google.com (mail-yk0-x22a.google.com [IPv6:2607:f8b0:4002:c07::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 EFB2E1B36E5 for ; Wed, 4 Nov 2015 09:03:29 -0800 (PST) Received: by ykba4 with SMTP id a4so82879851ykb.3 for ; Wed, 04 Nov 2015 09:03:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=nwHWL+2e3/updIYZKv2kia62xuaAqp/IAmhboJXzeCw=; b=bR1UyoRwd/cEQWweLfTSZT+kzLEf0TH+Z9kBPt60Og0+FYPECxKWTU/1GXc7vcGRiW T51MQS6OKPKquJvC9zb1/4/beuJceAvILer818oklOigZVYnhOr8hcSTlCHpzt+fJ8lU geNBvg6CTnaw6jSrnxa+Q8kEw8Bbjj/euSYZB/KrelRMB95lsEmP6LgIM6sVh87DgmwE NDYafhMe2gdno0KopXMDLveNYKXvVo8wfh/YeQeUWa0VtY7NHySjqnVB76WahwsUXukx 6aAEpozaiaZPhqhDZjIgBQcpifARaXl3gskDksa0jXRJpyibOb4hwOjLwwhOHoXIVfYL 42RQ== MIME-Version: 1.0 X-Received: by 10.129.130.7 with SMTP id s7mr2002103ywf.29.1446656609167; Wed, 04 Nov 2015 09:03:29 -0800 (PST) Received: by 10.37.231.87 with HTTP; Wed, 4 Nov 2015 09:03:29 -0800 (PST) Received: by 10.37.231.87 with HTTP; Wed, 4 Nov 2015 09:03:29 -0800 (PST) Date: Wed, 4 Nov 2015 09:03:29 -0800 Message-ID: From: ronald comaling To: oauth@ietf.org Content-Type: multipart/alternative; boundary=94eb2c07c9144d6cf90523b9fd1d Archived-At: Subject: [OAUTH-WG] Re X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2015 17:03:31 -0000 --94eb2c07c9144d6cf90523b9fd1d Content-Type: text/plain; charset=UTF-8 Reply http://about.me/ronaldo_comaling --94eb2c07c9144d6cf90523b9fd1d Content-Type: text/html; charset=UTF-8

Reply

http://about.me/ronaldo_comaling

--94eb2c07c9144d6cf90523b9fd1d-- From nobody Wed Nov 4 14:20:49 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C09451B348E for ; Wed, 4 Nov 2015 14:20:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9RXfvmcYJiFX for ; Wed, 4 Nov 2015 14:20:47 -0800 (PST) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 045701A702B for ; Wed, 4 Nov 2015 14:20:46 -0800 (PST) Received: by pasz6 with SMTP id z6so67142150pas.2 for ; Wed, 04 Nov 2015 14:20:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb_com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=j9FEvTxtbVMU0RwLPgOwQZv8dQrpGe3EzsPcjWRtco4=; b=kDklXq9PT61pfPp3roEj3Qe4DCEorvlyRNpbm/XHTajV4veDTWE1LmQqns8PDYrjhi DRJd2jurbzQWYjy8ZHV33Ov+cYfKC/SrYj8W/rS/btN8eFefoFj00uAchRn4wqCx3Z19 gCevdkMtlXRjh1v2MBM+2xPyqpg7mEtGdgKtbTEtXAKS/zIHd+3aF8XiMfzBEjG9Ceyj NIaTyAMy2RONu5z7seXOA7yU4LeoqlwQGyx9WeYlG6zJvQ7i2awXRTiEXUD+Ha3lTe1T 3FnFxLuHTip0ZuKBBChCFEJf6QgdMS4GfwF0Dh/VPZbyJYyxgo7eh5gpsbmbluhXGRGS fPQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=j9FEvTxtbVMU0RwLPgOwQZv8dQrpGe3EzsPcjWRtco4=; b=TSIE7FYTWopYTwCshcP5ZAsjXQYtBLMCVB3qqZiFXDrxzrvz74Gn3XLBh0zkIgwGRs p0bzuJTGwM5Ot0+zKOy4Fnzm9sbCrr4WWchfX+9lMfavnkr5/J4K0OZM54xWlC9wOG5K 10hSJdTlyAO35ZJrINUQCpq3Cf2vy6HR98DDOalSNIrymhPEx4hmFc8fYcz+BdjsAe87 HpzVBAb29ufPkO74BLuIUZWj5aLNifTr6rO9fI1KU0Hevh9mOcuj/uTdLbBEbAO9TIxW hO0qwWTppYYjKoliOAk0ORkS51FE5HGN+htdBglV3DpCWrcwLiadZMb2sUMO1i/EqogI O2KA== X-Gm-Message-State: ALoCoQlNrVYbKcJW8/0UfUkA36N1sZXo7W1BUyE4bhGLpKBxyf758LvWBK1kxklQ5jJTlcluRDXS X-Received: by 10.68.132.71 with SMTP id os7mr4927588pbb.125.1446675646430; Wed, 04 Nov 2015 14:20:46 -0800 (PST) Received: from t20010c400000308021f8199b7e9235ac.v6.meeting.ietf94.jp (t20010c400000308021f8199b7e9235ac.v6.meeting.ietf94.jp. [2001:c40:0:3080:21f8:199b:7e92:35ac]) by smtp.gmail.com with ESMTPSA id ou3sm3920293pbb.44.2015.11.04.14.20.45 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Nov 2015 14:20:45 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: John Bradley In-Reply-To: <563A2BCC.6030801@gmail.com> Date: Thu, 5 Nov 2015 07:20:42 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <77B2A3DD-3C0F-49EB-AD7F-9C4DAA6542AE@ve7jtb.com> References: <6A84AF37-C6FC-41DD-99D6-32A8DDD7A18A@mit.edu> <5637feb5.611a450a.bf33d.4307@mx.google.com> <563A2BCC.6030801@gmail.com> To: Sergey Beryozkin X-Mailer: Apple Mail (2.2104) Archived-At: Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Sharing a client_id: is it good or bad ? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2015 22:20:48 -0000 For a native app you can have one clientID and no secret (same as having = one secret for all of them) or you can use dynamic client registration = to give each one a separate client_id and secret. The middle ground is to use PKCE and no client secret. =20 The client generates a pkce challenge in the authorization request and = then presents the verifier. You can then use that verifier to place a = identifier for that app instance in the refresh/access tokens. That = would allow the RS to differentiate between two clients with the same = user on different devices. =20 That gets you more or less equivalent security, but binds the client = instance to a user/device as part of the authorization flow, rather = than by creating separate client_id for each instance and managing that. It is up to more of a deployer preference on what way to go. =20 I prefer the PKCE route personally, that requires a real user to be = involved in the flow before the AS needs to store state. In open = dynamic client registration you can face a denial of service attack by = creating unlimited clients, that is harder to manage. =20 One thing that will be coming up at the WG meeting today is the = possibility of extending PKCE verification to refresh tokens as well as = there current use with code. That would move the PKCE and client = registration security even closer together. John B. > On Nov 5, 2015, at 1:01 AM, Sergey Beryozkin = wrote: >=20 > Hi All >=20 > I'm having a discussion with my colleagues on the pros and cons of = sharing a client_id. >=20 > For example, say we have N number of public mobile applications (the = same application package, an application instance on an individual = phone), and one approach is for each of these applications to have the = same client_id. >=20 > I've been trying to analyze why it can be bad and the only thing I can = come up with is that there will be no (easy) way to track which = application instance actually accessed a given RS. >=20 > Can someone please explain what the pros and cons are of having the = same client_id shared between public client applications. >=20 > And what about multiple confidential clients being set up with the = same id/secret. I suspect it is a bad idea but what is main line why it = is a bad idea, lets say it is all done in the protected network, no = chance of the bad clients interfering... >=20 >=20 >=20 > Thanks, Sergey >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Wed Nov 4 14:48:23 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FC081B356F for ; Wed, 4 Nov 2015 14:48:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oVgWEXpTBz4T for ; Wed, 4 Nov 2015 14:48:20 -0800 (PST) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C8BA1B3566 for ; Wed, 4 Nov 2015 14:48:20 -0800 (PST) Received: by igbdj2 with SMTP id dj2so46516435igb.1 for ; Wed, 04 Nov 2015 14:48:19 -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:content-type; bh=qaFhZPX5HJWNEg5lqetUHscJENkW6X6Dhpmr18DHXe0=; b=bz9GbfuzucLsCz+HFIQ+U3eO+GI0BbEvAXgdWrTO6xg662igds/D3UyjDAY8cdndYy VT6dXzPbwQqjpLf3DACTgYsQi1QQsB/rbpC9SEpgQVjnHWYNb/W04TYof9hN1ty+RkFP iCXh18GD2wfZZ6TJKXmiZS7IOYqORnimkcaVU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=qaFhZPX5HJWNEg5lqetUHscJENkW6X6Dhpmr18DHXe0=; b=e2NhqBxgKJdPv7fH1ZqwXcAsfFrEXxK+DAvr8qnFR+WL+bvRSvSRvejlJxSnXBPjzJ TEwQBWlzdpYEdxLIMKMWWbbqSidMan6yfUTxqkCc28ySjE0VL7QE/xY35Avh2jKMpOe/ Uh19NNPP6WPIUtka+VEa0F6iYIX3rs3UNjZjOPpx4AVhMS6F6ldm8YEuqfibSqClLmNc R3h2ALiwSiShsDauO+olqBxBooZEXFuqPJyH8zZLLBMGAuHLbb+taYP2UoEfLbH2oHJB Zk3i9/T1SEZ92T9sf6Hs77Io1dD3qnSisRUNpB+baASgamrdj41UqODFoJsybR8IjthJ R99w== X-Gm-Message-State: ALoCoQlNdaJWjOuBU7qfQpBgneLRUxyrrUuEhYjbiDqe4TJvLAFtHUYvZ4tDVIYFW1GRLWPDvZw6 X-Received: by 10.50.47.70 with SMTP id b6mr6113366ign.57.1446677299782; Wed, 04 Nov 2015 14:48:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.117.132 with HTTP; Wed, 4 Nov 2015 14:47:50 -0800 (PST) In-Reply-To: References: From: Brian Campbell Date: Wed, 4 Nov 2015 15:47:50 -0700 Message-ID: To: Mike Jones Content-Type: multipart/alternative; boundary=089e0149bc2c8f2eec0523bece6b Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2015 22:48:22 -0000 --089e0149bc2c8f2eec0523bece6b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 for the diagrams making the document more understandable. One little nit/question, step 1 in both Symmetric and Asymmetric keys shows the Presenter sending the key to the Issuer. It's possible, however, for the key to be sent the other way. Presenter sending it to the Issuer is probably preferred for asymmetric, especially if the client can secure the private keys in hardware. But I don't know if one way or the other is clearly better for symmetric case and PoP key distribution currently has it the other way . Should the intro text somehow mention the possibility that the Issuer could create the key and send it to the Presenter? I know it's only the introduction but it was just something that jumped out at me. On Wed, Nov 4, 2015 at 9:04 AM, Mike Jones wrote: > Thanks for suggesting the diagrams, Kepeng. They make the document more > understandable. > > -- Mike > ------------------------------ > From: Kepeng Li > Sent: =E2=80=8E11/=E2=80=8E5/=E2=80=8E2015 12:57 AM > To: Mike Jones ; oauth@ietf.org > Subject: Re: Proof-of-Possession Key Semantics for JWTs spec addressing > final shepherd comment > > Thank you Mike. > > The diagrams look good to me. > > Kind Regards > Kepeng > > =E5=8F=91=E4=BB=B6=E4=BA=BA: Mike Jones > =E6=97=A5=E6=9C=9F: Thursday, 5 November, 2015 12:32 am > =E8=87=B3: "oauth@ietf.org" > =E6=8A=84=E9=80=81: Li Kepeng > =E4=B8=BB=E9=A2=98: Proof-of-Possession Key Semantics for JWTs spec addre= ssing final > shepherd comment > > Proof-of-Possession Key Semantics for JWTs draft -06 addresses the > remaining document shepherd comment =E2=80=93 adding use case diagrams to= the > introduction. > > > > The updated specification is available at: > > =C2=B7 > http://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-06 > > > > An HTML formatted version is also available at: > > =C2=B7 > https://self-issued.info/docs/draft-ietf-oauth-proof-of-possession-06.htm= l > > > > -- Mike > > > > P.S. This note was also posted at http://self-issued.info/?p=3D1471 and = as > @selfissued . > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --089e0149bc2c8f2eec0523bece6b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1 for the diagrams making the document more und= erstandable.

One little nit/question, step 1 in both Symmetric= and Asymmetric keys shows the Presenter sending the key to the Issuer. It&= #39;s possible, however, for the key to be sent the other way. Presenter se= nding it to the Issuer is probably preferred for asymmetric, especially if = the client can secure the private keys in hardware. But I don't know if= one way or the other is clearly better for symmetric case and PoP key distribution currently has it the other way. Should the i= ntro text somehow mention the possibility that the Issuer could create the = key and send it to the Presenter?

I know it's only the int= roduction but it was just something that jumped out at me. =C2=A0
=



On Wed, Nov 4, 2015 a= t 9:04 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:
Thanks for sug= gesting the diagrams, Kepeng. They make the document more understandable.
-- Mike
From: Kepeng Li
Sent: =E2=80= =8E11/=E2=80=8E5/=E2=80=8E2015 12:57 AM
To: Mike Jones; oauth@ietf.org
Subject: Re: Pr= oof-of-Possession Key Semantics for JWTs spec addressing final shepherd com= ment

Thank you Mike.

The diagrams look good to me.

Kind Regards
Kepeng

=E5=8F=91=E4=BB=B6=E4=BA=BA: Mike J= ones <M= ichael.Jones@microsoft.com>
=E6=97=A5=E6=9C=9F: Thursday, 5 Nov= ember, 2015 12:32 am
=E8=87=B3: "oauth@ietf.org" <oauth@ietf.org>
=E6=8A=84=E9=80=81: Li Kepeng <<= a href=3D"mailto:kepeng.lkp@alibaba-inc.com" target=3D"_blank">kepeng.lkp@a= libaba-inc.com>
=E4=B8=BB=E9=A2=98: Proof-of-Posses= sion Key Semantics for JWTs spec addressing final shepherd comment

Proof-of-Possession Key Semantics for JWTs draft -06= addresses the remaining document shepherd comment =E2=80=93 adding use cas= e diagrams to the introduction.

=C2=A0

The updated specification is available at:

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 http://tools.ietf.org/html/draft= -ietf-oauth-proof-of-possession-06

=C2=A0

An HTML formatted version is also available at:

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 https://self-issued.info= /docs/draft-ietf-oauth-proof-of-possession-06.html

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=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 note was also posted at http://self-issued.info/?p=3D1471 and as @selfissued.


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


--089e0149bc2c8f2eec0523bece6b-- From nobody Wed Nov 4 14:51:35 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57A5A1B35A5 for ; Wed, 4 Nov 2015 14:51:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gq0EKfFMbzbx for ; Wed, 4 Nov 2015 14:51:24 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0121.outbound.protection.outlook.com [207.46.100.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDC991B35D2 for ; Wed, 4 Nov 2015 14:51:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=AKo1VMYxnP5/1eU2KupR9D6i1hN/EQT8+CjMtH1B+xs=; b=Xf/63364MvGfkapJoIEfkqVkUPysrvzuPhVBQ/bBZAQPN7KQgJ45A+PKZHS9fRDhGzv7XywrP22xm9Yc1/sKkW9/ulDnKa0nTim16jfLNlj2Kgeo94EmNx6EoIwX+Julr0nOhzRnlFD03caiV8zXoUE9CbZZm/dv0GSogqhklvA= Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB443.namprd03.prod.outlook.com (10.141.141.152) with Microsoft SMTP Server (TLS) id 15.1.318.15; Wed, 4 Nov 2015 22:51:22 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0318.003; Wed, 4 Nov 2015 22:51:22 +0000 From: Mike Jones To: Brian Campbell Thread-Topic: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment Thread-Index: AdEXFgZ+9CN0zPNjS1iUuZ0RolJO4QAA29mAAAA+4ZAADhjrAAAADBnA Date: Wed, 4 Nov 2015 22:51:22 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [115.125.248.66] x-microsoft-exchange-diagnostics: 1; BY2PR03MB443; 5:87yypKnPiJ2v8Q+Yoq0V+wPNMyosQqMqDL91e2x8xZfb0r97+TU72nLAPF7cG+Il4DjASDpxUhWIz01NaP4awah/BaGZ9nIHpkVzIV2KhpQT635SJ2guqHMY7X5h9e7jHodgIVRWym21WKnWe65CGA==; 24:EKTVvCrV7WiTx34lNXJtIpFi7xY3GJYuWXY5BNSpK9w1yriGNVXMRCLVKDyhxezLF2VTwfWE9sj/qPo9N6l697HXBeXJ9uCwWeO8VvKiGaw=; 20:5TRblubTX+vGlt/KdgPVIrZoqH1nUlDOmYmsRaFfuTRMnRisH2Qnq7G+Wrxbua3j7LxPh58VxWD19F4aHkyWHQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB443; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425024)(601004)(2401047)(5005006)(8121501046)(520078)(3002001)(10201501046)(61426024)(61427024); SRVR:BY2PR03MB443; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB443; x-forefront-prvs: 0750463DC9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(209900001)(199003)(377454003)(189002)(24454002)(51914003)(71364002)(52604005)(93886004)(102836002)(5008740100001)(19609705001)(19625215002)(87936001)(230783001)(122556002)(5004730100002)(77096005)(5007970100001)(101416001)(2900100001)(2950100001)(11100500001)(40100003)(15975445007)(66066001)(76576001)(19300405004)(19580395003)(19580405001)(74316001)(19617315012)(86362001)(33656002)(50986999)(106356001)(54356999)(76176999)(105586002)(81156007)(86612001)(97736004)(99286002)(5001960100002)(5001920100001)(5002640100001)(5005710100001)(10400500002)(10290500002)(110136002)(8990500004)(10090500001)(16236675004)(189998001)(5003600100002)(92566002)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB443; H:BY2PR03MB442.namprd03.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:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR03MB44262EA4616E08287A91DB1F52A0BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Nov 2015 22:51:22.0606 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB443 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2015 22:51:30 -0000 --_000_BY2PR03MB44262EA4616E08287A91DB1F52A0BY2PR03MB442namprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIGZvciB0aGUgZGV0YWlsZWQgcmVhZCwgQnJpYW4uICBZb3XigJlyZSByaWdodCB0aGF0 IGluIHRoZSBzeW1tZXRyaWMgY2FzZSwgZWl0aGVyIHRoZSBpc3N1ZXIgb3IgdGhlIHByZXNlbnRl ciBjYW4gY3JlYXRlIHRoZSBzeW1tZXRyaWMgUG9QIGtleSBhbmQgc2hhcmUgaXQgd2l0aCB0aGUg b3RoZXIgcGFydHksIHNpbmNlIHRoZSBlZmZlY3QgaXMgZXF1aXZhbGVudC4gIEkgc3VzcGVjdCB0 aGF0IGJvdGggdGhlIGtleSBkaXN0cmlidXRpb24gZHJhZnQgYW5kIHRoaXMgZHJhZnQgc2hvdWxk IGJlIHVwZGF0ZWQgd2l0aCBhIHNlbnRlbmNlIG9yIHR3byBzYXlpbmcgdGhhdCBlaXRoZXIgYXBw cm9hY2ggY2FuIGJlIHRha2VuLiAgRG8gb3RoZXJzIGNvbmN1cj8NCg0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpG cm9tOiBCcmlhbiBDYW1wYmVsbCBbbWFpbHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tXQ0K U2VudDogVGh1cnNkYXksIE5vdmVtYmVyIDA1LCAyMDE1IDc6NDggQU0NClRvOiBNaWtlIEpvbmVz DQpDYzogS2VwZW5nIExpOyBvYXV0aEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10g UHJvb2Ytb2YtUG9zc2Vzc2lvbiBLZXkgU2VtYW50aWNzIGZvciBKV1RzIHNwZWMgYWRkcmVzc2lu ZyBmaW5hbCBzaGVwaGVyZCBjb21tZW50DQoNCisxIGZvciB0aGUgZGlhZ3JhbXMgbWFraW5nIHRo ZSBkb2N1bWVudCBtb3JlIHVuZGVyc3RhbmRhYmxlLg0KT25lIGxpdHRsZSBuaXQvcXVlc3Rpb24s IHN0ZXAgMSBpbiBib3RoIFN5bW1ldHJpYyBhbmQgQXN5bW1ldHJpYyBrZXlzIHNob3dzIHRoZSBQ cmVzZW50ZXIgc2VuZGluZyB0aGUga2V5IHRvIHRoZSBJc3N1ZXIuIEl0J3MgcG9zc2libGUsIGhv d2V2ZXIsIGZvciB0aGUga2V5IHRvIGJlIHNlbnQgdGhlIG90aGVyIHdheS4gUHJlc2VudGVyIHNl bmRpbmcgaXQgdG8gdGhlIElzc3VlciBpcyBwcm9iYWJseSBwcmVmZXJyZWQgZm9yIGFzeW1tZXRy aWMsIGVzcGVjaWFsbHkgaWYgdGhlIGNsaWVudCBjYW4gc2VjdXJlIHRoZSBwcml2YXRlIGtleXMg aW4gaGFyZHdhcmUuIEJ1dCBJIGRvbid0IGtub3cgaWYgb25lIHdheSBvciB0aGUgb3RoZXIgaXMg Y2xlYXJseSBiZXR0ZXIgZm9yIHN5bW1ldHJpYyBjYXNlIGFuZCBQb1Aga2V5IGRpc3RyaWJ1dGlv biBjdXJyZW50bHkgaGFzIGl0IHRoZSBvdGhlciB3YXk8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWlldGYtb2F1dGgtcG9wLWtleS1kaXN0cmlidXRpb24tMDIjc2VjdGlvbi00LjI+ LiBTaG91bGQgdGhlIGludHJvIHRleHQgc29tZWhvdyBtZW50aW9uIHRoZSBwb3NzaWJpbGl0eSB0 aGF0IHRoZSBJc3N1ZXIgY291bGQgY3JlYXRlIHRoZSBrZXkgYW5kIHNlbmQgaXQgdG8gdGhlIFBy ZXNlbnRlcj8NCkkga25vdyBpdCdzIG9ubHkgdGhlIGludHJvZHVjdGlvbiBidXQgaXQgd2FzIGp1 c3Qgc29tZXRoaW5nIHRoYXQganVtcGVkIG91dCBhdCBtZS4NCg0KDQpPbiBXZWQsIE5vdiA0LCAy MDE1IGF0IDk6MDQgQU0sIE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTxt YWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPj4gd3JvdGU6DQpUaGFua3MgZm9yIHN1 Z2dlc3RpbmcgdGhlIGRpYWdyYW1zLCBLZXBlbmcuIFRoZXkgbWFrZSB0aGUgZG9jdW1lbnQgbW9y ZSB1bmRlcnN0YW5kYWJsZS4NCg0KLS0gTWlrZQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCkZyb206IEtlcGVuZyBMaTxtYWlsdG86a2VwZW5nLmxrcEBhbGliYWJhLWluYy5jb20+ DQpTZW50OiDigI4xMS/igI41L+KAjjIwMTUgMTI6NTcgQU0NClRvOiBNaWtlIEpvbmVzPG1haWx0 bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+OyBvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1 dGhAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogUHJvb2Ytb2YtUG9zc2Vzc2lvbiBLZXkgU2VtYW50 aWNzIGZvciBKV1RzIHNwZWMgYWRkcmVzc2luZyBmaW5hbCBzaGVwaGVyZCBjb21tZW50DQpUaGFu ayB5b3UgTWlrZS4NCg0KVGhlIGRpYWdyYW1zIGxvb2sgZ29vZCB0byBtZS4NCg0KS2luZCBSZWdh cmRzDQpLZXBlbmcNCg0K5Y+R5Lu25Lq6OiBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jv c29mdC5jb208bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4+DQrml6XmnJ86IFRo dXJzZGF5LCA1IE5vdmVtYmVyLCAyMDE1IDEyOjMyIGFtDQroh7M6ICJvYXV0aEBpZXRmLm9yZzxt YWlsdG86b2F1dGhAaWV0Zi5vcmc+IiA8b2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYu b3JnPj4NCuaKhOmAgTogTGkgS2VwZW5nIDxrZXBlbmcubGtwQGFsaWJhYmEtaW5jLmNvbTxtYWls dG86a2VwZW5nLmxrcEBhbGliYWJhLWluYy5jb20+Pg0K5Li76aKYOiBQcm9vZi1vZi1Qb3NzZXNz aW9uIEtleSBTZW1hbnRpY3MgZm9yIEpXVHMgc3BlYyBhZGRyZXNzaW5nIGZpbmFsIHNoZXBoZXJk IGNvbW1lbnQNCg0KUHJvb2Ytb2YtUG9zc2Vzc2lvbiBLZXkgU2VtYW50aWNzIGZvciBKV1RzIGRy YWZ0IC0wNiBhZGRyZXNzZXMgdGhlIHJlbWFpbmluZyBkb2N1bWVudCBzaGVwaGVyZCBjb21tZW50 IOKAkyBhZGRpbmcgdXNlIGNhc2UgZGlhZ3JhbXMgdG8gdGhlIGludHJvZHVjdGlvbi4NCg0KVGhl IHVwZGF0ZWQgc3BlY2lmaWNhdGlvbiBpcyBhdmFpbGFibGUgYXQ6DQoNCsK3ICAgICAgICBodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLXByb29mLW9mLXBvc3Nlc3Np b24tMDYNCg0KQW4gSFRNTCBmb3JtYXR0ZWQgdmVyc2lvbiBpcyBhbHNvIGF2YWlsYWJsZSBhdDoN Cg0KwrcgICAgICAgIGh0dHBzOi8vc2VsZi1pc3N1ZWQuaW5mby9kb2NzL2RyYWZ0LWlldGYtb2F1 dGgtcHJvb2Ytb2YtcG9zc2Vzc2lvbi0wNi5odG1sDQoNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KUC5TLiAgVGhp cyBub3RlIHdhcyBhbHNvIHBvc3RlZCBhdCBodHRwOi8vc2VsZi1pc3N1ZWQuaW5mby8/cD0xNDcx IGFuZCBhcyBAc2VsZmlzc3VlZDxodHRwczovL3R3aXR0ZXIuY29tL3NlbGZpc3N1ZWQ+Lg0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFp bGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg== --_000_BY2PR03MB44262EA4616E08287A91DB1F52A0BY2PR03MB442namprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDE0IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjwhLS1baWYgIW1zb10+ PHN0eWxlPnZcOioge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCm9cOioge2JlaGF2aW9y OnVybCgjZGVmYXVsdCNWTUwpO30NCndcOioge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30N Ci5zaGFwZSB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KPC9zdHlsZT48IVtlbmRpZl0t LT48c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250 LWZhbWlseTpTaW1TdW47DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OlNpbVN1bjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAx O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJc QFNpbVN1biI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1h cmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNv QWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJz YW5zLXNlcmlmIjt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFs bG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0K c3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMDAyMDYwO30NCi5Nc29D aHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4g MTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rp b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0K PC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91 dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpz aGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVT IiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzAwMjA2MCI+VGhhbmtzIGZvciB0aGUgZGV0YWlsZWQgcmVhZCwgQnJpYW4uJm5ic3A7IFlvdeKA mXJlIHJpZ2h0IHRoYXQgaW4gdGhlIHN5bW1ldHJpYyBjYXNlLCBlaXRoZXIgdGhlIGlzc3VlciBv ciB0aGUgcHJlc2VudGVyIGNhbiBjcmVhdGUgdGhlIHN5bW1ldHJpYyBQb1Aga2V5IGFuZCBzaGFy ZQ0KIGl0IHdpdGggdGhlIG90aGVyIHBhcnR5LCBzaW5jZSB0aGUgZWZmZWN0IGlzIGVxdWl2YWxl bnQuJm5ic3A7IEkgc3VzcGVjdCB0aGF0IGJvdGggdGhlIGtleSBkaXN0cmlidXRpb24gZHJhZnQg YW5kIHRoaXMgZHJhZnQgc2hvdWxkIGJlIHVwZGF0ZWQgd2l0aCBhIHNlbnRlbmNlIG9yIHR3byBz YXlpbmcgdGhhdCBlaXRoZXIgYXBwcm9hY2ggY2FuIGJlIHRha2VuLiZuYnNwOyBEbyBvdGhlcnMg Y29uY3VyPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzAwMjA2MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEJyaWFuIENhbXBiZWxsIFttYWlsdG86YmNhbXBiZWxs QHBpbmdpZGVudGl0eS5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIE5vdmVtYmVy IDA1LCAyMDE1IDc6NDggQU08YnI+DQo8Yj5Ubzo8L2I+IE1pa2UgSm9uZXM8YnI+DQo8Yj5DYzo8 L2I+IEtlcGVuZyBMaTsgb2F1dGhAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtP QVVUSC1XR10gUHJvb2Ytb2YtUG9zc2Vzc2lvbiBLZXkgU2VtYW50aWNzIGZvciBKV1RzIHNwZWMg YWRkcmVzc2luZyBmaW5hbCBzaGVwaGVyZCBjb21tZW50PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQi PiYjNDM7MSBmb3IgdGhlIGRpYWdyYW1zIG1ha2luZyB0aGUgZG9jdW1lbnQgbW9yZSB1bmRlcnN0 YW5kYWJsZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5PbmUgbGl0dGxlIG5pdC9xdWVzdGlvbiwgc3RlcCAx IGluIGJvdGggU3ltbWV0cmljIGFuZCBBc3ltbWV0cmljIGtleXMgc2hvd3MgdGhlIFByZXNlbnRl ciBzZW5kaW5nIHRoZSBrZXkgdG8gdGhlIElzc3Vlci4gSXQncyBwb3NzaWJsZSwgaG93ZXZlciwg Zm9yIHRoZSBrZXkgdG8gYmUgc2VudCB0aGUgb3RoZXIgd2F5LiBQcmVzZW50ZXIgc2VuZGluZyBp dCB0bw0KIHRoZSBJc3N1ZXIgaXMgcHJvYmFibHkgcHJlZmVycmVkIGZvciBhc3ltbWV0cmljLCBl c3BlY2lhbGx5IGlmIHRoZSBjbGllbnQgY2FuIHNlY3VyZSB0aGUgcHJpdmF0ZSBrZXlzIGluIGhh cmR3YXJlLiBCdXQgSSBkb24ndCBrbm93IGlmIG9uZSB3YXkgb3IgdGhlIG90aGVyIGlzIGNsZWFy bHkgYmV0dGVyIGZvciBzeW1tZXRyaWMgY2FzZSBhbmQNCjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLXBvcC1rZXktZGlzdHJpYnV0aW9uLTAyI3Nl Y3Rpb24tNC4yIj4NClBvUCBrZXkgZGlzdHJpYnV0aW9uIGN1cnJlbnRseSBoYXMgaXQgdGhlIG90 aGVyIHdheTwvYT4uIFNob3VsZCB0aGUgaW50cm8gdGV4dCBzb21laG93IG1lbnRpb24gdGhlIHBv c3NpYmlsaXR5IHRoYXQgdGhlIElzc3VlciBjb3VsZCBjcmVhdGUgdGhlIGtleSBhbmQgc2VuZCBp dCB0byB0aGUgUHJlc2VudGVyPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5JIGtub3cgaXQncyBvbmx5IHRoZSBpbnRyb2R1Y3Rpb24gYnV0IGl0IHdhcyBqdXN0 IHNvbWV0aGluZyB0aGF0IGp1bXBlZCBvdXQgYXQgbWUuICZuYnNwOw0KPG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t OjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gV2VkLCBOb3YgNCwgMjAxNSBhdCA5OjA0IEFNLCBNaWtl IEpvbmVzICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tIiB0 YXJnZXQ9Il9ibGFuayI+TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPC9hPiZndDsgd3JvdGU6 PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPlRoYW5rcyBmb3Igc3Vn Z2VzdGluZyB0aGUgZGlhZ3JhbXMsIEtlcGVuZy4gVGhleSBtYWtlIHRoZSBkb2N1bWVudCBtb3Jl IHVuZGVyc3RhbmRhYmxlLjxicj4NCjxicj4NCi0tIE1pa2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNl bnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTpTaW1TdW47Y29sb3I6YmxhY2siPg0KPGhyIHNpemU9IjMiIHdpZHRo PSIxMDAlIiBhbGlnbj0iY2VudGVyIj4NCjwvc3Bhbj48L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOmJsYWNrIj5Gcm9tOg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6YmxhY2siPjxhIGhyZWY9Im1haWx0bzprZXBlbmcubGtwQGFsaWJhYmEt aW5jLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPktlcGVuZyBMaTwvYT48L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6U2ltU3VuO2NvbG9yOmJsYWNrIj48YnI+DQo8 L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5TZW50Og0K PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPuKAjjEx L+KAjjUv4oCOMjAxNSAxMjo1NyBBTTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTpTaW1TdW47Y29sb3I6YmxhY2siPjxicj4NCjwvc3Bhbj48Yj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPlRvOg0KPC9zcGFuPjwvYj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxhIGhyZWY9Im1haWx0bzpNaWNoYWVs LkpvbmVzQG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj5NaWtlIEpvbmVzPC9hPjsNCjxh IGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm9hdXRoQGlldGYu b3JnPC9hPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpT aW1TdW47Y29sb3I6YmxhY2siPjxicj4NCjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6YmxhY2siPlN1YmplY3Q6DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpibGFjayI+UmU6IFByb29mLW9mLVBvc3Nlc3Npb24gS2V5IFNlbWFu dGljcyBmb3IgSldUcyBzcGVjIGFkZHJlc3NpbmcgZmluYWwgc2hlcGhlcmQgY29tbWVudDwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpTaW1TdW47Y29sb3I6 YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OlNpbVN1bjtjb2xvcjpibGFjayI+VGhhbmsgeW91IE1pa2UuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6U2ltU3VuO2NvbG9yOmJsYWNr Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpTaW1T dW47Y29sb3I6YmxhY2siPlRoZSBkaWFncmFtcyBsb29rIGdvb2QgdG8gbWUuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6U2ltU3VuO2NvbG9yOmJsYWNrIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpTaW1TdW47Y29s b3I6YmxhY2siPktpbmQgUmVnYXJkczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OlNpbVN1bjtjb2xvcjpibGFjayI+S2VwZW5nPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6U2ltU3VuO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OlNpbVN1bjtjb2xvcjpibGFjayI+5Y+R5Lu25Lq6PC9zcGFuPjwvYj48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjoNCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5NaWtlIEpvbmVzICZsdDs8YSBocmVmPSJtYWls dG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+TWljaGFlbC5K b25lc0BtaWNyb3NvZnQuY29tPC9hPiZndDs8YnI+DQo8L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuO2NvbG9yOmJsYWNrIj7ml6XmnJ88L3Nw YW4+PC9iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Og0KPC9z cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPlRodXJzZGF5 LCA1IE5vdmVtYmVyLCAyMDE1IDEyOjMyIGFtPGJyPg0KPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1bjtjb2xvcjpibGFjayI+6IezPC9zcGFu PjwvYj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjoNCjwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mcXVvdDs8YSBo cmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5vYXV0aEBpZXRmLm9y ZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPm9hdXRoQGlldGYub3JnPC9hPiZndDs8YnI+DQo8L3NwYW4+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuO2NvbG9yOmJsYWNrIj7mioTpgIE8 L3NwYW4+PC9iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Og0K PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkxpIEtl cGVuZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmtlcGVuZy5sa3BAYWxpYmFiYS1pbmMuY29tIiB0YXJn ZXQ9Il9ibGFuayI+a2VwZW5nLmxrcEBhbGliYWJhLWluYy5jb208L2E+Jmd0Ozxicj4NCjwvc3Bh bj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpTaW1TdW47Y29s b3I6YmxhY2siPuS4u+mimDwvc3Bhbj48L2I+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOmJsYWNrIj46DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjpibGFjayI+UHJvb2Ytb2YtUG9zc2Vzc2lvbiBLZXkgU2VtYW50aWNzIGZvciBKV1RzIHNw ZWMgYWRkcmVzc2luZyBmaW5hbCBzaGVwaGVyZCBjb21tZW50PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6U2ltU3VuO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5Qcm9vZi1vZi1Qb3NzZXNzaW9u IEtleSBTZW1hbnRpY3MgZm9yIEpXVHMgZHJhZnQgLTA2IGFkZHJlc3NlcyB0aGUgcmVtYWluaW5n IGRvY3VtZW50IHNoZXBoZXJkIGNvbW1lbnQg4oCTIGFkZGluZyB1c2UgY2FzZSBkaWFncmFtcyB0 byB0aGUgaW50cm9kdWN0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ VGhlIHVwZGF0ZWQgc3BlY2lmaWNhdGlvbiBpcyBhdmFpbGFibGUgYXQ6PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6U2lt U3VuO2NvbG9yOmJsYWNrIj7Ctzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2Nv bG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpTaW1TdW47Y29s b3I6YmxhY2siPjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYt b2F1dGgtcHJvb2Ytb2YtcG9zc2Vzc2lvbi0wNiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtcHJvb2Ytb2YtcG9zc2Vzc2lvbi0wNjwv YT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkFuIEhUTUwgZm9ybWF0dGVk IHZlcnNpb24gaXMgYWxzbyBhdmFpbGFibGUgYXQ6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6U2ltU3VuO2NvbG9yOmJs YWNrIj7Ctzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2NvbG9yOmJsYWNrIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpTaW1TdW47Y29sb3I6YmxhY2siPjxh IGhyZWY9Imh0dHBzOi8vc2VsZi1pc3N1ZWQuaW5mby9kb2NzL2RyYWZ0LWlldGYtb2F1dGgtcHJv b2Ytb2YtcG9zc2Vzc2lvbi0wNi5odG1sIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9zZWxmLWlz c3VlZC5pbmZvL2RvY3MvZHJhZnQtaWV0Zi1vYXV0aC1wcm9vZi1vZi1wb3NzZXNzaW9uLTA2Lmh0 bWw8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg LS0gTWlrZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+UC5TLiZuYnNwOyBU aGlzIG5vdGUgd2FzIGFsc28gcG9zdGVkIGF0DQo8YSBocmVmPSJodHRwOi8vc2VsZi1pc3N1ZWQu aW5mby8/cD0xNDcxIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3NlbGYtaXNzdWVkLmluZm8vP3A9 MTQ3MTwvYT4gYW5kIGFzDQo8YSBocmVmPSJodHRwczovL3R3aXR0ZXIuY29tL3NlbGZpc3N1ZWQi IHRhcmdldD0iX2JsYW5rIj5Ac2VsZmlzc3VlZDwvYT4uPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGgg bWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj5PQXV0aEBp ZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_BY2PR03MB44262EA4616E08287A91DB1F52A0BY2PR03MB442namprd_-- From nobody Wed Nov 4 16:26:13 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D70A81B2A8A for ; Wed, 4 Nov 2015 16:26:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kuxvRJDOE1q1 for ; Wed, 4 Nov 2015 16:26:10 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D3AC1AD04E for ; Wed, 4 Nov 2015 16:26:10 -0800 (PST) Received: from [192.168.10.241] ([133.93.52.154]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MBFgr-1ZmgGX2D01-00AEEH; Thu, 05 Nov 2015 01:26:05 +0100 To: Mike Jones , Brian Campbell References: From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <563AA216.5010109@gmx.net> Date: Thu, 5 Nov 2015 01:25:58 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="l51nULH53TidKhnnDmpccSw8kDoHtiToi" X-Provags-ID: V03:K0:RdhsftmpYOsGli94wq2FIhn8vgMzRaY+R12NW4AdzdzH0U5O1EJ Famk9lBx+RRpB0SlP0BlPyhL+oAcjhnmrGaCEk3WgW/jGToGskRc2BgfGITvJ7TtOV4z1fQ tFclrWDOHQ6o2KAuKikoWbqfCA3GtW5nm23g/2mCJkEyzGEwQvHe6q42H3tz0IPa8IO1LF8 NvrLcmE6VrmWwqU1AYAlg== X-UI-Out-Filterresults: notjunk:1;V01:K0:9B1cERYCJs4=:JD3nXSdKDxq7B4iBVYRSxf 4n4tPkA4hp1FI5nt/xOXym4nUQiHjvN0l39aOtWE/WLLskwXq34uHjNBk3lPV1DcfGXlxQGjX S/KER6yVTAvI0kS9bMYLrQWDES0C8QAeDGR/IE7gBE8C9SSlto3JAsN2y1qHxPWhDgijEsNLc yxMn8wfJo0uHSF8tZwsrryPk+ice+ahwDsAPdVniZ+urxikGmUQFONQvhgvSeLpSpXLvc333O nFLe7EnFtWNEJznrY/V9Nb7a/EKWDZRcGAlglU5KFPcqf7CdQWzsFtfqAzVUYbI91177tCzle KDwmuAnUSbgapxoZIoiiYYwrCbwi8cMixZcpaONggWuHvOxL+hkCOVydFliK8QLkKb2oKE6ry nJUHrKg7XbXCC9OPP9OMmw1fWsZnLprqoSKhsXbWCneIEeil1obxgSZqPC9aBBzFMj4lLyIqI JdgHZKKLW8/0OGjcn4ky0+VzjRSkBpWoQ7D9q89yqylIZL3RZXYiaXUzA0xEeQC9KZ6puUL8c WV+bS7iGFeoUYHFeFVwBM6ci5hdPmyBJQPiVywHGMQwHWrk1q4yeKSYEqwb4EL6rTP9gNAqb9 XDLOydnx+WOW/Yp7rd1WNfhVlUJ/tRRDfzkTt3CNzBTNf7egV2yMkA9pNO5L+ltZ1343wLF9Q b37UpdXVhJcgf94XExJNi8EGmIelYXUZNy+E7/KV+0oO/jG4QEhyf36WODRKsNM1dMhQlUSKJ 4Drx6Z5Mi0eB7Qwj0cchIukXxcIUFNFWvS+mAZ0LEdAFlJFrcBfXtThuOOw= Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 00:26:13 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --l51nULH53TidKhnnDmpccSw8kDoHtiToi Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I agree that the effect is the same. From a security point of view there is only an impact if one of the two parties is in a better position to generate random numbers, which is the basis for generating a high entropy symmetric key. On 11/04/2015 11:51 PM, Mike Jones wrote: > Thanks for the detailed read, Brian. You=E2=80=99re right that in the = symmetric > case, either the issuer or the presenter can create the symmetric PoP > key and share it with the other party, since the effect is equivalent. = > I suspect that both the key distribution draft and this draft should be= > updated with a sentence or two saying that either approach can be > taken. Do others concur? >=20 > =20 >=20 > -- Mike >=20 > =20 >=20 > *From:*Brian Campbell [mailto:bcampbell@pingidentity.com] > *Sent:* Thursday, November 05, 2015 7:48 AM > *To:* Mike Jones > *Cc:* Kepeng Li; oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs > spec addressing final shepherd comment >=20 > =20 >=20 > +1 for the diagrams making the document more understandable. >=20 > One little nit/question, step 1 in both Symmetric and Asymmetric keys > shows the Presenter sending the key to the Issuer. It's possible, > however, for the key to be sent the other way. Presenter sending it to > the Issuer is probably preferred for asymmetric, especially if the > client can secure the private keys in hardware. But I don't know if one= > way or the other is clearly better for symmetric case and PoP key > distribution currently has it the other way > . > Should the intro text somehow mention the possibility that the Issuer > could create the key and send it to the Presenter? >=20 > I know it's only the introduction but it was just something that jumped= > out at me. =20 >=20 > =20 >=20 > =20 >=20 > On Wed, Nov 4, 2015 at 9:04 AM, Mike Jones > wrote: >=20 > Thanks for suggesting the diagrams, Kepeng. They make the document more= > understandable. >=20 > -- Mike >=20 > -----------------------------------------------------------------------= - >=20 > *From: *Kepeng Li > *Sent: *=E2=80=8E11/=E2=80=8E5/=E2=80=8E2015 12:57 AM > *To: *Mike Jones ; oauth@ietf.org > > *Subject: *Re: Proof-of-Possession Key Semantics for JWTs spec > addressing final shepherd comment >=20 > Thank you Mike. >=20 > =20 >=20 > The diagrams look good to me. >=20 > =20 >=20 > Kind Regards >=20 > Kepeng >=20 > =20 >=20 > *=E5=8F=91=E4=BB=B6=E4=BA=BA**: *Mike Jones > > *=E6=97=A5=E6=9C=9F**: *Thursday, 5 November, 2015 12:32 am > *=E8=87=B3**: *"oauth@ietf.org " > > *=E6=8A=84=E9=80=81**: *Li Kepeng > > *=E4=B8=BB=E9=A2=98**: *Proof-of-Possession Key Semantics for JWTs spec= addressing > final shepherd comment >=20 > =20 >=20 > Proof-of-Possession Key Semantics for JWTs draft -06 addresses the > remaining document shepherd comment =E2=80=93 adding use case diagrams = to the > introduction. >=20 > =20 >=20 > The updated specification is available at: >=20 > =C2=B7 http://tools.ietf.org/html/draft-ietf-oauth-proof-of-poss= ession-06 >=20 > =20 >=20 > An HTML formatted version is also available at: >=20 > =C2=B7 =20 > https://self-issued.info/docs/draft-ietf-oauth-proof-of-possession-06.h= tml >=20 > =20 >=20 > -- Mike >=20 > =20 >=20 > P.S. This note was also posted at http://self-issued.info/?p=3D1471 an= d > as @selfissued . >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 > =20 >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 --l51nULH53TidKhnnDmpccSw8kDoHtiToi Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJWOqIXAAoJEGhJURNOOiAtUlcIAIowuxFXV0gRp5c9O3Ds7DIV 56uHWRvfAvc9DWi1nITQAAlM08mfwb8MbBy0aLRwB9QkapxAQyt9DXCdbb61cs9c 2yMAp/UC+yyxF6L9DXHA06feuCe4BvOXNtguuhfLVlnuLsX1BQgx9u8S0LMnrOiR gy8+a6jJ154WYwJeQXQKDZHwJZQEWVAzU4THyY91ZAwX0EDjgK54XgpaVXN9v3PR hCkkAsytkrG9gGvePXBT8XaSaxS+OgRI/16UKfb+W1svN5lY9bTSgUkhPjaZXV5k bYpYOuWpm0uMKvCQzHBrfN9qb9oyYUYOsVBvIGPv1FXSLnAA7lP4xMLxZh7VJrM= =v6YZ -----END PGP SIGNATURE----- --l51nULH53TidKhnnDmpccSw8kDoHtiToi-- From nobody Wed Nov 4 16:44:50 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 836BA1B3432 for ; Wed, 4 Nov 2015 16:44:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jB4dceGKvqxT for ; Wed, 4 Nov 2015 16:44:48 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3A871B34F5 for ; Wed, 4 Nov 2015 16:44:47 -0800 (PST) Received: from [192.168.10.241] ([133.93.52.154]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MGnPx-1ZhCMH1KKH-00DVns for ; Thu, 05 Nov 2015 01:44:45 +0100 To: "oauth@ietf.org" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <563AA676.4060106@gmx.net> Date: Thu, 5 Nov 2015 01:44:38 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="9oixLeiEdmTBx5wW1LhFX54EU7kN8nfCP" X-Provags-ID: V03:K0:nCBhdQxakIR0vvcTCKbNCE3/CUYkw4/EeIHZzn598nONKIIdkvt 1L9Yyvi26/fuhHU2BULpc4gEH6IlRUc+sOmGH5motPwK2ksHvxTrfkc12ZGn+OnxDRpnaaB 9sf+MqrV0wkLe0AGcYCs45Umxy/HvligDKcGYNWuCakV5QOI0UxWFSA682Md9WQfm20px+Y 70QkK9RTjRXS6EQ6RsujQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:z3uWzIpAXJo=:35Oa386PBj6QgnZmC67gOC yMRZu9Dyo6/9wIjjKJ84LhEogaN0uwb3RyYyghjJNbO2CPOBsgPPPRWYFsMyzG54udimgjWWT 6PMd+Wtkq2+GttZWVZhDD5Axauy90ZGmJ9yVpGemCT9yeU1Lm7HxOzGz5JBpeAU6zpyPQQjl1 sddCGORV13cpuxT161YfpuNQferC4X2NH8W9zja2V+NA4m6mUhvD2ax0Migmze8jl3gGdkWo9 N/kutSUF8kUYUcUBuy0G1L7VYmyRn5OOZUrtpQ+YqyceFoJ64vW2zBdy9IzkWcaUkC81jubfc MjS2Apg5bebaUCXEXLa6HhwFrq/J9P06tNQkeL14iAKp7LwVZLYvL4I1G2Cud79STfc/AE9Cp TbnH5lem3YPd2BCQywPm73T8E4J/uRdlvZng07MRJdCUtCwz3NyiIU5pnTRt5oqialQbmdVXx K5Wi/4Q745TnWHFit4Z288yYZapDFLXHWhUGwykvkZePJYeoBt6bNdsvsmtKcF4dhfK1OkJX7 MKSiOCSrXiS5eyf1XU10229s0QLbWYE5MgEcZChJRej49YY1cJ5I+y0/GE0IsGN5MCMPIusMn arpa6pq/MC/5kxWhJvl3WSOD3k3we/VupFEvNU/nP0UMH/tUn3vhJrm8+lwZLg/w+8qyy53zY 8gU6XJakFh4jV33o6lNshSAb6+SYRYY+N6cIwY2Ukm9AXX5+SshduJR8+sljG5JVKnhc5XRo0 Q7MxDMObJtdiGgGiRNZ49ovj6lS4CtuE/6A60fMiD2yJTmuNHJ+10j6CTyc= Archived-At: Subject: [OAUTH-WG] OAuth Device Flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 00:44:49 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --9oixLeiEdmTBx5wW1LhFX54EU7kN8nfCP Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable FYI: A couple of us got together and re-published an old, expired draft about the OAuth Device Flow. Here is the document: https://tools.ietf.org/html/draft-denniss-oauth-device-flow-00 For the -00 version we tired to keep it inline with what has been available with draft-recordon-oauth-v2-device-00. In upcoming versions of this document we would like to capture existing deployment. Here are two deployment examples that are reasonably well described: - Google https://developers.google.com/youtube/v3/guides/auth/devices - Facebook https://developers.facebook.com/docs/facebook-login/for-devices Ciao Hannes --9oixLeiEdmTBx5wW1LhFX54EU7kN8nfCP Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJWOqZ3AAoJEGhJURNOOiAtgUMH/3eUshdpdF4HiE572d2MZRux dkHlv231/WnJh4eRi5DaVFuKg6V+gZLrJfW0vexQ+8yj2cHodsUvC9jOtDg7pWUF 9SSvGrI3hZn42yiMP8r6VWJyxeDpoxkOcpGmB/Hn96JOjOWtbl4mEZfw6es9DPEt k+LCjGmGngs9hDCzcwqWRf3e2SgKxuzsPfpE+4tsv5AWiJwthcxTaABKlVslVFRx GRv/5w+eDha0PxBdn0ksNa1y/6JlB27d1UHYhrlRj3ni69NnGfsiu5UoxKPfdPOb UEKO4zNfr6tOgpv7muKUmxzi959XG4AbdVd501Dybo5+g2uaxnKHU+xw7laRq3o= =pK2+ -----END PGP SIGNATURE----- --9oixLeiEdmTBx5wW1LhFX54EU7kN8nfCP-- From nobody Wed Nov 4 17:45:17 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3E961B362D for ; Wed, 4 Nov 2015 17:45:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aRtr6AnD5hSU for ; Wed, 4 Nov 2015 17:45:13 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0795.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::795]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D16A11B3645 for ; Wed, 4 Nov 2015 17:45:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=fUzJpv0yM21ddue73aw9beExVb2rxwLkNDJBpNZKxs4=; b=Zi3unwdSkrLhwxYE2voMcgqptFogxj4oHEj5vMtNG3vBQYDHT4iV0p9yo1EchQH0wGWf8ojuBZh8tNWma771tSpozaBZlVMRIzep7RljWIpbYCy0/4hM2tz23LhA3F2SjpUCIN46K2jTfwadTbbqpZ/ymcatoMbUQMyC2W4253A= Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB443.namprd03.prod.outlook.com (10.141.141.152) with Microsoft SMTP Server (TLS) id 15.1.318.15; Thu, 5 Nov 2015 01:44:49 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0318.003; Thu, 5 Nov 2015 01:44:49 +0000 From: Mike Jones To: Hannes Tschofenig , Brian Campbell Thread-Topic: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment Thread-Index: AdEXFgZ+9CN0zPNjS1iUuZ0RolJO4QAA29mAAAA+4ZAADhjrAAAADBnAAANhSAAAArrysA== Date: Thu, 5 Nov 2015 01:44:49 +0000 Message-ID: References: <563AA216.5010109@gmx.net> In-Reply-To: <563AA216.5010109@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [115.125.248.66] x-microsoft-exchange-diagnostics: 1; BY2PR03MB443; 5:D4LZ4jtkQ8k9oe8YudFy6ozQb4TVmfdrDmYwpdUmYfcjfaXHJ8l3hYDSqcRfNuKMrnm5zJKyKKtRhYSTW5nqQ2/OCXJQR7V5VavbmmjnSrnJgo8pZ3DwJ6gcDJwEOuTBCYnnr3NkVc1rzxl/2T+tHA==; 24:D2ElS+1FAOiz+nvGEgM9hxUx4pfuRslpFvECzbVB63EHMcr88bHEPYKeOa80r2rafqvqSqYI5P4opWOod8iodW39+RVuUtc7Vm3ChnLs9fo=; 20:EpKrQ6BU9IvQheJuifARvX3PVU3dxkZWX7iSzT1Ncs71vieIDHRir2SVlfVJPIleBQIgDI6gWSLda+3RG1hTmg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB443; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425024)(601004)(2401047)(5005006)(8121501046)(520078)(3002001)(10201501046)(61426024)(61427024); SRVR:BY2PR03MB443; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB443; x-forefront-prvs: 0751474A44 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(209900001)(189002)(377454003)(199003)(479174004)(13464003)(24454002)(51914003)(71364002)(52604005)(102836002)(93886004)(5008740100001)(1720100001)(87936001)(230783001)(122556002)(5004730100002)(77096005)(5007970100001)(2900100001)(2950100001)(11100500001)(40100003)(101416001)(66066001)(76576001)(15975445007)(19580395003)(19580405001)(74316001)(86362001)(50986999)(33656002)(106356001)(76176999)(54356999)(105586002)(86612001)(97736004)(99286002)(5001770100001)(5001960100002)(5001920100001)(5002640100001)(10400500002)(5005710100001)(10290500002)(81156007)(8990500004)(189998001)(10090500001)(5003600100002)(92566002)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB443; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Nov 2015 01:44:49.7292 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB443 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 01:45:16 -0000 R29vZCBwb2ludC4gIEknbGwgcmVwdWJsaXNoIGluIHRoZSBuZXh0IGRheSBvciBzbyBhZGRpbmcg dGhhdCB0byB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMuDQoNCgkJCQktLSBNaWtlDQoNCi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBIYW5uZXMgVHNjaG9mZW5pZyBbbWFpbHRv Omhhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXRdIA0KU2VudDogVGh1cnNkYXksIE5vdmVtYmVyIDA1 LCAyMDE1IDk6MjYgQU0NClRvOiBNaWtlIEpvbmVzOyBCcmlhbiBDYW1wYmVsbA0KQ2M6IG9hdXRo QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBQcm9vZi1vZi1Qb3NzZXNzaW9uIEtl eSBTZW1hbnRpY3MgZm9yIEpXVHMgc3BlYyBhZGRyZXNzaW5nIGZpbmFsIHNoZXBoZXJkIGNvbW1l bnQNCg0KSSBhZ3JlZSB0aGF0IHRoZSBlZmZlY3QgaXMgdGhlIHNhbWUuIEZyb20gYSBzZWN1cml0 eSBwb2ludCBvZiB2aWV3IHRoZXJlIGlzIG9ubHkgYW4gaW1wYWN0IGlmIG9uZSBvZiB0aGUgdHdv IHBhcnRpZXMgaXMgaW4gYSBiZXR0ZXIgcG9zaXRpb24gdG8gZ2VuZXJhdGUgcmFuZG9tIG51bWJl cnMsIHdoaWNoIGlzIHRoZSBiYXNpcyBmb3IgZ2VuZXJhdGluZyBhIGhpZ2ggZW50cm9weSBzeW1t ZXRyaWMga2V5Lg0KDQpPbiAxMS8wNC8yMDE1IDExOjUxIFBNLCBNaWtlIEpvbmVzIHdyb3RlOg0K PiBUaGFua3MgZm9yIHRoZSBkZXRhaWxlZCByZWFkLCBCcmlhbi4gIFlvdeKAmXJlIHJpZ2h0IHRo YXQgaW4gdGhlIA0KPiBzeW1tZXRyaWMgY2FzZSwgZWl0aGVyIHRoZSBpc3N1ZXIgb3IgdGhlIHBy ZXNlbnRlciBjYW4gY3JlYXRlIHRoZSANCj4gc3ltbWV0cmljIFBvUCBrZXkgYW5kIHNoYXJlIGl0 IHdpdGggdGhlIG90aGVyIHBhcnR5LCBzaW5jZSB0aGUgZWZmZWN0IGlzIGVxdWl2YWxlbnQuDQo+ IEkgc3VzcGVjdCB0aGF0IGJvdGggdGhlIGtleSBkaXN0cmlidXRpb24gZHJhZnQgYW5kIHRoaXMg ZHJhZnQgc2hvdWxkIA0KPiBiZSB1cGRhdGVkIHdpdGggYSBzZW50ZW5jZSBvciB0d28gc2F5aW5n IHRoYXQgZWl0aGVyIGFwcHJvYWNoIGNhbiBiZSANCj4gdGFrZW4uICBEbyBvdGhlcnMgY29uY3Vy Pw0KPiANCj4gIA0KPiANCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KPiANCj4gIA0KPiANCj4gKkZyb206KkJyaWFu IENhbXBiZWxsIFttYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb21dDQo+ICpTZW50Oiog VGh1cnNkYXksIE5vdmVtYmVyIDA1LCAyMDE1IDc6NDggQU0NCj4gKlRvOiogTWlrZSBKb25lcw0K PiAqQ2M6KiBLZXBlbmcgTGk7IG9hdXRoQGlldGYub3JnDQo+ICpTdWJqZWN0OiogUmU6IFtPQVVU SC1XR10gUHJvb2Ytb2YtUG9zc2Vzc2lvbiBLZXkgU2VtYW50aWNzIGZvciBKV1RzIA0KPiBzcGVj IGFkZHJlc3NpbmcgZmluYWwgc2hlcGhlcmQgY29tbWVudA0KPiANCj4gIA0KPiANCj4gKzEgZm9y IHRoZSBkaWFncmFtcyBtYWtpbmcgdGhlIGRvY3VtZW50IG1vcmUgdW5kZXJzdGFuZGFibGUuDQo+ IA0KPiBPbmUgbGl0dGxlIG5pdC9xdWVzdGlvbiwgc3RlcCAxIGluIGJvdGggU3ltbWV0cmljIGFu ZCBBc3ltbWV0cmljIGtleXMgDQo+IHNob3dzIHRoZSBQcmVzZW50ZXIgc2VuZGluZyB0aGUga2V5 IHRvIHRoZSBJc3N1ZXIuIEl0J3MgcG9zc2libGUsIA0KPiBob3dldmVyLCBmb3IgdGhlIGtleSB0 byBiZSBzZW50IHRoZSBvdGhlciB3YXkuIFByZXNlbnRlciBzZW5kaW5nIGl0IHRvIA0KPiB0aGUg SXNzdWVyIGlzIHByb2JhYmx5IHByZWZlcnJlZCBmb3IgYXN5bW1ldHJpYywgZXNwZWNpYWxseSBp ZiB0aGUgDQo+IGNsaWVudCBjYW4gc2VjdXJlIHRoZSBwcml2YXRlIGtleXMgaW4gaGFyZHdhcmUu IEJ1dCBJIGRvbid0IGtub3cgaWYgDQo+IG9uZSB3YXkgb3IgdGhlIG90aGVyIGlzIGNsZWFybHkg YmV0dGVyIGZvciBzeW1tZXRyaWMgY2FzZSBhbmQgUG9QIGtleSANCj4gZGlzdHJpYnV0aW9uIGN1 cnJlbnRseSBoYXMgaXQgdGhlIG90aGVyIHdheSANCj4gPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1pZXRmLW9hdXRoLXBvcC1rZXktZGlzdHJpYnV0aW9uLTAyI3NlY3Rpb24tNC4y Pi4NCj4gU2hvdWxkIHRoZSBpbnRybyB0ZXh0IHNvbWVob3cgbWVudGlvbiB0aGUgcG9zc2liaWxp dHkgdGhhdCB0aGUgSXNzdWVyIA0KPiBjb3VsZCBjcmVhdGUgdGhlIGtleSBhbmQgc2VuZCBpdCB0 byB0aGUgUHJlc2VudGVyPw0KPiANCj4gSSBrbm93IGl0J3Mgb25seSB0aGUgaW50cm9kdWN0aW9u IGJ1dCBpdCB3YXMganVzdCBzb21ldGhpbmcgdGhhdCANCj4ganVtcGVkIG91dCBhdCBtZS4NCj4g DQo+ICANCj4gDQo+ICANCj4gDQo+IE9uIFdlZCwgTm92IDQsIDIwMTUgYXQgOTowNCBBTSwgTWlr ZSBKb25lcyANCj4gPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSA8bWFpbHRvOk1pY2hhZWwu Sm9uZXNAbWljcm9zb2Z0LmNvbT4+IHdyb3RlOg0KPiANCj4gVGhhbmtzIGZvciBzdWdnZXN0aW5n IHRoZSBkaWFncmFtcywgS2VwZW5nLiBUaGV5IG1ha2UgdGhlIGRvY3VtZW50IA0KPiBtb3JlIHVu ZGVyc3RhbmRhYmxlLg0KPiANCj4gLS0gTWlrZQ0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAtLQ0K PiANCj4gKkZyb206ICpLZXBlbmcgTGkgPG1haWx0bzprZXBlbmcubGtwQGFsaWJhYmEtaW5jLmNv bT4NCj4gKlNlbnQ6ICrigI4xMS/igI41L+KAjjIwMTUgMTI6NTcgQU0NCj4gKlRvOiAqTWlrZSBK b25lcyA8bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT47IG9hdXRoQGlldGYub3Jn IA0KPiA8bWFpbHRvOm9hdXRoQGlldGYub3JnPg0KPiAqU3ViamVjdDogKlJlOiBQcm9vZi1vZi1Q b3NzZXNzaW9uIEtleSBTZW1hbnRpY3MgZm9yIEpXVHMgc3BlYyANCj4gYWRkcmVzc2luZyBmaW5h bCBzaGVwaGVyZCBjb21tZW50DQo+IA0KPiBUaGFuayB5b3UgTWlrZS4NCj4gDQo+ICANCj4gDQo+ IFRoZSBkaWFncmFtcyBsb29rIGdvb2QgdG8gbWUuDQo+IA0KPiAgDQo+IA0KPiBLaW5kIFJlZ2Fy ZHMNCj4gDQo+IEtlcGVuZw0KPiANCj4gIA0KPiANCj4gKuWPkeS7tuS6uioqOiAqTWlrZSBKb25l cyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tIA0KPiA8bWFpbHRvOk1pY2hhZWwuSm9uZXNA bWljcm9zb2Z0LmNvbT4+DQo+ICrml6XmnJ8qKjogKlRodXJzZGF5LCA1IE5vdmVtYmVyLCAyMDE1 IDEyOjMyIGFtDQo+ICroh7MqKjogKiJvYXV0aEBpZXRmLm9yZyA8bWFpbHRvOm9hdXRoQGlldGYu b3JnPiIgPG9hdXRoQGlldGYub3JnIA0KPiA8bWFpbHRvOm9hdXRoQGlldGYub3JnPj4NCj4gKuaK hOmAgSoqOiAqTGkgS2VwZW5nIDxrZXBlbmcubGtwQGFsaWJhYmEtaW5jLmNvbSANCj4gPG1haWx0 bzprZXBlbmcubGtwQGFsaWJhYmEtaW5jLmNvbT4+DQo+ICrkuLvpopgqKjogKlByb29mLW9mLVBv c3Nlc3Npb24gS2V5IFNlbWFudGljcyBmb3IgSldUcyBzcGVjIGFkZHJlc3NpbmcgDQo+IGZpbmFs IHNoZXBoZXJkIGNvbW1lbnQNCj4gDQo+ICANCj4gDQo+IFByb29mLW9mLVBvc3Nlc3Npb24gS2V5 IFNlbWFudGljcyBmb3IgSldUcyBkcmFmdCAtMDYgYWRkcmVzc2VzIHRoZSANCj4gcmVtYWluaW5n IGRvY3VtZW50IHNoZXBoZXJkIGNvbW1lbnQg4oCTIGFkZGluZyB1c2UgY2FzZSBkaWFncmFtcyB0 byB0aGUgDQo+IGludHJvZHVjdGlvbi4NCj4gDQo+ICANCj4gDQo+IFRoZSB1cGRhdGVkIHNwZWNp ZmljYXRpb24gaXMgYXZhaWxhYmxlIGF0Og0KPiANCj4gwrcgICAgICAgIGh0dHA6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtcHJvb2Ytb2YtcG9zc2Vzc2lvbi0wNg0KPiAN Cj4gIA0KPiANCj4gQW4gSFRNTCBmb3JtYXR0ZWQgdmVyc2lvbiBpcyBhbHNvIGF2YWlsYWJsZSBh dDoNCj4gDQo+IMK3ICAgICAgIA0KPiBodHRwczovL3NlbGYtaXNzdWVkLmluZm8vZG9jcy9kcmFm dC1pZXRmLW9hdXRoLXByb29mLW9mLXBvc3Nlc3Npb24tMDYuDQo+IGh0bWwNCj4gDQo+ICANCj4g DQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIC0tIE1pa2UNCj4gDQo+ICANCj4gDQo+IFAuUy4gIFRoaXMgbm90ZSB3YXMgYWxzbyBw b3N0ZWQgYXQgaHR0cDovL3NlbGYtaXNzdWVkLmluZm8vP3A9MTQ3MSBhbmQgDQo+IGFzIEBzZWxm aXNzdWVkIDxodHRwczovL3R3aXR0ZXIuY29tL3NlbGZpc3N1ZWQ+Lg0KPiANCj4gDQo+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IE9BdXRoIG1haWxp bmcgbGlzdA0KPiBPQXV0aEBpZXRmLm9yZyA8bWFpbHRvOk9BdXRoQGlldGYub3JnPiANCj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KPiANCj4gIA0KPiANCj4g DQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiBPQXV0aCBtYWlsaW5nIGxpc3QNCj4gT0F1dGhAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KPiANCg0K From nobody Wed Nov 4 18:26:47 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ED841B36D8 for ; Wed, 4 Nov 2015 18:26:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sWAkJbuwZLv7 for ; Wed, 4 Nov 2015 18:26:45 -0800 (PST) Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 101181B38D7 for ; Wed, 4 Nov 2015 18:26:43 -0800 (PST) Received: by qgeb1 with SMTP id b1so3362297qge.1 for ; Wed, 04 Nov 2015 18:26:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=kNiCLdrRYrka9/QzUn3wGzZnYhpna6SOJ2YeG/FJap8=; b=GS7N19OQnDLLLvyt3aTDfQAMBdmJsTjpNIbR2VtsmifzY6ITYNgBiwKj9TW/lYY28R Gb8EsAMlsIJKoNz0m9SnnnKuNT9H42QLor8FTTEBPcHQ1wHbec825eNO6NeRvtwWQ+l6 5iLOeeO0FblnnAVaafD5/gWlI2fJJgd3zYsvsGqUrNCewf0hcoAOoBc2n4SevzxCgngE YQZIyfHauq7tQU1pukGNd6u4dDLnL2u/GdSr3vbN71pZGIW+pk960GUqrmvme+iAMlAr z/H7gWDORj0fuY04cLt/25sivufntellXfz1NQ39HOl3wcaDNGrPG0WocPEJglz9zFdR TkIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=kNiCLdrRYrka9/QzUn3wGzZnYhpna6SOJ2YeG/FJap8=; b=D823o7JFJZ0SVZeZ0J6MRd78EgRdc61Jdnykzta1ROvqvd4kfJfLQ6wQ1IO/m5LSvf ws3MX/4ygB8T9PbIT+UTHJxZCJWy1OiUUNr8uxS9FLqF78R9kk+NZzs+Xz13iSETujk1 09rufsOG8Ce20Lc2mHHKQHUBzGPcXBe2Lpd2j9JixijdrG9COQkdwweBjZw8ocDXPQ+B PRML/NFeXf0Zq3lsSkexCshBSCMjHo4L2O9OhkLkeruvzlWQpQOcJqrWBHQ4SuzpfAbR Pod+RQgjdlmwda7uHopK021CIf3yd/RwWW+WSsfEXi3mQW8r3SnohlMTNLahQUaI5mJw 95yA== X-Gm-Message-State: ALoCoQljliHXptAFlSr3mDOxIlaaIAAwJvxOHIFrZepjOS5zo8Y+0DFLP9zYdhjL3RF5NW52IA1e X-Received: by 10.140.153.17 with SMTP id 17mr5197274qhz.91.1446690403044; Wed, 04 Nov 2015 18:26:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.81.99 with HTTP; Wed, 4 Nov 2015 18:26:23 -0800 (PST) In-Reply-To: <563AA676.4060106@gmx.net> References: <563AA676.4060106@gmx.net> From: William Denniss Date: Thu, 5 Nov 2015 11:26:23 +0900 Message-ID: To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=001a113a06aa9302750523c1db26 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth Device Flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 02:26:46 -0000 --001a113a06aa9302750523c1db26 Content-Type: text/plain; charset=UTF-8 Google has additional documentation here: https://developers.google.com/identity/protocols/OAuth2ForDevices The implementation mostly follows the original draft, but there are a few differences. Also we've learnt a lot about the security and usability implications of this flow along the way, which would be good to document. On Thu, Nov 5, 2015 at 9:44 AM, Hannes Tschofenig wrote: > FYI: A couple of us got together and re-published an old, expired draft > about the OAuth Device Flow. > > Here is the document: > https://tools.ietf.org/html/draft-denniss-oauth-device-flow-00 > > For the -00 version we tired to keep it inline with what has been > available with draft-recordon-oauth-v2-device-00. In upcoming versions > of this document we would like to capture existing deployment. > > Here are two deployment examples that are reasonably well described: > > - Google > https://developers.google.com/youtube/v3/guides/auth/devices > > - Facebook > https://developers.facebook.com/docs/facebook-login/for-devices > > Ciao > Hannes > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --001a113a06aa9302750523c1db26 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Google has additional documentation here:=C2=A0https://= developers.google.com/identity/protocols/OAuth2ForDevices

The implementation mostly follows the original draft, but there are a= few differences. Also we've learnt a lot about the security and usabil= ity implications of this flow along the way, which would be good to documen= t.

On = Thu, Nov 5, 2015 at 9:44 AM, Hannes Tschofenig <hannes.tschofenig@= gmx.net> wrote:
FYI: A coup= le of us got together and re-published an old, expired draft
about the OAuth Device Flow.

Here is the document:
https://tools.ietf.org/html/draft-denn= iss-oauth-device-flow-00

For the -00 version we tired to keep it inline with what has been
available with draft-recordon-oauth-v2-device-00. In upcoming versions
of this document we would like to capture existing deployment.

Here are two deployment examples that are reasonably well described:

- Google
https://developers.google.com/youtube/v3= /guides/auth/devices

- Facebook
https://developers.facebook.com/docs/= facebook-login/for-devices

Ciao
Hannes


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


--001a113a06aa9302750523c1db26-- From nobody Wed Nov 4 20:32:14 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5ECB1B36B5 for ; Wed, 4 Nov 2015 20:32:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pxilWXBb17Gc for ; Wed, 4 Nov 2015 20:32:08 -0800 (PST) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31A8B1ACD7B for ; Wed, 4 Nov 2015 20:32:08 -0800 (PST) Received: by pacdm15 with SMTP id dm15so50320349pac.3 for ; Wed, 04 Nov 2015 20:32:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb_com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=10k0na4HrMb041W2tn4IVg61PNOXGlQ0sQkEt8hCSbE=; b=O6/UsqhACUtCeikdbTh2jj3IXSiJIywLuMt8VyStvyOMQlTXaNByyx/5sHQQlabToR mpVn/S7Du4j0O4BtQit8gBgsmgMAUlfykM11SpUkdcNjW5xn26BIyIDoD48Xp0glD90f Sc6FGHNJHXcLh3J+3blv1kQAejzDL8clC3cyuCxcB9sotUx6TS5K44TApLMc01DGZqYw cnQflO3T81HjUPHEOM1Jep4SndP4ulAVP7HlUY9Jna7Q1xk64sL/UE3tKJCB4fKRnyqj neVKJxb8++xS+/W52yZargT+EiFmr+lDYyXKrqN7mAT9CeQWWJZ7JzMMrbS2w/MIvZu1 kKOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=10k0na4HrMb041W2tn4IVg61PNOXGlQ0sQkEt8hCSbE=; b=VsRxYBdvjl9hQvsdVp6CtYCa0WiSz1VLtV5oVoeUdlRYyXjFVQvEsVPMyEQTS5mc3r tA87FIHld+lQO0uowLFY7oMOy6hVLHbl7t6X8QuPsK4tsiiRBvbminURXgHO68NJXLEc Rias0GK//u23DM6RVEsRt2qkIoBDxivQAuOMNarAyZBkJP/psQA6DjAPqkMf61X2LqXW eiWK/84gpO2IrQSq4hDwCic+527slNijxzIxz6iIjSf/oUcvvvC8FdqYR9qwMYzohzCn WDTBiYIwvL5i9P1/sQlD3aBoJgkvqpEnRzFgHj/39Jlwk/nk/8o68uzhiaAQH1ffQPge wNUg== X-Gm-Message-State: ALoCoQmh2/FIfH7Hwh9OKJWH4PhUYJ8nmwem2YL3+H+H8i1bgmxror5lgB2el6j4qQQ+BHaf0XOI X-Received: by 10.68.111.101 with SMTP id ih5mr6983549pbb.84.1446697927723; Wed, 04 Nov 2015 20:32:07 -0800 (PST) Received: from t20010c40000030089044b9d401462547.v6.meeting.ietf94.jp (t20010c40000030089044b9d401462547.v6.meeting.ietf94.jp. [2001:c40:0:3008:9044:b9d4:146:2547]) by smtp.gmail.com with ESMTPSA id cx5sm4971063pbc.50.2015.11.04.20.32.05 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Nov 2015 20:32:07 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: John Bradley In-Reply-To: <563AA216.5010109@gmx.net> Date: Thu, 5 Nov 2015 13:32:05 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <563AA216.5010109@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 04:32:10 -0000 Agreed the only real difference is the quality of the key. If the = server generates it, then it knows that the client is not using the = fixed hex value of DEADBEEF for everything. John B. > On Nov 5, 2015, at 9:25 AM, Hannes Tschofenig = wrote: >=20 > I agree that the effect is the same. =46rom a security point of view = there > is only an impact if one of the two parties is in a better position to > generate random numbers, which is the basis for generating a high > entropy symmetric key. >=20 > On 11/04/2015 11:51 PM, Mike Jones wrote: >> Thanks for the detailed read, Brian. You=E2=80=99re right that in = the symmetric >> case, either the issuer or the presenter can create the symmetric PoP >> key and share it with the other party, since the effect is = equivalent.=20 >> I suspect that both the key distribution draft and this draft should = be >> updated with a sentence or two saying that either approach can be >> taken. Do others concur? >>=20 >>=20 >>=20 >> -- Mike >>=20 >>=20 >>=20 >> *From:*Brian Campbell [mailto:bcampbell@pingidentity.com] >> *Sent:* Thursday, November 05, 2015 7:48 AM >> *To:* Mike Jones >> *Cc:* Kepeng Li; oauth@ietf.org >> *Subject:* Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs >> spec addressing final shepherd comment >>=20 >>=20 >>=20 >> +1 for the diagrams making the document more understandable. >>=20 >> One little nit/question, step 1 in both Symmetric and Asymmetric keys >> shows the Presenter sending the key to the Issuer. It's possible, >> however, for the key to be sent the other way. Presenter sending it = to >> the Issuer is probably preferred for asymmetric, especially if the >> client can secure the private keys in hardware. But I don't know if = one >> way or the other is clearly better for symmetric case and PoP key >> distribution currently has it the other way >> = . >> Should the intro text somehow mention the possibility that the Issuer >> could create the key and send it to the Presenter? >>=20 >> I know it's only the introduction but it was just something that = jumped >> out at me. =20 >>=20 >>=20 >>=20 >>=20 >>=20 >> On Wed, Nov 4, 2015 at 9:04 AM, Mike Jones = > > wrote: >>=20 >> Thanks for suggesting the diagrams, Kepeng. They make the document = more >> understandable. >>=20 >> -- Mike >>=20 >> = ------------------------------------------------------------------------ >>=20 >> *From: *Kepeng Li >> *Sent: *=E2=80=8E11/=E2=80=8E5/=E2=80=8E2015 12:57 AM >> *To: *Mike Jones ; oauth@ietf.org >> >> *Subject: *Re: Proof-of-Possession Key Semantics for JWTs spec >> addressing final shepherd comment >>=20 >> Thank you Mike. >>=20 >>=20 >>=20 >> The diagrams look good to me. >>=20 >>=20 >>=20 >> Kind Regards >>=20 >> Kepeng >>=20 >>=20 >>=20 >> *=E5=8F=91=E4=BB=B6=E4=BA=BA**: *Mike Jones = > > >> *=E6=97=A5=E6=9C=9F**: *Thursday, 5 November, 2015 12:32 am >> *=E8=87=B3**: *"oauth@ietf.org " = > > >> *=E6=8A=84=E9=80=81**: *Li Kepeng > > >> *=E4=B8=BB=E9=A2=98**: *Proof-of-Possession Key Semantics for JWTs = spec addressing >> final shepherd comment >>=20 >>=20 >>=20 >> Proof-of-Possession Key Semantics for JWTs draft -06 addresses the >> remaining document shepherd comment =E2=80=93 adding use case = diagrams to the >> introduction. >>=20 >>=20 >>=20 >> The updated specification is available at: >>=20 >> =C2=B7 = http://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-06 >>=20 >>=20 >>=20 >> An HTML formatted version is also available at: >>=20 >> =C2=B7 =20 >> = https://self-issued.info/docs/draft-ietf-oauth-proof-of-possession-06.html= >>=20 >>=20 >>=20 >> -- Mike >>=20 >>=20 >>=20 >> P.S. This note was also posted at http://self-issued.info/?p=3D1471 = and >> as @selfissued . >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Wed Nov 4 20:36:12 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BDF91B390B for ; Wed, 4 Nov 2015 20:36:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MMFvHSHK6ut2 for ; Wed, 4 Nov 2015 20:36:06 -0800 (PST) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 658481A90BA for ; Wed, 4 Nov 2015 20:36:06 -0800 (PST) X-AuditID: 1209190d-f79766d000002fec-39-563adcb4c74c Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 68.62.12268.5BCDA365; Wed, 4 Nov 2015 23:36:05 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id tA54a4JS005999; Wed, 4 Nov 2015 23:36:04 -0500 Received: from dhcp-29-147.meeting.ietf94.jp (dhcp-29-147.meeting.ietf94.jp [133.93.29.147]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id tA54ZxWG008228 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 4 Nov 2015 23:36:02 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Justin Richer In-Reply-To: Date: Thu, 5 Nov 2015 13:35:58 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <89A6E4DE-263B-4DB4-8882-54FA7103C721@mit.edu> References: <563AA216.5010109@gmx.net> To: John Bradley X-Mailer: Apple Mail (2.2104) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgleLIzCtJLcpLzFFi42IR4hTV1t16xyrMoOkFs8XSnfdYLU6+fcVm sfruXzYHZo/Fm/azeSxZ8pPJ4/btjSwBzFFcNimpOZllqUX6dglcGddXyBcs16k4+O04cwNj m0oXIyeHhICJxNfT55ghbDGJC/fWs4HYQgKLmSTW/efoYuQCsjcwSmy5/50VwrnBJDHtwRMm kCpmAXWJP/MugXXzCuhJvLp1mRXEFhbIlHh9uAcsziagKjF9TQtYPaeAncTG6d1ANgcHi4CK xLt3WSAms0C8xOqN8RATtSWWLXwNNdFK4uKHXcwQa7cxS1y4cAtsjAhQ6759jxghjpaV2P37 EdMERsFZSC6aheSiWUjmLmBkXsUom5JbpZubmJlTnJqsW5ycmJeXWqRrpJebWaKXmlK6iREc 0JK8OxjfHVQ6xCjAwajEw9tRaxUmxJpYVlyZe4hRkoNJSZTX6hxQiC8pP6UyI7E4I76oNCe1 +BCjBAezkghvwUygHG9KYmVValE+TEqag0VJnHfTD74QIYH0xJLU7NTUgtQimKwMB4eSBG/1 baBGwaLU9NSKtMycEoQ0EwcnyHAeoOGNIDW8xQWJucWZ6RD5U4yKUuK8JiAJAZBERmkeXC8o 4bTGyk5+xSgO9IowbxtIFQ8wWcF1vwIazAQ0mKnVAmRwSSJCSqqBMcg/bf/OBbtCWz96rpIJ +P3dJGGDddKblzEK20/Zv/CY8OZUVFVJjatIr6LsbVNThpNfXXZ5JNhWv/Fgybg4h9XvmcMS L/bVvf8dHwlnp/dVLBZonm8vYXYxmflmaJVv0sn5R7hjPR/YXZyi4q9kfL8k4V/Zzc85cxyW POno9l4fqK+soeCtxFKckWioxVxUnAgAvT+2YxMDAAA= Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 04:36:09 -0000 I=E2=80=99d argue that it=E2=80=99s best practice, and in line with = other parts of OAuth, if we assume the server generates it in the normal = case (issuer -> presenter). Client generated token keys should be an = exception, especially in the asymmetric case. =E2=80=94 Justin > On Nov 5, 2015, at 1:32 PM, John Bradley wrote: >=20 > Agreed the only real difference is the quality of the key. If the = server generates it, then it knows that the client is not using the = fixed hex value of DEADBEEF for everything. >=20 > John B. >> On Nov 5, 2015, at 9:25 AM, Hannes Tschofenig = wrote: >>=20 >> I agree that the effect is the same. =46rom a security point of view = there >> is only an impact if one of the two parties is in a better position = to >> generate random numbers, which is the basis for generating a high >> entropy symmetric key. >>=20 >> On 11/04/2015 11:51 PM, Mike Jones wrote: >>> Thanks for the detailed read, Brian. You=E2=80=99re right that in = the symmetric >>> case, either the issuer or the presenter can create the symmetric = PoP >>> key and share it with the other party, since the effect is = equivalent.=20 >>> I suspect that both the key distribution draft and this draft should = be >>> updated with a sentence or two saying that either approach can be >>> taken. Do others concur? >>>=20 >>>=20 >>>=20 >>> -- Mike >>>=20 >>>=20 >>>=20 >>> *From:*Brian Campbell [mailto:bcampbell@pingidentity.com] >>> *Sent:* Thursday, November 05, 2015 7:48 AM >>> *To:* Mike Jones >>> *Cc:* Kepeng Li; oauth@ietf.org >>> *Subject:* Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs >>> spec addressing final shepherd comment >>>=20 >>>=20 >>>=20 >>> +1 for the diagrams making the document more understandable. >>>=20 >>> One little nit/question, step 1 in both Symmetric and Asymmetric = keys >>> shows the Presenter sending the key to the Issuer. It's possible, >>> however, for the key to be sent the other way. Presenter sending it = to >>> the Issuer is probably preferred for asymmetric, especially if the >>> client can secure the private keys in hardware. But I don't know if = one >>> way or the other is clearly better for symmetric case and PoP key >>> distribution currently has it the other way >>> = . >>> Should the intro text somehow mention the possibility that the = Issuer >>> could create the key and send it to the Presenter? >>>=20 >>> I know it's only the introduction but it was just something that = jumped >>> out at me. =20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> On Wed, Nov 4, 2015 at 9:04 AM, Mike Jones = >> > wrote: >>>=20 >>> Thanks for suggesting the diagrams, Kepeng. They make the document = more >>> understandable. >>>=20 >>> -- Mike >>>=20 >>> = ------------------------------------------------------------------------ >>>=20 >>> *From: *Kepeng Li >>> *Sent: *=E2=80=8E11/=E2=80=8E5/=E2=80=8E2015 12:57 AM >>> *To: *Mike Jones ; = oauth@ietf.org >>> >>> *Subject: *Re: Proof-of-Possession Key Semantics for JWTs spec >>> addressing final shepherd comment >>>=20 >>> Thank you Mike. >>>=20 >>>=20 >>>=20 >>> The diagrams look good to me. >>>=20 >>>=20 >>>=20 >>> Kind Regards >>>=20 >>> Kepeng >>>=20 >>>=20 >>>=20 >>> *=E5=8F=91=E4=BB=B6=E4=BA=BA**: *Mike Jones = >> > >>> *=E6=97=A5=E6=9C=9F**: *Thursday, 5 November, 2015 12:32 am >>> *=E8=87=B3**: *"oauth@ietf.org " = >> > >>> *=E6=8A=84=E9=80=81**: *Li Kepeng >> > >>> *=E4=B8=BB=E9=A2=98**: *Proof-of-Possession Key Semantics for JWTs = spec addressing >>> final shepherd comment >>>=20 >>>=20 >>>=20 >>> Proof-of-Possession Key Semantics for JWTs draft -06 addresses the >>> remaining document shepherd comment =E2=80=93 adding use case = diagrams to the >>> introduction. >>>=20 >>>=20 >>>=20 >>> The updated specification is available at: >>>=20 >>> =C2=B7 = http://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-06 >>>=20 >>>=20 >>>=20 >>> An HTML formatted version is also available at: >>>=20 >>> =C2=B7 =20 >>> = https://self-issued.info/docs/draft-ietf-oauth-proof-of-possession-06.html= >>>=20 >>>=20 >>>=20 >>> -- Mike >>>=20 >>>=20 >>>=20 >>> P.S. This note was also posted at http://self-issued.info/?p=3D1471 = and >>> as @selfissued . >>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Wed Nov 4 20:43:19 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F03B1A90AB for ; Wed, 4 Nov 2015 20:43:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AZwUUEAnfjG2 for ; Wed, 4 Nov 2015 20:43:15 -0800 (PST) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08D461A90D1 for ; Wed, 4 Nov 2015 20:43:14 -0800 (PST) Received: by pasz6 with SMTP id z6so77470106pas.2 for ; Wed, 04 Nov 2015 20:43:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb_com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3Z1Sg8FHdjfIDreThwRlIe7kfnrgGzAa3a72Fl6nF5Y=; b=pgRusCVMD/TNGkyARwC+urcJBY8ByHfz0Fk5GRU1K7wTawCtYGxsETzXhFmycduoCt 7cbSUqRlj4Sci65+5LIqSKVb6tH4YDNNunyq5Sdyid8DnPkf+xGMomw/4ZcqBPpd9c6T uUFXfzA2YwzSbLPkEfnJ4k2GT5OvPELrRGsUlS3Re49hqdDaY1+HiALFe5upkIxya0f/ d9xY/DQxUaNZTZLGLaGGiQyOvGdJqf1TS+bisYSGFm8vK25qYBwjTwJ9zVTvzZ2OwsZn y2sSE9hkyWfp+t3iAnJfVe5bFy+TawCq/1ELtTHIHy4VMkzfmcKTVXc4wg6veie6iS6e GIfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=3Z1Sg8FHdjfIDreThwRlIe7kfnrgGzAa3a72Fl6nF5Y=; b=RaJnRNKWlssynmxYWYhUMkP7nEH9x9mpozOHb20r1IYtZvPqrWibGU7p5LBMOMGbGt F9vaAS0GUJujwmKn3Lo3tLVjmpO0dZFa2UEEiEN0dC09t9Wk21gGoUEkqgIOa3FJTxoA iER6J8wGzvy7ugmAUVUarbyY5oFR4itWlIafLRM+mylwo78LpMVp15qvgey//lumLYMG y+xJFExgNYAJhRhjWpLyPNcMWpMTV7ie66NjwHG11muBfiZfO0Jtc0wvJRtHoGtsnQ21 1GpuFW9s7U/eF5eJsvDynA2yHW8+3Hw0Km6CbozEEatn5OLplVS2LmV0qoa3IaJLkNk6 U4iQ== X-Gm-Message-State: ALoCoQmb9KgjASoUfPShw1IFgqDSOEx3Cox5l+EM6emKZwuGElljNqVLDeXznVmQOQEEvFVq0JJ0 X-Received: by 10.66.141.42 with SMTP id rl10mr6915072pab.18.1446698594416; Wed, 04 Nov 2015 20:43:14 -0800 (PST) Received: from t20010c40000030089044b9d401462547.v6.meeting.ietf94.jp (t20010c40000030089044b9d401462547.v6.meeting.ietf94.jp. [2001:c40:0:3008:9044:b9d4:146:2547]) by smtp.gmail.com with ESMTPSA id w8sm4982804pbs.87.2015.11.04.20.43.12 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Nov 2015 20:43:13 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: John Bradley In-Reply-To: <89A6E4DE-263B-4DB4-8882-54FA7103C721@mit.edu> Date: Thu, 5 Nov 2015 13:43:12 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <82079E8A-2AC8-4A42-9AF7-77FF2A3CAFC2@ve7jtb.com> References: <563AA216.5010109@gmx.net> <89A6E4DE-263B-4DB4-8882-54FA7103C721@mit.edu> To: Justin Richer X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 04:43:18 -0000 In the asymmetric case the use of a HSM or secure element is the = argument for the client selecting the public key. In those cases the = client is doing the key gen in hardware so one hopes it is OK. In the = symetric case the client generating the key is weaker (as in I can=E2=80=99= t think of any really good reason). > On Nov 5, 2015, at 1:35 PM, Justin Richer wrote: >=20 > I=E2=80=99d argue that it=E2=80=99s best practice, and in line with = other parts of OAuth, if we assume the server generates it in the normal = case (issuer -> presenter). Client generated token keys should be an = exception, especially in the asymmetric case. >=20 > =E2=80=94 Justin >=20 >> On Nov 5, 2015, at 1:32 PM, John Bradley wrote: >>=20 >> Agreed the only real difference is the quality of the key. If the = server generates it, then it knows that the client is not using the = fixed hex value of DEADBEEF for everything. >>=20 >> John B. >>> On Nov 5, 2015, at 9:25 AM, Hannes Tschofenig = wrote: >>>=20 >>> I agree that the effect is the same. =46rom a security point of view = there >>> is only an impact if one of the two parties is in a better position = to >>> generate random numbers, which is the basis for generating a high >>> entropy symmetric key. >>>=20 >>> On 11/04/2015 11:51 PM, Mike Jones wrote: >>>> Thanks for the detailed read, Brian. You=E2=80=99re right that in = the symmetric >>>> case, either the issuer or the presenter can create the symmetric = PoP >>>> key and share it with the other party, since the effect is = equivalent.=20 >>>> I suspect that both the key distribution draft and this draft = should be >>>> updated with a sentence or two saying that either approach can be >>>> taken. Do others concur? >>>>=20 >>>>=20 >>>>=20 >>>> -- Mike >>>>=20 >>>>=20 >>>>=20 >>>> *From:*Brian Campbell [mailto:bcampbell@pingidentity.com] >>>> *Sent:* Thursday, November 05, 2015 7:48 AM >>>> *To:* Mike Jones >>>> *Cc:* Kepeng Li; oauth@ietf.org >>>> *Subject:* Re: [OAUTH-WG] Proof-of-Possession Key Semantics for = JWTs >>>> spec addressing final shepherd comment >>>>=20 >>>>=20 >>>>=20 >>>> +1 for the diagrams making the document more understandable. >>>>=20 >>>> One little nit/question, step 1 in both Symmetric and Asymmetric = keys >>>> shows the Presenter sending the key to the Issuer. It's possible, >>>> however, for the key to be sent the other way. Presenter sending it = to >>>> the Issuer is probably preferred for asymmetric, especially if the >>>> client can secure the private keys in hardware. But I don't know if = one >>>> way or the other is clearly better for symmetric case and PoP key >>>> distribution currently has it the other way >>>> = . >>>> Should the intro text somehow mention the possibility that the = Issuer >>>> could create the key and send it to the Presenter? >>>>=20 >>>> I know it's only the introduction but it was just something that = jumped >>>> out at me. =20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On Wed, Nov 4, 2015 at 9:04 AM, Mike Jones = >>> > wrote: >>>>=20 >>>> Thanks for suggesting the diagrams, Kepeng. They make the document = more >>>> understandable. >>>>=20 >>>> -- Mike >>>>=20 >>>> = ------------------------------------------------------------------------ >>>>=20 >>>> *From: *Kepeng Li >>>> *Sent: *=E2=80=8E11/=E2=80=8E5/=E2=80=8E2015 12:57 AM >>>> *To: *Mike Jones ; = oauth@ietf.org >>>> >>>> *Subject: *Re: Proof-of-Possession Key Semantics for JWTs spec >>>> addressing final shepherd comment >>>>=20 >>>> Thank you Mike. >>>>=20 >>>>=20 >>>>=20 >>>> The diagrams look good to me. >>>>=20 >>>>=20 >>>>=20 >>>> Kind Regards >>>>=20 >>>> Kepeng >>>>=20 >>>>=20 >>>>=20 >>>> *=E5=8F=91=E4=BB=B6=E4=BA=BA**: *Mike Jones = >>> > >>>> *=E6=97=A5=E6=9C=9F**: *Thursday, 5 November, 2015 12:32 am >>>> *=E8=87=B3**: *"oauth@ietf.org " = >>> > >>>> *=E6=8A=84=E9=80=81**: *Li Kepeng >>> > >>>> *=E4=B8=BB=E9=A2=98**: *Proof-of-Possession Key Semantics for JWTs = spec addressing >>>> final shepherd comment >>>>=20 >>>>=20 >>>>=20 >>>> Proof-of-Possession Key Semantics for JWTs draft -06 addresses the >>>> remaining document shepherd comment =E2=80=93 adding use case = diagrams to the >>>> introduction. >>>>=20 >>>>=20 >>>>=20 >>>> The updated specification is available at: >>>>=20 >>>> =C2=B7 = http://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-06 >>>>=20 >>>>=20 >>>>=20 >>>> An HTML formatted version is also available at: >>>>=20 >>>> =C2=B7 =20 >>>> = https://self-issued.info/docs/draft-ietf-oauth-proof-of-possession-06.html= >>>>=20 >>>>=20 >>>>=20 >>>> -- Mike >>>>=20 >>>>=20 >>>>=20 >>>> P.S. This note was also posted at http://self-issued.info/?p=3D1471 = and >>>> as @selfissued . >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 From nobody Wed Nov 4 20:45:57 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 929CE1B3417 for ; Wed, 4 Nov 2015 20:45:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o1dU9NPXNHbw for ; Wed, 4 Nov 2015 20:45:52 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0133.outbound.protection.outlook.com [65.55.169.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 455D81A89FB for ; Wed, 4 Nov 2015 20:45:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=dEVoe094cP74cKJAIs9g3oTf891EvoeB60r28EVzOhU=; b=hkjbqkH5u7iOrqXl+t0GCEcXZcQqJ/N+8IgPwyeomrGGCzeoqs6EILk0N86QZZcGAK8NmMU9c51m7Sq/a4TXDNXpo94KMCjG0Qciar3f0yfqCT2uWFHKg5xR24sSHdgAaAvqSCDCifaO/z7obvAF52wpe0wTpBBu/mhI5rmHIEA= Received: from BN3PR0301MB1234.namprd03.prod.outlook.com (10.161.207.22) by BN3PR0301MB1233.namprd03.prod.outlook.com (10.161.207.21) with Microsoft SMTP Server (TLS) id 15.1.312.18; Thu, 5 Nov 2015 04:45:49 +0000 Received: from BN3PR0301MB1234.namprd03.prod.outlook.com ([10.161.207.22]) by BN3PR0301MB1234.namprd03.prod.outlook.com ([10.161.207.22]) with mapi id 15.01.0312.014; Thu, 5 Nov 2015 04:45:49 +0000 From: Anthony Nadalin To: John Bradley , Justin Richer Thread-Topic: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment Thread-Index: AdEXFgZ+9CN0zPNjS1iUuZ0RolJO4QAA29mAAAA+4ZAADhjrAAAADBnAAANhSAAACJh0gAAAIrkAAABAqwAAAA9iQA== Date: Thu, 5 Nov 2015 04:45:49 +0000 Message-ID: References: <563AA216.5010109@gmx.net> <89A6E4DE-263B-4DB4-8882-54FA7103C721@mit.edu> <82079E8A-2AC8-4A42-9AF7-77FF2A3CAFC2@ve7jtb.com> In-Reply-To: <82079E8A-2AC8-4A42-9AF7-77FF2A3CAFC2@ve7jtb.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tonynad@microsoft.com; x-originating-ip: [133.93.34.100] x-microsoft-exchange-diagnostics: 1; BN3PR0301MB1233; 5:JdKxScvtDvTrkBekjBfLhtG3DQSQemQtk2e0VvZ3Ki8kJGcw/4V0Xg30JxKiNTFesYjm9GJWEcg40fDFwCLRT3OzoZa5KVcUBRoZci/7npy7ijcoAnHgfY89ytWJAgSkNqzrSeL64PgusOZvE+rTqA==; 24:VEEVNuKndd891qbSBIkNWDL+mK/e3Sn2opAfXnxmk0SudMmj+dNlwXeKvr75UNr+7rDj/9MRyHHONvlCzFdvrEzuG/KfgO5N0kX8YU1jAgw=; 20:QASuknmSP/I4kmFx/y8wZXRfI5yGpKdEmMn2bkn8khvEwVZ6ZR6/0zquxB32lqSklqTReIK1+WiUQAiJ1EqzhQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1233; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(240460790083961)(189930954265078)(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425024)(601004)(2401047)(520078)(5005006)(8121501046)(3002001)(10201501046)(61426024)(61427024); SRVR:BN3PR0301MB1233; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1233; x-forefront-prvs: 0751474A44 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(479174004)(71364002)(52604005)(24454002)(199003)(377454003)(51914003)(189002)(13464003)(86362001)(2900100001)(102836002)(5008740100001)(66066001)(87936001)(76576001)(5004730100002)(11100500001)(10090500001)(77096005)(2950100001)(5007970100001)(15975445007)(74316001)(5003600100002)(93886004)(92566002)(122556002)(10400500002)(40100003)(81156007)(5002640100001)(97736004)(8990500004)(230783001)(5001960100002)(189998001)(19580395003)(5005710100001)(99286002)(10290500002)(5001770100001)(19580405001)(575784001)(33656002)(2171001)(76176999)(101416001)(54356999)(105586002)(50986999)(106356001)(86612001)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1233; H:BN3PR0301MB1234.namprd03.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:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Nov 2015 04:45:49.7168 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0301MB1233 Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 04:45:55 -0000 Tm90IHN1cmUgd2h5IHlvdSB0aGluayBpdHMgd2Vha2VyIGFzIGl0IHdvdWxkIGJlIGEgd3JhcHBl ZCBrZXkgdGhhdCB0aGUgaGFyZHdhcmUgcHJvZHVjZXMgDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQpGcm9tOiBPQXV0aCBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiBKb2huIEJyYWRsZXkNClNlbnQ6IFdlZG5lc2RheSwgTm92ZW1iZXIgNCwgMjAxNSA4 OjQzIFBNDQpUbzogSnVzdGluIFJpY2hlciA8anJpY2hlckBtaXQuZWR1Pg0KQ2M6IDxvYXV0aEBp ZXRmLm9yZz4gPG9hdXRoQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gUHJvb2Yt b2YtUG9zc2Vzc2lvbiBLZXkgU2VtYW50aWNzIGZvciBKV1RzIHNwZWMgYWRkcmVzc2luZyBmaW5h bCBzaGVwaGVyZCBjb21tZW50DQoNCkluIHRoZSBhc3ltbWV0cmljIGNhc2UgdGhlIHVzZSBvZiBh IEhTTSBvciBzZWN1cmUgZWxlbWVudCBpcyB0aGUgYXJndW1lbnQgZm9yIHRoZSBjbGllbnQgc2Vs ZWN0aW5nIHRoZSBwdWJsaWMga2V5LiAgIEluIHRob3NlIGNhc2VzIHRoZSBjbGllbnQgaXMgZG9p bmcgdGhlIGtleSBnZW4gaW4gaGFyZHdhcmUgc28gb25lIGhvcGVzIGl0IGlzIE9LLiAgIEluIHRo ZSBzeW1ldHJpYyBjYXNlIHRoZSBjbGllbnQgZ2VuZXJhdGluZyB0aGUga2V5IGlzIHdlYWtlciAo YXMgaW4gSSBjYW7igJl0IHRoaW5rIG9mIGFueSByZWFsbHkgZ29vZCByZWFzb24pLg0KDQoNCj4g T24gTm92IDUsIDIwMTUsIGF0IDE6MzUgUE0sIEp1c3RpbiBSaWNoZXIgPGpyaWNoZXJAbWl0LmVk dT4gd3JvdGU6DQo+IA0KPiBJ4oCZZCBhcmd1ZSB0aGF0IGl04oCZcyBiZXN0IHByYWN0aWNlLCBh bmQgaW4gbGluZSB3aXRoIG90aGVyIHBhcnRzIG9mIE9BdXRoLCBpZiB3ZSBhc3N1bWUgdGhlIHNl cnZlciBnZW5lcmF0ZXMgaXQgaW4gdGhlIG5vcm1hbCBjYXNlIChpc3N1ZXIgLT4gcHJlc2VudGVy KS4gQ2xpZW50IGdlbmVyYXRlZCB0b2tlbiBrZXlzIHNob3VsZCBiZSBhbiBleGNlcHRpb24sIGVz cGVjaWFsbHkgaW4gdGhlIGFzeW1tZXRyaWMgY2FzZS4NCj4gDQo+IOKAlCBKdXN0aW4NCj4gDQo+ PiBPbiBOb3YgNSwgMjAxNSwgYXQgMTozMiBQTSwgSm9obiBCcmFkbGV5IDx2ZTdqdGJAdmU3anRi LmNvbT4gd3JvdGU6DQo+PiANCj4+IEFncmVlZCB0aGUgb25seSByZWFsIGRpZmZlcmVuY2UgaXMg dGhlIHF1YWxpdHkgb2YgdGhlIGtleS4gIElmIHRoZSBzZXJ2ZXIgZ2VuZXJhdGVzIGl0LCB0aGVu IGl0IGtub3dzIHRoYXQgdGhlIGNsaWVudCBpcyBub3QgdXNpbmcgdGhlIGZpeGVkIGhleCB2YWx1 ZSBvZiBERUFEQkVFRiBmb3IgZXZlcnl0aGluZy4NCj4+IA0KPj4gSm9obiBCLg0KPj4+IE9uIE5v diA1LCAyMDE1LCBhdCA5OjI1IEFNLCBIYW5uZXMgVHNjaG9mZW5pZyA8aGFubmVzLnRzY2hvZmVu aWdAZ214Lm5ldD4gd3JvdGU6DQo+Pj4gDQo+Pj4gSSBhZ3JlZSB0aGF0IHRoZSBlZmZlY3QgaXMg dGhlIHNhbWUuIEZyb20gYSBzZWN1cml0eSBwb2ludCBvZiB2aWV3IA0KPj4+IHRoZXJlIGlzIG9u bHkgYW4gaW1wYWN0IGlmIG9uZSBvZiB0aGUgdHdvIHBhcnRpZXMgaXMgaW4gYSBiZXR0ZXIgDQo+ Pj4gcG9zaXRpb24gdG8gZ2VuZXJhdGUgcmFuZG9tIG51bWJlcnMsIHdoaWNoIGlzIHRoZSBiYXNp cyBmb3IgDQo+Pj4gZ2VuZXJhdGluZyBhIGhpZ2ggZW50cm9weSBzeW1tZXRyaWMga2V5Lg0KPj4+ IA0KPj4+IE9uIDExLzA0LzIwMTUgMTE6NTEgUE0sIE1pa2UgSm9uZXMgd3JvdGU6DQo+Pj4+IFRo YW5rcyBmb3IgdGhlIGRldGFpbGVkIHJlYWQsIEJyaWFuLiAgWW914oCZcmUgcmlnaHQgdGhhdCBp biB0aGUgDQo+Pj4+IHN5bW1ldHJpYyBjYXNlLCBlaXRoZXIgdGhlIGlzc3VlciBvciB0aGUgcHJl c2VudGVyIGNhbiBjcmVhdGUgdGhlIA0KPj4+PiBzeW1tZXRyaWMgUG9QIGtleSBhbmQgc2hhcmUg aXQgd2l0aCB0aGUgb3RoZXIgcGFydHksIHNpbmNlIHRoZSBlZmZlY3QgaXMgZXF1aXZhbGVudC4N Cj4+Pj4gSSBzdXNwZWN0IHRoYXQgYm90aCB0aGUga2V5IGRpc3RyaWJ1dGlvbiBkcmFmdCBhbmQg dGhpcyBkcmFmdCANCj4+Pj4gc2hvdWxkIGJlIHVwZGF0ZWQgd2l0aCBhIHNlbnRlbmNlIG9yIHR3 byBzYXlpbmcgdGhhdCBlaXRoZXIgDQo+Pj4+IGFwcHJvYWNoIGNhbiBiZSB0YWtlbi4gIERvIG90 aGVycyBjb25jdXI/DQo+Pj4+IA0KPj4+PiANCj4+Pj4gDQo+Pj4+ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCj4+Pj4gDQo+ Pj4+IA0KPj4+PiANCj4+Pj4gKkZyb206KkJyaWFuIENhbXBiZWxsIFttYWlsdG86YmNhbXBiZWxs QHBpbmdpZGVudGl0eS5jb21dDQo+Pj4+ICpTZW50OiogVGh1cnNkYXksIE5vdmVtYmVyIDA1LCAy MDE1IDc6NDggQU0NCj4+Pj4gKlRvOiogTWlrZSBKb25lcw0KPj4+PiAqQ2M6KiBLZXBlbmcgTGk7 IG9hdXRoQGlldGYub3JnDQo+Pj4+ICpTdWJqZWN0OiogUmU6IFtPQVVUSC1XR10gUHJvb2Ytb2Yt UG9zc2Vzc2lvbiBLZXkgU2VtYW50aWNzIGZvciANCj4+Pj4gSldUcyBzcGVjIGFkZHJlc3Npbmcg ZmluYWwgc2hlcGhlcmQgY29tbWVudA0KPj4+PiANCj4+Pj4gDQo+Pj4+IA0KPj4+PiArMSBmb3Ig dGhlIGRpYWdyYW1zIG1ha2luZyB0aGUgZG9jdW1lbnQgbW9yZSB1bmRlcnN0YW5kYWJsZS4NCj4+ Pj4gDQo+Pj4+IE9uZSBsaXR0bGUgbml0L3F1ZXN0aW9uLCBzdGVwIDEgaW4gYm90aCBTeW1tZXRy aWMgYW5kIEFzeW1tZXRyaWMgDQo+Pj4+IGtleXMgc2hvd3MgdGhlIFByZXNlbnRlciBzZW5kaW5n IHRoZSBrZXkgdG8gdGhlIElzc3Vlci4gSXQncyANCj4+Pj4gcG9zc2libGUsIGhvd2V2ZXIsIGZv ciB0aGUga2V5IHRvIGJlIHNlbnQgdGhlIG90aGVyIHdheS4gUHJlc2VudGVyIA0KPj4+PiBzZW5k aW5nIGl0IHRvIHRoZSBJc3N1ZXIgaXMgcHJvYmFibHkgcHJlZmVycmVkIGZvciBhc3ltbWV0cmlj LCANCj4+Pj4gZXNwZWNpYWxseSBpZiB0aGUgY2xpZW50IGNhbiBzZWN1cmUgdGhlIHByaXZhdGUg a2V5cyBpbiBoYXJkd2FyZS4gDQo+Pj4+IEJ1dCBJIGRvbid0IGtub3cgaWYgb25lIHdheSBvciB0 aGUgb3RoZXIgaXMgY2xlYXJseSBiZXR0ZXIgZm9yIA0KPj4+PiBzeW1tZXRyaWMgY2FzZSBhbmQg UG9QIGtleSBkaXN0cmlidXRpb24gY3VycmVudGx5IGhhcyBpdCB0aGUgb3RoZXIgDQo+Pj4+IHdh eSA8aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0 cHMlM2ElMmYlMmZ0b29scy5pZXRmLm9yZyUyZmh0bWwlMmZkcmFmdC1pZXRmLW9hdXRoLXBvcC1r ZXktZGlzdHJpYnV0aW9uLTAyJTIzc2VjdGlvbi00LjImZGF0YT0wMSU3YzAxJTdjdG9ueW5hZCU0 MG1pY3Jvc29mdC5jb20lN2M5NDU2NjcwMDc1ZDA0YTUxZjg1NTA4ZDJlNTliYTI5NCU3YzcyZjk4 OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZzZGF0YT1VZ1pFb3FRaWFVazlWZFlwU1FS dlVlVlZPUWdJVWczVW1BcjE4b1E3R3RJJTNkPi4NCj4+Pj4gU2hvdWxkIHRoZSBpbnRybyB0ZXh0 IHNvbWVob3cgbWVudGlvbiB0aGUgcG9zc2liaWxpdHkgdGhhdCB0aGUgDQo+Pj4+IElzc3VlciBj b3VsZCBjcmVhdGUgdGhlIGtleSBhbmQgc2VuZCBpdCB0byB0aGUgUHJlc2VudGVyPw0KPj4+PiAN Cj4+Pj4gSSBrbm93IGl0J3Mgb25seSB0aGUgaW50cm9kdWN0aW9uIGJ1dCBpdCB3YXMganVzdCBz b21ldGhpbmcgdGhhdCANCj4+Pj4ganVtcGVkIG91dCBhdCBtZS4NCj4+Pj4gDQo+Pj4+IA0KPj4+ PiANCj4+Pj4gDQo+Pj4+IA0KPj4+PiBPbiBXZWQsIE5vdiA0LCAyMDE1IGF0IDk6MDQgQU0sIE1p a2UgSm9uZXMgDQo+Pj4+IDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20gPG1haWx0bzpNaWNo YWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+PiB3cm90ZToNCj4+Pj4gDQo+Pj4+IFRoYW5rcyBmb3Ig c3VnZ2VzdGluZyB0aGUgZGlhZ3JhbXMsIEtlcGVuZy4gVGhleSBtYWtlIHRoZSBkb2N1bWVudCAN Cj4+Pj4gbW9yZSB1bmRlcnN0YW5kYWJsZS4NCj4+Pj4gDQo+Pj4+IC0tIE1pa2UNCj4+Pj4gDQo+ Pj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCj4+Pj4gLS0tLS0NCj4+Pj4gDQo+Pj4+ICpGcm9tOiAqS2VwZW5nIExp IDxtYWlsdG86a2VwZW5nLmxrcEBhbGliYWJhLWluYy5jb20+DQo+Pj4+ICpTZW50OiAq4oCOMTEv 4oCONS/igI4yMDE1IDEyOjU3IEFNDQo+Pj4+ICpUbzogKk1pa2UgSm9uZXMgPG1haWx0bzpNaWNo YWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+OyANCj4+Pj4gb2F1dGhAaWV0Zi5vcmcgPG1haWx0bzpv YXV0aEBpZXRmLm9yZz4NCj4+Pj4gKlN1YmplY3Q6ICpSZTogUHJvb2Ytb2YtUG9zc2Vzc2lvbiBL ZXkgU2VtYW50aWNzIGZvciBKV1RzIHNwZWMgDQo+Pj4+IGFkZHJlc3NpbmcgZmluYWwgc2hlcGhl cmQgY29tbWVudA0KPj4+PiANCj4+Pj4gVGhhbmsgeW91IE1pa2UuDQo+Pj4+IA0KPj4+PiANCj4+ Pj4gDQo+Pj4+IFRoZSBkaWFncmFtcyBsb29rIGdvb2QgdG8gbWUuDQo+Pj4+IA0KPj4+PiANCj4+ Pj4gDQo+Pj4+IEtpbmQgUmVnYXJkcw0KPj4+PiANCj4+Pj4gS2VwZW5nDQo+Pj4+IA0KPj4+PiAN Cj4+Pj4gDQo+Pj4+ICrlj5Hku7bkuroqKjogKk1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWlj cm9zb2Z0LmNvbSANCj4+Pj4gPG1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+Pg0K Pj4+PiAq5pel5pyfKio6ICpUaHVyc2RheSwgNSBOb3ZlbWJlciwgMjAxNSAxMjozMiBhbQ0KPj4+ PiAq6IezKio6ICoib2F1dGhAaWV0Zi5vcmcgPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4iIDxvYXV0 aEBpZXRmLm9yZyANCj4+Pj4gPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4+DQo+Pj4+ICrmioTpgIEq KjogKkxpIEtlcGVuZyA8a2VwZW5nLmxrcEBhbGliYWJhLWluYy5jb20gDQo+Pj4+IDxtYWlsdG86 a2VwZW5nLmxrcEBhbGliYWJhLWluYy5jb20+Pg0KPj4+PiAq5Li76aKYKio6ICpQcm9vZi1vZi1Q b3NzZXNzaW9uIEtleSBTZW1hbnRpY3MgZm9yIEpXVHMgc3BlYyBhZGRyZXNzaW5nIA0KPj4+PiBm aW5hbCBzaGVwaGVyZCBjb21tZW50DQo+Pj4+IA0KPj4+PiANCj4+Pj4gDQo+Pj4+IFByb29mLW9m LVBvc3Nlc3Npb24gS2V5IFNlbWFudGljcyBmb3IgSldUcyBkcmFmdCAtMDYgYWRkcmVzc2VzIHRo ZSANCj4+Pj4gcmVtYWluaW5nIGRvY3VtZW50IHNoZXBoZXJkIGNvbW1lbnQg4oCTIGFkZGluZyB1 c2UgY2FzZSBkaWFncmFtcyB0byANCj4+Pj4gdGhlIGludHJvZHVjdGlvbi4NCj4+Pj4gDQo+Pj4+ IA0KPj4+PiANCj4+Pj4gVGhlIHVwZGF0ZWQgc3BlY2lmaWNhdGlvbiBpcyBhdmFpbGFibGUgYXQ6 DQo+Pj4+IA0KPj4+PiDCtyAgICAgICAgaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9u Lm91dGxvb2suY29tLz91cmw9aHR0cCUzYSUyZiUyZnRvb2xzLmlldGYub3JnJTJmaHRtbCUyZmRy YWZ0LWlldGYtb2F1dGgtcHJvb2Ytb2YtcG9zc2Vzc2lvbi0wNiZkYXRhPTAxJTdjMDElN2N0b255 bmFkJTQwbWljcm9zb2Z0LmNvbSU3Yzk0NTY2NzAwNzVkMDRhNTFmODU1MDhkMmU1OWJhMjk0JTdj NzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJnNkYXRhPTZoRTZkT08wSTElMmZm RjAwNXJWa255T0ZIdUIxOGdkcFpnOWRmdEV4THRDdyUzZA0KPj4+PiANCj4+Pj4gDQo+Pj4+IA0K Pj4+PiBBbiBIVE1MIGZvcm1hdHRlZCB2ZXJzaW9uIGlzIGFsc28gYXZhaWxhYmxlIGF0Og0KPj4+ PiANCj4+Pj4gwrcgICAgICAgDQo+Pj4+IGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlv bi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJmc2UNCj4+Pj4gbGYtaXNzdWVkLmluZm8l MmZkb2NzJTJmZHJhZnQtaWV0Zi1vYXV0aC1wcm9vZi1vZi1wb3NzZXNzaW9uLTA2Lmh0bQ0KPj4+ PiBsJmRhdGE9MDElN2MwMSU3Y3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdjOTQ1NjY3MDA3NWQw NGE1MWY4NTUwOGQyDQo+Pj4+IGU1OWJhMjk0JTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAx MWRiNDclN2MxJnNkYXRhPUVRZDRyVWN1eXFkU1ANCj4+Pj4gZ21pYnRjZmpNcEptNlJXV3dDWkM4 NSUyYkNib0VzNTQlM2QNCj4+Pj4gDQo+Pj4+IA0KPj4+PiANCj4+Pj4gICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KPj4+PiAN Cj4+Pj4gDQo+Pj4+IA0KPj4+PiBQLlMuICBUaGlzIG5vdGUgd2FzIGFsc28gcG9zdGVkIGF0IA0K Pj4+PiBodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1o dHRwJTNhJTJmJTJmc2VsZi1pc3N1ZWQuaW5mbyUyZiUzZnAlM2QxNDcxJmRhdGE9MDElN2MwMSU3 Y3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdjOTQ1NjY3MDA3NWQwNGE1MWY4NTUwOGQyZTU5YmEy OTQlN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmc2RhdGE9VE1mWDF0RzVx dWNsJTJiZTJLVnB5TUJ1ajcyWlElMmYlMmJFS0dvVHlKeWYlMmJmSmk0JTNkIGFuZCBhcyBAc2Vs Zmlzc3VlZCA8aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91 cmw9aHR0cHMlM2ElMmYlMmZ0d2l0dGVyLmNvbSUyZnNlbGZpc3N1ZWQmZGF0YT0wMSU3YzAxJTdj dG9ueW5hZCU0MG1pY3Jvc29mdC5jb20lN2M5NDU2NjcwMDc1ZDA0YTUxZjg1NTA4ZDJlNTliYTI5 NCU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZzZGF0YT1MZkZBamNoekNU aDB4JTJmWTlocjBXJTJmU29oUEdnYjBKVmpMJTJmMkF6JTJmMTJCQ2clM2Q+Lg0KPj4+PiANCj4+ Pj4gDQo+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+Pj4+IE9BdXRoIG1haWxpbmcgbGlzdA0KPj4+PiBPQXV0aEBpZXRmLm9yZyA8bWFpbHRvOk9B dXRoQGlldGYub3JnPiANCj4+Pj4gaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91 dGxvb2suY29tLz91cmw9aHR0cHMlM2ElMmYlMmZ3dw0KPj4+PiB3LmlldGYub3JnJTJmbWFpbG1h biUyZmxpc3RpbmZvJTJmb2F1dGgmZGF0YT0wMSU3YzAxJTdjdG9ueW5hZCU0MG1pDQo+Pj4+IGNy b3NvZnQuY29tJTdjOTQ1NjY3MDA3NWQwNGE1MWY4NTUwOGQyZTU5YmEyOTQlN2M3MmY5ODhiZjg2 ZjE0MWFmOTENCj4+Pj4gYWIyZDdjZDAxMWRiNDclN2MxJnNkYXRhPU5EM3lkYVhPc1BNc29SaEUw VXlxMHV6bkd5Nk1kWU9MWlFKSExoRVFLSg0KPj4+PiBzJTNkDQo+Pj4+IA0KPj4+PiANCj4+Pj4g DQo+Pj4+IA0KPj4+PiANCj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4+Pj4gT0F1dGggbWFpbGluZyBsaXN0DQo+Pj4+IE9BdXRoQGlldGYub3Jn DQo+Pj4+IGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJs PWh0dHBzJTNhJTJmJTJmd3cNCj4+Pj4gdy5pZXRmLm9yZyUyZm1haWxtYW4lMmZsaXN0aW5mbyUy Zm9hdXRoJmRhdGE9MDElN2MwMSU3Y3RvbnluYWQlNDBtaQ0KPj4+PiBjcm9zb2Z0LmNvbSU3Yzk0 NTY2NzAwNzVkMDRhNTFmODU1MDhkMmU1OWJhMjk0JTdjNzJmOTg4YmY4NmYxNDFhZjkxDQo+Pj4+ IGFiMmQ3Y2QwMTFkYjQ3JTdjMSZzZGF0YT1ORDN5ZGFYT3NQTXNvUmhFMFV5cTB1em5HeTZNZFlP TFpRSkhMaEVRS0oNCj4+Pj4gcyUzZA0KPj4+PiANCj4+PiANCj4+PiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+IE9BdXRoIG1haWxpbmcgbGlzdA0K Pj4+IE9BdXRoQGlldGYub3JnDQo+Pj4gaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9u Lm91dGxvb2suY29tLz91cmw9aHR0cHMlM2ElMmYlMmZ3d3cNCj4+PiAuaWV0Zi5vcmclMmZtYWls bWFuJTJmbGlzdGluZm8lMmZvYXV0aCZkYXRhPTAxJTdjMDElN2N0b255bmFkJTQwbWljcg0KPj4+ IG9zb2Z0LmNvbSU3Yzk0NTY2NzAwNzVkMDRhNTFmODU1MDhkMmU1OWJhMjk0JTdjNzJmOTg4YmY4 NmYxNDFhZjkxYWIyDQo+Pj4gZDdjZDAxMWRiNDclN2MxJnNkYXRhPU5EM3lkYVhPc1BNc29SaEUw VXlxMHV6bkd5Nk1kWU9MWlFKSExoRVFLSnMlM2QNCj4+IA0KPj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IE9BdXRoIG1haWxpbmcgbGlzdA0KPj4g T0F1dGhAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRs b29rLmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJmd3d3Lg0KPj4gaWV0Zi5vcmclMmZtYWlsbWFuJTJm bGlzdGluZm8lMmZvYXV0aCZkYXRhPTAxJTdjMDElN2N0b255bmFkJTQwbWljcm9zDQo+PiBvZnQu Y29tJTdjOTQ1NjY3MDA3NWQwNGE1MWY4NTUwOGQyZTU5YmEyOTQlN2M3MmY5ODhiZjg2ZjE0MWFm OTFhYjJkN2MNCj4+IGQwMTFkYjQ3JTdjMSZzZGF0YT1ORDN5ZGFYT3NQTXNvUmhFMFV5cTB1em5H eTZNZFlPTFpRSkhMaEVRS0pzJTNkDQo+IA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZw0K aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMl M2ElMmYlMmZ3d3cuaWV0Zi5vcmclMmZtYWlsbWFuJTJmbGlzdGluZm8lMmZvYXV0aCUwYSZkYXRh PTAxJTdjMDElN2N0b255bmFkJTQwbWljcm9zb2Z0LmNvbSU3Yzk0NTY2NzAwNzVkMDRhNTFmODU1 MDhkMmU1OWJhMjk0JTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJnNkYXRh PUJMcVN1RGpXTFk3MmZHbTBVcnBMd3hRVm5hbU1lbGdnSmVPcFlKRVNWRnMlM2QNCg== From nobody Wed Nov 4 20:48:17 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81B561B38EB for ; Wed, 4 Nov 2015 20:48:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AtsP8als3Tuf for ; Wed, 4 Nov 2015 20:48:07 -0800 (PST) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 193391B3643 for ; Wed, 4 Nov 2015 20:48:06 -0800 (PST) X-AuditID: 12074425-f79816d000004571-fa-563adf85d8a8 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 42.B3.17777.58FDA365; Wed, 4 Nov 2015 23:48:05 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id tA54m4M7018967; Wed, 4 Nov 2015 23:48:05 -0500 Received: from dhcp-29-147.meeting.ietf94.jp (dhcp-29-147.meeting.ietf94.jp [133.93.29.147]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id tA54m045012067 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 4 Nov 2015 23:48:03 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Justin Richer In-Reply-To: Date: Thu, 5 Nov 2015 13:47:59 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <563AA216.5010109@gmx.net> <89A6E4DE-263B-4DB4-8882-54FA7103C721@mit.edu> <82079E8A-2AC8-4A42-9AF7-77FF2A3CAFC2@ve7jtb.com> To: Anthony Nadalin X-Mailer: Apple Mail (2.2104) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmleLIzCtJLcpLzFFi42IRYrdT0W29bxVmcPK/tsXJt6/YLDbN3cZo sfruXzYHZo8lS34yebTu+Mvucfv2RpYA5igum5TUnMyy1CJ9uwSujHdfdjIVzAuoWHu6gaWB 8YpLFyMnh4SAicSOMw9ZIGwxiQv31rN1MXJxCAksZpJYdfgGO4SzgVHi+6GjUJkbTBI3m8+x gbQwC6hL/Jl3iRnE5hXQk3h16zIriC0skCnx+nAPWJxNQFVi+poWJhCbUyBR4srPZ2C9LAIq Ei+WHWWFmOMpsefZBUYIW1ti2cLXQL0cQDOtJHZPcIfY+4ZF4tHR5WC9IkA1J96vZIY4W1Zi 9+9HTBMYBWchOWkWkpNmIRm7gJF5FaNsSm6Vbm5iZk5xarJucXJiXl5qka6FXm5miV5qSukm RnBYu6juYJxwSOkQowAHoxIPr0G1VZgQa2JZcWXuIUZJDiYlUV6rc0AhvqT8lMqMxOKM+KLS nNTiQ4wSHMxKIrwFM4FyvCmJlVWpRfkwKWkOFiVx3k0/+EKEBNITS1KzU1MLUotgsjIcHEoS vL73gBoFi1LTUyvSMnNKENJMHJwgw3mAht+9CzK8uCAxtzgzHSJ/ilFRSpz3JEhCACSRUZoH 1wtKO62xspNfMYoDvSLMmwWyggeYsuC6XwENZgIazNRqATK4JBEhJdXAaJ8nsFT4S2312qJZ DZ+qErfLbzr8YrLmrlu9X+94Pp71z/tH8ufSsMbY3dk/t4q8+qh96+KffTtObayR0jGacvNf UWHX3tgTehItsR+Oqm2JTl8mwdl8R/lshn3lJtdb77Ly1zRXH9EMmu/A1ZQd+d7AqudIbY5J xX72+8HBeqec9+x7kXhXWImlOCPRUIu5qDgRAJimuw8WAwAA Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 04:48:11 -0000 That=E2=80=99s only if you=E2=80=99re using good hardware to produce a = key. We can=E2=80=99t assume that=E2=80=99s the only kind of client that = will exist, and software generation is likely to be much more common for = a while yet. Perhaps what we really need is strong guidance on when to use which = approach. =E2=80=9CIf you client has a strong random generator function = then you can make your own key, but otherwise let the server do it for = you." =E2=80=94 Justin > On Nov 5, 2015, at 1:45 PM, Anthony Nadalin = wrote: >=20 > Not sure why you think its weaker as it would be a wrapped key that = the hardware produces=20 >=20 > -----Original Message----- > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of John Bradley > Sent: Wednesday, November 4, 2015 8:43 PM > To: Justin Richer > Cc: > Subject: Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs = spec addressing final shepherd comment >=20 > In the asymmetric case the use of a HSM or secure element is the = argument for the client selecting the public key. In those cases the = client is doing the key gen in hardware so one hopes it is OK. In the = symetric case the client generating the key is weaker (as in I can=E2=80=99= t think of any really good reason). >=20 >=20 >> On Nov 5, 2015, at 1:35 PM, Justin Richer wrote: >>=20 >> I=E2=80=99d argue that it=E2=80=99s best practice, and in line with = other parts of OAuth, if we assume the server generates it in the normal = case (issuer -> presenter). Client generated token keys should be an = exception, especially in the asymmetric case. >>=20 >> =E2=80=94 Justin >>=20 >>> On Nov 5, 2015, at 1:32 PM, John Bradley wrote: >>>=20 >>> Agreed the only real difference is the quality of the key. If the = server generates it, then it knows that the client is not using the = fixed hex value of DEADBEEF for everything. >>>=20 >>> John B. >>>> On Nov 5, 2015, at 9:25 AM, Hannes Tschofenig = wrote: >>>>=20 >>>> I agree that the effect is the same. =46rom a security point of = view=20 >>>> there is only an impact if one of the two parties is in a better=20 >>>> position to generate random numbers, which is the basis for=20 >>>> generating a high entropy symmetric key. >>>>=20 >>>> On 11/04/2015 11:51 PM, Mike Jones wrote: >>>>> Thanks for the detailed read, Brian. You=E2=80=99re right that in = the=20 >>>>> symmetric case, either the issuer or the presenter can create the=20= >>>>> symmetric PoP key and share it with the other party, since the = effect is equivalent. >>>>> I suspect that both the key distribution draft and this draft=20 >>>>> should be updated with a sentence or two saying that either=20 >>>>> approach can be taken. Do others concur? >>>>>=20 >>>>>=20 >>>>>=20 >>>>> -- Mike >>>>>=20 >>>>>=20 >>>>>=20 >>>>> *From:*Brian Campbell [mailto:bcampbell@pingidentity.com] >>>>> *Sent:* Thursday, November 05, 2015 7:48 AM >>>>> *To:* Mike Jones >>>>> *Cc:* Kepeng Li; oauth@ietf.org >>>>> *Subject:* Re: [OAUTH-WG] Proof-of-Possession Key Semantics for=20 >>>>> JWTs spec addressing final shepherd comment >>>>>=20 >>>>>=20 >>>>>=20 >>>>> +1 for the diagrams making the document more understandable. >>>>>=20 >>>>> One little nit/question, step 1 in both Symmetric and Asymmetric=20= >>>>> keys shows the Presenter sending the key to the Issuer. It's=20 >>>>> possible, however, for the key to be sent the other way. Presenter=20= >>>>> sending it to the Issuer is probably preferred for asymmetric,=20 >>>>> especially if the client can secure the private keys in hardware.=20= >>>>> But I don't know if one way or the other is clearly better for=20 >>>>> symmetric case and PoP key distribution currently has it the other=20= >>>>> way = . >>>>> Should the intro text somehow mention the possibility that the=20 >>>>> Issuer could create the key and send it to the Presenter? >>>>>=20 >>>>> I know it's only the introduction but it was just something that=20= >>>>> jumped out at me. >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On Wed, Nov 4, 2015 at 9:04 AM, Mike Jones=20 >>>>> > = wrote: >>>>>=20 >>>>> Thanks for suggesting the diagrams, Kepeng. They make the document=20= >>>>> more understandable. >>>>>=20 >>>>> -- Mike >>>>>=20 >>>>> = ------------------------------------------------------------------- >>>>> ----- >>>>>=20 >>>>> *From: *Kepeng Li >>>>> *Sent: *=E2=80=8E11/=E2=80=8E5/=E2=80=8E2015 12:57 AM >>>>> *To: *Mike Jones ;=20 >>>>> oauth@ietf.org >>>>> *Subject: *Re: Proof-of-Possession Key Semantics for JWTs spec=20 >>>>> addressing final shepherd comment >>>>>=20 >>>>> Thank you Mike. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> The diagrams look good to me. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Kind Regards >>>>>=20 >>>>> Kepeng >>>>>=20 >>>>>=20 >>>>>=20 >>>>> *=E5=8F=91=E4=BB=B6=E4=BA=BA**: *Mike Jones = >>>> > >>>>> *=E6=97=A5=E6=9C=9F**: *Thursday, 5 November, 2015 12:32 am >>>>> *=E8=87=B3**: *"oauth@ietf.org " = >>>> > >>>>> *=E6=8A=84=E9=80=81**: *Li Kepeng >>>> > >>>>> *=E4=B8=BB=E9=A2=98**: *Proof-of-Possession Key Semantics for JWTs = spec addressing=20 >>>>> final shepherd comment >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Proof-of-Possession Key Semantics for JWTs draft -06 addresses the=20= >>>>> remaining document shepherd comment =E2=80=93 adding use case = diagrams to=20 >>>>> the introduction. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> The updated specification is available at: >>>>>=20 >>>>> =C2=B7 = https://na01.safelinks.protection.outlook.com/?url=3Dhttp%3a%2f%2ftools.ie= tf.org%2fhtml%2fdraft-ietf-oauth-proof-of-possession-06&data=3D01%7c01%7ct= onynad%40microsoft.com%7c9456670075d04a51f85508d2e59ba294%7c72f988bf86f141= af91ab2d7cd011db47%7c1&sdata=3D6hE6dOO0I1%2ffF005rVknyOFHuB18gdpZg9dftExLt= Cw%3d >>>>>=20 >>>>>=20 >>>>>=20 >>>>> An HTML formatted version is also available at: >>>>>=20 >>>>> =C2=B7 =20 >>>>> = https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fse >>>>> = lf-issued.info%2fdocs%2fdraft-ietf-oauth-proof-of-possession-06.htm >>>>> = l&data=3D01%7c01%7ctonynad%40microsoft.com%7c9456670075d04a51f85508d2 >>>>> = e59ba294%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=3DEQd4rUcuyqdSP >>>>> gmibtcfjMpJm6RWWwCZC85%2bCboEs54%3d >>>>>=20 >>>>>=20 >>>>>=20 >>>>> -- Mike >>>>>=20 >>>>>=20 >>>>>=20 >>>>> P.S. This note was also posted at=20 >>>>> = https://na01.safelinks.protection.outlook.com/?url=3Dhttp%3a%2f%2fself-iss= ued.info%2f%3fp%3d1471&data=3D01%7c01%7ctonynad%40microsoft.com%7c94566700= 75d04a51f85508d2e59ba294%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=3DTM= fX1tG5qucl%2be2KVpyMBuj72ZQ%2f%2bEKGoTyJyf%2bfJi4%3d and as @selfissued = . >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org =20 >>>>> = https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fww >>>>> = w.ietf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonynad%40mi >>>>> = crosoft.com%7c9456670075d04a51f85508d2e59ba294%7c72f988bf86f141af91 >>>>> = ab2d7cd011db47%7c1&sdata=3DND3ydaXOsPMsoRhE0Uyq0uznGy6MdYOLZQJHLhEQKJ >>>>> s%3d >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> = https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fww >>>>> = w.ietf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonynad%40mi >>>>> = crosoft.com%7c9456670075d04a51f85508d2e59ba294%7c72f988bf86f141af91 >>>>> = ab2d7cd011db47%7c1&sdata=3DND3ydaXOsPMsoRhE0Uyq0uznGy6MdYOLZQJHLhEQKJ >>>>> s%3d >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> = https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww >>>> = .ietf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonynad%40micr >>>> = osoft.com%7c9456670075d04a51f85508d2e59ba294%7c72f988bf86f141af91ab2 >>>> = d7cd011db47%7c1&sdata=3DND3ydaXOsPMsoRhE0Uyq0uznGy6MdYOLZQJHLhEQKJs%3d >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> = https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww. >>> = ietf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonynad%40micros >>> = oft.com%7c9456670075d04a51f85508d2e59ba294%7c72f988bf86f141af91ab2d7c >>> d011db47%7c1&sdata=3DND3ydaXOsPMsoRhE0Uyq0uznGy6MdYOLZQJHLhEQKJs%3d >>=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > = https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.iet= f.org%2fmailman%2flistinfo%2foauth%0a&data=3D01%7c01%7ctonynad%40microsoft= .com%7c9456670075d04a51f85508d2e59ba294%7c72f988bf86f141af91ab2d7cd011db47= %7c1&sdata=3DBLqSuDjWLY72fGm0UrpLwxQVnamMelggJeOpYJESVFs%3d From nobody Wed Nov 4 20:51:51 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D53101A911A for ; Wed, 4 Nov 2015 20:51:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BCHtQ1PrQv67 for ; Wed, 4 Nov 2015 20:51:44 -0800 (PST) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::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 AEDD41A1A4B for ; Wed, 4 Nov 2015 20:51:44 -0800 (PST) Received: by padhx2 with SMTP id hx2so67048468pad.1 for ; Wed, 04 Nov 2015 20:51:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb_com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=0BiZ6g7D5IgDQ8j9UzhcX6YaG+TBz4KCnIKiYbpFmXc=; b=yvZawJMlGPqQZKFZocqTOBF0nzKzE67wzt7rMcb90MA6O6AnORfuGCcv4Yj3s9Z1sD zpKyi/FxC423vNlkszxycqGoGHfYjTGNMI3vRe8I6+6W3A5llNs/rfGIZfEQHr94eO8B DQMdkKXZFaUEZTOAu++wfgTu+AnL2DwIg9d+vpYJ2vtM0ZhzGTm+/t3R7jdD1voDaQkP RZBE3dWnooE5/pgfmdVUKAxYZ0VJapPvrpYsc9Dh8Eh103jyNpkBiIolXhTJVutFpDKI HLSJlNOaVizUHth7H+ObjhMwSJ1hqegCbOAI/losWZMbOBO1xxJVZJqdRKDqKMweAL2V jAHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=0BiZ6g7D5IgDQ8j9UzhcX6YaG+TBz4KCnIKiYbpFmXc=; b=C4M/OH4sGEfxO7A2BvfiiB6JnhkxVR67nVEsUuJrlOmUwYfOFxU8jMOFFN3u8mffOP 39rFfQv/ScELujo342JR3lEukeKx3Omps6mp2bznx1yE9kYqOv91X8ZXclyfYYm0VO/X N3N+x1QHizjlMEtiiWLtPfZgBwQw1reCcVTNVE1boXq4MCGlKQi3v8RilaBGqoeRNP+0 LMHm92PJ7e2p0T+mhDQCmbnlb5OQbnA2FwPdl4hGGQfpvgPNq1rnRDe/VsjdGUl4tGgq 3LJ29eZGSlNT0m/6KIbwkSqrZjBwrlUkGu9ICGcohrTcrcK7McrzziHIR8ii/8/vEFUP LY3g== X-Gm-Message-State: ALoCoQkSZfbCAY58wxzVHZLvdDZ47Df2OAbH+rxHjwbgE5itMYtNHCA1e7pUNKKzIa3bS12TSr3Y X-Received: by 10.68.132.71 with SMTP id os7mr6862645pbb.125.1446699104267; Wed, 04 Nov 2015 20:51:44 -0800 (PST) Received: from t20010c40000030089044b9d401462547.v6.meeting.ietf94.jp (t20010c40000030089044b9d401462547.v6.meeting.ietf94.jp. [2001:c40:0:3008:9044:b9d4:146:2547]) by smtp.gmail.com with ESMTPSA id bs3sm5024053pbd.89.2015.11.04.20.51.42 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Nov 2015 20:51:43 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: John Bradley In-Reply-To: Date: Thu, 5 Nov 2015 13:51:43 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <9E23AF3A-F758-4CB4-B920-4E1E2F61BCF4@ve7jtb.com> References: <563AA216.5010109@gmx.net> <89A6E4DE-263B-4DB4-8882-54FA7103C721@mit.edu> <82079E8A-2AC8-4A42-9AF7-77FF2A3CAFC2@ve7jtb.com> To: Anthony Nadalin X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 04:51:48 -0000 OK, no good reason unless the client is using a HSM that can do HMAC and = can export a symmetric key wrapped in a asymmetric key provided by the = AS. We don=E2=80=99t currently cover that use case of sending a wrapped = symmetric key to the AS in POP key distribution. =20 I don=E2=80=99t know how common that is going to be, but it is worth = thinking about defining. John B. > On Nov 5, 2015, at 1:45 PM, Anthony Nadalin = wrote: >=20 > Not sure why you think its weaker as it would be a wrapped key that = the hardware produces=20 >=20 > -----Original Message----- > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of John Bradley > Sent: Wednesday, November 4, 2015 8:43 PM > To: Justin Richer > Cc: > Subject: Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs = spec addressing final shepherd comment >=20 > In the asymmetric case the use of a HSM or secure element is the = argument for the client selecting the public key. In those cases the = client is doing the key gen in hardware so one hopes it is OK. In the = symetric case the client generating the key is weaker (as in I can=E2=80=99= t think of any really good reason). >=20 >=20 >> On Nov 5, 2015, at 1:35 PM, Justin Richer wrote: >>=20 >> I=E2=80=99d argue that it=E2=80=99s best practice, and in line with = other parts of OAuth, if we assume the server generates it in the normal = case (issuer -> presenter). Client generated token keys should be an = exception, especially in the asymmetric case. >>=20 >> =E2=80=94 Justin >>=20 >>> On Nov 5, 2015, at 1:32 PM, John Bradley wrote: >>>=20 >>> Agreed the only real difference is the quality of the key. If the = server generates it, then it knows that the client is not using the = fixed hex value of DEADBEEF for everything. >>>=20 >>> John B. >>>> On Nov 5, 2015, at 9:25 AM, Hannes Tschofenig = wrote: >>>>=20 >>>> I agree that the effect is the same. =46rom a security point of = view=20 >>>> there is only an impact if one of the two parties is in a better=20 >>>> position to generate random numbers, which is the basis for=20 >>>> generating a high entropy symmetric key. >>>>=20 >>>> On 11/04/2015 11:51 PM, Mike Jones wrote: >>>>> Thanks for the detailed read, Brian. You=E2=80=99re right that in = the=20 >>>>> symmetric case, either the issuer or the presenter can create the=20= >>>>> symmetric PoP key and share it with the other party, since the = effect is equivalent. >>>>> I suspect that both the key distribution draft and this draft=20 >>>>> should be updated with a sentence or two saying that either=20 >>>>> approach can be taken. Do others concur? >>>>>=20 >>>>>=20 >>>>>=20 >>>>> -- Mike >>>>>=20 >>>>>=20 >>>>>=20 >>>>> *From:*Brian Campbell [mailto:bcampbell@pingidentity.com] >>>>> *Sent:* Thursday, November 05, 2015 7:48 AM >>>>> *To:* Mike Jones >>>>> *Cc:* Kepeng Li; oauth@ietf.org >>>>> *Subject:* Re: [OAUTH-WG] Proof-of-Possession Key Semantics for=20 >>>>> JWTs spec addressing final shepherd comment >>>>>=20 >>>>>=20 >>>>>=20 >>>>> +1 for the diagrams making the document more understandable. >>>>>=20 >>>>> One little nit/question, step 1 in both Symmetric and Asymmetric=20= >>>>> keys shows the Presenter sending the key to the Issuer. It's=20 >>>>> possible, however, for the key to be sent the other way. Presenter=20= >>>>> sending it to the Issuer is probably preferred for asymmetric,=20 >>>>> especially if the client can secure the private keys in hardware.=20= >>>>> But I don't know if one way or the other is clearly better for=20 >>>>> symmetric case and PoP key distribution currently has it the other=20= >>>>> way = . >>>>> Should the intro text somehow mention the possibility that the=20 >>>>> Issuer could create the key and send it to the Presenter? >>>>>=20 >>>>> I know it's only the introduction but it was just something that=20= >>>>> jumped out at me. >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On Wed, Nov 4, 2015 at 9:04 AM, Mike Jones=20 >>>>> > = wrote: >>>>>=20 >>>>> Thanks for suggesting the diagrams, Kepeng. They make the document=20= >>>>> more understandable. >>>>>=20 >>>>> -- Mike >>>>>=20 >>>>> = ------------------------------------------------------------------- >>>>> ----- >>>>>=20 >>>>> *From: *Kepeng Li >>>>> *Sent: *=E2=80=8E11/=E2=80=8E5/=E2=80=8E2015 12:57 AM >>>>> *To: *Mike Jones ;=20 >>>>> oauth@ietf.org >>>>> *Subject: *Re: Proof-of-Possession Key Semantics for JWTs spec=20 >>>>> addressing final shepherd comment >>>>>=20 >>>>> Thank you Mike. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> The diagrams look good to me. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Kind Regards >>>>>=20 >>>>> Kepeng >>>>>=20 >>>>>=20 >>>>>=20 >>>>> *=E5=8F=91=E4=BB=B6=E4=BA=BA**: *Mike Jones = >>>> > >>>>> *=E6=97=A5=E6=9C=9F**: *Thursday, 5 November, 2015 12:32 am >>>>> *=E8=87=B3**: *"oauth@ietf.org " = >>>> > >>>>> *=E6=8A=84=E9=80=81**: *Li Kepeng >>>> > >>>>> *=E4=B8=BB=E9=A2=98**: *Proof-of-Possession Key Semantics for JWTs = spec addressing=20 >>>>> final shepherd comment >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Proof-of-Possession Key Semantics for JWTs draft -06 addresses the=20= >>>>> remaining document shepherd comment =E2=80=93 adding use case = diagrams to=20 >>>>> the introduction. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> The updated specification is available at: >>>>>=20 >>>>> =C2=B7 = https://na01.safelinks.protection.outlook.com/?url=3Dhttp%3a%2f%2ftools.ie= tf.org%2fhtml%2fdraft-ietf-oauth-proof-of-possession-06&data=3D01%7c01%7ct= onynad%40microsoft.com%7c9456670075d04a51f85508d2e59ba294%7c72f988bf86f141= af91ab2d7cd011db47%7c1&sdata=3D6hE6dOO0I1%2ffF005rVknyOFHuB18gdpZg9dftExLt= Cw%3d >>>>>=20 >>>>>=20 >>>>>=20 >>>>> An HTML formatted version is also available at: >>>>>=20 >>>>> =C2=B7 =20 >>>>> = https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fse >>>>> = lf-issued.info%2fdocs%2fdraft-ietf-oauth-proof-of-possession-06.htm >>>>> = l&data=3D01%7c01%7ctonynad%40microsoft.com%7c9456670075d04a51f85508d2 >>>>> = e59ba294%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=3DEQd4rUcuyqdSP >>>>> gmibtcfjMpJm6RWWwCZC85%2bCboEs54%3d >>>>>=20 >>>>>=20 >>>>>=20 >>>>> -- Mike >>>>>=20 >>>>>=20 >>>>>=20 >>>>> P.S. This note was also posted at=20 >>>>> = https://na01.safelinks.protection.outlook.com/?url=3Dhttp%3a%2f%2fself-iss= ued.info%2f%3fp%3d1471&data=3D01%7c01%7ctonynad%40microsoft.com%7c94566700= 75d04a51f85508d2e59ba294%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=3DTM= fX1tG5qucl%2be2KVpyMBuj72ZQ%2f%2bEKGoTyJyf%2bfJi4%3d and as @selfissued = . >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org =20 >>>>> = https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fww >>>>> = w.ietf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonynad%40mi >>>>> = crosoft.com%7c9456670075d04a51f85508d2e59ba294%7c72f988bf86f141af91 >>>>> = ab2d7cd011db47%7c1&sdata=3DND3ydaXOsPMsoRhE0Uyq0uznGy6MdYOLZQJHLhEQKJ >>>>> s%3d >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> = https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fww >>>>> = w.ietf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonynad%40mi >>>>> = crosoft.com%7c9456670075d04a51f85508d2e59ba294%7c72f988bf86f141af91 >>>>> = ab2d7cd011db47%7c1&sdata=3DND3ydaXOsPMsoRhE0Uyq0uznGy6MdYOLZQJHLhEQKJ >>>>> s%3d >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> = https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww >>>> = .ietf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonynad%40micr >>>> = osoft.com%7c9456670075d04a51f85508d2e59ba294%7c72f988bf86f141af91ab2 >>>> = d7cd011db47%7c1&sdata=3DND3ydaXOsPMsoRhE0Uyq0uznGy6MdYOLZQJHLhEQKJs%3d >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> = https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww. >>> = ietf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonynad%40micros >>> = oft.com%7c9456670075d04a51f85508d2e59ba294%7c72f988bf86f141af91ab2d7c >>> d011db47%7c1&sdata=3DND3ydaXOsPMsoRhE0Uyq0uznGy6MdYOLZQJHLhEQKJs%3d >>=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > = https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.iet= f.org%2fmailman%2flistinfo%2foauth%0a&data=3D01%7c01%7ctonynad%40microsoft= .com%7c9456670075d04a51f85508d2e59ba294%7c72f988bf86f141af91ab2d7cd011db47= %7c1&sdata=3DBLqSuDjWLY72fGm0UrpLwxQVnamMelggJeOpYJESVFs%3d From nobody Wed Nov 4 20:53:30 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AF881A9109 for ; Wed, 4 Nov 2015 20:53:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i0_iSQ9nC1sb for ; Wed, 4 Nov 2015 20:53:26 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0133.outbound.protection.outlook.com [207.46.100.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BFA81B3921 for ; Wed, 4 Nov 2015 20:53:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ElIzp5SXOTtAQ5vo8xBsfMJ9qe7CXS5kGuoWDv/F2hA=; b=WySIoihOdTeohj6/9PMfGOxGay8C4enH6EDRTmarS4f7TOafjZPgiunh/yueUYoAvyYB6DJ9XDF37ZhtitbYYS31goE1ZduYBNq0Aaw04AbJJuSnHWbzLZEBmKt53Mn3zU2aNEct7S4DLese1OTjNN8/lhlWnPX3bCmb5GLcDw0= Received: from BN3PR0301MB1234.namprd03.prod.outlook.com (10.161.207.22) by BN3PR0301MB1233.namprd03.prod.outlook.com (10.161.207.21) with Microsoft SMTP Server (TLS) id 15.1.312.18; Thu, 5 Nov 2015 04:53:20 +0000 Received: from BN3PR0301MB1234.namprd03.prod.outlook.com ([10.161.207.22]) by BN3PR0301MB1234.namprd03.prod.outlook.com ([10.161.207.22]) with mapi id 15.01.0312.014; Thu, 5 Nov 2015 04:53:21 +0000 From: Anthony Nadalin To: Justin Richer Thread-Topic: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment Thread-Index: AdEXFgZ+9CN0zPNjS1iUuZ0RolJO4QAA29mAAAA+4ZAADhjrAAAADBnAAANhSAAACJh0gAAAIrkAAABAqwAAAA9iQAAAG2OAAAAMGSA= Date: Thu, 5 Nov 2015 04:53:20 +0000 Message-ID: References: <563AA216.5010109@gmx.net> <89A6E4DE-263B-4DB4-8882-54FA7103C721@mit.edu> <82079E8A-2AC8-4A42-9AF7-77FF2A3CAFC2@ve7jtb.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tonynad@microsoft.com; x-originating-ip: [133.93.34.100] x-microsoft-exchange-diagnostics: 1; BN3PR0301MB1233; 5:Wk/pSMwJOxab9R7bsfhMUFGgBcg9ihEd8j086vuhbV+CoZlbE+JYrqRAOi9EBv7RCeesbRrlEFVgFTHgnLstVGxakBAgAauCquHJJODsd6bMq2mf7Jh7tTx/PQsPDhwD7JVKzsE1HRodaMW2iUshLQ==; 24:5BZj3dU9PpdPpWTRjlSDUncdR5heThdKLR+JFR8qb4GwPJAfWRGvUNBXRdJK/q1ikTKCQPRuoWv21cKZuftz6vZg7eNvOTUSTST5qwMDyAU=; 20:WfJ/guN9AkfmWcc4q4pkuVtZdDH/MFUJjHxwIAikKeVLoilh4dA9bzq57eMTOKFLSj0K9QvvaDE9+pmhci+0rg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1233; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(240460790083961)(189930954265078)(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425024)(601004)(2401047)(5005006)(8121501046)(520078)(10201501046)(3002001)(61426024)(61427024); SRVR:BN3PR0301MB1233; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1233; x-forefront-prvs: 0751474A44 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(199003)(189002)(51914003)(13464003)(377454003)(52604005)(71364002)(479174004)(5005710100001)(19580395003)(99286002)(5001960100002)(230783001)(189998001)(10290500002)(19580405001)(110136002)(122556002)(10400500002)(40100003)(81156007)(92566002)(5001920100001)(5002640100001)(8990500004)(97736004)(105586002)(76176999)(101416001)(54356999)(86612001)(50986999)(106356001)(2171001)(33656002)(575784001)(87936001)(86362001)(5008740100001)(66066001)(102836002)(2900100001)(5007970100001)(15975445007)(93886004)(74316001)(5003600100002)(5004730100002)(10090500001)(76576001)(2950100001)(77096005)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1233; H:BN3PR0301MB1234.namprd03.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:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Nov 2015 04:53:20.7854 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0301MB1233 Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 04:53:29 -0000 T3VyIHVzZSBjYXNlIGludm9sdmVzIG1vc3RseSBoYXJkd2FyZSAoVFBNIDEuMikgYmFzZWQga2V5 IGdlbmVyYXRpb24sIHdoZXJlIHRoZSBoYXJkd2FyZSAoVFBNIDEuMSkgaXMgc2xvdyB3ZSB3aWxs IHVzZSBzZWN1cmUgc29mdHdhcmUgZXhlY3V0aW9uIGVudmlyb25tZW50LCBvdXIgdXNlIGNhc2Ug aXMgYWx3YXlzIGNsaWVudCBzaWRlIGdlbmVyYXRlZCBrZXlzDQoNCi0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQpGcm9tOiBKdXN0aW4gUmljaGVyIFttYWlsdG86anJpY2hlckBtaXQuZWR1XSAN ClNlbnQ6IFdlZG5lc2RheSwgTm92ZW1iZXIgNCwgMjAxNSA4OjQ4IFBNDQpUbzogQW50aG9ueSBO YWRhbGluIDx0b255bmFkQG1pY3Jvc29mdC5jb20+DQpDYzogSm9obiBCcmFkbGV5IDx2ZTdqdGJA dmU3anRiLmNvbT47IDxvYXV0aEBpZXRmLm9yZz4gPG9hdXRoQGlldGYub3JnPg0KU3ViamVjdDog UmU6IFtPQVVUSC1XR10gUHJvb2Ytb2YtUG9zc2Vzc2lvbiBLZXkgU2VtYW50aWNzIGZvciBKV1Rz IHNwZWMgYWRkcmVzc2luZyBmaW5hbCBzaGVwaGVyZCBjb21tZW50DQoNClRoYXTigJlzIG9ubHkg aWYgeW914oCZcmUgdXNpbmcgZ29vZCBoYXJkd2FyZSB0byBwcm9kdWNlIGEga2V5LiBXZSBjYW7i gJl0IGFzc3VtZSB0aGF04oCZcyB0aGUgb25seSBraW5kIG9mIGNsaWVudCB0aGF0IHdpbGwgZXhp c3QsIGFuZCBzb2Z0d2FyZSBnZW5lcmF0aW9uIGlzIGxpa2VseSB0byBiZSBtdWNoIG1vcmUgY29t bW9uIGZvciBhIHdoaWxlIHlldC4NCg0KUGVyaGFwcyB3aGF0IHdlIHJlYWxseSBuZWVkIGlzIHN0 cm9uZyBndWlkYW5jZSBvbiB3aGVuIHRvIHVzZSB3aGljaCBhcHByb2FjaC4g4oCcSWYgeW91IGNs aWVudCBoYXMgYSBzdHJvbmcgcmFuZG9tIGdlbmVyYXRvciBmdW5jdGlvbiB0aGVuIHlvdSBjYW4g bWFrZSB5b3VyIG93biBrZXksIGJ1dCBvdGhlcndpc2UgbGV0IHRoZSBzZXJ2ZXIgZG8gaXQgZm9y IHlvdS4iDQoNCiDigJQgSnVzdGluDQoNCj4gT24gTm92IDUsIDIwMTUsIGF0IDE6NDUgUE0sIEFu dGhvbnkgTmFkYWxpbiA8dG9ueW5hZEBtaWNyb3NvZnQuY29tPiB3cm90ZToNCj4gDQo+IE5vdCBz dXJlIHdoeSB5b3UgdGhpbmsgaXRzIHdlYWtlciBhcyBpdCB3b3VsZCBiZSBhIHdyYXBwZWQga2V5 IHRoYXQgDQo+IHRoZSBoYXJkd2FyZSBwcm9kdWNlcw0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4gRnJvbTogT0F1dGggW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYgT2YgSm9obiBCcmFkbGV5DQo+IFNlbnQ6IFdlZG5lc2RheSwgTm92ZW1iZXIgNCwg MjAxNSA4OjQzIFBNDQo+IFRvOiBKdXN0aW4gUmljaGVyIDxqcmljaGVyQG1pdC5lZHU+DQo+IENj OiA8b2F1dGhAaWV0Zi5vcmc+IDxvYXV0aEBpZXRmLm9yZz4NCj4gU3ViamVjdDogUmU6IFtPQVVU SC1XR10gUHJvb2Ytb2YtUG9zc2Vzc2lvbiBLZXkgU2VtYW50aWNzIGZvciBKV1RzIA0KPiBzcGVj IGFkZHJlc3NpbmcgZmluYWwgc2hlcGhlcmQgY29tbWVudA0KPiANCj4gSW4gdGhlIGFzeW1tZXRy aWMgY2FzZSB0aGUgdXNlIG9mIGEgSFNNIG9yIHNlY3VyZSBlbGVtZW50IGlzIHRoZSBhcmd1bWVu dCBmb3IgdGhlIGNsaWVudCBzZWxlY3RpbmcgdGhlIHB1YmxpYyBrZXkuICAgSW4gdGhvc2UgY2Fz ZXMgdGhlIGNsaWVudCBpcyBkb2luZyB0aGUga2V5IGdlbiBpbiBoYXJkd2FyZSBzbyBvbmUgaG9w ZXMgaXQgaXMgT0suICAgSW4gdGhlIHN5bWV0cmljIGNhc2UgdGhlIGNsaWVudCBnZW5lcmF0aW5n IHRoZSBrZXkgaXMgd2Vha2VyIChhcyBpbiBJIGNhbuKAmXQgdGhpbmsgb2YgYW55IHJlYWxseSBn b29kIHJlYXNvbikuDQo+IA0KPiANCj4+IE9uIE5vdiA1LCAyMDE1LCBhdCAxOjM1IFBNLCBKdXN0 aW4gUmljaGVyIDxqcmljaGVyQG1pdC5lZHU+IHdyb3RlOg0KPj4gDQo+PiBJ4oCZZCBhcmd1ZSB0 aGF0IGl04oCZcyBiZXN0IHByYWN0aWNlLCBhbmQgaW4gbGluZSB3aXRoIG90aGVyIHBhcnRzIG9m IE9BdXRoLCBpZiB3ZSBhc3N1bWUgdGhlIHNlcnZlciBnZW5lcmF0ZXMgaXQgaW4gdGhlIG5vcm1h bCBjYXNlIChpc3N1ZXIgLT4gcHJlc2VudGVyKS4gQ2xpZW50IGdlbmVyYXRlZCB0b2tlbiBrZXlz IHNob3VsZCBiZSBhbiBleGNlcHRpb24sIGVzcGVjaWFsbHkgaW4gdGhlIGFzeW1tZXRyaWMgY2Fz ZS4NCj4+IA0KPj4g4oCUIEp1c3Rpbg0KPj4gDQo+Pj4gT24gTm92IDUsIDIwMTUsIGF0IDE6MzIg UE0sIEpvaG4gQnJhZGxleSA8dmU3anRiQHZlN2p0Yi5jb20+IHdyb3RlOg0KPj4+IA0KPj4+IEFn cmVlZCB0aGUgb25seSByZWFsIGRpZmZlcmVuY2UgaXMgdGhlIHF1YWxpdHkgb2YgdGhlIGtleS4g IElmIHRoZSBzZXJ2ZXIgZ2VuZXJhdGVzIGl0LCB0aGVuIGl0IGtub3dzIHRoYXQgdGhlIGNsaWVu dCBpcyBub3QgdXNpbmcgdGhlIGZpeGVkIGhleCB2YWx1ZSBvZiBERUFEQkVFRiBmb3IgZXZlcnl0 aGluZy4NCj4+PiANCj4+PiBKb2huIEIuDQo+Pj4+IE9uIE5vdiA1LCAyMDE1LCBhdCA5OjI1IEFN LCBIYW5uZXMgVHNjaG9mZW5pZyA8aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldD4gd3JvdGU6DQo+ Pj4+IA0KPj4+PiBJIGFncmVlIHRoYXQgdGhlIGVmZmVjdCBpcyB0aGUgc2FtZS4gRnJvbSBhIHNl Y3VyaXR5IHBvaW50IG9mIHZpZXcgDQo+Pj4+IHRoZXJlIGlzIG9ubHkgYW4gaW1wYWN0IGlmIG9u ZSBvZiB0aGUgdHdvIHBhcnRpZXMgaXMgaW4gYSBiZXR0ZXIgDQo+Pj4+IHBvc2l0aW9uIHRvIGdl bmVyYXRlIHJhbmRvbSBudW1iZXJzLCB3aGljaCBpcyB0aGUgYmFzaXMgZm9yIA0KPj4+PiBnZW5l cmF0aW5nIGEgaGlnaCBlbnRyb3B5IHN5bW1ldHJpYyBrZXkuDQo+Pj4+IA0KPj4+PiBPbiAxMS8w NC8yMDE1IDExOjUxIFBNLCBNaWtlIEpvbmVzIHdyb3RlOg0KPj4+Pj4gVGhhbmtzIGZvciB0aGUg ZGV0YWlsZWQgcmVhZCwgQnJpYW4uICBZb3XigJlyZSByaWdodCB0aGF0IGluIHRoZSANCj4+Pj4+ IHN5bW1ldHJpYyBjYXNlLCBlaXRoZXIgdGhlIGlzc3VlciBvciB0aGUgcHJlc2VudGVyIGNhbiBj cmVhdGUgdGhlIA0KPj4+Pj4gc3ltbWV0cmljIFBvUCBrZXkgYW5kIHNoYXJlIGl0IHdpdGggdGhl IG90aGVyIHBhcnR5LCBzaW5jZSB0aGUgZWZmZWN0IGlzIGVxdWl2YWxlbnQuDQo+Pj4+PiBJIHN1 c3BlY3QgdGhhdCBib3RoIHRoZSBrZXkgZGlzdHJpYnV0aW9uIGRyYWZ0IGFuZCB0aGlzIGRyYWZ0 IA0KPj4+Pj4gc2hvdWxkIGJlIHVwZGF0ZWQgd2l0aCBhIHNlbnRlbmNlIG9yIHR3byBzYXlpbmcg dGhhdCBlaXRoZXIgDQo+Pj4+PiBhcHByb2FjaCBjYW4gYmUgdGFrZW4uICBEbyBvdGhlcnMgY29u Y3VyPw0KPj4+Pj4gDQo+Pj4+PiANCj4+Pj4+IA0KPj4+Pj4gICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQo+Pj4+PiANCj4+Pj4+ IA0KPj4+Pj4gDQo+Pj4+PiAqRnJvbToqQnJpYW4gQ2FtcGJlbGwgW21haWx0bzpiY2FtcGJlbGxA cGluZ2lkZW50aXR5LmNvbV0NCj4+Pj4+ICpTZW50OiogVGh1cnNkYXksIE5vdmVtYmVyIDA1LCAy MDE1IDc6NDggQU0NCj4+Pj4+ICpUbzoqIE1pa2UgSm9uZXMNCj4+Pj4+ICpDYzoqIEtlcGVuZyBM aTsgb2F1dGhAaWV0Zi5vcmcNCj4+Pj4+ICpTdWJqZWN0OiogUmU6IFtPQVVUSC1XR10gUHJvb2Yt b2YtUG9zc2Vzc2lvbiBLZXkgU2VtYW50aWNzIGZvciANCj4+Pj4+IEpXVHMgc3BlYyBhZGRyZXNz aW5nIGZpbmFsIHNoZXBoZXJkIGNvbW1lbnQNCj4+Pj4+IA0KPj4+Pj4gDQo+Pj4+PiANCj4+Pj4+ ICsxIGZvciB0aGUgZGlhZ3JhbXMgbWFraW5nIHRoZSBkb2N1bWVudCBtb3JlIHVuZGVyc3RhbmRh YmxlLg0KPj4+Pj4gDQo+Pj4+PiBPbmUgbGl0dGxlIG5pdC9xdWVzdGlvbiwgc3RlcCAxIGluIGJv dGggU3ltbWV0cmljIGFuZCBBc3ltbWV0cmljIA0KPj4+Pj4ga2V5cyBzaG93cyB0aGUgUHJlc2Vu dGVyIHNlbmRpbmcgdGhlIGtleSB0byB0aGUgSXNzdWVyLiBJdCdzIA0KPj4+Pj4gcG9zc2libGUs IGhvd2V2ZXIsIGZvciB0aGUga2V5IHRvIGJlIHNlbnQgdGhlIG90aGVyIHdheS4gUHJlc2VudGVy IA0KPj4+Pj4gc2VuZGluZyBpdCB0byB0aGUgSXNzdWVyIGlzIHByb2JhYmx5IHByZWZlcnJlZCBm b3IgYXN5bW1ldHJpYywgDQo+Pj4+PiBlc3BlY2lhbGx5IGlmIHRoZSBjbGllbnQgY2FuIHNlY3Vy ZSB0aGUgcHJpdmF0ZSBrZXlzIGluIGhhcmR3YXJlLg0KPj4+Pj4gQnV0IEkgZG9uJ3Qga25vdyBp ZiBvbmUgd2F5IG9yIHRoZSBvdGhlciBpcyBjbGVhcmx5IGJldHRlciBmb3IgDQo+Pj4+PiBzeW1t ZXRyaWMgY2FzZSBhbmQgUG9QIGtleSBkaXN0cmlidXRpb24gY3VycmVudGx5IGhhcyBpdCB0aGUg b3RoZXIgDQo+Pj4+PiB3YXkgPGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRs b29rLmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJmdG9vbHMuaWV0Zi5vcmclMmZodG1sJTJmZHJhZnQt aWV0Zi1vYXV0aC1wb3Ata2V5LWRpc3RyaWJ1dGlvbi0wMiUyM3NlY3Rpb24tNC4yJmRhdGE9MDEl N2MwMSU3Y3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdjOTQ1NjY3MDA3NWQwNGE1MWY4NTUwOGQy ZTU5YmEyOTQlN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmc2RhdGE9VWda RW9xUWlhVWs5VmRZcFNRUnZVZVZWT1FnSVVnM1VtQXIxOG9RN0d0SSUzZD4uDQo+Pj4+PiBTaG91 bGQgdGhlIGludHJvIHRleHQgc29tZWhvdyBtZW50aW9uIHRoZSBwb3NzaWJpbGl0eSB0aGF0IHRo ZSANCj4+Pj4+IElzc3VlciBjb3VsZCBjcmVhdGUgdGhlIGtleSBhbmQgc2VuZCBpdCB0byB0aGUg UHJlc2VudGVyPw0KPj4+Pj4gDQo+Pj4+PiBJIGtub3cgaXQncyBvbmx5IHRoZSBpbnRyb2R1Y3Rp b24gYnV0IGl0IHdhcyBqdXN0IHNvbWV0aGluZyB0aGF0IA0KPj4+Pj4ganVtcGVkIG91dCBhdCBt ZS4NCj4+Pj4+IA0KPj4+Pj4gDQo+Pj4+PiANCj4+Pj4+IA0KPj4+Pj4gDQo+Pj4+PiBPbiBXZWQs IE5vdiA0LCAyMDE1IGF0IDk6MDQgQU0sIE1pa2UgSm9uZXMgDQo+Pj4+PiA8TWljaGFlbC5Kb25l c0BtaWNyb3NvZnQuY29tIDxtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPj4gd3Jv dGU6DQo+Pj4+PiANCj4+Pj4+IFRoYW5rcyBmb3Igc3VnZ2VzdGluZyB0aGUgZGlhZ3JhbXMsIEtl cGVuZy4gVGhleSBtYWtlIHRoZSBkb2N1bWVudCANCj4+Pj4+IG1vcmUgdW5kZXJzdGFuZGFibGUu DQo+Pj4+PiANCj4+Pj4+IC0tIE1pa2UNCj4+Pj4+IA0KPj4+Pj4gLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+Pj4+PiAt DQo+Pj4+PiAtLS0tLQ0KPj4+Pj4gDQo+Pj4+PiAqRnJvbTogKktlcGVuZyBMaSA8bWFpbHRvOmtl cGVuZy5sa3BAYWxpYmFiYS1pbmMuY29tPg0KPj4+Pj4gKlNlbnQ6ICrigI4xMS/igI41L+KAjjIw MTUgMTI6NTcgQU0NCj4+Pj4+ICpUbzogKk1pa2UgSm9uZXMgPG1haWx0bzpNaWNoYWVsLkpvbmVz QG1pY3Jvc29mdC5jb20+Ow0KPj4+Pj4gb2F1dGhAaWV0Zi5vcmcgPG1haWx0bzpvYXV0aEBpZXRm Lm9yZz4NCj4+Pj4+ICpTdWJqZWN0OiAqUmU6IFByb29mLW9mLVBvc3Nlc3Npb24gS2V5IFNlbWFu dGljcyBmb3IgSldUcyBzcGVjIA0KPj4+Pj4gYWRkcmVzc2luZyBmaW5hbCBzaGVwaGVyZCBjb21t ZW50DQo+Pj4+PiANCj4+Pj4+IFRoYW5rIHlvdSBNaWtlLg0KPj4+Pj4gDQo+Pj4+PiANCj4+Pj4+ IA0KPj4+Pj4gVGhlIGRpYWdyYW1zIGxvb2sgZ29vZCB0byBtZS4NCj4+Pj4+IA0KPj4+Pj4gDQo+ Pj4+PiANCj4+Pj4+IEtpbmQgUmVnYXJkcw0KPj4+Pj4gDQo+Pj4+PiBLZXBlbmcNCj4+Pj4+IA0K Pj4+Pj4gDQo+Pj4+PiANCj4+Pj4+ICrlj5Hku7bkuroqKjogKk1pa2UgSm9uZXMgPE1pY2hhZWwu Sm9uZXNAbWljcm9zb2Z0LmNvbSANCj4+Pj4+IDxtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3Nv ZnQuY29tPj4NCj4+Pj4+ICrml6XmnJ8qKjogKlRodXJzZGF5LCA1IE5vdmVtYmVyLCAyMDE1IDEy OjMyIGFtDQo+Pj4+PiAq6IezKio6ICoib2F1dGhAaWV0Zi5vcmcgPG1haWx0bzpvYXV0aEBpZXRm Lm9yZz4iIDxvYXV0aEBpZXRmLm9yZyANCj4+Pj4+IDxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+Pg0K Pj4+Pj4gKuaKhOmAgSoqOiAqTGkgS2VwZW5nIDxrZXBlbmcubGtwQGFsaWJhYmEtaW5jLmNvbSAN Cj4+Pj4+IDxtYWlsdG86a2VwZW5nLmxrcEBhbGliYWJhLWluYy5jb20+Pg0KPj4+Pj4gKuS4u+mi mCoqOiAqUHJvb2Ytb2YtUG9zc2Vzc2lvbiBLZXkgU2VtYW50aWNzIGZvciBKV1RzIHNwZWMgYWRk cmVzc2luZyANCj4+Pj4+IGZpbmFsIHNoZXBoZXJkIGNvbW1lbnQNCj4+Pj4+IA0KPj4+Pj4gDQo+ Pj4+PiANCj4+Pj4+IFByb29mLW9mLVBvc3Nlc3Npb24gS2V5IFNlbWFudGljcyBmb3IgSldUcyBk cmFmdCAtMDYgYWRkcmVzc2VzIHRoZSANCj4+Pj4+IHJlbWFpbmluZyBkb2N1bWVudCBzaGVwaGVy ZCBjb21tZW50IOKAkyBhZGRpbmcgdXNlIGNhc2UgZGlhZ3JhbXMgdG8gDQo+Pj4+PiB0aGUgaW50 cm9kdWN0aW9uLg0KPj4+Pj4gDQo+Pj4+PiANCj4+Pj4+IA0KPj4+Pj4gVGhlIHVwZGF0ZWQgc3Bl Y2lmaWNhdGlvbiBpcyBhdmFpbGFibGUgYXQ6DQo+Pj4+PiANCj4+Pj4+IMK3ICAgICAgICBodHRw czovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwJTNhJTJm JTJmdG9vbHMuaWV0Zi5vcmclMmZodG1sJTJmZHJhZnQtaWV0Zi1vYXV0aC1wcm9vZi1vZi1wb3Nz ZXNzaW9uLTA2JmRhdGE9MDElN2MwMSU3Y3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdjOTQ1NjY3 MDA3NWQwNGE1MWY4NTUwOGQyZTU5YmEyOTQlN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDEx ZGI0NyU3YzEmc2RhdGE9NmhFNmRPTzBJMSUyZmZGMDA1clZrbnlPRkh1QjE4Z2RwWmc5ZGZ0RXhM dEN3JTNkDQo+Pj4+PiANCj4+Pj4+IA0KPj4+Pj4gDQo+Pj4+PiBBbiBIVE1MIGZvcm1hdHRlZCB2 ZXJzaW9uIGlzIGFsc28gYXZhaWxhYmxlIGF0Og0KPj4+Pj4gDQo+Pj4+PiDCtyAgICAgICANCj4+ Pj4+IGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0 dHBzJTNhJTJmJTJmcw0KPj4+Pj4gZSANCj4+Pj4+IGxmLWlzc3VlZC5pbmZvJTJmZG9jcyUyZmRy YWZ0LWlldGYtb2F1dGgtcHJvb2Ytb2YtcG9zc2Vzc2lvbi0wNi5odA0KPj4+Pj4gbQ0KPj4+Pj4g bCZkYXRhPTAxJTdjMDElN2N0b255bmFkJTQwbWljcm9zb2Z0LmNvbSU3Yzk0NTY2NzAwNzVkMDRh NTFmODU1MDhkDQo+Pj4+PiAyIA0KPj4+Pj4gZTU5YmEyOTQlN2M3MmY5ODhiZjg2ZjE0MWFmOTFh YjJkN2NkMDExZGI0NyU3YzEmc2RhdGE9RVFkNHJVY3V5cWRTDQo+Pj4+PiBQIGdtaWJ0Y2ZqTXBK bTZSV1d3Q1pDODUlMmJDYm9FczU0JTNkDQo+Pj4+PiANCj4+Pj4+IA0KPj4+Pj4gDQo+Pj4+PiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0t IE1pa2UNCj4+Pj4+IA0KPj4+Pj4gDQo+Pj4+PiANCj4+Pj4+IFAuUy4gIFRoaXMgbm90ZSB3YXMg YWxzbyBwb3N0ZWQgYXQgDQo+Pj4+PiBodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24u b3V0bG9vay5jb20vP3VybD1odHRwJTNhJTJmJTJmc2VsZi1pc3N1ZWQuaW5mbyUyZiUzZnAlM2Qx NDcxJmRhdGE9MDElN2MwMSU3Y3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdjOTQ1NjY3MDA3NWQw NGE1MWY4NTUwOGQyZTU5YmEyOTQlN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3 YzEmc2RhdGE9VE1mWDF0RzVxdWNsJTJiZTJLVnB5TUJ1ajcyWlElMmYlMmJFS0dvVHlKeWYlMmJm Smk0JTNkIGFuZCBhcyBAc2VsZmlzc3VlZCA8aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0 aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM2ElMmYlMmZ0d2l0dGVyLmNvbSUyZnNlbGZpc3N1 ZWQmZGF0YT0wMSU3YzAxJTdjdG9ueW5hZCU0MG1pY3Jvc29mdC5jb20lN2M5NDU2NjcwMDc1ZDA0 YTUxZjg1NTA4ZDJlNTliYTI5NCU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdj MSZzZGF0YT1MZkZBamNoekNUaDB4JTJmWTlocjBXJTJmU29oUEdnYjBKVmpMJTJmMkF6JTJmMTJC Q2clM2Q+Lg0KPj4+Pj4gDQo+Pj4+PiANCj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+Pj4+PiBPQXV0aCBtYWlsaW5nIGxpc3QNCj4+Pj4+IE9B dXRoQGlldGYub3JnIDxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+IA0KPj4+Pj4gaHR0cHM6Ly9uYTAx LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM2ElMmYlMmZ3DQo+ Pj4+PiB3IA0KPj4+Pj4gdy5pZXRmLm9yZyUyZm1haWxtYW4lMmZsaXN0aW5mbyUyZm9hdXRoJmRh dGE9MDElN2MwMSU3Y3RvbnluYWQlNDBtDQo+Pj4+PiBpDQo+Pj4+PiBjcm9zb2Z0LmNvbSU3Yzk0 NTY2NzAwNzVkMDRhNTFmODU1MDhkMmU1OWJhMjk0JTdjNzJmOTg4YmY4NmYxNDFhZjkNCj4+Pj4+ IDEgDQo+Pj4+PiBhYjJkN2NkMDExZGI0NyU3YzEmc2RhdGE9TkQzeWRhWE9zUE1zb1JoRTBVeXEw dXpuR3k2TWRZT0xaUUpITGhFUUsNCj4+Pj4+IEoNCj4+Pj4+IHMlM2QNCj4+Pj4+IA0KPj4+Pj4g DQo+Pj4+PiANCj4+Pj4+IA0KPj4+Pj4gDQo+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4gT0F1dGggbWFpbGluZyBsaXN0DQo+Pj4+PiBP QXV0aEBpZXRmLm9yZw0KPj4+Pj4gaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91 dGxvb2suY29tLz91cmw9aHR0cHMlM2ElMmYlMmZ3DQo+Pj4+PiB3IA0KPj4+Pj4gdy5pZXRmLm9y ZyUyZm1haWxtYW4lMmZsaXN0aW5mbyUyZm9hdXRoJmRhdGE9MDElN2MwMSU3Y3RvbnluYWQlNDBt DQo+Pj4+PiBpDQo+Pj4+PiBjcm9zb2Z0LmNvbSU3Yzk0NTY2NzAwNzVkMDRhNTFmODU1MDhkMmU1 OWJhMjk0JTdjNzJmOTg4YmY4NmYxNDFhZjkNCj4+Pj4+IDEgDQo+Pj4+PiBhYjJkN2NkMDExZGI0 NyU3YzEmc2RhdGE9TkQzeWRhWE9zUE1zb1JoRTBVeXEwdXpuR3k2TWRZT0xaUUpITGhFUUsNCj4+ Pj4+IEoNCj4+Pj4+IHMlM2QNCj4+Pj4+IA0KPj4+PiANCj4+Pj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4gT0F1dGggbWFpbGluZyBsaXN0DQo+ Pj4+IE9BdXRoQGlldGYub3JnDQo+Pj4+IGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlv bi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJmd3cNCj4+Pj4gdyANCj4+Pj4gLmlldGYu b3JnJTJmbWFpbG1hbiUyZmxpc3RpbmZvJTJmb2F1dGgmZGF0YT0wMSU3YzAxJTdjdG9ueW5hZCU0 MG1pYw0KPj4+PiByDQo+Pj4+IG9zb2Z0LmNvbSU3Yzk0NTY2NzAwNzVkMDRhNTFmODU1MDhkMmU1 OWJhMjk0JTdjNzJmOTg4YmY4NmYxNDFhZjkxYWINCj4+Pj4gMiANCj4+Pj4gZDdjZDAxMWRiNDcl N2MxJnNkYXRhPU5EM3lkYVhPc1BNc29SaEUwVXlxMHV6bkd5Nk1kWU9MWlFKSExoRVFLSnMlMw0K Pj4+PiBkDQo+Pj4gDQo+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4+PiBPQXV0aCBtYWlsaW5nIGxpc3QNCj4+PiBPQXV0aEBpZXRmLm9yZw0KPj4+ IGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBz JTNhJTJmJTJmd3d3Lg0KPj4+IGlldGYub3JnJTJmbWFpbG1hbiUyZmxpc3RpbmZvJTJmb2F1dGgm ZGF0YT0wMSU3YzAxJTdjdG9ueW5hZCU0MG1pY3JvDQo+Pj4gcyANCj4+PiBvZnQuY29tJTdjOTQ1 NjY3MDA3NWQwNGE1MWY4NTUwOGQyZTU5YmEyOTQlN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkNw0K Pj4+IGMgZDAxMWRiNDclN2MxJnNkYXRhPU5EM3lkYVhPc1BNc29SaEUwVXlxMHV6bkd5Nk1kWU9M WlFKSExoRVFLSnMlM2QNCj4+IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gT0F1dGggbWFpbGluZyBsaXN0DQo+IE9BdXRoQGlldGYub3Jn DQo+IGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0 dHBzJTNhJTJmJTJmd3d3LmkNCj4gZXRmLm9yZyUyZm1haWxtYW4lMmZsaXN0aW5mbyUyZm9hdXRo JTBhJmRhdGE9MDElN2MwMSU3Y3RvbnluYWQlNDBtaWNybw0KPiBzb2Z0LmNvbSU3Yzk0NTY2NzAw NzVkMDRhNTFmODU1MDhkMmU1OWJhMjk0JTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjDQo+IGQw MTFkYjQ3JTdjMSZzZGF0YT1CTHFTdURqV0xZNzJmR20wVXJwTHd4UVZuYW1NZWxnZ0plT3BZSkVT VkZzJTNkDQoNCg== From nobody Wed Nov 4 20:55:36 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8EA21B37E7 for ; Wed, 4 Nov 2015 20:55:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1tNmiHqcOsq8 for ; Wed, 4 Nov 2015 20:55:32 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0749.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::749]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7BFA1A9139 for ; Wed, 4 Nov 2015 20:55:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=jDBoAJHpnzvrKJZHGDrWGuY7JhmZ0ZqsP/md+J8TGzc=; b=XA5JpxQBjmCyHF8Ku7LGZSdYTxSiVE2cvkeG153nwgEjwJ2EO0gUt0ndnRqvttE57vFvE2J91aRzYoFK809XfG9z/fyzLr/FUL1em7II/OpONC+3WoIajoHfkNdTNTVOGZ4unz/xhkShpIJdUXqm9i3AA6nZL/nfHRT1Tl8/qr0= Received: from BN3PR0301MB1234.namprd03.prod.outlook.com (10.161.207.22) by BN3PR0301MB1233.namprd03.prod.outlook.com (10.161.207.21) with Microsoft SMTP Server (TLS) id 15.1.312.18; Thu, 5 Nov 2015 04:55:10 +0000 Received: from BN3PR0301MB1234.namprd03.prod.outlook.com ([10.161.207.22]) by BN3PR0301MB1234.namprd03.prod.outlook.com ([10.161.207.22]) with mapi id 15.01.0312.014; Thu, 5 Nov 2015 04:55:11 +0000 From: Anthony Nadalin To: John Bradley Thread-Topic: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment Thread-Index: AdEXFgZ+9CN0zPNjS1iUuZ0RolJO4QAA29mAAAA+4ZAADhjrAAAADBnAAANhSAAACJh0gAAAIrkAAABAqwAAAA9iQAAAPMSAAAAVIgA= Date: Thu, 5 Nov 2015 04:55:10 +0000 Message-ID: References: <563AA216.5010109@gmx.net> <89A6E4DE-263B-4DB4-8882-54FA7103C721@mit.edu> <82079E8A-2AC8-4A42-9AF7-77FF2A3CAFC2@ve7jtb.com> <9E23AF3A-F758-4CB4-B920-4E1E2F61BCF4@ve7jtb.com> In-Reply-To: <9E23AF3A-F758-4CB4-B920-4E1E2F61BCF4@ve7jtb.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tonynad@microsoft.com; x-originating-ip: [133.93.34.100] x-microsoft-exchange-diagnostics: 1; BN3PR0301MB1233; 5:qzHj9yVbQzQoHUVvAgaV62nSm+YjvjmOv/imjGxjVlTmo/puanR9mtUeIbFcsQCA5mtzf2pZsbNGwfHu6WuI5DwAlflEvBrR3PR1oASnHOpmwaTYD6Py7lZO4TKqWKncG+4nsiu5gE6ArZTK48E4bg==; 24:FMPhxnLpt2fUPKfdaJV73eDvuds0gsdvd4UdnNuq4gg4XLe6E1OKiBxuQRvN8i/Hhk6ZFf30Tw5IzJ2XHln/9EqTus7vgzxFhwQllZrox5E=; 20:M3RyKT5MXOz8OvR7fBVC7pfVLQ6RGb3tJnMnZgXTr/7iaR9asZaFz+7LT9ikrzsjfwtBhKa2WdsXvHpFKcJAMQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1233; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(240460790083961)(189930954265078)(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425024)(601004)(2401047)(5005006)(8121501046)(520078)(10201501046)(3002001)(61426024)(61427024); SRVR:BN3PR0301MB1233; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1233; x-forefront-prvs: 0751474A44 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(199003)(189002)(51914003)(13464003)(377454003)(52604005)(71364002)(479174004)(5005710100001)(19580395003)(99286002)(5001960100002)(230783001)(189998001)(10290500002)(19580405001)(110136002)(122556002)(10400500002)(40100003)(81156007)(92566002)(5001920100001)(5002640100001)(8990500004)(97736004)(105586002)(76176999)(101416001)(54356999)(86612001)(50986999)(106356001)(33656002)(575784001)(87936001)(86362001)(5008740100001)(66066001)(102836002)(2900100001)(5007970100001)(15975445007)(93886004)(74316001)(5003600100002)(5004730100002)(10090500001)(76576001)(2950100001)(77096005)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1233; H:BN3PR0301MB1234.namprd03.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:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Nov 2015 04:55:10.4594 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0301MB1233 Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 04:55:35 -0000 SSBjYW4gc2F5IG9uIGFsbCB3aW5kb3dzIGJhc2VkIGRldmljZXMgKHBjLCB4Ym94LCBwaG9uZSwg ZXRjKSB3aXRoIG9ubHkgVFBNIDEuMSB0aGlzIHdpbGwgYmUgdGhlIGFwcHJvYWNoIHNvIGl0IHdp bGwgYmUgY29tbW9ubHkgdXNlZCANCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206 IEpvaG4gQnJhZGxleSBbbWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29tXSANClNlbnQ6IFdlZG5lc2Rh eSwgTm92ZW1iZXIgNCwgMjAxNSA4OjUyIFBNDQpUbzogQW50aG9ueSBOYWRhbGluIDx0b255bmFk QG1pY3Jvc29mdC5jb20+DQpDYzogSnVzdGluIFJpY2hlciA8anJpY2hlckBtaXQuZWR1PjsgPG9h dXRoQGlldGYub3JnPiA8b2F1dGhAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBQ cm9vZi1vZi1Qb3NzZXNzaW9uIEtleSBTZW1hbnRpY3MgZm9yIEpXVHMgc3BlYyBhZGRyZXNzaW5n IGZpbmFsIHNoZXBoZXJkIGNvbW1lbnQNCg0KT0ssIG5vIGdvb2QgcmVhc29uIHVubGVzcyB0aGUg Y2xpZW50IGlzIHVzaW5nIGEgSFNNIHRoYXQgY2FuIGRvIEhNQUMgYW5kIGNhbiBleHBvcnQgYSBz eW1tZXRyaWMga2V5IHdyYXBwZWQgaW4gYSBhc3ltbWV0cmljIGtleSBwcm92aWRlZCBieSB0aGUg QVMuDQoNCldlIGRvbuKAmXQgY3VycmVudGx5IGNvdmVyIHRoYXQgdXNlIGNhc2Ugb2Ygc2VuZGlu ZyBhIHdyYXBwZWQgc3ltbWV0cmljIGtleSB0byB0aGUgQVMgaW4gUE9QIGtleSBkaXN0cmlidXRp b24uICAgDQpJIGRvbuKAmXQga25vdyBob3cgY29tbW9uIHRoYXQgaXMgZ29pbmcgdG8gYmUsIGJ1 dCBpdCBpcyB3b3J0aCB0aGlua2luZyBhYm91dCBkZWZpbmluZy4NCg0KSm9obiBCLg0KDQo+IE9u IE5vdiA1LCAyMDE1LCBhdCAxOjQ1IFBNLCBBbnRob255IE5hZGFsaW4gPHRvbnluYWRAbWljcm9z b2Z0LmNvbT4gd3JvdGU6DQo+IA0KPiBOb3Qgc3VyZSB3aHkgeW91IHRoaW5rIGl0cyB3ZWFrZXIg YXMgaXQgd291bGQgYmUgYSB3cmFwcGVkIGtleSB0aGF0IA0KPiB0aGUgaGFyZHdhcmUgcHJvZHVj ZXMNCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IE9BdXRoIFttYWls dG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEpvaG4gQnJhZGxleQ0KPiBT ZW50OiBXZWRuZXNkYXksIE5vdmVtYmVyIDQsIDIwMTUgODo0MyBQTQ0KPiBUbzogSnVzdGluIFJp Y2hlciA8anJpY2hlckBtaXQuZWR1Pg0KPiBDYzogPG9hdXRoQGlldGYub3JnPiA8b2F1dGhAaWV0 Zi5vcmc+DQo+IFN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIFByb29mLW9mLVBvc3Nlc3Npb24gS2V5 IFNlbWFudGljcyBmb3IgSldUcyANCj4gc3BlYyBhZGRyZXNzaW5nIGZpbmFsIHNoZXBoZXJkIGNv bW1lbnQNCj4gDQo+IEluIHRoZSBhc3ltbWV0cmljIGNhc2UgdGhlIHVzZSBvZiBhIEhTTSBvciBz ZWN1cmUgZWxlbWVudCBpcyB0aGUgYXJndW1lbnQgZm9yIHRoZSBjbGllbnQgc2VsZWN0aW5nIHRo ZSBwdWJsaWMga2V5LiAgIEluIHRob3NlIGNhc2VzIHRoZSBjbGllbnQgaXMgZG9pbmcgdGhlIGtl eSBnZW4gaW4gaGFyZHdhcmUgc28gb25lIGhvcGVzIGl0IGlzIE9LLiAgIEluIHRoZSBzeW1ldHJp YyBjYXNlIHRoZSBjbGllbnQgZ2VuZXJhdGluZyB0aGUga2V5IGlzIHdlYWtlciAoYXMgaW4gSSBj YW7igJl0IHRoaW5rIG9mIGFueSByZWFsbHkgZ29vZCByZWFzb24pLg0KPiANCj4gDQo+PiBPbiBO b3YgNSwgMjAxNSwgYXQgMTozNSBQTSwgSnVzdGluIFJpY2hlciA8anJpY2hlckBtaXQuZWR1PiB3 cm90ZToNCj4+IA0KPj4gSeKAmWQgYXJndWUgdGhhdCBpdOKAmXMgYmVzdCBwcmFjdGljZSwgYW5k IGluIGxpbmUgd2l0aCBvdGhlciBwYXJ0cyBvZiBPQXV0aCwgaWYgd2UgYXNzdW1lIHRoZSBzZXJ2 ZXIgZ2VuZXJhdGVzIGl0IGluIHRoZSBub3JtYWwgY2FzZSAoaXNzdWVyIC0+IHByZXNlbnRlciku IENsaWVudCBnZW5lcmF0ZWQgdG9rZW4ga2V5cyBzaG91bGQgYmUgYW4gZXhjZXB0aW9uLCBlc3Bl Y2lhbGx5IGluIHRoZSBhc3ltbWV0cmljIGNhc2UuDQo+PiANCj4+IOKAlCBKdXN0aW4NCj4+IA0K Pj4+IE9uIE5vdiA1LCAyMDE1LCBhdCAxOjMyIFBNLCBKb2huIEJyYWRsZXkgPHZlN2p0YkB2ZTdq dGIuY29tPiB3cm90ZToNCj4+PiANCj4+PiBBZ3JlZWQgdGhlIG9ubHkgcmVhbCBkaWZmZXJlbmNl IGlzIHRoZSBxdWFsaXR5IG9mIHRoZSBrZXkuICBJZiB0aGUgc2VydmVyIGdlbmVyYXRlcyBpdCwg dGhlbiBpdCBrbm93cyB0aGF0IHRoZSBjbGllbnQgaXMgbm90IHVzaW5nIHRoZSBmaXhlZCBoZXgg dmFsdWUgb2YgREVBREJFRUYgZm9yIGV2ZXJ5dGhpbmcuDQo+Pj4gDQo+Pj4gSm9obiBCLg0KPj4+ PiBPbiBOb3YgNSwgMjAxNSwgYXQgOToyNSBBTSwgSGFubmVzIFRzY2hvZmVuaWcgPGhhbm5lcy50 c2Nob2ZlbmlnQGdteC5uZXQ+IHdyb3RlOg0KPj4+PiANCj4+Pj4gSSBhZ3JlZSB0aGF0IHRoZSBl ZmZlY3QgaXMgdGhlIHNhbWUuIEZyb20gYSBzZWN1cml0eSBwb2ludCBvZiB2aWV3IA0KPj4+PiB0 aGVyZSBpcyBvbmx5IGFuIGltcGFjdCBpZiBvbmUgb2YgdGhlIHR3byBwYXJ0aWVzIGlzIGluIGEg YmV0dGVyIA0KPj4+PiBwb3NpdGlvbiB0byBnZW5lcmF0ZSByYW5kb20gbnVtYmVycywgd2hpY2gg aXMgdGhlIGJhc2lzIGZvciANCj4+Pj4gZ2VuZXJhdGluZyBhIGhpZ2ggZW50cm9weSBzeW1tZXRy aWMga2V5Lg0KPj4+PiANCj4+Pj4gT24gMTEvMDQvMjAxNSAxMTo1MSBQTSwgTWlrZSBKb25lcyB3 cm90ZToNCj4+Pj4+IFRoYW5rcyBmb3IgdGhlIGRldGFpbGVkIHJlYWQsIEJyaWFuLiAgWW914oCZ cmUgcmlnaHQgdGhhdCBpbiB0aGUgDQo+Pj4+PiBzeW1tZXRyaWMgY2FzZSwgZWl0aGVyIHRoZSBp c3N1ZXIgb3IgdGhlIHByZXNlbnRlciBjYW4gY3JlYXRlIHRoZSANCj4+Pj4+IHN5bW1ldHJpYyBQ b1Aga2V5IGFuZCBzaGFyZSBpdCB3aXRoIHRoZSBvdGhlciBwYXJ0eSwgc2luY2UgdGhlIGVmZmVj dCBpcyBlcXVpdmFsZW50Lg0KPj4+Pj4gSSBzdXNwZWN0IHRoYXQgYm90aCB0aGUga2V5IGRpc3Ry aWJ1dGlvbiBkcmFmdCBhbmQgdGhpcyBkcmFmdCANCj4+Pj4+IHNob3VsZCBiZSB1cGRhdGVkIHdp dGggYSBzZW50ZW5jZSBvciB0d28gc2F5aW5nIHRoYXQgZWl0aGVyIA0KPj4+Pj4gYXBwcm9hY2gg Y2FuIGJlIHRha2VuLiAgRG8gb3RoZXJzIGNvbmN1cj8NCj4+Pj4+IA0KPj4+Pj4gDQo+Pj4+PiAN Cj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgLS0gTWlrZQ0KPj4+Pj4gDQo+Pj4+PiANCj4+Pj4+IA0KPj4+Pj4gKkZyb206KkJyaWFu IENhbXBiZWxsIFttYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb21dDQo+Pj4+PiAqU2Vu dDoqIFRodXJzZGF5LCBOb3ZlbWJlciAwNSwgMjAxNSA3OjQ4IEFNDQo+Pj4+PiAqVG86KiBNaWtl IEpvbmVzDQo+Pj4+PiAqQ2M6KiBLZXBlbmcgTGk7IG9hdXRoQGlldGYub3JnDQo+Pj4+PiAqU3Vi amVjdDoqIFJlOiBbT0FVVEgtV0ddIFByb29mLW9mLVBvc3Nlc3Npb24gS2V5IFNlbWFudGljcyBm b3IgDQo+Pj4+PiBKV1RzIHNwZWMgYWRkcmVzc2luZyBmaW5hbCBzaGVwaGVyZCBjb21tZW50DQo+ Pj4+PiANCj4+Pj4+IA0KPj4+Pj4gDQo+Pj4+PiArMSBmb3IgdGhlIGRpYWdyYW1zIG1ha2luZyB0 aGUgZG9jdW1lbnQgbW9yZSB1bmRlcnN0YW5kYWJsZS4NCj4+Pj4+IA0KPj4+Pj4gT25lIGxpdHRs ZSBuaXQvcXVlc3Rpb24sIHN0ZXAgMSBpbiBib3RoIFN5bW1ldHJpYyBhbmQgQXN5bW1ldHJpYyAN Cj4+Pj4+IGtleXMgc2hvd3MgdGhlIFByZXNlbnRlciBzZW5kaW5nIHRoZSBrZXkgdG8gdGhlIElz c3Vlci4gSXQncyANCj4+Pj4+IHBvc3NpYmxlLCBob3dldmVyLCBmb3IgdGhlIGtleSB0byBiZSBz ZW50IHRoZSBvdGhlciB3YXkuIFByZXNlbnRlciANCj4+Pj4+IHNlbmRpbmcgaXQgdG8gdGhlIElz c3VlciBpcyBwcm9iYWJseSBwcmVmZXJyZWQgZm9yIGFzeW1tZXRyaWMsIA0KPj4+Pj4gZXNwZWNp YWxseSBpZiB0aGUgY2xpZW50IGNhbiBzZWN1cmUgdGhlIHByaXZhdGUga2V5cyBpbiBoYXJkd2Fy ZS4NCj4+Pj4+IEJ1dCBJIGRvbid0IGtub3cgaWYgb25lIHdheSBvciB0aGUgb3RoZXIgaXMgY2xl YXJseSBiZXR0ZXIgZm9yIA0KPj4+Pj4gc3ltbWV0cmljIGNhc2UgYW5kIFBvUCBrZXkgZGlzdHJp YnV0aW9uIGN1cnJlbnRseSBoYXMgaXQgdGhlIG90aGVyIA0KPj4+Pj4gd2F5IDxodHRwczovL25h MDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzYSUyZiUyZnRv b2xzLmlldGYub3JnJTJmaHRtbCUyZmRyYWZ0LWlldGYtb2F1dGgtcG9wLWtleS1kaXN0cmlidXRp b24tMDIlMjNzZWN0aW9uLTQuMiZkYXRhPTAxJTdjMDElN2N0b255bmFkJTQwbWljcm9zb2Z0LmNv bSU3Yzk0NTY2NzAwNzVkMDRhNTFmODU1MDhkMmU1OWJhMjk0JTdjNzJmOTg4YmY4NmYxNDFhZjkx YWIyZDdjZDAxMWRiNDclN2MxJnNkYXRhPVVnWkVvcVFpYVVrOVZkWXBTUVJ2VWVWVk9RZ0lVZzNV bUFyMThvUTdHdEklM2Q+Lg0KPj4+Pj4gU2hvdWxkIHRoZSBpbnRybyB0ZXh0IHNvbWVob3cgbWVu dGlvbiB0aGUgcG9zc2liaWxpdHkgdGhhdCB0aGUgDQo+Pj4+PiBJc3N1ZXIgY291bGQgY3JlYXRl IHRoZSBrZXkgYW5kIHNlbmQgaXQgdG8gdGhlIFByZXNlbnRlcj8NCj4+Pj4+IA0KPj4+Pj4gSSBr bm93IGl0J3Mgb25seSB0aGUgaW50cm9kdWN0aW9uIGJ1dCBpdCB3YXMganVzdCBzb21ldGhpbmcg dGhhdCANCj4+Pj4+IGp1bXBlZCBvdXQgYXQgbWUuDQo+Pj4+PiANCj4+Pj4+IA0KPj4+Pj4gDQo+ Pj4+PiANCj4+Pj4+IA0KPj4+Pj4gT24gV2VkLCBOb3YgNCwgMjAxNSBhdCA5OjA0IEFNLCBNaWtl IEpvbmVzIA0KPj4+Pj4gPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSA8bWFpbHRvOk1pY2hh ZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4+IHdyb3RlOg0KPj4+Pj4gDQo+Pj4+PiBUaGFua3MgZm9y IHN1Z2dlc3RpbmcgdGhlIGRpYWdyYW1zLCBLZXBlbmcuIFRoZXkgbWFrZSB0aGUgZG9jdW1lbnQg DQo+Pj4+PiBtb3JlIHVuZGVyc3RhbmRhYmxlLg0KPj4+Pj4gDQo+Pj4+PiAtLSBNaWtlDQo+Pj4+ PiANCj4+Pj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4+Pj4gLQ0KPj4+Pj4gLS0tLS0NCj4+Pj4+IA0KPj4+Pj4g KkZyb206ICpLZXBlbmcgTGkgPG1haWx0bzprZXBlbmcubGtwQGFsaWJhYmEtaW5jLmNvbT4NCj4+ Pj4+ICpTZW50OiAq4oCOMTEv4oCONS/igI4yMDE1IDEyOjU3IEFNDQo+Pj4+PiAqVG86ICpNaWtl IEpvbmVzIDxtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPjsNCj4+Pj4+IG9hdXRo QGlldGYub3JnIDxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+DQo+Pj4+PiAqU3ViamVjdDogKlJlOiBQ cm9vZi1vZi1Qb3NzZXNzaW9uIEtleSBTZW1hbnRpY3MgZm9yIEpXVHMgc3BlYyANCj4+Pj4+IGFk ZHJlc3NpbmcgZmluYWwgc2hlcGhlcmQgY29tbWVudA0KPj4+Pj4gDQo+Pj4+PiBUaGFuayB5b3Ug TWlrZS4NCj4+Pj4+IA0KPj4+Pj4gDQo+Pj4+PiANCj4+Pj4+IFRoZSBkaWFncmFtcyBsb29rIGdv b2QgdG8gbWUuDQo+Pj4+PiANCj4+Pj4+IA0KPj4+Pj4gDQo+Pj4+PiBLaW5kIFJlZ2FyZHMNCj4+ Pj4+IA0KPj4+Pj4gS2VwZW5nDQo+Pj4+PiANCj4+Pj4+IA0KPj4+Pj4gDQo+Pj4+PiAq5Y+R5Lu2 5Lq6Kio6ICpNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20gDQo+Pj4+PiA8 bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4+DQo+Pj4+PiAq5pel5pyfKio6ICpU aHVyc2RheSwgNSBOb3ZlbWJlciwgMjAxNSAxMjozMiBhbQ0KPj4+Pj4gKuiHsyoqOiAqIm9hdXRo QGlldGYub3JnIDxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+IiA8b2F1dGhAaWV0Zi5vcmcgDQo+Pj4+ PiA8bWFpbHRvOm9hdXRoQGlldGYub3JnPj4NCj4+Pj4+ICrmioTpgIEqKjogKkxpIEtlcGVuZyA8 a2VwZW5nLmxrcEBhbGliYWJhLWluYy5jb20gDQo+Pj4+PiA8bWFpbHRvOmtlcGVuZy5sa3BAYWxp YmFiYS1pbmMuY29tPj4NCj4+Pj4+ICrkuLvpopgqKjogKlByb29mLW9mLVBvc3Nlc3Npb24gS2V5 IFNlbWFudGljcyBmb3IgSldUcyBzcGVjIGFkZHJlc3NpbmcgDQo+Pj4+PiBmaW5hbCBzaGVwaGVy ZCBjb21tZW50DQo+Pj4+PiANCj4+Pj4+IA0KPj4+Pj4gDQo+Pj4+PiBQcm9vZi1vZi1Qb3NzZXNz aW9uIEtleSBTZW1hbnRpY3MgZm9yIEpXVHMgZHJhZnQgLTA2IGFkZHJlc3NlcyB0aGUgDQo+Pj4+ PiByZW1haW5pbmcgZG9jdW1lbnQgc2hlcGhlcmQgY29tbWVudCDigJMgYWRkaW5nIHVzZSBjYXNl IGRpYWdyYW1zIHRvIA0KPj4+Pj4gdGhlIGludHJvZHVjdGlvbi4NCj4+Pj4+IA0KPj4+Pj4gDQo+ Pj4+PiANCj4+Pj4+IFRoZSB1cGRhdGVkIHNwZWNpZmljYXRpb24gaXMgYXZhaWxhYmxlIGF0Og0K Pj4+Pj4gDQo+Pj4+PiDCtyAgICAgICAgaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9u Lm91dGxvb2suY29tLz91cmw9aHR0cCUzYSUyZiUyZnRvb2xzLmlldGYub3JnJTJmaHRtbCUyZmRy YWZ0LWlldGYtb2F1dGgtcHJvb2Ytb2YtcG9zc2Vzc2lvbi0wNiZkYXRhPTAxJTdjMDElN2N0b255 bmFkJTQwbWljcm9zb2Z0LmNvbSU3Yzk0NTY2NzAwNzVkMDRhNTFmODU1MDhkMmU1OWJhMjk0JTdj NzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJnNkYXRhPTZoRTZkT08wSTElMmZm RjAwNXJWa255T0ZIdUIxOGdkcFpnOWRmdEV4THRDdyUzZA0KPj4+Pj4gDQo+Pj4+PiANCj4+Pj4+ IA0KPj4+Pj4gQW4gSFRNTCBmb3JtYXR0ZWQgdmVyc2lvbiBpcyBhbHNvIGF2YWlsYWJsZSBhdDoN Cj4+Pj4+IA0KPj4+Pj4gwrcgICAgICAgDQo+Pj4+PiBodHRwczovL25hMDEuc2FmZWxpbmtzLnBy b3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzYSUyZiUyZnMNCj4+Pj4+IGUgDQo+Pj4+ PiBsZi1pc3N1ZWQuaW5mbyUyZmRvY3MlMmZkcmFmdC1pZXRmLW9hdXRoLXByb29mLW9mLXBvc3Nl c3Npb24tMDYuaHQNCj4+Pj4+IG0NCj4+Pj4+IGwmZGF0YT0wMSU3YzAxJTdjdG9ueW5hZCU0MG1p Y3Jvc29mdC5jb20lN2M5NDU2NjcwMDc1ZDA0YTUxZjg1NTA4ZA0KPj4+Pj4gMiANCj4+Pj4+IGU1 OWJhMjk0JTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJnNkYXRhPUVRZDRy VWN1eXFkUw0KPj4+Pj4gUCBnbWlidGNmak1wSm02UldXd0NaQzg1JTJiQ2JvRXM1NCUzZA0KPj4+ Pj4gDQo+Pj4+PiANCj4+Pj4+IA0KPj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQo+Pj4+PiANCj4+Pj4+IA0KPj4+Pj4g DQo+Pj4+PiBQLlMuICBUaGlzIG5vdGUgd2FzIGFsc28gcG9zdGVkIGF0IA0KPj4+Pj4gaHR0cHM6 Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cCUzYSUyZiUy ZnNlbGYtaXNzdWVkLmluZm8lMmYlM2ZwJTNkMTQ3MSZkYXRhPTAxJTdjMDElN2N0b255bmFkJTQw bWljcm9zb2Z0LmNvbSU3Yzk0NTY2NzAwNzVkMDRhNTFmODU1MDhkMmU1OWJhMjk0JTdjNzJmOTg4 YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJnNkYXRhPVRNZlgxdEc1cXVjbCUyYmUyS1Zw eU1CdWo3MlpRJTJmJTJiRUtHb1R5SnlmJTJiZkppNCUzZCBhbmQgYXMgQHNlbGZpc3N1ZWQgPGh0 dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNh JTJmJTJmdHdpdHRlci5jb20lMmZzZWxmaXNzdWVkJmRhdGE9MDElN2MwMSU3Y3RvbnluYWQlNDBt aWNyb3NvZnQuY29tJTdjOTQ1NjY3MDA3NWQwNGE1MWY4NTUwOGQyZTU5YmEyOTQlN2M3MmY5ODhi Zjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmc2RhdGE9TGZGQWpjaHpDVGgweCUyZlk5aHIw VyUyZlNvaFBHZ2IwSlZqTCUyZjJBeiUyZjEyQkNnJTNkPi4NCj4+Pj4+IA0KPj4+Pj4gDQo+Pj4+ PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4g T0F1dGggbWFpbGluZyBsaXN0DQo+Pj4+PiBPQXV0aEBpZXRmLm9yZyA8bWFpbHRvOk9BdXRoQGll dGYub3JnPiANCj4+Pj4+IGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29r LmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJmdw0KPj4+Pj4gdyANCj4+Pj4+IHcuaWV0Zi5vcmclMmZt YWlsbWFuJTJmbGlzdGluZm8lMmZvYXV0aCZkYXRhPTAxJTdjMDElN2N0b255bmFkJTQwbQ0KPj4+ Pj4gaQ0KPj4+Pj4gY3Jvc29mdC5jb20lN2M5NDU2NjcwMDc1ZDA0YTUxZjg1NTA4ZDJlNTliYTI5 NCU3YzcyZjk4OGJmODZmMTQxYWY5DQo+Pj4+PiAxIA0KPj4+Pj4gYWIyZDdjZDAxMWRiNDclN2Mx JnNkYXRhPU5EM3lkYVhPc1BNc29SaEUwVXlxMHV6bkd5Nk1kWU9MWlFKSExoRVFLDQo+Pj4+PiBK DQo+Pj4+PiBzJTNkDQo+Pj4+PiANCj4+Pj4+IA0KPj4+Pj4gDQo+Pj4+PiANCj4+Pj4+IA0KPj4+ Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+ IE9BdXRoIG1haWxpbmcgbGlzdA0KPj4+Pj4gT0F1dGhAaWV0Zi5vcmcNCj4+Pj4+IGh0dHBzOi8v bmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJm dw0KPj4+Pj4gdyANCj4+Pj4+IHcuaWV0Zi5vcmclMmZtYWlsbWFuJTJmbGlzdGluZm8lMmZvYXV0 aCZkYXRhPTAxJTdjMDElN2N0b255bmFkJTQwbQ0KPj4+Pj4gaQ0KPj4+Pj4gY3Jvc29mdC5jb20l N2M5NDU2NjcwMDc1ZDA0YTUxZjg1NTA4ZDJlNTliYTI5NCU3YzcyZjk4OGJmODZmMTQxYWY5DQo+ Pj4+PiAxIA0KPj4+Pj4gYWIyZDdjZDAxMWRiNDclN2MxJnNkYXRhPU5EM3lkYVhPc1BNc29SaEUw VXlxMHV6bkd5Nk1kWU9MWlFKSExoRVFLDQo+Pj4+PiBKDQo+Pj4+PiBzJTNkDQo+Pj4+PiANCj4+ Pj4gDQo+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+Pj4+IE9BdXRoIG1haWxpbmcgbGlzdA0KPj4+PiBPQXV0aEBpZXRmLm9yZw0KPj4+PiBodHRw czovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzYSUy ZiUyZnd3DQo+Pj4+IHcgDQo+Pj4+IC5pZXRmLm9yZyUyZm1haWxtYW4lMmZsaXN0aW5mbyUyZm9h dXRoJmRhdGE9MDElN2MwMSU3Y3RvbnluYWQlNDBtaWMNCj4+Pj4gcg0KPj4+PiBvc29mdC5jb20l N2M5NDU2NjcwMDc1ZDA0YTUxZjg1NTA4ZDJlNTliYTI5NCU3YzcyZjk4OGJmODZmMTQxYWY5MWFi DQo+Pj4+IDIgDQo+Pj4+IGQ3Y2QwMTFkYjQ3JTdjMSZzZGF0YT1ORDN5ZGFYT3NQTXNvUmhFMFV5 cTB1em5HeTZNZFlPTFpRSkhMaEVRS0pzJTMNCj4+Pj4gZA0KPj4+IA0KPj4+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4gT0F1dGggbWFpbGluZyBs aXN0DQo+Pj4gT0F1dGhAaWV0Zi5vcmcNCj4+PiBodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3Rl Y3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzYSUyZiUyZnd3dy4NCj4+PiBpZXRmLm9yZyUy Zm1haWxtYW4lMmZsaXN0aW5mbyUyZm9hdXRoJmRhdGE9MDElN2MwMSU3Y3RvbnluYWQlNDBtaWNy bw0KPj4+IHMgDQo+Pj4gb2Z0LmNvbSU3Yzk0NTY2NzAwNzVkMDRhNTFmODU1MDhkMmU1OWJhMjk0 JTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDcNCj4+PiBjIGQwMTFkYjQ3JTdjMSZzZGF0YT1ORDN5 ZGFYT3NQTXNvUmhFMFV5cTB1em5HeTZNZFlPTFpRSkhMaEVRS0pzJTNkDQo+PiANCj4gDQo+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IE9BdXRoIG1h aWxpbmcgbGlzdA0KPiBPQXV0aEBpZXRmLm9yZw0KPiBodHRwczovL25hMDEuc2FmZWxpbmtzLnBy b3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzYSUyZiUyZnd3dy5pDQo+IGV0Zi5vcmcl MmZtYWlsbWFuJTJmbGlzdGluZm8lMmZvYXV0aCUwYSZkYXRhPTAxJTdjMDElN2N0b255bmFkJTQw bWljcm8NCj4gc29mdC5jb20lN2M5NDU2NjcwMDc1ZDA0YTUxZjg1NTA4ZDJlNTliYTI5NCU3Yzcy Zjk4OGJmODZmMTQxYWY5MWFiMmQ3Yw0KPiBkMDExZGI0NyU3YzEmc2RhdGE9QkxxU3VEaldMWTcy ZkdtMFVycEx3eFFWbmFtTWVsZ2dKZU9wWUpFU1ZGcyUzZA0KDQo= From nobody Wed Nov 4 20:58:41 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC60E1B3950 for ; Wed, 4 Nov 2015 20:58:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A2ku77P_ldyV for ; Wed, 4 Nov 2015 20:58:31 -0800 (PST) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::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 8A1DB1B3943 for ; Wed, 4 Nov 2015 20:58:26 -0800 (PST) Received: by pabfh17 with SMTP id fh17so75269705pab.0 for ; Wed, 04 Nov 2015 20:58:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb_com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=HsDpw8fbFTEPyTfzuNph2A9lvXXMvQoiheBJCEumfF8=; b=rg53J7H3Ix+R05ZvtJvUUO4BSphJLPIEbebkUgHJCMGlIBEqrs+W18Cf8htjKAdFSl DqIzfHHtJ4v5THqopOSlTmMpXM+z7S74n46eInqOlVfRlCbYCj6b/l6k58dMB09r6zrH 3JrTtDss/2nbX3eQrt2x1Lt6wrkMgQY5/YgxUiM4PWniDI4U22d9iN3AcxswEi9mJtOR wtpSrob3hQ1RQAsaACKwy7L134Ji46Q2t/4RNIUiPdc2mCsmhEBvqh6kaZLJ3EvVU3qm BW8USjkN4+l1d9qH2E93VpffJulyoymluc/TSDDuYzkBvWtQFLQhDBlTOwf2AjECj/dL UJow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=HsDpw8fbFTEPyTfzuNph2A9lvXXMvQoiheBJCEumfF8=; b=U8cLYCvf6uchT/aI50wv1d/FE7GrsPVpph6ke4trSMnDz3PaUiqjwXeDly6yledM16 zBi9p5MDQgwBjwVBIMCdA2iU5MEUNIe6iQGOa4SY1vfYTBEA5fYb+4puMbgHKYoZABA2 6w7EdkE+RD27X/x1L5iDu1PxrEu90xtGbA4vqmp3Ry+7FaqvJU2yGnGHQYEfaOqkM6rq kWYIF4RkosBj5j6+EbiteZO+XKenCTp1B0cfqSJK7b5Sub6KxJZYVoDZRlpI2a8DQqCx pnbi4qEU2byvtLRYiMwFKz1bW+jNfae6wih2TNptNsTm68I8txYcPRA897Zz5jw00i1+ 1dmg== X-Gm-Message-State: ALoCoQlyCNb6Ym/tf8feo2afx3GazsLFL+qQjl6hgu7fVcrRpSDloXV4QfOyxKDjzcRF+ezsu96H X-Received: by 10.68.229.39 with SMTP id sn7mr6958940pbc.164.1446699506081; Wed, 04 Nov 2015 20:58:26 -0800 (PST) Received: from t20010c40000030089044b9d401462547.v6.meeting.ietf94.jp (t20010c40000030089044b9d401462547.v6.meeting.ietf94.jp. [2001:c40:0:3008:9044:b9d4:146:2547]) by smtp.gmail.com with ESMTPSA id zk3sm5117989pbb.41.2015.11.04.20.58.24 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Nov 2015 20:58:25 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: John Bradley In-Reply-To: Date: Thu, 5 Nov 2015 13:58:23 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <4D05C317-FF58-4CDE-98BE-D4ED1E078526@ve7jtb.com> References: <563AA216.5010109@gmx.net> <89A6E4DE-263B-4DB4-8882-54FA7103C721@mit.edu> <82079E8A-2AC8-4A42-9AF7-77FF2A3CAFC2@ve7jtb.com> <9E23AF3A-F758-4CB4-B920-4E1E2F61BCF4@ve7jtb.com> To: Anthony Nadalin X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 04:58:40 -0000 Good to know. So the AS needs to expose a public key for the TPM to = use for encryption. I am guessing you are not using a encrypted JWK = for that. What is the format the TPM produces the wrapped key in? John B. > On Nov 5, 2015, at 1:55 PM, Anthony Nadalin = wrote: >=20 > I can say on all windows based devices (pc, xbox, phone, etc) with = only TPM 1.1 this will be the approach so it will be commonly used=20 >=20 > -----Original Message----- > From: John Bradley [mailto:ve7jtb@ve7jtb.com]=20 > Sent: Wednesday, November 4, 2015 8:52 PM > To: Anthony Nadalin > Cc: Justin Richer ; > Subject: Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs = spec addressing final shepherd comment >=20 > OK, no good reason unless the client is using a HSM that can do HMAC = and can export a symmetric key wrapped in a asymmetric key provided by = the AS. >=20 > We don=E2=80=99t currently cover that use case of sending a wrapped = symmetric key to the AS in POP key distribution. =20 > I don=E2=80=99t know how common that is going to be, but it is worth = thinking about defining. >=20 > John B. >=20 >> On Nov 5, 2015, at 1:45 PM, Anthony Nadalin = wrote: >>=20 >> Not sure why you think its weaker as it would be a wrapped key that=20= >> the hardware produces >>=20 >> -----Original Message----- >> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of John Bradley >> Sent: Wednesday, November 4, 2015 8:43 PM >> To: Justin Richer >> Cc: >> Subject: Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs=20 >> spec addressing final shepherd comment >>=20 >> In the asymmetric case the use of a HSM or secure element is the = argument for the client selecting the public key. In those cases the = client is doing the key gen in hardware so one hopes it is OK. In the = symetric case the client generating the key is weaker (as in I can=E2=80=99= t think of any really good reason). >>=20 >>=20 >>> On Nov 5, 2015, at 1:35 PM, Justin Richer wrote: >>>=20 >>> I=E2=80=99d argue that it=E2=80=99s best practice, and in line with = other parts of OAuth, if we assume the server generates it in the normal = case (issuer -> presenter). Client generated token keys should be an = exception, especially in the asymmetric case. >>>=20 >>> =E2=80=94 Justin >>>=20 >>>> On Nov 5, 2015, at 1:32 PM, John Bradley wrote: >>>>=20 >>>> Agreed the only real difference is the quality of the key. If the = server generates it, then it knows that the client is not using the = fixed hex value of DEADBEEF for everything. >>>>=20 >>>> John B. >>>>> On Nov 5, 2015, at 9:25 AM, Hannes Tschofenig = wrote: >>>>>=20 >>>>> I agree that the effect is the same. =46rom a security point of = view=20 >>>>> there is only an impact if one of the two parties is in a better=20= >>>>> position to generate random numbers, which is the basis for=20 >>>>> generating a high entropy symmetric key. >>>>>=20 >>>>> On 11/04/2015 11:51 PM, Mike Jones wrote: >>>>>> Thanks for the detailed read, Brian. You=E2=80=99re right that = in the=20 >>>>>> symmetric case, either the issuer or the presenter can create the=20= >>>>>> symmetric PoP key and share it with the other party, since the = effect is equivalent. >>>>>> I suspect that both the key distribution draft and this draft=20 >>>>>> should be updated with a sentence or two saying that either=20 >>>>>> approach can be taken. Do others concur? >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> -- Mike >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> *From:*Brian Campbell [mailto:bcampbell@pingidentity.com] >>>>>> *Sent:* Thursday, November 05, 2015 7:48 AM >>>>>> *To:* Mike Jones >>>>>> *Cc:* Kepeng Li; oauth@ietf.org >>>>>> *Subject:* Re: [OAUTH-WG] Proof-of-Possession Key Semantics for=20= >>>>>> JWTs spec addressing final shepherd comment >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> +1 for the diagrams making the document more understandable. >>>>>>=20 >>>>>> One little nit/question, step 1 in both Symmetric and Asymmetric=20= >>>>>> keys shows the Presenter sending the key to the Issuer. It's=20 >>>>>> possible, however, for the key to be sent the other way. = Presenter=20 >>>>>> sending it to the Issuer is probably preferred for asymmetric,=20 >>>>>> especially if the client can secure the private keys in hardware. >>>>>> But I don't know if one way or the other is clearly better for=20 >>>>>> symmetric case and PoP key distribution currently has it the = other=20 >>>>>> way = . >>>>>> Should the intro text somehow mention the possibility that the=20 >>>>>> Issuer could create the key and send it to the Presenter? >>>>>>=20 >>>>>> I know it's only the introduction but it was just something that=20= >>>>>> jumped out at me. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On Wed, Nov 4, 2015 at 9:04 AM, Mike Jones=20 >>>>>> > wrote: >>>>>>=20 >>>>>> Thanks for suggesting the diagrams, Kepeng. They make the = document=20 >>>>>> more understandable. >>>>>>=20 >>>>>> -- Mike >>>>>>=20 >>>>>> = ------------------------------------------------------------------ >>>>>> - >>>>>> ----- >>>>>>=20 >>>>>> *From: *Kepeng Li >>>>>> *Sent: *=E2=80=8E11/=E2=80=8E5/=E2=80=8E2015 12:57 AM >>>>>> *To: *Mike Jones ; >>>>>> oauth@ietf.org >>>>>> *Subject: *Re: Proof-of-Possession Key Semantics for JWTs spec=20 >>>>>> addressing final shepherd comment >>>>>>=20 >>>>>> Thank you Mike. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> The diagrams look good to me. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Kind Regards >>>>>>=20 >>>>>> Kepeng >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> *=E5=8F=91=E4=BB=B6=E4=BA=BA**: *Mike Jones = >>>>> > >>>>>> *=E6=97=A5=E6=9C=9F**: *Thursday, 5 November, 2015 12:32 am >>>>>> *=E8=87=B3**: *"oauth@ietf.org " = >>>>> > >>>>>> *=E6=8A=84=E9=80=81**: *Li Kepeng >>>>> > >>>>>> *=E4=B8=BB=E9=A2=98**: *Proof-of-Possession Key Semantics for = JWTs spec addressing=20 >>>>>> final shepherd comment >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Proof-of-Possession Key Semantics for JWTs draft -06 addresses = the=20 >>>>>> remaining document shepherd comment =E2=80=93 adding use case = diagrams to=20 >>>>>> the introduction. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> The updated specification is available at: >>>>>>=20 >>>>>> =C2=B7 = https://na01.safelinks.protection.outlook.com/?url=3Dhttp%3a%2f%2ftools.ie= tf.org%2fhtml%2fdraft-ietf-oauth-proof-of-possession-06&data=3D01%7c01%7ct= onynad%40microsoft.com%7c9456670075d04a51f85508d2e59ba294%7c72f988bf86f141= af91ab2d7cd011db47%7c1&sdata=3D6hE6dOO0I1%2ffF005rVknyOFHuB18gdpZg9dftExLt= Cw%3d >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> An HTML formatted version is also available at: >>>>>>=20 >>>>>> =C2=B7 =20 >>>>>> = https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fs >>>>>> e=20 >>>>>> = lf-issued.info%2fdocs%2fdraft-ietf-oauth-proof-of-possession-06.ht >>>>>> m >>>>>> = l&data=3D01%7c01%7ctonynad%40microsoft.com%7c9456670075d04a51f85508d >>>>>> 2=20 >>>>>> = e59ba294%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=3DEQd4rUcuyqdS >>>>>> P gmibtcfjMpJm6RWWwCZC85%2bCboEs54%3d >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> -- Mike >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> P.S. This note was also posted at=20 >>>>>> = https://na01.safelinks.protection.outlook.com/?url=3Dhttp%3a%2f%2fself-iss= ued.info%2f%3fp%3d1471&data=3D01%7c01%7ctonynad%40microsoft.com%7c94566700= 75d04a51f85508d2e59ba294%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=3DTM= fX1tG5qucl%2be2KVpyMBuj72ZQ%2f%2bEKGoTyJyf%2bfJi4%3d and as @selfissued = . >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org =20 >>>>>> = https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fw >>>>>> w=20 >>>>>> = w.ietf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonynad%40m >>>>>> i >>>>>> = crosoft.com%7c9456670075d04a51f85508d2e59ba294%7c72f988bf86f141af9 >>>>>> 1=20 >>>>>> = ab2d7cd011db47%7c1&sdata=3DND3ydaXOsPMsoRhE0Uyq0uznGy6MdYOLZQJHLhEQK >>>>>> J >>>>>> s%3d >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> = https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fw >>>>>> w=20 >>>>>> = w.ietf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonynad%40m >>>>>> i >>>>>> = crosoft.com%7c9456670075d04a51f85508d2e59ba294%7c72f988bf86f141af9 >>>>>> 1=20 >>>>>> = ab2d7cd011db47%7c1&sdata=3DND3ydaXOsPMsoRhE0Uyq0uznGy6MdYOLZQJHLhEQK >>>>>> J >>>>>> s%3d >>>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> = https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fww >>>>> w=20 >>>>> = .ietf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonynad%40mic >>>>> r >>>>> = osoft.com%7c9456670075d04a51f85508d2e59ba294%7c72f988bf86f141af91ab >>>>> 2=20 >>>>> = d7cd011db47%7c1&sdata=3DND3ydaXOsPMsoRhE0Uyq0uznGy6MdYOLZQJHLhEQKJs%3 >>>>> d >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> = https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww. >>>> = ietf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonynad%40micro >>>> s=20 >>>> = oft.com%7c9456670075d04a51f85508d2e59ba294%7c72f988bf86f141af91ab2d7 >>>> c d011db47%7c1&sdata=3DND3ydaXOsPMsoRhE0Uyq0uznGy6MdYOLZQJHLhEQKJs%3d= >>>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> = https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.i >> = etf.org%2fmailman%2flistinfo%2foauth%0a&data=3D01%7c01%7ctonynad%40micro >> = soft.com%7c9456670075d04a51f85508d2e59ba294%7c72f988bf86f141af91ab2d7c >> d011db47%7c1&sdata=3DBLqSuDjWLY72fGm0UrpLwxQVnamMelggJeOpYJESVFs%3d >=20 From nobody Wed Nov 4 22:17:37 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D51931ACD96 for ; Wed, 4 Nov 2015 22:17:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NzsauO45SLsB for ; Wed, 4 Nov 2015 22:17:34 -0800 (PST) Received: from mail.amsl.com (mail.amsl.com [IPv6:2001:1900:3001:11::28]) by ietfa.amsl.com (Postfix) with ESMTP id 8E1561ACD95 for ; Wed, 4 Nov 2015 22:17:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 6B9961E59F2 for ; Wed, 4 Nov 2015 22:16:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DOHNvWYk9VSZ for ; Wed, 4 Nov 2015 22:16:52 -0800 (PST) Received: from dhcp-28-33.meeting.ietf94.jp (dhcp-28-33.meeting.ietf94.jp [133.93.28.33]) by c8a.amsl.com (Postfix) with ESMTPA id 22A521E59F1 for ; Wed, 4 Nov 2015 22:16:52 -0800 (PST) From: Alexa Morris Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Wed, 4 Nov 2015 22:17:34 -0800 Message-Id: <35489170-4E48-469A-B7D8-B5133A1EB470@amsl.com> To: oauth@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Sendlaterdate: Wed, 4 Nov 2015 22:17:34 -0800 X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: [OAUTH-WG] Queue for oauth Remote Attendees X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 06:17:36 -0000 If you are planning to participate in the oauth session here at IETF 94 = today =97 either locally in Yokohama or as a remote participant =97 we = want to make sure that you are aware that the IETF is providing remote = participants with a fairly new way to ask questions or make comments. In = addition to using the Jabber room, for the oauth session there is also = the opportunity for remote participants to enter a virtual queue and ask = questions directly into the meeting room.=20 This experimental queue was used in several sessions at IETF 92 and IETF = 93, so you may have already seen it in action. There will be two queues = for the oauth session =97 a virtual queue and an actual (in-room) queue. = Remote attendees will log into the Meetecho platform and will have a = virtual mic line that they can enter if they have a question or comment. = In-room participants will continue to use normal mic lines.=20 Instructions for remote participants are at = http://ietf94.conf.meetecho.com/index.php/Remote_Participation.=20 Information on how to join the Meetecho session is at = http://ietf94.conf.meetecho.com/. Verify that you are WebRTC compliant (required to use the virtual queue) = by performing a self-test here: = http://ietf94.conf.meetecho.com/index.php/Self_Test.=20 Regards, Alexa ---------- Alexa Morris / Executive Director / IETF 48377 Fremont Blvd., Suite 117, Fremont, CA 94538 Phone: +1.510.492.4089 / Fax: +1.510.492.4001 Email: amorris@amsl.com Managed by Association Management Solutions (AMS) Forum Management, Meeting and Event Planning www.amsl.com From nobody Wed Nov 4 23:05:34 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DA371B3B10 for ; Wed, 4 Nov 2015 23:05: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, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GxCX_Pwh-gzD for ; Wed, 4 Nov 2015 23:05:30 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0787.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::787]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0310C1B3A15 for ; Wed, 4 Nov 2015 23:05:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=6kzazm+hgfwg8MNjnWkXn8AVGpjGFegVtuVBsnXBkMY=; b=DDNv3D+TPhEmYlvyO32qBYOQOxH7HVfWYD6BeLN+HHjISeyme2yKXaPAhUG00WcpdMZPYyWfdiOsGzZup3vlKgdq7mlW75OUx2jonx1sqmcaCSbI/v1EDeRqrQhjD8FZbHwTUB4foyN7Gxb0U9Hf9ISRSKvVMv+kBAaPWdZgzTY= Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB441.namprd03.prod.outlook.com (10.141.141.142) with Microsoft SMTP Server (TLS) id 15.1.312.18; Thu, 5 Nov 2015 07:05:07 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0318.003; Thu, 5 Nov 2015 07:05:07 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: Inaccuracy in last point in JWSREQ presentation about registering request_object_signing_alg Thread-Index: AdEXmEuylo/VpcIHSmuiewi03AdI9w== Date: Thu, 5 Nov 2015 07:05:07 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [2001:c40:0:3032:bdaf:f166:976e:9bb] x-microsoft-exchange-diagnostics: 1; BY2PR03MB441; 5:rylSKngf9OgFlMLa4Btb3Xj9fS6qkqQBlwEkPTIQAuDeLlbBZcRjLZ5kNvVhNWemKEHwzciaOTRYC6BpnIr7XCuemguStfIbYOdHh04+Ig66pL5HFo2M0oxV9zBBuWZR6Hn6VqcarVzQArc8bC6BnQ==; 24:lorJuQohpjazUn0V5n4V7E+pw1vvl+i7KCli10g1pFbaaWzKMDp63lwoOLFTWqKf7eM4Dp+t14PCDjlrWMj5XO7y9kH0waYZoFVHgB7QsSc=; 20:kaOfg1SOQnfT9p0CXlAzQEyxg89h8BdV4a8hnjMib8xpW7YEgpSMVKccM4UsjPR9D3YIZrRd5dWhHGknc5a/Iw== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB441; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425024)(601004)(2401047)(520078)(5005006)(8121501046)(10201501046)(3002001)(61426024)(61427024); SRVR:BY2PR03MB441; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB441; x-forefront-prvs: 0751474A44 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(189002)(199003)(5008740100001)(40100003)(5004730100002)(450100001)(76576001)(122556002)(5007970100001)(10290500002)(229853001)(2351001)(102836002)(15975445007)(2900100001)(97736004)(5005710100001)(8990500004)(10400500002)(77096005)(74316001)(99286002)(105586002)(2501003)(106356001)(5002640100001)(19625215002)(87936001)(19609705001)(110136002)(5001960100002)(11100500001)(92566002)(81156007)(19617315012)(86612001)(10090500001)(189998001)(107886002)(5003600100002)(86362001)(16236675004)(33656002)(101416001)(54356999)(19580395003)(50986999)(15395725005)(19300405004)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB441; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR03MB4421A1068FDEA4FE95129B0F5290BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Nov 2015 07:05:07.4297 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB441 Archived-At: Subject: [OAUTH-WG] Inaccuracy in last point in JWSREQ presentation about registering request_object_signing_alg X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 07:05:32 -0000 --_000_BY2PR03MB4421A1068FDEA4FE95129B0F5290BY2PR03MB442namprd_ Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable The last bullet of the last slide of https://www.ietf.org/proceedings/94/sl= ides/slides-94-oauth-5.pdf says: Section 7 - False statement: =1B$B!|=1B(B The request_object_signing_alg OAuth Dynamic Client Regist= ration Metadata is pending registration by OpenID Connect Dynamic Registrat= ion specification. =1B$B!|=1B(B The registry doesn't have it and Connect's Registration "m= akes no requests of IANA" This not false. (I didn=1B$B!G=1B(Bt say so from the microphone in the roo= m in the interest of time.) http://openid.net/specs/openid-connect-registr= ation-1_0-29.html#DynRegContents, the current errata 2 draft version, conta= ins the registration request for request_object_signing_alg. It has not ye= t been submitted to IANA but it will be soon. -- Mike --_000_BY2PR03MB4421A1068FDEA4FE95129B0F5290BY2PR03MB442namprd_ Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable

The last bullet of the last slide of https://www.ietf.org/proceedings/94/slides/slides-94-oauth-5.pdf says:<= o:p>

  Section 7

  – False statement:

    =1B$B!|=1B(B The request_object_s= igning_alg OAuth Dynamic Client Registration Metadata is pending registrati= on by OpenID Connect Dynamic Registration specification.

    =1B$B!|=1B(B The registry doesn't= have it and Connect's Registration "makes no requests of IANA"

 

This not false.  (I didn=1B$B!G=1B(Bt say so fr= om the microphone in the room in the interest of time.)  http://openid.net/specs/openid-connect-registration-1_0-29.html#DynRegConte= nts, the current errata 2 draft version, contains the registration requ= est for request_object_signing_alg.  It has not yet been submitted to = IANA but it will be soon.

 

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

 

--_000_BY2PR03MB4421A1068FDEA4FE95129B0F5290BY2PR03MB442namprd_-- From nobody Thu Nov 5 00:21:56 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 458041A874F for ; Thu, 5 Nov 2015 00:21:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7AKEDEtnNa0x for ; Thu, 5 Nov 2015 00:21:53 -0800 (PST) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B0771A21BD for ; Thu, 5 Nov 2015 00:21:53 -0800 (PST) X-AuditID: 12074423-f793f6d000007fc1-b8-563b11a0da15 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 7F.55.32705.0A11B365; Thu, 5 Nov 2015 03:21:52 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id tA58LpEt001691 for ; Thu, 5 Nov 2015 03:21:52 -0500 Received: from dhcp-29-147.meeting.ietf94.jp (dhcp-29-147.meeting.ietf94.jp [133.93.29.147]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id tA58LmF7000800 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 5 Nov 2015 03:21:51 -0500 From: Justin Richer Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <329E288C-A6CB-47A5-8F6E-AD4B9B05D16B@mit.edu> Date: Thu, 5 Nov 2015 17:21:47 +0900 To: "" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCIsWRmVeSWpSXmKPExsUixG6nortA0DrMoGmjkMXJt6/YHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVcfivSEEbU8XZQxPZGxhvMHYxcnJICJhIXDu+EMoWk7hwbz1b FyMXh5DAYiaJM/vaoZyjjBK3/vawgVQJCbxlkli1Xh/EZhNQlZi/8hYTiM0soC7xZ94lZghb W2LZwtdgtrCAmsSk94/Zuxg5OHgFrCQO3PcECbMIqEj07P8NtlgEqHXN+Z9gY3gF9CRe3brM CnGQrMTu34+YJjDyzUKyYRaSDbOQtCxgZF7FKJuSW6Wbm5iZU5yarFucnJiXl1qka6aXm1mi l5pSuokRHGAuyjsY/xxUOsQowMGoxMNrUG0VJsSaWFZcmXuIUZKDSUmUt+IVUIgvKT+lMiOx OCO+qDQntfgQowQHs5IIb/F3oBxvSmJlVWpRPkxKmoNFSZx30w++ECGB9MSS1OzU1ILUIpis DAeHkgSvqoB1mJBgUWp6akVaZk4JQpqJgxNkOA/QcLAa3uKCxNzizHSI/ClGXY4FP26vZRJi ycvPS5US5xUCKRIAKcoozYObA0oMrbGyk18xigO9JczbAVLFA0wqcJNeAS1hAlrC1GoBsqQk ESEl1cC4TmCNwa17272DD54wOPT03zz9hDN1ewuLA+49mK8ouMJCtsp9lxFDcqd46aH5TTeW +f22LvU8N0XKJ2Zi6gmplTkxSV4sh48sb2abd1N804pnS/dJ7+c2ttrRe1nv/cvFRdXNl5dn TtCWEHsYYDnnoXtu/Y/XJ5zmKCtL1SybaLcq5vihzZ55SizFGYmGWsxFxYkAiBQbU+cCAAA= Archived-At: Subject: [OAUTH-WG] UMA Resource Set Registration X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 08:21:55 -0000 As brought up in the F2F today in Yokohama, the UMA Resource Set = Registration document is here: https://docs.kantarainitiative.org/uma/draft-oauth-resource-reg.html The ID has expired and is out of sync with the Kantara document. =E2=80=94 Justin= From nobody Thu Nov 5 00:35:49 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C83781A00DB for ; Thu, 5 Nov 2015 00:35:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F8YwoCbTyNYN for ; Thu, 5 Nov 2015 00:35:46 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25F881A007C for ; Thu, 5 Nov 2015 00:35:46 -0800 (PST) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id tA58ZjkN029158 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 5 Nov 2015 08:35:45 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id tA58Zit4009450 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 5 Nov 2015 08:35:44 GMT Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24]) by userv0122.oracle.com (8.13.8/8.13.8) with ESMTP id tA58ZiFA011277; Thu, 5 Nov 2015 08:35:44 GMT Received: from [133.93.38.120] (/133.93.38.120) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 05 Nov 2015 00:35:43 -0800 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Phil Hunt X-Mailer: iPhone Mail (13B143) In-Reply-To: <329E288C-A6CB-47A5-8F6E-AD4B9B05D16B@mit.edu> Date: Thu, 5 Nov 2015 17:35:41 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <06B31DE0-ACD3-4E20-B4F3-A165931F6D8A@oracle.com> References: <329E288C-A6CB-47A5-8F6E-AD4B9B05D16B@mit.edu> To: Justin Richer X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Cc: "" Subject: Re: [OAUTH-WG] UMA Resource Set Registration X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 08:35:47 -0000 I am thinking that the api management perspective might be very different th= an UMAs. Eg we want to automatically register resource servers to be managed= and negotiate token format and introspection.=20 Today this is all done manually both when installing and when packaging soft= ware for distribution in the form of multiple SKUs targeted at each major cl= oud provider and each enterprise oauth server.=20 In order to have a benefit we have to have interest to support it. Judging b= y the level of interest in the meeting I am not sure the pain/opportunity th= reshold to drive a spec is there yet.=20 Phil > On Nov 5, 2015, at 17:21, Justin Richer wrote: >=20 > As brought up in the F2F today in Yokohama, the UMA Resource Set Registrat= ion document is here: >=20 > https://docs.kantarainitiative.org/uma/draft-oauth-resource-reg.html >=20 > The ID has expired and is out of sync with the Kantara document. >=20 > =E2=80=94 Justin > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Thu Nov 5 01:22:33 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D00991A8908 for ; Thu, 5 Nov 2015 01:22:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_8BIT_HEADER=0.3] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CUvMT9KyiLEA for ; Thu, 5 Nov 2015 01:22:30 -0800 (PST) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::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 A60DF1A8784 for ; Thu, 5 Nov 2015 01:22:29 -0800 (PST) Received: by lbbkw15 with SMTP id kw15so25073235lbb.0 for ; Thu, 05 Nov 2015 01:22:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wahlstromstekniska_se.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ZbmPdug6vufDBs7yAMZdAKHXIQcLGuYodl0fukEby9Y=; b=ckY3DzGPUfpaEMdT8xy+h2uyknynpmdjyThXrap+JC3aw/GLr2VziGcH6aGoAK1cNC kuTMbgxP5f5mqRI1Zgmw5/7gnP+25PfPBDy0VXXxzH5yS2MCW2ctvvvA3FiuFDtrrUXX 3tlOSdZaHTWEH/CcB4kb0pRTIBXCUELFinzL4cD1EquELkiZxpx5WtxYmBT0uJEZbdFt vIfhNEEQ9t3JpSvWCjmYhVpF3Hol5uIjakER4hVZz2R5rO9AXga42o1Ji60oUoLAGIEL QXdWaj5BGeo3eyoFAniFiyu6K1dyl/ZjZN21oBa0os0LqVNgqyQsrdzjUeAA+AKK6Qta gmKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=ZbmPdug6vufDBs7yAMZdAKHXIQcLGuYodl0fukEby9Y=; b=aiQNDKbTlkcVGs9b0w+3BtRR1JEFK0PV+4iVZWoMoaDKKg+FoQsaoTQUc6MlKcjc9a F2BlKDx/M1vxwto6brd0+b+9khL5hpxPXsIpTV18YtWEmi34w+h1tn7stKysTdjSayga pnLIUBdNeHSDTJHrIkQF9qh3VRL9BEc2uBXjf8NBM6uhikWlmaCX9pI6qG8QHpkj4h2v 3gaQbVm7koxVZEGEa8pyQn+CQaTBQAdEpC54petueb8Y3Skk3lCmaOg+YngXUfVVrHEK UNAN7ESR5Bqd/Akm1KcsJr6bQHBYAKTD44FZLBtBdqfNBo5vbQWbeuNThMo8ylBb3vrp Uk+Q== X-Gm-Message-State: ALoCoQlEWaORIq1CMvcVGrRTg1qPjuLamhcQBqFv50ZcF1B/yIfdbyyInPpC7FZBGvKfwFziMvTz X-Received: by 10.112.202.35 with SMTP id kf3mr3194057lbc.19.1446715347858; Thu, 05 Nov 2015 01:22:27 -0800 (PST) Received: from [192.168.1.4] (37-247-26-197.customers.ownit.se. [37.247.26.197]) by smtp.gmail.com with ESMTPSA id e63sm836150lfi.1.2015.11.05.01.22.26 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Nov 2015 01:22:27 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: =?utf-8?Q?Erik_Wahlstr=C3=B6m?= In-Reply-To: <06B31DE0-ACD3-4E20-B4F3-A165931F6D8A@oracle.com> Date: Thu, 5 Nov 2015 10:22:24 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2FBC9C7B-110E-462C-B399-CEBEDF202053@wahlstromstekniska.se> References: <329E288C-A6CB-47A5-8F6E-AD4B9B05D16B@mit.edu> <06B31DE0-ACD3-4E20-B4F3-A165931F6D8A@oracle.com> To: Phil Hunt X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "" Subject: Re: [OAUTH-WG] UMA Resource Set Registration X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 09:22:32 -0000 The concepts on resource registration is also very important when it = comes to IoT so I think we will get there soon enough. / Erik > On 05 Nov 2015, at 09:35, Phil Hunt wrote: >=20 > I am thinking that the api management perspective might be very = different than UMAs. Eg we want to automatically register resource = servers to be managed and negotiate token format and introspection.=20 >=20 > Today this is all done manually both when installing and when = packaging software for distribution in the form of multiple SKUs = targeted at each major cloud provider and each enterprise oauth server.=20= >=20 > In order to have a benefit we have to have interest to support it. = Judging by the level of interest in the meeting I am not sure the = pain/opportunity threshold to drive a spec is there yet.=20 >=20 > Phil >=20 >> On Nov 5, 2015, at 17:21, Justin Richer wrote: >>=20 >> As brought up in the F2F today in Yokohama, the UMA Resource Set = Registration document is here: >>=20 >> https://docs.kantarainitiative.org/uma/draft-oauth-resource-reg.html >>=20 >> The ID has expired and is out of sync with the Kantara document. >>=20 >> =E2=80=94 Justin >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Thu Nov 5 03:09:38 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DBB81ACDFB for ; Thu, 5 Nov 2015 03:09:37 -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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id frAJK4z7qJKT for ; Thu, 5 Nov 2015 03:09:35 -0800 (PST) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::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 4DC1F1A8AB8 for ; Thu, 5 Nov 2015 03:09:35 -0800 (PST) Received: by wmww144 with SMTP id w144so4388415wmw.1 for ; Thu, 05 Nov 2015 03:09:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=tKbDWO2USM9XlyTBf0EguNOrbnYbAQi0vKRgvk7s68I=; b=wp/JOP4ru2Fb8nMXu2yIXiS/Q8cEdRgeX28z0e4OfKIcdC6GPoT8e54CWfE4OAp4um 6aA2AekOjc7tQN2hPx/f9BxJOZ/ZVjQmkVPniJx/Wi2DhTTKWayaGPS5EPNj+7J2gwNB mi7zCwxlc4BmTKmHoJp1t+XXmAhAUicslcxc5WPIWVPILBtrcHQeggyUXQAuiserWfMI QYCFhOjA6uIUPBvwJthxMZBYOe56APBuIrIg30vmh3NRzuFXOXQBWJYzRvRf+91PsfQj lNNLd21InKmhW7iXc4fa+q3tIg0/QnmaAL48wGeQLnCEVuQEP5wPRFU3G+lsLpwYrkYr UKNQ== X-Received: by 10.28.174.144 with SMTP id x138mr2959282wme.28.1446721773802; Thu, 05 Nov 2015 03:09:33 -0800 (PST) Received: from [10.36.226.98] ([80.169.137.63]) by smtp.googlemail.com with ESMTPSA id e63sm33544293wma.7.2015.11.05.03.09.32 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 05 Nov 2015 03:09:32 -0800 (PST) To: John Bradley References: <6A84AF37-C6FC-41DD-99D6-32A8DDD7A18A@mit.edu> <5637feb5.611a450a.bf33d.4307@mx.google.com> <563A2BCC.6030801@gmail.com> <77B2A3DD-3C0F-49EB-AD7F-9C4DAA6542AE@ve7jtb.com> From: Sergey Beryozkin Message-ID: <563B38EC.6000401@gmail.com> Date: Thu, 5 Nov 2015 11:09:32 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <77B2A3DD-3C0F-49EB-AD7F-9C4DAA6542AE@ve7jtb.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Sharing a client_id: is it good or bad ? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 11:09:37 -0000 Hi John, and Jim Thanks for the feedback On 04/11/15 22:20, John Bradley wrote: > For a native app you can have one clientID and no secret (same as having one secret for all of them) or you can use dynamic client registration to give each one a separate client_id and secret. > > The middle ground is to use PKCE and no client secret. > > The client generates a pkce challenge in the authorization request and then presents the verifier. You can then use that verifier to place a identifier for that app instance in the refresh/access tokens. That would allow the RS to differentiate between two clients with the same user on different devices. > That gets you more or less equivalent security, but binds the client instance to a user/device as part of the authorization flow, rather than by creating separate client_id for each instance and managing that. > > It is up to more of a deployer preference on what way to go. > We have a code dealing with the PKCE approach available on the server side, but I've had a little clue so far :-) about how practical it can be, thanks for the explanation, I'll have a deeper look, might ask a couple of questions later on... > I prefer the PKCE route personally, that requires a real user to be involved in the flow before the AS needs to store state. In open dynamic client registration you can face a denial of service attack by creating unlimited clients, that is harder to manage. > > One thing that will be coming up at the WG meeting today is the possibility of extending PKCE verification to refresh tokens as well as there current use with code. That would move the PKCE and client registration security even closer together. > Thanks, Sergey > John B. > >> On Nov 5, 2015, at 1:01 AM, Sergey Beryozkin wrote: >> >> Hi All >> >> I'm having a discussion with my colleagues on the pros and cons of sharing a client_id. >> >> For example, say we have N number of public mobile applications (the same application package, an application instance on an individual phone), and one approach is for each of these applications to have the same client_id. >> >> I've been trying to analyze why it can be bad and the only thing I can come up with is that there will be no (easy) way to track which application instance actually accessed a given RS. >> >> Can someone please explain what the pros and cons are of having the same client_id shared between public client applications. >> >> And what about multiple confidential clients being set up with the same id/secret. I suspect it is a bad idea but what is main line why it is a bad idea, lets say it is all done in the protected network, no chance of the bad clients interfering... >> >> >> >> Thanks, Sergey >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > From nobody Thu Nov 5 03:29:41 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 816E21A885F for ; Thu, 5 Nov 2015 03:29:40 -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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CMNgsSu2zk_S for ; Thu, 5 Nov 2015 03:29:38 -0800 (PST) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c: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 5F73A1A6F2E for ; Thu, 5 Nov 2015 03:29:38 -0800 (PST) Received: by wmeg8 with SMTP id g8so11423223wme.0 for ; Thu, 05 Nov 2015 03:29:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=fUIsDSJZ/L0d9S9fPTrP/soUwfc5i335ASXNN2VVnGk=; b=08Ph5PzsSEVIIP0wvMlFhjxdevBjqPy5KYu5Gbyi52a+YGlYUo+dbk+U+dToPjK1ES P1s707tGol5Bj7JN+oI/F13JGNk2F+edv98sjum15d2jYvWkJyJiTb1mTCdQkCROYBhb pPvcjyk2RJLeydp0vY1OWMYhe10Qzsupc4YxJ10iCBHNDTkZS3eDLWVoTS2SCBv76bzL f3EXwKwStbJIeNcZkujNqbti3b5zplW8GXCey0ZbLXRycGrUFRjYnZZyFtlK56A1dMDn 4g+aPJTkHSicMMyj1hcpjzSFxHiF99TF9Yrhp5rut4ZhrA7CY2nMzSGk0b725/aDxuXw jHVA== X-Received: by 10.28.7.67 with SMTP id 64mr2847225wmh.70.1446722976995; Thu, 05 Nov 2015 03:29:36 -0800 (PST) Received: from [10.36.226.98] ([80.169.137.63]) by smtp.googlemail.com with ESMTPSA id bo7sm6464709wjb.46.2015.11.05.03.29.35 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Nov 2015 03:29:35 -0800 (PST) To: John Bradley References: <6A84AF37-C6FC-41DD-99D6-32A8DDD7A18A@mit.edu> <5637feb5.611a450a.bf33d.4307@mx.google.com> <563A2BCC.6030801@gmail.com> <77B2A3DD-3C0F-49EB-AD7F-9C4DAA6542AE@ve7jtb.com> <563B38EC.6000401@gmail.com> From: Sergey Beryozkin Message-ID: <563B3D9F.20609@gmail.com> Date: Thu, 5 Nov 2015 11:29:35 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <563B38EC.6000401@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Sharing a client_id: is it good or bad ? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 11:29:40 -0000 Hi John On 05/11/15 11:09, Sergey Beryozkin wrote: > Hi John, and Jim > > Thanks for the feedback > On 04/11/15 22:20, John Bradley wrote: >> For a native app you can have one clientID and no secret (same as >> having one secret for all of them) or you can use dynamic client >> registration to give each one a separate client_id and secret. >> >> The middle ground is to use PKCE and no client secret. >> >> The client generates a pkce challenge in the authorization request and >> then presents the verifier. You can then use that verifier to place a >> identifier for that app instance in the refresh/access tokens. That >> would allow the RS to differentiate between two clients with the same >> user on different devices. >> That gets you more or less equivalent security, but binds the client >> instance to a user/device as part of the authorization flow, rather >> than by creating separate client_id for each instance and managing that. I guess you meant 'client_secret' in this last sentence as I was just about to ask if client_id was not needed when PKCE was used, but https://tools.ietf.org/html/rfc7636#page-9 clarified my confusion :-) Thanks, Sergey >> >> It is up to more of a deployer preference on what way to go. >> > We have a code dealing with the PKCE approach available on the server > side, but I've had a little clue so far :-) about how practical it can > be, thanks for the explanation, I'll have a deeper look, might ask a > couple of questions later on... >> I prefer the PKCE route personally, that requires a real user to be >> involved in the flow before the AS needs to store state. In open >> dynamic client registration you can face a denial of service attack by >> creating unlimited clients, that is harder to manage. >> >> One thing that will be coming up at the WG meeting today is the >> possibility of extending PKCE verification to refresh tokens as well >> as there current use with code. That would move the PKCE and client >> registration security even closer together. >> > Thanks, Sergey > >> John B. >> >>> On Nov 5, 2015, at 1:01 AM, Sergey Beryozkin >>> wrote: >>> >>> Hi All >>> >>> I'm having a discussion with my colleagues on the pros and cons of >>> sharing a client_id. >>> >>> For example, say we have N number of public mobile applications (the >>> same application package, an application instance on an individual >>> phone), and one approach is for each of these applications to have >>> the same client_id. >>> >>> I've been trying to analyze why it can be bad and the only thing I >>> can come up with is that there will be no (easy) way to track which >>> application instance actually accessed a given RS. >>> >>> Can someone please explain what the pros and cons are of having the >>> same client_id shared between public client applications. >>> >>> And what about multiple confidential clients being set up with the >>> same id/secret. I suspect it is a bad idea but what is main line why >>> it is a bad idea, lets say it is all done in the protected network, >>> no chance of the bad clients interfering... >>> >>> >>> >>> Thanks, Sergey >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> > -- Sergey Beryozkin Talend Community Coders http://coders.talend.com/ From nobody Thu Nov 5 04:48:34 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27A791B29DA for ; Thu, 5 Nov 2015 04:48:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.792 X-Spam-Level: X-Spam-Status: No, score=-1.792 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QcpXISHSCEaO for ; Thu, 5 Nov 2015 04:48:29 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0112.outbound.protection.outlook.com [207.46.100.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC3081B29D9 for ; Thu, 5 Nov 2015 04:48:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=K/+cXr9Rs9PXXW9NN4IhNDyLNcE690SJKcjAykxMflE=; b=gtoSy7gPDNkBMbZ3UCiZTAAhFsEqyaTi0DyTZ9XCTcKt70HTNY08Dq3w7ugV4Y32Zkeiji9CuMQ34cwwbroNFb/qO2s6rfbeTOfQuV+UptcY0RdMWb2EBn8DW/flNUFeBAY9JIqrigFSNHFvuJzhlWDtD1lVeFlStrbzoARU550= Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) with Microsoft SMTP Server (TLS) id 15.1.318.15; Thu, 5 Nov 2015 12:48:28 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0318.003; Thu, 5 Nov 2015 12:48:28 +0000 From: Mike Jones To: "oauth@ietf.org" , Nat Sakimura , "John Bradley" Thread-Topic: [OAUTH-WG] WGLC for draft-ietf-oauth-jwsreq-06 Thread-Index: AQHRCxY0a+EzJaqO+kOHPyEVOtLSO56NEKrg Date: Thu, 5 Nov 2015 12:48:27 +0000 Message-ID: References: <5626032F.7070700@gmx.net> In-Reply-To: <5626032F.7070700@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [210.160.37.23] x-microsoft-exchange-diagnostics: 1; BY2PR03MB442; 5:cCb0www1vZ2goR+yJ6pA8GN6H1/zMsY1WlKnMr+smsnpqpsquFGxefYIENexVWoHy5CDM5kWrn4KZ/1l6UXpEQw9gCS23N6S1kdWYA8DiNTNr8sQJwQoYZlcdydD0mPBmKyR0yZwL+TYqIkh9b8dJQ==; 24:YHw7L1fr1CAchZdAh50Ii0r9SYfkYA3VMb3zYlWASAyTJJsF9t3CVFtMMkTYVEpBJAl3vFHKRDPQ50sx4jyP3EzDb7MOHgcF0t1bxpNcoZI=; 20:u8xGJRIFQH/0SicQRR2RIVQc6DK5f3awuRPxOn3DSOEZ8MM8DptPxpdBjgCE2ah4kEgv3HkyJy7jR8ypt4BLvg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB442; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(189930954265078); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425024)(601004)(2401047)(8121501046)(520078)(5005006)(10201501046)(3002001)(61426024)(61427024); SRVR:BY2PR03MB442; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB442; x-forefront-prvs: 0751474A44 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(13464003)(53754006)(377454003)(52604005)(189002)(5005710100001)(230783001)(66066001)(54356999)(97736004)(106356001)(99286002)(105586002)(87936001)(76576001)(19580395003)(575784001)(76176999)(101416001)(86362001)(19580405001)(5007970100001)(5004730100002)(50986999)(86612001)(5002640100001)(40100003)(122556002)(10400500002)(5001920100001)(8990500004)(5001960100002)(106116001)(92566002)(189998001)(2501003)(10290500002)(11100500001)(5003600100002)(2900100001)(2950100001)(15975445007)(5001770100001)(81156007)(74316001)(77096005)(10090500001)(102836002)(5008740100001)(33656002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB442; H:BY2PR03MB442.namprd03.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:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Nov 2015 12:48:27.3267 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB442 Archived-At: Subject: Re: [OAUTH-WG] WGLC for draft-ietf-oauth-jwsreq-06 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 12:48:32 -0000 TXkgc2xpZ2h0bHkgbGF0ZSBXR0xDIHJldmlldyBmb2xsb3dzLi4uDQoNClNVQlNUQU5USVZFIElT U1VFUzoNCg0KU2VjdGlvbiAzLCBwYXJhZ3JhcGggODogIENoYW5nZSAiZXh0ZW5zaW9uIHZhcmlh YmxlcyBzdWNoIGFzICJub25jZSIsICJ1c2VyaW5mbyIsIGFuZCAiaWRfdG9rZW4iIiB0byAiZXh0 ZW5zaW9uIHBhcmFtZXRlcnMgc3VjaCBhcyAibm9uY2UiLCAibWF4X2FnZSIsIGFuZCAiY2xhaW1z IiIuICAoInVzZXJpbmZvIiBhbmQgImlkX3Rva2VuIiBhcmUgdmFsdWVzIHdpdGhpbiB0aGUgImNs YWltcyIgZXh0ZW5zaW9uIHBhcmFtZXRlci4pDQoNClNlY3Rpb24gNC4yLCBidWxsZXQgMjogIENo YW5nZSAiVGhlIG1heGltdW0gVVJMIGxlbmd0aCBzdXBwb3J0ZWQgYnkgSW50ZXJuZXQgRXhwbG9y ZXIgaXMgMjA4MyBBU0NJSSBjaGFyYWN0ZXJzIiB0byAiVGhlIG1heGltdW0gVVJMIGxlbmd0aCBz dXBwb3J0ZWQgYnkgb2xkZXIgdmVyc2lvbnMgb2YgSW50ZXJuZXQgRXhwbG9yZXIgd2FzIDIwODMg QVNDSUkgY2hhcmFjdGVycyIuICAoVGhpcyBoYXMgc2luY2UgYmVlbiBmaXhlZC4gIEkga25vdyAt IGJlY2F1c2UgSSBmaWxlZCB0aGUgYnVnIHRoYXQgcmVzdWx0ZWQgaW4gdGhlIGZpeCEgOi0pICkN Cg0KU2VjdGlvbiA0LjIuMSwgcGFyYWdyYXBoIDI6ICBDaGFuZ2UgInJlcXVlc3RlZCB2YWx1ZXMg Zm9yIENsYWltcyIgdG8gInByaXZhdGUgaW5mb3JtYXRpb24iLg0KDQpTZWN0aW9uIDUuMTogIENo YW5nZSAiVGhlIHJlc3VsdCBNQVkgYmUgZWl0aGVyIGEgc2lnbmVkIG9yIHVuc2lnbmVkIChwbGFp bnRleHQpIFJlcXVlc3QgT2JqZWN0IiB0byAiVGhlIHJlc3VsdCBNQVkgYmUgZWl0aGVyIGEgSldU IENsYWltcyBTZXQgcmVwcmVzZW50aW5nIHRoZSByZXF1ZXN0IHBhcmFtZXRlcnMgb3IgaWYgdGhl IEpXRSBpcyBhIG5lc3RlZCBKV1QsIGEgc2lnbmVkIEpXVCBjb250YWluaW5nIHRoZSByZXF1ZXN0 IHBhcmFtZXRlcnMiLg0KDQpTZWN0aW9uIDYsIHBhcmFncmFwaCAyOiAgQ2hhbmdlICJ0aGlzIGRv Y3VtZW50IGRlZmluZXMgYWRkaXRpb25hbCBlcnJvciB2YWx1ZXMgYXMgZm9sbG93cyIgdG8gInRo aXMgZG9jdW1lbnQgdXNlcyB0aGVzZSBhZGRpdGlvbmFsIGVycm9yIHZhbHVlcyIuDQoNClNlY3Rp b24gNzogIENoYW5nZSB0aGUgSUFOQSBDb25zaWRlcmF0aW9ucyB0ZXh0IHRvICJUaGlzIHNwZWNp ZmljYXRpb24gcmVxdWVzdHMgbm8gYWN0aW9ucyBieSBJQU5BLiINCg0KU2VjdGlvbiA4LCBzZWNv bmQgcGFyYWdyYXBoOiAgRGVsZXRlIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBwYXJhZ3Jh cGggYWJvdXQgbm90IHVzaW5nICJhbGciOiJub25lIi4gIFVzaW5nIGFuIFVuc2VjdXJlZCBKV1Mg aXMgbm8gd29yc2UgdGhhbiBzZW5kaW5nIHRoZSBwYXJhbWV0ZXJzIHRoZSB1c3VhbCB3YXkuDQoN Ck5JVFM6DQoNClNlY3Rpb24gMSwgYnVsbGV0IDM6IEluICJUaGUgYXV0aG9yaXphdGlvbiBzZXJ2 ZXIgdGhlbiBleGFtaW5lcyB0aGUgc2lnbmF0dXJlIGFuZCBzaG93IHRoZSBjb25mb3JtYW5jZSBz dGF0dXMgdG8gdGhlIGVuZC11c2VyLCB3aG8gd291bGQgaGF2ZSBzb21lIGFzc3VyYW5jZSBhcyB0 byB0aGUgbGVnaXRpbWFjeSBvZiB0aGUgcmVxdWVzdCB3aGVuIGF1dGhvcml6aW5nIGl0IiwgY2hh bmdlICJzaG93IiB0byAic2hvd3MiLg0KDQpTZWN0aW9uIDEsIHNlY29uZCBidWxsZXQgMzogIFRo aXMgaXMgY3VycmVudGx5IGEgcnVuLW9uIHNlbnRlbmNlLCBhbmQgbmVlZHMgdG8gYmUgc3BsaXQg aW50byB0d28gc2VudGVuY2VzOiAiVGhlIHJlcXVlc3RfdXJpIG1heSBpbmNsdWRlIGEgU0hBLTI1 NiBoYXNoIG9mIHRoZSBmaWxlLCBhcyBkZWZpbmVkIGluIEZJUFMxODAtMiBbRklQUzE4MC0yXSwg dGhlIHNlcnZlciBrbm93cyBpZiB0aGUgZmlsZSBoYXMgY2hhbmdlZCB3aXRob3V0IGZldGNoaW5n IGl0LCBzbyBpdCBkb2VzIG5vdCBoYXZlIHRvIHJlLWZldGNoIGEgc2FtZSBmaWxlLCB3aGljaCBp cyBhIHdpbiBhcyB3ZWxsLiINCg0KU2VjdGlvbiAxLCBzZWNvbmQgYnVsbGV0IDQ6ICBUaGlzIHNl bnRlbmNlIGlzIG1pc3NpbmcgYSB2ZXJiOiAiIFdoZW4gdGhlIGNsaWVudCB3YW50cyB0byBzaW1w bGlmeSB0aGUgaW1wbGVtZW50YXRpb24gd2l0aG91dCBjb21wcm9taXNpbmcgdGhlIHNlY3VyaXR5 LiINCg0KU2VjdGlvbiAxLCBzZWNvbmQgYnVsbGV0IDQ6ICBDaGFuZ2UgInRoZXkgbWF5IGJlIHRh bXBlcmVkIGluIHRoZSBicm93c2VyIiB0byAidGhleSBtYXkgYmUgdGFtcGVyZWQgd2l0aCBpbiB0 aGUgYnJvd3NlciIuDQoNClNlY3Rpb24gMSwgc2Vjb25kIGJ1bGxldCA0OiAgQ2hhbmdlICJUaGlz IGltcGxpZXMgd2UgbmVlZCB0byBoYXZlIHNpZ25hdHVyZSBvbiB0aGUgcmVxdWVzdCBhcyB3ZWxs IiB0byAiVGhpcyBpbXBsaWVzIHdlIG5lZWQgdG8gaGF2ZSBhIHNpZ25hdHVyZSBvbiB0aGUgcmVx dWVzdCBhcyB3ZWxsIi4NCg0KU2VjdGlvbiAxLCBzZWNvbmQgYnVsbGV0IDQ6ICBDaGFuZ2UgInRh bXBlcmVkIiB0byAidGFtcGVyZWQgd2l0aCIuDQoNClNlY3Rpb24gMywgcGFyYWdyYXBoIDE6ICBD aGFuZ2UgIkpXVCBbUkZDNzUxOV0gQ2xhaW1zIFNldCIgdG8gIkpXVCBDbGFpbXMgU2V0IFtSRkM3 NTE5XSIuDQoNClNlY3Rpb24gMywgcGFyYWdyYXBoIDQ6ICBDaGFuZ2UgIlJFUVVJUkVEIE9BdXRo IDIuMCBBdXRob3JpemF0aW9uIFJlcXVlc3QgcGFyYW1ldGVycyB0aGF0IGFyZSBub3QgaW5jbHVk ZWQgaW4gdGhlIFJlcXVlc3QgT2JqZWN0IE1VU1QgYmUgc2VudCBhcyBhIHF1ZXJ5IHBhcmFtZXRl ciIgdG8gIlJFUVVJUkVEIE9BdXRoIDIuMCBBdXRob3JpemF0aW9uIFJlcXVlc3QgcGFyYW1ldGVy cyB0aGF0IGFyZSBub3QgaW5jbHVkZWQgaW4gdGhlIFJlcXVlc3QgT2JqZWN0IE1VU1QgYmUgc2Vu dCBhcyBxdWVyeSBwYXJhbWV0ZXJzIi4NCg0KU2VjdGlvbiAzLCBwYXJhZ3JhcGggNDogIENoYW5n ZSAiSWYgYSByZXF1aXJlZCBwYXJhbWV0ZXIgaXMgbm90IHByZXNlbnQgaW4gbmVpdGhlciB0aGUg cXVlcnkgcGFyYW1ldGVyIG5vciB0aGUgUmVxdWVzdCBPYmplY3QsIGl0IGZvcm1zIGEgbWFsZm9y bWVkIHJlcXVlc3QiIHRvICJJZiBhIHJlcXVpcmVkIHBhcmFtZXRlciBpcyBub3QgcHJlc2VudCBp biBlaXRoZXIgYXMgYSBxdWVyeSBwYXJhbWV0ZXIgb3IgaW4gdGhlIFJlcXVlc3QgT2JqZWN0LCB0 aGUgcmVxdWVzdCBpcyBtYWxmb3JtZWQiLg0KDQpTZWN0aW9uIDMsIHBhcmFncmFwaCA2OiBDaGFu Z2UgInRoZSB2YWx1ZXMgaW4gdGhlIFJlcXVlc3QgT2JqZWN0IHRha2VzIHByZWNlZGVuY2UiIHRv ICJ0aGUgdmFsdWVzIGluIHRoZSBSZXF1ZXN0IE9iamVjdCB0YWtlIHByZWNlZGVuY2UiLg0KDQpT ZWN0aW9uIDMsIHBhcmFncmFwaCA2OiBDaGFuZ2UgIml0IGNhbm5vdCBpbmNsdWRlIHN1Y2ggcGFy YW1ldGVycyBsaWtlICJzdGF0ZSIgdGhhdCBpcyBleHBlY3RlZCB0byBkaWZmZXIgaW4gZXZlcnkg cmVxdWVzdCIgdG8gIml0IGNhbm5vdCBpbmNsdWRlIHBhcmFtZXRlcnMgc3VjaCBhcyAic3RhdGUi IHRoYXQgYXJlIGV4cGVjdGVkIHRvIGRpZmZlciBpbiBldmVyeSByZXF1ZXN0Ii4NCg0KU2VjdGlv biA0LCBwYXJhZ3JhcGggNjogIERlbGV0ZSAiKGxpbmUgYnJlYWtzIGFyZSBmb3IgZGlzcGxheSBw dXJwb3NlcyBvbmx5KSIgc2luY2UgdGhlcmUgYXJlIG5vIGV4dHJhIGxpbmUgYnJlYWtzIGluIHRo ZSBleGFtcGxlLg0KDQoJCQlUaGFua3MgZm9yIGRvaW5nIHRoaXMsIGd1eXMuLi4NCgkJCQktLSBN aWtlDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBPQXV0aCBbbWFpbHRvOm9h dXRoLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBIYW5uZXMgVHNjaG9mZW5pZw0KU2Vu dDogVHVlc2RheSwgT2N0b2JlciAyMCwgMjAxNSA2OjAzIFBNDQpUbzogb2F1dGhAaWV0Zi5vcmcN ClN1YmplY3Q6IFtPQVVUSC1XR10gV0dMQyBmb3IgZHJhZnQtaWV0Zi1vYXV0aC1qd3NyZXEtMDYN Cg0KSGkgYWxsLA0KDQp3ZSB3b3VsZCBsaWtlIHRvIHN0YXJ0IGEgV0dMQyBvbiBkcmFmdC1pZXRm LW9hdXRoLWp3c3JlcS0wNjoNCmh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRs b29rLmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJmdG9vbHMuaWV0Zi5vcmclMmZodG1sJTJmZHJhZnQt aWV0Zi1vYXV0aC1qd3NyZXEtMDYmZGF0YT0wMSU3YzAxJTdjTWljaGFlbC5Kb25lcyU0MG1pY3Jv c29mdC5jb20lN2MzMTY5ZTBiNDE3NTM0OTFkMzY1NTA4ZDJkOTJkNTRhOSU3YzcyZjk4OGJmODZm MTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZzZGF0YT1yVzNTUXlaRDNMOU9LVDVZcUUwJTJmcmVu JTJmMUhiNEtMQkcxdEVreXZNeldxMCUzZA0KDQpUaGlzIHdpbGwgYmUgYSAyLXdlZWsgbGFzdCBj YWxsLCBzbyBpdCB3aWxsIGVuZCBvbiBOb3ZlbWJlciAzcmQuDQoNClRoZSBXR0xDIHRpbWluZyBp cyBnb29kIHNpbmNlIG91ciBPQXV0aCBtZWV0aW5nIGluIFlva29oYW1hIGlzIG9uIHRoZSBUaHVy c2RheSwgTm92ZW1iZXIgNXRoIGFuZCB5b3UgbWlnaHQgd2FudCB0byBwcmVwYXJlIGZvciB0aGUg V0cgc2Vzc2lvbiBhbnl3YXkuDQoNClBsZWFzZSBzZW5kIGNvbW1lbnRzIHRvIHRoZSBsaXN0Lg0K DQpDaWFvDQpIYW5uZXMNCg0K From nobody Thu Nov 5 12:07:29 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B25AC1B3617 for ; Thu, 5 Nov 2015 12:07:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.693 X-Spam-Level: X-Spam-Status: No, score=0.693 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URI_NO_WWW_INFO_CGI=2.071] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b4gWDXlEwz-w for ; Thu, 5 Nov 2015 12:07:20 -0800 (PST) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 674011B360D for ; Thu, 5 Nov 2015 12:07:20 -0800 (PST) Received: by igbhv6 with SMTP id hv6so19362400igb.0 for ; Thu, 05 Nov 2015 12:07:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salesforce.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jW+ceuq5IkbQ8nUj/C4tUsxF1ZCEVxjRY3z/iLinu2g=; b=EbyQsXsVyoQxTQhGDCHSOnyyuDBEnZAa74yOJwk1rGituaNRTUiSUC/eEUnk4+Ne0P FKTM56A2VONKtOeb37c0MaA7UB3NvlOW1TAvt+k6IxQGbxzq53aa5RWu2hMp635w+4gC QqgE3aeqAQ35+n4sqcPJM4QHKF0+m+y4S8t2E= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=jW+ceuq5IkbQ8nUj/C4tUsxF1ZCEVxjRY3z/iLinu2g=; b=ipwfXTwi2v8n78+yw8PDvBPOG29l7oev8yq1obm6zC8bPGuT0KUcBnzAHwDLs5q47Z zG194x5r+vpx7NJ/BApgp/fGfO5fQFaMRAHal28SqCB47C/9eHmsAQkC547v6aIztqPg 67Tk9ho/a66gKGzJhYvJids+fSSPYxGMx61SvXcjBF6cHVUQI5iAIpYhHmoBPnQ3MU9d 7jKtyYbwFa3/BfSCuIHhpgTvhgfrWDYw8SMbap0vC/WY6OUzYKP43cyo3Yz7PFSpsneE SkK5ZnPCzTgtXArw6wvZjWDLDeoFjX6g30qfo9xaOjQ13gouCVQgaRrbRvLVGeD8BIGo Vutw== X-Gm-Message-State: ALoCoQmr0OXo3MF6HDoHrMUc5+t1i/XV92GINaf0jVpvEdtEKBwH03xaZ2CSwphmT2TciECeT6kD MIME-Version: 1.0 X-Received: by 10.50.79.135 with SMTP id j7mr5164543igx.73.1446754039564; Thu, 05 Nov 2015 12:07:19 -0800 (PST) Received: by 10.64.146.195 with HTTP; Thu, 5 Nov 2015 12:07:17 -0800 (PST) In-Reply-To: <4D05C317-FF58-4CDE-98BE-D4ED1E078526@ve7jtb.com> References: <563AA216.5010109@gmx.net> <89A6E4DE-263B-4DB4-8882-54FA7103C721@mit.edu> <82079E8A-2AC8-4A42-9AF7-77FF2A3CAFC2@ve7jtb.com> <9E23AF3A-F758-4CB4-B920-4E1E2F61BCF4@ve7jtb.com> <4D05C317-FF58-4CDE-98BE-D4ED1E078526@ve7jtb.com> Date: Thu, 5 Nov 2015 12:07:17 -0800 Message-ID: From: Chuck Mortimore To: John Bradley Content-Type: multipart/alternative; boundary=089e0122a7549b63b80523d0ac74 Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 20:07:26 -0000 --089e0122a7549b63b80523d0ac74 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The spec is very clear for most cases, but I think it could use some guidance on nested JWTs. (Or perhaps I've got the approach wrong.) Here's the use-case: We have devices that are self-issuing keys. Via token exchange, we're going to except a self-signed JWT from the device that includes a "cnf" claim of the key they generated. Assuming the signature checks out on that JWT, we'll then bind that key into a "cnf" claim in a new token that we issue and sign with a tenant key. When the device goes to use that token, the device would sign it, constructing a nested JWT. The outer signature is the proof of possession of the device's private key. The inner signature is our signature that binds the public key used to validate the outer token. Does this sound correct? The processing order is a bit odd since you first need to unpack and validate the inner token before you can validate the outer token. Is there some other way this is intended to work? thanks -cmort On Wed, Nov 4, 2015 at 8:58 PM, John Bradley wrote: > Good to know. So the AS needs to expose a public key for the TPM to use > for encryption. I am guessing you are not using a encrypted JWK for > that. What is the format the TPM produces the wrapped key in? > > John B. > > On Nov 5, 2015, at 1:55 PM, Anthony Nadalin > wrote: > > > > I can say on all windows based devices (pc, xbox, phone, etc) with only > TPM 1.1 this will be the approach so it will be commonly used > > > > -----Original Message----- > > From: John Bradley [mailto:ve7jtb@ve7jtb.com] > > Sent: Wednesday, November 4, 2015 8:52 PM > > To: Anthony Nadalin > > Cc: Justin Richer ; > > Subject: Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec > addressing final shepherd comment > > > > OK, no good reason unless the client is using a HSM that can do HMAC an= d > can export a symmetric key wrapped in a asymmetric key provided by the AS= . > > > > We don=E2=80=99t currently cover that use case of sending a wrapped sym= metric > key to the AS in POP key distribution. > > I don=E2=80=99t know how common that is going to be, but it is worth th= inking > about defining. > > > > John B. > > > >> On Nov 5, 2015, at 1:45 PM, Anthony Nadalin > wrote: > >> > >> Not sure why you think its weaker as it would be a wrapped key that > >> the hardware produces > >> > >> -----Original Message----- > >> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of John Bradley > >> Sent: Wednesday, November 4, 2015 8:43 PM > >> To: Justin Richer > >> Cc: > >> Subject: Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs > >> spec addressing final shepherd comment > >> > >> In the asymmetric case the use of a HSM or secure element is the > argument for the client selecting the public key. In those cases the > client is doing the key gen in hardware so one hopes it is OK. In the > symetric case the client generating the key is weaker (as in I can=E2=80= =99t think > of any really good reason). > >> > >> > >>> On Nov 5, 2015, at 1:35 PM, Justin Richer wrote: > >>> > >>> I=E2=80=99d argue that it=E2=80=99s best practice, and in line with o= ther parts of > OAuth, if we assume the server generates it in the normal case (issuer -> > presenter). Client generated token keys should be an exception, especiall= y > in the asymmetric case. > >>> > >>> =E2=80=94 Justin > >>> > >>>> On Nov 5, 2015, at 1:32 PM, John Bradley wrote: > >>>> > >>>> Agreed the only real difference is the quality of the key. If the > server generates it, then it knows that the client is not using the fixed > hex value of DEADBEEF for everything. > >>>> > >>>> John B. > >>>>> On Nov 5, 2015, at 9:25 AM, Hannes Tschofenig < > hannes.tschofenig@gmx.net> wrote: > >>>>> > >>>>> I agree that the effect is the same. From a security point of view > >>>>> there is only an impact if one of the two parties is in a better > >>>>> position to generate random numbers, which is the basis for > >>>>> generating a high entropy symmetric key. > >>>>> > >>>>> On 11/04/2015 11:51 PM, Mike Jones wrote: > >>>>>> Thanks for the detailed read, Brian. You=E2=80=99re right that in= the > >>>>>> symmetric case, either the issuer or the presenter can create the > >>>>>> symmetric PoP key and share it with the other party, since the > effect is equivalent. > >>>>>> I suspect that both the key distribution draft and this draft > >>>>>> should be updated with a sentence or two saying that either > >>>>>> approach can be taken. Do others concur? > >>>>>> > >>>>>> > >>>>>> > >>>>>> -- Mike > >>>>>> > >>>>>> > >>>>>> > >>>>>> *From:*Brian Campbell [mailto:bcampbell@pingidentity.com] > >>>>>> *Sent:* Thursday, November 05, 2015 7:48 AM > >>>>>> *To:* Mike Jones > >>>>>> *Cc:* Kepeng Li; oauth@ietf.org > >>>>>> *Subject:* Re: [OAUTH-WG] Proof-of-Possession Key Semantics for > >>>>>> JWTs spec addressing final shepherd comment > >>>>>> > >>>>>> > >>>>>> > >>>>>> +1 for the diagrams making the document more understandable. > >>>>>> > >>>>>> One little nit/question, step 1 in both Symmetric and Asymmetric > >>>>>> keys shows the Presenter sending the key to the Issuer. It's > >>>>>> possible, however, for the key to be sent the other way. Presenter > >>>>>> sending it to the Issuer is probably preferred for asymmetric, > >>>>>> especially if the client can secure the private keys in hardware. > >>>>>> But I don't know if one way or the other is clearly better for > >>>>>> symmetric case and PoP key distribution currently has it the other > >>>>>> way < > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2ftools.= ietf.org%2fhtml%2fdraft-ietf-oauth-pop-key-distribution-02%23section-4.2&da= ta=3D01%7c01%7ctonynad%40microsoft.com%7c9456670075d04a51f85508d2e59ba294%7= c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=3DUgZEoqQiaUk9VdYpSQRvUeVVOQgIU= g3UmAr18oQ7GtI%3d > >. > >>>>>> Should the intro text somehow mention the possibility that the > >>>>>> Issuer could create the key and send it to the Presenter? > >>>>>> > >>>>>> I know it's only the introduction but it was just something that > >>>>>> jumped out at me. > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> On Wed, Nov 4, 2015 at 9:04 AM, Mike Jones > >>>>>> > > wrote: > >>>>>> > >>>>>> Thanks for suggesting the diagrams, Kepeng. They make the document > >>>>>> more understandable. > >>>>>> > >>>>>> -- Mike > >>>>>> > >>>>>> ------------------------------------------------------------------ > >>>>>> - > >>>>>> ----- > >>>>>> > >>>>>> *From: *Kepeng Li > >>>>>> *Sent: *=E2=80=8E11/=E2=80=8E5/=E2=80=8E2015 12:57 AM > >>>>>> *To: *Mike Jones ; > >>>>>> oauth@ietf.org > >>>>>> *Subject: *Re: Proof-of-Possession Key Semantics for JWTs spec > >>>>>> addressing final shepherd comment > >>>>>> > >>>>>> Thank you Mike. > >>>>>> > >>>>>> > >>>>>> > >>>>>> The diagrams look good to me. > >>>>>> > >>>>>> > >>>>>> > >>>>>> Kind Regards > >>>>>> > >>>>>> Kepeng > >>>>>> > >>>>>> > >>>>>> > >>>>>> *=E5=8F=91=E4=BB=B6=E4=BA=BA**: *Mike Jones >>>>>> > > >>>>>> *=E6=97=A5=E6=9C=9F**: *Thursday, 5 November, 2015 12:32 am > >>>>>> *=E8=87=B3**: *"oauth@ietf.org " >>>>>> > > >>>>>> *=E6=8A=84=E9=80=81**: *Li Kepeng >>>>>> > > >>>>>> *=E4=B8=BB=E9=A2=98**: *Proof-of-Possession Key Semantics for JWTs= spec addressing > >>>>>> final shepherd comment > >>>>>> > >>>>>> > >>>>>> > >>>>>> Proof-of-Possession Key Semantics for JWTs draft -06 addresses the > >>>>>> remaining document shepherd comment =E2=80=93 adding use case diag= rams to > >>>>>> the introduction. > >>>>>> > >>>>>> > >>>>>> > >>>>>> The updated specification is available at: > >>>>>> > >>>>>> =C2=B7 > https://na01.safelinks.protection.outlook.com/?url=3Dhttp%3a%2f%2ftools.i= etf.org%2fhtml%2fdraft-ietf-oauth-proof-of-possession-06&data=3D01%7c01%7ct= onynad%40microsoft.com%7c9456670075d04a51f85508d2e59ba294%7c72f988bf86f141a= f91ab2d7cd011db47%7c1&sdata=3D6hE6dOO0I1%2ffF005rVknyOFHuB18gdpZg9dftExLtCw= %3d > >>>>>> > >>>>>> > >>>>>> > >>>>>> An HTML formatted version is also available at: > >>>>>> > >>>>>> =C2=B7 > >>>>>> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2= fs > >>>>>> e > >>>>>> lf-issued.info%2fdocs%2fdraft-ietf-oauth-proof-of-possession-06.ht > >>>>>> m > >>>>>> l&data=3D01%7c01%7ctonynad%40microsoft.com%7c9456670075d04a51f8550= 8d > >>>>>> 2 > >>>>>> e59ba294%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=3DEQd4rUcuyq= dS > >>>>>> P gmibtcfjMpJm6RWWwCZC85%2bCboEs54%3d > >>>>>> > >>>>>> > >>>>>> > >>>>>> -- Mike > >>>>>> > >>>>>> > >>>>>> > >>>>>> P.S. This note was also posted at > >>>>>> > https://na01.safelinks.protection.outlook.com/?url=3Dhttp%3a%2f%2fself-is= sued.info%2f%3fp%3d1471&data=3D01%7c01%7ctonynad%40microsoft.com%7c94566700= 75d04a51f85508d2e59ba294%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=3DTMf= X1tG5qucl%2be2KVpyMBuj72ZQ%2f%2bEKGoTyJyf%2bfJi4%3d > and as @selfissued < > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2ftwitte= r.com%2fselfissued&data=3D01%7c01%7ctonynad%40microsoft.com%7c9456670075d04= a51f85508d2e59ba294%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=3DLfFAjchz= CTh0x%2fY9hr0W%2fSohPGgb0JVjL%2f2Az%2f12BCg%3d > >. > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> OAuth mailing list > >>>>>> OAuth@ietf.org > >>>>>> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2= fw > >>>>>> w > >>>>>> w.ietf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonynad%4= 0m > >>>>>> i > >>>>>> crosoft.com%7c9456670075d04a51f85508d2e59ba294%7c72f988bf86f141af9 > >>>>>> 1 > >>>>>> ab2d7cd011db47%7c1&sdata=3DND3ydaXOsPMsoRhE0Uyq0uznGy6MdYOLZQJHLhE= QK > >>>>>> J > >>>>>> s%3d > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> OAuth mailing list > >>>>>> OAuth@ietf.org > >>>>>> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2= fw > >>>>>> w > >>>>>> w.ietf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonynad%4= 0m > >>>>>> i > >>>>>> crosoft.com%7c9456670075d04a51f85508d2e59ba294%7c72f988bf86f141af9 > >>>>>> 1 > >>>>>> ab2d7cd011db47%7c1&sdata=3DND3ydaXOsPMsoRhE0Uyq0uznGy6MdYOLZQJHLhE= QK > >>>>>> J > >>>>>> s%3d > >>>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> OAuth mailing list > >>>>> OAuth@ietf.org > >>>>> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2f= ww > >>>>> w > >>>>> .ietf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonynad%40m= ic > >>>>> r > >>>>> osoft.com%7c9456670075d04a51f85508d2e59ba294%7c72f988bf86f141af91ab > >>>>> 2 > >>>>> d7cd011db47%7c1&sdata=3DND3ydaXOsPMsoRhE0Uyq0uznGy6MdYOLZQJHLhEQKJs= %3 > >>>>> d > >>>> > >>>> _______________________________________________ > >>>> OAuth mailing list > >>>> OAuth@ietf.org > >>>> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fw= ww. > >>>> ietf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonynad%40mic= ro > >>>> s > >>>> oft.com%7c9456670075d04a51f85508d2e59ba294%7c72f988bf86f141af91ab2d7 > >>>> c d011db47%7c1&sdata=3DND3ydaXOsPMsoRhE0Uyq0uznGy6MdYOLZQJHLhEQKJs%3= d > >>> > >> > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww= .i > >> etf.org%2fmailman%2flistinfo%2foauth%0a&data=3D01%7c01%7ctonynad%40mic= ro > >> soft.com%7c9456670075d04a51f85508d2e59ba294%7c72f988bf86f141af91ab2d7c > >> d011db47%7c1&sdata=3DBLqSuDjWLY72fGm0UrpLwxQVnamMelggJeOpYJESVFs%3d > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --089e0122a7549b63b80523d0ac74 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The spec is very clear for most cases, but I think it= could use some guidance on nested JWTs. =C2=A0 =C2=A0(Or perhaps I've = got the approach wrong.)=C2=A0

Here's the use-= case:
We have devices that are self-is= suing keys. =C2=A0 =C2=A0Via token exchange, we're going to except a se= lf-signed JWT from the device that includes a "cnf" claim of the key they generated. =C2=A0 =C2=A0Assuming the signa= ture checks out on that JWT, we'll then bind that key into a "cnf" claim in a new token that we issue and sign w= ith a tenant key. =C2=A0

When the device goes to use that token, the de= vice would sign it, constructing a nested JWT.=C2=A0 The outer signature is= the proof of possession of the device's private key. =C2=A0 The inner = signature is our signature that binds the public key used to validate the o= uter token.

Does this sound correct? =C2=A0 The processing order is a b= it odd since you first need to unpack and validate the inner token before y= ou can validate the outer token. =C2=A0 Is there some other way this is int= ended to work?

thanks
=C2=A0=C2=A0= =C2=A0
-cmort



= On Wed, Nov 4, 2015 at 8:58 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
Good to know.=C2=A0 =C2=A0So= the AS needs to expose a public key for the TPM to use for encryption.=C2= =A0 =C2=A0I am guessing you are not using a encrypted JWK for that.=C2=A0 W= hat is the format the TPM produces the wrapped key in?

John B.
> On Nov 5, 2015, at 1:55 PM, An= thony Nadalin <tonynad@microsof= t.com> wrote:
>
> I can say on all windows based devices (pc, xbox, phone, etc) with onl= y TPM 1.1 this will be the approach so it will be commonly used
>
> -----Original Message-----
> From: John Bradley [mailto:ve7jtb= @ve7jtb.com]
> Sent: Wednesday, November 4, 2015 8:52 PM
> To: Anthony Nadalin <tonyn= ad@microsoft.com>
> Cc: Justin Richer <jricher@mit.e= du>; <oauth@ietf.org> &l= t;oauth@ietf.org>
> Subject: Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spe= c addressing final shepherd comment
>
> OK, no good reason unless the client is using a HSM that can do HMAC a= nd can export a symmetric key wrapped in a asymmetric key provided by the A= S.
>
> We don=E2=80=99t currently cover that use case of sending a wrapped sy= mmetric key to the AS in POP key distribution.
> I don=E2=80=99t know how common that is going to be, but it is worth t= hinking about defining.
>
> John B.
>
>> On Nov 5, 2015, at 1:45 PM, Anthony Nadalin <tonynad@microsoft.com> wrote:
>>
>> Not sure why you think its weaker as it would be a wrapped key tha= t
>> the hardware produces
>>
>> -----Original Message-----
>> From: OAuth [mailto:oaut= h-bounces@ietf.org] On Behalf Of John Bradley
>> Sent: Wednesday, November 4, 2015 8:43 PM
>> To: Justin Richer <jricher@m= it.edu>
>> Cc: <oauth@ietf.org> &= lt;oauth@ietf.org>
>> Subject: Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs=
>> spec addressing final shepherd comment
>>
>> In the asymmetric case the use of a HSM or secure element is the a= rgument for the client selecting the public key.=C2=A0 =C2=A0In those cases= the client is doing the key gen in hardware so one hopes it is OK.=C2=A0 = =C2=A0In the symetric case the client generating the key is weaker (as in I= can=E2=80=99t think of any really good reason).
>>
>>
>>> On Nov 5, 2015, at 1:35 PM, Justin Richer <jricher@mit.edu> wrote:
>>>
>>> I=E2=80=99d argue that it=E2=80=99s best practice, and in line= with other parts of OAuth, if we assume the server generates it in the nor= mal case (issuer -> presenter). Client generated token keys should be an= exception, especially in the asymmetric case.
>>>
>>> =E2=80=94 Justin
>>>
>>>> On Nov 5, 2015, at 1:32 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
>>>>
>>>> Agreed the only real difference is the quality of the key.= =C2=A0 If the server generates it, then it knows that the client is not usi= ng the fixed hex value of DEADBEEF for everything.
>>>>
>>>> John B.
>>>>> On Nov 5, 2015, at 9:25 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net> = wrote:
>>>>>
>>>>> I agree that the effect is the same. From a security p= oint of view
>>>>> there is only an impact if one of the two parties is i= n a better
>>>>> position to generate random numbers, which is the basi= s for
>>>>> generating a high entropy symmetric key.
>>>>>
>>>>> On 11/04/2015 11:51 PM, Mike Jones wrote:
>>>>>> Thanks for the detailed read, Brian.=C2=A0 You=E2= =80=99re right that in the
>>>>>> symmetric case, either the issuer or the presenter= can create the
>>>>>> symmetric PoP key and share it with the other part= y, since the effect is equivalent.
>>>>>> I suspect that both the key distribution draft and= this draft
>>>>>> should be updated with a sentence or two saying th= at either
>>>>>> approach can be taken.=C2=A0 Do others concur?
>>>>>>
>>>>>>
>>>>>>
>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -= - Mike
>>>>>>
>>>>>>
>>>>>>
>>>>>> *From:*Brian Campbell [mailto:bcampbell@pingidentity.com]
>>>>>> *Sent:* Thursday, November 05, 2015 7:48 AM
>>>>>> *To:* Mike Jones
>>>>>> *Cc:* Kepeng Li; oauth@ietf.org
>>>>>> *Subject:* Re: [OAUTH-WG] Proof-of-Possession Key = Semantics for
>>>>>> JWTs spec addressing final shepherd comment
>>>>>>
>>>>>>
>>>>>>
>>>>>> +1 for the diagrams making the document more under= standable.
>>>>>>
>>>>>> One little nit/question, step 1 in both Symmetric = and Asymmetric
>>>>>> keys shows the Presenter sending the key to the Is= suer. It's
>>>>>> possible, however, for the key to be sent the othe= r way. Presenter
>>>>>> sending it to the Issuer is probably preferred for= asymmetric,
>>>>>> especially if the client can secure the private ke= ys in hardware.
>>>>>> But I don't know if one way or the other is cl= early better for
>>>>>> symmetric case and PoP key distribution currently = has it the other
>>>>>> way <https://na01.safelinks.protection.outlook.co= m/?url=3Dhttps%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-ietf-oauth-pop-key-dis= tribution-02%23section-4.2&data=3D01%7c01%7ctonynad%40microsoft.com%7c9= 456670075d04a51f85508d2e59ba294%7c72f988bf86f141af91ab2d7cd011db47%7c1&= sdata=3DUgZEoqQiaUk9VdYpSQRvUeVVOQgIUg3UmAr18oQ7GtI%3d>.
>>>>>> Should the intro text somehow mention the possibil= ity that the
>>>>>> Issuer could create the key and send it to the Pre= senter?
>>>>>>
>>>>>> I know it's only the introduction but it was j= ust something that
>>>>>> jumped out at me.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Nov 4, 2015 at 9:04 AM, Mike Jones
>>>>>> <Michael.Jones@microsoft.com <mailto:Michael.Jones@microsoft.com>> wrote:
>>>>>>
>>>>>> Thanks for suggesting the diagrams, Kepeng. They m= ake the document
>>>>>> more understandable.
>>>>>>
>>>>>> -- Mike
>>>>>>
>>>>>> --------------------------------------------------= ----------------
>>>>>> -
>>>>>> -----
>>>>>>
>>>>>> *From: *Kepeng Li <mailto:kepeng.lkp@alibaba-inc.com>
>>>>>> *Sent: *=E2=80=8E11/=E2=80=8E5/=E2=80=8E2015 12:57= AM
>>>>>> *To: *Mike Jones <mailto:Michael.Jones@microsoft.com>;
>>>>>> oauth@ietf.org <mailto:oauth@ietf.org>
>>>>>> *Subject: *Re: Proof-of-Possession Key Semantics f= or JWTs spec
>>>>>> addressing final shepherd comment
>>>>>>
>>>>>> Thank you Mike.
>>>>>>
>>>>>>
>>>>>>
>>>>>> The diagrams look good to me.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Kind Regards
>>>>>>
>>>>>> Kepeng
>>>>>>
>>>>>>
>>>>>>
>>>>>> *=E5=8F=91=E4=BB=B6=E4=BA=BA**: *Mike Jones <Michael.Jones@microsoft.com
>>>>>> <mailto:Michael.Jones@microsoft.com>>
>>>>>> *=E6=97=A5=E6=9C=9F**: *Thursday, 5 November, 2015= 12:32 am
>>>>>> *=E8=87=B3**: *"oauth@ietf.org <mailto:oauth@= ietf.org>" <oauth@ietf.org=
>>>>>> <mailto:oauth= @ietf.org>>
>>>>>> *=E6=8A=84=E9=80=81**: *Li Kepeng <kepeng.lkp@alibaba-inc.com
>>>>>> <mailto:kepeng.lkp@alibaba-inc.com>>
>>>>>> *=E4=B8=BB=E9=A2=98**: *Proof-of-Possession Key Se= mantics for JWTs spec addressing
>>>>>> final shepherd comment
>>>>>>
>>>>>>
>>>>>>
>>>>>> Proof-of-Possession Key Semantics for JWTs draft -= 06 addresses the
>>>>>> remaining document shepherd comment =E2=80=93 addi= ng use case diagrams to
>>>>>> the introduction.
>>>>>>
>>>>>>
>>>>>>
>>>>>> The updated specification is available at:
>>>>>>
>>>>>> =C2=B7=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://na01.safelinks.protectio= n.outlook.com/?url=3Dhttp%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-ietf-oauth-= proof-of-possession-06&data=3D01%7c01%7ctonynad%40microsoft.com%7c94566= 70075d04a51f85508d2e59ba294%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdat= a=3D6hE6dOO0I1%2ffF005rVknyOFHuB18gdpZg9dftExLtCw%3d
>>>>>>
>>>>>>
>>>>>>
>>>>>> An HTML formatted version is also available at: >>>>>>
>>>>>> =C2=B7
>>>>>> https:/= /na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fs
>>>>>> e
>>>>>> lf-issued.info%2fdocs%2f= draft-ietf-oauth-proof-of-possession-06.ht
>>>>>> m
>>>>>> l&data=3D01%7c01%7ctonynad%40microsoft.com%7c= 9456670075d04a51f85508d
>>>>>> 2
>>>>>> e59ba294%7c72f988bf86f141af91ab2d7cd011db47%7c1&am= p;sdata=3DEQd4rUcuyqdS
>>>>>> P gmibtcfjMpJm6RWWwCZC85%2bCboEs54%3d
>>>>>>
>>>>>>
>>>>>>
>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =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
>>>>>>
>>>>>>
>>>>>>
>>>>>> P.S.=C2=A0 This note was also posted at
>>>>>> https://na01.safel= inks.protection.outlook.com/?url=3Dhttp%3a%2f%2fself-issued.info%2f%3fp%3d1= 471&data=3D01%7c01%7ctonynad%40microsoft.com%7c9456670075d04a51f85508d2= e59ba294%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=3DTMfX1tG5qucl%2b= e2KVpyMBuj72ZQ%2f%2bEKGoTyJyf%2bfJi4%3d and as @selfissued <https://na01.safelinks.protection.outlook.com/?url=3Dh= ttps%3a%2f%2ftwitter.com%2fselfissued&data=3D01%7c01%7ctonynad%40micros= oft.com%7c9456670075d04a51f85508d2e59ba294%7c72f988bf86f141af91ab2d7cd011db= 47%7c1&sdata=3DLfFAjchzCTh0x%2fY9hr0W%2fSohPGgb0JVjL%2f2Az%2f12BCg%3d>.
>>>>>>
>>>>>>
>>>>>> _______________________________________________ >>>>>> OAuth mailing list
>>>>>> OAuth@ietf.org <mailto:OAuth@ietf.org>
>>>>>> https:/= /na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fw
>>>>>> w
>>>>>> w.ietf.org%2fmailman%2flistinfo%2foauth&data=3D01%= 7c01%7ctonynad%40m
>>>>>> i
>>>>>> crosoft.com%7c9456670075d04a51f85508d2e59ba294%7c72f9= 88bf86f141af9
>>>>>> 1
>>>>>> ab2d7cd011db47%7c1&sdata=3DND3ydaXOsPMsoRhE0Uy= q0uznGy6MdYOLZQJHLhEQK
>>>>>> J
>>>>>> s%3d
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________ >>>>>> OAuth mailing list
>>>>>> OAuth@ietf.org
>>>>>> https:/= /na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fw
>>>>>> w
>>>>>> w.ietf.org%2fmailman%2flistinfo%2foauth&data=3D01%= 7c01%7ctonynad%40m
>>>>>> i
>>>>>> crosoft.com%7c9456670075d04a51f85508d2e59ba294%7c72f9= 88bf86f141af9
>>>>>> 1
>>>>>> ab2d7cd011db47%7c1&sdata=3DND3ydaXOsPMsoRhE0Uy= q0uznGy6MdYOLZQJHLhEQK
>>>>>> J
>>>>>> s%3d
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org >>>>> https://na= 01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fww
>>>>> w
>>>>> .ietf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7c= tonynad%40mic
>>>>> r
>>>>> osoft.com%7c9456670075d04a51f85508d2e59ba294%7c72f988bf86f1= 41af91ab
>>>>> 2
>>>>> d7cd011db47%7c1&sdata=3DND3ydaXOsPMsoRhE0Uyq0uznGy= 6MdYOLZQJHLhEQKJs%3
>>>>> d
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://na01.= safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.
>>>> ietf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonyn= ad%40micro
>>>> s
>>>> oft.com%7c9456670075d04a51f85508d2e59ba294%7c72f988bf86f141af91ab= 2d7
>>>> c d011db47%7c1&sdata=3DND3ydaXOsPMsoRhE0Uyq0uznGy6MdYO= LZQJHLhEQKJs%3d
>>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://na01.safeli= nks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.i
>> et= f.org%2fmailman%2flistinfo%2foauth%0a&data=3D01%7c01%7ctonynad%40mi= cro
>> s= oft.com%7c9456670075d04a51f85508d2e59ba294%7c72f988bf86f141af91ab2d7c >> d011db47%7c1&sdata=3DBLqSuDjWLY72fGm0UrpLwxQVnamMelggJeOpYJESV= Fs%3d
>

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

--089e0122a7549b63b80523d0ac74-- From nobody Thu Nov 5 17:01:26 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A99B01A8861 for ; Thu, 5 Nov 2015 17:01:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id no1KcDcFv9ES for ; Thu, 5 Nov 2015 17:01:24 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC5D41A896D for ; Thu, 5 Nov 2015 17:01:23 -0800 (PST) Received: from [192.168.10.243] ([133.93.52.154]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MPZuP-1ZpoRd2T2n-004g4p for ; Fri, 06 Nov 2015 02:01:21 +0100 To: "oauth@ietf.org" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <563BFBDB.4050101@gmx.net> Date: Fri, 6 Nov 2015 02:01:15 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="IjrJGFK7134xo9xsnvm7ag0IHG2kab1J4" X-Provags-ID: V03:K0:xFJu5ev65nmfV3lbzIn2YloT7i/mHwJ1+y5M7m+hpBluTxrXnKc OcG0tuOrTuLjiI7fxp79Y58zCzhXL8dkL3ISA3AH+9fjiIBaLDANR2+dbEGWZQpl40PZJNf YKilTdKBtertgAl+Mysa5oRU42+Vex/9iE5j2KL/+nwcH3gZjAIFpoSES2ZxrtsNTLWjwRu zf0ezCWyHKfyiHdwLjx5w== X-UI-Out-Filterresults: notjunk:1;V01:K0:UBbJyC99JKY=:XcaITBiObXYUfZP5W9LOOE BA0CoCEFurp4GiL3JjRhsQfH2hjhvfUCgqDJ8b5wexJBWYiTfBnMY1dr7Fy3P85xpOC+BvwFC PjJqBPNSdtVLJSBhv+xCxv7R5GnZ+i0EWcRmebG1K656SS00ffMy8vmRuyOGd7fnAkq+O0Oik FdEMBimKlOjbNUOVJ/t6Y6+4+RRPGmDrQ+f1mFb0TUa/jGPs4YuWUKCA/Vlm/mCMRGpkYZfaM +Q/scrM+75tFUgpM/t2SGUZy6lnLrPVCVMLZ81I5ACyFPuX8iOJ+m39OfWLP3XQIPYd+wfBz5 mrDC+OZCb/E4lwaTufmxXJ6K9A83sNX8nG9osPE/3VZD09zy00S3mL6dYuDFKAAwPENnoOoPN jfBu1TPBGomMLrriq3A2tr7qJcTD39z4y2L6EYdxnGKFqSJYIKS+mb19mus8LUf4qBuMt3OyB U7uDtvKPwgtw5jCbemSVzdTUmHMH85BWu68ROyrUtvgCNx5zqkAUvHwOZZVue0CMagAeDdoZh KiEsuutNvfDyKBCQX3QJbMBlNru5HuxHfU+HihvhZ8uVfZvDmIKB/rpR3TtjH8EctnBGZor0r AREvQ0vdV4vN926mJvcI2CGnwOSWxzpC5y9EUOkVt8kuh3UM3pyxY42JCUgyJ/86pc+21aWqU zlBWXwYLOc1AzuWDuBVLGqvWQL1vvh2vugKLtO/AhasD9hYaYrX8SsIWsqZ3RPm/gQx90xmqz 0iY+snPQ6NJWj4FdFcQ9sfBw2R+F+ZW55ZO3kPIpSKMNuxlzJU+b5ssgwkA= Archived-At: Subject: [OAUTH-WG] Your Review of the Native Apps Draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2015 01:01:25 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --IjrJGFK7134xo9xsnvm7ag0IHG2kab1J4 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I just checked the minutes from the Prague IETF meeting and noticed that Tony, Brian, Erik, Nat, and Eduardo promised to review the native apps draft and post their review comments to the list. Could you please do your reviews? Ciao Hannes --IjrJGFK7134xo9xsnvm7ag0IHG2kab1J4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJWO/vcAAoJEGhJURNOOiAtZTIH/228vYQ9fVvBpUgGkh69HCSH 4StRKMG1MEEeULrdbFuGPz0j8f0Clpw4c1KdLVpbQlgq/mcWDzJHu7ikKX/mVB9p slHK890CVykvhZAQpFhq5RpG44mQ4Udz5zCWKi9vGy1VEgG8t5wRRJewoi6vdhc3 lb6v4AQwMaB+7E1JJHOyMwkUNdDxJnhlQsOPCrGah5mxGUtxUDSLHn/vRkDxSno3 xzWQ6mdwfM3KrRKALbVXMvPnAeYekgVclzNMnNxeZdIKIW3GE8GoI7UtAoJK8OLy qgNwzdg1l0y/8ftcIVGSKPgV405Zm1Er5n3/j1AGuDveMNCePXOYA7l0sFZhF4s= =Vpq/ -----END PGP SIGNATURE----- --IjrJGFK7134xo9xsnvm7ag0IHG2kab1J4-- From nobody Fri Nov 6 03:31:52 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 795B21B3A09 for ; Fri, 6 Nov 2015 03:31:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XUkzHSEeodLF for ; Fri, 6 Nov 2015 03:31:49 -0800 (PST) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::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 647301B3A08 for ; Fri, 6 Nov 2015 03:31:49 -0800 (PST) Received: by lfs39 with SMTP id 39so40708991lfs.3 for ; Fri, 06 Nov 2015 03:31:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wahlstromstekniska_se.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=ZkcG4fOC7c6zwxHNTPiF6ewbN4PjLqlQBO5vCzplj5I=; b=lngXLT6I6Gls+DlnjnFxeeKJ+9jkoKlqvUg8s4ASKslB9YR3lEnLwrtu97aMIeiCi9 CpTg++GmocLsC8l94nx//+p0MIDANTi3qEFTZiDu/Rdo54M/JOgbnQPEqmw7lg6X8PLN EcJ8qCIcSxykc77xcnH1zHXqi+CJmxksZDo6J2eNusEEraPS7+jI9ZooPq9Evg0NiLIp DWaPDN/JqV3Qu99se98yphx/m4xEl/qucutFItpPVA3hpEJ10oWxEqjl3/ihT/QtlLxp De4PW/4DkQENYXA4rMpL19s9moi0cRVOd+C7Whrv+XODm+gC3US6BhlYbJEq6reKEtqV rfRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=ZkcG4fOC7c6zwxHNTPiF6ewbN4PjLqlQBO5vCzplj5I=; b=CF3ZLipG6mEsrDrgB9rr4a0uaXsoh+B6/qFOmt6u8eSwPCI0zrhiwP/U2IdpsGHvll 9zw15ihlcnnn2Ki053Osoj53E0T4jhDLGfZQ4BihEmQ2JTee6CVAJqvkgXH9BqzRp0pw 4pgICxeaxgPC1Bebflg+7DY9zBGl5rdljRl0XNxUnA+egRGdwzx9pUxw6WRXi66YmWu6 nRBIaVOjPwoNHo+1hwvxFPi+ArnExzxxXUj2i3wI+bcpBCgqlzmgYG8r51AsOfr31ya/ Wvn0p+HIMD9/VWuGR0ZYrrqdYuN9bBqmh36/4Fi6RklLYQKG4uApeEycInO5dm6mufof XKhA== X-Gm-Message-State: ALoCoQnaLEQzuEiWre6ByZ22KwgC9mO2xpa/o0dlpioH90PpVgDlyIn+V+jxi5pzDhwrf9VgjsLQ X-Received: by 10.25.21.26 with SMTP id l26mr3980289lfi.122.1446809507106; Fri, 06 Nov 2015 03:31:47 -0800 (PST) Received: from [192.168.1.4] (37-247-26-197.customers.ownit.se. [37.247.26.197]) by smtp.gmail.com with ESMTPSA id c7sm1288228lfe.22.2015.11.06.03.31.46 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 06 Nov 2015 03:31:46 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_50411C8A-A32F-45F4-A529-923D86A20C19" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: =?utf-8?Q?Erik_Wahlstr=C3=B6m?= In-Reply-To: <563BFBDB.4050101@gmx.net> Date: Fri, 6 Nov 2015 12:31:45 +0100 Message-Id: References: <563BFBDB.4050101@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Your Review of the Native Apps Draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2015 11:31:51 -0000 --Apple-Mail=_50411C8A-A32F-45F4-A529-923D86A20C19 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I posted my review comments here = https://www.ietf.org/mail-archive/web/oauth/current/msg14835.html = Reposing it because the first comment in my review is also the same = question I asked in this meeting. The problem is mainly a usability = issue that needs some good recommendations in the draft. What happens to = your app if the browser starts other apps to complete an authentication = flow when the user comes back? The document need a note that this should = be handled in some good way when the app is resumed again. I can try it = out in a demo app we have that uses different eID=E2=80=99s (some apps) = for authentication to see if it=E2=80=99s possible to figure out some = good practices if that=E2=80=99s of interest. / Erik > On 06 Nov 2015, at 02:01, Hannes Tschofenig = wrote: >=20 > I just checked the minutes from the Prague IETF meeting and noticed = that > Tony, Brian, Erik, Nat, and Eduardo promised to review the native apps > draft and post their review comments to the list. >=20 > Could you please do your reviews? >=20 > Ciao > Hannes >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_50411C8A-A32F-45F4-A529-923D86A20C19 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I posted my review comments here https://www.ietf.org/mail-archive/web/oauth/current/msg14835.ht= ml

Reposing it = because the first comment in my review is also the same question I asked = in this meeting. The problem is mainly a usability issue that needs some = good recommendations in the draft. What happens to your app if the = browser starts other apps to complete an authentication flow when the = user comes back? The document need a note that this should be handled in = some good way when the app is resumed again. I can try it out in a demo = app we have that uses different eID=E2=80=99s (some apps) for = authentication to see if it=E2=80=99s possible to figure out some good = practices if that=E2=80=99s of interest.

/ Erik



On = 06 Nov 2015, at 02:01, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:

I just checked the = minutes from the Prague IETF meeting and noticed that
Tony, = Brian, Erik, Nat, and Eduardo promised to review the native apps
draft and post their review comments to the list.

Could you please do your reviews?

Ciao
Hannes

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

= --Apple-Mail=_50411C8A-A32F-45F4-A529-923D86A20C19-- From nobody Fri Nov 6 05:03:16 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02E351A6FD8 for ; Fri, 6 Nov 2015 05:03:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hu4UV8lwtvaG for ; Fri, 6 Nov 2015 05:03:12 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6FB21A6F56 for ; Fri, 6 Nov 2015 05:03:11 -0800 (PST) Received: from [192.168.10.246] ([210.160.37.27]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MC4R6-1Zlqyx3cEy-008oHw for ; Fri, 06 Nov 2015 14:03:09 +0100 To: "oauth@ietf.org" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <563CA507.1030500@gmx.net> Date: Fri, 6 Nov 2015 14:03:03 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="v6AwhINfvRJLx4vHAxq0XXGl9vxKLQoW6" X-Provags-ID: V03:K0:oXXm2oPccgV4q4ZJIlb3KdE84Yd4oTLAVVie8U7QnIGfvSrhyMX C4Jg8S/Fe8voSJsszj8Mqm0B7WzXwf6vUzGxsI3yrEl0NuWfyU/fE3ehyGz8iMnCHS2XwqW AYz6R0tZD0YWPDjcfGbdMhZHW9W1RhY7kJcwAuetVQqx+wTtUKt8ENi259ORSQ+Gr4/6yZp 6acQIgDv1IWKCvk0Nk3UA== X-UI-Out-Filterresults: notjunk:1;V01:K0:lMKj5DqXQcA=:qv5/TEp+rkWDizz7PITEkc iIAPEoEoteH1fKbMYH0uJ2nZikIl6r6Y4cqGyXbqZAY0uaR17bqrc0d2FhRiSPqwXRs4aeNrX ST4/j4L024jKqC1bkLXKg1nOQs7TQDxEyDPCHbrPLzMZntiCB2y5Fidbn2TjKmSWqUKidfGiB 9Ka2x8rZ76O5NlcXk9+DBcUS7O1MOxfoSg6qRMD5xifRujaXckDDMxOwPt1XaroRtW95gRVm6 vORALN/dEb7PCpA/lOUMtCU2OAC6ZRKKrNobbvMvNjc5cA8IyQZBPHHamq7ouwz8woE5c96ZR cmaKKrTyOf9E5d1ghWdwMoD2p7nm7cC22kkYIjO3VeOiAahPLhm/+a5WGI4nLncmQEFcTTOFd o6vyOIKbyGlu2Hw+J/0+w4mfE7CMb/AdCaiimM0JLsl8lbRcUgVlyi7p563t+r1YMmuBkZ5+Q hirQx0q61PpokkWWgFeXwg2eLLL4ewCnehEHaLi6wlbcSapFukWdyXNqOZGv5pF48zagrRMm1 GI3TG7urOS91GwDCH5u5P03pNjfEJOvJThYvtPtbVpY0yNlCxs8PQ4mRFd3bRzQrzeoeXBMj2 MOMsoWCMAu0Ea3EZZsXWndmV40qyIgt6VyU59TfNGCwz0ySs5J4GpafceLkKfSGU/KZdGjFj6 KgMOR8RkrSyBGoVEkvCafP2z124KrgsbrkxznZYQCcS0d07HqKGlpb0+LSv+iMfg7bd8Rw+Gt xnO8adlqx1FeocPil+q55jZhNMQw0rrGeEqEhp+m4S7GmR2nASxrEiifTYZYT5+jdJtAIC8xh pq9obYb Archived-At: Subject: [OAUTH-WG] IETF 93 OAuth WG Meeting Minutes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2015 13:03:15 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --v6AwhINfvRJLx4vHAxq0XXGl9vxKLQoW6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Here are the meeting minutes from the f2f. Please drop us a message if there is something missing or incorrect. --------- IETF 93 OAuth WG Meeting Minutes Room 301 Time: 15:20-17:20 Date: Thursday, November 5, 2015 (JST) Chairs: Hannes Tschofenig + Derek Atkins (absent) Minute Taker: Kepeng Li (and revised by Hannes Tschofenig) 1) Status Update (Hannes) - PoP Shepherd write-ups by Kepeng regarding PoP architecture and PoP Key Semantics. Both were sent to the IESG already. - Charter Update Hannes to submit an updated charter based on the outcome of the discussions during this meeting. 2) OAuth 2.0 JWT Authorization Request (Nat) http://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/ Nat goes through the issues raised during the WGLC reviews from Brian and Hannes. It was noted that the document could offer more background information about why a new serialization mechanism is offered. John mentioned that it could be noted that the request object travels through the browser and can therefore be modified. =09 Brian raised a question whether the request object is only encrypted. This lead to a discussion of the difference between encryption and integrity protection (using symmetric and asymmetric cryptography). The conclusion was reached that the security consideration section needs to be updated to explain what properties the different methods for using JWS/JWE provide. =09 Nat was also asked to provide additional text regarding replay attacks since third party signing does not allow the sender of the request object to compute a digital signature or a MAC (since Section 5.2 should make normative reference to OpenID Connect. Brian also pointed out that there is a conflict with the PoP key distribution draft that uses the 'aud' parameter. John noted that currently the 'aud' parameter is used towards a different endpoint, used as a query parameter, but it would probably be good to take this into account now. =09 Justin noted that there is general utility to indicate the audience. Today people are forced to use the scope for WHAT, HOW and HOW LONG the client wants to access a protected resource. The 'aud' describes the WHAT aspect. He suggested to take it a general utility extension that is indepdent of the PoP document. =09 Hannes added a remark that the 'aud' parameter / claim was a separate document and then we added it to the PoP document. =09 John said that we didn't had the wide-enough picture and we now understand things better. =09 Section 5.2: Discussion about where to register parameters -- in the IETF document or in the OIDC spec. Section 4.2.1 defines the precedence rules. It was unclear whether this is OIDC specific or whether this is OAuth related. Nat will make a update within two weeks. Kepeng and Mike volunteered to review the draft. 3) Proof-of-Possession Key Distribution (John) http://datatracker.ietf.org/doc/draft-ietf-oauth-pop-key-distribution/ John starts his presentation and focuses on the description of the threat against refresh tokens where a client is unable to secure access and refresh tokens. There have been some real-world attacks against websites that did not protect their token store properly. Of course, there is the assumption that some hardware security can be used to secure some credentials. In the initial draft we did not allow the client to change the key bound to the access tokens. A number of people want to rotate the key when they request a new access token. When we want to do that securely we need to offer PoP version of the refresh token. If an adversary gets hold The proposed resolution is the following: (a) For confidential clients the client ID/client secret is enough as a PoP feature for the refresh token. (b) For public clients we make use of PKCE as the PoP feature. It might also be a good time to extend PKCE to support an asymmetric version= =2E Need to incorporate comments from Tony in the mailing list where he argued that we need to support TPCs. He wants to use a wrapped key since the draft is not friendly towards client creating symmetric keys locally. Tony also raises the desire to allow attestation information to be conveyed from the client to the authorization server. Hannes argues that we shouldn't not make the document TPM specific but rather to be open for other hardware security solutions. Justin argues that we need very clear rules for precedence order. Discussion about how these rules could look like and how much complexity it introduces. 4) HTTP Signing (Justin) Justin goes through his slide deck where he explains the current status with the HTTP signing concept. In his presentation he also raises open issues, such as repeated headers. Need implementations and inputs to the designs. Hannes points out that recently two groups in Sweden (Roland Hedberg, Fredrik Ljunggren, and Jakob Schlyter) offered help with the document and will work on implementations. Nat believes that this document has some relationship with sender constraint draft. 5) Token Exchange (Mike) http://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/ At the Prague IETF meeting we had a good discussion about the open issues. The draft editors have been working on proposed resolutions. A new document is expected to be published soon. Brian and Mike will post to the list on how the issues have been addressed. 7) Rechartering (a) OAuth 2.0 for Native Apps (William) http://datatracker.ietf.org/doc/draft-wdenniss-oauth-native-apps/ With this work Williams described how to securely use OAuth with native apps by utilizing new mobile operating system concepts so that the client application is not able to get access to the user provided credentials. The concept also allows the re-use of the SSO mechanism for apps developed in the OpenID Foundation to be used. Furthermore it will make the use of FIDO for apps easier since FIDO support in the OS can be utilized rather than requiring app developers to develop authentication functionality into their apps. The finalization of PKSE also helps securing native apps. Sandeep asked how to differentiate from a webview and a phishing app internal browsers. William argues that the best possible way is to see the login dialog in the first place. There is also an icon to return to the app that created the view. Tony argues that there are some patterns described in the draft do not exist any more, such as the authentication to the IdP. Erik argues that it solves a lot of issues in the enterprise use case but the UI aspect has to be looked at. Poll: 16 persons for doing the work / 0 persons against / 2 persons need more info (b) Security Extensions & Fixes (John) John argues that the new charter needs to include work like the asymmetric PKCE extension, token binding for refresh tokens; redirection best practices, and post message response mode to replace fragment. Kepeng subsequently brielfy explains the sender constraint. Hannes notes that this is based on existing implementation. Poll: 17 for/0 against/0 need more info (c) API Management (Phil) Phil explains the concept of API management where a resource server registers configuration data about the protected resources to the authorization server. This is functionality introduced by UMA as resource set registration. Justin and Phil argue that there are requirements beyond what has been developed within UMA. The relevant UMA document can be found here: https://docs.kantarainitiative.org/uma/draft-oauth-resource-reg.html Since there is currently no draft available discussions start about the exact content. Poll: 6 for / zero against / 9 persons need more information. (d) JWT Claims (Mike) Mike gives an example of the need to define new JWT claims based on draft-jones-oauth-amr-values draft. Poll: 9 for / zero against / 6 persons need more information. (e) Device Flow (William) William goes through his short presentation and explains the device flow that was part of the OAuth 2.0 specification but then got moved into a separate draft. The document later expired but has been implemented by various companies, including Facebook and Google. Poll: 16 for / zero against / 2 persons need more information. (f) Discovery (Nat) Nat explains his document as an example of the work that has to be done in the area of discovery, which is a topic that has been identified as necessary for interoperability since many years but so far there was not time to work on it. Mike, John and Nat are working on a new document that describes additional discovery-relevant components. Poll: 19 for / zero against / 4 persons need more information. Hannes will post an charter proposal. --v6AwhINfvRJLx4vHAxq0XXGl9vxKLQoW6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJWPKUIAAoJEGhJURNOOiAt+ycIAJVSeIfv00vy4eboa8RcmxDl TUWm/GgTYIWsSQ68EpLIpRqSrQHIdVUXd/VKwwKqTFZABmm+qpLh1qPbkPyStL98 kfKmFLcg7+tpAoAw35b6jUIWKTB7i18n/tFuXrwhCGDrB9aCpItmaGFY/2CNay8t hA+ezLUBxSCSShKSr103RgLKlS83ollO3K7LEVSUFMFPfQ8UeGYqwfjEO+MyCSHM /jTsxRbGAzbJ77sIc1M2H7J51Js/paSw3FFbPVjGwuWH4zRj3cKh0isxPfCxkWf8 d1Lz+zKBfoaDduYwKLlB88mYGPFA6Oee1EuAvfVo+F7xiE1al2BMxwzMjAXldw0= =mszP -----END PGP SIGNATURE----- --v6AwhINfvRJLx4vHAxq0XXGl9vxKLQoW6-- From nobody Fri Nov 6 12:40:17 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67DE61B3047 for ; Fri, 6 Nov 2015 12:40:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.778 X-Spam-Level: X-Spam-Status: No, score=-0.778 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oHy9omnKnnZ1 for ; Fri, 6 Nov 2015 12:40:14 -0800 (PST) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::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 1B94C1B3046 for ; Fri, 6 Nov 2015 12:40:14 -0800 (PST) Received: by iodd200 with SMTP id d200so134184295iod.0 for ; Fri, 06 Nov 2015 12:40:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=nGk7tFKs4kdxeN4xAvrgBTskCUtHGILF1WfIg34zhdI=; b=gkjfDMwErhOlKz4pLx/yxF2Vc0t5mwGzzqxHfgFDUjLbSjW3V1qQYIFR3pcbOCsKed LspsvnVxSZ18rAFcDk0KM7FdaRahYox9iWgYF2ic6j5NRTlvB+Q+jSn20H0Opu1AJRlL 4Vyi2srkgD5F5dIWBOz9u/PVq/xcXqATH+d64= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-type; bh=nGk7tFKs4kdxeN4xAvrgBTskCUtHGILF1WfIg34zhdI=; b=JaupRTPrEl0QdXjGQNnlbm6Z+eD+o67tTVmgVwbrYD0RHRIaTRWp+x8LwdGkKMBEYl Zmbq+QuUWo8OsPa86atXqdWdmv+iC/sgH7JFJei0BIRlZu/rW4LWW9u5B6ekSJn8L9b6 G41BIuuq95H5HieZXxkkIgxe9WiYgQ9rgpKvaehTxR8gPFcf8rY+vOu/vn4pvODRgWax kpCbrkkjecbjwSc//tq9FsHDuBBVGKkl0p4XVFwG/Oh1Z9kwHEY4mvIprOEfE3JTCabR hlUkMaJ4yujkfN3aiOB7Jb6kFb999LIXY3oGdpTGzYVhcyizhBFIWPhDgITisqEuPCwY GU0A== X-Gm-Message-State: ALoCoQkovLVl+rEXr9TYQaol4NRk5iR57ywehOxzWY0/TBp7h3rQeuxHslv95RsyvvKssP5ItMPZ X-Received: by 10.107.7.24 with SMTP id 24mr12751177ioh.48.1446842413193; Fri, 06 Nov 2015 12:40:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.117.132 with HTTP; Fri, 6 Nov 2015 12:39:43 -0800 (PST) From: Brian Campbell Date: Fri, 6 Nov 2015 13:39:43 -0700 Message-ID: To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=001a113f8b8215b9ab0523e54025 Archived-At: Cc: "oauth@ietf.org" Subject: [OAUTH-WG] (was Re: IETF 93 OAuth WG Meeting Minutes) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2015 20:40:15 -0000 --001a113f8b8215b9ab0523e54025 Content-Type: text/plain; charset=UTF-8 Adding those security considerations is probably a good idea but it doesn't actually address the question from my WGLC comments on draft-ietf-oauth-jwsreq-06 . The question was about what from an encrypted only Request Object should have. There's text in the draft that seems to suggest it must be a JWS with alg=none nested inside a JWE. But there's also text that suggests a JWE with JSON Claims directly as the payload is okay. I was asking what the intent of the spec actually was and that it be clarified in the doc. On Fri, Nov 6, 2015 at 6:03 AM, Hannes Tschofenig wrote: > > Brian raised a question whether the request object is only > encrypted. > This lead to a discussion of the difference between encryption and > integrity protection (using symmetric and asymmetric cryptography). The > conclusion was reached that the security consideration section needs to > be updated to explain what properties the different methods for using > JWS/JWE provide. > > --001a113f8b8215b9ab0523e54025 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Adding those security considerations is probably a go= od idea but it doesn't actually address the question from my WGLC comments on draft-ietf-oauth-jwsreq-06.

T= he question was about what from an encrypted only Request Object should hav= e. There's text in the draft that seems to suggest it must be a JWS wit= h alg=3Dnone nested inside a JWE. But there's also text that suggests a= JWE with JSON Claims directly as the payload is okay. I was asking what th= e intent of the spec actually was and that it be clarified in the doc.
=

On Fri,= Nov 6, 2015 at 6:03 AM, Hannes Tschofenig <hannes.tschofenig@gmx.= net> wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Brian raised a question whether the request obj= ect is only encrypted.
This lead to a discussion of the difference between encryption and
integrity protection (using symmetric and asymmetric cryptography). The
conclusion was reached that the security consideration section needs to
be updated to explain what properties the different methods for using
JWS/JWE provide.
=C2=A0 =C2=A0=C2=A0
--001a113f8b8215b9ab0523e54025-- From nobody Fri Nov 6 12:45:54 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5CEA1B3081 for ; Fri, 6 Nov 2015 12:45:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.778 X-Spam-Level: X-Spam-Status: No, score=-0.778 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pME926Xjoc1d for ; Fri, 6 Nov 2015 12:45:49 -0800 (PST) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 910761B3080 for ; Fri, 6 Nov 2015 12:45:49 -0800 (PST) Received: by igdg1 with SMTP id g1so46359743igd.1 for ; Fri, 06 Nov 2015 12:45:49 -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:content-type; bh=QlCa6rq8nYazGMZu2Ha4x5o9WvfZoYpsb3ACCNRW9rA=; b=QUMBafTrVKpK7BHCFooRBmrIMeEJwYa/gL/ZQbhpydms9rN384UeOBtBylhqTcL9gq oZmdR40lOnS1PN13pDYSlxuwcm6b5BV82lJni/SdAm2RdUJBV04+vgEhrae+G4hIdCgO Ds2KLkEHqrhUoJjtzvoWsmUaRjP8NO8DaogG0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=QlCa6rq8nYazGMZu2Ha4x5o9WvfZoYpsb3ACCNRW9rA=; b=iVmK/y5UZHkA5aWtCZTN9su4ZHnTuQ33WEPEUbyU3ljf18Pdc1qsm5cTV6IsrnI8M6 wsyzFIhfDXhWHEdTp6QmyCrYghPQMToMW+Xnq2n54exSWAH7pnXqYHAGVLi0eraC/RWV cYf08zCsVFaCzkT2u+O4SACUrzH85wVDloftM4wgaCmq+S4vTd1XCJMq6jNe8xb34Z6f /aPj7yRSxCjk706pBKRtPHJmqGDOybSO6jrcb0kL/NCwxl47arUpNICHg6FB0SFIrJ1E KapYfO3CQS6GwkYkJXbveYrTdrKwXWOu7uF5qSfnbPzPCb10hqes+xuYCEVIlK4QgW3B h7yw== X-Gm-Message-State: ALoCoQkzIPZJgB7Dr3gAyvwaKisHHMg9QChm3UIoD+vaW/bcStt8FzDK9AQaEOt8sKAZMGuRkWkq X-Received: by 10.50.28.70 with SMTP id z6mr2133992igg.57.1446842748816; Fri, 06 Nov 2015 12:45:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.117.132 with HTTP; Fri, 6 Nov 2015 12:45:19 -0800 (PST) In-Reply-To: References: <152AD4F1-84EF-47DC-9A41-C7413DE5464B@mit.edu> From: Brian Campbell Date: Fri, 6 Nov 2015 13:45:19 -0700 Message-ID: To: Mike Jones Content-Type: multipart/alternative; boundary=089e0158b2ce16fc070523e5545e Archived-At: Cc: "" Subject: Re: [OAUTH-WG] some WGLC comments on draft-ietf-oauth-jwsreq-06 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2015 20:45:53 -0000 --089e0158b2ce16fc070523e5545e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Apologies - I'd forgotten about the pending errata. On Wed, Oct 28, 2015 at 5:07 PM, Mike Jones wrote: > This working draft > http://openid.net/specs/openid-connect-registration-1_0-29.html > containing the OpenID Connect Dynamic Registration errata 2 edits to date > contains the registration requests that you=E2=80=99re referring to. See > http://openid.net/specs/openid-connect-registration-1_0-29.html#DynRegCon= tents > and > http://openid.net/specs/openid-connect-registration-1_0-29.html#TEAMConte= nts > . > > > > -- Mike > > > > *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Justin Riche= r > *Sent:* Wednesday, October 28, 2015 3:16 PM > *To:* Brian Campbell > *Cc:* > *Subject:* Re: [OAUTH-WG] some WGLC comments on draft-ietf-oauth-jwsreq-0= 6 > > > > The errata/update version of Connect=E2=80=99s registration spec need to = register > a bunch of stuff in the Dyn-Reg IANA registry, but I don=E2=80=99t think = that=E2=80=99s > been done yet. > > > > =E2=80=94 Justin > > > > On Oct 27, 2015, at 3:41 PM, Brian Campbell > wrote: > > > > Sakimura-san, Senior Bradley, and distinguished members of the OAUTH WG, > > I re-read draft-ietf-oauth-jwsreq (-06 anyway, it'd been a while) for WGL= C > and, while I feel it's in pretty good shape, I did have a few comments on > the draft. Those are listed below in roughly the order I came across thin= gs > while reading the document. > > > To my eye, "oauth-jar" looks a bit awkward. I'd suggest changing the > abbrev to something like > "OAuth JAR". > > From the wording in Section 3 > , it is > unclear whether the Request Object can be a JWE only or if a JWS is alway= s > used (with alg:none for unsigned) and is nested within a JWE when > encryption but not singing is needed. To my reading there is text that > suggest both cases. Which is it? I think some clarification is needed > around this. Section 5.1 > > doesn't help me as I'm unsure if "unsigned (plaintext) Request Object" is > an out-of-date usage of the old way to refer to the "none" JWS alg or is > intended to mean the straight up JSON of the request object parameters. > > Also in Section 3 > , the > sentence 'The Authorization Request Object MAY alternatively be sent by > reference using the "request_uri" parameter.' reads a little awkward > because the other alternative isn't explicit discussed anywhere nearby. > Perhaps something like "The Authorization Request Object may be sent by > value as described in section 4.1 or by reference as described in section > 4.2."? > > Also in Section 3 > , the > sentence "If a required parameter is not present in neither the query > parameter nor the Request Object, it forms a malformed request." made my > brain hurt. Maybe reword to something like, "If a required parameter is > missing from both the query parameters and the Request Object, the reques= t > is considered malformed."? > > > Also in Section 3 > , '... > the Authorization Request Object SHOULD contain the Claims "iss" (issuer) > and "aud" (audience) as members ...', however, that will produce a > parameter name conflict with the "aud" parameter from OAuth 2.0 > Proof-of-Possession: Authorization Server to Client Key Distribution. > > Seems like draft-ietf-oauth-pop-key-distribution will need to change its > parameter name (aud in JWT is pretty well established). And shouldn't > draft-ietf-oauth-jwsreq register some of the JWT's Registered Claim Names > (at least iss and aud > but maybe exp and others) as authorization request OAuth parameters > > ? > > Also in Section 3 > , I > personally feel like the "extension variables" detract from the example > being able to easily convey the concept. I would suggest using only > 'vanilla' OAuth parameters. Or, at the very least, removing the "claims" > stuff, which doubles the space used by the example and is a very OpenID > Connect specific thing. This applies to the examples throughout the draft > including those that have the encoded JWT Request Object. > > In Section 4 > , the > whole "The client constructs the authorization request URI by ..." follow= ed > by the list of parameters is somewhat awkward to me - especially with the > "REQUIRED"s. Why list "state" here and none of the others here? I think I > know why (you expect state to vary on each request but not others) but a > lot of inferring needs to happen from the reader. For the extension > defined in this document, one uses either request_uri or request (but not > both, right? I'm not sure it's explicitly stated anywhere) and whatever > other parameters are needed in the given situation. Maybe just some text > towards that end rather than the list format? > > Also in Section 4 > , the > request_uri in the example is a lot like the URI that's used for > redirect_uri in a lot of places (the /cb path, I think, was intended to > short for callback). I mean, it *could* happen but the example is more > confusing than needs to be. It's also too long/wide for the page - add so= me > line breaks, which are for display purposes only. Perhaps move this examp= le > to 4.2(.1) somewhere and match the value with the value shown there? > > Also in Section 4 > , the > sentence that starts with 'When the "request" parameter is used...' > suggests that the text about JWT parameters superseding others is only > applicable to the pass by value method but it applies to both. Perhaps > change '"request" parameter' to 'Request Object'? > > The second paragraph of Section 4.2.1 > > talks about "requested values for Claims" which is an OpenID Connect thin= g > that isn't really applicable to this draft. Can this paragraph be dropped > or made more general to be about any potentially sensitive or PII data? > > Also in Section 4.2.1 > , > is "... at a URL the Server can access... " - assume the "Authorization > Sever"? > > Isn't it a bit odd in Section 5.2 > to > talk about the "request_object_signing_alg" which is defined in OpenID > Connect Dynamic Client Registration > (which is > not referenced) and kinda mentioned in OpenID Connect Core > (informative > referenced)? I don't know that it belongs here? Or if it does, what about > request_object_encryption_alg and request_object_encryption_enc? I suppos= e > related to that is the question of if/how to use the client_secret for HM= AC > and symmetric encryption algorithms and if that needs to be discussed her= e? > Indicating public key(s) too for that matter. Seems like all the > metadata/registration stuff should be in here. Or it should all be out of > scope. But just the request_object_signing_alg seems odd to me. > > Section 6 > says > that "... this document defines additional error values ..." but those we= re > previously defined in 3.1.2.6 of OpenID Connect Core > . Maybe > just change the wording to reflect the real state of things? > > > > Section 7 > says > that "The request_object_signing_alg OAuth Dynamic Client Registration > Metadata is pending registration by OpenID Connect Dynamic Registration > specification." But is that true? The registry > > doesn't have it and Connect's Registration > > "makes no requests of IANA". > > As I'm sure reading this has been a ton of fun for the editors, I'm sure > you will be happy to please add me to the Acknowledgements Section > ;) > > > > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > --089e0158b2ce16fc070523e5545e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Apologies - I'd forgotten about the pending errata.

On Wed, O= ct 28, 2015 at 5:07 PM, Mike Jones <Michael.Jones@microsoft.com<= /a>> wrote:

This working draft http://openid.net/specs/openid-connect-registration-1_0-= 29.html containing the OpenID Connect Dynamic Registration errata 2 edi= ts to date contains the registration requests that you=E2=80=99re referring to.=C2=A0 See http://openid.net/specs/openid-connect-registration-1_0-29.html#DynRegConte= nts and http://openid.net/specs/openid-connect-registration-1_0-29.html#TEAMContent= s.

=C2=A0

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

=C2=A0

From: OAuth [m= ailto:oauth-bou= nces@ietf.org] On Behalf Of Justin Richer
Sent: Wednesday, October 28, 2015 3:16 PM
To: Brian Campbell
Cc: <oauth@ie= tf.org>
Subject: Re: [OAUTH-WG] some WGLC comments on draft-ietf-oauth-jwsre= q-06

=C2=A0

The errata/update version of Connect=E2=80=99s regis= tration spec need to register a bunch of stuff in the Dyn-Reg IANA registry= , but I don=E2=80=99t think that=E2=80=99s been done yet.

=C2=A0

=C2=A0=E2=80=94 Justin

=C2=A0

On Oct 27, 2015, at 3:41 PM, Brian Campbell <bcampbell@pingi= dentity.com> wrote:

=C2=A0

Sakimura-san, Senior = Bradley, and distinguished members of the OAUTH WG,

I re-read draft-ietf-oauth-jwsreq (-06 anyway, it= 9;d been a while) for WGLC and, while I feel it's in pretty good shape,= I did have a few comments on the draft. Those are listed below in roughly = the order I came across things while reading the document.


To my eye, "oauth-jar" looks a bit awkward. I'd suggest chang= ing the abbrev to something like
"OAuth JAR".

From the wording in <= a href=3D"https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-06#section-3"= target=3D"_blank"> Section 3, it is unclear whether the Request Object can be a JWE only o= r if a JWS is always used (with alg:none for unsigned) and is nested within= a JWE when encryption but not singing is needed. To my reading there is te= xt that suggest both cases. Which is it? I think some clarification is needed around this. Section 5.1 doesn't help me as I'm unsure if "unsigned (pl= aintext) Request Object" is an out-of-date usage of the old way to ref= er to the "none" JWS alg or is intended to mean the straight up J= SON of the request object parameters.

Also in Section 3, the sentence 'The Authorization Request Object MAY alter= natively be sent by reference using the "request_uri" parameter.&= #39; reads a little awkward because the other alternative isn't explici= t discussed anywhere nearby. Perhaps something like "The Authorization Request Object may be sent by value as described in section = 4.1 or by reference as described in section 4.2."?

Also in Section 3, the sentence "If a required parameter is not present in= neither the query parameter nor the Request Object, it forms a malformed r= equest." made my brain hurt. Maybe reword to something like, "If = a required parameter is missing from both the query parameters and the Request Object, the request is considered malformed.&qu= ot;?


Also in Section 3, '... the Authorization Request Object SHOULD contain the= Claims "iss" (issuer) and "aud" (audience) as members = ...', however, that will produce a parameter name conflict with the &qu= ot;aud" parameter from OAuth 2.0 Proof-of-Possession: Authorization Server to Client Key Distribut= ion. Seems like draft-ietf-oauth-pop-key-distribution will need to chan= ge its parameter name (aud in JWT is pretty well established). And shouldn&= #39;t draft-ietf-oauth-jwsreq register some of the JWT's Registered Claim Names (at least iss and aud but maybe exp an= d others) as authorization request OAuth parameters?

Also in Section 3, I personally feel like the "extension variables" d= etract from the example being able to easily convey the concept. I would su= ggest using only 'vanilla' OAuth parameters. Or, at the very least,= removing the "claims" stuff, which doubles the space used by the example and is a very OpenID Connect specific thing. This appl= ies to the examples throughout the draft including those that have the enco= ded JWT Request Object.

In Section 4, the whole "The client constructs the authorization requ= est URI by ..." followed by the list of parameters is somewhat awkward= to me - especially with the "REQUIRED"s. Why list "state&qu= ot; here and none of the others here? I think I know why (you expect state to vary on each request but not others) but a lot of inferrin= g needs to happen from the reader.=C2=A0 For the extension defined in this = document, one uses either request_uri or request (but not both, right? I= 9;m not sure it's explicitly stated anywhere) and whatever other parameters are needed in the given situation. Maybe jus= t some text towards that end rather than the list format?

Also in Section 4, the request_uri in the example is a lot like the URI that= 9;s used for redirect_uri in a lot of places (the /cb path, I think, was in= tended to short for callback). I mean, it *could* happen but the example is= more confusing than needs to be. It's also too long/wide for the page - add some line breaks, which are for disp= lay purposes only. Perhaps move this example to 4.2(.1) somewhere and match= the value with the value shown there?

Also in Section 4, the sentence that starts with 'When the "request&qu= ot; parameter is used...' suggests that the text about JWT parameters s= uperseding others is only applicable to the pass by value method but it app= lies to both. Perhaps change '"request" parameter' to 'Request Object'?

The second paragraph = of Section 4.2.1 talks about "requested values for Claims" which= is an OpenID Connect thing that isn't really applicable to this draft.= Can this paragraph be dropped or made more general to be about any potenti= ally sensitive or PII data?

Also in Section 4.2.1, is "... at a URL the Server can access... " - = assume the "Authorization Sever"?

Isn't it a bit od= d in Section 5.2 to talk about the "request_object_signing_alg" wh= ich is defined in OpenID Connect Dynamic Client Registration (which is not referenced) an= d kinda mentioned in OpenID Connect Core (informative referenced)? I don't know = that it belongs here? Or if it does, what about request_object_encryption_a= lg and request_object_encryption_enc? I suppose related to that is the question of if/how to use the client_secret= for HMAC and symmetric encryption algorithms and if that needs to be discu= ssed here? Indicating public key(s) too for that matter. Seems like all the= metadata/registration stuff should be in here. Or it should all be out of scope. But just the request_object_= signing_alg seems odd to me.

Section 6 says that "..= . this document defines additional error values ..." but those were pr= eviously defined in 3.1.2.6 of OpenID Connect Core. Maybe just change the wording to reflec= t the real state of things? =C2=A0

=C2=A0

S= ection 7 says that "The request_object_signing_alg OAuth Dynamic C= lient Registration Metadata is pending registration by OpenID Connect Dynamic Registration specification." But is that tr= ue? The registry doesn't have it and Connect's Registration "makes no requests of IANA".

As I'm sure reading this has been a ton of fun f= or the editors, I'm sure you will be happy to please add me to the Acknowledgements Section ;)

=C2=A0

=C2=A0

=C2=A0<= /p>

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

=C2=A0


--089e0158b2ce16fc070523e5545e-- From nobody Fri Nov 6 12:57:25 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ED7A1A0370 for ; Fri, 6 Nov 2015 12:57:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zIM93rSsw4Jx for ; Fri, 6 Nov 2015 12:57:23 -0800 (PST) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::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 E02E51A036F for ; Fri, 6 Nov 2015 12:57:22 -0800 (PST) Received: by igbhv6 with SMTP id hv6so43540963igb.0 for ; Fri, 06 Nov 2015 12:57:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:from:date:message-id:subject:to:content-type; bh=pPTuFgFXV+SU5PzE/y2CCVVGWu9GDD4rCaQ0t4RsZy4=; b=JSDGn7kUAngTARd9SzzJqdygB0iKrbbxvC/HuCGIkYGtsw0QKDextm6gfC45ps53YN xnSbwDQK9lb0M+bETxGx9migpYkgoM3MrcyPvAqXTSA3TkASMWPoa7jDakfCkCgS9uW7 jw8D89xC3GilAYz0QdHSfIbYq3n/VNsN74kaI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=pPTuFgFXV+SU5PzE/y2CCVVGWu9GDD4rCaQ0t4RsZy4=; b=IRbDY2VP9AtgADQT8I2NRPYia8zQ5cm/bsigqoHs9pL01e4QRHAIOxSxyENwjvjVQ6 Uf5+58tI57OVoyR4Oxd4LRh8fFsaWmEua8xhNCecwGsm8VqCE3NBQws7jYwIMRwbqjCF ihO86EGUHjHECxjEhA0qvtOasae1EIm9XA8Uhpm254AZJqCf/f3MLxiMnAmMdxOC1HjO NrSXS/KptKDqipAK+K6eQ0gU22GtZLim+zaq2uqmTvI3cFV0pKorcQxHvIkts+d+7dp1 uhJZECjEeDuJftpKqXGCMHtaSJgDlW8Sg0mhoPsQkdVuBVw+b+FMkii05CsAhcWe7z5F 6elw== X-Gm-Message-State: ALoCoQmoGWL+F5l+8kIrI6R4dYiffsZ+2ALmJ+CVPNAvq0K+WQj7VoNOVRU9frYiSLfn5nKC2H4e X-Received: by 10.50.23.38 with SMTP id j6mr10751037igf.57.1446843442276; Fri, 06 Nov 2015 12:57:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.117.132 with HTTP; Fri, 6 Nov 2015 12:56:52 -0800 (PST) From: Brian Campbell Date: Fri, 6 Nov 2015 13:56:52 -0700 Message-ID: To: oauth Content-Type: multipart/alternative; boundary=089e0158b23a6c49eb0523e57d70 Archived-At: Subject: [OAUTH-WG] one more post-WGLC comment on draft-ietf-oauth-jwsreq-06 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2015 20:57:24 -0000 --089e0158b23a6c49eb0523e57d70 Content-Type: text/plain; charset=UTF-8 Section 3 has, "If signed, the Authorization Request Object SHOULD contain the Claims "iss" (issuer) and "aud" (audience) as members, with their semantics being the same as defined in the JWT [RFC7519 ] specification." however OAuth doesn't really define an identifier for an AS (like Connect does with its Issuer). What value should a client use for 'aud' to identify the AS? The example later in the section has "aud": "https://server.example.com". However, the example seems to have just been copied from OpenID Connect and is using the Connect concept of Issuer which isn't currently defined or meaningful in the context of this document. --089e0158b23a6c49eb0523e57d70 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Section 3 has,

"If signed, th= e Authorization Request Object SHOULD contain the Claims "iss" (issuer) and &q= uot;aud" (audience) as members, with their semantics being the same as defined in the JWT [RFC7519] specification."

however OAuth doesn't really define an identifier for an AS (like Co= nnect does with its Issuer). What value should a client use for 'aud= 9; to identify the AS?

The example later in the section has &q= uot;aud": "https://server.= example.com". However, the example seems to have just been copied = from OpenID Connect and is using the Connect concept of Issuer whi= ch isn't currently defined or meaningful in the context of this documen= t.=C2=A0
--089e0158b23a6c49eb0523e57d70-- From nobody Fri Nov 6 14:57:22 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45A491A8AB3 for ; Fri, 6 Nov 2015 14:57:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TtsBU9CBI2Sr for ; Fri, 6 Nov 2015 14:57:19 -0800 (PST) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A2E21A8AC0 for ; Fri, 6 Nov 2015 14:57:19 -0800 (PST) Received: by ioc74 with SMTP id 74so71423344ioc.2 for ; Fri, 06 Nov 2015 14:57:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=ZV3CX08h5pZ3f8URqCzZY9kS9iNL/qPk9O5GC6nZXY0=; b=IklYVsOMIQiW0kjxhHsX1IM+km1RgdzXlsI/5jJiVDfZgAtC3ydbmiw55b/Dso8Ek/ VqTPsL033aHHOayTqmbXVoYayOOqLogu1qMfbYFvrgWYO/pfAjKSIdhiqCqgLxmJEVOG 4e7b6sTXtwbJEKmgR69s6iK3CT1uedqKukuJQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-type; bh=ZV3CX08h5pZ3f8URqCzZY9kS9iNL/qPk9O5GC6nZXY0=; b=GkwaF9D+UUvJh0m0DY/rGS/Zc1M+epxeD1xSsWrfpLa5eGr6jnkOtghyuHPCTOj8de cpxv2qsEXrHN4Aiq9OZdOAPaZNj8EpiTfMn+kqyQ9MDAXlCmfGTBMbjbcfqVvBpz3I12 VFaEy5uwgbS5KV8aLI3+cue+NRD3lzOEsxkP/kU2LHhdGAukvrCclPuXs0Tyn0yYaM8s qIIqg9PPn52Vy7a4qbftkRGOejtNbvy+RFH3OwBmiEDky59C6tcGg4MkOHb5I1ljDXpL Er/6RaZ6d2G0r4NAMN+skwYGFlEB24PAB4iD2Br4YJ+yyAhTc4AH1LGIMZipyPOcmlah 7dIQ== X-Gm-Message-State: ALoCoQlp+WuZRvdRkgfhrup2l68nXlwVPO0i8R/zlKm4J7ZkAdvnRp2GD5hD/GcyAPGRhFuMr3lG X-Received: by 10.107.7.24 with SMTP id 24mr13293363ioh.48.1446850638598; Fri, 06 Nov 2015 14:57:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.117.132 with HTTP; Fri, 6 Nov 2015 14:56:49 -0800 (PST) From: Brian Campbell Date: Fri, 6 Nov 2015 15:56:49 -0700 Message-ID: To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=001a113f8b825b6dc50523e72a1b Archived-At: Cc: "oauth@ietf.org" Subject: [OAUTH-WG] aud, JAR, PoP key distro, etc. (was Re: IETF 93 OAuth WG Meeting Minutes) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2015 22:57:21 -0000 --001a113f8b825b6dc50523e72a1b Content-Type: text/plain; charset=UTF-8 That's right, sorry, there's not actually a conflict now as the PoP key distribution draft currently only uses the 'aud' parameter at the token endpoint. I just assume it will end up being used at the authorization endpoint eventually because the need to disambiguate where the token will be used isn't limited to the token endpoint (we do have this implicit thing). As John mentioned, we have used an 'aud' parameter (interpreted as a resource location) in our AS on both endpoints to allow the client to indicate where it intends to use the token it's asking for, which enables the AS to apply unique policy to that token for the given resource (it's not the exact same thing as PoP key distribution but conceptually similar). So I was confusing implementation experience with what was actually in the PoP key distribution draft. That said, I do think that JAR should register JWT claims that it's likely to use in the Request Object as authorization endpoint parameters to avoid this kind of conflict. And I something like the 'aud' parameter is needed at both the token and authorization endpoints so PoP key distribution should use a different name. Or this potential independent draft, which I do think has value. I was planning on proposing something that's based on similar parameters being worked on in token exchange - we're just not there quite yet. On Fri, Nov 6, 2015 at 6:03 AM, Hannes Tschofenig wrote: > > Brian also pointed out that there is a conflict with the PoP key > distribution draft that uses the 'aud' parameter. John noted that > currently the 'aud' parameter is used towards a different endpoint, used > as a query parameter, but it would probably be good to take this into > account now. > > Justin noted that there is general utility to indicate the > audience. > Today people are forced to use the scope for WHAT, HOW and HOW LONG the > client wants to access a protected resource. The 'aud' describes the > WHAT aspect. He suggested to take it a general utility extension that > is indepdent of the PoP document. > > Hannes added a remark that the 'aud' parameter / claim was a > separate > document and then we added it to the PoP document. > > John said that we didn't had the wide-enough picture and we now > understand things better. > > --001a113f8b825b6dc50523e72a1b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
That's right, sorry, there's not actuall= y a conflict now as the PoP key distribution draft currently only uses the = 'aud' parameter at the token endpoint.

I just assume = it will end up being used at the authorization endpoint eventually because = the need to disambiguate where the token will be used isn't limited to = the token endpoint (we do have this implicit thing). As John mentioned, we = have used an 'aud' parameter (interpreted as a resource location) i= n our AS on both endpoints to allow the client to indicate where it intends= to use the token it's asking for, which enables the AS to apply unique= policy to that token for the given resource (it's not the exact same t= hing as PoP key distribution but conceptually similar). So I was confusing = implementation experience with what was actually in the PoP key distributio= n draft.

That said, I do think that JAR should register J= WT claims that it's likely to use in the Request Object as authorizatio= n endpoint parameters to avoid this kind of conflict.

An= d I something like the 'aud' parameter is needed at both the token = and authorization endpoints so=C2=A0 PoP key distribution should use a diff= erent name. Or this potential independent draft, which I do think has value= . I was planning on proposing something that's based on similar paramet= ers being worked on in token exchange - we're just not there quite yet.= =C2=A0





On Fri, Nov 6, 2015 at 6:03 AM, Hannes= Tschofenig <hannes.tschofenig@gmx.net> wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Brian also pointed out that there is a conflict= with the PoP key
distribution draft that uses the 'aud' parameter. John noted that currently the 'aud' parameter is used towards a different endpoint,= used
as a query parameter, but it would probably be good to take this into
account now.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Justin noted that there is general utility to i= ndicate the audience.
Today people are forced to use the scope for WHAT, HOW and HOW LONG the
client wants to access a protected resource. The 'aud' describes th= e
WHAT aspect.=C2=A0 He suggested to take it a general utility extension that=
is indepdent of the PoP document.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Hannes added a remark that the 'aud' pa= rameter / claim was a separate
document and then we added it to the PoP document.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 John said that we didn't had the wide-enoug= h picture and we now
understand things better.
=C2=A0
--001a113f8b825b6dc50523e72a1b-- From nobody Fri Nov 6 15:07:45 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 854B11A92B7 for ; Fri, 6 Nov 2015 15:07:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d4DpcEhG8FOz for ; Fri, 6 Nov 2015 15:07:40 -0800 (PST) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 583C91AC3AC for ; Fri, 6 Nov 2015 15:07:40 -0800 (PST) X-AuditID: 1209190d-f79306d000006b70-ec-563d32baf3f2 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id F8.19.27504.AB23D365; Fri, 6 Nov 2015 18:07:38 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id tA6N7bet030565; Fri, 6 Nov 2015 18:07:38 -0500 Received: from [100.117.16.1] (16.98.142.210.ap.mvno.net [210.142.98.16]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id tA6N7XHm003378 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 6 Nov 2015 18:07:36 -0500 Date: Sat, 07 Nov 2015 08:07:31 +0900 Message-ID: Importance: normal From: Justin Richer To: Brian Campbell , Hannes Tschofenig MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.android.email_913150996140290" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupgleLIzCtJLcpLzFFi42IR4hRV1t1lZBtmsGmhmcXq/zcZLZbuvMdq cfLtKzYHZo/Fm/azeSxZ8pPJ4+7RiywBzFFcNimpOZllqUX6dglcGZvmvWMpOBhYMbm/m7GB ca5/FyMHh4SAiUTjXZsuRk4gU0ziwr31bF2MXBxCAouZJL48nc4I4WxglDh/6zpU5iiTxJMr N1lAWlgEVCWe3rzGBGILC6RITJn0nxXE5hVwk2i4v4IdZAOngJBE1y4JkDAbUPn0NS1g5SIC mRJ/d21lBLGZgeJfFrxngmgVlDg58wkLRDxEYvb9o0wTGPlmIUnNQpKCsNUl/sy7xAxhK0pM 6X7IPgtoM7OAmsSyViVk4QWMbKsYZVNyq3RzEzNzilOTdYuTE/PyUot0jfRyM0v0UlNKNzGC A1qSdwfju4NKhxgFOBiVeHg3/LAJE2JNLCuuzD3EKMnBpCTKu4DZNkyILyk/pTIjsTgjvqg0 J7X4EKMEB7OSCG+NElCONyWxsiq1KB8mJc3BoiTOu+kHX4iQQHpiSWp2ampBahFMVoaDQ0mC 950hUKNgUWp6akVaZk4JQpqJgxNkOA/Q8JsgNbzFBYm5xZnpEPlTjJpS4rzTQBICIImM0jy4 XlDCSSkVYATRl/qSBF4xigO9JMybC1LNA0xecFNeAS1gAlrgEGUDsqAkESEl1cCoVMLa4PzU qjdPKzeK3fr3ib8iXZsNy7Y5H8k8le34p+8Ak9d77QO1opmRMw4/fcyy30TKZi7TzvO75vif iHxyItxrkceikmjB5eL7UnoO/qxe9/1aXrLvDJ4Lbm1bvHe/LXA2mK4vsnr935B1s7wmWRov 2sMh1LFIc+HkgpobTNe91f76reBXYinOSDTUYi4qTgQAmvtvAhsDAAA= Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] aud, JAR, PoP key distro, etc. (was Re: IETF 93 OAuth WG Meeting Minutes) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2015 23:07:43 -0000 ----_com.android.email_913150996140290 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 CiAgICAKSSB3YXMgY29uc2lkZXJpbmcgcHJlcGFyaW5nIGFuICJleHRlbmRlZCBzY29wZXMiIGNv bmNlcHQgZHJhZnQgdG8gZGVmaW5lIGJvdGggYSB0YXJnZXQgcGFyYW1ldGVyICh3aGF0IHdlJ3Jl IHVzaW5nICJhdWQiIGZvcikgYXMgd2VsbCBhcyBhIHRlbXBvcmFsIHBhcmFtZXRlciwgdG8gc2l0 IGJlc2lkZSBzY29wZSB3aGljaCBpcyBtb3JlIG5hdHVyYWxseSBhbiAiZXh0ZW50IG9mIHBlcm1p c3Npb24iLgpXZSBuZWVkIHRoZSBhdWRpZW5jZSBiaXQgZm9yIEhFQVJULCBhbmQgSSBrbm93IG90 aGVycyB0aGF0IGRvIGFzIHdlbGwuwqAKSSBwcm9wb3NlIHdlIGRlZmluZSBhbiBleHRlbmRlZCBz Y29wZXMgZG9jdW1lbnQgbGlrZSB0aGlzIHRvIGNhcHR1cmUgYSBjb3VwbGUgY2F0ZWdvcmllcyBs aWtlIHRoYXQuIEdvb2QgbmV3cyBpcyB0aGF0IHdlIGRvIGhhdmUgc29tZSBpbXBsZW1lbnRhdGlv biBleHBlcmllbmNlIGZyb20gYm90aCBwaW5nIGFuZCBNaWNyb3NvZnQgb24gdGhpcy7CoAotLSBK dXN0aW4KLyBTZW50IGZyb20gbXkgcGhvbmUgLwoKLS0tLS0tLS0gT3JpZ2luYWwgbWVzc2FnZSAt LS0tLS0tLQpGcm9tOiBCcmlhbiBDYW1wYmVsbCA8YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20+ IApEYXRlOiAxMS83LzIwMTUgIDc6NTYgQU0gIChHTVQrMDk6MDApIApUbzogSGFubmVzIFRzY2hv ZmVuaWcgPGhhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXQ+IApDYzogb2F1dGhAaWV0Zi5vcmcgClN1 YmplY3Q6IFtPQVVUSC1XR10gYXVkLCBKQVIsIFBvUCBrZXkgZGlzdHJvLCBldGMuICh3YXMgUmU6 ICBJRVRGIDkzIE9BdXRoIFdHIE1lZXRpbmcgTWludXRlcykgCgpUaGF0J3MgcmlnaHQsIHNvcnJ5 LCB0aGVyZSdzIG5vdCBhY3R1YWxseSBhIGNvbmZsaWN0IG5vdyBhcyB0aGUgUG9QIGtleSBkaXN0 cmlidXRpb24gZHJhZnQgY3VycmVudGx5IG9ubHkgdXNlcyB0aGUgJ2F1ZCcgcGFyYW1ldGVyIGF0 IHRoZSB0b2tlbiBlbmRwb2ludC4gCgpJIGp1c3QgYXNzdW1lIGl0IHdpbGwgZW5kIHVwIGJlaW5n IHVzZWQgYXQgdGhlIGF1dGhvcml6YXRpb24gZW5kcG9pbnQgZXZlbnR1YWxseSBiZWNhdXNlIHRo ZSBuZWVkIHRvIGRpc2FtYmlndWF0ZSB3aGVyZSB0aGUgdG9rZW4gd2lsbCBiZSB1c2VkIGlzbid0 IGxpbWl0ZWQgdG8gdGhlIHRva2VuIGVuZHBvaW50ICh3ZSBkbyBoYXZlIHRoaXMgaW1wbGljaXQg dGhpbmcpLiBBcyBKb2huIG1lbnRpb25lZCwgd2UgaGF2ZSB1c2VkIGFuICdhdWQnIHBhcmFtZXRl ciAoaW50ZXJwcmV0ZWQgYXMgYSByZXNvdXJjZSBsb2NhdGlvbikgaW4gb3VyIEFTIG9uIGJvdGgg ZW5kcG9pbnRzIHRvIGFsbG93IHRoZSBjbGllbnQgdG8gaW5kaWNhdGUgd2hlcmUgaXQgaW50ZW5k cyB0byB1c2UgdGhlIHRva2VuIGl0J3MgYXNraW5nIGZvciwgd2hpY2ggZW5hYmxlcyB0aGUgQVMg dG8gYXBwbHkgdW5pcXVlIHBvbGljeSB0byB0aGF0IHRva2VuIGZvciB0aGUgZ2l2ZW4gcmVzb3Vy Y2UgKGl0J3Mgbm90IHRoZSBleGFjdCBzYW1lIHRoaW5nIGFzIFBvUCBrZXkgZGlzdHJpYnV0aW9u IGJ1dCBjb25jZXB0dWFsbHkgc2ltaWxhcikuIFNvIEkgd2FzIGNvbmZ1c2luZyBpbXBsZW1lbnRh dGlvbiBleHBlcmllbmNlIHdpdGggd2hhdCB3YXMgYWN0dWFsbHkgaW4gdGhlIFBvUCBrZXkgZGlz dHJpYnV0aW9uIGRyYWZ0LgoKVGhhdCBzYWlkLCBJIGRvIHRoaW5rIHRoYXQgSkFSIHNob3VsZCBy ZWdpc3RlciBKV1QgY2xhaW1zIHRoYXQgaXQncyBsaWtlbHkgdG8gdXNlIGluIHRoZSBSZXF1ZXN0 IE9iamVjdCBhcyBhdXRob3JpemF0aW9uIGVuZHBvaW50IHBhcmFtZXRlcnMgdG8gYXZvaWQgdGhp cyBraW5kIG9mIGNvbmZsaWN0LiAKCkFuZCBJIHNvbWV0aGluZyBsaWtlIHRoZSAnYXVkJyBwYXJh bWV0ZXIgaXMgbmVlZGVkIGF0IGJvdGggdGhlIHRva2VuIGFuZCBhdXRob3JpemF0aW9uIGVuZHBv aW50cyBzb8KgIFBvUCBrZXkgZGlzdHJpYnV0aW9uIHNob3VsZCB1c2UgYSBkaWZmZXJlbnQgbmFt ZS4gT3IgdGhpcyBwb3RlbnRpYWwgaW5kZXBlbmRlbnQgZHJhZnQsIHdoaWNoIEkgZG8gdGhpbmsg aGFzIHZhbHVlLiBJIHdhcyBwbGFubmluZyBvbiBwcm9wb3Npbmcgc29tZXRoaW5nIHRoYXQncyBi YXNlZCBvbiBzaW1pbGFyIHBhcmFtZXRlcnMgYmVpbmcgd29ya2VkIG9uIGluIHRva2VuIGV4Y2hh bmdlIC0gd2UncmUganVzdCBub3QgdGhlcmUgcXVpdGUgeWV0LsKgCgoKCgpPbiBGcmksIE5vdiA2 LCAyMDE1IGF0IDY6MDMgQU0sIEhhbm5lcyBUc2Nob2ZlbmlnIDxoYW5uZXMudHNjaG9mZW5pZ0Bn bXgubmV0PiB3cm90ZToKCgrCoCDCoCDCoCDCoCBCcmlhbiBhbHNvIHBvaW50ZWQgb3V0IHRoYXQg dGhlcmUgaXMgYSBjb25mbGljdCB3aXRoIHRoZSBQb1Aga2V5CgpkaXN0cmlidXRpb24gZHJhZnQg dGhhdCB1c2VzIHRoZSAnYXVkJyBwYXJhbWV0ZXIuIEpvaG4gbm90ZWQgdGhhdAoKY3VycmVudGx5 IHRoZSAnYXVkJyBwYXJhbWV0ZXIgaXMgdXNlZCB0b3dhcmRzIGEgZGlmZmVyZW50IGVuZHBvaW50 LCB1c2VkCgphcyBhIHF1ZXJ5IHBhcmFtZXRlciwgYnV0IGl0IHdvdWxkIHByb2JhYmx5IGJlIGdv b2QgdG8gdGFrZSB0aGlzIGludG8KCmFjY291bnQgbm93LgoKCgrCoCDCoCDCoCDCoCBKdXN0aW4g bm90ZWQgdGhhdCB0aGVyZSBpcyBnZW5lcmFsIHV0aWxpdHkgdG8gaW5kaWNhdGUgdGhlIGF1ZGll bmNlLgoKVG9kYXkgcGVvcGxlIGFyZSBmb3JjZWQgdG8gdXNlIHRoZSBzY29wZSBmb3IgV0hBVCwg SE9XIGFuZCBIT1cgTE9ORyB0aGUKCmNsaWVudCB3YW50cyB0byBhY2Nlc3MgYSBwcm90ZWN0ZWQg cmVzb3VyY2UuIFRoZSAnYXVkJyBkZXNjcmliZXMgdGhlCgpXSEFUIGFzcGVjdC7CoCBIZSBzdWdn ZXN0ZWQgdG8gdGFrZSBpdCBhIGdlbmVyYWwgdXRpbGl0eSBleHRlbnNpb24gdGhhdAoKaXMgaW5k ZXBkZW50IG9mIHRoZSBQb1AgZG9jdW1lbnQuCgoKCsKgIMKgIMKgIMKgIEhhbm5lcyBhZGRlZCBh IHJlbWFyayB0aGF0IHRoZSAnYXVkJyBwYXJhbWV0ZXIgLyBjbGFpbSB3YXMgYSBzZXBhcmF0ZQoK ZG9jdW1lbnQgYW5kIHRoZW4gd2UgYWRkZWQgaXQgdG8gdGhlIFBvUCBkb2N1bWVudC4KCgoKwqAg wqAgwqAgwqAgSm9obiBzYWlkIHRoYXQgd2UgZGlkbid0IGhhZCB0aGUgd2lkZS1lbm91Z2ggcGlj dHVyZSBhbmQgd2Ugbm93Cgp1bmRlcnN0YW5kIHRoaW5ncyBiZXR0ZXIuCgrCoCAKCg== ----_com.android.email_913150996140290 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keT4KICAgIAo8ZGl2Pkkgd2FzIGNvbnNp ZGVyaW5nIHByZXBhcmluZyBhbiAiZXh0ZW5kZWQgc2NvcGVzIiBjb25jZXB0IGRyYWZ0IHRvIGRl ZmluZSBib3RoIGEgdGFyZ2V0IHBhcmFtZXRlciAod2hhdCB3ZSdyZSB1c2luZyAiYXVkIiBmb3Ip IGFzIHdlbGwgYXMgYSB0ZW1wb3JhbCBwYXJhbWV0ZXIsIHRvIHNpdCBiZXNpZGUgc2NvcGUgd2hp Y2ggaXMgbW9yZSBuYXR1cmFsbHkgYW4gImV4dGVudCBvZiBwZXJtaXNzaW9uIi48L2Rpdj48ZGl2 Pjxicj48L2Rpdj48ZGl2PldlIG5lZWQgdGhlIGF1ZGllbmNlIGJpdCBmb3IgSEVBUlQsIGFuZCBJ IGtub3cgb3RoZXJzIHRoYXQgZG8gYXMgd2VsbC4mbmJzcDs8L2Rpdj48ZGl2Pjxicj48L2Rpdj48 ZGl2PkkgcHJvcG9zZSB3ZSBkZWZpbmUgYW4gZXh0ZW5kZWQgc2NvcGVzIGRvY3VtZW50IGxpa2Ug dGhpcyB0byBjYXB0dXJlIGEgY291cGxlIGNhdGVnb3JpZXMgbGlrZSB0aGF0LiBHb29kIG5ld3Mg aXMgdGhhdCB3ZSBkbyBoYXZlIHNvbWUgaW1wbGVtZW50YXRpb24gZXhwZXJpZW5jZSBmcm9tIGJv dGggcGluZyBhbmQgTWljcm9zb2Z0IG9uIHRoaXMuJm5ic3A7PC9kaXY+PGRpdj48YnI+PC9kaXY+ PGRpdiBpZD0iY29tcG9zZXJfc2lnbmF0dXJlIj48bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5 cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD1VVEYtOCI+PGRpdjwgZGl2PSIiPjxkaXY+ PGRpdj4tLSBKdXN0aW48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2Pi8gU2VudCBmcm9tIG15IHBo b25lIC88L2Rpdj48L2Rpdj48ZGl2PjwvZGl2PjwvZGl2PD48L2Rpdj48YnI+PGJyPi0tLS0tLS0t IE9yaWdpbmFsIG1lc3NhZ2UgLS0tLS0tLS08YnI+RnJvbTogQnJpYW4gQ2FtcGJlbGwgJmx0O2Jj YW1wYmVsbEBwaW5naWRlbnRpdHkuY29tJmd0OyA8YnI+RGF0ZTogMTEvNy8yMDE1ICA3OjU2IEFN ICAoR01UKzA5OjAwKSA8YnI+VG86IEhhbm5lcyBUc2Nob2ZlbmlnICZsdDtoYW5uZXMudHNjaG9m ZW5pZ0BnbXgubmV0Jmd0OyA8YnI+Q2M6IG9hdXRoQGlldGYub3JnIDxicj5TdWJqZWN0OiBbT0FV VEgtV0ddIGF1ZCwgSkFSLCBQb1Aga2V5IGRpc3RybywgZXRjLiAod2FzIFJlOiAgSUVURiA5MyBP QXV0aCBXRyBNZWV0aW5nIE1pbnV0ZXMpIDxicj48YnI+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVu dC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjxkaXYgZGlyPSJsdHIi PjxkaXY+PGRpdj5UaGF0J3MgcmlnaHQsIHNvcnJ5LCB0aGVyZSdzIG5vdCBhY3R1YWxseSBhIGNv bmZsaWN0IG5vdyBhcyB0aGUgUG9QIGtleSBkaXN0cmlidXRpb24gZHJhZnQgY3VycmVudGx5IG9u bHkgdXNlcyB0aGUgJ2F1ZCcgcGFyYW1ldGVyIGF0IHRoZSB0b2tlbiBlbmRwb2ludC4gPGJyPjxi cj48L2Rpdj5JIGp1c3QgYXNzdW1lIGl0IHdpbGwgZW5kIHVwIGJlaW5nIHVzZWQgYXQgdGhlIGF1 dGhvcml6YXRpb24gZW5kcG9pbnQgZXZlbnR1YWxseSBiZWNhdXNlIHRoZSBuZWVkIHRvIGRpc2Ft YmlndWF0ZSB3aGVyZSB0aGUgdG9rZW4gd2lsbCBiZSB1c2VkIGlzbid0IGxpbWl0ZWQgdG8gdGhl IHRva2VuIGVuZHBvaW50ICh3ZSBkbyBoYXZlIHRoaXMgaW1wbGljaXQgdGhpbmcpLiBBcyBKb2hu IG1lbnRpb25lZCwgd2UgaGF2ZSB1c2VkIGFuICdhdWQnIHBhcmFtZXRlciAoaW50ZXJwcmV0ZWQg YXMgYSByZXNvdXJjZSBsb2NhdGlvbikgaW4gb3VyIEFTIG9uIGJvdGggZW5kcG9pbnRzIHRvIGFs bG93IHRoZSBjbGllbnQgdG8gaW5kaWNhdGUgd2hlcmUgaXQgaW50ZW5kcyB0byB1c2UgdGhlIHRv a2VuIGl0J3MgYXNraW5nIGZvciwgd2hpY2ggZW5hYmxlcyB0aGUgQVMgdG8gYXBwbHkgdW5pcXVl IHBvbGljeSB0byB0aGF0IHRva2VuIGZvciB0aGUgZ2l2ZW4gcmVzb3VyY2UgKGl0J3Mgbm90IHRo ZSBleGFjdCBzYW1lIHRoaW5nIGFzIFBvUCBrZXkgZGlzdHJpYnV0aW9uIGJ1dCBjb25jZXB0dWFs bHkgc2ltaWxhcikuIFNvIEkgd2FzIGNvbmZ1c2luZyBpbXBsZW1lbnRhdGlvbiBleHBlcmllbmNl IHdpdGggd2hhdCB3YXMgYWN0dWFsbHkgaW4gdGhlIFBvUCBrZXkgZGlzdHJpYnV0aW9uIGRyYWZ0 Ljxicj48YnI+PC9kaXY+PGRpdj5UaGF0IHNhaWQsIEkgZG8gdGhpbmsgdGhhdCBKQVIgc2hvdWxk IHJlZ2lzdGVyIEpXVCBjbGFpbXMgdGhhdCBpdCdzIGxpa2VseSB0byB1c2UgaW4gdGhlIFJlcXVl c3QgT2JqZWN0IGFzIGF1dGhvcml6YXRpb24gZW5kcG9pbnQgcGFyYW1ldGVycyB0byBhdm9pZCB0 aGlzIGtpbmQgb2YgY29uZmxpY3QuIDxicj48YnI+PC9kaXY+PGRpdj5BbmQgSSBzb21ldGhpbmcg bGlrZSB0aGUgJ2F1ZCcgcGFyYW1ldGVyIGlzIG5lZWRlZCBhdCBib3RoIHRoZSB0b2tlbiBhbmQg YXV0aG9yaXphdGlvbiBlbmRwb2ludHMgc28mbmJzcDsgUG9QIGtleSBkaXN0cmlidXRpb24gc2hv dWxkIHVzZSBhIGRpZmZlcmVudCBuYW1lLiBPciB0aGlzIHBvdGVudGlhbCBpbmRlcGVuZGVudCBk cmFmdCwgd2hpY2ggSSBkbyB0aGluayBoYXMgdmFsdWUuIEkgd2FzIHBsYW5uaW5nIG9uIHByb3Bv c2luZyBzb21ldGhpbmcgdGhhdCdzIGJhc2VkIG9uIHNpbWlsYXIgcGFyYW1ldGVycyBiZWluZyB3 b3JrZWQgb24gaW4gdG9rZW4gZXhjaGFuZ2UgLSB3ZSdyZSBqdXN0IG5vdCB0aGVyZSBxdWl0ZSB5 ZXQuJm5ic3A7PC9kaXY+PGRpdj48YnI+PGJyPjxicj48YnI+PC9kaXY+PGRpdj48ZGl2PjxkaXY+ PGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPjxicj48ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+T24g RnJpLCBOb3YgNiwgMjAxNSBhdCA2OjAzIEFNLCBIYW5uZXMgVHNjaG9mZW5pZyA8c3BhbiBkaXI9 Imx0ciI+Jmx0OzxhIGhyZWY9Im1haWx0bzpoYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0IiB0YXJn ZXQ9Il9ibGFuayI+aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldDwvYT4mZ3Q7PC9zcGFuPiB3cm90 ZTo8YnI+PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjBweCAw cHggMHB4IDAuOGV4O2JvcmRlci1sZWZ0OjFweCBzb2xpZCByZ2IoMjA0LDIwNCwyMDQpO3BhZGRp bmctbGVmdDoxZXgiPjxicj4KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEJyaWFuIGFsc28g cG9pbnRlZCBvdXQgdGhhdCB0aGVyZSBpcyBhIGNvbmZsaWN0IHdpdGggdGhlIFBvUCBrZXk8YnI+ CmRpc3RyaWJ1dGlvbiBkcmFmdCB0aGF0IHVzZXMgdGhlICdhdWQnIHBhcmFtZXRlci4gSm9obiBu b3RlZCB0aGF0PGJyPgpjdXJyZW50bHkgdGhlICdhdWQnIHBhcmFtZXRlciBpcyB1c2VkIHRvd2Fy ZHMgYSBkaWZmZXJlbnQgZW5kcG9pbnQsIHVzZWQ8YnI+CmFzIGEgcXVlcnkgcGFyYW1ldGVyLCBi dXQgaXQgd291bGQgcHJvYmFibHkgYmUgZ29vZCB0byB0YWtlIHRoaXMgaW50bzxicj4KYWNjb3Vu dCBub3cuPGJyPgo8YnI+CiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBKdXN0aW4gbm90ZWQg dGhhdCB0aGVyZSBpcyBnZW5lcmFsIHV0aWxpdHkgdG8gaW5kaWNhdGUgdGhlIGF1ZGllbmNlLjxi cj4KVG9kYXkgcGVvcGxlIGFyZSBmb3JjZWQgdG8gdXNlIHRoZSBzY29wZSBmb3IgV0hBVCwgSE9X IGFuZCBIT1cgTE9ORyB0aGU8YnI+CmNsaWVudCB3YW50cyB0byBhY2Nlc3MgYSBwcm90ZWN0ZWQg cmVzb3VyY2UuIFRoZSAnYXVkJyBkZXNjcmliZXMgdGhlPGJyPgpXSEFUIGFzcGVjdC4mbmJzcDsg SGUgc3VnZ2VzdGVkIHRvIHRha2UgaXQgYSBnZW5lcmFsIHV0aWxpdHkgZXh0ZW5zaW9uIHRoYXQ8 YnI+CmlzIGluZGVwZGVudCBvZiB0aGUgUG9QIGRvY3VtZW50Ljxicj4KPGJyPgombmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgSGFubmVzIGFkZGVkIGEgcmVtYXJrIHRoYXQgdGhlICdhdWQnIHBh cmFtZXRlciAvIGNsYWltIHdhcyBhIHNlcGFyYXRlPGJyPgpkb2N1bWVudCBhbmQgdGhlbiB3ZSBh ZGRlZCBpdCB0byB0aGUgUG9QIGRvY3VtZW50Ljxicj4KPGJyPgombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgSm9obiBzYWlkIHRoYXQgd2UgZGlkbid0IGhhZCB0aGUgd2lkZS1lbm91Z2ggcGlj dHVyZSBhbmQgd2Ugbm93PGJyPgp1bmRlcnN0YW5kIHRoaW5ncyBiZXR0ZXIuPGJyPgombmJzcDsg PGJyPjwvYmxvY2txdW90ZT48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj4KPC9i b2R5PjwvaHRtbD4= ----_com.android.email_913150996140290-- From nobody Sat Nov 7 08:29:12 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07C571A914A for ; Sat, 7 Nov 2015 08:29:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.384 X-Spam-Level: ** X-Spam-Status: No, score=2.384 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_12_24=1.049, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_SBL_CSS=3.335, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k7vNm0zeZk2H for ; Sat, 7 Nov 2015 08:29:10 -0800 (PST) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 416661A9145 for ; Sat, 7 Nov 2015 08:29:10 -0800 (PST) Received: by wmec201 with SMTP id c201so39832155wme.1 for ; Sat, 07 Nov 2015 08:29:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:subject:message-id:from:to:mime-version:content-type :content-transfer-encoding; bh=nkoutSXNTtKnxFl4tEkO8LOgYqvKArjaT/8uEPx41wc=; b=eEb/Y4tjylWWiVJ9QgyGARU30mqTGkD7vcb45b5AwY7lK/YYA8or2llBmi9m09KPsT WIcX1QK4PRdIYdybQhR+afX0BKrYLjs15yU8Fs4KOBz8FwVvt68TQ112jFtqM0jYgZqE 6Az6I5Q/2cApDJcJ+1MA/FKzsKSlFEaEmFBEHOQCIALePmIi6a4CAHWKOBBgvH43IHMt b1ILGdWTtstAkYvoOj8JPn778KH9xibtJXhYh9LgW3KqRGrYtWjmVSx8VgER57942Wv7 1oI0EhSvMPKEb1AI+TwLxiQ0F1cSddUFi3eW+9repu4cDFGreYuEa7b+NWhSJp0Tbvy2 DCJQ== X-Received: by 10.28.131.84 with SMTP id f81mr15752127wmd.57.1446913748824; Sat, 07 Nov 2015 08:29:08 -0800 (PST) Received: from [10.106.188.148] (41-66-208-4-dedicated.4u.com.gh. [41.66.208.4]) by smtp.gmail.com with ESMTPSA id he3sm5758721wjc.48.2015.11.07.08.29.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 07 Nov 2015 08:29:07 -0800 (PST) Date: Sat, 07 Nov 2015 09:44:21 +0700 Message-ID: From: brightbestb To: oauth@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [OAUTH-WG] OAuth Digest, Vol 84, Issue 1 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Nov 2015 16:29:12 -0000 Cgogb2F1dGgtcmVxdWVzdEBpZXRmLm9yZyB3cm90ZToKCj5TZW5kIE9BdXRoIG1haWxpbmcgbGlz dCBzdWJtaXNzaW9ucyB0bwo+CW9hdXRoQGlldGYub3JnCj4KPlRvIHN1YnNjcmliZSBvciB1bnN1 YnNjcmliZSB2aWEgdGhlIFdvcmxkIFdpZGUgV2ViLCB2aXNpdAo+CWh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgKPm9yLCB2aWEgZW1haWwsIHNlbmQgYSBtZXNzYWdl IHdpdGggc3ViamVjdCBvciBib2R5ICdoZWxwJyB0bwo+CW9hdXRoLXJlcXVlc3RAaWV0Zi5vcmcK Pgo+WW91IGNhbiByZWFjaCB0aGUgcGVyc29uIG1hbmFnaW5nIHRoZSBsaXN0IGF0Cj4Jb2F1dGgt b3duZXJAaWV0Zi5vcmcKPgo+V2hlbiByZXBseWluZywgcGxlYXNlIGVkaXQgeW91ciBTdWJqZWN0 IGxpbmUgc28gaXQgaXMgbW9yZSBzcGVjaWZpYwo+dGhhbiAiUmU6IENvbnRlbnRzIG9mIE9BdXRo IGRpZ2VzdC4uLiIKPgo+Cj5Ub2RheSdzIFRvcGljczoKPgo+ICAgMS4gUmU6IFBvUCBkb2N1bWVu dDogSVBSIENvbmZpcm1hdGlvbiAoSGFubmVzIFRzY2hvZmVuaWcpCj4KPgo+LS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQo+Cj5NZXNzYWdlOiAxCj5EYXRlOiBUaHUsIDEgT2N0IDIwMTUgMDk6MjQ6MjkgKzAyMDAKPkZy b206IEhhbm5lcyBUc2Nob2ZlbmlnIDxoYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0Pgo+VG86IEtl cGVuZyBMaSA8a2VwZW5nLmxrcEBhbGliYWJhLWluYy5jb20+LCBtYmpAbWljcm9zb2Z0LmNvbSwK Pgl2ZTdqdGJAdmU3anRiLmNvbQo+Q2M6IG9hdXRoQGlldGYub3JnCj5TdWJqZWN0OiBSZTogW09B VVRILVdHXSBQb1AgZG9jdW1lbnQ6IElQUiBDb25maXJtYXRpb24KPk1lc3NhZ2UtSUQ6IDw1NjBD REZBRC4zMDQwNDAwQGdteC5uZXQ+Cj5Db250ZW50LVR5cGU6IHRleHQvcGxhaW47IGNoYXJzZXQ9 IndpbmRvd3MtMTI1MiIKPgo+SSBhbSBub3QgYXdhcmUgb2YgYW55IElQUnMgb24gdGhlICdQcm9v Zi1vZi1Qb3NzZXNzaW9uIEtleSBTZW1hbnRpY3MgZm9yCj5KU09OIFdlYiBUb2tlbnMgKEpXVHMp JyBzcGVjaWZpY2F0aW9uCj4oZHJhZnQtaWV0Zi1vYXV0aC1wcm9vZi1vZi1wb3NzZXNzaW9uLTA0 KS4KPgo+Q2lhbwo+SGFubmVzCj4KPgo+T24gMDkvMzAvMjAxNSAxMjowMyBQTSwgS2VwZW5nIExp IHdyb3RlOgo+PiBIaSBNaWtlLCBKb2huIGFuZCBIYW5uZXMsCj4+IAo+PiBJIGFtIHdvcmtpbmcg b24gdGhlIHNoZXBoZXJkIHdyaXRldXAgZm9yIHRoZSBQb1AgZG9jdW1lbnQ6Cj4+IAo+PiBodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLXByb29mLW9mLXBvc3Nlc3Np b24tMDQKPj4gPGh0dHBzOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LWlldGYtb2F1dGgtcG9wLWFy Y2hpdGVjdHVyZS0wMi50eHQ+Cj4+IAo+PiBPbmUgaXRlbSBpbiB0aGUgdGVtcGxhdGUgcmVxdWly ZXMgbWUgdG8gaW5kaWNhdGUgd2hldGhlciBlYWNoIGRvY3VtZW50Cj4+IGF1dGhvciBoYXMgY29u ZmlybWVkIHRoYXQgYW55IGFuZCBhbGwgYXBwcm9wcmlhdGUgSVBSIGRpc2Nsb3N1cmVzCj4+IHJl cXVpcmVkIGZvciBmdWxsIGNvbmZvcm1hbmNlIHdpdGggdGhlIHByb3Zpc2lvbnMgb2YgQkNQIDc4 IGFuZCBCQ1AgNzkKPj4gaGF2ZSBhbHJlYWR5IGJlZW4gZmlsZWQuIENvdWxkIHlvdSBwbGVhc2Ug Y29uZmlybT8gS2luZCBSZWdhcmRzCj4+IAo+PiBLZXBlbmcKPj4gCj4+IAo+Cj4tLS0tLS0tLS0t LS0tLSBuZXh0IHBhcnQgLS0tLS0tLS0tLS0tLS0KPkEgbm9uLXRleHQgYXR0YWNobWVudCB3YXMg c2NydWJiZWQuLi4KPk5hbWU6IHNpZ25hdHVyZS5hc2MKPlR5cGU6IGFwcGxpY2F0aW9uL3BncC1z aWduYXR1cmUKPlNpemU6IDUzMCBieXRlcwo+RGVzYzogT3BlblBHUCBkaWdpdGFsIHNpZ25hdHVy ZQo+VVJMOiA8aHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL2Jyb3dzZS9vYXV0aC9h dHRhY2htZW50cy8yMDE1MTAwMS9jNjk4ZDlkNC9hdHRhY2htZW50LmFzYz4KPgo+LS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tCj4KPlN1YmplY3Q6IERpZ2VzdCBGb290ZXIKPgo+X19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPk9BdXRoIG1haWxpbmcg bGlzdAo+T0F1dGhAaWV0Zi5vcmcKPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vb2F1dGgKPgo+Cj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KPgo+RW5kIG9mIE9B dXRoIERpZ2VzdCwgVm9sIDg0LCBJc3N1ZSAxCj4qKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioK From nobody Sat Nov 7 10:13:29 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A52F81ACE20 for ; Sat, 7 Nov 2015 10:13:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e0lKSK_uZYZK for ; Sat, 7 Nov 2015 10:13:25 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34DA31ACE1E for ; Sat, 7 Nov 2015 10:13:25 -0800 (PST) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id tA7IDM0f006832 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 7 Nov 2015 18:13:23 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id tA7IDMke008027 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 7 Nov 2015 18:13:22 GMT Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id tA7IDMXl007951; Sat, 7 Nov 2015 18:13:22 GMT Received: from [10.0.1.3] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 07 Nov 2015 10:13:22 -0800 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Phil Hunt X-Mailer: iPhone Mail (13B143) In-Reply-To: <563CA507.1030500@gmx.net> Date: Sat, 7 Nov 2015 10:13:20 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <8A6BBB1B-DCC4-4EBB-BABC-000452C4D74C@oracle.com> References: <563CA507.1030500@gmx.net> To: Hannes Tschofenig X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] IETF 93 OAuth WG Meeting Minutes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Nov 2015 18:13:27 -0000 Correction regarding the API Protection new charter item.=20 There is the Thomas Hardjono IETF draft (referenced in my pres) from earlier= this year which could be used to work on. Justin was indicating the UMA dra= ft may be more recent.=20 Phil > On Nov 6, 2015, at 05:03, Hannes Tschofenig wr= ote: >=20 > Here are the meeting minutes from the f2f. Please drop us a message if > there is something missing or incorrect. >=20 > --------- >=20 > IETF 93 OAuth WG Meeting Minutes >=20 > Room 301 > Time: 15:20-17:20 > Date: Thursday, November 5, 2015 (JST) > Chairs: Hannes Tschofenig + Derek Atkins (absent) > Minute Taker: Kepeng Li (and revised by Hannes Tschofenig) >=20 > 1) Status Update (Hannes) >=20 > - PoP >=20 > Shepherd write-ups by Kepeng regarding PoP architecture and PoP Key > Semantics. > Both were sent to the IESG already. >=20 > - Charter Update >=20 > Hannes to submit an updated charter based on the outcome of the > discussions during this meeting. >=20 > 2) OAuth 2.0 JWT Authorization Request (Nat) > http://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/ >=20 > Nat goes through the issues raised during the WGLC reviews from > Brian and Hannes. >=20 > It was noted that the document could offer more background > information about why a new serialization mechanism is offered. John > mentioned that it could be noted that the request object travels through > the browser and can therefore be modified. >=20 > Brian raised a question whether the request object is only encrypted. > This lead to a discussion of the difference between encryption and > integrity protection (using symmetric and asymmetric cryptography). The > conclusion was reached that the security consideration section needs to > be updated to explain what properties the different methods for using > JWS/JWE provide. >=20 > Nat was also asked to provide additional text regarding replay attacks > since third party signing does not allow the sender of the request > object to compute a digital signature or a MAC (since > Section 5.2 should make normative reference to OpenID Connect. >=20 > Brian also pointed out that there is a conflict with the PoP key > distribution draft that uses the 'aud' parameter. John noted that > currently the 'aud' parameter is used towards a different endpoint, used > as a query parameter, but it would probably be good to take this into > account now. >=20 > Justin noted that there is general utility to indicate the audience. > Today people are forced to use the scope for WHAT, HOW and HOW LONG the > client wants to access a protected resource. The 'aud' describes the > WHAT aspect. He suggested to take it a general utility extension that > is indepdent of the PoP document. >=20 > Hannes added a remark that the 'aud' parameter / claim was a separate > document and then we added it to the PoP document. >=20 > John said that we didn't had the wide-enough picture and we now > understand things better. >=20 > Section 5.2: Discussion about where to register parameters -- in the > IETF document or in the OIDC spec. >=20 > Section 4.2.1 defines the precedence rules. It was unclear whether this > is OIDC specific or whether this is OAuth related. >=20 > Nat will make a update within two weeks. >=20 > Kepeng and Mike volunteered to review the draft. >=20 > 3) Proof-of-Possession Key Distribution (John) > http://datatracker.ietf.org/doc/draft-ietf-oauth-pop-key-distribution/ >=20 > John starts his presentation and focuses on the description of the > threat against refresh tokens where a client is unable to secure access > and refresh tokens. There have been some real-world attacks against > websites that did not protect their token store properly. Of course, > there is the assumption that some hardware security can be used to > secure some credentials. In the initial draft we did not allow the > client to change the key bound to the access tokens. A number of people > want to rotate the key when they request a new access token. When we > want to do that securely we need to offer PoP version of the refresh > token. If an adversary gets hold >=20 > The proposed resolution is the following: > (a) For confidential clients the client ID/client secret is enough as > a PoP feature for the refresh token. > (b) For public clients we make use of PKCE as the PoP feature. It > might also be a good time to extend PKCE to support an asymmetric version.= >=20 > Need to incorporate comments from Tony in the mailing list where he > argued that we need to support TPCs. He wants to use a wrapped key since > the draft is not friendly towards client creating symmetric keys > locally. Tony also raises the desire to allow attestation information to > be conveyed from the client to the authorization server. >=20 > Hannes argues that we shouldn't not make the document TPM specific > but rather to be open for other hardware security solutions. >=20 > Justin argues that we need very clear rules for precedence order. > Discussion about how these rules could look like and how much complexity > it introduces. >=20 > 4) HTTP Signing (Justin) >=20 > Justin goes through his slide deck where he explains the current > status with the HTTP signing concept. > In his presentation he also raises open issues, such as repeated > headers. >=20 > Need implementations and inputs to the designs. Hannes points out > that recently two groups in Sweden (Roland Hedberg, Fredrik Ljunggren, > and Jakob Schlyter) offered help with the document and will work on > implementations. >=20 > Nat believes that this document has some relationship with sender > constraint draft. >=20 > 5) Token Exchange (Mike) > http://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/ >=20 > At the Prague IETF meeting we had a good discussion about the open > issues. The draft editors have been working on proposed resolutions. >=20 > A new document is expected to be published soon. Brian and Mike will > post to the list on how the issues have been addressed. >=20 > 7) Rechartering >=20 > (a) OAuth 2.0 for Native Apps (William) > http://datatracker.ietf.org/doc/draft-wdenniss-oauth-native-apps/ >=20 > With this work Williams described how to securely use OAuth with > native apps by utilizing new mobile operating system concepts so that > the client application is not able to get access to the user provided > credentials. >=20 > The concept also allows the re-use of the SSO mechanism for apps > developed in the OpenID Foundation to be used. Furthermore it will make > the use of FIDO for apps easier since FIDO support in the OS can be > utilized rather than requiring app developers to develop authentication > functionality into their apps. The finalization of PKSE also helps > securing native apps. >=20 > Sandeep asked how to differentiate from a webview and a phishing app > internal browsers. William argues that the best possible way is to see > the login dialog in the first place. There is also an icon to return to > the app that created the view. >=20 > Tony argues that there are some patterns described in the draft do > not exist any more, such as the authentication to the IdP. >=20 > Erik argues that it solves a lot of issues in the enterprise use case > but the UI aspect has to be looked at. >=20 > Poll: 16 persons for doing the work / 0 persons against / 2 persons > need more info >=20 > (b) Security Extensions & Fixes (John) >=20 > John argues that the new charter needs to include work like the > asymmetric PKCE extension, token binding for refresh tokens; redirection > best practices, and post message response mode to replace fragment. >=20 > Kepeng subsequently brielfy explains the sender constraint. Hannes > notes that this is based on existing implementation. >=20 > Poll: 17 for/0 against/0 need more info >=20 > (c) API Management (Phil) >=20 > Phil explains the concept of API management where a resource server > registers configuration data about the protected resources to the > authorization server. This is functionality introduced by UMA as > resource set registration. Justin and Phil argue that there are > requirements beyond what has been developed within UMA. > The relevant UMA document can be found here: > https://docs.kantarainitiative.org/uma/draft-oauth-resource-reg.html >=20 > Since there is currently no draft available discussions start about > the exact content. >=20 > Poll: 6 for / zero against / 9 persons need more information. >=20 > (d) JWT Claims (Mike) >=20 > Mike gives an example of the need to define new JWT claims based on > draft-jones-oauth-amr-values draft. >=20 > Poll: 9 for / zero against / 6 persons need more information. >=20 > (e) Device Flow (William) >=20 > William goes through his short presentation and explains the device > flow that was part of the OAuth 2.0 specification but then got moved > into a separate draft. The document later expired but has been > implemented by various companies, including Facebook and Google. >=20 > Poll: 16 for / zero against / 2 persons need more information. >=20 > (f) Discovery (Nat) >=20 > Nat explains his document as an example of the work that has to be > done in the area of discovery, which is a topic that has been identified > as necessary for interoperability since many years but so far there was > not time to work on it. Mike, John and Nat are working on a new document > that describes additional discovery-relevant components. >=20 > Poll: 19 for / zero against / 4 persons need more information. >=20 > Hannes will post an charter proposal. >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Tue Nov 10 00:54:59 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C0181A8980 for ; Tue, 10 Nov 2015 00:54:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BDnG5TFE-kRg for ; Tue, 10 Nov 2015 00:54:57 -0800 (PST) Received: from p3plsmtpa12-02.prod.phx3.secureserver.net (p3plsmtpa12-02.prod.phx3.secureserver.net [68.178.252.231]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3487B1A8925 for ; Tue, 10 Nov 2015 00:54:56 -0800 (PST) Received: from [192.168.0.106] ([77.77.164.50]) by p3plsmtpa12-02.prod.phx3.secureserver.net with id fkuv1r00115ZTut01kuvZp; Tue, 10 Nov 2015 01:54:56 -0700 To: "oauth@ietf.org" From: Vladimir Dzhuvinov X-Enigmail-Draft-Status: N1110 Organization: Connect2id Ltd. Message-ID: <5641B0DE.3050501@connect2id.com> Date: Tue, 10 Nov 2015 10:54:54 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms010905030702090103040900" Archived-At: Subject: [OAUTH-WG] Registered token_endpoint_auth_method with bearer assertion grant X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2015 08:54:58 -0000 This is a cryptographically signed message in MIME format. --------------ms010905030702090103040900 Content-Type: multipart/alternative; boundary="------------050204060208060804010702" This is a multi-part message in MIME format. --------------050204060208060804010702 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, I've got a query regarding a use case: 1. Client with self-issued JWT bearer assertion grant 2. No explicit client auth, i.e. authentication is done via the presented JWT grant What value should then the *token_endpoint_auth_method* reg parameter for the client have? "none" is apparently reserved for public clients: http://tools.ietf.org/html/rfc7591#section-2 Empty value perhaps? Thanks, Vladimir --------------050204060208060804010702 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi,

I've got a query regarding a use case:

1. Client with self-issued JWT bearer assertion grant
2. No explicit client auth, i.e. authentication is done via the presented JWT grant

What value should then the token_endpoint_auth_method reg parameter for the client have?

"none" is apparently reserved for public clients: http://tools.ietf.org/html/rfc7591#section-2

Empty value perhaps?

Thanks,

Vladimir
--------------050204060208060804010702-- --------------ms010905030702090103040900 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfwwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggVFMIIELaADAgECAhAJWTI81U+XNs3vMVNsyOgrMA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTUwMzEyMDAwMDAwWhcNMTYwMzExMjM1OTU5WjAoMSYwJAYJKoZIhvcNAQkB Fhd2bGFkaW1pckBjb25uZWN0MmlkLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAKOyFE/JGyJPkJxnDLNMCit/gIMcHHimJ4QTbV7YNMReIh7/ccO9FQNwmmF4GCq347yB /eYy+9FXLh21Zp61RO3fSnCnEVmwNL5TwCF63iCSDLDEtXnx7AznLTV6MlheEljNtA7Cegos IM/XWE5NrzuO2vmHnj7C59uoGv4FTmcgVCDBJQ23Sdsju0zyNuAETqDyDw6yVwAfRlq+klRg G/ZZFn1D1iDRHyehgkwIoqc1cDbMPEcgkrS3ulWZhh8fGz/EQNo0JzUlwWe25DGpcSRrf47W yMHrVcP5HEQWFxEfGwQmZuNdYb/fzhnYThqGP0AjY2VMicAyOdttbbhutCsCAwEAAaOCAfUw ggHxMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBTiAjTIj8gY Zm3ThRvtNvKtyZoWRjAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0w OwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5u ZXQvQ1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9E T1NIQTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsG AQUFBwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01P RE9TSEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsG AQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wIgYDVR0RBBswGYEXdmxhZGltaXJA Y29ubmVjdDJpZC5jb20wDQYJKoZIhvcNAQELBQADggEBAC2rpYhJKODFdxGV5tBkuFuqW5/6 cnQ30GrREyk8/cLCWKhyvrMsnPnpK1ItafcQr4QPbR1hQcw0w7wzWBAl7FMjhpEVZIv286hM j+BStZPW4LTRiAHPo0Z7oEGvXPGuUuG2e6k0vAV65x7XN4S/wBYKQYg6hRatjK9Lhrlqr9K+ +Rg48LvWFdNbZ5F6VlQSHVBjX7bgQ86uUz0hRawCicJuTxE3J5fVWdfy2MULS5joW6js7V1J Hy86a/qyMZwqscXKPdv1W+UKAePtdGqKJbsZ6TFniBweSqa2pw7traBZ/ko65W2LEPi4tAhS KA7LaumILDPe82VqFHkHX4zuYC8xggRBMIIEPQIBATCBsDCBmzELMAkGA1UEBhMCR0IxGzAZ BgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRo ZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAJWTI81U+XNs3vMVNsyOgrMA0GCWCG SAFlAwQCAQUAoIICYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNTExMTAwODU0NTRaMC8GCSqGSIb3DQEJBDEiBCDXCDuLEt5IsmZ/9Xu4GjbzPZBgEP9J duzFLof5qVEgCDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIw CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G CCqGSIb3DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQCVkyPNVPlzbN7zFTbMjoKzCBwwYLKoZI hvcNAQkQAgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEw PwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3Vy ZSBFbWFpbCBDQQIQCVkyPNVPlzbN7zFTbMjoKzANBgkqhkiG9w0BAQEFAASCAQCKRjzfEuXL avI7H0s2b57NZNnQ7j+7dmIMSqLv00P/LHvICK5b61ebF3Urf3Wy1/C9lYCdElzI2lQGx/yB h4ZKUvyvtE2L0alFkxOgr49yOfzlfpXM4xSMV2aszpFuR4uDngQNHn/t1zs3iVNpkegWtey2 i0UapK+uNkez/aGaJEQGRjBTtmgApnGr513QTwooRYwovfPutrnPAXAm7DDRKg8o1tATyCv8 7B4ZUnZRZUkOgCw8FiGnR+iypwPBHMzAJpeDqtYoLmV/w5zjUfHu+0YR9CQbSQtKHUzc7W8e EW97wPNedhJ81uNOkLetWzYpptyEJ6s7HLhSlx8HslswAAAAAAAA --------------ms010905030702090103040900-- From nobody Tue Nov 10 05:10:41 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82EEA1A911F for ; Tue, 10 Nov 2015 05:10:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vz8sVF08seF2 for ; Tue, 10 Nov 2015 05:10:30 -0800 (PST) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 102E41ACDE0 for ; Tue, 10 Nov 2015 05:10:30 -0800 (PST) Received: by igl9 with SMTP id 9so52839797igl.0 for ; Tue, 10 Nov 2015 05:10:29 -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:content-type; bh=/cTWG+9SQ06gsrU7e88oyk8fbY0lL8C9qEnyzrO/nUg=; b=mKhD2RN0TU7/XumJts1jPAkf5CKqJZUwhU0wFA6O8SGEJyPOCmYET3EbtRxdeeDRBF SBqZgCl3vJ9r2FqAyKuPq0XuYs9WHigwb7nBqFwwDhL24ED00mmcxLVUOSVgYksjcngQ pFXPSmAuYDHOpxrWtdCHribewbodsR68s6WIw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=/cTWG+9SQ06gsrU7e88oyk8fbY0lL8C9qEnyzrO/nUg=; b=RQsQDrW3G6rePHBkC02P2LKzwbYnx++gqfVwjm8r5Ji9H8GGZR93BmQ2qZSm9zT0DJ nbHDPgNc1Td9EsTK3x7jCvvJQU9yDPzJvkTcnNPOuCn3SSlDJfynkoT7LNe/DjvhZ8o7 YfUgJhKEolsw/1tc3gJEkG9lf1KONSVLLHmBuTbkaZMImR1FfV6uJmEB4wnWiP/DiUMz mb4df+4ZP6RydMmVhIIqLGMntHmIyd00bip8jjkHL0nokOUxspgu9l28Kb5UHmGkirLl MsoTuHyL7PrJAdu7OWJAk+E9ZwUHfclDgKCewfpAg4DdZuSJT2fPTKZhIcxQlDza2agQ id7w== X-Gm-Message-State: ALoCoQkxOgb08mlK7sEexk1NdKaA/I8Xsmf5CtLXxCNxgneloGdHfPVNss0bCbK7swEVwcOoqByr X-Received: by 10.50.79.231 with SMTP id m7mr3673512igx.57.1447161029286; Tue, 10 Nov 2015 05:10:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.117.132 with HTTP; Tue, 10 Nov 2015 05:09:59 -0800 (PST) In-Reply-To: <5641B0DE.3050501@connect2id.com> References: <5641B0DE.3050501@connect2id.com> From: Brian Campbell Date: Tue, 10 Nov 2015 06:09:59 -0700 Message-ID: To: Vladimir Dzhuvinov Content-Type: multipart/alternative; boundary=089e013a06bc15a14105242f6f9b Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Registered token_endpoint_auth_method with bearer assertion grant X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2015 13:10:32 -0000 --089e013a06bc15a14105242f6f9b Content-Type: text/plain; charset=UTF-8 Despite the text in RFC 7591, IMHO "none" is still what you'd use here - "none" describes what will be used for explicit client authentication. And that's what the AS needs to know. On Tue, Nov 10, 2015 at 1:54 AM, Vladimir Dzhuvinov wrote: > Hi, > > I've got a query regarding a use case: > > 1. Client with self-issued JWT bearer assertion grant > 2. No explicit client auth, i.e. authentication is done via the presented > JWT grant > > What value should then the *token_endpoint_auth_method* reg parameter for > the client have? > > "none" is apparently reserved for public clients: > http://tools.ietf.org/html/rfc7591#section-2 > > Empty value perhaps? > > Thanks, > > Vladimir > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --089e013a06bc15a14105242f6f9b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Despite the text in RFC 7591, IMHO "none" is sti= ll what you'd use here - "none" describes what will be used f= or explicit client authentication. And that's what the AS needs to know= . =C2=A0

On Tue, Nov 10, 2015 at 1:54 AM, Vladimir Dzhuvinov <= ;vladimir@conn= ect2id.com> wrote:
=20 =20 =20
Hi,

I've got a query regarding a use case:

1. Client with self-issued JWT bearer assertion grant
2. No explicit client auth, i.e. authentication is done via the presented JWT grant

What value should then the token_endpoint_auth_method reg parameter for the client have?

"none" is apparently reserved for public clients: http://tools.ietf.org/html/rfc7591#section-2

Empty value perhaps?

Thanks,

Vladimir

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


--089e013a06bc15a14105242f6f9b-- From nobody Tue Nov 10 22:58:40 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B288F1B3144 for ; Tue, 10 Nov 2015 22:58:39 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UGXnYApGGKeb for ; Tue, 10 Nov 2015 22:58:38 -0800 (PST) Received: from p3plsmtpa12-10.prod.phx3.secureserver.net (p3plsmtpa12-10.prod.phx3.secureserver.net [68.178.252.239]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40A661B313E for ; Tue, 10 Nov 2015 22:58:38 -0800 (PST) Received: from [192.168.0.106] ([77.77.164.50]) by p3plsmtpa12-10.prod.phx3.secureserver.net with id g6yb1r00P15ZTut016ycCj; Tue, 10 Nov 2015 23:58:37 -0700 To: Brian Campbell References: <5641B0DE.3050501@connect2id.com> From: Vladimir Dzhuvinov Organization: Connect2id Ltd. Message-ID: <5642E71B.5080205@connect2id.com> Date: Wed, 11 Nov 2015 08:58:35 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000007080801040306010109" Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Registered token_endpoint_auth_method with bearer assertion grant X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2015 06:58:39 -0000 This is a cryptographically signed message in MIME format. --------------ms000007080801040306010109 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thanks Brian. We'll put a note in the SDK so developers are aware of this= =2E On 10.11.2015 15:09, Brian Campbell wrote: > Despite the text in RFC 7591, IMHO "none" is still what you'd use here = - > "none" describes what will be used for explicit client authentication. = And > that's what the AS needs to know. > > On Tue, Nov 10, 2015 at 1:54 AM, Vladimir Dzhuvinov > wrote: >> Hi, >> >> I've got a query regarding a use case: >> >> 1. Client with self-issued JWT bearer assertion grant >> 2. No explicit client auth, i.e. authentication is done via the presen= ted >> JWT grant >> >> What value should then the *token_endpoint_auth_method* reg parameter = for >> the client have? >> >> "none" is apparently reserved for public clients: >> http://tools.ietf.org/html/rfc7591#section-2 >> >> Empty value perhaps? >> >> Thanks, >> >> Vladimir >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> --=20 Vladimir Dzhuvinov :: vladimir@connect2id.com --------------ms000007080801040306010109 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfwwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggVFMIIELaADAgECAhAJWTI81U+XNs3vMVNsyOgrMA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTUwMzEyMDAwMDAwWhcNMTYwMzExMjM1OTU5WjAoMSYwJAYJKoZIhvcNAQkB Fhd2bGFkaW1pckBjb25uZWN0MmlkLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAKOyFE/JGyJPkJxnDLNMCit/gIMcHHimJ4QTbV7YNMReIh7/ccO9FQNwmmF4GCq347yB /eYy+9FXLh21Zp61RO3fSnCnEVmwNL5TwCF63iCSDLDEtXnx7AznLTV6MlheEljNtA7Cegos IM/XWE5NrzuO2vmHnj7C59uoGv4FTmcgVCDBJQ23Sdsju0zyNuAETqDyDw6yVwAfRlq+klRg G/ZZFn1D1iDRHyehgkwIoqc1cDbMPEcgkrS3ulWZhh8fGz/EQNo0JzUlwWe25DGpcSRrf47W yMHrVcP5HEQWFxEfGwQmZuNdYb/fzhnYThqGP0AjY2VMicAyOdttbbhutCsCAwEAAaOCAfUw ggHxMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBTiAjTIj8gY Zm3ThRvtNvKtyZoWRjAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0w OwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5u ZXQvQ1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9E T1NIQTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsG AQUFBwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01P RE9TSEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsG AQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wIgYDVR0RBBswGYEXdmxhZGltaXJA Y29ubmVjdDJpZC5jb20wDQYJKoZIhvcNAQELBQADggEBAC2rpYhJKODFdxGV5tBkuFuqW5/6 cnQ30GrREyk8/cLCWKhyvrMsnPnpK1ItafcQr4QPbR1hQcw0w7wzWBAl7FMjhpEVZIv286hM j+BStZPW4LTRiAHPo0Z7oEGvXPGuUuG2e6k0vAV65x7XN4S/wBYKQYg6hRatjK9Lhrlqr9K+ +Rg48LvWFdNbZ5F6VlQSHVBjX7bgQ86uUz0hRawCicJuTxE3J5fVWdfy2MULS5joW6js7V1J Hy86a/qyMZwqscXKPdv1W+UKAePtdGqKJbsZ6TFniBweSqa2pw7traBZ/ko65W2LEPi4tAhS KA7LaumILDPe82VqFHkHX4zuYC8xggRBMIIEPQIBATCBsDCBmzELMAkGA1UEBhMCR0IxGzAZ BgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRo ZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAJWTI81U+XNs3vMVNsyOgrMA0GCWCG SAFlAwQCAQUAoIICYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNTExMTEwNjU4MzVaMC8GCSqGSIb3DQEJBDEiBCB6eKV2p1fHeMo11dDkk86HJnrwQd9z PmqF3q6YL/AkxDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIw CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G CCqGSIb3DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQCVkyPNVPlzbN7zFTbMjoKzCBwwYLKoZI hvcNAQkQAgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEw PwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3Vy ZSBFbWFpbCBDQQIQCVkyPNVPlzbN7zFTbMjoKzANBgkqhkiG9w0BAQEFAASCAQCbVcXjkMId ZP/+9i0+pxEjycvhPFu/ZdzbJJzEuuuMtziLfQzMqcuseaeWeg4GBSveSbYSebEkR21D2Hma Qgx46/jA2u8WEl0GqTG0efOAVCX/HChkXfmeaqiZyvbc2FqNhiTQUzwXNVon595JQIZu9qS6 jmx6LoW3imF7QrXHNhkc1rXtrAbOybHbPyrt/R9ipGPeaJfaNFswcyHpr+gVnNCRKMCSDrWI +Agt6wBWtoZh8wBmAYlGq08S7JrVvitjya2Ztt2/JW8mAxP5+eb0mVebyRAYBytW+RciErhu FH+NpCaU+i27vIXmPwwtFmCFNFhYDrumrYZqlyO1hZckAAAAAAAA --------------ms000007080801040306010109-- From nobody Thu Nov 12 11:26:27 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5C971B3228 for ; Thu, 12 Nov 2015 11:26:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.31 X-Spam-Level: X-Spam-Status: No, score=-2.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o-EoNFyMSkYR for ; Thu, 12 Nov 2015 11:26:23 -0800 (PST) Received: from smtp.nexusgroup.com (smtp.nexusgroup.com [83.241.133.120]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DCCE1B3229 for ; Thu, 12 Nov 2015 11:26:20 -0800 (PST) Received: from NG-EX01.ad.nexusgroup.com (10.75.28.40) by NG-EX01.ad.nexusgroup.com (10.75.28.40) with Microsoft SMTP Server (TLS) id 15.0.995.29; Thu, 12 Nov 2015 20:26:17 +0100 Received: from NG-EX01.ad.nexusgroup.com ([fe80::1d3d:b319:f020:2bab]) by NG-EX01.ad.nexusgroup.com ([fe80::1d3d:b319:f020:2bab%12]) with mapi id 15.00.0995.032; Thu, 12 Nov 2015 20:26:17 +0100 From: =?utf-8?B?RXJpayBXYWhsc3Ryw7ZtIG5lWHVz?= To: "" Thread-Topic: A draft on CBOR Web Tokens (CWT) Thread-Index: AQHRHX3EcFviJsoC2k6K5CeJemK0Aw== Date: Thu, 12 Nov 2015 19:26:17 +0000 Message-ID: References: <53BB1987-979C-4945-9C7D-CDB6619AEFFC@nexusgroup.com> Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.2104) x-originating-ip: [37.247.26.197] Content-Type: text/plain; charset="utf-8" Content-ID: <1F86ECED8E58D84E981C5ECAD8D770DB@nexusgroup.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [OAUTH-WG] A draft on CBOR Web Tokens (CWT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2015 19:26:25 -0000 SGksDQoNCkluIHRoZSBBQ0UgV0cgYSBzdHJhdyBtYW4gcHJvcG9zYWwgb2YgYSBDQk9SIFdlYiBU b2tlbiAoQ1dUKSB3YXMgZGVmaW5lZCBpbiB0aGUgZHJhZnQgIkF1dGhvcml6YXRpb24gZm9yIHRo ZSBJbnRlcm5ldCBvZiBUaGluZ3MgdXNpbmcgT0F1dGggMi4w4oCdIFsxXS4gV2UganVzdCBicm9r ZSBvdXQgdGhlIENCT1IgV2ViIFRva2VuIGludG8gYSBzZXBhcmF0ZSBkcmFmdCBhbmQgdGhlIG5l dyBkcmFmdCBpcyBzdWJtaXR0ZWQgdG8gdGhlIE9BVVRIIFdHLiBJdCBjYW4gYmUgZm91bmQgaGVy ZTogDQoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXdhaGxzdHJvZW0t b2F1dGgtY2Jvci13ZWItdG9rZW4vDQoNCkFic3RyYWN0OiANCiJDQk9SIFdlYiBUb2tlbiAoQ1dU KSBpcyBhIGNvbXBhY3QgbWVhbnMgb2YgcmVwcmVzZW50aW5nIGNsYWltcyB0byBiZSB0cmFuc2Zl cnJlZCBiZXR3ZWVuIHR3byBwYXJ0aWVzLiAgQ1dUIGlzIGEgcHJvZmlsZSBvZiB0aGUgSlNPTiBX ZWIgVG9rZW4gKEpXVCkgdGhhdCBpcyBvcHRpbWl6ZWQgZm9yIGNvbnN0cmFpbmVkIGRldmljZXMu IFRoZSBjbGFpbXMgaW4gYSBDV1QgYXJlIGVuY29kZWQgaW4gdGhlIENvbmNpc2UgQmluYXJ5IE9i amVjdCBSZXByZXNlbnRhdGlvbiAoQ0JPUikgYW5kIENCT1IgT2JqZWN0IFNpZ25pbmcgYW5kIEVu Y3J5cHRpb24gKENPU0UpIGlzIHVzZWQgZm9yIGFkZGVkIGFwcGxpY2F0aW9uIGxheWVyIHNlY3Vy aXR5IHByb3RlY3Rpb24uICBBIGNsYWltIGlzIGEgcGllY2Ugb2YgaW5mb3JtYXRpb24gYXNzZXJ0 ZWQgYWJvdXQgYSBzdWJqZWN0IGFuZCBpcyByZXByZXNlbnRlZCBhcyBhIG5hbWUvdmFsdWUgcGFp ciBjb25zaXN0aW5nIG9mIGEgY2xhaW0gbmFtZSBhbmQgYSBjbGFpbSB2YWx1ZS4iDQoNCi8gRXJp aw0KDQoNClsxXSBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc2VpdHotYWNlLW9h dXRoLWF1dGh6LTAwDQoNCg== From nobody Thu Nov 12 12:01:50 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91B441B339A; Thu, 12 Nov 2015 12:01:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.31 X-Spam-Level: X-Spam-Status: No, score=-2.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qiIJZOOvm9Ct; Thu, 12 Nov 2015 12:01:42 -0800 (PST) Received: from smtp.nexusgroup.com (smtp.nexusgroup.com [83.241.133.121]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B19D71B33AC; Thu, 12 Nov 2015 12:01:27 -0800 (PST) Received: from NG-EX01.ad.nexusgroup.com (10.75.28.40) by NG-EX02.ad.nexusgroup.com (10.75.28.43) with Microsoft SMTP Server (TLS) id 15.0.995.29; Thu, 12 Nov 2015 21:01:25 +0100 Received: from NG-EX01.ad.nexusgroup.com ([fe80::1d3d:b319:f020:2bab]) by NG-EX01.ad.nexusgroup.com ([fe80::1d3d:b319:f020:2bab%12]) with mapi id 15.00.0995.032; Thu, 12 Nov 2015 21:01:25 +0100 From: =?utf-8?B?RXJpayBXYWhsc3Ryw7ZtIG5lWHVz?= To: Carsten Bormann Thread-Topic: [COSE] A draft on CBOR Web Tokens (CWT) Thread-Index: AQHRHX3EcFviJsoC2k6K5CeJemK0A56YuYEAgAAEkAA= Date: Thu, 12 Nov 2015 20:01:24 +0000 Message-ID: <73929C18-A3E7-4ACA-A6DC-5A7AD7576C9B@nexusgroup.com> References: <53BB1987-979C-4945-9C7D-CDB6619AEFFC@nexusgroup.com> <5644EC40.4010002@tzi.org> In-Reply-To: <5644EC40.4010002@tzi.org> Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.2104) x-originating-ip: [37.247.26.197] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Hannes Tschofenig , "cose@ietf.org" , "" , "ace@ietf.org" Subject: Re: [OAUTH-WG] [COSE] A draft on CBOR Web Tokens (CWT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2015 20:01:45 -0000 SGkgQ2Fyc3RlbiwNCg0KVGhhbmtzLCBhbmQgSSBhZ3JlZS4gSeKAmXZlIGhlYXJkIGFyZ3VtZW50 cyBmb3IgYWxsIHRocmVlIHdvcmsgZ3JvdXBzLg0KDQpCb3Jyb3dlZCBzb21lIG9mIHlvdXIgd29y ZHMgdG8gZGVmaW5lIHRoZSBjb250ZW50IG9mIHRoZSBkcmFmdCA6KQ0KSXTigJlzIGl0IGVzc2Vu dGlhbGx5IGEgSldULCBwaHJhc2VkIGluIGFuZCBwcm9maWxlZCBmb3IgQ0JPUiB0byBhZGRyZXNz IEFDRSBuZWVkcywgd2hlcmUgT0F1dGggbmVlZHMgQ09TRSBmdW5jdGlvbmFsaXR5LCBmb3Igb2Jq ZWN0IHNlY3VyaXR5Lg0KDQpJ4oCZbSBvcGVuIGZvciBsZXR0aW5nIHRoZSBBROKAmXMgbW92ZSBp dCBhcm91bmQsIGJ1dCBoYXZpbmcgaXQgcmlnaHQgbmV4dCB0byBKV1Qgc2VlbXMgcmlnaHQgdG8g bWUuIEFsc28gb3BlbiBmb3IgdGhlIEFDRSBXRy4gRmVlbCBpdCBoYXMgbGVzcyBwbGFjZSBpbiBD T1NFIGZvciB0aGUgc2FtZSByZWFzb25zIEpXVCBpcyBub3QgaW4gdGhlIEpPU0UgV0cuDQoNCi8g RXJpaw0KDQoNCj4gT24gMTIgTm92IDIwMTUsIGF0IDIwOjQ1LCBDYXJzdGVuIEJvcm1hbm4gPGNh Ym9AdHppLm9yZz4gd3JvdGU6DQo+IA0KPiBIaSBFcmlrLA0KPiANCj4gaGF2aW5nIHRoaXMgZHJh ZnQgaXMgYSBnb29kIHRoaW5nLg0KPiANCj4gT25lIHRoaW5nIEknbSBzdGlsbCB3b25kZXJpbmcg aXMgd2hhdCBXRyBpcyB0aGUgYmVzdCBwbGFjZSB0byBwcm9ncmVzcw0KPiB0aGlzLiAgV2UgcHJv YmFibHkgZG9uJ3QgbmVlZCB0byBzcGVuZCB0b28gbXVjaCB0aW1lIG9uIHRoaXMgYmVjYXVzZSwN Cj4gcmVnYXJkbGVzcyBvZiB0aGUgV0cgY2hvc2VuLCB0aGUgcGVvcGxlIGluIGFub3RoZXIgV0cg Y2FuIGxvb2sgYXQgaXQuDQo+IFN0aWxsLCBnZXR0aW5nIHRoaXMgcmlnaHQgbWlnaHQgcHJvdmlk ZSBzb21lIGVmZmljaWVuY2llcy4NCj4gDQo+IFdoYXQgaXMgdGhlIHRlY2huaWNhbCBjb250ZW50 IG9mIHRoaXMgZHJhZnQ/ICBJcyBpdCBhIG5ldyB0b2tlbiB0aGF0DQo+IE9BdXRoIG5lZWRzIHNw ZWNpZmljYWxseSBmb3IgdGhlIG5ldyBDT1NFLWJhc2VkIGFwcGxpY2F0aW9ucyBvZiBPQXV0aD8N Cj4gSXMgaXQgYSBuZXcgdG9rZW4gdGhhdCBpcyBzcGVjaWZpY2FsbHkgdGhlcmUgZm9yIGFkZHJl c3NpbmcgQUNFIG5lZWRzPw0KPiBPciBpcyBpdCBlc3NlbnRpYWxseSB0aGUgc2FtZSBzdWJzdGFu Y2UgYXMgSldULCBidXQgcGhyYXNlZCBpbiBhbmQNCj4gcHJvZmlsZWQgZm9yIENCT1I/DQo+IA0K PiBEZXBlbmRpbmcgb24gdGhlIGFuc3dlciwgQ1dUIHNob3VsZCBiZSBkb25lIGluIE9BdXRoLCBB Q0UsIG9yIENPU0UuDQo+IChJJ2QgcmF0aGVyIGhlYXIgdGhlIGFuc3dlciBmcm9tIHRoZSBhdXRo b3JzIHRoYW4gdmVudHVyZSBhIGd1ZXNzIG15c2VsZi4pDQo+IA0KPiBHcsO8w59lLCBDYXJzdGVu DQo+IA0KPiANCj4gDQo+IEVyaWsgV2FobHN0csO2bSBuZVh1cyB3cm90ZToNCj4+IEhpLA0KPj4g DQo+PiBJbiB0aGUgQUNFIFdHIGEgc3RyYXcgbWFuIHByb3Bvc2FsIG9mIGEgQ0JPUiBXZWIgVG9r ZW4gKENXVCkgd2FzIGRlZmluZWQNCj4+IGluIHRoZSBkcmFmdCAiQXV0aG9yaXphdGlvbiBmb3Ig dGhlIEludGVybmV0IG9mIFRoaW5ncyB1c2luZyBPQXV0aCAyLjDigJ0NCj4+IFsxXS4gV2UganVz dCBicm9rZSBvdXQgdGhlIENCT1IgV2ViIFRva2VuIGludG8gYSBzZXBhcmF0ZSBkcmFmdCBhbmQg dGhlDQo+PiBuZXcgZHJhZnQgaXMgc3VibWl0dGVkIHRvIHRoZSBPQVVUSCBXRy4gSXQgY2FuIGJl IGZvdW5kIGhlcmU6IA0KPj4gDQo+PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC13YWhsc3Ryb2VtLW9hdXRoLWNib3Itd2ViLXRva2VuLw0KPj4gDQo+PiBBYnN0cmFjdDog DQo+PiAiQ0JPUiBXZWIgVG9rZW4gKENXVCkgaXMgYSBjb21wYWN0IG1lYW5zIG9mIHJlcHJlc2Vu dGluZyBjbGFpbXMgdG8gYmUNCj4+IHRyYW5zZmVycmVkIGJldHdlZW4gdHdvIHBhcnRpZXMuICBD V1QgaXMgYSBwcm9maWxlIG9mIHRoZSBKU09OIFdlYiBUb2tlbg0KPj4gKEpXVCkgdGhhdCBpcyBv cHRpbWl6ZWQgZm9yIGNvbnN0cmFpbmVkIGRldmljZXMuIFRoZSBjbGFpbXMgaW4gYSBDV1QgYXJl DQo+PiBlbmNvZGVkIGluIHRoZSBDb25jaXNlIEJpbmFyeSBPYmplY3QgUmVwcmVzZW50YXRpb24g KENCT1IpIGFuZCBDQk9SDQo+PiBPYmplY3QgU2lnbmluZyBhbmQgRW5jcnlwdGlvbiAoQ09TRSkg aXMgdXNlZCBmb3IgYWRkZWQgYXBwbGljYXRpb24gbGF5ZXINCj4+IHNlY3VyaXR5IHByb3RlY3Rp b24uICBBIGNsYWltIGlzIGEgcGllY2Ugb2YgaW5mb3JtYXRpb24gYXNzZXJ0ZWQgYWJvdXQgYQ0K Pj4gc3ViamVjdCBhbmQgaXMgcmVwcmVzZW50ZWQgYXMgYSBuYW1lL3ZhbHVlIHBhaXIgY29uc2lz dGluZyBvZiBhIGNsYWltDQo+PiBuYW1lIGFuZCBhIGNsYWltIHZhbHVlLiINCj4+IA0KPj4gLyBF cmlrDQo+PiANCj4+IA0KPj4gWzFdIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1z ZWl0ei1hY2Utb2F1dGgtYXV0aHotMDANCj4+IA0KPj4gDQo+PiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gQ09TRSBtYWlsaW5nIGxpc3QNCj4+IENP U0VAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29z ZQ0KDQo= From nobody Thu Nov 12 12:38:39 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86BE01B355D for ; Thu, 12 Nov 2015 12:38:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.701 X-Spam-Level: X-Spam-Status: No, score=-1.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W_zcWq4UziET for ; Thu, 12 Nov 2015 12:38:31 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0118.outbound.protection.outlook.com [207.46.100.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF4071B355C for ; Thu, 12 Nov 2015 12:38:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=jZyGgdsipmPKVxDiPM1KtO8db1ti0ExlwdNYo+v3rmc=; b=f309s7G9O/zIiTkULSin7FXJwTIUFx2DzxjjagGQdGZByZi5Kr/rkZcI+7WSaRK5pQJEWlierttyY2nho/29gnzAMEIDgBdzN51MatZEDeBOHA1hs0cp2pM8Lt4fpvjIgIT7bTFbi6v6rcQ+3aGnoVPaKCtEEueS+GZAV7v6aus= Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB443.namprd03.prod.outlook.com (10.141.141.152) with Microsoft SMTP Server (TLS) id 15.1.325.17; Thu, 12 Nov 2015 20:38:29 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0325.003; Thu, 12 Nov 2015 20:38:29 +0000 From: Mike Jones To: =?utf-8?B?RXJpayBXYWhsc3Ryw7ZtIG5lWHVz?= , "" Thread-Topic: A draft on CBOR Web Tokens (CWT) Thread-Index: AQHRHX3DyXQEi0Hb60mPSXqbnVxSe56Y2MzQ Date: Thu, 12 Nov 2015 20:38:29 +0000 Message-ID: References: <53BB1987-979C-4945-9C7D-CDB6619AEFFC@nexusgroup.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [50.47.89.201] x-microsoft-exchange-diagnostics: 1; BY2PR03MB443; 5:9o83mr9bJaqzsNVigBDD6N6hXOVmpT814RCX0S3haHxBZKkN4RmqDNye9gR+NDjVwMCuZreg/kvA6cgL2ok4DMPk1b7RKiXjtvUQ/25Qn739lN64v0MZw3fBMCNJCq25NiKexm0FnWMoHfPk5lABCg==; 24:lcsCt1uIKl+dU9uov81SKIkVlA52/6CQ+0PYoX2RZHCQSG3+UPNZqjbi9JMklV/FRoDLXZu6vuWc2wD2omwpYlh6jBlQgV8Ya1wsS+f4sqk=; 20:FsY3Fj5lVmI2z0XT5JzCnn4wfxEoFq/W93D+hPHuv7BgbM32aAARBNCbtL00ymdRUWKEvORzOIBcfyrj3gPSpQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB443; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425024)(601004)(2401047)(5005006)(520078)(8121501046)(10201501046)(3002001)(61426024)(61427024); SRVR:BY2PR03MB443; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB443; x-forefront-prvs: 07584EDBCD x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(209900001)(377454003)(199003)(13464003)(189002)(69234005)(50986999)(54356999)(19300405004)(107886002)(10090500001)(16236675004)(19580395003)(33656002)(19580405001)(15975445007)(101416001)(76176999)(561944003)(19625215002)(2950100001)(106356001)(77096005)(2900100001)(105586002)(8990500004)(10290500002)(10400500002)(92566002)(99286002)(5005710100001)(106116001)(102836002)(87936001)(5008740100001)(11100500001)(5002640100001)(122556002)(5001920100001)(5001770100001)(5003600100002)(5004730100002)(66066001)(76576001)(189998001)(5001960100002)(81156007)(97736004)(5007970100001)(74316001)(86362001)(86612001)(19617315012)(40100003)(491001)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB443; H:BY2PR03MB442.namprd03.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:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR03MB442CD32A3E442C53707A09FF5120BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Nov 2015 20:38:29.4314 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB443 Archived-At: Subject: Re: [OAUTH-WG] A draft on CBOR Web Tokens (CWT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2015 20:38:38 -0000 --_000_BY2PR03MB442CD32A3E442C53707A09FF5120BY2PR03MB442namprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RllJIC0gSSBhbHNvIHdyb3RlIGFib3V0IHRoaXMgYXQgaHR0cDovL3NlbGYtaXNzdWVkLmluZm8v P3A9MTQ3NiBhbmQgYXMgQHNlbGZpc3N1ZWQ8aHR0cHM6Ly90d2l0dGVyLmNvbS9zZWxmaXNzdWVk Pi4NCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBPQXV0aCBbbWFpbHRv Om9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBFcmlrIFdhaGxzdHLDtm0gbmVY dXMNClNlbnQ6IFRodXJzZGF5LCBOb3ZlbWJlciAxMiwgMjAxNSAxMToyNiBBTQ0KVG86IDxvYXV0 aEBpZXRmLm9yZz4NClN1YmplY3Q6IFtPQVVUSC1XR10gQSBkcmFmdCBvbiBDQk9SIFdlYiBUb2tl bnMgKENXVCkNCg0KDQoNCkhpLA0KDQoNCg0KSW4gdGhlIEFDRSBXRyBhIHN0cmF3IG1hbiBwcm9w b3NhbCBvZiBhIENCT1IgV2ViIFRva2VuIChDV1QpIHdhcyBkZWZpbmVkIGluIHRoZSBkcmFmdCAi QXV0aG9yaXphdGlvbiBmb3IgdGhlIEludGVybmV0IG9mIFRoaW5ncyB1c2luZyBPQXV0aCAyLjDi gJ0gWzFdLiBXZSBqdXN0IGJyb2tlIG91dCB0aGUgQ0JPUiBXZWIgVG9rZW4gaW50byBhIHNlcGFy YXRlIGRyYWZ0IGFuZCB0aGUgbmV3IGRyYWZ0IGlzIHN1Ym1pdHRlZCB0byB0aGUgT0FVVEggV0cu IEl0IGNhbiBiZSBmb3VuZCBoZXJlOg0KDQoNCg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtd2FobHN0cm9lbS1vYXV0aC1jYm9yLXdlYi10b2tlbi8NCg0KDQoNCkFic3Ry YWN0Og0KDQoiQ0JPUiBXZWIgVG9rZW4gKENXVCkgaXMgYSBjb21wYWN0IG1lYW5zIG9mIHJlcHJl c2VudGluZyBjbGFpbXMgdG8gYmUgdHJhbnNmZXJyZWQgYmV0d2VlbiB0d28gcGFydGllcy4gIENX VCBpcyBhIHByb2ZpbGUgb2YgdGhlIEpTT04gV2ViIFRva2VuIChKV1QpIHRoYXQgaXMgb3B0aW1p emVkIGZvciBjb25zdHJhaW5lZCBkZXZpY2VzLiBUaGUgY2xhaW1zIGluIGEgQ1dUIGFyZSBlbmNv ZGVkIGluIHRoZSBDb25jaXNlIEJpbmFyeSBPYmplY3QgUmVwcmVzZW50YXRpb24gKENCT1IpIGFu ZCBDQk9SIE9iamVjdCBTaWduaW5nIGFuZCBFbmNyeXB0aW9uIChDT1NFKSBpcyB1c2VkIGZvciBh ZGRlZCBhcHBsaWNhdGlvbiBsYXllciBzZWN1cml0eSBwcm90ZWN0aW9uLiAgQSBjbGFpbSBpcyBh IHBpZWNlIG9mIGluZm9ybWF0aW9uIGFzc2VydGVkIGFib3V0IGEgc3ViamVjdCBhbmQgaXMgcmVw cmVzZW50ZWQgYXMgYSBuYW1lL3ZhbHVlIHBhaXIgY29uc2lzdGluZyBvZiBhIGNsYWltIG5hbWUg YW5kIGEgY2xhaW0gdmFsdWUuIg0KDQoNCg0KLyBFcmlrDQoNCg0KDQoNCg0KWzFdIGh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zZWl0ei1hY2Utb2F1dGgtYXV0aHotMDANCg0KDQoN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCk9BdXRo IG1haWxpbmcgbGlzdA0KDQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQoN Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg== --_000_BY2PR03MB442CD32A3E442C53707A09FF5120BY2PR03MB442namprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5 cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dl ZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxpLk1zb1BsYWluVGV4dCwgZGl2Lk1z b1BsYWluVGV4dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBs YWluIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30N CnNwYW4uUGxhaW5UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiUGxhaW4gVGV4dCBDaGFyIjsN Cgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQiOw0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KLk1zb0NocERlZmF1bHQNCgl7 bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFy Z2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpX b3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRp Zl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0 Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0Pjwv eG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPkZZSSAtIEkgYWxzbyB3cm90ZSBhYm91dCB0aGlzIGF0IDxhIGhyZWY9Imh0 dHA6Ly9zZWxmLWlzc3VlZC5pbmZvLz9wPTE0NzYiPg0KaHR0cDovL3NlbGYtaXNzdWVkLmluZm8v P3A9MTQ3NjwvYT4gYW5kIGFzIDxhIGhyZWY9Imh0dHBzOi8vdHdpdHRlci5jb20vc2VsZmlzc3Vl ZCI+DQpAc2VsZmlzc3VlZDwvYT4uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPi0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KRnJvbTogT0F1dGggW21haWx0bzpvYXV0aC1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRXJpayBXYWhsc3Ryw7ZtIG5lWHVzPGJyPg0KU2Vu dDogVGh1cnNkYXksIE5vdmVtYmVyIDEyLCAyMDE1IDExOjI2IEFNPGJyPg0KVG86ICZsdDtvYXV0 aEBpZXRmLm9yZyZndDs8YnI+DQpTdWJqZWN0OiBbT0FVVEgtV0ddIEEgZHJhZnQgb24gQ0JPUiBX ZWIgVG9rZW5zIChDV1QpPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5IaSw8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+SW4gdGhlIEFDRSBXRyBhIHN0cmF3IG1hbiBwcm9wb3NhbCBvZiBhIENCT1Ig V2ViIFRva2VuIChDV1QpIHdhcyBkZWZpbmVkIGluIHRoZSBkcmFmdCAmcXVvdDtBdXRob3JpemF0 aW9uIGZvciB0aGUgSW50ZXJuZXQgb2YgVGhpbmdzIHVzaW5nIE9BdXRoIDIuMOKAnSBbMV0uIFdl IGp1c3QgYnJva2Ugb3V0IHRoZSBDQk9SIFdlYiBUb2tlbiBpbnRvIGEgc2VwYXJhdGUgZHJhZnQg YW5kIHRoZSBuZXcgZHJhZnQgaXMgc3VibWl0dGVkDQogdG8gdGhlIE9BVVRIIFdHLiBJdCBjYW4g YmUgZm91bmQgaGVyZTogPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxhIGhyZWY9Imh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXdhaGxzdHJvZW0tb2F1dGgtY2Jv ci13ZWItdG9rZW4vIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRp b246bm9uZSI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtd2FobHN0cm9l bS1vYXV0aC1jYm9yLXdlYi10b2tlbi88L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij5BYnN0cmFjdDogPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mcXVvdDtDQk9SIFdlYiBUb2tlbiAoQ1dUKSBpcyBhIGNvbXBhY3QgbWVhbnMgb2YgcmVwcmVz ZW50aW5nIGNsYWltcyB0byBiZSB0cmFuc2ZlcnJlZCBiZXR3ZWVuIHR3byBwYXJ0aWVzLiZuYnNw OyBDV1QgaXMgYSBwcm9maWxlIG9mIHRoZSBKU09OIFdlYiBUb2tlbiAoSldUKSB0aGF0IGlzIG9w dGltaXplZCBmb3IgY29uc3RyYWluZWQgZGV2aWNlcy4gVGhlIGNsYWltcyBpbiBhIENXVCBhcmUg ZW5jb2RlZCBpbiB0aGUgQ29uY2lzZQ0KIEJpbmFyeSBPYmplY3QgUmVwcmVzZW50YXRpb24gKENC T1IpIGFuZCBDQk9SIE9iamVjdCBTaWduaW5nIGFuZCBFbmNyeXB0aW9uIChDT1NFKSBpcyB1c2Vk IGZvciBhZGRlZCBhcHBsaWNhdGlvbiBsYXllciBzZWN1cml0eSBwcm90ZWN0aW9uLiZuYnNwOyBB IGNsYWltIGlzIGEgcGllY2Ugb2YgaW5mb3JtYXRpb24gYXNzZXJ0ZWQgYWJvdXQgYSBzdWJqZWN0 IGFuZCBpcyByZXByZXNlbnRlZCBhcyBhIG5hbWUvdmFsdWUgcGFpciBjb25zaXN0aW5nIG9mIGEg Y2xhaW0NCiBuYW1lIGFuZCBhIGNsYWltIHZhbHVlLiZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4vIEVyaWs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5bMV0gPGEgaHJlZj0iaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNlaXR6LWFjZS1vYXV0aC1hdXRoei0wMCI+DQo8 c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+aHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNlaXR6LWFjZS1vYXV0aC1hdXRoei0wMDwvc3Bh bj48L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij5PQXV0aCBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9 ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPk9BdXRoQGlldGYub3JnPC9z cGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxhIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiPjxzcGFuIHN0eWxl PSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BY2PR03MB442CD32A3E442C53707A09FF5120BY2PR03MB442namprd_-- From nobody Thu Nov 12 13:02:17 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 630B01B2DAB; Thu, 12 Nov 2015 13:02:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aJhmDWatyTR7; Thu, 12 Nov 2015 13:02:12 -0800 (PST) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05B0E1B2CB2; Thu, 12 Nov 2015 13:02:10 -0800 (PST) X-AuditID: 1209190f-f79d06d000004b20-b5-5644fe5131c3 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 07.69.19232.15EF4465; Thu, 12 Nov 2015 16:02:09 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id tACL28Ag017398; Thu, 12 Nov 2015 16:02:08 -0500 Received: from artemisia.richer.local (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id tACL255e013631 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 12 Nov 2015 16:02:06 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_C6D98A78-6AB4-405D-80A6-BB4D661F8B40" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Justin Richer In-Reply-To: <53BB1987-979C-4945-9C7D-CDB6619AEFFC@nexusgroup.com> Date: Thu, 12 Nov 2015 16:02:05 -0500 Message-Id: <519F98B0-E02B-4827-9862-8F7AAF87FEA2@mit.edu> References: <53BB1987-979C-4945-9C7D-CDB6619AEFFC@nexusgroup.com> To: =?utf-8?Q?Erik_Wahlstr=C3=B6m_neXus?= X-Mailer: Apple Mail (2.2104) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrDKsWRmVeSWpSXmKPExsUixCmqrRv4zyXM4N1uWYvv33qYLaZtncpq cWzXYjaLmzNOMVnsnfaJxeLk21dsDmwea+atYfRYsuQnk0frjr/sHlvv/2YMYInisklJzcks Sy3St0vgyvg0bQNzQbd2xcJVbWwNjHNVuxg5OCQETCQmbTPrYuQEMsUkLtxbzwZiCwksZpL4 8KC4i5ELyN7IKHHr6V9WCOchk8SFI+1MIFXMAgkSS/vmsoDYvAJ6Eq9uXWYFGSoMNPTX51yQ MJuAqsT0NS1g5ZwCThLXt60GW8ACFF9xYyk7xJjbjBKLOgUgxlhJvLw/lQniCEeJxmW3mEFs EQFPiZsn/7NAHCorsfv3I6YJjAKzkFwxC8kVEHFtiWULXzND2JoS+7uXs2CKa0h0fpvIuoCR bRWjbEpulW5uYmZOcWqybnFyYl5eapGuiV5uZoleakrpJkZwpEjy72D8dlDpEKMAB6MSD++O Fy5hQqyJZcWVuYcYJTmYlER5pd4AhfiS8lMqMxKLM+KLSnNSiw8xSnAwK4nwLn4GlONNSays Si3Kh0lJc7AoifNu+sEXIiSQnliSmp2aWpBaBJOV4eBQkuDN/wvUKFiUmp5akZaZU4KQZuLg BBnOAzQ8CaSGt7ggMbc4Mx0if4pRUUqctwYkIQCSyCjNg+sFJbKEt4dNXzGKA70izBsBUsUD TIJw3a+ABjMBDf4i4QQyuCQRISXVwOjS/nK//sNG6VnZPxUrXx4znyHd/+jYC9mzfku+iz16 Yyo9xd726a2IrU88LgXJLmDoL7VvPLleWPOnJOutUmv7SwwlKabyK4Ua/tgFZFz6r3DswMmF h96f79meJbXbdtv+eZHf/ryfeYn1lfry8pnl3e8T/6+Pvqc9z3b/zaS2c75bwrsSrjIqsRRn JBpqMRcVJwIAxjqTyj8DAAA= Archived-At: Cc: Hannes Tschofenig , "cose@ietf.org" , "" , "ace@ietf.org" Subject: Re: [OAUTH-WG] [COSE] A draft on CBOR Web Tokens (CWT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2015 21:02:14 -0000 --Apple-Mail=_C6D98A78-6AB4-405D-80A6-BB4D661F8B40 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks very much, Eric. As we promised in Yokohama, the chairs of the COSE working group are = currently running a consensus call thread about this very topic, and = I=E2=80=99d encourage others to join that discussion. The thread starts = here: http://www.ietf.org/mail-archive/web/cose/current/msg00747.html =E2=80=94 Justin > On Nov 12, 2015, at 2:10 PM, Erik Wahlstr=C3=B6m neXus = wrote: >=20 > Hi, >=20 > In the ACE WG a straw man proposal of a CBOR Web Token (CWT) was = defined in the draft "Authorization for the Internet of Things using = OAuth 2.0=E2=80=9D [1]. We just broke out the CBOR Web Token into a = separate draft and the new draft is submitted to the OAUTH WG. It can be = found here:=20 >=20 > = https://datatracker.ietf.org/doc/draft-wahlstroem-oauth-cbor-web-token/ = >=20 > Abstract:=20 > "CBOR Web Token (CWT) is a compact means of representing claims to be = transferred between two parties. CWT is a profile of the JSON Web Token = (JWT) that is optimized for constrained devices. The claims in a CWT are = encoded in the Concise Binary Object Representation (CBOR) and CBOR = Object Signing and Encryption (COSE) is used for added application layer = security protection. A claim is a piece of information asserted about a = subject and is represented as a name/value pair consisting of a claim = name and a claim value." >=20 > / Erik >=20 >=20 > [1] https://tools.ietf.org/html/draft-seitz-ace-oauth-authz-00 = >=20 >=20 > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose --Apple-Mail=_C6D98A78-6AB4-405D-80A6-BB4D661F8B40 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thanks very much, Eric.

As we promised in Yokohama, the chairs = of the COSE working group are currently running a consensus call thread = about this very topic, and I=E2=80=99d encourage others to join that = discussion. The thread starts here:

http://www.ietf.org/mail-archive/web/cose/current/msg00747.html=

 =E2=80= =94 Justin

On Nov 12, 2015, at 2:10 PM, = Erik Wahlstr=C3=B6m neXus <erik.wahlstrom@nexusgroup.com> wrote:

Hi,

In the ACE WG a straw man proposal of a CBOR Web Token = (CWT) was defined in the draft "Authorization for the Internet of Things = using OAuth 2.0=E2=80=9D [1]. We just broke out the CBOR Web Token into = a separate draft and the new draft is submitted to the OAUTH WG. It can be found here: 

https://datatracker.ietf.org/doc/draft-wahlstroem-oauth-cbor-we= b-token/

Abstract: 
"CBOR Web Token (CWT) is a compact means of representing = claims to be transferred between two parties.  CWT is a profile of = the JSON Web Token (JWT) that is optimized for constrained devices. The = claims in a CWT are encoded in the Concise Binary Object Representation (CBOR) and CBOR Object Signing and Encryption = (COSE) is used for added application layer security protection.  A = claim is a piece of information asserted about a subject and is = represented as a name/value pair consisting of a claim name and a claim value."

/ Erik


[1] https://tools.ietf.org/html/draft-seitz-ace-oauth-authz-00<= /div>


_______________________________________________
COSE = mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose

= --Apple-Mail=_C6D98A78-6AB4-405D-80A6-BB4D661F8B40-- From nobody Thu Nov 12 19:19:56 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D5D91B3F4A for ; Thu, 12 Nov 2015 19:19:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.088 X-Spam-Level: X-Spam-Status: No, score=-1.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q0qaWGHO3FcZ for ; Thu, 12 Nov 2015 19:19:50 -0800 (PST) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FA801B3F44 for ; Thu, 12 Nov 2015 19:19:47 -0800 (PST) Received: by qkas77 with SMTP id s77so35838650qka.0 for ; Thu, 12 Nov 2015 19:19:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=OhV0MalIias2AhIT5ewNpHwULukXJA02/rJAmtrfKXY=; b=Ejo3ZFe3UZuRL13WEm1+NAtdeS5na43uIKZGA/4iZyBrdL4t5POuXT6Uk1PaZmDzzW 3t9ZxNuvs1ocFgiH2H5i7fnGxJfKgMVy7v+UECkI6C3TIxs3uTIjwaaYTA+mqaSYV+mr KPzNZJuB+c3ZkhA0Mz7EDmssHORbT8Wa4817pyDE8nfr3kVcKs2fgXHIB95HRY/vE4tJ K0d52PrOjNID4eOWmH6dsiS0+cvuSflri3q6PT9Ku45IBvWtAr+P8vbO2xzrVaP07moE R6mujkY8ikvER5wNGZ1yttlJJq/b3HUz6z76vNHqjo96ahoVAiNGTpYrmozn6Vlv8jkS Hc0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=OhV0MalIias2AhIT5ewNpHwULukXJA02/rJAmtrfKXY=; b=e0bvZWDw5YnETstU9WT+VZKEjQGEL8MzPJlGTzaKepePbVz2BR4pfEV0uDaCO8xB1M 88NeFSPir4k6fQDTdTHcyVRktD9Z0tQnnd4P4wns+WcaotjVTYUzRLzWEE8FLiIf38t2 FTAJjyWE1rmNFpQrYLfdLXmnFYuKcYqwcCOqndQkq3dIa69AaD4hgLR62C/6Bwv8Nmon qO2CobXgY45SC/mOnAsA5Mg+pDdKR9xVB3Vc9/WMxa5WCAZeWwNw9Xa6IM1AK+tuXF9V f+nhZMjQ6toUeilMLfZ0lO52mM8RQQhJTnJOt6VLG6ZJVhM7b0XMUpoqhLsrQb55XUI4 NGxw== X-Gm-Message-State: ALoCoQk3JCzqtVRAEhv+RKthps94Kyl2gZ8ubUR2Lgzbb6InFgeSatA3Y9ZDN/03lfqziQyuAHyT X-Received: by 10.55.55.82 with SMTP id e79mr18970471qka.59.1447384786307; Thu, 12 Nov 2015 19:19:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.29.68 with HTTP; Thu, 12 Nov 2015 19:19:26 -0800 (PST) In-Reply-To: <73929C18-A3E7-4ACA-A6DC-5A7AD7576C9B@nexusgroup.com> References: <53BB1987-979C-4945-9C7D-CDB6619AEFFC@nexusgroup.com> <5644EC40.4010002@tzi.org> <73929C18-A3E7-4ACA-A6DC-5A7AD7576C9B@nexusgroup.com> From: William Denniss Date: Thu, 12 Nov 2015 19:19:26 -0800 Message-ID: To: =?UTF-8?Q?Erik_Wahlstr=C3=B6m_neXus?= Content-Type: multipart/alternative; boundary=001a114900f40ad79205246388f8 Archived-At: Cc: "ace@ietf.org" , Carsten Bormann , Hannes Tschofenig , "" , "cose@ietf.org" Subject: Re: [OAUTH-WG] [COSE] A draft on CBOR Web Tokens (CWT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2015 03:19:52 -0000 --001a114900f40ad79205246388f8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Regarding the draft itself, a few comments: 1. Can we unify the claim registry with JWT? I'm worried about having the same claims defined twice in CWT and JWT with possibly conflicting meanings (and needless confusion even when they do match). Comparing https://tools.ietf.org/html/draft-wahlstroem-oauth-cbor-web-token-00#sectio= n-3.1.2 and https://tools.ietf.org/html/rfc7519#section-4.1.2 which are nearly identical, I just don't see the value in re-defining it. We may add new standard claims to JWT in the future (I proposed one in Yokohama on the id-event list ), it would be good if this didn't need a separate entry in CWT too, but could just apply directly (separately, I think you should consider this claim, as it helps prevent tokens from being re-used in the wrong context). 2. Is Section 4 "Summary of CBOR major types used by defined claims" normative ( https://tools.ietf.org/html/draft-wahlstroem-oauth-cbor-web-token-00#sectio= n-4)? What is the intention of this section? I feel like it could probably be fleshed out a bit. 3. Add a xref to draft COSE spec in section 6 Add xref to RFC7519 On Thu, Nov 12, 2015 at 12:01 PM, Erik Wahlstr=C3=B6m neXus < erik.wahlstrom@nexusgroup.com> wrote: > Hi Carsten, > > Thanks, and I agree. I=E2=80=99ve heard arguments for all three work grou= ps. > > Borrowed some of your words to define the content of the draft :) > It=E2=80=99s it essentially a JWT, phrased in and profiled for CBOR to ad= dress ACE > needs, where OAuth needs COSE functionality, for object security. > > I=E2=80=99m open for letting the AD=E2=80=99s move it around, but having = it right next to > JWT seems right to me. Also open for the ACE WG. Feel it has less place i= n > COSE for the same reasons JWT is not in the JOSE WG. > > / Erik > > > > On 12 Nov 2015, at 20:45, Carsten Bormann wrote: > > > > Hi Erik, > > > > having this draft is a good thing. > > > > One thing I'm still wondering is what WG is the best place to progress > > this. We probably don't need to spend too much time on this because, > > regardless of the WG chosen, the people in another WG can look at it. > > Still, getting this right might provide some efficiencies. > > > > What is the technical content of this draft? Is it a new token that > > OAuth needs specifically for the new COSE-based applications of OAuth? > > Is it a new token that is specifically there for addressing ACE needs? > > Or is it essentially the same substance as JWT, but phrased in and > > profiled for CBOR? > > > > Depending on the answer, CWT should be done in OAuth, ACE, or COSE. > > (I'd rather hear the answer from the authors than venture a guess > myself.) > > > > Gr=C3=BC=C3=9Fe, Carsten > > > > > > > > Erik Wahlstr=C3=B6m neXus wrote: > >> Hi, > >> > >> In the ACE WG a straw man proposal of a CBOR Web Token (CWT) was defin= ed > >> in the draft "Authorization for the Internet of Things using OAuth 2.0= =E2=80=9D > >> [1]. We just broke out the CBOR Web Token into a separate draft and th= e > >> new draft is submitted to the OAUTH WG. It can be found here: > >> > >> https://datatracker.ietf.org/doc/draft-wahlstroem-oauth-cbor-web-token= / > >> > >> Abstract: > >> "CBOR Web Token (CWT) is a compact means of representing claims to be > >> transferred between two parties. CWT is a profile of the JSON Web Tok= en > >> (JWT) that is optimized for constrained devices. The claims in a CWT a= re > >> encoded in the Concise Binary Object Representation (CBOR) and CBOR > >> Object Signing and Encryption (COSE) is used for added application lay= er > >> security protection. A claim is a piece of information asserted about= a > >> subject and is represented as a name/value pair consisting of a claim > >> name and a claim value." > >> > >> / Erik > >> > >> > >> [1] https://tools.ietf.org/html/draft-seitz-ace-oauth-authz-00 > >> > >> > >> _______________________________________________ > >> COSE mailing list > >> COSE@ietf.org > >> https://www.ietf.org/mailman/listinfo/cose > > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose > --001a114900f40ad79205246388f8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Regarding the draft itself, a few comments:
=

1.=C2=A0
Can we unify the claim registry with= JWT? I'm worried about having the same claims defined twice in CWT and= JWT with possibly conflicting meanings (and needless confusion even when t= hey do match).=C2=A0

Comparing=C2=A0https://tools.ietf.org/html/draft-wahlstroem-oauth-cbor-web-token= -00#section-3.1.2 and=C2=A0https://tools.ietf.org/html/rfc7519#section-4.1.2 whi= ch are nearly identical, I just don't see the value in re-defining it.<= /div>

We may add new standard claims to JWT in the futur= e (I=C2=A0proposed o= ne=C2=A0in Yokohama on the=C2=A0id-event list), it would be good if this didn't= need a separate entry in CWT too, but could just apply directly (separatel= y, I think you should consider this claim, as it helps prevent tokens from = being re-used in the wrong context).

2.
= Is Section 4 "Summary of CBOR major types used by defined claims"= normative (https://tools.ietf.org/html/draft-wahlstroem-oa= uth-cbor-web-token-00#section-4)? What is the intention of this section= ? I feel like it could probably be fleshed out a bit.

<= div>3.=C2=A0
Add a xref to draft COSE spec in=C2=A0
On Thu, Nov 12, 2015 at 12:01 PM, E= rik Wahlstr=C3=B6m neXus <erik.wahlstrom@nexusgroup.com>= ; wrote:
Hi Carsten,

Thanks, and I agree. I=E2=80=99ve heard arguments for all three work groups= .

Borrowed some of your words to define the content of the draft :)
It=E2=80=99s it essentially a JWT, phrased in and profiled for CBOR to addr= ess ACE needs, where OAuth needs COSE functionality, for object security.
I=E2=80=99m open for letting the AD=E2=80=99s move it around, but having it= right next to JWT seems right to me. Also open for the ACE WG. Feel it has= less place in COSE for the same reasons JWT is not in the JOSE WG.

/ Erik


> On 12 Nov 2015, at 20:45, Carsten Bormann <cabo@tzi.org> wrote:
>
> Hi Erik,
>
> having this draft is a good thing.
>
> One thing I'm still wondering is what WG is the best place to prog= ress
> this.=C2=A0 We probably don't need to spend too much time on this = because,
> regardless of the WG chosen, the people in another WG can look at it.<= br> > Still, getting this right might provide some efficiencies.
>
> What is the technical content of this draft?=C2=A0 Is it a new token t= hat
> OAuth needs specifically for the new COSE-based applications of OAuth?=
> Is it a new token that is specifically there for addressing ACE needs?=
> Or is it essentially the same substance as JWT, but phrased in and
> profiled for CBOR?
>
> Depending on the answer, CWT should be done in OAuth, ACE, or COSE. > (I'd rather hear the answer from the authors than venture a guess = myself.)
>
> Gr=C3=BC=C3=9Fe, Carsten
>
>
>
> Erik Wahlstr=C3=B6m neXus wrote:
>> Hi,
>>
>> In the ACE WG a straw man proposal of a CBOR Web Token (CWT) was d= efined
>> in the draft "Authorization for the Internet of Things using = OAuth 2.0=E2=80=9D
>> [1]. We just broke out the CBOR Web Token into a separate draft an= d the
>> new draft is submitted to the OAUTH WG. It can be found here:
>>
>> https://datatracker.= ietf.org/doc/draft-wahlstroem-oauth-cbor-web-token/
>>
>> Abstract:
>> "CBOR Web Token (CWT) is a compact means of representing clai= ms to be
>> transferred between two parties.=C2=A0 CWT is a profile of the JSO= N Web Token
>> (JWT) that is optimized for constrained devices. The claims in a C= WT are
>> encoded in the Concise Binary Object Representation (CBOR) and CBO= R
>> Object Signing and Encryption (COSE) is used for added application= layer
>> security protection.=C2=A0 A claim is a piece of information asser= ted about a
>> subject and is represented as a name/value pair consisting of a cl= aim
>> name and a claim value."
>>
>> / Erik
>>
>>
>> [1] https://tools.ietf.org/html/d= raft-seitz-ace-oauth-authz-00
>>
>>
>> _______________________________________________
>> COSE mailing list
>> COSE@ietf.org
>> https://www.ietf.org/mailman/listinfo/cose
_______________________________________________
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose

--001a114900f40ad79205246388f8-- From nobody Fri Nov 13 08:35:20 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC1EF1B32EE; Thu, 12 Nov 2015 11:45:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.25 X-Spam-Level: X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZAZlbFix0uNu; Thu, 12 Nov 2015 11:45:12 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FBDC1B32F0; Thu, 12 Nov 2015 11:45:10 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id tACJj54u003493; Thu, 12 Nov 2015 20:45:05 +0100 (CET) Received: from nar.local (p5DC7F6AE.dip0.t-ipconnect.de [93.199.246.174]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3nxYL94qc1z2GC8; Thu, 12 Nov 2015 20:45:05 +0100 (CET) Message-ID: <5644EC40.4010002@tzi.org> Date: Thu, 12 Nov 2015 20:45:04 +0100 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: =?UTF-8?B?RXJpayBXYWhsc3Ryw7ZtIG5lWHVz?= References: <53BB1987-979C-4945-9C7D-CDB6619AEFFC@nexusgroup.com> In-Reply-To: <53BB1987-979C-4945-9C7D-CDB6619AEFFC@nexusgroup.com> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: X-Mailman-Approved-At: Fri, 13 Nov 2015 08:35:18 -0800 Cc: Hannes Tschofenig , "cose@ietf.org" , "" , "ace@ietf.org" Subject: Re: [OAUTH-WG] [COSE] A draft on CBOR Web Tokens (CWT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2015 19:45:14 -0000 Hi Erik, having this draft is a good thing. One thing I'm still wondering is what WG is the best place to progress this. We probably don't need to spend too much time on this because, regardless of the WG chosen, the people in another WG can look at it. Still, getting this right might provide some efficiencies. What is the technical content of this draft? Is it a new token that OAuth needs specifically for the new COSE-based applications of OAuth? Is it a new token that is specifically there for addressing ACE needs? Or is it essentially the same substance as JWT, but phrased in and profiled for CBOR? Depending on the answer, CWT should be done in OAuth, ACE, or COSE. (I'd rather hear the answer from the authors than venture a guess myself.) Grüße, Carsten Erik Wahlström neXus wrote: > Hi, > > In the ACE WG a straw man proposal of a CBOR Web Token (CWT) was defined > in the draft "Authorization for the Internet of Things using OAuth 2.0†> [1]. We just broke out the CBOR Web Token into a separate draft and the > new draft is submitted to the OAUTH WG. It can be found here: > > https://datatracker.ietf.org/doc/draft-wahlstroem-oauth-cbor-web-token/ > > Abstract: > "CBOR Web Token (CWT) is a compact means of representing claims to be > transferred between two parties. CWT is a profile of the JSON Web Token > (JWT) that is optimized for constrained devices. The claims in a CWT are > encoded in the Concise Binary Object Representation (CBOR) and CBOR > Object Signing and Encryption (COSE) is used for added application layer > security protection. A claim is a piece of information asserted about a > subject and is represented as a name/value pair consisting of a claim > name and a claim value." > > / Erik > > > [1] https://tools.ietf.org/html/draft-seitz-ace-oauth-authz-00 > > > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose From nobody Fri Nov 13 12:46:53 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D5E11B3108 for ; Fri, 13 Nov 2015 12:46:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bxyHciRYF2O3 for ; Fri, 13 Nov 2015 12:46:50 -0800 (PST) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6163D1B3107 for ; Fri, 13 Nov 2015 12:46:50 -0800 (PST) Received: by ioc74 with SMTP id 74so109326609ioc.2 for ; Fri, 13 Nov 2015 12:46:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki_com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=hmqS7TksJ62OpKK37dZLdyxwWmGmLy84spx1QB2wCy4=; b=0D3IyE6hyLJKBvGYGjns7wSMvTL/hyPzwQuRH68h4tMpGH90pVR9rWN7Ge9bIUvFGO M94ngNKt0v3ITh9asr62Ko3bLMuXmn/AolQvfnTg2fswm5mxhSXNOlSom7uVSCzuRKJK jtiJLVWo6FY8iLFm02uTvK7KxvTCT/1JSno2xelA4d5ixYfLFpb7KAmtlhFhYdMNPGd0 liJKLQbcYKK4fXYKWqkivMTtbjGMB4k/5o+D+mtN4LO+YkM7Oe08CxiIZiqEmBIyKi2T nfW8639t2VxPaU+CTzEHqSTZnxULfXcRfjVYJyD+PCHOnCXOhY1H9TcXiSdItgaq7gVo GFkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=hmqS7TksJ62OpKK37dZLdyxwWmGmLy84spx1QB2wCy4=; b=Cx6cY6LpCVYOEgYDQID5CaT0DLp/V0qkpMi1C19yObhprm0TpWy5rrVYmvqFzDLpyz zHVF6UrdBImjpZt+po8jztW3nR55uCvo8mZDsoHPt7XNEDj34xddue4SKD6xZiXANSWD u80tIZTmD3Tdvtgcd1GKqWFSJKDSIJhkwtzqgiqq4m1qA1TKU8rSGjIxKR+WVzMjSfda C4hbACVf58C+505+BCI7JYfFFS2OEkfCF7acJapBn9jKA6KQRFwqY1woZfyosZLYFJNh J+We5LKFtIcxI7ve6ww2ycsjSsC9mZ5PVTGtbmJYTGCxQpcKfuc+tRHhbgywkgHawAHt AOFw== X-Gm-Message-State: ALoCoQnZwX/ZlCbWKn4SHBF/sX456Ya+piZph7kw8yjjEP2iyGkxXpvnNn4xRPC0rSfmW6lwdVXM X-Received: by 10.107.148.8 with SMTP id w8mr11176192iod.3.1447447609686; Fri, 13 Nov 2015 12:46:49 -0800 (PST) Received: from mail-ig0-f173.google.com (mail-ig0-f173.google.com. [209.85.213.173]) by smtp.gmail.com with ESMTPSA id n9sm1942998ige.16.2015.11.13.12.46.48 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Nov 2015 12:46:48 -0800 (PST) Received: by igbxm8 with SMTP id xm8so22064528igb.1 for ; Fri, 13 Nov 2015 12:46:48 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.50.61.232 with SMTP id t8mr5314265igr.16.1447447608559; Fri, 13 Nov 2015 12:46:48 -0800 (PST) Received: by 10.107.181.78 with HTTP; Fri, 13 Nov 2015 12:46:48 -0800 (PST) In-Reply-To: <563AA676.4060106@gmx.net> References: <563AA676.4060106@gmx.net> Date: Fri, 13 Nov 2015 12:46:48 -0800 X-Gmail-Original-Message-ID: Message-ID: From: Aaron Parecki To: "oauth@ietf.org" , Hannes Tschofenig Content-Type: multipart/alternative; boundary=047d7bdc05e88a1c5605247228aa Archived-At: Subject: Re: [OAUTH-WG] OAuth Device Flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2015 20:46:52 -0000 --047d7bdc05e88a1c5605247228aa Content-Type: text/plain; charset=UTF-8 In reading this over, I noticed a subtle difference from the Facebook and Google implementations, and I'm wondering if this was intentional or not. Section 3.1 says "The authorization server prompts the end-user to authorize the client's request by entering the end-user code provided by the client." The introduction has even more explicitly different wording: "(D) ... If the end-user agrees to the client's access request, the end-user enters the end-user code provided by the client." However this is different from Facebook and Google's implementations, which work as follows: - Device shows the verification URI and code to the user - The user visits the URL and is prompted to sign in to the service (Google has the extra step of then choosing which Youtube account to use) - The user is then prompted to enter the device code - After entering the device code, the authorization prompt is displayed In reading this draft, the implication is that the act of entering the code also is the authorization. The problem is that the server won't know things like the scope or application name until after the code is entered, so it can't properly show an authorization prompt. I think this needs to be reworded to separate entering the code from showing the authorization prompt. I believe it is only a wording change. Maybe something more like: 3.1 "The authorization server prompts the end-user to enter the end-user code provided by the client, after which it prompts the end-user to authorize the client's request." and in the introduction: 1. (D) "The authorization server authenticates the end-user (via the user-agent) and prompts the end-user to enter the end-user code provided by the client. The authorization server validates the end-user code and prompts the end-user to grant the client's access request." ---- Aaron Parecki aaronparecki.com @aaronpk On Wed, Nov 4, 2015 at 4:44 PM, Hannes Tschofenig wrote: > FYI: A couple of us got together and re-published an old, expired draft > about the OAuth Device Flow. > > Here is the document: > https://tools.ietf.org/html/draft-denniss-oauth-device-flow-00 > > For the -00 version we tired to keep it inline with what has been > available with draft-recordon-oauth-v2-device-00. In upcoming versions > of this document we would like to capture existing deployment. > > Here are two deployment examples that are reasonably well described: > > - Google > https://developers.google.com/youtube/v3/guides/auth/devices > > - Facebook > https://developers.facebook.com/docs/facebook-login/for-devices > > Ciao > Hannes > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --047d7bdc05e88a1c5605247228aa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
In reading this over, I noticed a subtle difference from t= he Facebook and Google implementations, and I'm wondering if this was i= ntentional or not.

Section 3.1 says "The authorizat= ion server prompts the end-user to authorize the client's request by en= tering the end-user code provided by the client." The introduction has= even more explicitly different wording: "(D) ... If the end-user agre= es to the client's access request, the end-user enters the end-user cod= e provided by the client."

However this is di= fferent from Facebook and Google's implementations, which work as follo= ws:
  • Device shows the verification URI and code to the use= r
  • The user visits the URL and is prompted to sign in to the service= (Google has the extra step of then choosing which Youtube account to use)<= /li>
  • The user is then prompted to enter the device code
  • After en= tering the device code, the authorization prompt is displayed
In r= eading this draft, the implication is that the act of entering the code als= o is the authorization. The problem is that the server won't know thing= s like the scope or application name until after the code is entered, so it= can't properly show an authorization prompt.

= I think this needs to be reworded to separate entering the code from showin= g the authorization prompt. I believe it is only a wording change. Maybe so= mething more like:

3.1 "The authorization ser= ver prompts the end-user to enter the end-user code provided by the client,= after which it prompts the end-user to authorize the client's request.= "

and in the introduction:

1. (D) "The authorization server authenticates the end-user (vi= a the user-agent) and prompts the end-user to enter the end-user code provi= ded by the client. The authorization server validates the end-user code and= prompts the end-user to grant the client's access request."
=

----
Aaron Parecki

On Wed, Nov 4, 2015 at 4:44 PM, Hannes Tscho= fenig <hannes.tschofenig@gmx.net> wrote:
FYI: A couple of us got together and re-published an= old, expired draft
about the OAuth Device Flow.

Here is the document:
https://tools.ietf.org/html/draft-denn= iss-oauth-device-flow-00

For the -00 version we tired to keep it inline with what has been
available with draft-recordon-oauth-v2-device-00. In upcoming versions
of this document we would like to capture existing deployment.

Here are two deployment examples that are reasonably well described:

- Google
https://developers.google.com/youtube/v3= /guides/auth/devices

- Facebook
https://developers.facebook.com/docs/= facebook-login/for-devices

Ciao
Hannes


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


--047d7bdc05e88a1c5605247228aa-- From nobody Fri Nov 13 14:02:22 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67C0D1B3328 for ; Fri, 13 Nov 2015 14:02:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pwrc5m-TPrdj for ; Fri, 13 Nov 2015 14:02:19 -0800 (PST) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3F991B306A for ; Fri, 13 Nov 2015 14:02:18 -0800 (PST) Received: by ioc74 with SMTP id 74so111077078ioc.2 for ; Fri, 13 Nov 2015 14:02:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki_com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zlvnyYLylz4RZwMYMqIHojX2fvWttGY/sH5L5J+ogJA=; b=gifFwZ6m6+21mewX5VftnD1mHXYn7xD2ZmTmVOu8M4bT/6bvC9p3urOERFLSJdKfcC WpF824G6O5WJ3pDewlonXeT7yn2qf3fXeyta885exzutQaSlToFlXoDO1rJLeRseWUaV vtGinzF1/wN1DwO1E1gvsxVS5VOajlpbpUMqLCrtNethqlFcI00rklprPvfdYXjBBdFx A/7vMYNv7f/boe++BLNdXnC+JFoj8cfVVL1DWIsfqgS969+I+QCgG01ODRgZiQ5GaJlm YavrFNCaUgXO7r5XHIn+7cWrb2ADyxgIwMIHF9PuJyoXMD8Iabt0SfEQ8MRqOh68tu6O d/4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=zlvnyYLylz4RZwMYMqIHojX2fvWttGY/sH5L5J+ogJA=; b=VdVRXiLvB9iA0ZUlrPkFtOGqSFlDjsKP4aKsQreaiqOv+gehwDUFR5g9M4rJcv1t8u B+GFEiZuV+hY4N5wKZJRhamLsJEb5om91L/UOIZebWjPT08JrABVdsZUXGISYlQeqn8a Wue4bDH2bMuCLH3cy7YrLBqQ4lV86CzS10jDXd/KDhI4cM7H6n+r5vvT6f4K1XuNJMIr ItIaJ5loLGodpj4lNpveQ9s+18jyer+AD9DqJt0wjV8ukYgdcbDWP7RY+fERm3aVVoV9 +DL282oQc650u9ifvEW2IPl0UFg169G4uoLs6qPImpQ0i2XKu3G+SQjorb7kLEsYmJd9 ickQ== X-Gm-Message-State: ALoCoQmAOxt4F1VpYhSVyKe7VAhcBNmJc2G38O8ztcLcxjgTyDsH8b4xIABALyHmT9wdUwdMT3/W X-Received: by 10.107.3.42 with SMTP id 42mr22588001iod.83.1447452138269; Fri, 13 Nov 2015 14:02:18 -0800 (PST) Received: from mail-ig0-f173.google.com (mail-ig0-f173.google.com. [209.85.213.173]) by smtp.gmail.com with ESMTPSA id b81sm7552192ioj.30.2015.11.13.14.02.17 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Nov 2015 14:02:17 -0800 (PST) Received: by igl9 with SMTP id 9so25162407igl.0 for ; Fri, 13 Nov 2015 14:02:17 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.50.43.225 with SMTP id z1mr5594431igl.19.1447452137181; Fri, 13 Nov 2015 14:02:17 -0800 (PST) Received: by 10.107.181.78 with HTTP; Fri, 13 Nov 2015 14:02:17 -0800 (PST) In-Reply-To: <563AA676.4060106@gmx.net> References: <563AA676.4060106@gmx.net> Date: Fri, 13 Nov 2015 14:02:17 -0800 X-Gmail-Original-Message-ID: Message-ID: From: Aaron Parecki To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=089e010d8dd6775deb0524733668 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth Device Flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2015 22:02:20 -0000 --089e010d8dd6775deb0524733668 Content-Type: text/plain; charset=UTF-8 I just noticed a typo, section 3.2 should refer to RFC6749 section 4.1.3 instead of 4.1.1 https://tools.ietf.org/html/draft-denniss-oauth-device-flow-00#section-3.2 Section 4.1.1 is the authorization request, 4.1.3 is the access token request which I believe is what's supposed to be referenced. ---- Aaron Parecki aaronparecki.com @aaronpk On Wed, Nov 4, 2015 at 4:44 PM, Hannes Tschofenig wrote: > FYI: A couple of us got together and re-published an old, expired draft > about the OAuth Device Flow. > > Here is the document: > https://tools.ietf.org/html/draft-denniss-oauth-device-flow-00 > > For the -00 version we tired to keep it inline with what has been > available with draft-recordon-oauth-v2-device-00. In upcoming versions > of this document we would like to capture existing deployment. > > Here are two deployment examples that are reasonably well described: > > - Google > https://developers.google.com/youtube/v3/guides/auth/devices > > - Facebook > https://developers.facebook.com/docs/facebook-login/for-devices > > Ciao > Hannes > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --089e010d8dd6775deb0524733668 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I just noticed a typo, section 3.2 should refer to RFC6749= section 4.1.3 instead of 4.1.1

https://tool= s.ietf.org/html/draft-denniss-oauth-device-flow-00#section-3.2

Section 4.1.1 is the authorization request, 4.1.3 is t= he access token request which I believe is what's supposed to be refere= nced.=C2=A0

----
Aaron Parecki
aaronparecki.com


On Wed, Nov 4, 2015 at 4:44 PM, Hannes Tscho= fenig <hannes.tschofenig@gmx.net> wrote:
FYI: A couple of us got together and re-published an= old, expired draft
about the OAuth Device Flow.

Here is the document:
https://tools.ietf.org/html/draft-denn= iss-oauth-device-flow-00

For the -00 version we tired to keep it inline with what has been
available with draft-recordon-oauth-v2-device-00. In upcoming versions
of this document we would like to capture existing deployment.

Here are two deployment examples that are reasonably well described:

- Google
https://developers.google.com/youtube/v3= /guides/auth/devices

- Facebook
https://developers.facebook.com/docs/= facebook-login/for-devices

Ciao
Hannes


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


--089e010d8dd6775deb0524733668-- From nobody Sun Nov 15 10:41:23 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 543D81A8A09 for ; Sun, 15 Nov 2015 10:41:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZZS8Ay41_r2d for ; Sun, 15 Nov 2015 10:41:20 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BDF91A8A0D for ; Sun, 15 Nov 2015 10:41:19 -0800 (PST) Received: from [192.168.10.139] ([80.92.121.34]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MRXVc-1Zn0gX3jmi-00SgtS; Sun, 15 Nov 2015 19:41:02 +0100 To: William Denniss , =?UTF-8?Q?Erik_Wahlstr=c3=b6m_neXus?= References: <53BB1987-979C-4945-9C7D-CDB6619AEFFC@nexusgroup.com> <5644EC40.4010002@tzi.org> <73929C18-A3E7-4ACA-A6DC-5A7AD7576C9B@nexusgroup.com> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <5648D1BA.4050109@gmx.net> Date: Sun, 15 Nov 2015 19:40:58 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="v45I75QNUTv0ruRI9p7HAqSNBwwrE7ebv" X-Provags-ID: V03:K0:aWpJU2nX6Dg3ODin2pSzRuBaAl+4QBVV7Eiw/ySTuhmnCxrvQmC cBMaijuXLTQtq0d3ngP2sBq9YPGMaQUR35VAeJzdECut2v32w1H+H/OvqjE+gUYoqqictky 26p//8eQF42ag34rwxDfhrTpXyfpJKZmhqOxI5LU9DVOvQMAL4D+aJkhC7cz63NCs54bgM3 iXiIbGUj5fh413fQSwcQQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:0XtVYMZjSZU=:diIV5ujH9+ZbE8puMt3mrt WXFSSvrKH3servB7U9CE53b+HeoihJVLxbeS6lkyiu1+s7M5z3kE0kDDQJnvbMKvm/5Z2TGvY CI/WXKiKmolh4hSlygQtilobIVzEqPyMh6Ur4a/xkkRQf5n8sSMXjuOWGcdPXGwsE3yAnuVJe 2NiZCdIIi9O0RhGGkQTTUaBckh+kYzYP7OEKqPejxhBKYVmEOY5GbI70zOOAacTms038lCqR2 JkKFof6qV2EjC5/MdZFXsWXtWDjqhGrW6GMHxQds08AH4zpnQzF7wGabrMcukNSoeHpo92Bn8 OGpa4jKrtnTV79qJOIF+bq36XzoFD/UJcjYHZhUdS+0qfJ2KHCuoH47J/arRZ3KWly0Wj56DE oc3rf73XSvHNjKx/dm0A6zPpN29FOQWS0qpCdRzh5sYZGAjcBGqOf4sFHonBGAZDp6p3PTz+F nTgDeyxNkvV4GPj/j0ooPUCe37Zv6XYOljANvg2M39poCh+cVzrwyuy0rXlWUi2BrGBVM82WR DiVpMcSRmooMx77GPWuN6T/ok1/8fZC1IPDzBzIQmSjmfybE2hcJ+vhBnhtye0/mvEPmXBSTT Rz3apQDmjOBYadoOTx1OR7JaRkqFSr44c2gwyoVKadzHjqJ3XjfVVah1svxZifw3Yf3CsMV5o 4ya7nMOE+KOuznDMk5CVlSsVNsQfzdqZ00brIFHTnvjfct1QvgqMR+deGX6qohq2ZiF06g+8G SrTE+9IH0TWRtmQCSfrfyF90Ttus6WfCi2mrRiTU/2gqgFvJIRt9JALlg0E= Archived-At: Cc: Hannes Tschofenig , Carsten Bormann , "" Subject: Re: [OAUTH-WG] [Ace] [COSE] A draft on CBOR Web Tokens (CWT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2015 18:41:22 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --v45I75QNUTv0ruRI9p7HAqSNBwwrE7ebv Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable [only posting to OAuth list] Hi William, thanks for your quick review comments. On 11/13/2015 04:19 AM, William Denniss wrote: > Regarding the draft itself, a few comments: >=20 > 1.=20 > Can we unify the claim registry with JWT? I'm worried about having the > same claims defined twice in CWT and JWT with possibly conflicting > meanings (and needless confusion even when they do match).=20 >=20 > Comparing https://tools.ietf.org/html/draft-wahlstroem-oauth-cbor-web-t= oken-00#section-3.1.2 > and https://tools.ietf.org/html/rfc7519#section-4.1.2 which are nearly > identical, I just don't see the value in re-defining it. >=20 > We may add new standard claims to JWT in the future (I proposed one > in > Yokohama on the id-event list > ), it would be good if > this didn't need a separate entry in CWT too, but could just apply > directly (separately, I think you should consider this claim, as it > helps prevent tokens from being re-used in the wrong context). >=20 For this IANA registry issue we have essentially two options: a) Single registry: JWT and CWT claims listed in the same registry b) Separate registries for JWT claims and for CWT claims. The drawback about using two registries is the additional effort in registering many, if not all, claims twice (with the potential risk to get them misaligned). The advantage is to avoid confusion when some entries are only applicable to the CWT or the JWT registry, respectively.= Note that we had the same question with regard to the token introspection registry* where I argued that we should use a single registry and we ended up defining two registries in the end. In this specific case I believe there is value in using one registry only since I don't see a reason for web and smart phone apps not using the CBOR-based encoding. During the last few years I witnessed a lot of activities that aimed to reduce the message size of protocols used in the mobile space. (*): I believe that Erik should update his token introspection draft (see https://tools.ietf.org/html/draft-wahlstroem-ace-oauth-introspection-01) by registering the CWT claims to the token introspection defined registry= =2E > 2. > Is Section 4 "Summary of CBOR major types used by defined claims" > normative > (https://tools.ietf.org/html/draft-wahlstroem-oauth-cbor-web-token-00#s= ection-4)? > What is the intention of this section? I feel like it could probably be= > fleshed out a bit. Maybe that section is not well motivated and should rather be placed into the IANA consideration section instead. All it does is to summarizes the CBOR-relevant information into a table. >=20 > 3.=20 > Add a xref to draft COSE spec in section 6 > > Add xref to RFC7519 Missing references will be fixed. Ciao Hannes >=20 > On Thu, Nov 12, 2015 at 12:01 PM, Erik Wahlstr=F6m neXus > > > wrote: >=20 > Hi Carsten, >=20 > Thanks, and I agree. I=92ve heard arguments for all three work grou= ps. >=20 > Borrowed some of your words to define the content of the draft :) > It=92s it essentially a JWT, phrased in and profiled for CBOR to > address ACE needs, where OAuth needs COSE functionality, for object= > security. >=20 > I=92m open for letting the AD=92s move it around, but having it rig= ht > next to JWT seems right to me. Also open for the ACE WG. Feel it ha= s > less place in COSE for the same reasons JWT is not in the JOSE WG. >=20 > / Erik >=20 >=20 > > On 12 Nov 2015, at 20:45, Carsten Bormann > wrote: > > > > Hi Erik, > > > > having this draft is a good thing. > > > > One thing I'm still wondering is what WG is the best place to pro= gress > > this. We probably don't need to spend too much time on this beca= use, > > regardless of the WG chosen, the people in another WG can look at= it. > > Still, getting this right might provide some efficiencies. > > > > What is the technical content of this draft? Is it a new token t= hat > > OAuth needs specifically for the new COSE-based applications of O= Auth? > > Is it a new token that is specifically there for addressing ACE n= eeds? > > Or is it essentially the same substance as JWT, but phrased in an= d > > profiled for CBOR? > > > > Depending on the answer, CWT should be done in OAuth, ACE, or COS= E. > > (I'd rather hear the answer from the authors than venture a guess= > myself.) > > > > Gr=FC=DFe, Carsten > > > > > > > > Erik Wahlstr=F6m neXus wrote: > >> Hi, > >> > >> In the ACE WG a straw man proposal of a CBOR Web Token (CWT) was= > defined > >> in the draft "Authorization for the Internet of Things using > OAuth 2.0=94 > >> [1]. We just broke out the CBOR Web Token into a separate draft > and the > >> new draft is submitted to the OAUTH WG. It can be found here: > >> > >> > https://datatracker.ietf.org/doc/draft-wahlstroem-oauth-cbor-web-to= ken/ > >> > >> Abstract: > >> "CBOR Web Token (CWT) is a compact means of representing claims = to be > >> transferred between two parties. CWT is a profile of the JSON > Web Token > >> (JWT) that is optimized for constrained devices. The claims in a= > CWT are > >> encoded in the Concise Binary Object Representation (CBOR) and C= BOR > >> Object Signing and Encryption (COSE) is used for added > application layer > >> security protection. A claim is a piece of information asserted= > about a > >> subject and is represented as a name/value pair consisting of a = claim > >> name and a claim value." > >> > >> / Erik > >> > >> > >> [1] https://tools.ietf.org/html/draft-seitz-ace-oauth-authz-00 > >> > >> > >> _______________________________________________ > >> COSE mailing list > >> COSE@ietf.org > >> https://www.ietf.org/mailman/listinfo/cose >=20 > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose >=20 >=20 >=20 >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace >=20 --v45I75QNUTv0ruRI9p7HAqSNBwwrE7ebv Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJWSNG7AAoJEGhJURNOOiAtJrIH/iVNVVmvbBKdsJArHtg9MT24 0H0uoeTggVazTlOonxxGh2kFRE3t/AcLKzn27w7PyqINl2Io/NW7zNvJYHyR1ob+ x5PIGB84ouQcEs6j5cHr8c9CxGvssj9F5Pzx5rxYYdDM7Bo1cB+XDn91wlba8mjX RTB2wtmwkxIUqFho4mqOnnw1NhCi3DncGBdBo3TZHv8LxVolBgGWnBrGpgagJxAg xyiXWqXSlFZe2MeEgzNTlYkWnydhG9Nwh63btKeckF1oAEMGxU110p7yBKnwCSsm 4/NrGC5u2WU4LSi/377Wr3NHb3LtfqxtoCYSO+GaVO24yafyqpf/yI551RO05K8= =Mvyf -----END PGP SIGNATURE----- --v45I75QNUTv0ruRI9p7HAqSNBwwrE7ebv-- From nobody Mon Nov 16 06:56:29 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C24BA1B307A for ; Mon, 16 Nov 2015 06:56:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.485 X-Spam-Level: X-Spam-Status: No, score=-0.485 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ipcz0MdtsrER for ; Mon, 16 Nov 2015 06:56:25 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B1051B3078 for ; Mon, 16 Nov 2015 06:56:25 -0800 (PST) Received: from [192.168.10.140] ([80.92.121.34]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MEXHd-1a92aP19s9-00Fgsm for ; Mon, 16 Nov 2015 15:56:23 +0100 From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 To: "oauth@ietf.org" Message-ID: <5649EE61.8060803@gmx.net> Date: Mon, 16 Nov 2015 15:55:29 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="LLcCluxa4VWwsX9P8L9QqmHupJIGGjDA3" X-Provags-ID: V03:K0:wHVCpoQCzSbajMJWnm82i1R30Z3Gg1KnubtxZadz7irlIlm1QNL iWTyZOkw2mqYCzdeMXzLef8VuHM6wbAEoCsnWzWetvMQY9Hs0WgV5r/JOLI2fIZfYN4zsjp GL8ryignd2hrhlh4vl/4/1d+JsXfyvHq4ZP5jzu5iSLPctcoSJs//f0VETNKKnavATyfMvp IrMB3uMkPgNjEtdc6zsug== X-UI-Out-Filterresults: notjunk:1;V01:K0:QvHppJRO02g=:VaiQYxax4+TxmSD2omHBe5 p2ZMK1wSq2o98+g7KQRvO1kxDPHxPfebQs1f3Xw8enZ4p2JG2vCQGTKLpNAaD2KxnbX7q75Bk Qsl0dyQ04zsvgbBbp985ZH//q7v1VXaX/IHvKZ4buK/yX2XrKEl52NLitJCUnps7S6foXldsh eT9naCNzWuAEDvjTc66JEd42Wp5cMXRY0Zpw5CpCXQJqIQ1uJcnCu2lq9ic3Bh+ghcL/sTWZZ ehyoY1d/W3ciwQt79VsATvMd3/0/Z8N3FfSL2DuQ6HZzRVvXjyHUNlqDNonHl47Sr433fM7jh pQDQANpiFuph7jOW6Qhob4EZzp/eMFn0h7Ma/CX7gihoW4VRgeO92IbOnLvk9VFxpo98gna0O swpQ4tJmpFQA6A1j/eRymA8rfa/wE+/OsiKKM/KlNzsZ6bUnEhuWMPB/8OIvnXuq3ijMGXdg3 KXf/gfIt8kQUb50afYeFX0AvP553VU+jy7pRm8KjlQzt8Bi8d8ordVI2vrfEd/UKAjbsNQPWF 1WKKo4LQ8nctJ7TSjkbMX2NU2QU+xoA7Q5g30FHybTdks4R6a6bPSD/yk9UoosKQY1TpN//aT Wxck9rxN9y7dnbqk0OqzxR5axpy3sMxISAYtmGJpE8DPy+Gfw2wp592e7nlQd7kzh0wlb3Kj4 YguZnL6rmejb+S0r0dOKdRq5pUgMlxdvrqHzD8RJ+OJbcNyDYAc0AECyavrDooFEFjWC5X0DV EE7Xp7I7TDjjdbqIzHNbNW9jWP1GdVDg5YXrbbVfobIcMBMaJydauRBjCqU= Archived-At: Subject: [OAUTH-WG] draft-ietf-oauth-proof-of-possession-06 Glitches X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2015 14:56:27 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --LLcCluxa4VWwsX9P8L9QqmHupJIGGjDA3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, I noticed a few glitches with the most recent version of the draft-ietf-oauth-proof-of-possession document. ** PoP Figure (Symmetric Key) FROM: +--------------+ | | +--------------+ | |--(4) Presentation of -->| | | | JWT w/ Encrypted | | | Presenter | PoP Key | | | | | | | |<-(5) Communication ---->| | | | Authenticated by | | +--------------+ PoP Key | | | ^ | | | | | | (1) Sym. (3) JWT w/ | Recipient | | PoP | Encrypted | | | Key | PoP Key | | v | | | +--------------+ | | | | | | | | | | | |<-(2) Key Exchange for ->| | | Issuer | Key Encryption Key | | | | | | | | | | | | +--------------+ +--------------+ Figure 1: Proof-of-Possession with a Symmetric Key TO: +--------------+ | | +--------------+ | |--(3) Presentation of -->| | | | JWT w/ Encrypted | | | Presenter | PoP Key | | | | | | | |<-(4) Communication ---->| | | | Authenticated by | | +--------------+ PoP Key | | | ^ | | | | | | (1) Sym. (2) JWT w/ | Recipient | | PoP | Encrypted | | | Key | PoP Key | | v | | | +--------------+ | | | | | | | | | | | |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D>| | | Issuer | Key Exchange for | | | | Key Encryption Key | | | | | | | | +--------------+ +--------------+ Figure 1: Proof-of-Possession with a Symmetric Key The reason for this change is that the figure currently included in the document gives the impression that the key used to protect the PoP token is actually dynamically exchanged in step (2), which isn't the case. While text says that it is dynamically established if it does not exist there is nothing in this or any document that provides this functionality= =2E Hence, I am also suggesting to change the text accordingly: FROM: This symmetric key is encrypted with a key known only to the issuer and the recipient, which is established in step (2), if it doesn't already exist. TO: This symmetric key is encrypted with a key known only to the issuer and the recipient. The problem with dynamically establishing keys is that we are then requiring yet another key to be in place to allow this procedure to happen securely. Without anything in place we are quickly vulnerable to various attacks. FROM: In the case illustrated in Figure 1, the presenter generates a symmetric key and (1) privately sends it to the issuer. TO: In the case illustrated in Figure 1, the presenter generates a symmetric key and in (1) sends it to the issuer. The key transport is confidentiality protected. ** CNF Claim I also have a question regarding this paragraph from Section 3.1. What does it mean to have other members of the "cnf" claim? What is the semantic of these two examples: { "iss": "https://server.example.com", "aud": "https://client.example.org", "exp": "1361398824", "cnf":{ "jwk":{...}, "jwk":{...} } } { "iss": "https://server.example.com", "aud": "https://client.example.org", "exp": "1361398824", "cnf":{ "jwk":{...}, "jwe":{...}, "kid":"..." } } Here is the relevant text: " 3.1. Confirmation Claim The "cnf" (confirmation) claim is used in the JWT to contain members used to identify the proof-of-possession key. Other members of the "cnf" object may be defined because a proof-of-possession key may not be the only means of confirming the authenticity of the token. This is analogous to the SAML 2.0 [OASIS.saml-core-2.0-os] SubjectConfirmation element, in which a number of different subject confirmation methods can be included, including proof-of-possession key information. When a recipient receives a "cnf" claim with a member that it does not understand, it MUST ignore that member. =2E.. Note that if an application needs to represent multiple proof-of- possession keys in the same JWT, one way for it to achieve this is to use other claim names, in addition to "cnf", to hold the additional proof-of-possession key information. These claims could use the same syntax and semantics as the "cnf" claim. " ** Key ID Lack of interoperability for the Key ID functionality described in Section 3.4. The text says that "The content of the "kid" value is application specific. For instance, some applications may choose to use a JWK Thumbprint [JWK.Thumbprint] value as the "kid" value." I think we should settle for something and then allow other key id types to be used as well. ** Nonce Claim This example in Section 3.3 uses a claim type, namely nonce, which has not been defined yet. I therefore suggest to remove it from this example since it does not fulfil a purpose. Here is the example: { "iss": "https://server.example.com", "sub": "24400320", "aud": "s6BhdRkqt3", "nonce": "n-0S6_WzA2Mj", "exp": 1311281970, "iat": 1311280970, "cnf":{ "jwe": "eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkExMjhDQkMtSFMyNTYifQ. (remainder of JWE omitted for brevity)" } } Ciao Hannes --LLcCluxa4VWwsX9P8L9QqmHupJIGGjDA3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJWSe6FAAoJEGhJURNOOiAt1ZcH/11652jHaMnimNJTvqjX1e0h kIZsTUM/sN7rbdrzk+eGu4i77/DOmXSIRkgc+eKQw28YacvVn1SKJfUJhq9SxZ7y fDEWV9hdWcxCFEqSIpdEiVE70/QPFAf2q+82PINO9OTB+/Zg4Y9mVkVWDNRT/8ny 7gUkANv5bGJsdsJN+z9bdqXaudlUcsSBREivTVs8pKu/Y4kvj9ablMi/S6gEl6jr EILbn4DLO2xiT621OUOYox3Cf11RRBFkh87Dm89OAXOTducLvMPHijOxa1Jg2O4V Za6+rwsHKEt7SpxxRS2XTBpFS4kGc1snvx+65ZffJaGfRLLp0Bbai+14bFvjm/g= =h1Zq -----END PGP SIGNATURE----- --LLcCluxa4VWwsX9P8L9QqmHupJIGGjDA3-- From nobody Mon Nov 16 11:24:20 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58F1E1A00ED for ; Mon, 16 Nov 2015 07:09:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.5 X-Spam-Level: X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lp-KSCQcZlIF for ; Mon, 16 Nov 2015 07:09:31 -0800 (PST) Received: from eu-smtp-delivery-143.mimecast.com (eu-smtp-delivery-143.mimecast.com [146.101.78.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 513951A0193 for ; Mon, 16 Nov 2015 07:09:18 -0800 (PST) Received: from emea-cam-gw2.Emea.Arm.com (fw-tnat.cambridge.arm.com [217.140.96.140]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-27-O4SaY608SBOGF6vWFm5ALQ-2; Mon, 16 Nov 2015 15:09:15 +0000 Received: from GB-CAM-EXCAS1.Emea.Arm.com (10.1.105.66) by emea-cam-gw2.Emea.Arm.com (10.1.105.150) with Microsoft SMTP Server (TLS) id 8.3.298.1; Mon, 16 Nov 2015 15:09:13 +0000 Received: from emea01-db3-obe.outbound.protection.outlook.com (10.1.2.79) by nebula.arm.com (10.1.105.66) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 16 Nov 2015 15:09:13 +0000 Received: from HE1PR08MB0732.eurprd08.prod.outlook.com (10.163.179.30) by HE1PR08MB0730.eurprd08.prod.outlook.com (10.163.179.28) with Microsoft SMTP Server (TLS) id 15.1.325.17; Mon, 16 Nov 2015 15:09:11 +0000 Received: from HE1PR08MB0732.eurprd08.prod.outlook.com ([10.163.179.30]) by HE1PR08MB0732.eurprd08.prod.outlook.com ([10.163.179.30]) with mapi id 15.01.0325.003; Mon, 16 Nov 2015 15:09:11 +0000 From: Hannes Tschofenig To: William Denniss , =?utf-8?B?RXJpayBXYWhsc3Ryw7ZtIG5lWHVz?= Thread-Topic: [COSE] A draft on CBOR Web Tokens (CWT) Thread-Index: AQHRHX3DyXQEi0Hb60mPSXqbnVxSe56YykQAgAAEkACAAHpjAIAFe1lw Date: Mon, 16 Nov 2015 15:09:11 +0000 Message-ID: References: <53BB1987-979C-4945-9C7D-CDB6619AEFFC@nexusgroup.com> <5644EC40.4010002@tzi.org> <73929C18-A3E7-4ACA-A6DC-5A7AD7576C9B@nexusgroup.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [80.92.121.34] x-microsoft-exchange-diagnostics: 1; HE1PR08MB0730; 5:zsLpV810HrYIlFEbc+gaazc8LAeWJhPAK8msUfEEpaKzntbH+w15wv53eh+W3CMAuIpMmGDhdnq+gq8RCCIM30W4/Z9aNZFcJynqG3MAGaLwPGNEJ1uQOt2B5Mclh8aVkubu/oDDOYvydJSafFp1YA==; 24:iATUBuE7ZV3GOwJKQKjivQUUxBwXlqqQbYJJ6Ths8vYqnyyFzvH9V5qrdfporsxymUE7oJLMsuyNP4arqjq7QL7LMxpt5TYMcPQ+CRIAQoI=; 20:1a9eERRguwhKXYwNwF+h3BcHJV+8bs3YlksTcokDmUPtVFMwbRiInezgwjGlw10Ko4K97Y/js1MuzgfkBtDHTySa3fzwQX5sAjsdewYBgEU3E94WlR4mE0blLBORbyF+xnwKA06cLC9d5GptK7sw+vp09IjILkUyMI4XJK0Tytw= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR08MB0730; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(211936372134217)(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(520078)(3002001)(10201501046); SRVR:HE1PR08MB0730; BCL:0; PCL:0; RULEID:; SRVR:HE1PR08MB0730; x-forefront-prvs: 0762FFD075 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(164054003)(199003)(24454002)(189002)(377454003)(74316001)(54356999)(10400500002)(189998001)(40100003)(5007970100001)(11100500001)(5003600100002)(50986999)(122556002)(76176999)(66066001)(5001770100001)(87936001)(105586002)(97736004)(86362001)(5001960100002)(106116001)(77096005)(76576001)(19625215002)(19580395003)(101416001)(5004730100002)(16236675004)(19580405001)(33656002)(93886004)(561944003)(586003)(102836002)(5008740100001)(5002640100001)(19300405004)(15975445007)(106356001)(92566002)(81156007)(2900100001)(19617315012)(2950100001); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR08MB0730; H:HE1PR08MB0732.eurprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Nov 2015 15:09:11.5597 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR08MB0730 X-OriginatorOrg: arm.com X-MC-Unique: O4SaY608SBOGF6vWFm5ALQ-2 Content-Type: multipart/alternative; boundary="_000_HE1PR08MB07324FD345F82CF6EC3AEAE3FA1E0HE1PR08MB0732eurp_" Archived-At: X-Mailman-Approved-At: Mon, 16 Nov 2015 11:24:18 -0800 Cc: Carsten Bormann , "" Subject: Re: [OAUTH-WG] [COSE] A draft on CBOR Web Tokens (CWT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2015 15:09:35 -0000 --_000_HE1PR08MB07324FD345F82CF6EC3AEAE3FA1E0HE1PR08MB0732eurp_ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 SGkgV2lsbGlhbSwNCg0KSSBoYXZlIGJlZW4gdHJ5aW5nIHRvIGRvIGEgZG9jdW1lbnQgdXBkYXRl IHRvIHNlZSBob3cgd2VsbCBhIGNvbWJpbmVkIHJlZ2lzdHJ5IHdvcmtzIGFuZCBJIGhhdmUgYmVl biB3b25kZXJpbmcgd2hldGhlciBpdCBpcyByZWFsbHkgd29ydGggdGhlIGVmZm9ydC4NClRvIG1h a2UgYSBnb29kIGp1ZGdtZW50IEkgbG9va2VkIGF0IHRoZSBDTkYgY2xhaW0gZGVmaW5lZCBpbiBk cmFmdC1pZXRmLW9hdXRoLXByb29mLW9mLXBvc3Nlc3Npb24uIFRoZSBDTkYgY2xhaW0gbWF5IGNv bnRhaW4gc3ViLWVsZW1lbnRzLCBzdWNoIGFzIGEgSldFIG9yIGEgSldLLg0KDQpJZiB3ZSB0cmFu c2xhdGUgdGhlIHNhbWUgbWVjaGFuaXNtcyB0byB0aGUgQ1dUICh3aGljaCBtYWtlcyBzZW5zZSkg dGhlbiB3ZSBuZWVkIHRvIHBvaW50IHRvIHRoZSByZXNwZWN0aXZlIENPU0Ugc3RydWN0dXJlcyBp bnN0ZWFkLiBUaG9zZSBkbyBub3Qgb25seSB1c2UgYSBkaWZmZXJlbnQgZW5jb2RpbmcgYnV0IGFs c28gdGhlIGZ1bmN0aW9uYWxpdHkgZG9lcyBub3QgbWF0Y2ggdGhlIEpPU0Ugc3RydWN0dXJlcyAx MDAlLiBTbywgdGhlcmUgYXJlIHBvdGVudGlhbGx5IGRpZmZlcmVuY2VzLiBJIGFtIGFsc28gbm90 IHN1cmUgd2hldGhlciB3ZSByZWFsbHkgd2FudCB0byB0cmFuc2xhdGUgdGhlIGZ1bGwgZnVuY3Rp b25hbGl0eSBvZiBhbGwgdGhlIGNsYWltcyBmcm9tIEpXVCBvdmVyIHRvIHRoZSBDV1QgZXF1aXZh bGVudC4gSXQgYmFzaWNhbGx5IHB1dHMgdGhlIGJ1cmRlbiBvbiBzb21lb25lIGRlZmluaW5nIG5l dyBjbGFpbXMgKGVpdGhlciBpbiBKV1Qgb3IgaW4gQ1dUKSB0byBjcmVhdGUgdGhlIGNvcnJlc3Bv bmRpbmcgc3RydWN0dXJlcyBpbiBhIGZvcm1hdCB0aGV5IG1heSBub3QgbmVjZXNzYXJpbHkgYmUg ZmFtaWxpYXIgd2l0aCBvciBldmVuIGNhcmUgYWJvdXQuIEkgaGF2ZSBzZWVuIHRoYXQgaGFwcGVu aW5nIGluIHRoZSBSQURJVVMgd29ybGQgcHJvdG9jb2wgZGVzaWduZXJzIGhhZCB0byBhbHNvIGRl ZmluZSB0aGUgZXF1aXZhbGVudCBzdHJ1Y3R1cmVzIGZvciB1c2Ugd2l0aCBEaWFtZXRlciBhbmQs IGd1ZXNzIHdoYXQsIG1vc3Qgb2YgdGhlIGRlZmluaXRpb25zIHdlcmUgd3JvbmcgKHNpbmNlIHRo ZSBhdXRob3JzIGRpZCBub3QgY2FyZSBhYm91dCBEaWFtZXRlciB3aGVuIHdvcmtpbmcgb24gUkFE SVVTKS4NCg0KQ2lhbw0KSGFubmVzDQoNCg0KRnJvbTogV2lsbGlhbSBEZW5uaXNzIFttYWlsdG86 d2Rlbm5pc3NAZ29vZ2xlLmNvbV0NClNlbnQ6IDEyIE5vdmVtYmVyIDIwMTUgMTk6MTkNClRvOiBF cmlrIFdhaGxzdHLDtm0gbmVYdXMNCkNjOiBDYXJzdGVuIEJvcm1hbm47IEhhbm5lcyBUc2Nob2Zl bmlnOyBNaWtlIEpvbmVzOyBjb3NlQGlldGYub3JnOyA8b2F1dGhAaWV0Zi5vcmc+OyBhY2VAaWV0 Zi5vcmcNClN1YmplY3Q6IFJlOiBbQ09TRV0gQSBkcmFmdCBvbiBDQk9SIFdlYiBUb2tlbnMgKENX VCkNCg0KUmVnYXJkaW5nIHRoZSBkcmFmdCBpdHNlbGYsIGEgZmV3IGNvbW1lbnRzOg0KDQoxLg0K Q2FuIHdlIHVuaWZ5IHRoZSBjbGFpbSByZWdpc3RyeSB3aXRoIEpXVD8gSSdtIHdvcnJpZWQgYWJv dXQgaGF2aW5nIHRoZSBzYW1lIGNsYWltcyBkZWZpbmVkIHR3aWNlIGluIENXVCBhbmQgSldUIHdp dGggcG9zc2libHkgY29uZmxpY3RpbmcgbWVhbmluZ3MgKGFuZCBuZWVkbGVzcyBjb25mdXNpb24g ZXZlbiB3aGVuIHRoZXkgZG8gbWF0Y2gpLg0KDQpDb21wYXJpbmcgaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LXdhaGxzdHJvZW0tb2F1dGgtY2Jvci13ZWItdG9rZW4tMDAjc2VjdGlv bi0zLjEuMiBhbmQgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzc1MTkjc2VjdGlvbi00 LjEuMiB3aGljaCBhcmUgbmVhcmx5IGlkZW50aWNhbCwgSSBqdXN0IGRvbid0IHNlZSB0aGUgdmFs dWUgaW4gcmUtZGVmaW5pbmcgaXQuDQoNCldlIG1heSBhZGQgbmV3IHN0YW5kYXJkIGNsYWltcyB0 byBKV1QgaW4gdGhlIGZ1dHVyZSAoSSBwcm9wb3NlZCBvbmU8aHR0cHM6Ly9tYWlsYXJjaGl2ZS5p ZXRmLm9yZy9hcmNoL3NlYXJjaC8/ZW1haWxfbGlzdD1pZC1ldmVudCZnYnQ9MSZpbmRleD03cU5V bmFFOWx0Mkx5YXlNbm1OeVdwWlNJRU0+IGluIFlva29oYW1hIG9uIHRoZSBpZC1ldmVudCBsaXN0 PGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWQtZXZlbnQ+KSwgaXQgd291 bGQgYmUgZ29vZCBpZiB0aGlzIGRpZG4ndCBuZWVkIGEgc2VwYXJhdGUgZW50cnkgaW4gQ1dUIHRv bywgYnV0IGNvdWxkIGp1c3QgYXBwbHkgZGlyZWN0bHkgKHNlcGFyYXRlbHksIEkgdGhpbmsgeW91 IHNob3VsZCBjb25zaWRlciB0aGlzIGNsYWltLCBhcyBpdCBoZWxwcyBwcmV2ZW50IHRva2VucyBm cm9tIGJlaW5nIHJlLXVzZWQgaW4gdGhlIHdyb25nIGNvbnRleHQpLg0KDQoyLg0KSXMgU2VjdGlv biA0ICJTdW1tYXJ5IG9mIENCT1IgbWFqb3IgdHlwZXMgdXNlZCBieSBkZWZpbmVkIGNsYWltcyIg bm9ybWF0aXZlIChodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtd2FobHN0cm9lbS1v YXV0aC1jYm9yLXdlYi10b2tlbi0wMCNzZWN0aW9uLTQpPyBXaGF0IGlzIHRoZSBpbnRlbnRpb24g b2YgdGhpcyBzZWN0aW9uPyBJIGZlZWwgbGlrZSBpdCBjb3VsZCBwcm9iYWJseSBiZSBmbGVzaGVk IG91dCBhIGJpdC4NCg0KMy4NCkFkZCBhIHhyZWYgdG8gZHJhZnQgQ09TRSBzcGVjIGluIHNlY3Rp b24gNjxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtd2FobHN0cm9lbS1vYXV0aC1j Ym9yLXdlYi10b2tlbi0wMCNzZWN0aW9uLTY+DQpBZGQgeHJlZiB0byBSRkM3NTE5DQoNCk9uIFRo dSwgTm92IDEyLCAyMDE1IGF0IDEyOjAxIFBNLCBFcmlrIFdhaGxzdHLDtm0gbmVYdXMgPGVyaWsu d2FobHN0cm9tQG5leHVzZ3JvdXAuY29tPG1haWx0bzplcmlrLndhaGxzdHJvbUBuZXh1c2dyb3Vw LmNvbT4+IHdyb3RlOg0KSGkgQ2Fyc3RlbiwNCg0KVGhhbmtzLCBhbmQgSSBhZ3JlZS4gSeKAmXZl IGhlYXJkIGFyZ3VtZW50cyBmb3IgYWxsIHRocmVlIHdvcmsgZ3JvdXBzLg0KDQpCb3Jyb3dlZCBz b21lIG9mIHlvdXIgd29yZHMgdG8gZGVmaW5lIHRoZSBjb250ZW50IG9mIHRoZSBkcmFmdCA6KQ0K SXTigJlzIGl0IGVzc2VudGlhbGx5IGEgSldULCBwaHJhc2VkIGluIGFuZCBwcm9maWxlZCBmb3Ig Q0JPUiB0byBhZGRyZXNzIEFDRSBuZWVkcywgd2hlcmUgT0F1dGggbmVlZHMgQ09TRSBmdW5jdGlv bmFsaXR5LCBmb3Igb2JqZWN0IHNlY3VyaXR5Lg0KDQpJ4oCZbSBvcGVuIGZvciBsZXR0aW5nIHRo ZSBBROKAmXMgbW92ZSBpdCBhcm91bmQsIGJ1dCBoYXZpbmcgaXQgcmlnaHQgbmV4dCB0byBKV1Qg c2VlbXMgcmlnaHQgdG8gbWUuIEFsc28gb3BlbiBmb3IgdGhlIEFDRSBXRy4gRmVlbCBpdCBoYXMg bGVzcyBwbGFjZSBpbiBDT1NFIGZvciB0aGUgc2FtZSByZWFzb25zIEpXVCBpcyBub3QgaW4gdGhl IEpPU0UgV0cuDQoNCi8gRXJpaw0KDQoNCj4gT24gMTIgTm92IDIwMTUsIGF0IDIwOjQ1LCBDYXJz dGVuIEJvcm1hbm4gPGNhYm9AdHppLm9yZzxtYWlsdG86Y2Fib0B0emkub3JnPj4gd3JvdGU6DQo+ DQo+IEhpIEVyaWssDQo+DQo+IGhhdmluZyB0aGlzIGRyYWZ0IGlzIGEgZ29vZCB0aGluZy4NCj4N Cj4gT25lIHRoaW5nIEknbSBzdGlsbCB3b25kZXJpbmcgaXMgd2hhdCBXRyBpcyB0aGUgYmVzdCBw bGFjZSB0byBwcm9ncmVzcw0KPiB0aGlzLiAgV2UgcHJvYmFibHkgZG9uJ3QgbmVlZCB0byBzcGVu ZCB0b28gbXVjaCB0aW1lIG9uIHRoaXMgYmVjYXVzZSwNCj4gcmVnYXJkbGVzcyBvZiB0aGUgV0cg Y2hvc2VuLCB0aGUgcGVvcGxlIGluIGFub3RoZXIgV0cgY2FuIGxvb2sgYXQgaXQuDQo+IFN0aWxs LCBnZXR0aW5nIHRoaXMgcmlnaHQgbWlnaHQgcHJvdmlkZSBzb21lIGVmZmljaWVuY2llcy4NCj4N Cj4gV2hhdCBpcyB0aGUgdGVjaG5pY2FsIGNvbnRlbnQgb2YgdGhpcyBkcmFmdD8gIElzIGl0IGEg bmV3IHRva2VuIHRoYXQNCj4gT0F1dGggbmVlZHMgc3BlY2lmaWNhbGx5IGZvciB0aGUgbmV3IENP U0UtYmFzZWQgYXBwbGljYXRpb25zIG9mIE9BdXRoPw0KPiBJcyBpdCBhIG5ldyB0b2tlbiB0aGF0 IGlzIHNwZWNpZmljYWxseSB0aGVyZSBmb3IgYWRkcmVzc2luZyBBQ0UgbmVlZHM/DQo+IE9yIGlz IGl0IGVzc2VudGlhbGx5IHRoZSBzYW1lIHN1YnN0YW5jZSBhcyBKV1QsIGJ1dCBwaHJhc2VkIGlu IGFuZA0KPiBwcm9maWxlZCBmb3IgQ0JPUj8NCj4NCj4gRGVwZW5kaW5nIG9uIHRoZSBhbnN3ZXIs IENXVCBzaG91bGQgYmUgZG9uZSBpbiBPQXV0aCwgQUNFLCBvciBDT1NFLg0KPiAoSSdkIHJhdGhl ciBoZWFyIHRoZSBhbnN3ZXIgZnJvbSB0aGUgYXV0aG9ycyB0aGFuIHZlbnR1cmUgYSBndWVzcyBt eXNlbGYuKQ0KPg0KPiBHcsO8w59lLCBDYXJzdGVuDQo+DQo+DQo+DQo+IEVyaWsgV2FobHN0csO2 bSBuZVh1cyB3cm90ZToNCj4+IEhpLA0KPj4NCj4+IEluIHRoZSBBQ0UgV0cgYSBzdHJhdyBtYW4g cHJvcG9zYWwgb2YgYSBDQk9SIFdlYiBUb2tlbiAoQ1dUKSB3YXMgZGVmaW5lZA0KPj4gaW4gdGhl IGRyYWZ0ICJBdXRob3JpemF0aW9uIGZvciB0aGUgSW50ZXJuZXQgb2YgVGhpbmdzIHVzaW5nIE9B dXRoIDIuMOKAnQ0KPj4gWzFdLiBXZSBqdXN0IGJyb2tlIG91dCB0aGUgQ0JPUiBXZWIgVG9rZW4g aW50byBhIHNlcGFyYXRlIGRyYWZ0IGFuZCB0aGUNCj4+IG5ldyBkcmFmdCBpcyBzdWJtaXR0ZWQg dG8gdGhlIE9BVVRIIFdHLiBJdCBjYW4gYmUgZm91bmQgaGVyZToNCj4+DQo+PiBodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC13YWhsc3Ryb2VtLW9hdXRoLWNib3Itd2ViLXRv a2VuLw0KPj4NCj4+IEFic3RyYWN0Og0KPj4gIkNCT1IgV2ViIFRva2VuIChDV1QpIGlzIGEgY29t cGFjdCBtZWFucyBvZiByZXByZXNlbnRpbmcgY2xhaW1zIHRvIGJlDQo+PiB0cmFuc2ZlcnJlZCBi ZXR3ZWVuIHR3byBwYXJ0aWVzLiAgQ1dUIGlzIGEgcHJvZmlsZSBvZiB0aGUgSlNPTiBXZWIgVG9r ZW4NCj4+IChKV1QpIHRoYXQgaXMgb3B0aW1pemVkIGZvciBjb25zdHJhaW5lZCBkZXZpY2VzLiBU aGUgY2xhaW1zIGluIGEgQ1dUIGFyZQ0KPj4gZW5jb2RlZCBpbiB0aGUgQ29uY2lzZSBCaW5hcnkg T2JqZWN0IFJlcHJlc2VudGF0aW9uIChDQk9SKSBhbmQgQ0JPUg0KPj4gT2JqZWN0IFNpZ25pbmcg YW5kIEVuY3J5cHRpb24gKENPU0UpIGlzIHVzZWQgZm9yIGFkZGVkIGFwcGxpY2F0aW9uIGxheWVy DQo+PiBzZWN1cml0eSBwcm90ZWN0aW9uLiAgQSBjbGFpbSBpcyBhIHBpZWNlIG9mIGluZm9ybWF0 aW9uIGFzc2VydGVkIGFib3V0IGENCj4+IHN1YmplY3QgYW5kIGlzIHJlcHJlc2VudGVkIGFzIGEg bmFtZS92YWx1ZSBwYWlyIGNvbnNpc3Rpbmcgb2YgYSBjbGFpbQ0KPj4gbmFtZSBhbmQgYSBjbGFp bSB2YWx1ZS4iDQo+Pg0KPj4gLyBFcmlrDQo+Pg0KPj4NCj4+IFsxXSBodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtc2VpdHotYWNlLW9hdXRoLWF1dGh6LTAwDQo+Pg0KPj4NCj4+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBDT1NFIG1h aWxpbmcgbGlzdA0KPj4gQ09TRUBpZXRmLm9yZzxtYWlsdG86Q09TRUBpZXRmLm9yZz4NCj4+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29zZQ0KDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KQ09TRSBtYWlsaW5nIGxpc3QNCkNP U0VAaWV0Zi5vcmc8bWFpbHRvOkNPU0VAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2Nvc2UNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KDQotLSBJTVBPUlRBTlQgTk9USUNFOiBUaGUgY29udGVudHMgb2YgdGhpcyBlbWFpbCBhbmQg YW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVn ZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkg dGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgZG8gbm90IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0 byBhbnkgb3RoZXIgcGVyc29uLCB1c2UgaXQgZm9yIGFueSBwdXJwb3NlLCBvciBzdG9yZSBvciBj b3B5IHRoZSBpbmZvcm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFuayB5b3UuDQo= --_000_HE1PR08MB07324FD345F82CF6EC3AEAE3FA1E0HE1PR08MB0732eurp_ Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5ob2VuemINCgl7bXNvLXN0eWxl LW5hbWU6aG9lbnpiO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6 IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsN CgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6 ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxp bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5IaSBXaWxsaWFtLA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIGhhdmUgYmVlbiB0cnlpbmcgdG8gZG8gYSBk b2N1bWVudCB1cGRhdGUgdG8gc2VlIGhvdyB3ZWxsIGEgY29tYmluZWQgcmVnaXN0cnkgd29ya3Mg YW5kIEkgaGF2ZSBiZWVuIHdvbmRlcmluZyB3aGV0aGVyIGl0IGlzIHJlYWxseSB3b3J0aCB0aGUg ZWZmb3J0Lg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRvIG1ha2UgYSBnb29kIGp1 ZGdtZW50IEkgbG9va2VkIGF0IHRoZSBDTkYgY2xhaW0gZGVmaW5lZCBpbiBkcmFmdC1pZXRmLW9h dXRoLXByb29mLW9mLXBvc3Nlc3Npb24uIFRoZSBDTkYgY2xhaW0gbWF5IGNvbnRhaW4gc3ViLWVs ZW1lbnRzLCBzdWNoIGFzIGEgSldFIG9yDQogYSBKV0suPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JZiB3ZSB0cmFuc2xh dGUgdGhlIHNhbWUgbWVjaGFuaXNtcyB0byB0aGUgQ1dUICh3aGljaCBtYWtlcyBzZW5zZSkgdGhl biB3ZSBuZWVkIHRvIHBvaW50IHRvIHRoZSByZXNwZWN0aXZlIENPU0Ugc3RydWN0dXJlcyBpbnN0 ZWFkLiBUaG9zZSBkbyBub3Qgb25seSB1c2UgYQ0KIGRpZmZlcmVudCBlbmNvZGluZyBidXQgYWxz byB0aGUgZnVuY3Rpb25hbGl0eSBkb2VzIG5vdCBtYXRjaCB0aGUgSk9TRSBzdHJ1Y3R1cmVzIDEw MCUuIFNvLCB0aGVyZSBhcmUgcG90ZW50aWFsbHkgZGlmZmVyZW5jZXMuIEkgYW0gYWxzbyBub3Qg c3VyZSB3aGV0aGVyIHdlIHJlYWxseSB3YW50IHRvIHRyYW5zbGF0ZSB0aGUgZnVsbCBmdW5jdGlv bmFsaXR5IG9mIGFsbCB0aGUgY2xhaW1zIGZyb20gSldUIG92ZXIgdG8gdGhlIENXVCBlcXVpdmFs ZW50Lg0KIEl0IGJhc2ljYWxseSBwdXRzIHRoZSBidXJkZW4gb24gc29tZW9uZSBkZWZpbmluZyBu ZXcgY2xhaW1zIChlaXRoZXIgaW4gSldUIG9yIGluIENXVCkgdG8gY3JlYXRlIHRoZSBjb3JyZXNw b25kaW5nIHN0cnVjdHVyZXMgaW4gYSBmb3JtYXQgdGhleSBtYXkgbm90IG5lY2Vzc2FyaWx5IGJl IGZhbWlsaWFyIHdpdGggb3IgZXZlbiBjYXJlIGFib3V0LiBJIGhhdmUgc2VlbiB0aGF0IGhhcHBl bmluZyBpbiB0aGUgUkFESVVTIHdvcmxkIHByb3RvY29sIGRlc2lnbmVycw0KIGhhZCB0byBhbHNv IGRlZmluZSB0aGUgZXF1aXZhbGVudCBzdHJ1Y3R1cmVzIGZvciB1c2Ugd2l0aCBEaWFtZXRlciBh bmQsIGd1ZXNzIHdoYXQsIG1vc3Qgb2YgdGhlIGRlZmluaXRpb25zIHdlcmUgd3JvbmcgKHNpbmNl IHRoZSBhdXRob3JzIGRpZCBub3QgY2FyZSBhYm91dCBEaWFtZXRlciB3aGVuIHdvcmtpbmcgb24g UkFESVVTKS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+Q2lhbzxicj4NCkhhbm5lczxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gV2lsbGlhbSBEZW5uaXNzIFttYWlsdG86d2Rl bm5pc3NAZ29vZ2xlLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiAxMiBOb3ZlbWJlciAyMDE1IDE5 OjE5PGJyPg0KPGI+VG86PC9iPiBFcmlrIFdhaGxzdHLDtm0gbmVYdXM8YnI+DQo8Yj5DYzo8L2I+ IENhcnN0ZW4gQm9ybWFubjsgSGFubmVzIFRzY2hvZmVuaWc7IE1pa2UgSm9uZXM7IGNvc2VAaWV0 Zi5vcmc7ICZsdDtvYXV0aEBpZXRmLm9yZyZndDs7IGFjZUBpZXRmLm9yZzxicj4NCjxiPlN1Ympl Y3Q6PC9iPiBSZTogW0NPU0VdIEEgZHJhZnQgb24gQ0JPUiBXZWIgVG9rZW5zIChDV1QpPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlZ2FyZGluZyB0aGUgZHJh ZnQgaXRzZWxmLCBhIGZldyBjb21tZW50czo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNhbiB3ZSB1bmlmeSB0aGUgY2xhaW0gcmVnaXN0 cnkgd2l0aCBKV1Q/IEknbSB3b3JyaWVkIGFib3V0IGhhdmluZyB0aGUgc2FtZSBjbGFpbXMgZGVm aW5lZCB0d2ljZSBpbiBDV1QgYW5kIEpXVCB3aXRoIHBvc3NpYmx5IGNvbmZsaWN0aW5nIG1lYW5p bmdzIChhbmQgbmVlZGxlc3MgY29uZnVzaW9uIGV2ZW4gd2hlbiB0aGV5IGRvIG1hdGNoKS4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Q29tcGFyaW5nJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LXdhaGxzdHJvZW0tb2F1dGgtY2Jvci13ZWItdG9rZW4tMDAjc2VjdGlvbi0zLjEuMiI+aHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXdhaGxzdHJvZW0tb2F1dGgtY2Jvci13ZWItdG9r ZW4tMDAjc2VjdGlvbi0zLjEuMjwvYT4gYW5kJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL3JmYzc1MTkjc2VjdGlvbi00LjEuMiI+aHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL3JmYzc1MTkjc2VjdGlvbi00LjEuMjwvYT4NCiB3aGljaCBhcmUgbmVhcmx5IGlkZW50 aWNhbCwgSSBqdXN0IGRvbid0IHNlZSB0aGUgdmFsdWUgaW4gcmUtZGVmaW5pbmcgaXQuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldlIG1heSBh ZGQgbmV3IHN0YW5kYXJkIGNsYWltcyB0byBKV1QgaW4gdGhlIGZ1dHVyZSAoSSZuYnNwOzxhIGhy ZWY9Imh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9zZWFyY2gvP2VtYWlsX2xpc3Q9 aWQtZXZlbnQmYW1wO2didD0xJmFtcDtpbmRleD03cU5VbmFFOWx0Mkx5YXlNbm1OeVdwWlNJRU0i PnByb3Bvc2VkIG9uZTwvYT4mbmJzcDtpbiBZb2tvaGFtYSBvbiB0aGUmbmJzcDs8YSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50Ij5pZC1ldmVudA0K IGxpc3Q8L2E+KSwgaXQgd291bGQgYmUgZ29vZCBpZiB0aGlzIGRpZG4ndCBuZWVkIGEgc2VwYXJh dGUgZW50cnkgaW4gQ1dUIHRvbywgYnV0IGNvdWxkIGp1c3QgYXBwbHkgZGlyZWN0bHkgKHNlcGFy YXRlbHksIEkgdGhpbmsgeW91IHNob3VsZCBjb25zaWRlciB0aGlzIGNsYWltLCBhcyBpdCBoZWxw cyBwcmV2ZW50IHRva2VucyBmcm9tIGJlaW5nIHJlLXVzZWQgaW4gdGhlIHdyb25nIGNvbnRleHQp LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4y LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXMg U2VjdGlvbiA0ICZxdW90O1N1bW1hcnkgb2YgQ0JPUiBtYWpvciB0eXBlcyB1c2VkIGJ5IGRlZmlu ZWQgY2xhaW1zJnF1b3Q7IG5vcm1hdGl2ZSAoPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LXdhaGxzdHJvZW0tb2F1dGgtY2Jvci13ZWItdG9rZW4tMDAjc2VjdGlvbi00 Ij5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtd2FobHN0cm9lbS1vYXV0aC1jYm9y LXdlYi10b2tlbi0wMCNzZWN0aW9uLTQ8L2E+KT8NCiBXaGF0IGlzIHRoZSBpbnRlbnRpb24gb2Yg dGhpcyBzZWN0aW9uPyBJIGZlZWwgbGlrZSBpdCBjb3VsZCBwcm9iYWJseSBiZSBmbGVzaGVkIG91 dCBhIGJpdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+My4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkFkZCBhIHhyZWYgdG8gZHJhZnQgQ09TRSBzcGVjIGluJm5ic3A7PGEgaHJlZj0i aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXdhaGxzdHJvZW0tb2F1dGgtY2Jvci13 ZWItdG9rZW4tMDAjc2VjdGlvbi02Ij5zZWN0aW9uIDY8L2E+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BZGQgeHJlZiB0byBSRkM3NTE5PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFRodSwg Tm92IDEyLCAyMDE1IGF0IDEyOjAxIFBNLCBFcmlrIFdhaGxzdHLDtm0gbmVYdXMgJmx0OzxhIGhy ZWY9Im1haWx0bzplcmlrLndhaGxzdHJvbUBuZXh1c2dyb3VwLmNvbSIgdGFyZ2V0PSJfYmxhbmsi PmVyaWsud2FobHN0cm9tQG5leHVzZ3JvdXAuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBDYXJzdGVuLDxicj4NCjxicj4NClRoYW5rcywg YW5kIEkgYWdyZWUuIEnigJl2ZSBoZWFyZCBhcmd1bWVudHMgZm9yIGFsbCB0aHJlZSB3b3JrIGdy b3Vwcy48YnI+DQo8YnI+DQpCb3Jyb3dlZCBzb21lIG9mIHlvdXIgd29yZHMgdG8gZGVmaW5lIHRo ZSBjb250ZW50IG9mIHRoZSBkcmFmdCA6KTxicj4NCkl04oCZcyBpdCBlc3NlbnRpYWxseSBhIEpX VCwgcGhyYXNlZCBpbiBhbmQgcHJvZmlsZWQgZm9yIENCT1IgdG8gYWRkcmVzcyBBQ0UgbmVlZHMs IHdoZXJlIE9BdXRoIG5lZWRzIENPU0UgZnVuY3Rpb25hbGl0eSwgZm9yIG9iamVjdCBzZWN1cml0 eS48YnI+DQo8YnI+DQpJ4oCZbSBvcGVuIGZvciBsZXR0aW5nIHRoZSBBROKAmXMgbW92ZSBpdCBh cm91bmQsIGJ1dCBoYXZpbmcgaXQgcmlnaHQgbmV4dCB0byBKV1Qgc2VlbXMgcmlnaHQgdG8gbWUu IEFsc28gb3BlbiBmb3IgdGhlIEFDRSBXRy4gRmVlbCBpdCBoYXMgbGVzcyBwbGFjZSBpbiBDT1NF IGZvciB0aGUgc2FtZSByZWFzb25zIEpXVCBpcyBub3QgaW4gdGhlIEpPU0UgV0cuPGJyPg0KPHNw YW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPjxicj4NCjxzcGFuIGNsYXNzPSJob2VuemIiPi8gRXJp azwvc3Bhbj48L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxicj4NCjxicj4NCiZndDsgT24gMTIgTm92IDIwMTUsIGF0IDIwOjQ1LCBDYXJz dGVuIEJvcm1hbm4gJmx0OzxhIGhyZWY9Im1haWx0bzpjYWJvQHR6aS5vcmciPmNhYm9AdHppLm9y ZzwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDs8YnI+DQomZ3Q7IEhpIEVyaWssPGJyPg0KJmd0Ozxi cj4NCiZndDsgaGF2aW5nIHRoaXMgZHJhZnQgaXMgYSBnb29kIHRoaW5nLjxicj4NCiZndDs8YnI+ DQomZ3Q7IE9uZSB0aGluZyBJJ20gc3RpbGwgd29uZGVyaW5nIGlzIHdoYXQgV0cgaXMgdGhlIGJl c3QgcGxhY2UgdG8gcHJvZ3Jlc3M8YnI+DQomZ3Q7IHRoaXMuJm5ic3A7IFdlIHByb2JhYmx5IGRv bid0IG5lZWQgdG8gc3BlbmQgdG9vIG11Y2ggdGltZSBvbiB0aGlzIGJlY2F1c2UsPGJyPg0KJmd0 OyByZWdhcmRsZXNzIG9mIHRoZSBXRyBjaG9zZW4sIHRoZSBwZW9wbGUgaW4gYW5vdGhlciBXRyBj YW4gbG9vayBhdCBpdC48YnI+DQomZ3Q7IFN0aWxsLCBnZXR0aW5nIHRoaXMgcmlnaHQgbWlnaHQg cHJvdmlkZSBzb21lIGVmZmljaWVuY2llcy48YnI+DQomZ3Q7PGJyPg0KJmd0OyBXaGF0IGlzIHRo ZSB0ZWNobmljYWwgY29udGVudCBvZiB0aGlzIGRyYWZ0PyZuYnNwOyBJcyBpdCBhIG5ldyB0b2tl biB0aGF0PGJyPg0KJmd0OyBPQXV0aCBuZWVkcyBzcGVjaWZpY2FsbHkgZm9yIHRoZSBuZXcgQ09T RS1iYXNlZCBhcHBsaWNhdGlvbnMgb2YgT0F1dGg/PGJyPg0KJmd0OyBJcyBpdCBhIG5ldyB0b2tl biB0aGF0IGlzIHNwZWNpZmljYWxseSB0aGVyZSBmb3IgYWRkcmVzc2luZyBBQ0UgbmVlZHM/PGJy Pg0KJmd0OyBPciBpcyBpdCBlc3NlbnRpYWxseSB0aGUgc2FtZSBzdWJzdGFuY2UgYXMgSldULCBi dXQgcGhyYXNlZCBpbiBhbmQ8YnI+DQomZ3Q7IHByb2ZpbGVkIGZvciBDQk9SPzxicj4NCiZndDs8 YnI+DQomZ3Q7IERlcGVuZGluZyBvbiB0aGUgYW5zd2VyLCBDV1Qgc2hvdWxkIGJlIGRvbmUgaW4g T0F1dGgsIEFDRSwgb3IgQ09TRS48YnI+DQomZ3Q7IChJJ2QgcmF0aGVyIGhlYXIgdGhlIGFuc3dl ciBmcm9tIHRoZSBhdXRob3JzIHRoYW4gdmVudHVyZSBhIGd1ZXNzIG15c2VsZi4pPGJyPg0KJmd0 Ozxicj4NCiZndDsgR3LDvMOfZSwgQ2Fyc3Rlbjxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0 Ozxicj4NCiZndDsgRXJpayBXYWhsc3Ryw7ZtIG5lWHVzIHdyb3RlOjxicj4NCiZndDsmZ3Q7IEhp LDxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgSW4gdGhlIEFDRSBXRyBhIHN0cmF3IG1hbiBw cm9wb3NhbCBvZiBhIENCT1IgV2ViIFRva2VuIChDV1QpIHdhcyBkZWZpbmVkPGJyPg0KJmd0OyZn dDsgaW4gdGhlIGRyYWZ0ICZxdW90O0F1dGhvcml6YXRpb24gZm9yIHRoZSBJbnRlcm5ldCBvZiBU aGluZ3MgdXNpbmcgT0F1dGggMi4w4oCdPGJyPg0KJmd0OyZndDsgWzFdLiBXZSBqdXN0IGJyb2tl IG91dCB0aGUgQ0JPUiBXZWIgVG9rZW4gaW50byBhIHNlcGFyYXRlIGRyYWZ0IGFuZCB0aGU8YnI+ DQomZ3Q7Jmd0OyBuZXcgZHJhZnQgaXMgc3VibWl0dGVkIHRvIHRoZSBPQVVUSCBXRy4gSXQgY2Fu IGJlIGZvdW5kIGhlcmU6PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyA8YSBocmVmPSJodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC13YWhsc3Ryb2VtLW9hdXRoLWNib3It d2ViLXRva2VuLyIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtd2FobHN0cm9lbS1vYXV0aC1jYm9yLXdlYi10b2tlbi88L2E+PGJyPg0KJmd0 OyZndDs8YnI+DQomZ3Q7Jmd0OyBBYnN0cmFjdDo8YnI+DQomZ3Q7Jmd0OyAmcXVvdDtDQk9SIFdl YiBUb2tlbiAoQ1dUKSBpcyBhIGNvbXBhY3QgbWVhbnMgb2YgcmVwcmVzZW50aW5nIGNsYWltcyB0 byBiZTxicj4NCiZndDsmZ3Q7IHRyYW5zZmVycmVkIGJldHdlZW4gdHdvIHBhcnRpZXMuJm5ic3A7 IENXVCBpcyBhIHByb2ZpbGUgb2YgdGhlIEpTT04gV2ViIFRva2VuPGJyPg0KJmd0OyZndDsgKEpX VCkgdGhhdCBpcyBvcHRpbWl6ZWQgZm9yIGNvbnN0cmFpbmVkIGRldmljZXMuIFRoZSBjbGFpbXMg aW4gYSBDV1QgYXJlPGJyPg0KJmd0OyZndDsgZW5jb2RlZCBpbiB0aGUgQ29uY2lzZSBCaW5hcnkg T2JqZWN0IFJlcHJlc2VudGF0aW9uIChDQk9SKSBhbmQgQ0JPUjxicj4NCiZndDsmZ3Q7IE9iamVj dCBTaWduaW5nIGFuZCBFbmNyeXB0aW9uIChDT1NFKSBpcyB1c2VkIGZvciBhZGRlZCBhcHBsaWNh dGlvbiBsYXllcjxicj4NCiZndDsmZ3Q7IHNlY3VyaXR5IHByb3RlY3Rpb24uJm5ic3A7IEEgY2xh aW0gaXMgYSBwaWVjZSBvZiBpbmZvcm1hdGlvbiBhc3NlcnRlZCBhYm91dCBhPGJyPg0KJmd0OyZn dDsgc3ViamVjdCBhbmQgaXMgcmVwcmVzZW50ZWQgYXMgYSBuYW1lL3ZhbHVlIHBhaXIgY29uc2lz dGluZyBvZiBhIGNsYWltPGJyPg0KJmd0OyZndDsgbmFtZSBhbmQgYSBjbGFpbSB2YWx1ZS4mcXVv dDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IC8gRXJpazxicj4NCiZndDsmZ3Q7PGJyPg0K Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBbMV0gPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LXNlaXR6LWFjZS1vYXV0aC1hdXRoei0wMCIgdGFyZ2V0PSJfYmxhbmsiPg0K aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNlaXR6LWFjZS1vYXV0aC1hdXRoei0w MDwvYT48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7Jmd0OyBDT1NF IG1haWxpbmcgbGlzdDxicj4NCiZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzpDT1NFQGlldGYub3Jn Ij5DT1NFQGlldGYub3JnPC9hPjxicj4NCiZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vY29zZSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29zZTwvYT48YnI+DQo8YnI+DQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCkNPU0UgbWFpbGluZyBs aXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOkNPU0VAaWV0Zi5vcmciPkNPU0VAaWV0Zi5vcmc8L2E+ PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3Nl IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9j b3NlPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJyPg0K PGhyPg0KPGZvbnQgZmFjZT0iQXJpYWwiIGNvbG9yPSJCbGFjayIgc2l6ZT0iMiI+PGJyPg0KLS0g SU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRh Y2htZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5 b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5k ZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90 aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBhbnkNCiBwdXJwb3NlLCBvciBzdG9yZSBvciBjb3B5IHRo ZSBpbmZvcm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFuayB5b3UuPGJyPg0KPC9mb250Pg0KPC9i b2R5Pg0KPC9odG1sPg0K --_000_HE1PR08MB07324FD345F82CF6EC3AEAE3FA1E0HE1PR08MB0732eurp_-- From nobody Mon Nov 16 12:37:04 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E83831B3139 for ; Mon, 16 Nov 2015 12:37:02 -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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uP_VjcCcW9hn for ; Mon, 16 Nov 2015 12:37:01 -0800 (PST) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::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 777CE1B3138 for ; Mon, 16 Nov 2015 12:37:01 -0800 (PST) Received: by wmww144 with SMTP id w144so127069236wmw.1 for ; Mon, 16 Nov 2015 12:37:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=WoKKp6XbD1w+Ss8gkH2y3R1AjmQ22iILAnyUcq/SHxY=; b=Ec+rpkYJ2PRWr1F90CvYMyFb9Vy58uu2xoB4pgebWxj83UPVZKH5SA9WNJ+TbM/P9G Xgftz+vQDcLOL/7L1l1Cipkbs7dMn9Vv576ByRWlbnypIYONT2/Lt0XpsB19h/EdzzUr tSx3Kw9OL1vPsJKPNlAr03x6meWPlZW0FSJTKb5VJXXByjzKWXeaAbcJSWxWEl1uG1MP gBpBULMcb7KFSEKHkzIJAa/XR48v+WgtwXHFsLRPQHKKghqZoMp1RsjKgibvqIE13Acu nmQc/Iu1Mcis80PsBvYK26uJv5VapG5h69YBpsqdal3m+wy57z+rqTTDFbRxc0TlI9Hy Txlw== MIME-Version: 1.0 X-Received: by 10.28.126.215 with SMTP id z206mr21739120wmc.71.1447706220073; Mon, 16 Nov 2015 12:37:00 -0800 (PST) Received: by 10.28.52.130 with HTTP; Mon, 16 Nov 2015 12:37:00 -0800 (PST) Date: Mon, 16 Nov 2015 15:37:00 -0500 Message-ID: From: Kathleen Moriarty To: "oauth@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [OAUTH-WG] AD review of draft-ietf-oauth-pop-architecture X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2015 20:37:03 -0000 Hello, I reviewed draft-ietf-oauth-pop-architecture and have a few questions. 1. Section 6, Threat Mitigation: Last sentence of first paragraph, "To simplify the subsequent description we assume that the token itself is digitally signed by the authorization server and therefore cannot be modified." Since bearer tokens are not signed by default, is this proposing a change? If so, where will that change occur? To state that "it is assumed" without it being required anywhere is not a good assumption. I'd still see this as a risk or security consideration. When OAuth is re-used by other protocols, I am seeing that re-use leave off basic protections that should be assumed like TLS, let alone digital signatures. If this is required in the defined architecture (Section 7 - it does show this, but there are no MUSTs that I can find), just state that and refer to the requirement. 2. Section 6, Threat Mitigation Third paragraph, "As an example, TLS with a ciphersuite that offers confidentiality protection has to be applied (which is currently true for all ciphersuites, except for one). Please list a reference so the reader knows which ciphersuites are acceptable from the recommended ones in RFC7525. I don't recall there being any MTI ciphersuites for OAuth (I'm pretty sure there aren't and that we've discussed that already with previous drafts, so this should be spelled out more). 3. (Nit) Section 6.2, add a comma to improve readability From: "Instead of providing confidentiality protection the authorization server could also put the identifier of the client into the protected token with the following semantic:" To: "Instead of providing confidentiality protection, the authorization server could also put the identifier of the client into the protected token with the following semantic:" Thank you all for your work on this draft! -- Best regards, Kathleen From nobody Mon Nov 16 13:32:21 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0151E1B31DC for ; Mon, 16 Nov 2015 13:32:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.963 X-Spam-Level: X-Spam-Status: No, score=-1.963 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MnIlPyBIUOTK for ; Mon, 16 Nov 2015 13:32:16 -0800 (PST) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79E6F1B31DF for ; Mon, 16 Nov 2015 13:32:16 -0800 (PST) Received: by qgeb1 with SMTP id b1so59885929qge.1 for ; Mon, 16 Nov 2015 13:32:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=E8eYsjbIjwoeNMQUa5EJTt1SL1k1YMkaYX3FcoAps78=; b=YB8F7Oq53wu2tV5xPLOqEMmClrffHE0efz/8prrUzG6zdv4Y2lNMZYHTAMW9sl/bgN celuAmYUcdzOpYyPJnoV8IvhgKj4i0647yx3d6VfaYTJ123xhSix1mXxKX2Pg9tuF0Bz ZKYXqwDBJrON6NR9y3JvS3IKX804pXkNKxbYZ/8PaCJ/f6qjpAbunv1yBd0h/Ya6Y+8U 7BFbG6yn6ZPS5kbgRUIBYtyMGMT67cra6quT59kSPjH0YzmllmNFAjcnxPHEU8XU5Bsg PSXRMhyJBrqlffbOzGtp6ANk1mlmiMpHdK4vhij1xBxeNMCVTdpd72Z8dH3Dko4lJMy7 rihA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=E8eYsjbIjwoeNMQUa5EJTt1SL1k1YMkaYX3FcoAps78=; b=CmeLFW9Kc5BMb8NFDpXB54WZKTixR+JFkhZOJai6I8/JmILVvmz/L3TSQBE7Wh0NYL VHVmNskF7M2vatxq3bYT5a9bOmnhrmEXzptG+CIaNxQfHatBPY5hyXgQSAhdcR2pP34B GVBZuWPIYrBaxgjtHYbuzcFXLqgtNJ2v6SIt6723bYjFUXYBdO+cdHx5Ya1w0OskLna6 wYbMCh30OKq4PM2eYpby+mGiSnebEBpArKkCQehjiAklZMUfyaM2HYg9lVxOogoUz0sy l+s8i5c5lgwF6qVsid5VhG0754oTe0u2/q1NyitndNUmCCHChrXMLOQSPVrHIK7vIbKo ebmQ== X-Gm-Message-State: ALoCoQlcQtxNH/zXMVabpkJcO273c0+YNM0mTFoxtsoz1+UoNvqFextij1s4crXFyVnhGOdJ8g+K X-Received: by 10.140.177.199 with SMTP id x190mr39753650qhx.91.1447709535422; Mon, 16 Nov 2015 13:32:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.29.68 with HTTP; Mon, 16 Nov 2015 13:31:55 -0800 (PST) In-Reply-To: References: <53BB1987-979C-4945-9C7D-CDB6619AEFFC@nexusgroup.com> <5644EC40.4010002@tzi.org> <73929C18-A3E7-4ACA-A6DC-5A7AD7576C9B@nexusgroup.com> From: William Denniss Date: Mon, 16 Nov 2015 13:31:55 -0800 Message-ID: To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=001a113a74ba991c400524af24b8 Archived-At: Cc: Carsten Bormann , "" Subject: Re: [OAUTH-WG] [COSE] A draft on CBOR Web Tokens (CWT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2015 21:32:20 -0000 --001a113a74ba991c400524af24b8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable You raise some good points, and perhaps that is relevant to future claims. The spec as drafted, is a one-for-one copy of the standard JWT claims, which is why I raised this point. Is the goal a CBOR representation of a JWT? If so, can it be defined in terms of a JWT? Would the CNF claim then inherit that representation (treating the JWE and JWK as their CBOR equivalents)? Perhaps if you go the separate registry route, those claims that *are* defined the same should at least normatively reference JWT? I want to avoid the whole "on behalf of" / "act as" fiasco where things can get re-defined, and muddled. On Mon, Nov 16, 2015 at 7:09 AM, Hannes Tschofenig < Hannes.Tschofenig@arm.com> wrote: > Hi William, > > > > I have been trying to do a document update to see how well a combined > registry works and I have been wondering whether it is really worth the > effort. > > To make a good judgment I looked at the CNF claim defined in > draft-ietf-oauth-proof-of-possession. The CNF claim may contain > sub-elements, such as a JWE or a JWK. > > > > If we translate the same mechanisms to the CWT (which makes sense) then w= e > need to point to the respective COSE structures instead. Those do not onl= y > use a different encoding but also the functionality does not match the JO= SE > structures 100%. So, there are potentially differences. I am also not sur= e > whether we really want to translate the full functionality of all the > claims from JWT over to the CWT equivalent. It basically puts the burden = on > someone defining new claims (either in JWT or in CWT) to create the > corresponding structures in a format they may not necessarily be familiar > with or even care about. I have seen that happening in the RADIUS world > protocol designers had to also define the equivalent structures for use > with Diameter and, guess what, most of the definitions were wrong (since > the authors did not care about Diameter when working on RADIUS). > > > > Ciao > Hannes > > > > > > *From:* William Denniss [mailto:wdenniss@google.com] > *Sent:* 12 November 2015 19:19 > *To:* Erik Wahlstr=C3=B6m neXus > *Cc:* Carsten Bormann; Hannes Tschofenig; Mike Jones; cose@ietf.org; < > oauth@ietf.org>; ace@ietf.org > *Subject:* Re: [COSE] A draft on CBOR Web Tokens (CWT) > > > > Regarding the draft itself, a few comments: > > > > 1. > > Can we unify the claim registry with JWT? I'm worried about having the > same claims defined twice in CWT and JWT with possibly conflicting meanin= gs > (and needless confusion even when they do match). > > > > Comparing > https://tools.ietf.org/html/draft-wahlstroem-oauth-cbor-web-token-00#sect= ion-3.1.2 > and https://tools.ietf.org/html/rfc7519#section-4.1.2 which are nearly > identical, I just don't see the value in re-defining it. > > > > We may add new standard claims to JWT in the future (I proposed one > in > Yokohama on the id-event list > ), it would be good if > this didn't need a separate entry in CWT too, but could just apply direct= ly > (separately, I think you should consider this claim, as it helps prevent > tokens from being re-used in the wrong context). > > > > 2. > > Is Section 4 "Summary of CBOR major types used by defined claims" > normative ( > https://tools.ietf.org/html/draft-wahlstroem-oauth-cbor-web-token-00#sect= ion-4)? > What is the intention of this section? I feel like it could probably be > fleshed out a bit. > > > > 3. > > Add a xref to draft COSE spec in section 6 > > > Add xref to RFC7519 > > > > On Thu, Nov 12, 2015 at 12:01 PM, Erik Wahlstr=C3=B6m neXus < > erik.wahlstrom@nexusgroup.com> wrote: > > Hi Carsten, > > Thanks, and I agree. I=E2=80=99ve heard arguments for all three work grou= ps. > > Borrowed some of your words to define the content of the draft :) > It=E2=80=99s it essentially a JWT, phrased in and profiled for CBOR to ad= dress ACE > needs, where OAuth needs COSE functionality, for object security. > > I=E2=80=99m open for letting the AD=E2=80=99s move it around, but having = it right next to > JWT seems right to me. Also open for the ACE WG. Feel it has less place i= n > COSE for the same reasons JWT is not in the JOSE WG. > > / Erik > > > > > On 12 Nov 2015, at 20:45, Carsten Bormann wrote: > > > > Hi Erik, > > > > having this draft is a good thing. > > > > One thing I'm still wondering is what WG is the best place to progress > > this. We probably don't need to spend too much time on this because, > > regardless of the WG chosen, the people in another WG can look at it. > > Still, getting this right might provide some efficiencies. > > > > What is the technical content of this draft? Is it a new token that > > OAuth needs specifically for the new COSE-based applications of OAuth? > > Is it a new token that is specifically there for addressing ACE needs? > > Or is it essentially the same substance as JWT, but phrased in and > > profiled for CBOR? > > > > Depending on the answer, CWT should be done in OAuth, ACE, or COSE. > > (I'd rather hear the answer from the authors than venture a guess > myself.) > > > > Gr=C3=BC=C3=9Fe, Carsten > > > > > > > > Erik Wahlstr=C3=B6m neXus wrote: > >> Hi, > >> > >> In the ACE WG a straw man proposal of a CBOR Web Token (CWT) was defin= ed > >> in the draft "Authorization for the Internet of Things using OAuth 2.0= =E2=80=9D > >> [1]. We just broke out the CBOR Web Token into a separate draft and th= e > >> new draft is submitted to the OAUTH WG. It can be found here: > >> > >> https://datatracker.ietf.org/doc/draft-wahlstroem-oauth-cbor-web-token= / > >> > >> Abstract: > >> "CBOR Web Token (CWT) is a compact means of representing claims to be > >> transferred between two parties. CWT is a profile of the JSON Web Tok= en > >> (JWT) that is optimized for constrained devices. The claims in a CWT a= re > >> encoded in the Concise Binary Object Representation (CBOR) and CBOR > >> Object Signing and Encryption (COSE) is used for added application lay= er > >> security protection. A claim is a piece of information asserted about= a > >> subject and is represented as a name/value pair consisting of a claim > >> name and a claim value." > >> > >> / Erik > >> > >> > >> [1] https://tools.ietf.org/html/draft-seitz-ace-oauth-authz-00 > >> > >> > >> _______________________________________________ > >> COSE mailing list > >> COSE@ietf.org > >> https://www.ietf.org/mailman/listinfo/cose > > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose > > > > ------------------------------ > > -- IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy th= e > information in any medium. Thank you. > --001a113a74ba991c400524af24b8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
You raise some good points, and perhaps that is relevant t= o future claims. The spec as drafted, is a one-for-one copy of the standard= JWT claims, which is why I raised this point.

Is the go= al a CBOR representation of a JWT? If so, can it be defined in terms of a J= WT?=C2=A0 Would the CNF claim then inherit that representation (treating th= e JWE and JWK as their CBOR equivalents)?

Perhaps = if you go the separate registry route, those claims that *are* defined the = same should at least normatively reference JWT?=C2=A0 I want to avoid the w= hole "on behalf of" / "act as" fiasco where things can = get re-defined, and muddled.

On Mon, Nov 16, 2015 at 7:09 AM, Hannes Tschofenig <= span dir=3D"ltr"><Hannes.Tschofenig@arm.com> wrote:

Hi William,

=C2=A0

I have been trying to do = a document update to see how well a combined registry works and I have been= wondering whether it is really worth the effort.

To make a good judgment I= looked at the CNF claim defined in draft-ietf-oauth-proof-of-possession. T= he CNF claim may contain sub-elements, such as a JWE or a JWK.

=C2=A0

If we translate the same = mechanisms to the CWT (which makes sense) then we need to point to the resp= ective COSE structures instead. Those do not only use a different encoding but also the functionality does not match the JOSE stru= ctures 100%. So, there are potentially differences. I am also not sure whet= her we really want to translate the full functionality of all the claims fr= om JWT over to the CWT equivalent. It basically puts the burden on someone defining new claims (either in JWT= or in CWT) to create the corresponding structures in a format they may not= necessarily be familiar with or even care about. I have seen that happenin= g in the RADIUS world protocol designers had to also define the equivalent structures for use with Diameter and, gu= ess what, most of the definitions were wrong (since the authors did not car= e about Diameter when working on RADIUS).

=C2=A0

Ciao
Hannes

=C2=A0

=C2=A0

From: William Denniss [mailto:wdenniss@google.com]
Sent: 12 November 2015 19:19
To: Erik Wahlstr=C3=B6m neXus
Cc: Carsten Bormann; Hannes Tschofenig; Mike Jones; cose@ietf.org; <oauth@ietf.org>; ace@ietf.org
Subject: Re: [COSE] A draft on CBOR Web Tokens (CWT)

=C2=A0

Regarding the draft itself, a few comments:

=C2=A0

1.=C2=A0

Can we unify the claim registry with JWT? I'm wo= rried about having the same claims defined twice in CWT and JWT with possib= ly conflicting meanings (and needless confusion even when they do match).= =C2=A0

=C2=A0

Comparing=C2=A0https://tools.ietf.org/html/draft-wahlstroem-oauth-cbor-web-token-00#secti= on-3.1.2 and=C2=A0https://tools.ietf.org/html/rfc7519#section-4.1.= 2 which are nearly identical, I just don't see the value in re-defining = it.

=C2=A0

We may add new standard claims to JWT in the future = (I=C2=A0proposed one=C2=A0in Yokohama on the=C2=A0id-event list), it would be good if this didn't need a separate entry in CW= T too, but could just apply directly (separately, I think you should consid= er this claim, as it helps prevent tokens from being re-used in the wrong c= ontext).

=C2=A0

2.

=C2=A0

3.=C2=A0

Add xref to RFC7519

=C2=A0

On Thu, Nov 12, 2015 at 12:01 PM, Erik Wahlstr=C3=B6= m neXus <erik.wahlstrom@nexusgroup.com> wrote:

Hi Carsten,

Thanks, and I agree. I=E2=80=99ve heard arguments for all three work groups= .

Borrowed some of your words to define the content of the draft :)
It=E2=80=99s it essentially a JWT, phrased in and profiled for CBOR to addr= ess ACE needs, where OAuth needs COSE functionality, for object security.
I=E2=80=99m open for letting the AD=E2=80=99s move it around, but having it= right next to JWT seems right to me. Also open for the ACE WG. Feel it has= less place in COSE for the same reasons JWT is not in the JOSE WG.

/ Erik



> On 12 Nov 2015, at 20:45, Carsten Bormann <cabo@tzi.org> wrote:
>
> Hi Erik,
>
> having this draft is a good thing.
>
> One thing I'm still wondering is what WG is the best place to prog= ress
> this.=C2=A0 We probably don't need to spend too much time on this = because,
> regardless of the WG chosen, the people in another WG can look at it.<= br> > Still, getting this right might provide some efficiencies.
>
> What is the technical content of this draft?=C2=A0 Is it a new token t= hat
> OAuth needs specifically for the new COSE-based applications of OAuth?=
> Is it a new token that is specifically there for addressing ACE needs?=
> Or is it essentially the same substance as JWT, but phrased in and
> profiled for CBOR?
>
> Depending on the answer, CWT should be done in OAuth, ACE, or COSE. > (I'd rather hear the answer from the authors than venture a guess = myself.)
>
> Gr=C3=BC=C3=9Fe, Carsten
>
>
>
> Erik Wahlstr=C3=B6m neXus wrote:
>> Hi,
>>
>> In the ACE WG a straw man proposal of a CBOR Web Token (CWT) was d= efined
>> in the draft "Authorization for the Internet of Things using = OAuth 2.0=E2=80=9D
>> [1]. We just broke out the CBOR Web Token into a separate draft an= d the
>> new draft is submitted to the OAUTH WG. It can be found here:
>>
>> https://datatracker.ietf.org/doc/draft-wahlstroem-oauth-cbor-web-token/=
>>
>> Abstract:
>> "CBOR Web Token (CWT) is a compact means of representing clai= ms to be
>> transferred between two parties.=C2=A0 CWT is a profile of the JSO= N Web Token
>> (JWT) that is optimized for constrained devices. The claims in a C= WT are
>> encoded in the Concise Binary Object Representation (CBOR) and CBO= R
>> Object Signing and Encryption (COSE) is used for added application= layer
>> security protection.=C2=A0 A claim is a piece of information asser= ted about a
>> subject and is represented as a name/value pair consisting of a cl= aim
>> name and a claim value."
>>
>> / Erik
>>
>>
>> [1] https://tools.ietf.org/html/draft-seitz-ace-oauth-authz-00
>>
>>
>> _______________________________________________
>> COSE mailing list
>> COSE@ietf.org
>> https://www.ietf.org/mailman/listinfo/cose

_______________________________________________
COSE mailing list
COSE@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/cose

=C2=A0



-- IMPORTANT NOTICE: The contents of this email and any attachments are con= fidential and may also be privileged. If you are not the intended recipient= , please notify the sender immediately and do not disclose the contents to = any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

--001a113a74ba991c400524af24b8-- From nobody Mon Nov 16 13:40:50 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B73B1B31FA for ; Mon, 16 Nov 2015 13:40:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SIzCmGj0I2Kx for ; Mon, 16 Nov 2015 13:40:46 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0125.outbound.protection.outlook.com [207.46.100.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EBBD1B31F8 for ; Mon, 16 Nov 2015 13:40:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=rwHZiRKaKrSpk8l448mL7D8xxb4J5jLOcfXUYkFWDlI=; b=nLC3Wori0mLsKg0E0yd8sOOlhHL65l27kr4cge/h0rwBdIuWyQTKu81qJ4H2tQ/MOH7hQRMFzRsUXhQusKYgmkCmoSij1TYGqa5upsTgUIQL2x4wjD91FG7UFZSFxiklan1inoyo8H9/dvFER1F3O5vyNinnmWLEwxZXuPylb5Q= Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB444.namprd03.prod.outlook.com (10.141.141.154) with Microsoft SMTP Server (TLS) id 15.1.325.17; Mon, 16 Nov 2015 21:40:44 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0325.003; Mon, 16 Nov 2015 21:40:44 +0000 From: Mike Jones To: Hannes Tschofenig , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] draft-ietf-oauth-proof-of-possession-06 Glitches Thread-Index: AQHRIH79mKZHRXxwvE+48vmOkQX4Rp6fJFzA Date: Mon, 16 Nov 2015 21:40:43 +0000 Message-ID: References: <5649EE61.8060803@gmx.net> In-Reply-To: <5649EE61.8060803@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [2001:4898:80e8:2::650] x-microsoft-exchange-diagnostics: 1; BY2PR03MB444; 5:3H5AERth2kju0wo4jSf+/ll0v8/n5POupIM4Cqo2r99K0gp9ll8bwbugoKkwILWjiF8Bfox22JWEL5LEpWgtyLEDqTwpXQ+Z4/y9f0Z0PdHpDLjZqDvXZ0a+3DddPhmOSvBNWGs+O2tI3J7FrLUh4Q==; 24:v5tKN//20bDqALlWKMXp6VW9ssaak1bwDu57/LPyT7OPj1kojf/DKYt6pxae6WdHzeddRUYXAlioSZk3K8K+zggEyMaEpoK0eF8i0kOh1HI=; 20:TUtdV8eXRtSJ8onH4/jr8+FVT1XfBYyIEB8eNye8PEkxwJj3UzZuZ6lutQi/TyF+6Rd7Sm2uaj3bq16ovBQeeQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB444; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425024)(601004)(2401047)(8121501046)(5005006)(520078)(10201501046)(3002001)(61426024)(61427024); SRVR:BY2PR03MB444; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB444; x-forefront-prvs: 0762FFD075 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(53754006)(51914003)(43784003)(199003)(189002)(377454003)(13464003)(8990500004)(40100003)(87936001)(11100500001)(2501003)(50986999)(74316001)(122556002)(76576001)(230783001)(102836002)(106356001)(92566002)(5001960100002)(77096005)(54356999)(81156007)(106116001)(19580395003)(15975445007)(97736004)(19580405001)(33656002)(5003600100002)(5005710100001)(10290500002)(76176999)(189998001)(586003)(99286002)(2900100001)(86612001)(2950100001)(101416001)(5008740100001)(5007970100001)(10400500002)(107886002)(86362001)(5001770100001)(5002640100001)(575784001)(10090500001)(105586002)(5004730100002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB444; H:BY2PR03MB442.namprd03.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:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Nov 2015 21:40:43.8608 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB444 Archived-At: Subject: Re: [OAUTH-WG] draft-ietf-oauth-proof-of-possession-06 Glitches X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2015 21:40:49 -0000 SGkgSGFubmVzLiAgVGhhbmtzIGZvciB0aGUgZmVlZGJhY2suICBSZXBsaWVzIGFyZSBpbmxpbmUg YmVsb3cuLi4NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBPQXV0aCBb bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBIYW5uZXMNCj4gVHNj aG9mZW5pZw0KPiBTZW50OiBNb25kYXksIE5vdmVtYmVyIDE2LCAyMDE1IDY6NTUgQU0NCj4gVG86 IG9hdXRoQGlldGYub3JnDQo+IFN1YmplY3Q6IFtPQVVUSC1XR10gZHJhZnQtaWV0Zi1vYXV0aC1w cm9vZi1vZi1wb3NzZXNzaW9uLTA2IEdsaXRjaGVzDQo+IA0KPiBIaSBhbGwsDQo+IA0KPiBJIG5v dGljZWQgYSBmZXcgZ2xpdGNoZXMgd2l0aCB0aGUgbW9zdCByZWNlbnQgdmVyc2lvbiBvZiB0aGUg ZHJhZnQtaWV0Zi1vYXV0aC0NCj4gcHJvb2Ytb2YtcG9zc2Vzc2lvbiBkb2N1bWVudC4NCj4gDQo+ ICoqIFBvUCBGaWd1cmUgKFN5bW1ldHJpYyBLZXkpDQo+IA0KPiBGUk9NOg0KPiANCj4gICAgICAr LS0tLS0tLS0tLS0tLS0rDQo+ICAgICAgfCAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAg ICAgICAgICArLS0tLS0tLS0tLS0tLS0rDQo+ICAgICAgfCAgICAgICAgICAgICAgfC0tKDQpIFBy ZXNlbnRhdGlvbiBvZiAtLT58ICAgICAgICAgICAgICB8DQo+ICAgICAgfCAgICAgICAgICAgICAg fCAgICAgIEpXVCB3LyBFbmNyeXB0ZWQgICB8ICAgICAgICAgICAgICB8DQo+ICAgICAgfCAgUHJl c2VudGVyICAgfCAgICAgIFBvUCBLZXkgICAgICAgICAgICB8ICAgICAgICAgICAgICB8DQo+ICAg ICAgfCAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAg ICB8DQo+ICAgICAgfCAgICAgICAgICAgICAgfDwtKDUpIENvbW11bmljYXRpb24gLS0tLT58ICAg ICAgICAgICAgICB8DQo+ICAgICAgfCAgICAgICAgICAgICAgfCAgICAgIEF1dGhlbnRpY2F0ZWQg YnkgICB8ICAgICAgICAgICAgICB8DQo+ICAgICAgKy0tLS0tLS0tLS0tLS0tKyAgICAgIFBvUCBL ZXkgICAgICAgICAgICB8ICAgICAgICAgICAgICB8DQo+ICAgICAgICB8ICAgICAgICAgIF4gICAg ICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICB8DQo+ICAgICAgICB8ICAgICAg ICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICB8DQo+ICAgICAg ICgxKSBTeW0uICAgKDMpIEpXVCB3LyAgICAgICAgICAgICAgICAgICB8ICBSZWNpcGllbnQgICB8 DQo+ICAgICAgICB8ICBQb1AgICAgIHwgIEVuY3J5cHRlZCAgICAgICAgICAgICAgICB8ICAgICAg ICAgICAgICB8DQo+ICAgICAgICB8ICBLZXkgICAgIHwgIFBvUCBLZXkgICAgICAgICAgICAgICAg ICB8ICAgICAgICAgICAgICB8DQo+ICAgICAgICB2ICAgICAgICAgIHwgICAgICAgICAgICAgICAg ICAgICAgICAgICB8ICAgICAgICAgICAgICB8DQo+ICAgICAgKy0tLS0tLS0tLS0tLS0tKyAgICAg ICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICB8DQo+ICAgICAgfCAgICAgICAgICAg ICAgfCAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICB8DQo+ICAgICAgfCAg ICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICB8DQo+ ICAgICAgfCAgICAgICAgICAgICAgfDwtKDIpIEtleSBFeGNoYW5nZSBmb3IgLT58ICAgICAgICAg ICAgICB8DQo+ICAgICAgfCAgIElzc3VlciAgICAgfCAgICAgIEtleSBFbmNyeXB0aW9uIEtleSB8 ICAgICAgICAgICAgICB8DQo+ICAgICAgfCAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAg ICAgICAgICB8ICAgICAgICAgICAgICB8DQo+ICAgICAgfCAgICAgICAgICAgICAgfCAgICAgICAg ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICB8DQo+ICAgICAgfCAgICAgICAgICAgICAg fCAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0rDQo+ICAgICAgKy0tLS0t LS0tLS0tLS0tKw0KPiANCj4gICAgICAgICAgICAgRmlndXJlIDE6IFByb29mLW9mLVBvc3Nlc3Np b24gd2l0aCBhIFN5bW1ldHJpYyBLZXkNCj4gDQo+IFRPOg0KPiANCj4gICstLS0tLS0tLS0tLS0t LSsNCj4gIHwgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0t LS0tLS0tKw0KPiAgfCAgICAgICAgICAgICAgfC0tKDMpIFByZXNlbnRhdGlvbiBvZiAtLT58ICAg ICAgICAgICAgICB8DQo+ICB8ICAgICAgICAgICAgICB8ICAgICAgSldUIHcvIEVuY3J5cHRlZCAg IHwgICAgICAgICAgICAgIHwNCj4gIHwgIFByZXNlbnRlciAgIHwgICAgICBQb1AgS2V5ICAgICAg ICAgICAgfCAgICAgICAgICAgICAgfA0KPiAgfCAgICAgICAgICAgICAgfCAgICAgICAgICAgICAg ICAgICAgICAgICB8ICAgICAgICAgICAgICB8DQo+ICB8ICAgICAgICAgICAgICB8PC0oNCkgQ29t bXVuaWNhdGlvbiAtLS0tPnwgICAgICAgICAgICAgIHwNCj4gIHwgICAgICAgICAgICAgIHwgICAg ICBBdXRoZW50aWNhdGVkIGJ5ICAgfCAgICAgICAgICAgICAgfA0KPiAgKy0tLS0tLS0tLS0tLS0t KyAgICAgIFBvUCBLZXkgICAgICAgICAgICB8ICAgICAgICAgICAgICB8DQo+ICAgIHwgICAgICAg ICAgXiAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgIHwNCj4gICAgfCAg ICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgfA0KPiAg ICgxKSBTeW0uICAgKDIpIEpXVCB3LyAgICAgICAgICAgICAgICAgICB8ICBSZWNpcGllbnQgICB8 DQo+ICAgIHwgIFBvUCAgICAgfCAgRW5jcnlwdGVkICAgICAgICAgICAgICAgIHwgICAgICAgICAg ICAgIHwNCj4gICAgfCAgS2V5ICAgICB8ICBQb1AgS2V5ICAgICAgICAgICAgICAgICAgfCAgICAg ICAgICAgICAgfA0KPiAgICB2ICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICB8 ICAgICAgICAgICAgICB8DQo+ICArLS0tLS0tLS0tLS0tLS0rICAgICAgICAgICAgICAgICAgICAg ICAgIHwgICAgICAgICAgICAgIHwNCj4gIHwgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAg ICAgICAgICAgfCAgICAgICAgICAgICAgfA0KPiAgfCAgICAgICAgICAgICAgfCAgICAgICAgICAg ICAgICAgICAgICAgICB8ICAgICAgICAgICAgICB8DQo+ICB8ICAgICAgICAgICAgICB8PD09PT09 PT09PT09PT09PT09PT09PT09PnwgICAgICAgICAgICAgIHwNCj4gIHwgICBJc3N1ZXIgICAgIHwg ICAgS2V5IEV4Y2hhbmdlIGZvciAgICAgfCAgICAgICAgICAgICAgfA0KPiAgfCAgICAgICAgICAg ICAgfCAgICBLZXkgRW5jcnlwdGlvbiBLZXkgICB8ICAgICAgICAgICAgICB8DQo+ICB8ICAgICAg ICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgIHwNCj4gIHwg ICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tKw0K PiAgKy0tLS0tLS0tLS0tLS0tKw0KPiANCj4gICAgICAgICAgICAgRmlndXJlIDE6IFByb29mLW9m LVBvc3Nlc3Npb24gd2l0aCBhIFN5bW1ldHJpYyBLZXkNCj4gDQo+IA0KPiBUaGUgcmVhc29uIGZv ciB0aGlzIGNoYW5nZSBpcyB0aGF0IHRoZSBmaWd1cmUgY3VycmVudGx5IGluY2x1ZGVkIGluIHRo ZQ0KPiBkb2N1bWVudCBnaXZlcyB0aGUgaW1wcmVzc2lvbiB0aGF0IHRoZSBrZXkgdXNlZCB0byBw cm90ZWN0IHRoZSBQb1AgdG9rZW4gaXMNCj4gYWN0dWFsbHkgZHluYW1pY2FsbHkgZXhjaGFuZ2Vk IGluIHN0ZXAgKDIpLCB3aGljaCBpc24ndCB0aGUgY2FzZS4NCj4gDQo+IFdoaWxlIHRleHQgc2F5 cyB0aGF0IGl0IGlzIGR5bmFtaWNhbGx5IGVzdGFibGlzaGVkIGlmIGl0IGRvZXMgbm90IGV4aXN0 IHRoZXJlIGlzDQo+IG5vdGhpbmcgaW4gdGhpcyBvciBhbnkgZG9jdW1lbnQgdGhhdCBwcm92aWRl cyB0aGlzIGZ1bmN0aW9uYWxpdHkuDQo+IEhlbmNlLCBJIGFtIGFsc28gc3VnZ2VzdGluZyB0byBj aGFuZ2UgdGhlIHRleHQgYWNjb3JkaW5nbHk6DQo+IA0KPiBGUk9NOg0KPiANCj4gVGhpcyBzeW1t ZXRyaWMga2V5IGlzIGVuY3J5cHRlZCB3aXRoIGEga2V5IGtub3duIG9ubHkgdG8gdGhlIGlzc3Vl ciBhbmQgdGhlDQo+IHJlY2lwaWVudCwgd2hpY2ggaXMgZXN0YWJsaXNoZWQgaW4gc3RlcCAoMiks IGlmIGl0IGRvZXNuJ3QgYWxyZWFkeSBleGlzdC4NCj4gDQo+IFRPOg0KPiANCj4gVGhpcyBzeW1t ZXRyaWMga2V5IGlzIGVuY3J5cHRlZCB3aXRoIGEga2V5IGtub3duIG9ubHkgdG8gdGhlIGlzc3Vl ciBhbmQgdGhlDQo+IHJlY2lwaWVudC4NCj4gDQo+IFRoZSBwcm9ibGVtIHdpdGggZHluYW1pY2Fs bHkgZXN0YWJsaXNoaW5nIGtleXMgaXMgdGhhdCB3ZSBhcmUgdGhlbiByZXF1aXJpbmcNCj4geWV0 IGFub3RoZXIga2V5IHRvIGJlIGluIHBsYWNlIHRvIGFsbG93IHRoaXMgcHJvY2VkdXJlIHRvIGhh cHBlbiBzZWN1cmVseS4NCj4gV2l0aG91dCBhbnl0aGluZyBpbiBwbGFjZSB3ZSBhcmUgcXVpY2ts eSB2dWxuZXJhYmxlIHRvIHZhcmlvdXMgYXR0YWNrcy4NCj4gDQo+IA0KPiBGUk9NOg0KPiANCj4g SW4gdGhlIGNhc2UgaWxsdXN0cmF0ZWQgaW4gRmlndXJlIDEsIHRoZSBwcmVzZW50ZXIgZ2VuZXJh dGVzIGEgc3ltbWV0cmljIGtleQ0KPiBhbmQgKDEpIHByaXZhdGVseSBzZW5kcyBpdCB0byB0aGUg aXNzdWVyLg0KPiANCj4gVE86DQo+IA0KPiBJbiB0aGUgY2FzZSBpbGx1c3RyYXRlZCBpbiBGaWd1 cmUgMSwgdGhlIHByZXNlbnRlciBnZW5lcmF0ZXMgYSBzeW1tZXRyaWMga2V5DQo+IGFuZCBpbiAo MSkgc2VuZHMgaXQgdG8gdGhlIGlzc3Vlci4gVGhlIGtleSB0cmFuc3BvcnQgaXMgY29uZmlkZW50 aWFsaXR5DQo+IHByb3RlY3RlZC4NCg0KT0sgLSBJIGNhbiBtYWtlIGNoYW5nZXMgYWxvbmcgdGhl c2UgbGluZXMuICBJJ2xsIHRlbnRhdGl2ZWx5IHBsYW4gb24gbGFiZWxsaW5nIHRoZSBrZXkgZXhj aGFuZ2UgZm9yIHRoZSBrZXkgZW5jcnlwdGlvbiBrZXkgYXMgKDApIGluIHRoZSBkaWFncmFtLCBh bmQgcmVmZXJyaW5nIHRvIGl0IGFzIHN1Y2ggaW4gdGhlIHRleHQuICBJJ2xsIHNlbmQgdGhlIHJl dmlzZWQgdGV4dCB0byB5b3UgYW5kIHRoZSBvdGhlciBlZGl0b3IgZm9yIHJldmlldyBiZWZvcmUg cHVibGljYXRpb24uDQoNCj4gKiogQ05GIENsYWltDQo+IA0KPiBJIGFsc28gaGF2ZSBhIHF1ZXN0 aW9uIHJlZ2FyZGluZyB0aGlzIHBhcmFncmFwaCBmcm9tIFNlY3Rpb24gMy4xLiBXaGF0IGRvZXMg aXQNCj4gbWVhbiB0byBoYXZlIG90aGVyIG1lbWJlcnMgb2YgdGhlICJjbmYiIGNsYWltPw0KDQpJ dCBtZWFucyB0aGF0IGFkZGl0aW9uYWwgbWV0aG9kcyBvZiBjb25maXJtaW5nIHRoZSBhdXRoZW50 aWNpdHkgb2YgdGhlIHRva2VuIG1heSBiZSBkZWZpbmVkIGluIHRoZSBmdXR1cmUuICBUaGV5IHdp bGwgYmUgcmVnaXN0ZXJlZCBpbiB0aGUgSldUIENvbmZpcm1hdGlvbiBNZXRob2RzIFJlZ2lzdHJ5 IGVzdGFibGlzaGVkIGluIFNlY3Rpb24gNi4yLiAgQXMgYW4gZXhhbXBsZSwgU0FNTCBoYXMgYW4g SVAgQWRkcmVzcyBjb25maXJtYXRpb24gbWV0aG9kLiAgV2hpbGUgSSdtIG5vdCByZWNvbW1lbmRp bmcgdGhhdCB3ZSBkZWZpbmUgYW4gZXF1aXZhbGVudCBjb25maXJtYXRpb24gbWV0aG9kIGhlcmUs IGl0J3MgYW4gZXhhbXBsZSBzaG93aW5nIHRoYXQgd2UgaGF2ZW4ndCBjb3ZlcmVkIHRoZSBjb21w bGV0ZSBzcGVjdHJ1bSBvZiBwb3NzaWJsZSBjb25maXJtYXRpb24gbWV0aG9kcy4NCg0KPiBXaGF0 IGlzIHRoZSBzZW1hbnRpYyBvZiB0aGVzZSB0d28gZXhhbXBsZXM6DQo+IA0KPiB7DQo+ICJpc3Mi OiAiaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20iLA0KPiAiYXVkIjogImh0dHBzOi8vY2xpZW50 LmV4YW1wbGUub3JnIiwNCj4gImV4cCI6ICIxMzYxMzk4ODI0IiwNCj4gImNuZiI6ew0KPiAiandr Ijp7Li4ufSwNCj4gImp3ayI6ey4uLn0NCj4gfQ0KPiB9DQoNClRoZSBleGFtcGxlIGFib3ZlIGlz IGludmFsaWQsIHNpbmNlIGl0IGNvbnRhaW5zIHR3byAiandrIiBtZW1iZXJzLiAgSldUIHBhcnNl cnMgc2hvdWxkIHJlamVjdCBzdWNoIGlucHV0LCBwZXIgU2VjdGlvbiA0IG9mIFJGQyA3NTE5Lg0K DQo+IHsNCj4gImlzcyI6ICJodHRwczovL3NlcnZlci5leGFtcGxlLmNvbSIsDQo+ICJhdWQiOiAi aHR0cHM6Ly9jbGllbnQuZXhhbXBsZS5vcmciLA0KPiAiZXhwIjogIjEzNjEzOTg4MjQiLA0KPiAi Y25mIjp7DQo+ICJqd2siOnsuLi59LA0KPiAiandlIjp7Li4ufSwNCj4gImtpZCI6Ii4uLiINCj4g fQ0KPiB9DQoNClRoaXMgZXhhbXBsZSBpcyBhbWJpZ3VvdXMgYW5kIG1hbGZvcm1lZCwgc2luY2Ug aXQgY29udGFpbnMgdHdvIGtleXMgYW5kIG1heSByZWZlciB0byBhIHRoaXJkIG9uZSAtIG9uZSBp biB0aGUgImp3ayIgZWxlbWVudCwgb25lIGluIHRoZSAiandlIiBlbGVtZW50LCBhbmQgcG9zc2li bHkgYSBkaWZmZXJlbnQgb25lIGJlaW5nIHJlZmVyZW5jZWQgYnkgdGhlICJraWQiIGVsZW1lbnQu ICBJJ2xsIHBsYW4gdG8gYWRkIGxhbmd1YWdlIHNheWluZyB0aGF0IG9ubHkgYSBzaW5nbGUgY29u ZmlybWF0aW9uIGtleSBpcyBpbnRlbmRlZCB0byBiZSBjb21tdW5pY2F0ZWQgaW4gdGhlICJjbmYi IGNsYWltIGFuZCB0aGF0IHVzZXMgaW4gd2hpY2ggbXVsdGlwbGUga2V5cyBhcmUgY29tbXVuaWNh dGVkIGFuZC9vciByZWZlcmVuY2VkIGluIHRoZSAiY25mIiB2YWx1ZSBhcmUgc3ludGFjdGljYWxs eSBpbnZhbGlkLg0KDQo+IEhlcmUgaXMgdGhlIHJlbGV2YW50IHRleHQ6DQo+IA0KPiAiDQo+IDMu MS4gQ29uZmlybWF0aW9uIENsYWltDQo+IA0KPiBUaGUgImNuZiIgKGNvbmZpcm1hdGlvbikgY2xh aW0gaXMgdXNlZCBpbiB0aGUgSldUIHRvIGNvbnRhaW4gbWVtYmVycyB1c2VkIHRvDQo+IGlkZW50 aWZ5IHRoZSBwcm9vZi1vZi1wb3NzZXNzaW9uIGtleS4gT3RoZXIgbWVtYmVycyBvZiB0aGUgImNu ZiIgb2JqZWN0DQo+IG1heSBiZSBkZWZpbmVkIGJlY2F1c2UgYSBwcm9vZi1vZi1wb3NzZXNzaW9u IGtleSBtYXkgbm90IGJlIHRoZSBvbmx5DQo+IG1lYW5zIG9mIGNvbmZpcm1pbmcgdGhlIGF1dGhl bnRpY2l0eSBvZiB0aGUgdG9rZW4uIFRoaXMgaXMgYW5hbG9nb3VzIHRvIHRoZQ0KPiBTQU1MIDIu MCBbT0FTSVMuc2FtbC1jb3JlLTIuMC1vc10gU3ViamVjdENvbmZpcm1hdGlvbiBlbGVtZW50LCBp biB3aGljaCBhDQo+IG51bWJlciBvZiBkaWZmZXJlbnQgc3ViamVjdCBjb25maXJtYXRpb24gbWV0 aG9kcyBjYW4gYmUgaW5jbHVkZWQsIGluY2x1ZGluZw0KPiBwcm9vZi1vZi1wb3NzZXNzaW9uIGtl eSBpbmZvcm1hdGlvbi4gV2hlbiBhIHJlY2lwaWVudCByZWNlaXZlcyBhICJjbmYiIGNsYWltDQo+ IHdpdGggYSBtZW1iZXIgdGhhdCBpdCBkb2VzIG5vdCB1bmRlcnN0YW5kLCBpdCBNVVNUIGlnbm9y ZSB0aGF0IG1lbWJlci4NCj4gDQo+IC4uLg0KPiANCj4gTm90ZSB0aGF0IGlmIGFuIGFwcGxpY2F0 aW9uIG5lZWRzIHRvIHJlcHJlc2VudCBtdWx0aXBsZSBwcm9vZi1vZi0gcG9zc2Vzc2lvbg0KPiBr ZXlzIGluIHRoZSBzYW1lIEpXVCwgb25lIHdheSBmb3IgaXQgdG8gYWNoaWV2ZSB0aGlzIGlzIHRv IHVzZSBvdGhlciBjbGFpbQ0KPiBuYW1lcywgaW4gYWRkaXRpb24gdG8gImNuZiIsIHRvIGhvbGQg dGhlIGFkZGl0aW9uYWwgcHJvb2Ytb2YtcG9zc2Vzc2lvbiBrZXkNCj4gaW5mb3JtYXRpb24uIFRo ZXNlIGNsYWltcyBjb3VsZCB1c2UgdGhlIHNhbWUgc3ludGF4IGFuZCBzZW1hbnRpY3MgYXMgdGhl DQo+ICJjbmYiIGNsYWltLg0KPiAiDQo+IA0KPiAqKiBLZXkgSUQNCj4gDQo+IExhY2sgb2YgaW50 ZXJvcGVyYWJpbGl0eSBmb3IgdGhlIEtleSBJRCBmdW5jdGlvbmFsaXR5IGRlc2NyaWJlZCBpbiBT ZWN0aW9uIDMuNC4NCj4gDQo+IFRoZSB0ZXh0IHNheXMgdGhhdA0KPiANCj4gIlRoZSBjb250ZW50 IG9mIHRoZSAia2lkIiB2YWx1ZSBpcyBhcHBsaWNhdGlvbiBzcGVjaWZpYy4gRm9yIGluc3RhbmNl LCBzb21lDQo+IGFwcGxpY2F0aW9ucyBtYXkgY2hvb3NlIHRvIHVzZSBhIEpXSyBUaHVtYnByaW50 IFtKV0suVGh1bWJwcmludF0gdmFsdWUgYXMNCj4gdGhlICJraWQiIHZhbHVlLiINCj4gDQo+IEkg dGhpbmsgd2Ugc2hvdWxkIHNldHRsZSBmb3Igc29tZXRoaW5nIGFuZCB0aGVuIGFsbG93IG90aGVy IGtleSBpZCB0eXBlcyB0bw0KPiBiZSB1c2VkIGFzIHdlbGwuDQoNClRoaXMgaXMgZXhhY3RseSB0 aGUgc2FtZSBhcyB0aGUgImtpZCIgdXNhZ2UgaW4gSldUIFtSRkMgNzUxOV0sIGJ5IGRlc2lnbi4g IEl0J3MgdXAgdG8gdGhlIGFwcGxpY2F0aW9uIHdoYXQgbGFiZWxzIHRvIHVzZSB0byBpZGVudGlm eSB0aGUga2V5cyB0aGF0IGl0IGNyZWF0ZXMuICBJdCBjYW4gbGFiZWwgdGhlbSAiMSIsICIyIiwg IjMiLCAuLi4uICBJdCBjYW4gbGFiZWwgdGhlbSB3aXRoIHRoZSBkYXRlIGNyZWF0ZWQsIHN1Y2gg YXMgIjE2LU5vdi0yMDE1Ii4gIEFuZCB5ZXMsIGl0IGNvdWxkIHVzZSBhbiAieDV0IiBvciBKV0sg VGh1bWJwcmludCB2YWx1ZS4gIE5vcm1hbGx5LCBpdCBkb2Vzbid0IG1hdHRlciB3aGF0IHRoZSBr ZXkgY3JlYXRvciBjaG9vc2VzIGFzIHRoZSBLZXkgSUQgdmFsdWUsIHNpbmNlIG90aGVyIHVzZXJz IG9mIHRoZSBrZXkganVzdCB1c2UgdGhlICJraWQiIHZhbHVlIGNyZWF0ZWQgYWxvbmcgd2l0aCB0 aGUga2V5IHZlcmJhdGltLiAgVGhlIGZhY3QgdGhhdCBvZnRlbiBib3RoIHBhcnRpZXMgZG9uJ3Qg bmVlZCB0byBrbm93IGhvdyBhIGtleSBJRCBpcyBjcmVhdGVkIGlzIGRlc2NyaWJlZCBpbiBwYXJh Z3JhcGggMiBvZiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3NjM4I3NlY3Rpb24tMy40 LiAgSW4gc2hvcnQsIHRoZXJlJ3Mgbm8gcmVhc29uIHRvIGdvIGJleW9uZCB3aGF0IEpXVCBkb2Vz IGluIGRlZmluaW5nIGhvdyAia2lkIiB2YWx1ZXMgYXJlIHVzZWQgLSBhbmQgdGhlcmUgYXJlIGdv b2QgcmVhc29ucyBub3QgdG8gZG8gc28uDQoNCj4gKiogTm9uY2UgQ2xhaW0NCj4gDQo+IFRoaXMg ZXhhbXBsZSBpbiBTZWN0aW9uIDMuMyB1c2VzIGEgY2xhaW0gdHlwZSwgbmFtZWx5IG5vbmNlLCB3 aGljaCBoYXMgbm90DQo+IGJlZW4gZGVmaW5lZCB5ZXQuIEkgdGhlcmVmb3JlIHN1Z2dlc3QgdG8g cmVtb3ZlIGl0IGZyb20gdGhpcyBleGFtcGxlIHNpbmNlIGl0DQo+IGRvZXMgbm90IGZ1bGZpbCBh IHB1cnBvc2UuDQo+IA0KPiBIZXJlIGlzIHRoZSBleGFtcGxlOg0KPiANCj4gew0KPiAiaXNzIjog Imh0dHBzOi8vc2VydmVyLmV4YW1wbGUuY29tIiwNCj4gInN1YiI6ICIyNDQwMDMyMCIsDQo+ICJh dWQiOiAiczZCaGRSa3F0MyIsDQo+ICJub25jZSI6ICJuLTBTNl9XekEyTWoiLA0KPiAiZXhwIjog MTMxMTI4MTk3MCwNCj4gImlhdCI6IDEzMTEyODA5NzAsDQo+ICJjbmYiOnsNCj4gImp3ZSI6DQo+ ICJleUpoYkdjaU9pSlNVMEV0VDBGRlVDSXNJbVZ1WXlJNklrRXhNamhEUWtNdFNGTXlOVFlpZlEu DQo+IChyZW1haW5kZXIgb2YgSldFIG9taXR0ZWQgZm9yIGJyZXZpdHkpIg0KPiB9DQo+IH0NCg0K VGhlICJub25jZSIgY2xhaW0gKmlzKiBkZWZpbmVkIGFuZCByZWdpc3RlcmVkIGluIHRoZSBJQU5B IEpXVCBDbGFpbXMgUmVnaXN0cnkgYXQgaHR0cDovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9q d3Qvand0LnhodG1sLg0KDQo+IENpYW8NCj4gSGFubmVzDQoNCgkJCQlUaGFua3MgYWdhaW4sDQoJ CQkJLS0gTWlrZQ0KDQo= From nobody Mon Nov 16 13:55:08 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D962B1B3144 for ; Mon, 16 Nov 2015 13:55:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.784 X-Spam-Level: X-Spam-Status: No, score=-2.784 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, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G8uZnc6EvQAV for ; Mon, 16 Nov 2015 13:55:04 -0800 (PST) Received: from nm31-vm1.bullet.mail.bf1.yahoo.com (nm31-vm1.bullet.mail.bf1.yahoo.com [72.30.239.9]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46E1B1B313D for ; Mon, 16 Nov 2015 13:55:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1447710903; bh=UrQdeN+eNPPJaUMWVpbXrTW6HabwtbMha0ViBor65/Q=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=iF9ynehYXT5YlZYUeS1ThUQLhzheKexOScBR4ybbXZvoeLhwgdfHRe+Lem4Q/JfRKBsa/qCPPww/2XbSzkCKGL5RE8MiIiGBdc7Td3nUvX/EiXYitA8PsOpaIUWPuwiR5OjkQodCmSRVDqc05QZw8mHYIHeVtlO/aut/GSOpVRpHb+xtviOBDSm2Ll77cMdp+UgkAoxni7/D5kCGPQ//1AXaoqh1GHI7OtkDkdd+1rB7lrYZNaBLrZHme1eTcFhNlL7elIMg9aRJPV4Beh523VQigAFDTztb2KDHr08/IIuagKOzfvC0nr2fVo0Dq5aInAFWmgjl3PiALanjYc4BxA== Received: from [98.139.215.143] by nm31.bullet.mail.bf1.yahoo.com with NNFMP; 16 Nov 2015 21:55:03 -0000 Received: from [98.139.212.233] by tm14.bullet.mail.bf1.yahoo.com with NNFMP; 16 Nov 2015 21:55:03 -0000 Received: from [127.0.0.1] by omp1042.mail.bf1.yahoo.com with NNFMP; 16 Nov 2015 21:55:03 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 268461.9154.bm@omp1042.mail.bf1.yahoo.com X-YMail-OSG: v8TadEwVM1lh6uRY_RFhdpxBfTWrh5yUWLSgsfyIvPGiapYMbfNuPRvUbL8F_Xl q7_lM.79IOFlpovfYF0KORpGS51IR63.YEBccG27T5HSKnbbDPzywoBXM.o3UqAutdc92x6WIwDm i2nwpTKyHD5L_2dnx6NH5sptpTw3YBieaDRRi6qRuRZl7Jjuu8wzVl2PfaKeDwN0Y_fjh48GmBUj 17z841A0MIh5cBc2a.Z9j97tQ0RfMjrGmDoIPVp5z_gREuxrh.PktHizGwRAX7r1UDWa5eqvlPyV N87qisbcgXB4TTOR0HyWqUq2Cl8vzlV1ZfssIie7jNUHLbCB.ClkxxCmK7dMpi1qUVnotDYls5mN DkXwnS4T1QImWyFd9qCWJDQ9ZwmYS45MYkyA9V7NF2wTA7L76ejyhCOJUa.oiPLbs7Jl.oX7.gzp pGwnCtd4qTrUhq3DGPjc_vqQ4McclZoQXyQR5ThU0DWwFMoXxbxOaXCXfciyJp_X0uw.0iWODp88 O5VuUPsiDwuegeYOVB8VEBkyNUPKh4f692OWmifQ- Received: by 66.196.80.146; Mon, 16 Nov 2015 21:55:02 +0000 Date: Mon, 16 Nov 2015 21:54:52 +0000 (UTC) From: Bill Mills To: William Denniss , Hannes Tschofenig Message-ID: <364007597.6139430.1447710892429.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_6139429_1436115240.1447710892409" Archived-At: Cc: Carsten Bormann , "" Subject: Re: [OAUTH-WG] [COSE] A draft on CBOR Web Tokens (CWT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2015 21:55:08 -0000 ------=_Part_6139429_1436115240.1447710892409 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable If there are structural differences in what CBOR can support it would be wo= rthwhile to note that. =C2=A0Examples of things supported in JWT that you c= an't do in CBOR could be very helpful to implementers. =20 On Monday, November 16, 2015 1:32 PM, William Denniss wrote: =20 You raise some good points, and perhaps that is relevant to future claims.= The spec as drafted, is a one-for-one copy of the standard JWT claims, whi= ch is why I raised this point. Is the goal a CBOR representation of a JWT? If so, can it be defined in ter= ms of a JWT?=C2=A0 Would the CNF claim then inherit that representation (tr= eating the JWE and JWK as their CBOR equivalents)? Perhaps if you go the separate registry route, those claims that *are* defi= ned the same should at least normatively reference JWT?=C2=A0 I want to avo= id the whole "on behalf of" / "act as" fiasco where things can get re-defin= ed, and muddled. On Mon, Nov 16, 2015 at 7:09 AM, Hannes Tschofenig wrote: Hi William,=C2=A0I have been trying to do a document update to see how well= a combined registry works and I have been wondering whether it is really w= orth the effort.To make a good judgment I looked at the CNF claim defined i= n draft-ietf-oauth-proof-of-possession. The CNF claim may contain sub-eleme= nts, such as a JWE or a JWK.=C2=A0If we translate the same mechanisms to th= e CWT (which makes sense) then we need to point to the respective COSE stru= ctures instead. Those do not only use a different encoding but also the fun= ctionality does not match the JOSE structures 100%. So, there are potential= ly differences. I am also not sure whether we really want to translate the = full functionality of all the claims from JWT over to the CWT equivalent. I= t basically puts the burden on someone defining new claims (either in JWT o= r in CWT) to create the corresponding structures in a format they may not n= ecessarily be familiar with or even care about. I have seen that happening = in the RADIUS world protocol designers had to also define the equivalent st= ructures for use with Diameter and, guess what, most of the definitions wer= e wrong (since the authors did not care about Diameter when working on RADI= US).=C2=A0Ciao Hannes=C2=A0=C2=A0From: William Denniss [mailto:wdenniss@google.com] Sent: 12 November 2015 19:19 To: Erik Wahlstr=C3=B6m neXus Cc: Carsten Bormann; Hannes Tschofenig; Mike Jones; cose@ietf.org; ; ace@ietf.org Subject: Re: [COSE] A draft on CBOR Web Tokens (CWT)=C2=A0Regarding the dra= ft itself, a few comments:=C2=A01.=C2=A0Can we unify the claim registry wit= h JWT? I'm worried about having the same claims defined twice in CWT and JW= T with possibly conflicting meanings (and needless confusion even when they= do match).=C2=A0=C2=A0Comparing=C2=A0https://tools.ietf.org/html/draft-wah= lstroem-oauth-cbor-web-token-00#section-3.1.2 and=C2=A0https://tools.ietf.o= rg/html/rfc7519#section-4.1.2 which are nearly identical, I just don't see = the value in re-defining it.=C2=A0We may add new standard claims to JWT in = the future (I=C2=A0proposed one=C2=A0in Yokohama on the=C2=A0id-event list)= , it would be good if this didn't need a separate entry in CWT too, but cou= ld just apply directly (separately, I think you should consider this claim,= as it helps prevent tokens from being re-used in the wrong context).=C2=A0= 2.Is Section 4 "Summary of CBOR major types used by defined claims" normati= ve (https://tools.ietf.org/html/draft-wahlstroem-oauth-cbor-web-token-00#se= ction-4)? What is the intention of this section? I feel like it could proba= bly be fleshed out a bit.=C2=A03.=C2=A0Add a xref to draft COSE spec in=C2= =A0section 6Add xref to RFC7519=C2=A0On Thu, Nov 12, 2015 at 12:01 PM, Erik= Wahlstr=C3=B6m neXus wrote:Hi Carsten, Thanks, and I agree. I=E2=80=99ve heard arguments for all three work groups= . Borrowed some of your words to define the content of the draft :) It=E2=80=99s it essentially a JWT, phrased in and profiled for CBOR to addr= ess ACE needs, where OAuth needs COSE functionality, for object security. I=E2=80=99m open for letting the AD=E2=80=99s move it around, but having it= right next to JWT seems right to me. Also open for the ACE WG. Feel it has= less place in COSE for the same reasons JWT is not in the JOSE WG. / Erik > On 12 Nov 2015, at 20:45, Carsten Bormann wrote: > > Hi Erik, > > having this draft is a good thing. > > One thing I'm still wondering is what WG is the best place to progress > this.=C2=A0 We probably don't need to spend too much time on this because= , > regardless of the WG chosen, the people in another WG can look at it. > Still, getting this right might provide some efficiencies. > > What is the technical content of this draft?=C2=A0 Is it a new token that > OAuth needs specifically for the new COSE-based applications of OAuth? > Is it a new token that is specifically there for addressing ACE needs? > Or is it essentially the same substance as JWT, but phrased in and > profiled for CBOR? > > Depending on the answer, CWT should be done in OAuth, ACE, or COSE. > (I'd rather hear the answer from the authors than venture a guess myself.= ) > > Gr=C3=BC=C3=9Fe, Carsten > > > > Erik Wahlstr=C3=B6m neXus wrote: >> Hi, >> >> In the ACE WG a straw man proposal of a CBOR Web Token (CWT) was defined >> in the draft "Authorization for the Internet of Things using OAuth 2.0= =E2=80=9D >> [1]. We just broke out the CBOR Web Token into a separate draft and the >> new draft is submitted to the OAUTH WG. It can be found here: >> >> https://datatracker.ietf.org/doc/draft-wahlstroem-oauth-cbor-web-token/ >> >> Abstract: >> "CBOR Web Token (CWT) is a compact means of representing claims to be >> transferred between two parties.=C2=A0 CWT is a profile of the JSON Web = Token >> (JWT) that is optimized for constrained devices. The claims in a CWT are >> encoded in the Concise Binary Object Representation (CBOR) and CBOR >> Object Signing and Encryption (COSE) is used for added application layer >> security protection.=C2=A0 A claim is a piece of information asserted ab= out a >> subject and is represented as a name/value pair consisting of a claim >> name and a claim value." >> >> / Erik >> >> >> [1] https://tools.ietf.org/html/draft-seitz-ace-oauth-authz-00 >> >> >> _______________________________________________ >> COSE mailing list >> COSE@ietf.org >> https://www.ietf.org/mailman/listinfo/cose _______________________________________________ COSE mailing list COSE@ietf.org https://www.ietf.org/mailman/listinfo/cose=C2=A0 -- IMPORTANT NOTICE: The contents of this email and any attachments are con= fidential and may also be privileged. If you are not the intended recipient= , please notify the sender immediately and do not disclose the contents to = any other person, use it for any purpose, or store or copy the information = in any medium. Thank you. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ------=_Part_6139429_1436115240.1447710892409 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
If there are structural differ= ences in what CBOR can support it would be worthwhile to note that.  E= xamples of things supported in JWT that you can't do in CBOR could be very = helpful to implementers.




<= /div>
On Monday, November = 16, 2015 1:32 PM, William Denniss <wdenniss@google.com> wrote:


You raise some good points, and perhaps that is = relevant to future claims. The spec as drafted, is a one-for-one copy of th= e standard JWT claims, which is why I raised this point.

Is the goal a CBOR representation of a JWT? If so, can it b= e defined in terms of a JWT?  Would the CNF claim then inherit that re= presentation (treating the JWE and JWK as their CBOR equivalents)?

Perhaps if you go the separate registry rou= te, those claims that *are* defined the same should at least normatively re= ference JWT?  I want to avoid the whole "on behalf of" / "act as" fias= co where things can get re-defined, and muddled.

On Mon, Nov 16, 2015 at 7:09 AM, Hannes Tschofenig &= lt;Hannes.= Tschofenig@arm.com> wrote:
Hi = William,
=  
I h= ave been trying to do a document update to see how well a combined registry= works and I have been wondering whether it is really worth the effort.
To = make a good judgment I looked at the CNF claim defined in draft-ietf-oauth-= proof-of-possession. The CNF claim may contain sub-elements, such as a JWE = or a JWK.
=  
If = we translate the same mechanisms to the CWT (which makes sense) then we nee= d to point to the respective COSE structures instead. Those do not only use= a different encoding but also the functionality does not match the JOSE stru= ctures 100%. So, there are potentially differences. I am also not sure whet= her we really want to translate the full functionality of all the claims fr= om JWT over to the CWT equivalent. It basically puts the burden on someone defining new claims (either in JWT= or in CWT) to create the corresponding structures in a format they may not= necessarily be familiar with or even care about. I have seen that happenin= g in the RADIUS world protocol designers had to also define the equivalent structures for use with Diameter and, gu= ess what, most of the definitions were wrong (since the authors did not car= e about Diameter when working on RADIUS).
=  
Cia= o
Hannes
=  
=  
From: William Denniss [mailto:wdenniss@google.com]
Sent: 12 November 2015 19:19
To: Erik Wahlstr=C3=B6m neXus
Cc: Carsten Bormann; Hannes Tschofenig; Mike Jones; cose@ietf.org; <oauth@ietf.org>; ace@ietf.org
Subject: Re: [COSE] A draft on CBOR Web Tokens (CWT)
 
Regarding the draft itself, a few com= ments:
 
1. 
Can we unify the claim registry with = JWT? I'm worried about having the same claims defined twice in CWT and JWT = with possibly conflicting meanings (and needless confusion even when they d= o match). 
 
Comparing https://tools.ietf.org/html= /draft-wahlstroem-oauth-cbor-web-token-00#section-3.1.2 and https://tools.ietf.org/html/rfc7519#section-= 4.1.2 which are nearly identical, I just don't see the value in re-defining it.<= u>
 
We may add new standard claims to JWT= in the future (I proposed one in= Yokohama on the id-event list), it would be good if this didn't need a separate entry in CWT to= o, but could just apply directly (separately, I think you should consider t= his claim, as it helps prevent tokens from being re-used in the wrong conte= xt).
 
2.
Is Section 4 "Summary of CBOR major t= ypes used by defined claims" normative (https://tools.ietf.org/html/draft-wahlstroem= -oauth-cbor-web-token-00#section-4)? What is the intention of this section? I feel like it could probably be fl= eshed out a bit.
 
3. 
Add a xref to draft COSE spec in = ;section = 6
Add xref to RFC7519
 
On Thu, Nov 12, 2015 at 12:01 PM, Eri= k Wahlstr=C3=B6m neXus <erik.wahlstrom@nexusgroup.com> wrote:
Hi Carsten,

Thanks, and I agree. I=E2=80=99ve heard arguments for all three work groups= .

Borrowed some of your words to define the content of the draft :)
It=E2=80=99s it essentially a JWT, phrased in and profiled for CBOR to addr= ess ACE needs, where OAuth needs COSE functionality, for object security.
I=E2=80=99m open for letting the AD=E2=80=99s move it around, but having it= right next to JWT seems right to me. Also open for the ACE WG. Feel it has= less place in COSE for the same reasons JWT is not in the JOSE WG.

/ Erik


> On 12 Nov 2015, at 20:45, Carsten Bormann <cabo@tzi.org> wrote:
>
> Hi Erik,
>
> having this draft is a good thing.
>
> One thing I'm still wondering is what WG is the best place to progress=
> this.  We probably don't need to spend too much time on this beca= use,
> regardless of the WG chosen, the people in another WG can look at it.<= br clear=3D"none"> > Still, getting this right might provide some efficiencies.
>
> What is the technical content of this draft?  Is it a new token t= hat
> OAuth needs specifically for the new COSE-based applications of OAuth?=
> Is it a new token that is specifically there for addressing ACE needs?=
> Or is it essentially the same substance as JWT, but phrased in and
> profiled for CBOR?
>
> Depending on the answer, CWT should be done in OAuth, ACE, or COSE. > (I'd rather hear the answer from the authors than venture a guess myse= lf.)
>
> Gr=C3=BC=C3=9Fe, Carsten
>
>
>
> Erik Wahlstr=C3=B6m neXus wrote:
>> Hi,
>>
>> In the ACE WG a straw man proposal of a CBOR Web Token (CWT) was d= efined
>> in the draft "Authorization for the Internet of Things using OAuth= 2.0=E2=80=9D
>> [1]. We just broke out the CBOR Web Token into a separate draft an= d the
>> new draft is submitted to the OAUTH WG. It can be found here:
>>
>> https://datatracker.ietf.org/doc/draft-wahlstroem-oauth-cbor-web-token/=
>>
>> Abstract:
>> "CBOR Web Token (CWT) is a compact means of representing claims to= be
>> transferred between two parties.  CWT is a profile of the JSO= N Web Token
>> (JWT) that is optimized for constrained devices. The claims in a C= WT are
>> encoded in the Concise Binary Object Representation (CBOR) and CBO= R
>> Object Signing and Encryption (COSE) is used for added application= layer
>> security protection.  A claim is a piece of information asser= ted about a
>> subject and is represented as a name/value pair consisting of a cl= aim
>> name and a claim value."
>>
>> / Erik
>>
>>
>> [1] https://tools.ietf.org/html/draft-seitz-ace-oauth-authz-00
>>
>>
>> _______________________________________________
>> COSE mailing list
>> COSE@ietf.org
>> https://www.ietf.org/mailman/listinf= o/cose

_______________________________________________
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose
 


-- IMPORTANT NOTICE: The contents of this email and any attachments are con= fidential and may also be privileged. If you are not the intended recipient= , please notify the sender immediately and do not disclose the contents to = any other person, use it for any purpose, or store or copy the information in any medium. Thank you.




=
------=_Part_6139429_1436115240.1447710892409-- From nobody Mon Nov 16 14:32:05 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66FED1A8972 for ; Mon, 16 Nov 2015 14:32:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TQlcSS7H6DHS for ; Mon, 16 Nov 2015 14:32:01 -0800 (PST) Received: from relay6-d.mail.gandi.net (relay6-d.mail.gandi.net [217.70.183.198]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 094FD1A896C for ; Mon, 16 Nov 2015 14:32:01 -0800 (PST) Received: from mfilter19-d.gandi.net (mfilter19-d.gandi.net [217.70.178.147]) by relay6-d.mail.gandi.net (Postfix) with ESMTP id 4CB9EFB886; Mon, 16 Nov 2015 23:31:59 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter19-d.gandi.net Received: from relay6-d.mail.gandi.net ([IPv6:::ffff:217.70.183.198]) by mfilter19-d.gandi.net (mfilter19-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id H3jyGUxlnCI0; Mon, 16 Nov 2015 23:31:58 +0100 (CET) X-Originating-IP: 178.26.22.158 Received: from nar.local (ipb21a169e.dynamic.kabel-deutschland.de [178.26.22.158]) (Authenticated sender: cabo@cabo.im) by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id 9E8A0FB87E; Mon, 16 Nov 2015 23:31:57 +0100 (CET) Message-ID: <564A595B.5030905@tzi.org> Date: Mon, 16 Nov 2015 23:31:55 +0100 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Bill Mills References: <364007597.6139430.1447710892429.JavaMail.yahoo@mail.yahoo.com> <564A58CE.2040908@tzi.org> In-Reply-To: <564A58CE.2040908@tzi.org> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "" Subject: Re: [OAUTH-WG] [COSE] A draft on CBOR Web Tokens (CWT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2015 22:32:02 -0000 Bill Mills wrote: > If there are structural differences in what CBOR can support it would be > worthwhile to note that. Examples of things supported in JWT that you > can't do in CBOR could be very helpful to implementers. Those don't exist, but there may be things you have to do in JSON that you can (and want to) do in a better way in CBOR. Grüße, Carsten From nobody Mon Nov 16 23:26:01 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9B481B2BCC for ; Mon, 16 Nov 2015 23:22:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cG2o5NgrAYyp for ; Mon, 16 Nov 2015 23:22:47 -0800 (PST) Received: from eu-smtp-delivery-143.mimecast.com (eu-smtp-delivery-143.mimecast.com [146.101.78.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41B591B2BCB for ; Mon, 16 Nov 2015 23:22:46 -0800 (PST) Received: from emea-cam-gw1.Emea.Arm.com (fw-tnat.cambridge.arm.com [217.140.96.140]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-31-QIHZRZLbTpSltOBEVznyuw-1; Tue, 17 Nov 2015 07:22:43 +0000 Received: from GB-CAM-EXCAS2.Emea.Arm.com (10.1.106.66) by emea-cam-gw1.Emea.Arm.com (10.1.248.203) with Microsoft SMTP Server (TLS) id 8.3.298.1; Tue, 17 Nov 2015 07:22:42 +0000 Received: from emea01-db3-obe.outbound.protection.outlook.com (10.1.2.79) by nebula.arm.com (10.1.106.66) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 17 Nov 2015 07:22:41 +0000 Received: from HE1PR08MB0732.eurprd08.prod.outlook.com (10.163.179.30) by HE1PR08MB0729.eurprd08.prod.outlook.com (10.163.179.27) with Microsoft SMTP Server (TLS) id 15.1.325.17; Tue, 17 Nov 2015 07:22:40 +0000 Received: from HE1PR08MB0732.eurprd08.prod.outlook.com ([10.163.179.30]) by HE1PR08MB0732.eurprd08.prod.outlook.com ([10.163.179.30]) with mapi id 15.01.0325.003; Tue, 17 Nov 2015 07:22:40 +0000 From: Hannes Tschofenig To: William Denniss Thread-Topic: [COSE] A draft on CBOR Web Tokens (CWT) Thread-Index: AQHRHX3DyXQEi0Hb60mPSXqbnVxSe56YykQAgAAEkACAAHpjAIAFe1lwgABs4oCAAKM5oA== Date: Tue, 17 Nov 2015 07:22:39 +0000 Message-ID: References: <53BB1987-979C-4945-9C7D-CDB6619AEFFC@nexusgroup.com> <5644EC40.4010002@tzi.org> <73929C18-A3E7-4ACA-A6DC-5A7AD7576C9B@nexusgroup.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [80.92.121.34] x-microsoft-exchange-diagnostics: 1; HE1PR08MB0729; 5:+CZctf+5eO8FrnAdHw87oYCPjCuZIdmOo3wgtGWVqeh4/G29yn1UUAw03jLNVqDGGYgj9z0YpD+j3u20J74BAYTu0DPtFgI1JkXs+Cn9KLNHeYPlfRdbawZJjcyeHlHnyym8pygbArFbRWF9MYFdpw==; 24:8G3KPSAwZqgriAHaUhX6HQvRgH6AG49Zh6OENUlTxwCD7IUSFscquuQP6vCGEz4tBhMB0i4UDGttnwRxnDSYS44XvwC+/nZPd/37T2zhbYw=; 20:Jt+0yU8pFr+GUSnS+HN/g1iaJ/Qw7bvSQSQn0G7/17O44/2hHLpQiutTHenLzt3FB8aI6Gxwi17N/0Gn3x/jdN/yZz2Rhn31wxEzGGtszmFSE7UAn1Hcq7UzkMjxIRxCI9nkNAgLlyeo/hc94eVooR0xgXPdxg+IKJeT/IzuWh0= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR08MB0729; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(211936372134217)(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(520078)(5005006)(10201501046)(3002001); SRVR:HE1PR08MB0729; BCL:0; PCL:0; RULEID:; SRVR:HE1PR08MB0729; x-forefront-prvs: 07630F72AD x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(24454002)(164054003)(40434004)(189002)(377454003)(199003)(76576001)(97736004)(33656002)(19580395003)(5001960100002)(92566002)(2950100001)(74316001)(102836002)(105586002)(81156007)(189998001)(5004730100002)(110136002)(5007970100001)(15975445007)(106116001)(5003600100002)(10400500002)(5890100001)(11100500001)(40100003)(586003)(106356001)(19580405001)(77096005)(101416001)(19300405004)(2900100001)(16236675004)(5008740100001)(50986999)(66066001)(93886004)(19625215002)(561944003)(5002640100001)(86362001)(54356999)(87936001)(76176999)(122556002)(19617315012); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR08MB0729; H:HE1PR08MB0732.eurprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Nov 2015 07:22:40.0462 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR08MB0729 X-OriginatorOrg: arm.com X-MC-Unique: QIHZRZLbTpSltOBEVznyuw-1 Content-Type: multipart/alternative; boundary="_000_HE1PR08MB0732DEC772A47528634F1F5CFA1D0HE1PR08MB0732eurp_" Archived-At: X-Mailman-Approved-At: Mon, 16 Nov 2015 23:25:58 -0800 Cc: "" Subject: Re: [OAUTH-WG] [COSE] A draft on CBOR Web Tokens (CWT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2015 07:22:51 -0000 --_000_HE1PR08MB0732DEC772A47528634F1F5CFA1D0HE1PR08MB0732eurp_ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 SGkgV2lsbGlhbSwNCg0KWW91IGFyZSBpbmRlZWQgY29ycmVjdCB0aGF0IHRoZSBjdXJyZW50IGRv Y3VtZW50IGNvbnRhaW5zIGEgbGlzdCBvZiBvbmUtYnktb25lIGNvcGllcyBvZiBjbGFpbXMgZnJv bSB0aGUgSldULiBUaGUgb25seSBkaWZmZXJlbmNlIGlzIHRoZSBkYXRhIHR5cGUuIFByb2JhYmx5 IGl0IHdvdWxkIGhhdmUgYmVlbiBiZXR0ZXIgdG8ganVzdCByZWZlcmVuY2UgdGhlIHNlbWFudGlj IGZyb20gdGhlIEpXVCBzcGVjIGFuZCB0aGVuIHN0YXRlIHRoZSBuZXcgZGF0YSB0eXBlLg0KDQpJ IGZ1bGx5IHVuZGVyc3RhbmQgdGhlIGNvbmNlcm4gb2YgZGVmaW5pbmcgQ1dUIGNsYWltcyB0aGF0 IGhhdmUgdGhlIHNhbWUgbmFtZSBhcyBKV1QgY2xhaW1zIGJ1dCB0aGVuIGRpZmZlcmVudCBzZW1h bnRpYy4gVGhpcyB3b3VsZCBiZSB0ZXJyaWJseSBjb25mdXNpbmcuDQoNCkNpYW8NCkhhbm5lcw0K DQpGcm9tOiBXaWxsaWFtIERlbm5pc3MgW21haWx0bzp3ZGVubmlzc0Bnb29nbGUuY29tXQ0KU2Vu dDogMTYgTm92ZW1iZXIgMjAxNSAyMjozMg0KVG86IEhhbm5lcyBUc2Nob2ZlbmlnDQpDYzogRXJp ayBXYWhsc3Ryw7ZtIG5lWHVzOyBDYXJzdGVuIEJvcm1hbm47IE1pa2UgSm9uZXM7IDxvYXV0aEBp ZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbQ09TRV0gQSBkcmFmdCBvbiBDQk9SIFdlYiBUb2tlbnMg KENXVCkNCg0KWW91IHJhaXNlIHNvbWUgZ29vZCBwb2ludHMsIGFuZCBwZXJoYXBzIHRoYXQgaXMg cmVsZXZhbnQgdG8gZnV0dXJlIGNsYWltcy4gVGhlIHNwZWMgYXMgZHJhZnRlZCwgaXMgYSBvbmUt Zm9yLW9uZSBjb3B5IG9mIHRoZSBzdGFuZGFyZCBKV1QgY2xhaW1zLCB3aGljaCBpcyB3aHkgSSBy YWlzZWQgdGhpcyBwb2ludC4NCg0KSXMgdGhlIGdvYWwgYSBDQk9SIHJlcHJlc2VudGF0aW9uIG9m IGEgSldUPyBJZiBzbywgY2FuIGl0IGJlIGRlZmluZWQgaW4gdGVybXMgb2YgYSBKV1Q/ICBXb3Vs ZCB0aGUgQ05GIGNsYWltIHRoZW4gaW5oZXJpdCB0aGF0IHJlcHJlc2VudGF0aW9uICh0cmVhdGlu ZyB0aGUgSldFIGFuZCBKV0sgYXMgdGhlaXIgQ0JPUiBlcXVpdmFsZW50cyk/DQoNClBlcmhhcHMg aWYgeW91IGdvIHRoZSBzZXBhcmF0ZSByZWdpc3RyeSByb3V0ZSwgdGhvc2UgY2xhaW1zIHRoYXQg KmFyZSogZGVmaW5lZCB0aGUgc2FtZSBzaG91bGQgYXQgbGVhc3Qgbm9ybWF0aXZlbHkgcmVmZXJl bmNlIEpXVD8gIEkgd2FudCB0byBhdm9pZCB0aGUgd2hvbGUgIm9uIGJlaGFsZiBvZiIgLyAiYWN0 IGFzIiBmaWFzY28gd2hlcmUgdGhpbmdzIGNhbiBnZXQgcmUtZGVmaW5lZCwgYW5kIG11ZGRsZWQu DQoNCk9uIE1vbiwgTm92IDE2LCAyMDE1IGF0IDc6MDkgQU0sIEhhbm5lcyBUc2Nob2ZlbmlnIDxI YW5uZXMuVHNjaG9mZW5pZ0Bhcm0uY29tPG1haWx0bzpIYW5uZXMuVHNjaG9mZW5pZ0Bhcm0uY29t Pj4gd3JvdGU6DQpIaSBXaWxsaWFtLA0KDQpJIGhhdmUgYmVlbiB0cnlpbmcgdG8gZG8gYSBkb2N1 bWVudCB1cGRhdGUgdG8gc2VlIGhvdyB3ZWxsIGEgY29tYmluZWQgcmVnaXN0cnkgd29ya3MgYW5k IEkgaGF2ZSBiZWVuIHdvbmRlcmluZyB3aGV0aGVyIGl0IGlzIHJlYWxseSB3b3J0aCB0aGUgZWZm b3J0Lg0KVG8gbWFrZSBhIGdvb2QganVkZ21lbnQgSSBsb29rZWQgYXQgdGhlIENORiBjbGFpbSBk ZWZpbmVkIGluIGRyYWZ0LWlldGYtb2F1dGgtcHJvb2Ytb2YtcG9zc2Vzc2lvbi4gVGhlIENORiBj bGFpbSBtYXkgY29udGFpbiBzdWItZWxlbWVudHMsIHN1Y2ggYXMgYSBKV0Ugb3IgYSBKV0suDQoN CklmIHdlIHRyYW5zbGF0ZSB0aGUgc2FtZSBtZWNoYW5pc21zIHRvIHRoZSBDV1QgKHdoaWNoIG1h a2VzIHNlbnNlKSB0aGVuIHdlIG5lZWQgdG8gcG9pbnQgdG8gdGhlIHJlc3BlY3RpdmUgQ09TRSBz dHJ1Y3R1cmVzIGluc3RlYWQuIFRob3NlIGRvIG5vdCBvbmx5IHVzZSBhIGRpZmZlcmVudCBlbmNv ZGluZyBidXQgYWxzbyB0aGUgZnVuY3Rpb25hbGl0eSBkb2VzIG5vdCBtYXRjaCB0aGUgSk9TRSBz dHJ1Y3R1cmVzIDEwMCUuIFNvLCB0aGVyZSBhcmUgcG90ZW50aWFsbHkgZGlmZmVyZW5jZXMuIEkg YW0gYWxzbyBub3Qgc3VyZSB3aGV0aGVyIHdlIHJlYWxseSB3YW50IHRvIHRyYW5zbGF0ZSB0aGUg ZnVsbCBmdW5jdGlvbmFsaXR5IG9mIGFsbCB0aGUgY2xhaW1zIGZyb20gSldUIG92ZXIgdG8gdGhl IENXVCBlcXVpdmFsZW50LiBJdCBiYXNpY2FsbHkgcHV0cyB0aGUgYnVyZGVuIG9uIHNvbWVvbmUg ZGVmaW5pbmcgbmV3IGNsYWltcyAoZWl0aGVyIGluIEpXVCBvciBpbiBDV1QpIHRvIGNyZWF0ZSB0 aGUgY29ycmVzcG9uZGluZyBzdHJ1Y3R1cmVzIGluIGEgZm9ybWF0IHRoZXkgbWF5IG5vdCBuZWNl c3NhcmlseSBiZSBmYW1pbGlhciB3aXRoIG9yIGV2ZW4gY2FyZSBhYm91dC4gSSBoYXZlIHNlZW4g dGhhdCBoYXBwZW5pbmcgaW4gdGhlIFJBRElVUyB3b3JsZCBwcm90b2NvbCBkZXNpZ25lcnMgaGFk IHRvIGFsc28gZGVmaW5lIHRoZSBlcXVpdmFsZW50IHN0cnVjdHVyZXMgZm9yIHVzZSB3aXRoIERp YW1ldGVyIGFuZCwgZ3Vlc3Mgd2hhdCwgbW9zdCBvZiB0aGUgZGVmaW5pdGlvbnMgd2VyZSB3cm9u ZyAoc2luY2UgdGhlIGF1dGhvcnMgZGlkIG5vdCBjYXJlIGFib3V0IERpYW1ldGVyIHdoZW4gd29y a2luZyBvbiBSQURJVVMpLg0KDQpDaWFvDQpIYW5uZXMNCg0KDQpGcm9tOiBXaWxsaWFtIERlbm5p c3MgW21haWx0bzp3ZGVubmlzc0Bnb29nbGUuY29tPG1haWx0bzp3ZGVubmlzc0Bnb29nbGUuY29t Pl0NClNlbnQ6IDEyIE5vdmVtYmVyIDIwMTUgMTk6MTkNClRvOiBFcmlrIFdhaGxzdHLDtm0gbmVY dXMNCkNjOiBDYXJzdGVuIEJvcm1hbm47IEhhbm5lcyBUc2Nob2ZlbmlnOyBNaWtlIEpvbmVzOyBj b3NlQGlldGYub3JnPG1haWx0bzpjb3NlQGlldGYub3JnPjsgPG9hdXRoQGlldGYub3JnPG1haWx0 bzpvYXV0aEBpZXRmLm9yZz4+OyBhY2VAaWV0Zi5vcmc8bWFpbHRvOmFjZUBpZXRmLm9yZz4NClN1 YmplY3Q6IFJlOiBbQ09TRV0gQSBkcmFmdCBvbiBDQk9SIFdlYiBUb2tlbnMgKENXVCkNCg0KUmVn YXJkaW5nIHRoZSBkcmFmdCBpdHNlbGYsIGEgZmV3IGNvbW1lbnRzOg0KDQoxLg0KQ2FuIHdlIHVu aWZ5IHRoZSBjbGFpbSByZWdpc3RyeSB3aXRoIEpXVD8gSSdtIHdvcnJpZWQgYWJvdXQgaGF2aW5n IHRoZSBzYW1lIGNsYWltcyBkZWZpbmVkIHR3aWNlIGluIENXVCBhbmQgSldUIHdpdGggcG9zc2li bHkgY29uZmxpY3RpbmcgbWVhbmluZ3MgKGFuZCBuZWVkbGVzcyBjb25mdXNpb24gZXZlbiB3aGVu IHRoZXkgZG8gbWF0Y2gpLg0KDQpDb21wYXJpbmcgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LXdhaGxzdHJvZW0tb2F1dGgtY2Jvci13ZWItdG9rZW4tMDAjc2VjdGlvbi0zLjEuMiBh bmQgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzc1MTkjc2VjdGlvbi00LjEuMiB3aGlj aCBhcmUgbmVhcmx5IGlkZW50aWNhbCwgSSBqdXN0IGRvbid0IHNlZSB0aGUgdmFsdWUgaW4gcmUt ZGVmaW5pbmcgaXQuDQoNCldlIG1heSBhZGQgbmV3IHN0YW5kYXJkIGNsYWltcyB0byBKV1QgaW4g dGhlIGZ1dHVyZSAoSSBwcm9wb3NlZCBvbmU8aHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9h cmNoL3NlYXJjaC8/ZW1haWxfbGlzdD1pZC1ldmVudCZnYnQ9MSZpbmRleD03cU5VbmFFOWx0Mkx5 YXlNbm1OeVdwWlNJRU0+IGluIFlva29oYW1hIG9uIHRoZSBpZC1ldmVudCBsaXN0PGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWQtZXZlbnQ+KSwgaXQgd291bGQgYmUgZ29v ZCBpZiB0aGlzIGRpZG4ndCBuZWVkIGEgc2VwYXJhdGUgZW50cnkgaW4gQ1dUIHRvbywgYnV0IGNv dWxkIGp1c3QgYXBwbHkgZGlyZWN0bHkgKHNlcGFyYXRlbHksIEkgdGhpbmsgeW91IHNob3VsZCBj b25zaWRlciB0aGlzIGNsYWltLCBhcyBpdCBoZWxwcyBwcmV2ZW50IHRva2VucyBmcm9tIGJlaW5n IHJlLXVzZWQgaW4gdGhlIHdyb25nIGNvbnRleHQpLg0KDQoyLg0KSXMgU2VjdGlvbiA0ICJTdW1t YXJ5IG9mIENCT1IgbWFqb3IgdHlwZXMgdXNlZCBieSBkZWZpbmVkIGNsYWltcyIgbm9ybWF0aXZl IChodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtd2FobHN0cm9lbS1vYXV0aC1jYm9y LXdlYi10b2tlbi0wMCNzZWN0aW9uLTQpPyBXaGF0IGlzIHRoZSBpbnRlbnRpb24gb2YgdGhpcyBz ZWN0aW9uPyBJIGZlZWwgbGlrZSBpdCBjb3VsZCBwcm9iYWJseSBiZSBmbGVzaGVkIG91dCBhIGJp dC4NCg0KMy4NCkFkZCBhIHhyZWYgdG8gZHJhZnQgQ09TRSBzcGVjIGluIHNlY3Rpb24gNjxodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtd2FobHN0cm9lbS1vYXV0aC1jYm9yLXdlYi10 b2tlbi0wMCNzZWN0aW9uLTY+DQpBZGQgeHJlZiB0byBSRkM3NTE5DQoNCk9uIFRodSwgTm92IDEy LCAyMDE1IGF0IDEyOjAxIFBNLCBFcmlrIFdhaGxzdHLDtm0gbmVYdXMgPGVyaWsud2FobHN0cm9t QG5leHVzZ3JvdXAuY29tPG1haWx0bzplcmlrLndhaGxzdHJvbUBuZXh1c2dyb3VwLmNvbT4+IHdy b3RlOg0KSGkgQ2Fyc3RlbiwNCg0KVGhhbmtzLCBhbmQgSSBhZ3JlZS4gSeKAmXZlIGhlYXJkIGFy Z3VtZW50cyBmb3IgYWxsIHRocmVlIHdvcmsgZ3JvdXBzLg0KDQpCb3Jyb3dlZCBzb21lIG9mIHlv dXIgd29yZHMgdG8gZGVmaW5lIHRoZSBjb250ZW50IG9mIHRoZSBkcmFmdCA6KQ0KSXTigJlzIGl0 IGVzc2VudGlhbGx5IGEgSldULCBwaHJhc2VkIGluIGFuZCBwcm9maWxlZCBmb3IgQ0JPUiB0byBh ZGRyZXNzIEFDRSBuZWVkcywgd2hlcmUgT0F1dGggbmVlZHMgQ09TRSBmdW5jdGlvbmFsaXR5LCBm b3Igb2JqZWN0IHNlY3VyaXR5Lg0KDQpJ4oCZbSBvcGVuIGZvciBsZXR0aW5nIHRoZSBBROKAmXMg bW92ZSBpdCBhcm91bmQsIGJ1dCBoYXZpbmcgaXQgcmlnaHQgbmV4dCB0byBKV1Qgc2VlbXMgcmln aHQgdG8gbWUuIEFsc28gb3BlbiBmb3IgdGhlIEFDRSBXRy4gRmVlbCBpdCBoYXMgbGVzcyBwbGFj ZSBpbiBDT1NFIGZvciB0aGUgc2FtZSByZWFzb25zIEpXVCBpcyBub3QgaW4gdGhlIEpPU0UgV0cu DQoNCi8gRXJpaw0KDQoNCj4gT24gMTIgTm92IDIwMTUsIGF0IDIwOjQ1LCBDYXJzdGVuIEJvcm1h bm4gPGNhYm9AdHppLm9yZzxtYWlsdG86Y2Fib0B0emkub3JnPj4gd3JvdGU6DQo+DQo+IEhpIEVy aWssDQo+DQo+IGhhdmluZyB0aGlzIGRyYWZ0IGlzIGEgZ29vZCB0aGluZy4NCj4NCj4gT25lIHRo aW5nIEknbSBzdGlsbCB3b25kZXJpbmcgaXMgd2hhdCBXRyBpcyB0aGUgYmVzdCBwbGFjZSB0byBw cm9ncmVzcw0KPiB0aGlzLiAgV2UgcHJvYmFibHkgZG9uJ3QgbmVlZCB0byBzcGVuZCB0b28gbXVj aCB0aW1lIG9uIHRoaXMgYmVjYXVzZSwNCj4gcmVnYXJkbGVzcyBvZiB0aGUgV0cgY2hvc2VuLCB0 aGUgcGVvcGxlIGluIGFub3RoZXIgV0cgY2FuIGxvb2sgYXQgaXQuDQo+IFN0aWxsLCBnZXR0aW5n IHRoaXMgcmlnaHQgbWlnaHQgcHJvdmlkZSBzb21lIGVmZmljaWVuY2llcy4NCj4NCj4gV2hhdCBp cyB0aGUgdGVjaG5pY2FsIGNvbnRlbnQgb2YgdGhpcyBkcmFmdD8gIElzIGl0IGEgbmV3IHRva2Vu IHRoYXQNCj4gT0F1dGggbmVlZHMgc3BlY2lmaWNhbGx5IGZvciB0aGUgbmV3IENPU0UtYmFzZWQg YXBwbGljYXRpb25zIG9mIE9BdXRoPw0KPiBJcyBpdCBhIG5ldyB0b2tlbiB0aGF0IGlzIHNwZWNp ZmljYWxseSB0aGVyZSBmb3IgYWRkcmVzc2luZyBBQ0UgbmVlZHM/DQo+IE9yIGlzIGl0IGVzc2Vu dGlhbGx5IHRoZSBzYW1lIHN1YnN0YW5jZSBhcyBKV1QsIGJ1dCBwaHJhc2VkIGluIGFuZA0KPiBw cm9maWxlZCBmb3IgQ0JPUj8NCj4NCj4gRGVwZW5kaW5nIG9uIHRoZSBhbnN3ZXIsIENXVCBzaG91 bGQgYmUgZG9uZSBpbiBPQXV0aCwgQUNFLCBvciBDT1NFLg0KPiAoSSdkIHJhdGhlciBoZWFyIHRo ZSBhbnN3ZXIgZnJvbSB0aGUgYXV0aG9ycyB0aGFuIHZlbnR1cmUgYSBndWVzcyBteXNlbGYuKQ0K Pg0KPiBHcsO8w59lLCBDYXJzdGVuDQo+DQo+DQo+DQo+IEVyaWsgV2FobHN0csO2bSBuZVh1cyB3 cm90ZToNCj4+IEhpLA0KPj4NCj4+IEluIHRoZSBBQ0UgV0cgYSBzdHJhdyBtYW4gcHJvcG9zYWwg b2YgYSBDQk9SIFdlYiBUb2tlbiAoQ1dUKSB3YXMgZGVmaW5lZA0KPj4gaW4gdGhlIGRyYWZ0ICJB dXRob3JpemF0aW9uIGZvciB0aGUgSW50ZXJuZXQgb2YgVGhpbmdzIHVzaW5nIE9BdXRoIDIuMOKA nQ0KPj4gWzFdLiBXZSBqdXN0IGJyb2tlIG91dCB0aGUgQ0JPUiBXZWIgVG9rZW4gaW50byBhIHNl cGFyYXRlIGRyYWZ0IGFuZCB0aGUNCj4+IG5ldyBkcmFmdCBpcyBzdWJtaXR0ZWQgdG8gdGhlIE9B VVRIIFdHLiBJdCBjYW4gYmUgZm91bmQgaGVyZToNCj4+DQo+PiBodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC13YWhsc3Ryb2VtLW9hdXRoLWNib3Itd2ViLXRva2VuLw0KPj4N Cj4+IEFic3RyYWN0Og0KPj4gIkNCT1IgV2ViIFRva2VuIChDV1QpIGlzIGEgY29tcGFjdCBtZWFu cyBvZiByZXByZXNlbnRpbmcgY2xhaW1zIHRvIGJlDQo+PiB0cmFuc2ZlcnJlZCBiZXR3ZWVuIHR3 byBwYXJ0aWVzLiAgQ1dUIGlzIGEgcHJvZmlsZSBvZiB0aGUgSlNPTiBXZWIgVG9rZW4NCj4+IChK V1QpIHRoYXQgaXMgb3B0aW1pemVkIGZvciBjb25zdHJhaW5lZCBkZXZpY2VzLiBUaGUgY2xhaW1z IGluIGEgQ1dUIGFyZQ0KPj4gZW5jb2RlZCBpbiB0aGUgQ29uY2lzZSBCaW5hcnkgT2JqZWN0IFJl cHJlc2VudGF0aW9uIChDQk9SKSBhbmQgQ0JPUg0KPj4gT2JqZWN0IFNpZ25pbmcgYW5kIEVuY3J5 cHRpb24gKENPU0UpIGlzIHVzZWQgZm9yIGFkZGVkIGFwcGxpY2F0aW9uIGxheWVyDQo+PiBzZWN1 cml0eSBwcm90ZWN0aW9uLiAgQSBjbGFpbSBpcyBhIHBpZWNlIG9mIGluZm9ybWF0aW9uIGFzc2Vy dGVkIGFib3V0IGENCj4+IHN1YmplY3QgYW5kIGlzIHJlcHJlc2VudGVkIGFzIGEgbmFtZS92YWx1 ZSBwYWlyIGNvbnNpc3Rpbmcgb2YgYSBjbGFpbQ0KPj4gbmFtZSBhbmQgYSBjbGFpbSB2YWx1ZS4i DQo+Pg0KPj4gLyBFcmlrDQo+Pg0KPj4NCj4+IFsxXSBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtc2VpdHotYWNlLW9hdXRoLWF1dGh6LTAwDQo+Pg0KPj4NCj4+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBDT1NFIG1haWxpbmcgbGlz dA0KPj4gQ09TRUBpZXRmLm9yZzxtYWlsdG86Q09TRUBpZXRmLm9yZz4NCj4+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29zZQ0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KQ09TRSBtYWlsaW5nIGxpc3QNCkNPU0VAaWV0Zi5v cmc8bWFpbHRvOkNPU0VAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2Nvc2UNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQotLSBJ TVBPUlRBTlQgTk9USUNFOiBUaGUgY29udGVudHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0dGFj aG1lbnRzIGFyZSBjb25maWRlbnRpYWwgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlv dSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRl ciBpbW1lZGlhdGVseSBhbmQgZG8gbm90IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0byBhbnkgb3Ro ZXIgcGVyc29uLCB1c2UgaXQgZm9yIGFueSBwdXJwb3NlLCBvciBzdG9yZSBvciBjb3B5IHRoZSBp bmZvcm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFuayB5b3UuDQoNCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCg0KLS0gSU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9m IHRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkg YWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50 LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9z ZSB0aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBhbnkgcHVycG9z ZSwgb3Igc3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsg eW91Lg0K --_000_HE1PR08MB0732DEC772A47528634F1F5CFA1D0HE1PR08MB0732eurp_ Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQg MyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu Iiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvQWNl dGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi Ow0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5h bWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0 eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2Vy aWYiOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUdCO30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x DQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3 Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0 eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVk aXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hl YWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIFdpbGxpYW0sDQo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPllv dSBhcmUgaW5kZWVkIGNvcnJlY3QgdGhhdCB0aGUgY3VycmVudCBkb2N1bWVudCBjb250YWlucyBh IGxpc3Qgb2Ygb25lLWJ5LW9uZSBjb3BpZXMgb2YgY2xhaW1zIGZyb20gdGhlIEpXVC4gVGhlIG9u bHkgZGlmZmVyZW5jZSBpcyB0aGUgZGF0YSB0eXBlLiBQcm9iYWJseQ0KIGl0IHdvdWxkIGhhdmUg YmVlbiBiZXR0ZXIgdG8ganVzdCByZWZlcmVuY2UgdGhlIHNlbWFudGljIGZyb20gdGhlIEpXVCBz cGVjIGFuZCB0aGVuIHN0YXRlIHRoZSBuZXcgZGF0YSB0eXBlLg0KPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIGZ1bGx5 IHVuZGVyc3RhbmQgdGhlIGNvbmNlcm4gb2YgZGVmaW5pbmcgQ1dUIGNsYWltcyB0aGF0IGhhdmUg dGhlIHNhbWUgbmFtZSBhcyBKV1QgY2xhaW1zIGJ1dCB0aGVuIGRpZmZlcmVudCBzZW1hbnRpYy4g VGhpcyB3b3VsZCBiZSB0ZXJyaWJseSBjb25mdXNpbmcuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkNpYW88bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGFubmVzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9i PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFdpbGxpYW0gRGVubmlz cyBbbWFpbHRvOndkZW5uaXNzQGdvb2dsZS5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gMTYgTm92 ZW1iZXIgMjAxNSAyMjozMjxicj4NCjxiPlRvOjwvYj4gSGFubmVzIFRzY2hvZmVuaWc8YnI+DQo8 Yj5DYzo8L2I+IEVyaWsgV2FobHN0csO2bSBuZVh1czsgQ2Fyc3RlbiBCb3JtYW5uOyBNaWtlIEpv bmVzOyAmbHQ7b2F1dGhAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbQ09T RV0gQSBkcmFmdCBvbiBDQk9SIFdlYiBUb2tlbnMgKENXVCk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5Zb3UgcmFpc2Ugc29tZSBnb29kIHBvaW50cywgYW5kIHBlcmhhcHMg dGhhdCBpcyByZWxldmFudCB0byBmdXR1cmUgY2xhaW1zLiBUaGUgc3BlYyBhcyBkcmFmdGVkLCBp cyBhIG9uZS1mb3Itb25lIGNvcHkgb2YgdGhlIHN0YW5kYXJkIEpXVCBjbGFpbXMsIHdoaWNoIGlz IHdoeSBJIHJhaXNlZCB0aGlzIHBvaW50LjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SXMgdGhlIGdvYWwgYSBDQk9SIHJlcHJlc2VudGF0aW9uIG9mIGEgSldU PyBJZiBzbywgY2FuIGl0IGJlIGRlZmluZWQgaW4gdGVybXMgb2YgYSBKV1Q/Jm5ic3A7IFdvdWxk IHRoZSBDTkYgY2xhaW0gdGhlbiBpbmhlcml0IHRoYXQgcmVwcmVzZW50YXRpb24gKHRyZWF0aW5n IHRoZSBKV0UgYW5kIEpXSyBhcyB0aGVpciBDQk9SIGVxdWl2YWxlbnRzKT88bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UGVyaGFwcyBpZiB5b3Ug Z28gdGhlIHNlcGFyYXRlIHJlZ2lzdHJ5IHJvdXRlLCB0aG9zZSBjbGFpbXMgdGhhdCAqYXJlKiBk ZWZpbmVkIHRoZSBzYW1lIHNob3VsZCBhdCBsZWFzdCBub3JtYXRpdmVseSByZWZlcmVuY2UgSldU PyZuYnNwOyBJIHdhbnQgdG8gYXZvaWQgdGhlIHdob2xlICZxdW90O29uIGJlaGFsZiBvZiZxdW90 OyAvICZxdW90O2FjdCBhcyZxdW90OyBmaWFzY28gd2hlcmUgdGhpbmdzIGNhbiBnZXQgcmUtZGVm aW5lZCwgYW5kIG11ZGRsZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPk9uIE1vbiwgTm92IDE2LCAyMDE1IGF0IDc6MDkgQU0sIEhhbm5lcyBU c2Nob2ZlbmlnICZsdDs8YSBocmVmPSJtYWlsdG86SGFubmVzLlRzY2hvZmVuaWdAYXJtLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPkhhbm5lcy5Uc2Nob2ZlbmlnQGFybS5jb208L2E+Jmd0OyB3cm90ZTo8 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgV2lsbGlhbSwNCjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPkkgaGF2ZSBiZWVuIHRyeWluZyB0byBkbyBhIGRvY3VtZW50IHVwZGF0ZSB0byBz ZWUgaG93IHdlbGwgYSBjb21iaW5lZCByZWdpc3RyeSB3b3JrcyBhbmQgSSBoYXZlIGJlZW4NCiB3 b25kZXJpbmcgd2hldGhlciBpdCBpcyByZWFsbHkgd29ydGggdGhlIGVmZm9ydC4gPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VG8gbWFrZSBhIGdvb2QganVkZ21lbnQgSSBsb29rZWQg YXQgdGhlIENORiBjbGFpbSBkZWZpbmVkIGluIGRyYWZ0LWlldGYtb2F1dGgtcHJvb2Ytb2YtcG9z c2Vzc2lvbi4NCiBUaGUgQ05GIGNsYWltIG1heSBjb250YWluIHN1Yi1lbGVtZW50cywgc3VjaCBh cyBhIEpXRSBvciBhIEpXSy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JZiB3ZSB0cmFuc2xhdGUgdGhlIHNhbWUg bWVjaGFuaXNtcyB0byB0aGUgQ1dUICh3aGljaCBtYWtlcyBzZW5zZSkgdGhlbiB3ZSBuZWVkIHRv IHBvaW50IHRvIHRoZSByZXNwZWN0aXZlDQogQ09TRSBzdHJ1Y3R1cmVzIGluc3RlYWQuIFRob3Nl IGRvIG5vdCBvbmx5IHVzZSBhIGRpZmZlcmVudCBlbmNvZGluZyBidXQgYWxzbyB0aGUgZnVuY3Rp b25hbGl0eSBkb2VzIG5vdCBtYXRjaCB0aGUgSk9TRSBzdHJ1Y3R1cmVzIDEwMCUuIFNvLCB0aGVy ZSBhcmUgcG90ZW50aWFsbHkgZGlmZmVyZW5jZXMuIEkgYW0gYWxzbyBub3Qgc3VyZSB3aGV0aGVy IHdlIHJlYWxseSB3YW50IHRvIHRyYW5zbGF0ZSB0aGUgZnVsbCBmdW5jdGlvbmFsaXR5IG9mDQog YWxsIHRoZSBjbGFpbXMgZnJvbSBKV1Qgb3ZlciB0byB0aGUgQ1dUIGVxdWl2YWxlbnQuIEl0IGJh c2ljYWxseSBwdXRzIHRoZSBidXJkZW4gb24gc29tZW9uZSBkZWZpbmluZyBuZXcgY2xhaW1zIChl aXRoZXIgaW4gSldUIG9yIGluIENXVCkgdG8gY3JlYXRlIHRoZSBjb3JyZXNwb25kaW5nIHN0cnVj dHVyZXMgaW4gYSBmb3JtYXQgdGhleSBtYXkgbm90IG5lY2Vzc2FyaWx5IGJlIGZhbWlsaWFyIHdp dGggb3IgZXZlbiBjYXJlIGFib3V0LiBJIGhhdmUNCiBzZWVuIHRoYXQgaGFwcGVuaW5nIGluIHRo ZSBSQURJVVMgd29ybGQgcHJvdG9jb2wgZGVzaWduZXJzIGhhZCB0byBhbHNvIGRlZmluZSB0aGUg ZXF1aXZhbGVudCBzdHJ1Y3R1cmVzIGZvciB1c2Ugd2l0aCBEaWFtZXRlciBhbmQsIGd1ZXNzIHdo YXQsIG1vc3Qgb2YgdGhlIGRlZmluaXRpb25zIHdlcmUgd3JvbmcgKHNpbmNlIHRoZSBhdXRob3Jz IGRpZCBub3QgY2FyZSBhYm91dCBEaWFtZXRlciB3aGVuIHdvcmtpbmcgb24gUkFESVVTKS4NCjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPkNpYW88YnI+DQpIYW5uZXM8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFdpbGxpYW0NCiBEZW5uaXNzIFttYWlsdG86PGEg aHJlZj0ibWFpbHRvOndkZW5uaXNzQGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj53ZGVubmlz c0Bnb29nbGUuY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiAxMiBOb3ZlbWJlciAyMDE1IDE5 OjE5PGJyPg0KPGI+VG86PC9iPiBFcmlrIFdhaGxzdHLDtm0gbmVYdXM8YnI+DQo8Yj5DYzo8L2I+ IENhcnN0ZW4gQm9ybWFubjsgSGFubmVzIFRzY2hvZmVuaWc7IE1pa2UgSm9uZXM7IDxhIGhyZWY9 Im1haWx0bzpjb3NlQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQpjb3NlQGlldGYub3JnPC9h PjsgJmx0OzxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm9h dXRoQGlldGYub3JnPC9hPiZndDs7DQo8YSBocmVmPSJtYWlsdG86YWNlQGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+YWNlQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0NP U0VdIEEgZHJhZnQgb24gQ0JPUiBXZWIgVG9rZW5zIChDV1QpPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5SZWdhcmRpbmcgdGhlIGRyYWZ0IGl0c2VsZiwg YSBmZXcgY29tbWVudHM6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjEuJm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkNhbiB3ZSB1bmlmeSB0aGUgY2xh aW0gcmVnaXN0cnkgd2l0aCBKV1Q/IEknbSB3b3JyaWVkIGFib3V0IGhhdmluZyB0aGUgc2FtZSBj bGFpbXMgZGVmaW5lZCB0d2ljZSBpbiBDV1QgYW5kIEpXVCB3aXRoIHBvc3NpYmx5IGNvbmZsaWN0 aW5nIG1lYW5pbmdzIChhbmQgbmVlZGxlc3MgY29uZnVzaW9uIGV2ZW4gd2hlbg0KIHRoZXkgZG8g bWF0Y2gpLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Q29tcGFyaW5nJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LXdhaGxzdHJvZW0tb2F1dGgtY2Jvci13ZWItdG9rZW4tMDAjc2VjdGlv bi0zLjEuMiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC13YWhsc3Ryb2VtLW9hdXRoLWNib3Itd2ViLXRva2VuLTAwI3NlY3Rpb24tMy4xLjI8L2E+DQog YW5kJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzc1MTkjc2Vj dGlvbi00LjEuMiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9y ZmM3NTE5I3NlY3Rpb24tNC4xLjI8L2E+IHdoaWNoIGFyZSBuZWFybHkgaWRlbnRpY2FsLCBJIGp1 c3QgZG9uJ3Qgc2VlIHRoZSB2YWx1ZSBpbiByZS1kZWZpbmluZyBpdC48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPldlIG1heSBhZGQgbmV3 IHN0YW5kYXJkIGNsYWltcyB0byBKV1QgaW4gdGhlIGZ1dHVyZSAoSSZuYnNwOzxhIGhyZWY9Imh0 dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9zZWFyY2gvP2VtYWlsX2xpc3Q9aWQtZXZl bnQmYW1wO2didD0xJmFtcDtpbmRleD03cU5VbmFFOWx0Mkx5YXlNbm1OeVdwWlNJRU0iIHRhcmdl dD0iX2JsYW5rIj5wcm9wb3NlZA0KIG9uZTwvYT4mbmJzcDtpbiBZb2tvaGFtYSBvbiB0aGUmbmJz cDs8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50 IiB0YXJnZXQ9Il9ibGFuayI+aWQtZXZlbnQgbGlzdDwvYT4pLCBpdCB3b3VsZCBiZSBnb29kIGlm IHRoaXMgZGlkbid0IG5lZWQgYSBzZXBhcmF0ZSBlbnRyeSBpbiBDV1QgdG9vLCBidXQgY291bGQg anVzdCBhcHBseSBkaXJlY3RseSAoc2VwYXJhdGVseSwgSSB0aGluayB5b3Ugc2hvdWxkIGNvbnNp ZGVyDQogdGhpcyBjbGFpbSwgYXMgaXQgaGVscHMgcHJldmVudCB0b2tlbnMgZnJvbSBiZWluZyBy ZS11c2VkIGluIHRoZSB3cm9uZyBjb250ZXh0KS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjIuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPklzIFNlY3Rpb24gNCAmcXVvdDtTdW1tYXJ5 IG9mIENCT1IgbWFqb3IgdHlwZXMgdXNlZCBieSBkZWZpbmVkIGNsYWltcyZxdW90OyBub3JtYXRp dmUgKDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC13YWhsc3Ryb2Vt LW9hdXRoLWNib3Itd2ViLXRva2VuLTAwI3NlY3Rpb24tNCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC13YWhsc3Ryb2VtLW9hdXRoLWNib3Itd2ViLXRv a2VuLTAwI3NlY3Rpb24tNDwvYT4pPw0KIFdoYXQgaXMgdGhlIGludGVudGlvbiBvZiB0aGlzIHNl Y3Rpb24/IEkgZmVlbCBsaWtlIGl0IGNvdWxkIHByb2JhYmx5IGJlIGZsZXNoZWQgb3V0IGEgYml0 LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+My4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+QWRkIGEgeHJlZiB0byBkcmFmdCBDT1NFIHNwZWMgaW4mbmJzcDs8YSBocmVmPSJo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtd2FobHN0cm9lbS1vYXV0aC1jYm9yLXdl Yi10b2tlbi0wMCNzZWN0aW9uLTYiIHRhcmdldD0iX2JsYW5rIj5zZWN0aW9uIDY8L2E+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkFkZCB4cmVm IHRvIFJGQzc1MTk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIFRodSwgTm92IDEy LCAyMDE1IGF0IDEyOjAxIFBNLCBFcmlrIFdhaGxzdHLDtm0gbmVYdXMgJmx0OzxhIGhyZWY9Im1h aWx0bzplcmlrLndhaGxzdHJvbUBuZXh1c2dyb3VwLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmVyaWsu d2FobHN0cm9tQG5leHVzZ3JvdXAuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPkhpIENhcnN0ZW4sPGJyPg0KPGJyPg0KVGhhbmtzLCBhbmQg SSBhZ3JlZS4gSeKAmXZlIGhlYXJkIGFyZ3VtZW50cyBmb3IgYWxsIHRocmVlIHdvcmsgZ3JvdXBz Ljxicj4NCjxicj4NCkJvcnJvd2VkIHNvbWUgb2YgeW91ciB3b3JkcyB0byBkZWZpbmUgdGhlIGNv bnRlbnQgb2YgdGhlIGRyYWZ0IDopPGJyPg0KSXTigJlzIGl0IGVzc2VudGlhbGx5IGEgSldULCBw aHJhc2VkIGluIGFuZCBwcm9maWxlZCBmb3IgQ0JPUiB0byBhZGRyZXNzIEFDRSBuZWVkcywgd2hl cmUgT0F1dGggbmVlZHMgQ09TRSBmdW5jdGlvbmFsaXR5LCBmb3Igb2JqZWN0IHNlY3VyaXR5Ljxi cj4NCjxicj4NCknigJltIG9wZW4gZm9yIGxldHRpbmcgdGhlIEFE4oCZcyBtb3ZlIGl0IGFyb3Vu ZCwgYnV0IGhhdmluZyBpdCByaWdodCBuZXh0IHRvIEpXVCBzZWVtcyByaWdodCB0byBtZS4gQWxz byBvcGVuIGZvciB0aGUgQUNFIFdHLiBGZWVsIGl0IGhhcyBsZXNzIHBsYWNlIGluIENPU0UgZm9y IHRoZSBzYW1lIHJlYXNvbnMgSldUIGlzIG5vdCBpbiB0aGUgSk9TRSBXRy48YnI+DQo8c3BhbiBz dHlsZT0iY29sb3I6Izg4ODg4OCI+PGJyPg0KLyBFcmlrPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxicj4NCjxicj4NCiZndDsgT24g MTIgTm92IDIwMTUsIGF0IDIwOjQ1LCBDYXJzdGVuIEJvcm1hbm4gJmx0OzxhIGhyZWY9Im1haWx0 bzpjYWJvQHR6aS5vcmciIHRhcmdldD0iX2JsYW5rIj5jYWJvQHR6aS5vcmc8L2E+Jmd0OyB3cm90 ZTo8YnI+DQomZ3Q7PGJyPg0KJmd0OyBIaSBFcmlrLDxicj4NCiZndDs8YnI+DQomZ3Q7IGhhdmlu ZyB0aGlzIGRyYWZ0IGlzIGEgZ29vZCB0aGluZy48YnI+DQomZ3Q7PGJyPg0KJmd0OyBPbmUgdGhp bmcgSSdtIHN0aWxsIHdvbmRlcmluZyBpcyB3aGF0IFdHIGlzIHRoZSBiZXN0IHBsYWNlIHRvIHBy b2dyZXNzPGJyPg0KJmd0OyB0aGlzLiZuYnNwOyBXZSBwcm9iYWJseSBkb24ndCBuZWVkIHRvIHNw ZW5kIHRvbyBtdWNoIHRpbWUgb24gdGhpcyBiZWNhdXNlLDxicj4NCiZndDsgcmVnYXJkbGVzcyBv ZiB0aGUgV0cgY2hvc2VuLCB0aGUgcGVvcGxlIGluIGFub3RoZXIgV0cgY2FuIGxvb2sgYXQgaXQu PGJyPg0KJmd0OyBTdGlsbCwgZ2V0dGluZyB0aGlzIHJpZ2h0IG1pZ2h0IHByb3ZpZGUgc29tZSBl ZmZpY2llbmNpZXMuPGJyPg0KJmd0Ozxicj4NCiZndDsgV2hhdCBpcyB0aGUgdGVjaG5pY2FsIGNv bnRlbnQgb2YgdGhpcyBkcmFmdD8mbmJzcDsgSXMgaXQgYSBuZXcgdG9rZW4gdGhhdDxicj4NCiZn dDsgT0F1dGggbmVlZHMgc3BlY2lmaWNhbGx5IGZvciB0aGUgbmV3IENPU0UtYmFzZWQgYXBwbGlj YXRpb25zIG9mIE9BdXRoPzxicj4NCiZndDsgSXMgaXQgYSBuZXcgdG9rZW4gdGhhdCBpcyBzcGVj aWZpY2FsbHkgdGhlcmUgZm9yIGFkZHJlc3NpbmcgQUNFIG5lZWRzPzxicj4NCiZndDsgT3IgaXMg aXQgZXNzZW50aWFsbHkgdGhlIHNhbWUgc3Vic3RhbmNlIGFzIEpXVCwgYnV0IHBocmFzZWQgaW4g YW5kPGJyPg0KJmd0OyBwcm9maWxlZCBmb3IgQ0JPUj88YnI+DQomZ3Q7PGJyPg0KJmd0OyBEZXBl bmRpbmcgb24gdGhlIGFuc3dlciwgQ1dUIHNob3VsZCBiZSBkb25lIGluIE9BdXRoLCBBQ0UsIG9y IENPU0UuPGJyPg0KJmd0OyAoSSdkIHJhdGhlciBoZWFyIHRoZSBhbnN3ZXIgZnJvbSB0aGUgYXV0 aG9ycyB0aGFuIHZlbnR1cmUgYSBndWVzcyBteXNlbGYuKTxicj4NCiZndDs8YnI+DQomZ3Q7IEdy w7zDn2UsIENhcnN0ZW48YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IEVy aWsgV2FobHN0csO2bSBuZVh1cyB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyBIaSw8YnI+DQomZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7IEluIHRoZSBBQ0UgV0cgYSBzdHJhdyBtYW4gcHJvcG9zYWwgb2YgYSBD Qk9SIFdlYiBUb2tlbiAoQ1dUKSB3YXMgZGVmaW5lZDxicj4NCiZndDsmZ3Q7IGluIHRoZSBkcmFm dCAmcXVvdDtBdXRob3JpemF0aW9uIGZvciB0aGUgSW50ZXJuZXQgb2YgVGhpbmdzIHVzaW5nIE9B dXRoIDIuMOKAnTxicj4NCiZndDsmZ3Q7IFsxXS4gV2UganVzdCBicm9rZSBvdXQgdGhlIENCT1Ig V2ViIFRva2VuIGludG8gYSBzZXBhcmF0ZSBkcmFmdCBhbmQgdGhlPGJyPg0KJmd0OyZndDsgbmV3 IGRyYWZ0IGlzIHN1Ym1pdHRlZCB0byB0aGUgT0FVVEggV0cuIEl0IGNhbiBiZSBmb3VuZCBoZXJl Ojxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtd2FobHN0cm9lbS1vYXV0aC1jYm9yLXdlYi10b2tlbi8iIHRh cmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXdh aGxzdHJvZW0tb2F1dGgtY2Jvci13ZWItdG9rZW4vPC9hPjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0 OyZndDsgQWJzdHJhY3Q6PGJyPg0KJmd0OyZndDsgJnF1b3Q7Q0JPUiBXZWIgVG9rZW4gKENXVCkg aXMgYSBjb21wYWN0IG1lYW5zIG9mIHJlcHJlc2VudGluZyBjbGFpbXMgdG8gYmU8YnI+DQomZ3Q7 Jmd0OyB0cmFuc2ZlcnJlZCBiZXR3ZWVuIHR3byBwYXJ0aWVzLiZuYnNwOyBDV1QgaXMgYSBwcm9m aWxlIG9mIHRoZSBKU09OIFdlYiBUb2tlbjxicj4NCiZndDsmZ3Q7IChKV1QpIHRoYXQgaXMgb3B0 aW1pemVkIGZvciBjb25zdHJhaW5lZCBkZXZpY2VzLiBUaGUgY2xhaW1zIGluIGEgQ1dUIGFyZTxi cj4NCiZndDsmZ3Q7IGVuY29kZWQgaW4gdGhlIENvbmNpc2UgQmluYXJ5IE9iamVjdCBSZXByZXNl bnRhdGlvbiAoQ0JPUikgYW5kIENCT1I8YnI+DQomZ3Q7Jmd0OyBPYmplY3QgU2lnbmluZyBhbmQg RW5jcnlwdGlvbiAoQ09TRSkgaXMgdXNlZCBmb3IgYWRkZWQgYXBwbGljYXRpb24gbGF5ZXI8YnI+ DQomZ3Q7Jmd0OyBzZWN1cml0eSBwcm90ZWN0aW9uLiZuYnNwOyBBIGNsYWltIGlzIGEgcGllY2Ug b2YgaW5mb3JtYXRpb24gYXNzZXJ0ZWQgYWJvdXQgYTxicj4NCiZndDsmZ3Q7IHN1YmplY3QgYW5k IGlzIHJlcHJlc2VudGVkIGFzIGEgbmFtZS92YWx1ZSBwYWlyIGNvbnNpc3Rpbmcgb2YgYSBjbGFp bTxicj4NCiZndDsmZ3Q7IG5hbWUgYW5kIGEgY2xhaW0gdmFsdWUuJnF1b3Q7PGJyPg0KJmd0OyZn dDs8YnI+DQomZ3Q7Jmd0OyAvIEVyaWs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0K Jmd0OyZndDsgWzFdIDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1z ZWl0ei1hY2Utb2F1dGgtYXV0aHotMDAiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1zZWl0ei1hY2Utb2F1dGgtYXV0aHotMDA8L2E+PGJyPg0KJmd0 OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyZndDsgQ09TRSBtYWlsaW5nIGxpc3Q8 YnI+DQomZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86Q09TRUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPkNPU0VAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3NlIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3NlPC9hPjxicj4NCjxicj4NCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KQ09TRSBtYWlsaW5n IGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86Q09TRUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi PkNPU0VAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9jb3NlIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9jb3NlPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0 eWxlPSJ0ZXh0LWFsaWduOmNlbnRlciI+DQo8aHIgc2l6ZT0iMiIgd2lkdGg9IjEwMCUiIGFsaWdu PSJjZW50ZXIiPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48YnI+DQotLSBJTVBPUlRBTlQgTk9USUNFOiBUaGUgY29u dGVudHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwg YW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCBy ZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgZG8gbm90 IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLCB1c2UgaXQgZm9yIGFu eQ0KIHB1cnBvc2UsIG9yIHN0b3JlIG9yIGNvcHkgdGhlIGluZm9ybWF0aW9uIGluIGFueSBtZWRp dW0uIFRoYW5rIHlvdS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGJyPg0KPGhyPg0KPGZvbnQgZmFjZT0iQXJpYWwiIGNvbG9yPSJCbGFjayIgc2l6ZT0iMiI+PGJy Pg0KLS0gSU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFu eSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2Vk LiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRo ZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8g YW55IG90aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBhbnkNCiBwdXJwb3NlLCBvciBzdG9yZSBvciBj b3B5IHRoZSBpbmZvcm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFuayB5b3UuPGJyPg0KPC9mb250 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_HE1PR08MB0732DEC772A47528634F1F5CFA1D0HE1PR08MB0732eurp_-- From nobody Mon Nov 16 23:26:02 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86CB81B2BB2 for ; Mon, 16 Nov 2015 23:24:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lg6LtvjE9Wev for ; Mon, 16 Nov 2015 23:24:55 -0800 (PST) Received: from eu-smtp-delivery-143.mimecast.com (eu-smtp-delivery-143.mimecast.com [146.101.78.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C9641B2BA3 for ; Mon, 16 Nov 2015 23:24:54 -0800 (PST) Received: from emea-cam-gw1.Emea.Arm.com (fw-tnat.cambridge.arm.com [217.140.96.140]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-31-ywhj0KFOQ0SvwNp47zf_wQ-1; Tue, 17 Nov 2015 07:24:51 +0000 Received: from GB-CAM-EXCAS1.Emea.Arm.com (10.1.105.66) by emea-cam-gw1.Emea.Arm.com (10.1.248.204) with Microsoft SMTP Server (TLS) id 8.3.298.1; Tue, 17 Nov 2015 07:24:50 +0000 Received: from emea01-db3-obe.outbound.protection.outlook.com (10.1.2.79) by nebula.arm.com (10.1.105.66) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 17 Nov 2015 07:24:49 +0000 Received: from HE1PR08MB0732.eurprd08.prod.outlook.com (10.163.179.30) by HE1PR08MB0729.eurprd08.prod.outlook.com (10.163.179.27) with Microsoft SMTP Server (TLS) id 15.1.325.17; Tue, 17 Nov 2015 07:24:48 +0000 Received: from HE1PR08MB0732.eurprd08.prod.outlook.com ([10.163.179.30]) by HE1PR08MB0732.eurprd08.prod.outlook.com ([10.163.179.30]) with mapi id 15.01.0325.003; Tue, 17 Nov 2015 07:24:48 +0000 From: Hannes Tschofenig To: Bill Mills , William Denniss Thread-Topic: [OAUTH-WG] [COSE] A draft on CBOR Web Tokens (CWT) Thread-Index: AQHRHX3DyXQEi0Hb60mPSXqbnVxSe56YykQAgAAEkACAAHpjAIAFe1lwgABs4oCAAAZqAIAAnrDA Date: Tue, 17 Nov 2015 07:24:47 +0000 Message-ID: References: <364007597.6139430.1447710892429.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <364007597.6139430.1447710892429.JavaMail.yahoo@mail.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [80.92.121.34] x-microsoft-exchange-diagnostics: 1; HE1PR08MB0729; 5:7QOS3bDy3PLHRFYPZGwho1g2D3CBWduvf9bMfS2dUJiFrDPLd7DbREgEW63gqDkg3mSCnUYsd+TKz3LattK1FPr1N+cY3aIjB2+WLs6TZpCzmSAyAN/wIJeMVY9qC3jwohe1wEM6wwzFgfTbaIcP7Q==; 24:qY5+ieq9gkAu1vSw0AkgsMJuDZ7FriAOohAd+127rNQczk0FscfuqZlgY5FrTiUMuwnAtSYFvoKaf3V1BJYrgwqlqdg9gIaI/JvOHHuhc30=; 20:aXTJfrK9WtWFzPbrcF+6NSTa5D8bF8W0JCtkhksLAXHmyXUwmsQWAbq43ZlWRBmkpV8wTphsE7tPNv8m+0bXM6/Cv7g23nkV0Bi97QfPLZ4mPcbMC4+q/DrlFR7j8+EFLbiHEtWXTgWmxDCFo4GddVFGFmaoTa2wvgRDfq3BDTk= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR08MB0729; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(201166117486090)(211936372134217)(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(10201501046)(3002001); SRVR:HE1PR08MB0729; BCL:0; PCL:0; RULEID:; SRVR:HE1PR08MB0729; x-forefront-prvs: 07630F72AD x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(24454002)(164054003)(40434004)(189002)(377454003)(199003)(76576001)(97736004)(33656002)(19580395003)(5001960100002)(92566002)(2950100001)(74316001)(102836002)(105586002)(81156007)(189998001)(5004730100002)(5007970100001)(15975445007)(5001770100001)(106116001)(5003600100002)(10400500002)(5890100001)(11100500001)(40100003)(586003)(106356001)(2521001)(19580405001)(77096005)(101416001)(19300405004)(2900100001)(16236675004)(5008740100001)(50986999)(66066001)(19625215002)(561944003)(5002640100001)(86362001)(54356999)(87936001)(76176999)(122556002)(19617315012); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR08MB0729; H:HE1PR08MB0732.eurprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Nov 2015 07:24:47.9714 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR08MB0729 X-OriginatorOrg: arm.com X-MC-Unique: ywhj0KFOQ0SvwNp47zf_wQ-1 Content-Type: multipart/alternative; boundary="_000_HE1PR08MB0732F817E687A11E59E5EDB1FA1D0HE1PR08MB0732eurp_" Archived-At: X-Mailman-Approved-At: Mon, 16 Nov 2015 23:25:58 -0800 Cc: "" Subject: Re: [OAUTH-WG] [COSE] A draft on CBOR Web Tokens (CWT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2015 07:24:58 -0000 --_000_HE1PR08MB0732F817E687A11E59E5EDB1FA1D0HE1PR08MB0732eurp_ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 SGkgQmlsbCwNCg0KRnJvbSB3aGF0IEkgY2FuIHRlbGwgdGhlcmUgYXJlIG5vIGRpZmZlcmVuY2Vz IGluIHRoaXMgcmVnYXJkLiBPZiBjb3Vyc2UsIHRoZSBkYXRhIGhhcyB0byBiZSBlbmNvZGVkIGRp ZmZlcmVudGx5IGFuZCBzbyB0aGVyZSBpcyBhIG5lZWQgdG8gc3RhdGUgdGhlIG5ldyBkYXRhIHR5 cGUgYnV0IGJleW9uZCB0aGF0IEkgaGF2ZW7igJl0IHNlZW4gYW55IHJlc3RyaWN0aW9ucyB5ZXQu IE9mIGNvdXJzZSwgdGhlIENPU0Ugd29yayBpcyBzdGlsbCBvbmdvaW5nIGFuZCBzbyBpdCBtaWdo dCBiZSBhIGJpdCB0b28gZWFybHkgdG8gdGVsbC4NCg0KQ2lhbw0KSGFubmVzDQoNCkZyb206IEJp bGwgTWlsbHMgW21haWx0bzp3bWlsbHNfOTIxMDVAeWFob28uY29tXQ0KU2VudDogMTYgTm92ZW1i ZXIgMjAxNSAyMjo1NQ0KVG86IFdpbGxpYW0gRGVubmlzczsgSGFubmVzIFRzY2hvZmVuaWcNCkNj OiBDYXJzdGVuIEJvcm1hbm47IDxvYXV0aEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbT0FVVEgt V0ddIFtDT1NFXSBBIGRyYWZ0IG9uIENCT1IgV2ViIFRva2VucyAoQ1dUKQ0KDQpJZiB0aGVyZSBh cmUgc3RydWN0dXJhbCBkaWZmZXJlbmNlcyBpbiB3aGF0IENCT1IgY2FuIHN1cHBvcnQgaXQgd291 bGQgYmUgd29ydGh3aGlsZSB0byBub3RlIHRoYXQuICBFeGFtcGxlcyBvZiB0aGluZ3Mgc3VwcG9y dGVkIGluIEpXVCB0aGF0IHlvdSBjYW4ndCBkbyBpbiBDQk9SIGNvdWxkIGJlIHZlcnkgaGVscGZ1 bCB0byBpbXBsZW1lbnRlcnMuDQoNCg0KDQpPbiBNb25kYXksIE5vdmVtYmVyIDE2LCAyMDE1IDE6 MzIgUE0sIFdpbGxpYW0gRGVubmlzcyA8d2Rlbm5pc3NAZ29vZ2xlLmNvbTxtYWlsdG86d2Rlbm5p c3NAZ29vZ2xlLmNvbT4+IHdyb3RlOg0KDQpZb3UgcmFpc2Ugc29tZSBnb29kIHBvaW50cywgYW5k IHBlcmhhcHMgdGhhdCBpcyByZWxldmFudCB0byBmdXR1cmUgY2xhaW1zLiBUaGUgc3BlYyBhcyBk cmFmdGVkLCBpcyBhIG9uZS1mb3Itb25lIGNvcHkgb2YgdGhlIHN0YW5kYXJkIEpXVCBjbGFpbXMs IHdoaWNoIGlzIHdoeSBJIHJhaXNlZCB0aGlzIHBvaW50Lg0KDQpJcyB0aGUgZ29hbCBhIENCT1Ig cmVwcmVzZW50YXRpb24gb2YgYSBKV1Q/IElmIHNvLCBjYW4gaXQgYmUgZGVmaW5lZCBpbiB0ZXJt cyBvZiBhIEpXVD8gIFdvdWxkIHRoZSBDTkYgY2xhaW0gdGhlbiBpbmhlcml0IHRoYXQgcmVwcmVz ZW50YXRpb24gKHRyZWF0aW5nIHRoZSBKV0UgYW5kIEpXSyBhcyB0aGVpciBDQk9SIGVxdWl2YWxl bnRzKT8NCg0KUGVyaGFwcyBpZiB5b3UgZ28gdGhlIHNlcGFyYXRlIHJlZ2lzdHJ5IHJvdXRlLCB0 aG9zZSBjbGFpbXMgdGhhdCAqYXJlKiBkZWZpbmVkIHRoZSBzYW1lIHNob3VsZCBhdCBsZWFzdCBu b3JtYXRpdmVseSByZWZlcmVuY2UgSldUPyAgSSB3YW50IHRvIGF2b2lkIHRoZSB3aG9sZSAib24g YmVoYWxmIG9mIiAvICJhY3QgYXMiIGZpYXNjbyB3aGVyZSB0aGluZ3MgY2FuIGdldCByZS1kZWZp bmVkLCBhbmQgbXVkZGxlZC4NCg0KT24gTW9uLCBOb3YgMTYsIDIwMTUgYXQgNzowOSBBTSwgSGFu bmVzIFRzY2hvZmVuaWcgPEhhbm5lcy5Uc2Nob2ZlbmlnQGFybS5jb208bWFpbHRvOkhhbm5lcy5U c2Nob2ZlbmlnQGFybS5jb20+PiB3cm90ZToNCkhpIFdpbGxpYW0sDQoNCkkgaGF2ZSBiZWVuIHRy eWluZyB0byBkbyBhIGRvY3VtZW50IHVwZGF0ZSB0byBzZWUgaG93IHdlbGwgYSBjb21iaW5lZCBy ZWdpc3RyeSB3b3JrcyBhbmQgSSBoYXZlIGJlZW4gd29uZGVyaW5nIHdoZXRoZXIgaXQgaXMgcmVh bGx5IHdvcnRoIHRoZSBlZmZvcnQuDQpUbyBtYWtlIGEgZ29vZCBqdWRnbWVudCBJIGxvb2tlZCBh dCB0aGUgQ05GIGNsYWltIGRlZmluZWQgaW4gZHJhZnQtaWV0Zi1vYXV0aC1wcm9vZi1vZi1wb3Nz ZXNzaW9uLiBUaGUgQ05GIGNsYWltIG1heSBjb250YWluIHN1Yi1lbGVtZW50cywgc3VjaCBhcyBh IEpXRSBvciBhIEpXSy4NCg0KSWYgd2UgdHJhbnNsYXRlIHRoZSBzYW1lIG1lY2hhbmlzbXMgdG8g dGhlIENXVCAod2hpY2ggbWFrZXMgc2Vuc2UpIHRoZW4gd2UgbmVlZCB0byBwb2ludCB0byB0aGUg cmVzcGVjdGl2ZSBDT1NFIHN0cnVjdHVyZXMgaW5zdGVhZC4gVGhvc2UgZG8gbm90IG9ubHkgdXNl IGEgZGlmZmVyZW50IGVuY29kaW5nIGJ1dCBhbHNvIHRoZSBmdW5jdGlvbmFsaXR5IGRvZXMgbm90 IG1hdGNoIHRoZSBKT1NFIHN0cnVjdHVyZXMgMTAwJS4gU28sIHRoZXJlIGFyZSBwb3RlbnRpYWxs eSBkaWZmZXJlbmNlcy4gSSBhbSBhbHNvIG5vdCBzdXJlIHdoZXRoZXIgd2UgcmVhbGx5IHdhbnQg dG8gdHJhbnNsYXRlIHRoZSBmdWxsIGZ1bmN0aW9uYWxpdHkgb2YgYWxsIHRoZSBjbGFpbXMgZnJv bSBKV1Qgb3ZlciB0byB0aGUgQ1dUIGVxdWl2YWxlbnQuIEl0IGJhc2ljYWxseSBwdXRzIHRoZSBi dXJkZW4gb24gc29tZW9uZSBkZWZpbmluZyBuZXcgY2xhaW1zIChlaXRoZXIgaW4gSldUIG9yIGlu IENXVCkgdG8gY3JlYXRlIHRoZSBjb3JyZXNwb25kaW5nIHN0cnVjdHVyZXMgaW4gYSBmb3JtYXQg dGhleSBtYXkgbm90IG5lY2Vzc2FyaWx5IGJlIGZhbWlsaWFyIHdpdGggb3IgZXZlbiBjYXJlIGFi b3V0LiBJIGhhdmUgc2VlbiB0aGF0IGhhcHBlbmluZyBpbiB0aGUgUkFESVVTIHdvcmxkIHByb3Rv Y29sIGRlc2lnbmVycyBoYWQgdG8gYWxzbyBkZWZpbmUgdGhlIGVxdWl2YWxlbnQgc3RydWN0dXJl cyBmb3IgdXNlIHdpdGggRGlhbWV0ZXIgYW5kLCBndWVzcyB3aGF0LCBtb3N0IG9mIHRoZSBkZWZp bml0aW9ucyB3ZXJlIHdyb25nIChzaW5jZSB0aGUgYXV0aG9ycyBkaWQgbm90IGNhcmUgYWJvdXQg RGlhbWV0ZXIgd2hlbiB3b3JraW5nIG9uIFJBRElVUykuDQoNCkNpYW8NCkhhbm5lcw0KDQoNCkZy b206IFdpbGxpYW0gRGVubmlzcyBbbWFpbHRvOndkZW5uaXNzQGdvb2dsZS5jb208bWFpbHRvOndk ZW5uaXNzQGdvb2dsZS5jb20+XQ0KU2VudDogMTIgTm92ZW1iZXIgMjAxNSAxOToxOQ0KVG86IEVy aWsgV2FobHN0csO2bSBuZVh1cw0KQ2M6IENhcnN0ZW4gQm9ybWFubjsgSGFubmVzIFRzY2hvZmVu aWc7IE1pa2UgSm9uZXM7IGNvc2VAaWV0Zi5vcmc8bWFpbHRvOmNvc2VAaWV0Zi5vcmc+OyA8b2F1 dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPj47IGFjZUBpZXRmLm9yZzxtYWlsdG86 YWNlQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtDT1NFXSBBIGRyYWZ0IG9uIENCT1IgV2ViIFRv a2VucyAoQ1dUKQ0KDQpSZWdhcmRpbmcgdGhlIGRyYWZ0IGl0c2VsZiwgYSBmZXcgY29tbWVudHM6 DQoNCjEuDQpDYW4gd2UgdW5pZnkgdGhlIGNsYWltIHJlZ2lzdHJ5IHdpdGggSldUPyBJJ20gd29y cmllZCBhYm91dCBoYXZpbmcgdGhlIHNhbWUgY2xhaW1zIGRlZmluZWQgdHdpY2UgaW4gQ1dUIGFu ZCBKV1Qgd2l0aCBwb3NzaWJseSBjb25mbGljdGluZyBtZWFuaW5ncyAoYW5kIG5lZWRsZXNzIGNv bmZ1c2lvbiBldmVuIHdoZW4gdGhleSBkbyBtYXRjaCkuDQoNCkNvbXBhcmluZyBodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtd2FobHN0cm9lbS1vYXV0aC1jYm9yLXdlYi10b2tlbi0w MCNzZWN0aW9uLTMuMS4yIGFuZCBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzUxOSNz ZWN0aW9uLTQuMS4yIHdoaWNoIGFyZSBuZWFybHkgaWRlbnRpY2FsLCBJIGp1c3QgZG9uJ3Qgc2Vl IHRoZSB2YWx1ZSBpbiByZS1kZWZpbmluZyBpdC4NCg0KV2UgbWF5IGFkZCBuZXcgc3RhbmRhcmQg Y2xhaW1zIHRvIEpXVCBpbiB0aGUgZnV0dXJlIChJIHByb3Bvc2VkIG9uZTxodHRwczovL21haWxh cmNoaXZlLmlldGYub3JnL2FyY2gvc2VhcmNoLz9lbWFpbF9saXN0PWlkLWV2ZW50JmdidD0xJmlu ZGV4PTdxTlVuYUU5bHQyTHlheU1ubU55V3BaU0lFTT4gaW4gWW9rb2hhbWEgb24gdGhlIGlkLWV2 ZW50IGxpc3Q8aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZC1ldmVudD4p LCBpdCB3b3VsZCBiZSBnb29kIGlmIHRoaXMgZGlkbid0IG5lZWQgYSBzZXBhcmF0ZSBlbnRyeSBp biBDV1QgdG9vLCBidXQgY291bGQganVzdCBhcHBseSBkaXJlY3RseSAoc2VwYXJhdGVseSwgSSB0 aGluayB5b3Ugc2hvdWxkIGNvbnNpZGVyIHRoaXMgY2xhaW0sIGFzIGl0IGhlbHBzIHByZXZlbnQg dG9rZW5zIGZyb20gYmVpbmcgcmUtdXNlZCBpbiB0aGUgd3JvbmcgY29udGV4dCkuDQoNCjIuDQpJ cyBTZWN0aW9uIDQgIlN1bW1hcnkgb2YgQ0JPUiBtYWpvciB0eXBlcyB1c2VkIGJ5IGRlZmluZWQg Y2xhaW1zIiBub3JtYXRpdmUgKGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC13YWhs c3Ryb2VtLW9hdXRoLWNib3Itd2ViLXRva2VuLTAwI3NlY3Rpb24tNCk/IFdoYXQgaXMgdGhlIGlu dGVudGlvbiBvZiB0aGlzIHNlY3Rpb24/IEkgZmVlbCBsaWtlIGl0IGNvdWxkIHByb2JhYmx5IGJl IGZsZXNoZWQgb3V0IGEgYml0Lg0KDQozLg0KQWRkIGEgeHJlZiB0byBkcmFmdCBDT1NFIHNwZWMg aW4gc2VjdGlvbiA2PGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC13YWhsc3Ryb2Vt LW9hdXRoLWNib3Itd2ViLXRva2VuLTAwI3NlY3Rpb24tNj4NCkFkZCB4cmVmIHRvIFJGQzc1MTkN Cg0KT24gVGh1LCBOb3YgMTIsIDIwMTUgYXQgMTI6MDEgUE0sIEVyaWsgV2FobHN0csO2bSBuZVh1 cyA8ZXJpay53YWhsc3Ryb21AbmV4dXNncm91cC5jb208bWFpbHRvOmVyaWsud2FobHN0cm9tQG5l eHVzZ3JvdXAuY29tPj4gd3JvdGU6DQpIaSBDYXJzdGVuLA0KDQpUaGFua3MsIGFuZCBJIGFncmVl LiBJ4oCZdmUgaGVhcmQgYXJndW1lbnRzIGZvciBhbGwgdGhyZWUgd29yayBncm91cHMuDQoNCkJv cnJvd2VkIHNvbWUgb2YgeW91ciB3b3JkcyB0byBkZWZpbmUgdGhlIGNvbnRlbnQgb2YgdGhlIGRy YWZ0IDopDQpJdOKAmXMgaXQgZXNzZW50aWFsbHkgYSBKV1QsIHBocmFzZWQgaW4gYW5kIHByb2Zp bGVkIGZvciBDQk9SIHRvIGFkZHJlc3MgQUNFIG5lZWRzLCB3aGVyZSBPQXV0aCBuZWVkcyBDT1NF IGZ1bmN0aW9uYWxpdHksIGZvciBvYmplY3Qgc2VjdXJpdHkuDQoNCknigJltIG9wZW4gZm9yIGxl dHRpbmcgdGhlIEFE4oCZcyBtb3ZlIGl0IGFyb3VuZCwgYnV0IGhhdmluZyBpdCByaWdodCBuZXh0 IHRvIEpXVCBzZWVtcyByaWdodCB0byBtZS4gQWxzbyBvcGVuIGZvciB0aGUgQUNFIFdHLiBGZWVs IGl0IGhhcyBsZXNzIHBsYWNlIGluIENPU0UgZm9yIHRoZSBzYW1lIHJlYXNvbnMgSldUIGlzIG5v dCBpbiB0aGUgSk9TRSBXRy4NCg0KLyBFcmlrDQoNCg0KPiBPbiAxMiBOb3YgMjAxNSwgYXQgMjA6 NDUsIENhcnN0ZW4gQm9ybWFubiA8Y2Fib0B0emkub3JnPG1haWx0bzpjYWJvQHR6aS5vcmc+PiB3 cm90ZToNCj4NCj4gSGkgRXJpaywNCj4NCj4gaGF2aW5nIHRoaXMgZHJhZnQgaXMgYSBnb29kIHRo aW5nLg0KPg0KPiBPbmUgdGhpbmcgSSdtIHN0aWxsIHdvbmRlcmluZyBpcyB3aGF0IFdHIGlzIHRo ZSBiZXN0IHBsYWNlIHRvIHByb2dyZXNzDQo+IHRoaXMuICBXZSBwcm9iYWJseSBkb24ndCBuZWVk IHRvIHNwZW5kIHRvbyBtdWNoIHRpbWUgb24gdGhpcyBiZWNhdXNlLA0KPiByZWdhcmRsZXNzIG9m IHRoZSBXRyBjaG9zZW4sIHRoZSBwZW9wbGUgaW4gYW5vdGhlciBXRyBjYW4gbG9vayBhdCBpdC4N Cj4gU3RpbGwsIGdldHRpbmcgdGhpcyByaWdodCBtaWdodCBwcm92aWRlIHNvbWUgZWZmaWNpZW5j aWVzLg0KPg0KPiBXaGF0IGlzIHRoZSB0ZWNobmljYWwgY29udGVudCBvZiB0aGlzIGRyYWZ0PyAg SXMgaXQgYSBuZXcgdG9rZW4gdGhhdA0KPiBPQXV0aCBuZWVkcyBzcGVjaWZpY2FsbHkgZm9yIHRo ZSBuZXcgQ09TRS1iYXNlZCBhcHBsaWNhdGlvbnMgb2YgT0F1dGg/DQo+IElzIGl0IGEgbmV3IHRv a2VuIHRoYXQgaXMgc3BlY2lmaWNhbGx5IHRoZXJlIGZvciBhZGRyZXNzaW5nIEFDRSBuZWVkcz8N Cj4gT3IgaXMgaXQgZXNzZW50aWFsbHkgdGhlIHNhbWUgc3Vic3RhbmNlIGFzIEpXVCwgYnV0IHBo cmFzZWQgaW4gYW5kDQo+IHByb2ZpbGVkIGZvciBDQk9SPw0KPg0KPiBEZXBlbmRpbmcgb24gdGhl IGFuc3dlciwgQ1dUIHNob3VsZCBiZSBkb25lIGluIE9BdXRoLCBBQ0UsIG9yIENPU0UuDQo+IChJ J2QgcmF0aGVyIGhlYXIgdGhlIGFuc3dlciBmcm9tIHRoZSBhdXRob3JzIHRoYW4gdmVudHVyZSBh IGd1ZXNzIG15c2VsZi4pDQo+DQo+IEdyw7zDn2UsIENhcnN0ZW4NCj4NCj4NCj4NCj4gRXJpayBX YWhsc3Ryw7ZtIG5lWHVzIHdyb3RlOg0KPj4gSGksDQo+Pg0KPj4gSW4gdGhlIEFDRSBXRyBhIHN0 cmF3IG1hbiBwcm9wb3NhbCBvZiBhIENCT1IgV2ViIFRva2VuIChDV1QpIHdhcyBkZWZpbmVkDQo+ PiBpbiB0aGUgZHJhZnQgIkF1dGhvcml6YXRpb24gZm9yIHRoZSBJbnRlcm5ldCBvZiBUaGluZ3Mg dXNpbmcgT0F1dGggMi4w4oCdDQo+PiBbMV0uIFdlIGp1c3QgYnJva2Ugb3V0IHRoZSBDQk9SIFdl YiBUb2tlbiBpbnRvIGEgc2VwYXJhdGUgZHJhZnQgYW5kIHRoZQ0KPj4gbmV3IGRyYWZ0IGlzIHN1 Ym1pdHRlZCB0byB0aGUgT0FVVEggV0cuIEl0IGNhbiBiZSBmb3VuZCBoZXJlOg0KPj4NCj4+IGh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXdhaGxzdHJvZW0tb2F1dGgtY2Jv ci13ZWItdG9rZW4vDQo+Pg0KPj4gQWJzdHJhY3Q6DQo+PiAiQ0JPUiBXZWIgVG9rZW4gKENXVCkg aXMgYSBjb21wYWN0IG1lYW5zIG9mIHJlcHJlc2VudGluZyBjbGFpbXMgdG8gYmUNCj4+IHRyYW5z ZmVycmVkIGJldHdlZW4gdHdvIHBhcnRpZXMuICBDV1QgaXMgYSBwcm9maWxlIG9mIHRoZSBKU09O IFdlYiBUb2tlbg0KPj4gKEpXVCkgdGhhdCBpcyBvcHRpbWl6ZWQgZm9yIGNvbnN0cmFpbmVkIGRl dmljZXMuIFRoZSBjbGFpbXMgaW4gYSBDV1QgYXJlDQo+PiBlbmNvZGVkIGluIHRoZSBDb25jaXNl IEJpbmFyeSBPYmplY3QgUmVwcmVzZW50YXRpb24gKENCT1IpIGFuZCBDQk9SDQo+PiBPYmplY3Qg U2lnbmluZyBhbmQgRW5jcnlwdGlvbiAoQ09TRSkgaXMgdXNlZCBmb3IgYWRkZWQgYXBwbGljYXRp b24gbGF5ZXINCj4+IHNlY3VyaXR5IHByb3RlY3Rpb24uICBBIGNsYWltIGlzIGEgcGllY2Ugb2Yg aW5mb3JtYXRpb24gYXNzZXJ0ZWQgYWJvdXQgYQ0KPj4gc3ViamVjdCBhbmQgaXMgcmVwcmVzZW50 ZWQgYXMgYSBuYW1lL3ZhbHVlIHBhaXIgY29uc2lzdGluZyBvZiBhIGNsYWltDQo+PiBuYW1lIGFu ZCBhIGNsYWltIHZhbHVlLiINCj4+DQo+PiAvIEVyaWsNCj4+DQo+Pg0KPj4gWzFdIGh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zZWl0ei1hY2Utb2F1dGgtYXV0aHotMDANCj4+DQo+ Pg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ IENPU0UgbWFpbGluZyBsaXN0DQo+PiBDT1NFQGlldGYub3JnPG1haWx0bzpDT1NFQGlldGYub3Jn Pg0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3NlDQoNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpDT1NFIG1haWxpbmcg bGlzdA0KQ09TRUBpZXRmLm9yZzxtYWlsdG86Q09TRUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vY29zZQ0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQoNCi0tIElNUE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0aGlzIGVt YWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5IGFsc28gYmUg cHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNl IG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xvc2UgdGhlIGNv bnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24sIHVzZSBpdCBmb3IgYW55IHB1cnBvc2UsIG9yIHN0 b3JlIG9yIGNvcHkgdGhlIGluZm9ybWF0aW9uIGluIGFueSBtZWRpdW0uIFRoYW5rIHlvdS4NCg0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGgg bWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCg0KLS0gSU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRz IG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBt YXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBp ZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNj bG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBhbnkgcHVy cG9zZSwgb3Igc3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhh bmsgeW91Lg0K --_000_HE1PR08MB0732F817E687A11E59E5EDB1FA1D0HE1PR08MB0732eurp_ Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkhlbHZldGljYTsNCglwYW5vc2UtMToyIDExIDYgNCAyIDIgMiAyIDIg NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkhlbHZldGljYTsNCglwYW5vc2UtMToyIDEx IDYgNCAyIDIgMiAyIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVm aW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7 bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsN Cglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5N c29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9s bG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1z b0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxs b29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpz cGFuLnlpdjQxOTU0NzgwMDMNCgl7bXNvLXN0eWxlLW5hbWU6eWl2NDE5NTQ3ODAwMzt9DQpzcGFu LkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0K CW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsN Cglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjAN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1z dHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcy LjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+ DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIEJpbGwsDQo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PkZyb20gd2hhdCBJIGNhbiB0ZWxsIHRoZXJlIGFyZSBubyBkaWZmZXJlbmNlcyBpbiB0aGlzIHJl Z2FyZC4gT2YgY291cnNlLCB0aGUgZGF0YSBoYXMgdG8gYmUgZW5jb2RlZCBkaWZmZXJlbnRseSBh bmQgc28gdGhlcmUgaXMgYSBuZWVkIHRvIHN0YXRlIHRoZSBuZXcgZGF0YQ0KIHR5cGUgYnV0IGJl eW9uZCB0aGF0IEkgaGF2ZW7igJl0IHNlZW4gYW55IHJlc3RyaWN0aW9ucyB5ZXQuIE9mIGNvdXJz ZSwgdGhlIENPU0Ugd29yayBpcyBzdGlsbCBvbmdvaW5nIGFuZCBzbyBpdCBtaWdodCBiZSBhIGJp dCB0b28gZWFybHkgdG8gdGVsbC4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Q2lhbzxicj4NCkhhbm5lczxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gQmlsbCBNaWxscyBbbWFpbHRv OndtaWxsc185MjEwNUB5YWhvby5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gMTYgTm92ZW1iZXIg MjAxNSAyMjo1NTxicj4NCjxiPlRvOjwvYj4gV2lsbGlhbSBEZW5uaXNzOyBIYW5uZXMgVHNjaG9m ZW5pZzxicj4NCjxiPkNjOjwvYj4gQ2Fyc3RlbiBCb3JtYW5uOyAmbHQ7b2F1dGhAaWV0Zi5vcmcm Z3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIFtDT1NFXSBBIGRyYWZ0IG9u IENCT1IgV2ViIFRva2VucyAoQ1dUKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8 ZGl2IGlkPSJ5dWlfM18xNl8wXzFfMTQ0NzI4MTgxMTU4Ml8zMTE5NTEiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6YmxhY2siPklmIHRoZXJlIGFyZSBzdHJ1Y3R1cmFsIGRpZmZlcmVuY2VzIGlu IHdoYXQgQ0JPUiBjYW4gc3VwcG9ydCBpdCB3b3VsZCBiZSB3b3J0aHdoaWxlIHRvIG5vdGUgdGhh dC4gJm5ic3A7RXhhbXBsZXMgb2YgdGhpbmdzIHN1cHBvcnRlZCBpbiBKV1QNCiB0aGF0IHlvdSBj YW4ndCBkbyBpbiBDQk9SIGNvdWxkIGJlIHZlcnkgaGVscGZ1bCB0byBpbXBsZW1lbnRlcnMuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJ5dWlfM18xNl8wXzFfMTQ0NzI4 MTgxMTU4Ml8zMTE5NTEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6 d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymxh Y2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQ7YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6YmxhY2siPk9uIE1vbmRheSwgTm92ZW1iZXIgMTYsIDIwMTUgMTozMiBQTSwgV2ls bGlhbSBEZW5uaXNzICZsdDs8YSBocmVmPSJtYWlsdG86d2Rlbm5pc3NAZ29vZ2xlLmNvbSI+d2Rl bm5pc3NAZ29vZ2xlLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0O2JhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxk aXYgaWQ9InlpdjQxOTU0NzgwMDMiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5Zb3Ug cmFpc2Ugc29tZSBnb29kIHBvaW50cywgYW5kIHBlcmhhcHMgdGhhdCBpcyByZWxldmFudCB0byBm dXR1cmUgY2xhaW1zLiBUaGUgc3BlYyBhcyBkcmFmdGVkLCBpcyBhIG9uZS1mb3Itb25lIGNvcHkg b2YgdGhlIHN0YW5kYXJkIEpXVCBjbGFpbXMsIHdoaWNoDQogaXMgd2h5IEkgcmFpc2VkIHRoaXMg cG9pbnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPklz IHRoZSBnb2FsIGEgQ0JPUiByZXByZXNlbnRhdGlvbiBvZiBhIEpXVD8gSWYgc28sIGNhbiBpdCBi ZSBkZWZpbmVkIGluIHRlcm1zIG9mIGEgSldUPyZuYnNwOyBXb3VsZCB0aGUgQ05GIGNsYWltIHRo ZW4gaW5oZXJpdCB0aGF0IHJlcHJlc2VudGF0aW9uICh0cmVhdGluZw0KIHRoZSBKV0UgYW5kIEpX SyBhcyB0aGVpciBDQk9SIGVxdWl2YWxlbnRzKT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0 ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5QZXJoYXBzIGlmIHlvdSBnbyB0aGUgc2VwYXJh dGUgcmVnaXN0cnkgcm91dGUsIHRob3NlIGNsYWltcyB0aGF0ICphcmUqIGRlZmluZWQgdGhlIHNh bWUgc2hvdWxkIGF0IGxlYXN0IG5vcm1hdGl2ZWx5IHJlZmVyZW5jZSBKV1Q/Jm5ic3A7IEkgd2Fu dCB0byBhdm9pZA0KIHRoZSB3aG9sZSAmcXVvdDtvbiBiZWhhbGYgb2YmcXVvdDsgLyAmcXVvdDth Y3QgYXMmcXVvdDsgZmlhc2NvIHdoZXJlIHRoaW5ncyBjYW4gZ2V0IHJlLWRlZmluZWQsIGFuZCBt dWRkbGVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGlkPSJ5 aXY0MTk1NDc4MDAzeXF0NTE4NjEiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFj a2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5PbiBNb24sIE5vdiAxNiwg MjAxNSBhdCA3OjA5IEFNLCBIYW5uZXMgVHNjaG9mZW5pZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOkhh bm5lcy5Uc2Nob2ZlbmlnQGFybS5jb20iIHRhcmdldD0iX2JsYW5rIj5IYW5uZXMuVHNjaG9mZW5p Z0Bhcm0uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5IaSBXaWxsaWFtLA0K PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hp dGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkkgaGF2ZSBiZWVuIHRy eWluZyB0byBkbyBhIGRvY3VtZW50IHVwZGF0ZSB0byBzZWUgaG93IHdlbGwgYSBjb21iaW5lZCBy ZWdpc3RyeSB3b3JrcyBhbmQgSSBoYXZlIGJlZW4gd29uZGVyaW5nIHdoZXRoZXIgaXQgaXMgcmVh bGx5DQogd29ydGggdGhlIGVmZm9ydC4gPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOmJsYWNrIj5UbyBtYWtlIGEgZ29vZCBqdWRnbWVudCBJIGxvb2tlZCBhdCB0aGUgQ05G IGNsYWltIGRlZmluZWQgaW4gZHJhZnQtaWV0Zi1vYXV0aC1wcm9vZi1vZi1wb3NzZXNzaW9uLiBU aGUgQ05GIGNsYWltIG1heSBjb250YWluIHN1Yi1lbGVtZW50cywNCiBzdWNoIGFzIGEgSldFIG9y IGEgSldLLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3Jv dW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5i c3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6 d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5JZiB3ZSB0 cmFuc2xhdGUgdGhlIHNhbWUgbWVjaGFuaXNtcyB0byB0aGUgQ1dUICh3aGljaCBtYWtlcyBzZW5z ZSkgdGhlbiB3ZSBuZWVkIHRvIHBvaW50IHRvIHRoZSByZXNwZWN0aXZlIENPU0Ugc3RydWN0dXJl cyBpbnN0ZWFkLg0KIFRob3NlIGRvIG5vdCBvbmx5IHVzZSBhIGRpZmZlcmVudCBlbmNvZGluZyBi dXQgYWxzbyB0aGUgZnVuY3Rpb25hbGl0eSBkb2VzIG5vdCBtYXRjaCB0aGUgSk9TRSBzdHJ1Y3R1 cmVzIDEwMCUuIFNvLCB0aGVyZSBhcmUgcG90ZW50aWFsbHkgZGlmZmVyZW5jZXMuIEkgYW0gYWxz byBub3Qgc3VyZSB3aGV0aGVyIHdlIHJlYWxseSB3YW50IHRvIHRyYW5zbGF0ZSB0aGUgZnVsbCBm dW5jdGlvbmFsaXR5IG9mIGFsbCB0aGUgY2xhaW1zIGZyb20gSldUIG92ZXINCiB0byB0aGUgQ1dU IGVxdWl2YWxlbnQuIEl0IGJhc2ljYWxseSBwdXRzIHRoZSBidXJkZW4gb24gc29tZW9uZSBkZWZp bmluZyBuZXcgY2xhaW1zIChlaXRoZXIgaW4gSldUIG9yIGluIENXVCkgdG8gY3JlYXRlIHRoZSBj b3JyZXNwb25kaW5nIHN0cnVjdHVyZXMgaW4gYSBmb3JtYXQgdGhleSBtYXkgbm90IG5lY2Vzc2Fy aWx5IGJlIGZhbWlsaWFyIHdpdGggb3IgZXZlbiBjYXJlIGFib3V0LiBJIGhhdmUgc2VlbiB0aGF0 IGhhcHBlbmluZyBpbiB0aGUNCiBSQURJVVMgd29ybGQgcHJvdG9jb2wgZGVzaWduZXJzIGhhZCB0 byBhbHNvIGRlZmluZSB0aGUgZXF1aXZhbGVudCBzdHJ1Y3R1cmVzIGZvciB1c2Ugd2l0aCBEaWFt ZXRlciBhbmQsIGd1ZXNzIHdoYXQsIG1vc3Qgb2YgdGhlIGRlZmluaXRpb25zIHdlcmUgd3Jvbmcg KHNpbmNlIHRoZSBhdXRob3JzIGRpZCBub3QgY2FyZSBhYm91dCBEaWFtZXRlciB3aGVuIHdvcmtp bmcgb24gUkFESVVTKS4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi bGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJh Y2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNr Ij5DaWFvPGJyPg0KSGFubmVzPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymxh Y2siPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNr Z3JvdW5kOndoaXRlIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6YmxhY2siPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiBXaWxsaWFtDQogRGVubmlzcyBbbWFpbHRv OjxhIGhyZWY9Im1haWx0bzp3ZGVubmlzc0Bnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+d2Rl bm5pc3NAZ29vZ2xlLmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gMTIgTm92ZW1iZXIgMjAx NSAxOToxOTxicj4NCjxiPlRvOjwvYj4gRXJpayBXYWhsc3Ryw7ZtIG5lWHVzPGJyPg0KPGI+Q2M6 PC9iPiBDYXJzdGVuIEJvcm1hbm47IEhhbm5lcyBUc2Nob2ZlbmlnOyBNaWtlIEpvbmVzOyA8YSBo cmVmPSJtYWlsdG86Y29zZUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0KY29zZUBpZXRmLm9y ZzwvYT47ICZsdDs8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij5vYXV0aEBpZXRmLm9yZzwvYT4mZ3Q7Ow0KPGEgaHJlZj0ibWFpbHRvOmFjZUBpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPmFjZUBpZXRmLm9yZzwvYT48YnI+DQo8c3BhbiBjbGFzcz0ieWl2NDE5 NTQ3ODAwMyI+PGI+U3ViamVjdDo8L2I+IFJlOiBbQ09TRV0gQSBkcmFmdCBvbiBDQk9SIFdlYiBU b2tlbnMgKENXVCk8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OmJsYWNrIj5SZWdhcmRpbmcgdGhlIGRyYWZ0IGl0c2VsZiwgYSBmZXcgY29tbWVudHM6PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dy b3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4xLiZuYnNwOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2si PkNhbiB3ZSB1bmlmeSB0aGUgY2xhaW0gcmVnaXN0cnkgd2l0aCBKV1Q/IEknbSB3b3JyaWVkIGFi b3V0IGhhdmluZyB0aGUgc2FtZSBjbGFpbXMgZGVmaW5lZCB0d2ljZSBpbiBDV1QgYW5kIEpXVCB3 aXRoIHBvc3NpYmx5IGNvbmZsaWN0aW5nIG1lYW5pbmdzIChhbmQNCiBuZWVkbGVzcyBjb25mdXNp b24gZXZlbiB3aGVuIHRoZXkgZG8gbWF0Y2gpLiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 YmxhY2siPkNvbXBhcmluZyZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC13YWhsc3Ryb2VtLW9hdXRoLWNib3Itd2ViLXRva2VuLTAwI3NlY3Rpb24tMy4xLjIi IHRhcmdldD0iX2JsYW5rIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtd2FobHN0 cm9lbS1vYXV0aC1jYm9yLXdlYi10b2tlbi0wMCNzZWN0aW9uLTMuMS4yPC9hPg0KIGFuZCZuYnNw OzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3NTE5I3NlY3Rpb24tNC4x LjIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzUxOSNz ZWN0aW9uLTQuMS4yPC9hPiB3aGljaCBhcmUgbmVhcmx5IGlkZW50aWNhbCwgSSBqdXN0IGRvbid0 IHNlZSB0aGUgdmFsdWUgaW4gcmUtZGVmaW5pbmcgaXQuPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi bGFjayI+V2UgbWF5IGFkZCBuZXcgc3RhbmRhcmQgY2xhaW1zIHRvIEpXVCBpbiB0aGUgZnV0dXJl IChJJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL3NlYXJj aC8/ZW1haWxfbGlzdD1pZC1ldmVudCZhbXA7Z2J0PTEmYW1wO2luZGV4PTdxTlVuYUU5bHQyTHlh eU1ubU55V3BaU0lFTSIgdGFyZ2V0PSJfYmxhbmsiPnByb3Bvc2VkDQogb25lPC9hPiZuYnNwO2lu IFlva29oYW1hIG9uIHRoZSZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vaWQtZXZlbnQiIHRhcmdldD0iX2JsYW5rIj5pZC1ldmVudCBsaXN0PC9hPiks IGl0IHdvdWxkIGJlIGdvb2QgaWYgdGhpcyBkaWRuJ3QgbmVlZCBhIHNlcGFyYXRlIGVudHJ5IGlu IENXVCB0b28sIGJ1dCBjb3VsZCBqdXN0IGFwcGx5IGRpcmVjdGx5IChzZXBhcmF0ZWx5LCBJIHRo aW5rIHlvdSBzaG91bGQgY29uc2lkZXINCiB0aGlzIGNsYWltLCBhcyBpdCBoZWxwcyBwcmV2ZW50 IHRva2VucyBmcm9tIGJlaW5nIHJlLXVzZWQgaW4gdGhlIHdyb25nIGNvbnRleHQpLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymxh Y2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6YmxhY2siPjIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91 bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+SXMgU2VjdGlvbiA0ICZxdW90O1N1 bW1hcnkgb2YgQ0JPUiBtYWpvciB0eXBlcyB1c2VkIGJ5IGRlZmluZWQgY2xhaW1zJnF1b3Q7IG5v cm1hdGl2ZSAoPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXdhaGxz dHJvZW0tb2F1dGgtY2Jvci13ZWItdG9rZW4tMDAjc2VjdGlvbi00IiB0YXJnZXQ9Il9ibGFuayI+ aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXdhaGxzdHJvZW0tb2F1dGgtY2Jvci13 ZWItdG9rZW4tMDAjc2VjdGlvbi00PC9hPik/DQogV2hhdCBpcyB0aGUgaW50ZW50aW9uIG9mIHRo aXMgc2VjdGlvbj8gSSBmZWVsIGxpa2UgaXQgY291bGQgcHJvYmFibHkgYmUgZmxlc2hlZCBvdXQg YSBiaXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91 bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+My4mbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5B ZGQgYSB4cmVmIHRvIGRyYWZ0IENPU0Ugc3BlYyBpbiZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC13YWhsc3Ryb2VtLW9hdXRoLWNib3Itd2ViLXRva2VuLTAw I3NlY3Rpb24tNiIgdGFyZ2V0PSJfYmxhbmsiPnNlY3Rpb24gNjwvYT48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5BZGQg eHJlZiB0byBSRkM3NTE5PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjpibGFjayI+T24gVGh1LCBOb3YgMTIsIDIwMTUgYXQgMTI6MDEgUE0sIEVyaWsg V2FobHN0csO2bSBuZVh1cyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmVyaWsud2FobHN0cm9tQG5leHVz Z3JvdXAuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZXJpay53YWhsc3Ryb21AbmV4dXNncm91cC5jb208 L2E+Jmd0Ow0KIHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6YmxhY2siPkhpIENhcnN0ZW4sPGJyPg0KPGJyPg0KVGhhbmtzLCBhbmQgSSBhZ3JlZS4g SeKAmXZlIGhlYXJkIGFyZ3VtZW50cyBmb3IgYWxsIHRocmVlIHdvcmsgZ3JvdXBzLjxicj4NCjxi cj4NCkJvcnJvd2VkIHNvbWUgb2YgeW91ciB3b3JkcyB0byBkZWZpbmUgdGhlIGNvbnRlbnQgb2Yg dGhlIGRyYWZ0IDopPGJyPg0KSXTigJlzIGl0IGVzc2VudGlhbGx5IGEgSldULCBwaHJhc2VkIGlu IGFuZCBwcm9maWxlZCBmb3IgQ0JPUiB0byBhZGRyZXNzIEFDRSBuZWVkcywgd2hlcmUgT0F1dGgg bmVlZHMgQ09TRSBmdW5jdGlvbmFsaXR5LCBmb3Igb2JqZWN0IHNlY3VyaXR5Ljxicj4NCjxicj4N CknigJltIG9wZW4gZm9yIGxldHRpbmcgdGhlIEFE4oCZcyBtb3ZlIGl0IGFyb3VuZCwgYnV0IGhh dmluZyBpdCByaWdodCBuZXh0IHRvIEpXVCBzZWVtcyByaWdodCB0byBtZS4gQWxzbyBvcGVuIGZv ciB0aGUgQUNFIFdHLiBGZWVsIGl0IGhhcyBsZXNzIHBsYWNlIGluIENPU0UgZm9yIHRoZSBzYW1l IHJlYXNvbnMgSldUIGlzIG5vdCBpbiB0aGUgSk9TRSBXRy48YnI+DQo8L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiM4ODg4ODgiPjxicj4NCi8gRXJpazwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjpibGFjayI+PGJyPg0KPGJyPg0KJmd0OyBPbiAxMiBOb3YgMjAxNSwgYXQgMjA6 NDUsIENhcnN0ZW4gQm9ybWFubiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNhYm9AdHppLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPmNhYm9AdHppLm9yZzwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDs8YnI+DQom Z3Q7IEhpIEVyaWssPGJyPg0KJmd0Ozxicj4NCiZndDsgaGF2aW5nIHRoaXMgZHJhZnQgaXMgYSBn b29kIHRoaW5nLjxicj4NCiZndDs8YnI+DQomZ3Q7IE9uZSB0aGluZyBJJ20gc3RpbGwgd29uZGVy aW5nIGlzIHdoYXQgV0cgaXMgdGhlIGJlc3QgcGxhY2UgdG8gcHJvZ3Jlc3M8YnI+DQomZ3Q7IHRo aXMuJm5ic3A7IFdlIHByb2JhYmx5IGRvbid0IG5lZWQgdG8gc3BlbmQgdG9vIG11Y2ggdGltZSBv biB0aGlzIGJlY2F1c2UsPGJyPg0KJmd0OyByZWdhcmRsZXNzIG9mIHRoZSBXRyBjaG9zZW4sIHRo ZSBwZW9wbGUgaW4gYW5vdGhlciBXRyBjYW4gbG9vayBhdCBpdC48YnI+DQomZ3Q7IFN0aWxsLCBn ZXR0aW5nIHRoaXMgcmlnaHQgbWlnaHQgcHJvdmlkZSBzb21lIGVmZmljaWVuY2llcy48YnI+DQom Z3Q7PGJyPg0KJmd0OyBXaGF0IGlzIHRoZSB0ZWNobmljYWwgY29udGVudCBvZiB0aGlzIGRyYWZ0 PyZuYnNwOyBJcyBpdCBhIG5ldyB0b2tlbiB0aGF0PGJyPg0KJmd0OyBPQXV0aCBuZWVkcyBzcGVj aWZpY2FsbHkgZm9yIHRoZSBuZXcgQ09TRS1iYXNlZCBhcHBsaWNhdGlvbnMgb2YgT0F1dGg/PGJy Pg0KJmd0OyBJcyBpdCBhIG5ldyB0b2tlbiB0aGF0IGlzIHNwZWNpZmljYWxseSB0aGVyZSBmb3Ig YWRkcmVzc2luZyBBQ0UgbmVlZHM/PGJyPg0KJmd0OyBPciBpcyBpdCBlc3NlbnRpYWxseSB0aGUg c2FtZSBzdWJzdGFuY2UgYXMgSldULCBidXQgcGhyYXNlZCBpbiBhbmQ8YnI+DQomZ3Q7IHByb2Zp bGVkIGZvciBDQk9SPzxicj4NCiZndDs8YnI+DQomZ3Q7IERlcGVuZGluZyBvbiB0aGUgYW5zd2Vy LCBDV1Qgc2hvdWxkIGJlIGRvbmUgaW4gT0F1dGgsIEFDRSwgb3IgQ09TRS48YnI+DQomZ3Q7IChJ J2QgcmF0aGVyIGhlYXIgdGhlIGFuc3dlciBmcm9tIHRoZSBhdXRob3JzIHRoYW4gdmVudHVyZSBh IGd1ZXNzIG15c2VsZi4pPGJyPg0KJmd0Ozxicj4NCiZndDsgR3LDvMOfZSwgQ2Fyc3Rlbjxicj4N CiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgRXJpayBXYWhsc3Ryw7ZtIG5lWHVz IHdyb3RlOjxicj4NCiZndDsmZ3Q7IEhpLDxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgSW4g dGhlIEFDRSBXRyBhIHN0cmF3IG1hbiBwcm9wb3NhbCBvZiBhIENCT1IgV2ViIFRva2VuIChDV1Qp IHdhcyBkZWZpbmVkPGJyPg0KJmd0OyZndDsgaW4gdGhlIGRyYWZ0ICZxdW90O0F1dGhvcml6YXRp b24gZm9yIHRoZSBJbnRlcm5ldCBvZiBUaGluZ3MgdXNpbmcgT0F1dGggMi4w4oCdPGJyPg0KJmd0 OyZndDsgWzFdLiBXZSBqdXN0IGJyb2tlIG91dCB0aGUgQ0JPUiBXZWIgVG9rZW4gaW50byBhIHNl cGFyYXRlIGRyYWZ0IGFuZCB0aGU8YnI+DQomZ3Q7Jmd0OyBuZXcgZHJhZnQgaXMgc3VibWl0dGVk IHRvIHRoZSBPQVVUSCBXRy4gSXQgY2FuIGJlIGZvdW5kIGhlcmU6PGJyPg0KJmd0OyZndDs8YnI+ DQomZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC13YWhsc3Ryb2VtLW9hdXRoLWNib3Itd2ViLXRva2VuLyIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtd2FobHN0cm9lbS1vYXV0aC1jYm9y LXdlYi10b2tlbi88L2E+PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBBYnN0cmFjdDo8YnI+ DQomZ3Q7Jmd0OyAmcXVvdDtDQk9SIFdlYiBUb2tlbiAoQ1dUKSBpcyBhIGNvbXBhY3QgbWVhbnMg b2YgcmVwcmVzZW50aW5nIGNsYWltcyB0byBiZTxicj4NCiZndDsmZ3Q7IHRyYW5zZmVycmVkIGJl dHdlZW4gdHdvIHBhcnRpZXMuJm5ic3A7IENXVCBpcyBhIHByb2ZpbGUgb2YgdGhlIEpTT04gV2Vi IFRva2VuPGJyPg0KJmd0OyZndDsgKEpXVCkgdGhhdCBpcyBvcHRpbWl6ZWQgZm9yIGNvbnN0cmFp bmVkIGRldmljZXMuIFRoZSBjbGFpbXMgaW4gYSBDV1QgYXJlPGJyPg0KJmd0OyZndDsgZW5jb2Rl ZCBpbiB0aGUgQ29uY2lzZSBCaW5hcnkgT2JqZWN0IFJlcHJlc2VudGF0aW9uIChDQk9SKSBhbmQg Q0JPUjxicj4NCiZndDsmZ3Q7IE9iamVjdCBTaWduaW5nIGFuZCBFbmNyeXB0aW9uIChDT1NFKSBp cyB1c2VkIGZvciBhZGRlZCBhcHBsaWNhdGlvbiBsYXllcjxicj4NCiZndDsmZ3Q7IHNlY3VyaXR5 IHByb3RlY3Rpb24uJm5ic3A7IEEgY2xhaW0gaXMgYSBwaWVjZSBvZiBpbmZvcm1hdGlvbiBhc3Nl cnRlZCBhYm91dCBhPGJyPg0KJmd0OyZndDsgc3ViamVjdCBhbmQgaXMgcmVwcmVzZW50ZWQgYXMg YSBuYW1lL3ZhbHVlIHBhaXIgY29uc2lzdGluZyBvZiBhIGNsYWltPGJyPg0KJmd0OyZndDsgbmFt ZSBhbmQgYSBjbGFpbSB2YWx1ZS4mcXVvdDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IC8g RXJpazxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBbMV0gPGEgaHJl Zj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNlaXR6LWFjZS1vYXV0aC1hdXRo ei0wMCIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LXNlaXR6LWFjZS1vYXV0aC1hdXRoei0wMDwvYT48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7 PGJyPg0KJmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+DQomZ3Q7Jmd0OyBDT1NFIG1haWxpbmcgbGlzdDxicj4NCiZndDsmZ3Q7IDxhIGhy ZWY9Im1haWx0bzpDT1NFQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+Q09TRUBpZXRmLm9yZzwv YT48YnI+DQomZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2Nvc2UiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2Nvc2U8L2E+PGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188YnI+DQpDT1NFIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9 Im1haWx0bzpDT1NFQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+Q09TRUBpZXRmLm9yZzwvYT48 YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Nvc2Ui IHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Nv c2U8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249 ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4NCjxociBzaXplPSIyIiB3aWR0aD0iMTAwJSIgYWxpZ249 ImNlbnRlciI+DQo8L3NwYW4+PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFj a2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PGJy Pg0KLS0gSU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFu eSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2Vk LiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRo ZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8g YW55IG90aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBhbnkNCiBwdXJwb3NlLCBvciBzdG9yZSBvciBj b3B5IHRoZSBpbmZvcm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFuayB5b3UuPC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tn cm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPGRpdiBpZD0ieXF0MDc0NzYiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+X19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5n IGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3Jn PC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v b2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0O2JhY2tncm91bmQ6d2hpdGUiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJyPg0KPGhyPg0K PGZvbnQgZmFjZT0iQXJpYWwiIGNvbG9yPSJCbGFjayIgc2l6ZT0iMiI+PGJyPg0KLS0gSU1QT1JU QU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50 cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJl IG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1t ZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBl cnNvbiwgdXNlIGl0IGZvciBhbnkNCiBwdXJwb3NlLCBvciBzdG9yZSBvciBjb3B5IHRoZSBpbmZv cm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFuayB5b3UuPGJyPg0KPC9mb250Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_HE1PR08MB0732F817E687A11E59E5EDB1FA1D0HE1PR08MB0732eurp_-- From nobody Tue Nov 17 02:41:37 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 935F41A1B51 for ; Tue, 17 Nov 2015 02:41:36 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BAxNntSHvd4y for ; Tue, 17 Nov 2015 02:41:35 -0800 (PST) Received: from p3plsmtpa06-03.prod.phx3.secureserver.net (p3plsmtpa06-03.prod.phx3.secureserver.net [173.201.192.104]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CA501A1B48 for ; Tue, 17 Nov 2015 02:41:35 -0800 (PST) Received: from [192.168.0.106] ([77.77.164.50]) by p3plsmtpa06-03.prod.phx3.secureserver.net with id iahZ1r00E15ZTut01ahadc; Tue, 17 Nov 2015 03:41:34 -0700 To: "oauth@ietf.org" From: Vladimir Dzhuvinov Organization: Connect2id Ltd. Message-ID: <564B045C.50301@connect2id.com> Date: Tue, 17 Nov 2015 12:41:32 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms040804080804030608070803" Archived-At: Subject: [OAUTH-WG] RFC 7662 OAuth 2.0 Token Introspection: token_type X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2015 10:41:36 -0000 This is a cryptographically signed message in MIME format. --------------ms040804080804030608070803 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable The "token_type" parameter in introspection responses - is that supposed to be "access_token" / "refresh_token", or the type of the access token, e.g. "Bearer"? https://tools.ietf.org/html/rfc7662#section-2.2 Section 5.1 in RFC 6749 that is referred to points to section 7.1 which seems to imply the latter? http://tools.ietf.org/html/rfc6749#section-7.1 Thanks, Vladimir --=20 Vladimir Dzhuvinov --------------ms040804080804030608070803 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfwwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggVFMIIELaADAgECAhAJWTI81U+XNs3vMVNsyOgrMA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTUwMzEyMDAwMDAwWhcNMTYwMzExMjM1OTU5WjAoMSYwJAYJKoZIhvcNAQkB Fhd2bGFkaW1pckBjb25uZWN0MmlkLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAKOyFE/JGyJPkJxnDLNMCit/gIMcHHimJ4QTbV7YNMReIh7/ccO9FQNwmmF4GCq347yB /eYy+9FXLh21Zp61RO3fSnCnEVmwNL5TwCF63iCSDLDEtXnx7AznLTV6MlheEljNtA7Cegos IM/XWE5NrzuO2vmHnj7C59uoGv4FTmcgVCDBJQ23Sdsju0zyNuAETqDyDw6yVwAfRlq+klRg G/ZZFn1D1iDRHyehgkwIoqc1cDbMPEcgkrS3ulWZhh8fGz/EQNo0JzUlwWe25DGpcSRrf47W yMHrVcP5HEQWFxEfGwQmZuNdYb/fzhnYThqGP0AjY2VMicAyOdttbbhutCsCAwEAAaOCAfUw ggHxMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBTiAjTIj8gY Zm3ThRvtNvKtyZoWRjAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0w OwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5u ZXQvQ1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9E T1NIQTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsG AQUFBwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01P RE9TSEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsG AQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wIgYDVR0RBBswGYEXdmxhZGltaXJA Y29ubmVjdDJpZC5jb20wDQYJKoZIhvcNAQELBQADggEBAC2rpYhJKODFdxGV5tBkuFuqW5/6 cnQ30GrREyk8/cLCWKhyvrMsnPnpK1ItafcQr4QPbR1hQcw0w7wzWBAl7FMjhpEVZIv286hM j+BStZPW4LTRiAHPo0Z7oEGvXPGuUuG2e6k0vAV65x7XN4S/wBYKQYg6hRatjK9Lhrlqr9K+ +Rg48LvWFdNbZ5F6VlQSHVBjX7bgQ86uUz0hRawCicJuTxE3J5fVWdfy2MULS5joW6js7V1J Hy86a/qyMZwqscXKPdv1W+UKAePtdGqKJbsZ6TFniBweSqa2pw7traBZ/ko65W2LEPi4tAhS KA7LaumILDPe82VqFHkHX4zuYC8xggRBMIIEPQIBATCBsDCBmzELMAkGA1UEBhMCR0IxGzAZ BgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRo ZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAJWTI81U+XNs3vMVNsyOgrMA0GCWCG SAFlAwQCAQUAoIICYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNTExMTcxMDQxMzJaMC8GCSqGSIb3DQEJBDEiBCCoKWVISaUI1+YBXc2ZVSEZcpchNl6M GQctnMaCjXSuyjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIw CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G CCqGSIb3DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQCVkyPNVPlzbN7zFTbMjoKzCBwwYLKoZI hvcNAQkQAgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEw PwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3Vy ZSBFbWFpbCBDQQIQCVkyPNVPlzbN7zFTbMjoKzANBgkqhkiG9w0BAQEFAASCAQBYErpzNVvC yNgGPF8BuzlnhoAQQ83KaQ2Gndo4Op5PlzG/y/7wmSbe11T+sFv+W/8iiCBDFUSOAewgldTh 0HaGKUnSTdl1b2bP6xbuVmQJvxFdsxKAkwQtTVh3eB5pY9zVK2TuTNcmSmwD89N/Dfjh0oZF RCPbvyZtw1eOx3dsuM+RM+XZEoe3XlAKzEWeEiFWOMYDhU0VvHISIe75CfqEP+uVHwSRdMof FJcTEtXHkglGFmepGbUxRLepBlDqaih0QPJVHfxga4ReCHtZDFdIGqagc1ALeEOqJ8Efqgow C1w8vliSsddAob7UCX92ckL6IN6G6Ib+qaoLCCliC2kRAAAAAAAA --------------ms040804080804030608070803-- From nobody Tue Nov 17 03:16:56 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 216021B2E39 for ; Tue, 17 Nov 2015 03:16:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.185 X-Spam-Level: X-Spam-Status: No, score=-3.185 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ERvzeBu3UKm for ; Tue, 17 Nov 2015 03:16:53 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3980C1B2E38 for ; Tue, 17 Nov 2015 03:16:52 -0800 (PST) Received: from [192.168.10.133] ([80.92.121.34]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0LcBBl-1ahddn2bsD-00jWZg; Tue, 17 Nov 2015 12:16:50 +0100 To: Vladimir Dzhuvinov , "oauth@ietf.org" References: <564B045C.50301@connect2id.com> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <564B0C9A.5030809@gmx.net> Date: Tue, 17 Nov 2015 12:16:42 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <564B045C.50301@connect2id.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="f7PuAticHOmHomRKqUIfLeAJPQEtU0BsI" X-Provags-ID: V03:K0:yy2Bj/igwlKKuOu0uVBU3xVXmyJZla/Bicb6ck87zVug8l3DhMT wZNRW0wFEwQYXu+f8UScD3YBfeJ/s2PObLAiuMqGB9Dm2USZ8QC36Z7T5OaWYoMT+yTxk6N 42tztplwXr1TJds/ou82py4YdnnrcwE2QQCCyLc6yl4XLBWEf5BVCtCjDES5XSTMAJPaMhx Z6xvrcz1k6JXQURFqNzlw== X-UI-Out-Filterresults: notjunk:1;V01:K0:vtKEs5o/QoY=:07m02bvFTMxbbFtI+zn4UO gTvUjUs8fSXuFSOneubarkuTBZYKzixhIgh96QAG81F7PpPbnag7qdwuCO03ywZT1oZVbNYde cZrv+qBBPkSee9QYamrsLS7PzMWTDoTW7WPuuG5w4Fy+fKm+Q0Dr8OKW+5qWFvEGMSYwjcKGC Iib+hNiccSKea6aJkASmK0ndvisPV3Uce+4Rvw3KNFgi3SSzp5oZ0ypb0owGkhki22pZuCq08 hiO8/tyfDZI4HcHrZIRxlE1+2t++BvN0F0uUyKl9alF4TYXIJxPsptkYGRXRXmCFK9Y2DPoZL Ouiqj2/Qr791EjC9U9kPWRHh//2ffI12xHqc3U6kbOciCxwnpoACSLb8535pIEEvoJZVGxWbx nTQUbfbBhO/BPWXsqpIJMMFajEjKUOQ4hAeYvv1YdjX7dOVBtrVWS/hmZXJjpV6hjCMq9GOjJ LpFuOBfSk8J431N2Rt2uUdTrCEMoS0HKcvSQ2PhsKvLlNM9cnb3BPJ7rnU0pbmi2fm8pefhAL jQVqGH6Xj8hl3+T1Zc20tm+bW/9b5XlhQsz8yxpsn+qb259LBkpkFnt8Uenxh3sr1iUIBM1Xj AN61LiRacR1/+YnfzbiIVFVK5VXdThhrYHTQo50ytLaD1j3AlpBhy1gzoOpa8VTGVMed1rf6O YEbwC+rpPYApiCrw7d9FlbezWrvKcwo6mHiXlbAzYbsZANCm3EL+R6BKFNiEE75HgU+HFsrEe Z/3CfP/xoUae9gduoc+qlOVQvyB+ae5ZtSYax9aH4egu+80G1wtqJFCDf+w= Archived-At: Subject: Re: [OAUTH-WG] RFC 7662 OAuth 2.0 Token Introspection: token_type X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2015 11:16:55 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --f7PuAticHOmHomRKqUIfLeAJPQEtU0BsI Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Vladimir, it is 'Bearer'. Section 5.1 in RFC 6749 defines the token_type concept and RFC 6750 registers the 'Bearer' token value (since it defines the bearer token concept). We currently have work going on with the PoP token work to also extend the concept further. Ciao Hannes On 11/17/2015 11:41 AM, Vladimir Dzhuvinov wrote: > The "token_type" parameter in introspection responses - is that suppose= d > to be "access_token" / "refresh_token", or the type of the access token= , > e.g. "Bearer"? >=20 > https://tools.ietf.org/html/rfc7662#section-2.2 >=20 > Section 5.1 in RFC 6749 that is referred to points to section 7.1 which= > seems to imply the latter? >=20 > http://tools.ietf.org/html/rfc6749#section-7.1 >=20 > Thanks, >=20 > Vladimir >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 --f7PuAticHOmHomRKqUIfLeAJPQEtU0BsI Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJWSwyaAAoJEGhJURNOOiAtdlAH/i9iory5bBwrQ4wWtBzC0LT6 MlDTJrXlnDgfcvNNs2SAqmNFOwNCtWWLiK3i4UzY0C+6gESLcXVnOsSP5A3iG2Gy KT6sAiRVP1nWv4AJzxWx+6rF6rzH7R5FSThcleW8B6j/aHIS4dt8KD1JO8xq+6Pu iEJ6d8azNp7YLZw+Zhbtk+ac9hSb+HlVNdQ++uZsfTYoTGv9JYR3rGECwb0e2mlo bCq/IhmlL/4NejYJHnCAHbCbNOF5xV1ZFsU8wktHphnTipH4TUUZCrwxn5gy8rlj FBAalpNZRlumgzN4Obh9oo+u9gYEv8ES3cEmTOPrNsy341qVCyzx2vGyhoj+A4U= =lknq -----END PGP SIGNATURE----- --f7PuAticHOmHomRKqUIfLeAJPQEtU0BsI-- From nobody Tue Nov 17 09:52:18 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1AE51B2CEE for ; Tue, 17 Nov 2015 09:52:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.084 X-Spam-Level: X-Spam-Status: No, score=-0.084 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zS9jXkgR3YfC for ; Tue, 17 Nov 2015 09:52:12 -0800 (PST) Received: from nm6.bullet.mail.bf1.yahoo.com (nm6.bullet.mail.bf1.yahoo.com [98.139.212.165]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA8121B2CDB for ; Tue, 17 Nov 2015 09:52:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1447782731; bh=fzoeOryD8M1Qwx6v4T/SxRvAXjrlbK/ax8p0IkBD83U=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=JbuYd2vFGeW7cMaIiDgVe2xI1cyE9spKnO4GnXpM3A0+D7q09ALnfMdUNVvCFvzwBcT2jr4RYbsIKZqoTHUUFnJOlC5rF5o1NVMubNUeicBdKO/SezaAXS9Y9ESvp+KTmid7CUZUeR70dl0UPV46CLU/22KH/bftBTGqJKvM6/KuI9n32zWfrkvxJQpe+5M5cHeDKbF3eOojcJ7lTs9Imavxg+gBk9nV+DUhw36VWJXSpaepf+W5PbZUISxkH4KSGHEqE/F22wLTjFnyFkRmSlCWHYo+9k5uL0Bm0Zq5lvdIobWRCYpBPInfNkJqmn/Q0L+M5P85EOHSh+C0pLBc7Q== Received: from [66.196.81.172] by nm6.bullet.mail.bf1.yahoo.com with NNFMP; 17 Nov 2015 17:52:11 -0000 Received: from [98.139.212.200] by tm18.bullet.mail.bf1.yahoo.com with NNFMP; 17 Nov 2015 17:52:11 -0000 Received: from [127.0.0.1] by omp1009.mail.bf1.yahoo.com with NNFMP; 17 Nov 2015 17:52:11 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 35460.25404.bm@omp1009.mail.bf1.yahoo.com X-YMail-OSG: KoqATPQVM1mQa9Ubm03Kze7a6MFLcVo_FXFGRzs4MwQVB_wZrYmRKFPoHfaRN7l KDR_npS21GCo_JX5WlsAIFy2pkv5vncCHZSy_Udc2MeeH5o6L9NnsoUAaA7taiOgY2YhO2rDFybj K8VRkAHdy5lMI_XAYbl60HtzURjNKg0kqMnFJ7w5GXtO6tq1JueY6AfNdqpf0krpStttdZwsIm_F 1ALA6L2FTqAfdZhJZwvfTkT32LcrfqaWenC6p96hntiS6Q0qmM2opqknBr_o3tArS7BCS.kmyQ9_ YCjdnG.4L.AzPzAkfsEsykq41iGtBcEa5WQy.wjNOhNPIKcFn8KYK6avoIzKgnWpLSYaS57WbGI4 LYh8UzPMf6d5ct5C9jx0o7AxoGm85Sap5XxTpn3R9KhqQQCURgmg3O4JSqlBQtkgBrWNzoE6b7LJ 6v4NTPJeldI_3syJLhtF17Ql3gCx9HuMSdwiTtJGldvuwn6Dt3ZrV1nk80z3BXRhiph9iONJa1I. s1m18B8KMBggNFTp0qslEWhBOQv7j5qeRW0NMw1mizj7bD4CMt.dlYDNR8Qk3wybl2kc48NU- Received: by 66.196.80.114; Tue, 17 Nov 2015 17:52:10 +0000 Date: Tue, 17 Nov 2015 17:52:10 +0000 (UTC) From: Bill Mills To: Hannes Tschofenig , William Denniss Message-ID: <1371112237.6425773.1447782730081.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_6425772_1609887347.1447782730062" Archived-At: Cc: "" Subject: Re: [OAUTH-WG] [COSE] A draft on CBOR Web Tokens (CWT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2015 17:52:16 -0000 ------=_Part_6425772_1609887347.1447782730062 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Is a data type mapping form JWT to CBOR sufficient then? On Monday, November 16, 2015 11:26 PM, Hannes Tschofenig wrote: =20 #yiv5390846737 #yiv5390846737 -- _filtered #yiv5390846737 {font-family:Cal= ibri;panose-1:2 15 5 2 2 2 4 3 2 4;} _filtered #yiv5390846737 {font-family:= Tahoma;panose-1:2 11 6 4 3 5 4 4 2 4;}#yiv5390846737 #yiv5390846737 p.yiv53= 90846737MsoNormal, #yiv5390846737 li.yiv5390846737MsoNormal, #yiv5390846737= div.yiv5390846737MsoNormal {margin:0cm;margin-bottom:.0001pt;font-size:12.= 0pt;}#yiv5390846737 a:link, #yiv5390846737 span.yiv5390846737MsoHyperlink {= color:blue;text-decoration:underline;}#yiv5390846737 a:visited, #yiv5390846= 737 span.yiv5390846737MsoHyperlinkFollowed {color:purple;text-decoration:un= derline;}#yiv5390846737 p.yiv5390846737MsoAcetate, #yiv5390846737 li.yiv539= 0846737MsoAcetate, #yiv5390846737 div.yiv5390846737MsoAcetate {margin:0cm;m= argin-bottom:.0001pt;font-size:8.0pt;}#yiv5390846737 span.yiv5390846737Emai= lStyle17 {color:#1F497D;}#yiv5390846737 span.yiv5390846737BalloonTextChar {= }#yiv5390846737 .yiv5390846737MsoChpDefault {} _filtered #yiv5390846737 {ma= rgin:72.0pt 72.0pt 72.0pt 72.0pt;}#yiv5390846737 div.yiv5390846737WordSecti= on1 {}#yiv5390846737 Hi William, =C2=A0 You are indeed correct that the cu= rrent document contains a list of one-by-one copies of claims from the JWT.= The only difference is the data type. Probably it would have been better t= o just reference the semantic from the JWT spec and then state the new data= type. =C2=A0 I fully understand the concern of defining CWT claims that h= ave the same name as JWT claims but then different semantic. This would be = terribly confusing. =C2=A0 Ciao Hannes =C2=A0 From: William Denniss [mail= to:wdenniss@google.com] Sent: 16 November 2015 22:32 To: Hannes Tschofenig Cc: Erik Wahlstr=C3=B6m neXus; Carsten Bormann; Mike Jones; Subject: Re: [COSE] A draft on CBOR Web Tokens (CWT) =C2=A0 You raise some= good points, and perhaps that is relevant to future claims. The spec as dr= afted, is a one-for-one copy of the standard JWT claims, which is why I rai= sed this point. =C2=A0 Is the goal a CBOR representation of a JWT? If so, = can it be defined in terms of a JWT?=C2=A0 Would the CNF claim then inherit= that representation (treating the JWE and JWK as their CBOR equivalents)? = =C2=A0 Perhaps if you go the separate registry route, those claims that *a= re* defined the same should at least normatively reference JWT?=C2=A0 I wan= t to avoid the whole "on behalf of" / "act as" fiasco where things can get = re-defined, and muddled. =C2=A0 On Mon, Nov 16, 2015 at 7:09 AM, Hannes Ts= chofenig wrote: Hi William, =C2=A0 I have been = trying to do a document update to see how well a combined registry works an= d I have been wondering whether it is really worth the effort. To make a g= ood judgment I looked at the CNF claim defined in draft-ietf-oauth-proof-of= -possession. The CNF claim may contain sub-elements, such as a JWE or a JWK= . =C2=A0 If we translate the same mechanisms to the CWT (which makes sense)= then we need to point to the respective COSE structures instead. Those do = not only use a different encoding but also the functionality does not match= the JOSE structures 100%. So, there are potentially differences. I am also= not sure whether we really want to translate the full functionality of all= the claims from JWT over to the CWT equivalent. It basically puts the burd= en on someone defining new claims (either in JWT or in CWT) to create the c= orresponding structures in a format they may not necessarily be familiar wi= th or even care about. I have seen that happening in the RADIUS world proto= col designers had to also define the equivalent structures for use with Dia= meter and, guess what, most of the definitions were wrong (since the author= s did not care about Diameter when working on RADIUS). =C2=A0 Ciao Hannes =C2=A0 =C2=A0 From: William Denniss [mailto:wdenniss@google.com] Sent: 12 November 2015 19:19 To: Erik Wahlstr=C3=B6m neXus Cc: Carsten Bormann; Hannes Tschofenig; Mike Jones; cose@ietf.org; ;ace@ietf.org Subject: Re: [COSE] A draft on CBOR Web Tokens (CWT) =C2=A0 Regarding the d= raft itself, a few comments: =C2=A0 1.=C2=A0 Can we unify the claim registr= y with JWT? I'm worried about having the same claims defined twice in CWT a= nd JWT with possibly conflicting meanings (and needless confusion even when= they do match).=C2=A0 =C2=A0 Comparing=C2=A0https://tools.ietf.org/html/dr= aft-wahlstroem-oauth-cbor-web-token-00#section-3.1.2 and=C2=A0https://tools= .ietf.org/html/rfc7519#section-4.1.2 which are nearly identical, I just don= 't see the value in re-defining it. =C2=A0 We may add new standard claims t= o JWT in the future (I=C2=A0proposed one=C2=A0in Yokohama on the=C2=A0id-ev= ent list), it would be good if this didn't need a separate entry in CWT too= , but could just apply directly (separately, I think you should consider th= is claim, as it helps prevent tokens from being re-used in the wrong contex= t). =C2=A0 2. Is Section 4 "Summary of CBOR major types used by defined cla= ims" normative (https://tools.ietf.org/html/draft-wahlstroem-oauth-cbor-web= -token-00#section-4)? What is the intention of this section? I feel like it= could probably be fleshed out a bit. =C2=A0 3.=C2=A0 Add a xref to draft C= OSE spec in=C2=A0section 6 Add xref to RFC7519 =C2=A0 On Thu, Nov 12, 2015 = at 12:01 PM, Erik Wahlstr=C3=B6m neXus wrot= e: Hi Carsten, Thanks, and I agree. I=E2=80=99ve heard arguments for all three work groups= . Borrowed some of your words to define the content of the draft :) It=E2=80=99s it essentially a JWT, phrased in and profiled for CBOR to addr= ess ACE needs, where OAuth needs COSE functionality, for object security. I=E2=80=99m open for letting the AD=E2=80=99s move it around, but having it= right next to JWT seems right to me. Also open for the ACE WG. Feel it has= less place in COSE for the same reasons JWT is not in the JOSE WG. / Erik=20 > On 12 Nov 2015, at 20:45, Carsten Bormann wrote: > > Hi Erik, > > having this draft is a good thing. > > One thing I'm still wondering is what WG is the best place to progress > this.=C2=A0 We probably don't need to spend too much time on this because= , > regardless of the WG chosen, the people in another WG can look at it. > Still, getting this right might provide some efficiencies. > > What is the technical content of this draft?=C2=A0 Is it a new token that > OAuth needs specifically for the new COSE-based applications of OAuth? > Is it a new token that is specifically there for addressing ACE needs? > Or is it essentially the same substance as JWT, but phrased in and > profiled for CBOR? > > Depending on the answer, CWT should be done in OAuth, ACE, or COSE. > (I'd rather hear the answer from the authors than venture a guess myself.= ) > > Gr=C3=BC=C3=9Fe, Carsten > > > > Erik Wahlstr=C3=B6m neXus wrote: >> Hi, >> >> In the ACE WG a straw man proposal of a CBOR Web Token (CWT) was defined >> in the draft "Authorization for the Internet of Things using OAuth 2.0= =E2=80=9D >> [1]. We just broke out the CBOR Web Token into a separate draft and the >> new draft is submitted to the OAUTH WG. It can be found here: >> >> https://datatracker.ietf.org/doc/draft-wahlstroem-oauth-cbor-web-token/ >> >> Abstract: >> "CBOR Web Token (CWT) is a compact means of representing claims to be >> transferred between two parties.=C2=A0 CWT is a profile of the JSON Web = Token >> (JWT) that is optimized for constrained devices. The claims in a CWT are >> encoded in the Concise Binary Object Representation (CBOR) and CBOR >> Object Signing and Encryption (COSE) is used for added application layer >> security protection.=C2=A0 A claim is a piece of information asserted ab= out a >> subject and is represented as a name/value pair consisting of a claim >> name and a claim value." >> >> / Erik >> >> >> [1] https://tools.ietf.org/html/draft-seitz-ace-oauth-authz-00 >> >> >> _______________________________________________ >> COSE mailing list >> COSE@ietf.org >> https://www.ietf.org/mailman/listinfo/cose _______________________________________________ COSE mailing list COSE@ietf.org https://www.ietf.org/mailman/listinfo/cose =C2=A0 =C2=A0=20 -- IMPORTANT NOTICE: The contents of this email and any attachments are con= fidential and may also be privileged. If you are not the intended recipient= , please notify the sender immediately and do not disclose the contents to = any other person, use it for any purpose, or store or copy the information = in any medium. Thank you. =C2=A0=20 -- IMPORTANT NOTICE: The contents of this email and any attachments are con= fidential and may also be privileged. If you are not the intended recipient= , please notify the sender immediately and do not disclose the contents to = any other person, use it for any purpose, or store or copy the information = in any medium. Thank you. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ------=_Part_6425772_1609887347.1447782730062 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
As th= is generalization change could be seen as substantial, I would like to have t= he chairs and AD comment. Is this a good idea?  Or is COSE better to wr= ite their own parallel arch draft?

<= /div>
I'm happy to bend to the will of the gro= up(s) on this. 

Phil
=
On Nov 19, 2015, at 01:17, Erik Wahlstr=C3=B6m neXus <erik.wahlstrom@nexusgroup.com> wrot= e:

Hi, 

I have been reviewing draft-ietf-oauth-pop-architecture= -05. In ACE WG we have a draft that uses PoP tokens for IoT and the architec= tures defined here so my review was done with that IoT perspective. I=E2=80=99= m a bit late with the review and some of the comments might already be mentioned by others.

 

=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94
=

3.1. Preventing Access Token Re-Use by the Resource Server

If a symmetric key is used it=E2=80=99s possible to re-use t= he key for a resource server. The section talks about the importance of scop= es, but I feel it should also mention the importance for the resource server= to verify the audience (=E2=80=9Caud=E2=80=9D) claim in the token to disable missuse.

=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94
=

The draft in ACE WG (https://tools.ietf.org/html/draft= -seitz-ace-oauth-authz-00) relies heavily on this work. The main reason f= or this is the way PoP tokens can establish key material, with the help of the authorization server, on both t= he client and resource server. PoP tokens is also a very good fit for constr= ained IoT devices that can be offline and it=E2=80=99s also possible to use h= ardware key storages to handle asymmetric pop keys.

There could be a place for a new "Use Case" under section 3 t= hat talks about scenarios where PoP keys are a really good match for offline= IoT devices. I could help out ironing out a text for that with the help of t= he docs authors if that=E2=80=99s of interest. 

=E2=80=94=E2=80=94=E2=80=94

s/a bogus tokens/a bogus token

=E2=80=94=E2=80=94

In the document only references are made to JSON, JWT and JO= SE. More exactly in the following two sections:

   A number of the thr=
eats listed in Section 4 demand protection of the
   access token content and a standardized solution, in form of a JSON-
   based format, is available with the JWT [RFC751=
9].



   With the JSON Web T=
oken (JWT) [RFC7519] a standardized format for=

   access tokens is available.  The necessary elements to bind symmetric
   or asymmetric keys to a JWT are described in
   [I-D.ietf-oauth-proof-=
of-possession].

Constrained IoT devices uses other access token and messages= formats (according to our draft). It does not only use signed/encrypted JWT= =E2=80=99s but also COSE protected CBOR Web Tokens. See https://tools.ietf.org/id/draft-wahlstroem-oauth-cbor-web-token-00.txt

I totally agree that JWT is the correct examples to have in t= his document due to the fact that they are RFC=E2=80=99s, they are well know= n and should be used in as many places as possible, but it would be good to o= pen up for other types of message formats. For example like this:


   A number of the thr=
eats listed in Section 4 demand protection of the
   access token content and a standardized solution in form of, for example, a JSON-
   based format, is available with the JWT [RFC751=
9].


=E2=80=94=E2=80=94

 For that
   purpose the client will have to authenticate the resource server
   before transmitting the access token.


I=E2=80=99m missing a description about how this is handled i= n an end-to-end security scenario.

=E2=80=94=E2=80=94=E2=80=94

      The resource ser=
ver queries the authorization server for the
      symmetric key.  This is an approach envisioned by the token
      introspection endpoint [I=
-D.ietf-oauth-introspection].


Not a question for this draft maybe, but in what draft is th= e introspection response claim defined? It=E2=80=99s not defined in https://t= ools.ietf.org/html/rfc7662#section-2.2 and I don=E2=80=99t know in what other draft it can be defined.

=E2=80=94=E2=80=94

In ACE WG the draft seitz-ace-oauth-authz have a profile for= an access request to make it work over CoAP. CoAP is the HTTP equivalent fo= r constrained devices, and it has limitations, for example it can=E2=80=99t s= end large tokens in options (headers in "http-speak"). This means that the draft defines a way to first send the Po= P token to an new endpoint on the resource server to establish a security co= ntext. Then the real request against the resource server can be done once th= e security context is established. See more details here https://tools.ietf.org/html/dr= aft-seitz-ace-oauth-authz-00#section-5.2.

An open question; should a flow like that be added to the ar= chitecture section? That means a new section 7.5.

=E2=80=94=E2=80=94

Thanks for writing this. I think it=E2=80=99s very important= work.

/ Erik


____________________= ___________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mai= lman/listinfo/oauth
= --Apple-Mail-0F232C7C-E2DC-4111-8B15-970279335DC8-- From nobody Thu Nov 19 08:39:45 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 528571B2C4E for ; Thu, 19 Nov 2015 08:39:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.884 X-Spam-Level: X-Spam-Status: No, score=-2.884 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.585] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3AHiGtXgSj-Y for ; Thu, 19 Nov 2015 08:39:40 -0800 (PST) Received: from smtp.nexusgroup.com (smtp.nexusgroup.com [83.241.133.121]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 130491B2C3D for ; Thu, 19 Nov 2015 08:39:40 -0800 (PST) Received: from NG-EX01.ad.nexusgroup.com (10.75.28.40) by NG-EX02.ad.nexusgroup.com (10.75.28.43) with Microsoft SMTP Server (TLS) id 15.0.995.29; Thu, 19 Nov 2015 17:39:37 +0100 Received: from NG-EX01.ad.nexusgroup.com ([fe80::1d3d:b319:f020:2bab]) by NG-EX01.ad.nexusgroup.com ([fe80::1d3d:b319:f020:2bab%12]) with mapi id 15.00.0995.032; Thu, 19 Nov 2015 17:39:38 +0100 From: =?Windows-1252?Q?Erik_Wahlstr=F6m_neXus?= To: Phil Hunt Thread-Topic: [OAUTH-WG] A review of draft-ietf-oauth-pop-architecture-05 Thread-Index: AQHRIqsWCr6RmlnVq02omaMFbp3lkZ6jdZCAgAAW25Q= Date: Thu, 19 Nov 2015 16:39:37 +0000 Message-ID: References: <4197256B-0C12-46AA-B2F2-C9849F44BB3A@nexusgroup.com>, <89483136-58E9-49C6-AE8B-E2A58E14F3B3@oracle.com> In-Reply-To: <89483136-58E9-49C6-AE8B-E2A58E14F3B3@oracle.com> Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_BE468D61B1164EB58ECBED3A21D846FBnexusgroupcom_" MIME-Version: 1.0 Archived-At: Cc: "" Subject: Re: [OAUTH-WG] A review of draft-ietf-oauth-pop-architecture-05 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2015 16:39:44 -0000 --_000_BE468D61B1164EB58ECBED3A21D846FBnexusgroupcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Just a note then. I did not see anything that prohibited the usage of pop t= okens for IoT so shipping it as is works. Sent from my iPhone On 19 Nov 2015, at 17:18, Phil Hunt > wrote: On the subject of making the spec(s) less JWT specific, it was a foundation= al assumption and (I think) in the charter. However COSE wasn't around yet. I suppose the more generic architecture doc could be altered to cover IoT c= ases, but it may be problematic for the other specs that are more specific. Another issue is I assume the COSE based tokens will have a different type = (eg cpop) to differentiate between jwt and COSE web tokens (what are we cal= ling them now?). As this generalization change could be seen as substantial, I would like to= have the chairs and AD comment. Is this a good idea? Or is COSE better to= write their own parallel arch draft? I'm happy to bend to the will of the group(s) on this. Phil On Nov 19, 2015, at 01:17, Erik Wahlstr=F6m neXus > wrote: Hi, I have been reviewing draft-ietf-oauth-pop-architecture-05. In ACE WG we ha= ve a draft that uses PoP tokens for IoT and the architectures defined here = so my review was done with that IoT perspective. I=92m a bit late with the = review and some of the comments might already be mentioned by others. =97=97=97=97=97=97 3.1. Preventing Access Token Re-Use by the Resource Server If a symmetric key is used it=92s possible to re-use the key for a resource= server. The section talks about the importance of scopes, but I feel it sh= ould also mention the importance for the resource server to verify the audi= ence (=93aud=94) claim in the token to disable missuse. =97=97=97=97=97=97 The draft in ACE WG (https://tools.ietf.org/html/draft-seitz-ace-oauth-auth= z-00) relies heavily on this work. The main reason for this is the way PoP = tokens can establish key material, with the help of the authorization serve= r, on both the client and resource server. PoP tokens is also a very good f= it for constrained IoT devices that can be offline and it=92s also possible= to use hardware key storages to handle asymmetric pop keys. There could be a place for a new "Use Case" under section 3 that talks abou= t scenarios where PoP keys are a really good match for offline IoT devices.= I could help out ironing out a text for that with the help of the docs aut= hors if that=92s of interest. =97=97=97 s/a bogus tokens/a bogus token =97=97 In the document only references are made to JSON, JWT and JOSE. More exactl= y in the following two sections: A number of the threats listed in Section 4 demand protection of the access token content and a standardized solution, in form of a JSON- based format, is available with the JWT [RFC7519]. With the JSON Web Token (JWT) [RFC7519] a standardized format for access tokens is available. The necessary elements to bind symmetric or asymmetric keys to a JWT are described in [I-D.ietf-oauth-proof-of-possession]. Constrained IoT devices uses other access token and messages formats (accor= ding to our draft). It does not only use signed/encrypted JWT=92s but also = COSE protected CBOR Web Tokens. See https://tools.ietf.org/id/draft-wahlstr= oem-oauth-cbor-web-token-00.txt I totally agree that JWT is the correct examples to have in this document d= ue to the fact that they are RFC=92s, they are well known and should be use= d in as many places as possible, but it would be good to open up for other = types of message formats. For example like this: A number of the threats listed in Section 4 demand protection of the access token content and a standardized solution in form of, for example= , a JSON- based format, is available with the JWT [RFC7519]. =97=97 For that purpose the client will have to authenticate the resource server before transmitting the access token. I=92m missing a description about how this is handled in an end-to-end secu= rity scenario. =97=97=97 The resource server queries the authorization server for the symmetric key. This is an approach envisioned by the token introspection endpoint [I-D.ietf-oauth-introspection]. Not a question for this draft maybe, but in what draft is the introspection= response claim defined? It=92s not defined in https://tools.ietf.org/html/= rfc7662#section-2.2 and I don=92t know in what other draft it can be define= d. =97=97 In ACE WG the draft seitz-ace-oauth-authz have a profile for an access requ= est to make it work over CoAP. CoAP is the HTTP equivalent for constrained = devices, and it has limitations, for example it can=92t send large tokens i= n options (headers in "http-speak"). This means that the draft defines a wa= y to first send the PoP token to an new endpoint on the resource server to = establish a security context. Then the real request against the resource se= rver can be done once the security context is established. See more details= here https://tools.ietf.org/html/draft-seitz-ace-oauth-authz-00#section-5.= 2. An open question; should a flow like that be added to the architecture sect= ion? That means a new section 7.5. =97=97 Thanks for writing this. I think it=92s very important work. / Erik _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_BE468D61B1164EB58ECBED3A21D846FBnexusgroupcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Just a note then. I did not see anything that prohibited the usage of = pop tokens for IoT so  shipping it as is works.

Sent from my iPhone

On 19 Nov 2015, at 17:18, Phil Hunt <phil.hunt@oracle.com> wrote:

On the subject of making the spec(s) less JWT specific, it was a found= ational assumption and (I think) in the charter. However COSE wasn't around= yet. 

I suppose the more generic architecture doc = could be altered to cover IoT cases, but it may be problematic for the othe= r specs that are more specific. 

Another issue is I assume the COSE based tok= ens will have a different type (eg cpop) to differentiate between jwt and C= OSE web tokens (what are we calling them now?). 

As this generalization change could be seen = as substantial, I would like to have the chairs and AD comment. Is this a g= ood idea?  Or is COSE better to write their own parallel arch draft?

I'm happy to bend to the will of the group(s= ) on this. 

Phil

On Nov 19, 2015, at 01:17, Erik Wahlstr=F6m neXus <erik.wahlstrom@nexusgroup.com> wrote:
Hi, 

I have been reviewing draft-ietf-oauth-pop-architectur= e-05. In ACE WG we have a draft that uses PoP tokens for IoT and the archit= ectures defined here so my review was done with that IoT perspective. I=92m= a bit late with the review and some of the comments might already be mentioned by others.

 

=97=97=97=97=97=97

3.1. Preventing Access Token Re-Use by the Resource Server

If a symmetric key is used it=92s possible to re-use the ke= y for a resource server. The section talks about the importance of scopes, = but I feel it should also mention the importance for the resource server to= verify the audience (=93aud=94) claim in the token to disable missuse.

=97=97=97=97=97=97

The draft in ACE WG (https://tools.ietf.org/html/dra= ft-seitz-ace-oauth-authz-00) relies heavily on this work. The main reas= on for this is the way PoP tokens can establish key material, with the help of the authorization server, on both= the client and resource server. PoP tokens is also a very good fit for con= strained IoT devices that can be offline and it=92s also possible to use ha= rdware key storages to handle asymmetric pop keys.

There could be a place for a new "Use Case" under= section 3 that talks about scenarios where PoP keys are a really good matc= h for offline IoT devices. I could help out ironing out a text for that wit= h the help of the docs authors if that=92s of interest. 

=97=97=97

s/a bogus tokens/a bogus token

=97=97

In the document only references are made to JSON, JWT and J= OSE. More exactly in the following two sections:

   A number of the t=
hreats listed in Section 4 demand protection of =
the
   access token content and a standardized solution, in form of a JSON-
   based format, is available with the JWT [RFC7=
519].



   With the JSON Web=
 Token (JWT) [RFC7519] a standardized format=
 for
   access tokens is available.  The necessary elements to bind symmetric
   or asymmetric keys to a JWT are described in
   [I-D.ietf-oauth-proo=
f-of-possession].

Constrained IoT devices uses other access token and message= s formats (according to our draft). It does not only use signed/encrypted J= WT=92s but also COSE protected CBOR Web Tokens. See https://tools.ietf.org/id/draft-wahlstroem-oauth-cbor-web-token-00.txt=

I totally agree that JWT is the correct examples to have in= this document due to the fact that they are RFC=92s, they are well known a= nd should be used in as many places as possible, but it would be good to op= en up for other types of message formats. For example like this:


   A number of the t=
hreats listed in Section 4 demand protection of =
the
   access token content and a standardized solution in form of, for example, a JSON-
   based format, is available with the JWT [RFC7=
519].


=97=97

 For that
   purpose the client will have to authenticate the resource server
   before transmitting the access token.


I=92m missing a description about how this is handled in an= end-to-end security scenario.

=97=97=97

      The resource s=
erver queries the authorization server for the
      symmetric key.  This is an approach envisioned by the token
      introspection endpoint [I-D.ietf-oauth-introspection].


Not a question for this draft maybe, but in what draft is t= he introspection response claim defined? It=92s not defined in https://too= ls.ietf.org/html/rfc7662#section-2.2 and I don=92t know in what other draft it can be defined.

=97=97

In ACE WG the draft seitz-ace-oauth-authz have a profile fo= r an access request to make it work over CoAP. CoAP is the HTTP equivalent = for constrained devices, and it has limitations, for example it can=92t sen= d large tokens in options (headers in "http-speak"). This means that the draft defines a way to first = send the PoP token to an new endpoint on the resource server to establish a= security context. Then the real request against the resource server can be= done once the security context is established. See more details here https://tools.ietf.org/html/= draft-seitz-ace-oauth-authz-00#section-5.2.

An open question; should a flow like that be added to the a= rchitecture section? That means a new section 7.5.

=97=97

Thanks for writing this. I think it=92s very important work= .

/ Erik


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.i= etf.org/mailman/listinfo/oauth
--_000_BE468D61B1164EB58ECBED3A21D846FBnexusgroupcom_-- From nobody Thu Nov 19 09:28:58 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6EF51B2CFA for ; Thu, 19 Nov 2015 09:28:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.484 X-Spam-Level: X-Spam-Status: No, score=-4.484 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VgrQSxfNQQhX for ; Thu, 19 Nov 2015 09:28:45 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C227C1B2E19 for ; Thu, 19 Nov 2015 09:28:44 -0800 (PST) Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id tAJHSZqY008220 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 19 Nov 2015 17:28:36 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0022.oracle.com (8.13.8/8.13.8) with ESMTP id tAJHSYSO021979 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 19 Nov 2015 17:28:34 GMT Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id tAJHSVmE009336; Thu, 19 Nov 2015 17:28:31 GMT Received: from [192.168.1.27] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 19 Nov 2015 09:28:30 -0800 Content-Type: multipart/alternative; boundary=Apple-Mail-97C73E99-2EE0-45AE-A556-C6D22F206D0C Mime-Version: 1.0 (1.0) From: Phil Hunt X-Mailer: iPhone Mail (13B143) In-Reply-To: Date: Thu, 19 Nov 2015 09:28:28 -0800 Content-Transfer-Encoding: 7bit Message-Id: <32AE79F6-DC20-4556-85A6-0C7E7B20E30F@oracle.com> References: <4197256B-0C12-46AA-B2F2-C9849F44BB3A@nexusgroup.com> <89483136-58E9-49C6-AE8B-E2A58E14F3B3@oracle.com> To: =?utf-8?Q?Erik_Wahlstr=C3=B6m_neXus?= X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Cc: "" , Justin Richer Subject: Re: [OAUTH-WG] A review of draft-ietf-oauth-pop-architecture-05 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2015 17:28:50 -0000 --Apple-Mail-97C73E99-2EE0-45AE-A556-C6D22F206D0C Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I think your point that maybe the architecture doc be generic enough to supp= ort both json and cbor tokens is worth consideration.=20 I am just not sure of process and consensus now that we are past WGLC. Would= the cose group prefer this? Happy to do it if desired. Also understand if we are too far down the road.=20= Phil > On Nov 19, 2015, at 08:39, Erik Wahlstr=C3=B6m neXus wrote: >=20 > Just a note then. I did not see anything that prohibited the usage of pop t= okens for IoT so shipping it as is works. >=20 > Sent from my iPhone >=20 > On 19 Nov 2015, at 17:18, Phil Hunt wrote: >=20 >> On the subject of making the spec(s) less JWT specific, it was a foundati= onal assumption and (I think) in the charter. However COSE wasn't around yet= .=20 >>=20 >> I suppose the more generic architecture doc could be altered to cover IoT= cases, but it may be problematic for the other specs that are more specific= .=20 >>=20 >> Another issue is I assume the COSE based tokens will have a different typ= e (eg cpop) to differentiate between jwt and COSE web tokens (what are we ca= lling them now?).=20 >>=20 >> As this generalization change could be seen as substantial, I would like t= o have the chairs and AD comment. Is this a good idea? Or is COSE better to= write their own parallel arch draft? >>=20 >> I'm happy to bend to the will of the group(s) on this.=20 >>=20 >> Phil >>=20 >> On Nov 19, 2015, at 01:17, Erik Wahlstr=C3=B6m neXus wrote: >>=20 >>> Hi,=20 >>>=20 >>> I have been reviewing draft-ietf-oauth-pop-architecture-05. In ACE WG we= have a draft that uses PoP tokens for IoT and the architectures defined her= e so my review was done with that IoT perspective. I=E2=80=99m a bit late wi= th the review and some of the comments might already be mentioned by others.= >>>=20 >>> =20 >>>=20 >>> =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 >>>=20 >>> 3.1. Preventing Access Token Re-Use by the Resource Server=20 >>>=20 >>> If a symmetric key is used it=E2=80=99s possible to re-use the key for a= resource server. The section talks about the importance of scopes, but I fe= el it should also mention the importance for the resource server to verify t= he audience (=E2=80=9Caud=E2=80=9D) claim in the token to disable missuse. >>>=20 >>> =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 >>>=20 >>> The draft in ACE WG (https://tools.ietf.org/html/draft-seitz-ace-oauth-a= uthz-00) relies heavily on this work. The main reason for this is the way Po= P tokens can establish key material, with the help of the authorization serv= er, on both the client and resource server. PoP tokens is also a very good f= it for constrained IoT devices that can be offline and it=E2=80=99s also pos= sible to use hardware key storages to handle asymmetric pop keys. >>>=20 >>> There could be a place for a new "Use Case" under section 3 that talks a= bout scenarios where PoP keys are a really good match for offline IoT device= s. I could help out ironing out a text for that with the help of the docs au= thors if that=E2=80=99s of interest.=20 >>>=20 >>> =E2=80=94=E2=80=94=E2=80=94 >>>=20 >>> s/a bogus tokens/a bogus token >>>=20 >>> =E2=80=94=E2=80=94 >>>=20 >>> In the document only references are made to JSON, JWT and JOSE. More exa= ctly in the following two sections: >>>=20 >>> A number of the threats listed in Section 4 demand protection of the >>> access token content and a standardized solution, in form of a JSON- >>> based format, is available with the JWT [RFC7519]. >>>=20 >>>=20 >>> With the JSON Web Token (JWT) [RFC7519] a standardized format for >>> access tokens is available. The necessary elements to bind symmetric= >>> or asymmetric keys to a JWT are described in >>> [I-D.ietf-oauth-proof-of-possession]. >>>=20 >>> Constrained IoT devices uses other access token and messages formats (ac= cording to our draft). It does not only use signed/encrypted JWT=E2=80=99s b= ut also COSE protected CBOR Web Tokens. See https://tools.ietf.org/id/draft-= wahlstroem-oauth-cbor-web-token-00.txt >>>=20 >>> I totally agree that JWT is the correct examples to have in this documen= t due to the fact that they are RFC=E2=80=99s, they are well known and shoul= d be used in as many places as possible, but it would be good to open up for= other types of message formats. For example like this: >>>=20 >>>=20 >>> A number of the threats listed in Section 4 demand protection of the >>> access token content and a standardized solution in form of, for exam= ple, a JSON- >>> based format, is available with the JWT [RFC7519]. >>>=20 >>>=20 >>> =E2=80=94=E2=80=94 >>>=20 >>> For that >>> purpose the client will have to authenticate the resource server >>> before transmitting the access token. >>>=20 >>>=20 >>> I=E2=80=99m missing a description about how this is handled in an end-to= -end security scenario. >>>=20 >>> =E2=80=94=E2=80=94=E2=80=94 >>>=20 >>> The resource server queries the authorization server for the >>> symmetric key. This is an approach envisioned by the token >>> introspection endpoint [I-D.ietf-oauth-introspection]. >>>=20 >>>=20 >>> Not a question for this draft maybe, but in what draft is the introspect= ion response claim defined? It=E2=80=99s not defined in https://tools.ietf.o= rg/html/rfc7662#section-2.2 and I don=E2=80=99t know in what other draft it c= an be defined. >>>=20 >>> =E2=80=94=E2=80=94 >>>=20 >>> In ACE WG the draft seitz-ace-oauth-authz have a profile for an access r= equest to make it work over CoAP. CoAP is the HTTP equivalent for constraine= d devices, and it has limitations, for example it can=E2=80=99t send large t= okens in options (headers in "http-speak"). This means that the draft define= s a way to first send the PoP token to an new endpoint on the resource serve= r to establish a security context. Then the real request against the resourc= e server can be done once the security context is established. See more deta= ils here https://tools.ietf.org/html/draft-seitz-ace-oauth-authz-00#section-= 5.2. >>>=20 >>> An open question; should a flow like that be added to the architecture s= ection? That means a new section 7.5. >>>=20 >>> =E2=80=94=E2=80=94 >>>=20 >>> Thanks for writing this. I think it=E2=80=99s very important work. >>>=20 >>> / Erik >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-97C73E99-2EE0-45AE-A556-C6D22F206D0C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I think your point that maybe the arch= itecture doc be generic enough to support both json and cbor tokens is worth= consideration. 

I am just not sure of process and consensus now that we= are past WGLC. Would the cose group prefer this?

Happy to do it if desired= . Also understand if we are too far down the road. 

Phil

On Nov 19, 2015, at 08:39, Erik Wahlstr=C3=B6m neXus <erik.wahlstrom@nexusgroup.com> w= rote:

Just a note then. I did not see anything that prohibited the usage of p= op tokens for IoT so  shipping it as is works.

Sent from my iPhone

On 19 Nov 2015, at 17:18, Phil Hunt <phil.hunt@oracle.com> wrote:

On the subject of making the spec(s) less JWT specific, it was a founda= tional assumption and (I think) in the charter. However COSE wasn't around y= et. 

I suppose the more generic architecture doc c= ould be altered to cover IoT cases, but it may be problematic for the other s= pecs that are more specific. 

Another issue is I assume the COSE based toke= ns will have a different type (eg cpop) to differentiate between jwt and COS= E web tokens (what are we calling them now?). 

As this generalization change could be seen a= s substantial, I would like to have the chairs and AD comment. Is this a goo= d idea?  Or is COSE better to write their own parallel arch draft?

I'm happy to bend to the will of the group(s)= on this. 

Phil

On Nov 19, 2015, at 01:17, Erik Wahlstr=C3=B6m neXus <erik.wahlstrom@nexusgroup.com> wrote:
Hi, 

I have been reviewing draft-ietf-oauth-pop-architecture= -05. In ACE WG we have a draft that uses PoP tokens for IoT and the architec= tures defined here so my review was done with that IoT perspective. I=E2=80=99= m a bit late with the review and some of the comments might already be mentioned by others.

 

=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94
=

3.1. Preventing Access Token Re-Use by the Resource Server

If a symmetric key is used it=E2=80=99s possible to re-use t= he key for a resource server. The section talks about the importance of scop= es, but I feel it should also mention the importance for the resource server= to verify the audience (=E2=80=9Caud=E2=80=9D) claim in the token to disable missuse.

=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94
=

The draft in ACE WG (https://tools.ietf.org/html/draft= -seitz-ace-oauth-authz-00) relies heavily on this work. The main reason f= or this is the way PoP tokens can establish key material, with the help of the authorization server, on both t= he client and resource server. PoP tokens is also a very good fit for constr= ained IoT devices that can be offline and it=E2=80=99s also possible to use h= ardware key storages to handle asymmetric pop keys.

There could be a place for a new "Use Case" under section 3 t= hat talks about scenarios where PoP keys are a really good match for offline= IoT devices. I could help out ironing out a text for that with the help of t= he docs authors if that=E2=80=99s of interest. 

=E2=80=94=E2=80=94=E2=80=94

s/a bogus tokens/a bogus token

=E2=80=94=E2=80=94

In the document only references are made to JSON, JWT and JO= SE. More exactly in the following two sections:

   A number of the thr=
eats listed in Section 4 demand protection of the
   access token content and a standardized solution, in form of a JSON-
   based format, is available with the JWT [RFC751=
9].



   With the JSON Web T=
oken (JWT) [RFC7519] a standardized format for=

   access tokens is available.  The necessary elements to bind symmetric
   or asymmetric keys to a JWT are described in
   [I-D.ietf-oauth-proof-=
of-possession].

Constrained IoT devices uses other access token and messages= formats (according to our draft). It does not only use signed/encrypted JWT= =E2=80=99s but also COSE protected CBOR Web Tokens. See https://tools.ietf.org/id/draft-wahlstroem-oauth-cbor-web-token-00.txt

I totally agree that JWT is the correct examples to have in t= his document due to the fact that they are RFC=E2=80=99s, they are well know= n and should be used in as many places as possible, but it would be good to o= pen up for other types of message formats. For example like this:


   A number of the thr=
eats listed in Section 4 demand protection of the
   access token content and a standardized solution in form of, for example, a JSON-
   based format, is available with the JWT [RFC751=
9].


=E2=80=94=E2=80=94

 For that
   purpose the client will have to authenticate the resource server
   before transmitting the access token.


I=E2=80=99m missing a description about how this is handled i= n an end-to-end security scenario.

=E2=80=94=E2=80=94=E2=80=94

      The resource ser=
ver queries the authorization server for the
      symmetric key.  This is an approach envisioned by the token
      introspection endpoint [I=
-D.ietf-oauth-introspection].


Not a question for this draft maybe, but in what draft is th= e introspection response claim defined? It=E2=80=99s not defined in https://t= ools.ietf.org/html/rfc7662#section-2.2 and I don=E2=80=99t know in what other draft it can be defined.

=E2=80=94=E2=80=94

In ACE WG the draft seitz-ace-oauth-authz have a profile for= an access request to make it work over CoAP. CoAP is the HTTP equivalent fo= r constrained devices, and it has limitations, for example it can=E2=80=99t s= end large tokens in options (headers in "http-speak"). This means that the draft defines a way to first send the Po= P token to an new endpoint on the resource server to establish a security co= ntext. Then the real request against the resource server can be done once th= e security context is established. See more details here https://tools.ietf.org/html/dr= aft-seitz-ace-oauth-authz-00#section-5.2.

An open question; should a flow like that be added to the ar= chitecture section? That means a new section 7.5.

=E2=80=94=E2=80=94

Thanks for writing this. I think it=E2=80=99s very important= work.

/ Erik


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ie= tf.org/mailman/listinfo/oauth
= --Apple-Mail-97C73E99-2EE0-45AE-A556-C6D22F206D0C-- From nobody Thu Nov 19 10:18:53 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1291A1B33E1 for ; Thu, 19 Nov 2015 10:18:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.485 X-Spam-Level: X-Spam-Status: No, score=-4.485 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8BswNBFGNmMI for ; Thu, 19 Nov 2015 10:18:48 -0800 (PST) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D9DB1B33E0 for ; Thu, 19 Nov 2015 10:18:47 -0800 (PST) X-AuditID: 1209190d-f79306d000006b70-2b-564e12866051 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 32.FF.27504.6821E465; Thu, 19 Nov 2015 13:18:46 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id tAJIIjV4018293; Thu, 19 Nov 2015 13:18:45 -0500 Received: from [IPv6:2607:fb90:2308:dab:0:4b:4084:d301] ([172.56.21.241]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id tAJIIfs5016106 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 19 Nov 2015 13:18:43 -0500 Date: Thu, 19 Nov 2015 12:18:41 -0600 Message-ID: Importance: normal From: Justin Richer To: Phil Hunt , =?ISO-8859-1?Q?Erik_Wahlstr=F6m_neXus?= MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.android.email_2441371127924970" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrIKsWRmVeSWpSXmKPExsUixG6notsm5Bdm8LxDyeLYrsVsFrteN7FY nHz7is1iwfxGdgcWjyVLfjJ5TJr2gcVj6/3fjB4fn95iCWCJ4rJJSc3JLEst0rdL4Mo4c2Ub a8GFA4wVc28sYW5gPLCbsYuRk0NCwERi6pU9ULaYxIV769m6GLk4hAQWM0msX/+HFcLZyChx 8sohFgjnGJPE39YP7CAtLAKqEs9eXmADsYUFPCT+rJsJNopXwE2irfMbkM3BwSkgJNG1SwIk zAZUPn1NCxOILSJQJtE3dQ5YObNAlMS6IxOZIVoFJU7OfMICEQ+VONz/lnECI98sJKlZSFIQ trrEn3mXmCFsRYkp3Q/ZZwFtZhZQk1jWqoQsvICRbRWjbEpulW5uYmZOcWqybnFyYl5eapGu kV5uZoleakrpJkZQqHNK8u5gfHdQ6RCjAAejEg8vx1mfMCHWxLLiytxDjJIcTEqivMKcfmFC fEn5KZUZicUZ8UWlOanFhxglOJiVRHidBYFyvCmJlVWpRfkwKWkOFiVx3rlffMOEBNITS1Kz U1MLUotgsjIcHEoSvEUgjYJFqempFWmZOSUIaSYOTpDhPEDDC8GGFxck5hZnpkPkTzGaSonz hoMkBEASGaV5cL1KQkICauy/Jyhz8K5mYGDwdmi5zAhKWWssRD++YhQHek+YNxSkkweY7uAm vgJaxgS07HeNL8iykkSElFQDo+Yx++MCVY+XHD5Tcu776QiJpJrHmuWXOafKRDl4pF2rOiXI 4tD0xCwzZcX8W0nCu552Ke/pu97MZx2qP6VJPaog4OU571dTD1Z8bZ31RyF4h9uCV6pd1jVW ShbvKlQbTC3cVwXs/LzFVpC3f/Jhw7lxE3bveXoyfPV8poZpJ7bqN4rPT9HtU2Ipzkg01GIu Kk4EAKDhtDY0AwAA Archived-At: Cc: "" , Justin Richer Subject: Re: [OAUTH-WG] A review of draft-ietf-oauth-pop-architecture-05 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2015 18:18:52 -0000 ----_com.android.email_2441371127924970 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 CiAgICAKSSBhZ3JlZSB3aXRoIGFkZGVkICJGb3IgZXhhbXBsZSIgaW4gYSBmZXcgcGxhY2VzLiBJ dCdzIG5vdCBub3JtYXRpdmUgaXQncyBpbmZvcm1hdGlvbmFsIGhlcmUuwqAKCgotLSBKdXN0aW4K LyBTZW50IGZyb20gbXkgcGhvbmUgLwoKLS0tLS0tLS0gT3JpZ2luYWwgbWVzc2FnZSAtLS0tLS0t LQpGcm9tOiBQaGlsIEh1bnQgPHBoaWwuaHVudEBvcmFjbGUuY29tPiAKRGF0ZTogMTEvMTkvMjAx NSAgMTE6MjggQU0gIChHTVQtMDY6MDApIApUbzogRXJpayBXYWhsc3Ryw7ZtIG5lWHVzIDxlcmlr LndhaGxzdHJvbUBuZXh1c2dyb3VwLmNvbT4gCkNjOiAiPG9hdXRoQGlldGYub3JnPiIgPG9hdXRo QGlldGYub3JnPiwgSnVzdGluIFJpY2hlciA8aWV0ZkBqdXN0aW4ucmljaGVyLm9yZz4gClN1Ympl Y3Q6IFJlOiBbT0FVVEgtV0ddIEEgcmV2aWV3IG9mIGRyYWZ0LWlldGYtb2F1dGgtcG9wLWFyY2hp dGVjdHVyZS0wNSAKCkkgdGhpbmsgeW91ciBwb2ludCB0aGF0IG1heWJlIHRoZSBhcmNoaXRlY3R1 cmUgZG9jIGJlIGdlbmVyaWMgZW5vdWdoIHRvIHN1cHBvcnQgYm90aCBqc29uIGFuZCBjYm9yIHRv a2VucyBpcyB3b3J0aCBjb25zaWRlcmF0aW9uLsKgCkkgYW0ganVzdCBub3Qgc3VyZSBvZiBwcm9j ZXNzIGFuZCBjb25zZW5zdXMgbm93IHRoYXQgd2UgYXJlIHBhc3QgV0dMQy4gV291bGQgdGhlIGNv c2UgZ3JvdXAgcHJlZmVyIHRoaXM/CkhhcHB5IHRvIGRvIGl0IGlmIGRlc2lyZWQuIEFsc28gdW5k ZXJzdGFuZCBpZiB3ZSBhcmUgdG9vIGZhciBkb3duIHRoZSByb2FkLsKgCgpQaGlsCk9uIE5vdiAx OSwgMjAxNSwgYXQgMDg6MzksIEVyaWsgV2FobHN0csO2bSBuZVh1cyA8ZXJpay53YWhsc3Ryb21A bmV4dXNncm91cC5jb20+IHdyb3RlOgoKCgoKCgpKdXN0IGEgbm90ZSB0aGVuLiBJIGRpZCBub3Qg c2VlIGFueXRoaW5nIHRoYXQgcHJvaGliaXRlZCB0aGUgdXNhZ2Ugb2YgcG9wIHRva2VucyBmb3Ig SW9UIHNvIMKgc2hpcHBpbmcgaXQgYXMgaXMgd29ya3MuCgoKClNlbnQgZnJvbSBteSBpUGhvbmUK CgpPbiAxOSBOb3YgMjAxNSwgYXQgMTc6MTgsIFBoaWwgSHVudCA8cGhpbC5odW50QG9yYWNsZS5j b20+IHdyb3RlOgoKCgoKCgpPbiB0aGUgc3ViamVjdCBvZiBtYWtpbmcgdGhlIHNwZWMocykgbGVz cyBKV1Qgc3BlY2lmaWMsIGl0IHdhcyBhIGZvdW5kYXRpb25hbCBhc3N1bXB0aW9uIGFuZCAoSSB0 aGluaykgaW4gdGhlIGNoYXJ0ZXIuIEhvd2V2ZXIgQ09TRSB3YXNuJ3QgYXJvdW5kIHlldC7CoAoK CgpJIHN1cHBvc2UgdGhlIG1vcmUgZ2VuZXJpYyBhcmNoaXRlY3R1cmUgZG9jIGNvdWxkIGJlIGFs dGVyZWQgdG8gY292ZXIgSW9UIGNhc2VzLCBidXQgaXQgbWF5IGJlIHByb2JsZW1hdGljIGZvciB0 aGUgb3RoZXIgc3BlY3MgdGhhdCBhcmUgbW9yZSBzcGVjaWZpYy7CoAoKCgpBbm90aGVyIGlzc3Vl IGlzIEkgYXNzdW1lIHRoZSBDT1NFIGJhc2VkIHRva2VucyB3aWxsIGhhdmUgYSBkaWZmZXJlbnQg dHlwZSAoZWcgY3BvcCkgdG8gZGlmZmVyZW50aWF0ZSBiZXR3ZWVuIGp3dCBhbmQgQ09TRSB3ZWIg dG9rZW5zICh3aGF0IGFyZSB3ZSBjYWxsaW5nIHRoZW0gbm93PykuwqAKCgoKQXMgdGhpcyBnZW5l cmFsaXphdGlvbiBjaGFuZ2UgY291bGQgYmUgc2VlbiBhcyBzdWJzdGFudGlhbCwgSSB3b3VsZCBs aWtlIHRvIGhhdmUgdGhlIGNoYWlycyBhbmQgQUQgY29tbWVudC4gSXMgdGhpcyBhIGdvb2QgaWRl YT8gwqBPciBpcyBDT1NFIGJldHRlciB0byB3cml0ZSB0aGVpciBvd24gcGFyYWxsZWwgYXJjaCBk cmFmdD8KCgoKSSdtIGhhcHB5IHRvIGJlbmQgdG8gdGhlIHdpbGwgb2YgdGhlIGdyb3VwKHMpIG9u IHRoaXMuwqAKCgpQaGlsCgoKT24gTm92IDE5LCAyMDE1LCBhdCAwMToxNywgRXJpayBXYWhsc3Ry w7ZtIG5lWHVzIDxlcmlrLndhaGxzdHJvbUBuZXh1c2dyb3VwLmNvbT4gd3JvdGU6CgoKCgoKCgpI aSzCoAoKCgpJIGhhdmUgYmVlbiByZXZpZXdpbmfCoGRyYWZ0LWlldGYtb2F1dGgtcG9wLWFyY2hp dGVjdHVyZS0wNS4gSW4gQUNFIFdHIHdlIGhhdmUgYSBkcmFmdCB0aGF0IHVzZXMgUG9QIHRva2Vu cyBmb3IgSW9UIGFuZCB0aGUgYXJjaGl0ZWN0dXJlcyBkZWZpbmVkIGhlcmUgc28gbXkgcmV2aWV3 IHdhcyBkb25lIHdpdGggdGhhdCBJb1QgcGVyc3BlY3RpdmUuIEnigJltIGEgYml0IGxhdGUgd2l0 aCB0aGUgcmV2aWV3IGFuZCBzb21lIG9mIHRoZQogY29tbWVudHMgbWlnaHQgYWxyZWFkeSBiZSBt ZW50aW9uZWQgYnkgb3RoZXJzLgoKCgrCoAoKCgrigJTigJTigJTigJTigJTigJQKCgoKCjMuMS4g UHJldmVudGluZyBBY2Nlc3MgVG9rZW4gUmUtVXNlIGJ5IHRoZSBSZXNvdXJjZSBTZXJ2ZXIKCgoK SWYgYSBzeW1tZXRyaWMga2V5IGlzIHVzZWQgaXTigJlzIHBvc3NpYmxlIHRvIHJlLXVzZSB0aGUg a2V5IGZvciBhIHJlc291cmNlIHNlcnZlci4gVGhlIHNlY3Rpb24gdGFsa3MgYWJvdXQgdGhlIGlt cG9ydGFuY2Ugb2Ygc2NvcGVzLCBidXQgSSBmZWVsIGl0IHNob3VsZCBhbHNvIG1lbnRpb24gdGhl IGltcG9ydGFuY2UgZm9yIHRoZSByZXNvdXJjZSBzZXJ2ZXIgdG8gdmVyaWZ5IHRoZSBhdWRpZW5j ZSAo4oCcYXVk4oCdKSBjbGFpbSBpbgogdGhlIHRva2VuIHRvIGRpc2FibGUgbWlzc3VzZS4KCgoK 4oCU4oCU4oCU4oCU4oCU4oCUCgoKClRoZSBkcmFmdCBpbiBBQ0UgV0cgKGh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1zZWl0ei1hY2Utb2F1dGgtYXV0aHotMDApIHJlbGllcyBoZWF2 aWx5IG9uIHRoaXMgd29yay4gVGhlIG1haW4gcmVhc29uIGZvciB0aGlzIGlzIHRoZSB3YXkgUG9Q IHRva2VucyBjYW4KIGVzdGFibGlzaCBrZXkgbWF0ZXJpYWwsIHdpdGggdGhlIGhlbHAgb2YgdGhl IGF1dGhvcml6YXRpb24gc2VydmVyLCBvbiBib3RoIHRoZSBjbGllbnQgYW5kIHJlc291cmNlIHNl cnZlci4gUG9QIHRva2VucyBpcyBhbHNvIGEgdmVyeSBnb29kIGZpdCBmb3IgY29uc3RyYWluZWQg SW9UIGRldmljZXMgdGhhdCBjYW4gYmUgb2ZmbGluZSBhbmQgaXTigJlzIGFsc28gcG9zc2libGUg dG8gdXNlIGhhcmR3YXJlIGtleSBzdG9yYWdlcyB0byBoYW5kbGUgYXN5bW1ldHJpYwogcG9wIGtl eXMuCgoKClRoZXJlIGNvdWxkIGJlIGEgcGxhY2UgZm9yIGEgbmV3ICJVc2UgQ2FzZSIgdW5kZXIg c2VjdGlvbiAzIHRoYXQgdGFsa3MgYWJvdXQgc2NlbmFyaW9zIHdoZXJlIFBvUCBrZXlzIGFyZSBh IHJlYWxseSBnb29kIG1hdGNoIGZvciBvZmZsaW5lIElvVCBkZXZpY2VzLiBJIGNvdWxkIGhlbHAg b3V0IGlyb25pbmcgb3V0IGEgdGV4dCBmb3IgdGhhdCB3aXRoIHRoZSBoZWxwIG9mIHRoZSBkb2Nz IGF1dGhvcnMgaWYgdGhhdOKAmXMgb2YKIGludGVyZXN0LsKgCgoKCuKAlOKAlOKAlAoKCgpzL2Eg Ym9ndXMgdG9rZW5zL2EgYm9ndXMgdG9rZW4KCgoK4oCU4oCUCgoKCkluIHRoZSBkb2N1bWVudCBv bmx5IHJlZmVyZW5jZXMgYXJlIG1hZGUgdG8gSlNPTiwgSldUIGFuZCBKT1NFLiBNb3JlIGV4YWN0 bHkgaW4gdGhlIGZvbGxvd2luZyB0d28gc2VjdGlvbnM6CgoKCgogICBBIG51bWJlciBvZiB0aGUg dGhyZWF0cyBsaXN0ZWQgaW4gU2VjdGlvbiA0IGRlbWFuZCBwcm90ZWN0aW9uIG9mIHRoZQogICBh Y2Nlc3MgdG9rZW4gY29udGVudCBhbmQgYSBzdGFuZGFyZGl6ZWQgc29sdXRpb24sIGluIGZvcm0g b2YgYSBKU09OLQogICBiYXNlZCBmb3JtYXQsIGlzIGF2YWlsYWJsZSB3aXRoIHRoZSBKV1QgW1JG Qzc1MTldLgoKCgoKCgoKCgoKICAgV2l0aCB0aGUgSlNPTiBXZWIgVG9rZW4gKEpXVCkgW1JGQzc1 MTldIGEgc3RhbmRhcmRpemVkIGZvcm1hdCBmb3IKICAgYWNjZXNzIHRva2VucyBpcyBhdmFpbGFi bGUuICBUaGUgbmVjZXNzYXJ5IGVsZW1lbnRzIHRvIGJpbmQgc3ltbWV0cmljCiAgIG9yIGFzeW1t ZXRyaWMga2V5cyB0byBhIEpXVCBhcmUgZGVzY3JpYmVkIGluCiAgIFtJLUQuaWV0Zi1vYXV0aC1w cm9vZi1vZi1wb3NzZXNzaW9uXS4KCgoKCgoKQ29uc3RyYWluZWQgSW9UIGRldmljZXMgdXNlcyBv dGhlciBhY2Nlc3MgdG9rZW4gYW5kIG1lc3NhZ2VzIGZvcm1hdHMgKGFjY29yZGluZyB0byBvdXIg ZHJhZnQpLiBJdCBkb2VzIG5vdCBvbmx5IHVzZSBzaWduZWQvZW5jcnlwdGVkIEpXVOKAmXMgYnV0 IGFsc28gQ09TRSBwcm90ZWN0ZWQgQ0JPUiBXZWIgVG9rZW5zLiBTZWXCoGh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaWQvZHJhZnQtd2FobHN0cm9lbS1vYXV0aC1jYm9yLXdlYi10b2tlbi0wMC50eHQK CgoKSSB0b3RhbGx5IGFncmVlIHRoYXQgSldUIGlzIHRoZSBjb3JyZWN0IGV4YW1wbGVzIHRvIGhh dmUgaW4gdGhpcyBkb2N1bWVudCBkdWUgdG8gdGhlIGZhY3QgdGhhdCB0aGV5IGFyZSBSRkPigJlz LCB0aGV5IGFyZSB3ZWxsIGtub3duIGFuZCBzaG91bGQgYmUgdXNlZCBpbiBhcyBtYW55IHBsYWNl cyBhcyBwb3NzaWJsZSwgYnV0IGl0IHdvdWxkIGJlIGdvb2QgdG8gb3BlbiB1cCBmb3Igb3RoZXIg dHlwZXMgb2YgbWVzc2FnZSBmb3JtYXRzLgogRm9yIGV4YW1wbGUgbGlrZSB0aGlzOgoKCgoKCgoK ICAgQSBudW1iZXIgb2YgdGhlIHRocmVhdHMgbGlzdGVkIGluIFNlY3Rpb24gNCBkZW1hbmQgcHJv dGVjdGlvbiBvZiB0aGUKICAgYWNjZXNzIHRva2VuIGNvbnRlbnQgYW5kIGEgc3RhbmRhcmRpemVk IHNvbHV0aW9uIGluIGZvcm0gb2YsIGZvciBleGFtcGxlLCBhIEpTT04tCiAgIGJhc2VkIGZvcm1h dCwgaXMgYXZhaWxhYmxlIHdpdGggdGhlIEpXVCBbUkZDNzUxOV0uCgoKCgoKCgoK4oCU4oCUCgoK CgoKIEZvciB0aGF0CiAgIHB1cnBvc2UgdGhlIGNsaWVudCB3aWxsIGhhdmUgdG8gYXV0aGVudGlj YXRlIHRoZSByZXNvdXJjZSBzZXJ2ZXIKICAgYmVmb3JlIHRyYW5zbWl0dGluZyB0aGUgYWNjZXNz IHRva2VuLgoKCgoKCgoKCknigJltIG1pc3NpbmcgYSBkZXNjcmlwdGlvbiBhYm91dCBob3cgdGhp cyBpcyBoYW5kbGVkIGluIGFuIGVuZC10by1lbmQgc2VjdXJpdHkgc2NlbmFyaW8uCgoKCuKAlOKA lOKAlAoKCgoKICAgICAgVGhlIHJlc291cmNlIHNlcnZlciBxdWVyaWVzIHRoZSBhdXRob3JpemF0 aW9uIHNlcnZlciBmb3IgdGhlCiAgICAgIHN5bW1ldHJpYyBrZXkuICBUaGlzIGlzIGFuIGFwcHJv YWNoIGVudmlzaW9uZWQgYnkgdGhlIHRva2VuCiAgICAgIGludHJvc3BlY3Rpb24gZW5kcG9pbnQg W0ktRC5pZXRmLW9hdXRoLWludHJvc3BlY3Rpb25dLgoKCgoKCgoKCk5vdCBhIHF1ZXN0aW9uIGZv ciB0aGlzIGRyYWZ0IG1heWJlLCBidXQgaW4gd2hhdCBkcmFmdCBpcyB0aGUgaW50cm9zcGVjdGlv biByZXNwb25zZSBjbGFpbSBkZWZpbmVkPyBJdOKAmXMgbm90IGRlZmluZWQgaW7CoGh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3NjYyI3NlY3Rpb24tMi4ywqBhbmQKIEkgZG9u4oCZdCBr bm93IGluIHdoYXQgb3RoZXIgZHJhZnQgaXQgY2FuIGJlIGRlZmluZWQuCgoKCuKAlOKAlAoKCgpJ biBBQ0UgV0cgdGhlIGRyYWZ0IHNlaXR6LWFjZS1vYXV0aC1hdXRoeiBoYXZlIGEgcHJvZmlsZSBm b3IgYW4gYWNjZXNzIHJlcXVlc3QgdG8gbWFrZSBpdCB3b3JrIG92ZXIgQ29BUC4gQ29BUCBpcyB0 aGUgSFRUUCBlcXVpdmFsZW50IGZvciBjb25zdHJhaW5lZCBkZXZpY2VzLCBhbmQgaXQgaGFzIGxp bWl0YXRpb25zLCBmb3IgZXhhbXBsZSBpdCBjYW7igJl0IHNlbmQgbGFyZ2UgdG9rZW5zIGluIG9w dGlvbnMgKGhlYWRlcnMgaW4KICJodHRwLXNwZWFrIikuIFRoaXMgbWVhbnMgdGhhdCB0aGUgZHJh ZnQgZGVmaW5lcyBhIHdheSB0byBmaXJzdCBzZW5kIHRoZSBQb1AgdG9rZW4gdG8gYW4gbmV3IGVu ZHBvaW50IG9uIHRoZSByZXNvdXJjZSBzZXJ2ZXIgdG8gZXN0YWJsaXNoIGEgc2VjdXJpdHkgY29u dGV4dC4gVGhlbiB0aGUgcmVhbCByZXF1ZXN0IGFnYWluc3QgdGhlIHJlc291cmNlIHNlcnZlciBj YW4gYmUgZG9uZSBvbmNlIHRoZSBzZWN1cml0eSBjb250ZXh0IGlzIGVzdGFibGlzaGVkLgogU2Vl IG1vcmUgZGV0YWlscyBoZXJlwqBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc2Vp dHotYWNlLW9hdXRoLWF1dGh6LTAwI3NlY3Rpb24tNS4yLgoKCgpBbiBvcGVuIHF1ZXN0aW9uOyBz aG91bGQgYSBmbG93IGxpa2UgdGhhdCBiZSBhZGRlZCB0byB0aGUgYXJjaGl0ZWN0dXJlIHNlY3Rp b24/IFRoYXQgbWVhbnMgYSBuZXcgc2VjdGlvbiA3LjUuCgoKCuKAlOKAlAoKCgpUaGFua3MgZm9y IHdyaXRpbmcgdGhpcy4gSSB0aGluayBpdOKAmXMgdmVyeSBpbXBvcnRhbnQgd29yay4KCgoKLyBF cmlrCgoKCgoKCgoKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXwoKT0F1dGggbWFpbGluZyBsaXN0CgpPQXV0aEBpZXRmLm9yZwoKaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aAoKCgoKCgoK ----_com.android.email_2441371127924970 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keT4KICAgIAo8ZGl2PkkgYWdyZWUgd2l0 aCBhZGRlZCAiRm9yIGV4YW1wbGUiIGluIGEgZmV3IHBsYWNlcy4gSXQncyBub3Qgbm9ybWF0aXZl IGl0J3MgaW5mb3JtYXRpb25hbCBoZXJlLiZuYnNwOzwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+ PGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXYgaWQ9ImNvbXBvc2VyX3NpZ25hdHVyZSI+PG1l dGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9 VVRGLTgiPjxkaXY8IGRpdj0iIj48ZGl2PjxkaXY+LS0gSnVzdGluPC9kaXY+PGRpdj48YnI+PC9k aXY+PGRpdj4vIFNlbnQgZnJvbSBteSBwaG9uZSAvPC9kaXY+PC9kaXY+PGRpdj48L2Rpdj48L2Rp djw+PC9kaXY+PGJyPjxicj4tLS0tLS0tLSBPcmlnaW5hbCBtZXNzYWdlIC0tLS0tLS0tPGJyPkZy b206IFBoaWwgSHVudCAmbHQ7cGhpbC5odW50QG9yYWNsZS5jb20mZ3Q7IDxicj5EYXRlOiAxMS8x OS8yMDE1ICAxMToyOCBBTSAgKEdNVC0wNjowMCkgPGJyPlRvOiBFcmlrIFdhaGxzdHLDtm0gbmVY dXMgJmx0O2VyaWsud2FobHN0cm9tQG5leHVzZ3JvdXAuY29tJmd0OyA8YnI+Q2M6ICImbHQ7b2F1 dGhAaWV0Zi5vcmcmZ3Q7IiAmbHQ7b2F1dGhAaWV0Zi5vcmcmZ3Q7LCBKdXN0aW4gUmljaGVyICZs dDtpZXRmQGp1c3Rpbi5yaWNoZXIub3JnJmd0OyA8YnI+U3ViamVjdDogUmU6IFtPQVVUSC1XR10g QSByZXZpZXcgb2YgZHJhZnQtaWV0Zi1vYXV0aC1wb3AtYXJjaGl0ZWN0dXJlLTA1IDxicj48YnI+ PGRpdj5JIHRoaW5rIHlvdXIgcG9pbnQgdGhhdCBtYXliZSB0aGUgYXJjaGl0ZWN0dXJlIGRvYyBi ZSBnZW5lcmljIGVub3VnaCB0byBzdXBwb3J0IGJvdGgganNvbiBhbmQgY2JvciB0b2tlbnMgaXMg d29ydGggY29uc2lkZXJhdGlvbi4mbmJzcDs8L2Rpdj48ZGl2IGlkPSJBcHBsZU1haWxTaWduYXR1 cmUiPjxicj48L2Rpdj48ZGl2IGlkPSJBcHBsZU1haWxTaWduYXR1cmUiPkkgYW0ganVzdCBub3Qg c3VyZSBvZiBwcm9jZXNzIGFuZCBjb25zZW5zdXMgbm93IHRoYXQgd2UgYXJlIHBhc3QgV0dMQy4g V291bGQgdGhlIGNvc2UgZ3JvdXAgcHJlZmVyIHRoaXM/PC9kaXY+PGRpdiBpZD0iQXBwbGVNYWls U2lnbmF0dXJlIj48YnI+PC9kaXY+PGRpdiBpZD0iQXBwbGVNYWlsU2lnbmF0dXJlIj5IYXBweSB0 byBkbyBpdCBpZiBkZXNpcmVkLiBBbHNvIHVuZGVyc3RhbmQgaWYgd2UgYXJlIHRvbyBmYXIgZG93 biB0aGUgcm9hZC4mbmJzcDs8YnI+PGJyPlBoaWw8L2Rpdj48ZGl2Pjxicj5PbiBOb3YgMTksIDIw MTUsIGF0IDA4OjM5LCBFcmlrIFdhaGxzdHLDtm0gbmVYdXMgJmx0OzxhIGhyZWY9Im1haWx0bzpl cmlrLndhaGxzdHJvbUBuZXh1c2dyb3VwLmNvbSI+ZXJpay53YWhsc3Ryb21AbmV4dXNncm91cC5j b208L2E+Jmd0OyB3cm90ZTo8YnI+PGJyPjwvZGl2PjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxk aXY+CgoKCgo8ZGl2Pkp1c3QgYSBub3RlIHRoZW4uIEkgZGlkIG5vdCBzZWUgYW55dGhpbmcgdGhh dCBwcm9oaWJpdGVkIHRoZSB1c2FnZSBvZiBwb3AgdG9rZW5zIGZvciBJb1Qgc28gJm5ic3A7c2hp cHBpbmcgaXQgYXMgaXMgd29ya3MuPGJyPgo8YnI+ClNlbnQgZnJvbSBteSBpUGhvbmU8L2Rpdj4K PGRpdj48YnI+Ck9uIDE5IE5vdiAyMDE1LCBhdCAxNzoxOCwgUGhpbCBIdW50ICZsdDs8YSBocmVm PSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iPnBoaWwuaHVudEBvcmFjbGUuY29tPC9hPiZn dDsgd3JvdGU6PGJyPgo8YnI+CjwvZGl2Pgo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4KPGRpdj4K PGRpdj5PbiB0aGUgc3ViamVjdCBvZiBtYWtpbmcgdGhlIHNwZWMocykgbGVzcyBKV1Qgc3BlY2lm aWMsIGl0IHdhcyBhIGZvdW5kYXRpb25hbCBhc3N1bXB0aW9uIGFuZCAoSSB0aGluaykgaW4gdGhl IGNoYXJ0ZXIuIEhvd2V2ZXIgQ09TRSB3YXNuJ3QgYXJvdW5kIHlldC4mbmJzcDs8L2Rpdj4KPGRp diBpZD0iQXBwbGVNYWlsU2lnbmF0dXJlIj48YnI+CjwvZGl2Pgo8ZGl2IGlkPSJBcHBsZU1haWxT aWduYXR1cmUiPkkgc3VwcG9zZSB0aGUgbW9yZSBnZW5lcmljIGFyY2hpdGVjdHVyZSBkb2MgY291 bGQgYmUgYWx0ZXJlZCB0byBjb3ZlciBJb1QgY2FzZXMsIGJ1dCBpdCBtYXkgYmUgcHJvYmxlbWF0 aWMgZm9yIHRoZSBvdGhlciBzcGVjcyB0aGF0IGFyZSBtb3JlIHNwZWNpZmljLiZuYnNwOzwvZGl2 Pgo8ZGl2IGlkPSJBcHBsZU1haWxTaWduYXR1cmUiPjxicj4KPC9kaXY+CjxkaXYgaWQ9IkFwcGxl TWFpbFNpZ25hdHVyZSI+QW5vdGhlciBpc3N1ZSBpcyBJIGFzc3VtZSB0aGUgQ09TRSBiYXNlZCB0 b2tlbnMgd2lsbCBoYXZlIGEgZGlmZmVyZW50IHR5cGUgKGVnIGNwb3ApIHRvIGRpZmZlcmVudGlh dGUgYmV0d2VlbiBqd3QgYW5kIENPU0Ugd2ViIHRva2VucyAod2hhdCBhcmUgd2UgY2FsbGluZyB0 aGVtIG5vdz8pLiZuYnNwOzwvZGl2Pgo8ZGl2IGlkPSJBcHBsZU1haWxTaWduYXR1cmUiPjxicj4K PC9kaXY+CjxkaXYgaWQ9IkFwcGxlTWFpbFNpZ25hdHVyZSI+QXMgdGhpcyBnZW5lcmFsaXphdGlv biBjaGFuZ2UgY291bGQgYmUgc2VlbiBhcyBzdWJzdGFudGlhbCwgSSB3b3VsZCBsaWtlIHRvIGhh dmUgdGhlIGNoYWlycyBhbmQgQUQgY29tbWVudC4gSXMgdGhpcyBhIGdvb2QgaWRlYT8gJm5ic3A7 T3IgaXMgQ09TRSBiZXR0ZXIgdG8gd3JpdGUgdGhlaXIgb3duIHBhcmFsbGVsIGFyY2ggZHJhZnQ/ PC9kaXY+CjxkaXYgaWQ9IkFwcGxlTWFpbFNpZ25hdHVyZSI+PGJyPgo8L2Rpdj4KPGRpdiBpZD0i QXBwbGVNYWlsU2lnbmF0dXJlIj5JJ20gaGFwcHkgdG8gYmVuZCB0byB0aGUgd2lsbCBvZiB0aGUg Z3JvdXAocykgb24gdGhpcy4mbmJzcDs8L2Rpdj4KPGRpdiBpZD0iQXBwbGVNYWlsU2lnbmF0dXJl Ij48YnI+ClBoaWw8L2Rpdj4KPGRpdj48YnI+Ck9uIE5vdiAxOSwgMjAxNSwgYXQgMDE6MTcsIEVy aWsgV2FobHN0csO2bSBuZVh1cyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmVyaWsud2FobHN0cm9tQG5l eHVzZ3JvdXAuY29tIj5lcmlrLndhaGxzdHJvbUBuZXh1c2dyb3VwLmNvbTwvYT4mZ3Q7IHdyb3Rl Ojxicj4KPGJyPgo8L2Rpdj4KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+CjxkaXY+CjxkaXYgY2xh c3M9IiI+CjxkaXYgY2xhc3M9IiI+SGksJm5ic3A7PC9kaXY+CjxkaXYgY2xhc3M9IiI+PGJyIGNs YXNzPSIiPgo8L2Rpdj4KPGRpdiBjbGFzcz0iIj5JIGhhdmUgYmVlbiByZXZpZXdpbmcmbmJzcDtk cmFmdC1pZXRmLW9hdXRoLXBvcC1hcmNoaXRlY3R1cmUtMDUuIEluIEFDRSBXRyB3ZSBoYXZlIGEg ZHJhZnQgdGhhdCB1c2VzIFBvUCB0b2tlbnMgZm9yIElvVCBhbmQgdGhlIGFyY2hpdGVjdHVyZXMg ZGVmaW5lZCBoZXJlIHNvIG15IHJldmlldyB3YXMgZG9uZSB3aXRoIHRoYXQgSW9UIHBlcnNwZWN0 aXZlLiBJ4oCZbSBhIGJpdCBsYXRlIHdpdGggdGhlIHJldmlldyBhbmQgc29tZSBvZiB0aGUKIGNv bW1lbnRzIG1pZ2h0IGFscmVhZHkgYmUgbWVudGlvbmVkIGJ5IG90aGVycy48L2Rpdj4KPGRpdiBj bGFzcz0iIj48YnIgY2xhc3M9IiI+CjwvZGl2Pgo8ZGl2IGNsYXNzPSIiPiZuYnNwOzwvZGl2Pgo8 ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4KPC9kaXY+CjxkaXYgY2xhc3M9IiI+4oCU4oCU4oCU 4oCU4oCU4oCUPC9kaXY+CjwvZGl2Pgo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4KPC9kaXY+ CjMuMS4gUHJldmVudGluZyBBY2Nlc3MgVG9rZW4gUmUtVXNlIGJ5IHRoZSBSZXNvdXJjZSBTZXJ2 ZXIKPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+CjwvZGl2Pgo8ZGl2IGNsYXNzPSIiPklmIGEg c3ltbWV0cmljIGtleSBpcyB1c2VkIGl04oCZcyBwb3NzaWJsZSB0byByZS11c2UgdGhlIGtleSBm b3IgYSByZXNvdXJjZSBzZXJ2ZXIuIFRoZSBzZWN0aW9uIHRhbGtzIGFib3V0IHRoZSBpbXBvcnRh bmNlIG9mIHNjb3BlcywgYnV0IEkgZmVlbCBpdCBzaG91bGQgYWxzbyBtZW50aW9uIHRoZSBpbXBv cnRhbmNlIGZvciB0aGUgcmVzb3VyY2Ugc2VydmVyIHRvIHZlcmlmeSB0aGUgYXVkaWVuY2UgKOKA nGF1ZOKAnSkgY2xhaW0gaW4KIHRoZSB0b2tlbiB0byBkaXNhYmxlIG1pc3N1c2UuPGJyIGNsYXNz PSIiPgo8YnIgY2xhc3M9IiI+CjxkaXYgY2xhc3M9IiI+4oCU4oCU4oCU4oCU4oCU4oCUPC9kaXY+ CjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPgo8L2Rpdj4KPGRpdiBjbGFzcz0iIj5UaGUgZHJh ZnQgaW4gQUNFIFdHICg8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt c2VpdHotYWNlLW9hdXRoLWF1dGh6LTAwIiBjbGFzcz0iIj5odHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtc2VpdHotYWNlLW9hdXRoLWF1dGh6LTAwPC9hPikgcmVsaWVzIGhlYXZpbHkg b24gdGhpcyB3b3JrLiBUaGUgbWFpbiByZWFzb24gZm9yIHRoaXMgaXMgdGhlIHdheSBQb1AgdG9r ZW5zIGNhbgogZXN0YWJsaXNoIGtleSBtYXRlcmlhbCwgd2l0aCB0aGUgaGVscCBvZiB0aGUgYXV0 aG9yaXphdGlvbiBzZXJ2ZXIsIG9uIGJvdGggdGhlIGNsaWVudCBhbmQgcmVzb3VyY2Ugc2VydmVy LiBQb1AgdG9rZW5zIGlzIGFsc28gYSB2ZXJ5IGdvb2QgZml0IGZvciBjb25zdHJhaW5lZCBJb1Qg ZGV2aWNlcyB0aGF0IGNhbiBiZSBvZmZsaW5lIGFuZCBpdOKAmXMgYWxzbyBwb3NzaWJsZSB0byB1 c2UgaGFyZHdhcmUga2V5IHN0b3JhZ2VzIHRvIGhhbmRsZSBhc3ltbWV0cmljCiBwb3Aga2V5cy48 L2Rpdj4KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+CjwvZGl2Pgo8ZGl2IGNsYXNzPSIiPlRo ZXJlIGNvdWxkIGJlIGEgcGxhY2UgZm9yIGEgbmV3ICJVc2UgQ2FzZSIgdW5kZXIgc2VjdGlvbiAz IHRoYXQgdGFsa3MgYWJvdXQgc2NlbmFyaW9zIHdoZXJlIFBvUCBrZXlzIGFyZSBhIHJlYWxseSBn b29kIG1hdGNoIGZvciBvZmZsaW5lIElvVCBkZXZpY2VzLiBJIGNvdWxkIGhlbHAgb3V0IGlyb25p bmcgb3V0IGEgdGV4dCBmb3IgdGhhdCB3aXRoIHRoZSBoZWxwIG9mIHRoZSBkb2NzIGF1dGhvcnMg aWYgdGhhdOKAmXMgb2YKIGludGVyZXN0LiZuYnNwOzwvZGl2Pgo8ZGl2IGNsYXNzPSIiPjxiciBj bGFzcz0iIj4KPC9kaXY+CjxkaXYgY2xhc3M9IiI+4oCU4oCU4oCUPC9kaXY+CjxkaXYgY2xhc3M9 IiI+PGJyIGNsYXNzPSIiPgo8L2Rpdj4KPGRpdiBjbGFzcz0iIj5zL2EgYm9ndXMgdG9rZW5zL2Eg Ym9ndXMgdG9rZW48L2Rpdj4KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+CjwvZGl2Pgo8ZGl2 IGNsYXNzPSIiPuKAlOKAlDwvZGl2Pgo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4KPC9kaXY+ CjxkaXYgY2xhc3M9IiI+SW4gdGhlIGRvY3VtZW50IG9ubHkgcmVmZXJlbmNlcyBhcmUgbWFkZSB0 byBKU09OLCBKV1QgYW5kIEpPU0UuIE1vcmUgZXhhY3RseSBpbiB0aGUgZm9sbG93aW5nIHR3byBz ZWN0aW9uczo8L2Rpdj4KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+CjwvZGl2Pgo8ZGl2IGNs YXNzPSIiPgo8cHJlIGNsYXNzPSJuZXdwYWdlIiBzdHlsZT0iZm9udC1zaXplOiAxMy4zMzMzcHg7 IG1hcmdpbi10b3A6IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4OyBwYWdlLWJyZWFrLWJlZm9yZTog YWx3YXlzOyB3aWRvd3M6IDE7Ij4gICBBIG51bWJlciBvZiB0aGUgdGhyZWF0cyBsaXN0ZWQgaW4g PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtcG9w LWFyY2hpdGVjdHVyZS0wNSNzZWN0aW9uLTQiIGNsYXNzPSIiPlNlY3Rpb24gNDwvYT4gZGVtYW5k IHByb3RlY3Rpb24gb2YgdGhlCiAgIGFjY2VzcyB0b2tlbiBjb250ZW50IGFuZCBhIHN0YW5kYXJk aXplZCBzb2x1dGlvbiwgaW4gZm9ybSBvZiBhIEpTT04tCiAgIGJhc2VkIGZvcm1hdCwgaXMgYXZh aWxhYmxlIHdpdGggdGhlIEpXVCBbPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L3JmYzc1MTkiIHRpdGxlPSImcXVvdDtKU09OIFdlYiBUb2tlbiAoSldUKSZxdW90OyIgY2xhc3M9 IiI+UkZDNzUxOTwvYT5dLgo8L3ByZT4KPC9kaXY+CjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIi Pgo8L2Rpdj4KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+CjwvZGl2Pgo8ZGl2IGNsYXNzPSIi Pgo8ZGl2IGNsYXNzPSIiPgo8cHJlIGNsYXNzPSJuZXdwYWdlIiBzdHlsZT0iZm9udC1zaXplOiAx My4zMzMzcHg7IG1hcmdpbi10b3A6IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4OyBwYWdlLWJyZWFr LWJlZm9yZTogYWx3YXlzOyB3aWRvd3M6IDE7Ij4gICBXaXRoIHRoZSBKU09OIFdlYiBUb2tlbiAo SldUKSBbPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzc1MTkiIHRpdGxl PSImcXVvdDtKU09OIFdlYiBUb2tlbiAoSldUKSZxdW90OyIgY2xhc3M9IiI+UkZDNzUxOTwvYT5d IGEgc3RhbmRhcmRpemVkIGZvcm1hdCBmb3IKICAgYWNjZXNzIHRva2VucyBpcyBhdmFpbGFibGUu ICBUaGUgbmVjZXNzYXJ5IGVsZW1lbnRzIHRvIGJpbmQgc3ltbWV0cmljCiAgIG9yIGFzeW1tZXRy aWMga2V5cyB0byBhIEpXVCBhcmUgZGVzY3JpYmVkIGluCiAgIFs8YSBocmVmPSJodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1wb3AtYXJjaGl0ZWN0dXJlLTA1I3Jl Zi1JLUQuaWV0Zi1vYXV0aC1wcm9vZi1vZi1wb3NzZXNzaW9uIiBjbGFzcz0iIj5JLUQuaWV0Zi1v YXV0aC1wcm9vZi1vZi1wb3NzZXNzaW9uPC9hPl0uCjwvcHJlPgo8L2Rpdj4KPGRpdiBjbGFzcz0i Ij48YnIgY2xhc3M9IiI+CjwvZGl2Pgo8L2Rpdj4KPGRpdiBjbGFzcz0iIj5Db25zdHJhaW5lZCBJ b1QgZGV2aWNlcyB1c2VzIG90aGVyIGFjY2VzcyB0b2tlbiBhbmQgbWVzc2FnZXMgZm9ybWF0cyAo YWNjb3JkaW5nIHRvIG91ciBkcmFmdCkuIEl0IGRvZXMgbm90IG9ubHkgdXNlIHNpZ25lZC9lbmNy eXB0ZWQgSldU4oCZcyBidXQgYWxzbyBDT1NFIHByb3RlY3RlZCBDQk9SIFdlYiBUb2tlbnMuIFNl ZSZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtd2FobHN0cm9l bS1vYXV0aC1jYm9yLXdlYi10b2tlbi0wMC50eHQiIGNsYXNzPSIiPmh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaWQvZHJhZnQtd2FobHN0cm9lbS1vYXV0aC1jYm9yLXdlYi10b2tlbi0wMC50eHQ8L2E+ PC9kaXY+CjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPgo8L2Rpdj4KPGRpdiBjbGFzcz0iIj5J IHRvdGFsbHkgYWdyZWUgdGhhdCBKV1QgaXMgdGhlIGNvcnJlY3QgZXhhbXBsZXMgdG8gaGF2ZSBp biB0aGlzIGRvY3VtZW50IGR1ZSB0byB0aGUgZmFjdCB0aGF0IHRoZXkgYXJlIFJGQ+KAmXMsIHRo ZXkgYXJlIHdlbGwga25vd24gYW5kIHNob3VsZCBiZSB1c2VkIGluIGFzIG1hbnkgcGxhY2VzIGFz IHBvc3NpYmxlLCBidXQgaXQgd291bGQgYmUgZ29vZCB0byBvcGVuIHVwIGZvciBvdGhlciB0eXBl cyBvZiBtZXNzYWdlIGZvcm1hdHMuCiBGb3IgZXhhbXBsZSBsaWtlIHRoaXM6PC9kaXY+CjxkaXYg Y2xhc3M9IiI+PGJyIGNsYXNzPSIiPgo8L2Rpdj4KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+ CjwvZGl2Pgo8ZGl2IGNsYXNzPSIiPgo8cHJlIGNsYXNzPSJuZXdwYWdlIiBzdHlsZT0iZm9udC1z aXplOiAxMy4zMzMzcHg7IG1hcmdpbi10b3A6IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4OyBwYWdl LWJyZWFrLWJlZm9yZTogYWx3YXlzOyB3aWRvd3M6IDE7Ij4gICBBIG51bWJlciBvZiB0aGUgdGhy ZWF0cyBsaXN0ZWQgaW4gPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWlldGYtb2F1dGgtcG9wLWFyY2hpdGVjdHVyZS0wNSNzZWN0aW9uLTQiIGNsYXNzPSIiPlNlY3Rp b24gNDwvYT4gZGVtYW5kIHByb3RlY3Rpb24gb2YgdGhlCiAgIGFjY2VzcyB0b2tlbiBjb250ZW50 IGFuZCBhIHN0YW5kYXJkaXplZCBzb2x1dGlvbiBpbiBmb3JtIG9mLCA8YiBjbGFzcz0iIj5mb3Ig ZXhhbXBsZSw8L2I+IGEgSlNPTi0KICAgYmFzZWQgZm9ybWF0LCBpcyBhdmFpbGFibGUgd2l0aCB0 aGUgSldUIFs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzUxOSIgdGl0 bGU9IiZxdW90O0pTT04gV2ViIFRva2VuIChKV1QpJnF1b3Q7IiBjbGFzcz0iIj5SRkM3NTE5PC9h Pl0uCjwvcHJlPgo8L2Rpdj4KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+CjwvZGl2Pgo8ZGl2 IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4KPC9kaXY+CjxkaXYgY2xhc3M9IiI+4oCU4oCUPC9kaXY+ CjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPgo8L2Rpdj4KPGRpdiBjbGFzcz0iIj4KPGRpdiBj bGFzcz0iIj4KPHByZSBjbGFzcz0ibmV3cGFnZSIgc3R5bGU9ImZvbnQtc2l6ZTogMTMuMzMzM3B4 OyBtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0b206IDBweDsgcGFnZS1icmVhay1iZWZvcmU6 IGFsd2F5czsgd2lkb3dzOiAxOyI+IEZvciB0aGF0CiAgIHB1cnBvc2UgdGhlIGNsaWVudCB3aWxs IGhhdmUgdG8gYXV0aGVudGljYXRlIHRoZSByZXNvdXJjZSBzZXJ2ZXIKICAgYmVmb3JlIHRyYW5z bWl0dGluZyB0aGUgYWNjZXNzIHRva2VuLgo8L3ByZT4KPC9kaXY+CjxkaXYgY2xhc3M9IiI+PGJy IGNsYXNzPSIiPgo8L2Rpdj4KPGJyIGNsYXNzPSIiPgo8L2Rpdj4KPGRpdiBjbGFzcz0iIj5J4oCZ bSBtaXNzaW5nIGEgZGVzY3JpcHRpb24gYWJvdXQgaG93IHRoaXMgaXMgaGFuZGxlZCBpbiBhbiBl bmQtdG8tZW5kIHNlY3VyaXR5IHNjZW5hcmlvLjwvZGl2Pgo8ZGl2IGNsYXNzPSIiPjxiciBjbGFz cz0iIj4KPC9kaXY+CjxkaXYgY2xhc3M9IiI+4oCU4oCU4oCUPC9kaXY+CjxkaXYgY2xhc3M9IiI+ PGJyIGNsYXNzPSIiPgo8L2Rpdj4KPGRpdiBjbGFzcz0iIj4KPHByZSBjbGFzcz0ibmV3cGFnZSIg c3R5bGU9ImZvbnQtc2l6ZTogMTMuMzMzM3B4OyBtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0 b206IDBweDsgcGFnZS1icmVhay1iZWZvcmU6IGFsd2F5czsgd2lkb3dzOiAxOyI+ICAgICAgVGhl IHJlc291cmNlIHNlcnZlciBxdWVyaWVzIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBmb3IgdGhl CiAgICAgIHN5bW1ldHJpYyBrZXkuICBUaGlzIGlzIGFuIGFwcHJvYWNoIGVudmlzaW9uZWQgYnkg dGhlIHRva2VuCiAgICAgIGludHJvc3BlY3Rpb24gZW5kcG9pbnQgWzxhIGhyZWY9Imh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLXBvcC1hcmNoaXRlY3R1cmUtMDUj cmVmLUktRC5pZXRmLW9hdXRoLWludHJvc3BlY3Rpb24iIGNsYXNzPSIiPkktRC5pZXRmLW9hdXRo LWludHJvc3BlY3Rpb248L2E+XS4KPC9wcmU+CjwvZGl2Pgo8ZGl2IGNsYXNzPSIiPjxiciBjbGFz cz0iIj4KPC9kaXY+CjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPgo8L2Rpdj4KPGRpdiBjbGFz cz0iIj5Ob3QgYSBxdWVzdGlvbiBmb3IgdGhpcyBkcmFmdCBtYXliZSwgYnV0IGluIHdoYXQgZHJh ZnQgaXMgdGhlIGludHJvc3BlY3Rpb24gcmVzcG9uc2UgY2xhaW0gZGVmaW5lZD8gSXTigJlzIG5v dCBkZWZpbmVkIGluJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3Jm Yzc2NjIjc2VjdGlvbi0yLjIiIGNsYXNzPSIiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9y ZmM3NjYyI3NlY3Rpb24tMi4yPC9hPiZuYnNwO2FuZAogSSBkb27igJl0IGtub3cgaW4gd2hhdCBv dGhlciBkcmFmdCBpdCBjYW4gYmUgZGVmaW5lZC48L2Rpdj4KPGRpdiBjbGFzcz0iIj48YnIgY2xh c3M9IiI+CjwvZGl2Pgo8ZGl2IGNsYXNzPSIiPuKAlOKAlDwvZGl2Pgo8ZGl2IGNsYXNzPSIiPjxi ciBjbGFzcz0iIj4KPC9kaXY+CjxkaXYgY2xhc3M9IiI+SW4gQUNFIFdHIHRoZSBkcmFmdCBzZWl0 ei1hY2Utb2F1dGgtYXV0aHogaGF2ZSBhIHByb2ZpbGUgZm9yIGFuIGFjY2VzcyByZXF1ZXN0IHRv IG1ha2UgaXQgd29yayBvdmVyIENvQVAuIENvQVAgaXMgdGhlIEhUVFAgZXF1aXZhbGVudCBmb3Ig Y29uc3RyYWluZWQgZGV2aWNlcywgYW5kIGl0IGhhcyBsaW1pdGF0aW9ucywgZm9yIGV4YW1wbGUg aXQgY2Fu4oCZdCBzZW5kIGxhcmdlIHRva2VucyBpbiBvcHRpb25zIChoZWFkZXJzIGluCiAiaHR0 cC1zcGVhayIpLiBUaGlzIG1lYW5zIHRoYXQgdGhlIGRyYWZ0IGRlZmluZXMgYSB3YXkgdG8gZmly c3Qgc2VuZCB0aGUgUG9QIHRva2VuIHRvIGFuIG5ldyBlbmRwb2ludCBvbiB0aGUgcmVzb3VyY2Ug c2VydmVyIHRvIGVzdGFibGlzaCBhIHNlY3VyaXR5IGNvbnRleHQuIFRoZW4gdGhlIHJlYWwgcmVx dWVzdCBhZ2FpbnN0IHRoZSByZXNvdXJjZSBzZXJ2ZXIgY2FuIGJlIGRvbmUgb25jZSB0aGUgc2Vj dXJpdHkgY29udGV4dCBpcyBlc3RhYmxpc2hlZC4KIFNlZSBtb3JlIGRldGFpbHMgaGVyZSZuYnNw OzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zZWl0ei1hY2Utb2F1 dGgtYXV0aHotMDAjc2VjdGlvbi01LjIiIGNsYXNzPSIiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1zZWl0ei1hY2Utb2F1dGgtYXV0aHotMDAjc2VjdGlvbi01LjI8L2E+LjwvZGl2 Pgo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4KPC9kaXY+CjxkaXYgY2xhc3M9IiI+QW4gb3Bl biBxdWVzdGlvbjsgc2hvdWxkIGEgZmxvdyBsaWtlIHRoYXQgYmUgYWRkZWQgdG8gdGhlIGFyY2hp dGVjdHVyZSBzZWN0aW9uPyBUaGF0IG1lYW5zIGEgbmV3IHNlY3Rpb24gNy41LjwvZGl2Pgo8ZGl2 IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4KPC9kaXY+CjxkaXYgY2xhc3M9IiI+4oCU4oCUPC9kaXY+ CjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPgo8L2Rpdj4KPGRpdiBjbGFzcz0iIj5UaGFua3Mg Zm9yIHdyaXRpbmcgdGhpcy4gSSB0aGluayBpdOKAmXMgdmVyeSBpbXBvcnRhbnQgd29yay48L2Rp dj4KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+CjwvZGl2Pgo8ZGl2IGNsYXNzPSIiPi8gRXJp azwvZGl2Pgo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4KPC9kaXY+CjxkaXYgY2xhc3M9IiI+ PGJyIGNsYXNzPSIiPgo8L2Rpdj4KPC9kaXY+CjwvZGl2Pgo8L2Jsb2NrcXVvdGU+CjxibG9ja3F1 b3RlIHR5cGU9ImNpdGUiPgo8ZGl2PjxzcGFuPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPC9zcGFuPjxicj4KPHNwYW4+T0F1dGggbWFpbGluZyBsaXN0PC9z cGFuPjxicj4KPHNwYW4+PGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj5PQXV0aEBpZXRm Lm9yZzwvYT48L3NwYW4+PGJyPgo8c3Bhbj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL29hdXRoIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL29hdXRoPC9hPjwvc3Bhbj48YnI+CjwvZGl2Pgo8L2Jsb2NrcXVvdGU+CjwvZGl2Pgo8L2Js b2NrcXVvdGU+CgoKPC9kaXY+PC9ibG9ja3F1b3RlPjwvYm9keT48L2h0bWw+ ----_com.android.email_2441371127924970-- From nobody Thu Nov 19 11:29:32 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0B7B1A6EFE for ; Thu, 19 Nov 2015 11:29:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.884 X-Spam-Level: X-Spam-Status: No, score=-2.884 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.585] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pPam0qHmvWz9 for ; Thu, 19 Nov 2015 11:29:27 -0800 (PST) Received: from smtp.nexusgroup.com (smtp.nexusgroup.com [83.241.133.121]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 144951A1BAE for ; Thu, 19 Nov 2015 11:29:26 -0800 (PST) Received: from NG-EX01.ad.nexusgroup.com (10.75.28.40) by NG-EX02.ad.nexusgroup.com (10.75.28.43) with Microsoft SMTP Server (TLS) id 15.0.995.29; Thu, 19 Nov 2015 20:29:24 +0100 Received: from NG-EX01.ad.nexusgroup.com ([fe80::1d3d:b319:f020:2bab]) by NG-EX01.ad.nexusgroup.com ([fe80::1d3d:b319:f020:2bab%12]) with mapi id 15.00.0995.032; Thu, 19 Nov 2015 20:29:24 +0100 From: =?utf-8?B?RXJpayBXYWhsc3Ryw7ZtIG5lWHVz?= To: Justin Richer Thread-Topic: [OAUTH-WG] A review of draft-ietf-oauth-pop-architecture-05 Thread-Index: AQHRIva3Cr6RmlnVq02omaMFbp3lkZ6jqoGA Date: Thu, 19 Nov 2015 19:29:24 +0000 Message-ID: <2DC07A54-BA80-48EE-9CC3-7BDE4CAA0AD7@nexusgroup.com> References: In-Reply-To: Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.2104) x-originating-ip: [37.247.26.197] Content-Type: multipart/alternative; boundary="_000_2DC07A54BA8048EE9CC37BDE4CAA0AD7nexusgroupcom_" MIME-Version: 1.0 Archived-At: Cc: "" , Justin Richer Subject: Re: [OAUTH-WG] A review of draft-ietf-oauth-pop-architecture-05 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2015 19:29:32 -0000 --_000_2DC07A54BA8048EE9CC37BDE4CAA0AD7nexusgroupcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RmFpciBlbm91Z2guIFdhcyB3YXkgdG8gbGF0ZSB0byB0aGUgZ2FtZSBoZXJlLiBBbGwgYW5kIGFs bCwgaXTigJlzIGEgdmVyeSBnb29kIGRvY3VtZW50Lg0KLyBFcmlrDQoNCg0KT24gMTkgTm92IDIw MTUsIGF0IDE5OjE4LCBKdXN0aW4gUmljaGVyIDxqcmljaGVyQE1JVC5FRFU8bWFpbHRvOmpyaWNo ZXJATUlULkVEVT4+IHdyb3RlOg0KDQpJIGFncmVlIHdpdGggYWRkZWQgIkZvciBleGFtcGxlIiBp biBhIGZldyBwbGFjZXMuIEl0J3Mgbm90IG5vcm1hdGl2ZSBpdCdzIGluZm9ybWF0aW9uYWwgaGVy ZS4NCg0KDQoNCjwgZGl2PSIiPg0KLS0gSnVzdGluDQoNCi8gU2VudCBmcm9tIG15IHBob25lIC8N Cjw+DQoNCg0KLS0tLS0tLS0gT3JpZ2luYWwgbWVzc2FnZSAtLS0tLS0tLQ0KRnJvbTogUGhpbCBI dW50IDxwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+Pg0K RGF0ZTogMTEvMTkvMjAxNSAxMToyOCBBTSAoR01ULTA2OjAwKQ0KVG86IEVyaWsgV2FobHN0csO2 bSBuZVh1cyA8ZXJpay53YWhsc3Ryb21AbmV4dXNncm91cC5jb208bWFpbHRvOmVyaWsud2FobHN0 cm9tQG5leHVzZ3JvdXAuY29tPj4NCkNjOiAiPG9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBp ZXRmLm9yZz4+IiA8b2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPj4sIEp1c3Rp biBSaWNoZXIgPGlldGZAanVzdGluLnJpY2hlci5vcmc8bWFpbHRvOmlldGZAanVzdGluLnJpY2hl ci5vcmc+Pg0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gQSByZXZpZXcgb2YgZHJhZnQtaWV0Zi1v YXV0aC1wb3AtYXJjaGl0ZWN0dXJlLTA1DQoNCkkgdGhpbmsgeW91ciBwb2ludCB0aGF0IG1heWJl IHRoZSBhcmNoaXRlY3R1cmUgZG9jIGJlIGdlbmVyaWMgZW5vdWdoIHRvIHN1cHBvcnQgYm90aCBq c29uIGFuZCBjYm9yIHRva2VucyBpcyB3b3J0aCBjb25zaWRlcmF0aW9uLg0KDQpJIGFtIGp1c3Qg bm90IHN1cmUgb2YgcHJvY2VzcyBhbmQgY29uc2Vuc3VzIG5vdyB0aGF0IHdlIGFyZSBwYXN0IFdH TEMuIFdvdWxkIHRoZSBjb3NlIGdyb3VwIHByZWZlciB0aGlzPw0KDQpIYXBweSB0byBkbyBpdCBp ZiBkZXNpcmVkLiBBbHNvIHVuZGVyc3RhbmQgaWYgd2UgYXJlIHRvbyBmYXIgZG93biB0aGUgcm9h ZC4NCg0KUGhpbA0KDQpPbiBOb3YgMTksIDIwMTUsIGF0IDA4OjM5LCBFcmlrIFdhaGxzdHLDtm0g bmVYdXMgPGVyaWsud2FobHN0cm9tQG5leHVzZ3JvdXAuY29tPG1haWx0bzplcmlrLndhaGxzdHJv bUBuZXh1c2dyb3VwLmNvbT4+IHdyb3RlOg0KDQpKdXN0IGEgbm90ZSB0aGVuLiBJIGRpZCBub3Qg c2VlIGFueXRoaW5nIHRoYXQgcHJvaGliaXRlZCB0aGUgdXNhZ2Ugb2YgcG9wIHRva2VucyBmb3Ig SW9UIHNvICBzaGlwcGluZyBpdCBhcyBpcyB3b3Jrcy4NCg0KU2VudCBmcm9tIG15IGlQaG9uZQ0K DQpPbiAxOSBOb3YgMjAxNSwgYXQgMTc6MTgsIFBoaWwgSHVudCA8cGhpbC5odW50QG9yYWNsZS5j b208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPj4gd3JvdGU6DQoNCk9uIHRoZSBzdWJqZWN0 IG9mIG1ha2luZyB0aGUgc3BlYyhzKSBsZXNzIEpXVCBzcGVjaWZpYywgaXQgd2FzIGEgZm91bmRh dGlvbmFsIGFzc3VtcHRpb24gYW5kIChJIHRoaW5rKSBpbiB0aGUgY2hhcnRlci4gSG93ZXZlciBD T1NFIHdhc24ndCBhcm91bmQgeWV0Lg0KDQpJIHN1cHBvc2UgdGhlIG1vcmUgZ2VuZXJpYyBhcmNo aXRlY3R1cmUgZG9jIGNvdWxkIGJlIGFsdGVyZWQgdG8gY292ZXIgSW9UIGNhc2VzLCBidXQgaXQg bWF5IGJlIHByb2JsZW1hdGljIGZvciB0aGUgb3RoZXIgc3BlY3MgdGhhdCBhcmUgbW9yZSBzcGVj aWZpYy4NCg0KQW5vdGhlciBpc3N1ZSBpcyBJIGFzc3VtZSB0aGUgQ09TRSBiYXNlZCB0b2tlbnMg d2lsbCBoYXZlIGEgZGlmZmVyZW50IHR5cGUgKGVnIGNwb3ApIHRvIGRpZmZlcmVudGlhdGUgYmV0 d2VlbiBqd3QgYW5kIENPU0Ugd2ViIHRva2VucyAod2hhdCBhcmUgd2UgY2FsbGluZyB0aGVtIG5v dz8pLg0KDQpBcyB0aGlzIGdlbmVyYWxpemF0aW9uIGNoYW5nZSBjb3VsZCBiZSBzZWVuIGFzIHN1 YnN0YW50aWFsLCBJIHdvdWxkIGxpa2UgdG8gaGF2ZSB0aGUgY2hhaXJzIGFuZCBBRCBjb21tZW50 LiBJcyB0aGlzIGEgZ29vZCBpZGVhPyAgT3IgaXMgQ09TRSBiZXR0ZXIgdG8gd3JpdGUgdGhlaXIg b3duIHBhcmFsbGVsIGFyY2ggZHJhZnQ/DQoNCkknbSBoYXBweSB0byBiZW5kIHRvIHRoZSB3aWxs IG9mIHRoZSBncm91cChzKSBvbiB0aGlzLg0KDQpQaGlsDQoNCk9uIE5vdiAxOSwgMjAxNSwgYXQg MDE6MTcsIEVyaWsgV2FobHN0csO2bSBuZVh1cyA8ZXJpay53YWhsc3Ryb21AbmV4dXNncm91cC5j b208bWFpbHRvOmVyaWsud2FobHN0cm9tQG5leHVzZ3JvdXAuY29tPj4gd3JvdGU6DQoNCkhpLA0K DQpJIGhhdmUgYmVlbiByZXZpZXdpbmcgZHJhZnQtaWV0Zi1vYXV0aC1wb3AtYXJjaGl0ZWN0dXJl LTA1LiBJbiBBQ0UgV0cgd2UgaGF2ZSBhIGRyYWZ0IHRoYXQgdXNlcyBQb1AgdG9rZW5zIGZvciBJ b1QgYW5kIHRoZSBhcmNoaXRlY3R1cmVzIGRlZmluZWQgaGVyZSBzbyBteSByZXZpZXcgd2FzIGRv bmUgd2l0aCB0aGF0IElvVCBwZXJzcGVjdGl2ZS4gSeKAmW0gYSBiaXQgbGF0ZSB3aXRoIHRoZSBy ZXZpZXcgYW5kIHNvbWUgb2YgdGhlIGNvbW1lbnRzIG1pZ2h0IGFscmVhZHkgYmUgbWVudGlvbmVk IGJ5IG90aGVycy4NCg0KDQoNCuKAlOKAlOKAlOKAlOKAlOKAlA0KDQozLjEuIFByZXZlbnRpbmcg QWNjZXNzIFRva2VuIFJlLVVzZSBieSB0aGUgUmVzb3VyY2UgU2VydmVyDQoNCklmIGEgc3ltbWV0 cmljIGtleSBpcyB1c2VkIGl04oCZcyBwb3NzaWJsZSB0byByZS11c2UgdGhlIGtleSBmb3IgYSBy ZXNvdXJjZSBzZXJ2ZXIuIFRoZSBzZWN0aW9uIHRhbGtzIGFib3V0IHRoZSBpbXBvcnRhbmNlIG9m IHNjb3BlcywgYnV0IEkgZmVlbCBpdCBzaG91bGQgYWxzbyBtZW50aW9uIHRoZSBpbXBvcnRhbmNl IGZvciB0aGUgcmVzb3VyY2Ugc2VydmVyIHRvIHZlcmlmeSB0aGUgYXVkaWVuY2UgKOKAnGF1ZOKA nSkgY2xhaW0gaW4gdGhlIHRva2VuIHRvIGRpc2FibGUgbWlzc3VzZS4NCg0K4oCU4oCU4oCU4oCU 4oCU4oCUDQoNClRoZSBkcmFmdCBpbiBBQ0UgV0cgKGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1zZWl0ei1hY2Utb2F1dGgtYXV0aHotMDApIHJlbGllcyBoZWF2aWx5IG9uIHRoaXMg d29yay4gVGhlIG1haW4gcmVhc29uIGZvciB0aGlzIGlzIHRoZSB3YXkgUG9QIHRva2VucyBjYW4g ZXN0YWJsaXNoIGtleSBtYXRlcmlhbCwgd2l0aCB0aGUgaGVscCBvZiB0aGUgYXV0aG9yaXphdGlv biBzZXJ2ZXIsIG9uIGJvdGggdGhlIGNsaWVudCBhbmQgcmVzb3VyY2Ugc2VydmVyLiBQb1AgdG9r ZW5zIGlzIGFsc28gYSB2ZXJ5IGdvb2QgZml0IGZvciBjb25zdHJhaW5lZCBJb1QgZGV2aWNlcyB0 aGF0IGNhbiBiZSBvZmZsaW5lIGFuZCBpdOKAmXMgYWxzbyBwb3NzaWJsZSB0byB1c2UgaGFyZHdh cmUga2V5IHN0b3JhZ2VzIHRvIGhhbmRsZSBhc3ltbWV0cmljIHBvcCBrZXlzLg0KDQpUaGVyZSBj b3VsZCBiZSBhIHBsYWNlIGZvciBhIG5ldyAiVXNlIENhc2UiIHVuZGVyIHNlY3Rpb24gMyB0aGF0 IHRhbGtzIGFib3V0IHNjZW5hcmlvcyB3aGVyZSBQb1Aga2V5cyBhcmUgYSByZWFsbHkgZ29vZCBt YXRjaCBmb3Igb2ZmbGluZSBJb1QgZGV2aWNlcy4gSSBjb3VsZCBoZWxwIG91dCBpcm9uaW5nIG91 dCBhIHRleHQgZm9yIHRoYXQgd2l0aCB0aGUgaGVscCBvZiB0aGUgZG9jcyBhdXRob3JzIGlmIHRo YXTigJlzIG9mIGludGVyZXN0Lg0KDQrigJTigJTigJQNCg0Kcy9hIGJvZ3VzIHRva2Vucy9hIGJv Z3VzIHRva2VuDQoNCuKAlOKAlA0KDQpJbiB0aGUgZG9jdW1lbnQgb25seSByZWZlcmVuY2VzIGFy ZSBtYWRlIHRvIEpTT04sIEpXVCBhbmQgSk9TRS4gTW9yZSBleGFjdGx5IGluIHRoZSBmb2xsb3dp bmcgdHdvIHNlY3Rpb25zOg0KDQoNCiAgIEEgbnVtYmVyIG9mIHRoZSB0aHJlYXRzIGxpc3RlZCBp biBTZWN0aW9uIDQ8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgt cG9wLWFyY2hpdGVjdHVyZS0wNSNzZWN0aW9uLTQ+IGRlbWFuZCBwcm90ZWN0aW9uIG9mIHRoZQ0K ICAgYWNjZXNzIHRva2VuIGNvbnRlbnQgYW5kIGEgc3RhbmRhcmRpemVkIHNvbHV0aW9uLCBpbiBm b3JtIG9mIGEgSlNPTi0NCiAgIGJhc2VkIGZvcm1hdCwgaXMgYXZhaWxhYmxlIHdpdGggdGhlIEpX VCBbUkZDNzUxOTxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzUxOT5dLg0KDQoNCg0K DQogICBXaXRoIHRoZSBKU09OIFdlYiBUb2tlbiAoSldUKSBbUkZDNzUxOTxodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvcmZjNzUxOT5dIGEgc3RhbmRhcmRpemVkIGZvcm1hdCBmb3INCiAgIGFj Y2VzcyB0b2tlbnMgaXMgYXZhaWxhYmxlLiAgVGhlIG5lY2Vzc2FyeSBlbGVtZW50cyB0byBiaW5k IHN5bW1ldHJpYw0KICAgb3IgYXN5bW1ldHJpYyBrZXlzIHRvIGEgSldUIGFyZSBkZXNjcmliZWQg aW4NCiAgIFtJLUQuaWV0Zi1vYXV0aC1wcm9vZi1vZi1wb3NzZXNzaW9uPGh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLXBvcC1hcmNoaXRlY3R1cmUtMDUjcmVmLUkt RC5pZXRmLW9hdXRoLXByb29mLW9mLXBvc3Nlc3Npb24+XS4NCg0KDQpDb25zdHJhaW5lZCBJb1Qg ZGV2aWNlcyB1c2VzIG90aGVyIGFjY2VzcyB0b2tlbiBhbmQgbWVzc2FnZXMgZm9ybWF0cyAoYWNj b3JkaW5nIHRvIG91ciBkcmFmdCkuIEl0IGRvZXMgbm90IG9ubHkgdXNlIHNpZ25lZC9lbmNyeXB0 ZWQgSldU4oCZcyBidXQgYWxzbyBDT1NFIHByb3RlY3RlZCBDQk9SIFdlYiBUb2tlbnMuIFNlZSBo dHRwczovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LXdhaGxzdHJvZW0tb2F1dGgtY2Jvci13ZWIt dG9rZW4tMDAudHh0DQoNCkkgdG90YWxseSBhZ3JlZSB0aGF0IEpXVCBpcyB0aGUgY29ycmVjdCBl eGFtcGxlcyB0byBoYXZlIGluIHRoaXMgZG9jdW1lbnQgZHVlIHRvIHRoZSBmYWN0IHRoYXQgdGhl eSBhcmUgUkZD4oCZcywgdGhleSBhcmUgd2VsbCBrbm93biBhbmQgc2hvdWxkIGJlIHVzZWQgaW4g YXMgbWFueSBwbGFjZXMgYXMgcG9zc2libGUsIGJ1dCBpdCB3b3VsZCBiZSBnb29kIHRvIG9wZW4g dXAgZm9yIG90aGVyIHR5cGVzIG9mIG1lc3NhZ2UgZm9ybWF0cy4gRm9yIGV4YW1wbGUgbGlrZSB0 aGlzOg0KDQoNCg0KICAgQSBudW1iZXIgb2YgdGhlIHRocmVhdHMgbGlzdGVkIGluIFNlY3Rpb24g NDxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1wb3AtYXJjaGl0 ZWN0dXJlLTA1I3NlY3Rpb24tND4gZGVtYW5kIHByb3RlY3Rpb24gb2YgdGhlDQogICBhY2Nlc3Mg dG9rZW4gY29udGVudCBhbmQgYSBzdGFuZGFyZGl6ZWQgc29sdXRpb24gaW4gZm9ybSBvZiwgZm9y IGV4YW1wbGUsIGEgSlNPTi0NCiAgIGJhc2VkIGZvcm1hdCwgaXMgYXZhaWxhYmxlIHdpdGggdGhl IEpXVCBbUkZDNzUxOTxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzUxOT5dLg0KDQoN Cg0K4oCU4oCUDQoNCg0KIEZvciB0aGF0DQogICBwdXJwb3NlIHRoZSBjbGllbnQgd2lsbCBoYXZl IHRvIGF1dGhlbnRpY2F0ZSB0aGUgcmVzb3VyY2Ugc2VydmVyDQogICBiZWZvcmUgdHJhbnNtaXR0 aW5nIHRoZSBhY2Nlc3MgdG9rZW4uDQoNCg0KDQpJ4oCZbSBtaXNzaW5nIGEgZGVzY3JpcHRpb24g YWJvdXQgaG93IHRoaXMgaXMgaGFuZGxlZCBpbiBhbiBlbmQtdG8tZW5kIHNlY3VyaXR5IHNjZW5h cmlvLg0KDQrigJTigJTigJQNCg0KDQogICAgICBUaGUgcmVzb3VyY2Ugc2VydmVyIHF1ZXJpZXMg dGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGZvciB0aGUNCiAgICAgIHN5bW1ldHJpYyBrZXkuICBU aGlzIGlzIGFuIGFwcHJvYWNoIGVudmlzaW9uZWQgYnkgdGhlIHRva2VuDQogICAgICBpbnRyb3Nw ZWN0aW9uIGVuZHBvaW50IFtJLUQuaWV0Zi1vYXV0aC1pbnRyb3NwZWN0aW9uPGh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLXBvcC1hcmNoaXRlY3R1cmUtMDUjcmVm LUktRC5pZXRmLW9hdXRoLWludHJvc3BlY3Rpb24+XS4NCg0KDQoNCk5vdCBhIHF1ZXN0aW9uIGZv ciB0aGlzIGRyYWZ0IG1heWJlLCBidXQgaW4gd2hhdCBkcmFmdCBpcyB0aGUgaW50cm9zcGVjdGlv biByZXNwb25zZSBjbGFpbSBkZWZpbmVkPyBJdOKAmXMgbm90IGRlZmluZWQgaW4gaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL3JmYzc2NjIjc2VjdGlvbi0yLjIgYW5kIEkgZG9u4oCZdCBrbm93 IGluIHdoYXQgb3RoZXIgZHJhZnQgaXQgY2FuIGJlIGRlZmluZWQuDQoNCuKAlOKAlA0KDQpJbiBB Q0UgV0cgdGhlIGRyYWZ0IHNlaXR6LWFjZS1vYXV0aC1hdXRoeiBoYXZlIGEgcHJvZmlsZSBmb3Ig YW4gYWNjZXNzIHJlcXVlc3QgdG8gbWFrZSBpdCB3b3JrIG92ZXIgQ29BUC4gQ29BUCBpcyB0aGUg SFRUUCBlcXVpdmFsZW50IGZvciBjb25zdHJhaW5lZCBkZXZpY2VzLCBhbmQgaXQgaGFzIGxpbWl0 YXRpb25zLCBmb3IgZXhhbXBsZSBpdCBjYW7igJl0IHNlbmQgbGFyZ2UgdG9rZW5zIGluIG9wdGlv bnMgKGhlYWRlcnMgaW4gImh0dHAtc3BlYWsiKS4gVGhpcyBtZWFucyB0aGF0IHRoZSBkcmFmdCBk ZWZpbmVzIGEgd2F5IHRvIGZpcnN0IHNlbmQgdGhlIFBvUCB0b2tlbiB0byBhbiBuZXcgZW5kcG9p bnQgb24gdGhlIHJlc291cmNlIHNlcnZlciB0byBlc3RhYmxpc2ggYSBzZWN1cml0eSBjb250ZXh0 LiBUaGVuIHRoZSByZWFsIHJlcXVlc3QgYWdhaW5zdCB0aGUgcmVzb3VyY2Ugc2VydmVyIGNhbiBi ZSBkb25lIG9uY2UgdGhlIHNlY3VyaXR5IGNvbnRleHQgaXMgZXN0YWJsaXNoZWQuIFNlZSBtb3Jl IGRldGFpbHMgaGVyZSBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc2VpdHotYWNl LW9hdXRoLWF1dGh6LTAwI3NlY3Rpb24tNS4yLg0KDQpBbiBvcGVuIHF1ZXN0aW9uOyBzaG91bGQg YSBmbG93IGxpa2UgdGhhdCBiZSBhZGRlZCB0byB0aGUgYXJjaGl0ZWN0dXJlIHNlY3Rpb24/IFRo YXQgbWVhbnMgYSBuZXcgc2VjdGlvbiA3LjUuDQoNCuKAlOKAlA0KDQpUaGFua3MgZm9yIHdyaXRp bmcgdGhpcy4gSSB0aGluayBpdOKAmXMgdmVyeSBpbXBvcnRhbnQgd29yay4NCg0KLyBFcmlrDQoN Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRo IG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQo= --_000_2DC07A54BA8048EE9CC37BDE4CAA0AD7nexusgroupcom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KRmFpciBlbm91Z2guIFdhcyB3YXkg dG8gbGF0ZSB0byB0aGUgZ2FtZSBoZXJlLiBBbGwgYW5kIGFsbCwgaXTigJlzIGEgdmVyeSBnb29k IGRvY3VtZW50Lg0KPGRpdiBjbGFzcz0iIj4vIEVyaWs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJy IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8ZGl2Pg0KPGJsb2NrcXVv dGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIDE5IE5vdiAyMDE1LCBh dCAxOToxOCwgSnVzdGluIFJpY2hlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpyaWNoZXJATUlULkVE VSIgY2xhc3M9IiI+anJpY2hlckBNSVQuRURVPC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8YnIgY2xh c3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xh c3M9IiI+DQo8ZGl2IGNsYXNzPSIiPkkgYWdyZWUgd2l0aCBhZGRlZCAmcXVvdDtGb3IgZXhhbXBs ZSZxdW90OyBpbiBhIGZldyBwbGFjZXMuIEl0J3Mgbm90IG5vcm1hdGl2ZSBpdCdzIGluZm9ybWF0 aW9uYWwgaGVyZS4mbmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48 YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgaWQ9ImNvbXBvc2VyX3NpZ25hdHVyZSIgY2xhc3M9 IiI+DQo8ZGl2IGNsYXNzPSIiPiZsdDsgZGl2PSZxdW90OyZxdW90OyZndDsNCjxkaXYgY2xhc3M9 IiI+DQo8ZGl2IGNsYXNzPSIiPi0tIEp1c3RpbjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xh c3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+LyBTZW50IGZyb20gbXkgcGhvbmUgLzwvZGl2 Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjwvZGl2Pg0KPC9kaXY+DQombHQ7Jmd0OzwvZGl2Pg0K PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KLS0tLS0tLS0gT3JpZ2luYWwgbWVzc2FnZSAt LS0tLS0tLTxiciBjbGFzcz0iIj4NCkZyb206IFBoaWwgSHVudCAmbHQ7PGEgaHJlZj0ibWFpbHRv OnBoaWwuaHVudEBvcmFjbGUuY29tIiBjbGFzcz0iIj5waGlsLmh1bnRAb3JhY2xlLmNvbTwvYT4m Z3Q7DQo8YnIgY2xhc3M9IiI+DQpEYXRlOiAxMS8xOS8yMDE1IDExOjI4IEFNIChHTVQtMDY6MDAp IDxiciBjbGFzcz0iIj4NClRvOiBFcmlrIFdhaGxzdHLDtm0gbmVYdXMgJmx0OzxhIGhyZWY9Im1h aWx0bzplcmlrLndhaGxzdHJvbUBuZXh1c2dyb3VwLmNvbSIgY2xhc3M9IiI+ZXJpay53YWhsc3Ry b21AbmV4dXNncm91cC5jb208L2E+Jmd0Ow0KPGJyIGNsYXNzPSIiPg0KQ2M6ICZxdW90OyZsdDs8 YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciIGNsYXNzPSIiPm9hdXRoQGlldGYub3JnPC9h PiZndDsmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyIgY2xhc3M9IiI+ b2F1dGhAaWV0Zi5vcmc8L2E+Jmd0OywgSnVzdGluIFJpY2hlciAmbHQ7PGEgaHJlZj0ibWFpbHRv OmlldGZAanVzdGluLnJpY2hlci5vcmciIGNsYXNzPSIiPmlldGZAanVzdGluLnJpY2hlci5vcmc8 L2E+Jmd0Ow0KPGJyIGNsYXNzPSIiPg0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gQSByZXZpZXcg b2YgZHJhZnQtaWV0Zi1vYXV0aC1wb3AtYXJjaGl0ZWN0dXJlLTA1IDxiciBjbGFzcz0iIj4NCjxi ciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+SSB0aGluayB5b3VyIHBvaW50IHRoYXQgbWF5YmUg dGhlIGFyY2hpdGVjdHVyZSBkb2MgYmUgZ2VuZXJpYyBlbm91Z2ggdG8gc3VwcG9ydCBib3RoIGpz b24gYW5kIGNib3IgdG9rZW5zIGlzIHdvcnRoIGNvbnNpZGVyYXRpb24uJm5ic3A7PC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5JIGFtIGp1 c3Qgbm90IHN1cmUgb2YgcHJvY2VzcyBhbmQgY29uc2Vuc3VzIG5vdyB0aGF0IHdlIGFyZSBwYXN0 IFdHTEMuIFdvdWxkIHRoZSBjb3NlIGdyb3VwIHByZWZlciB0aGlzPzwvZGl2Pg0KPGRpdiBjbGFz cz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+SGFwcHkgdG8gZG8gaXQg aWYgZGVzaXJlZC4gQWxzbyB1bmRlcnN0YW5kIGlmIHdlIGFyZSB0b28gZmFyIGRvd24gdGhlIHJv YWQuJm5ic3A7PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KUGhpbDwvZGl2Pg0KPGRpdiBj bGFzcz0iIj48YnIgY2xhc3M9IiI+DQpPbiBOb3YgMTksIDIwMTUsIGF0IDA4OjM5LCBFcmlrIFdh aGxzdHLDtm0gbmVYdXMgJmx0OzxhIGhyZWY9Im1haWx0bzplcmlrLndhaGxzdHJvbUBuZXh1c2dy b3VwLmNvbSIgY2xhc3M9IiI+ZXJpay53YWhsc3Ryb21AbmV4dXNncm91cC5jb208L2E+Jmd0OyB3 cm90ZTo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHR5 cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+SnVzdCBh IG5vdGUgdGhlbi4gSSBkaWQgbm90IHNlZSBhbnl0aGluZyB0aGF0IHByb2hpYml0ZWQgdGhlIHVz YWdlIG9mIHBvcCB0b2tlbnMgZm9yIElvVCBzbyAmbmJzcDtzaGlwcGluZyBpdCBhcyBpcyB3b3Jr cy48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpTZW50IGZyb20gbXkgaVBob25lPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCk9uIDE5IE5vdiAyMDE1LCBhdCAxNzoxOCwg UGhpbCBIdW50ICZsdDs8YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iIGNsYXNz PSIiPnBoaWwuaHVudEBvcmFjbGUuY29tPC9hPiZndDsgd3JvdGU6PGJyIGNsYXNzPSIiPg0KPGJy IGNsYXNzPSIiPg0KPC9kaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxk aXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIHRoZSBzdWJqZWN0IG9mIG1ha2luZyB0aGUg c3BlYyhzKSBsZXNzIEpXVCBzcGVjaWZpYywgaXQgd2FzIGEgZm91bmRhdGlvbmFsIGFzc3VtcHRp b24gYW5kIChJIHRoaW5rKSBpbiB0aGUgY2hhcnRlci4gSG93ZXZlciBDT1NFIHdhc24ndCBhcm91 bmQgeWV0LiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4N CjxkaXYgY2xhc3M9IiI+SSBzdXBwb3NlIHRoZSBtb3JlIGdlbmVyaWMgYXJjaGl0ZWN0dXJlIGRv YyBjb3VsZCBiZSBhbHRlcmVkIHRvIGNvdmVyIElvVCBjYXNlcywgYnV0IGl0IG1heSBiZSBwcm9i bGVtYXRpYyBmb3IgdGhlIG90aGVyIHNwZWNzIHRoYXQgYXJlIG1vcmUgc3BlY2lmaWMuJm5ic3A7 PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij5Bbm90aGVyIGlzc3VlIGlzIEkgYXNzdW1lIHRoZSBDT1NFIGJhc2VkIHRva2VucyB3aWxsIGhh dmUgYSBkaWZmZXJlbnQgdHlwZSAoZWcgY3BvcCkgdG8gZGlmZmVyZW50aWF0ZSBiZXR3ZWVuIGp3 dCBhbmQgQ09TRSB3ZWIgdG9rZW5zICh3aGF0IGFyZSB3ZSBjYWxsaW5nIHRoZW0gbm93PykuJm5i c3A7PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj5BcyB0aGlzIGdlbmVyYWxpemF0aW9uIGNoYW5nZSBjb3VsZCBiZSBzZWVuIGFzIHN1YnN0 YW50aWFsLCBJIHdvdWxkIGxpa2UgdG8gaGF2ZSB0aGUgY2hhaXJzIGFuZCBBRCBjb21tZW50LiBJ cyB0aGlzIGEgZ29vZCBpZGVhPyAmbmJzcDtPciBpcyBDT1NFIGJldHRlciB0byB3cml0ZSB0aGVp ciBvd24gcGFyYWxsZWwgYXJjaCBkcmFmdD88L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNz PSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkknbSBoYXBweSB0byBiZW5kIHRvIHRoZSB3aWxs IG9mIHRoZSBncm91cChzKSBvbiB0aGlzLiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIg Y2xhc3M9IiI+DQpQaGlsPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCk9uIE5v diAxOSwgMjAxNSwgYXQgMDE6MTcsIEVyaWsgV2FobHN0csO2bSBuZVh1cyAmbHQ7PGEgaHJlZj0i bWFpbHRvOmVyaWsud2FobHN0cm9tQG5leHVzZ3JvdXAuY29tIiBjbGFzcz0iIj5lcmlrLndhaGxz dHJvbUBuZXh1c2dyb3VwLmNvbTwvYT4mZ3Q7IHdyb3RlOjxiciBjbGFzcz0iIj4NCjxiciBjbGFz cz0iIj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNs YXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+SGksJm5ic3A7PC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5JIGhhdmUg YmVlbiByZXZpZXdpbmcmbmJzcDtkcmFmdC1pZXRmLW9hdXRoLXBvcC1hcmNoaXRlY3R1cmUtMDUu IEluIEFDRSBXRyB3ZSBoYXZlIGEgZHJhZnQgdGhhdCB1c2VzIFBvUCB0b2tlbnMgZm9yIElvVCBh bmQgdGhlIGFyY2hpdGVjdHVyZXMgZGVmaW5lZCBoZXJlIHNvIG15IHJldmlldyB3YXMgZG9uZSB3 aXRoIHRoYXQgSW9UIHBlcnNwZWN0aXZlLiBJ4oCZbSBhIGJpdCBsYXRlIHdpdGggdGhlIHJldmll dyBhbmQgc29tZSBvZiB0aGUNCiBjb21tZW50cyBtaWdodCBhbHJlYWR5IGJlIG1lbnRpb25lZCBi eSBvdGhlcnMuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRp diBjbGFzcz0iIj4mbmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPuKAlOKAlOKAlOKAlOKAlOKAlDwvZGl2Pg0KPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KMy4xLiBQcmV2ZW50aW5nIEFjY2VzcyBU b2tlbiBSZS1Vc2UgYnkgdGhlIFJlc291cmNlIFNlcnZlcg0KPGRpdiBjbGFzcz0iIj48YnIgY2xh c3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+SWYgYSBzeW1tZXRyaWMga2V5IGlzIHVzZWQg aXTigJlzIHBvc3NpYmxlIHRvIHJlLXVzZSB0aGUga2V5IGZvciBhIHJlc291cmNlIHNlcnZlci4g VGhlIHNlY3Rpb24gdGFsa3MgYWJvdXQgdGhlIGltcG9ydGFuY2Ugb2Ygc2NvcGVzLCBidXQgSSBm ZWVsIGl0IHNob3VsZCBhbHNvIG1lbnRpb24gdGhlIGltcG9ydGFuY2UgZm9yIHRoZSByZXNvdXJj ZSBzZXJ2ZXIgdG8gdmVyaWZ5IHRoZSBhdWRpZW5jZSAo4oCcYXVk4oCdKSBjbGFpbSBpbg0KIHRo ZSB0b2tlbiB0byBkaXNhYmxlIG1pc3N1c2UuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0K PGRpdiBjbGFzcz0iIj7igJTigJTigJTigJTigJTigJQ8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJy IGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlRoZSBkcmFmdCBpbiBBQ0UgV0cgKDxh IGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zZWl0ei1hY2Utb2F1dGgt YXV0aHotMDAiIGNsYXNzPSIiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zZWl0 ei1hY2Utb2F1dGgtYXV0aHotMDA8L2E+KSByZWxpZXMgaGVhdmlseSBvbiB0aGlzIHdvcmsuIFRo ZSBtYWluIHJlYXNvbiBmb3IgdGhpcyBpcyB0aGUgd2F5IFBvUCB0b2tlbnMgY2FuDQogZXN0YWJs aXNoIGtleSBtYXRlcmlhbCwgd2l0aCB0aGUgaGVscCBvZiB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2 ZXIsIG9uIGJvdGggdGhlIGNsaWVudCBhbmQgcmVzb3VyY2Ugc2VydmVyLiBQb1AgdG9rZW5zIGlz IGFsc28gYSB2ZXJ5IGdvb2QgZml0IGZvciBjb25zdHJhaW5lZCBJb1QgZGV2aWNlcyB0aGF0IGNh biBiZSBvZmZsaW5lIGFuZCBpdOKAmXMgYWxzbyBwb3NzaWJsZSB0byB1c2UgaGFyZHdhcmUga2V5 IHN0b3JhZ2VzIHRvIGhhbmRsZSBhc3ltbWV0cmljDQogcG9wIGtleXMuPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5UaGVyZSBjb3VsZCBi ZSBhIHBsYWNlIGZvciBhIG5ldyAmcXVvdDtVc2UgQ2FzZSZxdW90OyB1bmRlciBzZWN0aW9uIDMg dGhhdCB0YWxrcyBhYm91dCBzY2VuYXJpb3Mgd2hlcmUgUG9QIGtleXMgYXJlIGEgcmVhbGx5IGdv b2QgbWF0Y2ggZm9yIG9mZmxpbmUgSW9UIGRldmljZXMuIEkgY291bGQgaGVscCBvdXQgaXJvbmlu ZyBvdXQgYSB0ZXh0IGZvciB0aGF0IHdpdGggdGhlIGhlbHAgb2YgdGhlIGRvY3MgYXV0aG9ycyBp ZiB0aGF04oCZcyBvZg0KIGludGVyZXN0LiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIg Y2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+4oCU4oCU4oCUPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5zL2EgYm9ndXMgdG9r ZW5zL2EgYm9ndXMgdG9rZW48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPuKAlOKAlDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9 IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+SW4gdGhlIGRvY3VtZW50IG9ubHkgcmVmZXJlbmNl cyBhcmUgbWFkZSB0byBKU09OLCBKV1QgYW5kIEpPU0UuIE1vcmUgZXhhY3RseSBpbiB0aGUgZm9s bG93aW5nIHR3byBzZWN0aW9uczo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0K PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPHByZSBjbGFzcz0ibmV3cGFnZSIgc3R5bGU9ImZvbnQt c2l6ZTogMTMuMzMzM3B4OyBtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0b206IDBweDsgcGFn ZS1icmVhay1iZWZvcmU6IGFsd2F5czsgd2lkb3dzOiAxOyI+ICAgQSBudW1iZXIgb2YgdGhlIHRo cmVhdHMgbGlzdGVkIGluIDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1pZXRmLW9hdXRoLXBvcC1hcmNoaXRlY3R1cmUtMDUjc2VjdGlvbi00IiBjbGFzcz0iIj5TZWN0 aW9uIDQ8L2E+IGRlbWFuZCBwcm90ZWN0aW9uIG9mIHRoZQ0KICAgYWNjZXNzIHRva2VuIGNvbnRl bnQgYW5kIGEgc3RhbmRhcmRpemVkIHNvbHV0aW9uLCBpbiBmb3JtIG9mIGEgSlNPTi0NCiAgIGJh c2VkIGZvcm1hdCwgaXMgYXZhaWxhYmxlIHdpdGggdGhlIEpXVCBbPGEgaHJlZj0iaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL3JmYzc1MTkiIHRpdGxlPSImcXVvdDtKU09OIFdlYiBUb2tlbiAo SldUKSZxdW90OyIgY2xhc3M9IiI+UkZDNzUxOTwvYT5dLg0KPC9wcmU+DQo8L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0i Ij4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8cHJlIGNsYXNzPSJu ZXdwYWdlIiBzdHlsZT0iZm9udC1zaXplOiAxMy4zMzMzcHg7IG1hcmdpbi10b3A6IDBweDsgbWFy Z2luLWJvdHRvbTogMHB4OyBwYWdlLWJyZWFrLWJlZm9yZTogYWx3YXlzOyB3aWRvd3M6IDE7Ij4g ICBXaXRoIHRoZSBKU09OIFdlYiBUb2tlbiAoSldUKSBbPGEgaHJlZj0iaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL3JmYzc1MTkiIHRpdGxlPSImcXVvdDtKU09OIFdlYiBUb2tlbiAoSldUKSZx dW90OyIgY2xhc3M9IiI+UkZDNzUxOTwvYT5dIGEgc3RhbmRhcmRpemVkIGZvcm1hdCBmb3INCiAg IGFjY2VzcyB0b2tlbnMgaXMgYXZhaWxhYmxlLiAgVGhlIG5lY2Vzc2FyeSBlbGVtZW50cyB0byBi aW5kIHN5bW1ldHJpYw0KICAgb3IgYXN5bW1ldHJpYyBrZXlzIHRvIGEgSldUIGFyZSBkZXNjcmli ZWQgaW4NCiAgIFs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0 Zi1vYXV0aC1wb3AtYXJjaGl0ZWN0dXJlLTA1I3JlZi1JLUQuaWV0Zi1vYXV0aC1wcm9vZi1vZi1w b3NzZXNzaW9uIiBjbGFzcz0iIj5JLUQuaWV0Zi1vYXV0aC1wcm9vZi1vZi1wb3NzZXNzaW9uPC9h Pl0uDQo8L3ByZT4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5Db25zdHJhaW5lZCBJb1QgZGV2aWNlcyB1c2VzIG90aGVy IGFjY2VzcyB0b2tlbiBhbmQgbWVzc2FnZXMgZm9ybWF0cyAoYWNjb3JkaW5nIHRvIG91ciBkcmFm dCkuIEl0IGRvZXMgbm90IG9ubHkgdXNlIHNpZ25lZC9lbmNyeXB0ZWQgSldU4oCZcyBidXQgYWxz byBDT1NFIHByb3RlY3RlZCBDQk9SIFdlYiBUb2tlbnMuIFNlZSZuYnNwOzxhIGhyZWY9Imh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtd2FobHN0cm9lbS1vYXV0aC1jYm9yLXdlYi10b2tl bi0wMC50eHQiIGNsYXNzPSIiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtd2FobHN0 cm9lbS1vYXV0aC1jYm9yLXdlYi10b2tlbi0wMC50eHQ8L2E+PC9kaXY+DQo8ZGl2IGNsYXNzPSIi PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5JIHRvdGFsbHkgYWdyZWUgdGhh dCBKV1QgaXMgdGhlIGNvcnJlY3QgZXhhbXBsZXMgdG8gaGF2ZSBpbiB0aGlzIGRvY3VtZW50IGR1 ZSB0byB0aGUgZmFjdCB0aGF0IHRoZXkgYXJlIFJGQ+KAmXMsIHRoZXkgYXJlIHdlbGwga25vd24g YW5kIHNob3VsZCBiZSB1c2VkIGluIGFzIG1hbnkgcGxhY2VzIGFzIHBvc3NpYmxlLCBidXQgaXQg d291bGQgYmUgZ29vZCB0byBvcGVuIHVwIGZvciBvdGhlciB0eXBlcyBvZiBtZXNzYWdlIGZvcm1h dHMuDQogRm9yIGV4YW1wbGUgbGlrZSB0aGlzOjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xh c3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPg0KPHByZSBjbGFzcz0ibmV3cGFnZSIgc3R5bGU9ImZvbnQtc2l6ZTogMTMuMzMz M3B4OyBtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0b206IDBweDsgcGFnZS1icmVhay1iZWZv cmU6IGFsd2F5czsgd2lkb3dzOiAxOyI+ICAgQSBudW1iZXIgb2YgdGhlIHRocmVhdHMgbGlzdGVk IGluIDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRo LXBvcC1hcmNoaXRlY3R1cmUtMDUjc2VjdGlvbi00IiBjbGFzcz0iIj5TZWN0aW9uIDQ8L2E+IGRl bWFuZCBwcm90ZWN0aW9uIG9mIHRoZQ0KICAgYWNjZXNzIHRva2VuIGNvbnRlbnQgYW5kIGEgc3Rh bmRhcmRpemVkIHNvbHV0aW9uIGluIGZvcm0gb2YsIDxiIGNsYXNzPSIiPmZvciBleGFtcGxlLDwv Yj4gYSBKU09OLQ0KICAgYmFzZWQgZm9ybWF0LCBpcyBhdmFpbGFibGUgd2l0aCB0aGUgSldUIFs8 YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzUxOSIgdGl0bGU9IiZxdW90 O0pTT04gV2ViIFRva2VuIChKV1QpJnF1b3Q7IiBjbGFzcz0iIj5SRkM3NTE5PC9hPl0uDQo8L3By ZT4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xh c3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPuKAlOKAlDwvZGl2Pg0K PGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2 IGNsYXNzPSIiPg0KPHByZSBjbGFzcz0ibmV3cGFnZSIgc3R5bGU9ImZvbnQtc2l6ZTogMTMuMzMz M3B4OyBtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0b206IDBweDsgcGFnZS1icmVhay1iZWZv cmU6IGFsd2F5czsgd2lkb3dzOiAxOyI+IEZvciB0aGF0DQogICBwdXJwb3NlIHRoZSBjbGllbnQg d2lsbCBoYXZlIHRvIGF1dGhlbnRpY2F0ZSB0aGUgcmVzb3VyY2Ugc2VydmVyDQogICBiZWZvcmUg dHJhbnNtaXR0aW5nIHRoZSBhY2Nlc3MgdG9rZW4uDQo8L3ByZT4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj5J4oCZbSBtaXNzaW5nIGEgZGVzY3JpcHRpb24gYWJvdXQgaG93IHRoaXMgaXMgaGFu ZGxlZCBpbiBhbiBlbmQtdG8tZW5kIHNlY3VyaXR5IHNjZW5hcmlvLjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+4oCU4oCU4oCUPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxw cmUgY2xhc3M9Im5ld3BhZ2UiIHN0eWxlPSJmb250LXNpemU6IDEzLjMzMzNweDsgbWFyZ2luLXRv cDogMHB4OyBtYXJnaW4tYm90dG9tOiAwcHg7IHBhZ2UtYnJlYWstYmVmb3JlOiBhbHdheXM7IHdp ZG93czogMTsiPiAgICAgIFRoZSByZXNvdXJjZSBzZXJ2ZXIgcXVlcmllcyB0aGUgYXV0aG9yaXph dGlvbiBzZXJ2ZXIgZm9yIHRoZQ0KICAgICAgc3ltbWV0cmljIGtleS4gIFRoaXMgaXMgYW4gYXBw cm9hY2ggZW52aXNpb25lZCBieSB0aGUgdG9rZW4NCiAgICAgIGludHJvc3BlY3Rpb24gZW5kcG9p bnQgWzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRo LXBvcC1hcmNoaXRlY3R1cmUtMDUjcmVmLUktRC5pZXRmLW9hdXRoLWludHJvc3BlY3Rpb24iIGNs YXNzPSIiPkktRC5pZXRmLW9hdXRoLWludHJvc3BlY3Rpb248L2E+XS4NCjwvcHJlPg0KPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIg Y2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Tm90IGEgcXVlc3Rpb24gZm9yIHRoaXMg ZHJhZnQgbWF5YmUsIGJ1dCBpbiB3aGF0IGRyYWZ0IGlzIHRoZSBpbnRyb3NwZWN0aW9uIHJlc3Bv bnNlIGNsYWltIGRlZmluZWQ/IEl04oCZcyBub3QgZGVmaW5lZCBpbiZuYnNwOzxhIGhyZWY9Imh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3NjYyI3NlY3Rpb24tMi4yIiBjbGFzcz0iIj5o dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzY2MiNzZWN0aW9uLTIuMjwvYT4mbmJzcDth bmQNCiBJIGRvbuKAmXQga25vdyBpbiB3aGF0IG90aGVyIGRyYWZ0IGl0IGNhbiBiZSBkZWZpbmVk LjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+4oCU4oCUPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRp diBjbGFzcz0iIj5JbiBBQ0UgV0cgdGhlIGRyYWZ0IHNlaXR6LWFjZS1vYXV0aC1hdXRoeiBoYXZl IGEgcHJvZmlsZSBmb3IgYW4gYWNjZXNzIHJlcXVlc3QgdG8gbWFrZSBpdCB3b3JrIG92ZXIgQ29B UC4gQ29BUCBpcyB0aGUgSFRUUCBlcXVpdmFsZW50IGZvciBjb25zdHJhaW5lZCBkZXZpY2VzLCBh bmQgaXQgaGFzIGxpbWl0YXRpb25zLCBmb3IgZXhhbXBsZSBpdCBjYW7igJl0IHNlbmQgbGFyZ2Ug dG9rZW5zIGluIG9wdGlvbnMgKGhlYWRlcnMgaW4NCiAmcXVvdDtodHRwLXNwZWFrJnF1b3Q7KS4g VGhpcyBtZWFucyB0aGF0IHRoZSBkcmFmdCBkZWZpbmVzIGEgd2F5IHRvIGZpcnN0IHNlbmQgdGhl IFBvUCB0b2tlbiB0byBhbiBuZXcgZW5kcG9pbnQgb24gdGhlIHJlc291cmNlIHNlcnZlciB0byBl c3RhYmxpc2ggYSBzZWN1cml0eSBjb250ZXh0LiBUaGVuIHRoZSByZWFsIHJlcXVlc3QgYWdhaW5z dCB0aGUgcmVzb3VyY2Ugc2VydmVyIGNhbiBiZSBkb25lIG9uY2UgdGhlIHNlY3VyaXR5IGNvbnRl eHQgaXMgZXN0YWJsaXNoZWQuDQogU2VlIG1vcmUgZGV0YWlscyBoZXJlJm5ic3A7PGEgaHJlZj0i aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNlaXR6LWFjZS1vYXV0aC1hdXRoei0w MCNzZWN0aW9uLTUuMiIgY2xhc3M9IiI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LXNlaXR6LWFjZS1vYXV0aC1hdXRoei0wMCNzZWN0aW9uLTUuMjwvYT4uPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5BbiBvcGVuIHF1ZXN0 aW9uOyBzaG91bGQgYSBmbG93IGxpa2UgdGhhdCBiZSBhZGRlZCB0byB0aGUgYXJjaGl0ZWN0dXJl IHNlY3Rpb24/IFRoYXQgbWVhbnMgYSBuZXcgc2VjdGlvbiA3LjUuPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj7igJTigJQ8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlRoYW5rcyBm b3Igd3JpdGluZyB0aGlzLiBJIHRoaW5rIGl04oCZcyB2ZXJ5IGltcG9ydGFudCB3b3JrLjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+LyBF cmlrPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+PHNwYW4g Y2xhc3M9IiI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 L3NwYW4+PGJyIGNsYXNzPSIiPg0KPHNwYW4gY2xhc3M9IiI+T0F1dGggbWFpbGluZyBsaXN0PC9z cGFuPjxiciBjbGFzcz0iIj4NCjxzcGFuIGNsYXNzPSIiPjxhIGhyZWY9Im1haWx0bzpPQXV0aEBp ZXRmLm9yZyIgY2xhc3M9IiI+T0F1dGhAaWV0Zi5vcmc8L2E+PC9zcGFuPjxiciBjbGFzcz0iIj4N CjxzcGFuIGNsYXNzPSIiPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vb2F1dGgiIGNsYXNzPSIiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vb2F1dGg8L2E+PC9zcGFuPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_2DC07A54BA8048EE9CC37BDE4CAA0AD7nexusgroupcom_-- From nobody Fri Nov 20 08:27:18 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3287F1B36E2 for ; Fri, 20 Nov 2015 08:27:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 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, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bSVwZyBoJKgU for ; Fri, 20 Nov 2015 08:27:11 -0800 (PST) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::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 AC8F61B36D1 for ; Fri, 20 Nov 2015 08:27:10 -0800 (PST) Received: by wmec201 with SMTP id c201so27893549wme.1 for ; Fri, 20 Nov 2015 08:27:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=pQh+rCw0dJqYQyGodFGbg5gZTqJNKgJLREnU+CGvsEE=; b=aX37yRdQNBqSD6YEvKnW7pUgjed79/+QjZYBA8uYYN2zDaNXIxWLudykvR1ZwENwxD BavY5GQek/ymg9EB9PeM0BAyTc2L60KbzoQ1MMsX8AYDJUHsn75SH4TbNZpNz0n6NsYP QUuq7R6ff7q7O3sSSpADZP05fT0SmfSHb/fEYEMQK21mBALNFfvuQKU9uYWOhXFlGJdt KMcpi0pZ1FbzbmqDcb1dZIxIyopty3VY/YrQZwytJjh8YDeI3v/dMp5sFSyEADUnLyRX FvqWb2oUGX1mzjMbzCxVEeEfRevKevoRNQhNywbdDR1biyEScsiCA+ynJHS3czjvux73 6BTw== MIME-Version: 1.0 X-Received: by 10.194.179.71 with SMTP id de7mr15362019wjc.119.1448036829220; Fri, 20 Nov 2015 08:27:09 -0800 (PST) Received: by 10.28.52.130 with HTTP; Fri, 20 Nov 2015 08:27:09 -0800 (PST) In-Reply-To: <2DC07A54-BA80-48EE-9CC3-7BDE4CAA0AD7@nexusgroup.com> References: <2DC07A54-BA80-48EE-9CC3-7BDE4CAA0AD7@nexusgroup.com> Date: Fri, 20 Nov 2015 11:27:09 -0500 Message-ID: From: Kathleen Moriarty To: =?UTF-8?Q?Erik_Wahlstr=C3=B6m_neXus?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Justin Richer , "" Subject: Re: [OAUTH-WG] A review of draft-ietf-oauth-pop-architecture-05 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2015 16:27:13 -0000 I'm re-reading to make sure this would be okay at this stage and have some suggestions. Could 3.2 cover TLS and DTLS? Then you don't need to state COSE/CBOR specifically in this section but it hints at applicable IoT use cases and isn't a big change since OAuth could be used in scenarios with DTLS and IoT. Since 3.3 refers to a web client, I'd leave it alone. It's just a use case. And I don't think 3.4 is a good example for IoT with discussions of load balancers. In section 4, the client is listed generically without definition, Maybe stating constrained and devices that are not constrained are clients would be enough in the Token manufacture/modification threat scenario? That would be on first use in this section for clients. Section 6.2 calls out 2 examples with TLS, but doesn't restrict the selection to these two, so I think the text there is fine as-is, especially since "available infrastructure" is one of the considerations. I think that would be enough and wouldn't be too much to change at this stage to include IoT under this draft. I would not add in explicit mention of CBOR or COSE as the draft doesn't mention JSON or JOSE anywhere. Does that should like a good approach? This just means 2 minor changes to make the generic text also explicitly include constrained devices. Thanks, Kathleen On Thu, Nov 19, 2015 at 2:29 PM, Erik Wahlstr=C3=B6m neXus wrote: > Fair enough. Was way to late to the game here. All and all, it=E2=80=99s = a very good > document. > / Erik > > > On 19 Nov 2015, at 19:18, Justin Richer wrote: > > I agree with added "For example" in a few places. It's not normative it's > informational here. > > > > < div=3D""> > -- Justin > > / Sent from my phone / > <> > > > -------- Original message -------- > From: Phil Hunt > Date: 11/19/2015 11:28 AM (GMT-06:00) > To: Erik Wahlstr=C3=B6m neXus > Cc: "" , Justin Richer > > Subject: Re: [OAUTH-WG] A review of draft-ietf-oauth-pop-architecture-05 > > I think your point that maybe the architecture doc be generic enough to > support both json and cbor tokens is worth consideration. > > I am just not sure of process and consensus now that we are past WGLC. Wo= uld > the cose group prefer this? > > Happy to do it if desired. Also understand if we are too far down the roa= d. > > Phil > > On Nov 19, 2015, at 08:39, Erik Wahlstr=C3=B6m neXus > wrote: > > Just a note then. I did not see anything that prohibited the usage of pop > tokens for IoT so shipping it as is works. > > Sent from my iPhone > > On 19 Nov 2015, at 17:18, Phil Hunt wrote: > > On the subject of making the spec(s) less JWT specific, it was a > foundational assumption and (I think) in the charter. However COSE wasn't > around yet. > > I suppose the more generic architecture doc could be altered to cover IoT > cases, but it may be problematic for the other specs that are more specif= ic. > > Another issue is I assume the COSE based tokens will have a different typ= e > (eg cpop) to differentiate between jwt and COSE web tokens (what are we > calling them now?). > > As this generalization change could be seen as substantial, I would like = to > have the chairs and AD comment. Is this a good idea? Or is COSE better t= o > write their own parallel arch draft? > > I'm happy to bend to the will of the group(s) on this. > > Phil > > On Nov 19, 2015, at 01:17, Erik Wahlstr=C3=B6m neXus > wrote: > > Hi, > > I have been reviewing draft-ietf-oauth-pop-architecture-05. In ACE WG we > have a draft that uses PoP tokens for IoT and the architectures defined h= ere > so my review was done with that IoT perspective. I=E2=80=99m a bit late w= ith the > review and some of the comments might already be mentioned by others. > > > > =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 > > 3.1. Preventing Access Token Re-Use by the Resource Server > > If a symmetric key is used it=E2=80=99s possible to re-use the key for a = resource > server. The section talks about the importance of scopes, but I feel it > should also mention the importance for the resource server to verify the > audience (=E2=80=9Caud=E2=80=9D) claim in the token to disable missuse. > > =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 > > The draft in ACE WG > (https://tools.ietf.org/html/draft-seitz-ace-oauth-authz-00) relies heavi= ly > on this work. The main reason for this is the way PoP tokens can establis= h > key material, with the help of the authorization server, on both the clie= nt > and resource server. PoP tokens is also a very good fit for constrained I= oT > devices that can be offline and it=E2=80=99s also possible to use hardwar= e key > storages to handle asymmetric pop keys. > > There could be a place for a new "Use Case" under section 3 that talks ab= out > scenarios where PoP keys are a really good match for offline IoT devices.= I > could help out ironing out a text for that with the help of the docs auth= ors > if that=E2=80=99s of interest. > > =E2=80=94=E2=80=94=E2=80=94 > > s/a bogus tokens/a bogus token > > =E2=80=94=E2=80=94 > > In the document only references are made to JSON, JWT and JOSE. More exac= tly > in the following two sections: > > A number of the threats listed in Section 4 demand protection of the > access token content and a standardized solution, in form of a JSON- > based format, is available with the JWT [RFC7519]. > > > > With the JSON Web Token (JWT) [RFC7519] a standardized format for > access tokens is available. The necessary elements to bind symmetric > or asymmetric keys to a JWT are described in > [I-D.ietf-oauth-proof-of-possession]. > > > Constrained IoT devices uses other access token and messages formats > (according to our draft). It does not only use signed/encrypted JWT=E2=80= =99s but > also COSE protected CBOR Web Tokens. See > https://tools.ietf.org/id/draft-wahlstroem-oauth-cbor-web-token-00.txt > > I totally agree that JWT is the correct examples to have in this document > due to the fact that they are RFC=E2=80=99s, they are well known and shou= ld be used > in as many places as possible, but it would be good to open up for other > types of message formats. For example like this: > > > A number of the threats listed in Section 4 demand protection of the > access token content and a standardized solution in form of, for examp= le, > a JSON- > based format, is available with the JWT [RFC7519]. > > > > =E2=80=94=E2=80=94 > > For that > purpose the client will have to authenticate the resource server > before transmitting the access token. > > > > I=E2=80=99m missing a description about how this is handled in an end-to-= end > security scenario. > > =E2=80=94=E2=80=94=E2=80=94 > > The resource server queries the authorization server for the > symmetric key. This is an approach envisioned by the token > introspection endpoint [I-D.ietf-oauth-introspection]. > > > > Not a question for this draft maybe, but in what draft is the introspecti= on > response claim defined? It=E2=80=99s not defined in > https://tools.ietf.org/html/rfc7662#section-2.2 and I don=E2=80=99t know = in what > other draft it can be defined. > > =E2=80=94=E2=80=94 > > In ACE WG the draft seitz-ace-oauth-authz have a profile for an access > request to make it work over CoAP. CoAP is the HTTP equivalent for > constrained devices, and it has limitations, for example it can=E2=80=99t= send large > tokens in options (headers in "http-speak"). This means that the draft > defines a way to first send the PoP token to an new endpoint on the resou= rce > server to establish a security context. Then the real request against the > resource server can be done once the security context is established. See > more details here > https://tools.ietf.org/html/draft-seitz-ace-oauth-authz-00#section-5.2. > > An open question; should a flow like that be added to the architecture > section? That means a new section 7.5. > > =E2=80=94=E2=80=94 > > Thanks for writing this. I think it=E2=80=99s very important work. > > / Erik > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 Best regards, Kathleen From nobody Fri Nov 20 08:37:14 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8C3A1B3879 for ; Fri, 20 Nov 2015 08:37:12 -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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LeCd3Ge807Ca for ; Fri, 20 Nov 2015 08:37:10 -0800 (PST) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::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 3214E1B3865 for ; Fri, 20 Nov 2015 08:36:52 -0800 (PST) Received: by wmww144 with SMTP id w144so28131086wmw.0 for ; Fri, 20 Nov 2015 08:36:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=dkYcSnMl/UrM4hBJXa8gRP8qTMRI0rpqD601GhGkudM=; b=MAB6NCQoIbum0pR8IIRVo1jeysUjswm17YE6tQVJTPRoXZ4Lj2oKFWd324/EU16vZx iQNHXCf4xGKkF8ydtPPqz+5UKCUWBTUhRpPhZqZPXPLu3g63XfEgX/ND1xK+mZLCjDEz wU3fjMxCd4H8MYt5g+0bp8kZ74GrVdZn1l/+ymoUSZr7tqBOAERHJOCSffG70Vc0PtCV 0CM8gnW9sf4G3lBqnIjSCn+Gz4yJrKD3B01FAk0wOe1h1rmiFryenlth3tx4NBbLB6OI Hb/xWrHGNPPz1FuVJ5HNEA+e6cIyS2mj0f9nafDsC5hzqtFZcEAFYIo1Gr36sHYFxDoU m/FQ== MIME-Version: 1.0 X-Received: by 10.194.179.162 with SMTP id dh2mr15628580wjc.17.1448037410677; Fri, 20 Nov 2015 08:36:50 -0800 (PST) Received: by 10.28.52.130 with HTTP; Fri, 20 Nov 2015 08:36:50 -0800 (PST) In-Reply-To: <7028747C-88DD-43BD-B0A4-FDEB7662A208@oracle.com> References: <7028747C-88DD-43BD-B0A4-FDEB7662A208@oracle.com> Date: Fri, 20 Nov 2015 11:36:50 -0500 Message-ID: From: Kathleen Moriarty To: Phil Hunt Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-pop-architecture X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2015 16:37:12 -0000 Hi Phil, Thanks for your response on these questions, a few more comments in-line and we should be able to wrap this up and move it to the next phase quickly. On Wed, Nov 18, 2015 at 4:03 PM, Phil Hunt wrote: > Comments inline. > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > >> On Nov 16, 2015, at 12:37 PM, Kathleen Moriarty wrote: >> >> Hello, >> >> I reviewed draft-ietf-oauth-pop-architecture and have a few questions. >> >> 1. Section 6, Threat Mitigation: >> >> Last sentence of first paragraph, "To >> simplify the subsequent description we assume that the token itself >> is digitally signed by the authorization server and therefore cannot >> be modified." >> >> Since bearer tokens are not signed by default, is this proposing a >> change? If so, where will that change occur? To state that "it is >> assumed" without it being required anywhere is not a good assumption. >> I'd still see this as a risk or security consideration. When OAuth is >> re-used by other protocols, I am seeing that re-use leave off basic >> protections that should be assumed like TLS, let alone digital >> signatures. If this is required in the defined architecture (Section >> 7 - it does show this, but there are no MUSTs that I can find), just >> state that and refer to the requirement. > > [PH] I think the change is the point of the POP specifications. We are ta= lking about a new class of tokens that are specifically not Bearer tokens t= hus the threat mitigation states that POP tokens are assumed to be digitall= y signed. Sure, but that is not spelled out in the requirements section and should be. I think the issue may be that the requirements section just says that the requirements are from RFC4962 and put into OAuth terms. There isn't any text or list that says the following requirements are added for this architecture and I would expect to see that. Can you add that so you will be able to make such assumptions with this architecture going forward and subsequent draft authors would have clear guidance? > > Was that not clear from the introduction? There should be something in the requirements section. The phrasing of this particular sentence could be changed as follows (in addition to adding a requirement): "To simplify the subsequent description we assume in the POP architecture that the token itself is digitally signed by the authorization server and therefore cannot be modified." Or something like: "To simplify the subsequent description we assume in this architecture that the token itself is digitally signed by the authorization server and therefore cannot be modified." The second choice is added only because you don't seem to use the term POP architecture in the draft, but it would be good to make it clear that this draft adds this assumption, it is something new. >> >> 2. Section 6, Threat Mitigation >> >> Third paragraph, "As an example, TLS with a ciphersuite >> that offers confidentiality protection has to be applied (which is >> currently true for all ciphersuites, except for one). >> >> Please list a reference so the reader knows which ciphersuites are >> acceptable from the recommended ones in RFC7525. I don't recall there >> being any MTI ciphersuites for OAuth (I'm pretty sure there aren't and >> that we've discussed that already with previous drafts, so this should >> be spelled out more). > [PH] I think this can be simplified a bit. I think this was referring to = a =E2=80=9CNULL=E2=80=9D ciphersuite which is what 7525 says should not be = done. We should also point to 7525. That would take care of it and would be a minor and clear change. Thank yo= u! >> >> 3. (Nit) Section 6.2, add a comma to improve readability >> From: "Instead of providing confidentiality protection the authorization >> server could also put the identifier of the client into the protected >> token with the following semantic:" >> To: "Instead of providing confidentiality protection, the authorization >> server could also put the identifier of the client into the protected >> token with the following semantic:=E2=80=9D >> > [PH] Will add to the next draft pending your comments on the above items. Thank you! Kathleen > >> Thank you all for your work on this draft! >> -- >> >> Best regards, >> Kathleen >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > --=20 Best regards, Kathleen From nobody Fri Nov 20 09:00:15 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 451B91B3848 for ; Fri, 20 Nov 2015 09:00:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.786 X-Spam-Level: X-Spam-Status: No, score=-4.786 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9mkv8bywnq6j for ; Fri, 20 Nov 2015 09:00:07 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C0BE1B392A for ; Fri, 20 Nov 2015 08:59:57 -0800 (PST) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id tAKGxtx9008521 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 20 Nov 2015 16:59:56 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id tAKGxsmW003699 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 20 Nov 2015 16:59:54 GMT Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by userv0122.oracle.com (8.13.8/8.13.8) with ESMTP id tAKGxsXq013604; Fri, 20 Nov 2015 16:59:54 GMT Received: from [192.168.1.27] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 20 Nov 2015 08:59:54 -0800 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Phil Hunt X-Mailer: iPhone Mail (13B143) In-Reply-To: Date: Fri, 20 Nov 2015 08:59:52 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <807F71A5-3C01-437C-8187-8A4349D7DF46@oracle.com> References: <2DC07A54-BA80-48EE-9CC3-7BDE4CAA0AD7@nexusgroup.com> To: Kathleen Moriarty X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Cc: "" , Justin Richer Subject: Re: [OAUTH-WG] A review of draft-ietf-oauth-pop-architecture-05 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2015 17:00:12 -0000 +1. I will post an update monday.=20 Ps. Did you see my original responses to your first comments? Phil > On Nov 20, 2015, at 08:27, Kathleen Moriarty wrote: >=20 > I'm re-reading to make sure this would be okay at this stage and have > some suggestions. >=20 > Could 3.2 cover TLS and DTLS? Then you don't need to state COSE/CBOR > specifically in this section but it hints at applicable IoT use cases > and isn't a big change since OAuth could be used in scenarios with > DTLS and IoT. >=20 > Since 3.3 refers to a web client, I'd leave it alone. It's just a use > case. And I don't think 3.4 is a good example for IoT with > discussions of load balancers. >=20 > In section 4, the client is listed generically without definition, > Maybe stating constrained and devices that are not constrained are > clients would be enough in the Token manufacture/modification threat > scenario? That would be on first use in this section for clients. >=20 > Section 6.2 calls out 2 examples with TLS, but doesn't restrict the > selection to these two, so I think the text there is fine as-is, > especially since "available infrastructure" is one of the > considerations. >=20 > I think that would be enough and wouldn't be too much to change at > this stage to include IoT under this draft. I would not add in > explicit mention of CBOR or COSE as the draft doesn't mention JSON or > JOSE anywhere. >=20 > Does that should like a good approach? This just means 2 minor > changes to make the generic text also explicitly include constrained > devices. >=20 > Thanks, > Kathleen >=20 >=20 >=20 >=20 >=20 >=20 >=20 > On Thu, Nov 19, 2015 at 2:29 PM, Erik Wahlstr=C3=B6m neXus > wrote: >> Fair enough. Was way to late to the game here. All and all, it=E2=80=99s a= very good >> document. >> / Erik >>=20 >>=20 >> On 19 Nov 2015, at 19:18, Justin Richer wrote: >>=20 >> I agree with added "For example" in a few places. It's not normative it's= >> informational here. >>=20 >>=20 >>=20 >> < div=3D""> >> -- Justin >>=20 >> / Sent from my phone / >> <> >>=20 >>=20 >> -------- Original message -------- >> From: Phil Hunt >> Date: 11/19/2015 11:28 AM (GMT-06:00) >> To: Erik Wahlstr=C3=B6m neXus >> Cc: "" , Justin Richer >> >> Subject: Re: [OAUTH-WG] A review of draft-ietf-oauth-pop-architecture-05 >>=20 >> I think your point that maybe the architecture doc be generic enough to >> support both json and cbor tokens is worth consideration. >>=20 >> I am just not sure of process and consensus now that we are past WGLC. Wo= uld >> the cose group prefer this? >>=20 >> Happy to do it if desired. Also understand if we are too far down the roa= d. >>=20 >> Phil >>=20 >> On Nov 19, 2015, at 08:39, Erik Wahlstr=C3=B6m neXus >> wrote: >>=20 >> Just a note then. I did not see anything that prohibited the usage of pop= >> tokens for IoT so shipping it as is works. >>=20 >> Sent from my iPhone >>=20 >> On 19 Nov 2015, at 17:18, Phil Hunt wrote: >>=20 >> On the subject of making the spec(s) less JWT specific, it was a >> foundational assumption and (I think) in the charter. However COSE wasn't= >> around yet. >>=20 >> I suppose the more generic architecture doc could be altered to cover IoT= >> cases, but it may be problematic for the other specs that are more specif= ic. >>=20 >> Another issue is I assume the COSE based tokens will have a different typ= e >> (eg cpop) to differentiate between jwt and COSE web tokens (what are we >> calling them now?). >>=20 >> As this generalization change could be seen as substantial, I would like t= o >> have the chairs and AD comment. Is this a good idea? Or is COSE better t= o >> write their own parallel arch draft? >>=20 >> I'm happy to bend to the will of the group(s) on this. >>=20 >> Phil >>=20 >> On Nov 19, 2015, at 01:17, Erik Wahlstr=C3=B6m neXus >> wrote: >>=20 >> Hi, >>=20 >> I have been reviewing draft-ietf-oauth-pop-architecture-05. In ACE WG we >> have a draft that uses PoP tokens for IoT and the architectures defined h= ere >> so my review was done with that IoT perspective. I=E2=80=99m a bit late w= ith the >> review and some of the comments might already be mentioned by others. >>=20 >>=20 >>=20 >> =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 >>=20 >> 3.1. Preventing Access Token Re-Use by the Resource Server >>=20 >> If a symmetric key is used it=E2=80=99s possible to re-use the key for a r= esource >> server. The section talks about the importance of scopes, but I feel it >> should also mention the importance for the resource server to verify the >> audience (=E2=80=9Caud=E2=80=9D) claim in the token to disable missuse. >>=20 >> =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 >>=20 >> The draft in ACE WG >> (https://tools.ietf.org/html/draft-seitz-ace-oauth-authz-00) relies heavi= ly >> on this work. The main reason for this is the way PoP tokens can establis= h >> key material, with the help of the authorization server, on both the clie= nt >> and resource server. PoP tokens is also a very good fit for constrained I= oT >> devices that can be offline and it=E2=80=99s also possible to use hardwar= e key >> storages to handle asymmetric pop keys. >>=20 >> There could be a place for a new "Use Case" under section 3 that talks ab= out >> scenarios where PoP keys are a really good match for offline IoT devices.= I >> could help out ironing out a text for that with the help of the docs auth= ors >> if that=E2=80=99s of interest. >>=20 >> =E2=80=94=E2=80=94=E2=80=94 >>=20 >> s/a bogus tokens/a bogus token >>=20 >> =E2=80=94=E2=80=94 >>=20 >> In the document only references are made to JSON, JWT and JOSE. More exac= tly >> in the following two sections: >>=20 >> A number of the threats listed in Section 4 demand protection of the >> access token content and a standardized solution, in form of a JSON- >> based format, is available with the JWT [RFC7519]. >>=20 >>=20 >>=20 >> With the JSON Web Token (JWT) [RFC7519] a standardized format for >> access tokens is available. The necessary elements to bind symmetric >> or asymmetric keys to a JWT are described in >> [I-D.ietf-oauth-proof-of-possession]. >>=20 >>=20 >> Constrained IoT devices uses other access token and messages formats >> (according to our draft). It does not only use signed/encrypted JWT=E2=80= =99s but >> also COSE protected CBOR Web Tokens. See >> https://tools.ietf.org/id/draft-wahlstroem-oauth-cbor-web-token-00.txt >>=20 >> I totally agree that JWT is the correct examples to have in this document= >> due to the fact that they are RFC=E2=80=99s, they are well known and shou= ld be used >> in as many places as possible, but it would be good to open up for other >> types of message formats. For example like this: >>=20 >>=20 >> A number of the threats listed in Section 4 demand protection of the >> access token content and a standardized solution in form of, for exampl= e, >> a JSON- >> based format, is available with the JWT [RFC7519]. >>=20 >>=20 >>=20 >> =E2=80=94=E2=80=94 >>=20 >> For that >> purpose the client will have to authenticate the resource server >> before transmitting the access token. >>=20 >>=20 >>=20 >> I=E2=80=99m missing a description about how this is handled in an end-to-= end >> security scenario. >>=20 >> =E2=80=94=E2=80=94=E2=80=94 >>=20 >> The resource server queries the authorization server for the >> symmetric key. This is an approach envisioned by the token >> introspection endpoint [I-D.ietf-oauth-introspection]. >>=20 >>=20 >>=20 >> Not a question for this draft maybe, but in what draft is the introspecti= on >> response claim defined? It=E2=80=99s not defined in >> https://tools.ietf.org/html/rfc7662#section-2.2 and I don=E2=80=99t know i= n what >> other draft it can be defined. >>=20 >> =E2=80=94=E2=80=94 >>=20 >> In ACE WG the draft seitz-ace-oauth-authz have a profile for an access >> request to make it work over CoAP. CoAP is the HTTP equivalent for >> constrained devices, and it has limitations, for example it can=E2=80=99t= send large >> tokens in options (headers in "http-speak"). This means that the draft >> defines a way to first send the PoP token to an new endpoint on the resou= rce >> server to establish a security context. Then the real request against the= >> resource server can be done once the security context is established. See= >> more details here >> https://tools.ietf.org/html/draft-seitz-ace-oauth-authz-00#section-5.2. >>=20 >> An open question; should a flow like that be added to the architecture >> section? That means a new section 7.5. >>=20 >> =E2=80=94=E2=80=94 >>=20 >> Thanks for writing this. I think it=E2=80=99s very important work. >>=20 >> / Erik >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 >=20 > --=20 >=20 > Best regards, > Kathleen >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Fri Nov 20 09:02:01 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C15861B2C3D for ; Fri, 20 Nov 2015 09:02:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.786 X-Spam-Level: X-Spam-Status: No, score=-4.786 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6WVR8hAh5kIq for ; Fri, 20 Nov 2015 09:01:59 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3B7C1B2C2B for ; Fri, 20 Nov 2015 09:01:58 -0800 (PST) Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id tAKH1v8S028193 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 20 Nov 2015 17:01:57 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id tAKH1vCH019562 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 20 Nov 2015 17:01:57 GMT Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id tAKH1uXU024131; Fri, 20 Nov 2015 17:01:57 GMT Received: from [192.168.1.27] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 20 Nov 2015 09:01:56 -0800 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Phil Hunt X-Mailer: iPhone Mail (13B143) In-Reply-To: Date: Fri, 20 Nov 2015 09:01:54 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <2D3AD473-E2E0-4502-BC79-B3FA2FF7F089@oracle.com> References: <7028747C-88DD-43BD-B0A4-FDEB7662A208@oracle.com> To: Kathleen Moriarty X-Source-IP: aserv0021.oracle.com [141.146.126.233] Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-pop-architecture X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2015 17:02:00 -0000 Looks good. (Sorry I missed this in my earlier message).=20 I will add to Monday's revision.=20 Phil > On Nov 20, 2015, at 08:36, Kathleen Moriarty wrote: >=20 > Hi Phil, >=20 > Thanks for your response on these questions, a few more comments > in-line and we should be able to wrap this up and move it to the next > phase quickly. >=20 >> On Wed, Nov 18, 2015 at 4:03 PM, Phil Hunt wrote: >> Comments inline. >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>> On Nov 16, 2015, at 12:37 PM, Kathleen Moriarty wrote: >>>=20 >>> Hello, >>>=20 >>> I reviewed draft-ietf-oauth-pop-architecture and have a few questions. >>>=20 >>> 1. Section 6, Threat Mitigation: >>>=20 >>> Last sentence of first paragraph, "To >>> simplify the subsequent description we assume that the token itself >>> is digitally signed by the authorization server and therefore cannot >>> be modified." >>>=20 >>> Since bearer tokens are not signed by default, is this proposing a >>> change? If so, where will that change occur? To state that "it is >>> assumed" without it being required anywhere is not a good assumption. >>> I'd still see this as a risk or security consideration. When OAuth is >>> re-used by other protocols, I am seeing that re-use leave off basic >>> protections that should be assumed like TLS, let alone digital >>> signatures. If this is required in the defined architecture (Section >>> 7 - it does show this, but there are no MUSTs that I can find), just >>> state that and refer to the requirement. >>=20 >> [PH] I think the change is the point of the POP specifications. We are ta= lking about a new class of tokens that are specifically not Bearer tokens th= us the threat mitigation states that POP tokens are assumed to be digitally s= igned. >=20 > Sure, but that is not spelled out in the requirements section and > should be. I think the issue may be that the requirements section > just says that the requirements are from RFC4962 and put into OAuth > terms. There isn't any text or list that says the following > requirements are added for this architecture and I would expect to see > that. Can you add that so you will be able to make such assumptions > with this architecture going forward and subsequent draft authors > would have clear guidance? >=20 >>=20 >> Was that not clear from the introduction? >=20 > There should be something in the requirements section. The phrasing > of this particular sentence could be changed as follows (in addition > to adding a requirement): >=20 > "To > simplify the subsequent description we assume in the POP > architecture that the token itself > is digitally signed by the authorization server and therefore cannot > be modified." >=20 > Or something like: > "To > simplify the subsequent description we assume in this > architecture that the token itself > is digitally signed by the authorization server and therefore cannot > be modified." >=20 > The second choice is added only because you don't seem to use the term > POP architecture in the draft, but it would be good to make it clear > that this draft adds this assumption, it is something new. >=20 >=20 >>>=20 >>> 2. Section 6, Threat Mitigation >>>=20 >>> Third paragraph, "As an example, TLS with a ciphersuite >>> that offers confidentiality protection has to be applied (which is >>> currently true for all ciphersuites, except for one). >>>=20 >>> Please list a reference so the reader knows which ciphersuites are >>> acceptable from the recommended ones in RFC7525. I don't recall there >>> being any MTI ciphersuites for OAuth (I'm pretty sure there aren't and >>> that we've discussed that already with previous drafts, so this should >>> be spelled out more). >> [PH] I think this can be simplified a bit. I think this was referring to a= =E2=80=9CNULL=E2=80=9D ciphersuite which is what 7525 says should not be do= ne. We should also point to 7525. >=20 > That would take care of it and would be a minor and clear change. Thank y= ou! >=20 >>>=20 >>> 3. (Nit) Section 6.2, add a comma to improve readability >>> From: "Instead of providing confidentiality protection the authorization= >>> server could also put the identifier of the client into the protected >>> token with the following semantic:" >>> To: "Instead of providing confidentiality protection, the authorization >>> server could also put the identifier of the client into the protected >>> token with the following semantic:=E2=80=9D >> [PH] Will add to the next draft pending your comments on the above items.= >=20 > Thank you! > Kathleen >=20 >>=20 >>> Thank you all for your work on this draft! >>> -- >>>=20 >>> Best regards, >>> Kathleen >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 >=20 > --=20 >=20 > Best regards, > Kathleen From nobody Fri Nov 20 09:07:52 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81DBD1B2CCA for ; Fri, 20 Nov 2015 09:07:51 -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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3EMSIUjcMuwQ for ; Fri, 20 Nov 2015 09:07:48 -0800 (PST) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BF841B2CBF for ; Fri, 20 Nov 2015 09:07:48 -0800 (PST) Received: by vkay187 with SMTP id y187so1618404vka.3 for ; Fri, 20 Nov 2015 09:07:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=81U7VUWbjXKwGP0kiY+zR+0KkLHNk57FB/h7x5/T1IE=; b=KwUyuUhS0UqDOEFP3xyc6q6rRmHP0nKgh0Wj2YvTAWs0/fEyu2pK/xgBp1mOIhjY32 dB0MNbd2m/v1hY/lI1IMhl9yGDe5a+qlUTu3uX1FLrfUcvB7mt0V0IbO0gF/ZYr82FF9 gEzzVGbzpedImqs1IpooUV4a5EXRYcS2rThbZ8IYZFfNaC39ctH0y70tiftKkbvjXdAz ZMtA18dw975Pdw43QX4Bgp6OcCXtti/ClylENr20mbquvZhF/ItVc151b2HRIUvLqXIU 2v2zoARe7a3+w3ZubOolTUzvK4WyuptPd8/TL4scsXnZ8uOEzPtUTz8SfOxIj6zH2W3T jUZg== X-Received: by 10.31.155.131 with SMTP id d125mr380322vke.67.1448039267750; Fri, 20 Nov 2015 09:07:47 -0800 (PST) Received: from [172.20.3.0] ([65.200.157.66]) by smtp.gmail.com with ESMTPSA id 188sm243921vki.27.2015.11.20.09.07.46 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 20 Nov 2015 09:07:46 -0800 (PST) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (12H143) In-Reply-To: <807F71A5-3C01-437C-8187-8A4349D7DF46@oracle.com> Date: Fri, 20 Nov 2015 12:07:45 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <64BD1BA4-D109-4EBE-A3B5-4A6C309E6421@gmail.com> References: <2DC07A54-BA80-48EE-9CC3-7BDE4CAA0AD7@nexusgroup.com> <807F71A5-3C01-437C-8187-8A4349D7DF46@oracle.com> To: Phil Hunt Archived-At: Cc: "" , Justin Richer Subject: Re: [OAUTH-WG] A review of draft-ietf-oauth-pop-architecture-05 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2015 17:07:51 -0000 Sent from my iPhone > On Nov 20, 2015, at 11:59 AM, Phil Hunt wrote: >=20 > +1. I will post an update monday.=20 >=20 > Ps. Did you see my original responses to your first comments? Our emails must have crossed. Since I was re-reading, I figured it would be= best to respond to both after that. I think we are good now! Thanks. Kathleen=20 >=20 > Phil >=20 >> On Nov 20, 2015, at 08:27, Kathleen Moriarty wrote: >>=20 >> I'm re-reading to make sure this would be okay at this stage and have >> some suggestions. >>=20 >> Could 3.2 cover TLS and DTLS? Then you don't need to state COSE/CBOR >> specifically in this section but it hints at applicable IoT use cases >> and isn't a big change since OAuth could be used in scenarios with >> DTLS and IoT. >>=20 >> Since 3.3 refers to a web client, I'd leave it alone. It's just a use >> case. And I don't think 3.4 is a good example for IoT with >> discussions of load balancers. >>=20 >> In section 4, the client is listed generically without definition, >> Maybe stating constrained and devices that are not constrained are >> clients would be enough in the Token manufacture/modification threat >> scenario? That would be on first use in this section for clients. >>=20 >> Section 6.2 calls out 2 examples with TLS, but doesn't restrict the >> selection to these two, so I think the text there is fine as-is, >> especially since "available infrastructure" is one of the >> considerations. >>=20 >> I think that would be enough and wouldn't be too much to change at >> this stage to include IoT under this draft. I would not add in >> explicit mention of CBOR or COSE as the draft doesn't mention JSON or >> JOSE anywhere. >>=20 >> Does that should like a good approach? This just means 2 minor >> changes to make the generic text also explicitly include constrained >> devices. >>=20 >> Thanks, >> Kathleen >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> On Thu, Nov 19, 2015 at 2:29 PM, Erik Wahlstr=C3=B6m neXus >> wrote: >>> Fair enough. Was way to late to the game here. All and all, it=E2=80=99s= a very good >>> document. >>> / Erik >>>=20 >>>=20 >>> On 19 Nov 2015, at 19:18, Justin Richer wrote: >>>=20 >>> I agree with added "For example" in a few places. It's not normative it'= s >>> informational here. >>>=20 >>>=20 >>>=20 >>> < div=3D""> >>> -- Justin >>>=20 >>> / Sent from my phone / >>> <> >>>=20 >>>=20 >>> -------- Original message -------- >>> From: Phil Hunt >>> Date: 11/19/2015 11:28 AM (GMT-06:00) >>> To: Erik Wahlstr=C3=B6m neXus >>> Cc: "" , Justin Richer >>> >>> Subject: Re: [OAUTH-WG] A review of draft-ietf-oauth-pop-architecture-05= >>>=20 >>> I think your point that maybe the architecture doc be generic enough to >>> support both json and cbor tokens is worth consideration. >>>=20 >>> I am just not sure of process and consensus now that we are past WGLC. W= ould >>> the cose group prefer this? >>>=20 >>> Happy to do it if desired. Also understand if we are too far down the ro= ad. >>>=20 >>> Phil >>>=20 >>> On Nov 19, 2015, at 08:39, Erik Wahlstr=C3=B6m neXus >>> wrote: >>>=20 >>> Just a note then. I did not see anything that prohibited the usage of po= p >>> tokens for IoT so shipping it as is works. >>>=20 >>> Sent from my iPhone >>>=20 >>> On 19 Nov 2015, at 17:18, Phil Hunt wrote: >>>=20 >>> On the subject of making the spec(s) less JWT specific, it was a >>> foundational assumption and (I think) in the charter. However COSE wasn'= t >>> around yet. >>>=20 >>> I suppose the more generic architecture doc could be altered to cover Io= T >>> cases, but it may be problematic for the other specs that are more speci= fic. >>>=20 >>> Another issue is I assume the COSE based tokens will have a different ty= pe >>> (eg cpop) to differentiate between jwt and COSE web tokens (what are we >>> calling them now?). >>>=20 >>> As this generalization change could be seen as substantial, I would like= to >>> have the chairs and AD comment. Is this a good idea? Or is COSE better t= o >>> write their own parallel arch draft? >>>=20 >>> I'm happy to bend to the will of the group(s) on this. >>>=20 >>> Phil >>>=20 >>> On Nov 19, 2015, at 01:17, Erik Wahlstr=C3=B6m neXus >>> wrote: >>>=20 >>> Hi, >>>=20 >>> I have been reviewing draft-ietf-oauth-pop-architecture-05. In ACE WG we= >>> have a draft that uses PoP tokens for IoT and the architectures defined h= ere >>> so my review was done with that IoT perspective. I=E2=80=99m a bit late w= ith the >>> review and some of the comments might already be mentioned by others. >>>=20 >>>=20 >>>=20 >>> =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 >>>=20 >>> 3.1. Preventing Access Token Re-Use by the Resource Server >>>=20 >>> If a symmetric key is used it=E2=80=99s possible to re-use the key for a= resource >>> server. The section talks about the importance of scopes, but I feel it >>> should also mention the importance for the resource server to verify the= >>> audience (=E2=80=9Caud=E2=80=9D) claim in the token to disable missuse. >>>=20 >>> =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 >>>=20 >>> The draft in ACE WG >>> (https://tools.ietf.org/html/draft-seitz-ace-oauth-authz-00) relies heav= ily >>> on this work. The main reason for this is the way PoP tokens can establi= sh >>> key material, with the help of the authorization server, on both the cli= ent >>> and resource server. PoP tokens is also a very good fit for constrained I= oT >>> devices that can be offline and it=E2=80=99s also possible to use hardwa= re key >>> storages to handle asymmetric pop keys. >>>=20 >>> There could be a place for a new "Use Case" under section 3 that talks a= bout >>> scenarios where PoP keys are a really good match for offline IoT devices= . I >>> could help out ironing out a text for that with the help of the docs aut= hors >>> if that=E2=80=99s of interest. >>>=20 >>> =E2=80=94=E2=80=94=E2=80=94 >>>=20 >>> s/a bogus tokens/a bogus token >>>=20 >>> =E2=80=94=E2=80=94 >>>=20 >>> In the document only references are made to JSON, JWT and JOSE. More exa= ctly >>> in the following two sections: >>>=20 >>> A number of the threats listed in Section 4 demand protection of the >>> access token content and a standardized solution, in form of a JSON- >>> based format, is available with the JWT [RFC7519]. >>>=20 >>>=20 >>>=20 >>> With the JSON Web Token (JWT) [RFC7519] a standardized format for >>> access tokens is available. The necessary elements to bind symmetric >>> or asymmetric keys to a JWT are described in >>> [I-D.ietf-oauth-proof-of-possession]. >>>=20 >>>=20 >>> Constrained IoT devices uses other access token and messages formats >>> (according to our draft). It does not only use signed/encrypted JWT=E2=80= =99s but >>> also COSE protected CBOR Web Tokens. See >>> https://tools.ietf.org/id/draft-wahlstroem-oauth-cbor-web-token-00.txt >>>=20 >>> I totally agree that JWT is the correct examples to have in this documen= t >>> due to the fact that they are RFC=E2=80=99s, they are well known and sho= uld be used >>> in as many places as possible, but it would be good to open up for other= >>> types of message formats. For example like this: >>>=20 >>>=20 >>> A number of the threats listed in Section 4 demand protection of the >>> access token content and a standardized solution in form of, for exampl= e, >>> a JSON- >>> based format, is available with the JWT [RFC7519]. >>>=20 >>>=20 >>>=20 >>> =E2=80=94=E2=80=94 >>>=20 >>> For that >>> purpose the client will have to authenticate the resource server >>> before transmitting the access token. >>>=20 >>>=20 >>>=20 >>> I=E2=80=99m missing a description about how this is handled in an end-to= -end >>> security scenario. >>>=20 >>> =E2=80=94=E2=80=94=E2=80=94 >>>=20 >>> The resource server queries the authorization server for the >>> symmetric key. This is an approach envisioned by the token >>> introspection endpoint [I-D.ietf-oauth-introspection]. >>>=20 >>>=20 >>>=20 >>> Not a question for this draft maybe, but in what draft is the introspect= ion >>> response claim defined? It=E2=80=99s not defined in >>> https://tools.ietf.org/html/rfc7662#section-2.2 and I don=E2=80=99t know= in what >>> other draft it can be defined. >>>=20 >>> =E2=80=94=E2=80=94 >>>=20 >>> In ACE WG the draft seitz-ace-oauth-authz have a profile for an access >>> request to make it work over CoAP. CoAP is the HTTP equivalent for >>> constrained devices, and it has limitations, for example it can=E2=80=99= t send large >>> tokens in options (headers in "http-speak"). This means that the draft >>> defines a way to first send the PoP token to an new endpoint on the reso= urce >>> server to establish a security context. Then the real request against th= e >>> resource server can be done once the security context is established. Se= e >>> more details here >>> https://tools.ietf.org/html/draft-seitz-ace-oauth-authz-00#section-5.2. >>>=20 >>> An open question; should a flow like that be added to the architecture >>> section? That means a new section 7.5. >>>=20 >>> =E2=80=94=E2=80=94 >>>=20 >>> Thanks for writing this. I think it=E2=80=99s very important work. >>>=20 >>> / Erik >>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >>=20 >> --=20 >>=20 >> Best regards, >> Kathleen >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth From nobody Fri Nov 20 11:12:07 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F4171B3D1B for ; Fri, 20 Nov 2015 11:12:06 -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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tHqNaoPWcCIu for ; Fri, 20 Nov 2015 11:12:03 -0800 (PST) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::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 8E1AF1B3413 for ; Fri, 20 Nov 2015 11:12:02 -0800 (PST) Received: by wmec201 with SMTP id c201so85498100wme.0 for ; Fri, 20 Nov 2015 11:12:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=VcOw67q2BSqlsokEYQhm8fGfeJVuV0fVSbE6Jt0DpF4=; b=CYHJp4IH/qplFRRax0YU55ii6vN+Tf8rwdXg7u8rcuT7WCG+S/uoiLQaecfpl+z+Xv /DZ5IRMSoDvTQbMAOIWoVo86P5tsBNb43hU0dWIYLIPYdJe+R6R1i1QidoXeZfs3GU+V AMlvOsYivk+qOigpOz0Zf2aiLFnS6trjfjv3AoG5CsnsJZKBMSHGKzgZvGDlSA0FdLVP CmB4WXKQrdzarCBzhNPWXhNBcRTD7PqW38XfxUeElIuaIpodONSHsXsa7d/P+1SBQOqo SKt/yQ+rx5SpOZ4jtLUdYLgvxQEg9U1DD7CfAeRNUSzjsW0fKXJygc50/OhgSdwbUOy9 A4dQ== MIME-Version: 1.0 X-Received: by 10.194.179.71 with SMTP id de7mr16077380wjc.119.1448046721085; Fri, 20 Nov 2015 11:12:01 -0800 (PST) Received: by 10.28.52.130 with HTTP; Fri, 20 Nov 2015 11:12:00 -0800 (PST) In-Reply-To: References: <563AA216.5010109@gmx.net> <89A6E4DE-263B-4DB4-8882-54FA7103C721@mit.edu> <82079E8A-2AC8-4A42-9AF7-77FF2A3CAFC2@ve7jtb.com> <9E23AF3A-F758-4CB4-B920-4E1E2F61BCF4@ve7jtb.com> <4D05C317-FF58-4CDE-98BE-D4ED1E078526@ve7jtb.com> Date: Fri, 20 Nov 2015 14:12:00 -0500 Message-ID: From: Kathleen Moriarty To: Chuck Mortimore Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2015 19:12:06 -0000 Hi, This draft was tossed over the fence to me, but it seems that there may be a few open questions that remain. Use of HSM and TPMwere raised in this tread and not addressed in the current draft version. Is guidance needed for nested JWTs? If not, why? In a separate thread, JWK is mentioned, but I'm okay with that text as there is a reference. I'd like to get this moving, os if we can wrap up these questions and if anything will be done about them, it would be helpful. Thank you, Kathleen On Thu, Nov 5, 2015 at 3:07 PM, Chuck Mortimore wrote: > The spec is very clear for most cases, but I think it could use some > guidance on nested JWTs. (Or perhaps I've got the approach wrong.) > > Here's the use-case: > We have devices that are self-issuing keys. Via token exchange, we're > going to except a self-signed JWT from the device that includes a "cnf" > claim of the key they generated. Assuming the signature checks out on > that JWT, we'll then bind that key into a "cnf" claim in a new token that= we > issue and sign with a tenant key. > > When the device goes to use that token, the device would sign it, > constructing a nested JWT. The outer signature is the proof of possessio= n > of the device's private key. The inner signature is our signature that > binds the public key used to validate the outer token. > > Does this sound correct? The processing order is a bit odd since you fi= rst > need to unpack and validate the inner token before you can validate the > outer token. Is there some other way this is intended to work? > > thanks > > -cmort > > > > On Wed, Nov 4, 2015 at 8:58 PM, John Bradley wrote: >> >> Good to know. So the AS needs to expose a public key for the TPM to us= e >> for encryption. I am guessing you are not using a encrypted JWK for th= at. >> What is the format the TPM produces the wrapped key in? >> >> John B. >> > On Nov 5, 2015, at 1:55 PM, Anthony Nadalin >> > wrote: >> > >> > I can say on all windows based devices (pc, xbox, phone, etc) with onl= y >> > TPM 1.1 this will be the approach so it will be commonly used >> > >> > -----Original Message----- >> > From: John Bradley [mailto:ve7jtb@ve7jtb.com] >> > Sent: Wednesday, November 4, 2015 8:52 PM >> > To: Anthony Nadalin >> > Cc: Justin Richer ; >> > Subject: Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spe= c >> > addressing final shepherd comment >> > >> > OK, no good reason unless the client is using a HSM that can do HMAC a= nd >> > can export a symmetric key wrapped in a asymmetric key provided by the= AS. >> > >> > We don=E2=80=99t currently cover that use case of sending a wrapped sy= mmetric >> > key to the AS in POP key distribution. >> > I don=E2=80=99t know how common that is going to be, but it is worth t= hinking >> > about defining. >> > >> > John B. >> > >> >> On Nov 5, 2015, at 1:45 PM, Anthony Nadalin >> >> wrote: >> >> >> >> Not sure why you think its weaker as it would be a wrapped key that >> >> the hardware produces >> >> >> >> -----Original Message----- >> >> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of John Bradley >> >> Sent: Wednesday, November 4, 2015 8:43 PM >> >> To: Justin Richer >> >> Cc: >> >> Subject: Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs >> >> spec addressing final shepherd comment >> >> >> >> In the asymmetric case the use of a HSM or secure element is the >> >> argument for the client selecting the public key. In those cases th= e >> >> client is doing the key gen in hardware so one hopes it is OK. In t= he >> >> symetric case the client generating the key is weaker (as in I can=E2= =80=99t think >> >> of any really good reason). >> >> >> >> >> >>> On Nov 5, 2015, at 1:35 PM, Justin Richer wrote: >> >>> >> >>> I=E2=80=99d argue that it=E2=80=99s best practice, and in line with = other parts of >> >>> OAuth, if we assume the server generates it in the normal case (issu= er -> >> >>> presenter). Client generated token keys should be an exception, espe= cially >> >>> in the asymmetric case. >> >>> >> >>> =E2=80=94 Justin >> >>> >> >>>> On Nov 5, 2015, at 1:32 PM, John Bradley wrote: >> >>>> >> >>>> Agreed the only real difference is the quality of the key. If the >> >>>> server generates it, then it knows that the client is not using the= fixed >> >>>> hex value of DEADBEEF for everything. >> >>>> >> >>>> John B. >> >>>>> On Nov 5, 2015, at 9:25 AM, Hannes Tschofenig >> >>>>> wrote: >> >>>>> >> >>>>> I agree that the effect is the same. From a security point of view >> >>>>> there is only an impact if one of the two parties is in a better >> >>>>> position to generate random numbers, which is the basis for >> >>>>> generating a high entropy symmetric key. >> >>>>> >> >>>>> On 11/04/2015 11:51 PM, Mike Jones wrote: >> >>>>>> Thanks for the detailed read, Brian. You=E2=80=99re right that i= n the >> >>>>>> symmetric case, either the issuer or the presenter can create the >> >>>>>> symmetric PoP key and share it with the other party, since the >> >>>>>> effect is equivalent. >> >>>>>> I suspect that both the key distribution draft and this draft >> >>>>>> should be updated with a sentence or two saying that either >> >>>>>> approach can be taken. Do others concur? >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> -- Mike >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> *From:*Brian Campbell [mailto:bcampbell@pingidentity.com] >> >>>>>> *Sent:* Thursday, November 05, 2015 7:48 AM >> >>>>>> *To:* Mike Jones >> >>>>>> *Cc:* Kepeng Li; oauth@ietf.org >> >>>>>> *Subject:* Re: [OAUTH-WG] Proof-of-Possession Key Semantics for >> >>>>>> JWTs spec addressing final shepherd comment >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> +1 for the diagrams making the document more understandable. >> >>>>>> >> >>>>>> One little nit/question, step 1 in both Symmetric and Asymmetric >> >>>>>> keys shows the Presenter sending the key to the Issuer. It's >> >>>>>> possible, however, for the key to be sent the other way. Presente= r >> >>>>>> sending it to the Issuer is probably preferred for asymmetric, >> >>>>>> especially if the client can secure the private keys in hardware. >> >>>>>> But I don't know if one way or the other is clearly better for >> >>>>>> symmetric case and PoP key distribution currently has it the othe= r >> >>>>>> way >> >>>>>> . >> >>>>>> Should the intro text somehow mention the possibility that the >> >>>>>> Issuer could create the key and send it to the Presenter? >> >>>>>> >> >>>>>> I know it's only the introduction but it was just something that >> >>>>>> jumped out at me. >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> On Wed, Nov 4, 2015 at 9:04 AM, Mike Jones >> >>>>>> = > >> >>>>>> wrote: >> >>>>>> >> >>>>>> Thanks for suggesting the diagrams, Kepeng. They make the documen= t >> >>>>>> more understandable. >> >>>>>> >> >>>>>> -- Mike >> >>>>>> >> >>>>>> -----------------------------------------------------------------= - >> >>>>>> - >> >>>>>> ----- >> >>>>>> >> >>>>>> *From: *Kepeng Li >> >>>>>> *Sent: *=E2=80=8E11/=E2=80=8E5/=E2=80=8E2015 12:57 AM >> >>>>>> *To: *Mike Jones ; >> >>>>>> oauth@ietf.org >> >>>>>> *Subject: *Re: Proof-of-Possession Key Semantics for JWTs spec >> >>>>>> addressing final shepherd comment >> >>>>>> >> >>>>>> Thank you Mike. >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> The diagrams look good to me. >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> Kind Regards >> >>>>>> >> >>>>>> Kepeng >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> *=E5=8F=91=E4=BB=B6=E4=BA=BA**: *Mike Jones > >>>>>> > >> >>>>>> *=E6=97=A5=E6=9C=9F**: *Thursday, 5 November, 2015 12:32 am >> >>>>>> *=E8=87=B3**: *"oauth@ietf.org " > >>>>>> > >> >>>>>> *=E6=8A=84=E9=80=81**: *Li Kepeng > >>>>>> > >> >>>>>> *=E4=B8=BB=E9=A2=98**: *Proof-of-Possession Key Semantics for JWT= s spec addressing >> >>>>>> final shepherd comment >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> Proof-of-Possession Key Semantics for JWTs draft -06 addresses th= e >> >>>>>> remaining document shepherd comment =E2=80=93 adding use case dia= grams to >> >>>>>> the introduction. >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> The updated specification is available at: >> >>>>>> >> >>>>>> =C2=B7 >> >>>>>> https://na01.safelinks.protection.outlook.com/?url=3Dhttp%3a%2f%2= ftools.ietf.org%2fhtml%2fdraft-ietf-oauth-proof-of-possession-06&data=3D01%= 7c01%7ctonynad%40microsoft.com%7c9456670075d04a51f85508d2e59ba294%7c72f988b= f86f141af91ab2d7cd011db47%7c1&sdata=3D6hE6dOO0I1%2ffF005rVknyOFHuB18gdpZg9d= ftExLtCw%3d >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> An HTML formatted version is also available at: >> >>>>>> >> >>>>>> =C2=B7 >> >>>>>> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%= 2fs >> >>>>>> e >> >>>>>> lf-issued.info%2fdocs%2fdraft-ietf-oauth-proof-of-possession-06.h= t >> >>>>>> m >> >>>>>> l&data=3D01%7c01%7ctonynad%40microsoft.com%7c9456670075d04a51f855= 08d >> >>>>>> 2 >> >>>>>> e59ba294%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=3DEQd4rUcuy= qdS >> >>>>>> P gmibtcfjMpJm6RWWwCZC85%2bCboEs54%3d >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> -- Mike >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> P.S. This note was also posted at >> >>>>>> >> >>>>>> https://na01.safelinks.protection.outlook.com/?url=3Dhttp%3a%2f%2= fself-issued.info%2f%3fp%3d1471&data=3D01%7c01%7ctonynad%40microsoft.com%7c= 9456670075d04a51f85508d2e59ba294%7c72f988bf86f141af91ab2d7cd011db47%7c1&sda= ta=3DTMfX1tG5qucl%2be2KVpyMBuj72ZQ%2f%2bEKGoTyJyf%2bfJi4%3d >> >>>>>> and as @selfissued >> >>>>>> . >> >>>>>> >> >>>>>> >> >>>>>> _______________________________________________ >> >>>>>> OAuth mailing list >> >>>>>> OAuth@ietf.org >> >>>>>> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%= 2fw >> >>>>>> w >> >>>>>> w.ietf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonynad%= 40m >> >>>>>> i >> >>>>>> crosoft.com%7c9456670075d04a51f85508d2e59ba294%7c72f988bf86f141af= 9 >> >>>>>> 1 >> >>>>>> ab2d7cd011db47%7c1&sdata=3DND3ydaXOsPMsoRhE0Uyq0uznGy6MdYOLZQJHLh= EQK >> >>>>>> J >> >>>>>> s%3d >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> _______________________________________________ >> >>>>>> OAuth mailing list >> >>>>>> OAuth@ietf.org >> >>>>>> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%= 2fw >> >>>>>> w >> >>>>>> w.ietf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonynad%= 40m >> >>>>>> i >> >>>>>> crosoft.com%7c9456670075d04a51f85508d2e59ba294%7c72f988bf86f141af= 9 >> >>>>>> 1 >> >>>>>> ab2d7cd011db47%7c1&sdata=3DND3ydaXOsPMsoRhE0Uyq0uznGy6MdYOLZQJHLh= EQK >> >>>>>> J >> >>>>>> s%3d >> >>>>>> >> >>>>> >> >>>>> _______________________________________________ >> >>>>> OAuth mailing list >> >>>>> OAuth@ietf.org >> >>>>> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2= fww >> >>>>> w >> >>>>> .ietf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonynad%40= mic >> >>>>> r >> >>>>> osoft.com%7c9456670075d04a51f85508d2e59ba294%7c72f988bf86f141af91a= b >> >>>>> 2 >> >>>>> d7cd011db47%7c1&sdata=3DND3ydaXOsPMsoRhE0Uyq0uznGy6MdYOLZQJHLhEQKJ= s%3 >> >>>>> d >> >>>> >> >>>> _______________________________________________ >> >>>> OAuth mailing list >> >>>> OAuth@ietf.org >> >>>> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2f= www. >> >>>> ietf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonynad%40mi= cro >> >>>> s >> >>>> oft.com%7c9456670075d04a51f85508d2e59ba294%7c72f988bf86f141af91ab2d= 7 >> >>>> c d011db47%7c1&sdata=3DND3ydaXOsPMsoRhE0Uyq0uznGy6MdYOLZQJHLhEQKJs%= 3d >> >>> >> >> >> >> _______________________________________________ >> >> OAuth mailing list >> >> OAuth@ietf.org >> >> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fww= w.i >> >> etf.org%2fmailman%2flistinfo%2foauth%0a&data=3D01%7c01%7ctonynad%40mi= cro >> >> soft.com%7c9456670075d04a51f85508d2e59ba294%7c72f988bf86f141af91ab2d7= c >> >> d011db47%7c1&sdata=3DBLqSuDjWLY72fGm0UrpLwxQVnamMelggJeOpYJESVFs%3d >> > >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 Best regards, Kathleen From nobody Fri Nov 20 11:33:13 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 863271B2D3E for ; Fri, 20 Nov 2015 11:33:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.402 X-Spam-Level: X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_21=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id biqvOTnEI3Mw for ; Fri, 20 Nov 2015 11:33:07 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0781.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:781]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24B5D1B2D22 for ; Fri, 20 Nov 2015 11:33:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=hREHA3nlMrqyaHhNVMFqUC1KvyOYSb7O/bFG6PFcAzQ=; b=nQbRcHwDDMCxwZQFS3RMhosWXg5lXU4xBuFOHSVcO4HzRQZBL6GOn+sDQ9kwImT0z3dTm+cYCtc/4ovGbQXhg8sKQq9I9nRrisyO6FyvKu0p89v1GouNV/LvX9hltMYp4rdKNrBr4l0qhZyULq0Rf4/4Vhpk8lefhyphmLfETv4= Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB441.namprd03.prod.outlook.com (10.141.141.142) with Microsoft SMTP Server (TLS) id 15.1.325.17; Fri, 20 Nov 2015 19:32:49 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0325.019; Fri, 20 Nov 2015 19:32:49 +0000 From: Mike Jones To: Kathleen Moriarty , Chuck Mortimore Thread-Topic: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment Thread-Index: AdEXFgZ+9CN0zPNjS1iUuZ0RolJO4QAA29mAAAA+4ZAADhjrAAAADBnAAANhSAAACJh0gAAAIrkAAABAqwAAAA9iQAAAPMSAAAAVIgAAACZ4gAAfvjOAAvBwxwAAAFKMwA== Date: Fri, 20 Nov 2015 19:32:49 +0000 Message-ID: References: <563AA216.5010109@gmx.net> <89A6E4DE-263B-4DB4-8882-54FA7103C721@mit.edu> <82079E8A-2AC8-4A42-9AF7-77FF2A3CAFC2@ve7jtb.com> <9E23AF3A-F758-4CB4-B920-4E1E2F61BCF4@ve7jtb.com> <4D05C317-FF58-4CDE-98BE-D4ED1E078526@ve7jtb.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [50.47.85.157] x-microsoft-exchange-diagnostics: 1; BY2PR03MB441; 5:v6QDhBX0p2wGbQnzQWV5gbkS85n9kUC2VJeh+c38umfdZWuHiNQAcRLRN2DqzIKmL5wLy3wChltLm0jtWPpzAU+/+X1b67NEuD0/EvvhOtFc8ImikGzavEnlXnen3E2XFSTmtEmvFrbq91/ESZItiw==; 24:pDuefM4++bKpmmt9sHx9dvwEVLs+kyNLlu31i9UMUb/JWQ6zCnLPqRoa1V98qNAMNqZ40JWVMGeLJccBjufk7WyAEEeocoHWezV/pGwZvGA=; 20:SjxaHElLQDDJPpIBpfzcO7A/SJuU80nFBQgyBGrdr7/xWIWZZSAeoww9sjNUj3hXQGL01fPg/bIrASHsrIMhuQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB441; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(189930954265078)(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425024)(601004)(2401047)(8121501046)(520078)(5005006)(10201501046)(3002001)(61426024)(61427024); SRVR:BY2PR03MB441; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB441; x-forefront-prvs: 07665BE9D1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(479174004)(377454003)(71364002)(199003)(52604005)(189002)(51914003)(24454002)(13464003)(5007970100001)(10090500001)(575784001)(86362001)(122556002)(5001960100002)(97736004)(105586002)(19580405001)(33656002)(106356001)(87936001)(40100003)(92566002)(10400500002)(76576001)(74316001)(86612001)(5005710100001)(19580395003)(5004730100002)(586003)(10290500002)(8990500004)(189998001)(81156007)(230783001)(5001770100001)(5002640100001)(76176999)(93886004)(6116002)(54356999)(15975445007)(99286002)(2950100001)(101416001)(3846002)(5008740100001)(5003600100002)(66066001)(50986999)(102836003)(2900100001)(77096005)(11100500001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB441; H:BY2PR03MB442.namprd03.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:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Nov 2015 19:32:49.4324 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB441 Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2015 19:33:11 -0000 SFNNLWJhY2tlZCBwdWJsaWMga2V5cyB3b3VsZCBiZSByZXByZXNlbnRlZCBpbiB0aGUgc2FtZSB3 YXkgdGhhdCBvdGhlciBwdWJsaWMga2V5cyBhcmUgLSB1c2luZyB0aGUgc3RhbmRhcmQgSldLIHJl cHJlc2VudGF0aW9uIGZvciB0aGVtLiAgTGlrZXdpc2UgZm9yIFRQTS1iYWNrZWQgcHVibGljIGtl eXMuICBUaGF0IHNhaWQsIEknbSBub3QgYW4gZXhwZXJ0IGluIFRQTXMgYW5kIGtub3cgdGhhdCB0 aGV5IGRlZmluZSBUUE0tc3BlY2lmaWMgc2lnbmF0dXJlIGZvcm1hdHMgYnV0IHRvIG15IHVuZGVy c3RhbmRpbmcsIHRoZXkncmUgdXNpbmcgc3RhbmRhcmQga2luZHMgb2Yga2V5cy4gIElmIHRoaXMg aXNuJ3QgdGhlIGNhc2UsIGEgbmV3IGtleSB0eXBlICgia3R5Iikgd291bGQgYmUgbmVlZGVkIHRv IHJlcHJlc2VudCB0aGVtLCBidXQgdGhleSdkIHN0aWxsIGJlIHJlcHJlc2VudGVkIGFzIGEgSldL IGluIHRoZSBKV1QgdXNpbmcgdGhhdCBrZXkgdHlwZS4gIFRoZSBkcmFmdCB3b3VsZCBzdGlsbCB3 b3JrIGZpbmUgZm9yIHRoZXNlIHVzZSBjYXNlcyBhcyB3cml0dGVuLiAgRG9lcyB0aGF0IHNvdW5k IHJpZ2h0IHRvIHBlb3BsZSBvciBhbSBJIG1pc3Npbmcgc29tZXRoaW5nIGhlcmU/DQoNCkZvciBD aHVjaydzIG5lc3RlZCBKV1QgdXNlIGNhc2UsIHRoYXQgc2VlbXMgbGlrZSBpdCB3b3VsZCB3b3Jr IG91dCBhcyBoZSBkZXNjcmliZWQgaXQuICBOb3RlIHRoYXQgaGUncyBwcmltYXJpbHkgZGVzY3Jp YmluZyB0aGUgcHJvdG9jb2wgbWVzc2FnZXMgaGUncyB1c2luZyB0byBkbyB0aGUgcHJvb2Ytb2Yt cG9zc2Vzc2lvbiAtIG5vdCBqdXN0IGhvdyB0byByZXByZXNlbnQgdGhlIFBvUCBrZXkgaW4gYSBK V1QgLSB3aGljaCBpcyB0aGUgc2NvcGUgb2YgdGhpcyBkcmFmdC4gIFRoZSBQb1AgcHJvdG9jb2wg cGllY2VzIGFyZSBleHBsaWNpdGx5IG91dCBvZiBzY29wZSBmb3IgdGhpcyBkcmFmdCAtIGl0J3Mg anVzdCBhYm91dCBQb1Aga2V5IHJlcHJlc2VudGF0aW9uLg0KDQpJZiBJIGhhdmUgdGhlIGFib3Zl IHJpZ2h0LCBkb2VzIGFueW9uZSBiZWxpZXZlIHRoYXQgd2Ugbm9uZXRoZWxlc3MgbmVlZCB0byBk byBhbiB1cGRhdGUgdG8gdGhlIGRyYWZ0PyAgSWYgc28sIGNhbiB5b3Ugc3VwcGx5IHByb3Bvc2Vk IHdvcmRpbmcgb3IgYXQgbGVhc3QgdGhlIGdpc3Qgb2YgdGhlIGFkZGl0aW9uYWwgaWRlYXMgdGhh dCB5b3UnZCBsaWtlIHRvIGhhdmUgY29udmV5ZWQuDQoNCgkJCQlCZXN0IHdpc2hlcywNCgkJCQkt LSBNaWtlDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBPQXV0aCBbbWFpbHRv Om9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBLYXRobGVlbiBNb3JpYXJ0eQ0K U2VudDogRnJpZGF5LCBOb3ZlbWJlciAyMCwgMjAxNSAxMToxMiBBTQ0KVG86IENodWNrIE1vcnRp bW9yZSA8Y21vcnRpbW9yZUBzYWxlc2ZvcmNlLmNvbT4NCkNjOiA8b2F1dGhAaWV0Zi5vcmc+IDxv YXV0aEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIFByb29mLW9mLVBvc3Nlc3Np b24gS2V5IFNlbWFudGljcyBmb3IgSldUcyBzcGVjIGFkZHJlc3NpbmcgZmluYWwgc2hlcGhlcmQg Y29tbWVudA0KDQpIaSwNCg0KVGhpcyBkcmFmdCB3YXMgdG9zc2VkIG92ZXIgdGhlIGZlbmNlIHRv IG1lLCBidXQgaXQgc2VlbXMgdGhhdCB0aGVyZSBtYXkgYmUgYSBmZXcgb3BlbiBxdWVzdGlvbnMg dGhhdCByZW1haW4uICBVc2Ugb2YgSFNNIGFuZCBUUE13ZXJlIHJhaXNlZCBpbiB0aGlzIHRyZWFk IGFuZCBub3QgYWRkcmVzc2VkIGluIHRoZSBjdXJyZW50IGRyYWZ0IHZlcnNpb24uDQoNCklzIGd1 aWRhbmNlIG5lZWRlZCBmb3IgbmVzdGVkIEpXVHM/ICBJZiBub3QsIHdoeT8NCg0KSW4gYSBzZXBh cmF0ZSB0aHJlYWQsIEpXSyBpcyBtZW50aW9uZWQsIGJ1dCBJJ20gb2theSB3aXRoIHRoYXQgdGV4 dCBhcyB0aGVyZSBpcyBhIHJlZmVyZW5jZS4NCg0KSSdkIGxpa2UgdG8gZ2V0IHRoaXMgbW92aW5n LCBvcyBpZiB3ZSBjYW4gd3JhcCB1cCB0aGVzZSBxdWVzdGlvbnMgYW5kIGlmIGFueXRoaW5nIHdp bGwgYmUgZG9uZSBhYm91dCB0aGVtLCBpdCB3b3VsZCBiZSBoZWxwZnVsLg0KDQpUaGFuayB5b3Us DQpLYXRobGVlbg0KDQpPbiBUaHUsIE5vdiA1LCAyMDE1IGF0IDM6MDcgUE0sIENodWNrIE1vcnRp bW9yZSA8Y21vcnRpbW9yZUBzYWxlc2ZvcmNlLmNvbT4gd3JvdGU6DQo+IFRoZSBzcGVjIGlzIHZl cnkgY2xlYXIgZm9yIG1vc3QgY2FzZXMsIGJ1dCBJIHRoaW5rIGl0IGNvdWxkIHVzZSBzb21lDQo+ IGd1aWRhbmNlIG9uIG5lc3RlZCBKV1RzLiAgICAoT3IgcGVyaGFwcyBJJ3ZlIGdvdCB0aGUgYXBw cm9hY2ggd3JvbmcuKQ0KPg0KPiBIZXJlJ3MgdGhlIHVzZS1jYXNlOg0KPiBXZSBoYXZlIGRldmlj ZXMgdGhhdCBhcmUgc2VsZi1pc3N1aW5nIGtleXMuICAgIFZpYSB0b2tlbiBleGNoYW5nZSwgd2Un cmUNCj4gZ29pbmcgdG8gZXhjZXB0IGEgc2VsZi1zaWduZWQgSldUIGZyb20gdGhlIGRldmljZSB0 aGF0IGluY2x1ZGVzIGEgImNuZiINCj4gY2xhaW0gb2YgdGhlIGtleSB0aGV5IGdlbmVyYXRlZC4g ICAgQXNzdW1pbmcgdGhlIHNpZ25hdHVyZSBjaGVja3Mgb3V0IG9uDQo+IHRoYXQgSldULCB3ZSds bCB0aGVuIGJpbmQgdGhhdCBrZXkgaW50byBhICJjbmYiIGNsYWltIGluIGEgbmV3IHRva2VuIA0K PiB0aGF0IHdlIGlzc3VlIGFuZCBzaWduIHdpdGggYSB0ZW5hbnQga2V5Lg0KPg0KPiBXaGVuIHRo ZSBkZXZpY2UgZ29lcyB0byB1c2UgdGhhdCB0b2tlbiwgdGhlIGRldmljZSB3b3VsZCBzaWduIGl0 LCANCj4gY29uc3RydWN0aW5nIGEgbmVzdGVkIEpXVC4gIFRoZSBvdXRlciBzaWduYXR1cmUgaXMg dGhlIHByb29mIG9mIHBvc3Nlc3Npb24NCj4gb2YgdGhlIGRldmljZSdzIHByaXZhdGUga2V5LiAg IFRoZSBpbm5lciBzaWduYXR1cmUgaXMgb3VyIHNpZ25hdHVyZSB0aGF0DQo+IGJpbmRzIHRoZSBw dWJsaWMga2V5IHVzZWQgdG8gdmFsaWRhdGUgdGhlIG91dGVyIHRva2VuLg0KPg0KPiBEb2VzIHRo aXMgc291bmQgY29ycmVjdD8gICBUaGUgcHJvY2Vzc2luZyBvcmRlciBpcyBhIGJpdCBvZGQgc2lu Y2UgeW91IGZpcnN0DQo+IG5lZWQgdG8gdW5wYWNrIGFuZCB2YWxpZGF0ZSB0aGUgaW5uZXIgdG9r ZW4gYmVmb3JlIHlvdSBjYW4gdmFsaWRhdGUgdGhlDQo+IG91dGVyIHRva2VuLiAgIElzIHRoZXJl IHNvbWUgb3RoZXIgd2F5IHRoaXMgaXMgaW50ZW5kZWQgdG8gd29yaz8NCj4NCj4gdGhhbmtzDQo+ DQo+IC1jbW9ydA0KPg0KPg0KPg0KPiBPbiBXZWQsIE5vdiA0LCAyMDE1IGF0IDg6NTggUE0sIEpv aG4gQnJhZGxleSA8dmU3anRiQHZlN2p0Yi5jb20+IHdyb3RlOg0KPj4NCj4+IEdvb2QgdG8ga25v dy4gICBTbyB0aGUgQVMgbmVlZHMgdG8gZXhwb3NlIGEgcHVibGljIGtleSBmb3IgdGhlIFRQTSB0 byB1c2UNCj4+IGZvciBlbmNyeXB0aW9uLiAgIEkgYW0gZ3Vlc3NpbmcgeW91IGFyZSBub3QgdXNp bmcgYSBlbmNyeXB0ZWQgSldLIGZvciB0aGF0Lg0KPj4gV2hhdCBpcyB0aGUgZm9ybWF0IHRoZSBU UE0gcHJvZHVjZXMgdGhlIHdyYXBwZWQga2V5IGluPw0KPj4NCj4+IEpvaG4gQi4NCj4+ID4gT24g Tm92IDUsIDIwMTUsIGF0IDE6NTUgUE0sIEFudGhvbnkgTmFkYWxpbiA8dG9ueW5hZEBtaWNyb3Nv ZnQuY29tPg0KPj4gPiB3cm90ZToNCj4+ID4NCj4+ID4gSSBjYW4gc2F5IG9uIGFsbCB3aW5kb3dz IGJhc2VkIGRldmljZXMgKHBjLCB4Ym94LCBwaG9uZSwgZXRjKSB3aXRoIA0KPj4gPiBvbmx5IFRQ TSAxLjEgdGhpcyB3aWxsIGJlIHRoZSBhcHByb2FjaCBzbyBpdCB3aWxsIGJlIGNvbW1vbmx5IHVz ZWQNCj4+ID4NCj4+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+ID4gRnJvbTogSm9o biBCcmFkbGV5IFttYWlsdG86dmU3anRiQHZlN2p0Yi5jb21dDQo+PiA+IFNlbnQ6IFdlZG5lc2Rh eSwgTm92ZW1iZXIgNCwgMjAxNSA4OjUyIFBNDQo+PiA+IFRvOiBBbnRob255IE5hZGFsaW4gPHRv bnluYWRAbWljcm9zb2Z0LmNvbT4NCj4+ID4gQ2M6IEp1c3RpbiBSaWNoZXIgPGpyaWNoZXJAbWl0 LmVkdT47IDxvYXV0aEBpZXRmLm9yZz4gDQo+PiA+IDxvYXV0aEBpZXRmLm9yZz4NCj4+ID4gU3Vi amVjdDogUmU6IFtPQVVUSC1XR10gUHJvb2Ytb2YtUG9zc2Vzc2lvbiBLZXkgU2VtYW50aWNzIGZv ciBKV1RzIA0KPj4gPiBzcGVjIGFkZHJlc3NpbmcgZmluYWwgc2hlcGhlcmQgY29tbWVudA0KPj4g Pg0KPj4gPiBPSywgbm8gZ29vZCByZWFzb24gdW5sZXNzIHRoZSBjbGllbnQgaXMgdXNpbmcgYSBI U00gdGhhdCBjYW4gZG8gDQo+PiA+IEhNQUMgYW5kIGNhbiBleHBvcnQgYSBzeW1tZXRyaWMga2V5 IHdyYXBwZWQgaW4gYSBhc3ltbWV0cmljIGtleSBwcm92aWRlZCBieSB0aGUgQVMuDQo+PiA+DQo+ PiA+IFdlIGRvbuKAmXQgY3VycmVudGx5IGNvdmVyIHRoYXQgdXNlIGNhc2Ugb2Ygc2VuZGluZyBh IHdyYXBwZWQgDQo+PiA+IHN5bW1ldHJpYyBrZXkgdG8gdGhlIEFTIGluIFBPUCBrZXkgZGlzdHJp YnV0aW9uLg0KPj4gPiBJIGRvbuKAmXQga25vdyBob3cgY29tbW9uIHRoYXQgaXMgZ29pbmcgdG8g YmUsIGJ1dCBpdCBpcyB3b3J0aCANCj4+ID4gdGhpbmtpbmcgYWJvdXQgZGVmaW5pbmcuDQo+PiA+ DQo+PiA+IEpvaG4gQi4NCj4+ID4NCj4+ID4+IE9uIE5vdiA1LCAyMDE1LCBhdCAxOjQ1IFBNLCBB bnRob255IE5hZGFsaW4gDQo+PiA+PiA8dG9ueW5hZEBtaWNyb3NvZnQuY29tPg0KPj4gPj4gd3Jv dGU6DQo+PiA+Pg0KPj4gPj4gTm90IHN1cmUgd2h5IHlvdSB0aGluayBpdHMgd2Vha2VyIGFzIGl0 IHdvdWxkIGJlIGEgd3JhcHBlZCBrZXkgDQo+PiA+PiB0aGF0IHRoZSBoYXJkd2FyZSBwcm9kdWNl cw0KPj4gPj4NCj4+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiA+PiBGcm9tOiBP QXV0aCBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKb2huIA0K Pj4gPj4gQnJhZGxleQ0KPj4gPj4gU2VudDogV2VkbmVzZGF5LCBOb3ZlbWJlciA0LCAyMDE1IDg6 NDMgUE0NCj4+ID4+IFRvOiBKdXN0aW4gUmljaGVyIDxqcmljaGVyQG1pdC5lZHU+DQo+PiA+PiBD YzogPG9hdXRoQGlldGYub3JnPiA8b2F1dGhAaWV0Zi5vcmc+DQo+PiA+PiBTdWJqZWN0OiBSZTog W09BVVRILVdHXSBQcm9vZi1vZi1Qb3NzZXNzaW9uIEtleSBTZW1hbnRpY3MgZm9yIEpXVHMgDQo+ PiA+PiBzcGVjIGFkZHJlc3NpbmcgZmluYWwgc2hlcGhlcmQgY29tbWVudA0KPj4gPj4NCj4+ID4+ IEluIHRoZSBhc3ltbWV0cmljIGNhc2UgdGhlIHVzZSBvZiBhIEhTTSBvciBzZWN1cmUgZWxlbWVu dCBpcyB0aGUNCj4+ID4+IGFyZ3VtZW50IGZvciB0aGUgY2xpZW50IHNlbGVjdGluZyB0aGUgcHVi bGljIGtleS4gICBJbiB0aG9zZSBjYXNlcyB0aGUNCj4+ID4+IGNsaWVudCBpcyBkb2luZyB0aGUg a2V5IGdlbiBpbiBoYXJkd2FyZSBzbyBvbmUgaG9wZXMgaXQgaXMgT0suICAgSW4gdGhlDQo+PiA+ PiBzeW1ldHJpYyBjYXNlIHRoZSBjbGllbnQgZ2VuZXJhdGluZyB0aGUga2V5IGlzIHdlYWtlciAo YXMgaW4gSSANCj4+ID4+IGNhbuKAmXQgdGhpbmsgb2YgYW55IHJlYWxseSBnb29kIHJlYXNvbiku DQo+PiA+Pg0KPj4gPj4NCj4+ID4+PiBPbiBOb3YgNSwgMjAxNSwgYXQgMTozNSBQTSwgSnVzdGlu IFJpY2hlciA8anJpY2hlckBtaXQuZWR1PiB3cm90ZToNCj4+ID4+Pg0KPj4gPj4+IEnigJlkIGFy Z3VlIHRoYXQgaXTigJlzIGJlc3QgcHJhY3RpY2UsIGFuZCBpbiBsaW5lIHdpdGggb3RoZXIgcGFy dHMgDQo+PiA+Pj4gb2YgT0F1dGgsIGlmIHdlIGFzc3VtZSB0aGUgc2VydmVyIGdlbmVyYXRlcyBp dCBpbiB0aGUgbm9ybWFsIGNhc2UgDQo+PiA+Pj4gKGlzc3VlciAtPiBwcmVzZW50ZXIpLiBDbGll bnQgZ2VuZXJhdGVkIHRva2VuIGtleXMgc2hvdWxkIGJlIGFuIA0KPj4gPj4+IGV4Y2VwdGlvbiwg ZXNwZWNpYWxseSBpbiB0aGUgYXN5bW1ldHJpYyBjYXNlLg0KPj4gPj4+DQo+PiA+Pj4g4oCUIEp1 c3Rpbg0KPj4gPj4+DQo+PiA+Pj4+IE9uIE5vdiA1LCAyMDE1LCBhdCAxOjMyIFBNLCBKb2huIEJy YWRsZXkgPHZlN2p0YkB2ZTdqdGIuY29tPiB3cm90ZToNCj4+ID4+Pj4NCj4+ID4+Pj4gQWdyZWVk IHRoZSBvbmx5IHJlYWwgZGlmZmVyZW5jZSBpcyB0aGUgcXVhbGl0eSBvZiB0aGUga2V5LiAgSWYg DQo+PiA+Pj4+IHRoZSBzZXJ2ZXIgZ2VuZXJhdGVzIGl0LCB0aGVuIGl0IGtub3dzIHRoYXQgdGhl IGNsaWVudCBpcyBub3QgDQo+PiA+Pj4+IHVzaW5nIHRoZSBmaXhlZCBoZXggdmFsdWUgb2YgREVB REJFRUYgZm9yIGV2ZXJ5dGhpbmcuDQo+PiA+Pj4+DQo+PiA+Pj4+IEpvaG4gQi4NCj4+ID4+Pj4+ IE9uIE5vdiA1LCAyMDE1LCBhdCA5OjI1IEFNLCBIYW5uZXMgVHNjaG9mZW5pZyANCj4+ID4+Pj4+ IDxoYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0PiB3cm90ZToNCj4+ID4+Pj4+DQo+PiA+Pj4+PiBJ IGFncmVlIHRoYXQgdGhlIGVmZmVjdCBpcyB0aGUgc2FtZS4gRnJvbSBhIHNlY3VyaXR5IHBvaW50 IG9mIA0KPj4gPj4+Pj4gdmlldyB0aGVyZSBpcyBvbmx5IGFuIGltcGFjdCBpZiBvbmUgb2YgdGhl IHR3byBwYXJ0aWVzIGlzIGluIGEgDQo+PiA+Pj4+PiBiZXR0ZXIgcG9zaXRpb24gdG8gZ2VuZXJh dGUgcmFuZG9tIG51bWJlcnMsIHdoaWNoIGlzIHRoZSBiYXNpcyANCj4+ID4+Pj4+IGZvciBnZW5l cmF0aW5nIGEgaGlnaCBlbnRyb3B5IHN5bW1ldHJpYyBrZXkuDQo+PiA+Pj4+Pg0KPj4gPj4+Pj4g T24gMTEvMDQvMjAxNSAxMTo1MSBQTSwgTWlrZSBKb25lcyB3cm90ZToNCj4+ID4+Pj4+PiBUaGFu a3MgZm9yIHRoZSBkZXRhaWxlZCByZWFkLCBCcmlhbi4gIFlvdeKAmXJlIHJpZ2h0IHRoYXQgaW4g dGhlIA0KPj4gPj4+Pj4+IHN5bW1ldHJpYyBjYXNlLCBlaXRoZXIgdGhlIGlzc3VlciBvciB0aGUg cHJlc2VudGVyIGNhbiBjcmVhdGUgDQo+PiA+Pj4+Pj4gdGhlIHN5bW1ldHJpYyBQb1Aga2V5IGFu ZCBzaGFyZSBpdCB3aXRoIHRoZSBvdGhlciBwYXJ0eSwgc2luY2UgDQo+PiA+Pj4+Pj4gdGhlIGVm ZmVjdCBpcyBlcXVpdmFsZW50Lg0KPj4gPj4+Pj4+IEkgc3VzcGVjdCB0aGF0IGJvdGggdGhlIGtl eSBkaXN0cmlidXRpb24gZHJhZnQgYW5kIHRoaXMgZHJhZnQgDQo+PiA+Pj4+Pj4gc2hvdWxkIGJl IHVwZGF0ZWQgd2l0aCBhIHNlbnRlbmNlIG9yIHR3byBzYXlpbmcgdGhhdCBlaXRoZXIgDQo+PiA+ Pj4+Pj4gYXBwcm9hY2ggY2FuIGJlIHRha2VuLiAgRG8gb3RoZXJzIGNvbmN1cj8NCj4+ID4+Pj4+ Pg0KPj4gPj4+Pj4+DQo+PiA+Pj4+Pj4NCj4+ID4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KPj4gPj4+Pj4+DQo+PiA+ Pj4+Pj4NCj4+ID4+Pj4+Pg0KPj4gPj4+Pj4+ICpGcm9tOipCcmlhbiBDYW1wYmVsbCBbbWFpbHRv OmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tXQ0KPj4gPj4+Pj4+ICpTZW50OiogVGh1cnNkYXks IE5vdmVtYmVyIDA1LCAyMDE1IDc6NDggQU0NCj4+ID4+Pj4+PiAqVG86KiBNaWtlIEpvbmVzDQo+ PiA+Pj4+Pj4gKkNjOiogS2VwZW5nIExpOyBvYXV0aEBpZXRmLm9yZw0KPj4gPj4+Pj4+ICpTdWJq ZWN0OiogUmU6IFtPQVVUSC1XR10gUHJvb2Ytb2YtUG9zc2Vzc2lvbiBLZXkgU2VtYW50aWNzIA0K Pj4gPj4+Pj4+IGZvciBKV1RzIHNwZWMgYWRkcmVzc2luZyBmaW5hbCBzaGVwaGVyZCBjb21tZW50 DQo+PiA+Pj4+Pj4NCj4+ID4+Pj4+Pg0KPj4gPj4+Pj4+DQo+PiA+Pj4+Pj4gKzEgZm9yIHRoZSBk aWFncmFtcyBtYWtpbmcgdGhlIGRvY3VtZW50IG1vcmUgdW5kZXJzdGFuZGFibGUuDQo+PiA+Pj4+ Pj4NCj4+ID4+Pj4+PiBPbmUgbGl0dGxlIG5pdC9xdWVzdGlvbiwgc3RlcCAxIGluIGJvdGggU3lt bWV0cmljIGFuZCANCj4+ID4+Pj4+PiBBc3ltbWV0cmljIGtleXMgc2hvd3MgdGhlIFByZXNlbnRl ciBzZW5kaW5nIHRoZSBrZXkgdG8gdGhlIA0KPj4gPj4+Pj4+IElzc3Vlci4gSXQncyBwb3NzaWJs ZSwgaG93ZXZlciwgZm9yIHRoZSBrZXkgdG8gYmUgc2VudCB0aGUgDQo+PiA+Pj4+Pj4gb3RoZXIg d2F5LiBQcmVzZW50ZXIgc2VuZGluZyBpdCB0byB0aGUgSXNzdWVyIGlzIHByb2JhYmx5IA0KPj4g Pj4+Pj4+IHByZWZlcnJlZCBmb3IgYXN5bW1ldHJpYywgZXNwZWNpYWxseSBpZiB0aGUgY2xpZW50 IGNhbiBzZWN1cmUgdGhlIHByaXZhdGUga2V5cyBpbiBoYXJkd2FyZS4NCj4+ID4+Pj4+PiBCdXQg SSBkb24ndCBrbm93IGlmIG9uZSB3YXkgb3IgdGhlIG90aGVyIGlzIGNsZWFybHkgYmV0dGVyIGZv ciANCj4+ID4+Pj4+PiBzeW1tZXRyaWMgY2FzZSBhbmQgUG9QIGtleSBkaXN0cmlidXRpb24gY3Vy cmVudGx5IGhhcyBpdCB0aGUgDQo+PiA+Pj4+Pj4gb3RoZXIgd2F5IA0KPj4gPj4+Pj4+IDxodHRw czovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzYSUy ZiUyZnRvb2xzLmlldGYub3JnJTJmaHRtbCUyZmRyYWZ0LWlldGYtb2F1dGgtcG9wLWtleS1kaXN0 cmlidXRpb24tMDIlMjNzZWN0aW9uLTQuMiZkYXRhPTAxJTdjMDElN2N0b255bmFkJTQwbWljcm9z b2Z0LmNvbSU3Yzk0NTY2NzAwNzVkMDRhNTFmODU1MDhkMmU1OWJhMjk0JTdjNzJmOTg4YmY4NmYx NDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJnNkYXRhPVVnWkVvcVFpYVVrOVZkWXBTUVJ2VWVWVk9R Z0lVZzNVbUFyMThvUTdHdEklM2Q+Lg0KPj4gPj4+Pj4+IFNob3VsZCB0aGUgaW50cm8gdGV4dCBz b21laG93IG1lbnRpb24gdGhlIHBvc3NpYmlsaXR5IHRoYXQgdGhlIA0KPj4gPj4+Pj4+IElzc3Vl ciBjb3VsZCBjcmVhdGUgdGhlIGtleSBhbmQgc2VuZCBpdCB0byB0aGUgUHJlc2VudGVyPw0KPj4g Pj4+Pj4+DQo+PiA+Pj4+Pj4gSSBrbm93IGl0J3Mgb25seSB0aGUgaW50cm9kdWN0aW9uIGJ1dCBp dCB3YXMganVzdCBzb21ldGhpbmcgDQo+PiA+Pj4+Pj4gdGhhdCBqdW1wZWQgb3V0IGF0IG1lLg0K Pj4gPj4+Pj4+DQo+PiA+Pj4+Pj4NCj4+ID4+Pj4+Pg0KPj4gPj4+Pj4+DQo+PiA+Pj4+Pj4NCj4+ ID4+Pj4+PiBPbiBXZWQsIE5vdiA0LCAyMDE1IGF0IDk6MDQgQU0sIE1pa2UgSm9uZXMgDQo+PiA+ Pj4+Pj4gPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSANCj4+ID4+Pj4+PiA8bWFpbHRvOk1p Y2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4+DQo+PiA+Pj4+Pj4gd3JvdGU6DQo+PiA+Pj4+Pj4N Cj4+ID4+Pj4+PiBUaGFua3MgZm9yIHN1Z2dlc3RpbmcgdGhlIGRpYWdyYW1zLCBLZXBlbmcuIFRo ZXkgbWFrZSB0aGUgDQo+PiA+Pj4+Pj4gZG9jdW1lbnQgbW9yZSB1bmRlcnN0YW5kYWJsZS4NCj4+ ID4+Pj4+Pg0KPj4gPj4+Pj4+IC0tIE1pa2UNCj4+ID4+Pj4+Pg0KPj4gPj4+Pj4+IC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ PiA+Pj4+Pj4gLS0tLQ0KPj4gPj4+Pj4+IC0NCj4+ID4+Pj4+PiAtLS0tLQ0KPj4gPj4+Pj4+DQo+ PiA+Pj4+Pj4gKkZyb206ICpLZXBlbmcgTGkgPG1haWx0bzprZXBlbmcubGtwQGFsaWJhYmEtaW5j LmNvbT4NCj4+ID4+Pj4+PiAqU2VudDogKuKAjjExL+KAjjUv4oCOMjAxNSAxMjo1NyBBTQ0KPj4g Pj4+Pj4+ICpUbzogKk1pa2UgSm9uZXMgPG1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5j b20+Ow0KPj4gPj4+Pj4+IG9hdXRoQGlldGYub3JnIDxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+DQo+ PiA+Pj4+Pj4gKlN1YmplY3Q6ICpSZTogUHJvb2Ytb2YtUG9zc2Vzc2lvbiBLZXkgU2VtYW50aWNz IGZvciBKV1RzIHNwZWMgDQo+PiA+Pj4+Pj4gYWRkcmVzc2luZyBmaW5hbCBzaGVwaGVyZCBjb21t ZW50DQo+PiA+Pj4+Pj4NCj4+ID4+Pj4+PiBUaGFuayB5b3UgTWlrZS4NCj4+ID4+Pj4+Pg0KPj4g Pj4+Pj4+DQo+PiA+Pj4+Pj4NCj4+ID4+Pj4+PiBUaGUgZGlhZ3JhbXMgbG9vayBnb29kIHRvIG1l Lg0KPj4gPj4+Pj4+DQo+PiA+Pj4+Pj4NCj4+ID4+Pj4+Pg0KPj4gPj4+Pj4+IEtpbmQgUmVnYXJk cw0KPj4gPj4+Pj4+DQo+PiA+Pj4+Pj4gS2VwZW5nDQo+PiA+Pj4+Pj4NCj4+ID4+Pj4+Pg0KPj4g Pj4+Pj4+DQo+PiA+Pj4+Pj4gKuWPkeS7tuS6uioqOiAqTWlrZSBKb25lcyA8TWljaGFlbC5Kb25l c0BtaWNyb3NvZnQuY29tIA0KPj4gPj4+Pj4+IDxtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3Nv ZnQuY29tPj4NCj4+ID4+Pj4+PiAq5pel5pyfKio6ICpUaHVyc2RheSwgNSBOb3ZlbWJlciwgMjAx NSAxMjozMiBhbQ0KPj4gPj4+Pj4+ICroh7MqKjogKiJvYXV0aEBpZXRmLm9yZyA8bWFpbHRvOm9h dXRoQGlldGYub3JnPiIgDQo+PiA+Pj4+Pj4gPG9hdXRoQGlldGYub3JnIDxtYWlsdG86b2F1dGhA aWV0Zi5vcmc+Pg0KPj4gPj4+Pj4+ICrmioTpgIEqKjogKkxpIEtlcGVuZyA8a2VwZW5nLmxrcEBh bGliYWJhLWluYy5jb20gDQo+PiA+Pj4+Pj4gPG1haWx0bzprZXBlbmcubGtwQGFsaWJhYmEtaW5j LmNvbT4+DQo+PiA+Pj4+Pj4gKuS4u+mimCoqOiAqUHJvb2Ytb2YtUG9zc2Vzc2lvbiBLZXkgU2Vt YW50aWNzIGZvciBKV1RzIHNwZWMgDQo+PiA+Pj4+Pj4gYWRkcmVzc2luZyBmaW5hbCBzaGVwaGVy ZCBjb21tZW50DQo+PiA+Pj4+Pj4NCj4+ID4+Pj4+Pg0KPj4gPj4+Pj4+DQo+PiA+Pj4+Pj4gUHJv b2Ytb2YtUG9zc2Vzc2lvbiBLZXkgU2VtYW50aWNzIGZvciBKV1RzIGRyYWZ0IC0wNiBhZGRyZXNz ZXMgDQo+PiA+Pj4+Pj4gdGhlIHJlbWFpbmluZyBkb2N1bWVudCBzaGVwaGVyZCBjb21tZW50IOKA kyBhZGRpbmcgdXNlIGNhc2UgDQo+PiA+Pj4+Pj4gZGlhZ3JhbXMgdG8gdGhlIGludHJvZHVjdGlv bi4NCj4+ID4+Pj4+Pg0KPj4gPj4+Pj4+DQo+PiA+Pj4+Pj4NCj4+ID4+Pj4+PiBUaGUgdXBkYXRl ZCBzcGVjaWZpY2F0aW9uIGlzIGF2YWlsYWJsZSBhdDoNCj4+ID4+Pj4+Pg0KPj4gPj4+Pj4+IMK3 DQo+PiA+Pj4+Pj4gaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29t Lz91cmw9aHR0cCUzYSUyZiUNCj4+ID4+Pj4+PiAyZnRvb2xzLmlldGYub3JnJTJmaHRtbCUyZmRy YWZ0LWlldGYtb2F1dGgtcHJvb2Ytb2YtcG9zc2Vzc2lvbg0KPj4gPj4+Pj4+IC0wNiZkYXRhPTAx JTdjMDElN2N0b255bmFkJTQwbWljcm9zb2Z0LmNvbSU3Yzk0NTY2NzAwNzVkMDRhNTFmDQo+PiA+ Pj4+Pj4gODU1MDhkMmU1OWJhMjk0JTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDcl N2MxJnNkYXRhPTYNCj4+ID4+Pj4+PiBoRTZkT08wSTElMmZmRjAwNXJWa255T0ZIdUIxOGdkcFpn OWRmdEV4THRDdyUzZA0KPj4gPj4+Pj4+DQo+PiA+Pj4+Pj4NCj4+ID4+Pj4+Pg0KPj4gPj4+Pj4+ IEFuIEhUTUwgZm9ybWF0dGVkIHZlcnNpb24gaXMgYWxzbyBhdmFpbGFibGUgYXQ6DQo+PiA+Pj4+ Pj4NCj4+ID4+Pj4+PiDCtw0KPj4gPj4+Pj4+IGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVj dGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNhJTJmDQo+PiA+Pj4+Pj4gJTJmcw0KPj4gPj4+ Pj4+IGUNCj4+ID4+Pj4+PiBsZi1pc3N1ZWQuaW5mbyUyZmRvY3MlMmZkcmFmdC1pZXRmLW9hdXRo LXByb29mLW9mLXBvc3Nlc3Npb24tMA0KPj4gPj4+Pj4+IDYuaHQNCj4+ID4+Pj4+PiBtDQo+PiA+ Pj4+Pj4gbCZkYXRhPTAxJTdjMDElN2N0b255bmFkJTQwbWljcm9zb2Z0LmNvbSU3Yzk0NTY2NzAw NzVkMDRhNTFmODUNCj4+ID4+Pj4+PiA1MDhkDQo+PiA+Pj4+Pj4gMg0KPj4gPj4+Pj4+IGU1OWJh Mjk0JTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJnNkYXRhPUVRZDRyVWN1 DQo+PiA+Pj4+Pj4geXFkUyBQIGdtaWJ0Y2ZqTXBKbTZSV1d3Q1pDODUlMmJDYm9FczU0JTNkDQo+ PiA+Pj4+Pj4NCj4+ID4+Pj4+Pg0KPj4gPj4+Pj4+DQo+PiA+Pj4+Pj4gICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCj4+ID4+Pj4+ Pg0KPj4gPj4+Pj4+DQo+PiA+Pj4+Pj4NCj4+ID4+Pj4+PiBQLlMuICBUaGlzIG5vdGUgd2FzIGFs c28gcG9zdGVkIGF0DQo+PiA+Pj4+Pj4NCj4+ID4+Pj4+PiBodHRwczovL25hMDEuc2FmZWxpbmtz LnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwJTNhJTJmJQ0KPj4gPj4+Pj4+IDJmc2Vs Zi1pc3N1ZWQuaW5mbyUyZiUzZnAlM2QxNDcxJmRhdGE9MDElN2MwMSU3Y3RvbnluYWQlNDBtaWNy DQo+PiA+Pj4+Pj4gb3NvZnQuY29tJTdjOTQ1NjY3MDA3NWQwNGE1MWY4NTUwOGQyZTU5YmEyOTQl N2M3MmY5ODhiZjg2ZjE0MWENCj4+ID4+Pj4+PiBmOTFhYjJkN2NkMDExZGI0NyU3YzEmc2RhdGE9 VE1mWDF0RzVxdWNsJTJiZTJLVnB5TUJ1ajcyWlElMmYlMg0KPj4gPj4+Pj4+IGJFS0dvVHlKeWYl MmJmSmk0JTNkDQo+PiA+Pj4+Pj4gYW5kIGFzIEBzZWxmaXNzdWVkDQo+PiA+Pj4+Pj4gPGh0dHBz Oi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNhJTJm JTJmdHdpdHRlci5jb20lMmZzZWxmaXNzdWVkJmRhdGE9MDElN2MwMSU3Y3RvbnluYWQlNDBtaWNy b3NvZnQuY29tJTdjOTQ1NjY3MDA3NWQwNGE1MWY4NTUwOGQyZTU5YmEyOTQlN2M3MmY5ODhiZjg2 ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmc2RhdGE9TGZGQWpjaHpDVGgweCUyZlk5aHIwVyUy ZlNvaFBHZ2IwSlZqTCUyZjJBeiUyZjEyQkNnJTNkPi4NCj4+ID4+Pj4+Pg0KPj4gPj4+Pj4+DQo+ PiA+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4+ID4+Pj4+PiBPQXV0aCBtYWlsaW5nIGxpc3QNCj4+ID4+Pj4+PiBPQXV0aEBpZXRmLm9yZyA8 bWFpbHRvOk9BdXRoQGlldGYub3JnPiANCj4+ID4+Pj4+PiBodHRwczovL25hMDEuc2FmZWxpbmtz LnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzYSUyZg0KPj4gPj4+Pj4+ICUyZncN Cj4+ID4+Pj4+PiB3DQo+PiA+Pj4+Pj4gdy5pZXRmLm9yZyUyZm1haWxtYW4lMmZsaXN0aW5mbyUy Zm9hdXRoJmRhdGE9MDElN2MwMSU3Y3RvbnluYWQNCj4+ID4+Pj4+PiAlNDBtDQo+PiA+Pj4+Pj4g aQ0KPj4gPj4+Pj4+IGNyb3NvZnQuY29tJTdjOTQ1NjY3MDA3NWQwNGE1MWY4NTUwOGQyZTU5YmEy OTQlN2M3MmY5ODhiZjg2ZjE0DQo+PiA+Pj4+Pj4gMWFmOQ0KPj4gPj4+Pj4+IDENCj4+ID4+Pj4+ PiBhYjJkN2NkMDExZGI0NyU3YzEmc2RhdGE9TkQzeWRhWE9zUE1zb1JoRTBVeXEwdXpuR3k2TWRZ T0xaUUpITA0KPj4gPj4+Pj4+IGhFUUsNCj4+ID4+Pj4+PiBKDQo+PiA+Pj4+Pj4gcyUzZA0KPj4g Pj4+Pj4+DQo+PiA+Pj4+Pj4NCj4+ID4+Pj4+Pg0KPj4gPj4+Pj4+DQo+PiA+Pj4+Pj4NCj4+ID4+ Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4g Pj4+Pj4+IE9BdXRoIG1haWxpbmcgbGlzdA0KPj4gPj4+Pj4+IE9BdXRoQGlldGYub3JnDQo+PiA+ Pj4+Pj4gaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9 aHR0cHMlM2ElMmYNCj4+ID4+Pj4+PiAlMmZ3DQo+PiA+Pj4+Pj4gdw0KPj4gPj4+Pj4+IHcuaWV0 Zi5vcmclMmZtYWlsbWFuJTJmbGlzdGluZm8lMmZvYXV0aCZkYXRhPTAxJTdjMDElN2N0b255bmFk DQo+PiA+Pj4+Pj4gJTQwbQ0KPj4gPj4+Pj4+IGkNCj4+ID4+Pj4+PiBjcm9zb2Z0LmNvbSU3Yzk0 NTY2NzAwNzVkMDRhNTFmODU1MDhkMmU1OWJhMjk0JTdjNzJmOTg4YmY4NmYxNA0KPj4gPj4+Pj4+ IDFhZjkNCj4+ID4+Pj4+PiAxDQo+PiA+Pj4+Pj4gYWIyZDdjZDAxMWRiNDclN2MxJnNkYXRhPU5E M3lkYVhPc1BNc29SaEUwVXlxMHV6bkd5Nk1kWU9MWlFKSEwNCj4+ID4+Pj4+PiBoRVFLDQo+PiA+ Pj4+Pj4gSg0KPj4gPj4+Pj4+IHMlM2QNCj4+ID4+Pj4+Pg0KPj4gPj4+Pj4NCj4+ID4+Pj4+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiA+Pj4+PiBP QXV0aCBtYWlsaW5nIGxpc3QNCj4+ID4+Pj4+IE9BdXRoQGlldGYub3JnDQo+PiA+Pj4+PiBodHRw czovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzYSUy ZiUNCj4+ID4+Pj4+IDJmd3cNCj4+ID4+Pj4+IHcNCj4+ID4+Pj4+IC5pZXRmLm9yZyUyZm1haWxt YW4lMmZsaXN0aW5mbyUyZm9hdXRoJmRhdGE9MDElN2MwMSU3Y3RvbnluYWQlNA0KPj4gPj4+Pj4g MG1pYw0KPj4gPj4+Pj4gcg0KPj4gPj4+Pj4gb3NvZnQuY29tJTdjOTQ1NjY3MDA3NWQwNGE1MWY4 NTUwOGQyZTU5YmEyOTQlN2M3MmY5ODhiZjg2ZjE0MWFmDQo+PiA+Pj4+PiA5MWFiDQo+PiA+Pj4+ PiAyDQo+PiA+Pj4+PiBkN2NkMDExZGI0NyU3YzEmc2RhdGE9TkQzeWRhWE9zUE1zb1JoRTBVeXEw dXpuR3k2TWRZT0xaUUpITGhFUUsNCj4+ID4+Pj4+IEpzJTMNCj4+ID4+Pj4+IGQNCj4+ID4+Pj4N Cj4+ID4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4+ID4+Pj4gT0F1dGggbWFpbGluZyBsaXN0DQo+PiA+Pj4+IE9BdXRoQGlldGYub3JnDQo+PiA+ Pj4+IGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0 dHBzJTNhJTJmJTJmd3d3Lg0KPj4gPj4+PiBpZXRmLm9yZyUyZm1haWxtYW4lMmZsaXN0aW5mbyUy Zm9hdXRoJmRhdGE9MDElN2MwMSU3Y3RvbnluYWQlNDBtDQo+PiA+Pj4+IGljcm8NCj4+ID4+Pj4g cw0KPj4gPj4+PiBvZnQuY29tJTdjOTQ1NjY3MDA3NWQwNGE1MWY4NTUwOGQyZTU5YmEyOTQlN2M3 MmY5ODhiZjg2ZjE0MWFmOTFhDQo+PiA+Pj4+IGIyZDcgYyANCj4+ID4+Pj4gZDAxMWRiNDclN2Mx JnNkYXRhPU5EM3lkYVhPc1BNc29SaEUwVXlxMHV6bkd5Nk1kWU9MWlFKSExoRVFLSnMlMw0KPj4g Pj4+PiBkDQo+PiA+Pj4NCj4+ID4+DQo+PiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPj4gPj4gT0F1dGggbWFpbGluZyBsaXN0DQo+PiA+PiBPQXV0 aEBpZXRmLm9yZw0KPj4gPj4gaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxv b2suY29tLz91cmw9aHR0cHMlM2ElMmYlMmZ3DQo+PiA+PiB3dy5pIA0KPj4gPj4gZXRmLm9yZyUy Zm1haWxtYW4lMmZsaXN0aW5mbyUyZm9hdXRoJTBhJmRhdGE9MDElN2MwMSU3Y3RvbnluYWQlNDBt DQo+PiA+PiBpY3JvIA0KPj4gPj4gc29mdC5jb20lN2M5NDU2NjcwMDc1ZDA0YTUxZjg1NTA4ZDJl NTliYTI5NCU3YzcyZjk4OGJmODZmMTQxYWY5MWFiDQo+PiA+PiAyZDdjIA0KPj4gPj4gZDAxMWRi NDclN2MxJnNkYXRhPUJMcVN1RGpXTFk3MmZHbTBVcnBMd3hRVm5hbU1lbGdnSmVPcFlKRVNWRnMl M2QNCj4+ID4NCj4+DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPj4gT0F1dGggbWFpbGluZyBsaXN0DQo+PiBPQXV0aEBpZXRmLm9yZw0KPj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KPg0KPg0KPg0KPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBPQXV0aCBtYWls aW5nIGxpc3QNCj4gT0F1dGhAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9vYXV0aA0KPg0KDQoNCg0KLS0gDQoNCkJlc3QgcmVnYXJkcywNCkthdGhsZWVu DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0 aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL29hdXRoDQo= From nobody Fri Nov 20 11:52:37 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 549E41B3300 for ; Fri, 20 Nov 2015 11:52:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.522 X-Spam-Level: * X-Spam-Status: No, score=1.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, MANGLED_AVOID=2.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yHAwVCUcnfHP for ; Fri, 20 Nov 2015 11:52:29 -0800 (PST) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::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 76B221B32A7 for ; Fri, 20 Nov 2015 11:52:29 -0800 (PST) Received: by igcph11 with SMTP id ph11so17874025igc.1 for ; Fri, 20 Nov 2015 11:52:28 -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:content-type; bh=OYja05c6sjlPSNNaelQFLNthrWsHQDG7//NVeaeLzv8=; b=cQCCmp/43PENMgmJnz8mskSQF22KKg0s3a7zuddj0MQzO9dUZgHKteX+t3kKdLrV4k YIAKM85EZFdAm1OvVzHZRZXnVJz11ZuZV49WGg2Q7voo0gYk/QgYMJCaZAWgLXkxmB67 01dr0eRE/iXLpJRk2UFXIzugJtf0Pid14UA8A= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=OYja05c6sjlPSNNaelQFLNthrWsHQDG7//NVeaeLzv8=; b=PX2JS2TDfLKFUpAWp9Ej3/MccOOZca4dYlGCoQp4UvxZHl9zfS9pZgrm2O4q5hPk7e oVw7KCYLZAs06thzy55fa8h/T5Snhs6V293gugTIZDt35ZFuOQRDjD91Tbpz5K2hElyF Jr4YFqfmmUmEPbi7UbvR2tVMEuWMklvKFyt7+5LfO1Y0nus6OnJI3dCrvirf6IDzzH7M vQFTkcH3J1PDKEj37dtntNYbLqr0DkXNLz5J543yUt2rjIMJ1n+C5I2mz9rN3+Bj/gOq 12nCn8cVhBMtatay+3CzAjXGEgPeWLblo+EwfkTrxUpEk5qTMidURgJzBI4n880GvPzJ B1WQ== X-Gm-Message-State: ALoCoQmXVYjOTZqTvkqTItM/pGguD9G7722Kwl++ose+0qjZjrHU2bbayV9ZZ9ce7XGE0vX5R3Dc X-Received: by 10.50.143.10 with SMTP id sa10mr1771933igb.77.1448049148722; Fri, 20 Nov 2015 11:52:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.117.132 with HTTP; Fri, 20 Nov 2015 11:51:59 -0800 (PST) In-Reply-To: References: <563AA216.5010109@gmx.net> <89A6E4DE-263B-4DB4-8882-54FA7103C721@mit.edu> <82079E8A-2AC8-4A42-9AF7-77FF2A3CAFC2@ve7jtb.com> <9E23AF3A-F758-4CB4-B920-4E1E2F61BCF4@ve7jtb.com> <4D05C317-FF58-4CDE-98BE-D4ED1E078526@ve7jtb.com> From: Brian Campbell Date: Fri, 20 Nov 2015 12:51:59 -0700 Message-ID: To: Mike Jones Content-Type: multipart/alternative; boundary=001a1135fe9a209b170524fe377b Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2015 19:52:35 -0000 --001a1135fe9a209b170524fe377b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Agree that the nested JWT question is really outside the scope of this document. That's would be a way to try and actually prove the possession of some key (though Chuck and I chatted offline about it some and are not convinced it's a particularly good way) while this document is just about how to indicate the key that will be proven somehow in a JWT. I do believe there's a bit of a void on the PoP protocol side of things but that's a different topic that shouldn't prevent this document from proceeding. If I recall correctly, the HSM/TPM concerns were actually raised about draft-ietf-oauth-pop-key-distribution-02 rather than this document. Something about only wrapped secret keys being exportable from certain TPMs or something like that. I'm not sure exactly what it was but don't think it pertained to this document. On Fri, Nov 20, 2015 at 12:32 PM, Mike Jones wrote: > HSM-backed public keys would be represented in the same way that other > public keys are - using the standard JWK representation for them. Likewi= se > for TPM-backed public keys. That said, I'm not an expert in TPMs and kno= w > that they define TPM-specific signature formats but to my understanding, > they're using standard kinds of keys. If this isn't the case, a new key > type ("kty") would be needed to represent them, but they'd still be > represented as a JWK in the JWT using that key type. The draft would sti= ll > work fine for these use cases as written. Does that sound right to peopl= e > or am I missing something here? > > For Chuck's nested JWT use case, that seems like it would work out as he > described it. Note that he's primarily describing the protocol messages > he's using to do the proof-of-possession - not just how to represent the > PoP key in a JWT - which is the scope of this draft. The PoP protocol > pieces are explicitly out of scope for this draft - it's just about PoP k= ey > representation. > > If I have the above right, does anyone believe that we nonetheless need t= o > do an update to the draft? If so, can you supply proposed wording or at > least the gist of the additional ideas that you'd like to have conveyed. > > Best wishes, > -- Mike > > -----Original Message----- > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Kathleen Moriart= y > Sent: Friday, November 20, 2015 11:12 AM > To: Chuck Mortimore > Cc: > Subject: Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec > addressing final shepherd comment > > Hi, > > This draft was tossed over the fence to me, but it seems that there may b= e > a few open questions that remain. Use of HSM and TPMwere raised in this > tread and not addressed in the current draft version. > > Is guidance needed for nested JWTs? If not, why? > > In a separate thread, JWK is mentioned, but I'm okay with that text as > there is a reference. > > I'd like to get this moving, os if we can wrap up these questions and if > anything will be done about them, it would be helpful. > > Thank you, > Kathleen > > On Thu, Nov 5, 2015 at 3:07 PM, Chuck Mortimore > wrote: > > The spec is very clear for most cases, but I think it could use some > > guidance on nested JWTs. (Or perhaps I've got the approach wrong.) > > > > Here's the use-case: > > We have devices that are self-issuing keys. Via token exchange, we'r= e > > going to except a self-signed JWT from the device that includes a "cnf" > > claim of the key they generated. Assuming the signature checks out o= n > > that JWT, we'll then bind that key into a "cnf" claim in a new token > > that we issue and sign with a tenant key. > > > > When the device goes to use that token, the device would sign it, > > constructing a nested JWT. The outer signature is the proof of > possession > > of the device's private key. The inner signature is our signature tha= t > > binds the public key used to validate the outer token. > > > > Does this sound correct? The processing order is a bit odd since you > first > > need to unpack and validate the inner token before you can validate the > > outer token. Is there some other way this is intended to work? > > > > thanks > > > > -cmort > > > > > > > > On Wed, Nov 4, 2015 at 8:58 PM, John Bradley wrote: > >> > >> Good to know. So the AS needs to expose a public key for the TPM to > use > >> for encryption. I am guessing you are not using a encrypted JWK for > that. > >> What is the format the TPM produces the wrapped key in? > >> > >> John B. > >> > On Nov 5, 2015, at 1:55 PM, Anthony Nadalin > >> > wrote: > >> > > >> > I can say on all windows based devices (pc, xbox, phone, etc) with > >> > only TPM 1.1 this will be the approach so it will be commonly used > >> > > >> > -----Original Message----- > >> > From: John Bradley [mailto:ve7jtb@ve7jtb.com] > >> > Sent: Wednesday, November 4, 2015 8:52 PM > >> > To: Anthony Nadalin > >> > Cc: Justin Richer ; > >> > > >> > Subject: Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs > >> > spec addressing final shepherd comment > >> > > >> > OK, no good reason unless the client is using a HSM that can do > >> > HMAC and can export a symmetric key wrapped in a asymmetric key > provided by the AS. > >> > > >> > We don=E2=80=99t currently cover that use case of sending a wrapped > >> > symmetric key to the AS in POP key distribution. > >> > I don=E2=80=99t know how common that is going to be, but it is worth > >> > thinking about defining. > >> > > >> > John B. > >> > > >> >> On Nov 5, 2015, at 1:45 PM, Anthony Nadalin > >> >> > >> >> wrote: > >> >> > >> >> Not sure why you think its weaker as it would be a wrapped key > >> >> that the hardware produces > >> >> > >> >> -----Original Message----- > >> >> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of John > >> >> Bradley > >> >> Sent: Wednesday, November 4, 2015 8:43 PM > >> >> To: Justin Richer > >> >> Cc: > >> >> Subject: Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs > >> >> spec addressing final shepherd comment > >> >> > >> >> In the asymmetric case the use of a HSM or secure element is the > >> >> argument for the client selecting the public key. In those cases > the > >> >> client is doing the key gen in hardware so one hopes it is OK. In > the > >> >> symetric case the client generating the key is weaker (as in I > >> >> can=E2=80=99t think of any really good reason). > >> >> > >> >> > >> >>> On Nov 5, 2015, at 1:35 PM, Justin Richer wrote: > >> >>> > >> >>> I=E2=80=99d argue that it=E2=80=99s best practice, and in line wit= h other parts > >> >>> of OAuth, if we assume the server generates it in the normal case > >> >>> (issuer -> presenter). Client generated token keys should be an > >> >>> exception, especially in the asymmetric case. > >> >>> > >> >>> =E2=80=94 Justin > >> >>> > >> >>>> On Nov 5, 2015, at 1:32 PM, John Bradley > wrote: > >> >>>> > >> >>>> Agreed the only real difference is the quality of the key. If > >> >>>> the server generates it, then it knows that the client is not > >> >>>> using the fixed hex value of DEADBEEF for everything. > >> >>>> > >> >>>> John B. > >> >>>>> On Nov 5, 2015, at 9:25 AM, Hannes Tschofenig > >> >>>>> wrote: > >> >>>>> > >> >>>>> I agree that the effect is the same. From a security point of > >> >>>>> view there is only an impact if one of the two parties is in a > >> >>>>> better position to generate random numbers, which is the basis > >> >>>>> for generating a high entropy symmetric key. > >> >>>>> > >> >>>>> On 11/04/2015 11:51 PM, Mike Jones wrote: > >> >>>>>> Thanks for the detailed read, Brian. You=E2=80=99re right that= in the > >> >>>>>> symmetric case, either the issuer or the presenter can create > >> >>>>>> the symmetric PoP key and share it with the other party, since > >> >>>>>> the effect is equivalent. > >> >>>>>> I suspect that both the key distribution draft and this draft > >> >>>>>> should be updated with a sentence or two saying that either > >> >>>>>> approach can be taken. Do others concur? > >> >>>>>> > >> >>>>>> > >> >>>>>> > >> >>>>>> -- Mike > >> >>>>>> > >> >>>>>> > >> >>>>>> > >> >>>>>> *From:*Brian Campbell [mailto:bcampbell@pingidentity.com] > >> >>>>>> *Sent:* Thursday, November 05, 2015 7:48 AM > >> >>>>>> *To:* Mike Jones > >> >>>>>> *Cc:* Kepeng Li; oauth@ietf.org > >> >>>>>> *Subject:* Re: [OAUTH-WG] Proof-of-Possession Key Semantics > >> >>>>>> for JWTs spec addressing final shepherd comment > >> >>>>>> > >> >>>>>> > >> >>>>>> > >> >>>>>> +1 for the diagrams making the document more understandable. > >> >>>>>> > >> >>>>>> One little nit/question, step 1 in both Symmetric and > >> >>>>>> Asymmetric keys shows the Presenter sending the key to the > >> >>>>>> Issuer. It's possible, however, for the key to be sent the > >> >>>>>> other way. Presenter sending it to the Issuer is probably > >> >>>>>> preferred for asymmetric, especially if the client can secure > the private keys in hardware. > >> >>>>>> But I don't know if one way or the other is clearly better for > >> >>>>>> symmetric case and PoP key distribution currently has it the > >> >>>>>> other way > >> >>>>>> < > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2ftools.= ietf.org%2fhtml%2fdraft-ietf-oauth-pop-key-distribution-02%23section-4.2&da= ta=3D01%7c01%7ctonynad%40microsoft.com%7c9456670075d04a51f85508d2e59ba294%7= c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=3DUgZEoqQiaUk9VdYpSQRvUeVVOQgIU= g3UmAr18oQ7GtI%3d > >. > >> >>>>>> Should the intro text somehow mention the possibility that the > >> >>>>>> Issuer could create the key and send it to the Presenter? > >> >>>>>> > >> >>>>>> I know it's only the introduction but it was just something > >> >>>>>> that jumped out at me. > >> >>>>>> > >> >>>>>> > >> >>>>>> > >> >>>>>> > >> >>>>>> > >> >>>>>> On Wed, Nov 4, 2015 at 9:04 AM, Mike Jones > >> >>>>>> >> >>>>>> > > >> >>>>>> wrote: > >> >>>>>> > >> >>>>>> Thanks for suggesting the diagrams, Kepeng. They make the > >> >>>>>> document more understandable. > >> >>>>>> > >> >>>>>> -- Mike > >> >>>>>> > >> >>>>>> -------------------------------------------------------------- > >> >>>>>> ---- > >> >>>>>> - > >> >>>>>> ----- > >> >>>>>> > >> >>>>>> *From: *Kepeng Li > >> >>>>>> *Sent: *=E2=80=8E11/=E2=80=8E5/=E2=80=8E2015 12:57 AM > >> >>>>>> *To: *Mike Jones ; > >> >>>>>> oauth@ietf.org > >> >>>>>> *Subject: *Re: Proof-of-Possession Key Semantics for JWTs spec > >> >>>>>> addressing final shepherd comment > >> >>>>>> > >> >>>>>> Thank you Mike. > >> >>>>>> > >> >>>>>> > >> >>>>>> > >> >>>>>> The diagrams look good to me. > >> >>>>>> > >> >>>>>> > >> >>>>>> > >> >>>>>> Kind Regards > >> >>>>>> > >> >>>>>> Kepeng > >> >>>>>> > >> >>>>>> > >> >>>>>> > >> >>>>>> *=E5=8F=91=E4=BB=B6=E4=BA=BA**: *Mike Jones >> >>>>>> > > >> >>>>>> *=E6=97=A5=E6=9C=9F**: *Thursday, 5 November, 2015 12:32 am > >> >>>>>> *=E8=87=B3**: *"oauth@ietf.org " > >> >>>>>> > > >> >>>>>> *=E6=8A=84=E9=80=81**: *Li Kepeng >> >>>>>> > > >> >>>>>> *=E4=B8=BB=E9=A2=98**: *Proof-of-Possession Key Semantics for J= WTs spec > >> >>>>>> addressing final shepherd comment > >> >>>>>> > >> >>>>>> > >> >>>>>> > >> >>>>>> Proof-of-Possession Key Semantics for JWTs draft -06 addresses > >> >>>>>> the remaining document shepherd comment =E2=80=93 adding use ca= se > >> >>>>>> diagrams to the introduction. > >> >>>>>> > >> >>>>>> > >> >>>>>> > >> >>>>>> The updated specification is available at: > >> >>>>>> > >> >>>>>> =C2=B7 > >> >>>>>> https://na01.safelinks.protection.outlook.com/?url=3Dhttp%3a%2f= % > >> >>>>>> 2ftools.ietf.org%2fhtml%2fdraft-ietf-oauth-proof-of-possession > >> >>>>>> -06&data=3D01%7c01%7ctonynad%40microsoft.com%7c9456670075d04a51= f > >> >>>>>> 85508d2e59ba294%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=3D= 6 > >> >>>>>> hE6dOO0I1%2ffF005rVknyOFHuB18gdpZg9dftExLtCw%3d > >> >>>>>> > >> >>>>>> > >> >>>>>> > >> >>>>>> An HTML formatted version is also available at: > >> >>>>>> > >> >>>>>> =C2=B7 > >> >>>>>> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2= f > >> >>>>>> %2fs > >> >>>>>> e > >> >>>>>> lf-issued.info%2fdocs%2fdraft-ietf-oauth-proof-of-possession-0 > >> >>>>>> 6.ht > >> >>>>>> m > >> >>>>>> l&data=3D01%7c01%7ctonynad%40microsoft.com%7c9456670075d04a51f8= 5 > >> >>>>>> 508d > >> >>>>>> 2 > >> >>>>>> e59ba294%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=3DEQd4rUc= u > >> >>>>>> yqdS P gmibtcfjMpJm6RWWwCZC85%2bCboEs54%3d > >> >>>>>> > >> >>>>>> > >> >>>>>> > >> >>>>>> -- Mike > >> >>>>>> > >> >>>>>> > >> >>>>>> > >> >>>>>> P.S. This note was also posted at > >> >>>>>> > >> >>>>>> https://na01.safelinks.protection.outlook.com/?url=3Dhttp%3a%2f= % > >> >>>>>> 2fself-issued.info%2f%3fp%3d1471&data=3D01%7c01%7ctonynad%40mic= r > >> >>>>>> osoft.com%7c9456670075d04a51f85508d2e59ba294%7c72f988bf86f141a > >> >>>>>> f91ab2d7cd011db47%7c1&sdata=3DTMfX1tG5qucl%2be2KVpyMBuj72ZQ%2f%= 2 > >> >>>>>> bEKGoTyJyf%2bfJi4%3d > >> >>>>>> and as @selfissued > >> >>>>>> < > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2ftwitte= r.com%2fselfissued&data=3D01%7c01%7ctonynad%40microsoft.com%7c9456670075d04= a51f85508d2e59ba294%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=3DLfFAjchz= CTh0x%2fY9hr0W%2fSohPGgb0JVjL%2f2Az%2f12BCg%3d > >. > >> >>>>>> > >> >>>>>> > >> >>>>>> _______________________________________________ > >> >>>>>> OAuth mailing list > >> >>>>>> OAuth@ietf.org > >> >>>>>> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2= f > >> >>>>>> %2fw > >> >>>>>> w > >> >>>>>> w.ietf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonyna= d > >> >>>>>> %40m > >> >>>>>> i > >> >>>>>> crosoft.com%7c9456670075d04a51f85508d2e59ba294%7c72f988bf86f14 > >> >>>>>> 1af9 > >> >>>>>> 1 > >> >>>>>> ab2d7cd011db47%7c1&sdata=3DND3ydaXOsPMsoRhE0Uyq0uznGy6MdYOLZQJH= L > >> >>>>>> hEQK > >> >>>>>> J > >> >>>>>> s%3d > >> >>>>>> > >> >>>>>> > >> >>>>>> > >> >>>>>> > >> >>>>>> > >> >>>>>> _______________________________________________ > >> >>>>>> OAuth mailing list > >> >>>>>> OAuth@ietf.org > >> >>>>>> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2= f > >> >>>>>> %2fw > >> >>>>>> w > >> >>>>>> w.ietf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonyna= d > >> >>>>>> %40m > >> >>>>>> i > >> >>>>>> crosoft.com%7c9456670075d04a51f85508d2e59ba294%7c72f988bf86f14 > >> >>>>>> 1af9 > >> >>>>>> 1 > >> >>>>>> ab2d7cd011db47%7c1&sdata=3DND3ydaXOsPMsoRhE0Uyq0uznGy6MdYOLZQJH= L > >> >>>>>> hEQK > >> >>>>>> J > >> >>>>>> s%3d > >> >>>>>> > >> >>>>> > >> >>>>> _______________________________________________ > >> >>>>> OAuth mailing list > >> >>>>> OAuth@ietf.org > >> >>>>> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f= % > >> >>>>> 2fww > >> >>>>> w > >> >>>>> .ietf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonynad%= 4 > >> >>>>> 0mic > >> >>>>> r > >> >>>>> osoft.com%7c9456670075d04a51f85508d2e59ba294%7c72f988bf86f141af > >> >>>>> 91ab > >> >>>>> 2 > >> >>>>> d7cd011db47%7c1&sdata=3DND3ydaXOsPMsoRhE0Uyq0uznGy6MdYOLZQJHLhEQ= K > >> >>>>> Js%3 > >> >>>>> d > >> >>>> > >> >>>> _______________________________________________ > >> >>>> OAuth mailing list > >> >>>> OAuth@ietf.org > >> >>>> > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww. > >> >>>> ietf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonynad%40= m > >> >>>> icro > >> >>>> s > >> >>>> oft.com%7c9456670075d04a51f85508d2e59ba294%7c72f988bf86f141af91a > >> >>>> b2d7 c > >> >>>> d011db47%7c1&sdata=3DND3ydaXOsPMsoRhE0Uyq0uznGy6MdYOLZQJHLhEQKJs%= 3 > >> >>>> d > >> >>> > >> >> > >> >> _______________________________________________ > >> >> OAuth mailing list > >> >> OAuth@ietf.org > >> >> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2f= w > >> >> ww.i > >> >> etf.org%2fmailman%2flistinfo%2foauth%0a&data=3D01%7c01%7ctonynad%40= m > >> >> icro > >> >> soft.com%7c9456670075d04a51f85508d2e59ba294%7c72f988bf86f141af91ab > >> >> 2d7c > >> >> d011db47%7c1&sdata=3DBLqSuDjWLY72fGm0UrpLwxQVnamMelggJeOpYJESVFs%3d > >> > > >> > >> _______________________________________________ > >> 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 > > > > > > -- > > Best regards, > Kathleen > > _______________________________________________ > 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 > --001a1135fe9a209b170524fe377b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Agree that the nested JWT question is really outside = the scope of this document. That's would be a way to try and actually p= rove the possession of some key (though Chuck and I chatted offline about i= t some and are not convinced it's a particularly good way) while this d= ocument is just about how to indicate the key that will be proven somehow i= n a JWT. I do believe there's a bit of a void on the PoP protocol side = of things but that's a different topic that shouldn't prevent this = document from proceeding.

If I recall correctly, the HSM/TPM = concerns were actually raised about draft-ietf-oauth-pop-key-distribution-0= 2 rather than this document. Something about only wrapped secret keys being= exportable from certain TPMs or something like that. I'm not sure exac= tly what it was but don't think it pertained to this document.
=



On Fri, Nov 20, 2015 at 12:32 PM, Mike Jones <Mich= ael.Jones@microsoft.com> wrote:
HSM-backed public keys would be represented in the same way that other= public keys are - using the standard JWK representation for them.=C2=A0 Li= kewise for TPM-backed public keys.=C2=A0 That said, I'm not an expert i= n TPMs and know that they define TPM-specific signature formats but to my u= nderstanding, they're using standard kinds of keys.=C2=A0 If this isn&#= 39;t the case, a new key type ("kty") would be needed to represen= t them, but they'd still be represented as a JWK in the JWT using that = key type.=C2=A0 The draft would still work fine for these use cases as writ= ten.=C2=A0 Does that sound right to people or am I missing something here?<= br>
For Chuck's nested JWT use case, that seems like it would work out as h= e described it.=C2=A0 Note that he's primarily describing the protocol = messages he's using to do the proof-of-possession - not just how to rep= resent the PoP key in a JWT - which is the scope of this draft.=C2=A0 The P= oP protocol pieces are explicitly out of scope for this draft - it's ju= st about PoP key representation.

If I have the above right, does anyone believe that we nonetheless need to = do an update to the draft?=C2=A0 If so, can you supply proposed wording or = at least the gist of the additional ideas that you'd like to have conve= yed.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Best wishes,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =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

-----Original Message-----
From: OAuth [mailto:oauth-bounces= @ietf.org] On Behalf Of Kathleen Moriarty
Sent: Friday, November 20, 2015 11:12 AM
To: Chuck Mortimore <cmorti= more@salesforce.com>
Cc: <oauth@ietf.org> <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec add= ressing final shepherd comment

Hi,

This draft was tossed over the fence to me, but it seems that there may be = a few open questions that remain.=C2=A0 Use of HSM and TPMwere raised in th= is tread and not addressed in the current draft version.

Is guidance needed for nested JWTs?=C2=A0 If not, why?

In a separate thread, JWK is mentioned, but I'm okay with that text as = there is a reference.

I'd like to get this moving, os if we can wrap up these questions and i= f anything will be done about them, it would be helpful.

Thank you,
Kathleen

On Thu, Nov 5, 2015 at 3:07 PM, Chuck Mortimore <cmortimore@salesforce.com> wrote:
> The spec is very clear for most cases, but I think it could use some > guidance on nested JWTs.=C2=A0 =C2=A0 (Or perhaps I've got the app= roach wrong.)
>
> Here's the use-case:
> We have devices that are self-issuing keys.=C2=A0 =C2=A0 Via token exc= hange, we're
> going to except a self-signed JWT from the device that includes a &quo= t;cnf"
> claim of the key they generated.=C2=A0 =C2=A0 Assuming the signature c= hecks out on
> that JWT, we'll then bind that key into a "cnf" claim in= a new token
> that we issue and sign with a tenant key.
>
> When the device goes to use that token, the device would sign it,
> constructing a nested JWT.=C2=A0 The outer signature is the proof of p= ossession
> of the device's private key.=C2=A0 =C2=A0The inner signature is ou= r signature that
> binds the public key used to validate the outer token.
>
> Does this sound correct?=C2=A0 =C2=A0The processing order is a bit odd= since you first
> need to unpack and validate the inner token before you can validate th= e
> outer token.=C2=A0 =C2=A0Is there some other way this is intended to w= ork?
>
> thanks
>
> -cmort
>
>
>
> On Wed, Nov 4, 2015 at 8:58 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
>>
>> Good to know.=C2=A0 =C2=A0So the AS needs to expose a public key f= or the TPM to use
>> for encryption.=C2=A0 =C2=A0I am guessing you are not using a encr= ypted JWK for that.
>> What is the format the TPM produces the wrapped key in?
>>
>> John B.
>> > On Nov 5, 2015, at 1:55 PM, Anthony Nadalin <tonynad@microsoft.com>
>> > wrote:
>> >
>> > I can say on all windows based devices (pc, xbox, phone, etc)= with
>> > only TPM 1.1 this will be the approach so it will be commonly= used
>> >
>> > -----Original Message-----
>> > From: John Bradley [mailto:ve7jtb@ve7jtb.com]
>> > Sent: Wednesday, November 4, 2015 8:52 PM
>> > To: Anthony Nadalin <tonynad@microsoft.com>
>> > Cc: Justin Richer <jric= her@mit.edu>; <oauth@ietf.org>
>> > <oauth@ietf.org><= br> >> > Subject: Re: [OAUTH-WG] Proof-of-Possession Key Semantics for= JWTs
>> > spec addressing final shepherd comment
>> >
>> > OK, no good reason unless the client is using a HSM that can = do
>> > HMAC and can export a symmetric key wrapped in a asymmetric k= ey provided by the AS.
>> >
>> > We don=E2=80=99t currently cover that use case of sending a w= rapped
>> > symmetric key to the AS in POP key distribution.
>> > I don=E2=80=99t know how common that is going to be, but it i= s worth
>> > thinking about defining.
>> >
>> > John B.
>> >
>> >> On Nov 5, 2015, at 1:45 PM, Anthony Nadalin
>> >> <tonynad@micr= osoft.com>
>> >> wrote:
>> >>
>> >> Not sure why you think its weaker as it would be a wrappe= d key
>> >> that the hardware produces
>> >>
>> >> -----Original Message-----
>> >> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of John
>> >> Bradley
>> >> Sent: Wednesday, November 4, 2015 8:43 PM
>> >> To: Justin Richer <= jricher@mit.edu>
>> >> Cc: <oauth@ietf.org<= /a>> <oauth@ietf.org>
>> >> Subject: Re: [OAUTH-WG] Proof-of-Possession Key Semantics= for JWTs
>> >> spec addressing final shepherd comment
>> >>
>> >> In the asymmetric case the use of a HSM or secure element= is the
>> >> argument for the client selecting the public key.=C2=A0 = =C2=A0In those cases the
>> >> client is doing the key gen in hardware so one hopes it i= s OK.=C2=A0 =C2=A0In the
>> >> symetric case the client generating the key is weaker (as= in I
>> >> can=E2=80=99t think of any really good reason).
>> >>
>> >>
>> >>> On Nov 5, 2015, at 1:35 PM, Justin Richer <jricher@mit.edu> wrote:
>> >>>
>> >>> I=E2=80=99d argue that it=E2=80=99s best practice, an= d in line with other parts
>> >>> of OAuth, if we assume the server generates it in the= normal case
>> >>> (issuer -> presenter). Client generated token keys= should be an
>> >>> exception, especially in the asymmetric case.
>> >>>
>> >>> =E2=80=94 Justin
>> >>>
>> >>>> On Nov 5, 2015, at 1:32 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
>> >>>>
>> >>>> Agreed the only real difference is the quality of= the key.=C2=A0 If
>> >>>> the server generates it, then it knows that the c= lient is not
>> >>>> using the fixed hex value of DEADBEEF for everyth= ing.
>> >>>>
>> >>>> John B.
>> >>>>> On Nov 5, 2015, at 9:25 AM, Hannes Tschofenig=
>> >>>>> <hannes.tschofenig@gmx.net> wrote:
>> >>>>>
>> >>>>> I agree that the effect is the same. From a s= ecurity point of
>> >>>>> view there is only an impact if one of the tw= o parties is in a
>> >>>>> better position to generate random numbers, w= hich is the basis
>> >>>>> for generating a high entropy symmetric key.<= br> >> >>>>>
>> >>>>> On 11/04/2015 11:51 PM, Mike Jones wrote:
>> >>>>>> Thanks for the detailed read, Brian.=C2= =A0 You=E2=80=99re right that in the
>> >>>>>> symmetric case, either the issuer or the = presenter can create
>> >>>>>> the symmetric PoP key and share it with t= he other party, since
>> >>>>>> the effect is equivalent.
>> >>>>>> I suspect that both the key distribution = draft and this draft
>> >>>>>> should be updated with a sentence or two = saying that either
>> >>>>>> approach can be taken.=C2=A0 Do others co= ncur?
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 -- Mike
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> *From:*Brian Campbell [mailto:bcampbell@pingidentity.com]
>> >>>>>> *Sent:* Thursday, November 05, 2015 7:48 = AM
>> >>>>>> *To:* Mike Jones
>> >>>>>> *Cc:* Kepeng Li; oauth@ietf.org
>> >>>>>> *Subject:* Re: [OAUTH-WG] Proof-of-Posses= sion Key Semantics
>> >>>>>> for JWTs spec addressing final shepherd c= omment
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> +1 for the diagrams making the document m= ore understandable.
>> >>>>>>
>> >>>>>> One little nit/question, step 1 in both S= ymmetric and
>> >>>>>> Asymmetric keys shows the Presenter sendi= ng the key to the
>> >>>>>> Issuer. It's possible, however, for t= he key to be sent the
>> >>>>>> other way. Presenter sending it to the Is= suer is probably
>> >>>>>> preferred for asymmetric, especially if t= he client can secure the private keys in hardware.
>> >>>>>> But I don't know if one way or the ot= her is clearly better for
>> >>>>>> symmetric case and PoP key distribution c= urrently has it the
>> >>>>>> other way
>> >>>>>> <https://na01.safelinks.protection.outlo= ok.com/?url=3Dhttps%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-ietf-oauth-pop-ke= y-distribution-02%23section-4.2&data=3D01%7c01%7ctonynad%40microsoft.co= m%7c9456670075d04a51f85508d2e59ba294%7c72f988bf86f141af91ab2d7cd011db47%7c1= &sdata=3DUgZEoqQiaUk9VdYpSQRvUeVVOQgIUg3UmAr18oQ7GtI%3d>.
>> >>>>>> Should the intro text somehow mention the= possibility that the
>> >>>>>> Issuer could create the key and send it t= o the Presenter?
>> >>>>>>
>> >>>>>> I know it's only the introduction but= it was just something
>> >>>>>> that jumped out at me.
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> On Wed, Nov 4, 2015 at 9:04 AM, Mike Jone= s
>> >>>>>> <Michael.Jones@microsoft.com
>> >>>>>> <mailto:Michael.Jones@microsoft.com>>
>> >>>>>> wrote:
>> >>>>>>
>> >>>>>> Thanks for suggesting the diagrams, Kepen= g. They make the
>> >>>>>> document more understandable.
>> >>>>>>
>> >>>>>> -- Mike
>> >>>>>>
>> >>>>>> -----------------------------------------= ---------------------
>> >>>>>> ----
>> >>>>>> -
>> >>>>>> -----
>> >>>>>>
>> >>>>>> *From: *Kepeng Li <mailto:kepeng.lkp@alibaba-inc.com>
>> >>>>>> *Sent: *=E2=80=8E11/=E2=80=8E5/=E2=80=8E2= 015 12:57 AM
>> >>>>>> *To: *Mike Jones <mailto:Michael.Jones@microsoft.com>;
>> >>>>>> oauth@i= etf.org <mailto:oauth@ietf.org= >
>> >>>>>> *Subject: *Re: Proof-of-Possession Key Se= mantics for JWTs spec
>> >>>>>> addressing final shepherd comment
>> >>>>>>
>> >>>>>> Thank you Mike.
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> The diagrams look good to me.
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> Kind Regards
>> >>>>>>
>> >>>>>> Kepeng
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> *=E5=8F=91=E4=BB=B6=E4=BA=BA**: *Mike Jon= es <Michael.Jones@microso= ft.com
>> >>>>>> <mailto:Michael.Jones@microsoft.com>>
>> >>>>>> *=E6=97=A5=E6=9C=9F**: *Thursday, 5 Novem= ber, 2015 12:32 am
>> >>>>>> *=E8=87=B3**: *"oauth@ietf.org <mailto:oauth@ietf.org>"
>> >>>>>> <oau= th@ietf.org <mailto:oauth@ietf.org= >>
>> >>>>>> *=E6=8A=84=E9=80=81**: *Li Kepeng <kepeng.lkp@alibaba-inc.com >> >>>>>> <mailto:kepeng.lkp@alibaba-inc.com>>
>> >>>>>> *=E4=B8=BB=E9=A2=98**: *Proof-of-Possessi= on Key Semantics for JWTs spec
>> >>>>>> addressing final shepherd comment
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> Proof-of-Possession Key Semantics for JWT= s draft -06 addresses
>> >>>>>> the remaining document shepherd comment = =E2=80=93 adding use case
>> >>>>>> diagrams to the introduction.
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> The updated specification is available at= :
>> >>>>>>
>> >>>>>> =C2=B7
>> >>>>>> ht= tps://na01.safelinks.protection.outlook.com/?url=3Dhttp%3a%2f%
>> >>>>>> 2ftools.ietf.org%2fhtml%2fdraft-ietf-= oauth-proof-of-possession
>> >>>>>> -06&data=3D01%7c01%7ctonynad%40microsof= t.com%7c9456670075d04a51f
>> >>>>>> 85508d2e59ba294%7c72f988bf86f141af91ab2d7= cd011db47%7c1&sdata=3D6
>> >>>>>> hE6dOO0I1%2ffF005rVknyOFHuB18gdpZg9dftExL= tCw%3d
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> An HTML formatted version is also availab= le at:
>> >>>>>>
>> >>>>>> =C2=B7
>> >>>>>> ht= tps://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f
>> >>>>>> %2fs
>> >>>>>> e
>> >>>>>> lf-issued.info%2fdocs%2fdraft-ietf-oauth-= proof-of-possession-0
>> >>>>>> 6.ht
>> >>>>>> m
>> >>>>>> l&data=3D01%7c01%7ctonynad%40microsoft.c= om%7c9456670075d04a51f85
>> >>>>>> 508d
>> >>>>>> 2
>> >>>>>> e59ba294%7c72f988bf86f141af91ab2d7cd011db= 47%7c1&sdata=3DEQd4rUcu
>> >>>>>> yqdS P gmibtcfjMpJm6RWWwCZC85= %2bCboEs54%3d
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =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
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> P.S.=C2=A0 This note was also posted at >> >>>>>>
>> >>>>>> ht= tps://na01.safelinks.protection.outlook.com/?url=3Dhttp%3a%2f%
>> >>>>>> 2fself-issued.info%2f%3fp%3d1471&= data=3D01%7c01%7ctonynad%40micr
>> >>>>>> osoft.com%7c9456670075d04a51f85508d2e59ba294%7= c72f988bf86f141a
>> >>>>>> f91ab2d7cd011db47%7c1&sdata=3DTMfX1tG= 5qucl%2be2KVpyMBuj72ZQ%2f%2
>> >>>>>> bEKGoTyJyf%2bfJi4%3d
>> >>>>>> and as @selfissued
>> >>>>>> <https://n= a01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2ftwitter.com%2fsel= fissued&data=3D01%7c01%7ctonynad%40microsoft.com%7c9456670075d04a51f855= 08d2e59ba294%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=3DLfFAjchzCTh= 0x%2fY9hr0W%2fSohPGgb0JVjL%2f2Az%2f12BCg%3d>.
>> >>>>>>
>> >>>>>>
>> >>>>>> _________________________________________= ______
>> >>>>>> OAuth mailing list
>> >>>>>> OAuth@i= etf.org <mailto:OAuth@ietf.org= >
>> >>>>>> ht= tps://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f
>> >>>>>> %2fw
>> >>>>>> w
>> >>>>>> w.ietf.org%2fmailman%2flistinfo%2foauth&d= ata=3D01%7c01%7ctonynad
>> >>>>>> %40m
>> >>>>>> i
>> >>>>>> crosoft.com%7c9456670075d04a51f85508d2e59ba2= 94%7c72f988bf86f14
>> >>>>>> 1af9
>> >>>>>> 1
>> >>>>>> ab2d7cd011db47%7c1&sdata=3DND3ydaXOsP= MsoRhE0Uyq0uznGy6MdYOLZQJHL
>> >>>>>> hEQK
>> >>>>>> J
>> >>>>>> s%3d
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> _________________________________________= ______
>> >>>>>> OAuth mailing list
>> >>>>>> OAuth@i= etf.org
>> >>>>>> ht= tps://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f
>> >>>>>> %2fw
>> >>>>>> w
>> >>>>>> w.ietf.org%2fmailman%2flistinfo%2foauth&d= ata=3D01%7c01%7ctonynad
>> >>>>>> %40m
>> >>>>>> i
>> >>>>>> crosoft.com%7c9456670075d04a51f85508d2e59ba2= 94%7c72f988bf86f14
>> >>>>>> 1af9
>> >>>>>> 1
>> >>>>>> ab2d7cd011db47%7c1&sdata=3DND3ydaXOsP= MsoRhE0Uyq0uznGy6MdYOLZQJHL
>> >>>>>> hEQK
>> >>>>>> J
>> >>>>>> s%3d
>> >>>>>>
>> >>>>>
>> >>>>> _____________________________________________= __
>> >>>>> OAuth mailing list
>> >>>>> OAuth@ietf.= org
>> >>>>> https= ://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%
>> >>>>> 2fww
>> >>>>> w
>> >>>>> .ietf.org%2fmailman%2flistinfo%2foauth&data=3D0= 1%7c01%7ctonynad%4
>> >>>>> 0mic
>> >>>>> r
>> >>>>> osoft.com%7c9456670075d04a51f85508d2e59ba294%7c72f= 988bf86f141af
>> >>>>> 91ab
>> >>>>> 2
>> >>>>> d7cd011db47%7c1&sdata=3DND3ydaXOsPMsoRhE0= Uyq0uznGy6MdYOLZQJHLhEQK
>> >>>>> Js%3
>> >>>>> d
>> >>>>
>> >>>> _______________________________________________ >> >>>> OAuth mailing list
>> >>>> OAuth@ietf.org<= /a>
>> >>>> http= s://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.
>> >>>> ietf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c0= 1%7ctonynad%40m
>> >>>> icro
>> >>>> s
>> >>>> oft.com%7c9456670075d04a51f85508d2e59ba294%7c72f988bf86f= 141af91a
>> >>>> b2d7 c
>> >>>> d011db47%7c1&sdata=3DND3ydaXOsPMsoRhE0Uyq0uzn= Gy6MdYOLZQJHLhEQKJs%3
>> >>>> d
>> >>>
>> >>
>> >> _______________________________________________
>> >> OAuth mailing list
>> >> OAuth@ietf.org
>> >> https://na01.s= afelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fw
>> >> ww.i
>> >> etf.org%2fmailman%2flistinfo%2foauth%0a&data=3D01%7c0= 1%7ctonynad%40m
>> >> icro
>> >> soft.com%7c9456670075d04a51f85508d2e59ba294%7c72f988bf86f141af9= 1ab
>> >> 2d7c
>> >> d011db47%7c1&= sdata=3DBLqSuDjWLY72fGm0UrpLwxQVnamMelggJeOpYJESVFs%3d
>> >
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth<= br> >
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>



--

Best regards,
Kathleen

_______________________________________________
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

--001a1135fe9a209b170524fe377b-- From nobody Fri Nov 20 11:53:52 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 408061B2E11 for ; Fri, 20 Nov 2015 11:53:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_21=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id trigbsUFOpMF for ; Fri, 20 Nov 2015 11:53:46 -0800 (PST) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CB7F1B335D for ; Fri, 20 Nov 2015 11:53:46 -0800 (PST) Received: by qgeb1 with SMTP id b1so80390283qge.1 for ; Fri, 20 Nov 2015 11:53:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=k8lCNoYHUJ7z8LQ9aWGElV84gV1jV+BZF3VbRX+QL/k=; b=xKTi5keilY/P38+x0d97Nvd27cPlDuPi9zZUFJUZbJd3e/7vU1eAqnU2zGndyTSjjP ojTA4eSXEqyPWSebUzZQY6jlNadQUnGlG41OGlMlcDyFOIjgijayO1CfWNh+7s7Wtl/F iPXxQqr7mrY1ZniAlNWQbe7nmSgU6dkq5CNGGuFWObXIQUWo9FLUFlxI0lYk6FMhGra3 K4W3+cnjEoQR4G4dGNcnCZ+8mDA/LfNs6ZeI6Nr3yy3KMhzPbZtNIz/Z9VSE0DuBKwB2 3OfCZQ8GyBQ69snQf5WQ2ghw+zKmCISIiiIYTUxZGzyHeY3sfqLyh+/TVMcVRW/rzNvn 0jBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=k8lCNoYHUJ7z8LQ9aWGElV84gV1jV+BZF3VbRX+QL/k=; b=JmKX5/6hUTjFVIQeGOpncqmJ/wm4NVTjaq7foSm/duXk69xLt3pnV+oZhhQZpsnjFG ufjpWRCgPMND2c9n8ASP7PQhtD66Rx/T+3mQf6iBjX4wJ/YXv37rn5W3KVF9qL/NPMU/ Z/CG9IBu0O6TcmZVPgHvtYvfaRKobGVujNDurTS9rnIPGpMk4wJZYHAt3SFUgzIMsjii 8YbF0XInPgouXAV8h4rdW1WZuLZKvr7Y2I6s6F4aGLXzfL11UmpfXXROznsVsewLqmOA SHUybmNUJIBuxu5aFiV1EwESNw5ZQ6A832QsxjCuPFuV/JcS0kn86TgEmLjXSynyqHrL DG7A== X-Gm-Message-State: ALoCoQloVKGC2z1E7mIMDVDTcAfyEDhUmHF3zFJs2zmmqaOvR5nio6g7vhbAihXdHrfImmy2N99b X-Received: by 10.140.222.80 with SMTP id s77mr15688713qhb.21.1448049225490; Fri, 20 Nov 2015 11:53:45 -0800 (PST) Received: from [192.168.1.37] ([191.115.123.36]) by smtp.gmail.com with ESMTPSA id f2sm240122qge.37.2015.11.20.11.53.43 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 20 Nov 2015 11:53:44 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: John Bradley In-Reply-To: Date: Fri, 20 Nov 2015 16:53:41 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: <8800F3C8-121C-49C1-9AEE-B050F73967F5@ve7jtb.com> References: <563AA216.5010109@gmx.net> <89A6E4DE-263B-4DB4-8882-54FA7103C721@mit.edu> <82079E8A-2AC8-4A42-9AF7-77FF2A3CAFC2@ve7jtb.com> <9E23AF3A-F758-4CB4-B920-4E1E2F61BCF4@ve7jtb.com> <4D05C317-FF58-4CDE-98BE-D4ED1E078526@ve7jtb.com> To: Michael Jones X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2015 19:53:50 -0000 I don=E2=80=99t know of any special requirements for representing HSM = keys. =20 How they are negotiated and stored is out of scope for this draft. I think Brian mentioned that we had an example that is different from = the default in the POP drafts. That can be looked at. I don=E2=80=99t think we want to get into key management. That should = be left to specifications that use this. Chuck=E2=80=99s example gets into proof mechanisms for token = presentment. That is also out of scope for this draft. There are two mechanisms as = part of the POP specs. One is mutual TLS and the other is using a signed message. =20 I think the signed message one is what he is looking for. =20 https://tools.ietf.org/html/draft-ietf-oauth-signed-http-request-01 I suppose that you could over sign the token itself but there are = perhaps better ways to do it. So if wrapping rules are needed that would probably be part of a pop = token proof presentment spec. John B. > On Nov 20, 2015, at 4:32 PM, Mike Jones = wrote: >=20 > HSM-backed public keys would be represented in the same way that other = public keys are - using the standard JWK representation for them. = Likewise for TPM-backed public keys. That said, I'm not an expert in = TPMs and know that they define TPM-specific signature formats but to my = understanding, they're using standard kinds of keys. If this isn't the = case, a new key type ("kty") would be needed to represent them, but = they'd still be represented as a JWK in the JWT using that key type. = The draft would still work fine for these use cases as written. Does = that sound right to people or am I missing something here? >=20 > For Chuck's nested JWT use case, that seems like it would work out as = he described it. Note that he's primarily describing the protocol = messages he's using to do the proof-of-possession - not just how to = represent the PoP key in a JWT - which is the scope of this draft. The = PoP protocol pieces are explicitly out of scope for this draft - it's = just about PoP key representation. >=20 > If I have the above right, does anyone believe that we nonetheless = need to do an update to the draft? If so, can you supply proposed = wording or at least the gist of the additional ideas that you'd like to = have conveyed. >=20 > Best wishes, > -- Mike >=20 > -----Original Message----- > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Kathleen = Moriarty > Sent: Friday, November 20, 2015 11:12 AM > To: Chuck Mortimore > Cc: > Subject: Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs = spec addressing final shepherd comment >=20 > Hi, >=20 > This draft was tossed over the fence to me, but it seems that there = may be a few open questions that remain. Use of HSM and TPMwere raised = in this tread and not addressed in the current draft version. >=20 > Is guidance needed for nested JWTs? If not, why? >=20 > In a separate thread, JWK is mentioned, but I'm okay with that text as = there is a reference. >=20 > I'd like to get this moving, os if we can wrap up these questions and = if anything will be done about them, it would be helpful. >=20 > Thank you, > Kathleen >=20 > On Thu, Nov 5, 2015 at 3:07 PM, Chuck Mortimore = wrote: >> The spec is very clear for most cases, but I think it could use some >> guidance on nested JWTs. (Or perhaps I've got the approach wrong.) >>=20 >> Here's the use-case: >> We have devices that are self-issuing keys. Via token exchange, = we're >> going to except a self-signed JWT from the device that includes a = "cnf" >> claim of the key they generated. Assuming the signature checks out = on >> that JWT, we'll then bind that key into a "cnf" claim in a new token=20= >> that we issue and sign with a tenant key. >>=20 >> When the device goes to use that token, the device would sign it,=20 >> constructing a nested JWT. The outer signature is the proof of = possession >> of the device's private key. The inner signature is our signature = that >> binds the public key used to validate the outer token. >>=20 >> Does this sound correct? The processing order is a bit odd since = you first >> need to unpack and validate the inner token before you can validate = the >> outer token. Is there some other way this is intended to work? >>=20 >> thanks >>=20 >> -cmort >>=20 >>=20 >>=20 >> On Wed, Nov 4, 2015 at 8:58 PM, John Bradley = wrote: >>>=20 >>> Good to know. So the AS needs to expose a public key for the TPM = to use >>> for encryption. I am guessing you are not using a encrypted JWK = for that. >>> What is the format the TPM produces the wrapped key in? >>>=20 >>> John B. >>>> On Nov 5, 2015, at 1:55 PM, Anthony Nadalin >>>> wrote: >>>>=20 >>>> I can say on all windows based devices (pc, xbox, phone, etc) with=20= >>>> only TPM 1.1 this will be the approach so it will be commonly used >>>>=20 >>>> -----Original Message----- >>>> From: John Bradley [mailto:ve7jtb@ve7jtb.com] >>>> Sent: Wednesday, November 4, 2015 8:52 PM >>>> To: Anthony Nadalin >>>> Cc: Justin Richer ; =20 >>>> >>>> Subject: Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs=20= >>>> spec addressing final shepherd comment >>>>=20 >>>> OK, no good reason unless the client is using a HSM that can do=20 >>>> HMAC and can export a symmetric key wrapped in a asymmetric key = provided by the AS. >>>>=20 >>>> We don=E2=80=99t currently cover that use case of sending a wrapped=20= >>>> symmetric key to the AS in POP key distribution. >>>> I don=E2=80=99t know how common that is going to be, but it is = worth=20 >>>> thinking about defining. >>>>=20 >>>> John B. >>>>=20 >>>>> On Nov 5, 2015, at 1:45 PM, Anthony Nadalin=20 >>>>> >>>>> wrote: >>>>>=20 >>>>> Not sure why you think its weaker as it would be a wrapped key=20 >>>>> that the hardware produces >>>>>=20 >>>>> -----Original Message----- >>>>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of John=20 >>>>> Bradley >>>>> Sent: Wednesday, November 4, 2015 8:43 PM >>>>> To: Justin Richer >>>>> Cc: >>>>> Subject: Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs=20= >>>>> spec addressing final shepherd comment >>>>>=20 >>>>> In the asymmetric case the use of a HSM or secure element is the >>>>> argument for the client selecting the public key. In those cases = the >>>>> client is doing the key gen in hardware so one hopes it is OK. = In the >>>>> symetric case the client generating the key is weaker (as in I=20 >>>>> can=E2=80=99t think of any really good reason). >>>>>=20 >>>>>=20 >>>>>> On Nov 5, 2015, at 1:35 PM, Justin Richer = wrote: >>>>>>=20 >>>>>> I=E2=80=99d argue that it=E2=80=99s best practice, and in line = with other parts=20 >>>>>> of OAuth, if we assume the server generates it in the normal case=20= >>>>>> (issuer -> presenter). Client generated token keys should be an=20= >>>>>> exception, especially in the asymmetric case. >>>>>>=20 >>>>>> =E2=80=94 Justin >>>>>>=20 >>>>>>> On Nov 5, 2015, at 1:32 PM, John Bradley = wrote: >>>>>>>=20 >>>>>>> Agreed the only real difference is the quality of the key. If=20= >>>>>>> the server generates it, then it knows that the client is not=20 >>>>>>> using the fixed hex value of DEADBEEF for everything. >>>>>>>=20 >>>>>>> John B. >>>>>>>> On Nov 5, 2015, at 9:25 AM, Hannes Tschofenig=20 >>>>>>>> wrote: >>>>>>>>=20 >>>>>>>> I agree that the effect is the same. =46rom a security point of=20= >>>>>>>> view there is only an impact if one of the two parties is in a=20= >>>>>>>> better position to generate random numbers, which is the basis=20= >>>>>>>> for generating a high entropy symmetric key. >>>>>>>>=20 >>>>>>>> On 11/04/2015 11:51 PM, Mike Jones wrote: >>>>>>>>> Thanks for the detailed read, Brian. You=E2=80=99re right = that in the=20 >>>>>>>>> symmetric case, either the issuer or the presenter can create=20= >>>>>>>>> the symmetric PoP key and share it with the other party, since=20= >>>>>>>>> the effect is equivalent. >>>>>>>>> I suspect that both the key distribution draft and this draft=20= >>>>>>>>> should be updated with a sentence or two saying that either=20 >>>>>>>>> approach can be taken. Do others concur? >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> -- Mike >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> *From:*Brian Campbell [mailto:bcampbell@pingidentity.com] >>>>>>>>> *Sent:* Thursday, November 05, 2015 7:48 AM >>>>>>>>> *To:* Mike Jones >>>>>>>>> *Cc:* Kepeng Li; oauth@ietf.org >>>>>>>>> *Subject:* Re: [OAUTH-WG] Proof-of-Possession Key Semantics=20 >>>>>>>>> for JWTs spec addressing final shepherd comment >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> +1 for the diagrams making the document more understandable. >>>>>>>>>=20 >>>>>>>>> One little nit/question, step 1 in both Symmetric and=20 >>>>>>>>> Asymmetric keys shows the Presenter sending the key to the=20 >>>>>>>>> Issuer. It's possible, however, for the key to be sent the=20 >>>>>>>>> other way. Presenter sending it to the Issuer is probably=20 >>>>>>>>> preferred for asymmetric, especially if the client can secure = the private keys in hardware. >>>>>>>>> But I don't know if one way or the other is clearly better for=20= >>>>>>>>> symmetric case and PoP key distribution currently has it the=20= >>>>>>>>> other way=20 >>>>>>>>> = . >>>>>>>>> Should the intro text somehow mention the possibility that the=20= >>>>>>>>> Issuer could create the key and send it to the Presenter? >>>>>>>>>=20 >>>>>>>>> I know it's only the introduction but it was just something=20 >>>>>>>>> that jumped out at me. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> On Wed, Nov 4, 2015 at 9:04 AM, Mike Jones=20 >>>>>>>>> >>>>>>>> > >>>>>>>>> wrote: >>>>>>>>>=20 >>>>>>>>> Thanks for suggesting the diagrams, Kepeng. They make the=20 >>>>>>>>> document more understandable. >>>>>>>>>=20 >>>>>>>>> -- Mike >>>>>>>>>=20 >>>>>>>>> -------------------------------------------------------------- >>>>>>>>> ---- >>>>>>>>> - >>>>>>>>> ----- >>>>>>>>>=20 >>>>>>>>> *From: *Kepeng Li >>>>>>>>> *Sent: *=E2=80=8E11/=E2=80=8E5/=E2=80=8E2015 12:57 AM >>>>>>>>> *To: *Mike Jones ; >>>>>>>>> oauth@ietf.org >>>>>>>>> *Subject: *Re: Proof-of-Possession Key Semantics for JWTs spec=20= >>>>>>>>> addressing final shepherd comment >>>>>>>>>=20 >>>>>>>>> Thank you Mike. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> The diagrams look good to me. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Kind Regards >>>>>>>>>=20 >>>>>>>>> Kepeng >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> *=E5=8F=91=E4=BB=B6=E4=BA=BA**: *Mike Jones = >>>>>>>> > >>>>>>>>> *=E6=97=A5=E6=9C=9F**: *Thursday, 5 November, 2015 12:32 am >>>>>>>>> *=E8=87=B3**: *"oauth@ietf.org "=20 >>>>>>>>> > >>>>>>>>> *=E6=8A=84=E9=80=81**: *Li Kepeng >>>>>>>> > >>>>>>>>> *=E4=B8=BB=E9=A2=98**: *Proof-of-Possession Key Semantics for = JWTs spec=20 >>>>>>>>> addressing final shepherd comment >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Proof-of-Possession Key Semantics for JWTs draft -06 addresses=20= >>>>>>>>> the remaining document shepherd comment =E2=80=93 adding use = case=20 >>>>>>>>> diagrams to the introduction. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> The updated specification is available at: >>>>>>>>>=20 >>>>>>>>> =C2=B7 >>>>>>>>> https://na01.safelinks.protection.outlook.com/?url=3Dhttp%3a%2f%= >>>>>>>>> 2ftools.ietf.org%2fhtml%2fdraft-ietf-oauth-proof-of-possession >>>>>>>>> -06&data=3D01%7c01%7ctonynad%40microsoft.com%7c9456670075d04a51f= >>>>>>>>> 85508d2e59ba294%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=3D6= >>>>>>>>> hE6dOO0I1%2ffF005rVknyOFHuB18gdpZg9dftExLtCw%3d >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> An HTML formatted version is also available at: >>>>>>>>>=20 >>>>>>>>> =C2=B7 >>>>>>>>> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f= >>>>>>>>> %2fs >>>>>>>>> e >>>>>>>>> lf-issued.info%2fdocs%2fdraft-ietf-oauth-proof-of-possession-0 >>>>>>>>> 6.ht >>>>>>>>> m >>>>>>>>> l&data=3D01%7c01%7ctonynad%40microsoft.com%7c9456670075d04a51f85= >>>>>>>>> 508d >>>>>>>>> 2 >>>>>>>>> e59ba294%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=3DEQd4rUcu= >>>>>>>>> yqdS P gmibtcfjMpJm6RWWwCZC85%2bCboEs54%3d >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> -- Mike >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> P.S. This note was also posted at >>>>>>>>>=20 >>>>>>>>> https://na01.safelinks.protection.outlook.com/?url=3Dhttp%3a%2f%= >>>>>>>>> 2fself-issued.info%2f%3fp%3d1471&data=3D01%7c01%7ctonynad%40micr= >>>>>>>>> osoft.com%7c9456670075d04a51f85508d2e59ba294%7c72f988bf86f141a >>>>>>>>> f91ab2d7cd011db47%7c1&sdata=3DTMfX1tG5qucl%2be2KVpyMBuj72ZQ%2f%2= >>>>>>>>> bEKGoTyJyf%2bfJi4%3d >>>>>>>>> and as @selfissued >>>>>>>>> = . >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> OAuth mailing list >>>>>>>>> OAuth@ietf.org =20 >>>>>>>>> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f= >>>>>>>>> %2fw >>>>>>>>> w >>>>>>>>> w.ietf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonynad= >>>>>>>>> %40m >>>>>>>>> i >>>>>>>>> crosoft.com%7c9456670075d04a51f85508d2e59ba294%7c72f988bf86f14 >>>>>>>>> 1af9 >>>>>>>>> 1 >>>>>>>>> ab2d7cd011db47%7c1&sdata=3DND3ydaXOsPMsoRhE0Uyq0uznGy6MdYOLZQJHL= >>>>>>>>> hEQK >>>>>>>>> J >>>>>>>>> s%3d >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> OAuth mailing list >>>>>>>>> OAuth@ietf.org >>>>>>>>> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f= >>>>>>>>> %2fw >>>>>>>>> w >>>>>>>>> w.ietf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonynad= >>>>>>>>> %40m >>>>>>>>> i >>>>>>>>> crosoft.com%7c9456670075d04a51f85508d2e59ba294%7c72f988bf86f14 >>>>>>>>> 1af9 >>>>>>>>> 1 >>>>>>>>> ab2d7cd011db47%7c1&sdata=3DND3ydaXOsPMsoRhE0Uyq0uznGy6MdYOLZQJHL= >>>>>>>>> hEQK >>>>>>>>> J >>>>>>>>> s%3d >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing list >>>>>>>> OAuth@ietf.org >>>>>>>> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%= >>>>>>>> 2fww >>>>>>>> w >>>>>>>> .ietf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonynad%4= >>>>>>>> 0mic >>>>>>>> r >>>>>>>> osoft.com%7c9456670075d04a51f85508d2e59ba294%7c72f988bf86f141af >>>>>>>> 91ab >>>>>>>> 2 >>>>>>>> d7cd011db47%7c1&sdata=3DND3ydaXOsPMsoRhE0Uyq0uznGy6MdYOLZQJHLhEQK= >>>>>>>> Js%3 >>>>>>>> d >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> = https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww. >>>>>>> ietf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonynad%40m= >>>>>>> icro >>>>>>> s >>>>>>> oft.com%7c9456670075d04a51f85508d2e59ba294%7c72f988bf86f141af91a >>>>>>> b2d7 c=20 >>>>>>> d011db47%7c1&sdata=3DND3ydaXOsPMsoRhE0Uyq0uznGy6MdYOLZQJHLhEQKJs%3= >>>>>>> d >>>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fw= >>>>> ww.i=20 >>>>> etf.org%2fmailman%2flistinfo%2foauth%0a&data=3D01%7c01%7ctonynad%40m= >>>>> icro=20 >>>>> soft.com%7c9456670075d04a51f85508d2e59ba294%7c72f988bf86f141af91ab >>>>> 2d7c=20 >>>>> d011db47%7c1&sdata=3DBLqSuDjWLY72fGm0UrpLwxQVnamMelggJeOpYJESVFs%3d >>>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >=20 >=20 >=20 > --=20 >=20 > Best regards, > Kathleen >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Fri Nov 20 12:11:57 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AE541B33E1 for ; Fri, 20 Nov 2015 12:11:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 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, J_CHICKENPOX_21=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mJWfsuGivh6v for ; Fri, 20 Nov 2015 12:11:52 -0800 (PST) Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE7B91B33D8 for ; Fri, 20 Nov 2015 12:11:51 -0800 (PST) Received: by vkbs1 with SMTP id s1so4970793vkb.1 for ; Fri, 20 Nov 2015 12:11:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=egiGqHRhxKS0MtKwzfezyx2McbzFLXTvjab/1/eAih4=; b=lAW9WjfSOd0eJxX9I+2VXvUOdpAugzECIEmnWxeh2IoEk/8Y6P246R5S9xtazL3dV1 ussLVqRhBlGr5x2d9uvoFlOnJ5ko3kWJ3vPVSY4cUBnYXJNoIZ10njxbhPa/cpvwqDQj mgBeXE22Q5jeizlsgUck2lmkrpPoce7zsRafr6W151FSA1ijI4VtezXkZNaBw0MfPT6S kVsoSPna0dTL2wL0KcXZFRxJhVobHxHt2ECxh7eIShE1IaS2nOdXcI5r87dpHnRg4tms Qw91Ip5x6QuhtZlTNs/Ujw/e2mlV/RgkI3xwCGuiwsjBPPzm66LK75n3qguoBhmcN+F8 gbdw== X-Received: by 10.31.157.196 with SMTP id g187mr1336417vke.72.1448050310863; Fri, 20 Nov 2015 12:11:50 -0800 (PST) Received: from [172.20.3.0] ([65.200.157.66]) by smtp.gmail.com with ESMTPSA id o66sm791320vkf.2.2015.11.20.12.11.49 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 20 Nov 2015 12:11:49 -0800 (PST) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (12H143) In-Reply-To: <8800F3C8-121C-49C1-9AEE-B050F73967F5@ve7jtb.com> Date: Fri, 20 Nov 2015 15:11:48 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <563AA216.5010109@gmx.net> <89A6E4DE-263B-4DB4-8882-54FA7103C721@mit.edu> <82079E8A-2AC8-4A42-9AF7-77FF2A3CAFC2@ve7jtb.com> <9E23AF3A-F758-4CB4-B920-4E1E2F61BCF4@ve7jtb.com> <4D05C317-FF58-4CDE-98BE-D4ED1E078526@ve7jtb.com> <8800F3C8-121C-49C1-9AEE-B050F73967F5@ve7jtb.com> To: John Bradley Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2015 20:11:56 -0000 Sent from my iPhone > On Nov 20, 2015, at 2:53 PM, John Bradley wrote: >=20 > I don=E2=80=99t know of any special requirements for representing HSM keys= . =20 I wasn't suggesting that there were separate requirements or different key t= ypes as that would not be the case, just that the discussions did not seem t= o be complete.=20 >=20 > How they are negotiated and stored is out of scope for this draft. >=20 > I think Brian mentioned that we had an example that is different from the d= efault in the POP drafts. That can be looked at. >=20 > I don=E2=80=99t think we want to get into key management. That should be l= eft to specifications that use this. >=20 > Chuck=E2=80=99s example gets into proof mechanisms for token presentment. > That is also out of scope for this draft. There are two mechanisms as pa= rt of the POP specs. Ok, sounds good. Thanks. > One is mutual TLS and the other is using a signed message. =20 > I think the signed message one is what he is looking for. =20 > https://tools.ietf.org/html/draft-ietf-oauth-signed-http-request-01 >=20 > I suppose that you could over sign the token itself but there are perhaps b= etter ways to do it. > So if wrapping rules are needed that would probably be part of a pop token= proof presentment spec. Ok, thanks. Kathleen=20 >=20 >=20 > John B. >=20 >> On Nov 20, 2015, at 4:32 PM, Mike Jones wro= te: >>=20 >> HSM-backed public keys would be represented in the same way that other pu= blic keys are - using the standard JWK representation for them. Likewise fo= r TPM-backed public keys. That said, I'm not an expert in TPMs and know tha= t they define TPM-specific signature formats but to my understanding, they'r= e using standard kinds of keys. If this isn't the case, a new key type ("kt= y") would be needed to represent them, but they'd still be represented as a J= WK in the JWT using that key type. The draft would still work fine for thes= e use cases as written. Does that sound right to people or am I missing som= ething here? >>=20 >> For Chuck's nested JWT use case, that seems like it would work out as he d= escribed it. Note that he's primarily describing the protocol messages he's= using to do the proof-of-possession - not just how to represent the PoP key= in a JWT - which is the scope of this draft. The PoP protocol pieces are e= xplicitly out of scope for this draft - it's just about PoP key representati= on. >>=20 >> If I have the above right, does anyone believe that we nonetheless need t= o do an update to the draft? If so, can you supply proposed wording or at l= east the gist of the additional ideas that you'd like to have conveyed. >>=20 >> Best wishes, >> -- Mike >>=20 >> -----Original Message----- >> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Kathleen Moriart= y >> Sent: Friday, November 20, 2015 11:12 AM >> To: Chuck Mortimore >> Cc: >> Subject: Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec a= ddressing final shepherd comment >>=20 >> Hi, >>=20 >> This draft was tossed over the fence to me, but it seems that there may b= e a few open questions that remain. Use of HSM and TPMwere raised in this t= read and not addressed in the current draft version. >>=20 >> Is guidance needed for nested JWTs? If not, why? >>=20 >> In a separate thread, JWK is mentioned, but I'm okay with that text as th= ere is a reference. >>=20 >> I'd like to get this moving, os if we can wrap up these questions and if a= nything will be done about them, it would be helpful. >>=20 >> Thank you, >> Kathleen >>=20 >>> On Thu, Nov 5, 2015 at 3:07 PM, Chuck Mortimore wrote: >>> The spec is very clear for most cases, but I think it could use some >>> guidance on nested JWTs. (Or perhaps I've got the approach wrong.) >>>=20 >>> Here's the use-case: >>> We have devices that are self-issuing keys. Via token exchange, we're= >>> going to except a self-signed JWT from the device that includes a "cnf" >>> claim of the key they generated. Assuming the signature checks out on= >>> that JWT, we'll then bind that key into a "cnf" claim in a new token=20 >>> that we issue and sign with a tenant key. >>>=20 >>> When the device goes to use that token, the device would sign it,=20 >>> constructing a nested JWT. The outer signature is the proof of possessi= on >>> of the device's private key. The inner signature is our signature that= >>> binds the public key used to validate the outer token. >>>=20 >>> Does this sound correct? The processing order is a bit odd since you f= irst >>> need to unpack and validate the inner token before you can validate the >>> outer token. Is there some other way this is intended to work? >>>=20 >>> thanks >>>=20 >>> -cmort >>>=20 >>>=20 >>>=20 >>>> On Wed, Nov 4, 2015 at 8:58 PM, John Bradley wrote:= >>>>=20 >>>> Good to know. So the AS needs to expose a public key for the TPM to u= se >>>> for encryption. I am guessing you are not using a encrypted JWK for t= hat. >>>> What is the format the TPM produces the wrapped key in? >>>>=20 >>>> John B. >>>>> On Nov 5, 2015, at 1:55 PM, Anthony Nadalin >>>>> wrote: >>>>>=20 >>>>> I can say on all windows based devices (pc, xbox, phone, etc) with=20 >>>>> only TPM 1.1 this will be the approach so it will be commonly used >>>>>=20 >>>>> -----Original Message----- >>>>> From: John Bradley [mailto:ve7jtb@ve7jtb.com] >>>>> Sent: Wednesday, November 4, 2015 8:52 PM >>>>> To: Anthony Nadalin >>>>> Cc: Justin Richer ; =20 >>>>> >>>>> Subject: Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs=20 >>>>> spec addressing final shepherd comment >>>>>=20 >>>>> OK, no good reason unless the client is using a HSM that can do=20 >>>>> HMAC and can export a symmetric key wrapped in a asymmetric key provid= ed by the AS. >>>>>=20 >>>>> We don=E2=80=99t currently cover that use case of sending a wrapped=20= >>>>> symmetric key to the AS in POP key distribution. >>>>> I don=E2=80=99t know how common that is going to be, but it is worth=20= >>>>> thinking about defining. >>>>>=20 >>>>> John B. >>>>>=20 >>>>>> On Nov 5, 2015, at 1:45 PM, Anthony Nadalin=20 >>>>>> >>>>>> wrote: >>>>>>=20 >>>>>> Not sure why you think its weaker as it would be a wrapped key=20 >>>>>> that the hardware produces >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of John=20 >>>>>> Bradley >>>>>> Sent: Wednesday, November 4, 2015 8:43 PM >>>>>> To: Justin Richer >>>>>> Cc: >>>>>> Subject: Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs=20= >>>>>> spec addressing final shepherd comment >>>>>>=20 >>>>>> In the asymmetric case the use of a HSM or secure element is the >>>>>> argument for the client selecting the public key. In those cases th= e >>>>>> client is doing the key gen in hardware so one hopes it is OK. In t= he >>>>>> symetric case the client generating the key is weaker (as in I=20 >>>>>> can=E2=80=99t think of any really good reason). >>>>>>=20 >>>>>>=20 >>>>>>> On Nov 5, 2015, at 1:35 PM, Justin Richer wrote: >>>>>>>=20 >>>>>>> I=E2=80=99d argue that it=E2=80=99s best practice, and in line with o= ther parts=20 >>>>>>> of OAuth, if we assume the server generates it in the normal case=20= >>>>>>> (issuer -> presenter). Client generated token keys should be an=20 >>>>>>> exception, especially in the asymmetric case. >>>>>>>=20 >>>>>>> =E2=80=94 Justin >>>>>>>=20 >>>>>>>> On Nov 5, 2015, at 1:32 PM, John Bradley wrote:= >>>>>>>>=20 >>>>>>>> Agreed the only real difference is the quality of the key. If=20 >>>>>>>> the server generates it, then it knows that the client is not=20 >>>>>>>> using the fixed hex value of DEADBEEF for everything. >>>>>>>>=20 >>>>>>>> John B. >>>>>>>>> On Nov 5, 2015, at 9:25 AM, Hannes Tschofenig=20 >>>>>>>>> wrote: >>>>>>>>>=20 >>>>>>>>> I agree that the effect is the same. =46rom a security point of=20= >>>>>>>>> view there is only an impact if one of the two parties is in a=20 >>>>>>>>> better position to generate random numbers, which is the basis=20 >>>>>>>>> for generating a high entropy symmetric key. >>>>>>>>>=20 >>>>>>>>>> On 11/04/2015 11:51 PM, Mike Jones wrote: >>>>>>>>>> Thanks for the detailed read, Brian. You=E2=80=99re right that i= n the=20 >>>>>>>>>> symmetric case, either the issuer or the presenter can create=20 >>>>>>>>>> the symmetric PoP key and share it with the other party, since=20= >>>>>>>>>> the effect is equivalent. >>>>>>>>>> I suspect that both the key distribution draft and this draft=20 >>>>>>>>>> should be updated with a sentence or two saying that either=20 >>>>>>>>>> approach can be taken. Do others concur? >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> -- Mike >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> *From:*Brian Campbell [mailto:bcampbell@pingidentity.com] >>>>>>>>>> *Sent:* Thursday, November 05, 2015 7:48 AM >>>>>>>>>> *To:* Mike Jones >>>>>>>>>> *Cc:* Kepeng Li; oauth@ietf.org >>>>>>>>>> *Subject:* Re: [OAUTH-WG] Proof-of-Possession Key Semantics=20 >>>>>>>>>> for JWTs spec addressing final shepherd comment >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> +1 for the diagrams making the document more understandable. >>>>>>>>>>=20 >>>>>>>>>> One little nit/question, step 1 in both Symmetric and=20 >>>>>>>>>> Asymmetric keys shows the Presenter sending the key to the=20 >>>>>>>>>> Issuer. It's possible, however, for the key to be sent the=20 >>>>>>>>>> other way. Presenter sending it to the Issuer is probably=20 >>>>>>>>>> preferred for asymmetric, especially if the client can secure the= private keys in hardware. >>>>>>>>>> But I don't know if one way or the other is clearly better for=20= >>>>>>>>>> symmetric case and PoP key distribution currently has it the=20 >>>>>>>>>> other way=20 >>>>>>>>>> . >>>>>>>>>> Should the intro text somehow mention the possibility that the=20= >>>>>>>>>> Issuer could create the key and send it to the Presenter? >>>>>>>>>>=20 >>>>>>>>>> I know it's only the introduction but it was just something=20 >>>>>>>>>> that jumped out at me. >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> On Wed, Nov 4, 2015 at 9:04 AM, Mike Jones=20 >>>>>>>>>> >>>>>>>>> > >>>>>>>>>> wrote: >>>>>>>>>>=20 >>>>>>>>>> Thanks for suggesting the diagrams, Kepeng. They make the=20 >>>>>>>>>> document more understandable. >>>>>>>>>>=20 >>>>>>>>>> -- Mike >>>>>>>>>>=20 >>>>>>>>>> -------------------------------------------------------------- >>>>>>>>>> ---- >>>>>>>>>> - >>>>>>>>>> ----- >>>>>>>>>>=20 >>>>>>>>>> *From: *Kepeng Li >>>>>>>>>> *Sent: *=E2=80=8E11/=E2=80=8E5/=E2=80=8E2015 12:57 AM >>>>>>>>>> *To: *Mike Jones ; >>>>>>>>>> oauth@ietf.org >>>>>>>>>> *Subject: *Re: Proof-of-Possession Key Semantics for JWTs spec=20= >>>>>>>>>> addressing final shepherd comment >>>>>>>>>>=20 >>>>>>>>>> Thank you Mike. >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> The diagrams look good to me. >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Kind Regards >>>>>>>>>>=20 >>>>>>>>>> Kepeng >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> *=E5=8F=91=E4=BB=B6=E4=BA=BA**: *Mike Jones >>>>>>>>> > >>>>>>>>>> *=E6=97=A5=E6=9C=9F**: *Thursday, 5 November, 2015 12:32 am >>>>>>>>>> *=E8=87=B3**: *"oauth@ietf.org "=20 >>>>>>>>>> > >>>>>>>>>> *=E6=8A=84=E9=80=81**: *Li Kepeng >>>>>>>>> > >>>>>>>>>> *=E4=B8=BB=E9=A2=98**: *Proof-of-Possession Key Semantics for JWT= s spec=20 >>>>>>>>>> addressing final shepherd comment >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Proof-of-Possession Key Semantics for JWTs draft -06 addresses=20= >>>>>>>>>> the remaining document shepherd comment =E2=80=93 adding use case= =20 >>>>>>>>>> diagrams to the introduction. >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> The updated specification is available at: >>>>>>>>>>=20 >>>>>>>>>> =C2=B7 >>>>>>>>>> https://na01.safelinks.protection.outlook.com/?url=3Dhttp%3a%2f% >>>>>>>>>> 2ftools.ietf.org%2fhtml%2fdraft-ietf-oauth-proof-of-possession >>>>>>>>>> -06&data=3D01%7c01%7ctonynad%40microsoft.com%7c9456670075d04a51f >>>>>>>>>> 85508d2e59ba294%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=3D6 >>>>>>>>>> hE6dOO0I1%2ffF005rVknyOFHuB18gdpZg9dftExLtCw%3d >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> An HTML formatted version is also available at: >>>>>>>>>>=20 >>>>>>>>>> =C2=B7 >>>>>>>>>> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f >>>>>>>>>> %2fs >>>>>>>>>> e >>>>>>>>>> lf-issued.info%2fdocs%2fdraft-ietf-oauth-proof-of-possession-0 >>>>>>>>>> 6.ht >>>>>>>>>> m >>>>>>>>>> l&data=3D01%7c01%7ctonynad%40microsoft.com%7c9456670075d04a51f85 >>>>>>>>>> 508d >>>>>>>>>> 2 >>>>>>>>>> e59ba294%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=3DEQd4rUcu >>>>>>>>>> yqdS P gmibtcfjMpJm6RWWwCZC85%2bCboEs54%3d >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> -- Mike >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> P.S. This note was also posted at >>>>>>>>>>=20 >>>>>>>>>> https://na01.safelinks.protection.outlook.com/?url=3Dhttp%3a%2f% >>>>>>>>>> 2fself-issued.info%2f%3fp%3d1471&data=3D01%7c01%7ctonynad%40micr >>>>>>>>>> osoft.com%7c9456670075d04a51f85508d2e59ba294%7c72f988bf86f141a >>>>>>>>>> f91ab2d7cd011db47%7c1&sdata=3DTMfX1tG5qucl%2be2KVpyMBuj72ZQ%2f%2 >>>>>>>>>> bEKGoTyJyf%2bfJi4%3d >>>>>>>>>> and as @selfissued >>>>>>>>>> . >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> OAuth mailing list >>>>>>>>>> OAuth@ietf.org =20 >>>>>>>>>> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f >>>>>>>>>> %2fw >>>>>>>>>> w >>>>>>>>>> w.ietf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonynad >>>>>>>>>> %40m >>>>>>>>>> i >>>>>>>>>> crosoft.com%7c9456670075d04a51f85508d2e59ba294%7c72f988bf86f14 >>>>>>>>>> 1af9 >>>>>>>>>> 1 >>>>>>>>>> ab2d7cd011db47%7c1&sdata=3DND3ydaXOsPMsoRhE0Uyq0uznGy6MdYOLZQJHL >>>>>>>>>> hEQK >>>>>>>>>> J >>>>>>>>>> s%3d >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> OAuth mailing list >>>>>>>>>> OAuth@ietf.org >>>>>>>>>> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f >>>>>>>>>> %2fw >>>>>>>>>> w >>>>>>>>>> w.ietf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonynad >>>>>>>>>> %40m >>>>>>>>>> i >>>>>>>>>> crosoft.com%7c9456670075d04a51f85508d2e59ba294%7c72f988bf86f14 >>>>>>>>>> 1af9 >>>>>>>>>> 1 >>>>>>>>>> ab2d7cd011db47%7c1&sdata=3DND3ydaXOsPMsoRhE0Uyq0uznGy6MdYOLZQJHL >>>>>>>>>> hEQK >>>>>>>>>> J >>>>>>>>>> s%3d >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> OAuth mailing list >>>>>>>>> OAuth@ietf.org >>>>>>>>> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f% >>>>>>>>> 2fww >>>>>>>>> w >>>>>>>>> .ietf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonynad%4 >>>>>>>>> 0mic >>>>>>>>> r >>>>>>>>> osoft.com%7c9456670075d04a51f85508d2e59ba294%7c72f988bf86f141af >>>>>>>>> 91ab >>>>>>>>> 2 >>>>>>>>> d7cd011db47%7c1&sdata=3DND3ydaXOsPMsoRhE0Uyq0uznGy6MdYOLZQJHLhEQK >>>>>>>>> Js%3 >>>>>>>>> d >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing list >>>>>>>> OAuth@ietf.org >>>>>>>> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2f= www. >>>>>>>> ietf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonynad%40m >>>>>>>> icro >>>>>>>> s >>>>>>>> oft.com%7c9456670075d04a51f85508d2e59ba294%7c72f988bf86f141af91a >>>>>>>> b2d7 c=20 >>>>>>>> d011db47%7c1&sdata=3DND3ydaXOsPMsoRhE0Uyq0uznGy6MdYOLZQJHLhEQKJs%3 >>>>>>>> d >>>>>>=20 >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fw >>>>>> ww.i=20 >>>>>> etf.org%2fmailman%2flistinfo%2foauth%0a&data=3D01%7c01%7ctonynad%40m >>>>>> icro=20 >>>>>> soft.com%7c9456670075d04a51f85508d2e59ba294%7c72f988bf86f141af91ab >>>>>> 2d7c=20 >>>>>> d011db47%7c1&sdata=3DBLqSuDjWLY72fGm0UrpLwxQVnamMelggJeOpYJESVFs%3d >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >>=20 >> --=20 >>=20 >> Best regards, >> Kathleen >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 From nobody Sat Nov 21 04:55:56 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61F781A8A82 for ; Sat, 21 Nov 2015 04:55:55 -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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mhNO1FHC_fFm for ; Sat, 21 Nov 2015 04:55:54 -0800 (PST) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E4321A8A7E for ; Sat, 21 Nov 2015 04:55:54 -0800 (PST) Received: by pacdm15 with SMTP id dm15so144046559pac.3 for ; Sat, 21 Nov 2015 04:55:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matake-jp.20150623.gappssmtp.com; s=20150623; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; bh=ga9HtTKkv/0DOFrHIO4IiBJlQI7p9nehuGW5Qz/TeMg=; b=BVzO6OYxPBARM+bvw+ZE/VaD1t0IrUa4L62GnY195beOyufVdwX/NxYfFUjPZrIegr RSZMzuvg/M2pSFvsy5UslQ43cnxs+lA+oXTAByDNWLw2xjxI+ASzPy/zUU5+ipxSg6DU leSLO6RTnmbmoQB4pDvp6+S28rlqEGHwy+EeLjm1tDOTZr3VM4D0ybI6mlPk3gHY9HXB B3zkRohWS6UwxlbGPGTZ5kQUFF/diFewIMLxxMbfQU+kEaQMrDvcYdXy4qJDeoMte/NC qfps1gC0QistU8PvU4yrf8ZmvwBgMOpb7/OHLML1h0T9bMqtvIJfwvW4Kd45euIUFOaQ WjsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:content-transfer-encoding :subject:message-id:date:to:mime-version; bh=ga9HtTKkv/0DOFrHIO4IiBJlQI7p9nehuGW5Qz/TeMg=; b=Bxmrbvq0TRLk5iwdDejKrybh3Vq687RCZpvt/eaATZSNGDj4QbxOAv5vshFyvw4b3B 0HpdAlWcxrnkPrQXr4OFG+lGlnxG9+W0/dexzgad7jVlMRzU7+34fHJ+f23EJ9rXCEAK x8L2LCSCRRZhAB0vYzA/44r4/V059e6zQcSKSo8rfUSXjfA4d7gpcnuJuHOMKE5snjLJ iac2YLmAZpfAs0mFF0MUg+Zu8De6dyQpKV7ugagBYhWm923iWUWyYZF0vGEQ8AXPq440 jU6IY/mT1v0phLH84zyaQxLISz22ps8koaPoe+ukG3WsUFg9jp5SBuaVp/w8RJPvv3Ff ZWIA== X-Gm-Message-State: ALoCoQkutvhV1uuKLm6jkGfH/Wk0rNlBtXsk2r3shTYVNHcUe3F3RtyjTq/KL9GIqOVbKT3H6eK9 X-Received: by 10.66.163.36 with SMTP id yf4mr25642185pab.145.1448110553687; Sat, 21 Nov 2015 04:55:53 -0800 (PST) Received: from [192.168.1.16] (122x210x153x65.ap122.ftth.ucom.ne.jp. [122.210.153.65]) by smtp.gmail.com with ESMTPSA id o63sm3165785pfi.77.2015.11.21.04.55.52 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 21 Nov 2015 04:55:53 -0800 (PST) From: nov matake Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Sat, 21 Nov 2015 21:55:49 +0900 To: oauth@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) X-Mailer: Apple Mail (2.3096.5) Archived-At: Subject: [OAUTH-WG] allowing offline access for native app & its backend server X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Nov 2015 12:55:55 -0000 Hi OAuthers, I=E2=80=99m thinking the way to issue refresh tokens both to native app = and its backend server at same time. I have 2 ideas currently. 1. including 2 audience in a single authorization code, and allow using = the code once per the audience. 2. issuing 2 code one for native app, one for backend server. 1st way means code can be used twice, so it can break RFC6749. 2nd way means defining another code (ex. code_for_backend etc.) Does someone has implementation supporting such use-case? =E2=80=94 nov= From nobody Sat Nov 21 06:00:45 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC0141A92B3 for ; Sat, 21 Nov 2015 06:00:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AsN43Gihbn7k for ; Sat, 21 Nov 2015 06:00:42 -0800 (PST) Received: from mail-qg0-x232.google.com (mail-qg0-x232.google.com [IPv6:2607:f8b0:400d:c04::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 DA0521A92AE for ; Sat, 21 Nov 2015 06:00:41 -0800 (PST) Received: by qgec40 with SMTP id c40so90258492qge.2 for ; Sat, 21 Nov 2015 06:00:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=819BWgXlWvr8uYICSWZK6zf/C/nd+IU9qJCf152OeAA=; b=HZiy4ewh68nz+psxlC0/e6bvhlA9kE9e3r7vNn8fbiKnq4eDhHMn3UUjWJbrtQ+Q18 NiMcG2Svs9YqlCOZmwrDSCwMEMrBttP3hFFTJ1LeXxZJI9I/5uw5CtZYpXMRDQcZ/Db7 tzE8bVCa486b8j5Q8GOQUvz6ysve2RGR7kxsd1PGqHn3BgONj9U0iajWnVh2Zl3IrdIY 1kGzyh0YNxv568Y+VemVfkd8nP0Uf7Bh8gSdoFZiEBV/Ve5QVXsku0Tlyc5Iz8kpvgLf KxRSyGlXHVKhraaNGy8Gt7IuBDMusWkW/qAVIWuo7sB2z5CXd9zFd5tjc6zLigmbtzpi ZtVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=819BWgXlWvr8uYICSWZK6zf/C/nd+IU9qJCf152OeAA=; b=iMzRtMWOP78c7pkRcrGX+vh54eCJwVsU2M0J/dMC792a5gH2IOcOHkN5fQcH2jNygM wIJN+TX78CMSesQqLersZsPjztu/PsQ2fDKXrmY7jdElUj+pB8bp/Fz7lpViQA9M0Vqk zESkMna7yFxDQ+qnKF+eTtEU2wD1xN8PFYqeXE0IHoV9rIr5QRNBoxxVS/MhQw2mNvpD e+hvci8nOvX6lQSWohBaodV7zcDNS+Dge7r99K28zguUhkvHXa2xYPP+tlg8cfH7Apty XS6k2e9Xt66T4cr58aL9U3BAHqBf60sV4/oRDCvWJnPXp66rxJDD4qCAw+2kSWebHIuo 7O+w== X-Gm-Message-State: ALoCoQnFs8+fGOTXcsXhvUV4Zlj9vBRV6J1VvCzolEehwXDWsKFgAR5bHHzJmu/QimaknvxZzOne X-Received: by 10.140.84.202 with SMTP id l68mr18211646qgd.21.1448114440628; Sat, 21 Nov 2015 06:00:40 -0800 (PST) Received: from [192.168.1.216] ([191.115.11.160]) by smtp.gmail.com with ESMTPSA id x82sm714936qhx.40.2015.11.21.06.00.38 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 21 Nov 2015 06:00:39 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: John Bradley In-Reply-To: Date: Sat, 21 Nov 2015 11:00:33 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: nov matake X-Mailer: Apple Mail (2.2104) Archived-At: Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] allowing offline access for native app & its backend server X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Nov 2015 14:00:43 -0000 There is a missing step in this flow that also needs to be considered, = and that is how the app authenticates to the backend server. In the Google case they are providing a JWT/id_token to the client from = the token endpoint for the client to use for it=E2=80=99s authentication = to it=E2=80=99s backend. It would not be a huge step to have the backend then use token exchange = along with it=E2=80=99s credentials to exchange that for a refresh = token. I can see giving out two codes and we have discussed that in the past. =20= This topic should perhaps be added to the list of things for = rechartering. There are a lot of interactions and posable security = side effects that need to be looked at. John B. > On Nov 21, 2015, at 9:55 AM, nov matake wrote: >=20 > Hi OAuthers, >=20 > I=E2=80=99m thinking the way to issue refresh tokens both to native = app and its backend server at same time. > I have 2 ideas currently. >=20 > 1. including 2 audience in a single authorization code, and allow = using the code once per the audience. > 2. issuing 2 code one for native app, one for backend server. >=20 > 1st way means code can be used twice, so it can break RFC6749. > 2nd way means defining another code (ex. code_for_backend etc.) >=20 > Does someone has implementation supporting such use-case? >=20 > =E2=80=94 > nov > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Sat Nov 21 06:12:44 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 114EB1AC39F for ; Sat, 21 Nov 2015 06:12:43 -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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JVQQS7kAzSgE for ; Sat, 21 Nov 2015 06:12:41 -0800 (PST) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::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 6C0CB1AC39A for ; Sat, 21 Nov 2015 06:12:41 -0800 (PST) Received: by pacdm15 with SMTP id dm15so145151527pac.3 for ; Sat, 21 Nov 2015 06:12:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matake-jp.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3qYPK9LXiyY9Rgu8NlkCoi6oSGSL2ioqpRcJD/N6yEQ=; b=QgyrUMot+EiOJyAbwrdLWJr+Qg133dqsnQ3/eEXod7mUWxZPATu3UiVxjrqNhdDbYh 7vP8fuvfm3z6hh5cZQ8C8tIo98pwsqbo2bIqBAan5veBFueoEqS8MBcRsAy3sGj1sG/T p65/0YIHGbYT2uCcXgiVYDTEriL+T1QLQjw13BR7nEdYsZQa6NcZIeDbsLuUeMbSbR8N NekbYIWzD5F7W2wk1NFto7GFks2mlK3QuOoXgkNIrZH/ozMxgbYe78sjF6WuCxsXieXy eM2kKCYSxsNGtbAQa9d3hWVE5BhHcenbgxpKe0kDk5+pj9zbK3MMLi162/TEXamh4mDk PdmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=3qYPK9LXiyY9Rgu8NlkCoi6oSGSL2ioqpRcJD/N6yEQ=; b=CK1V3Qs/cMxkwVM+b6Fvpbatu3PxVwjTC+OjHzNTnh+jeZ1TDv6dLMd6n2BWGwPdLR N3DnXQhdgJgog4QJpZcRC5Zwo4TSf9ZE9AtgvluHMhCsize7tNgP++17kEE4E3Bktpnu vZWhAh5KzLQlznzxPfmbIO2M39v6EtojzfmvsT9kbBFeFAL0dpNmbdwZNA5UCBsjoBgO 41KkJKYVAwcsdUdA11Brm89obh+uCugsx4IYMDCCCEQYvfhilIte+M1GHRHH9n2iZnOP Be/0PdWXk/tIY2qINwug2lR6/4GAXYrtmHYmbWYhbpAJ1izn2Ao7+hUw8JphwkEg5NfB J65A== X-Gm-Message-State: ALoCoQkv988uMRJzyAH36/1kSNPfDhyQ67GGKZCENEuo0W3dfgRtLm3yfzMMlmELQiGImhm+2kw1 X-Received: by 10.98.67.207 with SMTP id l76mr5726693pfi.59.1448115160881; Sat, 21 Nov 2015 06:12:40 -0800 (PST) Received: from [192.168.1.16] (122x210x153x65.ap122.ftth.ucom.ne.jp. [122.210.153.65]) by smtp.gmail.com with ESMTPSA id q20sm3393510pfi.5.2015.11.21.06.12.39 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 21 Nov 2015 06:12:40 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: nov matake In-Reply-To: Date: Sat, 21 Nov 2015 23:12:37 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: John Bradley X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] allowing offline access for native app & its backend server X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Nov 2015 14:12:43 -0000 Thanks John, I=E2=80=99m also OK to exchange id_token (from token endpoint) with = access/refresh token using OAuth assertion flow etc., if the AuthZ = server is OpenID Connect IdP. (In my case, AuthZ server would be OIDC IdP) ps. I also want to use PKCE for the native app & its backend combination = case. So id_token given from authorization endpoint won=E2=80=99t be my = solution. > On Nov 21, 2015, at 23:00, John Bradley wrote: >=20 > There is a missing step in this flow that also needs to be considered, = and that is how the app authenticates to the backend server. >=20 > In the Google case they are providing a JWT/id_token to the client = from the token endpoint for the client to use for it=E2=80=99s = authentication to it=E2=80=99s backend. >=20 > It would not be a huge step to have the backend then use token = exchange along with it=E2=80=99s credentials to exchange that for a = refresh token. >=20 > I can see giving out two codes and we have discussed that in the past. = =20 >=20 > This topic should perhaps be added to the list of things for = rechartering. There are a lot of interactions and posable security = side effects that need to be looked at. >=20 > John B. >=20 >=20 >> On Nov 21, 2015, at 9:55 AM, nov matake wrote: >>=20 >> Hi OAuthers, >>=20 >> I=E2=80=99m thinking the way to issue refresh tokens both to native = app and its backend server at same time. >> I have 2 ideas currently. >>=20 >> 1. including 2 audience in a single authorization code, and allow = using the code once per the audience. >> 2. issuing 2 code one for native app, one for backend server. >>=20 >> 1st way means code can be used twice, so it can break RFC6749. >> 2nd way means defining another code (ex. code_for_backend etc.) >>=20 >> Does someone has implementation supporting such use-case? >>=20 >> =E2=80=94 >> nov >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Mon Nov 23 11:49:18 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E4241B3318 for ; Mon, 23 Nov 2015 11:49:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.785 X-Spam-Level: X-Spam-Status: No, score=-1.785 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VbdFGKxMqStq for ; Mon, 23 Nov 2015 11:49:12 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DB5C1B330E for ; Mon, 23 Nov 2015 11:49:11 -0800 (PST) Received: from [192.168.10.143] ([80.92.121.34]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MWCKz-1ZpaBQ0rRR-00XLhm for ; Mon, 23 Nov 2015 20:49:09 +0100 From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 To: "oauth@ietf.org" Message-ID: <56536DB2.2020609@gmx.net> Date: Mon, 23 Nov 2015 20:49:06 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="X7pl2ECBEip2xRbUJh0hgf3uxgL8dCCvW" X-Provags-ID: V03:K0:86KE2dOkYZDQse8Jvgsm9Vq5K4Ez2FY7G9LZ1xCGx0h1a3c190H qWwf/e8WtFxlx6y/7o1U7NNMFz9mNkHVXxmPo9vINv4WP3ffgIIH5jX92L7Thc9PZMnuT1v jM/sbONrR7rwfFreAYEKMoP2R6Mgl4bbvp0FiOZ/p6BJOVdMOwJFgCumsemYI7LpKC5BxDP gA0pgTEINjEkOPqsMcU/A== X-UI-Out-Filterresults: notjunk:1;V01:K0:HlxPLiq2M+A=:n40eec3eFp4SeBG5GMQq+k kGL3V1RXVzQLH/9ZChiSDHTapzFTaubijEeCTUv3m2lZSLuSo/Ff3NwCfVV/OyE1BYkyD/lBq dOzoGGItgSjGSlGYvaNnBQgXUtEQw+AXIqjEh5eTii9Xs0BVrIC1WzpwxE5SIjwUgEH4S4u2n cQbef5jdavhuBa+XSX0CpQNbCu/Pg2wDNoP/yCbyoo6fEIfXrf5S6nQE2tWE83+DF6z6BYhO7 4aVPs6mLThpyktDxaqF4fkzlT/h+4bCNmK5BHUsu9Dz3YfEvfHiZnHmO5e5yCex3hX+llv7tg 9a5O5t7gKvJnfOeWQ49BNCVvmqDhY6CE1/3uWWo1B+QQVQqYpcs0Do16qx6DPiXsAzbSYJ7Mp PaPgXQmledVQndTA4i5Ktzi3LTmpHzF8i6J0A1RD/WRhqlRFbdioLK/9vpTSS+7XRRXFc+dDZ +DXsaFBGo9g8nXW1otj7l0lTgbCJRKN6nvbjlLhv1QnkRxCGhS7T0mk9SOPhxvSqEQrnFKxP+ mZDxwOU0U2CdbO/DkLvF+G+byiQyxr5bILLViT7+hMBgc2HF8LngOaVCz2akJa1YJiMYTMGMH YwONjUwAA7oxW1I+3zU0HMAcAk2/3qstlfEywMJ7tVycj4ooveUh9op88QgVAbqi0V6ZAbRHZ x1LDEOTiA5Pj0hvMPBQp3vKALzK0NAMeYesV07xXAg3PFzbNmjsEVQcpF2EnZx5lFUc3M1a2T roz8EbiFmv6Xw3y3yz3FZwpa0+qjBnhtFVO9s5+8wzfv7LzQMV7nvspaLH8= Archived-At: Subject: [OAUTH-WG] Adding use case to draft-ietf-oauth-pop-architecture-05 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2015 19:49:17 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --X7pl2ECBEip2xRbUJh0hgf3uxgL8dCCvW Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, at the Yokohama IETF meeting John gave a presentation about the need to also secure access and refresh tokens against unauthorized access and loss, see https://www.ietf.org/proceedings/94/minutes/minutes-94-oauth Unfortunately, this threat has not been documented in the current PoP architecture draft while other threats have been captured appropriately (see Section 3 of https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-05). Since we are currently finalizing the work on the PoP architecture document I wanted to contribute text about this use case: ------------------------ 3.5. Preventing Loss of Access and Refresh Tokens RFC 6749 distinguished two types of clients, namely public and confidential clients, based on their ability to authenticate securely with the authorization server. Even with confidential clients there is the risk, combined with certain deployment choices, that an attacker gains unauthorized access to access and refresh tokens. If those tokens are bearer tokens then the adversary can re-use them to gain access to the protected resource, for example to post messages to a social networking site to distribute spam. With proof-of-possession tokens an adversary not only needs to gain access to a database where those tokens are stored but it also needs to retrieve the associated keying material. Assuming that these keys are stored more securely, for example, in a hardware security module or trusted execution environment this specification offers an additional layer of defence. Since refresh tokens offer a client the ability to request access tokens the need arises to also define proof-of-possession functionality for refresh tokens (unless keys bound to the access token cannot be changed during the lifetime of the refresh token). ------------------------ Please let us know what you think about including this text into the next revision of the PoP architecture document and if you have some suggestions for improved wording. Ciao Hannes --X7pl2ECBEip2xRbUJh0hgf3uxgL8dCCvW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJWU22zAAoJEGhJURNOOiAtg3sH/iXgBYh1zhebj1OyOTKibdAr Gzp8qsFHoLe0uV3AEBCjAtQQ65ZOHY2O+WFs13hzYozUKv+lHIg9PHA/o2+hSRhp zRfdzWScOnhVsDs2MtEB2zWMr6kUhUxIF/29B6RtHcaocEIyCTiecrU41mid5Ei/ pSV11G6svVg08fhu88MiYnUOOyjGk2jnlDZWnAk0s11RoYobL1OqAdsVIXUuJjYE da341J2NO1wpw5bZMe2nFpB9jk5dmyC17YjEF+Y3TmsNEq9UsuzWuKfSv96Dowc+ jbhnovjTWUQ+eNBThwFbsZnurA8nTzRtCBdIkmN5Hek8a8Sbwxxxldf4H6u5HIE= =5Ie4 -----END PGP SIGNATURE----- --X7pl2ECBEip2xRbUJh0hgf3uxgL8dCCvW-- From nobody Mon Nov 23 11:59:17 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 392A01B331D for ; Mon, 23 Nov 2015 11:59:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.786 X-Spam-Level: X-Spam-Status: No, score=-4.786 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yc86F-1aaDpJ for ; Mon, 23 Nov 2015 11:59:14 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 667E91B32F6 for ; Mon, 23 Nov 2015 11:59:14 -0800 (PST) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id tANJxBrj029278 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 23 Nov 2015 19:59:12 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id tANJxBZP015111 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 23 Nov 2015 19:59:11 GMT Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id tANJxAnK032706; Mon, 23 Nov 2015 19:59:11 GMT Received: from [192.168.1.200] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 23 Nov 2015 11:59:10 -0800 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Phil Hunt In-Reply-To: <56536DB2.2020609@gmx.net> Date: Mon, 23 Nov 2015 11:59:09 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <56536DB2.2020609@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.3096.5) X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Adding use case to draft-ietf-oauth-pop-architecture-05 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2015 19:59:16 -0000 We discussed that confidential clients are not subject to any risks = since by definition they already have a unique proof-of-possesion = necessary to redeem the refresh token which is already a one-time token. Phil @independentid www.independentid.com phil.hunt@oracle.com > On Nov 23, 2015, at 11:49 AM, Hannes Tschofenig = wrote: >=20 > Hi all, >=20 > at the Yokohama IETF meeting John gave a presentation about the need = to > also secure access and refresh tokens against unauthorized access and > loss, see > https://www.ietf.org/proceedings/94/minutes/minutes-94-oauth >=20 > Unfortunately, this threat has not been documented in the current PoP > architecture draft while other threats have been captured = appropriately > (see Section 3 of > https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-05). >=20 > Since we are currently finalizing the work on the PoP architecture > document I wanted to contribute text about this use case: >=20 > ------------------------ >=20 > 3.5. Preventing Loss of Access and Refresh Tokens >=20 > RFC 6749 distinguished two types of clients, namely public and > confidential clients, based on their ability to authenticate securely > with the authorization server. Even with confidential clients there is > the risk, combined with certain deployment choices, that an attacker > gains unauthorized access to access and refresh tokens. If those = tokens > are bearer tokens then the adversary can re-use them to gain access to > the protected resource, for example to post messages to a social > networking site to distribute spam. >=20 > With proof-of-possession tokens an adversary not only needs to gain > access to a database where those tokens are stored but it also needs = to > retrieve the associated keying material. Assuming that these keys are > stored more securely, for example, in a hardware security module or > trusted execution environment this specification offers an additional > layer of defence. >=20 > Since refresh tokens offer a client the ability to request access = tokens > the need arises to also define proof-of-possession functionality for > refresh tokens (unless keys bound to the access token cannot be = changed > during the lifetime of the refresh token). >=20 > ------------------------ >=20 > Please let us know what you think about including this text into the > next revision of the PoP architecture document and if you have some > suggestions for improved wording. >=20 > Ciao > Hannes >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Mon Nov 23 12:11:52 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41D061B336E for ; Mon, 23 Nov 2015 12:11:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.786 X-Spam-Level: X-Spam-Status: No, score=-4.786 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ntKiCF0v7o8V for ; Mon, 23 Nov 2015 12:11:47 -0800 (PST) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 916B41B3368 for ; Mon, 23 Nov 2015 12:11:47 -0800 (PST) X-AuditID: 1209190d-f79306d000006b70-cc-56537301b646 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id DC.96.27504.20373565; Mon, 23 Nov 2015 15:11:46 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id tANKBjMS023561; Mon, 23 Nov 2015 15:11:45 -0500 Received: from artemisia.richer.local (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id tANKBh6E006400 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 23 Nov 2015 15:11:44 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Justin Richer In-Reply-To: Date: Mon, 23 Nov 2015 15:11:43 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <56536DB2.2020609@gmx.net> To: Phil Hunt X-Mailer: Apple Mail (2.2104) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplleLIzCtJLcpLzFFi42IRYrdT0WUqDg4zuLqBzWLpznusFiffvmKz WDC/kd2B2WPxpv1sHkuW/GTy+Pj0FksAcxSXTUpqTmZZapG+XQJXxvUbvgX7ZSr6z21kaWA8 I97FyMkhIWAiMWfuR3YIW0ziwr31bF2MXBxCAouZJNr/rWaFcDYyShxsOQflPGSS2Hz+AzNI C7OAusSfeZfAbF4BPYlXty6zgtjCAv4SD/a1s4HYbAKqEtPXtDCB2JwCdhK3ll4Ai7MAxTdt fg8U5wCaEy+xemM8xEhtiWULX0ONtJLovD4T7DohgQiJFTMbwFpFBFQkvl29zghxtazE7t+P mCYwCs5CctEsJBfNQjJ2ASPzKkbZlNwq3dzEzJzi1GTd4uTEvLzUIl0jvdzMEr3UlNJNjKCQ 5pTk3cH47qDSIUYBDkYlHt4ZRcFhQqyJZcWVuYcYJTmYlER5d+UChfiS8lMqMxKLM+KLSnNS iw8xSnAwK4nwTkkHyvGmJFZWpRblw6SkOViUxHnnfvENExJITyxJzU5NLUgtgsnKcHAoSfAy gOwRLEpNT61Iy8wpQUgzcXCCDOcBGj6xEGR4cUFibnFmOkT+FKMux6Ep99cyCbHk5eelSonz TgEpEgApyijNg5sDSkUJbw+bvmIUB3pLmJcTZB0PMI3BTXoFtIQJaMmRkkCQJSWJCCmpBsZ1 P3x178VlfNcv2Xr3ek/kn+/3hedP3P7no/nm0svODTs+cD5+2P0/WePdtW0THmt1x8xdH9v1 S/HPmpWJyW8jE1ZcqY/2by1KXM/2O1NdVub5AZ1YBimzgOov+fPdJxVOTDaa42V0ddvnu7Ul 55yC+afYx3Nuiqx5NTv3SPbCnGnhL0+kqwcpsRRnJBpqMRcVJwIAoSm07yADAAA= Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Adding use case to draft-ietf-oauth-pop-architecture-05 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2015 20:11:51 -0000 Access tokens and refresh tokens provide different attack surfaces.=20 The refresh token is *potentially* a one-time-use token, but not = necessarily so. Confidential clients are still subject to having their = credentials stolen across HTTP Basic, but that=E2=80=99s where things = like OIDC=E2=80=99s =E2=80=9Cprivate_key_jwt=E2=80=9D authentication = method come into play. Making the refresh token itself PoP doesn=E2=80=99t= solve that issue alone. You can=E2=80=99t use things like that at the resource server because = the client, by design, doesn=E2=80=99t authenticate there. =E2=80=94 Justin > On Nov 23, 2015, at 2:59 PM, Phil Hunt wrote: >=20 > We discussed that confidential clients are not subject to any risks = since by definition they already have a unique proof-of-possesion = necessary to redeem the refresh token which is already a one-time token. >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >> On Nov 23, 2015, at 11:49 AM, Hannes Tschofenig = wrote: >>=20 >> Hi all, >>=20 >> at the Yokohama IETF meeting John gave a presentation about the need = to >> also secure access and refresh tokens against unauthorized access and >> loss, see >> https://www.ietf.org/proceedings/94/minutes/minutes-94-oauth >>=20 >> Unfortunately, this threat has not been documented in the current PoP >> architecture draft while other threats have been captured = appropriately >> (see Section 3 of >> https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-05). >>=20 >> Since we are currently finalizing the work on the PoP architecture >> document I wanted to contribute text about this use case: >>=20 >> ------------------------ >>=20 >> 3.5. Preventing Loss of Access and Refresh Tokens >>=20 >> RFC 6749 distinguished two types of clients, namely public and >> confidential clients, based on their ability to authenticate securely >> with the authorization server. Even with confidential clients there = is >> the risk, combined with certain deployment choices, that an attacker >> gains unauthorized access to access and refresh tokens. If those = tokens >> are bearer tokens then the adversary can re-use them to gain access = to >> the protected resource, for example to post messages to a social >> networking site to distribute spam. >>=20 >> With proof-of-possession tokens an adversary not only needs to gain >> access to a database where those tokens are stored but it also needs = to >> retrieve the associated keying material. Assuming that these keys are >> stored more securely, for example, in a hardware security module or >> trusted execution environment this specification offers an additional >> layer of defence. >>=20 >> Since refresh tokens offer a client the ability to request access = tokens >> the need arises to also define proof-of-possession functionality for >> refresh tokens (unless keys bound to the access token cannot be = changed >> during the lifetime of the refresh token). >>=20 >> ------------------------ >>=20 >> Please let us know what you think about including this text into the >> next revision of the PoP architecture document and if you have some >> suggestions for improved wording. >>=20 >> Ciao >> Hannes >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Mon Nov 23 12:57:37 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DCA41B3ABE for ; Mon, 23 Nov 2015 12:57:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.786 X-Spam-Level: X-Spam-Status: No, score=-4.786 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0p2tca5YJrP3 for ; Mon, 23 Nov 2015 12:57:34 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6F1D1B3ABC for ; Mon, 23 Nov 2015 12:57:34 -0800 (PST) Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id tANKvWlb008194 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 23 Nov 2015 20:57:32 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id tANKvWq2013274 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 23 Nov 2015 20:57:32 GMT Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id tANKvVuY032716; Mon, 23 Nov 2015 20:57:32 GMT Received: from [192.168.1.200] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 23 Nov 2015 12:57:31 -0800 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Phil Hunt In-Reply-To: Date: Mon, 23 Nov 2015 12:57:28 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <56536DB2.2020609@gmx.net> To: Justin Richer X-Mailer: Apple Mail (2.3096.5) X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Adding use case to draft-ietf-oauth-pop-architecture-05 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2015 20:57:36 -0000 Huh? We=E2=80=99re not talking about PoP with the resource server.=20 This is a new issue regarding refresh tokens that John and Hannes are = raising. Phil @independentid www.independentid.com phil.hunt@oracle.com > On Nov 23, 2015, at 12:11 PM, Justin Richer wrote: >=20 > Access tokens and refresh tokens provide different attack surfaces.=20 >=20 > The refresh token is *potentially* a one-time-use token, but not = necessarily so. Confidential clients are still subject to having their = credentials stolen across HTTP Basic, but that=E2=80=99s where things = like OIDC=E2=80=99s =E2=80=9Cprivate_key_jwt=E2=80=9D authentication = method come into play. Making the refresh token itself PoP doesn=E2=80=99t= solve that issue alone. >=20 > You can=E2=80=99t use things like that at the resource server because = the client, by design, doesn=E2=80=99t authenticate there. >=20 > =E2=80=94 Justin >=20 >> On Nov 23, 2015, at 2:59 PM, Phil Hunt wrote: >>=20 >> We discussed that confidential clients are not subject to any risks = since by definition they already have a unique proof-of-possesion = necessary to redeem the refresh token which is already a one-time token. >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>> On Nov 23, 2015, at 11:49 AM, Hannes Tschofenig = wrote: >>>=20 >>> Hi all, >>>=20 >>> at the Yokohama IETF meeting John gave a presentation about the need = to >>> also secure access and refresh tokens against unauthorized access = and >>> loss, see >>> https://www.ietf.org/proceedings/94/minutes/minutes-94-oauth >>>=20 >>> Unfortunately, this threat has not been documented in the current = PoP >>> architecture draft while other threats have been captured = appropriately >>> (see Section 3 of >>> https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-05). >>>=20 >>> Since we are currently finalizing the work on the PoP architecture >>> document I wanted to contribute text about this use case: >>>=20 >>> ------------------------ >>>=20 >>> 3.5. Preventing Loss of Access and Refresh Tokens >>>=20 >>> RFC 6749 distinguished two types of clients, namely public and >>> confidential clients, based on their ability to authenticate = securely >>> with the authorization server. Even with confidential clients there = is >>> the risk, combined with certain deployment choices, that an attacker >>> gains unauthorized access to access and refresh tokens. If those = tokens >>> are bearer tokens then the adversary can re-use them to gain access = to >>> the protected resource, for example to post messages to a social >>> networking site to distribute spam. >>>=20 >>> With proof-of-possession tokens an adversary not only needs to gain >>> access to a database where those tokens are stored but it also needs = to >>> retrieve the associated keying material. Assuming that these keys = are >>> stored more securely, for example, in a hardware security module or >>> trusted execution environment this specification offers an = additional >>> layer of defence. >>>=20 >>> Since refresh tokens offer a client the ability to request access = tokens >>> the need arises to also define proof-of-possession functionality for >>> refresh tokens (unless keys bound to the access token cannot be = changed >>> during the lifetime of the refresh token). >>>=20 >>> ------------------------ >>>=20 >>> Please let us know what you think about including this text into the >>> next revision of the PoP architecture document and if you have some >>> suggestions for improved wording. >>>=20 >>> Ciao >>> Hannes >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 From nobody Mon Nov 23 15:25:13 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D9271A8864 for ; Mon, 23 Nov 2015 15:25:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.786 X-Spam-Level: X-Spam-Status: No, score=-4.786 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TqRgynYfQhnA for ; Mon, 23 Nov 2015 15:25:09 -0800 (PST) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A62E1A21A3 for ; Mon, 23 Nov 2015 15:25:08 -0800 (PST) X-AuditID: 1209190f-f79d06d000004b20-01-5653a0528aa9 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id F9.94.19232.250A3565; Mon, 23 Nov 2015 18:25:06 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id tANNP58J001578; Mon, 23 Nov 2015 18:25:06 -0500 Received: from [192.168.128.56] (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id tANNP36k022423 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 23 Nov 2015 18:25:04 -0500 To: Phil Hunt References: <56536DB2.2020609@gmx.net> From: Justin Richer Message-ID: <5653A04C.5030804@mit.edu> Date: Mon, 23 Nov 2015 18:25:00 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjleLIzCtJLcpLzFFi42IR4hTV1g1aEBxmcPe2hcXSnfdYLU6+fcVm sWB+I7sDs8fiTfvZPJYs+cnk8fHpLZYA5igum5TUnMyy1CJ9uwSujO2XZzEWNCtWfP3/g6mB cbt0FyMnh4SAicTBhi2sELaYxIV769m6GLk4hAQWM0n8OnifGcLZyCgxaedMNpAqIYHbTBJn vnCD2MICgRKTzswH6xYRUJH4dvU6I0TDfkaJ/vaFQA4HB7NAvMTqjfEgNWwCqhLT17Qwgdi8 AmoSC+dOZQexWYDirfPXgc0XFYiReL9pFSNEjaDEyZlPWEBsTgE7ieWPV4HVMAuYSczb/JAZ wpaXaN46m3kCo+AsJC2zkJTNQlK2gJF5FaNsSm6Vbm5iZk5xarJucXJiXl5qka6JXm5miV5q SukmRnBQS/LvYPx2UOkQowAHoxIP74yi4DAh1sSy4srcQ4ySHExKoryfJgKF+JLyUyozEosz 4otKc1KLDzFKcDArifCumgeU401JrKxKLcqHSUlzsCiJ88794hsmJJCeWJKanZpakFoEk5Xh 4FCS4FWbD9QoWJSanlqRlplTgpBm4uAEGc4DNFwEpIa3uCAxtzgzHSJ/ilGX49CU+2uZhFjy 8vNSpcR59UCKBECKMkrz4OaAklHC28OmrxjFgd4S5nUAqeIBJjK4Sa+AljABLTlSEgiypCQR ISXVwGjGb7aGK88g82b+k5l9dRsW2ugu8JHKvVDtzKFx5/qEd4sZ9Aqf5Irc2rnGoSa9V7n6 Xau4XN+9dkHvO39+TH2+Zc4m7alPVh9MUd5j3J5jdbO5a3n8wew2bRNdV8+1uT+v/3jwvo// 7Xrma0yz1mvOWM4RcUnppF5EhUdg4957jh/db58uWqDEUpyRaKjFXFScCAAU6JR5IQMAAA== Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Adding use case to draft-ietf-oauth-pop-architecture-05 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2015 23:25:11 -0000 I'm agreeing with you that because the confidential client authenticates while using the refresh token then the same set of issues addressed by PoP don't automatically apply as they do to access tokens. -- Justin On 11/23/2015 3:57 PM, Phil Hunt wrote: > Huh? > > We’re not talking about PoP with the resource server. > > This is a new issue regarding refresh tokens that John and Hannes are raising. > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > >> On Nov 23, 2015, at 12:11 PM, Justin Richer wrote: >> >> Access tokens and refresh tokens provide different attack surfaces. >> >> The refresh token is *potentially* a one-time-use token, but not necessarily so. Confidential clients are still subject to having their credentials stolen across HTTP Basic, but that’s where things like OIDC’s “private_key_jwt†authentication method come into play. Making the refresh token itself PoP doesn’t solve that issue alone. >> >> You can’t use things like that at the resource server because the client, by design, doesn’t authenticate there. >> >> — Justin >> >>> On Nov 23, 2015, at 2:59 PM, Phil Hunt wrote: >>> >>> We discussed that confidential clients are not subject to any risks since by definition they already have a unique proof-of-possesion necessary to redeem the refresh token which is already a one-time token. >>> >>> Phil >>> >>> @independentid >>> www.independentid.com >>> phil.hunt@oracle.com >>> >>>> On Nov 23, 2015, at 11:49 AM, Hannes Tschofenig wrote: >>>> >>>> Hi all, >>>> >>>> at the Yokohama IETF meeting John gave a presentation about the need to >>>> also secure access and refresh tokens against unauthorized access and >>>> loss, see >>>> https://www.ietf.org/proceedings/94/minutes/minutes-94-oauth >>>> >>>> Unfortunately, this threat has not been documented in the current PoP >>>> architecture draft while other threats have been captured appropriately >>>> (see Section 3 of >>>> https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-05). >>>> >>>> Since we are currently finalizing the work on the PoP architecture >>>> document I wanted to contribute text about this use case: >>>> >>>> ------------------------ >>>> >>>> 3.5. Preventing Loss of Access and Refresh Tokens >>>> >>>> RFC 6749 distinguished two types of clients, namely public and >>>> confidential clients, based on their ability to authenticate securely >>>> with the authorization server. Even with confidential clients there is >>>> the risk, combined with certain deployment choices, that an attacker >>>> gains unauthorized access to access and refresh tokens. If those tokens >>>> are bearer tokens then the adversary can re-use them to gain access to >>>> the protected resource, for example to post messages to a social >>>> networking site to distribute spam. >>>> >>>> With proof-of-possession tokens an adversary not only needs to gain >>>> access to a database where those tokens are stored but it also needs to >>>> retrieve the associated keying material. Assuming that these keys are >>>> stored more securely, for example, in a hardware security module or >>>> trusted execution environment this specification offers an additional >>>> layer of defence. >>>> >>>> Since refresh tokens offer a client the ability to request access tokens >>>> the need arises to also define proof-of-possession functionality for >>>> refresh tokens (unless keys bound to the access token cannot be changed >>>> during the lifetime of the refresh token). >>>> >>>> ------------------------ >>>> >>>> Please let us know what you think about including this text into the >>>> next revision of the PoP architecture document and if you have some >>>> suggestions for improved wording. >>>> >>>> Ciao >>>> Hannes >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth From nobody Mon Nov 23 23:25:24 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BFEA1A01D6 for ; Mon, 23 Nov 2015 23:25:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.185 X-Spam-Level: X-Spam-Status: No, score=-3.185 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ii2qDTHWWRKf for ; Mon, 23 Nov 2015 23:25:20 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 358F11A01F2 for ; Mon, 23 Nov 2015 23:25:20 -0800 (PST) Received: from [192.168.10.143] ([80.92.121.34]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LnCkb-1aXQyz1Oof-00hJXR; Tue, 24 Nov 2015 08:25:12 +0100 To: Phil Hunt , Justin Richer References: <56536DB2.2020609@gmx.net> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <565410D6.40507@gmx.net> Date: Tue, 24 Nov 2015 08:25:10 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="T7clmK5vn842GK9a5Vkg6twfB2lKOwX00" X-Provags-ID: V03:K0:Am1JpxdH2plFor7/fBnnVNDCeu6eYQrfk0kyywghHMODyITuKyo 9s0cEq/OQWYHFgdf+zI+Fb64JnaHJ/31ckA+7tRTFtiooZPkGUnmDCp4fpaYzx5Jyg6hh6s HLUudTFTqvlWqpl81/SlcbewRO4aex0urUiGnQocN/2/uGZcxvKttlZhhWv4kYosjtyWopy ZvRck+uWEZh1DrwGcAvOA== X-UI-Out-Filterresults: notjunk:1;V01:K0:t0IoOxEC6Mw=:2SkP0UknvpKmJCc4i+FY+8 0McAihwGlDkCO+3/A2L+IrqCAyxqSjZUU26zqrlIELbk9nYkR76uH7I7wnRMimoIqz0kygNWA SX4U8vHWvzzRDKVY0luF6NfAm+LSkHTSrOjwaZ6YAFUS3ATebbyUstDdcEO8sVPyQZkuSuy7o QRtay+aGDDwUjZkPEXYew8peLJP2Y3NqXMBapVmAtPsYAoSfBGje4hFdPxXwel3NkGEZ/vLpG UWGGqYfEv3KC0HQjtzBIB0hgDQqkzTt0J4CVYkAZ2wWmSLscFMjK9I10TFsmPCrzGA5HNsGAY b2Eb53joSNT0TOtFX/Oac/6vgecd9Fs0R3hNM5bELJv0k64lIiSfYZXAMr58WjgSFHNI9CSHv ZAT29QNfjjSRjCvPpbVaEQg4UBJ9a+ICzZm6Xio5JGPVVBlEzZfK0lzx0hgHBBqA43SZhUQCe aAspyJHZScpO1ZHMMEURUF7H1Guzt57iBd6a6+QUWW7r9kXFWBSAO0ZrFRBa/4a8VG2XMS3g/ WOWbppDdm15lfgF4K79N2V+ZyiieDP8p/r9L39AQz7rfhOW7i8ahY5z+nl8o3CLxG9Rdd56R8 Xav7GaC3KG1UykUdl0df86jDdmrlMBMDDG+WDVR5jR5eDiW7M8Lux3AOyS/F9Pb9iGBfNv5b7 dCiYoW3hryLcSeDlK+x5CIPhNVsYo2tVXzo4rqxlfO1Aais+ytleUcuN75IFPMITNEFJmMAsH cBqfFz6ecK2DPcRkm/dRiuCHBVflp6APp4dYpErP9Tsl3We2EfzBoAlsjms= Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Adding use case to draft-ietf-oauth-pop-architecture-05 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2015 07:25:22 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --T7clmK5vn842GK9a5Vkg6twfB2lKOwX00 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Phil, Hi Justin, maybe I need to improve the text here but there are two aspects that I believe are worth adding, namely a) the OAuth client may leak access tokens. This has happened in the past, for example with Buffer: http://www.programmableweb.com/news/why-attack-buffer-was-serious-wake-ca= ll-web/analysis/2013/11/04 This use case motivates the use of PoP tokens. This of course only works if the attacker is not able to get the token plus the key. b) the OAuth client may leak other credentials as well, such as refresh tokens =46rom an overall solution point of view we tend to talk about access tokens but, of course, other credentials that may allow the adversary to get the access token also need to be secured. This includes the refresh token (if it is more than a one-time key). I particularly pointed out refresh tokens since we discussed them at the last IETF meeting. Justin and John mentioned other credentials as well (such as the client credentials). I think it is worthwhile to point this out to the reader as well. Ciao Hannes On 11/23/2015 09:57 PM, Phil Hunt wrote: > Huh? >=20 > We=E2=80=99re not talking about PoP with the resource server.=20 >=20 > This is a new issue regarding refresh tokens that John and Hannes are r= aising. >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >> On Nov 23, 2015, at 12:11 PM, Justin Richer wrote: >> >> Access tokens and refresh tokens provide different attack surfaces.=20 >> >> The refresh token is *potentially* a one-time-use token, but not neces= sarily so. Confidential clients are still subject to having their credent= ials stolen across HTTP Basic, but that=E2=80=99s where things like OIDC=E2= =80=99s =E2=80=9Cprivate_key_jwt=E2=80=9D authentication method come into= play. Making the refresh token itself PoP doesn=E2=80=99t solve that iss= ue alone. >> >> You can=E2=80=99t use things like that at the resource server because = the client, by design, doesn=E2=80=99t authenticate there. >> >> =E2=80=94 Justin >> >>> On Nov 23, 2015, at 2:59 PM, Phil Hunt wrote: >>> >>> We discussed that confidential clients are not subject to any risks s= ince by definition they already have a unique proof-of-possesion necessar= y to redeem the refresh token which is already a one-time token. >>> >>> Phil >>> >>> @independentid >>> www.independentid.com >>> phil.hunt@oracle.com >>> >>>> On Nov 23, 2015, at 11:49 AM, Hannes Tschofenig wrote: >>>> >>>> Hi all, >>>> >>>> at the Yokohama IETF meeting John gave a presentation about the need= to >>>> also secure access and refresh tokens against unauthorized access an= d >>>> loss, see >>>> https://www.ietf.org/proceedings/94/minutes/minutes-94-oauth >>>> >>>> Unfortunately, this threat has not been documented in the current Po= P >>>> architecture draft while other threats have been captured appropriat= ely >>>> (see Section 3 of >>>> https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-05). >>>> >>>> Since we are currently finalizing the work on the PoP architecture >>>> document I wanted to contribute text about this use case: >>>> >>>> ------------------------ >>>> >>>> 3.5. Preventing Loss of Access and Refresh Tokens >>>> >>>> RFC 6749 distinguished two types of clients, namely public and >>>> confidential clients, based on their ability to authenticate securel= y >>>> with the authorization server. Even with confidential clients there = is >>>> the risk, combined with certain deployment choices, that an attacker= >>>> gains unauthorized access to access and refresh tokens. If those tok= ens >>>> are bearer tokens then the adversary can re-use them to gain access = to >>>> the protected resource, for example to post messages to a social >>>> networking site to distribute spam. >>>> >>>> With proof-of-possession tokens an adversary not only needs to gain >>>> access to a database where those tokens are stored but it also needs= to >>>> retrieve the associated keying material. Assuming that these keys ar= e >>>> stored more securely, for example, in a hardware security module or >>>> trusted execution environment this specification offers an additiona= l >>>> layer of defence. >>>> >>>> Since refresh tokens offer a client the ability to request access to= kens >>>> the need arises to also define proof-of-possession functionality for= >>>> refresh tokens (unless keys bound to the access token cannot be chan= ged >>>> during the lifetime of the refresh token). >>>> >>>> ------------------------ >>>> >>>> Please let us know what you think about including this text into the= >>>> next revision of the PoP architecture document and if you have some >>>> suggestions for improved wording. >>>> >>>> Ciao >>>> Hannes >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> >=20 --T7clmK5vn842GK9a5Vkg6twfB2lKOwX00 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJWVBDXAAoJEGhJURNOOiAtyS8IAKAISPIIuV7ot0fKda0dzWjd tetpmuIuobkCI0h+FfvjCJJ5iIgn6emZ3ojqu3KPF6qNICilWilTBqIu4DMdC3vR /rnzmFA14dap7NUQpewFmVDRlPrNcMJwSO5cUOUg+eHExdGYxu2FIN/VlKYbNHi0 cmXcjRLSiR/P/KWkJZMv6cKPRqikTbIYlgD/N8ZKjsLE9HbRXkoes1Ha3DyuPPdQ siwfGXI7Ly7++3okThdqJxylUKl1CwxLmsc3fpuNW1tlcqzg4GOORTVzAcluOYd8 rDMAYWlmnD/7FbmmPudq5lpFAz+5H4N+XcCRI+Pm0h/vmQsTv6YQRGGvBa7RZFE= =QKU6 -----END PGP SIGNATURE----- --T7clmK5vn842GK9a5Vkg6twfB2lKOwX00-- From nobody Tue Nov 24 06:20:45 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BADDE1A7001 for ; Tue, 24 Nov 2015 06:20:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i-eQrWrnsKCA for ; Tue, 24 Nov 2015 06:20:33 -0800 (PST) Received: from p3plsmtpa09-01.prod.phx3.secureserver.net (p3plsmtpa09-01.prod.phx3.secureserver.net [173.201.193.230]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DA371A6FF8 for ; Tue, 24 Nov 2015 06:20:33 -0800 (PST) Received: from [192.168.0.106] ([77.77.164.50]) by p3plsmtpa09-01.prod.phx3.secureserver.net with id lSLX1r00D15ZTut01SLYkU; Tue, 24 Nov 2015 07:20:33 -0700 To: Hannes Tschofenig , "oauth@ietf.org" References: <564B045C.50301@connect2id.com> <564B0C9A.5030809@gmx.net> From: Vladimir Dzhuvinov Organization: Connect2id Ltd. Message-ID: <5654722E.3030708@connect2id.com> Date: Tue, 24 Nov 2015 16:20:30 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <564B0C9A.5030809@gmx.net> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms010907050505010202020004" Archived-At: Subject: Re: [OAUTH-WG] RFC 7662 OAuth 2.0 Token Introspection: token_type X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2015 14:20:38 -0000 This is a cryptographically signed message in MIME format. --------------ms010907050505010202020004 Content-Type: multipart/alternative; boundary="------------050602050803080407010601" This is a multi-part message in MIME format. --------------050602050803080407010601 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Thank you Hannes, If the inspected token is a refresh token (which is permitted by the spec), what should the token_type response say? Vladimir On 17.11.2015 13:16, Hannes Tschofenig wrote: > Hi Vladimir, > > it is 'Bearer'. > > Section 5.1 in RFC 6749 defines th= e token_type concept and RFC 6750 > registers the 'Bearer' token value (since it defines the bearer token > concept). > > We currently have work going on with the PoP token work to also extend > the concept further. > > Ciao > Hannes > > > On 11/17/2015 11:41 AM, Vladimir Dzhuvinov wrote: >> The "token_type" parameter in introspection responses - is that supposed >> to be "access_token" / "refresh_token", or the type of the access token, >> e.g. "Bearer"? >> >> https://tools.ietf.org/html/rfc7662#section-2.2 >> >> Section 5.1 in RFC 6749 that is referred to points to section 7.1 which >> seems to imply the latter? >> >> http://tools.ietf.org/html/rfc6749#section-7.1 >> >> Thanks, >> >> Vladimir >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > --=20 Vladimir Dzhuvinov :: vladimir@connect2id.com --------------050602050803080407010601 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Thank you Hannes,

If the inspected token is a refresh token (which is permitted by the spec), what should the token_type response say?

Vladimir

On 17.11.2015 13:16, Hannes Tschofenig wrote:
> Hi Vladimir, > > it is 'Bearer'. > > Section 5.1 in RFC 6749 defines the token_type concept and RFC 6750 > registers the 'Bearer' token value (since it defines the bearer toke= n > concept). > > We currently have work going on with the PoP token work to also exte= nd > the concept further. > > Ciao > Hannes > > > On 11/17/2015 11:41 AM, Vladimir Dzhuvinov wrote: >> The "token_type" parameter in introspection responses - is that = supposed >> to be "access_token" / "refresh_token", or the type of the acces= s token, >> e.g. "Bearer"? >> >> https://tools.ietf.org/html/rfc7662#section-2= =2E2 >> >> Section 5.1 in RFC 6749 that is referred to points to section 7.= 1 which >> seems to imply the latter? >> >> http://tools.ietf.org/html/rfc6749#section-7.1= >> >> Thanks, >> >> Vladimir >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >

--
Vladimir Dzhuvinov :: vladimir@connect2id.com

--------------050602050803080407010601-- --------------ms010907050505010202020004 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfwwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggVFMIIELaADAgECAhAJWTI81U+XNs3vMVNsyOgrMA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTUwMzEyMDAwMDAwWhcNMTYwMzExMjM1OTU5WjAoMSYwJAYJKoZIhvcNAQkB Fhd2bGFkaW1pckBjb25uZWN0MmlkLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAKOyFE/JGyJPkJxnDLNMCit/gIMcHHimJ4QTbV7YNMReIh7/ccO9FQNwmmF4GCq347yB /eYy+9FXLh21Zp61RO3fSnCnEVmwNL5TwCF63iCSDLDEtXnx7AznLTV6MlheEljNtA7Cegos IM/XWE5NrzuO2vmHnj7C59uoGv4FTmcgVCDBJQ23Sdsju0zyNuAETqDyDw6yVwAfRlq+klRg G/ZZFn1D1iDRHyehgkwIoqc1cDbMPEcgkrS3ulWZhh8fGz/EQNo0JzUlwWe25DGpcSRrf47W yMHrVcP5HEQWFxEfGwQmZuNdYb/fzhnYThqGP0AjY2VMicAyOdttbbhutCsCAwEAAaOCAfUw ggHxMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBTiAjTIj8gY Zm3ThRvtNvKtyZoWRjAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0w OwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5u ZXQvQ1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9E T1NIQTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsG AQUFBwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01P RE9TSEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsG AQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wIgYDVR0RBBswGYEXdmxhZGltaXJA Y29ubmVjdDJpZC5jb20wDQYJKoZIhvcNAQELBQADggEBAC2rpYhJKODFdxGV5tBkuFuqW5/6 cnQ30GrREyk8/cLCWKhyvrMsnPnpK1ItafcQr4QPbR1hQcw0w7wzWBAl7FMjhpEVZIv286hM j+BStZPW4LTRiAHPo0Z7oEGvXPGuUuG2e6k0vAV65x7XN4S/wBYKQYg6hRatjK9Lhrlqr9K+ +Rg48LvWFdNbZ5F6VlQSHVBjX7bgQ86uUz0hRawCicJuTxE3J5fVWdfy2MULS5joW6js7V1J Hy86a/qyMZwqscXKPdv1W+UKAePtdGqKJbsZ6TFniBweSqa2pw7traBZ/ko65W2LEPi4tAhS KA7LaumILDPe82VqFHkHX4zuYC8xggRBMIIEPQIBATCBsDCBmzELMAkGA1UEBhMCR0IxGzAZ BgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRo ZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAJWTI81U+XNs3vMVNsyOgrMA0GCWCG SAFlAwQCAQUAoIICYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNTExMjQxNDIwMzBaMC8GCSqGSIb3DQEJBDEiBCB+vy9r5ejlsnnfxr69JbX3QqRyRZKM kn1oWMRQ1gU5ljBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIw CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G CCqGSIb3DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQCVkyPNVPlzbN7zFTbMjoKzCBwwYLKoZI hvcNAQkQAgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEw PwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3Vy ZSBFbWFpbCBDQQIQCVkyPNVPlzbN7zFTbMjoKzANBgkqhkiG9w0BAQEFAASCAQBR5cHQNdVJ FPUQ18wzTD5WKu+ylnVHUcD8mNQ6cPKP0ZwAZZLbo0NuNHMzi2+WBDe8qV3qwoyng2aLhEuO vOorLztVID3HPshv2EjwWMEcocLL1lLZaYEsfdB2UVrsNPEje7Ig0W+asJKl/RUv/v/D90UO GIVxsYgg+TlSDfRegiMIsAWRedTaQiaBBqk4gcU5KbzXQrWdAvHLYtK4Tv1GHZPOZfmF9OUh hOiSokH+edUONn5VT7LL4W+duO7BIVEHq5/u52R7ANpONeHIkv35LWyx6X9UtI9idNknLjcN VtAJOay6zpAvUiANCfbzT8hRSMDMZZ7uuIm+8Y+hzeqdAAAAAAAA --------------ms010907050505010202020004-- From nobody Tue Nov 24 07:34:17 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D7621A88CF for ; Tue, 24 Nov 2015 07:34:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.785 X-Spam-Level: X-Spam-Status: No, score=-4.785 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id js5kwS-vZR9C for ; Tue, 24 Nov 2015 07:34:08 -0800 (PST) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2468B1A87C0 for ; Tue, 24 Nov 2015 07:34:01 -0800 (PST) X-AuditID: 12074425-f793c6d000006975-eb-565483682bc4 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id FE.F8.26997.86384565; Tue, 24 Nov 2015 10:34:00 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id tAOFXx9x007304; Tue, 24 Nov 2015 10:33:59 -0500 Received: from artemisia.richer.local (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id tAOFXvn5026412 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 24 Nov 2015 10:33:58 -0500 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/signed; boundary="Apple-Mail=_4AD82252-5342-4D08-B784-209B4B367D5F"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail 2.5.2 From: Justin Richer In-Reply-To: <5654722E.3030708@connect2id.com> Date: Tue, 24 Nov 2015 10:33:56 -0500 Message-Id: References: <564B045C.50301@connect2id.com> <564B0C9A.5030809@gmx.net> <5654722E.3030708@connect2id.com> To: Vladimir Dzhuvinov X-Mailer: Apple Mail (2.2104) X-Brightmail-Tracker: H4sIAAAAAAAAA2WSW0gUURzGOXNZZzcnxlXztCXVVBbGuhskbBdFwgcJRC3ZoBcd3WlncXeU mV1RoVATKSsvZXktNW94gTLMS0Ermw+VREYY2UVIi4U1JSqLFLE5rJegt+983+//nf8wh8K1 c6SOsolOXhI5O6vSEFp16G69cCHVbHywuM3UPjxFmp7N+VSm+flvIA5PaPpRQia03nerEtra /mDJ+BnNMQtvt+XykiE2XSNc+VxM5jSY8loe3w4oBJeNZUBNQeYQ9PZPBPj1Fjg+dVdVBjSU lmnFYEWJj/Af+gC8UVMd4D98wmD5kJdAI8HMCbhwfQJDmmaioO/daxJBOFMN4GjDZ7wMUEqv Dta6GcSomL2wprcEQ7Za4ZuqMpBNKPbs0w4C2TiTBnv60pCkmSOwf/EcIrSMAD9MLAGkQxgj nJl9ift3DoePlqaxShBU/88O9f/ugAKcyYBvHtYDvz4AO1pmV30j/HLJR/7vG+DX+UbMr3fA wbnGVf8wbK17S/h1DHxX3rzKxMLpm3fIZrCpG4RbHAV6B2ezy3ymXs7kRJGX9KYoh80ZxVtc 9wH6kwHxe4dApYf1AIYCbCBdK50ya0kuV853eMBWCmND6ebCVLN2c0a2JV/gZCFNctl52QP2 KHdN3+sZBzpCzBZ5NoQ+alA42sLlF/BS9hq2jSLYMPrWz0SzlrFyTj6L53N4aS3dTlEspCeL lMEgibfyeWdtdudGjFFqD4BUoFK+ghhazuEcss3qz5+DXbowmi5WAgYFgktcn0WvNH3uSbQP hCmfFUzHISpQecPr0z6lGFOKR50pqNjJbUS6QrCvKwtbTiKLHrkd8aXy7PR7TWnli/1d3t8r A4ku1ULVScOMldSMpR33Jv+KdXpDGh5/rXAu90dYaKGkPaE9usrbOZI0XGu/dmykg/3ec/r9 wPmiLabggd7wFGHRk24uvdrTeSViZ8zH7s6xpOXBbxdFo3syMZIV675nfngVk8MSssAdjMQl mfsLvDkcwIADAAA= Archived-At: Cc: "" Subject: Re: [OAUTH-WG] RFC 7662 OAuth 2.0 Token Introspection: token_type X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2015 15:34:12 -0000 --Apple-Mail=_4AD82252-5342-4D08-B784-209B4B367D5F Content-Type: multipart/alternative; boundary="Apple-Mail=_13520E11-66A8-47A9-BA5E-BC7BFC6730B9" --Apple-Mail=_13520E11-66A8-47A9-BA5E-BC7BFC6730B9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 It should be left off of the the response. We probably should=92ve had = more examples for that. In general though it=92s going to be the = protected resource introspecting tokens, and they usually don=92t have = refresh tokens. We allow other kinds of tokens (ID Tokens, Refresh = Tokens, etc) but the canonical use case is the protected resource = getting information about an access token. =97 Justin > On Nov 24, 2015, at 9:20 AM, Vladimir Dzhuvinov = wrote: >=20 > Thank you Hannes, >=20 > If the inspected token is a refresh token (which is permitted by the = spec), what should the token_type response say? >=20 > Vladimir >=20 > On 17.11.2015 13:16, Hannes Tschofenig wrote: > > Hi Vladimir, > > > > it is 'Bearer'. > > > > Section 5.1 in RFC 6749 defines the token_type concept and RFC 6750 > > registers the 'Bearer' token value (since it defines the bearer = token > > concept). > > > > We currently have work going on with the PoP token work to also = extend > > the concept further. > > > > Ciao > > Hannes > > > > > > On 11/17/2015 11:41 AM, Vladimir Dzhuvinov wrote: > >> The "token_type" parameter in introspection responses - is that = supposed > >> to be "access_token" / "refresh_token", or the type of the access = token, > >> e.g. "Bearer"? > >> > >> https://tools.ietf.org/html/rfc7662#section-2.2 = > >> > >> Section 5.1 in RFC 6749 that is referred to points to section 7.1 = which > >> seems to imply the latter? > >> > >> http://tools.ietf.org/html/rfc6749#section-7.1 = > >> > >> Thanks, > >> > >> Vladimir > >> > >> > >> > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth = > >> > > >=20 > -- > Vladimir Dzhuvinov :: vladimir@connect2id.com = >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_13520E11-66A8-47A9-BA5E-BC7BFC6730B9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 It should be left off of the the response. We probably = should=92ve had more examples for that. In general though it=92s going = to be the protected resource introspecting tokens, and they usually = don=92t have refresh tokens. We allow other kinds of tokens (ID Tokens, = Refresh Tokens, etc) but the canonical use case is the protected = resource getting information about an access token. 

 =97 = Justin

On Nov 24, 2015, at 9:20 AM, Vladimir = Dzhuvinov <vladimir@connect2id.com> wrote:

=20 =20
Thank you Hannes,

If the inspected token is a refresh token (which is permitted by the spec), what should the token_type response say?

Vladimir

On 17.11.2015 13:16, Hannes Tschofenig wrote:
> Hi Vladimir, > > it is 'Bearer'. > > Section 5.1 in RFC 6749 defines the token_type concept and RFC 6750 > registers the 'Bearer' token value (since it defines the bearer = token > concept). > > We currently have work going on with the PoP token work to also = extend > the concept further. > > Ciao > Hannes > > > On 11/17/2015 11:41 AM, Vladimir Dzhuvinov wrote: >> The "token_type" parameter in introspection responses - is that = supposed >> to be "access_token" / "refresh_token", or the type of the = access token, >> e.g. "Bearer"? >> >> https://tools.iet= f.org/html/rfc7662#section-2.2 >> >> Section 5.1 in RFC 6749 that is referred to points to section = 7.1 which >> seems to imply the latter? >> >> http://tools.ietf.= org/html/rfc6749#section-7.1 >> >> Thanks, >> >> Vladimir >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/= mailman/listinfo/oauth >> >

--
Vladimir Dzhuvinov :: vladimir@connect2id.com

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

= --Apple-Mail=_13520E11-66A8-47A9-BA5E-BC7BFC6730B9-- --Apple-Mail=_4AD82252-5342-4D08-B784-209B4B367D5F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJWVINlAAoJEDPAngkbd+w96sQIAJ+iW5djkD2Ef0hw1hjmC4vU /FREoZCgxg3eZrOCSKLVcW9PGzeFPS0MMT/9VRwXEbgK0zewHXe0Haug5Ic2S00W bFaVtN/1ak6hz5MGouwtb94ZQvrhjYTOKz5KaQRlxZKh1mcPxlESvx+OHTQt9xET j+ScHu9vWb+FW3gliuc1PypIC/uEOYuTiaPOHjZwdQ/l4PAeccyan3iQICO7lDFG kga2+Gv/j7yaO1vMkznYKKUFhoE75BvOAbAXL+QfwrJi+cqU4q6kbEQ1eVc8X8B4 aqkWs/QXlAYeT35wmc14VaaCVCynIvDXy1vRchbGBDyIZT/ilHR7cGVzwxMzAAw= =SReU -----END PGP SIGNATURE----- --Apple-Mail=_4AD82252-5342-4D08-B784-209B4B367D5F-- From nobody Tue Nov 24 09:44:11 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A8AA1B300B for ; Tue, 24 Nov 2015 09:44:11 -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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OLRTehm8BNYL for ; Tue, 24 Nov 2015 09:44:09 -0800 (PST) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::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 6563D1B2FFD for ; Tue, 24 Nov 2015 09:44:09 -0800 (PST) Received: by wmww144 with SMTP id w144so149046379wmw.1 for ; Tue, 24 Nov 2015 09:44:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=mm4o4q9sBIJKsN8Xq4nuOuP9iSASoNjwIR1CokWjYyk=; b=AGYTvHmyqD8NSa/ieqbvKJ3G3585wKEaXgWisbVXx6rU8b2P4ph5QlSagwihXVmxNh Rn5IyUIUfxgUsFlA3cWdmymvyZAL8NGfZqZTekpRd+69UIxQW5Fy4trE6e/wzhmKTbuZ GNSq0gSZhMRxYBqh54CTvrcEw9xBroyC/BWZ56h4p9MI3jMXOsuGOFHPSx+9k8OB6H3O iK3MGFudKlXxnwQfro3eaCR35Wt0EWWb9KQLVY0lAK3whLut/uYZbkKrxGdD3wsP8nwP yjSXJyLcd3NXLJ/zaCuCST1+h1cf32wT1QMJ9DM6oHOhDb7ms7bb8UmAeixjnd4Z/NoY 7ACQ== MIME-Version: 1.0 X-Received: by 10.28.126.215 with SMTP id z206mr25028443wmc.71.1448387047942; Tue, 24 Nov 2015 09:44:07 -0800 (PST) Received: by 10.28.52.130 with HTTP; Tue, 24 Nov 2015 09:44:07 -0800 (PST) Date: Tue, 24 Nov 2015 12:44:07 -0500 Message-ID: From: Kathleen Moriarty To: "oauth@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [OAUTH-WG] AD review of draft-ietf-oauth-proof-of-possession X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2015 17:44:11 -0000 Hi, Thank you all for your work on this draft! I just have a few questions: 1. Security considerations section says: "All of the normal security issues, especially in relationship to comparing URIs and dealing with unrecognized values, that are discussed in JWT [JWT] also apply here." I find that to be odd phrasing that would likely be picked up in subsequent reviews. Please remove the word "normal" so that all of the security issues discusses in JWT are included. Are there other 'normal considerations in addition to those in JWT that need to be listed? The phrasing reads as if that may the case and would be better to include them all or pointers or change the phrasing. 2. Also in the security considerations section, "A recipient may not understand the newly introduced "cnf" claim and may consequently treat it as a bearer token." What is the proper handling requirement when an unknown claim is present? Section 3.1 says: "When a recipient receives a "cnf" claim with a member that it does not understand, it MUST ignore that member." Is this why it is treated as a bearer token rather than being rejected? Is this really the action you want to see with cnf? Why isn't there an error and a resend as a bearer token so that parties understand (or have an opportunity to understand) that there were issues? Then the following text in the security section says: "While this is a legitimate concern, it is outside the scope of this specification, since demonstration the possession of the key associated with the "cnf" claim is not covered by this specification. For more details, How is this outside of the scope of this draft? cnf is defined in this draft, so handling should be covered in this draft. A pointer to the POP architecture draft is not helpful as it is not defined there, it's covered int his draft. Should this text just be removed and replaced with more explicit handling information int he body of this draft? Thanks! -- Best regards, Kathleen From nobody Tue Nov 24 10:48:26 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 376601A87A7 for ; Tue, 24 Nov 2015 10:48:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.786 X-Spam-Level: X-Spam-Status: No, score=-4.786 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZqnxgPMXeN1d for ; Tue, 24 Nov 2015 10:48:18 -0800 (PST) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38F311A879D for ; Tue, 24 Nov 2015 10:48:16 -0800 (PST) X-AuditID: 1209190c-f79c96d00000038e-5a-5654b0ef19a7 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 97.51.00910.FE0B4565; Tue, 24 Nov 2015 13:48:15 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id tAOImFcD001033; Tue, 24 Nov 2015 13:48:15 -0500 Received: from artemisia.richer.local (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id tAOImD1v010222 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 24 Nov 2015 13:48:14 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Justin Richer In-Reply-To: Date: Tue, 24 Nov 2015 13:48:13 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Kathleen Moriarty X-Mailer: Apple Mail (2.2104) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrCIsWRmVeSWpSXmKPExsUixG6nrvt+Q0iYwZT7ehYNO/MtTr59xebA 5LFz1l12jyVLfjIFMEVx2aSk5mSWpRbp2yVwZZz6dYWt4JhUxbXZR9gbGNtEuxg5OSQETCQm 3l7FCmGLSVy4t56ti5GLQ0hgMZPEwS2dTCAJIYGNjBIr70pB2A+ZJNavFQGxmQXUJf7Mu8QM YvMK6Em8unUZbJCwgKfEwjNT2UBsNgFVielrWoDmcHBwCgRK3NsgDBJmAQpPu3eGGSQMMqb9 pAvERG2JZQtfQ020krj1cCkLxNYAiX/fb4FNFBGwkFjT/I0N4mRZid2/HzFNYBScheSgWUgO moVk7AJG5lWMsim5Vbq5iZk5xanJusXJiXl5qUW6hnq5mSV6qSmlmxhBgcspybOD8c1BpUOM AhyMSjy8M4qCw4RYE8uKK3MPMUpyMCmJ8h6bFxImxJeUn1KZkVicEV9UmpNafIhRgoNZSYT3 dBdQjjclsbIqtSgfJiXNwaIkzjv3i2+YkEB6YklqdmpqQWoRTFaGg0NJgrdmPVCjYFFqempF WmZOCUKaiYMTZDgP0PCp60CGFxck5hZnpkPkTzEqSonzKgFTg5AASCKjNA+uF5RYEt4eNn3F KA70ijCvI8gKHmBSgut+BTSYCWjwkZJAkMEliQgpqQZGhmnZ5z//9Fi1/dImAz4LtQtcWmuz J3w8lFqw9tMul4eJWxOCJ6h+0r4bHlV3IKWH1+Pb7XeHsgsvXVjesjXa6tWJzzk7wo+k+35h Fi46Nc9HvF/tbEHUw8UPo+wfl88vCDPg89y4RErL/UMZy1l2FqVvUe17/f7fDXkRmLU1neeM ne3d5SXJSizFGYmGWsxFxYkA6L0UwgcDAAA= Archived-At: Cc: "" Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-proof-of-possession X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2015 18:48:21 -0000 I suggest removal of the reference to bearer tokens in this section, = since that seems to suggest that this is what the RS should do in such a = case. What=E2=80=99s really going to happen is that an RS is going to = get a request with this token and it=E2=80=99s going to have to figure = out how to deal with it. If there=E2=80=99s a signature (like in = http-message-signing) then it=E2=80=99s going to need to find the key. = If it can=E2=80=99t read the key out of the cnf claim then it won=E2=80=99= t be able to validate the signature and won=E2=80=99t process the = message. If that=E2=80=99s the case then this RS can=E2=80=99t accept = this token.=20 This has nothing to do with bearer tokens vs. PoP tokens. It=E2=80=99s = not really any different from an RS accepting JWT bearer tokens needing = to be able to parse or process the JWT bearer token to figure out what = it=E2=80=99s good for. Right? =E2=80=94 Justin > On Nov 24, 2015, at 12:44 PM, Kathleen Moriarty = wrote: >=20 > Hi, >=20 > Thank you all for your work on this draft! I just have a few = questions: >=20 > 1. Security considerations section says: >=20 > "All of the normal security issues, especially in relationship to > comparing URIs and dealing with unrecognized values, that are > discussed in JWT [JWT] also apply here." >=20 > I find that to be odd phrasing that would likely be picked up in > subsequent reviews. Please remove the word "normal" so that all of > the security issues discusses in JWT are included. Are there other > 'normal considerations in addition to those in JWT that need to be > listed? The phrasing reads as if that may the case and would be > better to include them all or pointers or change the phrasing. >=20 > 2. Also in the security considerations section, >=20 > "A recipient may not understand the newly introduced "cnf" claim and > may consequently treat it as a bearer token." >=20 > What is the proper handling requirement when an unknown claim is > present? Section 3.1 says: > "When a recipient receives a "cnf" claim with a > member that it does not understand, it MUST ignore that member." >=20 > Is this why it is treated as a bearer token rather than being > rejected? Is this really the action you want to see with cnf? Why > isn't there an error and a resend as a bearer token so that parties > understand (or have an opportunity to understand) that there were > issues? >=20 > Then the following text in the security section says: > "While this is a > legitimate concern, it is outside the scope of this specification, > since demonstration the possession of the key associated with the > "cnf" claim is not covered by this specification. For more details, >=20 > How is this outside of the scope of this draft? cnf is defined in > this draft, so handling should be covered in this draft. A pointer to > the POP architecture draft is not helpful as it is not defined there, > it's covered int his draft. Should this text just be removed and > replaced with more explicit handling information int he body of this > draft? >=20 > Thanks! >=20 > --=20 >=20 > Best regards, > Kathleen >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Tue Nov 24 12:05:13 2015 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 6935F1A88EC; Tue, 24 Nov 2015 12:05:12 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151124200512.20833.28463.idtracker@ietfa.amsl.com> Date: Tue, 24 Nov 2015 12:05:12 -0800 Archived-At: Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-pop-architecture-06.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2015 20:05:12 -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 Working Group of the IETF. Title : OAuth 2.0 Proof-of-Possession (PoP) Security Architecture Authors : Phil Hunt Justin Richer William Mills Prateek Mishra Hannes Tschofenig Filename : draft-ietf-oauth-pop-architecture-06.txt Pages : 23 Date : 2015-11-24 Abstract: The OAuth 2.0 bearer token specification, as defined in RFC 6750, allows any party in possession of a bearer token (a "bearer") to get access to the associated resources (without demonstrating possession of a cryptographic key). To prevent misuse, bearer tokens must be protected from disclosure in transit and at rest. Some scenarios demand additional security protection whereby a client needs to demonstrate possession of cryptographic keying material when accessing a protected resource. This document motivates the development of the OAuth 2.0 proof-of-possession security mechanism. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architecture/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-pop-architecture-06 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 24 12:07:15 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8B131A891F for ; Tue, 24 Nov 2015 12:07:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.786 X-Spam-Level: X-Spam-Status: No, score=-4.786 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G2MRkeI7DQXi for ; Tue, 24 Nov 2015 12:07:13 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 280D41A891E for ; Tue, 24 Nov 2015 12:07:13 -0800 (PST) Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id tAOK75do020798 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 24 Nov 2015 20:07:06 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0022.oracle.com (8.13.8/8.13.8) with ESMTP id tAOK75AS024523 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 24 Nov 2015 20:07:05 GMT Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by userv0122.oracle.com (8.13.8/8.13.8) with ESMTP id tAOK75Ws006826; Tue, 24 Nov 2015 20:07:05 GMT Received: from [192.168.1.200] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 24 Nov 2015 12:07:05 -0800 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Phil Hunt In-Reply-To: <20151124200512.20833.28463.idtracker@ietfa.amsl.com> Date: Tue, 24 Nov 2015 12:07:03 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20151124200512.20833.28463.idtracker@ietfa.amsl.com> To: "" X-Mailer: Apple Mail (2.3096.5) X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-pop-architecture-06.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2015 20:07:14 -0000 This draft addresses review comments from Kathleen and Erik raised since = the last draft. It may not include some of the discussion from yesterday/today. I will = add that as the group decides. Cheers, Phil @independentid www.independentid.com phil.hunt@oracle.com > On Nov 24, 2015, at 12:05 PM, internet-drafts@ietf.org wrote: >=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 Working = Group of the IETF. >=20 > Title : OAuth 2.0 Proof-of-Possession (PoP) Security = Architecture > Authors : Phil Hunt > Justin Richer > William Mills > Prateek Mishra > Hannes Tschofenig > Filename : draft-ietf-oauth-pop-architecture-06.txt > Pages : 23 > Date : 2015-11-24 >=20 > Abstract: > The OAuth 2.0 bearer token specification, as defined in RFC 6750, > allows any party in possession of a bearer token (a "bearer") to get > access to the associated resources (without demonstrating possession > of a cryptographic key). To prevent misuse, bearer tokens must be > protected from disclosure in transit and at rest. >=20 > Some scenarios demand additional security protection whereby a = client > needs to demonstrate possession of cryptographic keying material = when > accessing a protected resource. This document motivates the > development of the OAuth 2.0 proof-of-possession security mechanism. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architecture/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-06 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-pop-architecture-06= >=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 From nobody Tue Nov 24 17:42:29 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B65B1ACD31 for ; Tue, 24 Nov 2015 17:42:29 -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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E1IiYigygxj9 for ; Tue, 24 Nov 2015 17:42:27 -0800 (PST) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c: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 700C21ACD2F for ; Tue, 24 Nov 2015 17:42:27 -0800 (PST) Received: by wmuu63 with SMTP id u63so119416273wmu.0 for ; Tue, 24 Nov 2015 17:42:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=cHYOBRblHiJ61t+Pnxdj5ICUn07NFHhXu/HlmUzYEsQ=; b=ieuPodnXpSLQhFZw3SWky6/4VvAAW/6vvGB34c84jC6nnllGJVSXhhcezGvSYL0KJf Xl90MZxWP5CRP12S0N663C7N1jj1MaeQqwSyKCUnNDdgA+EFztLr9WobH/Ie2T/V1+c9 X6rJg3z/9xYPod3zNEuUHzn1/PRerL8S01Thpfz1v8R3SXULNsufYo4T6eGER87Dquym A/fCNKGseU/ps2GZIUqRGPy3UzfJv5IzWK1h3s4Lwo9wwSd8Y9aCpvxCUzUcd5/xuhQG qWyec4kWi1x5mnZhSjoQrZUWQIoGN1g8ZhrbVBCl1ZAVL54IcHvNEjhQJyF12s/B7K27 51pA== MIME-Version: 1.0 X-Received: by 10.194.83.228 with SMTP id t4mr39828187wjy.51.1448415746059; Tue, 24 Nov 2015 17:42:26 -0800 (PST) Received: by 10.28.52.130 with HTTP; Tue, 24 Nov 2015 17:42:26 -0800 (PST) In-Reply-To: References: Date: Tue, 24 Nov 2015 20:42:26 -0500 Message-ID: From: Kathleen Moriarty To: Justin Richer Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "" Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-proof-of-possession X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2015 01:42:29 -0000 Thanks for a quick reply, Justin. On Tue, Nov 24, 2015 at 1:48 PM, Justin Richer wrote: > I suggest removal of the reference to bearer tokens in this section, sinc= e that seems to suggest that this is what the RS should do in such a case. = What=E2=80=99s really going to happen is that an RS is going to get a reque= st with this token and it=E2=80=99s going to have to figure out how to deal= with it. If there=E2=80=99s a signature (like in http-message-signing) the= n it=E2=80=99s going to need to find the key. If it can=E2=80=99t read the = key out of the cnf claim then it won=E2=80=99t be able to validate the sign= ature and won=E2=80=99t process the message. If that=E2=80=99s the case the= n this RS can=E2=80=99t accept this token. If this is the case, handling text would be helpful in the draft. > > This has nothing to do with bearer tokens vs. PoP tokens. It=E2=80=99s no= t really any different from an RS accepting JWT bearer tokens needing to be= able to parse or process the JWT bearer token to figure out what it=E2=80= =99s good for. Right? If this is the case, new text would be helpful, it's a little confusing as-is and I would assume what you assume above too. Hopefully, new text is a simple fix as I'd like to start IETF last call soon on this and the architecture draft (as in this week soon). Thanks, Kathleen > > =E2=80=94 Justin > >> On Nov 24, 2015, at 12:44 PM, Kathleen Moriarty wrote: >> >> Hi, >> >> Thank you all for your work on this draft! I just have a few questions: >> >> 1. Security considerations section says: >> >> "All of the normal security issues, especially in relationship to >> comparing URIs and dealing with unrecognized values, that are >> discussed in JWT [JWT] also apply here." >> >> I find that to be odd phrasing that would likely be picked up in >> subsequent reviews. Please remove the word "normal" so that all of >> the security issues discusses in JWT are included. Are there other >> 'normal considerations in addition to those in JWT that need to be >> listed? The phrasing reads as if that may the case and would be >> better to include them all or pointers or change the phrasing. >> >> 2. Also in the security considerations section, >> >> "A recipient may not understand the newly introduced "cnf" claim and >> may consequently treat it as a bearer token." >> >> What is the proper handling requirement when an unknown claim is >> present? Section 3.1 says: >> "When a recipient receives a "cnf" claim with a >> member that it does not understand, it MUST ignore that member." >> >> Is this why it is treated as a bearer token rather than being >> rejected? Is this really the action you want to see with cnf? Why >> isn't there an error and a resend as a bearer token so that parties >> understand (or have an opportunity to understand) that there were >> issues? >> >> Then the following text in the security section says: >> "While this is a >> legitimate concern, it is outside the scope of this specification, >> since demonstration the possession of the key associated with the >> "cnf" claim is not covered by this specification. For more details, >> >> How is this outside of the scope of this draft? cnf is defined in >> this draft, so handling should be covered in this draft. A pointer to >> the POP architecture draft is not helpful as it is not defined there, >> it's covered int his draft. Should this text just be removed and >> replaced with more explicit handling information int he body of this >> draft? >> >> Thanks! >> >> -- >> >> Best regards, >> Kathleen >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > --=20 Best regards, Kathleen From nobody Tue Nov 24 17:44:11 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94E8F1ACD37 for ; Tue, 24 Nov 2015 17:44:10 -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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lpigpx6krwYB for ; Tue, 24 Nov 2015 17:44:09 -0800 (PST) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAD061AC42F for ; Tue, 24 Nov 2015 17:44:08 -0800 (PST) Received: by wmww144 with SMTP id w144so50085537wmw.0 for ; Tue, 24 Nov 2015 17:44:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rGZ1mIxh7yqPvu6hKic5vNYSFwHB9JvN6Chrr3qDB1g=; b=r7Qb0JUaJdLDh9Mitmd7DCMpme28992Fke9sYIOU0/72kPji5bF2bVaBE6DV/KDeoE aBUOTdCE458gNj3xQVBWeiN/vxV/hqEQqWPQbPGj4k2sxnnqUTtQGaZUvsG/s0vtkdkb cdb0VtPgUgEQ3GI6hWOwIjioMGO8hzwQdbJdyP1Dp7IJjW2TPvLx6u71ck722HaS17ZK QLhg4OGyjGJbLqX0iycx2ix114mNdmJDrcHQQGGtV5Lg/5I/kV6OB5CLT20wcFmxxDcG Z75TMaR+B8E+0h5ZFteegEgc3RrPl0MiK4VbE31RfgdXKASt4BU6NmnyVG9FEBNxykOM OPtw== MIME-Version: 1.0 X-Received: by 10.194.179.71 with SMTP id de7mr39370464wjc.119.1448415847300; Tue, 24 Nov 2015 17:44:07 -0800 (PST) Received: by 10.28.52.130 with HTTP; Tue, 24 Nov 2015 17:44:07 -0800 (PST) In-Reply-To: References: <20151124200512.20833.28463.idtracker@ietfa.amsl.com> Date: Tue, 24 Nov 2015 20:44:07 -0500 Message-ID: From: Kathleen Moriarty To: Phil Hunt Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-pop-architecture-06.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2015 01:44:10 -0000 Thanks, Phil. Hopefully we can wrap up that discussion soon as well. Best regards, Kathleen On Tue, Nov 24, 2015 at 3:07 PM, Phil Hunt wrote: > This draft addresses review comments from Kathleen and Erik raised since the last draft. > > It may not include some of the discussion from yesterday/today. I will add that as the group decides. > > Cheers, > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > >> On Nov 24, 2015, at 12:05 PM, internet-drafts@ietf.org wrote: >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> This draft is a work item of the Web Authorization Protocol Working Group of the IETF. >> >> Title : OAuth 2.0 Proof-of-Possession (PoP) Security Architecture >> Authors : Phil Hunt >> Justin Richer >> William Mills >> Prateek Mishra >> Hannes Tschofenig >> Filename : draft-ietf-oauth-pop-architecture-06.txt >> Pages : 23 >> Date : 2015-11-24 >> >> Abstract: >> The OAuth 2.0 bearer token specification, as defined in RFC 6750, >> allows any party in possession of a bearer token (a "bearer") to get >> access to the associated resources (without demonstrating possession >> of a cryptographic key). To prevent misuse, bearer tokens must be >> protected from disclosure in transit and at rest. >> >> Some scenarios demand additional security protection whereby a client >> needs to demonstrate possession of cryptographic keying material when >> accessing a protected resource. This document motivates the >> development of the OAuth 2.0 proof-of-possession security mechanism. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architecture/ >> >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-06 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-pop-architecture-06 >> >> >> 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 > -- Best regards, Kathleen From nobody Tue Nov 24 18:06:03 2015 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 2CE591ACD9B; Tue, 24 Nov 2015 18:06:01 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151125020601.406.22928.idtracker@ietfa.amsl.com> Date: Tue, 24 Nov 2015 18:06:01 -0800 Archived-At: Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-proof-of-possession-07.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2015 02:06:01 -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 Working Group of the IETF. Title : Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs) Authors : Michael B. Jones John Bradley Hannes Tschofenig Filename : draft-ietf-oauth-proof-of-possession-07.txt Pages : 17 Date : 2015-11-24 Abstract: This specification defines how to express a declaration in a JSON Web Token (JWT) that the presenter of the JWT possesses a particular key and that the recipient can cryptographically confirm proof-of- possession of the key by the presenter. Being able to prove possession of a key is also sometimes described as the presenter being a holder-of-key. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-proof-of-possession/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-proof-of-possession-07 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 24 18:09:21 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FDC91ACD9C for ; Tue, 24 Nov 2015 18:09:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vn9NrfaIbANf for ; Tue, 24 Nov 2015 18:09:18 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0124.outbound.protection.outlook.com [65.55.169.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C5551ACD87 for ; Tue, 24 Nov 2015 18:09:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=DLI04rHPpfsho/d+Lo1TuXoY5N5xnhHbcRu7oDLTTkU=; b=jTiXJa35nsejkK/3lx4thg1mLe9y/svxcUJysnW6RzfILP55mAw4vp5br0ra1Vu3B3dHE9ZopU8D3SAheN3F7cW9+HO2zB953QKizMFE5YI3ShkQcbBQ4cRmk3blJH24Jh3UO8pih+ZkRAckLwAhgzAsILPYgLKqSNFeixBSxGg= Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB441.namprd03.prod.outlook.com (10.141.141.142) with Microsoft SMTP Server (TLS) id 15.1.331.20; Wed, 25 Nov 2015 02:09:15 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0331.023; Wed, 25 Nov 2015 02:09:15 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: Proof-of-Possession Key Semantics for JWTs spec addressing Area Director comments Thread-Index: AdEnJLNEEFJSSfG0SKSP2LGsFjD6Cw== Date: Wed, 25 Nov 2015 02:09:15 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [2001:4898:80e8:a::650] x-microsoft-exchange-diagnostics: 1; BY2PR03MB441; 5:sefeu7/3/gtCrLZrM9tznCPcNgIuU7nRMkMuMBoIHlpD/UWuVkHZtnmmXVjiOQOS4dChIqBPbViGwVuYsynN9Z9rDnCoE4A1OEgO92+cZL5N/k4Uu6wVkTb81mFzqRm5ar4xndD7VHZVSkYVGjs9Lg==; 24:Jyu4+S3k1qRDZllAY7bdI5fKUSqVXPWNmOQY3f1vkLFp0fAfsiScvD5euk4Uve0PQ+CTyFeWcussiYgANI49EMUs0wKYDinQaFcYEBoPU50= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB441; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425024)(601004)(2401047)(8121501046)(5005006)(520078)(3002001)(10201501046)(61426024)(61427024); SRVR:BY2PR03MB441; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB441; x-forefront-prvs: 0771670921 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(209900001)(199003)(189002)(790700001)(6116002)(5002640100001)(2351001)(102836003)(230783001)(229853001)(586003)(87936001)(99286002)(122556002)(105586002)(74316001)(16236675004)(5003600100002)(50986999)(40100003)(106356001)(5007970100001)(11100500001)(19625215002)(86612001)(54356999)(86362001)(8990500004)(33656002)(10090500001)(10400500002)(5004730100002)(10290500002)(5005710100001)(189998001)(77096005)(2501003)(19617315012)(5001920100001)(5001960100002)(2900100001)(110136002)(81156007)(5008740100001)(450100001)(107886002)(15975445007)(76576001)(92566002)(97736004)(19300405004)(101416001)(19580395003)(3826002)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB441; H:BY2PR03MB442.namprd03.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:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR03MB4427D5FD76955AEF9823D74F5050BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Nov 2015 02:09:15.6365 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB441 Archived-At: Subject: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing Area Director comments X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2015 02:09:20 -0000 --_000_BY2PR03MB4427D5FD76955AEF9823D74F5050BY2PR03MB442namprd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Proof-of-Possession Key Semantics for JWTs draft -07 addresses review comme= nts by our Area Director, Kathleen Moriarty, as well as comments by Hannes = Tschofenig and Justin Richer. This should hopefully enable IETF last call. The specification is available at: * http://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-0= 7 An HTML formatted version is also available at: * https://self-issued.info/docs/draft-ietf-oauth-proof-of-possessio= n-07.html -- Mike P.S. This note was also posted at http://self-issued.info/?p=3D1487 and as= @selfissued. --_000_BY2PR03MB4427D5FD76955AEF9823D74F5050BY2PR03MB442namprd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Proof-of-Possession Key Semantics for JWTs draft -07= addresses review comments by our Area Director, Kathleen Moriarty, as well= as comments by Hannes Tschofenig and Justin Richer.  This should hope= fully enable IETF last call.

 

The specification is available at:

·         http://tools.ietf.org/html/draft-ietf-oa= uth-proof-of-possession-07

 

An HTML formatted version is also available at:=

·         https://self-issued.info/docs/dr= aft-ietf-oauth-proof-of-possession-07.html

 

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

 

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

 

--_000_BY2PR03MB4427D5FD76955AEF9823D74F5050BY2PR03MB442namprd_-- From nobody Tue Nov 24 18:09:43 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C61A1ACDA6 for ; Tue, 24 Nov 2015 18:09:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5IpqHiqYU0gG for ; Tue, 24 Nov 2015 18:09:40 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0104.outbound.protection.outlook.com [65.55.169.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 891C81A1ADD for ; Tue, 24 Nov 2015 18:09:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=StNZXrBTjIN0Oam3E2laZ1YPWPsFVtZtXjFWnhpGGxs=; b=BD2nUmtmwbKyqI4b0/I3fYNivzPdgTi9TdYCiEqkambtW4U2tDlhBTd6FP/zKBLjRYnUEfvf5bawAXFOJcY/Aw6R7EmQGXXpPNhB9PgrlcHfhVlh8bW+f1RA6FOBIXf5oFsiX+KbmmD+60esfkzlcVNuTzvOzKmLXvys0qo8o0g= Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB441.namprd03.prod.outlook.com (10.141.141.142) with Microsoft SMTP Server (TLS) id 15.1.331.20; Wed, 25 Nov 2015 02:09:37 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0331.023; Wed, 25 Nov 2015 02:09:37 +0000 From: Mike Jones To: Hannes Tschofenig , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] draft-ietf-oauth-proof-of-possession-06 Glitches Thread-Index: AQHRIH79mKZHRXxwvE+48vmOkQX4Rp6fJFzAgAzRlIA= Date: Wed, 25 Nov 2015 02:09:36 +0000 Message-ID: References: <5649EE61.8060803@gmx.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [2001:4898:80e8:a::650] x-microsoft-exchange-diagnostics: 1; BY2PR03MB441; 5:ppmpl/83UX+PfZxWAVkxk96dVIdMeONxWU5pDJjkdacpoWME3QEPMF8L+TP1nklvfJ6W9xk9NARb4rVq2IaExpNZmylsLaCOa2cX2l/Xt/WkZC9Ve44lzRtonW8dxnU/calmNonET7TBanG4A78Ahg==; 24:Muik3B7d3O+K/nq+jtxWFOLJzaJxrXIh24oOLiS7c35+kK/G4q9i+0T0n30bcKojsGnPNF3iWUJFV4Fuudm13an29vvIZr3I31O0ByToXSk= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB441; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425024)(601004)(2401047)(8121501046)(5005006)(520078)(3002001)(10201501046)(61426024)(61427024); SRVR:BY2PR03MB441; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB441; x-forefront-prvs: 0771670921 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(53754006)(51914003)(199003)(189002)(13464003)(377454003)(43784003)(6116002)(5002640100001)(102836003)(230783001)(586003)(87936001)(99286002)(122556002)(105586002)(74316001)(5003600100002)(50986999)(40100003)(106116001)(76176999)(106356001)(5007970100001)(11100500001)(86612001)(54356999)(86362001)(8990500004)(33656002)(10090500001)(10400500002)(5004730100002)(10290500002)(5005710100001)(575784001)(189998001)(77096005)(5001770100001)(2501003)(5001920100001)(5001960100002)(2900100001)(81156007)(5008740100001)(107886002)(15975445007)(76576001)(92566002)(97736004)(19580405001)(101416001)(19580395003)(2950100001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB441; H:BY2PR03MB442.namprd03.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:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Nov 2015 02:09:36.9650 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB441 Archived-At: Subject: Re: [OAUTH-WG] draft-ietf-oauth-proof-of-possession-06 Glitches X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2015 02:09:42 -0000 Thanks again for your comments, Hannes. I applied the responses described = below in -07. -- Mike -----Original Message----- From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones Sent: Monday, November 16, 2015 1:41 PM To: Hannes Tschofenig ; oauth@ietf.org Subject: Re: [OAUTH-WG] draft-ietf-oauth-proof-of-possession-06 Glitches Hi Hannes. Thanks for the feedback. Replies are inline below... > -----Original Message----- > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes=20 > Tschofenig > Sent: Monday, November 16, 2015 6:55 AM > To: oauth@ietf.org > Subject: [OAUTH-WG] draft-ietf-oauth-proof-of-possession-06 Glitches >=20 > Hi all, >=20 > I noticed a few glitches with the most recent version of the=20 > draft-ietf-oauth- proof-of-possession document. >=20 > ** PoP Figure (Symmetric Key) >=20 > FROM: >=20 > +--------------+ > | | +--------------+ > | |--(4) Presentation of -->| | > | | JWT w/ Encrypted | | > | Presenter | PoP Key | | > | | | | > | |<-(5) Communication ---->| | > | | Authenticated by | | > +--------------+ PoP Key | | > | ^ | | > | | | | > (1) Sym. (3) JWT w/ | Recipient | > | PoP | Encrypted | | > | Key | PoP Key | | > v | | | > +--------------+ | | > | | | | > | | | | > | |<-(2) Key Exchange for ->| | > | Issuer | Key Encryption Key | | > | | | | > | | | | > | | +--------------+ > +--------------+ >=20 > Figure 1: Proof-of-Possession with a Symmetric Key >=20 > TO: >=20 > +--------------+ > | | +--------------+ > | |--(3) Presentation of -->| | > | | JWT w/ Encrypted | | > | Presenter | PoP Key | | > | | | | > | |<-(4) Communication ---->| | > | | Authenticated by | | > +--------------+ PoP Key | | > | ^ | | > | | | | > (1) Sym. (2) JWT w/ | Recipient | > | PoP | Encrypted | | > | Key | PoP Key | | > v | | | > +--------------+ | | > | | | | > | | | | > | |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D>| | > | Issuer | Key Exchange for | | > | | Key Encryption Key | | > | | | | > | | +--------------+ > +--------------+ >=20 > Figure 1: Proof-of-Possession with a Symmetric Key >=20 >=20 > The reason for this change is that the figure currently included in=20 > the document gives the impression that the key used to protect the PoP=20 > token is actually dynamically exchanged in step (2), which isn't the case= . >=20 > While text says that it is dynamically established if it does not=20 > exist there is nothing in this or any document that provides this functio= nality. > Hence, I am also suggesting to change the text accordingly: >=20 > FROM: >=20 > This symmetric key is encrypted with a key known only to the issuer=20 > and the recipient, which is established in step (2), if it doesn't alread= y exist. >=20 > TO: >=20 > This symmetric key is encrypted with a key known only to the issuer=20 > and the recipient. >=20 > The problem with dynamically establishing keys is that we are then=20 > requiring yet another key to be in place to allow this procedure to happe= n securely. > Without anything in place we are quickly vulnerable to various attacks. >=20 >=20 > FROM: >=20 > In the case illustrated in Figure 1, the presenter generates a=20 > symmetric key and (1) privately sends it to the issuer. >=20 > TO: >=20 > In the case illustrated in Figure 1, the presenter generates a=20 > symmetric key and in (1) sends it to the issuer. The key transport is=20 > confidentiality protected. OK - I can make changes along these lines. I'll tentatively plan on labell= ing the key exchange for the key encryption key as (0) in the diagram, and = referring to it as such in the text. I'll send the revised text to you and= the other editor for review before publication. > ** CNF Claim >=20 > I also have a question regarding this paragraph from Section 3.1. What=20 > does it mean to have other members of the "cnf" claim? It means that additional methods of confirming the authenticity of the toke= n may be defined in the future. They will be registered in the JWT Confirm= ation Methods Registry established in Section 6.2. As an example, SAML has= an IP Address confirmation method. While I'm not recommending that we def= ine an equivalent confirmation method here, it's an example showing that we= haven't covered the complete spectrum of possible confirmation methods. > What is the semantic of these two examples: >=20 > { > "iss": "https://server.example.com", > "aud": "https://client.example.org", > "exp": "1361398824", > "cnf":{ > "jwk":{...}, > "jwk":{...} > } > } The example above is invalid, since it contains two "jwk" members. JWT par= sers should reject such input, per Section 4 of RFC 7519. > { > "iss": "https://server.example.com", > "aud": "https://client.example.org", > "exp": "1361398824", > "cnf":{ > "jwk":{...}, > "jwe":{...}, > "kid":"..." > } > } This example is ambiguous and malformed, since it contains two keys and may= refer to a third one - one in the "jwk" element, one in the "jwe" element,= and possibly a different one being referenced by the "kid" element. I'll = plan to add language saying that only a single confirmation key is intended= to be communicated in the "cnf" claim and that uses in which multiple keys= are communicated and/or referenced in the "cnf" value are syntactically in= valid. > Here is the relevant text: >=20 > " > 3.1. Confirmation Claim >=20 > The "cnf" (confirmation) claim is used in the JWT to contain members=20 > used to identify the proof-of-possession key. Other members of the=20 > "cnf" object may be defined because a proof-of-possession key may not=20 > be the only means of confirming the authenticity of the token. This is=20 > analogous to the SAML 2.0 [OASIS.saml-core-2.0-os] SubjectConfirmation=20 > element, in which a number of different subject confirmation methods=20 > can be included, including proof-of-possession key information. When a=20 > recipient receives a "cnf" claim with a member that it does not understan= d, it MUST ignore that member. >=20 > ... >=20 > Note that if an application needs to represent multiple proof-of-=20 > possession keys in the same JWT, one way for it to achieve this is to=20 > use other claim names, in addition to "cnf", to hold the additional=20 > proof-of-possession key information. These claims could use the same=20 > syntax and semantics as the "cnf" claim. > " >=20 > ** Key ID >=20 > Lack of interoperability for the Key ID functionality described in Sectio= n 3.4. >=20 > The text says that >=20 > "The content of the "kid" value is application specific. For instance,=20 > some applications may choose to use a JWK Thumbprint [JWK.Thumbprint]=20 > value as the "kid" value." >=20 > I think we should settle for something and then allow other key id=20 > types to be used as well. This is exactly the same as the "kid" usage in JWT [RFC 7519], by design. = It's up to the application what labels to use to identify the keys that it = creates. It can label them "1", "2", "3", .... It can label them with the= date created, such as "16-Nov-2015". And yes, it could use an "x5t" or JW= K Thumbprint value. Normally, it doesn't matter what the key creator choos= es as the Key ID value, since other users of the key just use the "kid" val= ue created along with the key verbatim. The fact that often both parties d= on't need to know how a key ID is created is described in paragraph 2 of ht= tp://tools.ietf.org/html/rfc7638#section-3.4. In short, there's no reason = to go beyond what JWT does in defining how "kid" values are used - and ther= e are good reasons not to do so. > ** Nonce Claim >=20 > This example in Section 3.3 uses a claim type, namely nonce, which has=20 > not been defined yet. I therefore suggest to remove it from this=20 > example since it does not fulfil a purpose. >=20 > Here is the example: >=20 > { > "iss": "https://server.example.com", > "sub": "24400320", > "aud": "s6BhdRkqt3", > "nonce": "n-0S6_WzA2Mj", > "exp": 1311281970, > "iat": 1311280970, > "cnf":{ > "jwe": > "eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkExMjhDQkMtSFMyNTYifQ. > (remainder of JWE omitted for brevity)" > } > } The "nonce" claim *is* defined and registered in the IANA JWT Claims Regist= ry at http://www.iana.org/assignments/jwt/jwt.xhtml. > Ciao > Hannes Thanks again, -- Mike _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From nobody Tue Nov 24 18:10:13 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26E3F1ACD97 for ; Tue, 24 Nov 2015 18:10:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id boQ-EiQPnlBV for ; Tue, 24 Nov 2015 18:10:09 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0144.outbound.protection.outlook.com [65.55.169.144]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E58751ACD8E for ; Tue, 24 Nov 2015 18:10:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=W+iFFGITrLMPb7cAnsoLplb9OQlD3EbA9WxQevOW3KE=; b=PGsUXlVWJqK5PYk+iJIDoVE2jtDM7FOGgFZ5gutPHDXkuyDDXIx8NyJw+KsNnX4brj9FBSgEEJTvL0FvnFJMrCC7gAVwzujx+Y36j96bW/UmCybA1MyCKjnwZck0+ttRGbWeA4ao69z8VqeuomQmp3OToMhixcu7RkNzWlzKQxs= Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB441.namprd03.prod.outlook.com (10.141.141.142) with Microsoft SMTP Server (TLS) id 15.1.331.20; Wed, 25 Nov 2015 02:10:07 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0331.023; Wed, 25 Nov 2015 02:10:06 +0000 From: Mike Jones To: Kathleen Moriarty , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] AD review of draft-ietf-oauth-proof-of-possession Thread-Index: AQHRJt++kWDp0FqlfEmPEzc+Ih7voJ6r6UxQ Date: Wed, 25 Nov 2015 02:10:06 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [2001:4898:80e8:a::650] x-microsoft-exchange-diagnostics: 1; BY2PR03MB441; 5:+FBVu/2SrjN3M1Yj4aW6pxYjsCaPsuNj4XV12medTafG8k4zmPDU6rW2yAZjcI3KcKKBcZR7R4l74no08WdHMtjWXVaXoxxjI6E650MIdN5lkE65U8987YLLfRSicjxWyJD/F3MSzTU1M+w4iQ704Q==; 24:OU8EfjFk4noVkVgaWiBD+Tl0hhnkQLa3xkPAMn/ig+xjAHvw48AHzqCtkPw9b87HwfnDlgoC6PQFTozmn6sr9Bd8eCqeBEVm7iKs7b1Dm0c= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB441; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425024)(601004)(2401047)(8121501046)(5005006)(520078)(3002001)(10201501046)(61426024)(61427024); SRVR:BY2PR03MB441; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB441; x-forefront-prvs: 0771670921 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(13464003)(377454003)(43784003)(6116002)(5002640100001)(102836003)(230783001)(586003)(87936001)(99286002)(122556002)(105586002)(74316001)(5003600100002)(50986999)(40100003)(106116001)(76176999)(106356001)(5007970100001)(86612001)(54356999)(86362001)(8990500004)(33656002)(10090500001)(10400500002)(5004730100002)(10290500002)(5005710100001)(189998001)(77096005)(5001770100001)(2501003)(5001920100001)(5001960100002)(2900100001)(81156007)(5008740100001)(107886002)(15975445007)(76576001)(92566002)(97736004)(19580405001)(101416001)(19580395003)(2950100001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB441; H:BY2PR03MB442.namprd03.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:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Nov 2015 02:10:06.8406 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB441 Archived-At: Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-proof-of-possession X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2015 02:10:11 -0000 Thanks for your review comments, Kathleen. Responses are inline below... > -----Original Message----- > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Kathleen > Moriarty > Sent: Tuesday, November 24, 2015 9:44 AM > To: oauth@ietf.org > Subject: [OAUTH-WG] AD review of draft-ietf-oauth-proof-of-possession >=20 > Hi, >=20 > Thank you all for your work on this draft! I just have a few questions: >=20 > 1. Security considerations section says: >=20 > "All of the normal security issues, especially in relationship to > comparing URIs and dealing with unrecognized values, that are > discussed in JWT [JWT] also apply here." >=20 > I find that to be odd phrasing that would likely be picked up in subseque= nt > reviews. Please remove the word "normal" so that all of the security iss= ues > discusses in JWT are included. Are there other 'normal considerations in > addition to those in JWT that need to be listed? The phrasing reads as i= f that > may the case and would be better to include them all or pointers or chang= e > the phrasing. You're right. I removed this awkward wording. > 2. Also in the security considerations section, >=20 > "A recipient may not understand the newly introduced "cnf" claim and > may consequently treat it as a bearer token." >=20 > What is the proper handling requirement when an unknown claim is > present? Section 3.1 says: > "When a recipient receives a "cnf" claim with a > member that it does not understand, it MUST ignore that member." >=20 > Is this why it is treated as a bearer token rather than being rejected? = Is this > really the action you want to see with cnf? Why isn't there an error and= a > resend as a bearer token so that parties understand (or have an opportuni= ty > to understand) that there were issues? >=20 > Then the following text in the security section says: > "While this is a > legitimate concern, it is outside the scope of this specification, > since demonstration the possession of the key associated with the > "cnf" claim is not covered by this specification. For more details, >=20 > How is this outside of the scope of this draft? cnf is defined in this d= raft, so > handling should be covered in this draft. A pointer to the POP architect= ure > draft is not helpful as it is not defined there, it's covered int his dra= ft. Should > this text just be removed and replaced with more explicit handling > information int he body of this draft? Good catch. JWT [RFC 7519] Section 4 says that claims that are not underst= ood must be ignored unless otherwise specified by the application. This al= lows new claims to be dynamically added without breaking existing applicati= ons. For the same reason, I have incorporated this language about understa= nding claims from 7519, but having it be about understanding confirmation m= embers. Ultimately, what features must be implemented are always up to the= application, just as with JWT claims. > Thanks! >=20 > -- >=20 > Best regards, > Kathleen >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth Thanks again, -- Mike From nobody Tue Nov 24 18:10:51 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F2E61ACDAE for ; Tue, 24 Nov 2015 18:10:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SDgc_ieIn_R8 for ; Tue, 24 Nov 2015 18:10:47 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0105.outbound.protection.outlook.com [207.46.100.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 37D221ACDA7 for ; Tue, 24 Nov 2015 18:10:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=taL4nscvEm+JLprfK4+He5ed+THjIYXKpN7cKFX80H8=; b=nh4FqWYa1irg1LZMexZGFlO62hFW7BXvgxOQVo8JGCaWVxgx9oFhoaHPEgymw1wqkM9qZf+AxrhMw5+2PjYftcLmeW7Ipx8P8TKUibAxIIV7dvXgSTAAX2C2XBT3T4/dRBWSyGWBK3eKtI8GuR35MtLu5MZj5CUvbwX7HGsAehw= Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB441.namprd03.prod.outlook.com (10.141.141.142) with Microsoft SMTP Server (TLS) id 15.1.331.20; Wed, 25 Nov 2015 02:10:45 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0331.023; Wed, 25 Nov 2015 02:10:45 +0000 From: Mike Jones To: Justin Richer , Kathleen Moriarty Thread-Topic: [OAUTH-WG] AD review of draft-ietf-oauth-proof-of-possession Thread-Index: AQHRJt++kWDp0FqlfEmPEzc+Ih7voJ6rg5iAgABl3iA= Date: Wed, 25 Nov 2015 02:10:45 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [2001:4898:80e8:a::650] x-microsoft-exchange-diagnostics: 1; BY2PR03MB441; 5:k4qQUan3Mj25TuzbFBMGIOgvEyOFQ4mQtaItvw7GJuc20tzyHcHRm35TgMQdu/y4TR7LHk2bUNd7jecIOiU2C5TOfqAb9PaEPEB3tyHiki+P26QY7vwgAubrAoA2eyPso3PqRFo1TQtt/srO1p6Iag==; 24:TjKIt21JrIL3nTkxLa7t1FaT5EcVTrSvWJcOldlnvcQOR4RX8qP41841jl4RoMNm5QUPbiilQ6h9KlUJAcSV9BC5EaZ4sPmGHijRp0X4a6U= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB441; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425024)(601004)(2401047)(8121501046)(5005006)(520078)(3002001)(10201501046)(61426024)(61427024); SRVR:BY2PR03MB441; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB441; x-forefront-prvs: 0771670921 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(199003)(189002)(13464003)(377454003)(43784003)(6116002)(5002640100001)(102836003)(2171001)(230783001)(586003)(87936001)(99286002)(122556002)(105586002)(74316001)(5003600100002)(50986999)(40100003)(106116001)(76176999)(106356001)(5007970100001)(11100500001)(86612001)(54356999)(86362001)(8990500004)(33656002)(10090500001)(10400500002)(5004730100002)(10290500002)(5005710100001)(189998001)(77096005)(5001770100001)(5001920100001)(5001960100002)(2900100001)(81156007)(5008740100001)(15975445007)(76576001)(92566002)(97736004)(19580405001)(101416001)(19580395003)(2950100001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB441; H:BY2PR03MB442.namprd03.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:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Nov 2015 02:10:45.7944 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB441 Archived-At: Cc: "" Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-proof-of-possession X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2015 02:10:49 -0000 VGhhbmtzIEp1c3Rpbi4gIFVwb24gcmVyZWFkaW5nIHRoaXMgc2VjdGlvbiB3aXRoIEthdGhsZWVu J3MgYW5kIHlvdXIgY29tbWVudHMgaW4gbWluZCwgSSByZW1vdmVkIGFsbCB0aGUgdGV4dCB0aGF0 IHlvdSB3ZXJlIG9iamVjdGluZyB0byBhbmQgcmVwbGFjZWQgaXQgd2l0aCB0aGUgbmV3IGxhc3Qg cGFyYWdyYXBoIG9mIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uLCB3aGljaCBt YWtlcyB0aGUgcG9pbnQgdGhhdCB1bHRpbWF0ZWx5LCB3aGF0IGZlYXR1cmVzIG11c3QgYmUgaW1w bGVtZW50ZWQgYXJlIGFsd2F5cyB1cCB0byB0aGUgYXBwbGljYXRpb24sIGp1c3QgYXMgd2l0aCBK V1QgY2xhaW1zLg0KDQoJCQkJVGhhbmtzIGFnYWluLA0KCQkJCS0tIE1pa2UNCg0KLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IE9BdXRoIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mIEp1c3RpbiBSaWNoZXINClNlbnQ6IFR1ZXNkYXksIE5vdmVtYmVy IDI0LCAyMDE1IDEwOjQ4IEFNDQpUbzogS2F0aGxlZW4gTW9yaWFydHkgPGthdGhsZWVuLm1vcmlh cnR5LmlldGZAZ21haWwuY29tPg0KQ2M6IDxvYXV0aEBpZXRmLm9yZz4gPG9hdXRoQGlldGYub3Jn Pg0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gQUQgcmV2aWV3IG9mIGRyYWZ0LWlldGYtb2F1dGgt cHJvb2Ytb2YtcG9zc2Vzc2lvbg0KDQpJIHN1Z2dlc3QgcmVtb3ZhbCBvZiB0aGUgcmVmZXJlbmNl IHRvIGJlYXJlciB0b2tlbnMgaW4gdGhpcyBzZWN0aW9uLCBzaW5jZSB0aGF0IHNlZW1zIHRvIHN1 Z2dlc3QgdGhhdCB0aGlzIGlzIHdoYXQgdGhlIFJTIHNob3VsZCBkbyBpbiBzdWNoIGEgY2FzZS4g V2hhdOKAmXMgcmVhbGx5IGdvaW5nIHRvIGhhcHBlbiBpcyB0aGF0IGFuIFJTIGlzIGdvaW5nIHRv IGdldCBhIHJlcXVlc3Qgd2l0aCB0aGlzIHRva2VuIGFuZCBpdOKAmXMgZ29pbmcgdG8gaGF2ZSB0 byBmaWd1cmUgb3V0IGhvdyB0byBkZWFsIHdpdGggaXQuIElmIHRoZXJl4oCZcyBhIHNpZ25hdHVy ZSAobGlrZSBpbiBodHRwLW1lc3NhZ2Utc2lnbmluZykgdGhlbiBpdOKAmXMgZ29pbmcgdG8gbmVl ZCB0byBmaW5kIHRoZSBrZXkuIElmIGl0IGNhbuKAmXQgcmVhZCB0aGUga2V5IG91dCBvZiB0aGUg Y25mIGNsYWltIHRoZW4gaXQgd29u4oCZdCBiZSBhYmxlIHRvIHZhbGlkYXRlIHRoZSBzaWduYXR1 cmUgYW5kIHdvbuKAmXQgcHJvY2VzcyB0aGUgbWVzc2FnZS4gSWYgdGhhdOKAmXMgdGhlIGNhc2Ug dGhlbiB0aGlzIFJTIGNhbuKAmXQgYWNjZXB0IHRoaXMgdG9rZW4uIA0KDQpUaGlzIGhhcyBub3Ro aW5nIHRvIGRvIHdpdGggYmVhcmVyIHRva2VucyB2cy4gUG9QIHRva2Vucy4gSXTigJlzIG5vdCBy ZWFsbHkgYW55IGRpZmZlcmVudCBmcm9tIGFuIFJTIGFjY2VwdGluZyBKV1QgYmVhcmVyIHRva2Vu cyBuZWVkaW5nIHRvIGJlIGFibGUgdG8gcGFyc2Ugb3IgcHJvY2VzcyB0aGUgSldUIGJlYXJlciB0 b2tlbiB0byBmaWd1cmUgb3V0IHdoYXQgaXTigJlzIGdvb2QgZm9yLiBSaWdodD8NCg0KIOKAlCBK dXN0aW4NCg0KPiBPbiBOb3YgMjQsIDIwMTUsIGF0IDEyOjQ0IFBNLCBLYXRobGVlbiBNb3JpYXJ0 eSA8a2F0aGxlZW4ubW9yaWFydHkuaWV0ZkBnbWFpbC5jb20+IHdyb3RlOg0KPiANCj4gSGksDQo+ IA0KPiBUaGFuayB5b3UgYWxsIGZvciB5b3VyIHdvcmsgb24gdGhpcyBkcmFmdCEgIEkganVzdCBo YXZlIGEgZmV3IHF1ZXN0aW9uczoNCj4gDQo+IDEuIFNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHNl Y3Rpb24gc2F5czoNCj4gDQo+ICJBbGwgb2YgdGhlIG5vcm1hbCBzZWN1cml0eSBpc3N1ZXMsIGVz cGVjaWFsbHkgaW4gcmVsYXRpb25zaGlwIHRvDQo+ICAgY29tcGFyaW5nIFVSSXMgYW5kIGRlYWxp bmcgd2l0aCB1bnJlY29nbml6ZWQgdmFsdWVzLCB0aGF0IGFyZQ0KPiAgIGRpc2N1c3NlZCBpbiBK V1QgW0pXVF0gYWxzbyBhcHBseSBoZXJlLiINCj4gDQo+IEkgZmluZCB0aGF0IHRvIGJlIG9kZCBw aHJhc2luZyB0aGF0IHdvdWxkIGxpa2VseSBiZSBwaWNrZWQgdXAgaW4gDQo+IHN1YnNlcXVlbnQg cmV2aWV3cy4gIFBsZWFzZSByZW1vdmUgdGhlIHdvcmQgIm5vcm1hbCIgc28gdGhhdCBhbGwgb2Yg DQo+IHRoZSBzZWN1cml0eSBpc3N1ZXMgZGlzY3Vzc2VzIGluIEpXVCBhcmUgaW5jbHVkZWQuICBB cmUgdGhlcmUgb3RoZXIgDQo+ICdub3JtYWwgY29uc2lkZXJhdGlvbnMgaW4gYWRkaXRpb24gdG8g dGhvc2UgaW4gSldUIHRoYXQgbmVlZCB0byBiZSANCj4gbGlzdGVkPyAgVGhlIHBocmFzaW5nIHJl YWRzIGFzIGlmIHRoYXQgbWF5IHRoZSBjYXNlIGFuZCB3b3VsZCBiZSANCj4gYmV0dGVyIHRvIGlu Y2x1ZGUgdGhlbSBhbGwgb3IgcG9pbnRlcnMgb3IgY2hhbmdlIHRoZSBwaHJhc2luZy4NCj4gDQo+ IDIuIEFsc28gaW4gdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHNlY3Rpb24sDQo+IA0KPiAg ICJBIHJlY2lwaWVudCBtYXkgbm90IHVuZGVyc3RhbmQgdGhlIG5ld2x5IGludHJvZHVjZWQgImNu ZiIgY2xhaW0gYW5kDQo+ICAgbWF5IGNvbnNlcXVlbnRseSB0cmVhdCBpdCBhcyBhIGJlYXJlciB0 b2tlbi4iDQo+IA0KPiBXaGF0IGlzIHRoZSBwcm9wZXIgaGFuZGxpbmcgcmVxdWlyZW1lbnQgd2hl biBhbiB1bmtub3duIGNsYWltIGlzIA0KPiBwcmVzZW50PyAgU2VjdGlvbiAzLjEgc2F5czoNCj4g ICJXaGVuIGEgcmVjaXBpZW50IHJlY2VpdmVzIGEgImNuZiIgY2xhaW0gd2l0aCBhDQo+ICAgbWVt YmVyIHRoYXQgaXQgZG9lcyBub3QgdW5kZXJzdGFuZCwgaXQgTVVTVCBpZ25vcmUgdGhhdCBtZW1i ZXIuIg0KPiANCj4gSXMgdGhpcyB3aHkgaXQgaXMgdHJlYXRlZCBhcyBhIGJlYXJlciB0b2tlbiBy YXRoZXIgdGhhbiBiZWluZyANCj4gcmVqZWN0ZWQ/ICBJcyB0aGlzIHJlYWxseSB0aGUgYWN0aW9u IHlvdSB3YW50IHRvIHNlZSB3aXRoIGNuZj8gIFdoeSANCj4gaXNuJ3QgdGhlcmUgYW4gZXJyb3Ig YW5kIGEgcmVzZW5kIGFzIGEgYmVhcmVyIHRva2VuIHNvIHRoYXQgcGFydGllcyANCj4gdW5kZXJz dGFuZCAob3IgaGF2ZSBhbiBvcHBvcnR1bml0eSB0byB1bmRlcnN0YW5kKSB0aGF0IHRoZXJlIHdl cmUgDQo+IGlzc3Vlcz8NCj4gDQo+IFRoZW4gdGhlIGZvbGxvd2luZyB0ZXh0IGluIHRoZSBzZWN1 cml0eSBzZWN0aW9uIHNheXM6DQo+ICAiV2hpbGUgdGhpcyBpcyBhDQo+ICAgbGVnaXRpbWF0ZSBj b25jZXJuLCBpdCBpcyBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzIHNwZWNpZmljYXRpb24sDQo+ ICAgc2luY2UgZGVtb25zdHJhdGlvbiB0aGUgcG9zc2Vzc2lvbiBvZiB0aGUga2V5IGFzc29jaWF0 ZWQgd2l0aCB0aGUNCj4gICAiY25mIiBjbGFpbSBpcyBub3QgY292ZXJlZCBieSB0aGlzIHNwZWNp ZmljYXRpb24uIEZvciBtb3JlIGRldGFpbHMsDQo+IA0KPiBIb3cgaXMgdGhpcyBvdXRzaWRlIG9m IHRoZSBzY29wZSBvZiB0aGlzIGRyYWZ0PyAgY25mIGlzIGRlZmluZWQgaW4gDQo+IHRoaXMgZHJh ZnQsIHNvIGhhbmRsaW5nIHNob3VsZCBiZSBjb3ZlcmVkIGluIHRoaXMgZHJhZnQuICBBIHBvaW50 ZXIgdG8gDQo+IHRoZSBQT1AgYXJjaGl0ZWN0dXJlIGRyYWZ0IGlzIG5vdCBoZWxwZnVsIGFzIGl0 IGlzIG5vdCBkZWZpbmVkIHRoZXJlLCANCj4gaXQncyBjb3ZlcmVkIGludCBoaXMgZHJhZnQuICBT aG91bGQgdGhpcyB0ZXh0IGp1c3QgYmUgcmVtb3ZlZCBhbmQgDQo+IHJlcGxhY2VkIHdpdGggbW9y ZSBleHBsaWNpdCBoYW5kbGluZyBpbmZvcm1hdGlvbiBpbnQgaGUgYm9keSBvZiB0aGlzIA0KPiBk cmFmdD8NCj4gDQo+IFRoYW5rcyENCj4gDQo+IC0tDQo+IA0KPiBCZXN0IHJlZ2FyZHMsDQo+IEth dGhsZWVuDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPiBPQXV0aCBtYWlsaW5nIGxpc3QNCj4gT0F1dGhAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBp ZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0K From nobody Tue Nov 24 18:41:24 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D05C51ACE03 for ; Tue, 24 Nov 2015 18:41:22 -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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4kNkBM1sYcp0 for ; Tue, 24 Nov 2015 18:41:21 -0800 (PST) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC60C1ACE01 for ; Tue, 24 Nov 2015 18:41:20 -0800 (PST) Received: by wmww144 with SMTP id w144so51135182wmw.0 for ; Tue, 24 Nov 2015 18:41:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=uc1HnEpiRE2o2TlIv8OqiyncBSKBqv/8+jZ7We5dvnc=; b=Ag/NhmiYOkMtMpRa8+VL5cGttnYggQfjuclEhwhdbXRr/qMwa1ARakTYme2dkajCDj 6mm77jCB/Uu1Vwlg9F4eLEgRtbwHVwTtxRnNVH8yqg8XZXbafS/BUTmI8ctra7kz58us UN1kcus9mt1tNqPB88Z+g4U0xGcgfuM+6/dEzsrqesZFYS5kXU/4HlGKtNRcVmrmlinV KosVpYK0nSXViAwY1t+bvXTH8mMqxX2w/GyKLjYaluOsNN8uQyYdQ9Ohm8wm9M5NdTon YMlxdJLoTsw/V88oT6AxuRne9sR2/cc11C2KAZnD3gYArFWAP7vLH+6hRd8F4Vsd/9Bo 8aXA== MIME-Version: 1.0 X-Received: by 10.28.224.7 with SMTP id x7mr1484236wmg.17.1448419279531; Tue, 24 Nov 2015 18:41:19 -0800 (PST) Received: by 10.28.52.130 with HTTP; Tue, 24 Nov 2015 18:41:19 -0800 (PST) In-Reply-To: References: Date: Tue, 24 Nov 2015 21:41:19 -0500 Message-ID: From: Kathleen Moriarty To: Mike Jones Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-proof-of-possession X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2015 02:41:23 -0000 Hi Mike, Thanks for the quick turn-around. Just one more comment on my comments. On Tue, Nov 24, 2015 at 9:10 PM, Mike Jones w= rote: > Thanks for your review comments, Kathleen. Responses are inline below... > >> -----Original Message----- >> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Kathleen >> Moriarty >> Sent: Tuesday, November 24, 2015 9:44 AM >> To: oauth@ietf.org >> Subject: [OAUTH-WG] AD review of draft-ietf-oauth-proof-of-possession >> >> Hi, >> >> Thank you all for your work on this draft! I just have a few questions: >> >> 1. Security considerations section says: >> >> "All of the normal security issues, especially in relationship to >> comparing URIs and dealing with unrecognized values, that are >> discussed in JWT [JWT] also apply here." >> >> I find that to be odd phrasing that would likely be picked up in subsequ= ent >> reviews. Please remove the word "normal" so that all of the security is= sues >> discusses in JWT are included. Are there other 'normal considerations i= n >> addition to those in JWT that need to be listed? The phrasing reads as = if that >> may the case and would be better to include them all or pointers or chan= ge >> the phrasing. > > You're right. I removed this awkward wording. > >> 2. Also in the security considerations section, >> >> "A recipient may not understand the newly introduced "cnf" claim and >> may consequently treat it as a bearer token." >> >> What is the proper handling requirement when an unknown claim is >> present? Section 3.1 says: >> "When a recipient receives a "cnf" claim with a >> member that it does not understand, it MUST ignore that member." >> >> Is this why it is treated as a bearer token rather than being rejected? = Is this >> really the action you want to see with cnf? Why isn't there an error an= d a >> resend as a bearer token so that parties understand (or have an opportun= ity >> to understand) that there were issues? >> >> Then the following text in the security section says: >> "While this is a >> legitimate concern, it is outside the scope of this specification, >> since demonstration the possession of the key associated with the >> "cnf" claim is not covered by this specification. For more details, >> >> How is this outside of the scope of this draft? cnf is defined in this = draft, so >> handling should be covered in this draft. A pointer to the POP architec= ture >> draft is not helpful as it is not defined there, it's covered int his dr= aft. Should >> this text just be removed and replaced with more explicit handling >> information int he body of this draft? > > Good catch. JWT [RFC 7519] Section 4 says that claims that are not under= stood must be ignored unless otherwise specified by the application. This = allows new claims to be dynamically added without breaking existing applica= tions. For the same reason, I have incorporated this language about unders= tanding claims from 7519, but having it be about understanding confirmation= members. Ultimately, what features must be implemented are always up to t= he application, just as with JWT claims. The new text in Section 3.1 looks good. I'm not sure why the word "typically" appears int he new text of the security considerations section though after reading the new text in 3.1. Wouldn't it just be ignored since 3.1 now says: "However, in the absence of such requirements, all confirmation members that are not understood by implementations MUST be ignored." Thanks, Kathleen > >> Thanks! >> >> -- >> >> Best regards, >> Kathleen >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > Thanks again, > -- Mike > --=20 Best regards, Kathleen From nobody Tue Nov 24 19:11:06 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 780A51ACE48 for ; Tue, 24 Nov 2015 19:11:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uf81lD-7bo1j for ; Tue, 24 Nov 2015 19:11:01 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0798.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::798]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7762E1ACE47 for ; Tue, 24 Nov 2015 19:11:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=kutTGE7A2uSW8uoWO9iMS3RNLNuoRqcp0yGXVnylsE4=; b=SIE8bOzf09CRc0ODVB5fJVV6SRXT5/CaXRsKwu5jVUxCYFe9n++WDmT5VZo78pQMdxygiFMlPGqYK0807T7ZZYeo8faAfBbJvSB9s9rfyPQoAZzQ/QSd6PTE3LQckzlHdbzj/aSU6A/Y6rJGqBJWWq1Ati08oM9CZo7ddvoZn0I= Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB441.namprd03.prod.outlook.com (10.141.141.142) with Microsoft SMTP Server (TLS) id 15.1.331.20; Wed, 25 Nov 2015 03:10:42 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0331.023; Wed, 25 Nov 2015 03:10:42 +0000 From: Mike Jones To: Kathleen Moriarty Thread-Topic: [OAUTH-WG] AD review of draft-ietf-oauth-proof-of-possession Thread-Index: AQHRJt++kWDp0FqlfEmPEzc+Ih7voJ6r6UxQgAAee4CAAAb2QA== Date: Wed, 25 Nov 2015 03:10:42 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [50.47.85.157] x-microsoft-exchange-diagnostics: 1; BY2PR03MB441; 5:Srfe3TQpVnm0EHaMOh2bpH/dGEaXuzMYXEFk0jKKco83z3WHvFjyIgwqYFPf7vW52/Sl4V+U3d3yjO46lO/mH6PKkeJpeQSf9Ss8LHGSL82593yidEzva2pVZLyl0bmzHBxsysCu8owsVNTAFgjR0Q==; 24:yuO/7ad7xZJEhUdi1fSCcgYQM6YAedlRCFdtxHAKr3Vq5ixC3OeTCzAJk/2wif2WUi7tNsoLfYQkY5knRFQm8r2MEwP4VM9gTEL7NLAyohw= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB441; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425024)(601004)(2401047)(8121501046)(520078)(5005006)(3002001)(10201501046)(61426024)(61427024); SRVR:BY2PR03MB441; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB441; x-forefront-prvs: 0771670921 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(51914003)(199003)(24454002)(189002)(13464003)(377454003)(43784003)(164054003)(5002640100001)(6116002)(3846002)(102836003)(230783001)(586003)(87936001)(99286002)(122556002)(105586002)(74316001)(5003600100002)(50986999)(40100003)(106116001)(76176999)(106356001)(5007970100001)(11100500001)(86612001)(54356999)(86362001)(8990500004)(33656002)(10090500001)(10400500002)(10290500002)(5005710100001)(5004730100002)(189998001)(66066001)(77096005)(5001920100001)(5001960100002)(2900100001)(81156007)(5008740100001)(110136002)(15975445007)(76576001)(92566002)(97736004)(19580405001)(101416001)(19580395003)(2950100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB441; H:BY2PR03MB442.namprd03.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:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Nov 2015 03:10:42.2020 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB441 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-proof-of-possession X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2015 03:11:05 -0000 RmFpciBxdWVzdGlvbiBhYm91dCB0aGUgdXNlIG9mICJ0eXBpY2FsbHkiLiAgVGhlIHJlYXNvbiBp dCdzIHRoZXJlIGlzIHRoYXQgdGhpcyBsYW5ndWFnZSBpbiBKV1QgW1JGQyA3NTE5XSBTZWN0aW9u IDQgZG9lcyBwZXJtaXQgYXBwbGljYXRpb25zIHRvIHJlcXVpcmUgdGhhdCBKV1RzIHdpdGggbm90 LXVuZGVyc3Rvb2QgY2xhaW1zIGJlIHJlamVjdGVkLCByYXRoZXIgdGhhbiBpZ25vcmVkLCBldmVu IHRob3VnaCB0aGF0J3Mgbm90IHRoZSBkZWZhdWx0IGJlaGF2aW9yOg0KDQogICBUaGUgc2V0IG9m IGNsYWltcyB0aGF0IGEgSldUIG11c3QgY29udGFpbiB0byBiZSBjb25zaWRlcmVkIHZhbGlkIGlz DQogICBjb250ZXh0IGRlcGVuZGVudCBhbmQgaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBz cGVjaWZpY2F0aW9uLg0KICAgU3BlY2lmaWMgYXBwbGljYXRpb25zIG9mIEpXVHMgd2lsbCByZXF1 aXJlIGltcGxlbWVudGF0aW9ucyB0bw0KICAgdW5kZXJzdGFuZCBhbmQgcHJvY2VzcyBzb21lIGNs YWltcyBpbiBwYXJ0aWN1bGFyIHdheXMuICBIb3dldmVyLCBpbg0KICAgdGhlIGFic2VuY2Ugb2Yg c3VjaCByZXF1aXJlbWVudHMsIGFsbCBjbGFpbXMgdGhhdCBhcmUgbm90IHVuZGVyc3Rvb2QNCiAg IGJ5IGltcGxlbWVudGF0aW9ucyBNVVNUIGJlIGlnbm9yZWQuDQoNClNvIHdoZW4gbm90IHVuZGVy c3Rvb2QsICJjbmYiIHdvdWxkIHR5cGljYWxseSBiZSBpZ25vcmVkLCBidXQgbWlnaHQgbm90IGJl Lg0KDQoJCQkJLS0gTWlrZQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogS2F0 aGxlZW4gTW9yaWFydHkgW21haWx0bzprYXRobGVlbi5tb3JpYXJ0eS5pZXRmQGdtYWlsLmNvbV0g DQpTZW50OiBUdWVzZGF5LCBOb3ZlbWJlciAyNCwgMjAxNSA2OjQxIFBNDQpUbzogTWlrZSBKb25l cyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPg0KQ2M6IG9hdXRoQGlldGYub3JnDQpTdWJq ZWN0OiBSZTogW09BVVRILVdHXSBBRCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1vYXV0aC1wcm9vZi1v Zi1wb3NzZXNzaW9uDQoNCkhpIE1pa2UsDQoNClRoYW5rcyBmb3IgdGhlIHF1aWNrIHR1cm4tYXJv dW5kLiAgSnVzdCBvbmUgbW9yZSBjb21tZW50IG9uIG15IGNvbW1lbnRzLg0KDQpPbiBUdWUsIE5v diAyNCwgMjAxNSBhdCA5OjEwIFBNLCBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29m dC5jb20+IHdyb3RlOg0KPiBUaGFua3MgZm9yIHlvdXIgcmV2aWV3IGNvbW1lbnRzLCBLYXRobGVl bi4gIFJlc3BvbnNlcyBhcmUgaW5saW5lIGJlbG93Li4uDQo+DQo+PiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPj4gRnJvbTogT0F1dGggW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgS2F0aGxlZW4gDQo+PiBNb3JpYXJ0eQ0KPj4gU2VudDogVHVlc2RheSwg Tm92ZW1iZXIgMjQsIDIwMTUgOTo0NCBBTQ0KPj4gVG86IG9hdXRoQGlldGYub3JnDQo+PiBTdWJq ZWN0OiBbT0FVVEgtV0ddIEFEIHJldmlldyBvZiBkcmFmdC1pZXRmLW9hdXRoLXByb29mLW9mLXBv c3Nlc3Npb24NCj4+DQo+PiBIaSwNCj4+DQo+PiBUaGFuayB5b3UgYWxsIGZvciB5b3VyIHdvcmsg b24gdGhpcyBkcmFmdCEgIEkganVzdCBoYXZlIGEgZmV3IHF1ZXN0aW9uczoNCj4+DQo+PiAxLiBT ZWN1cml0eSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uIHNheXM6DQo+Pg0KPj4gIkFsbCBvZiB0aGUg bm9ybWFsIHNlY3VyaXR5IGlzc3VlcywgZXNwZWNpYWxseSBpbiByZWxhdGlvbnNoaXAgdG8NCj4+ ICAgIGNvbXBhcmluZyBVUklzIGFuZCBkZWFsaW5nIHdpdGggdW5yZWNvZ25pemVkIHZhbHVlcywg dGhhdCBhcmUNCj4+ICAgIGRpc2N1c3NlZCBpbiBKV1QgW0pXVF0gYWxzbyBhcHBseSBoZXJlLiIN Cj4+DQo+PiBJIGZpbmQgdGhhdCB0byBiZSBvZGQgcGhyYXNpbmcgdGhhdCB3b3VsZCBsaWtlbHkg YmUgcGlja2VkIHVwIGluIA0KPj4gc3Vic2VxdWVudCByZXZpZXdzLiAgUGxlYXNlIHJlbW92ZSB0 aGUgd29yZCAibm9ybWFsIiBzbyB0aGF0IGFsbCBvZiANCj4+IHRoZSBzZWN1cml0eSBpc3N1ZXMg ZGlzY3Vzc2VzIGluIEpXVCBhcmUgaW5jbHVkZWQuICBBcmUgdGhlcmUgb3RoZXIgDQo+PiAnbm9y bWFsIGNvbnNpZGVyYXRpb25zIGluIGFkZGl0aW9uIHRvIHRob3NlIGluIEpXVCB0aGF0IG5lZWQg dG8gYmUgDQo+PiBsaXN0ZWQ/ICBUaGUgcGhyYXNpbmcgcmVhZHMgYXMgaWYgdGhhdCBtYXkgdGhl IGNhc2UgYW5kIHdvdWxkIGJlIA0KPj4gYmV0dGVyIHRvIGluY2x1ZGUgdGhlbSBhbGwgb3IgcG9p bnRlcnMgb3IgY2hhbmdlIHRoZSBwaHJhc2luZy4NCj4NCj4gWW91J3JlIHJpZ2h0LiAgSSByZW1v dmVkIHRoaXMgYXdrd2FyZCB3b3JkaW5nLg0KPg0KPj4gMi4gQWxzbyBpbiB0aGUgc2VjdXJpdHkg Y29uc2lkZXJhdGlvbnMgc2VjdGlvbiwNCj4+DQo+PiAgICAiQSByZWNpcGllbnQgbWF5IG5vdCB1 bmRlcnN0YW5kIHRoZSBuZXdseSBpbnRyb2R1Y2VkICJjbmYiIGNsYWltIGFuZA0KPj4gICAgbWF5 IGNvbnNlcXVlbnRseSB0cmVhdCBpdCBhcyBhIGJlYXJlciB0b2tlbi4iDQo+Pg0KPj4gV2hhdCBp cyB0aGUgcHJvcGVyIGhhbmRsaW5nIHJlcXVpcmVtZW50IHdoZW4gYW4gdW5rbm93biBjbGFpbSBp cyANCj4+IHByZXNlbnQ/ICBTZWN0aW9uIDMuMSBzYXlzOg0KPj4gICAiV2hlbiBhIHJlY2lwaWVu dCByZWNlaXZlcyBhICJjbmYiIGNsYWltIHdpdGggYQ0KPj4gICAgbWVtYmVyIHRoYXQgaXQgZG9l cyBub3QgdW5kZXJzdGFuZCwgaXQgTVVTVCBpZ25vcmUgdGhhdCBtZW1iZXIuIg0KPj4NCj4+IElz IHRoaXMgd2h5IGl0IGlzIHRyZWF0ZWQgYXMgYSBiZWFyZXIgdG9rZW4gcmF0aGVyIHRoYW4gYmVp bmcgDQo+PiByZWplY3RlZD8gIElzIHRoaXMgcmVhbGx5IHRoZSBhY3Rpb24geW91IHdhbnQgdG8g c2VlIHdpdGggY25mPyAgV2h5IA0KPj4gaXNuJ3QgdGhlcmUgYW4gZXJyb3IgYW5kIGEgcmVzZW5k IGFzIGEgYmVhcmVyIHRva2VuIHNvIHRoYXQgcGFydGllcyANCj4+IHVuZGVyc3RhbmQgKG9yIGhh dmUgYW4gb3Bwb3J0dW5pdHkgdG8gdW5kZXJzdGFuZCkgdGhhdCB0aGVyZSB3ZXJlIGlzc3Vlcz8N Cj4+DQo+PiBUaGVuIHRoZSBmb2xsb3dpbmcgdGV4dCBpbiB0aGUgc2VjdXJpdHkgc2VjdGlvbiBz YXlzOg0KPj4gICAiV2hpbGUgdGhpcyBpcyBhDQo+PiAgICBsZWdpdGltYXRlIGNvbmNlcm4sIGl0 IGlzIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgc3BlY2lmaWNhdGlvbiwNCj4+ICAgIHNpbmNl IGRlbW9uc3RyYXRpb24gdGhlIHBvc3Nlc3Npb24gb2YgdGhlIGtleSBhc3NvY2lhdGVkIHdpdGgg dGhlDQo+PiAgICAiY25mIiBjbGFpbSBpcyBub3QgY292ZXJlZCBieSB0aGlzIHNwZWNpZmljYXRp b24uIEZvciBtb3JlIA0KPj4gZGV0YWlscywNCj4+DQo+PiBIb3cgaXMgdGhpcyBvdXRzaWRlIG9m IHRoZSBzY29wZSBvZiB0aGlzIGRyYWZ0PyAgY25mIGlzIGRlZmluZWQgaW4gDQo+PiB0aGlzIGRy YWZ0LCBzbyBoYW5kbGluZyBzaG91bGQgYmUgY292ZXJlZCBpbiB0aGlzIGRyYWZ0LiAgQSBwb2lu dGVyIA0KPj4gdG8gdGhlIFBPUCBhcmNoaXRlY3R1cmUgZHJhZnQgaXMgbm90IGhlbHBmdWwgYXMg aXQgaXMgbm90IGRlZmluZWQgDQo+PiB0aGVyZSwgaXQncyBjb3ZlcmVkIGludCBoaXMgZHJhZnQu ICBTaG91bGQgdGhpcyB0ZXh0IGp1c3QgYmUgcmVtb3ZlZCANCj4+IGFuZCByZXBsYWNlZCB3aXRo IG1vcmUgZXhwbGljaXQgaGFuZGxpbmcgaW5mb3JtYXRpb24gaW50IGhlIGJvZHkgb2YgdGhpcyBk cmFmdD8NCj4NCj4gR29vZCBjYXRjaC4gIEpXVCBbUkZDIDc1MTldIFNlY3Rpb24gNCBzYXlzIHRo YXQgY2xhaW1zIHRoYXQgYXJlIG5vdCB1bmRlcnN0b29kIG11c3QgYmUgaWdub3JlZCB1bmxlc3Mg b3RoZXJ3aXNlIHNwZWNpZmllZCBieSB0aGUgYXBwbGljYXRpb24uICBUaGlzIGFsbG93cyBuZXcg Y2xhaW1zIHRvIGJlIGR5bmFtaWNhbGx5IGFkZGVkIHdpdGhvdXQgYnJlYWtpbmcgZXhpc3Rpbmcg YXBwbGljYXRpb25zLiAgRm9yIHRoZSBzYW1lIHJlYXNvbiwgSSBoYXZlIGluY29ycG9yYXRlZCB0 aGlzIGxhbmd1YWdlIGFib3V0IHVuZGVyc3RhbmRpbmcgY2xhaW1zIGZyb20gNzUxOSwgYnV0IGhh dmluZyBpdCBiZSBhYm91dCB1bmRlcnN0YW5kaW5nIGNvbmZpcm1hdGlvbiBtZW1iZXJzLiAgVWx0 aW1hdGVseSwgd2hhdCBmZWF0dXJlcyBtdXN0IGJlIGltcGxlbWVudGVkIGFyZSBhbHdheXMgdXAg dG8gdGhlIGFwcGxpY2F0aW9uLCBqdXN0IGFzIHdpdGggSldUIGNsYWltcy4NCg0KVGhlIG5ldyB0 ZXh0IGluIFNlY3Rpb24gMy4xIGxvb2tzIGdvb2QuICBJJ20gbm90IHN1cmUgd2h5IHRoZSB3b3Jk ICJ0eXBpY2FsbHkiIGFwcGVhcnMgaW50IGhlIG5ldyB0ZXh0IG9mIHRoZSBzZWN1cml0eSBjb25z aWRlcmF0aW9ucyBzZWN0aW9uIHRob3VnaCBhZnRlciByZWFkaW5nIHRoZSBuZXcgdGV4dCBpbiAz LjEuICBXb3VsZG4ndCBpdCBqdXN0IGJlIGlnbm9yZWQgc2luY2UgMy4xIG5vdyBzYXlzOg0KDQog ICAiSG93ZXZlciwgaW4gdGhlIGFic2VuY2Ugb2Ygc3VjaCByZXF1aXJlbWVudHMsDQogICAgYWxs IGNvbmZpcm1hdGlvbiBtZW1iZXJzIHRoYXQgYXJlIG5vdCB1bmRlcnN0b29kIGJ5IGltcGxlbWVu dGF0aW9ucw0KICAgIE1VU1QgYmUgaWdub3JlZC4iDQoNClRoYW5rcywNCkthdGhsZWVuDQoNCg0K Pg0KPj4gVGhhbmtzIQ0KPj4NCj4+IC0tDQo+Pg0KPj4gQmVzdCByZWdhcmRzLA0KPj4gS2F0aGxl ZW4NCj4+DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPj4gT0F1dGggbWFpbGluZyBsaXN0DQo+PiBPQXV0aEBpZXRmLm9yZw0KPj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KPg0KPiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIFRoYW5rcyBhZ2FpbiwNCj4gICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAtLSBNaWtlDQo+DQoNCg0KDQotLSANCg0KQmVzdCByZWdhcmRzLA0KS2F0aGxlZW4N Cg== From nobody Tue Nov 24 19:14:16 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 649A61ACE4B for ; Tue, 24 Nov 2015 19:14:15 -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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KP7hxJFtYPWR for ; Tue, 24 Nov 2015 19:14:12 -0800 (PST) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::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 3CAB31ACE39 for ; Tue, 24 Nov 2015 19:14:12 -0800 (PST) Received: by wmww144 with SMTP id w144so163103243wmw.1 for ; Tue, 24 Nov 2015 19:14:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=YdLxnbmkt4qFhU280XVGs6y0simELfRtjgHMwkeZq34=; b=pwVKIBNEVJOmhlEBmwJLJ3gRMnhXlsxBcK1G3RgplnwND5rvzccvGVhJ5mb7LU522D HODuIGEV9hrOajkCNpPQXaNk2mhiaHBybpNbeosrRpxqszxXDipAtrdvRaP+kC6mPLNw bz0riW8vjyeBtE8eEpS4Dkmwpa5IRH+c+gcKGjmJ0+qv/UZkTSPLjAklarO8uAZSDBUc cFH+nloh1GpgbIbSQ0z4Vb2t704efy/wsXH6VAqrMwBlNyjDZTkwZz/YC1RPJ5gZDYnI Aaz/84jd3ve5goM3KAz/xtI+bVee0K4leSOahhpmPhnEj7PAX/o1NhOSZyofZz6Ejphg /2Og== MIME-Version: 1.0 X-Received: by 10.28.224.7 with SMTP id x7mr1584967wmg.17.1448421250818; Tue, 24 Nov 2015 19:14:10 -0800 (PST) Received: by 10.28.52.130 with HTTP; Tue, 24 Nov 2015 19:14:10 -0800 (PST) In-Reply-To: References: Date: Tue, 24 Nov 2015 22:14:10 -0500 Message-ID: From: Kathleen Moriarty To: Mike Jones Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-proof-of-possession X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2015 03:14:15 -0000 On Tue, Nov 24, 2015 at 10:10 PM, Mike Jones wrote: > Fair question about the use of "typically". The reason it's there is tha= t this language in JWT [RFC 7519] Section 4 does permit applications to req= uire that JWTs with not-understood claims be rejected, rather than ignored,= even though that's not the default behavior: > > The set of claims that a JWT must contain to be considered valid is > context dependent and is outside the scope of this specification. > Specific applications of JWTs will require implementations to > understand and process some claims in particular ways. However, in > the absence of such requirements, all claims that are not understood > by implementations MUST be ignored. > > So when not understood, "cnf" would typically be ignored, but might not b= e. I find that confusing and am now thinking this came up in a discuss as well during the review for 7519, didn't it? Can you elaborate int eh security considerations section a bit more, otherwise this text appears to be conflicting and even with what you intend, it's confusing for implementers and will lead to issues with interoperability. Thanks, Kathleen > > -- Mike > > -----Original Message----- > From: Kathleen Moriarty [mailto:kathleen.moriarty.ietf@gmail.com] > Sent: Tuesday, November 24, 2015 6:41 PM > To: Mike Jones > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-proof-of-possession > > Hi Mike, > > Thanks for the quick turn-around. Just one more comment on my comments. > > On Tue, Nov 24, 2015 at 9:10 PM, Mike Jones = wrote: >> Thanks for your review comments, Kathleen. Responses are inline below..= . >> >>> -----Original Message----- >>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Kathleen >>> Moriarty >>> Sent: Tuesday, November 24, 2015 9:44 AM >>> To: oauth@ietf.org >>> Subject: [OAUTH-WG] AD review of draft-ietf-oauth-proof-of-possession >>> >>> Hi, >>> >>> Thank you all for your work on this draft! I just have a few questions= : >>> >>> 1. Security considerations section says: >>> >>> "All of the normal security issues, especially in relationship to >>> comparing URIs and dealing with unrecognized values, that are >>> discussed in JWT [JWT] also apply here." >>> >>> I find that to be odd phrasing that would likely be picked up in >>> subsequent reviews. Please remove the word "normal" so that all of >>> the security issues discusses in JWT are included. Are there other >>> 'normal considerations in addition to those in JWT that need to be >>> listed? The phrasing reads as if that may the case and would be >>> better to include them all or pointers or change the phrasing. >> >> You're right. I removed this awkward wording. >> >>> 2. Also in the security considerations section, >>> >>> "A recipient may not understand the newly introduced "cnf" claim and >>> may consequently treat it as a bearer token." >>> >>> What is the proper handling requirement when an unknown claim is >>> present? Section 3.1 says: >>> "When a recipient receives a "cnf" claim with a >>> member that it does not understand, it MUST ignore that member." >>> >>> Is this why it is treated as a bearer token rather than being >>> rejected? Is this really the action you want to see with cnf? Why >>> isn't there an error and a resend as a bearer token so that parties >>> understand (or have an opportunity to understand) that there were issue= s? >>> >>> Then the following text in the security section says: >>> "While this is a >>> legitimate concern, it is outside the scope of this specification, >>> since demonstration the possession of the key associated with the >>> "cnf" claim is not covered by this specification. For more >>> details, >>> >>> How is this outside of the scope of this draft? cnf is defined in >>> this draft, so handling should be covered in this draft. A pointer >>> to the POP architecture draft is not helpful as it is not defined >>> there, it's covered int his draft. Should this text just be removed >>> and replaced with more explicit handling information int he body of thi= s draft? >> >> Good catch. JWT [RFC 7519] Section 4 says that claims that are not unde= rstood must be ignored unless otherwise specified by the application. This= allows new claims to be dynamically added without breaking existing applic= ations. For the same reason, I have incorporated this language about under= standing claims from 7519, but having it be about understanding confirmatio= n members. Ultimately, what features must be implemented are always up to = the application, just as with JWT claims. > > The new text in Section 3.1 looks good. I'm not sure why the word "typic= ally" appears int he new text of the security considerations section though= after reading the new text in 3.1. Wouldn't it just be ignored since 3.1 = now says: > > "However, in the absence of such requirements, > all confirmation members that are not understood by implementations > MUST be ignored." > > Thanks, > Kathleen > > >> >>> Thanks! >>> >>> -- >>> >>> Best regards, >>> Kathleen >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> >> Thanks again, >> -- Mike >> > > > > -- > > Best regards, > Kathleen --=20 Best regards, Kathleen From nobody Tue Nov 24 19:25:58 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6279A1A8AAB for ; Tue, 24 Nov 2015 19:25:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sxMxCX6tW4LQ for ; Tue, 24 Nov 2015 19:25:50 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0131.outbound.protection.outlook.com [207.46.100.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD8161ACE32 for ; Tue, 24 Nov 2015 19:25:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=D/c1UIiVaMQbSYeY6Q86mpgLpb+/6bCxyVw/exSHBew=; b=DrB17yAfxQB1bfzdFlvdUmWJfIDOtHJ9T+zTWfnYrp8gr7gnytA2Cku0wsSWBdYs9R4zIj/a9qsPQneSAzrfZ3yqnZ4QhHIwvJdk5ELsLWKbNyYY/1CnGtFD1l719yngrp1UUZCdhXOxdw9VGKub/8HJyQUhIDPXXxxSEzjTQEM= Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) with Microsoft SMTP Server (TLS) id 15.1.331.20; Wed, 25 Nov 2015 03:25:48 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0331.023; Wed, 25 Nov 2015 03:25:48 +0000 From: Mike Jones To: Kathleen Moriarty Thread-Topic: [OAUTH-WG] AD review of draft-ietf-oauth-proof-of-possession Thread-Index: AQHRJt++kWDp0FqlfEmPEzc+Ih7voJ6r6UxQgAAee4CAAAb2QIAAAjcAgAAA9fA= Date: Wed, 25 Nov 2015 03:25:48 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [50.47.85.157] x-microsoft-exchange-diagnostics: 1; BY2PR03MB442; 5:hmWTn9dLSnpQL7LUJVdk62b6bamex6Xk9TLgi9qvzsvGlINXpK4Yer42EmiH7fP0V/BZfAE+X2lEHV+7i2pLLkp78DmSMBa1jx1AHU1AVvUDmZLSVAfM5uGJkpQDEvLcbzzllB01kzb8OOoyeVgBIQ==; 24:WDMfrdCis73jdfAuQ0EVNjtCwJQ6pLIFVLmntxJDL2AitHiYLlLEvdGs9B6XnZojrBfJgM58HvC0PpRKiKtb75WUyK+yn1Bl3kyg2Ze8s7Q= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB442; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425024)(601004)(2401047)(520078)(5005006)(8121501046)(10201501046)(3002001)(61426024)(61427024); SRVR:BY2PR03MB442; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB442; x-forefront-prvs: 0771670921 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(164054003)(43784003)(13464003)(377454003)(51914003)(189002)(24454002)(199003)(10090500001)(5003600100002)(5002640100001)(5005710100001)(586003)(92566002)(10400500002)(3846002)(76176999)(10290500002)(76576001)(102836003)(50986999)(106356001)(110136002)(105586002)(5001960100002)(106116001)(189998001)(8990500004)(99286002)(2900100001)(6116002)(86362001)(81156007)(40100003)(5004730100002)(5007970100001)(97736004)(2950100001)(93886004)(87936001)(33656002)(5008740100001)(15975445007)(74316001)(11100500001)(101416001)(66066001)(122556002)(230783001)(77096005)(86612001)(19580395003)(19580405001)(54356999); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB442; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Nov 2015 03:25:48.3793 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB442 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-proof-of-possession X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2015 03:25:55 -0000 UmF0aGVyIHRoYW4gZWxhYm9yYXRpbmcsIGhhdmluZyBsb29rZWQgYXQgdGhlIHRleHQgd2UncmUg ZGlzY3Vzc2luZyBhZ2FpbiwgSSdtIGdvaW5nIHRvIGNvdW50ZXItcHJvcG9zZSB0aGF0IHdlIGlu c3RlYWQgc2ltcGxpZnkgLSBzdGlja2luZyBvbmx5IHRvIHRoZSBwb2ludCB0aGF0IHRoZSBwYXJh Z3JhcGggaXMgaW50ZW5kaW5nIHRvIGdldCBhY3Jvc3MuICBXb3VsZCBpdCB3b3JrIGZvciB5b3Ug dG8gc2ltcGxpZnkgdGhlIGN1cnJlbnQgdGV4dDoNCg0KICAgICJBIHJlY2lwaWVudCBtaWdodCBu b3QgdW5kZXJzdGFuZCB0aGUgY25mIGNsYWltLCBpbiB3aGljaCBjYXNlIGl0IHdpbGwgdHlwaWNh bGx5IGJlIGlnbm9yZWQuIFVubGVzcyB0aGlzIGlzIGFjY2VwdGFibGUgYmVoYXZpb3IsIGFwcGxp Y2F0aW9ucyB0aGF0IG5lZWQgdGhlIHByb29mLW9mLXBvc3Nlc3Npb24ga2V5cyBjb21tdW5pY2F0 ZWQgd2l0aCBpdCB0byBiZSB1bmRlcnN0b29kIGFuZCBwcm9jZXNzZWQgbXVzdCByZXF1aXJlIHRo YXQgdGhlIHBhcnRzIG9mIHRoaXMgc3BlY2lmaWNhdGlvbiB0aGF0IHRoZXkgdXNlIGJlIGltcGxl bWVudGVkLiINCg0KdG8gdGhpcyBzaW1wbGVyIHRleHQ/DQoNCiAgICAiQSByZWNpcGllbnQgbWln aHQgbm90IHVuZGVyc3RhbmQgdGhlIGNuZiBjbGFpbS4gIEFwcGxpY2F0aW9ucyB0aGF0IG5lZWQg dGhlIHByb29mLW9mLXBvc3Nlc3Npb24ga2V5cyBjb21tdW5pY2F0ZWQgd2l0aCBpdCB0byBiZSB1 bmRlcnN0b29kIGFuZCBwcm9jZXNzZWQgbXVzdCByZXF1aXJlIHRoYXQgdGhlIHBhcnRzIG9mIHRo aXMgc3BlY2lmaWNhdGlvbiB0aGF0IHRoZXkgdXNlIGJlIGltcGxlbWVudGVkLiINCg0KVGhlICJt dXN0IGlnbm9yZSIgdG9waWMgaXMgYWxyZWFkeSBhZGRyZXNzZWQgaW4gdGhlIHNlY29uZCBwYXJh Z3JhcGggb2YgMy4xIChhbmQgd2l0aCBleGFjdGx5IHRoZSBzZW1hbnRpY3MgYXMgdGhlIHJlc3Qg b2YgSldUKSwgYW5kIHNvIGRvZXNuJ3QgaGF2ZSB0byBiZSByZS1yYWlzZWQgaGVyZSwgYXMgaXQg Y3VycmVudGx5IGlzLiAgUmUtcmFpc2luZyBpdCBpcyBjbGVhcmx5IGEgcG9pbnQgb2YgZGlzdHJh Y3Rpb24uDQoNCkZvciB3aGF0IGl0J3Mgd29ydGgsIEkgZG9uJ3QgcmVtZW1iZXIgYW55IERJU0NV U1NlcyBvbiB0aGlzIHRvcGljIChhbHRob3VnaCBpdCdzIHBvc3NpYmxlIHRoYXQgeW91ciBtZW1v cnkgaXMgYmV0dGVyIHRoYW4gbWluZSBvbiB0aGlzIHBvaW50KS4NCg0KCQkJCUJlc3Qgd2lzaGVz LA0KCQkJCS0tIE1pa2UNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEthdGhs ZWVuIE1vcmlhcnR5IFttYWlsdG86a2F0aGxlZW4ubW9yaWFydHkuaWV0ZkBnbWFpbC5jb21dIA0K U2VudDogVHVlc2RheSwgTm92ZW1iZXIgMjQsIDIwMTUgNzoxNCBQTQ0KVG86IE1pa2UgSm9uZXMg PE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4NCkNjOiBvYXV0aEBpZXRmLm9yZw0KU3ViamVj dDogUmU6IFtPQVVUSC1XR10gQUQgcmV2aWV3IG9mIGRyYWZ0LWlldGYtb2F1dGgtcHJvb2Ytb2Yt cG9zc2Vzc2lvbg0KDQpPbiBUdWUsIE5vdiAyNCwgMjAxNSBhdCAxMDoxMCBQTSwgTWlrZSBKb25l cyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPiB3cm90ZToNCj4gRmFpciBxdWVzdGlvbiBh Ym91dCB0aGUgdXNlIG9mICJ0eXBpY2FsbHkiLiAgVGhlIHJlYXNvbiBpdCdzIHRoZXJlIGlzIHRo YXQgdGhpcyBsYW5ndWFnZSBpbiBKV1QgW1JGQyA3NTE5XSBTZWN0aW9uIDQgZG9lcyBwZXJtaXQg YXBwbGljYXRpb25zIHRvIHJlcXVpcmUgdGhhdCBKV1RzIHdpdGggbm90LXVuZGVyc3Rvb2QgY2xh aW1zIGJlIHJlamVjdGVkLCByYXRoZXIgdGhhbiBpZ25vcmVkLCBldmVuIHRob3VnaCB0aGF0J3Mg bm90IHRoZSBkZWZhdWx0IGJlaGF2aW9yOg0KPg0KPiAgICBUaGUgc2V0IG9mIGNsYWltcyB0aGF0 IGEgSldUIG11c3QgY29udGFpbiB0byBiZSBjb25zaWRlcmVkIHZhbGlkIGlzDQo+ICAgIGNvbnRl eHQgZGVwZW5kZW50IGFuZCBpcyBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzIHNwZWNpZmljYXRp b24uDQo+ICAgIFNwZWNpZmljIGFwcGxpY2F0aW9ucyBvZiBKV1RzIHdpbGwgcmVxdWlyZSBpbXBs ZW1lbnRhdGlvbnMgdG8NCj4gICAgdW5kZXJzdGFuZCBhbmQgcHJvY2VzcyBzb21lIGNsYWltcyBp biBwYXJ0aWN1bGFyIHdheXMuICBIb3dldmVyLCBpbg0KPiAgICB0aGUgYWJzZW5jZSBvZiBzdWNo IHJlcXVpcmVtZW50cywgYWxsIGNsYWltcyB0aGF0IGFyZSBub3QgdW5kZXJzdG9vZA0KPiAgICBi eSBpbXBsZW1lbnRhdGlvbnMgTVVTVCBiZSBpZ25vcmVkLg0KPg0KPiBTbyB3aGVuIG5vdCB1bmRl cnN0b29kLCAiY25mIiB3b3VsZCB0eXBpY2FsbHkgYmUgaWdub3JlZCwgYnV0IG1pZ2h0IG5vdCBi ZS4NCg0KSSBmaW5kIHRoYXQgY29uZnVzaW5nIGFuZCBhbSBub3cgdGhpbmtpbmcgdGhpcyBjYW1l IHVwIGluIGEgZGlzY3VzcyBhcyB3ZWxsIGR1cmluZyB0aGUgcmV2aWV3IGZvciA3NTE5LCBkaWRu J3QgaXQ/ICBDYW4geW91IGVsYWJvcmF0ZSBpbnQgZWggc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMg c2VjdGlvbiBhIGJpdCBtb3JlLCBvdGhlcndpc2UgdGhpcyB0ZXh0IGFwcGVhcnMgdG8gYmUgY29u ZmxpY3RpbmcgYW5kIGV2ZW4gd2l0aCB3aGF0IHlvdSBpbnRlbmQsIGl0J3MgY29uZnVzaW5nIGZv ciBpbXBsZW1lbnRlcnMgYW5kIHdpbGwgbGVhZCB0byBpc3N1ZXMgd2l0aCBpbnRlcm9wZXJhYmls aXR5Lg0KDQpUaGFua3MsDQpLYXRobGVlbg0KDQoNCj4NCj4gICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAtLSBNaWtlDQo+DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZy b206IEthdGhsZWVuIE1vcmlhcnR5IFttYWlsdG86a2F0aGxlZW4ubW9yaWFydHkuaWV0ZkBnbWFp bC5jb21dDQo+IFNlbnQ6IFR1ZXNkYXksIE5vdmVtYmVyIDI0LCAyMDE1IDY6NDEgUE0NCj4gVG86 IE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4NCj4gQ2M6IG9hdXRoQGll dGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIEFEIHJldmlldyBvZiANCj4gZHJhZnQt aWV0Zi1vYXV0aC1wcm9vZi1vZi1wb3NzZXNzaW9uDQo+DQo+IEhpIE1pa2UsDQo+DQo+IFRoYW5r cyBmb3IgdGhlIHF1aWNrIHR1cm4tYXJvdW5kLiAgSnVzdCBvbmUgbW9yZSBjb21tZW50IG9uIG15 IGNvbW1lbnRzLg0KPg0KPiBPbiBUdWUsIE5vdiAyNCwgMjAxNSBhdCA5OjEwIFBNLCBNaWtlIEpv bmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+IHdyb3RlOg0KPj4gVGhhbmtzIGZvciB5 b3VyIHJldmlldyBjb21tZW50cywgS2F0aGxlZW4uICBSZXNwb25zZXMgYXJlIGlubGluZSBiZWxv dy4uLg0KPj4NCj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+IEZyb206IE9BdXRo IFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEthdGhsZWVuIA0K Pj4+IE1vcmlhcnR5DQo+Pj4gU2VudDogVHVlc2RheSwgTm92ZW1iZXIgMjQsIDIwMTUgOTo0NCBB TQ0KPj4+IFRvOiBvYXV0aEBpZXRmLm9yZw0KPj4+IFN1YmplY3Q6IFtPQVVUSC1XR10gQUQgcmV2 aWV3IG9mIA0KPj4+IGRyYWZ0LWlldGYtb2F1dGgtcHJvb2Ytb2YtcG9zc2Vzc2lvbg0KPj4+DQo+ Pj4gSGksDQo+Pj4NCj4+PiBUaGFuayB5b3UgYWxsIGZvciB5b3VyIHdvcmsgb24gdGhpcyBkcmFm dCEgIEkganVzdCBoYXZlIGEgZmV3IHF1ZXN0aW9uczoNCj4+Pg0KPj4+IDEuIFNlY3VyaXR5IGNv bnNpZGVyYXRpb25zIHNlY3Rpb24gc2F5czoNCj4+Pg0KPj4+ICJBbGwgb2YgdGhlIG5vcm1hbCBz ZWN1cml0eSBpc3N1ZXMsIGVzcGVjaWFsbHkgaW4gcmVsYXRpb25zaGlwIHRvDQo+Pj4gICAgY29t cGFyaW5nIFVSSXMgYW5kIGRlYWxpbmcgd2l0aCB1bnJlY29nbml6ZWQgdmFsdWVzLCB0aGF0IGFy ZQ0KPj4+ICAgIGRpc2N1c3NlZCBpbiBKV1QgW0pXVF0gYWxzbyBhcHBseSBoZXJlLiINCj4+Pg0K Pj4+IEkgZmluZCB0aGF0IHRvIGJlIG9kZCBwaHJhc2luZyB0aGF0IHdvdWxkIGxpa2VseSBiZSBw aWNrZWQgdXAgaW4gDQo+Pj4gc3Vic2VxdWVudCByZXZpZXdzLiAgUGxlYXNlIHJlbW92ZSB0aGUg d29yZCAibm9ybWFsIiBzbyB0aGF0IGFsbCBvZiANCj4+PiB0aGUgc2VjdXJpdHkgaXNzdWVzIGRp c2N1c3NlcyBpbiBKV1QgYXJlIGluY2x1ZGVkLiAgQXJlIHRoZXJlIG90aGVyIA0KPj4+ICdub3Jt YWwgY29uc2lkZXJhdGlvbnMgaW4gYWRkaXRpb24gdG8gdGhvc2UgaW4gSldUIHRoYXQgbmVlZCB0 byBiZSANCj4+PiBsaXN0ZWQ/ICBUaGUgcGhyYXNpbmcgcmVhZHMgYXMgaWYgdGhhdCBtYXkgdGhl IGNhc2UgYW5kIHdvdWxkIGJlIA0KPj4+IGJldHRlciB0byBpbmNsdWRlIHRoZW0gYWxsIG9yIHBv aW50ZXJzIG9yIGNoYW5nZSB0aGUgcGhyYXNpbmcuDQo+Pg0KPj4gWW91J3JlIHJpZ2h0LiAgSSBy ZW1vdmVkIHRoaXMgYXdrd2FyZCB3b3JkaW5nLg0KPj4NCj4+PiAyLiBBbHNvIGluIHRoZSBzZWN1 cml0eSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uLA0KPj4+DQo+Pj4gICAgIkEgcmVjaXBpZW50IG1h eSBub3QgdW5kZXJzdGFuZCB0aGUgbmV3bHkgaW50cm9kdWNlZCAiY25mIiBjbGFpbSBhbmQNCj4+ PiAgICBtYXkgY29uc2VxdWVudGx5IHRyZWF0IGl0IGFzIGEgYmVhcmVyIHRva2VuLiINCj4+Pg0K Pj4+IFdoYXQgaXMgdGhlIHByb3BlciBoYW5kbGluZyByZXF1aXJlbWVudCB3aGVuIGFuIHVua25v d24gY2xhaW0gaXMgDQo+Pj4gcHJlc2VudD8gIFNlY3Rpb24gMy4xIHNheXM6DQo+Pj4gICAiV2hl biBhIHJlY2lwaWVudCByZWNlaXZlcyBhICJjbmYiIGNsYWltIHdpdGggYQ0KPj4+ICAgIG1lbWJl ciB0aGF0IGl0IGRvZXMgbm90IHVuZGVyc3RhbmQsIGl0IE1VU1QgaWdub3JlIHRoYXQgbWVtYmVy LiINCj4+Pg0KPj4+IElzIHRoaXMgd2h5IGl0IGlzIHRyZWF0ZWQgYXMgYSBiZWFyZXIgdG9rZW4g cmF0aGVyIHRoYW4gYmVpbmcgDQo+Pj4gcmVqZWN0ZWQ/ICBJcyB0aGlzIHJlYWxseSB0aGUgYWN0 aW9uIHlvdSB3YW50IHRvIHNlZSB3aXRoIGNuZj8gIFdoeSANCj4+PiBpc24ndCB0aGVyZSBhbiBl cnJvciBhbmQgYSByZXNlbmQgYXMgYSBiZWFyZXIgdG9rZW4gc28gdGhhdCBwYXJ0aWVzIA0KPj4+ IHVuZGVyc3RhbmQgKG9yIGhhdmUgYW4gb3Bwb3J0dW5pdHkgdG8gdW5kZXJzdGFuZCkgdGhhdCB0 aGVyZSB3ZXJlIGlzc3Vlcz8NCj4+Pg0KPj4+IFRoZW4gdGhlIGZvbGxvd2luZyB0ZXh0IGluIHRo ZSBzZWN1cml0eSBzZWN0aW9uIHNheXM6DQo+Pj4gICAiV2hpbGUgdGhpcyBpcyBhDQo+Pj4gICAg bGVnaXRpbWF0ZSBjb25jZXJuLCBpdCBpcyBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzIHNwZWNp ZmljYXRpb24sDQo+Pj4gICAgc2luY2UgZGVtb25zdHJhdGlvbiB0aGUgcG9zc2Vzc2lvbiBvZiB0 aGUga2V5IGFzc29jaWF0ZWQgd2l0aCB0aGUNCj4+PiAgICAiY25mIiBjbGFpbSBpcyBub3QgY292 ZXJlZCBieSB0aGlzIHNwZWNpZmljYXRpb24uIEZvciBtb3JlIA0KPj4+IGRldGFpbHMsDQo+Pj4N Cj4+PiBIb3cgaXMgdGhpcyBvdXRzaWRlIG9mIHRoZSBzY29wZSBvZiB0aGlzIGRyYWZ0PyAgY25m IGlzIGRlZmluZWQgaW4gDQo+Pj4gdGhpcyBkcmFmdCwgc28gaGFuZGxpbmcgc2hvdWxkIGJlIGNv dmVyZWQgaW4gdGhpcyBkcmFmdC4gIEEgcG9pbnRlciANCj4+PiB0byB0aGUgUE9QIGFyY2hpdGVj dHVyZSBkcmFmdCBpcyBub3QgaGVscGZ1bCBhcyBpdCBpcyBub3QgZGVmaW5lZCANCj4+PiB0aGVy ZSwgaXQncyBjb3ZlcmVkIGludCBoaXMgZHJhZnQuICBTaG91bGQgdGhpcyB0ZXh0IGp1c3QgYmUg cmVtb3ZlZCANCj4+PiBhbmQgcmVwbGFjZWQgd2l0aCBtb3JlIGV4cGxpY2l0IGhhbmRsaW5nIGlu Zm9ybWF0aW9uIGludCBoZSBib2R5IG9mIHRoaXMgZHJhZnQ/DQo+Pg0KPj4gR29vZCBjYXRjaC4g IEpXVCBbUkZDIDc1MTldIFNlY3Rpb24gNCBzYXlzIHRoYXQgY2xhaW1zIHRoYXQgYXJlIG5vdCB1 bmRlcnN0b29kIG11c3QgYmUgaWdub3JlZCB1bmxlc3Mgb3RoZXJ3aXNlIHNwZWNpZmllZCBieSB0 aGUgYXBwbGljYXRpb24uICBUaGlzIGFsbG93cyBuZXcgY2xhaW1zIHRvIGJlIGR5bmFtaWNhbGx5 IGFkZGVkIHdpdGhvdXQgYnJlYWtpbmcgZXhpc3RpbmcgYXBwbGljYXRpb25zLiAgRm9yIHRoZSBz YW1lIHJlYXNvbiwgSSBoYXZlIGluY29ycG9yYXRlZCB0aGlzIGxhbmd1YWdlIGFib3V0IHVuZGVy c3RhbmRpbmcgY2xhaW1zIGZyb20gNzUxOSwgYnV0IGhhdmluZyBpdCBiZSBhYm91dCB1bmRlcnN0 YW5kaW5nIGNvbmZpcm1hdGlvbiBtZW1iZXJzLiAgVWx0aW1hdGVseSwgd2hhdCBmZWF0dXJlcyBt dXN0IGJlIGltcGxlbWVudGVkIGFyZSBhbHdheXMgdXAgdG8gdGhlIGFwcGxpY2F0aW9uLCBqdXN0 IGFzIHdpdGggSldUIGNsYWltcy4NCj4NCj4gVGhlIG5ldyB0ZXh0IGluIFNlY3Rpb24gMy4xIGxv b2tzIGdvb2QuICBJJ20gbm90IHN1cmUgd2h5IHRoZSB3b3JkICJ0eXBpY2FsbHkiIGFwcGVhcnMg aW50IGhlIG5ldyB0ZXh0IG9mIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uIHRo b3VnaCBhZnRlciByZWFkaW5nIHRoZSBuZXcgdGV4dCBpbiAzLjEuICBXb3VsZG4ndCBpdCBqdXN0 IGJlIGlnbm9yZWQgc2luY2UgMy4xIG5vdyBzYXlzOg0KPg0KPiAgICAiSG93ZXZlciwgaW4gdGhl IGFic2VuY2Ugb2Ygc3VjaCByZXF1aXJlbWVudHMsDQo+ICAgICBhbGwgY29uZmlybWF0aW9uIG1l bWJlcnMgdGhhdCBhcmUgbm90IHVuZGVyc3Rvb2QgYnkgaW1wbGVtZW50YXRpb25zDQo+ICAgICBN VVNUIGJlIGlnbm9yZWQuIg0KPg0KPiBUaGFua3MsDQo+IEthdGhsZWVuDQo+DQo+DQo+Pg0KPj4+ IFRoYW5rcyENCj4+Pg0KPj4+IC0tDQo+Pj4NCj4+PiBCZXN0IHJlZ2FyZHMsDQo+Pj4gS2F0aGxl ZW4NCj4+Pg0KPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+Pj4gT0F1dGggbWFpbGluZyBsaXN0DQo+Pj4gT0F1dGhAaWV0Zi5vcmcNCj4+PiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQo+Pg0KPj4gICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBUaGFua3MgYWdhaW4sDQo+PiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIC0tIE1pa2UNCj4+DQo+DQo+DQo+DQo+IC0tDQo+DQo+IEJlc3QgcmVn YXJkcywNCj4gS2F0aGxlZW4NCg0KDQoNCi0tIA0KDQpCZXN0IHJlZ2FyZHMsDQpLYXRobGVlbg0K From nobody Wed Nov 25 06:21:53 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81CF71B2D4A for ; Wed, 25 Nov 2015 06:21:52 -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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6QGzTtaenZRM for ; Wed, 25 Nov 2015 06:21:50 -0800 (PST) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c: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 EE1451B2D48 for ; Wed, 25 Nov 2015 06:21:49 -0800 (PST) Received: by vkay187 with SMTP id y187so35215490vka.3 for ; Wed, 25 Nov 2015 06:21:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:mime-version:subject :date:message-id:references:cc:in-reply-to:to; bh=96sOix4UHQRSEIolPELRZq6dwbbPEEi82GHqJku3NMY=; b=ZVt8PgY8Q9x5Dzor1Gc9xpId4jU+CyQT0lgHxWiXcUUqIE1pWJbbElOG00rgphAWPF FSnYatzOGYLGuxo7bSyeY7Gpx1VHmjXpRuXSBeBorSgDT5T798p/cViAgCBdJMuyz/QA r65C+YkREQOD1mF+lD4bcrigAnaVTrVheWRyGj+WBm+2sIW4V745l108hRpk3D5WORZd PrwiWLx93Xnv47uwMPFB4LDe4856gGi0OZtJLB/828h7I87mXrDY6GbatJ2LCL4WP8J1 itma85Gi3i/K0VVkB6Bj8I7WOd1eJd5fXIbqh1U+jI8AcUEH8YGom98H+0fs2xzd5IMf Pwuw== X-Received: by 10.31.162.16 with SMTP id l16mr34654145vke.69.1448461309109; Wed, 25 Nov 2015 06:21:49 -0800 (PST) Received: from [10.60.76.50] (mobile-107-107-57-11.mycingular.net. [107.107.57.11]) by smtp.gmail.com with ESMTPSA id 87sm18523356vkd.8.2015.11.25.06.21.47 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 25 Nov 2015 06:21:48 -0800 (PST) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Date: Wed, 25 Nov 2015 09:21:16 -0500 Message-Id: References: In-Reply-To: To: Mike Jones X-Mailer: iPhone Mail (12H143) Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-proof-of-possession X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2015 14:21:52 -0000 Hi Mike, If the working group is okay with the current text, leave it. What you prop= osed is exactly the same as what is there. I'll note this point in my ballo= t as I think you are leaving ambiguity that is not necessary. After getting far enough on this, I think it was Pete who discussed this wit= h you and he gave up and remained in disagreement. Regards, Kathleen=20 Sent from my iPhone > On Nov 24, 2015, at 10:25 PM, Mike Jones wro= te: >=20 > Rather than elaborating, having looked at the text we're discussing again,= I'm going to counter-propose that we instead simplify - sticking only to th= e point that the paragraph is intending to get across. Would it work for yo= u to simplify the current text: >=20 > "A recipient might not understand the cnf claim, in which case it will t= ypically be ignored. Unless this is acceptable behavior, applications that n= eed the proof-of-possession keys communicated with it to be understood and p= rocessed must require that the parts of this specification that they use be i= mplemented." >=20 > to this simpler text? >=20 > "A recipient might not understand the cnf claim. Applications that nee= d the proof-of-possession keys communicated with it to be understood and pro= cessed must require that the parts of this specification that they use be im= plemented." >=20 > The "must ignore" topic is already addressed in the second paragraph of 3.= 1 (and with exactly the semantics as the rest of JWT), and so doesn't have t= o be re-raised here, as it currently is. Re-raising it is clearly a point o= f distraction. >=20 > For what it's worth, I don't remember any DISCUSSes on this topic (althoug= h it's possible that your memory is better than mine on this point). >=20 > Best wishes, > -- Mike >=20 > -----Original Message----- > From: Kathleen Moriarty [mailto:kathleen.moriarty.ietf@gmail.com]=20 > Sent: Tuesday, November 24, 2015 7:14 PM > To: Mike Jones > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-proof-of-possession >=20 >> On Tue, Nov 24, 2015 at 10:10 PM, Mike Jones wrote: >> Fair question about the use of "typically". The reason it's there is tha= t this language in JWT [RFC 7519] Section 4 does permit applications to requ= ire that JWTs with not-understood claims be rejected, rather than ignored, e= ven though that's not the default behavior: >>=20 >> The set of claims that a JWT must contain to be considered valid is >> context dependent and is outside the scope of this specification. >> Specific applications of JWTs will require implementations to >> understand and process some claims in particular ways. However, in >> the absence of such requirements, all claims that are not understood >> by implementations MUST be ignored. >>=20 >> So when not understood, "cnf" would typically be ignored, but might not b= e. >=20 > I find that confusing and am now thinking this came up in a discuss as wel= l during the review for 7519, didn't it? Can you elaborate int eh security c= onsiderations section a bit more, otherwise this text appears to be conflict= ing and even with what you intend, it's confusing for implementers and will l= ead to issues with interoperability. >=20 > Thanks, > Kathleen >=20 >=20 >>=20 >> -- Mike >>=20 >> -----Original Message----- >> From: Kathleen Moriarty [mailto:kathleen.moriarty.ietf@gmail.com] >> Sent: Tuesday, November 24, 2015 6:41 PM >> To: Mike Jones >> Cc: oauth@ietf.org >> Subject: Re: [OAUTH-WG] AD review of=20 >> draft-ietf-oauth-proof-of-possession >>=20 >> Hi Mike, >>=20 >> Thanks for the quick turn-around. Just one more comment on my comments. >>=20 >>> On Tue, Nov 24, 2015 at 9:10 PM, Mike Jones wrote: >>> Thanks for your review comments, Kathleen. Responses are inline below..= . >>>=20 >>>> -----Original Message----- >>>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Kathleen=20 >>>> Moriarty >>>> Sent: Tuesday, November 24, 2015 9:44 AM >>>> To: oauth@ietf.org >>>> Subject: [OAUTH-WG] AD review of=20 >>>> draft-ietf-oauth-proof-of-possession >>>>=20 >>>> Hi, >>>>=20 >>>> Thank you all for your work on this draft! I just have a few questions= : >>>>=20 >>>> 1. Security considerations section says: >>>>=20 >>>> "All of the normal security issues, especially in relationship to >>>> comparing URIs and dealing with unrecognized values, that are >>>> discussed in JWT [JWT] also apply here." >>>>=20 >>>> I find that to be odd phrasing that would likely be picked up in=20 >>>> subsequent reviews. Please remove the word "normal" so that all of=20 >>>> the security issues discusses in JWT are included. Are there other=20 >>>> 'normal considerations in addition to those in JWT that need to be=20 >>>> listed? The phrasing reads as if that may the case and would be=20 >>>> better to include them all or pointers or change the phrasing. >>>=20 >>> You're right. I removed this awkward wording. >>>=20 >>>> 2. Also in the security considerations section, >>>>=20 >>>> "A recipient may not understand the newly introduced "cnf" claim and >>>> may consequently treat it as a bearer token." >>>>=20 >>>> What is the proper handling requirement when an unknown claim is=20 >>>> present? Section 3.1 says: >>>> "When a recipient receives a "cnf" claim with a >>>> member that it does not understand, it MUST ignore that member." >>>>=20 >>>> Is this why it is treated as a bearer token rather than being=20 >>>> rejected? Is this really the action you want to see with cnf? Why=20 >>>> isn't there an error and a resend as a bearer token so that parties=20 >>>> understand (or have an opportunity to understand) that there were issue= s? >>>>=20 >>>> Then the following text in the security section says: >>>> "While this is a >>>> legitimate concern, it is outside the scope of this specification, >>>> since demonstration the possession of the key associated with the >>>> "cnf" claim is not covered by this specification. For more=20 >>>> details, >>>>=20 >>>> How is this outside of the scope of this draft? cnf is defined in=20 >>>> this draft, so handling should be covered in this draft. A pointer=20 >>>> to the POP architecture draft is not helpful as it is not defined=20 >>>> there, it's covered int his draft. Should this text just be removed=20= >>>> and replaced with more explicit handling information int he body of thi= s draft? >>>=20 >>> Good catch. JWT [RFC 7519] Section 4 says that claims that are not unde= rstood must be ignored unless otherwise specified by the application. This a= llows new claims to be dynamically added without breaking existing applicati= ons. For the same reason, I have incorporated this language about understan= ding claims from 7519, but having it be about understanding confirmation mem= bers. Ultimately, what features must be implemented are always up to the ap= plication, just as with JWT claims. >>=20 >> The new text in Section 3.1 looks good. I'm not sure why the word "typic= ally" appears int he new text of the security considerations section though a= fter reading the new text in 3.1. Wouldn't it just be ignored since 3.1 now= says: >>=20 >> "However, in the absence of such requirements, >> all confirmation members that are not understood by implementations >> MUST be ignored." >>=20 >> Thanks, >> Kathleen >>=20 >>=20 >>>=20 >>>> Thanks! >>>>=20 >>>> -- >>>>=20 >>>> Best regards, >>>> Kathleen >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>> Thanks again, >>> -- Mike >>=20 >>=20 >>=20 >> -- >>=20 >> Best regards, >> Kathleen >=20 >=20 >=20 > --=20 >=20 > Best regards, > Kathleen From nobody Wed Nov 25 07:30:40 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A5641B2E24 for ; Wed, 25 Nov 2015 07:30:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.368 X-Spam-Level: X-Spam-Status: No, score=-1.368 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uXkcdnLufBQY for ; Wed, 25 Nov 2015 07:30:36 -0800 (PST) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001: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 EB7A81B2E20 for ; Wed, 25 Nov 2015 07:30:35 -0800 (PST) Received: by igcph11 with SMTP id ph11so95785360igc.1 for ; Wed, 25 Nov 2015 07:30:35 -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:content-type; bh=nQgMMwZ9cwM3O9DJPeBTeDbX+vpvFJh8n2JfUMjwoPo=; b=Xy4VzriTeFdz/HTP7HusBhwUP4uoL2OjgSb56pE4rACw8G497ud4Q501Ij+lanfWss Yw4xs2fEQGxe6lcCpNX6eRIK9+dPlOj73TWJ1tDV3/11hxtQSEO7A+7w7/u15VJ9bVU9 EuG49tdXlJ7Fs56uy98fqJeZoYok4aKjmsVIg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=nQgMMwZ9cwM3O9DJPeBTeDbX+vpvFJh8n2JfUMjwoPo=; b=F4s52hzNBG5Bp+1uHIULqoi72cnXKqC69N/XRRP96x/uIFJUNggOVsPjWzcm9DYgI+ BlP1pJh9SM5+OubmE+bRzY8HyTox8Lfh6p4um87I9ejpfTdyrztfbCmQWpWfZrr1wmtl 1dA8Beci5jNVPfPOVaWK0O8ncVu9AJGju9T5Gd0KZEZr+gfxoB7CsG6BDYkVVVZ6Sj5P J+bLjPWR3EO4hleVo7SKQf+k6HZmcDQEZ0HDSfjMWhj1boFjAiYCsp/v+Rh41EKlTTp5 lk3JptcQ0qaXK/N13l9OWaNIRAU5FXJ7rSUXB+vjZAd/0gnKY/PDt6DS2zgCXFpZgRt3 MOFw== X-Gm-Message-State: ALoCoQl4YHkQNgQ5DZNr0i8vdmRjXVBGvTktHMxPrBosIX5hFN2cHYGoZ8MUz8iFGnDurIpfK8F+ X-Received: by 10.50.143.10 with SMTP id sa10mr4804859igb.77.1448465435328; Wed, 25 Nov 2015 07:30:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.23.133 with HTTP; Wed, 25 Nov 2015 07:30:05 -0800 (PST) In-Reply-To: References: <20151124200512.20833.28463.idtracker@ietfa.amsl.com> From: Brian Campbell Date: Wed, 25 Nov 2015 08:30:05 -0700 Message-ID: To: Phil Hunt Content-Type: multipart/alternative; boundary=001a1135fe9abe432705255f2363 Archived-At: Cc: "" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-pop-architecture-06.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2015 15:30:38 -0000 --001a1135fe9abe432705255f2363 Content-Type: text/plain; charset=UTF-8 Looking at the diff I noticed the following new text, which seems to conflate bearer/PoP and opaqueness to the client. A client demonstrating proof-of-possession of some key is orthogonal to the client being able to parse and understand the access token itself. "In contrast to bearer tokens [RFC6750] which call for tokens that are opaque to OAuth 2.0 clients, this specification defines the requirements for proof-of-possession ("PoP") tokens that may be parsed and verified by OAuth 2.0 clients and relying parties." On Tue, Nov 24, 2015 at 1:07 PM, Phil Hunt wrote: > This draft addresses review comments from Kathleen and Erik raised since > the last draft. > > It may not include some of the discussion from yesterday/today. I will > add that as the group decides. > > Cheers, > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > On Nov 24, 2015, at 12:05 PM, internet-drafts@ietf.org wrote: > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Web Authorization Protocol Working > Group of the IETF. > > > > Title : OAuth 2.0 Proof-of-Possession (PoP) Security > Architecture > > Authors : Phil Hunt > > Justin Richer > > William Mills > > Prateek Mishra > > Hannes Tschofenig > > Filename : draft-ietf-oauth-pop-architecture-06.txt > > Pages : 23 > > Date : 2015-11-24 > > > > Abstract: > > The OAuth 2.0 bearer token specification, as defined in RFC 6750, > > allows any party in possession of a bearer token (a "bearer") to get > > access to the associated resources (without demonstrating possession > > of a cryptographic key). To prevent misuse, bearer tokens must be > > protected from disclosure in transit and at rest. > > > > Some scenarios demand additional security protection whereby a client > > needs to demonstrate possession of cryptographic keying material when > > accessing a protected resource. This document motivates the > > development of the OAuth 2.0 proof-of-possession security mechanism. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architecture/ > > > > There's also a htmlized version available at: > > https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-06 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-pop-architecture-06 > > > > > > 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 > -- [image: Ping Identity logo] Brian Campbell Distinguished Engineer Ping Identity @ bcampbell@pingidentity.com [image: phone] +1 720.317.2061 [image: twitter] @pingidentity Connect with us! [image: pingidentity.com] [image: pingidentity.com] [image: twitter logo] [image: twitter logo] [image: youtube logo] [image: LinkedIn logo] [image: Facebook logo] [image: Google+ logo] [image: slideshare logo] [image: flipboard logo] [image: rss feed icon] --001a1135fe9abe432705255f2363 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Looking at the diff I noticed the following new text, whic= h seems to conflate bearer/PoP and opaqueness to the client. A client demon= strating proof-of-possession of some key is orthogonal to the client being = able to parse and understand the access token itself.
=C2=A0
"I= n contrast to bearer tokens [RFC6750] which call for tokens that are opaque= to OAuth 2.0 clients, this specification defines the requirements for proo= f-of-possession ("PoP") tokens that may be parsed and verified by= OAuth 2.0 clients and relying parties."

On Tue, Nov 24, 2015 at 1:07 PM, Phil= Hunt <phil.hunt@oracle.com> wrote:
This draft addresses review comments from Kathleen and Erik r= aised since the last draft.

It may not include some of the discussion from yesterday/today.=C2=A0 I wil= l add that as the group decides.

Cheers,

Phil

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

> On Nov 24, 2015, at 12:05 PM, internet-drafts@ietf.org wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
> This draft is a work item of the Web Authorization Protocol Working Gr= oup of the IETF.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: OAuth 2.0 Proof-of-Possession (PoP) Security Architecture
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: = Phil Hunt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Justin Richer
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 William Mills
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Prateek Mishra
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Hannes Tschofenig
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-= ietf-oauth-pop-architecture-06.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: 23
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : 2015-11-24
>
> Abstract:
>=C2=A0 =C2=A0The OAuth 2.0 bearer token specification, as defined in RF= C 6750,
>=C2=A0 =C2=A0allows any party in possession of a bearer token (a "= bearer") to get
>=C2=A0 =C2=A0access to the associated resources (without demonstrating = possession
>=C2=A0 =C2=A0of a cryptographic key).=C2=A0 To prevent misuse, bearer t= okens must be
>=C2=A0 =C2=A0protected from disclosure in transit and at rest.
>
>=C2=A0 =C2=A0Some scenarios demand additional security protection where= by a client
>=C2=A0 =C2=A0needs to demonstrate possession of cryptographic keying ma= terial when
>=C2=A0 =C2=A0accessing a protected resource.=C2=A0 This document motiva= tes the
>=C2=A0 =C2=A0development of the OAuth 2.0 proof-of-possession security = mechanism.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org= /doc/draft-ietf-oauth-pop-architecture/
>
> There's also a htmlized version available at:
> https://tools.ietf.org/html/dra= ft-ietf-oauth-pop-architecture-06
>
> A diff from the previous version is available at:
> https://www.ietf.org/rf= cdiff?url2=3Ddraft-ietf-oauth-pop-architecture-06
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org. >
> 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



--
=09 =3D"Ping=20
Brian Campbell
Distinguished Engineer
Ping Identity
@<= /td> <= span style=3D"text-decoration:none;color:#000000;font-family:arial,helvetic= a,sans-serif;font-weight:normal;font-size:14px;padding:0 0 0 3px">bcampbell@pingiden= tity.com
3D"phone" <= span style=3D"color:#000000;font-family:arial,helvetica,sans-serif;font-wei= ght:normal;font-size:14px;padding:0 0 0 3px">+1 720.317.2061
3D"twitter" <= span style=3D"color:#000000;font-family:arial,helvetica,sans-serif;font-wei= ght:normal;font-size:14px;padding:0 0 0 3px">@pingidentity
Connect with us!
3D"pingidentity.com"
3D"pingidentity.com"
3D"twitter 3D"twitter 3D"youtube 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard 3D"rss
--001a1135fe9abe432705255f2363-- From nobody Wed Nov 25 07:44:27 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B97201B2E57 for ; Wed, 25 Nov 2015 07:44:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.774 X-Spam-Level: X-Spam-Status: No, score=-4.774 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g1BMf6C6gjWX for ; Wed, 25 Nov 2015 07:44:23 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D6571B2E37 for ; Wed, 25 Nov 2015 07:44:23 -0800 (PST) Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id tAPFiM48013335 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 25 Nov 2015 15:44:22 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0022.oracle.com (8.13.8/8.13.8) with ESMTP id tAPFiM7B002420 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 25 Nov 2015 15:44:22 GMT Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id tAPFiMrY022408; Wed, 25 Nov 2015 15:44:22 GMT Received: from [25.91.163.115] (/24.114.24.55) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 25 Nov 2015 07:44:22 -0800 Content-Type: multipart/alternative; boundary=Apple-Mail-97652FDA-C54E-4BA9-B500-A67B7D263267 Mime-Version: 1.0 (1.0) From: Phil Hunt X-Mailer: iPhone Mail (13B143) In-Reply-To: Date: Wed, 25 Nov 2015 07:44:20 -0800 Content-Transfer-Encoding: 7bit Message-Id: <16FAD3AC-CFB8-46D5-A12E-436E902EA439@oracle.com> References: <20151124200512.20833.28463.idtracker@ietfa.amsl.com> To: Brian Campbell X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Cc: "" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-pop-architecture-06.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2015 15:44:25 -0000 --Apple-Mail-97652FDA-C54E-4BA9-B500-A67B7D263267 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Except that later on we require the token be signed and the client verify th= at signed token. IOW mutual pop.=20 Phil > On Nov 25, 2015, at 07:30, Brian Campbell wro= te: >=20 > Looking at the diff I noticed the following new text, which seems to confl= ate bearer/PoP and opaqueness to the client. A client demonstrating proof-of= -possession of some key is orthogonal to the client being able to parse and u= nderstand the access token itself.=20 > =20 > "In contrast to bearer tokens [RFC6750] which call for tokens that are opa= que to OAuth 2.0 clients, this specification defines the requirements for pr= oof-of-possession ("PoP") tokens that may be parsed and verified by OAuth 2.= 0 clients and relying parties." >=20 >> On Tue, Nov 24, 2015 at 1:07 PM, Phil Hunt wrote: >> This draft addresses review comments from Kathleen and Erik raised since t= he last draft. >>=20 >> It may not include some of the discussion from yesterday/today. I will a= dd that as the group decides. >>=20 >> Cheers, >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >> > On Nov 24, 2015, at 12:05 PM, internet-drafts@ietf.org wrote: >> > >> > >> > A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. >> > This draft is a work item of the Web Authorization Protocol Working Gro= up of the IETF. >> > >> > Title : OAuth 2.0 Proof-of-Possession (PoP) Security A= rchitecture >> > Authors : Phil Hunt >> > Justin Richer >> > William Mills >> > Prateek Mishra >> > Hannes Tschofenig >> > Filename : draft-ietf-oauth-pop-architecture-06.txt >> > Pages : 23 >> > Date : 2015-11-24 >> > >> > Abstract: >> > The OAuth 2.0 bearer token specification, as defined in RFC 6750, >> > allows any party in possession of a bearer token (a "bearer") to get >> > access to the associated resources (without demonstrating possession >> > of a cryptographic key). To prevent misuse, bearer tokens must be >> > protected from disclosure in transit and at rest. >> > >> > Some scenarios demand additional security protection whereby a client= >> > needs to demonstrate possession of cryptographic keying material when= >> > accessing a protected resource. This document motivates the >> > development of the OAuth 2.0 proof-of-possession security mechanism. >> > >> > >> > The IETF datatracker status page for this draft is: >> > https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architecture/ >> > >> > There's also a htmlized version available at: >> > https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-06 >> > >> > A diff from the previous version is available at: >> > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-pop-architecture-0= 6 >> > >> > >> > Please note that it may take a couple of minutes from the time of submi= ssion >> > until the htmlized version and diff are available at tools.ietf.org. >> > >> > 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 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 >=20 > --=20 > =09 > Brian Campbell > Distinguished Engineer > Ping Identity > @ bcampbell@pingidentity.com > +1 720.317.2061 > @pingidentity > Connect with us! >=20 >=20 > =20 --Apple-Mail-97652FDA-C54E-4BA9-B500-A67B7D263267 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Except that later on we require the to= ken be signed and the client verify that signed token. IOW mutual pop. =

Phil

On Nov 25, 2015, at 07:30, Brian Campbell <bcampbell@pingidentity.com>= wrote:

Looking= at the diff I noticed the following new text, which seems to conflate beare= r/PoP and opaqueness to the client. A client demonstrating proof-of-possessi= on of some key is orthogonal to the client being able to parse and understan= d the access token itself.
 
"In contrast to bearer tokens [RFC6= 750] which call for tokens that are opaque to OAuth 2.0 clients, this specif= ication defines the requirements for proof-of-possession ("PoP") tokens that= may be parsed and verified by OAuth 2.0 clients and relying parties."

On Tue, Nov 24= , 2015 at 1:07 PM, Phil Hunt <phil.hunt@oracle.com> wrote:<= br>
This draft addresses review comments from K= athleen and Erik raised since the last draft.

It may not include some of the discussion from yesterday/today.  I will= add that as the group decides.

Cheers,

Phil

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

> On Nov 24, 2015, at 12:05 PM, internet-drafts@ietf.org wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories.
> This draft is a work item of the Web Authorization Protocol Working Gro= up of the IETF.
>
>        Title          &nbs= p;: OAuth 2.0 Proof-of-Possession (PoP) Security Architecture
>        Authors         : P= hil Hunt
>                    &n= bsp;     Justin Richer
>                    &n= bsp;     William Mills
>                    &n= bsp;     Prateek Mishra
>                    &n= bsp;     Hannes Tschofenig
>       Filename        : draft-i= etf-oauth-pop-architecture-06.txt
>       Pages           = ;: 23
>       Date           = : 2015-11-24
>
> Abstract:
>   The OAuth 2.0 bearer token specification, as defined in RFC= 6750,
>   allows any party in possession of a bearer token (a "bearer= ") to get
>   access to the associated resources (without demonstrating p= ossession
>   of a cryptographic key).  To prevent misuse, bearer to= kens must be
>   protected from disclosure in transit and at rest.
>
>   Some scenarios demand additional security protection whereb= y a client
>   needs to demonstrate possession of cryptographic keying mat= erial when
>   accessing a protected resource.  This document motivat= es the
>   development of the OAuth 2.0 proof-of-possession security m= echanism.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/d= oc/draft-ietf-oauth-pop-architecture/
>
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft= -ietf-oauth-pop-architecture-06
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcd= iff?url2=3Ddraft-ietf-oauth-pop-architecture-06
>
>
> Please note that it may take a couple of minutes from the time of submi= ssion
> until the htmlized version and diff are available at tools.ietf.org.
= >
> 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



--
= =09 3D"Ping=20
Brian Campbell
Distinguished En= gineer
Ping Identity
@ bcampbell@pingidentity.com
3D"phone" +1 720.317.2061
3D"twitter" @pingidentity
Connect with us!
3D"pingidentit=
3D"twitter= 3D"= 3D"LinkedIn 3D"Google+3D"slideshare 3D"flipboard 3D"rss
= --Apple-Mail-97652FDA-C54E-4BA9-B500-A67B7D263267-- From nobody Wed Nov 25 09:15:31 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A18DE1A6F3A for ; Wed, 25 Nov 2015 09:15:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.368 X-Spam-Level: X-Spam-Status: No, score=-1.368 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q7bYDb2IeYTi for ; Wed, 25 Nov 2015 09:15:24 -0800 (PST) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 269411A6F3B for ; Wed, 25 Nov 2015 09:15:24 -0800 (PST) Received: by ioc74 with SMTP id 74so60010786ioc.2 for ; Wed, 25 Nov 2015 09:15:23 -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:content-type; bh=F6a9PH97uA0Z/RXACTIAl3iIlJnoJ+fBzncjVQxyefI=; b=IE0xJnHhxzXgEc84fRo+enRQvNEJpimyWyZwoxgwGCqzA0SKKGXh/4lhDEwFndbeVS K4bZgn9vQ8Jti/vO82PfxrkZtpyz7Yom1kLuUtaspcqYtro7dxwohdDwVjA0Nu1HAV8/ u0pVm7j86bOs+VowbHs3VX920V02pZXYpTsjI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=F6a9PH97uA0Z/RXACTIAl3iIlJnoJ+fBzncjVQxyefI=; b=kICOCVWc9JTprAEHT1s9pGhV3lMyYXh4GMOAdzDPj3MjG7fyMir1B7uPXhjpYMg4Tw ye87UHtBur1qYorX5b+TBta/o05ycP7Xi/KN4m71igC68HyxyLDTxgRU6L5PGqsfO2Ns jBCkSLrtP4x+3rwja6y8hRVYwiQCCuH0HmhreQIPy5JbRrWM3PjigPJAIVp0TkzFPIMo gJiGGkz2FocuIBOzb0H5VyJ+zVy8CDFjMbozcedVN5N3CwdRTA2PfciDcQv+UwDDVSfj 2EOihlYIJEjLW9L3C8ft++aCPsmAFejrNUw9wY1JQyWLEVzpyL18Kht5rN54k9i+dWPw 7U+A== X-Gm-Message-State: ALoCoQmcKJW9Jb7hRQJlx98edti7YKrR7BqGEP9q0zoB5BsNQ8iY/Ts9/GYPFz86fqQAwNf73P2l X-Received: by 10.107.7.24 with SMTP id 24mr40492328ioh.48.1448471723343; Wed, 25 Nov 2015 09:15:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.23.133 with HTTP; Wed, 25 Nov 2015 09:14:53 -0800 (PST) In-Reply-To: <16FAD3AC-CFB8-46D5-A12E-436E902EA439@oracle.com> References: <20151124200512.20833.28463.idtracker@ietfa.amsl.com> <16FAD3AC-CFB8-46D5-A12E-436E902EA439@oracle.com> From: Brian Campbell Date: Wed, 25 Nov 2015 10:14:53 -0700 Message-ID: To: Phil Hunt Content-Type: multipart/alternative; boundary=001a113f8b8289b9870525609aa7 Archived-At: Cc: "" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-pop-architecture-06.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2015 17:15:26 -0000 --001a113f8b8289b9870525609aa7 Content-Type: text/plain; charset=UTF-8 Where does it say that? On Wed, Nov 25, 2015 at 8:44 AM, Phil Hunt wrote: > Except that later on we require the token be signed and the client verify > that signed token. IOW mutual pop. > > Phil > > On Nov 25, 2015, at 07:30, Brian Campbell > wrote: > > Looking at the diff I noticed the following new text, which seems to > conflate bearer/PoP and opaqueness to the client. A client demonstrating > proof-of-possession of some key is orthogonal to the client being able to > parse and understand the access token itself. > > "In contrast to bearer tokens [RFC6750] which call for tokens that are > opaque to OAuth 2.0 clients, this specification defines the requirements > for proof-of-possession ("PoP") tokens that may be parsed and verified by > OAuth 2.0 clients and relying parties." > > On Tue, Nov 24, 2015 at 1:07 PM, Phil Hunt wrote: > >> This draft addresses review comments from Kathleen and Erik raised since >> the last draft. >> >> It may not include some of the discussion from yesterday/today. I will >> add that as the group decides. >> >> Cheers, >> >> Phil >> >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >> >> > On Nov 24, 2015, at 12:05 PM, internet-drafts@ietf.org wrote: >> > >> > >> > A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> > This draft is a work item of the Web Authorization Protocol Working >> Group of the IETF. >> > >> > Title : OAuth 2.0 Proof-of-Possession (PoP) Security >> Architecture >> > Authors : Phil Hunt >> > Justin Richer >> > William Mills >> > Prateek Mishra >> > Hannes Tschofenig >> > Filename : draft-ietf-oauth-pop-architecture-06.txt >> > Pages : 23 >> > Date : 2015-11-24 >> > >> > Abstract: >> > The OAuth 2.0 bearer token specification, as defined in RFC 6750, >> > allows any party in possession of a bearer token (a "bearer") to get >> > access to the associated resources (without demonstrating possession >> > of a cryptographic key). To prevent misuse, bearer tokens must be >> > protected from disclosure in transit and at rest. >> > >> > Some scenarios demand additional security protection whereby a client >> > needs to demonstrate possession of cryptographic keying material when >> > accessing a protected resource. This document motivates the >> > development of the OAuth 2.0 proof-of-possession security mechanism. >> > >> > >> > The IETF datatracker status page for this draft is: >> > https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architecture/ >> > >> > There's also a htmlized version available at: >> > https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-06 >> > >> > A diff from the previous version is available at: >> > https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-pop-architecture-06 >> > >> > >> > 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 >> > > > > -- > [image: Ping Identity logo] > Brian Campbell > Distinguished Engineer > Ping Identity > @ bcampbell@pingidentity.com [image: phone] +1 720.317.2061 [image: > twitter] @pingidentity Connect with us! > [image: pingidentity.com] > > [image: > pingidentity.com] > > [image: twitter logo] > [image: > twitter logo] [image: youtube logo] > [image: LinkedIn logo] > [image: Facebook logo] > [image: Google+ logo] > [image: slideshare > logo] [image: flipboard logo] > [image: rss feed icon] > > > -- [image: Ping Identity logo] Brian Campbell Distinguished Engineer Ping Identity @ bcampbell@pingidentity.com [image: phone] +1 720.317.2061 [image: twitter] @pingidentity Connect with us! [image: pingidentity.com] [image: pingidentity.com] [image: twitter logo] [image: twitter logo] [image: youtube logo] [image: LinkedIn logo] [image: Facebook logo] [image: Google+ logo] [image: slideshare logo] [image: flipboard logo] [image: rss feed icon] --001a113f8b8289b9870525609aa7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Where does it say that?



On Wed, Nov 25, 2015 at 8:44 AM, = Phil Hunt <phil.hunt@oracle.com> wrote:
Except that later on we require the= token be signed and the client verify that signed token. IOW mutual pop.= =C2=A0

Phil

On Nov 25, 2015, at 07:30, Brian = Campbell <bcampbell@pingidentity.com> wrote:

Looking at the diff I noticed the following= new text, which seems to conflate bearer/PoP and opaqueness to the client.= A client demonstrating proof-of-possession of some key is orthogonal to th= e client being able to parse and understand the access token itself.
= =C2=A0
"In contrast to bearer tokens [RFC6750] which call for token= s that are opaque to OAuth 2.0 clients, this specification defines the requ= irements for proof-of-possession ("PoP") tokens that may be parse= d and verified by OAuth 2.0 clients and relying parties."

On Tue, Nov 24, 2015= at 1:07 PM, Phil Hunt <phil.hunt@oracle.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">This draft addresses review comments from Kat= hleen and Erik raised since the last draft.

It may not include some of the discussion from yesterday/today.=C2=A0 I wil= l add that as the group decides.

Cheers,

Phil

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

> On Nov 24, 2015, at 12:05 PM, internet-drafts@ietf.org wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
> This draft is a work item of the Web Authorization Protocol Working Gr= oup of the IETF.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: OAuth 2.0 Proof-of-Possession (PoP) Security Architecture
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: = Phil Hunt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Justin Richer
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 William Mills
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Prateek Mishra
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Hannes Tschofenig
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-= ietf-oauth-pop-architecture-06.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: 23
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : 2015-11-24
>
> Abstract:
>=C2=A0 =C2=A0The OAuth 2.0 bearer token specification, as defined in RF= C 6750,
>=C2=A0 =C2=A0allows any party in possession of a bearer token (a "= bearer") to get
>=C2=A0 =C2=A0access to the associated resources (without demonstrating = possession
>=C2=A0 =C2=A0of a cryptographic key).=C2=A0 To prevent misuse, bearer t= okens must be
>=C2=A0 =C2=A0protected from disclosure in transit and at rest.
>
>=C2=A0 =C2=A0Some scenarios demand additional security protection where= by a client
>=C2=A0 =C2=A0needs to demonstrate possession of cryptographic keying ma= terial when
>=C2=A0 =C2=A0accessing a protected resource.=C2=A0 This document motiva= tes the
>=C2=A0 =C2=A0development of the OAuth 2.0 proof-of-possession security = mechanism.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org= /doc/draft-ietf-oauth-pop-architecture/
>
> There's also a htmlized version available at:
> https://tools.ietf.org/html/dra= ft-ietf-oauth-pop-architecture-06
>
> A diff from the previous version is available at:
> https://www.ietf.org/rf= cdiff?url2=3Ddraft-ietf-oauth-pop-architecture-06
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org. >
> 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



--
=09 3D"Ping=20
Brian Campbell
Distinguished Engineer
Ping Identity
@<= /td> <= span style=3D"text-decoration:none;color:#000000;font-family:arial,helvetic= a,sans-serif;font-weight:normal;font-size:14px;padding:0 0 0 3px">bcampbell@pingiden= tity.com
3D"phone" <= span style=3D"color:#000000;font-family:arial,helvetica,sans-serif;font-wei= ght:normal;font-size:14px;padding:0 0 0 3px">+1 720.317.2061
3D"twitter" <= span style=3D"color:#000000;font-family:arial,helvetica,sans-serif;font-wei= ght:normal;font-size:14px;padding:0 0 0 3px">@pingidentity
Connect with us!
3D"pingidentity.com"
3D"pingidentity.com" 3D"twitter 3D"twitter 3D"youtube 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard 3D"rss
Is a data type mapping form JWT to CBOR sufficie= nt then?


On Monday, November 16, 2015 11:26 PM, Hannes= Tschofenig <Hannes.Tschofenig@arm.com> wrote:

Hi = William,
=20
&n= bsp;
=20
You= are indeed correct that the current document contains a list of one-by-one= copies of claims from the JWT. The only difference is the data type. Proba= bly it would have been better to just reference the semantic from the JWT spec= and then state the new data type.
=20
&n= bsp;
=20
I f= ully understand the concern of defining CWT claims that have the same name = as JWT claims but then different semantic. This would be terribly confusing= .
=20
&n= bsp;
=20
Cia= o
=20
Han= nes
=20
&n= bsp;
=20
From: William Denniss [mailto:wdenniss@google.com]
Sent: 16 November 2015 22:32
To: Hannes Tschofenig
Cc: Erik Wahlstr=C3=B6m neXus; Carsten Bormann; Mike Jones; <oaut= h@ietf.org>
Subject: Re: [COSE] A draft on CBOR Web Tokens (CWT)
=20
 
=20
You raise some good points, and perha= ps that is relevant to future claims. The spec as drafted, is a one-for-one= copy of the standard JWT claims, which is why I raised this point.
= =20
 
=20
Is the goal a CBOR representation of = a JWT? If so, can it be defined in terms of a JWT?  Would the CNF clai= m then inherit that representation (treating the JWE and JWK as their CBOR = equivalents)?
=20
 
=20
Perhaps if you go the separate regist= ry route, those claims that *are* defined the same should at least normativ= ely reference JWT?  I want to avoid the whole "on behalf of" / "act as= " fiasco where things can get re-defined, and muddled.
=20
 
=20
On Mon, Nov 16, 2015 at 7:09 AM, Hann= es Tschofenig <Hannes.Tschofenig@arm.com> wrote:
=20
Hi William,
=20
 
=20
I have been trying to do a document update to see how well a combin= ed registry works and I have been wondering whether it is really worth the effort.
=20
To make a good judgment I looked at the CNF claim defined in draft-= ietf-oauth-proof-of-possession. The CNF claim may contain sub-elements, such as a JWE or a JWK.=20
 
=20
If we translate the same mechanisms to the CWT (which makes sense) = then we need to point to the respective COSE structures instead. Those do not only use a different encoding but al= so the functionality does not match the JOSE structures 100%. So, there are= potentially differences. I am also not sure whether we really want to tran= slate the full functionality of all the claims from JWT over to the CWT equivalent. It basically puts the = burden on someone defining new claims (either in JWT or in CWT) to create t= he corresponding structures in a format they may not necessarily be familia= r with or even care about. I have seen that happening in the RADIUS world protocol designers had to also def= ine the equivalent structures for use with Diameter and, guess what, most o= f the definitions were wrong (since the authors did not care about Diameter= when working on RADIUS).
=20
 
=20
Ciao
Hannes
=20
 
=20
 
=20
From: William Denniss [mailto:wdenn= iss@google.com]
Sent: 12 November 2015 19:19
To: Erik Wahlstr=C3=B6m neXus
Cc: Carsten Bormann; Hannes Tschofenig; Mike Jones; cose@ietf.org; <oauth@iet= f.org>; ace@ietf.org
Subject: Re: [COSE] A draft on CBOR Web Tokens (CWT)
=20
 
=20
Regarding the draft itself= , a few comments:
=20
 
=20
1. 
=20
Can we unify the claim reg= istry with JWT? I'm worried about having the same claims defined twice in C= WT and JWT with possibly conflicting meanings (and needless confusion even = when they do match). 
=20
 
=20
Comparing https://tools.ie= tf.org/html/draft-wahlstroem-oauth-cbor-web-token-00#section-3.1.2 and https://tools.ietf.org/html/= rfc7519#section-4.1.2 which are nearly identical, I just don't see the = value in re-defining it.
=20
 
=20
We may add new standard cl= aims to JWT in the future (I proposed one in Yokohama on the id-= event list), it would be good if this didn't need a separate entry in C= WT too, but could just apply directly (separately, I think you should consi= der this claim, as it helps prevent tokens from being re-used in the wrong con= text).
=20
 
=20
2.
=20
Is Section 4 "Summary of C= BOR major types used by defined claims" normative (https://tools.ietf.org/html/draft= -wahlstroem-oauth-cbor-web-token-00#section-4)? What is the intention of this section? I feel like it could probably be fl= eshed out a bit.
=20
 
=20
3. 
=20
Add a xref to draft COSE s= pec in section 6
=20
Add xref to RFC7519
= =20
 
=20
On Thu, Nov 12, 2015 at 12= :01 PM, Erik Wahlstr=C3=B6m neXus <erik.wahlstrom@nexusgroup.com> w= rote:
=20
Hi Carsten,

Thanks, and I agree. I=E2=80=99ve heard arguments for all three work groups= .

Borrowed some of your words to define the content of the draft :)
It=E2=80=99s it essentially a JWT, phrased in and profiled for CBOR to addr= ess ACE needs, where OAuth needs COSE functionality, for object security.
I=E2=80=99m open for letting the AD=E2=80=99s move it around, but having it= right next to JWT seems right to me. Also open for the ACE WG. Feel it has= less place in COSE for the same reasons JWT is not in the JOSE WG.

/ Erik
=20


> On 12 Nov 2015, at 20:45, Carsten Bormann <cabo@tzi.org> wrote:
>
> Hi Erik,
>
> having this draft is a good thing.
>
> One thing I'm still wondering is what WG is the best place to progress=
> this.  We probably don't need to spend too much time on this beca= use,
> regardless of the WG chosen, the people in another WG can look at it.<= br clear=3D"none"> > Still, getting this right might provide some efficiencies.
>
> What is the technical content of this draft?  Is it a new token t= hat
> OAuth needs specifically for the new COSE-based applications of OAuth?=
> Is it a new token that is specifically there for addressing ACE needs?=
> Or is it essentially the same substance as JWT, but phrased in and
> profiled for CBOR?
>
> Depending on the answer, CWT should be done in OAuth, ACE, or COSE. > (I'd rather hear the answer from the authors than venture a guess myse= lf.)
>
> Gr=C3=BC=C3=9Fe, Carsten
>
>
>
> Erik Wahlstr=C3=B6m neXus wrote:
>> Hi,
>>
>> In the ACE WG a straw man proposal of a CBOR Web Token (CWT) was d= efined
>> in the draft "Authorization for the Internet of Things using OAuth= 2.0=E2=80=9D
>> [1]. We just broke out the CBOR Web Token into a separate draft an= d the
>> new draft is submitted to the OAUTH WG. It can be found here:
>>
>> https://datatracker.ietf.org/doc/draft-wahlstroem-oauth-cbor-web-token/=
>>
>> Abstract:
>> "CBOR Web Token (CWT) is a compact means of representing claims to= be
>> transferred between two parties.  CWT is a profile of the JSO= N Web Token
>> (JWT) that is optimized for constrained devices. The claims in a C= WT are
>> encoded in the Concise Binary Object Representation (CBOR) and CBO= R
>> Object Signing and Encryption (COSE) is used for added application= layer
>> security protection.  A claim is a piece of information asser= ted about a
>> subject and is represented as a name/value pair consisting of a cl= aim
>> name and a claim value."
>>
>> / Erik
>>
>>
>> [1] https://tools.ietf.org/html/draft-seitz-ace-oauth-authz-00
>>
>>
>> _______________________________________________
>> COSE mailing list
>> COSE@ietf.org
>> https://www.ietf.org/mailman/listinf= o/cose

_______________________________________________
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose
=20
 
=20
 
=20
-- IMPORTANT NOTICE: The contents of this email and any attachments are con= fidential and may also be privileged. If you are not the intended recipient= , please notify the sender immediately and do not disclose the contents to = any other person, use it for any purpose, or store or copy the information in any medium. Thank you.=
=20
 
=20

------=_Part_6425772_1609887347.1447782730062-- From nobody Tue Nov 17 17:06:42 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 047741B36A3 for ; Tue, 17 Nov 2015 17:06:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.786 X-Spam-Level: X-Spam-Status: No, score=-4.786 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vWEnvpIszv8w for ; Tue, 17 Nov 2015 17:06:39 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE4CB1B36A7 for ; Tue, 17 Nov 2015 17:06:23 -0800 (PST) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id tAI16HYA030316 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 18 Nov 2015 01:06:18 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id tAI16HHZ032132 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 18 Nov 2015 01:06:17 GMT Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id tAI16Hr4031162; Wed, 18 Nov 2015 01:06:17 GMT Received: from [10.0.1.3] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 17 Nov 2015 17:06:17 -0800 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Phil Hunt X-Mailer: iPhone Mail (13B143) In-Reply-To: Date: Tue, 17 Nov 2015 17:06:10 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Kathleen Moriarty X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-pop-architecture X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2015 01:06:41 -0000 Just wanted to let everyone know I intend to respond shortly.=20 I just got back from some holidays and just clearing my backlog now.=20 Cheers Phil > On Nov 16, 2015, at 12:37, Kathleen Moriarty wrote: >=20 > Hello, >=20 > I reviewed draft-ietf-oauth-pop-architecture and have a few questions. >=20 > 1. Section 6, Threat Mitigation: >=20 > Last sentence of first paragraph, "To > simplify the subsequent description we assume that the token itself > is digitally signed by the authorization server and therefore cannot > be modified." >=20 > Since bearer tokens are not signed by default, is this proposing a > change? If so, where will that change occur? To state that "it is > assumed" without it being required anywhere is not a good assumption. > I'd still see this as a risk or security consideration. When OAuth is > re-used by other protocols, I am seeing that re-use leave off basic > protections that should be assumed like TLS, let alone digital > signatures. If this is required in the defined architecture (Section > 7 - it does show this, but there are no MUSTs that I can find), just > state that and refer to the requirement. >=20 > 2. Section 6, Threat Mitigation >=20 > Third paragraph, "As an example, TLS with a ciphersuite > that offers confidentiality protection has to be applied (which is > currently true for all ciphersuites, except for one). >=20 > Please list a reference so the reader knows which ciphersuites are > acceptable from the recommended ones in RFC7525. I don't recall there > being any MTI ciphersuites for OAuth (I'm pretty sure there aren't and > that we've discussed that already with previous drafts, so this should > be spelled out more). >=20 > 3. (Nit) Section 6.2, add a comma to improve readability > From: "Instead of providing confidentiality protection the authorization > server could also put the identifier of the client into the protected > token with the following semantic:" > To: "Instead of providing confidentiality protection, the authorization > server could also put the identifier of the client into the protected > token with the following semantic:" >=20 > Thank you all for your work on this draft! > --=20 >=20 > Best regards, > Kathleen >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Wed Nov 18 00:02:01 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E47791B29FF for ; Wed, 18 Nov 2015 00:02:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ef6xBP7WuhcQ for ; Wed, 18 Nov 2015 00:01:58 -0800 (PST) Received: from eu-smtp-delivery-143.mimecast.com (eu-smtp-delivery-143.mimecast.com [146.101.78.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E4B41B29FA for ; Wed, 18 Nov 2015 00:01:57 -0800 (PST) Received: from emea-cam-gw2.Emea.Arm.com (fw-tnat.cambridge.arm.com [217.140.96.140]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-17-uGt2WqGjSXWii1X6faU8Lg-1; Wed, 18 Nov 2015 08:01:54 +0000 Received: from GB-CAM-EXCAS1.Emea.Arm.com (10.1.105.66) by emea-cam-gw2.Emea.Arm.com (10.1.105.151) with Microsoft SMTP Server (TLS) id 8.3.298.1; Wed, 18 Nov 2015 08:01:54 +0000 Received: from emea01-am1-obe.outbound.protection.outlook.com (10.1.2.79) by nebula.arm.com (10.1.105.66) with Microsoft SMTP Server (TLS) id 14.3.266.1; Wed, 18 Nov 2015 08:01:54 +0000 Received: from HE1PR08MB0732.eurprd08.prod.outlook.com (10.163.179.30) by HE1PR08MB0732.eurprd08.prod.outlook.com (10.163.179.30) with Microsoft SMTP Server (TLS) id 15.1.325.17; Wed, 18 Nov 2015 08:01:53 +0000 Received: from HE1PR08MB0732.eurprd08.prod.outlook.com ([10.163.179.30]) by HE1PR08MB0732.eurprd08.prod.outlook.com ([10.163.179.30]) with mapi id 15.01.0325.003; Wed, 18 Nov 2015 08:01:52 +0000 From: Hannes Tschofenig To: Bill Mills , William Denniss Thread-Topic: [OAUTH-WG] [COSE] A draft on CBOR Web Tokens (CWT) Thread-Index: AQHRHX3DyXQEi0Hb60mPSXqbnVxSe56YykQAgAAEkACAAHpjAIAFe1lwgABs4oCAAKM5oIAAsbYAgADtIFA= Date: Wed, 18 Nov 2015 08:01:52 +0000 Message-ID: References: <1371112237.6425773.1447782730081.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <1371112237.6425773.1447782730081.JavaMail.yahoo@mail.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [80.92.121.34] x-microsoft-exchange-diagnostics: 1; HE1PR08MB0732; 5:rROJ3tpy3PhN9eb9RB5ysKTpxlZ82M7LswIpfkcfIbya3nUw/72kcM+luqic6dQomFkFEEXvE5LAjX6RAOj/SO6KQVPKTeZiPG1pODZD9jPLHf+TPpuhd0vlj4lLlaF+bAR2z8MXdhtEkuqQ0TjiCA==; 24:k2o3w/LZK1xKts4FWS1uqiglfkYA06+5bDdZTOVdaHMVgjld5/VxKoo1uvEXG5dBQLzc6DxhSFO6hnBOs/EqZbGoiuZwt7mXaJgCVjrK0fM=; 20:5ZVlDTZuEAtbNpf+sIgnlQ2r1wuhLKdC7EpMqN41RRUYh5n3k/fHI2NnmlI77wiritlmQ0t0YV5k/7g8YHaXqNBprZLMe5wsVOW7SDK2zaDpw5cl1/MGNdHnCok6qla7ACz0hd7WhRB+6xkp4OZ0ZKJyDuuNDdn+z03eCdVnQeE= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR08MB0732; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001)(10201501046); SRVR:HE1PR08MB0732; BCL:0; PCL:0; RULEID:; SRVR:HE1PR08MB0732; x-forefront-prvs: 0764C4A8CD x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(189002)(199003)(15975445007)(101416001)(2950100001)(106356001)(19300405004)(105586002)(5007970100001)(66066001)(5001770100001)(97736004)(19625215002)(50986999)(81156007)(106116001)(54356999)(76176999)(19580395003)(102836002)(92566002)(76576001)(2900100001)(189998001)(87936001)(77096005)(5004730100002)(5003600100002)(5001960100002)(16236675004)(122556002)(40100003)(86362001)(74316001)(10400500002)(586003)(5002640100001)(33656002)(5008740100001)(2521001)(558084003); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR08MB0732; H:HE1PR08MB0732.eurprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Nov 2015 08:01:52.6083 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR08MB0732 X-OriginatorOrg: arm.com X-MC-Unique: uGt2WqGjSXWii1X6faU8Lg-1 Content-Type: multipart/alternative; boundary="_000_HE1PR08MB0732E32EE7A71845847536AFFA1C0HE1PR08MB0732eurp_" Archived-At: Cc: "" Subject: Re: [OAUTH-WG] [COSE] A draft on CBOR Web Tokens (CWT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2015 08:02:01 -0000 --_000_HE1PR08MB0732E32EE7A71845847536AFFA1C0HE1PR08MB0732eurp_ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 SGkgQmlsbCwNCg0KDQrDmCAgSXMgYSBkYXRhIHR5cGUgbWFwcGluZyBmb3JtIEpXVCB0byBDQk9S IHN1ZmZpY2llbnQgdGhlbj8NCg0KSSBpbml0aWFsbHkgdGhvdWdodCBidXQgdGhlbiBJIHJhbiBp bnRvIHRoZSBDT1NFIHdvcmssIHdoaWNoIGlzIG5vdCBhIG1hcHBpbmcgb2YgdGhlIEpPU0Ugc3Bl YyB0byBDQk9SLiBJdCBpcyBhIHJlLXdyaXRlLg0KQ2lhbw0KSGFubmVzDQoNCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCg0KLS0gSU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRl bnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIGFu ZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVj aXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBk aXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBhbnkg cHVycG9zZSwgb3Igc3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4g VGhhbmsgeW91Lg0K --_000_HE1PR08MB0732E32EE7A71845847536AFFA1C0HE1PR08MB0732eurp_ Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAg MCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFu b3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpU YWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5p dGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFy Z2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglm b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29I eXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93 ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0Fj ZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29u IFRleHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpwLk1z b0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBo DQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBjbTsNCgltYXJnaW4tcmln aHQ6MGNtOw0KCW1hcmdpbi1ib3R0b206MGNtOw0KCW1hcmdpbi1sZWZ0OjM2LjBwdDsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnAueWl2NTM5MDg0NjczN21zb2FjZXRhdGUsIGxpLnlp djUzOTA4NDY3Mzdtc29hY2V0YXRlLCBkaXYueWl2NTM5MDg0NjczN21zb2FjZXRhdGUNCgl7bXNv LXN0eWxlLW5hbWU6eWl2NTM5MDg0NjczN21zb2FjZXRhdGU7DQoJbXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsN CgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnAueWl2NTM5MDg0NjczN21zb25vcm1hbCwgbGkueWl2 NTM5MDg0NjczN21zb25vcm1hbCwgZGl2LnlpdjUzOTA4NDY3Mzdtc29ub3JtYWwNCgl7bXNvLXN0 eWxlLW5hbWU6eWl2NTM5MDg0NjczN21zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1h cmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi55aXY1MzkwODQ2NzM3bXNvaHlwZXJsaW5rDQoJe21z by1zdHlsZS1uYW1lOnlpdjUzOTA4NDY3Mzdtc29oeXBlcmxpbms7fQ0Kc3Bhbi55aXY1MzkwODQ2 NzM3bXNvaHlwZXJsaW5rZm9sbG93ZWQNCgl7bXNvLXN0eWxlLW5hbWU6eWl2NTM5MDg0NjczN21z b2h5cGVybGlua2ZvbGxvd2VkO30NCnNwYW4ueWl2NTM5MDg0NjczN2VtYWlsc3R5bGUxNw0KCXtt c28tc3R5bGUtbmFtZTp5aXY1MzkwODQ2NzM3ZW1haWxzdHlsZTE3O30NCnAueWl2NTM5MDg0Njcz N21zb25vcm1hbDEsIGxpLnlpdjUzOTA4NDY3Mzdtc29ub3JtYWwxLCBkaXYueWl2NTM5MDg0Njcz N21zb25vcm1hbDENCgl7bXNvLXN0eWxlLW5hbWU6eWl2NTM5MDg0NjczN21zb25vcm1hbDE7DQoJ bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsN Cglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4ueWl2NTM5MDg0 NjczN21zb2h5cGVybGluazENCgl7bXNvLXN0eWxlLW5hbWU6eWl2NTM5MDg0NjczN21zb2h5cGVy bGluazE7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4u eWl2NTM5MDg0NjczN21zb2h5cGVybGlua2ZvbGxvd2VkMQ0KCXttc28tc3R5bGUtbmFtZTp5aXY1 MzkwODQ2NzM3bXNvaHlwZXJsaW5rZm9sbG93ZWQxOw0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lO30NCnAueWl2NTM5MDg0NjczN21zb2FjZXRhdGUxLCBsaS55aXY1 MzkwODQ2NzM3bXNvYWNldGF0ZTEsIGRpdi55aXY1MzkwODQ2NzM3bXNvYWNldGF0ZTENCgl7bXNv LXN0eWxlLW5hbWU6eWl2NTM5MDg0NjczN21zb2FjZXRhdGUxOw0KCW1hcmdpbjowY207DQoJbWFy Z2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4ueWl2NTM5MDg0NjczN2VtYWlsc3R5bGUxNzEN Cgl7bXNvLXN0eWxlLW5hbWU6eWl2NTM5MDg0NjczN2VtYWlsc3R5bGUxNzE7DQoJY29sb3I6IzFG NDk3RDt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBU ZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFs bG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5F bWFpbFN0eWxlMjkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZh dWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4w cHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1p ZDoyMTM4NTIyNTY5Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRl LWlkczotMTEzMTk5NzE0IC0xMzMxODA0MDA0IDEzNDgwNzU1NSAxMzQ4MDc1NTcgMTM0ODA3NTUz IDEzNDgwNzU1NSAxMzQ4MDc1NTcgMTM0ODA3NTUzIDEzNDgwNzU1NSAxMzQ4MDc1NTc7fQ0KQGxp c3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvg5g7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2lu Z2RpbmdzOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iOw0KCW1z by1iaWRpLWZvbnQtZmFtaWx5OkhlbHZldGljYTsNCgljb2xvcjojMUY0OTdEO30NCkBsaXN0IGww OmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBO ZXciO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQt ZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4 LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2 ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv gqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30N CkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5 OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRv bTowY207fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEw MjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAv Pg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFu Zz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNl Y3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5IaSBCaWxsLA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTGlzdFBh cmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxm bzE7YmFja2dyb3VuZDp3aGl0ZSI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5ncztjb2xvcjojMUY0OTdEIj48c3Bh biBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7DmDxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtl bmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+SXMgYSBkYXRh IHR5cGUgbWFwcGluZyBmb3JtIEpXVCB0byBDQk9SIHN1ZmZpY2llbnQgdGhlbj88bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0O2JhY2tncm91bmQ6d2hpdGUiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0 O2JhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5JIGluaXRpYWxseSB0aG91Z2h0IGJ1dCB0aGVuIEkgcmFuIGludG8gdGhlIENPU0Ugd29y aywgd2hpY2ggaXMgbm90IGEgbWFwcGluZyBvZiB0aGUgSk9TRSBzcGVjIHRvIENCT1IuIEl0IGlz DQogYSByZS13cml0ZS4gPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0O2JhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5DaWFvPGJyPg0KSGFubmVzPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0 b206MTIuMHB0O2JhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8YnI+DQo8aHI+DQo8Zm9udCBmYWNl PSJBcmlhbCIgY29sb3I9IkJsYWNrIiBzaXplPSIyIj48YnI+DQotLSBJTVBPUlRBTlQgTk9USUNF OiBUaGUgY29udGVudHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25m aWRlbnRpYWwgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBp bnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBh bmQgZG8gbm90IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLCB1c2Ug aXQgZm9yIGFueQ0KIHB1cnBvc2UsIG9yIHN0b3JlIG9yIGNvcHkgdGhlIGluZm9ybWF0aW9uIGlu IGFueSBtZWRpdW0uIFRoYW5rIHlvdS48YnI+DQo8L2ZvbnQ+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_HE1PR08MB0732E32EE7A71845847536AFFA1C0HE1PR08MB0732eurp_-- From nobody Wed Nov 18 09:30:16 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A7E21A8AF0 for ; Wed, 18 Nov 2015 09:30:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.785 X-Spam-Level: X-Spam-Status: No, score=-4.785 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z0xuc5driptd for ; Wed, 18 Nov 2015 09:30:13 -0800 (PST) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1E2D1A8AEE for ; Wed, 18 Nov 2015 09:30:12 -0800 (PST) X-AuditID: 1209190c-f79c96d00000038e-13-564cb5a3f77a Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id EE.88.00910.3A5BC465; Wed, 18 Nov 2015 12:30:11 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id tAIHUA3L029339; Wed, 18 Nov 2015 12:30:10 -0500 Received: from [192.168.0.104] (ip-53-040.atvci.net [209.240.53.40]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id tAIHU3lC015411 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 18 Nov 2015 12:30:08 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_39029A78-54F4-4CC5-8DC2-EABBE7493E2B" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Justin Richer In-Reply-To: Date: Wed, 18 Nov 2015 09:59:20 -0600 Message-Id: References: <1371112237.6425773.1447782730081.JavaMail.yahoo@mail.yahoo.com> To: Hannes Tschofenig X-Mailer: Apple Mail (2.2104) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprPKsWRmVeSWpSXmKPExsUixG6nrrt4q0+YwcU9GhY3Z5xisjj59hWb xaY5zewW37quMzuweKyZt4bRY8GmUo8lS34yecyadZgpgCWKyyYlNSezLLVI3y6BK+PRJtWC WeEVs6auZG5g/OPTxcjJISFgItGyqIMZwhaTuHBvPVsXIxeHkMBiJolLh3eyQDgbGSXa2++w QzgHmSSWHf3K2sXIwcEskCDxYzNYN6+AnsSrW5fBwsIC9hKXbiWAhNkEVCXmr7zFBBLmFIiV uDYtGcRkAQqfu1YMUsEsUCNx+OIyRoghVhKdq/8wQSx6xyjx7usasOkiAoYSe5sPsULcKSux +/cjpgmMArMQbpiF5IZZYGO1JZYtfM0MYWtK7O9ezoIpriHR+W0i6wJGtlWMsim5Vbq5iZk5 xanJusXJiXl5qUW6hnq5mSV6qSmlmxhB8cApybOD8c1BpUOMAhyMSjy8CYu9w4RYE8uKK3MP MUpyMCmJ8rKt8QkT4kvKT6nMSCzOiC8qzUktPsQowcGsJMKrXQ2U401JrKxKLcqHSUlzsCiJ 8276wRciJJCeWJKanZpakFoEk5Xh4FCS4BXbAtQoWJSanlqRlplTgpBm4uAEGc4DNHzqZpDh xQWJucWZ6RD5U4yKUuK870ASAiCJjNI8uF5Qurr4wVTjFaM40CvCvALA5CXEA0x1cN2vgAYz AQ0+0eAJMrgkESEl1cBYun6f444PucYZjj3tgfvZncPedOyP2Rb86MrK+WmPbz/vz8wTvOd9 o1F2r0RUNKM/V66SeJzIjVs3gxm9Ht3ytxR/JPXGY+IVbZ/+ic82RJeu/H5Pa43+uoPPI++W K80OjzwfY/35la/xv5An567PXjhj0mrJzdb5h/le9F7PmKHwMyfX+fp2JZbijERDLeai4kQA oF33sTIDAAA= Archived-At: Cc: "" Subject: Re: [OAUTH-WG] [COSE] A draft on CBOR Web Tokens (CWT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2015 17:30:15 -0000 --Apple-Mail=_39029A78-54F4-4CC5-8DC2-EABBE7493E2B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 By the way, folks:=20 If people disagree with COSE being a rewrite of JOSE, they should speak = up in the COSE working group and say so.=20 =E2=80=94 Justin > On Nov 18, 2015, at 2:01 AM, Hannes Tschofenig = > wrote: >=20 > Hi Bill, > =20 > =C3=98 Is a data type mapping form JWT to CBOR sufficient then? > =20 >=20 > I initially thought but then I ran into the COSE work, which is not a = mapping of the JOSE spec to CBOR. It is a re-write. >=20 > Ciao > Hannes >=20 > =20 >=20 >=20 >=20 > -- IMPORTANT NOTICE: The contents of this email and any attachments = are confidential and may also be privileged. If you are not the intended = recipient, please notify the sender immediately and do not disclose the = contents to any other person, use it for any purpose, or store or copy = the information in any medium. Thank you. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_39029A78-54F4-4CC5-8DC2-EABBE7493E2B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 By the way, folks: 

If people disagree with COSE being a = rewrite of JOSE, they should speak up in the COSE working group and say = so. 

 =E2=80= =94 Justin

On Nov 18, 2015, at 2:01 AM, = Hannes Tschofenig <Hannes.Tschofenig@arm.com> wrote:

Hi Bill,

 

=C3=98  Is a data type mapping = form JWT to CBOR sufficient then?

 

I initially thought but then I ran into = the COSE work, which is not a mapping of the JOSE spec to CBOR. It is a re-write.

Ciao
Hannes

 



-- IMPORTANT NOTICE: The contents of this email and any attachments are = confidential and may also be privileged. If you are not the intended = recipient, please notify the sender immediately and do not disclose the = contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
_______________________________________________
OAuth = mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

= --Apple-Mail=_39029A78-54F4-4CC5-8DC2-EABBE7493E2B-- From nobody Wed Nov 18 13:03:46 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8C351B2EF1 for ; Wed, 18 Nov 2015 13:03:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.786 X-Spam-Level: X-Spam-Status: No, score=-4.786 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YnZwUa3b4xYF for ; Wed, 18 Nov 2015 13:03:37 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61CA71B2EF0 for ; Wed, 18 Nov 2015 13:03:37 -0800 (PST) Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id tAIL3ZrL008804 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 18 Nov 2015 21:03:36 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id tAIL3ZMP026421 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 18 Nov 2015 21:03:35 GMT Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id tAIL3YoC001794; Wed, 18 Nov 2015 21:03:34 GMT Received: from [10.0.1.22] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 18 Nov 2015 13:03:34 -0800 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Phil Hunt In-Reply-To: Date: Wed, 18 Nov 2015 13:03:33 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <7028747C-88DD-43BD-B0A4-FDEB7662A208@oracle.com> References: To: Kathleen Moriarty X-Mailer: Apple Mail (2.3096.5) X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-pop-architecture X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2015 21:03:41 -0000 Comments inline. Phil @independentid www.independentid.com phil.hunt@oracle.com > On Nov 16, 2015, at 12:37 PM, Kathleen Moriarty = wrote: >=20 > Hello, >=20 > I reviewed draft-ietf-oauth-pop-architecture and have a few questions. >=20 > 1. Section 6, Threat Mitigation: >=20 > Last sentence of first paragraph, "To > simplify the subsequent description we assume that the token itself > is digitally signed by the authorization server and therefore cannot > be modified." >=20 > Since bearer tokens are not signed by default, is this proposing a > change? If so, where will that change occur? To state that "it is > assumed" without it being required anywhere is not a good assumption. > I'd still see this as a risk or security consideration. When OAuth is > re-used by other protocols, I am seeing that re-use leave off basic > protections that should be assumed like TLS, let alone digital > signatures. If this is required in the defined architecture (Section > 7 - it does show this, but there are no MUSTs that I can find), just > state that and refer to the requirement. [PH] I think the change is the point of the POP specifications. We are = talking about a new class of tokens that are specifically not Bearer = tokens thus the threat mitigation states that POP tokens are assumed to = be digitally signed. Was that not clear from the introduction? >=20 > 2. Section 6, Threat Mitigation >=20 > Third paragraph, "As an example, TLS with a ciphersuite > that offers confidentiality protection has to be applied (which is > currently true for all ciphersuites, except for one). >=20 > Please list a reference so the reader knows which ciphersuites are > acceptable from the recommended ones in RFC7525. I don't recall there > being any MTI ciphersuites for OAuth (I'm pretty sure there aren't and > that we've discussed that already with previous drafts, so this should > be spelled out more). [PH] I think this can be simplified a bit. I think this was referring to = a =E2=80=9CNULL=E2=80=9D ciphersuite which is what 7525 says should not = be done. We should also point to 7525. >=20 > 3. (Nit) Section 6.2, add a comma to improve readability > From: "Instead of providing confidentiality protection the = authorization > server could also put the identifier of the client into the = protected > token with the following semantic:" > To: "Instead of providing confidentiality protection, the = authorization > server could also put the identifier of the client into the = protected > token with the following semantic:=E2=80=9D >=20 [PH] Will add to the next draft pending your comments on the above = items. > Thank you all for your work on this draft! > --=20 >=20 > Best regards, > Kathleen >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Thu Nov 19 01:19:23 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBC4D1B3041 for ; Thu, 19 Nov 2015 01:17:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.884 X-Spam-Level: X-Spam-Status: No, score=-2.884 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.585] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x0l6G2hu-sK2 for ; Thu, 19 Nov 2015 01:17:21 -0800 (PST) Received: from smtp.nexusgroup.com (smtp.nexusgroup.com [83.241.133.120]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21EF81B303C for ; Thu, 19 Nov 2015 01:17:20 -0800 (PST) Received: from NG-EX01.ad.nexusgroup.com (10.75.28.40) by NG-EX01.ad.nexusgroup.com (10.75.28.40) with Microsoft SMTP Server (TLS) id 15.0.995.29; Thu, 19 Nov 2015 10:17:18 +0100 Received: from NG-EX01.ad.nexusgroup.com ([fe80::1d3d:b319:f020:2bab]) by NG-EX01.ad.nexusgroup.com ([fe80::1d3d:b319:f020:2bab%12]) with mapi id 15.00.0995.032; Thu, 19 Nov 2015 10:17:18 +0100 From: =?utf-8?B?RXJpayBXYWhsc3Ryw7ZtIG5lWHVz?= To: "" Thread-Topic: A review of draft-ietf-oauth-pop-architecture-05 Thread-Index: AQHRIqsWh1Kr9qJTskO0p1mDeu7WuQ== Date: Thu, 19 Nov 2015 09:17:18 +0000 Message-ID: <4197256B-0C12-46AA-B2F2-C9849F44BB3A@nexusgroup.com> Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.2104) x-originating-ip: [213.113.163.201] Content-Type: multipart/alternative; boundary="_000_4197256B0C1246AAB2F2C9849F44BB3Anexusgroupcom_" MIME-Version: 1.0 Archived-At: Subject: [OAUTH-WG] A review of draft-ietf-oauth-pop-architecture-05 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2015 09:17:25 -0000 --_000_4197256B0C1246AAB2F2C9849F44BB3Anexusgroupcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkkgaGF2ZSBiZWVuIHJldmlld2luZyBkcmFmdC1pZXRmLW9hdXRoLXBvcC1hcmNoaXRl Y3R1cmUtMDUuIEluIEFDRSBXRyB3ZSBoYXZlIGEgZHJhZnQgdGhhdCB1c2VzIFBvUCB0b2tlbnMg Zm9yIElvVCBhbmQgdGhlIGFyY2hpdGVjdHVyZXMgZGVmaW5lZCBoZXJlIHNvIG15IHJldmlldyB3 YXMgZG9uZSB3aXRoIHRoYXQgSW9UIHBlcnNwZWN0aXZlLiBJ4oCZbSBhIGJpdCBsYXRlIHdpdGgg dGhlIHJldmlldyBhbmQgc29tZSBvZiB0aGUgY29tbWVudHMgbWlnaHQgYWxyZWFkeSBiZSBtZW50 aW9uZWQgYnkgb3RoZXJzLg0KDQoNCg0K4oCU4oCU4oCU4oCU4oCU4oCUDQoNCjMuMS4gUHJldmVu dGluZyBBY2Nlc3MgVG9rZW4gUmUtVXNlIGJ5IHRoZSBSZXNvdXJjZSBTZXJ2ZXINCg0KSWYgYSBz eW1tZXRyaWMga2V5IGlzIHVzZWQgaXTigJlzIHBvc3NpYmxlIHRvIHJlLXVzZSB0aGUga2V5IGZv ciBhIHJlc291cmNlIHNlcnZlci4gVGhlIHNlY3Rpb24gdGFsa3MgYWJvdXQgdGhlIGltcG9ydGFu Y2Ugb2Ygc2NvcGVzLCBidXQgSSBmZWVsIGl0IHNob3VsZCBhbHNvIG1lbnRpb24gdGhlIGltcG9y dGFuY2UgZm9yIHRoZSByZXNvdXJjZSBzZXJ2ZXIgdG8gdmVyaWZ5IHRoZSBhdWRpZW5jZSAo4oCc YXVk4oCdKSBjbGFpbSBpbiB0aGUgdG9rZW4gdG8gZGlzYWJsZSBtaXNzdXNlLg0KDQrigJTigJTi gJTigJTigJTigJQNCg0KVGhlIGRyYWZ0IGluIEFDRSBXRyAoaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LXNlaXR6LWFjZS1vYXV0aC1hdXRoei0wMCkgcmVsaWVzIGhlYXZpbHkgb24g dGhpcyB3b3JrLiBUaGUgbWFpbiByZWFzb24gZm9yIHRoaXMgaXMgdGhlIHdheSBQb1AgdG9rZW5z IGNhbiBlc3RhYmxpc2gga2V5IG1hdGVyaWFsLCB3aXRoIHRoZSBoZWxwIG9mIHRoZSBhdXRob3Jp emF0aW9uIHNlcnZlciwgb24gYm90aCB0aGUgY2xpZW50IGFuZCByZXNvdXJjZSBzZXJ2ZXIuIFBv UCB0b2tlbnMgaXMgYWxzbyBhIHZlcnkgZ29vZCBmaXQgZm9yIGNvbnN0cmFpbmVkIElvVCBkZXZp Y2VzIHRoYXQgY2FuIGJlIG9mZmxpbmUgYW5kIGl04oCZcyBhbHNvIHBvc3NpYmxlIHRvIHVzZSBo YXJkd2FyZSBrZXkgc3RvcmFnZXMgdG8gaGFuZGxlIGFzeW1tZXRyaWMgcG9wIGtleXMuDQoNClRo ZXJlIGNvdWxkIGJlIGEgcGxhY2UgZm9yIGEgbmV3ICJVc2UgQ2FzZSIgdW5kZXIgc2VjdGlvbiAz IHRoYXQgdGFsa3MgYWJvdXQgc2NlbmFyaW9zIHdoZXJlIFBvUCBrZXlzIGFyZSBhIHJlYWxseSBn b29kIG1hdGNoIGZvciBvZmZsaW5lIElvVCBkZXZpY2VzLiBJIGNvdWxkIGhlbHAgb3V0IGlyb25p bmcgb3V0IGEgdGV4dCBmb3IgdGhhdCB3aXRoIHRoZSBoZWxwIG9mIHRoZSBkb2NzIGF1dGhvcnMg aWYgdGhhdOKAmXMgb2YgaW50ZXJlc3QuDQoNCuKAlOKAlOKAlA0KDQpzL2EgYm9ndXMgdG9rZW5z L2EgYm9ndXMgdG9rZW4NCg0K4oCU4oCUDQoNCkluIHRoZSBkb2N1bWVudCBvbmx5IHJlZmVyZW5j ZXMgYXJlIG1hZGUgdG8gSlNPTiwgSldUIGFuZCBKT1NFLiBNb3JlIGV4YWN0bHkgaW4gdGhlIGZv bGxvd2luZyB0d28gc2VjdGlvbnM6DQoNCg0KICAgQSBudW1iZXIgb2YgdGhlIHRocmVhdHMgbGlz dGVkIGluIFNlY3Rpb24gNDxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1v YXV0aC1wb3AtYXJjaGl0ZWN0dXJlLTA1I3NlY3Rpb24tND4gZGVtYW5kIHByb3RlY3Rpb24gb2Yg dGhlDQogICBhY2Nlc3MgdG9rZW4gY29udGVudCBhbmQgYSBzdGFuZGFyZGl6ZWQgc29sdXRpb24s IGluIGZvcm0gb2YgYSBKU09OLQ0KICAgYmFzZWQgZm9ybWF0LCBpcyBhdmFpbGFibGUgd2l0aCB0 aGUgSldUIFtSRkM3NTE5PGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3NTE5Pl0uDQoN Cg0KDQoNCiAgIFdpdGggdGhlIEpTT04gV2ViIFRva2VuIChKV1QpIFtSRkM3NTE5PGh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3NTE5Pl0gYSBzdGFuZGFyZGl6ZWQgZm9ybWF0IGZvcg0K ICAgYWNjZXNzIHRva2VucyBpcyBhdmFpbGFibGUuICBUaGUgbmVjZXNzYXJ5IGVsZW1lbnRzIHRv IGJpbmQgc3ltbWV0cmljDQogICBvciBhc3ltbWV0cmljIGtleXMgdG8gYSBKV1QgYXJlIGRlc2Ny aWJlZCBpbg0KICAgW0ktRC5pZXRmLW9hdXRoLXByb29mLW9mLXBvc3Nlc3Npb248aHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtcG9wLWFyY2hpdGVjdHVyZS0wNSNy ZWYtSS1ELmlldGYtb2F1dGgtcHJvb2Ytb2YtcG9zc2Vzc2lvbj5dLg0KDQoNCkNvbnN0cmFpbmVk IElvVCBkZXZpY2VzIHVzZXMgb3RoZXIgYWNjZXNzIHRva2VuIGFuZCBtZXNzYWdlcyBmb3JtYXRz IChhY2NvcmRpbmcgdG8gb3VyIGRyYWZ0KS4gSXQgZG9lcyBub3Qgb25seSB1c2Ugc2lnbmVkL2Vu Y3J5cHRlZCBKV1TigJlzIGJ1dCBhbHNvIENPU0UgcHJvdGVjdGVkIENCT1IgV2ViIFRva2Vucy4g U2VlIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtd2FobHN0cm9lbS1vYXV0aC1jYm9y LXdlYi10b2tlbi0wMC50eHQNCg0KSSB0b3RhbGx5IGFncmVlIHRoYXQgSldUIGlzIHRoZSBjb3Jy ZWN0IGV4YW1wbGVzIHRvIGhhdmUgaW4gdGhpcyBkb2N1bWVudCBkdWUgdG8gdGhlIGZhY3QgdGhh dCB0aGV5IGFyZSBSRkPigJlzLCB0aGV5IGFyZSB3ZWxsIGtub3duIGFuZCBzaG91bGQgYmUgdXNl ZCBpbiBhcyBtYW55IHBsYWNlcyBhcyBwb3NzaWJsZSwgYnV0IGl0IHdvdWxkIGJlIGdvb2QgdG8g b3BlbiB1cCBmb3Igb3RoZXIgdHlwZXMgb2YgbWVzc2FnZSBmb3JtYXRzLiBGb3IgZXhhbXBsZSBs aWtlIHRoaXM6DQoNCg0KDQogICBBIG51bWJlciBvZiB0aGUgdGhyZWF0cyBsaXN0ZWQgaW4gU2Vj dGlvbiA0PGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLXBvcC1h cmNoaXRlY3R1cmUtMDUjc2VjdGlvbi00PiBkZW1hbmQgcHJvdGVjdGlvbiBvZiB0aGUNCiAgIGFj Y2VzcyB0b2tlbiBjb250ZW50IGFuZCBhIHN0YW5kYXJkaXplZCBzb2x1dGlvbiBpbiBmb3JtIG9m LCBmb3IgZXhhbXBsZSwgYSBKU09OLQ0KICAgYmFzZWQgZm9ybWF0LCBpcyBhdmFpbGFibGUgd2l0 aCB0aGUgSldUIFtSRkM3NTE5PGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3NTE5Pl0u DQoNCg0KDQrigJTigJQNCg0KDQogRm9yIHRoYXQNCiAgIHB1cnBvc2UgdGhlIGNsaWVudCB3aWxs IGhhdmUgdG8gYXV0aGVudGljYXRlIHRoZSByZXNvdXJjZSBzZXJ2ZXINCiAgIGJlZm9yZSB0cmFu c21pdHRpbmcgdGhlIGFjY2VzcyB0b2tlbi4NCg0KDQoNCknigJltIG1pc3NpbmcgYSBkZXNjcmlw dGlvbiBhYm91dCBob3cgdGhpcyBpcyBoYW5kbGVkIGluIGFuIGVuZC10by1lbmQgc2VjdXJpdHkg c2NlbmFyaW8uDQoNCuKAlOKAlOKAlA0KDQoNCiAgICAgIFRoZSByZXNvdXJjZSBzZXJ2ZXIgcXVl cmllcyB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgZm9yIHRoZQ0KICAgICAgc3ltbWV0cmljIGtl eS4gIFRoaXMgaXMgYW4gYXBwcm9hY2ggZW52aXNpb25lZCBieSB0aGUgdG9rZW4NCiAgICAgIGlu dHJvc3BlY3Rpb24gZW5kcG9pbnQgW0ktRC5pZXRmLW9hdXRoLWludHJvc3BlY3Rpb248aHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtcG9wLWFyY2hpdGVjdHVyZS0w NSNyZWYtSS1ELmlldGYtb2F1dGgtaW50cm9zcGVjdGlvbj5dLg0KDQoNCg0KTm90IGEgcXVlc3Rp b24gZm9yIHRoaXMgZHJhZnQgbWF5YmUsIGJ1dCBpbiB3aGF0IGRyYWZ0IGlzIHRoZSBpbnRyb3Nw ZWN0aW9uIHJlc3BvbnNlIGNsYWltIGRlZmluZWQ/IEl04oCZcyBub3QgZGVmaW5lZCBpbiBodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzY2MiNzZWN0aW9uLTIuMiBhbmQgSSBkb27igJl0 IGtub3cgaW4gd2hhdCBvdGhlciBkcmFmdCBpdCBjYW4gYmUgZGVmaW5lZC4NCg0K4oCU4oCUDQoN CkluIEFDRSBXRyB0aGUgZHJhZnQgc2VpdHotYWNlLW9hdXRoLWF1dGh6IGhhdmUgYSBwcm9maWxl IGZvciBhbiBhY2Nlc3MgcmVxdWVzdCB0byBtYWtlIGl0IHdvcmsgb3ZlciBDb0FQLiBDb0FQIGlz IHRoZSBIVFRQIGVxdWl2YWxlbnQgZm9yIGNvbnN0cmFpbmVkIGRldmljZXMsIGFuZCBpdCBoYXMg bGltaXRhdGlvbnMsIGZvciBleGFtcGxlIGl0IGNhbuKAmXQgc2VuZCBsYXJnZSB0b2tlbnMgaW4g b3B0aW9ucyAoaGVhZGVycyBpbiAiaHR0cC1zcGVhayIpLiBUaGlzIG1lYW5zIHRoYXQgdGhlIGRy YWZ0IGRlZmluZXMgYSB3YXkgdG8gZmlyc3Qgc2VuZCB0aGUgUG9QIHRva2VuIHRvIGFuIG5ldyBl bmRwb2ludCBvbiB0aGUgcmVzb3VyY2Ugc2VydmVyIHRvIGVzdGFibGlzaCBhIHNlY3VyaXR5IGNv bnRleHQuIFRoZW4gdGhlIHJlYWwgcmVxdWVzdCBhZ2FpbnN0IHRoZSByZXNvdXJjZSBzZXJ2ZXIg Y2FuIGJlIGRvbmUgb25jZSB0aGUgc2VjdXJpdHkgY29udGV4dCBpcyBlc3RhYmxpc2hlZC4gU2Vl IG1vcmUgZGV0YWlscyBoZXJlIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zZWl0 ei1hY2Utb2F1dGgtYXV0aHotMDAjc2VjdGlvbi01LjIuDQoNCkFuIG9wZW4gcXVlc3Rpb247IHNo b3VsZCBhIGZsb3cgbGlrZSB0aGF0IGJlIGFkZGVkIHRvIHRoZSBhcmNoaXRlY3R1cmUgc2VjdGlv bj8gVGhhdCBtZWFucyBhIG5ldyBzZWN0aW9uIDcuNS4NCg0K4oCU4oCUDQoNClRoYW5rcyBmb3Ig d3JpdGluZyB0aGlzLiBJIHRoaW5rIGl04oCZcyB2ZXJ5IGltcG9ydGFudCB3b3JrLg0KDQovIEVy aWsNCg0KDQo= --_000_4197256B0C1246AAB2F2C9849F44BB3Anexusgroupcom_ Content-Type: text/html; charset="utf-8" Content-ID: <3DF764B56654DA4D8ADD07290129354D@nexusgroup.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYg Y2xhc3M9IiI+SGksJm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj5JIGhhdmUgYmVlbiByZXZpZXdpbmcmbmJzcDtkcmFmdC1pZXRm LW9hdXRoLXBvcC1hcmNoaXRlY3R1cmUtMDUuIEluIEFDRSBXRyB3ZSBoYXZlIGEgZHJhZnQgdGhh dCB1c2VzIFBvUCB0b2tlbnMgZm9yIElvVCBhbmQgdGhlIGFyY2hpdGVjdHVyZXMgZGVmaW5lZCBo ZXJlIHNvIG15IHJldmlldyB3YXMgZG9uZSB3aXRoIHRoYXQgSW9UIHBlcnNwZWN0aXZlLiBJ4oCZ bSBhIGJpdCBsYXRlIHdpdGggdGhlIHJldmlldyBhbmQgc29tZSBvZiB0aGUNCiBjb21tZW50cyBt aWdodCBhbHJlYWR5IGJlIG1lbnRpb25lZCBieSBvdGhlcnMuPC9kaXY+DQo8ZGl2IGNsYXNzPSIi PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4mbmJzcDs8L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPuKAlOKAlOKAlOKA lOKAlOKAlDwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2 Pg0KMy4xLiBQcmV2ZW50aW5nIEFjY2VzcyBUb2tlbiBSZS1Vc2UgYnkgdGhlIFJlc291cmNlIFNl cnZlcg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ SWYgYSBzeW1tZXRyaWMga2V5IGlzIHVzZWQgaXTigJlzIHBvc3NpYmxlIHRvIHJlLXVzZSB0aGUg a2V5IGZvciBhIHJlc291cmNlIHNlcnZlci4gVGhlIHNlY3Rpb24gdGFsa3MgYWJvdXQgdGhlIGlt cG9ydGFuY2Ugb2Ygc2NvcGVzLCBidXQgSSBmZWVsIGl0IHNob3VsZCBhbHNvIG1lbnRpb24gdGhl IGltcG9ydGFuY2UgZm9yIHRoZSByZXNvdXJjZSBzZXJ2ZXIgdG8gdmVyaWZ5IHRoZSBhdWRpZW5j ZSAo4oCcYXVk4oCdKSBjbGFpbSBpbg0KIHRoZSB0b2tlbiB0byBkaXNhYmxlIG1pc3N1c2UuPGJy IGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj7igJTigJTigJTigJTigJTi gJQ8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPlRoZSBkcmFmdCBpbiBBQ0UgV0cgKDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1zZWl0ei1hY2Utb2F1dGgtYXV0aHotMDAiIGNsYXNzPSIiPmh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zZWl0ei1hY2Utb2F1dGgtYXV0aHotMDA8L2E+KSByZWxp ZXMgaGVhdmlseSBvbiB0aGlzIHdvcmsuIFRoZSBtYWluIHJlYXNvbiBmb3IgdGhpcyBpcyB0aGUg d2F5IFBvUCB0b2tlbnMgY2FuDQogZXN0YWJsaXNoIGtleSBtYXRlcmlhbCwgd2l0aCB0aGUgaGVs cCBvZiB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIsIG9uIGJvdGggdGhlIGNsaWVudCBhbmQgcmVz b3VyY2Ugc2VydmVyLiBQb1AgdG9rZW5zIGlzIGFsc28gYSB2ZXJ5IGdvb2QgZml0IGZvciBjb25z dHJhaW5lZCBJb1QgZGV2aWNlcyB0aGF0IGNhbiBiZSBvZmZsaW5lIGFuZCBpdOKAmXMgYWxzbyBw b3NzaWJsZSB0byB1c2UgaGFyZHdhcmUga2V5IHN0b3JhZ2VzIHRvIGhhbmRsZSBhc3ltbWV0cmlj DQogcG9wIGtleXMuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj5UaGVyZSBjb3VsZCBiZSBhIHBsYWNlIGZvciBhIG5ldyAmcXVvdDtVc2Ug Q2FzZSZxdW90OyB1bmRlciBzZWN0aW9uIDMgdGhhdCB0YWxrcyBhYm91dCBzY2VuYXJpb3Mgd2hl cmUgUG9QIGtleXMgYXJlIGEgcmVhbGx5IGdvb2QgbWF0Y2ggZm9yIG9mZmxpbmUgSW9UIGRldmlj ZXMuIEkgY291bGQgaGVscCBvdXQgaXJvbmluZyBvdXQgYSB0ZXh0IGZvciB0aGF0IHdpdGggdGhl IGhlbHAgb2YgdGhlIGRvY3MgYXV0aG9ycyBpZiB0aGF04oCZcyBvZg0KIGludGVyZXN0LiZuYnNw OzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+4oCU4oCU4oCUPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj5zL2EgYm9ndXMgdG9rZW5zL2EgYm9ndXMgdG9rZW48L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPuKAlOKAlDwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+SW4g dGhlIGRvY3VtZW50IG9ubHkgcmVmZXJlbmNlcyBhcmUgbWFkZSB0byBKU09OLCBKV1QgYW5kIEpP U0UuIE1vcmUgZXhhY3RseSBpbiB0aGUgZm9sbG93aW5nIHR3byBzZWN0aW9uczo8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPHByZSBj bGFzcz0ibmV3cGFnZSIgc3R5bGU9ImZvbnQtc2l6ZTogMTMuMzMzM3B4OyBtYXJnaW4tdG9wOiAw cHg7IG1hcmdpbi1ib3R0b206IDBweDsgcGFnZS1icmVhay1iZWZvcmU6IGFsd2F5czsgd2lkb3dz OiAxOyI+ICAgQSBudW1iZXIgb2YgdGhlIHRocmVhdHMgbGlzdGVkIGluIDxhIGhyZWY9Imh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLXBvcC1hcmNoaXRlY3R1cmUt MDUjc2VjdGlvbi00IiBjbGFzcz0iIj5TZWN0aW9uIDQ8L2E+IGRlbWFuZCBwcm90ZWN0aW9uIG9m IHRoZQ0KICAgYWNjZXNzIHRva2VuIGNvbnRlbnQgYW5kIGEgc3RhbmRhcmRpemVkIHNvbHV0aW9u LCBpbiBmb3JtIG9mIGEgSlNPTi0NCiAgIGJhc2VkIGZvcm1hdCwgaXMgYXZhaWxhYmxlIHdpdGgg dGhlIEpXVCBbPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzc1MTkiIHRp dGxlPSImcXVvdDtKU09OIFdlYiBUb2tlbiAoSldUKSZxdW90OyIgY2xhc3M9IiI+UkZDNzUxOTwv YT5dLg0KPC9wcmU+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxk aXYgY2xhc3M9IiI+DQo8cHJlIGNsYXNzPSJuZXdwYWdlIiBzdHlsZT0iZm9udC1zaXplOiAxMy4z MzMzcHg7IG1hcmdpbi10b3A6IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4OyBwYWdlLWJyZWFrLWJl Zm9yZTogYWx3YXlzOyB3aWRvd3M6IDE7Ij4gICBXaXRoIHRoZSBKU09OIFdlYiBUb2tlbiAoSldU KSBbPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzc1MTkiIHRpdGxlPSIm cXVvdDtKU09OIFdlYiBUb2tlbiAoSldUKSZxdW90OyIgY2xhc3M9IiI+UkZDNzUxOTwvYT5dIGEg c3RhbmRhcmRpemVkIGZvcm1hdCBmb3INCiAgIGFjY2VzcyB0b2tlbnMgaXMgYXZhaWxhYmxlLiAg VGhlIG5lY2Vzc2FyeSBlbGVtZW50cyB0byBiaW5kIHN5bW1ldHJpYw0KICAgb3IgYXN5bW1ldHJp YyBrZXlzIHRvIGEgSldUIGFyZSBkZXNjcmliZWQgaW4NCiAgIFs8YSBocmVmPSJodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1wb3AtYXJjaGl0ZWN0dXJlLTA1I3Jl Zi1JLUQuaWV0Zi1vYXV0aC1wcm9vZi1vZi1wb3NzZXNzaW9uIiBjbGFzcz0iIj5JLUQuaWV0Zi1v YXV0aC1wcm9vZi1vZi1wb3NzZXNzaW9uPC9hPl0uDQo8L3ByZT4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5Db25zdHJh aW5lZCBJb1QgZGV2aWNlcyB1c2VzIG90aGVyIGFjY2VzcyB0b2tlbiBhbmQgbWVzc2FnZXMgZm9y bWF0cyAoYWNjb3JkaW5nIHRvIG91ciBkcmFmdCkuIEl0IGRvZXMgbm90IG9ubHkgdXNlIHNpZ25l ZC9lbmNyeXB0ZWQgSldU4oCZcyBidXQgYWxzbyBDT1NFIHByb3RlY3RlZCBDQk9SIFdlYiBUb2tl bnMuIFNlZSZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtd2Fo bHN0cm9lbS1vYXV0aC1jYm9yLXdlYi10b2tlbi0wMC50eHQiIGNsYXNzPSIiPmh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaWQvZHJhZnQtd2FobHN0cm9lbS1vYXV0aC1jYm9yLXdlYi10b2tlbi0wMC50 eHQ8L2E+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj5JIHRvdGFsbHkgYWdyZWUgdGhhdCBKV1QgaXMgdGhlIGNvcnJlY3QgZXhhbXBsZXMg dG8gaGF2ZSBpbiB0aGlzIGRvY3VtZW50IGR1ZSB0byB0aGUgZmFjdCB0aGF0IHRoZXkgYXJlIFJG Q+KAmXMsIHRoZXkgYXJlIHdlbGwga25vd24gYW5kIHNob3VsZCBiZSB1c2VkIGluIGFzIG1hbnkg cGxhY2VzIGFzIHBvc3NpYmxlLCBidXQgaXQgd291bGQgYmUgZ29vZCB0byBvcGVuIHVwIGZvciBv dGhlciB0eXBlcyBvZiBtZXNzYWdlIGZvcm1hdHMuDQogRm9yIGV4YW1wbGUgbGlrZSB0aGlzOjwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPHByZSBjbGFzcz0ibmV3cGFn ZSIgc3R5bGU9ImZvbnQtc2l6ZTogMTMuMzMzM3B4OyBtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1i b3R0b206IDBweDsgcGFnZS1icmVhay1iZWZvcmU6IGFsd2F5czsgd2lkb3dzOiAxOyI+ICAgQSBu dW1iZXIgb2YgdGhlIHRocmVhdHMgbGlzdGVkIGluIDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLXBvcC1hcmNoaXRlY3R1cmUtMDUjc2VjdGlvbi00 IiBjbGFzcz0iIj5TZWN0aW9uIDQ8L2E+IGRlbWFuZCBwcm90ZWN0aW9uIG9mIHRoZQ0KICAgYWNj ZXNzIHRva2VuIGNvbnRlbnQgYW5kIGEgc3RhbmRhcmRpemVkIHNvbHV0aW9uIGluIGZvcm0gb2Ys IDxiIGNsYXNzPSIiPmZvciBleGFtcGxlLDwvYj4gYSBKU09OLQ0KICAgYmFzZWQgZm9ybWF0LCBp cyBhdmFpbGFibGUgd2l0aCB0aGUgSldUIFs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvcmZjNzUxOSIgdGl0bGU9IiZxdW90O0pTT04gV2ViIFRva2VuIChKV1QpJnF1b3Q7IiBj bGFzcz0iIj5SRkM3NTE5PC9hPl0uDQo8L3ByZT4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIg Y2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPuKAlOKAlDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPHByZSBjbGFzcz0ibmV3cGFn ZSIgc3R5bGU9ImZvbnQtc2l6ZTogMTMuMzMzM3B4OyBtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1i b3R0b206IDBweDsgcGFnZS1icmVhay1iZWZvcmU6IGFsd2F5czsgd2lkb3dzOiAxOyI+IEZvciB0 aGF0DQogICBwdXJwb3NlIHRoZSBjbGllbnQgd2lsbCBoYXZlIHRvIGF1dGhlbnRpY2F0ZSB0aGUg cmVzb3VyY2Ugc2VydmVyDQogICBiZWZvcmUgdHJhbnNtaXR0aW5nIHRoZSBhY2Nlc3MgdG9rZW4u DQo8L3ByZT4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5J4oCZbSBtaXNzaW5nIGEgZGVzY3Jp cHRpb24gYWJvdXQgaG93IHRoaXMgaXMgaGFuZGxlZCBpbiBhbiBlbmQtdG8tZW5kIHNlY3VyaXR5 IHNjZW5hcmlvLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+4oCU4oCU4oCUPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4N CjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxwcmUgY2xhc3M9Im5ld3BhZ2UiIHN0eWxlPSJmb250 LXNpemU6IDEzLjMzMzNweDsgbWFyZ2luLXRvcDogMHB4OyBtYXJnaW4tYm90dG9tOiAwcHg7IHBh Z2UtYnJlYWstYmVmb3JlOiBhbHdheXM7IHdpZG93czogMTsiPiAgICAgIFRoZSByZXNvdXJjZSBz ZXJ2ZXIgcXVlcmllcyB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgZm9yIHRoZQ0KICAgICAgc3lt bWV0cmljIGtleS4gIFRoaXMgaXMgYW4gYXBwcm9hY2ggZW52aXNpb25lZCBieSB0aGUgdG9rZW4N CiAgICAgIGludHJvc3BlY3Rpb24gZW5kcG9pbnQgWzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLXBvcC1hcmNoaXRlY3R1cmUtMDUjcmVmLUktRC5p ZXRmLW9hdXRoLWludHJvc3BlY3Rpb24iIGNsYXNzPSIiPkktRC5pZXRmLW9hdXRoLWludHJvc3Bl Y3Rpb248L2E+XS4NCjwvcHJlPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4N CjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+Tm90IGEgcXVlc3Rpb24gZm9yIHRoaXMgZHJhZnQgbWF5YmUsIGJ1dCBpbiB3aGF0IGRyYWZ0 IGlzIHRoZSBpbnRyb3NwZWN0aW9uIHJlc3BvbnNlIGNsYWltIGRlZmluZWQ/IEl04oCZcyBub3Qg ZGVmaW5lZCBpbiZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3 NjYyI3NlY3Rpb24tMi4yIiBjbGFzcz0iIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZj NzY2MiNzZWN0aW9uLTIuMjwvYT4mbmJzcDthbmQNCiBJIGRvbuKAmXQga25vdyBpbiB3aGF0IG90 aGVyIGRyYWZ0IGl0IGNhbiBiZSBkZWZpbmVkLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xh c3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+4oCU4oCUPC9kaXY+DQo8ZGl2IGNsYXNzPSIi PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5JbiBBQ0UgV0cgdGhlIGRyYWZ0 IHNlaXR6LWFjZS1vYXV0aC1hdXRoeiBoYXZlIGEgcHJvZmlsZSBmb3IgYW4gYWNjZXNzIHJlcXVl c3QgdG8gbWFrZSBpdCB3b3JrIG92ZXIgQ29BUC4gQ29BUCBpcyB0aGUgSFRUUCBlcXVpdmFsZW50 IGZvciBjb25zdHJhaW5lZCBkZXZpY2VzLCBhbmQgaXQgaGFzIGxpbWl0YXRpb25zLCBmb3IgZXhh bXBsZSBpdCBjYW7igJl0IHNlbmQgbGFyZ2UgdG9rZW5zIGluIG9wdGlvbnMgKGhlYWRlcnMgaW4N CiAmcXVvdDtodHRwLXNwZWFrJnF1b3Q7KS4gVGhpcyBtZWFucyB0aGF0IHRoZSBkcmFmdCBkZWZp bmVzIGEgd2F5IHRvIGZpcnN0IHNlbmQgdGhlIFBvUCB0b2tlbiB0byBhbiBuZXcgZW5kcG9pbnQg b24gdGhlIHJlc291cmNlIHNlcnZlciB0byBlc3RhYmxpc2ggYSBzZWN1cml0eSBjb250ZXh0LiBU aGVuIHRoZSByZWFsIHJlcXVlc3QgYWdhaW5zdCB0aGUgcmVzb3VyY2Ugc2VydmVyIGNhbiBiZSBk b25lIG9uY2UgdGhlIHNlY3VyaXR5IGNvbnRleHQgaXMgZXN0YWJsaXNoZWQuDQogU2VlIG1vcmUg ZGV0YWlscyBoZXJlJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LXNlaXR6LWFjZS1vYXV0aC1hdXRoei0wMCNzZWN0aW9uLTUuMiIgY2xhc3M9IiI+aHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNlaXR6LWFjZS1vYXV0aC1hdXRoei0wMCNzZWN0 aW9uLTUuMjwvYT4uPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj5BbiBvcGVuIHF1ZXN0aW9uOyBzaG91bGQgYSBmbG93IGxpa2UgdGhhdCBi ZSBhZGRlZCB0byB0aGUgYXJjaGl0ZWN0dXJlIHNlY3Rpb24/IFRoYXQgbWVhbnMgYSBuZXcgc2Vj dGlvbiA3LjUuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRp diBjbGFzcz0iIj7igJTigJQ8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPlRoYW5rcyBmb3Igd3JpdGluZyB0aGlzLiBJIHRoaW5rIGl04oCZ cyB2ZXJ5IGltcG9ydGFudCB3b3JrLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+ DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+LyBFcmlrPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_4197256B0C1246AAB2F2C9849F44BB3Anexusgroupcom_-- From nobody Thu Nov 19 03:04:00 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D78AF1B320B for ; Thu, 19 Nov 2015 03:02:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.884 X-Spam-Level: X-Spam-Status: No, score=-2.884 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.585] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1PxD1ymh8jMK for ; Thu, 19 Nov 2015 03:02:42 -0800 (PST) Received: from smtp.nexusgroup.com (smtp.nexusgroup.com [83.241.133.120]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94D811B320D for ; Thu, 19 Nov 2015 03:02:41 -0800 (PST) Received: from NG-EX01.ad.nexusgroup.com (10.75.28.40) by NG-EX01.ad.nexusgroup.com (10.75.28.40) with Microsoft SMTP Server (TLS) id 15.0.995.29; Thu, 19 Nov 2015 12:02:39 +0100 Received: from NG-EX01.ad.nexusgroup.com ([fe80::1d3d:b319:f020:2bab]) by NG-EX01.ad.nexusgroup.com ([fe80::1d3d:b319:f020:2bab%12]) with mapi id 15.00.0995.032; Thu, 19 Nov 2015 12:02:39 +0100 From: =?utf-8?B?RXJpayBXYWhsc3Ryw7ZtIG5lWHVz?= To: "" Thread-Topic: A review of draft-ietf-oauth-proof-of-possession-06 Thread-Index: AQHRIrnNevd5trzixkmxn3Rk/lM2BA== Date: Thu, 19 Nov 2015 11:02:38 +0000 Message-ID: <73BB3C65-C30B-4634-8561-A4F3B5912995@nexusgroup.com> Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.2104) x-originating-ip: [213.113.163.201] Content-Type: multipart/alternative; boundary="_000_73BB3C65C30B46348561A4F3B5912995nexusgroupcom_" MIME-Version: 1.0 Archived-At: Subject: [OAUTH-WG] A review of draft-ietf-oauth-proof-of-possession-06 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2015 11:02:47 -0000 --_000_73BB3C65C30B46348561A4F3B5912995nexusgroupcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBtYWRlIGEgKGxhdGUpIHJldmlldyBvZiBkcmFmdC1pZXRmLW9hdXRoLXByb29mLW9mLXBvc3Nl c3Npb24tMDYgIGFuZCBhcyB3aXRoIGRyYWZ0LWlldGYtb2F1dGgtcG9wLWFyY2hpdGVjdHVyZS0w NSBJIHRoaW5rIGl04oCZcyBpbiByZWFsbHkgZ29vZCBzaGFwZSBhbmQgaXTigJlzIG5vdCBtdWNo IHRvIGNvbW1lbnQgb24uDQoNCg0KVGhlIG9ubHkgdGhpbmcgdGhhdCBJIGNvdWxkIG1lbnRpb24g aXMgdGhhdCB0aGUgaW50cm9kdWN0aW9uIG9mIHRoZSDigJxqd2vigJ0gbWVtYmVyIGluIHRoZSBm b2xsb3dpbmcgdGV4dCBpcyBhIGJpdCBhYnJ1cHQ6DQoNCg0KV2hlbiB0aGUga2V5IGhlbGQgYnkg dGhlIHByZXNlbnRlciBpcyBhbiBhc3ltbWV0cmljIHByaXZhdGUga2V5LCB0aGUNCiAgICJqd2si IG1lbWJlciBpcyBhIEpTT04gV2ViIEtleSAoSldLKSBbSldLPGh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLXByb29mLW9mLXBvc3Nlc3Npb24tMDYjcmVmLUpXSz5d IHJlcHJlc2VudGluZyB0aGUNCiAgIGNvcnJlc3BvbmRpbmcgYXN5bW1ldHJpYyBwdWJsaWMga2V5 Lg0KDQoNCkl04oCZcyB0aGUgZmlyc3QgdGltZSB0aGUgbWVtYmVyIGlzIGludHJvZHVjZWQuIFNh bWUgb24g4oCcandlIi4NCg0KT3RoZXJ3aXNlLCBhcyBJIHNhaWQuIEl04oCZcyBpbiByZWFsbHkg Z29vZCBzaGFwZS4NCg0KLyBFcmlrDQoNCg== --_000_73BB3C65C30B46348561A4F3B5912995nexusgroupcom_ Content-Type: text/html; charset="utf-8" Content-ID: <94174970B04FDD4889EA76019C52EE64@nexusgroup.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPHByZSBjbGFzcz0ibmV3cGFnZSIg c3R5bGU9IndpZG93czogMTsgbWFyZ2luLXRvcDogMHB4OyBtYXJnaW4tYm90dG9tOiAwcHg7IHBh Z2UtYnJlYWstYmVmb3JlOiBhbHdheXM7Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMnB4OyBm b250LWZhbWlseTogSGVsdmV0aWNhOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87 IiBjbGFzcz0iIj5JIG1hZGUgYSAobGF0ZSkgcmV2aWV3IG9mJm5ic3A7PC9zcGFuPjxmb250IGZh Y2U9IkhlbHZldGljYSIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9IndoaXRlLXNwYWNlOiBub3JtYWw7 IiBjbGFzcz0iIj5kcmFmdC1pZXRmLW9hdXRoLXByb29mLW9mLXBvc3Nlc3Npb24tMDYgJm5ic3A7 YW5kIGFzIHdpdGgmbmJzcDtkcmFmdC1pZXRmLW9hdXRoLXBvcC1hcmNoaXRlY3R1cmUtMDUgSSB0 aGluayBpdOKAmXMgaW4mbmJzcDtyZWFsbHkmbmJzcDtnb29kIHNoYXBlIGFuZCBpdOKAmXMgbm90 IG11Y2ggdG8gY29tbWVudCBvbi48L3NwYW4+PC9mb250PjwvcHJlPg0KPHByZSBjbGFzcz0ibmV3 cGFnZSIgc3R5bGU9ImZvbnQtc2l6ZTogMTMuMzMzM3B4OyBtYXJnaW4tdG9wOiAwcHg7IG1hcmdp bi1ib3R0b206IDBweDsgcGFnZS1icmVhay1iZWZvcmU6IGFsd2F5czsgd2lkb3dzOiAxOyI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgd2hpdGUt c3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyIgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPjwvc3Bh bj48L3ByZT4NCjxwcmUgY2xhc3M9Im5ld3BhZ2UiIHN0eWxlPSJtYXJnaW4tdG9wOiAwcHg7IG1h cmdpbi1ib3R0b206IDBweDsgcGFnZS1icmVhay1iZWZvcmU6IGFsd2F5czsgd2lkb3dzOiAxOyI+ PHNwYW4gc3R5bGU9IndpZG93czogYXV0bzsiIGNsYXNzPSIiPjxmb250IGZhY2U9IkhlbHZldGlj YSIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9IndoaXRlLXNwYWNlOiBub3JtYWw7IiBjbGFzcz0iIj5U aGUgb25seSB0aGluZyB0aGF0IEkgY291bGQmbmJzcDttZW50aW9uIGlzIHRoYXQgdGhlIGludHJv ZHVjdGlvbiBvZiB0aGUg4oCcandr4oCdIG1lbWJlciBpbiB0aGUgZm9sbG93aW5nIHRleHQgaXMg YSBiaXQgYWJydXB0Ojwvc3Bhbj48L2ZvbnQ+PC9zcGFuPjwvcHJlPg0KPHByZSBjbGFzcz0ibmV3 cGFnZSIgc3R5bGU9ImZvbnQtc2l6ZTogMTMuMzMzM3B4OyBtYXJnaW4tdG9wOiAwcHg7IG1hcmdp bi1ib3R0b206IDBweDsgcGFnZS1icmVhay1iZWZvcmU6IGFsd2F5czsgd2lkb3dzOiAxOyI+PGJy IGNsYXNzPSIiPjwvcHJlPg0KPHByZSBjbGFzcz0ibmV3cGFnZSIgc3R5bGU9ImZvbnQtc2l6ZTog MTMuMzMzM3B4OyBtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0b206IDBweDsgcGFnZS1icmVh ay1iZWZvcmU6IGFsd2F5czsgd2lkb3dzOiAxOyI+V2hlbiB0aGUga2V5IGhlbGQgYnkgdGhlIHBy ZXNlbnRlciBpcyBhbiBhc3ltbWV0cmljIHByaXZhdGUga2V5LCB0aGUNCiAgICZxdW90O2p3ayZx dW90OyBtZW1iZXIgaXMgYSBKU09OIFdlYiBLZXkgKEpXSykgWzxhIGhyZWY9Imh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLXByb29mLW9mLXBvc3Nlc3Npb24tMDYj cmVmLUpXSyIgdGl0bGU9IiZxdW90O0pTT04gV2ViIEtleSAoSldLKSZxdW90OyIgY2xhc3M9IiI+ SldLPC9hPl0gcmVwcmVzZW50aW5nIHRoZQ0KICAgY29ycmVzcG9uZGluZyBhc3ltbWV0cmljIHB1 YmxpYyBrZXkuPC9wcmU+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRp diBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+SXTigJlzIHRo ZSBmaXJzdCB0aW1lIHRoZSBtZW1iZXIgaXMgaW50cm9kdWNlZC4gU2FtZSBvbiDigJxqd2UmcXVv dDsuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj5PdGhlcndpc2UsIGFzIEkgc2FpZC4gSXTigJlzIGluIHJlYWxseSBnb29kIHNoYXBlLjwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ LyBFcmlrPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9ib2R5 Pg0KPC9odG1sPg0K --_000_73BB3C65C30B46348561A4F3B5912995nexusgroupcom_-- From nobody Thu Nov 19 08:18:17 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17D471B2B88 for ; Thu, 19 Nov 2015 08:18:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.484 X-Spam-Level: X-Spam-Status: No, score=-4.484 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v4z7rj0bprgI for ; Thu, 19 Nov 2015 08:18:13 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE2D81B2C63 for ; Thu, 19 Nov 2015 08:17:54 -0800 (PST) Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id tAJGHq35031775 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 19 Nov 2015 16:17:52 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id tAJGHp2V004403 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 19 Nov 2015 16:17:51 GMT Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id tAJGHpdX001240; Thu, 19 Nov 2015 16:17:51 GMT Received: from [192.168.1.27] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 19 Nov 2015 08:17:50 -0800 Content-Type: multipart/alternative; boundary=Apple-Mail-0F232C7C-E2DC-4111-8B15-970279335DC8 Mime-Version: 1.0 (1.0) From: Phil Hunt X-Mailer: iPhone Mail (13B143) In-Reply-To: <4197256B-0C12-46AA-B2F2-C9849F44BB3A@nexusgroup.com> Date: Thu, 19 Nov 2015 08:17:49 -0800 Content-Transfer-Encoding: 7bit Message-Id: <89483136-58E9-49C6-AE8B-E2A58E14F3B3@oracle.com> References: <4197256B-0C12-46AA-B2F2-C9849F44BB3A@nexusgroup.com> To: =?utf-8?Q?Erik_Wahlstr=C3=B6m_neXus?= X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Cc: "" Subject: Re: [OAUTH-WG] A review of draft-ietf-oauth-pop-architecture-05 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2015 16:18:16 -0000 --Apple-Mail-0F232C7C-E2DC-4111-8B15-970279335DC8 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On the subject of making the spec(s) less JWT specific, it was a foundationa= l assumption and (I think) in the charter. However COSE wasn't around yet.=20= I suppose the more generic architecture doc could be altered to cover IoT ca= ses, but it may be problematic for the other specs that are more specific.=20= Another issue is I assume the COSE based tokens will have a different type (= eg cpop) to differentiate between jwt and COSE web tokens (what are we calli= ng them now?).=20 As this generalization change could be seen as substantial, I would like to h= ave the chairs and AD comment. Is this a good idea? Or is COSE better to wr= ite their own parallel arch draft? I'm happy to bend to the will of the group(s) on this.=20 Phil > On Nov 19, 2015, at 01:17, Erik Wahlstr=C3=B6m neXus wrote: >=20 > Hi,=20 >=20 > I have been reviewing draft-ietf-oauth-pop-architecture-05. In ACE WG we h= ave a draft that uses PoP tokens for IoT and the architectures defined here s= o my review was done with that IoT perspective. I=E2=80=99m a bit late with t= he review and some of the comments might already be mentioned by others. >=20 > =20 >=20 > =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 >=20 > 3.1. Preventing Access Token Re-Use by the Resource Server >=20 > If a symmetric key is used it=E2=80=99s possible to re-use the key for a r= esource server. The section talks about the importance of scopes, but I feel= it should also mention the importance for the resource server to verify the= audience (=E2=80=9Caud=E2=80=9D) claim in the token to disable missuse. >=20 > =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 >=20 > The draft in ACE WG (https://tools.ietf.org/html/draft-seitz-ace-oauth-aut= hz-00) relies heavily on this work. The main reason for this is the way PoP t= okens can establish key material, with the help of the authorization server,= on both the client and resource server. PoP tokens is also a very good fit f= or constrained IoT devices that can be offline and it=E2=80=99s also possibl= e to use hardware key storages to handle asymmetric pop keys. >=20 > There could be a place for a new "Use Case" under section 3 that talks abo= ut scenarios where PoP keys are a really good match for offline IoT devices.= I could help out ironing out a text for that with the help of the docs auth= ors if that=E2=80=99s of interest.=20 >=20 > =E2=80=94=E2=80=94=E2=80=94 >=20 > s/a bogus tokens/a bogus token >=20 > =E2=80=94=E2=80=94 >=20 > In the document only references are made to JSON, JWT and JOSE. More exact= ly in the following two sections: >=20 > A number of the threats listed in Section 4 demand protection of the > access token content and a standardized solution, in form of a JSON- > based format, is available with the JWT [RFC7519]. >=20 >=20 > With the JSON Web Token (JWT) [RFC7519] a standardized format for > access tokens is available. The necessary elements to bind symmetric > or asymmetric keys to a JWT are described in > [I-D.ietf-oauth-proof-of-possession]. >=20 > Constrained IoT devices uses other access token and messages formats (acco= rding to our draft). It does not only use signed/encrypted JWT=E2=80=99s but= also COSE protected CBOR Web Tokens. See https://tools.ietf.org/id/draft-wa= hlstroem-oauth-cbor-web-token-00.txt >=20 > I totally agree that JWT is the correct examples to have in this document d= ue to the fact that they are RFC=E2=80=99s, they are well known and should b= e used in as many places as possible, but it would be good to open up for ot= her types of message formats. For example like this: >=20 >=20 > A number of the threats listed in Section 4 demand protection of the > access token content and a standardized solution in form of, for exampl= e, a JSON- > based format, is available with the JWT [RFC7519]. >=20 >=20 > =E2=80=94=E2=80=94 >=20 > For that > purpose the client will have to authenticate the resource server > before transmitting the access token. >=20 >=20 > I=E2=80=99m missing a description about how this is handled in an end-to-e= nd security scenario. >=20 > =E2=80=94=E2=80=94=E2=80=94 >=20 > The resource server queries the authorization server for the > symmetric key. This is an approach envisioned by the token > introspection endpoint [I-D.ietf-oauth-introspection]. >=20 >=20 > Not a question for this draft maybe, but in what draft is the introspectio= n response claim defined? It=E2=80=99s not defined in https://tools.ietf.org= /html/rfc7662#section-2.2 and I don=E2=80=99t know in what other draft it ca= n be defined. >=20 > =E2=80=94=E2=80=94 >=20 > In ACE WG the draft seitz-ace-oauth-authz have a profile for an access req= uest to make it work over CoAP. CoAP is the HTTP equivalent for constrained d= evices, and it has limitations, for example it can=E2=80=99t send large toke= ns in options (headers in "http-speak"). This means that the draft defines a= way to first send the PoP token to an new endpoint on the resource server t= o establish a security context. Then the real request against the resource s= erver can be done once the security context is established. See more details= here https://tools.ietf.org/html/draft-seitz-ace-oauth-authz-00#section-5.2= . >=20 > An open question; should a flow like that be added to the architecture sec= tion? That means a new section 7.5. >=20 > =E2=80=94=E2=80=94 >=20 > Thanks for writing this. I think it=E2=80=99s very important work. >=20 > / Erik >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-0F232C7C-E2DC-4111-8B15-970279335DC8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
On the subject of making the spec(s) l= ess JWT specific, it was a foundational assumption and (I think) in the char= ter. However COSE wasn't around yet. 

I suppose the more generic archi= tecture doc could be altered to cover IoT cases, but it may be problematic f= or the other specs that are more specific. 

Another issue is I assume t= he COSE based tokens will have a different type (eg cpop) to differentiate b= etween jwt and COSE web tokens (what are we calling them now?). 
<= div id=3D"AppleMailSignature">



--
=09 =3D"Ping=20
Brian Campbell
Distinguished Engineer
Ping Identity
@<= /td> <= span style=3D"text-decoration:none;color:#000000;font-family:arial,helvetic= a,sans-serif;font-weight:normal;font-size:14px;padding:0 0 0 3px">bcampbell@pingiden= tity.com
3D"phone" <= span style=3D"color:#000000;font-family:arial,helvetica,sans-serif;font-wei= ght:normal;font-size:14px;padding:0 0 0 3px">+1 720.317.2061
3D"twitter" <= span style=3D"color:#000000;font-family:arial,helvetica,sans-serif;font-wei= ght:normal;font-size:14px;padding:0 0 0 3px">@pingidentity
Connect with us!
3D"pingidentity.com"
3D"pingidentity.com"
3D"twitter 3D"twitter 3D"youtube 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard 3D"rss
--001a113f8b8289b9870525609aa7-- From nobody Wed Nov 25 09:33:45 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E81D1A6FDE for ; Wed, 25 Nov 2015 09:33:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.775 X-Spam-Level: X-Spam-Status: No, score=-4.775 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id argu9hKnGl4k for ; Wed, 25 Nov 2015 09:33:39 -0800 (PST) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECE801A6FCD for ; Wed, 25 Nov 2015 09:33:31 -0800 (PST) X-AuditID: 12074425-f793c6d000006975-21-5655f0e92c79 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 04.98.26997.9E0F5565; Wed, 25 Nov 2015 12:33:29 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id tAPHXSYL017412; Wed, 25 Nov 2015 12:33:29 -0500 Received: from artemisia.richer.local (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id tAPHXQf9016583 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 25 Nov 2015 12:33:28 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_F4EC4F39-AD6A-451B-A42F-7BFEEFABCA9E" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Justin Richer In-Reply-To: Date: Wed, 25 Nov 2015 12:33:26 -0500 Message-Id: References: <20151124200512.20833.28463.idtracker@ietfa.amsl.com> <16FAD3AC-CFB8-46D5-A12E-436E902EA439@oracle.com> To: Brian Campbell X-Mailer: Apple Mail (2.2104) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprHKsWRmVeSWpSXmKPExsUixCmqrPvyQ2iYwfxjmhar/99ktDj59hWb xYL5jewOzB5Llvxk8vj49BaLx92jF1kCmKO4bFJSczLLUov07RK4Ms6v+MFe0PuHsaJzz3a2 BsY7txm7GDk5JARMJJ5+fssMYYtJXLi3nq2LkYtDSGAxk8S1ff0sEM5GRokpnfuZIJyHTBKr 5r9lB2lhFkiQWN+ziAXE5hXQk3h16zIriC0s4CNx8fQTMJtNQFVi+poWJhCbUyBQovv8YjYQ mwUofmXzZSaIOZ4Sn6ZPh5pjJfG7YSrU5vVMEku7WsAaRAT0JW4/ncMOcausxO7fj5gmMArM QnLHLCR3QMS1JZYtfM0MYWtK7O9ezoIpriHR+W0i6wJGtlWMsim5Vbq5iZk5xanJusXJiXl5 qUW6Fnq5mSV6qSmlmxhB0cDuorqDccIhpUOMAhyMSjy8Ex6FhAmxJpYVV+YeYpTkYFIS5W27 EBomxJeUn1KZkVicEV9UmpNafIhRgoNZSYT3dy1QjjclsbIqtSgfJiXNwaIkzjv3i2+YkEB6 YklqdmpqQWoRTFaGg0NJgjfkPVCjYFFqempFWmZOCUKaiYMTZDgP0PBgkBre4oLE3OLMdIj8 KUZFKXHe+SAJAZBERmkeXC8oWSW8PWz6ilEc6BVhXmGQKh5gooPrfgU0mAlocEQO2OCSRISU VAOj8CruveeWyd7x3iq/uLbs+kKTOGGzOev6ZwZ5bY6szGTRrlpbpq8rPGGTqtdV3w/G9W87 Ow8F5y42CAsw36d4+pUJy7zQCVXs7Fuf6H7maPA9a9WhHd4ayML4wonBWt5hRwvPYaGzkjmW WvpP+1bK/50c9bthc3ZsKKN6vkHa06nHH/9xkFJiKc5INNRiLipOBACbGWAtMQMAAA== Archived-At: Cc: "" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-pop-architecture-06.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2015 17:33:43 -0000 --Apple-Mail=_F4EC4F39-AD6A-451B-A42F-7BFEEFABCA9E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The token doesn=E2=80=99t have to be signed and the client doesn=E2=80=99t= have to verify the signature on the token. That=E2=80=99s not PoP. The = request has to be signed in a way that includes the token. The token = itself can still be opaque. The *key* material can=E2=80=99t be opaque = to the client, but the *token* material still is. I agree with Brian that this statement is misleading. The examples use a signed token but that is absolutely not a = requirement. Maybe the examples shouldn=E2=80=99t all use one style. What=E2=80=99s most difficult about this particular spec is that it=E2=80=99= s very hand-wavy, saying =E2=80=9Cthis is kinda a thing that kinda works = like this=E2=80=9D without saying how to actually do it. I=E2=80=99m = honestly not sure it=E2=80=99s worth publishing as an RFC in its own = right but I=E2=80=99m not going to stand in its way. =E2=80=94 Justin > On Nov 25, 2015, at 12:14 PM, Brian Campbell = wrote: >=20 > Where does it say that?=20 >=20 >=20 >=20 > On Wed, Nov 25, 2015 at 8:44 AM, Phil Hunt > wrote: > Except that later on we require the token be signed and the client = verify that signed token. IOW mutual pop.=20 >=20 > Phil >=20 > On Nov 25, 2015, at 07:30, Brian Campbell > wrote: >=20 >> Looking at the diff I noticed the following new text, which seems to = conflate bearer/PoP and opaqueness to the client. A client demonstrating = proof-of-possession of some key is orthogonal to the client being able = to parse and understand the access token itself.=20 >> =20 >> "In contrast to bearer tokens [RFC6750] which call for tokens that = are opaque to OAuth 2.0 clients, this specification defines the = requirements for proof-of-possession ("PoP") tokens that may be parsed = and verified by OAuth 2.0 clients and relying parties." >>=20 >> On Tue, Nov 24, 2015 at 1:07 PM, Phil Hunt > wrote: >> This draft addresses review comments from Kathleen and Erik raised = since the last draft. >>=20 >> It may not include some of the discussion from yesterday/today. I = will add that as the group decides. >>=20 >> Cheers, >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >> > On Nov 24, 2015, at 12:05 PM, internet-drafts@ietf.org = wrote: >> > >> > >> > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >> > This draft is a work item of the Web Authorization Protocol Working = Group of the IETF. >> > >> > Title : OAuth 2.0 Proof-of-Possession (PoP) = Security Architecture >> > Authors : Phil Hunt >> > Justin Richer >> > William Mills >> > Prateek Mishra >> > Hannes Tschofenig >> > Filename : draft-ietf-oauth-pop-architecture-06.txt >> > Pages : 23 >> > Date : 2015-11-24 >> > >> > Abstract: >> > The OAuth 2.0 bearer token specification, as defined in RFC 6750, >> > allows any party in possession of a bearer token (a "bearer") to = get >> > access to the associated resources (without demonstrating = possession >> > of a cryptographic key). To prevent misuse, bearer tokens must = be >> > protected from disclosure in transit and at rest. >> > >> > Some scenarios demand additional security protection whereby a = client >> > needs to demonstrate possession of cryptographic keying material = when >> > accessing a protected resource. This document motivates the >> > development of the OAuth 2.0 proof-of-possession security = mechanism. >> > >> > >> > The IETF datatracker status page for this draft is: >> > https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architecture/ = >> > >> > There's also a htmlized version available at: >> > https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-06 = >> > >> > A diff from the previous version is available at: >> > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-pop-architecture-06 = = >> > >> > >> > 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 = >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = >>=20 >>=20 >>=20 >> --=20 >> =09 >> Brian Campbell >> Distinguished Engineer >> Ping Identity >> @ bcampbell@pingidentity.com >> +1 720.317.2061 >> @pingidentity >> Connect with us! >> >> = = = = = = = = >=20 >=20 > --=20 > =09 > Brian Campbell > Distinguished Engineer > Ping Identity > @ bcampbell@pingidentity.com > +1 720.317.2061 > @pingidentity > Connect with us! > > = = = = = = = = _____________________________________= __________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_F4EC4F39-AD6A-451B-A42F-7BFEEFABCA9E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 The token doesn=E2=80=99t have to be signed and the client = doesn=E2=80=99t have to verify the signature on the token. That=E2=80=99s = not PoP. The request has to be signed in a way that includes the token. = The token itself can still be opaque. The *key* material can=E2=80=99t = be opaque to the client, but the *token* material still is.

I agree with Brian that = this statement is misleading.

The examples use a signed token but = that is absolutely not a requirement. Maybe the examples shouldn=E2=80=99t= all use one style.

What=E2=80=99s most difficult about this particular spec is = that it=E2=80=99s very hand-wavy, saying =E2=80=9Cthis is kinda a thing = that kinda works like this=E2=80=9D without saying how to actually do = it. I=E2=80=99m honestly not sure it=E2=80=99s worth publishing as an = RFC in its own right but I=E2=80=99m not going to stand in its = way.

 =E2=80= =94 Justin

On Nov 25, 2015, at 12:14 PM, = Brian Campbell <bcampbell@pingidentity.com> wrote:

Where does it say that?



On Wed, = Nov 25, 2015 at 8:44 AM, Phil Hunt <phil.hunt@oracle.com> wrote:
Except that later on we require the token be = signed and the client verify that signed token. IOW mutual = pop. 

Phil

On Nov 25, 2015, at 07:30, = Brian Campbell <bcampbell@pingidentity.com> = wrote:

Looking at the = diff I noticed the following new text, which seems to conflate = bearer/PoP and opaqueness to the client. A client demonstrating = proof-of-possession of some key is orthogonal to the client being able = to parse and understand the access token itself.
 
"In contrast to bearer tokens [RFC6750] which call for tokens = that are opaque to OAuth 2.0 clients, this specification defines the = requirements for proof-of-possession ("PoP") tokens that may be parsed = and verified by OAuth 2.0 clients and relying parties."

On Tue, Nov 24, 2015 at 1:07 PM, Phil Hunt <phil.hunt@oracle.com> = wrote:
This draft = addresses review comments from Kathleen and Erik raised since the last = draft.

It may not include some of the discussion from yesterday/today.  I = will add that as the group decides.

Cheers,

Phil

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

> On Nov 24, 2015, at 12:05 PM, internet-drafts@ietf.org wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts = directories.
> This draft is a work item of the Web Authorization Protocol Working = Group of the IETF.
>
>        Title          =  : OAuth 2.0 Proof-of-Possession (PoP) Security Architecture
>        Authors        =  : Phil Hunt
>                  =         Justin Richer
>                  =         William Mills
>                  =         Prateek Mishra
>                  =         Hannes Tschofenig
>       Filename        : = draft-ietf-oauth-pop-architecture-06.txt
>       Pages          =  : 23
>       Date          =   : 2015-11-24
>
> Abstract:
>   The OAuth 2.0 bearer token specification, as defined in = RFC 6750,
>   allows any party in possession of a bearer token (a = "bearer") to get
>   access to the associated resources (without = demonstrating possession
>   of a cryptographic key).  To prevent misuse, = bearer tokens must be
>   protected from disclosure in transit and at rest.
>
>   Some scenarios demand additional security protection = whereby a client
>   needs to demonstrate possession of cryptographic keying = material when
>   accessing a protected resource.  This document = motivates the
>   development of the OAuth 2.0 proof-of-possession = security mechanism.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architect= ure/
>
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-0= 6
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-pop-archit= ecture-06
>
>
> 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



--
=09 3D"Ping=20
Brian Campbell
Distinguished Engineer
Ping Identity
@ bcampbell@pingidentity.com
3D"phone" +1 720.317.2061
3D"twitter" @pingidentity
Connect with = us!
3D"pingidentity.com"
=
3D"pingidentity.com"
= 3D"twitter 3D"twitter 3D"youtube 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard= 3D"rss


--
=09 3D"Ping=20
Brian Campbell
Distinguished Engineer
Ping Identity
@ bcampbell@pingidentity.com
3D"phone" +1 720.317.2061
3D"twitter" @pingidentity
Connect with = us!
3D"pingidentity.com"
=
3D"pingidentity.com"
= 3D"twitter 3D"twitter 3D"youtube 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard 3D"rss
_______________________________________________
OAuth = mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

= --Apple-Mail=_F4EC4F39-AD6A-451B-A42F-7BFEEFABCA9E-- From nobody Wed Nov 25 10:06:08 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48DA51A8769 for ; Wed, 25 Nov 2015 10:06:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.775 X-Spam-Level: X-Spam-Status: No, score=-4.775 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5cDv4oCbM3yG for ; Wed, 25 Nov 2015 10:06:04 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08B461A8765 for ; Wed, 25 Nov 2015 10:06:04 -0800 (PST) Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id tAPI62cx015836 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 25 Nov 2015 18:06:03 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id tAPI61rr018144 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 25 Nov 2015 18:06:01 GMT Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id tAPI60Gr028834; Wed, 25 Nov 2015 18:06:00 GMT Received: from [10.0.1.22] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 25 Nov 2015 10:05:58 -0800 Content-Type: multipart/alternative; boundary="Apple-Mail=_9BED1FB8-0183-419B-A9C1-048D2CA108C0" Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Phil Hunt In-Reply-To: Date: Wed, 25 Nov 2015 10:05:49 -0800 Message-Id: <6015EE15-1FEE-43DC-930C-68ACAEDC083E@oracle.com> References: <20151124200512.20833.28463.idtracker@ietfa.amsl.com> <16FAD3AC-CFB8-46D5-A12E-436E902EA439@oracle.com> To: Justin Richer X-Mailer: Apple Mail (2.3096.5) X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Cc: "" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-pop-architecture-06.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2015 18:06:07 -0000 --Apple-Mail=_9BED1FB8-0183-419B-A9C1-048D2CA108C0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Ok. Well this was requested by Kathleen because of this paragraph in Sec = 6.=E2=80=A6 To simplify the subsequent description we assume in the PoP = architecture that the token itself is digitally signed by the authorization server and therefore cannot be modified. Please=20 Phil @independentid www.independentid.com phil.hunt@oracle.com > On Nov 25, 2015, at 9:33 AM, Justin Richer wrote: >=20 > The token doesn=E2=80=99t have to be signed and the client doesn=E2=80=99= t have to verify the signature on the token. That=E2=80=99s not PoP. The = request has to be signed in a way that includes the token. The token = itself can still be opaque. The *key* material can=E2=80=99t be opaque = to the client, but the *token* material still is. >=20 > I agree with Brian that this statement is misleading. >=20 > The examples use a signed token but that is absolutely not a = requirement. Maybe the examples shouldn=E2=80=99t all use one style. >=20 > What=E2=80=99s most difficult about this particular spec is that = it=E2=80=99s very hand-wavy, saying =E2=80=9Cthis is kinda a thing that = kinda works like this=E2=80=9D without saying how to actually do it. = I=E2=80=99m honestly not sure it=E2=80=99s worth publishing as an RFC in = its own right but I=E2=80=99m not going to stand in its way. >=20 > =E2=80=94 Justin >=20 >> On Nov 25, 2015, at 12:14 PM, Brian Campbell = > wrote: >>=20 >> Where does it say that?=20 >>=20 >>=20 >>=20 >> On Wed, Nov 25, 2015 at 8:44 AM, Phil Hunt > wrote: >> Except that later on we require the token be signed and the client = verify that signed token. IOW mutual pop.=20 >>=20 >> Phil >>=20 >> On Nov 25, 2015, at 07:30, Brian Campbell > wrote: >>=20 >>> Looking at the diff I noticed the following new text, which seems to = conflate bearer/PoP and opaqueness to the client. A client demonstrating = proof-of-possession of some key is orthogonal to the client being able = to parse and understand the access token itself.=20 >>> =20 >>> "In contrast to bearer tokens [RFC6750] which call for tokens that = are opaque to OAuth 2.0 clients, this specification defines the = requirements for proof-of-possession ("PoP") tokens that may be parsed = and verified by OAuth 2.0 clients and relying parties." >>>=20 >>> On Tue, Nov 24, 2015 at 1:07 PM, Phil Hunt > wrote: >>> This draft addresses review comments from Kathleen and Erik raised = since the last draft. >>>=20 >>> It may not include some of the discussion from yesterday/today. I = will add that as the group decides. >>>=20 >>> Cheers, >>>=20 >>> Phil >>>=20 >>> @independentid >>> www.independentid.com >>> phil.hunt@oracle.com >>>=20 >>> > On Nov 24, 2015, at 12:05 PM, internet-drafts@ietf.org = wrote: >>> > >>> > >>> > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >>> > This draft is a work item of the Web Authorization Protocol = Working Group of the IETF. >>> > >>> > Title : OAuth 2.0 Proof-of-Possession (PoP) = Security Architecture >>> > Authors : Phil Hunt >>> > Justin Richer >>> > William Mills >>> > Prateek Mishra >>> > Hannes Tschofenig >>> > Filename : draft-ietf-oauth-pop-architecture-06.txt >>> > Pages : 23 >>> > Date : 2015-11-24 >>> > >>> > Abstract: >>> > The OAuth 2.0 bearer token specification, as defined in RFC = 6750, >>> > allows any party in possession of a bearer token (a "bearer") to = get >>> > access to the associated resources (without demonstrating = possession >>> > of a cryptographic key). To prevent misuse, bearer tokens must = be >>> > protected from disclosure in transit and at rest. >>> > >>> > Some scenarios demand additional security protection whereby a = client >>> > needs to demonstrate possession of cryptographic keying material = when >>> > accessing a protected resource. This document motivates the >>> > development of the OAuth 2.0 proof-of-possession security = mechanism. >>> > >>> > >>> > The IETF datatracker status page for this draft is: >>> > = https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architecture/ = >>> > >>> > There's also a htmlized version available at: >>> > https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-06 = >>> > >>> > A diff from the previous version is available at: >>> > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-pop-architecture-06 = = >>> > >>> > >>> > 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 = >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth = >>>=20 >>>=20 >>>=20 >>> --=20 >>> =09 >>> Brian Campbell >>> Distinguished Engineer >>> Ping Identity >>> @ bcampbell@pingidentity.com >>> +1 720.317.2061 >>> @pingidentity >>> Connect with us! >>> >>> = = = = = = = = >>=20 >>=20 >> --=20 >> =09 >> Brian Campbell >> Distinguished Engineer >> Ping Identity >> @ bcampbell@pingidentity.com >> +1 720.317.2061 >> @pingidentity >> Connect with us! >> >> = = = = = = = = _____________________________________= __________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 --Apple-Mail=_9BED1FB8-0183-419B-A9C1-048D2CA108C0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Ok. Well this was requested by Kathleen because of this = paragraph in Sec 6.=E2=80=A6

   To simplify the subsequent description we =
assume in the PoP architecture
   that the token itself is digitally signed =
by the authorization server

   and therefore cannot =
be modified.

Please 

On Nov 25, 2015, at 9:33 AM, Justin Richer <jricher@mit.edu> = wrote:

The token = doesn=E2=80=99t have to be signed and the client doesn=E2=80=99t have to = verify the signature on the token. That=E2=80=99s not PoP. The request = has to be signed in a way that includes the token. The token itself can = still be opaque. The *key* material can=E2=80=99t be opaque to the = client, but the *token* material still is.

I agree with Brian that this statement = is misleading.

The examples use a signed token but that is absolutely not a = requirement. Maybe the examples shouldn=E2=80=99t all use one = style.

What=E2=80= =99s most difficult about this particular spec is that it=E2=80=99s very = hand-wavy, saying =E2=80=9Cthis is kinda a thing that kinda works like = this=E2=80=9D without saying how to actually do it. I=E2=80=99m honestly = not sure it=E2=80=99s worth publishing as an RFC in its own right but = I=E2=80=99m not going to stand in its way.

 =E2=80=94 Justin

On Nov 25, 2015, at 12:14 PM, Brian Campbell = <bcampbell@pingidentity.com> wrote:

Where does it say that?



On Wed, = Nov 25, 2015 at 8:44 AM, Phil Hunt <phil.hunt@oracle.com> wrote:
Except that later on we require the token be = signed and the client verify that signed token. IOW mutual = pop. 

Phil

On Nov 25, 2015, at 07:30, = Brian Campbell <bcampbell@pingidentity.com> = wrote:

Looking at the = diff I noticed the following new text, which seems to conflate = bearer/PoP and opaqueness to the client. A client demonstrating = proof-of-possession of some key is orthogonal to the client being able = to parse and understand the access token itself.
 
"In contrast to bearer tokens [RFC6750] which call for tokens = that are opaque to OAuth 2.0 clients, this specification defines the = requirements for proof-of-possession ("PoP") tokens that may be parsed = and verified by OAuth 2.0 clients and relying parties."

On Tue, Nov 24, 2015 at 1:07 PM, Phil Hunt <phil.hunt@oracle.com> = wrote:
This draft = addresses review comments from Kathleen and Erik raised since the last = draft.

It may not include some of the discussion from yesterday/today.  I = will add that as the group decides.

Cheers,

Phil

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

> On Nov 24, 2015, at 12:05 PM, internet-drafts@ietf.org wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts = directories.
> This draft is a work item of the Web Authorization Protocol Working = Group of the IETF.
>
>        Title          =  : OAuth 2.0 Proof-of-Possession (PoP) Security Architecture
>        Authors        =  : Phil Hunt
>                  =         Justin Richer
>                  =         William Mills
>                  =         Prateek Mishra
>                  =         Hannes Tschofenig
>       Filename        : = draft-ietf-oauth-pop-architecture-06.txt
>       Pages          =  : 23
>       Date          =   : 2015-11-24
>
> Abstract:
>   The OAuth 2.0 bearer token specification, as defined in = RFC 6750,
>   allows any party in possession of a bearer token (a = "bearer") to get
>   access to the associated resources (without = demonstrating possession
>   of a cryptographic key).  To prevent misuse, = bearer tokens must be
>   protected from disclosure in transit and at rest.
>
>   Some scenarios demand additional security protection = whereby a client
>   needs to demonstrate possession of cryptographic keying = material when
>   accessing a protected resource.  This document = motivates the
>   development of the OAuth 2.0 proof-of-possession = security mechanism.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architect= ure/
>
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-0= 6
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-pop-archit= ecture-06
>
>
> 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



--
=09 3D"Ping=20
Brian Campbell
Distinguished Engineer
Ping Identity
@ bcampbell@pingidentity.com
3D"phone" +1 720.317.2061
3D"twitter" @pingidentity
Connect with = us!
3D"pingidentity.com"
=
3D"pingidentity.com"
= 3D"twitter 3D"twitter 3D"youtube 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard= 3D"rss


--
=09 3D"Ping=20
Brian Campbell
Distinguished Engineer
Ping Identity
@ bcampbell@pingidentity.com
3D"phone" +1 720.317.2061
3D"twitter" @pingidentity
Connect with = us!
3D"pingidentity.com"
=
3D"pingidentity.com"
= 3D"twitter 3D"twitter 3D"youtube 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard 3D"rss
_______________________________________________
OAuth = mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


= --Apple-Mail=_9BED1FB8-0183-419B-A9C1-048D2CA108C0-- From nobody Wed Nov 25 10:27:32 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D75761A8A52 for ; Wed, 25 Nov 2015 10:27:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.775 X-Spam-Level: X-Spam-Status: No, score=-4.775 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ycydk7w8DLiK for ; Wed, 25 Nov 2015 10:27:28 -0800 (PST) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D96C01A89C4 for ; Wed, 25 Nov 2015 10:27:27 -0800 (PST) X-AuditID: 12074423-f797f6d0000023d0-df-5655fd8d4b60 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 76.C8.09168.E8DF5565; Wed, 25 Nov 2015 13:27:26 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id tAPIRPcY007252; Wed, 25 Nov 2015 13:27:25 -0500 Received: from artemisia.richer.local (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id tAPIRNBb002878 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 25 Nov 2015 13:27:24 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_F94CB62B-96BB-4659-B60B-3B715F3D5070" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Justin Richer In-Reply-To: <6015EE15-1FEE-43DC-930C-68ACAEDC083E@oracle.com> Date: Wed, 25 Nov 2015 13:27:22 -0500 Message-Id: <38555799-721C-4A2F-AAAA-24D9B69EB72E@mit.edu> References: <20151124200512.20833.28463.idtracker@ietfa.amsl.com> <16FAD3AC-CFB8-46D5-A12E-436E902EA439@oracle.com> <6015EE15-1FEE-43DC-930C-68ACAEDC083E@oracle.com> To: Phil Hunt X-Mailer: Apple Mail (2.2104) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDKsWRmVeSWpSXmKPExsUixG6nrtv3NzTM4Pl9DovV/28yWpx8+4rN YsH8RnYHZo8lS34yeXx8eovF4+7RiywBzFFcNimpOZllqUX6dglcGacbTzEX/N3OVLGq8wJT A+OvCUxdjJwcEgImEjuP7WOHsMUkLtxbz9bFyMUhJLCYSeLCqlYWkISQwEZGifcbUyASD5kk zv6bzQaSYBZIkPjZsowZxOYV0JN4desyK4gtLOAjcfH0EzCbTUBVYvqaFrBtnAJ2Eh1//4MN ZQGKf93cwwgxJ1biU+sbJog5VhINV/YwQyyewCzR+toLxBYRUJH4dvU6I8SlshK7fz9imsAo MAvJGbOQnAER15ZYtvA1M4StKbG/ezkLpriGROe3iawLGNlWMcqm5Fbp5iZm5hSnJusWJyfm 5aUW6Zrp5WaW6KWmlG5iBEeCi/IOxj8HlQ4xCnAwKvHwTngUEibEmlhWXJl7iFGSg0lJlLft QmiYEF9SfkplRmJxRnxRaU5q8SFGCQ5mJRHebR+AcrwpiZVVqUX5MClpDhYlcd65X3zDhATS E0tSs1NTC1KLYLIyHBxKErzMf4AaBYtS01Mr0jJzShDSTBycIMN5gIZXgdTwFhck5hZnpkPk TzEqSonzCoIkBEASGaV5cL2gRJXw9rDpK0ZxoFeEedtAqniASQ6u+xXQYCagwRE5YINLEhFS Ug2MXuY5lmsDdurqSHwoE2tlnb+n1X4Z31Wpu08spxjGexjX/t3Py/HowSOB3iPeksZVzIvl 1+qU8ne/DN0muTI1PqEl4s8PR+sbr2YV3/641dHwr63U/tDfRl2G7etfGUs9Knn/efeyo6Hn lsV1nCtmTy02euhrnhb4/HXUYR732Isvp65dumibEktxRqKhFnNRcSIAc5GZIy8DAAA= Archived-At: Cc: "" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-pop-architecture-06.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2015 18:27:32 -0000 --Apple-Mail=_F94CB62B-96BB-4659-B60B-3B715F3D5070 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Right, I read that as text for describing the examples and not for = describing requirements. The token itself doesn=E2=80=99t have to be signed at all. =E2=80=94 Justin > On Nov 25, 2015, at 1:05 PM, Phil Hunt wrote: >=20 > Ok. Well this was requested by Kathleen because of this paragraph in = Sec 6.=E2=80=A6 >=20 > To simplify the subsequent description we assume in the PoP = architecture > that the token itself is digitally signed by the authorization = server > and therefore cannot be modified. >=20 > Please=20 > Phil >=20 > @independentid > www.independentid.com = phil.hunt@oracle.com = >> On Nov 25, 2015, at 9:33 AM, Justin Richer > wrote: >>=20 >> The token doesn=E2=80=99t have to be signed and the client doesn=E2=80=99= t have to verify the signature on the token. That=E2=80=99s not PoP. The = request has to be signed in a way that includes the token. The token = itself can still be opaque. The *key* material can=E2=80=99t be opaque = to the client, but the *token* material still is. >>=20 >> I agree with Brian that this statement is misleading. >>=20 >> The examples use a signed token but that is absolutely not a = requirement. Maybe the examples shouldn=E2=80=99t all use one style. >>=20 >> What=E2=80=99s most difficult about this particular spec is that = it=E2=80=99s very hand-wavy, saying =E2=80=9Cthis is kinda a thing that = kinda works like this=E2=80=9D without saying how to actually do it. = I=E2=80=99m honestly not sure it=E2=80=99s worth publishing as an RFC in = its own right but I=E2=80=99m not going to stand in its way. >>=20 >> =E2=80=94 Justin >>=20 >>> On Nov 25, 2015, at 12:14 PM, Brian Campbell = > wrote: >>>=20 >>> Where does it say that?=20 >>>=20 >>>=20 >>>=20 >>> On Wed, Nov 25, 2015 at 8:44 AM, Phil Hunt > wrote: >>> Except that later on we require the token be signed and the client = verify that signed token. IOW mutual pop.=20 >>>=20 >>> Phil >>>=20 >>> On Nov 25, 2015, at 07:30, Brian Campbell = > wrote: >>>=20 >>>> Looking at the diff I noticed the following new text, which seems = to conflate bearer/PoP and opaqueness to the client. A client = demonstrating proof-of-possession of some key is orthogonal to the = client being able to parse and understand the access token itself.=20 >>>> =20 >>>> "In contrast to bearer tokens [RFC6750] which call for tokens that = are opaque to OAuth 2.0 clients, this specification defines the = requirements for proof-of-possession ("PoP") tokens that may be parsed = and verified by OAuth 2.0 clients and relying parties." >>>>=20 >>>> On Tue, Nov 24, 2015 at 1:07 PM, Phil Hunt > wrote: >>>> This draft addresses review comments from Kathleen and Erik raised = since the last draft. >>>>=20 >>>> It may not include some of the discussion from yesterday/today. I = will add that as the group decides. >>>>=20 >>>> Cheers, >>>>=20 >>>> Phil >>>>=20 >>>> @independentid >>>> www.independentid.com >>>> phil.hunt@oracle.com >>>>=20 >>>> > On Nov 24, 2015, at 12:05 PM, internet-drafts@ietf.org = wrote: >>>> > >>>> > >>>> > A New Internet-Draft is available from the on-line = Internet-Drafts directories. >>>> > This draft is a work item of the Web Authorization Protocol = Working Group of the IETF. >>>> > >>>> > Title : OAuth 2.0 Proof-of-Possession (PoP) = Security Architecture >>>> > Authors : Phil Hunt >>>> > Justin Richer >>>> > William Mills >>>> > Prateek Mishra >>>> > Hannes Tschofenig >>>> > Filename : draft-ietf-oauth-pop-architecture-06.txt >>>> > Pages : 23 >>>> > Date : 2015-11-24 >>>> > >>>> > Abstract: >>>> > The OAuth 2.0 bearer token specification, as defined in RFC = 6750, >>>> > allows any party in possession of a bearer token (a "bearer") = to get >>>> > access to the associated resources (without demonstrating = possession >>>> > of a cryptographic key). To prevent misuse, bearer tokens must = be >>>> > protected from disclosure in transit and at rest. >>>> > >>>> > Some scenarios demand additional security protection whereby a = client >>>> > needs to demonstrate possession of cryptographic keying = material when >>>> > accessing a protected resource. This document motivates the >>>> > development of the OAuth 2.0 proof-of-possession security = mechanism. >>>> > >>>> > >>>> > The IETF datatracker status page for this draft is: >>>> > = https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architecture/ = >>>> > >>>> > There's also a htmlized version available at: >>>> > https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-06 = >>>> > >>>> > A diff from the previous version is available at: >>>> > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-pop-architecture-06 = = >>>> > >>>> > >>>> > 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 = >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>=20 >>>>=20 >>>>=20 >>>> --=20 >>>> =09 >>>> Brian Campbell >>>> Distinguished Engineer >>>> Ping Identity >>>> @ bcampbell@pingidentity.com >>>> +1 720.317.2061 >>>> @pingidentity >>>> Connect with us! >>>> >>>> = = = = = = = = >>>=20 >>>=20 >>> --=20 >>> =09 >>> Brian Campbell >>> Distinguished Engineer >>> Ping Identity >>> @ bcampbell@pingidentity.com >>> +1 720.317.2061 >>> @pingidentity >>> Connect with us! >>> >>> = = = = = = = = _____________________________________= __________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth = >>=20 >=20 --Apple-Mail=_F94CB62B-96BB-4659-B60B-3B715F3D5070 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Right, I read that as text for describing the examples and = not for describing requirements.

The token itself doesn=E2=80=99t have to be signed at = all.

 =E2=80= =94 Justin

On Nov 25, 2015, at 1:05 PM, = Phil Hunt <phil.hunt@oracle.com> wrote:

Ok. Well this = was requested by Kathleen because of this paragraph in Sec 6.=E2=80=A6

   To =
simplify the subsequent description we assume in the PoP =
architecture
   that =
the token itself is digitally signed by the authorization server

   and therefore cannot =
be modified.

Please 

On Nov 25, 2015, at 9:33 AM, Justin Richer <jricher@mit.edu> = wrote:

The token doesn=E2=80=99= t have to be signed and the client doesn=E2=80=99t have to verify the = signature on the token. That=E2=80=99s not PoP. The request has to be = signed in a way that includes the token. The token itself can still be = opaque. The *key* material can=E2=80=99t be opaque to the client, but = the *token* material still is.

I agree with Brian that this statement is misleading.

The = examples use a signed token but that is absolutely not a requirement. = Maybe the examples shouldn=E2=80=99t all use one style.

What=E2=80=99s most = difficult about this particular spec is that it=E2=80=99s very = hand-wavy, saying =E2=80=9Cthis is kinda a thing that kinda works like = this=E2=80=9D without saying how to actually do it. I=E2=80=99m honestly = not sure it=E2=80=99s worth publishing as an RFC in its own right but = I=E2=80=99m not going to stand in its way.

 =E2=80=94 Justin

On Nov 25, 2015, at 12:14 PM, Brian Campbell = <bcampbell@pingidentity.com> wrote:

Where does it say that?



On Wed, Nov 25, 2015 at 8:44 AM, Phil Hunt <phil.hunt@oracle.com> = wrote:
Except that later on we require the token be = signed and the client verify that signed token. IOW mutual = pop. 

Phil

On Nov 25, 2015, at 07:30, = Brian Campbell <bcampbell@pingidentity.com> = wrote:

Looking at the = diff I noticed the following new text, which seems to conflate = bearer/PoP and opaqueness to the client. A client demonstrating = proof-of-possession of some key is orthogonal to the client being able = to parse and understand the access token itself.
 
"In contrast to bearer tokens [RFC6750] which call for tokens = that are opaque to OAuth 2.0 clients, this specification defines the = requirements for proof-of-possession ("PoP") tokens that may be parsed = and verified by OAuth 2.0 clients and relying parties."

On Tue, Nov 24, 2015 at 1:07 PM, Phil Hunt <phil.hunt@oracle.com> = wrote:
This draft = addresses review comments from Kathleen and Erik raised since the last = draft.

It may not include some of the discussion from yesterday/today.  I = will add that as the group decides.

Cheers,

Phil

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

> On Nov 24, 2015, at 12:05 PM, internet-drafts@ietf.org wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts = directories.
> This draft is a work item of the Web Authorization Protocol Working = Group of the IETF.
>
>        Title          =  : OAuth 2.0 Proof-of-Possession (PoP) Security Architecture
>        Authors        =  : Phil Hunt
>                  =         Justin Richer
>                  =         William Mills
>                  =         Prateek Mishra
>                  =         Hannes Tschofenig
>       Filename        : = draft-ietf-oauth-pop-architecture-06.txt
>       Pages          =  : 23
>       Date          =   : 2015-11-24
>
> Abstract:
>   The OAuth 2.0 bearer token specification, as defined in = RFC 6750,
>   allows any party in possession of a bearer token (a = "bearer") to get
>   access to the associated resources (without = demonstrating possession
>   of a cryptographic key).  To prevent misuse, = bearer tokens must be
>   protected from disclosure in transit and at rest.
>
>   Some scenarios demand additional security protection = whereby a client
>   needs to demonstrate possession of cryptographic keying = material when
>   accessing a protected resource.  This document = motivates the
>   development of the OAuth 2.0 proof-of-possession = security mechanism.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architect= ure/
>
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-0= 6
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-pop-archit= ecture-06
>
>
> 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



--
=09 3D"Ping=20
Brian Campbell
Distinguished Engineer
Ping Identity
@ bcampbell@pingidentity.com
3D"phone" +1 720.317.2061
3D"twitter" @pingidentity
Connect with = us!
3D"pingidentity.com"
=
3D"pingidentity.com"
= 3D"twitter 3D"twitter 3D"youtube 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard= 3D"rss


--
=09 3D"Ping=20
Brian Campbell
Distinguished Engineer
Ping Identity
@ bcampbell@pingidentity.com
3D"phone" +1 720.317.2061
3D"twitter" @pingidentity
Connect with = us!
3D"pingidentity.com"
=
3D"pingidentity.com"
= 3D"twitter 3D"twitter 3D"youtube 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard 3D"rss
_______________________________________________
OAuth = mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



= --Apple-Mail=_F94CB62B-96BB-4659-B60B-3B715F3D5070-- From nobody Wed Nov 25 10:35:49 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 860681A8BB7 for ; Wed, 25 Nov 2015 10:35:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.991 X-Spam-Level: X-Spam-Status: No, score=-1.991 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qk-zIgRT41_u for ; Wed, 25 Nov 2015 10:35:35 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0786.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:786]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 936D51A8AFB for ; Wed, 25 Nov 2015 10:35:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=0FWItjBWOYPaZ7cHyxEHJkHT1m7puaf0xY9tbL30s0A=; b=QJx3gDn66QGU+bVVvhHpdePyJs0ehDYZra0rsOW6ODO1KXca52vFF6ut45/WdqZoE3DvPRSW0IVX7azwO89KHX36A2EFe7hH4v2suW2EImxe0uKDWy/fsZTYvYkFae7RAsy0CGL2VES2UUFTgZ0vIUwUSz/dJNBJ7gmZQzYsJTc= Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB443.namprd03.prod.outlook.com (10.141.141.152) with Microsoft SMTP Server (TLS) id 15.1.331.20; Wed, 25 Nov 2015 18:35:11 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0331.023; Wed, 25 Nov 2015 18:35:11 +0000 From: Mike Jones To: Justin Richer , Phil Hunt Thread-Topic: [OAUTH-WG] I-D Action: draft-ietf-oauth-pop-architecture-06.txt Thread-Index: AQHRJvN1C1MPuLAu4029awXghHgj7p6rmXeAgAFE84CAAAP7AIAAGU2AgAAFLgCAAAkNgIAABgUAgAACL/w= Date: Wed, 25 Nov 2015 18:35:10 +0000 Message-ID: References: <20151124200512.20833.28463.idtracker@ietfa.amsl.com> <16FAD3AC-CFB8-46D5-A12E-436E902EA439@oracle.com> <6015EE15-1FEE-43DC-930C-68ACAEDC083E@oracle.com>, <38555799-721C-4A2F-AAAA-24D9B69EB72E@mit.edu> In-Reply-To: <38555799-721C-4A2F-AAAA-24D9B69EB72E@mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [167.220.63.225] x-microsoft-exchange-diagnostics: 1; BY2PR03MB443; 5:5s2zB4MhiUlBQWDYRNEmFwiKmo0H9qw5przYpYsGRD3tjmjnW4UNyl/18z9RPRYYk7KDILZ2qL104BUmeXB2SeivgCg5lCSeYXiSdah9zyyTsoyVfw0c+UJWv2avSIchfuIylo+8sQxK5rJQvB/4ew==; 24:/VfLJvpxwzyYBoc9JUw171sKwvqu85bRgD62dA3jpK1P9IaHYkEPyfJntcrOJuC6YvWACNTAxMnKkNG4k2+ay3vKm23mHZ16hIzdUefaI9c= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB443; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(211936372134217)(146099531331640); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425024)(601004)(2401047)(8121501046)(5005006)(520078)(10201501046)(3002001)(61426024)(61427024); SRVR:BY2PR03MB443; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB443; x-forefront-prvs: 0771670921 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(24454002)(189002)(377454003)(377424004)(199003)(106356001)(5004730100002)(106116001)(33656002)(86612001)(105586002)(2171001)(19618635001)(230783001)(10090500001)(99286002)(18206015028)(93886004)(122556002)(87936001)(8990500004)(5005710100001)(10290500002)(10400500002)(74316001)(86362001)(5007970100001)(5002640100001)(2900100001)(1220700001)(19273905006)(5003600100002)(15975445007)(2950100001)(19617315012)(77096005)(40100003)(19622755009)(101416001)(50986999)(16236675004)(66066001)(19580395003)(3846002)(102836003)(6116002)(54356999)(586003)(19580405001)(76176999)(97736004)(5001770100001)(11100500001)(15198665003)(5001960100002)(5001920100001)(189998001)(76576001)(5008740100001)(4001150100001)(81156007)(15395725005)(92566002)(7099028)(9984715007)(19622745005)(19625245003); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB443; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR03MB442E907EBD01BD6007233D4F5050BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Nov 2015 18:35:10.8830 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB443 Archived-At: Cc: "" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-pop-architecture-06.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2015 18:35:47 -0000 --_000_BY2PR03MB442E907EBD01BD6007233D4F5050BY2PR03MB442namprd_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Agreed. We need to clarify that the token need not be signed, as that's a = choice that's orthogonal to PoP. -- Mike ________________________________ From: Justin Richer Sent: =FD11/=FD25/=FD2015 10:27 AM To: Phil Hunt Cc: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-pop-architecture-06.tx= t Right, I read that as text for describing the examples and not for describi= ng requirements. The token itself doesn=92t have to be signed at all. =97 Justin On Nov 25, 2015, at 1:05 PM, Phil Hunt > wrote: Ok. Well this was requested by Kathleen because of this paragraph in Sec 6.= =85 To simplify the subsequent description we assume in the PoP architecture that the token itself is digitally signed by the authorization server and therefore cannot be modified. Please Phil @independentid www.independentid.com phil.hunt@oracle.com On Nov 25, 2015, at 9:33 AM, Justin Richer > wrote: The token doesn=92t have to be signed and the client doesn=92t have to veri= fy the signature on the token. That=92s not PoP. The request has to be sign= ed in a way that includes the token. The token itself can still be opaque. = The *key* material can=92t be opaque to the client, but the *token* materia= l still is. I agree with Brian that this statement is misleading. The examples use a signed token but that is absolutely not a requirement. M= aybe the examples shouldn=92t all use one style. What=92s most difficult about this particular spec is that it=92s very hand= -wavy, saying =93this is kinda a thing that kinda works like this=94 withou= t saying how to actually do it. I=92m honestly not sure it=92s worth publis= hing as an RFC in its own right but I=92m not going to stand in its way. =97 Justin On Nov 25, 2015, at 12:14 PM, Brian Campbell > wrote: Where does it say that? On Wed, Nov 25, 2015 at 8:44 AM, Phil Hunt > wrote: Except that later on we require the token be signed and the client verify t= hat signed token. IOW mutual pop. Phil On Nov 25, 2015, at 07:30, Brian Campbell > wrote: Looking at the diff I noticed the following new text, which seems to confla= te bearer/PoP and opaqueness to the client. A client demonstrating proof-of= -possession of some key is orthogonal to the client being able to parse and= understand the access token itself. "In contrast to bearer tokens [RFC6750] which call for tokens that are opaq= ue to OAuth 2.0 clients, this specification defines the requirements for pr= oof-of-possession ("PoP") tokens that may be parsed and verified by OAuth 2= .0 clients and relying parties." On Tue, Nov 24, 2015 at 1:07 PM, Phil Hunt > wrote: This draft addresses review comments from Kathleen and Erik raised since th= e last draft. It may not include some of the discussion from yesterday/today. I will add= that as the group decides. Cheers, Phil @independentid www.independentid.com phil.hunt@oracle.com > On Nov 24, 2015, at 12:05 PM, internet-drafts@ietf.org wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Web Authorization Protocol Working Group= of the IETF. > > Title : OAuth 2.0 Proof-of-Possession (PoP) Security Arc= hitecture > Authors : Phil Hunt > Justin Richer > William Mills > Prateek Mishra > Hannes Tschofenig > Filename : draft-ietf-oauth-pop-architecture-06.txt > Pages : 23 > Date : 2015-11-24 > > Abstract: > The OAuth 2.0 bearer token specification, as defined in RFC 6750, > allows any party in possession of a bearer token (a "bearer") to get > access to the associated resources (without demonstrating possession > of a cryptographic key). To prevent misuse, bearer tokens must be > protected from disclosure in transit and at rest. > > Some scenarios demand additional security protection whereby a client > needs to demonstrate possession of cryptographic keying material when > accessing a protected resource. This document motivates the > development of the OAuth 2.0 proof-of-possession security mechanism. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architecture/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-06 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-pop-architecture-06 > > > Please note that it may take a couple of minutes from the time of submiss= ion > 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 -- [Ping Identity logo] Brian Campbell Distinguished Engineer Ping Identity @ bcampbell@pingidentity.com [phone] +1 720.317.2061 [twitter] @pingidentity Connect with us! [pingidentity.com] [pingidentity.com= ] [twitter logo] [twitter logo] [y= outube logo] [LinkedIn logo]= [Facebook logo] [Google+ logo] [slideshare logo] [flipboard logo] [rss feed icon] -- [Ping Identity logo] Brian Campbell Distinguished Engineer Ping Identity @ bcampbell@pingidentity.com [phone] +1 720.317.2061 [twitter] @pingidentity Connect with us! [pingidentity.com] [pingidentity.com= ] [twitter logo] [twitter logo] [y= outube logo] [LinkedIn logo]= [Facebook logo] [Google+ logo] [slideshare logo] [flipboard logo] [rss feed icon] _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_BY2PR03MB442E907EBD01BD6007233D4F5050BY2PR03MB442namprd_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
Agreed. = We need to clarify that the token need not be signed, as that's a choice t= hat's orthogonal to PoP.

-- Mike
From: Justin Richer
Sent: =FD11= /=FD25/=FD2015 10:27 AM
To: Phil Hunt
Cc: <oauth@ietf.org>
Subject: Re: [= OAUTH-WG] I-D Action: draft-ietf-oauth-pop-architecture-06.txt

Right, I read that as text for describing the examples and not for des= cribing requirements.

The token itself doesn=92t have to be signed at all.

 =97 Justin

On Nov 25, 2015, at 1:05 PM, Phil Hunt <phil.hunt@oracle.com> wrote:
Ok. Well this was requested = by Kathleen because of this paragraph in Sec 6.=85 

   To simplify the subsequent description=
 we assume in the PoP architecture
   that the token itself is digitally sig=
ned by the authorization server

   and therefore cannot be modified.

Please 
Phil

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

On Nov 25, 2015, at 9:33 AM, Justin Richer <jricher@mit.edu> wrote:

The token doesn=92t have to = be signed and the client doesn=92t have to verify the signature on the toke= n. That=92s not PoP. The request has to be signed in a way that includes th= e token. The token itself can still be opaque. The *key* material can=92t be opaque to the client, but the *token* materi= al still is.

I agree with Brian that this statement is misleading.

The examples use a signed token but that is absolutely not = a requirement. Maybe the examples shouldn=92t all use one style.

What=92s most difficult about this particular spec is that = it=92s very hand-wavy, saying =93this is kinda a thing that kinda works lik= e this=94 without saying how to actually do it. I=92m honestly not sure it= =92s worth publishing as an RFC in its own right but I=92m not going to stand in its way.

 =97 Justin

On Nov 25, 2015, at 12:14 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:

Where does it say that?



On Wed, Nov 25, 2015 at 8:44 AM, Phil Hunt <ph= il.hunt@oracle.com> wrote:
Except that later on we require the token be signed and the= client verify that signed token. IOW mutual pop. 

Phil

On Nov 25, 2015, at 07:30, Brian Campbell <bcampbell@pingidentity.com> wrote:

Looking at the diff I noticed the following new= text, which seems to conflate bearer/PoP and opaqueness to the client. A c= lient demonstrating proof-of-possession of some key is orthogonal to the cl= ient being able to parse and understand the access token itself.
 
"In contrast to bearer tokens [RFC6750] which call for tokens that are= opaque to OAuth 2.0 clients, this specification defines the requirements f= or proof-of-possession ("PoP") tokens that may be parsed and veri= fied by OAuth 2.0 clients and relying parties."

On Tue, Nov 24, 2015 at 1:07 PM, Phil Hunt <ph= il.hunt@oracle.com> wrote:
This draft addresses review comments from Kathleen and Erik raised since th= e last draft.

It may not include some of the discussion from yesterday/today.  I wil= l add that as the group decides.

Cheers,

Phil

@independentid
www.independentid.com
phil.h= unt@oracle.com

> On Nov 24, 2015, at 12:05 PM, internet-drafts@ietf.org wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
> This draft is a work item of the Web Authorization Protocol Working Gr= oup of the IETF.
>
>        Title          &nb= sp;: OAuth 2.0 Proof-of-Possession (PoP) Security Architecture
>        Authors         : = Phil Hunt
>                    &= nbsp;     Justin Richer
>                    &= nbsp;     William Mills
>                    &= nbsp;     Prateek Mishra
>                    &= nbsp;     Hannes Tschofenig
>       Filename        : draft-= ietf-oauth-pop-architecture-06.txt
>       Pages          &nbs= p;: 23
>       Date           = ; : 2015-11-24
>
> Abstract:
>   The OAuth 2.0 bearer token specification, as defined in RF= C 6750,
>   allows any party in possession of a bearer token (a "= bearer") to get
>   access to the associated resources (without demonstrating = possession
>   of a cryptographic key).  To prevent misuse, bearer t= okens must be
>   protected from disclosure in transit and at rest.
>
>   Some scenarios demand additional security protection where= by a client
>   needs to demonstrate possession of cryptographic keying ma= terial when
>   accessing a protected resource.  This document motiva= tes the
>   development of the OAuth 2.0 proof-of-possession security = mechanism.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architecture/
>
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-06
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-pop-architecture-06
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> OAuth mailing list
> OAuth@i= etf.org
> https://www.ietf.org/mailman/listinfo/oauth

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



--
3D"Ping=20
Brian Campbell
Distinguished Engineer
Ping Identity
@ bcampbell@pingidentity.com
3D"phone" +1 720.317.2061
3D"twitter" @pingidentity
Connect with us!
3D"pingidentity.com"
3D"pi=
3D"twitter 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard =3D"rss



--
3D"Ping=20
Brian Campbell
Distinguished Engineer
Ping Identity
@ bcampbell@pingidentity.com
3D"phone" +1 720.317.2= 061
3D"twitter" @pingidentity
Connect with us!
3D"pingidentity.com"
3D"pi=
3D"twitter 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard =3D"rss
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://= www.ietf.org/mailman/listinfo/oauth



--_000_BY2PR03MB442E907EBD01BD6007233D4F5050BY2PR03MB442namprd_-- From nobody Wed Nov 25 10:49:09 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E67E1A8BB6 for ; Wed, 25 Nov 2015 10:49:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.368 X-Spam-Level: X-Spam-Status: No, score=-1.368 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ria0spFF-xoK for ; Wed, 25 Nov 2015 10:49:01 -0800 (PST) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20B781A0011 for ; Wed, 25 Nov 2015 10:49:01 -0800 (PST) Received: by igcph11 with SMTP id ph11so99378556igc.1 for ; Wed, 25 Nov 2015 10:49:00 -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:content-type; bh=2s5EUeIiLh4I9Yi9gTic+VsjLCNxIkTdFxu6ZyoGZP8=; b=lZ8OjKB+wsn2k1IgfwDTlrBIj2Fp/cfurCxXDIwp7ntDGqOSV5xB0wflmzvFZ6a4PW LZP/SErOZPat1GF1PObSu4y7kNzVjsYdpFT3jTVapWfRiZbOd5XG9bWpAklYgTvtPddX Dc+GncUqd6CFnqfkOfOI4oXj6eTszd5o5zYZg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=2s5EUeIiLh4I9Yi9gTic+VsjLCNxIkTdFxu6ZyoGZP8=; b=L4BQb6fPUGhiyESCkEHYSfA66UyLlkWnzlE9cZ1MmN6MO8O3eSL78+s7BL4UX2xLkU 9DhweCmwqLAKexq3OVoYWLIBLyPAmGozWtNAQKPX5TWfePIe3osx1bkXsbSPH5FLnMx/ gfWptP3al3/5gYy63ffs4gWc8oEqcYWvfHr1maG4jyMg8gsvOA+SGYKdT9QhVRrNiele +TdOLhTghJVceVTWw+mi3/33VdSXQE7X+aJpcsHrDVYW/1wE4dHp6eMO5u8TbFvfLAXo ZZ1aETd5B3iN8iA1D/fKDC3RxAOvj2gr98AH1KIagC+etv2fnRbgcAbXhCaaC0SN6qVM 58cA== X-Gm-Message-State: ALoCoQnYZmicd53+j45hb8fgnzpmYOCS7X/yzWAc+x7R2rNwWwAWeppRereptGLLGuIWaN1JskoG X-Received: by 10.50.143.5 with SMTP id sa5mr1491915igb.77.1448477340316; Wed, 25 Nov 2015 10:49:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.23.133 with HTTP; Wed, 25 Nov 2015 10:48:30 -0800 (PST) In-Reply-To: <38555799-721C-4A2F-AAAA-24D9B69EB72E@mit.edu> References: <20151124200512.20833.28463.idtracker@ietfa.amsl.com> <16FAD3AC-CFB8-46D5-A12E-436E902EA439@oracle.com> <6015EE15-1FEE-43DC-930C-68ACAEDC083E@oracle.com> <38555799-721C-4A2F-AAAA-24D9B69EB72E@mit.edu> From: Brian Campbell Date: Wed, 25 Nov 2015 11:48:30 -0700 Message-ID: To: Justin Richer Content-Type: multipart/alternative; boundary=001a1134c2e655d3af052561e913 Archived-At: Cc: "" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-pop-architecture-06.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2015 18:49:04 -0000 --001a1134c2e655d3af052561e913 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable While I can't say I disagree with the deeper existential questions about the draft that Justin raises, I was trying not to go there and rather just point out concerns with the newly added text. The text Phil cites from Sec 6 doesn't say the client must be able to parse and verify the token. It's an assumption to simplify the examples that follow and still the token is opaque to the client. I reread the whole draft (reluctantly) and there's nothing that says the token has to be non-opaque to the client. And it does talk about reference style tokens and encrypted tokens, both of which rely on the opaqueness to the client. On Wed, Nov 25, 2015 at 11:27 AM, Justin Richer wrote: > Right, I read that as text for describing the examples and not for > describing requirements. > > The token itself doesn=E2=80=99t have to be signed at all. > > =E2=80=94 Justin > > On Nov 25, 2015, at 1:05 PM, Phil Hunt wrote: > > Ok. Well this was requested by Kathleen because of this paragraph in Sec > 6.=E2=80=A6 > > > To simplify the subsequent description we assume in the PoP architectu= re > > that the token itself is digitally signed by the authorization server > > and therefore cannot be modified. > > > Please > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > On Nov 25, 2015, at 9:33 AM, Justin Richer wrote: > > The token doesn=E2=80=99t have to be signed and the client doesn=E2=80=99= t have to verify > the signature on the token. That=E2=80=99s not PoP. The request has to be= signed in > a way that includes the token. The token itself can still be opaque. The > *key* material can=E2=80=99t be opaque to the client, but the *token* mat= erial > still is. > > I agree with Brian that this statement is misleading. > > The examples use a signed token but that is absolutely not a requirement. > Maybe the examples shouldn=E2=80=99t all use one style. > > What=E2=80=99s most difficult about this particular spec is that it=E2=80= =99s very > hand-wavy, saying =E2=80=9Cthis is kinda a thing that kinda works like th= is=E2=80=9D > without saying how to actually do it. I=E2=80=99m honestly not sure it=E2= =80=99s worth > publishing as an RFC in its own right but I=E2=80=99m not going to stand = in its way. > > =E2=80=94 Justin > > On Nov 25, 2015, at 12:14 PM, Brian Campbell > wrote: > > Where does it say that? > > > > On Wed, Nov 25, 2015 at 8:44 AM, Phil Hunt wrote: > >> Except that later on we require the token be signed and the client verif= y >> that signed token. IOW mutual pop. >> >> Phil >> >> On Nov 25, 2015, at 07:30, Brian Campbell >> wrote: >> >> Looking at the diff I noticed the following new text, which seems to >> conflate bearer/PoP and opaqueness to the client. A client demonstrating >> proof-of-possession of some key is orthogonal to the client being able t= o >> parse and understand the access token itself. >> >> "In contrast to bearer tokens [RFC6750] which call for tokens that are >> opaque to OAuth 2.0 clients, this specification defines the requirements >> for proof-of-possession ("PoP") tokens that may be parsed and verified b= y >> OAuth 2.0 clients and relying parties." >> >> On Tue, Nov 24, 2015 at 1:07 PM, Phil Hunt wrote: >> >>> This draft addresses review comments from Kathleen and Erik raised sinc= e >>> the last draft. >>> >>> It may not include some of the discussion from yesterday/today. I will >>> add that as the group decides. >>> >>> Cheers, >>> >>> Phil >>> >>> @independentid >>> www.independentid.com >>> phil.hunt@oracle.com >>> >>> > On Nov 24, 2015, at 12:05 PM, internet-drafts@ietf.org wrote: >>> > >>> > >>> > A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> > This draft is a work item of the Web Authorization Protocol Working >>> Group of the IETF. >>> > >>> > Title : OAuth 2.0 Proof-of-Possession (PoP) Security >>> Architecture >>> > Authors : Phil Hunt >>> > Justin Richer >>> > William Mills >>> > Prateek Mishra >>> > Hannes Tschofenig >>> > Filename : draft-ietf-oauth-pop-architecture-06.txt >>> > Pages : 23 >>> > Date : 2015-11-24 >>> > >>> > Abstract: >>> > The OAuth 2.0 bearer token specification, as defined in RFC 6750, >>> > allows any party in possession of a bearer token (a "bearer") to ge= t >>> > access to the associated resources (without demonstrating possessio= n >>> > of a cryptographic key). To prevent misuse, bearer tokens must be >>> > protected from disclosure in transit and at rest. >>> > >>> > Some scenarios demand additional security protection whereby a clie= nt >>> > needs to demonstrate possession of cryptographic keying material wh= en >>> > accessing a protected resource. This document motivates the >>> > development of the OAuth 2.0 proof-of-possession security mechanism= . >>> > >>> > >>> > The IETF datatracker status page for this draft is: >>> > https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architecture/ >>> > >>> > There's also a htmlized version available at: >>> > https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-06 >>> > >>> > A diff from the previous version is available at: >>> > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-pop-architecture= -06 >>> > >>> > >>> > 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 >>> >> >> >> >> -- >> [image: Ping Identity logo] >> Brian Campbell >> Distinguished Engineer >> Ping Identity >> @ bcampbell@pingidentity.com [image: phone] +1 720.317.2061 [image: >> twitter] @pingidentity Connect with us! >> [image: pingidentity.com] >> >> [image: >> pingidentity.com] >> >> [image: twitter logo] >> [image: >> twitter logo] [image: youtube logo] >> [image: LinkedIn logo] >> [image: Facebook logo] >> [image: Google+ logo] >> [image: slideshare >> logo] [image: flipboard logo] >> [image: rss feed icon] >> >> >> > > > -- > [image: Ping Identity logo] > Brian Campbell > Distinguished Engineer > Ping Identity > @ bcampbell@pingidentity.com [image: phone] +1 720.317.2061 [image: > twitter] @pingidentity Connect with us! > [image: pingidentity.com] > > [image: > pingidentity.com] > > [image: twitter logo] > [image: > twitter logo] [image: youtube logo] > [image: LinkedIn logo] > [image: Facebook logo] > [image: Google+ logo] > [image: slideshare > logo] [image: flipboard logo] > [image: rss feed icon] > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > --=20 [image: Ping Identity logo] Brian Campbell Distinguished Engineer Ping Identity @ bcampbell@pingidentity.com [image: phone] +1 720.317.2061 [image: twitter= ] @pingidentity Connect with us! [image: pingidentity.com] [image: pingidentity.com] [image: twitter logo] [image: twitter logo] [image: youtube logo] [image: LinkedIn logo] [image: Facebook logo] [image: Google+ logo] [image: slideshare logo= ] [image: flipboard logo] [image: rss feed icon] --001a1134c2e655d3af052561e913 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
While I can't say I disagree with the deeper= existential questions about the draft that Justin raises, I was trying not= to go there and rather just point out concerns with the newly added text. =

The text Phil cites from Sec 6 doesn't say the client mus= t be able to parse and verify the token. It's an assumption to simplify= the examples that follow and still the token is opaque to the client. I re= read the whole draft (reluctantly) and there's nothing that says the to= ken has to be non-opaque to the client. And it does talk about reference st= yle tokens and encrypted tokens, both of which rely on the opaqueness to th= e client.

On Wed, Nov 25, 2015 at 11:27 AM, Justin Richer = <jricher@mit.edu> wrote:
Right, I read that as text for describing the examples and n= ot for describing requirements.

The token itself doesn= =E2=80=99t have to be signed at all.

=C2=A0=E2=80=94 Justin


Ok. Well this was requested by Kathleen= because of this paragraph in Sec 6.=E2=80=A6
On Nov 25, 2015, at 9:33 AM, Justin= Richer <jricher@mi= t.edu> wrote:

The = token doesn=E2=80=99t have to be signed and the client doesn=E2=80=99t have= to verify the signature on the token. That=E2=80=99s not PoP. The request = has to be signed in a way that includes the token. The token itself can sti= ll be opaque. The *key* material can=E2=80=99t be opaque to the client, but= the *token* material still is.

I agree with Brian that = this statement is misleading.

The examples use a sig= ned token but that is absolutely not a requirement. Maybe the examples shou= ldn=E2=80=99t all use one style.

What=E2=80=99s mo= st difficult about this particular spec is that it=E2=80=99s very hand-wavy= , saying =E2=80=9Cthis is kinda a thing that kinda works like this=E2=80=9D= without saying how to actually do it. I=E2=80=99m honestly not sure it=E2= =80=99s worth publishing as an RFC in its own right but I=E2=80=99m not goi= ng to stand in its way.

=C2=A0=E2=80=94 Justin

On Nov 25, 2015, at 12:14 PM= , Brian Campbell <bcampbell@pingidentity.com> wrote:

Where does it say that?



On Wed, Nov 25, 2015 at 8:44 AM, Phil Hu= nt <phil.hunt@oracle.com> wrote:
Except that later on we require the token = be signed and the client verify that signed token. IOW mutual pop.=C2=A0

Phil
<= br>On Nov 25, 2015, at 07:30, Brian Campbell <bcampbell@pingidentity.com> wr= ote:

Looking a= t the diff I noticed the following new text, which seems to conflate bearer= /PoP and opaqueness to the client. A client demonstrating proof-of-possessi= on of some key is orthogonal to the client being able to parse and understa= nd the access token itself.
=C2=A0
"In contrast to bearer token= s [RFC6750] which call for tokens that are opaque to OAuth 2.0 clients, thi= s specification defines the requirements for proof-of-possession ("PoP= ") tokens that may be parsed and verified by OAuth 2.0 clients and rel= ying parties."

On Tue, Nov 24, 2015 at 1:07 PM, Phil Hunt &l= t;phil.hunt@oracl= e.com> wrote:
This draft ad= dresses review comments from Kathleen and Erik raised since the last draft.=

It may not include some of the discussion from yesterday/today.=C2=A0 I wil= l add that as the group decides.

Cheers,

Phil

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

> On Nov 24, 2015, at 12:05 PM, internet-drafts@ietf.org wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
> This draft is a work item of the Web Authorization Protocol Working Gr= oup of the IETF.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: OAuth 2.0 Proof-of-Possession (PoP) Security Architecture
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: = Phil Hunt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Justin Richer
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 William Mills
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Prateek Mishra
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Hannes Tschofenig
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-= ietf-oauth-pop-architecture-06.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: 23
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : 2015-11-24
>
> Abstract:
>=C2=A0 =C2=A0The OAuth 2.0 bearer token specification, as defined in RF= C 6750,
>=C2=A0 =C2=A0allows any party in possession of a bearer token (a "= bearer") to get
>=C2=A0 =C2=A0access to the associated resources (without demonstrating = possession
>=C2=A0 =C2=A0of a cryptographic key).=C2=A0 To prevent misuse, bearer t= okens must be
>=C2=A0 =C2=A0protected from disclosure in transit and at rest.
>
>=C2=A0 =C2=A0Some scenarios demand additional security protection where= by a client
>=C2=A0 =C2=A0needs to demonstrate possession of cryptographic keying ma= terial when
>=C2=A0 =C2=A0accessing a protected resource.=C2=A0 This document motiva= tes the
>=C2=A0 =C2=A0development of the OAuth 2.0 proof-of-possession security = mechanism.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org= /doc/draft-ietf-oauth-pop-architecture/
>
> There's also a htmlized version available at:
> https://tools.ietf.org/html/dra= ft-ietf-oauth-pop-architecture-06
>
> A diff from the previous version is available at:
> https://www.ietf.org/rf= cdiff?url2=3Ddraft-ietf-oauth-pop-architecture-06
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org.<= br> >
> 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



--
=09 3D"Ping=20
Brian Campbell
Distinguished Engineer
Ping Identity
@<= /td> <= span style=3D"text-decoration:none;font-family:arial,helvetica,sans-serif;f= ont-weight:normal;font-size:14px;padding:0px 0px 0px 3px">bcampbell@pingidentity.com
3D"phone" <= span style=3D"font-family:arial,helvetica,sans-serif;font-weight:normal;fon= t-size:14px;padding:0px 0px 0px 3px">+1 720.317.2061
3D"twitter" <= span style=3D"font-family:arial,helvetica,sans-serif;font-weight:normal;fon= t-size:14px;padding:0px 0px 0px 3px">@pingidentity
Connect with us!
3D"pingidentity.com"
3D"pingidentity.com" 3D"twitter 3D"twitter 3D"youtube 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard 3D"rss



--
=09 3D"Ping=20
Brian Campbell
Distinguished Engineer
Ping Identity
@<= /td> <= span style=3D"text-decoration:none;font-family:arial,helvetica,sans-serif;f= ont-weight:normal;font-size:14px;padding:0px 0px 0px 3px">bcampbell@pingidentity.com
3D"phone" <= span style=3D"font-family:arial,helvetica,sans-serif;font-weight:normal;fon= t-size:14px;padding:0px 0px 0px 3px">+1 720.317.2061
3D"twitter" <= span style=3D"font-family:arial,helvetica,sans-serif;font-weight:normal;fon= t-size:14px;padding:0px 0px 0px 3px">@pingidentity
Connect with us!
3D"pingidentity.com"
3D"pingidentity.com" 3D"twitter 3D"twitter 3D"youtube 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard 3D"rss
_______________________________________________
OAuth mailing list
OAuth@ietf.org
http= s://www.ietf.org/mailman/listinfo/oauth





--
=09 =3D"Ping=20
Brian Campbell
Distinguished Engineer
Ping Identity
@<= /td> <= span style=3D"text-decoration:none;color:#000000;font-family:arial,helvetic= a,sans-serif;font-weight:normal;font-size:14px;padding:0 0 0 3px">bcampbell@pingiden= tity.com
3D"phone" <= span style=3D"color:#000000;font-family:arial,helvetica,sans-serif;font-wei= ght:normal;font-size:14px;padding:0 0 0 3px">+1 720.317.2061
3D"twitter" <= span style=3D"color:#000000;font-family:arial,helvetica,sans-serif;font-wei= ght:normal;font-size:14px;padding:0 0 0 3px">@pingidentity
Connect with us!
3D"pingidentity.com"
3D"pingidentity.com"
3D"twitter 3D"twitter 3D"youtube 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard 3D"rss
--001a1134c2e655d3af052561e913-- From nobody Wed Nov 25 11:03:19 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2258B1ACE6E for ; Wed, 25 Nov 2015 11:03:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.775 X-Spam-Level: X-Spam-Status: No, score=-4.775 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2xrTe6u2rv-0 for ; Wed, 25 Nov 2015 11:03:15 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEFC11ACDCD for ; Wed, 25 Nov 2015 11:03:14 -0800 (PST) Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id tAPJ3DOL019460 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 25 Nov 2015 19:03:13 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id tAPJ3DnE023393 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 25 Nov 2015 19:03:13 GMT Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id tAPJ3C7V024218; Wed, 25 Nov 2015 19:03:12 GMT Received: from [10.0.1.22] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 25 Nov 2015 11:03:11 -0800 Content-Type: multipart/alternative; boundary="Apple-Mail=_CDDBAEC6-94BB-4501-B619-0E43221FF921" Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Phil Hunt In-Reply-To: Date: Wed, 25 Nov 2015 11:03:09 -0800 Message-Id: <1AD1F44B-9837-4288-9997-5292F1DBE30E@oracle.com> References: <20151124200512.20833.28463.idtracker@ietfa.amsl.com> <16FAD3AC-CFB8-46D5-A12E-436E902EA439@oracle.com> <6015EE15-1FEE-43DC-930C-68ACAEDC083E@oracle.com> <38555799-721C-4A2F-AAAA-24D9B69EB72E@mit.edu> To: Brian Campbell X-Mailer: Apple Mail (2.3096.5) X-Source-IP: aserv0021.oracle.com [141.146.126.233] Archived-At: Cc: "" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-pop-architecture-06.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2015 19:03:19 -0000 --Apple-Mail=_CDDBAEC6-94BB-4501-B619-0E43221FF921 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Folks,=20 I did not want to go here either. :-) I don=E2=80=99t read sec 6 as examples. I believe this may stem from = the pop-architecture documents having a dual role as both = =E2=80=9Carchitecture=E2=80=9D and =E2=80=9Cuse-case=E2=80=9D. Maybe we = should clarify the purpose of the document? I believe section 6 is talking about threat mitigation assumptions based = on the examples that need to be implemented. I am assuming these are = requirements that the other specifications SHOULD implement. I do not believe we have discussed Opaque PoP tokens and any inherent = risks because the client is not or is unable to validate the = authenticity of the token. Does this introduce the possibility of a = MITM attack where a client can be convinced to sign requests for an = attacker? If we want to include opaque PoP, I think we need to take a pause and = consider / discuss any threats here. I find the desire for opaque PoP tokens to be a bit contradictory. If = we=E2=80=99re saying we don=E2=80=99t want to trust TLS alone (e.g. = because of load-balancer termination), why would we then say, but we are = perfectly willing to accept it worked for the OAuth AS exchanges? Maybe = I was very wrong here, but my assumption all along is that for PoP = we=E2=80=99re talking about end-to-end authentication of all parties = except in the case of 3.3 where we simply want to protect an access = token over a non-TLS HTTP connection. Phil @independentid www.independentid.com phil.hunt@oracle.com > On Nov 25, 2015, at 10:48 AM, Brian Campbell = wrote: >=20 > While I can't say I disagree with the deeper existential questions = about the draft that Justin raises, I was trying not to go there and = rather just point out concerns with the newly added text.=20 >=20 > The text Phil cites from Sec 6 doesn't say the client must be able to = parse and verify the token. It's an assumption to simplify the examples = that follow and still the token is opaque to the client. I reread the = whole draft (reluctantly) and there's nothing that says the token has to = be non-opaque to the client. And it does talk about reference style = tokens and encrypted tokens, both of which rely on the opaqueness to the = client.=20 >=20 > On Wed, Nov 25, 2015 at 11:27 AM, Justin Richer > wrote: > Right, I read that as text for describing the examples and not for = describing requirements. >=20 > The token itself doesn=E2=80=99t have to be signed at all. >=20 > =E2=80=94 Justin >=20 >> On Nov 25, 2015, at 1:05 PM, Phil Hunt > wrote: >>=20 >> Ok. Well this was requested by Kathleen because of this paragraph in = Sec 6.=E2=80=A6 >>=20 >> To simplify the subsequent description we assume in the PoP = architecture >> that the token itself is digitally signed by the authorization = server >> and therefore cannot be modified. >>=20 >> Please=20 >> Phil >>=20 >> @independentid >> www.independentid.com = phil.hunt@oracle.com = >>> On Nov 25, 2015, at 9:33 AM, Justin Richer > wrote: >>>=20 >>> The token doesn=E2=80=99t have to be signed and the client doesn=E2=80= =99t have to verify the signature on the token. That=E2=80=99s not PoP. = The request has to be signed in a way that includes the token. The token = itself can still be opaque. The *key* material can=E2=80=99t be opaque = to the client, but the *token* material still is. >>>=20 >>> I agree with Brian that this statement is misleading. >>>=20 >>> The examples use a signed token but that is absolutely not a = requirement. Maybe the examples shouldn=E2=80=99t all use one style. >>>=20 >>> What=E2=80=99s most difficult about this particular spec is that = it=E2=80=99s very hand-wavy, saying =E2=80=9Cthis is kinda a thing that = kinda works like this=E2=80=9D without saying how to actually do it. = I=E2=80=99m honestly not sure it=E2=80=99s worth publishing as an RFC in = its own right but I=E2=80=99m not going to stand in its way. >>>=20 >>> =E2=80=94 Justin >>>=20 >>>> On Nov 25, 2015, at 12:14 PM, Brian Campbell = > wrote: >>>>=20 >>>> Where does it say that?=20 >>>>=20 >>>>=20 >>>>=20 >>>> On Wed, Nov 25, 2015 at 8:44 AM, Phil Hunt > wrote: >>>> Except that later on we require the token be signed and the client = verify that signed token. IOW mutual pop.=20 >>>>=20 >>>> Phil >>>>=20 >>>> On Nov 25, 2015, at 07:30, Brian Campbell = > wrote: >>>>=20 >>>>> Looking at the diff I noticed the following new text, which seems = to conflate bearer/PoP and opaqueness to the client. A client = demonstrating proof-of-possession of some key is orthogonal to the = client being able to parse and understand the access token itself.=20 >>>>> =20 >>>>> "In contrast to bearer tokens [RFC6750] which call for tokens that = are opaque to OAuth 2.0 clients, this specification defines the = requirements for proof-of-possession ("PoP") tokens that may be parsed = and verified by OAuth 2.0 clients and relying parties." >>>>>=20 >>>>> On Tue, Nov 24, 2015 at 1:07 PM, Phil Hunt > wrote: >>>>> This draft addresses review comments from Kathleen and Erik raised = since the last draft. >>>>>=20 >>>>> It may not include some of the discussion from yesterday/today. I = will add that as the group decides. >>>>>=20 >>>>> Cheers, >>>>>=20 >>>>> Phil >>>>>=20 >>>>> @independentid >>>>> www.independentid.com >>>>> phil.hunt@oracle.com >>>>>=20 >>>>> > On Nov 24, 2015, at 12:05 PM, internet-drafts@ietf.org = wrote: >>>>> > >>>>> > >>>>> > A New Internet-Draft is available from the on-line = Internet-Drafts directories. >>>>> > This draft is a work item of the Web Authorization Protocol = Working Group of the IETF. >>>>> > >>>>> > Title : OAuth 2.0 Proof-of-Possession (PoP) = Security Architecture >>>>> > Authors : Phil Hunt >>>>> > Justin Richer >>>>> > William Mills >>>>> > Prateek Mishra >>>>> > Hannes Tschofenig >>>>> > Filename : draft-ietf-oauth-pop-architecture-06.txt >>>>> > Pages : 23 >>>>> > Date : 2015-11-24 >>>>> > >>>>> > Abstract: >>>>> > The OAuth 2.0 bearer token specification, as defined in RFC = 6750, >>>>> > allows any party in possession of a bearer token (a "bearer") = to get >>>>> > access to the associated resources (without demonstrating = possession >>>>> > of a cryptographic key). To prevent misuse, bearer tokens = must be >>>>> > protected from disclosure in transit and at rest. >>>>> > >>>>> > Some scenarios demand additional security protection whereby a = client >>>>> > needs to demonstrate possession of cryptographic keying = material when >>>>> > accessing a protected resource. This document motivates the >>>>> > development of the OAuth 2.0 proof-of-possession security = mechanism. >>>>> > >>>>> > >>>>> > The IETF datatracker status page for this draft is: >>>>> > = https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architecture/ = >>>>> > >>>>> > There's also a htmlized version available at: >>>>> > https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-06 = >>>>> > >>>>> > A diff from the previous version is available at: >>>>> > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-pop-architecture-06 = = >>>>> > >>>>> > >>>>> > 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 = >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>>=20 >>>>>=20 >>>>>=20 >>>>> --=20 >>>>> =09 >>>>> Brian Campbell >>>>> Distinguished Engineer >>>>> Ping Identity >>>>> @ bcampbell@pingidentity.com >>>>> +1 720.317.2061 >>>>> @pingidentity >>>>> Connect with us! >>>>> >>>>> = = = = = = = = >>>>=20 >>>>=20 >>>> --=20 >>>> =09 >>>> Brian Campbell >>>> Distinguished Engineer >>>> Ping Identity >>>> @ bcampbell@pingidentity.com >>>> +1 720.317.2061 >>>> @pingidentity >>>> Connect with us! >>>> >>>> = = = = = = = = _____________________________________= __________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth = >>>=20 >>=20 >=20 >=20 >=20 >=20 > --=20 > =09 > Brian Campbell > Distinguished Engineer > Ping Identity > @ bcampbell@pingidentity.com > +1 720.317.2061 > @pingidentity > Connect with us! > > = = = = = = = = --Apple-Mail=_CDDBAEC6-94BB-4501-B619-0E43221FF921 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Folks, 

<editor hat>
I did not want to go = here either. :-)

I don=E2=80=99t read sec 6 as examples.  I believe this = may stem from the pop-architecture documents having a dual role as both = =E2=80=9Carchitecture=E2=80=9D and =E2=80=9Cuse-case=E2=80=9D. =  Maybe we should clarify the purpose of the document?

I believe section 6 is = talking about threat mitigation assumptions based on the examples that = need to be implemented.  I am assuming these are requirements that = the other specifications SHOULD implement.

<personal hat>
I do not believe we have discussed Opaque PoP tokens and any = inherent risks because the client is not or is unable to validate the = authenticity of the token.  Does this introduce the possibility of = a MITM attack where a client can be convinced to sign requests for an = attacker?

If = we want to include opaque PoP, I think we need to take a pause and = consider / discuss any threats here.

I find the desire for opaque PoP tokens = to be a bit contradictory. If we=E2=80=99re saying we don=E2=80=99t want = to trust TLS alone (e.g. because of load-balancer termination), why = would we then say, but we are perfectly willing to accept it worked for = the OAuth AS exchanges?  Maybe I was very wrong here, but my = assumption all along is that for PoP we=E2=80=99re talking about = end-to-end authentication of all parties except in the case of 3.3 where = we simply want to protect an access token over a non-TLS HTTP = connection.



On Nov 25, 2015, at 10:48 AM, Brian Campbell <bcampbell@pingidentity.com> wrote:

While I can't say I disagree = with the deeper existential questions about the draft that Justin = raises, I was trying not to go there and rather just point out concerns = with the newly added text.

The text = Phil cites from Sec 6 doesn't say the client must be able to parse and = verify the token. It's an assumption to simplify the examples that = follow and still the token is opaque to the client. I reread the whole = draft (reluctantly) and there's nothing that says the token has to be = non-opaque to the client. And it does talk about reference style tokens = and encrypted tokens, both of which rely on the opaqueness to the = client.

On Wed, Nov 25, 2015 at 11:27 AM, = Justin Richer <jricher@mit.edu> wrote:
Right, I read that as text for describing the examples and = not for describing requirements.

The token itself doesn=E2=80=99t have to be signed at = all.

 =E2=80=94 = Justin

On Nov 25, 2015, at 1:05 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

Ok. Well this was = requested by Kathleen because of this paragraph in Sec 6.=E2=80=A6

   =
To simplify the subsequent description we assume in the PoP =
architecture
   =
that the token itself is digitally signed by the authorization server

   and therefore cannot be modified.

Please 

On Nov 25, 2015, at 9:33 AM, Justin Richer <jricher@mit.edu> wrote:

The token = doesn=E2=80=99t have to be signed and the client doesn=E2=80=99t have to = verify the signature on the token. That=E2=80=99s not PoP. The request = has to be signed in a way that includes the token. The token itself can = still be opaque. The *key* material can=E2=80=99t be opaque to the = client, but the *token* material still is.

I agree with Brian that this statement = is misleading.

The examples use a signed token but that is absolutely not a = requirement. Maybe the examples shouldn=E2=80=99t all use one = style.

What=E2=80= =99s most difficult about this particular spec is that it=E2=80=99s very = hand-wavy, saying =E2=80=9Cthis is kinda a thing that kinda works like = this=E2=80=9D without saying how to actually do it. I=E2=80=99m honestly = not sure it=E2=80=99s worth publishing as an RFC in its own right but = I=E2=80=99m not going to stand in its way.

 =E2=80=94 Justin

On Nov 25, 2015, at 12:14 PM, Brian Campbell = <bcampbell@pingidentity.com> wrote:

Where does it say = that?



On Wed, = Nov 25, 2015 at 8:44 AM, Phil Hunt <phil.hunt@oracle.com> wrote:
Except that later on we require the token be = signed and the client verify that signed token. IOW mutual = pop. 

Phil

On Nov 25, 2015, at 07:30, = Brian Campbell <bcampbell@pingidentity.com> = wrote:

Looking at the = diff I noticed the following new text, which seems to conflate = bearer/PoP and opaqueness to the client. A client demonstrating = proof-of-possession of some key is orthogonal to the client being able = to parse and understand the access token itself.
 
"In contrast to bearer tokens [RFC6750] which call for tokens = that are opaque to OAuth 2.0 clients, this specification defines the = requirements for proof-of-possession ("PoP") tokens that may be parsed = and verified by OAuth 2.0 clients and relying parties."

On Tue, Nov 24, 2015 at 1:07 PM, Phil Hunt <phil.hunt@oracle.com> = wrote:
This draft = addresses review comments from Kathleen and Erik raised since the last = draft.

It may not include some of the discussion from yesterday/today.  I = will add that as the group decides.

Cheers,

Phil

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

> On Nov 24, 2015, at 12:05 PM, internet-drafts@ietf.org wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts = directories.
> This draft is a work item of the Web Authorization Protocol Working = Group of the IETF.
>
>        Title          =  : OAuth 2.0 Proof-of-Possession (PoP) Security Architecture
>        Authors        =  : Phil Hunt
>                  =         Justin Richer
>                  =         William Mills
>                  =         Prateek Mishra
>                  =         Hannes Tschofenig
>       Filename        : = draft-ietf-oauth-pop-architecture-06.txt
>       Pages          =  : 23
>       Date          =   : 2015-11-24
>
> Abstract:
>   The OAuth 2.0 bearer token specification, as defined in = RFC 6750,
>   allows any party in possession of a bearer token (a = "bearer") to get
>   access to the associated resources (without = demonstrating possession
>   of a cryptographic key).  To prevent misuse, = bearer tokens must be
>   protected from disclosure in transit and at rest.
>
>   Some scenarios demand additional security protection = whereby a client
>   needs to demonstrate possession of cryptographic keying = material when
>   accessing a protected resource.  This document = motivates the
>   development of the OAuth 2.0 proof-of-possession = security mechanism.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architect= ure/
>
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-0= 6
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-pop-archit= ecture-06
>
>
> 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



--
=09 3D"Ping=20
Brian Campbell
Distinguished Engineer
Ping = Identity
@ bcampbell@pingidentity.com
3D"phone" +1 720.317.2061
3D"twitter" @pingidentity
Connect with = us!
3D"pingidentity.com"
=
3D"pingidentity.com"
= 3D"twitter 3D"twitter 3D"youtube 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard= 3D"rss


--
=09 3D"Ping=20
Brian Campbell
Distinguished Engineer
Ping = Identity
@ bcampbell@pingidentity.com
3D"phone" +1 720.317.2061
3D"twitter" @pingidentity
Connect with = us!
3D"pingidentity.com"
=
3D"pingidentity.com"
= 3D"twitter 3D"twitter 3D"youtube 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard= 3D"rss
_______________________________________________
OAuth = mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth






--
=09 3D"Ping=20
Brian Campbell
Distinguished Engineer
Ping Identity
@ bcampbell@pingidentity.com
3D"phone" +1 720.317.2061
3D"twitter" @pingidentity
Connect with = us!
3D"pingidentity.com"
=
3D"pingidentity.com"
= 3D"twitter 3D"twitter 3D"youtube 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard 3D"rss

= --Apple-Mail=_CDDBAEC6-94BB-4501-B619-0E43221FF921-- From nobody Wed Nov 25 11:24:32 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EE5D1B2D08 for ; Wed, 25 Nov 2015 11:24:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.785 X-Spam-Level: X-Spam-Status: No, score=-4.785 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y4E_gbhpTooa for ; Wed, 25 Nov 2015 11:24:25 -0800 (PST) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E39E1B2D03 for ; Wed, 25 Nov 2015 11:24:25 -0800 (PST) X-AuditID: 1209190d-f79306d000006b70-23-56560ae7b8d5 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 6B.C2.27504.7EA06565; Wed, 25 Nov 2015 14:24:23 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id tAPJOMRC021697; Wed, 25 Nov 2015 14:24:22 -0500 Received: from artemisia.richer.local (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id tAPJOKbI023968 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 25 Nov 2015 14:24:21 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_5FD75B8C-A10D-4381-8228-3BD6709B90B0" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Justin Richer In-Reply-To: <1AD1F44B-9837-4288-9997-5292F1DBE30E@oracle.com> Date: Wed, 25 Nov 2015 14:24:20 -0500 Message-Id: References: <20151124200512.20833.28463.idtracker@ietfa.amsl.com> <16FAD3AC-CFB8-46D5-A12E-436E902EA439@oracle.com> <6015EE15-1FEE-43DC-930C-68ACAEDC083E@oracle.com> <38555799-721C-4A2F-AAAA-24D9B69EB72E@mit.edu> <1AD1F44B-9837-4288-9997-5292F1DBE30E@oracle.com> To: Phil Hunt X-Mailer: Apple Mail (2.2104) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLKsWRmVeSWpSXmKPExsUixCmqrfucKyzM4Gu/sMXq/zcZLU6+fcVm sWB+I7sDs8eSJT+ZPD4+vcXicffoRZYA5igum5TUnMyy1CJ9uwSujJVXLQpu9LBUXLvSzdTA uPUscxcjJ4eEgIlE04ZWNghbTOLCvfVANheHkMBiJokFz5dDORsZJd5ce8cE4TxkkujdcIER pIVZIEHi2IrLYDavgJ7Eq1uXWUFsYQEfiYunn4DZbAKqEtPXtDCB2JwCdhIvP2xjAbFZgOIr 7zYyQcyJlfjU+oYJYo6VxK2NC5ghlm1jkfj/4SrYAhEBFYlvV68zQtwqK7H79yOmCYwCs5Dc MQvJHRBxbYllC18zQ9iaEvu7l7NgimtIdH6byLqAkW0Vo2xKbpVubmJmTnFqsm5xcmJeXmqR rpFebmaJXmpK6SZGcCxI8u5gfHdQ6RCjAAejEg/vhEchYUKsiWXFlbmHGCU5mJREeS05wsKE +JLyUyozEosz4otKc1KLDzFKcDArifBu+xAaJsSbklhZlVqUD5OS5mBREued+8U3TEggPbEk NTs1tSC1CCYrw8GhJMEbB4x5IcGi1PTUirTMnBKENBMHJ8hwHqDhGpxANbzFBYm5xZnpEPlT jIpS4rxvQRICIImM0jy4XlCqSnh72PQVozjQK8K8aSAreIBpDq77FdBgJqDBETkgVxeXJCKk pBoY1RZaO1k8edGyfNmhbRv//bX8tbM56TqzmkfjEgVnT5YjiVVnZ1h690ns+/9SVMFqwd3T FjMn/Z5vzex6yEf0ns/Cw++TDj3cwh5TaNF2blHkP31zV+dun97AjxdP6Rleeeaknvf2UHRp 57N/bO8v79Vr2PJFk9l//6l7txi4574+IKp80f9pixJLcUaioRZzUXEiAA1LhgAwAwAA Archived-At: Cc: "" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-pop-architecture-06.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2015 19:24:31 -0000 --Apple-Mail=_5FD75B8C-A10D-4381-8228-3BD6709B90B0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 It is still end to end authentication with opaque tokens =E2=80=94 since = all OAuth tokens, including PoP tokens, have always been intended to be = opaque to the client. That hasn=E2=80=99t changed and that isn=E2=80=99t = the intent of this document. If that=E2=80=99s how people are reading it = then we need to pull it back and rewrite it so that=E2=80=99s not the = case. The client gets a token that has two parts: the token and the key. The = token is analogous to the access_token we have today and would come out = of the server in the same field. The key is handed to the client = alongside the token or registered by the client during the token = request. Either way there=E2=80=99s an association between the two but = it=E2=80=99s not the same association as a public/private keypair.=20 It=E2=80=99s possible to sign the token itself, but the client doesn=E2=80= =99t care. It sends the token and signs the HTTP request to the RS = whether the token is signed, unsigned, hex blob, encrypted, or anything = else. The same series of options are available as with bearer tokens. = PoP tokens have never, ever been intended to be anything but opaque to = the client. The token can=E2=80=99t be opaque to the RS, which has to figure out = what key to use to check the message signature. But we=E2=80=99ve got = options there, like the embedded key in a JWT from Mike=E2=80=99s draft, = or doing introspection to get the key (from an extension that hasn=E2=80=99= t been written yet), or simply looking it up in the same database = because the RS and the AS are in the same box. Does this = structure/service/database choice sound familiar? It should, it=E2=80=99s = the same as bearer tokens. This is also how the RS gets information like = which scopes are associated with the token, if it=E2=80=99s expired, and = all that.=20 So here=E2=80=99s how I see it going on the wire: (I just wrote this up so there are probably holes. Here=E2=80=99s the = source if anyone wants to tweak it: = http://www.websequencediagrams.com/?lz=3DcGFydGljaXBhbnQgQ2xpZW50IGFzIEMKA= AwMUmVzb3VyY2UgT3duZXIgYXMgUk8AFA1BdXRob3JpemF0aW9uIFNlcnYAIQZBUwA7DVByb3R= lY3RlZABICmFzIFJTCgoKClJPLS0-QzogR28gZ2V0IG15IHIAbwcKQy0tPlJPOiBSZWRpcmVjd= CB0byBBUy9BRQAvBkFTOiBMb2cgaW4sIGEAgQIHZSBjAIFHBQpBUwAqEwAVBwBrCEhhbmQAKQc= APAUgZ3JhbnQKCmFsdCBzAIFGBnN1cHBsaWVkIGtleQpDAG4GVG9rZW4gcmVxdWVzdCAoADAFK= QpBUwCBDAZnZW5lcmF0ZSB0ACIFYW4ANwUva2V5cGFpcgAiBUMAPAgmIEsAEAtlbHMAgTcIAE8= pICYga2V5AGYYLCBhc3NvY2lhdGUgd2l0aACBQQUAcBIKZW5kCgpDLT5SUzogUgCBUQdpbmNsd= WRpbmcAgT4Lc2lnbmVkAEEKAIIkBnRydWN0dXJlZACBbQYKUlMARAZjaGVjawCCAAdzaWduYXR= 1cmUgLyBkZWNyeXB0AB8PUGFycwCCLgcAOQlVbnBhY2sAgncFAIIYBWludHJvc3BlY3RpbwBiB= kFTOiBzZW4AdAcgKG5vdABiCikgdG8AJQ9BAIEVBwAvBWtleSAocHVibGljIG9yIHNoYXJlZCk= AgwIGZGF0YWJhc2UAgUUJbG9vayB1cABhCGxvY2FsLwAtBiBEQikAHQthAIQoBgCCUAUAgX4OA= IQsCACCBAp1c2luZwCEWAUAGw9pZ2h0cwCDNQoAgm4HAIJbBgCCXQVDOiByZXR1cm4AhicJ&s=3D= modern-blue ) The client is oblivious to the token just like always. This is = intentional. The RS has the same options to figure out how to process = the token. =E2=80=94 Justin > On Nov 25, 2015, at 2:03 PM, Phil Hunt wrote: >=20 > Folks,=20 >=20 > > I did not want to go here either. :-) >=20 > I don=E2=80=99t read sec 6 as examples. I believe this may stem from = the pop-architecture documents having a dual role as both = =E2=80=9Carchitecture=E2=80=9D and =E2=80=9Cuse-case=E2=80=9D. Maybe we = should clarify the purpose of the document? >=20 > I believe section 6 is talking about threat mitigation assumptions = based on the examples that need to be implemented. I am assuming these = are requirements that the other specifications SHOULD implement. >=20 > > I do not believe we have discussed Opaque PoP tokens and any inherent = risks because the client is not or is unable to validate the = authenticity of the token. Does this introduce the possibility of a = MITM attack where a client can be convinced to sign requests for an = attacker? >=20 > If we want to include opaque PoP, I think we need to take a pause and = consider / discuss any threats here. >=20 > I find the desire for opaque PoP tokens to be a bit contradictory. If = we=E2=80=99re saying we don=E2=80=99t want to trust TLS alone (e.g. = because of load-balancer termination), why would we then say, but we are = perfectly willing to accept it worked for the OAuth AS exchanges? Maybe = I was very wrong here, but my assumption all along is that for PoP = we=E2=80=99re talking about end-to-end authentication of all parties = except in the case of 3.3 where we simply want to protect an access = token over a non-TLS HTTP connection. >=20 >=20 > Phil >=20 > @independentid > www.independentid.com = phil.hunt@oracle.com = >> On Nov 25, 2015, at 10:48 AM, Brian Campbell = > wrote: >>=20 >> While I can't say I disagree with the deeper existential questions = about the draft that Justin raises, I was trying not to go there and = rather just point out concerns with the newly added text.=20 >>=20 >> The text Phil cites from Sec 6 doesn't say the client must be able to = parse and verify the token. It's an assumption to simplify the examples = that follow and still the token is opaque to the client. I reread the = whole draft (reluctantly) and there's nothing that says the token has to = be non-opaque to the client. And it does talk about reference style = tokens and encrypted tokens, both of which rely on the opaqueness to the = client.=20 >>=20 >> On Wed, Nov 25, 2015 at 11:27 AM, Justin Richer > wrote: >> Right, I read that as text for describing the examples and not for = describing requirements. >>=20 >> The token itself doesn=E2=80=99t have to be signed at all. >>=20 >> =E2=80=94 Justin >>=20 >>> On Nov 25, 2015, at 1:05 PM, Phil Hunt > wrote: >>>=20 >>> Ok. Well this was requested by Kathleen because of this paragraph in = Sec 6.=E2=80=A6 >>>=20 >>> To simplify the subsequent description we assume in the PoP = architecture >>> that the token itself is digitally signed by the authorization = server >>> and therefore cannot be modified. >>>=20 >>> Please=20 >>> Phil >>>=20 >>> @independentid >>> www.independentid.com = phil.hunt@oracle.com = >>>> On Nov 25, 2015, at 9:33 AM, Justin Richer > wrote: >>>>=20 >>>> The token doesn=E2=80=99t have to be signed and the client = doesn=E2=80=99t have to verify the signature on the token. That=E2=80=99s = not PoP. The request has to be signed in a way that includes the token. = The token itself can still be opaque. The *key* material can=E2=80=99t = be opaque to the client, but the *token* material still is. >>>>=20 >>>> I agree with Brian that this statement is misleading. >>>>=20 >>>> The examples use a signed token but that is absolutely not a = requirement. Maybe the examples shouldn=E2=80=99t all use one style. >>>>=20 >>>> What=E2=80=99s most difficult about this particular spec is that = it=E2=80=99s very hand-wavy, saying =E2=80=9Cthis is kinda a thing that = kinda works like this=E2=80=9D without saying how to actually do it. = I=E2=80=99m honestly not sure it=E2=80=99s worth publishing as an RFC in = its own right but I=E2=80=99m not going to stand in its way. >>>>=20 >>>> =E2=80=94 Justin >>>>=20 >>>>> On Nov 25, 2015, at 12:14 PM, Brian Campbell = > wrote: >>>>>=20 >>>>> Where does it say that?=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On Wed, Nov 25, 2015 at 8:44 AM, Phil Hunt > wrote: >>>>> Except that later on we require the token be signed and the client = verify that signed token. IOW mutual pop.=20 >>>>>=20 >>>>> Phil >>>>>=20 >>>>> On Nov 25, 2015, at 07:30, Brian Campbell = > wrote: >>>>>=20 >>>>>> Looking at the diff I noticed the following new text, which seems = to conflate bearer/PoP and opaqueness to the client. A client = demonstrating proof-of-possession of some key is orthogonal to the = client being able to parse and understand the access token itself.=20 >>>>>> =20 >>>>>> "In contrast to bearer tokens [RFC6750] which call for tokens = that are opaque to OAuth 2.0 clients, this specification defines the = requirements for proof-of-possession ("PoP") tokens that may be parsed = and verified by OAuth 2.0 clients and relying parties." >>>>>>=20 >>>>>> On Tue, Nov 24, 2015 at 1:07 PM, Phil Hunt > wrote: >>>>>> This draft addresses review comments from Kathleen and Erik = raised since the last draft. >>>>>>=20 >>>>>> It may not include some of the discussion from yesterday/today. = I will add that as the group decides. >>>>>>=20 >>>>>> Cheers, >>>>>>=20 >>>>>> Phil >>>>>>=20 >>>>>> @independentid >>>>>> www.independentid.com >>>>>> phil.hunt@oracle.com >>>>>>=20 >>>>>> > On Nov 24, 2015, at 12:05 PM, internet-drafts@ietf.org = wrote: >>>>>> > >>>>>> > >>>>>> > A New Internet-Draft is available from the on-line = Internet-Drafts directories. >>>>>> > This draft is a work item of the Web Authorization Protocol = Working Group of the IETF. >>>>>> > >>>>>> > Title : OAuth 2.0 Proof-of-Possession (PoP) = Security Architecture >>>>>> > Authors : Phil Hunt >>>>>> > Justin Richer >>>>>> > William Mills >>>>>> > Prateek Mishra >>>>>> > Hannes Tschofenig >>>>>> > Filename : = draft-ietf-oauth-pop-architecture-06.txt >>>>>> > Pages : 23 >>>>>> > Date : 2015-11-24 >>>>>> > >>>>>> > Abstract: >>>>>> > The OAuth 2.0 bearer token specification, as defined in RFC = 6750, >>>>>> > allows any party in possession of a bearer token (a "bearer") = to get >>>>>> > access to the associated resources (without demonstrating = possession >>>>>> > of a cryptographic key). To prevent misuse, bearer tokens = must be >>>>>> > protected from disclosure in transit and at rest. >>>>>> > >>>>>> > Some scenarios demand additional security protection whereby = a client >>>>>> > needs to demonstrate possession of cryptographic keying = material when >>>>>> > accessing a protected resource. This document motivates the >>>>>> > development of the OAuth 2.0 proof-of-possession security = mechanism. >>>>>> > >>>>>> > >>>>>> > The IETF datatracker status page for this draft is: >>>>>> > = https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architecture/ = >>>>>> > >>>>>> > There's also a htmlized version available at: >>>>>> > = https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-06 = >>>>>> > >>>>>> > A diff from the previous version is available at: >>>>>> > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-pop-architecture-06 = = >>>>>> > >>>>>> > >>>>>> > 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 = >>>>>>=20 >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> --=20 >>>>>> =09 >>>>>> Brian Campbell >>>>>> Distinguished Engineer >>>>>> Ping Identity >>>>>> @ bcampbell@pingidentity.com = >>>>>> +1 720.317.2061 >>>>>> @pingidentity >>>>>> Connect with us! >>>>>> >>>>>> = = = = = = = = >>>>>=20 >>>>>=20 >>>>> --=20 >>>>> =09 >>>>> Brian Campbell >>>>> Distinguished Engineer >>>>> Ping Identity >>>>> @ bcampbell@pingidentity.com >>>>> +1 720.317.2061 >>>>> @pingidentity >>>>> Connect with us! >>>>> >>>>> = = = = = = = = _____________________________________= __________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>=20 >>>=20 >>=20 >>=20 >>=20 >>=20 >> --=20 >> =09 >> Brian Campbell >> Distinguished Engineer >> Ping Identity >> @ bcampbell@pingidentity.com >> +1 720.317.2061 >> @pingidentity >> Connect with us! >> >> = = = = = = = = --Apple-Mail=_5FD75B8C-A10D-4381-8228-3BD6709B90B0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 It is still end to end authentication with opaque tokens =E2=80= =94 since all OAuth tokens, including PoP tokens, have always been = intended to be opaque to the client. That hasn=E2=80=99t changed and = that isn=E2=80=99t the intent of this document. If that=E2=80=99s how = people are reading it then we need to pull it back and rewrite it so = that=E2=80=99s not the case.

The client gets a token that has two parts: the token and the = key. The token is analogous to the access_token we have today and would = come out of the server in the same field. The key is handed to the = client alongside the token or registered by the client during the token = request. Either way there=E2=80=99s an association between the two but = it=E2=80=99s not the same association as a public/private = keypair. 

It=E2=80=99s possible to sign the token itself, but the = client doesn=E2=80=99t care. It sends the token and signs the HTTP = request to the RS whether the token is signed, unsigned, hex blob, = encrypted, or anything else. The same series of options are available as = with bearer tokens. PoP tokens have never, ever been intended to be = anything but opaque to the client.

The token can=E2=80=99t be opaque to = the RS, which has to figure out what key to use to check the message = signature. But we=E2=80=99ve got options there, like the embedded key in = a JWT from Mike=E2=80=99s draft, or doing introspection to get the key = (from an extension that hasn=E2=80=99t been written yet), or simply = looking it up in the same database because the RS and the AS are in the = same box. Does this structure/service/database choice sound familiar? It = should, it=E2=80=99s the same as bearer tokens. This is also how the RS = gets information like which scopes are associated with the token, if = it=E2=80=99s expired, and all that. 




So = here=E2=80=99s how I see it going on the wire:



3D"http://www.websequencediagrams.com/cgi-bin/cdraw?lz=3DcGFydGljaXBhb=



(I just wrote this up so there are = probably holes. Here=E2=80=99s the source if anyone wants to tweak = it: http://www.websequencediagrams.com/?lz=3DcGFydGljaXBhbnQgQ2xpZW= 50IGFzIEMKAAwMUmVzb3VyY2UgT3duZXIgYXMgUk8AFA1BdXRob3JpemF0aW9uIFNlcnYAIQZB= UwA7DVByb3RlY3RlZABICmFzIFJTCgoKClJPLS0-QzogR28gZ2V0IG15IHIAbwcKQy0tPl= JPOiBSZWRpcmVjdCB0byBBUy9BRQAvBkFTOiBMb2cgaW4sIGEAgQIHZSBjAIFHBQpBUwAqEwAV= BwBrCEhhbmQAKQcAPAUgZ3JhbnQKCmFsdCBzAIFGBnN1cHBsaWVkIGtleQpDAG4GVG9rZW4gcm= VxdWVzdCAoADAFKQpBUwCBDAZnZW5lcmF0ZSB0ACIFYW4ANwUva2V5cGFpcgAiBUMAPAgmIEsA= EAtlbHMAgTcIAE8pICYga2V5AGYYLCBhc3NvY2lhdGUgd2l0aACBQQUAcBIKZW5kCgpDLT5SUz= ogUgCBUQdpbmNsdWRpbmcAgT4Lc2lnbmVkAEEKAIIkBnRydWN0dXJlZACBbQYKUlMARAZjaGVj= awCCAAdzaWduYXR1cmUgLyBkZWNyeXB0AB8PUGFycwCCLgcAOQlVbnBhY2sAgncFAIIYBWludH= Jvc3BlY3RpbwBiBkFTOiBzZW4AdAcgKG5vdABiCikgdG8AJQ9BAIEVBwAvBWtleSAocHVibGlj= IG9yIHNoYXJlZCkAgwIGZGF0YWJhc2UAgUUJbG9vayB1cABhCGxvY2FsLwAtBiBEQikAHQthAI= QoBgCCUAUAgX4OAIQsCACCBAp1c2luZwCEWAUAGw9pZ2h0cwCDNQoAgm4HAIJbBgCCXQVDOiBy= ZXR1cm4AhicJ&s=3Dmodern-blue )

The client is oblivious to the token = just like always. This is intentional. The RS has the same options to = figure out how to process the token.

 =E2=80=94 Justin

On Nov 25, 2015, at 2:03 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

Folks, 
<editor = hat>
I did not want to go here either. = :-)

I don=E2=80=99= t read sec 6 as examples.  I believe this may stem from the = pop-architecture documents having a dual role as both =E2=80=9Carchitectur= e=E2=80=9D and =E2=80=9Cuse-case=E2=80=9D.  Maybe we should clarify = the purpose of the document?

I believe section 6 is talking about = threat mitigation assumptions based on the examples that need to be = implemented.  I am assuming these are requirements that the other = specifications SHOULD implement.

<personal hat>
I do not believe we have discussed Opaque PoP tokens and any = inherent risks because the client is not or is unable to validate the = authenticity of the token.  Does this introduce the possibility of = a MITM attack where a client can be convinced to sign requests for an = attacker?

If = we want to include opaque PoP, I think we need to take a pause and = consider / discuss any threats here.

I find the desire for opaque PoP tokens = to be a bit contradictory. If we=E2=80=99re saying we don=E2=80=99t want = to trust TLS alone (e.g. because of load-balancer termination), why = would we then say, but we are perfectly willing to accept it worked for = the OAuth AS exchanges?  Maybe I was very wrong here, but my = assumption all along is that for PoP we=E2=80=99re talking about = end-to-end authentication of all parties except in the case of 3.3 where = we simply want to protect an access token over a non-TLS HTTP = connection.



On Nov 25, 2015, at 10:48 AM, Brian Campbell <bcampbell@pingidentity.com> wrote:

While I can't say I disagree = with the deeper existential questions about the draft that Justin = raises, I was trying not to go there and rather just point out concerns = with the newly added text.

The text = Phil cites from Sec 6 doesn't say the client must be able to parse and = verify the token. It's an assumption to simplify the examples that = follow and still the token is opaque to the client. I reread the whole = draft (reluctantly) and there's nothing that says the token has to be = non-opaque to the client. And it does talk about reference style tokens = and encrypted tokens, both of which rely on the opaqueness to the = client.

On Wed, Nov 25, 2015 at 11:27 AM, = Justin Richer <jricher@mit.edu> wrote:
Right, I read that as text for describing the examples and = not for describing requirements.

The token itself doesn=E2=80=99t have to be signed at = all.

 =E2=80=94 = Justin

On Nov 25, 2015, at 1:05 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

Ok. Well this was = requested by Kathleen because of this paragraph in Sec 6.=E2=80=A6

   =
To simplify the subsequent description we assume in the PoP =
architecture
   =
that the token itself is digitally signed by the authorization server

   and therefore cannot be modified.

Please 

On Nov 25, 2015, at 9:33 AM, Justin Richer <jricher@mit.edu> wrote:

The token = doesn=E2=80=99t have to be signed and the client doesn=E2=80=99t have to = verify the signature on the token. That=E2=80=99s not PoP. The request = has to be signed in a way that includes the token. The token itself can = still be opaque. The *key* material can=E2=80=99t be opaque to the = client, but the *token* material still is.

I agree with Brian that this statement = is misleading.

The examples use a signed token but that is absolutely not a = requirement. Maybe the examples shouldn=E2=80=99t all use one = style.

What=E2=80= =99s most difficult about this particular spec is that it=E2=80=99s very = hand-wavy, saying =E2=80=9Cthis is kinda a thing that kinda works like = this=E2=80=9D without saying how to actually do it. I=E2=80=99m honestly = not sure it=E2=80=99s worth publishing as an RFC in its own right but = I=E2=80=99m not going to stand in its way.

 =E2=80=94 Justin

On Nov 25, 2015, at 12:14 PM, Brian Campbell = <bcampbell@pingidentity.com> wrote:

Where does it say = that?



On Wed, = Nov 25, 2015 at 8:44 AM, Phil Hunt <phil.hunt@oracle.com> wrote:
Except that later on we require the token be = signed and the client verify that signed token. IOW mutual = pop. 

Phil

On Nov 25, 2015, at 07:30, = Brian Campbell <bcampbell@pingidentity.com> = wrote:

Looking at the = diff I noticed the following new text, which seems to conflate = bearer/PoP and opaqueness to the client. A client demonstrating = proof-of-possession of some key is orthogonal to the client being able = to parse and understand the access token itself.
 
"In contrast to bearer tokens [RFC6750] which call for tokens = that are opaque to OAuth 2.0 clients, this specification defines the = requirements for proof-of-possession ("PoP") tokens that may be parsed = and verified by OAuth 2.0 clients and relying parties."

On Tue, Nov 24, 2015 at 1:07 PM, Phil Hunt <phil.hunt@oracle.com> = wrote:
This draft = addresses review comments from Kathleen and Erik raised since the last = draft.

It may not include some of the discussion from yesterday/today.  I = will add that as the group decides.

Cheers,

Phil

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

> On Nov 24, 2015, at 12:05 PM, internet-drafts@ietf.org wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts = directories.
> This draft is a work item of the Web Authorization Protocol Working = Group of the IETF.
>
>        Title          =  : OAuth 2.0 Proof-of-Possession (PoP) Security Architecture
>        Authors        =  : Phil Hunt
>                  =         Justin Richer
>                  =         William Mills
>                  =         Prateek Mishra
>                  =         Hannes Tschofenig
>       Filename        : = draft-ietf-oauth-pop-architecture-06.txt
>       Pages          =  : 23
>       Date          =   : 2015-11-24
>
> Abstract:
>   The OAuth 2.0 bearer token specification, as defined in = RFC 6750,
>   allows any party in possession of a bearer token (a = "bearer") to get
>   access to the associated resources (without = demonstrating possession
>   of a cryptographic key).  To prevent misuse, = bearer tokens must be
>   protected from disclosure in transit and at rest.
>
>   Some scenarios demand additional security protection = whereby a client
>   needs to demonstrate possession of cryptographic keying = material when
>   accessing a protected resource.  This document = motivates the
>   development of the OAuth 2.0 proof-of-possession = security mechanism.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architect= ure/
>
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-0= 6
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-pop-archit= ecture-06
>
>
> 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



--
=09 3D"Ping=20
Brian Campbell
Distinguished Engineer
Ping = Identity
@ bcampbell@pingidentity.com
3D"phone" +1 720.317.2061
3D"twitter" @pingidentity
Connect with = us!
3D"pingidentity.com"
=
3D"pingidentity.com"
= 3D"twitter 3D"twitter 3D"youtube 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard= 3D"rss


--
=09 3D"Ping=20
Brian Campbell
Distinguished Engineer
Ping = Identity
@ bcampbell@pingidentity.com
3D"phone" +1 720.317.2061
3D"twitter" @pingidentity
Connect with = us!
3D"pingidentity.com"
=
3D"pingidentity.com"
= 3D"twitter 3D"twitter 3D"youtube 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard= 3D"rss
_______________________________________________
OAuth = mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth






--
=09 3D"Ping=20
Brian Campbell
Distinguished Engineer
Ping Identity
@ bcampbell@pingidentity.com
3D"phone" +1 720.317.2061
3D"twitter" @pingidentity
Connect with = us!
3D"pingidentity.com"
=
3D"pingidentity.com"
= 3D"twitter 3D"twitter 3D"youtube 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard 3D"rss


= --Apple-Mail=_5FD75B8C-A10D-4381-8228-3BD6709B90B0-- From nobody Wed Nov 25 11:26:28 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B36C1B2D65 for ; Wed, 25 Nov 2015 11:26:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X9tqKz7vIXOP for ; Wed, 25 Nov 2015 11:26:23 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0143.outbound.protection.outlook.com [207.46.100.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FD0D1B2D5B for ; Wed, 25 Nov 2015 11:26:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Bpj39UtMacMjX/q97XVxzUTu2XMMC9k0WWMIPrWxdQo=; b=ZfctM+t+GTp/GRtX6+kyXO0qNQc+9PQWLy9ahy2hD3fvGLhalVD9yS5KejDxaB4N4YrFd3x2pL1gDZjW8igLPeQ9hZWQZHmEBC0GNTorUt6nuU8asQC8gi97B4UsdgAHI0K5WGYdqwETd814+VoLVUSJFIZIGSSWiA+x8MimgEs= Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) with Microsoft SMTP Server (TLS) id 15.1.331.20; Wed, 25 Nov 2015 19:26:21 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0331.023; Wed, 25 Nov 2015 19:26:21 +0000 From: Mike Jones To: Kathleen Moriarty Thread-Topic: [OAUTH-WG] AD review of draft-ietf-oauth-proof-of-possession Thread-Index: AQHRJt++kWDp0FqlfEmPEzc+Ih7voJ6r6UxQgAAee4CAAAb2QIAAAjcAgAAA9fCAALluAIAAUfFw Date: Wed, 25 Nov 2015 19:26:21 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [2001:4898:80e8:a::650] x-microsoft-exchange-diagnostics: 1; BY2PR03MB442; 5:b9fNOCnaZn2I0ZlNIAEi5Luhawnz9K50ax3KjnagN/TBHaBeZG1xELuHqLeVkVe0KUbkNzpdBCkbI01LYtZnmW6MQXi0kg7S4eSI5hqOFWpwSssDKtRElKrKvxnxoe/XnZRMD3UhhRR4rRTxFp/seA==; 24:7ciPejuvUYtoPMwbnABfmUznhiUttNif8dIEiKjjXHFtBqiZp7EPHeAbDDep1J9r015HRUyUvfEef5y4/AB8sxUSQ4Rvr3aTdVkRML5xJ8o= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB442; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425024)(601004)(2401047)(8121501046)(5005006)(520078)(3002001)(10201501046)(61426024)(61427024); SRVR:BY2PR03MB442; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB442; x-forefront-prvs: 0771670921 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(164054003)(43784003)(13464003)(51914003)(189002)(377454003)(24454002)(199003)(10400500002)(10090500001)(5002640100001)(5003630100001)(586003)(5005710100001)(50986999)(102836003)(76576001)(76176999)(10290500002)(5003600100002)(106116001)(105586002)(189998001)(8990500004)(5001960100002)(110136002)(99286002)(2900100001)(106356001)(6116002)(5007970100001)(40100003)(5004730100002)(97736004)(81156007)(93886004)(5008740100001)(2950100001)(87936001)(74316001)(33656002)(15975445007)(230783001)(101416001)(86362001)(92566002)(11100500001)(122556002)(77096005)(86612001)(19580395003)(54356999)(19580405001)(1220700001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB442; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Nov 2015 19:26:21.1409 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB442 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-proof-of-possession X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2015 19:26:26 -0000 Hi Kathleen, For what it's worth, Pete's ballot on JWT - recorded at http://datatracker.= ietf.org/doc/rfc7519/ballot/#pete-resnick - consisted entirely of this comm= ent: Others have said all I might say. I do not object to "joots". :-) There were things in the JOSE specs that Pete, in the end, abstained on, bu= t not JWT. I think we may be talking past each other on the ambiguity that you're refe= rring to. Let me try again. In normal uses of JWT, there will be a JWT library (using a JOSE library) a= nd application-specific code that uses the resulting JWTs. At the JWT libr= ary level, yes, stuff that's not understood will be ignored. There's no am= biguity for JWT implementers on what to do. But at the application level, it's entirely within the application's rights= to reject a JWT that contains things that don't conform to the application= 's specified use of JWT, including rejecting it because things were include= d that it didn't expect. It's the *application* that may choose not to ign= ore some not-understood or not-anticipated values - not the JWT library. T= hat's what the second paragraph of http://tools.ietf.org/html/rfc7519#secti= on-4 is talking about and what the equivalent second paragraph of https://t= ools.ietf.org/html/draft-ietf-oauth-proof-of-possession-07#section-3.1 is a= lso about. If you feel that that point needs further clarification in the draft, I'd r= ather that we do that now, than have you submit a ballot that calls out the= ambiguity that you're referring to, when the situation for JWT implementer= s is actually unambiguous. How would you like to proceed? -- Mike -----Original Message----- From: Kathleen Moriarty [mailto:kathleen.moriarty.ietf@gmail.com]=20 Sent: Wednesday, November 25, 2015 6:21 AM To: Mike Jones Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-proof-of-possession Hi Mike, If the working group is okay with the current text, leave it. What you pro= posed is exactly the same as what is there. I'll note this point in my bal= lot as I think you are leaving ambiguity that is not necessary. After getting far enough on this, I think it was Pete who discussed this wi= th you and he gave up and remained in disagreement. Regards, Kathleen=20 Sent from my iPhone > On Nov 24, 2015, at 10:25 PM, Mike Jones wr= ote: >=20 > Rather than elaborating, having looked at the text we're discussing again= , I'm going to counter-propose that we instead simplify - sticking only to = the point that the paragraph is intending to get across. Would it work for= you to simplify the current text: >=20 > "A recipient might not understand the cnf claim, in which case it will= typically be ignored. Unless this is acceptable behavior, applications tha= t need the proof-of-possession keys communicated with it to be understood a= nd processed must require that the parts of this specification that they us= e be implemented." >=20 > to this simpler text? >=20 > "A recipient might not understand the cnf claim. Applications that ne= ed the proof-of-possession keys communicated with it to be understood and p= rocessed must require that the parts of this specification that they use be= implemented." >=20 > The "must ignore" topic is already addressed in the second paragraph of 3= .1 (and with exactly the semantics as the rest of JWT), and so doesn't have= to be re-raised here, as it currently is. Re-raising it is clearly a poin= t of distraction. >=20 > For what it's worth, I don't remember any DISCUSSes on this topic (althou= gh it's possible that your memory is better than mine on this point). >=20 > Best wishes, > -- Mike >=20 > -----Original Message----- > From: Kathleen Moriarty [mailto:kathleen.moriarty.ietf@gmail.com] > Sent: Tuesday, November 24, 2015 7:14 PM > To: Mike Jones > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] AD review of=20 > draft-ietf-oauth-proof-of-possession >=20 >> On Tue, Nov 24, 2015 at 10:10 PM, Mike Jones wrote: >> Fair question about the use of "typically". The reason it's there is th= at this language in JWT [RFC 7519] Section 4 does permit applications to re= quire that JWTs with not-understood claims be rejected, rather than ignored= , even though that's not the default behavior: >>=20 >> The set of claims that a JWT must contain to be considered valid is >> context dependent and is outside the scope of this specification. >> Specific applications of JWTs will require implementations to >> understand and process some claims in particular ways. However, in >> the absence of such requirements, all claims that are not understood >> by implementations MUST be ignored. >>=20 >> So when not understood, "cnf" would typically be ignored, but might not = be. >=20 > I find that confusing and am now thinking this came up in a discuss as we= ll during the review for 7519, didn't it? Can you elaborate int eh securit= y considerations section a bit more, otherwise this text appears to be conf= licting and even with what you intend, it's confusing for implementers and = will lead to issues with interoperability. >=20 > Thanks, > Kathleen >=20 >=20 >>=20 >> -- Mike >>=20 >> -----Original Message----- >> From: Kathleen Moriarty [mailto:kathleen.moriarty.ietf@gmail.com] >> Sent: Tuesday, November 24, 2015 6:41 PM >> To: Mike Jones >> Cc: oauth@ietf.org >> Subject: Re: [OAUTH-WG] AD review of=20 >> draft-ietf-oauth-proof-of-possession >>=20 >> Hi Mike, >>=20 >> Thanks for the quick turn-around. Just one more comment on my comments. >>=20 >>> On Tue, Nov 24, 2015 at 9:10 PM, Mike Jones wrote: >>> Thanks for your review comments, Kathleen. Responses are inline below.= .. >>>=20 >>>> -----Original Message----- >>>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Kathleen=20 >>>> Moriarty >>>> Sent: Tuesday, November 24, 2015 9:44 AM >>>> To: oauth@ietf.org >>>> Subject: [OAUTH-WG] AD review of >>>> draft-ietf-oauth-proof-of-possession >>>>=20 >>>> Hi, >>>>=20 >>>> Thank you all for your work on this draft! I just have a few question= s: >>>>=20 >>>> 1. Security considerations section says: >>>>=20 >>>> "All of the normal security issues, especially in relationship to >>>> comparing URIs and dealing with unrecognized values, that are >>>> discussed in JWT [JWT] also apply here." >>>>=20 >>>> I find that to be odd phrasing that would likely be picked up in=20 >>>> subsequent reviews. Please remove the word "normal" so that all of=20 >>>> the security issues discusses in JWT are included. Are there other=20 >>>> 'normal considerations in addition to those in JWT that need to be=20 >>>> listed? The phrasing reads as if that may the case and would be=20 >>>> better to include them all or pointers or change the phrasing. >>>=20 >>> You're right. I removed this awkward wording. >>>=20 >>>> 2. Also in the security considerations section, >>>>=20 >>>> "A recipient may not understand the newly introduced "cnf" claim and >>>> may consequently treat it as a bearer token." >>>>=20 >>>> What is the proper handling requirement when an unknown claim is=20 >>>> present? Section 3.1 says: >>>> "When a recipient receives a "cnf" claim with a >>>> member that it does not understand, it MUST ignore that member." >>>>=20 >>>> Is this why it is treated as a bearer token rather than being=20 >>>> rejected? Is this really the action you want to see with cnf? Why=20 >>>> isn't there an error and a resend as a bearer token so that parties=20 >>>> understand (or have an opportunity to understand) that there were issu= es? >>>>=20 >>>> Then the following text in the security section says: >>>> "While this is a >>>> legitimate concern, it is outside the scope of this specification, >>>> since demonstration the possession of the key associated with the >>>> "cnf" claim is not covered by this specification. For more=20 >>>> details, >>>>=20 >>>> How is this outside of the scope of this draft? cnf is defined in=20 >>>> this draft, so handling should be covered in this draft. A pointer=20 >>>> to the POP architecture draft is not helpful as it is not defined=20 >>>> there, it's covered int his draft. Should this text just be=20 >>>> removed and replaced with more explicit handling information int he bo= dy of this draft? >>>=20 >>> Good catch. JWT [RFC 7519] Section 4 says that claims that are not und= erstood must be ignored unless otherwise specified by the application. Thi= s allows new claims to be dynamically added without breaking existing appli= cations. For the same reason, I have incorporated this language about unde= rstanding claims from 7519, but having it be about understanding confirmati= on members. Ultimately, what features must be implemented are always up to= the application, just as with JWT claims. >>=20 >> The new text in Section 3.1 looks good. I'm not sure why the word "typi= cally" appears int he new text of the security considerations section thoug= h after reading the new text in 3.1. Wouldn't it just be ignored since 3.1= now says: >>=20 >> "However, in the absence of such requirements, >> all confirmation members that are not understood by implementations >> MUST be ignored." >>=20 >> Thanks, >> Kathleen >>=20 >>=20 >>>=20 >>>> Thanks! >>>>=20 >>>> -- >>>>=20 >>>> Best regards, >>>> Kathleen >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>> Thanks again, >>> -- Mike >>=20 >>=20 >>=20 >> -- >>=20 >> Best regards, >> Kathleen >=20 >=20 >=20 > -- >=20 > Best regards, > Kathleen From nobody Wed Nov 25 11:38:49 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19DB81A87C1 for ; Wed, 25 Nov 2015 11:38:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.784 X-Spam-Level: X-Spam-Status: No, score=-4.784 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KwiB6P3oZvHi for ; Wed, 25 Nov 2015 11:38:44 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 239E51B2E9F for ; Wed, 25 Nov 2015 11:38:44 -0800 (PST) Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id tAPJcgRH003883 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 25 Nov 2015 19:38:42 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id tAPJcfTf020235 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 25 Nov 2015 19:38:42 GMT Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id tAPJcfML024589; Wed, 25 Nov 2015 19:38:41 GMT Received: from [10.0.1.3] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 25 Nov 2015 11:38:40 -0800 Content-Type: multipart/alternative; boundary=Apple-Mail-6B586EDD-A309-4981-AFF5-ED9E8B8C0FF1 Mime-Version: 1.0 (1.0) From: Phil Hunt X-Mailer: iPhone Mail (13B143) In-Reply-To: Date: Wed, 25 Nov 2015 11:38:36 -0800 Content-Transfer-Encoding: 7bit Message-Id: References: <20151124200512.20833.28463.idtracker@ietfa.amsl.com> <16FAD3AC-CFB8-46D5-A12E-436E902EA439@oracle.com> <6015EE15-1FEE-43DC-930C-68ACAEDC083E@oracle.com> <38555799-721C-4A2F-AAAA-24D9B69EB72E@mit.edu> <1AD1F44B-9837-4288-9997-5292F1DBE30E@oracle.com> To: Justin Richer X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Cc: "" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-pop-architecture-06.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2015 19:38:49 -0000 --Apple-Mail-6B586EDD-A309-4981-AFF5-ED9E8B8C0FF1 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable If there is agreement that tokens are opaque then the requirement that token= s be signed must be removed from the threat mitigation requirements.=20 And the paragraph in sec 5 that brian was concerned about be restored.=20 Phil > On Nov 25, 2015, at 11:24, Justin Richer wrote: >=20 > It is still end to end authentication with opaque tokens =E2=80=94 since a= ll OAuth tokens, including PoP tokens, have always been intended to be opaqu= e to the client. That hasn=E2=80=99t changed and that isn=E2=80=99t the inte= nt of this document. If that=E2=80=99s how people are reading it then we nee= d to pull it back and rewrite it so that=E2=80=99s not the case. >=20 > The client gets a token that has two parts: the token and the key. The tok= en is analogous to the access_token we have today and would come out of the s= erver in the same field. The key is handed to the client alongside the token= or registered by the client during the token request. Either way there=E2=80= =99s an association between the two but it=E2=80=99s not the same associatio= n as a public/private keypair.=20 >=20 > It=E2=80=99s possible to sign the token itself, but the client doesn=E2=80= =99t care. It sends the token and signs the HTTP request to the RS whether t= he token is signed, unsigned, hex blob, encrypted, or anything else. The sam= e series of options are available as with bearer tokens. PoP tokens have nev= er, ever been intended to be anything but opaque to the client. >=20 > The token can=E2=80=99t be opaque to the RS, which has to figure out what k= ey to use to check the message signature. But we=E2=80=99ve got options ther= e, like the embedded key in a JWT from Mike=E2=80=99s draft, or doing intros= pection to get the key (from an extension that hasn=E2=80=99t been written y= et), or simply looking it up in the same database because the RS and the AS a= re in the same box. Does this structure/service/database choice sound famili= ar? It should, it=E2=80=99s the same as bearer tokens. This is also how the R= S gets information like which scopes are associated with the token, if it=E2= =80=99s expired, and all that.=20 >=20 >=20 >=20 >=20 > So here=E2=80=99s how I see it going on the wire: >=20 >=20 >=20 >=20 >=20 >=20 >=20 > (I just wrote this up so there are probably holes. Here=E2=80=99s the sour= ce if anyone wants to tweak it: http://www.websequencediagrams.com/?lz=3DcGFy= dGljaXBhbnQgQ2xpZW50IGFzIEMKAAwMUmVzb3VyY2UgT3duZXIgYXMgUk8AFA1BdXRob3JpemF0= aW9uIFNlcnYAIQZBUwA7DVByb3RlY3RlZABICmFzIFJTCgoKClJPLS0-QzogR28gZ2V0IG15IHIA= bwcKQy0tPlJPOiBSZWRpcmVjdCB0byBBUy9BRQAvBkFTOiBMb2cgaW4sIGEAgQIHZSBjAIFHBQpB= UwAqEwAVBwBrCEhhbmQAKQcAPAUgZ3JhbnQKCmFsdCBzAIFGBnN1cHBsaWVkIGtleQpDAG4GVG9r= ZW4gcmVxdWVzdCAoADAFKQpBUwCBDAZnZW5lcmF0ZSB0ACIFYW4ANwUva2V5cGFpcgAiBUMAPAgm= IEsAEAtlbHMAgTcIAE8pICYga2V5AGYYLCBhc3NvY2lhdGUgd2l0aACBQQUAcBIKZW5kCgpDLT5S= UzogUgCBUQdpbmNsdWRpbmcAgT4Lc2lnbmVkAEEKAIIkBnRydWN0dXJlZACBbQYKUlMARAZjaGVj= awCCAAdzaWduYXR1cmUgLyBkZWNyeXB0AB8PUGFycwCCLgcAOQlVbnBhY2sAgncFAIIYBWludHJv= c3BlY3RpbwBiBkFTOiBzZW4AdAcgKG5vdABiCikgdG8AJQ9BAIEVBwAvBWtleSAocHVibGljIG9y= IHNoYXJlZCkAgwIGZGF0YWJhc2UAgUUJbG9vayB1cABhCGxvY2FsLwAtBiBEQikAHQthAIQoBgCC= UAUAgX4OAIQsCACCBAp1c2luZwCEWAUAGw9pZ2h0cwCDNQoAgm4HAIJbBgCCXQVDOiByZXR1cm4A= hicJ&s=3Dmodern-blue ) >=20 > The client is oblivious to the token just like always. This is intentional= . The RS has the same options to figure out how to process the token. >=20 > =E2=80=94 Justin >=20 >> On Nov 25, 2015, at 2:03 PM, Phil Hunt wrote: >>=20 >> Folks,=20 >>=20 >> >> I did not want to go here either. :-) >>=20 >> I don=E2=80=99t read sec 6 as examples. I believe this may stem from the= pop-architecture documents having a dual role as both =E2=80=9Carchitecture= =E2=80=9D and =E2=80=9Cuse-case=E2=80=9D. Maybe we should clarify the purpo= se of the document? >>=20 >> I believe section 6 is talking about threat mitigation assumptions based o= n the examples that need to be implemented. I am assuming these are require= ments that the other specifications SHOULD implement. >>=20 >> >> I do not believe we have discussed Opaque PoP tokens and any inherent ris= ks because the client is not or is unable to validate the authenticity of th= e token. Does this introduce the possibility of a MITM attack where a clien= t can be convinced to sign requests for an attacker? >>=20 >> If we want to include opaque PoP, I think we need to take a pause and con= sider / discuss any threats here. >>=20 >> I find the desire for opaque PoP tokens to be a bit contradictory. If we=E2= =80=99re saying we don=E2=80=99t want to trust TLS alone (e.g. because of lo= ad-balancer termination), why would we then say, but we are perfectly willin= g to accept it worked for the OAuth AS exchanges? Maybe I was very wrong he= re, but my assumption all along is that for PoP we=E2=80=99re talking about e= nd-to-end authentication of all parties except in the case of 3.3 where we s= imply want to protect an access token over a non-TLS HTTP connection. >>=20 >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>> On Nov 25, 2015, at 10:48 AM, Brian Campbell wrote: >>>=20 >>> While I can't say I disagree with the deeper existential questions about= the draft that Justin raises, I was trying not to go there and rather just p= oint out concerns with the newly added text.=20 >>>=20 >>> The text Phil cites from Sec 6 doesn't say the client must be able to pa= rse and verify the token. It's an assumption to simplify the examples that f= ollow and still the token is opaque to the client. I reread the whole draft (= reluctantly) and there's nothing that says the token has to be non-opaque to= the client. And it does talk about reference style tokens and encrypted tok= ens, both of which rely on the opaqueness to the client.=20 >>>=20 >>>> On Wed, Nov 25, 2015 at 11:27 AM, Justin Richer wrote= : >>>> Right, I read that as text for describing the examples and not for desc= ribing requirements. >>>>=20 >>>> The token itself doesn=E2=80=99t have to be signed at all. >>>>=20 >>>> =E2=80=94 Justin >>>>=20 >>>>> On Nov 25, 2015, at 1:05 PM, Phil Hunt wrote: >>>>>=20 >>>>> Ok. Well this was requested by Kathleen because of this paragraph in S= ec 6.=E2=80=A6 >>>>>=20 >>>>> To simplify the subsequent description we assume in the PoP archite= cture >>>>> that the token itself is digitally signed by the authorization serv= er >>>>> and therefore cannot be modified. >>>>>=20 >>>>> Please=20 >>>>> Phil >>>>>=20 >>>>> @independentid >>>>> www.independentid.com >>>>> phil.hunt@oracle.com >>>>>=20 >>>>>> On Nov 25, 2015, at 9:33 AM, Justin Richer wrote: >>>>>>=20 >>>>>> The token doesn=E2=80=99t have to be signed and the client doesn=E2=80= =99t have to verify the signature on the token. That=E2=80=99s not PoP. The r= equest has to be signed in a way that includes the token. The token itself c= an still be opaque. The *key* material can=E2=80=99t be opaque to the client= , but the *token* material still is. >>>>>>=20 >>>>>> I agree with Brian that this statement is misleading. >>>>>>=20 >>>>>> The examples use a signed token but that is absolutely not a requirem= ent. Maybe the examples shouldn=E2=80=99t all use one style. >>>>>>=20 >>>>>> What=E2=80=99s most difficult about this particular spec is that it=E2= =80=99s very hand-wavy, saying =E2=80=9Cthis is kinda a thing that kinda wor= ks like this=E2=80=9D without saying how to actually do it. I=E2=80=99m hone= stly not sure it=E2=80=99s worth publishing as an RFC in its own right but I= =E2=80=99m not going to stand in its way. >>>>>>=20 >>>>>> =E2=80=94 Justin >>>>>>=20 >>>>>>> On Nov 25, 2015, at 12:14 PM, Brian Campbell wrote: >>>>>>>=20 >>>>>>> Where does it say that?=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>> On Wed, Nov 25, 2015 at 8:44 AM, Phil Hunt w= rote: >>>>>>>> Except that later on we require the token be signed and the client v= erify that signed token. IOW mutual pop.=20 >>>>>>>>=20 >>>>>>>> Phil >>>>>>>>=20 >>>>>>>>> On Nov 25, 2015, at 07:30, Brian Campbell wrote: >>>>>>>>>=20 >>>>>>>>> Looking at the diff I noticed the following new text, which seems t= o conflate bearer/PoP and opaqueness to the client. A client demonstrating p= roof-of-possession of some key is orthogonal to the client being able to par= se and understand the access token itself.=20 >>>>>>>>> =20 >>>>>>>>> "In contrast to bearer tokens [RFC6750] which call for tokens that= are opaque to OAuth 2.0 clients, this specification defines the requirement= s for proof-of-possession ("PoP") tokens that may be parsed and verified by O= Auth 2.0 clients and relying parties." >>>>>>>>>=20 >>>>>>>>>> On Tue, Nov 24, 2015 at 1:07 PM, Phil Hunt = wrote: >>>>>>>>>> This draft addresses review comments from Kathleen and Erik raise= d since the last draft. >>>>>>>>>>=20 >>>>>>>>>> It may not include some of the discussion from yesterday/today. I= will add that as the group decides. >>>>>>>>>>=20 >>>>>>>>>> Cheers, >>>>>>>>>>=20 >>>>>>>>>> Phil >>>>>>>>>>=20 >>>>>>>>>> @independentid >>>>>>>>>> www.independentid.com >>>>>>>>>> phil.hunt@oracle.com >>>>>>>>>>=20 >>>>>>>>>> > On Nov 24, 2015, at 12:05 PM, internet-drafts@ietf.org wrote: >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > A New Internet-Draft is available from the on-line Internet-Dra= fts directories. >>>>>>>>>> > This draft is a work item of the Web Authorization Protocol Wor= king Group of the IETF. >>>>>>>>>> > >>>>>>>>>> > Title : OAuth 2.0 Proof-of-Possession (PoP) Se= curity Architecture >>>>>>>>>> > Authors : Phil Hunt >>>>>>>>>> > Justin Richer >>>>>>>>>> > William Mills >>>>>>>>>> > Prateek Mishra >>>>>>>>>> > Hannes Tschofenig >>>>>>>>>> > Filename : draft-ietf-oauth-pop-architecture-06.tx= t >>>>>>>>>> > Pages : 23 >>>>>>>>>> > Date : 2015-11-24 >>>>>>>>>> > >>>>>>>>>> > Abstract: >>>>>>>>>> > The OAuth 2.0 bearer token specification, as defined in RFC 6= 750, >>>>>>>>>> > allows any party in possession of a bearer token (a "bearer")= to get >>>>>>>>>> > access to the associated resources (without demonstrating pos= session >>>>>>>>>> > of a cryptographic key). To prevent misuse, bearer tokens mu= st be >>>>>>>>>> > protected from disclosure in transit and at rest. >>>>>>>>>> > >>>>>>>>>> > Some scenarios demand additional security protection whereby a= client >>>>>>>>>> > needs to demonstrate possession of cryptographic keying mater= ial when >>>>>>>>>> > accessing a protected resource. This document motivates the >>>>>>>>>> > development of the OAuth 2.0 proof-of-possession security mec= hanism. >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > The IETF datatracker status page for this draft is: >>>>>>>>>> > https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architect= ure/ >>>>>>>>>> > >>>>>>>>>> > There's also a htmlized version available at: >>>>>>>>>> > https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-0= 6 >>>>>>>>>> > >>>>>>>>>> > A diff from the previous version is available at: >>>>>>>>>> > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-pop-archit= ecture-06 >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > Please note that it may take a couple of minutes from the time o= f 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 >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> OAuth mailing list >>>>>>>>>> OAuth@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> --=20 >>>>>>>>> =09 >>>>>>>>> Brian Campbell >>>>>>>>> Distinguished Engineer >>>>>>>>> Ping Identity >>>>>>>>> @ bcampbell@pingidentity.com >>>>>>>>> +1 720.317.2061 >>>>>>>>> @pingidentity >>>>>>>>> Connect with us! >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> =20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> --=20 >>>>>>> =09 >>>>>>> Brian Campbell >>>>>>> Distinguished Engineer >>>>>>> Ping Identity >>>>>>> @ bcampbell@pingidentity.com >>>>>>> +1 720.317.2061 >>>>>>> @pingidentity >>>>>>> Connect with us! >>>>>>>=20 >>>>>>>=20 >>>>>>> =20 >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>>=20 >>>=20 >>> --=20 >>> =09 >>> Brian Campbell >>> Distinguished Engineer >>> Ping Identity >>> @ bcampbell@pingidentity.com >>> +1 720.317.2061 >>> @pingidentity >>> Connect with us! >>>=20 >>>=20 >>> =20 >=20 --Apple-Mail-6B586EDD-A309-4981-AFF5-ED9E8B8C0FF1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
<editors hat>
If there is agreement that tokens are opaque then the requ= irement that tokens be signed must be removed from the threat mitigation req= uirements. 

And the paragraph in sec 5 that brian was concerned about b= e restored. 

Phil

On Nov 25, 2015, at 11:24, Justin Rich= er <jricher@mit.edu> wrote:
=
It is still end to end authentication w= ith opaque tokens =E2=80=94 since all OAuth tokens, including PoP tokens, ha= ve always been intended to be opaque to the client. That hasn=E2=80=99t chan= ged and that isn=E2=80=99t the intent of this document. If that=E2=80=99s ho= w people are reading it then we need to pull it back and rewrite it so that=E2= =80=99s not the case.

Th= e client gets a token that has two parts: the token and the key. The token i= s analogous to the access_token we have today and would come out of the serv= er in the same field. The key is handed to the client alongside the token or= registered by the client during the token request. Either way there=E2=80=99= s an association between the two but it=E2=80=99s not the same association a= s a public/private keypair. 

=
It=E2=80=99s possible to sign the token itself, but the clie= nt doesn=E2=80=99t care. It sends the token and signs the HTTP request to th= e RS whether the token is signed, unsigned, hex blob, encrypted, or anything= else. The same series of options are available as with bearer tokens. PoP t= okens have never, ever been intended to be anything but opaque to the client= .

The token can=E2= =80=99t be opaque to the RS, which has to figure out what key to use to chec= k the message signature. But we=E2=80=99ve got options there, like the embed= ded key in a JWT from Mike=E2=80=99s draft, or doing introspection to get th= e key (from an extension that hasn=E2=80=99t been written yet), or simply lo= oking it up in the same database because the RS and the AS are in the same b= ox. Does this structure/service/database choice sound familiar? It should, i= t=E2=80=99s the same as bearer tokens. This is also how the RS gets informat= ion like which scopes are associated with the token, if it=E2=80=99s expired= , and all that. 




So here=E2=80=99s how I see it going o= n the wire:



3D"http://www.websequencediagrams.com/cgi-bin/cdraw?l=



(I just wrote this up so there are probably ho= les. Here=E2=80=99s the source if anyone wants to tweak it: http://www.websequencediagrams.com/?lz=3D= cGFydGljaXBhbnQgQ2xpZW50IGFzIEMKAAwMUmVzb3VyY2UgT3duZXIgYXMgUk8AFA1BdXRob3Jp= emF0aW9uIFNlcnYAIQZBUwA7DVByb3RlY3RlZABICmFzIFJTCgoKClJPLS0-QzogR28gZ2V0= IG15IHIAbwcKQy0tPlJPOiBSZWRpcmVjdCB0byBBUy9BRQAvBkFTOiBMb2cgaW4sIGEAgQIHZSBj= AIFHBQpBUwAqEwAVBwBrCEhhbmQAKQcAPAUgZ3JhbnQKCmFsdCBzAIFGBnN1cHBsaWVkIGtleQpD= AG4GVG9rZW4gcmVxdWVzdCAoADAFKQpBUwCBDAZnZW5lcmF0ZSB0ACIFYW4ANwUva2V5cGFpcgAi= BUMAPAgmIEsAEAtlbHMAgTcIAE8pICYga2V5AGYYLCBhc3NvY2lhdGUgd2l0aACBQQUAcBIKZW5k= CgpDLT5SUzogUgCBUQdpbmNsdWRpbmcAgT4Lc2lnbmVkAEEKAIIkBnRydWN0dXJlZACBbQYKUlMA= RAZjaGVjawCCAAdzaWduYXR1cmUgLyBkZWNyeXB0AB8PUGFycwCCLgcAOQlVbnBhY2sAgncFAIIY= BWludHJvc3BlY3RpbwBiBkFTOiBzZW4AdAcgKG5vdABiCikgdG8AJQ9BAIEVBwAvBWtleSAocHVi= bGljIG9yIHNoYXJlZCkAgwIGZGF0YWJhc2UAgUUJbG9vayB1cABhCGxvY2FsLwAtBiBEQikAHQth= AIQoBgCCUAUAgX4OAIQsCACCBAp1c2luZwCEWAUAGw9pZ2h0cwCDNQoAgm4HAIJbBgCCXQVDOiBy= ZXR1cm4AhicJ&s=3Dmodern-blue )

The client is oblivious to the token just like always. This= is intentional. The RS has the same options to figure out how to process th= e token.

 =E2= =80=94 Justin

On Nov 25, 2015, at 2:03 PM, Phil Hunt <<= a href=3D"mailto:phil.hunt@oracle.com" class=3D"">phil.hunt@oracle.com&g= t; wrote:

Folks, 
<editor hat>
I= did not want to go here either. :-)

I don=E2=80=99t read sec 6 as examples.  I believe t= his may stem from the pop-architecture documents having a dual role as both =E2= =80=9Carchitecture=E2=80=9D and =E2=80=9Cuse-case=E2=80=9D.  Maybe we s= hould clarify the purpose of the document?

I believe section 6 is talking about threat mitigat= ion assumptions based on the examples that need to be implemented.  I a= m assuming these are requirements that the other specifications SHOULD imple= ment.

<personal= hat>
I do not believe we have discussed Opaque PoP t= okens and any inherent risks because the client is not or is unable to valid= ate the authenticity of the token.  Does this introduce the possibility= of a MITM attack where a client can be convinced to sign requests for an at= tacker?

If we want= to include opaque PoP, I think we need to take a pause and consider / discu= ss any threats here.

I find the desire for opaque PoP tokens to be a bit contradictory. If we=E2= =80=99re saying we don=E2=80=99t want to trust TLS alone (e.g. because of lo= ad-balancer termination), why would we then say, but we are perfectly willin= g to accept it worked for the OAuth AS exchanges?  Maybe I was very wro= ng here, but my assumption all along is that for PoP we=E2=80=99re talking a= bout end-to-end authentication of all parties except in the case of 3.3 wher= e we simply want to protect an access token over a non-TLS HTTP connection.<= /div>


Phil

@independentid
www.independentid.com=
phil.hunt@oracle.com
<= /div>

On Nov 25, 2015, at 10:48 AM, Brian Campbell <bcampbell@pingidentity.com> wro= te:

While I can't say I disagre= e with the deeper existential questions about the draft that Justin raises, I= was trying not to go there and rather just point out concerns with the newl= y added text.

The text Phil cites from S= ec 6 doesn't say the client must be able to parse and verify the token. It's= an assumption to simplify the examples that follow and still the token is o= paque to the client. I reread the whole draft (reluctantly) and there's noth= ing that says the token has to be non-opaque to the client. And it does talk= about reference style tokens and encrypted tokens, both of which rely on th= e opaqueness to the client.

On Wed, Nov 25, 2015 at 11:2= 7 AM, Justin Richer <jricher@mit.edu> wrot= e:
Right, I read that as text for describing the examples and= not for describing requirements.

The token itself doesn=E2=80=99t have to be signed at all.

 =E2=80=94 Justin

On Nov 25, 2015, at 1= :05 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

Ok. Well this was requested b= y Kathleen because of this paragraph in Sec 6.=E2=80=A6

   To simplify the subsequent description we assume in the PoP arc=
hitecture
   that the token itself is digitally signed by the authorizati=
on server

   and therefore cannot be modified.

Please 
<= div class=3D"">
Phil

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

On Nov 25, 2015, at 9:33 AM, Justin Richer <jricher@mit.edu> wrote:
The token doesn=E2=80=99t have to be signed and the client doesn=E2=80=99= t have to verify the signature on the token. That=E2=80=99s not PoP. The req= uest has to be signed in a way that includes the token. The token itself can= still be opaque. The *key* material can=E2=80=99t be opaque to the client, b= ut the *token* material still is.

I agree with Brian that this statement is misleading.

The examples use a si= gned token but that is absolutely not a requirement. Maybe the examples shou= ldn=E2=80=99t all use one style.

<= div class=3D"">What=E2=80=99s most difficult about this particular spec is t= hat it=E2=80=99s very hand-wavy, saying =E2=80=9Cthis is kinda a thing that k= inda works like this=E2=80=9D without saying how to actually do it. I=E2=80=99= m honestly not sure it=E2=80=99s worth publishing as an RFC in its own right= but I=E2=80=99m not going to stand in its way.

 =E2=80=94 Justin
On Nov 25, 2015, at 12:14 PM, Brian Campbell <bcampbell@pingidentity= .com> wrote:

Where does it say that?



= On Wed, Nov 25, 2015 at 8:44 AM, Phil Hunt <= phil.hu= nt@oracle.com> wrote:
Except that later on we req= uire the token be signed and the client verify that signed token. IOW mutual= pop. 

Phil

On Nov 25, 2015, at 07:30, Brian Campbell <bca= mpbell@pingidentity.com> wrote:

Looking at the diff I noticed the following new text, which seems to conf= late bearer/PoP and opaqueness to the client. A client demonstrating proof-o= f-possession of some key is orthogonal to the client being able to parse and= understand the access token itself.
 
"In= contrast to bearer tokens [RFC6750] which call for tokens that are opaque t= o OAuth 2.0 clients, this specification defines the requirements for proof-o= f-possession ("PoP") tokens that may be parsed and verified by OAuth 2.0 cli= ents and relying parties."
On Tue, Nov 24, 2015 at 1:07 PM, Phi= l Hunt <phil.hunt@oracle.com> wrote:<= br class=3D"">
This draft addresses review comm= ents from Kathleen and Erik raised since the last draft.

It may not include some of the discussion from yesterday/today.  I will= add that as the group decides.

Cheers,

Phil

@independentid
www.independentid.com
phil.hu= nt@oracle.com

> On Nov 24, 2015, at 12:05 PM, internet-drafts@ietf.org wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories.
> This draft is a work item of the Web Authorization Protocol Working Gro= up of the IETF.
>
>        Title          &nbs= p;: OAuth 2.0 Proof-of-Possession (PoP) Security Architecture
= >        Authors         : P= hil Hunt
>                    &n= bsp;     Justin Richer
>                    &n= bsp;     William Mills
>                    &n= bsp;     Prateek Mishra
>                    &n= bsp;     Hannes Tschofenig
>       Filename        : draft-i= etf-oauth-pop-architecture-06.txt
>       Pages           = ;: 23
>       Date           = : 2015-11-24
>
> Abstract:
>   The OAuth 2.0 bearer token specification, as defined in RFC= 6750,
>   allows any party in possession of a bearer token (a "bearer= ") to get
>   access to the associated resources (without demonstrating p= ossession
>   of a cryptographic key).  To prevent misuse, bearer to= kens must be
>   protected from disclosure in transit and at rest.
>
>   Some scenarios demand additional security protection whereb= y a client
>   needs to demonstrate possession of cryptographic keying mat= erial when
>   accessing a protected resource.  This document motivat= es the
>   development of the OAuth 2.0 proof-of-possession security m= echanism.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker= .ietf.org/doc/draft-ietf-oauth-pop-architecture/
>
> There's also a htmlized version available at:
> https://tools.ietf.org= /html/draft-ietf-oauth-pop-architecture-06
>
> A diff from the previous version is available at:
> https://www.ie= tf.org/rfcdiff?url2=3Ddraft-ietf-oauth-pop-architecture-06
>
>
> Please note that it may take a couple of minutes from the time of submi= ssion
> until the htmlized version and diff are available at tools.ietf.= org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> OAuth mailing list
> OAuth@ie= tf.org
> https://www.ietf.org/mailman/listinfo/oauth=

_______________________________________________
OAuth mailing list
OAuth@ietf.or= g
https://www.ietf.org/mailman/listinfo/oauth<= br class=3D"">


<= br class=3D"">--
=09 3D"Ping=20
Brian C= ampbell
Distinguished Engin= eer
Ping Identity
@ bcampbell@pingidentity.com
3D"p= +1 720.317.2061
3D"twit= @pingidentity
Connect with us!
3D"pingidentity.com"
= 3D"pingidentity.com"
3D"twitter 3D"twitter 3D"youtu= 3D"LinkedIn 3D"Faceb= 3D= 3D"slid= 3D"flipboard 3D"rss



--
=09 3D"Ping=20
Brian C= ampbell
Distinguished Engin= eer
Ping Identity
@ bcampbell@pingidentity.com
3D"p= +1 720.317.2061
3D"twit= @pingidentity
Connect with us!
3D"pingidentity.com"
= 3D"pingidentity.com"
3D"twitter 3D"twitter 3D"youtu= 3D"LinkedIn 3D"Faceb= 3D= 3D"slid= 3D"flipboard 3D"rss
_______________________________________________
OAuth mailing l= ist
OAuth@ietf.org
https://www.ietf.org/mailman/li= stinfo/oauth






--
=09 3D"Ping=20
Brian C= ampbell
Distinguish= ed Engineer
Ping Identity
@ bcampbell@pingidentity.com<= /a>
3D"phone= +1 720.317.2061
3D"twitter"= @pingidentity
Connect with us!
3D"pingidentity.com"
= 3D"pingidentity.com" =3D"twitter 3D"twitter 3D"youtube 3D"LinkedIn 3D"Facebook 3D"G= 3D"slidesha= 3D"flipboard


= --Apple-Mail-6B586EDD-A309-4981-AFF5-ED9E8B8C0FF1-- From nobody Wed Nov 25 11:52:38 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B9C01B2EE4 for ; Wed, 25 Nov 2015 11:52:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XdTjVlmMatMo for ; Wed, 25 Nov 2015 11:52:32 -0800 (PST) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001: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 10BD41B2EED for ; Wed, 25 Nov 2015 11:52:32 -0800 (PST) Received: by igcmv3 with SMTP id mv3so910211igc.0 for ; Wed, 25 Nov 2015 11:52:31 -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:content-type; bh=3IpANebhmD6J2UvMlgsmfLsSrOWMlPtVOP/SJgu92L0=; b=fWWpF2HZaZ3ljGqQMfi1BvyPlyJJwciBbHShIwnGJqyEIh8gy+uHmZaURNgTdeCI7o 6U5qnQo05ktxhqXv1UUIDahdPeG8WwZE1+WflvesvDw4Z330cL7zo/g214aQHEb3U0x0 m7KMatRRk0bh8xP7ReO4WZEe/xqabOqj/sVfk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=3IpANebhmD6J2UvMlgsmfLsSrOWMlPtVOP/SJgu92L0=; b=S5bPmpazGcMCcTGsZc01TlHzvhewB01ZMY3jTpxPZHFqRgTKXbTT2T3ghqryKPiOip lr/I5m2fPAsV5Mr/YjpuJtObvHNaAsNMv7+YED5XTh0X7Ko/084nMVg0+iwOjGGxVnZY 1dE0GIpAxGwfwHi5pzEQvSWGaf0/TAqMXBx9FxKfp0L0Hp5dV5fuv4SeL/T5VQw2s5+T iwoN//7KSdKjFJaQis+F1SSBepmEIDx4xbnQKrbpuBHHpKZnV61szUYW433Smbfgd97p 3uVOTNwqQDvrjsWi9aOKnn7OUFyqd1IzAo9EbGGBzN6j4a24AwvqgIaAxHH0PWlEOa6W fGxw== X-Gm-Message-State: ALoCoQl1KuhBL4nzUeMg67p/ovWmWKApk2NkZhQk8HGSkbC4U3toE+qELWDMApv+3il7rD6+45kt X-Received: by 10.50.143.5 with SMTP id sa5mr1748358igb.77.1448481151338; Wed, 25 Nov 2015 11:52:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.23.133 with HTTP; Wed, 25 Nov 2015 11:52:01 -0800 (PST) In-Reply-To: References: <20151124200512.20833.28463.idtracker@ietfa.amsl.com> <16FAD3AC-CFB8-46D5-A12E-436E902EA439@oracle.com> <6015EE15-1FEE-43DC-930C-68ACAEDC083E@oracle.com> <38555799-721C-4A2F-AAAA-24D9B69EB72E@mit.edu> <1AD1F44B-9837-4288-9997-5292F1DBE30E@oracle.com> From: Brian Campbell Date: Wed, 25 Nov 2015 12:52:01 -0700 Message-ID: To: Phil Hunt Content-Type: multipart/alternative; boundary=001a1134c2e67d6b51052562cc54 Archived-At: Cc: "" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-pop-architecture-06.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2015 19:52:37 -0000 --001a1134c2e67d6b51052562cc54 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable My concern was about text that was just *added* to Sec 5 in -06, which just needs a little fixing up. I agree with Justin's take on things and think that the document is inline with that. And is fine for what it is. No major changes are needed. Just adjust the new text so it's strictly about the distinction between bearer and pop. On Wed, Nov 25, 2015 at 12:38 PM, Phil Hunt wrote: > > If there is agreement that tokens are opaque then the requirement that > tokens be signed must be removed from the threat mitigation requirements. > > And the paragraph in sec 5 that brian was concerned about be restored. > > Phil > > On Nov 25, 2015, at 11:24, Justin Richer wrote: > > It is still end to end authentication with opaque tokens =E2=80=94 since = all OAuth > tokens, including PoP tokens, have always been intended to be opaque to t= he > client. That hasn=E2=80=99t changed and that isn=E2=80=99t the intent of = this document. If > that=E2=80=99s how people are reading it then we need to pull it back and= rewrite > it so that=E2=80=99s not the case. > > The client gets a token that has two parts: the token and the key. The > token is analogous to the access_token we have today and would come out o= f > the server in the same field. The key is handed to the client alongside t= he > token or registered by the client during the token request. Either way > there=E2=80=99s an association between the two but it=E2=80=99s not the s= ame association as > a public/private keypair. > > It=E2=80=99s possible to sign the token itself, but the client doesn=E2= =80=99t care. It > sends the token and signs the HTTP request to the RS whether the token is > signed, unsigned, hex blob, encrypted, or anything else. The same series = of > options are available as with bearer tokens. PoP tokens have never, ever > been intended to be anything but opaque to the client. > > The token can=E2=80=99t be opaque to the RS, which has to figure out what= key to > use to check the message signature. But we=E2=80=99ve got options there, = like the > embedded key in a JWT from Mike=E2=80=99s draft, or doing introspection t= o get the > key (from an extension that hasn=E2=80=99t been written yet), or simply l= ooking it > up in the same database because the RS and the AS are in the same box. Do= es > this structure/service/database choice sound familiar? It should, it=E2= =80=99s the > same as bearer tokens. This is also how the RS gets information like whic= h > scopes are associated with the token, if it=E2=80=99s expired, and all th= at. > > > > > So here=E2=80=99s how I see it going on the wire: > > > > [image: > http://www.websequencediagrams.com/cgi-bin/cdraw?lz=3DcGFydGljaXBhbnQgQ2x= pZW50IGFzIEMKAAwMUmVzb3VyY2UgT3duZXIgYXMgUk8AFA1BdXRob3JpemF0aW9uIFNlcnYAIQ= ZBUwA7DVByb3RlY3RlZABICmFzIFJTCgoKClJPLS0-QzogR28gZ2V0IG15IHIAbwcKQy0tPlJPO= iBSZWRpcmVjdCB0byBBUy9BRQAvBkFTOiBMb2cgaW4sIGEAgQIHZSBjAIFHBQpBUwAqEwAVBwBr= CEhhbmQAKQcAPAUgZ3JhbnQKCmFsdCBzAIFGBnN1cHBsaWVkIGtleQpDAG4GVG9rZW4gcmVxdWV= zdCAoADAFKQpBUwCBDAZnZW5lcmF0ZSB0ACIFYW4ANwUva2V5cGFpcgAiBUMAPAgmIEsAEAtlbH= MAgTcIAE8pICYga2V5AGYYLCBhc3NvY2lhdGUgd2l0aACBQQUAcBIKZW5kCgpDLT5SUzogUgCBU= QdpbmNsdWRpbmcAgT4Lc2lnbmVkAEEKAIIkBnRydWN0dXJlZACBbQYKUlMARAZjaGVjawCCAAdz= aWduYXR1cmUgLyBkZWNyeXB0AB8PUGFycwCCLgcAOQlVbnBhY2sAgncFAIIYBWludHJvc3BlY3R= pbwBiBkFTOiBzZW4AdAcgKG5vdABiCikgdG8AJQ9BAIEVBwAvBWtleSAocHVibGljIG9yIHNoYX= JlZCkAgwIGZGF0YWJhc2UAgUUJbG9vayB1cABhCGxvY2FsLwAtBiBEQikAHQthAIQoBgCCUAUAg= X4OAIQsCACCBAp1c2luZwCEWAUAGw9pZ2h0cwCDNQoAgm4HAIJbBgCCXQVDOiByZXR1cm4AhicJ= &s=3Dmodern-blue] > > > > (I just wrote this up so there are probably holes. Here=E2=80=99s the sou= rce if > anyone wants to tweak it: > http://www.websequencediagrams.com/?lz=3DcGFydGljaXBhbnQgQ2xpZW50IGFzIEMK= AAwMUmVzb3VyY2UgT3duZXIgYXMgUk8AFA1BdXRob3JpemF0aW9uIFNlcnYAIQZBUwA7DVByb3R= lY3RlZABICmFzIFJTCgoKClJPLS0-QzogR28gZ2V0IG15IHIAbwcKQy0tPlJPOiBSZWRpcmVjdC= B0byBBUy9BRQAvBkFTOiBMb2cgaW4sIGEAgQIHZSBjAIFHBQpBUwAqEwAVBwBrCEhhbmQAKQcAP= AUgZ3JhbnQKCmFsdCBzAIFGBnN1cHBsaWVkIGtleQpDAG4GVG9rZW4gcmVxdWVzdCAoADAFKQpB= UwCBDAZnZW5lcmF0ZSB0ACIFYW4ANwUva2V5cGFpcgAiBUMAPAgmIEsAEAtlbHMAgTcIAE8pICY= ga2V5AGYYLCBhc3NvY2lhdGUgd2l0aACBQQUAcBIKZW5kCgpDLT5SUzogUgCBUQdpbmNsdWRpbm= cAgT4Lc2lnbmVkAEEKAIIkBnRydWN0dXJlZACBbQYKUlMARAZjaGVjawCCAAdzaWduYXR1cmUgL= yBkZWNyeXB0AB8PUGFycwCCLgcAOQlVbnBhY2sAgncFAIIYBWludHJvc3BlY3RpbwBiBkFTOiBz= ZW4AdAcgKG5vdABiCikgdG8AJQ9BAIEVBwAvBWtleSAocHVibGljIG9yIHNoYXJlZCkAgwIGZGF= 0YWJhc2UAgUUJbG9vayB1cABhCGxvY2FsLwAtBiBEQikAHQthAIQoBgCCUAUAgX4OAIQsCACCBA= p1c2luZwCEWAUAGw9pZ2h0cwCDNQoAgm4HAIJbBgCCXQVDOiByZXR1cm4AhicJ&s=3Dmodern-b= lue > ) > > The client is oblivious to the token just like always. This is > intentional. The RS has the same options to figure out how to process the > token. > > =E2=80=94 Justin > > On Nov 25, 2015, at 2:03 PM, Phil Hunt wrote: > > Folks, > > > I did not want to go here either. :-) > > I don=E2=80=99t read sec 6 as examples. I believe this may stem from the > pop-architecture documents having a dual role as both =E2=80=9Carchitectu= re=E2=80=9D and > =E2=80=9Cuse-case=E2=80=9D. Maybe we should clarify the purpose of the d= ocument? > > I believe section 6 is talking about threat mitigation assumptions based > on the examples that need to be implemented. I am assuming these are > requirements that the other specifications SHOULD implement. > > > I do not believe we have discussed Opaque PoP tokens and any inherent > risks because the client is not or is unable to validate the authenticity > of the token. Does this introduce the possibility of a MITM attack where= a > client can be convinced to sign requests for an attacker? > > If we want to include opaque PoP, I think we need to take a pause and > consider / discuss any threats here. > > I find the desire for opaque PoP tokens to be a bit contradictory. If > we=E2=80=99re saying we don=E2=80=99t want to trust TLS alone (e.g. becau= se of > load-balancer termination), why would we then say, but we are perfectly > willing to accept it worked for the OAuth AS exchanges? Maybe I was very > wrong here, but my assumption all along is that for PoP we=E2=80=99re tal= king about > end-to-end authentication of all parties except in the case of 3.3 where = we > simply want to protect an access token over a non-TLS HTTP connection. > > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > On Nov 25, 2015, at 10:48 AM, Brian Campbell > wrote: > > While I can't say I disagree with the deeper existential questions about > the draft that Justin raises, I was trying not to go there and rather jus= t > point out concerns with the newly added text. > > The text Phil cites from Sec 6 doesn't say the client must be able to > parse and verify the token. It's an assumption to simplify the examples > that follow and still the token is opaque to the client. I reread the who= le > draft (reluctantly) and there's nothing that says the token has to be > non-opaque to the client. And it does talk about reference style tokens a= nd > encrypted tokens, both of which rely on the opaqueness to the client. > > On Wed, Nov 25, 2015 at 11:27 AM, Justin Richer wrote: > >> Right, I read that as text for describing the examples and not for >> describing requirements. >> >> The token itself doesn=E2=80=99t have to be signed at all. >> >> =E2=80=94 Justin >> >> On Nov 25, 2015, at 1:05 PM, Phil Hunt wrote: >> >> Ok. Well this was requested by Kathleen because of this paragraph in Sec >> 6.=E2=80=A6 >> >> >> To simplify the subsequent description we assume in the PoP architect= ure >> >> that the token itself is digitally signed by the authorization server >> >> and therefore cannot be modified. >> >> >> Please >> Phil >> >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >> >> On Nov 25, 2015, at 9:33 AM, Justin Richer wrote: >> >> The token doesn=E2=80=99t have to be signed and the client doesn=E2=80= =99t have to verify >> the signature on the token. That=E2=80=99s not PoP. The request has to b= e signed in >> a way that includes the token. The token itself can still be opaque. The >> *key* material can=E2=80=99t be opaque to the client, but the *token* ma= terial >> still is. >> >> I agree with Brian that this statement is misleading. >> >> The examples use a signed token but that is absolutely not a requirement= . >> Maybe the examples shouldn=E2=80=99t all use one style. >> >> What=E2=80=99s most difficult about this particular spec is that it=E2= =80=99s very >> hand-wavy, saying =E2=80=9Cthis is kinda a thing that kinda works like t= his=E2=80=9D >> without saying how to actually do it. I=E2=80=99m honestly not sure it= =E2=80=99s worth >> publishing as an RFC in its own right but I=E2=80=99m not going to stand= in its way. >> >> =E2=80=94 Justin >> >> On Nov 25, 2015, at 12:14 PM, Brian Campbell >> wrote: >> >> Where does it say that? >> >> >> >> On Wed, Nov 25, 2015 at 8:44 AM, Phil Hunt wrote: >> >>> Except that later on we require the token be signed and the client >>> verify that signed token. IOW mutual pop. >>> >>> Phil >>> >>> On Nov 25, 2015, at 07:30, Brian Campbell >>> wrote: >>> >>> Looking at the diff I noticed the following new text, which seems to >>> conflate bearer/PoP and opaqueness to the client. A client demonstratin= g >>> proof-of-possession of some key is orthogonal to the client being able = to >>> parse and understand the access token itself. >>> >>> "In contrast to bearer tokens [RFC6750] which call for tokens that are >>> opaque to OAuth 2.0 clients, this specification defines the requirement= s >>> for proof-of-possession ("PoP") tokens that may be parsed and verified = by >>> OAuth 2.0 clients and relying parties." >>> >>> On Tue, Nov 24, 2015 at 1:07 PM, Phil Hunt wrote= : >>> >>>> This draft addresses review comments from Kathleen and Erik raised >>>> since the last draft. >>>> >>>> It may not include some of the discussion from yesterday/today. I wil= l >>>> add that as the group decides. >>>> >>>> Cheers, >>>> >>>> Phil >>>> >>>> @independentid >>>> www.independentid.com >>>> phil.hunt@oracle.com >>>> >>>> > On Nov 24, 2015, at 12:05 PM, internet-drafts@ietf.org wrote: >>>> > >>>> > >>>> > A New Internet-Draft is available from the on-line Internet-Drafts >>>> directories. >>>> > This draft is a work item of the Web Authorization Protocol Working >>>> Group of the IETF. >>>> > >>>> > Title : OAuth 2.0 Proof-of-Possession (PoP) Securit= y >>>> Architecture >>>> > Authors : Phil Hunt >>>> > Justin Richer >>>> > William Mills >>>> > Prateek Mishra >>>> > Hannes Tschofenig >>>> > Filename : draft-ietf-oauth-pop-architecture-06.txt >>>> > Pages : 23 >>>> > Date : 2015-11-24 >>>> > >>>> > Abstract: >>>> > The OAuth 2.0 bearer token specification, as defined in RFC 6750, >>>> > allows any party in possession of a bearer token (a "bearer") to g= et >>>> > access to the associated resources (without demonstrating possessi= on >>>> > of a cryptographic key). To prevent misuse, bearer tokens must be >>>> > protected from disclosure in transit and at rest. >>>> > >>>> > Some scenarios demand additional security protection whereby a >>>> client >>>> > needs to demonstrate possession of cryptographic keying material >>>> when >>>> > accessing a protected resource. This document motivates the >>>> > development of the OAuth 2.0 proof-of-possession security mechanis= m. >>>> > >>>> > >>>> > The IETF datatracker status page for this draft is: >>>> > https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architecture/ >>>> > >>>> > There's also a htmlized version available at: >>>> > https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-06 >>>> > >>>> > A diff from the previous version is available at: >>>> > >>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-pop-architecture-= 06 >>>> > >>>> > >>>> > 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 >>>> >>> >>> >>> >>> -- >>> [image: Ping Identity logo] >>> Brian Campbell >>> Distinguished Engineer >>> Ping Identity >>> @ bcampbell@pingidentity.com [image: phone] +1 720.317.2061 [image: >>> twitter] @pingidentity Connect with us! >>> [image: pingidentity.com] >>> >>> [image: >>> pingidentity.com] >>> >>> [image: twitter logo] >>> [image: >>> twitter logo] [image: youtube logo] >>> [image: LinkedIn logo] >>> [image: Facebook logo] >>> [image: Google+ logo] >>> [image: slideshare >>> logo] [image: flipboard logo] >>> [image: rss feed icon] >>> >>> >>> >> >> >> -- >> [image: Ping Identity logo] >> Brian Campbell >> Distinguished Engineer >> Ping Identity >> @ bcampbell@pingidentity.com [image: phone] +1 720.317.2061 [image: >> twitter] @pingidentity Connect with us! >> [image: pingidentity.com] >> >> [image: >> pingidentity.com] >> >> [image: twitter logo] >> [image: >> twitter logo] [image: youtube logo] >> [image: LinkedIn logo] >> [image: Facebook logo] >> [image: Google+ logo] >> [image: slideshare >> logo] [image: flipboard logo] >> [image: rss feed icon] >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> >> > > > -- > [image: Ping Identity logo] > Brian Campbell > Distinguished Engineer > Ping Identity > @ bcampbell@pingidentity.com [image: phone] +1 720.317.2061 [image: > twitter] @pingidentity Connect with us! > [image: pingidentity.com] > > [image: > pingidentity.com] > > [image: twitter logo] > [image: > twitter logo] [image: youtube logo] > [image: LinkedIn logo] > [image: Facebook logo] > [image: Google+ logo] > [image: slideshare > logo] [image: flipboard logo] > [image: rss feed icon] > > > > > --=20 [image: Ping Identity logo] Brian Campbell Distinguished Engineer Ping Identity @ bcampbell@pingidentity.com [image: phone] +1 720.317.2061 [image: twitter= ] @pingidentity Connect with us! [image: pingidentity.com] [image: pingidentity.com] [image: twitter logo] [image: twitter logo] [image: youtube logo] [image: LinkedIn logo] [image: Facebook logo] [image: Google+ logo] [image: slideshare logo= ] [image: flipboard logo] [image: rss feed icon] --001a1134c2e67d6b51052562cc54 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
My concern was about text that was just *added* = to Sec 5 in -06, which just needs a little fixing up.

I agree= with Justin's take on things and think that the document is inline wit= h that. And is fine for what it is.

No major changes are need= ed. Just adjust the new text so it's strictly about the distinction bet= ween bearer and pop.



On Wed, Nov 25, 2015 at 12:38 PM, Phil Hun= t <phil.hunt@oracle.com> wrote:
<editors hat>
If there is a= greement that tokens are opaque then the requirement that tokens be signed = must be removed from the threat mitigation requirements.=C2=A0
And the paragraph in sec 5 that brian was concerned about be r= estored.=C2=A0
Phil

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

It is still end to end authentication with opaque tokens = =E2=80=94 since all OAuth tokens, including PoP tokens, have always been in= tended to be opaque to the client. That hasn=E2=80=99t changed and that isn= =E2=80=99t the intent of this document. If that=E2=80=99s how people are re= ading it then we need to pull it back and rewrite it so that=E2=80=99s not = the case.

The client gets a token that has two parts: th= e token and the key. The token is analogous to the access_token we have tod= ay and would come out of the server in the same field. The key is handed to= the client alongside the token or registered by the client during the toke= n request. Either way there=E2=80=99s an association between the two but it= =E2=80=99s not the same association as a public/private keypair.=C2=A0

It=E2=80=99s possible to sign the token itself, but th= e client doesn=E2=80=99t care. It sends the token and signs the HTTP reques= t to the RS whether the token is signed, unsigned, hex blob, encrypted, or = anything else. The same series of options are available as with bearer toke= ns. PoP tokens have never, ever been intended to be anything but opaque to = the client.

The token can=E2=80=99t be opaque to t= he RS, which has to figure out what key to use to check the message signatu= re. But we=E2=80=99ve got options there, like the embedded key in a JWT fro= m Mike=E2=80=99s draft, or doing introspection to get the key (from an exte= nsion that hasn=E2=80=99t been written yet), or simply looking it up in the= same database because the RS and the AS are in the same box. Does this str= ucture/service/database choice sound familiar? It should, it=E2=80=99s the = same as bearer tokens. This is also how the RS gets information like which = scopes are associated with the token, if it=E2=80=99s expired, and all that= .=C2=A0




So here=E2=80=99s how I see it going on the wire:



3D"http://www.websequencediagrams=



(I= just wrote this up so there are probably holes. Here=E2=80=99s the source = if anyone wants to tweak it:=C2=A0http://www.websequencediagrams.com/?lz=3DcGFydGljaXBhbnQgQ2= xpZW50IGFzIEMKAAwMUmVzb3VyY2UgT3duZXIgYXMgUk8AFA1BdXRob3JpemF0aW9uIFNlcnYAI= QZBUwA7DVByb3RlY3RlZABICmFzIFJTCgoKClJPLS0-QzogR28gZ2V0IG15IHIAbwcKQy0t= PlJPOiBSZWRpcmVjdCB0byBBUy9BRQAvBkFTOiBMb2cgaW4sIGEAgQIHZSBjAIFHBQpBUwAqEwA= VBwBrCEhhbmQAKQcAPAUgZ3JhbnQKCmFsdCBzAIFGBnN1cHBsaWVkIGtleQpDAG4GVG9rZW4gcm= VxdWVzdCAoADAFKQpBUwCBDAZnZW5lcmF0ZSB0ACIFYW4ANwUva2V5cGFpcgAiBUMAPAgmIEsAE= AtlbHMAgTcIAE8pICYga2V5AGYYLCBhc3NvY2lhdGUgd2l0aACBQQUAcBIKZW5kCgpDLT5SUzog= UgCBUQdpbmNsdWRpbmcAgT4Lc2lnbmVkAEEKAIIkBnRydWN0dXJlZACBbQYKUlMARAZjaGVjawC= CAAdzaWduYXR1cmUgLyBkZWNyeXB0AB8PUGFycwCCLgcAOQlVbnBhY2sAgncFAIIYBWludHJvc3= BlY3RpbwBiBkFTOiBzZW4AdAcgKG5vdABiCikgdG8AJQ9BAIEVBwAvBWtleSAocHVibGljIG9yI= HNoYXJlZCkAgwIGZGF0YWJhc2UAgUUJbG9vayB1cABhCGxvY2FsLwAtBiBEQikAHQthAIQoBgCC= UAUAgX4OAIQsCACCBAp1c2luZwCEWAUAGw9pZ2h0cwCDNQoAgm4HAIJbBgCCXQVDOiByZXR1cm4= AhicJ&s=3Dmodern-blue )

The client is obliviou= s to the token just like always. This is intentional. The RS has the same o= ptions to figure out how to process the token.

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

On No= v 25, 2015, at 2:03 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

Folks,=C2=A0

<edi= tor hat>
I did not want to go here either. :-)

<= /div>
I don=E2=80=99t read sec 6 as examples.=C2=A0 I believe this may = stem from the pop-architecture documents having a dual role as both =E2=80= =9Carchitecture=E2=80=9D and =E2=80=9Cuse-case=E2=80=9D.=C2=A0 Maybe we sho= uld clarify the purpose of the document?

I believe= section 6 is talking about threat mitigation assumptions based on the exam= ples that need to be implemented.=C2=A0 I am assuming these are requirement= s that the other specifications SHOULD implement.

= <personal hat>
I do not believe we have discussed Opaque Po= P tokens and any inherent risks because the client is not or is unable to v= alidate the authenticity of the token.=C2=A0 Does this introduce the possib= ility of a MITM attack where a client can be convinced to sign requests for= an attacker?

If we want to include opaque PoP, I = think we need to take a pause and consider / discuss any threats here.

I find the desire for opaque PoP tokens to be a bit co= ntradictory. If we=E2=80=99re saying we don=E2=80=99t want to trust TLS alo= ne (e.g. because of load-balancer termination), why would we then say, but = we are perfectly willing to accept it worked for the OAuth AS exchanges?=C2= =A0 Maybe I was very wrong here, but my assumption all along is that for Po= P we=E2=80=99re talking about end-to-end authentication of all parties exce= pt in the case of 3.3 where we simply want to protect an access token over = a non-TLS HTTP connection.


On Nov 25, 2015, at 10:48 AM, Brian= Campbell <bcampbell@pingidentity.com> wrote:

While I can't say I disagree with the deeper existential que= stions about the draft that Justin raises, I was trying not to go there and= rather just point out concerns with the newly added text.

Th= e text Phil cites from Sec 6 doesn't say the client must be able to par= se and verify the token. It's an assumption to simplify the examples th= at follow and still the token is opaque to the client. I reread the whole d= raft (reluctantly) and there's nothing that says the token has to be no= n-opaque to the client. And it does talk about reference style tokens and e= ncrypted tokens, both of which rely on the opaqueness to the client.

On Wed,= Nov 25, 2015 at 11:27 AM, Justin Richer <jricher@mit.edu> wro= te:
R= ight, I read that as text for describing the examples and not for describin= g requirements.

The token itself doesn=E2=80=99t have to= be signed at all.

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

On Nov 25, 2015, at 1:05 PM, Phil Hunt <phil.hunt@oracle.com>= ; wrote:

Ok. Well this was requested by Kathleen= because of this paragraph in Sec 6.=E2=80=A6

   To simplify the subsequent descripti=
on we assume in the PoP architecture
   that the token itself is digitally signed =
by the authorization server

   and=
 therefore cannot be modified.

Please=C2=A0

On Nov 25, 2015, at 9:33 AM, Justin= Richer <jricher@mi= t.edu> wrote:

The = token doesn=E2=80=99t have to be signed and the client doesn=E2=80=99t have= to verify the signature on the token. That=E2=80=99s not PoP. The request = has to be signed in a way that includes the token. The token itself can sti= ll be opaque. The *key* material can=E2=80=99t be opaque to the client, but= the *token* material still is.

I agree with Brian that = this statement is misleading.

The examples use a sig= ned token but that is absolutely not a requirement. Maybe the examples shou= ldn=E2=80=99t all use one style.

What=E2=80=99s mo= st difficult about this particular spec is that it=E2=80=99s very hand-wavy= , saying =E2=80=9Cthis is kinda a thing that kinda works like this=E2=80=9D= without saying how to actually do it. I=E2=80=99m honestly not sure it=E2= =80=99s worth publishing as an RFC in its own right but I=E2=80=99m not goi= ng to stand in its way.

=C2=A0=E2=80=94 Justin

On Nov 25, 2015, at 12:14 PM= , Brian Campbell <bcampbell@pingidentity.com> wrote:

Where does it say that?



On Wed, Nov 25, 2015 at 8:44 AM, Phil Hu= nt <phil.hunt@oracle.com> wrote:
Except that later on we require the token = be signed and the client verify that signed token. IOW mutual pop.=C2=A0

Phil
<= br>On Nov 25, 2015, at 07:30, Brian Campbell <bcampbell@pingidentity.com> wr= ote:

Looking a= t the diff I noticed the following new text, which seems to conflate bearer= /PoP and opaqueness to the client. A client demonstrating proof-of-possessi= on of some key is orthogonal to the client being able to parse and understa= nd the access token itself.
=C2=A0
"In contrast to bearer token= s [RFC6750] which call for tokens that are opaque to OAuth 2.0 clients, thi= s specification defines the requirements for proof-of-possession ("PoP= ") tokens that may be parsed and verified by OAuth 2.0 clients and rel= ying parties."

On Tue, Nov 24, 2015 at 1:07 PM, Phil Hunt &l= t;phil.hunt@oracl= e.com> wrote:
This draft ad= dresses review comments from Kathleen and Erik raised since the last draft.=

It may not include some of the discussion from yesterday/today.=C2=A0 I wil= l add that as the group decides.

Cheers,

Phil

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

> On Nov 24, 2015, at 12:05 PM, internet-drafts@ietf.org wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
> This draft is a work item of the Web Authorization Protocol Working Gr= oup of the IETF.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: OAuth 2.0 Proof-of-Possession (PoP) Security Architecture
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: = Phil Hunt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Justin Richer
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 William Mills
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Prateek Mishra
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Hannes Tschofenig
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-= ietf-oauth-pop-architecture-06.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: 23
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : 2015-11-24
>
> Abstract:
>=C2=A0 =C2=A0The OAuth 2.0 bearer token specification, as defined in RF= C 6750,
>=C2=A0 =C2=A0allows any party in possession of a bearer token (a "= bearer") to get
>=C2=A0 =C2=A0access to the associated resources (without demonstrating = possession
>=C2=A0 =C2=A0of a cryptographic key).=C2=A0 To prevent misuse, bearer t= okens must be
>=C2=A0 =C2=A0protected from disclosure in transit and at rest.
>
>=C2=A0 =C2=A0Some scenarios demand additional security protection where= by a client
>=C2=A0 =C2=A0needs to demonstrate possession of cryptographic keying ma= terial when
>=C2=A0 =C2=A0accessing a protected resource.=C2=A0 This document motiva= tes the
>=C2=A0 =C2=A0development of the OAuth 2.0 proof-of-possession security = mechanism.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org= /doc/draft-ietf-oauth-pop-architecture/
>
> There's also a htmlized version available at:
> https://tools.ietf.org/html/dra= ft-ietf-oauth-pop-architecture-06
>
> A diff from the previous version is available at:
> https://www.ietf.org/rf= cdiff?url2=3Ddraft-ietf-oauth-pop-architecture-06
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org.<= br> >
> 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



--
=09 3D"Ping=20
Brian Campbell
Distinguished Engineer
Ping Identity
@<= /td> <= span style=3D"text-decoration:none;font-family:arial,helvetica,sans-serif;f= ont-weight:normal;font-size:14px;padding:0px 0px 0px 3px">bcampbell@pingidentity.com
3D"phone" <= span style=3D"font-family:arial,helvetica,sans-serif;font-weight:normal;fon= t-size:14px;padding:0px 0px 0px 3px">+1 720.317.2061
3D"twitter" <= span style=3D"font-family:arial,helvetica,sans-serif;font-weight:normal;fon= t-size:14px;padding:0px 0px 0px 3px">@pingidentity
Connect with us!
3D"pingidentity.com"
3D"pingidentity.com" 3D"twitter 3D"twitter 3D"youtube 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard 3D"rss



--
=09 3D"Ping=20
Brian Campbell
Distinguished Engineer
Ping Identity
@<= /td> <= span style=3D"text-decoration:none;font-family:arial,helvetica,sans-serif;f= ont-weight:normal;font-size:14px;padding:0px 0px 0px 3px">bcampbell@pingidentity.com
3D"phone" <= span style=3D"font-family:arial,helvetica,sans-serif;font-weight:normal;fon= t-size:14px;padding:0px 0px 0px 3px">+1 720.317.2061
3D"twitter" <= span style=3D"font-family:arial,helvetica,sans-serif;font-weight:normal;fon= t-size:14px;padding:0px 0px 0px 3px">@pingidentity
Connect with us!
3D"pingidentity.com"
3D"pingidentity.com" 3D"twitter 3D"twitter 3D"youtube 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard 3D"rss
_______________________________________________
OAuth mailing list
OAuth@ietf.org
http= s://www.ietf.org/mailman/listinfo/oauth





--
=09 3D"Ping=20
Brian Campbell
Distinguished Engineer
Ping Identity
@<= /td> <= span style=3D"text-decoration:none;font-family:arial,helvetica,sans-serif;f= ont-weight:normal;font-size:14px;padding:0px 0px 0px 3px">bcampbell@pingidentity.com
3D"phone" <= span style=3D"font-family:arial,helvetica,sans-serif;font-weight:normal;fon= t-size:14px;padding:0px 0px 0px 3px">+1 720.317.2061
3D"twitter" <= span style=3D"font-family:arial,helvetica,sans-serif;font-weight:normal;fon= t-size:14px;padding:0px 0px 0px 3px">@pingidentity
Connect with us!
3D"pingidentity.com"
3D"pingidentity.com" 3D"twitter 3D"twitter 3D"youtube 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard 3D"rss





--
=09 =3D"Ping=20
Brian Campbell
Distinguished Engineer
Ping Identity
@<= /td> <= span style=3D"text-decoration:none;color:#000000;font-family:arial,helvetic= a,sans-serif;font-weight:normal;font-size:14px;padding:0 0 0 3px">bcampbell@pingiden= tity.com
3D"phone" <= span style=3D"color:#000000;font-family:arial,helvetica,sans-serif;font-wei= ght:normal;font-size:14px;padding:0 0 0 3px">+1 720.317.2061
3D"twitter" <= span style=3D"color:#000000;font-family:arial,helvetica,sans-serif;font-wei= ght:normal;font-size:14px;padding:0 0 0 3px">@pingidentity
Connect with us!
3D"pingidentity.com"
3D"pingidentity.com"
3D"twitter 3D"twitter 3D"youtube 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard 3D"rss
--001a1134c2e67d6b51052562cc54-- From nobody Wed Nov 25 12:02:29 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0572B1B2F07 for ; Wed, 25 Nov 2015 12:02:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GYT5DS7Tmrv3 for ; Wed, 25 Nov 2015 12:02:24 -0800 (PST) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::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 9787D1B2F10 for ; Wed, 25 Nov 2015 12:02:24 -0800 (PST) Received: by qkas77 with SMTP id s77so20267034qka.0 for ; Wed, 25 Nov 2015 12:02:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=fiprI5KCxM7wBBj4Txe7XzdDNJcXZPD6I15HTKmVwsU=; b=BeAt9HyOYPpuBHe5r4FKE03V+PLa/WVfmy9dstG/rMhBJlrIki3jbFEgCvZ5qg2svY JVnY7TiFwEGFYZD21MT0hq6xh6JHm3oRCuoMM0eugHj219HYcgsGP+5C8xDmS71bx1au jr1sjd56z4U05aoRQwc5E8cBe/iQAJH8kNS2T4vvNY3vwredTRKLakZXvcb07NPYTkGA c0lsWlp+R7l8EyTfOjeSmOj8YLqhtdgTeHlt33meMBCCosACyu2i+BpgpxsPQwTeRwU0 wvauqtMDFSBSefuwiNq81e35fjVa77RzhxJDiC/GQgH7DMNvUlrPcipBTTfFqxFOc+Ew kaaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=fiprI5KCxM7wBBj4Txe7XzdDNJcXZPD6I15HTKmVwsU=; b=QOUzY40HdC5VQuceAMgQLUZ3MsoMcEZTYN3X19nQ/LSWkeDFg44yNlj1VBpD4/o0X+ Ef0A4IoIADfZAWxequQruWc9J1seOjX/PES9kuo4CpaSakikZiDI3jKZTKSeZjBVTfHq UWQJ3yqPOSNQr3suw5Tt1Hrv4bQrkFkbD/zrzOq1lRsQgQCvmE/3N74zKiZY8njkghJ3 UpqVLf1FJdiUS14PQ7UWMQayDhn7za8kMs59NIsPFYX5/B3Kn2azQy7MBnOSqsfiJrcY 4lUr7Y74h9/PRdwq7Yzq/phCuqCEXXvevLBNUoSZEQbuzgVxXe1m51JQtB9DzE8q/fhl BHCw== X-Gm-Message-State: ALoCoQm5USTEANETYydB3raTnkJtdEzF1QoqjpVtYXUK6KXId2qI2rHtMOywe0N8rNezpRkjSYfP X-Received: by 10.55.42.27 with SMTP id q27mr41896646qkh.33.1448481743630; Wed, 25 Nov 2015 12:02:23 -0800 (PST) Received: from [192.168.1.216] ([191.115.122.254]) by smtp.gmail.com with ESMTPSA id t103sm5371762qgd.12.2015.11.25.12.02.14 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 25 Nov 2015 12:02:22 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_84B27472-B2B5-4CCC-B660-285375F841DA" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: John Bradley In-Reply-To: <16FAD3AC-CFB8-46D5-A12E-436E902EA439@oracle.com> Date: Wed, 25 Nov 2015 17:02:10 -0300 Message-Id: References: <20151124200512.20833.28463.idtracker@ietfa.amsl.com> <16FAD3AC-CFB8-46D5-A12E-436E902EA439@oracle.com> To: Phil Hunt X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-pop-architecture-06.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2015 20:02:28 -0000 --Apple-Mail=_84B27472-B2B5-4CCC-B660-285375F841DA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The token is opaque to the client. It=E2=80=99s format is a matter = between the RS and the AS.=20 Where do we require the client verify the token? The RS is the only = party that needs to verify the access token. The information that the client needs about the token is in additional = meta-data delivered with but not in the AT. I agree with Brian that is wrong on two counts. 1) the token is opaque to the client. 2) one method of delivering the key to the RS is in a signed JWT. It is = however also possible (if not ideal) for the AT to be a reference, and = introspected by the RS to get the key. So=20 "In contrast to bearer tokens [RFC6750] which call for tokens that are = opaque to OAuth 2.0 clients, this specification defines the requirements = for proof-of-possession ("PoP") tokens that may are also opaque to OAuth = 2.0 clients but may be parsed and verified, or introspected by OAuth 2.0 = Resource Servers. When token endpoints issue =E2=80=9CPoP=E2=80=9D = tokens they provide the OAuth Client additional parameters with = information on what key material to use for the proof.=E2=80=9D Or given that they are both opaque that part of the statement could be = dropped. John B.=20 > On Nov 25, 2015, at 12:44 PM, Phil Hunt wrote: >=20 > Except that later on we require the token be signed and the client = verify that signed token. IOW mutual pop.=20 >=20 > Phil >=20 > On Nov 25, 2015, at 07:30, Brian Campbell > wrote: >=20 >> Looking at the diff I noticed the following new text, which seems to = conflate bearer/PoP and opaqueness to the client. A client demonstrating = proof-of-possession of some key is orthogonal to the client being able = to parse and understand the access token itself.=20 >> =20 >> "In contrast to bearer tokens [RFC6750] which call for tokens that = are opaque to OAuth 2.0 clients, this specification defines the = requirements for proof-of-possession ("PoP") tokens that may be parsed = and verified by OAuth 2.0 clients and relying parties." >>=20 >> On Tue, Nov 24, 2015 at 1:07 PM, Phil Hunt > wrote: >> This draft addresses review comments from Kathleen and Erik raised = since the last draft. >>=20 >> It may not include some of the discussion from yesterday/today. I = will add that as the group decides. >>=20 >> Cheers, >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >> > On Nov 24, 2015, at 12:05 PM, internet-drafts@ietf.org = wrote: >> > >> > >> > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >> > This draft is a work item of the Web Authorization Protocol Working = Group of the IETF. >> > >> > Title : OAuth 2.0 Proof-of-Possession (PoP) = Security Architecture >> > Authors : Phil Hunt >> > Justin Richer >> > William Mills >> > Prateek Mishra >> > Hannes Tschofenig >> > Filename : draft-ietf-oauth-pop-architecture-06.txt >> > Pages : 23 >> > Date : 2015-11-24 >> > >> > Abstract: >> > The OAuth 2.0 bearer token specification, as defined in RFC 6750, >> > allows any party in possession of a bearer token (a "bearer") to = get >> > access to the associated resources (without demonstrating = possession >> > of a cryptographic key). To prevent misuse, bearer tokens must = be >> > protected from disclosure in transit and at rest. >> > >> > Some scenarios demand additional security protection whereby a = client >> > needs to demonstrate possession of cryptographic keying material = when >> > accessing a protected resource. This document motivates the >> > development of the OAuth 2.0 proof-of-possession security = mechanism. >> > >> > >> > The IETF datatracker status page for this draft is: >> > https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architecture/ = >> > >> > There's also a htmlized version available at: >> > https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-06 = >> > >> > A diff from the previous version is available at: >> > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-pop-architecture-06 = = >> > >> > >> > 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 = >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = >>=20 >>=20 >>=20 >> --=20 >> =09 >> Brian Campbell >> Distinguished Engineer >> Ping Identity >> @ bcampbell@pingidentity.com >> +1 720.317.2061 >> @pingidentity >> Connect with us! >> >> = = = = = = = = _____________________________________= __________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_84B27472-B2B5-4CCC-B660-285375F841DA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 The token is opaque to the client.  It=E2=80=99s format = is a matter between the RS and the AS. 

Where do we require the client verify = the token?    The RS is the only party that needs to verify = the access token.

The information that the client needs about the token is in = additional meta-data delivered with but not in the AT.

I agree with Brian that = is wrong on two counts.

1) the token is opaque to the client.
2) = one method of delivering the key to the RS is in a signed JWT.  It = is however also possible (if not ideal) for the AT to be a reference, = and introspected by the RS to get the key.

So 
"In = contrast to bearer tokens [RFC6750] which call for tokens that are = opaque to OAuth 2.0 clients, this specification defines the requirements = for proof-of-possession ("PoP") tokens that may are also opaque to OAuth = 2.0 clients but may be parsed and verified, or introspected by OAuth 2.0 = Resource Servers. When token endpoints issue =E2=80=9CPoP=E2=80=9D = tokens they provide the OAuth Client additional parameters with = information on what key material to use for the proof.=E2=80=9D

Or= given that they are both opaque that part of the statement could be = dropped.

John B. 


On = Nov 25, 2015, at 12:44 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

Except that = later on we require the token be signed and the client verify that = signed token. IOW mutual pop. 

Phil

On Nov 25, 2015, at = 07:30, Brian Campbell <bcampbell@pingidentity.com> wrote:

Looking at the diff I noticed the following new = text, which seems to conflate bearer/PoP and opaqueness to the client. A = client demonstrating proof-of-possession of some key is orthogonal to = the client being able to parse and understand the access token itself. =
 
"In contrast to bearer tokens = [RFC6750] which call for tokens that are opaque to OAuth 2.0 clients, = this specification defines the requirements for proof-of-possession = ("PoP") tokens that may be parsed and verified by OAuth 2.0 clients and = relying parties."

On Tue, Nov 24, 2015 at 1:07 PM, = Phil Hunt <phil.hunt@oracle.com> wrote:
This draft addresses = review comments from Kathleen and Erik raised since the last draft.

It may not include some of the discussion from yesterday/today.  I = will add that as the group decides.

Cheers,

Phil

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

> On Nov 24, 2015, at 12:05 PM, internet-drafts@ietf.org wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts = directories.
> This draft is a work item of the Web Authorization Protocol Working = Group of the IETF.
>
>        Title          =  : OAuth 2.0 Proof-of-Possession (PoP) Security Architecture
>        Authors        =  : Phil Hunt
>                  =         Justin Richer
>                  =         William Mills
>                  =         Prateek Mishra
>                  =         Hannes Tschofenig
>       Filename        : = draft-ietf-oauth-pop-architecture-06.txt
>       Pages          =  : 23
>       Date          =   : 2015-11-24
>
> Abstract:
>   The OAuth 2.0 bearer token specification, as defined in = RFC 6750,
>   allows any party in possession of a bearer token (a = "bearer") to get
>   access to the associated resources (without = demonstrating possession
>   of a cryptographic key).  To prevent misuse, = bearer tokens must be
>   protected from disclosure in transit and at rest.
>
>   Some scenarios demand additional security protection = whereby a client
>   needs to demonstrate possession of cryptographic keying = material when
>   accessing a protected resource.  This document = motivates the
>   development of the OAuth 2.0 proof-of-possession = security mechanism.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architect= ure/
>
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-0= 6
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-pop-archit= ecture-06
>
>
> 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



--
=09 3D"Ping=20
Brian Campbell
Distinguished Engineer
Ping Identity
@ bcampbell@pingidentity.com
3D"phone" +1 720.317.2061
3D"twitter" @pingidentity
Connect with = us!
3D"pingidentity.com"
=
3D"pingidentity.com"
= 3D"twitter 3D"twitter 3D"youtube 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard 3D"rss
=
_______________________________________________OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

= --Apple-Mail=_84B27472-B2B5-4CCC-B660-285375F841DA-- From nobody Wed Nov 25 12:19:14 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9BB81B2F53 for ; Wed, 25 Nov 2015 12:19:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.774 X-Spam-Level: X-Spam-Status: No, score=-4.774 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VvFigNbOZSNo for ; Wed, 25 Nov 2015 12:19:09 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BADA11B2F43 for ; Wed, 25 Nov 2015 12:19:09 -0800 (PST) Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id tAPKJ8SY007663 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 25 Nov 2015 20:19:09 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id tAPKJ8rL003202 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 25 Nov 2015 20:19:08 GMT Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id tAPKJ8qX024233; Wed, 25 Nov 2015 20:19:08 GMT Received: from [10.0.1.3] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 25 Nov 2015 12:19:07 -0800 Content-Type: multipart/alternative; boundary=Apple-Mail-950D6303-5F66-4618-9490-2D0372185F83 Mime-Version: 1.0 (1.0) From: Phil Hunt X-Mailer: iPhone Mail (13B143) In-Reply-To: Date: Wed, 25 Nov 2015 12:19:05 -0800 Content-Transfer-Encoding: 7bit Message-Id: References: <20151124200512.20833.28463.idtracker@ietfa.amsl.com> <16FAD3AC-CFB8-46D5-A12E-436E902EA439@oracle.com> To: John Bradley X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Cc: "" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-pop-architecture-06.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2015 20:19:12 -0000 --Apple-Mail-950D6303-5F66-4618-9490-2D0372185F83 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thats not what I am on about.=20 Kathleen objected to the signed requirement in sec 6 without making it clear= in sec 5.=20 We can't have it both ways. Be both opaque and signed for the client to veri= fy. =20 If I restore the requirements than the threat mitigation assumption of signe= d tokens must also be removed.=20 Phil > On Nov 25, 2015, at 12:02, John Bradley wrote: >=20 > The token is opaque to the client. It=E2=80=99s format is a matter betwee= n the RS and the AS.=20 >=20 > Where do we require the client verify the token? The RS is the only par= ty that needs to verify the access token. >=20 > The information that the client needs about the token is in additional met= a-data delivered with but not in the AT. >=20 > I agree with Brian that is wrong on two counts. >=20 > 1) the token is opaque to the client. > 2) one method of delivering the key to the RS is in a signed JWT. It is h= owever also possible (if not ideal) for the AT to be a reference, and intros= pected by the RS to get the key. >=20 > So=20 > "In contrast to bearer tokens [RFC6750] which call for tokens that are opa= que to OAuth 2.0 clients, this specification defines the requirements for pr= oof-of-possession ("PoP") tokens that may are also opaque to OAuth 2.0 clien= ts but may be parsed and verified, or introspected by OAuth 2.0 Resource Ser= vers. When token endpoints issue =E2=80=9CPoP=E2=80=9D tokens they provide t= he OAuth Client additional parameters with information on what key material t= o use for the proof.=E2=80=9D >=20 > Or given that they are both opaque that part of the statement could be dro= pped. >=20 > John B.=20 >=20 >=20 >> On Nov 25, 2015, at 12:44 PM, Phil Hunt wrote: >>=20 >> Except that later on we require the token be signed and the client verify= that signed token. IOW mutual pop.=20 >>=20 >> Phil >>=20 >>> On Nov 25, 2015, at 07:30, Brian Campbell w= rote: >>>=20 >>> Looking at the diff I noticed the following new text, which seems to con= flate bearer/PoP and opaqueness to the client. A client demonstrating proof-= of-possession of some key is orthogonal to the client being able to parse an= d understand the access token itself.=20 >>> =20 >>> "In contrast to bearer tokens [RFC6750] which call for tokens that are o= paque to OAuth 2.0 clients, this specification defines the requirements for p= roof-of-possession ("PoP") tokens that may be parsed and verified by OAuth 2= .0 clients and relying parties." >>>=20 >>>> On Tue, Nov 24, 2015 at 1:07 PM, Phil Hunt wrote= : >>>> This draft addresses review comments from Kathleen and Erik raised sinc= e the last draft. >>>>=20 >>>> It may not include some of the discussion from yesterday/today. I will= add that as the group decides. >>>>=20 >>>> Cheers, >>>>=20 >>>> Phil >>>>=20 >>>> @independentid >>>> www.independentid.com >>>> phil.hunt@oracle.com >>>>=20 >>>> > On Nov 24, 2015, at 12:05 PM, internet-drafts@ietf.org wrote: >>>> > >>>> > >>>> > A New Internet-Draft is available from the on-line Internet-Drafts di= rectories. >>>> > This draft is a work item of the Web Authorization Protocol Working G= roup of the IETF. >>>> > >>>> > Title : OAuth 2.0 Proof-of-Possession (PoP) Security= Architecture >>>> > Authors : Phil Hunt >>>> > Justin Richer >>>> > William Mills >>>> > Prateek Mishra >>>> > Hannes Tschofenig >>>> > Filename : draft-ietf-oauth-pop-architecture-06.txt >>>> > Pages : 23 >>>> > Date : 2015-11-24 >>>> > >>>> > Abstract: >>>> > The OAuth 2.0 bearer token specification, as defined in RFC 6750, >>>> > allows any party in possession of a bearer token (a "bearer") to ge= t >>>> > access to the associated resources (without demonstrating possessio= n >>>> > of a cryptographic key). To prevent misuse, bearer tokens must be >>>> > protected from disclosure in transit and at rest. >>>> > >>>> > Some scenarios demand additional security protection whereby a clie= nt >>>> > needs to demonstrate possession of cryptographic keying material wh= en >>>> > accessing a protected resource. This document motivates the >>>> > development of the OAuth 2.0 proof-of-possession security mechanism= . >>>> > >>>> > >>>> > The IETF datatracker status page for this draft is: >>>> > https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architecture/ >>>> > >>>> > There's also a htmlized version available at: >>>> > https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-06 >>>> > >>>> > A diff from the previous version is available at: >>>> > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-pop-architecture= -06 >>>> > >>>> > >>>> > Please note that it may take a couple of minutes from the time of sub= mission >>>> > 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 >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>>=20 >>>=20 >>> --=20 >>> =09 >>> Brian Campbell >>> Distinguished Engineer >>> Ping Identity >>> @ bcampbell@pingidentity.com >>> +1 720.317.2061 >>> @pingidentity >>> Connect with us! >>>=20 >>>=20 >>> =20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 --Apple-Mail-950D6303-5F66-4618-9490-2D0372185F83 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Thats not what I am on about. 

K= athleen objected to the signed requirement in sec 6 without making it clear i= n sec 5. 

We can't have it both ways. Be both opaque and signed for th= e client to verify.  

If I restore the requirements than the threat mi= tigation assumption of signed tokens must also be removed. 

Phil

On Nov 25, 2015, at 12:02, J= ohn Bradley <ve7jtb@ve7jtb.com&g= t; wrote:

The token is opaque to the= client.  It=E2=80=99s format is a matter between the RS and the AS.&nb= sp;

Where do we require t= he client verify the token?    The RS is the only party that needs= to verify the access token.

The information that the client needs about the token is in additi= onal meta-data delivered with but not in the AT.

I agree with Brian that is wrong on two count= s.

1) the token is= opaque to the client.
2) one method of delivering the k= ey to the RS is in a signed JWT.  It is however also possible (if not i= deal) for the AT to be a reference, and introspected by the RS to get the ke= y.

So 
<= div class=3D"">
"In contrast to bearer tokens [RFC6750] which call for tokens th= at are opaque to OAuth 2.0 clients, this specification defines the requireme= nts for proof-of-possession ("PoP") tokens that may are also opaque to OAuth= 2.0 clients but may be parsed and verified, or introspected by OAuth 2.0 Re= source Servers. When token endpoints issue =E2=80=9CPoP=E2=80=9D tokens they= provide the OAuth Client additional parameters with information on what key= material to use for the proof.=E2=80=9D
Or given that they are both o= paque that part of the statement could be dropped.

John B. 
=


On Nov 25, 2015, at 12:44 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

Except that later on we require the token be signed and t= he client verify that signed token. IOW mutual pop. 

Phil

On Nov 25, 2015, at 07:30= , Brian Campbell <bcampbell@pingidentity.com> wrote:

Looking at the diff I noticed the following new text, which seems to= conflate bearer/PoP and opaqueness to the client. A client demonstrating pr= oof-of-possession of some key is orthogonal to the client being able to pars= e and understand the access token itself.
 
"In contrast to bearer tokens [RFC6750] which call for tokens that are opa= que to OAuth 2.0 clients, this specification defines the requirements for pr= oof-of-possession ("PoP") tokens that may be parsed and verified by OAuth 2.= 0 clients and relying parties."

On Tue, Nov 24, 2015 at 1:07 PM= , Phil Hunt <phil.hunt@oracle.com> wr= ote:
This draft addresses review= comments from Kathleen and Erik raised since the last draft.
=
It may not include some of the discussion from yesterday/today.  I will= add that as the group decides.

Cheers,

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com<= br class=3D"">

> On Nov 24, 2015, at 12:05 PM, internet-drafts@ietf.org wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories.
> This draft is a work item of the Web Authorization Protocol Working Gro= up of the IETF.
>
>        Title          &nbs= p;: OAuth 2.0 Proof-of-Possession (PoP) Security Architecture
= >        Authors         : P= hil Hunt
>                    &n= bsp;     Justin Richer
>                    &n= bsp;     William Mills
>                    &n= bsp;     Prateek Mishra
>                    &n= bsp;     Hannes Tschofenig
>       Filename        : draft-i= etf-oauth-pop-architecture-06.txt
>       Pages           = ;: 23
>       Date           = : 2015-11-24
>
> Abstract:
>   The OAuth 2.0 bearer token specification, as defined in RFC= 6750,
>   allows any party in possession of a bearer token (a "bearer= ") to get
>   access to the associated resources (without demonstrating p= ossession
>   of a cryptographic key).  To prevent misuse, bearer to= kens must be
>   protected from disclosure in transit and at rest.
>
>   Some scenarios demand additional security protection whereb= y a client
>   needs to demonstrate possession of cryptographic keying mat= erial when
>   accessing a protected resource.  This document motivat= es the
>   development of the OAuth 2.0 proof-of-possession security m= echanism.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker= .ietf.org/doc/draft-ietf-oauth-pop-architecture/
>
> There's also a htmlized version available at:
> https://tools.ietf.org= /html/draft-ietf-oauth-pop-architecture-06
>
> A diff from the previous version is available at:
> https://www.ie= tf.org/rfcdiff?url2=3Ddraft-ietf-oauth-pop-architecture-06
>
>
> Please note that it may take a couple of minutes from the time of submi= ssion
> until the htmlized version and diff are available at tools.ietf.= org.
>
> 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<= br class=3D"">


<= br class=3D"">--
=09 3D"Ping=20
Brian C= ampbell
Distinguish= ed Engineer
Ping Identity
@ bcampbell@pingidentity.com<= /a>
3D"phone= +1 720.317.2061
3D"twitter"= @pingidentity
Connect with us!
3D"pingidentity.com"
= 3D"pingidentity.com" =3D"twitter 3D"twitter 3D"youtube 3D"LinkedIn 3D"Facebook 3D"G= 3D"slidesha= 3D"flipboard
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

<= /body>= --Apple-Mail-950D6303-5F66-4618-9490-2D0372185F83-- From nobody Wed Nov 25 12:20:41 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DAA71B2F5B for ; Wed, 25 Nov 2015 12:20:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G4i1pXY3uhUM for ; Wed, 25 Nov 2015 12:20:34 -0800 (PST) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::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 8F0B51B2F52 for ; Wed, 25 Nov 2015 12:20:34 -0800 (PST) Received: by qkas77 with SMTP id s77so20451570qka.0 for ; Wed, 25 Nov 2015 12:20:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=p5F8qJzC18FaAzfHa/atM2oHUnkEOlO7tj6M4kVTLbM=; b=HjqcYdzhujcC2UfPaX7n2r6/kEtjXyNcl2Wt42rUbKEb6kqMejofX8bjwYKn6yLZyW rFIUmwi0zjueHGeHn9bijMFU5jF/9unwSLScVAWjzTTVLYmkeebPFsQskf76hEwjKZSE pYLpJstJbQ18fWROmpH8bJBN2wEhvY/O/7Wszi3r3bjB9Pdt+F+q800bu1XljUXuhG+B C2Z70cS4oBH+1VyYe0Zz/5vr+GfKwy4ZbXCTD3rjNY1CNzn5uaRJ6S7h/XPcnnNmp7GN ZpecpkqXLyGu1gFTcC+yhRCuzIJkPgyNx7Tu1hmQxZwz+ns1++3AThCEVGUOJY37et1V ufeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=p5F8qJzC18FaAzfHa/atM2oHUnkEOlO7tj6M4kVTLbM=; b=EgFM/b87uAW+kwUvT+XlNoFFj1Ho04CizGJFrbPokAikSOxQ2sR32YHkMYo+CJl2eS eY7smpyuZfk/lq36nKqkhPggXDlKNrAkgoflj5etfj6TqgneZL7eJVOH63ZDbvHt1NPE fQVohnuBJkm5Ok24v037/g6rVd7MSgTLN3FCBcMh4YRtIFpmGtAf4wDJGdHzuY7bp3q4 mBLZPgLH3Mu5M+sMCqwZTVhvUHOTuFvbl0ajHTtURlWeqQDLA1n+6RKf16kpNJLjrBWU RQyWwlhj7BdffQfq4HOkDmNUyKZGRANxd9Vw7nWdm1MNF7mWoNSBhKvG+r4xS1V2ncmC +fnA== X-Gm-Message-State: ALoCoQlX2JeTigsnvzLgio74jmxmE8dlkjVvG1tg0Vz1UwdSFypOCyEAv7IIyF9UH/kStb2ttp+s X-Received: by 10.55.201.1 with SMTP id q1mr41582448qki.13.1448482833534; Wed, 25 Nov 2015 12:20:33 -0800 (PST) Received: from [192.168.1.216] ([191.115.122.254]) by smtp.gmail.com with ESMTPSA id v83sm5924888qhc.14.2015.11.25.12.20.20 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 25 Nov 2015 12:20:32 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_AED27604-C3DD-4769-B365-DF284D047E9A" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: John Bradley In-Reply-To: Date: Wed, 25 Nov 2015 17:20:09 -0300 Message-Id: <9E20E73C-AC35-4E03-A011-119A32CD0BF1@ve7jtb.com> References: <20151124200512.20833.28463.idtracker@ietfa.amsl.com> <16FAD3AC-CFB8-46D5-A12E-436E902EA439@oracle.com> <6015EE15-1FEE-43DC-930C-68ACAEDC083E@oracle.com> <38555799-721C-4A2F-AAAA-24D9B69EB72E@mit.edu> <1AD1F44B-9837-4288-9997-5292F1DBE30E@oracle.com> To: Phil Hunt X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-pop-architecture-06.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2015 20:20:40 -0000 --Apple-Mail=_AED27604-C3DD-4769-B365-DF284D047E9A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Tokens are signed or the information is otherwise integrity protected = between the AS and the RS. =20 I suspect Kathleen is concerned about the key getting modified in = transit. =20 That needs to be protected against, but there is more than one way to do = that. So sending the public key in a unsigned JWT access token would be = immensely stupid, not just for PoP but for scopes and everything else. In OAuth 2 all tokens need to be integrity protected between the AS and = RS. =20 That can be via signature, by having a reference with sufficient = entropy and secure introspection or database lookup. I think that is a OAuth 2 security consideration. We are adding a = additional confirmation claim to the existing information that needs to = be protected the same as the rest. John B. > On Nov 25, 2015, at 4:38 PM, Phil Hunt wrote: >=20 > > If there is agreement that tokens are opaque then the requirement that = tokens be signed must be removed from the threat mitigation = requirements.=20 >=20 > And the paragraph in sec 5 that brian was concerned about be restored.=20= >=20 > Phil >=20 > On Nov 25, 2015, at 11:24, Justin Richer > wrote: >=20 >> It is still end to end authentication with opaque tokens =E2=80=94 = since all OAuth tokens, including PoP tokens, have always been intended = to be opaque to the client. That hasn=E2=80=99t changed and that isn=E2=80= =99t the intent of this document. If that=E2=80=99s how people are = reading it then we need to pull it back and rewrite it so that=E2=80=99s = not the case. >>=20 >> The client gets a token that has two parts: the token and the key. = The token is analogous to the access_token we have today and would come = out of the server in the same field. The key is handed to the client = alongside the token or registered by the client during the token = request. Either way there=E2=80=99s an association between the two but = it=E2=80=99s not the same association as a public/private keypair.=20 >>=20 >> It=E2=80=99s possible to sign the token itself, but the client = doesn=E2=80=99t care. It sends the token and signs the HTTP request to = the RS whether the token is signed, unsigned, hex blob, encrypted, or = anything else. The same series of options are available as with bearer = tokens. PoP tokens have never, ever been intended to be anything but = opaque to the client. >>=20 >> The token can=E2=80=99t be opaque to the RS, which has to figure out = what key to use to check the message signature. But we=E2=80=99ve got = options there, like the embedded key in a JWT from Mike=E2=80=99s draft, = or doing introspection to get the key (from an extension that hasn=E2=80=99= t been written yet), or simply looking it up in the same database = because the RS and the AS are in the same box. Does this = structure/service/database choice sound familiar? It should, it=E2=80=99s = the same as bearer tokens. This is also how the RS gets information like = which scopes are associated with the token, if it=E2=80=99s expired, and = all that.=20 >>=20 >>=20 >>=20 >>=20 >> So here=E2=80=99s how I see it going on the wire: >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> (I just wrote this up so there are probably holes. Here=E2=80=99s the = source if anyone wants to tweak it: = http://www.websequencediagrams.com/?lz=3DcGFydGljaXBhbnQgQ2xpZW50IGFzIEMKA= AwMUmVzb3VyY2UgT3duZXIgYXMgUk8AFA1BdXRob3JpemF0aW9uIFNlcnYAIQZBUwA7DVByb3R= lY3RlZABICmFzIFJTCgoKClJPLS0 = -QzogR28gZ2V0IG15IHIAbwcKQy0tPlJPOiBSZWRpcmV= jdCB0byBBUy9BRQAvBkFTOiBMb2cgaW4sIGEAgQIHZSBjAIFHBQpBUwAqEwAVBwBrCEhhbmQAK= QcAPAUgZ3JhbnQKCmFsdCBzAIFGBnN1cHBsaWVkIGtleQpDAG4GVG9rZW4gcmVxdWVzdCAoADA= FKQpBUwCBDAZnZW5lcmF0ZSB0ACIFYW4ANwUva2V5cGFpcgAiBUMAPAgmIEsAEAtlbHMAgTcIA= E8pICYga2V5AGYYLCBhc3NvY2lhdGUgd2l0aACBQQUAcBIKZW5kCgpDLT5SUzogUgCBUQdpbmN= sdWRpbmcAgT4Lc2lnbmVkAEEKAIIkBnRydWN0dXJlZACBbQYKUlMARAZjaGVjawCCAAdzaWduY= XR1cmUgLyBkZWNyeXB0AB8PUGFycwCCLgcAOQlVbnBhY2sAgncFAIIYBWludHJvc3BlY3RpbwB= iBkFTOiBzZW4AdAcgKG5vdABiCikgdG8AJQ9BAIEVBwAvBWtleSAocHVibGljIG9yIHNoYXJlZ= CkAgwIGZGF0YWJhc2UAgUUJbG9vayB1cABhCGxvY2FsLwAtBiBEQikAHQthAIQoBgCCUAUAgX4= OAIQsCACCBAp1c2luZwCEWAUAGw9pZ2h0cwCDNQoAgm4HAIJbBgCCXQVDOiByZXR1cm4AhicJ&= s=3Dmodern-blue ) >>=20 >> The client is oblivious to the token just like always. This is = intentional. The RS has the same options to figure out how to process = the token. >>=20 >> =E2=80=94 Justin >>=20 >>> On Nov 25, 2015, at 2:03 PM, Phil Hunt > wrote: >>>=20 >>> Folks,=20 >>>=20 >>> >>> I did not want to go here either. :-) >>>=20 >>> I don=E2=80=99t read sec 6 as examples. I believe this may stem = from the pop-architecture documents having a dual role as both = =E2=80=9Carchitecture=E2=80=9D and =E2=80=9Cuse-case=E2=80=9D. Maybe we = should clarify the purpose of the document? >>>=20 >>> I believe section 6 is talking about threat mitigation assumptions = based on the examples that need to be implemented. I am assuming these = are requirements that the other specifications SHOULD implement. >>>=20 >>> >>> I do not believe we have discussed Opaque PoP tokens and any = inherent risks because the client is not or is unable to validate the = authenticity of the token. Does this introduce the possibility of a = MITM attack where a client can be convinced to sign requests for an = attacker? >>>=20 >>> If we want to include opaque PoP, I think we need to take a pause = and consider / discuss any threats here. >>>=20 >>> I find the desire for opaque PoP tokens to be a bit contradictory. = If we=E2=80=99re saying we don=E2=80=99t want to trust TLS alone (e.g. = because of load-balancer termination), why would we then say, but we are = perfectly willing to accept it worked for the OAuth AS exchanges? Maybe = I was very wrong here, but my assumption all along is that for PoP = we=E2=80=99re talking about end-to-end authentication of all parties = except in the case of 3.3 where we simply want to protect an access = token over a non-TLS HTTP connection. >>>=20 >>>=20 >>> Phil >>>=20 >>> @independentid >>> www.independentid.com = phil.hunt@oracle.com = >>>> On Nov 25, 2015, at 10:48 AM, Brian Campbell = > wrote: >>>>=20 >>>> While I can't say I disagree with the deeper existential questions = about the draft that Justin raises, I was trying not to go there and = rather just point out concerns with the newly added text.=20 >>>>=20 >>>> The text Phil cites from Sec 6 doesn't say the client must be able = to parse and verify the token. It's an assumption to simplify the = examples that follow and still the token is opaque to the client. I = reread the whole draft (reluctantly) and there's nothing that says the = token has to be non-opaque to the client. And it does talk about = reference style tokens and encrypted tokens, both of which rely on the = opaqueness to the client.=20 >>>>=20 >>>> On Wed, Nov 25, 2015 at 11:27 AM, Justin Richer > wrote: >>>> Right, I read that as text for describing the examples and not for = describing requirements. >>>>=20 >>>> The token itself doesn=E2=80=99t have to be signed at all. >>>>=20 >>>> =E2=80=94 Justin >>>>=20 >>>>> On Nov 25, 2015, at 1:05 PM, Phil Hunt > wrote: >>>>>=20 >>>>> Ok. Well this was requested by Kathleen because of this paragraph = in Sec 6.=E2=80=A6 >>>>>=20 >>>>> To simplify the subsequent description we assume in the PoP = architecture >>>>> that the token itself is digitally signed by the authorization = server >>>>> and therefore cannot be modified. >>>>>=20 >>>>> Please=20 >>>>> Phil >>>>>=20 >>>>> @independentid >>>>> www.independentid.com = phil.hunt@oracle.com = >>>>>> On Nov 25, 2015, at 9:33 AM, Justin Richer > wrote: >>>>>>=20 >>>>>> The token doesn=E2=80=99t have to be signed and the client = doesn=E2=80=99t have to verify the signature on the token. That=E2=80=99s = not PoP. The request has to be signed in a way that includes the token. = The token itself can still be opaque. The *key* material can=E2=80=99t = be opaque to the client, but the *token* material still is. >>>>>>=20 >>>>>> I agree with Brian that this statement is misleading. >>>>>>=20 >>>>>> The examples use a signed token but that is absolutely not a = requirement. Maybe the examples shouldn=E2=80=99t all use one style. >>>>>>=20 >>>>>> What=E2=80=99s most difficult about this particular spec is that = it=E2=80=99s very hand-wavy, saying =E2=80=9Cthis is kinda a thing that = kinda works like this=E2=80=9D without saying how to actually do it. = I=E2=80=99m honestly not sure it=E2=80=99s worth publishing as an RFC in = its own right but I=E2=80=99m not going to stand in its way. >>>>>>=20 >>>>>> =E2=80=94 Justin >>>>>>=20 >>>>>>> On Nov 25, 2015, at 12:14 PM, Brian Campbell = > wrote: >>>>>>>=20 >>>>>>> Where does it say that?=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> On Wed, Nov 25, 2015 at 8:44 AM, Phil Hunt > wrote: >>>>>>> Except that later on we require the token be signed and the = client verify that signed token. IOW mutual pop.=20 >>>>>>>=20 >>>>>>> Phil >>>>>>>=20 >>>>>>> On Nov 25, 2015, at 07:30, Brian Campbell = > wrote: >>>>>>>=20 >>>>>>>> Looking at the diff I noticed the following new text, which = seems to conflate bearer/PoP and opaqueness to the client. A client = demonstrating proof-of-possession of some key is orthogonal to the = client being able to parse and understand the access token itself.=20 >>>>>>>> =20 >>>>>>>> "In contrast to bearer tokens [RFC6750] which call for tokens = that are opaque to OAuth 2.0 clients, this specification defines the = requirements for proof-of-possession ("PoP") tokens that may be parsed = and verified by OAuth 2.0 clients and relying parties." >>>>>>>>=20 >>>>>>>> On Tue, Nov 24, 2015 at 1:07 PM, Phil Hunt = > wrote: >>>>>>>> This draft addresses review comments from Kathleen and Erik = raised since the last draft. >>>>>>>>=20 >>>>>>>> It may not include some of the discussion from yesterday/today. = I will add that as the group decides. >>>>>>>>=20 >>>>>>>> Cheers, >>>>>>>>=20 >>>>>>>> Phil >>>>>>>>=20 >>>>>>>> @independentid >>>>>>>> www.independentid.com >>>>>>>> phil.hunt@oracle.com >>>>>>>>=20 >>>>>>>> > On Nov 24, 2015, at 12:05 PM, internet-drafts@ietf.org = wrote: >>>>>>>> > >>>>>>>> > >>>>>>>> > A New Internet-Draft is available from the on-line = Internet-Drafts directories. >>>>>>>> > This draft is a work item of the Web Authorization Protocol = Working Group of the IETF. >>>>>>>> > >>>>>>>> > Title : OAuth 2.0 Proof-of-Possession (PoP) = Security Architecture >>>>>>>> > Authors : Phil Hunt >>>>>>>> > Justin Richer >>>>>>>> > William Mills >>>>>>>> > Prateek Mishra >>>>>>>> > Hannes Tschofenig >>>>>>>> > Filename : = draft-ietf-oauth-pop-architecture-06.txt >>>>>>>> > Pages : 23 >>>>>>>> > Date : 2015-11-24 >>>>>>>> > >>>>>>>> > Abstract: >>>>>>>> > The OAuth 2.0 bearer token specification, as defined in RFC = 6750, >>>>>>>> > allows any party in possession of a bearer token (a = "bearer") to get >>>>>>>> > access to the associated resources (without demonstrating = possession >>>>>>>> > of a cryptographic key). To prevent misuse, bearer tokens = must be >>>>>>>> > protected from disclosure in transit and at rest. >>>>>>>> > >>>>>>>> > Some scenarios demand additional security protection = whereby a client >>>>>>>> > needs to demonstrate possession of cryptographic keying = material when >>>>>>>> > accessing a protected resource. This document motivates = the >>>>>>>> > development of the OAuth 2.0 proof-of-possession security = mechanism. >>>>>>>> > >>>>>>>> > >>>>>>>> > The IETF datatracker status page for this draft is: >>>>>>>> > = https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architecture/ = >>>>>>>> > >>>>>>>> > There's also a htmlized version available at: >>>>>>>> > = https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-06 = >>>>>>>> > >>>>>>>> > A diff from the previous version is available at: >>>>>>>> > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-pop-architecture-06 = = >>>>>>>> > >>>>>>>> > >>>>>>>> > 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 = >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing list >>>>>>>> OAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> --=20 >>>>>>>> =09 >>>>>>>> Brian Campbell >>>>>>>> Distinguished Engineer >>>>>>>> Ping Identity >>>>>>>> @ bcampbell@pingidentity.com = >>>>>>>> +1 720.317.2061 >>>>>>>> @pingidentity >>>>>>>> Connect with us! >>>>>>>> = >>>>>>>> = = = = = = = = >>>>>>>=20 >>>>>>>=20 >>>>>>> --=20 >>>>>>> =09 >>>>>>> Brian Campbell >>>>>>> Distinguished Engineer >>>>>>> Ping Identity >>>>>>> @ bcampbell@pingidentity.com = >>>>>>> +1 720.317.2061 >>>>>>> @pingidentity >>>>>>> Connect with us! >>>>>>> >>>>>>> = = = = = = = = _____________________________________= __________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> --=20 >>>> =09 >>>> Brian Campbell >>>> Distinguished Engineer >>>> Ping Identity >>>> @ bcampbell@pingidentity.com >>>> +1 720.317.2061 >>>> @pingidentity >>>> Connect with us! >>>> >>>> = = = = = = = = >>=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_AED27604-C3DD-4769-B365-DF284D047E9A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Tokens are signed or the information is otherwise integrity = protected between the AS and the RS.  

I suspect Kathleen is concerned about = the key getting modified in transit.   
That needs to be protected against, but there is more than = one way to do that.

So sending the public key in a unsigned JWT access token = would be immensely stupid,  not just for PoP but for scopes and = everything else.

In OAuth 2 all tokens need to be integrity protected between = the AS and RS.  
That can be via signature, =  by having a reference with sufficient entropy and secure = introspection or database lookup.

I think that is a OAuth 2 security = consideration.   We are adding a additional confirmation claim to = the existing information that needs to be protected the same as the = rest.

John = B.


On = Nov 25, 2015, at 4:38 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

<editors = hat>
If there is agreement that tokens are = opaque then the requirement that tokens be signed must be removed from = the threat mitigation requirements. 

And the paragraph in sec 5 that brian = was concerned about be restored. 

Phil

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

It is still end to end = authentication with opaque tokens =E2=80=94 since all OAuth tokens, = including PoP tokens, have always been intended to be opaque to the = client. That hasn=E2=80=99t changed and that isn=E2=80=99t the intent of = this document. If that=E2=80=99s how people are reading it then we need = to pull it back and rewrite it so that=E2=80=99s not the case.

The client gets a token = that has two parts: the token and the key. The token is analogous to the = access_token we have today and would come out of the server in the same = field. The key is handed to the client alongside the token or registered = by the client during the token request. Either way there=E2=80=99s an = association between the two but it=E2=80=99s not the same association as = a public/private keypair. 

It=E2=80=99s possible to sign the token = itself, but the client doesn=E2=80=99t care. It sends the token and = signs the HTTP request to the RS whether the token is signed, unsigned, = hex blob, encrypted, or anything else. The same series of options are = available as with bearer tokens. PoP tokens have never, ever been = intended to be anything but opaque to the client.
The token can=E2=80=99t be opaque to = the RS, which has to figure out what key to use to check the message = signature. But we=E2=80=99ve got options there, like the embedded key in = a JWT from Mike=E2=80=99s draft, or doing introspection to get the key = (from an extension that hasn=E2=80=99t been written yet), or simply = looking it up in the same database because the RS and the AS are in the = same box. Does this structure/service/database choice sound familiar? It = should, it=E2=80=99s the same as bearer tokens. This is also how the RS = gets information like which scopes are associated with the token, if = it=E2=80=99s expired, and all that. 




So = here=E2=80=99s how I see it going on the wire:



3D"http://www.websequencediagrams.com/cgi-bin/cdraw?lz=3DcGFydGljaXBhb=



(I just wrote this up so there are = probably holes. Here=E2=80=99s the source if anyone wants to tweak = it: http://www.websequencediagrams.com/?lz=3DcGFydGljaXBhbnQgQ2xpZW= 50IGFzIEMKAAwMUmVzb3VyY2UgT3duZXIgYXMgUk8AFA1BdXRob3JpemF0aW9uIFNlcnYAIQZB= UwA7DVByb3RlY3RlZABICmFzIFJTCgoKClJPLS0-QzogR28gZ2V0IG15IHIAbwcKQy0tPl= JPOiBSZWRpcmVjdCB0byBBUy9BRQAvBkFTOiBMb2cgaW4sIGEAgQIHZSBjAIFHBQpBUwAqEwAV= BwBrCEhhbmQAKQcAPAUgZ3JhbnQKCmFsdCBzAIFGBnN1cHBsaWVkIGtleQpDAG4GVG9rZW4gcm= VxdWVzdCAoADAFKQpBUwCBDAZnZW5lcmF0ZSB0ACIFYW4ANwUva2V5cGFpcgAiBUMAPAgmIEsA= EAtlbHMAgTcIAE8pICYga2V5AGYYLCBhc3NvY2lhdGUgd2l0aACBQQUAcBIKZW5kCgpDLT5SUz= ogUgCBUQdpbmNsdWRpbmcAgT4Lc2lnbmVkAEEKAIIkBnRydWN0dXJlZACBbQYKUlMARAZjaGVj= awCCAAdzaWduYXR1cmUgLyBkZWNyeXB0AB8PUGFycwCCLgcAOQlVbnBhY2sAgncFAIIYBWludH= Jvc3BlY3RpbwBiBkFTOiBzZW4AdAcgKG5vdABiCikgdG8AJQ9BAIEVBwAvBWtleSAocHVibGlj= IG9yIHNoYXJlZCkAgwIGZGF0YWJhc2UAgUUJbG9vayB1cABhCGxvY2FsLwAtBiBEQikAHQthAI= QoBgCCUAUAgX4OAIQsCACCBAp1c2luZwCEWAUAGw9pZ2h0cwCDNQoAgm4HAIJbBgCCXQVDOiBy= ZXR1cm4AhicJ&s=3Dmodern-blue )

The client is oblivious to the token = just like always. This is intentional. The RS has the same options to = figure out how to process the token.

 =E2=80=94 Justin

On Nov 25, 2015, at 2:03 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

Folks, 
<editor = hat>
I did not want to go here either. = :-)

I don=E2=80=99= t read sec 6 as examples.  I believe this may stem from the = pop-architecture documents having a dual role as both =E2=80=9Carchitectur= e=E2=80=9D and =E2=80=9Cuse-case=E2=80=9D.  Maybe we should clarify = the purpose of the document?

I believe section 6 is talking about = threat mitigation assumptions based on the examples that need to be = implemented.  I am assuming these are requirements that the other = specifications SHOULD implement.

<personal hat>
I do not believe we have discussed Opaque PoP tokens and any = inherent risks because the client is not or is unable to validate the = authenticity of the token.  Does this introduce the possibility of = a MITM attack where a client can be convinced to sign requests for an = attacker?

If = we want to include opaque PoP, I think we need to take a pause and = consider / discuss any threats here.

I find the desire for opaque PoP tokens = to be a bit contradictory. If we=E2=80=99re saying we don=E2=80=99t want = to trust TLS alone (e.g. because of load-balancer termination), why = would we then say, but we are perfectly willing to accept it worked for = the OAuth AS exchanges?  Maybe I was very wrong here, but my = assumption all along is that for PoP we=E2=80=99re talking about = end-to-end authentication of all parties except in the case of 3.3 where = we simply want to protect an access token over a non-TLS HTTP = connection.



On Nov 25, 2015, at 10:48 AM, Brian Campbell <bcampbell@pingidentity.com> wrote:

While I can't say I disagree = with the deeper existential questions about the draft that Justin = raises, I was trying not to go there and rather just point out concerns = with the newly added text.

The text = Phil cites from Sec 6 doesn't say the client must be able to parse and = verify the token. It's an assumption to simplify the examples that = follow and still the token is opaque to the client. I reread the whole = draft (reluctantly) and there's nothing that says the token has to be = non-opaque to the client. And it does talk about reference style tokens = and encrypted tokens, both of which rely on the opaqueness to the = client.

On Wed, Nov 25, 2015 at 11:27 AM, = Justin Richer <jricher@mit.edu> wrote:
Right, I read that as text for describing the examples and = not for describing requirements.

The token itself doesn=E2=80=99t have to be signed at = all.

 =E2=80=94 = Justin

On Nov 25, 2015, at 1:05 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

Ok. Well this was = requested by Kathleen because of this paragraph in Sec 6.=E2=80=A6

   =
To simplify the subsequent description we assume in the PoP =
architecture
   =
that the token itself is digitally signed by the authorization server

   and therefore cannot be modified.

Please 

On Nov 25, 2015, at 9:33 AM, Justin Richer <jricher@mit.edu> wrote:

The token = doesn=E2=80=99t have to be signed and the client doesn=E2=80=99t have to = verify the signature on the token. That=E2=80=99s not PoP. The request = has to be signed in a way that includes the token. The token itself can = still be opaque. The *key* material can=E2=80=99t be opaque to the = client, but the *token* material still is.

I agree with Brian that this statement = is misleading.

The examples use a signed token but that is absolutely not a = requirement. Maybe the examples shouldn=E2=80=99t all use one = style.

What=E2=80= =99s most difficult about this particular spec is that it=E2=80=99s very = hand-wavy, saying =E2=80=9Cthis is kinda a thing that kinda works like = this=E2=80=9D without saying how to actually do it. I=E2=80=99m honestly = not sure it=E2=80=99s worth publishing as an RFC in its own right but = I=E2=80=99m not going to stand in its way.

 =E2=80=94 Justin

On Nov 25, 2015, at 12:14 PM, Brian Campbell = <bcampbell@pingidentity.com> wrote:

Where does it say = that?



On Wed, = Nov 25, 2015 at 8:44 AM, Phil Hunt <phil.hunt@oracle.com> wrote:
Except that later on we require the token be = signed and the client verify that signed token. IOW mutual = pop. 

Phil

On Nov 25, 2015, at 07:30, = Brian Campbell <bcampbell@pingidentity.com> = wrote:

Looking at the = diff I noticed the following new text, which seems to conflate = bearer/PoP and opaqueness to the client. A client demonstrating = proof-of-possession of some key is orthogonal to the client being able = to parse and understand the access token itself.
 
"In contrast to bearer tokens [RFC6750] which call for tokens = that are opaque to OAuth 2.0 clients, this specification defines the = requirements for proof-of-possession ("PoP") tokens that may be parsed = and verified by OAuth 2.0 clients and relying parties."

On Tue, Nov 24, 2015 at 1:07 PM, Phil Hunt <phil.hunt@oracle.com> = wrote:
This draft = addresses review comments from Kathleen and Erik raised since the last = draft.

It may not include some of the discussion from yesterday/today.  I = will add that as the group decides.

Cheers,

Phil

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

> On Nov 24, 2015, at 12:05 PM, internet-drafts@ietf.org wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts = directories.
> This draft is a work item of the Web Authorization Protocol Working = Group of the IETF.
>
>        Title          =  : OAuth 2.0 Proof-of-Possession (PoP) Security Architecture
>        Authors        =  : Phil Hunt
>                  =         Justin Richer
>                  =         William Mills
>                  =         Prateek Mishra
>                  =         Hannes Tschofenig
>       Filename        : = draft-ietf-oauth-pop-architecture-06.txt
>       Pages          =  : 23
>       Date          =   : 2015-11-24
>
> Abstract:
>   The OAuth 2.0 bearer token specification, as defined in = RFC 6750,
>   allows any party in possession of a bearer token (a = "bearer") to get
>   access to the associated resources (without = demonstrating possession
>   of a cryptographic key).  To prevent misuse, = bearer tokens must be
>   protected from disclosure in transit and at rest.
>
>   Some scenarios demand additional security protection = whereby a client
>   needs to demonstrate possession of cryptographic keying = material when
>   accessing a protected resource.  This document = motivates the
>   development of the OAuth 2.0 proof-of-possession = security mechanism.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architect= ure/
>
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-0= 6
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-pop-archit= ecture-06
>
>
> 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



--
=09 3D"Ping=20
Brian Campbell
Distinguished Engineer
Ping = Identity
@ bcampbell@pingidentity.com
3D"phone" +1 720.317.2061
3D"twitter" @pingidentity
Connect with = us!
3D"pingidentity.com"
=
3D"pingidentity.com"
= 3D"twitter 3D"twitter 3D"youtube 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard= 3D"rss


--
=09 3D"Ping=20
Brian Campbell
Distinguished Engineer
Ping = Identity
@ bcampbell@pingidentity.com
3D"phone" +1 720.317.2061
3D"twitter" @pingidentity
Connect with = us!
3D"pingidentity.com"
=
3D"pingidentity.com"
= 3D"twitter 3D"twitter 3D"youtube 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard= 3D"rss
_______________________________________________
OAuth = mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth






--
=09 3D"Ping=20
Brian Campbell
Distinguished Engineer
Ping Identity
@ bcampbell@pingidentity.com
3D"phone" +1 720.317.2061
3D"twitter" @pingidentity
Connect with = us!
3D"pingidentity.com"
=
3D"pingidentity.com"
= 3D"twitter 3D"twitter 3D"youtube 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard 3D"rss


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

= --Apple-Mail=_AED27604-C3DD-4769-B365-DF284D047E9A-- From nobody Wed Nov 25 12:21:48 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93CDD1B2F52 for ; Wed, 25 Nov 2015 12:21:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.775 X-Spam-Level: X-Spam-Status: No, score=-4.775 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z0enHNx-3_6L for ; Wed, 25 Nov 2015 12:21:42 -0800 (PST) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) by ietfa.amsl.com (Postfix) with ESMTP id 7DB1D1B2F57 for ; Wed, 25 Nov 2015 12:21:42 -0800 (PST) X-AuditID: 12074422-f79c46d000006aa7-7d-56561855c01c Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id B1.A1.27303.55816565; Wed, 25 Nov 2015 15:21:41 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id tAPKLeBF028903; Wed, 25 Nov 2015 15:21:41 -0500 Received: from artemisia.richer.local (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id tAPKLcEA010652 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 25 Nov 2015 15:21:40 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_A05AE503-8740-4726-AC73-1D5819887E71" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Justin Richer In-Reply-To: Date: Wed, 25 Nov 2015 15:21:38 -0500 Message-Id: References: <20151124200512.20833.28463.idtracker@ietfa.amsl.com> <16FAD3AC-CFB8-46D5-A12E-436E902EA439@oracle.com> To: Phil Hunt X-Mailer: Apple Mail (2.2104) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprHKsWRmVeSWpSXmKPExsUixCmqrRsqERZmMHONtsXJt6/YLBbMb2S3 WH33L5sDs8eSJT+ZPD4+vcXicfv2RpYA5igum5TUnMyy1CJ9uwSujIePXzEVPLjGWHGneT5r A+O6nYxdjJwcEgImEh8Or2eBsMUkLtxbz9bFyMUhJLCYSWLd/15GCGcjo8SN6duYIZyHTBJT /ixkBWlhFkiQ6JxyBWwUr4CexKtbl8HiwgI+EhdPPwGz2QRUJaavaWECsTkF7CS+rfsPto4F KN6/YRUzxBxPiT3PLkDNsZKY8no9K8Syc0wS2579YgdJiAioSHy7eh3qblmJ3b8fMU1gFJiF 5I5ZSO6AiGtLLFv4mhnC1pTY372cBVNcQ6Lz20TWBYxsqxhlU3KrdHMTM3OKU5N1i5MT8/JS i3RN9XIzS/RSU0o3MYKigd1FaQfjz4NKhxgFOBiVeHgnPAoJE2JNLCuuzD3EKMnBpCTKa8kR FibEl5SfUpmRWJwRX1Sak1p8iFGCg1lJhHfbh9AwId6UxMqq1KJ8mJQ0B4uSOO/cL75hQgLp iSWp2ampBalFMFkZDg4lCd7zYkBDBYtS01Mr0jJzShDSTBycIMN5gIaHgtTwFhck5hZnpkPk TzEqSonzXgVJCIAkMkrz4HpBySrh7WHTV4ziQK8I80qLA1XxABMdXPcroMFMQIMjckCuLi5J REhJNTDOsZJgLbDqfr1XqpV7zbTik+9/Buv/T7fc61YVsuu9tUVY/vuyl6zSJ8Qmzsl7pX1d J+yx59YTFZWyk2fpv1/nwlj9xNkqr11zWrXl1rCYm4cFjpxwjBcQNdEueOobNTP0cJTTORPn vQUuGq8eN9goTNzndqq6//UXnqyO/LKNS43kdsdETVNiKc5INNRiLipOBACUzihBMQMAAA== Archived-At: Cc: "" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-pop-architecture-06.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2015 20:21:46 -0000 --Apple-Mail=_A05AE503-8740-4726-AC73-1D5819887E71 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The only actual requirement is opacity. Section 6 should be more clearly = called out as an example instead, which is what it is. Perhaps we should also re-state that access tokens remain opaque to the = client in the introductory text. =E2=80=94 Justin > On Nov 25, 2015, at 3:19 PM, Phil Hunt wrote: >=20 > Thats not what I am on about.=20 >=20 > Kathleen objected to the signed requirement in sec 6 without making it = clear in sec 5.=20 >=20 > We can't have it both ways. Be both opaque and signed for the client = to verify. =20 >=20 > If I restore the requirements than the threat mitigation assumption of = signed tokens must also be removed.=20 >=20 > Phil >=20 > On Nov 25, 2015, at 12:02, John Bradley > wrote: >=20 >> The token is opaque to the client. It=E2=80=99s format is a matter = between the RS and the AS.=20 >>=20 >> Where do we require the client verify the token? The RS is the = only party that needs to verify the access token. >>=20 >> The information that the client needs about the token is in = additional meta-data delivered with but not in the AT. >>=20 >> I agree with Brian that is wrong on two counts. >>=20 >> 1) the token is opaque to the client. >> 2) one method of delivering the key to the RS is in a signed JWT. It = is however also possible (if not ideal) for the AT to be a reference, = and introspected by the RS to get the key. >>=20 >> So=20 >> "In contrast to bearer tokens [RFC6750] which call for tokens that = are opaque to OAuth 2.0 clients, this specification defines the = requirements for proof-of-possession ("PoP") tokens that may are also = opaque to OAuth 2.0 clients but may be parsed and verified, or = introspected by OAuth 2.0 Resource Servers. When token endpoints issue = =E2=80=9CPoP=E2=80=9D tokens they provide the OAuth Client additional = parameters with information on what key material to use for the = proof.=E2=80=9D >>=20 >> Or given that they are both opaque that part of the statement could = be dropped. >>=20 >> John B.=20 >>=20 >>=20 >>> On Nov 25, 2015, at 12:44 PM, Phil Hunt > wrote: >>>=20 >>> Except that later on we require the token be signed and the client = verify that signed token. IOW mutual pop.=20 >>>=20 >>> Phil >>>=20 >>> On Nov 25, 2015, at 07:30, Brian Campbell = > wrote: >>>=20 >>>> Looking at the diff I noticed the following new text, which seems = to conflate bearer/PoP and opaqueness to the client. A client = demonstrating proof-of-possession of some key is orthogonal to the = client being able to parse and understand the access token itself.=20 >>>> =20 >>>> "In contrast to bearer tokens [RFC6750] which call for tokens that = are opaque to OAuth 2.0 clients, this specification defines the = requirements for proof-of-possession ("PoP") tokens that may be parsed = and verified by OAuth 2.0 clients and relying parties." >>>>=20 >>>> On Tue, Nov 24, 2015 at 1:07 PM, Phil Hunt > wrote: >>>> This draft addresses review comments from Kathleen and Erik raised = since the last draft. >>>>=20 >>>> It may not include some of the discussion from yesterday/today. I = will add that as the group decides. >>>>=20 >>>> Cheers, >>>>=20 >>>> Phil >>>>=20 >>>> @independentid >>>> www.independentid.com >>>> phil.hunt@oracle.com >>>>=20 >>>> > On Nov 24, 2015, at 12:05 PM, internet-drafts@ietf.org = wrote: >>>> > >>>> > >>>> > A New Internet-Draft is available from the on-line = Internet-Drafts directories. >>>> > This draft is a work item of the Web Authorization Protocol = Working Group of the IETF. >>>> > >>>> > Title : OAuth 2.0 Proof-of-Possession (PoP) = Security Architecture >>>> > Authors : Phil Hunt >>>> > Justin Richer >>>> > William Mills >>>> > Prateek Mishra >>>> > Hannes Tschofenig >>>> > Filename : draft-ietf-oauth-pop-architecture-06.txt >>>> > Pages : 23 >>>> > Date : 2015-11-24 >>>> > >>>> > Abstract: >>>> > The OAuth 2.0 bearer token specification, as defined in RFC = 6750, >>>> > allows any party in possession of a bearer token (a "bearer") = to get >>>> > access to the associated resources (without demonstrating = possession >>>> > of a cryptographic key). To prevent misuse, bearer tokens must = be >>>> > protected from disclosure in transit and at rest. >>>> > >>>> > Some scenarios demand additional security protection whereby a = client >>>> > needs to demonstrate possession of cryptographic keying = material when >>>> > accessing a protected resource. This document motivates the >>>> > development of the OAuth 2.0 proof-of-possession security = mechanism. >>>> > >>>> > >>>> > The IETF datatracker status page for this draft is: >>>> > = https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architecture/ = >>>> > >>>> > There's also a htmlized version available at: >>>> > https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-06 = >>>> > >>>> > A diff from the previous version is available at: >>>> > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-pop-architecture-06 = = >>>> > >>>> > >>>> > 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 = >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>=20 >>>>=20 >>>>=20 >>>> --=20 >>>> =09 >>>> Brian Campbell >>>> Distinguished Engineer >>>> Ping Identity >>>> @ bcampbell@pingidentity.com >>>> +1 720.317.2061 >>>> @pingidentity >>>> Connect with us! >>>> >>>> = = = = = = = = _____________________________________= __________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth = >>=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_A05AE503-8740-4726-AC73-1D5819887E71 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 The only actual requirement is opacity. Section 6 should be = more clearly called out as an example instead, which is what it is.

Perhaps we should also = re-state that access tokens remain opaque to the client in the = introductory text.

 =E2=80=94 Justin

On = Nov 25, 2015, at 3:19 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

Thats not what I = am on about. 

Kathleen objected to the signed requirement in sec 6 without = making it clear in sec 5. 

We can't have it both ways. Be both = opaque and signed for the client to verify.  

If I restore the = requirements than the threat mitigation assumption of signed tokens must = also be removed. 

Phil

On Nov 25, 2015, at 12:02, John Bradley <ve7jtb@ve7jtb.com> = wrote:

The token is opaque to the client. =  It=E2=80=99s format is a matter between the RS and the = AS. 

Where do = we require the client verify the token?    The RS is the only = party that needs to verify the access token.

The information that the client needs = about the token is in additional meta-data delivered with but not in the = AT.

I agree = with Brian that is wrong on two counts.

1) the token is opaque to the = client.
2) one method of delivering the key to the = RS is in a signed JWT.  It is however also possible (if not ideal) = for the AT to be a reference, and introspected by the RS to get the = key.

So 
"In contrast to bearer tokens = [RFC6750] which call for tokens that are opaque to OAuth 2.0 clients, = this specification defines the requirements for proof-of-possession = ("PoP") tokens that may are also opaque to OAuth 2.0 clients but may be = parsed and verified, or introspected by OAuth 2.0 Resource Servers. When = token endpoints issue =E2=80=9CPoP=E2=80=9D tokens they provide the = OAuth Client additional parameters with information on what key material = to use for the proof.=E2=80=9D

Or given that they are both = opaque that part of the statement could be dropped.

John = B. 


On Nov = 25, 2015, at 12:44 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

Except that later on we require the token be = signed and the client verify that signed token. IOW mutual pop. 

Phil

On = Nov 25, 2015, at 07:30, Brian Campbell <bcampbell@pingidentity.com> wrote:

Looking at the diff I noticed the following new = text, which seems to conflate bearer/PoP and opaqueness to the client. A = client demonstrating proof-of-possession of some key is orthogonal to = the client being able to parse and understand the access token itself. =
 
"In contrast to bearer tokens = [RFC6750] which call for tokens that are opaque to OAuth 2.0 clients, = this specification defines the requirements for proof-of-possession = ("PoP") tokens that may be parsed and verified by OAuth 2.0 clients and = relying parties."

On Tue, Nov 24, 2015 at 1:07 PM, = Phil Hunt <phil.hunt@oracle.com> wrote:
This draft addresses = review comments from Kathleen and Erik raised since the last draft.

It may not include some of the discussion from yesterday/today.  I = will add that as the group decides.

Cheers,

Phil

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

> On Nov 24, 2015, at 12:05 PM, internet-drafts@ietf.org wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts = directories.
> This draft is a work item of the Web Authorization Protocol Working = Group of the IETF.
>
>        Title          =  : OAuth 2.0 Proof-of-Possession (PoP) Security Architecture
>        Authors        =  : Phil Hunt
>                  =         Justin Richer
>                  =         William Mills
>                  =         Prateek Mishra
>                  =         Hannes Tschofenig
>       Filename        : = draft-ietf-oauth-pop-architecture-06.txt
>       Pages          =  : 23
>       Date          =   : 2015-11-24
>
> Abstract:
>   The OAuth 2.0 bearer token specification, as defined in = RFC 6750,
>   allows any party in possession of a bearer token (a = "bearer") to get
>   access to the associated resources (without = demonstrating possession
>   of a cryptographic key).  To prevent misuse, = bearer tokens must be
>   protected from disclosure in transit and at rest.
>
>   Some scenarios demand additional security protection = whereby a client
>   needs to demonstrate possession of cryptographic keying = material when
>   accessing a protected resource.  This document = motivates the
>   development of the OAuth 2.0 proof-of-possession = security mechanism.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architect= ure/
>
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-0= 6
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-pop-archit= ecture-06
>
>
> 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



--
=09 3D"Ping=20
Brian Campbell
Distinguished Engineer
Ping Identity
@ bcampbell@pingidentity.com
3D"phone" +1 720.317.2061
3D"twitter" @pingidentity
Connect with = us!
3D"pingidentity.com"
=
3D"pingidentity.com"
= 3D"twitter 3D"twitter 3D"youtube 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard 3D"rss
=
_______________________________________________OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

= --Apple-Mail=_A05AE503-8740-4726-AC73-1D5819887E71-- From nobody Wed Nov 25 12:25:19 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 336D31B2F75 for ; Wed, 25 Nov 2015 12:25:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u92XZxAG0_GB for ; Wed, 25 Nov 2015 12:25:12 -0800 (PST) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::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 9AD1F1B2F65 for ; Wed, 25 Nov 2015 12:25:11 -0800 (PST) Received: by qkao63 with SMTP id o63so20274321qka.2 for ; Wed, 25 Nov 2015 12:25:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=x2i5misi8AKB7eXj/r7Q9KKfjgfMALudv3NSoiMdB1M=; b=wNfmCJNA/nDzyr8tzqBTLY6oMBBTHQwcXAl1Zd6E4F5BY1wqz+SWcdxzlVnApQwWPe r/5ym3Mfax/CnJWH1D/Dyvb4Kx46CrfXBdv0H29oUpE2RZ5UGIZribrBXklSIIDGC7Jd xD0oZsqDxmRrCGTB5zoqKn9/N7RdzAvsQD26m8P/P+05Ttl1AfgG3w+DNqg8HfusqEtL JtTgqpPfaaA8JPG2pLCHTvZMqF6++RBeCv78Tgojr/oCj4Z3YTcXU22u+mLP2/TuUdPK onyrlgAWwdi8V6Qw9I5fz38yoIPUrPEfk6AzQiw3wDTZCZy9aNjl3vW/QaHt/vacD2vU hr5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=x2i5misi8AKB7eXj/r7Q9KKfjgfMALudv3NSoiMdB1M=; b=cj6YLSvL2qkShrDifsQVlrz722Lj50flA1QR4DV7GPzj5Y4EbT9Hx4EOmnVz95OCbG Vm7e/a2f/Ld8/uqFpawuSy+3hJbGFwITp1mMAB4zDu7U99tfpsI86soXBwK0r2WyPEtY YB4pX+OHURV3o1baBG48um/aCETOBeuPm/FVNCouLNZibgBP2vARR2WTw0RzAhgTXisP uiqaCqbhMLpXETrjfO6Z5dUX0OvsUSE6yfvegNJxtb3LpIV5nFzP8xRUIGkMJQO4gx8Z 1CSi29snHTNzzB8HPLbQ7HFzy/lA9eswGOROEQDvDjOTnyNoWbdGq2wriCUR8UZhJjWG CUMw== X-Gm-Message-State: ALoCoQmVAxoMqBX+R6W82/vbcv2j//L+2N1wJWaGfB1EtxeIjxWYP3+Df5vXWVTWqJ8cj8Yiq0KB X-Received: by 10.55.76.213 with SMTP id z204mr41201425qka.58.1448483110701; Wed, 25 Nov 2015 12:25:10 -0800 (PST) Received: from [192.168.1.216] ([191.115.122.254]) by smtp.gmail.com with ESMTPSA id u59sm5995930qge.0.2015.11.25.12.24.55 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 25 Nov 2015 12:25:09 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_B1BF3DD0-B80D-4C79-B287-4BF5FA47E84D" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: John Bradley In-Reply-To: Date: Wed, 25 Nov 2015 17:24:45 -0300 Message-Id: References: <20151124200512.20833.28463.idtracker@ietfa.amsl.com> <16FAD3AC-CFB8-46D5-A12E-436E902EA439@oracle.com> To: Phil Hunt X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-pop-architecture-06.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2015 20:25:18 -0000 --Apple-Mail=_B1BF3DD0-B80D-4C79-B287-4BF5FA47E84D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The client is verifying the certificate of the token endpoint not the = signature of the token. =20 That is why It is still vulnerable to man in the middle attacks=20 There is no guarantee that the signing key for the AT is one that the = client has any way to verify. =20 The client checking the signature would not stop a man in the middle = attack. John B. > On Nov 25, 2015, at 5:19 PM, Phil Hunt wrote: >=20 > Thats not what I am on about.=20 >=20 > Kathleen objected to the signed requirement in sec 6 without making it = clear in sec 5.=20 >=20 > We can't have it both ways. Be both opaque and signed for the client = to verify. =20 >=20 > If I restore the requirements than the threat mitigation assumption of = signed tokens must also be removed.=20 >=20 > Phil >=20 > On Nov 25, 2015, at 12:02, John Bradley > wrote: >=20 >> The token is opaque to the client. It=E2=80=99s format is a matter = between the RS and the AS.=20 >>=20 >> Where do we require the client verify the token? The RS is the = only party that needs to verify the access token. >>=20 >> The information that the client needs about the token is in = additional meta-data delivered with but not in the AT. >>=20 >> I agree with Brian that is wrong on two counts. >>=20 >> 1) the token is opaque to the client. >> 2) one method of delivering the key to the RS is in a signed JWT. It = is however also possible (if not ideal) for the AT to be a reference, = and introspected by the RS to get the key. >>=20 >> So=20 >> "In contrast to bearer tokens [RFC6750] which call for tokens that = are opaque to OAuth 2.0 clients, this specification defines the = requirements for proof-of-possession ("PoP") tokens that may are also = opaque to OAuth 2.0 clients but may be parsed and verified, or = introspected by OAuth 2.0 Resource Servers. When token endpoints issue = =E2=80=9CPoP=E2=80=9D tokens they provide the OAuth Client additional = parameters with information on what key material to use for the = proof.=E2=80=9D >>=20 >> Or given that they are both opaque that part of the statement could = be dropped. >>=20 >> John B.=20 >>=20 >>=20 >>> On Nov 25, 2015, at 12:44 PM, Phil Hunt > wrote: >>>=20 >>> Except that later on we require the token be signed and the client = verify that signed token. IOW mutual pop.=20 >>>=20 >>> Phil >>>=20 >>> On Nov 25, 2015, at 07:30, Brian Campbell = > wrote: >>>=20 >>>> Looking at the diff I noticed the following new text, which seems = to conflate bearer/PoP and opaqueness to the client. A client = demonstrating proof-of-possession of some key is orthogonal to the = client being able to parse and understand the access token itself.=20 >>>> =20 >>>> "In contrast to bearer tokens [RFC6750] which call for tokens that = are opaque to OAuth 2.0 clients, this specification defines the = requirements for proof-of-possession ("PoP") tokens that may be parsed = and verified by OAuth 2.0 clients and relying parties." >>>>=20 >>>> On Tue, Nov 24, 2015 at 1:07 PM, Phil Hunt > wrote: >>>> This draft addresses review comments from Kathleen and Erik raised = since the last draft. >>>>=20 >>>> It may not include some of the discussion from yesterday/today. I = will add that as the group decides. >>>>=20 >>>> Cheers, >>>>=20 >>>> Phil >>>>=20 >>>> @independentid >>>> www.independentid.com >>>> phil.hunt@oracle.com >>>>=20 >>>> > On Nov 24, 2015, at 12:05 PM, internet-drafts@ietf.org = wrote: >>>> > >>>> > >>>> > A New Internet-Draft is available from the on-line = Internet-Drafts directories. >>>> > This draft is a work item of the Web Authorization Protocol = Working Group of the IETF. >>>> > >>>> > Title : OAuth 2.0 Proof-of-Possession (PoP) = Security Architecture >>>> > Authors : Phil Hunt >>>> > Justin Richer >>>> > William Mills >>>> > Prateek Mishra >>>> > Hannes Tschofenig >>>> > Filename : draft-ietf-oauth-pop-architecture-06.txt >>>> > Pages : 23 >>>> > Date : 2015-11-24 >>>> > >>>> > Abstract: >>>> > The OAuth 2.0 bearer token specification, as defined in RFC = 6750, >>>> > allows any party in possession of a bearer token (a "bearer") = to get >>>> > access to the associated resources (without demonstrating = possession >>>> > of a cryptographic key). To prevent misuse, bearer tokens must = be >>>> > protected from disclosure in transit and at rest. >>>> > >>>> > Some scenarios demand additional security protection whereby a = client >>>> > needs to demonstrate possession of cryptographic keying = material when >>>> > accessing a protected resource. This document motivates the >>>> > development of the OAuth 2.0 proof-of-possession security = mechanism. >>>> > >>>> > >>>> > The IETF datatracker status page for this draft is: >>>> > = https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architecture/ = >>>> > >>>> > There's also a htmlized version available at: >>>> > https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-06 = >>>> > >>>> > A diff from the previous version is available at: >>>> > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-pop-architecture-06 = = >>>> > >>>> > >>>> > 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 = >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>=20 >>>>=20 >>>>=20 >>>> --=20 >>>> =09 >>>> Brian Campbell >>>> Distinguished Engineer >>>> Ping Identity >>>> @ bcampbell@pingidentity.com >>>> +1 720.317.2061 >>>> @pingidentity >>>> Connect with us! >>>> >>>> = = = = = = = = _____________________________________= __________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth = >>=20 --Apple-Mail=_B1BF3DD0-B80D-4C79-B287-4BF5FA47E84D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 The client is verifying the certificate of the token endpoint = not the signature of the token.  
That is why It is = still vulnerable to man in the middle attacks 

There is no guarantee = that the signing key for the AT is one that the client has any way to = verify.  
The client checking the signature = would not stop a man in the middle attack.

John B.


On = Nov 25, 2015, at 5:19 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

Thats not what I = am on about. 

Kathleen objected to the signed requirement in sec 6 without = making it clear in sec 5. 

We can't have it both ways. Be both = opaque and signed for the client to verify.  

If I restore the = requirements than the threat mitigation assumption of signed tokens must = also be removed. 

Phil

On Nov 25, 2015, at 12:02, John Bradley <ve7jtb@ve7jtb.com> = wrote:

The token is opaque to = the client.  It=E2=80=99s format is a matter between the RS and the = AS. 

Where do = we require the client verify the token?    The RS is the only = party that needs to verify the access token.

The information that the client needs = about the token is in additional meta-data delivered with but not in the = AT.

I agree = with Brian that is wrong on two counts.

1) the token is opaque to the = client.
2) one method of delivering the key to the = RS is in a signed JWT.  It is however also possible (if not ideal) = for the AT to be a reference, and introspected by the RS to get the = key.

So 
"In contrast to bearer tokens = [RFC6750] which call for tokens that are opaque to OAuth 2.0 clients, = this specification defines the requirements for proof-of-possession = ("PoP") tokens that may are also opaque to OAuth 2.0 clients but may be = parsed and verified, or introspected by OAuth 2.0 Resource Servers. When = token endpoints issue =E2=80=9CPoP=E2=80=9D tokens they provide the = OAuth Client additional parameters with information on what key material = to use for the proof.=E2=80=9D

Or given that they are both = opaque that part of the statement could be dropped.

John = B. 


On Nov = 25, 2015, at 12:44 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

Except that = later on we require the token be signed and the client verify that = signed token. IOW mutual pop. 

Phil

On Nov 25, 2015, at = 07:30, Brian Campbell <bcampbell@pingidentity.com> wrote:

Looking at the diff I noticed the following new = text, which seems to conflate bearer/PoP and opaqueness to the client. A = client demonstrating proof-of-possession of some key is orthogonal to = the client being able to parse and understand the access token itself. =
 
"In contrast to bearer tokens = [RFC6750] which call for tokens that are opaque to OAuth 2.0 clients, = this specification defines the requirements for proof-of-possession = ("PoP") tokens that may be parsed and verified by OAuth 2.0 clients and = relying parties."

On Tue, Nov 24, 2015 at 1:07 PM, = Phil Hunt <phil.hunt@oracle.com> wrote:
This draft addresses = review comments from Kathleen and Erik raised since the last draft.

It may not include some of the discussion from yesterday/today.  I = will add that as the group decides.

Cheers,

Phil

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

> On Nov 24, 2015, at 12:05 PM, internet-drafts@ietf.org wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts = directories.
> This draft is a work item of the Web Authorization Protocol Working = Group of the IETF.
>
>        Title          =  : OAuth 2.0 Proof-of-Possession (PoP) Security Architecture
>        Authors        =  : Phil Hunt
>                  =         Justin Richer
>                  =         William Mills
>                  =         Prateek Mishra
>                  =         Hannes Tschofenig
>       Filename        : = draft-ietf-oauth-pop-architecture-06.txt
>       Pages          =  : 23
>       Date          =   : 2015-11-24
>
> Abstract:
>   The OAuth 2.0 bearer token specification, as defined in = RFC 6750,
>   allows any party in possession of a bearer token (a = "bearer") to get
>   access to the associated resources (without = demonstrating possession
>   of a cryptographic key).  To prevent misuse, = bearer tokens must be
>   protected from disclosure in transit and at rest.
>
>   Some scenarios demand additional security protection = whereby a client
>   needs to demonstrate possession of cryptographic keying = material when
>   accessing a protected resource.  This document = motivates the
>   development of the OAuth 2.0 proof-of-possession = security mechanism.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architect= ure/
>
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-0= 6
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-pop-archit= ecture-06
>
>
> 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



--
=09 3D"Ping=20
Brian Campbell
Distinguished Engineer
Ping Identity
@ bcampbell@pingidentity.com
3D"phone" +1 720.317.2061
3D"twitter" @pingidentity
Connect with = us!
3D"pingidentity.com"
=
3D"pingidentity.com"
= 3D"twitter 3D"twitter 3D"youtube 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard 3D"rss
=
_______________________________________________OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


= --Apple-Mail=_B1BF3DD0-B80D-4C79-B287-4BF5FA47E84D-- From nobody Wed Nov 25 12:32:14 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ECC81B2F8C for ; Wed, 25 Nov 2015 12:32:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H2BcWHYf0AE4 for ; Wed, 25 Nov 2015 12:32:10 -0800 (PST) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::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 BA9F41B2F8B for ; Wed, 25 Nov 2015 12:32:09 -0800 (PST) Received: by qgeb1 with SMTP id b1so41213268qge.1 for ; Wed, 25 Nov 2015 12:32:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=SfekaLvLlINoaoIvZPzsaw4QTRSRy3x4kYOzR/aVSW4=; b=fZMJ/MB2QoHyoa5HJ7r9pDS1Heoc+O7wi2KhdjcjKDAjy2rF+40FZKKcBSg+t2wAMv Abj6mDvRKfDetF858YoTk317p4/PAZQMXhGWGypc7tYeG9menqU1eoWUQPzENYiq5/LO 1JzGOCTDOOk6Mbsk3Rqud9+FED+ZZq9fWwvqbxM8Yo4BJvcGZml7zC0T+KV/LPk7tcl6 Tjue4he9GOKi+fJettLcesKV9pM/UvoiKn9FvYHGATxiEWZzLJDWSLEKMSzRoglJUzBb k+/aEtpKlAzYJ44MZeQ9aR7nQrupds0f28wVy+oJ22N0CjfH3zZxNahp3gRu5TeemsWY 8B/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=SfekaLvLlINoaoIvZPzsaw4QTRSRy3x4kYOzR/aVSW4=; b=nMIRSjhtYGYX3OgpxHa79BImOQGeukQct7HEqtZ8jaK600kG/v1QTEJmS7G5nUNTYR guw8EKGYNvyijHDYSzn3lVOwBZfm1LYCj/LSLlaBArEGqmVbSDoW5fz/VpLbV1o7hMgr SbrZ2/AiJvgK8W2MFOfh4urmyBMeScU0LbIUseew8mIFaD3C2J5I8qodlPCq43YQ92RL ttZyS/IIbRcZjnYIZUQDVSl95GIzB3B2/h0U7uBecM6qVtSy22U/FkSwAOeueyOCDbtk rBw58k1xcQGtjNoPOzr5wA1NgARofw9qpdq8g0i2W9pJ/XaJikoJ0sx9sLgpLhaemM/Z nvgg== X-Gm-Message-State: ALoCoQnhxad0ewGQfxtBI+UffmBK+sMPhCIyUWrE7EKORStOVHhC3etNTOmvClIkZIgz7Iz2xMya X-Received: by 10.140.101.130 with SMTP id u2mr41170424qge.2.1448483528793; Wed, 25 Nov 2015 12:32:08 -0800 (PST) Received: from [192.168.1.216] ([191.115.122.254]) by smtp.gmail.com with ESMTPSA id 20sm5967303qhg.13.2015.11.25.12.32.01 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 25 Nov 2015 12:32:07 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_B7863849-307B-4E32-B837-07DCF7F59637" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: John Bradley In-Reply-To: Date: Wed, 25 Nov 2015 17:31:54 -0300 Message-Id: References: <20151124200512.20833.28463.idtracker@ietfa.amsl.com> <16FAD3AC-CFB8-46D5-A12E-436E902EA439@oracle.com> To: Justin Richer X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-pop-architecture-06.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2015 20:32:13 -0000 --Apple-Mail=_B7863849-307B-4E32-B837-07DCF7F59637 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Yes all access tokens bearer or PoP are audienced to the RS, Integrity = protected in a way the RS can verify, and if required encrypted to the = RS. I would guess that a majority of deployments I know of want = introspection or encrypted AT to protect the confidentiality of the = attributes passed in the access token. There is commonly user and or role info that they want to protect. If = PoP required the tokens to be readable/verifiable by the client then it = would be a non starter for privacy reasons lots of places. John B. > On Nov 25, 2015, at 5:21 PM, Justin Richer wrote: >=20 > The only actual requirement is opacity. Section 6 should be more = clearly called out as an example instead, which is what it is. >=20 > Perhaps we should also re-state that access tokens remain opaque to = the client in the introductory text. >=20 > =E2=80=94 Justin >=20 >> On Nov 25, 2015, at 3:19 PM, Phil Hunt > wrote: >>=20 >> Thats not what I am on about.=20 >>=20 >> Kathleen objected to the signed requirement in sec 6 without making = it clear in sec 5.=20 >>=20 >> We can't have it both ways. Be both opaque and signed for the client = to verify. =20 >>=20 >> If I restore the requirements than the threat mitigation assumption = of signed tokens must also be removed.=20 >>=20 >> Phil >>=20 >> On Nov 25, 2015, at 12:02, John Bradley > wrote: >>=20 >>> The token is opaque to the client. It=E2=80=99s format is a matter = between the RS and the AS.=20 >>>=20 >>> Where do we require the client verify the token? The RS is the = only party that needs to verify the access token. >>>=20 >>> The information that the client needs about the token is in = additional meta-data delivered with but not in the AT. >>>=20 >>> I agree with Brian that is wrong on two counts. >>>=20 >>> 1) the token is opaque to the client. >>> 2) one method of delivering the key to the RS is in a signed JWT. = It is however also possible (if not ideal) for the AT to be a reference, = and introspected by the RS to get the key. >>>=20 >>> So=20 >>> "In contrast to bearer tokens [RFC6750] which call for tokens that = are opaque to OAuth 2.0 clients, this specification defines the = requirements for proof-of-possession ("PoP") tokens that may are also = opaque to OAuth 2.0 clients but may be parsed and verified, or = introspected by OAuth 2.0 Resource Servers. When token endpoints issue = =E2=80=9CPoP=E2=80=9D tokens they provide the OAuth Client additional = parameters with information on what key material to use for the = proof.=E2=80=9D >>>=20 >>> Or given that they are both opaque that part of the statement could = be dropped. >>>=20 >>> John B.=20 >>>=20 >>>=20 >>>> On Nov 25, 2015, at 12:44 PM, Phil Hunt > wrote: >>>>=20 >>>> Except that later on we require the token be signed and the client = verify that signed token. IOW mutual pop.=20 >>>>=20 >>>> Phil >>>>=20 >>>> On Nov 25, 2015, at 07:30, Brian Campbell = > wrote: >>>>=20 >>>>> Looking at the diff I noticed the following new text, which seems = to conflate bearer/PoP and opaqueness to the client. A client = demonstrating proof-of-possession of some key is orthogonal to the = client being able to parse and understand the access token itself.=20 >>>>> =20 >>>>> "In contrast to bearer tokens [RFC6750] which call for tokens that = are opaque to OAuth 2.0 clients, this specification defines the = requirements for proof-of-possession ("PoP") tokens that may be parsed = and verified by OAuth 2.0 clients and relying parties." >>>>>=20 >>>>> On Tue, Nov 24, 2015 at 1:07 PM, Phil Hunt > wrote: >>>>> This draft addresses review comments from Kathleen and Erik raised = since the last draft. >>>>>=20 >>>>> It may not include some of the discussion from yesterday/today. I = will add that as the group decides. >>>>>=20 >>>>> Cheers, >>>>>=20 >>>>> Phil >>>>>=20 >>>>> @independentid >>>>> www.independentid.com >>>>> phil.hunt@oracle.com >>>>>=20 >>>>> > On Nov 24, 2015, at 12:05 PM, internet-drafts@ietf.org = wrote: >>>>> > >>>>> > >>>>> > A New Internet-Draft is available from the on-line = Internet-Drafts directories. >>>>> > This draft is a work item of the Web Authorization Protocol = Working Group of the IETF. >>>>> > >>>>> > Title : OAuth 2.0 Proof-of-Possession (PoP) = Security Architecture >>>>> > Authors : Phil Hunt >>>>> > Justin Richer >>>>> > William Mills >>>>> > Prateek Mishra >>>>> > Hannes Tschofenig >>>>> > Filename : draft-ietf-oauth-pop-architecture-06.txt >>>>> > Pages : 23 >>>>> > Date : 2015-11-24 >>>>> > >>>>> > Abstract: >>>>> > The OAuth 2.0 bearer token specification, as defined in RFC = 6750, >>>>> > allows any party in possession of a bearer token (a "bearer") = to get >>>>> > access to the associated resources (without demonstrating = possession >>>>> > of a cryptographic key). To prevent misuse, bearer tokens = must be >>>>> > protected from disclosure in transit and at rest. >>>>> > >>>>> > Some scenarios demand additional security protection whereby a = client >>>>> > needs to demonstrate possession of cryptographic keying = material when >>>>> > accessing a protected resource. This document motivates the >>>>> > development of the OAuth 2.0 proof-of-possession security = mechanism. >>>>> > >>>>> > >>>>> > The IETF datatracker status page for this draft is: >>>>> > = https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architecture/ = >>>>> > >>>>> > There's also a htmlized version available at: >>>>> > https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-06 = >>>>> > >>>>> > A diff from the previous version is available at: >>>>> > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-pop-architecture-06 = = >>>>> > >>>>> > >>>>> > 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 = >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>>=20 >>>>>=20 >>>>>=20 >>>>> --=20 >>>>> =09 >>>>> Brian Campbell >>>>> Distinguished Engineer >>>>> Ping Identity >>>>> @ bcampbell@pingidentity.com >>>>> +1 720.317.2061 >>>>> @pingidentity >>>>> Connect with us! >>>>> >>>>> = = = = = = = = _____________________________________= __________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth = >>>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 --Apple-Mail=_B7863849-307B-4E32-B837-07DCF7F59637 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Yes all access tokens bearer or PoP are audienced to the RS, = Integrity protected in a way the RS can verify, and if required = encrypted to the RS.

I= would guess that a majority of deployments I know of want introspection = or encrypted AT to protect the confidentiality of the attributes passed = in the access token.
There is commonly user and or = role info that they want to protect.   If PoP required the tokens = to be readable/verifiable by the client then it would be a non starter = for privacy reasons lots of places.

John B.


On = Nov 25, 2015, at 5:21 PM, Justin Richer <jricher@mit.edu> = wrote:

The only = actual requirement is opacity. Section 6 should be more clearly called = out as an example instead, which is what it is.

Perhaps we should also re-state that = access tokens remain opaque to the client in the introductory text.

 =E2=80= =94 Justin

On Nov 25, 2015, at 3:19 PM, = Phil Hunt <phil.hunt@oracle.com> wrote:

Thats not what I = am on about. 

Kathleen objected to the signed requirement in sec 6 without = making it clear in sec 5. 

We can't have it both ways. Be both = opaque and signed for the client to verify.  

If I restore the = requirements than the threat mitigation assumption of signed tokens must = also be removed. 

Phil

On Nov 25, 2015, at 12:02, John Bradley <ve7jtb@ve7jtb.com> = wrote:

The token is opaque to the client. =  It=E2=80=99s format is a matter between the RS and the = AS. 

Where do = we require the client verify the token?    The RS is the only = party that needs to verify the access token.

The information that the client needs = about the token is in additional meta-data delivered with but not in the = AT.

I agree = with Brian that is wrong on two counts.

1) the token is opaque to the = client.
2) one method of delivering the key to the = RS is in a signed JWT.  It is however also possible (if not ideal) = for the AT to be a reference, and introspected by the RS to get the = key.

So 
"In contrast to bearer tokens = [RFC6750] which call for tokens that are opaque to OAuth 2.0 clients, = this specification defines the requirements for proof-of-possession = ("PoP") tokens that may are also opaque to OAuth 2.0 clients but may be = parsed and verified, or introspected by OAuth 2.0 Resource Servers. When = token endpoints issue =E2=80=9CPoP=E2=80=9D tokens they provide the = OAuth Client additional parameters with information on what key material = to use for the proof.=E2=80=9D

Or given that they are both = opaque that part of the statement could be dropped.

John = B. 


On Nov = 25, 2015, at 12:44 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

Except that later on we require the token be = signed and the client verify that signed token. IOW mutual pop. 

Phil

On = Nov 25, 2015, at 07:30, Brian Campbell <bcampbell@pingidentity.com> wrote:

Looking at the diff I noticed the following new = text, which seems to conflate bearer/PoP and opaqueness to the client. A = client demonstrating proof-of-possession of some key is orthogonal to = the client being able to parse and understand the access token itself. =
 
"In contrast to bearer tokens = [RFC6750] which call for tokens that are opaque to OAuth 2.0 clients, = this specification defines the requirements for proof-of-possession = ("PoP") tokens that may be parsed and verified by OAuth 2.0 clients and = relying parties."

On Tue, Nov 24, 2015 at 1:07 PM, = Phil Hunt <phil.hunt@oracle.com> wrote:
This draft addresses = review comments from Kathleen and Erik raised since the last draft.

It may not include some of the discussion from yesterday/today.  I = will add that as the group decides.

Cheers,

Phil

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

> On Nov 24, 2015, at 12:05 PM, internet-drafts@ietf.org wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts = directories.
> This draft is a work item of the Web Authorization Protocol Working = Group of the IETF.
>
>        Title          =  : OAuth 2.0 Proof-of-Possession (PoP) Security Architecture
>        Authors        =  : Phil Hunt
>                  =         Justin Richer
>                  =         William Mills
>                  =         Prateek Mishra
>                  =         Hannes Tschofenig
>       Filename        : = draft-ietf-oauth-pop-architecture-06.txt
>       Pages          =  : 23
>       Date          =   : 2015-11-24
>
> Abstract:
>   The OAuth 2.0 bearer token specification, as defined in = RFC 6750,
>   allows any party in possession of a bearer token (a = "bearer") to get
>   access to the associated resources (without = demonstrating possession
>   of a cryptographic key).  To prevent misuse, = bearer tokens must be
>   protected from disclosure in transit and at rest.
>
>   Some scenarios demand additional security protection = whereby a client
>   needs to demonstrate possession of cryptographic keying = material when
>   accessing a protected resource.  This document = motivates the
>   development of the OAuth 2.0 proof-of-possession = security mechanism.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architect= ure/
>
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-0= 6
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-pop-archit= ecture-06
>
>
> 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



--
=09 3D"Ping=20
Brian Campbell
Distinguished Engineer
Ping Identity
@ bcampbell@pingidentity.com
3D"phone" +1 720.317.2061
3D"twitter" @pingidentity
Connect with = us!
3D"pingidentity.com"
=
3D"pingidentity.com"
= 3D"twitter 3D"twitter 3D"youtube 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard 3D"rss
=
_______________________________________________OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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


= --Apple-Mail=_B7863849-307B-4E32-B837-07DCF7F59637-- From nobody Wed Nov 25 12:35:02 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23DA31B2F8E for ; Wed, 25 Nov 2015 12:35:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.775 X-Spam-Level: X-Spam-Status: No, score=-4.775 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0m57LYQlqo22 for ; Wed, 25 Nov 2015 12:34:57 -0800 (PST) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECD3B1B2F19 for ; Wed, 25 Nov 2015 12:34:56 -0800 (PST) X-AuditID: 1209190e-f79046d0000036c0-1d-56561b6eaf9d Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 0F.85.14016.F6B16565; Wed, 25 Nov 2015 15:34:55 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id tAPKYsCW010495; Wed, 25 Nov 2015 15:34:54 -0500 Received: from artemisia.richer.local (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id tAPKYqA4015378 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 25 Nov 2015 15:34:53 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_F39AB13D-5D31-426E-ACC5-0F5878FC4E1D" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Justin Richer In-Reply-To: Date: Wed, 25 Nov 2015 15:34:51 -0500 Message-Id: <64BFC277-5966-4B02-8EE2-D23CD1390766@mit.edu> References: <20151124200512.20833.28463.idtracker@ietfa.amsl.com> <16FAD3AC-CFB8-46D5-A12E-436E902EA439@oracle.com> To: John Bradley X-Mailer: Apple Mail (2.2104) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNKsWRmVeSWpSXmKPExsUixCmqrJsvHRZmcOMvq8XJt6/YLBbMb2S3 WH33L5sDs8eSJT+ZPD4+vcXicfv2RpYA5igum5TUnMyy1CJ9uwSujONTPApmfmKsePjmAksD 498LjF2MnBwSAiYSp7svMEHYYhIX7q1n62Lk4hASWMwkMX/5dShnI6PE699/mCGch0wS566t BspwcDALJEj8XSYN0s0roCfx6tZlVhBbWMBH4uLpJ2A2m4CqxPQ1LWAbOAXsJLZO2cgMYrMA xSfsPskCYjMLeEp8mj6dBWKOlcSrN/9ZIHatZ5Z4fuUiG0hCREBFYt++R1Bny0rs/v2IaQKj wCyEM2YhOWMW2FhtiWULXzND2JoS+7uXs2CKa0h0fpvIuoCRbRWjbEpulW5uYmZOcWqybnFy Yl5eapGusV5uZoleakrpJkZwHEjy7WD8elDpEKMAB6MSD++ERyFhQqyJZcWVuYcYJTmYlER5 LTnCwoT4kvJTKjMSizPii0pzUosPMUpwMCuJ8G77EBomxJuSWFmVWpQPk5LmYFES5537xTdM SCA9sSQ1OzW1ILUIJivDwaEkwRsqBTRUsCg1PbUiLTOnBCHNxMEJMpwHaHgQSA1vcUFibnFm OkT+FKOilDivEkhCACSRUZoH1wtKUwlvD5u+YhQHekWYtwikigeY4uC6XwENZgIaHJEDcnVx SSJCSqqB0Wb7G3PVXPsz0nOO7l8fd+12sdqCr/8uJ/p08Z2+73aZYw1zSbK4U1kF5wOxbqfk 44Kv5Pmz7nTM1fr4efr/e/+2yHxOF3lTw2deLX69M3q+TP+SC49eH7u16n9i3nZttqi1arfb mH6HSG0TbbNZK60kv3mOfqzK1viNN7ROil/59cjV/ckfXyWW4oxEQy3mouJEACR6hk0uAwAA Archived-At: Cc: "" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-pop-architecture-06.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2015 20:35:01 -0000 --Apple-Mail=_F39AB13D-5D31-426E-ACC5-0F5878FC4E1D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Well not only is it a non-starter, it=E2=80=99s completely unnecessary = to begin with. Issues are getting conflated here. I never read that = section in the way that it apparently was, so that needs to be backed = out. =E2=80=94 Justin > On Nov 25, 2015, at 3:31 PM, John Bradley wrote: >=20 > Yes all access tokens bearer or PoP are audienced to the RS, Integrity = protected in a way the RS can verify, and if required encrypted to the = RS. >=20 > I would guess that a majority of deployments I know of want = introspection or encrypted AT to protect the confidentiality of the = attributes passed in the access token. > There is commonly user and or role info that they want to protect. = If PoP required the tokens to be readable/verifiable by the client then = it would be a non starter for privacy reasons lots of places. >=20 > John B. >=20 >=20 >> On Nov 25, 2015, at 5:21 PM, Justin Richer > wrote: >>=20 >> The only actual requirement is opacity. Section 6 should be more = clearly called out as an example instead, which is what it is. >>=20 >> Perhaps we should also re-state that access tokens remain opaque to = the client in the introductory text. >>=20 >> =E2=80=94 Justin >>=20 >>> On Nov 25, 2015, at 3:19 PM, Phil Hunt > wrote: >>>=20 >>> Thats not what I am on about.=20 >>>=20 >>> Kathleen objected to the signed requirement in sec 6 without making = it clear in sec 5.=20 >>>=20 >>> We can't have it both ways. Be both opaque and signed for the client = to verify. =20 >>>=20 >>> If I restore the requirements than the threat mitigation assumption = of signed tokens must also be removed.=20 >>>=20 >>> Phil >>>=20 >>> On Nov 25, 2015, at 12:02, John Bradley > wrote: >>>=20 >>>> The token is opaque to the client. It=E2=80=99s format is a matter = between the RS and the AS.=20 >>>>=20 >>>> Where do we require the client verify the token? The RS is the = only party that needs to verify the access token. >>>>=20 >>>> The information that the client needs about the token is in = additional meta-data delivered with but not in the AT. >>>>=20 >>>> I agree with Brian that is wrong on two counts. >>>>=20 >>>> 1) the token is opaque to the client. >>>> 2) one method of delivering the key to the RS is in a signed JWT. = It is however also possible (if not ideal) for the AT to be a reference, = and introspected by the RS to get the key. >>>>=20 >>>> So=20 >>>> "In contrast to bearer tokens [RFC6750] which call for tokens that = are opaque to OAuth 2.0 clients, this specification defines the = requirements for proof-of-possession ("PoP") tokens that may are also = opaque to OAuth 2.0 clients but may be parsed and verified, or = introspected by OAuth 2.0 Resource Servers. When token endpoints issue = =E2=80=9CPoP=E2=80=9D tokens they provide the OAuth Client additional = parameters with information on what key material to use for the = proof.=E2=80=9D >>>>=20 >>>> Or given that they are both opaque that part of the statement could = be dropped. >>>>=20 >>>> John B.=20 >>>>=20 >>>>=20 >>>>> On Nov 25, 2015, at 12:44 PM, Phil Hunt > wrote: >>>>>=20 >>>>> Except that later on we require the token be signed and the client = verify that signed token. IOW mutual pop.=20 >>>>>=20 >>>>> Phil >>>>>=20 >>>>> On Nov 25, 2015, at 07:30, Brian Campbell = > wrote: >>>>>=20 >>>>>> Looking at the diff I noticed the following new text, which seems = to conflate bearer/PoP and opaqueness to the client. A client = demonstrating proof-of-possession of some key is orthogonal to the = client being able to parse and understand the access token itself.=20 >>>>>> =20 >>>>>> "In contrast to bearer tokens [RFC6750] which call for tokens = that are opaque to OAuth 2.0 clients, this specification defines the = requirements for proof-of-possession ("PoP") tokens that may be parsed = and verified by OAuth 2.0 clients and relying parties." >>>>>>=20 >>>>>> On Tue, Nov 24, 2015 at 1:07 PM, Phil Hunt > wrote: >>>>>> This draft addresses review comments from Kathleen and Erik = raised since the last draft. >>>>>>=20 >>>>>> It may not include some of the discussion from yesterday/today. = I will add that as the group decides. >>>>>>=20 >>>>>> Cheers, >>>>>>=20 >>>>>> Phil >>>>>>=20 >>>>>> @independentid >>>>>> www.independentid.com >>>>>> phil.hunt@oracle.com >>>>>>=20 >>>>>> > On Nov 24, 2015, at 12:05 PM, internet-drafts@ietf.org = wrote: >>>>>> > >>>>>> > >>>>>> > A New Internet-Draft is available from the on-line = Internet-Drafts directories. >>>>>> > This draft is a work item of the Web Authorization Protocol = Working Group of the IETF. >>>>>> > >>>>>> > Title : OAuth 2.0 Proof-of-Possession (PoP) = Security Architecture >>>>>> > Authors : Phil Hunt >>>>>> > Justin Richer >>>>>> > William Mills >>>>>> > Prateek Mishra >>>>>> > Hannes Tschofenig >>>>>> > Filename : = draft-ietf-oauth-pop-architecture-06.txt >>>>>> > Pages : 23 >>>>>> > Date : 2015-11-24 >>>>>> > >>>>>> > Abstract: >>>>>> > The OAuth 2.0 bearer token specification, as defined in RFC = 6750, >>>>>> > allows any party in possession of a bearer token (a "bearer") = to get >>>>>> > access to the associated resources (without demonstrating = possession >>>>>> > of a cryptographic key). To prevent misuse, bearer tokens = must be >>>>>> > protected from disclosure in transit and at rest. >>>>>> > >>>>>> > Some scenarios demand additional security protection whereby = a client >>>>>> > needs to demonstrate possession of cryptographic keying = material when >>>>>> > accessing a protected resource. This document motivates the >>>>>> > development of the OAuth 2.0 proof-of-possession security = mechanism. >>>>>> > >>>>>> > >>>>>> > The IETF datatracker status page for this draft is: >>>>>> > = https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architecture/ = >>>>>> > >>>>>> > There's also a htmlized version available at: >>>>>> > = https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-06 = >>>>>> > >>>>>> > A diff from the previous version is available at: >>>>>> > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-pop-architecture-06 = = >>>>>> > >>>>>> > >>>>>> > 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 = >>>>>>=20 >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> --=20 >>>>>> =09 >>>>>> Brian Campbell >>>>>> Distinguished Engineer >>>>>> Ping Identity >>>>>> @ bcampbell@pingidentity.com = >>>>>> +1 720.317.2061 >>>>>> @pingidentity >>>>>> Connect with us! >>>>>> >>>>>> = = = = = = = = _____________________________________= __________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth = >>=20 >=20 --Apple-Mail=_F39AB13D-5D31-426E-ACC5-0F5878FC4E1D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Well not only is it a non-starter, it=E2=80=99s completely = unnecessary to begin with. Issues are getting conflated here. I never = read that section in the way that it apparently was, so that needs to be = backed out.

 =E2=80= =94 Justin

On Nov 25, 2015, at 3:31 PM, = John Bradley <ve7jtb@ve7jtb.com> wrote:

Yes all access = tokens bearer or PoP are audienced to the RS, Integrity protected in a = way the RS can verify, and if required encrypted to the RS.

I would guess that a = majority of deployments I know of want introspection or encrypted AT to = protect the confidentiality of the attributes passed in the access = token.
There is commonly user and or role info that = they want to protect.   If PoP required the tokens to be = readable/verifiable by the client then it would be a non starter for = privacy reasons lots of places.

John B.


On Nov = 25, 2015, at 5:21 PM, Justin Richer <jricher@mit.edu> wrote:

The only actual = requirement is opacity. Section 6 should be more clearly called out as = an example instead, which is what it is.

Perhaps we should also re-state that = access tokens remain opaque to the client in the introductory text.

 =E2=80= =94 Justin

On Nov 25, 2015, at 3:19 PM, = Phil Hunt <phil.hunt@oracle.com> wrote:

Thats not what I am on = about. 

Kathleen objected to the signed requirement in sec 6 without = making it clear in sec 5. 

We can't have it both ways. Be both = opaque and signed for the client to verify.  

If I restore the = requirements than the threat mitigation assumption of signed tokens must = also be removed. 

Phil

On Nov 25, 2015, at 12:02, John Bradley <ve7jtb@ve7jtb.com> = wrote:

The token is opaque to the client. =  It=E2=80=99s format is a matter between the RS and the = AS. 

Where do = we require the client verify the token?    The RS is the only = party that needs to verify the access token.

The information that the client needs = about the token is in additional meta-data delivered with but not in the = AT.

I agree = with Brian that is wrong on two counts.

1) the token is opaque to the = client.
2) one method of delivering the key to the = RS is in a signed JWT.  It is however also possible (if not ideal) = for the AT to be a reference, and introspected by the RS to get the = key.

So 
"In contrast to bearer tokens = [RFC6750] which call for tokens that are opaque to OAuth 2.0 clients, = this specification defines the requirements for proof-of-possession = ("PoP") tokens that may are also opaque to OAuth 2.0 clients but may be = parsed and verified, or introspected by OAuth 2.0 Resource Servers. When = token endpoints issue =E2=80=9CPoP=E2=80=9D tokens they provide the = OAuth Client additional parameters with information on what key material = to use for the proof.=E2=80=9D

Or given that they are both = opaque that part of the statement could be dropped.

John = B. 


On Nov = 25, 2015, at 12:44 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

Except that later on we require the token be = signed and the client verify that signed token. IOW mutual pop. 

Phil

On = Nov 25, 2015, at 07:30, Brian Campbell <bcampbell@pingidentity.com> wrote:

Looking at the diff I noticed the following new = text, which seems to conflate bearer/PoP and opaqueness to the client. A = client demonstrating proof-of-possession of some key is orthogonal to = the client being able to parse and understand the access token itself. =
 
"In contrast to bearer tokens = [RFC6750] which call for tokens that are opaque to OAuth 2.0 clients, = this specification defines the requirements for proof-of-possession = ("PoP") tokens that may be parsed and verified by OAuth 2.0 clients and = relying parties."

On Tue, Nov 24, 2015 at 1:07 PM, = Phil Hunt <phil.hunt@oracle.com> wrote:
This draft addresses = review comments from Kathleen and Erik raised since the last draft.

It may not include some of the discussion from yesterday/today.  I = will add that as the group decides.

Cheers,

Phil

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

> On Nov 24, 2015, at 12:05 PM, internet-drafts@ietf.org wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts = directories.
> This draft is a work item of the Web Authorization Protocol Working = Group of the IETF.
>
>        Title          =  : OAuth 2.0 Proof-of-Possession (PoP) Security Architecture
>        Authors        =  : Phil Hunt
>                  =         Justin Richer
>                  =         William Mills
>                  =         Prateek Mishra
>                  =         Hannes Tschofenig
>       Filename        : = draft-ietf-oauth-pop-architecture-06.txt
>       Pages          =  : 23
>       Date          =   : 2015-11-24
>
> Abstract:
>   The OAuth 2.0 bearer token specification, as defined in = RFC 6750,
>   allows any party in possession of a bearer token (a = "bearer") to get
>   access to the associated resources (without = demonstrating possession
>   of a cryptographic key).  To prevent misuse, = bearer tokens must be
>   protected from disclosure in transit and at rest.
>
>   Some scenarios demand additional security protection = whereby a client
>   needs to demonstrate possession of cryptographic keying = material when
>   accessing a protected resource.  This document = motivates the
>   development of the OAuth 2.0 proof-of-possession = security mechanism.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architect= ure/
>
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-0= 6
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-pop-archit= ecture-06
>
>
> 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



--
=09 3D"Ping=20
Brian Campbell
Distinguished Engineer
Ping Identity
@ bcampbell@pingidentity.com
3D"phone" +1 720.317.2061
3D"twitter" @pingidentity
Connect with = us!
3D"pingidentity.com"
=
3D"pingidentity.com"
= 3D"twitter 3D"twitter 3D"youtube 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard 3D"rss
=
_______________________________________________OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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



= --Apple-Mail=_F39AB13D-5D31-426E-ACC5-0F5878FC4E1D-- From nobody Wed Nov 25 12:37:09 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 931641B2FAD for ; Wed, 25 Nov 2015 12:37:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tpar_G63tYhr for ; Wed, 25 Nov 2015 12:37:04 -0800 (PST) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::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 BE9431B2FAC for ; Wed, 25 Nov 2015 12:37:03 -0800 (PST) Received: by qkfo3 with SMTP id o3so20420239qkf.1 for ; Wed, 25 Nov 2015 12:37:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=lKBB02tOJVC72YIMIiNEJGLvhSRlAwB3thrAzVahfi8=; b=n7tf5zQGZFMXk6vHOoTAIJU4v4PTcSki19FFWaU/JvFhaMHzhyBtvy/X5PuJhpLHpO P9dSjJtukF5ddLUqbG8r6BdyKgvZq5JQfGv1GD6hVUaNML7toaRxP8IheyrEbokyMSJX 46EbQdlBg2Vo1seOeWGaltbDRsB7hJ14d6r2dVQO6jlZpdJlxwlU3rtMRVJJNVthpvHW DRyGqfC4CnXTGMriQuHRUgbB6IUyvskJkfzIKvS/BVMQmXoHz5Lv8OZs5OuYG/wsPzj6 y/spMrTUNeNs0OfOTAmF39dmrBvvKD8QHl03sxoFFOg8kF76wki6/u+Hue3ut5klIfOu PfXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=lKBB02tOJVC72YIMIiNEJGLvhSRlAwB3thrAzVahfi8=; b=e/fAT6WeBQ9dky1fMNAy/g+yacCrMWpNVY9LdkfdLSsu2HTvfYWDD7WRU1gcGAjtvR C6YUT5iCH2odpdR6ZTP0x3RM2ZcVkS0j4jS+YkoxcZGs0BGJPypQzKS5qluwzNOkPP5d wxa8ZOYJfAdDNs6d1ep2ecVfwr7GsqnTYzMRrbNex5cIJ0cy/c/KUrQdRkKyt5a5fV0m VxCWIOW/vuNDRW2EE9RIfiRQxdw8LovOtRPqhXBq5hXPc21t9XCCu3H+8U1jaAk3xcsq 1VNh1oUf5sxcIXc42UaYMPQCYBl7IfeMM3Q+TLYU0R9UlkcQSba8JDT77YhBayPjmNaP +rvg== X-Gm-Message-State: ALoCoQkt0bMyosOrwNmj+THb+BwP7vz9+ySPsaATjMekbEE7VsTxdJIyPEvesPA+tlQFXbHstlrF X-Received: by 10.55.81.3 with SMTP id f3mr30567855qkb.35.1448483822808; Wed, 25 Nov 2015 12:37:02 -0800 (PST) Received: from [192.168.1.216] ([191.115.122.254]) by smtp.gmail.com with ESMTPSA id z65sm5942474qhb.22.2015.11.25.12.36.54 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 25 Nov 2015 12:37:02 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_3EEE783F-3436-4681-98E9-B352AC28BA79" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: John Bradley In-Reply-To: Date: Wed, 25 Nov 2015 17:36:44 -0300 Message-Id: References: <20151124200512.20833.28463.idtracker@ietfa.amsl.com> <16FAD3AC-CFB8-46D5-A12E-436E902EA439@oracle.com> To: Justin Richer X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-pop-architecture-06.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2015 20:37:07 -0000 --Apple-Mail=_3EEE783F-3436-4681-98E9-B352AC28BA79 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The current text of 6 has. Alternatively, the content of the token could be passed by reference rather than by value (requiring a separate message exchange to resolve the reference to the token content). The rest of 6 is an example of using the signed method. not the only = method. > On Nov 25, 2015, at 5:31 PM, John Bradley wrote: >=20 > Yes all access tokens bearer or PoP are audienced to the RS, Integrity = protected in a way the RS can verify, and if required encrypted to the = RS. >=20 > I would guess that a majority of deployments I know of want = introspection or encrypted AT to protect the confidentiality of the = attributes passed in the access token. > There is commonly user and or role info that they want to protect. = If PoP required the tokens to be readable/verifiable by the client then = it would be a non starter for privacy reasons lots of places. >=20 > John B. >=20 >=20 >> On Nov 25, 2015, at 5:21 PM, Justin Richer > wrote: >>=20 >> The only actual requirement is opacity. Section 6 should be more = clearly called out as an example instead, which is what it is. >>=20 >> Perhaps we should also re-state that access tokens remain opaque to = the client in the introductory text. >>=20 >> =E2=80=94 Justin >>=20 >>> On Nov 25, 2015, at 3:19 PM, Phil Hunt > wrote: >>>=20 >>> Thats not what I am on about.=20 >>>=20 >>> Kathleen objected to the signed requirement in sec 6 without making = it clear in sec 5.=20 >>>=20 >>> We can't have it both ways. Be both opaque and signed for the client = to verify. =20 >>>=20 >>> If I restore the requirements than the threat mitigation assumption = of signed tokens must also be removed.=20 >>>=20 >>> Phil >>>=20 >>> On Nov 25, 2015, at 12:02, John Bradley > wrote: >>>=20 >>>> The token is opaque to the client. It=E2=80=99s format is a matter = between the RS and the AS.=20 >>>>=20 >>>> Where do we require the client verify the token? The RS is the = only party that needs to verify the access token. >>>>=20 >>>> The information that the client needs about the token is in = additional meta-data delivered with but not in the AT. >>>>=20 >>>> I agree with Brian that is wrong on two counts. >>>>=20 >>>> 1) the token is opaque to the client. >>>> 2) one method of delivering the key to the RS is in a signed JWT. = It is however also possible (if not ideal) for the AT to be a reference, = and introspected by the RS to get the key. >>>>=20 >>>> So=20 >>>> "In contrast to bearer tokens [RFC6750] which call for tokens that = are opaque to OAuth 2.0 clients, this specification defines the = requirements for proof-of-possession ("PoP") tokens that may are also = opaque to OAuth 2.0 clients but may be parsed and verified, or = introspected by OAuth 2.0 Resource Servers. When token endpoints issue = =E2=80=9CPoP=E2=80=9D tokens they provide the OAuth Client additional = parameters with information on what key material to use for the = proof.=E2=80=9D >>>>=20 >>>> Or given that they are both opaque that part of the statement could = be dropped. >>>>=20 >>>> John B.=20 >>>>=20 >>>>=20 >>>>> On Nov 25, 2015, at 12:44 PM, Phil Hunt > wrote: >>>>>=20 >>>>> Except that later on we require the token be signed and the client = verify that signed token. IOW mutual pop.=20 >>>>>=20 >>>>> Phil >>>>>=20 >>>>> On Nov 25, 2015, at 07:30, Brian Campbell = > wrote: >>>>>=20 >>>>>> Looking at the diff I noticed the following new text, which seems = to conflate bearer/PoP and opaqueness to the client. A client = demonstrating proof-of-possession of some key is orthogonal to the = client being able to parse and understand the access token itself.=20 >>>>>> =20 >>>>>> "In contrast to bearer tokens [RFC6750] which call for tokens = that are opaque to OAuth 2.0 clients, this specification defines the = requirements for proof-of-possession ("PoP") tokens that may be parsed = and verified by OAuth 2.0 clients and relying parties." >>>>>>=20 >>>>>> On Tue, Nov 24, 2015 at 1:07 PM, Phil Hunt > wrote: >>>>>> This draft addresses review comments from Kathleen and Erik = raised since the last draft. >>>>>>=20 >>>>>> It may not include some of the discussion from yesterday/today. = I will add that as the group decides. >>>>>>=20 >>>>>> Cheers, >>>>>>=20 >>>>>> Phil >>>>>>=20 >>>>>> @independentid >>>>>> www.independentid.com >>>>>> phil.hunt@oracle.com >>>>>>=20 >>>>>> > On Nov 24, 2015, at 12:05 PM, internet-drafts@ietf.org = wrote: >>>>>> > >>>>>> > >>>>>> > A New Internet-Draft is available from the on-line = Internet-Drafts directories. >>>>>> > This draft is a work item of the Web Authorization Protocol = Working Group of the IETF. >>>>>> > >>>>>> > Title : OAuth 2.0 Proof-of-Possession (PoP) = Security Architecture >>>>>> > Authors : Phil Hunt >>>>>> > Justin Richer >>>>>> > William Mills >>>>>> > Prateek Mishra >>>>>> > Hannes Tschofenig >>>>>> > Filename : = draft-ietf-oauth-pop-architecture-06.txt >>>>>> > Pages : 23 >>>>>> > Date : 2015-11-24 >>>>>> > >>>>>> > Abstract: >>>>>> > The OAuth 2.0 bearer token specification, as defined in RFC = 6750, >>>>>> > allows any party in possession of a bearer token (a "bearer") = to get >>>>>> > access to the associated resources (without demonstrating = possession >>>>>> > of a cryptographic key). To prevent misuse, bearer tokens = must be >>>>>> > protected from disclosure in transit and at rest. >>>>>> > >>>>>> > Some scenarios demand additional security protection whereby = a client >>>>>> > needs to demonstrate possession of cryptographic keying = material when >>>>>> > accessing a protected resource. This document motivates the >>>>>> > development of the OAuth 2.0 proof-of-possession security = mechanism. >>>>>> > >>>>>> > >>>>>> > The IETF datatracker status page for this draft is: >>>>>> > = https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architecture/ = >>>>>> > >>>>>> > There's also a htmlized version available at: >>>>>> > = https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-06 = >>>>>> > >>>>>> > A diff from the previous version is available at: >>>>>> > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-pop-architecture-06 = = >>>>>> > >>>>>> > >>>>>> > 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 = >>>>>>=20 >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> --=20 >>>>>> =09 >>>>>> Brian Campbell >>>>>> Distinguished Engineer >>>>>> Ping Identity >>>>>> @ bcampbell@pingidentity.com = >>>>>> +1 720.317.2061 >>>>>> @pingidentity >>>>>> Connect with us! >>>>>> >>>>>> = = = = = = = = _____________________________________= __________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth = >>=20 >=20 --Apple-Mail=_3EEE783F-3436-4681-98E9-B352AC28BA79 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 The current text of 6 has.
Alternatively, the content of the token could be
   passed by reference rather than by value (requiring a separate
   message exchange to resolve the reference to the token =
content).

The = rest of 6 is an example of using the signed method.  not the only = method.

On Nov 25, 2015, at 5:31 PM, = John Bradley <ve7jtb@ve7jtb.com> wrote:

Yes all access = tokens bearer or PoP are audienced to the RS, Integrity protected in a = way the RS can verify, and if required encrypted to the RS.

I would guess that a = majority of deployments I know of want introspection or encrypted AT to = protect the confidentiality of the attributes passed in the access = token.
There is commonly user and or role info that = they want to protect.   If PoP required the tokens to be = readable/verifiable by the client then it would be a non starter for = privacy reasons lots of places.

John B.


On Nov = 25, 2015, at 5:21 PM, Justin Richer <jricher@mit.edu> wrote:

The only = actual requirement is opacity. Section 6 should be more clearly called = out as an example instead, which is what it is.

Perhaps we should also re-state that = access tokens remain opaque to the client in the introductory text.

 =E2=80= =94 Justin

On Nov 25, 2015, at 3:19 PM, = Phil Hunt <phil.hunt@oracle.com> wrote:

Thats not what I = am on about. 

Kathleen objected to the signed requirement in sec 6 without = making it clear in sec 5. 

We can't have it both ways. Be both = opaque and signed for the client to verify.  

If I restore the = requirements than the threat mitigation assumption of signed tokens must = also be removed. 

Phil

On Nov 25, 2015, at 12:02, John Bradley <ve7jtb@ve7jtb.com> = wrote:

The token is opaque to the client. =  It=E2=80=99s format is a matter between the RS and the = AS. 

Where do = we require the client verify the token?    The RS is the only = party that needs to verify the access token.

The information that the client needs = about the token is in additional meta-data delivered with but not in the = AT.

I agree = with Brian that is wrong on two counts.

1) the token is opaque to the = client.
2) one method of delivering the key to the = RS is in a signed JWT.  It is however also possible (if not ideal) = for the AT to be a reference, and introspected by the RS to get the = key.

So 
"In contrast to bearer tokens = [RFC6750] which call for tokens that are opaque to OAuth 2.0 clients, = this specification defines the requirements for proof-of-possession = ("PoP") tokens that may are also opaque to OAuth 2.0 clients but may be = parsed and verified, or introspected by OAuth 2.0 Resource Servers. When = token endpoints issue =E2=80=9CPoP=E2=80=9D tokens they provide the = OAuth Client additional parameters with information on what key material = to use for the proof.=E2=80=9D

Or given that they are both = opaque that part of the statement could be dropped.

John = B. 


On Nov = 25, 2015, at 12:44 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

Except that later on we require the token be = signed and the client verify that signed token. IOW mutual pop. 

Phil

On = Nov 25, 2015, at 07:30, Brian Campbell <bcampbell@pingidentity.com> wrote:

Looking at the diff I noticed the following new = text, which seems to conflate bearer/PoP and opaqueness to the client. A = client demonstrating proof-of-possession of some key is orthogonal to = the client being able to parse and understand the access token itself. =
 
"In contrast to bearer tokens = [RFC6750] which call for tokens that are opaque to OAuth 2.0 clients, = this specification defines the requirements for proof-of-possession = ("PoP") tokens that may be parsed and verified by OAuth 2.0 clients and = relying parties."

On Tue, Nov 24, 2015 at 1:07 PM, = Phil Hunt <phil.hunt@oracle.com> wrote:
This draft addresses = review comments from Kathleen and Erik raised since the last draft.

It may not include some of the discussion from yesterday/today.  I = will add that as the group decides.

Cheers,

Phil

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

> On Nov 24, 2015, at 12:05 PM, internet-drafts@ietf.org wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts = directories.
> This draft is a work item of the Web Authorization Protocol Working = Group of the IETF.
>
>        Title          =  : OAuth 2.0 Proof-of-Possession (PoP) Security Architecture
>        Authors        =  : Phil Hunt
>                  =         Justin Richer
>                  =         William Mills
>                  =         Prateek Mishra
>                  =         Hannes Tschofenig
>       Filename        : = draft-ietf-oauth-pop-architecture-06.txt
>       Pages          =  : 23
>       Date          =   : 2015-11-24
>
> Abstract:
>   The OAuth 2.0 bearer token specification, as defined in = RFC 6750,
>   allows any party in possession of a bearer token (a = "bearer") to get
>   access to the associated resources (without = demonstrating possession
>   of a cryptographic key).  To prevent misuse, = bearer tokens must be
>   protected from disclosure in transit and at rest.
>
>   Some scenarios demand additional security protection = whereby a client
>   needs to demonstrate possession of cryptographic keying = material when
>   accessing a protected resource.  This document = motivates the
>   development of the OAuth 2.0 proof-of-possession = security mechanism.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architect= ure/
>
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-0= 6
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-pop-archit= ecture-06
>
>
> 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



--
=09 3D"Ping=20
Brian Campbell
Distinguished Engineer
Ping Identity
@ bcampbell@pingidentity.com
3D"phone" +1 720.317.2061
3D"twitter" @pingidentity
Connect with = us!
3D"pingidentity.com"
=
3D"pingidentity.com"
= 3D"twitter 3D"twitter 3D"youtube 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard 3D"rss
=
_______________________________________________OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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



= --Apple-Mail=_3EEE783F-3436-4681-98E9-B352AC28BA79-- From nobody Wed Nov 25 12:39:29 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9227C1B2F7D for ; Wed, 25 Nov 2015 12:39:27 -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, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4QDJnXgMvc0u for ; Wed, 25 Nov 2015 12:39:22 -0800 (PST) Received: from mail-qg0-x22a.google.com (mail-qg0-x22a.google.com [IPv6:2607:f8b0:400d:c04::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 81E521A8919 for ; Wed, 25 Nov 2015 12:39:19 -0800 (PST) Received: by qgcc31 with SMTP id c31so40891669qgc.3 for ; Wed, 25 Nov 2015 12:39:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PcA6Q5Qjkus2Vv8W9eTBskyFKkKl74e7ocMX+Q4TL54=; b=lyUE+baEjgoyxcFfj7oNRAzKbcB4k8FqZfLqwyucSHnmh3s7/9toY9Xt2gtUg2Nf80 BGX2Bm2i4hFJ4a7yD+0fQdBNjbOm2brREF/790ckjw8L80/DpnYxEL39ag2A83e2F1fV z0cJnLCsZapMWf55Ld0XHZjVDe+HW5Pe6tLmhj2GSCaQaT7An08ZH6Fvq/oDiAqfs742 ZouKkgWiq3JlSMGWmSSG0JVfK7k9AoEX3qdtEFmIMXYBkYMXfDRtgfwB/XZrAasaYsMj sqk+18EEScwP22nZ61FBe3BwNlNssAVFPtFyDF0AB1mYmxN3+WD7lqHQy5tx38Yzi/wK xabA== X-Received: by 10.140.89.113 with SMTP id u104mr36073349qgd.98.1448483958710; Wed, 25 Nov 2015 12:39:18 -0800 (PST) Received: from [10.60.76.50] (mobile-107-107-57-11.mycingular.net. [107.107.57.11]) by smtp.gmail.com with ESMTPSA id 31sm5997012qgy.13.2015.11.25.12.39.16 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 25 Nov 2015 12:39:17 -0800 (PST) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: multipart/alternative; boundary=Apple-Mail-BDE9C893-E631-447F-8357-0A960F41AA42 Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (12H143) In-Reply-To: <9E20E73C-AC35-4E03-A011-119A32CD0BF1@ve7jtb.com> Date: Wed, 25 Nov 2015 15:39:14 -0500 Content-Transfer-Encoding: 7bit Message-Id: <7431079B-818C-46E9-8102-D193E49384B2@gmail.com> References: <20151124200512.20833.28463.idtracker@ietfa.amsl.com> <16FAD3AC-CFB8-46D5-A12E-436E902EA439@oracle.com> <6015EE15-1FEE-43DC-930C-68ACAEDC083E@oracle.com> <38555799-721C-4A2F-AAAA-24D9B69EB72E@mit.edu> <1AD1F44B-9837-4288-9997-5292F1DBE30E@oracle.com> <9E20E73C-AC35-4E03-A011-119A32CD0BF1@ve7jtb.com> To: John Bradley Archived-At: Cc: "" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-pop-architecture-06.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2015 20:39:27 -0000 --Apple-Mail-BDE9C893-E631-447F-8357-0A960F41AA42 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, Sent from my iPhone > On Nov 25, 2015, at 3:20 PM, John Bradley wrote: >=20 > Tokens are signed or the information is otherwise integrity protected betw= een the AS and the RS. =20 >=20 > I suspect Kathleen is concerned about the key getting modified in transit.= =20 > That needs to be protected against, but there is more than one way to do t= hat. Phil is correct. I was looking for consistency between the sections since t= hey related to each other. If there is a security risk or consideration, th= at needs to be explicitly called out as a concern such as a key being modifi= ed in transit. If there are options to protect against that, those would id= eally be required or would have warnings. >=20 > So sending the public key in a unsigned JWT access token would be immensel= y stupid, not just for PoP but for scopes and everything else. Good, easy to require then. Thanks, Kathleen=20 >=20 > In OAuth 2 all tokens need to be integrity protected between the AS and RS= . =20 > That can be via signature, by having a reference with sufficient entropy a= nd secure introspection or database lookup. >=20 > I think that is a OAuth 2 security consideration. We are adding a additi= onal confirmation claim to the existing information that needs to be protect= ed the same as the rest. >=20 > John B. >=20 >=20 >> On Nov 25, 2015, at 4:38 PM, Phil Hunt wrote: >>=20 >> >> If there is agreement that tokens are opaque then the requirement that to= kens be signed must be removed from the threat mitigation requirements.=20 >>=20 >> And the paragraph in sec 5 that brian was concerned about be restored.=20= >>=20 >> Phil >>=20 >>> On Nov 25, 2015, at 11:24, Justin Richer wrote: >>>=20 >>> It is still end to end authentication with opaque tokens =E2=80=94 since= all OAuth tokens, including PoP tokens, have always been intended to be opa= que to the client. That hasn=E2=80=99t changed and that isn=E2=80=99t the in= tent of this document. If that=E2=80=99s how people are reading it then we n= eed to pull it back and rewrite it so that=E2=80=99s not the case. >>>=20 >>> The client gets a token that has two parts: the token and the key. The t= oken is analogous to the access_token we have today and would come out of th= e server in the same field. The key is handed to the client alongside the to= ken or registered by the client during the token request. Either way there=E2= =80=99s an association between the two but it=E2=80=99s not the same associa= tion as a public/private keypair.=20 >>>=20 >>> It=E2=80=99s possible to sign the token itself, but the client doesn=E2=80= =99t care. It sends the token and signs the HTTP request to the RS whether t= he token is signed, unsigned, hex blob, encrypted, or anything else. The sam= e series of options are available as with bearer tokens. PoP tokens have nev= er, ever been intended to be anything but opaque to the client. >>>=20 >>> The token can=E2=80=99t be opaque to the RS, which has to figure out wha= t key to use to check the message signature. But we=E2=80=99ve got options t= here, like the embedded key in a JWT from Mike=E2=80=99s draft, or doing int= rospection to get the key (from an extension that hasn=E2=80=99t been writte= n yet), or simply looking it up in the same database because the RS and the A= S are in the same box. Does this structure/service/database choice sound fam= iliar? It should, it=E2=80=99s the same as bearer tokens. This is also how t= he RS gets information like which scopes are associated with the token, if i= t=E2=80=99s expired, and all that.=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> So here=E2=80=99s how I see it going on the wire: >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> (I just wrote this up so there are probably holes. Here=E2=80=99s the so= urce if anyone wants to tweak it: http://www.websequencediagrams.com/?lz=3Dc= GFydGljaXBhbnQgQ2xpZW50IGFzIEMKAAwMUmVzb3VyY2UgT3duZXIgYXMgUk8AFA1BdXRob3Jpe= mF0aW9uIFNlcnYAIQZBUwA7DVByb3RlY3RlZABICmFzIFJTCgoKClJPLS0-QzogR28gZ2V0IG15I= HIAbwcKQy0tPlJPOiBSZWRpcmVjdCB0byBBUy9BRQAvBkFTOiBMb2cgaW4sIGEAgQIHZSBjAIFHB= QpBUwAqEwAVBwBrCEhhbmQAKQcAPAUgZ3JhbnQKCmFsdCBzAIFGBnN1cHBsaWVkIGtleQpDAG4GV= G9rZW4gcmVxdWVzdCAoADAFKQpBUwCBDAZnZW5lcmF0ZSB0ACIFYW4ANwUva2V5cGFpcgAiBUMAP= AgmIEsAEAtlbHMAgTcIAE8pICYga2V5AGYYLCBhc3NvY2lhdGUgd2l0aACBQQUAcBIKZW5kCgpDL= T5SUzogUgCBUQdpbmNsdWRpbmcAgT4Lc2lnbmVkAEEKAIIkBnRydWN0dXJlZACBbQYKUlMARAZja= GVjawCCAAdzaWduYXR1cmUgLyBkZWNyeXB0AB8PUGFycwCCLgcAOQlVbnBhY2sAgncFAIIYBWlud= HJvc3BlY3RpbwBiBkFTOiBzZW4AdAcgKG5vdABiCikgdG8AJQ9BAIEVBwAvBWtleSAocHVibGljI= G9yIHNoYXJlZCkAgwIGZGF0YWJhc2UAgUUJbG9vayB1cABhCGxvY2FsLwAtBiBEQikAHQthAIQoB= gCCUAUAgX4OAIQsCACCBAp1c2luZwCEWAUAGw9pZ2h0cwCDNQoAgm4HAIJbBgCCXQVDOiByZXR1c= m4AhicJ&s=3Dmodern-blue ) >>>=20 >>> The client is oblivious to the token just like always. This is intention= al. The RS has the same options to figure out how to process the token. >>>=20 >>> =E2=80=94 Justin >>>=20 >>>> On Nov 25, 2015, at 2:03 PM, Phil Hunt wrote: >>>>=20 >>>> Folks,=20 >>>>=20 >>>> >>>> I did not want to go here either. :-) >>>>=20 >>>> I don=E2=80=99t read sec 6 as examples. I believe this may stem from t= he pop-architecture documents having a dual role as both =E2=80=9Carchitectu= re=E2=80=9D and =E2=80=9Cuse-case=E2=80=9D. Maybe we should clarify the pur= pose of the document? >>>>=20 >>>> I believe section 6 is talking about threat mitigation assumptions base= d on the examples that need to be implemented. I am assuming these are requ= irements that the other specifications SHOULD implement. >>>>=20 >>>> >>>> I do not believe we have discussed Opaque PoP tokens and any inherent r= isks because the client is not or is unable to validate the authenticity of t= he token. Does this introduce the possibility of a MITM attack where a clie= nt can be convinced to sign requests for an attacker? >>>>=20 >>>> If we want to include opaque PoP, I think we need to take a pause and c= onsider / discuss any threats here. >>>>=20 >>>> I find the desire for opaque PoP tokens to be a bit contradictory. If w= e=E2=80=99re saying we don=E2=80=99t want to trust TLS alone (e.g. because o= f load-balancer termination), why would we then say, but we are perfectly wi= lling to accept it worked for the OAuth AS exchanges? Maybe I was very wron= g here, but my assumption all along is that for PoP we=E2=80=99re talking ab= out end-to-end authentication of all parties except in the case of 3.3 where= we simply want to protect an access token over a non-TLS HTTP connection. >>>>=20 >>>>=20 >>>> Phil >>>>=20 >>>> @independentid >>>> www.independentid.com >>>> phil.hunt@oracle.com >>>>=20 >>>>> On Nov 25, 2015, at 10:48 AM, Brian Campbell wrote: >>>>>=20 >>>>> While I can't say I disagree with the deeper existential questions abo= ut the draft that Justin raises, I was trying not to go there and rather jus= t point out concerns with the newly added text.=20 >>>>>=20 >>>>> The text Phil cites from Sec 6 doesn't say the client must be able to p= arse and verify the token. It's an assumption to simplify the examples that f= ollow and still the token is opaque to the client. I reread the whole draft (= reluctantly) and there's nothing that says the token has to be non-opaque to= the client. And it does talk about reference style tokens and encrypted tok= ens, both of which rely on the opaqueness to the client.=20 >>>>>=20 >>>>>> On Wed, Nov 25, 2015 at 11:27 AM, Justin Richer wro= te: >>>>>> Right, I read that as text for describing the examples and not for de= scribing requirements. >>>>>>=20 >>>>>> The token itself doesn=E2=80=99t have to be signed at all. >>>>>>=20 >>>>>> =E2=80=94 Justin >>>>>>=20 >>>>>>> On Nov 25, 2015, at 1:05 PM, Phil Hunt wrote:= >>>>>>>=20 >>>>>>> Ok. Well this was requested by Kathleen because of this paragraph in= Sec 6.=E2=80=A6 >>>>>>>=20 >>>>>>> To simplify the subsequent description we assume in the PoP archi= tecture >>>>>>> that the token itself is digitally signed by the authorization se= rver >>>>>>> and therefore cannot be modified. >>>>>>>=20 >>>>>>> Please=20 >>>>>>> Phil >>>>>>>=20 >>>>>>> @independentid >>>>>>> www.independentid.com >>>>>>> phil.hunt@oracle.com >>>>>>>=20 >>>>>>>> On Nov 25, 2015, at 9:33 AM, Justin Richer wrote:= >>>>>>>>=20 >>>>>>>> The token doesn=E2=80=99t have to be signed and the client doesn=E2= =80=99t have to verify the signature on the token. That=E2=80=99s not PoP. T= he request has to be signed in a way that includes the token. The token itse= lf can still be opaque. The *key* material can=E2=80=99t be opaque to the cl= ient, but the *token* material still is. >>>>>>>>=20 >>>>>>>> I agree with Brian that this statement is misleading. >>>>>>>>=20 >>>>>>>> The examples use a signed token but that is absolutely not a requir= ement. Maybe the examples shouldn=E2=80=99t all use one style. >>>>>>>>=20 >>>>>>>> What=E2=80=99s most difficult about this particular spec is that it= =E2=80=99s very hand-wavy, saying =E2=80=9Cthis is kinda a thing that kinda w= orks like this=E2=80=9D without saying how to actually do it. I=E2=80=99m ho= nestly not sure it=E2=80=99s worth publishing as an RFC in its own right but= I=E2=80=99m not going to stand in its way. >>>>>>>>=20 >>>>>>>> =E2=80=94 Justin >>>>>>>>=20 >>>>>>>>> On Nov 25, 2015, at 12:14 PM, Brian Campbell wrote: >>>>>>>>>=20 >>>>>>>>> Where does it say that?=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> On Wed, Nov 25, 2015 at 8:44 AM, Phil Hunt = wrote: >>>>>>>>>> Except that later on we require the token be signed and the clien= t verify that signed token. IOW mutual pop.=20 >>>>>>>>>>=20 >>>>>>>>>> Phil >>>>>>>>>>=20 >>>>>>>>>>> On Nov 25, 2015, at 07:30, Brian Campbell wrote: >>>>>>>>>>>=20 >>>>>>>>>>> Looking at the diff I noticed the following new text, which seem= s to conflate bearer/PoP and opaqueness to the client. A client demonstratin= g proof-of-possession of some key is orthogonal to the client being able to p= arse and understand the access token itself.=20 >>>>>>>>>>> =20 >>>>>>>>>>> "In contrast to bearer tokens [RFC6750] which call for tokens th= at are opaque to OAuth 2.0 clients, this specification defines the requireme= nts for proof-of-possession ("PoP") tokens that may be parsed and verified b= y OAuth 2.0 clients and relying parties." >>>>>>>>>>>=20 >>>>>>>>>>>> On Tue, Nov 24, 2015 at 1:07 PM, Phil Hunt wrote: >>>>>>>>>>>> This draft addresses review comments from Kathleen and Erik rai= sed since the last draft. >>>>>>>>>>>>=20 >>>>>>>>>>>> It may not include some of the discussion from yesterday/today.= I will add that as the group decides. >>>>>>>>>>>>=20 >>>>>>>>>>>> Cheers, >>>>>>>>>>>>=20 >>>>>>>>>>>> Phil >>>>>>>>>>>>=20 >>>>>>>>>>>> @independentid >>>>>>>>>>>> www.independentid.com >>>>>>>>>>>> phil.hunt@oracle.com >>>>>>>>>>>>=20 >>>>>>>>>>>> > On Nov 24, 2015, at 12:05 PM, internet-drafts@ietf.org wrote:= >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > A New Internet-Draft is available from the on-line Internet-D= rafts directories. >>>>>>>>>>>> > This draft is a work item of the Web Authorization Protocol W= orking Group of the IETF. >>>>>>>>>>>> > >>>>>>>>>>>> > Title : OAuth 2.0 Proof-of-Possession (PoP) S= ecurity Architecture >>>>>>>>>>>> > Authors : Phil Hunt >>>>>>>>>>>> > Justin Richer >>>>>>>>>>>> > William Mills >>>>>>>>>>>> > Prateek Mishra >>>>>>>>>>>> > Hannes Tschofenig >>>>>>>>>>>> > Filename : draft-ietf-oauth-pop-architecture-06.= txt >>>>>>>>>>>> > Pages : 23 >>>>>>>>>>>> > Date : 2015-11-24 >>>>>>>>>>>> > >>>>>>>>>>>> > Abstract: >>>>>>>>>>>> > The OAuth 2.0 bearer token specification, as defined in RFC= 6750, >>>>>>>>>>>> > allows any party in possession of a bearer token (a "bearer= ") to get >>>>>>>>>>>> > access to the associated resources (without demonstrating p= ossession >>>>>>>>>>>> > of a cryptographic key). To prevent misuse, bearer tokens m= ust be >>>>>>>>>>>> > protected from disclosure in transit and at rest. >>>>>>>>>>>> > >>>>>>>>>>>> > Some scenarios demand additional security protection whereb= y a client >>>>>>>>>>>> > needs to demonstrate possession of cryptographic keying mat= erial when >>>>>>>>>>>> > accessing a protected resource. This document motivates th= e >>>>>>>>>>>> > development of the OAuth 2.0 proof-of-possession security m= echanism. >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > The IETF datatracker status page for this draft is: >>>>>>>>>>>> > https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-archite= cture/ >>>>>>>>>>>> > >>>>>>>>>>>> > There's also a htmlized version available at: >>>>>>>>>>>> > https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture= -06 >>>>>>>>>>>> > >>>>>>>>>>>> > A diff from the previous version is available at: >>>>>>>>>>>> > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-pop-arch= itecture-06 >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > Please note that it may take a couple of minutes from the tim= e of submission >>>>>>>>>>>> > until the htmlized version and diff are available at tools.ie= tf.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 >>>>>>>>>>>>=20 >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> --=20 >>>>>>>>>>> =09 >>>>>>>>>>> Brian Campbell >>>>>>>>>>> Distinguished Engineer >>>>>>>>>>> Ping Identity >>>>>>>>>>> @ bcampbell@pingidentity.com >>>>>>>>>>> +1 720.317.2061 >>>>>>>>>>> @pingidentity >>>>>>>>>>> Connect with us! >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> =20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> --=20 >>>>>>>>> =09 >>>>>>>>> Brian Campbell >>>>>>>>> Distinguished Engineer >>>>>>>>> Ping Identity >>>>>>>>> @ bcampbell@pingidentity.com >>>>>>>>> +1 720.317.2061 >>>>>>>>> @pingidentity >>>>>>>>> Connect with us! >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> =20 >>>>>>>>> _______________________________________________ >>>>>>>>> OAuth mailing list >>>>>>>>> OAuth@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>=20 >>>>>=20 >>>>>=20 >>>>> --=20 >>>>> =09 >>>>> Brian Campbell >>>>> Distinguished Engineer >>>>> Ping Identity >>>>> @ bcampbell@pingidentity.com >>>>> +1 720.317.2061 >>>>> @pingidentity >>>>> Connect with us! >>>>>=20 >>>>>=20 >>>>> =20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-BDE9C893-E631-447F-8357-0A960F41AA42 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi,

Sent from my iPhone

On Nov 25, 2015, at 3:20 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:

Tokens are signed or the information is otherwise integrity prote= cted between the AS and the RS.  

<= div class=3D"">I suspect Kathleen is concerned about the key getting modifie= d in transit.   
That needs to be protected a= gainst, but there is more than one way to do that.
<= div>
Phil is correct.  I was looking for consistency between t= he sections since they related to each other.  If there is a security r= isk or consideration, that needs to be explicitly called out as a concern su= ch as a key being modified in transit.  If there are options to protect= against that, those would ideally be required or would have warnings.

So sending the public key in a unsigned JWT access token would be imme= nsely stupid,  not just for PoP but for scopes and everything else.

Good, easy to require then.

Thanks,
Kathleen 

In OAuth 2 all tokens nee= d to be integrity protected between the AS and RS.  
That can be via signature,  by having a reference with sufficient en= tropy and secure introspection or database lookup.

I think that is a OAuth 2 security considera= tion.   We are adding a additional confirmation claim to the existing i= nformation that needs to be protected the same as the rest.

John B.


On Nov 25, 2015, at 4:38 PM, Phil Hunt <phil.hunt@oracle.com> wro= te:

<editors hat>
If there is agreement that tokens are opaque then the requirement tha= t tokens be signed must be removed from the threat mitigation requirements.&= nbsp;

And the para= graph in sec 5 that brian was concerned about be restored. 

Phil
On Nov 25, 2015, at 11:24, Justin Richer <jricher@mit.edu> wrote:

= It is still end to end authentication with opaque tokens =E2=80=94 since all= OAuth tokens, including PoP tokens, have always been intended to be opaque t= o the client. That hasn=E2=80=99t changed and that isn=E2=80=99t the intent o= f this document. If that=E2=80=99s how people are reading it then we need to= pull it back and rewrite it so that=E2=80=99s not the case.
=
The client gets a token that has two pa= rts: the token and the key. The token is analogous to the access_token we ha= ve today and would come out of the server in the same field. The key is hand= ed to the client alongside the token or registered by the client during the t= oken request. Either way there=E2=80=99s an association between the two but i= t=E2=80=99s not the same association as a public/private keypair. 

It=E2=80=99s possible t= o sign the token itself, but the client doesn=E2=80=99t care. It sends the t= oken and signs the HTTP request to the RS whether the token is signed, unsig= ned, hex blob, encrypted, or anything else. The same series of options are a= vailable as with bearer tokens. PoP tokens have never, ever been intended to= be anything but opaque to the client.

<= /div>
The token can=E2=80=99t be opaque to the RS, which has t= o figure out what key to use to check the message signature. But we=E2=80=99= ve got options there, like the embedded key in a JWT from Mike=E2=80=99s dra= ft, or doing introspection to get the key (from an extension that hasn=E2=80= =99t been written yet), or simply looking it up in the same database because= the RS and the AS are in the same box. Does this structure/service/database= choice sound familiar? It should, it=E2=80=99s the same as bearer tokens. T= his is also how the RS gets information like which scopes are associated wit= h the token, if it=E2=80=99s expired, and all that. 




S= o here=E2=80=99s how I see it going on the wire:



3D"http://www.we=



(I just wr= ote this up so there are probably holes. Here=E2=80=99s the source if anyone= wants to tweak it: http= ://www.websequencediagrams.com/?lz=3DcGFydGljaXBhbnQgQ2xpZW50IGFzIEMKAAwMUmV= zb3VyY2UgT3duZXIgYXMgUk8AFA1BdXRob3JpemF0aW9uIFNlcnYAIQZBUwA7DVByb3RlY3RlZAB= ICmFzIFJTCgoKClJPLS0-QzogR28gZ2V0IG15IHIAbwcKQy0tPlJPOiBSZWRpcmVjdCB0byB= BUy9BRQAvBkFTOiBMb2cgaW4sIGEAgQIHZSBjAIFHBQpBUwAqEwAVBwBrCEhhbmQAKQcAPAUgZ3J= hbnQKCmFsdCBzAIFGBnN1cHBsaWVkIGtleQpDAG4GVG9rZW4gcmVxdWVzdCAoADAFKQpBUwCBDAZ= nZW5lcmF0ZSB0ACIFYW4ANwUva2V5cGFpcgAiBUMAPAgmIEsAEAtlbHMAgTcIAE8pICYga2V5AGY= YLCBhc3NvY2lhdGUgd2l0aACBQQUAcBIKZW5kCgpDLT5SUzogUgCBUQdpbmNsdWRpbmcAgT4Lc2l= nbmVkAEEKAIIkBnRydWN0dXJlZACBbQYKUlMARAZjaGVjawCCAAdzaWduYXR1cmUgLyBkZWNyeXB= 0AB8PUGFycwCCLgcAOQlVbnBhY2sAgncFAIIYBWludHJvc3BlY3RpbwBiBkFTOiBzZW4AdAcgKG5= vdABiCikgdG8AJQ9BAIEVBwAvBWtleSAocHVibGljIG9yIHNoYXJlZCkAgwIGZGF0YWJhc2UAgUU= JbG9vayB1cABhCGxvY2FsLwAtBiBEQikAHQthAIQoBgCCUAUAgX4OAIQsCACCBAp1c2luZwCEWAU= AGw9pZ2h0cwCDNQoAgm4HAIJbBgCCXQVDOiByZXR1cm4AhicJ&s=3Dmodern-blue )

The client is obliviou= s to the token just like always. This is intentional. The RS has the same op= tions to figure out how to process the token.

 =E2=80=94 Justin

On Nov 25, 2015, at 2:03 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

Folks, 
<editor hat>
I= did not want to go here either. :-)

I don=E2=80=99t read sec 6 as examples.  I believe t= his may stem from the pop-architecture documents having a dual role as both =E2= =80=9Carchitecture=E2=80=9D and =E2=80=9Cuse-case=E2=80=9D.  Maybe we s= hould clarify the purpose of the document?

I believe section 6 is talking about threat mitigat= ion assumptions based on the examples that need to be implemented.  I a= m assuming these are requirements that the other specifications SHOULD imple= ment.

<personal= hat>
I do not believe we have discussed Opaque PoP t= okens and any inherent risks because the client is not or is unable to valid= ate the authenticity of the token.  Does this introduce the possibility= of a MITM attack where a client can be convinced to sign requests for an at= tacker?

If we want= to include opaque PoP, I think we need to take a pause and consider / discu= ss any threats here.

I find the desire for opaque PoP tokens to be a bit contradictory. If we=E2= =80=99re saying we don=E2=80=99t want to trust TLS alone (e.g. because of lo= ad-balancer termination), why would we then say, but we are perfectly willin= g to accept it worked for the OAuth AS exchanges?  Maybe I was very wro= ng here, but my assumption all along is that for PoP we=E2=80=99re talking a= bout end-to-end authentication of all parties except in the case of 3.3 wher= e we simply want to protect an access token over a non-TLS HTTP connection.<= /div>


Phil

@independentid
www.independentid.com=
phil.hunt@oracle.com
<= /div>

On Nov 25, 2015, at 10:48 AM, Brian Campbell <bcampbell@pingidentity.com> wro= te:

While I can't say I disagre= e with the deeper existential questions about the draft that Justin raises, I= was trying not to go there and rather just point out concerns with the newl= y added text.

The text Phil cites from S= ec 6 doesn't say the client must be able to parse and verify the token. It's= an assumption to simplify the examples that follow and still the token is o= paque to the client. I reread the whole draft (reluctantly) and there's noth= ing that says the token has to be non-opaque to the client. And it does talk= about reference style tokens and encrypted tokens, both of which rely on th= e opaqueness to the client.

On Wed, Nov 25, 2015 at 11:2= 7 AM, Justin Richer <jricher@mit.edu> wrot= e:
Right, I read that as text for describing the examples and= not for describing requirements.

The token itself doesn=E2=80=99t have to be signed at all.

 =E2=80=94 Justin

On Nov 25, 2015, at 1= :05 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

Ok. Well this was requested b= y Kathleen because of this paragraph in Sec 6.=E2=80=A6

   To simplify the subsequent description we assume in the PoP arc=
hitecture
   that the token itself is digitally signed by the authorizati=
on server

   and therefore cannot be modified.

Please 
<= div class=3D"">
Phil

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

On Nov 25, 2015, at 9:33 AM, Justin Richer <jricher@mit.edu> wrote:
The token doesn=E2=80=99t have to be signed and the client doesn=E2=80=99= t have to verify the signature on the token. That=E2=80=99s not PoP. The req= uest has to be signed in a way that includes the token. The token itself can= still be opaque. The *key* material can=E2=80=99t be opaque to the client, b= ut the *token* material still is.

I agree with Brian that this statement is misleading.

The examples use a si= gned token but that is absolutely not a requirement. Maybe the examples shou= ldn=E2=80=99t all use one style.

<= div class=3D"">What=E2=80=99s most difficult about this particular spec is t= hat it=E2=80=99s very hand-wavy, saying =E2=80=9Cthis is kinda a thing that k= inda works like this=E2=80=9D without saying how to actually do it. I=E2=80=99= m honestly not sure it=E2=80=99s worth publishing as an RFC in its own right= but I=E2=80=99m not going to stand in its way.

 =E2=80=94 Justin
On Nov 25, 2015, at 12:14 PM, Brian Campbell <bcampbell@pingidentity= .com> wrote:

Where does it say that?



= On Wed, Nov 25, 2015 at 8:44 AM, Phil Hunt <= phil.hu= nt@oracle.com> wrote:
Except that later on we req= uire the token be signed and the client verify that signed token. IOW mutual= pop. 

Phil

On Nov 25, 2015, at 07:30, Brian Campbell <bca= mpbell@pingidentity.com> wrote:

Looking at the diff I noticed the following new text, which seems to conf= late bearer/PoP and opaqueness to the client. A client demonstrating proof-o= f-possession of some key is orthogonal to the client being able to parse and= understand the access token itself.
 
"In= contrast to bearer tokens [RFC6750] which call for tokens that are opaque t= o OAuth 2.0 clients, this specification defines the requirements for proof-o= f-possession ("PoP") tokens that may be parsed and verified by OAuth 2.0 cli= ents and relying parties."
On Tue, Nov 24, 2015 at 1:07 PM, Phi= l Hunt <phil.hunt@oracle.com> wrote:<= br class=3D"">
This draft addresses review comm= ents from Kathleen and Erik raised since the last draft.

It may not include some of the discussion from yesterday/today.  I will= add that as the group decides.

Cheers,

Phil

@independentid
www.independentid.com
phil.hu= nt@oracle.com

> On Nov 24, 2015, at 12:05 PM, internet-drafts@ietf.org wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories.
> This draft is a work item of the Web Authorization Protocol Working Gro= up of the IETF.
>
>        Title          &nbs= p;: OAuth 2.0 Proof-of-Possession (PoP) Security Architecture
= >        Authors         : P= hil Hunt
>                    &n= bsp;     Justin Richer
>                    &n= bsp;     William Mills
>                    &n= bsp;     Prateek Mishra
>                    &n= bsp;     Hannes Tschofenig
>       Filename        : draft-i= etf-oauth-pop-architecture-06.txt
>       Pages           = ;: 23
>       Date           = : 2015-11-24
>
> Abstract:
>   The OAuth 2.0 bearer token specification, as defined in RFC= 6750,
>   allows any party in possession of a bearer token (a "bearer= ") to get
>   access to the associated resources (without demonstrating p= ossession
>   of a cryptographic key).  To prevent misuse, bearer to= kens must be
>   protected from disclosure in transit and at rest.
>
>   Some scenarios demand additional security protection whereb= y a client
>   needs to demonstrate possession of cryptographic keying mat= erial when
>   accessing a protected resource.  This document motivat= es the
>   development of the OAuth 2.0 proof-of-possession security m= echanism.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker= .ietf.org/doc/draft-ietf-oauth-pop-architecture/
>
> There's also a htmlized version available at:
> https://tools.ietf.org= /html/draft-ietf-oauth-pop-architecture-06
>
> A diff from the previous version is available at:
> https://www.ie= tf.org/rfcdiff?url2=3Ddraft-ietf-oauth-pop-architecture-06
>
>
> Please note that it may take a couple of minutes from the time of submi= ssion
> until the htmlized version and diff are available at tools.ietf.= org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> OAuth mailing list
> OAuth@ie= tf.org
> https://www.ietf.org/mailman/listinfo/oauth=

_______________________________________________
OAuth mailing list
OAuth@ietf.or= g
https://www.ietf.org/mailman/listinfo/oauth<= br class=3D"">


<= br class=3D"">--
=09 3D"Ping=20
Brian C= ampbell
Distinguished Engin= eer
Ping Identity
@ bcampbell@pingidentity.com
3D"p= +1 720.317.2061
3D"twit= @pingidentity
Connect with us!
3D"pingidentity.com"
= 3D"pingidentity.com"
3D"twitter 3D"twitter 3D"youtu= 3D"LinkedIn 3D"Faceb= 3D= 3D"slid= 3D"flipboard 3D"rss



--
=09 3D"Ping=20
Brian C= ampbell
Distinguished Engin= eer
Ping Identity
@ bcampbell@pingidentity.com
3D"p= +1 720.317.2061
3D"twit= @pingidentity
Connect with us!
3D"pingidentity.com"
= 3D"pingidentity.com"
3D"twitter 3D"twitter 3D"youtu= 3D"LinkedIn 3D"Faceb= 3D= 3D"slid= 3D"flipboard 3D"rss
_______________________________________________
OAuth mailing l= ist
OAuth@ietf.org
https://www.ietf.org/mailman/li= stinfo/oauth






--
=09 3D"Ping=20
Brian C= ampbell
Distinguish= ed Engineer
Ping Identity
@ bcampbell@pingidentity.com<= /a>
3D"phone= +1 720.317.2061
3D"twitter"= @pingidentity
Connect with us!
3D"pingidentity.com"
= 3D"pingidentity.com" =3D"twitter 3D"twitter 3D"youtube 3D"LinkedIn 3D"Facebook 3D"G= 3D"slidesha= 3D"flipboard


_____________________________= __________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/l= istinfo/oauth

__________________= _____________________________
OAuth mailing list
<= span>OAuth@ietf.org
https://www.ietf.org/m= ailman/listinfo/oauth
= --Apple-Mail-BDE9C893-E631-447F-8357-0A960F41AA42-- From nobody Wed Nov 25 12:53:59 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 955881B2FD5 for ; Wed, 25 Nov 2015 12:53:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.785 X-Spam-Level: X-Spam-Status: No, score=-4.785 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IPqZSfDr90xy for ; Wed, 25 Nov 2015 12:53:50 -0800 (PST) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2EC01A893A for ; Wed, 25 Nov 2015 12:53:49 -0800 (PST) X-AuditID: 1209190f-f79d06d000004b20-9a-56561fdb74b3 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 16.F0.19232.BDF16565; Wed, 25 Nov 2015 15:53:47 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id tAPKrkYu027184; Wed, 25 Nov 2015 15:53:47 -0500 Received: from artemisia.richer.local (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id tAPKrixe021857 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 25 Nov 2015 15:53:45 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_47C8A66C-9C11-4124-83F6-1FCF75B5B52C" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Justin Richer In-Reply-To: <7431079B-818C-46E9-8102-D193E49384B2@gmail.com> Date: Wed, 25 Nov 2015 15:53:44 -0500 Message-Id: <638FA321-4DE1-467C-9B5C-3BEA0EC3EB0F@mit.edu> References: <20151124200512.20833.28463.idtracker@ietfa.amsl.com> <16FAD3AC-CFB8-46D5-A12E-436E902EA439@oracle.com> <6015EE15-1FEE-43DC-930C-68ACAEDC083E@oracle.com> <38555799-721C-4A2F-AAAA-24D9B69EB72E@mit.edu> <1AD1F44B-9837-4288-9997-5292F1DBE30E@oracle.com> <9E20E73C-AC35-4E03-A011-119A32CD0BF1@ve7jtb.com> <7431079B-818C-46E9-8102-D193E49384B2@gmail.com> To: Kathleen Moriarty X-Mailer: Apple Mail (2.2104) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDKsWRmVeSWpSXmKPExsUixG6nrntbPizMYM4XFYuGnfkWJ9++YrNY ffcvmwOzx85Zd9k9liz5yeRx+/ZGlgDmKC6blNSczLLUIn27BK6MvTvvshU8esVS0frrKnsD 45d5LF2MnBwSAiYS535/ZIOwxSQu3FsPZHNxCAksZpKY/+0nO4SzkVGi9e86RgjnIZPE47nv mUBamAUSJLZem8cMYvMK6Em8unWZFcQWFvCRuHj6CZjNJqAqMX1NC1g9p4CtxKO3F4GmcnCw AMX/tgRCjPGU2PPsAiPEGCuJhy8eM0Ps+sUqsfDnd7A5IgIWEmuav0GdKiux+/cjpgmMArOQ nDELyRkQcW2JZQtfM0PYmhL7u5ezYIprSHR+m8i6gJFtFaNsSm6Vbm5iZk5xarJucXJiXl5q ka6JXm5miV5qSukmRlAkcEry72D8dlDpEKMAB6MSD++LJyFhQqyJZcWVuYcYJTmYlER5LTnC woT4kvJTKjMSizPii0pzUosPMUpwMCuJ8G77EBomxJuSWFmVWpQPk5LmYFES5537xTdMSCA9 sSQ1OzW1ILUIJivDwaEkwXteDmioYFFqempFWmZOCUKaiYMTZDgP0PAOkBre4oLE3OLMdIj8 KUZFKXHemSAJAZBERmkeXC8oUSW8PWz6ilEc6BVh3nSQKh5gkoPrfgU0mAlocEQOyNXFJYkI KakGxsaf3Pa7b6gay0m8r7IxceGSW3q+nzV6hsT6t9Wza7tq+oUv9Lw+dvh16n85479iQnGG vZJq7xsm5K3zU5uvG5V0Vj2srVfBK6+BOWHDow9LtfQTP2pGzrIXbDCW81RgCzFgMlB7ufTS vk/zZp+xy3vhdUj/c8Jc18zVD1UUjD9m669ZqXpAiaU4I9FQi7moOBEAMtThgS8DAAA= Archived-At: Cc: "" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-pop-architecture-06.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2015 20:53:56 -0000 --Apple-Mail=_47C8A66C-9C11-4124-83F6-1FCF75B5B52C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The requirement is not that signed JWTs be used, it=E2=80=99s that = unsigned JWTs not be used on their own. Reference tokens and encrypted = JWTs are also valid, as are other signed formats like SAML assertions or = even a COSE Token (if it=E2=80=99s encoded to HTTP friendliness).=20 My recommendation: Remove the erroneous requirement text from section 5 and restore to = previous version. Amend the text in section 6 from: To simplify the subsequent description we assume in the PoP architecture that the token itself is digitally signed by the authorization server and therefore cannot be modified. To: In all such cases, the token remains opaque to the client. To simplify the subsequent example and description we assume in the PoP = architecture that the token itself cannot be modified by the client, either due to cryptographic protection (such as signature or encryption) or use of=20= a reference value with sufficient entropy and associated secure = lookup. These are characteristics shared with bearer tokens and more = information on best practices can be found in [[RFC6819]] and in the security=20 considerations section of [[RFC6750]].=20 =E2=80=94 Justin > On Nov 25, 2015, at 3:39 PM, Kathleen Moriarty = wrote: >=20 > Hi, >=20 > Sent from my iPhone >=20 > On Nov 25, 2015, at 3:20 PM, John Bradley > wrote: >=20 >> Tokens are signed or the information is otherwise integrity protected = between the AS and the RS. =20 >>=20 >> I suspect Kathleen is concerned about the key getting modified in = transit. =20 >> That needs to be protected against, but there is more than one way to = do that. >=20 > Phil is correct. I was looking for consistency between the sections = since they related to each other. If there is a security risk or = consideration, that needs to be explicitly called out as a concern such = as a key being modified in transit. If there are options to protect = against that, those would ideally be required or would have warnings. >>=20 >> So sending the public key in a unsigned JWT access token would be = immensely stupid, not just for PoP but for scopes and everything else. >=20 > Good, easy to require then. >=20 > Thanks, > Kathleen=20 >>=20 >> In OAuth 2 all tokens need to be integrity protected between the AS = and RS. =20 >> That can be via signature, by having a reference with sufficient = entropy and secure introspection or database lookup. >>=20 >> I think that is a OAuth 2 security consideration. We are adding a = additional confirmation claim to the existing information that needs to = be protected the same as the rest. >>=20 >> John B. >>=20 >>=20 >>> On Nov 25, 2015, at 4:38 PM, Phil Hunt > wrote: >>>=20 >>> >>> If there is agreement that tokens are opaque then the requirement = that tokens be signed must be removed from the threat mitigation = requirements.=20 >>>=20 >>> And the paragraph in sec 5 that brian was concerned about be = restored.=20 >>>=20 >>> Phil >>>=20 >>> On Nov 25, 2015, at 11:24, Justin Richer > wrote: >>>=20 >>>> It is still end to end authentication with opaque tokens =E2=80=94 = since all OAuth tokens, including PoP tokens, have always been intended = to be opaque to the client. That hasn=E2=80=99t changed and that isn=E2=80= =99t the intent of this document. If that=E2=80=99s how people are = reading it then we need to pull it back and rewrite it so that=E2=80=99s = not the case. >>>>=20 >>>> The client gets a token that has two parts: the token and the key. = The token is analogous to the access_token we have today and would come = out of the server in the same field. The key is handed to the client = alongside the token or registered by the client during the token = request. Either way there=E2=80=99s an association between the two but = it=E2=80=99s not the same association as a public/private keypair.=20 >>>>=20 >>>> It=E2=80=99s possible to sign the token itself, but the client = doesn=E2=80=99t care. It sends the token and signs the HTTP request to = the RS whether the token is signed, unsigned, hex blob, encrypted, or = anything else. The same series of options are available as with bearer = tokens. PoP tokens have never, ever been intended to be anything but = opaque to the client. >>>>=20 >>>> The token can=E2=80=99t be opaque to the RS, which has to figure = out what key to use to check the message signature. But we=E2=80=99ve = got options there, like the embedded key in a JWT from Mike=E2=80=99s = draft, or doing introspection to get the key (from an extension that = hasn=E2=80=99t been written yet), or simply looking it up in the same = database because the RS and the AS are in the same box. Does this = structure/service/database choice sound familiar? It should, it=E2=80=99s = the same as bearer tokens. This is also how the RS gets information like = which scopes are associated with the token, if it=E2=80=99s expired, and = all that.=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> So here=E2=80=99s how I see it going on the wire: >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> (I just wrote this up so there are probably holes. Here=E2=80=99s = the source if anyone wants to tweak it: = http://www.websequencediagrams.com/?lz=3DcGFydGljaXBhbnQgQ2xpZW50IGFzIEMKA= AwMUmVzb3VyY2UgT3duZXIgYXMgUk8AFA1BdXRob3JpemF0aW9uIFNlcnYAIQZBUwA7DVByb3R= lY3RlZABICmFzIFJTCgoKClJPLS0 = -QzogR28gZ2V0IG15IHIAbwcKQy0tPlJPOiBSZWRpcmV= jdCB0byBBUy9BRQAvBkFTOiBMb2cgaW4sIGEAgQIHZSBjAIFHBQpBUwAqEwAVBwBrCEhhbmQAK= QcAPAUgZ3JhbnQKCmFsdCBzAIFGBnN1cHBsaWVkIGtleQpDAG4GVG9rZW4gcmVxdWVzdCAoADA= FKQpBUwCBDAZnZW5lcmF0ZSB0ACIFYW4ANwUva2V5cGFpcgAiBUMAPAgmIEsAEAtlbHMAgTcIA= E8pICYga2V5AGYYLCBhc3NvY2lhdGUgd2l0aACBQQUAcBIKZW5kCgpDLT5SUzogUgCBUQdpbmN= sdWRpbmcAgT4Lc2lnbmVkAEEKAIIkBnRydWN0dXJlZACBbQYKUlMARAZjaGVjawCCAAdzaWduY= XR1cmUgLyBkZWNyeXB0AB8PUGFycwCCLgcAOQlVbnBhY2sAgncFAIIYBWludHJvc3BlY3RpbwB= iBkFTOiBzZW4AdAcgKG5vdABiCikgdG8AJQ9BAIEVBwAvBWtleSAocHVibGljIG9yIHNoYXJlZ= CkAgwIGZGF0YWJhc2UAgUUJbG9vayB1cABhCGxvY2FsLwAtBiBEQikAHQthAIQoBgCCUAUAgX4= OAIQsCACCBAp1c2luZwCEWAUAGw9pZ2h0cwCDNQoAgm4HAIJbBgCCXQVDOiByZXR1cm4AhicJ&= s=3Dmodern-blue ) >>>>=20 >>>> The client is oblivious to the token just like always. This is = intentional. The RS has the same options to figure out how to process = the token. >>>>=20 >>>> =E2=80=94 Justin >>>>=20 >>>>> On Nov 25, 2015, at 2:03 PM, Phil Hunt > wrote: >>>>>=20 >>>>> Folks,=20 >>>>>=20 >>>>> >>>>> I did not want to go here either. :-) >>>>>=20 >>>>> I don=E2=80=99t read sec 6 as examples. I believe this may stem = from the pop-architecture documents having a dual role as both = =E2=80=9Carchitecture=E2=80=9D and =E2=80=9Cuse-case=E2=80=9D. Maybe we = should clarify the purpose of the document? >>>>>=20 >>>>> I believe section 6 is talking about threat mitigation assumptions = based on the examples that need to be implemented. I am assuming these = are requirements that the other specifications SHOULD implement. >>>>>=20 >>>>> >>>>> I do not believe we have discussed Opaque PoP tokens and any = inherent risks because the client is not or is unable to validate the = authenticity of the token. Does this introduce the possibility of a = MITM attack where a client can be convinced to sign requests for an = attacker? >>>>>=20 >>>>> If we want to include opaque PoP, I think we need to take a pause = and consider / discuss any threats here. >>>>>=20 >>>>> I find the desire for opaque PoP tokens to be a bit contradictory. = If we=E2=80=99re saying we don=E2=80=99t want to trust TLS alone (e.g. = because of load-balancer termination), why would we then say, but we are = perfectly willing to accept it worked for the OAuth AS exchanges? Maybe = I was very wrong here, but my assumption all along is that for PoP = we=E2=80=99re talking about end-to-end authentication of all parties = except in the case of 3.3 where we simply want to protect an access = token over a non-TLS HTTP connection. >>>>>=20 >>>>>=20 >>>>> Phil >>>>>=20 >>>>> @independentid >>>>> www.independentid.com = phil.hunt@oracle.com = >>>>>> On Nov 25, 2015, at 10:48 AM, Brian Campbell = > wrote: >>>>>>=20 >>>>>> While I can't say I disagree with the deeper existential = questions about the draft that Justin raises, I was trying not to go = there and rather just point out concerns with the newly added text.=20 >>>>>>=20 >>>>>> The text Phil cites from Sec 6 doesn't say the client must be = able to parse and verify the token. It's an assumption to simplify the = examples that follow and still the token is opaque to the client. I = reread the whole draft (reluctantly) and there's nothing that says the = token has to be non-opaque to the client. And it does talk about = reference style tokens and encrypted tokens, both of which rely on the = opaqueness to the client.=20 >>>>>>=20 >>>>>> On Wed, Nov 25, 2015 at 11:27 AM, Justin Richer > wrote: >>>>>> Right, I read that as text for describing the examples and not = for describing requirements. >>>>>>=20 >>>>>> The token itself doesn=E2=80=99t have to be signed at all. >>>>>>=20 >>>>>> =E2=80=94 Justin >>>>>>=20 >>>>>>> On Nov 25, 2015, at 1:05 PM, Phil Hunt > wrote: >>>>>>>=20 >>>>>>> Ok. Well this was requested by Kathleen because of this = paragraph in Sec 6.=E2=80=A6 >>>>>>>=20 >>>>>>> To simplify the subsequent description we assume in the PoP = architecture >>>>>>> that the token itself is digitally signed by the = authorization server >>>>>>> and therefore cannot be modified. >>>>>>>=20 >>>>>>> Please=20 >>>>>>> Phil >>>>>>>=20 >>>>>>> @independentid >>>>>>> www.independentid.com = phil.hunt@oracle.com = >>>>>>>> On Nov 25, 2015, at 9:33 AM, Justin Richer > wrote: >>>>>>>>=20 >>>>>>>> The token doesn=E2=80=99t have to be signed and the client = doesn=E2=80=99t have to verify the signature on the token. That=E2=80=99s = not PoP. The request has to be signed in a way that includes the token. = The token itself can still be opaque. The *key* material can=E2=80=99t = be opaque to the client, but the *token* material still is. >>>>>>>>=20 >>>>>>>> I agree with Brian that this statement is misleading. >>>>>>>>=20 >>>>>>>> The examples use a signed token but that is absolutely not a = requirement. Maybe the examples shouldn=E2=80=99t all use one style. >>>>>>>>=20 >>>>>>>> What=E2=80=99s most difficult about this particular spec is = that it=E2=80=99s very hand-wavy, saying =E2=80=9Cthis is kinda a thing = that kinda works like this=E2=80=9D without saying how to actually do = it. I=E2=80=99m honestly not sure it=E2=80=99s worth publishing as an = RFC in its own right but I=E2=80=99m not going to stand in its way. >>>>>>>>=20 >>>>>>>> =E2=80=94 Justin >>>>>>>>=20 >>>>>>>>> On Nov 25, 2015, at 12:14 PM, Brian Campbell = > wrote: >>>>>>>>>=20 >>>>>>>>> Where does it say that?=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> On Wed, Nov 25, 2015 at 8:44 AM, Phil Hunt = > wrote: >>>>>>>>> Except that later on we require the token be signed and the = client verify that signed token. IOW mutual pop.=20 >>>>>>>>>=20 >>>>>>>>> Phil >>>>>>>>>=20 >>>>>>>>> On Nov 25, 2015, at 07:30, Brian Campbell = > wrote: >>>>>>>>>=20 >>>>>>>>>> Looking at the diff I noticed the following new text, which = seems to conflate bearer/PoP and opaqueness to the client. A client = demonstrating proof-of-possession of some key is orthogonal to the = client being able to parse and understand the access token itself.=20 >>>>>>>>>> =20 >>>>>>>>>> "In contrast to bearer tokens [RFC6750] which call for tokens = that are opaque to OAuth 2.0 clients, this specification defines the = requirements for proof-of-possession ("PoP") tokens that may be parsed = and verified by OAuth 2.0 clients and relying parties." >>>>>>>>>>=20 >>>>>>>>>> On Tue, Nov 24, 2015 at 1:07 PM, Phil Hunt = > wrote: >>>>>>>>>> This draft addresses review comments from Kathleen and Erik = raised since the last draft. >>>>>>>>>>=20 >>>>>>>>>> It may not include some of the discussion from = yesterday/today. I will add that as the group decides. >>>>>>>>>>=20 >>>>>>>>>> Cheers, >>>>>>>>>>=20 >>>>>>>>>> Phil >>>>>>>>>>=20 >>>>>>>>>> @independentid >>>>>>>>>> www.independentid.com >>>>>>>>>> phil.hunt@oracle.com >>>>>>>>>>=20 >>>>>>>>>> > On Nov 24, 2015, at 12:05 PM, internet-drafts@ietf.org = wrote: >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > A New Internet-Draft is available from the on-line = Internet-Drafts directories. >>>>>>>>>> > This draft is a work item of the Web Authorization Protocol = Working Group of the IETF. >>>>>>>>>> > >>>>>>>>>> > Title : OAuth 2.0 Proof-of-Possession = (PoP) Security Architecture >>>>>>>>>> > Authors : Phil Hunt >>>>>>>>>> > Justin Richer >>>>>>>>>> > William Mills >>>>>>>>>> > Prateek Mishra >>>>>>>>>> > Hannes Tschofenig >>>>>>>>>> > Filename : = draft-ietf-oauth-pop-architecture-06.txt >>>>>>>>>> > Pages : 23 >>>>>>>>>> > Date : 2015-11-24 >>>>>>>>>> > >>>>>>>>>> > Abstract: >>>>>>>>>> > The OAuth 2.0 bearer token specification, as defined in = RFC 6750, >>>>>>>>>> > allows any party in possession of a bearer token (a = "bearer") to get >>>>>>>>>> > access to the associated resources (without demonstrating = possession >>>>>>>>>> > of a cryptographic key). To prevent misuse, bearer = tokens must be >>>>>>>>>> > protected from disclosure in transit and at rest. >>>>>>>>>> > >>>>>>>>>> > Some scenarios demand additional security protection = whereby a client >>>>>>>>>> > needs to demonstrate possession of cryptographic keying = material when >>>>>>>>>> > accessing a protected resource. This document motivates = the >>>>>>>>>> > development of the OAuth 2.0 proof-of-possession security = mechanism. >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > The IETF datatracker status page for this draft is: >>>>>>>>>> > = https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architecture/ = >>>>>>>>>> > >>>>>>>>>> > There's also a htmlized version available at: >>>>>>>>>> > = https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-06 = >>>>>>>>>> > >>>>>>>>>> > A diff from the previous version is available at: >>>>>>>>>> > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-pop-architecture-06 = = >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > 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 = >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> OAuth mailing list >>>>>>>>>> OAuth@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> --=20 >>>>>>>>>> =09 >>>>>>>>>> Brian Campbell >>>>>>>>>> Distinguished Engineer >>>>>>>>>> Ping Identity >>>>>>>>>> @ bcampbell@pingidentity.com = >>>>>>>>>> +1 720.317.2061 >>>>>>>>>> @pingidentity >>>>>>>>>> Connect with us! >>>>>>>>>> = >>>>>>>>>> = = = = = = = = >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> --=20 >>>>>>>>> =09 >>>>>>>>> Brian Campbell >>>>>>>>> Distinguished Engineer >>>>>>>>> Ping Identity >>>>>>>>> @ bcampbell@pingidentity.com = >>>>>>>>> +1 720.317.2061 >>>>>>>>> @pingidentity >>>>>>>>> Connect with us! >>>>>>>>> = >>>>>>>>> = = = = = = = = _____________________________________= __________ >>>>>>>>> OAuth mailing list >>>>>>>>> OAuth@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> --=20 >>>>>> =09 >>>>>> Brian Campbell >>>>>> Distinguished Engineer >>>>>> Ping Identity >>>>>> @ bcampbell@pingidentity.com = >>>>>> +1 720.317.2061 >>>>>> @pingidentity >>>>>> Connect with us! >>>>>> >>>>>> = = = = = = = = >>>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth = >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_47C8A66C-9C11-4124-83F6-1FCF75B5B52C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 The requirement is not that signed JWTs be used, it=E2=80=99s = that unsigned JWTs not be used on their own. Reference tokens and = encrypted JWTs are also valid, as are other signed formats like SAML = assertions or even a COSE Token (if it=E2=80=99s encoded to HTTP = friendliness). 

My recommendation:

Remove the erroneous requirement text = from section 5 and restore to previous version.

Amend the text in section 6 = from:

   To
   simplify the subsequent description we assume in the PoP architecture

   that the token itself is digitally =
signed by the authorization server
   and therefore cannot be modified.


To:

   In all such cases, the token =
remains opaque to the client. To
   simplify the subsequent example and description we assume in the PoP =
architecture
   that the token itself cannot =
be modified by the client, either due to
   =
cryptographic protection (such as signature or encryption) or use =
of 
   a reference value with =
sufficient entropy and associated secure lookup.
   These are characteristics shared with bearer tokens =
and more information
   on best practices =
can be found in [[RFC6819]] and in the security 
   considerations section of [[RFC6750]].


 =E2=80=94 Justin

On Nov 25, 2015, at 3:39 PM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:

Hi,

Sent from my iPhone

On Nov 25, 2015, at 3:20 PM, John Bradley <ve7jtb@ve7jtb.com> = wrote:

Tokens are signed or the information is = otherwise integrity protected between the AS and the RS.  

I suspect Kathleen is = concerned about the key getting modified in transit. =   
That needs to be protected against, = but there is more than one way to do that.

Phil is correct.  I was looking for = consistency between the sections since they related to each other. =  If there is a security risk or consideration, that needs to be = explicitly called out as a concern such as a key being modified in = transit.  If there are options to protect against that, those would = ideally be required or would have warnings.

So sending the public key in a unsigned = JWT access token would be immensely stupid,  not just for PoP but = for scopes and everything else.

Good, easy to require then.

Thanks,
Kathleen 

In OAuth 2 all tokens need to be integrity protected between = the AS and RS.  
That can be via signature, =  by having a reference with sufficient entropy and secure = introspection or database lookup.

I think that is a OAuth 2 security = consideration.   We are adding a additional confirmation claim to = the existing information that needs to be protected the same as the = rest.

John = B.


On Nov 25, 2015, at 4:38 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

<editors hat>
If = there is agreement that tokens are opaque then the requirement that = tokens be signed must be removed from the threat mitigation = requirements. 

And the paragraph in sec 5 that brian was concerned about be = restored. 

Phil

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

It = is still end to end authentication with opaque tokens =E2=80=94 since = all OAuth tokens, including PoP tokens, have always been intended to be = opaque to the client. That hasn=E2=80=99t changed and that isn=E2=80=99t = the intent of this document. If that=E2=80=99s how people are reading it = then we need to pull it back and rewrite it so that=E2=80=99s not the = case.

The client = gets a token that has two parts: the token and the key. The token is = analogous to the access_token we have today and would come out of the = server in the same field. The key is handed to the client alongside the = token or registered by the client during the token request. Either way = there=E2=80=99s an association between the two but it=E2=80=99s not the = same association as a public/private keypair. 

It=E2=80=99s possible to = sign the token itself, but the client doesn=E2=80=99t care. It sends the = token and signs the HTTP request to the RS whether the token is signed, = unsigned, hex blob, encrypted, or anything else. The same series of = options are available as with bearer tokens. PoP tokens have never, ever = been intended to be anything but opaque to the client.

The token can=E2=80=99t = be opaque to the RS, which has to figure out what key to use to check = the message signature. But we=E2=80=99ve got options there, like the = embedded key in a JWT from Mike=E2=80=99s draft, or doing introspection = to get the key (from an extension that hasn=E2=80=99t been written yet), = or simply looking it up in the same database because the RS and the AS = are in the same box. Does this structure/service/database choice sound = familiar? It should, it=E2=80=99s the same as bearer tokens. This is = also how the RS gets information like which scopes are associated with = the token, if it=E2=80=99s expired, and all that. 




So here=E2=80=99s how I see it going on the wire:



3D"http://www.websequencediagrams.com/cgi-bin/cdraw?lz=3DcGFydGljaXBhb=



(I just wrote this up so there are = probably holes. Here=E2=80=99s the source if anyone wants to tweak = it: http://www.websequencediagrams.com/?lz=3DcGFydGljaXBhbnQgQ2xpZW= 50IGFzIEMKAAwMUmVzb3VyY2UgT3duZXIgYXMgUk8AFA1BdXRob3JpemF0aW9uIFNlcnYAIQZB= UwA7DVByb3RlY3RlZABICmFzIFJTCgoKClJPLS0-QzogR28gZ2V0IG15IHIAbwcKQy0tPl= JPOiBSZWRpcmVjdCB0byBBUy9BRQAvBkFTOiBMb2cgaW4sIGEAgQIHZSBjAIFHBQpBUwAqEwAV= BwBrCEhhbmQAKQcAPAUgZ3JhbnQKCmFsdCBzAIFGBnN1cHBsaWVkIGtleQpDAG4GVG9rZW4gcm= VxdWVzdCAoADAFKQpBUwCBDAZnZW5lcmF0ZSB0ACIFYW4ANwUva2V5cGFpcgAiBUMAPAgmIEsA= EAtlbHMAgTcIAE8pICYga2V5AGYYLCBhc3NvY2lhdGUgd2l0aACBQQUAcBIKZW5kCgpDLT5SUz= ogUgCBUQdpbmNsdWRpbmcAgT4Lc2lnbmVkAEEKAIIkBnRydWN0dXJlZACBbQYKUlMARAZjaGVj= awCCAAdzaWduYXR1cmUgLyBkZWNyeXB0AB8PUGFycwCCLgcAOQlVbnBhY2sAgncFAIIYBWludH= Jvc3BlY3RpbwBiBkFTOiBzZW4AdAcgKG5vdABiCikgdG8AJQ9BAIEVBwAvBWtleSAocHVibGlj= IG9yIHNoYXJlZCkAgwIGZGF0YWJhc2UAgUUJbG9vayB1cABhCGxvY2FsLwAtBiBEQikAHQthAI= QoBgCCUAUAgX4OAIQsCACCBAp1c2luZwCEWAUAGw9pZ2h0cwCDNQoAgm4HAIJbBgCCXQVDOiBy= ZXR1cm4AhicJ&s=3Dmodern-blue )

The client is oblivious to the token = just like always. This is intentional. The RS has the same options to = figure out how to process the token.

 =E2=80=94 Justin

On Nov 25, 2015, at 2:03 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

Folks, 

<editor = hat>
I did not want to go here either. = :-)

I don=E2=80=99= t read sec 6 as examples.  I believe this may stem from the = pop-architecture documents having a dual role as both =E2=80=9Carchitectur= e=E2=80=9D and =E2=80=9Cuse-case=E2=80=9D.  Maybe we should clarify = the purpose of the document?

I believe section 6 is talking about = threat mitigation assumptions based on the examples that need to be = implemented.  I am assuming these are requirements that the other = specifications SHOULD implement.

<personal hat>
I do not believe we have discussed Opaque PoP tokens and any = inherent risks because the client is not or is unable to validate the = authenticity of the token.  Does this introduce the possibility of = a MITM attack where a client can be convinced to sign requests for an = attacker?

If = we want to include opaque PoP, I think we need to take a pause and = consider / discuss any threats here.

I find the desire for opaque PoP tokens = to be a bit contradictory. If we=E2=80=99re saying we don=E2=80=99t want = to trust TLS alone (e.g. because of load-balancer termination), why = would we then say, but we are perfectly willing to accept it worked for = the OAuth AS exchanges?  Maybe I was very wrong here, but my = assumption all along is that for PoP we=E2=80=99re talking about = end-to-end authentication of all parties except in the case of 3.3 where = we simply want to protect an access token over a non-TLS HTTP = connection.



On Nov 25, 2015, at 10:48 AM, Brian Campbell <bcampbell@pingidentity.com> wrote:

While I can't say I disagree = with the deeper existential questions about the draft that Justin = raises, I was trying not to go there and rather just point out concerns = with the newly added text.

The text = Phil cites from Sec 6 doesn't say the client must be able to parse and = verify the token. It's an assumption to simplify the examples that = follow and still the token is opaque to the client. I reread the whole = draft (reluctantly) and there's nothing that says the token has to be = non-opaque to the client. And it does talk about reference style tokens = and encrypted tokens, both of which rely on the opaqueness to the = client.

On Wed, Nov 25, 2015 at 11:27 AM, = Justin Richer <jricher@mit.edu> wrote:
Right, I read that as text for describing the examples and = not for describing requirements.

The token itself doesn=E2=80=99t have to be signed at = all.

 =E2=80=94 = Justin

On Nov 25, 2015, at 1:05 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

Ok. Well this was = requested by Kathleen because of this paragraph in Sec 6.=E2=80=A6

   =
To simplify the subsequent description we assume in the PoP =
architecture
   =
that the token itself is digitally signed by the authorization server

   and therefore cannot be modified.

Please 

On Nov 25, 2015, at 9:33 AM, Justin Richer <jricher@mit.edu> wrote:

The token = doesn=E2=80=99t have to be signed and the client doesn=E2=80=99t have to = verify the signature on the token. That=E2=80=99s not PoP. The request = has to be signed in a way that includes the token. The token itself can = still be opaque. The *key* material can=E2=80=99t be opaque to the = client, but the *token* material still is.

I agree with Brian that this statement = is misleading.

The examples use a signed token but that is absolutely not a = requirement. Maybe the examples shouldn=E2=80=99t all use one = style.

What=E2=80= =99s most difficult about this particular spec is that it=E2=80=99s very = hand-wavy, saying =E2=80=9Cthis is kinda a thing that kinda works like = this=E2=80=9D without saying how to actually do it. I=E2=80=99m honestly = not sure it=E2=80=99s worth publishing as an RFC in its own right but = I=E2=80=99m not going to stand in its way.

 =E2=80=94 Justin

On Nov 25, 2015, at 12:14 PM, Brian Campbell = <bcampbell@pingidentity.com> wrote:

Where does it say = that?



On Wed, = Nov 25, 2015 at 8:44 AM, Phil Hunt <phil.hunt@oracle.com> wrote:
Except that later on we require the token be = signed and the client verify that signed token. IOW mutual = pop. 

Phil

On Nov 25, 2015, at 07:30, = Brian Campbell <bcampbell@pingidentity.com> = wrote:

Looking at the = diff I noticed the following new text, which seems to conflate = bearer/PoP and opaqueness to the client. A client demonstrating = proof-of-possession of some key is orthogonal to the client being able = to parse and understand the access token itself.
 
"In contrast to bearer tokens [RFC6750] which call for tokens = that are opaque to OAuth 2.0 clients, this specification defines the = requirements for proof-of-possession ("PoP") tokens that may be parsed = and verified by OAuth 2.0 clients and relying parties."

On Tue, Nov 24, 2015 at 1:07 PM, Phil Hunt <phil.hunt@oracle.com> = wrote:
This draft = addresses review comments from Kathleen and Erik raised since the last = draft.

It may not include some of the discussion from yesterday/today.  I = will add that as the group decides.

Cheers,

Phil

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

> On Nov 24, 2015, at 12:05 PM, internet-drafts@ietf.org wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts = directories.
> This draft is a work item of the Web Authorization Protocol Working = Group of the IETF.
>
>        Title          =  : OAuth 2.0 Proof-of-Possession (PoP) Security Architecture
>        Authors        =  : Phil Hunt
>                  =         Justin Richer
>                  =         William Mills
>                  =         Prateek Mishra
>                  =         Hannes Tschofenig
>       Filename        : = draft-ietf-oauth-pop-architecture-06.txt
>       Pages          =  : 23
>       Date          =   : 2015-11-24
>
> Abstract:
>   The OAuth 2.0 bearer token specification, as defined in = RFC 6750,
>   allows any party in possession of a bearer token (a = "bearer") to get
>   access to the associated resources (without = demonstrating possession
>   of a cryptographic key).  To prevent misuse, = bearer tokens must be
>   protected from disclosure in transit and at rest.
>
>   Some scenarios demand additional security protection = whereby a client
>   needs to demonstrate possession of cryptographic keying = material when
>   accessing a protected resource.  This document = motivates the
>   development of the OAuth 2.0 proof-of-possession = security mechanism.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architect= ure/
>
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-0= 6
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-pop-archit= ecture-06
>
>
> 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



--
=09 3D"Ping=20
Brian Campbell
Distinguished Engineer
Ping = Identity
@ bcampbell@pingidentity.com
3D"phone" +1 720.317.2061
3D"twitter" @pingidentity
Connect with = us!
3D"pingidentity.com"
=
3D"pingidentity.com"
= 3D"twitter 3D"twitter 3D"youtube 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard= 3D"rss


--
=09 3D"Ping=20
Brian Campbell
Distinguished Engineer
Ping = Identity
@ bcampbell@pingidentity.com
3D"phone" +1 720.317.2061
3D"twitter" @pingidentity
Connect with = us!
3D"pingidentity.com"
=
3D"pingidentity.com"
= 3D"twitter 3D"twitter 3D"youtube 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard= 3D"rss
_______________________________________________
OAuth = mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth






--
=09 3D"Ping=20
Brian Campbell
Distinguished Engineer
Ping Identity
@ bcampbell@pingidentity.com
3D"phone" +1 720.317.2061
3D"twitter" @pingidentity
Connect with = us!
3D"pingidentity.com"
=
3D"pingidentity.com"
= 3D"twitter 3D"twitter 3D"youtube 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard 3D"rss


________________________________= _______________
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

= --Apple-Mail=_47C8A66C-9C11-4124-83F6-1FCF75B5B52C-- From nobody Wed Nov 25 12:55:33 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DCC61B2FF5 for ; Wed, 25 Nov 2015 12:55:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l71crZ9bYTJX for ; Wed, 25 Nov 2015 12:55:26 -0800 (PST) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::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 9E1FB1B2FD5 for ; Wed, 25 Nov 2015 12:55:25 -0800 (PST) Received: by qkao63 with SMTP id o63so20558935qka.2 for ; Wed, 25 Nov 2015 12:55:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=1I96BQSIqmEr0UFNrQi0eiWBaJSxuPT9OjT66AohecI=; b=R1zWQ6VAwlGjnYTLXs5/Y88kG7KKNHYyAbmCCzXhxNuc4DFghBbT5XPL5Un3yPB66t 3gsCXtzWGgnWkC26q2xU1FO6IrMDXx/eJl2uRjePJmSKX4TRPV4ZsvqFl++swXJgpsG1 cETqT/cCBN2heMl9dwHktZzk7USxJiSur/ub1JK5V5YwbuVVQ9tDCSbC4GG/X1sKmbrN v/+KqKOV9RGw0eAcTIY4t16TlNf6YxREXGKSsjQLcdyl/eC38tP2IABbRr6KH5Tr+ODe pzZc3EliDC0z+452bShfyrOBU5eIwhFTTIvPwFl9A8eCHlhLAieSHVtitkaezhT0KXJD WNVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=1I96BQSIqmEr0UFNrQi0eiWBaJSxuPT9OjT66AohecI=; b=Qnlw0/YREAa4lfeatwBCW/0XG4y/JdnXTRRUVwOkDG0wpukWmglXLzUd6Co69UKdGC xS114ksBwXvt1y1Y6fyvunclPxSPv21p3ERI+B0CdFjlR0/M/kt1MT8oKg0gGRn3SRRr TtxHHb7faVKf7PIKCxnqmQ094oEsJHATdTH+WU9GAka+b6CUp0S5H3UF8Iys74Afh2uf UDIY4MXPDmrkce49IsxcIn2m8wVSDrgg1YPguEK4+a9VCYEvKe5yGySKXOGrU67IaZ5W DsUC/778OqQny021OFpGAES7dSDX+kpViq2bI783/yZP47tP56gPB3qKjARpR/tfdlWj p8jA== X-Gm-Message-State: ALoCoQnfTtnQPi4grAEkMuvfLpid4SzkJTX//FFCOW+nhMH01Mad24uWBKcpBe1SQKffNYPy8Shu X-Received: by 10.55.33.40 with SMTP id h40mr41168219qkh.77.1448484924678; Wed, 25 Nov 2015 12:55:24 -0800 (PST) Received: from [192.168.1.216] ([191.115.122.254]) by smtp.gmail.com with ESMTPSA id a19sm6036501qgf.45.2015.11.25.12.55.13 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 25 Nov 2015 12:55:23 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_D1325A63-744D-4B0B-B479-538740A3A4B3" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: John Bradley In-Reply-To: <7431079B-818C-46E9-8102-D193E49384B2@gmail.com> Date: Wed, 25 Nov 2015 17:55:06 -0300 Message-Id: References: <20151124200512.20833.28463.idtracker@ietfa.amsl.com> <16FAD3AC-CFB8-46D5-A12E-436E902EA439@oracle.com> <6015EE15-1FEE-43DC-930C-68ACAEDC083E@oracle.com> <38555799-721C-4A2F-AAAA-24D9B69EB72E@mit.edu> <1AD1F44B-9837-4288-9997-5292F1DBE30E@oracle.com> <9E20E73C-AC35-4E03-A011-119A32CD0BF1@ve7jtb.com> <7431079B-818C-46E9-8102-D193E49384B2@gmail.com> To: Kathleen Moriarty X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-pop-architecture-06.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2015 20:55:32 -0000 --Apple-Mail=_D1325A63-744D-4B0B-B479-538740A3A4B3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I have been assuming that security considerations from RFC 6750 would be = applied to =E2=80=9CPoP=E2=80=9D tokens as well when the tokens = presentment/confirmation specs are done. Sec 5.2 of RFC 6750 covers mitigations for modification and manufacture = for by value and by reference tokens. Do we want to keep repeating this information in all documents or = reference it? It is fair to say that the threats and mitigations from bearer tokens = also apply to PoP tokens. PoP tokens add additional key information that must also be protected = along with the other information in a access token. John B. > On Nov 25, 2015, at 5:39 PM, Kathleen Moriarty = wrote: >=20 > Hi, >=20 > Sent from my iPhone >=20 > On Nov 25, 2015, at 3:20 PM, John Bradley > wrote: >=20 >> Tokens are signed or the information is otherwise integrity protected = between the AS and the RS. =20 >>=20 >> I suspect Kathleen is concerned about the key getting modified in = transit. =20 >> That needs to be protected against, but there is more than one way to = do that. >=20 > Phil is correct. I was looking for consistency between the sections = since they related to each other. If there is a security risk or = consideration, that needs to be explicitly called out as a concern such = as a key being modified in transit. If there are options to protect = against that, those would ideally be required or would have warnings. >>=20 >> So sending the public key in a unsigned JWT access token would be = immensely stupid, not just for PoP but for scopes and everything else. >=20 > Good, easy to require then. >=20 > Thanks, > Kathleen=20 >>=20 >> In OAuth 2 all tokens need to be integrity protected between the AS = and RS. =20 >> That can be via signature, by having a reference with sufficient = entropy and secure introspection or database lookup. >>=20 >> I think that is a OAuth 2 security consideration. We are adding a = additional confirmation claim to the existing information that needs to = be protected the same as the rest. >>=20 >> John B. >>=20 >>=20 >>> On Nov 25, 2015, at 4:38 PM, Phil Hunt > wrote: >>>=20 >>> >>> If there is agreement that tokens are opaque then the requirement = that tokens be signed must be removed from the threat mitigation = requirements.=20 >>>=20 >>> And the paragraph in sec 5 that brian was concerned about be = restored.=20 >>>=20 >>> Phil >>>=20 >>> On Nov 25, 2015, at 11:24, Justin Richer > wrote: >>>=20 >>>> It is still end to end authentication with opaque tokens =E2=80=94 = since all OAuth tokens, including PoP tokens, have always been intended = to be opaque to the client. That hasn=E2=80=99t changed and that isn=E2=80= =99t the intent of this document. If that=E2=80=99s how people are = reading it then we need to pull it back and rewrite it so that=E2=80=99s = not the case. >>>>=20 >>>> The client gets a token that has two parts: the token and the key. = The token is analogous to the access_token we have today and would come = out of the server in the same field. The key is handed to the client = alongside the token or registered by the client during the token = request. Either way there=E2=80=99s an association between the two but = it=E2=80=99s not the same association as a public/private keypair.=20 >>>>=20 >>>> It=E2=80=99s possible to sign the token itself, but the client = doesn=E2=80=99t care. It sends the token and signs the HTTP request to = the RS whether the token is signed, unsigned, hex blob, encrypted, or = anything else. The same series of options are available as with bearer = tokens. PoP tokens have never, ever been intended to be anything but = opaque to the client. >>>>=20 >>>> The token can=E2=80=99t be opaque to the RS, which has to figure = out what key to use to check the message signature. But we=E2=80=99ve = got options there, like the embedded key in a JWT from Mike=E2=80=99s = draft, or doing introspection to get the key (from an extension that = hasn=E2=80=99t been written yet), or simply looking it up in the same = database because the RS and the AS are in the same box. Does this = structure/service/database choice sound familiar? It should, it=E2=80=99s = the same as bearer tokens. This is also how the RS gets information like = which scopes are associated with the token, if it=E2=80=99s expired, and = all that.=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> So here=E2=80=99s how I see it going on the wire: >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> (I just wrote this up so there are probably holes. Here=E2=80=99s = the source if anyone wants to tweak it: = http://www.websequencediagrams.com/?lz=3DcGFydGljaXBhbnQgQ2xpZW50IGFzIEMKA= AwMUmVzb3VyY2UgT3duZXIgYXMgUk8AFA1BdXRob3JpemF0aW9uIFNlcnYAIQZBUwA7DVByb3R= lY3RlZABICmFzIFJTCgoKClJPLS0 = -QzogR28gZ2V0IG15IHIAbwcKQy0tPlJPOiBSZWRpcmV= jdCB0byBBUy9BRQAvBkFTOiBMb2cgaW4sIGEAgQIHZSBjAIFHBQpBUwAqEwAVBwBrCEhhbmQAK= QcAPAUgZ3JhbnQKCmFsdCBzAIFGBnN1cHBsaWVkIGtleQpDAG4GVG9rZW4gcmVxdWVzdCAoADA= FKQpBUwCBDAZnZW5lcmF0ZSB0ACIFYW4ANwUva2V5cGFpcgAiBUMAPAgmIEsAEAtlbHMAgTcIA= E8pICYga2V5AGYYLCBhc3NvY2lhdGUgd2l0aACBQQUAcBIKZW5kCgpDLT5SUzogUgCBUQdpbmN= sdWRpbmcAgT4Lc2lnbmVkAEEKAIIkBnRydWN0dXJlZACBbQYKUlMARAZjaGVjawCCAAdzaWduY= XR1cmUgLyBkZWNyeXB0AB8PUGFycwCCLgcAOQlVbnBhY2sAgncFAIIYBWludHJvc3BlY3RpbwB= iBkFTOiBzZW4AdAcgKG5vdABiCikgdG8AJQ9BAIEVBwAvBWtleSAocHVibGljIG9yIHNoYXJlZ= CkAgwIGZGF0YWJhc2UAgUUJbG9vayB1cABhCGxvY2FsLwAtBiBEQikAHQthAIQoBgCCUAUAgX4= OAIQsCACCBAp1c2luZwCEWAUAGw9pZ2h0cwCDNQoAgm4HAIJbBgCCXQVDOiByZXR1cm4AhicJ&= s=3Dmodern-blue ) >>>>=20 >>>> The client is oblivious to the token just like always. This is = intentional. The RS has the same options to figure out how to process = the token. >>>>=20 >>>> =E2=80=94 Justin >>>>=20 >>>>> On Nov 25, 2015, at 2:03 PM, Phil Hunt > wrote: >>>>>=20 >>>>> Folks,=20 >>>>>=20 >>>>> >>>>> I did not want to go here either. :-) >>>>>=20 >>>>> I don=E2=80=99t read sec 6 as examples. I believe this may stem = from the pop-architecture documents having a dual role as both = =E2=80=9Carchitecture=E2=80=9D and =E2=80=9Cuse-case=E2=80=9D. Maybe we = should clarify the purpose of the document? >>>>>=20 >>>>> I believe section 6 is talking about threat mitigation assumptions = based on the examples that need to be implemented. I am assuming these = are requirements that the other specifications SHOULD implement. >>>>>=20 >>>>> >>>>> I do not believe we have discussed Opaque PoP tokens and any = inherent risks because the client is not or is unable to validate the = authenticity of the token. Does this introduce the possibility of a = MITM attack where a client can be convinced to sign requests for an = attacker? >>>>>=20 >>>>> If we want to include opaque PoP, I think we need to take a pause = and consider / discuss any threats here. >>>>>=20 >>>>> I find the desire for opaque PoP tokens to be a bit contradictory. = If we=E2=80=99re saying we don=E2=80=99t want to trust TLS alone (e.g. = because of load-balancer termination), why would we then say, but we are = perfectly willing to accept it worked for the OAuth AS exchanges? Maybe = I was very wrong here, but my assumption all along is that for PoP = we=E2=80=99re talking about end-to-end authentication of all parties = except in the case of 3.3 where we simply want to protect an access = token over a non-TLS HTTP connection. >>>>>=20 >>>>>=20 >>>>> Phil >>>>>=20 >>>>> @independentid >>>>> www.independentid.com = phil.hunt@oracle.com = >>>>>> On Nov 25, 2015, at 10:48 AM, Brian Campbell = > wrote: >>>>>>=20 >>>>>> While I can't say I disagree with the deeper existential = questions about the draft that Justin raises, I was trying not to go = there and rather just point out concerns with the newly added text.=20 >>>>>>=20 >>>>>> The text Phil cites from Sec 6 doesn't say the client must be = able to parse and verify the token. It's an assumption to simplify the = examples that follow and still the token is opaque to the client. I = reread the whole draft (reluctantly) and there's nothing that says the = token has to be non-opaque to the client. And it does talk about = reference style tokens and encrypted tokens, both of which rely on the = opaqueness to the client.=20 >>>>>>=20 >>>>>> On Wed, Nov 25, 2015 at 11:27 AM, Justin Richer > wrote: >>>>>> Right, I read that as text for describing the examples and not = for describing requirements. >>>>>>=20 >>>>>> The token itself doesn=E2=80=99t have to be signed at all. >>>>>>=20 >>>>>> =E2=80=94 Justin >>>>>>=20 >>>>>>> On Nov 25, 2015, at 1:05 PM, Phil Hunt > wrote: >>>>>>>=20 >>>>>>> Ok. Well this was requested by Kathleen because of this = paragraph in Sec 6.=E2=80=A6 >>>>>>>=20 >>>>>>> To simplify the subsequent description we assume in the PoP = architecture >>>>>>> that the token itself is digitally signed by the = authorization server >>>>>>> and therefore cannot be modified. >>>>>>>=20 >>>>>>> Please=20 >>>>>>> Phil >>>>>>>=20 >>>>>>> @independentid >>>>>>> www.independentid.com = phil.hunt@oracle.com = >>>>>>>> On Nov 25, 2015, at 9:33 AM, Justin Richer > wrote: >>>>>>>>=20 >>>>>>>> The token doesn=E2=80=99t have to be signed and the client = doesn=E2=80=99t have to verify the signature on the token. That=E2=80=99s = not PoP. The request has to be signed in a way that includes the token. = The token itself can still be opaque. The *key* material can=E2=80=99t = be opaque to the client, but the *token* material still is. >>>>>>>>=20 >>>>>>>> I agree with Brian that this statement is misleading. >>>>>>>>=20 >>>>>>>> The examples use a signed token but that is absolutely not a = requirement. Maybe the examples shouldn=E2=80=99t all use one style. >>>>>>>>=20 >>>>>>>> What=E2=80=99s most difficult about this particular spec is = that it=E2=80=99s very hand-wavy, saying =E2=80=9Cthis is kinda a thing = that kinda works like this=E2=80=9D without saying how to actually do = it. I=E2=80=99m honestly not sure it=E2=80=99s worth publishing as an = RFC in its own right but I=E2=80=99m not going to stand in its way. >>>>>>>>=20 >>>>>>>> =E2=80=94 Justin >>>>>>>>=20 >>>>>>>>> On Nov 25, 2015, at 12:14 PM, Brian Campbell = > wrote: >>>>>>>>>=20 >>>>>>>>> Where does it say that?=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> On Wed, Nov 25, 2015 at 8:44 AM, Phil Hunt = > wrote: >>>>>>>>> Except that later on we require the token be signed and the = client verify that signed token. IOW mutual pop.=20 >>>>>>>>>=20 >>>>>>>>> Phil >>>>>>>>>=20 >>>>>>>>> On Nov 25, 2015, at 07:30, Brian Campbell = > wrote: >>>>>>>>>=20 >>>>>>>>>> Looking at the diff I noticed the following new text, which = seems to conflate bearer/PoP and opaqueness to the client. A client = demonstrating proof-of-possession of some key is orthogonal to the = client being able to parse and understand the access token itself.=20 >>>>>>>>>> =20 >>>>>>>>>> "In contrast to bearer tokens [RFC6750] which call for tokens = that are opaque to OAuth 2.0 clients, this specification defines the = requirements for proof-of-possession ("PoP") tokens that may be parsed = and verified by OAuth 2.0 clients and relying parties." >>>>>>>>>>=20 >>>>>>>>>> On Tue, Nov 24, 2015 at 1:07 PM, Phil Hunt = > wrote: >>>>>>>>>> This draft addresses review comments from Kathleen and Erik = raised since the last draft. >>>>>>>>>>=20 >>>>>>>>>> It may not include some of the discussion from = yesterday/today. I will add that as the group decides. >>>>>>>>>>=20 >>>>>>>>>> Cheers, >>>>>>>>>>=20 >>>>>>>>>> Phil >>>>>>>>>>=20 >>>>>>>>>> @independentid >>>>>>>>>> www.independentid.com >>>>>>>>>> phil.hunt@oracle.com >>>>>>>>>>=20 >>>>>>>>>> > On Nov 24, 2015, at 12:05 PM, internet-drafts@ietf.org = wrote: >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > A New Internet-Draft is available from the on-line = Internet-Drafts directories. >>>>>>>>>> > This draft is a work item of the Web Authorization Protocol = Working Group of the IETF. >>>>>>>>>> > >>>>>>>>>> > Title : OAuth 2.0 Proof-of-Possession = (PoP) Security Architecture >>>>>>>>>> > Authors : Phil Hunt >>>>>>>>>> > Justin Richer >>>>>>>>>> > William Mills >>>>>>>>>> > Prateek Mishra >>>>>>>>>> > Hannes Tschofenig >>>>>>>>>> > Filename : = draft-ietf-oauth-pop-architecture-06.txt >>>>>>>>>> > Pages : 23 >>>>>>>>>> > Date : 2015-11-24 >>>>>>>>>> > >>>>>>>>>> > Abstract: >>>>>>>>>> > The OAuth 2.0 bearer token specification, as defined in = RFC 6750, >>>>>>>>>> > allows any party in possession of a bearer token (a = "bearer") to get >>>>>>>>>> > access to the associated resources (without demonstrating = possession >>>>>>>>>> > of a cryptographic key). To prevent misuse, bearer = tokens must be >>>>>>>>>> > protected from disclosure in transit and at rest. >>>>>>>>>> > >>>>>>>>>> > Some scenarios demand additional security protection = whereby a client >>>>>>>>>> > needs to demonstrate possession of cryptographic keying = material when >>>>>>>>>> > accessing a protected resource. This document motivates = the >>>>>>>>>> > development of the OAuth 2.0 proof-of-possession security = mechanism. >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > The IETF datatracker status page for this draft is: >>>>>>>>>> > = https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architecture/ = >>>>>>>>>> > >>>>>>>>>> > There's also a htmlized version available at: >>>>>>>>>> > = https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-06 = >>>>>>>>>> > >>>>>>>>>> > A diff from the previous version is available at: >>>>>>>>>> > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-pop-architecture-06 = = >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > 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 = >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> OAuth mailing list >>>>>>>>>> OAuth@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> --=20 >>>>>>>>>> =09 >>>>>>>>>> Brian Campbell >>>>>>>>>> Distinguished Engineer >>>>>>>>>> Ping Identity >>>>>>>>>> @ bcampbell@pingidentity.com = >>>>>>>>>> +1 720.317.2061 >>>>>>>>>> @pingidentity >>>>>>>>>> Connect with us! >>>>>>>>>> = >>>>>>>>>> = = = = = = = = >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> --=20 >>>>>>>>> =09 >>>>>>>>> Brian Campbell >>>>>>>>> Distinguished Engineer >>>>>>>>> Ping Identity >>>>>>>>> @ bcampbell@pingidentity.com = >>>>>>>>> +1 720.317.2061 >>>>>>>>> @pingidentity >>>>>>>>> Connect with us! >>>>>>>>> = >>>>>>>>> = = = = = = = = _____________________________________= __________ >>>>>>>>> OAuth mailing list >>>>>>>>> OAuth@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> --=20 >>>>>> =09 >>>>>> Brian Campbell >>>>>> Distinguished Engineer >>>>>> Ping Identity >>>>>> @ bcampbell@pingidentity.com = >>>>>> +1 720.317.2061 >>>>>> @pingidentity >>>>>> Connect with us! >>>>>> >>>>>> = = = = = = = = >>>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth = >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = --Apple-Mail=_D1325A63-744D-4B0B-B479-538740A3A4B3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I have been assuming that security considerations from RFC = 6750 would be applied to =E2=80=9CPoP=E2=80=9D tokens as well when the = tokens presentment/confirmation specs are done.

Sec 5.2 of RFC 6750 covers mitigations = for modification and manufacture for by value and by reference = tokens.

Do we = want to keep repeating this information in all documents or reference = it?

It is fair = to say that the threats and mitigations from bearer tokens also apply to = PoP tokens.
PoP tokens add additional key = information that must also be protected along with the other information = in a access token.

John B.

On = Nov 25, 2015, at 5:39 PM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:

Hi,

Sent from my iPhone

On Nov 25, = 2015, at 3:20 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:

Tokens are = signed or the information is otherwise integrity protected between the = AS and the RS.  

I suspect Kathleen is concerned about the key getting = modified in transit.   
That needs to be = protected against, but there is more than one way to do = that.

Phil is correct.  I was looking for = consistency between the sections since they related to each other. =  If there is a security risk or consideration, that needs to be = explicitly called out as a concern such as a key being modified in = transit.  If there are options to protect against that, those would = ideally be required or would have warnings.

So sending the public = key in a unsigned JWT access token would be immensely stupid,  not = just for PoP but for scopes and everything = else.

Good, easy to require then.

Thanks,
Kathleen 

In OAuth 2 all tokens = need to be integrity protected between the AS and RS.  
That can be via signature,  by having a reference with = sufficient entropy and secure introspection or database = lookup.

I = think that is a OAuth 2 security consideration.   We are adding a = additional confirmation claim to the existing information that needs to = be protected the same as the rest.

John B.


On Nov = 25, 2015, at 4:38 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

<editors hat>
If = there is agreement that tokens are opaque then the requirement that = tokens be signed must be removed from the threat mitigation = requirements. 

And the paragraph in sec 5 that brian was concerned about be = restored. 

Phil

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

It = is still end to end authentication with opaque tokens =E2=80=94 since = all OAuth tokens, including PoP tokens, have always been intended to be = opaque to the client. That hasn=E2=80=99t changed and that isn=E2=80=99t = the intent of this document. If that=E2=80=99s how people are reading it = then we need to pull it back and rewrite it so that=E2=80=99s not the = case.

The client = gets a token that has two parts: the token and the key. The token is = analogous to the access_token we have today and would come out of the = server in the same field. The key is handed to the client alongside the = token or registered by the client during the token request. Either way = there=E2=80=99s an association between the two but it=E2=80=99s not the = same association as a public/private keypair. 

It=E2=80=99s possible to = sign the token itself, but the client doesn=E2=80=99t care. It sends the = token and signs the HTTP request to the RS whether the token is signed, = unsigned, hex blob, encrypted, or anything else. The same series of = options are available as with bearer tokens. PoP tokens have never, ever = been intended to be anything but opaque to the client.

The token can=E2=80=99t = be opaque to the RS, which has to figure out what key to use to check = the message signature. But we=E2=80=99ve got options there, like the = embedded key in a JWT from Mike=E2=80=99s draft, or doing introspection = to get the key (from an extension that hasn=E2=80=99t been written yet), = or simply looking it up in the same database because the RS and the AS = are in the same box. Does this structure/service/database choice sound = familiar? It should, it=E2=80=99s the same as bearer tokens. This is = also how the RS gets information like which scopes are associated with = the token, if it=E2=80=99s expired, and all that. 




So here=E2=80=99s how I see it going on the wire:



3D"http://www.websequencediagrams.com/cgi-bin/cdraw?lz=3DcGFydGljaXBhb=



(I just wrote this up so there are = probably holes. Here=E2=80=99s the source if anyone wants to tweak = it: http://www.websequencediagrams.com/?lz=3DcGFydGljaXBhbnQgQ2xpZW= 50IGFzIEMKAAwMUmVzb3VyY2UgT3duZXIgYXMgUk8AFA1BdXRob3JpemF0aW9uIFNlcnYAIQZB= UwA7DVByb3RlY3RlZABICmFzIFJTCgoKClJPLS0-QzogR28gZ2V0IG15IHIAbwcKQy0tPl= JPOiBSZWRpcmVjdCB0byBBUy9BRQAvBkFTOiBMb2cgaW4sIGEAgQIHZSBjAIFHBQpBUwAqEwAV= BwBrCEhhbmQAKQcAPAUgZ3JhbnQKCmFsdCBzAIFGBnN1cHBsaWVkIGtleQpDAG4GVG9rZW4gcm= VxdWVzdCAoADAFKQpBUwCBDAZnZW5lcmF0ZSB0ACIFYW4ANwUva2V5cGFpcgAiBUMAPAgmIEsA= EAtlbHMAgTcIAE8pICYga2V5AGYYLCBhc3NvY2lhdGUgd2l0aACBQQUAcBIKZW5kCgpDLT5SUz= ogUgCBUQdpbmNsdWRpbmcAgT4Lc2lnbmVkAEEKAIIkBnRydWN0dXJlZACBbQYKUlMARAZjaGVj= awCCAAdzaWduYXR1cmUgLyBkZWNyeXB0AB8PUGFycwCCLgcAOQlVbnBhY2sAgncFAIIYBWludH= Jvc3BlY3RpbwBiBkFTOiBzZW4AdAcgKG5vdABiCikgdG8AJQ9BAIEVBwAvBWtleSAocHVibGlj= IG9yIHNoYXJlZCkAgwIGZGF0YWJhc2UAgUUJbG9vayB1cABhCGxvY2FsLwAtBiBEQikAHQthAI= QoBgCCUAUAgX4OAIQsCACCBAp1c2luZwCEWAUAGw9pZ2h0cwCDNQoAgm4HAIJbBgCCXQVDOiBy= ZXR1cm4AhicJ&s=3Dmodern-blue )

The client is oblivious to the token = just like always. This is intentional. The RS has the same options to = figure out how to process the token.

 =E2=80=94 Justin

On Nov 25, 2015, at 2:03 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

Folks, 

<editor hat>
I= did not want to go here either. :-)

I don=E2=80=99t read sec 6 as examples. =  I believe this may stem from the pop-architecture documents having = a dual role as both =E2=80=9Carchitecture=E2=80=9D and =E2=80=9Cuse-case=E2= =80=9D.  Maybe we should clarify the purpose of the = document?

I = believe section 6 is talking about threat mitigation assumptions based = on the examples that need to be implemented.  I am assuming these = are requirements that the other specifications SHOULD = implement.

<personal hat>
I do not believe we = have discussed Opaque PoP tokens and any inherent risks because the = client is not or is unable to validate the authenticity of the token. =  Does this introduce the possibility of a MITM attack where a = client can be convinced to sign requests for an attacker?

If we want to include = opaque PoP, I think we need to take a pause and consider / discuss any = threats here.

I = find the desire for opaque PoP tokens to be a bit contradictory. If = we=E2=80=99re saying we don=E2=80=99t want to trust TLS alone (e.g. = because of load-balancer termination), why would we then say, but we are = perfectly willing to accept it worked for the OAuth AS exchanges? =  Maybe I was very wrong here, but my assumption all along is that = for PoP we=E2=80=99re talking about end-to-end authentication of all = parties except in the case of 3.3 where we simply want to protect an = access token over a non-TLS HTTP connection.


Phil

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

On Nov = 25, 2015, at 10:48 AM, Brian Campbell <bcampbell@pingidentity.com> wrote:

While I can't say I disagree = with the deeper existential questions about the draft that Justin = raises, I was trying not to go there and rather just point out concerns = with the newly added text. 

The text Phil cites from Sec 6 doesn't say the client = must be able to parse and verify the token. It's an assumption to = simplify the examples that follow and still the token is opaque to the = client. I reread the whole draft (reluctantly) and there's nothing that = says the token has to be non-opaque to the client. And it does talk = about reference style tokens and encrypted tokens, both of which rely on = the opaqueness to the client. 

On Wed, Nov 25, 2015 at 11:27 AM, Justin = Richer <jricher@mit.edu> wrote:
Right, I read that as text for = describing the examples and not for describing requirements.

The token itself = doesn=E2=80=99t have to be signed at all.

 =E2=80=94 = Justin

On Nov 25, 2015, at 1:05 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

Ok. Well = this was requested by Kathleen because of this paragraph in Sec = 6.=E2=80=A6

   To =
simplify the subsequent description we assume in the PoP =
architecture
   that the token itself is digitally signed =
by the authorization server

   and therefore cannot be modified.

Please 
Phil

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

On Nov = 25, 2015, at 9:33 AM, Justin Richer <jricher@mit.edu> wrote:

The token doesn=E2=80=99t have to be signed and the client = doesn=E2=80=99t have to verify the signature on the token. That=E2=80=99s = not PoP. The request has to be signed in a way that includes the token. = The token itself can still be opaque. The *key* material can=E2=80=99t = be opaque to the client, but the *token* material still is.

I agree with Brian that = this statement is misleading.

The examples use a signed token but = that is absolutely not a requirement. Maybe the examples shouldn=E2=80=99t= all use one style.

What=E2=80=99s most difficult about this particular spec is = that it=E2=80=99s very hand-wavy, saying =E2=80=9Cthis is kinda a thing = that kinda works like this=E2=80=9D without saying how to actually do = it. I=E2=80=99m honestly not sure it=E2=80=99s worth publishing as an = RFC in its own right but I=E2=80=99m not going to stand in its = way.

 =E2=80= =94 Justin

On Nov 25, 2015, at 12:14 PM, = Brian Campbell <bcampbell@pingidentity.com> = wrote:

Where does it say that? 



On Wed, Nov 25, 2015 at 8:44 AM, = Phil Hunt <phil.hunt@oracle.com> wrote:
Except that later on we require the token be = signed and the client verify that signed token. IOW mutual = pop. 

Phil

On Nov 25, 2015, at 07:30, = Brian Campbell <bcampbell@pingidentity.com> = wrote:

Looking at the = diff I noticed the following new text, which seems to conflate = bearer/PoP and opaqueness to the client. A client demonstrating = proof-of-possession of some key is orthogonal to the client being able = to parse and understand the access token itself. 
 
"In contrast to bearer tokens [RFC6750] which call for tokens = that are opaque to OAuth 2.0 clients, this specification defines the = requirements for proof-of-possession ("PoP") tokens that may be parsed = and verified by OAuth 2.0 clients and relying parties."

On Tue, Nov 24, 2015 at 1:07 PM, Phil Hunt <phil.hunt@oracle.com> wrote:
This draft addresses = review comments from Kathleen and Erik raised since the last draft.

It may not include some of the discussion from = yesterday/today.  I will add that as the group decides.

Cheers,

Phil

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

> On Nov 24, 2015, at 12:05 PM, internet-drafts@ietf.org wrote:
>
>
> A New Internet-Draft is available = from the on-line Internet-Drafts directories.
> This = draft is a work item of the Web Authorization Protocol Working Group of = the IETF.
>
>      =   Title           : OAuth 2.0 = Proof-of-Possession (PoP) Security Architecture
>  =       Authors         : Phil = Hunt
>              =             Justin Richer
>                =           William Mills
>  =                     =     Prateek Mishra
>      =                     = Hannes Tschofenig
>      =  Filename        : = draft-ietf-oauth-pop-architecture-06.txt
>    =    Pages           : 23
>       Date      =       : 2015-11-24
>
> = Abstract:
>   The OAuth 2.0 bearer token = specification, as defined in RFC 6750,
>  =  allows any party in possession of a bearer token (a "bearer") to = get
>   access to the associated resources = (without demonstrating possession
>   of a = cryptographic key).  To prevent misuse, bearer tokens must be
>   protected from disclosure in transit and at = rest.
>
>   Some scenarios = demand additional security protection whereby a client
>   needs to demonstrate possession of = cryptographic keying material when
>  =  accessing a protected resource.  This document motivates = the
>   development of the OAuth 2.0 = proof-of-possession security mechanism.
>
>
> The IETF datatracker status page for = this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architect= ure/
>
> There's also a htmlized = version available at:
> https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-0= 6
>
> A diff from the previous = version is available at:
> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-pop-archit= ecture-06
>
>
> = 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



-- 
3D"Ping=20 
Brian = Campbell
Distinguished Engineer
Ping = Identity
@bcampbell@pingidentity.com
3D"phone"+1 = 720.317.2061
3D"twitter"@pingidentity
Connect with us!
3D"pingidentity.com"
3D"pingidentity.com"
3D"twitter 3D"twitter 3D"youtube 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard 3D"rss
=



-- 
3D"Ping=20 
Brian = Campbell
Distinguished Engineer
Ping = Identity
@bcampbell@pingidentity.com
3D"phone"+1 = 720.317.2061
3D"twitter"@pingidentity
Connect with us!
3D"pingidentity.com"
3D"pingidentity.com"
3D"twitter 3D"twitter 3D"youtube 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard 3D"rss
=
_______________________________________________
OAuth = mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth






-- 
3D"Ping=20 
Brian = Campbell
Distinguished Engineer
Ping = Identity
@bcampbell@pingidentity.com
3D"phone"+1 720.317.2061
3D"twitter"@pingidentity
Connect with us!
3D"pingidentity.com"
3D"pingidentity.com"
3D"twitter 3D"twitter 3D"youtube 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard 3D"rss
=


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

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

= --Apple-Mail=_D1325A63-744D-4B0B-B479-538740A3A4B3-- From nobody Wed Nov 25 12:58:57 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24A7B1B3001 for ; Wed, 25 Nov 2015 12:58:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X5-TqJFbBoMh for ; Wed, 25 Nov 2015 12:58:50 -0800 (PST) Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com [IPv6:2607:f8b0:400d:c04::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 A07161A8872 for ; Wed, 25 Nov 2015 12:58:49 -0800 (PST) Received: by qgec40 with SMTP id c40so41306322qge.2 for ; Wed, 25 Nov 2015 12:58:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=vtdZNsT94lr9daaOEpr9CVAX5tNch/0FlvdRq5Wnd3A=; b=r4uXq9LQbgEXOvT9iYp/TTaVoz8cb3lsMLoNMAJytn9tK9urIHR0Nl9JbDuFFmHXGp V2uPqy4N1zK5lk/ULqghXOsnr3d8EbPA2xFcW5UoJ2S+1nxaHNdEUyinUdyEm66dShzF C+GF+o/lm0tHuFep+MFltX9haro+ViKrragRBijjZ2ieidxp2zTVrmUpCLDPFvZQDigh RrLMiu+XUtvA2Sz3Ir7/HfqNOI0bz94+nLtPlg9kt10A5TgA0c8kI+DgZjSAa02550c9 QI8uhf3d4+y6qsEistZM2Lj07xa5vfs4Ny0WQ6NJ1v1eVz4griQ3ToIH1eoXCUpsq4IJ 6cQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=vtdZNsT94lr9daaOEpr9CVAX5tNch/0FlvdRq5Wnd3A=; b=DNh1r9kERsP49RHFcj1B25nCIdOnGxruBAi/ALc8z1xb9mqiAz1GDu13+qN5e1l+Eb OuIIBxPl4ATCHdK2p6EoSmZbupTZpPTlp9jBn86vZJ9V/91RZe0DL9joRab18sI6ALH3 ZdmLVPEYME8Uwk4iBCehIW3FPyKGydHO9rh5O5Otb3pZTfzQpuGumX7CMWJAYSg7tvVm T+KtdOxnig8SmGBR/wM3z1tdR2Wsa2aHYk/EuXQokllb7Mama3pkwycQ/aALXVAqCzUK EkqIVyYJ/0c7t5p0lYuKREtbMJIoTU3bmlrQxBerDlrZ3iRrVUOqAThBpSYf63v6GwFX o1LQ== X-Gm-Message-State: ALoCoQk45iUytNHWLmIHjUx+MNacgsCs/gyDHWBtO77KxivtMcieBqDpEZHuIrgMfAx9QQ+q7elh X-Received: by 10.140.27.238 with SMTP id 101mr41112411qgx.4.1448485128636; Wed, 25 Nov 2015 12:58:48 -0800 (PST) Received: from [192.168.1.216] ([191.115.122.254]) by smtp.gmail.com with ESMTPSA id g106sm6029827qge.6.2015.11.25.12.58.42 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 25 Nov 2015 12:58:47 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_6F82A26C-E048-476D-9B61-8D843D5A84AB" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: John Bradley In-Reply-To: <638FA321-4DE1-467C-9B5C-3BEA0EC3EB0F@mit.edu> Date: Wed, 25 Nov 2015 17:58:33 -0300 Message-Id: <207E620F-97AA-4851-8776-2A7B1921D58A@ve7jtb.com> References: <20151124200512.20833.28463.idtracker@ietfa.amsl.com> <16FAD3AC-CFB8-46D5-A12E-436E902EA439@oracle.com> <6015EE15-1FEE-43DC-930C-68ACAEDC083E@oracle.com> <38555799-721C-4A2F-AAAA-24D9B69EB72E@mit.edu> <1AD1F44B-9837-4288-9997-5292F1DBE30E@oracle.com> <9E20E73C-AC35-4E03-A011-119A32CD0BF1@ve7jtb.com> <7431079B-818C-46E9-8102-D193E49384B2@gmail.com> <638FA321-4DE1-467C-9B5C-3BEA0EC3EB0F@mit.edu> To: Justin Richer X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-pop-architecture-06.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2015 20:58:56 -0000 --Apple-Mail=_6F82A26C-E048-476D-9B61-8D843D5A84AB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I am fine with that, however saying integrity protected, may be better = than signed. May people will argue that HMAC or encryption with sender = verification is not signature. However they are perfectly valid. > On Nov 25, 2015, at 5:53 PM, Justin Richer wrote: >=20 > The requirement is not that signed JWTs be used, it=E2=80=99s that = unsigned JWTs not be used on their own. Reference tokens and encrypted = JWTs are also valid, as are other signed formats like SAML assertions or = even a COSE Token (if it=E2=80=99s encoded to HTTP friendliness).=20 >=20 > My recommendation: >=20 > Remove the erroneous requirement text from section 5 and restore to = previous version. >=20 > Amend the text in section 6 from: >=20 > To > simplify the subsequent description we assume in the PoP = architecture > that the token itself is digitally signed by the authorization = server > and therefore cannot be modified. >=20 >=20 > To: >=20 > In all such cases, the token remains opaque to the client. To > simplify the subsequent example and description we assume in the = PoP architecture > that the token itself cannot be modified by the client, either due = to > cryptographic protection (such as signature or encryption) or use = of=20 > a reference value with sufficient entropy and associated secure = lookup. > These are characteristics shared with bearer tokens and more = information > on best practices can be found in [[RFC6819]] and in the security=20= > considerations section of [[RFC6750]].=20 >=20 >=20 > =E2=80=94 Justin >=20 >> On Nov 25, 2015, at 3:39 PM, Kathleen Moriarty = > wrote: >>=20 >> Hi, >>=20 >> Sent from my iPhone >>=20 >> On Nov 25, 2015, at 3:20 PM, John Bradley > wrote: >>=20 >>> Tokens are signed or the information is otherwise integrity = protected between the AS and the RS. =20 >>>=20 >>> I suspect Kathleen is concerned about the key getting modified in = transit. =20 >>> That needs to be protected against, but there is more than one way = to do that. >>=20 >> Phil is correct. I was looking for consistency between the sections = since they related to each other. If there is a security risk or = consideration, that needs to be explicitly called out as a concern such = as a key being modified in transit. If there are options to protect = against that, those would ideally be required or would have warnings. >>>=20 >>> So sending the public key in a unsigned JWT access token would be = immensely stupid, not just for PoP but for scopes and everything else. >>=20 >> Good, easy to require then. >>=20 >> Thanks, >> Kathleen=20 >>>=20 >>> In OAuth 2 all tokens need to be integrity protected between the AS = and RS. =20 >>> That can be via signature, by having a reference with sufficient = entropy and secure introspection or database lookup. >>>=20 >>> I think that is a OAuth 2 security consideration. We are adding a = additional confirmation claim to the existing information that needs to = be protected the same as the rest. >>>=20 >>> John B. >>>=20 >>>=20 >>>> On Nov 25, 2015, at 4:38 PM, Phil Hunt > wrote: >>>>=20 >>>> >>>> If there is agreement that tokens are opaque then the requirement = that tokens be signed must be removed from the threat mitigation = requirements.=20 >>>>=20 >>>> And the paragraph in sec 5 that brian was concerned about be = restored.=20 >>>>=20 >>>> Phil >>>>=20 >>>> On Nov 25, 2015, at 11:24, Justin Richer > wrote: >>>>=20 >>>>> It is still end to end authentication with opaque tokens =E2=80=94 = since all OAuth tokens, including PoP tokens, have always been intended = to be opaque to the client. That hasn=E2=80=99t changed and that isn=E2=80= =99t the intent of this document. If that=E2=80=99s how people are = reading it then we need to pull it back and rewrite it so that=E2=80=99s = not the case. >>>>>=20 >>>>> The client gets a token that has two parts: the token and the key. = The token is analogous to the access_token we have today and would come = out of the server in the same field. The key is handed to the client = alongside the token or registered by the client during the token = request. Either way there=E2=80=99s an association between the two but = it=E2=80=99s not the same association as a public/private keypair.=20 >>>>>=20 >>>>> It=E2=80=99s possible to sign the token itself, but the client = doesn=E2=80=99t care. It sends the token and signs the HTTP request to = the RS whether the token is signed, unsigned, hex blob, encrypted, or = anything else. The same series of options are available as with bearer = tokens. PoP tokens have never, ever been intended to be anything but = opaque to the client. >>>>>=20 >>>>> The token can=E2=80=99t be opaque to the RS, which has to figure = out what key to use to check the message signature. But we=E2=80=99ve = got options there, like the embedded key in a JWT from Mike=E2=80=99s = draft, or doing introspection to get the key (from an extension that = hasn=E2=80=99t been written yet), or simply looking it up in the same = database because the RS and the AS are in the same box. Does this = structure/service/database choice sound familiar? It should, it=E2=80=99s = the same as bearer tokens. This is also how the RS gets information like = which scopes are associated with the token, if it=E2=80=99s expired, and = all that.=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> So here=E2=80=99s how I see it going on the wire: >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> (I just wrote this up so there are probably holes. Here=E2=80=99s = the source if anyone wants to tweak it: = http://www.websequencediagrams.com/?lz=3DcGFydGljaXBhbnQgQ2xpZW50IGFzIEMKA= AwMUmVzb3VyY2UgT3duZXIgYXMgUk8AFA1BdXRob3JpemF0aW9uIFNlcnYAIQZBUwA7DVByb3R= lY3RlZABICmFzIFJTCgoKClJPLS0 = -QzogR28gZ2V0IG15IHIAbwcKQy0tPlJPOiBSZWRpcmV= jdCB0byBBUy9BRQAvBkFTOiBMb2cgaW4sIGEAgQIHZSBjAIFHBQpBUwAqEwAVBwBrCEhhbmQAK= QcAPAUgZ3JhbnQKCmFsdCBzAIFGBnN1cHBsaWVkIGtleQpDAG4GVG9rZW4gcmVxdWVzdCAoADA= FKQpBUwCBDAZnZW5lcmF0ZSB0ACIFYW4ANwUva2V5cGFpcgAiBUMAPAgmIEsAEAtlbHMAgTcIA= E8pICYga2V5AGYYLCBhc3NvY2lhdGUgd2l0aACBQQUAcBIKZW5kCgpDLT5SUzogUgCBUQdpbmN= sdWRpbmcAgT4Lc2lnbmVkAEEKAIIkBnRydWN0dXJlZACBbQYKUlMARAZjaGVjawCCAAdzaWduY= XR1cmUgLyBkZWNyeXB0AB8PUGFycwCCLgcAOQlVbnBhY2sAgncFAIIYBWludHJvc3BlY3RpbwB= iBkFTOiBzZW4AdAcgKG5vdABiCikgdG8AJQ9BAIEVBwAvBWtleSAocHVibGljIG9yIHNoYXJlZ= CkAgwIGZGF0YWJhc2UAgUUJbG9vayB1cABhCGxvY2FsLwAtBiBEQikAHQthAIQoBgCCUAUAgX4= OAIQsCACCBAp1c2luZwCEWAUAGw9pZ2h0cwCDNQoAgm4HAIJbBgCCXQVDOiByZXR1cm4AhicJ&= s=3Dmodern-blue ) >>>>>=20 >>>>> The client is oblivious to the token just like always. This is = intentional. The RS has the same options to figure out how to process = the token. >>>>>=20 >>>>> =E2=80=94 Justin >>>>>=20 >>>>>> On Nov 25, 2015, at 2:03 PM, Phil Hunt > wrote: >>>>>>=20 >>>>>> Folks,=20 >>>>>>=20 >>>>>> >>>>>> I did not want to go here either. :-) >>>>>>=20 >>>>>> I don=E2=80=99t read sec 6 as examples. I believe this may stem = from the pop-architecture documents having a dual role as both = =E2=80=9Carchitecture=E2=80=9D and =E2=80=9Cuse-case=E2=80=9D. Maybe we = should clarify the purpose of the document? >>>>>>=20 >>>>>> I believe section 6 is talking about threat mitigation = assumptions based on the examples that need to be implemented. I am = assuming these are requirements that the other specifications SHOULD = implement. >>>>>>=20 >>>>>> >>>>>> I do not believe we have discussed Opaque PoP tokens and any = inherent risks because the client is not or is unable to validate the = authenticity of the token. Does this introduce the possibility of a = MITM attack where a client can be convinced to sign requests for an = attacker? >>>>>>=20 >>>>>> If we want to include opaque PoP, I think we need to take a pause = and consider / discuss any threats here. >>>>>>=20 >>>>>> I find the desire for opaque PoP tokens to be a bit = contradictory. If we=E2=80=99re saying we don=E2=80=99t want to trust = TLS alone (e.g. because of load-balancer termination), why would we then = say, but we are perfectly willing to accept it worked for the OAuth AS = exchanges? Maybe I was very wrong here, but my assumption all along is = that for PoP we=E2=80=99re talking about end-to-end authentication of = all parties except in the case of 3.3 where we simply want to protect an = access token over a non-TLS HTTP connection. >>>>>>=20 >>>>>>=20 >>>>>> Phil >>>>>>=20 >>>>>> @independentid >>>>>> www.independentid.com = phil.hunt@oracle.com = >>>>>>> On Nov 25, 2015, at 10:48 AM, Brian Campbell = > wrote: >>>>>>>=20 >>>>>>> While I can't say I disagree with the deeper existential = questions about the draft that Justin raises, I was trying not to go = there and rather just point out concerns with the newly added text.=20 >>>>>>>=20 >>>>>>> The text Phil cites from Sec 6 doesn't say the client must be = able to parse and verify the token. It's an assumption to simplify the = examples that follow and still the token is opaque to the client. I = reread the whole draft (reluctantly) and there's nothing that says the = token has to be non-opaque to the client. And it does talk about = reference style tokens and encrypted tokens, both of which rely on the = opaqueness to the client.=20 >>>>>>>=20 >>>>>>> On Wed, Nov 25, 2015 at 11:27 AM, Justin Richer > wrote: >>>>>>> Right, I read that as text for describing the examples and not = for describing requirements. >>>>>>>=20 >>>>>>> The token itself doesn=E2=80=99t have to be signed at all. >>>>>>>=20 >>>>>>> =E2=80=94 Justin >>>>>>>=20 >>>>>>>> On Nov 25, 2015, at 1:05 PM, Phil Hunt > wrote: >>>>>>>>=20 >>>>>>>> Ok. Well this was requested by Kathleen because of this = paragraph in Sec 6.=E2=80=A6 >>>>>>>>=20 >>>>>>>> To simplify the subsequent description we assume in the PoP = architecture >>>>>>>> that the token itself is digitally signed by the = authorization server >>>>>>>> and therefore cannot be modified. >>>>>>>>=20 >>>>>>>> Please=20 >>>>>>>> Phil >>>>>>>>=20 >>>>>>>> @independentid >>>>>>>> www.independentid.com = phil.hunt@oracle.com = >>>>>>>>> On Nov 25, 2015, at 9:33 AM, Justin Richer > wrote: >>>>>>>>>=20 >>>>>>>>> The token doesn=E2=80=99t have to be signed and the client = doesn=E2=80=99t have to verify the signature on the token. That=E2=80=99s = not PoP. The request has to be signed in a way that includes the token. = The token itself can still be opaque. The *key* material can=E2=80=99t = be opaque to the client, but the *token* material still is. >>>>>>>>>=20 >>>>>>>>> I agree with Brian that this statement is misleading. >>>>>>>>>=20 >>>>>>>>> The examples use a signed token but that is absolutely not a = requirement. Maybe the examples shouldn=E2=80=99t all use one style. >>>>>>>>>=20 >>>>>>>>> What=E2=80=99s most difficult about this particular spec is = that it=E2=80=99s very hand-wavy, saying =E2=80=9Cthis is kinda a thing = that kinda works like this=E2=80=9D without saying how to actually do = it. I=E2=80=99m honestly not sure it=E2=80=99s worth publishing as an = RFC in its own right but I=E2=80=99m not going to stand in its way. >>>>>>>>>=20 >>>>>>>>> =E2=80=94 Justin >>>>>>>>>=20 >>>>>>>>>> On Nov 25, 2015, at 12:14 PM, Brian Campbell = > wrote: >>>>>>>>>>=20 >>>>>>>>>> Where does it say that?=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> On Wed, Nov 25, 2015 at 8:44 AM, Phil Hunt = > wrote: >>>>>>>>>> Except that later on we require the token be signed and the = client verify that signed token. IOW mutual pop.=20 >>>>>>>>>>=20 >>>>>>>>>> Phil >>>>>>>>>>=20 >>>>>>>>>> On Nov 25, 2015, at 07:30, Brian Campbell = > wrote: >>>>>>>>>>=20 >>>>>>>>>>> Looking at the diff I noticed the following new text, which = seems to conflate bearer/PoP and opaqueness to the client. A client = demonstrating proof-of-possession of some key is orthogonal to the = client being able to parse and understand the access token itself.=20 >>>>>>>>>>> =20 >>>>>>>>>>> "In contrast to bearer tokens [RFC6750] which call for = tokens that are opaque to OAuth 2.0 clients, this specification defines = the requirements for proof-of-possession ("PoP") tokens that may be = parsed and verified by OAuth 2.0 clients and relying parties." >>>>>>>>>>>=20 >>>>>>>>>>> On Tue, Nov 24, 2015 at 1:07 PM, Phil Hunt = > wrote: >>>>>>>>>>> This draft addresses review comments from Kathleen and Erik = raised since the last draft. >>>>>>>>>>>=20 >>>>>>>>>>> It may not include some of the discussion from = yesterday/today. I will add that as the group decides. >>>>>>>>>>>=20 >>>>>>>>>>> Cheers, >>>>>>>>>>>=20 >>>>>>>>>>> Phil >>>>>>>>>>>=20 >>>>>>>>>>> @independentid >>>>>>>>>>> www.independentid.com >>>>>>>>>>> phil.hunt@oracle.com >>>>>>>>>>>=20 >>>>>>>>>>> > On Nov 24, 2015, at 12:05 PM, internet-drafts@ietf.org = wrote: >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > A New Internet-Draft is available from the on-line = Internet-Drafts directories. >>>>>>>>>>> > This draft is a work item of the Web Authorization = Protocol Working Group of the IETF. >>>>>>>>>>> > >>>>>>>>>>> > Title : OAuth 2.0 Proof-of-Possession = (PoP) Security Architecture >>>>>>>>>>> > Authors : Phil Hunt >>>>>>>>>>> > Justin Richer >>>>>>>>>>> > William Mills >>>>>>>>>>> > Prateek Mishra >>>>>>>>>>> > Hannes Tschofenig >>>>>>>>>>> > Filename : = draft-ietf-oauth-pop-architecture-06.txt >>>>>>>>>>> > Pages : 23 >>>>>>>>>>> > Date : 2015-11-24 >>>>>>>>>>> > >>>>>>>>>>> > Abstract: >>>>>>>>>>> > The OAuth 2.0 bearer token specification, as defined in = RFC 6750, >>>>>>>>>>> > allows any party in possession of a bearer token (a = "bearer") to get >>>>>>>>>>> > access to the associated resources (without = demonstrating possession >>>>>>>>>>> > of a cryptographic key). To prevent misuse, bearer = tokens must be >>>>>>>>>>> > protected from disclosure in transit and at rest. >>>>>>>>>>> > >>>>>>>>>>> > Some scenarios demand additional security protection = whereby a client >>>>>>>>>>> > needs to demonstrate possession of cryptographic keying = material when >>>>>>>>>>> > accessing a protected resource. This document motivates = the >>>>>>>>>>> > development of the OAuth 2.0 proof-of-possession = security mechanism. >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > The IETF datatracker status page for this draft is: >>>>>>>>>>> > = https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architecture/ = >>>>>>>>>>> > >>>>>>>>>>> > There's also a htmlized version available at: >>>>>>>>>>> > = https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-06 = >>>>>>>>>>> > >>>>>>>>>>> > A diff from the previous version is available at: >>>>>>>>>>> > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-pop-architecture-06 = = >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > 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 = >>>>>>>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> OAuth mailing list >>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> --=20 >>>>>>>>>>> =09 >>>>>>>>>>> Brian Campbell >>>>>>>>>>> Distinguished Engineer >>>>>>>>>>> Ping Identity >>>>>>>>>>> @ bcampbell@pingidentity.com = >>>>>>>>>>> +1 720.317.2061 >>>>>>>>>>> @pingidentity >>>>>>>>>>> Connect with us! >>>>>>>>>>> = >>>>>>>>>>> = = = = = = = = >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> --=20 >>>>>>>>>> =09 >>>>>>>>>> Brian Campbell >>>>>>>>>> Distinguished Engineer >>>>>>>>>> Ping Identity >>>>>>>>>> @ bcampbell@pingidentity.com = >>>>>>>>>> +1 720.317.2061 >>>>>>>>>> @pingidentity >>>>>>>>>> Connect with us! >>>>>>>>>> = >>>>>>>>>> = = = = = = = = _____________________________________= __________ >>>>>>>>>> OAuth mailing list >>>>>>>>>> OAuth@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> --=20 >>>>>>> =09 >>>>>>> Brian Campbell >>>>>>> Distinguished Engineer >>>>>>> Ping Identity >>>>>>> @ bcampbell@pingidentity.com = >>>>>>> +1 720.317.2061 >>>>>>> @pingidentity >>>>>>> Connect with us! >>>>>>> >>>>>>> = = = = = = = = >>>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth = >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth = >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 --Apple-Mail=_6F82A26C-E048-476D-9B61-8D843D5A84AB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I am fine with that, however saying integrity protected, may = be better than signed.  May people will argue that HMAC or = encryption with sender verification is not signature.
However they are perfectly valid.


On Nov 25, 2015, at 5:53 PM, = Justin Richer <jricher@mit.edu> wrote:

The = requirement is not that signed JWTs be used, it=E2=80=99s that unsigned = JWTs not be used on their own. Reference tokens and encrypted JWTs are = also valid, as are other signed formats like SAML assertions or even a = COSE Token (if it=E2=80=99s encoded to HTTP friendliness). 

My = recommendation:

Remove the erroneous requirement text from section 5 and = restore to previous version.

Amend the text in section 6 = from:

   To
   simplify the subsequent description we assume in the PoP architecture

   that the token itself is digitally =
signed by the authorization server
   and therefore cannot be modified.


To:

   In all such cases, the token =
remains opaque to the client. To
   simplify the subsequent example and description we assume in the PoP =
architecture
   that the token itself cannot =
be modified by the client, either due to
   =
cryptographic protection (such as signature or encryption) or use =
of 
   a reference value with =
sufficient entropy and associated secure lookup.
   These are characteristics shared with bearer tokens =
and more information
   on best practices =
can be found in [[RFC6819]] and in the security 
   considerations section of [[RFC6750]].


 =E2=80=94 Justin

On Nov 25, 2015, at 3:39 PM, Kathleen = Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:

Hi,

Sent from my iPhone

On Nov 25, 2015, at 3:20 PM, John Bradley <ve7jtb@ve7jtb.com> = wrote:

Tokens are signed or the information is = otherwise integrity protected between the AS and the RS.  

I suspect Kathleen is = concerned about the key getting modified in transit. =   
That needs to be protected against, = but there is more than one way to do that.

Phil is correct.  I was looking for = consistency between the sections since they related to each other. =  If there is a security risk or consideration, that needs to be = explicitly called out as a concern such as a key being modified in = transit.  If there are options to protect against that, those would = ideally be required or would have warnings.

So sending the public key in a unsigned = JWT access token would be immensely stupid,  not just for PoP but = for scopes and everything else.

Good, easy to require then.

Thanks,
Kathleen 

In OAuth 2 all tokens need to be integrity protected between = the AS and RS.  
That can be via signature, =  by having a reference with sufficient entropy and secure = introspection or database lookup.

I think that is a OAuth 2 security = consideration.   We are adding a additional confirmation claim to = the existing information that needs to be protected the same as the = rest.

John = B.


On Nov 25, 2015, at 4:38 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

<editors hat>
If = there is agreement that tokens are opaque then the requirement that = tokens be signed must be removed from the threat mitigation = requirements. 

And the paragraph in sec 5 that brian was concerned about be = restored. 

Phil

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

It = is still end to end authentication with opaque tokens =E2=80=94 since = all OAuth tokens, including PoP tokens, have always been intended to be = opaque to the client. That hasn=E2=80=99t changed and that isn=E2=80=99t = the intent of this document. If that=E2=80=99s how people are reading it = then we need to pull it back and rewrite it so that=E2=80=99s not the = case.

The client = gets a token that has two parts: the token and the key. The token is = analogous to the access_token we have today and would come out of the = server in the same field. The key is handed to the client alongside the = token or registered by the client during the token request. Either way = there=E2=80=99s an association between the two but it=E2=80=99s not the = same association as a public/private keypair. 

It=E2=80=99s possible to = sign the token itself, but the client doesn=E2=80=99t care. It sends the = token and signs the HTTP request to the RS whether the token is signed, = unsigned, hex blob, encrypted, or anything else. The same series of = options are available as with bearer tokens. PoP tokens have never, ever = been intended to be anything but opaque to the client.

The token can=E2=80=99t = be opaque to the RS, which has to figure out what key to use to check = the message signature. But we=E2=80=99ve got options there, like the = embedded key in a JWT from Mike=E2=80=99s draft, or doing introspection = to get the key (from an extension that hasn=E2=80=99t been written yet), = or simply looking it up in the same database because the RS and the AS = are in the same box. Does this structure/service/database choice sound = familiar? It should, it=E2=80=99s the same as bearer tokens. This is = also how the RS gets information like which scopes are associated with = the token, if it=E2=80=99s expired, and all that. 




So here=E2=80=99s how I see it going on the wire:



3D"http://www.websequencediagrams.com/cgi-bin/cdraw?lz=3DcGFydGljaXBhb=



(I just wrote this up so there are = probably holes. Here=E2=80=99s the source if anyone wants to tweak = it: http://www.websequencediagrams.com/?lz=3DcGFydGljaXBhbnQgQ2xpZW= 50IGFzIEMKAAwMUmVzb3VyY2UgT3duZXIgYXMgUk8AFA1BdXRob3JpemF0aW9uIFNlcnYAIQZB= UwA7DVByb3RlY3RlZABICmFzIFJTCgoKClJPLS0-QzogR28gZ2V0IG15IHIAbwcKQy0tPl= JPOiBSZWRpcmVjdCB0byBBUy9BRQAvBkFTOiBMb2cgaW4sIGEAgQIHZSBjAIFHBQpBUwAqEwAV= BwBrCEhhbmQAKQcAPAUgZ3JhbnQKCmFsdCBzAIFGBnN1cHBsaWVkIGtleQpDAG4GVG9rZW4gcm= VxdWVzdCAoADAFKQpBUwCBDAZnZW5lcmF0ZSB0ACIFYW4ANwUva2V5cGFpcgAiBUMAPAgmIEsA= EAtlbHMAgTcIAE8pICYga2V5AGYYLCBhc3NvY2lhdGUgd2l0aACBQQUAcBIKZW5kCgpDLT5SUz= ogUgCBUQdpbmNsdWRpbmcAgT4Lc2lnbmVkAEEKAIIkBnRydWN0dXJlZACBbQYKUlMARAZjaGVj= awCCAAdzaWduYXR1cmUgLyBkZWNyeXB0AB8PUGFycwCCLgcAOQlVbnBhY2sAgncFAIIYBWludH= Jvc3BlY3RpbwBiBkFTOiBzZW4AdAcgKG5vdABiCikgdG8AJQ9BAIEVBwAvBWtleSAocHVibGlj= IG9yIHNoYXJlZCkAgwIGZGF0YWJhc2UAgUUJbG9vayB1cABhCGxvY2FsLwAtBiBEQikAHQthAI= QoBgCCUAUAgX4OAIQsCACCBAp1c2luZwCEWAUAGw9pZ2h0cwCDNQoAgm4HAIJbBgCCXQVDOiBy= ZXR1cm4AhicJ&s=3Dmodern-blue )

The client is oblivious to the token = just like always. This is intentional. The RS has the same options to = figure out how to process the token.

 =E2=80=94 Justin

On Nov 25, 2015, at 2:03 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

Folks, 

<editor = hat>
I did not want to go here either. = :-)

I don=E2=80=99= t read sec 6 as examples.  I believe this may stem from the = pop-architecture documents having a dual role as both =E2=80=9Carchitectur= e=E2=80=9D and =E2=80=9Cuse-case=E2=80=9D.  Maybe we should clarify = the purpose of the document?

I believe section 6 is talking about = threat mitigation assumptions based on the examples that need to be = implemented.  I am assuming these are requirements that the other = specifications SHOULD implement.

<personal hat>
I do not believe we have discussed Opaque PoP tokens and any = inherent risks because the client is not or is unable to validate the = authenticity of the token.  Does this introduce the possibility of = a MITM attack where a client can be convinced to sign requests for an = attacker?

If = we want to include opaque PoP, I think we need to take a pause and = consider / discuss any threats here.

I find the desire for opaque PoP tokens = to be a bit contradictory. If we=E2=80=99re saying we don=E2=80=99t want = to trust TLS alone (e.g. because of load-balancer termination), why = would we then say, but we are perfectly willing to accept it worked for = the OAuth AS exchanges?  Maybe I was very wrong here, but my = assumption all along is that for PoP we=E2=80=99re talking about = end-to-end authentication of all parties except in the case of 3.3 where = we simply want to protect an access token over a non-TLS HTTP = connection.



On Nov 25, 2015, at 10:48 AM, Brian Campbell <bcampbell@pingidentity.com> wrote:

While I can't say I disagree = with the deeper existential questions about the draft that Justin = raises, I was trying not to go there and rather just point out concerns = with the newly added text.

The text = Phil cites from Sec 6 doesn't say the client must be able to parse and = verify the token. It's an assumption to simplify the examples that = follow and still the token is opaque to the client. I reread the whole = draft (reluctantly) and there's nothing that says the token has to be = non-opaque to the client. And it does talk about reference style tokens = and encrypted tokens, both of which rely on the opaqueness to the = client.

On Wed, Nov 25, 2015 at 11:27 AM, = Justin Richer <jricher@mit.edu> wrote:
Right, I read that as text for describing the examples and = not for describing requirements.

The token itself doesn=E2=80=99t have to be signed at = all.

 =E2=80=94 = Justin

On Nov 25, 2015, at 1:05 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

Ok. Well this was = requested by Kathleen because of this paragraph in Sec 6.=E2=80=A6

   =
To simplify the subsequent description we assume in the PoP =
architecture
   =
that the token itself is digitally signed by the authorization server

   and therefore cannot be modified.

Please 

On Nov 25, 2015, at 9:33 AM, Justin Richer <jricher@mit.edu> wrote:

The token = doesn=E2=80=99t have to be signed and the client doesn=E2=80=99t have to = verify the signature on the token. That=E2=80=99s not PoP. The request = has to be signed in a way that includes the token. The token itself can = still be opaque. The *key* material can=E2=80=99t be opaque to the = client, but the *token* material still is.

I agree with Brian that this statement = is misleading.

The examples use a signed token but that is absolutely not a = requirement. Maybe the examples shouldn=E2=80=99t all use one = style.

What=E2=80= =99s most difficult about this particular spec is that it=E2=80=99s very = hand-wavy, saying =E2=80=9Cthis is kinda a thing that kinda works like = this=E2=80=9D without saying how to actually do it. I=E2=80=99m honestly = not sure it=E2=80=99s worth publishing as an RFC in its own right but = I=E2=80=99m not going to stand in its way.

 =E2=80=94 Justin

On Nov 25, 2015, at 12:14 PM, Brian Campbell = <bcampbell@pingidentity.com> wrote:

Where does it say = that?



On Wed, = Nov 25, 2015 at 8:44 AM, Phil Hunt <phil.hunt@oracle.com> wrote:
Except that later on we require the token be = signed and the client verify that signed token. IOW mutual = pop. 

Phil

On Nov 25, 2015, at 07:30, = Brian Campbell <bcampbell@pingidentity.com> = wrote:

Looking at the = diff I noticed the following new text, which seems to conflate = bearer/PoP and opaqueness to the client. A client demonstrating = proof-of-possession of some key is orthogonal to the client being able = to parse and understand the access token itself.
 
"In contrast to bearer tokens [RFC6750] which call for tokens = that are opaque to OAuth 2.0 clients, this specification defines the = requirements for proof-of-possession ("PoP") tokens that may be parsed = and verified by OAuth 2.0 clients and relying parties."

On Tue, Nov 24, 2015 at 1:07 PM, Phil Hunt <phil.hunt@oracle.com> = wrote:
This draft = addresses review comments from Kathleen and Erik raised since the last = draft.

It may not include some of the discussion from yesterday/today.  I = will add that as the group decides.

Cheers,

Phil

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

> On Nov 24, 2015, at 12:05 PM, internet-drafts@ietf.org wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts = directories.
> This draft is a work item of the Web Authorization Protocol Working = Group of the IETF.
>
>        Title          =  : OAuth 2.0 Proof-of-Possession (PoP) Security Architecture
>        Authors        =  : Phil Hunt
>                  =         Justin Richer
>                  =         William Mills
>                  =         Prateek Mishra
>                  =         Hannes Tschofenig
>       Filename        : = draft-ietf-oauth-pop-architecture-06.txt
>       Pages          =  : 23
>       Date          =   : 2015-11-24
>
> Abstract:
>   The OAuth 2.0 bearer token specification, as defined in = RFC 6750,
>   allows any party in possession of a bearer token (a = "bearer") to get
>   access to the associated resources (without = demonstrating possession
>   of a cryptographic key).  To prevent misuse, = bearer tokens must be
>   protected from disclosure in transit and at rest.
>
>   Some scenarios demand additional security protection = whereby a client
>   needs to demonstrate possession of cryptographic keying = material when
>   accessing a protected resource.  This document = motivates the
>   development of the OAuth 2.0 proof-of-possession = security mechanism.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architect= ure/
>
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-0= 6
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-pop-archit= ecture-06
>
>
> 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



--
=09 3D"Ping=20
Brian Campbell
Distinguished Engineer
Ping = Identity
@ bcampbell@pingidentity.com
3D"phone" +1 720.317.2061
3D"twitter" @pingidentity
Connect with = us!
3D"pingidentity.com"
=
3D"pingidentity.com"
= 3D"twitter 3D"twitter 3D"youtube 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard= 3D"rss


--
=09 3D"Ping=20
Brian Campbell
Distinguished Engineer
Ping = Identity
@ bcampbell@pingidentity.com
3D"phone" +1 720.317.2061
3D"twitter" @pingidentity
Connect with = us!
3D"pingidentity.com"
=
3D"pingidentity.com"
= 3D"twitter 3D"twitter 3D"youtube 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard= 3D"rss
_______________________________________________
OAuth = mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth






--
=09 3D"Ping=20
Brian Campbell
Distinguished Engineer
Ping Identity
@ bcampbell@pingidentity.com
3D"phone" +1 720.317.2061
3D"twitter" @pingidentity
Connect with = us!
3D"pingidentity.com"
=
3D"pingidentity.com"
= 3D"twitter 3D"twitter 3D"youtube 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard 3D"rss


________________________________= _______________
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


= --Apple-Mail=_6F82A26C-E048-476D-9B61-8D843D5A84AB-- From nobody Wed Nov 25 13:42:13 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D13021B30D4 for ; Wed, 25 Nov 2015 13:42:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zhY-mYPjYGQe for ; Wed, 25 Nov 2015 13:42:10 -0800 (PST) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00BDE1B30D3 for ; Wed, 25 Nov 2015 13:42:09 -0800 (PST) Received: by qgec40 with SMTP id c40so42060332qge.2 for ; Wed, 25 Nov 2015 13:42:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=KcP1q1jIQMlbCLClAvBHLKoriNIQNa3Op9wyvvojgnU=; b=ZbyEYnjSek6czqaINrxQCdBlkd4hP6rNk+w83W7/dH6I5hts5+I7SucSlj1oy9YXC7 RfegDo+P4oOl/DOtqxWKmaj7eriqVQAChcgsilBQ4g5JNZMro/b5LjWSsZ6JCf0LjWBQ ufHy9r5cr6ODsXNidP3ASJoe1zH5v6CrsZzdjK7xSnQ05/k687LTuVV801mPwjv8J+Hn RIzFU4Y0y3rmQVDx9BClaPuahZQ/vWDg3In4GrcDp4PMPnLtuIWWRP9xfWmfuw4TxMwo tPQ6L2iDcqOm9svF4mYH54o1B37s45jFRjGU2oEwDdfQYoPQFbjPHfcrM8Z3zzA1CV6b vSEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=KcP1q1jIQMlbCLClAvBHLKoriNIQNa3Op9wyvvojgnU=; b=ZDmI6kIeURMw0S6vMqtMB9HuEIwu0T7eAqCiUyaVI39Fs5C5yOcHiab7dZ2eMfth1L tN6keQOPKiQL0BjtCQtzpwhZGjFIfHamgTw8Jiy0CDiHrsdjuwyaaOIdbNoQIxZwBOWi MwXNRo/H7nZ/+Aq6mtG5pR9DtlxRubGpWawlPJ3XZqcEFj/ZDDK17Dg2UNrVzI4LDY2G CuVSHxCwFzmlEZRXGiMHnNs1Eh0lY2KrCI8xeoTqVfRr3Sy7c19+tSOWGZohhjzSbrTH l6ID9BrDc5O25UaxvLWiAZRPMb5UW6J1L7jETYRkMLwbynIvCkMxQgDJjZvo/ouIpbU/ 2CWQ== X-Gm-Message-State: ALoCoQm3cdobsxoMhGVwiqHw8thW/AIhTQLu5mfd3huqXWoUPSCWteFyWaLRtyLjPqjTsJ6Uk20c X-Received: by 10.140.29.7 with SMTP id a7mr5074141qga.6.1448487728918; Wed, 25 Nov 2015 13:42:08 -0800 (PST) Received: from [192.168.1.216] ([191.115.122.254]) by smtp.gmail.com with ESMTPSA id x129sm6041782qhc.33.2015.11.25.13.42.01 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 25 Nov 2015 13:42:07 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: John Bradley In-Reply-To: Date: Wed, 25 Nov 2015 18:41:50 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: <4AF8FE9C-3484-410B-B52F-C1F9706B18A5@ve7jtb.com> References: To: Michael Jones X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-proof-of-possession X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2015 21:42:13 -0000 I prefer the new wording. However the last part could be clearer. > use be implemented by recipients. Or perhaps the blunter =E2=80=9CRecipients only understanding bearer = tokens may accept JWT containing =E2=80=9Ccnf=E2=80=9D elements if all = the other required claims are valid. It is important for security to = audience restrict tokens using the JWT =E2=80=9Caud claim. The = =E2=80=9Ccnf=E2=80=9D claim MUST NOT be used as a pseudo audience = restriction.=E2=80=9D Looking at the comments, I get the feeling that some people might think = that cnf may restrict what endpoints can receive the token (because of = the key distribution) it only allows endpoints that should receive the = token to reject ones that come from entities who don=E2=80=99t possess = the correct confirmation. John B. > On Nov 25, 2015, at 12:25 AM, Mike Jones = wrote: >=20 > Rather than elaborating, having looked at the text we're discussing = again, I'm going to counter-propose that we instead simplify - sticking = only to the point that the paragraph is intending to get across. Would = it work for you to simplify the current text: >=20 > "A recipient might not understand the cnf claim, in which case it = will typically be ignored. Unless this is acceptable behavior, = applications that need the proof-of-possession keys communicated with it = to be understood and processed must require that the parts of this = specification that they use be implemented." >=20 > to this simpler text? >=20 > "A recipient might not understand the cnf claim. Applications that = need the proof-of-possession keys communicated with it to be understood = and processed must require that the parts of this specification that = they use be implemented." >=20 > The "must ignore" topic is already addressed in the second paragraph = of 3.1 (and with exactly the semantics as the rest of JWT), and so = doesn't have to be re-raised here, as it currently is. Re-raising it is = clearly a point of distraction. >=20 > For what it's worth, I don't remember any DISCUSSes on this topic = (although it's possible that your memory is better than mine on this = point). >=20 > Best wishes, > -- Mike >=20 > -----Original Message----- > From: Kathleen Moriarty [mailto:kathleen.moriarty.ietf@gmail.com]=20 > Sent: Tuesday, November 24, 2015 7:14 PM > To: Mike Jones > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] AD review of = draft-ietf-oauth-proof-of-possession >=20 > On Tue, Nov 24, 2015 at 10:10 PM, Mike Jones = wrote: >> Fair question about the use of "typically". The reason it's there is = that this language in JWT [RFC 7519] Section 4 does permit applications = to require that JWTs with not-understood claims be rejected, rather than = ignored, even though that's not the default behavior: >>=20 >> The set of claims that a JWT must contain to be considered valid is >> context dependent and is outside the scope of this specification. >> Specific applications of JWTs will require implementations to >> understand and process some claims in particular ways. However, in >> the absence of such requirements, all claims that are not = understood >> by implementations MUST be ignored. >>=20 >> So when not understood, "cnf" would typically be ignored, but might = not be. >=20 > I find that confusing and am now thinking this came up in a discuss as = well during the review for 7519, didn't it? Can you elaborate int eh = security considerations section a bit more, otherwise this text appears = to be conflicting and even with what you intend, it's confusing for = implementers and will lead to issues with interoperability. >=20 > Thanks, > Kathleen >=20 >=20 >>=20 >> -- Mike >>=20 >> -----Original Message----- >> From: Kathleen Moriarty [mailto:kathleen.moriarty.ietf@gmail.com] >> Sent: Tuesday, November 24, 2015 6:41 PM >> To: Mike Jones >> Cc: oauth@ietf.org >> Subject: Re: [OAUTH-WG] AD review of=20 >> draft-ietf-oauth-proof-of-possession >>=20 >> Hi Mike, >>=20 >> Thanks for the quick turn-around. Just one more comment on my = comments. >>=20 >> On Tue, Nov 24, 2015 at 9:10 PM, Mike Jones = wrote: >>> Thanks for your review comments, Kathleen. Responses are inline = below... >>>=20 >>>> -----Original Message----- >>>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Kathleen=20= >>>> Moriarty >>>> Sent: Tuesday, November 24, 2015 9:44 AM >>>> To: oauth@ietf.org >>>> Subject: [OAUTH-WG] AD review of=20 >>>> draft-ietf-oauth-proof-of-possession >>>>=20 >>>> Hi, >>>>=20 >>>> Thank you all for your work on this draft! I just have a few = questions: >>>>=20 >>>> 1. Security considerations section says: >>>>=20 >>>> "All of the normal security issues, especially in relationship to >>>> comparing URIs and dealing with unrecognized values, that are >>>> discussed in JWT [JWT] also apply here." >>>>=20 >>>> I find that to be odd phrasing that would likely be picked up in=20 >>>> subsequent reviews. Please remove the word "normal" so that all of=20= >>>> the security issues discusses in JWT are included. Are there other=20= >>>> 'normal considerations in addition to those in JWT that need to be=20= >>>> listed? The phrasing reads as if that may the case and would be=20 >>>> better to include them all or pointers or change the phrasing. >>>=20 >>> You're right. I removed this awkward wording. >>>=20 >>>> 2. Also in the security considerations section, >>>>=20 >>>> "A recipient may not understand the newly introduced "cnf" claim = and >>>> may consequently treat it as a bearer token." >>>>=20 >>>> What is the proper handling requirement when an unknown claim is=20 >>>> present? Section 3.1 says: >>>> "When a recipient receives a "cnf" claim with a >>>> member that it does not understand, it MUST ignore that member." >>>>=20 >>>> Is this why it is treated as a bearer token rather than being=20 >>>> rejected? Is this really the action you want to see with cnf? Why=20= >>>> isn't there an error and a resend as a bearer token so that parties=20= >>>> understand (or have an opportunity to understand) that there were = issues? >>>>=20 >>>> Then the following text in the security section says: >>>> "While this is a >>>> legitimate concern, it is outside the scope of this = specification, >>>> since demonstration the possession of the key associated with the >>>> "cnf" claim is not covered by this specification. For more=20 >>>> details, >>>>=20 >>>> How is this outside of the scope of this draft? cnf is defined in=20= >>>> this draft, so handling should be covered in this draft. A pointer=20= >>>> to the POP architecture draft is not helpful as it is not defined=20= >>>> there, it's covered int his draft. Should this text just be = removed=20 >>>> and replaced with more explicit handling information int he body of = this draft? >>>=20 >>> Good catch. JWT [RFC 7519] Section 4 says that claims that are not = understood must be ignored unless otherwise specified by the = application. This allows new claims to be dynamically added without = breaking existing applications. For the same reason, I have = incorporated this language about understanding claims from 7519, but = having it be about understanding confirmation members. Ultimately, what = features must be implemented are always up to the application, just as = with JWT claims. >>=20 >> The new text in Section 3.1 looks good. I'm not sure why the word = "typically" appears int he new text of the security considerations = section though after reading the new text in 3.1. Wouldn't it just be = ignored since 3.1 now says: >>=20 >> "However, in the absence of such requirements, >> all confirmation members that are not understood by = implementations >> MUST be ignored." >>=20 >> Thanks, >> Kathleen >>=20 >>=20 >>>=20 >>>> Thanks! >>>>=20 >>>> -- >>>>=20 >>>> Best regards, >>>> Kathleen >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>> Thanks again, >>> -- Mike >>>=20 >>=20 >>=20 >>=20 >> -- >>=20 >> Best regards, >> Kathleen >=20 >=20 >=20 > --=20 >=20 > Best regards, > Kathleen > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Wed Nov 25 14:12:56 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2AE21B315D for ; Wed, 25 Nov 2015 14:12:55 -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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TRWKG546Gdh9 for ; Wed, 25 Nov 2015 14:12:53 -0800 (PST) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::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 B9A611B315C for ; Wed, 25 Nov 2015 14:12:52 -0800 (PST) Received: by wmec201 with SMTP id c201so88220590wme.1 for ; Wed, 25 Nov 2015 14:12:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=W2yL93v8VCUBFRnJICG7fxOVE/SgPDphcjt2qF9wiIE=; b=vjZcmkqCqR+VlMo80P2zy/JAAoDNYxMeni0yBJdukaNrLjhW3oe3KCqQhEFkKog31w GMEKFxZ7nsBi/ld961OCvf8+LlwvedSxgn2gboxBwSIZ70rZYBQpuzZxMgBbe3YOoXHt p559XZJwA/V0Yx0OBUzPOTiKKhnLB7A8rDNthOva0I4DoYywo2lR16lb66NKgIDeMmcx coG1jmxW/KRwLxJHG3bYWW8cszEHlDeatR20wA8a+iT75C3sOGzbem2D0X0QxqNWsydn hdH4innkblVhEzWTl7C34C9Q0u4FNO4QoiyNr9OtHyj14aVyUXqzHRSw9DsQbGCW29p9 kBvg== MIME-Version: 1.0 X-Received: by 10.194.179.71 with SMTP id de7mr44794493wjc.119.1448489570846; Wed, 25 Nov 2015 14:12:50 -0800 (PST) Received: by 10.28.52.130 with HTTP; Wed, 25 Nov 2015 14:12:50 -0800 (PST) In-Reply-To: <4AF8FE9C-3484-410B-B52F-C1F9706B18A5@ve7jtb.com> References: <4AF8FE9C-3484-410B-B52F-C1F9706B18A5@ve7jtb.com> Date: Wed, 25 Nov 2015 17:12:50 -0500 Message-ID: From: Kathleen Moriarty To: John Bradley Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-proof-of-possession X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2015 22:12:55 -0000 Thanks, John! On Wed, Nov 25, 2015 at 4:41 PM, John Bradley wrote: > I prefer the new wording. > > However the last part could be clearer. >> use be implemented by recipients. > > Or perhaps the blunter =E2=80=9CRecipients only understanding bearer toke= ns may accept JWT containing =E2=80=9Ccnf=E2=80=9D elements if all the othe= r required claims are valid. It is important for security to audience rest= rict tokens using the JWT =E2=80=9Caud claim. The =E2=80=9Ccnf=E2=80=9D cl= aim MUST NOT be used as a pseudo audience restriction.=E2=80=9D More explicit text like this is is more helpful in my opinion. Kathleen > > Looking at the comments, I get the feeling that some people might think t= hat cnf may restrict what endpoints can receive the token (because of the k= ey distribution) it only allows endpoints that should receive the token to= reject ones that come from entities who don=E2=80=99t possess the correct = confirmation. > > John B. > >> On Nov 25, 2015, at 12:25 AM, Mike Jones w= rote: >> >> Rather than elaborating, having looked at the text we're discussing agai= n, I'm going to counter-propose that we instead simplify - sticking only to= the point that the paragraph is intending to get across. Would it work fo= r you to simplify the current text: >> >> "A recipient might not understand the cnf claim, in which case it wil= l typically be ignored. Unless this is acceptable behavior, applications th= at need the proof-of-possession keys communicated with it to be understood = and processed must require that the parts of this specification that they u= se be implemented." >> >> to this simpler text? >> >> "A recipient might not understand the cnf claim. Applications that n= eed the proof-of-possession keys communicated with it to be understood and = processed must require that the parts of this specification that they use b= e implemented." >> >> The "must ignore" topic is already addressed in the second paragraph of = 3.1 (and with exactly the semantics as the rest of JWT), and so doesn't hav= e to be re-raised here, as it currently is. Re-raising it is clearly a poi= nt of distraction. >> >> For what it's worth, I don't remember any DISCUSSes on this topic (altho= ugh it's possible that your memory is better than mine on this point). >> >> Best wishes, >> -- Mike >> >> -----Original Message----- >> From: Kathleen Moriarty [mailto:kathleen.moriarty.ietf@gmail.com] >> Sent: Tuesday, November 24, 2015 7:14 PM >> To: Mike Jones >> Cc: oauth@ietf.org >> Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-proof-of-possessio= n >> >> On Tue, Nov 24, 2015 at 10:10 PM, Mike Jones wrote: >>> Fair question about the use of "typically". The reason it's there is t= hat this language in JWT [RFC 7519] Section 4 does permit applications to r= equire that JWTs with not-understood claims be rejected, rather than ignore= d, even though that's not the default behavior: >>> >>> The set of claims that a JWT must contain to be considered valid is >>> context dependent and is outside the scope of this specification. >>> Specific applications of JWTs will require implementations to >>> understand and process some claims in particular ways. However, in >>> the absence of such requirements, all claims that are not understood >>> by implementations MUST be ignored. >>> >>> So when not understood, "cnf" would typically be ignored, but might not= be. >> >> I find that confusing and am now thinking this came up in a discuss as w= ell during the review for 7519, didn't it? Can you elaborate int eh securi= ty considerations section a bit more, otherwise this text appears to be con= flicting and even with what you intend, it's confusing for implementers and= will lead to issues with interoperability. >> >> Thanks, >> Kathleen >> >> >>> >>> -- Mike >>> >>> -----Original Message----- >>> From: Kathleen Moriarty [mailto:kathleen.moriarty.ietf@gmail.com] >>> Sent: Tuesday, November 24, 2015 6:41 PM >>> To: Mike Jones >>> Cc: oauth@ietf.org >>> Subject: Re: [OAUTH-WG] AD review of >>> draft-ietf-oauth-proof-of-possession >>> >>> Hi Mike, >>> >>> Thanks for the quick turn-around. Just one more comment on my comments= . >>> >>> On Tue, Nov 24, 2015 at 9:10 PM, Mike Jones wrote: >>>> Thanks for your review comments, Kathleen. Responses are inline below= ... >>>> >>>>> -----Original Message----- >>>>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Kathleen >>>>> Moriarty >>>>> Sent: Tuesday, November 24, 2015 9:44 AM >>>>> To: oauth@ietf.org >>>>> Subject: [OAUTH-WG] AD review of >>>>> draft-ietf-oauth-proof-of-possession >>>>> >>>>> Hi, >>>>> >>>>> Thank you all for your work on this draft! I just have a few questio= ns: >>>>> >>>>> 1. Security considerations section says: >>>>> >>>>> "All of the normal security issues, especially in relationship to >>>>> comparing URIs and dealing with unrecognized values, that are >>>>> discussed in JWT [JWT] also apply here." >>>>> >>>>> I find that to be odd phrasing that would likely be picked up in >>>>> subsequent reviews. Please remove the word "normal" so that all of >>>>> the security issues discusses in JWT are included. Are there other >>>>> 'normal considerations in addition to those in JWT that need to be >>>>> listed? The phrasing reads as if that may the case and would be >>>>> better to include them all or pointers or change the phrasing. >>>> >>>> You're right. I removed this awkward wording. >>>> >>>>> 2. Also in the security considerations section, >>>>> >>>>> "A recipient may not understand the newly introduced "cnf" claim an= d >>>>> may consequently treat it as a bearer token." >>>>> >>>>> What is the proper handling requirement when an unknown claim is >>>>> present? Section 3.1 says: >>>>> "When a recipient receives a "cnf" claim with a >>>>> member that it does not understand, it MUST ignore that member." >>>>> >>>>> Is this why it is treated as a bearer token rather than being >>>>> rejected? Is this really the action you want to see with cnf? Why >>>>> isn't there an error and a resend as a bearer token so that parties >>>>> understand (or have an opportunity to understand) that there were iss= ues? >>>>> >>>>> Then the following text in the security section says: >>>>> "While this is a >>>>> legitimate concern, it is outside the scope of this specification, >>>>> since demonstration the possession of the key associated with the >>>>> "cnf" claim is not covered by this specification. For more >>>>> details, >>>>> >>>>> How is this outside of the scope of this draft? cnf is defined in >>>>> this draft, so handling should be covered in this draft. A pointer >>>>> to the POP architecture draft is not helpful as it is not defined >>>>> there, it's covered int his draft. Should this text just be removed >>>>> and replaced with more explicit handling information int he body of t= his draft? >>>> >>>> Good catch. JWT [RFC 7519] Section 4 says that claims that are not un= derstood must be ignored unless otherwise specified by the application. Th= is allows new claims to be dynamically added without breaking existing appl= ications. For the same reason, I have incorporated this language about und= erstanding claims from 7519, but having it be about understanding confirmat= ion members. Ultimately, what features must be implemented are always up t= o the application, just as with JWT claims. >>> >>> The new text in Section 3.1 looks good. I'm not sure why the word "typ= ically" appears int he new text of the security considerations section thou= gh after reading the new text in 3.1. Wouldn't it just be ignored since 3.= 1 now says: >>> >>> "However, in the absence of such requirements, >>> all confirmation members that are not understood by implementations >>> MUST be ignored." >>> >>> Thanks, >>> Kathleen >>> >>> >>>> >>>>> Thanks! >>>>> >>>>> -- >>>>> >>>>> Best regards, >>>>> Kathleen >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> Thanks again, >>>> -- Mike >>>> >>> >>> >>> >>> -- >>> >>> Best regards, >>> Kathleen >> >> >> >> -- >> >> Best regards, >> Kathleen >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > --=20 Best regards, Kathleen From nobody Wed Nov 25 14:19:44 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 376131A8BC5 for ; Wed, 25 Nov 2015 14:19:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JyLihEFbFzcM for ; Wed, 25 Nov 2015 14:19:33 -0800 (PST) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::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 35FBC1B317B for ; Wed, 25 Nov 2015 14:19:32 -0800 (PST) Received: by wmuu63 with SMTP id u63so18723wmu.0 for ; Wed, 25 Nov 2015 14:19:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/nhUQ+iNWZtg243c7UuRODGQJ/8ThIliDwdav0Bn/YI=; b=XjRvhfPuKoQlNQAAKeYgP1w8gJEGaWsyPvYBKMbUsgHXzAcFecTxByeSW4mw/ouef+ eXozZMssSiEUQVlHxu/HiDpacFwHLKwqVJkPYq2S1cJZYV5Ga6KviYPp0HpLyar/v8CF GqPt5kv+Om9G1cT/GUSobLicVlog+Vg20SjctNmg9MxseVIQb8QPnTXxn4du6ggs+AMG m4zMQ/3CemFLDgOtK2y3L5mh3rjnVUh3UtO+v+ztZ4sa461c6AlCLi1C9MYxjjfSOqjL Lm8NV8NBfnn70HoAXf1Wt8ND7R3c9KBwFxsSKszKi6DQXRO42Uuq1S7LP2ACA6mmn3NB x70A== MIME-Version: 1.0 X-Received: by 10.194.222.195 with SMTP id qo3mr3946555wjc.51.1448489970664; Wed, 25 Nov 2015 14:19:30 -0800 (PST) Received: by 10.28.52.130 with HTTP; Wed, 25 Nov 2015 14:19:30 -0800 (PST) In-Reply-To: <207E620F-97AA-4851-8776-2A7B1921D58A@ve7jtb.com> References: <20151124200512.20833.28463.idtracker@ietfa.amsl.com> <16FAD3AC-CFB8-46D5-A12E-436E902EA439@oracle.com> <6015EE15-1FEE-43DC-930C-68ACAEDC083E@oracle.com> <38555799-721C-4A2F-AAAA-24D9B69EB72E@mit.edu> <1AD1F44B-9837-4288-9997-5292F1DBE30E@oracle.com> <9E20E73C-AC35-4E03-A011-119A32CD0BF1@ve7jtb.com> <7431079B-818C-46E9-8102-D193E49384B2@gmail.com> <638FA321-4DE1-467C-9B5C-3BEA0EC3EB0F@mit.edu> <207E620F-97AA-4851-8776-2A7B1921D58A@ve7jtb.com> Date: Wed, 25 Nov 2015 17:19:30 -0500 Message-ID: From: Kathleen Moriarty To: John Bradley Content-Type: multipart/alternative; boundary=001a11c3babe298e92052564da84 Archived-At: Cc: "" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-pop-architecture-06.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2015 22:19:42 -0000 --001a11c3babe298e92052564da84 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Nov 25, 2015 at 3:58 PM, John Bradley wrote: > I am fine with that, however saying integrity protected, may be better > than signed. May people will argue that HMAC or encryption with sender > verification is not signature. > Good point, I also prefer integrity protected. Are we all good with this now? I'd like to look at a diff to make sure after following the thread. Thanks! Kathleen > However they are perfectly valid. > > > On Nov 25, 2015, at 5:53 PM, Justin Richer wrote: > > The requirement is not that signed JWTs be used, it=E2=80=99s that unsign= ed JWTs > not be used on their own. Reference tokens and encrypted JWTs are also > valid, as are other signed formats like SAML assertions or even a COSE > Token (if it=E2=80=99s encoded to HTTP friendliness). > > My recommendation: > > Remove the erroneous requirement text from section 5 and restore to > previous version. > > Amend the text in section 6 from: > > To > simplify the subsequent description we assume in the PoP architecture > > that the token itself is digitally signed by the authorization server > and therefore cannot be modified. > > > > To: > > In all such cases, the token remains opaque to the client. To > simplify the subsequent example and description we assume in the PoP a= rchitecture > > that the token itself cannot be modified by the client, either due to > > cryptographic protection (such as signature or encryption) or use of > > a reference value with sufficient entropy and associated secure lookup= . > > These are characteristics shared with bearer tokens and more informati= on > > on best practices can be found in [[RFC6819]] and in the security > > considerations section of [[RFC6750]]. > > > > =E2=80=94 Justin > > On Nov 25, 2015, at 3:39 PM, Kathleen Moriarty < > kathleen.moriarty.ietf@gmail.com> wrote: > > Hi, > > Sent from my iPhone > > On Nov 25, 2015, at 3:20 PM, John Bradley wrote: > > Tokens are signed or the information is otherwise integrity protected > between the AS and the RS. > > I suspect Kathleen is concerned about the key getting modified in transit= . > > That needs to be protected against, but there is more than one way to do > that. > > > Phil is correct. I was looking for consistency between the sections sinc= e > they related to each other. If there is a security risk or consideration= , > that needs to be explicitly called out as a concern such as a key being > modified in transit. If there are options to protect against that, those > would ideally be required or would have warnings. > > > So sending the public key in a unsigned JWT access token would be > immensely stupid, not just for PoP but for scopes and everything else. > > > Good, easy to require then. > > Thanks, > Kathleen > > > In OAuth 2 all tokens need to be integrity protected between the AS and > RS. > That can be via signature, by having a reference with sufficient entropy > and secure introspection or database lookup. > > I think that is a OAuth 2 security consideration. We are adding a > additional confirmation claim to the existing information that needs to b= e > protected the same as the rest. > > John B. > > > On Nov 25, 2015, at 4:38 PM, Phil Hunt wrote: > > > If there is agreement that tokens are opaque then the requirement that > tokens be signed must be removed from the threat mitigation requirements. > > And the paragraph in sec 5 that brian was concerned about be restored. > > Phil > > On Nov 25, 2015, at 11:24, Justin Richer wrote: > > It is still end to end authentication with opaque tokens =E2=80=94 since = all OAuth > tokens, including PoP tokens, have always been intended to be opaque to t= he > client. That hasn=E2=80=99t changed and that isn=E2=80=99t the intent of = this document. If > that=E2=80=99s how people are reading it then we need to pull it back and= rewrite > it so that=E2=80=99s not the case. > > The client gets a token that has two parts: the token and the key. The > token is analogous to the access_token we have today and would come out o= f > the server in the same field. The key is handed to the client alongside t= he > token or registered by the client during the token request. Either way > there=E2=80=99s an association between the two but it=E2=80=99s not the s= ame association as > a public/private keypair. > > It=E2=80=99s possible to sign the token itself, but the client doesn=E2= =80=99t care. It > sends the token and signs the HTTP request to the RS whether the token is > signed, unsigned, hex blob, encrypted, or anything else. The same series = of > options are available as with bearer tokens. PoP tokens have never, ever > been intended to be anything but opaque to the client. > > The token can=E2=80=99t be opaque to the RS, which has to figure out what= key to > use to check the message signature. But we=E2=80=99ve got options there, = like the > embedded key in a JWT from Mike=E2=80=99s draft, or doing introspection t= o get the > key (from an extension that hasn=E2=80=99t been written yet), or simply l= ooking it > up in the same database because the RS and the AS are in the same box. Do= es > this structure/service/database choice sound familiar? It should, it=E2= =80=99s the > same as bearer tokens. This is also how the RS gets information like whic= h > scopes are associated with the token, if it=E2=80=99s expired, and all th= at. > > > > > So here=E2=80=99s how I see it going on the wire: > > > > [image: > http://www.websequencediagrams.com/cgi-bin/cdraw?lz=3DcGFydGljaXBhbnQgQ2x= pZW50IGFzIEMKAAwMUmVzb3VyY2UgT3duZXIgYXMgUk8AFA1BdXRob3JpemF0aW9uIFNlcnYAIQ= ZBUwA7DVByb3RlY3RlZABICmFzIFJTCgoKClJPLS0-QzogR28gZ2V0IG15IHIAbwcKQy0tPlJPO= iBSZWRpcmVjdCB0byBBUy9BRQAvBkFTOiBMb2cgaW4sIGEAgQIHZSBjAIFHBQpBUwAqEwAVBwBr= CEhhbmQAKQcAPAUgZ3JhbnQKCmFsdCBzAIFGBnN1cHBsaWVkIGtleQpDAG4GVG9rZW4gcmVxdWV= zdCAoADAFKQpBUwCBDAZnZW5lcmF0ZSB0ACIFYW4ANwUva2V5cGFpcgAiBUMAPAgmIEsAEAtlbH= MAgTcIAE8pICYga2V5AGYYLCBhc3NvY2lhdGUgd2l0aACBQQUAcBIKZW5kCgpDLT5SUzogUgCBU= QdpbmNsdWRpbmcAgT4Lc2lnbmVkAEEKAIIkBnRydWN0dXJlZACBbQYKUlMARAZjaGVjawCCAAdz= aWduYXR1cmUgLyBkZWNyeXB0AB8PUGFycwCCLgcAOQlVbnBhY2sAgncFAIIYBWludHJvc3BlY3R= pbwBiBkFTOiBzZW4AdAcgKG5vdABiCikgdG8AJQ9BAIEVBwAvBWtleSAocHVibGljIG9yIHNoYX= JlZCkAgwIGZGF0YWJhc2UAgUUJbG9vayB1cABhCGxvY2FsLwAtBiBEQikAHQthAIQoBgCCUAUAg= X4OAIQsCACCBAp1c2luZwCEWAUAGw9pZ2h0cwCDNQoAgm4HAIJbBgCCXQVDOiByZXR1cm4AhicJ= &s=3Dmodern-blue] > > > > (I just wrote this up so there are probably holes. Here=E2=80=99s the sou= rce if > anyone wants to tweak it: > http://www.websequencediagrams.com/?lz=3DcGFydGljaXBhbnQgQ2xpZW50IGFzIEMK= AAwMUmVzb3VyY2UgT3duZXIgYXMgUk8AFA1BdXRob3JpemF0aW9uIFNlcnYAIQZBUwA7DVByb3R= lY3RlZABICmFzIFJTCgoKClJPLS0-QzogR28gZ2V0IG15IHIAbwcKQy0tPlJPOiBSZWRpcmVjdC= B0byBBUy9BRQAvBkFTOiBMb2cgaW4sIGEAgQIHZSBjAIFHBQpBUwAqEwAVBwBrCEhhbmQAKQcAP= AUgZ3JhbnQKCmFsdCBzAIFGBnN1cHBsaWVkIGtleQpDAG4GVG9rZW4gcmVxdWVzdCAoADAFKQpB= UwCBDAZnZW5lcmF0ZSB0ACIFYW4ANwUva2V5cGFpcgAiBUMAPAgmIEsAEAtlbHMAgTcIAE8pICY= ga2V5AGYYLCBhc3NvY2lhdGUgd2l0aACBQQUAcBIKZW5kCgpDLT5SUzogUgCBUQdpbmNsdWRpbm= cAgT4Lc2lnbmVkAEEKAIIkBnRydWN0dXJlZACBbQYKUlMARAZjaGVjawCCAAdzaWduYXR1cmUgL= yBkZWNyeXB0AB8PUGFycwCCLgcAOQlVbnBhY2sAgncFAIIYBWludHJvc3BlY3RpbwBiBkFTOiBz= ZW4AdAcgKG5vdABiCikgdG8AJQ9BAIEVBwAvBWtleSAocHVibGljIG9yIHNoYXJlZCkAgwIGZGF= 0YWJhc2UAgUUJbG9vayB1cABhCGxvY2FsLwAtBiBEQikAHQthAIQoBgCCUAUAgX4OAIQsCACCBA= p1c2luZwCEWAUAGw9pZ2h0cwCDNQoAgm4HAIJbBgCCXQVDOiByZXR1cm4AhicJ&s=3Dmodern-b= lue > ) > > The client is oblivious to the token just like always. This is > intentional. The RS has the same options to figure out how to process the > token. > > =E2=80=94 Justin > > On Nov 25, 2015, at 2:03 PM, Phil Hunt wrote: > > Folks, > > > I did not want to go here either. :-) > > I don=E2=80=99t read sec 6 as examples. I believe this may stem from the > pop-architecture documents having a dual role as both =E2=80=9Carchitectu= re=E2=80=9D and > =E2=80=9Cuse-case=E2=80=9D. Maybe we should clarify the purpose of the d= ocument? > > I believe section 6 is talking about threat mitigation assumptions based > on the examples that need to be implemented. I am assuming these are > requirements that the other specifications SHOULD implement. > > > I do not believe we have discussed Opaque PoP tokens and any inherent > risks because the client is not or is unable to validate the authenticity > of the token. Does this introduce the possibility of a MITM attack where= a > client can be convinced to sign requests for an attacker? > > If we want to include opaque PoP, I think we need to take a pause and > consider / discuss any threats here. > > I find the desire for opaque PoP tokens to be a bit contradictory. If > we=E2=80=99re saying we don=E2=80=99t want to trust TLS alone (e.g. becau= se of > load-balancer termination), why would we then say, but we are perfectly > willing to accept it worked for the OAuth AS exchanges? Maybe I was very > wrong here, but my assumption all along is that for PoP we=E2=80=99re tal= king about > end-to-end authentication of all parties except in the case of 3.3 where = we > simply want to protect an access token over a non-TLS HTTP connection. > > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > On Nov 25, 2015, at 10:48 AM, Brian Campbell > wrote: > > While I can't say I disagree with the deeper existential questions about > the draft that Justin raises, I was trying not to go there and rather jus= t > point out concerns with the newly added text. > > The text Phil cites from Sec 6 doesn't say the client must be able to > parse and verify the token. It's an assumption to simplify the examples > that follow and still the token is opaque to the client. I reread the who= le > draft (reluctantly) and there's nothing that says the token has to be > non-opaque to the client. And it does talk about reference style tokens a= nd > encrypted tokens, both of which rely on the opaqueness to the client. > > On Wed, Nov 25, 2015 at 11:27 AM, Justin Richer wrote: > >> Right, I read that as text for describing the examples and not for >> describing requirements. >> >> The token itself doesn=E2=80=99t have to be signed at all. >> >> =E2=80=94 Justin >> >> On Nov 25, 2015, at 1:05 PM, Phil Hunt wrote: >> >> Ok. Well this was requested by Kathleen because of this paragraph in Sec >> 6.=E2=80=A6 >> >> >> To simplify the subsequent description we assume in the PoP architect= ure >> >> that the token itself is digitally signed by the authorization server >> >> and therefore cannot be modified. >> >> >> Please >> Phil >> >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >> >> On Nov 25, 2015, at 9:33 AM, Justin Richer wrote: >> >> The token doesn=E2=80=99t have to be signed and the client doesn=E2=80= =99t have to verify >> the signature on the token. That=E2=80=99s not PoP. The request has to b= e signed in >> a way that includes the token. The token itself can still be opaque. The >> *key* material can=E2=80=99t be opaque to the client, but the *token* ma= terial >> still is. >> >> I agree with Brian that this statement is misleading. >> >> The examples use a signed token but that is absolutely not a requirement= . >> Maybe the examples shouldn=E2=80=99t all use one style. >> >> What=E2=80=99s most difficult about this particular spec is that it=E2= =80=99s very >> hand-wavy, saying =E2=80=9Cthis is kinda a thing that kinda works like t= his=E2=80=9D >> without saying how to actually do it. I=E2=80=99m honestly not sure it= =E2=80=99s worth >> publishing as an RFC in its own right but I=E2=80=99m not going to stand= in its way. >> >> =E2=80=94 Justin >> >> On Nov 25, 2015, at 12:14 PM, Brian Campbell >> wrote: >> >> Where does it say that? >> >> >> >> On Wed, Nov 25, 2015 at 8:44 AM, Phil Hunt wrote: >> >>> Except that later on we require the token be signed and the client >>> verify that signed token. IOW mutual pop. >>> >>> Phil >>> >>> On Nov 25, 2015, at 07:30, Brian Campbell >>> wrote: >>> >>> Looking at the diff I noticed the following new text, which seems to >>> conflate bearer/PoP and opaqueness to the client. A client demonstratin= g >>> proof-of-possession of some key is orthogonal to the client being able = to >>> parse and understand the access token itself. >>> >>> "In contrast to bearer tokens [RFC6750] which call for tokens that are >>> opaque to OAuth 2.0 clients, this specification defines the requirement= s >>> for proof-of-possession ("PoP") tokens that may be parsed and verified = by >>> OAuth 2.0 clients and relying parties." >>> >>> On Tue, Nov 24, 2015 at 1:07 PM, Phil Hunt wrote= : >>> >>>> This draft addresses review comments from Kathleen and Erik raised >>>> since the last draft. >>>> >>>> It may not include some of the discussion from yesterday/today. I wil= l >>>> add that as the group decides. >>>> >>>> Cheers, >>>> >>>> Phil >>>> >>>> @independentid >>>> www.independentid.com >>>> phil.hunt@oracle.com >>>> >>>> > On Nov 24, 2015, at 12:05 PM, internet-drafts@ietf.org wrote: >>>> > >>>> > >>>> > A New Internet-Draft is available from the on-line Internet-Drafts >>>> directories. >>>> > This draft is a work item of the Web Authorization Protocol Working >>>> Group of the IETF. >>>> > >>>> > Title : OAuth 2.0 Proof-of-Possession (PoP) Securit= y >>>> Architecture >>>> > Authors : Phil Hunt >>>> > Justin Richer >>>> > William Mills >>>> > Prateek Mishra >>>> > Hannes Tschofenig >>>> > Filename : draft-ietf-oauth-pop-architecture-06.txt >>>> > Pages : 23 >>>> > Date : 2015-11-24 >>>> > >>>> > Abstract: >>>> > The OAuth 2.0 bearer token specification, as defined in RFC 6750, >>>> > allows any party in possession of a bearer token (a "bearer") to g= et >>>> > access to the associated resources (without demonstrating possessi= on >>>> > of a cryptographic key). To prevent misuse, bearer tokens must be >>>> > protected from disclosure in transit and at rest. >>>> > >>>> > Some scenarios demand additional security protection whereby a >>>> client >>>> > needs to demonstrate possession of cryptographic keying material >>>> when >>>> > accessing a protected resource. This document motivates the >>>> > development of the OAuth 2.0 proof-of-possession security mechanis= m. >>>> > >>>> > >>>> > The IETF datatracker status page for this draft is: >>>> > https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architecture/ >>>> > >>>> > There's also a htmlized version available at: >>>> > https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-06 >>>> > >>>> > A diff from the previous version is available at: >>>> > >>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-pop-architecture-= 06 >>>> > >>>> > >>>> > 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 >>>> >>> >>> >>> >>> -- >>> [image: Ping Identity logo] >>> Brian Campbell >>> Distinguished Engineer >>> Ping Identity >>> @ bcampbell@pingidentity.com [image: phone] +1 720.317.2061 [image: >>> twitter] @pingidentity Connect with us! >>> [image: pingidentity.com] >>> >>> [image: >>> pingidentity.com] >>> >>> [image: twitter logo] >>> [image: >>> twitter logo] [image: youtube logo] >>> [image: LinkedIn logo] >>> [image: Facebook logo] >>> [image: Google+ logo] >>> [image: slideshare >>> logo] [image: flipboard logo] >>> [image: rss feed icon] >>> >>> >>> >> >> >> -- >> [image: Ping Identity logo] >> Brian Campbell >> Distinguished Engineer >> Ping Identity >> @ bcampbell@pingidentity.com [image: phone] +1 720.317.2061 [image: >> twitter] @pingidentity Connect with us! >> [image: pingidentity.com] >> >> [image: >> pingidentity.com] >> >> [image: twitter logo] >> [image: >> twitter logo] [image: youtube logo] >> [image: LinkedIn logo] >> [image: Facebook logo] >> [image: Google+ logo] >> [image: slideshare >> logo] [image: flipboard logo] >> [image: rss feed icon] >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> >> > > > -- > [image: Ping Identity logo] > Brian Campbell > Distinguished Engineer > Ping Identity > @ bcampbell@pingidentity.com [image: phone] +1 720.317.2061 [image: > twitter] @pingidentity Connect with us! > [image: pingidentity.com] > > [image: > pingidentity.com] > > [image: twitter logo] > [image: > twitter logo] [image: youtube logo] > [image: LinkedIn logo] > [image: Facebook logo] > [image: Google+ logo] > [image: slideshare > logo] [image: flipboard logo] > [image: rss feed icon] > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > --=20 Best regards, Kathleen --001a11c3babe298e92052564da84 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Nov 25, 2015 at 3:58 PM, John Bradley <ve7jtb@ve7jtb.com&g= t; wrote:
I am fine with that, however saying integrity protected, may be= better than signed.=C2=A0 May people will argue that HMAC or encryption wi= th sender verification is not signature.

<= div>Good point, I also prefer integrity protected.=C2=A0 Are we all good wi= th this now?=C2=A0 I'd like to look at a diff to make sure after follow= ing the thread.

Thanks!
Kathleen

=C2=A0
However they are perfectly valid.


O= n Nov 25, 2015, at 5:53 PM, Justin Richer <jricher@mit.edu> wrote:

The requirement is not that signed JWTs be us= ed, it=E2=80=99s that unsigned JWTs not be used on their own. Reference tok= ens and encrypted JWTs are also valid, as are other signed formats like SAM= L assertions or even a COSE Token (if it=E2=80=99s encoded to HTTP friendli= ness).=C2=A0

My recommendation:

Remove the erroneous requirement text from section 5 and restore to previo= us version.

Amend the text in section 6 from:

   To
   simplify the subsequent description we assume in the PoP architecture

   that the token itself is digitally signed by the authorizatio=
n server
   and therefore cannot be modified.


To:

   In all such cases, the token r=
emains opaque to the client. To
   simplify the subsequent example and description we assume in the PoP arc=
hitecture
   that the token itself cannot be modified by the clie=
nt, either due to
   cryptographic protection (such as signature =
or encryption) or use of=C2=A0
   a reference value with sufficie=
nt entropy and associated secure lookup.
   These are characteris=
tics shared with bearer tokens and more information
   on best pr=
actices can be found in [[RFC6819]] and in the security=C2=A0
   =
considerations section of [[RFC6750]].


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

On Nov 25, 2015, at 3:39 PM, Kathleen Moriarty <kathleen.moriarty.ie= tf@gmail.com> wrote:

Hi,

Sent from my iPhone

On Nov = 25, 2015, at 3:20 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:

Tokens are signed or the information is otherwise inte= grity protected between the AS and the RS. =C2=A0

I susp= ect Kathleen is concerned about the key getting modified in transit. =C2=A0= =C2=A0
That needs to be protected against, but there is more than= one way to do that.

Phil is correct= .=C2=A0 I was looking for consistency between the sections since they relat= ed to each other.=C2=A0 If there is a security risk or consideration, that = needs to be explicitly called out as a concern such as a key being modified= in transit.=C2=A0 If there are options to protect against that, those woul= d ideally be required or would have warnings.
=

So sending the public key in a unsigned JWT access= token would be immensely stupid, =C2=A0not just for PoP but for scopes and= everything else.

Good, easy to requ= ire then.

Thanks,
Kathleen=C2=A0

In OAuth 2 all tokens need to be i= ntegrity protected between the AS and RS. =C2=A0
That can be via = signature, =C2=A0by having a reference with sufficient entropy and secure i= ntrospection or database lookup.

I think that is a= OAuth 2 security consideration. =C2=A0 We are adding a additional confirma= tion claim to the existing information that needs to be protected the same = as the rest.

John B.


=
On Nov 25, 2015, at 4:38 PM, Phil Hunt = <phil.hunt@ora= cle.com> wrote:

<editors hat= >
If there is agreement that tokens are opaque then the requir= ement that tokens be signed must be removed from the threat mitigation requ= irements.=C2=A0

And the paragraph in sec 5 that br= ian was concerned about be restored.=C2=A0

Phil

On Nov 25, 2015, at 11:24, Justin Richer <jricher@mit.edu> wrote:

It is still end to end authentication wi= th opaque tokens =E2=80=94 since all OAuth tokens, including PoP tokens, ha= ve always been intended to be opaque to the client. That hasn=E2=80=99t cha= nged and that isn=E2=80=99t the intent of this document. If that=E2=80=99s = how people are reading it then we need to pull it back and rewrite it so th= at=E2=80=99s not the case.

The client gets a token that = has two parts: the token and the key. The token is analogous to the access_= token we have today and would come out of the server in the same field. The= key is handed to the client alongside the token or registered by the clien= t during the token request. Either way there=E2=80=99s an association betwe= en the two but it=E2=80=99s not the same association as a public/private ke= ypair.=C2=A0

It=E2=80=99s possible to sign the tok= en itself, but the client doesn=E2=80=99t care. It sends the token and sign= s the HTTP request to the RS whether the token is signed, unsigned, hex blo= b, encrypted, or anything else. The same series of options are available as= with bearer tokens. PoP tokens have never, ever been intended to be anythi= ng but opaque to the client.

The token can=E2=80= =99t be opaque to the RS, which has to figure out what key to use to check = the message signature. But we=E2=80=99ve got options there, like the embedd= ed key in a JWT from Mike=E2=80=99s draft, or doing introspection to get th= e key (from an extension that hasn=E2=80=99t been written yet), or simply l= ooking it up in the same database because the RS and the AS are in the same= box. Does this structure/service/database choice sound familiar? It should= , it=E2=80=99s the same as bearer tokens. This is also how the RS gets info= rmation like which scopes are associated with the token, if it=E2=80=99s ex= pired, and all that.=C2=A0




So here=E2=80=99s how I see it going on the wire:



3D"http://www.=



(I just wrote this up so there are probably holes. Here=E2= =80=99s the source if anyone wants to tweak it:=C2=A0http://www.websequencediagrams.com/?lz= =3DcGFydGljaXBhbnQgQ2xpZW50IGFzIEMKAAwMUmVzb3VyY2UgT3duZXIgYXMgUk8AFA1BdXRo= b3JpemF0aW9uIFNlcnYAIQZBUwA7DVByb3RlY3RlZABICmFzIFJTCgoKClJPLS0-QzogR28= gZ2V0IG15IHIAbwcKQy0tPlJPOiBSZWRpcmVjdCB0byBBUy9BRQAvBkFTOiBMb2cgaW4sIGEAgQ= IHZSBjAIFHBQpBUwAqEwAVBwBrCEhhbmQAKQcAPAUgZ3JhbnQKCmFsdCBzAIFGBnN1cHBsaWVkI= GtleQpDAG4GVG9rZW4gcmVxdWVzdCAoADAFKQpBUwCBDAZnZW5lcmF0ZSB0ACIFYW4ANwUva2V5= cGFpcgAiBUMAPAgmIEsAEAtlbHMAgTcIAE8pICYga2V5AGYYLCBhc3NvY2lhdGUgd2l0aACBQQU= AcBIKZW5kCgpDLT5SUzogUgCBUQdpbmNsdWRpbmcAgT4Lc2lnbmVkAEEKAIIkBnRydWN0dXJlZA= CBbQYKUlMARAZjaGVjawCCAAdzaWduYXR1cmUgLyBkZWNyeXB0AB8PUGFycwCCLgcAOQlVbnBhY= 2sAgncFAIIYBWludHJvc3BlY3RpbwBiBkFTOiBzZW4AdAcgKG5vdABiCikgdG8AJQ9BAIEVBwAv= BWtleSAocHVibGljIG9yIHNoYXJlZCkAgwIGZGF0YWJhc2UAgUUJbG9vayB1cABhCGxvY2FsLwA= tBiBEQikAHQthAIQoBgCCUAUAgX4OAIQsCACCBAp1c2luZwCEWAUAGw9pZ2h0cwCDNQoAgm4HAI= JbBgCCXQVDOiByZXR1cm4AhicJ&s=3Dmodern-blue )

T= he client is oblivious to the token just like always. This is intentional. = The RS has the same options to figure out how to process the token.

=C2=A0=E2=80=94 Justin

On Nov 25, 2015, at 2:03 PM, Phil Hunt <phil.hunt@oracle.com> wrot= e:

Folks,=C2=A0

<edi= tor hat>
I did not want to go here either. :-)

<= /div>
I don=E2=80=99t read sec 6 as examples.=C2=A0 I believe this may = stem from the pop-architecture documents having a dual role as both =E2=80= =9Carchitecture=E2=80=9D and =E2=80=9Cuse-case=E2=80=9D.=C2=A0 Maybe we sho= uld clarify the purpose of the document?

I believe= section 6 is talking about threat mitigation assumptions based on the exam= ples that need to be implemented.=C2=A0 I am assuming these are requirement= s that the other specifications SHOULD implement.

= <personal hat>
I do not believe we have discussed Opaque Po= P tokens and any inherent risks because the client is not or is unable to v= alidate the authenticity of the token.=C2=A0 Does this introduce the possib= ility of a MITM attack where a client can be convinced to sign requests for= an attacker?

If we want to include opaque PoP, I = think we need to take a pause and consider / discuss any threats here.

I find the desire for opaque PoP tokens to be a bit co= ntradictory. If we=E2=80=99re saying we don=E2=80=99t want to trust TLS alo= ne (e.g. because of load-balancer termination), why would we then say, but = we are perfectly willing to accept it worked for the OAuth AS exchanges?=C2= =A0 Maybe I was very wrong here, but my assumption all along is that for Po= P we=E2=80=99re talking about end-to-end authentication of all parties exce= pt in the case of 3.3 where we simply want to protect an access token over = a non-TLS HTTP connection.


On Nov 25, 2015, at 10:48 AM, Brian= Campbell <bcampbell@pingidentity.com> wrote:

While I can't say I disagree with the deeper existential que= stions about the draft that Justin raises, I was trying not to go there and= rather just point out concerns with the newly added text.

Th= e text Phil cites from Sec 6 doesn't say the client must be able to par= se and verify the token. It's an assumption to simplify the examples th= at follow and still the token is opaque to the client. I reread the whole d= raft (reluctantly) and there's nothing that says the token has to be no= n-opaque to the client. And it does talk about reference style tokens and e= ncrypted tokens, both of which rely on the opaqueness to the client.

On Wed,= Nov 25, 2015 at 11:27 AM, Justin Richer <jricher@mit.edu> wro= te:
R= ight, I read that as text for describing the examples and not for describin= g requirements.

The token itself doesn=E2=80=99t have to= be signed at all.

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

On Nov 25, 2015, at 1:05 PM, Phil Hunt <phil.hunt@oracle.com>= ; wrote:

Ok. Well this was requested by Kathleen= because of this paragraph in Sec 6.=E2=80=A6

   To simplify the subsequent descripti=
on we assume in the PoP architecture
   that the token itself is digitally signed =
by the authorization server

   and=
 therefore cannot be modified.

Please=C2=A0

On Nov 25, 2015, at 9:33 AM, Justin= Richer <jricher@mi= t.edu> wrote:

The = token doesn=E2=80=99t have to be signed and the client doesn=E2=80=99t have= to verify the signature on the token. That=E2=80=99s not PoP. The request = has to be signed in a way that includes the token. The token itself can sti= ll be opaque. The *key* material can=E2=80=99t be opaque to the client, but= the *token* material still is.

I agree with Brian that = this statement is misleading.

The examples use a sig= ned token but that is absolutely not a requirement. Maybe the examples shou= ldn=E2=80=99t all use one style.

What=E2=80=99s mo= st difficult about this particular spec is that it=E2=80=99s very hand-wavy= , saying =E2=80=9Cthis is kinda a thing that kinda works like this=E2=80=9D= without saying how to actually do it. I=E2=80=99m honestly not sure it=E2= =80=99s worth publishing as an RFC in its own right but I=E2=80=99m not goi= ng to stand in its way.

=C2=A0=E2=80=94 Justin

On Nov 25, 2015, at 12:14 PM= , Brian Campbell <bcampbell@pingidentity.com> wrote:

Where does it say that?



On Wed, Nov 25, 2015 at 8:44 AM, Phil Hu= nt <phil.hunt@oracle.com> wrote:
Except that later on we require the token = be signed and the client verify that signed token. IOW mutual pop.=C2=A0

Phil
<= br>On Nov 25, 2015, at 07:30, Brian Campbell <bcampbell@pingidentity.com> wr= ote:

Looking a= t the diff I noticed the following new text, which seems to conflate bearer= /PoP and opaqueness to the client. A client demonstrating proof-of-possessi= on of some key is orthogonal to the client being able to parse and understa= nd the access token itself.
=C2=A0
"In contrast to bearer token= s [RFC6750] which call for tokens that are opaque to OAuth 2.0 clients, thi= s specification defines the requirements for proof-of-possession ("PoP= ") tokens that may be parsed and verified by OAuth 2.0 clients and rel= ying parties."

On Tue, Nov 24, 2015 at 1:07 PM, Phil Hunt &l= t;phil.hunt@oracl= e.com> wrote:
This draft ad= dresses review comments from Kathleen and Erik raised since the last draft.=

It may not include some of the discussion from yesterday/today.=C2=A0 I wil= l add that as the group decides.

Cheers,

Phil

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

> On Nov 24, 2015, at 12:05 PM, internet-drafts@ietf.org wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
> This draft is a work item of the Web Authorization Protocol Working Gr= oup of the IETF.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: OAuth 2.0 Proof-of-Possession (PoP) Security Architecture
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: = Phil Hunt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Justin Richer
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 William Mills
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Prateek Mishra
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Hannes Tschofenig
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-= ietf-oauth-pop-architecture-06.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: 23
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : 2015-11-24
>
> Abstract:
>=C2=A0 =C2=A0The OAuth 2.0 bearer token specification, as defined in RF= C 6750,
>=C2=A0 =C2=A0allows any party in possession of a bearer token (a "= bearer") to get
>=C2=A0 =C2=A0access to the associated resources (without demonstrating = possession
>=C2=A0 =C2=A0of a cryptographic key).=C2=A0 To prevent misuse, bearer t= okens must be
>=C2=A0 =C2=A0protected from disclosure in transit and at rest.
>
>=C2=A0 =C2=A0Some scenarios demand additional security protection where= by a client
>=C2=A0 =C2=A0needs to demonstrate possession of cryptographic keying ma= terial when
>=C2=A0 =C2=A0accessing a protected resource.=C2=A0 This document motiva= tes the
>=C2=A0 =C2=A0development of the OAuth 2.0 proof-of-possession security = mechanism.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org= /doc/draft-ietf-oauth-pop-architecture/
>
> There's also a htmlized version available at:
> https://tools.ietf.org/html/dra= ft-ietf-oauth-pop-architecture-06
>
> A diff from the previous version is available at:
> https://www.ietf.org/rf= cdiff?url2=3Ddraft-ietf-oauth-pop-architecture-06
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org.<= br> >
> 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



--
=09 3D"Ping=20
Brian Campbell
Distinguished Engineer
Ping Identity
@<= /td> <= span style=3D"text-decoration:none;font-family:arial,helvetica,sans-serif;f= ont-weight:normal;font-size:14px;padding:0px 0px 0px 3px">bcampbell@pingidentity.com
3D"phone" <= span style=3D"font-family:arial,helvetica,sans-serif;font-weight:normal;fon= t-size:14px;padding:0px 0px 0px 3px">+1 720.317.2061
3D"twitter" <= span style=3D"font-family:arial,helvetica,sans-serif;font-weight:normal;fon= t-size:14px;padding:0px 0px 0px 3px">@pingidentity
Connect with us!
3D"pingidentity.com"
3D"pingidentity.com" 3D"twitter 3D"twitter 3D"youtube 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard 3D"rss



--
=09 3D"Ping=20
Brian Campbell
Distinguished Engineer
Ping Identity
@<= /td> <= span style=3D"text-decoration:none;font-family:arial,helvetica,sans-serif;f= ont-weight:normal;font-size:14px;padding:0px 0px 0px 3px">bcampbell@pingidentity.com
3D"phone" <= span style=3D"font-family:arial,helvetica,sans-serif;font-weight:normal;fon= t-size:14px;padding:0px 0px 0px 3px">+1 720.317.2061
3D"twitter" <= span style=3D"font-family:arial,helvetica,sans-serif;font-weight:normal;fon= t-size:14px;padding:0px 0px 0px 3px">@pingidentity
Connect with us!
3D"pingidentity.com"
3D"pingidentity.com" 3D"twitter 3D"twitter 3D"youtube 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard 3D"rss
_______________________________________________
OAuth mailing list
OAuth@ietf.org
http= s://www.ietf.org/mailman/listinfo/oauth





--
=09 3D"Ping=20
Brian Campbell
Distinguished Engineer
Ping Identity
@<= /td> <= span style=3D"text-decoration:none;font-family:arial,helvetica,sans-serif;f= ont-weight:normal;font-size:14px;padding:0px 0px 0px 3px">bcampbell@pingidentity.com
3D"phone" <= span style=3D"font-family:arial,helvetica,sans-serif;font-weight:normal;fon= t-size:14px;padding:0px 0px 0px 3px">+1 720.317.2061
3D"twitter" <= span style=3D"font-family:arial,helvetica,sans-serif;font-weight:normal;fon= t-size:14px;padding:0px 0px 0px 3px">@pingidentity
Connect with us!
3D"pingidentity.com"
3D"pingidentity.com" 3D"twitter 3D"twitter 3D"youtube 3D"LinkedIn 3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard 3D"rss


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

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




--

Best regards,
Kathleen
--001a11c3babe298e92052564da84-- From nobody Wed Nov 25 15:37:19 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A9881B3295 for ; Wed, 25 Nov 2015 15:37:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tvSLlKjFHyVG for ; Wed, 25 Nov 2015 15:37:14 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0106.outbound.protection.outlook.com [65.55.169.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32AA91B3294 for ; Wed, 25 Nov 2015 15:37:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=VZbFJs2tsJpYmuv8ANo3braKtkg8+j9CO3H87nC5qac=; b=IwfLMTw3oW23tycDbLmdX/q0AYPCwBGYgGY4sbfzKAt03Q/iMipACc7NzhVb2s/qo2AfQ1+t83gGxOhdi5q6jDHbadpMvg48Sn2U7QmcB+cFG914ZMUz2sOUBbjzeXr6d7sJaya++D0PBaLxR1I2XH9f6ncRMTzUzcmALKphsIk= Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB443.namprd03.prod.outlook.com (10.141.141.152) with Microsoft SMTP Server (TLS) id 15.1.331.20; Wed, 25 Nov 2015 23:37:10 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0331.023; Wed, 25 Nov 2015 23:37:10 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: OAuth Discovery Thread-Index: AdEnv6MqmLA/Ph7MT4qJwfYSFGITHw== Date: Wed, 25 Nov 2015 23:37:10 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [2001:4898:80e8:a::650] x-microsoft-exchange-diagnostics: 1; BY2PR03MB443; 5:391+g9/NR2yYYwIK6svUKpJfrqAlKaNigBU/6KwvMR+rHYM+NMHhHMdl8bKkrz1viwH7u1kohs64FjmMFDi8PXwKbfylG4rSdbCxt4aVZMwrS4UVA64dXgm/AthfeM4swPu7Pw27YM40I658XNw9rw==; 24:mn4LLs4ZwMuCgabg3cqX/JelVIPhjWj0G7cvCW4Zu/1aAj/a+acP8sgR7vkSIiQ2RKqFLcuTdDt9qaUE4OwSV9DOUO8sG4LGfmQHgNJoHuY= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB443; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425024)(601004)(2401047)(520078)(5005006)(8121501046)(10201501046)(3002001)(61426024)(61427024); SRVR:BY2PR03MB443; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB443; x-forefront-prvs: 0771670921 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(209900001)(189002)(199003)(106356001)(5004730100002)(33656002)(86612001)(105586002)(99286002)(122556002)(5005710100001)(87936001)(8990500004)(74316001)(10290500002)(2501003)(10400500002)(450100001)(86362001)(10090500001)(1220700001)(5002640100001)(5003600100002)(2900100001)(15975445007)(19617315012)(77096005)(40100003)(19625215002)(221733001)(50986999)(16236675004)(586003)(19580395003)(6116002)(102836003)(54356999)(790700001)(11100500001)(5001960100002)(110136002)(97736004)(76576001)(2351001)(189998001)(19300405004)(107886002)(81156007)(229853001)(15395725005)(5008740100001)(92566002)(101416001)(1096002)(3826002)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB443; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR03MB4420981B312D92924AD6BFFF5050BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Nov 2015 23:37:10.4883 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB443 Archived-At: Subject: [OAUTH-WG] OAuth Discovery X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2015 23:37:17 -0000 --_000_BY2PR03MB4420981B312D92924AD6BFFF5050BY2PR03MB442namprd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm pleased to announce that Nat Sakimura, John Bradley, and I have created= an OAuth 2.0 Discovery specification. This fills a hole in the current OA= uth specification set that is necessary to achieve interoperability. Indee= d, the Interoperability section of OAuth 2.0 states: In addition, this specification leaves a few required components partially = or fully undefined (e.g., client registration, authorization server capabil= ities, endpoint discovery). Without these components, clients must be manu= ally and specifically configured against a specific authorization server an= d resource server in order to interoperate. This framework was designed with the clear expectation that future work wil= l define prescriptive profiles and extensions necessary to achieve full web= -scale interoperability. This specification enables discovery of both endpoint locations and authori= zation server capabilities. This specification is based upon the already widely deployed OpenID Connect= Discovery 1.0 s= pecification and is compatible with it, by design. The OAuth Discovery spe= c removes the portions of OpenID Connect Discovery that are OpenID specific= and adds metadata values for Revocation and Introspection endpoints. It a= lso maps OpenID concepts, such as OpenID Provider, Relying Party, End-User,= and Issuer to their OAuth underpinnings, respectively Authorization Server= , Client, Resource Owner, and the newly introduced Configuration Informatio= n Location. Some identifiers with names that appear to be OpenID specific = were retained for compatibility purposes; despite the reuse of these identi= fiers that appear to be OpenID specific, their usage in this specification = is actually referring to general OAuth 2.0 features that are not specific t= o OpenID Connect. The specification is available at: * http://tools.ietf.org/html/draft-jones-oauth-discovery-00 An HTML-formatted version is also available at: * http://self-issued.info/docs/draft-jones-oauth-discovery-00.html -- Mike P.S. This note was also posted at http://self-issued.info/?p=3D1496 and as= @selfissued. --_000_BY2PR03MB4420981B312D92924AD6BFFF5050BY2PR03MB442namprd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’m pleased to announce that Nat Sakimura, Joh= n Bradley, and I have created an OAuth 2.0 Discovery specification.  T= his fills a hole in the current OAuth specification set that is necessary t= o achieve interoperability.  Indeed, the Interoperabilit= y section of OAuth 2.0 states:

In addition, this specification leaves a few req=
uired components partially or fully undefined (e.g., client registration, a=
uthorization server capabilities, endpoint discovery).  Without these =
components, clients must be manually and specifically configured against a =
specific authorization server and resource server in order to interoperate.=

 
This framework was designed with the clear expec=
tation that future work will define prescriptive profiles and extensions ne=
cessary to achieve full web-scale interoperability.

 

This specification enables discove= ry of both endpoint locations and authorization server capabilities.

 

This specification is based upon t= he already widely deployed OpenI= D Connect Discovery 1.0 specification and is compatible with it, by des= ign.  The OAuth Discovery spec removes the portions of OpenID Connect = Discovery that are OpenID specific and adds metadata values for Revocation and Introspection endpoints.  It = also maps OpenID concepts, such as OpenID Provider, Relying Party, End-User= , and Issuer to their OAuth underpinnings, respectively Authorization Serve= r, Client, Resource Owner, and the newly introduced Configuration Information Location.  Some identifiers with= names that appear to be OpenID specific were retained for compatibility pu= rposes; despite the reuse of these identifiers that appear to be OpenID spe= cific, their usage in this specification is actually referring to general OAuth 2.0 features that are not specific = to OpenID Connect.

 

The specification is available at:=

·         http://tools.ietf.org/html/draf= t-jones-oauth-discovery-00

 

An HTML-formatted version is also = available at:

·         http://self-issued.info/docs= /draft-jones-oauth-discovery-00.html

 

     &nbs= p;             =             &nb= sp;            =             &nb= sp;       -- Mike

 

P.S.  This note was also post= ed at http://self-issued.info/?p=3D1496 and as @selfissued.

--_000_BY2PR03MB4420981B312D92924AD6BFFF5050BY2PR03MB442namprd_-- From nobody Wed Nov 25 16:01:47 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B103F1B32D4 for ; Wed, 25 Nov 2015 16:01:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.963 X-Spam-Level: X-Spam-Status: No, score=-1.963 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6x-euv2xH-n7 for ; Wed, 25 Nov 2015 16:01:44 -0800 (PST) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::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 D07B31B32D5 for ; Wed, 25 Nov 2015 16:01:43 -0800 (PST) Received: by qgcc31 with SMTP id c31so44018517qgc.3 for ; Wed, 25 Nov 2015 16:01:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ZjgwWGKbAMm+p2vuJA3fen+/9IV0SHEUjFjm1XkZwMQ=; b=clV5fu8r73aZpV4fcRNsZC6rWT32FRPQADORC1nXQLoFhGv0oThMnELg2c/rvvaXP6 ZTE+XgvSlKpyXpf6cYywkhMyurMXvsgDZ9VUPsPsl3ediOieitIMkWqJ3DLVdvR7DdcA i5XYGQGvUrqiMM/Okq4OVjj+heISF5F33UkGU8sMepBMgIt0w+BoNo8cN3uM1Z7Hl/Ue be+FvfKDsR9Tt7exikmX2aQgI2I/Hsry+pAAHI+bVpJ/1NZ/j5lMjdRK0FdUnO8gNzTV sN2Uxo3lwHTa/eLhfoHicWoHxti7xK8QXY9Yy+HWUM68w9rJO1WOzeze2glU6Kg/exWo ERQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=ZjgwWGKbAMm+p2vuJA3fen+/9IV0SHEUjFjm1XkZwMQ=; b=dNmIH64sw9owBV/7CncVKLMhxQVmVhoE3eZ3Wfue7Adr7PdttAEs4rawuxn9qQoFMl S0FlaS3rP66eM5ugCWqd8gP5yNttl7t6yI08SvoWpNQdPcH2Rjz6Uw8e4YwWy7A6aXKy 1q9zQ4r+GPOwGwp3bu5XJax+msjnNCGGs1vG0TLwo/upukD/iGR1jlkShwzaZcGleTSr 59Sahr5lXfdsyz3KFic3+t2ZqvMeWLrHKgMh1noYhGmapvk/mUSTOgycmEdP8YtDuyTB m0BdXokP5j8Rv2AURcqX0YAQtBN3TOFyMxGnB5Q2WO75xGr837iZGi4gOTJlb1Jl86Yx F45A== X-Gm-Message-State: ALoCoQmDecOEIWj7j4sJ7O08NJJXybHVYOsp8ITTDqLPinrlrUKFMkbBMqkDH5xMeKW3j2u+ZX6Q X-Received: by 10.141.6.69 with SMTP id i66mr45683606qhd.68.1448496102872; Wed, 25 Nov 2015 16:01:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.29.68 with HTTP; Wed, 25 Nov 2015 16:01:23 -0800 (PST) In-Reply-To: References: From: William Denniss Date: Wed, 25 Nov 2015 16:01:23 -0800 Message-ID: To: Mike Jones Content-Type: multipart/alternative; boundary=001a113a7c1cabf29c05256647df Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth Discovery X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2015 00:01:46 -0000 --001a113a7c1cabf29c05256647df Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Looks good. A few review notes: 1. Can we add a xref to the WebFinger spec (RFC7033) in section 2? 2. Is the only way to discover the location of the discovery document via WebFinger? In Yokohama we also talked about the AS returning the discovery document host (i.e. issuer) on the auth and token endpoints. What are the reasons for choosing WebFinger over that method? 3. It looks like an IANA registry was not setup for OpenID Connect discovery params (at least, not in that spec). Is the registry established in http://tools.ietf.org/html/draft-jones-oauth-discovery-00#section-8.1.2 designed to be a shared registry for OIDC/OAuth discovery? And if so, should we also register values defined in the OIDC discovery spec, e.g. "subject_types_supported" On Wed, Nov 25, 2015 at 3:37 PM, Mike Jones wrote: > I=E2=80=99m pleased to announce that Nat Sakimura, John Bradley, and I ha= ve > created an OAuth 2.0 Discovery specification. This fills a hole in the > current OAuth specification set that is necessary to achieve > interoperability. Indeed, the Interoperability section of OAuth 2.0 > states: > > In addition, this specification leaves a few required components partiall= y or fully undefined (e.g., client registration, authorization server capab= ilities, endpoint discovery). Without these components, clients must be ma= nually and specifically configured against a specific authorization server = and resource server in order to interoperate. > > > > This framework was designed with the clear expectation that future work w= ill define prescriptive profiles and extensions necessary to achieve full w= eb-scale interoperability. > > > > This specification enables discovery of both endpoint locations and > authorization server capabilities. > > > > This specification is based upon the already widely deployed OpenID > Connect Discovery 1.0 > specification > and is compatible with it, by design. The OAuth Discovery spec removes t= he > portions of OpenID Connect Discovery that are OpenID specific and adds > metadata values for Revocation and Introspection endpoints. It also maps > OpenID concepts, such as OpenID Provider, Relying Party, End-User, and > Issuer to their OAuth underpinnings, respectively Authorization Server, > Client, Resource Owner, and the newly introduced Configuration Informatio= n > Location. Some identifiers with names that appear to be OpenID specific > were retained for compatibility purposes; despite the reuse of these > identifiers that appear to be OpenID specific, their usage in this > specification is actually referring to general OAuth 2.0 features that ar= e > not specific to OpenID Connect. > > > > The specification is available at: > > =C2=B7 http://tools.ietf.org/html/draft-jones-oauth-discovery-00 > > > > An HTML-formatted version is also available at: > > =C2=B7 http://self-issued.info/docs/draft-jones-oauth-discovery-0= 0.html > > > > -- Mike > > > > P.S. This note was also posted at http://self-issued.info/?p=3D1496 and = as > @selfissued . > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --001a113a7c1cabf29c05256647df Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Looks good. A few review notes:

1.
Can we add a xref to the WebFinger spec (RFC7033) in section 2?
=

2.
Is the only way to discover the location o= f the discovery document via WebFinger?

In Yokoham= a we also talked about the AS returning the discovery document host (i.e. i= ssuer) on the auth and token endpoints.=C2=A0 What are the reasons for choo= sing WebFinger over that method?

3.

On Wed, Nov 25, 2015 at 3:37 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

I=E2=80=99m pleased to announce that Nat Sakimura, J= ohn Bradley, and I have created an OAuth 2.0 Discovery specification.=C2=A0= This fills a hole in the current OAuth specification set that is necessary= to achieve interoperability.=C2=A0 Indeed, the Interoperability section of OAuth 2.0 states:

In addition, this specification leaves a few required components partiall=
y or fully undefined (e.g., client registration, authorization server capab=
ilities, endpoint discovery).=C2=A0 Without these components, clients must =
be manually and specifically configured against a specific authorization se=
rver and resource server in order to interoperate.

=C2=A0


This framework was designed with the clear expectation that future work w=
ill define prescriptive profiles and extensions necessary to achieve full w=
eb-scale interoperability.


=C2=A0


This specification enables discove=
ry of both endpoint locations and authorization server capabilities.=



=C2=A0


This specification is based upon t=
he already widely deployed
OpenID Connect Discovery 1.0 specification and is compatib=
le with it, by design.=C2=A0 The OAuth Discovery spec removes the portions =
of OpenID Connect Discovery that are OpenID specific and
 adds metadata values for Revocation and Introspection endpoints.=C2=A0 It =
also maps OpenID concepts, such as OpenID Provider, Relying Party, End-User=
, and Issuer to their OAuth underpinnings, respectively Authorization Serve=
r, Client, Resource Owner, and the newly
 introduced Configuration Information Location.=C2=A0 Some identifiers with=
 names that appear to be OpenID specific were retained for compatibility pu=
rposes; despite the reuse of these identifiers that appear to be OpenID spe=
cific, their usage in this specification
 is actually referring to general OAuth 2.0 features that are not specific =
to OpenID Connect.


=C2=A0


The specification is available at:=



=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0
http://tools.iet=
f.org/html/draft-jones-oauth-discovery-00


=C2=A0


An HTML-formatted version is also =
available at:


=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0
http://self-i=
ssued.info/docs/draft-jones-oauth-discovery-00.html=



=C2=A0


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=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 note was also post=
ed at 
http://self-issued.info/?p=3D1496 and as 
@selfissued.

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


--001a113a7c1cabf29c05256647df-- From nobody Wed Nov 25 16:59:36 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65A521A1A1C for ; Wed, 25 Nov 2015 16:59:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GYOWWrEqFkkz for ; Wed, 25 Nov 2015 16:59:32 -0800 (PST) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2E211A0856 for ; Wed, 25 Nov 2015 16:59:31 -0800 (PST) Received: by qgea14 with SMTP id a14so44827226qge.0 for ; Wed, 25 Nov 2015 16:59:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=Tgp9lmibL+hzWdeMxam5D2GWTfKsF4+7nbjzhqkL0Ps=; b=H5Ggqjek8Tf8e+tfYYsNBpq0AnrseYiKrBb+d2AN7iQqXTrI5CHaAj/qnCxMjEPqn8 VOImN7GtzT1Y+6fYRTQR9BWRCJASF1/WLmr/Q7hlzCYfUH3mWUPQM4NSU5/DWy0OHuJY UyZc7joNJ3dX/TuQjCNvwXRlurXCH23oHCTi3B/MpW/RMNmqWiLVKfnNQT6C7erY1Sid NXebuntWWu5kMC6rFl0SskF7YUeuPq9jUJ0rgILYIcv1yWqm97PQ9srQ2xxTqfOCPEap zS5PxBQtUOVqPRt5MDHku3FgkVdVMfNkEvn9y0zqdLLf+aQ0YhfvokntJZTsaFgUi+z/ TdlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=Tgp9lmibL+hzWdeMxam5D2GWTfKsF4+7nbjzhqkL0Ps=; b=LE0g6gYzOAoHq6JBsGVGFg3XLOESZBb2b0FixNvZEWSxCeulRqG0PB3c8yxEMlINHD RALg4iHxzzYXkijhHCWqayU2eTq0YbS/ij/OC/gSjiEGkFQMxokHewMmEVPva796mTvd PWAh4CbbSbwUwKKiHp2eXkbtznoie0CGcYK9W241OtRq2fcVqg21ZP2YUqw+EG+KVwM1 0LKQ3It/Ws0/865taTyVCjMUKh/zLFZi04MtmvLfT0V+UGFIZ8Dbjq+LiZF7/L8x3X5V Drn1TIPJfi12nCwjDZplHmr6gAW85fqNnjAfu+BUB+vu9PpZPPEaE0BfM2GZdf3Yz1tW /k9A== X-Gm-Message-State: ALoCoQnY2kkpbtUU7P9ZfF4D1dbm1/gZ2ftWhDTmsBSG9lmvAhm8/vi0j2BeiJMicg/EfqtXGZ7N X-Received: by 10.140.106.201 with SMTP id e67mr32562590qgf.80.1448499570840; Wed, 25 Nov 2015 16:59:30 -0800 (PST) Received: from [192.168.1.216] ([191.115.122.254]) by smtp.gmail.com with ESMTPSA id q133sm6307288qhq.20.2015.11.25.16.59.26 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 25 Nov 2015 16:59:29 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_1A35F566-BF9D-426A-B155-C511E62ABF85" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: John Bradley In-Reply-To: Date: Wed, 25 Nov 2015 21:59:18 -0300 Message-Id: References: To: William Denniss X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth Discovery X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2015 00:59:35 -0000 --Apple-Mail=_1A35F566-BF9D-426A-B155-C511E62ABF85 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Inline > On Nov 25, 2015, at 9:01 PM, William Denniss = wrote: >=20 > Looks good. A few review notes: >=20 > 1. > Can we add a xref to the WebFinger spec (RFC7033) in section 2? Yes that should be OK >=20 > 2. > Is the only way to discover the location of the discovery document via = WebFinger? >=20 > In Yokohama we also talked about the AS returning the discovery = document host (i.e. issuer) on the auth and token endpoints. What are = the reasons for choosing WebFinger over that method? This is a first draft, that is close to the Connect Document. It needs = work, around what a issuer (AS identity) is in OAuth. Some of the = Webdinger stuff is strange without a specific API that you are looking = for. It would be odd to look for someone=E2=80=99s OAuth server. I = could see looking for a persons Photosharing service and getting = directed to It=E2=80=99s AS discovery document assuming a well known = API. Nat has a spec on meta-data for the endpoint API. The WG may elect to = merge them or keep them separate. It would be the endpoint meta-data = (headers) that would point at the discovery document. This is a start. >=20 > 3. > It looks like an IANA registry was not setup for OpenID Connect = discovery params (at least, not in that spec). Is the registry = established in = http://tools.ietf.org/html/draft-jones-oauth-discovery-00#section-8.1.2 = = designed to be a shared registry for OIDC/OAuth discovery? And if so, = should we also register values defined in the OIDC discovery spec, e.g. = =E2=80=9Csubject_types_supported" I expect that like registration, OAuth would establish the registry and = register an initial set, and then Connect would add connect specific = claims to that registry once it is established. John B. >=20 > On Wed, Nov 25, 2015 at 3:37 PM, Mike Jones = > = wrote: > I=E2=80=99m pleased to announce that Nat Sakimura, John Bradley, and I = have created an OAuth 2.0 Discovery specification. This fills a hole in = the current OAuth specification set that is necessary to achieve = interoperability. Indeed, the Interoperability section of OAuth 2.0 = states: >=20 > In addition, this specification leaves a few required components = partially or fully undefined (e.g., client registration, authorization = server capabilities, endpoint discovery). Without these components, = clients must be manually and specifically configured against a specific = authorization server and resource server in order to interoperate. > =20 > This framework was designed with the clear expectation that future = work will define prescriptive profiles and extensions necessary to = achieve full web-scale interoperability. > =20 >=20 > This specification enables discovery of both endpoint locations and = authorization server capabilities. >=20 > =20 >=20 > This specification is based upon the already widely deployed OpenID = Connect Discovery 1.0 = = specification and is compatible with it, by design. The OAuth Discovery = spec removes the portions of OpenID Connect Discovery that are OpenID = specific and adds metadata values for Revocation and Introspection = endpoints. It also maps OpenID concepts, such as OpenID Provider, = Relying Party, End-User, and Issuer to their OAuth underpinnings, = respectively Authorization Server, Client, Resource Owner, and the newly = introduced Configuration Information Location. Some identifiers with = names that appear to be OpenID specific were retained for compatibility = purposes; despite the reuse of these identifiers that appear to be = OpenID specific, their usage in this specification is actually referring = to general OAuth 2.0 features that are not specific to OpenID Connect. >=20 > =20 >=20 > The specification is available at: >=20 > =C2=B7 = http://tools.ietf.org/html/draft-jones-oauth-discovery-00 = > =20 >=20 > An HTML-formatted version is also available at: >=20 > =C2=B7 = http://self-issued.info/docs/draft-jones-oauth-discovery-00.html = > =20 >=20 > -- = Mike >=20 > =20 >=20 > P.S. This note was also posted at http://self-issued.info/?p=3D1496 = and as @selfissued = . >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_1A35F566-BF9D-426A-B155-C511E62ABF85 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Inline
On Nov 25, 2015, at 9:01 PM, William Denniss = <wdenniss@google.com> wrote:

Looks good. A few review notes:

1.
Can we add a = xref to the WebFinger spec (RFC7033) in section = 2?
Yes that should be OK

2.
Is the only way to discover the = location of the discovery document via WebFinger?
In Yokohama we also talked about the = AS returning the discovery document host (i.e. issuer) on the auth and = token endpoints.  What are the reasons for choosing WebFinger over = that method?

This = is a first draft, that is close to the Connect Document.  It needs = work, around what a issuer (AS identity) is in OAuth.   Some of the = Webdinger stuff is strange without a specific API that you are looking = for.   It would be odd to look for someone=E2=80=99s OAuth server. =  I could see looking for a persons Photosharing service and getting = directed to It=E2=80=99s AS discovery document assuming a well known = API.

Nat has a spec on meta-data for = the endpoint API.   The WG may elect to merge them or keep them = separate.   It would be the endpoint meta-data (headers) that would = point at the discovery document.

This = is a start.

3.
It looks like = an IANA registry was not setup for OpenID Connect discovery params (at = least, not in that spec). Is the registry established in http://tools.ietf.org/html/draft-jones-oauth-discovery-00#secti= on-8.1.2 designed to be a shared registry for OIDC/OAuth discovery? = And if so, should we also register values defined in the OIDC discovery = spec, e.g. = =E2=80=9Csubject_types_supported"

I expect that like registration, OAuth would establish = the registry and register an initial set, and then Connect would add = connect specific claims to that registry once it is = established.

John B.

On Wed, = Nov 25, 2015 at 3:37 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

I=E2=80=99m pleased to announce = that Nat Sakimura, John Bradley, and I have created an OAuth 2.0 = Discovery specification.  This fills a hole in the current OAuth = specification set that is necessary to achieve interoperability.  = Indeed, the Interoperability section of OAuth 2.0 states:

In addition, this specification =
leaves a few required components partially or fully undefined (e.g., =
client registration, authorization server capabilities, endpoint =
discovery).  Without these components, clients must be manually and =
specifically configured against a specific authorization server and =
resource server in order to interoperate.
 
This framework was designed with =
the clear expectation that future work will define prescriptive profiles =
and extensions necessary to achieve full web-scale interoperability.

 

This specification enables discovery of both endpoint = locations and authorization server capabilities.

 

This specification is = based upon the already widely deployed OpenID Connect Discovery 1.0 = specification and is compatible with it, by design.  The OAuth = Discovery spec removes the portions of OpenID Connect Discovery that are = OpenID specific and adds metadata values for Revocation and Introspection endpoints.  = It also maps OpenID concepts, such as OpenID Provider, Relying Party, = End-User, and Issuer to their OAuth underpinnings, respectively = Authorization Server, Client, Resource Owner, and the newly introduced Configuration Information Location.  Some identifiers = with names that appear to be OpenID specific were retained for = compatibility purposes; despite the reuse of these identifiers that = appear to be OpenID specific, their usage in this specification is actually referring to general OAuth 2.0 features that are not = specific to OpenID Connect.

 

The specification is = available at:

=C2=B7         http://tools.ietf.org/html/draft-jones-oauth-discovery-00

 

An HTML-formatted version is also available at:

=C2=B7         http://self-issued.info/docs/draft-jones-oauth-discovery-00.htm= l

 

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

 

P.S.  This note = was also posted at http://self-issued.info/?p=3D1496 and 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

= --Apple-Mail=_1A35F566-BF9D-426A-B155-C511E62ABF85-- From nobody Wed Nov 25 17:13:45 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2D4C1A87B2 for ; Wed, 25 Nov 2015 17:13:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kf1MLQY8mknb for ; Wed, 25 Nov 2015 17:13:40 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0109.outbound.protection.outlook.com [65.55.169.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D59171A87AE for ; Wed, 25 Nov 2015 17:13:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=1PPau+/ULIw8kZBJFdUeMCeD4QDCPc19XvpvGsrz8O8=; b=mAJsfuzF/OWeBuv1O+LBHXJVixW4qqwmRA8B73ecI+8c+XMppCZgWnTVAweqvwBF/jBJM4IhdoSsssrP++B84DXdxgse7YvyEW8LTl6oXHA9ufO9nzlsqgQrfdEp2EQixKpLd+qQ2Fb7I9ljvuP8YBywJD91hemDkCBi9VNvtQw= Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB444.namprd03.prod.outlook.com (10.141.141.154) with Microsoft SMTP Server (TLS) id 15.1.331.20; Thu, 26 Nov 2015 01:13:35 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0331.023; Thu, 26 Nov 2015 01:13:35 +0000 From: Mike Jones To: John Bradley , William Denniss Thread-Topic: [OAUTH-WG] OAuth Discovery Thread-Index: AdEnv6MqmLA/Ph7MT4qJwfYSFGITHwAHfLyAAAIF0AAAAA2/IA== Date: Thu, 26 Nov 2015 01:13:35 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [50.47.85.157] x-microsoft-exchange-diagnostics: 1; BY2PR03MB444; 5:tM74bfeghdFYVZvtnLKK+PaMvJfjxEwmKREMF+nZYYRazKX4XZarZ69kPOkLmRiYgSTek+7lg3x6FiWI33/4mjtGuF0iCrEuudO/PMUnGQRxKSAFSiBZMF6P3Y1l/XVdnsd4tuq1ZeK4XNa3OFKRWQ==; 24:rb6pPg40mjUiYCfEl9UgezFaQ5KLb7eZymmQ/+CtmBqCxWrx3MBDqV8hnfvtGzmtO5826AXLyvmXlnG2B3/2CA30jWnFifw3lEM1U9yCT/A= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB444; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(211936372134217)(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425024)(601004)(2401047)(520078)(5005006)(8121501046)(3002001)(10201501046)(61426024)(61427024); SRVR:BY2PR03MB444; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB444; x-forefront-prvs: 0772E5DAD5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(209900001)(377454003)(189002)(199003)(51914003)(24454002)(99286002)(5004730100002)(8990500004)(2900100001)(19580405001)(19580395003)(105586002)(40100003)(87936001)(122556002)(66066001)(2950100001)(92566002)(106356001)(74316001)(11100500001)(86362001)(1096002)(19609705001)(19300405004)(86612001)(76176999)(101416001)(189998001)(81156007)(97736004)(5001770100001)(1220700001)(5001960100002)(10090500001)(76576001)(33656002)(5002640100001)(19625215002)(15395725005)(16236675004)(5008740100001)(5003600100002)(15975445007)(5005710100001)(10290500002)(77096005)(54356999)(10400500002)(586003)(19617315012)(6116002)(50986999)(790700001)(102836003)(3846002)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB444; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR03MB4421A1D95F9415936C73C20F5040BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Nov 2015 01:13:35.6571 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB444 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth Discovery X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2015 01:13:44 -0000 --_000_BY2PR03MB4421A1D95F9415936C73C20F5040BY2PR03MB442namprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIGZvciB0aGUgcXVpY2sgZmVlZGJhY2ssIFdpbGxpYW0uICBJIGhhZCBhbG1vc3QgZmlu aXNoZWQgd3JpdGluZyBzaW1pbGFyIGNvbW1lbnRzIHRvIEpvaG7igJlzIHdoZW4gaGlzIHJlcGx5 IGNhbWUgaW4uIDstKQ0KDQpQZXIgeW91ciBzZWNvbmQgcXVlc3Rpb25zLCBmb3IgdGhlIC0wMCBk cmFmdCwgd2UgaW50ZW50aW9uYWxseSBkaWRu4oCZdCBpbnZlbnQgYW55IG5ldyBmdW5jdGlvbmFs aXR5IChvdGhlciB0aGFuIGFkZGluZyByZXZvY2F0aW9uIGFuZCBpbnRyb3NwZWN0aW9uIGVuZHBv aW50IHZhbHVlcykuICBPdGhlciBtZWFucyBvZiBvYnRhaW5pbmcgdGhlIGNvbmZpZ3VyYXRpb24g aW5mb3JtYXRpb24gbG9jYXRpb24gY2FuIGJlIGFkZGVkIGxhdGVyLCBpZiB0aGVyZeKAmXMgY29u c2Vuc3VzIHRvIGRvIHNvLiAgSeKAmWxsIG9ic2VydmUgdGhhdCBpZiB3ZSB3YW50IHRoZSBhdXRo b3JpemF0aW9uIGVuZHBvaW50IHRvIHJldHVybiBzb21ldGhpbmcgYWRkaXRpb25hbCwgdGhhdCBt YXkgYmUgbW9yZSBvZiBhbiBhY3Rpdml0eSB0aGF0IHJldmlzZXMgUkZDIDY3NDkgdGhhbiBhIGRp c2NvdmVyeSBzcGVjIGFjdGl2aXR5LiAgSWYgc28sIHRoZSA2NzQ5YmlzIGNvdWxkIHNwZWNpZnkg dGhhdCBhIFVSTCBmb3IgdGhlIGRpc2NvdmVyeSBpbmZvcm1hdGlvbiBiZSByZXR1cm5lZCB1bmRl ciBzcGVjaWZpYyBjaXJjdW1zdGFuY2VzLg0KDQpKb2hu4oCZcyByaWdodCB0aGF0IHBlb3BsZSBz aG91bGQgdGhpbmsgYWJvdXQgaG93IHRvIGJlc3QgZGVzY3JpYmUgdGhlIOKAnGlzc3VlcuKAnSB2 YWx1ZSBpbiBhIGdlbmVyYWwgT0F1dGggY29udGV4dC4gIFRoZSBzcGVjIGN1cnJlbnRseSBzYXlz IHRoYXQgdGhpcyBsb2NhdGlvbiBpcyB0aGUgcm9vdCBvZiAud2VsbC1rbm93biByZXNvdXJjZXMg Zm9yIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlci4gIFRoYXTigJlzIGNlcnRhaW5seSB0cnVlIGJ1 dCBtYXliZSBub3QgY29tcGxldGVseSBpbnR1aXRpdmVseSBhcHBlYWxpbmcuICBZb3VyIHRob3Vn aHRzIGhvdyB0byBiZXR0ZXIgZGVzY3JpYmUgdGhpcyB3b3VsZCBiZSBhcHByZWNpYXRlZC4NCg0K SGFwcHkgVGhhbmtzZ2l2aW5nIHRvIGFsbCBvZiB5b3UgaW4gdGhlIFVTIQ0KDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0K DQpGcm9tOiBKb2huIEJyYWRsZXkgW21haWx0bzp2ZTdqdGJAdmU3anRiLmNvbV0NClNlbnQ6IFdl ZG5lc2RheSwgTm92ZW1iZXIgMjUsIDIwMTUgNDo1OSBQTQ0KVG86IFdpbGxpYW0gRGVubmlzcyA8 d2Rlbm5pc3NAZ29vZ2xlLmNvbT4NCkNjOiBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jv c29mdC5jb20+OyBvYXV0aEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gT0F1dGgg RGlzY292ZXJ5DQoNCklubGluZQ0KT24gTm92IDI1LCAyMDE1LCBhdCA5OjAxIFBNLCBXaWxsaWFt IERlbm5pc3MgPHdkZW5uaXNzQGdvb2dsZS5jb208bWFpbHRvOndkZW5uaXNzQGdvb2dsZS5jb20+ PiB3cm90ZToNCg0KTG9va3MgZ29vZC4gQSBmZXcgcmV2aWV3IG5vdGVzOg0KDQoxLg0KQ2FuIHdl IGFkZCBhIHhyZWYgdG8gdGhlIFdlYkZpbmdlciBzcGVjIChSRkM3MDMzKSBpbiBzZWN0aW9uIDI/ DQpZZXMgdGhhdCBzaG91bGQgYmUgT0sNCg0KDQoyLg0KSXMgdGhlIG9ubHkgd2F5IHRvIGRpc2Nv dmVyIHRoZSBsb2NhdGlvbiBvZiB0aGUgZGlzY292ZXJ5IGRvY3VtZW50IHZpYSBXZWJGaW5nZXI/ DQoNCkluIFlva29oYW1hIHdlIGFsc28gdGFsa2VkIGFib3V0IHRoZSBBUyByZXR1cm5pbmcgdGhl IGRpc2NvdmVyeSBkb2N1bWVudCBob3N0IChpLmUuIGlzc3Vlcikgb24gdGhlIGF1dGggYW5kIHRv a2VuIGVuZHBvaW50cy4gIFdoYXQgYXJlIHRoZSByZWFzb25zIGZvciBjaG9vc2luZyBXZWJGaW5n ZXIgb3ZlciB0aGF0IG1ldGhvZD8NCg0KVGhpcyBpcyBhIGZpcnN0IGRyYWZ0LCB0aGF0IGlzIGNs b3NlIHRvIHRoZSBDb25uZWN0IERvY3VtZW50LiAgSXQgbmVlZHMgd29yaywgYXJvdW5kIHdoYXQg YSBpc3N1ZXIgKEFTIGlkZW50aXR5KSBpcyBpbiBPQXV0aC4gICBTb21lIG9mIHRoZSBXZWJkaW5n ZXIgc3R1ZmYgaXMgc3RyYW5nZSB3aXRob3V0IGEgc3BlY2lmaWMgQVBJIHRoYXQgeW91IGFyZSBs b29raW5nIGZvci4gICBJdCB3b3VsZCBiZSBvZGQgdG8gbG9vayBmb3Igc29tZW9uZeKAmXMgT0F1 dGggc2VydmVyLiAgSSBjb3VsZCBzZWUgbG9va2luZyBmb3IgYSBwZXJzb25zIFBob3Rvc2hhcmlu ZyBzZXJ2aWNlIGFuZCBnZXR0aW5nIGRpcmVjdGVkIHRvIEl04oCZcyBBUyBkaXNjb3ZlcnkgZG9j dW1lbnQgYXNzdW1pbmcgYSB3ZWxsIGtub3duIEFQSS4NCg0KTmF0IGhhcyBhIHNwZWMgb24gbWV0 YS1kYXRhIGZvciB0aGUgZW5kcG9pbnQgQVBJLiAgIFRoZSBXRyBtYXkgZWxlY3QgdG8gbWVyZ2Ug dGhlbSBvciBrZWVwIHRoZW0gc2VwYXJhdGUuICAgSXQgd291bGQgYmUgdGhlIGVuZHBvaW50IG1l dGEtZGF0YSAoaGVhZGVycykgdGhhdCB3b3VsZCBwb2ludCBhdCB0aGUgZGlzY292ZXJ5IGRvY3Vt ZW50Lg0KDQpUaGlzIGlzIGEgc3RhcnQuDQoNCg0KMy4NCkl0IGxvb2tzIGxpa2UgYW4gSUFOQSBy ZWdpc3RyeSB3YXMgbm90IHNldHVwIGZvciBPcGVuSUQgQ29ubmVjdCBkaXNjb3ZlcnkgcGFyYW1z IChhdCBsZWFzdCwgbm90IGluIHRoYXQgc3BlYykuIElzIHRoZSByZWdpc3RyeSBlc3RhYmxpc2hl ZCBpbiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1qb25lcy1vYXV0aC1kaXNjb3Zl cnktMDAjc2VjdGlvbi04LjEuMiBkZXNpZ25lZCB0byBiZSBhIHNoYXJlZCByZWdpc3RyeSBmb3Ig T0lEQy9PQXV0aCBkaXNjb3Zlcnk/IEFuZCBpZiBzbywgc2hvdWxkIHdlIGFsc28gcmVnaXN0ZXIg dmFsdWVzIGRlZmluZWQgaW4gdGhlIE9JREMgZGlzY292ZXJ5IHNwZWMsIGUuZy4g4oCcc3ViamVj dF90eXBlc19zdXBwb3J0ZWQiDQoNCkkgZXhwZWN0IHRoYXQgbGlrZSByZWdpc3RyYXRpb24sIE9B dXRoIHdvdWxkIGVzdGFibGlzaCB0aGUgcmVnaXN0cnkgYW5kIHJlZ2lzdGVyIGFuIGluaXRpYWwg c2V0LCBhbmQgdGhlbiBDb25uZWN0IHdvdWxkIGFkZCBjb25uZWN0IHNwZWNpZmljIGNsYWltcyB0 byB0aGF0IHJlZ2lzdHJ5IG9uY2UgaXQgaXMgZXN0YWJsaXNoZWQuDQoNCkpvaG4gQi4NCg0KDQpP biBXZWQsIE5vdiAyNSwgMjAxNSBhdCAzOjM3IFBNLCBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVz QG1pY3Jvc29mdC5jb208bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4+IHdyb3Rl Og0KSeKAmW0gcGxlYXNlZCB0byBhbm5vdW5jZSB0aGF0IE5hdCBTYWtpbXVyYSwgSm9obiBCcmFk bGV5LCBhbmQgSSBoYXZlIGNyZWF0ZWQgYW4gT0F1dGggMi4wIERpc2NvdmVyeSBzcGVjaWZpY2F0 aW9uLiAgVGhpcyBmaWxscyBhIGhvbGUgaW4gdGhlIGN1cnJlbnQgT0F1dGggc3BlY2lmaWNhdGlv biBzZXQgdGhhdCBpcyBuZWNlc3NhcnkgdG8gYWNoaWV2ZSBpbnRlcm9wZXJhYmlsaXR5LiAgSW5k ZWVkLCB0aGUgSW50ZXJvcGVyYWJpbGl0eSBzZWN0aW9uIG9mIE9BdXRoIDIuMCA8aHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL3JmYzY3NDkjc2VjdGlvbi0xLjg+IHN0YXRlczoNCg0KSW4gYWRk aXRpb24sIHRoaXMgc3BlY2lmaWNhdGlvbiBsZWF2ZXMgYSBmZXcgcmVxdWlyZWQgY29tcG9uZW50 cyBwYXJ0aWFsbHkgb3IgZnVsbHkgdW5kZWZpbmVkIChlLmcuLCBjbGllbnQgcmVnaXN0cmF0aW9u LCBhdXRob3JpemF0aW9uIHNlcnZlciBjYXBhYmlsaXRpZXMsIGVuZHBvaW50IGRpc2NvdmVyeSku ICBXaXRob3V0IHRoZXNlIGNvbXBvbmVudHMsIGNsaWVudHMgbXVzdCBiZSBtYW51YWxseSBhbmQg c3BlY2lmaWNhbGx5IGNvbmZpZ3VyZWQgYWdhaW5zdCBhIHNwZWNpZmljIGF1dGhvcml6YXRpb24g c2VydmVyIGFuZCByZXNvdXJjZSBzZXJ2ZXIgaW4gb3JkZXIgdG8gaW50ZXJvcGVyYXRlLg0KDQoN Cg0KVGhpcyBmcmFtZXdvcmsgd2FzIGRlc2lnbmVkIHdpdGggdGhlIGNsZWFyIGV4cGVjdGF0aW9u IHRoYXQgZnV0dXJlIHdvcmsgd2lsbCBkZWZpbmUgcHJlc2NyaXB0aXZlIHByb2ZpbGVzIGFuZCBl eHRlbnNpb25zIG5lY2Vzc2FyeSB0byBhY2hpZXZlIGZ1bGwgd2ViLXNjYWxlIGludGVyb3BlcmFi aWxpdHkuDQoNClRoaXMgc3BlY2lmaWNhdGlvbiBlbmFibGVzIGRpc2NvdmVyeSBvZiBib3RoIGVu ZHBvaW50IGxvY2F0aW9ucyBhbmQgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgY2FwYWJpbGl0aWVzLg0K DQpUaGlzIHNwZWNpZmljYXRpb24gaXMgYmFzZWQgdXBvbiB0aGUgYWxyZWFkeSB3aWRlbHkgZGVw bG95ZWQgT3BlbklEIENvbm5lY3QgRGlzY292ZXJ5IDEuMDxodHRwOi8vb3BlbmlkLm5ldC9zcGVj cy9vcGVuaWQtY29ubmVjdC1kaXNjb3ZlcnktMV8wLmh0bWw+IHNwZWNpZmljYXRpb24gYW5kIGlz IGNvbXBhdGlibGUgd2l0aCBpdCwgYnkgZGVzaWduLiAgVGhlIE9BdXRoIERpc2NvdmVyeSBzcGVj IHJlbW92ZXMgdGhlIHBvcnRpb25zIG9mIE9wZW5JRCBDb25uZWN0IERpc2NvdmVyeSB0aGF0IGFy ZSBPcGVuSUQgc3BlY2lmaWMgYW5kIGFkZHMgbWV0YWRhdGEgdmFsdWVzIGZvciBSZXZvY2F0aW9u IGFuZCBJbnRyb3NwZWN0aW9uIGVuZHBvaW50cy4gIEl0IGFsc28gbWFwcyBPcGVuSUQgY29uY2Vw dHMsIHN1Y2ggYXMgT3BlbklEIFByb3ZpZGVyLCBSZWx5aW5nIFBhcnR5LCBFbmQtVXNlciwgYW5k IElzc3VlciB0byB0aGVpciBPQXV0aCB1bmRlcnBpbm5pbmdzLCByZXNwZWN0aXZlbHkgQXV0aG9y aXphdGlvbiBTZXJ2ZXIsIENsaWVudCwgUmVzb3VyY2UgT3duZXIsIGFuZCB0aGUgbmV3bHkgaW50 cm9kdWNlZCBDb25maWd1cmF0aW9uIEluZm9ybWF0aW9uIExvY2F0aW9uLiAgU29tZSBpZGVudGlm aWVycyB3aXRoIG5hbWVzIHRoYXQgYXBwZWFyIHRvIGJlIE9wZW5JRCBzcGVjaWZpYyB3ZXJlIHJl dGFpbmVkIGZvciBjb21wYXRpYmlsaXR5IHB1cnBvc2VzOyBkZXNwaXRlIHRoZSByZXVzZSBvZiB0 aGVzZSBpZGVudGlmaWVycyB0aGF0IGFwcGVhciB0byBiZSBPcGVuSUQgc3BlY2lmaWMsIHRoZWly IHVzYWdlIGluIHRoaXMgc3BlY2lmaWNhdGlvbiBpcyBhY3R1YWxseSByZWZlcnJpbmcgdG8gZ2Vu ZXJhbCBPQXV0aCAyLjAgZmVhdHVyZXMgdGhhdCBhcmUgbm90IHNwZWNpZmljIHRvIE9wZW5JRCBD b25uZWN0Lg0KDQpUaGUgc3BlY2lmaWNhdGlvbiBpcyBhdmFpbGFibGUgYXQ6DQrigKIgICAgICAg ICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1qb25lcy1vYXV0aC1kaXNjb3Zlcnkt MDANCg0KQW4gSFRNTC1mb3JtYXR0ZWQgdmVyc2lvbiBpcyBhbHNvIGF2YWlsYWJsZSBhdDoNCuKA oiAgICAgICAgIGh0dHA6Ly9zZWxmLWlzc3VlZC5pbmZvL2RvY3MvZHJhZnQtam9uZXMtb2F1dGgt ZGlzY292ZXJ5LTAwLmh0bWwNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KUC5TLiAgVGhpcyBub3RlIHdh cyBhbHNvIHBvc3RlZCBhdCBodHRwOi8vc2VsZi1pc3N1ZWQuaW5mby8/cD0xNDk2IGFuZCBhcyBA c2VsZmlzc3VlZDxodHRwczovL3R3aXR0ZXIuY29tL3NlbGZpc3N1ZWQ+Lg0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0 DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3Jn PG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vb2F1dGgNCg0K --_000_BY2PR03MB4421A1D95F9415936C73C20F5040BY2PR03MB442namprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJTZWdvZSBVSSI7 DQoJcGFub3NlLTE6MiAxMSA1IDIgNCAyIDQgMiAyIDM7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5r DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5r OiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7 fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5 bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJp Z2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47 DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJp Zjt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFBy ZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLmhv ZW56Yg0KCXttc28tc3R5bGUtbmFtZTpob2VuemI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt c2VyaWY7DQoJY29sb3I6IzAwMjA2MDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw ZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9 IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9k eSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJX b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMwMDIwNjAiPlRoYW5rcyBmb3IgdGhlIHF1aWNrIGZlZWRiYWNrLCBXaWxsaWFtLiZuYnNwOyBJ IGhhZCBhbG1vc3QgZmluaXNoZWQgd3JpdGluZyBzaW1pbGFyIGNvbW1lbnRzIHRvIEpvaG7igJlz IHdoZW4gaGlzIHJlcGx5IGNhbWUgaW4uIDstKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzAwMjA2MCI+UGVyIHlvdXIgc2Vjb25kIHF1ZXN0aW9ucywgZm9yIHRoZSAtMDAgZHJh ZnQsIHdlIGludGVudGlvbmFsbHkgZGlkbuKAmXQgaW52ZW50IGFueSBuZXcgZnVuY3Rpb25hbGl0 eSAob3RoZXIgdGhhbiBhZGRpbmcgcmV2b2NhdGlvbiBhbmQgaW50cm9zcGVjdGlvbiBlbmRwb2lu dCB2YWx1ZXMpLiZuYnNwOw0KIE90aGVyIG1lYW5zIG9mIG9idGFpbmluZyB0aGUgY29uZmlndXJh dGlvbiBpbmZvcm1hdGlvbiBsb2NhdGlvbiBjYW4gYmUgYWRkZWQgbGF0ZXIsIGlmIHRoZXJl4oCZ cyBjb25zZW5zdXMgdG8gZG8gc28uJm5ic3A7IEnigJlsbCBvYnNlcnZlIHRoYXQgaWYgd2Ugd2Fu dCB0aGUgYXV0aG9yaXphdGlvbiBlbmRwb2ludCB0byByZXR1cm4gc29tZXRoaW5nIGFkZGl0aW9u YWwsIHRoYXQgbWF5IGJlIG1vcmUgb2YgYW4gYWN0aXZpdHkgdGhhdCByZXZpc2VzIFJGQyA2NzQ5 DQogdGhhbiBhIGRpc2NvdmVyeSBzcGVjIGFjdGl2aXR5LiZuYnNwOyBJZiBzbywgdGhlIDY3NDli aXMgY291bGQgc3BlY2lmeSB0aGF0IGEgVVJMIGZvciB0aGUgZGlzY292ZXJ5IGluZm9ybWF0aW9u IGJlIHJldHVybmVkIHVuZGVyIHNwZWNpZmljIGNpcmN1bXN0YW5jZXMuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIw NjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj5Kb2hu4oCZcyByaWdodCB0aGF0IHBlb3BsZSBz aG91bGQgdGhpbmsgYWJvdXQgaG93IHRvIGJlc3QgZGVzY3JpYmUgdGhlIOKAnGlzc3VlcuKAnSB2 YWx1ZSBpbiBhIGdlbmVyYWwgT0F1dGggY29udGV4dC4mbmJzcDsgVGhlIHNwZWMgY3VycmVudGx5 IHNheXMgdGhhdCB0aGlzIGxvY2F0aW9uIGlzDQogdGhlIHJvb3Qgb2YgLndlbGwta25vd24gcmVz b3VyY2VzIGZvciB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIuJm5ic3A7IFRoYXTigJlzIGNlcnRh aW5seSB0cnVlIGJ1dCBtYXliZSBub3QgY29tcGxldGVseSBpbnR1aXRpdmVseSBhcHBlYWxpbmcu Jm5ic3A7IFlvdXIgdGhvdWdodHMgaG93IHRvIGJldHRlciBkZXNjcmliZSB0aGlzIHdvdWxkIGJl IGFwcHJlY2lhdGVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+ SGFwcHkgVGhhbmtzZ2l2aW5nIHRvIGFsbCBvZiB5b3UgaW4gdGhlIFVTITxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAy MDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9w Pg0KPHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbEVuZENvbXBvc2UiPjwvc3Bhbj4NCjxk aXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4w cHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBKb2huIEJy YWRsZXkgW21haWx0bzp2ZTdqdGJAdmU3anRiLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBXZWRu ZXNkYXksIE5vdmVtYmVyIDI1LCAyMDE1IDQ6NTkgUE08YnI+DQo8Yj5Ubzo8L2I+IFdpbGxpYW0g RGVubmlzcyAmbHQ7d2Rlbm5pc3NAZ29vZ2xlLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IE1pa2Ug Sm9uZXMgJmx0O01pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSZndDs7IG9hdXRoQGlldGYub3Jn PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIE9BdXRoIERpc2NvdmVyeTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklubGluZTxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE5vdiAyNSwg MjAxNSwgYXQgOTowMSBQTSwgV2lsbGlhbSBEZW5uaXNzICZsdDs8YSBocmVmPSJtYWlsdG86d2Rl bm5pc3NAZ29vZ2xlLmNvbSI+d2Rlbm5pc3NAZ29vZ2xlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TG9va3MgZ29vZC4gQSBm ZXcgcmV2aWV3IG5vdGVzOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+MS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkNhbiB3ZSBhZGQgYSB4cmVmIHRvIHRoZSBXZWJGaW5nZXIgc3BlYyAoUkZDNzAzMykgaW4g c2VjdGlvbiAyPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WWVzIHRoYXQgc2hvdWxkIGJlIE9LPGJyPg0K PGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Mi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPklzIHRoZSBvbmx5IHdheSB0byBkaXNjb3ZlciB0aGUgbG9jYXRpb24gb2YgdGhl IGRpc2NvdmVyeSBkb2N1bWVudCB2aWEgV2ViRmluZ2VyPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiBZb2tvaGFtYSB3ZSBhbHNvIHRhbGtl ZCBhYm91dCB0aGUgQVMgcmV0dXJuaW5nIHRoZSBkaXNjb3ZlcnkgZG9jdW1lbnQgaG9zdCAoaS5l LiBpc3N1ZXIpIG9uIHRoZSBhdXRoIGFuZCB0b2tlbiBlbmRwb2ludHMuJm5ic3A7IFdoYXQgYXJl IHRoZSByZWFzb25zIGZvciBjaG9vc2luZyBXZWJGaW5nZXIgb3ZlciB0aGF0IG1ldGhvZD88bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBpcyBhIGZpcnN0IGRyYWZ0LCB0aGF0IGlzIGNsb3NlIHRv IHRoZSBDb25uZWN0IERvY3VtZW50LiAmbmJzcDtJdCBuZWVkcyB3b3JrLCBhcm91bmQgd2hhdCBh IGlzc3VlciAoQVMgaWRlbnRpdHkpIGlzIGluIE9BdXRoLiAmbmJzcDsgU29tZSBvZiB0aGUgV2Vi ZGluZ2VyIHN0dWZmIGlzIHN0cmFuZ2Ugd2l0aG91dCBhIHNwZWNpZmljIEFQSSB0aGF0IHlvdSBh cmUgbG9va2luZyBmb3IuICZuYnNwOyBJdCB3b3VsZCBiZSBvZGQgdG8NCiBsb29rIGZvciBzb21l b25l4oCZcyBPQXV0aCBzZXJ2ZXIuICZuYnNwO0kgY291bGQgc2VlIGxvb2tpbmcgZm9yIGEgcGVy c29ucyBQaG90b3NoYXJpbmcgc2VydmljZSBhbmQgZ2V0dGluZyBkaXJlY3RlZCB0byBJdOKAmXMg QVMgZGlzY292ZXJ5IGRvY3VtZW50IGFzc3VtaW5nIGEgd2VsbCBrbm93biBBUEkuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5hdCBoYXMgYSBz cGVjIG9uIG1ldGEtZGF0YSBmb3IgdGhlIGVuZHBvaW50IEFQSS4gJm5ic3A7IFRoZSBXRyBtYXkg ZWxlY3QgdG8gbWVyZ2UgdGhlbSBvciBrZWVwIHRoZW0gc2VwYXJhdGUuICZuYnNwOyBJdCB3b3Vs ZCBiZSB0aGUgZW5kcG9pbnQgbWV0YS1kYXRhIChoZWFkZXJzKSB0aGF0IHdvdWxkIHBvaW50IGF0 IHRoZSBkaXNjb3ZlcnkgZG9jdW1lbnQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgaXMgYSBzdGFydC48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5JdCBsb29rcyBsaWtlIGFuIElBTkEgcmVnaXN0cnkgd2FzIG5vdCBzZXR1cCBmb3IgT3BlbklE IENvbm5lY3QgZGlzY292ZXJ5IHBhcmFtcyAoYXQgbGVhc3QsIG5vdCBpbiB0aGF0IHNwZWMpLiBJ cyB0aGUgcmVnaXN0cnkgZXN0YWJsaXNoZWQgaW4mbmJzcDs8YSBocmVmPSJodHRwOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1qb25lcy1vYXV0aC1kaXNjb3ZlcnktMDAjc2VjdGlvbi04LjEu MiI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtam9uZXMtb2F1dGgtZGlzY292ZXJ5 LTAwI3NlY3Rpb24tOC4xLjI8L2E+DQogZGVzaWduZWQgdG8gYmUgYSBzaGFyZWQgcmVnaXN0cnkg Zm9yIE9JREMvT0F1dGggZGlzY292ZXJ5PyBBbmQgaWYgc28sIHNob3VsZCB3ZSBhbHNvIHJlZ2lz dGVyIHZhbHVlcyBkZWZpbmVkIGluIHRoZSBPSURDIGRpc2NvdmVyeSBzcGVjLCBlLmcuIOKAnHN1 YmplY3RfdHlwZXNfc3VwcG9ydGVkJnF1b3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZXhwZWN0 IHRoYXQgbGlrZSByZWdpc3RyYXRpb24sIE9BdXRoIHdvdWxkIGVzdGFibGlzaCB0aGUgcmVnaXN0 cnkgYW5kIHJlZ2lzdGVyIGFuIGluaXRpYWwgc2V0LCBhbmQgdGhlbiBDb25uZWN0IHdvdWxkIGFk ZCBjb25uZWN0IHNwZWNpZmljIGNsYWltcyB0byB0aGF0IHJlZ2lzdHJ5IG9uY2UgaXQgaXMgZXN0 YWJsaXNoZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkpvaG4gQi48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIE5vdiAyNSwgMjAxNSBhdCAzOjM3IFBNLCBNaWtlIEpv bmVzICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tIiB0YXJn ZXQ9Il9ibGFuayI+TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPC9hPiZndDsgd3JvdGU6PG86 cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0 OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPknigJltIHBsZWFzZWQgdG8gYW5ub3VuY2UgdGhhdCBOYXQgU2FraW11cmEsIEpvaG4g QnJhZGxleSwgYW5kIEkgaGF2ZSBjcmVhdGVkIGFuIE9BdXRoIDIuMCBEaXNjb3Zlcnkgc3BlY2lm aWNhdGlvbi4mbmJzcDsgVGhpcyBmaWxscyBhIGhvbGUgaW4gdGhlIGN1cnJlbnQgT0F1dGggc3Bl Y2lmaWNhdGlvbiBzZXQgdGhhdA0KIGlzIG5lY2Vzc2FyeSB0byBhY2hpZXZlIGludGVyb3BlcmFi aWxpdHkuJm5ic3A7IEluZGVlZCwgdGhlIDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9yZmM2NzQ5I3NlY3Rpb24tMS44IiB0YXJnZXQ9Il9ibGFuayI+DQpJbnRlcm9wZXJhYmls aXR5IHNlY3Rpb24gb2YgT0F1dGggMi4wIDwvYT5zdGF0ZXM6PG86cD48L286cD48L3A+DQo8cHJl IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQiPkluIGFkZGl0aW9uLCB0aGlzIHNwZWNpZmljYXRpb24gbGVhdmVzIGEgZmV3IHJl cXVpcmVkIGNvbXBvbmVudHMgcGFydGlhbGx5IG9yIGZ1bGx5IHVuZGVmaW5lZCAoZS5nLiwgY2xp ZW50IHJlZ2lzdHJhdGlvbiwgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgY2FwYWJpbGl0aWVzLCBlbmRw b2ludCBkaXNjb3ZlcnkpLiZuYnNwOyBXaXRob3V0IHRoZXNlIGNvbXBvbmVudHMsIGNsaWVudHMg bXVzdCBiZSBtYW51YWxseSBhbmQgc3BlY2lmaWNhbGx5IGNvbmZpZ3VyZWQgYWdhaW5zdCBhIHNw ZWNpZmljIGF1dGhvcml6YXRpb24gc2VydmVyIGFuZCByZXNvdXJjZSBzZXJ2ZXIgaW4gb3JkZXIg dG8gaW50ZXJvcGVyYXRlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+VGhpcyBmcmFtZXdv cmsgd2FzIGRlc2lnbmVkIHdpdGggdGhlIGNsZWFyIGV4cGVjdGF0aW9uIHRoYXQgZnV0dXJlIHdv cmsgd2lsbCBkZWZpbmUgcHJlc2NyaXB0aXZlIHByb2ZpbGVzIGFuZCBleHRlbnNpb25zIG5lY2Vz c2FyeSB0byBhY2hpZXZlIGZ1bGwgd2ViLXNjYWxlIGludGVyb3BlcmFiaWxpdHkuPC9zcGFuPjxv OnA+PC9vOnA+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IGxhbmc9IkVOIj5UaGlzIHNwZWNpZmljYXRpb24gZW5hYmxlcyBkaXNjb3Zlcnkgb2YgYm90aCBl bmRwb2ludCBsb2NhdGlvbnMgYW5kIGF1dGhvcml6YXRpb24gc2VydmVyIGNhcGFiaWxpdGllcy48 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9 IkVOIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIGxhbmc9IkVOIj5UaGlzIHNwZWNpZmljYXRpb24gaXMgYmFzZWQgdXBvbiB0aGUgYWxy ZWFkeSB3aWRlbHkgZGVwbG95ZWQNCjxhIGhyZWY9Imh0dHA6Ly9vcGVuaWQubmV0L3NwZWNzL29w ZW5pZC1jb25uZWN0LWRpc2NvdmVyeS0xXzAuaHRtbCIgdGFyZ2V0PSJfYmxhbmsiPg0KT3BlbklE IENvbm5lY3QgRGlzY292ZXJ5IDEuMDwvYT4gc3BlY2lmaWNhdGlvbiBhbmQgaXMgY29tcGF0aWJs ZSB3aXRoIGl0LCBieSBkZXNpZ24uJm5ic3A7IFRoZSBPQXV0aCBEaXNjb3Zlcnkgc3BlYyByZW1v dmVzIHRoZSBwb3J0aW9ucyBvZiBPcGVuSUQgQ29ubmVjdCBEaXNjb3ZlcnkgdGhhdCBhcmUgT3Bl bklEIHNwZWNpZmljIGFuZCBhZGRzIG1ldGFkYXRhIHZhbHVlcyBmb3IgUmV2b2NhdGlvbiBhbmQg SW50cm9zcGVjdGlvbiBlbmRwb2ludHMuJm5ic3A7IEl0DQogYWxzbyBtYXBzIE9wZW5JRCBjb25j ZXB0cywgc3VjaCBhcyBPcGVuSUQgUHJvdmlkZXIsIFJlbHlpbmcgUGFydHksIEVuZC1Vc2VyLCBh bmQgSXNzdWVyIHRvIHRoZWlyIE9BdXRoIHVuZGVycGlubmluZ3MsIHJlc3BlY3RpdmVseSBBdXRo b3JpemF0aW9uIFNlcnZlciwgQ2xpZW50LCBSZXNvdXJjZSBPd25lciwgYW5kIHRoZSBuZXdseSBp bnRyb2R1Y2VkIENvbmZpZ3VyYXRpb24gSW5mb3JtYXRpb24gTG9jYXRpb24uJm5ic3A7IFNvbWUg aWRlbnRpZmllcnMNCiB3aXRoIG5hbWVzIHRoYXQgYXBwZWFyIHRvIGJlIE9wZW5JRCBzcGVjaWZp YyB3ZXJlIHJldGFpbmVkIGZvciBjb21wYXRpYmlsaXR5IHB1cnBvc2VzOyBkZXNwaXRlIHRoZSBy ZXVzZSBvZiB0aGVzZSBpZGVudGlmaWVycyB0aGF0IGFwcGVhciB0byBiZSBPcGVuSUQgc3BlY2lm aWMsIHRoZWlyIHVzYWdlIGluIHRoaXMgc3BlY2lmaWNhdGlvbiBpcyBhY3R1YWxseSByZWZlcnJp bmcgdG8gZ2VuZXJhbCBPQXV0aCAyLjAgZmVhdHVyZXMgdGhhdCBhcmUNCiBub3Qgc3BlY2lmaWMg dG8gT3BlbklEIENvbm5lY3QuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBsYW5nPSJFTiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTiI+VGhlIHNwZWNpZmljYXRpb24gaXMg YXZhaWxhYmxlIGF0Ojwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LWZhbWlseTpTeW1ib2wiPsK3PC9zcGFuPjxz cGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1zaXplOjcuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTiI+PGEg aHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtam9uZXMtb2F1dGgtZGlzY292 ZXJ5LTAwIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt am9uZXMtb2F1dGgtZGlzY292ZXJ5LTAwPC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4iPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4iPkFuIEhUTUwtZm9y bWF0dGVkIHZlcnNpb24gaXMgYWxzbyBhdmFpbGFibGUgYXQ6PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtZmFt aWx5OlN5bWJvbCI+wrc8L3NwYW4+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LXNpemU6Ny4w cHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1NlZ29l IFVJJnF1b3Q7LHNhbnMtc2VyaWYiPjxhIGhyZWY9Imh0dHA6Ly9zZWxmLWlzc3VlZC5pbmZvL2Rv Y3MvZHJhZnQtam9uZXMtb2F1dGgtZGlzY292ZXJ5LTAwLmh0bWwiIHRhcmdldD0iX2JsYW5rIj5o dHRwOi8vc2VsZi1pc3N1ZWQuaW5mby9kb2NzL2RyYWZ0LWpvbmVzLW9hdXRoLWRpc2NvdmVyeS0w MC5odG1sPC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJjb2xvcjojODg4ODg4Ij4mbmJzcDs8L3NwYW4+PHNwYW4g c3R5bGU9ImNvbG9yOiM4ODg4ODgiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJjb2xvcjojODg4ODg4Ij4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9y OiM4ODg4ODgiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gbGFuZz0iRU4iPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4iPlAuUy4mbmJzcDsgVGhpcyBub3RlIHdhcyBhbHNv IHBvc3RlZCBhdA0KPGEgaHJlZj0iaHR0cDovL3NlbGYtaXNzdWVkLmluZm8vP3A9MTQ5NiIgdGFy Z2V0PSJfYmxhbmsiPmh0dHA6Ly9zZWxmLWlzc3VlZC5pbmZvLz9wPTE0OTY8L2E+IGFuZCBhcw0K PGEgaHJlZj0iaHR0cHM6Ly90d2l0dGVyLmNvbS9zZWxmaXNzdWVkIiB0YXJnZXQ9Il9ibGFuayI+ QHNlbGZpc3N1ZWQ8L2E+Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGgg bWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj5PQXV0aEBp ZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9B dXRoQGlldGYub3JnIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BY2PR03MB4421A1D95F9415936C73C20F5040BY2PR03MB442namprd_-- From nobody Wed Nov 25 17:29:32 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E8E11A8835 for ; Wed, 25 Nov 2015 17:29:32 -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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dHVc2rbJLBEs for ; Wed, 25 Nov 2015 17:29:29 -0800 (PST) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::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 DEA241A882E for ; Wed, 25 Nov 2015 17:29:28 -0800 (PST) Received: by wmuu63 with SMTP id u63so3412322wmu.0 for ; Wed, 25 Nov 2015 17:29:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=MP4cTtAyIcpAU83ZkL4fERGXBj3sh7zBXeKm8a5yCyA=; b=BVXDCj1AN2S+Fjge0JMLUCQQpWIM1FgJ25jExzYdOG2PLBFybjHcops+6JYQXZGiQg Yu0RamOINYcEa0LWp/jZZNp7M3NOvlKHEs1QqkmPyeBIpVUaExyj1Gi4IWiky5yI0kZl uGG1hrlUnIgxYPZ/jjtZ72+oNH+GcekvltV2PQujsBn9tezsC8fx5w64iZO6EogUHNFt 0qeJRcz6jd3OriFRMZuAgUtc3u0SK5Vm7+VkiKdHIJxRN/qMCyL60bACp23U7+r3TpD7 0X8M7J40wJjh0jCT235KyroMQOc9BkBg89Z6HspPdTlNsWWITt+DaQQOx8Cj6MTpuX5i fU7Q== MIME-Version: 1.0 X-Received: by 10.28.218.17 with SMTP id r17mr669564wmg.90.1448501367522; Wed, 25 Nov 2015 17:29:27 -0800 (PST) Received: by 10.28.52.130 with HTTP; Wed, 25 Nov 2015 17:29:27 -0800 (PST) In-Reply-To: References: Date: Wed, 25 Nov 2015 20:29:27 -0500 Message-ID: From: Kathleen Moriarty To: Mike Jones Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-proof-of-possession X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2015 01:29:32 -0000 Mike, On Wed, Nov 25, 2015 at 2:26 PM, Mike Jones w= rote: > Hi Kathleen, > > For what it's worth, Pete's ballot on JWT - recorded at http://datatracke= r.ietf.org/doc/rfc7519/ballot/#pete-resnick - consisted entirely of this co= mment: > Others have said all I might say. I do not object to "joots". :-) > > There were things in the JOSE specs that Pete, in the end, abstained on, = but not JWT. I'm not going to dig through all of the discuss comments and emails to find this one as there was huge amounts of overlapping text in each of the drafts and continuing this type of discussion serves no purpose. I continued from John's message as that was more productive. Best regards, Kathleen > > I think we may be talking past each other on the ambiguity that you're re= ferring to. Let me try again. > > In normal uses of JWT, there will be a JWT library (using a JOSE library)= and application-specific code that uses the resulting JWTs. At the JWT li= brary level, yes, stuff that's not understood will be ignored. There's no = ambiguity for JWT implementers on what to do. > > But at the application level, it's entirely within the application's righ= ts to reject a JWT that contains things that don't conform to the applicati= on's specified use of JWT, including rejecting it because things were inclu= ded that it didn't expect. It's the *application* that may choose not to i= gnore some not-understood or not-anticipated values - not the JWT library. = That's what the second paragraph of http://tools.ietf.org/html/rfc7519#sec= tion-4 is talking about and what the equivalent second paragraph of https:/= /tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-07#section-3.1 is= also about. > > If you feel that that point needs further clarification in the draft, I'd= rather that we do that now, than have you submit a ballot that calls out t= he ambiguity that you're referring to, when the situation for JWT implement= ers is actually unambiguous. > > How would you like to proceed? > > -- Mike > > -----Original Message----- > From: Kathleen Moriarty [mailto:kathleen.moriarty.ietf@gmail.com] > Sent: Wednesday, November 25, 2015 6:21 AM > To: Mike Jones > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-proof-of-possession > > Hi Mike, > > If the working group is okay with the current text, leave it. What you p= roposed is exactly the same as what is there. I'll note this point in my b= allot as I think you are leaving ambiguity that is not necessary. > > After getting far enough on this, I think it was Pete who discussed this = with you and he gave up and remained in disagreement. > > Regards, > Kathleen > > Sent from my iPhone > >> On Nov 24, 2015, at 10:25 PM, Mike Jones w= rote: >> >> Rather than elaborating, having looked at the text we're discussing agai= n, I'm going to counter-propose that we instead simplify - sticking only to= the point that the paragraph is intending to get across. Would it work fo= r you to simplify the current text: >> >> "A recipient might not understand the cnf claim, in which case it wil= l typically be ignored. Unless this is acceptable behavior, applications th= at need the proof-of-possession keys communicated with it to be understood = and processed must require that the parts of this specification that they u= se be implemented." >> >> to this simpler text? >> >> "A recipient might not understand the cnf claim. Applications that n= eed the proof-of-possession keys communicated with it to be understood and = processed must require that the parts of this specification that they use b= e implemented." >> >> The "must ignore" topic is already addressed in the second paragraph of = 3.1 (and with exactly the semantics as the rest of JWT), and so doesn't hav= e to be re-raised here, as it currently is. Re-raising it is clearly a poi= nt of distraction. >> >> For what it's worth, I don't remember any DISCUSSes on this topic (altho= ugh it's possible that your memory is better than mine on this point). >> >> Best wishes, >> -- Mike >> >> -----Original Message----- >> From: Kathleen Moriarty [mailto:kathleen.moriarty.ietf@gmail.com] >> Sent: Tuesday, November 24, 2015 7:14 PM >> To: Mike Jones >> Cc: oauth@ietf.org >> Subject: Re: [OAUTH-WG] AD review of >> draft-ietf-oauth-proof-of-possession >> >>> On Tue, Nov 24, 2015 at 10:10 PM, Mike Jones wrote: >>> Fair question about the use of "typically". The reason it's there is t= hat this language in JWT [RFC 7519] Section 4 does permit applications to r= equire that JWTs with not-understood claims be rejected, rather than ignore= d, even though that's not the default behavior: >>> >>> The set of claims that a JWT must contain to be considered valid is >>> context dependent and is outside the scope of this specification. >>> Specific applications of JWTs will require implementations to >>> understand and process some claims in particular ways. However, in >>> the absence of such requirements, all claims that are not understood >>> by implementations MUST be ignored. >>> >>> So when not understood, "cnf" would typically be ignored, but might not= be. >> >> I find that confusing and am now thinking this came up in a discuss as w= ell during the review for 7519, didn't it? Can you elaborate int eh securi= ty considerations section a bit more, otherwise this text appears to be con= flicting and even with what you intend, it's confusing for implementers and= will lead to issues with interoperability. >> >> Thanks, >> Kathleen >> >> >>> >>> -- Mike >>> >>> -----Original Message----- >>> From: Kathleen Moriarty [mailto:kathleen.moriarty.ietf@gmail.com] >>> Sent: Tuesday, November 24, 2015 6:41 PM >>> To: Mike Jones >>> Cc: oauth@ietf.org >>> Subject: Re: [OAUTH-WG] AD review of >>> draft-ietf-oauth-proof-of-possession >>> >>> Hi Mike, >>> >>> Thanks for the quick turn-around. Just one more comment on my comments= . >>> >>>> On Tue, Nov 24, 2015 at 9:10 PM, Mike Jones wrote: >>>> Thanks for your review comments, Kathleen. Responses are inline below= ... >>>> >>>>> -----Original Message----- >>>>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Kathleen >>>>> Moriarty >>>>> Sent: Tuesday, November 24, 2015 9:44 AM >>>>> To: oauth@ietf.org >>>>> Subject: [OAUTH-WG] AD review of >>>>> draft-ietf-oauth-proof-of-possession >>>>> >>>>> Hi, >>>>> >>>>> Thank you all for your work on this draft! I just have a few questio= ns: >>>>> >>>>> 1. Security considerations section says: >>>>> >>>>> "All of the normal security issues, especially in relationship to >>>>> comparing URIs and dealing with unrecognized values, that are >>>>> discussed in JWT [JWT] also apply here." >>>>> >>>>> I find that to be odd phrasing that would likely be picked up in >>>>> subsequent reviews. Please remove the word "normal" so that all of >>>>> the security issues discusses in JWT are included. Are there other >>>>> 'normal considerations in addition to those in JWT that need to be >>>>> listed? The phrasing reads as if that may the case and would be >>>>> better to include them all or pointers or change the phrasing. >>>> >>>> You're right. I removed this awkward wording. >>>> >>>>> 2. Also in the security considerations section, >>>>> >>>>> "A recipient may not understand the newly introduced "cnf" claim an= d >>>>> may consequently treat it as a bearer token." >>>>> >>>>> What is the proper handling requirement when an unknown claim is >>>>> present? Section 3.1 says: >>>>> "When a recipient receives a "cnf" claim with a >>>>> member that it does not understand, it MUST ignore that member." >>>>> >>>>> Is this why it is treated as a bearer token rather than being >>>>> rejected? Is this really the action you want to see with cnf? Why >>>>> isn't there an error and a resend as a bearer token so that parties >>>>> understand (or have an opportunity to understand) that there were iss= ues? >>>>> >>>>> Then the following text in the security section says: >>>>> "While this is a >>>>> legitimate concern, it is outside the scope of this specification, >>>>> since demonstration the possession of the key associated with the >>>>> "cnf" claim is not covered by this specification. For more >>>>> details, >>>>> >>>>> How is this outside of the scope of this draft? cnf is defined in >>>>> this draft, so handling should be covered in this draft. A pointer >>>>> to the POP architecture draft is not helpful as it is not defined >>>>> there, it's covered int his draft. Should this text just be >>>>> removed and replaced with more explicit handling information int he b= ody of this draft? >>>> >>>> Good catch. JWT [RFC 7519] Section 4 says that claims that are not un= derstood must be ignored unless otherwise specified by the application. Th= is allows new claims to be dynamically added without breaking existing appl= ications. For the same reason, I have incorporated this language about und= erstanding claims from 7519, but having it be about understanding confirmat= ion members. Ultimately, what features must be implemented are always up t= o the application, just as with JWT claims. >>> >>> The new text in Section 3.1 looks good. I'm not sure why the word "typ= ically" appears int he new text of the security considerations section thou= gh after reading the new text in 3.1. Wouldn't it just be ignored since 3.= 1 now says: >>> >>> "However, in the absence of such requirements, >>> all confirmation members that are not understood by implementations >>> MUST be ignored." >>> >>> Thanks, >>> Kathleen >>> >>> >>>> >>>>> Thanks! >>>>> >>>>> -- >>>>> >>>>> Best regards, >>>>> Kathleen >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> Thanks again, >>>> -- Mike >>> >>> >>> >>> -- >>> >>> Best regards, >>> Kathleen >> >> >> >> -- >> >> Best regards, >> Kathleen --=20 Best regards, Kathleen From nobody Wed Nov 25 22:59:57 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69CC71AD2EC for ; Wed, 25 Nov 2015 22:59:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KlRTjlEBedkj for ; Wed, 25 Nov 2015 22:59:52 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0713.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:713]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C29FF1AD359 for ; Wed, 25 Nov 2015 22:59:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=iD4TLIjPtWJXAShXgaZj+1iRKXk60642DE49q9f9bto=; b=gH7X0iv8kmmSS1IN5vdWhyJJK9+hL1y2P8xpW+C1aRbr9gXpgGwuHmYDM6Em22RgyMQZPWKR7odH4Nd7TPwjkNq+F4HBNbavPBNfWYeoyYStlDdGl8xsTzID/ruiKMzsUAvCQOqksEDgNVNWrL+ai9M3ltujkKXMcWR+3/iiefQ= Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB444.namprd03.prod.outlook.com (10.141.141.154) with Microsoft SMTP Server (TLS) id 15.1.331.20; Thu, 26 Nov 2015 06:59:32 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0331.023; Thu, 26 Nov 2015 06:59:32 +0000 From: Mike Jones To: Kathleen Moriarty , John Bradley Thread-Topic: [OAUTH-WG] AD review of draft-ietf-oauth-proof-of-possession Thread-Index: AQHRJt++kWDp0FqlfEmPEzc+Ih7voJ6r6UxQgAAee4CAAAb2QIAAAjcAgAAA9fCAATSGAIAACKkAgACR9ZA= Date: Thu, 26 Nov 2015 06:59:31 +0000 Message-ID: References: <4AF8FE9C-3484-410B-B52F-C1F9706B18A5@ve7jtb.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [50.47.85.157] x-microsoft-exchange-diagnostics: 1; BY2PR03MB444; 5:jCZvxYRftXBHlZoBYBkaiLBlk4oQClq5g+R+iUROg5M/Rkrpv1++DUtIxF6SXIMTE2kxc78HST50YlLEYwOXraA7rnAMQC/k0m5u3rLOVh9Fk3olfgLxl5wbDeUziG/YnGIMNmcFCaQaYVS7funeww==; 24:JvaSKzpWZzzgUrzlfqiOFC8SOp26yegEmfHXwdAVSjtzdlnbl1i4rft8FKe28oBHxZg8JMxT0QQLKWf0kuqLkv9CbgFuCkVI3DcwgQdT+JA= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB444; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425024)(601004)(2401047)(8121501046)(5005006)(520078)(10201501046)(3002001)(61426024)(61427024); SRVR:BY2PR03MB444; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB444; x-forefront-prvs: 0772E5DAD5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(6009001)(164054003)(13464003)(24454002)(51914003)(43784003)(377454003)(199003)(189002)(5008740100001)(33656002)(5002640100001)(5003600100002)(15975445007)(10090500001)(5001770100001)(97736004)(1220700001)(5001960100002)(76576001)(6116002)(3846002)(81156007)(102836003)(50986999)(77096005)(5005710100001)(10290500002)(10400500002)(586003)(54356999)(66066001)(2950100001)(106116001)(87936001)(106356001)(92566002)(105586002)(230783001)(5004730100002)(8990500004)(2900100001)(99286002)(40100003)(93886004)(19580405001)(19580395003)(101416001)(76176999)(189998001)(86612001)(86362001)(74316001)(11100500001)(1096002)(122556002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB444; H:BY2PR03MB442.namprd03.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:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Nov 2015 06:59:31.5424 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB444 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-proof-of-possession X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2015 06:59:55 -0000 SSBoYWRuJ3Qgc2VlbiB0aGlzIHBhcnQgb2YgdGhlIHRocmVhZCB1bnRpbCBub3cuICAoSSB0aG91 Z2h0IGl0IHdhcyBwYXJ0IG9mIHRoZSB2b2x1bWlub3VzIHRocmVhZCBvbiB0aGUgUG9QIGFyY2hp dGVjdHVyZSBkb2N1bWVudC4pDQoNClRoZSAibWF5IGFjY2VwdCBKV1QgY29udGFpbmluZyDigJxj bmbigJ0gZWxlbWVudHMiIGxhbmd1YWdlIHNvdW5kcyBsaWtlIGl0J3MgZ2l2aW5nIGFwcGxpY2F0 aW9ucyBwZXJtaXNzaW9uIHRvIGRvIHRoaXMuICBJcyB0aGF0IHRoZSBpbnRlbnQgb2YgdGhlIGxh bmd1YWdlIHlvdSBwcm9wb3NlZCwgb3Igd2VyZSB5b3UgaW50ZW5kaW5nIHNvbWV0aGluZyBkaWZm ZXJlbnQsIEpvaG4/DQoNCkFsc28sIGNhbiB5b3UgZXhwYW5kIG9uIHRoZSAicHNldWRvIGF1ZGll bmNlIiBpZGVhPyAgSW4gd2hhdCB3YXkgbWlnaHQgYSBwcm9vZi1vZi1wb3NzZXNzaW9uIGJlIGNv bmZ1c2VkIHdpdGggYW4gYXVkaWVuY2U/DQoNCgkJCQlUaGFua3MsDQoJCQkJLS0gTWlrZQ0KDQot LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogS2F0aGxlZW4gTW9yaWFydHkgW21haWx0 bzprYXRobGVlbi5tb3JpYXJ0eS5pZXRmQGdtYWlsLmNvbV0gDQpTZW50OiBXZWRuZXNkYXksIE5v dmVtYmVyIDI1LCAyMDE1IDI6MTMgUE0NClRvOiBKb2huIEJyYWRsZXkgPHZlN2p0YkB2ZTdqdGIu Y29tPg0KQ2M6IE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT47IG9hdXRo QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBBRCByZXZpZXcgb2YgZHJhZnQtaWV0 Zi1vYXV0aC1wcm9vZi1vZi1wb3NzZXNzaW9uDQoNClRoYW5rcywgSm9obiENCg0KT24gV2VkLCBO b3YgMjUsIDIwMTUgYXQgNDo0MSBQTSwgSm9obiBCcmFkbGV5IDx2ZTdqdGJAdmU3anRiLmNvbT4g d3JvdGU6DQo+IEkgcHJlZmVyIHRoZSBuZXcgd29yZGluZy4NCj4NCj4gSG93ZXZlciB0aGUgbGFz dCBwYXJ0IGNvdWxkIGJlIGNsZWFyZXIuDQo+PiAgdXNlIGJlIGltcGxlbWVudGVkIGJ5IHJlY2lw aWVudHMuDQo+DQo+IE9yIHBlcmhhcHMgdGhlIGJsdW50ZXIg4oCcUmVjaXBpZW50cyBvbmx5IHVu ZGVyc3RhbmRpbmcgYmVhcmVyIHRva2VucyBtYXkgYWNjZXB0IEpXVCBjb250YWluaW5nIOKAnGNu ZuKAnSBlbGVtZW50cyBpZiBhbGwgdGhlIG90aGVyIHJlcXVpcmVkIGNsYWltcyBhcmUgdmFsaWQu ICBJdCBpcyBpbXBvcnRhbnQgZm9yIHNlY3VyaXR5IHRvIGF1ZGllbmNlIHJlc3RyaWN0IHRva2Vu cyB1c2luZyB0aGUgSldUIOKAnGF1ZCBjbGFpbS4gIFRoZSDigJxjbmbigJ0gY2xhaW0gTVVTVCBO T1QgYmUgdXNlZCBhcyBhIHBzZXVkbyBhdWRpZW5jZSByZXN0cmljdGlvbi7igJ0NCg0KTW9yZSBl eHBsaWNpdCB0ZXh0IGxpa2UgdGhpcyBpcyBpcyBtb3JlIGhlbHBmdWwgaW4gbXkgb3Bpbmlvbi4N Cg0KS2F0aGxlZW4NCj4NCj4gTG9va2luZyBhdCB0aGUgY29tbWVudHMsIEkgZ2V0IHRoZSBmZWVs aW5nIHRoYXQgc29tZSBwZW9wbGUgbWlnaHQgdGhpbmsgdGhhdCBjbmYgbWF5IHJlc3RyaWN0IHdo YXQgZW5kcG9pbnRzIGNhbiByZWNlaXZlIHRoZSB0b2tlbiAoYmVjYXVzZSBvZiB0aGUga2V5IGRp c3RyaWJ1dGlvbikgIGl0IG9ubHkgYWxsb3dzIGVuZHBvaW50cyB0aGF0IHNob3VsZCByZWNlaXZl IHRoZSB0b2tlbiB0byByZWplY3Qgb25lcyB0aGF0IGNvbWUgZnJvbSBlbnRpdGllcyB3aG8gZG9u 4oCZdCBwb3NzZXNzIHRoZSBjb3JyZWN0IGNvbmZpcm1hdGlvbi4NCj4NCj4gSm9obiBCLg0KPg0K Pj4gT24gTm92IDI1LCAyMDE1LCBhdCAxMjoyNSBBTSwgTWlrZSBKb25lcyA8TWljaGFlbC5Kb25l c0BtaWNyb3NvZnQuY29tPiB3cm90ZToNCj4+DQo+PiBSYXRoZXIgdGhhbiBlbGFib3JhdGluZywg aGF2aW5nIGxvb2tlZCBhdCB0aGUgdGV4dCB3ZSdyZSBkaXNjdXNzaW5nIGFnYWluLCBJJ20gZ29p bmcgdG8gY291bnRlci1wcm9wb3NlIHRoYXQgd2UgaW5zdGVhZCBzaW1wbGlmeSAtIHN0aWNraW5n IG9ubHkgdG8gdGhlIHBvaW50IHRoYXQgdGhlIHBhcmFncmFwaCBpcyBpbnRlbmRpbmcgdG8gZ2V0 IGFjcm9zcy4gIFdvdWxkIGl0IHdvcmsgZm9yIHlvdSB0byBzaW1wbGlmeSB0aGUgY3VycmVudCB0 ZXh0Og0KPj4NCj4+ICAgICJBIHJlY2lwaWVudCBtaWdodCBub3QgdW5kZXJzdGFuZCB0aGUgY25m IGNsYWltLCBpbiB3aGljaCBjYXNlIGl0IHdpbGwgdHlwaWNhbGx5IGJlIGlnbm9yZWQuIFVubGVz cyB0aGlzIGlzIGFjY2VwdGFibGUgYmVoYXZpb3IsIGFwcGxpY2F0aW9ucyB0aGF0IG5lZWQgdGhl IHByb29mLW9mLXBvc3Nlc3Npb24ga2V5cyBjb21tdW5pY2F0ZWQgd2l0aCBpdCB0byBiZSB1bmRl cnN0b29kIGFuZCBwcm9jZXNzZWQgbXVzdCByZXF1aXJlIHRoYXQgdGhlIHBhcnRzIG9mIHRoaXMg c3BlY2lmaWNhdGlvbiB0aGF0IHRoZXkgdXNlIGJlIGltcGxlbWVudGVkLiINCj4+DQo+PiB0byB0 aGlzIHNpbXBsZXIgdGV4dD8NCj4+DQo+PiAgICAiQSByZWNpcGllbnQgbWlnaHQgbm90IHVuZGVy c3RhbmQgdGhlIGNuZiBjbGFpbS4gIEFwcGxpY2F0aW9ucyB0aGF0IG5lZWQgdGhlIHByb29mLW9m LXBvc3Nlc3Npb24ga2V5cyBjb21tdW5pY2F0ZWQgd2l0aCBpdCB0byBiZSB1bmRlcnN0b29kIGFu ZCBwcm9jZXNzZWQgbXVzdCByZXF1aXJlIHRoYXQgdGhlIHBhcnRzIG9mIHRoaXMgc3BlY2lmaWNh dGlvbiB0aGF0IHRoZXkgdXNlIGJlIGltcGxlbWVudGVkLiINCj4+DQo+PiBUaGUgIm11c3QgaWdu b3JlIiB0b3BpYyBpcyBhbHJlYWR5IGFkZHJlc3NlZCBpbiB0aGUgc2Vjb25kIHBhcmFncmFwaCBv ZiAzLjEgKGFuZCB3aXRoIGV4YWN0bHkgdGhlIHNlbWFudGljcyBhcyB0aGUgcmVzdCBvZiBKV1Qp LCBhbmQgc28gZG9lc24ndCBoYXZlIHRvIGJlIHJlLXJhaXNlZCBoZXJlLCBhcyBpdCBjdXJyZW50 bHkgaXMuICBSZS1yYWlzaW5nIGl0IGlzIGNsZWFybHkgYSBwb2ludCBvZiBkaXN0cmFjdGlvbi4N Cj4+DQo+PiBGb3Igd2hhdCBpdCdzIHdvcnRoLCBJIGRvbid0IHJlbWVtYmVyIGFueSBESVNDVVNT ZXMgb24gdGhpcyB0b3BpYyAoYWx0aG91Z2ggaXQncyBwb3NzaWJsZSB0aGF0IHlvdXIgbWVtb3J5 IGlzIGJldHRlciB0aGFuIG1pbmUgb24gdGhpcyBwb2ludCkuDQo+Pg0KPj4gICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgQmVzdCB3aXNoZXMsDQo+PiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAtLSBNaWtlDQo+Pg0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZy b206IEthdGhsZWVuIE1vcmlhcnR5IFttYWlsdG86a2F0aGxlZW4ubW9yaWFydHkuaWV0ZkBnbWFp bC5jb21dDQo+PiBTZW50OiBUdWVzZGF5LCBOb3ZlbWJlciAyNCwgMjAxNSA3OjE0IFBNDQo+PiBU bzogTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPg0KPj4gQ2M6IG9hdXRo QGlldGYub3JnDQo+PiBTdWJqZWN0OiBSZTogW09BVVRILVdHXSBBRCByZXZpZXcgb2YgDQo+PiBk cmFmdC1pZXRmLW9hdXRoLXByb29mLW9mLXBvc3Nlc3Npb24NCj4+DQo+PiBPbiBUdWUsIE5vdiAy NCwgMjAxNSBhdCAxMDoxMCBQTSwgTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQu Y29tPiB3cm90ZToNCj4+PiBGYWlyIHF1ZXN0aW9uIGFib3V0IHRoZSB1c2Ugb2YgInR5cGljYWxs eSIuICBUaGUgcmVhc29uIGl0J3MgdGhlcmUgaXMgdGhhdCB0aGlzIGxhbmd1YWdlIGluIEpXVCBb UkZDIDc1MTldIFNlY3Rpb24gNCBkb2VzIHBlcm1pdCBhcHBsaWNhdGlvbnMgdG8gcmVxdWlyZSB0 aGF0IEpXVHMgd2l0aCBub3QtdW5kZXJzdG9vZCBjbGFpbXMgYmUgcmVqZWN0ZWQsIHJhdGhlciB0 aGFuIGlnbm9yZWQsIGV2ZW4gdGhvdWdoIHRoYXQncyBub3QgdGhlIGRlZmF1bHQgYmVoYXZpb3I6 DQo+Pj4NCj4+PiAgIFRoZSBzZXQgb2YgY2xhaW1zIHRoYXQgYSBKV1QgbXVzdCBjb250YWluIHRv IGJlIGNvbnNpZGVyZWQgdmFsaWQgaXMNCj4+PiAgIGNvbnRleHQgZGVwZW5kZW50IGFuZCBpcyBv dXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzIHNwZWNpZmljYXRpb24uDQo+Pj4gICBTcGVjaWZpYyBh cHBsaWNhdGlvbnMgb2YgSldUcyB3aWxsIHJlcXVpcmUgaW1wbGVtZW50YXRpb25zIHRvDQo+Pj4g ICB1bmRlcnN0YW5kIGFuZCBwcm9jZXNzIHNvbWUgY2xhaW1zIGluIHBhcnRpY3VsYXIgd2F5cy4g IEhvd2V2ZXIsIGluDQo+Pj4gICB0aGUgYWJzZW5jZSBvZiBzdWNoIHJlcXVpcmVtZW50cywgYWxs IGNsYWltcyB0aGF0IGFyZSBub3QgdW5kZXJzdG9vZA0KPj4+ICAgYnkgaW1wbGVtZW50YXRpb25z IE1VU1QgYmUgaWdub3JlZC4NCj4+Pg0KPj4+IFNvIHdoZW4gbm90IHVuZGVyc3Rvb2QsICJjbmYi IHdvdWxkIHR5cGljYWxseSBiZSBpZ25vcmVkLCBidXQgbWlnaHQgbm90IGJlLg0KPj4NCj4+IEkg ZmluZCB0aGF0IGNvbmZ1c2luZyBhbmQgYW0gbm93IHRoaW5raW5nIHRoaXMgY2FtZSB1cCBpbiBh IGRpc2N1c3MgYXMgd2VsbCBkdXJpbmcgdGhlIHJldmlldyBmb3IgNzUxOSwgZGlkbid0IGl0PyAg Q2FuIHlvdSBlbGFib3JhdGUgaW50IGVoIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHNlY3Rpb24g YSBiaXQgbW9yZSwgb3RoZXJ3aXNlIHRoaXMgdGV4dCBhcHBlYXJzIHRvIGJlIGNvbmZsaWN0aW5n IGFuZCBldmVuIHdpdGggd2hhdCB5b3UgaW50ZW5kLCBpdCdzIGNvbmZ1c2luZyBmb3IgaW1wbGVt ZW50ZXJzIGFuZCB3aWxsIGxlYWQgdG8gaXNzdWVzIHdpdGggaW50ZXJvcGVyYWJpbGl0eS4NCj4+ DQo+PiBUaGFua3MsDQo+PiBLYXRobGVlbg0KPj4NCj4+DQo+Pj4NCj4+PiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KPj4+DQo+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4+PiBGcm9tOiBLYXRobGVlbiBNb3JpYXJ0eSBbbWFpbHRvOmthdGhsZWVuLm1vcmlh cnR5LmlldGZAZ21haWwuY29tXQ0KPj4+IFNlbnQ6IFR1ZXNkYXksIE5vdmVtYmVyIDI0LCAyMDE1 IDY6NDEgUE0NCj4+PiBUbzogTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29t Pg0KPj4+IENjOiBvYXV0aEBpZXRmLm9yZw0KPj4+IFN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIEFE IHJldmlldyBvZiANCj4+PiBkcmFmdC1pZXRmLW9hdXRoLXByb29mLW9mLXBvc3Nlc3Npb24NCj4+ Pg0KPj4+IEhpIE1pa2UsDQo+Pj4NCj4+PiBUaGFua3MgZm9yIHRoZSBxdWljayB0dXJuLWFyb3Vu ZC4gIEp1c3Qgb25lIG1vcmUgY29tbWVudCBvbiBteSBjb21tZW50cy4NCj4+Pg0KPj4+IE9uIFR1 ZSwgTm92IDI0LCAyMDE1IGF0IDk6MTAgUE0sIE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWlj cm9zb2Z0LmNvbT4gd3JvdGU6DQo+Pj4+IFRoYW5rcyBmb3IgeW91ciByZXZpZXcgY29tbWVudHMs IEthdGhsZWVuLiAgUmVzcG9uc2VzIGFyZSBpbmxpbmUgYmVsb3cuLi4NCj4+Pj4NCj4+Pj4+IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+PiBGcm9tOiBPQXV0aCBbbWFpbHRvOm9hdXRo LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBLYXRobGVlbiANCj4+Pj4+IE1vcmlhcnR5 DQo+Pj4+PiBTZW50OiBUdWVzZGF5LCBOb3ZlbWJlciAyNCwgMjAxNSA5OjQ0IEFNDQo+Pj4+PiBU bzogb2F1dGhAaWV0Zi5vcmcNCj4+Pj4+IFN1YmplY3Q6IFtPQVVUSC1XR10gQUQgcmV2aWV3IG9m DQo+Pj4+PiBkcmFmdC1pZXRmLW9hdXRoLXByb29mLW9mLXBvc3Nlc3Npb24NCj4+Pj4+DQo+Pj4+ PiBIaSwNCj4+Pj4+DQo+Pj4+PiBUaGFuayB5b3UgYWxsIGZvciB5b3VyIHdvcmsgb24gdGhpcyBk cmFmdCEgIEkganVzdCBoYXZlIGEgZmV3IHF1ZXN0aW9uczoNCj4+Pj4+DQo+Pj4+PiAxLiBTZWN1 cml0eSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uIHNheXM6DQo+Pj4+Pg0KPj4+Pj4gIkFsbCBvZiB0 aGUgbm9ybWFsIHNlY3VyaXR5IGlzc3VlcywgZXNwZWNpYWxseSBpbiByZWxhdGlvbnNoaXAgdG8N Cj4+Pj4+ICAgY29tcGFyaW5nIFVSSXMgYW5kIGRlYWxpbmcgd2l0aCB1bnJlY29nbml6ZWQgdmFs dWVzLCB0aGF0IGFyZQ0KPj4+Pj4gICBkaXNjdXNzZWQgaW4gSldUIFtKV1RdIGFsc28gYXBwbHkg aGVyZS4iDQo+Pj4+Pg0KPj4+Pj4gSSBmaW5kIHRoYXQgdG8gYmUgb2RkIHBocmFzaW5nIHRoYXQg d291bGQgbGlrZWx5IGJlIHBpY2tlZCB1cCBpbiANCj4+Pj4+IHN1YnNlcXVlbnQgcmV2aWV3cy4g IFBsZWFzZSByZW1vdmUgdGhlIHdvcmQgIm5vcm1hbCIgc28gdGhhdCBhbGwgDQo+Pj4+PiBvZiB0 aGUgc2VjdXJpdHkgaXNzdWVzIGRpc2N1c3NlcyBpbiBKV1QgYXJlIGluY2x1ZGVkLiAgQXJlIHRo ZXJlIA0KPj4+Pj4gb3RoZXIgJ25vcm1hbCBjb25zaWRlcmF0aW9ucyBpbiBhZGRpdGlvbiB0byB0 aG9zZSBpbiBKV1QgdGhhdCBuZWVkIA0KPj4+Pj4gdG8gYmUgbGlzdGVkPyAgVGhlIHBocmFzaW5n IHJlYWRzIGFzIGlmIHRoYXQgbWF5IHRoZSBjYXNlIGFuZCANCj4+Pj4+IHdvdWxkIGJlIGJldHRl ciB0byBpbmNsdWRlIHRoZW0gYWxsIG9yIHBvaW50ZXJzIG9yIGNoYW5nZSB0aGUgcGhyYXNpbmcu DQo+Pj4+DQo+Pj4+IFlvdSdyZSByaWdodC4gIEkgcmVtb3ZlZCB0aGlzIGF3a3dhcmQgd29yZGlu Zy4NCj4+Pj4NCj4+Pj4+IDIuIEFsc28gaW4gdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHNl Y3Rpb24sDQo+Pj4+Pg0KPj4+Pj4gICAiQSByZWNpcGllbnQgbWF5IG5vdCB1bmRlcnN0YW5kIHRo ZSBuZXdseSBpbnRyb2R1Y2VkICJjbmYiIGNsYWltIGFuZA0KPj4+Pj4gICBtYXkgY29uc2VxdWVu dGx5IHRyZWF0IGl0IGFzIGEgYmVhcmVyIHRva2VuLiINCj4+Pj4+DQo+Pj4+PiBXaGF0IGlzIHRo ZSBwcm9wZXIgaGFuZGxpbmcgcmVxdWlyZW1lbnQgd2hlbiBhbiB1bmtub3duIGNsYWltIGlzIA0K Pj4+Pj4gcHJlc2VudD8gIFNlY3Rpb24gMy4xIHNheXM6DQo+Pj4+PiAgIldoZW4gYSByZWNpcGll bnQgcmVjZWl2ZXMgYSAiY25mIiBjbGFpbSB3aXRoIGENCj4+Pj4+ICAgbWVtYmVyIHRoYXQgaXQg ZG9lcyBub3QgdW5kZXJzdGFuZCwgaXQgTVVTVCBpZ25vcmUgdGhhdCBtZW1iZXIuIg0KPj4+Pj4N Cj4+Pj4+IElzIHRoaXMgd2h5IGl0IGlzIHRyZWF0ZWQgYXMgYSBiZWFyZXIgdG9rZW4gcmF0aGVy IHRoYW4gYmVpbmcgDQo+Pj4+PiByZWplY3RlZD8gIElzIHRoaXMgcmVhbGx5IHRoZSBhY3Rpb24g eW91IHdhbnQgdG8gc2VlIHdpdGggY25mPyAgDQo+Pj4+PiBXaHkgaXNuJ3QgdGhlcmUgYW4gZXJy b3IgYW5kIGEgcmVzZW5kIGFzIGEgYmVhcmVyIHRva2VuIHNvIHRoYXQgDQo+Pj4+PiBwYXJ0aWVz IHVuZGVyc3RhbmQgKG9yIGhhdmUgYW4gb3Bwb3J0dW5pdHkgdG8gdW5kZXJzdGFuZCkgdGhhdCB0 aGVyZSB3ZXJlIGlzc3Vlcz8NCj4+Pj4+DQo+Pj4+PiBUaGVuIHRoZSBmb2xsb3dpbmcgdGV4dCBp biB0aGUgc2VjdXJpdHkgc2VjdGlvbiBzYXlzOg0KPj4+Pj4gICJXaGlsZSB0aGlzIGlzIGENCj4+ Pj4+ICAgbGVnaXRpbWF0ZSBjb25jZXJuLCBpdCBpcyBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlz IHNwZWNpZmljYXRpb24sDQo+Pj4+PiAgIHNpbmNlIGRlbW9uc3RyYXRpb24gdGhlIHBvc3Nlc3Np b24gb2YgdGhlIGtleSBhc3NvY2lhdGVkIHdpdGggdGhlDQo+Pj4+PiAgICJjbmYiIGNsYWltIGlz IG5vdCBjb3ZlcmVkIGJ5IHRoaXMgc3BlY2lmaWNhdGlvbi4gRm9yIG1vcmUgDQo+Pj4+PiBkZXRh aWxzLA0KPj4+Pj4NCj4+Pj4+IEhvdyBpcyB0aGlzIG91dHNpZGUgb2YgdGhlIHNjb3BlIG9mIHRo aXMgZHJhZnQ/ICBjbmYgaXMgZGVmaW5lZCBpbiANCj4+Pj4+IHRoaXMgZHJhZnQsIHNvIGhhbmRs aW5nIHNob3VsZCBiZSBjb3ZlcmVkIGluIHRoaXMgZHJhZnQuICBBIA0KPj4+Pj4gcG9pbnRlciB0 byB0aGUgUE9QIGFyY2hpdGVjdHVyZSBkcmFmdCBpcyBub3QgaGVscGZ1bCBhcyBpdCBpcyBub3Qg DQo+Pj4+PiBkZWZpbmVkIHRoZXJlLCBpdCdzIGNvdmVyZWQgaW50IGhpcyBkcmFmdC4gIFNob3Vs ZCB0aGlzIHRleHQganVzdCANCj4+Pj4+IGJlIHJlbW92ZWQgYW5kIHJlcGxhY2VkIHdpdGggbW9y ZSBleHBsaWNpdCBoYW5kbGluZyBpbmZvcm1hdGlvbiBpbnQgaGUgYm9keSBvZiB0aGlzIGRyYWZ0 Pw0KPj4+Pg0KPj4+PiBHb29kIGNhdGNoLiAgSldUIFtSRkMgNzUxOV0gU2VjdGlvbiA0IHNheXMg dGhhdCBjbGFpbXMgdGhhdCBhcmUgbm90IHVuZGVyc3Rvb2QgbXVzdCBiZSBpZ25vcmVkIHVubGVz cyBvdGhlcndpc2Ugc3BlY2lmaWVkIGJ5IHRoZSBhcHBsaWNhdGlvbi4gIFRoaXMgYWxsb3dzIG5l dyBjbGFpbXMgdG8gYmUgZHluYW1pY2FsbHkgYWRkZWQgd2l0aG91dCBicmVha2luZyBleGlzdGlu ZyBhcHBsaWNhdGlvbnMuICBGb3IgdGhlIHNhbWUgcmVhc29uLCBJIGhhdmUgaW5jb3Jwb3JhdGVk IHRoaXMgbGFuZ3VhZ2UgYWJvdXQgdW5kZXJzdGFuZGluZyBjbGFpbXMgZnJvbSA3NTE5LCBidXQg aGF2aW5nIGl0IGJlIGFib3V0IHVuZGVyc3RhbmRpbmcgY29uZmlybWF0aW9uIG1lbWJlcnMuICBV bHRpbWF0ZWx5LCB3aGF0IGZlYXR1cmVzIG11c3QgYmUgaW1wbGVtZW50ZWQgYXJlIGFsd2F5cyB1 cCB0byB0aGUgYXBwbGljYXRpb24sIGp1c3QgYXMgd2l0aCBKV1QgY2xhaW1zLg0KPj4+DQo+Pj4g VGhlIG5ldyB0ZXh0IGluIFNlY3Rpb24gMy4xIGxvb2tzIGdvb2QuICBJJ20gbm90IHN1cmUgd2h5 IHRoZSB3b3JkICJ0eXBpY2FsbHkiIGFwcGVhcnMgaW50IGhlIG5ldyB0ZXh0IG9mIHRoZSBzZWN1 cml0eSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uIHRob3VnaCBhZnRlciByZWFkaW5nIHRoZSBuZXcg dGV4dCBpbiAzLjEuICBXb3VsZG4ndCBpdCBqdXN0IGJlIGlnbm9yZWQgc2luY2UgMy4xIG5vdyBz YXlzOg0KPj4+DQo+Pj4gICAiSG93ZXZlciwgaW4gdGhlIGFic2VuY2Ugb2Ygc3VjaCByZXF1aXJl bWVudHMsDQo+Pj4gICAgYWxsIGNvbmZpcm1hdGlvbiBtZW1iZXJzIHRoYXQgYXJlIG5vdCB1bmRl cnN0b29kIGJ5IGltcGxlbWVudGF0aW9ucw0KPj4+ICAgIE1VU1QgYmUgaWdub3JlZC4iDQo+Pj4N Cj4+PiBUaGFua3MsDQo+Pj4gS2F0aGxlZW4NCj4+Pg0KPj4+DQo+Pj4+DQo+Pj4+PiBUaGFua3Mh DQo+Pj4+Pg0KPj4+Pj4gLS0NCj4+Pj4+DQo+Pj4+PiBCZXN0IHJlZ2FyZHMsDQo+Pj4+PiBLYXRo bGVlbg0KPj4+Pj4NCj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+Pj4+PiBPQXV0aCBtYWlsaW5nIGxpc3QNCj4+Pj4+IE9BdXRoQGlldGYub3Jn DQo+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQo+Pj4+ DQo+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBUaGFua3MgYWdhaW4sDQo+Pj4+ ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQo+Pj4+DQo+Pj4NCj4+Pg0K Pj4+DQo+Pj4gLS0NCj4+Pg0KPj4+IEJlc3QgcmVnYXJkcywNCj4+PiBLYXRobGVlbg0KPj4NCj4+ DQo+Pg0KPj4gLS0NCj4+DQo+PiBCZXN0IHJlZ2FyZHMsDQo+PiBLYXRobGVlbg0KPj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IE9BdXRoIG1haWxp bmcgbGlzdA0KPj4gT0F1dGhAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vb2F1dGgNCj4NCg0KDQoNCi0tIA0KDQpCZXN0IHJlZ2FyZHMsDQpLYXRobGVl bg0K From nobody Thu Nov 26 04:45:27 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3EA11B2B4D for ; Thu, 26 Nov 2015 04:45:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D5pRf-DxQXMX for ; Thu, 26 Nov 2015 04:45:22 -0800 (PST) Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com [IPv6:2607:f8b0:400d:c04::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 878951B2B44 for ; Thu, 26 Nov 2015 04:45:22 -0800 (PST) Received: by qgea14 with SMTP id a14so53138346qge.0 for ; Thu, 26 Nov 2015 04:45:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3XCL13nXUZDoNcmCnu43tkHviAzRgHRdlEeHRFwSxiw=; b=vZ9Wcmh1WB8/e7LUTC4QQdzEYB2OwnKc/Xy9BZE6BGvfXYPhx/3Pa668o76r48g/zR EIGSAzLuHnZeml9thSMZlQKTygwWX5qwPaDMkJegFsrkSzUAx7LM1CxmzRvyU2/v6Xyl OfDNIxlTzSC3HxdsHnOLrUQHNP1P4OWEH6mM0zwKm/T1ocOjoU29YMBttvrvXm7XQJs9 VKJ8nBNahi9F7lSaDxTXFn6RuO/LAHb0Mtytq6s6+4yRUgUsVn1XBSOqj9hIs4aWJ8LT KhEjh19Nj90hna8uHOzTP3EbbITk3+pqE+g+Gfhu/DS/50ZFYRbI+MhdXPIvIUikVlzk hZtg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=3XCL13nXUZDoNcmCnu43tkHviAzRgHRdlEeHRFwSxiw=; b=OkTX9pFjmY04DKy1Bh5h8QN+DBKVtgunglMitqU4EbID8o32i3ST2DSR+YTLf5D+ox vr3w93CEg8eUQ3ms/o69a+OviFajjxJV24pk7Zc/jZVuXDk6kWLmzxy0x6am2LzouboT B85Pv2i0qR65qG6MAVGVQv76D9oSIs8xCkcTVgMuXZt5WZJ7Oong7de0gEDrocZQUzZP i+iDW9rxiDRdHlu+biyjL30yzQkXq61Jg6XJrP6taupwGSy3eGZ4V1uLq0XHJ7mQsCpG O5l54JgmMRJ89r3Or4x7d5biSryhTRj72A/p3ymO6MErROMZxhdmhXu/wFGbSktjDtec tizw== X-Gm-Message-State: ALoCoQn+e62ObETba01NSp/vnxZXHAScIfI8qZfeKipcpL2nFODxqd+AKJjjTcT8l2e3xuK83vDX X-Received: by 10.140.19.177 with SMTP id 46mr45889049qgh.67.1448541921543; Thu, 26 Nov 2015 04:45:21 -0800 (PST) Received: from [192.168.1.216] ([191.115.122.254]) by smtp.gmail.com with ESMTPSA id f7sm7096930qhf.7.2015.11.26.04.45.19 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 26 Nov 2015 04:45:20 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: John Bradley In-Reply-To: Date: Thu, 26 Nov 2015 09:45:17 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: <9C5F3F9A-3197-4080-B412-389318780D9A@ve7jtb.com> References: <4AF8FE9C-3484-410B-B52F-C1F9706B18A5@ve7jtb.com> To: Michael Jones X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-proof-of-possession X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2015 12:45:26 -0000 May should perhaps be might. This spec can=E2=80=99t confer or deny = the ability for implementations that don=E2=80=99t support this = extension to process JWT containing it. I think the concern is that some people may misunderstand what cnf is = doing, and think that a recipient not supporting cnf would automatically = reject it. cnf allows recipients that support confirmation methods to reject tokens = not sent by entities that possess the correct confirmation material. It is aud that restricts what recipients can process the assertion. So use aud to restrict the recipients, and cnf to restrict the = presenters. =20 A producer SHOULD restrict the valid recipients in aud to recipients = that support the cnf mechanism otherwise they will not get the get the = benefit of presenter restriction at the recipients that don=E2=80=99t = support it. The danger is that someone using cnf will assume that the token can only = be used by the entity possessing the cnf material, and that is not = necessarily true. If the token is otherwise valid (correct iss, aud and sig) , and the = recipient doesn=E2=80=99t understand cnf then a attacker who has the = token might be able to use it as a bearer token at the endpoint. This is probably too self evident to us, as we are close to the subject. So I think that the last paragraph of 4 is mostly OK. I think however we need to say that the way to stop endpoints that = don=E2=80=99t support cnf from processing tokens as bearer is to not = include them in the aud. =20 On another point that Kathleen raised in 3.1 I think Kathleen's reading may have led her to the conclusion that if = there are no members of the cnf claim that the recipient understands = then the cnf claim itself MUST be ignored. That wouldn=E2=80=99t be my interpretation but looking at it again, I = can see how someone might read it that way. Do we want to say that if there are no members that the recipient = understands then it SHOULD be an error, or leave it up to the protocols = using cnf to determine if it should be processed as a bearer token. =20 In any event we don=E2=80=99t want people ignoring the resulting empty = cnf claim. In most cases bearer and POP tokens will be presented differently = because PoP tokens need a way to present the proof, so a missing cnf = element would be a clear error. In other cases the proof might be passive. Token Binding or source IP. = In that case a recipient might leave it up to the producer of the token = to determine if it should be bound to the presenter. =20 I can see an argument for saying at the token level that a JWT = containing a cnf member with no understood members is malformed. These are two separate issues. John B. > On Nov 26, 2015, at 3:59 AM, Mike Jones = wrote: >=20 > I hadn't seen this part of the thread until now. (I thought it was = part of the voluminous thread on the PoP architecture document.) >=20 > The "may accept JWT containing =E2=80=9Ccnf=E2=80=9D elements" = language sounds like it's giving applications permission to do this. Is = that the intent of the language you proposed, or were you intending = something different, John? >=20 > Also, can you expand on the "pseudo audience" idea? In what way might = a proof-of-possession be confused with an audience? >=20 > Thanks, > -- Mike >=20 > -----Original Message----- > From: Kathleen Moriarty [mailto:kathleen.moriarty.ietf@gmail.com]=20 > Sent: Wednesday, November 25, 2015 2:13 PM > To: John Bradley > Cc: Mike Jones ; oauth@ietf.org > Subject: Re: [OAUTH-WG] AD review of = draft-ietf-oauth-proof-of-possession >=20 > Thanks, John! >=20 > On Wed, Nov 25, 2015 at 4:41 PM, John Bradley = wrote: >> I prefer the new wording. >>=20 >> However the last part could be clearer. >>> use be implemented by recipients. >>=20 >> Or perhaps the blunter =E2=80=9CRecipients only understanding bearer = tokens may accept JWT containing =E2=80=9Ccnf=E2=80=9D elements if all = the other required claims are valid. It is important for security to = audience restrict tokens using the JWT =E2=80=9Caud claim. The = =E2=80=9Ccnf=E2=80=9D claim MUST NOT be used as a pseudo audience = restriction.=E2=80=9D >=20 > More explicit text like this is is more helpful in my opinion. >=20 > Kathleen >>=20 >> Looking at the comments, I get the feeling that some people might = think that cnf may restrict what endpoints can receive the token = (because of the key distribution) it only allows endpoints that should = receive the token to reject ones that come from entities who don=E2=80=99t= possess the correct confirmation. >>=20 >> John B. >>=20 >>> On Nov 25, 2015, at 12:25 AM, Mike Jones = wrote: >>>=20 >>> Rather than elaborating, having looked at the text we're discussing = again, I'm going to counter-propose that we instead simplify - sticking = only to the point that the paragraph is intending to get across. Would = it work for you to simplify the current text: >>>=20 >>> "A recipient might not understand the cnf claim, in which case it = will typically be ignored. Unless this is acceptable behavior, = applications that need the proof-of-possession keys communicated with it = to be understood and processed must require that the parts of this = specification that they use be implemented." >>>=20 >>> to this simpler text? >>>=20 >>> "A recipient might not understand the cnf claim. Applications = that need the proof-of-possession keys communicated with it to be = understood and processed must require that the parts of this = specification that they use be implemented." >>>=20 >>> The "must ignore" topic is already addressed in the second paragraph = of 3.1 (and with exactly the semantics as the rest of JWT), and so = doesn't have to be re-raised here, as it currently is. Re-raising it is = clearly a point of distraction. >>>=20 >>> For what it's worth, I don't remember any DISCUSSes on this topic = (although it's possible that your memory is better than mine on this = point). >>>=20 >>> Best wishes, >>> -- Mike >>>=20 >>> -----Original Message----- >>> From: Kathleen Moriarty [mailto:kathleen.moriarty.ietf@gmail.com] >>> Sent: Tuesday, November 24, 2015 7:14 PM >>> To: Mike Jones >>> Cc: oauth@ietf.org >>> Subject: Re: [OAUTH-WG] AD review of=20 >>> draft-ietf-oauth-proof-of-possession >>>=20 >>> On Tue, Nov 24, 2015 at 10:10 PM, Mike Jones = wrote: >>>> Fair question about the use of "typically". The reason it's there = is that this language in JWT [RFC 7519] Section 4 does permit = applications to require that JWTs with not-understood claims be = rejected, rather than ignored, even though that's not the default = behavior: >>>>=20 >>>> The set of claims that a JWT must contain to be considered valid = is >>>> context dependent and is outside the scope of this specification. >>>> Specific applications of JWTs will require implementations to >>>> understand and process some claims in particular ways. However, = in >>>> the absence of such requirements, all claims that are not = understood >>>> by implementations MUST be ignored. >>>>=20 >>>> So when not understood, "cnf" would typically be ignored, but might = not be. >>>=20 >>> I find that confusing and am now thinking this came up in a discuss = as well during the review for 7519, didn't it? Can you elaborate int eh = security considerations section a bit more, otherwise this text appears = to be conflicting and even with what you intend, it's confusing for = implementers and will lead to issues with interoperability. >>>=20 >>> Thanks, >>> Kathleen >>>=20 >>>=20 >>>>=20 >>>> -- Mike >>>>=20 >>>> -----Original Message----- >>>> From: Kathleen Moriarty [mailto:kathleen.moriarty.ietf@gmail.com] >>>> Sent: Tuesday, November 24, 2015 6:41 PM >>>> To: Mike Jones >>>> Cc: oauth@ietf.org >>>> Subject: Re: [OAUTH-WG] AD review of=20 >>>> draft-ietf-oauth-proof-of-possession >>>>=20 >>>> Hi Mike, >>>>=20 >>>> Thanks for the quick turn-around. Just one more comment on my = comments. >>>>=20 >>>> On Tue, Nov 24, 2015 at 9:10 PM, Mike Jones = wrote: >>>>> Thanks for your review comments, Kathleen. Responses are inline = below... >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Kathleen=20= >>>>>> Moriarty >>>>>> Sent: Tuesday, November 24, 2015 9:44 AM >>>>>> To: oauth@ietf.org >>>>>> Subject: [OAUTH-WG] AD review of >>>>>> draft-ietf-oauth-proof-of-possession >>>>>>=20 >>>>>> Hi, >>>>>>=20 >>>>>> Thank you all for your work on this draft! I just have a few = questions: >>>>>>=20 >>>>>> 1. Security considerations section says: >>>>>>=20 >>>>>> "All of the normal security issues, especially in relationship to >>>>>> comparing URIs and dealing with unrecognized values, that are >>>>>> discussed in JWT [JWT] also apply here." >>>>>>=20 >>>>>> I find that to be odd phrasing that would likely be picked up in=20= >>>>>> subsequent reviews. Please remove the word "normal" so that all=20= >>>>>> of the security issues discusses in JWT are included. Are there=20= >>>>>> other 'normal considerations in addition to those in JWT that = need=20 >>>>>> to be listed? The phrasing reads as if that may the case and=20 >>>>>> would be better to include them all or pointers or change the = phrasing. >>>>>=20 >>>>> You're right. I removed this awkward wording. >>>>>=20 >>>>>> 2. Also in the security considerations section, >>>>>>=20 >>>>>> "A recipient may not understand the newly introduced "cnf" claim = and >>>>>> may consequently treat it as a bearer token." >>>>>>=20 >>>>>> What is the proper handling requirement when an unknown claim is=20= >>>>>> present? Section 3.1 says: >>>>>> "When a recipient receives a "cnf" claim with a >>>>>> member that it does not understand, it MUST ignore that member." >>>>>>=20 >>>>>> Is this why it is treated as a bearer token rather than being=20 >>>>>> rejected? Is this really the action you want to see with cnf? =20= >>>>>> Why isn't there an error and a resend as a bearer token so that=20= >>>>>> parties understand (or have an opportunity to understand) that = there were issues? >>>>>>=20 >>>>>> Then the following text in the security section says: >>>>>> "While this is a >>>>>> legitimate concern, it is outside the scope of this = specification, >>>>>> since demonstration the possession of the key associated with = the >>>>>> "cnf" claim is not covered by this specification. For more=20 >>>>>> details, >>>>>>=20 >>>>>> How is this outside of the scope of this draft? cnf is defined = in=20 >>>>>> this draft, so handling should be covered in this draft. A=20 >>>>>> pointer to the POP architecture draft is not helpful as it is not=20= >>>>>> defined there, it's covered int his draft. Should this text just=20= >>>>>> be removed and replaced with more explicit handling information = int he body of this draft? >>>>>=20 >>>>> Good catch. JWT [RFC 7519] Section 4 says that claims that are = not understood must be ignored unless otherwise specified by the = application. This allows new claims to be dynamically added without = breaking existing applications. For the same reason, I have = incorporated this language about understanding claims from 7519, but = having it be about understanding confirmation members. Ultimately, what = features must be implemented are always up to the application, just as = with JWT claims. >>>>=20 >>>> The new text in Section 3.1 looks good. I'm not sure why the word = "typically" appears int he new text of the security considerations = section though after reading the new text in 3.1. Wouldn't it just be = ignored since 3.1 now says: >>>>=20 >>>> "However, in the absence of such requirements, >>>> all confirmation members that are not understood by = implementations >>>> MUST be ignored." >>>>=20 >>>> Thanks, >>>> Kathleen >>>>=20 >>>>=20 >>>>>=20 >>>>>> Thanks! >>>>>>=20 >>>>>> -- >>>>>>=20 >>>>>> Best regards, >>>>>> Kathleen >>>>>>=20 >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>=20 >>>>> Thanks again, >>>>> -- Mike >>>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> -- >>>>=20 >>>> Best regards, >>>> Kathleen >>>=20 >>>=20 >>>=20 >>> -- >>>=20 >>> Best regards, >>> Kathleen >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >=20 >=20 >=20 > --=20 >=20 > Best regards, > Kathleen From nobody Thu Nov 26 06:31:06 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0B3F1B3A45 for ; Thu, 26 Nov 2015 06:31:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kXqnCMWCfNPb for ; Thu, 26 Nov 2015 06:30:58 -0800 (PST) Received: from p3plsmtpa06-08.prod.phx3.secureserver.net (p3plsmtpa06-08.prod.phx3.secureserver.net [173.201.192.109]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D0921B3A43 for ; Thu, 26 Nov 2015 06:30:58 -0800 (PST) Received: from [192.168.0.106] ([77.77.164.50]) by p3plsmtpa06-08.prod.phx3.secureserver.net with id mEWw1r00B15ZTut01EWxfT; Thu, 26 Nov 2015 07:30:58 -0700 To: oauth@ietf.org References: From: Vladimir Dzhuvinov X-Enigmail-Draft-Status: N1110 Organization: Connect2id Ltd. Message-ID: <565717A0.7080805@connect2id.com> Date: Thu, 26 Nov 2015 16:30:56 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------040202020508060105020808" Archived-At: Subject: Re: [OAUTH-WG] OAuth Discovery X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2015 14:31:05 -0000 This is a multi-part message in MIME format. --------------040202020508060105020808 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Good work, Mike, John, Nat! I see that the introspection and revocation endpoints are included now (they've been missing in OpenID discovery). Regarding client authentication, would it make sense to let token_endpoint_auth_methods_supported apply to the introspection and revocation endpoints as well? token_endpoint_auth_methods_supported OPTIONAL. JSON array containing a list of client authentication methods supported by this token endpoint. Client authentication method values are used in the "token_endpoint_auth_method" parameter defined in Section 2 of [RFC7591] . If omitted, the default is "client_secret_basic" -- the HTTP Basic Authentication Scheme specified in Section 2.3.1 = of OAuth 2.0 [RFC6749 ]. Vladimir On 26.11.2015 01:37, Mike Jones wrote: > I'm pleased to announce that Nat Sakimura, John Bradley, and I have cre= ated an OAuth 2.0 Discovery specification. This fills a hole in the curr= ent OAuth specification set that is necessary to achieve interoperability= =2E Indeed, the Interoperability section of OAuth 2.0 states: > > In addition, this specification leaves a few required components partia= lly or fully undefined (e.g., client registration, authorization server c= apabilities, endpoint discovery). Without these components, clients must= be manually and specifically configured against a specific authorization= server and resource server in order to interoperate. > > > > This framework was designed with the clear expectation that future work= will define prescriptive profiles and extensions necessary to achieve fu= ll web-scale interoperability. > > This specification enables discovery of both endpoint locations and aut= horization server capabilities. > > This specification is based upon the already widely deployed OpenID Con= nect Discovery 1.0 specification and is compatible with it, by design. The OAuth Disco= very spec removes the portions of OpenID Connect Discovery that are OpenI= D specific and adds metadata values for Revocation and Introspection endp= oints. It also maps OpenID concepts, such as OpenID Provider, Relying Pa= rty, End-User, and Issuer to their OAuth underpinnings, respectively Auth= orization Server, Client, Resource Owner, and the newly introduced Config= uration Information Location. Some identifiers with names that appear to= be OpenID specific were retained for compatibility purposes; despite the= reuse of these identifiers that appear to be OpenID specific, their usag= e in this specification is actually referring to general OAuth 2.0 featur= es that are not specific to OpenID Connect. > > The specification is available at: > > * http://tools.ietf.org/html/draft-jones-oauth-discovery-00 > > An HTML-formatted version is also available at: > > * http://self-issued.info/docs/draft-jones-oauth-discovery-00.h= tml > > -- Mike= > > P.S. This note was also posted at http://self-issued.info/?p=3D1496 an= d as @selfissued. > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------040202020508060105020808 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Good work, Mike, John, Nat!

I see that the introspection and revocation endpoints are included now (they've been missing in OpenID discovery).

Regarding client authentication, would it make sense to let token_endpoint_auth_methods_supported apply to the introspection and revocation endpoints as well?

token_endpoint_auth_methods_supported
      OPTIONAL.  JSON array containing a list of client authentication
      methods supported by this token endpoint.  Client authentication
      method values are used in the "token_endpoint_auth_method"
      parameter defined in Section 2 of [RFC7591].  If omitted, the
      default is "client_secret_basic" -- the HTTP Basic Authentication
      Scheme specified in Section 2.3.1 of OAuth 2.0 [RFC6749].


Vladimir

On 26.11.2015 01:37, Mike Jones wrote:
I'm pleased to announce that Nat Sakimura, John Bradley, and I have created an OAuth 2.0 Discovery specification.  This fills a hole in the current OAuth specification set that is necessary to achieve interoperability.  Indeed, the Interoperability section of OAuth 2.0 <https://tools.ietf.org/html/rfc6749#section-1.8> states:

In addition, this specification leaves a few required components partially or fully undefined (e.g., client registration, authorization server capabilities, endpoint discovery).  Without these components, clients must be manually and specifically configured against a specific authorization server and resource server in order to interoperate.



This framework was designed with the clear expectation that future work will define prescriptive profiles and extensions necessary to achieve full web-scale interoperability.

This specification enables discovery of both endpoint locations and authorization server capabilities.

This specification is based upon the already widely deployed OpenID Connect Discovery 1.0<http://openid.net/specs/openid-connect-discovery-1_0.html> specification and is compatible with it, by design.  The OAuth Discovery spec removes the portions of OpenID Connect Discovery that are OpenID specific and adds metadata values for Revocation and Introspection endpoints.  It also maps OpenID concepts, such as OpenID Provider, Relying Party, End-User, and Issuer to their OAuth underpinnings, respectively Authorization Server, Client, Resource Owner, and the newly introduced Configuration Information Location.  Some identifiers with names that appear to be OpenID specific were retained for compatibility purposes; despite the reuse of these identifiers that appear to be OpenID specific, their usage in this specification is actually referring to general OAuth 2.0 features that are not 
 s
pecific to OpenID Connect.

The specification is available at:

*         http://tools.ietf.org/html/draft-jones-oauth-discovery-00

An HTML-formatted version is also available at:

*         http://self-issued.info/docs/draft-jones-oauth-discovery-00.html

                                                                -- Mike

P.S.  This note was also posted at http://self-issued.info/?p=1496 and as @selfissued<https://twitter.com/selfissued>.




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

--------------040202020508060105020808-- From nobody Thu Nov 26 06:37:53 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89E091B3A5B for ; Thu, 26 Nov 2015 06:37:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.785 X-Spam-Level: X-Spam-Status: No, score=-4.785 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fE-D6FAIZQIg for ; Thu, 26 Nov 2015 06:37:50 -0800 (PST) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1D971B3A53 for ; Thu, 26 Nov 2015 06:37:49 -0800 (PST) X-AuditID: 12074423-f797f6d0000023d0-49-5657193c7252 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 5C.C7.09168.C3917565; Thu, 26 Nov 2015 09:37:48 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id tAQEblPk031419; Thu, 26 Nov 2015 09:37:48 -0500 Received: from artemisia.richer.local (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id tAQEbko6008165 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 26 Nov 2015 09:37:47 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_7C1FAAE5-AA3F-4D7E-936E-7A2F3A3F33AD" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Justin Richer In-Reply-To: <565717A0.7080805@connect2id.com> Date: Thu, 26 Nov 2015 09:37:45 -0500 Message-Id: <63869603-8710-47D6-8CFA-2A6FC18A8603@mit.edu> References: <565717A0.7080805@connect2id.com> To: Vladimir Dzhuvinov X-Mailer: Apple Mail (2.2104) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjleLIzCtJLcpLzFFi42IRYrdT0bWRDA8zmPBKz+Lk21dsFu/efWB0 YPKY/7mF1WPJkp9MAUxRXDYpqTmZZalF+nYJXBn3Gi6xFnSEV3Te2srcwLjRs4uRk0NCwERi 5fdfLBC2mMSFe+vZQGwhgcVMEuue53cxcgHZGxklTtzezQLhPGSSaF39hhWkilkgQeLtxH9g HbwCehKvbl0GiwsLqEvc2bCGHcRmE1CVmL6mhamLkYODE6im53QySJgFKPxsw282kDAzUHn7 SReIKVYS89c9ZoW4oUZi5oU/zCC2iICBxOPX55kh7pSV2P37EdMERoFZSI6YheQIiLi2xLKF r5khbAOJp52vsIjrS7x5N4dpASPbKkbZlNwq3dzEzJzi1GTd4uTEvLzUIl0zvdzMEr3UlNJN jOBgd1HewfjnoNIhRgEORiUe3gLbsDAh1sSy4srcQ4ySHExKorzyguFhQnxJ+SmVGYnFGfFF pTmpxYcYJTiYlUR4b7EA5XhTEiurUovyYVLSHCxK4rxzv/iGCQmkJ5akZqemFqQWwWRlODiU JHg3SgA1ChalpqdWpGXmlCCkmTg4QYbzAA3PAanhLS5IzC3OTIfIn2JUlBLnLQRJCIAkMkrz 4HpBySjh7WHTV4ziQK8I83aLA1XxABMZXPcroMFMQIMjckJBBpckIqSkGhi3H2iODhF9dMhR PmYLw51OhgUv/gg4ueRz2ZqeDU02FlJ7tVvLf65RrFSO5Ypmq9Tk9RExOa+jfi8uF/ewTf18 TuRljRwzu/baeuuWOd/De/6ttp/Fc+hLkcKfeUb3lgVtSJ0+a5UDj+6dL04i3z0Ovy5geeCz 67WfTX9bzbfT/ezzlzv72CixFGckGmoxFxUnAgBvoHdcIQMAAA== Archived-At: Cc: "" Subject: Re: [OAUTH-WG] OAuth Discovery X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2015 14:37:52 -0000 --Apple-Mail=_7C1FAAE5-AA3F-4D7E-936E-7A2F3A3F33AD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Those should be handled separately if they=92re to be added to = discovery. =97 Justin > On Nov 26, 2015, at 9:30 AM, Vladimir Dzhuvinov = wrote: >=20 > Good work, Mike, John, Nat! >=20 > I see that the introspection and revocation endpoints are included now = (they've been missing in OpenID discovery). >=20 > Regarding client authentication, would it make sense to let = token_endpoint_auth_methods_supported apply to the introspection and = revocation endpoints as well? >=20 > token_endpoint_auth_methods_supported > OPTIONAL. JSON array containing a list of client authentication > methods supported by this token endpoint. Client authentication > method values are used in the "token_endpoint_auth_method" > parameter defined in Section=A02 of [RFC7591] = . If omitted, the > default is "client_secret_basic" -- the HTTP Basic = Authentication > Scheme specified in Section 2.3.1 = = of OAuth 2.0 [RFC6749 ]. >=20 >=20 > Vladimir >=20 > On 26.11.2015 01:37, Mike Jones wrote: >> I'm pleased to announce that Nat Sakimura, John Bradley, and I have = created an OAuth 2.0 Discovery specification. This fills a hole in the = current OAuth specification set that is necessary to achieve = interoperability. Indeed, the Interoperability section of OAuth 2.0 = = states: >>=20 >> In addition, this specification leaves a few required components = partially or fully undefined (e.g., client registration, authorization = server capabilities, endpoint discovery). Without these components, = clients must be manually and specifically configured against a specific = authorization server and resource server in order to interoperate. >>=20 >>=20 >>=20 >> This framework was designed with the clear expectation that future = work will define prescriptive profiles and extensions necessary to = achieve full web-scale interoperability. >>=20 >> This specification enables discovery of both endpoint locations and = authorization server capabilities. >>=20 >> This specification is based upon the already widely deployed OpenID = Connect Discovery = 1.0 = = specification and is compatible with it, by design. The OAuth Discovery = spec removes the portions of OpenID Connect Discovery that are OpenID = specific and adds metadata values for Revocation and Introspection = endpoints. It also maps OpenID concepts, such as OpenID Provider, = Relying Party, End-User, and Issuer to their OAuth underpinnings, = respectively Authorization Server, Client, Resource Owner, and the newly = introduced Configuration Information Location. Some identifiers with = names that appear to be OpenID specific were retained for compatibility = purposes; despite the reuse of these identifiers that appear to be = OpenID specific, their usage in this specification is actually referring = to general OAuth 2.0 features that! >> are not=20 >> s >> pecific to OpenID Connect. >>=20 >> The specification is available at: >>=20 >> * http://tools.ietf.org/html/draft-jones-oauth-discovery-00 = >>=20 >> An HTML-formatted version is also available at: >>=20 >> * = http://self-issued.info/docs/draft-jones-oauth-discovery-00.html = >>=20 >> -- = Mike >>=20 >> P.S. This note was also posted at http://self-issued.info/?p=3D1496 = and as = @selfissued = . >>=20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_7C1FAAE5-AA3F-4D7E-936E-7A2F3A3F33AD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Those should be handled separately if they=92re to be added = to discovery.

 =97= Justin

On Nov 26, 2015, at 9:30 AM, = Vladimir Dzhuvinov <vladimir@connect2id.com> wrote:

=20
Good work, Mike, John, Nat!

I see that the introspection and revocation endpoints are included now (they've been missing in OpenID discovery).

Regarding client authentication, would it make sense to let token_endpoint_auth_methods_supported apply to the introspection and revocation endpoints as well?

token_endpoint_auth_methods_supported
      OPTIONAL.  JSON array containing a list of client authentication
      methods supported by this token endpoint.  Client authentication
      method values are used in the "token_endpoint_auth_method"
      parameter defined in Section 2 of [RFC7591].  If omitted, the
      default is "client_secret_basic" -- the HTTP Basic Authentication
      Scheme specified in Section 2.3.1 of OAuth 2.0 [RFC6749].


Vladimir

On 26.11.2015 01:37, Mike Jones = wrote:
I'm pleased to announce that Nat =
Sakimura, John Bradley, and I have created an OAuth 2.0 Discovery =
specification.  This fills a hole in the current OAuth specification set =
that is necessary to achieve interoperability.  Indeed, the =
Interoperability section of OAuth 2.0 <https://tools=
.ietf.org/html/rfc6749#section-1.8> states:

In addition, this specification leaves a few required components =
partially or fully undefined (e.g., client registration, authorization =
server capabilities, endpoint discovery).  Without these components, =
clients must be manually and specifically configured against a specific =
authorization server and resource server in order to interoperate.



This framework was designed with the clear expectation that future work =
will define prescriptive profiles and extensions necessary to achieve =
full web-scale interoperability.

This specification enables discovery of both endpoint locations and =
authorization server capabilities.

This specification is based upon the already widely deployed OpenID =
Connect Discovery 1.0<htt=
p://openid.net/specs/openid-connect-discovery-1_0.html> =
specification and is compatible with it, by design.  The OAuth Discovery =
spec removes the portions of OpenID Connect Discovery that are OpenID =
specific and adds metadata values for Revocation and Introspection =
endpoints.  It also maps OpenID concepts, such as OpenID Provider, =
Relying Party, End-User, and Issuer to their OAuth underpinnings, =
respectively Authorization Server, Client, Resource Owner, and the newly =
introduced Configuration Information Location.  Some identifiers with =
names that appear to be OpenID specific were retained for compatibility =
purposes; despite the reuse of these identifiers that appear to be =
OpenID specific, their usage in this specification is actually referring =
to general OAuth 2.0 features that!
  are not=20
 s
pecific to OpenID Connect.

The specification is available at:

*         http://=
tools.ietf.org/html/draft-jones-oauth-discovery-00

An HTML-formatted version is also available at:

*         =
http://self-issued.info/docs/draft-jones-oauth-discovery-00.html

                                                                -- Mike

P.S.  This note was also posted at http://self-issued.info/?p=3D14=
96 and as @selfissued<https://twitter.com/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

= --Apple-Mail=_7C1FAAE5-AA3F-4D7E-936E-7A2F3A3F33AD-- From nobody Thu Nov 26 07:59:42 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49AB31A6F6D for ; Thu, 26 Nov 2015 07:59:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.594 X-Spam-Level: X-Spam-Status: No, score=-0.594 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, TRACKER_ID=1.306] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M3COm5siBQLv for ; Thu, 26 Nov 2015 07:59:38 -0800 (PST) Received: from mail-qg0-x22b.google.com (mail-qg0-x22b.google.com [IPv6:2607:f8b0:400d:c04::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 A76191A6EE8 for ; Thu, 26 Nov 2015 07:59:37 -0800 (PST) Received: by qgcc31 with SMTP id c31so56382266qgc.3 for ; Thu, 26 Nov 2015 07:59:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=KmUUOdCbgZVs3kOCYDzAZlurgvwgClns8Aq09ILO++Q=; b=uG0ej6PN6svbetaUvKjMmie845FZszbgX28A4gbkC9fg2DRahAhNWkjVPAPH6zovls ROFVud7lEPcOOrHIPlnLoNS3ovY1w+rjoGrzCBFVd3xMEBDW6qvuzQUl/p2+C/8npooN ujQqOVj5SaqoCDKIHl3MCcsLYFfpvehKa5kPOKGVIn7gdOgFKsLywqXMheNQcxAMSizn Ugfj/PJxYUEEICykgJVU9B3SDw7Nw1ZFG8xciRDjlwaTIW/slzwc+XB/DCiYIOkuwO80 NQeLEVoXjkaNipFeckXpfM6OMcoC3ApObjCqQoSzCCGSJP0GM5/zsali0hH3BUb+F2Ws vnMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=KmUUOdCbgZVs3kOCYDzAZlurgvwgClns8Aq09ILO++Q=; b=JB6zzzSjKk2l0gM7hoEmgQHaO8X1ZTqamuJXP1FvcarSNRnALgnwIaI3LdHPRLHVqC /Txu4rHBty6zLSqTLX3i7h+MDND6i9daumU2SF2pTG8+MxOoIQz67LEog6PEK90NlU/B sLQ0GhXe252xdIHmLjtTkEDMoG6adip+A9TSvR9sUPYhH84+C1Sn44q1xEmfhjILOdt0 XEPAWTLS4VAiv7n2Si+pmhHeMS+5/LLbqBgBwMqGwIYxyJ5z3KRC+NoJ9m9WJLG7t8Qo XiHUQKXBR2rjBaPFoGmkT0P79/HVZEAekOnF3nTN8QT4UYyiXRm4aYFVRHhfEcKxkWXw 8MzQ== X-Gm-Message-State: ALoCoQkWVB6KmWn2ugKOfYyK1p8uJURAHmyD4mP/S3xklFSk6ETvIMrs5HHgXbUmp0uRg097Zj/N X-Received: by 10.140.159.134 with SMTP id f128mr50028197qhf.72.1448553576589; Thu, 26 Nov 2015 07:59:36 -0800 (PST) Received: from [192.168.8.100] ([181.202.72.81]) by smtp.gmail.com with ESMTPSA id f126sm2701246qkb.43.2015.11.26.07.59.34 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 26 Nov 2015 07:59:35 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_FF4969E2-9850-4C84-9473-4B93D4C64E26" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: John Bradley In-Reply-To: <565717A0.7080805@connect2id.com> Date: Thu, 26 Nov 2015 12:59:30 -0300 Message-Id: <282CA912-3F1A-4E04-85A4-0834D78E9725@ve7jtb.com> References: <565717A0.7080805@connect2id.com> To: Vladimir Dzhuvinov X-Mailer: Apple Mail (2.2104) Archived-At: Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth Discovery X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2015 15:59:40 -0000 --Apple-Mail=_FF4969E2-9850-4C84-9473-4B93D4C64E26 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 The methods could be the same but they should probably specified = separately eg introspection_endpoint_auth_methods_supported If we overload them we will probably regret it later. John B. > On Nov 26, 2015, at 11:30 AM, Vladimir Dzhuvinov = wrote: >=20 > Good work, Mike, John, Nat! >=20 > I see that the introspection and revocation endpoints are included now = (they've been missing in OpenID discovery). >=20 > Regarding client authentication, would it make sense to let = token_endpoint_auth_methods_supported apply to the introspection and = revocation endpoints as well? >=20 > token_endpoint_auth_methods_supported > OPTIONAL. JSON array containing a list of client authentication > methods supported by this token endpoint. Client authentication > method values are used in the "token_endpoint_auth_method" > parameter defined in Section=A02 of [RFC7591] = . If omitted, the > default is "client_secret_basic" -- the HTTP Basic = Authentication > Scheme specified in Section 2.3.1 = = of OAuth 2.0 [RFC6749 ]. >=20 >=20 > Vladimir >=20 > On 26.11.2015 01:37, Mike Jones wrote: >> I'm pleased to announce that Nat Sakimura, John Bradley, and I have = created an OAuth 2.0 Discovery specification. This fills a hole in the = current OAuth specification set that is necessary to achieve = interoperability. Indeed, the Interoperability section of OAuth 2.0 = = states: >>=20 >> In addition, this specification leaves a few required components = partially or fully undefined (e.g., client registration, authorization = server capabilities, endpoint discovery). Without these components, = clients must be manually and specifically configured against a specific = authorization server and resource server in order to interoperate. >>=20 >>=20 >>=20 >> This framework was designed with the clear expectation that future = work will define prescriptive profiles and extensions necessary to = achieve full web-scale interoperability. >>=20 >> This specification enables discovery of both endpoint locations and = authorization server capabilities. >>=20 >> This specification is based upon the already widely deployed OpenID = Connect Discovery = 1.0 = = specification and is compatible with it, by design. The OAuth Discovery = spec removes the portions of OpenID Connect Discovery that are OpenID = specific and adds metadata values for Revocation and Introspection = endpoints. It also maps OpenID concepts, such as OpenID Provider, = Relying Party, End-User, and Issuer to their OAuth underpinnings, = respectively Authorization Server, Client, Resource Owner, and the newly = introduced Configuration Information Location. Some identifiers with = names that appear to be OpenID specific were retained for compatibility = purposes; despite the reuse of these identifiers that appear to be = OpenID specific, their usage in this specification is actually referring = to general OAuth 2.0 features that are not=20 >> s >> pecific to OpenID Connect. >>=20 >> The specification is available at: >>=20 >> * http://tools.ietf.org/html/draft-jones-oauth-discovery-00 = >>=20 >> An HTML-formatted version is also available at: >>=20 >> * = http://self-issued.info/docs/draft-jones-oauth-discovery-00.html = >>=20 >> -- = Mike >>=20 >> P.S. This note was also posted at http://self-issued.info/?p=3D1496 = and as = @selfissued = . >>=20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_FF4969E2-9850-4C84-9473-4B93D4C64E26 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 The methods could be the same but they should probably = specified separately eg

introspection_endpoint_auth_methods_supported
If we overload them we will probably regret it = later.

John = B.
On Nov = 26, 2015, at 11:30 AM, Vladimir Dzhuvinov <vladimir@connect2id.com> wrote:

=20 =20
Good work, Mike, John, Nat!

I see that the introspection and revocation endpoints are included now (they've been missing in OpenID discovery).

Regarding client authentication, would it make sense to let token_endpoint_auth_methods_supported apply to the introspection and revocation endpoints as well?

token_endpoint_auth_methods_supported
      OPTIONAL.  JSON array containing a list of client authentication
      methods supported by this token endpoint.  Client authentication
      method values are used in the "token_endpoint_auth_method"
      parameter defined in Section 2 of [RFC7591].  If omitted, the
      default is "client_secret_basic" -- the HTTP Basic Authentication
      Scheme specified in Section 2.3.1 of OAuth 2.0 [RFC6749].


Vladimir

On 26.11.2015 01:37, Mike Jones = wrote:
I'm pleased to announce that Nat =
Sakimura, John Bradley, and I have created an OAuth 2.0 Discovery =
specification.  This fills a hole in the current OAuth specification set =
that is necessary to achieve interoperability.  Indeed, the =
Interoperability section of OAuth 2.0 <https://tools=
.ietf.org/html/rfc6749#section-1.8> states:

In addition, this specification leaves a few required components =
partially or fully undefined (e.g., client registration, authorization =
server capabilities, endpoint discovery).  Without these components, =
clients must be manually and specifically configured against a specific =
authorization server and resource server in order to interoperate.



This framework was designed with the clear expectation that future work =
will define prescriptive profiles and extensions necessary to achieve =
full web-scale interoperability.

This specification enables discovery of both endpoint locations and =
authorization server capabilities.

This specification is based upon the already widely deployed OpenID =
Connect Discovery 1.0<htt=
p://openid.net/specs/openid-connect-discovery-1_0.html> =
specification and is compatible with it, by design.  The OAuth Discovery =
spec removes the portions of OpenID Connect Discovery that are OpenID =
specific and adds metadata values for Revocation and Introspection =
endpoints.  It also maps OpenID concepts, such as OpenID Provider, =
Relying Party, End-User, and Issuer to their OAuth underpinnings, =
respectively Authorization Server, Client, Resource Owner, and the newly =
introduced Configuration Information Location.  Some identifiers with =
names that appear to be OpenID specific were retained for compatibility =
purposes; despite the reuse of these identifiers that appear to be =
OpenID specific, their usage in this specification is actually referring =
to general OAuth 2.0 features that are not=20
 s
pecific to OpenID Connect.

The specification is available at:

*         http://=
tools.ietf.org/html/draft-jones-oauth-discovery-00

An HTML-formatted version is also available at:

*         =
http://self-issued.info/docs/draft-jones-oauth-discovery-00.html

                                                                -- Mike

P.S.  This note was also posted at http://self-issued.info/?p=3D14=
96 and as @selfissued<https://twitter.com/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

= --Apple-Mail=_FF4969E2-9850-4C84-9473-4B93D4C64E26-- From nobody Thu Nov 26 08:35:27 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59ADC1B2BBA for ; Thu, 26 Nov 2015 08:35:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.693 X-Spam-Level: X-Spam-Status: No, score=-0.693 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, TRACKER_ID=1.306] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gNg8PcZkjx48 for ; Thu, 26 Nov 2015 08:35:20 -0800 (PST) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::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 910CA1B2BB8 for ; Thu, 26 Nov 2015 08:35:20 -0800 (PST) Received: by obbbj7 with SMTP id bj7so65930153obb.1 for ; Thu, 26 Nov 2015 08:35:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dh1SbNRLbHkNn0vcMzvdT/7lC/tXvsMGRHRQVxjNyz0=; b=ehqZEqNGb2fMn+uOOrOBzqPiSCJcfZ2EEPuv3aqUQZ5K+RZFi5FzCeOVbvC3wXYP0h uFmHYvctplbiQ3Ieqd1/n6gOX0DSgo3/aPvHRwKJN2PnMmFEfqMbYA2X6uYr0X3caZrz 6WBb4TiAw6nsj5r2iQ4iWOO0RaaBzsMTPJmC7qtD94jX8CxJE4Bv4jeaiW9iYXLzRGeb g4hbAAxGcgzES+FNhxum+Aeaqg/Bi6CKsDKYlp/QuKOkMTNFnd9LK3CNX4mJqG+2wbgy /0M+NBl2L5HlfxTdxP/1Eu008QDaV9ncUCg6KLE4Uk8EzlVuslQKrgDs/AmFABN/gPUa aOuw== MIME-Version: 1.0 X-Received: by 10.182.251.130 with SMTP id zk2mr28291941obc.57.1448555719970; Thu, 26 Nov 2015 08:35:19 -0800 (PST) Received: by 10.182.236.196 with HTTP; Thu, 26 Nov 2015 08:35:19 -0800 (PST) In-Reply-To: <282CA912-3F1A-4E04-85A4-0834D78E9725@ve7jtb.com> References: <565717A0.7080805@connect2id.com> <282CA912-3F1A-4E04-85A4-0834D78E9725@ve7jtb.com> Date: Fri, 27 Nov 2015 01:35:19 +0900 Message-ID: From: Nat Sakimura To: John Bradley Content-Type: multipart/alternative; boundary=089e01634c2a2059b905257429f1 Archived-At: Cc: oauth Subject: Re: [OAUTH-WG] OAuth Discovery X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2015 16:35:26 -0000 --089e01634c2a2059b905257429f1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Agreed... 2015-11-27 0:59 GMT+09:00 John Bradley : > The methods could be the same but they should probably specified > separately eg > > introspection_endpoint_auth_methods_supported > > If we overload them we will probably regret it later. > > John B. > > On Nov 26, 2015, at 11:30 AM, Vladimir Dzhuvinov > wrote: > > Good work, Mike, John, Nat! > > I see that the introspection and revocation endpoints are included now > (they've been missing in OpenID discovery). > > Regarding client authentication, would it make sense to let > token_endpoint_auth_methods_supported apply to the introspection and > revocation endpoints as well? > > token_endpoint_auth_methods_supported > OPTIONAL. JSON array containing a list of client authentication > methods supported by this token endpoint. Client authentication > method values are used in the "token_endpoint_auth_method" > parameter defined in Section 2 of [RFC7591] . If omitted, the > default is "client_secret_basic" -- the HTTP Basic Authentication > Scheme specified in Section 2.3.1 of OAuth 2.0 [RFC6749 ]. > > > > Vladimir > > On 26.11.2015 01:37, Mike Jones wrote: > > I'm pleased to announce that Nat Sakimura, John Bradley, and I have creat= ed an OAuth 2.0 Discovery specification. This fills a hole in the current = OAuth specification set that is necessary to achieve interoperability. Ind= eed, the Interoperability section of OAuth 2.0 sta= tes: > > In addition, this specification leaves a few required components partiall= y or fully undefined (e.g., client registration, authorization server capab= ilities, endpoint discovery). Without these components, clients must be ma= nually and specifically configured against a specific authorization server = and resource server in order to interoperate. > > > > This framework was designed with the clear expectation that future work w= ill define prescriptive profiles and extensions necessary to achieve full w= eb-scale interoperability. > > This specification enables discovery of both endpoint locations and autho= rization server capabilities. > > This specification is based upon the already widely deployed OpenID Conne= ct Discovery 1.0= specification = and is compatible with it, by design. The OAuth Discovery spec removes the= portions of OpenID Connect Discovery that are OpenID specific and adds met= adata values for Revocation and Introspection endpoints. It also maps Open= ID concepts, such as OpenID Provider, Relying Party, End-User, and Issuer t= o their OAuth underpinnings, respectively Authorization Server, Client, Res= ource Owner, and the newly introduced Configuration Information Location. = Some identifiers with names that appear to be OpenID specific were retained= for compatibility purposes; despite the reuse of these identifiers that ap= pear to be OpenID specific, their usage in this specification is actually r= eferring to general OAuth 2.0 features that are not > s > pecific to OpenID Connect. > > The specification is available at: > > * http://tools.ietf.org/html/draft-jones-oauth-discovery-00 > > An HTML-formatted version is also available at: > > * http://self-issued.info/docs/draft-jones-oauth-discovery-00.htm= l > > -- Mike > > P.S. This note was also posted at http://self-issued.info/?p=3D1496 and = as @selfissued . > > > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oau= th > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --=20 Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --089e01634c2a2059b905257429f1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Agreed...=C2=A0

2015-11-27 0:59 GMT+09:00 John Bradley <ve7jtb@ve7jtb= .com>:
The methods could be the same but they should probably spec= ified separately eg

introspection_endpoint_auth_methods_supported
If= we overload them we will probably regret it later.

John B.
O= n Nov 26, 2015, at 11:30 AM, Vladimir Dzhuvinov <vladimir@connect2id.com> wrote= :

=20 =20 =20
Good work, Mike, John, Nat!

I see that the introspection and revocation endpoints are included now (they've been missing in OpenID discovery).

Regarding client authentication, would it make sense to let token_endpoint_auth_methods_supported apply to the introspection and revocation endpoints as well?

token_endpoint_auth_methods_supported
      OPTIONAL.  JSON array containing a list of client authentication
      methods supported by this token endpoint.  Client authentication
      method values are used in the "token_endpoint_auth_method"
      parameter defined in Section=C2=A02 of [RFC7591].  If omitted, th=
e
      default is "client_secret_basic" -- the HTTP Basic Authenti=
cation
      Scheme specified in Section 2.3.1 of O=
Auth 2.0 [RFC6749].
    

    

    Vladimir

    

    
On 26.11.2015 01:37, Mike Jones wrote:

    

    

      
I'm pleased to announce that Nat Sakimura, John Bradley, and=
 I have created an OAuth 2.0 Discovery specification.  This fills a hole in=
 the current OAuth specification set that is necessary to achieve interoper=
ability.  Indeed, the Interoperability section of OAuth 2.0 <https://=
tools.ietf.org/html/rfc6749#section-1.8> states:

In addition, this specification leaves a few required components partially =
or fully undefined (e.g., client registration, authorization server capabil=
ities, endpoint discovery).  Without these components, clients must be manu=
ally and specifically configured against a specific authorization server an=
d resource server in order to interoperate.



This framework was designed with the clear expectation that future work wil=
l define prescriptive profiles and extensions necessary to achieve full web=
-scale interoperability.

This specification enables discovery of both endpoint locations and authori=
zation server capabilities.

This specification is based upon the already widely deployed OpenID Connect=
 Discovery 1.0<http://openid.net/specs/openid-connect-disco=
very-1_0.html> specification and is compatible with it, by design.  =
The OAuth Discovery spec removes the portions of OpenID Connect Discovery t=
hat are OpenID specific and adds metadata values for Revocation and Introsp=
ection endpoints.  It also maps OpenID concepts, such as OpenID Provider, R=
elying Party, End-User, and Issuer to their OAuth underpinnings, respective=
ly Authorization Server, Client, Resource Owner, and the newly introduced C=
onfiguration Information Location.  Some identifiers with names that appear=
 to be OpenID specific were retained for compatibility purposes; despite th=
e reuse of these identifiers that appear to be OpenID specific, their usage=
 in this specification is actually referring to general OAuth 2.0 features =
that are not=20
 s
pecific to OpenID Connect.

The specification is available at:

*         http://tools.ietf.org/html/draft-jones-oauth-discove=
ry-00

An HTML-formatted version is also available at:

*         http://self-issued.info/docs/draft-jones-oaut=
h-discovery-00.html

                                                                -- Mike

P.S.  This note was also posted at http://self-issued.info/?p=3D1496 and as @selfi=
ssued<https=
://twitter.com/selfissued>.



      

      

      

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

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




--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundatio= n
http://nat.saki= mura.org/
@_nat_en
--089e01634c2a2059b905257429f1-- From nobody Thu Nov 26 10:32:02 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFA5B1A21A8 for ; Thu, 26 Nov 2015 10:31:59 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id luZ0J4QpAXRS for ; Thu, 26 Nov 2015 10:31:58 -0800 (PST) Received: from p3plsmtpa07-08.prod.phx3.secureserver.net (p3plsmtpa07-08.prod.phx3.secureserver.net [173.201.192.237]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA82C1A21A4 for ; Thu, 26 Nov 2015 10:31:57 -0800 (PST) Received: from [192.168.0.106] ([77.77.164.50]) by p3plsmtpa07-08.prod.phx3.secureserver.net with id mJXv1r00A15ZTut01JXw6V; Thu, 26 Nov 2015 11:31:57 -0700 To: John Bradley References: <565717A0.7080805@connect2id.com> <282CA912-3F1A-4E04-85A4-0834D78E9725@ve7jtb.com> From: Vladimir Dzhuvinov X-Enigmail-Draft-Status: N1110 Organization: Connect2id Ltd. Message-ID: <5657501A.7080507@connect2id.com> Date: Thu, 26 Nov 2015 20:31:54 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <282CA912-3F1A-4E04-85A4-0834D78E9725@ve7jtb.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth Discovery X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2015 18:31:59 -0000 Introspection (RFC 7662) allows bearer token authorisation for the request, which I guess will require a new keyword for this auth method? https://tools.ietf.org/html/rfc7662#section-2.1 On 26.11.2015 17:59, John Bradley wrote: > The methods could be the same but they should probably specified separa= tely eg > > introspection_endpoint_auth_methods_supported > If we overload them we will probably regret it later. > > John B. >> On Nov 26, 2015, at 11:30 AM, Vladimir Dzhuvinov wrote: >> >> Good work, Mike, John, Nat! >> >> I see that the introspection and revocation endpoints are included now= (they've been missing in OpenID discovery). >> >> Regarding client authentication, would it make sense to let token_endp= oint_auth_methods_supported apply to the introspection and revocation end= points as well? >> >> token_endpoint_auth_methods_supported >> OPTIONAL. JSON array containing a list of client authentication= >> methods supported by this token endpoint. Client authentication= >> method values are used in the "token_endpoint_auth_method" >> parameter defined in Section 2 of [RFC7591] . If omitted, the >> default is "client_secret_basic" -- the HTTP Basic Authenticatio= n >> Scheme specified in Section 2.3.1 of OAuth 2.0 [RFC6749 ]. >> >> >> Vladimir >> >> On 26.11.2015 01:37, Mike Jones wrote: >>> I'm pleased to announce that Nat Sakimura, John Bradley, and I have c= reated an OAuth 2.0 Discovery specification. This fills a hole in the cu= rrent OAuth specification set that is necessary to achieve interoperabili= ty. Indeed, the Interoperability section of OAuth 2.0 states: >>> Vladimir Dzhuvinov :: vladimir@connect2id.com >>> >>> In addition, this specification leaves a few required components part= ially or fully undefined (e.g., client registration, authorization server= capabilities, endpoint discovery). Without these components, clients mu= st be manually and specifically configured against a specific authorizati= on server and resource server in order to interoperate. >>> >>> >>> >>> This framework was designed with the clear expectation that future wo= rk will define prescriptive profiles and extensions necessary to achieve = full web-scale interoperability. >>> >>> This specification enables discovery of both endpoint locations and a= uthorization server capabilities. >>> >>> This specification is based upon the already widely deployed OpenID C= onnect Discovery 1.0 spec= ification and is compatible with it, by design. The OAuth Discovery spec= removes the portions of OpenID Connect Discovery that are OpenID specifi= c and adds metadata values for Revocation and Introspection endpoints. I= t also maps OpenID concepts, such as OpenID Provider, Relying Party, End-= User, and Issuer to their OAuth underpinnings, respectively Authorization= Server, Client, Resource Owner, and the newly introduced Configuration I= nformation Location. Some identifiers with names that appear to be OpenI= D specific were retained for compatibility purposes; despite the reuse of= these identifiers that appear to be OpenID specific, their usage in this= specification is actually referring to general OAuth 2.0 features that a= re not=20 >>> s >>> pecific to OpenID Connect. >>> >>> The specification is available at: >>> >>> * http://tools.ietf.org/html/draft-jones-oauth-discovery-00 <= http://tools.ietf.org/html/draft-jones-oauth-discovery-00> >>> >>> An HTML-formatted version is also available at: >>> >>> * http://self-issued.info/docs/draft-jones-oauth-discovery-00= =2Ehtml >>> >>> -- Mi= ke >>> >>> P.S. This note was also posted at http://self-issued.info/?p=3D1496 = and 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 > From nobody Fri Nov 27 19:58:26 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C38CD1A88C1 for ; Fri, 27 Nov 2015 19:58:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.084 X-Spam-Level: X-Spam-Status: No, score=-0.084 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7TW8ZngU4A1E for ; Fri, 27 Nov 2015 19:58:22 -0800 (PST) Received: from nm35-vm5.bullet.mail.bf1.yahoo.com (nm35-vm5.bullet.mail.bf1.yahoo.com [72.30.238.77]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A90E1A88BD for ; Fri, 27 Nov 2015 19:58:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1448683101; bh=nyBnd4QrrgLBekiyoOYu9Cby+c+36DsVWK1QjgIfS14=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=jx/u1OI8NGmWXdZEOixg0103PNLWQuGKSwGo/clzV2/7XLvaT4gLLxyT6x6dX3iqwYCedani3Vzk3pFD8UWlHW8sIoYPUaToYgSB/QXFIwfCIw+1zrWxHIDbzX4OjkrdAGjKS3IhVI7pEM5eMysVJAP3tEeCsRNxFO/YEclqDUT5Al35hP00ZanIPePg4Nu2kv1UeNFR6XOiK1B2ek8yXUXUkLF6MBCXgx1Rc69lc8fZp7q9FqU/ktudNr6TwJZwIfsWcUy6IP14gevG6/iI0JdZd809iKV6kqq0dMN26A9B7whBl14pT9rUNUVGeKAwYaTdDili0QMBWdjBmgH5Rg== Received: from [98.139.215.142] by nm35.bullet.mail.bf1.yahoo.com with NNFMP; 28 Nov 2015 03:58:21 -0000 Received: from [98.139.212.195] by tm13.bullet.mail.bf1.yahoo.com with NNFMP; 28 Nov 2015 03:58:21 -0000 Received: from [127.0.0.1] by omp1004.mail.bf1.yahoo.com with NNFMP; 28 Nov 2015 03:58:21 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 165902.53822.bm@omp1004.mail.bf1.yahoo.com X-YMail-OSG: AbrpowUVM1l9LNloPqKFslkx1S6SDQklFXRc_zPHf646WVkg4xFJ6_hcmX0CLms 6eJYZQ4_mN.CbdStS0gHootTfYlktLHdJEqU4W3rxMeXXEer9i1soe.NvqXvBEQB335xK68pARzk 5gnYKIHiYy0FpbpY3.yTSX43grXMS2pm7SsJsZSaen_zZeISn7lKEmbPSIYoP2gdhhYV2j0Wc3iK fIQLFRIj2CtXWoGEM6SeUTT3R_6Ka6123aaaoBqkfRpGtfwdHdLa7d17CAe6e9JxUgMy7T1NKepZ 3GLrwp1T2Lb4MfCXczjL1sK78Qe2RWPVKF3I7CYGTIq6sdr8ApNicrVHt2TMCOjsSHP7_PV56lVz ao1NDGMhLgI_NUq8RsZ8dQ7AQKiz5Wc63SKjiLz9Rxm1iP0N1BMexCFgzbcDERXE2KKXikM6MX1X VkDg9du7PzYWB5WMlMbKr9CXsss47vDLSeiRePQiUQHjKyBYcSn.JKSUN3B36ZWDwR0SJsmAmd0o gR.yV1oAN11l2h511oEIptES79AsAyFJ7iY.X6j0G1JhmdQ-- Received: by 66.196.80.193; Sat, 28 Nov 2015 03:58:20 +0000 Date: Sat, 28 Nov 2015 03:58:20 +0000 (UTC) From: Bill Mills To: Mike Jones , "oauth@ietf.org" Message-ID: <128376572.11963058.1448683100369.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_11963057_983591253.1448683100359" Archived-At: Subject: Re: [OAUTH-WG] OAuth Discovery X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2015 03:58:24 -0000 ------=_Part_11963057_983591253.1448683100359 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Can you elaborate on the advantage of having a separate parallel spec to Op= enID Discovery?=20 On Wednesday, November 25, 2015 3:37 PM, Mike Jones wrote: =20 I=E2=80=99m pleased to announce that Nat Sa= kimura, John Bradley, and I have created an OAuth 2.0 Discovery specificati= on.=C2=A0 This fills a hole in the current OAuth specification set that is = necessary to achieve interoperability.=C2=A0 Indeed, theInteroperability se= ction of OAuth 2.0states: In addition, this specification leaves a few requ= ired components partially or fully undefined (e.g., client registration, au= thorization server capabilities, endpoint discovery).=C2=A0 Without these c= omponents, clients must be manually and specifically configured against a s= pecific authorization server and resource server in order to interoperate. = =C2=A0 This framework was designed with the clear expectation that future = work will define prescriptive profiles and extensions necessary to achieve = full web-scale interoperability. =C2=A0 This specification enables discove= ry of both endpoint locations and authorization server capabilities. =C2= =A0 This specification is based upon the already widely deployedOpenID Conn= ect Discovery 1.0 specification and is compatible with it, by design.=C2=A0= The OAuth Discovery spec removes the portions of OpenID Connect Discovery = that are OpenID specific and adds metadata values for Revocation and Intros= pection endpoints.=C2=A0 It also maps OpenID concepts, such as OpenID Provi= der, Relying Party, End-User, and Issuer to their OAuth underpinnings, resp= ectively Authorization Server, Client, Resource Owner, and the newly introd= uced Configuration Information Location. =C2=A0Some identifiers with names = that appear to be OpenID specific were retained for compatibility purposes;= despite the reuse of these identifiers that appear to be OpenID specific, = their usage in this specification is actually referring to general OAuth 2.= 0 features that are not specific to OpenID Connect. =C2=A0 The specificati= on is available at: =C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0h= ttp://tools.ietf.org/html/draft-jones-oauth-discovery-00 =C2=A0 An HTML-fo= rmatted version is also available at: =C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0http://self-issued.info/docs/draft-jones-oauth-discovery-= 00.html =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=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 note was also posted at = http://self-issued.info/?p=3D1496 and as @selfissued.=20 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ------=_Part_11963057_983591253.1448683100359 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Can you elaborate on the advantage of= having a separate parallel spec to OpenID Discovery?



On Wednesday, November 25, 2015 3:37 PM, Mike Jones <Michae= l.Jones@microsoft.com> wrote:


=20 =20
I=E2=80=99m pleased to announce that = Nat Sakimura, John Bradley, and I have created an OAuth 2.0 Discovery speci= fication.  This fills a hole in the current OAuth specification set th= at is necessary to achieve interoperability.  Indeed, the Interoperability section of OAuth 2.0 states:
=20 
In addition, this specification leaves a few required components partia=
lly or fully undefined (e.g., client registration, authorization server cap=
abilities, endpoint discovery).  Without these components, clients mus=
t be manually and specifically configured against a specific authorization =
server and resource server in order to interoperate.
=20 
  
=20 
This framework was designed with the clear expectation that future work=
 will define prescriptive profiles and extensions necessary to achieve full=
 web-scale interoperability.
=20
 =20
This specification = enables discovery of both endpoint locations and authorization server capab= ilities.
=20
 =20
This specification = is based upon the already widely deployed OpenID Connect Discovery 1.0 specificatio= n and is compatible with it, by design.  The OAuth Discovery spec remo= ves the portions of OpenID Connect Discovery that are OpenID specific and adds metadata values for Revocation and Introspection endpoints.  It = also maps OpenID concepts, such as OpenID Provider, Relying Party, End-User= , and Issuer to their OAuth underpinnings, respectively Authorization Serve= r, Client, Resource Owner, and the newly introduced Configuration Information Location.  Some identifiers with= names that appear to be OpenID specific were retained for compatibility pu= rposes; despite the reuse of these identifiers that appear to be OpenID spe= cific, their usage in this specification is actually referring to general OAuth 2.0 features that are not specific = to OpenID Connect.
=20
 =20
The specification i= s available at:
=20
=C2=B7         http:/= /tools.ietf.org/html/draft-jones-oauth-discovery-00
=20
 =20
An HTML-formatted v= ersion is also available at:
=20
=C2=B7         http://self-issued.info/docs/draft-jones-oau= th-discovery-00.html
=20
 =20
   &= nbsp;            &nb= sp;            =             &nb= sp;            =           -- Mike
= =20
 =20
P.S.  This not= e was also posted at http://self-issued.info/?p=3D1496 and as @selfissued.
=20

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

------=_Part_11963057_983591253.1448683100359-- From nobody Fri Nov 27 20:05:55 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B92C1A88D6 for ; Fri, 27 Nov 2015 20:05:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13H8ol7QbD_F for ; Fri, 27 Nov 2015 20:05:48 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0125.outbound.protection.outlook.com [207.46.100.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DD1C1A88D5 for ; Fri, 27 Nov 2015 20:05:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=YD8yh5/HR+Tepi/S57XnzCjeBBuZ0dlbqHjuO2OV6Ko=; b=A85Zxb9q9tKSPV3DarcclvWsZEPa84tVJSZ4M8zSs5GDsFOYZtPja6z+/YY1SRM12PlBzPyUjSNODZtRojwHOAjlvn23NH+AyID6mmMZ6EUIhdlQuXErtqgDWL4Skt5IzjkGOB9f41i/593h2ku4Eb6VtJxkQdmVU+WZBETCT54= Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) with Microsoft SMTP Server (TLS) id 15.1.331.20; Sat, 28 Nov 2015 04:05:46 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0331.023; Sat, 28 Nov 2015 04:05:46 +0000 From: Mike Jones To: Bill Mills , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] OAuth Discovery Thread-Index: AdEnv6MqmLA/Ph7MT4qJwfYSFGITHwB0WHAAAAA37DA= Date: Sat, 28 Nov 2015 04:05:45 +0000 Message-ID: References: <128376572.11963058.1448683100369.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <128376572.11963058.1448683100369.JavaMail.yahoo@mail.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [50.47.85.157] x-microsoft-exchange-diagnostics: 1; BY2PR03MB442; 5:Goix8bNg6SmopfiGF9OIHHcT4pcPZWJXC5B2Df9uqcSh+HkT49mXb09Jid9xfHBDRMQMDTKM66eGwpYhXYeGJg52YFs76nd0uuEXMDBtR+h4IVMy6tyHulV8EoGsSaxJga1nxDu5Y0g8j6aXMfQiLw==; 24:Y0GWgHElcJZ6OAjj/QRw7Hw54a5h55eCi5RH5GL3rd17Y+wdLwE3JCnZDOOptSZuSP5ZxUghp2GOy01Rhs7U1OW24HGVBnePuLT9v8w2vJA= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB442; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(201166117486090)(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425024)(601004)(2401047)(8121501046)(5005006)(520078)(10201501046)(3002001)(61426024)(61427024); SRVR:BY2PR03MB442; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB442; x-forefront-prvs: 07749F8C42 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(209900001)(189002)(24454002)(199003)(377454003)(5001770100001)(92566002)(790700001)(54356999)(33656002)(66066001)(74316001)(2501003)(10090500001)(19617315012)(5008740100001)(15975445007)(11100500001)(15395725005)(86612001)(19580405001)(19580395003)(16236675004)(5004730100002)(1220700001)(87936001)(40100003)(2521001)(97736004)(2950100001)(77096005)(86362001)(19300405004)(101416001)(19609705001)(122556002)(5002640100001)(586003)(6116002)(5005710100001)(10400500002)(189998001)(81156007)(106356001)(105586002)(2900100001)(50986999)(5001960100002)(102836003)(76576001)(3846002)(76176999)(1096002)(10290500002)(107886002)(8990500004)(19625215002)(5003600100002)(99286002)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB442; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR03MB442BDB413693994CA405044F5020BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Nov 2015 04:05:45.7125 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB442 Archived-At: Subject: Re: [OAUTH-WG] OAuth Discovery X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2015 04:05:51 -0000 --_000_BY2PR03MB442BDB413693994CA405044F5020BY2PR03MB442namprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SXQgYWxsb3dzIG5vbi1Db25uZWN0IGltcGxlbWVudGF0aW9uIG9mIE9BdXRoIDIuMCB0byBhbHNv IGhhdmUgYSBzdGFuZGFyZCBkaXNjb3ZlcnkgY2FwYWJpbGl0eSDigJMgYW5kIG9uZSB0aGF0IGNh biBsYXRlciBiZSB1cGRhdGVkIHRvIGFsc28gc3VwcG9ydCBPcGVuSUQgQ29ubmVjdCB3aXRoIG5v IGJyZWFraW5nIGNoYW5nZXMsIHNob3VsZCB0aGF0IGJlIGRlc2lyZWQgaW4gdGhlIGZ1dHVyZS4N Cg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIC0tIE1pa2UNCg0KRnJvbTogQmlsbCBNaWxscyBbbWFpbHRvOndtaWxsc185MjEwNUB5YWhv by5jb21dDQpTZW50OiBGcmlkYXksIE5vdmVtYmVyIDI3LCAyMDE1IDc6NTggUE0NClRvOiBNaWtl IEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+OyBvYXV0aEBpZXRmLm9yZw0KU3Vi amVjdDogUmU6IFtPQVVUSC1XR10gT0F1dGggRGlzY292ZXJ5DQoNCkNhbiB5b3UgZWxhYm9yYXRl IG9uIHRoZSBhZHZhbnRhZ2Ugb2YgaGF2aW5nIGEgc2VwYXJhdGUgcGFyYWxsZWwgc3BlYyB0byBP cGVuSUQgRGlzY292ZXJ5Pw0KDQoNCk9uIFdlZG5lc2RheSwgTm92ZW1iZXIgMjUsIDIwMTUgMzoz NyBQTSwgTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPG1haWx0bzpNaWNo YWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+PiB3cm90ZToNCg0KSeKAmW0gcGxlYXNlZCB0byBhbm5v dW5jZSB0aGF0IE5hdCBTYWtpbXVyYSwgSm9obiBCcmFkbGV5LCBhbmQgSSBoYXZlIGNyZWF0ZWQg YW4gT0F1dGggMi4wIERpc2NvdmVyeSBzcGVjaWZpY2F0aW9uLiAgVGhpcyBmaWxscyBhIGhvbGUg aW4gdGhlIGN1cnJlbnQgT0F1dGggc3BlY2lmaWNhdGlvbiBzZXQgdGhhdCBpcyBuZWNlc3Nhcnkg dG8gYWNoaWV2ZSBpbnRlcm9wZXJhYmlsaXR5LiAgSW5kZWVkLCB0aGUgSW50ZXJvcGVyYWJpbGl0 eSBzZWN0aW9uIG9mIE9BdXRoIDIuMCA8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzY3 NDkjc2VjdGlvbi0xLjg+IHN0YXRlczoNCg0KSW4gYWRkaXRpb24sIHRoaXMgc3BlY2lmaWNhdGlv biBsZWF2ZXMgYSBmZXcgcmVxdWlyZWQgY29tcG9uZW50cyBwYXJ0aWFsbHkgb3IgZnVsbHkgdW5k ZWZpbmVkIChlLmcuLCBjbGllbnQgcmVnaXN0cmF0aW9uLCBhdXRob3JpemF0aW9uIHNlcnZlciBj YXBhYmlsaXRpZXMsIGVuZHBvaW50IGRpc2NvdmVyeSkuICBXaXRob3V0IHRoZXNlIGNvbXBvbmVu dHMsIGNsaWVudHMgbXVzdCBiZSBtYW51YWxseSBhbmQgc3BlY2lmaWNhbGx5IGNvbmZpZ3VyZWQg YWdhaW5zdCBhIHNwZWNpZmljIGF1dGhvcml6YXRpb24gc2VydmVyIGFuZCByZXNvdXJjZSBzZXJ2 ZXIgaW4gb3JkZXIgdG8gaW50ZXJvcGVyYXRlLg0KDQoNCg0KVGhpcyBmcmFtZXdvcmsgd2FzIGRl c2lnbmVkIHdpdGggdGhlIGNsZWFyIGV4cGVjdGF0aW9uIHRoYXQgZnV0dXJlIHdvcmsgd2lsbCBk ZWZpbmUgcHJlc2NyaXB0aXZlIHByb2ZpbGVzIGFuZCBleHRlbnNpb25zIG5lY2Vzc2FyeSB0byBh Y2hpZXZlIGZ1bGwgd2ViLXNjYWxlIGludGVyb3BlcmFiaWxpdHkuDQoNClRoaXMgc3BlY2lmaWNh dGlvbiBlbmFibGVzIGRpc2NvdmVyeSBvZiBib3RoIGVuZHBvaW50IGxvY2F0aW9ucyBhbmQgYXV0 aG9yaXphdGlvbiBzZXJ2ZXIgY2FwYWJpbGl0aWVzLg0KDQpUaGlzIHNwZWNpZmljYXRpb24gaXMg YmFzZWQgdXBvbiB0aGUgYWxyZWFkeSB3aWRlbHkgZGVwbG95ZWQgT3BlbklEIENvbm5lY3QgRGlz Y292ZXJ5IDEuMDxodHRwOi8vb3BlbmlkLm5ldC9zcGVjcy9vcGVuaWQtY29ubmVjdC1kaXNjb3Zl cnktMV8wLmh0bWw+IHNwZWNpZmljYXRpb24gYW5kIGlzIGNvbXBhdGlibGUgd2l0aCBpdCwgYnkg ZGVzaWduLiAgVGhlIE9BdXRoIERpc2NvdmVyeSBzcGVjIHJlbW92ZXMgdGhlIHBvcnRpb25zIG9m IE9wZW5JRCBDb25uZWN0IERpc2NvdmVyeSB0aGF0IGFyZSBPcGVuSUQgc3BlY2lmaWMgYW5kIGFk ZHMgbWV0YWRhdGEgdmFsdWVzIGZvciBSZXZvY2F0aW9uIGFuZCBJbnRyb3NwZWN0aW9uIGVuZHBv aW50cy4gIEl0IGFsc28gbWFwcyBPcGVuSUQgY29uY2VwdHMsIHN1Y2ggYXMgT3BlbklEIFByb3Zp ZGVyLCBSZWx5aW5nIFBhcnR5LCBFbmQtVXNlciwgYW5kIElzc3VlciB0byB0aGVpciBPQXV0aCB1 bmRlcnBpbm5pbmdzLCByZXNwZWN0aXZlbHkgQXV0aG9yaXphdGlvbiBTZXJ2ZXIsIENsaWVudCwg UmVzb3VyY2UgT3duZXIsIGFuZCB0aGUgbmV3bHkgaW50cm9kdWNlZCBDb25maWd1cmF0aW9uIElu Zm9ybWF0aW9uIExvY2F0aW9uLiAgU29tZSBpZGVudGlmaWVycyB3aXRoIG5hbWVzIHRoYXQgYXBw ZWFyIHRvIGJlIE9wZW5JRCBzcGVjaWZpYyB3ZXJlIHJldGFpbmVkIGZvciBjb21wYXRpYmlsaXR5 IHB1cnBvc2VzOyBkZXNwaXRlIHRoZSByZXVzZSBvZiB0aGVzZSBpZGVudGlmaWVycyB0aGF0IGFw cGVhciB0byBiZSBPcGVuSUQgc3BlY2lmaWMsIHRoZWlyIHVzYWdlIGluIHRoaXMgc3BlY2lmaWNh dGlvbiBpcyBhY3R1YWxseSByZWZlcnJpbmcgdG8gZ2VuZXJhbCBPQXV0aCAyLjAgZmVhdHVyZXMg dGhhdCBhcmUgbm90IHNwZWNpZmljIHRvIE9wZW5JRCBDb25uZWN0Lg0KDQpUaGUgc3BlY2lmaWNh dGlvbiBpcyBhdmFpbGFibGUgYXQ6DQrigKIgICAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1qb25lcy1vYXV0aC1kaXNjb3ZlcnktMDANCg0KQW4gSFRNTC1mb3JtYXR0ZWQg dmVyc2lvbiBpcyBhbHNvIGF2YWlsYWJsZSBhdDoNCuKAoiAgICAgICAgIGh0dHA6Ly9zZWxmLWlz c3VlZC5pbmZvL2RvY3MvZHJhZnQtam9uZXMtb2F1dGgtZGlzY292ZXJ5LTAwLmh0bWwNCg0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIC0tIE1pa2UNCg0KUC5TLiAgVGhpcyBub3RlIHdhcyBhbHNvIHBvc3RlZCBhdCBodHRwOi8v c2VsZi1pc3N1ZWQuaW5mby8/cD0xNDk2IGFuZCBhcyBAc2VsZmlzc3VlZDxodHRwczovL3R3aXR0 ZXIuY29tL3NlbGZpc3N1ZWQ+Lg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86 T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29h dXRoDQoNCg== --_000_BY2PR03MB442BDB413693994CA405044F5020BY2PR03MB442namprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsN CglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAq Lw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGlu Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6 IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTou MDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9 DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHls ZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmln aHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsN Cglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlm O30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJl Zm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnAueWl2MjEw MTg2MDMwNG1zb2xpc3RwYXJhZ3JhcGgsIGxpLnlpdjIxMDE4NjAzMDRtc29saXN0cGFyYWdyYXBo LCBkaXYueWl2MjEwMTg2MDMwNG1zb2xpc3RwYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLW5hbWU6eWl2 MjEwMTg2MDMwNG1zb2xpc3RwYXJhZ3JhcGg7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJ bWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4t bGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIixzZXJpZjt9DQpwLnlpdjIxMDE4NjAzMDRtc29ub3JtYWwsIGxpLnlpdjIxMDE4NjAzMDRt c29ub3JtYWwsIGRpdi55aXYyMTAxODYwMzA0bXNvbm9ybWFsDQoJe21zby1zdHlsZS1uYW1lOnlp djIxMDE4NjAzMDRtc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2lu LXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDow aW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixz ZXJpZjt9DQpzcGFuLnlpdjIxMDE4NjAzMDRtc29oeXBlcmxpbmsNCgl7bXNvLXN0eWxlLW5hbWU6 eWl2MjEwMTg2MDMwNG1zb2h5cGVybGluazt9DQpzcGFuLnlpdjIxMDE4NjAzMDRtc29oeXBlcmxp bmtmb2xsb3dlZA0KCXttc28tc3R5bGUtbmFtZTp5aXYyMTAxODYwMzA0bXNvaHlwZXJsaW5rZm9s bG93ZWQ7fQ0Kc3Bhbi55aXYyMTAxODYwMzA0ZW1haWxzdHlsZTE3DQoJe21zby1zdHlsZS1uYW1l OnlpdjIxMDE4NjAzMDRlbWFpbHN0eWxlMTc7fQ0Kc3Bhbi55aXYyMTAxODYwMzA0aHRtbHByZWZv cm1hdHRlZGNoYXINCgl7bXNvLXN0eWxlLW5hbWU6eWl2MjEwMTg2MDMwNGh0bWxwcmVmb3JtYXR0 ZWRjaGFyO30NCnAueWl2MjEwMTg2MDMwNG1zb25vcm1hbDEsIGxpLnlpdjIxMDE4NjAzMDRtc29u b3JtYWwxLCBkaXYueWl2MjEwMTg2MDMwNG1zb25vcm1hbDENCgl7bXNvLXN0eWxlLW5hbWU6eWl2 MjEwMTg2MDMwNG1zb25vcm1hbDE7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp Zjt9DQpzcGFuLnlpdjIxMDE4NjAzMDRtc29oeXBlcmxpbmsxDQoJe21zby1zdHlsZS1uYW1lOnlp djIxMDE4NjAzMDRtc29oeXBlcmxpbmsxOw0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTt9DQpzcGFuLnlpdjIxMDE4NjAzMDRtc29oeXBlcmxpbmtmb2xsb3dlZDEN Cgl7bXNvLXN0eWxlLW5hbWU6eWl2MjEwMTg2MDMwNG1zb2h5cGVybGlua2ZvbGxvd2VkMTsNCglj b2xvcjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC55aXYyMTAxODYw MzA0bXNvbGlzdHBhcmFncmFwaDEsIGxpLnlpdjIxMDE4NjAzMDRtc29saXN0cGFyYWdyYXBoMSwg ZGl2LnlpdjIxMDE4NjAzMDRtc29saXN0cGFyYWdyYXBoMQ0KCXttc28tc3R5bGUtbmFtZTp5aXYy MTAxODYwMzA0bXNvbGlzdHBhcmFncmFwaDE7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJp Z2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmO30NCnNwYW4ueWl2MjEwMTg2MDMwNGVtYWlsc3R5bGUxNzENCgl7bXNv LXN0eWxlLW5hbWU6eWl2MjEwMTg2MDMwNGVtYWlsc3R5bGUxNzE7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLnlpdjIxMDE4NjAz MDRodG1scHJlZm9ybWF0dGVkY2hhcjENCgl7bXNvLXN0eWxlLW5hbWU6eWl2MjEwMTg2MDMwNGh0 bWxwcmVmb3JtYXR0ZWRjaGFyMTsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnNwYW4u RW1haWxTdHlsZTMyDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMwMDIwNjA7fQ0KLk1zb0NocERlZmF1 bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpA cGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEu MGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7 fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMg djpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFw IHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlm XS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJw bGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj5JdCBhbGxvd3Mgbm9uLUNvbm5lY3QgaW1wbGVt ZW50YXRpb24gb2YgT0F1dGggMi4wIHRvIGFsc28gaGF2ZSBhIHN0YW5kYXJkIGRpc2NvdmVyeSBj YXBhYmlsaXR5IOKAkyBhbmQgb25lIHRoYXQgY2FuIGxhdGVyIGJlIHVwZGF0ZWQgdG8gYWxzbyBz dXBwb3J0IE9wZW5JRCBDb25uZWN0DQogd2l0aCBubyBicmVha2luZyBjaGFuZ2VzLCBzaG91bGQg dGhhdCBiZSBkZXNpcmVkIGluIHRoZSBmdXR1cmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8c3BhbiBzdHls ZT0ibXNvLWJvb2ttYXJrOl9NYWlsRW5kQ29tcG9zZSI+PC9zcGFuPg0KPGRpdj4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMu MHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IEJpbGwgTWlsbHMgW21haWx0bzp3 bWlsbHNfOTIxMDVAeWFob28uY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgTm92ZW1i ZXIgMjcsIDIwMTUgNzo1OCBQTTxicj4NCjxiPlRvOjwvYj4gTWlrZSBKb25lcyAmbHQ7TWljaGFl bC5Kb25lc0BtaWNyb3NvZnQuY29tJmd0Ozsgb2F1dGhAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0 OjwvYj4gUmU6IFtPQVVUSC1XR10gT0F1dGggRGlzY292ZXJ5PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3Vu ZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Q2FuIHlvdSBlbGFib3JhdGUg b24gdGhlIGFkdmFudGFnZSBvZiBoYXZpbmcgYSBzZXBhcmF0ZSBwYXJhbGxlbCBzcGVjIHRvIE9w ZW5JRCBEaXNjb3Zlcnk/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdDtiYWNrZ3JvdW5kOndoaXRlIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+T24g V2VkbmVzZGF5LCBOb3ZlbWJlciAyNSwgMjAxNSAzOjM3IFBNLCBNaWtlIEpvbmVzICZsdDs8YSBo cmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tIj5NaWNoYWVsLkpvbmVzQG1p Y3Jvc29mdC5jb208L2E+Jmd0OyB3cm90ZTo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t Ym90dG9tOjEyLjBwdDtiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IGlkPSJ5aXYyMTAxODYwMzA0Ij4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndo aXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6YmxhY2siPknigJltIHBsZWFzZWQgdG8gYW5ub3VuY2UgdGhhdCBOYXQgU2Fr aW11cmEsIEpvaG4gQnJhZGxleSwgYW5kIEkgaGF2ZSBjcmVhdGVkIGFuIE9BdXRoIDIuMCBEaXNj b3Zlcnkgc3BlY2lmaWNhdGlvbi4mbmJzcDsgVGhpcyBmaWxscyBhIGhvbGUgaW4gdGhlIGN1cnJl bnQgT0F1dGgNCiBzcGVjaWZpY2F0aW9uIHNldCB0aGF0IGlzIG5lY2Vzc2FyeSB0byBhY2hpZXZl IGludGVyb3BlcmFiaWxpdHkuJm5ic3A7IEluZGVlZCwgdGhlIDxhIGhyZWY9Imh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9yZmM2NzQ5I3NlY3Rpb24tMS44IiB0YXJnZXQ9Il9ibGFuayI+DQpJ bnRlcm9wZXJhYmlsaXR5IHNlY3Rpb24gb2YgT0F1dGggMi4wIDwvYT5zdGF0ZXM6PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluO2JhY2tn cm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xv cjpibGFjayI+SW4gYWRkaXRpb24sIHRoaXMgc3BlY2lmaWNhdGlvbiBsZWF2ZXMgYSBmZXcgcmVx dWlyZWQgY29tcG9uZW50cyBwYXJ0aWFsbHkgb3IgZnVsbHkgdW5kZWZpbmVkIChlLmcuLCBjbGll bnQgcmVnaXN0cmF0aW9uLCBhdXRob3JpemF0aW9uIHNlcnZlciBjYXBhYmlsaXRpZXMsIGVuZHBv aW50IGRpc2NvdmVyeSkuJm5ic3A7IFdpdGhvdXQgdGhlc2UgY29tcG9uZW50cywgY2xpZW50cyBt dXN0IGJlIG1hbnVhbGx5IGFuZCBzcGVjaWZpY2FsbHkgY29uZmlndXJlZCBhZ2FpbnN0IGEgc3Bl Y2lmaWMgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgYW5kIHJlc291cmNlIHNlcnZlciBpbiBvcmRlciB0 byBpbnRlcm9wZXJhdGUuPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286 cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluO2JhY2tncm91bmQ6 d2hpdGUiPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjpibGFj ayI+ICZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9z cGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbjtiYWNrZ3JvdW5kOndoaXRl Ij48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6YmxhY2siPlRo aXMgZnJhbWV3b3JrIHdhcyBkZXNpZ25lZCB3aXRoIHRoZSBjbGVhciBleHBlY3RhdGlvbiB0aGF0 IGZ1dHVyZSB3b3JrIHdpbGwgZGVmaW5lIHByZXNjcmlwdGl2ZSBwcm9maWxlcyBhbmQgZXh0ZW5z aW9ucyBuZWNlc3NhcnkgdG8gYWNoaWV2ZSBmdWxsIHdlYi1zY2FsZSBpbnRlcm9wZXJhYmlsaXR5 Ljwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48 c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+VGhpcyBzcGVjaWZp Y2F0aW9uIGVuYWJsZXMgZGlzY292ZXJ5IG9mIGJvdGggZW5kcG9pbnQgbG9jYXRpb25zIGFuZCBh dXRob3JpemF0aW9uIHNlcnZlciBjYXBhYmlsaXRpZXMuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOzwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5n PSJFTiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOmJsYWNrIj5UaGlzIHNwZWNpZmljYXRpb24gaXMgYmFzZWQgdXBvbiB0aGUgYWxyZWFk eSB3aWRlbHkgZGVwbG95ZWQNCjxhIGhyZWY9Imh0dHA6Ly9vcGVuaWQubmV0L3NwZWNzL29wZW5p ZC1jb25uZWN0LWRpc2NvdmVyeS0xXzAuaHRtbCIgdGFyZ2V0PSJfYmxhbmsiPg0KT3BlbklEIENv bm5lY3QgRGlzY292ZXJ5IDEuMDwvYT4gc3BlY2lmaWNhdGlvbiBhbmQgaXMgY29tcGF0aWJsZSB3 aXRoIGl0LCBieSBkZXNpZ24uJm5ic3A7IFRoZSBPQXV0aCBEaXNjb3Zlcnkgc3BlYyByZW1vdmVz IHRoZSBwb3J0aW9ucyBvZiBPcGVuSUQgQ29ubmVjdCBEaXNjb3ZlcnkgdGhhdCBhcmUgT3BlbklE IHNwZWNpZmljIGFuZCBhZGRzIG1ldGFkYXRhIHZhbHVlcyBmb3IgUmV2b2NhdGlvbiBhbmQgSW50 cm9zcGVjdGlvbiBlbmRwb2ludHMuJm5ic3A7IEl0DQogYWxzbyBtYXBzIE9wZW5JRCBjb25jZXB0 cywgc3VjaCBhcyBPcGVuSUQgUHJvdmlkZXIsIFJlbHlpbmcgUGFydHksIEVuZC1Vc2VyLCBhbmQg SXNzdWVyIHRvIHRoZWlyIE9BdXRoIHVuZGVycGlubmluZ3MsIHJlc3BlY3RpdmVseSBBdXRob3Jp emF0aW9uIFNlcnZlciwgQ2xpZW50LCBSZXNvdXJjZSBPd25lciwgYW5kIHRoZSBuZXdseSBpbnRy b2R1Y2VkIENvbmZpZ3VyYXRpb24gSW5mb3JtYXRpb24gTG9jYXRpb24uICZuYnNwO1NvbWUgaWRl bnRpZmllcnMNCiB3aXRoIG5hbWVzIHRoYXQgYXBwZWFyIHRvIGJlIE9wZW5JRCBzcGVjaWZpYyB3 ZXJlIHJldGFpbmVkIGZvciBjb21wYXRpYmlsaXR5IHB1cnBvc2VzOyBkZXNwaXRlIHRoZSByZXVz ZSBvZiB0aGVzZSBpZGVudGlmaWVycyB0aGF0IGFwcGVhciB0byBiZSBPcGVuSUQgc3BlY2lmaWMs IHRoZWlyIHVzYWdlIGluIHRoaXMgc3BlY2lmaWNhdGlvbiBpcyBhY3R1YWxseSByZWZlcnJpbmcg dG8gZ2VuZXJhbCBPQXV0aCAyLjAgZmVhdHVyZXMgdGhhdCBhcmUNCiBub3Qgc3BlY2lmaWMgdG8g T3BlbklEIENvbm5lY3QuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6 d2hpdGUiPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2si PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5UaGUg c3BlY2lmaWNhdGlvbiBpcyBhdmFpbGFibGUgYXQ6PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1mYW1pbHk6 U3ltYm9sO2NvbG9yOmJsYWNrIj7Ctzwvc3Bhbj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQt c2l6ZTo3LjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1zaXplOjcu MHB0O2ZvbnQtZmFtaWx5OlN5bWJvbDtjb2xvcjpibGFjayI+DQo8L3NwYW4+PHNwYW4gbGFuZz0i RU4iIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjpibGFjayI+PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtam9u ZXMtb2F1dGgtZGlzY292ZXJ5LTAwIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtam9uZXMtb2F1dGgtZGlzY292ZXJ5LTAwPC9hPjwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNr Ij4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+ PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjpibGFjayI+QW4gSFRNTC1mb3JtYXR0ZWQgdmVyc2lvbiBpcyBhbHNv IGF2YWlsYWJsZSBhdDo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3 aGl0ZSI+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LWZhbWlseTpTeW1ib2w7Y29sb3I6Ymxh Y2siPsK3PC9zcGFuPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2NvbG9y OmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8 L3NwYW4+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk6 U3ltYm9sO2NvbG9yOmJsYWNrIj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFj ayI+PGEgaHJlZj0iaHR0cDovL3NlbGYtaXNzdWVkLmluZm8vZG9jcy9kcmFmdC1qb25lcy1vYXV0 aC1kaXNjb3ZlcnktMDAuaHRtbCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9zZWxmLWlzc3VlZC5p bmZvL2RvY3MvZHJhZnQtam9uZXMtb2F1dGgtZGlzY292ZXJ5LTAwLmh0bWw8L2E+PC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOIiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndo aXRlIj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IC0tIE1pa2U8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0 ZSI+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPlAuUy4mbmJz cDsgVGhpcyBub3RlIHdhcyBhbHNvIHBvc3RlZCBhdA0KPGEgaHJlZj0iaHR0cDovL3NlbGYtaXNz dWVkLmluZm8vP3A9MTQ5NiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9zZWxmLWlzc3VlZC5pbmZv Lz9wPTE0OTY8L2E+IGFuZCBhcw0KPGEgaHJlZj0iaHR0cHM6Ly90d2l0dGVyLmNvbS9zZWxmaXNz dWVkIiB0YXJnZXQ9Il9ibGFuayI+QHNlbGZpc3N1ZWQ8L2E+Ljwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2si PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0O2JhY2tncm91 bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVm PSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2Js YW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxicj4N Cjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BY2PR03MB442BDB413693994CA405044F5020BY2PR03MB442namprd_-- From nobody Fri Nov 27 20:43:40 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2DDF1A8A5A for ; Fri, 27 Nov 2015 20:43:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.784 X-Spam-Level: X-Spam-Status: No, score=-4.784 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IZ7liB-glHHb for ; Fri, 27 Nov 2015 20:43:36 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9532A1A8A56 for ; Fri, 27 Nov 2015 20:43:36 -0800 (PST) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id tAS4hZCB021684 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 28 Nov 2015 04:43:36 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id tAS4hYUV015627 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 28 Nov 2015 04:43:35 GMT Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by userv0122.oracle.com (8.13.8/8.13.8) with ESMTP id tAS4hYRS032053; Sat, 28 Nov 2015 04:43:34 GMT Received: from [192.168.1.27] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 27 Nov 2015 20:43:34 -0800 Content-Type: multipart/alternative; boundary=Apple-Mail-AC0AF273-E1D9-41CE-833F-BCA34A2DFBFD Mime-Version: 1.0 (1.0) From: Phil Hunt X-Mailer: iPhone Mail (13B143) In-Reply-To: Date: Fri, 27 Nov 2015 20:43:32 -0800 Content-Transfer-Encoding: 7bit Message-Id: <5F43839D-06E7-4E56-BAAC-0F0DE3A553D7@oracle.com> References: <128376572.11963058.1448683100369.JavaMail.yahoo@mail.yahoo.com> To: Mike Jones X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth Discovery X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2015 04:43:38 -0000 --Apple-Mail-AC0AF273-E1D9-41CE-833F-BCA34A2DFBFD Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable While it is good to start with the connect spec, i would caution on the assu= mption of compatibility. More than likely there will be changes based on bro= ader cases.=20 I would like to understand these broader requirements, use cases, and securi= ty considerations first.=20 Phil > On Nov 27, 2015, at 20:05, Mike Jones wrote:= >=20 > It allows non-Connect implementation of OAuth 2.0 to also have a standard d= iscovery capability =E2=80=93 and one that can later be updated to also supp= ort OpenID Connect with no breaking changes, should that be desired in the f= uture. > =20 > -- Mike > =20 > From: Bill Mills [mailto:wmills_92105@yahoo.com]=20 > Sent: Friday, November 27, 2015 7:58 PM > To: Mike Jones ; oauth@ietf.org > Subject: Re: [OAUTH-WG] OAuth Discovery > =20 > Can you elaborate on the advantage of having a separate parallel spec to O= penID Discovery? > =20 > =20 >=20 > On Wednesday, November 25, 2015 3:37 PM, Mike Jones wrote: > =20 >=20 > I=E2=80=99m pleased to announce that Nat Sakimura, John Bradley, and I hav= e created an OAuth 2.0 Discovery specification. This fills a hole in the cu= rrent OAuth specification set that is necessary to achieve interoperability.= Indeed, the Interoperability section of OAuth 2.0 states: > In addition, this specification leaves a few required components partially= or fully undefined (e.g., client registration, authorization server capabil= ities, endpoint discovery). Without these components, clients must be manua= lly and specifically configured against a specific authorization server and r= esource server in order to interoperate. > =20 > This framework was designed with the clear expectation that future work wi= ll define prescriptive profiles and extensions necessary to achieve full web= -scale interoperability. > =20 > This specification enables discovery of both endpoint locations and author= ization server capabilities. > =20 > This specification is based upon the already widely deployed OpenID Connec= t Discovery 1.0 specification and is compatible with it, by design. The OAu= th Discovery spec removes the portions of OpenID Connect Discovery that are O= penID specific and adds metadata values for Revocation and Introspection end= points. It also maps OpenID concepts, such as OpenID Provider, Relying Part= y, End-User, and Issuer to their OAuth underpinnings, respectively Authoriza= tion Server, Client, Resource Owner, and the newly introduced Configuration I= nformation Location. Some identifiers with names that appear to be OpenID s= pecific were retained for compatibility purposes; despite the reuse of these= identifiers that appear to be OpenID specific, their usage in this specific= ation is actually referring to general OAuth 2.0 features that are not speci= fic to OpenID Connect. > =20 > The specification is available at: > =C2=B7 http://tools.ietf.org/html/draft-jones-oauth-discovery-00 > =20 > An HTML-formatted version is also available at: > =C2=B7 http://self-issued.info/docs/draft-jones-oauth-discovery-00= .html > =20 > -- Mike > =20 > P.S. This note was also posted at http://self-issued.info/?p=3D1496 and a= s @selfissued. >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-AC0AF273-E1D9-41CE-833F-BCA34A2DFBFD Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
While it is good to start with the con= nect spec, i would caution on the assumption of compatibility. More than lik= ely there will be changes based on broader cases. 

I would like to und= erstand these broader requirements, use cases, and security considerations f= irst. 



Phil

On Nov 27, 2015, at 20:05, Mike Jone= s <Michael.Jones@microsoft= .com> wrote:

It allows non-Connect implementation of= OAuth 2.0 to also have a standard discovery capability =E2=80=93 and one th= at can later be updated to also support OpenID Connect with no breaking changes, should that be desired in the future.<= /span>

 

      &nb= sp;            &= nbsp;            = ;            &nb= sp;             -= - Mike

 =

From: Bill Mills [mailto:wmills_92105@yahoo.com]
Sent: Friday, November 27, 2015 7:58 PM
To: Mike Jones <Mic= hael.Jones@microsoft.com>; oauth@ie= tf.org
Subject: Re: [OAUTH-WG] OAuth Discovery

 

Can you elabo= rate on the advantage of having a separate parallel spec to OpenID Discovery= ?

 

 

On Wednesday, No= vember 25, 2015 3:37 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:<= /p>

&nb= sp;

I=E2=80=99m pleased to announ= ce that Nat Sakimura, John Bradley, and I have created an OAuth 2.0 Discover= y specification.  This fills a hole in the current OAuth specification set that is necessary to achieve interoperability.  Inde= ed, the Interoperability section of OAuth 2.0 states:

In addition, this specification leaves a few r=
equired components partially or fully undefined (e.g., client registration, a=
uthorization server capabilities, endpoint discovery).  Without these c=
omponents, clients must be manually and specifically configured against a sp=
ecific authorization server and resource server in order to interoperate.
  
This framework was designed with the clear exp=
ectation that future work will define prescriptive profiles and extensions n=
ecessary to achieve full web-scale interoperability.

 

This specificatio= n enables discovery of both endpoint locations and authorization server capa= bilities.

 

This specificatio= n is based upon the already widely deployed OpenID Connect Discovery 1.0 specification and is compatible with it, by= design.  The OAuth Discovery spec removes the portions of OpenID Conne= ct Discovery that are OpenID specific and adds metadata values for Revocatio= n and Introspection endpoints.  It also maps OpenID concepts, such as OpenID Provider, Relying Party, End-User= , and Issuer to their OAuth underpinnings, respectively Authorization Server= , Client, Resource Owner, and the newly introduced Configuration Information= Location.  Some identifiers with names that appear to be OpenID specific were retained for compatibilit= y purposes; despite the reuse of these identifiers that appear to be OpenID s= pecific, their usage in this specification is actually referring to general O= Auth 2.0 features that are not specific to OpenID Connect.

 

The specification= is available at:

 

An HTML-formatted= version is also available at:

 

   = ;             &n= bsp;            =             &nbs= p;            &n= bsp;         -- Mike<= /span>

 

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


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

____________________= ___________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mai= lman/listinfo/oauth
= --Apple-Mail-AC0AF273-E1D9-41CE-833F-BCA34A2DFBFD-- From nobody Fri Nov 27 23:33:31 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 668091B30C8 for ; Fri, 27 Nov 2015 23:33:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.184 X-Spam-Level: X-Spam-Status: No, score=-0.184 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RVPtRsW1pb5F for ; Fri, 27 Nov 2015 23:33:25 -0800 (PST) Received: from nm22-vm1.bullet.mail.bf1.yahoo.com (nm22-vm1.bullet.mail.bf1.yahoo.com [98.139.212.127]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 195891B30C9 for ; Fri, 27 Nov 2015 23:33:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1448696004; bh=zRsQYSHfZ5f+Tr+pkTNimCpIenH3glnhhcT9ysBCMkw=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=JXlpLfefton/diJhkdtObftms5FLYHBoBdi3vgbaZYlOx9FHwFS+Q1Wmutnx8ckfs61sigjvANcQ5GUFkiMACR1di36XeWo+11JQW+2mj2ahBlultgCrt5mKXfwO9rYX5iD154H16n3BmGyhlXigWsPvsQtHZZFdCRJhPJD1KXpSP4ovbVc8TEMwVepo7GMGHMFvXYZzccTnArE0EOZ479JusNx9nfWFdkV1T8ysSnrzEkcur1hbK0iySGlCFGTqo7cZ/ckQ17zEQt003veCaOyNYOHn4fM7jrVTi8UGHbpgFuPs3gILyvO2MHDelXO5aVKLwUIodjpvzbdVxngjGw== Received: from [98.139.170.182] by nm22.bullet.mail.bf1.yahoo.com with NNFMP; 28 Nov 2015 07:33:24 -0000 Received: from [98.139.212.222] by tm25.bullet.mail.bf1.yahoo.com with NNFMP; 28 Nov 2015 07:33:24 -0000 Received: from [127.0.0.1] by omp1031.mail.bf1.yahoo.com with NNFMP; 28 Nov 2015 07:33:24 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 84391.68707.bm@omp1031.mail.bf1.yahoo.com X-YMail-OSG: .FPDivwVM1k0nbuHcgjA0nZXRXZb8ZmRZksO3ASjrz_aVDEns5tiuVigXl.QTwD TPHRGte.sS5xw1aTws4dnp39CNGCLRpR1mF9uV4OUKHYQq.wD0Vu_93OCOIfG0FLiLmGxe9r3P2T tik34CZMRtB3t7Z5eEfwt3ye4uDWTunZXjFWhMLMEQpdpVJcbwPzvVxKHpIfu7wJHgoIGeFLNaFC JFQhwMVkSuf.HnGt5my1CnJZOMHDoH3Bp_CMpCYDZ38heX7.y4UW0YH4yDXUt6w1ksBdP5KbGKu9 juVYkXWDYaTXhXS0G9aLpoW7ZKUxRnWAwzHsyl7TRuxS1NLWtovkw8qRdFWnAuTH8ytbDF2lvdQH y2jnLymy2cZlBaT7VLhS1gyGUintcMOQRDix8MCyOuECkB0P7.hI8nMr3tx1wN0xeczaJVgV7WDd ojQHr9cldkXxDM6jfItgclFgcj_4t6sy2vlsp5hGTlCIU6N5OeeeLB1BVcn9U4bwf5ovfcKW1zBx 0JSTzhZNGrRHRl354piUssqxiCoi3 Received: by 76.13.27.49; Sat, 28 Nov 2015 07:33:23 +0000 Date: Sat, 28 Nov 2015 07:33:22 +0000 (UTC) From: Bill Mills To: John Bradley , Kathleen Moriarty Message-ID: <118591309.12414777.1448696003022.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_12414776_499481236.1448696002977" Archived-At: Cc: "" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-pop-architecture-06.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2015 07:33:30 -0000 ------=_Part_12414776_499481236.1448696002977 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > It is fair to say that the threats and mitigations from bearer tokens als= o apply to PoP tokens.> PoP tokens add additional key information that must= also be protected along with the other=C2=A0> information in a access toke= n. THis doesn't really work because for example transport security to protect= the token itself is part of the Bearer security considerations and PoP tok= ens are making that much less of a problem. =C2=A0I don't know if there's m= ore but that doesn't work. =C2=A0Referencing specific things from Bearer an= d not the whole secuiryt considerations section could work. On Wednesday, November 25, 2015 12:55 PM, John Bradley wrote: =20 I have been assuming that security considerations from RFC 6750 would be a= pplied to =E2=80=9CPoP=E2=80=9D tokens as well when the tokens presentment/= confirmation specs are done. Sec 5.2 of RFC 6750 covers mitigations for modification and manufacture for= by value and by reference tokens. Do we want to keep repeating this information in all documents or reference= it? It is fair to say that the threats and mitigations from bearer tokens also = apply to PoP tokens.PoP tokens add additional key information that must als= o be protected along with the other information in a access token. John B. On Nov 25, 2015, at 5:39 PM, Kathleen Moriarty wrote: Hi, Sent from my iPhone On Nov 25, 2015, at 3:20 PM, John Bradley wrote: Tokens are signed or the information is otherwise integrity protected betwe= en the AS and the RS. =C2=A0 I suspect Kathleen is concerned about the key getting modified in transit. = =C2=A0=C2=A0That needs to be protected against, but there is more than one = way to do that. Phil is correct. =C2=A0I was looking for consistency between the sections s= ince they related to each other. =C2=A0If there is a security risk or consi= deration, that needs to be explicitly called out as a concern such as a key= being modified in transit. =C2=A0If there are options to protect against t= hat, those would ideally be required or would have warnings. So sending the public key in a unsigned JWT access token would be immensely= stupid, =C2=A0not just for PoP but for scopes and everything else. Good, easy to require then. Thanks,Kathleen=C2=A0 In OAuth 2 all tokens need to be integrity protected between the AS and RS.= =C2=A0That can be via signature, =C2=A0by having a reference with sufficie= nt entropy and secure introspection or database lookup. I think that is a OAuth 2 security consideration. =C2=A0 We are adding a ad= ditional confirmation claim to the existing information that needs to be pr= otected the same as the rest. John B. On Nov 25, 2015, at 4:38 PM, Phil Hunt wrote: If there is agreement that tokens are opaque then the requirem= ent that tokens be signed must be removed from the threat mitigation requir= ements.=C2=A0 And the paragraph in sec 5 that brian was concerned about be restored.=C2= =A0 Phil On Nov 25, 2015, at 11:24, Justin Richer wrote: It is still end to end authentication with opaque tokens =E2=80=94 since al= l OAuth tokens, including PoP tokens, have always been intended to be opaqu= e to the client. That hasn=E2=80=99t changed and that isn=E2=80=99t the int= ent of this document. If that=E2=80=99s how people are reading it then we n= eed to pull it back and rewrite it so that=E2=80=99s not the case. The client gets a token that has two parts: the token and the key. The toke= n is analogous to the access_token we have today and would come out of the = server in the same field. The key is handed to the client alongside the tok= en or registered by the client during the token request. Either way there= =E2=80=99s an association between the two but it=E2=80=99s not the same ass= ociation as a public/private keypair.=C2=A0 It=E2=80=99s possible to sign the token itself, but the client doesn=E2=80= =99t care. It sends the token and signs the HTTP request to the RS whether = the token is signed, unsigned, hex blob, encrypted, or anything else. The s= ame series of options are available as with bearer tokens. PoP tokens have = never, ever been intended to be anything but opaque to the client. The token can=E2=80=99t be opaque to the RS, which has to figure out what k= ey to use to check the message signature. But we=E2=80=99ve got options the= re, like the embedded key in a JWT from Mike=E2=80=99s draft, or doing intr= ospection to get the key (from an extension that hasn=E2=80=99t been writte= n yet), or simply looking it up in the same database because the RS and the= AS are in the same box. Does this structure/service/database choice sound = familiar? It should, it=E2=80=99s the same as bearer tokens. This is also h= ow the RS gets information like which scopes are associated with the token,= if it=E2=80=99s expired, and all that.=C2=A0 So here=E2=80=99s how I see it going on the wire: (I just wrote this up so there are probably holes. Here=E2=80=99s the sourc= e if anyone wants to tweak it:=C2=A0http://www.websequencediagrams.com/?lz= =3DcGFydGljaXBhbnQgQ2xpZW50IGFzIEMKAAwMUmVzb3VyY2UgT3duZXIgYXMgUk8AFA1BdXRo= b3JpemF0aW9uIFNlcnYAIQZBUwA7DVByb3RlY3RlZABICmFzIFJTCgoKClJPLS0-QzogR28gZ2V= 0IG15IHIAbwcKQy0tPlJPOiBSZWRpcmVjdCB0byBBUy9BRQAvBkFTOiBMb2cgaW4sIGEAgQIHZS= BjAIFHBQpBUwAqEwAVBwBrCEhhbmQAKQcAPAUgZ3JhbnQKCmFsdCBzAIFGBnN1cHBsaWVkIGtle= QpDAG4GVG9rZW4gcmVxdWVzdCAoADAFKQpBUwCBDAZnZW5lcmF0ZSB0ACIFYW4ANwUva2V5cGFp= cgAiBUMAPAgmIEsAEAtlbHMAgTcIAE8pICYga2V5AGYYLCBhc3NvY2lhdGUgd2l0aACBQQUAcBI= KZW5kCgpDLT5SUzogUgCBUQdpbmNsdWRpbmcAgT4Lc2lnbmVkAEEKAIIkBnRydWN0dXJlZACBbQ= YKUlMARAZjaGVjawCCAAdzaWduYXR1cmUgLyBkZWNyeXB0AB8PUGFycwCCLgcAOQlVbnBhY2sAg= ncFAIIYBWludHJvc3BlY3RpbwBiBkFTOiBzZW4AdAcgKG5vdABiCikgdG8AJQ9BAIEVBwAvBWtl= eSAocHVibGljIG9yIHNoYXJlZCkAgwIGZGF0YWJhc2UAgUUJbG9vayB1cABhCGxvY2FsLwAtBiB= EQikAHQthAIQoBgCCUAUAgX4OAIQsCACCBAp1c2luZwCEWAUAGw9pZ2h0cwCDNQoAgm4HAIJbBg= CCXQVDOiByZXR1cm4AhicJ&s=3Dmodern-blue ) The client is oblivious to the token just like always. This is intentional.= The RS has the same options to figure out how to process the token. =C2=A0=E2=80=94 Justin On Nov 25, 2015, at 2:03 PM, Phil Hunt wrote: Folks,=C2=A0 I did not want to go here either. :-) I don=E2=80=99t read sec 6 as examples. =C2=A0I believe this may stem from = the pop-architecture documents having a dual role as both =E2=80=9Carchitec= ture=E2=80=9D and =E2=80=9Cuse-case=E2=80=9D. =C2=A0Maybe we should clarify= the purpose of the document? I believe section 6 is talking about threat mitigation assumptions based on= the examples that need to be implemented. =C2=A0I am assuming these are re= quirements that the other specifications SHOULD implement. I do not believe we have discussed Opaque PoP tokens and any = inherent risks because the client is not or is unable to validate the authe= nticity of the token. =C2=A0Does this introduce the possibility of a MITM a= ttack where a client can be convinced to sign requests for an attacker? If we want to include opaque PoP, I think we need to take a pause and consi= der / discuss any threats here. I find the desire for opaque PoP tokens to be a bit contradictory. If we=E2= =80=99re saying we don=E2=80=99t want to trust TLS alone (e.g. because of l= oad-balancer termination), why would we then say, but we are perfectly will= ing to accept it worked for the OAuth AS exchanges? =C2=A0Maybe I was very = wrong here, but my assumption all along is that for PoP we=E2=80=99re talki= ng about end-to-end authentication of all parties except in the case of 3.3= where we simply want to protect an access token over a non-TLS HTTP connec= tion. Phil @independentidwww.independentid.comphil.hunt@oracle.com On Nov 25, 2015, at 10:48 AM, Brian Campbell w= rote: While I can't say I disagree with the deeper existential questions about th= e draft that Justin raises, I was trying not to go there and rather just po= int out concerns with the newly added text.=C2=A0 The text Phil cites from Sec 6 doesn't say the client must be able to parse= and verify the token. It's an assumption to simplify the examples that fol= low and still the token is opaque to the client. I reread the whole draft (= reluctantly) and there's nothing that says the token has to be non-opaque t= o the client. And it does talk about reference style tokens and encrypted t= okens, both of which rely on the opaqueness to the client.=C2=A0 On Wed, Nov 25, 2015 at 11:27 AM, Justin Richer=C2=A0=C2= =A0wrote: Right, I read that as text for describing the examples and not for describi= ng requirements. The token itself doesn=E2=80=99t have to be signed at all. =C2=A0=E2=80=94 Justin On Nov 25, 2015, at 1:05 PM, Phil Hunt wrote: Ok. Well this was requested by Kathleen because of this paragraph in Sec 6.= =E2=80=A6 To simplify the subsequent description we assume in the PoP architecture= that the token itself is digitally signed by the authorization server and therefore cannot be modified. Please=C2=A0Phil @independentidwww.independentid.comphil.hunt@oracle.com On Nov 25, 2015, at 9:33 AM, Justin Richer wrote: The token doesn=E2=80=99t have to be signed and the client doesn=E2=80=99t = have to verify the signature on the token. That=E2=80=99s not PoP. The requ= est has to be signed in a way that includes the token. The token itself can= still be opaque. The *key* material can=E2=80=99t be opaque to the client,= but the *token* material still is. I agree with Brian that this statement is misleading. The examples use a signed token but that is absolutely not a requirement. M= aybe the examples shouldn=E2=80=99t all use one style. What=E2=80=99s most difficult about this particular spec is that it=E2=80= =99s very hand-wavy, saying =E2=80=9Cthis is kinda a thing that kinda works= like this=E2=80=9D without saying how to actually do it. I=E2=80=99m hones= tly not sure it=E2=80=99s worth publishing as an RFC in its own right but I= =E2=80=99m not going to stand in its way. =C2=A0=E2=80=94 Justin On Nov 25, 2015, at 12:14 PM, Brian Campbell w= rote: Where does it say that?=C2=A0 On Wed, Nov 25, 2015 at 8:44 AM, Phil Hunt=C2=A0=C2= =A0wrote: Except that later on we require the token be signed and the client verify t= hat signed token. IOW mutual pop.=C2=A0 Phil On Nov 25, 2015, at 07:30, Brian Campbell wrot= e: Looking at the diff I noticed the following new text, which seems to confla= te bearer/PoP and opaqueness to the client. A client demonstrating proof-of= -possession of some key is orthogonal to the client being able to parse and= understand the access token itself.=C2=A0 =C2=A0 "In contrast to bearer tokens [RFC6750] which call for tokens that are opaq= ue to OAuth 2.0 clients, this specification defines the requirements for pr= oof-of-possession ("PoP") tokens that may be parsed and verified by OAuth 2= .0 clients and relying parties." On Tue, Nov 24, 2015 at 1:07 PM, Phil Hunt=C2=A0=C2= =A0wrote: This draft addresses review comments from Kathleen and Erik raised since th= e last draft. It may not include some of the discussion from yesterday/today.=C2=A0 I wil= l add that as the group decides. Cheers, Phil @independentid www.independentid.com phil.hunt@oracle.com > On Nov 24, 2015, at 12:05 PM,=C2=A0internet-drafts@ietf.org=C2=A0wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Web Authorization Protocol Working Group= of the IETF. > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= : OAuth 2.0 Proof-of-Possession (PoP) Security Architecture >=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Phi= l Hunt >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Justin Richer >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 William Mills >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Prateek Mishra >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Hannes Tschofenig >=C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-oauth-pop-architecture-06.txt >=C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 23 >=C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2015-11-24 > > Abstract: >=C2=A0 =C2=A0The OAuth 2.0 bearer token specification, as defined in RFC 6= 750, >=C2=A0 =C2=A0allows any party in possession of a bearer token (a "bearer")= to get >=C2=A0 =C2=A0access to the associated resources (without demonstrating pos= session >=C2=A0 =C2=A0of a cryptographic key).=C2=A0 To prevent misuse, bearer toke= ns must be >=C2=A0 =C2=A0protected from disclosure in transit and at rest. > >=C2=A0 =C2=A0Some scenarios demand additional security protection whereby = a client >=C2=A0 =C2=A0needs to demonstrate possession of cryptographic keying mater= ial when >=C2=A0 =C2=A0accessing a protected resource.=C2=A0 This document motivates= the >=C2=A0 =C2=A0development of the OAuth 2.0 proof-of-possession security mec= hanism. > > > The IETF datatracker status page for this draft is: >=C2=A0https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architecture/ > > There's also a htmlized version available at: >=C2=A0https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-06 > > A diff from the previous version is available at: >=C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-pop-architectur= e-06 > > > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at=C2=A0tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: >=C2=A0ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > OAuth mailing list >=C2=A0OAuth@ietf.org >=C2=A0https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --=C2=A0 | =C2=A0 | Brian Campbell Distinguished Engineer Ping Identity | @ | bcampbell@pingidentity.com | | | +1 720.317.2061 | | | @pingidentity | | Connect with us! | | =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | | --=C2=A0 | =C2=A0 | Brian Campbell Distinguished Engineer Ping Identity | @ | bcampbell@pingidentity.com | | | +1 720.317.2061 | | | @pingidentity | | Connect with us! | | =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | | _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --=C2=A0 | =C2=A0 | Brian Campbell Distinguished Engineer Ping Identity | @ | bcampbell@pingidentity.com | | | +1 720.317.2061 | | | @pingidentity | | Connect with us! | | =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | | _______________________________________________ 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 ------=_Part_12414776_499481236.1448696002977 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
> It is fair to say that the threats= and mitigations from bearer tokens also apply to PoP tokens.
> PoP tokens add additional key information that must also be protected= along with the other 
> information in a access toke= n.

THis doesn't really work be= cause for example transport security to protect the token itself is part of= the Bearer security considerations and PoP tokens are making that much les= s of a problem.  I don't know if there's more but that doesn't work. &= nbsp;Referencing specific things from Bearer and not the whole secuiryt con= siderations section could work.


= On Wednesday, November 25, 2015 12:55 PM, John Bradley <ve7jtb@ve7jtb.co= m> wrote:


= I have been assuming that security considerations from RFC 6750 would be ap= plied to =E2=80=9CPoP=E2=80=9D tokens as well when the tokens presentment/c= onfirmation specs are done.

Sec 5.2 o= f RFC 6750 covers mitigations for modification and manufacture for by value= and by reference tokens.

=
Do we= want to keep repeating this information in all documents or reference it?<= /div>
=
It is fair to say that the thre= ats and mitigations from bearer tokens also apply to PoP tokens.
PoP tokens= add additional key information that must also be protected along with the = other information in a access token.

John B.

=
On Nov 25, 2015, at 5:3= 9 PM, Kathleen Moriarty <kathleen.moriarty.i= etf@gmail.com> wrote:

Hi,

Sent from my iPhone

On Nov 25, 2015, at 3:20 PM, John Bradley= <ve7jtb@ve7jtb.com> wrote:

Tokens are signed or the i= nformation is otherwise integrity protected between the AS and the RS. &nbs= p;

<= /div>
I suspect Kathleen is concerned about the= key getting modified in transit.   
That needs to be protected against, but there is more than one way to= do that.

Phil is correct.  I was looking for consistency between the sectio= ns since they related to each other.  If there is a security risk or c= onsideration, that needs to be explicitly called out as a concern such as a= key being modified in transit.  If there are options to protect again= st that, those would ideally be required or would have warnings.
=

So sending the= public key in a unsigned JWT access token would be immensely stupid,  = ;not just for PoP but for scopes and everything else.

<= span class=3D"yiv8571302535" style=3D"font-family:Helvetica;font-size:12px;= font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:nor= mal;line-height:normal;text-indent:0px;text-transform:none;white-space:norm= al;word-spacing:0px;float:none;display:inline;">Good, easy to require then.=

Thanks,
Kathleen <= br clear=3D"none" class=3D"yiv8571302535">
=
In OAuth 2 all tokens need to be integrity protected between the AS and = RS.  
That can be via signature, &nb= sp;by having a reference with sufficient entropy and secure introspection o= r database lookup.

I think that is a O= Auth 2 security consideration.   We are adding a additional confirmati= on claim to the existing information that needs to be protected the same as= the rest.

John B.


On Nov 25, 2015, at 4:38 PM, Phil Hunt <phil.hun= t@oracle.com> wrote:

<editors hat>
If there is agreement that tokens are opaque then the re= quirement that tokens be signed must be removed from the threat mitigation = requirements. 

And the paragraph = in sec 5 that brian was concerned about be restored. 

Phil

On Nov 25, 2015, at 11:24, Justin Richer <<= a rel=3D"nofollow" shape=3D"rect" class=3D"yiv8571302535" ymailto=3D"mailto= :jricher@mit.edu" target=3D"_blank" href=3D"mailto:jricher@mit.edu">jricher= @mit.edu> wrote:

It is still end to end authenti= cation with opaque tokens =E2=80=94 since all OAuth tokens, including PoP t= okens, have always been intended to be opaque to the client. That hasn=E2= =80=99t changed and that isn=E2=80=99t the intent of this document. If that= =E2=80=99s how people are reading it then we need to pull it back and rewri= te it so that=E2=80=99s not the case.

The cl= ient gets a token that has two parts: the token and the key. The token is a= nalogous to the access_token we have today and would come out of the server= in the same field. The key is handed to the client alongside the token or = registered by the client during the token request. Either way there=E2=80= =99s an association between the two but it=E2=80=99s not the same associati= on as a public/private keypair. 
= It=E2=80=99s possible to sign the token itself, but the client doesn=E2=80= =99t care. It sends the token and signs the HTTP request to the RS whether = the token is signed, unsigned, hex blob, encrypted, or anything else. The s= ame series of options are available as with bearer tokens. PoP tokens have = never, ever been intended to be anything but opaque to the client.

=
The token can=E2=80=99t be opaque to the RS, w= hich has to figure out what key to use to check the message signature. But = we=E2=80=99ve got options there, like the embedded key in a JWT from Mike= =E2=80=99s draft, or doing introspection to get the key (from an extension = that hasn=E2=80=99t been written yet), or simply looking it up in the same = database because the RS and the AS are in the same box. Does this structure= /service/database choice sound familiar? It should, it=E2=80=99s the same a= s bearer tokens. This is also how the RS gets information like which scopes= are associated with the token, if it=E2=80=99s expired, and all that. = ;




So here=E2=80=99s how I see= it going on the wire:



3D"http://www.websequencediagrams.com/cg=



<= div class=3D"yiv8571302535">(I just wrote this up so there are probably hol= es. Here=E2=80=99s the source if anyone wants to tweak it: http://www.websequencediagrams.com/?lz=3DcGFydGl= jaXBhbnQgQ2xpZW50IGFzIEMKAAwMUmVzb3VyY2UgT3duZXIgYXMgUk8AFA1BdXRob3JpemF0aW= 9uIFNlcnYAIQZBUwA7DVByb3RlY3RlZABICmFzIFJTCgoKClJPLS0-QzogR28gZ2V0IG15I= HIAbwcKQy0tPlJPOiBSZWRpcmVjdCB0byBBUy9BRQAvBkFTOiBMb2cgaW4sIGEAgQIHZSBjAIFH= BQpBUwAqEwAVBwBrCEhhbmQAKQcAPAUgZ3JhbnQKCmFsdCBzAIFGBnN1cHBsaWVkIGtleQpDAG4= GVG9rZW4gcmVxdWVzdCAoADAFKQpBUwCBDAZnZW5lcmF0ZSB0ACIFYW4ANwUva2V5cGFpcgAiBU= MAPAgmIEsAEAtlbHMAgTcIAE8pICYga2V5AGYYLCBhc3NvY2lhdGUgd2l0aACBQQUAcBIKZW5kC= gpDLT5SUzogUgCBUQdpbmNsdWRpbmcAgT4Lc2lnbmVkAEEKAIIkBnRydWN0dXJlZACBbQYKUlMA= RAZjaGVjawCCAAdzaWduYXR1cmUgLyBkZWNyeXB0AB8PUGFycwCCLgcAOQlVbnBhY2sAgncFAII= YBWludHJvc3BlY3RpbwBiBkFTOiBzZW4AdAcgKG5vdABiCikgdG8AJQ9BAIEVBwAvBWtleSAocH= VibGljIG9yIHNoYXJlZCkAgwIGZGF0YWJhc2UAgUUJbG9vayB1cABhCGxvY2FsLwAtBiBEQikAH= QthAIQoBgCCUAUAgX4OAIQsCACCBAp1c2luZwCEWAUAGw9pZ2h0cwCDNQoAgm4HAIJbBgCCXQVD= OiByZXR1cm4AhicJ&s=3Dmodern-blue )
The client is oblivious to the token just like always. This is intentional= . The RS has the same options to figure out how to process the token.
=

 =E2=80=94 Justin

On Nov 25, 2015, at 2:03 PM, Phil Hunt <phil.hunt@ora= cle.com> wrote:

Folks, 

<editor hat>
I did not want to= go here either. :-)

I don=E2=80=99t r= ead sec 6 as examples.  I believe this may stem from the pop-architect= ure documents having a dual role as both =E2=80=9Carchitecture=E2=80=9D and= =E2=80=9Cuse-case=E2=80=9D.  Maybe we should clarify the purpose of t= he document?

I believe section 6 is ta= lking about threat mitigation assumptions based on the examples that need t= o be implemented.  I am assuming these are requirements that the other= specifications SHOULD implement.

<= personal hat>
I do not believe we have= discussed Opaque PoP tokens and any inherent risks because the client is n= ot or is unable to validate the authenticity of the token.  Does this = introduce the possibility of a MITM attack where a client can be convinced = to sign requests for an attacker?

If w= e want to include opaque PoP, I think we need to take a pause and consider = / discuss any threats here.

I find the= desire for opaque PoP tokens to be a bit contradictory. If we=E2=80=99re s= aying we don=E2=80=99t want to trust TLS alone (e.g. because of load-balanc= er termination), why would we then say, but we are perfectly willing to acc= ept it worked for the OAuth AS exchanges?  Maybe I was very wrong here= , but my assumption all along is that for PoP we=E2=80=99re talking about e= nd-to-end authentication of all parties except in the case of 3.3 where we = simply want to protect an access token over a non-TLS HTTP connection.


=
Phil

@independentid=
www.independentid.com
phil.hunt@oracle.com<= /a>

On Nov 25, 2015, = at 10:48 AM, Brian Campbell <bcampbell@pingidentity.com<= /a>> wrote:

While I = can't say I disagree with the deeper existential questions about the draft = that Justin raises, I was trying not to go there and rather just point out = concerns with the newly added text. 

The text Phil cites from Sec 6 doe= sn't say the client must be able to parse and verify the token. It's an ass= umption to simplify the examples that follow and still the token is opaque = to the client. I reread the whole draft (reluctantly) and there's nothing t= hat says the token has to be non-opaque to the client. And it does talk abo= ut reference style tokens and encrypted tokens, both of which rely on the o= paqueness to the client.=  

On Wed, Nov 25, 2015 at 11:27 AM, = Justin Richer <jricher@mit.edu><= span class=3D"yiv8571302535Apple-converted-space"> wrote:
Right, I read that = as text for describing the examples and not for describing requirements.
=
The token itself doesn=E2=80=99t have to be si= gned at all.

&n= bsp;=E2=80=94 Justin

On Nov 25, 2015, at 1:05 PM, Phil = Hunt <phil.hunt@oracle.com> wrote:

Ok. Well this was requested by Kathlee= n because of this paragraph in Sec 6.=E2=80=A6
= 

=
   To simplify the subsequent description we assume in the PoP architecture=

   that the token itself is digitally signed by the auth=
orization server

   and therefore cannot be modified.

Please 
Phil

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

On Nov 25, 2015, at 9:33 AM, Justin Richer <<= a rel=3D"nofollow" shape=3D"rect" class=3D"yiv8571302535" ymailto=3D"mailto= :jricher@mit.edu" target=3D"_blank" href=3D"mailto:jricher@mit.edu">jricher= @mit.edu> wrote:

The token doesn=E2=80=99t have to be signed and the client does= n=E2=80=99t have to verify the signature on the token. That=E2=80=99s not P= oP. The request has to be signed in a way that includes the token. The toke= n itself can still be opaque. The *key* material can=E2=80=99t be opaque to= the client, but the *token* material still is.

I agree with Brian that this statement is misleading.

The examples use a= signed token but that is absolutely not a requirement. Maybe the examples = shouldn=E2=80=99t all use one style.

W= hat=E2=80=99s most difficult about this particular spec is that it=E2=80=99= s very hand-wavy, saying =E2=80=9Cthis is kinda a thing that kinda works li= ke this=E2=80=9D without saying how to actually do it. I=E2=80=99m honestly= not sure it=E2=80=99s worth publishing as an RFC in its own right but I=E2= =80=99m not going to stand in its way.
 =E2=80=94 Justin

On Nov 25, 2015,= at 12:14 PM, Brian Campbell <bcampbell@pingidentity.c= om> wrote:

Where does it = say that? 


On Wed, Nov 25, 2015 at 8:44 AM, Phil Hunt <phil.hunt@oracle.com><= span class=3D"yiv8571302535Apple-converted-space"> wrote:
Except that later on w= e require the token be signed and the client verify that signed token. IOW = mutual pop. 

Phil

On Nov 25, 2015, at 07:30, Brian Campbel= l <bcampbell@pingidentity.com> wrote:

<= /div>
Looking at the diff I not= iced the following new text, which seems to conflate bearer/PoP and opaquen= ess to the client. A client demonstrating proof-of-possession of some key i= s orthogonal to the client being able to parse and understand the access to= ken itself. =
 
"In contrast to bearer tokens [RFC6750] which call for t= okens that are opaque to OAuth 2.0 clients, this specification defines the = requirements for proof-of-possession ("PoP") tokens that may be parsed and = verified by OAuth 2.0 clients and relying parties."

O= n Tue, Nov 24, 2015 at 1:07 PM, Phil Hunt <= ;phil.hunt@oracle.com> wrote:
This draft addresses review comments fr= om Kathleen and Erik raised since the last draft.

It may not in= clude some of the discussion from yesterday/today.  I will add that as= the group decides.

Cheers,

Phil

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

> On Nov 24, 2015, at 12:05 PM, internet-draf= ts@ietf.org wrote:
>
>
>= ; A New Internet-Draft is available from the on-line Internet-Drafts direct= ories.
> This draft is a work = item of the Web Authorization Protocol Working Group of the IETF.
>
>        Title        &nbs= p;  : OAuth 2.0 Proof-of-Possession (PoP) Security Architecture
>        Authors=          : Phil Hunt
>                &n= bsp;         Justin Richer
>                &= nbsp;         William Mills
>                =           Prateek Mishra
>              &nb= sp;           Hannes Tschofenig
>       Filename   = ;     : draft-ietf-oauth-pop-architecture-06.txt
>       Pages   =        : 23
= >       Date           = ; : 2015-11-24
>
> Abstract:
>   The OAuth 2.0 bearer token specification, as de= fined in RFC 6750,
>  &nb= sp;allows any party in possession of a bearer token (a "bearer") to get
>   access to the assoc= iated resources (without demonstrating possession
>   of a cryptographic key).  To preve= nt misuse, bearer tokens must be
= >   protected from disclosure in transit and at rest.
>
>   Some scenarios demand additional security protection= whereby a client
>  &nbs= p;needs to demonstrate possession of cryptographic keying material when
>   accessing a protect= ed resource.  This document motivates the
>   development of the OAuth 2.0 proof-of-posses= sion security mechanism.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf= -oauth-pop-architecture/
>=
> There's also a htmlized ver= sion available at:
> https://tools.ietf.o= rg/html/draft-ietf-oauth-pop-architecture-06
>
> A diff = from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-pop-archit= ecture-06
>
>
= > Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized ve= rsion 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@ie= tf.org
https://www.ietf.org/mailman/listinfo/oaut= h



-- 
3D"Ping =09= =09=09
Brian Campbell
Distinguished E= ngineer
Ping Identity=
@bcampbell@pingidentity.com
3D"phone"+1 720.317.2061
3D"twitt=@pingidentity=
Connect with us!
3D"pingidentity.com"
= 3D"pingidentity.com"
3D"twitter 3D"twitter 3D"youtube = ;3D"LinkedIn&n= bsp;3D"Facebook 3D"Google+ 3D"slideshare 3D"flipboard 3D"rss
<= /div>



-- 
<= tr class=3D"yiv8571302535">
3D= =09=09=09
Brian Campbell
= Distinguished Engineer
Ping Identity
<= td colspan=3D"1" rowspan=3D"1" class=3D"yiv8571302535" style=3D"text-align:= center;border-right-width:1px;border-right-style:solid;border-right-color:r= gb(230, 60, 29);vertical-align:middle;height:26px;padding:0px 2px 0px 0px;"= >3D"phone"
@b= campbell@pingidentity.com
+1 720.317.2061
3D"twitter"@pingidentity
Connect with us!
=
3D"pingidentity.com"
3D"pingidentity.com"
3D"twitter= 3D"twitter 3D"youtube 3D"LinkedIn=  3D"Facebook=  3D"Google+ 3D"slideshare&= nbsp;3D"flipboard 3D"rss
__________________= _____________________________
OAu= th mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth





-- 
3D"Ping&nbs= p;=09=09=09Brian Campbell
Dis= tinguished Engineer
Ping Identity=
@bcampbell@pingidentity.com
3D"phone=+1 720.317.2061
=3D"twitter"@pingide= ntity
Connect with = us!
3D"pingidentity.com"
<= a rel=3D"nofollow" shape=3D"rect" class=3D"yiv8571302535" target=3D"_blank"= href=3D"https://ping.force.com/Support/PingIdentityCommunityHome">3D"pingidentity.com"
3D"twitter <= img class=3D"yiv8571302535" src=3D"http://4.pingidentity.com/rs/pingidentit= y/images/twitter.gif" alt=3D"twitter logo" style=3D"width:20px;height:23px;= border:none;margin:0px;" data-id=3D"5b7b1554-3b43-cea8-cc7d-44900e227179"><= /a> = 3D"youtube=    3D"Google+  3D"flipboard 3D"rss


_____= __________________________________________
OAuth mailing list
OAuth@ietf.o= rg
https://www.ietf.org/mailman/listinfo/oauth

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


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


------=_Part_12414776_499481236.1448696002977-- From nobody Sat Nov 28 14:24:29 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D57301A89F5 for ; Sat, 28 Nov 2015 14:24:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.785 X-Spam-Level: X-Spam-Status: No, score=-4.785 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q3bddBS58B19 for ; Sat, 28 Nov 2015 14:24:21 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DC821B38B4 for ; Sat, 28 Nov 2015 14:24:21 -0800 (PST) Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id tASMOKFl026275 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 28 Nov 2015 22:24:20 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id tASMOJSo018989 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 28 Nov 2015 22:24:19 GMT Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id tASMOIcH031664; Sat, 28 Nov 2015 22:24:18 GMT Received: from [10.0.0.8] (/73.252.144.56) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 28 Nov 2015 14:24:18 -0800 Content-Type: multipart/alternative; boundary="Apple-Mail=_54EEF70B-4F82-490A-BDCE-6598BD9D9DAE" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Prateek Mishra In-Reply-To: <5F43839D-06E7-4E56-BAAC-0F0DE3A553D7@oracle.com> Date: Sat, 28 Nov 2015 14:24:17 -0800 Message-Id: References: <128376572.11963058.1448683100369.JavaMail.yahoo@mail.yahoo.com> <5F43839D-06E7-4E56-BAAC-0F0DE3A553D7@oracle.com> To: Phil Hunt X-Mailer: Apple Mail (2.2098) X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth Discovery X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2015 22:24:24 -0000 --Apple-Mail=_54EEF70B-4F82-490A-BDCE-6598BD9D9DAE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 +1 [quote] >=20 > I would like to understand these broader requirements, use cases, and = security considerations first.=20 >=20 >=20 >=20 > Phil >=20 [\quote] OAuth is being used in a *much* broader set of use-cases and contexts = than OpenID connect.=20 I think its very important to have a solution that addresses these = flows.=20 - prateek > On Nov 27, 2015, at 20:05, Mike Jones > wrote: >=20 >> It allows non-Connect implementation of OAuth 2.0 to also have a = standard discovery capability =E2=80=93 and one that can later be = updated to also support OpenID Connect with no breaking changes, should = that be desired in the future. >> =20 >> -- Mike >> =C2=A0 <> >> From: Bill Mills [mailto:wmills_92105@yahoo.com = ]=20 >> Sent: Friday, November 27, 2015 7:58 PM >> To: Mike Jones >; oauth@ietf.org = >> Subject: Re: [OAUTH-WG] OAuth Discovery >> =20 >> Can you elaborate on the advantage of having a separate parallel spec = to OpenID Discovery? >> =20 >> =20 >>=20 >> On Wednesday, November 25, 2015 3:37 PM, Mike Jones = > = wrote: >> =20 >>=20 >> I=E2=80=99m pleased to announce that Nat Sakimura, John Bradley, and = I have created an OAuth 2.0 Discovery specification. This fills a hole = in the current OAuth specification set that is necessary to achieve = interoperability. Indeed, the Interoperability section of OAuth 2.0=C2=A0= states: >> In addition, this specification leaves a few required components = partially or fully undefined (e.g., client registration, authorization = server capabilities, endpoint discovery). Without these components, = clients must be manually and specifically configured against a specific = authorization server and resource server in order to interoperate. >> =20 >> This framework was designed with the clear expectation that future = work will define prescriptive profiles and extensions necessary to = achieve full web-scale interoperability. >> =20 >> This specification enables discovery of both endpoint locations and = authorization server capabilities. >> =20 >> This specification is based upon the already widely deployed OpenID = Connect Discovery 1.0 = = specification and is compatible with it, by design. The OAuth Discovery = spec removes the portions of OpenID Connect Discovery that are OpenID = specific and adds metadata values for Revocation and Introspection = endpoints. It also maps OpenID concepts, such as OpenID Provider, = Relying Party, End-User, and Issuer to their OAuth underpinnings, = respectively Authorization Server, Client, Resource Owner, and the newly = introduced Configuration Information Location. Some identifiers with = names that appear to be OpenID specific were retained for compatibility = purposes; despite the reuse of these identifiers that appear to be = OpenID specific, their usage in this specification is actually referring = to general OAuth 2.0 features that are not specific to OpenID Connect. >> =20 >> The specification is available at: >> =C2=B7 = http://tools.ietf.org/html/draft-jones-oauth-discovery-00 = >> =20 >> An HTML-formatted version is also available at: >> =C2=B7 = http://self-issued.info/docs/draft-jones-oauth-discovery-00.html = >> =20 >> -- = Mike >> =20 >> P.S. This note was also posted at http://self-issued.info/?p=3D1496 = and as @selfissued = . >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = --Apple-Mail=_54EEF70B-4F82-490A-BDCE-6598BD9D9DAE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
+1
[quote]

I would like to understand = these broader requirements, use cases, and security considerations = first. 



Phil


[\quote]


OAuth is being used in a *much* broader set of = use-cases and contexts than OpenID connect. 

I think its very important to have a solution that = addresses these flows. 

- = prateek


On Nov 27, 2015, at 20:05, Mike Jones <Michael.Jones@microsoft.com> wrote:

It allows non-Connect = implementation of OAuth 2.0 to also have a standard discovery capability = =E2=80=93 and one that can later be updated to also support OpenID = Connect with no breaking changes, should that be desired in the = future.
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;          -- Mike
 
From: Bill Mills [mailto:wmills_92105@yahoo.com] 
Sent: Friday, November 27, 2015 = 7:58 PM
To: Mike Jones <Michael.Jones@microsoft.com>; oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth = Discovery
 
Can you elaborate on the = advantage of having a separate parallel spec to OpenID Discovery?
 

 

On Wednesday, November 25, = 2015 3:37 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

 

I=E2=80=99m pleased to announce that Nat Sakimura, John = Bradley, and I have created an OAuth 2.0 Discovery specification.  = This fills a hole in the current OAuth specification set that is = necessary to achieve interoperability.  Indeed, the Interoperability section of OAuth 2.0 states:
In addition, this specification =
leaves a few required components partially or fully undefined (e.g., =
client registration, authorization server capabilities, endpoint =
discovery).  Without these components, clients must be manually and =
specifically configured against a specific authorization server and =
resource server in order to interoperate.
  
This framework was designed with =
the clear expectation that future work will define prescriptive profiles =
and extensions necessary to achieve full web-scale =
interoperability.
 
This specification enables discovery of both = endpoint locations and authorization server capabilities.
 
This specification is based upon the already = widely deployed OpenID Connect Discovery 1.0 specification and is = compatible with it, by design.  The OAuth Discovery spec removes = the portions of OpenID Connect Discovery that are OpenID specific and = adds metadata values for Revocation and Introspection endpoints.  = It also maps OpenID concepts, such as OpenID Provider, Relying Party, = End-User, and Issuer to their OAuth underpinnings, respectively = Authorization Server, Client, Resource Owner, and the newly introduced = Configuration Information Location.  Some identifiers with names = that appear to be OpenID specific were retained for compatibility = purposes; despite the reuse of these identifiers that appear to be = OpenID specific, their usage in this specification is actually referring = to general OAuth 2.0 features that are not specific to OpenID = Connect.
 
The specification is available at:
=C2=B7         http://tools.ietf.org/html/draft-jones-oauth-discovery-00
 
An HTML-formatted version is also available = at:
=C2=B7         http://self-issued.info/docs/draft-jones-oauth-discovery-00.htm= l
 
          &nb= sp;     =             &n= bsp;           &nbs= p;            =            -- = Mike
 
P.S.  This note was also posted at http://self-issued.info/?p=3D1496 and 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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

= --Apple-Mail=_54EEF70B-4F82-490A-BDCE-6598BD9D9DAE-- From nobody Sat Nov 28 15:41:10 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01ADB1A6F7D for ; Sat, 28 Nov 2015 15:41:08 -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 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 IzHm2v0qh6Fl for ; Sat, 28 Nov 2015 15:41:01 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0109.outbound.protection.outlook.com [65.55.169.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61FE11A6F7B for ; Sat, 28 Nov 2015 15:41:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=bvYivseNHsZNbhNMjL5Zwn75JSDak6FK36DKG4A2Hg8=; b=X5lqYO6MPDbf/Rg/7zhc2INo2D0lKRm1fdqZAjCRhE8IwCwOl+hMYjLkUwFjkskC2UCJWYB5uN7rJx03xh5sYlk6KQwDMMHxceRXl5bXG3ZV0HX6HPx2wpy83t0ygePYpiyIAuhwLOuv+28tcuDHuC01DW11NTgiGj4Wq9+ncFs= Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) with Microsoft SMTP Server (TLS) id 15.1.331.20; Sat, 28 Nov 2015 23:40:57 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0331.023; Sat, 28 Nov 2015 23:40:57 +0000 From: Mike Jones To: Prateek Mishra , Phil Hunt Thread-Topic: [OAUTH-WG] OAuth Discovery Thread-Index: AdEnv6MqmLA/Ph7MT4qJwfYSFGITHwB0WHAAAAA37DAAAVwyAAAlC9mAAAIKO5A= Date: Sat, 28 Nov 2015 23:40:55 +0000 Message-ID: References: <128376572.11963058.1448683100369.JavaMail.yahoo@mail.yahoo.com> <5F43839D-06E7-4E56-BAAC-0F0DE3A553D7@oracle.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [50.47.85.157] x-microsoft-exchange-diagnostics: 1; BY2PR03MB442; 5:m89EGLDMFZiP0g6T0B0TPZQkG7dYFv4nLJSfVTF/dHlpJW259JbP+CLGDp4wJeN/GdC7PVs9Whp2v5grJHHDedK3ZjbZOjMjJWrw8RrwNorrZS5NGRth+QAvZzbtDO4gGIRLNg2VQrx4gNQuQ2F0Lw==; 24:oZ68V60sryNdtH2kxqhNVq/a2YDy2R6FjWTN0CFVi23eecat3C0G6Qx8uSIFNY3ipIRSVENjfL05/jqgHY6Y2TVM/tHfR9dbOVeDlJ/6yAY= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB442; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(201166117486090)(108003899814671)(146099531331640); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425024)(601004)(2401047)(8121501046)(5005006)(520078)(10201501046)(3002001)(61426024)(61427024); SRVR:BY2PR03MB442; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB442; x-forefront-prvs: 07749F8C42 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(209900001)(189002)(24454002)(199003)(377454003)(93886004)(5001770100001)(54356999)(2950100001)(66066001)(33656002)(74316001)(10090500001)(5008740100001)(790700001)(92566002)(19617315012)(97736004)(40100003)(11100500001)(15975445007)(15395725005)(86612001)(16236675004)(1220700001)(5004730100002)(87936001)(86362001)(77096005)(19580395003)(19580405001)(101416001)(19300405004)(122556002)(19609705001)(5002640100001)(5005710100001)(586003)(189998001)(50986999)(10400500002)(5001960100002)(81156007)(106356001)(105586002)(5003600100002)(2900100001)(99286002)(10290500002)(102836003)(3846002)(8990500004)(76176999)(1096002)(76576001)(19625215002)(6116002)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB442; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR03MB442F731A3C923118AAEC740F5020BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Nov 2015 23:40:55.8803 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB442 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth Discovery X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2015 23:41:09 -0000 --_000_BY2PR03MB442F731A3C923118AAEC740F5020BY2PR03MB442namprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Tm8gZGlzYWdyZWVtZW50LiAgSeKAmW0gc3VyZSB0aGF0IHRoZSB3b3JraW5nIGdyb3VwIHdpbGwg YWRkIGZlYXR1cmVzIHRvIGFkZHJlc3MgZnVuY3Rpb25hbGl0eSBuZWVkZWQgZm9yIHNvbWUgY29t bW9uIHVzZSBjYXNlcyB0aGF0IGFyZSBub3QgbmVlZGVkIGJ5IE9wZW5JRCBDb25uZWN0LiAgSW5k ZWVkLCB0aGUgdGhyZWUgYXV0aG9ycyBoYXZlIGFscmVhZHkgZG9uZSBzbyDigJMgYWRkaW5nIGVu ZHBvaW50cyBmb3IgdG9rZW4gcmV2b2NhdGlvbiBhbmQgdG9rZW4gaW50cm9zcGVjdGlvbi4gIE90 aGVyIGFkZGl0aW9ucyBhcmUgbGlrZWx5IHRvIG9jY3VyIGFzIHdlbGwgYWxvbmcgdGhlIHdheS4N Cg0KVGhhdCBiZWluZyBzYWlkLCBnaXZlbiB0aGF0IE9wZW5JRCBDb25uZWN0IERpc2NvdmVyeTxo dHRwOi8vb3BlbmlkLm5ldC9zcGVjcy9vcGVuaWQtY29ubmVjdC1kaXNjb3ZlcnktMV8wLmh0bWw+ IGVzdGFibGlzaGVkIGV4aXN0aW5nIHByYWN0aWNlIGZvciByZXByZXNlbnRpbmcgY29tbW9uIGRp c2NvdmVyeSBmdW5jdGlvbmFsaXR5IGxpa2UgdGhlIGF1dGhvcml6YXRpb24gZW5kcG9pbnQgVVJM LCB0aGUgdG9rZW4gZW5kcG9pbnQgVVJMLCBldGMuLCBpdCB3b3VsZCBzZWVtIGNvdW50ZXJwcm9k dWN0aXZlIG5vdCB0byBmb2xsb3cgdGhhdCBleGlzdGluZyBwcmFjdGljZSwgd2hlcmUgYXBwbGlj YWJsZS4gIEluZGVlZCwgdGhlIE9BdXRoIHdvcmtpbmcgZ3JvdXAgaGFzIGFscmVhZHkgaGFkIGEg c2ltaWxhciBzdWNjZXNzIHdpdGggYSBjb21wbGV0ZWQgUkZDLCBrZWVwaW5nIE9BdXRoIDIuMCBE eW5hbWljIENsaWVudCBSZWdpc3RyYXRpb248aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZj NzU5MT4gMTAwJSBjb21wYXRpYmxlIHdpdGggT3BlbklEIENvbm5lY3QgRHluYW1pYyBDbGllbnQg UmVnaXN0cmF0aW9uPGh0dHA6Ly9vcGVuaWQubmV0L3NwZWNzL29wZW5pZC1jb25uZWN0LXJlZ2lz dHJhdGlvbi0xXzAuaHRtbD4uDQoNCkdldHRpbmcgZG93biB0byBzcGVjaWZpY3MsIHdoYXQgZmVh dHVyZXMgYXJlIG5lZWRlZCBmb3IgY29tbW9uIHVzZSBjYXNlcyB0aGF0IGFyZW7igJl0IGFscmVh ZHkgaW4gdGhlIGN1cnJlbnQgZHJhZnQ/ICBGb3Igc3RhcnRlcnMsIFZsYWRpbWlyIER6aHV2aW5v diBoYXMgYWxyZWFkeSBjYWxsZWQgb3V0IGRlZmluaW5nIGF1dGhlbnRpY2F0aW9uIG1ldGhvZHMg dG8gdGhlIHJldm9jYXRpb24gYW5kIGludHJvc3BlY3Rpb24gZW5kcG9pbnRzLiAgV2hhdCBlbHNl IGFyZSBwZW9wbGUgY29tbW9ubHkgZG9pbmcgdGhhdCBpc27igJl0IGNvdmVyZWQgaW4gdGhlIGN1 cnJlbnQgZHJhZnQ/DQoNClJlbWVtYmVyIG9mIGNvdXJzZSwgdGhhdCBvbmUgb2YgdGhlIHByaW1h cnkgcHVycG9zZXMgb2YgdGhlIHNwZWNpZmljYXRpb24gaXMgdG8gZXN0YWJsaXNoIHRoZSBPQXV0 aCBEaXNjb3ZlcnkgTWV0YWRhdGEgUmVnaXN0cnkuICBUaGF0IHdheSB3ZSBkb27igJl0IGhhdmUg dG8gdGhpbmsgb2YgZXZlcnl0aGluZyB0aGF0IGFueW9uZSBtaWdodCBuZWVkIGluIGFkdmFuY2Uu ICBOZXcgdmFsdWVzIGNhbiBhbmQgd2lsbCBiZSBhZGRlZCBhcyB0aGV5IGFyZSBuZWVkZWQgYnkg bmV3IGFuZCBleGlzdGluZyBhcHBsaWNhdGlvbnMgaW4gYWRkaXRpb25hbCBzcGVjaWZpY2F0aW9u cyB1dGlsaXppbmcgdGhlIHJlZ2lzdHJ5Lg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQmVzdCB3aXNoZXMsDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpG cm9tOiBQcmF0ZWVrIE1pc2hyYSBbbWFpbHRvOlByYXRlZWsuTWlzaHJhQG9yYWNsZS5jb21dDQpT ZW50OiBTYXR1cmRheSwgTm92ZW1iZXIgMjgsIDIwMTUgMjoyNCBQTQ0KVG86IFBoaWwgSHVudCA8 cGhpbC5odW50QG9yYWNsZS5jb20+DQpDYzogTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNy b3NvZnQuY29tPjsgb2F1dGhAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIE9BdXRo IERpc2NvdmVyeQ0KDQorMQ0KW3F1b3RlXQ0KDQoNCkkgd291bGQgbGlrZSB0byB1bmRlcnN0YW5k IHRoZXNlIGJyb2FkZXIgcmVxdWlyZW1lbnRzLCB1c2UgY2FzZXMsIGFuZCBzZWN1cml0eSBjb25z aWRlcmF0aW9ucyBmaXJzdC4NCg0KDQoNClBoaWwNCg0KDQpbXHF1b3RlXQ0KDQoNCk9BdXRoIGlz IGJlaW5nIHVzZWQgaW4gYSAqbXVjaCogYnJvYWRlciBzZXQgb2YgdXNlLWNhc2VzIGFuZCBjb250 ZXh0cyB0aGFuIE9wZW5JRCBjb25uZWN0Lg0KDQpJIHRoaW5rIGl0cyB2ZXJ5IGltcG9ydGFudCB0 byBoYXZlIGEgc29sdXRpb24gdGhhdCBhZGRyZXNzZXMgdGhlc2UgZmxvd3MuDQoNCi0gcHJhdGVl aw0KDQoNCg0KT24gTm92IDI3LCAyMDE1LCBhdCAyMDowNSwgTWlrZSBKb25lcyA8TWljaGFlbC5K b25lc0BtaWNyb3NvZnQuY29tPG1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+PiB3 cm90ZToNCkl0IGFsbG93cyBub24tQ29ubmVjdCBpbXBsZW1lbnRhdGlvbiBvZiBPQXV0aCAyLjAg dG8gYWxzbyBoYXZlIGEgc3RhbmRhcmQgZGlzY292ZXJ5IGNhcGFiaWxpdHkg4oCTIGFuZCBvbmUg dGhhdCBjYW4gbGF0ZXIgYmUgdXBkYXRlZCB0byBhbHNvIHN1cHBvcnQgT3BlbklEIENvbm5lY3Qg d2l0aCBubyBicmVha2luZyBjaGFuZ2VzLCBzaG91bGQgdGhhdCBiZSBkZXNpcmVkIGluIHRoZSBm dXR1cmUuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAtLSBNaWtlDQoNCkZyb206IEJpbGwgTWlsbHMgW21haWx0bzp3bWlsbHNfOTIx MDVAeWFob28uY29tXQ0KU2VudDogRnJpZGF5LCBOb3ZlbWJlciAyNywgMjAxNSA3OjU4IFBNDQpU bzogTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPG1haWx0bzpNaWNoYWVs LkpvbmVzQG1pY3Jvc29mdC5jb20+Pjsgb2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYu b3JnPg0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gT0F1dGggRGlzY292ZXJ5DQoNCkNhbiB5b3Ug ZWxhYm9yYXRlIG9uIHRoZSBhZHZhbnRhZ2Ugb2YgaGF2aW5nIGEgc2VwYXJhdGUgcGFyYWxsZWwg c3BlYyB0byBPcGVuSUQgRGlzY292ZXJ5Pw0KDQoNCk9uIFdlZG5lc2RheSwgTm92ZW1iZXIgMjUs IDIwMTUgMzozNyBQTSwgTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPG1h aWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+PiB3cm90ZToNCg0KSeKAmW0gcGxlYXNl ZCB0byBhbm5vdW5jZSB0aGF0IE5hdCBTYWtpbXVyYSwgSm9obiBCcmFkbGV5LCBhbmQgSSBoYXZl IGNyZWF0ZWQgYW4gT0F1dGggMi4wIERpc2NvdmVyeSBzcGVjaWZpY2F0aW9uLiAgVGhpcyBmaWxs cyBhIGhvbGUgaW4gdGhlIGN1cnJlbnQgT0F1dGggc3BlY2lmaWNhdGlvbiBzZXQgdGhhdCBpcyBu ZWNlc3NhcnkgdG8gYWNoaWV2ZSBpbnRlcm9wZXJhYmlsaXR5LiAgSW5kZWVkLCB0aGUgSW50ZXJv cGVyYWJpbGl0eSBzZWN0aW9uIG9mIE9BdXRoIDIuMCA8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL3JmYzY3NDkjc2VjdGlvbi0xLjg+IHN0YXRlczoNCg0KSW4gYWRkaXRpb24sIHRoaXMgc3Bl Y2lmaWNhdGlvbiBsZWF2ZXMgYSBmZXcgcmVxdWlyZWQgY29tcG9uZW50cyBwYXJ0aWFsbHkgb3Ig ZnVsbHkgdW5kZWZpbmVkIChlLmcuLCBjbGllbnQgcmVnaXN0cmF0aW9uLCBhdXRob3JpemF0aW9u IHNlcnZlciBjYXBhYmlsaXRpZXMsIGVuZHBvaW50IGRpc2NvdmVyeSkuICBXaXRob3V0IHRoZXNl IGNvbXBvbmVudHMsIGNsaWVudHMgbXVzdCBiZSBtYW51YWxseSBhbmQgc3BlY2lmaWNhbGx5IGNv bmZpZ3VyZWQgYWdhaW5zdCBhIHNwZWNpZmljIGF1dGhvcml6YXRpb24gc2VydmVyIGFuZCByZXNv dXJjZSBzZXJ2ZXIgaW4gb3JkZXIgdG8gaW50ZXJvcGVyYXRlLg0KDQoNCg0KVGhpcyBmcmFtZXdv cmsgd2FzIGRlc2lnbmVkIHdpdGggdGhlIGNsZWFyIGV4cGVjdGF0aW9uIHRoYXQgZnV0dXJlIHdv cmsgd2lsbCBkZWZpbmUgcHJlc2NyaXB0aXZlIHByb2ZpbGVzIGFuZCBleHRlbnNpb25zIG5lY2Vz c2FyeSB0byBhY2hpZXZlIGZ1bGwgd2ViLXNjYWxlIGludGVyb3BlcmFiaWxpdHkuDQoNClRoaXMg c3BlY2lmaWNhdGlvbiBlbmFibGVzIGRpc2NvdmVyeSBvZiBib3RoIGVuZHBvaW50IGxvY2F0aW9u cyBhbmQgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgY2FwYWJpbGl0aWVzLg0KDQpUaGlzIHNwZWNpZmlj YXRpb24gaXMgYmFzZWQgdXBvbiB0aGUgYWxyZWFkeSB3aWRlbHkgZGVwbG95ZWQgT3BlbklEIENv bm5lY3QgRGlzY292ZXJ5IDEuMDxodHRwOi8vb3BlbmlkLm5ldC9zcGVjcy9vcGVuaWQtY29ubmVj dC1kaXNjb3ZlcnktMV8wLmh0bWw+IHNwZWNpZmljYXRpb24gYW5kIGlzIGNvbXBhdGlibGUgd2l0 aCBpdCwgYnkgZGVzaWduLiAgVGhlIE9BdXRoIERpc2NvdmVyeSBzcGVjIHJlbW92ZXMgdGhlIHBv cnRpb25zIG9mIE9wZW5JRCBDb25uZWN0IERpc2NvdmVyeSB0aGF0IGFyZSBPcGVuSUQgc3BlY2lm aWMgYW5kIGFkZHMgbWV0YWRhdGEgdmFsdWVzIGZvciBSZXZvY2F0aW9uIGFuZCBJbnRyb3NwZWN0 aW9uIGVuZHBvaW50cy4gIEl0IGFsc28gbWFwcyBPcGVuSUQgY29uY2VwdHMsIHN1Y2ggYXMgT3Bl bklEIFByb3ZpZGVyLCBSZWx5aW5nIFBhcnR5LCBFbmQtVXNlciwgYW5kIElzc3VlciB0byB0aGVp ciBPQXV0aCB1bmRlcnBpbm5pbmdzLCByZXNwZWN0aXZlbHkgQXV0aG9yaXphdGlvbiBTZXJ2ZXIs IENsaWVudCwgUmVzb3VyY2UgT3duZXIsIGFuZCB0aGUgbmV3bHkgaW50cm9kdWNlZCBDb25maWd1 cmF0aW9uIEluZm9ybWF0aW9uIExvY2F0aW9uLiAgU29tZSBpZGVudGlmaWVycyB3aXRoIG5hbWVz IHRoYXQgYXBwZWFyIHRvIGJlIE9wZW5JRCBzcGVjaWZpYyB3ZXJlIHJldGFpbmVkIGZvciBjb21w YXRpYmlsaXR5IHB1cnBvc2VzOyBkZXNwaXRlIHRoZSByZXVzZSBvZiB0aGVzZSBpZGVudGlmaWVy cyB0aGF0IGFwcGVhciB0byBiZSBPcGVuSUQgc3BlY2lmaWMsIHRoZWlyIHVzYWdlIGluIHRoaXMg c3BlY2lmaWNhdGlvbiBpcyBhY3R1YWxseSByZWZlcnJpbmcgdG8gZ2VuZXJhbCBPQXV0aCAyLjAg ZmVhdHVyZXMgdGhhdCBhcmUgbm90IHNwZWNpZmljIHRvIE9wZW5JRCBDb25uZWN0Lg0KDQpUaGUg c3BlY2lmaWNhdGlvbiBpcyBhdmFpbGFibGUgYXQ6DQrigKIgICAgICAgICBodHRwOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1qb25lcy1vYXV0aC1kaXNjb3ZlcnktMDANCg0KQW4gSFRNTC1m b3JtYXR0ZWQgdmVyc2lvbiBpcyBhbHNvIGF2YWlsYWJsZSBhdDoNCuKAoiAgICAgICAgIGh0dHA6 Ly9zZWxmLWlzc3VlZC5pbmZvL2RvY3MvZHJhZnQtam9uZXMtb2F1dGgtZGlzY292ZXJ5LTAwLmh0 bWwNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIC0tIE1pa2UNCg0KUC5TLiAgVGhpcyBub3RlIHdhcyBhbHNvIHBvc3RlZCBh dCBodHRwOi8vc2VsZi1pc3N1ZWQuaW5mby8/cD0xNDk2IGFuZCBhcyBAc2VsZmlzc3VlZDxodHRw czovL3R3aXR0ZXIuY29tL3NlbGZpc3N1ZWQ+Lg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9y ZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL29hdXRoDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRo QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1h aWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQo= --_000_BY2PR03MB442F731A3C923118AAEC740F5020BY2PR03MB442namprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsN CglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAq Lw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGlu Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6 IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTou MDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9 DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHls ZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmln aHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsN Cglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlm O30NCnNwYW4uYXBwbGUtY29udmVydGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLWNv bnZlcnRlZC1zcGFjZTt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1u YW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ bXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xh czt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMDAyMDYwO30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZTox MC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdp bjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZd LS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+ DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3ht bD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2 bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+Tm8gZGlzYWdyZWVtZW50LiZu YnNwOyBJ4oCZbSBzdXJlIHRoYXQgdGhlIHdvcmtpbmcgZ3JvdXAgd2lsbCBhZGQgZmVhdHVyZXMg dG8gYWRkcmVzcyBmdW5jdGlvbmFsaXR5IG5lZWRlZCBmb3Igc29tZSBjb21tb24gdXNlIGNhc2Vz IHRoYXQgYXJlIG5vdCBuZWVkZWQgYnkgT3BlbklEIENvbm5lY3QuJm5ic3A7DQogSW5kZWVkLCB0 aGUgdGhyZWUgYXV0aG9ycyBoYXZlIGFscmVhZHkgZG9uZSBzbyDigJMgYWRkaW5nIGVuZHBvaW50 cyBmb3IgdG9rZW4gcmV2b2NhdGlvbiBhbmQgdG9rZW4gaW50cm9zcGVjdGlvbi4mbmJzcDsgT3Ro ZXIgYWRkaXRpb25zIGFyZSBsaWtlbHkgdG8gb2NjdXIgYXMgd2VsbCBhbG9uZyB0aGUgd2F5Ljxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+VGhhdCBiZWluZyBzYWlk LCBnaXZlbiB0aGF0DQo8YSBocmVmPSJodHRwOi8vb3BlbmlkLm5ldC9zcGVjcy9vcGVuaWQtY29u bmVjdC1kaXNjb3ZlcnktMV8wLmh0bWwiPk9wZW5JRCBDb25uZWN0IERpc2NvdmVyeTwvYT4gZXN0 YWJsaXNoZWQgZXhpc3RpbmcgcHJhY3RpY2UgZm9yIHJlcHJlc2VudGluZyBjb21tb24gZGlzY292 ZXJ5IGZ1bmN0aW9uYWxpdHkgbGlrZSB0aGUgYXV0aG9yaXphdGlvbiBlbmRwb2ludCBVUkwsIHRo ZSB0b2tlbiBlbmRwb2ludCBVUkwsIGV0Yy4sIGl0IHdvdWxkIHNlZW0gY291bnRlcnByb2R1Y3Rp dmUNCiBub3QgdG8gZm9sbG93IHRoYXQgZXhpc3RpbmcgcHJhY3RpY2UsIHdoZXJlIGFwcGxpY2Fi bGUuJm5ic3A7IEluZGVlZCwgdGhlIE9BdXRoIHdvcmtpbmcgZ3JvdXAgaGFzIGFscmVhZHkgaGFk IGEgc2ltaWxhciBzdWNjZXNzIHdpdGggYSBjb21wbGV0ZWQgUkZDLCBrZWVwaW5nDQo8YSBocmVm PSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3NTkxIj5PQXV0aCAyLjAgRHluYW1pYyBD bGllbnQgUmVnaXN0cmF0aW9uPC9hPiAxMDAlIGNvbXBhdGlibGUgd2l0aA0KPGEgaHJlZj0iaHR0 cDovL29wZW5pZC5uZXQvc3BlY3Mvb3BlbmlkLWNvbm5lY3QtcmVnaXN0cmF0aW9uLTFfMC5odG1s Ij5PcGVuSUQgQ29ubmVjdCBEeW5hbWljIENsaWVudCBSZWdpc3RyYXRpb248L2E+LjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+R2V0dGluZyBkb3duIHRvIHNwZWNp Zmljcywgd2hhdCBmZWF0dXJlcyBhcmUgbmVlZGVkIGZvciBjb21tb24gdXNlIGNhc2VzIHRoYXQg YXJlbuKAmXQgYWxyZWFkeSBpbiB0aGUgY3VycmVudCBkcmFmdD8mbmJzcDsNCjxhIG5hbWU9Il9N YWlsRW5kQ29tcG9zZSI+Rm9yIHN0YXJ0ZXJzLCBWbGFkaW1pciBEemh1dmlub3YgaGFzIGFscmVh ZHkgY2FsbGVkIG91dCBkZWZpbmluZyBhdXRoZW50aWNhdGlvbiBtZXRob2RzIHRvIHRoZSByZXZv Y2F0aW9uIGFuZCBpbnRyb3NwZWN0aW9uIGVuZHBvaW50cy4mbmJzcDsgV2hhdCBlbHNlIGFyZSBw ZW9wbGUgY29tbW9ubHkgZG9pbmcgdGhhdCBpc27igJl0IGNvdmVyZWQgaW4gdGhlIGN1cnJlbnQg ZHJhZnQ/PG86cD48L286cD48L2E+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxFbmRDb21wb3Nl Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+UmVtZW1iZXIgb2YgY291cnNlLCB0aGF0 IG9uZSBvZiB0aGUgcHJpbWFyeSBwdXJwb3NlcyBvZiB0aGUgc3BlY2lmaWNhdGlvbiBpcyB0byBl c3RhYmxpc2ggdGhlIE9BdXRoIERpc2NvdmVyeSBNZXRhZGF0YQ0KIFJlZ2lzdHJ5LiZuYnNwOyBU aGF0IHdheSB3ZSBkb27igJl0IGhhdmUgdG8gdGhpbmsgb2YgZXZlcnl0aGluZyB0aGF0IGFueW9u ZSBtaWdodCBuZWVkIGluIGFkdmFuY2UuJm5ic3A7IE5ldyB2YWx1ZXMgY2FuIGFuZCB3aWxsIGJl IGFkZGVkIGFzIHRoZXkgYXJlIG5lZWRlZCBieSBuZXcgYW5kIGV4aXN0aW5nIGFwcGxpY2F0aW9u cyBpbiBhZGRpdGlvbmFsIHNwZWNpZmljYXRpb25zIHV0aWxpemluZyB0aGUgcmVnaXN0cnkuPG86 cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJtc28tYm9va21hcms6X01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxFbmRDb21wb3NlIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEJlc3Qgd2lzaGVzLDxvOnA+PC9vOnA+PC9zcGFu Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2tt YXJrOl9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBN aWtlPG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjxzcGFu IHN0eWxlPSJtc28tYm9va21hcms6X01haWxFbmRDb21wb3NlIj48L3NwYW4+DQo8ZGl2Pg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRp bmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gUHJhdGVlayBNaXNocmEg W21haWx0bzpQcmF0ZWVrLk1pc2hyYUBvcmFjbGUuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFNh dHVyZGF5LCBOb3ZlbWJlciAyOCwgMjAxNSAyOjI0IFBNPGJyPg0KPGI+VG86PC9iPiBQaGlsIEh1 bnQgJmx0O3BoaWwuaHVudEBvcmFjbGUuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gTWlrZSBKb25l cyAmbHQ7TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tJmd0Ozsgb2F1dGhAaWV0Zi5vcmc8YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10gT0F1dGggRGlzY292ZXJ5PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiYjNDM7MTxicj4N CltxdW90ZV08YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkkg d291bGQgbGlrZSB0byB1bmRlcnN0YW5kIHRoZXNlIGJyb2FkZXIgcmVxdWlyZW1lbnRzLCB1c2Ug Y2FzZXMsIGFuZCBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBmaXJzdC4mbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz YW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48YnI+DQo8YnI+DQpQaGlsPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPltccXVvdGVdPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T0F1dGggaXMgYmVp bmcgdXNlZCBpbiBhICptdWNoKiBicm9hZGVyIHNldCBvZiB1c2UtY2FzZXMgYW5kIGNvbnRleHRz IHRoYW4gT3BlbklEIGNvbm5lY3QuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgdGhpbmsgaXRzIHZlcnkgaW1wb3J0YW50IHRvIGhh dmUgYSBzb2x1dGlvbiB0aGF0IGFkZHJlc3NlcyB0aGVzZSBmbG93cy4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LSBwcmF0ZWVrPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4N Cjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5PbiBOb3YgMjcsIDIw MTUsIGF0IDIwOjA1LCBNaWtlIEpvbmVzICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5Kb25l c0BtaWNyb3NvZnQuY29tIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5NaWNoYWVsLkpvbmVz QG1pY3Jvc29mdC5jb208L3NwYW4+PC9hPiZndDsNCiB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQ7b3JwaGFuczogYXV0bzt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93czogYXV0bzst d2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYw Ij5JdCBhbGxvd3Mgbm9uLUNvbm5lY3QgaW1wbGVtZW50YXRpb24gb2YgT0F1dGggMi4wIHRvIGFs c28gaGF2ZSBhIHN0YW5kYXJkIGRpc2NvdmVyeSBjYXBhYmlsaXR5IOKAkyBhbmQgb25lIHRoYXQg Y2FuIGxhdGVyIGJlIHVwZGF0ZWQgdG8gYWxzbyBzdXBwb3J0IE9wZW5JRCBDb25uZWN0DQogd2l0 aCBubyBicmVha2luZyBjaGFuZ2VzLCBzaG91bGQgdGhhdCBiZSBkZXNpcmVkIGluIHRoZSBmdXR1 cmUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAy MDYwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzoz LjBwdCAwaW4gMGluIDBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+QmlsbA0KIE1pbGxzIFs8YSBocmVmPSJtYWlsdG86d21pbGxzXzkyMTA1QHlhaG9vLmNvbSI+ PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+bWFpbHRvOndtaWxsc185MjEwNUB5YWhvby5jb208 L3NwYW4+PC9hPl08c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw YW4+PGJyPg0KPGI+U2VudDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPkZyaWRheSwgTm92ZW1iZXIgMjcsIDIwMTUgNzo1OCBQTTxicj4NCjxiPlRv OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+TWlr ZSBKb25lcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSI+ PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPC9z cGFuPjwvYT4mZ3Q7OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwv c3Bhbj48YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjpw dXJwbGUiPm9hdXRoQGlldGYub3JnPC9zcGFuPjwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj48c3Bh biBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+UmU6IFtPQVVUSC1X R10gT0F1dGggRGlzY292ZXJ5PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Q2FuIHlvdSBlbGFib3JhdGUg b24gdGhlIGFkdmFudGFnZSBvZiBoYXZpbmcgYSBzZXBhcmF0ZSBwYXJhbGxlbCBzcGVjIHRvIE9w ZW5JRCBEaXNjb3Zlcnk/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss c2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0O2JhY2tncm91 bmQ6d2hpdGU7YmFja2dyb3VuZC1wb3NpdGlvbjppbml0aWFsIGluaXRpYWw7YmFja2dyb3VuZC1y ZXBlYXQ6aW5pdGlhbCBpbml0aWFsIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1z ZXJpZiI+T24gV2VkbmVzZGF5LCBOb3ZlbWJlciAyNSwgMjAxNSAzOjM3IFBNLCBNaWtlIEpvbmVz ICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tIj48c3BhbiBz dHlsZT0iY29sb3I6cHVycGxlIj5NaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208L3NwYW4+PC9h PiZndDsNCiB3cm90ZTo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0O2JhY2tncm91bmQ6 d2hpdGU7YmFja2dyb3VuZC1wb3NpdGlvbjppbml0aWFsIGluaXRpYWw7YmFja2dyb3VuZC1yZXBl YXQ6aW5pdGlhbCBpbml0aWFsIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxkaXYgaWQ9InlpdjIxMDE4NjAzMDQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPknigJltIHBs ZWFzZWQgdG8gYW5ub3VuY2UgdGhhdCBOYXQgU2FraW11cmEsIEpvaG4gQnJhZGxleSwgYW5kIEkg aGF2ZSBjcmVhdGVkIGFuIE9BdXRoIDIuMCBEaXNjb3Zlcnkgc3BlY2lmaWNhdGlvbi4mbmJzcDsg VGhpcyBmaWxscyBhIGhvbGUgaW4gdGhlIGN1cnJlbnQgT0F1dGggc3BlY2lmaWNhdGlvbg0KIHNl dCB0aGF0IGlzIG5lY2Vzc2FyeSB0byBhY2hpZXZlIGludGVyb3BlcmFiaWxpdHkuJm5ic3A7IElu ZGVlZCwgdGhlPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu PjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2NzQ5I3NlY3Rpb24tMS44 IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+SW50ZXJvcGVyYWJp bGl0eSBzZWN0aW9uIG9mIE9BdXRoIDIuMDxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PC9hPnN0YXRlczo8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbjtiYWNrZ3JvdW5k OndoaXRlO2JhY2tncm91bmQtcG9zaXRpb246aW5pdGlhbCBpbml0aWFsO2JhY2tncm91bmQtcmVw ZWF0OmluaXRpYWwgaW5pdGlhbCI+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LXNpemU6MTEu MHB0Ij5JbiBhZGRpdGlvbiwgdGhpcyBzcGVjaWZpY2F0aW9uIGxlYXZlcyBhIGZldyByZXF1aXJl ZCBjb21wb25lbnRzIHBhcnRpYWxseSBvciBmdWxseSB1bmRlZmluZWQgKGUuZy4sIGNsaWVudCBy ZWdpc3RyYXRpb24sIGF1dGhvcml6YXRpb24gc2VydmVyIGNhcGFiaWxpdGllcywgZW5kcG9pbnQg ZGlzY292ZXJ5KS4mbmJzcDsgV2l0aG91dCB0aGVzZSBjb21wb25lbnRzLCBjbGllbnRzIG11c3Qg YmUgbWFudWFsbHkgYW5kIHNwZWNpZmljYWxseSBjb25maWd1cmVkIGFnYWluc3QgYSBzcGVjaWZp YyBhdXRob3JpemF0aW9uIHNlcnZlciBhbmQgcmVzb3VyY2Ugc2VydmVyIGluIG9yZGVyIHRvIGlu dGVyb3BlcmF0ZS48L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW47YmFja2dyb3VuZDp3aGl0ZTtiYWNrZ3JvdW5kLXBvc2l0aW9uOmluaXRpYWwgaW5p dGlhbDtiYWNrZ3JvdW5kLXJlcGVhdDppbml0aWFsIGluaXRpYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0Ij4gPHNwYW4gbGFuZz0iRU4iPiZuYnNwOzwvc3Bhbj48L3NwYW4+PG86cD48 L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW47YmFja2dyb3VuZDp3aGl0 ZTtiYWNrZ3JvdW5kLXBvc2l0aW9uOmluaXRpYWwgaW5pdGlhbDtiYWNrZ3JvdW5kLXJlcGVhdDpp bml0aWFsIGluaXRpYWwiPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+ VGhpcyBmcmFtZXdvcmsgd2FzIGRlc2lnbmVkIHdpdGggdGhlIGNsZWFyIGV4cGVjdGF0aW9uIHRo YXQgZnV0dXJlIHdvcmsgd2lsbCBkZWZpbmUgcHJlc2NyaXB0aXZlIHByb2ZpbGVzIGFuZCBleHRl bnNpb25zIG5lY2Vzc2FyeSB0byBhY2hpZXZlIGZ1bGwgd2ViLXNjYWxlIGludGVyb3BlcmFiaWxp dHkuPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4iIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+VGhpcyBzcGVj aWZpY2F0aW9uIGVuYWJsZXMgZGlzY292ZXJ5IG9mIGJvdGggZW5kcG9pbnQgbG9jYXRpb25zIGFu ZCBhdXRob3JpemF0aW9uIHNlcnZlciBjYXBhYmlsaXRpZXMuPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5UaGlzIHNwZWNpZmljYXRpb24g aXMgYmFzZWQgdXBvbiB0aGUgYWxyZWFkeSB3aWRlbHkgZGVwbG95ZWQ8c3BhbiBjbGFzcz0iYXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cDovL29wZW5pZC5u ZXQvc3BlY3Mvb3BlbmlkLWNvbm5lY3QtZGlzY292ZXJ5LTFfMC5odG1sIiB0YXJnZXQ9Il9ibGFu ayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+T3BlbklEDQogQ29ubmVjdCBEaXNjb3Zlcnkg MS4wPC9zcGFuPjwvYT48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8 L3NwYW4+c3BlY2lmaWNhdGlvbiBhbmQgaXMgY29tcGF0aWJsZSB3aXRoIGl0LCBieSBkZXNpZ24u Jm5ic3A7IFRoZSBPQXV0aCBEaXNjb3Zlcnkgc3BlYyByZW1vdmVzIHRoZSBwb3J0aW9ucyBvZiBP cGVuSUQgQ29ubmVjdCBEaXNjb3ZlcnkgdGhhdCBhcmUgT3BlbklEIHNwZWNpZmljIGFuZCBhZGRz IG1ldGFkYXRhIHZhbHVlcyBmb3INCiBSZXZvY2F0aW9uIGFuZCBJbnRyb3NwZWN0aW9uIGVuZHBv aW50cy4mbmJzcDsgSXQgYWxzbyBtYXBzIE9wZW5JRCBjb25jZXB0cywgc3VjaCBhcyBPcGVuSUQg UHJvdmlkZXIsIFJlbHlpbmcgUGFydHksIEVuZC1Vc2VyLCBhbmQgSXNzdWVyIHRvIHRoZWlyIE9B dXRoIHVuZGVycGlubmluZ3MsIHJlc3BlY3RpdmVseSBBdXRob3JpemF0aW9uIFNlcnZlciwgQ2xp ZW50LCBSZXNvdXJjZSBPd25lciwgYW5kIHRoZSBuZXdseSBpbnRyb2R1Y2VkIENvbmZpZ3VyYXRp b24NCiBJbmZvcm1hdGlvbiBMb2NhdGlvbi4gJm5ic3A7U29tZSBpZGVudGlmaWVycyB3aXRoIG5h bWVzIHRoYXQgYXBwZWFyIHRvIGJlIE9wZW5JRCBzcGVjaWZpYyB3ZXJlIHJldGFpbmVkIGZvciBj b21wYXRpYmlsaXR5IHB1cnBvc2VzOyBkZXNwaXRlIHRoZSByZXVzZSBvZiB0aGVzZSBpZGVudGlm aWVycyB0aGF0IGFwcGVhciB0byBiZSBPcGVuSUQgc3BlY2lmaWMsIHRoZWlyIHVzYWdlIGluIHRo aXMgc3BlY2lmaWNhdGlvbiBpcyBhY3R1YWxseSByZWZlcnJpbmcNCiB0byBnZW5lcmFsIE9BdXRo IDIuMCBmZWF0dXJlcyB0aGF0IGFyZSBub3Qgc3BlY2lmaWMgdG8gT3BlbklEIENvbm5lY3QuPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOIiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJF TiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5U aGUgc3BlY2lmaWNhdGlvbiBpcyBhdmFpbGFibGUgYXQ6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1mYW1pbHk6U3lt Ym9sIj7Ctzwvc3Bhbj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdCI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9zcGFuPjxzcGFu IGxhbmc9IkVOIiBzdHlsZT0iZm9udC1zaXplOjcuMHB0Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFu Zz0iRU4iIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJp ZiI+PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtam9uZXMtb2F1dGgt ZGlzY292ZXJ5LTAwIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+ aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtam9uZXMtb2F1dGgtZGlzY292ZXJ5LTAw PC9zcGFuPjwvYT48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNw YW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu cy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUi PjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LHNhbnMtc2VyaWYiPkFuIEhUTUwtZm9ybWF0dGVkIHZlcnNpb24gaXMgYWxzbyBhdmFpbGFibGUg YXQ6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9 IkVOIiBzdHlsZT0iZm9udC1mYW1pbHk6U3ltYm9sIj7Ctzwvc3Bhbj48c3BhbiBsYW5nPSJFTiIg c3R5bGU9ImZvbnQtc2l6ZTo3LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1zaXplOjcu MHB0Ij4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxhIGhyZWY9Imh0dHA6Ly9zZWxm LWlzc3VlZC5pbmZvL2RvY3MvZHJhZnQtam9uZXMtb2F1dGgtZGlzY292ZXJ5LTAwLmh0bWwiIHRh cmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwOi8vc2VsZi1pc3N1 ZWQuaW5mby9kb2NzL2RyYWZ0LWpvbmVzLW9hdXRoLWRpc2NvdmVyeS0wMC5odG1sPC9zcGFuPjwv YT48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0i RU4iIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxh bmc9IkVOIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy aWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+UC5TLiZuYnNwOyBU aGlzIG5vdGUgd2FzIGFsc28gcG9zdGVkIGF0PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0dHA6Ly9zZWxmLWlzc3VlZC5pbmZvLz9wPTE0 OTYiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwOi8vc2Vs Zi1pc3N1ZWQuaW5mby8/cD0xNDk2PC9zcGFuPjwvYT48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+YW5kDQogYXM8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly90d2l0dGVyLmNvbS9zZWxm aXNzdWVkIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+QHNlbGZp c3N1ZWQ8L3NwYW4+PC9hPi48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1ib3R0b206MTIuMHB0O2JhY2tncm91bmQ6d2hpdGU7YmFja2dyb3VuZC1wb3NpdGlvbjppbml0 aWFsIGluaXRpYWw7YmFja2dyb3VuZC1yZXBlYXQ6aW5pdGlhbCBpbml0aWFsIj4NCjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PGJyPg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0 aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPjxzcGFu IHN0eWxlPSJjb2xvcjpwdXJwbGUiPk9BdXRoQGlldGYub3JnPC9zcGFuPjwvYT48YnI+DQo8YSBo cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9 Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9vYXV0aDwvc3Bhbj48L2E+PGJyPg0KPGJyPg0KPGJyPg0KPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdDtvcnBoYW5zOiBhdXRvO3RleHQtYWxpZ246c3RhcnQ7d2lk b3dzOiBhdXRvOy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4 Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxp bmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9 ImNvbG9yOnB1cnBsZSI+T0F1dGhAaWV0Zi5vcmc8L3NwYW4+PC9hPjxicj4NCjxhIGhyZWY9Imh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiPjxzcGFuIHN0eWxlPSJj b2xvcjpwdXJwbGUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8 L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+X19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+ DQo8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOnB1cnBsZSI+T0F1dGhAaWV0Zi5vcmc8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYi Pjxicj4NCjwvc3Bhbj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL29hdXRoIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOnB1cnBsZSI+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BY2PR03MB442F731A3C923118AAEC740F5020BY2PR03MB442namprd_-- From nobody Sat Nov 28 15:41:44 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47E6C1A6F83 for ; Sat, 28 Nov 2015 15:41:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Punsck_xebou for ; Sat, 28 Nov 2015 15:41:38 -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 354DA1A6F7B for ; Sat, 28 Nov 2015 15:41:38 -0800 (PST) Received: by qkao63 with SMTP id o63so47087224qka.2 for ; Sat, 28 Nov 2015 15:41:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=1HqaR3uchW455S9xDlwOlLuYaF5jFushcWLEKdNEdmw=; b=ntvPorvp3qpS9XK4D0jJV1uU5HymcSPO4oYBHVefo/sqXTwA2+FgaW99MTb0vPeS9k UhRQOkRqKiv0Lic+7ctr/eqN63gKg9fVUOLMA3a3PhkLpA8u69oU0VJKUHJY0O+LjD+C JuF8FgHjBHZk0bG0h0snA63qWUClZbfNXBVwT4OLj3CsGiBlB1fWB1z/ZXrMx7mqXE+N vi06oSihSgxaE0sddoz2Nh7KwY5OKAU6Cr7ihC3cMNpiOeK0hb2KU6fCX7JQ9KMS/kmn OQnht+HgSr2oyeBrGrsG8qttCcMVd1sVIrSqTzaje09EeNZrMJk6aZ+eQAN+hMVVv431 4AkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=1HqaR3uchW455S9xDlwOlLuYaF5jFushcWLEKdNEdmw=; b=a0Xvi9ogkDA6/DyHyX+3ybVLqfC7GDal7qm0laNRASk+baNIFQcB1lb73zl9vjtJTW vgJUmdJ+MXeVj/IYxzxmopJXQg4g1Y5B1rysoLTwZDV6DUp5bbQI8n9d9R4iXYpIUMAb la76LXDI35FZ202oAZwXnHYq1V4MojklTYYfMkduEVzyk1NkxMcrwV1mF2l75DaCUd04 FanfRzPUasSEqQBl++DqDHh7GzeQYSwD2+Wgs3Zdv99TpVjB9qtWSNFeu15vQquk3+yU eIeK8TBrsCC+yOh30pQbjoHeJkKDa8//lynAVcxiKNy6/1c4lR0VhoYzGP4hVdi2Cd5n qt2A== X-Gm-Message-State: ALoCoQmMi7NTmPF5s25Z3g8BcRVz31x5z07RUM/IK18gu7Ruy9LBGCxCvIeq7wh2Anz9oEo95G0j X-Received: by 10.55.75.87 with SMTP id y84mr62979871qka.56.1448754097330; Sat, 28 Nov 2015 15:41:37 -0800 (PST) Received: from [192.168.8.100] ([181.202.153.166]) by smtp.gmail.com with ESMTPSA id d64sm12117089qgd.48.2015.11.28.15.41.35 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 28 Nov 2015 15:41:36 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_0B2E87BE-CABF-4B7B-8626-C14B4B08CC1E" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: John Bradley In-Reply-To: Date: Sat, 28 Nov 2015 20:41:32 -0300 Message-Id: <8271D74C-7DA4-4B12-82AC-D3C3303006ED@ve7jtb.com> References: <128376572.11963058.1448683100369.JavaMail.yahoo@mail.yahoo.com> <5F43839D-06E7-4E56-BAAC-0F0DE3A553D7@oracle.com> To: Prateek Mishra X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth Discovery X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2015 23:41:41 -0000 --Apple-Mail=_0B2E87BE-CABF-4B7B-8626-C14B4B08CC1E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 No one is saying we shouldn=E2=80=99t. What I said was that Connect will consider refactoring it=E2=80=99s = discovery to be based on the IETF version once there is one if it is = posable. If it is not posable for Connect to use the OAuth discovery from this WG = then that would be a fail. I think we are in agreement. What Mike and I submitted is a starting point. John B. > On Nov 28, 2015, at 7:24 PM, Prateek Mishra = wrote: >=20 > +1 > [quote] >>=20 >> I would like to understand these broader requirements, use cases, and = security considerations first.=20 >>=20 >>=20 >>=20 >> Phil >>=20 >=20 > [\quote] >=20 >=20 > OAuth is being used in a *much* broader set of use-cases and contexts = than OpenID connect.=20 >=20 > I think its very important to have a solution that addresses these = flows.=20 >=20 > - prateek >=20 >=20 >> On Nov 27, 2015, at 20:05, Mike Jones > wrote: >>=20 >>> It allows non-Connect implementation of OAuth 2.0 to also have a = standard discovery capability =E2=80=93 and one that can later be = updated to also support OpenID Connect with no breaking changes, should = that be desired in the future. >>> =20 >>> -- Mike >>> =C2=A0 <> >>> From: Bill Mills [mailto:wmills_92105@yahoo.com = ]=20 >>> Sent: Friday, November 27, 2015 7:58 PM >>> To: Mike Jones >; oauth@ietf.org = >>> Subject: Re: [OAUTH-WG] OAuth Discovery >>> =20 >>> Can you elaborate on the advantage of having a separate parallel = spec to OpenID Discovery? >>> =20 >>> =20 >>> On Wednesday, November 25, 2015 3:37 PM, Mike Jones = > = wrote: >>> =20 >>> I=E2=80=99m pleased to announce that Nat Sakimura, John Bradley, and = I have created an OAuth 2.0 Discovery specification. This fills a hole = in the current OAuth specification set that is necessary to achieve = interoperability. Indeed, the Interoperability section of OAuth 2.0=C2=A0= states: >>> In addition, this specification leaves a few required components = partially or fully undefined (e.g., client registration, authorization = server capabilities, endpoint discovery). Without these components, = clients must be manually and specifically configured against a specific = authorization server and resource server in order to interoperate. >>> =20 >>> This framework was designed with the clear expectation that future = work will define prescriptive profiles and extensions necessary to = achieve full web-scale interoperability. >>> =20 >>> This specification enables discovery of both endpoint locations and = authorization server capabilities. >>> =20 >>> This specification is based upon the already widely deployed OpenID = Connect Discovery 1.0 = = specification and is compatible with it, by design. The OAuth Discovery = spec removes the portions of OpenID Connect Discovery that are OpenID = specific and adds metadata values for Revocation and Introspection = endpoints. It also maps OpenID concepts, such as OpenID Provider, = Relying Party, End-User, and Issuer to their OAuth underpinnings, = respectively Authorization Server, Client, Resource Owner, and the newly = introduced Configuration Information Location. Some identifiers with = names that appear to be OpenID specific were retained for compatibility = purposes; despite the reuse of these identifiers that appear to be = OpenID specific, their usage in this specification is actually referring = to general OAuth 2.0 features that are not specific to OpenID Connect. >>> =20 >>> The specification is available at: >>> =C2=B7 = http://tools.ietf.org/html/draft-jones-oauth-discovery-00 = >>> =20 >>> An HTML-formatted version is also available at: >>> =C2=B7 = http://self-issued.info/docs/draft-jones-oauth-discovery-00.html = >>> =20 >>> -- = Mike >>> =20 >>> P.S. This note was also posted at http://self-issued.info/?p=3D1496 = and as @selfissued = . >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth = >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth = >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = --Apple-Mail=_0B2E87BE-CABF-4B7B-8626-C14B4B08CC1E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 No one is saying we shouldn=E2=80=99t.

What I said was that Connect will = consider refactoring it=E2=80=99s discovery to be based on the IETF = version once there is one if it is posable.

If it is not posable for Connect to use = the OAuth discovery from this WG then that would be a fail.

I think we are in = agreement.

What = Mike and I submitted is a starting point.

John B.

On Nov 28, 2015, at 7:24 PM, = Prateek Mishra <Prateek.Mishra@oracle.com> wrote:

+1
[quote]

I would like to understand these broader requirements, use cases, = and security considerations first. 



Phil


[\quote]


OAuth is being used in = a *much* broader set of use-cases and contexts than OpenID = connect. 

I think its very important to have a solution that = addresses these flows. 

- prateek


On Nov 27, 2015, at 20:05, Mike = Jones <Michael.Jones@microsoft.com> wrote:

It allows = non-Connect implementation of OAuth 2.0 to also have a standard = discovery capability =E2=80=93 and one that can later be updated to also = support OpenID Connect with no breaking changes, should that be desired = in the future.
 
           &n= bsp;           &nbs= p;            =             &n= bsp;         -- Mike
 
From: Bill Mills [mailto:wmills_92105@yahoo.com] 
Sent: Friday, November 27, 2015 = 7:58 PM
To: Mike Jones <Michael.Jones@microsoft.com>; oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth = Discovery
 
Can you elaborate on the advantage = of having a separate parallel spec to OpenID Discovery?
 
 
On Wednesday, = November 25, 2015 3:37 PM, Mike Jones <Michael.Jones@microsoft.com> = wrote:
 
I=E2=80=99m pleased to announce that Nat Sakimura, John = Bradley, and I have created an OAuth 2.0 Discovery specification.  = This fills a hole in the current OAuth specification set that is = necessary to achieve interoperability.  Indeed, the Interoperability section of OAuth 2.0 states:
In addition, this specification leaves a few required components =
partially or fully undefined (e.g., client registration, authorization =
server capabilities, endpoint discovery).  Without these =
components, clients must be manually and specifically configured against =
a specific authorization server and resource server in order to =
interoperate.
  
This framework was designed with the clear expectation that =
future work will define prescriptive profiles and extensions necessary =
to achieve full web-scale interoperability.
 
This specification enables = discovery of both endpoint locations and authorization server = capabilities.
 
This specification is based upon the already widely = deployed OpenID Connect Discovery 1.0 specification and is = compatible with it, by design.  The OAuth Discovery spec removes = the portions of OpenID Connect Discovery that are OpenID specific and = adds metadata values for Revocation and Introspection endpoints.  = It also maps OpenID concepts, such as OpenID Provider, Relying Party, = End-User, and Issuer to their OAuth underpinnings, respectively = Authorization Server, Client, Resource Owner, and the newly introduced = Configuration Information Location.  Some identifiers with names = that appear to be OpenID specific were retained for compatibility = purposes; despite the reuse of these identifiers that appear to be = OpenID specific, their usage in this specification is actually referring = to general OAuth 2.0 features that are not specific to OpenID = Connect.
 
The specification is available at:
=C2=B7         http://tools.ietf.org/html/draft-jones-oauth-discovery-00<= /span>
 
An HTML-formatted version is also available at:
=C2=B7         http://self-issued.info/docs/draft-jones-oauth-discovery-00.ht= ml
 
          &= nbsp;     =             &n= bsp;           &nbs= p;            =            -- = Mike
 
P.S.  This note was also posted at http://self-issued.info/?p=3D1496 and 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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
= --Apple-Mail=_0B2E87BE-CABF-4B7B-8626-C14B4B08CC1E-- From nobody Mon Nov 30 08:15:55 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1952A1ACE74 for ; Mon, 30 Nov 2015 08:15:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cbrC4cdHkjwx for ; Mon, 30 Nov 2015 08:15:52 -0800 (PST) Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A2BA1A6F6F for ; Mon, 30 Nov 2015 08:15:52 -0800 (PST) Received: by igcto18 with SMTP id to18so74329515igc.0 for ; Mon, 30 Nov 2015 08:15:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=t/3DO2DNLB9jJ5DE6TeXRoGjEMa8fWWp0fmLy5i1krc=; b=Z8CdEJAsNTG94+g6t1rvKWdq7Jo6S5Z1YNOKuCgNtXxncVduDupCmAkdxKi6481ieQ HsZOdYvDdu2Y5SJW1JKEINpVyVhIKUnZ4undq1LP8eymgB1ZF3CUOA3TZ2EMiQR9lxlp PSpl1kpzKhCx9+YY4ns0PzPMPqFspq8/RexkB8MDVNG19XT8ihtITI11TuzWeohL4zuv w0JMPgu9J7mdI+vXefxwkgG3Hvr+7IQoMao5cxktaFKGwqcZw0pNT3fxIQBehRzOf739 +GwryeVNCXhQO+qc7leDhJXL5Twgo+ulPtAFI3h+fjq3CerDIl5qB/ehuvZuNZLFo+ci iMAw== MIME-Version: 1.0 X-Received: by 10.50.3.8 with SMTP id 8mr11644865igy.84.1448900151979; Mon, 30 Nov 2015 08:15:51 -0800 (PST) Received: by 10.36.155.131 with HTTP; Mon, 30 Nov 2015 08:15:51 -0800 (PST) Received: by 10.36.155.131 with HTTP; Mon, 30 Nov 2015 08:15:51 -0800 (PST) Date: Mon, 30 Nov 2015 16:15:51 +0000 Message-ID: From: Ronald Aguirre Comaling To: oauth@ietf.org Content-Type: multipart/alternative; boundary=089e0122f64edfb5b10525c45abe Archived-At: Subject: [OAUTH-WG] Re X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2015 16:15:54 -0000 --089e0122f64edfb5b10525c45abe Content-Type: text/plain; charset=UTF-8 Reply aaaa https://about.me/ronaldo_comaling --089e0122f64edfb5b10525c45abe Content-Type: text/html; charset=UTF-8

Reply aaaa

https://about.me/ronaldo_comaling

--089e0122f64edfb5b10525c45abe-- From nobody Mon Nov 30 17:13:53 2015 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 1E16C1B3558; Mon, 30 Nov 2015 17:13:52 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151201011352.3622.9174.idtracker@ietfa.amsl.com> Date: Mon, 30 Nov 2015 17:13:52 -0800 Archived-At: Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-proof-of-possession-08.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 01:13:52 -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 Working Group of the IETF. Title : Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs) Authors : Michael B. Jones John Bradley Hannes Tschofenig Filename : draft-ietf-oauth-proof-of-possession-08.txt Pages : 18 Date : 2015-11-30 Abstract: This specification defines how to express a declaration in a JSON Web Token (JWT) that the presenter of the JWT possesses a particular key and that the recipient can cryptographically confirm proof-of- possession of the key by the presenter. Being able to prove possession of a key is also sometimes described as the presenter being a holder-of-key. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-proof-of-possession/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-proof-of-possession-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 Mon Nov 30 17:18:27 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 311921B3577 for ; Mon, 30 Nov 2015 17:18:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yjj-2OVTOLpl for ; Mon, 30 Nov 2015 17:18:24 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0114.outbound.protection.outlook.com [65.55.169.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF42D1B3576 for ; Mon, 30 Nov 2015 17:18:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=EECLmi2doUDVkr+hN8zXwV6HiBLfKQl2CNubPUPzP94=; b=G5J2ofZETArdu7/Iz/gg4UAujUrS/8ZqKBrBdidJWmae69+wpGagiLimDQgH7Zlmm1Cndq//8xc0c4gTpW08o4AUU6Ub42zbE0PnlOHRD1yOdm/BUfXgnDD01bVT5npAPP4BNaxqNA3sNEDBIYe07tYwXG9QctFPNEewDQCltNM= Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) with Microsoft SMTP Server (TLS) id 15.1.331.20; Tue, 1 Dec 2015 01:18:20 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0331.023; Tue, 1 Dec 2015 01:18:20 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: Proof-of-Possession Key Semantics for JWTs spec addressing additional AD comments Thread-Index: AdEr0yfMliy0mqtvQOmRikmYYgTBvQ== Date: Tue, 1 Dec 2015 01:18:20 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [50.47.85.157] x-microsoft-exchange-diagnostics: 1; BY2PR03MB442; 5:Ymd6Lk8xfTrv6StuEtq62V7EUOv3TkkBlG3ApCr6Qa5waiw/w/nHvNC9rPy8YbGrASu4V9N/HMyYez8AzKvs2jDwJXeD26oI2r2i/5m99XQ8/HIb9FtDsAQYO4TkhBev2XxtxkmTa3y+GYl3SnqN9g==; 24:rQQBXQmOf2gOyWeChPTj+Ij4hM+FhxEURkRU25hV505gVB4ZiR0+vF+afqWKJu7hnxVRxFaC/D3yXUE0Elrph7uwP/06swVWZ/1ysMUSxw0= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB442; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(520078)(10201501046)(3002001)(61426038)(61427038); SRVR:BY2PR03MB442; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB442; x-forefront-prvs: 07778E4001 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(209900001)(189002)(199003)(6116002)(2501003)(92566002)(1220700001)(74316001)(54356999)(33656002)(10090500001)(790700001)(19617315012)(86612001)(86362001)(5004730100002)(15975445007)(97736004)(16236675004)(11100500001)(2351001)(122556002)(101416001)(19580395003)(77096005)(229853001)(230783001)(19300405004)(40100003)(5008740100001)(87936001)(5002640100001)(450100001)(189998001)(50986999)(586003)(1096002)(5001960100002)(66066001)(110136002)(10400500002)(106356001)(81156007)(19625215002)(5005710100001)(99286002)(2900100001)(5003600100002)(105586002)(102836003)(10290500002)(3846002)(76576001)(8990500004)(107886002)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB442; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR03MB4421EA5FA162C2D7347E360F50F0BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Dec 2015 01:18:20.6503 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB442 Archived-At: Subject: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing additional AD comments X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 01:18:26 -0000 --_000_BY2PR03MB4421EA5FA162C2D7347E360F50F0BY2PR03MB442namprd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Proof-of-Possession Key Semantics for JWTs draft -08 addresses additional A= rea Director review comments. A security consideration about utilizing aud= ience restriction in combination with proof-of-possession was added. Thank= s to John Bradley for working on the additional wording with me. The specification is available at: * http://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-08 An HTML formatted version is also available at: * http://self-issued.info/docs/draft-ietf-oauth-proof-of-possession-0= 8.html -- Mike P.S. This note was also posted at http://self-issued.info/?p=3D1499 and as= @selfissued. --_000_BY2PR03MB4421EA5FA162C2D7347E360F50F0BY2PR03MB442namprd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Proof-of-Possession Key Semantics for JWTs draft -08= addresses additional Area Director review comments.  A security consi= deration about utilizing audience restriction in combination with proof-of-= possession was added.  Thanks to John Bradley for working on the additional wording with me.

 

The specification is available at:

·       http://tools.ietf.org/html/draft-ietf-oa= uth-proof-of-possession-08

 

An HTML formatted version is also available at:=

·       http://self-issued.info/docs/draf= t-ietf-oauth-proof-of-possession-08.html

 

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

 

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

 

--_000_BY2PR03MB4421EA5FA162C2D7347E360F50F0BY2PR03MB442namprd_-- From nobody Mon Nov 30 17:21:51 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DB481B358F for ; Mon, 30 Nov 2015 17:21:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PTn25e7oqxqE for ; Mon, 30 Nov 2015 17:21:45 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0132.outbound.protection.outlook.com [207.46.100.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A583F1B358D for ; Mon, 30 Nov 2015 17:21:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=m96vrGyMquvA/CFrlSvIvye/vDfmuzbuSNQmT3sL3p8=; b=MQaiGpQwWhqlAREWrTuz1YZUVGyBgPAA3s/7qX+og3CQcEbJP+4jTlrClZSajm+z+Pk9hWPozrtdFC2bjrN1/vFXSBGNn2zChsrWU3C+D5t6dSjMoYwAu/WGjP6VGC/9lmEgeSRugRMpj31zgn/UOIyGb79zsUS2OEWq9WQ0mBw= Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) with Microsoft SMTP Server (TLS) id 15.1.331.20; Tue, 1 Dec 2015 01:21:43 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0331.023; Tue, 1 Dec 2015 01:21:43 +0000 From: Mike Jones To: John Bradley , Kathleen Moriarty Thread-Topic: [OAUTH-WG] AD review of draft-ietf-oauth-proof-of-possession Thread-Index: AQHRJt++kWDp0FqlfEmPEzc+Ih7voJ6r6UxQgAAee4CAAAb2QIAAAjcAgAAA9fCAATSGAIAACKkAgACR9ZCAAGHOgIAHG+wQ Date: Tue, 1 Dec 2015 01:21:43 +0000 Message-ID: References: <4AF8FE9C-3484-410B-B52F-C1F9706B18A5@ve7jtb.com> <9C5F3F9A-3197-4080-B412-389318780D9A@ve7jtb.com> In-Reply-To: <9C5F3F9A-3197-4080-B412-389318780D9A@ve7jtb.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [50.47.85.157] x-microsoft-exchange-diagnostics: 1; BY2PR03MB442; 5:MIMj6YomKGc5sxIDMjsskbkHWqU96rE5lPq+XkG96AkEkeMmsQy6xjyP5KBxngs0zYCWO/xxdBZi8TlVNoZoMg385Q4m8jmgWnDO4lsADYxfcyc7me5xvFkHZrWovsikgYW9jN9+CcxfOnCzMrWpVQ==; 24:np0ilY88K0FrMoGk3ZfSd+4KHsj4AxC6qQe10qEFfBHoHriEKucOkjO+AugMrB9IXIHrhTeW940reabQNcx6IONYeiWQqsdu49Z0uu67Te4= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB442; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(520078)(10201501046)(3002001)(61426038)(61427038); SRVR:BY2PR03MB442; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB442; x-forefront-prvs: 07778E4001 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(51914003)(189002)(24454002)(199003)(377454003)(51444003)(43784003)(164054003)(13464003)(93886004)(6116002)(5001770100001)(92566002)(1220700001)(74316001)(54356999)(33656002)(2950100001)(10090500001)(86612001)(86362001)(5004730100002)(15975445007)(97736004)(11100500001)(122556002)(101416001)(19580405001)(19580395003)(77096005)(230783001)(40100003)(5008740100001)(87936001)(106116001)(5002640100001)(189998001)(50986999)(586003)(1096002)(5001960100002)(66066001)(10400500002)(106356001)(81156007)(5005710100001)(99286002)(2900100001)(5003600100002)(105586002)(102836003)(10290500002)(76176999)(3846002)(76576001)(8990500004); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB442; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Dec 2015 01:21:43.4850 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB442 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-proof-of-possession X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 01:21:49 -0000 VGhhbmtzIGZvciB0aGUgZGlzY3Vzc2lvbiwgS2F0aGxlZW4gYW5kIEpvaG4sIGFuZCBmb3Igd29y a2luZyBvbiB0aGUgYWRkaXRpb25hbCBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyB3b3JkaW5nIG5v dyBpbiB0aGUgbGFzdCBwYXJhZ3JhcGggb2YgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtaWV0Zi1vYXV0aC1wcm9vZi1vZi1wb3NzZXNzaW9uLTA4I3NlY3Rpb24tNCBhYm91dCB1c2lu ZyBhdWRpZW5jZSByZXN0cmljdGlvbiBpbiBjb21iaW5hdGlvbiB3aXRoIHByb29mLW9mLXBvc3Nl c3Npb24uDQoNCgkJCQktLSBNaWtlIA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJv bTogSm9obiBCcmFkbGV5IFttYWlsdG86dmU3anRiQHZlN2p0Yi5jb21dIA0KU2VudDogVGh1cnNk YXksIE5vdmVtYmVyIDI2LCAyMDE1IDQ6NDUgQU0NClRvOiBNaWtlIEpvbmVzIDxNaWNoYWVsLkpv bmVzQG1pY3Jvc29mdC5jb20+DQpDYzogS2F0aGxlZW4gTW9yaWFydHkgPGthdGhsZWVuLm1vcmlh cnR5LmlldGZAZ21haWwuY29tPjsgb2F1dGhAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbT0FVVEgt V0ddIEFEIHJldmlldyBvZiBkcmFmdC1pZXRmLW9hdXRoLXByb29mLW9mLXBvc3Nlc3Npb24NCg0K TWF5IHNob3VsZCBwZXJoYXBzIGJlIG1pZ2h0LiAgIFRoaXMgc3BlYyBjYW7igJl0IGNvbmZlciBv ciBkZW55IHRoZSBhYmlsaXR5IGZvciBpbXBsZW1lbnRhdGlvbnMgdGhhdCBkb27igJl0IHN1cHBv cnQgdGhpcyBleHRlbnNpb24gdG8gcHJvY2VzcyBKV1QgY29udGFpbmluZyBpdC4NCg0KSSB0aGlu ayB0aGUgY29uY2VybiBpcyB0aGF0IHNvbWUgcGVvcGxlIG1heSBtaXN1bmRlcnN0YW5kIHdoYXQg Y25mIGlzIGRvaW5nLCBhbmQgdGhpbmsgdGhhdCBhIHJlY2lwaWVudCBub3Qgc3VwcG9ydGluZyBj bmYgd291bGQgYXV0b21hdGljYWxseSByZWplY3QgaXQuDQoNCmNuZiBhbGxvd3MgcmVjaXBpZW50 cyB0aGF0IHN1cHBvcnQgY29uZmlybWF0aW9uIG1ldGhvZHMgdG8gcmVqZWN0IHRva2VucyBub3Qg c2VudCBieSBlbnRpdGllcyB0aGF0IHBvc3Nlc3MgdGhlIGNvcnJlY3QgY29uZmlybWF0aW9uIG1h dGVyaWFsLg0KDQpJdCBpcyBhdWQgdGhhdCByZXN0cmljdHMgd2hhdCAgcmVjaXBpZW50cyBjYW4g cHJvY2VzcyB0aGUgYXNzZXJ0aW9uLg0KDQpTbyB1c2UgYXVkIHRvIHJlc3RyaWN0IHRoZSByZWNp cGllbnRzLCBhbmQgY25mIHRvIHJlc3RyaWN0IHRoZSBwcmVzZW50ZXJzLiAgDQoNCkEgcHJvZHVj ZXIgU0hPVUxEIHJlc3RyaWN0IHRoZSB2YWxpZCByZWNpcGllbnRzIGluIGF1ZCB0byByZWNpcGll bnRzIHRoYXQgc3VwcG9ydCB0aGUgY25mIG1lY2hhbmlzbSBvdGhlcndpc2UgdGhleSB3aWxsIG5v dCBnZXQgdGhlIGdldCB0aGUgYmVuZWZpdCBvZiBwcmVzZW50ZXIgcmVzdHJpY3Rpb24gYXQgdGhl IHJlY2lwaWVudHMgdGhhdCBkb27igJl0IHN1cHBvcnQgaXQuDQoNClRoZSBkYW5nZXIgaXMgdGhh dCBzb21lb25lIHVzaW5nIGNuZiB3aWxsIGFzc3VtZSB0aGF0IHRoZSB0b2tlbiBjYW4gb25seSBi ZSB1c2VkIGJ5IHRoZSBlbnRpdHkgcG9zc2Vzc2luZyB0aGUgY25mIG1hdGVyaWFsLCBhbmQgdGhh dCBpcyBub3QgbmVjZXNzYXJpbHkgdHJ1ZS4NCklmIHRoZSB0b2tlbiBpcyBvdGhlcndpc2UgdmFs aWQgKGNvcnJlY3QgaXNzLCBhdWQgYW5kIHNpZykgLCBhbmQgdGhlIHJlY2lwaWVudCBkb2VzbuKA mXQgdW5kZXJzdGFuZCBjbmYgdGhlbiBhIGF0dGFja2VyIHdobyBoYXMgdGhlIHRva2VuIG1pZ2h0 IGJlIGFibGUgdG8gdXNlIGl0IGFzIGEgYmVhcmVyIHRva2VuIGF0IHRoZSBlbmRwb2ludC4NCg0K VGhpcyBpcyBwcm9iYWJseSB0b28gc2VsZiBldmlkZW50IHRvIHVzLCBhcyB3ZSBhcmUgY2xvc2Ug dG8gdGhlIHN1YmplY3QuDQoNClNvIEkgdGhpbmsgdGhhdCB0aGUgbGFzdCBwYXJhZ3JhcGggb2Yg NCBpcyBtb3N0bHkgT0suDQpJIHRoaW5rIGhvd2V2ZXIgd2UgbmVlZCB0byBzYXkgdGhhdCB0aGUg d2F5IHRvIHN0b3AgZW5kcG9pbnRzIHRoYXQgZG9u4oCZdCBzdXBwb3J0IGNuZiBmcm9tIHByb2Nl c3NpbmcgdG9rZW5zIGFzIGJlYXJlciBpcyB0byBub3QgaW5jbHVkZSB0aGVtIGluIHRoZSBhdWQu ICANCg0KT24gYW5vdGhlciBwb2ludCB0aGF0IEthdGhsZWVuIHJhaXNlZCBpbiAzLjENCg0KSSB0 aGluayBLYXRobGVlbidzIHJlYWRpbmcgbWF5IGhhdmUgbGVkIGhlciB0byB0aGUgY29uY2x1c2lv biB0aGF0IGlmIHRoZXJlIGFyZSBubyBtZW1iZXJzIG9mIHRoZSBjbmYgY2xhaW0gdGhhdCB0aGUg cmVjaXBpZW50IHVuZGVyc3RhbmRzIHRoZW4gdGhlIGNuZiBjbGFpbSBpdHNlbGYgTVVTVCBiZSBp Z25vcmVkLg0KVGhhdCB3b3VsZG7igJl0IGJlIG15IGludGVycHJldGF0aW9uIGJ1dCBsb29raW5n IGF0IGl0IGFnYWluLCBJIGNhbiBzZWUgaG93IHNvbWVvbmUgbWlnaHQgcmVhZCBpdCB0aGF0IHdh eS4NCg0KRG8gd2Ugd2FudCB0byBzYXkgdGhhdCBpZiB0aGVyZSBhcmUgbm8gbWVtYmVycyB0aGF0 IHRoZSByZWNpcGllbnQgdW5kZXJzdGFuZHMgdGhlbiBpdCBTSE9VTEQgYmUgYW4gZXJyb3IsIG9y IGxlYXZlIGl0IHVwIHRvIHRoZSBwcm90b2NvbHMgdXNpbmcgY25mIHRvIGRldGVybWluZSBpZiBp dCBzaG91bGQgYmUgcHJvY2Vzc2VkIGFzIGEgYmVhcmVyIHRva2VuLiAgIA0KDQpJbiBhbnkgZXZl bnQgd2UgZG9u4oCZdCB3YW50IHBlb3BsZSBpZ25vcmluZyB0aGUgcmVzdWx0aW5nIGVtcHR5IGNu ZiBjbGFpbS4NCg0KSW4gbW9zdCBjYXNlcyBiZWFyZXIgYW5kIFBPUCB0b2tlbnMgd2lsbCBiZSBw cmVzZW50ZWQgZGlmZmVyZW50bHkgYmVjYXVzZSBQb1AgdG9rZW5zIG5lZWQgYSB3YXkgdG8gcHJl c2VudCB0aGUgcHJvb2YsIHNvIGEgbWlzc2luZyBjbmYgZWxlbWVudCB3b3VsZCBiZSBhIGNsZWFy IGVycm9yLg0KDQpJbiBvdGhlciBjYXNlcyB0aGUgcHJvb2YgbWlnaHQgYmUgcGFzc2l2ZS4gIFRv a2VuIEJpbmRpbmcgb3Igc291cmNlIElQLiAgSW4gdGhhdCBjYXNlIGEgcmVjaXBpZW50IG1pZ2h0 IGxlYXZlIGl0IHVwIHRvIHRoZSBwcm9kdWNlciBvZiB0aGUgdG9rZW4gdG8gZGV0ZXJtaW5lIGlm IGl0IHNob3VsZCBiZSBib3VuZCB0byB0aGUgcHJlc2VudGVyLiAgICANCg0KSSBjYW4gc2VlIGFu IGFyZ3VtZW50IGZvciBzYXlpbmcgYXQgdGhlIHRva2VuIGxldmVsIHRoYXQgYSBKV1QgY29udGFp bmluZyBhIGNuZiBtZW1iZXIgd2l0aCBubyB1bmRlcnN0b29kIG1lbWJlcnMgaXMgbWFsZm9ybWVk Lg0KDQpUaGVzZSBhcmUgdHdvIHNlcGFyYXRlIGlzc3Vlcy4NCg0KSm9obiBCLg0KDQoNCg0KPiBP biBOb3YgMjYsIDIwMTUsIGF0IDM6NTkgQU0sIE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWlj cm9zb2Z0LmNvbT4gd3JvdGU6DQo+IA0KPiBJIGhhZG4ndCBzZWVuIHRoaXMgcGFydCBvZiB0aGUg dGhyZWFkIHVudGlsIG5vdy4gIChJIHRob3VnaHQgaXQgd2FzIA0KPiBwYXJ0IG9mIHRoZSB2b2x1 bWlub3VzIHRocmVhZCBvbiB0aGUgUG9QIGFyY2hpdGVjdHVyZSBkb2N1bWVudC4pDQo+IA0KPiBU aGUgIm1heSBhY2NlcHQgSldUIGNvbnRhaW5pbmcg4oCcY25m4oCdIGVsZW1lbnRzIiBsYW5ndWFn ZSBzb3VuZHMgbGlrZSBpdCdzIGdpdmluZyBhcHBsaWNhdGlvbnMgcGVybWlzc2lvbiB0byBkbyB0 aGlzLiAgSXMgdGhhdCB0aGUgaW50ZW50IG9mIHRoZSBsYW5ndWFnZSB5b3UgcHJvcG9zZWQsIG9y IHdlcmUgeW91IGludGVuZGluZyBzb21ldGhpbmcgZGlmZmVyZW50LCBKb2huPw0KPiANCj4gQWxz bywgY2FuIHlvdSBleHBhbmQgb24gdGhlICJwc2V1ZG8gYXVkaWVuY2UiIGlkZWE/ICBJbiB3aGF0 IHdheSBtaWdodCBhIHByb29mLW9mLXBvc3Nlc3Npb24gYmUgY29uZnVzZWQgd2l0aCBhbiBhdWRp ZW5jZT8NCj4gDQo+IAkJCQlUaGFua3MsDQo+IAkJCQktLSBNaWtlDQo+IA0KPiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBLYXRobGVlbiBNb3JpYXJ0eSBbbWFpbHRvOmthdGhs ZWVuLm1vcmlhcnR5LmlldGZAZ21haWwuY29tXQ0KPiBTZW50OiBXZWRuZXNkYXksIE5vdmVtYmVy IDI1LCAyMDE1IDI6MTMgUE0NCj4gVG86IEpvaG4gQnJhZGxleSA8dmU3anRiQHZlN2p0Yi5jb20+ DQo+IENjOiBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+OyBvYXV0aEBp ZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW09BVVRILVdHXSBBRCByZXZpZXcgb2YgDQo+IGRyYWZ0 LWlldGYtb2F1dGgtcHJvb2Ytb2YtcG9zc2Vzc2lvbg0KPiANCj4gVGhhbmtzLCBKb2huIQ0KPiAN Cj4gT24gV2VkLCBOb3YgMjUsIDIwMTUgYXQgNDo0MSBQTSwgSm9obiBCcmFkbGV5IDx2ZTdqdGJA dmU3anRiLmNvbT4gd3JvdGU6DQo+PiBJIHByZWZlciB0aGUgbmV3IHdvcmRpbmcuDQo+PiANCj4+ IEhvd2V2ZXIgdGhlIGxhc3QgcGFydCBjb3VsZCBiZSBjbGVhcmVyLg0KPj4+IHVzZSBiZSBpbXBs ZW1lbnRlZCBieSByZWNpcGllbnRzLg0KPj4gDQo+PiBPciBwZXJoYXBzIHRoZSBibHVudGVyIOKA nFJlY2lwaWVudHMgb25seSB1bmRlcnN0YW5kaW5nIGJlYXJlciB0b2tlbnMgbWF5IGFjY2VwdCBK V1QgY29udGFpbmluZyDigJxjbmbigJ0gZWxlbWVudHMgaWYgYWxsIHRoZSBvdGhlciByZXF1aXJl ZCBjbGFpbXMgYXJlIHZhbGlkLiAgSXQgaXMgaW1wb3J0YW50IGZvciBzZWN1cml0eSB0byBhdWRp ZW5jZSByZXN0cmljdCB0b2tlbnMgdXNpbmcgdGhlIEpXVCDigJxhdWQgY2xhaW0uICBUaGUg4oCc Y25m4oCdIGNsYWltIE1VU1QgTk9UIGJlIHVzZWQgYXMgYSBwc2V1ZG8gYXVkaWVuY2UgcmVzdHJp Y3Rpb24u4oCdDQo+IA0KPiBNb3JlIGV4cGxpY2l0IHRleHQgbGlrZSB0aGlzIGlzIGlzIG1vcmUg aGVscGZ1bCBpbiBteSBvcGluaW9uLg0KPiANCj4gS2F0aGxlZW4NCj4+IA0KPj4gTG9va2luZyBh dCB0aGUgY29tbWVudHMsIEkgZ2V0IHRoZSBmZWVsaW5nIHRoYXQgc29tZSBwZW9wbGUgbWlnaHQg dGhpbmsgdGhhdCBjbmYgbWF5IHJlc3RyaWN0IHdoYXQgZW5kcG9pbnRzIGNhbiByZWNlaXZlIHRo ZSB0b2tlbiAoYmVjYXVzZSBvZiB0aGUga2V5IGRpc3RyaWJ1dGlvbikgIGl0IG9ubHkgYWxsb3dz IGVuZHBvaW50cyB0aGF0IHNob3VsZCByZWNlaXZlIHRoZSB0b2tlbiB0byByZWplY3Qgb25lcyB0 aGF0IGNvbWUgZnJvbSBlbnRpdGllcyB3aG8gZG9u4oCZdCBwb3NzZXNzIHRoZSBjb3JyZWN0IGNv bmZpcm1hdGlvbi4NCj4+IA0KPj4gSm9obiBCLg0KPj4gDQo+Pj4gT24gTm92IDI1LCAyMDE1LCBh dCAxMjoyNSBBTSwgTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPiB3cm90 ZToNCj4+PiANCj4+PiBSYXRoZXIgdGhhbiBlbGFib3JhdGluZywgaGF2aW5nIGxvb2tlZCBhdCB0 aGUgdGV4dCB3ZSdyZSBkaXNjdXNzaW5nIGFnYWluLCBJJ20gZ29pbmcgdG8gY291bnRlci1wcm9w b3NlIHRoYXQgd2UgaW5zdGVhZCBzaW1wbGlmeSAtIHN0aWNraW5nIG9ubHkgdG8gdGhlIHBvaW50 IHRoYXQgdGhlIHBhcmFncmFwaCBpcyBpbnRlbmRpbmcgdG8gZ2V0IGFjcm9zcy4gIFdvdWxkIGl0 IHdvcmsgZm9yIHlvdSB0byBzaW1wbGlmeSB0aGUgY3VycmVudCB0ZXh0Og0KPj4+IA0KPj4+ICAg IkEgcmVjaXBpZW50IG1pZ2h0IG5vdCB1bmRlcnN0YW5kIHRoZSBjbmYgY2xhaW0sIGluIHdoaWNo IGNhc2UgaXQgd2lsbCB0eXBpY2FsbHkgYmUgaWdub3JlZC4gVW5sZXNzIHRoaXMgaXMgYWNjZXB0 YWJsZSBiZWhhdmlvciwgYXBwbGljYXRpb25zIHRoYXQgbmVlZCB0aGUgcHJvb2Ytb2YtcG9zc2Vz c2lvbiBrZXlzIGNvbW11bmljYXRlZCB3aXRoIGl0IHRvIGJlIHVuZGVyc3Rvb2QgYW5kIHByb2Nl c3NlZCBtdXN0IHJlcXVpcmUgdGhhdCB0aGUgcGFydHMgb2YgdGhpcyBzcGVjaWZpY2F0aW9uIHRo YXQgdGhleSB1c2UgYmUgaW1wbGVtZW50ZWQuIg0KPj4+IA0KPj4+IHRvIHRoaXMgc2ltcGxlciB0 ZXh0Pw0KPj4+IA0KPj4+ICAgIkEgcmVjaXBpZW50IG1pZ2h0IG5vdCB1bmRlcnN0YW5kIHRoZSBj bmYgY2xhaW0uICBBcHBsaWNhdGlvbnMgdGhhdCBuZWVkIHRoZSBwcm9vZi1vZi1wb3NzZXNzaW9u IGtleXMgY29tbXVuaWNhdGVkIHdpdGggaXQgdG8gYmUgdW5kZXJzdG9vZCBhbmQgcHJvY2Vzc2Vk IG11c3QgcmVxdWlyZSB0aGF0IHRoZSBwYXJ0cyBvZiB0aGlzIHNwZWNpZmljYXRpb24gdGhhdCB0 aGV5IHVzZSBiZSBpbXBsZW1lbnRlZC4iDQo+Pj4gDQo+Pj4gVGhlICJtdXN0IGlnbm9yZSIgdG9w aWMgaXMgYWxyZWFkeSBhZGRyZXNzZWQgaW4gdGhlIHNlY29uZCBwYXJhZ3JhcGggb2YgMy4xIChh bmQgd2l0aCBleGFjdGx5IHRoZSBzZW1hbnRpY3MgYXMgdGhlIHJlc3Qgb2YgSldUKSwgYW5kIHNv IGRvZXNuJ3QgaGF2ZSB0byBiZSByZS1yYWlzZWQgaGVyZSwgYXMgaXQgY3VycmVudGx5IGlzLiAg UmUtcmFpc2luZyBpdCBpcyBjbGVhcmx5IGEgcG9pbnQgb2YgZGlzdHJhY3Rpb24uDQo+Pj4gDQo+ Pj4gRm9yIHdoYXQgaXQncyB3b3J0aCwgSSBkb24ndCByZW1lbWJlciBhbnkgRElTQ1VTU2VzIG9u IHRoaXMgdG9waWMgKGFsdGhvdWdoIGl0J3MgcG9zc2libGUgdGhhdCB5b3VyIG1lbW9yeSBpcyBi ZXR0ZXIgdGhhbiBtaW5lIG9uIHRoaXMgcG9pbnQpLg0KPj4+IA0KPj4+ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgQmVzdCB3aXNoZXMsDQo+Pj4gICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAtLSBNaWtlDQo+Pj4gDQo+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+PiBG cm9tOiBLYXRobGVlbiBNb3JpYXJ0eSBbbWFpbHRvOmthdGhsZWVuLm1vcmlhcnR5LmlldGZAZ21h aWwuY29tXQ0KPj4+IFNlbnQ6IFR1ZXNkYXksIE5vdmVtYmVyIDI0LCAyMDE1IDc6MTQgUE0NCj4+ PiBUbzogTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPg0KPj4+IENjOiBv YXV0aEBpZXRmLm9yZw0KPj4+IFN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIEFEIHJldmlldyBvZiAN Cj4+PiBkcmFmdC1pZXRmLW9hdXRoLXByb29mLW9mLXBvc3Nlc3Npb24NCj4+PiANCj4+PiBPbiBU dWUsIE5vdiAyNCwgMjAxNSBhdCAxMDoxMCBQTSwgTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0Bt aWNyb3NvZnQuY29tPiB3cm90ZToNCj4+Pj4gRmFpciBxdWVzdGlvbiBhYm91dCB0aGUgdXNlIG9m ICJ0eXBpY2FsbHkiLiAgVGhlIHJlYXNvbiBpdCdzIHRoZXJlIGlzIHRoYXQgdGhpcyBsYW5ndWFn ZSBpbiBKV1QgW1JGQyA3NTE5XSBTZWN0aW9uIDQgZG9lcyBwZXJtaXQgYXBwbGljYXRpb25zIHRv IHJlcXVpcmUgdGhhdCBKV1RzIHdpdGggbm90LXVuZGVyc3Rvb2QgY2xhaW1zIGJlIHJlamVjdGVk LCByYXRoZXIgdGhhbiBpZ25vcmVkLCBldmVuIHRob3VnaCB0aGF0J3Mgbm90IHRoZSBkZWZhdWx0 IGJlaGF2aW9yOg0KPj4+PiANCj4+Pj4gIFRoZSBzZXQgb2YgY2xhaW1zIHRoYXQgYSBKV1QgbXVz dCBjb250YWluIHRvIGJlIGNvbnNpZGVyZWQgdmFsaWQgDQo+Pj4+IGlzICBjb250ZXh0IGRlcGVu ZGVudCBhbmQgaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBzcGVjaWZpY2F0aW9uLg0KPj4+ PiAgU3BlY2lmaWMgYXBwbGljYXRpb25zIG9mIEpXVHMgd2lsbCByZXF1aXJlIGltcGxlbWVudGF0 aW9ucyB0byAgDQo+Pj4+IHVuZGVyc3RhbmQgYW5kIHByb2Nlc3Mgc29tZSBjbGFpbXMgaW4gcGFy dGljdWxhciB3YXlzLiAgSG93ZXZlciwgaW4gIA0KPj4+PiB0aGUgYWJzZW5jZSBvZiBzdWNoIHJl cXVpcmVtZW50cywgYWxsIGNsYWltcyB0aGF0IGFyZSBub3QgDQo+Pj4+IHVuZGVyc3Rvb2QgIGJ5 IGltcGxlbWVudGF0aW9ucyBNVVNUIGJlIGlnbm9yZWQuDQo+Pj4+IA0KPj4+PiBTbyB3aGVuIG5v dCB1bmRlcnN0b29kLCAiY25mIiB3b3VsZCB0eXBpY2FsbHkgYmUgaWdub3JlZCwgYnV0IG1pZ2h0 IG5vdCBiZS4NCj4+PiANCj4+PiBJIGZpbmQgdGhhdCBjb25mdXNpbmcgYW5kIGFtIG5vdyB0aGlu a2luZyB0aGlzIGNhbWUgdXAgaW4gYSBkaXNjdXNzIGFzIHdlbGwgZHVyaW5nIHRoZSByZXZpZXcg Zm9yIDc1MTksIGRpZG4ndCBpdD8gIENhbiB5b3UgZWxhYm9yYXRlIGludCBlaCBzZWN1cml0eSBj b25zaWRlcmF0aW9ucyBzZWN0aW9uIGEgYml0IG1vcmUsIG90aGVyd2lzZSB0aGlzIHRleHQgYXBw ZWFycyB0byBiZSBjb25mbGljdGluZyBhbmQgZXZlbiB3aXRoIHdoYXQgeW91IGludGVuZCwgaXQn cyBjb25mdXNpbmcgZm9yIGltcGxlbWVudGVycyBhbmQgd2lsbCBsZWFkIHRvIGlzc3VlcyB3aXRo IGludGVyb3BlcmFiaWxpdHkuDQo+Pj4gDQo+Pj4gVGhhbmtzLA0KPj4+IEthdGhsZWVuDQo+Pj4g DQo+Pj4gDQo+Pj4+IA0KPj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtl DQo+Pj4+IA0KPj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+PiBGcm9tOiBLYXRo bGVlbiBNb3JpYXJ0eSBbbWFpbHRvOmthdGhsZWVuLm1vcmlhcnR5LmlldGZAZ21haWwuY29tXQ0K Pj4+PiBTZW50OiBUdWVzZGF5LCBOb3ZlbWJlciAyNCwgMjAxNSA2OjQxIFBNDQo+Pj4+IFRvOiBN aWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+DQo+Pj4+IENjOiBvYXV0aEBp ZXRmLm9yZw0KPj4+PiBTdWJqZWN0OiBSZTogW09BVVRILVdHXSBBRCByZXZpZXcgb2YgDQo+Pj4+ IGRyYWZ0LWlldGYtb2F1dGgtcHJvb2Ytb2YtcG9zc2Vzc2lvbg0KPj4+PiANCj4+Pj4gSGkgTWlr ZSwNCj4+Pj4gDQo+Pj4+IFRoYW5rcyBmb3IgdGhlIHF1aWNrIHR1cm4tYXJvdW5kLiAgSnVzdCBv bmUgbW9yZSBjb21tZW50IG9uIG15IGNvbW1lbnRzLg0KPj4+PiANCj4+Pj4gT24gVHVlLCBOb3Yg MjQsIDIwMTUgYXQgOToxMCBQTSwgTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQu Y29tPiB3cm90ZToNCj4+Pj4+IFRoYW5rcyBmb3IgeW91ciByZXZpZXcgY29tbWVudHMsIEthdGhs ZWVuLiAgUmVzcG9uc2VzIGFyZSBpbmxpbmUgYmVsb3cuLi4NCj4+Pj4+IA0KPj4+Pj4+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+Pj4gRnJvbTogT0F1dGggW21haWx0bzpvYXV0aC1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgS2F0aGxlZW4gDQo+Pj4+Pj4gTW9yaWFydHkN Cj4+Pj4+PiBTZW50OiBUdWVzZGF5LCBOb3ZlbWJlciAyNCwgMjAxNSA5OjQ0IEFNDQo+Pj4+Pj4g VG86IG9hdXRoQGlldGYub3JnDQo+Pj4+Pj4gU3ViamVjdDogW09BVVRILVdHXSBBRCByZXZpZXcg b2YNCj4+Pj4+PiBkcmFmdC1pZXRmLW9hdXRoLXByb29mLW9mLXBvc3Nlc3Npb24NCj4+Pj4+PiAN Cj4+Pj4+PiBIaSwNCj4+Pj4+PiANCj4+Pj4+PiBUaGFuayB5b3UgYWxsIGZvciB5b3VyIHdvcmsg b24gdGhpcyBkcmFmdCEgIEkganVzdCBoYXZlIGEgZmV3IHF1ZXN0aW9uczoNCj4+Pj4+PiANCj4+ Pj4+PiAxLiBTZWN1cml0eSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uIHNheXM6DQo+Pj4+Pj4gDQo+ Pj4+Pj4gIkFsbCBvZiB0aGUgbm9ybWFsIHNlY3VyaXR5IGlzc3VlcywgZXNwZWNpYWxseSBpbiBy ZWxhdGlvbnNoaXAgdG8gIA0KPj4+Pj4+IGNvbXBhcmluZyBVUklzIGFuZCBkZWFsaW5nIHdpdGgg dW5yZWNvZ25pemVkIHZhbHVlcywgdGhhdCBhcmUgIA0KPj4+Pj4+IGRpc2N1c3NlZCBpbiBKV1Qg W0pXVF0gYWxzbyBhcHBseSBoZXJlLiINCj4+Pj4+PiANCj4+Pj4+PiBJIGZpbmQgdGhhdCB0byBi ZSBvZGQgcGhyYXNpbmcgdGhhdCB3b3VsZCBsaWtlbHkgYmUgcGlja2VkIHVwIGluIA0KPj4+Pj4+ IHN1YnNlcXVlbnQgcmV2aWV3cy4gIFBsZWFzZSByZW1vdmUgdGhlIHdvcmQgIm5vcm1hbCIgc28g dGhhdCBhbGwgDQo+Pj4+Pj4gb2YgdGhlIHNlY3VyaXR5IGlzc3VlcyBkaXNjdXNzZXMgaW4gSldU IGFyZSBpbmNsdWRlZC4gIEFyZSB0aGVyZSANCj4+Pj4+PiBvdGhlciAnbm9ybWFsIGNvbnNpZGVy YXRpb25zIGluIGFkZGl0aW9uIHRvIHRob3NlIGluIEpXVCB0aGF0IA0KPj4+Pj4+IG5lZWQgdG8g YmUgbGlzdGVkPyAgVGhlIHBocmFzaW5nIHJlYWRzIGFzIGlmIHRoYXQgbWF5IHRoZSBjYXNlIA0K Pj4+Pj4+IGFuZCB3b3VsZCBiZSBiZXR0ZXIgdG8gaW5jbHVkZSB0aGVtIGFsbCBvciBwb2ludGVy cyBvciBjaGFuZ2UgdGhlIHBocmFzaW5nLg0KPj4+Pj4gDQo+Pj4+PiBZb3UncmUgcmlnaHQuICBJ IHJlbW92ZWQgdGhpcyBhd2t3YXJkIHdvcmRpbmcuDQo+Pj4+PiANCj4+Pj4+PiAyLiBBbHNvIGlu IHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uLA0KPj4+Pj4+IA0KPj4+Pj4+ICAi QSByZWNpcGllbnQgbWF5IG5vdCB1bmRlcnN0YW5kIHRoZSBuZXdseSBpbnRyb2R1Y2VkICJjbmYi IGNsYWltIA0KPj4+Pj4+IGFuZCAgbWF5IGNvbnNlcXVlbnRseSB0cmVhdCBpdCBhcyBhIGJlYXJl ciB0b2tlbi4iDQo+Pj4+Pj4gDQo+Pj4+Pj4gV2hhdCBpcyB0aGUgcHJvcGVyIGhhbmRsaW5nIHJl cXVpcmVtZW50IHdoZW4gYW4gdW5rbm93biBjbGFpbSBpcyANCj4+Pj4+PiBwcmVzZW50PyAgU2Vj dGlvbiAzLjEgc2F5czoNCj4+Pj4+PiAiV2hlbiBhIHJlY2lwaWVudCByZWNlaXZlcyBhICJjbmYi IGNsYWltIHdpdGggYSAgbWVtYmVyIHRoYXQgaXQgDQo+Pj4+Pj4gZG9lcyBub3QgdW5kZXJzdGFu ZCwgaXQgTVVTVCBpZ25vcmUgdGhhdCBtZW1iZXIuIg0KPj4+Pj4+IA0KPj4+Pj4+IElzIHRoaXMg d2h5IGl0IGlzIHRyZWF0ZWQgYXMgYSBiZWFyZXIgdG9rZW4gcmF0aGVyIHRoYW4gYmVpbmcgDQo+ Pj4+Pj4gcmVqZWN0ZWQ/ICBJcyB0aGlzIHJlYWxseSB0aGUgYWN0aW9uIHlvdSB3YW50IHRvIHNl ZSB3aXRoIGNuZj8NCj4+Pj4+PiBXaHkgaXNuJ3QgdGhlcmUgYW4gZXJyb3IgYW5kIGEgcmVzZW5k IGFzIGEgYmVhcmVyIHRva2VuIHNvIHRoYXQgDQo+Pj4+Pj4gcGFydGllcyB1bmRlcnN0YW5kIChv ciBoYXZlIGFuIG9wcG9ydHVuaXR5IHRvIHVuZGVyc3RhbmQpIHRoYXQgdGhlcmUgd2VyZSBpc3N1 ZXM/DQo+Pj4+Pj4gDQo+Pj4+Pj4gVGhlbiB0aGUgZm9sbG93aW5nIHRleHQgaW4gdGhlIHNlY3Vy aXR5IHNlY3Rpb24gc2F5czoNCj4+Pj4+PiAiV2hpbGUgdGhpcyBpcyBhDQo+Pj4+Pj4gIGxlZ2l0 aW1hdGUgY29uY2VybiwgaXQgaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyANCj4+Pj4+PiBz cGVjaWZpY2F0aW9uLCAgc2luY2UgZGVtb25zdHJhdGlvbiB0aGUgcG9zc2Vzc2lvbiBvZiB0aGUg a2V5IA0KPj4+Pj4+IGFzc29jaWF0ZWQgd2l0aCB0aGUgICJjbmYiIGNsYWltIGlzIG5vdCBjb3Zl cmVkIGJ5IHRoaXMgDQo+Pj4+Pj4gc3BlY2lmaWNhdGlvbi4gRm9yIG1vcmUgZGV0YWlscywNCj4+ Pj4+PiANCj4+Pj4+PiBIb3cgaXMgdGhpcyBvdXRzaWRlIG9mIHRoZSBzY29wZSBvZiB0aGlzIGRy YWZ0PyAgY25mIGlzIGRlZmluZWQgDQo+Pj4+Pj4gaW4gdGhpcyBkcmFmdCwgc28gaGFuZGxpbmcg c2hvdWxkIGJlIGNvdmVyZWQgaW4gdGhpcyBkcmFmdC4gIEEgDQo+Pj4+Pj4gcG9pbnRlciB0byB0 aGUgUE9QIGFyY2hpdGVjdHVyZSBkcmFmdCBpcyBub3QgaGVscGZ1bCBhcyBpdCBpcyBub3QgDQo+ Pj4+Pj4gZGVmaW5lZCB0aGVyZSwgaXQncyBjb3ZlcmVkIGludCBoaXMgZHJhZnQuICBTaG91bGQg dGhpcyB0ZXh0IGp1c3QgDQo+Pj4+Pj4gYmUgcmVtb3ZlZCBhbmQgcmVwbGFjZWQgd2l0aCBtb3Jl IGV4cGxpY2l0IGhhbmRsaW5nIGluZm9ybWF0aW9uIGludCBoZSBib2R5IG9mIHRoaXMgZHJhZnQ/ DQo+Pj4+PiANCj4+Pj4+IEdvb2QgY2F0Y2guICBKV1QgW1JGQyA3NTE5XSBTZWN0aW9uIDQgc2F5 cyB0aGF0IGNsYWltcyB0aGF0IGFyZSBub3QgdW5kZXJzdG9vZCBtdXN0IGJlIGlnbm9yZWQgdW5s ZXNzIG90aGVyd2lzZSBzcGVjaWZpZWQgYnkgdGhlIGFwcGxpY2F0aW9uLiAgVGhpcyBhbGxvd3Mg bmV3IGNsYWltcyB0byBiZSBkeW5hbWljYWxseSBhZGRlZCB3aXRob3V0IGJyZWFraW5nIGV4aXN0 aW5nIGFwcGxpY2F0aW9ucy4gIEZvciB0aGUgc2FtZSByZWFzb24sIEkgaGF2ZSBpbmNvcnBvcmF0 ZWQgdGhpcyBsYW5ndWFnZSBhYm91dCB1bmRlcnN0YW5kaW5nIGNsYWltcyBmcm9tIDc1MTksIGJ1 dCBoYXZpbmcgaXQgYmUgYWJvdXQgdW5kZXJzdGFuZGluZyBjb25maXJtYXRpb24gbWVtYmVycy4g IFVsdGltYXRlbHksIHdoYXQgZmVhdHVyZXMgbXVzdCBiZSBpbXBsZW1lbnRlZCBhcmUgYWx3YXlz IHVwIHRvIHRoZSBhcHBsaWNhdGlvbiwganVzdCBhcyB3aXRoIEpXVCBjbGFpbXMuDQo+Pj4+IA0K Pj4+PiBUaGUgbmV3IHRleHQgaW4gU2VjdGlvbiAzLjEgbG9va3MgZ29vZC4gIEknbSBub3Qgc3Vy ZSB3aHkgdGhlIHdvcmQgInR5cGljYWxseSIgYXBwZWFycyBpbnQgaGUgbmV3IHRleHQgb2YgdGhl IHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHNlY3Rpb24gdGhvdWdoIGFmdGVyIHJlYWRpbmcgdGhl IG5ldyB0ZXh0IGluIDMuMS4gIFdvdWxkbid0IGl0IGp1c3QgYmUgaWdub3JlZCBzaW5jZSAzLjEg bm93IHNheXM6DQo+Pj4+IA0KPj4+PiAgIkhvd2V2ZXIsIGluIHRoZSBhYnNlbmNlIG9mIHN1Y2gg cmVxdWlyZW1lbnRzLA0KPj4+PiAgIGFsbCBjb25maXJtYXRpb24gbWVtYmVycyB0aGF0IGFyZSBu b3QgdW5kZXJzdG9vZCBieSBpbXBsZW1lbnRhdGlvbnMNCj4+Pj4gICBNVVNUIGJlIGlnbm9yZWQu Ig0KPj4+PiANCj4+Pj4gVGhhbmtzLA0KPj4+PiBLYXRobGVlbg0KPj4+PiANCj4+Pj4gDQo+Pj4+ PiANCj4+Pj4+PiBUaGFua3MhDQo+Pj4+Pj4gDQo+Pj4+Pj4gLS0NCj4+Pj4+PiANCj4+Pj4+PiBC ZXN0IHJlZ2FyZHMsDQo+Pj4+Pj4gS2F0aGxlZW4NCj4+Pj4+PiANCj4+Pj4+PiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4+IE9BdXRoIG1haWxp bmcgbGlzdA0KPj4+Pj4+IE9BdXRoQGlldGYub3JnDQo+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KPj4+Pj4gDQo+Pj4+PiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBUaGFua3MgYWdhaW4sDQo+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAtLSBNaWtlDQo+Pj4+PiANCj4+Pj4gDQo+Pj4+IA0KPj4+PiANCj4+Pj4gLS0NCj4+ Pj4gDQo+Pj4+IEJlc3QgcmVnYXJkcywNCj4+Pj4gS2F0aGxlZW4NCj4+PiANCj4+PiANCj4+PiAN Cj4+PiAtLQ0KPj4+IA0KPj4+IEJlc3QgcmVnYXJkcywNCj4+PiBLYXRobGVlbg0KPj4+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4gT0F1dGggbWFp bGluZyBsaXN0DQo+Pj4gT0F1dGhAaWV0Zi5vcmcNCj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL29hdXRoDQo+PiANCj4gDQo+IA0KPiANCj4gLS0NCj4gDQo+IEJlc3Qg cmVnYXJkcywNCj4gS2F0aGxlZW4NCg0K