Hi Mischa, Thanks very much for your comments on http://goo.gl/VnMKXS. We'll work on a revised version.
1) I would try to focuss on the MyProxy specific features. Currently a large part of the document is redescribing the standard OpenID-Connect specification/architecture which distracts.
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.
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.
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.
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.
5) You give an example of a /getcert request passing the CSR via a GET request in the URL. That will give problems on certain platforms due to maximum length of URLs. I would make it a POST.
Thanks. Agreed. Regards, Jim