> Eran Hammer has decided to step down as Editor of the OAuth Core
> specification. I would like to personally thank Eran for all his years
> of hard work and effort to the draft as well as to the working group at
> large.
As former chair, I want to add my thanks. Eran has done a *lot* of
work o
Having re-read this I think I now understand how symmetric would work. In the
HOK model as I think of it we have 3 basic parts: opaque token stuff, asserted
client key, and server signature. The asserted client key could be:
-a public key
-a certificate
-an encrypted symmetric key
-other?
Fo
Hmmm, well actually, I am referencing something like the symmetric key
generation (ephemeral) within TLS, I certainly dont view that as "crazy
enterprise identity management" :-)
If a client (with a public-private key pair) and resource have a
multi-step interaction, and this is a common use-c
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
a
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 certainl
It would be good to get your feedback here as well as this document relates to
the the holder-of-the-key concept (with the exchange of the raw public key in
TLS).
Ciao
Hannes
Begin forwarded message:
> From: Hannes Tschofenig
> Date: July 11, 2012 1:56:40 PM GMT+03:00
> To: t...@ietf.org
> C
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
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 struct
Hi Tony,
On Jul 10, 2012, at 12:17 AM, Anthony Nadalin wrote:
>> Regarding the symmetric keys: The asymmetric key can be re-used but with a
>> symmetric key holder-of-the-key you would have to request a fresh one every
>> time in order to accomplish comparable security benefits.
>
> We have u
>>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 Cr
10 matches
Mail list logo
