Hi Jim, a few more remarks, one important one, inline below. On Mon, Jun 08, 2015 at 03:25:09PM +0000, Basney, Jim wrote:
For our implementation work we've found it useful to have all the protocol messages specified in a single document, but I agree if we make this an OGF specification we'd just document the GetCert endpoint since the rest is standard OIDC/OAuth. I agree it's useful at this stage. It probably even could stay in as long as it is very clear which points are the additions.
2) As I suggested, it would be good to use the information retrieved from the userinfo endpoint to put in the CSR. As you mentioned, this gives an extra check for binding the token with the user.
I like the idea of doing some "channel binding" for the CSR in the GetCert request. I think I'd use the Subject Identifier from the ID Token so the client isn't required to call the UserInfo endpoint before calling the GetCert endpoint. I don't think we want a dependency between the GetCert and UserInfo endpoints. The client may call either UserInfo or GetCert but need not call both. Okee, that's of course equally fine, to use info from the ID Token. It only might be more in line with the spec to use the userinfo.
3) Also I would probably demand some form of client auth (e.g. the client_secret) for the /userinfo endpoint. This is one of the things I don't like so much in the OpenID Connect spec, it leaves this auth too much open (and so does google): if someone intercepts the access token, (s)he can get all the /userinfo information. By preventing that, point 2) becomes much stronger. Personally I would have liked if OIC would use (also) the ID Token for that, since it can contain audience and authorized party restrictions, but the spec doesn't seem to want you to do that... Perhaps I don't understand the ID Token rationale sufficiently yet.
I don't think we want to deviate from the OIDC standard's UserInfo endpoint behavior. We need to interoperate with other OIDC implementations. see above. Especially for the getcert this must somehow be better
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? An encrypted ID token, which is encrypted with a public key used by the getcert endpoint could also solve this (the ID token can contain a nonce set at the auth request time) but I think that's against the spec: the client also must be able to read it, and the malicious user can obtain the nonce. As far as I understood, the SURFnet APIS also demands client_id+client_secret for accessing the /userinfo endpoint. I don't think it's per-se against the OIC spec, the SPEC basically leaves it open. protected then only via an access token. The good thing is that you are writing the spec for that endpoint (-;
4) Likewise, doing a GET /userinfo request with an access_token in the URL is IMHO a bad idea as the token ends up in logfiles and/or leak in other ways (this is the second example at the UserInfo Request). I don't think the OIC spec mentions this, but RFC6750 mentions it in section 5.3 (last point).
Thanks. Agreed. I think the final OIDC/OAuth specifications don't require us to support that, so we should drop it. I think it might be required for some of the flows, not for all...
Best wishes, Mischa -- Nikhef Room H155 Science Park 105 Tel. +31-20-592 5102 1098 XG Amsterdam Fax +31-20-592 5155 The Netherlands Email msalle@nikhef.nl __ .. ... _._. .... ._ ... ._ ._.. ._.. .._..