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

Brian Campbell <bcampbell@pingidentity.com> Wed, 30 April 2014 21:23 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 EA2B91A0997 for <oauth@ietfa.amsl.com>; Wed, 30 Apr 2014 14:23:07 -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 eflMhLzGdLiZ for <oauth@ietfa.amsl.com>; Wed, 30 Apr 2014 14:23:05 -0700 (PDT)
Received: from na6sys009bog002.obsmtp.com (na6sys009bog002.obsmtp.com [74.125.150.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1CBAC1A09A8 for <oauth@ietf.org>; Wed, 30 Apr 2014 14:23:04 -0700 (PDT)
Received: from mail-ig0-f178.google.com ([209.85.213.178]) (using TLSv1) by na6sys009bob002.postini.com ([74.125.148.12]) with SMTP ID DSNKU2FpthrgOT5yn9uXxXlYeCN1SlO+K/mM@postini.com; Wed, 30 Apr 2014 14:23:02 PDT
Received: by mail-ig0-f178.google.com with SMTP id r10so699310igi.11 for <oauth@ietf.org>; Wed, 30 Apr 2014 14:23:01 -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=r2Jlwkny6FNlvcoOY8SNkMeYak5qXtuZrHYXIRRhPLY=; b=I9ZI6RxdRU48PcsjevnSOYhe4JvC+5CZ7T6zBSlRz4sl/LYk7wIIS1iSiBzUBOT+Zs OXNem+FUb03hRvNU7s8ppeQPrq4PWgCPEk7zYewsTpgGZI74FVHXQI6PI7/KktBWSWJv YS8F+OWiDAgBHNL1+5al+5zANYMf+R01lDasNDcOpabRkHTvG+GD/txQNAtZ2u7rs3Tz coyMj6Pc9camnIAnV+6gdwyt42OiBP7qNgM3dN/DdDDuAKk2MjUMEd3oNsxdQF1lWBQY lSXK6DLv/rpRldustC8KkcxC9NNPSFHaAcN1OnJ26JntrEcrOvXNQt2eRxscB5SFSvFe ewLg==
X-Gm-Message-State: ALoCoQkeXJkDgCdWRSVfMMEFUDW81Y4stOUx+d2Od9aciRsBoDN8ObXzz7sfNKgmwO35am6L3UwevdXYB5FFWM+kvqJ60K4GFtpoz5SEz7DGcWnBweeFhKf0XOimbdNyPqpLQ2nU7QGv
X-Received: by 10.50.4.70 with SMTP id i6mr41685692igi.40.1398892981142; Wed, 30 Apr 2014 14:23:01 -0700 (PDT)
X-Received: by 10.50.4.70 with SMTP id i6mr41685675igi.40.1398892980930; Wed, 30 Apr 2014 14:23:00 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.240.201 with HTTP; Wed, 30 Apr 2014 14:22:30 -0700 (PDT)
In-Reply-To: <CA+k3eCTeNpMi-=jeaa0UMEEMmGSohmRgDJ1doshWtY+M7B_cKA@mail.gmail.com>
References: <533E77C3.9000509@gmx.net> <53539DF1.4020103@lodderstedt.net> <CA+k3eCTeNpMi-=jeaa0UMEEMmGSohmRgDJ1doshWtY+M7B_cKA@mail.gmail.com>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Wed, 30 Apr 2014 15:22:30 -0600
Message-ID: <CA+k3eCQmZPRr2q-Xq3v7deiUowT--Gk+0krJtH7gY9LvhdNkHA@mail.gmail.com>
To: Torsten Lodderstedt <torsten@lodderstedt.net>
Content-Type: multipart/alternative; boundary=001a11c32a8835251c04f849278d
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/hQAHr_NnyhXrn_Di6DP9agqIldw
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:23:08 -0000

Somewhat related is the client_secret_expires_at parameter. It seems a
little odd to have that in this protocol that offers no way to deal with
the expiration other than a completely new reregistration. It also seems
like it should be more general than just the expiration of the secret and
apply to any credential (like "jwks") that doesn't have another means of
rotation. Or maybe just be a general expiration of the client's
registration.


On Wed, Apr 30, 2014 at 3:15 PM, Brian Campbell
<bcampbell@pingidentity.com>wrote;wrote:

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


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