Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

draft for SEP on URI Scheme #95

Merged
merged 16 commits into from May 8, 2018

Conversation

@nikhilsaraf
Copy link
Member

commented Apr 16, 2018

This is the draft for the SEP for the URI Scheme. It may be easier to view the actual file to see the rendered markdown, here

Simple Summary: This Stellar Ecosystem Proposal introduces a URI Scheme that can be used to generate a URI that will serve as a request to sign a transaction. The URI (request) will typically be signed by the user’s trusted wallet where she stores her secret key(s).

RFC - Please add any comments to this PR on how this specification can be improved to better serve the community.

4. `asset_issuer` (optional) - Account ID of asset issuer (XLM if not present) destination will receive
5. `memo` (optional) - Can be a memo to be included in the payment / path payment. This should follow the normal guidelines for memos. This should also be URL-encoded.
6. `submit` (optional) - If this value is omitted then the URI handler should create and submit the proper transaction to the network. If the value is present then it should be interpreted as a URL-encoded callback. The URL-encoded callback will be prefixed with its own namespace to denote whether this is a `url` callback or some other form of callback. In the case where it is a url callback (denoted by `url:`) the URI handler should send the signed XDR to this url in a `POST` request with `Content-Type` set to `application/x-www-form-urlencoded` with the data fields `xdr` containing the signed XDR (URL-encoded). If there are any query params specified in the URL callback then those should be included in the URL when submitting. For now only `url` callback types are supported.
7. `msg` (optional) - There can be an optional `msg` query param to indicate any additional information that the website or application wants to show the user in her wallet. The value for this query param should be URL-encoded as well and should not be longer than 300 characters before the URL-encoding. Note that the `msg` field is _different_ from the `memo` field that is included in a transaction. The `msg` field will not be put on-chain, but the `memo` field will be put on-chain.

This comment has been minimized.

Copy link
@nullstyle

nullstyle Apr 16, 2018

This is my least favorite portion of this proposal. Generic messaging systems are usually dangerous (see memo spam for an example in our own system) and the distinction between msg and memo will be very thin for users who aren't very experienced with stellar jargon.

This comment has been minimized.

Copy link
@jedmccaleb

jedmccaleb Apr 16, 2018

Contributor

I agree it is confusing but it seems like the system that generates the transaction needs someway to give the URI handler some context of what is going on.

@nullstyle

This comment has been minimized.

Copy link

commented Apr 16, 2018

I'd love to see some discussion around the security implications of using a URL scheme for payment links. For example, I'd like to see some discussion around scheme hijacking and if/how that's an issue for wallet developers.

Copy link
Contributor

left a comment

This proposal makes sense to me.

Maybe it's already possible, but if not, it'd be useful to identify the party that generated the transaction that needs signing. This would allow wallets to handle transactions from different sources in different ways. A user may want to sign trades from a trusted exchange without review, but review anything from an untrusted source. A wallet may also want to implement per-source access controls (perhaps allowing a user to permit only manage_offer transactions for an exchange).

This could be accomplished by allowing the transaction XDR to be signed, but in a way that is only interpreted locally by the wallet and not sent to the Stellar network. Or, better, the entire URI could be signed. The identity of the signer could then be deduced by finding the stellar.toml file that lists the signing key.

@tempofr

This comment has been minimized.

Copy link
Contributor

commented Apr 17, 2018


### Operation `tx`
The `tx` operation represents a request to sign a specific XDR `Transaction`. The parameters for the `tx` op are as follows:
1. `xdr` (required) - A Stellar transaction in XDR format that is base64 encoded and then URL-encoded. If the existing source account uses the Master Account behind the network passphrase with an empty string (i.e. `keypair.Master("").Address()`) then the interpreting code will replace the source account and sequence number on this XDR `Transaction` with its own source account and sequence number before it signs it. If the source account is not the sentinel value and the sequence number is 0 then the interpreting code should replace only the sequence number before signing. See the reference implementation for implementation details.

This comment has been minimized.

Copy link
@bartekn

bartekn Apr 17, 2018

Member

Using master key for the network as a sentinel value seems overcomplicated. Why not use byte array filled with zeros instead?

This comment has been minimized.

Copy link
@poliha

poliha Apr 18, 2018

Agree with bartek here, this was a bit complicated to me when I read it at first. Can this be part of the parameters? E.g. when updateSource = true the source should be updated, or something along those lines.

