I think that you need to consider confidentiality here as well. It might be
desirable to have the addressing information concealed. That implies a
mechanism like: http://tools.ietf.org/html/draft-rescorla-stateless-tokens
Now for a variation on a well-worn screed that I had to repeat many times while
I was at Skype...
I think that the general guidance for designing APIs on HTTP is that URLs
should not represent actions, they should represent things. So /call/ might be
OK in the noun sense, but if the intent is to load this with other actions, I
think that I might have to question the wisdom of that. Not knowing what these
implied other actions are makes it hard to assess this properly though.
As it stands, I believe that we have two "things" here: a registry of contact
URIs, and a registry of calls. So the nouns might be /contact/{token} and
/calls/{token}.
That leads to the next concern, which is that committing to a URI format is not
wise in general because that can dictate server architecture. If you do as you
describe (s/http/https), then loop.services.mozilla.com is it. You can't hand
out tokens that reference a specific deployment or server, you can't move stuff
without paying redirect or proxying costs.
Since you are minting tokens anyway, why not provide clients with all the URIs
they will need, in full, when the token is minted. Then you can hand clients
off to https://idontcareabout.loop.services.mozilla.com.itspants.for.me/ and
change URI layouts and all sorts of magical stuff. The only fixed part is the
starting point.
I'll also note that /call/1/... and /call/... are identical in very many
respects. The first is revised by increasing 1 to 2, the second by picking
another name.
(I have a design for a RESTful registrar API if you are at all interested. I
built two of those in the past year, it's a fairly straightforward pattern.)
----- Original Message -----
From: "Adam Roach" <a...@mozilla.com>
To: dev-media@lists.mozilla.org
Sent: Wednesday, February 19, 2014 7:52:53 PM
Subject: WebRTC Service: On temporary call URLs
[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 "a...@mozilla.com" to "a...@nostrum.com",
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:a...@mozilla.com:a...@nostrum.com: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 -- a...@nostrum.com in this example -- but for MLP, this
should be sufficient)
--
Adam Roach
Principal Platform Engineer
a...@mozilla.com
+1 650 903 0800 x863
_______________________________________________
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media
_______________________________________________
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media
