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 20:53 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 0C56121F96A9 for <oauth@ietfa.amsl.com>; Fri, 17 May 2013 13:53:11 -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 PZjbBbYDMW9y for <oauth@ietfa.amsl.com>; Fri, 17 May 2013 13:53:06 -0700 (PDT)
Received: from oproxy14-pub.unifiedlayer.com (oproxy14-pub.unifiedlayer.com [67.222.51.224]) by ietfa.amsl.com (Postfix) with SMTP id 77E8821F96A2 for <oauth@ietf.org>; Fri, 17 May 2013 13:53:04 -0700 (PDT)
Received: (qmail 20283 invoked by uid 0); 17 May 2013 20:32:00 -0000
Received: from unknown (HELO host125.hostmonster.com) (74.220.207.125) by oproxy14.unifiedlayer.com with SMTP; 17 May 2013 20:32:00 -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:Cc:To:From; bh=58W5jjwQz7ouOGmAE6WLkAdkC3PMQsGQrUQBmRmnWI8=; b=KznXrQN0ZAR/T/xH63M3wNgNCOQ27p5YrXNSKs2jBoSHkBF4kjgamAja1lL4Qq89EhJSz6gkvblPh4vPM1QwxFvxokvHcxkL2zgmWZTB/5VwG9EDhvwT45YbfVnwbPNI;
Received: from [68.4.207.246] (port=2508 helo=HPPavilionElite) by host125.hostmonster.com with esmtpa (Exim 4.80) (envelope-from <donald.coffin@reminetworks.com>) id 1UdRJn-00048c-ND; Fri, 17 May 2013 14:31:59 -0600
From: Donald F Coffin <donald.coffin@reminetworks.com>
To: 'Phil Hunt' <phil.hunt@oracle.com>
References: <C0CE9538-4B72-4882-9462-B08A2D386720@oracle.com> <4E1F6AAD24975D4BA5B1680429673943677327E5@TK5EX14MBXC283.redmond.corp.microsoft.com> <015101ce532f$d9e75d70$8db61850$@reminetworks.com> <57F130F2-AE65-4B78-A7B4-797965285067@oracle.com>
In-Reply-To: <57F130F2-AE65-4B78-A7B4-797965285067@oracle.com>
Date: Fri, 17 May 2013 13:30:11 -0700
Message-ID: <019a01ce533d$54cb4080$fe61c180$@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/Ac33NBwCxRi/1pktY6aQ
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}
Cc: oauth@ietf.org
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 20:53:11 -0000

Phil,

That is true.  

All I am saying is the client may use the client_credential access token to
access groups of authorizations which have been granted based on the client
grant request and thus does have access to resources.  Your initial post
said the client_credential grant cannot be used to access resources, which
IMHO is incorrect based on the RFC 6749 definition in section 4.4. 

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: Phil Hunt [mailto:phil.hunt@oracle.com] 
Sent: Friday, May 17, 2013 12:01 PM
To: Donald F Coffin
Cc: Mike Jones; oauth@ietf.org
Subject: Re: [OAUTH-WG] Client Credential Expiry and new Registration Access
Token - draft-ietf-oauth-dyn-reg-10

That is incorrect. A client grant request still results in a separate access
token issued. 

Phil

On 2013-05-17, at 11:53, Donald F Coffin <donald.coffin@reminetworks.com>
wrote:

> 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
> 
>