[OAUTH-WG] About Big Brother and draft-campbell-oauth-resource-indicators-00

Denis <denis.ietf@free.fr> Tue, 15 November 2016 11:50 UTC

Return-Path: <denis.ietf@free.fr>
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 15ECB12957A for <oauth@ietfa.amsl.com>; Tue, 15 Nov 2016 03:50:15 -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 zvZ8xKqDc3yR for <oauth@ietfa.amsl.com>; Tue, 15 Nov 2016 03:50:11 -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 9577F129436 for <oauth@ietf.org>; Tue, 15 Nov 2016 03:50:11 -0800 (PST)
Received: from [192.168.0.14] (unknown [88.182.125.39]) by smtp6-g21.free.fr (Postfix) with ESMTP id DFA0178036C for <oauth@ietf.org>; Tue, 15 Nov 2016 12:50:08 +0100 (CET)
From: Denis <denis.ietf@free.fr>
To: oauth@ietf.org
Message-ID: <f5f049b9-1aca-9949-ffd6-c9ce1396ef31@free.fr>
Date: Tue, 15 Nov 2016 12:50:10 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------D47ABB75C172DF7D3E7913DA"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/NqXy4qKLm9biYU6MV0kG3w0DRJ0>
Subject: [OAUTH-WG] About Big Brother and draft-campbell-oauth-resource-indicators-00
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Nov 2016 11:50:15 -0000

Hello everybody,

Since I am not present at the meeting, I read the minutes from the first 
session, in particular:

    Brian Campbell and John did a draft allowing the client to tell the
    AS where it plans to use the token
    draft-campbell-oauth-resource-indicators

                   This enables the AS to audience restrict the access
    token to the resource
                   Phil Hunt:  We should keep the audience restriction
    idea on the table

The introduction contains the following sentences:

    Several years of deployment and implementation experience with OAuth
    2.0 [RFC6749] has uncovered a need, in some circumstances,
    for the client to explicitly signal to the authorization sever where
    it intends to use the access token it is requesting.

    A means for the client to signal to the authorization sever where it
    intends to use the access token it's requesting is important and
    useful.

The document contains a "security considerations" section but 
unfortunately no "privacy considerations" section.

Clause 2 states:

    The client may indicate the resource server(s) for which it is
    requesting an access token by including the
    following parameter in the request.

    resource

    OPTIONAL. The value of the resource parameter indicates a resource
    server where the requested
    access token will be used.*It MUST be an absolute URI*, as specified
    by Section 4.3 of[RFC3986],

With such an approach, the authorization server would have the ability 
to *act as a Big Brother *and hence to know exactly
where the user will be performing activities.

However, some users might be concerned with their privacy, and would 
like to restrict the use of the access token
to some resource servers without the authorization server knowing which 
are these resource servers.

The key point is whether the information is primarily intended to the 
authorization server or to the resource server(s).

I believe that it is primarily intended to the resource server(s) rather 
than to the authorization server in order to be included
in an access token. Obviously, the information needs to transit through 
the authorization sever, that should simply be copied
and pasted into the access token. Its semantics, if any, does not 
necessarily needs to be interpreted by the authorization sever.

I believe that a "privacy considerations" section should be added.

The sentence "*It MUST be an absolute URI*, as specified by Section 4.3 
of [RFC3986]" should be removed or
  replaced by : "*It MAY be an absolute URI*, as specified by Section 
4.3 of [RFC3986]".

Obviously, other changes would be necessary too.

Denis