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
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
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,
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
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
OpenID Connect defines how it happens for OpenID Connect. Other dynamic OAuth
use cases still definitely need this.
From: Phil Hunt [mailto:phil.h...@oracle.com]
Sent: Sunday, April 06, 2014 10:49 AM
To: Mike Jones
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Working Group Last Call on Dynamic
I have to agree with Phil on this as there are already spec out there that use
HoK and PoP , either of these work but prefer HoK as folks get confused with
PoP as we have seen this within our company already
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Mike Jones
Sent: Thursday,
