Re: [OAUTH-WG] Dynamic Client Registration Conference Call: Wed 28 Aug, 2pm PDT: Conference Bridge Details

George Fletcher <gffletch@aol.com> Wed, 28 August 2013 16:20 UTC

Return-Path: <gffletch@aol.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 867BC11E81FE for <oauth@ietfa.amsl.com>; Wed, 28 Aug 2013 09:20:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.398
X-Spam-Level:
X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 JbYAm2aYuhDz for <oauth@ietfa.amsl.com>; Wed, 28 Aug 2013 09:20:38 -0700 (PDT)
Received: from omr-d04.mx.aol.com (omr-d04.mx.aol.com [205.188.109.201]) by ietfa.amsl.com (Postfix) with ESMTP id 0C4A921F9D0C for <oauth@ietf.org>; Wed, 28 Aug 2013 09:20:38 -0700 (PDT)
Received: from mtaout-mb06.r1000.mx.aol.com (mtaout-mb06.r1000.mx.aol.com [172.29.41.70]) by omr-d04.mx.aol.com (Outbound Mail Relay) with ESMTP id B7DE4700000A0; Wed, 28 Aug 2013 12:20:36 -0400 (EDT)
Received: from palantir.local (unknown [10.181.176.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mtaout-mb06.r1000.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 766C0E00009D; Wed, 28 Aug 2013 12:20:35 -0400 (EDT)
Message-ID: <521E2353.2030904@aol.com>
Date: Wed, 28 Aug 2013 12:20:35 -0400
From: George Fletcher <gffletch@aol.com>
Organization: AOL LLC
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Phil Hunt <phil.hunt@oracle.com>
References: <1373E8CE237FCC43BCA36C6558612D2AA28D6A@USCHMBX001.nsn-intra.net> <4D9D4AAD-55F9-4B7E-A56F-5BC42F028E13@oracle.com> <B14A12F5-EF5C-4529-90B7-C30E17958907@oracle.com> <521E1A34.30204@mitre.org> <BC009D74-FEF3-4827-8C0D-1B2FCCF9DA65@oracle.com>
In-Reply-To: <BC009D74-FEF3-4827-8C0D-1B2FCCF9DA65@oracle.com>
Content-Type: multipart/alternative; boundary="------------030302030309090109010109"
x-aol-global-disposition: G
X-AOL-VSS-INFO: 5400.1158/93304
X-AOL-VSS-CODE: clean
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20121107; t=1377706835; bh=5yZYRdOPWQFqANYiXQnqkyOFt71ehTipi57teMgd0Zo=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=XZhsC1Lk0YskalxuFkjfmq8L1wNCjX/HuuAT5rWN/+O8YNvsJffgGiL7po5zujkwM OUKHrP8Qk4YLoxKRKgbcZBJGkdDjsw8frOsbOY3TaTIEqZvgq80r24qXyHAoQUEsKW T+cRAFLkoAkFHYumffQxDbJpiwiqM4pyYIP0cMMk=
x-aol-sid: 3039ac1d2946521e235349c6
X-AOL-IP: 10.181.176.48
Cc: oauth mailing list <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Dynamic Client Registration Conference Call: Wed 28 Aug, 2pm PDT: Conference Bridge Details
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: Wed, 28 Aug 2013 16:20:48 -0000

On 8/28/13 12:02 PM, Phil Hunt wrote:
> Please define the all in one case. I think this is the edge case and is in fact rare.
>
> I agree, in many cases step 1 can be made by simply approving a class of software. But then step 2 is simplified.
>
> Dyn reg assumes every registration of an instance is unique which too me is a very extreme
If you have a mobile app that needs to do the code flow... which 
requires a client_secret in order to retrieve the access token and 
refresh token, how does the app do this without per app instance 
registration?

I'd argue that almost all user facing mobile apps will want the above 
flow and that's not a small, rare edge case.

Thanks,
George
> position.
>
> Phil
>
> On 2013-08-28, at 8:41, Justin Richer <jricher@mitre.org> wrote:
>
>> Except for the cases where you want step 1 to happen in band. To me, that is a vitally and fundamentally important use case that we can't disregard, and we must have a solution that can accommodate that. The notions of "publisher" and "product" fade very quickly once you get outside of the software vendor world.
>>
>> This is, of course, not to stand in the way of other solutions or approaches (such as something assertion based like you're after). It's not a one-or-the-other proposition, especially when there are mutually exclusive aspects of each.
>>
>> Therefore I once again call for the WG to finish the current dynamic registration spec *AND* pursue the assertion based process that Phil's talking about. They're not mutually exclusive, let's please stop talking about them like they are.
>>
>> -- Justin
>>
>> On 08/28/2013 11:17 AM, Phil Hunt wrote:
>>> Sorry. I meant also to say i think there are 2 registration steps.
>>>
>>> 1. Software registration/approval. This often happens out of band. But in this step policy is defined that approves software for use. Many of the reg params are known here.
>>>
>>> Federation techniques come into play as trust approvals can be based on developer, product or even publisher.
>>>
>>> 2. Each instance associates in a stateless way. Only clients that need credential rotation need more.
>>>
>>> Phil
>>>
>>> On 2013-08-28, at 8:04, Phil Hunt <phil.hunt@oracle.com> wrote:
>>>
>>>> I have a conflict I cannot get out of for 2pacific.
>>>>
>>>> I think a certificate based approach is going to simplify exchanges in all cases. I encourage the group to explore the concept on the call.
>>>>
>>>> I am not sure breaking dyn reg up helps. It creates yet another option. I would like to explore how federation concept in software statements can help with facilitating association and making many reg stateless.
>>>>
>>>> Phil
>>>>
>>>> On 2013-08-28, at 5:43, "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com> wrote:
>>>>
>>>>> Here are the conference bridge / Webex details for the call today.
>>>>> We are going to complete the use case discussions from last time (Phil wasn't able to walk through all slides). Justin was also able to work out a strawman proposal based on the discussions last week and we will have a look at it to see whether this is a suitable compromise. Here is Justin's mail, in case you have missed it: http://www.ietf.org/mail-archive/web/oauth/current/msg12036.html
>>>>>
>>>>> Phil, please feel free to make adjustments to your slides given the Justin's recent proposal.
>>>>>
>>>>> Topic: OAuth Dynamic Client Registration
>>>>> Date: Wednesday, August 28, 2013
>>>>> Time: 2:00 pm, Pacific Daylight Time (San Francisco, GMT-07:00)
>>>>> Meeting Number: 703 230 586
>>>>> Meeting Password: oauth
>>>>>
>>>>> -------------------------------------------------------
>>>>> To join the online meeting
>>>>> -------------------------------------------------------
>>>>> 1. Go to https://nsn.webex.com/nsn/j.php?ED=269567657&UID=0&PW=NNTI1ZWQzMDJk&RT=MiM0
>>>>> 2. Enter your name and email address.
>>>>> 3. Enter the meeting password: oauth
>>>>> 4. Click "Join Now".
>>>>>
>>>>> To view in other time zones or languages, please click the link:
>>>>> https://nsn.webex.com/nsn/j.php?ED=269567657&UID=0&PW=NNTI1ZWQzMDJk&ORT=MiM0
>>>>>
>>>>> To add this meeting to your calendar program (for example Microsoft Outlook), click this link:
>>>>> https://nsn.webex.com/nsn/j.php?ED=269567657&UID=0&ICS=MI&LD=1&RD=2&ST=1&SHA2=C6-AjLGvhdYjmpVdx75M6UsAwrNLMsequ5n95Gyv1R8=&RT=MiM0
>>>>>
>>>>> -------------------------------------------------------
>>>>> To join the teleconference only
>>>>> -------------------------------------------------------
>>>>> Global dial-in Numbers: http://www.nokiasiemensnetworks.com/nvc
>>>>> Conference Code: 944 910 5485
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>

-- 
George Fletcher <http://connect.me/gffletch>