Subject: [OAUTH-WG] Comments on draft-ietf-oauth-dyn-reg-01

From: Torsten Lodderstedt <[email-masked]>
Date: Sat, 24 Nov 2012 19:42:10 +0100

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.

---

From: John Bradley <[email-masked]>
Date: Mon, 26 Nov 2012 11:12:09 -0300

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-masked]> wrote:

> Hi Justin,
> 
> I think your draft is a significant step forward. Thanks for putting it together.
> 
> 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
> 
> 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-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Justin Richer <[email-masked]>
Date: Mon, 26 Nov 2012 09:51:08 -0500

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.

> 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.

> 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.

> 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 
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

---

From: Torsten Lodderstedt <[email-masked]>
Date: Mon, 26 Nov 2012 20:03:04 +0100

Hi Justin,

Am 26.11.2012 15:51, schrieb Justin Richer:
> intended for the Token Endpoint, while the registration_access_token 
> is intended for the Registration Endpoint.

I would rather intend to use the same credential for a particular 
client_id on all _AS_ endpoints. That's the way the revocation endpoint 
is designed. I would not want to have another client cedential there.

> functionality of the Registration Endpoint itself.

I don't get this argument. I would assume if clients use another 
credential (than client_secret) at the token endpoint they use it at the 
registration endpoint as well.

> 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.

Ok, it seems the whole design of the registration endpoint is optimized 
to have the same credential type for bootstrapping and "ordinary" usage 
on the registration endpoint (in contrast to use the same credential on 
all endpoints).

regards,
Torsten.

---

From: John Bradley <[email-masked]>
Date: Mon, 26 Nov 2012 16:10:27 -0300

The idea is that registration is how you get/set the credential to use at the other endpoints.
Bootstrapping and updating that with a bearer token is not unreasonable.

The larger problem is that the password credential at the token endpoint is a bit of an anachronism.

In my opinion we should be using the assertion profile for that. 

Basically we are trying to stick with using access tokens for endpoint authorization.   I think that is in the spirit of OAuth.

Getting a password to use at the token endpoint with http basic auth is supported but I prefer to see less basic auth not more.

John B.

On 2012-11-26, at 4:03 PM, Torsten Lodderstedt <[email-masked]> wrote:

>> 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.
> 
> I would rather intend to use the same credential for a particular client_id on all _AS_ endpoints. That's the way the revocation endpoint is designed. I would not want to have another client cedential there.
> 
> 
>> 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.
> 
> I don't get this argument. I would assume if clients use another credential (than client_secret) at the token endpoint they use it at the registration endpoint as well.
> 
>> 
>> 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.
> 
> Ok, it seems the whole design of the registration endpoint is optimized to have the same credential type for bootstrapping and "ordinary" usage on the registration endpoint (in contrast to use the same credential on all endpoints).
> 
> regards,
> Torsten.
>