Torsten, Originally in OIC we defined using the client secret to access the registration endpoint.
We received a lot of feedback that having it bearer protected for the first access and password protected for subsequent access was confusing. There are also the cases where there is no need for a client secret. In the case of the token grant type. There was also feedback that using the same secret for both makes rotation of the client secret more challenging when errors occur. I think having them separate made the OIDC spec cleaner. So there was a fair amount of thought that went into that decision. In OIDC the jwk_url is used most commonly for the authorization server to validate the signature of a request object coming from the client or the signature of the request to the token endpoint using the JWT assertion spec. Nether of those are part of the core spec but I can see keeping it to standardize registration for those clients using the Assertion spec for authentication to the token endpoint. John B. On 2012-11-24, at 3:42 PM, Torsten Lodderstedt <[email protected]> wrote: > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
