Re: [OAUTH-WG] Client Instances of An Application - Was: Re: Last call review of draft-ietf-oauth-dyn-reg-10

Justin Richer <jricher@mitre.org> Tue, 04 June 2013 18:42 UTC

Return-Path: <jricher@mitre.org>
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 722C421F869F for <oauth@ietfa.amsl.com>; Tue, 4 Jun 2013 11:42:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.143
X-Spam-Level:
X-Spam-Status: No, score=-6.143 tagged_above=-999 required=5 tests=[AWL=0.455, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 NKgLg4WXul8F for <oauth@ietfa.amsl.com>; Tue, 4 Jun 2013 11:42:41 -0700 (PDT)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 79E2521F9952 for <oauth@ietf.org>; Tue, 4 Jun 2013 11:35:12 -0700 (PDT)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id DF4CC1F1187; Tue, 4 Jun 2013 14:35:11 -0400 (EDT)
Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id BDEF41F1176; Tue, 4 Jun 2013 14:35:11 -0400 (EDT)
Received: from [10.146.15.13] (129.83.31.56) by IMCCAS03.MITRE.ORG (129.83.29.80) with Microsoft SMTP Server (TLS) id 14.2.342.3; Tue, 4 Jun 2013 14:35:11 -0400
Message-ID: <51AE3331.5080209@mitre.org>
Date: Tue, 4 Jun 2013 14:34:25 -0400
From: Justin Richer <jricher@mitre.org>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6
MIME-Version: 1.0
To: George Fletcher <gffletch@aol.com>
References: <85AA2C66-108B-4276-92EE-2D7566E54990@oracle.com> <6AF52CCD-4D6B-4696-8465-3345FFFDBE9C@mitre.org> <A1F47E63-DFE6-41A2-9F91-2DB44091D94C@oracle.com> <8EFC7565-0E81-4688-9AEB-459E7503F609@mitre.org> <6D11C230-31F6-4206-8F29-B1F2BFB5C17E@oracle.com> <4E1F6AAD24975D4BA5B16804296739436773435C@TK5EX14MBXC283.redmond.corp.microsoft.com> <B0C50AAD-97F0-4E55-A30D-C011B012A3DB@oracle.com> <519A42B4.2020803@mitre.org> <2B22BE68-6903-4C5B-8B0F-A10EB5BA74FE@oracle.com> <519B7AA5.3070908@mitre.org> <D4A8CBBB-2929-4B8D-BE05-086F895F0930@oracle.com> <519B9623.8030403@mitre.org> <C7C4CA9B-1C34-452A-B3C3-0BBE9EF1ECB7@oracle.com> <sjmr4gi4o3a.fsf@mocana.ihtfp.org> <13631B8F-D3FA-47E6-9176-812840BA507F@oracle.com> <c842d056-82f1-4d23-b130-4bd7f6ea0057@email.android.com> <1AB6F2B5-BBDE-476C-B30E-33510EAA024C@oracle.com> <51AE19BA.1090806@mitre.org> <51AE2A50.4030800@aol.com> <51AE2D85.4040101@aol.com>
In-Reply-To: <51AE2D85.4040101@aol.com>
Content-Type: multipart/alternative; boundary="------------050009040906090103070606"
X-Originating-IP: [129.83.31.56]
Cc: "oauth@ietf.org WG" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Client Instances of An Application - Was: Re: Last call review of 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: Tue, 04 Jun 2013 18:42:46 -0000

No problem, Georgia. :)

