[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [XRIXDI] RE: [xdi] Prototypical use case attempt: Registration
Fen, per my last response to Victor, you are correct, I was assuming that the e-numbers were assigned by the Registry. So =:1000/:1234 would be assigned by the = Registry, and could then be used as a cross-reference under their own e-number/e-name space by each Registrar or Data Broker that needs to reference the same logical registrant. =Drummond -----Original Message----- From: Fen Labalme [mailto:fen@idcommons.net] Sent: Thursday, May 06, 2004 12:06 AM To: Drummond Reed Cc: 'XDI TC'; xrixdi@idcommons.net Subject: Re: [XRIXDI] RE: [xdi] Prototypical use case attempt: Registration There's still the problem of who *chooses* the e-number being registered. A Registry working with several Registrars could not allow each Registrar to define an e-number to be registered in the Registry's "e-number-space" for reasons of e-number collisions. In your previous example (a few emails back), you wrote: >>>Global e-name: =Drummond >>>Global e-number: =:1000/:1234 I parse these numbers to read :1000 is the Registry (e.g. Neustar) and :1234 is Drummond's unique e-number. (Perhaps I am parsing it incorrectly? Is the :1000 referring to the Registrar?) If my parsing is accurate, then the Registry *must* be in charge of creating these e-numbers. The *reason* for creating them is to tack on to the URI the Registrar provides (pointing to, in our case, a Data Broker), so that the entire URI might look something like: https://data.broker.com/xri/global/(=:1000/:1234) This provides a resolvable, privacy protected path to (e.g.) Drummond's profile data. Further comments prefixed by "FEN>" below. Drummond Reed wrote: > Here's the way I see it (which is all in terms of XRI synonyms, mind you). > > Any registry at any level that wants to be able to track an XDI account > separate from the e-names registered to resolve to that account will issue > an e-number for the account. Thanks to XRI cross-referencing, that e-number > can then be used in the context of any other registry or XSP to identify > that account (simply by cross-referencing it under their own e-name(s) or > e-number(s)). FEN> So yes, the Registry is in charge of issuing e-numbers. The Registrar will have to have a mechanism (at e-name registration time) of obtaining this e-number. FEN> Separate question: when is a cross-reference not opaque? The second registry, using a cross-referenced e-number issued by the first registry, must have some way of knowing that this is not just a string of characters, but rather a string that "references" > The global registry services will almost certainly follow this policy > because that's what we're going to propose to XDI.ORG. > > Therefore the scenario when doing a global e-name resolution request with > the global registry will be as follows: > > 1) global e-name is resolved to > 2) global e-number which is resolved to > 3) current URI registered for that global e-number. FEN> This is our understanding, too. > In the case of an individual in the Identity Commons model, this current URI > will point to the registrant's XDI account at whatever data broker a > user/organization has selected to be their home data broker for that e-name. FEN> Yes, as noted above. > Note that this means if a user/organization wants to register multiple > global e-names, the user/organization has the option of resolving them to > the SAME XDI account or to DIFFERENT XDI accounts. This may be confusing to > the user/organization, but it's essentially the same thing as registering a > second domain name and having it point to a) an existing website, or b) a > new website. FEN> Such synonymous resolutions could occur either at the Registry (multiple e-names to same e-number) or at the Data Broker (multiple e-names to multiple e-numbers that all resolve to the same place). > Thus these options must be accounted for in the registration scenarios, > i.e., there must be scenarios for: > > 1) Registering a global E-NUMBER and the corresponding URI for the XDI > resource (such as an XDI account) to which it resolves. FEN> Can a Registrar register a global e-number of its choosing? This seems ripe for e-number-space collisions, unless the Registrar prefixes the e-number with its own e-number, effectively making the Registrar a Registry of e-numbers in its local space. In such a case, wouldn't the e-number being Registered to the "Global" Registry then be a cross-reference to the e-number in the Registrar's name space? > 2) Registering a global E-NAME and pointing it at the global e-number to > which it resolves. FEN> This is the simple case. > 3) Doing 1 and 2 at the SAME TIME, to make it easy for registrants. FEN> My suggestion is that the registrant submits an e-name to the Registrar, which in turn submits it to the Registry along with the base URI for the e-name's resolution authority (Data Broker). The Registry then returns to the Registrar an associated "Registry-global" e-number. Finally, the Registrar, which is in close association with the Data Broker, passes this e-number to the Data Broker for account set up. FEN> This scenario is described in a bit more detail in "Variation 1: Steps/Activities" of the UseCase at http://xrixdi.idcommons.net/moin.cgi/XdiUseCases_2fEnameRegistration > 4) Registering a SECOND (or Nth) global e-number (i.e., repeating 1, but for > a new XDI resource, such as a second and completely independent XDI > account). FEN> Again, can the Registrar register global e-numbers of its choosing? On the other hand, I imagine that some entities may desire e-numbers and not need an e-name. This is no problem at all, as the Registrar would simply be requesting the registration of an empty (NULL) e-name, which could be defined (by protocol) to mean that only an e-number is necessary. In this case, the Registry would issue and e-number and return it, and internally attach the URI to the resolution authority in the same way as if an e-name had been requested. > 5) Registering a SECOND (or Nth) global e-name (i.e., repeating 2, but > pointing it at the selected e-number, which could be anything registered in > 1 or 4). FEN> This is easy, just attach the same e-number to an e-name in the Registry (though a protocol for this will have to be developed). If not done at the Registry, it could easily be accomplished by the Data Broker. > 6) Doing 4 and 5 at the SAME TIME, to make it easy for registrants. FEN> Again, if e-name driven, this is easy. > =Drummond > > > -----Original Message----- > From: Fen Labalme [mailto:fen@idcommons.org] > Sent: Wednesday, May 05, 2004 3:01 PM > To: Peter C Davis > Cc: Drummond Reed; 'XDI TC' > Subject: Re: [xdi] Prototypical use case attempt: Registration > > Let's talk Global e-names/e-numbers only, as local communities have > their own Registries and yes, those local Registries will generate local > e-numbers for the e-names that are unique within their local namespace. > So talking Global only is similar to talking Local only - what applies > in one case will apply to the other. > > There's a problem with both the Registry and the Registrar generating > e-numbers in that resolving an e-name must occur via a Data Broker that > maintains the contracts for the user's data access. So when setting up > a new e-name, the Registry must have three pieces of information: 1) the > e-name, 2) the Data Broker URL, and 3) the e-number. The Registrar, > which works closely with the Data Broker, provides the e-number to the > Data Broker when the account is set up. > > When a Registry is asked to resolve an e-name, it does a re-direct to > the Data Broker with the e-number, and then the Data Broker determines > access rights. So the Registry and Data Broker must both know the > e-number associated with an e-name. (The Registrar only needs to know > it for purposes of setting up the various accounts.) > > We considered having the Registrar generate the e-number, but since the > uniqueness property of the e-name relies on the Registry, we felt that > the Registry ought to also ensure the uniqueness of the e-numbers. > Also, it makes more sense for the user's e-number to be associated with > their Registry (community) rather than some random Registrar that is > merely acting as the middleman in the deal. > > Does this make sense? > > Fen > > > Peter C Davis wrote: > >>yeah, i tend to agree w/drummond on this.. that the registry MAY produce >>an e number when requested, and maintains uniqueness 9outside the domain >>of the registrar). >> >>--- peterd >> >>On Wed, 2004-05-05 at 13:46, Drummond Reed wrote: >> >> >>>RE the generation of e-numbers for e-names, I believe BOTH the Registry > > and > >>>the Registrar/Broker should assign an e-number corresponding to the > > e-name, > >>>though the latter should probably be a cross-reference to the former. > > Here's > >>>why: >>> >>>* The global e-number produced by the Registry is what enables the >>>registrant's account to be portable among Registrars/Brokers. >>> >>>* The local e-number produced by the Registrar/Broker is what enables >>>identification of the registrant's account in a local context, i.e., at > > that > >>>particular Registrar/Broker. >>> >>>Example (using my own global personal e-name) >>> >>>Global e-name: =Drummond >>>Global e-number: =:1000/:1234 >>>Local e-number: @:1001/(=:1000/:1234) >>> >>>Now, the challenge I see in doing all this for Identity Commons E-name > > Early > >>>Registration Program is that the policies for the structure and assignment >>>of global e-numbers need to be set by XDI.ORG in the global services >>>specifications that won't be published until this summer and approved > > until > >>>September. >>> >>>So for the E-name Early Registration Program, it may make sense for > > Identity > >>>Commons to assign its own local e-numbers, then retrofit global e-numbers > > as > >>>synonyms during the transition period between the E-name Early > > Registration > >>>Program and the start of general e-name registration. >>> >>>=Drummond >>> >>>-----Original Message----- >>>From: Fen Labalme [mailto:fen@idcommons.org] >>>Sent: Wednesday, May 05, 2004 9:32 AM >>>To: Peter C Davis >>>Cc: XDI TC >>>Subject: Re: [xdi] Prototypical use case attempt: Registration >>> >>>Thanks Peter. SourceID and OpenSAML/Shibboleth are definitely on our >>>radar screen for our reference implementation, though we are not yet >>>integrating them into our current (alpha) code base. FYI, we (Identity >>>Commons) have collected a set of links and resources we find useful >>>here: http://wiki.idcommons.net/moin.cgi/SSXDI_2fLinks >>> >>>Did you get a chance to look at the EnameRegistration page? >>>http://xrixdi.idcommons.net/moin.cgi/XdiUseCases/EnameRegistration >>> >>>There's an issue regarding the fact that we are expecting the Registry >>>to generate and return an e-number associated with an e-name that is >>>being registered. We considered having the Registrar generate the >>>e-number, but as it is the Registry that "defines" a community (and >>>ensures uniqueness of e-names within that community) it seems that the >>>Registry ought also to generate the unique e-number. >>> >>>Best, >>>Fen >>> >>> >>>Peter C Davis wrote: >>> >>> >>>>>Next question: is anyone working on #2, Generic Data Sharing, >>>>>particularly WRT Create and Query, as that is our next hurdle. >>>> >>>> >>>>_IF_ the TC moves towards buidling on other composable architectures, >>>>such as Liberty and WS-*, then you may take a look at sourceID, which >>>>has impimented the Attribute protocols within Liberty (aka DST >>>>Framework). This is a specific profile of DST (PIP), but it may give >>>>you a good baseline reference. >>>> >>>>--- peterd >>>> >>> > > > _______________________________________________ > XRIXDI mailing list > XRIXDI@idcommons.net > http://idcommons.net/cgi-bin/mailman/listinfo/xrixdi >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]