; Tim Bray ;
IETF oauth WG
*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 eran said the token in
oauth1 (which is inside the oauth1 spec) had many impl
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 another
: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 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
_
From: Justin Richer mailto:jric...@mitre.org>>
To: Tim Bray mailto:twb...@google.com>>
Cc: William Mills mailto:wmills_92...@yahoo.com>>; IETF
oauth WG mailto:oauth@ietf.org>>
Sent: Friday, February 15, 2013 12:54 PM
Subject: Re: [OAUTH-WG] Minutes from the OAuth
t;> capabilites that OAuth 2 does not provide. Simply stating "move to HTTPS"
>> is not a viable response here.
>>
>> From: Torsten Lodderstedt
>> To: William Mills
>> Cc: Mike Jones ; Justin Richer
>> ; Phil Hunt ; IETF oauth WG
>>
iable
response here.
>
>
>
>
> From: Torsten Lodderstedt
>To: William Mills
>Cc: Mike Jones ; Justin Richer
>; Phil Hunt ; IETF oauth WG
>
>Sent: Friday, February 15, 2013 7:22 AM
>Subject: Re: [OAUTH-WG] Minutes from the OAu
t up again.
From: Sergey Beryozkin
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 completed
iam Mills
> *Cc:* Mike Jones ; Justin Richer <
> jric...@mitre.org>; Phil Hunt ; IETF oauth WG <
> oauth@ietf.org>
> *Sent:* Thursday, February 14, 2013 10:05 PM
> *Subject:* Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference
> Call - 11th February 2013
>
&
TTPS" is not a viable response here.
*From:* Torsten Lodderstedt
*To:* William Mills
*Cc:* Mike Jones ; Justin Richer
; Phil Hunt ; IETF oauth WG
*Sent:* Friday, February 15, 2013 7:22 AM
*Subject:* Re: [OAUTH-WG] Minutes from the OAuth Design T
icher ; IETF oauth WG
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 objecting to https in the as communications correct? It is the rs
comms which is plain http where you want to p
tin Richer
> ; Phil Hunt ; IETF oauth WG
>
> 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 t
; Justin Richer
; Phil Hunt ; IETF oauth WG
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
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
Remember that proof of possession is intended to prove that the client that was
issued the token is the one presenting it.
We tend to mix that up with replay and other protection issues.
To do this you don't need to authenticate the client.
The client can prove it controls a key by signing s
-- 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: [OA
t;Sent: Thursday, February 14, 2013 1:44 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 sc
was the impediment to OAuth 1.0 adoption that OAuth 2.0 solved
> in the first place.
>
> -- 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
ain text HTTP. 1.0a solved that.
From: Mike Jones
To: Justin Richer ; Phil Hunt
Cc: IETF oauth WG
Sent: Thursday, February 14, 2013 1:44 PM
Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call -
11th February 2013
I'm in favo
-- 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 m
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 imp
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 achie
Regarding the question of AS to RS communication, I think capturing it
is a reasonable task but not one essential to this activity.
So my view would be to exclude it from consideration in this groups
activity. We have many use-cases where support for confirmation that goes
beyond the currently
On 02/14/2013 02:45 AM, Hannes Tschofenig wrote:
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
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 differen
You have a trust relationship with the user and perhaps with the client.
From: Prateek Mishra
To: oauth@ietf.org
Sent: Wednesday, February 13, 2013 8:13 AM
Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call -
11th February 2013
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) R
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 stuffi
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.
P
lf contained then.
>
> From: Hannes Tschofenig
> To: William Mills
> Cc: Hannes Tschofenig ; IETF oauth WG
>
> 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,
ls
; IETF oauth WG
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 the authorization server is described in
Section 5.1 and is called "mac_key".
The mechan
at we do NOT duplicate any HTTP info into the
>>>> JSON. Just signatures of that stuff.
>>>>
>>> I believe the folks on the call also agreed with you on that aspect that
>>> the content of the HTTP message should not be replicated in the JSON
>>> pay
that aspect that the
>> content of the HTTP message should not be replicated in the JSON payload
>> itself.
>>
>> Ciao
>> Hannes
>>
>>> From: Hannes Tschofenig
>>> To: IETF oauth WG
>>> Sent: Tuesday, February 12, 2013 1:10 AM
&g
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:
http://www.tschofenig.priv.at/OAuth2-S
the
> content of the HTTP message should not be replicated in the JSON payload
> itself.
>
> Ciao
> Hannes
>
>> From: Hannes Tschofenig
>> To: IETF oauth WG
>> Sent: Tuesday, February 12, 2013 1:10 AM
>> Subject: [OAUTH-WG] Minutes from the OAuth Des
contained then.
From: Hannes Tschofenig
To: William Mills
Cc: Hannes Tschofenig ; IETF oauth WG
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 12, 2013, at 11
he JSON payload
itself.
Ciao
Hannes
> From: Hannes Tschofenig
> To: IETF oauth WG
> 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:
>
ON.
Just signatures of that stuff.
From: Hannes Tschofenig
To: IETF oauth WG
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 Bradl
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 discussio
38 matches
Mail list logo
