I was hoping to avoid needing str_replace -- but I've been convinced. I'm
happy with base64url :)
Thanks,
-Naitik
On Tue, Jul 6, 2010 at 9:17 PM, Evan Gilbert uid...@google.com wrote:
Hi all - having a little bit of a hard time following the full thread, but
I'm strongly in favor of base64url
scope is about the permissions that a client application is
requesting. But if those permissions are inherently bound to the users
becaus the users have certain roles, the Access Token requested for a
user can be bound to those roles by the Authorization server. I don't
feel there's a requirement
On Wed, Jul 7, 2010 at 12:57 AM, Michael D Adams m...@automattic.com wrote:
WordPress uses query parameters. A WordPress plugin that enables
OAuth, though, would have to register new URL handlers with WordPress
to act as the token and end-user authorization endpoints. Having done
so, the
+1 on reference to section 2. Also, in 4.1.1, the wording in the last
paragraph makes it sound like the client_secret is REQUIRED for flows
using the authorization code, when as per section 2 the secret is only
required IF a secret was issued with the client_id. Wording such as
found in 4.1.2 is a
Hi folks -
What is the story with the evolution of the assertion profile?
As far as I can tell, it keeps changing for no good reason. Everyone who
wants to implement the profile has the exact same requirements, and
agreed on how it should work a long time ago.
Here's the timeline:
- a bunch
The issue is that it is hard (or even impossible) to prevent another user-agent
client from imitating another user-agent client. A pre-registered redirection
URI does very little to help. In most cases, such a URI will point to a web
page with a script that will extract the information and pass
On Wed, Jul 7, 2010 at 12:47 PM, Eran Hammer-Lahav e...@hueniverse.com wrote:
The issue is that it is hard (or even impossible) to prevent another
user-agent client from imitating another user-agent client. A pre-registered
redirection URI does very little to help. In most cases, such a URI
Thanks. Browser security is not my area.
It seems to me that this must be documented as all the examples I have seen for
such scripts did not include any such security measures.
EHL
On 7/7/10 1:06 PM, m...@automattic.com m...@automattic.com wrote:
On Wed, Jul 7, 2010 at 12:47 PM, Eran
On Wed, Jul 7, 2010 at 1:08 PM, Eran Hammer-Lahav e...@hueniverse.com wrote:
It is pretty much the same as originally proposed. Any recent changes are an
oversight, not any intentional change. Since it was proposed, the only
change made (with full consensus) was to allow client authentication
I don't have time to go dig through the list archive.
On 7/7/10 2:02 PM, Brian Eaton bea...@google.com wrote:
On Wed, Jul 7, 2010 at 1:08 PM, Eran Hammer-Lahav e...@hueniverse.com wrote:
It is pretty much the same as originally proposed. Any recent changes are an
oversight, not any
On Wed, Jul 7, 2010 at 2:18 PM, Eran Hammer-Lahav e...@hueniverse.com wrote:
On 7/7/10 2:02 PM, Brian Eaton bea...@google.com wrote:
Can you point me to the e-mail threads that reached consensus on using
client authentication?
This was requested a few months ago and was included in -05 as
I disagree with this approach. There are plenty of optional parameters in the
spec.
The assertion access grant requires further profiling to be useful. This
doesn't mean it needs another spec, but that when you use it, you need to
document clearly what is expected. When you do that, spell out
On Wed, Jul 7, 2010 at 2:52 PM, Eran Hammer-Lahav e...@hueniverse.com wrote:
I disagree with this approach. There are plenty of optional parameters in
the spec.
Yes. I think most of them are a bad idea.
The assertion access grant requires further profiling to be useful. This
doesn’t mean it
On 7/7/10 3:01 PM, Brian Eaton bea...@google.com wrote:
On Wed, Jul 7, 2010 at 2:52 PM, Eran Hammer-Lahav e...@hueniverse.com wrote:
I disagree with this approach. There are plenty of optional parameters in
the spec.
Yes. I think most of them are a bad idea.
The assertion access grant
This thread forced a great deal on internal discussion today, and we
actually do have some more immediate use-cases where we'll require
client_id with the assertion flow
I support leaving it as optional
-cmort
On Wednesday, July 7, 2010, Brian Eaton bea...@google.com wrote:
On Wed, Jul 7, 2010
On Wed, Jul 7, 2010 at 4:51 PM, Chuck Mortimore
cmortim...@salesforce.com wrote:
This thread forced a great deal on internal discussion today, and we
actually do have some more immediate use-cases where we'll require
client_id with the assertion flow
I support leaving it as optional
Can you
Hi,
I just wanted to follow up and see if I could solicit a bit more
feedback on this request, since it sounds like the end of the OAuth 2
spec is growing near and I would like to see something added to resolve
this problem if at all feasible (or suggestions on how else to deal with
it;
BTW, I'm not opposed to writing more detailed profiles based on the generic
framework provided by the two endpoints defined and theyr many optional
components. I think the new format helps clarify the overall architecture and
easier to implement a generic client for (given that all the
18 matches
Mail list logo
