[OpenID] Musing on FaceBook, OpenID and the next mountain to climb
Peter Williams
pwilliams at rapattoni.com
Wed Jul 30 17:05:50 UTC 2008
Focus on signals for providing and verifyin trust/assurance levels (just like ssl sends lists acceptable CAs and proposed ciphersuites)
Don't address the "battle of the legal terms" topic (avoid doing as did those who wanted certain legal presumptions or obligations to be established when, for example, a cert from a certain authority bearing a certain exension is handled by the relying party)
What we ideally don't want to focus on is the scenario in which the rp claims to the user, after an openid e-commerce experience: ah but the fine print in the policy presented during rp discovery shows you (via your op) agreed that this transaction would be limited to, for example, final sale rules (no return rights).
-----Original Message-----
From: Johannes Ernst <jernst+openid.net at netmesh.us>
Sent: Wednesday, July 30, 2008 9:47 AM
To: Peter Williams <pwilliams at rapattoni.com>
Cc: OpenID List <general at openid.net>
Subject: Re: [OpenID] Musing on FaceBook, OpenID and the next mountain to climb
So what would that mean in terms of what work to focus on what work to
leave out?
On 2008/07/30, at 8:23, Peter Williams wrote:
> Every handshake protocol eventually hits the point where scalability
> and assurance requirements lead design teams to consider capability
> exchange and negotiation. For example, in ssl one has ciphersuites
> and trust points, each being negotiated in a suitable phase of the
> handshake. In the case of ssl, much of the capability negotiation
> and management is delegated - to the key management protocol that
> aligns with the ciphersuite (eg kerberos for kerberos ciphersuites).
> One can venture that ssl adoptability was in part due to reliance on
> such infrastructures for trustworthiness and assurance: which
> allowed the designers to avoid reengineering the wheel, probably
> badly. Negotiation of capabilities exchange security handshakes
> requires careful security handshake design, note.
>
> Openid might want to take the posture that its goal is to provide
> the integration points for other system's reputation,
> trustworthiness, capability negotiations handling. For example, one
> might opt to let established routing logic handle trustwortiness
> metrics (since handling of routes of different trustworthiness is an
> advanced art in the vpn and virtual routing domain fields, these
> days).
>
> Id split from assurance/trustworthiness issues the issue of terms
> negotiation. In both the edi and early pki era, folks played with
> using such as cert fields to encode legal terms, and otherwise use
> reliance procedures to attempt to enact legal agreements and legal
> obligation passing. Neither wasparticularly succesful, though there
> is always large amounts of interest generated - given the nature of
> those problems. Not a lot tends to result, however: reflecting the
> fact prhaps that some things are just better handled procedurally,
> rather than by using machine logic.
>
> -----Original Message-----
> From: Nat Sakimura <n-sakimura at nri.co.jp>
> Sent: Tuesday, July 29, 2008 11:40 PM
> To: Johannes Ernst <jernst+openid.net at netmesh.us>; OpenID List <general at openid.net
> >
> Subject: Re: [OpenID] Musing on FaceBook, OpenID and the next
> mountain to climb
>
>
> I'd volunteer, but, for drafting the WG charter,
> I need more input from the people on this list on
> what should be in the scope.
>
> For me, I was thinking of the below for sometime:
>
> 1) Contralct Negotiation Protocol
> - Negotiates the terms of the use, and back channel data transfer
> protocol.
> 2) Reputation Service Protocol
> - Means to obtain the trustworthiness score of an assertion.
>
> In terms of Johannes's enumeration:
>
>> - single-sign-on across the web with a simple user experience
> => OpenID Authentication 2.0 + some more security features.
>
>> - high-quality identity information available to RPs
> => 1) + 2) above.
>
>> - social network information available to RPs
> => 1) + 2) above.
>
>> - communication from RP into the social network of the user
> => I am still vague on what it will be like.
> Could someone post a concrete example usecase, please?
>
> =nat
>
>
>
> On Wed, 30 Jul 2008 13:05:48 +0900, Johannes Ernst
> <jernst+openid.net at netmesh.us> wrote:
>
>> Like others, I've been amazed about what Facebook has put together
>> with Facebook Connect as announced last week.
>>
>> Their proposition for relying parties seems to be:
>>
>> - single-sign-on across the web with a simple user experience
>> - high-quality identity information available to RPs
>> - social network information available to RPs
>> - communication from RP into the social network of the user
>>
>> and IMHO, that is indeed a great business proposition for RPs.
>>
>> Of course, they seem to be building this with Facebook-specific
>> protocols, but that's not surprising given that the OpenID technology
>> stack right now is insufficient to accomplish what they wanted to
>> accomplish. But not dramatically so -- it might just be plugging some
>> other technologies into OpenID (like XFN or FOAF etc.) and filling in
>> some gaps if one wanted to do that.
>>
>> So ... methinks we should grow the OpenID stack over the next 6-12
>> months to be able to do all of this (and more?) with open
>> technologies. This would also make OpenID much more interesting to
>> relying parties...
>>
>> Open protocols are clearly necessary to grow the entire market, which
>> would be in the interest of everybody including Facebook.
>>
>> Anybody up to getting an OpenID working group started up to work on
>> this?
>>
>> [Feel free to respond on the list or privately.]
>>
>>
>>
>> Johannes Ernst
>> NetMesh Inc.
>>
>>
>
>
>
> --
> =nat
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general
More information about the general
mailing list