From nobody Fri Dec 1 10:12:33 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2A57127876 for ; Fri, 1 Dec 2017 10:12:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.617 X-Spam-Level: X-Spam-Status: No, score=-1.617 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vfxJOXF-00ng for ; Fri, 1 Dec 2017 10:12:29 -0800 (PST) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [IPv6:2a01:e0c:1:1599::15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B22312762F for ; Fri, 1 Dec 2017 10:12:29 -0800 (PST) Received: from [192.168.0.13] (unknown [88.182.125.39]) by smtp6-g21.free.fr (Postfix) with ESMTP id ECD21780336 for ; Fri, 1 Dec 2017 19:12:26 +0100 (CET) To: oauth@ietf.org References: <151208615408.11802.12175452260900272912@ietfa.amsl.com> From: Denis Message-ID: Date: Fri, 1 Dec 2017 19:12:30 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <151208615408.11802.12175452260900272912@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------2470B47927CC114E82FF06B9" Content-Language: en-US Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchange-10.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Dec 2017 18:12:32 -0000 This is a multi-part message in MIME format. --------------2470B47927CC114E82FF06B9 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Comments on draft-ietf-oauth-token-exchange-10 I propose the following rephrasing for sections 6 and 7: 6 . Security Considerations All of the normal security issues that are discussed in [JWT],especially in relationship to comparing URIs and dealing with unrecognized values, also apply here.  In addition, both delegation and impersonation introduce unique security issues. Any time one user receives a token, the potential for abuse is a concern, since that user might be willing to collude with another user so that other user could use the token. Techniques like the binding of an access token to a TLS channel described elsewhere are ineffective since the legitimate user would be able to perform all the cryptographic computations that the other user would need to demonstrate the ownership of the token. The use of the "scp" claim is suggested to mitigate potential for such abuse, as it restricts the contexts in which the token can be exercised. If the issued access token scope allows to unambiguously identify the user, then that user is likely to be reluctant to collude with another user. However, if the issued access token scope only indicates that the user is over 18, then there is no risk for the original user to be discovered and in such a context a collusion may easily take place. This document does not specify techniques to prevent such a collusion to be successful. 7 . Privacy Considerations Tokens typically carry personal information and their usage in Token Exchange may reveal details of the target services being accessed. The resource and the audience parameters allow authorization servers to know where the issued access token will be used. This may be a privacy concern for some users. This document does not specify techniques to prevent authorization servers to know where the access tokens they issue will be used. Denis > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Web Authorization Protocol WG of the IETF. > > Title : OAuth 2.0 Token Exchange > Authors : Michael B. Jones > Anthony Nadalin > Brian Campbell > John Bradley > Chuck Mortimore > Filename : draft-ietf-oauth-token-exchange-10.txt > Pages : 32 > Date : 2017-11-30 > > Abstract: > This specification defines a protocol for an HTTP- and JSON- based > Security Token Service (STS) by defining how to request and obtain > security tokens from OAuth 2.0 authorization servers, including > security tokens employing impersonation and delegation. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-10 > https://datatracker.ietf.org/doc/html/draft-ietf-oauth-token-exchange-10 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-token-exchange-10 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------2470B47927CC114E82FF06B9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Comments on draft-ietf-oauth-token-exchange-10

I propose the following rephrasing for sections 6 and 7:

6 . Security Considerations

All of the normal security issues that are discussed in [JWT],especially in relationship to comparing URIs
and dealing with unrecognized values, also apply here.  In addition, both delegation and impersonation introduce
unique security issues. Any time one user receives a token, the potential for abuse is a concern,
since that user might be willing to collude with another user so that other user could use the token.
 
Techniques like the binding of an access token to a TLS channel described elsewhere are ineffective since
the legitimate user would be able to perform all the cryptographic computations that the other user would need
to demonstrate the ownership of the token. The use of the "scp" claim is suggested to mitigate potential for
such abuse, as it restricts the contexts in which the token can be exercised.  If the issued access token scope
allows to unambiguously identify the user, then that user is likely to be reluctant to collude with another user.  
However, if the issued access token scope only indicates that the user is over 18, then there is no risk
for the original user to be discovered and in such a context a collusion may easily take place.
This document does not specify techniques to prevent such a collusion to be successful.

7 . Privacy Considerations

Tokens typically carry personal information and their usage in Token Exchange may reveal details of the target services
being accessed. The resource and the audience parameters allow authorization servers to know where the issued access token
will be used.  This may be a privacy concern for some users. This document does not specify techniques to prevent
authorization servers to know where the access tokens they issue will be used.

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

        Title           : OAuth 2.0 Token Exchange
        Authors         : Michael B. Jones
                          Anthony Nadalin
                          Brian Campbell
                          John Bradley
                          Chuck Mortimore
	Filename        : draft-ietf-oauth-token-exchange-10.txt
	Pages           : 32
	Date            : 2017-11-30

Abstract:
   This specification defines a protocol for an HTTP- and JSON- based
   Security Token Service (STS) by defining how to request and obtain
   security tokens from OAuth 2.0 authorization servers, including
   security tokens employing impersonation and delegation.


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

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

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


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

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

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


--------------2470B47927CC114E82FF06B9-- From nobody Wed Dec 6 13:31:26 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D08A1270AC for ; Wed, 6 Dec 2017 13:31:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.421 X-Spam-Level: X-Spam-Status: No, score=-1.421 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ornRe46XZQY for ; Wed, 6 Dec 2017 13:31:22 -0800 (PST) Received: from mail-ua0-f178.google.com (mail-ua0-f178.google.com [209.85.217.178]) (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 7F9721200FC for ; Wed, 6 Dec 2017 13:31:22 -0800 (PST) Received: by mail-ua0-f178.google.com with SMTP id j14so3884544uag.11 for ; Wed, 06 Dec 2017 13:31:22 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=SsHrGDpuGt3R6goxSLMXqvF1IPIxb7pIJti7LktiRxw=; b=ICLrrTKLR3qcPC3RCUzIdQpOq6F1nzJyi+qFTqbXgsfQhDj0YtyIapWH4q2frjIgqk T1JuYwhcXz1E2BjFMmlezxbg2NIhJ/l2zCluFbWXrYZN/0f8h0rr2L32UDQ0I6LpRHoo 7cip7xBTFnYYfoNuZ4L6A1C6cpqDsTWUOUCAsLGtqeauIFhHVhPI3xhVwKDXAKIrSWZd b1A8JWfSpGWm0Pc8VEc72pJoQ7Hd+52e6xj94sI1HwAX4kLp5+2Meg7pAzCgeIpGRJj6 i9iEZORIQC0WuMIgctgZocHyHYa52iX35/DjnCsHid/W+gOx8wHezveSsY/lBeshjqvd oB8Q== X-Gm-Message-State: AKGB3mJPJlpM2vqNfMorjYufgq8ab4awLrDIXgCwJg/e8pwirhhANd/y wnzv+JPxAlPHIf9i0WctxxwXZJk3/LuldcO8fvkwf2BF X-Google-Smtp-Source: AGs4zMYHme6poqy0Cnc44/j5xjKE/IWgpr3asEtSymT1o+omW1RJrJAhjIWDq6aknrUlNa3iW5oSW1ilDFqb4FbxuEg= X-Received: by 10.176.72.137 with SMTP id x9mr11447762uac.76.1512595881087; Wed, 06 Dec 2017 13:31:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.68.86 with HTTP; Wed, 6 Dec 2017 13:31:20 -0800 (PST) From: Bill Burke Date: Wed, 6 Dec 2017 16:31:20 -0500 Message-ID: To: OAuth WG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [OAUTH-WG] [token-exchange] Parameters to support external token exchange X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Dec 2017 21:31:24 -0000 The Keycloak project (oss idp), has implemented [1] the token exchange draft (minus the actor token). There's a couple of extensions we have made to allow external token exchange to work. I'd like to get some consideration for these extensions to be added. With proper configurations, clients are able to exchange between different domains and even social providers. i.e. you can exchange a Facebook token for a token issued by the IDP. Here are the details: We added a 'subject_issuer' parameter. Many OAuth IDPs have opaque access tokens and do not use JWTs for their access token (i.e. Facebook and Google). If the 'subject_token_type' is 'urn:ietf:params:oauth:token-type:access_token' and the access token comes from an external provider, then the client must also pass a 'subject_issuer'. The parameter value is something, anything that can the IDP can resolve to an external provider. How the validation of this external token happens is implementation independent. As I stated a few months back in an earlier email thread, I do not think the 'audience' parameter would work for this type of external exchange. It is just too overloaded. Additionally, I think it is cleaner to specify an additional parameter rather than extracting issuer information from the 'subject_token_type'. You could do this, but the spec would also have to define a URI scheme for 'subject_token_type' so that issuer information could be transmitted. We also added a 'requested_issuer' parameter. This allows the client to request an external provider to obtain a token from. Same reasons and rules as 'subject_token_type'. When 'requested_issuer' flow is done, user consent is often required before the request issuer can issue a token for the user. When this is the case, a 400 response is returned with the following JSON document: { "error" : "....", "error_description" : "..." "account-link-url" : "https://...." } The error claim will be either token_expired or not_linked. The 'account-link-url' claim is a link that the client can forward an user agent to to obtain consent. The client simply appends a 'redirect_uri' query parameter to this link and forwards the browser for consent. This 'redirect_uri' must be a registered and valid redirect uri for the forwarding client. After the redirect, the client can then make an exchange request. For error conditions, the redirect_uri may by forwarded to with an additional 'error' query parameter depending on whether the IDP deams it safe to do so. Thanks, Bill [1] http://www.keycloak.org/docs/latest/securing_apps/index.html#_token-exchange -- Bill Burke Red Hat From nobody Thu Dec 7 09:00:17 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EACF1294A3 for ; Thu, 7 Dec 2017 09:00:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.699 X-Spam-Level: X-Spam-Status: No, score=-4.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mx.aol.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZviD8pwXEXHz for ; Thu, 7 Dec 2017 09:00:13 -0800 (PST) Received: from omr-a018e.mx.aol.com (omr-a018e.mx.aol.com [204.29.186.64]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 887B41294A8 for ; Thu, 7 Dec 2017 09:00:13 -0800 (PST) Received: from mtaout-mbc01.mx.aol.com (mtaout-mbc01.mx.aol.com [172.26.221.141]) by omr-a018e.mx.aol.com (Outbound Mail Relay) with ESMTP id D0F853800055; Thu, 7 Dec 2017 12:00:12 -0500 (EST) Received: from [10.89.82.127] (unknown [98.139.248.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mtaout-mbc01.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id E2F8E380000A0; Thu, 7 Dec 2017 12:00:11 -0500 (EST) To: "oauth@ietf.org" From: George Fletcher Organization: AOL LLC Message-ID: Date: Thu, 7 Dec 2017 12:00:10 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------5E82469B1E037FDBA22396F1" Content-Language: en-US x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20150623; t=1512666012; bh=NSl+piFxqTbKJhjHokq4TUdSTJj6IbAeNX0Xv+116YU=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=w81UqYTC3gar2lIPK2AQdJuPr2EPHnCILQTs+3oG6SXNi+J7nLbecvTo3QpNSxw0o xkbIv/tMEC3gf2iQ6akc8h4vzvehbN2TsPBDEedmULu1MzvtZOv+FVQY2x1QwGDgup kxXMzU3Hj3bn/odafY12h8ZQg2QMVNW9U0wkL1zQ= x-aol-sid: 3039ac1add8d5a29739b12e7 X-AOL-IP: 98.139.248.67 Archived-At: Subject: [OAUTH-WG] Token exchange use cases X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Dec 2017 17:00:15 -0000 This is a multi-part message in MIME format. --------------5E82469B1E037FDBA22396F1 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I have a use case for which I'd like to leverage the token exchange spec... 1. As part of an identity migration effort, I'd like to exchange a refresh_token issued by one AS for a refresh_token, access_token and potentially id_token issued by a second AS. For this use case I have two questions...    -- does the spec allow me to extend the response to include an additional "claim" in the response?        refresh_token and access_token are already defined, but id_token is not    -- what would I use as the desired "requested_token_type"?        should it be a "virtual" token type that then represents the tokens to be returned in the response?        It looks like I could also leave the "requested_token_type" blank and just let the AS do what it wants. Is that the best option? Thanks, George --------------5E82469B1E037FDBA22396F1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit I have a use case for which I'd like to leverage the token exchange spec...

1. As part of an identity migration effort, I'd like to exchange a refresh_token issued by one AS for a refresh_token, access_token and potentially id_token issued by a second AS.

For this use case I have two questions...

   -- does the spec allow me to extend the response to include an additional "claim" in the response?
       refresh_token and access_token are already defined, but id_token is not

   -- what would I use as the desired "requested_token_type"?
       should it be a "virtual" token type that then represents the tokens to be returned in the response?
       It looks like I could also leave the "requested_token_type" blank and just let the AS do what it wants. Is that the best option?

Thanks,
George
 --------------5E82469B1E037FDBA22396F1-- From nobody Fri Dec 8 09:41:45 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45588127077 for ; Fri, 8 Dec 2017 09:41:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zBT4Hdyk5xy0 for ; Fri, 8 Dec 2017 09:41:41 -0800 (PST) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::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 C8405126DFB for ; Fri, 8 Dec 2017 09:41:40 -0800 (PST) Received: by mail-it0-x22a.google.com with SMTP id b5so6459612itc.3 for ; Fri, 08 Dec 2017 09:41:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+ybRA3YYnMcK3yKQH9Tb0aBGxlqb0CloVqNFZITBOWk=; b=Pgi9iohiWJ0s9OYWH2Ll5rsC51F+T6X7E7T7EGcaSeeErAQz+7SEWb14hTdTric38i jrRjcA8XJ7GyQk0xmBqkmt4jUoDGhM5drSHPKY84vum/ta6vt1Rl0Hn6LJ4L+5xZfINF GOPw6sRURcgXwDy1uhOlQaXwyocS0Mx8a415U= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+ybRA3YYnMcK3yKQH9Tb0aBGxlqb0CloVqNFZITBOWk=; b=n7LfD8Ya5xzBxWLx/2mAL5O5plaIVY73XYpEqK+gpHcfj4S/yxLCHeWdBkxxggybk7 CWMzm0EpUv78mpmqFQ7bgqob/ukbOpxfvUA1BKUi2Az3cUUqBdQhb/mW1zounXkpN2fJ z77ZvV2isUq59L/S1mvrLHYFCGceypNAjHmyZftJ9TnzEmf0O8jjVL+2sET/9asoxrr1 wF7xOjY/Z2+FHIDwgONq0Litt8mWQBHv7fJOfq2dT0BzhcS2OR1SuozeeAxuS3IWzamw GGs5IgBlrjEJGE0PGgpq9QFgntveZXV+cSHm3Ndx19Nu8K4ArsgWT+X3/X927cWvI1fD 5POg== X-Gm-Message-State: AJaThX7vmy1yl0+2wv7qOr1GJ5QEOJKEU1nuNMUHLA7ix7HNaHKHl56+ JinMyT7mbs5NP/m64WiziJvmgj3Bz977dlva9E3vf2N+8hL8VbJ7Ig/SfSTXswTe8Like3wBNnB 1LCVQ+Oncj50ILQU/ X-Google-Smtp-Source: AGs4zMYWOk0p7pEyrqDB+/E44FC9cEMOoDyBqgY2Q7SXlDimu2QbjmYK7fD4v6QVwlgBCOSRCxjVKkGOT79LiSTKcC4= X-Received: by 10.107.48.197 with SMTP id w188mr44230776iow.301.1512754899821; Fri, 08 Dec 2017 09:41:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.2.118.194 with HTTP; Fri, 8 Dec 2017 09:41:09 -0800 (PST) In-Reply-To: References: From: Brian Campbell Date: Fri, 8 Dec 2017 10:41:09 -0700 Message-ID: To: Bill Burke Cc: OAuth WG Content-Type: multipart/alternative; boundary="001a11444bfa6fd680055fd7b283" Archived-At: Subject: Re: [OAUTH-WG] [token-exchange] Parameters to support external token exchange X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Dec 2017 17:41:43 -0000 --001a11444bfa6fd680055fd7b283 Content-Type: text/plain; charset="UTF-8" I guess I'm going to kind of restate some of what I said in that earlier thread and a bit more. The access and refresh token URIs from the draft are intended to indicate that such tokens are issued by the given authorization server acting as the STS (perhaps this could be stated more clearly in the doc). As such, there isn't direct explicit support for OAuth access token to OAuth access token cross-domain type exchanges. That was intentional and I think is appropriate as I don't believe this draft should delve into pseudo federating access tokens and all the additional complexity and security implications that entails. The assertion based authorization grants (RFCs 7523 & 7522 ) are intended to facilitate acquiring an access token from an external or cross-domain AS and I prefer that more explicit model for cross-domain than codifying a rather implicit way of doing it in token exchange. A Facebook access token, for example, is issued to a client for delegated access to Facebook APIs. It isn't for delegated access to some other domain's APIs but an access token for access token exchange effectively turns it into that. And in some situations that can have problematic security implications. Big providers like Facebook have a lot of apps (OAuth clients) that can get access tokens. An organization might well be okay with an app it controls exchanging a Facebook access token for an access token for its own APIs. But a 3rd party Facebook app (like maybe a new viral rate my '80's hairdo app) doing the same thing could be very problematic. It's not exactly the same thing but many of the same potential issues arise as when using OAuth for User Authentication . Standardization around access token for access token exchange would, at a minimum, need some real security analysis and recommendations/considerations. The token exchange draft went thought WGLC some time ago and is currently being written up by the document shepherd to send to the AD. It's close. It's been a long time coming and I'd really object to derailing it by making big additions to it at this late stage in the process. If explicit support for directly swapping an access token from one AS for an access token issued by a different AS is something this WG is interested in working on, while admittedly I have my hesitations, I propose/suggest that it be done in a new document. Such a document could but wouldn't necessarily have to take the from of the additional extension parameters you've mentioned. It could, for example, be a 'token profile' of sorts that defines a new URI with an associated format that is some simple structure that carries both the access token and issuer together. Something like "urn:ietf:params:oauth:token-type:wrapped_foreign_access_token" and {"issuer":"https://api.login.yahoo.com","token":"bwcK0esc3ACC3DB2Y5_lESsXE8o9ltc05O89jdN-dg2"} - that's just spitballing but hopefully conveys the idea. The new document would also have to cover the security considerations. On Wed, Dec 6, 2017 at 2:31 PM, Bill Burke wrote: > The Keycloak project (oss idp), has implemented [1] the token exchange > draft (minus the actor token). There's a couple of extensions we have > made to allow external token exchange to work. I'd like to get some > consideration for these extensions to be added. With proper > configurations, clients are able to exchange between different domains > and even social providers. i.e. you can exchange a Facebook token for > a token issued by the IDP. > > Here are the details: > > We added a 'subject_issuer' parameter. Many OAuth IDPs have opaque > access tokens and do not use JWTs for their access token (i.e. > Facebook and Google). If the 'subject_token_type' is > 'urn:ietf:params:oauth:token-type:access_token' and the access token > comes from an external provider, then the client must also pass a > 'subject_issuer'. The parameter value is something, anything that can > the IDP can resolve to an external provider. How the validation of > this external token happens is implementation independent. > > As I stated a few months back in an earlier email thread, I do not > think the 'audience' parameter would work for this type of external > exchange. It is just too overloaded. Additionally, I think it is > cleaner to specify an additional parameter rather than extracting > issuer information from the 'subject_token_type'. You could do this, > but the spec would also have to define a URI scheme for > 'subject_token_type' so that issuer information could be transmitted. > > We also added a 'requested_issuer' parameter. This allows the client > to request an external provider to obtain a token from. Same reasons > and rules as 'subject_token_type'. > > When 'requested_issuer' flow is done, user consent is often required > before the request issuer can issue a token for the user. When this > is the case, a 400 response is returned with the following JSON > document: > > { > "error" : "....", > "error_description" : "..." > "account-link-url" : "https://...." > } > > The error claim will be either token_expired or not_linked. The > 'account-link-url' claim is a link that the client can forward an user > agent to to obtain consent. The client simply appends a > 'redirect_uri' query parameter to this link and forwards the browser > for consent. This 'redirect_uri' must be a registered and valid > redirect uri for the forwarding client. After the redirect, the > client can then make an exchange request. For error conditions, the > redirect_uri may by forwarded to with an additional 'error' query > parameter depending on whether the IDP deams it safe to do so. > > > Thanks, > > Bill > > [1] http://www.keycloak.org/docs/latest/securing_apps/index. > html#_token-exchange > > -- > Bill Burke > Red Hat > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- *CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.* --001a11444bfa6fd680055fd7b283 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I guess I'm going to kind of restate some of what= I said in that earlier thread and a bit more. The access and refresh token URI= s from the draft are intended to indicate that such tokens are issued by th= e given authorization server acting as the STS (perhaps this could be state= d more clearly in the doc). As such, there isn't direct explicit suppor= t for OAuth access token to OAuth access token cross-domain type exchanges.= That was intentional and I think is appropriate as I don't believe thi= s draft should delve into pseudo federating access tokens and all the addit= ional complexity and security implications that entails. The assertion base= d authorization grants (RFCs 7523 & 7522) are intended to facilitate acquiring an= access token from an external or cross-domain AS and I prefer that more ex= plicit model for cross-domain than codifying a rather implicit way of doing= it in token exchange. A Facebook access token, for example, is issued to a= client for delegated access to Facebook APIs. It isn't for delegated a= ccess to some other domain's APIs but an access token for access token = exchange effectively turns it into that. And in some situations that can ha= ve problematic security implications. Big providers like Facebook have a lo= t of apps (OAuth clients) that can get access tokens. An organization might= well be okay with an app it controls exchanging a Facebook access token fo= r an access token for its own APIs. But a 3rd party Facebook app (like mayb= e a new viral rate my '80's hairdo app) doing the same thing could = be very problematic. It's not exactly the same thing but many of the sa= me potential issues arise as when using OAuth for User Authentication. St= andardization around access token for access token exchange would, at a min= imum, need some real security analysis and recommendations/considerati= ons.

The token exchange draft went thought WG= LC some time ago and is currently being written up by the document shepherd to send to the AD. = It's close. It's been a long time coming and I'd really object = to derailing it by making big additions to it at this late stage in the pro= cess.

If explicit support for directly swapp= ing an access token from one AS for an access token issued by a different AS is so= mething this WG is interested in working on, while admittedly I have my hes= itations, I propose/suggest that it be done in a new document. Such a docum= ent could but wouldn't necessarily have to take the from of the additio= nal extension parameters you've mentioned. It could, for example, be a = 'token profile' of sorts that defines a new URI with an associated = format that is some simple structure that carries both the access token and= issuer together. Something like "urn:ietf:params:oauth:token-typ= e:wrapped_foreign_access_token" and {"issuer":"https://api.login.yahoo.com","token":"bwcK0esc3ACC3DB2Y5_lESsXE8o9ltc05O89jdN-dg2"} - that's just spitballing but hopefull= y conveys the idea. The new document would also have to cover the security = considerations.



=

On Wed, Dec 6, 2017 at 2:31 PM, Bill Burke <bburke@redhat.com> wrote:
The Keycloak project (oss id= p), has implemented [1] the token exchange
draft (minus the actor token).=C2=A0 There's a couple of extensions we = have
made to allow external token exchange to work.=C2=A0 I'd like to get so= me
consideration for these extensions to be added.=C2=A0 With proper
configurations, clients are able to exchange between different domains
and even social providers.=C2=A0 i.e. you can exchange a Facebook token for=
a token issued by the IDP.

Here are the details:

We added a 'subject_issuer' parameter.=C2=A0 Many OAuth IDPs have o= paque
access tokens and do not use JWTs for their access token (i.e.
Facebook and Google).=C2=A0 If the 'subject_token_type' is
'urn:ietf:params:oauth:token-type:access_token' and the access= token
comes from an external provider, then the client must also pass a
'subject_issuer'.=C2=A0 The parameter value is something, anything = that can
the IDP can resolve to an external provider.=C2=A0 How the validation of this external token happens is implementation independent.

As I stated a few months back in an earlier email thread, I do not
think the 'audience' parameter would work for this type of external=
exchange.=C2=A0 It is just too overloaded.=C2=A0 Additionally, I think it i= s
cleaner to specify an additional parameter rather than extracting
issuer information from the 'subject_token_type'.=C2=A0 You could d= o this,
but the spec would also have to define a URI scheme for
'subject_token_type' so that issuer information could be transmitte= d.

We also added a 'requested_issuer' parameter.=C2=A0 This allows the= client
to request an external provider to obtain a token from.=C2=A0 Same reasons<= br> and rules as 'subject_token_type'.

When 'requested_issuer' flow is done, user consent is often require= d
before the request issuer can issue a token for the user.=C2=A0 When this is the case, a 400 response is returned with the following JSON
document:

{
=C2=A0 =C2=A0"error" : "....",
=C2=A0 =C2=A0"error_description" : "..."
=C2=A0 =C2=A0"account-link-url" : "https://...."
}

The error claim will be either token_expired or not_linked.=C2=A0 The
'account-link-url' claim is a link that the client can forward an u= ser
agent to to obtain consent.=C2=A0 The client simply appends a
'redirect_uri' query parameter to this link and forwards the browse= r
for consent.=C2=A0 This 'redirect_uri' must be a registered and val= id
redirect uri for the forwarding client.=C2=A0 After the redirect, the
client can then make an exchange request.=C2=A0 For error conditions, the redirect_uri may by forwarded to with an additional 'error' query parameter depending on whether the IDP deams it safe to do so.


Thanks,

Bill

[1] http://www.keycloak.= org/docs/latest/securing_apps/index.html#_token-exchange

--
Bill Burke
Red Hat

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


<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --001a11444bfa6fd680055fd7b283-- From nobody Fri Dec 8 10:32:00 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F35951289B0 for ; Fri, 8 Dec 2017 10:31:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HlHhVaL51jo1 for ; Fri, 8 Dec 2017 10:31:57 -0800 (PST) Received: from mail-ua0-x22e.google.com (mail-ua0-x22e.google.com [IPv6:2607:f8b0:400c:c08::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 03DB5127601 for ; Fri, 8 Dec 2017 10:31:57 -0800 (PST) Received: by mail-ua0-x22e.google.com with SMTP id v20so8093907uaj.0 for ; Fri, 08 Dec 2017 10:31:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9hKmyr24bKxTB1Mv8DW4kSw8jmIg8BnwWvmDxc0mkAo=; b=jwe8gxg7OE57xOoAtwQsy4e/gADMu8Mtzd7M/9jrcBE6y6Wil187LXXP/OeF9K5ssD 3V2WDO3qNqFafivq8eBPmjp2PVuCQs+3LwoRowohTcxAsjxSe4pZAdfXl7cMcbY7B0Bi JHhwwH9UHPpeKAmK9YJVTOZd/tjj9SILu3AX4Jjpn+2JQY23/Rl0rpZLHZcF36XWtNQH rDuIUKpIs8rzu7eJV6XekcO/YlJv0Da6RTG0/oIPb8QahhYi8VgsyoaeMD/Xc5KeLAx/ rSQrTb4QSY8o0uDnikDuKPQdCOxaLADFWqxL4ejrR2oD7hmB/ZgA6rRzVc4dBTodzJ0s 6t6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9hKmyr24bKxTB1Mv8DW4kSw8jmIg8BnwWvmDxc0mkAo=; b=cOIE4Ay3hYfplhQnUm55ohsxwSeORqozS6Pqn5x6m9j+fGa9TxwzbYcGWKDJ+swCj0 aU/Fs4TkLXQgicy+q0EOhvrm15dNMGdpO21slDp+3Ga4IdqnSC0Gffky0emzEyjy59QD 8BxAvbVWfbfRm32P8HqFqQ7a2FKmneelZ8F+zOfzhdpksmECcu5CvbRqR2qWdMbrVKRU 0HceYNGd8K5D9kP6FklMk4OEjSw7dfoLYXklzvZxi3DPi1feq3vFWuTntDIl6FDRppNS jZXL0J9MjyYeCITuoydLSmlMVgSmUbfUFHjodUVO/b6l7owaCfYVuJnmO3oEFgk1ctfc wFww== X-Gm-Message-State: AKGB3mIEr9bAdTeaMhB13iPYvbnzE25Y6PPCPV7alsNGPxIhmsWtLLHm pgGYjq5nG0WLKnui9hMCPltwwgL85jFSyOQPo1E= X-Google-Smtp-Source: AGs4zMZrQCZHIsgS94uFh0Uy1Xrh3BuqfdRMeIld9dcdKuoOgEXDYcdh4OvE1vcp9t5nBSJNMB7Sx8dpbY2dSQBrkPY= X-Received: by 10.176.22.82 with SMTP id l18mr18206679uae.73.1512757916028; Fri, 08 Dec 2017 10:31:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.68.133 with HTTP; Fri, 8 Dec 2017 10:31:55 -0800 (PST) In-Reply-To: References: From: Rifaat Shekh-Yusef Date: Fri, 8 Dec 2017 13:31:55 -0500 Message-ID: To: Brian Campbell Cc: Bill Burke , OAuth WG Content-Type: multipart/alternative; boundary="001a11456b30375413055fd8664c" Archived-At: Subject: Re: [OAUTH-WG] [token-exchange] Parameters to support external token exchange X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Dec 2017 18:32:00 -0000 --001a11456b30375413055fd8664c Content-Type: text/plain; charset="UTF-8" Hi Bill, I agree with Brian that an AS to AS token exchange is beyond the scope of this document. I suggest that you send a separate email to start a discussion on this topic and see if there is interest in the WG to take this topic as a new work. Regards, Rifaat (as co-chair and document shepherd) On Fri, Dec 8, 2017 at 12:41 PM, Brian Campbell wrote: > I guess I'm going to kind of restate some of what I said in that earlier > thread > > and a bit more. The access and refresh token URIs from the draft are > intended to indicate that such tokens are issued by the given authorization > server acting as the STS (perhaps this could be stated more clearly in the > doc). As such, there isn't direct explicit support for OAuth access token > to OAuth access token cross-domain type exchanges. That was intentional and > I think is appropriate as I don't believe this draft should delve into > pseudo federating access tokens and all the additional complexity and > security implications that entails. The assertion based authorization > grants (RFCs 7523 & 7522 > ) are intended to facilitate > acquiring an access token from an external or cross-domain AS and I prefer > that more explicit model for cross-domain than codifying a rather implicit > way of doing it in token exchange. A Facebook access token, for example, is > issued to a client for delegated access to Facebook APIs. It isn't for > delegated access to some other domain's APIs but an access token for access > token exchange effectively turns it into that. And in some situations that > can have problematic security implications. Big providers like Facebook > have a lot of apps (OAuth clients) that can get access tokens. An > organization might well be okay with an app it controls exchanging a > Facebook access token for an access token for its own APIs. But a 3rd party > Facebook app (like maybe a new viral rate my '80's hairdo app) doing the > same thing could be very problematic. It's not exactly the same thing but > many of the same potential issues arise as when using OAuth for User > Authentication . > Standardization around access token for access token exchange would, at a > minimum, need some real security analysis and recommendations/considerations. > > > The token exchange draft went thought WGLC some time ago and is currently > being written up by the document shepherd to send to the AD. It's close. > It's been a long time coming and I'd really object to derailing it by > making big additions to it at this late stage in the process. > > If explicit support for directly swapping an access token from one AS for > an access token issued by a different AS is something this WG is interested > in working on, while admittedly I have my hesitations, I propose/suggest > that it be done in a new document. Such a document could but wouldn't > necessarily have to take the from of the additional extension parameters > you've mentioned. It could, for example, be a 'token profile' of sorts that > defines a new URI with an associated format that is some simple structure > that carries both the access token and issuer together. Something like > "urn:ietf:params:oauth:token-type:wrapped_foreign_access_token" and > {"issuer":"https://api.login.yahoo.com","token":"bwcK0esc3AC > C3DB2Y5_lESsXE8o9ltc05O89jdN-dg2"} - that's just spitballing but > hopefully conveys the idea. The new document would also have to cover the > security considerations. > > > > > On Wed, Dec 6, 2017 at 2:31 PM, Bill Burke wrote: > >> The Keycloak project (oss idp), has implemented [1] the token exchange >> draft (minus the actor token). There's a couple of extensions we have >> made to allow external token exchange to work. I'd like to get some >> consideration for these extensions to be added. With proper >> configurations, clients are able to exchange between different domains >> and even social providers. i.e. you can exchange a Facebook token for >> a token issued by the IDP. >> >> Here are the details: >> >> We added a 'subject_issuer' parameter. Many OAuth IDPs have opaque >> access tokens and do not use JWTs for their access token (i.e. >> Facebook and Google). If the 'subject_token_type' is >> 'urn:ietf:params:oauth:token-type:access_token' and the access token >> comes from an external provider, then the client must also pass a >> 'subject_issuer'. The parameter value is something, anything that can >> the IDP can resolve to an external provider. How the validation of >> this external token happens is implementation independent. >> >> As I stated a few months back in an earlier email thread, I do not >> think the 'audience' parameter would work for this type of external >> exchange. It is just too overloaded. Additionally, I think it is >> cleaner to specify an additional parameter rather than extracting >> issuer information from the 'subject_token_type'. You could do this, >> but the spec would also have to define a URI scheme for >> 'subject_token_type' so that issuer information could be transmitted. >> >> We also added a 'requested_issuer' parameter. This allows the client >> to request an external provider to obtain a token from. Same reasons >> and rules as 'subject_token_type'. >> >> When 'requested_issuer' flow is done, user consent is often required >> before the request issuer can issue a token for the user. When this >> is the case, a 400 response is returned with the following JSON >> document: >> >> { >> "error" : "....", >> "error_description" : "..." >> "account-link-url" : "https://...." >> } >> >> The error claim will be either token_expired or not_linked. The >> 'account-link-url' claim is a link that the client can forward an user >> agent to to obtain consent. The client simply appends a >> 'redirect_uri' query parameter to this link and forwards the browser >> for consent. This 'redirect_uri' must be a registered and valid >> redirect uri for the forwarding client. After the redirect, the >> client can then make an exchange request. For error conditions, the >> redirect_uri may by forwarded to with an additional 'error' query >> parameter depending on whether the IDP deams it safe to do so. >> >> >> Thanks, >> >> Bill >> >> [1] http://www.keycloak.org/docs/latest/securing_apps/index.html >> #_token-exchange >> >> -- >> Bill Burke >> Red Hat >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited. > If you have received this communication in error, please notify the sender > immediately by e-mail and delete the message and any file attachments from > your computer. Thank you.* > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --001a11456b30375413055fd8664c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Bill,

I agree with Brian that an AS = to AS token exchange is beyond the scope of this document.
I sugg= est that you send a separate email to start a discussion on this topic and = see if there is interest in the WG to take this topic as a new work.
<= div>
Regards,
=C2=A0Rifaat (as co-chair and documen= t shepherd)

On Fri, Dec 8, 2017 at 12:41 PM, Brian Campbell <= ;bcampbell@= pingidentity.com> wrote:
I guess I'm going to kind of restate some of what I= said in that earlier thread and a bit more. The access and refresh token URIs = from the draft are intended to indicate that such tokens are issued by the = given authorization server acting as the STS (perhaps this could be stated = more clearly in the doc). As such, there isn't direct explicit support = for OAuth access token to OAuth access token cross-domain type exchanges. T= hat was intentional and I think is appropriate as I don't believe this = draft should delve into pseudo federating access tokens and all the additio= nal complexity and security implications that entails. The assertion based = authorization grants (RFCs 7523 & 7522) are intended to facilitate acquiring an a= ccess token from an external or cross-domain AS and I prefer that more expl= icit model for cross-domain than codifying a rather implicit way of doing i= t in token exchange. A Facebook access token, for example, is issued to a c= lient for delegated access to Facebook APIs. It isn't for delegated acc= ess to some other domain's APIs but an access token for access token ex= change effectively turns it into that. And in some situations that can have= problematic security implications. Big providers like Facebook have a lot = of apps (OAuth clients) that can get access tokens. An organization might w= ell be okay with an app it controls exchanging a Facebook access token for = an access token for its own APIs. But a 3rd party Facebook app (like maybe = a new viral rate my '80's hairdo app) doing the same thing could be= very problematic. It's not exactly the same thing but many of the same= potential issues arise as when using OAuth for User Authentication. Stan= dardization around access token for access token exchange would, at a minim= um, need some real security analysis and recommendations/considerations.

The token exchange draft went thought WGLC= some time ago and is currently being written up by the document shepherd to send to the AD. = It's close. It's been a long time coming and I'd really object = to derailing it by making big additions to it at this late stage in the pro= cess.

If explicit support for directly swapp= ing an access token from one AS for an access token issued by a different AS is so= mething this WG is interested in working on, while admittedly I have my hes= itations, I propose/suggest that it be done in a new document. Such a docum= ent could but wouldn't necessarily have to take the from of the additio= nal extension parameters you've mentioned. It could, for example, be a = 'token profile' of sorts that defines a new URI with an associated = format that is some simple structure that carries both the access token and= issuer together. Something like "urn:ietf:params:oauth:token-typ= e:wrapped_foreign_access_token" and {"issuer":"https://api.login.y<= wbr>ahoo.com","token":"bwcK0esc3ACC3DB2Y5_lESs= XE8o9ltc05O89jdN-dg2"} - that's just spitballing but hopefull= y conveys the idea. The new document would also have to cover the security = considerations.




On Wed, Dec 6, 2017 at 2:31 PM, Bill Burke <bburke@redh= at.com> wrote:
The Keycloak= project (oss idp), has implemented [1] the token exchange
draft (minus the actor token).=C2=A0 There's a couple of extensions we = have
made to allow external token exchange to work.=C2=A0 I'd like to get so= me
consideration for these extensions to be added.=C2=A0 With proper
configurations, clients are able to exchange between different domains
and even social providers.=C2=A0 i.e. you can exchange a Facebook token for=
a token issued by the IDP.

Here are the details:

We added a 'subject_issuer' parameter.=C2=A0 Many OAuth IDPs have o= paque
access tokens and do not use JWTs for their access token (i.e.
Facebook and Google).=C2=A0 If the 'subject_token_type' is
'urn:ietf:params:oauth:token-type:access_token' and the access= token
comes from an external provider, then the client must also pass a
'subject_issuer'.=C2=A0 The parameter value is something, anything = that can
the IDP can resolve to an external provider.=C2=A0 How the validation of this external token happens is implementation independent.

As I stated a few months back in an earlier email thread, I do not
think the 'audience' parameter would work for this type of external=
exchange.=C2=A0 It is just too overloaded.=C2=A0 Additionally, I think it i= s
cleaner to specify an additional parameter rather than extracting
issuer information from the 'subject_token_type'.=C2=A0 You could d= o this,
but the spec would also have to define a URI scheme for
'subject_token_type' so that issuer information could be transmitte= d.

We also added a 'requested_issuer' parameter.=C2=A0 This allows the= client
to request an external provider to obtain a token from.=C2=A0 Same reasons<= br> and rules as 'subject_token_type'.

When 'requested_issuer' flow is done, user consent is often require= d
before the request issuer can issue a token for the user.=C2=A0 When this is the case, a 400 response is returned with the following JSON
document:

{
=C2=A0 =C2=A0"error" : "....",
=C2=A0 =C2=A0"error_description" : "..."
=C2=A0 =C2=A0"account-link-url" : "https://...."
}

The error claim will be either token_expired or not_linked.=C2=A0 The
'account-link-url' claim is a link that the client can forward an u= ser
agent to to obtain consent.=C2=A0 The client simply appends a
'redirect_uri' query parameter to this link and forwards the browse= r
for consent.=C2=A0 This 'redirect_uri' must be a registered and val= id
redirect uri for the forwarding client.=C2=A0 After the redirect, the
client can then make an exchange request.=C2=A0 For error conditions, the redirect_uri may by forwarded to with an additional 'error' query parameter depending on whether the IDP deams it safe to do so.


Thanks,

Bill

[1] http://www.keycloak.= org/docs/latest/securing_apps/index.html#_token-exchange

--
Bill Burke
Red Hat

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


CONFIDENTIALITY NOTICE: This email may contai= n confidential and privileged material for the sole use of the intended rec= ipient(s). Any review, use, distribution or disclosure by others is strictl= y prohibited.=C2=A0 If you have received this communication in error, pleas= e notify the sender immediately by e-mail and delete the message and any fi= le attachments from your computer. Thank you.
________= _______________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


--001a11456b30375413055fd8664c-- From nobody Fri Dec 8 11:42:29 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FA73126579 for ; Fri, 8 Dec 2017 11:42:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ivJTd6K_q0PD for ; Fri, 8 Dec 2017 11:42:27 -0800 (PST) Received: from p3plsmtpa08-09.prod.phx3.secureserver.net (p3plsmtpa08-09.prod.phx3.secureserver.net [173.201.193.110]) (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 E9BF512871F for ; Fri, 8 Dec 2017 11:42:26 -0800 (PST) Received: from [192.168.0.107] ([78.130.190.73]) by :SMTPAUTH: with SMTP id NOXReofFj82OANOXRevo7n; Fri, 08 Dec 2017 12:42:26 -0700 To: oauth@ietf.org References: From: Vladimir Dzhuvinov Organization: Connect2id Ltd. Message-ID: <4e14a1ec-8b6d-476b-3949-8a0b63017232@connect2id.com> Date: Fri, 8 Dec 2017 21:42:24 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms010400020101070501010906" X-CMAE-Envelope: MS4wfKfucZFYTF61vGnoMWwepoFIaJ/ZDUUWJwaq572ID+GzWleQNCYxpf7lPClqf6p/+3iQQVMBLeOetZgl/3weRuYpee/habvnVTyjajpwkL6NaiqkVLQ3 dRw88bm2hVAPmKStzpGmfhkaPqvWf/TmEqiA2Pu6MmG8boYix/ZgHRNh Archived-At: Subject: Re: [OAUTH-WG] WGLC for OAuth 2.0 Device Flow for Browserless and Input Constrained Devices X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Dec 2017 19:42:28 -0000 This is a cryptographically signed message in MIME format. --------------ms010400020101070501010906 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi, I just got a question on Twitter about the slow_down error: https://tools.ietf.org/html/draft-ietf-oauth-device-flow-07#section-3.5 The question was why slow_down is communicated via HTTP status code 400 and not 429 (Too Many Requests). Thanks, Vladimir On 27/11/17 15:55, Rifaat Shekh-Yusef wrote: > All, > > As discussed in Singapore, we are starting a WGLC for the > *draft-ietf-oauth-device-flow-07* document, starting today and ending o= n > December 11, 2018. > https://datatracker.ietf.org/doc/draft-ietf-oauth-device-flow/ > > Please, review the document and provide feedback on the list. > > Regards, > Rifaat & Hannes --------------ms010400020101070501010906 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+5swggVFMIIELaADAgECAhAlSsBX16i/yGZZkfkyj/exMA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTcwNDA2MDAwMDAwWhcNMTgwNDA2MjM1OTU5WjAoMSYwJAYJKoZIhvcNAQkB Fhd2bGFkaW1pckBjb25uZWN0MmlkLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAMHntIxpX2yNwHUcSrxfJihY9EtYTwC4VArv/C03YlEV92AQljLFYVKtRp+iKT8WDKo2 CqzPYaIHbKD0ivoou0qXQgv4yOk8rQxFmpTzCCe2c1KercueHfy595CnMz1u8GsQyblZqFMD HmzoEvD1YZiI3FEh049tVixBnHwPD9fyiGlf8+QdjwmBLMQwdrrib7xcswNXKYIsfj6Qm5oa d83bsz8VmYm5U39DbNPh01SzqAzwZt3jMuhy0su7lMs75lKYzWMA7b/9qrp40E3vR0yDvOn5 7Ijs+LFE2wPDTebVVfYT+m24e5/v/2w6sX5g/6oJsZnwPM737zIXV7x6jqECAwEAAaOCAfUw ggHxMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBQA+4E14UMY HyjzXHClSV9VfWHpPzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0w OwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5u ZXQvQ1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9E T1NIQTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsG AQUFBwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01P RE9TSEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsG AQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wIgYDVR0RBBswGYEXdmxhZGltaXJA Y29ubmVjdDJpZC5jb20wDQYJKoZIhvcNAQELBQADggEBACYLv9z6ZOucvt5MlRhNY6SJISDN 880UmdH7IdeP2kJjS3GwuVaVUCQY/frypeIm3A+y0fKEVNJAJO7tfL88yOW4wjA9JMGokpy5 RswZ0uikkNSOt6CF3YGagsfr4VnrcoUxCH+FoGZcWvWYHajJy+QkVG2i6XvsTE7jv1PIsoDU SJuCW+Dvg6iJI9Etpfv1ZrBeDEL05PkPBZfazKMj4MkVirkfbG3qgbzRzAb+7Vsm309NKQ+i EUfoxt83ByC6+URLl3PoR2UTZv7M1JQmTtaQWe1LrAEKlBGHkfnSlxueLnmpCUJRS7Ldyfh5 60OdVFcB5twXPnYWtoZfdTlbv5oxggRBMIIEPQIBATCBsDCBmzELMAkGA1UEBhMCR0IxGzAZ BgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRo ZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAlSsBX16i/yGZZkfkyj/exMA0GCWCG SAFlAwQCAQUAoIICYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNzEyMDgxOTQyMjRaMC8GCSqGSIb3DQEJBDEiBCBiiU0qIneE6FosrVlxiLCbVIUpTnVP zhW9akfznEKERzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIw CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G CCqGSIb3DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQJUrAV9eov8hmWZH5Mo/3sTCBwwYLKoZI hvcNAQkQAgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEw PwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3Vy ZSBFbWFpbCBDQQIQJUrAV9eov8hmWZH5Mo/3sTANBgkqhkiG9w0BAQEFAASCAQBCBbFQ4NjM VqsDOkh7FGRvjghYxSVDH8sawYn8iOk7K0lawHkcNrr3ATQ6VqnsQ4110oTqhB+7Ksz3ajs7 XGF0J3qbhqRnNIOSvLUcgbwobnJOICLWYpcSzgwIUZxtVYXBofn+EM/g3ll41fyhHVCEYnQT PQC9PW5RtrX6hSZYiMHPDpOe0X2MlYUWWLtBV1/N+mU58oXxCdgeziA6PQTt6fZbbpmuoK69 iOwqaKhFAJpkEvRm9MvjG1A6BN4Ft3syCKAwARUNbNUtBl9P7Hw21X+BCQ0+WtJXoj2ZXk8d ER3fPiAMft21QArv855fBjNF0vadpioEebCj+XTykSegAAAAAAAA --------------ms010400020101070501010906-- From nobody Fri Dec 8 12:06:02 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BCCD128D2E for ; Fri, 8 Dec 2017 12:06:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IUoJB63hUlnu for ; Fri, 8 Dec 2017 12:05:57 -0800 (PST) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0113.outbound.protection.outlook.com [104.47.36.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2467E127076 for ; Fri, 8 Dec 2017 12:05:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=vmkEpeiFEZvrwjKkWW9G21+3UlBVCakHvVUfB1bIJDs=; b=nzps4UpviJsNK4ePrBARTL8jdZIRS0Yz4K5MdBZqIJXtkkXnE33vvvxzkeaT8kKlpr84oPquXw12QG0hwewT+hhOpN85Fjy0paNu2jRSkdX/TmAA58IO0LJvZ8G5fc43RYIEtCENuXld5d0JnOWwC8QwhY2BGWqP8/un5JSHW30= Received: from CY4PR21MB0504.namprd21.prod.outlook.com (10.172.122.14) by CY4PR21MB0181.namprd21.prod.outlook.com (10.173.193.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.323.0; Fri, 8 Dec 2017 20:05:55 +0000 Received: from CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) by CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) with mapi id 15.20.0323.001; Fri, 8 Dec 2017 20:05:55 +0000 From: Mike Jones To: Brian Campbell , Rifaat Shekh-Yusef CC: OAuth WG Thread-Topic: [OAUTH-WG] [token-exchange] Parameters to support external token exchange Thread-Index: AQHTbtmWBn8npBvFe0mAu+QoTNk9vaM5ucOAgAAOL4CAABpD6Q== Date: Fri, 8 Dec 2017 20:05:55 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [104.208.33.187] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0181; 6:xe7KZiMz9aqVewNXYwlX0Zv1YlbahdilWY671zIqRveI9HkOh8NpTMK5bILIsTxOSIptBTHux6dAIpv+pjk6mxEM5gHOB5jIUM+WMhOmtGRgYJ3VBJxOual93rfKGAo0OyMioZY+e1r3iLAOVf790ABLw/hYzp1dryfHz/PCcWCw8LK+uxUBwr+A6WWZO2Ta703wLLMM9qBb0bJV5K4iqsz9PBecQotzVphakkgrlwGPCFZ3eo1C6a/cq9cieVC7OL2LMeYOcwnEsr+pcDktt/juVY9SQ6/o3tpAUU/GUWc6d71z1ClA85vNCj10VHRTovcj9kuS/bIYiEHKnOIWhfgiHqeHPV0y3naZNqgiB50=; 5:2L+yHL4oN1fFSD5K9oi6rOxYifld4QvB88Ceylz6pH+ADca2XC17SmeRSgsBjj42iz/cT/ubRq+cDKY9cYVoMJ0lchcRnzgYFEy25zC7SyE54WC3IkDMhdJuq9ZmN51AmxVcf/3j8wBPrCc15fCjxdXZKoUhzIfyv96EdX68jLo=; 24:oOPSpEKo04PX+kvIKw6hw0fDKjnSINYzoMmflINL3uG1TfkwNfEJJ0otJyxkMV9/svJQ/X4I1emqQMr4Mi/FfFZvejVAIdYUkvxPO0sY/vE=; 7:aWYv0w/Me+MQPNI5zsJGLrOnQaaBvLFXFqcREFAP0w630N0zBznMimw33BfUOv+OEYWi5JkKN1O8lV1UFm9Tvim/0eLdTqiPm3KVfaZycRIozp3I7QTi++v+RhOnOyeJBm1X9KU0dxEvfkY/KA6+8aO0Jo56MqjBx9egSyW3rJpLOpDzyCpYt58RZJO0ROcclkkjgK5X+ai4p3dQa4jA64JH06qoHknIvokfovUW5aakrCA2YFVDPp4bfNUPncAB x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 928c9bc6-cd07-4756-252f-08d53e77175d x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(2017052603307); SRVR:CY4PR21MB0181; x-ms-traffictypediagnostic: CY4PR21MB0181: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(192374486261705)(277287716339344)(81227570615382)(201166117486090); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040450)(2401047)(5005006)(8121501046)(3231022)(10201501046)(3002001)(93006095)(93001095)(6055026)(61426038)(61427038)(6041248)(20161123560025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123558100)(20161123555025)(6072148)(201708071742011); SRVR:CY4PR21MB0181; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:CY4PR21MB0181; x-forefront-prvs: 0515208626 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(346002)(39860400002)(376002)(24454002)(11905935001)(36304003)(199004)(189003)(99286004)(14454004)(575784001)(105586002)(10290500003)(6246003)(347745004)(10090500001)(966005)(25786009)(16297215004)(19273905006)(7696005)(68736007)(4326008)(3660700001)(316002)(39060400002)(22452003)(110136005)(106356001)(3280700002)(33656002)(97736004)(2906002)(72206003)(76176011)(8936002)(478600001)(86362001)(8676002)(6306002)(5660300001)(54896002)(74316002)(6116002)(9686003)(8990500004)(2950100002)(5890100001)(3846002)(86612001)(102836003)(53936002)(81166006)(606006)(7736002)(81156014)(6506006)(229853002)(77096006)(53546010)(6436002)(66066001)(2900100001)(55016002)(236005); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0181; H:CY4PR21MB0504.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB0504591CF62D9F73A92C9E31F5300CY4PR21MB0504namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 928c9bc6-cd07-4756-252f-08d53e77175d X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Dec 2017 20:05:55.5397 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0181 Archived-At: Subject: Re: [OAUTH-WG] [token-exchange] Parameters to support external token exchange X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Dec 2017 20:06:00 -0000 --_000_CY4PR21MB0504591CF62D9F73A92C9E31F5300CY4PR21MB0504namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I also agree that this additional functionality is out of scope for the Tok= en Exchange specification. -- Mike ________________________________ From: OAuth on behalf of Rifaat Shekh-Yusef Sent: Friday, December 8, 2017 1:31:55 PM To: Brian Campbell Cc: OAuth WG Subject: Re: [OAUTH-WG] [token-exchange] Parameters to support external tok= en exchange Hi Bill, I agree with Brian that an AS to AS token exchange is beyond the scope of t= his document. I suggest that you send a separate email to start a discussion on this topi= c and see if there is interest in the WG to take this topic as a new work. Regards, Rifaat (as co-chair and document shepherd) On Fri, Dec 8, 2017 at 12:41 PM, Brian Campbell > wrote: I guess I'm going to kind of restate some of what I said in that earlier th= read and a bit more. The access and r= efresh token URIs from the draft are intended to indicate that such tokens = are issued by the given authorization server acting as the STS (perhaps thi= s could be stated more clearly in the doc). As such, there isn't direct exp= licit support for OAuth access token to OAuth access token cross-domain typ= e exchanges. That was intentional and I think is appropriate as I don't bel= ieve this draft should delve into pseudo federating access tokens and all t= he additional complexity and security implications that entails. The assert= ion based authorization grants (RFCs 7523 & 7522) are intended to facilitate= acquiring an access token from an external or cross-domain AS and I prefer= that more explicit model for cross-domain than codifying a rather implicit= way of doing it in token exchange. A Facebook access token, for example, i= s issued to a client for delegated access to Facebook APIs. It isn't for de= legated access to some other domain's APIs but an access token for access t= oken exchange effectively turns it into that. And in some situations that c= an have problematic security implications. Big providers like Facebook have= a lot of apps (OAuth clients) that can get access tokens. An organization = might well be okay with an app it controls exchanging a Facebook access tok= en for an access token for its own APIs. But a 3rd party Facebook app (like= maybe a new viral rate my '80's hairdo app) doing the same thing could be = very problematic. It's not exactly the same thing but many of the same pote= ntial issues arise as when using OAuth for User Authentication. Standardization around access token for ac= cess token exchange would, at a minimum, need some real security analysis a= nd recommendations/considerations. The token exchange draft went thought WGLC some time ago and is currently b= eing written up by the document shepherd to send to the AD. It's close. It'= s been a long time coming and I'd really object to derailing it by making b= ig additions to it at this late stage in the process. If explicit support for directly swapping an access token from one AS for a= n access token issued by a different AS is something this WG is interested = in working on, while admittedly I have my hesitations, I propose/suggest th= at it be done in a new document. Such a document could but wouldn't necessa= rily have to take the from of the additional extension parameters you've me= ntioned. It could, for example, be a 'token profile' of sorts that defines = a new URI with an associated format that is some simple structure that carr= ies both the access token and issuer together. Something like "urn:ietf:par= ams:oauth:token-type:wrapped_foreign_access_token" and {"issuer":"https://a= pi.login.yahoo.com","token":"bwcK0esc3ACC3DB2Y5_lESsXE8o9ltc05O89jdN-dg2"} = - that's just spitballing but hopefully conveys the idea. The new document = would also have to cover the security considerations. On Wed, Dec 6, 2017 at 2:31 PM, Bill Burke > wrote: The Keycloak project (oss idp), has implemented [1] the token exchange draft (minus the actor token). There's a couple of extensions we have made to allow external token exchange to work. I'd like to get some consideration for these extensions to be added. With proper configurations, clients are able to exchange between different domains and even social providers. i.e. you can exchange a Facebook token for a token issued by the IDP. Here are the details: We added a 'subject_issuer' parameter. Many OAuth IDPs have opaque access tokens and do not use JWTs for their access token (i.e. Facebook and Google). If the 'subject_token_type' is 'urn:ietf:params:oauth:token-type:access_token' and the access token comes from an external provider, then the client must also pass a 'subject_issuer'. The parameter value is something, anything that can the IDP can resolve to an external provider. How the validation of this external token happens is implementation independent. As I stated a few months back in an earlier email thread, I do not think the 'audience' parameter would work for this type of external exchange. It is just too overloaded. Additionally, I think it is cleaner to specify an additional parameter rather than extracting issuer information from the 'subject_token_type'. You could do this, but the spec would also have to define a URI scheme for 'subject_token_type' so that issuer information could be transmitted. We also added a 'requested_issuer' parameter. This allows the client to request an external provider to obtain a token from. Same reasons and rules as 'subject_token_type'. When 'requested_issuer' flow is done, user consent is often required before the request issuer can issue a token for the user. When this is the case, a 400 response is returned with the following JSON document: { "error" : "....", "error_description" : "..." "account-link-url" : "https://...." } The error claim will be either token_expired or not_linked. The 'account-link-url' claim is a link that the client can forward an user agent to to obtain consent. The client simply appends a 'redirect_uri' query parameter to this link and forwards the browser for consent. This 'redirect_uri' must be a registered and valid redirect uri for the forwarding client. After the redirect, the client can then make an exchange request. For error conditions, the redirect_uri may by forwarded to with an additional 'error' query parameter depending on whether the IDP deams it safe to do so. Thanks, Bill [1] http://www.keycloak.org/docs/latest/securing_apps/index.html#_token-exc= hange -- Bill Burke Red Hat _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth CONFIDENTIALITY NOTICE: This email may contain confidential and privileged = material for the sole use of the intended recipient(s). Any review, use, di= stribution or disclosure by others is strictly prohibited. If you have rec= eived this communication in error, please notify the sender immediately by = e-mail and delete the message and any file attachments from your computer. = Thank you. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_CY4PR21MB0504591CF62D9F73A92C9E31F5300CY4PR21MB0504namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I also agree that this additional functionality is out of scope for the Tok= en Exchange specification.

-- Mike
From: OAuth <oauth-bounc= es@ietf.org> on behalf of Rifaat Shekh-Yusef <rifaat.ietf@gmail.com&g= t;
Sent: Friday, December 8, 2017 1:31:55 PM
To: Brian Campbell
Cc: OAuth WG
Subject: Re: [OAUTH-WG] [token-exchange] Parameters to support exter= nal token exchange
 
Hi Bill,

I agree with Brian that an AS to AS token exchange is beyond the scope= of this document.
I suggest that you send a separate email to start a discussion on this= topic and see if there is interest in the WG to take this topic as a new w= ork.

Regards,
 Rifaat (as co-chair and document shepherd)

On Fri, Dec 8, 2017 at 12:41 PM, Brian Campbell = <bcampbe= ll@pingidentity.com> wrote:
I guess I'm going to kind of restate some of what I said in that earlier thread and a bit more. The access and refresh token URIs f= rom the draft are intended to indicate that such tokens are issued by the g= iven authorization server acting as the STS (perhaps this could be stated m= ore clearly in the doc). As such, there isn't direct explicit support for OAuth access token to OAuth access= token cross-domain type exchanges. That was intentional and I think is app= ropriate as I don't believe this draft should delve into pseudo federating = access tokens and all the additional complexity and security implications that entails. The assertion based aut= horization grants (RFCs 7523 = & 7522) are intended to facilitate acquiring an access token from an exte= rnal or cross-domain AS and I prefer that more explicit model for cross-dom= ain than codifying a rather implicit way of doing it in token exchange. A F= acebook access token, for example, is issued to a client for delegated access to Facebook APIs. It isn't for = delegated access to some other domain's APIs but an access token for access= token exchange effectively turns it into that. And in some situations that= can have problematic security implications. Big providers like Facebook have a lot of apps (OAuth clients) that can ge= t access tokens. An organization might well be okay with an app it controls= exchanging a Facebook access token for an access token for its own APIs. B= ut a 3rd party Facebook app (like maybe a new viral rate my '80's hairdo app) doing the same thing could be = very problematic. It's not exactly the same thing but many of the same pote= ntial issues arise as when using OA= uth for User Authentication. Standardization around access token for ac= cess token exchange would, at a minimum, need some real security analysis a= nd recommendations/considerations.

The token exchange draft went thought WGLC some time ago and is curren= tly being written up by the document shepherd to send to the AD. It's close= . It's been a long time coming and I'd really object to derailing it by mak= ing big additions to it at this late stage in the process.

If explicit support for directly swapping an access token from one AS = for an access token issued by a different AS is something this WG is intere= sted in working on, while admittedly I have my hesitations, I propose/sugge= st that it be done in a new document. Such a document could but wouldn't necessarily have to take the from of th= e additional extension parameters you've mentioned. It could, for example, = be a 'token profile' of sorts that defines a new URI with an associated for= mat that is some simple structure that carries both the access token and issuer together. Something like &qu= ot;urn:ietf:params:oauth:token-type:wrapped_foreign_access_token&= quot; and {"issuer":"https://api.login.yahoo.com","token&q= uot;:"bwcK0esc3ACC3DB2Y5_lESsXE8o9ltc05O89jdN-dg2"} - that's just spitballing but hopefully conveys the idea. The new document= would also have to cover the security considerations.




On Wed, Dec 6, 2017 at 2:31 PM, Bill Burke <bburke@redhat.co= m> wrote:
The Keycloak project (oss idp), has implemented [1] the token exchange
draft (minus the actor token).  There's a couple of extensions we have=
made to allow external token exchange to work.  I'd like to get some consideration for these extensions to be added.  With proper
configurations, clients are able to exchange between different domains
and even social providers.  i.e. you can exchange a Facebook token for=
a token issued by the IDP.

Here are the details:

We added a 'subject_issuer' parameter.  Many OAuth IDPs have opaque access tokens and do not use JWTs for their access token (i.e.
Facebook and Google).  If the 'subject_token_type' is
'urn:ietf:params:oauth:token-type:access_token' and the access token comes from an external provider, then the client must also pass a
'subject_issuer'.  The parameter value is something, anything that can=
the IDP can resolve to an external provider.  How the validation of this external token happens is implementation independent.

As I stated a few months back in an earlier email thread, I do not
think the 'audience' parameter would work for this type of external
exchange.  It is just too overloaded.  Additionally, I think it i= s
cleaner to specify an additional parameter rather than extracting
issuer information from the 'subject_token_type'.  You could do this,<= br> but the spec would also have to define a URI scheme for
'subject_token_type' so that issuer information could be transmitted.

We also added a 'requested_issuer' parameter.  This allows the client<= br> to request an external provider to obtain a token from.  Same reasons<= br> and rules as 'subject_token_type'.

When 'requested_issuer' flow is done, user consent is often required
before the request issuer can issue a token for the user.  When this is the case, a 400 response is returned with the following JSON
document:

{
   "error" : "....",
   "error_description" : "..."
   "account-link-url" : "https://...."
}

The error claim will be either token_expired or not_linked.  The
'account-link-url' claim is a link that the client can forward an user
agent to to obtain consent.  The client simply appends a
'redirect_uri' query parameter to this link and forwards the browser
for consent.  This 'redirect_uri' must be a registered and valid
redirect uri for the forwarding client.  After the redirect, the
client can then make an exchange request.  For error conditions, the redirect_uri may by forwarded to with an additional 'error' query
parameter depending on whether the IDP deams it safe to do so.


Thanks,

Bill

[1] http://www.keycloak.org/docs/latest/securing_apps/index.html#_tok= en-exchange

--
Bill Burke
Red Hat

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


CONFIDENTIALI= TY NOTICE: This email may contain confidential and privileged material for th= e sole use of the intended recipient(s). Any review, use, distribution or d= isclosure by others is strictly prohibited.  If you have received this= communication in error, please notify the sender immediately by e-mail and delete the message and any file attac= hments from your computer. Thank you.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


--_000_CY4PR21MB0504591CF62D9F73A92C9E31F5300CY4PR21MB0504namp_-- From nobody Fri Dec 8 12:48:08 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20104128656 for ; Fri, 8 Dec 2017 12:48:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.719 X-Spam-Level: X-Spam-Status: No, score=-1.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fVxL--3lawTl for ; Fri, 8 Dec 2017 12:48:04 -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 61D80127241 for ; Fri, 8 Dec 2017 12:48:04 -0800 (PST) Received: by mail-io0-x22d.google.com with SMTP id s37so3678995ioe.10 for ; Fri, 08 Dec 2017 12:48:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=R7wjuzfwfBSxz2QgHWDnmbLSa9fK3ZCQiQuGF4tnnfI=; b=pkZILknah4ExFRH/3bAI8fuvn7N2HGGwh4cr/LpTAL05tXA3OWZFFIXRpugyRUa6+w EUTJOCxpVtvB+2LmoO/Aooz0N2khlKLMbIqVivKW1/b+L537E86S3dORjQaUD2ILvnT+ tYt7rU4AgpoyHNmX4I/ZCbyjeKLikiAGvMD6s= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=R7wjuzfwfBSxz2QgHWDnmbLSa9fK3ZCQiQuGF4tnnfI=; b=DKemQkTPPWpBAgWcpgAbMLSBWKJ03F8PJj3vDM2WkTFKdjF/PcJJ4FVSEw/nX08mH1 LHaj0jrKhcHkNP8dSOuiEI7DkQqruO810y8Q6S8lkrV5CdVaMi7qK3eQNpnfbU4MgCJX Uildfccey+cxCjLI1fQI9y1hg1W7KZC9QsRTEoORU5rt1kBz7Wv9SeUuD9cjMqAkT36r gMX1pCz6b0FSJm9/QNIgZsrD+TAdEpYlShboO3HTbotxggfMnGcevIkbg6kLBWZHwfgq nlmEdXh8KicYPtJQXdlvOk9d4wkWIox6rgfoYG/Fc0lUvPN67rB4VTmdTaahE6nK1H0F qrAg== X-Gm-Message-State: AKGB3mJC0xY/lwWjNh8wxg9qjYtXFjNtKNsO/R9ZO5bhn4090v3yfM0A 1qqe6YVnscSnJhM1pHv92b6bUvhLW0VXXmfPymBRZeLj87gQ6tbciwPWUACJNb2PILn9OBaXkBd SuWOltRAKg/q1Yw== X-Google-Smtp-Source: AGs4zMaJ2P21mzZGcj/3SG4FkpLpxSg43/x9bbIitIKPyhNfrBynrm9gA/NAjLMsY1yRYUO9NUX/NL2B4jSy3iEbVV4= X-Received: by 10.107.139.196 with SMTP id n187mr39398465iod.54.1512766083184; Fri, 08 Dec 2017 12:48:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.2.118.194 with HTTP; Fri, 8 Dec 2017 12:47:32 -0800 (PST) In-Reply-To: References: <151208615408.11802.12175452260900272912@ietfa.amsl.com> From: Brian Campbell Date: Fri, 8 Dec 2017 13:47:32 -0700 Message-ID: To: Denis Cc: oauth Content-Type: multipart/alternative; boundary="94eb2c05be5a045b9a055fda4dec" Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchange-10.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Dec 2017 20:48:07 -0000 --94eb2c05be5a045b9a055fda4dec Content-Type: text/plain; charset="UTF-8" As an individual, I do not believe that the proposed text should be incorporated into the draft. As one of the document editors, my responsibility is for the document to be of reasonable quality and to reflect the rough consensus of this Working Group. So I should ask the list more explicitly - are there other WG remembers who are in favor of the proposed text here (the text would have to be fixed up some too)? On Fri, Dec 1, 2017 at 11:12 AM, Denis wrote: > Comments on draft-ietf-oauth-token-exchange-10 > > I propose the following rephrasing for sections 6 and 7: > > 6 . Security Considerations > > All of the normal security issues that are discussed in [JWT],especially > in relationship to comparing URIs > and dealing with unrecognized values, also apply here. In addition, both > delegation and impersonation introduce > unique security issues. Any time one user receives a token, the potential > for abuse is a concern, > since that user might be willing to collude with another user so that > other user could use the token. > > Techniques like the binding of an access token to a TLS channel described > elsewhere are ineffective since > the legitimate user would be able to perform all the cryptographic > computations that the other user would need > to demonstrate the ownership of the token. The use of the "scp" claim is > suggested to mitigate potential for > such abuse, as it restricts the contexts in which the token can be > exercised. If the issued access token scope > allows to unambiguously identify the user, then that user is likely to be > reluctant to collude with another user. > However, if the issued access token scope only indicates that the user is > over 18, then there is no risk > for the original user to be discovered and in such a context a collusion > may easily take place. > This document does not specify techniques to prevent such a collusion to > be successful. > > 7 . Privacy Considerations > > Tokens typically carry personal information and their usage in Token > Exchange may reveal details of the target services > being accessed. The resource and the audience parameters allow > authorization servers to know where the issued access token > will be used. This may be a privacy concern for some users. This > document does not specify techniques to prevent > authorization servers to know where the access tokens they issue will be > used. > Denis > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Web Authorization Protocol WG of the IETF. > > Title : OAuth 2.0 Token Exchange > Authors : Michael B. Jones > Anthony Nadalin > Brian Campbell > John Bradley > Chuck Mortimore > Filename : draft-ietf-oauth-token-exchange-10.txt > Pages : 32 > Date : 2017-11-30 > > Abstract: > This specification defines a protocol for an HTTP- and JSON- based > Security Token Service (STS) by defining how to request and obtain > security tokens from OAuth 2.0 authorization servers, including > security tokens employing impersonation and delegation. > > > The IETF datatracker status page for this draft is:https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/ > > There are also htmlized versions available at:https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-10https://datatracker.ietf.org/doc/html/draft-ietf-oauth-token-exchange-10 > > A diff from the previous version is available at:https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-token-exchange-10 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at:ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > -- *CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.* --94eb2c05be5a045b9a055fda4dec Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As an individual, I do not believe that the proposed text = should be incorporated into the draft.

As one of the document editor= s, my responsibility is for the document to be of reasonable quality and to= reflect the rough consensus of this Working Group. So I should ask the lis= t more explicitly - are there other WG remembers who are in favor of the pr= oposed text here (the text would have to be fixed up some too)?
<= div class=3D"gmail_extra">
On Fri, Dec 1, 201= 7 at 11:12 AM, Denis <denis.ietf@free.fr> wrote:
=20 =20 =20

Comments on draft-ietf-oauth-token-exchange-10

I propose the following rephrasing for sections 6 and 7:

6 . Security Considerations

All of the normal security issues that are discussed in [JWT],especially in relationship to comparing URIs
and dealing with unrecognized values, also apply here.=C2=A0 In addition, both delegation and impersonation introduce
unique security issues. Any time one user receives a token, the potential for abuse is a concern,
since that user might be willing to collude with another user so that other user could use the token.
=C2=A0
Techniques like the binding of an access token to a TLS channel described elsewhere are ineffective since
the legitimate user would be able to perform all the cryptographic computations that the other user would need
to demonstrate the ownership of the token. The use of the "scp" claim is suggested to mitigate potential for
such abuse, as it restricts the contexts in which the token can be exercised.=C2=A0 If the issu= ed access token scope
allows to unambiguously identify the user, then that user is likely to be reluctant to collude with another user. =C2=A0
However, if the issued access token scope only indicates that the user is over 18, then there is no risk
for the original user to be discovered and in such a context a collusion may easily take place.
This document does not specify techniques to prevent such a collusion to be successful.

7 . Privacy Considerations

Tokens typically carry personal information and their usage in Token Exchange may reveal details of the target services
being accessed. The resource and the audience parameters allow authorization servers to know where the issued access token
will be used. =C2=A0This may be a privacy concern for some users. This document does not specify techniques to prevent
authorization servers to know where the access tokens they issue will be used.

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

        Title           : OAuth 2.0 Token Exchange
        Authors         : Michael B. Jones
                          Anthony Nadalin
                          Brian Campbell
                          John Bradley
                          Chuck Mortimore
	Filename        : draft-ietf-oauth-token-exchange-10.txt
	Pages           : 32
	Date            : 2017-11-30

Abstract:
   This specification defines a protocol for an HTTP- and JSON- based
   Security Token Service (STS) by defining how to request and obtain
   security tokens from OAuth 2.0 authorization servers, including
   security tokens employing impersonation and delegation.


The IETF datatracker status page for this draft is:
ht=
tps://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/

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

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


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

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

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



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



<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --94eb2c05be5a045b9a055fda4dec-- From nobody Fri Dec 8 12:55:58 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 807431272E1 for ; Fri, 8 Dec 2017 12:55:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.039 X-Spam-Level: X-Spam-Status: No, score=-1.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WrDClFlaAtTU for ; Fri, 8 Dec 2017 12:55:55 -0800 (PST) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0097.outbound.protection.outlook.com [104.47.41.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0346A126CC4 for ; Fri, 8 Dec 2017 12:55:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=X37TBzPe27kToj+fVBKesluT0/rlOd8I93jdcGggfKs=; b=DoVe1SwZRxUbLPKy8zN0HEOJn3Tj0EWAj31LCvHYgT8n/WAYz+zxknPEE8MD/vwwbbEvhom24EzvfGg/ZHUW528o4foYEVvlRerXJPLWGvT+Fs+5IMmRISkJ0Zx/6czoqzk74r/aHcOAtd4Fkg1O0Y1AHIscMa0C+1bvs9HC8wU= Received: from CY4PR21MB0504.namprd21.prod.outlook.com (10.172.122.14) by CY4PR21MB0278.namprd21.prod.outlook.com (10.173.193.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.323.1; Fri, 8 Dec 2017 20:55:53 +0000 Received: from CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) by CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) with mapi id 15.20.0323.001; Fri, 8 Dec 2017 20:55:53 +0000 From: Mike Jones To: Denis , Brian Campbell CC: oauth Thread-Topic: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchange-10.txt Thread-Index: AQHTajbUHynLN4CxSk61u85TcnP8RqMuy3kAgAsrogCAAAJWOg== Date: Fri, 8 Dec 2017 20:55:53 +0000 Message-ID: References: <151208615408.11802.12175452260900272912@ietfa.amsl.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [104.208.33.187] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0278; 6:4s8OS+d7gbwhcNa0EdPpHIHEpw4pKdSgTedNMExKSCkuwjRLXhf3giGp8Hby5Z3StXSQEwPCBfXeL5BxSk/aYAlUlvr5V+A2L56650XyZVp1YM01ootr7nZSBUvyFwROR7XAUVDdOD8NsAx53+YVAZBe9P4rrgQ9LojjgVXaN+RrL2/rSxx5RfcB700LZaAOJJkYPCZLq3yK+NMr7qwpeUifMQQUUVJB8IVUpjKt0asZ01pLy2lHb4jF4Jz201obxaC55uB+XgCF8IMZ8foksuPLm35N/lA3pel+6+bfNFV9c69EH05eESP4qQA/zgiCC8MMkZLUrybsssYU9zQvAbwXzFR4b+pdkNM9phqG9EE=; 5:Ewjb65qJyql9sTVLzJmzI0kSw+DFqISQ+BCzbkaj4x2aou7JRRbAqj+8wfjVASpxJIlum+eTvJ7imky0Yv0O2vXeFNLeusbunVaJDE7STT1BGquUR9YMNPs+5q+A9edlSRdd+/58wFypcie+AnRv82ltZkOeR3OjY60nrrt99WI=; 24:ykmxLUKczsxZRx1eQ8LYx7h2MIoX2VhK2qzI5+4nFL2JZ3j2U+tNPF4/O+XXOtlN6Tw+5r5SVHi/vX5ZqDhFXibF9a4n/I5/x+hsxebugF4=; 7:61j2VIFy7rynFHCQ5TCi8zKXDJNEB7JJ1uJKzvAi9jpItrA1S9kp/aEePOe0NdkmO7TocijL7yDvIIa8e6LN0mWN8gDsifZkbxbjvI7VGySnjm/ioi7oRBIgXDwyaxAcaSNKvTPtRIYEpsUlxp4NOyW7Drm+fz2hQk/K09trSasb2pU9G+A1s8vwB7H4OXP0RW31jxIY05gJzGGvSJ8+Ec3XAfKN6eFtL/tFwVzJsU52gtkXw/mOGsh7py1zOV6d x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 24d41644-b4f6-49bd-74c5-08d53e7e1231 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(2017052603307); SRVR:CY4PR21MB0278; x-ms-traffictypediagnostic: CY4PR21MB0278: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(60795455431006)(191636701735510)(120809045254105)(192374486261705)(100405760836317); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(3231022)(6055026)(61426038)(61427038)(6041248)(20161123562025)(20161123555025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123564025)(6072148)(201708071742011); SRVR:CY4PR21MB0278; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:CY4PR21MB0278; x-forefront-prvs: 0515208626 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(366004)(39860400002)(346002)(377424004)(24454002)(36304003)(189003)(199004)(25786009)(102836003)(76176011)(99286004)(8990500004)(6436002)(6506006)(53386004)(5890100001)(606006)(5660300001)(33656002)(4000630100001)(66066001)(81166006)(2906002)(8676002)(105586002)(81156014)(53936002)(3280700002)(2900100001)(6246003)(106356001)(2950100002)(110136005)(53546010)(966005)(7696005)(478600001)(4001150100001)(10090500001)(86612001)(3846002)(7736002)(86362001)(230783001)(77096006)(97736004)(74316002)(4326008)(8936002)(9686003)(68736007)(22452003)(229853002)(14454004)(10290500003)(6116002)(54896002)(236005)(316002)(55016002)(72206003)(3660700001)(6306002)(15866825006); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0278; H:CY4PR21MB0504.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB05042AF4B393C14146411240F5300CY4PR21MB0504namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 24d41644-b4f6-49bd-74c5-08d53e7e1231 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Dec 2017 20:55:53.3263 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0278 Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchange-10.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Dec 2017 20:55:57 -0000 --_000_CY4PR21MB05042AF4B393C14146411240F5300CY4PR21MB0504namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I believe the text would detract from the document. ________________________________ From: OAuth on behalf of Brian Campbell Sent: Friday, December 8, 2017 3:47:32 PM To: Denis Cc: oauth Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchange-10.txt As an individual, I do not believe that the proposed text should be incorpo= rated into the draft. As one of the document editors, my responsibility is for the document to be= of reasonable quality and to reflect the rough consensus of this Working G= roup. So I should ask the list more explicitly - are there other WG remembe= rs who are in favor of the proposed text here (the text would have to be fi= xed up some too)? On Fri, Dec 1, 2017 at 11:12 AM, Denis > wrote: Comments on draft-ietf-oauth-token-exchange-10 I propose the following rephrasing for sections 6 and 7: 6 . Security Considerations All of the normal security issues that are discussed in [JWT],especially in= relationship to comparing URIs and dealing with unrecognized values, also apply here. In addition, both d= elegation and impersonation introduce unique security issues. Any time one user receives a token, the potential f= or abuse is a concern, since that user might be willing to collude with another user so that other= user could use the token. Techniques like the binding of an access token to a TLS channel described e= lsewhere are ineffective since the legitimate user would be able to perform all the cryptographic computat= ions that the other user would need to demonstrate the ownership of the token. The use of the "scp" claim is su= ggested to mitigate potential for such abuse, as it restricts the contexts in which the token can be exercise= d. If the issued access token scope allows to unambiguously identify the user, then that user is likely to be r= eluctant to collude with another user. However, if the issued access token scope only indicates that the user is o= ver 18, then there is no risk for the original user to be discovered and in such a context a collusion ma= y easily take place. This document does not specify techniques to prevent such a collusion to be= successful. 7 . Privacy Considerations Tokens typically carry personal information and their usage in Token Exchan= ge may reveal details of the target services being accessed. The resource and the audience parameters allow authorizatio= n servers to know where the issued access token will be used. This may be a privacy concern for some users. This document = does not specify techniques to prevent authorization servers to know where the access tokens they issue will be us= ed. Denis A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web Authorization Protocol WG of the IETF. Title : OAuth 2.0 Token Exchange Authors : Michael B. Jones Anthony Nadalin Brian Campbell John Bradley Chuck Mortimore Filename : draft-ietf-oauth-token-exchange-10.txt Pages : 32 Date : 2017-11-30 Abstract: This specification defines a protocol for an HTTP- and JSON- based Security Token Service (STS) by defining how to request and obtain security tokens from OAuth 2.0 authorization servers, including security tokens employing impersonation and delegation. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-10 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-token-exchange-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-token-exchange-10 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth CONFIDENTIALITY NOTICE: This email may contain confidential and privileged = material for the sole use of the intended recipient(s). Any review, use, di= stribution or disclosure by others is strictly prohibited. If you have rec= eived this communication in error, please notify the sender immediately by = e-mail and delete the message and any file attachments from your computer. = Thank you. --_000_CY4PR21MB05042AF4B393C14146411240F5300CY4PR21MB0504namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I believe the text would detract from the document.
From: OAuth <oauth-bounc= es@ietf.org> on behalf of Brian Campbell <bcampbell@pingidentity.com&= gt;
Sent: Friday, December 8, 2017 3:47:32 PM
To: Denis
Cc: oauth
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchange-= 10.txt
 
As an individual, I do not believe that the proposed text = should be incorporated into the draft.

As one of the document editors, my responsibility is for the document to be= of reasonable quality and to reflect the rough consensus of this Working G= roup. So I should ask the list more explicitly - are there other WG remembe= rs who are in favor of the proposed text here (the text would have to be fixed up some too)?

On Fri, Dec 1, 2017 at 11:12 AM, Denis <denis.= ietf@free.fr> wrote:

Comments on d= raft-ietf-oauth-token-exchange-10

I propose the following rephrasing for sections 6 and 7:

6 . Security Considerations

All of the normal security issues that are discussed= in [JWT],especially in relationship to comparing URIs
and dealing with unrecognized values, also apply here.  In addition, b= oth delegation and impersonation introduce
unique security issues. Any time one user receives a token, the potential f= or abuse is a concern,
since that user might be willing to collude with another user so that other= user could use the token.
 
Techniques like the binding of an access token to a TLS channel described e= lsewhere are ineffective since
the legitimate user would be able to perform all the cryptographic computat= ions that the other user would need
to demonstrate the ownership of the token. The use of the "scp" c= laim is suggested to mitigate potential for
such abuse, as it restricts the contexts in which the token can be exercise= d.  If the issued= access token scope
allows to unambiguously identify the user, then that user is likely to be r= eluctant to collude with another user.  
However, if the issued access token scope only indicates that the user is o= ver 18, then there is no risk
for the original user to be discovered and in such a context a collusion ma= y easily take place.
This document does n= ot specify techniques to prevent such a collusion to be successful.<= /font>

7 . Privacy Considerations

Tokens typically carry personal information and thei= r usage in Token Exchange may reveal details of the target services
being accessed. The resource and the audience parameters allow authorizatio= n servers to know where the issued access token
will be used.  This may be a privacy concern for some use= rs. This document does not specify techniques to prevent
authorization servers to know where the access tokens they issue will be us= ed.

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

        Title           : OAuth 2.0 Token Exchange
        Authors         : Michael B. Jones
                          Anthony Nadalin
                          Brian Campbell
                          John Bradley
                          Chuck Mortimore
	Filename        : draft-ietf-oauth-token-exchange-10.txt
	Pages           : 32
	Date            : 2017-11-30

Abstract:
   This specification defines a protocol for an HTTP- and JSON- based
   Security Token Service (STS) by defining how to request and obtain
   security tokens from OAuth 2.0 authorization servers, including
   security tokens employing impersonation and delegation.


The IETF datatracker status page for this draft is:
ht=
tps://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/

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

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


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

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

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



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



CONFIDENTIALI= TY NOTICE: This email may contain confidential and privileged material for th= e sole use of the intended recipient(s). Any review, use, distribution or d= isclosure by others is strictly prohibited.  If you have received this= communication in error, please notify the sender immediately by e-mail and delete the message and any file attac= hments from your computer. Thank you.
--_000_CY4PR21MB05042AF4B393C14146411240F5300CY4PR21MB0504namp_-- From nobody Fri Dec 8 13:29:46 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF6AD12711E for ; Fri, 8 Dec 2017 13:29:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2qywAIbknECP for ; Fri, 8 Dec 2017 13:29:41 -0800 (PST) Received: from mail-ua0-f181.google.com (mail-ua0-f181.google.com [209.85.217.181]) (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 91509124B18 for ; Fri, 8 Dec 2017 13:29:41 -0800 (PST) Received: by mail-ua0-f181.google.com with SMTP id i4so8347476uab.5 for ; Fri, 08 Dec 2017 13:29:41 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=aSl0taKZ2iL0Z2ERVsWnyoKVsB9eYJcX/haY/kj+agw=; b=pmwKcO8RNfx6Mtt6chPuRwnzeFQ3H5xt7sR8I7pTOg260t8OiLjpxgxe66uwaobe+p DjdczTY2K1SOZSWt2wj/0JEaxxaTueG5FX27cyK2K08/VAARs1zpGIdxsDfU3fShGOwC VasKWw2tRmkVDosdNUdAfcDcyQtQCQmXgy6l5T5aaBCIj3sDIv+HnZjyhhG/nwLyqAhG dFDLP5LFCSK62Ab6wUYVd3cxs4aEcjtOuSU51JDMkcalDP5/kfWSaaU/C88QLSh2oa1a K1MxS6BlhKfSYd5cg+22DJ6w1TLz37151pAKxh+T9+Frl0r0fNbWh1xsihzPaXZ5Ks8w rIMw== X-Gm-Message-State: AKGB3mKLn7TF6owkeFFkILL6mG+7jfumM+sabmCC8a0VSQOgoT4RaFZI ckhwuEt7OQDY0dKv/TpzauriASL9+2h0jsE1paFrKg== X-Google-Smtp-Source: AGs4zMalTapREaCUO7of83R396u9GvOsyyhq2mmpxcBVokdH69oKVTdBqZDXrHB8xhe92qGDpgnO9qMvU2VOqpOIgkE= X-Received: by 10.176.23.81 with SMTP id k17mr8636933uaf.131.1512768580469; Fri, 08 Dec 2017 13:29:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.68.86 with HTTP; Fri, 8 Dec 2017 13:29:39 -0800 (PST) In-Reply-To: References: From: Bill Burke Date: Fri, 8 Dec 2017 16:29:39 -0500 Message-ID: To: Brian Campbell Cc: OAuth WG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [OAUTH-WG] [token-exchange] Parameters to support external token exchange X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Dec 2017 21:29:44 -0000 On Fri, Dec 8, 2017 at 12:41 PM, Brian Campbell wrote: > I guess I'm going to kind of restate some of what I said in that earlier > thread and a bit more. The access and refresh token URIs from the draft are > intended to indicate that such tokens are issued by the given authorization > server acting as the STS (perhaps this could be stated more clearly in the > doc). As such, there isn't direct explicit support for OAuth access token to > OAuth access token cross-domain type exchanges. That was intentional and I > think is appropriate as I don't believe this draft should delve into pseudo > federating access tokens and all the additional complexity and security > implications that entails. I'll look in my email archives again, but, I wasn't convinced then that there is all this additional complexity. > The assertion based authorization grants (RFCs > 7523 & 7522) are intended to facilitate acquiring an access token from an > external or cross-domain AS and I prefer that more explicit model for > cross-domain than codifying a rather implicit way of doing it in token > exchange. Not understanding what you mean by implicit vs. explicit. I don't see how what we've implemented is any more implicit than the current specification. If anything, I thought our impl was more explicit as you can't derive the issuer from an opaque access token in the current spec. > A Facebook access token, for example, is issued to a client for > delegated access to Facebook APIs. It isn't for delegated access to some > other domain's APIs but an access token for access token exchange > effectively turns it into that. And in some situations that can have > problematic security implications. Internet applications trust Facebook, Google, whoever to identity and authenticate users all the time and to grant access and permission based on that identity. An external exchange is just a non-browser mechanism to facilitate this relationship. For our IDP, our userbase often use us as a broker between the various social websites and their apps. This way, apps don't care where the user was authenticated from, they just see open id connect with a token format and domain they control. Developers often have apps that they are not able to change how a user logs in or cannot unify their apps with a common STS, token format, or even protocol. Yet they still have a need to make secure invocations across these domains and apps. > Big providers like Facebook have a lot of > apps (OAuth clients) that can get access tokens. An organization might well > be okay with an app it controls exchanging a Facebook access token for an > access token for its own APIs. But a 3rd party Facebook app (like maybe a > new viral rate my '80's hairdo app) doing the same thing could be very > problematic. It's not exactly the same thing but many of the same potential > issues arise as when using OAuth for User Authentication. Standardization > around access token for access token exchange would, at a minimum, need some > real security analysis and recommendations/considerations. > > The token exchange draft went thought WGLC some time ago and is currently > being written up by the document shepherd to send to the AD. It's close. > It's been a long time coming and I'd really object to derailing it by making > big additions to it at this late stage in the process. > That's fair enough. I didn't know how far in the process the token exchange draft was. In the least, I wanted to make the WG aware of our work. We have a decent and growing user base with a problem looking for a solution and we're going to get a lot of feedback on what we've implemented. At least from our open source project perspective, there's a lot more interest in external exchange than internal. Which is why I'm posting this. -- Bill Burke Red Hat From nobody Fri Dec 8 13:46:30 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A78F8124207 for ; Fri, 8 Dec 2017 13:46:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vFeYcl9klNm9 for ; Fri, 8 Dec 2017 13:46:25 -0800 (PST) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F6891200F1 for ; Fri, 8 Dec 2017 13:46:25 -0800 (PST) Received: from [192.168.0.13] (unknown [88.182.125.39]) by smtp6-g21.free.fr (Postfix) with ESMTP id E613378033D; Fri, 8 Dec 2017 22:46:22 +0100 (CET) To: Mike Jones , Brian Campbell Cc: oauth , Rifaat Shekh-Yusef , Hannes Tschofenig References: <151208615408.11802.12175452260900272912@ietfa.amsl.com> From: Denis Message-ID: <9e362874-54d3-ae73-2e77-fc0eb3a98e3b@free.fr> Date: Fri, 8 Dec 2017 22:46:25 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------5A6BBC15DB39DC6948E1C4B6" Content-Language: fr Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchange-10.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Dec 2017 21:46:29 -0000 This is a multi-part message in MIME format. --------------5A6BBC15DB39DC6948E1C4B6 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit RFC 3552 (Guidelines for Writing RFC Text on Security Considerations) states: All RFCs are required by RFC 2223 to contain a Security Considerations section.The purpose of this is both to encourage document authors to consider security in their designs and to inform the reader of relevant security issues.This memo is intended to provide guidance to RFC authors in service of both ends. Section 5 (Writing Security Considerations Sections) of RFC 3552 states: While it is not a requirement that any given protocol or system be immune to all forms of attack, it is still necessary for authors to consider as many forms as possible.Part of the purpose of the Security Considerations section is to explain what attacks are out of scope and what countermeasures can be applied to defend against them There should be a clear description of the kinds of threats on the described protocol or technology. It is important to mention the threat related to collusion attacks. A different wording could be used, but the threat should be mentioned**one way or another. RFC 6973 (Privacy Considerations for Internet Protocols) intends to provide a similar set of guidelines for considering privacy in protocol design. It is important to mention a current threat related to privacy. A different wording could be used, e.g. using the word "surveillance" as mentioned in 5.1.1 : "Surveillance is the observation or monitoring of an individual’s communications or activities", but the threat should be mentioned one way or another. Denis > I believe the text would detract from the document. > ------------------------------------------------------------------------ > *From:* OAuth on behalf of Brian Campbell > > *Sent:* Friday, December 8, 2017 3:47:32 PM > *To:* Denis > *Cc:* oauth > *Subject:* Re: [OAUTH-WG] I-D Action: > draft-ietf-oauth-token-exchange-10.txt > As an individual, I do not believe that the proposed text should be > incorporated into the draft. > > As one of the document editors, my responsibility is for the document > to be of reasonable quality and to reflect the rough consensus of this > Working Group. So I should ask the list more explicitly - are there > other WG remembers who are in favor of the proposed text here (the > text would have to be fixed up some too)? > > On Fri, Dec 1, 2017 at 11:12 AM, Denis > wrote: > > Comments on draft-ietf-oauth-token-exchange-10 > > I propose the following rephrasing for sections 6 and 7: > > 6 . Security Considerations > > All of the normal security issues that are discussed in > [JWT],especially in relationship to comparing URIs > and dealing with unrecognized values, also apply here.  In > addition, both delegation and impersonation introduce > unique security issues. Any time one user receives a token, the > potential for abuse is a concern, > since that user might be willing to collude with another user so > that other user could use the token. > > Techniques like the binding of an access token to a TLS channel > described elsewhere are ineffective since > the legitimate user would be able to perform all the cryptographic > computations that the other user would need > to demonstrate the ownership of the token. The use of the "scp" > claim is suggested to mitigate potential for > such abuse, as it restricts the contexts in which the token can be > exercised. If the issued access token scope > allows to unambiguously identify the user, then that user is > likely to be reluctant to collude with another user. > However, if the issued access token scope only indicates that the > user is over 18, then there is no risk > for the original user to be discovered and in such a context a > collusion may easily take place. > This document does not specify techniques to prevent such a > collusion to be successful. > > 7 . Privacy Considerations > > Tokens typically carry personal information and their usage in > Token Exchange may reveal details of the target services > being accessed. The resource and the audience parameters allow > authorization servers to know where the issued access token > will be used. This may be a privacy concern for some users. This > document does not specify techniques to prevent > authorization servers to know where the access tokens they issue > will be used. > > Denis >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> This draft is a work item of the Web Authorization Protocol WG of the IETF. >> >> Title : OAuth 2.0 Token Exchange >> Authors : Michael B. Jones >> Anthony Nadalin >> Brian Campbell >> John Bradley >> Chuck Mortimore >> Filename : draft-ietf-oauth-token-exchange-10.txt >> Pages : 32 >> Date : 2017-11-30 >> >> Abstract: >> This specification defines a protocol for an HTTP- and JSON- based >> Security Token Service (STS) by defining how to request and obtain >> security tokens from OAuth 2.0 authorization servers, including >> security tokens employing impersonation and delegation. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/ >> >> >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-10 >> >> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-token-exchange-10 >> >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-token-exchange-10 >> >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available attools.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 > > > > > /CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly > prohibited.  If you have received this communication in error, please > notify the sender immediately by e-mail and delete the message and any > file attachments from your computer. Thank you./ --------------5A6BBC15DB39DC6948E1C4B6 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

RFC 3552 (Guidelines for Writing RFC Text on Security Considerations) states:

   All RFCs are required by RFC 2223 to contain a Security
   Considerations section.  The purpose of this is both to encourage
   document authors to consider security in their designs and to inform
   the reader of relevant security issues.  This memo is intended to
   provide guidance to RFC authors in service of both ends.

Section 5 (Writing Security Considerations Sections) of RFC 3552 states:

   While it is not a requirement that any given protocol or system be
   immune to all forms of attack, it is still necessary for authors to
   consider as many forms as possible.  Part of the purpose of the
   Security Considerations section is to explain what attacks are out of
   scope and what countermeasures can be applied to defend against them

   There should be a clear description of the kinds of threats on the
   described protocol or technology. 

It is important to mention the threat related to collusion attacks. A different wording could be used,
but the threat should be mentioned one way or another.

RFC 6973 (Privacy Considerations for Internet Protocols) intends to provide a similar set of guidelines
for considering privacy in protocol design.

It is important to mention a current threat related to privacy. A different wording could be used,
e.g. using the word "surveillance" as mentioned in 5.1.1 : "Surveillance is the observation or monitoring
of an individual’s communications or activities", but the threat should be mentioned one way or another.

Denis

I believe the text would detract from the document.
From: OAuth <oauth-bounces@ietf.org> on behalf of Brian Campbell <bcampbell@pingidentity.com>
Sent: Friday, December 8, 2017 3:47:32 PM
To: Denis
Cc: oauth
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchange-10.txt
 
As an individual, I do not believe that the proposed text should be incorporated into the draft.

As one of the document editors, my responsibility is for the document to be of reasonable quality and to reflect the rough consensus of this Working Group. So I should ask the list more explicitly - are there other WG remembers who are in favor of the proposed text here (the text would have to be fixed up some too)?

On Fri, Dec 1, 2017 at 11:12 AM, Denis <denis.ietf@free.fr> wrote:

Comments on draft-ietf-oauth-token-exchange-10

I propose the following rephrasing for sections 6 and 7:

6 . Security Considerations

All of the normal security issues that are discussed in [JWT],especially in relationship to comparing URIs
and dealing with unrecognized values, also apply here.  In addition, both delegation and impersonation introduce
unique security issues. Any time one user receives a token, the potential for abuse is a concern,
since that user might be willing to collude with another user so that other user could use the token.
 
Techniques like the binding of an access token to a TLS channel described elsewhere are ineffective since
the legitimate user would be able to perform all the cryptographic computations that the other user would need
to demonstrate the ownership of the token. The use of the "scp" claim is suggested to mitigate potential for
such abuse, as it restricts the contexts in which the token can be exercised.  If the issued access token scope
allows to unambiguously identify the user, then that user is likely to be reluctant to collude with another user.  
However, if the issued access token scope only indicates that the user is over 18, then there is no risk
for the original user to be discovered and in such a context a collusion may easily take place.
This document does not specify techniques to prevent such a collusion to be successful.

7 . Privacy Considerations

Tokens typically carry personal information and their usage in Token Exchange may reveal details of the target services
being accessed. The resource and the audience parameters allow authorization servers to know where the issued access token
will be used.  This may be a privacy concern for some users. This document does not specify techniques to prevent
authorization servers to know where the access tokens they issue will be used.

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

        Title           : OAuth 2.0 Token Exchange
        Authors         : Michael B. Jones
                          Anthony Nadalin
                          Brian Campbell
                          John Bradley
                          Chuck Mortimore
	Filename        : draft-ietf-oauth-token-exchange-10.txt
	Pages           : 32
	Date            : 2017-11-30

Abstract:
   This specification defines a protocol for an HTTP- and JSON- based
   Security Token Service (STS) by defining how to request and obtain
   security tokens from OAuth 2.0 authorization servers, including
   security tokens employing impersonation and delegation.


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

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

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


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

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

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



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



CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.


--------------5A6BBC15DB39DC6948E1C4B6-- From nobody Fri Dec 8 17:48:45 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10254126C26 for ; Fri, 8 Dec 2017 17:48:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4PN0AcwLGvoZ for ; Fri, 8 Dec 2017 17:48:41 -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 4CF251200CF for ; Fri, 8 Dec 2017 17:48:41 -0800 (PST) Received: by mail-io0-x235.google.com with SMTP id s37so4237317ioe.10 for ; Fri, 08 Dec 2017 17:48:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UXj6fgQ4xEq6vQbmTNHG2/uqX1H72UHieIW4BaKCMiw=; b=J9bBg2FpNp6nxFRj5TaRqUHsEpE+p1dTlDVx8XW3aHbMIWXRxelw0xRt/aHfIUl1/b hXx0qqvFmxZ2+avC40TPiedHG6Gm1SHZ8E/jjszz7BcvPXwVhdu79wKSTgsWRRQ9TUTJ eE9AO8ETUTRizNa6SVXBDHPZLyW2nt7kPtw3s= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UXj6fgQ4xEq6vQbmTNHG2/uqX1H72UHieIW4BaKCMiw=; b=OkrSmwoqRHLy/ink5zhzjIdaI/I8839tOymqF01uL8qi9c2+9Np8Nv/oX8OoRU+hAm ACvoMENo70K4mQOSymvaDkkPFwSUe7KQyFZ5JYyyjuRhHQraB1G//3JAc6nVcFTavZW9 /u7+70h08CFwtr5JYHkvLAOQcpL6eLyU/cndt9CyS5xRUgdyyGe7NHTpVJGcbpm/d5wd 6DmGumkCxNzJ452PqIa0qGPu3RiKm3Zz3gHi1nY3I5krKBlFCBKpD0wG1JAwg70uJJpj pVaCdui28HvVKcvQPHAtjNVVYhkV3pG8PGWA3ckgT3cRRUgR1K1SV/HB6mAALeXplCuH oGIg== X-Gm-Message-State: AKGB3mISvz46xYZsu65jZg46J8ku2AWEsIYbHlVBNXrD+68i3kUioyBx JlwqKVx++lWNRlEAfT942bwPH3ssN95Q1ockEAhFA4e0kSWcpD0MNAlY0agX20bLGxFIx+/gnk5 P5xyU6BzTN0MIIA== X-Google-Smtp-Source: AGs4zMbzVQtlUllTPry+v/eqZ3Ounm8tynk/kuNEMhs8P/BjFi2+B+faImEDi3LQTvGRKI6eut7Su9mlJ+MaRuplV94= X-Received: by 10.107.139.196 with SMTP id n187mr40307999iod.54.1512784120334; Fri, 08 Dec 2017 17:48:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.2.118.194 with HTTP; Fri, 8 Dec 2017 17:48:09 -0800 (PST) In-Reply-To: <9e362874-54d3-ae73-2e77-fc0eb3a98e3b@free.fr> References: <151208615408.11802.12175452260900272912@ietfa.amsl.com> <9e362874-54d3-ae73-2e77-fc0eb3a98e3b@free.fr> From: Brian Campbell Date: Fri, 8 Dec 2017 18:48:09 -0700 Message-ID: To: Denis Cc: Mike Jones , oauth , Rifaat Shekh-Yusef , Hannes Tschofenig Content-Type: multipart/alternative; boundary="94eb2c05be5a1d6e65055fde809a" Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchange-10.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Dec 2017 01:48:44 -0000 --94eb2c05be5a1d6e65055fde809a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The privacy matter is already mentioned. Despite your many messages to this WG and others about the so called ABC attack, I do not believe it warrants treatment in this document or others. And your continued proposals to have it included in documents have not gotten support. On Fri, Dec 8, 2017 at 2:46 PM, Denis wrote: > RFC 3552 (Guidelines for Writing RFC Text on Security Considerations) > states: > > All RFCs are required by RFC 2223 to contain a Security > Considerations section. The purpose of this is both to encourage > document authors to consider security in their designs and to inform > the reader of relevant security issues. This memo is intended to > provide guidance to RFC authors in service of both ends. > > Section 5 (Writing Security Considerations Sections) of RFC 3552 states: > > While it is not a requirement that any given protocol or system be > immune to all forms of attack, it is still necessary for authors to > consider as many forms as possible. Part of the purpose of the > Security Considerations section is to explain what attacks are out of > scope and what countermeasures can be applied to defend against them > > There should be a clear description of the kinds of threats on the > described protocol or technology. > > It is important to mention the threat related to collusion attacks. A > different wording could be used, > but the threat should be mentioned one way or another. > RFC 6973 (Privacy Considerations for Internet Protocols) intends to > provide a similar set of guidelines > for considering privacy in protocol design. It is important to mention a > current threat related to privacy. A different wording could be used, > e.g. using the word "surveillance" as mentioned in 5.1.1 : "Surveillance > is the observation or monitoring > of an individual=E2=80=99s communications or activities", but the threat = should be > mentioned one way or another. Denis > > I believe the text would detract from the document. > ------------------------------ > *From:* OAuth on behalf > of Brian Campbell > > *Sent:* Friday, December 8, 2017 3:47:32 PM > *To:* Denis > *Cc:* oauth > *Subject:* Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-token- > exchange-10.txt > > As an individual, I do not believe that the proposed text should be > incorporated into the draft. > > As one of the document editors, my responsibility is for the document to > be of reasonable quality and to reflect the rough consensus of this Worki= ng > Group. So I should ask the list more explicitly - are there other WG > remembers who are in favor of the proposed text here (the text would have > to be fixed up some too)? > > On Fri, Dec 1, 2017 at 11:12 AM, Denis wrote: > >> Comments on draft-ietf-oauth-token-exchange-10 >> >> I propose the following rephrasing for sections 6 and 7: >> >> 6 . Security Considerations >> >> All of the normal security issues that are discussed in [JWT],especially >> in relationship to comparing URIs >> and dealing with unrecognized values, also apply here. In addition, bot= h >> delegation and impersonation introduce >> unique security issues. Any time one user receives a token, the potentia= l >> for abuse is a concern, >> since that user might be willing to collude with another user so that >> other user could use the token. >> >> Techniques like the binding of an access token to a TLS channel describe= d >> elsewhere are ineffective since >> the legitimate user would be able to perform all the cryptographic >> computations that the other user would need >> to demonstrate the ownership of the token. The use of the "scp" claim is >> suggested to mitigate potential for >> such abuse, as it restricts the contexts in which the token can be >> exercised. If the issued access token scope >> allows to unambiguously identify the user, then that user is likely to b= e >> reluctant to collude with another user. >> However, if the issued access token scope only indicates that the user i= s >> over 18, then there is no risk >> for the original user to be discovered and in such a context a collusion >> may easily take place. >> This document does not specify techniques to prevent such a collusion to >> be successful. >> >> 7 . Privacy Considerations >> >> Tokens typically carry personal information and their usage in Token >> Exchange may reveal details of the target services >> being accessed. The resource and the audience parameters allow >> authorization servers to know where the issued access token >> will be used. This may be a privacy concern for some users. This >> document does not specify techniques to prevent >> authorization servers to know where the access tokens they issue will be >> used. >> Denis >> >> A New Internet-Draft is available from the on-line Internet-Drafts direc= tories. >> This draft is a work item of the Web Authorization Protocol WG of the IE= TF. >> >> Title : OAuth 2.0 Token Exchange >> Authors : Michael B. Jones >> Anthony Nadalin >> Brian Campbell >> John Bradley >> Chuck Mortimore >> Filename : draft-ietf-oauth-token-exchange-10.txt >> Pages : 32 >> Date : 2017-11-30 >> >> Abstract: >> This specification defines a protocol for an HTTP- and JSON- based >> Security Token Service (STS) by defining how to request and obtain >> security tokens from OAuth 2.0 authorization servers, including >> security tokens employing impersonation and delegation. >> >> >> The IETF datatracker status page for this draft is:https://datatracker.i= etf.org/doc/draft-ietf-oauth-token-exchange/ >> >> There are also htmlized versions available at:https://tools.ietf.org/htm= l/draft-ietf-oauth-token-exchange-10https://datatracker.ietf.org/doc/html/d= raft-ietf-oauth-token-exchange-10 >> >> A diff from the previous version is available at:https://www.ietf.org/rf= cdiff?url2=3Ddraft-ietf-oauth-token-exchange-10 >> >> >> Please note that it may take a couple of minutes from the time of submis= sion >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at:ftp://ftp.ietf.or= g/internet-drafts/ >> >> _______________________________________________ >> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oa= uth >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited. > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > > > --=20 *CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited. If you have= =20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you.* --94eb2c05be5a1d6e65055fde809a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The privacy matter is already mentioned. Despite your many= messages to this WG and others about the so called ABC attack, I do not be= lieve it warrants treatment in this document or others. And your continued = proposals to have it included in documents have not gotten support.=C2=A0 <= br>

On Fri, = Dec 8, 2017 at 2:46 PM, Denis <denis.ietf@free.fr> wrote:
=20 =20 =20

RFC 3552 (Guidelines for Writing RFC Text on Security Considerations) states:

=C2=A0=C2=A0 All RFCs are required by RFC 2223 to contain a Security
=C2=A0=C2=A0 Considerations section.=C2=A0 The purpose of this is both to encourage
=C2=A0=C2=A0 document authors to consider security in their designs and = to inform
=C2=A0=C2=A0 the reader of relevant security issues.=C2=A0 This memo is intended to
=C2=A0=C2=A0 provide guidance to RFC authors in service of both ends.

Section 5 (Writing Security Considerations Sections) of RFC 3552 states:

=C2=A0=C2=A0 While it is not a requirement that any given protocol or system be
=C2=A0=C2=A0 immune to all forms of attack, it is still necessary for authors to
=C2=A0=C2=A0 consider as many forms as possible.=C2=A0 Part of the purpose of the
=C2=A0=C2=A0 Security Considerations section is to explain what attacks are out of
=C2=A0=C2=A0 scope and what countermeasures can be applied to defend against them

=C2=A0=C2=A0 There should be a clear description of the kinds of threats on the
=C2=A0=C2=A0 described protocol or technology.=C2=A0

It is important to mention the threat related to collusion attacks. A different wording could be used,
but the threat should be mentioned one way or another.

RFC 6973 (Privacy Considerations for Internet Protocols) intends to provide a similar set of guidelines
for considering privacy in protocol design.

It is important to mention a current threat related to privacy. A different wording could be used,
e.g. using the word "surveillance" as mentioned in 5.1.1 : "Surve= illance is the observation or monitoring
of an individual=E2=80=99s communications or activities", bu= t the threat should be mentioned one way or another.

Denis

I believe the text would detract from the document.
Fro= m: OAuth <oauth-bounces@ietf.org= > on behalf of Brian Campbell <bcampbell@pingiden= tity.com>
Sent: Friday, December 8, 2017 3:47:32 PM
To: Denis
Cc: oauth
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchange-10.txt
=C2=A0
As an individual, I do not believe that the proposed text should be incorporated into the draft.

As one of the document editors, my responsibility is for the document to be of reasonable quality and to reflect the rough consensus of this Working Group. So I should ask the list more explicitly - are there other WG remembers who are in favor of the proposed text here (the text would have to be fixed up some too)?

On Fri, Dec 1, 2017 at 11:12 AM, Denis <denis.ietf@free.fr> wrote:

Comments on draft-ietf-oauth-token-exchange-10=

I propose the following rephrasing for sections 6 and 7:

6 . Security Considerations

All of the normal security issues that are discussed in [JWT],especially in relationship to comparing URIs
and dealing with unrecognized values, also apply here.=C2=A0 In addition, both delegation and impersonation introduce
unique security issues. Any time one user receives a token, the potential for abuse is a concern,
since that user might be willing to collude with another user so that other user could use the token.
=C2=A0
Techniques like the binding of an access token to a TLS channel described elsewhere are ineffective since
the legitimate user would be able to perform all the cryptographic computations that the other user would need
to demonstrate the ownership of the token. The use of the "scp" claim is suggested to mi= tigate potential for
such abuse, as it restricts the contexts in which the token can be exercised.=C2=A0 If the issued access token scope
allows to unambiguously identify the user, then that user is likely to be reluctant to collude with another user. =C2=A0
However, if the issued access token scope only indicates that the user is over 18, then there is no risk
for the original user to be discovered and in such a context a collusion may easily take place.
This document does not specify techniques to prevent such a collusion to be successful.

7 . Privacy Considerations

Tokens typically carry personal information and their usage in Token Exchange may reveal details of the target services
being accessed. The resource and the audience parameters allow authorization servers to know where the issued access token
will be used. =C2=A0This may be a privacy concern for some users. This document does not specify techniques to prevent
authorization servers to know where the access tokens they issue will be used.

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

        Title           : OAuth 2.0 Token Exchange
        Authors         : Michael B. Jones
                          Anthony Nadalin
                          Brian Campbell
                          John Bradley
                          Chuck Mortimore
	Filename        : draft-ietf-oauth-token-exchange-10.txt
	Pages           : 32
	Date            : 2017-11-30

Abstract:
   This specification defines a protocol for an HTTP- and JSON- based
   Security Token Service (STS) by defining how to request and obtain
   security tokens from OAuth 2.0 authorization servers, including
   security tokens employing impersonation and delegation.


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

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-oauth-token-ex=
change-10
https://datatracker.ietf.org/doc/html/draft=
-ietf-oauth-token-exchange-10

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


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

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

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



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



CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.=C2=A0 If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.<= /div>




<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --94eb2c05be5a1d6e65055fde809a-- From nobody Mon Dec 11 08:46:44 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 404F41270A3 for ; Mon, 11 Dec 2017 08:46:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a1eDcCqVU3V3 for ; Mon, 11 Dec 2017 08:46:41 -0800 (PST) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2554A126DEE for ; Mon, 11 Dec 2017 08:46:41 -0800 (PST) Received: by mail-it0-x229.google.com with SMTP id b5so17380405itc.3 for ; Mon, 11 Dec 2017 08:46:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=61ahkD6XBa1qeNOQdHwak6zI+SQsPPzytHkZ94sgThg=; b=YBZ9+QrH/1vJzTl3ogP4k1YIh4US526y2V0WkmeeQVIVCuHHds4mwQO1i3AhZJUU5q nHMRYmrMvapkDPfqESaD5ebFmJQ+jAb6P5vHROUIpvdl+2RAHcP51+Ji0ijTYDqrT38M T0SINBQ1LB2xXquILIgD+Xq+iEwJB/GuhlX9g= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=61ahkD6XBa1qeNOQdHwak6zI+SQsPPzytHkZ94sgThg=; b=E6c0FMg3trTrAUEgtpO+BVGNtay0kBgoI9emAwDHqUuDKSzKugOIzJ32EmFEmClR/R aSs6d1gJwC2LyAcx8OwYqt+sdD7aOqhHt2qevOYI+S7HqXLEWb1e7tcOSztGWpAGbTFd 0cfMB5ZvFF1/VLI1BeX23wR4z675qO+W9BdQ9nkQ4Oop8TBxrRq8ZEmBs+noTq64OnUA Rbzn7Kx6osa0OOhoQiP4Zob6KbGXfGoM4tF3xmA6uzB7ChO4MN67Z0LST3Fyd2uwAlJ9 2U4HQsxYXdeCnIZk24B7G4D5iJKgYUms/l+n7GTczdYrX/93knfJVgJD5EfMzisbb8mw e5Qw== X-Gm-Message-State: AKGB3mKY1gQi4Ms1scUjDG2FGaD1bo6HGJOPs4NM29LEKj1Yyhax7l7i SzT8KNZFFL3iqVboJOQmTju0YqGxsOigvoitxV4VMh5SlISmu1lWsKow/tsbpKH9Ozl6XlePxJG NXhxEaeoQY01SNg== X-Google-Smtp-Source: ACJfBouXagJetRzHuLGz/q1sUdTVE9Pb4M0iJ70jBJ6zOpmU8ZQsIY84eLKM2nLwqGvcyPJ/SclNcpU+6U9O8/LmuQ8= X-Received: by 10.36.44.197 with SMTP id i188mr1882358iti.40.1513010800170; Mon, 11 Dec 2017 08:46:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.2.118.194 with HTTP; Mon, 11 Dec 2017 08:46:09 -0800 (PST) In-Reply-To: References: From: Brian Campbell Date: Mon, 11 Dec 2017 09:46:09 -0700 Message-ID: To: Rifaat Shekh-Yusef Cc: oauth Content-Type: multipart/alternative; boundary="001a1143d3304beb8d056013474d" Archived-At: Subject: Re: [OAUTH-WG] WGLC for OAuth 2.0 Device Flow for Browserless and Input Constrained Devices X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Dec 2017 16:46:43 -0000 --001a1143d3304beb8d056013474d Content-Type: text/plain; charset="UTF-8" I couldn't get the QR code to work... ;) On Mon, Nov 27, 2017 at 6:55 AM, Rifaat Shekh-Yusef wrote: > All, > > As discussed in Singapore, we are starting a WGLC for the > *draft-ietf-oauth-device-flow-07* document, starting today and ending on > December 11, 2018. > https://datatracker.ietf.org/doc/draft-ietf-oauth-device-flow/ > > Please, review the document and provide feedback on the list. > > Regards, > Rifaat & Hannes > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > -- *CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.* --001a1143d3304beb8d056013474d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I couldn't get the QR code to work... ;)

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

As discussed in Singapore, we are starting a WGLC for the=C2=A0dr= aft-ietf-oauth-device-flow-07 document, starting today and ending = on December 11, 2018.

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

Regards,
=C2=A0Rifaat & Hannes


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



<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --001a1143d3304beb8d056013474d-- From nobody Mon Dec 11 09:56:36 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73B12127BA3 for ; Mon, 11 Dec 2017 09:56:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.19 X-Spam-Level: X-Spam-Status: No, score=-4.19 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_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zjFwFSY8s5Fi for ; Mon, 11 Dec 2017 09:56:31 -0800 (PST) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B5861271FD for ; Mon, 11 Dec 2017 09:56:30 -0800 (PST) X-AuditID: 1209190d-b65ff70000007ce7-bb-5a2ec6cc5ef1 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 87.86.31975.CC6CE2A5; Mon, 11 Dec 2017 12:56:29 -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 vBBHuOeJ012136; Mon, 11 Dec 2017 12:56:25 -0500 Received: from [192.168.1.9] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id vBBHuLSP019509 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 11 Dec 2017 12:56:23 -0500 From: Justin Richer Message-Id: <94AA427C-744B-4A33-AEFC-A5F276C911A2@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_33D54241-FB8A-4A09-AD6F-72B13AF05A17" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 11 Dec 2017 12:56:21 -0500 In-Reply-To: Cc: Denis , "" To: Brian Campbell References: <151208615408.11802.12175452260900272912@ietfa.amsl.com> <9e362874-54d3-ae73-2e77-fc0eb3a98e3b@free.fr> X-Mailer: Apple Mail (2.3273) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHKsWRmVeSWpSXmKPExsUixG6nonv2mF6Uwbt1Ahar/99ktFjfZWdx 8u0rNgdmj/51n1k9liz5yeRx9+hFlgDmKC6blNSczLLUIn27BK6Mk0+eMRX0tzFVTPuwmamB se0xYxcjJ4eEgInExfcH2boYuTiEBBYzSTy5voMdwtnIKNH8p4kVwrnGJLHi2DlmkBY2AVWJ 6WtamEBsXgEriRdPtrCB2MwCSRLvrzQCxTmA4voSvc/BNggLeEm8PNHCCmKzALVunLQPLM4p EChx/Ng1RohWZ4k9E+aCjREBar39dA47iC0k0M4scWNGIMSlshK3Zl9insDIPwvJtlkI2yDC 2hLLFr5mhrA1JfZ3L2fBFNeQ6Pw2kXUBI9sqRtmU3Crd3MTMnOLUZN3i5MS8vNQiXSO93MwS vdSU0k2MoGDnlOTdwfjvrtchRgEORiUe3ogOvSgh1sSy4srcQ4ySHExKorwswUAhvqT8lMqM xOKM+KLSnNTiQ4wSHMxKIrymfrpRQrwpiZVVqUX5MClpDhYlcV53E+0oIYH0xJLU7NTUgtQi mKwMB4eSBO/xo0BDBYtS01Mr0jJzShDSTBycIMN5gIb/A6nhLS5IzC3OTIfIn2IM5HjScuMP E8eGm3eB5D4wueH7AyD5bObrBmaOaVdbm5g55h3/1sQsxJKXn5cqJc67GWSQAMigjNI8uF2g ZOe+zs7iFaM40OvCvA7A1CfEA0yUcNteAR3CBHQI02RtkENKEhFSUg2MSnt3JUoWP1a6W7px 7vefmzrc+uLvr1Sz4/p7WlP0jfFJGb89H5tDdXXvMbg+3fb55okZ2/kin/wT17zIrjb3q8Ha 6k1vxfMe3A69dOp/U9qFBLUPm/ee77/7Q7R42o8nB0QT/Hb7z46xyfZezdF2m/Wa1c4Y8UUK 33LelaY27YvcfKqEQWZ/jxJLcUaioRZzUXEiAJsSd8dRAwAA Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchange-10.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Dec 2017 17:56:34 -0000 --Apple-Mail=_33D54241-FB8A-4A09-AD6F-72B13AF05A17 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 +1 to Brian -1 to the proposed text from Denis > On Dec 8, 2017, at 8:48 PM, Brian Campbell = wrote: >=20 > The privacy matter is already mentioned. Despite your many messages to = this WG and others about the so called ABC attack, I do not believe it = warrants treatment in this document or others. And your continued = proposals to have it included in documents have not gotten support. =20 >=20 > On Fri, Dec 8, 2017 at 2:46 PM, Denis > wrote: > RFC 3552 (Guidelines for Writing RFC Text on Security Considerations) = states:=20 >=20 > All RFCs are required by RFC 2223 to contain a Security > Considerations section. The purpose of this is both to encourage > document authors to consider security in their designs and to = inform > the reader of relevant security issues. This memo is intended to > provide guidance to RFC authors in service of both ends. >=20 > Section 5 (Writing Security Considerations Sections) of RFC 3552 = states:=20 >=20 > While it is not a requirement that any given protocol or system be > immune to all forms of attack, it is still necessary for authors to > consider as many forms as possible. Part of the purpose of the > Security Considerations section is to explain what attacks are out = of > scope and what countermeasures can be applied to defend against = them=20 >=20 > There should be a clear description of the kinds of threats on the > described protocol or technology. =20 >=20 > It is important to mention the threat related to collusion attacks. A = different wording could be used,=20 > but the threat should be mentioned one way or another. >=20 > RFC 6973 (Privacy Considerations for Internet Protocols) intends to = provide a similar set of guidelines=20 > for considering privacy in protocol design. >=20 > It is important to mention a current threat related to privacy. A = different wording could be used,=20 > e.g. using the word "surveillance" as mentioned in 5.1.1 : = "Surveillance is the observation or monitoring=20 > of an individual=E2=80=99s communications or activities", but the = threat should be mentioned one way or another. >=20 > Denis >=20 >> I believe the text would detract from the document.=20 >> From: OAuth = on behalf of Brian Campbell = >> Sent: Friday, December 8, 2017 3:47:32 PM >> To: Denis >> Cc: oauth >> Subject: Re: [OAUTH-WG] I-D Action: = draft-ietf-oauth-token-exchange-10.txt >> =20 >> As an individual, I do not believe that the proposed text should be = incorporated into the draft. >>=20 >> As one of the document editors, my responsibility is for the document = to be of reasonable quality and to reflect the rough consensus of this = Working Group. So I should ask the list more explicitly - are there = other WG remembers who are in favor of the proposed text here (the text = would have to be fixed up some too)?=20 >>=20 >> On Fri, Dec 1, 2017 at 11:12 AM, Denis > wrote: >> Comments on draft-ietf-oauth-token-exchange-10 >>=20 >> I propose the following rephrasing for sections 6 and 7: >>=20 >> 6 . Security Considerations >>=20 >> All of the normal security issues that are discussed in = [JWT],especially in relationship to comparing URIs=20 >> and dealing with unrecognized values, also apply here. In addition, = both delegation and impersonation introduce=20 >> unique security issues. Any time one user receives a token, the = potential for abuse is a concern,=20 >> since that user might be willing to collude with another user so that = other user could use the token.=20 >> =20 >> Techniques like the binding of an access token to a TLS channel = described elsewhere are ineffective since=20 >> the legitimate user would be able to perform all the cryptographic = computations that the other user would need=20 >> to demonstrate the ownership of the token. The use of the "scp" claim = is suggested to mitigate potential for=20 >> such abuse, as it restricts the contexts in which the token can be = exercised. If the issued access token scope=20 >> allows to unambiguously identify the user, then that user is likely = to be reluctant to collude with another user. =20 >> However, if the issued access token scope only indicates that the = user is over 18, then there is no risk=20 >> for the original user to be discovered and in such a context a = collusion may easily take place.=20 >> This document does not specify techniques to prevent such a collusion = to be successful. >>=20 >> 7 . Privacy Considerations >>=20 >> Tokens typically carry personal information and their usage in Token = Exchange may reveal details of the target services=20 >> being accessed. The resource and the audience parameters allow = authorization servers to know where the issued access token=20 >> will be used. This may be a privacy concern for some users. This = document does not specify techniques to prevent=20 >> authorization servers to know where the access tokens they issue will = be used. >>=20 >> Denis >>> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >>> This draft is a work item of the Web Authorization Protocol WG of = the IETF. >>>=20 >>> Title : OAuth 2.0 Token Exchange >>> Authors : Michael B. Jones >>> Anthony Nadalin >>> Brian Campbell >>> John Bradley >>> Chuck Mortimore >>> Filename : draft-ietf-oauth-token-exchange-10.txt >>> Pages : 32 >>> Date : 2017-11-30 >>>=20 >>> Abstract: >>> This specification defines a protocol for an HTTP- and JSON- = based >>> Security Token Service (STS) by defining how to request and = obtain >>> security tokens from OAuth 2.0 authorization servers, including >>> security tokens employing impersonation and delegation. >>>=20 >>>=20 >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/ = >>>=20 >>> There are also htmlized versions available at: >>> https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-10 = >>> = https://datatracker.ietf.org/doc/html/draft-ietf-oauth-token-exchange-10 = = >>>=20 >>> A diff from the previous version is available at: >>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-token-exchange-10= >>>=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 = >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = >>=20 >>=20 >>=20 >> CONFIDENTIALITY NOTICE: This email may contain confidential and = privileged material for the sole use of the intended recipient(s). Any = review, use, distribution or disclosure by others is strictly = prohibited. If you have received this communication in error, please = notify the sender immediately by e-mail and delete the message and any = file attachments from your computer. Thank you. >=20 >=20 >=20 > CONFIDENTIALITY NOTICE: This email may contain confidential and = privileged material for the sole use of the intended recipient(s). Any = review, use, distribution or disclosure by others is strictly = prohibited. If you have received this communication in error, please = notify the sender immediately by e-mail and delete the message and any = file attachments from your computer. Thank = you._______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = --Apple-Mail=_33D54241-FB8A-4A09-AD6F-72B13AF05A17 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 +1 to Brian

-1 to the proposed text from Denis


On Dec 8, 2017, at 8:48 PM, = Brian Campbell <bcampbell@pingidentity.com> wrote:

The= privacy matter is already mentioned. Despite your many messages to this = WG and others about the so called ABC attack, I do not believe it = warrants treatment in this document or others. And your continued = proposals to have it included in documents have not gotten = support.  

On Fri, Dec 8, 2017 at 2:46 PM, Denis <denis.ietf@free.fr> wrote:

RFC 3552 (Guidelines for Writing RFC Text on Security = Considerations) states: 

   All RFCs are = required by RFC 2223 to contain a Security
   Considerations = section.  The purpose of this = is both to encourage
   document authors to consider security in = their designs and to inform
   the reader of = relevant security issues.  This memo is = intended to
   provide guidance to = RFC authors in service of both ends.

Section 5 (Writing Security Considerations Sections) of RFC = 3552 states: 

   While it is not a = requirement that any given protocol or system be
   immune to all forms = of attack, it is still necessary for authors to
   consider as many = forms as possible.  Part of the purpose = of the
   Security = Considerations section is to explain what attacks are out of
   scope and what = countermeasures can be applied to defend against them 

   There should be a = clear description of the kinds of threats on the
   described protocol = or technology.  

It is important to mention the = threat related to collusion attacks. A different wording could be = used, 
but= the threat should be mentioned one way or = another.

RFC 6973 = (Privacy Considerations for Internet Protocols) intends to provide a = similar set of guidelines 
for = considering privacy in protocol design.

It is important to mention a current = threat related to privacy. A different wording could be used, 
e.g. using = the word "surveillance" as mentioned in 5.1.1 : "Surveillance is the = observation or monitoring 
of an = individual=E2=80=99s communications or activities", but the threat = should be mentioned one way or another.

Denis

I believe the text would = detract from the document. 
From: OAuth <oauth-bounces@ietf.org> on behalf of Brian = Campbell <bcampbell@pingidentity.com>
Sent: Friday, December 8, 2017 = 3:47:32 PM
To: Denis
Cc: oauth
Subject: Re: [OAUTH-WG] I-D Action: = draft-ietf-oauth-token-exchange-10.txt
 
As an individual, I do not believe that the proposed text = should be incorporated into the draft.

As = one of the document editors, my responsibility is for the document to be = of reasonable quality and to reflect the rough consensus of this Working = Group. So I should ask the list more explicitly - are there other WG = remembers who are in favor of the proposed text here (the text would = have to be fixed up some too)? 

On Fri, = Dec 1, 2017 at 11:12 AM, Denis <denis.ietf@free.fr> wrote:

Comments on draft-ietf-oauth-token-exchange-10

I propose the following rephrasing for sections 6 and = 7:

6 = . Security Considerations

All of the normal security issues that are discussed = in [JWT],especially in relationship to comparing URIs 
and dealing = with unrecognized values, also apply here.  In addition, both = delegation and impersonation introduce 
unique = security issues. Any time one user receives a token, the potential for = abuse is a concern, 
since that user might be willing to collude with another user = so that other user could use the token. 
 
Techniques like the binding of an = access token to a TLS channel described elsewhere are ineffective = since 
the= legitimate user would be able to perform all the cryptographic = computations that the other user would need 
to = demonstrate the ownership of the token. The use of the "scp" claim is = suggested to mitigate potential for 
such abuse, = as it restricts the contexts in which the token can be = exercised.  If the issued access token scope 
allows to = unambiguously identify the user, then that user is likely to be = reluctant to collude with another user.  
However, if the issued access = token scope only indicates that the user is over 18, then there is no = risk 
for = the original user to be discovered and in such a context a collusion may = easily take place. 
This document does not specify techniques to prevent such a = collusion to be successful.

7 . Privacy Considerations

Tokens typically = carry personal information and their usage in Token Exchange may reveal = details of the target services 
being = accessed. The resource and the audience parameters allow authorization = servers to know where the issued access token 
will be = used.  This may be a privacy concern for some users. = This document does not specify techniques to prevent 
authorization = servers to know where the access tokens they issue will be = used.

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

        Title           : OAuth 2.0 Token Exchange
        Authors         : Michael B. Jones
                          Anthony Nadalin
                          Brian Campbell
                          John Bradley
                          Chuck Mortimore
	Filename        : draft-ietf-oauth-token-exchange-10.txt
	Pages           : 32
	Date            : 2017-11-30

Abstract:
   This specification defines a protocol for an HTTP- and JSON- based
   Security Token Service (STS) by defining how to request and obtain
   security tokens from OAuth 2.0 authorization servers, including
   security tokens employing impersonation and delegation.


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

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

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


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

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

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



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



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




CONFIDENTIALITY NOTICE: = This email may contain confidential and privileged material for the sole = use of the intended recipient(s). Any review, use, distribution or = disclosure by others is strictly prohibited.  If you have received = this communication in error, please notify the sender immediately by = e-mail and delete the message and any file attachments from your = computer. Thank you._______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

= --Apple-Mail=_33D54241-FB8A-4A09-AD6F-72B13AF05A17-- From nobody Mon Dec 11 12:19:14 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61AA01288A9 for ; Mon, 11 Dec 2017 12:19:13 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31UrPRXU3uF2 for ; Mon, 11 Dec 2017 12:19:10 -0800 (PST) Received: from SMTPGATE01.enterexchange.com (smtpgate01.enterexchange.com [109.205.192.241]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D81A128799 for ; Mon, 11 Dec 2017 12:19:09 -0800 (PST) From: Jaap Francke To: "oauth@ietf.org" Thread-Topic: WGLC for OAuth 2.0 Device Flow for Browserless and Input Constrained Devices (Brian Campbell) Thread-Index: AQHTcr1LWw+9OJo3D02VMQW5q6baWA== Date: Mon, 11 Dec 2017 20:19:06 +0000 Message-ID: References: In-Reply-To: Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.17.5.138] Content-Type: text/plain; charset="utf-8" Content-ID: <971CB06F15230648B4EA443CF5414D7E@enterexchange.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] WGLC for OAuth 2.0 Device Flow for Browserless and Input Constrained Devices (Brian Campbell) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Dec 2017 20:19:13 -0000 SGkgYWxsLA0KDQpJIGhhdmUgcHJldmlvdXNseSBtYWRlIHRoZSBmb2xsb3dpbmcgc3VnZ2VzdGlv biB3aGljaCBzdGlsbCBtYWtlcyBzZW5zZSB0byBtZS4NCg0KW+KApl13ZSB3ZXJlIHdvcmtpbmcg d2l0aCBvbmUgb2Ygb3VyIGN1c3RvbWVycyB0byBpbXBsZW1lbnQgdGhlIGRldmljZSBmbG93IGFz IHBhcnQgb2Ygb3VyIElEYWFTLg0KT25lIG9mIHRoZSByZXF1aXJlbWVudHMgd2FzIHRoZSBhYmls aXR5IHRvIHJldm9rZSB0b2tlbnMgZm9yIG9uZSBvZiB0aGUgZGV2aWNlcyBhdCB0aGUgUmVzb3Vy Y2UgU2VydmVyLg0KDQpJbiBvdXIgdXNlIGNhc2UsIHdlIHVzZWQgdGhlIHRlcm1pbm9sZ3kg4oCY cGFpcmluZyBhIGRldmljZSB0byB0aGUgZW5kdXNlcuKAmXMgYWNjb3VudOKAmSB0byBkZXNjcmli ZSB0aGUgcHJvY2VzcyBvZiBhdXRob3Jpc2luZyBhIGRldmljZSB0byBhY2Nlc3MgdGhlIHJlc291 cmNlIG93bmVy4oCZcyByZXNvdXJjZXMuDQpUaGUgcmVzb3VyY2Ugb3duZXIgbWF5IHdhbnQgdG8g 4oCYdW5wYWly4oCZIGEgZGV2aWNlIGZyb20gYSBsaXN0IG9mIHBhaXJlZCBkZXZpY2VzIHdpdGhv dXQgaGF2aW5nIGFjY2VzcyB0byB0aGUgZGV2aWNlIGl0c2VsZiAoYW55bW9yZSkuIFRoaW5rIGFi b3V0IGEgc3RvbGVuL2xvc3Qga2luZCBvZiBzaXR1YXRpb24uDQpXZSBhcmUgbG9va2luZyBmb3Ig d2F5cyB0byBhbGxvdyB0aGUgdXNlciB0byB1bnBhaXIgb25lIG9mIGhpcyBkZXZpY2VzIGF0IHRo ZSBBdXRob3Jpc2F0aW9uIFNlcnZlci4NClNpbmNlIHRoZSBEZXZpY2UgRmxvdyBleGNoYW5nZXMg b25seSB0aGUg4oCYZ2VuZXJpY+KAmSBjbGllbnRfaWQgd2l0aCB0aGUgQXV0aG9yaXNhdGlvbiBT ZXJ2ZXIsIHRoZXJlIGlzIG5vIGxvZ2ljYWwgd2F5IGF0IHRoZSBSZXNvdXJjZSBTZXJ2ZXIgdG8g bWFrZSBhIGRpc3RpbmN0aW9uIGJldHdlZW4gdmFyaW91cyBkZXZpY2VzIChoYXZpbmcgdGhlIHNh bWUgY2xpZW50X2lkKSB0aGF0IG1heSBiZSBwYWlyZWQgdG8gdGhlIHNhbWUgUmVzb3VyY2UgT3du ZXIuDQoNCk15IHN1Z2dlc3Rpb24gaXMgdGhlIGZvbGxvd2luZw0KLSBhZGQgYW4gb3B0aW9uYWwg cGFyYW1ldGVyIHRvIHRoZSBkZXZpY2UgYXV0aG9yaXNhdGlvbiByZXF1ZXN0IChvciBkZXZpY2Ug YWNjZXNzIHRva2VuIHJlcXVlc3QpOiAnZGV2aWNlX2lkZW50aWZpZXInLiBBIGRldmljZSBjYW4g dXNlIHRoaXMgdG8gbWFrZSAoZm9yIGV4YW1wbGUpIGl0cyBzZXJpYWwtbnVtYmVyIGtub3duIGF0 IHRoZSBSZXNvdXJjZSBTZXJ2ZXIuDQotIGFkZCBhbiBvcHRpb25hbCBwYXJhbWV0ZXIgdG8gdGhl IGRldmljZSBhY2Nlc3MgdG9rZW4gcmVzcG9uc2UgdGhhdCBhbGxvd3MgdG8gY29tbXVuaWNhdGUg YSBuYW1lIGZvciB0aGUgZGV2aWNlIGFzIG1heSBoYXZlIGJlZW4gZ2l2ZW4gdG8gaXQgYnkgdGhl IHJlc291cmNlIG93bmVyIHdoaWxlIGFsbG93aW5nIHRoZSBjbGllbnRzIGFjY2VzcyAoRSkuIFRo aXMgcGFyYW1ldGVyIGNvdWxkIGJlIHNvbWV0aGluZyBsaWtlIOKAmGRldmljZV9uYW1l4oCZLiBU aGUgZGV2aWNlIG1heSBiZSBhYmxlIHRvIGRpc3BsYXkgdGhpcyDigJhkZXZpY2VfbmFtZeKAmSBv biBpdHMgZGlzcGxheS4NCg0KUGxlYXNlIGNvbnNpZGVyIHRoaXMgYXMgYSBzdWdnZXN0ZWQgZW5o YW5jZW1lbnQgb2YgdGhlIERldmljZSBGbG93IHNwZWNpZmljYXRpb25zLg0KDQoNCktpbmQgcmVn YXJkcywNCg0KSmFhcA0KPiBPbiAxMSBEZWMgMjAxNywgYXQgMTg6NTYsIG9hdXRoLXJlcXVlc3RA aWV0Zi5vcmcgd3JvdGU6DQo+IA0KPiBTZW5kIE9BdXRoIG1haWxpbmcgbGlzdCBzdWJtaXNzaW9u cyB0bw0KPiAJb2F1dGhAaWV0Zi5vcmcNCj4gDQo+IFRvIHN1YnNjcmliZSBvciB1bnN1YnNjcmli ZSB2aWEgdGhlIFdvcmxkIFdpZGUgV2ViLCB2aXNpdA0KPiAJaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9vYXV0aA0KPiBvciwgdmlhIGVtYWlsLCBzZW5kIGEgbWVzc2FnZSB3 aXRoIHN1YmplY3Qgb3IgYm9keSAnaGVscCcgdG8NCj4gCW9hdXRoLXJlcXVlc3RAaWV0Zi5vcmcN Cj4gDQo+IFlvdSBjYW4gcmVhY2ggdGhlIHBlcnNvbiBtYW5hZ2luZyB0aGUgbGlzdCBhdA0KPiAJ b2F1dGgtb3duZXJAaWV0Zi5vcmcNCj4gDQo+IFdoZW4gcmVwbHlpbmcsIHBsZWFzZSBlZGl0IHlv dXIgU3ViamVjdCBsaW5lIHNvIGl0IGlzIG1vcmUgc3BlY2lmaWMNCj4gdGhhbiAiUmU6IENvbnRl bnRzIG9mIE9BdXRoIGRpZ2VzdC4uLiINCj4gDQo+IA0KPiBUb2RheSdzIFRvcGljczoNCj4gDQo+ ICAgMS4gUmU6IFdHTEMgZm9yIE9BdXRoIDIuMCBEZXZpY2UgRmxvdyBmb3IgQnJvd3Nlcmxlc3Mg YW5kIElucHV0DQo+ICAgICAgQ29uc3RyYWluZWQgRGV2aWNlcyAoQnJpYW4gQ2FtcGJlbGwpDQo+ ICAgMi4gUmU6IEktRCBBY3Rpb246IGRyYWZ0LWlldGYtb2F1dGgtdG9rZW4tZXhjaGFuZ2UtMTAu dHh0DQo+ICAgICAgKEp1c3RpbiBSaWNoZXIpDQo+IA0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAN Cj4gTWVzc2FnZTogMQ0KPiBEYXRlOiBNb24sIDExIERlYyAyMDE3IDA5OjQ2OjA5IC0wNzAwDQo+ IEZyb206IEJyaWFuIENhbXBiZWxsIDxiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbT4NCj4gVG86 IFJpZmFhdCBTaGVraC1ZdXNlZiA8cmlmYWF0LmlldGZAZ21haWwuY29tPg0KPiBDYzogb2F1dGgg PG9hdXRoQGlldGYub3JnPg0KPiBTdWJqZWN0OiBSZTogW09BVVRILVdHXSBXR0xDIGZvciBPQXV0 aCAyLjAgRGV2aWNlIEZsb3cgZm9yIEJyb3dzZXJsZXNzDQo+IAlhbmQgSW5wdXQgQ29uc3RyYWlu ZWQgRGV2aWNlcw0KPiBNZXNzYWdlLUlEOg0KPiAJPENBK2szZUNSelRlMlh0X04tOW13c25jNFdD ZHlXbzNVVFJlPVVVbnpjZ2lkR3BxbVdfQUBtYWlsLmdtYWlsLmNvbT4NCj4gQ29udGVudC1UeXBl OiB0ZXh0L3BsYWluOyBjaGFyc2V0PSJ1dGYtOCINCj4gDQo+IEkgY291bGRuJ3QgZ2V0IHRoZSBR UiBjb2RlIHRvIHdvcmsuLi4gOykNCj4gDQo+IE9uIE1vbiwgTm92IDI3LCAyMDE3IGF0IDY6NTUg QU0sIFJpZmFhdCBTaGVraC1ZdXNlZiA8cmlmYWF0LmlldGZAZ21haWwuY29tPg0KPiB3cm90ZToN Cj4gDQo+PiBBbGwsDQo+PiANCj4+IEFzIGRpc2N1c3NlZCBpbiBTaW5nYXBvcmUsIHdlIGFyZSBz dGFydGluZyBhIFdHTEMgZm9yIHRoZQ0KPj4gKmRyYWZ0LWlldGYtb2F1dGgtZGV2aWNlLWZsb3ct MDcqIGRvY3VtZW50LCBzdGFydGluZyB0b2RheSBhbmQgZW5kaW5nIG9uDQo+PiBEZWNlbWJlciAx MSwgMjAxOC4NCj4+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYt b2F1dGgtZGV2aWNlLWZsb3cvDQo+PiANCj4+IFBsZWFzZSwgcmV2aWV3IHRoZSBkb2N1bWVudCBh bmQgcHJvdmlkZSBmZWVkYmFjayBvbiB0aGUgbGlzdC4NCj4+IA0KPj4gUmVnYXJkcywNCj4+IFJp ZmFhdCAmIEhhbm5lcw0KPj4gDQo+PiANCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+PiBPQXV0aCBtYWlsaW5nIGxpc3QNCj4+IE9BdXRoQGlldGYu b3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQo+PiAN Cj4+IA0KPiANCj4gLS0gDQo+ICpDT05GSURFTlRJQUxJVFkgTk9USUNFOiBUaGlzIGVtYWlsIG1h eSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJpdmlsZWdlZCANCj4gbWF0ZXJpYWwgZm9yIHRo ZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMpLiBBbnkgcmV2aWV3LCB1c2Us IA0KPiBkaXN0cmlidXRpb24gb3IgZGlzY2xvc3VyZSBieSBvdGhlcnMgaXMgc3RyaWN0bHkgcHJv aGliaXRlZC4gIElmIHlvdSBoYXZlIA0KPiByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4g ZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSANCj4gYnkgZS1tYWls IGFuZCBkZWxldGUgdGhlIG1lc3NhZ2UgYW5kIGFueSBmaWxlIGF0dGFjaG1lbnRzIGZyb20geW91 ciANCj4gY29tcHV0ZXIuIFRoYW5rIHlvdS4qDQo+IC0tLS0tLS0tLS0tLS0tIG5leHQgcGFydCAt LS0tLS0tLS0tLS0tLQ0KPiBBbiBIVE1MIGF0dGFjaG1lbnQgd2FzIHNjcnViYmVkLi4uDQo+IFVS TDogPGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9icm93c2Uvb2F1dGgvYXR0YWNo bWVudHMvMjAxNzEyMTEvMTE5YzYxNGMvYXR0YWNobWVudC5odG1sPg0KPiANCj4gLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IA0KPiBNZXNzYWdlOiAyDQo+IERhdGU6IE1vbiwgMTEg RGVjIDIwMTcgMTI6NTY6MjEgLTA1MDANCj4gRnJvbTogSnVzdGluIFJpY2hlciA8anJpY2hlckBt aXQuZWR1Pg0KPiBUbzogQnJpYW4gQ2FtcGJlbGwgPGJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29t Pg0KPiBDYzogRGVuaXMgPGRlbmlzLmlldGZAZnJlZS5mcj4sICI8b2F1dGhAaWV0Zi5vcmc+IiA8 b2F1dGhAaWV0Zi5vcmc+DQo+IFN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIEktRCBBY3Rpb246DQo+ IAlkcmFmdC1pZXRmLW9hdXRoLXRva2VuLWV4Y2hhbmdlLTEwLnR4dA0KPiBNZXNzYWdlLUlEOiA8 OTRBQTQyN0MtNzQ0Qi00QTMzLUFFRkMtQTVGMjc2QzkxMUEyQG1pdC5lZHU+DQo+IENvbnRlbnQt VHlwZTogdGV4dC9wbGFpbjsgY2hhcnNldD0idXRmLTgiDQo+IA0KPiArMSB0byBCcmlhbg0KPiAN Cj4gLTEgdG8gdGhlIHByb3Bvc2VkIHRleHQgZnJvbSBEZW5pcw0KPiANCj4gDQo+PiBPbiBEZWMg OCwgMjAxNywgYXQgODo0OCBQTSwgQnJpYW4gQ2FtcGJlbGwgPGJjYW1wYmVsbEBwaW5naWRlbnRp dHkuY29tPiB3cm90ZToNCj4+IA0KPj4gVGhlIHByaXZhY3kgbWF0dGVyIGlzIGFscmVhZHkgbWVu dGlvbmVkLiBEZXNwaXRlIHlvdXIgbWFueSBtZXNzYWdlcyB0byB0aGlzIFdHIGFuZCBvdGhlcnMg YWJvdXQgdGhlIHNvIGNhbGxlZCBBQkMgYXR0YWNrLCBJIGRvIG5vdCBiZWxpZXZlIGl0IHdhcnJh bnRzIHRyZWF0bWVudCBpbiB0aGlzIGRvY3VtZW50IG9yIG90aGVycy4gQW5kIHlvdXIgY29udGlu dWVkIHByb3Bvc2FscyB0byBoYXZlIGl0IGluY2x1ZGVkIGluIGRvY3VtZW50cyBoYXZlIG5vdCBn b3R0ZW4gc3VwcG9ydC4gIA0KPj4gDQo+PiBPbiBGcmksIERlYyA4LCAyMDE3IGF0IDI6NDYgUE0s IERlbmlzIDxkZW5pcy5pZXRmQGZyZWUuZnIgPG1haWx0bzpkZW5pcy5pZXRmQGZyZWUuZnI+PiB3 cm90ZToNCj4+IFJGQyAzNTUyIChHdWlkZWxpbmVzIGZvciBXcml0aW5nIFJGQyBUZXh0IG9uIFNl Y3VyaXR5IENvbnNpZGVyYXRpb25zKSBzdGF0ZXM6IA0KPj4gDQo+PiAgIEFsbCBSRkNzIGFyZSBy ZXF1aXJlZCBieSBSRkMgMjIyMyB0byBjb250YWluIGEgU2VjdXJpdHkNCj4+ICAgQ29uc2lkZXJh dGlvbnMgc2VjdGlvbi4gIFRoZSBwdXJwb3NlIG9mIHRoaXMgaXMgYm90aCB0byBlbmNvdXJhZ2UN Cj4+ICAgZG9jdW1lbnQgYXV0aG9ycyB0byBjb25zaWRlciBzZWN1cml0eSBpbiB0aGVpciBkZXNp Z25zIGFuZCB0byBpbmZvcm0NCj4+ICAgdGhlIHJlYWRlciBvZiByZWxldmFudCBzZWN1cml0eSBp c3N1ZXMuICBUaGlzIG1lbW8gaXMgaW50ZW5kZWQgdG8NCj4+ICAgcHJvdmlkZSBndWlkYW5jZSB0 byBSRkMgYXV0aG9ycyBpbiBzZXJ2aWNlIG9mIGJvdGggZW5kcy4NCj4+IA0KPj4gU2VjdGlvbiA1 IChXcml0aW5nIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIFNlY3Rpb25zKSBvZiBSRkMgMzU1MiBz dGF0ZXM6IA0KPj4gDQo+PiAgIFdoaWxlIGl0IGlzIG5vdCBhIHJlcXVpcmVtZW50IHRoYXQgYW55 IGdpdmVuIHByb3RvY29sIG9yIHN5c3RlbSBiZQ0KPj4gICBpbW11bmUgdG8gYWxsIGZvcm1zIG9m IGF0dGFjaywgaXQgaXMgc3RpbGwgbmVjZXNzYXJ5IGZvciBhdXRob3JzIHRvDQo+PiAgIGNvbnNp ZGVyIGFzIG1hbnkgZm9ybXMgYXMgcG9zc2libGUuICBQYXJ0IG9mIHRoZSBwdXJwb3NlIG9mIHRo ZQ0KPj4gICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBzZWN0aW9uIGlzIHRvIGV4cGxhaW4gd2hh dCBhdHRhY2tzIGFyZSBvdXQgb2YNCj4+ICAgc2NvcGUgYW5kIHdoYXQgY291bnRlcm1lYXN1cmVz IGNhbiBiZSBhcHBsaWVkIHRvIGRlZmVuZCBhZ2FpbnN0IHRoZW0gDQo+PiANCj4+ICAgVGhlcmUg c2hvdWxkIGJlIGEgY2xlYXIgZGVzY3JpcHRpb24gb2YgdGhlIGtpbmRzIG9mIHRocmVhdHMgb24g dGhlDQo+PiAgIGRlc2NyaWJlZCBwcm90b2NvbCBvciB0ZWNobm9sb2d5LiAgDQo+PiANCj4+IEl0 IGlzIGltcG9ydGFudCB0byBtZW50aW9uIHRoZSB0aHJlYXQgcmVsYXRlZCB0byBjb2xsdXNpb24g YXR0YWNrcy4gQSBkaWZmZXJlbnQgd29yZGluZyBjb3VsZCBiZSB1c2VkLCANCj4+IGJ1dCB0aGUg dGhyZWF0IHNob3VsZCBiZSBtZW50aW9uZWQgb25lIHdheSBvciBhbm90aGVyLg0KPj4gDQo+PiBS RkMgNjk3MyAoUHJpdmFjeSBDb25zaWRlcmF0aW9ucyBmb3IgSW50ZXJuZXQgUHJvdG9jb2xzKSBp bnRlbmRzIHRvIHByb3ZpZGUgYSBzaW1pbGFyIHNldCBvZiBndWlkZWxpbmVzIA0KPj4gZm9yIGNv bnNpZGVyaW5nIHByaXZhY3kgaW4gcHJvdG9jb2wgZGVzaWduLg0KPj4gDQo+PiBJdCBpcyBpbXBv cnRhbnQgdG8gbWVudGlvbiBhIGN1cnJlbnQgdGhyZWF0IHJlbGF0ZWQgdG8gcHJpdmFjeS4gQSBk aWZmZXJlbnQgd29yZGluZyBjb3VsZCBiZSB1c2VkLCANCj4+IGUuZy4gdXNpbmcgdGhlIHdvcmQg InN1cnZlaWxsYW5jZSIgYXMgbWVudGlvbmVkIGluIDUuMS4xIDogIlN1cnZlaWxsYW5jZSBpcyB0 aGUgb2JzZXJ2YXRpb24gb3IgbW9uaXRvcmluZyANCj4+IG9mIGFuIGluZGl2aWR1YWw/cyBjb21t dW5pY2F0aW9ucyBvciBhY3Rpdml0aWVzIiwgYnV0IHRoZSB0aHJlYXQgc2hvdWxkIGJlIG1lbnRp b25lZCBvbmUgd2F5IG9yIGFub3RoZXIuDQo+PiANCj4+IERlbmlzDQo+PiANCj4+PiBJIGJlbGll dmUgdGhlIHRleHQgd291bGQgZGV0cmFjdCBmcm9tIHRoZSBkb2N1bWVudC4gDQo+Pj4gRnJvbTog T0F1dGggPG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc+IDxtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRm Lm9yZz4gb24gYmVoYWxmIG9mIEJyaWFuIENhbXBiZWxsIDxiY2FtcGJlbGxAcGluZ2lkZW50aXR5 LmNvbT4gPG1haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbT4NCj4+PiBTZW50OiBGcmlk YXksIERlY2VtYmVyIDgsIDIwMTcgMzo0NzozMiBQTQ0KPj4+IFRvOiBEZW5pcw0KPj4+IENjOiBv YXV0aA0KPj4+IFN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIEktRCBBY3Rpb246IGRyYWZ0LWlldGYt b2F1dGgtdG9rZW4tZXhjaGFuZ2UtMTAudHh0DQo+Pj4gDQo+Pj4gQXMgYW4gaW5kaXZpZHVhbCwg SSBkbyBub3QgYmVsaWV2ZSB0aGF0IHRoZSBwcm9wb3NlZCB0ZXh0IHNob3VsZCBiZSBpbmNvcnBv cmF0ZWQgaW50byB0aGUgZHJhZnQuDQo+Pj4gDQo+Pj4gQXMgb25lIG9mIHRoZSBkb2N1bWVudCBl ZGl0b3JzLCBteSByZXNwb25zaWJpbGl0eSBpcyBmb3IgdGhlIGRvY3VtZW50IHRvIGJlIG9mIHJl YXNvbmFibGUgcXVhbGl0eSBhbmQgdG8gcmVmbGVjdCB0aGUgcm91Z2ggY29uc2Vuc3VzIG9mIHRo aXMgV29ya2luZyBHcm91cC4gU28gSSBzaG91bGQgYXNrIHRoZSBsaXN0IG1vcmUgZXhwbGljaXRs eSAtIGFyZSB0aGVyZSBvdGhlciBXRyByZW1lbWJlcnMgd2hvIGFyZSBpbiBmYXZvciBvZiB0aGUg cHJvcG9zZWQgdGV4dCBoZXJlICh0aGUgdGV4dCB3b3VsZCBoYXZlIHRvIGJlIGZpeGVkIHVwIHNv bWUgdG9vKT8gDQo+Pj4gDQo+Pj4gT24gRnJpLCBEZWMgMSwgMjAxNyBhdCAxMToxMiBBTSwgRGVu aXMgPGRlbmlzLmlldGZAZnJlZS5mciA8bWFpbHRvOmRlbmlzLmlldGZAZnJlZS5mcj4+IHdyb3Rl Og0KPj4+IENvbW1lbnRzIG9uIGRyYWZ0LWlldGYtb2F1dGgtdG9rZW4tZXhjaGFuZ2UtMTANCj4+ PiANCj4+PiBJIHByb3Bvc2UgdGhlIGZvbGxvd2luZyByZXBocmFzaW5nIGZvciBzZWN0aW9ucyA2 IGFuZCA3Og0KPj4+IA0KPj4+IDYgLiBTZWN1cml0eSBDb25zaWRlcmF0aW9ucw0KPj4+IA0KPj4+ IEFsbCBvZiB0aGUgbm9ybWFsIHNlY3VyaXR5IGlzc3VlcyB0aGF0IGFyZSBkaXNjdXNzZWQgaW4g W0pXVF0sZXNwZWNpYWxseSBpbiByZWxhdGlvbnNoaXAgdG8gY29tcGFyaW5nIFVSSXMgDQo+Pj4g YW5kIGRlYWxpbmcgd2l0aCB1bnJlY29nbml6ZWQgdmFsdWVzLCBhbHNvIGFwcGx5IGhlcmUuICBJ biBhZGRpdGlvbiwgYm90aCBkZWxlZ2F0aW9uIGFuZCBpbXBlcnNvbmF0aW9uIGludHJvZHVjZSAN Cj4+PiB1bmlxdWUgc2VjdXJpdHkgaXNzdWVzLiBBbnkgdGltZSBvbmUgdXNlciByZWNlaXZlcyBh IHRva2VuLCB0aGUgcG90ZW50aWFsIGZvciBhYnVzZSBpcyBhIGNvbmNlcm4sIA0KPj4+IHNpbmNl IHRoYXQgdXNlciBtaWdodCBiZSB3aWxsaW5nIHRvIGNvbGx1ZGUgd2l0aCBhbm90aGVyIHVzZXIg c28gdGhhdCBvdGhlciB1c2VyIGNvdWxkIHVzZSB0aGUgdG9rZW4uIA0KPj4+IA0KPj4+IFRlY2hu aXF1ZXMgbGlrZSB0aGUgYmluZGluZyBvZiBhbiBhY2Nlc3MgdG9rZW4gdG8gYSBUTFMgY2hhbm5l bCBkZXNjcmliZWQgZWxzZXdoZXJlIGFyZSBpbmVmZmVjdGl2ZSBzaW5jZSANCj4+PiB0aGUgbGVn aXRpbWF0ZSB1c2VyIHdvdWxkIGJlIGFibGUgdG8gcGVyZm9ybSBhbGwgdGhlIGNyeXB0b2dyYXBo aWMgY29tcHV0YXRpb25zIHRoYXQgdGhlIG90aGVyIHVzZXIgd291bGQgbmVlZCANCj4+PiB0byBk ZW1vbnN0cmF0ZSB0aGUgb3duZXJzaGlwIG9mIHRoZSB0b2tlbi4gVGhlIHVzZSBvZiB0aGUgInNj cCIgY2xhaW0gaXMgc3VnZ2VzdGVkIHRvIG1pdGlnYXRlIHBvdGVudGlhbCBmb3IgDQo+Pj4gc3Vj aCBhYnVzZSwgYXMgaXQgcmVzdHJpY3RzIHRoZSBjb250ZXh0cyBpbiB3aGljaCB0aGUgdG9rZW4g Y2FuIGJlIGV4ZXJjaXNlZC4gIElmIHRoZSBpc3N1ZWQgYWNjZXNzIHRva2VuIHNjb3BlIA0KPj4+ IGFsbG93cyB0byB1bmFtYmlndW91c2x5IGlkZW50aWZ5IHRoZSB1c2VyLCB0aGVuIHRoYXQgdXNl ciBpcyBsaWtlbHkgdG8gYmUgcmVsdWN0YW50IHRvIGNvbGx1ZGUgd2l0aCBhbm90aGVyIHVzZXIu ICANCj4+PiBIb3dldmVyLCBpZiB0aGUgaXNzdWVkIGFjY2VzcyB0b2tlbiBzY29wZSBvbmx5IGlu ZGljYXRlcyB0aGF0IHRoZSB1c2VyIGlzIG92ZXIgMTgsIHRoZW4gdGhlcmUgaXMgbm8gcmlzayAN Cj4+PiBmb3IgdGhlIG9yaWdpbmFsIHVzZXIgdG8gYmUgZGlzY292ZXJlZCBhbmQgaW4gc3VjaCBh IGNvbnRleHQgYSBjb2xsdXNpb24gbWF5IGVhc2lseSB0YWtlIHBsYWNlLiANCj4+PiBUaGlzIGRv Y3VtZW50IGRvZXMgbm90IHNwZWNpZnkgdGVjaG5pcXVlcyB0byBwcmV2ZW50IHN1Y2ggYSBjb2xs dXNpb24gdG8gYmUgc3VjY2Vzc2Z1bC4NCj4+PiANCj4+PiA3IC4gUHJpdmFjeSBDb25zaWRlcmF0 aW9ucw0KPj4+IA0KPj4+IFRva2VucyB0eXBpY2FsbHkgY2FycnkgcGVyc29uYWwgaW5mb3JtYXRp b24gYW5kIHRoZWlyIHVzYWdlIGluIFRva2VuIEV4Y2hhbmdlIG1heSByZXZlYWwgZGV0YWlscyBv ZiB0aGUgdGFyZ2V0IHNlcnZpY2VzIA0KPj4+IGJlaW5nIGFjY2Vzc2VkLiBUaGUgcmVzb3VyY2Ug YW5kIHRoZSBhdWRpZW5jZSBwYXJhbWV0ZXJzIGFsbG93IGF1dGhvcml6YXRpb24gc2VydmVycyB0 byBrbm93IHdoZXJlIHRoZSBpc3N1ZWQgYWNjZXNzIHRva2VuIA0KPj4+IHdpbGwgYmUgdXNlZC4g IFRoaXMgbWF5IGJlIGEgcHJpdmFjeSBjb25jZXJuIGZvciBzb21lIHVzZXJzLiBUaGlzIGRvY3Vt ZW50IGRvZXMgbm90IHNwZWNpZnkgdGVjaG5pcXVlcyB0byBwcmV2ZW50IA0KPj4+IGF1dGhvcml6 YXRpb24gc2VydmVycyB0byBrbm93IHdoZXJlIHRoZSBhY2Nlc3MgdG9rZW5zIHRoZXkgaXNzdWUg d2lsbCBiZSB1c2VkLg0KPj4+IA0KPj4+IERlbmlzDQo+Pj4+IEEgTmV3IEludGVybmV0LURyYWZ0 IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmll cy4NCj4+Pj4gVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgV2ViIEF1dGhvcml6YXRp b24gUHJvdG9jb2wgV0cgb2YgdGhlIElFVEYuDQo+Pj4+IA0KPj4+PiAgICAgICAgVGl0bGUgICAg ICAgICAgIDogT0F1dGggMi4wIFRva2VuIEV4Y2hhbmdlDQo+Pj4+ICAgICAgICBBdXRob3JzICAg ICAgICAgOiBNaWNoYWVsIEIuIEpvbmVzDQo+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICBB bnRob255IE5hZGFsaW4NCj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgIEJyaWFuIENhbXBi ZWxsDQo+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICBKb2huIEJyYWRsZXkNCj4+Pj4gICAg ICAgICAgICAgICAgICAgICAgICAgIENodWNrIE1vcnRpbW9yZQ0KPj4+PiAJRmlsZW5hbWUgICAg ICAgIDogZHJhZnQtaWV0Zi1vYXV0aC10b2tlbi1leGNoYW5nZS0xMC50eHQNCj4+Pj4gCVBhZ2Vz ICAgICAgICAgICA6IDMyDQo+Pj4+IAlEYXRlICAgICAgICAgICAgOiAyMDE3LTExLTMwDQo+Pj4+ IA0KPj4+PiBBYnN0cmFjdDoNCj4+Pj4gICBUaGlzIHNwZWNpZmljYXRpb24gZGVmaW5lcyBhIHBy b3RvY29sIGZvciBhbiBIVFRQLSBhbmQgSlNPTi0gYmFzZWQNCj4+Pj4gICBTZWN1cml0eSBUb2tl biBTZXJ2aWNlIChTVFMpIGJ5IGRlZmluaW5nIGhvdyB0byByZXF1ZXN0IGFuZCBvYnRhaW4NCj4+ Pj4gICBzZWN1cml0eSB0b2tlbnMgZnJvbSBPQXV0aCAyLjAgYXV0aG9yaXphdGlvbiBzZXJ2ZXJz LCBpbmNsdWRpbmcNCj4+Pj4gICBzZWN1cml0eSB0b2tlbnMgZW1wbG95aW5nIGltcGVyc29uYXRp b24gYW5kIGRlbGVnYXRpb24uDQo+Pj4+IA0KPj4+PiANCj4+Pj4gVGhlIElFVEYgZGF0YXRyYWNr ZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQo+Pj4+IGh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtb2F1dGgtdG9rZW4tZXhjaGFuZ2UvIDxodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW9hdXRoLXRva2VuLWV4Y2hhbmdl Lz4NCj4+Pj4gDQo+Pj4+IFRoZXJlIGFyZSBhbHNvIGh0bWxpemVkIHZlcnNpb25zIGF2YWlsYWJs ZSBhdDoNCj4+Pj4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgt dG9rZW4tZXhjaGFuZ2UtMTAgPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRm LW9hdXRoLXRva2VuLWV4Y2hhbmdlLTEwPg0KPj4+PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtdG9rZW4tZXhjaGFuZ2UtMTAgPGh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC10b2tlbi1leGNo YW5nZS0xMD4NCj4+Pj4gDQo+Pj4+IEEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlz IGF2YWlsYWJsZSBhdDoNCj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRy YWZ0LWlldGYtb2F1dGgtdG9rZW4tZXhjaGFuZ2UtMTAgPGh0dHBzOi8vd3d3LmlldGYub3JnL3Jm Y2RpZmY/dXJsMj1kcmFmdC1pZXRmLW9hdXRoLXRva2VuLWV4Y2hhbmdlLTEwPg0KPj4+PiANCj4+ Pj4gDQo+Pj4+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRl cyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCj4+Pj4gdW50aWwgdGhlIGh0bWxpemVkIHZl cnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZyA8aHR0cDovL3Rv b2xzLmlldGYub3JnLz4uDQo+Pj4+IA0KPj4+PiBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZh aWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQo+Pj4+IGZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRl cm5ldC1kcmFmdHMvIDxmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLz4NCj4+Pj4g DQo+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ Pj4+IE9BdXRoIG1haWxpbmcgbGlzdA0KPj4+PiBPQXV0aEBpZXRmLm9yZyA8bWFpbHRvOk9BdXRo QGlldGYub3JnPg0KPj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29h dXRoIDxodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPg0KPj4+IA0K Pj4+IA0KPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+Pj4gT0F1dGggbWFpbGluZyBsaXN0DQo+Pj4gT0F1dGhAaWV0Zi5vcmcgPG1haWx0bzpPQXV0 aEBpZXRmLm9yZz4NCj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29h dXRoIDxodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPg0KPj4+IA0K Pj4+IA0KPj4+IA0KPj4+IENPTkZJREVOVElBTElUWSBOT1RJQ0U6IFRoaXMgZW1haWwgbWF5IGNv bnRhaW4gY29uZmlkZW50aWFsIGFuZCBwcml2aWxlZ2VkIG1hdGVyaWFsIGZvciB0aGUgc29sZSB1 c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudChzKS4gQW55IHJldmlldywgdXNlLCBkaXN0cmli dXRpb24gb3IgZGlzY2xvc3VyZSBieSBvdGhlcnMgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gIElm IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciwgcGxlYXNlIG5v dGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGJ5IGUtbWFpbCBhbmQgZGVsZXRlIHRoZSBtZXNz YWdlIGFuZCBhbnkgZmlsZSBhdHRhY2htZW50cyBmcm9tIHlvdXIgY29tcHV0ZXIuIFRoYW5rIHlv dS4NCj4+IA0KPj4gDQo+PiANCj4+IENPTkZJREVOVElBTElUWSBOT1RJQ0U6IFRoaXMgZW1haWwg bWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZCBwcml2aWxlZ2VkIG1hdGVyaWFsIGZvciB0aGUg c29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudChzKS4gQW55IHJldmlldywgdXNlLCBk aXN0cmlidXRpb24gb3IgZGlzY2xvc3VyZSBieSBvdGhlcnMgaXMgc3RyaWN0bHkgcHJvaGliaXRl ZC4gIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciwgcGxl YXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGJ5IGUtbWFpbCBhbmQgZGVsZXRlIHRo ZSBtZXNzYWdlIGFuZCBhbnkgZmlsZSBhdHRhY2htZW50cyBmcm9tIHlvdXIgY29tcHV0ZXIuIFRo YW5rIHlvdS5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K Pj4gT0F1dGggbWFpbGluZyBsaXN0DQo+PiBPQXV0aEBpZXRmLm9yZyA8bWFpbHRvOk9BdXRoQGll dGYub3JnPg0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCA8 aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aD4NCj4gLS0tLS0tLS0t LS0tLS0gbmV4dCBwYXJ0IC0tLS0tLS0tLS0tLS0tDQo+IEFuIEhUTUwgYXR0YWNobWVudCB3YXMg c2NydWJiZWQuLi4NCj4gVVJMOiA8aHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL2Jy b3dzZS9vYXV0aC9hdHRhY2htZW50cy8yMDE3MTIxMS9kYmQyNDdmNi9hdHRhY2htZW50Lmh0bWw+ DQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gDQo+IFN1YmplY3Q6IERp Z2VzdCBGb290ZXINCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+IE9BdXRoIG1haWxpbmcgbGlzdA0KPiBPQXV0aEBpZXRmLm9yZw0KPiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQo+IA0KPiANCj4gLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IA0KPiBFbmQgb2YgT0F1dGggRGlnZXN0LCBWb2wg MTEwLCBJc3N1ZSA4DQo+ICoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCg0K From nobody Mon Dec 11 12:41:46 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 702981273B1 for ; Mon, 11 Dec 2017 12:41:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22o2o86a-ulH for ; Mon, 11 Dec 2017 12:41:42 -0800 (PST) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (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 062DB126D85 for ; Mon, 11 Dec 2017 12:41:41 -0800 (PST) X-AuditID: 12074425-8d9ff70000000e7d-a6-5a2eed81e60b 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-8.mit.edu (Symantec Messaging Gateway) with SMTP id 13.EB.03709.28DEE2A5; Mon, 11 Dec 2017 15:41:39 -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 vBBKfXVM015236; Mon, 11 Dec 2017 15:41:34 -0500 Received: from [192.168.1.9] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id vBBKfV0B016634 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 11 Dec 2017 15:41:32 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Justin Richer In-Reply-To: Date: Mon, 11 Dec 2017 15:41:30 -0500 Cc: "" Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Jaap Francke X-Mailer: Apple Mail (2.3273) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprIKsWRmVeSWpSXmKPExsUixG6nrtv8Vi/KYOtrZou2WU/YLU6+fcXm wOSxZMlPJo+rPx+wBzBFcdmkpOZklqUW6dslcGUsebCApeBFWcXHD5tYGhi/JXYxcnJICJhI 3Hrwl72LkYtDSGAxk8TjxzNZIJyNjBLvjpxlBakSErjGJLFqLpjNLKAu8WfeJeYuRg4OXgF9 id7njCBhYYFyib5tX1hAbDYBVYnpa1qYQGxOAQeJ9yemsYCUswDFW69EgJggU9pPukAM1JZY tvA1M4jNK2Al0fd8CStIiZBAvsTke/kgYREBHYkTB/4zQlwsK3Fr9iXmCYwCs5CcMwvhnFlI hi5gZF7FKJuSW6Wbm5iZU5yarFucnJiXl1qka6GXm1mil5pSuokRHJ4uqjsY5/z1OsQowMGo xMMb0aEXJcSaWFZcmXuIUZKDSUmUlyUYKMSXlJ9SmZFYnBFfVJqTWnyIUYKDWUmE19RPN0qI NyWxsiq1KB8mJc3BoiTO62GiHSUkkJ5YkpqdmlqQWgSTleHgUJLgnfAGaKhgUWp6akVaZk4J QpqJgxNkOA/Q8EaQGt7igsTc4sx0iPwpRm+OJy03/jBxXLp1F0hu+P4ASD6b+bqBmWPa1dYm Zo55x781MQux5OXnpUqJ8055DTRCAGRERmke3BZQSnJfZ2fxilEc6Glh3uUgi3iA6Qxuzyug E5iATmCarA1yQkkiQkqqgVHbfFf5qTTBbqeZGzk1tIt966qmz5J6Or/M6WHPxAVeX95+a3ip /3T52qWf+VILme9PFtn24OUfG4aiFqV6uyKrJtE7cR+/T96RO/VV/izJIslN30wv+D+fIlMS /c5s8Y3j4dMOfy7QfK2/TWOC7fT/Bb+3XTu6XnT1qtzZpmYXLhfeXPnWhC9GiaU4I9FQi7mo OBEANpw0FiQDAAA= Archived-At: Subject: Re: [OAUTH-WG] WGLC for OAuth 2.0 Device Flow for Browserless and Input Constrained Devices (Brian Campbell) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Dec 2017 20:41:45 -0000 This could be useful but shouldn=E2=80=99t be done in a way that=E2=80=99s= tied to the device flow =E2=80=94 any public client would suffer from = the same fate.=20 =E2=80=94 Justin > On Dec 11, 2017, at 3:19 PM, Jaap Francke = wrote: >=20 > Hi all, >=20 > I have previously made the following suggestion which still makes = sense to me. >=20 > [=E2=80=A6]we were working with one of our customers to implement the = device flow as part of our IDaaS. > One of the requirements was the ability to revoke tokens for one of = the devices at the Resource Server. >=20 > In our use case, we used the terminolgy =E2=80=98pairing a device to = the enduser=E2=80=99s account=E2=80=99 to describe the process of = authorising a device to access the resource owner=E2=80=99s resources. > The resource owner may want to =E2=80=98unpair=E2=80=99 a device from = a list of paired devices without having access to the device itself = (anymore). Think about a stolen/lost kind of situation. > We are looking for ways to allow the user to unpair one of his devices = at the Authorisation Server. > Since the Device Flow exchanges only the =E2=80=98generic=E2=80=99 = client_id with the Authorisation Server, there is no logical way at the = Resource Server to make a distinction between various devices (having = the same client_id) that may be paired to the same Resource Owner. >=20 > My suggestion is the following > - add an optional parameter to the device authorisation request (or = device access token request): 'device_identifier'. A device can use this = to make (for example) its serial-number known at the Resource Server. > - add an optional parameter to the device access token response that = allows to communicate a name for the device as may have been given to it = by the resource owner while allowing the clients access (E). This = parameter could be something like =E2=80=98device_name=E2=80=99. The = device may be able to display this =E2=80=98device_name=E2=80=99 on its = display. >=20 > Please consider this as a suggested enhancement of the Device Flow = specifications. >=20 >=20 > Kind regards, >=20 > Jaap >> On 11 Dec 2017, at 18:56, oauth-request@ietf.org wrote: >>=20 >> Send OAuth mailing list submissions to >> oauth@ietf.org >>=20 >> To subscribe or unsubscribe via the World Wide Web, visit >> https://www.ietf.org/mailman/listinfo/oauth >> or, via email, send a message with subject or body 'help' to >> oauth-request@ietf.org >>=20 >> You can reach the person managing the list at >> oauth-owner@ietf.org >>=20 >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of OAuth digest..." >>=20 >>=20 >> Today's Topics: >>=20 >> 1. Re: WGLC for OAuth 2.0 Device Flow for Browserless and Input >> Constrained Devices (Brian Campbell) >> 2. Re: I-D Action: draft-ietf-oauth-token-exchange-10.txt >> (Justin Richer) >>=20 >>=20 >> = ---------------------------------------------------------------------- >>=20 >> Message: 1 >> Date: Mon, 11 Dec 2017 09:46:09 -0700 >> From: Brian Campbell >> To: Rifaat Shekh-Yusef >> Cc: oauth >> Subject: Re: [OAUTH-WG] WGLC for OAuth 2.0 Device Flow for = Browserless >> and Input Constrained Devices >> Message-ID: >> = >> Content-Type: text/plain; charset=3D"utf-8" >>=20 >> I couldn't get the QR code to work... ;) >>=20 >> On Mon, Nov 27, 2017 at 6:55 AM, Rifaat Shekh-Yusef = >> wrote: >>=20 >>> All, >>>=20 >>> As discussed in Singapore, we are starting a WGLC for the >>> *draft-ietf-oauth-device-flow-07* document, starting today and = ending on >>> December 11, 2018. >>> https://datatracker.ietf.org/doc/draft-ietf-oauth-device-flow/ >>>=20 >>> Please, review the document and provide feedback on the list. >>>=20 >>> Regards, >>> Rifaat & Hannes >>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>>=20 >>=20 >> --=20 >> *CONFIDENTIALITY NOTICE: This email may contain confidential and = privileged=20 >> material for the sole use of the intended recipient(s). Any review, = use,=20 >> distribution or disclosure by others is strictly prohibited. If you = have=20 >> received this communication in error, please notify the sender = immediately=20 >> by e-mail and delete the message and any file attachments from your=20= >> computer. Thank you.* >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: = >>=20 >> ------------------------------ >>=20 >> Message: 2 >> Date: Mon, 11 Dec 2017 12:56:21 -0500 >> From: Justin Richer >> To: Brian Campbell >> Cc: Denis , "" >> Subject: Re: [OAUTH-WG] I-D Action: >> draft-ietf-oauth-token-exchange-10.txt >> Message-ID: <94AA427C-744B-4A33-AEFC-A5F276C911A2@mit.edu> >> Content-Type: text/plain; charset=3D"utf-8" >>=20 >> +1 to Brian >>=20 >> -1 to the proposed text from Denis >>=20 >>=20 >>> On Dec 8, 2017, at 8:48 PM, Brian Campbell = wrote: >>>=20 >>> The privacy matter is already mentioned. Despite your many messages = to this WG and others about the so called ABC attack, I do not believe = it warrants treatment in this document or others. And your continued = proposals to have it included in documents have not gotten support. =20 >>>=20 >>> On Fri, Dec 8, 2017 at 2:46 PM, Denis > wrote: >>> RFC 3552 (Guidelines for Writing RFC Text on Security = Considerations) states:=20 >>>=20 >>> All RFCs are required by RFC 2223 to contain a Security >>> Considerations section. The purpose of this is both to encourage >>> document authors to consider security in their designs and to = inform >>> the reader of relevant security issues. This memo is intended to >>> provide guidance to RFC authors in service of both ends. >>>=20 >>> Section 5 (Writing Security Considerations Sections) of RFC 3552 = states:=20 >>>=20 >>> While it is not a requirement that any given protocol or system be >>> immune to all forms of attack, it is still necessary for authors to >>> consider as many forms as possible. Part of the purpose of the >>> Security Considerations section is to explain what attacks are out = of >>> scope and what countermeasures can be applied to defend against = them=20 >>>=20 >>> There should be a clear description of the kinds of threats on the >>> described protocol or technology. =20 >>>=20 >>> It is important to mention the threat related to collusion attacks. = A different wording could be used,=20 >>> but the threat should be mentioned one way or another. >>>=20 >>> RFC 6973 (Privacy Considerations for Internet Protocols) intends to = provide a similar set of guidelines=20 >>> for considering privacy in protocol design. >>>=20 >>> It is important to mention a current threat related to privacy. A = different wording could be used,=20 >>> e.g. using the word "surveillance" as mentioned in 5.1.1 : = "Surveillance is the observation or monitoring=20 >>> of an individual?s communications or activities", but the threat = should be mentioned one way or another. >>>=20 >>> Denis >>>=20 >>>> I believe the text would detract from the document.=20 >>>> From: OAuth = on behalf of Brian Campbell = >>>> Sent: Friday, December 8, 2017 3:47:32 PM >>>> To: Denis >>>> Cc: oauth >>>> Subject: Re: [OAUTH-WG] I-D Action: = draft-ietf-oauth-token-exchange-10.txt >>>>=20 >>>> As an individual, I do not believe that the proposed text should be = incorporated into the draft. >>>>=20 >>>> As one of the document editors, my responsibility is for the = document to be of reasonable quality and to reflect the rough consensus = of this Working Group. So I should ask the list more explicitly - are = there other WG remembers who are in favor of the proposed text here (the = text would have to be fixed up some too)?=20 >>>>=20 >>>> On Fri, Dec 1, 2017 at 11:12 AM, Denis > wrote: >>>> Comments on draft-ietf-oauth-token-exchange-10 >>>>=20 >>>> I propose the following rephrasing for sections 6 and 7: >>>>=20 >>>> 6 . Security Considerations >>>>=20 >>>> All of the normal security issues that are discussed in = [JWT],especially in relationship to comparing URIs=20 >>>> and dealing with unrecognized values, also apply here. In = addition, both delegation and impersonation introduce=20 >>>> unique security issues. Any time one user receives a token, the = potential for abuse is a concern,=20 >>>> since that user might be willing to collude with another user so = that other user could use the token.=20 >>>>=20 >>>> Techniques like the binding of an access token to a TLS channel = described elsewhere are ineffective since=20 >>>> the legitimate user would be able to perform all the cryptographic = computations that the other user would need=20 >>>> to demonstrate the ownership of the token. The use of the "scp" = claim is suggested to mitigate potential for=20 >>>> such abuse, as it restricts the contexts in which the token can be = exercised. If the issued access token scope=20 >>>> allows to unambiguously identify the user, then that user is likely = to be reluctant to collude with another user. =20 >>>> However, if the issued access token scope only indicates that the = user is over 18, then there is no risk=20 >>>> for the original user to be discovered and in such a context a = collusion may easily take place.=20 >>>> This document does not specify techniques to prevent such a = collusion to be successful. >>>>=20 >>>> 7 . Privacy Considerations >>>>=20 >>>> Tokens typically carry personal information and their usage in = Token Exchange may reveal details of the target services=20 >>>> being accessed. The resource and the audience parameters allow = authorization servers to know where the issued access token=20 >>>> will be used. This may be a privacy concern for some users. This = document does not specify techniques to prevent=20 >>>> authorization servers to know where the access tokens they issue = will be used. >>>>=20 >>>> Denis >>>>> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >>>>> This draft is a work item of the Web Authorization Protocol WG of = the IETF. >>>>>=20 >>>>> Title : OAuth 2.0 Token Exchange >>>>> Authors : Michael B. Jones >>>>> Anthony Nadalin >>>>> Brian Campbell >>>>> John Bradley >>>>> Chuck Mortimore >>>>> Filename : draft-ietf-oauth-token-exchange-10.txt >>>>> Pages : 32 >>>>> Date : 2017-11-30 >>>>>=20 >>>>> Abstract: >>>>> This specification defines a protocol for an HTTP- and JSON- = based >>>>> Security Token Service (STS) by defining how to request and = obtain >>>>> security tokens from OAuth 2.0 authorization servers, including >>>>> security tokens employing impersonation and delegation. >>>>>=20 >>>>>=20 >>>>> The IETF datatracker status page for this draft is: >>>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/ = >>>>>=20 >>>>> There are also htmlized versions available at: >>>>> https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-10 = >>>>> = https://datatracker.ietf.org/doc/html/draft-ietf-oauth-token-exchange-10 = = >>>>>=20 >>>>> A diff from the previous version is available at: >>>>> = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-token-exchange-10 = >>>>>=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 = >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>=20 >>>>=20 >>>>=20 >>>> CONFIDENTIALITY NOTICE: This email may contain confidential and = privileged material for the sole use of the intended recipient(s). Any = review, use, distribution or disclosure by others is strictly = prohibited. If you have received this communication in error, please = notify the sender immediately by e-mail and delete the message and any = file attachments from your computer. Thank you. >>>=20 >>>=20 >>>=20 >>> CONFIDENTIALITY NOTICE: This email may contain confidential and = privileged material for the sole use of the intended recipient(s). Any = review, use, distribution or disclosure by others is strictly = prohibited. If you have received this communication in error, please = notify the sender immediately by e-mail and delete the message and any = file attachments from your computer. Thank = you._______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth = >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: = >>=20 >> ------------------------------ >>=20 >> Subject: Digest Footer >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >> ------------------------------ >>=20 >> End of OAuth Digest, Vol 110, Issue 8 >> ************************************* >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Mon Dec 11 15:24:05 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B802412711D for ; Mon, 11 Dec 2017 15:24:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WajeQvnAuHvK for ; Mon, 11 Dec 2017 15:24:01 -0800 (PST) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::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 17AE2124239 for ; Mon, 11 Dec 2017 15:24:01 -0800 (PST) Received: by mail-it0-x22f.google.com with SMTP id d16so19947567itj.1 for ; Mon, 11 Dec 2017 15:24:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HgsjySPNz2hB0ZYwkPh/tWvoRzrDZq8FwozXqRgzQ/0=; b=RJtOoicaEwBNT1pTc5IuiZLO/td4X0oskVNZxnXe7Q3+gPSvmFa+FTEDLy3G+NhTiP 3LfaXEaNNZhratAQ2QqQ5qgaWeEkTMruerrzgiqNuM/kJb2NqSf8vndYYmz30wNvPsCt YvIojALjJIF7Jcu1EQUUag+2XEfAfJKs9/VKw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=HgsjySPNz2hB0ZYwkPh/tWvoRzrDZq8FwozXqRgzQ/0=; b=dNiD/RbW24bNLvBcBmhvw/FfH/TGbYtUQwsRbAhFJ6z6BDrCrtBhNbICLDzYmmQ6AK UwzZFC7fVQEexyNWHYnCjWSY/v3qnpodXEoAu8bwxcWfafoN9IU4mEchPxl5s7DAkDcg UHi9os8xlFO8EM8VHYrhL50u3aTXFNI26YgnrdnUNSdMdfncRcI5XvJHCHDwhGp63GG6 pPC2chNY3BcVBhxs6yXAqDNQ94c7tT8Wwpp+3DPitS1YgZThi88DoXLr8Pgx9JcOdEt2 3QtddsQj2Ui+84gFEuViLoxjSPRaeU7PRvz36cwPntqw+kmMStN8gCSenCt7G2RgqfGU ma5Q== X-Gm-Message-State: AKGB3mKU1vNWdU08+0Gc3+k5HVjFYCpV69R64MJv3crLWZ/VeoONNdF2 MFgKo9/eyu3NGzwTyvlNDO9ZlMmUD9TSqICA/dGEwYh8SAJ/sIdJ4de5TIXMTmjlOsFQ1vxBpIp Ftzu1TZhfcaDfIEDa X-Google-Smtp-Source: ACJfBou87gNmmuIPC4hGMzdvmzk/W31Xmj1bODznXkYc8X8c3HtrS74KOdeUl2CjFgVNjfEQvl64JID6SAGO2Keh9vE= X-Received: by 10.36.95.14 with SMTP id r14mr8605itb.42.1513034640050; Mon, 11 Dec 2017 15:24:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.2.118.194 with HTTP; Mon, 11 Dec 2017 15:23:29 -0800 (PST) In-Reply-To: References: From: Brian Campbell Date: Mon, 11 Dec 2017 16:23:29 -0700 Message-ID: To: Bill Burke Cc: OAuth WG Content-Type: multipart/alternative; boundary="001a1144b57a40ef3d056018d462" Archived-At: Subject: Re: [OAUTH-WG] [token-exchange] Parameters to support external token exchange X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Dec 2017 23:24:04 -0000 --001a1144b57a40ef3d056018d462 Content-Type: text/plain; charset="UTF-8" The words implicit vs. explicit might not have been the best choice but the concepts are complicated and subtle and I was (and still am) at a bit of a lose for the right language to describe things. By explicit what I was trying to express is that the token that is going cross-domain is explicitly intended for that purpose and includes things like an audience restriction that reflect that intention. The OpenID Connect ID Token is an example of that for browser based flows and the RFC 7523 JWT authorization grant is an example for non-browser flows. By implicit what I was trying to express are situations where a token that issued for a particular purpose (like a Facebook access token for access to Facebook APIs) is used implicitly for a different purpose (like getting a different access token for access to APIs in a different domain). On Fri, Dec 8, 2017 at 2:29 PM, Bill Burke wrote: > On Fri, Dec 8, 2017 at 12:41 PM, Brian Campbell > wrote: > > I guess I'm going to kind of restate some of what I said in that earlier > > thread and a bit more. The access and refresh token URIs from the draft > are > > intended to indicate that such tokens are issued by the given > authorization > > server acting as the STS (perhaps this could be stated more clearly in > the > > doc). As such, there isn't direct explicit support for OAuth access > token to > > OAuth access token cross-domain type exchanges. That was intentional and > I > > think is appropriate as I don't believe this draft should delve into > pseudo > > federating access tokens and all the additional complexity and security > > implications that entails. > > I'll look in my email archives again, but, I wasn't convinced then > that there is all this additional complexity. > > > The assertion based authorization grants (RFCs > > 7523 & 7522) are intended to facilitate acquiring an access token from an > > external or cross-domain AS and I prefer that more explicit model for > > cross-domain than codifying a rather implicit way of doing it in token > > exchange. > > Not understanding what you mean by implicit vs. explicit. I don't see > how what we've implemented is any more implicit than the current > specification. If anything, I thought our impl was more explicit as > you can't derive the issuer from an opaque access token in the current > spec. > > > > A Facebook access token, for example, is issued to a client for > > delegated access to Facebook APIs. It isn't for delegated access to some > > other domain's APIs but an access token for access token exchange > > effectively turns it into that. And in some situations that can have > > problematic security implications. > > Internet applications trust Facebook, Google, whoever to identity and > authenticate users all the time and to grant access and permission > based on that identity. An external exchange is just a non-browser > mechanism to facilitate this relationship. For our IDP, our userbase > often use us as a broker between the various social websites and their > apps. This way, apps don't care where the user was authenticated > from, they just see open id connect with a token format and domain > they control. Developers often have apps that they are not able to > change how a user logs in or cannot unify their apps with a common > STS, token format, or even protocol. Yet they still have a need to > make secure invocations across these domains and apps. > > > Big providers like Facebook have a lot of > > apps (OAuth clients) that can get access tokens. An organization might > well > > be okay with an app it controls exchanging a Facebook access token for an > > access token for its own APIs. But a 3rd party Facebook app (like maybe a > > new viral rate my '80's hairdo app) doing the same thing could be very > > problematic. It's not exactly the same thing but many of the same > potential > > issues arise as when using OAuth for User Authentication. Standardization > > around access token for access token exchange would, at a minimum, need > some > > real security analysis and recommendations/considerations. > > > > The token exchange draft went thought WGLC some time ago and is currently > > being written up by the document shepherd to send to the AD. It's close. > > It's been a long time coming and I'd really object to derailing it by > making > > big additions to it at this late stage in the process. > > > > That's fair enough. I didn't know how far in the process the token > exchange draft was. In the least, I wanted to make the WG aware of > our work. We have a decent and growing user base with a problem > looking for a solution and we're going to get a lot of feedback on > what we've implemented. At least from our open source project > perspective, there's a lot more interest in external exchange than > internal. Which is why I'm posting this. > > > -- > Bill Burke > Red Hat > -- *CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.* --001a1144b57a40ef3d056018d462 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The words implicit vs. explicit might not have b= een the best choice but the concepts are complicated and subtle and I was (= and still am) at a bit of a lose for the right language to describe things.=

By explicit what I was trying to express is that the token t= hat is going cross-domain is explicitly intended for that purpose and inclu= des things like an audience restriction that reflect that intention. The Op= enID Connect ID Token is an example of that for browser based flows and the= RFC 7523 JWT authorization grant is an example for non-browser flows.
<= br>
By implicit what I was trying to express are situations where a to= ken that issued for a particular purpose (like a Facebook access token for = access to Facebook APIs) is used implicitly for a different purpose (like g= etting a different access token for access to APIs in a different domain). =

=C2=A0

On Fri, Dec 8, 2017 at 2:29 PM, Bill Burke <bburke@redhat.com&g= t; wrote:
On Fri,= Dec 8, 2017 at 12:41 PM, Brian Campbell
<bcampbell@pingidentity.co= m> wrote:
> I guess I'm going to kind of restate some = of what I said in that earlier
> thread and a bit more. The access and refresh token URIs from the draf= t are
> intended to indicate that such tokens are issued by the given authoriz= ation
> server acting as the STS (perhaps this could be stated more clearly in= the
> doc). As such, there isn't direct explicit support for OAuth acces= s token to
> OAuth access token cross-domain type exchanges. That was intentional a= nd I
> think is appropriate as I don't believe this draft should delve in= to pseudo
> federating access tokens and all the additional complexity and securit= y
> implications that entails.

I'll look in my email archives again, but, I wasn't convince= d then
that there is all this additional complexity.

> The assertion based authorization grants (RFCs
> 7523 & 7522) are intended to facilitate acquiring an access token = from an
> external or cross-domain AS and I prefer that more explicit model for<= br> > cross-domain than codifying a rather implicit way of doing it in token=
> exchange.

Not understanding what you mean by implicit vs. explicit.=C2=A0 I do= n't see
how what we've implemented is any more implicit than the current
specification.=C2=A0 If anything, I thought our impl was more explicit as you can't derive the issuer from an opaque access token in the current<= br> spec.


> A Facebook access token, for example, is issued to a client for
> delegated access to Facebook APIs. It isn't for delegated access t= o some
> other domain's APIs but an access token for access token exchange<= br> > effectively turns it into that. And in some situations that can have > problematic security implications.

Internet applications trust Facebook, Google, whoever to identity an= d
authenticate users all the time and to grant access and permission
based on that identity.=C2=A0 An external exchange is just a non-browser mechanism to facilitate this relationship.=C2=A0 For our IDP, our userbase<= br> often use us as a broker between the various social websites and their
apps.=C2=A0 This way, apps don't care where the user was authenticated<= br> from, they just see open id connect with a token format and domain
they control.=C2=A0 Developers often have apps that they are not able to change how a user logs in or cannot unify their apps with a common
STS, token format, or even protocol.=C2=A0 Yet they still have a need to make secure invocations across these domains and apps.

> Big providers like Facebook have a lot of
> apps (OAuth clients) that can get access tokens. An organization might= well
> be okay with an app it controls exchanging a Facebook access token for= an
> access token for its own APIs. But a 3rd party Facebook app (like mayb= e a
> new viral rate my '80's hairdo app) doing the same thing could= be very
> problematic. It's not exactly the same thing but many of the same = potential
> issues arise as when using OAuth for User Authentication. Standardizat= ion
> around access token for access token exchange would, at a minimum, nee= d some
> real security analysis and recommendations/considerations.
>
> The token exchange draft went thought WGLC some time ago and is curren= tly
> being written up by the document shepherd to send to the AD. It's = close.
> It's been a long time coming and I'd really object to derailin= g it by making
> big additions to it at this late stage in the process.
>

That's fair enough.=C2=A0 I didn't know how far in the proce= ss the token
exchange draft was.=C2=A0 In the least, I wanted to make the WG aware of our work.=C2=A0 We have a decent and growing user base with a problem
looking for a solution and we're going to get a lot of feedback on
what we've implemented.=C2=A0 =C2=A0At least from our open source proje= ct
perspective, there's a lot more interest in external exchange than
internal.=C2=A0 Which is why I'm posting this.


--
Bill Burke
Red Hat


<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --001a1144b57a40ef3d056018d462-- From nobody Tue Dec 12 09:04:13 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A9231294B9 for ; Tue, 12 Dec 2017 09:04:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.909 X-Spam-Level: X-Spam-Status: No, score=-2.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u5kCTaxw6Z_6 for ; Tue, 12 Dec 2017 09:04:10 -0800 (PST) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00044.outbound.protection.outlook.com [40.107.0.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E66B6124BAC for ; Tue, 12 Dec 2017 09:04:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=QiXw3dU4FatwGywEzy6XtG12EqsBxLQyC044M6U023Q=; b=JpJCDIs08VBa5pKUs/xIxpgZUBmg/Je7Zt2BpRUMwiU8+OS+upFS5Y8WnSWU8xtsfOgwL7kzz8VcQTceOJB05uy4/E5RTHDxJFDFBPOALWll4cHoxTnwfYI5kTiRpv/IF4eA7UrLuJMoX20iUOoa1IsEl7NiY2lX7a5qY9BhncA= Received: from AM4PR0801MB2706.eurprd08.prod.outlook.com (10.167.90.148) by AM4PR0801MB2705.eurprd08.prod.outlook.com (10.167.90.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.302.9; Tue, 12 Dec 2017 17:04:07 +0000 Received: from AM4PR0801MB2706.eurprd08.prod.outlook.com ([fe80::b9af:5048:9d97:f7e6]) by AM4PR0801MB2706.eurprd08.prod.outlook.com ([fe80::b9af:5048:9d97:f7e6%14]) with mapi id 15.20.0302.013; Tue, 12 Dec 2017 17:04:07 +0000 From: Hannes Tschofenig To: "oauth@ietf.org" Thread-Topic: IETF#100 OAuth Meeting Minutes Thread-Index: AdNzam8CRRJDd45WRumY1u66rjsyUA== Date: Tue, 12 Dec 2017 17:04: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=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.123.79] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR0801MB2705; 6:8bvrR07++xwVP65hhbWo2Frf2a7gdiR1mo8alHsrfpS4ieRI2pkuwTuDuMHaa01ypM7sylEUYgmi1XGh8CozYRDfvRWYWKI27vSHz37lh1ZVBM5Xl9i51bfrcXUtdIkL9XZpNLTNSU8EZKUxg6/WT0QNaviQrQ6gLPHk7PiUQbsoHfKDfqTqPcFBRVIjtLQCrSbVCvW96iFzD8iCRRO3Zh8qqrNvEWfARMQbXmCtZh4915evokfnViDVZkP/cEjZciRftPpqI3KSNTpyTjbrZtO0XnhAtHnefGNFI9BwnGIBIXcbonQRzYG5l3LxjOe60Df3ykUMyYpeoaWoFCzzIvuleLckLUXflaJaIAuDk9U=; 5:KE177V05PsVnXVGfxoskrkCCu6ZBDDt6LVTzp43gmOCNrQoIDvRrW8UwGRS3orOAeNKL6Sn+qdwIObyn2sSZ3s2IJPsomPFevCUPAR2Vd3qT+7fcf88I+UFnxKVGaZgHSknVa8M0kYKmZUT9745jR2XlFm1+O9zUyMtG79JsuQs=; 24:8SrQh7L0cZkOdv8VP5zFGmFf1NgtlKaQhyr5ZJhzQiHQnfbk14zhzosTJ/tQoO50IjgXaEB7sKXyLToFBBsmrvVZU65IDE+6JWlt2cmkHX0=; 7:v+m9aGZ6Im1HswIMelcBXVJ6fKCncOhLMpYM11v4sGkSTH1i38iZk7n68EqVZAS6zaNhe6vYoEW4QtMYubdeUTI8rWCw3JS8lzQ5JOP8MElkwc4Bled9jLalxAIUC/7QD/7j/4wEuvw3pZps5uMLdWV+bxfwVhqobj0aaVND+IuE7bqeuDzJ/zS8jlPCfHujCKJYTkYbKGNIKKEANTOrG1W+FvwlXRrFCHbJxsWcayvo0rY/2cjH/k/aZ/n/PWs8 x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: e7b9e750-c500-4745-017e-08d541825b13 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(2017052603307); SRVR:AM4PR0801MB2705; x-ms-traffictypediagnostic: AM4PR0801MB2705: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3002001)(3231023)(6055026)(6041248)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123558100)(20161123555025)(20161123562025)(6072148)(201708071742011); SRVR:AM4PR0801MB2705; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:AM4PR0801MB2705; x-forefront-prvs: 051900244E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(346002)(376002)(366004)(40434004)(53754006)(189003)(199004)(2900100001)(106356001)(316002)(105586002)(2351001)(1730700003)(81166006)(8676002)(6916009)(2906002)(97736004)(66066001)(81156014)(68736007)(25786009)(7696005)(33656002)(7736002)(6436002)(6306002)(6506006)(74316002)(5630700001)(3660700001)(99286004)(3280700002)(8936002)(236005)(55016002)(9686003)(54896002)(478600001)(5640700003)(14454004)(53936002)(102836003)(966005)(72206003)(6116002)(606006)(790700001)(5890100001)(59450400001)(2501003)(86362001)(3846002)(5250100002)(5660300001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0801MB2705; H:AM4PR0801MB2706.eurprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM4PR0801MB2706C5811E4423B061799EE1FA340AM4PR0801MB2706_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: e7b9e750-c500-4745-017e-08d541825b13 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Dec 2017 17:04:07.1850 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0801MB2705 Archived-At: Subject: [OAUTH-WG] IETF#100 OAuth Meeting Minutes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Dec 2017 17:04:12 -0000 --_000_AM4PR0801MB2706C5811E4423B061799EE1FA340AM4PR0801MB2706_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, Here are the meeting minutes from the last IETF meeting in Singapore: https://datatracker.ietf.org/doc/minutes-100-oauth/ Feedback welcome. Also note that some of you volunteered to review some dra= fts. Thanks to Tony & Torsten for taking notes. Ciao Hannes & Rifaat IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease 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. --_000_AM4PR0801MB2706C5811E4423B061799EE1FA340AM4PR0801MB2706_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

Here are the meeting minutes from the last IETF meet= ing in Singapore:

https://datatracker.ietf.org/doc/minutes-100-oauth/

 

Feedback welcome. Also note that some of you volunte= ered to review some drafts.

 

Thanks to Tony & Torsten for taking notes. =

 

Ciao

Hannes & Rifaat

 

 

IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease 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. --_000_AM4PR0801MB2706C5811E4423B061799EE1FA340AM4PR0801MB2706_-- From nobody Tue Dec 12 09:18:55 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E98B11200FC; Tue, 12 Dec 2017 09:18:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.019 X-Spam-Level: X-Spam-Status: No, score=-2.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0rDryiCloD2i; Tue, 12 Dec 2017 09:18:51 -0800 (PST) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0127.outbound.protection.outlook.com [104.47.41.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF67F1294B9; Tue, 12 Dec 2017 09:18:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=1ICUQWuvZ/XyQMTKyIF9NM28XBkIX1xNLiZQtQ65yXs=; b=ZvI6LiuQ3m9UPhHeT1vEUPHQxqdkmiKl2fLOhxQO2rAGDmB+ew8oBLxAgKQrUOy7D4GmMvEozr0wS+UNmmyMQtylh0D4E6KN9jOZ0GYJIf4b6Z3Ki9fCHREZkziKvypOoqO8ncORttfha7ZCZOYTvazpgzP1yjn1suQQepYJw5o= Received: from BN3PR00MB0083.namprd00.prod.outlook.com (10.167.6.147) by BN3PR00MB0099.namprd00.prod.outlook.com (10.167.6.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.361.0; Tue, 12 Dec 2017 17:18:46 +0000 Received: from BN3PR00MB0083.namprd00.prod.outlook.com ([fe80::29b2:dc54:a0db:751d]) by BN3PR00MB0083.namprd00.prod.outlook.com ([fe80::29b2:dc54:a0db:751d%3]) with mapi id 15.20.0360.000; Tue, 12 Dec 2017 17:18:46 +0000 From: Anthony Nadalin To: Rifaat Shekh-Yusef , "draft-ietf-oauth-token-exchange.all@ietf.org" , oauth Thread-Topic: Token Exchange - IPR Disclosure Thread-Index: AQHTZHYkX+kChNZQ9Umf0wkcWrH7SaNAEZRw Date: Tue, 12 Dec 2017 17:18:46 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=tonynad@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2017-12-12T17:18:44.5161577Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General x-originating-ip: [2001:4898:80e8:9::6b] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN3PR00MB0099; 6:DBAZ2lGDmjZ+3tO3jqruM4WQsRm1qy1R2xgggytF7lxLOgZVGdcQ5w0/CaaVdBBWHct6IJEZ2nWZ1yjIwDU0nVjHUJBYpOJAKjHSIJTMf5/lab6OYTLvVf0yak0hZPpKVs8tWPvChjGT4pvDwce6HrDq3/xjM8fIc+shTegmLOoSCUseB3fSPvm+9VeHz4SSugWp9txIgZyZkLQjenjCYdmvb53MW1E3fF+YdN5mrm7jgV0uz2MQYcet33IfWcorCuceVQWd3l3cl/UjWlpb5Uf/1FueN41oao3PqVaFPtEWzyqdx6oNi0GoIfC9sxLjwABZWcUnUh7J8vpz6au7t1bbLmCpiIO3GGBCi/wp42I=; 5:aszV1lcUIVmip63kceMc1UUUWK/M9zjD8tHWIoiQ/ihcCcIB0U0nakaeM/UT+5Sgu7T9aZfDuGUtpqpclcVixBnjSfRO2fqiLSAWNx5KbfukutJDkwOSqkKJfvmYyo+ss/LBkrah1xLzxA+nDrjtEtw128l1NKXY4B/h4LOT9rs=; 24:d2NglAum9ozOGRVK4Rrw303TZHtITsschCk+89GdAUchtzzpz4yGUOpqq8OG22XBk4+sudI6V5rKiBqMbHO05ZSCfw6w3zQNc4U2ZzXbvxo=; 7:0vHnRGyHNp+yqMG3QApHI2XEO00BEKKypv2Hxf4vDDeVLxdXlQ663U4BSseroXCjdwC1phZlzN4Tr8ZL3G+vJL/HS0nYT5VrP5pL2X/uiYJhxMIAeyIKStNyZxXFFwrfJIbFmMx4CCLjW6lZK/YAWmkTVZxefetYjWUDazHgwgAxZinXiAM28zNIf/D9eeeDZjFQJuSA6OtRl9TLn2Hu5YKP9rbEZ7SaReZAwvVu23avBXBNXgKoiG5BSycx/4Dq x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: aa438cf4-4681-43fb-d32f-08d541846768 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(48565401081)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(2017052603307); SRVR:BN3PR00MB0099; x-ms-traffictypediagnostic: BN3PR00MB0099: x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(180628864354917)(120809045254105)(189930954265078)(219752817060721)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040450)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3002001)(3231023)(6055026)(61426038)(61427038)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123562025)(20161123564025)(20161123558100)(20161123555025)(6072148)(201708071742011); SRVR:BN3PR00MB0099; BCL:0; PCL:0; RULEID:(100000803110)(100110400104); SRVR:BN3PR00MB0099; x-forefront-prvs: 051900244E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(366004)(39860400002)(199004)(189003)(229853002)(4326008)(25786009)(966005)(81156014)(81166006)(8676002)(9686003)(55016002)(54896002)(6306002)(2501003)(6506006)(5250100002)(19609705001)(6436002)(8990500004)(74316002)(3660700001)(3280700002)(2906002)(2900100001)(6246003)(105586002)(97736004)(106356001)(39060400002)(236005)(7736002)(14454004)(53936002)(316002)(110136005)(33656002)(86362001)(22452003)(7696005)(76176011)(2950100002)(8936002)(99286004)(790700001)(53546010)(10090500001)(606006)(5660300001)(478600001)(102836003)(68736007)(6116002)(86612001)(10290500003)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR00MB0099; H:BN3PR00MB0083.namprd00.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=tonynad@microsoft.com; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN3PR00MB0083E1711BE882A0AEC8A612A6340BN3PR00MB0083namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: aa438cf4-4681-43fb-d32f-08d541846768 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Dec 2017 17:18:46.7863 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR00MB0099 Archived-At: Subject: Re: [OAUTH-WG] Token Exchange - IPR Disclosure X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Dec 2017 17:18:53 -0000 --_000_BN3PR00MB0083E1711BE882A0AEC8A612A6340BN3PR00MB0083namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhbSBub3QgYXdhcmUgb2YgYW55IElQUiBvbiB0aGUgdG9rZW4gZXhjaGFuZ2UgZG9jdW1lbnQu DQoNCg0KRnJvbTogUmlmYWF0IFNoZWtoLVl1c2VmIFttYWlsdG86cmlmYWF0LmlldGZAZ21haWwu Y29tXQ0KU2VudDogVGh1cnNkYXksIE5vdmVtYmVyIDIzLCAyMDE3IDg6MTQgQU0NClRvOiBkcmFm dC1pZXRmLW9hdXRoLXRva2VuLWV4Y2hhbmdlLmFsbEBpZXRmLm9yZzsgb2F1dGggPG9hdXRoQGll dGYub3JnPg0KQ2M6IEhhbm5lcyBUc2Nob2ZlbmlnIDxIYW5uZXMuVHNjaG9mZW5pZ0Bhcm0uY29t Pg0KU3ViamVjdDogVG9rZW4gRXhjaGFuZ2UgLSBJUFIgRGlzY2xvc3VyZQ0KDQpBdXRob3JzLA0K DQpBcyBwYXJ0IG9mIHRoZSB3cml0ZS11cCBmb3IgdGhlIFRva2VuIEV4Y2hhbmdlIGRvY3VtZW50 LCB3ZSBuZWVkIGFuIElQUiBkaXNjbG9zdXJlIGZyb20gYWxsIG9mIHlvdS4NCg0KQXJlIHlvdSBh d2FyZSBvZiBhbnkgSVBSIHJlbGF0ZWQgdG8gdGhlIGZvbGxvd2luZyBUb2tlbiBFeGNoYW5nZSBk b2N1bWVudD8NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtb2F1 dGgtdG9rZW4tZXhjaGFuZ2UvPGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRs b29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGZGF0YXRyYWNrZXIuaWV0Zi5vcmclMkZkb2MlMkZk cmFmdC1pZXRmLW9hdXRoLXRva2VuLWV4Y2hhbmdlJTJGJmRhdGE9MDIlN0MwMSU3Q3RvbnluYWQl NDBtaWNyb3NvZnQuY29tJTdDYmEzNzc3NWI4NzZhNGNmYjE3NDIwOGQ1MzI4ZDQ1MzYlN0M3MmY5 ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM2NDcwNTA0NjkyMTkyMDAy JnNkYXRhPTkwaW5kdE1SQ1FYSnU4WGwlMkI2UCUyQnpTZGJ0bWJ4Q3NIN25PaUMwQ1ZZRzRFJTNE JnJlc2VydmVkPTA+DQoNClJlZ2FyZHMsDQogUmlmYWF0DQoNCg== --_000_BN3PR00MB0083E1711BE882A0AEC8A612A6340BN3PR00MB0083namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J IGFtIG5vdCBhd2FyZSBvZiBhbnkgSVBSIG9uIHRoZSB0b2tlbiBleGNoYW5nZSBkb2N1bWVudC4g PG86cD4NCjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gUmlmYWF0IFNoZWtoLVl1c2VmIFttYWlsdG86cmlm YWF0LmlldGZAZ21haWwuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBOb3ZlbWJl ciAyMywgMjAxNyA4OjE0IEFNPGJyPg0KPGI+VG86PC9iPiBkcmFmdC1pZXRmLW9hdXRoLXRva2Vu LWV4Y2hhbmdlLmFsbEBpZXRmLm9yZzsgb2F1dGggJmx0O29hdXRoQGlldGYub3JnJmd0Ozxicj4N CjxiPkNjOjwvYj4gSGFubmVzIFRzY2hvZmVuaWcgJmx0O0hhbm5lcy5Uc2Nob2ZlbmlnQGFybS5j b20mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFRva2VuIEV4Y2hhbmdlIC0gSVBSIERpc2Nsb3N1 cmU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkF1dGhvcnMsPG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BcyBwYXJ0IG9mIHRoZSB3cml0ZS11cCBm b3IgdGhlIFRva2VuIEV4Y2hhbmdlIGRvY3VtZW50LCB3ZSBuZWVkIGFuIElQUiBkaXNjbG9zdXJl IGZyb20gYWxsIG9mIHlvdS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+QXJlIHlvdSBhd2FyZSBvZiBhbnkgSVBSIHJlbGF0ZWQgdG8gdGhlIGZv bGxvd2luZyBUb2tlbiBFeGNoYW5nZSBkb2N1bWVudD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlu a3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGZGF0YXRyYWNrZXIu aWV0Zi5vcmclMkZkb2MlMkZkcmFmdC1pZXRmLW9hdXRoLXRva2VuLWV4Y2hhbmdlJTJGJmFtcDtk YXRhPTAyJTdDMDElN0N0b255bmFkJTQwbWljcm9zb2Z0LmNvbSU3Q2JhMzc3NzViODc2YTRjZmIx NzQyMDhkNTMyOGQ0NTM2JTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdD MCU3QzYzNjQ3MDUwNDY5MjE5MjAwMiZhbXA7c2RhdGE9OTBpbmR0TVJDUVhKdThYbCUyQjZQJTJC elNkYnRtYnhDc0g3bk9pQzBDVllHNEUlM0QmYW1wO3Jlc2VydmVkPTAiPmh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtb2F1dGgtdG9rZW4tZXhjaGFuZ2UvPC9hPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZWdh cmRzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7UmlmYWF0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_BN3PR00MB0083E1711BE882A0AEC8A612A6340BN3PR00MB0083namp_-- From nobody Tue Dec 12 10:19:24 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B84D129504 for ; Tue, 12 Dec 2017 10:19:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g36V4crslqJ4 for ; Tue, 12 Dec 2017 10:19:08 -0800 (PST) Received: from mail-vk0-f42.google.com (mail-vk0-f42.google.com [209.85.213.42]) (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 8DE981294F4 for ; Tue, 12 Dec 2017 10:19:08 -0800 (PST) Received: by mail-vk0-f42.google.com with SMTP id j192so5332227vkc.1 for ; Tue, 12 Dec 2017 10:19:08 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=mh/e5QvI4z30d8iYooAFY4BA4jjDH5+8dFmyVIbX+Q8=; b=EvxNq5yNrHwR4OdJh1Q5hJ39WGnRA+S4lTJY/s6BJgvKFGua+DPojxmPnWRY77U91K gjVPRHwOvc1dzyz4S1VSI524vcIodOVurjG9FrSqxVuFOrqpWt/l5GXEIE/k49MOoDGs S+UISE1eCXa8XiAFCPHoIp3FH5H/dtAeVfxQrPxWWrh2Sz1977nu/eCmkl4hZ4fn7TXw LlBDmZKbG+yM0CS+Eb4royu6JxL90SlFi8dIfvvbiJJqfaZyJH0TD0AlvM6gL5N4l5Oc hwv0KZft+U3IpuFO5U2Zm0PtNP64fBorNNz857lIsDsuJEc9YlPKRm9Av9YATOoXvDt6 YQSA== X-Gm-Message-State: AKGB3mKcnjU+v7V5wKJNr7SorDaB9ah9KF+p8jV8HN1wxF9HYUdYPPSu CqettLtcn8/7uSfi1bsW2zggKA8zHk+8VOpOfqpoNQ== X-Google-Smtp-Source: ACJfBosANU8Ra6G0q4pGlyiSqHZrbdkbdhg2Hcm85yZ4sVH1bTMieCj3rSYrNCoJAX/WqAiWjV8Vk89BHk97CVtZUno= X-Received: by 10.31.52.196 with SMTP id b187mr4858038vka.23.1513102747188; Tue, 12 Dec 2017 10:19:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.68.86 with HTTP; Tue, 12 Dec 2017 10:19:06 -0800 (PST) In-Reply-To: References: From: Bill Burke Date: Tue, 12 Dec 2017 13:19:06 -0500 Message-ID: To: Brian Campbell Cc: OAuth WG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [OAUTH-WG] [token-exchange] Parameters to support external token exchange X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Dec 2017 18:19:13 -0000 How the target STS processes the external token is up to the STS. The external token could solely be used as an authentication mechanism. The client must be registered and known by the STS, so it can decide if the client is allowed to exchange an external token, and what target audience or resource the client is allowed to ask for. At least this is how it works in our implementation. With Facebook token, the STS knows that it is a Facebook token and was obtained to access Facebook APIs. I don't see the vulnerabilites right now as much different than an internal exchange or bearer token invocations. Clients need to be aware that they should downgrade tokens before passing them to less trusted target endpoints. On Mon, Dec 11, 2017 at 6:23 PM, Brian Campbell wrote: > The words implicit vs. explicit might not have been the best choice but the > concepts are complicated and subtle and I was (and still am) at a bit of a > lose for the right language to describe things. > > By explicit what I was trying to express is that the token that is going > cross-domain is explicitly intended for that purpose and includes things > like an audience restriction that reflect that intention. The OpenID Connect > ID Token is an example of that for browser based flows and the RFC 7523 JWT > authorization grant is an example for non-browser flows. > > By implicit what I was trying to express are situations where a token that > issued for a particular purpose (like a Facebook access token for access to > Facebook APIs) is used implicitly for a different purpose (like getting a > different access token for access to APIs in a different domain). > > > > On Fri, Dec 8, 2017 at 2:29 PM, Bill Burke wrote: >> >> On Fri, Dec 8, 2017 at 12:41 PM, Brian Campbell >> wrote: >> > I guess I'm going to kind of restate some of what I said in that earlier >> > thread and a bit more. The access and refresh token URIs from the draft >> > are >> > intended to indicate that such tokens are issued by the given >> > authorization >> > server acting as the STS (perhaps this could be stated more clearly in >> > the >> > doc). As such, there isn't direct explicit support for OAuth access >> > token to >> > OAuth access token cross-domain type exchanges. That was intentional and >> > I >> > think is appropriate as I don't believe this draft should delve into >> > pseudo >> > federating access tokens and all the additional complexity and security >> > implications that entails. >> >> I'll look in my email archives again, but, I wasn't convinced then >> that there is all this additional complexity. >> >> > The assertion based authorization grants (RFCs >> > 7523 & 7522) are intended to facilitate acquiring an access token from >> > an >> > external or cross-domain AS and I prefer that more explicit model for >> > cross-domain than codifying a rather implicit way of doing it in token >> > exchange. >> >> Not understanding what you mean by implicit vs. explicit. I don't see >> how what we've implemented is any more implicit than the current >> specification. If anything, I thought our impl was more explicit as >> you can't derive the issuer from an opaque access token in the current >> spec. >> >> >> > A Facebook access token, for example, is issued to a client for >> > delegated access to Facebook APIs. It isn't for delegated access to some >> > other domain's APIs but an access token for access token exchange >> > effectively turns it into that. And in some situations that can have >> > problematic security implications. >> >> Internet applications trust Facebook, Google, whoever to identity and >> authenticate users all the time and to grant access and permission >> based on that identity. An external exchange is just a non-browser >> mechanism to facilitate this relationship. For our IDP, our userbase >> often use us as a broker between the various social websites and their >> apps. This way, apps don't care where the user was authenticated >> from, they just see open id connect with a token format and domain >> they control. Developers often have apps that they are not able to >> change how a user logs in or cannot unify their apps with a common >> STS, token format, or even protocol. Yet they still have a need to >> make secure invocations across these domains and apps. >> >> > Big providers like Facebook have a lot of >> > apps (OAuth clients) that can get access tokens. An organization might >> > well >> > be okay with an app it controls exchanging a Facebook access token for >> > an >> > access token for its own APIs. But a 3rd party Facebook app (like maybe >> > a >> > new viral rate my '80's hairdo app) doing the same thing could be very >> > problematic. It's not exactly the same thing but many of the same >> > potential >> > issues arise as when using OAuth for User Authentication. >> > Standardization >> > around access token for access token exchange would, at a minimum, need >> > some >> > real security analysis and recommendations/considerations. >> > >> > The token exchange draft went thought WGLC some time ago and is >> > currently >> > being written up by the document shepherd to send to the AD. It's close. >> > It's been a long time coming and I'd really object to derailing it by >> > making >> > big additions to it at this late stage in the process. >> > >> >> That's fair enough. I didn't know how far in the process the token >> exchange draft was. In the least, I wanted to make the WG aware of >> our work. We have a decent and growing user base with a problem >> looking for a solution and we're going to get a lot of feedback on >> what we've implemented. At least from our open source project >> perspective, there's a lot more interest in external exchange than >> internal. Which is why I'm posting this. >> >> >> -- >> Bill Burke >> Red Hat > > > > CONFIDENTIALITY NOTICE: This email may contain confidential and privileged > material for the sole use of the intended recipient(s). Any review, use, > distribution or disclosure by others is strictly prohibited. If you have > received this communication in error, please notify the sender immediately > by e-mail and delete the message and any file attachments from your > computer. Thank you. -- Bill Burke Red Hat From nobody Wed Dec 13 11:53:14 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53B4F128CF0 for ; Wed, 13 Dec 2017 11:53:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i_108E5uTEYe for ; Wed, 13 Dec 2017 11:52:53 -0800 (PST) Received: from mail-ua0-x22b.google.com (mail-ua0-x22b.google.com [IPv6:2607:f8b0:400c:c08::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 5DE84126D45 for ; Wed, 13 Dec 2017 11:52:53 -0800 (PST) Received: by mail-ua0-x22b.google.com with SMTP id i92so2395267uad.7 for ; Wed, 13 Dec 2017 11:52:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=/sZ/s78eIMFQbuAPSb7GxhAQv5IbA6VHZZFAA5QZQHk=; b=ims20+Vt4ZtBiuyOxbzcNdptA+oiZvY8uEkV0WqCL1/sAFNf9xWNe3W4jnV6K6hhmk CflPpSN0Kh9oZaZUQITDz1PjVTVt7TxiKLjPTFkwxSv2HDRuW2azUV0njygY32hC7eV/ aBMprxqPc+jLB+u8Zsz0NSwPfgBw9L/CcpvfkMXkILg3c4+G2eZZAkzxX7Vs47lVHGFk dAhVJZ/1EyYVmIglZAZo4xvs3b4WlFea2MO9xKZxYiaz8MpR4HbvxqQ0p11edplw0a90 McdKywYDKRqQbOp8Sa9ZYrZWiwOxF9Gos6ZXGnGEJrdl/u98gYImP9e/rVdN9WMS96eM d4Og== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=/sZ/s78eIMFQbuAPSb7GxhAQv5IbA6VHZZFAA5QZQHk=; b=aboKLeIfGxgw7ykxXkDlqf2YbqCHWPqddJDgPLhyotfP5huodPOlIBOhKtNbIU4m1K jVRGGRt3i9YWl9moH3V05HyUCqQdzLE+CQOBnW3O8sA1AYtpB+SvBiSWyMC1EbHqU8oQ nKd96r2tcuqOUlZOvIwqi/m0lkzC/jtXU+XB0TETS+cdUCzzQkccvHOzKQWt01X3A2kD NzU6Mqx/NH78KL+k5xBDm8KY7SgwQTZpPW/FRtbSPDq50F0VRhoLxQTW9cy6T0FiYvIY SM0c0dhJgJHc1dV6LQTXRWWFetiTCOvbM12EJnXN62Y92d9l74BBs91PcmMM8p10fz2f ySVw== X-Gm-Message-State: AKGB3mJPfyW5qgQ/FPI5+muAj1E4xwlNZ6BQ8ckNT8Lh25thzpbJYxDa +msKORNAdjwB34Fjf1QwMMecN34YxvbpinvKtNYG0yn+ X-Google-Smtp-Source: ACJfBotSMqugyPb4R8II9aa81z+jE3I8dc/YHFAVQ+wZdO8lV3EQpfjAsbFAfCqJzM5mTGiQV0ueHHiPlQoGgBObcFA= X-Received: by 10.159.37.69 with SMTP id 63mr9157912uaz.12.1513194772081; Wed, 13 Dec 2017 11:52:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.68.133 with HTTP; Wed, 13 Dec 2017 11:52:51 -0800 (PST) From: Rifaat Shekh-Yusef Date: Wed, 13 Dec 2017 14:52:51 -0500 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="94eb2c0476c6ddb32605603e1c13" Archived-At: Subject: [OAUTH-WG] Interim Meetings Doodle Poll X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 19:53:03 -0000 --94eb2c0476c6ddb32605603e1c13 Content-Type: text/plain; charset="UTF-8" All, We are looking to schedule *two* Virtual Interim Meetings to discuss the *Distributed OAuth* and *"Mutual" OAuth* documents presented by Dick in Singapore. https://datatracker.ietf.org/doc/draft-hardt-oauth-distributed/ https://datatracker.ietf.org/doc/draft-hardt-oauth-mutual/ It is a real challenge to try to schedule such a meeting that takes into considerations all the various time zones. The following Doodle Poll has the time-slots that we thought would be somewhat reasonable: https://doodle.com/poll/erqrc75gtcmdgtru#table Please, take a look and let us know if you have any comments and choose the best time-slot that works for you. Regards, Rifaat & Hannes --94eb2c0476c6ddb32605603e1c13 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
All,

We are looking to schedule two<= /b> Virtual=C2=A0Interim Meetings to discuss the Distributed OAuth a= nd "Mutual" OAuth documents presented by Dick in Singapore= .

It is a real challenge to try to schedule such a meeting that take= s into considerations all the various time zones.
The following D= oodle Poll has the time-slots that we thought would be somewhat reasonable:=

= Please, take a look and let us know if you have any comments and choose the= best time-slot that works for you.

Regards,
=
=C2=A0Rifaat & Hannes



=
--94eb2c0476c6ddb32605603e1c13-- From nobody Thu Dec 14 01:00:19 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40AE51275C5 for ; Thu, 14 Dec 2017 01:00:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.91 X-Spam-Level: X-Spam-Status: No, score=-2.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YG9X2wM9mzYQ for ; Thu, 14 Dec 2017 01:00:10 -0800 (PST) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40068.outbound.protection.outlook.com [40.107.4.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CA00120046 for ; Thu, 14 Dec 2017 01:00:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=oIMuHVPA0xuM1jfUfXUtrqjwLEc1DowjcN/+9T0xGE4=; b=MqfK0FcWq7rYVp9sTUzDCnw74Ej88EL2OEPzkOxJ9u2qD9OnJEeLV16Sbjy09+bkgqVavEHA8xIIdzW8qdR3nW4lFQQZ3tXEpO35kFK+s3H/UlxmyPAO9se6cFruCO6Ueo/cqJiWLNZexdoFUlonvPbIPriZOKt3kCprZUNHn2c= Received: from AM4PR0801MB2706.eurprd08.prod.outlook.com (10.167.90.148) by AM4PR0801MB2706.eurprd08.prod.outlook.com (10.167.90.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.302.9; Thu, 14 Dec 2017 09:00:06 +0000 Received: from AM4PR0801MB2706.eurprd08.prod.outlook.com ([fe80::b9af:5048:9d97:f7e6]) by AM4PR0801MB2706.eurprd08.prod.outlook.com ([fe80::b9af:5048:9d97:f7e6%14]) with mapi id 15.20.0302.013; Thu, 14 Dec 2017 09:00:06 +0000 From: Hannes Tschofenig To: "oauth@ietf.org" Thread-Topic: 3rd OAuth Security Workshop (OSW 2018) Thread-Index: AdN0uB/T+4wdQKrgRbablUGaZSSlWQ== Date: Thu, 14 Dec 2017 09:00:06 +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=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.123.79] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR0801MB2706; 6:W7cQ/zPt1d8jevzEc7gvaPJtrw/kxco+Uwn+vtyS2OzJ1Z+1mNVjmQcqkDmeIXi0Zt8om2gr5Z3x5A+nTfZnaxmacWB7YYl6KoxWv9kVtD1ZtPUO1SoF6BWhfaVlsALSuNUbSG5mugm3SVgwG3faf54gZE+sPqGpJiCpLDuP54aFiu25E38jq95gmSSbUe+qoF2yAC51odfXLVhrPZDfwFG0wz1k7CdxwyK9k7JVMvyAdtgxaZ/TBUXuGWi443w8nNtlzDxCwR5+QuUJevhCKyi7sr031LmYeUgUC+oHu5z0vEaUzAqVk6M5LavxoUNIWh/espBdnwx+ShcxiCwKgOHuMTWepPQgVbdY8wLZ7pw=; 5:iGjswIIuhCceULOO2AEgfO42KxfutC9oHRMK9sOIZZ+2ezbeBJWKJFZbb/YcXkRXktrXCwjVdiz8JJpxK3bf3EI8ioM7+q7Q0mQ9pPyE9c+MC7Q44Cp85GMfoOKzOK8DCC6Z9XMOrnpKmaO+6xTRAa5Lla8t9K40Nz3VTB30Xs4=; 24:ARwCNJS9hviUr5ndtKi+iTJiofXhBoWlrkmJvaqaFJr8On5HPCuzSIlqg5+7s31g6gbhd/NernJblViIe2Wmc+CXT9aQrt35u5zdEV72b8A=; 7:fGAA/nAWs1cMgRe5dIfnBRRpMF/hgwJhNMD3AsipXJDiFMP2msTWwoOvjb3VUs8eLFZjYXomgM7ziGdr4I0LqeREZoE2yWP0BeY6VRksB3dCrGRH/TPPcil7XWf5vU7hym5fujQWuUkNXolBGiIBx5s5dEXxlqW7B5cQxUTJCk/YmKZkcrEAjZyydxntmJFgOdaa6aIDm4J1D+9GUXStXW5o2POOQG+mNHbWvmdDSqmxMsflYV+W06Hsc0vJ4hcX x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 94c62612-3faf-43dd-316b-08d542d11286 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(48565401081)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(2017052603307); SRVR:AM4PR0801MB2706; x-ms-traffictypediagnostic: AM4PR0801MB2706: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(209352067349851)(192374486261705)(21532816269658); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(5005006)(8121501046)(3231023)(93006095)(93001095)(3002001)(10201501046)(6055026)(6041248)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123560025)(20161123564025)(20161123562025)(6072148)(201708071742011); SRVR:AM4PR0801MB2706; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:AM4PR0801MB2706; x-forefront-prvs: 05214FD68E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(39860400002)(346002)(396003)(366004)(199004)(189003)(53754006)(28244002)(40434004)(81156014)(15650500001)(7736002)(74316002)(33656002)(2900100001)(561944003)(66066001)(81166006)(2906002)(8676002)(305945005)(99286004)(102836003)(6436002)(3846002)(9686003)(5640700003)(1730700003)(53936002)(55016002)(106356001)(5890100001)(2501003)(5250100002)(2351001)(6116002)(6306002)(105586002)(59450400001)(3660700001)(7696005)(3280700002)(8936002)(86362001)(316002)(14454004)(5660300001)(6916009)(25786009)(478600001)(97736004)(966005)(72206003)(4743002)(68736007)(6506007)(45080400002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0801MB2706; H:AM4PR0801MB2706.eurprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 94c62612-3faf-43dd-316b-08d542d11286 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Dec 2017 09:00:06.8238 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0801MB2706 Archived-At: Subject: [OAUTH-WG] 3rd OAuth Security Workshop (OSW 2018) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 09:00:17 -0000 Hi all, at the Singapore IETF meeting I announced the next OAuth security workshop = and provided a link to the website at during the introduction of the OAuth = WG meeting. Below is the call for papers and tutorials. Please keep the deadline (Janua= ry 19, 2018) in mind. The workshop takes place the week before the London I= ETF meeting. We would appreciate your input and contributions since this is our primary = way to reach out to the research community. Ciao Hannes & Rifaat Call for Position Papers and Tutorials =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D Third OAuth Security Workshop (OSW 2018) Fondazione Bruno Kessler Trento, Italy March 14-16, 2018 Workshop website: https://st.fbk.eu/osw2018 =3D=3D About OSW 2018 =3D=3D The OAuth Security Workshop (OSW) aim is to improve the security of OAuth and related Internet protocols by a direct exchange of views between academic researchers, IETF OAuth Working Group members and industry. The workshop is hosted by the Security and Trust research unit of the Bruno Kessler Foundation (FBK). While the standardization process of OAuth ensures extensive reviews (both security and non-security related), further analysis by security experts from academia and industry is essential to ensure high quality specifications. Contributions to this workshop can help to improve the security of the Web and the Internet. =3D=3D Scope and Topics =3D=3D We seek position papers related to OAuth, OpenID Connect, and other technologies using OAuth under the hood. Contributions regarding technologies that are used in OAuth, such as JOSE, or impact the security of OAuth, such as Web technology, are also welcome. Areas of interest where OAuth can be used as enabler of innovative scenarios include: - IoT, SmartCities and Industry 4.0. - Mobile and Strong authentication. - Federated Identity. - Privacy-enhancing technologies. =3D=3D Important Dates =3D=3D - Position paper and Tutorial submission deadline: January 19, 2018 (AoE, UTC-12). - Author notification: February 5, 2018 - Workshop: Wed, March 14, 2018 (half-day), Thu, March 15, 2018 (full-day),= and Fri, March 16, 2018 (half day) =3D=3D Submissions =3D=3D We solicit position papers that highlight challenges and lesson-learned from OAuth-based work. As all papers and presentations will be shared online without formal proceedings, we accept different kinds of submissions= : from original contributions to already published or preliminary works. Submissions must be in PDF format and should feature reasonable margins and formatting. There is no page limit, but the submission should be brief (ideally not more than 3-5 pages). Submissions should not be anonymized. Authors of accepted papers will have the option to revise their papers before they are put online. One of the authors of the accepted position paper is expected to present the paper at the workshop. The workshop will host a half-day (March 14, 2018) tutorial program. Each tutorial proposal should concisely describe the content and objectives of the tutorial, and include: - title - abstract - outline of the tutorial content - intended audience, including possible assumed background of attendees - name, affiliation, email address, and brief biography of the speaker(s) - duration: 1 hour or 2 hours Tutorial proposals should be submitted as a PDF file. Submissions should be distinguished by the prefix "Tutorial:" in the title. Submission Website: https://easychair.org/conferences/?conf=3Dosw2018 =3D=3D IPR Policy =3D=3D The workshop will have no expectation of IPR disclosure or licensing related to its submissions. Authors are responsible for obtaining appropriate publication clearances. =3D=3D Workshop Chair =3D=3D - Silvio Ranise (Security & Trust, Fondazione Bruno Kessler) =3D=3D Program Committee =3D=3D Chairs - Roberto Carbone (Security & Trust, Fondazione Bruno Kessler) - Hannes Tschofenig (IETF OAuth Working Group Co-Chair) Members - Michael Jones (Microsoft) - Ralf Kuesters (University of Stuttgart) - Torsten Lodderstedt (YES Europe AG) - Chris Mitchell (Royal Holloway, University of London) - Anthony Nadalin (Microsoft) - Nat Sakimura (Nomura Research Institute) - Antonio Sanso (Adobe) - Ralf Sasse (ETH Zurich) - Joerg Schwenk (Ruhr-Universit=E4t Bochum) - Giada Sciarretta (Security & Trust, Fondazione Bruno Kessler and Univ. of= Trento) =3D=3D Conference site and contacts =3D=3D For more detailed information please refer to the workshop web site: https://st.fbk.eu/osw2018 If you have any questions on OSW18, please contact carbone [at] fbk [dot] eu, giada.sciarretta [at] fbk [dot] eu IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease 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. From nobody Thu Dec 14 05:42:37 2017 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 243F31292AE; Thu, 14 Dec 2017 05:42:27 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Rifaat Shekh-Yusef To: X-Test-IDTracker: no X-IETF-IDTracker: 6.67.1 Auto-Submitted: auto-generated Precedence: bulk Cc: Rifaat Shekh-Yusef , rifaat.ietf@gmail.com, oauth@ietf.org, iesg-secretary@ietf.org, Hannes Tschofenig , oauth-chairs@ietf.org Message-ID: <151325894714.6198.3114046031218096256.idtracker@ietfa.amsl.com> Date: Thu, 14 Dec 2017 05:42:27 -0800 Archived-At: Subject: [OAUTH-WG] Publication has been requested for draft-ietf-oauth-token-exchange-10 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 13:42:27 -0000 Rifaat Shekh-Yusef has requested publication of draft-ietf-oauth-token-exchange-10 as Proposed Standard on behalf of the OAUTH working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/ From nobody Thu Dec 14 14:43:57 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91FA912741D for ; Thu, 14 Dec 2017 14:43:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X0F63yUf8g-q for ; Thu, 14 Dec 2017 14:43:52 -0800 (PST) Received: from mail-yb0-x233.google.com (mail-yb0-x233.google.com [IPv6:2607:f8b0:4002: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 244E21242F5 for ; Thu, 14 Dec 2017 14:43:52 -0800 (PST) Received: by mail-yb0-x233.google.com with SMTP id x83so4742314ybg.8 for ; Thu, 14 Dec 2017 14:43:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=whyBPXHwAtntF8XWgPa3oCMchkYNrYaYGyFDhiGqoA0=; b=rZVX8jqU927swPMSq+ZRGWWHds0prddKwPL3reMbhp2K4ksYIC0nChkHWWlzcNDrlo lk4Fi4EpdTewNFEULV7B1/6uJc1VGSEPJNRi/ZA94emPHLVviOjYq4IdQ4wtGKigDg5H 2FuaeGPlQ+LGcLjZwHiXl/YB5qX0/vs7zCdUNP1X/XVBJemynCrTXQsPkKIpytF34SxY wVKg2SgcXxa8Xg3vcnq5uheE7+oemGyBoYrXm2pfvpxLSf0HOG0IC0823ruBRzwtDSeR a2v5+uviaSyOCG4goUTzizDweD6QOp/FEOqpGe8nGCuuoEIqQA89i1Gjl+BWWbX9zqqk pWcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=whyBPXHwAtntF8XWgPa3oCMchkYNrYaYGyFDhiGqoA0=; b=stEaeL0YlKTz6q7G8bnf4Cj/ch0xcTmdvSMOU2yBOut6lVg2LkHwGrx0lUW4BI5ihq XEvkZhXi5ufHRkOnu4vlJ4YkP27WskV2WvBkb3Krx4UxdIWRYYLuSbeHq52IUFpbpC0W v0TvYQJ/aikXOED11PfBQvSWfiETSBvXMkiQ5DpUxWNYk3xeBd9ZtzzwALN2K1F45CWw ZSRkjKnvIWbeM0FBhX8tNsfeAgzsVzuQIscrFRhGkpBeZwbSOJ7SO+j6WZYEvQqTSnE+ Lz8hf0Lrs/Cb5Z8a0n2z1efe8tEiX1MNbu3KyqIjSgzbeSQjeVCKjgzIF1MlzfURs3wM arwA== X-Gm-Message-State: AKGB3mK6EW5azRTXbAssY7XIxXfGRbDSX/uIU08Np7WRfArpg/hahPLN FKUbs2G4UIkgufSLtDm7n+vAw6mMobf0naCtH+nVrQcS X-Google-Smtp-Source: ACJfBouLAPcpTJYKzI8EB06aMRYed6ORwZuZm0KKu5RwTbKB5/duhGKeG00Eu7WVGOxFTwEiHYe+oULzmoaD9FllXzc= X-Received: by 10.37.185.5 with SMTP id x5mr5754527ybj.393.1513291429708; Thu, 14 Dec 2017 14:43:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.160.146 with HTTP; Thu, 14 Dec 2017 14:43:29 -0800 (PST) In-Reply-To: <4e14a1ec-8b6d-476b-3949-8a0b63017232@connect2id.com> References: <4e14a1ec-8b6d-476b-3949-8a0b63017232@connect2id.com> From: William Denniss Date: Thu, 14 Dec 2017 14:43:29 -0800 Message-ID: To: Vladimir Dzhuvinov Cc: oauth@ietf.org Content-Type: multipart/alternative; boundary="089e08267e8c1cdcfa0560549e77" Archived-At: Subject: Re: [OAUTH-WG] WGLC for OAuth 2.0 Device Flow for Browserless and Input Constrained Devices X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 22:43:55 -0000 --089e08267e8c1cdcfa0560549e77 Content-Type: text/plain; charset="UTF-8" On Fri, Dec 8, 2017 at 11:42 AM, Vladimir Dzhuvinov wrote: > Hi, > > I just got a question on Twitter about the slow_down error: > > https://tools.ietf.org/html/draft-ietf-oauth-device-flow-07#section-3.5 > > The question was why slow_down is communicated via HTTP status code 400 > and not 429 (Too Many Requests). > We could, it seems to match the intent of that error code. Main reason it's not like that so far is that 400 is the default for OAuth, I fear people may not be checking for a 429. We don't strictly *need* the 429, since we're returning data in machine readable format one way or another (i.e. it's easy for the client to extract the "slow_down" response either way), which differs from HTML over HTTP which is intended for end-user consumption, making the specific status code more important. What do others think about this? It's a simple change to make. > > Thanks, > > Vladimir > > > On 27/11/17 15:55, Rifaat Shekh-Yusef wrote: > > All, > > > > As discussed in Singapore, we are starting a WGLC for the > > *draft-ietf-oauth-device-flow-07* document, starting today and ending on > > December 11, 2018. > > https://datatracker.ietf.org/doc/draft-ietf-oauth-device-flow/ > > > > Please, review the document and provide feedback on the list. > > > > Regards, > > Rifaat & Hannes > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --089e08267e8c1cdcfa0560549e77 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

= On Fri, Dec 8, 2017 at 11:42 AM, Vladimir Dzhuvinov <<= a href=3D"mailto:vladimir@connect2id.com" target=3D"_blank">vladimir@connec= t2id.com> wrote:
Hi,

I just got a question on Twitter about the slow_down error:

https://tools.ietf.org/html/d= raft-ietf-oauth-device-flow-07#section-3.5

The question was why slow_down is communicated via HTTP status code 400
and not 429 (Too Many Requests).

We cou= ld, it seems to match the intent of that error code. Main reason it's n= ot like that so far is that 400 is the default for OAuth, I fear people may= not be checking for a 429. We don't strictly need the 429, sinc= e we're returning data in machine readable format one way or another (i= .e. it's easy for the client to extract the "slow_down" respo= nse either way), which differs from HTML over HTTP which is intended for en= d-user consumption, making the specific status code more important.

What do others think about this? It's a simple change= to make.
=C2=A0

Thanks,

Vladimir


On 27/11/17 15:55, Rifaat Shekh-Yusef wrote:
> All,
>
> As discussed in Singapore, we are starting a WGLC for the
> *draft-ietf-oauth-device-flow-07* document, starting today= and ending on
> December 11, 2018.
> https://datatracker.ietf.org/doc/draft-ietf-oauth-device-flow/
>
> Please, review the document and provide feedback on the list.
>
> Regards,
>=C2=A0 Rifaat & Hannes



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


--089e08267e8c1cdcfa0560549e77-- From nobody Thu Dec 14 14:44:07 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35AFB1293EB for ; Thu, 14 Dec 2017 14:44:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XttPbueM1LKI for ; Thu, 14 Dec 2017 14:43:56 -0800 (PST) Received: from mail-yb0-x234.google.com (mail-yb0-x234.google.com [IPv6:2607:f8b0:4002: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 07F8A128C81 for ; Thu, 14 Dec 2017 14:43:56 -0800 (PST) Received: by mail-yb0-x234.google.com with SMTP id 69so4744408ybc.6 for ; Thu, 14 Dec 2017 14:43:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=shDH03YL0OW5Fb1j4Biy+yX38oGfNSgy5dXo7LM8QRc=; b=ccAaGw+/ANU8ad/DB7/cDnU4wVtSxIxn08QBlSGsKIuJI9S8H5M6sDX6XpByjFdsse TZYZ/lG55DYBlXFwyEAYYlCv4eln93pXHBbf3GhIGnbbeMP1NWl6ja3kgWuIUBY2j6oo UG7/HWpxcniU8RBPc7fdXkcGjK6k1kf/fqOXFJOQcP9g1pJ+FwgGFAeLTPJ9EcNexE2l vnwo67KkLqG7KwlkEKuyw1prq6bFNywwwH+E6VEswjrzGK9A0BGa7FO6TJzoeDuMIK9S vGVbw1kvGEGEEiYzduHYiS/sRvMAOmmxOroJft6O8qpIQTmq0pnRYGAH+0An4jnH++0I nWxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=shDH03YL0OW5Fb1j4Biy+yX38oGfNSgy5dXo7LM8QRc=; b=LZ5PESlfiq2l78fzGZ4xO8Grtqig9cxd1sSW05I40Ao1hi8J6CJmQuvu62w9LOOFP4 UKoei4qcOW8/JPed3bg+UtM+xZInS7mXIAe9H7zOQvfF6Vw76Mjra2TAMY8nCMdlDUnM GA7UpXNPuHiUwhfAxxH1Ce86syD53+20apU9YxO3cNfj0w48PaH9vUXOTpn6o81pzgYo svBBZ1wL0qKqj/jzBJure/6/hddKDuLyNXeKHdp2KLcgDwW103JQClINBnsp4qp6ZjRx BYIVnPvMI9X8iqNfvwvKvjMFMN2aXz2kBvSmtesJmKnvSnqdo/kpjfH9UxmxuU1NBBAp brjg== X-Gm-Message-State: AKGB3mK4ou9pkYJLNXHwaVwNFnbm8h1SclqBOXz1GTbT+7l4ZVU7nktH fZXuxPhGuk9sLjH6e+buiCnNgJ8HlFGcDcNNTx1QdDQM X-Google-Smtp-Source: ACJfBotloDZ9UUpZCCp6BcwMhkmt13GW19qU08uuvQu0eqDZLMtEU/ellhJgHkV6Pzu1EGEKti2UKxrPb3d5LZclImA= X-Received: by 10.129.76.130 with SMTP id z124mr5339243ywa.187.1513291434931; Thu, 14 Dec 2017 14:43:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.160.146 with HTTP; Thu, 14 Dec 2017 14:43:34 -0800 (PST) In-Reply-To: References: From: William Denniss Date: Thu, 14 Dec 2017 14:43:34 -0800 Message-ID: To: Brian Campbell Cc: Rifaat Shekh-Yusef , oauth Content-Type: multipart/alternative; boundary="001a113f17006c834b0560549e0a" Archived-At: Subject: Re: [OAUTH-WG] WGLC for OAuth 2.0 Device Flow for Browserless and Input Constrained Devices X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 22:44:01 -0000 --001a113f17006c834b0560549e0a Content-Type: text/plain; charset="UTF-8" On Mon, Dec 11, 2017 at 8:46 AM, Brian Campbell wrote: > I couldn't get the QR code to work... ;) > Mild shock! ;-) > On Mon, Nov 27, 2017 at 6:55 AM, Rifaat Shekh-Yusef > wrote: > >> All, >> >> As discussed in Singapore, we are starting a WGLC for the >> *draft-ietf-oauth-device-flow-07* document, starting today and ending on >> December 11, 2018. >> https://datatracker.ietf.org/doc/draft-ietf-oauth-device-flow/ >> >> Please, review the document and provide feedback on the list. >> >> Regards, >> Rifaat & Hannes >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited. > If you have received this communication in error, please notify the sender > immediately by e-mail and delete the message and any file attachments from > your computer. Thank you.* > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --001a113f17006c834b0560549e0a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

= On Mon, Dec 11, 2017 at 8:46 AM, Brian Campbell <bcampbell@pingid= entity.com> wrote:
I couldn't get the QR code to work... ;)

Mild shock! ;-)


On Mon, No= v 27, 2017 at 6:55 AM, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com&g= t; wrote:
All,

A= s discussed in Singapore, we are starting a WGLC for the=C2=A0draft-ietf= -oauth-device-flow-07 document, starting today and ending on Decem= ber 11, 2018.

Pl= ease, review the document and provide feedback on the list.
<= br>
Regards,
=C2=A0Rifaat & Hannes


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



<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you.
____________________= ___________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


--001a113f17006c834b0560549e0a-- From nobody Thu Dec 14 15:04:01 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E471E126CBF for ; Thu, 14 Dec 2017 15:03:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q840i0FhiJnX for ; Thu, 14 Dec 2017 15:03:56 -0800 (PST) Received: from mail-yb0-x233.google.com (mail-yb0-x233.google.com [IPv6:2607:f8b0:4002: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 DEF891205F0 for ; Thu, 14 Dec 2017 15:03:55 -0800 (PST) Received: by mail-yb0-x233.google.com with SMTP id r4so4765304ybd.12 for ; Thu, 14 Dec 2017 15:03:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9uCQZ3uBfCC16Tgv17rqmNhG66X2gd6BAwPyjdixeUI=; b=vThNtliUf5K4LCMod1npLUR59NPhgFqy/ik6/uDoPlhziiRxdcto4kQ+yOsAnUdTGj vVwfoeXGPQ63wI6hA4Q+OTKXGZ3J4Yh4mC5xLnXuoXCF86nv1wF0rWMQqIRvLVFbVZHr bO2TfQG0Pqjzy9d64m2jx5miFww8hijtQlzipQe/tg0leOEqCOaIz6uhlhS6XLoeB7Zs X3+CKKeBp3q9C0Jg4aU8R43kYA9CKwGjeFe7L2KDyzYRsXXzhkqv4dOXUmGQWO/Xv3rL /xcbNSZgaVaEPJgXEBW5v8I+vxhf9y5rkoP0mwBEvA6KOMA100IQl9bIHZr6Jz53ypU6 kCXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9uCQZ3uBfCC16Tgv17rqmNhG66X2gd6BAwPyjdixeUI=; b=sOxjctuVu8dxMhcPu+DqNAxfAKc6sS4pgr7a2I70eE1QJ9FWuxcMTF+FZL4zVuX+6L SzqWyrJZpj62/yv1HseKwhEp+4olHvdgkHaGSqUv8MOfnuYoQoTlHL+Z0OJGykjQ4PjW BFXb12fiUud1hC9vMohSduizPysDWpMC/WrIDvdTmmKoZwBxGlJdM+3DBFY4FC1kuTqp AodnmmU2CyzCz7wBKYWdvXarw2iL2saBKf52BbCOX7dgQZS+By/1Lg6fr2iqMlYUzaYE uJRFtKOff0/dRlB1oxwxKsHLI34DlzAUVHQGlB2wEltdJKutSzJ0uGVnfGGkjmIlL9tm CkBA== X-Gm-Message-State: AKGB3mKe4XtU3uv/Z4ZqMYd6HyBgq1tiEX/LD17ZVI9GmGciULfWfyjr ryQlFKv9j9wrMDm8pKAnfprkESvIkNcgVWrO51Nsng/d X-Google-Smtp-Source: ACJfBoskPgAerKq+IIzPW71UY+rFU5yZRZA3jXh+Xs6IMuU5Zkm5BY01g8fOraE//RKaesN9aFX6b8s5x6T+PfACsgg= X-Received: by 10.37.172.212 with SMTP id x20mr5619512ybd.512.1513292634567; Thu, 14 Dec 2017 15:03:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.160.146 with HTTP; Thu, 14 Dec 2017 15:03:34 -0800 (PST) In-Reply-To: References: From: William Denniss Date: Thu, 14 Dec 2017 15:03:34 -0800 Message-ID: To: Justin Richer Cc: Jaap Francke , "" Content-Type: multipart/alternative; boundary="f403045ec2d4ed698b056054e53d" Archived-At: Subject: Re: [OAUTH-WG] WGLC for OAuth 2.0 Device Flow for Browserless and Input Constrained Devices (Brian Campbell) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 23:04:00 -0000 --f403045ec2d4ed698b056054e53d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable This suggestion was considered by the working group, I raised the proposal at IETF98, you can see the recording . The WG rejected the inclusion of this construct in the device flow specification, but as Justin suggested, the door is open for a standalone document so that it could be useful for *all* OAuth clients, not just device flow ones. On Mon, Dec 11, 2017 at 12:41 PM, Justin Richer wrote: > This could be useful but shouldn=E2=80=99t be done in a way that=E2=80=99= s tied to the > device flow =E2=80=94 any public client would suffer from the same fate. > > =E2=80=94 Justin > > > On Dec 11, 2017, at 3:19 PM, Jaap Francke > wrote: > > > > Hi all, > > > > I have previously made the following suggestion which still makes sense > to me. > > > > [=E2=80=A6]we were working with one of our customers to implement the d= evice > flow as part of our IDaaS. > > One of the requirements was the ability to revoke tokens for one of the > devices at the Resource Server. > > > > In our use case, we used the terminolgy =E2=80=98pairing a device to th= e > enduser=E2=80=99s account=E2=80=99 to describe the process of authorising= a device to > access the resource owner=E2=80=99s resources. > > The resource owner may want to =E2=80=98unpair=E2=80=99 a device from a= list of paired > devices without having access to the device itself (anymore). Think about= a > stolen/lost kind of situation. > > We are looking for ways to allow the user to unpair one of his devices > at the Authorisation Server. > > Since the Device Flow exchanges only the =E2=80=98generic=E2=80=99 clie= nt_id with the > Authorisation Server, there is no logical way at the Resource Server to > make a distinction between various devices (having the same client_id) th= at > may be paired to the same Resource Owner. > > > > My suggestion is the following > > - add an optional parameter to the device authorisation request (or > device access token request): 'device_identifier'. A device can use this = to > make (for example) its serial-number known at the Resource Server. > > - add an optional parameter to the device access token response that > allows to communicate a name for the device as may have been given to it = by > the resource owner while allowing the clients access (E). This parameter > could be something like =E2=80=98device_name=E2=80=99. The device may be = able to display > this =E2=80=98device_name=E2=80=99 on its display. > > > > Please consider this as a suggested enhancement of the Device Flow > specifications. > > > > > > Kind regards, > > > > Jaap > >> On 11 Dec 2017, at 18:56, oauth-request@ietf.org wrote: > >> > >> Send OAuth mailing list submissions to > >> oauth@ietf.org > >> > >> To subscribe or unsubscribe via the World Wide Web, visit > >> https://www.ietf.org/mailman/listinfo/oauth > >> or, via email, send a message with subject or body 'help' to > >> oauth-request@ietf.org > >> > >> You can reach the person managing the list at > >> oauth-owner@ietf.org > >> > >> When replying, please edit your Subject line so it is more specific > >> than "Re: Contents of OAuth digest..." > >> > >> > >> Today's Topics: > >> > >> 1. Re: WGLC for OAuth 2.0 Device Flow for Browserless and Input > >> Constrained Devices (Brian Campbell) > >> 2. Re: I-D Action: draft-ietf-oauth-token-exchange-10.txt > >> (Justin Richer) > >> > >> > >> ---------------------------------------------------------------------- > >> > >> Message: 1 > >> Date: Mon, 11 Dec 2017 09:46:09 -0700 > >> From: Brian Campbell > >> To: Rifaat Shekh-Yusef > >> Cc: oauth > >> Subject: Re: [OAUTH-WG] WGLC for OAuth 2.0 Device Flow for Browserless > >> and Input Constrained Devices > >> Message-ID: > >> mW_A@mail.gmail.com> > >> Content-Type: text/plain; charset=3D"utf-8" > >> > >> I couldn't get the QR code to work... ;) > >> > >> On Mon, Nov 27, 2017 at 6:55 AM, Rifaat Shekh-Yusef < > rifaat.ietf@gmail.com> > >> wrote: > >> > >>> All, > >>> > >>> As discussed in Singapore, we are starting a WGLC for the > >>> *draft-ietf-oauth-device-flow-07* document, starting today and ending > on > >>> December 11, 2018. > >>> https://datatracker.ietf.org/doc/draft-ietf-oauth-device-flow/ > >>> > >>> Please, review the document and provide feedback on the list. > >>> > >>> Regards, > >>> Rifaat & Hannes > >>> > >>> > >>> _______________________________________________ > >>> OAuth mailing list > >>> OAuth@ietf.org > >>> https://www.ietf.org/mailman/listinfo/oauth > >>> > >>> > >> > >> -- > >> *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged > >> material for the sole use of the intended recipient(s). Any review, us= e, > >> distribution or disclosure by others is strictly prohibited. If you > have > >> received this communication in error, please notify the sender > immediately > >> by e-mail and delete the message and any file attachments from your > >> computer. Thank you.* > >> -------------- next part -------------- > >> An HTML attachment was scrubbed... > >> URL: 20171211/119c614c/attachment.html> > >> > >> ------------------------------ > >> > >> Message: 2 > >> Date: Mon, 11 Dec 2017 12:56:21 -0500 > >> From: Justin Richer > >> To: Brian Campbell > >> Cc: Denis , "" > >> Subject: Re: [OAUTH-WG] I-D Action: > >> draft-ietf-oauth-token-exchange-10.txt > >> Message-ID: <94AA427C-744B-4A33-AEFC-A5F276C911A2@mit.edu> > >> Content-Type: text/plain; charset=3D"utf-8" > >> > >> +1 to Brian > >> > >> -1 to the proposed text from Denis > >> > >> > >>> On Dec 8, 2017, at 8:48 PM, Brian Campbell > wrote: > >>> > >>> The privacy matter is already mentioned. Despite your many messages t= o > this WG and others about the so called ABC attack, I do not believe it > warrants treatment in this document or others. And your continued proposa= ls > to have it included in documents have not gotten support. > >>> > >>> On Fri, Dec 8, 2017 at 2:46 PM, Denis denis.ietf@free.fr>> wrote: > >>> RFC 3552 (Guidelines for Writing RFC Text on Security Considerations) > states: > >>> > >>> All RFCs are required by RFC 2223 to contain a Security > >>> Considerations section. The purpose of this is both to encourage > >>> document authors to consider security in their designs and to inform > >>> the reader of relevant security issues. This memo is intended to > >>> provide guidance to RFC authors in service of both ends. > >>> > >>> Section 5 (Writing Security Considerations Sections) of RFC 3552 > states: > >>> > >>> While it is not a requirement that any given protocol or system be > >>> immune to all forms of attack, it is still necessary for authors to > >>> consider as many forms as possible. Part of the purpose of the > >>> Security Considerations section is to explain what attacks are out o= f > >>> scope and what countermeasures can be applied to defend against them > >>> > >>> There should be a clear description of the kinds of threats on the > >>> described protocol or technology. > >>> > >>> It is important to mention the threat related to collusion attacks. A > different wording could be used, > >>> but the threat should be mentioned one way or another. > >>> > >>> RFC 6973 (Privacy Considerations for Internet Protocols) intends to > provide a similar set of guidelines > >>> for considering privacy in protocol design. > >>> > >>> It is important to mention a current threat related to privacy. A > different wording could be used, > >>> e.g. using the word "surveillance" as mentioned in 5.1.1 : > "Surveillance is the observation or monitoring > >>> of an individual?s communications or activities", but the threat > should be mentioned one way or another. > >>> > >>> Denis > >>> > >>>> I believe the text would detract from the document. > >>>> From: OAuth > on behalf of Brian Campbell bcampbell@pingidentity.com> > >>>> Sent: Friday, December 8, 2017 3:47:32 PM > >>>> To: Denis > >>>> Cc: oauth > >>>> Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-token- > exchange-10.txt > >>>> > >>>> As an individual, I do not believe that the proposed text should be > incorporated into the draft. > >>>> > >>>> As one of the document editors, my responsibility is for the documen= t > to be of reasonable quality and to reflect the rough consensus of this > Working Group. So I should ask the list more explicitly - are there other > WG remembers who are in favor of the proposed text here (the text would > have to be fixed up some too)? > >>>> > >>>> On Fri, Dec 1, 2017 at 11:12 AM, Denis denis.ietf@free.fr>> wrote: > >>>> Comments on draft-ietf-oauth-token-exchange-10 > >>>> > >>>> I propose the following rephrasing for sections 6 and 7: > >>>> > >>>> 6 . Security Considerations > >>>> > >>>> All of the normal security issues that are discussed in > [JWT],especially in relationship to comparing URIs > >>>> and dealing with unrecognized values, also apply here. In addition, > both delegation and impersonation introduce > >>>> unique security issues. Any time one user receives a token, the > potential for abuse is a concern, > >>>> since that user might be willing to collude with another user so tha= t > other user could use the token. > >>>> > >>>> Techniques like the binding of an access token to a TLS channel > described elsewhere are ineffective since > >>>> the legitimate user would be able to perform all the cryptographic > computations that the other user would need > >>>> to demonstrate the ownership of the token. The use of the "scp" clai= m > is suggested to mitigate potential for > >>>> such abuse, as it restricts the contexts in which the token can be > exercised. If the issued access token scope > >>>> allows to unambiguously identify the user, then that user is likely > to be reluctant to collude with another user. > >>>> However, if the issued access token scope only indicates that the > user is over 18, then there is no risk > >>>> for the original user to be discovered and in such a context a > collusion may easily take place. > >>>> This document does not specify techniques to prevent such a collusio= n > to be successful. > >>>> > >>>> 7 . Privacy Considerations > >>>> > >>>> Tokens typically carry personal information and their usage in Token > Exchange may reveal details of the target services > >>>> being accessed. The resource and the audience parameters allow > authorization servers to know where the issued access token > >>>> will be used. This may be a privacy concern for some users. This > document does not specify techniques to prevent > >>>> authorization servers to know where the access tokens they issue wil= l > be used. > >>>> > >>>> Denis > >>>>> A New Internet-Draft is available from the on-line Internet-Drafts > directories. > >>>>> This draft is a work item of the Web Authorization Protocol WG of > the IETF. > >>>>> > >>>>> Title : OAuth 2.0 Token Exchange > >>>>> Authors : Michael B. Jones > >>>>> Anthony Nadalin > >>>>> Brian Campbell > >>>>> John Bradley > >>>>> Chuck Mortimore > >>>>> Filename : draft-ietf-oauth-token-exchange-10.txt > >>>>> Pages : 32 > >>>>> Date : 2017-11-30 > >>>>> > >>>>> Abstract: > >>>>> This specification defines a protocol for an HTTP- and JSON- based > >>>>> Security Token Service (STS) by defining how to request and obtain > >>>>> security tokens from OAuth 2.0 authorization servers, including > >>>>> security tokens employing impersonation and delegation. > >>>>> > >>>>> > >>>>> The IETF datatracker status page for this draft is: > >>>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/ < > https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/> > >>>>> > >>>>> There are also htmlized versions available at: > >>>>> https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-10 < > https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-10> > >>>>> https://datatracker.ietf.org/doc/html/draft-ietf-oauth- > token-exchange-10 token-exchange-10> > >>>>> > >>>>> A diff from the previous version is available at: > >>>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-token-exchange= -10 > > >>>>> > >>>>> > >>>>> Please note that it may take a couple of minutes from the time of > submission > >>>>> until the htmlized version and diff are available at tools.ietf.org > . > >>>>> > >>>>> Internet-Drafts are also available by anonymous FTP at: > >>>>> ftp://ftp.ietf.org/internet-drafts/ drafts/> > >>>>> > >>>>> _______________________________________________ > >>>>> OAuth mailing list > >>>>> OAuth@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/oauth < > https://www.ietf.org/mailman/listinfo/oauth> > >>>> > >>>> > >>>> _______________________________________________ > >>>> OAuth mailing list > >>>> OAuth@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/oauth < > https://www.ietf.org/mailman/listinfo/oauth> > >>>> > >>>> > >>>> > >>>> CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited. > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you. > >>> > >>> > >>> > >>> CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited. > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you._______________________________________________ > >>> OAuth mailing list > >>> OAuth@ietf.org > >>> https://www.ietf.org/mailman/listinfo/oauth < > https://www.ietf.org/mailman/listinfo/oauth> > >> -------------- next part -------------- > >> An HTML attachment was scrubbed... > >> URL: 20171211/dbd247f6/attachment.html> > >> > >> ------------------------------ > >> > >> Subject: Digest Footer > >> > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > >> > >> > >> ------------------------------ > >> > >> End of OAuth Digest, Vol 110, Issue 8 > >> ************************************* > > > > _______________________________________________ > > 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 > --f403045ec2d4ed698b056054e53d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This suggestion was considered by the working group, I rai= sed the proposal at IETF98, you can see the recording.

The WG rejected the = inclusion of this construct in the device flow specification, but as Justin= suggested, the door is open for a standalone document so that it could be = useful for *all* OAuth clients, not just device flow ones.

On Mon, Dec 11, 2017 a= t 12:41 PM, Justin Richer <jricher@mit.edu> wrote:
This could be useful but shouldn=E2=80=99t be done i= n a way that=E2=80=99s tied to the device flow =E2=80=94 any public client = would suffer from the same fate.

=C2=A0=E2=80=94 Justin

> On Dec 11, 2017, at 3:19 PM, Jaap Francke <jaap.francke@iwelcome.com> wrote:
>
> Hi all,
>
> I have previously made the following suggestion which still makes sens= e to me.
>
> [=E2=80=A6]we were working with one of our customers to implement the = device flow as part of our IDaaS.
> One of the requirements was the ability to revoke tokens for one of th= e devices at the Resource Server.
>
> In our use case, we used the terminolgy =E2=80=98pairing a device to t= he enduser=E2=80=99s account=E2=80=99 to describe the process of authorisin= g a device to access the resource owner=E2=80=99s resources.
> The resource owner may want to =E2=80=98unpair=E2=80=99 a device from = a list of paired devices without having access to the device itself (anymor= e). Think about a stolen/lost kind of situation.
> We are looking for ways to allow the user to unpair one of his devices= at the Authorisation Server.
> Since the Device Flow exchanges only the =E2=80=98generic=E2=80=99 cli= ent_id with the Authorisation Server, there is no logical way at the Resour= ce Server to make a distinction between various devices (having the same cl= ient_id) that may be paired to the same Resource Owner.
>
> My suggestion is the following
> - add an optional parameter to the device authorisation request (or de= vice access token request): 'device_identifier'. A device can use t= his to make (for example) its serial-number known at the Resource Server. > - add an optional parameter to the device access token response that a= llows to communicate a name for the device as may have been given to it by = the resource owner while allowing the clients access (E). This parameter co= uld be something like =E2=80=98device_name=E2=80=99. The device may be able= to display this =E2=80=98device_name=E2=80=99 on its display.
>
> Please consider this as a suggested enhancement of the Device Flow spe= cifications.
>
>
> Kind regards,
>
> Jaap
>> On 11 Dec 2017, at 18:56, oauth-request@ietf.org wrote:
>>
>> Send OAuth mailing list submissions to
>>=C2=A0 =C2=A0 =C2=A0 oauth@ietf.o= rg
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>>=C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman= /listinfo/oauth
>> or, via email, send a message with subject or body 'help' = to
>>=C2=A0 =C2=A0 =C2=A0 oaut= h-request@ietf.org
>>
>> You can reach the person managing the list at
>>=C2=A0 =C2=A0 =C2=A0 oauth-= owner@ietf.org
>>
>> When replying, please edit your Subject line so it is more specifi= c
>> than "Re: Contents of OAuth digest..."
>>
>>
>> Today's Topics:
>>
>>=C2=A0 1. Re: WGLC for OAuth 2.0 Device Flow for Browserless and In= put
>>=C2=A0 =C2=A0 =C2=A0Constrained Devices (Brian Campbell)
>>=C2=A0 2. Re: I-D Action: draft-ietf-oauth-token-exchange-10.t= xt
>>=C2=A0 =C2=A0 =C2=A0(Justin Richer)
>>
>>
>> ------------------------------------------------------------<= wbr>----------
>>
>> Message: 1
>> Date: Mon, 11 Dec 2017 09:46:09 -0700
>> From: Brian Campbell <bcampbell@pingidentity.com>
>> To: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
>> Cc: oauth <oauth@ietf.org= >
>> Subject: Re: [OAUTH-WG] WGLC for OAuth 2.0 Device Flow for Browser= less
>>=C2=A0 =C2=A0 =C2=A0 and Input Constrained Devices
>> Message-ID:
>>=C2=A0 =C2=A0 =C2=A0 <CA+k3eCRzTe2Xt_N-9mwsnc4WCdyWo3UTRe= =3DUUnzcgidGpqmW_A@m= ail.gmail.com>
>> Content-Type: text/plain; charset=3D"utf-8"
>>
>> I couldn't get the QR code to work... ;)
>>
>> On Mon, Nov 27, 2017 at 6:55 AM, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
>> wrote:
>>
>>> All,
>>>
>>> As discussed in Singapore, we are starting a WGLC for the
>>> *draft-ietf-oauth-device-flow-07* document, starting toda= y and ending on
>>> December 11, 2018.
>>> https://datatracker.ietf.= org/doc/draft-ietf-oauth-device-flow/
>>>
>>> Please, review the document and provide feedback on the list.<= br> >>>
>>> Regards,
>>> Rifaat & Hannes
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/o= auth
>>>
>>>
>>
>> --
>> *CONFIDENTIALITY NOTICE: This email may contain confidential and p= rivileged
>> material for the sole use of the intended recipient(s). Any review= , use,
>> distribution or disclosure by others is strictly prohibited.=C2=A0= If you have
>> received this communication in error, please notify the sender imm= ediately
>> by e-mail and delete the message and any file attachments from you= r
>> computer. Thank you.*
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <https://mailarchive.ietf.org/arch/browse/oauth/attachments= /20171211/119c614c/attachment.html>
>>
>> ------------------------------
>>
>> Message: 2
>> Date: Mon, 11 Dec 2017 12:56:21 -0500
>> From: Justin Richer <jricher= @mit.edu>
>> To: Brian Campbell <bcampbell@pingidentity.com>
>> Cc: Denis <denis.ietf@fre= e.fr>, "<oauth@ietf.org>" <oauth@ietf.org> >> Subject: Re: [OAUTH-WG] I-D Action:
>>=C2=A0 =C2=A0 =C2=A0 draft-ietf-oauth-token-exchange-10.txt >> Message-ID: <94AA427C-744B-4A33-AEFC-A5F276C911A2@mit.edu>
>> Content-Type: text/plain; charset=3D"utf-8"
>>
>> +1 to Brian
>>
>> -1 to the proposed text from Denis
>>
>>
>>> On Dec 8, 2017, at 8:48 PM, Brian Campbell <bcampbell@pingidentity.com> wrote: >>>
>>> The privacy matter is already mentioned. Despite your many mes= sages to this WG and others about the so called ABC attack, I do not believ= e it warrants treatment in this document or others. And your continued prop= osals to have it included in documents have not gotten support.
>>>
>>> On Fri, Dec 8, 2017 at 2:46 PM, Denis <denis.ietf@free.fr <mailto:denis.ietf@free.fr>> wrote:
>>> RFC 3552 (Guidelines for Writing RFC Text on Security Consider= ations) states:
>>>
>>>=C2=A0 All RFCs are required by RFC 2223 to contain a Security<= br> >>>=C2=A0 Considerations section.=C2=A0 The purpose of this is bot= h to encourage
>>>=C2=A0 document authors to consider security in their designs a= nd to inform
>>>=C2=A0 the reader of relevant security issues.=C2=A0 This memo = is intended to
>>>=C2=A0 provide guidance to RFC authors in service of both ends.=
>>>
>>> Section 5 (Writing Security Considerations Sections) of RFC 35= 52 states:
>>>
>>>=C2=A0 While it is not a requirement that any given protocol or= system be
>>>=C2=A0 immune to all forms of attack, it is still necessary for= authors to
>>>=C2=A0 consider as many forms as possible.=C2=A0 Part of the pu= rpose of the
>>>=C2=A0 Security Considerations section is to explain what attac= ks are out of
>>>=C2=A0 scope and what countermeasures can be applied to defend = against them
>>>
>>>=C2=A0 There should be a clear description of the kinds of thre= ats on the
>>>=C2=A0 described protocol or technology.
>>>
>>> It is important to mention the threat related to collusion att= acks. A different wording could be used,
>>> but the threat should be mentioned one way or another.
>>>
>>> RFC 6973 (Privacy Considerations for Internet Protocols) inten= ds to provide a similar set of guidelines
>>> for considering privacy in protocol design.
>>>
>>> It is important to mention a current threat related to privacy= . A different wording could be used,
>>> e.g. using the word "surveillance" as mentioned in 5= .1.1 : "Surveillance is the observation or monitoring
>>> of an individual?s communications or activities", but the= threat should be mentioned one way or another.
>>>
>>> Denis
>>>
>>>> I believe the text would detract from the document.
>>>> From: OAuth <= oauth-bounces@ietf.org> <mailto:oauth-bounces@ietf.org> on behalf of Brian Campbell &l= t;bcampbell@pingidentity.com<= /a>> <mailto:bcampbell@= pingidentity.com>
>>>> Sent: Friday, December 8, 2017 3:47:32 PM
>>>> To: Denis
>>>> Cc: oauth
>>>> Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-token= -exchange-10.txt
>>>>
>>>> As an individual, I do not believe that the proposed text = should be incorporated into the draft.
>>>>
>>>> As one of the document editors, my responsibility is for t= he document to be of reasonable quality and to reflect the rough consensus = of this Working Group. So I should ask the list more explicitly - are there= other WG remembers who are in favor of the proposed text here (the text wo= uld have to be fixed up some too)?
>>>>
>>>> On Fri, Dec 1, 2017 at 11:12 AM, Denis <denis.ietf@free.fr <mailto:denis.ietf@free.fr>> wrote:
>>>> Comments on draft-ietf-oauth-token-exchange-10
>>>>
>>>> I propose the following rephrasing for sections 6 and 7: >>>>
>>>> 6 . Security Considerations
>>>>
>>>> All of the normal security issues that are discussed in [J= WT],especially in relationship to comparing URIs
>>>> and dealing with unrecognized values, also apply here.=C2= =A0 In addition, both delegation and impersonation introduce
>>>> unique security issues. Any time one user receives a token= , the potential for abuse is a concern,
>>>> since that user might be willing to collude with another u= ser so that other user could use the token.
>>>>
>>>> Techniques like the binding of an access token to a TLS ch= annel described elsewhere are ineffective since
>>>> the legitimate user would be able to perform all the crypt= ographic computations that the other user would need
>>>> to demonstrate the ownership of the token. The use of the = "scp" claim is suggested to mitigate potential for
>>>> such abuse, as it restricts the contexts in which the toke= n can be exercised.=C2=A0 If the issued access token scope
>>>> allows to unambiguously identify the user, then that user = is likely to be reluctant to collude with another user.
>>>> However, if the issued access token scope only indicates t= hat the user is over 18, then there is no risk
>>>> for the original user to be discovered and in such a conte= xt a collusion may easily take place.
>>>> This document does not specify techniques to prevent such = a collusion to be successful.
>>>>
>>>> 7 . Privacy Considerations
>>>>
>>>> Tokens typically carry personal information and their usag= e in Token Exchange may reveal details of the target services
>>>> being accessed. The resource and the audience parameters a= llow authorization servers to know where the issued access token
>>>> will be used.=C2=A0 This may be a privacy concern for some= users. This document does not specify techniques to prevent
>>>> authorization servers to know where the access tokens they= issue will be used.
>>>>
>>>> Denis
>>>>> A New Internet-Draft is available from the on-line Int= ernet-Drafts directories.
>>>>> This draft is a work item of the Web Authorization Pro= tocol WG of the IETF.
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0Title=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0: OAuth 2.0 Token Exchange
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0Authors=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0: Michael B. Jones
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Anthony Nadalin
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Brian Campbell
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0John Bradley
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Chuck Mortimore
>>>>>=C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draf= t-ietf-oauth-token-exchange-10.txt
>>>>>=C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0: 32
>>>>>=C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : 2017-11-30
>>>>>
>>>>> Abstract:
>>>>>=C2=A0 This specification defines a protocol for an HTT= P- and JSON- based
>>>>>=C2=A0 Security Token Service (STS) by defining how to = request and obtain
>>>>>=C2=A0 security tokens from OAuth 2.0 authorization ser= vers, including
>>>>>=C2=A0 security tokens employing impersonation and dele= gation.
>>>>>
>>>>>
>>>>> The IETF datatracker status page for this draft is: >>>>> https://datatr= acker.ietf.org/doc/draft-ietf-oauth-token-exchange/ <https://datatracker.ietf.org/doc/dr= aft-ietf-oauth-token-exchange/>
>>>>>
>>>>> There are also htmlized versions available at:
>>>>> https://tools.iet= f.org/html/draft-ietf-oauth-token-exchange-10 <https://tools.ietf.org/html/draft-ietf-oauth= -token-exchange-10>
>>>>> https:/= /datatracker.ietf.org/doc/html/draft-ietf-oauth-token-exchange-10= <https://datatracker= .ietf.org/doc/html/draft-ietf-oauth-token-exchange-10>
>>>>>
>>>>> A diff from the previous version is available at:
>>>>> https://w= ww.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-token-exchange-10= <https://www.ietf.org/rfcd= iff?url2=3Ddraft-ietf-oauth-token-exchange-10>
>>>>>
>>>>>
>>>>> Please note that it may take a couple of minutes from = the time of submission
>>>>> until the htmlized version and diff are available at <= a href=3D"http://tools.ietf.org" rel=3D"noreferrer" target=3D"_blank">tools= .ietf.org <http://tools.ietf.org/>.
>>>>>
>>>>> Internet-Drafts are also available by anonymous FTP at= :
>>>>> ftp://ftp.ietf.org/internet-drafts/= <ftp://ftp.ietf.org/internet-drafts/>
>>>>>
>>>>> _______________________________________________ >>>>> OAuth mailing list
>>>>> OAuth@ietf.org &= lt;mailto:OAuth@ietf.org>
>>>>> https://www.ietf.org/mailman/li= stinfo/oauth <https://www.ietf.org/mailman/li= stinfo/oauth>
>>>>
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org <m= ailto:OAuth@ietf.org>
>>>> https://www.ietf.org/mailman/listin= fo/oauth <https://www.ietf.org/mailman/listin= fo/oauth>
>>>>
>>>>
>>>>
>>>> CONFIDENTIALITY NOTICE: This email may contain confidentia= l and privileged material for the sole use of the intended recipient(s). An= y review, use, distribution or disclosure by others is strictly prohibited.= =C2=A0 If you have received this communication in error, please notify the = sender immediately by e-mail and delete the message and any file attachment= s from your computer. Thank you.
>>>
>>>
>>>
>>> CONFIDENTIALITY NOTICE: This email may contain confidential an= d privileged material for the sole use of the intended recipient(s). Any re= view, use, distribution or disclosure by others is strictly prohibited.=C2= =A0 If you have received this communication in error, please notify the sen= der immediately by e-mail and delete the message and any file attachments f= rom your computer. Thank you._________________________________________= ______
>>> OAuth mailing list
>>> OAuth@ietf.org <mailt= o:OAuth@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/o= auth <https://www.ietf.org/mailman/listinfo/o= auth>
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <https://mailarchive.ietf.org/arch/browse/oauth/attachments= /20171211/dbd247f6/attachment.html>
>>
>> ------------------------------
>>
>> Subject: Digest Footer
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth=
>>
>>
>> ------------------------------
>>
>> End of OAuth Digest, Vol 110, Issue 8
>> *************************************
>
> _______________________________________________
> 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

--f403045ec2d4ed698b056054e53d-- From nobody Fri Dec 15 23:12:27 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1697C1241F5 for ; Fri, 15 Dec 2017 23:12:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.699 X-Spam-Level: X-Spam-Status: No, score=-4.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kAAoDLOwzeZC for ; Fri, 15 Dec 2017 23:12:23 -0800 (PST) Received: from p3plsmtpa11-04.prod.phx3.secureserver.net (p3plsmtpa11-04.prod.phx3.secureserver.net [68.178.252.105]) (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 4119D120725 for ; Fri, 15 Dec 2017 23:12:23 -0800 (PST) Received: from [192.168.0.107] ([78.130.190.73]) by :SMTPAUTH: with SMTP id Q6dxecHX6jkV9Q6dye0vqX; Sat, 16 Dec 2017 00:12:22 -0700 To: William Denniss Cc: oauth@ietf.org References: <4e14a1ec-8b6d-476b-3949-8a0b63017232@connect2id.com> From: Vladimir Dzhuvinov Organization: Connect2id Ltd. Message-ID: Date: Sat, 16 Dec 2017 09:12:20 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms090002090208090803040805" X-CMAE-Envelope: MS4wfFcrTxqwqbfRElQ/q+Fo+Gi3ylb8uJLL1MkBAY9/qOpHos1TLZzKb6VcyS241yL6Pp4Xjlt6pmoGOt21V3JHeutCmdhz7UIezLCNhnZY9jxwjSRbi7jI EWizXi84YyuIlcs7j5+I2REWgJdEFfK23m40gk+8yJIBsCxKalH1hrn36ottK5TChMhMlQW0Jp2zyDUcV9rhu9JMUycGFs8ydys= Archived-At: Subject: Re: [OAUTH-WG] WGLC for OAuth 2.0 Device Flow for Browserless and Input Constrained Devices X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Dec 2017 07:12:25 -0000 This is a cryptographically signed message in MIME format. --------------ms090002090208090803040805 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US On 15/12/17 00:43, William Denniss wrote: > On Fri, Dec 8, 2017 at 11:42 AM, Vladimir Dzhuvinov > wrote: >> Hi, >> >> I just got a question on Twitter about the slow_down error: >> >> https://tools.ietf.org/html/draft-ietf-oauth-device-flow-07#section-3.= 5 >> >> The question was why slow_down is communicated via HTTP status code 40= 0 >> and not 429 (Too Many Requests). >> > We could, it seems to match the intent of that error code. Main reason = it's > not like that so far is that 400 is the default for OAuth, I fear peopl= e > may not be checking for a 429. We don't strictly *need* the 429, since > we're returning data in machine readable format one way or another (i.e= =2E > it's easy for the client to extract the "slow_down" response either way= ), > which differs from HTML over HTTP which is intended for end-user > consumption, making the specific status code more important. Yes, on a 400 clients will need to check the error JSON object anyway, so the "slow_down" cannot be missed. Whereas with 429 that becomes more likely. +1 to return "slow_down" with status 400 as it is with the other OAuth error codes. Vladimir --------------ms090002090208090803040805 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+5swggVFMIIELaADAgECAhAlSsBX16i/yGZZkfkyj/exMA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTcwNDA2MDAwMDAwWhcNMTgwNDA2MjM1OTU5WjAoMSYwJAYJKoZIhvcNAQkB Fhd2bGFkaW1pckBjb25uZWN0MmlkLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAMHntIxpX2yNwHUcSrxfJihY9EtYTwC4VArv/C03YlEV92AQljLFYVKtRp+iKT8WDKo2 CqzPYaIHbKD0ivoou0qXQgv4yOk8rQxFmpTzCCe2c1KercueHfy595CnMz1u8GsQyblZqFMD HmzoEvD1YZiI3FEh049tVixBnHwPD9fyiGlf8+QdjwmBLMQwdrrib7xcswNXKYIsfj6Qm5oa d83bsz8VmYm5U39DbNPh01SzqAzwZt3jMuhy0su7lMs75lKYzWMA7b/9qrp40E3vR0yDvOn5 7Ijs+LFE2wPDTebVVfYT+m24e5/v/2w6sX5g/6oJsZnwPM737zIXV7x6jqECAwEAAaOCAfUw ggHxMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBQA+4E14UMY HyjzXHClSV9VfWHpPzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0w OwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5u ZXQvQ1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9E T1NIQTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsG AQUFBwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01P RE9TSEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsG AQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wIgYDVR0RBBswGYEXdmxhZGltaXJA Y29ubmVjdDJpZC5jb20wDQYJKoZIhvcNAQELBQADggEBACYLv9z6ZOucvt5MlRhNY6SJISDN 880UmdH7IdeP2kJjS3GwuVaVUCQY/frypeIm3A+y0fKEVNJAJO7tfL88yOW4wjA9JMGokpy5 RswZ0uikkNSOt6CF3YGagsfr4VnrcoUxCH+FoGZcWvWYHajJy+QkVG2i6XvsTE7jv1PIsoDU SJuCW+Dvg6iJI9Etpfv1ZrBeDEL05PkPBZfazKMj4MkVirkfbG3qgbzRzAb+7Vsm309NKQ+i EUfoxt83ByC6+URLl3PoR2UTZv7M1JQmTtaQWe1LrAEKlBGHkfnSlxueLnmpCUJRS7Ldyfh5 60OdVFcB5twXPnYWtoZfdTlbv5oxggRBMIIEPQIBATCBsDCBmzELMAkGA1UEBhMCR0IxGzAZ BgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRo ZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAlSsBX16i/yGZZkfkyj/exMA0GCWCG SAFlAwQCAQUAoIICYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNzEyMTYwNzEyMjFaMC8GCSqGSIb3DQEJBDEiBCD4yI4Oxn01UOZHMxHN0fm48FFm9Tik 97earslVWPbnxjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIw CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G CCqGSIb3DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQJUrAV9eov8hmWZH5Mo/3sTCBwwYLKoZI hvcNAQkQAgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEw PwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3Vy ZSBFbWFpbCBDQQIQJUrAV9eov8hmWZH5Mo/3sTANBgkqhkiG9w0BAQEFAASCAQCWBkIusG7B fShGbWf/qJcyA/26/HcfmuMS5SEa11vGxElfbQJulOnpQM9YAp5+Uh8VQSla2MVYtqCWpyCd x4yp/YczbOWBrl0m/HnLzejOkAP/Cz39nT1xcvTIFblkFrtr627+1L2F+NAXrAIMFROvqTBM Tw7B4rr9+b8HL+ha1ng1OYt6sK7OXwcDWLX8vCk0qwikeWtdQ1hHWhd7l1AqfAV2fC9uool2 3eO6aJoCRWC+biEigIV77hvD4lIDzhxgrc3+eFKQwBVyhK0V0h6W05ZXBlnQ+qnriEZqWanV 3h2u1Usl1r6xGl6OSfNksSk+C1WgA/PZzIU6crt5KigAAAAAAAAA --------------ms090002090208090803040805-- From nobody Tue Dec 19 00:43:12 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A60412D835 for ; Tue, 19 Dec 2017 00:43:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N1_VJ4FT60MB for ; Tue, 19 Dec 2017 00:43:09 -0800 (PST) Received: from mail-ot0-x22d.google.com (mail-ot0-x22d.google.com [IPv6:2607:f8b0:4003:c0f::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 80B02124BE8 for ; Tue, 19 Dec 2017 00:43:09 -0800 (PST) Received: by mail-ot0-x22d.google.com with SMTP id b56so1856018otd.10 for ; Tue, 19 Dec 2017 00:43:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=ySlifec2nH6BUFY9jqk3qRYhiUm1PINTLP4gJVA5k+w=; b=M8QWJg/M75crD9T5u9HpxcUiAuT+YqAHxYH5FRsxILhN5GdppvstmVStT/fBpmkrhO eJKA+UtgEkxrsAhmICl9LDeoxEVvA6twJsePVCMxqv41XY6n+uviScbreN0RFqVVNthB 8f3BDrr8ZIBcBf85LTDRSr6InKvuvqycZY6ogctv+bMsvMvplIpHM4YRavs1+9YepXvv 0PAJBwJ4xvtsKuvbHKg9PfTfQi3FhKqPTufeB9RGfS8gmITYmUoBMu4wrccIbDHDcIaM eI1HJMAgiCw7llafAty/QtUAtHDCHPO+afpudcy6/eOluVLtKgFu5NUxHfHxgx6BFbE4 a/JA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=ySlifec2nH6BUFY9jqk3qRYhiUm1PINTLP4gJVA5k+w=; b=Wkxm54lWqPl6uHl4EXo8liLk0Pf3bEzh70AJwTLOz0kPeGruU/f0Z1ry2YdHzUj8RB 5HOS0eThsdOU6WMrQdKblEhylY74Er61k8QoXJPzBknn4Ovt+Sd5A3cPajTg4yvn41wn rKa/UmuoQrQ/u2F9P6t+ZsnhcjTdJWwsk3H4t++l+FB6q/Nq88KZy+QNPE2Orye4Smw9 PLXY2RJONDdTGVayQWBLYO8xsKqRAxGg46IsM3EIBMCkYcR5oaUh431U6VP7yQ4EtjHu 6TdUm2K3yRf7BDKF0LxbVi7eWba7ElaRwdOudkBxLc/hNC3LETV8qRxCI5gNdoSoA//p qjpA== X-Gm-Message-State: AKGB3mLtfwpRhlTha4+2PXByDEJXqnr+VqrU00iBq9XpcCAOneN7xxnc JvVktU00rE0H4FR+GgL/xEaGHm2PpnWQF2KgdMm7iQ== X-Google-Smtp-Source: ACJfBoulWFN83aD2aLgV249UMNLoBH91nscwpGCEjKSZyZ9RiAy62XSztVuHYRp9gh+XdAH10SlZ9zmjOotgZZpp4GA= X-Received: by 10.157.87.92 with SMTP id x28mr1173513oti.264.1513672988621; Tue, 19 Dec 2017 00:43:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.59.131 with HTTP; Tue, 19 Dec 2017 00:43:05 -0800 (PST) Received: by 10.157.59.131 with HTTP; Tue, 19 Dec 2017 00:43:05 -0800 (PST) From: cebu taxi driver Date: Tue, 19 Dec 2017 16:43:05 +0800 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary="94eb2c1c0beacafe640560ad74c6" Archived-At: Subject: [OAUTH-WG] Using OAuth X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Dec 2017 08:43:10 -0000 --94eb2c1c0beacafe640560ad74c6 Content-Type: text/plain; charset="UTF-8" Reply --94eb2c1c0beacafe640560ad74c6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Reply=C2=A0
--94eb2c1c0beacafe640560ad74c6-- From nobody Thu Dec 28 10:38:55 2017 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BC0F124B17; Thu, 28 Dec 2017 10:38:49 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Brian Carpenter To: Cc: oauth@ietf.org, draft-ietf-oauth-discovery.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.68.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151448632907.3124.13538369110127909149@ietfa.amsl.com> Date: Thu, 28 Dec 2017 10:38:49 -0800 Archived-At: Subject: [OAUTH-WG] Genart telechat review of draft-ietf-oauth-discovery-08 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Dec 2017 18:38:49 -0000 Reviewer: Brian Carpenter Review result: Ready Gen-ART telechat review of draft-ietf-oauth-discovery-08 I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at . Document: draft-ietf-oauth-discovery-08.txt Reviewer: Brian Carpenter Review Date: 2017-12-29 IETF LC End Date: 2017-10-09 IESG Telechat date: 2018-01-25 Summary: Ready -------- Comment: I'm happy with the changes since the -07 version. -------- From nobody Fri Dec 29 08:41:43 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D06B129C51 for ; Fri, 29 Dec 2017 08:41:42 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UwdozcFWVzDV for ; Fri, 29 Dec 2017 08:41:39 -0800 (PST) Received: from mail-yb0-x234.google.com (mail-yb0-x234.google.com [IPv6:2607:f8b0:4002: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 91186120725 for ; Fri, 29 Dec 2017 08:41:39 -0800 (PST) Received: by mail-yb0-x234.google.com with SMTP id s10so1154486ybl.7 for ; Fri, 29 Dec 2017 08:41:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=KB0xao1HYPTPEbzduHwxitC210tPtFiM84/uONbGej4=; b=xhhuAH4ROH9nqq9id2fopFgFzQWeGOZIATMSTEuCMU5k30hdQ+28ctv+/rvVmhaqB6 Xm2vmWUVCaktUxsiI/r7+GpzOB66KYDlwoOG6FmHndaBNK+9CMQ9GoSxKonwXONItWm6 pF65cZbOwVmr3y6neFofyXl3F1UIyUZ9/02V/jZi23NkNDLitjm9jQ2G5qMv+3gBpY7g bkrVYWqtsu8MnDoKGs3xztdrw5x5MEiRL51u8HBh/3mkah0KNsudj4JVviO1gpJPg72V 1lWARjBH5OF4zIclIaBxSLvZUc84BjOmKfWB/rqVb404aNxG+QkiBidYOOJrPFrDvmG1 CWnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=KB0xao1HYPTPEbzduHwxitC210tPtFiM84/uONbGej4=; b=Ur2ZVbLPSRh+bOmXRAjjhP5nhqqVjivzCtjjniLavze2NvNXEIOZ9I0xRMiFscDrUn dahMqQoA6pi22yOnOQAEwtL+vltfdO0eZrFLCfNegiVTN3D/pz4doiDLpqhnJtTfLVDe htvMTOJt+8fPEeF5LeWn1rxLnQtTzMtzeXASiRswOj4e7em5NUvshKxivOjj7r7ACdI/ Zx5fJVBRHvzxbCn25ODZtaU5i+kYZos0lNGpDZ7XEjioB4407xJC1o1pUpTtihsiib5O rFj88/EBvV5p0neRQKMEuffZllzS6gtMHyu9hJzLd50at1fG2GZ6qXoTwlOsteO87cWI 4+GA== X-Gm-Message-State: AKGB3mJdldEEvVrMXh1v2Gc2vV3LxQNyq5IzLiRAEu3glkOkMDvEvhRJ e9ObPDH6ZgVSUb2Mp+gpzBsrNXiI8A4nFqz14o+BurzQyK0= X-Google-Smtp-Source: ACJfBovyrj+aDyFgTDeA6e0n/L/DvG8CeZ0jPKyfrVbAtYBf6PwckPKj0pbSsm4pcchOovPcTSKbMI4K01adLQxkghA= X-Received: by 10.37.129.194 with SMTP id n2mr3869138ybm.293.1514565698395; Fri, 29 Dec 2017 08:41:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.123.132 with HTTP; Fri, 29 Dec 2017 08:40:57 -0800 (PST) From: Eric Rescorla Date: Fri, 29 Dec 2017 08:40:57 -0800 Message-ID: To: oauth@ietf.org, draft-ietf-oauth-token-exchange@tools.ietf.org Content-Type: multipart/alternative; boundary="089e08264eb071354f05617d4e37" Archived-At: Subject: [OAUTH-WG] AD Review: draft-ietf-oauth-token-exchange-09 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Dec 2017 16:41:42 -0000 --089e08264eb071354f05617d4e37 Content-Type: text/plain; charset="UTF-8" Full-featured review at: https://mozphab-ietf.devsvcdev.mozaws.net/D4278 As noted in inline comments, some additional words about the security model in which this document is embedded seem like they are needed. In particular, it's pretty unclear to me what checks the STS is supposed to do on a given request to determine whether to fulfill it. Where is that documented? *INLINE COMMENTS* View Inline draft-ietf-oauth-token-exchange.txt:129 securing access to HTTP and RESTful resources but do not provide everything necessary to facilitate token exchange interactions. Can you say a bit more about what is missing here? View Inline draft-ietf-oauth-token-exchange.txt:265 REQUIRED. The value "urn:ietf:params:oauth:grant-type:token- exchange" indicates that a token exchange is being performed. I note that S 4.5. says that the grant_type is "defined by the authorization server" but that's not the case here, right? View Inline draft-ietf-oauth-token-exchange.txt:268 resource OPTIONAL. Indicates the physical location of the target service or resource where the client intends to use the requested security Do you actually mean "physical" here? Presumably if it's a URI it's most likely a network address. I would take "physical" to mean "geographic" View Inline draft-ietf-oauth-token-exchange.txt:304 target services with a mix of logical names and physical locations. But it seems you can only specify one of each, right? View Inline draft-ietf-oauth-token-exchange.txt:310 security token in the context of the service or resource where the token will be used. It's not clear to me where these values would come from. Can you expand on this? View Inline draft-ietf-oauth-token-exchange.txt:341 REQUIRED when the "actor_token" parameter is present in the request but MUST NOT be included otherwise. It's not entirely clear to me from this text how these tokens authenticate the request. It's clear if they are bearer tokens, but if they are some sort of token over a public key, then how does that work. View Inline draft-ietf-oauth-token-exchange.txt:587 2.0 [OASIS.saml-core-2.0-os] assertion, respectively. Other URIs to indicate other token types MAY be used. This feels like it would be better as some kind of list (maybe bulleted)? View Inline draft-ietf-oauth-token-exchange.txt:666 it as the current actor and that can be used at https://backend.example.com. Where can I find the definitions of "iss" and "sub"? View Inline draft-ietf-oauth-token-exchange.txt:689 response, "act" has the same semantics and format as the claim of the same name. It's not entirely clear to me how I'm supposed to evaluate these from an access control perspective. Is the assumption here that the entity producing the JWT has ensured the correct chain of issuers and subs? Is it the RP's job to evaluate whether each entity in the chain could have performed the action? View Inline draft-ietf-oauth-token-exchange.txt:755 claims such as "exp", "nbf", and "aud" are not meaningful when used within a "may_act" claim, and therefore should not be used. I'm having a hard time understanding this claim. Can you provide an example to me (in email is fine, it doesn't need to be in the draft) of how it would be used? View Inline draft-ietf-oauth-token-exchange.txt:1273 produced under the chairmanship of Hannes Tschofenig and Derek Atkins with Kathleen Moriarty and Stephen Farrell serving as Security Area Directors. The following individuals contributed ideas, feedback, You may want to update this *REPOSITORY* rIETFREVIEW ietf-review *REVISION DETAIL* https://mozphab-ietf.devsvcdev.mozaws.net/D4278 *EMAIL PREFERENCES* https://mozphab-ietf.devsvcdev.mozaws.net/settings/panel/emailpreferences/ *To: *ekr-moz, ekr *Cc: *ekr --089e08264eb071354f05617d4e37 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Full-featured review at:
<= div class=3D"gmail_quote">https://mozphab-ietf.devsvcdev.mozaws.net/D4278

As noted in inline comments, some addi= tional words about the security model in which this document is embedded se= em like they are needed. In particular, it's pretty unclear to me what = checks the STS is supposed to do on a given request to determine whether to= fulfill it. Where is that documented?


INLI= NE COMMENTS
View I= nlinedraft-ietf-oa= uth-token-exchange.txt:129
securing access to HTTP and RESTful resources but do not provide
everything necessary to facilitate token exchange interaction= s.

Can you say a bit more about what is missing here?

<= br>
View Inlinedraft-ietf-oauth-token-exchange.txt:265
REQUIRED. The value "urn:ietf:params:oauth:grant-ty= pe:token-
exchange" indicates that a token exchange is being pe= rformed.

I note that S 4.5. says that the grant_type is "defined by the= authorization server" but that's not the case here, right?


View Inlinedraft-ietf-oauth-token-exchange.txt:268
resource
OPTIONAL. Indicates the physical location of the target s= ervice
or resource where the client intends to use the requested = security

Do you actually mean "physical" here? Presumably if it= 9;s a URI it's most likely a network address. I would take "physic= al" to mean "geographic"


View Inli= nedraft-ietf-oauth= -token-exchange.txt:304
target services with a mix of logical names and physical
locations.

But it seems you can only specify one of each, right?


View Inlinedraft-ietf-oauth-token-exchange.txt:310
security token in the context of the service or resource where= the
token will be used.

It's not clear to me where these values would come from. Can yo= u expand on this?


View Inlinedraft-ietf-oauth-token-exchange.t= xt:341
REQUIRED when the "actor_token" parameter is present= in the
request but MUST NOT be included otherwise.

It's not entirely clear to me from this text how these tokens a= uthenticate the request. It's clear if they are bearer tokens, but if t= hey are some sort of token over a public key, then how does that work.

<= /div>

View Inlinedraft-ietf-oauth-token-exchange.txt:587
2.0 [OASIS.saml-core-2.0-os] assertion, respectively. Other URIs= to
indicate other token types MAY be used.

This feels like it would be better as some kind of list (maybe bull= eted)?


View Inlinedraft-ietf-oauth-token-exchange.txt:666
it as the current actor and that can be used at

Where can I find the definitions of "iss" and "sub&q= uot;?


View Inlinedraft-ietf-oauth-token-exchange.txt:689
response, "act" has the same semantics and format as th= e claim of the
same name.

It's not entirely clear to me how I'm supposed to evaluate = these from an access control perspective.

Is the assumption here that the entity = producing the JWT has ensured the correct chain of issuers and subs?

Is it the RP's job to evaluate whet= her each entity in the chain could have performed the action?


View Inlinedraft-ietf-oauth-token-exchange.txt:755
claims such as "exp", "nbf", and "aud&qu= ot; are not meaningful when used
within a "may_act" claim, and therefore should not = be used.

I'm having a hard time understanding this claim. Can you provid= e an example to me (in email is fine, it doesn't need to be in the draf= t) of how it would be used?


View Inlinedraft-ietf-oauth-token-= exchange.txt:1273
produced under the chairmanship of Hannes Tschofenig and Derek At= kins
with Kathleen Moriarty and Stephen Farrell serving as Securit= y Area
Directors. The following individuals contributed ideas, feed= back,

You may want to update this


REPOSITORY
rIETFREVIEW ietf-review
=

EMAIL PREFERENCES
To: ekr-mo= z, ekr
Cc: ekr

--089e08264eb071354f05617d4e37-- From nobody Fri Dec 29 09:48:15 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83EC6126CE8 for ; Fri, 29 Dec 2017 09:48:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.01 X-Spam-Level: X-Spam-Status: No, score=-3.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id viEzBcAr4hxw for ; Fri, 29 Dec 2017 09:48:11 -0800 (PST) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0139.outbound.protection.outlook.com [104.47.40.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC20A12426E for ; Fri, 29 Dec 2017 09:48:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=u0g6IAGS25u+jpOWgxieACaVeBIiviG/IP0J48ayMeg=; b=FzQXi2OtKPAZtkbUuuGTSHDpM/alA9CUiLCjXy83bsyv0v6amXpnQHJ6hNgUagnDiZTnQyin9Lwg1bI6VmjeLOlZkheW1DtGfvYPM3/SK2k/9q48Zn3LfCvEE5Z4QlIjCLisouSDswAqQOSTsYHLgkr4tVpKS2K5hMSLxRBY08o= Received: from CY4PR21MB0504.namprd21.prod.outlook.com (10.172.122.14) by CY4PR21MB0744.namprd21.prod.outlook.com (10.173.189.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.345.2; Fri, 29 Dec 2017 17:48:06 +0000 Received: from CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) by CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) with mapi id 15.20.0407.000; Fri, 29 Dec 2017 17:48:06 +0000 From: Mike Jones To: Eric Rescorla , "oauth@ietf.org" , "draft-ietf-oauth-token-exchange@tools.ietf.org" Thread-Topic: [OAUTH-WG] AD Review: draft-ietf-oauth-token-exchange-09 Thread-Index: AQHTgMPugLlckbvpIE2JNpgrfT8UNaNamK8Q Date: Fri, 29 Dec 2017 17:48:06 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.47.88.182] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0744; 7:KycoF0nBje0+P7OEO8Fxw/2JHA6p0WEisabdy7MndF/T0AeQhZWqSLZyArbVXdBJAduTy38ZhA2sXDIBdGNRn9tnmInEYnUJYNS0a/c8yX25sufMfWnQnrzHaztX2u+WVcmPfEVAqG1+NTnm5k8LmsBAmorV3xJn9ZO+ho+EK0dWWkS9hFpxQGcXKp6f5Zq+WHnj/np64lnfgwVqShU02QoIcFAwYq1X6mDjDMZPwdpAdV08GY4Ls3MQArCiKK+O x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 3f4f388b-34a5-41d8-7dbe-08d54ee4516f x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020020)(48565401081)(4534040)(4602075)(4627136)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307); SRVR:CY4PR21MB0744; x-ms-traffictypediagnostic: CY4PR21MB0744: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(192374486261705)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040470)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(3231023)(944501075)(6055026)(61426038)(61427038)(6041268)(20161123564045)(20161123560045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(6072148)(201708071742011); SRVR:CY4PR21MB0744; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:CY4PR21MB0744; x-forefront-prvs: 0536638EAC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(39860400002)(366004)(39380400002)(396003)(51914003)(189003)(199004)(66066001)(22452003)(8936002)(790700001)(6116002)(33656002)(55016002)(6306002)(6506007)(236005)(2501003)(86362001)(316002)(6246003)(76176011)(478600001)(2906002)(77096006)(10290500003)(25786009)(3846002)(10090500001)(99286004)(3660700001)(105586002)(229853002)(2900100001)(6436002)(53936002)(966005)(81166006)(2950100002)(54896002)(68736007)(2201001)(3280700002)(7696005)(110136005)(53546011)(8676002)(9686003)(230783001)(14454004)(72206003)(97736004)(7736002)(5660300001)(74316002)(81156014)(19609705001)(86612001)(102836004)(106356001)(8990500004)(606006)(59450400001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0744; H:CY4PR21MB0504.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: oYIuvdlgxa1umnLYHcLK1vyD+C5iDnMyJOR0AwLVbITfn9ejLNQygSGj2OGzDrF282a2/6pGT1fQ3B744VFs2w== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB05046590C8F5889AB1AAA3C7F5050CY4PR21MB0504namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3f4f388b-34a5-41d8-7dbe-08d54ee4516f X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Dec 2017 17:48:06.7243 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0744 Archived-At: Subject: Re: [OAUTH-WG] AD Review: draft-ietf-oauth-token-exchange-09 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Dec 2017 17:48:14 -0000 --_000_CY4PR21MB05046590C8F5889AB1AAA3C7F5050CY4PR21MB0504namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIGZvciB0aGUgdXNlZnVsIHJldmlldywgRXJpYy4gIEnigJlsbCB3b3JrIHdpdGggQnJp YW4gYW5kIHRoZSBjcmV3IHRvIGluY29ycG9yYXRlIHRoaXMgZmVlZGJhY2suDQoNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoN CkZyb206IE9BdXRoIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IEVyaWMgUmVzY29ybGENClNlbnQ6IEZyaWRheSwgRGVjZW1iZXIgMjksIDIwMTcgODo0MSBBTQ0K VG86IG9hdXRoQGlldGYub3JnOyBkcmFmdC1pZXRmLW9hdXRoLXRva2VuLWV4Y2hhbmdlQHRvb2xz LmlldGYub3JnDQpTdWJqZWN0OiBbT0FVVEgtV0ddIEFEIFJldmlldzogZHJhZnQtaWV0Zi1vYXV0 aC10b2tlbi1leGNoYW5nZS0wOQ0KDQpGdWxsLWZlYXR1cmVkIHJldmlldyBhdDoNCmh0dHBzOi8v bW96cGhhYi1pZXRmLmRldnN2Y2Rldi5tb3phd3MubmV0L0Q0Mjc4DQoNCg0KQXMgbm90ZWQgaW4g aW5saW5lIGNvbW1lbnRzLCBzb21lIGFkZGl0aW9uYWwgd29yZHMgYWJvdXQgdGhlIHNlY3VyaXR5 IG1vZGVsIGluIHdoaWNoIHRoaXMgZG9jdW1lbnQgaXMgZW1iZWRkZWQgc2VlbSBsaWtlIHRoZXkg YXJlIG5lZWRlZC4gSW4gcGFydGljdWxhciwgaXQncyBwcmV0dHkgdW5jbGVhciB0byBtZSB3aGF0 IGNoZWNrcyB0aGUgU1RTIGlzIHN1cHBvc2VkIHRvIGRvIG9uIGEgZ2l2ZW4gcmVxdWVzdCB0byBk ZXRlcm1pbmUgd2hldGhlciB0byBmdWxmaWxsIGl0LiBXaGVyZSBpcyB0aGF0IGRvY3VtZW50ZWQ/ DQoNCklOTElORSBDT01NRU5UUw0KVmlldyBJbmxpbmU8aHR0cHM6Ly9tb3pwaGFiLWlldGYuZGV2 c3ZjZGV2Lm1vemF3cy5uZXQvRDQyNzgjaW5saW5lLTE1ODA+ZHJhZnQtaWV0Zi1vYXV0aC10b2tl bi1leGNoYW5nZS50eHQ6MTI5DQpzZWN1cmluZyBhY2Nlc3MgdG8gSFRUUCBhbmQgUkVTVGZ1bCBy ZXNvdXJjZXMgYnV0IGRvIG5vdCBwcm92aWRlDQpldmVyeXRoaW5nIG5lY2Vzc2FyeSB0byBmYWNp bGl0YXRlIHRva2VuIGV4Y2hhbmdlIGludGVyYWN0aW9ucy4NCg0KQ2FuIHlvdSBzYXkgYSBiaXQg bW9yZSBhYm91dCB3aGF0IGlzIG1pc3NpbmcgaGVyZT8NCg0KVmlldyBJbmxpbmU8aHR0cHM6Ly9t b3pwaGFiLWlldGYuZGV2c3ZjZGV2Lm1vemF3cy5uZXQvRDQyNzgjaW5saW5lLTE1ODE+ZHJhZnQt aWV0Zi1vYXV0aC10b2tlbi1leGNoYW5nZS50eHQ6MjY1DQpSRVFVSVJFRC4gVGhlIHZhbHVlICJ1 cm46aWV0ZjpwYXJhbXM6b2F1dGg6Z3JhbnQtdHlwZTp0b2tlbi0NCmV4Y2hhbmdlIiBpbmRpY2F0 ZXMgdGhhdCBhIHRva2VuIGV4Y2hhbmdlIGlzIGJlaW5nIHBlcmZvcm1lZC4NCg0KSSBub3RlIHRo YXQgUyA0LjUuIHNheXMgdGhhdCB0aGUgZ3JhbnRfdHlwZSBpcyAiZGVmaW5lZCBieSB0aGUgYXV0 aG9yaXphdGlvbiBzZXJ2ZXIiIGJ1dCB0aGF0J3Mgbm90IHRoZSBjYXNlIGhlcmUsIHJpZ2h0Pw0K DQpWaWV3IElubGluZTxodHRwczovL21venBoYWItaWV0Zi5kZXZzdmNkZXYubW96YXdzLm5ldC9E NDI3OCNpbmxpbmUtMTU4Mj5kcmFmdC1pZXRmLW9hdXRoLXRva2VuLWV4Y2hhbmdlLnR4dDoyNjgN CnJlc291cmNlDQpPUFRJT05BTC4gSW5kaWNhdGVzIHRoZSBwaHlzaWNhbCBsb2NhdGlvbiBvZiB0 aGUgdGFyZ2V0IHNlcnZpY2UNCm9yIHJlc291cmNlIHdoZXJlIHRoZSBjbGllbnQgaW50ZW5kcyB0 byB1c2UgdGhlIHJlcXVlc3RlZCBzZWN1cml0eQ0KDQpEbyB5b3UgYWN0dWFsbHkgbWVhbiAicGh5 c2ljYWwiIGhlcmU/IFByZXN1bWFibHkgaWYgaXQncyBhIFVSSSBpdCdzIG1vc3QgbGlrZWx5IGEg bmV0d29yayBhZGRyZXNzLiBJIHdvdWxkIHRha2UgInBoeXNpY2FsIiB0byBtZWFuICJnZW9ncmFw aGljIg0KDQpWaWV3IElubGluZTxodHRwczovL21venBoYWItaWV0Zi5kZXZzdmNkZXYubW96YXdz Lm5ldC9ENDI3OCNpbmxpbmUtMTU4Mz5kcmFmdC1pZXRmLW9hdXRoLXRva2VuLWV4Y2hhbmdlLnR4 dDozMDQNCnRhcmdldCBzZXJ2aWNlcyB3aXRoIGEgbWl4IG9mIGxvZ2ljYWwgbmFtZXMgYW5kIHBo eXNpY2FsDQpsb2NhdGlvbnMuDQoNCkJ1dCBpdCBzZWVtcyB5b3UgY2FuIG9ubHkgc3BlY2lmeSBv bmUgb2YgZWFjaCwgcmlnaHQ/DQoNClZpZXcgSW5saW5lPGh0dHBzOi8vbW96cGhhYi1pZXRmLmRl dnN2Y2Rldi5tb3phd3MubmV0L0Q0Mjc4I2lubGluZS0xNTg0PmRyYWZ0LWlldGYtb2F1dGgtdG9r ZW4tZXhjaGFuZ2UudHh0OjMxMA0Kc2VjdXJpdHkgdG9rZW4gaW4gdGhlIGNvbnRleHQgb2YgdGhl IHNlcnZpY2Ugb3IgcmVzb3VyY2Ugd2hlcmUgdGhlDQp0b2tlbiB3aWxsIGJlIHVzZWQuDQoNCkl0 J3Mgbm90IGNsZWFyIHRvIG1lIHdoZXJlIHRoZXNlIHZhbHVlcyB3b3VsZCBjb21lIGZyb20uIENh biB5b3UgZXhwYW5kIG9uIHRoaXM/DQoNClZpZXcgSW5saW5lPGh0dHBzOi8vbW96cGhhYi1pZXRm LmRldnN2Y2Rldi5tb3phd3MubmV0L0Q0Mjc4I2lubGluZS0xNTg1PmRyYWZ0LWlldGYtb2F1dGgt dG9rZW4tZXhjaGFuZ2UudHh0OjM0MQ0KUkVRVUlSRUQgd2hlbiB0aGUgImFjdG9yX3Rva2VuIiBw YXJhbWV0ZXIgaXMgcHJlc2VudCBpbiB0aGUNCnJlcXVlc3QgYnV0IE1VU1QgTk9UIGJlIGluY2x1 ZGVkIG90aGVyd2lzZS4NCg0KSXQncyBub3QgZW50aXJlbHkgY2xlYXIgdG8gbWUgZnJvbSB0aGlz IHRleHQgaG93IHRoZXNlIHRva2VucyBhdXRoZW50aWNhdGUgdGhlIHJlcXVlc3QuIEl0J3MgY2xl YXIgaWYgdGhleSBhcmUgYmVhcmVyIHRva2VucywgYnV0IGlmIHRoZXkgYXJlIHNvbWUgc29ydCBv ZiB0b2tlbiBvdmVyIGEgcHVibGljIGtleSwgdGhlbiBob3cgZG9lcyB0aGF0IHdvcmsuDQoNClZp ZXcgSW5saW5lPGh0dHBzOi8vbW96cGhhYi1pZXRmLmRldnN2Y2Rldi5tb3phd3MubmV0L0Q0Mjc4 I2lubGluZS0xNTg2PmRyYWZ0LWlldGYtb2F1dGgtdG9rZW4tZXhjaGFuZ2UudHh0OjU4Nw0KMi4w IFtPQVNJUy5zYW1sLWNvcmUtMi4wLW9zXSBhc3NlcnRpb24sIHJlc3BlY3RpdmVseS4gT3RoZXIg VVJJcyB0bw0KaW5kaWNhdGUgb3RoZXIgdG9rZW4gdHlwZXMgTUFZIGJlIHVzZWQuDQoNClRoaXMg ZmVlbHMgbGlrZSBpdCB3b3VsZCBiZSBiZXR0ZXIgYXMgc29tZSBraW5kIG9mIGxpc3QgKG1heWJl IGJ1bGxldGVkKT8NCg0KVmlldyBJbmxpbmU8aHR0cHM6Ly9tb3pwaGFiLWlldGYuZGV2c3ZjZGV2 Lm1vemF3cy5uZXQvRDQyNzgjaW5saW5lLTE1ODc+ZHJhZnQtaWV0Zi1vYXV0aC10b2tlbi1leGNo YW5nZS50eHQ6NjY2DQppdCBhcyB0aGUgY3VycmVudCBhY3RvciBhbmQgdGhhdCBjYW4gYmUgdXNl ZCBhdA0KaHR0cHM6Ly9iYWNrZW5kLmV4YW1wbGUuY29tLg0KDQpXaGVyZSBjYW4gSSBmaW5kIHRo ZSBkZWZpbml0aW9ucyBvZiAiaXNzIiBhbmQgInN1YiI/DQoNClZpZXcgSW5saW5lPGh0dHBzOi8v bW96cGhhYi1pZXRmLmRldnN2Y2Rldi5tb3phd3MubmV0L0Q0Mjc4I2lubGluZS0xNTg4PmRyYWZ0 LWlldGYtb2F1dGgtdG9rZW4tZXhjaGFuZ2UudHh0OjY4OQ0KcmVzcG9uc2UsICJhY3QiIGhhcyB0 aGUgc2FtZSBzZW1hbnRpY3MgYW5kIGZvcm1hdCBhcyB0aGUgY2xhaW0gb2YgdGhlDQpzYW1lIG5h bWUuDQoNCkl0J3Mgbm90IGVudGlyZWx5IGNsZWFyIHRvIG1lIGhvdyBJJ20gc3VwcG9zZWQgdG8g ZXZhbHVhdGUgdGhlc2UgZnJvbSBhbiBhY2Nlc3MgY29udHJvbCBwZXJzcGVjdGl2ZS4NCg0KSXMg dGhlIGFzc3VtcHRpb24gaGVyZSB0aGF0IHRoZSBlbnRpdHkgcHJvZHVjaW5nIHRoZSBKV1QgaGFz IGVuc3VyZWQgdGhlIGNvcnJlY3QgY2hhaW4gb2YgaXNzdWVycyBhbmQgc3Vicz8NCg0KSXMgaXQg dGhlIFJQJ3Mgam9iIHRvIGV2YWx1YXRlIHdoZXRoZXIgZWFjaCBlbnRpdHkgaW4gdGhlIGNoYWlu IGNvdWxkIGhhdmUgcGVyZm9ybWVkIHRoZSBhY3Rpb24/DQoNClZpZXcgSW5saW5lPGh0dHBzOi8v bW96cGhhYi1pZXRmLmRldnN2Y2Rldi5tb3phd3MubmV0L0Q0Mjc4I2lubGluZS0xNTg5PmRyYWZ0 LWlldGYtb2F1dGgtdG9rZW4tZXhjaGFuZ2UudHh0Ojc1NQ0KY2xhaW1zIHN1Y2ggYXMgImV4cCIs ICJuYmYiLCBhbmQgImF1ZCIgYXJlIG5vdCBtZWFuaW5nZnVsIHdoZW4gdXNlZA0Kd2l0aGluIGEg Im1heV9hY3QiIGNsYWltLCBhbmQgdGhlcmVmb3JlIHNob3VsZCBub3QgYmUgdXNlZC4NCg0KSSdt IGhhdmluZyBhIGhhcmQgdGltZSB1bmRlcnN0YW5kaW5nIHRoaXMgY2xhaW0uIENhbiB5b3UgcHJv dmlkZSBhbiBleGFtcGxlIHRvIG1lIChpbiBlbWFpbCBpcyBmaW5lLCBpdCBkb2Vzbid0IG5lZWQg dG8gYmUgaW4gdGhlIGRyYWZ0KSBvZiBob3cgaXQgd291bGQgYmUgdXNlZD8NCg0KVmlldyBJbmxp bmU8aHR0cHM6Ly9tb3pwaGFiLWlldGYuZGV2c3ZjZGV2Lm1vemF3cy5uZXQvRDQyNzgjaW5saW5l LTE1OTA+ZHJhZnQtaWV0Zi1vYXV0aC10b2tlbi1leGNoYW5nZS50eHQ6MTI3Mw0KcHJvZHVjZWQg dW5kZXIgdGhlIGNoYWlybWFuc2hpcCBvZiBIYW5uZXMgVHNjaG9mZW5pZyBhbmQgRGVyZWsgQXRr aW5zDQp3aXRoIEthdGhsZWVuIE1vcmlhcnR5IGFuZCBTdGVwaGVuIEZhcnJlbGwgc2VydmluZyBh cyBTZWN1cml0eSBBcmVhDQpEaXJlY3RvcnMuIFRoZSBmb2xsb3dpbmcgaW5kaXZpZHVhbHMgY29u dHJpYnV0ZWQgaWRlYXMsIGZlZWRiYWNrLA0KDQpZb3UgbWF5IHdhbnQgdG8gdXBkYXRlIHRoaXMN Cg0KUkVQT1NJVE9SWQ0KcklFVEZSRVZJRVcgaWV0Zi1yZXZpZXcNCg0KUkVWSVNJT04gREVUQUlM DQpodHRwczovL21venBoYWItaWV0Zi5kZXZzdmNkZXYubW96YXdzLm5ldC9ENDI3OA0KDQpFTUFJ TCBQUkVGRVJFTkNFUw0KaHR0cHM6Ly9tb3pwaGFiLWlldGYuZGV2c3ZjZGV2Lm1vemF3cy5uZXQv c2V0dGluZ3MvcGFuZWwvZW1haWxwcmVmZXJlbmNlcy8NCg0KVG86IGVrci1tb3osIGVrcg0KQ2M6 IGVrcg0KDQo= --_000_CY4PR21MB05046590C8F5889AB1AAA3C7F5050CY4PR21MB0504namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNvbm9y bWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNv bm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJ bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6 ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFp bFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzAwMjA2MDt9DQouTXNvQ2hwRGVmYXVsdA0K CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFy Z2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpX b3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRp Zl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0 Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0Pjwv eG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5UaGFua3MgZm9yIHRoZSB1c2Vm dWwgcmV2aWV3LCBFcmljLiZuYnNwOyBJ4oCZbGwgd29yayB3aXRoIEJyaWFuIGFuZCB0aGUgY3Jl dyB0byBpbmNvcnBvcmF0ZSB0aGlzIGZlZWRiYWNrLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6IzAwMjA2MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1p a2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IE9BdXRoIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRm Lm9yZ10gPGI+T24gQmVoYWxmIE9mDQo8L2I+RXJpYyBSZXNjb3JsYTxicj4NCjxiPlNlbnQ6PC9i PiBGcmlkYXksIERlY2VtYmVyIDI5LCAyMDE3IDg6NDEgQU08YnI+DQo8Yj5Ubzo8L2I+IG9hdXRo QGlldGYub3JnOyBkcmFmdC1pZXRmLW9hdXRoLXRva2VuLWV4Y2hhbmdlQHRvb2xzLmlldGYub3Jn PGJyPg0KPGI+U3ViamVjdDo8L2I+IFtPQVVUSC1XR10gQUQgUmV2aWV3OiBkcmFmdC1pZXRmLW9h dXRoLXRva2VuLWV4Y2hhbmdlLTA5PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+RnVsbC1mZWF0dXJlZCByZXZpZXcgYXQ6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRwczovL21venBoYWItaWV0Zi5kZXZz dmNkZXYubW96YXdzLm5ldC9ENDI3OCI+aHR0cHM6Ly9tb3pwaGFiLWlldGYuZGV2c3ZjZGV2Lm1v emF3cy5uZXQvRDQyNzg8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHA+QXMg bm90ZWQgaW4gaW5saW5lIGNvbW1lbnRzLCBzb21lIGFkZGl0aW9uYWwgd29yZHMgYWJvdXQgdGhl IHNlY3VyaXR5IG1vZGVsIGluIHdoaWNoIHRoaXMgZG9jdW1lbnQgaXMgZW1iZWRkZWQgc2VlbSBs aWtlIHRoZXkgYXJlIG5lZWRlZC4gSW4gcGFydGljdWxhciwgaXQncyBwcmV0dHkgdW5jbGVhciB0 byBtZSB3aGF0IGNoZWNrcyB0aGUgU1RTIGlzIHN1cHBvc2VkIHRvIGRvIG9uIGEgZ2l2ZW4gcmVx dWVzdCB0byBkZXRlcm1pbmUgd2hldGhlcg0KIHRvIGZ1bGZpbGwgaXQuIFdoZXJlIGlzIHRoYXQg ZG9jdW1lbnRlZD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPklOTElORSBDT01NRU5UUzwvc3Bhbj48L3N0cm9uZz48bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tdG9wOjQuNXB0O21hcmdpbi1ib3R0b206OS4wcHQi Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOnNvbGlkICNDN0NDRDkgMS4wcHQ7cGFkZGluZzowaW4gMGlu IDBpbiAwaW47Ym9yZGVyLXJhZGl1czozcHgiPg0KPGRpdiBzdHlsZT0iYm9yZGVyOnNvbGlkICNF M0U0RTggMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiAwaW4iPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOiNFRkYyRjQiPjxzcGFuIHN0eWxlPSJjb2xvcjoj NzQ3NzdEIj48YSBocmVmPSJodHRwczovL21venBoYWItaWV0Zi5kZXZzdmNkZXYubW96YXdzLm5l dC9ENDI3OCNpbmxpbmUtMTU4MCIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJ0ZXh0LWRl Y29yYXRpb246bm9uZSI+VmlldyBJbmxpbmU8L3NwYW4+PC9hPjwvc3Bhbj48Yj48c3BhbiBzdHls ZT0iY29sb3I6IzRCNEQ1MSI+ZHJhZnQtaWV0Zi1vYXV0aC10b2tlbi1leGNoYW5nZS50eHQ6MTI5 PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iY29sb3I6Izc0Nzc3RCI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6My4wcHQ7bWFyZ2lu LXJpZ2h0OjMuMHB0O2JhY2tncm91bmQ6cmdiYSgxNTIsMjA3LDIzNSwwLjM1KSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTEuMjVwdDtiYWNrZ3JvdW5kOiNGN0Y3 RjciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXMiPnNl Y3VyaW5nIGFjY2VzcyB0byBIVFRQIGFuZCBSRVNUZnVsIHJlc291cmNlcyBidXQgZG8gbm90IHBy b3ZpZGUNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2lu LWxlZnQ6My4wcHQ7bWFyZ2luLXJpZ2h0OjMuMHB0O2JhY2tncm91bmQ6cmdiYSgxNTIsMjA3LDIz NSwwLjM1KSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTEuMjVw dDtiYWNrZ3JvdW5kOiNGN0Y3RjciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC41cHQ7Zm9udC1m YW1pbHk6Q29uc29sYXMiPmV2ZXJ5dGhpbmcgbmVjZXNzYXJ5IHRvIGZhY2lsaXRhdGUgdG9rZW4g ZXhjaGFuZ2UgaW50ZXJhY3Rpb25zLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLXRvcDo2LjBwdDttYXJnaW4tYm90dG9t OjYuMHB0Ij4NCjxwIHN0eWxlPSJtYXJnaW46Ni4wcHQiPkNhbiB5b3Ugc2F5IGEgYml0IG1vcmUg YWJvdXQgd2hhdCBpcyBtaXNzaW5nIGhlcmU/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxl PSJib3JkZXI6c29saWQgI0M3Q0NEOSAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDBpbjtib3Jk ZXItcmFkaXVzOjNweCI+DQo8ZGl2IHN0eWxlPSJib3JkZXI6c29saWQgI0UzRTRFOCAxLjBwdDtw YWRkaW5nOjBpbiAwaW4gMGluIDBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9ImJhY2tncm91bmQ6I0VGRjJGNCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM3NDc3N0QiPjxhIGhy ZWY9Imh0dHBzOi8vbW96cGhhYi1pZXRmLmRldnN2Y2Rldi5tb3phd3MubmV0L0Q0Mjc4I2lubGlu ZS0xNTgxIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9InRleHQtZGVjb3JhdGlvbjpub25l Ij5WaWV3IElubGluZTwvc3Bhbj48L2E+PC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJjb2xvcjojNEI0 RDUxIj5kcmFmdC1pZXRmLW9hdXRoLXRva2VuLWV4Y2hhbmdlLnR4dDoyNjU8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSJjb2xvcjojNzQ3NzdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDozLjBwdDttYXJnaW4tcmlnaHQ6My4wcHQ7 YmFja2dyb3VuZDpyZ2JhKDE1MiwyMDcsMjM1LDAuMzUpIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJsaW5lLWhlaWdodDoxMS4yNXB0O2JhY2tncm91bmQ6I0Y3RjdGNyI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseTpDb25zb2xhcyI+UkVRVUlSRUQuIFRoZSB2 YWx1ZSAmcXVvdDt1cm46aWV0ZjpwYXJhbXM6b2F1dGg6Z3JhbnQtdHlwZTp0b2tlbi0NCjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6My4wcHQ7 bWFyZ2luLXJpZ2h0OjMuMHB0O2JhY2tncm91bmQ6cmdiYSgxNTIsMjA3LDIzNSwwLjM1KSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTEuMjVwdDtiYWNrZ3JvdW5k OiNGN0Y3RjciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6Q29uc29s YXMiPmV4Y2hhbmdlJnF1b3Q7IGluZGljYXRlcyB0aGF0IGEgdG9rZW4gZXhjaGFuZ2UgaXMgYmVp bmcgcGVyZm9ybWVkLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLXRvcDo2LjBwdDttYXJnaW4tYm90dG9tOjYuMHB0Ij4N CjxwIHN0eWxlPSJtYXJnaW46Ni4wcHQiPkkgbm90ZSB0aGF0IFMgNC41LiBzYXlzIHRoYXQgdGhl IGdyYW50X3R5cGUgaXMgJnF1b3Q7ZGVmaW5lZCBieSB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIm cXVvdDsgYnV0IHRoYXQncyBub3QgdGhlIGNhc2UgaGVyZSwgcmlnaHQ/PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6c29saWQgI0M3Q0NEOSAxLjBwdDtwYWRkaW5nOjBpbiAw aW4gMGluIDBpbjtib3JkZXItcmFkaXVzOjNweCI+DQo8ZGl2IHN0eWxlPSJib3JkZXI6c29saWQg I0UzRTRFOCAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6I0VGRjJGNCI+PHNwYW4gc3R5bGU9ImNvbG9y OiM3NDc3N0QiPjxhIGhyZWY9Imh0dHBzOi8vbW96cGhhYi1pZXRmLmRldnN2Y2Rldi5tb3phd3Mu bmV0L0Q0Mjc4I2lubGluZS0xNTgyIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9InRleHQt ZGVjb3JhdGlvbjpub25lIj5WaWV3IElubGluZTwvc3Bhbj48L2E+PC9zcGFuPjxiPjxzcGFuIHN0 eWxlPSJjb2xvcjojNEI0RDUxIj5kcmFmdC1pZXRmLW9hdXRoLXRva2VuLWV4Y2hhbmdlLnR4dDoy Njg8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJjb2xvcjojNzQ3NzdEIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDozLjBwdDttYXJn aW4tcmlnaHQ6My4wcHQ7YmFja2dyb3VuZDpyZ2JhKDE1MiwyMDcsMjM1LDAuMzUpIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxMS4yNXB0O2JhY2tncm91bmQ6I0Y3 RjdGNyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseTpDb25zb2xhcyI+ cmVzb3VyY2UNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFy Z2luLWxlZnQ6My4wcHQ7bWFyZ2luLXJpZ2h0OjMuMHB0O2JhY2tncm91bmQ6cmdiYSgxNTIsMjA3 LDIzNSwwLjM1KSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTEu MjVwdDtiYWNrZ3JvdW5kOiNGN0Y3RjciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC41cHQ7Zm9u dC1mYW1pbHk6Q29uc29sYXMiPk9QVElPTkFMLiBJbmRpY2F0ZXMgdGhlIHBoeXNpY2FsIGxvY2F0 aW9uIG9mIHRoZSB0YXJnZXQgc2VydmljZQ0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDozLjBwdDttYXJnaW4tcmlnaHQ6My4wcHQ7YmFja2dy b3VuZDpyZ2JhKDE1MiwyMDcsMjM1LDAuMzUpIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJsaW5lLWhlaWdodDoxMS4yNXB0O2JhY2tncm91bmQ6I0Y3RjdGNyI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseTpDb25zb2xhcyI+b3IgcmVzb3VyY2Ugd2hlcmUgdGhl IGNsaWVudCBpbnRlbmRzIHRvIHVzZSB0aGUgcmVxdWVzdGVkIHNlY3VyaXR5DQo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4t dG9wOjYuMHB0O21hcmdpbi1ib3R0b206Ni4wcHQiPg0KPHAgc3R5bGU9Im1hcmdpbjo2LjBwdCI+ RG8geW91IGFjdHVhbGx5IG1lYW4gJnF1b3Q7cGh5c2ljYWwmcXVvdDsgaGVyZT8gUHJlc3VtYWJs eSBpZiBpdCdzIGEgVVJJIGl0J3MgbW9zdCBsaWtlbHkgYSBuZXR3b3JrIGFkZHJlc3MuIEkgd291 bGQgdGFrZSAmcXVvdDtwaHlzaWNhbCZxdW90OyB0byBtZWFuICZxdW90O2dlb2dyYXBoaWMmcXVv dDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpzb2xpZCAjQzdDQ0Q5IDEu MHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gMGluO2JvcmRlci1yYWRpdXM6M3B4Ij4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpzb2xpZCAjRTNFNEU4IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gMGluIj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDojRUZGMkY0Ij48 c3BhbiBzdHlsZT0iY29sb3I6Izc0Nzc3RCI+PGEgaHJlZj0iaHR0cHM6Ly9tb3pwaGFiLWlldGYu ZGV2c3ZjZGV2Lm1vemF3cy5uZXQvRDQyNzgjaW5saW5lLTE1ODMiIHRhcmdldD0iX2JsYW5rIj48 c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOm5vbmUiPlZpZXcgSW5saW5lPC9zcGFuPjwvYT48 L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOiM0QjRENTEiPmRyYWZ0LWlldGYtb2F1dGgtdG9r ZW4tZXhjaGFuZ2UudHh0OjMwNDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImNvbG9yOiM3NDc3N0Qi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdp bi1sZWZ0OjMuMHB0O21hcmdpbi1yaWdodDozLjBwdDtiYWNrZ3JvdW5kOnJnYmEoMTUyLDIwNywy MzUsMC4zNSkiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjExLjI1 cHQ7YmFja2dyb3VuZDojRjdGN0Y3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguNXB0O2ZvbnQt ZmFtaWx5OkNvbnNvbGFzIj50YXJnZXQgc2VydmljZXMgd2l0aCBhIG1peCBvZiBsb2dpY2FsIG5h bWVzIGFuZCBwaHlzaWNhbA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0 eWxlPSJtYXJnaW4tbGVmdDozLjBwdDttYXJnaW4tcmlnaHQ6My4wcHQ7YmFja2dyb3VuZDpyZ2Jh KDE1MiwyMDcsMjM1LDAuMzUpIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhl aWdodDoxMS4yNXB0O2JhY2tncm91bmQ6I0Y3RjdGNyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4 LjVwdDtmb250LWZhbWlseTpDb25zb2xhcyI+bG9jYXRpb25zLg0KPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLXRvcDo2LjBw dDttYXJnaW4tYm90dG9tOjYuMHB0Ij4NCjxwIHN0eWxlPSJtYXJnaW46Ni4wcHQiPkJ1dCBpdCBz ZWVtcyB5b3UgY2FuIG9ubHkgc3BlY2lmeSBvbmUgb2YgZWFjaCwgcmlnaHQ/PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6c29saWQgI0M3Q0NEOSAxLjBwdDtwYWRkaW5nOjBp biAwaW4gMGluIDBpbjtib3JkZXItcmFkaXVzOjNweCI+DQo8ZGl2IHN0eWxlPSJib3JkZXI6c29s aWQgI0UzRTRFOCAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDBpbiI+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6I0VGRjJGNCI+PHNwYW4gc3R5bGU9ImNv bG9yOiM3NDc3N0QiPjxhIGhyZWY9Imh0dHBzOi8vbW96cGhhYi1pZXRmLmRldnN2Y2Rldi5tb3ph d3MubmV0L0Q0Mjc4I2lubGluZS0xNTg0IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9InRl eHQtZGVjb3JhdGlvbjpub25lIj5WaWV3IElubGluZTwvc3Bhbj48L2E+PC9zcGFuPjxiPjxzcGFu IHN0eWxlPSJjb2xvcjojNEI0RDUxIj5kcmFmdC1pZXRmLW9hdXRoLXRva2VuLWV4Y2hhbmdlLnR4 dDozMTA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJjb2xvcjojNzQ3NzdEIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDozLjBwdDtt YXJnaW4tcmlnaHQ6My4wcHQ7YmFja2dyb3VuZDpyZ2JhKDE1MiwyMDcsMjM1LDAuMzUpIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxMS4yNXB0O2JhY2tncm91bmQ6 I0Y3RjdGNyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseTpDb25zb2xh cyI+c2VjdXJpdHkgdG9rZW4gaW4gdGhlIGNvbnRleHQgb2YgdGhlIHNlcnZpY2Ugb3IgcmVzb3Vy Y2Ugd2hlcmUgdGhlDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9 Im1hcmdpbi1sZWZ0OjMuMHB0O21hcmdpbi1yaWdodDozLjBwdDtiYWNrZ3JvdW5kOnJnYmEoMTUy LDIwNywyMzUsMC4zNSkiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0 OjExLjI1cHQ7YmFja2dyb3VuZDojRjdGN0Y3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguNXB0 O2ZvbnQtZmFtaWx5OkNvbnNvbGFzIj50b2tlbiB3aWxsIGJlIHVzZWQuDQo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tdG9w OjYuMHB0O21hcmdpbi1ib3R0b206Ni4wcHQiPg0KPHAgc3R5bGU9Im1hcmdpbjo2LjBwdCI+SXQn cyBub3QgY2xlYXIgdG8gbWUgd2hlcmUgdGhlc2UgdmFsdWVzIHdvdWxkIGNvbWUgZnJvbS4gQ2Fu IHlvdSBleHBhbmQgb24gdGhpcz88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRl cjpzb2xpZCAjQzdDQ0Q5IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gMGluO2JvcmRlci1yYWRp dXM6M3B4Ij4NCjxkaXYgc3R5bGU9ImJvcmRlcjpzb2xpZCAjRTNFNEU4IDEuMHB0O3BhZGRpbmc6 MGluIDBpbiAwaW4gMGluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFj a2dyb3VuZDojRUZGMkY0Ij48c3BhbiBzdHlsZT0iY29sb3I6Izc0Nzc3RCI+PGEgaHJlZj0iaHR0 cHM6Ly9tb3pwaGFiLWlldGYuZGV2c3ZjZGV2Lm1vemF3cy5uZXQvRDQyNzgjaW5saW5lLTE1ODUi IHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOm5vbmUiPlZpZXcg SW5saW5lPC9zcGFuPjwvYT48L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOiM0QjRENTEiPmRy YWZ0LWlldGYtb2F1dGgtdG9rZW4tZXhjaGFuZ2UudHh0OjM0MTwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImNvbG9yOiM3NDc3N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0OjMuMHB0O21hcmdpbi1yaWdodDozLjBwdDtiYWNrZ3Jv dW5kOnJnYmEoMTUyLDIwNywyMzUsMC4zNSkiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImxpbmUtaGVpZ2h0OjExLjI1cHQ7YmFja2dyb3VuZDojRjdGN0Y3Ij48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzIj5SRVFVSVJFRCB3aGVuIHRoZSAmcXVv dDthY3Rvcl90b2tlbiZxdW90OyBwYXJhbWV0ZXIgaXMgcHJlc2VudCBpbiB0aGUNCjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6My4wcHQ7bWFy Z2luLXJpZ2h0OjMuMHB0O2JhY2tncm91bmQ6cmdiYSgxNTIsMjA3LDIzNSwwLjM1KSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTEuMjVwdDtiYWNrZ3JvdW5kOiNG N0Y3RjciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXMi PnJlcXVlc3QgYnV0IE1VU1QgTk9UIGJlIGluY2x1ZGVkIG90aGVyd2lzZS4NCjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi10 b3A6Ni4wcHQ7bWFyZ2luLWJvdHRvbTo2LjBwdCI+DQo8cCBzdHlsZT0ibWFyZ2luOjYuMHB0Ij5J dCdzIG5vdCBlbnRpcmVseSBjbGVhciB0byBtZSBmcm9tIHRoaXMgdGV4dCBob3cgdGhlc2UgdG9r ZW5zIGF1dGhlbnRpY2F0ZSB0aGUgcmVxdWVzdC4gSXQncyBjbGVhciBpZiB0aGV5IGFyZSBiZWFy ZXIgdG9rZW5zLCBidXQgaWYgdGhleSBhcmUgc29tZSBzb3J0IG9mIHRva2VuIG92ZXIgYSBwdWJs aWMga2V5LCB0aGVuIGhvdyBkb2VzIHRoYXQgd29yay48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYg c3R5bGU9ImJvcmRlcjpzb2xpZCAjQzdDQ0Q5IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gMGlu O2JvcmRlci1yYWRpdXM6M3B4Ij4NCjxkaXYgc3R5bGU9ImJvcmRlcjpzb2xpZCAjRTNFNEU4IDEu MHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gMGluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iYmFja2dyb3VuZDojRUZGMkY0Ij48c3BhbiBzdHlsZT0iY29sb3I6Izc0Nzc3RCI+ PGEgaHJlZj0iaHR0cHM6Ly9tb3pwaGFiLWlldGYuZGV2c3ZjZGV2Lm1vemF3cy5uZXQvRDQyNzgj aW5saW5lLTE1ODYiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0aW9u Om5vbmUiPlZpZXcgSW5saW5lPC9zcGFuPjwvYT48L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImNvbG9y OiM0QjRENTEiPmRyYWZ0LWlldGYtb2F1dGgtdG9rZW4tZXhjaGFuZ2UudHh0OjU4Nzwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImNvbG9yOiM3NDc3N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0OjMuMHB0O21hcmdpbi1yaWdodDoz LjBwdDtiYWNrZ3JvdW5kOnJnYmEoMTUyLDIwNywyMzUsMC4zNSkiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjExLjI1cHQ7YmFja2dyb3VuZDojRjdGN0Y3Ij48c3Bh biBzdHlsZT0iZm9udC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzIj4yLjAgW09BU0lT LnNhbWwtY29yZS0yLjAtb3NdIGFzc2VydGlvbiwgcmVzcGVjdGl2ZWx5LiBPdGhlciBVUklzIHRv DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0 OjMuMHB0O21hcmdpbi1yaWdodDozLjBwdDtiYWNrZ3JvdW5kOnJnYmEoMTUyLDIwNywyMzUsMC4z NSkiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjExLjI1cHQ7YmFj a2dyb3VuZDojRjdGN0Y3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5 OkNvbnNvbGFzIj5pbmRpY2F0ZSBvdGhlciB0b2tlbiB0eXBlcyBNQVkgYmUgdXNlZC4NCjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1h cmdpbi10b3A6Ni4wcHQ7bWFyZ2luLWJvdHRvbTo2LjBwdCI+DQo8cCBzdHlsZT0ibWFyZ2luOjYu MHB0Ij5UaGlzIGZlZWxzIGxpa2UgaXQgd291bGQgYmUgYmV0dGVyIGFzIHNvbWUga2luZCBvZiBs aXN0IChtYXliZSBidWxsZXRlZCk/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6c29saWQgI0M3Q0NEOSAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDBpbjtib3JkZXItcmFk aXVzOjNweCI+DQo8ZGl2IHN0eWxlPSJib3JkZXI6c29saWQgI0UzRTRFOCAxLjBwdDtwYWRkaW5n OjBpbiAwaW4gMGluIDBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJh Y2tncm91bmQ6I0VGRjJGNCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM3NDc3N0QiPjxhIGhyZWY9Imh0 dHBzOi8vbW96cGhhYi1pZXRmLmRldnN2Y2Rldi5tb3phd3MubmV0L0Q0Mjc4I2lubGluZS0xNTg3 IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9InRleHQtZGVjb3JhdGlvbjpub25lIj5WaWV3 IElubGluZTwvc3Bhbj48L2E+PC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJjb2xvcjojNEI0RDUxIj5k cmFmdC1pZXRmLW9hdXRoLXRva2VuLWV4Y2hhbmdlLnR4dDo2NjY8L3NwYW4+PC9iPjxzcGFuIHN0 eWxlPSJjb2xvcjojNzQ3NzdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDozLjBwdDttYXJnaW4tcmlnaHQ6My4wcHQ7YmFja2dy b3VuZDpyZ2JhKDE1MiwyMDcsMjM1LDAuMzUpIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJsaW5lLWhlaWdodDoxMS4yNXB0O2JhY2tncm91bmQ6I0Y3RjdGNyI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseTpDb25zb2xhcyI+aXQgYXMgdGhlIGN1cnJlbnQgYWN0 b3IgYW5kIHRoYXQgY2FuIGJlIHVzZWQgYXQNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6My4wcHQ7bWFyZ2luLXJpZ2h0OjMuMHB0O2JhY2tn cm91bmQ6cmdiYSgxNTIsMjA3LDIzNSwwLjM1KSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibGluZS1oZWlnaHQ6MTEuMjVwdDtiYWNrZ3JvdW5kOiNGN0Y3RjciPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXMiPjxhIGhyZWY9Imh0dHBzOi8vYmFj a2VuZC5leGFtcGxlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vYmFja2VuZC5leGFtcGxl LmNvbTwvYT4uDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2IHN0eWxlPSJtYXJnaW4tdG9wOjYuMHB0O21hcmdpbi1ib3R0b206Ni4wcHQiPg0KPHAg c3R5bGU9Im1hcmdpbjo2LjBwdCI+V2hlcmUgY2FuIEkgZmluZCB0aGUgZGVmaW5pdGlvbnMgb2Yg JnF1b3Q7aXNzJnF1b3Q7IGFuZCAmcXVvdDtzdWImcXVvdDs/PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6c29saWQgI0M3Q0NEOSAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGlu IDBpbjtib3JkZXItcmFkaXVzOjNweCI+DQo8ZGl2IHN0eWxlPSJib3JkZXI6c29saWQgI0UzRTRF OCAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6I0VGRjJGNCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM3NDc3 N0QiPjxhIGhyZWY9Imh0dHBzOi8vbW96cGhhYi1pZXRmLmRldnN2Y2Rldi5tb3phd3MubmV0L0Q0 Mjc4I2lubGluZS0xNTg4IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9InRleHQtZGVjb3Jh dGlvbjpub25lIj5WaWV3IElubGluZTwvc3Bhbj48L2E+PC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJj b2xvcjojNEI0RDUxIj5kcmFmdC1pZXRmLW9hdXRoLXRva2VuLWV4Y2hhbmdlLnR4dDo2ODk8L3Nw YW4+PC9iPjxzcGFuIHN0eWxlPSJjb2xvcjojNzQ3NzdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDozLjBwdDttYXJnaW4tcmln aHQ6My4wcHQ7YmFja2dyb3VuZDpyZ2JhKDE1MiwyMDcsMjM1LDAuMzUpIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxMS4yNXB0O2JhY2tncm91bmQ6I0Y3RjdGNyI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseTpDb25zb2xhcyI+cmVzcG9u c2UsICZxdW90O2FjdCZxdW90OyBoYXMgdGhlIHNhbWUgc2VtYW50aWNzIGFuZCBmb3JtYXQgYXMg dGhlIGNsYWltIG9mIHRoZQ0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0 eWxlPSJtYXJnaW4tbGVmdDozLjBwdDttYXJnaW4tcmlnaHQ6My4wcHQ7YmFja2dyb3VuZDpyZ2Jh KDE1MiwyMDcsMjM1LDAuMzUpIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhl aWdodDoxMS4yNXB0O2JhY2tncm91bmQ6I0Y3RjdGNyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4 LjVwdDtmb250LWZhbWlseTpDb25zb2xhcyI+c2FtZSBuYW1lLg0KPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLXRvcDo2LjBw dDttYXJnaW4tYm90dG9tOjYuMHB0Ij4NCjxwIHN0eWxlPSJtYXJnaW46Ni4wcHQiPkl0J3Mgbm90 IGVudGlyZWx5IGNsZWFyIHRvIG1lIGhvdyBJJ20gc3VwcG9zZWQgdG8gZXZhbHVhdGUgdGhlc2Ug ZnJvbSBhbiBhY2Nlc3MgY29udHJvbCBwZXJzcGVjdGl2ZS48bzpwPjwvbzpwPjwvcD4NCjxwIHN0 eWxlPSJtYXJnaW46Ni4wcHQiPklzIHRoZSBhc3N1bXB0aW9uIGhlcmUgdGhhdCB0aGUgZW50aXR5 IHByb2R1Y2luZyB0aGUgSldUIGhhcyBlbnN1cmVkIHRoZSBjb3JyZWN0IGNoYWluIG9mIGlzc3Vl cnMgYW5kIHN1YnM/PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjYuMHB0Ij5JcyBp dCB0aGUgUlAncyBqb2IgdG8gZXZhbHVhdGUgd2hldGhlciBlYWNoIGVudGl0eSBpbiB0aGUgY2hh aW4gY291bGQgaGF2ZSBwZXJmb3JtZWQgdGhlIGFjdGlvbj88bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXYgc3R5bGU9ImJvcmRlcjpzb2xpZCAjQzdDQ0Q5IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4g MGluO2JvcmRlci1yYWRpdXM6M3B4Ij4NCjxkaXYgc3R5bGU9ImJvcmRlcjpzb2xpZCAjRTNFNEU4 IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gMGluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0iYmFja2dyb3VuZDojRUZGMkY0Ij48c3BhbiBzdHlsZT0iY29sb3I6Izc0Nzc3 RCI+PGEgaHJlZj0iaHR0cHM6Ly9tb3pwaGFiLWlldGYuZGV2c3ZjZGV2Lm1vemF3cy5uZXQvRDQy NzgjaW5saW5lLTE1ODkiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0 aW9uOm5vbmUiPlZpZXcgSW5saW5lPC9zcGFuPjwvYT48L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImNv bG9yOiM0QjRENTEiPmRyYWZ0LWlldGYtb2F1dGgtdG9rZW4tZXhjaGFuZ2UudHh0Ojc1NTwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9ImNvbG9yOiM3NDc3N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0OjMuMHB0O21hcmdpbi1yaWdo dDozLjBwdDtiYWNrZ3JvdW5kOnJnYmEoMTUyLDIwNywyMzUsMC4zNSkiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjExLjI1cHQ7YmFja2dyb3VuZDojRjdGN0Y3Ij48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzIj5jbGFpbXMg c3VjaCBhcyAmcXVvdDtleHAmcXVvdDssICZxdW90O25iZiZxdW90OywgYW5kICZxdW90O2F1ZCZx dW90OyBhcmUgbm90IG1lYW5pbmdmdWwgd2hlbiB1c2VkDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0OjMuMHB0O21hcmdpbi1yaWdodDozLjBw dDtiYWNrZ3JvdW5kOnJnYmEoMTUyLDIwNywyMzUsMC4zNSkiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjExLjI1cHQ7YmFja2dyb3VuZDojRjdGN0Y3Ij48c3BhbiBz dHlsZT0iZm9udC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzIj53aXRoaW4gYSAmcXVv dDttYXlfYWN0JnF1b3Q7IGNsYWltLCBhbmQgdGhlcmVmb3JlIHNob3VsZCBub3QgYmUgdXNlZC4N CjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5 bGU9Im1hcmdpbi10b3A6Ni4wcHQ7bWFyZ2luLWJvdHRvbTo2LjBwdCI+DQo8cCBzdHlsZT0ibWFy Z2luOjYuMHB0Ij5JJ20gaGF2aW5nIGEgaGFyZCB0aW1lIHVuZGVyc3RhbmRpbmcgdGhpcyBjbGFp bS4gQ2FuIHlvdSBwcm92aWRlIGFuIGV4YW1wbGUgdG8gbWUgKGluIGVtYWlsIGlzIGZpbmUsIGl0 IGRvZXNuJ3QgbmVlZCB0byBiZSBpbiB0aGUgZHJhZnQpIG9mIGhvdyBpdCB3b3VsZCBiZSB1c2Vk PzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOnNvbGlkICNDN0NDRDkgMS4w cHQ7cGFkZGluZzowaW4gMGluIDBpbiAwaW47Ym9yZGVyLXJhZGl1czozcHgiPg0KPGRpdiBzdHls ZT0iYm9yZGVyOnNvbGlkICNFM0U0RTggMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiAwaW4iPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOiNFRkYyRjQiPjxz cGFuIHN0eWxlPSJjb2xvcjojNzQ3NzdEIj48YSBocmVmPSJodHRwczovL21venBoYWItaWV0Zi5k ZXZzdmNkZXYubW96YXdzLm5ldC9ENDI3OCNpbmxpbmUtMTU5MCIgdGFyZ2V0PSJfYmxhbmsiPjxz cGFuIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246bm9uZSI+VmlldyBJbmxpbmU8L3NwYW4+PC9hPjwv c3Bhbj48Yj48c3BhbiBzdHlsZT0iY29sb3I6IzRCNEQ1MSI+ZHJhZnQtaWV0Zi1vYXV0aC10b2tl bi1leGNoYW5nZS50eHQ6MTI3Mzwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImNvbG9yOiM3NDc3N0Qi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdp bi1sZWZ0OjMuMHB0O21hcmdpbi1yaWdodDozLjBwdDtiYWNrZ3JvdW5kOnJnYmEoMTUyLDIwNywy MzUsMC4zNSkiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjExLjI1 cHQ7YmFja2dyb3VuZDojRjdGN0Y3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguNXB0O2ZvbnQt ZmFtaWx5OkNvbnNvbGFzIj5wcm9kdWNlZCB1bmRlciB0aGUgY2hhaXJtYW5zaGlwIG9mIEhhbm5l cyBUc2Nob2ZlbmlnIGFuZCBEZXJlayBBdGtpbnMNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6My4wcHQ7bWFyZ2luLXJpZ2h0OjMuMHB0O2Jh Y2tncm91bmQ6cmdiYSgxNTIsMjA3LDIzNSwwLjM1KSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibGluZS1oZWlnaHQ6MTEuMjVwdDtiYWNrZ3JvdW5kOiNGN0Y3RjciPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXMiPndpdGggS2F0aGxlZW4gTW9y aWFydHkgYW5kIFN0ZXBoZW4gRmFycmVsbCBzZXJ2aW5nIGFzIFNlY3VyaXR5IEFyZWENCjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6My4wcHQ7 bWFyZ2luLXJpZ2h0OjMuMHB0O2JhY2tncm91bmQ6cmdiYSgxNTIsMjA3LDIzNSwwLjM1KSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTEuMjVwdDtiYWNrZ3JvdW5k OiNGN0Y3RjciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6Q29uc29s YXMiPkRpcmVjdG9ycy4gVGhlIGZvbGxvd2luZyBpbmRpdmlkdWFscyBjb250cmlidXRlZCBpZGVh cywgZmVlZGJhY2ssDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tdG9wOjYuMHB0O21hcmdpbi1ib3R0b206Ni4wcHQiPg0K PHAgc3R5bGU9Im1hcmdpbjo2LjBwdCI+WW91IG1heSB3YW50IHRvIHVwZGF0ZSB0aGlzPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHN0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj5SRVBPU0lUT1JZPC9zcGFuPjwvc3Ryb25nPjxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ySUVURlJFVklFVyBpZXRmLXJl dmlldzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHN0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj5SRVZJU0lPTiBERVRBSUw8L3NwYW4+PC9zdHJvbmc+PG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly9tb3pwaGFiLWll dGYuZGV2c3ZjZGV2Lm1vemF3cy5uZXQvRDQyNzgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL21v enBoYWItaWV0Zi5kZXZzdmNkZXYubW96YXdzLm5ldC9ENDI3ODwvYT48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkVNQUlMIFBSRUZFUkVOQ0VT PC9zcGFuPjwvc3Ryb25nPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxhIGhyZWY9Imh0dHBzOi8vbW96cGhhYi1pZXRmLmRldnN2Y2Rldi5tb3phd3MubmV0L3Nl dHRpbmdzL3BhbmVsL2VtYWlscHJlZmVyZW5jZXMvIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9t b3pwaGFiLWlldGYuZGV2c3ZjZGV2Lm1vemF3cy5uZXQvc2V0dGluZ3MvcGFuZWwvZW1haWxwcmVm ZXJlbmNlcy88L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHN0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj5UbzogPC9zcGFuPg0KPC9zdHJvbmc+ZWtyLW1veiwgZWtyPGJyPg0KPHN0cm9u Zz48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij5DYzogPC9zcGFuPjwvc3Ryb25nPmVrcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_CY4PR21MB05046590C8F5889AB1AAA3C7F5050CY4PR21MB0504namp_-- From nobody Fri Dec 29 18:34:03 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E656126FDC for ; Fri, 29 Dec 2017 18:34:01 -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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lZ2pWGJB-Ziz for ; Fri, 29 Dec 2017 18:33:59 -0800 (PST) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0094.outbound.protection.outlook.com [104.47.32.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBFF1126FB3 for ; Fri, 29 Dec 2017 18:33:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=u0g6IAGS25u+jpOWgxieACaVeBIiviG/IP0J48ayMeg=; b=FzQXi2OtKPAZtkbUuuGTSHDpM/alA9CUiLCjXy83bsyv0v6amXpnQHJ6hNgUagnDiZTnQyin9Lwg1bI6VmjeLOlZkheW1DtGfvYPM3/SK2k/9q48Zn3LfCvEE5Z4QlIjCLisouSDswAqQOSTsYHLgkr4tVpKS2K5hMSLxRBY08o= Received: from MWHPR21MB0752.namprd21.prod.outlook.com (10.173.51.14) by MWHPR21MB0752.namprd21.prod.outlook.com (10.173.51.14) with TransportReplication id Version 15.20 (Build 407.0); Sat, 30 Dec 2017 02:33:56 +0000 Received: from CY4PR21MB0504.namprd21.prod.outlook.com (10.172.122.14) by CY4PR21MB0744.namprd21.prod.outlook.com (10.173.189.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.345.2; Fri, 29 Dec 2017 17:48:06 +0000 Received: from CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) by CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) with mapi id 15.20.0407.000; Fri, 29 Dec 2017 17:48:06 +0000 From: Mike Jones To: Eric Rescorla , "oauth@ietf.org" , "draft-ietf-oauth-token-exchange@tools.ietf.org" Thread-Topic: [OAUTH-WG] AD Review: draft-ietf-oauth-token-exchange-09 Thread-Index: AQHTgMPugLlckbvpIE2JNpgrfT8UNaNamK8Q Date: Fri, 29 Dec 2017 17:48:06 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.47.88.182] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR21MB0752; 7:c9HWLtWHHmFZQPQws6ymtqSABLjoKlp6bpWEq2zPC6ZHiMaRgbo7h8JLlaDzRIJJ1vmSKOa4lU1gpPEshDIIvW3hewEEoIEdFDw7y2TjjqcoPrCjdLdaKvWJPZbopEfr+2rrONym3wHekzHMx5uNKVN9uwpD+VrY0pYo3lLwDNTVzX1xyFaOpG5BadMmAvEkDMcAvvcDzPxBdnMyH8JBnQfg9V6t6GutjWbvFYzYaujVE0VhvrMIr2XyDIgPEuWi x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 3f4f388b-34a5-41d8-7dbe-08d54ee4516f x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020020)(48565401081)(4534040)(4602075)(4627136)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307); SRVR:CY4PR21MB0744; x-ms-traffictypediagnostic: MWHPR21MB0752: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(192374486261705)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040470)(2401047)(5005006)(8121501046)(3002001)(3231023)(944501075)(93006095)(93001095)(10201501046)(6055026)(61426038)(61427038)(6041268)(20161123562045)(20161123564045)(20161123558120)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:MWHPR21MB0752; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:MWHPR21MB0752; x-forefront-prvs: 05373A0663 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39380400002)(396003)(366004)(376002)(39860400002)(346002)(51914003)(189003)(199004)(76176011)(7696005)(606006)(97736004)(8990500004)(2906002)(14454004)(72206003)(966005)(478600001)(2900100001)(105586002)(106356001)(3846002)(2201001)(86362001)(10290500003)(6246003)(6116002)(790700001)(74316002)(229853002)(33656002)(110136005)(6506007)(53546011)(66066001)(22452003)(59450400001)(9686003)(236005)(3660700001)(102836004)(68736007)(316002)(3280700002)(2501003)(53936002)(54896002)(6306002)(77096006)(230783001)(7736002)(19609705001)(55016002)(10090500001)(6436002)(25786009)(2950100002)(8936002)(81156014)(86612001)(8676002)(99286004)(81166006)(5660300001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR21MB0752; H:CY4PR21MB0504.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-microsoft-antispam-message-info: P0WjdaOmwS93/ewvSbsEwiUrtLvB9T7lVIv3WsU0HrhhFAoctIS1cpqUD5qroID8H8PdrWJx4V7kNxIVLP9+ig== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB05046590C8F5889AB1AAA3C7F5050CY4PR21MB0504namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3f4f388b-34a5-41d8-7dbe-08d54ee4516f X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Dec 2017 17:48:06.7243 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR21MB0752 Archived-At: Subject: Re: [OAUTH-WG] AD Review: draft-ietf-oauth-token-exchange-09 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Dec 2017 02:34:01 -0000 --_000_CY4PR21MB05046590C8F5889AB1AAA3C7F5050CY4PR21MB0504namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIGZvciB0aGUgdXNlZnVsIHJldmlldywgRXJpYy4gIEnigJlsbCB3b3JrIHdpdGggQnJp YW4gYW5kIHRoZSBjcmV3IHRvIGluY29ycG9yYXRlIHRoaXMgZmVlZGJhY2suDQoNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoN CkZyb206IE9BdXRoIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IEVyaWMgUmVzY29ybGENClNlbnQ6IEZyaWRheSwgRGVjZW1iZXIgMjksIDIwMTcgODo0MSBBTQ0K VG86IG9hdXRoQGlldGYub3JnOyBkcmFmdC1pZXRmLW9hdXRoLXRva2VuLWV4Y2hhbmdlQHRvb2xz LmlldGYub3JnDQpTdWJqZWN0OiBbT0FVVEgtV0ddIEFEIFJldmlldzogZHJhZnQtaWV0Zi1vYXV0 aC10b2tlbi1leGNoYW5nZS0wOQ0KDQpGdWxsLWZlYXR1cmVkIHJldmlldyBhdDoNCmh0dHBzOi8v bW96cGhhYi1pZXRmLmRldnN2Y2Rldi5tb3phd3MubmV0L0Q0Mjc4DQoNCg0KQXMgbm90ZWQgaW4g aW5saW5lIGNvbW1lbnRzLCBzb21lIGFkZGl0aW9uYWwgd29yZHMgYWJvdXQgdGhlIHNlY3VyaXR5 IG1vZGVsIGluIHdoaWNoIHRoaXMgZG9jdW1lbnQgaXMgZW1iZWRkZWQgc2VlbSBsaWtlIHRoZXkg YXJlIG5lZWRlZC4gSW4gcGFydGljdWxhciwgaXQncyBwcmV0dHkgdW5jbGVhciB0byBtZSB3aGF0 IGNoZWNrcyB0aGUgU1RTIGlzIHN1cHBvc2VkIHRvIGRvIG9uIGEgZ2l2ZW4gcmVxdWVzdCB0byBk ZXRlcm1pbmUgd2hldGhlciB0byBmdWxmaWxsIGl0LiBXaGVyZSBpcyB0aGF0IGRvY3VtZW50ZWQ/ DQoNCklOTElORSBDT01NRU5UUw0KVmlldyBJbmxpbmU8aHR0cHM6Ly9tb3pwaGFiLWlldGYuZGV2 c3ZjZGV2Lm1vemF3cy5uZXQvRDQyNzgjaW5saW5lLTE1ODA+ZHJhZnQtaWV0Zi1vYXV0aC10b2tl bi1leGNoYW5nZS50eHQ6MTI5DQpzZWN1cmluZyBhY2Nlc3MgdG8gSFRUUCBhbmQgUkVTVGZ1bCBy ZXNvdXJjZXMgYnV0IGRvIG5vdCBwcm92aWRlDQpldmVyeXRoaW5nIG5lY2Vzc2FyeSB0byBmYWNp bGl0YXRlIHRva2VuIGV4Y2hhbmdlIGludGVyYWN0aW9ucy4NCg0KQ2FuIHlvdSBzYXkgYSBiaXQg bW9yZSBhYm91dCB3aGF0IGlzIG1pc3NpbmcgaGVyZT8NCg0KVmlldyBJbmxpbmU8aHR0cHM6Ly9t b3pwaGFiLWlldGYuZGV2c3ZjZGV2Lm1vemF3cy5uZXQvRDQyNzgjaW5saW5lLTE1ODE+ZHJhZnQt aWV0Zi1vYXV0aC10b2tlbi1leGNoYW5nZS50eHQ6MjY1DQpSRVFVSVJFRC4gVGhlIHZhbHVlICJ1 cm46aWV0ZjpwYXJhbXM6b2F1dGg6Z3JhbnQtdHlwZTp0b2tlbi0NCmV4Y2hhbmdlIiBpbmRpY2F0 ZXMgdGhhdCBhIHRva2VuIGV4Y2hhbmdlIGlzIGJlaW5nIHBlcmZvcm1lZC4NCg0KSSBub3RlIHRo YXQgUyA0LjUuIHNheXMgdGhhdCB0aGUgZ3JhbnRfdHlwZSBpcyAiZGVmaW5lZCBieSB0aGUgYXV0 aG9yaXphdGlvbiBzZXJ2ZXIiIGJ1dCB0aGF0J3Mgbm90IHRoZSBjYXNlIGhlcmUsIHJpZ2h0Pw0K DQpWaWV3IElubGluZTxodHRwczovL21venBoYWItaWV0Zi5kZXZzdmNkZXYubW96YXdzLm5ldC9E NDI3OCNpbmxpbmUtMTU4Mj5kcmFmdC1pZXRmLW9hdXRoLXRva2VuLWV4Y2hhbmdlLnR4dDoyNjgN CnJlc291cmNlDQpPUFRJT05BTC4gSW5kaWNhdGVzIHRoZSBwaHlzaWNhbCBsb2NhdGlvbiBvZiB0 aGUgdGFyZ2V0IHNlcnZpY2UNCm9yIHJlc291cmNlIHdoZXJlIHRoZSBjbGllbnQgaW50ZW5kcyB0 byB1c2UgdGhlIHJlcXVlc3RlZCBzZWN1cml0eQ0KDQpEbyB5b3UgYWN0dWFsbHkgbWVhbiAicGh5 c2ljYWwiIGhlcmU/IFByZXN1bWFibHkgaWYgaXQncyBhIFVSSSBpdCdzIG1vc3QgbGlrZWx5IGEg bmV0d29yayBhZGRyZXNzLiBJIHdvdWxkIHRha2UgInBoeXNpY2FsIiB0byBtZWFuICJnZW9ncmFw aGljIg0KDQpWaWV3IElubGluZTxodHRwczovL21venBoYWItaWV0Zi5kZXZzdmNkZXYubW96YXdz Lm5ldC9ENDI3OCNpbmxpbmUtMTU4Mz5kcmFmdC1pZXRmLW9hdXRoLXRva2VuLWV4Y2hhbmdlLnR4 dDozMDQNCnRhcmdldCBzZXJ2aWNlcyB3aXRoIGEgbWl4IG9mIGxvZ2ljYWwgbmFtZXMgYW5kIHBo eXNpY2FsDQpsb2NhdGlvbnMuDQoNCkJ1dCBpdCBzZWVtcyB5b3UgY2FuIG9ubHkgc3BlY2lmeSBv bmUgb2YgZWFjaCwgcmlnaHQ/DQoNClZpZXcgSW5saW5lPGh0dHBzOi8vbW96cGhhYi1pZXRmLmRl dnN2Y2Rldi5tb3phd3MubmV0L0Q0Mjc4I2lubGluZS0xNTg0PmRyYWZ0LWlldGYtb2F1dGgtdG9r ZW4tZXhjaGFuZ2UudHh0OjMxMA0Kc2VjdXJpdHkgdG9rZW4gaW4gdGhlIGNvbnRleHQgb2YgdGhl IHNlcnZpY2Ugb3IgcmVzb3VyY2Ugd2hlcmUgdGhlDQp0b2tlbiB3aWxsIGJlIHVzZWQuDQoNCkl0 J3Mgbm90IGNsZWFyIHRvIG1lIHdoZXJlIHRoZXNlIHZhbHVlcyB3b3VsZCBjb21lIGZyb20uIENh biB5b3UgZXhwYW5kIG9uIHRoaXM/DQoNClZpZXcgSW5saW5lPGh0dHBzOi8vbW96cGhhYi1pZXRm LmRldnN2Y2Rldi5tb3phd3MubmV0L0Q0Mjc4I2lubGluZS0xNTg1PmRyYWZ0LWlldGYtb2F1dGgt dG9rZW4tZXhjaGFuZ2UudHh0OjM0MQ0KUkVRVUlSRUQgd2hlbiB0aGUgImFjdG9yX3Rva2VuIiBw YXJhbWV0ZXIgaXMgcHJlc2VudCBpbiB0aGUNCnJlcXVlc3QgYnV0IE1VU1QgTk9UIGJlIGluY2x1 ZGVkIG90aGVyd2lzZS4NCg0KSXQncyBub3QgZW50aXJlbHkgY2xlYXIgdG8gbWUgZnJvbSB0aGlz IHRleHQgaG93IHRoZXNlIHRva2VucyBhdXRoZW50aWNhdGUgdGhlIHJlcXVlc3QuIEl0J3MgY2xl YXIgaWYgdGhleSBhcmUgYmVhcmVyIHRva2VucywgYnV0IGlmIHRoZXkgYXJlIHNvbWUgc29ydCBv ZiB0b2tlbiBvdmVyIGEgcHVibGljIGtleSwgdGhlbiBob3cgZG9lcyB0aGF0IHdvcmsuDQoNClZp ZXcgSW5saW5lPGh0dHBzOi8vbW96cGhhYi1pZXRmLmRldnN2Y2Rldi5tb3phd3MubmV0L0Q0Mjc4 I2lubGluZS0xNTg2PmRyYWZ0LWlldGYtb2F1dGgtdG9rZW4tZXhjaGFuZ2UudHh0OjU4Nw0KMi4w IFtPQVNJUy5zYW1sLWNvcmUtMi4wLW9zXSBhc3NlcnRpb24sIHJlc3BlY3RpdmVseS4gT3RoZXIg VVJJcyB0bw0KaW5kaWNhdGUgb3RoZXIgdG9rZW4gdHlwZXMgTUFZIGJlIHVzZWQuDQoNClRoaXMg ZmVlbHMgbGlrZSBpdCB3b3VsZCBiZSBiZXR0ZXIgYXMgc29tZSBraW5kIG9mIGxpc3QgKG1heWJl IGJ1bGxldGVkKT8NCg0KVmlldyBJbmxpbmU8aHR0cHM6Ly9tb3pwaGFiLWlldGYuZGV2c3ZjZGV2 Lm1vemF3cy5uZXQvRDQyNzgjaW5saW5lLTE1ODc+ZHJhZnQtaWV0Zi1vYXV0aC10b2tlbi1leGNo YW5nZS50eHQ6NjY2DQppdCBhcyB0aGUgY3VycmVudCBhY3RvciBhbmQgdGhhdCBjYW4gYmUgdXNl ZCBhdA0KaHR0cHM6Ly9iYWNrZW5kLmV4YW1wbGUuY29tLg0KDQpXaGVyZSBjYW4gSSBmaW5kIHRo ZSBkZWZpbml0aW9ucyBvZiAiaXNzIiBhbmQgInN1YiI/DQoNClZpZXcgSW5saW5lPGh0dHBzOi8v bW96cGhhYi1pZXRmLmRldnN2Y2Rldi5tb3phd3MubmV0L0Q0Mjc4I2lubGluZS0xNTg4PmRyYWZ0 LWlldGYtb2F1dGgtdG9rZW4tZXhjaGFuZ2UudHh0OjY4OQ0KcmVzcG9uc2UsICJhY3QiIGhhcyB0 aGUgc2FtZSBzZW1hbnRpY3MgYW5kIGZvcm1hdCBhcyB0aGUgY2xhaW0gb2YgdGhlDQpzYW1lIG5h bWUuDQoNCkl0J3Mgbm90IGVudGlyZWx5IGNsZWFyIHRvIG1lIGhvdyBJJ20gc3VwcG9zZWQgdG8g ZXZhbHVhdGUgdGhlc2UgZnJvbSBhbiBhY2Nlc3MgY29udHJvbCBwZXJzcGVjdGl2ZS4NCg0KSXMg dGhlIGFzc3VtcHRpb24gaGVyZSB0aGF0IHRoZSBlbnRpdHkgcHJvZHVjaW5nIHRoZSBKV1QgaGFz IGVuc3VyZWQgdGhlIGNvcnJlY3QgY2hhaW4gb2YgaXNzdWVycyBhbmQgc3Vicz8NCg0KSXMgaXQg dGhlIFJQJ3Mgam9iIHRvIGV2YWx1YXRlIHdoZXRoZXIgZWFjaCBlbnRpdHkgaW4gdGhlIGNoYWlu IGNvdWxkIGhhdmUgcGVyZm9ybWVkIHRoZSBhY3Rpb24/DQoNClZpZXcgSW5saW5lPGh0dHBzOi8v bW96cGhhYi1pZXRmLmRldnN2Y2Rldi5tb3phd3MubmV0L0Q0Mjc4I2lubGluZS0xNTg5PmRyYWZ0 LWlldGYtb2F1dGgtdG9rZW4tZXhjaGFuZ2UudHh0Ojc1NQ0KY2xhaW1zIHN1Y2ggYXMgImV4cCIs ICJuYmYiLCBhbmQgImF1ZCIgYXJlIG5vdCBtZWFuaW5nZnVsIHdoZW4gdXNlZA0Kd2l0aGluIGEg Im1heV9hY3QiIGNsYWltLCBhbmQgdGhlcmVmb3JlIHNob3VsZCBub3QgYmUgdXNlZC4NCg0KSSdt IGhhdmluZyBhIGhhcmQgdGltZSB1bmRlcnN0YW5kaW5nIHRoaXMgY2xhaW0uIENhbiB5b3UgcHJv dmlkZSBhbiBleGFtcGxlIHRvIG1lIChpbiBlbWFpbCBpcyBmaW5lLCBpdCBkb2Vzbid0IG5lZWQg dG8gYmUgaW4gdGhlIGRyYWZ0KSBvZiBob3cgaXQgd291bGQgYmUgdXNlZD8NCg0KVmlldyBJbmxp bmU8aHR0cHM6Ly9tb3pwaGFiLWlldGYuZGV2c3ZjZGV2Lm1vemF3cy5uZXQvRDQyNzgjaW5saW5l LTE1OTA+ZHJhZnQtaWV0Zi1vYXV0aC10b2tlbi1leGNoYW5nZS50eHQ6MTI3Mw0KcHJvZHVjZWQg dW5kZXIgdGhlIGNoYWlybWFuc2hpcCBvZiBIYW5uZXMgVHNjaG9mZW5pZyBhbmQgRGVyZWsgQXRr aW5zDQp3aXRoIEthdGhsZWVuIE1vcmlhcnR5IGFuZCBTdGVwaGVuIEZhcnJlbGwgc2VydmluZyBh cyBTZWN1cml0eSBBcmVhDQpEaXJlY3RvcnMuIFRoZSBmb2xsb3dpbmcgaW5kaXZpZHVhbHMgY29u dHJpYnV0ZWQgaWRlYXMsIGZlZWRiYWNrLA0KDQpZb3UgbWF5IHdhbnQgdG8gdXBkYXRlIHRoaXMN Cg0KUkVQT1NJVE9SWQ0KcklFVEZSRVZJRVcgaWV0Zi1yZXZpZXcNCg0KUkVWSVNJT04gREVUQUlM DQpodHRwczovL21venBoYWItaWV0Zi5kZXZzdmNkZXYubW96YXdzLm5ldC9ENDI3OA0KDQpFTUFJ TCBQUkVGRVJFTkNFUw0KaHR0cHM6Ly9tb3pwaGFiLWlldGYuZGV2c3ZjZGV2Lm1vemF3cy5uZXQv c2V0dGluZ3MvcGFuZWwvZW1haWxwcmVmZXJlbmNlcy8NCg0KVG86IGVrci1tb3osIGVrcg0KQ2M6 IGVrcg0KDQo= --_000_CY4PR21MB05046590C8F5889AB1AAA3C7F5050CY4PR21MB0504namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNvbm9y bWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNv bm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJ bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6 ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFp bFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzAwMjA2MDt9DQouTXNvQ2hwRGVmYXVsdA0K CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFy Z2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpX b3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRp Zl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0 Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0Pjwv eG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5UaGFua3MgZm9yIHRoZSB1c2Vm dWwgcmV2aWV3LCBFcmljLiZuYnNwOyBJ4oCZbGwgd29yayB3aXRoIEJyaWFuIGFuZCB0aGUgY3Jl dyB0byBpbmNvcnBvcmF0ZSB0aGlzIGZlZWRiYWNrLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6IzAwMjA2MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1p a2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IE9BdXRoIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRm Lm9yZ10gPGI+T24gQmVoYWxmIE9mDQo8L2I+RXJpYyBSZXNjb3JsYTxicj4NCjxiPlNlbnQ6PC9i PiBGcmlkYXksIERlY2VtYmVyIDI5LCAyMDE3IDg6NDEgQU08YnI+DQo8Yj5Ubzo8L2I+IG9hdXRo QGlldGYub3JnOyBkcmFmdC1pZXRmLW9hdXRoLXRva2VuLWV4Y2hhbmdlQHRvb2xzLmlldGYub3Jn PGJyPg0KPGI+U3ViamVjdDo8L2I+IFtPQVVUSC1XR10gQUQgUmV2aWV3OiBkcmFmdC1pZXRmLW9h dXRoLXRva2VuLWV4Y2hhbmdlLTA5PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+RnVsbC1mZWF0dXJlZCByZXZpZXcgYXQ6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRwczovL21venBoYWItaWV0Zi5kZXZz dmNkZXYubW96YXdzLm5ldC9ENDI3OCI+aHR0cHM6Ly9tb3pwaGFiLWlldGYuZGV2c3ZjZGV2Lm1v emF3cy5uZXQvRDQyNzg8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHA+QXMg bm90ZWQgaW4gaW5saW5lIGNvbW1lbnRzLCBzb21lIGFkZGl0aW9uYWwgd29yZHMgYWJvdXQgdGhl IHNlY3VyaXR5IG1vZGVsIGluIHdoaWNoIHRoaXMgZG9jdW1lbnQgaXMgZW1iZWRkZWQgc2VlbSBs aWtlIHRoZXkgYXJlIG5lZWRlZC4gSW4gcGFydGljdWxhciwgaXQncyBwcmV0dHkgdW5jbGVhciB0 byBtZSB3aGF0IGNoZWNrcyB0aGUgU1RTIGlzIHN1cHBvc2VkIHRvIGRvIG9uIGEgZ2l2ZW4gcmVx dWVzdCB0byBkZXRlcm1pbmUgd2hldGhlcg0KIHRvIGZ1bGZpbGwgaXQuIFdoZXJlIGlzIHRoYXQg ZG9jdW1lbnRlZD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPklOTElORSBDT01NRU5UUzwvc3Bhbj48L3N0cm9uZz48bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tdG9wOjQuNXB0O21hcmdpbi1ib3R0b206OS4wcHQi Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOnNvbGlkICNDN0NDRDkgMS4wcHQ7cGFkZGluZzowaW4gMGlu IDBpbiAwaW47Ym9yZGVyLXJhZGl1czozcHgiPg0KPGRpdiBzdHlsZT0iYm9yZGVyOnNvbGlkICNF M0U0RTggMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiAwaW4iPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOiNFRkYyRjQiPjxzcGFuIHN0eWxlPSJjb2xvcjoj NzQ3NzdEIj48YSBocmVmPSJodHRwczovL21venBoYWItaWV0Zi5kZXZzdmNkZXYubW96YXdzLm5l dC9ENDI3OCNpbmxpbmUtMTU4MCIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJ0ZXh0LWRl Y29yYXRpb246bm9uZSI+VmlldyBJbmxpbmU8L3NwYW4+PC9hPjwvc3Bhbj48Yj48c3BhbiBzdHls ZT0iY29sb3I6IzRCNEQ1MSI+ZHJhZnQtaWV0Zi1vYXV0aC10b2tlbi1leGNoYW5nZS50eHQ6MTI5 PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iY29sb3I6Izc0Nzc3RCI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6My4wcHQ7bWFyZ2lu LXJpZ2h0OjMuMHB0O2JhY2tncm91bmQ6cmdiYSgxNTIsMjA3LDIzNSwwLjM1KSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTEuMjVwdDtiYWNrZ3JvdW5kOiNGN0Y3 RjciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXMiPnNl Y3VyaW5nIGFjY2VzcyB0byBIVFRQIGFuZCBSRVNUZnVsIHJlc291cmNlcyBidXQgZG8gbm90IHBy b3ZpZGUNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2lu LWxlZnQ6My4wcHQ7bWFyZ2luLXJpZ2h0OjMuMHB0O2JhY2tncm91bmQ6cmdiYSgxNTIsMjA3LDIz NSwwLjM1KSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTEuMjVw dDtiYWNrZ3JvdW5kOiNGN0Y3RjciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC41cHQ7Zm9udC1m YW1pbHk6Q29uc29sYXMiPmV2ZXJ5dGhpbmcgbmVjZXNzYXJ5IHRvIGZhY2lsaXRhdGUgdG9rZW4g ZXhjaGFuZ2UgaW50ZXJhY3Rpb25zLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLXRvcDo2LjBwdDttYXJnaW4tYm90dG9t OjYuMHB0Ij4NCjxwIHN0eWxlPSJtYXJnaW46Ni4wcHQiPkNhbiB5b3Ugc2F5IGEgYml0IG1vcmUg YWJvdXQgd2hhdCBpcyBtaXNzaW5nIGhlcmU/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxl PSJib3JkZXI6c29saWQgI0M3Q0NEOSAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDBpbjtib3Jk ZXItcmFkaXVzOjNweCI+DQo8ZGl2IHN0eWxlPSJib3JkZXI6c29saWQgI0UzRTRFOCAxLjBwdDtw YWRkaW5nOjBpbiAwaW4gMGluIDBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9ImJhY2tncm91bmQ6I0VGRjJGNCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM3NDc3N0QiPjxhIGhy ZWY9Imh0dHBzOi8vbW96cGhhYi1pZXRmLmRldnN2Y2Rldi5tb3phd3MubmV0L0Q0Mjc4I2lubGlu ZS0xNTgxIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9InRleHQtZGVjb3JhdGlvbjpub25l Ij5WaWV3IElubGluZTwvc3Bhbj48L2E+PC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJjb2xvcjojNEI0 RDUxIj5kcmFmdC1pZXRmLW9hdXRoLXRva2VuLWV4Y2hhbmdlLnR4dDoyNjU8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSJjb2xvcjojNzQ3NzdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDozLjBwdDttYXJnaW4tcmlnaHQ6My4wcHQ7 YmFja2dyb3VuZDpyZ2JhKDE1MiwyMDcsMjM1LDAuMzUpIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJsaW5lLWhlaWdodDoxMS4yNXB0O2JhY2tncm91bmQ6I0Y3RjdGNyI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseTpDb25zb2xhcyI+UkVRVUlSRUQuIFRoZSB2 YWx1ZSAmcXVvdDt1cm46aWV0ZjpwYXJhbXM6b2F1dGg6Z3JhbnQtdHlwZTp0b2tlbi0NCjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6My4wcHQ7 bWFyZ2luLXJpZ2h0OjMuMHB0O2JhY2tncm91bmQ6cmdiYSgxNTIsMjA3LDIzNSwwLjM1KSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTEuMjVwdDtiYWNrZ3JvdW5k OiNGN0Y3RjciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6Q29uc29s YXMiPmV4Y2hhbmdlJnF1b3Q7IGluZGljYXRlcyB0aGF0IGEgdG9rZW4gZXhjaGFuZ2UgaXMgYmVp bmcgcGVyZm9ybWVkLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLXRvcDo2LjBwdDttYXJnaW4tYm90dG9tOjYuMHB0Ij4N CjxwIHN0eWxlPSJtYXJnaW46Ni4wcHQiPkkgbm90ZSB0aGF0IFMgNC41LiBzYXlzIHRoYXQgdGhl IGdyYW50X3R5cGUgaXMgJnF1b3Q7ZGVmaW5lZCBieSB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIm cXVvdDsgYnV0IHRoYXQncyBub3QgdGhlIGNhc2UgaGVyZSwgcmlnaHQ/PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6c29saWQgI0M3Q0NEOSAxLjBwdDtwYWRkaW5nOjBpbiAw aW4gMGluIDBpbjtib3JkZXItcmFkaXVzOjNweCI+DQo8ZGl2IHN0eWxlPSJib3JkZXI6c29saWQg I0UzRTRFOCAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6I0VGRjJGNCI+PHNwYW4gc3R5bGU9ImNvbG9y OiM3NDc3N0QiPjxhIGhyZWY9Imh0dHBzOi8vbW96cGhhYi1pZXRmLmRldnN2Y2Rldi5tb3phd3Mu bmV0L0Q0Mjc4I2lubGluZS0xNTgyIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9InRleHQt ZGVjb3JhdGlvbjpub25lIj5WaWV3IElubGluZTwvc3Bhbj48L2E+PC9zcGFuPjxiPjxzcGFuIHN0 eWxlPSJjb2xvcjojNEI0RDUxIj5kcmFmdC1pZXRmLW9hdXRoLXRva2VuLWV4Y2hhbmdlLnR4dDoy Njg8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJjb2xvcjojNzQ3NzdEIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDozLjBwdDttYXJn aW4tcmlnaHQ6My4wcHQ7YmFja2dyb3VuZDpyZ2JhKDE1MiwyMDcsMjM1LDAuMzUpIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxMS4yNXB0O2JhY2tncm91bmQ6I0Y3 RjdGNyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseTpDb25zb2xhcyI+ cmVzb3VyY2UNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFy Z2luLWxlZnQ6My4wcHQ7bWFyZ2luLXJpZ2h0OjMuMHB0O2JhY2tncm91bmQ6cmdiYSgxNTIsMjA3 LDIzNSwwLjM1KSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTEu MjVwdDtiYWNrZ3JvdW5kOiNGN0Y3RjciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC41cHQ7Zm9u dC1mYW1pbHk6Q29uc29sYXMiPk9QVElPTkFMLiBJbmRpY2F0ZXMgdGhlIHBoeXNpY2FsIGxvY2F0 aW9uIG9mIHRoZSB0YXJnZXQgc2VydmljZQ0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDozLjBwdDttYXJnaW4tcmlnaHQ6My4wcHQ7YmFja2dy b3VuZDpyZ2JhKDE1MiwyMDcsMjM1LDAuMzUpIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJsaW5lLWhlaWdodDoxMS4yNXB0O2JhY2tncm91bmQ6I0Y3RjdGNyI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseTpDb25zb2xhcyI+b3IgcmVzb3VyY2Ugd2hlcmUgdGhl IGNsaWVudCBpbnRlbmRzIHRvIHVzZSB0aGUgcmVxdWVzdGVkIHNlY3VyaXR5DQo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4t dG9wOjYuMHB0O21hcmdpbi1ib3R0b206Ni4wcHQiPg0KPHAgc3R5bGU9Im1hcmdpbjo2LjBwdCI+ RG8geW91IGFjdHVhbGx5IG1lYW4gJnF1b3Q7cGh5c2ljYWwmcXVvdDsgaGVyZT8gUHJlc3VtYWJs eSBpZiBpdCdzIGEgVVJJIGl0J3MgbW9zdCBsaWtlbHkgYSBuZXR3b3JrIGFkZHJlc3MuIEkgd291 bGQgdGFrZSAmcXVvdDtwaHlzaWNhbCZxdW90OyB0byBtZWFuICZxdW90O2dlb2dyYXBoaWMmcXVv dDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpzb2xpZCAjQzdDQ0Q5IDEu MHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gMGluO2JvcmRlci1yYWRpdXM6M3B4Ij4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpzb2xpZCAjRTNFNEU4IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gMGluIj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDojRUZGMkY0Ij48 c3BhbiBzdHlsZT0iY29sb3I6Izc0Nzc3RCI+PGEgaHJlZj0iaHR0cHM6Ly9tb3pwaGFiLWlldGYu ZGV2c3ZjZGV2Lm1vemF3cy5uZXQvRDQyNzgjaW5saW5lLTE1ODMiIHRhcmdldD0iX2JsYW5rIj48 c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOm5vbmUiPlZpZXcgSW5saW5lPC9zcGFuPjwvYT48 L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOiM0QjRENTEiPmRyYWZ0LWlldGYtb2F1dGgtdG9r ZW4tZXhjaGFuZ2UudHh0OjMwNDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImNvbG9yOiM3NDc3N0Qi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdp bi1sZWZ0OjMuMHB0O21hcmdpbi1yaWdodDozLjBwdDtiYWNrZ3JvdW5kOnJnYmEoMTUyLDIwNywy MzUsMC4zNSkiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjExLjI1 cHQ7YmFja2dyb3VuZDojRjdGN0Y3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguNXB0O2ZvbnQt ZmFtaWx5OkNvbnNvbGFzIj50YXJnZXQgc2VydmljZXMgd2l0aCBhIG1peCBvZiBsb2dpY2FsIG5h bWVzIGFuZCBwaHlzaWNhbA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0 eWxlPSJtYXJnaW4tbGVmdDozLjBwdDttYXJnaW4tcmlnaHQ6My4wcHQ7YmFja2dyb3VuZDpyZ2Jh KDE1MiwyMDcsMjM1LDAuMzUpIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhl aWdodDoxMS4yNXB0O2JhY2tncm91bmQ6I0Y3RjdGNyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4 LjVwdDtmb250LWZhbWlseTpDb25zb2xhcyI+bG9jYXRpb25zLg0KPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLXRvcDo2LjBw dDttYXJnaW4tYm90dG9tOjYuMHB0Ij4NCjxwIHN0eWxlPSJtYXJnaW46Ni4wcHQiPkJ1dCBpdCBz ZWVtcyB5b3UgY2FuIG9ubHkgc3BlY2lmeSBvbmUgb2YgZWFjaCwgcmlnaHQ/PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6c29saWQgI0M3Q0NEOSAxLjBwdDtwYWRkaW5nOjBp biAwaW4gMGluIDBpbjtib3JkZXItcmFkaXVzOjNweCI+DQo8ZGl2IHN0eWxlPSJib3JkZXI6c29s aWQgI0UzRTRFOCAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDBpbiI+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6I0VGRjJGNCI+PHNwYW4gc3R5bGU9ImNv bG9yOiM3NDc3N0QiPjxhIGhyZWY9Imh0dHBzOi8vbW96cGhhYi1pZXRmLmRldnN2Y2Rldi5tb3ph d3MubmV0L0Q0Mjc4I2lubGluZS0xNTg0IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9InRl eHQtZGVjb3JhdGlvbjpub25lIj5WaWV3IElubGluZTwvc3Bhbj48L2E+PC9zcGFuPjxiPjxzcGFu IHN0eWxlPSJjb2xvcjojNEI0RDUxIj5kcmFmdC1pZXRmLW9hdXRoLXRva2VuLWV4Y2hhbmdlLnR4 dDozMTA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJjb2xvcjojNzQ3NzdEIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDozLjBwdDtt YXJnaW4tcmlnaHQ6My4wcHQ7YmFja2dyb3VuZDpyZ2JhKDE1MiwyMDcsMjM1LDAuMzUpIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxMS4yNXB0O2JhY2tncm91bmQ6 I0Y3RjdGNyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseTpDb25zb2xh cyI+c2VjdXJpdHkgdG9rZW4gaW4gdGhlIGNvbnRleHQgb2YgdGhlIHNlcnZpY2Ugb3IgcmVzb3Vy Y2Ugd2hlcmUgdGhlDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9 Im1hcmdpbi1sZWZ0OjMuMHB0O21hcmdpbi1yaWdodDozLjBwdDtiYWNrZ3JvdW5kOnJnYmEoMTUy LDIwNywyMzUsMC4zNSkiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0 OjExLjI1cHQ7YmFja2dyb3VuZDojRjdGN0Y3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguNXB0 O2ZvbnQtZmFtaWx5OkNvbnNvbGFzIj50b2tlbiB3aWxsIGJlIHVzZWQuDQo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tdG9w OjYuMHB0O21hcmdpbi1ib3R0b206Ni4wcHQiPg0KPHAgc3R5bGU9Im1hcmdpbjo2LjBwdCI+SXQn cyBub3QgY2xlYXIgdG8gbWUgd2hlcmUgdGhlc2UgdmFsdWVzIHdvdWxkIGNvbWUgZnJvbS4gQ2Fu IHlvdSBleHBhbmQgb24gdGhpcz88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRl cjpzb2xpZCAjQzdDQ0Q5IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gMGluO2JvcmRlci1yYWRp dXM6M3B4Ij4NCjxkaXYgc3R5bGU9ImJvcmRlcjpzb2xpZCAjRTNFNEU4IDEuMHB0O3BhZGRpbmc6 MGluIDBpbiAwaW4gMGluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFj a2dyb3VuZDojRUZGMkY0Ij48c3BhbiBzdHlsZT0iY29sb3I6Izc0Nzc3RCI+PGEgaHJlZj0iaHR0 cHM6Ly9tb3pwaGFiLWlldGYuZGV2c3ZjZGV2Lm1vemF3cy5uZXQvRDQyNzgjaW5saW5lLTE1ODUi IHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOm5vbmUiPlZpZXcg SW5saW5lPC9zcGFuPjwvYT48L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOiM0QjRENTEiPmRy YWZ0LWlldGYtb2F1dGgtdG9rZW4tZXhjaGFuZ2UudHh0OjM0MTwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImNvbG9yOiM3NDc3N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0OjMuMHB0O21hcmdpbi1yaWdodDozLjBwdDtiYWNrZ3Jv dW5kOnJnYmEoMTUyLDIwNywyMzUsMC4zNSkiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImxpbmUtaGVpZ2h0OjExLjI1cHQ7YmFja2dyb3VuZDojRjdGN0Y3Ij48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzIj5SRVFVSVJFRCB3aGVuIHRoZSAmcXVv dDthY3Rvcl90b2tlbiZxdW90OyBwYXJhbWV0ZXIgaXMgcHJlc2VudCBpbiB0aGUNCjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6My4wcHQ7bWFy Z2luLXJpZ2h0OjMuMHB0O2JhY2tncm91bmQ6cmdiYSgxNTIsMjA3LDIzNSwwLjM1KSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTEuMjVwdDtiYWNrZ3JvdW5kOiNG N0Y3RjciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXMi PnJlcXVlc3QgYnV0IE1VU1QgTk9UIGJlIGluY2x1ZGVkIG90aGVyd2lzZS4NCjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi10 b3A6Ni4wcHQ7bWFyZ2luLWJvdHRvbTo2LjBwdCI+DQo8cCBzdHlsZT0ibWFyZ2luOjYuMHB0Ij5J dCdzIG5vdCBlbnRpcmVseSBjbGVhciB0byBtZSBmcm9tIHRoaXMgdGV4dCBob3cgdGhlc2UgdG9r ZW5zIGF1dGhlbnRpY2F0ZSB0aGUgcmVxdWVzdC4gSXQncyBjbGVhciBpZiB0aGV5IGFyZSBiZWFy ZXIgdG9rZW5zLCBidXQgaWYgdGhleSBhcmUgc29tZSBzb3J0IG9mIHRva2VuIG92ZXIgYSBwdWJs aWMga2V5LCB0aGVuIGhvdyBkb2VzIHRoYXQgd29yay48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYg c3R5bGU9ImJvcmRlcjpzb2xpZCAjQzdDQ0Q5IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gMGlu O2JvcmRlci1yYWRpdXM6M3B4Ij4NCjxkaXYgc3R5bGU9ImJvcmRlcjpzb2xpZCAjRTNFNEU4IDEu MHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gMGluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iYmFja2dyb3VuZDojRUZGMkY0Ij48c3BhbiBzdHlsZT0iY29sb3I6Izc0Nzc3RCI+ PGEgaHJlZj0iaHR0cHM6Ly9tb3pwaGFiLWlldGYuZGV2c3ZjZGV2Lm1vemF3cy5uZXQvRDQyNzgj aW5saW5lLTE1ODYiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0aW9u Om5vbmUiPlZpZXcgSW5saW5lPC9zcGFuPjwvYT48L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImNvbG9y OiM0QjRENTEiPmRyYWZ0LWlldGYtb2F1dGgtdG9rZW4tZXhjaGFuZ2UudHh0OjU4Nzwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImNvbG9yOiM3NDc3N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0OjMuMHB0O21hcmdpbi1yaWdodDoz LjBwdDtiYWNrZ3JvdW5kOnJnYmEoMTUyLDIwNywyMzUsMC4zNSkiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjExLjI1cHQ7YmFja2dyb3VuZDojRjdGN0Y3Ij48c3Bh biBzdHlsZT0iZm9udC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzIj4yLjAgW09BU0lT LnNhbWwtY29yZS0yLjAtb3NdIGFzc2VydGlvbiwgcmVzcGVjdGl2ZWx5LiBPdGhlciBVUklzIHRv DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0 OjMuMHB0O21hcmdpbi1yaWdodDozLjBwdDtiYWNrZ3JvdW5kOnJnYmEoMTUyLDIwNywyMzUsMC4z NSkiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjExLjI1cHQ7YmFj a2dyb3VuZDojRjdGN0Y3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5 OkNvbnNvbGFzIj5pbmRpY2F0ZSBvdGhlciB0b2tlbiB0eXBlcyBNQVkgYmUgdXNlZC4NCjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1h cmdpbi10b3A6Ni4wcHQ7bWFyZ2luLWJvdHRvbTo2LjBwdCI+DQo8cCBzdHlsZT0ibWFyZ2luOjYu MHB0Ij5UaGlzIGZlZWxzIGxpa2UgaXQgd291bGQgYmUgYmV0dGVyIGFzIHNvbWUga2luZCBvZiBs aXN0IChtYXliZSBidWxsZXRlZCk/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6c29saWQgI0M3Q0NEOSAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDBpbjtib3JkZXItcmFk aXVzOjNweCI+DQo8ZGl2IHN0eWxlPSJib3JkZXI6c29saWQgI0UzRTRFOCAxLjBwdDtwYWRkaW5n OjBpbiAwaW4gMGluIDBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJh Y2tncm91bmQ6I0VGRjJGNCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM3NDc3N0QiPjxhIGhyZWY9Imh0 dHBzOi8vbW96cGhhYi1pZXRmLmRldnN2Y2Rldi5tb3phd3MubmV0L0Q0Mjc4I2lubGluZS0xNTg3 IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9InRleHQtZGVjb3JhdGlvbjpub25lIj5WaWV3 IElubGluZTwvc3Bhbj48L2E+PC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJjb2xvcjojNEI0RDUxIj5k cmFmdC1pZXRmLW9hdXRoLXRva2VuLWV4Y2hhbmdlLnR4dDo2NjY8L3NwYW4+PC9iPjxzcGFuIHN0 eWxlPSJjb2xvcjojNzQ3NzdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDozLjBwdDttYXJnaW4tcmlnaHQ6My4wcHQ7YmFja2dy b3VuZDpyZ2JhKDE1MiwyMDcsMjM1LDAuMzUpIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJsaW5lLWhlaWdodDoxMS4yNXB0O2JhY2tncm91bmQ6I0Y3RjdGNyI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseTpDb25zb2xhcyI+aXQgYXMgdGhlIGN1cnJlbnQgYWN0 b3IgYW5kIHRoYXQgY2FuIGJlIHVzZWQgYXQNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6My4wcHQ7bWFyZ2luLXJpZ2h0OjMuMHB0O2JhY2tn cm91bmQ6cmdiYSgxNTIsMjA3LDIzNSwwLjM1KSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibGluZS1oZWlnaHQ6MTEuMjVwdDtiYWNrZ3JvdW5kOiNGN0Y3RjciPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXMiPjxhIGhyZWY9Imh0dHBzOi8vYmFj a2VuZC5leGFtcGxlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vYmFja2VuZC5leGFtcGxl LmNvbTwvYT4uDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2IHN0eWxlPSJtYXJnaW4tdG9wOjYuMHB0O21hcmdpbi1ib3R0b206Ni4wcHQiPg0KPHAg c3R5bGU9Im1hcmdpbjo2LjBwdCI+V2hlcmUgY2FuIEkgZmluZCB0aGUgZGVmaW5pdGlvbnMgb2Yg JnF1b3Q7aXNzJnF1b3Q7IGFuZCAmcXVvdDtzdWImcXVvdDs/PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6c29saWQgI0M3Q0NEOSAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGlu IDBpbjtib3JkZXItcmFkaXVzOjNweCI+DQo8ZGl2IHN0eWxlPSJib3JkZXI6c29saWQgI0UzRTRF OCAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6I0VGRjJGNCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM3NDc3 N0QiPjxhIGhyZWY9Imh0dHBzOi8vbW96cGhhYi1pZXRmLmRldnN2Y2Rldi5tb3phd3MubmV0L0Q0 Mjc4I2lubGluZS0xNTg4IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9InRleHQtZGVjb3Jh dGlvbjpub25lIj5WaWV3IElubGluZTwvc3Bhbj48L2E+PC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJj b2xvcjojNEI0RDUxIj5kcmFmdC1pZXRmLW9hdXRoLXRva2VuLWV4Y2hhbmdlLnR4dDo2ODk8L3Nw YW4+PC9iPjxzcGFuIHN0eWxlPSJjb2xvcjojNzQ3NzdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDozLjBwdDttYXJnaW4tcmln aHQ6My4wcHQ7YmFja2dyb3VuZDpyZ2JhKDE1MiwyMDcsMjM1LDAuMzUpIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxMS4yNXB0O2JhY2tncm91bmQ6I0Y3RjdGNyI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseTpDb25zb2xhcyI+cmVzcG9u c2UsICZxdW90O2FjdCZxdW90OyBoYXMgdGhlIHNhbWUgc2VtYW50aWNzIGFuZCBmb3JtYXQgYXMg dGhlIGNsYWltIG9mIHRoZQ0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0 eWxlPSJtYXJnaW4tbGVmdDozLjBwdDttYXJnaW4tcmlnaHQ6My4wcHQ7YmFja2dyb3VuZDpyZ2Jh KDE1MiwyMDcsMjM1LDAuMzUpIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhl aWdodDoxMS4yNXB0O2JhY2tncm91bmQ6I0Y3RjdGNyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4 LjVwdDtmb250LWZhbWlseTpDb25zb2xhcyI+c2FtZSBuYW1lLg0KPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLXRvcDo2LjBw dDttYXJnaW4tYm90dG9tOjYuMHB0Ij4NCjxwIHN0eWxlPSJtYXJnaW46Ni4wcHQiPkl0J3Mgbm90 IGVudGlyZWx5IGNsZWFyIHRvIG1lIGhvdyBJJ20gc3VwcG9zZWQgdG8gZXZhbHVhdGUgdGhlc2Ug ZnJvbSBhbiBhY2Nlc3MgY29udHJvbCBwZXJzcGVjdGl2ZS48bzpwPjwvbzpwPjwvcD4NCjxwIHN0 eWxlPSJtYXJnaW46Ni4wcHQiPklzIHRoZSBhc3N1bXB0aW9uIGhlcmUgdGhhdCB0aGUgZW50aXR5 IHByb2R1Y2luZyB0aGUgSldUIGhhcyBlbnN1cmVkIHRoZSBjb3JyZWN0IGNoYWluIG9mIGlzc3Vl cnMgYW5kIHN1YnM/PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjYuMHB0Ij5JcyBp dCB0aGUgUlAncyBqb2IgdG8gZXZhbHVhdGUgd2hldGhlciBlYWNoIGVudGl0eSBpbiB0aGUgY2hh aW4gY291bGQgaGF2ZSBwZXJmb3JtZWQgdGhlIGFjdGlvbj88bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXYgc3R5bGU9ImJvcmRlcjpzb2xpZCAjQzdDQ0Q5IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4g MGluO2JvcmRlci1yYWRpdXM6M3B4Ij4NCjxkaXYgc3R5bGU9ImJvcmRlcjpzb2xpZCAjRTNFNEU4 IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gMGluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0iYmFja2dyb3VuZDojRUZGMkY0Ij48c3BhbiBzdHlsZT0iY29sb3I6Izc0Nzc3 RCI+PGEgaHJlZj0iaHR0cHM6Ly9tb3pwaGFiLWlldGYuZGV2c3ZjZGV2Lm1vemF3cy5uZXQvRDQy NzgjaW5saW5lLTE1ODkiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0 aW9uOm5vbmUiPlZpZXcgSW5saW5lPC9zcGFuPjwvYT48L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImNv bG9yOiM0QjRENTEiPmRyYWZ0LWlldGYtb2F1dGgtdG9rZW4tZXhjaGFuZ2UudHh0Ojc1NTwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9ImNvbG9yOiM3NDc3N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0OjMuMHB0O21hcmdpbi1yaWdo dDozLjBwdDtiYWNrZ3JvdW5kOnJnYmEoMTUyLDIwNywyMzUsMC4zNSkiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjExLjI1cHQ7YmFja2dyb3VuZDojRjdGN0Y3Ij48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzIj5jbGFpbXMg c3VjaCBhcyAmcXVvdDtleHAmcXVvdDssICZxdW90O25iZiZxdW90OywgYW5kICZxdW90O2F1ZCZx dW90OyBhcmUgbm90IG1lYW5pbmdmdWwgd2hlbiB1c2VkDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0OjMuMHB0O21hcmdpbi1yaWdodDozLjBw dDtiYWNrZ3JvdW5kOnJnYmEoMTUyLDIwNywyMzUsMC4zNSkiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjExLjI1cHQ7YmFja2dyb3VuZDojRjdGN0Y3Ij48c3BhbiBz dHlsZT0iZm9udC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzIj53aXRoaW4gYSAmcXVv dDttYXlfYWN0JnF1b3Q7IGNsYWltLCBhbmQgdGhlcmVmb3JlIHNob3VsZCBub3QgYmUgdXNlZC4N CjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5 bGU9Im1hcmdpbi10b3A6Ni4wcHQ7bWFyZ2luLWJvdHRvbTo2LjBwdCI+DQo8cCBzdHlsZT0ibWFy Z2luOjYuMHB0Ij5JJ20gaGF2aW5nIGEgaGFyZCB0aW1lIHVuZGVyc3RhbmRpbmcgdGhpcyBjbGFp bS4gQ2FuIHlvdSBwcm92aWRlIGFuIGV4YW1wbGUgdG8gbWUgKGluIGVtYWlsIGlzIGZpbmUsIGl0 IGRvZXNuJ3QgbmVlZCB0byBiZSBpbiB0aGUgZHJhZnQpIG9mIGhvdyBpdCB3b3VsZCBiZSB1c2Vk PzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOnNvbGlkICNDN0NDRDkgMS4w cHQ7cGFkZGluZzowaW4gMGluIDBpbiAwaW47Ym9yZGVyLXJhZGl1czozcHgiPg0KPGRpdiBzdHls ZT0iYm9yZGVyOnNvbGlkICNFM0U0RTggMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiAwaW4iPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOiNFRkYyRjQiPjxz cGFuIHN0eWxlPSJjb2xvcjojNzQ3NzdEIj48YSBocmVmPSJodHRwczovL21venBoYWItaWV0Zi5k ZXZzdmNkZXYubW96YXdzLm5ldC9ENDI3OCNpbmxpbmUtMTU5MCIgdGFyZ2V0PSJfYmxhbmsiPjxz cGFuIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246bm9uZSI+VmlldyBJbmxpbmU8L3NwYW4+PC9hPjwv c3Bhbj48Yj48c3BhbiBzdHlsZT0iY29sb3I6IzRCNEQ1MSI+ZHJhZnQtaWV0Zi1vYXV0aC10b2tl bi1leGNoYW5nZS50eHQ6MTI3Mzwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImNvbG9yOiM3NDc3N0Qi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdp bi1sZWZ0OjMuMHB0O21hcmdpbi1yaWdodDozLjBwdDtiYWNrZ3JvdW5kOnJnYmEoMTUyLDIwNywy MzUsMC4zNSkiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjExLjI1 cHQ7YmFja2dyb3VuZDojRjdGN0Y3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguNXB0O2ZvbnQt ZmFtaWx5OkNvbnNvbGFzIj5wcm9kdWNlZCB1bmRlciB0aGUgY2hhaXJtYW5zaGlwIG9mIEhhbm5l cyBUc2Nob2ZlbmlnIGFuZCBEZXJlayBBdGtpbnMNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6My4wcHQ7bWFyZ2luLXJpZ2h0OjMuMHB0O2Jh Y2tncm91bmQ6cmdiYSgxNTIsMjA3LDIzNSwwLjM1KSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibGluZS1oZWlnaHQ6MTEuMjVwdDtiYWNrZ3JvdW5kOiNGN0Y3RjciPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXMiPndpdGggS2F0aGxlZW4gTW9y aWFydHkgYW5kIFN0ZXBoZW4gRmFycmVsbCBzZXJ2aW5nIGFzIFNlY3VyaXR5IEFyZWENCjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6My4wcHQ7 bWFyZ2luLXJpZ2h0OjMuMHB0O2JhY2tncm91bmQ6cmdiYSgxNTIsMjA3LDIzNSwwLjM1KSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTEuMjVwdDtiYWNrZ3JvdW5k OiNGN0Y3RjciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6Q29uc29s YXMiPkRpcmVjdG9ycy4gVGhlIGZvbGxvd2luZyBpbmRpdmlkdWFscyBjb250cmlidXRlZCBpZGVh cywgZmVlZGJhY2ssDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tdG9wOjYuMHB0O21hcmdpbi1ib3R0b206Ni4wcHQiPg0K PHAgc3R5bGU9Im1hcmdpbjo2LjBwdCI+WW91IG1heSB3YW50IHRvIHVwZGF0ZSB0aGlzPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHN0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj5SRVBPU0lUT1JZPC9zcGFuPjwvc3Ryb25nPjxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ySUVURlJFVklFVyBpZXRmLXJl dmlldzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHN0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj5SRVZJU0lPTiBERVRBSUw8L3NwYW4+PC9zdHJvbmc+PG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly9tb3pwaGFiLWll dGYuZGV2c3ZjZGV2Lm1vemF3cy5uZXQvRDQyNzgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL21v enBoYWItaWV0Zi5kZXZzdmNkZXYubW96YXdzLm5ldC9ENDI3ODwvYT48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkVNQUlMIFBSRUZFUkVOQ0VT PC9zcGFuPjwvc3Ryb25nPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxhIGhyZWY9Imh0dHBzOi8vbW96cGhhYi1pZXRmLmRldnN2Y2Rldi5tb3phd3MubmV0L3Nl dHRpbmdzL3BhbmVsL2VtYWlscHJlZmVyZW5jZXMvIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9t b3pwaGFiLWlldGYuZGV2c3ZjZGV2Lm1vemF3cy5uZXQvc2V0dGluZ3MvcGFuZWwvZW1haWxwcmVm ZXJlbmNlcy88L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHN0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj5UbzogPC9zcGFuPg0KPC9zdHJvbmc+ZWtyLW1veiwgZWtyPGJyPg0KPHN0cm9u Zz48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij5DYzogPC9zcGFuPjwvc3Ryb25nPmVrcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_CY4PR21MB05046590C8F5889AB1AAA3C7F5050CY4PR21MB0504namp_--