[Fedsec-cg] [Idel-wg] OIDC/OA4MP Specification v0.2 - please read and comment

[Basney, Jim]

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