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

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 04 Apr 2014 11:13:39 +0200

Hi all,

This is a Last Call for comments on the dynamic client registration
documents:

* OAuth 2.0 Dynamic Client Registration Core Protocol
http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-16

* OAuth 2.0 Dynamic Client Registration Metadata
http://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

---

From: Justin Richer <[email-masked]>
Date: Fri, 4 Apr 2014 09:22:53 -0400

I believe the two documents should be merged back into one, keeping the 
same functionality. It doesn't help developers to split them out like 
this and it doesn't change the modularity of the implementation at all 
to have things listed in separate documents.

I would really like to see actual concrete implementations of the 
software statement.

  -- Justin

On 04/04/2014 05:13 AM, Hannes Tschofenig wrote:
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Bill Mills <[email-masked]>
Date: Fri, 4 Apr 2014 09:41:12 -0700 (PDT)

Given the fundamental scalability problem we discussed in London do we really feel we're ready?
On Friday, April 4, 2014 3:07 AM, Hannes Tschofenig <[email-masked]> wrote:
 
Hi all,

Ciao
Hannes & Derek

---

From: Mike Jones <[email-masked]>
Date: Sat, 5 Apr 2014 00:49:03 +0000

I would combine these two documents, with no normative changes.  This would be a convenience for implementers.  And the metadata values that are currently optional would remain optional.

I would also add an optional "jwks" metadata member, paralleling this addition in OpenID Connect Registration.  This allows the JWK Set to be passed by value, rather than by reference.  This was discussed in London and people seemed to agree with this change.

The reference to RFC 4627 should be changed to RFC 7159, which has obsoleted 4627.

Other than that, I believe they're ready to proceed on the next steps towards becoming an RFC.

				-- Mike

