JWT is a OAuth WG item so we can do a proof semantic for that that works with the OAuth bindings but is not necessarily specific to OAuth. Connect and Browser ID may want to use it as well for JWT outside of OAuth.
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
