Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.txt

Justin Richer <jricher@mitre.org> Thu, 30 May 2013 16:43 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 2AFF921F972C for <oauth@ietfa.amsl.com>; Thu, 30 May 2013 09:43:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.213
X-Spam-Level:
X-Spam-Status: No, score=-5.213 tagged_above=-999 required=5 tests=[AWL=-0.914, BAYES_00=-2.599, MANGLED_CREDIT=2.3, 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 Jv-ppjD78XZH for <oauth@ietfa.amsl.com>; Thu, 30 May 2013 09:43:36 -0700 (PDT)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 2ADA221F96FD for <oauth@ietf.org>; Thu, 30 May 2013 09:43:36 -0700 (PDT)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id C3B711F02A2; Thu, 30 May 2013 12:43:35 -0400 (EDT)
Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id AE6221F00DC; Thu, 30 May 2013 12:43:35 -0400 (EDT)
Received: from [10.146.15.13] (129.83.31.56) by IMCCAS02.MITRE.ORG (129.83.29.79) with Microsoft SMTP Server (TLS) id 14.2.342.3; Thu, 30 May 2013 12:43:35 -0400
Message-ID: <51A7818F.1090004@mitre.org>
Date: Thu, 30 May 2013 12:42:55 -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: Phil Hunt <phil.hunt@oracle.com>
References: <20130524203638.25945.84709.idtracker@ietfa.amsl.com> <5071FA1C-F6F7-43AD-9EDC-13B0D480F97A@mitre.org> <51A3AE0B.1020802@lodderstedt.net> <51A4BF27.50800@mitre.org> <51A72B3E.9050300@lodderstedt.net> <51A76052.6040004@mitre.org> <0354062A-DEB8-4272-861B-43DC48887F54@ve7jtb.com> <2E872A80-1B5B-468D-910C-1D6E9DFEFF78@oracle.com> <60DC41E5-7A35-4FAB-B383-152159CE0112@ve7jtb.com> <06889BF8-67A8-4058-8AC0-52A9302BBA4D@oracle.com>
In-Reply-To: <06889BF8-67A8-4058-8AC0-52A9302BBA4D@oracle.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Originating-IP: [129.83.31.56]
Cc: "oauth@ietf.org WG" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.txt
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: Thu, 30 May 2013 16:43:41 -0000

But OAuth says nothing about whether tokens are "local" or "3rd party", 
and this spec inherits that definition. The AS is free to do whatever it 
wants with the token. You can already do both scenarios that you're 
talking about below with the existing functionality (in a way that makes 
sense), so I just don't see the value in adding another parameter to 
handle that case.

Yes, some registration endpoint implementations won't be able to handle 
external assertions as their OAuth tokens and won't have access to them 
at the right levels. But, that's already true for other kinds of 
protected resource, isn't it? As far as DynReg is concerned, I want it 
to just stay an OAuth protected resource. What you do with it beyond 
that (like what we're doing in BB+) is of no concern to the base spec.

As I've said before, I'm not opposed to adding a very strictly defined, 
optional software_id field (if others agree), but I'm not OK with 
defining assertion semantics there. I'm also not OK with defining 
assertion semantics in the Initial Registration Token. Both of these are 
too implementation specific, and from the client/developer's perspective 
these tokens ought to remain opaque, like OAuth tokens always are.

  -- Justin

On 05/30/2013 12:36 PM, Phil Hunt wrote:
> In 1.4.1 - I'm ok with this use of having the AS token endpoint issue an access token to an anonymous client to begin the registration process (just not sure the value of it).
>
> I'm not ok with what is happening in 1.4.2 (Protected Registration).
>
> I think we should make it clear that it is for Protected *Local* Registration.  In this case it makes sense that the local OOB registration process could reasonably issue a local access token.
>
> A new option (1.4.3), Protected 3rd Party Registration would proceed differently (the BB+ case)….
>
> It opens the door for a scenarios such as where a certifying entity, e.g. the publisher of a REST API issues the developer a client application assertion that includes some defined application metadata.  We should specify what claims are typically present and what is minimally required.
>
> Because this assertion is not an AuthN statement (technically), my preference is that this assertion then be presented as the software_id because it is identifying the software and represents assertions about client metadata.
>
> IMPORTANT:  By NOT presenting the 3rd party assertion as the initial access token, it is possible for an administrator to then take that assertion and locally register the application --> converting the client application registration to a 1.4.2 local registration.  The client would still present the 3rd party assertion as the software_id AND the initial access token from the manual registration.
>
> OR,
>
> The client registers *anonymously* but presents the signed 3rd party assertion in software_id.
>
> Phil
>
> @independentid
> www.independentid.com
> phil.hunt@oracle.com
>
>
>
>
>
> On 2013-05-30, at 9:08 AM, John Bradley wrote:
>
>> The initial access token is a OAuth bearer Access token (Authz).   Like any bearer token it can be structured or not.   Your concern is I think around some work BB+ has done to profile a structured token for this particular RS use.  That is out of scope for the core of dynamic registration, as it is out of scope for OAuth core.
>>
>> So http basic vs parameters makes no difference to you.  The assertion profile only uses POST parameters for the assertion rather than headers so that should not be an issue for that authentication method.
>>
>> John B.
>>
>> On 2013-05-30, at 11:52 AM, Phil Hunt <phil.hunt@oracle.com> wrote:
>>
>>> No different issue. I was concerned about the initial client assertion being passed in as authen cred. It is a signed set of client reg metadata.
>>>
>>> See we are confused. Hence my worry. :-)
>>>
>>> Phil
>>>
>>> On 2013-05-30, at 8:48, John Bradley <ve7jtb@ve7jtb.com> wrote:
>>>
>>>> I think Phil also had some processing reason why a Token endpoint or RS wouldn't want to tale the authentication as a header, as the processing was easier with them as parameters as they are potentially available to different parts of the stack.   That may have been mostly around RS, but the principal may apply to the token endpoint as well.
>>>>
>>>> On 2013-05-30, at 10:21 AM, Justin Richer <jricher@mitre.org> wrote:
>>>>
>>>>>>>> "client_secret_post vs client_secret_basic"
>>>>>>>> BASIC and POST are essentially the same just different ways to send the client secret. If an authorization server supports both, both should work for any client. So are both methods treated differently?
>>>>>>> I agree, and this was one of my original arguments for making this field plural (or plural-able), but there hasn't been WG support for that so far.
>>>>>> I'm not arguing to make it plural. I think the authentication method is just "client_secret".
>>>>> That was also an option that was brought up, but in the OIDC WG the counter-argument was (as I recall) that the two are syntactically separate and there's a desire to restrict to a single type, such as disabling client_secret_post. Basically, to make it unambiguous.
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth