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

[Basney, Jim]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6007 bytes
Desc: not available
URL: <http://www.ogf.org/pipermail/fedsec-cg/attachments/20150610/ee4790bb/attachment.bin>