[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: XDI Glossary - Examples (2 of 3)
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.]
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]