-
Notifications
You must be signed in to change notification settings - Fork 256
Conversation
Covers topics of federation and compliance, uses the pre-built federation server, compliance server, and bridge server to do so.
For these diagrams, can we change it to "Your FI" instead of "Your Bank" or "Your Financial Institution" or maybe just "Your Infrastructure" |
@jedmccaleb, yeah, definitely. The diagrams may need some general revision anyway; I was trying to get a) a condensed version of the bigger diagram so you could actually see it all at once and b) show how it works with/without various addons like federation and compliance. Probably not "FI" (I think that abbreviation is problematic; it seemed to be when I asked people about the old doc, which also used it). Will have to think about whether "financial institution" or "infrastructure" is better. |
Also, organizationally: do we want/need a better structure for where images go, filesystem-wise? |
you mean like docs/images or something? |
When it comes to diagrams I'd add a background layer for Your/Other FI. Right now, it's not clear where each part of the system belongs. |
Yeah. Is it ok that the images are just free-floating in the guides directory right now, or should they be grouped into a directory? (probably with the same name as the guide) Relatedly, I can put the sketch files in dropbox, but should they also live in the repo? Seems like that would make sense.
What about “your systems?” (“infrastructure” is good, too, just slightly more jargon-y.)
Yeah, that's probably a good idea. |
Seems better to have the images in a separate dir but I don't feel strongly about it. Also don't feel strongly about sketch in the repo or not. Probably better to have it be here. |
Get rid of nice indentations (bad for copy/paste), add `source` (it's required for now), add `apiKey`). May want to consider removing all the API key bits since not really recommended anyway.
54b160d
to
c2fc2d9
Compare
This completes a first full draft of the new anchor guide. Lots of clean up (and splitting up) needed.
Ok, basic first draft of all the parts, fully working. Needs cleanup:
|
Looks great. are things like "[^friendly_names]" placeholders? |
@@ -354,7 +354,7 @@ You should get a response like: | |||
|
|||
## Compliance | |||
|
|||
The final piece of the puzzle is handling regulatory compliance, like <abbr title="Know Your Customer">KYC</abbr>. The [Stellar compliance protocol](compliance-protocol.md) is a standard way to exchange compliance information and pre-approve a transaction with another financial institution. | |||
The final piece of the puzzle is handling regulatory compliance, like <abbr title="Anti-Money Laundering">AML</abbr>. The [Stellar compliance protocol](compliance-protocol.md) is a standard way to exchange compliance information and pre-approve a transaction with another financial institution. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jedmccaleb what exactly is the right context for AML vs. KYC?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
KYC is a more thorough process that a bank will go through when someone is creating a bank account with them. When they are sending a payment they just need enough info on the recipient to do the AML check to make sure the recipient isn't on some sanction list. Since people already have accounts in these scenarios, we are just dealing with AML.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, gotcha. I had thought KYC referred to exchanging the information as well, not just initially gathering it. Will keep that in mind!
Those are named footnote links. So you can footnotes like |
The above splits the anchor guide into a 5 page group, kind of like the get started guide. I also added support in the build scripts for metadata named Not sure if that’s desirable (it kind of obscures the links when reading straight markdown or in github). Any thoughts on it? |
@bartekn if you have a nicer way to write out the Java stuff, that'd be awesome. I'm not really sure what helper libraries are most used for HTTP stuff these days.
- Hooks -> Callbacks - Stop discussing error callback since it never gets used - Don't discuss api_key since we've decided its use shouldn't be encouraged - Minor formatting and language tweaks
This helps clarify to the reader exactly which file is being shown, since they can see the name in the heading of the code snippet.
This also makes some technical corrections to the diagrams (and adds one for federation). Diagrams still need final cleanup from Romina.
Ok, I think this is mostly done save for:
But otherwise, I think this is pretty much there, excepting any further feedback anyone’s got. Please let me and Romina both know if you think there are technical inaccuracies in the diagrams, too. /cc @jedmccaleb @nullstyle @bartekn |
|
Headings that used to be H3 should have become H2 when we broke this guide into 5 pages (what used to be level 2 headings are now level 1 page headings).
Don't merge into master until stellar-deprecated/docs#160 is shipping.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great! 👍
`AUTH_SERVER` is the address for the *external* port of your compliance server. Like your federation server, this can be any URL you like, but **it must support HTTPS and use a valid SSL certificate.**[^ssl] | ||
|
||
`SIGNING_KEY` is the public key that matches the secret seed specified for `signing_seed` in your compliance server’s configuration. Other organizations will use it to safely encrypt sensitive compliance data (like customer names, birthdates, and addresses) so that only you can read it and to verify that messages were actually sent by you. | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
SIGNING_KEY
is used to sign Auth Request (sig
param) so receiving organization can check whether it was really sent by the sender organization.
There will be also ENCRYPTION_KEY
in stellar.toml file but we haven't decided on the format yet.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@bartekn Ah! I admit to not having inspected data on the wire to see if this was additionally used for encryption. D’oh! How about:
SIGNING_KEY
is the public key that matches the secret seed specified forsigning_seed
in your compliance server’s configuration. Other organizations will use it to verify that messages were actually sent by you.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
✅ DONE!
This ensures we have working back and next links when browsing the docs on Github (I had previously been planning on autogenerating these links when the developers site builds).
Added the back/next links to the docs. Needs stellar-deprecated/developers#84 for nicer styling. That just leaves improved diagrams from Romina, I think. |
Nice work Rob! |
This isn’t even sort of done yet, but I want to get it in public so @jedmccaleb / @bartekn / @nullstyle can take a basic look at whether I'm doing things right with the various prebuilt servers and @mozzadrella can start to gut-check me on direction.
Unlike the old guide, this: