| Principles | Migration | IoT | Connected Road to/from Car | DNS | Block Chain (e.g., OneName, NameCoin) | Distributed Hashes | Promise Theory | Ontology |
|---|
| | | SalesForce | Strong Device Identity (SDID) - Low Computing Power | SDID - High Computing Power | | | | | | |
| Is there a role for a Relationship Manager? | Yes | Yes | Yes | Yes | Yes | | | | | yes (basically, this is the role of the ontology engine here) |
| Scalable | | Reality of IoT Raw device data stream, vs. identity (asset token) | Has to be | Has to be | Yes - Road handles multiple cars but traffic and road usage is applied | v4, v6 | | | | instances, wip rules |
| Actionable | | By the nature of the of the asset token and platform | | | | IANA, Registration | | | | Defined in TBox |
| (Im)Mutable | | Depends on info available from the device | | | Push - TBD | Immutable/Proxy/Forwarding | | | | TBox ->'Reasoner' ->ABox |
| Contextual | | Depends on constraints of the device Nothing that excludes this | | | | Actually provides context | | | | TBox ->'Reasoner' ->ABox |
| Transferrable (Delegation) | | As token of "agency" Need to re-mint token (new JWT) | In terms of Ownership NOT Identity Change (Change vs. Transfer) | In terms of Ownership NOT Identity Change (Change vs. Transfer) | - Today - in the Future - when automated vehicles are on the roads | Bought, Forwarded | | | | Ontology referentials |
| Provable | | If HoK (signed JWT via JOSE) | Requires gateway | | | w/HTTPS DNSSEC | | | | Ontology referentials |
| Acknowledgable | | Allows it to be assigned, you can show this | As capable as the device is | | | NMAP, other | | | | Ontology referentials |
| Revocable | | Delete the token, there is an endpoint for access token status | | | | | (although challenging for the right-to-be-forgotten) | | | Ontology referentials |
| Constrainable | | From the device perspective - not referring to back-end | Difficult to add constraints - limited options | | | Subnets, Domains, etc. | | | | Ontology referentials TBox ->'Reasoner' ->ABox |