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

[Infinity Linden <[e-mail]>]

the LLIDL describes the contents of a message, not it's address. the
construction

  &identifier = {
    type: 'account',        ; identifies this as an "account identifier"
    account_name: string,
    first_name: string,     ; optional - first_name and last_name
    last_name: string,      ; identify agent to log in as for accounts
                            ; with more than one agent
  }

describes a portion of the message a client sends to a fixed URL, for
the purpose of authenticating itself. it is assumed that the fixed URL
(the authentication URI) is known before attempting to log in. note
that in the account authentication technique accepts an optional
first_name and last_name to be used if the account associated with the
account_name maps to more than one avatar name.

the processing expectation is that the account_name will be a "long
lived" value. however, if people want to do service resolution with
another process and reference short lived values as account_names,
sure, but i don't really see the benefit in that.

i think my main point here is that the subject authenticates
themselves to an agent-domain specific URI, but a third party queries
an agent specific URI for public information about the subject, and
may use that agent specific URI as an identifier in other protocol to
request more information.

but maybe you're getting at the use of capabilities for privileged
access? here's an example.

1. a user authenticates with the example.com agent domain by
presenting it's credentials for the avatar InnovationGrrl Tester to
http://example.com/service/authenticate (the agent domain's
authentication URI,) receives an agent specific seed cap and a series
of agent specific service capabilities. InnovationGrrl's long lived
public URI is http://example.com/a/1AB69DB3-6A7C-4743-9651-AAFF2458B03D.
And, there's an alias for this public URI at
http://agents.example.com/Tester/InnovationGrrl, but it simply
redirects to the other URI. (the latter is there only if there's a
requirement for human memorable public URIs and to assist people who
use the <firstname>.<lastname>@<gridname> format convert it into a
canonical identifier.)

2. the user teleports to a region hosted at secondlife.com and leaves
an object in an area with auto-return turned on. (i.e. - in a few
minutes, the region will attempt to return the item to the agent.)

3. when the region needs to return the item, it requests a "return
item" capability from the agent domain and sends a (as of yet
undefined) message to the agent domain indicating that it is removing
a particular item from itself and the item needs to be returned to the
agent. the region identifies the agent with the long lived URI:
http://example.com/a/1AB69DB3-6A7C-4743-9651-AAFF2458B03D .

-cheers
-meadhbh

On Tue, Jun 30, 2009 at 1:34 AM, Nexii Malthus<[e-mail]> wrote:
> 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:
>>
>> 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:
>>
>> Arbitrary in-world name tags, which have only one intent: to provide a
>> customer-satisfying visual name.
>> Globally unique identifiers, either UUID or formed by composition of
>> N-part local name @ issuing authority.
>> 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
>>
>
>
> _______________________________________________
> ogpx mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ogpx
>
>