Hi Torsten, thanks for the comments.
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)?
Two things are at play here, from what I understand of the discussions
that went into this:
1) The audience of the secret is different. The client_secret is
intended for the Token Endpoint, while the registration_access_token is
intended for the Registration Endpoint.
2) Clients can use all different kinds of authentication at the Token
Endpoint, not just a client_secret. This gives us a way to support
dynamic registration of those clients without conflating the
functionality of the Registration Endpoint itself.
Additionally, there's a strong desire from Google and others for a
semi-registered use case, where the app developer gets a "developer key"
that they present to the registration endpoint. This "developer key" is
effectively a bootstrapped registration access token, and if you look at
it that way this lets us keep the same mechanisms here.
Section 2.1.
Some of those parameters seems to be OIDC-specific, e.g.
default_max_age. I would suggest to remove those.
I definitely want to trim any OIDC or UMA specific stuff. However, the
session-age-management stuff I think makes sense to keep. I'll pull it
out if others feel strongly about it though.
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?
I think it's a good idea to be more explicit about what each of the
parameters relates to - jwk_url for instance is the key of the *client*
and has more to do with using JWT Assertion for client credentials than
it does the server's token format.
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.
That is a really good idea, I'll do that. I've been struggling at how
best to present this information without it being overwhelmingly repetitive.
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.
I think this can be stated better, but the idea is that you should tell
people that a client was dynamically registered since the trust model is
going to be different from a background-registered one. The spoofing of
the client name is exactly one of the reasons for this, and it should be
stated explicitly.
Should external URLs be sanitized in order to prevent CSS and Request
Forgery?
If someone can give me the right text and tell me which URLs it needs to
be applied to, I'd be happy to incorporate it. Potential targets:
- redirect_uri
- logo
- homepage
- TOS
- privacy
Any others I'm missing?
Everything is being tracked in GitHub:
https://github.com/jricher/oauth-spec/issues
Again, thanks,
-- Justin
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
