These were not introduced in the new draft, they were just explained
better.
The Client Registration Endpoint has been (optionally) OAuth protected
all along. The Initial Registration Token is an authorization token (not
authentication) used to access that protected resource.
The Client Configuration Endpoint has been fully OAuth protected all
along. The Registration Access Token is (and has been) an authorization
token (not authentication) that is used to access that protected resource.
The fact that extensions and profiles of the DynReg spec are also doing
other things with it in addition to the authorization is completely out
of scope for the base.
-- Justin
On 05/30/2013 12:02 PM, Phil Hunt wrote:
Seriously. The new dyn reg draft introduces two new tokens. The initial reg
token and the registration access token.
As for the latter, the reg access token, my understanding is it has nothing to
do with an access token. It is issued *after* registration to allow reg
updates. Right? I know some are confused about this.
Phil
On 2013-05-30, at 8:52, Phil Hunt <phil.h...@oracle.com> wrote:
No different issue. I was concerned about the initial client assertion being
passed in as authen cred. It is a signed set of client reg metadata.
See we are confused. Hence my worry. :-)
Phil
On 2013-05-30, at 8:48, John Bradley <ve7...@ve7jtb.com> wrote:
I think Phil also had some processing reason why a Token endpoint or RS
wouldn't want to tale the authentication as a header, as the processing was
easier with them as parameters as they are potentially available to different
parts of the stack. That may have been mostly around RS, but the principal
may apply to the token endpoint as well.
On 2013-05-30, at 10:21 AM, Justin Richer <jric...@mitre.org> wrote:
"client_secret_post vs client_secret_basic"
BASIC and POST are essentially the same just different ways to send the client
secret. If an authorization server supports both, both should work for any
client. So are both methods treated differently?
I agree, and this was one of my original arguments for making this field plural
(or plural-able), but there hasn't been WG support for that so far.
I'm not arguing to make it plural. I think the authentication method is just
"client_secret".
That was also an option that was brought up, but in the OIDC WG the
counter-argument was (as I recall) that the two are syntactically separate and
there's a desire to restrict to a single type, such as disabling
client_secret_post. Basically, to make it unambiguous.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
