[OpenID] Purpose of OpenID Foundation and the Elections

[Peter Williams]

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