Yeah!
On 2010-07-06, at 11:12 PM, Naitik Shah wrote:
> 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 wrote:
> Hi all - having a little bit of a hard time following t
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 wrote:
> Hi all - having a little bit of a hard time following the full thread, but
> I'm strongly in favor of base64url encoding.
>
> A
On Tue, Jul 6, 2010 at 10:18 PM, Michael D Adams wrote:
>>> If there are actual requirements for using OAuth 2.0 with such systems, we
>>> should discuss these, but it would be silly for us to architect our work
>>> based on the limitations of random platforms.
>>
>> I don't think these are random
On Tue, Jul 6, 2010 at 12:49 PM, Andrew Arnott wrote:
> If we can agree that it is useless from a security perspective (and I think
> we agree on that by now),
I don't think this is useless. As Evan mentioned, a JavaScript client
could register and provide a redirect_uri (or redirect_uri pattern)
>> If there are actual requirements for using OAuth 2.0 with such systems, we
>> should discuss these, but it would be silly for us to architect our work
>> based on the limitations of random platforms.
>
> I don't think these are random at all. MediaWiki, Drupal, WordPress,
> to name a few, are ma
On Tue, Jul 6, 2010 at 11:23 AM, Eran Hammer-Lahav wrote:
> Platforms change over time. These platforms are not designed with providing
> APIs and web services in mind. They are also typically not capable of
> running over SSL (due to the self-hosted nature of most deployments). Using
> an apache
On Sat, Jul 3, 2010 at 3:27 AM, Rob Richards wrote:
> Eran Hammer-Lahav wrote:
>>
>> Hi Rob,
>>
>> I agree with you that a migration spec is important - please write one.
>>
>
> Like I didn't see that coming :)
I would like to help with this migration spec. Is this a good starting point:
http://w
On Tue, Jul 6, 2010 at 12:49 PM, Andrew Arnott wrote:
> If we can agree that it is useless from a security perspective (and I think
> we agree on that by now), then an auth server must not ever issue an access
> token to a user agent client without interacting with the user (no
> "immediate" mode
Hi all - having a little bit of a hard time following the full thread, but
I'm strongly in favor of base64url encoding.
A big advantage of this encoding is that, if token is base64url encoded,
then urlencode(token) == token.
This allows developers to avoid a large class of problems in dealing wit
How the client authenticates itself is covered in section 2, and
client_id plus client_secret in 2.1.
The first paragraph of section 4 mentions this in a general way, but I
think an explicit pointer to section 2 would help.
Regarding the last paragraph of 4.1.1, since it explains the example,
it
James, in theory I agree with you that we should use the authorization header.
Unfortunately the reality of how implementations work prevent that as a viable
option. So for corporate scenarios where we need SAML we will have to put the
parameters into the request body. I do not see a viable way
Responses below.
On Jul 6, 2010, at 2:23 PM, Brian Eaton wrote:
> On Tue, Jun 22, 2010 at 11:00 PM, Luke Shepard wrote:
>> Two points:
>>
>> 1/ I agree that it can be onerous for clients to host web pages. It's not a
>> matter of expense but of complexity.
>>
>> BUT
>>
>> 2/ As we discussed
On Tue, Jun 22, 2010 at 11:00 PM, Luke Shepard wrote:
> Two points:
>
> 1/ I agree that it can be onerous for clients to host web pages. It's not a
> matter of expense but of complexity.
>
> BUT
>
> 2/ As we discussed previously in our in-person meeting, this should be
> handled by a different e
There are known issues with using cookies and other passive authentication
measures, and we should document them. However, this all depends on the
security needs of the service, and these patterns are already deployed in
services such as FB. It would be useful to find out how they address these
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org]
> On Behalf Of Justin Richer
> Sent: Tuesday, July 06, 2010 11:10 AM
> To: Eran Hammer-Lahav
> Cc: OAuth WG
> Subject: Re: [OAUTH-WG] register prefixes as opposed to full
> parameter names
>
> > > When re
If we can agree that it is useless from a security perspective (and I think
we agree on that by now), then an auth server must not ever issue an access
token to a user agent client without interacting with the user (no
"immediate" mode issuing of access tokens) so the user is aware that some
anonym
Platforms change over time. These platforms are not designed with providing
APIs and web services in mind. They are also typically not capable of running
over SSL (due to the self-hosted nature of most deployments). Using an apache
rewrite rules might be hard for some developers, but it is a goo
> > When receiving an OAuth request MediaWiki will have two title parameters,
> > the damage is already done.
>
> Yes, they might need to change their platform to support it. I'm ok with that.
I think this is an unfortunate hubris of the spec-defining community
here. For most people, if it comes
Thanks Eran,
Best regards,
Diogo Almeida
On Jul 6, 2010, at 3:03 PM, Eran Hammer-Lahav wrote:
>
>
>
>
> On Jul 3, 2010, at 7:50, Diogo Almeida wrote:
>
>> Good afternoon,
>>
>> I would like to ask the WG two questions regarding -09
>>
>> 1)
>> On section 3.1, regarding the scope paramete
On Jul 3, 2010, at 7:50, Diogo Almeida wrote:
> Good afternoon,
>
> I would like to ask the WG two questions regarding -09
>
> 1)
> On section 3.1, regarding the scope parameter, it reads:
>
> code
> REQUIRED if the response type is "token" or "code-and-token", otherwise MUST
> NOT be inc
Um, this is reasonably common Mailman behavior (admittedly less common
than the alternative), and the signup page warns you about it:
You may enter a privacy password below. This provides only mild
security, but should prevent others from messing with your
subscription. Do not use a valuable passw
I just noticed that every month the list administration system sends out an
email that includes the password to my account on this system. Obviously
this is a huge security issue. I am a member of around fifteen lists and
this is the only one that does this. I hope it can be resolved.
Thanks.
Hank
Hello David,
Just a small note: if such change was made I believe it would also have to be
reflected on section 4.2 (draft 09), in order to have a coherent scope
parameter.
Best regards,
Diogo Almeida
On Jul 5, 2010, at 5:46 PM, David Recordon wrote:
> Seems like adding, "It's RECOMMENDED tha
Sorry to repost this mail to the WG. However, we're still looking for feedback
on these two issues for our provider implementation.
PS: There was a typo in my first question. Where it reads: "On section 3.1,
regarding the scope parameter" it should read: "On section 3.1, regarding the
code para
24 matches
Mail list logo
