XDI Review and Demo
Personal Data Ownership in a Corporate World
Wednesday 1D
Convener:Markus S.
Notes-taker(s): Hugh P.
Tags for the session - technology discussed/ideas considered: XDI Names
Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:
People: identified with '=' identifier. The Leola “nymble” registry uses +nym=markus (etc). Then: Organizations (name begins with '+'). Finally, Things (prefix is '*').
Some more discussion of names (global forms, local forms) & registry & their scope, context, and semantics. (The subject of names is way too big to handle this session but XDI designed to describe those context & relationships.) Drummond enumerated the six contexts
- two authority-types: = and +. Only for privacy purposes.
- two instance-types. *:unordered-list. @: ordered-list.
- two classes: hashtag (#friend etc), used by the community; dollar-sign ($and $or $not $msg $if $uri), used by the XDI Itself.
---
xdi2: Java implementation (http://xdi2.org)
Tools: parser, signatures, discovery
discovery: the registry resolves =name to an authority URI (someone running an XDI service that hosts the graph for this name). Then it'll query the authority & get (e.g.) public keys for signature.
Support multiple registries. But the registry is just how to find the name. Graphs themselves just interoperate. Point from one to the other. Also pseudonym thing ("wrapper") that hides the underlying name from you, you only see the pseudonym in the result.
Signature things: just a convention, not deeply assumed into the XDI language itself. Over time there will be a data dictionary defining common names for the standard things, e.g. cryptosystems, signatures, and so on.
---
Some higher-level tools. See the list of demos, http://xdi2.org/demos.html. Things that can be useful as functional building-blocks for the application layer.
link contract: permissioning steps. e.g pizza demo: provide my address without typing it in, by instead making a link contract that describes that the pizza site is allowed to connect to my personal cloud for the purpose of reading my address. The "forever address-book" thing. Ongoing connection, revocable. Unlike OpenID Connect where attributes are transferred once; this creates a permanent connection (will also persist if you move your graph from one place to another, as long as I maintain the link contract, its UUID doesn't change).
q: what about the problem domain of reverse-id - verifying identity of a phone caller from amex when they ask for all your personal information to authenticate. Routine scam model.
Cloud cards similar, connections between individuals. Webpage that shows some of my profile information.
q: relationship with uma? some discussions. OAuth about access to a single resource. UMA for one place where I manage my permissions in different service providers, with all the people I want to give permission to. Could relate directly with the link-contract mechanism.
q: blockchain - use case for peer-to-peer assertions about things at a moment in time. How would that with XDI? Things that could be done there.
