Hi,
Some comments on this:
- although we're still waiting for a final confirmation, we will very
likely adopt Oauth 2.0 as the solution for identifying/authenticating
users instead of BrowserID. This means that automatically "sending" the
identity information on step 3 depends on the use of sessio
S COLOMA BAIGES"
Cc: dev-...@lists.mozilla.org, "Fernando Jiménez" ,
dev-security@lists.mozilla.org, "Andreas Gal" , "DAVID LOZANO
LLANOS"
Sent: Thursday, August 16, 2012 11:50:02 AM
Subject: Re: [b2g] Privacy concerns with navigator.pay
On Thu, Aug 16, 2012 a
> Note that I'm not proposing an additional confirmation by Gecko. I'm
> proposing that we replace the confirmation UI displayed by BlueVia in
> step 3 of the original flow, with a confirmation UI displayed by
> Gecko. So from the user's point of view it's almost exactly the same
> behavior.
Also
> Note that this approach requires us to standardize the JWT, whereas serving
> the "UI" from the payment provider does not. That is definitely an added
> protocol risk. I would love to standardize the JWT down the road, but its
> easier and more extensible if we can punt on that initially. It
On 17/08/2012, at 02:15, Jonas Sicking wrote:
>>> I'm a bit confused as to what you are proposing since you are
>>> commenting on the user-flow in my counter proposal. Did you intend for
>>> this comment to be in response to step 3 in the original flow?
>>
>> Sorry, I was referring to step 6 of
Note that this approach requires us to standardize the JWT, whereas serving the
"UI" from the payment provider does not. That is definitely an added protocol
risk. I would love to standardize the JWT down the road, but its easier and
more extensible if we can punt on that initially. It also mea
On Thu, Aug 16, 2012 at 7:52 AM, Fernando Jiménez wrote:
>> Yup. I'm aware of this. It's definitely somewhat worrying, but it
>> seems to me like it should work as long as the JWT request is signed
>> rather than encrypted with the developer key.
>>
>> It could result in the situation when the use
On Aug 16, 2012, at 12:50 PM, Jonas Sicking wrote:
> On Thu, Aug 16, 2012 at 3:06 AM, DANIEL JESUS COLOMA BAIGES
> wrote:
>> Hi,
>>
>> The bottom line is that we need a decision today, whatever that decision is.
>> We are moving back and forth continuously (the protocol was suggested late
>> J
Hi,
On 16/08/2012, at 13:41, Jonas Sicking wrote:
> Don't we have the freedom to impose what JWTs that we are willing to
> funnel between the website and the payment provider? I.e. can't we
> require that the JWT contains human readable descriptions?
Yes, we do have that freedom. That's why I wa
On Thu, Aug 16, 2012 at 2:16 AM, Fernando Jiménez wrote:
>>> It seems like we can get a very similar UX experience with the same
>>> number of clicks using a flow like:
>>>
>>> 1. User visits website.
>>> 2. Website calls navigator.pay and provides a JWT-encoded request
>>> which contains informat
On Thu, Aug 16, 2012 at 1:29 AM, Andreas Gal wrote:
>
> On Aug 16, 2012, at 1:13 AM, Jonas Sicking wrote:
>
>> Hi All,
>>
>> While looking at the navigator.pay API, there's one privacy concern that I
>> had.
>>
>> As the API is currently intended to use, the flow is something like
>> the followi
On Thu, Aug 16, 2012 at 3:06 AM, DANIEL JESUS COLOMA BAIGES
wrote:
> Hi,
>
> The bottom line is that we need a decision today, whatever that decision is.
> We are moving back and forth continuously (the protocol was suggested late
> June) and that is something we cannot afford.
Given that we h
Hi,
The bottom line is that we need a decision today, whatever that decision is.
We are moving back and forth continuously (the protocol was suggested late
June) and that is something we cannot afford.
Thanks!
On Aug 16, 2012, at 11:16 AM, Fernando Jiménez wrote:
> Hi,
>
> as I already said
Hi,
as I already said via IRC, FWIW this looks to me more like a BlueVia identity
protocol issue than a payment protocol issue. The privacy issue that you
mention would not happen for other payment providers, unless these payment
providers implement a similar identity protocol. The login infor
On Aug 16, 2012, at 1:13 AM, Jonas Sicking wrote:
> Hi All,
>
> While looking at the navigator.pay API, there's one privacy concern that I
> had.
>
> As the API is currently intended to use, the flow is something like
> the following:
>
> 1. User visits website.
> 2. Website calls navigator.
15 matches
Mail list logo
