This definition (and the HTTPS+AES one) leaves a lot to be desired, IMO
* What are the use cases?
* Why is it better than using HTTPS? If the URL is sent over HTTPS you
will very likely already have at least one persistent HTTP connection open
to the server (assuming it is the same server) so establishing a new
connection (same or different server) for this request is not going to
increase performance. Even if no connections are open, for a properly
configured server, reestablishing a SSL/TLS session is not going to take
much longer (one extra roundtrip) and the entire request and response will
* What is the keymaterial? If the userinfo is the key, how is it encoded?
Base64, hex, calculated (how?), or other format, and if so, where is the
CTR nonce encoded? If userinfo is not the key, how is the userinfo used to
obtain the the encryption key, and how is that information secured?
* If the keymaterial is intended for long-term usage by a single user,
depending on storage methods, how is the keymaterial info migrated
securely to a new client, either for parallel use in multiple clients, or
* Given that this is probably going to be MITM vulnerable when used over
plain HTTP, what should the client do if the URL is provided over HTTP (or
included by reference in a document loaded over HTTP)? Refuse to perform
the request, or go ahead anyway?
* How does this interact with other ongoing specification work, such as
* How will this interact with clients that does not understand the URL
scheme? It is quite possible that they will display the userinfo in the
addressbar or the resulting error messages.