Hi Justin,
I think your draft is a significant step forward. Thanks for putting it
together.
Here are my detailed comments/questions:
Whats the advantage of having two secrets for the same client_id, namely
request_access_token and client_secret? Why not always issuing a secret
and use it for authentication on this endpoint (in the same way as at
the token endpoint)?
Section 2.1.
Some of those parameters seems to be OIDC-specific, e.g.
default_max_age. I would suggest to remove those.
I would also recommend to state the relation of the parameters to core
_or_ extension features. For example, "jwk_url" is only be used if the
AS supports JWT Bearer Tokens, right?
When reading the document the first time, I was a bit lost since none of
the parameters is explained in this section. I would therefore suggest
to change order of sections 2 and 3.
Security Considerations
"An IdP can also make warnings against untrusted RPs in all
cases, especially if they're dynamically registered, have not been
trusted by any users at the IdP before, and want to use the logo
feature."
This reads funny since this whole document is about dynamic client
registration, isn’t it?
I think AS should generally be careful when displaying client meta data
if they did not previously validate them. A client could also call
itself Google or Facebook. This section must call this out aloud.
Should external URLs be sanitized in order to prevent CSS and Request
Forgery?
regards,
Torsten.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
