Re: [vwrap] Why are we standardizing the login handshake? (was RE: one question)

[Meadhbh Hamrick <[e-mail]>]

because we like capabilities for reasons described earlier this week.

i know morgaine likes to say the intro is beyond repair, but if you
actually read it, there are some interesting little nuggets.

like for instance the whole thing about wanting to support loosely
coupled collections of services. capabilities allow us to avoid (among
other things) the confused deputy problem.

as of yet, there's no other proposal for how to address this issue.

-cheers
-meadhbh
--
meadhbh hamrick * it's pronounced "maeve"
@OhMeadhbh * http://meadhbh.org/ * [e-mail]



On Fri, Sep 24, 2010 at 3:41 PM, Crista Lopes <[e-mail]> wrote:
> On 9/24/2010 3:36 PM, Hurliman, John wrote:
>>>
>>> -----Original Message-----
>>> From: [e-mail] [mailto:[e-mail]] On Behalf
>>> Of Crista Lopes
>>> Sent: Friday, September 24, 2010 3:16 PM
>>> To: [e-mail]
>>> Subject: Re: [vwrap] Why are we standardizing the login handshake? (was
>>> RE: one question)
>>>
>>> On 9/24/2010 3:11 PM, Hurliman, John wrote:
>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: [e-mail] [mailto:[e-mail]] On
>>>>> Behalf Of Crista Lopes
>>>>> Sent: Friday, September 24, 2010 3:07 PM
>>>>> To: [e-mail]
>>>>> Subject: Re: [vwrap] Why are we standardizing the login handshake?
>>>>> (was
>>>>> RE: one question)
>>>>>
>>>>> John,
>>>>>
>>>>> You may also want to read the intro draft.
>>>>> http://tools.ietf.org/html/draft-ietf-vwrap-intro-00
>>>>>
>>>>> This is in 4.4:
>>>>>
>>>>> "VWRAP defines formats  for describing objects and avatar shapes, but
>>>>> more importantly it
>>>>>      describes the mechanism by which those digital asset descriptions
>>>>> are
>>>>>      transferred between client applications, agent domains and region
>>>>>      domains."
>>>>> ...
>>>>> "Accessing and manipulating digital assets is  performed via
>>>>> capabilities which expose the state of the asset to an authorized
>>>>> client. "
>>>>>
>>>>> In other words, assets are fetched by the client. So if my world
>>>>> pushes them to the client, it's not VWRAP-compliant.
>>>>>
>>>>>
>>>>>
>>>>
>>>> You keep saying "if my world does X, it's not VWRAP-compliant". That's
>>>> not
>>>>
>>>
>>> correct. "If my world does not have service endpoint X, it's not VWRAP-
>>> compliant" is the correct statement here. Your world can send assets to
>>> your
>>> client in any way it wishes, but if your asset service does not expose a
>>> VWRAP asset fetch capability (regardless of whether your own client uses
>>> it
>>> or not) then it is not VWRAP-compliant.
>>>
>>>>
>>>>
>>>
>>> So what exactly does this mean? (especially the 2nd sentence, the 1st is
>>> just
>>> for context of the word "client")
>>>
>>>
>>
>> Let's say I have a blog running Wordpress. The default way to leave
>> comments on the blog is to create an account, confirm the e-mail activation,
>> login, then leave a comment. Wordpress is doing a non-standard login
>> (equivalent to "if my world does X"), which makes it neither compliant with
>> OpenID nor non-compliant with OpenID. It is completely orthogonal.
>>
>> Now I install an OpenID plugin for Wordpress that allows people to either
>> use the traditional method, or use OpenID authentication when leaving
>> comments. I've added a service endpoint for accepting OpenID authentication,
>> and my blog is now OpenID compliant.
>>
>> Pushing assets to your client does not make your world non-compliant with
>> VWRAP. Being compliant with VWRAP depends on whether you also have a service
>> endpoint that speaks the VWRAP language, in addition to whatever else your
>> system might be doing.
>>
>
> So why is this prescription in the intro document at all?
>  "Accessing and manipulating digital assets is  performed via capabilities
> which
>  expose the state of the asset to an authorized client. " (where client
> means the client application, in the context of that section)
>
> _______________________________________________
> vwrap mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/vwrap
>