On the specifics of OAuth bindings. We may profit by stepping back a bit and agreeing on what threats we are attempting to mitigate.
One threat that is on a number of peoples minds is the complete failure of PKIX. Another is the simple fact that many clients don't validate server certificates and ignore warnings. One of the issues people had with MAC was that while it protected the client from MTM in the connection to the protected resource it basically did nothing to stop the same attack between the client and token endpoint where the attacker gets the MAC token and secret. Agreeing on what attacks against OAuth we are trying to prevent may help focus our discussions on bindings. We need to be careful not to just push the problem around, from endpoint to endpoint. John B. On 2012-07-11, at 6:48 AM, Hannes Tschofenig wrote: > It is certainly a plus that we can now make use of the JSON work. This will > improve interoperability and avoid making implementation mistakes if > developers use libraries (with the JOSE features). > > On Jul 11, 2012, at 1:37 PM, John Bradley wrote: > >> The POST of a signed blob would work with JOSE or CMS signing the blob. >> >> I suspect that would be more of a application level signing than OAuth >> though. >> Though worth talking about. >> >> I suspect a OAuth level signing might look a bit like HMAC. >> >> The access_token might be: >> 1 a JWT including a JWK structure for the proof key (public key or key >> reference). >> 2 a opaque token that is used by the Protected resource to look up the >> actual token via a STS like mechanism. >> 3 a SAML token in JOSE is also a possibility for some people. >> >> The above choice should be opaque to the client. >> >> For asymmetric binding the key to TLS seems like a good idea. There are >> however many practical key management issues that clients may have >> (especially if multiple keys are used) and it may not be end to end. >> >> Another OAuth binding might be to use a token collection. One being the >> access token and another being a JWT/JWS containing one or more hashes of >> the HTTP message or message components. >> >> I don't want to reinvent SOAP, or WS-Security, however I also don't want to >> reject all of the use-cases out of hand. >> >> The common uses need to be dead simple for clients. >> >> John B. >> >> >> >> On 2012-07-11, at 3:37 AM, Manger, James H wrote: >> >>>>> John Bradley wrote: >>>>>> I suspect that we will need two OAuth bindings. One for TLS and one for >>>>>> signed message. >>>>> >>>>> I agree. For instance, set “token_type”:”tls_client_cert” when the client >>>>> has to use TLS; set “token_type”:”cms” when the client has to digitally >>>>> sign messages using Crypto Message Syntax (CMS); …. >>> >>>> Perhaps JWT/JOSE rather than CMS:) >>>> >>>> Though there will need to be discussions about what part of the message >>>> needs to be signed. >>> >>> I was about to list JOSE as the example, but baulked precisely because of >>> this issue. It wasn't obvious how a request to a protected resource would >>> be wrapped in a JOSE message. At least with CMS (or WS-*, or XML DSig, or >>> SOAP…) you can guess that the request is a POST of a signed blob. >>> >>> -- >>> James Manger >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
