A Look At IRM in the Wild

The following table is a working document which reflects the various "IRM in the Wild" use cases the IRM WG is discussing and how each applies to the IRM Principles as they are currently defined.


Use/Business Cases Explored

PrinciplesMigrationIoTConnected Road to/from CarDNS

Block Chain

(e.g., OneName, NameCoin)
Distributed HashesPromise TheoryOntology
  SalesForceStrong Device Identity (SDID) - Low Computing PowerSDID - High Computing Power      
Is there a role for a Relationship Manager?YesYesYesYesYes    yes (basically, this is the role of the ontology engine here)

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



By the nature of the of the asset token and platform



IANA, Registration


Defined in TBox


Depends on info available from the device

Push - TBD



TBox ->'Reasoner' ->ABox

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

If HoK (signed JWT via JOSE)

Requires gateway



Ontology referentials

Allows it to be assigned, you can show this

As capable as the device is

NMAP, other


Ontology referentials

Delete the token, there is an endpoint for access token status

(although challenging for the right-to-be-forgotten)


Ontology referentials

From the device perspective - not referring to back-end

Difficult to add constraints - limited options

Subnets, Domains, etc.


Ontology referentials

TBox ->'Reasoner' ->ABox


Architecture Notions

Scope it/ Profile 
Bounded for use/links to the real worldSAML, UMA?
Are components a viable approach?


OpenID Connect

At the IdP layer as backend or data store, "contextual identity store"

Can't change the apps

Hack the IdP

Hack the manager be it the IdP or the AS

Is it a rule generator?

"Contextual claims compiler"

Co-opt the IdP

Human Understandable

Are there simplifying assumptions? 
IRM provides the context for AuthZ? 
Build up the attributes from IdP in order to meet need for a claim 
Semantic aspects 
Distributed Ledgers