Add Capability class.

sdk/lib/isolate/capability.dart

Index: sdk/lib/isolate/capability.dart
diff --git a/sdk/lib/isolate/capability.dart b/sdk/lib/isolate/capability.dart
new file mode 100644
index 0000000000000000000000000000000000000000..a5893d55bc6902fe8803c32408973a513c905d3f
--- /dev/null
+++ b/sdk/lib/isolate/capability.dart
@@ -0,0 +1,39 @@
+// Copyright (c) 2014, the Dart project authors.  Please see the AUTHORS file
+// for details. All rights reserved. Use of this source code is governed by a
+// BSD-style license that can be found in the LICENSE file.
+
+part of dart.isolate;
+
+/**
+ * An unforgable object that preserves its identity when passed through other
+ * isolates.
+ *
+ * Objects sent through [SendPort]s to other isolates, and back again, will
+ * generally be copied, and will not have the same identity as the original.
+ * A capability object preserves its identity when sent through other isolates.

[floitsch, 2014/01/29 15:26:26]

Do we need the identity requirement?
Equality would probably be enough.

I would say that the main advantage of capabilities is that they are
non-forgeable, can be transferred through isolate-communication, and are
guaranteed to be == only if they originate from the same capability.

They could just contain a random 8-byte string inside.

[Lasse Reichstein Nielsen, 2014/01/29 15:58:13]

I think identity is preferable.
It allows you to use "identical", which doesn't have the problem of accidentally
swapping the order of operands of an '==', which will allow a trick-capability
to claim equality with everything (users can implement Capability, but not
extend it - that's why I made the constructor a factory).

Whatever is stored inside must be completely hidden from user code, and not
accessed through dart code (or you might be able to fake it by extracting the
data and having suitable noSuchMethod behavior provide it).
Using 64 random bits might be fine (if you trust your random generater to not
leak information, I wouldn't trust Math.random in V8).

[floitsch, 2014/01/29 16:52:35]

No doubt about that. The question is, if it's not too expensive.
I'm not sure this is an issue: inside the same isolate you are dead anyways.
Using reflection you can get whatever you want. You would have access to the
capability that is stored somewhere to compare against.
If you had access to the what's inside, then you already have access to the
token.
We will need something like this anyways. We can't transmit anything else.

+ *
+ * Capabilities can be used as access guards: A remote isolate can send
+ * a request for an operation, but it is only allowed if the request contains
+ * the correct capability object.
+ *
+ * This allows exposing the same interface to multiple clients, but restricting
+ * some operations to only those clients that have also been given the
+ * corresponding capability.
+ *
+ * When comparing capabilities, always use identity comparison. That is, either
+ * use [identical] to test, or use the known capability as the left-hand side of
+ * the `==` operator. This prevents a malicious user from providing a fake
+ * capability object with a custom equality that would claim to be equal
+ * to your capability.
+ *
+ * Capabilities can be used inside a single isolate, but they have no advantage
+ * over just using `new Object` to create a unique object. The only advantage
+ * of `Capability` over `Object` is that it preserves its identity when
+ * round-tripped through other isolates.
+ */
+class Capability {
+  /**
+   * Create a new unforgable capability object.
+   */
+  external factory Capability();
+}