XDI Glossary - Examples (2 of 3)

["Drummond Reed" <drummond.reed@cordance.net>]

XDI TC Members:

This message contains a set of example scenarios illustrating the XDI
glossary terms in the previous message. These are also listed on the XRI/XDI
wiki at http://xrixdi.idcommons.net/moin.cgi/XdiGlossary_2fGlossaryExamples.


These examples are intended only to help us test these terms and see if they
work at the necessary level of abstraction and function-neutrality.

See also my next message regarding glossary-related action items for this
week's TC call.

=Drummond 

Formatting note: each term from the proposed XDI Glossary is shown *starred*
and each term from the XRI 1.0 glossary is shown in ''quotes'' the first
time it is used. (Note that a handful of terms have been copied over from
the XRI 1.0 glossary for clarity - these are shown in *bold*.)

= Individual User Opening an XDI Account =

An individual user, Alice, wants to start using XDI data sharing services.
Since it is the Alice's personal data being shared, Alice is a *Data
Authority (DA)*.

Since Alice does not want to host her own XDI services, she needs to obtain
an *XDI account* with an *XDI Service Provider (XSP)* - an organization (or
individual) who offers XDI data sharing services (whether for their own
data, or for another party's data). Let's say in Alice's case this is a
commercial ISP called Jet City. Jet City, being a corporation, is also a DA
for its own organizational data. However in its role as an XSP for Alice,
Jet City will be operating as a *Delegated DA*. That means that Alice has
granted Jet City the authority to host her data and process XDI service
requests on her behalf.

= Registering XRIs =

Just as when Alice opens an email account or gets a personal web page from
Jet City, the first thing Alice needs for her XDI account is an address. Jet
City has its own ''persistent XRI(s)'' within one or more ''community(s)''
that have a global *Identifier Authority (IA)*. Therefore Jet City is a
*Delegated IA*, and in this capacity it assigns Alice's XDI account a
''delegated persistent XRI''. This officially makes Alice's XDI account an
*XDI resource*.

While a persistent XRI is very helpful, Alice would like to have a more
human-friendly identifier to use for her XDI account. So Alice requests Jet
City to register for her a ''reassignable XRI'' with Community Link, an XRI
registry provider. Community Link is another IA, and since it offers an XDI
interface to its registry services, it is also an XSP. As an authorized
registrar for Community Link, Jet City operates as an *XDI Service Consumer
(XSC)* of the registry services offered by Community Link.

Jet City (as an IA/XSC) makes an XDI registration request to the Community
Link registry (as an IA/XSP) and receives a reassignable XRI in response.
This reassignable XRI is mapped to the persistent XRI assigned by Jet City
to Alice's XDI account. Now Alice's XDI account has both persistent and
reassignable XRIs and Alice is and is ready to begin creating adding XDI
resources to her XDI account (an activity not dissimilar from adding new
content and pages to a personal website). Note that in doing this, Alice too
will be acting as a Delegated IA, since each resource she adds will have an
XRI.

= Adding Resources to an XDI Account =

Of course there are multiple ways Alice could begin to populate her XDI
account, but for the sake of simplicity let's say she starts adding *data*
manually via a Web interface provided by Jet City. Each new item of data
(such as contact data, demographic data, travel profile data, etc.), is
assigned at least one new persistent XRI as she stores it, turning it into
an XDI resource. This persistent XRI is the XDI equivalent of an i-node in a
file system or an index key in the database. In addition Alice (or the XDI
interface software she is using) may assign the item one or more
reassignable XRIs (the XDI equivalent of a file name in a file system or a
field name in a database.) 

Alice may also create resources that group together other resources, such as
XDI business cards that link atomic resources such as telephone numbers,
email addresses, and web addresses. In all these cases Alice is the DA, and
she is acting as a Delegated IA when she assigns the identifiers. However it
is important to mention that when Alice is assigning persistent XRIs, she is
acting as a Delegated IA under Jet City, who registered her persistent XRI,
whereas when she is assigning reassignable XRIs, she is acting as a
Delegated IA under Community Link, who registered her reassignable XRI.

= Setting Policies for an XDI Account =

Lastly, Alice can choose the *policies* she wants to control the sharing of
this data. Typically Alice might choose from a menu of XDI data sharing
policies pre-defined and automatically supported by Jet City as her XSP (and
all stored as XDI resources so Jet City and its customers can reference and
reuse them easily). However she may also want to define her own policies, or
select policies defined as XDI resources in some other XDI data sharing
community. In any case these are the policies that Jet City, as her XSP,
must follow when receiving XDI data sharing requests.

= Sharing an XDI Business Card =

Now let's say Alice wants to share one of her XDI business cards with Bob.
Rather than sending Bob the actual XDI resource, she sends Bob an XRI for
this resource (the start of an *XDI link*). When Bob activates this link,
Jet City looks at the XRI, resolves it to Alice's business card, looks at
her policies, and then use them to process Bob's request. Let's imagine four
different scenarios here:

 1. In the first case, Alice's policy simply says Jet City needs to
authenticate that Bob is a human. Jet City presents a human test, Bob passes
it, and Jet City serves up the data. 
 1. In the second case, Alice's policy says Bob needs to have an
authenticated email address. So Jet City sends him an authentication email,
he responds, and Jet City serves up the data. 
 1. In the third case, Alice's policy says Bob must have an XDI account so
she and Bob can create a persistent XDI link. So Jet City asks Bob to enter
an XRI for his account, then Jet City as an XSC sends an XDI message to
Bob's XSP to authenticate Bob has an account. Bob's XSP responds back with a
satisfactory authentication assertion. Now Jet City and Bob's XSP negotiate
the *XDI link contract* that satisfies both Alice's and Bob's data sharing
policies. Assuming there is agreement and that Bob wants a cached copy of
Alice's XDI business card, Jet City sends it to Bob's XSP and the persistent
XDI link is formed. 
 1. In the fourth case, Alice's policy says Bob's XSP must belong to a
specified *XDI community*. This is identical to previous case, except Bob's
XSP must not only return an authentication assertion for Bob, but one
authenticating that it belongs to the specified XDI community. Again, if
successful, Alice and Bob end up with an XDI link.

[END OF CURRENT DRAFT. We can extend this example scenario further as
necessary, but this should be enough to allow: a) TC members to apply this
terminology within their use cases, and b) support discussion of these
glossary items on the next XDI TC call.]