feat: (eng-607), rafiki cards blog #185
Draft
+281
−0
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
✅ Deploy Preview for developers-preview ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
koekiebox
changed the title
Member
sabineschaller
left a comment
sabineschaller
left a comment
There was a problem hiding this comment.
I know there are quite a few comments, but generally, I love this! It is a fantastic overview!
|
|
||
| [Rafiki](https://rafiki.dev/) is an open-source platform that enables Account Servicing Entities (ASEs) like banks and digital wallet providers to integrate [Interledger Protocol](/developers/get-started) (ILP) functionality into their systems. | ||
|
|
||
| Card payments are the backbone of global commerce... trusted, regulated, and deeply entrenched. Our latest exploration asks a pivotal question: how can we bring the ubiquity of card payments into the Interledger ecosystem without compromising the security and standards of the EMV model? |
Member
There was a problem hiding this comment.
Suggested change
| Card payments are the backbone of global commerce... trusted, regulated, and deeply entrenched. Our latest exploration asks a pivotal question: how can we bring the ubiquity of card payments into the Interledger ecosystem without compromising the security and standards of the EMV model? | |
| Card payments are the backbone of global commerce--trusted, regulated, and deeply entrenched. Our latest exploration asks a pivotal question: how can we bring the ubiquity of card payments into the Interledger ecosystem without compromising the security and standards of the EMV model? |
|
|
||
| [Rafiki](https://rafiki.dev/) is an open-source platform that enables Account Servicing Entities (ASEs) like banks and digital wallet providers to integrate [Interledger Protocol](/developers/get-started) (ILP) functionality into their systems. | ||
|
|
||
| Card payments are the backbone of global commerce... trusted, regulated, and deeply entrenched. Our latest exploration asks a pivotal question: how can we bring the ubiquity of card payments into the Interledger ecosystem without compromising the security and standards of the EMV model? |
Member
There was a problem hiding this comment.
You may want to explain what the EMV model is?
|
|
||
| 1. Card (ICC) - EMV-compliant card with an ILP-linked wallet address | ||
| 2. POS Device - EMV kernel + ILP extensions | ||
| 3. Merchant ASE - Runs Rafiki and manages POS trust (RKI, IPEK lifecycle, compliance) |
Member
There was a problem hiding this comment.
Depending on the audience, maybe explain the abbreviations.
| What we have been exploring is a simple question: | ||
|
|
||
| - What if card payments could naturally flow into Interledger without breaking EMV, without replacing kernels, and without weakening the security model everyone already relies on? | ||
| - This post is a walkthrough of that exploration. It is not a final specification, but a journey through the design, the trade-offs, and the emerging shape of an ILP-enabled card flow built around Rafiki, existing EMV kernels, and a small set of new services. |
Member
There was a problem hiding this comment.
I wouldn't put this as a bullet point but as a paragraph underneath.
|
|
||
| ## Starting Point: Should you build a a Kernel? | ||
|
|
||
| One of the earliest and most important decisions came out of conversations with our first POS (Point of Sale) manufacturing partner, who provides both the EMV kernel and a significant portion of the overall payment software stack running on the device. |
Member
There was a problem hiding this comment.
You use the abbreviation POS earlier but you only define it here. Maybe move it up?
|
|
||
| 1. The POS generates a key pair locally and sends a CSR, along with device metadata, to the ASE | ||
| 2. The ASE signs the CSR via its CA | ||
| 3. The ASE generates the IPEK (Initial PIN Encryption Key) for SRED/PIN (Secure Reading and Exchange of Data / Personal Identification Number) |
Member
There was a problem hiding this comment.
With all those abbreviations, maybe have a glossary somewhere (top or bottom) that you link to? May be easier than having all of the definitions in the text.
Comment on lines
+125
to
+129
| Once we started thinking seriously about certification (for example, MPOC), a practical requirement surfaced very quickly: | ||
|
|
||
| Encryption keys must be rotated regularly (at least monthly)! | ||
|
|
||
| This is where things get interesting. |
Member
There was a problem hiding this comment.
Suggested change
| Once we started thinking seriously about certification (for example, MPOC), a practical requirement surfaced very quickly: | |
| Encryption keys must be rotated regularly (at least monthly)! | |
| This is where things get interesting. | |
| Once we started thinking seriously about certification (for example, MPOC), a practical requirement surfaced very quickly: _Encryption keys must be rotated regularly (at least monthly)!_ This is where things get interesting. |
Comment on lines
+143
to
+148
| So rather than fighting that model, we leaned into it. | ||
|
|
||
| A Crucial Piece Emerges: Remote Key Injection (RKI) and Key Rotation! | ||
|
|
||
| Instead of pushing key management into the kernel or POS logic, we introduced a new ASE-side service whose sole responsibility is key lifecycle management. | ||
| Not payment processing. Not EMV logic. Just keys. |
Member
There was a problem hiding this comment.
Suggested change
| So rather than fighting that model, we leaned into it. | |
| A Crucial Piece Emerges: Remote Key Injection (RKI) and Key Rotation! | |
| Instead of pushing key management into the kernel or POS logic, we introduced a new ASE-side service whose sole responsibility is key lifecycle management. | |
| Not payment processing. Not EMV logic. Just keys. | |
| So rather than fighting that model, we leaned into it. A Crucial Piece Emerges: _Remote Key Injection (RKI) and Key Rotation!_ Instead of pushing key management into the kernel or POS logic, we introduced a new ASE-side service whose sole responsibility is key lifecycle management. | |
| Not payment processing. Not EMV logic. Just keys. |
|
|
||
| - POS TMK (Terminal Master Key) is generated and injected during POS manufacturing | ||
| - Transaction keys live inside the WhiteBox | ||
| - Network / ILP keys live outside the SDK, in the device keystore |
Member
There was a problem hiding this comment.
I think this is the first time you mention the SDK. Maybe add somewhere earlier that we amend the C2 kernel via an SDK?
Comment on lines
+215
to
+218
| See ADPU (Application Protocol Data Unit: | ||
|
|
||
| - https://en.wikipedia.org/wiki/Smart_card_application_protocol_data_unit | ||
| - https://www.emvco.com/specifications/?search_bar_keywords=c-2 |
Member
There was a problem hiding this comment.
Maybe make this a footnote?
golobitch
reviewed
Jan 17, 2026
|
|
||
| The POS is already running: | ||
|
|
||
| - POS Manufacturer bespoke software (Andriod / Symbian / iOS / Windows Phone) |
Contributor
There was a problem hiding this comment.
Suggested change
| - POS Manufacturer bespoke software (Andriod / Symbian / iOS / Windows Phone) | |
| - POS Manufacturer bespoke software (Android / Symbian / iOS / Windows Phone) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
PR Checklist
Fixes #eng-607). See: https://linear.app/interledger/issue/ENG-607/technical-blog-on-rafiki-and-cardsbun run formatto ensure code is properly formattedbun run lintpasses without errorsSummary
Please see the preview: https://deploy-preview-185--developers-preview.netlify.app/developers/blog/rafiki-card-integration/