Re: [OAUTH-WG] Client Credential Expiry and new Registration Access Token - draft-ietf-oauth-dyn-reg-10

"Donald F Coffin" <donald.coffin@reminetworks.com> Fri, 17 May 2013 18:56 UTC

Return-Path: <donald.coffin@reminetworks.com>
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 E8D5021F9746 for <oauth@ietfa.amsl.com>; Fri, 17 May 2013 11:56:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.265
X-Spam-Level:
X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F38v7UgkthaT for <oauth@ietfa.amsl.com>; Fri, 17 May 2013 11:56:00 -0700 (PDT)
Received: from oproxy6-pub.bluehost.com (oproxy6-pub.bluehost.com [67.222.54.6]) by ietfa.amsl.com (Postfix) with SMTP id 4099221F9747 for <oauth@ietf.org>; Fri, 17 May 2013 11:56:00 -0700 (PDT)
Received: (qmail 29119 invoked by uid 0); 17 May 2013 18:55:30 -0000
Received: from unknown (HELO host125.hostmonster.com) (74.220.207.125) by cpoproxy3.bluehost.com with SMTP; 17 May 2013 18:55:30 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=reminetworks.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:To:From; bh=oUk0SYm0lGcHbv5w4INW3A/8fAUT6LUZNKaP+n2d8rk=; b=vu+KyAEyZDJusORJvVPFo1hxmUnfLbz0YRZuK7jTRr7qBVBnsPpRBuel40UogicsON+2tk/hbuf50expQwQ5zNlCxxCZAQJAPGUnK45H3kzZ6SrzKqEGFfKV+deFBP5u;
Received: from [68.4.207.246] (port=1599 helo=HPPavilionElite) by host125.hostmonster.com with esmtpa (Exim 4.80) (envelope-from <donald.coffin@reminetworks.com>) id 1UdPoP-0003KU-WE; Fri, 17 May 2013 12:55:30 -0600
From: Donald F Coffin <donald.coffin@reminetworks.com>
To: 'Mike Jones' <Michael.Jones@microsoft.com>, 'Phil Hunt' <phil.hunt@oracle.com>, oauth@ietf.org
References: <C0CE9538-4B72-4882-9462-B08A2D386720@oracle.com> <4E1F6AAD24975D4BA5B1680429673943677327E5@TK5EX14MBXC283.redmond.corp.microsoft.com>
In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943677327E5@TK5EX14MBXC283.redmond.corp.microsoft.com>
Date: Fri, 17 May 2013 11:53:41 -0700
Message-ID: <015101ce532f$d9e75d70$8db61850$@reminetworks.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQGc2XTV0stTXKINHA5eqQN7Dtb7MgNZWJg/mVHfx4A=
Content-Language: en-us
X-Identified-User: {1395:host125.hostmonster.com:reminetw:reminetworks.com} {sentby:smtp auth 68.4.207.246 authed with donald.coffin@reminetworks.com}
Subject: Re: [OAUTH-WG] Client Credential Expiry and new Registration Access Token - draft-ietf-oauth-dyn-reg-10
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Fri, 17 May 2013 18:56:05 -0000

The statement "Keep in mind that client credential is only used with the
token endpoint over TLS connection. It is NOT used to access resources
directly." is incorrect.  Section 4.4 of RFC 6749 states:

	The client can request an access token using only its client
credentials (or other supported means of authentication) when the client is
requesting access to the protected
	resources under its control, or those of another resource owner that
have been previously arranged with the authorization server (the method of
which is beyond the scope
	of this specification).

I have interpreted section 4.4 to imply that a client who has been granted
access to resources via an authorization code, for example, may use their
client credentials to access either a single
resource or multiple resources for which they have been granted access.
Although it is possible to never expire an access token obtained using
client credentials, I believe not expiring the
token, since it allows access to resources, is not desirable from a security
stand point.

On the other hand, the registration_access_token clearly will not allow a
client to access any resources and can only be used with client application
information.

Best regards,
Don
Donald F. Coffin
Founder/CTO

REMI Networks
22751 El Prado Suite 6216
Rancho Santa Margarita, CA  92688-3836

Phone:      (949) 636-8571
Email:       donald.coffin@reminetworks.com

-----Original Message-----
From: Mike Jones [mailto:Michael.Jones@microsoft.com] 
Sent: Thursday, May 16, 2013 3:27 PM
To: Phil Hunt; oauth@ietf.org WG
Subject: Re: [OAUTH-WG] Client Credential Expiry and new Registration Access
Token - draft-ietf-oauth-dyn-reg-10

This is nothing more than an RFC 6750 bearer token.  These can expire, as
explained in that draft.  (The can also be issued an a manner that they
don't expire.)  Nothing new is being invented in this regard.

				-- Mike

-----Original Message-----
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of
Phil Hunt
Sent: Thursday, May 16, 2013 2:35 PM
To: oauth@ietf.org WG
Subject: [OAUTH-WG] Client Credential Expiry and new Registration Access
Token - draft-ietf-oauth-dyn-reg-10

All,

In the dynamic registration draft, a new token type is defined called the
"registration access token". Its use is intended to facilitate clients being
able to update their registration and obtain new client credentials over
time.  The client credential is issued on completion of the initial
registration request by a particular client instance.

It appears the need for the registration access token arises from the
implied assertion that client credentials should expire. 
--> Is anyone expiring client credentials?

To date, we haven't had much discussion about client credential expiry. It
leads me to the following questions:

1.  Is there technical value with client credential/token expiry?  Keep in
mind that client credential is only used with the token endpoint over TLS
connection. It is NOT used to access resources directly.

2.  If yes, on what basis should client credential/token expire?
  a.  Time?
  b.  A change to the client software (e.g. version update)?
  c.  Some other reason?

3. Is it worth the complication to create a new token type (registration
access token) just to allow clients to obtain new client tokens?  Keep in
mind that client tokens are only usable with the AS token endpoint.  Why not
instead use a client token for dyn reg and token endpoint with the rule that
once a client token has expired (if they expire), an expired token may still
be used at the registration end-point.

4. Are there other reasons for the registration token?

Thanks,

Phil

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





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