RE: [xdi] Prototypical use case attempt: Registration

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

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)).

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.

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.

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.

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.

2) Registering a global E-NAME and pointing it at the global e-number to
which it resolves.

3) Doing 1 and 2 at the SAME TIME, to make it easy for registrants.

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).

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).

6) Doing 4 and 5 at the SAME TIME, to make it easy for registrants.

=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
>>>
>>
>