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

From: Mike Jones <[email-masked]>
Date: Sun, 6 Apr 2014 06:47:03 +0000

The core spec actually already does speak to this question, Bill.  http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-16#section-3 says:

   In some cases, authorization servers MAY choose to accept a software
   statement value directly as a Client ID in an authorization request,
   without a prior dynamic client registration having been performed.
   The circumstances under which an authorization server would do so,
   and the specific software statement characteristics required in this
   case, are beyond the scope of this specification.

This spec is about dynamic registration, and how to accomplish it.  In the case where registration isn't used, other specs or conventions would be needed, which are out of scope for the dynamic registration work (by definition!).

                                                            Cheers,
                                                            -- Mike

From: OAuth [mailto:[email-masked]] On Behalf Of Bill Mills
Sent: Saturday, April 05, 2014 10:13 PM
To: Torsten Lodderstedt
Cc: [email-masked]
Subject: Re: [OAUTH-WG] Working Group Last Call on Dynamic Client Registration Documents

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,

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]>>:
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,

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

_______________________________________________
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: Mike Jones <[email-masked]>
Date: Sun, 6 Apr 2014 06:48:10 +0000

If the working group decides to merge these specs, I'd be happy to do the editorial work to do so.

				Best wishes,
				-- Mike

-----Original Message-----
From: Anthony Nadalin 
Sent: Saturday, April 05, 2014 4:06 PM
To: Mike Jones; Hannes Tschofenig; [email-masked]
Subject: RE: [OAUTH-WG] Working Group Last Call on Dynamic Client Registration Documents

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

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

[email-masked]

---

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

OpenID Connect defines how it happens for OpenID Connect.  Other dynamic OAuth use cases still definitely need this.

From: Phil Hunt [mailto:[email-masked]]
Sent: Sunday, April 06, 2014 10:49 AM
To: Mike Jones
Cc: [email-masked]
Subject: Re: [OAUTH-WG] Working Group Last Call on Dynamic Client Registration Documents

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<http://www.independentid.com>
[email-masked]<mailto:[email-masked]>

On Apr 6, 2014, at 10:44 AM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:

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]<mailto:[email-masked]>
Subject: Re: [OAUTH-WG] Working Group Last Call on Dynamic Client Registration Documents

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

regards,
Torsten.

Ciao
Hannes & Derek