2. `amount` (required) - Amount that destination will receive
3. `asset_code` (optional) - Asset code (XLM if not present) destination will receive
4. `asset_issuer` (optional) - Account ID of asset issuer (XLM if not present) destination will receive
5. `memo` (optional) - Can be a memo to be included in the payment / path payment. This should follow the normal guidelines for memos. This should also be URL-encoded.

This comment has been minimized.

Copy link
@bartekn

bartekn Apr 17, 2018

Member

We should also have a param for memo_type and agree on encoding of memo_hash: hex or base64?

This comment has been minimized.

Copy link
@MisterTicot

MisterTicot Apr 22, 2018

Contributor

In cosmic link I use:
memo=text:hello!
memo=hash:DE6...87C

@bartekn

This comment has been minimized.

Copy link
Member

commented Apr 17, 2018

Other than my comments I think this SEP should have following features:

  • There should be network_passphrase or just network param (with two predefined values: public and testnet). Without it, it will be hard to perform end-to-end testing.
  • Payment requests should be signed. Without it, this solution doesn't prevent from phishing as any malicious browser extension can easily change the params in-flight. Here's how I think it could work:
    • Add origin param to the request. If it's possible for an external app to check the origin of the request (domain) use this value and ignore the origin param.
    • Add sig param to the request which is a signature generated using SIGNING_KEY in stellar.toml file for a given domain.
    • Signing app should display origin domain to a user and check if the signature is valid.
    • EDIT this is more or less what @tomquisel suggested.
Copy link

left a comment

In all, I think this will be very useful. One part that is not clear to me is how this will work for users that have paper wallets? Will the application be required to generate and handle the URI requests?


### Operation `tx`
The `tx` operation represents a request to sign a specific XDR `Transaction`. The parameters for the `tx` op are as follows:
1. `xdr` (required) - A Stellar transaction in XDR format that is base64 encoded and then URL-encoded. If the existing source account uses the Master Account behind the network passphrase with an empty string (i.e. `keypair.Master("").Address()`) then the interpreting code will replace the source account and sequence number on this XDR `Transaction` with its own source account and sequence number before it signs it. If the source account is not the sentinel value and the sequence number is 0 then the interpreting code should replace only the sequence number before signing. See the reference implementation for implementation details.

This comment has been minimized.

Copy link
@poliha

poliha Apr 18, 2018

The sequence number being updated here is that of the source account correct? This should stated clearly.


### Operation `tx`
The `tx` operation represents a request to sign a specific XDR `Transaction`. The parameters for the `tx` op are as follows:
1. `xdr` (required) - A Stellar transaction in XDR format that is base64 encoded and then URL-encoded. If the existing source account uses the Master Account behind the network passphrase with an empty string (i.e. `keypair.Master("").Address()`) then the interpreting code will replace the source account and sequence number on this XDR `Transaction` with its own source account and sequence number before it signs it. If the source account is not the sentinel value and the sequence number is 0 then the interpreting code should replace only the sequence number before signing. See the reference implementation for implementation details.

This comment has been minimized.

Copy link
@poliha

poliha Apr 18, 2018

Agree with bartek here, this was a bit complicated to me when I read it at first. Can this be part of the parameters? E.g. when updateSource = true the source should be updated, or something along those lines.

Jed McCaleb
Copy link
Contributor

left a comment

This looks great and will be extremely useful to the ecosystem.

I don't know if this fits in this proposal but I think we should add another operation whois: a mechanism a webpage to ask your wallet for your public address, in case it wants to send you assets, authorize your account, etc.

