> 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
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
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
