is not compatible with the specification language, but this is just
terminology and has little to no practical implications.
EHL
*From:* Phil Hunt [mailto:phil.h...@oracle.com]
*Sent:* Monday, February 07, 2011 10:16 AM
*To:* Eran Hammer-Lahav
*Cc:* Dirk Balfanz; Manger, James H; OAuth WG
On Sun, Feb 6, 2011 at 4:26 AM, Manger, James H
james.h.man...@team.telstra.com wrote:
Dirk said:
FWIW, I agree with Brian - it [the “Bearer” scheme] should say OAuth
somewhere, because it's an OAuth token.
OAuth can deliver any variety of bearer token: SAML, JWT, SWT, opaque id,
FWIW, I agree with Brian - it should say OAuth somewhere, because it's an
OAuth token. My vote would be for OAuth2 for bearer tokens, and OAuth2Signed
for MAC tokens, for all the backward-compatibility issues with oauth_bearer,
etc.
Dirk.
On Fri, Feb 4, 2011 at 12:07 AM, Eran Hammer-Lahav
of negotiation protocol then could take that up at a later time, I
know its not the best but we need to be able to support the government
endorsed algorithms
*From:* Dirk Balfanz [mailto:balf...@google.com]
*Sent:* Wednesday, October 06, 2010 2:26 PM
*To:* Anthony Nadalin
*Cc:* Yaron Goland; Mike
...@microsoft.comwrote:
I don’t believe that negotiation (policy) has to be part of this
proposal, so in the spec if one of the claims is not supported then the
token MUST not be processed. We have this today in the web services security
stack and there are really no issues.
*From:* Dirk Balfanz
:* Wednesday, September 29, 2010 8:34 AM
*To:* Dirk Balfanz; Mike Jones
*Cc:* oauth@ietf.org
*Subject:* Re: [OAUTH-WG] Comparing the JSON Token drafts
So this one I do feel more strongly about: We should only include crypto
mechanisms that everybody MUST support. Otherwise, we'll have to invent
within the request (as is the case here). Recent experience shows
that with a little help and good libraries, developers can figure out how to
normalize and sign an HTTP request successfully, when motivated.
EHL
On 9/23/10 7:07 PM, Dirk Balfanz balf...@google.com wrote:
On Thu, Sep 23, 2010
Hi guys,
sorry it took a while, but here is an updated proposal. It's still in three
parts:
Part I is about JSON Tokens that can be used for all sorts of things, not
just OAuth:
http://balfanz.github.com/jsontoken-spec/draft-balfanz-jsontoken-00.html
Part II is about how to embed an OAuth token
/10 3:39 PM, Dirk Balfanz balf...@google.com wrote:
Hi guys,
sorry it took a while, but here is an updated proposal. It's still in three
parts:
Part I is about JSON Tokens that can be used for all sorts of things, not
just OAuth:
http://balfanz.github.com/jsontoken-spec/draft-balfanz
On Tue, Jul 27, 2010 at 4:31 PM, Nat Sakimura sakim...@gmail.com wrote:
Hi.
Currently, the discovery document would have something like:
{
verification_keys: {
key1:RSA.ALqcwR...,
key2:X509.certificate
}
}
It defines RSA and X509. Could we
On Tue, Jul 27, 2010 at 3:35 PM, Nat Sakimura sakim...@gmail.com wrote:
On Wed, Jul 28, 2010 at 1:12 AM, Dirk Balfanz balf...@google.com wrote:
On Tue, Jul 27, 2010 at 12:34 AM, Nat Sakimura sakim...@gmail.com
wrote:
I have a fundamental question.
While separating signature
On Wed, Jul 21, 2010 at 1:26 AM, Nat Sakimura sakim...@gmail.com wrote:
Hi Dirk,
Inline:
On Tue, Jul 20, 2010 at 9:22 AM, Dirk Balfanz balf...@google.com wrote:
On Sun, Jul 18, 2010 at 8:20 AM, Torsten Lodderstedt
tors...@lodderstedt.net wrote:
Hi Dirk,
I have some questions
of if it
was encrypted or not.
Perhaps the first string would always be an envelope that would contain
everything to either decrypt or verify the payload?
-- Dick
On 2010-06-22, at 10:57 PM, Dirk Balfanz wrote:
Hi Dick,
interesting point about encrypted payloads.
People more cryptographically-inclined than
On Tue, Jul 13, 2010 at 7:18 AM, Eran Hammer-Lahav e...@hueniverse.comwrote:
From the client's perspective, they are 'shared symmetric secrets' because
the client has to store them as-is and present them as-is. The act exactly
like passwords. I added that text to make that stand out.
When
On Wed, Jul 7, 2010 at 7:49 PM, Eran Hammer-Lahav e...@hueniverse.comwrote:
Can we get an updated document based on the feedback received?
Sure - I just got back from my vacation. I'll read through the thread and
update the docs.
Cheers,
Dirk.
EHL
On 6/21/10 12:04 AM, Dirk Balfanz
Hi guys,
I think I owe the list a proposal for signatures.
I wrote something down that liberally borrows ideas from Magic
Signatureshttp://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-magicsig-00.html,
SWT http://groups.google.com/group/WRAP-WG/files, and (even the name from)
JSON Web
On Mon, Jun 21, 2010 at 4:18 AM, Ben Laurie b...@google.com wrote:
On 21 June 2010 08:04, Dirk Balfanz balf...@google.com wrote:
Hi guys,
I think I owe the list a proposal for signatures.
I wrote something down that liberally borrows ideas from Magic
Signatures,
SWT, and (even the name
, we
need to sign the body.
For this, I somehow feel that Magic Signatures is more interoperable
since it actually sends the armored ASCII strings with it.
=nat
On Mon, Jun 21, 2010 at 8:18 PM, Ben Laurie b...@google.com wrote:
On 21 June 2010 08:04, Dirk Balfanz balf...@google.com wrote
-bidirectional [Feb 2010]
--
James Manger
Am 08.06.2010 22:23, schrieb Dirk Balfanz:
Hi guys,
currently, we specify how polling should work in the device flow as part
of
the OAuth2 spec.
I would argue that that polling should be handled at a lower layer
Hi guys,
currently, we specify how polling should work in the device flow as part of
the OAuth2 spec.
I would argue that that polling should be handled at a lower layer of the
stack, and that OAuth2 should be silent on the issue of polling. The benefit
will be a simpler spec.
HTTP specifies the
is worthless and
usually blank, authenticate/sign their own requests?
--
Andrew Arnott
I [may] not agree with what you have to say, but I'll defend to the death
your right to say it. - S. G. Tallentyre
On Thu, May 20, 2010 at 4:39 PM, Dirk Balfanz balf...@google.com wrote:
Hi guys,
at today's
secret for generating signatures.
(forgive me if this was already discussed today - I was very zonked out
after 3 days of IIW)
Thanks
Allen
On Thu, May 27, 2010 at 9:41 AM, Dirk Balfanz balf...@google.com wrote:
Sorry, I didn't mean to turn this into a debate over whether we should
have
to the SP.
Does that clarify things?
Allen
On 5/27/10 9:04 AM, Dirk Balfanz balf...@google.com wrote:
On Thu, May 27, 2010 at 8:56 AM, David Recordon record...@gmail.com
wrote:
I thought Allen clearly said that signing with the client secret won't work
for Yahoo!?
Right - but he also said
(as detailed
below)
but makes the overall use case of using signed tokens more complicated to
follow, as it'd be split in two.
-- justin
From: oauth-boun...@ietf.org [oauth-boun...@ietf.org] On Behalf Of Dirk
Balfanz [balf...@google.com
to build
an LoA2 or LoA3 auth protocol on top of OAuth2, that's not good enough.
Dirk.
One could use another PR-specific client-secret to sign PR requests. But
that's out of OAuth2-scope, from my point of view.
regards,
Torsten.
Am 21.05.2010 01:39, schrieb Dirk Balfanz:
Hi guys
as the original Client has told
the Server that they're sub-delegating to that particular sub-delegatee.
Only the first of those is possible with token-secret-signatures. All three
are possible with client-secret signatures.
Dirk.
On Friday, May 21, 2010, Dirk Balfanz balf...@google.com wrote
On Thu, May 20, 2010 at 11:34 PM, Eran Hammer-Lahav e...@hueniverse.comwrote:
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Dirk Balfanz
Sent: Thursday, May 20, 2010 4:39 PM
To: OAuth WG
Subject: [OAUTH-WG] proposal
because of deployers who do
not wish for their protected resources to have access to client secrets.
--David
On Thu, May 20, 2010 at 4:39 PM, Dirk Balfanz balf...@google.com wrote:
Hi guys,
at today's interim meeting, we were discussing Brian Eaton's proposal for
OAuth signatures. He
Hi guys,
at today's interim meeting, we were discussing Brian Eaton's proposal for
OAuth signatures. He was proposing a mechanism that would (1) do away with
base string canonicalization, (2) allow for symmetric and public keys, and
(3) allow for extensibility.
He got homework from the group to
29 matches
Mail list logo
