I also fail to see the value of a symmetric holder-of-the-key solution and I
don't buy the performance argument either (particularly since we are using a
short key length here.
I hope that this is not the "let us replicate all the work we had done in some
other crazy enterprise identity managem
inline
On 2012-07-10, at 8:44 PM, Manger, James H wrote:
> William Mills wrote:
> > The server would need to issue a key pair and not just the private key.
> > Are you saying the private key is for the certificate, and that certificate
> > is part of the access_token?
>
> Yes. The AS issues
William Mills wrote:
> The server would need to issue a key pair and not just the private key. Are
> you saying the private key is for the certificate, and that certificate is
> part of the access_token?
Yes. The AS issues temporary credentials for the client app to use. In this
case the crede
I don't have much data on how many request/responses an oauth web client does
per connection. But if we force a new TLS connection for each access token
(which may only be used for 1 or 2 request/responses) we will have a
scalability issue. I do agree the approach is relatively simple and workab
OK, but why do you need holder-of-key then? I think holder-of-key gets
significantly weird in the symmetric key case. In the PKI case the token has
(public_key, token, signature(public_key, token, serversecret)). How will the
server assert something in the credential that's useful in place o
Hannes,
we have a variety of use-cases wherein a single server ("client")
repeatedly interacts with a resource server for business purposes. These
interactions may be on-behalf-of
a single user or even multiple users. In such a use-case, use of
assymetric signature imposes an unacceptable perf
Hi,
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.
Dick Hardt has agreed to take over the editor role to see the draft to
comple
So one of our cases is that we want to use a proof key to protect the symmetric
key that is used to protect messages, so yes this would be application specific
but that is the nature of OAuth in general, not much interop except at the
application level
From: oauth-boun...@ietf.org [mailto:oauth
Hi Prateek,
why do you care about the symmetric key case?
Specifying more variants requires more code and decreases
interoperability.
Ciao
Hannes
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of ext prateek mishra
Sent: Tuesday, July 10, 2012 8:42 PM
To:
As Phil Hunt suggests, there is a need for a discussion of the use-cases
involved
How to bind the key to the requestor may have several variations, I
would hope the work would cover a broad range
Given the importance of the symmetric key case, I would also be
interested in key establishment
When I say arguably, I expect you to argue.
John B.
Sent from my iPhone
On 2012-07-10, at 1:01 PM, Anthony Nadalin wrote:
>> Binding the key to the channel is arguably the most secure
>
> Not really, there are hardware options that give good security properties
>
> -Original Message-
> Binding the key to the channel is arguably the most secure
Not really, there are hardware options that give good security properties
-Original Message-
From: John Bradley [mailto:ve7...@ve7jtb.com]
Sent: Tuesday, July 10, 2012 9:55 AM
To: Hannes Tschofenig
Cc: Anthony Nadalin; Hannes T
We should be supporting both the client providing the key pair and a server
generated pair.
In higher security the private key may be stored in hardware.
There are more possible attacks if the key is sent to the client.
John B.
Sent from my iPhone
On 2012-07-10, at 12:53 PM, William Mills
Hannes,
Thanks for your proposal. I'm glad to see work on this starting.
I think use cases may demand more than just channel security. A lot of cases do
not have end-to-end TLS channels available. So while this could be stated to be
an improvement it may not achieve the end-to-end authenticatio
Binding the key to the channel is arguably the most secure.
SSL offloading and other factors may prevent that from working in all cases.
I suspect that we will need two OAuth bindings. One for TLS and one for signed
message.
John B.
Sent from my iPhone
On 2012-07-10, at 12:11 PM, Hannes
The server would need to issue a key pair and not just the private key. Are
you saying the private key is for the certificate, and that certificate is part
of the access_token?
From: "Manger, James H"
To: Hannes Tschofenig ; OAuth WG
Sent: Monday, July 9,
The key does not have to be bound to the channel, that is just one option, the
key can be a negotiated key
-Original Message-
From: Hannes Tschofenig [mailto:hannes.tschofe...@gmx.net]
Sent: Tuesday, July 10, 2012 9:12 AM
To: Anthony Nadalin
Cc: Hannes Tschofenig; John Bradley; OAuth WG
If we do not bind the key to the channel than we will run into all sorts of
problems. The current MAC specification illustrates that quite nicely. On top
of that you can re-use the established security channel for the actual data
exchange.
On Jul 10, 2012, at 5:29 PM, Anthony Nadalin wrote:
>
> One question is if we want to do a generic proof of possession for JWT that
> is useful outside OAuth, or something OAuth specific.The answer may be a
> combined approach.
Depends if we want OAuth to support the concept of a request/response for a
proof token and keep the actual binding
I agree that there are use-cases for all of the proof of possession mechanisms.
Presentment methods also need to be considered.
TLS client auth may not always be the best option. Sometimes message signing
is more appropriate.
One question is if we want to do a generic proof of possession fo
20 matches
Mail list logo
