On 2/20/14 04:54, Alexis Métaireau wrote:
Adam, thanks for starting this discussion,
Le 20/02/2014 04:52, Adam Roach a écrit :
Putting this together, what we want is something that semantically
evaluates to:
http://authority/action/url-format-version/{serial
#,caller,callee,expiration,hmac}
As Martin points out, URLs should not represent actions, they should
represent things.
Sure, for most of the HTTP interactions, this is true, and it's a good
principle in general. The way I was viewing this was that the handed-out
call URLs (unlike other operations we're performing) weren't going to be
idempotent: accessing the resource twice would create two calls. In
traditional HTTP design, this would typically be relegated to something
like POST, but we can't pass around URLs with an embedded method in a
well-supported way.
That said, I see that the GET/POST proposal you have addresses this in a
more resource-based fashion, and agree that it's a cleaner way to handle
URLs.
On the experiment we made with Romain Gauthier and Nicolas Perriault, we
went ahead and chose the following scheme...
# A "*" means this URI requires authentication (a valid token from the token
server,
# which contains user id).
* POST /call-url/ → Create the call url a callee can click on.
GET /calls/{token} → Get the app (that's the url in question, which
displays an app)
POST /calls/{token} → Add an incoming call (does a simple push notif
and gets room tokens)
* GET /calls/ → List incoming calls for the authenticated user.
{token} was something that is containing the user id of the callee plus
a . I don't understand why we're trying to put information about the
caller here, since we don't know who is this.
Keep in mind that the nominal user experience for this, once we get to
MVP, will be rooted in an address book. I'll have my list of contacts,
which includes phone numbers and email addresses. When an address book
user is activated by a user, we'll check whether the contact info
corresponds to a Loop user. If so, we place a call in that direction;
otherwise, we offer to create a "call me" URL and (if possible) deliver
it using the contact means (email or phone/SMS) corresponding to the
address book entry. So, when we create the URL, we'll know who the user
intends to give it to.
This is important because it allows us to say "You have an incoming call
from Alexis" rather than "You have an incoming call from some random
person." The delivery of calling party identity is simply considered
table stakes for a communications service nowadays [1].
In your proposal, I don't understand what is the "serial #", and
especially why it can't replace the version as you specify it.
The "serial number" is different for each and every URL issued, and is
used for revocation purposes.
The "version" allows us to transition between schemes in the future, if
we need to change the properties of the URL -- it allows us to
unambiguously change the format of the {token} [2]. For example, if we
decide to re-key the HMAC, we can increase the version number. The same
goes if we decide to add fields, encode them differently, or even go to
a completely different design (such as a sparse key into a database
table). It gives us an "out" to reconsider the design of the token if it
doesn't meet future needs.
It seems straightforward to just have a serial number (randomly
generated and not auto incremented, because auto increment is harder to
scale) that we can revoke if needed.
Sure, random would work, as long as we have sufficiently low chance of
collision. It would be a pretty big error if revocation of one URL
caused a different URL to also be revoked because they shared the same
random identifier.
It means that before displaying the app and accepting a call (we can
also chose one of them only), we will have to check in the database if
this serial # is still a valid one.
If I understand you correctly, you're describing an intended feature of
the system, not a problem: the check for revocation of a serial # is
part of the revocation mechanism.
We could let the user chose what's the duration of their call-url, and
default to something specified in a configuration file if the user don't
specify anything.
Right, that's the intention.
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.
If you're thinking about having multiple versions of the service running
at once, then I think this shouldn't be handled this way. When you ask
for a node to the token server, you ask for a particular version of the
service, and you get an endpoint to this service.
This allows us to not have to deal with multiple versions of the API in
the server code. If that's not what you're refering to, can you provide
more info?
It's not multiple versions of the application; it's multiple versions of
the URL field format. At any given moment, any single version of the
server application running would be expected to be able to parse the
current URL format, plus any of the previous URL formats that have been
issued within the ${max_url_duration} seconds.
Yes, this requires some conditional logic in the server code when (if)
we decide to change to change the token format, but that should be
pretty lightweight.
____
[1] cf.
http://pimcore-1872623517.us-east-1.elb.amazonaws.com/infoservices/resources/whitepapers/whats-next-in-caller-identification-services#.UwYya8dn9N0
[2] Since the current plan is for all tokens to be time-bounded with a
known maximum possible duration, the general means of transitioning from
token format "n" to token format "n+1" would be to introduce the new
format on the new version number; have both formats running side-by-side
for this maximum possible duration; and then retire format "n" altogether.
--
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
