[For the tl;dr, skip down the the line starting "Putting this all
together."]
I realize that, while I've had a few discussions with people about the
nature of the temporary calling URLs, I haven't really communicated some
of the requirements we have around them, and how we can meet those
requirements.
Users need the ability to revoke a URL that they have passed out -- if
it, for example, falls into the hands of marketers or people from whom
they do not wish to receive communications, users need a means to tell
the server that the URL can no longer be used to reach them. This means
the calling URLs must be unique each time they are generated; and,
ideally, will identify the party to whom they were given. This also
means that the URLs need to be tamper-proof, which implies some form of
integrity protection.
Second, for this kind of system where users can and will create
boundless state at a potentially rapid pace, we need to ensure that the
server is not required to store all that state -- it just doesn't scale.
This means the calling URLs need to encode all the information necessary
to identify the called party and the calling party.
Now, revocation is inherently state that we need to store; but
revocation events should be infrequent. Nonetheless, we don't want to
store such state in perpetuity, which means all calling URLs need to be
time bounded: once a URL expires, we can discard any associated
revocation state. We can also optimize the size of the data we need to
store for revocation: by including a short, unique serial number in each
URL, a revocation record can consist simply of that serial number along
with a date after which the URL is no longer valid (and, consequently,
after which the revocation can be discarded). Both pieces of information
are readily available from a URL each time it is used. If we use, say,
64-bit serials and 32-bit expirations, this requires nominally 96 bits
of state per revocation, which is pretty cheap.
Ideally, we also want the ability to identify multiple versions of URL
encodings, should we decide to migrate to include an enhanced scheme in
the future.
Putting this together, what we want is something that semantically
evaluates to:
http://authority/action/url-format-version/{serial
#,caller,callee,expiration,hmac}
Where "hmac" is an HMAC that includes the serial #, the caller, the
callee, and the expiration. We may find that we want to add more fields
to the part I have inside brackets here; using an explicit URL format
versioning allows us to do this very easily.
------------------------------------------------------------------------
For example (and this is meant to be illustrative, not normative), a URL
that is minted to call from "[email protected]" to "[email protected]",
with an expiration of March 1st, 2014 at 21:19:13 CST might crafted
first by concatenating these three fields together, prepended with a
serial number (1 in this example):
secret = "Bjqcy:FCwn^1P.s,v9,+;9AN(<w%X$:"
state = "1:[email protected]:[email protected]:1393730353"
hmac = HMAC_SHA265(secret, state) % 0x100000000 = 0x7a4a77ba
call_string = base64(concat(state, hmac)) =
"MTphYnIuY29tOmFkYW0uY29tOjEzOTM3MzAzNTN6Sne6"
This would then be combined with the authority
("loop.services.mozilla.com"), the action ("call") and the version ("1")
to create the following url:
http://loop.services.mozilla.com/call/1/MTphYnIuY29tOmFkYW0uY29tOjEzOTM3MzAzNTN6Sne6
(n.b., we probably want to strongly obscure the fields inside the blob
so as to avoid the ability to back out a called-party's contact
information -- [email protected] in this example -- but for MLP, this
should be sufficient)
--
Adam Roach
Principal Platform Engineer
[email protected]
+1 650 903 0800 x863
_______________________________________________
dev-media mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-media
