Hi Mischa, Thanks again for the comments. I've started to update http://goo.gl/VnMKXS based on our discussion.
One very important point, which David (Groep) and I discussed this afternoon: there currently isn't any protection, unless I'm missing something, against a malicious user obtaining a valid certificate using a stolen token and a CSR and key-pair he created. That would give him a valid certificate in some else's name, for which he owns the private key. OAuth2.0 tokens aren't the best protected secrets typically, as they are passed around. If they never leave the client in this scenario, apart from being send to the getcert endpoint, it is probably still manageable, but I think it would certainly be better to demand some form of client authentication. If it is the client in any case, then it already has the client_secret, so you could then demand that the client authenticates using client_id and client_secret to the getcert endpoint. Restricting it to the specific client is probably what you want to do in any case?
Yes, I'm convinced. :) If I understand correctly it means that GET requests to the GetCert endpoint will contain two Authorization headers, one of type Basic containing the client_id and client_secret and another of type Bearer containing the access_token. However, as previously discussed, we prefer POST requests to the GetCert endpoint, in which case client_id, client_secret, and access_token are included in the application/x-www-form-urlencoded body. I've updated http://goo.gl/VnMKXS to match my understanding. Regards, Jim