On 06/04/2013 02:10 PM, George Fletcher wrote:
> Argh! Typos (due to iPhone? no bad brain <-> hand connections). Sorry 
> Justin!
>
> On 6/4/13 1:56 PM, George Fletcher wrote:
>> +1 for leaving dyn reg as is and working on a profile that enables 
>> this more domain specific scenario. I agree with Phil and Justine 
>> that it's important... I just don't think it should be put in the 
>> core dyn reg spec.
>>
>> Thanks,
>> George
>>
>> On 6/4/13 12:45 PM, Justin Richer wrote:
>>> I agree with the goal of standardizing on identifying software 
>>> instances, but I think it's out of scope to do so inside of dynamic 
>>> registration when most dynamic registration use cases don't need it 
>>> and won't use it. I think that you've got to define discovery, 
>>> assertion contents, and a few other things in order to make it work 
>>> and interoperable across different services. Do we really want to 
>>> define assertion formats and server/client discovery and processing 
>>> rules inside of dynamic registration? I really don't think that's 
>>> beneficial, either to dynamic registration itself or to the problem 
>>> that the software instance tracking is trying to solve.
>>>
>>> If this gets proposed as a separate document, I will support it and 
>>> I will help work on it. Heck, I'll even help edit the thing (or 
>>> things) if people want. But I strongly believe that it's a separate 
>>> concern from dynamic client registration, and I think it needs to 
>>> have its own proper discussion apart from that.
>>>
>>>  -- Justin
>>>
>>> On 06/04/2013 02:28 AM, Phil Hunt wrote:
>>>> Yes. However the contents and format are out of scope.
>>>>
>>>> Phil
>>>>
>>>> On 2013-06-03, at 22:32, Torsten Lodderstedt 
>>>> <torsten@lodderstedt.net <mailto:torsten@lodderstedt.net>> wrote:
>>>>
>>>>> Hi Phil,
>>>>>
>>>>> isn't the initial registration token such a credential, which 
>>>>> allows to co-relate different instances of the same software?
>>>>>
>>>>> regards,
>>>>> Torsten.
>>>>>
>>>>>
>>>>>
>>>>> Phil Hunt <phil.hunt@oracle.com <mailto:phil.hunt@oracle.com>> 
>>>>> schrieb:
>>>>>
>>>>>     Finally i believe the bb+ doesn't have the issue because they are solving with an initial authn credential that contains the same info.
>>>>>
>>>>>     My feeling is that this functionality needs to be standardized one way or another.
>>>>>
>>>>>     Phil
>>>>>
>>>>>     On 2013-06-03, at 19:16, Derek Atkins <derek@ihtfp.com  <mailto:derek@ihtfp.com>> wrote:
>>>>>
>>>>>         Phil, Phil Hunt <phil.hunt@oracle.com
>>>>>         <mailto:phil.hunt@oracle.com>> writes:
>>>>>
>>>>>             Not quite. I will call you. I am saying we are
>>>>>             transitioning from the old public client model. The
>>>>>             new model proposes quasi-confidential characteristics
>>>>>             but in some respects is missing key information from
>>>>>             the public m! odel. Namely that a group of clients are
>>>>>             related and there have common behaviour and security
>>>>>             characteristics. We need to add to the self-asserted
>>>>>             model an assertion equiv to the old common client_id.
>>>>>             That is all. I am NOT looking for a proof of
>>>>>             application identity here. That is too far. But
>>>>>             certainly what we define here can open that door. Phil
>>>>>
>>>>>         I think I understand what you're saying here. In the "old
>>>>>         way", a public client had a constant client_id amongst all
>>>>>         instances of that public client, whereas in the "new way",
>>>>>         a public client will have different client_ids amongst all
>>>>>         instances of that client. You feel this is a loss, whereas
>>>>>         it seems most people seem to feel this change is okay.
>>>>>         Since you are effectively the lone dissenter on this one
>>>>>         topic, let me ask you a question: What is a technical
>>>>>         reason that you need to have a constant, assertion that
>>>>>         would bind to! gether (in a non-authenticated way)
>>>>>         multiple instances of a client? I believe that Justin has
>>>>>         provides some attacks against this; so I'm trying to
>>>>>         understand, (with my chair hat on), why you need this
>>>>>         functionality? With my security-mafia hat on, I feel like
>>>>>         the old way was bad, and I much prefer the newer way where
>>>>>         each instance of a client gets its own ID and a
>>>>>         locally-stored secret. -derek -- Derek Atkins 617-623-3745
>>>>>         derek@ihtfp.com <mailto:derek@ihtfp.com> www.ihtfp.com
>>>>>         <http://www.ihtfp.com> Computer and Internet Security
>>>>>         Consultant 
>>>>>
>>>>>     ------------------------------------------------------------------------
>>>>>
>>>>>     OAuth mailing list
>>>>>     OAuth@ietf.org  <mailto:OAuth@ietf.org>
>>>>>     https://www.ietf.org/mailman/listinfo/oauth
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth