Re: [OAUTH-WG] Working Group Last Call on Dynamic Client Registration Documents

Brian Campbell <bcampbell@pingidentity.com> Wed, 30 April 2014 21:16 UTC

Return-Path: <bcampbell@pingidentity.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08F951A0852 for <oauth@ietfa.amsl.com>; Wed, 30 Apr 2014 14:16:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.578
X-Spam-Level:
X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YpVoeox-RbWC for <oauth@ietfa.amsl.com>; Wed, 30 Apr 2014 14:16:13 -0700 (PDT)
Received: from na6sys009bog029.obsmtp.com (na6sys009bog029.obsmtp.com [74.125.150.103]) by ietfa.amsl.com (Postfix) with ESMTP id CD3751A0639 for <oauth@ietf.org>; Wed, 30 Apr 2014 14:16:12 -0700 (PDT)
Received: from mail-ig0-f171.google.com ([209.85.213.171]) (using TLSv1) by na6sys009bob029.postini.com ([74.125.148.12]) with SMTP ID DSNKU2FoG7yYgII/sfTp8pbGNFERYbya11N2@postini.com; Wed, 30 Apr 2014 14:16:11 PDT
Received: by mail-ig0-f171.google.com with SMTP id c1so2472947igq.4 for <oauth@ietf.org>; Wed, 30 Apr 2014 14:16:10 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=1zurINaAYw2NpLbegkhCKHYAS8py5rUkb5ZRP14Eovs=; b=J54l/LZ9C6lz6h2JYepPBttQ47H3QwThaVohgpBpPeyEMyHjbxlbLP+yECkF/+r3et VV0pLFOsr5hzdJOlcE+tXajKEOqhBY8GGB62IEWvtA2lKJ0OdiwwCLM/mDzuBXyqs15c /QbbHBY3p34s1Mp4JgUAi7SY2cdB5fnrqKMes+kG6ie+3t+/maWHmBn5F5Hnvp9E6tpe okPhDQWC8MHX1hhcco4deoLuNoUJJJJrr/xBvvRMpJ/ysEi1+fpQTLCkbk41w4kF0SGr 4wfSroylXWY2ozACW4/HX6HCHGZANYFkhwoDRvZK5Z5IH2GUvHT5DumQfkWyNEuTrUPp Bnlg==
X-Received: by 10.43.49.195 with SMTP id vb3mr6878091icb.14.1398892570751; Wed, 30 Apr 2014 14:16:10 -0700 (PDT)
X-Gm-Message-State: ALoCoQl4Yt4TaL6Ao2w2+lfdcmoE6vWSg1M/iXTKNSJhJxyiiCAYjQVuwFCBQEByHzOgdfQAc2X/w2BAPETfvJZvP8AgBnR4Bq7erQH9IsIfxk2wMQnGJACjoPb2zQkJy4yzt7p7FoyC
X-Received: by 10.43.49.195 with SMTP id vb3mr6877755icb.14.1398892565892; Wed, 30 Apr 2014 14:16:05 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.240.201 with HTTP; Wed, 30 Apr 2014 14:15:35 -0700 (PDT)
In-Reply-To: <53539DF1.4020103@lodderstedt.net>
References: <533E77C3.9000509@gmx.net> <53539DF1.4020103@lodderstedt.net>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Wed, 30 Apr 2014 15:15:35 -0600
Message-ID: <CA+k3eCTeNpMi-=jeaa0UMEEMmGSohmRgDJ1doshWtY+M7B_cKA@mail.gmail.com>
To: Torsten Lodderstedt <torsten@lodderstedt.net>
Content-Type: multipart/alternative; boundary=bcaec52999a7799da104f8490e66
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/PnliePHCAH6NDigpA1HAD3mJPkQ
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Working Group Last Call on Dynamic Client Registration Documents
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
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, 30 Apr 2014 21:16:16 -0000

As Mike and Torsten have said, and for the same reasons, I would also like
to see the "jwks" metadata parameter added.


On Sun, Apr 20, 2014 at 4:14 AM, Torsten Lodderstedt <
torsten@lodderstedt.net> wrote:

