[Idel-wg] OIDC/OA4MP Specification v0.2 - please read and comment
Basney, Jim
jbasney at illinois.edu
Mon Jun 8 11:25:09 EDT 2015
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
More information about the Idel-wg
mailing list