Re: [ogpx] A Review of Multi-Domain Use Cases [Was: Re: OpenID and OGP : beginning the discussion ...]

[Nexii Malthus <[e-mail]>]

Hmmm interesting.

So we have a server-side facing identifier received by the agent domain:
& identifier = {
   type: 'account',
   agent_domain: urlstring,
   account_name: string,
}
(Side question, should there be free-reign for server-side facing arbritary
data too? Could pose some interesting innovations between regiondomains and
agentdomains.)

And client-side facing identifier that is distributed by the server to other
agents as necessary received by the agent domain: (Should the server be
allowed to modify this at will? I could imagine the server wanting to
add/remove or edit meaningful entries programmatically, say a specific user
had admin, maintenance and/or support powers in a region?)
& identifier = {
   type: 'agent',
   arbritarykey: stringvalue,
   morekeys: morevalues,
   etc..
   etc..
}

Limits imposed of course naturally on the amount of keys and values
available and character limit on the strings. It seems like its up to the
client developers how to interpret these. I think, the very first key by
definition should become the most representative name that any client can
use in the most basic form and all other keys left up to interpretation.

What about other profile data? Should there be a agent-domain capability URL
in the client-side facing identifier that a client can use to request a caps
for the profile of this user?

- Nexii

On Tue, Jun 30, 2009 at 8:03 AM, Morgaine <[e-mail]>wrote;wrote:

> On Mon, Jun 29, 2009 at 9:41 PM, Joshua Bell <[e-mail]> wrote:
>
>> Be aware that (firstname, lastname) as a unique identifier within a
>> service is a quirk of Second Life, and not necessarily something that every
>> OGP provider must use. One could imagine services that use single field
>> account identifiers (like most email providers), or allow more flexibility
>> in name choice to match real-world conventions.
>>
>
> +1
>
>>
>> It sounds like we're all agreeing, though - there will be some N-part
>> unique identifier (which may be easily human readable, but may not) issued
>> by an authoritative domain to a user, and given that the domain almost
>> certainly has a globally unique identifier of its own (i.e. DNS name) there
>> is a composition of the two that can give a globally unique identifier for
>> the agent.
>>
>
> +1
>
>>
>> We should also be explicit that these identifiers are not necessarily also
>> used as authentication credentials. Some service providers may want
>> two-factor authentication (e.g. hardware key fob) or private login
>> credentials distinct from any public identifiers for additional security.
>> The 3-tuple login credentials (firstname, lastname, password) which Second
>> Life uses today should not be viewed as the only allowable mechanism.
>>
>
> +1
>
> Joshua, you've provided a very concise and precise summary of the overall
> requirement --- I agree with this entirely.  Condensing it even further, we
> need 3 things, and they are quite independent of each other:
>
>
>    1. Arbitrary in-world name tags, which have only one intent: to provide
>    a customer-satisfying visual name.
>    2. Globally unique identifiers, either UUID or formed by composition of
>    N-part local name @ issuing authority.
>    3. Entirely separate authentication credentials, in other words,
>    unrelated to 1) or 2).
>
>
> Keeping these 3 things entirely disjoint would serve us well in many ways,
> particularly in the key areas of scalability, flexibility, uniqueness, and
> user-friendliness / appropriateness.
>
>
> Morgaine.
>
>
> _______________________________________________
> ogpx mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ogpx
>
>