>  Hi all,
>
> I also believe both documents should be merged.
>
> Nevertheless, here are my comments on the current drafts:
>
>
> *  OAuth 2.0 Dynamic Client Registration Core Protocol
> http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-16
>
> 1.2.  Terminology
>
>  " Multiple instances of the same piece of client software MAY use
>       the same Client ID value at an authorization server, provided that
>       the Redirection URI values and potentially other values dictated
>       by authorization server policy are the same for all instances."
>
> Which entity determines whether the same client id is used for different
> instances? Given the current protocol design, I would assume it is at the
> discretion of the authz server. Other opinions?
>
> "Software Statement ... It may also be accepted by some authorization
> servers
>       directly as a Client ID value, without prior registration."
>
> under which circumstances does an authz server accept a software statement
> as client_id? How does the client know? I think the idea is valuable but
> needs much more text in order to come up with an interoperable protocol
> design.
>
> 1.3. Protocol Flow
>
> Initial Access Token vs. Software Statement: In my opinion, those concepts
> are two different ways to authorize client registration. Although there are
> the typical differences between tokens and assertions (such as opaque
> content vs. defined syntax), I feel software statements could supersede
> initial access tokens.
> Thoughts?
>
> 2.  Client Metadata
>
> "redirect_uris  ...  It is
>       RECOMMENDED that clients using these flows register this
>       parameter, and an authorization server SHOULD require ..."
>
> I consider this a rather weak statement - does this foster interop? Why
> not requiring registration of redirect_uris for all clients using web-based
> grant types.
>
> last paragraph:
> "If the same client metadata name is present in both
>    locations, the value in the software statement SHOULD take
>    precedence."
>
> why not MUST?
>
> 3.  Software Statement
>
> Is there a need to require a certain signature method for JWTs used as
> software statement (interop)? JWT itself requires "HMAC" and "none", which
> both are of no or limited value in this context. RSA is just recommended by
> the JWT spec.
>
> 5.1
>
> "If a software statement was used as part of the registration, its
>    value SHOULD be returned in the response and its value MUST be
>    returned if the authorization server supports registration management
>    operations [OAuth.Registration.Management] that would require its
>    presence in subsequent operations."
>
> I don't get the connection between software statements and the management
> API. In the management API spec, I only found a reference to software
> statements in the introduction. Should this text just be removed?
>
> 5.2
>
> error codes - invalid_client_metadata
>
> I consider this underspecified. How is the client supposed to react if
> this error occurs? I would expect the authz server to give more detailed
> information regarding error conditions, e.g. notify the client if
> particular requested grant types are not supported. Otherwise, the client
> cannot handle those error differently.
>
>
> * OAuth 2.0 Dynamic Client Registration Metadata
> http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-metadata-00
>
> I would suggest to add "jwks" (as defined in
> http://openid.net/specs/openid-connect-registration-1_0.html#ClientMetadata)
> in order to support native clients.
>
> regards,
> Torsten.
>
> Am 04.04.2014 11:13, schrieb Hannes Tschofenig:
>
> Hi all,
>
> This is a Last Call for comments on the dynamic client registration
> documents:
>
> * OAuth 2.0 Dynamic Client Registration Core Protocolhttp://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-16
>
> * OAuth 2.0 Dynamic Client Registration Metadatahttp://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-metadata-00
>
> Since we have to do the last call for these two documents together we
> are setting the call for **3 weeks**.
>
> Please have your comments in no later than April 25th.
>
> Ciao
> Hannes & Derek
>
>
>
>
> _______________________________________________
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>


-- 
   [image: Ping Identity logo] <https://www.pingidentity.com/>
Brian Campbell
[Enter Title]
  @ bcampbell@pingidentity.com  [image: phone] +1 720.317.2061  Connect
with us…  [image: twitter logo] <https://twitter.com/pingidentity> [image:
youtube logo] <https://www.youtube.com/user/PingIdentityTV> [image:
LinkedIn logo] <https://www.linkedin.com/company/21870> [image: Facebook
logo] <https://www.facebook.com/pingidentitypage> [image: Google+
logo]<https://plus.google.com/u/0/114266977739397708540> [image:
slideshare logo] <http://www.slideshare.net/PingIdentity> [image: flipboard
logo] <http://flip.it/vjBF7> [image: rss feed
icon]<https://www.pingidentity.com/blogs/>
   [image: Register for Cloud Identity Summit 2014 | Modern Identity
Revolution | 19–23 July, 2014 | Monterey,
CA]<https://www.cloudidentitysummit.com/>