...@yahoo.com
*Cc:* Justin Richer jric...@mitre.org; Tim Bray twb...@google.com;
IETF oauth WG oauth@ietf.org
*Sent:* Friday, February 15, 2013 11:22 PM
*Subject:* Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference
Call - 11th February 2013
I don't see oauth1 tokens as a short cut because
Who has a rather detailed description about the three key distribution
machanisms?
Please tell me if I am wrong in understanding them only from the ppt and
previouse mac and hotk document:
1. The key distributuon means AS distributing a short-term-key to client
and RS;
2. AS and RS has
: Thursday, February 14, 2013 10:05 PM
Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call -
11th February 2013
Hi Bill,
OAuth 2.0 took a different direction by relying on HTTPS to provide the basic
protection. So the need to have a token, which can be used for service
John - two separate issues here -
(i) for the symmetric key case, whether we need a key distribution
method for the client and AS/RS, and if so, what form should it take?
(ii) asymmetric case is quite different, I agree with your point - the
client could be pre-provisioned with a managed key
...@yahoo.com
Cc: Mike Jones michael.jo...@microsoft.com; Justin Richer
jric...@mitre.org; Phil Hunt phil.h...@oracle.com; IETF oauth WG
oauth@ietf.org
Sent: Friday, February 15, 2013 7:22 AM
Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call -
11th February 2013
Hi Bill,
I
michael.jo...@microsoft.com; Justin Richer
jric...@mitre.org; Phil Hunt phil.h...@oracle.com; IETF oauth WG
oauth@ietf.org
Sent: Friday, February 15, 2013 7:22 AM
Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call -
11th February 2013
Hi Bill,
I think one
Lodderstedt tors...@lodderstedt.net; Mike Jones
michael.jo...@microsoft.com; Justin Richer jric...@mitre.org; IETF oauth WG
oauth@ietf.org
Sent: Friday, February 15, 2013 8:19 AM
Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call -
11th February 2013
Bill
You aren't
, February 15, 2013 7:22 AM
*Subject:* Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference
Call - 11th February 2013
Hi Bill,
I think one needs to compare the costs/impact of HTTPS on one side and
the implementation of integrity protection and replay detection on the
other. We had
15, 2013 7:22 AM
*Subject:* Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference
Call - 11th February 2013
Hi Bill,
I think one needs to compare the costs/impact of HTTPS on one side and the
implementation of integrity protection and replay detection on the other.
We had
.
From: Sergey Beryozkin sberyoz...@gmail.com
To: oauth@ietf.org
Sent: Friday, February 15, 2013 8:25 AM
Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call -
11th February 2013
I wonder why it is proving so difficult to get a nearly
: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call -
11th February 2013
Not deeply acquainted with the Flickr scenario, but it occurs to me to ask: If
OAuth 1.0 is working well for them, why don’t they just keep using it? I.e. if
there’s already a good solution in place
Sent: Friday, February 15, 2013 12:54 PM
Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call -
11th February 2013
So that you can fetch and manage all your tokens using the same code
paths as the OAuth2 services. The get a token part will be identical to
Oauth2
@ietf.orgmailto:oauth@ietf.org
Sent: Friday, February 15, 2013 7:22 AM
Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call -
11th February 2013
Hi Bill,
I think one needs to compare the costs/impact of HTTPS on one side and the
implementation of integrity protection and replay detection
*Subject:* Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference
Call - 11th February 2013
I wonder why it is proving so difficult to get a nearly completed MAC
draft completed ?
Is it because:
1. JWT was first in OAuth2 and thus it wins ?
2. MAC is not 'capable' enough as JWT is ?
3
Justin - my comment was scoped to *key distribution* - not to the
general use of public clients.
I was wondering how one can distribute keys or have key agreement
between an AS and a client, if there is no existing trust relationship
between them. Maybe there is some
clever crypto way of
Prateek,
My point was that a public client could very easily and safely be issued
a secret in the form of an OAuth token. This includes any type of
signing key that the MAC/etc token would want to use. What public
client's can't have are configuration-time keys, like a client_secret.
It's
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Justin Richer
Sent: Tuesday, February 12, 2013 9:35 AM
To: Phil Hunt
Cc: IETF oauth WG
Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call -
11th February 2013
That's my reading
.
-- Mike
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Justin Richer
Sent: Tuesday, February 12, 2013 9:35 AM
To: Phil Hunt
Cc: IETF oauth WG
Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call -
11th February 2013
That's
PM
Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call -
11th February 2013
I'm in favor of reusing the JWT work that this WG is also doing. :-)
I'm pretty skeptical of us inventing another custom scheme for signing HTTP
headers. That was the impediment to OAuth
Hannes,
1) Its not clear to me that we need to specify exchanges between the AS
and the RS as part of this work. The core specification leaves this
unspecified. There could be many different ways that the AS and RS
collaborate to validate signatures in messages received from the client.
2)
You have a trust relationship with the user and perhaps with the client.
From: Prateek Mishra prateek.mis...@oracle.com
To: oauth@ietf.org
Sent: Wednesday, February 13, 2013 8:13 AM
Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call
Hi Prateek,
thanks for your questions.
On Feb 13, 2013, at 6:13 PM, Prateek Mishra wrote:
Hannes,
1) Its not clear to me that we need to specify exchanges between the AS and
the RS as part of this work. The core specification leaves this
unspecified. There could be many different
Here are my notes.
Participants:
* John Bradley
* Derek Atkins
* Phil Hunt
* Prateek Mishra
* Hannes Tschofenig
* Mike Jones
* Antonio Sanso
* Justin Richer
Notes:
My slides are available here:
http://www.tschofenig.priv.at/OAuth2-Security-11Feb2013.ppt
Slide #2 summarizes earlier
signatures of that stuff.
From: Hannes Tschofenig hannes.tschofe...@gmx.net
To: IETF oauth WG oauth@ietf.org
Sent: Tuesday, February 12, 2013 1:10 AM
Subject: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th
February 2013
Here are my notes
From: Hannes Tschofenig hannes.tschofe...@gmx.net
To: IETF oauth WG oauth@ietf.org
Sent: Tuesday, February 12, 2013 1:10 AM
Subject: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th
February 2013
Here are my notes.
Participants:
* John Bradley
* Derek Atkins
* Phil
payload
itself.
Ciao
Hannes
From: Hannes Tschofenig hannes.tschofe...@gmx.net
To: IETF oauth WG oauth@ietf.org
Sent: Tuesday, February 12, 2013 1:10 AM
Subject: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th
February 2013
Here are my notes.
Participants:
* John
...@gmx.net
To: IETF oauth WG oauth@ietf.org
Sent: Tuesday, February 12, 2013 1:10 AM
Subject: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call -
11th February 2013
Here are my notes.
Participants:
* John Bradley
* Derek Atkins
* Phil Hunt
* Prateek Mishra
* Hannes
Hi Hannes, All,
On 12/02/13 09:10, Hannes Tschofenig wrote:
Here are my notes.
Participants:
* John Bradley
* Derek Atkins
* Phil Hunt
* Prateek Mishra
* Hannes Tschofenig
* Mike Jones
* Antonio Sanso
* Justin Richer
Notes:
My slides are available here:
Design Team Conference Call -
11th February 2013
Here are my notes.
Participants:
* John Bradley
* Derek Atkins
* Phil Hunt
* Prateek Mishra
* Hannes Tschofenig
* Mike Jones
* Antonio Sanso
* Justin Richer
Notes:
My slides are available here:
http://www.tschofenig.priv.at
that
the content of the HTTP message should not be replicated in the JSON
payload itself.
Ciao
Hannes
From: Hannes Tschofenig hannes.tschofe...@gmx.net
To: IETF oauth WG oauth@ietf.org
Sent: Tuesday, February 12, 2013 1:10 AM
Subject: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call
: Hannes Tschofenig hannes.tschofe...@gmx.net; William Mills
wmills_92...@yahoo.com; IETF oauth WG oauth@ietf.org
Sent: Tuesday, February 12, 2013 3:06 AM
Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call -
11th February 2013
The transport of the session key from
...@gmx.net
To: William Mills wmills_92...@yahoo.com
Cc: Hannes Tschofenig hannes.tschofe...@gmx.net; IETF oauth WG
oauth@ietf.org
Sent: Tuesday, February 12, 2013 1:44 AM
Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call -
11th February 2013
Hi Bill,
On Feb
Clarification. I think Justin and I were in agreement that we don't want to
see a format that requires JSON payloads. We are both interested in a JSON
token used in the authorization header that could be based on a computed
signature of some combination of http headers and body if possible.
That's my reading of it as well, Phil, thanks for providing the
clarification. One motivator behind using a JSON-based token is to be
able to re-use some of the great work that the JOSE group is doing but
apply it to an HTTP payload.
What neither of us want is a token type that requires
34 matches
Mail list logo
