[OpenID] Purpose of OpenID Foundation and the Elections

[Pat Cappelaere]

I would really like to hear from the candidates about OpenID branding  
and their position on possible brand extension with OAuth.

What is their brand definition for OpenID and whether or not OAuth  
would be a natural extension?

I really like the discussion that started with Eran and Johannes.

Pat.

On Dec 11, 2008, at 9:12 PM, Peter Williams wrote:

> Sounds like a framework for authorized impersonation, privilege  
> delegation, take-grant authZ, revocable capabilities.
>
> There is lots of DoD/USNavy high-assurance research security models  
> to apply here, now for use in the general infrastructure.
>
> -----Original Message-----
> From: general-bounces at openid.net [mailto:general-bounces at openid.net]  
> On Behalf Of Pat Cappelaere
> Sent: Thursday, December 11, 2008 5:39 PM
> To: Martin Atkins
> Cc: general at openid.net List
> Subject: Re: [OpenID] Purpose of OpenID Foundation and the Elections
>
> Let me restate my premise.
> OpenID + OAuth would allow a consumer to act on behalf of a user (with
> his consent) and access the provider.
> Revoking that consumer would in essence prohibit the consumer from
> impersonating the user and access the provider.
> So it is centered around user identity and its delegation to
> applications under user control.
> This is what I meant.
> Pat.
>
> On Dec 11, 2008, at 8:27 PM, Martin Atkins wrote:
>
>> Pat Cappelaere wrote:
>>> Nice promise.
>>> I would love to extend it one step further:
>>> The data is mine. If I authorize an application to access it on my
>>> behalf, application can then get it.  And I can revoke that grant...
>>> and dispute access...  This is OpenID + OAuth which will now
>>> authorize
>>> transactions between services.  Very close to the VISA experience
>>> actually.  This would not be very hard to implement since most of  
>>> the
>>> infrastructure is already in place.  No reason for providers to
>>> implement it on their own and do it wrong and provide another bad
>>> user
>>> experience.
>>>
>>
>> It's important to be clear about what you mean by revoking access to
>> the
>> data.
>>
>> Information, by its very nature, cannot be "taken back". Once you  
>> tell
>> someone something, you can't un-tell them. You can choose not to give
>> them new information, of course, but they will still know what you
>> told
>> them to start with.
>>
>> Facebook's Platform attempts to work around this using legal
>> agreements
>> in the form of agreeing to the terms of service, which put
>> restrictions
>> on what client applications are allowed to "store". (Whether all
>> application developers comply with this in practice is unclear.)
>>
>> VISA of course has similar contractual arrangements with card
>> providers
>> and merchants, but their framework is far stronger than ticking a
>> box to
>> agree to a terms of service, and I assume involves those involved
>> agreeing to allow auditing to ensure compliance.
>>
>> OpenID as it exists today does not have the legal framework
>> necessary to
>> support this sort of assurance, and some would argue that the "anyone
>> can play" architecture is in fact fundamentally incompatible with
>> such.
>>
>> Of course, this can be mitigated somewhat by being careful what you
>> promise. No-one is claiming that today's OpenID allows you to "take
>> back" information you've previously supplied, it simply aims to make
>> it
>> easier for you to provide the information you *want* to provide.
>>
>> The question is of course whether that is a useful value proposition
>> or
>> whether OpenID needs to do better.
>>
>> _______________________________________________
>> general mailing list
>> general at openid.net
>> http://openid.net/mailman/listinfo/general
>
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general