Yes, it's on my desk and not yet ready, but I am working on one. It includes
your sites proposal among other things. I am trying to get the core spec stable
this week and focus on that next.
EHL
-Original Message-
From: Manger, James H
Sent: Monday, June 21, 2010 8:03 PM
To:
Thanks for writing this. A few questions...
Do we need both `issuer` and `key_id`? Shouldn't we use `client_id`
instead at least for OAuth?
Can we write out algorithm instead of `alg`?
How do you generate the body hash?
Does websafe-base64-encoded mean that I can't just blindly use my
btw, I wrote a very naive PHP sample. http://gist.github.com/448164
On Mon, Jun 21, 2010 at 11:03 PM, David Recordon record...@gmail.com wrote:
Thanks for writing this. A few questions...
Do we need both `issuer` and `key_id`? Shouldn't we use `client_id`
instead at least for OAuth?
Can we
Hello,
In section 1.4., “exchaning” should be “exchanging.”
In section 1.4.3., “user-agnet” should be “user-agent.”
In section 4., “support addition mechanisms” should be “support additional
mechanisms.”
And, as already mentioned on the list, “access grand type” in section 4 should
be
On 22 June 2010 02:40, Manger, James H james.h.man...@team.telstra.com wrote:
Nat and Ben,
In addition to Ben's questions, I have another. For X.509, you seem to
be using DER. How do you express the entire certificate chain using
DER?
(With PEM, you can just concatenate ... )
With
On 22 June 2010 07:03, David Recordon record...@gmail.com wrote:
Thanks for writing this. A few questions...
Do we need both `issuer` and `key_id`? Shouldn't we use `client_id`
instead at least for OAuth?
Can we write out algorithm instead of `alg`?
How do you generate the body hash?
I am working on -09 which I hope will be the last major revision of
the specification. If you were planning on submitting any feedback on
draft -08 or the simplification proposal from David and me, please do
so by tomorrow to be included in the next draft.
I am mostly looking for the
On 2010-06-21, at 11:03 PM, David Recordon wrote:
Thanks for writing this. A few questions...
Do we need both `issuer` and `key_id`? Shouldn't we use `client_id`
instead at least for OAuth?
it is the ID of the key, not the client -- used to rollover keys
Does websafe-base64-encoded mean
On Tue, Jun 22, 2010 at 7:17 AM, Dick Hardt dick.ha...@gmail.com wrote:
Thanks for writing this. A few questions...
Do we need both `issuer` and `key_id`? Shouldn't we use `client_id`
instead at least for OAuth?
it is the ID of the key, not the client -- used to rollover keys
I don't think
Having a key ID is an optimization. If you're using public key
signatures is having to do potentially 3x the signatures going to be a
problem?
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org]
On Behalf Of Brian Eaton
Sent: Tuesday, June 22, 2010
On Tue, Jun 22, 2010 at 2:36 AM, Ben Laurie b...@google.com wrote:
On 22 June 2010 07:03, David Recordon record...@gmail.com wrote:
Thanks for writing this. A few questions...
Do we need both `issuer` and `key_id`? Shouldn't we use `client_id`
instead at least for OAuth?
Can we write
Aside/my $.02: This is a key issue which Salmon+Magic Signatures
evades by essentially treating the HTTP request (the method, URL,
headers, etc.) as advisory/transport hints, to be ignored when reading
the data, and making sure the protocol works even if the data is sent
via carrier pigeon;
All of the OAuth 1.0 implementations which I'm aware of either have
the server provide a shared secret to the client or the client upload
their public key to the server.
In the case of the server providing a shared secret to the client,
what would the value of key_id be?
In the case of a client
There was a suggestion to expand the 'error' parameter to two
different parameters:
- error_code - well defined list of error codes
- error_description - authz server specific free form error
description (for logging and troubleshooting)
Not sure if you considered this.
Marius
On Mon, Jun 21,
On Tue, Jun 8, 2010 at 10:46 AM, Marius Scurtescu mscurte...@google.com wrote:
In order to properly support native applications I suggest the
following changes:
[...]
2. optional redirect_uri (default result page)
Some native apps do not have a redirect_uri, as a result two things are
One of the modifications I concluded to do to WRAP was to add in the type
parameter. I was happy to see if in David's draft.
Even though redundant in some ways, it make it very clear to both the client
and server what is intended.
+1 for putting it back in.
On Mon, Jun 14, 2010 at 11:23 AM,
Per an earlier comment, type might not be the best name for the parameter.
Perhaps method might work and adds a clear extension point for other types
of calls?
On Tue, Jun 22, 2010 at 1:22 PM, Dick Hardt dick.ha...@gmail.com wrote:
One of the modifications I concluded to do to WRAP was to add
Hey Dick, in answering my questions you made my point. If keys are
managed out of band – as is done in OAuth 1.0 and what was done in the
OAuth 2.0 Core spec until signatures were extracted – then having a
key id is not needed. I certainly understand what they're used for,
but don't find them
The only additional value might be during key rotation. If key_id is
removed, then both (or n) have to be checked. Probably not a huge issue.
Thanks,
George
On 6/22/10 4:45 PM, David Recordon wrote:
Hey Dick, in answering my questions you made my point. If keys are
managed out of band -- as
It was proposed as part of the device or username and password flow IIRC.
Google has something like that when captcha breaks.
EHL
-Original Message-
From: David Recordon [mailto:record...@gmail.com]
Sent: Tuesday, June 22, 2010 1:47 PM
To: Eran Hammer-Lahav
Cc: Marius Scurtescu;
You are a bit behind. -08 added it back as grant_type which works better with
the current explanation.
EHL
From: Dick Hardt [mailto:dick.ha...@gmail.com]
Sent: Tuesday, June 22, 2010 1:29 PM
To: Brian Eaton
Cc: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Draft -07
On Tue, Jun 22, 2010 at 3:14 PM, Eran Hammer-Lahav e...@hueniverse.com wrote:
In OAuth 1.0a, we needed it for the patch. I don't think this needs to be in
the spec because it doesn't help interop. If the server supports such a
scheme, it should document it. It also falls under previously
On Tue, Jun 22, 2010 at 4:07 PM, Eran Hammer-Lahav e...@hueniverse.com wrote:
-Original Message-
From: Marius Scurtescu [mailto:mscurte...@google.com]
Sent: Tuesday, June 22, 2010 3:35 PM
To: Eran Hammer-Lahav
Cc: OAuth WG (oauth@ietf.org)
Subject: Re: native app support (was: Next
In that case, I suggest an extension. But I just don't think this needs it. Why
involve the server at all in this? The client should just host a web page
somewhere with the format it wants or the language for the user.
With $10 hosting, every client can host a web page somewhere.
EHL
RFC4648 The Base16, Base32, and Base64 Data Encodings
defines web-safe base64 (and normal base64)
http://tools.ietf.org/html/rfc4648#section-5.
The spec suggests calling it base64url.
The spec explicitly states that:
in some circumstances, the use of padding (=)
in base-encoded data is not
Sounds like it's already in for -09 but I'd still like to voice my support
for some kind of optional parameter like error_description.
I'm working on a draft profiling a specific use of SAML in the assertion
grant_type flow (coming soon to this list I hope) and added in an
error_detail parameter
26 matches
Mail list logo