-----Original Message-----
From: OAuth [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
Sent: Friday, April 04, 2014 2:14 AM
To: [email-masked]
Subject: [OAUTH-WG] Working Group Last Call on Dynamic Client Registration Documents

Hi all,

Since we have to do the last call for these two documents together we are setting the call for **3 weeks**.

Ciao
Hannes & Derek

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sat, 5 Apr 2014 08:39:15 +0200

Hi Bill,

which scalability problem are you referring to? As far as I remember there were issues around the management API but not the core protocol.

regards,
Torsten.

> Am 04.04.2014 um 18:41 schrieb Bill Mills <[email-masked]>:
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 05 Apr 2014 10:36:41 +0200

Hi Bill,

I believe Torsten is right. Most of the discussion in London was focused
on the management API rather than the core/meta-data docs.

Unfortunately, in our agenda we lumped both of these topics together.
There wasn't much disagreement on the core/meta-data docs.
As I wrote on the mailing list after our management API discussion (see
http://www.ietf.org/mail-archive/web/oauth/current/msg12514.html ) we
will have to get a better understanding of the constraints of the
deployment environments.

Ciao
Hannes

On 04/05/2014 08:39 AM, Torsten Lodderstedt wrote:
> Hi Bill,
> 
> which scalability problem are you referring to? As far as I remember
> there were issues around the management API but not the core protocol.
> 
> regards,
> Torsten.
> 
> Am 04.04.2014 um 18:41 schrieb Bill Mills <[email-masked]
> <mailto:[email-masked]>>:
> 
>> On Friday, April 4, 2014 3:07 AM, Hannes Tschofenig
>> <[email-masked] <mailto:[email-masked]>> wrote:
>> Hi all,
>>
>> [email-masked] <mailto:[email-masked]>
>> [email-masked] <mailto:[email-masked]>

---

From: Anthony Nadalin <[email-masked]>
Date: Sat, 5 Apr 2014 23:06:01 +0000

If these are going to be combined then a draft should be produced and then a decision should be made once everyone has a chance to review

-----Original Message-----
From: OAuth [mailto:[email-masked]] On Behalf Of Mike Jones
Sent: Friday, April 4, 2014 5:49 PM
To: Hannes Tschofenig; [email-masked]
Subject: Re: [OAUTH-WG] Working Group Last Call on Dynamic Client Registration Documents

				-- Mike

-----Original Message-----
From: OAuth [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
Sent: Friday, April 04, 2014 2:14 AM
To: [email-masked]
Subject: [OAUTH-WG] Working Group Last Call on Dynamic Client Registration Documents

Hi all,

Ciao
Hannes & Derek

---

From: Bill Mills <[email-masked]>
Date: Sat, 5 Apr 2014 22:12:33 -0700 (PDT)

To me the fundamental question of whether a client has to be registered in each place it is used is quite significant.  We don't address the problem and have not discussed it enough.

-bill
On Friday, April 4, 2014 11:39 PM, Torsten Lodderstedt <[email-masked]> wrote:
 
Hi Bill,

regards,
Torsten.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sun, 6 Apr 2014 09:59:07 +0200

I think it is at the discretion of the actual deployment whether clients may dynamically register or not (meaning they need to go through some oob mechanism). Protocols utilizing OAuth could make it part of their mandatory to implement features - in the same way OIDC does.

Best regards,
Torsten.
> Am 06.04.2014 um 07:12 schrieb Bill Mills <[email-masked]>:
>

---

From: Phil Hunt <[email-masked]>
Date: Sun, 6 Apr 2014 08:26:42 -0700

Hmm. I think this issue is self evident to the developer

If they have obtained a client id through developer registration (current typical oauth) they are good to go. 

IOW If you have a client id issued out of band you are good to go. 

Otherwise look for dyn reg or some other method. This likely happens where clients connect to apis and/or protocols deployed by many service providers  eg OIDC. An emerging example I heard at ietf london was interest in adapting oauth to non web protocols like smtp, imap, pop and even jabber. 

Phil

> On Apr 6, 2014, at 0:59, Torsten Lodderstedt <[email-masked]> wrote:
>

---

From: Mike Jones <[email-masked]>
Date: Sun, 6 Apr 2014 17:44:57 +0000

As a point of clarity, OpenID Connect does not mandate support for dynamic registration in all cases.  In static profiles with a pre-established set of identity providers, it isn’t required.  It *is* required in the dynamic profile, in which clients can use identity providers that they have no pre-existing relationship with.

                                                            -- Mike

From: OAuth [mailto:[email-masked]] On Behalf Of Torsten Lodderstedt
Sent: Sunday, April 06, 2014 12:59 AM
To: Bill Mills
Cc: [email-masked]
Subject: Re: [OAUTH-WG] Working Group Last Call on Dynamic Client Registration Documents

Best regards,
Torsten.
Am 06.04.2014 um 07:12 schrieb Bill Mills <[email-masked]<mailto:[email-masked]>>:
To me the fundamental question of whether a client has to be registered in each place it is used is quite significant.  We don't address the problem and have not discussed it enough.

-bill
On Friday, April 4, 2014 11:39 PM, Torsten Lodderstedt <[email-masked]<mailto:[email-masked]>> wrote:
Hi Bill,

regards,
Torsten.

Am 04.04.2014 um 18:41 schrieb Bill Mills <[email-masked]<mailto:[email-masked]>>:
Given the fundamental scalability problem we discussed in London do we really feel we're ready?
On Friday, April 4, 2014 3:07 AM, Hannes Tschofenig <[email-masked]<mailto:[email-masked]>> wrote:
Hi all,

Ciao
Hannes & Derek

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: Phil Hunt <[email-masked]>
Date: Sun, 6 Apr 2014 10:48:44 -0700

So in other words, OpenID Connect defines (or should define) how this happens.

There is no need for the Dyn Reg spec to clarify this right?

Phil

@independentid
www.independentid.com
[email-masked]

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sun, 20 Apr 2014 12:14:09 +0200

Hi all,

I also believe both documents should be merged.

Nevertheless, here are my comments on the current drafts:

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.

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.

---

From: Brian Campbell <[email-masked]>
Date: Wed, 30 Apr 2014 15:15:35 -0600

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 <
[email-masked]> wrote:

> instances? Given the current protocol design, I would assume it is at the
> discretion of the authz server. Other opinions?
>
> 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
> not requiring registration of redirect_uris for all clients using web-based
> grant types.
>
> last paragraph:
> 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
>
> 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
>
> particular requested grant types are not supported. Otherwise, the client
> cannot handle those error differently.
>
>
> * 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
>
> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
>
>

-- 
    <https://www.pingidentity.com/>
Brian Campbell
[Enter Title]
  @ [email-masked]   +1 720.317.2061  Connect
with us…   <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/>

---

From: Brian Campbell <[email-masked]>
Date: Wed, 30 Apr 2014 15:22:30 -0600

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
<[email-masked]>wrote:

>> valuable but needs much more text in order to come up with an interoperable
>> protocol design.
>>
>> 1.3. Protocol Flow
>>
>> 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
> logo] <https://www.facebook.com/pingidentitypage> <https://plus.google.com/u/0/114266977739397708540> [image:
> slideshare logo] <http://www.slideshare.net/PingIdentity> [image:
> flipboard logo] <http://flip.it/vjBF7> <https://www.pingidentity.com/blogs/>
> Revolution | 19–23 July, 2014 | Monterey, CA]<https://www.cloudidentitysummit.com/>
>
>

---

From: John Bradley <[email-masked]>
Date: Wed, 30 Apr 2014 17:32:18 -0400

The "jwks" meta-data parameter may also be required for some of the Proof of Possession flows.   Allowing a client to register its public key is important for reducing the number of long term symetric keys that need to be maintained.

On Apr 30, 2014, at 5:15 PM, Brian Campbell <[email-masked]> 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 <[email-masked]> wrote:
> Hi all,
> 
> *  OAuth 2.0 Dynamic Client Registration Core Protocol http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-16
> 
> 1.2.  Terminology
> 
> 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
> 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
> 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: 
> 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
> 
> 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 
> 
> 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.
> 
> 
> 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.
> 
> @	[email-masked]
> 	+1 720.317.2061
> Connect with us…
>        
>