4. `asset_issuer` (optional) - Account ID of asset issuer (XLM if not present) destination will receive
5. `memo` (optional) - Can be a memo to be included in the payment / path payment. Memos of type `MEMO_HASH` and `MEMO_RETURN` should be base64 encoded and the URL encoded. Memos of type `MEMO_TEXT` should be URL-encoded.
6. `memo_type` (optional) - One of `MEMO_TEXT`, `MEMO_ID`,`MEMO_HASH`, `MEMO_RETURN`. See [transaction guide](https://www.stellar.org/developers/guides/concepts/transactions.html#memo) for a description of these values.
7. `submit` (optional) - If this value is omitted then the URI handler should create and submit the proper transaction to the network. If the value is present then it should be interpreted as a URL-encoded callback. The URL-encoded callback will be prefixed with its own namespace to denote whether this is a `url` callback or some other form of callback. In the case where it is a url callback (denoted by `url:`) the URI handler should send the signed XDR to this url in a `POST` request with `Content-Type` set to `application/x-www-form-urlencoded` with the data fields `xdr` containing the signed XDR (URL-encoded). If there are any query params specified in the URL callback then those should be included in the URL when submitting. For now only `url` callback types are supported.

This comment has been minimized.

Copy link
@tomerweller

tomerweller Apr 18, 2018

Contributor

I'm concerned about only allowing the url callback type. We need to have a good story for how a client side app communicates with the signer app without setting up a backend. Specifically, I'm thinking about single page apps communicating with browser extensions (cryptokitties + metamask style).

One way to do so is to have the single page app register a custom protocol handler and have the submission callback refer to that. That can work but will create an awkward user experience (the browser will ask the user if it approves this webpage to handle "Stellar Response" links or something like that)

Usually, webpage <-> extension communication happen through postMessage(), but that requires the website to know of a specific extension in advance (example) rather than being able to communicate with any extension that supports the protocol.

I wonder if I'm missing another option here. @nullstyle @bartekn ?

@jedmccaleb

This comment has been minimized.

Copy link
Contributor

commented Apr 19, 2018

@tomerweller how would "whois" work? how would the URI handler tell the webpage?

@tomerweller

This comment has been minimized.

Copy link
Contributor

commented Apr 19, 2018

@jedmccaleb the whois operation will have a submit callback option, similar to the one in the other operations.

This will provide a mechanism for "stellar enabled" websites to present personalized information for the user. Similarly, websites that have the metamask sdk can show users (that have the extension installed) information about their account by asking the extension for the address.

@johansten

This comment has been minimized.

Copy link
Contributor

commented Apr 20, 2018

I'll add this as a comment, for "whois", since I'm doing the same thing(?) in QR.

https://galactictalk.org/d/33-log-in-via-qr-code-challenge-response

### Operation `tx`
The `tx` operation represents a request to sign a specific XDR `Transaction`. The parameters for the `tx` op are as follows:
1. `xdr` (required) - A Stellar transaction in XDR format that is base64 encoded and then URL-encoded. If the source account in the xdr is all zeros then the URI handler should replace the source account and sequence number with the user's source account and sequence number before it signs it. If the source account is set and the sequence number is 0 then the URI handler should replace only the sequence number before signing.
2. `submit` (optional) - If this value is omitted then the signed XDR should be submitted to the network. If the value is present then it should be interpreted as a URL-encoded callback. The URL-encoded callback will be prefixed with its own namespace to denote whether this is a `url` callback or some other form of callback. In the case where it is a url callback (denoted by `url:`) the URI handler should send the signed XDR to this url in a `POST` request with `Content-Type` set to `application/x-www-form-urlencoded` with the data fields `xdr` containing the signed XDR (URL-encoded). If there are any query params specified in the URL callback then those should be included in the URL when submitting. For now only `url` callback types are supported.

This comment has been minimized.

Copy link
@pselden

pselden Apr 20, 2018

Contributor

Should it actually be defined what the behavior is if submit is not defined? Why is the default to submit to the network? I know it says should -- but is that actually a requirement?

Consider a multisig account -- the application handling the signing request should be the one deciding how to coordinate the rest of the signatures if submit is not present. In its current state it seems like they would be required to submit a transaction that may not have the proper signatures. The note on multisig wallets seems to conflict with this parameter.

To provide a real world use case with StellarGuard:

  1. Application submits request for payment.
  2. Wallet handles the URI and builds and signs the transaction with one signature.
  3. Wallet checks if it is a StellarGuard-protected multisig account and submits it to StellarGuard for authorization.
  4. Post-authorization, StellarGuard can either sign and submit it to the network, or return the transaction as another URI for further handling.

Step 3 would fall apart if submit was not present and the wallet were required to submit it to the network.

It seems like this is probably covered by the multisig note (meaning does not need to be submitted), but likely just needs some clarifying wording around this part.

This comment has been minimized.

Copy link
@jedmccaleb

jedmccaleb Apr 20, 2018

Contributor

The URI handler can really do whatever it wants. The application is just giving the handler the info that it has that is presumably the user's intention. If the URI handler is managing a multi-sig account than yeah it would need to gather all the signatures before submitting to the network. I'll reword a bit to try to clarify

This comment has been minimized.

Copy link
@pselden

pselden Apr 20, 2018

Contributor

Understood, and the change to "callback" improves the clarity. My concern was with the language "If this value is omitted then the signed XDR should be submitted to the network." which is not true in the multisig case (and maybe not even true in the normal case -- it's probably up to the wallet/user to decide to submit it or not).

Jed McCaleb
@jedmccaleb

This comment has been minimized.

Copy link
Contributor

commented Apr 20, 2018

Let's leave the whois to a later extension for this or another mechanism

@sacarlson

This comment has been minimized.

Copy link

commented Apr 21, 2018

This to me looks like a good start in many ways. I am very happy to see more eyes looking into this subject. But I am curios as to how future escrow transactions might be implemented or added to this format at some point. In my implementation of an escrow transaction we needed to add a few meta data fields that included:

Added Escrow Data:
publicId: GAVUFP... // this is the 3rd party escrow agents publicID that becomes a signer in the escrow contract
email: funtracker.site.bank@gmail.com // the email contact info for the 3rd party escrow agent above
expire_ts: 1490574272 // timestamp of expire time when the store can recover it's funds with no reponse from the buyer.
expire_dt: the above time stamp in date format just for reference by humans not really used in the protocol, as the contract is down to the second
status: 0 // Order_status used in most cases to provides detailed error messages if problems happen in the escrow handshake at some point or stages in escrow post processing.
fee: This is the escrow service fee in XLM that is sent to the 3rd party escrow agent, this fee is optional depending on what the 3rd party wants to charge.
callback: this is the URL callback address that the wallet will submit the signed escrow transaction package to after the customer confirms payment from the wallet.

Might we standardize on how information like this might be added to the URI?

More details on how we already implemented a version of escrow in QR-code can be seen here: https://github.com/sacarlson/OpenCart_stellar_plugin as a reference.

As I read a bit more into this document I think I note that submit callback might be equivalent to my callback field. But I would still need the info above to generate the escrow tx to send back to it.

To me it seems a payment system for products without an escrow option is almost worthless. Escrow should at least at some point be a part of the infrastructure and made simple to integrate with some added documentation.

@MisterTicot

This comment has been minimized.

Copy link
Contributor

commented Apr 22, 2018

Hi,

I'm implementing a similar protocol and have a working alpha version, see:

https://galactictalk.org/d/1267-cosmic-link-alpha-release

The present draft include some features I had in my initial design that I removed after more serious research and implementation attempts.

I'll try to explain my choices here.


I dropped the /operation/?arguments... semantic in favor of /?operation&arguments.... This is better because this can be handled straightforwardly as a query string. This doesn't need several pages or redirection for webservice to handle.

I ask that you match the semantic used in cosmic-lib, or at least express every operation using a query string in order to ease implementation.


I dropped custom URI scheme in favor of universal links. Meaning, instead of 'stellar://' the link should start with any website URL. I provided 'cosmic.link' as a default but services such as exchanges and wallet could directly link to authenticator URL. Now this seems wrong as it centralize the process, but this simply was the less bad design. This obviously makes cosmic.link a target of choice, but I found interesting means to make the node secure enough. I'm open to write an article about those possibilities.

Custom URI scheme, however, are insecure by design as they may be hijacked by any program or application you install. Meaning, I can simply take the code of a wallet such as stargazer and include it in my new fancy program, then subscribe to 'stellar://' link handling on installation and go ahead for phishing attempt, like prompring for backup restoration. How are you going to prevent this ?

Another big drawback is that custom URI scheme can't be handled by webwallets at all, putting stellar port, stronghold, stroopy and such definitely out of the game.

Additionaly, clicking on such links without installed authenticator lead to an error, while universal links elegantly handle this case.

Custom URI scheme is being progressively deprecated by Apple for those reasons.

I ask that more time is given explorating seriously those issues, and that a solution to phishing attack is found if stellar:// have to be made standard.


The statement that not all operation should have their own semantic because it may be complicated to handle new operations an so on is simply untrue. If you take a look at cosmic-lib you'll see that it is a matter of few lines to add/remove/change operations.

There may be cases where we may loose backward compatibility and broke links. By example, if an asset disappear or if an operation doesn't accept the same parameters anymore, or need a new one to be given. In any of those cases, XDR would break as well and it is library implementator's job to write some compatibility layer.

There's a true value in having writeable/readable links and that's why I support federated address in cosmic link protocol. Think public adoption.

I ask that we adopt the semantic proposed in cosmic-lib, which mimic js-stellar-sdk and rules out any individual implementator preferences.

I ask for federated addresses to be supported in the standard.


I've been rulling out the message feature. It sure seems nice, but it boils down to allowing an untrusted source to display a message in a trusted interface. This is very bad. Just think about what scammers are going to do with such a gift. Really, they will.

So, I'd say it's up to the transaction emitter to explain the transaction in its own interface. As protocol implentators, we could eventually give additional description to operations, such as displaying warning when master key is going to be set to 0, but that's it.

I ask that this feature is removed from the standard.


I know I'm being fairly critic here. I've rewrote cosmic-lib several times in an attempt to find the most satisfying form for this protocol. Not to say there's nothing to improve, as there's nice ideas in this standard proposal I'll be happy to grab. My point is what looks good on the paper may appear like wrong at implementation time or after extensive searches about the actual possibilities.

Please acknowledge that I'm only trying to have us finding the best way to implement this thing. We'll have to support it forever then, so better think twice about the design.

@nikhilsaraf

This comment has been minimized.

Copy link
Member Author

commented May 3, 2018

@pselden

I don't know what special implications the custom protocol scheme has on this topic, but why would the the order of the query matter? Traditional in traditional querystrings the order does not matter at all, and most libraries just parse it and convert it to some sort of unordered map of querystring param name and value.

The ordering of parameters does not matter when parsing the URI but it matters when verifying the signature. Since signatures are based on hashes if the order is changed when verifying the signature then the verification will fail.

If the signature field is at the end It is marginally easier to exclude the signature field to obtain the correct URI request that was signed by the signature. The process of signing and verification is detailed out in the Request Signing section.

@MisterTicot

This comment has been minimized.

Copy link
Contributor

commented May 3, 2018

@nikhilsaraf

I assume that

web+stellar:tx?xdr=...

Get converted into

wallet.org/tx?xdr...

And that two different pages will be required to handle tx in one and pay in another. This is the reason why I moved operations inside the query.

@pselden

This comment has been minimized.

Copy link
Contributor

commented May 3, 2018

Thank you for the clarification. I will mention that many people feel that the signature part of oauth 1 was the worst part about it, but I have no better alternative to offer at this time.

@MisterTicot

This comment has been minimized.

Copy link
Contributor

commented May 3, 2018

@nikhilsaraf

I understand better your point about stellar.toml. I can see my lack of knowledge about how everything works together. Pinning the public keys for signature checking is indeed a good way to do.

Signing the stellar.toml would be a way to guarantee its content. You could either sign the whole content, or preferably sign its shasum. Obviously the public key would have to be stored in another location. I'm saying this only to answer your question now that I mentioned it and I'm aware I'm out of scope there.

@nikhilsaraf

This comment has been minimized.

Copy link
Member Author

commented May 4, 2018

@MisterTicot

I assume that

web+stellar:tx?xdr=...

Get converted into

wallet.org/tx?xdr...

And that two different pages will be required to handle tx in one and pay in another. This is the reason why I moved operations inside the query.

registerProtocolHandler allows you to set a handler that takes in the URI as a string. It is up to you to decide how to parse it and what it should be converted to. See the Syntax for registerProtocolHandler and the sample webHandler.html included in the SEP for a PoC on how this can work.


@pselden

Thank you for the clarification. I will mention that many people feel that the signature part of oauth 1 was the worst part about it, but I have no better alternative to offer at this time.

I understand your concerns and agree that the signatures would be tricky to get right. This is why it would be important to have the right libraries to handle this --something we would depend on the community to help with. The security provided by having signatures outweighs the cost of having to use these libraries, especially when libraries would likely be used to construct these URIs anyway.


@MisterTicot

I understand better your point about stellar.toml. I can see my lack of knowledge about how everything works together. Pinning the public keys for signature checking is indeed a good way to do.

Signing the stellar.toml would be a way to guarantee its content. You could either sign the whole content, or preferably sign its shasum. Obviously the public key would have to be stored in another location. I'm saying this only to answer your question now that I mentioned it and I'm aware I'm out of scope there.

This is a great suggestion and should be included as a future SEP to strengthen the stellar.toml.

@MisterTicot

This comment has been minimized.

Copy link
Contributor

commented May 4, 2018

Hi @nikhilsaraf,

registerProtocolHandler allows you to set a handler that takes in the URI as a string. It is up to you to decide how to parse it and what it should be converted to. See the Syntax for registerProtocolHandler and the sample webHandler.html included in the SEP for a PoC on how this can work.

I'm a bit lost here. Isn't this protocol supposed to allow sending transaction between services? How are we going to do if we don't specify how it should be done?

We need a standard way to write a query encoding a transaction, in such a way that if my wallet is Stellar Port I can sign at

https://stellarport.io/auth?{operation}&{parameters...}

And if my wallet is stroppy then

https://stroopy.org/sign?{operation}&{parameters...}

And a transaction editor could offer a service at

https://stellar.org/editor/?{operation}&{parameters...}

As well as a signature collector would allow to register a new transaction to synchronise at a given URL and so on.

This would allow each users to authenticate with different services without having to talk each service language each time. I mean, isn't that the point of this protocol?

I think you're getting my point that this would be easier using a query string so everybody speak the same language and can work together. I would be a shame to miss such an opportunity by ending saying : " ok each platforms issue links for itself and handle it as it want."

That's why I felt a bit perplex when cosmic link propocol have been said to be centralized; while the cosmic.link website itself is a service and the protocol is a syntax available to everybody.

I think something may have been overlooked here. Or I missed something again.

@nikhilsaraf

This comment has been minimized.

Copy link
Member Author

commented May 4, 2018

@MisterTicot

I'm a bit lost here. Isn't this protocol supposed to allow sending transaction between services?

This protocol is not meant specifically to allow sending transaction between services --it can certainly be used for that but is not the intended use.

The ideal use case is to go to a shopping website (or exchange or hotel website etc.) to make a payment which generates a URI request that you can sign in your trusted desktop/web wallet. Quoting from the Motivation section of the SEP below:

Non-wallet applications want a way to have their users sign a transaction
that is generated by it without requiring it to ever see the user’s secret
key in any form. Users already have their preferences for a trusted wallet
where they are storing their secret keys.

This leaves room for a common protocol that can be implemented by both
applications that want transactions to be signed as well as wallets that can
sign transactions.

if my wallet is Stellar Port I can sign at

https://stellarport.io/auth?{operation}&{parameters...}

If your wallet is stellarport then stellarport would generate a URI request for a payment (or change trust etc.) like web+stellar:pay?.... When you click this link it will open up the wallet that you have registered to handle the web+stellar scheme and you can complete the payment. Sellarport checks to see if you've sent the payment and then proceeds in the workflow to reflect this payment. I've added a section on User Experience to further clarify how this should work.


This would allow each users to authenticate with different services without having to talk each service language each time. I mean, isn't that the point of this protocol?

This sounds more like Single Sign-On, which is not the point of this protocol.


That's why I felt a bit perplex when cosmic link propocol have been said to be centralized; while the cosmic.link website itself is a service and the protocol is a syntax available to everybody.

I think something may have been overlooked here. Or I missed something again.

There can certainly be a protocol that provides a standard way to send payment requests to any domain/service. If it were to exist I think it would be useful to have it specified in the stellar.toml file to be standardized in the same way that the stellar.toml hosts a link to the FEDERATION_SERVER.

In my opinion, such a standard should go through the SEP process and is independent from this SEP. I can see how such a SEP would use the URI Scheme specified in this SEP by passing around a URL-encoded URI Scheme so the new SEP would not need to reinvent the concept of transaction request. I hope this is useful in clarifying the goals of this SEP and how it's different from what cosmic.link is trying to achieve.

@MisterTicot

This comment has been minimized.

Copy link
Contributor

commented May 5, 2018

@nikhilsaraf

Ok then I got it. Thank you for taking the time to help me understand this protocol.

@nikhilsaraf nikhilsaraf force-pushed the nikhilsaraf:draft_uri_scheme branch 3 times, most recently from 13c5551 to 5c6d174 May 8, 2018
@nikhilsaraf nikhilsaraf force-pushed the nikhilsaraf:draft_uri_scheme branch from 5c6d174 to b56f6e0 May 8, 2018
@nikhilsaraf nikhilsaraf force-pushed the nikhilsaraf:draft_uri_scheme branch from ee8b686 to 18f0e1a May 8, 2018
@nikhilsaraf nikhilsaraf merged commit d3e85c8 into stellar:master May 8, 2018
@nikhilsaraf

This comment has been minimized.

Copy link
Member Author

commented May 8, 2018

@johansten

This comment has been minimized.

Copy link
Contributor

commented May 8, 2018

@nikhilsaraf You never replied to me about tx and callback in regards to multisig.

@MisterTicot

This comment has been minimized.

Copy link
Contributor

commented May 8, 2018

@nikhilsaraf Please don't let such an ugly security hole as an example ;-)

--- webHandler1.html	2018-05-08 11:09:40.056256219 +0200
+++ webHandler2.html	2018-05-08 11:18:29.989358747 +0200
@@ -29,13 +29,15 @@
                 var url = new URL(url_string);
                 var req_url_string = url.searchParams.get("req");
                 console.log(req_url_string)
-                document.getElementById("req").innerHTML = req_url_string;
+                var req_url_node = document.createTextNode(req_url_string);
+                document.getElementById("req").appendChild(req_url_node);
 
                 // extract the xdr from the payment request
                 var req_url = new URL(req_url_string);
                 var xdr_string = req_url.searchParams.get("xdr");
                 console.log(xdr_string)
-                document.getElementById("xdr").innerHTML = xdr_string;
+                var xdr_node = document.createTextNode(xdr_string);
+                document.getElementById("xdr").appendChild(xdr_node);
             }
         </script>
     </head>
@johansten

This comment has been minimized.

Copy link
Contributor

commented May 8, 2018

There's so much wrong with this I don't even know where to start.

Everything relating to multisig coordination for starters. It would have been nice to have been listened to.

QR codes can't use the same encoding, since they will become too large, and if they are too large they can't be scanned using entry level camera phones.

@MisterTicot

This comment has been minimized.

Copy link
Contributor

commented May 8, 2018

@nikhilsaraf I tried the webHandler.html as a first step to implement the protocol and I got pretty bad results. I may have made an error, or something may be wrong somewhere.

Anyway the webhandler.html is available for now at https://testing.stellar-authenticator.org/test.html

Lubuntu 16.04

  • Firefox : Works like a charm. Register webhandler and cross-domain links works.
  • Chomium/Opera/Webkits browsers: Doesn't register webhandler. Try to open URI with xdr-open but ungracely fails

Android 7:

  • I tried chrome, brave, opera, firefox, firefox focus and edge. Got nothing at all. Clicking at the link does nothing. It seems the webhandler doesn't register.

Windows:

  • Chrome: clicking on the link does nothing
  • Internet Explorer 11: error page, ask to install an application
    I could not install other browsers as it was not my own machine.

All in all the problem seems to be that no protocol handler seems to get registered.
A quick look at Can I Use confirmed the situation:
https://caniuse.com/#feat=registerprotocolhandler
Global support is said to be 35% with no clue that it could go better. Despite being flagged as supported by Chrome on desktops I couldn't get it to work. No support at all for phone & tablets.

I can't tell if the links would have been trigger had I installed a native application handler. I suppose that yes. Anyway web wallets support for this protocol will be poor to say the least.

For this reason I question whether it's of any use I implement it in cosmic-lib which's a javascript library. I know some people are using javascript to code phone apps so it could make sense anyway. Maybe I'd like to hear about them.

I'd also like to know if there's any support at all for this protocol inside iOs/macOs as I heard Apple is gradually dropping custom URI schemes in iOs in favor of universal links.

It would be nice to have a better view of how it performs on other platforms and how it behaves with native programs/applications. I assume this have been checked before as the protocol just got accepted, so I guess I'm missing something again.

@johansten

This comment has been minimized.

Copy link
Contributor

commented May 8, 2018

@MisterTicot

macOS:
Firefox and Opera manages to register the handler, Chrome doesn't.
Chrome opens up Opera when registered though.

@MisterTicot

This comment has been minimized.

Copy link
Contributor

commented May 8, 2018

@johansten Thank you Johan. I add the same behavior for chrome here on Linux.
Could you please check if it does works cross-domain?
https://markdownshare.com/view/9118c815-6bb0-4662-8a96-7c8e6b6d3d39

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.