Needs JOSE npm lib. Easiest thing to do is just install it in a temp working dir.
cd /tmp
npm i jose
node
Inside the REPL:
#include <ESP8266WiFi.h> | |
#include <WiFiClient.h> | |
#include <ESP8266WebServer.h> | |
#define SENSOR A0 | |
#define DIGI_SENSOR D5 | |
#define PUMPOUT D6 | |
/* Set these to your desired credentials. */ | |
const char *ssid = ""; //Enter your WIFI ssid | |
const char *password = ""; //Enter your WIFI password |
Can we use a combination of Payment Request API and WebAuthN API to get Transaction Confirmation (Dynamic Linking)?
Transaction Confirmation (TxConf) is a feature of FIDO that guarantees to the Relying Party (RP) that the user saw the same transaction details that are signed by their authenticator, i.e. WYSIWYS (What You See Is What You Sign)
In the absence of TxConf an authenticator can ONLY assert that a challenge (generated by the RP to prevent replays) was signed inside the authenticator at the consent of the user (who provided the neccessary gesture to "unlock" the authenticator, e.g. biometric scan, PIN etc).
import { Duplex } from 'stream' | |
export class Requestor { | |
private _map = new Map<number, (reply: string) => void>() | |
private _nextCorrelationId = 1 | |
private _stream: Duplex | |
constructor (stream: Duplex) { | |
this._stream = stream | |
this._stream.on('data', (chunk: any) => { |
The Interledger is a network of interconnected payment networks operating under a universal address space. To send a payment over the Interledger a sender has some practical prerequisites they must meet:
For the majority of use cases, an Interledger payment will originate from, and terminate at, an entity that is on the limits of the network graph. That entity may have more than a single connection to other nodes but will not be operating as an intermediary node. For clarity the node(s) that this entity connects to is/are defined as an Interledger Service provider (ILSP).
The ILSP provides services to senders and receivers that allow them to send and receive payments via ILP without needing to be fully functioning ILP nodes. These services include one or more of:
The W3C Web Payments working group have published a specification for web-based payment apps, web applications that can handle Payment Requests from other web applications.
The Editor's Draft (latest version) of the specification for the Payment Handler API is at https://w3c.github.io/payment-handler/
Thus far only Google have implemented this specification in the latest version of Chrome Canary for Android. Other browsers are expected to follow.
There is a rudimentary example of a web-based payment app here: https://github.com/madmath/payment-request-show/tree/master/bobpay/public/pay
Assuming https://example.com/
is ILP Kit URL
POST {"username": "", "password": "" }
to https://example.com/api/auth/login
inspect response.headers.set-cookie and use as cookie for future requests
POST {“destination”:“<SPSP Endpoint URL>”,“sourceAmount”:null,“destinationAmount”:“<Amount>”}
to https://example.com/api/payments/quote
I hereby claim:
To claim this, I am signing this object:
ILP and the various higher-level protocols depend on extensive messaging between components. It's important for the messaging protocols to be well defined in order to ensure interoperability.
This includes both the logical data model and the serialization.
ILP requires the following messaging channels and messages:
Client <-> Ledger
-> Request Ledger info
Response to thread on zCash forums:
Hi Zooko,
Adrian here from the Interledger Project. The use case you describe is exactly the one we're trying to address with Interledger. Thanks Brett Carter for pointing me to this thread.
Ito interoperability, Interledger takes the approach of providing a protocol for inter-networking payment networks (in a similar manner to how IP solves for inter-networking between data networks). So rather than trying to provide any features that should be ledger/network specific Interledger simply addresses "How can value be transferred from an account on one ledger to an account on another, reliably?" It is completely ledger agnostic and actually very very simple.
The protocol depends on Conditional Payments on each network, however it is possible to work around this if the two pa