5G NR, CA, e-Receipt, DIL, Ed448, SSL3, Matrix, Outlook
5G NR, CA, e-Receipt, DIL, Ed448, SSL3, Matrix, Outlook
- Checked out 5G NR / mmWave technology articles quickly. Lot more bandwidth for places where it's needed. See: 5G NR frequency bands @ Wikipedia.
- Studied national root certificates (CA) in several European countries. It seems that there is no root CA chains being used. ICAO PKD is being used for official keys used to sign documents like e-passport data. Found national public key from the ldif data and imported it successfully.
- Studied latest version of eReceipt technical implementation documentation. Standardized structured machine-readable data entity. standard eAddress and indentification method and transport for eReceipts. Federated solution, using four-corner model where the seller and the buyer can use different eReceipt operators. Payments and receipts are kept separate, allowing any payment method to be used with eReceipts. Will be suitable for B2C and B2B situations. Lost of costs savings, when paper receipts aren't necessary anymore and processes can be automated. Great advances on data analytics side, when data is easily available. Also archiving warranty receipts becomes much easier. Receipts can be easily formatted for speciality groups, like elderly, visually impaired and so on. Information can be automatically forwarded and routed to required destinations, no need for manual forwarding. EDI ID (SO 6523) are used for routing. PSD2 payment services are used. eReceipt format is based on Finance Finland Finvoice data version 3.0 or newer requirements with specific extensions. eReceipts will be delivere in quasi-real-time. All systems must comply with GDPR and EDPB guidelines. eReceipts cannot contain pictures. Mobile Payments are also supported. Automated processing in the financial, travel, purchase invoice, accounting, payment and cost management systems (FMS). Under users uses mobile service application. Additional information can be supplemented like Cost center, Project number, Label / Reason, participants, passengers, etc. Of course it's also possible to photograph an "import" paper based receipts to the system. Receipts aren't encrypted, key management would be problematic. It's optional to use external authentication services, authentication can done using single-way public encryption check. Purpose of this is to guarantee receipts immutability and prevent intentional or unintended alterations of the receipt data. Secondary authenticator is for the authorities using blockchain, so the output of previous receipt is an input to for the next receipt. This is threaded chaining and forces chained continuum. Current documentation doesn't cover feedback & refund transactions.
- DIL-Networks (Disconnected, Interrupted and Low-bandwidth) - Depending on application design and architecture, that's a huge problem, or no problem at all. Yet that list still lacked high latency, which can be really devastating for applications which aren't designed correctly.
- RFC 8410 - X448 and Ed448 new stronger curve for ECC. Also see: Curve448 @ Wikipedia and RFC7748 Elliptic Curves for Security.
- Open SSL 3.0.0 design - Read just for weekend fun. Remarks: It's nice that they do POST, KAT and IC, SHA-3 is being included as well as DH keys with lengths 6144 and 8192.
- Decided that matrix.org and riot.im aren't ready yet for prime time use. Riot uses way too much resources on mobile phone. It's heavy even in browser. Even if not nearly as bloated as Slack. With same usage level, Riot used 4-5x resources compared to WhatsApp, which is way too much. But that's a great project to keep in mind and re-check in a year or two. I like the design principles.
- That reminded me about Outlook and it's Android app. Which also refreshes content constantly. In a way it's nice, but it's also really wasteful when you're going through massive piles of email on desktop, what's the point of refreshing that in real time on mobile. It only wastes resources.
2020-05-17